Hi Andrey,
Thanks for this driver. Some review comments below:
On 07/09/2016 09:46 PM, Andrey Utkin wrote:
> From: Andrey Utkin
>
>
> Changes in v3 since v2:
> - Kconfig: select VIDEOBUF2_DMA_CONTIG, not SG
> - drop i2c code as unused
> - Dropped
Hi Andrey,
Thanks for this driver. Some review comments below:
On 07/09/2016 09:46 PM, Andrey Utkin wrote:
> From: Andrey Utkin
>
>
> Changes in v3 since v2:
> - Kconfig: select VIDEOBUF2_DMA_CONTIG, not SG
> - drop i2c code as unused
> - Dropped num_buffers check in queue_setup as
On 07/09/2016 11:23 AM, Randy Li wrote:
> Those platforms are reported to use the same rtc IP core
> as exynos3250's.
Insufficient. Exynos4 also has to be updated. Actually all SoC from SoC
family requires rtc src clock. I think S3C6410 also requires it but I
don't have all the data necessary to
On 07/09/2016 11:23 AM, Randy Li wrote:
> Those platforms are reported to use the same rtc IP core
> as exynos3250's.
Insufficient. Exynos4 also has to be updated. Actually all SoC from SoC
family requires rtc src clock. I think S3C6410 also requires it but I
don't have all the data necessary to
On 07/09/2016 11:23 AM, Randy Li wrote:
> The device data for samsung,exynos3250-rtc and samsung,s3c6410-rtc
> are just have a difference, but keeping using the same device data
> would cause the platform using the other IP core not work.
I cannot understand what you wanted to say here. Please
On 07/09/2016 11:23 AM, Randy Li wrote:
> The device data for samsung,exynos3250-rtc and samsung,s3c6410-rtc
> are just have a difference, but keeping using the same device data
> would cause the platform using the other IP core not work.
I cannot understand what you wanted to say here. Please
On 07/09/2016 11:23 AM, Randy Li wrote:
> This reverts commit 8792f7772f4f40ffc68bad5f28311205584b734d.
> The s3c6410 rtc don't use rtc_src property, that property is designed
> for Exynos5250 and Exynos5440. The problem reported in the commit
> I mentioned should be fixed in the other way.
...
On 07/09/2016 11:23 AM, Randy Li wrote:
> This reverts commit 8792f7772f4f40ffc68bad5f28311205584b734d.
> The s3c6410 rtc don't use rtc_src property, that property is designed
> for Exynos5250 and Exynos5440. The problem reported in the commit
> I mentioned should be fixed in the other way.
...
On Thu, Jul 07, 2016 at 03:21:10PM -0700, Stephen Boyd wrote:
> The ULPI phy on qcom platforms needs to be initialized and
> powered on after a USB reset and before we toggle the run/stop
> bit. Otherwise, the phy locks up and doesn't work properly. Hook
> the phy initialization into the RESET
On Thu, Jul 07, 2016 at 03:21:11PM -0700, Stephen Boyd wrote:
> If something fails in ci_hdrc_add_device() due to probe defer, we
> shouldn't print an error message. Be silent in this case as we'll
> try probe again later.
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
On 07/09/2016 11:23 AM, Randy Li wrote:
> The 8792f7772f4f40ffc68bad5f28311205584b734d would just make those
> platform using rtc core from exynos3250 work but have a huge
> effect on those platforms using the rtc core from s3c6410.
> These patches would fix this problem.
>
Which problem? What
On Thu, Jul 07, 2016 at 03:21:10PM -0700, Stephen Boyd wrote:
> The ULPI phy on qcom platforms needs to be initialized and
> powered on after a USB reset and before we toggle the run/stop
> bit. Otherwise, the phy locks up and doesn't work properly. Hook
> the phy initialization into the RESET
On Thu, Jul 07, 2016 at 03:21:11PM -0700, Stephen Boyd wrote:
> If something fails in ci_hdrc_add_device() due to probe defer, we
> shouldn't print an error message. Be silent in this case as we'll
> try probe again later.
>
> Cc: Peter Chen
> Cc: Greg Kroah-Hartman
> Signed-off-by: Stephen
On 07/09/2016 11:23 AM, Randy Li wrote:
> The 8792f7772f4f40ffc68bad5f28311205584b734d would just make those
> platform using rtc core from exynos3250 work but have a huge
> effect on those platforms using the rtc core from s3c6410.
> These patches would fix this problem.
>
Which problem? What
On Thu, Jul 07, 2016 at 03:21:09PM -0700, Stephen Boyd wrote:
> The MSM chipidea wrapper has two bits that are used to reset the
> first or second phy. Add support for these bits via the reset
> controller framework, so that phy drivers can reset their
> hardware at the right time during
On Thu, Jul 07, 2016 at 03:21:09PM -0700, Stephen Boyd wrote:
> The MSM chipidea wrapper has two bits that are used to reset the
> first or second phy. Add support for these bits via the reset
> controller framework, so that phy drivers can reset their
> hardware at the right time during
On Thu, Jul 07, 2016 at 03:21:08PM -0700, Stephen Boyd wrote:
> If two devices are probed with this same driver, they'll share
> the same platform data structure, while the chipidea core layer
> writes and modifies it. This can lead to interesting results
> especially if one device is an OTG type
On Thu, Jul 07, 2016 at 03:21:08PM -0700, Stephen Boyd wrote:
> If two devices are probed with this same driver, they'll share
> the same platform data structure, while the chipidea core layer
> writes and modifies it. This can lead to interesting results
> especially if one device is an OTG type
From: Jiada Wang
Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate
From: Jiada Wang
Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
On Thu, Jul 07, 2016 at 03:21:07PM -0700, Stephen Boyd wrote:
> When the RESET bit is set in the USBCMD register it resets quite
> a few of the wrapper's registers to their reset state. This
> includes the GENCONFIG and GENCONFIG2 registers. Currently this
> is done by the usb phy and ehci-msm
On Thu, Jul 07, 2016 at 03:21:07PM -0700, Stephen Boyd wrote:
> When the RESET bit is set in the USBCMD register it resets quite
> a few of the wrapper's registers to their reset state. This
> includes the GENCONFIG and GENCONFIG2 registers. Currently this
> is done by the usb phy and ehci-msm
Hi Mika,
On Mon, 11 Jul 2016 07:48:17 +0300 Mika Westerberg
wrote:
>
> Looks like it is the module name (configfs.o) that confuses modpost or
> linker. The below patch fixes it for me.
That makes sense. Thanks.
--
Cheers,
Stephen Rothwell
Hi Mika,
On Mon, 11 Jul 2016 07:48:17 +0300 Mika Westerberg
wrote:
>
> Looks like it is the module name (configfs.o) that confuses modpost or
> linker. The below patch fixes it for me.
That makes sense. Thanks.
--
Cheers,
Stephen Rothwell
Hi all,
On Thu, 7 Jul 2016 14:12:26 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the clockevents tree got a conflict in:
>
> arch/arm/Kconfig
>
> between commit:
>
> c86f51737f8d ("ARM: clps711x: Switch to MULTIPLATFORM")
>
> from the arm-soc tree
Hi Felipe,
On 1 July 2016 at 14:05, Baolin Wang wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this
Hi all,
On Thu, 7 Jul 2016 14:12:26 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the clockevents tree got a conflict in:
>
> arch/arm/Kconfig
>
> between commit:
>
> c86f51737f8d ("ARM: clps711x: Switch to MULTIPLATFORM")
>
> from the arm-soc tree and commit:
>
>
Hi Felipe,
On 1 July 2016 at 14:05, Baolin Wang wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this in their kernels
> or
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/kernel/x86_init.c
between commit:
255303026193 ("x86: apply more __ro_after_init and const")
from the kspp tree and commit:
1bf8915ae515 ("x86/tsc: Enumerate SKL cpu_khz and tsc_khz via CPUID")
from the tip
Hi, Theodore
On Sun, Jul 10, 2016 at 11:15:53PM -0400, Theodore Ts'o wrote:
>On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
>>
>> FYI, we noticed the following commit:
>>
>> https://github.com/0day-ci/linux
>>
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/kernel/x86_init.c
between commit:
255303026193 ("x86: apply more __ro_after_init and const")
from the kspp tree and commit:
1bf8915ae515 ("x86/tsc: Enumerate SKL cpu_khz and tsc_khz via CPUID")
from the tip
Hi, Theodore
On Sun, Jul 10, 2016 at 11:15:53PM -0400, Theodore Ts'o wrote:
>On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
>>
>> FYI, we noticed the following commit:
>>
>> https://github.com/0day-ci/linux
>>
From:
Date: Thu, 7 Jul 2016 20:23:30 -0700
> From: Tien Hock Loh
>
> This adds support for TSE PCS that uses SGMII adapter when the phy-mode of
> the dwmac is set to sgmii.
>
> Signed-off-by: Tien Hock Loh
> Acked-by: Rob Herring
From:
Date: Thu, 7 Jul 2016 20:23:30 -0700
> From: Tien Hock Loh
>
> This adds support for TSE PCS that uses SGMII adapter when the phy-mode of
> the dwmac is set to sgmii.
>
> Signed-off-by: Tien Hock Loh
> Acked-by: Rob Herring
Applied to net-next, thanks.
Hi Prahlad,
On Sunday 10 July 2016 01:35 AM, Prahlad V wrote:
> When a word length of 1 byte is selected and writing data of length
> more than QSPI_WLEN_MAX_BYTES, first MAX_BYTES will be transfered
> and remaining will be transfered byte by byte. In that case wlen
> field should be cleared
Hi Prahlad,
On Sunday 10 July 2016 01:35 AM, Prahlad V wrote:
> When a word length of 1 byte is selected and writing data of length
> more than QSPI_WLEN_MAX_BYTES, first MAX_BYTES will be transfered
> and remaining will be transfered byte by byte. In that case wlen
> field should be cleared
On 2016/07/08 at 19:28, Juri Lelli wrote:
> setup_new_dl_entity() takes two parameters, but it only actually uses
> one of them, under a different name, to setup a new dl_entity, after:
>
> 2f9f3fdc928 "sched/deadline: Remove dl_new from struct sched_dl_entity"
>
> as we currently do
>
>
On 2016/07/08 at 19:28, Juri Lelli wrote:
> setup_new_dl_entity() takes two parameters, but it only actually uses
> one of them, under a different name, to setup a new dl_entity, after:
>
> 2f9f3fdc928 "sched/deadline: Remove dl_new from struct sched_dl_entity"
>
> as we currently do
>
>
2016-07-08 20:02 GMT+08:00 Paolo Bonzini :
> As mentioned earlier, I don't have a reproducer yet that requires any
> changes beyond Wanpeng's (patch 1)---it's possible of course to write
> a kvm-unit-test testcase but I haven't had time for that yet.
>
> Thanks,
>
> Paolo
2016-07-08 20:02 GMT+08:00 Paolo Bonzini :
> As mentioned earlier, I don't have a reproducer yet that requires any
> changes beyond Wanpeng's (patch 1)---it's possible of course to write
> a kvm-unit-test testcase but I haven't had time for that yet.
>
> Thanks,
>
> Paolo Bonzini (2):
> KVM:
From: Jiada Wang
Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate
From: Jiada Wang
Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
fs/f2fs/data.c
between commits:
19a5f5e2ef37 ("f2fs: drop any block plugging")
52763a4b7a21 ("f2fs: detect host-managed SMR by feature flag")
78682f794479 ("f2fs: fix to avoid reading out encrypted data in page
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
fs/f2fs/data.c
between commits:
19a5f5e2ef37 ("f2fs: drop any block plugging")
52763a4b7a21 ("f2fs: detect host-managed SMR by feature flag")
78682f794479 ("f2fs: fix to avoid reading out encrypted data in page
On Thu, Jul 07, 2016 at 03:21:06PM -0700, Stephen Boyd wrote:
> We need to pick the correct phy at runtime based on how the SoC
> has been wired onto the board. If the secondary phy is used, take
> it out of reset and mux over to it by writing into the TCSR
> register. Make sure to do this on
On Thu, Jul 07, 2016 at 03:21:06PM -0700, Stephen Boyd wrote:
> We need to pick the correct phy at runtime based on how the SoC
> has been wired onto the board. If the secondary phy is used, take
> it out of reset and mux over to it by writing into the TCSR
> register. Make sure to do this on
On Mon, Jul 11, 2016 at 11:46:53AM +1000, Stephen Rothwell wrote:
> Hi Rafael,
>
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko]
> undefined!
> ERROR:
On Mon, Jul 11, 2016 at 11:46:53AM +1000, Stephen Rothwell wrote:
> Hi Rafael,
>
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko]
> undefined!
> ERROR:
On Thu, Jul 07, 2016 at 03:21:05PM -0700, Stephen Boyd wrote:
> The msm chipidea controller uses two main clks, an AHB clk to
> read/write the MMIO registers and a core clk called the system
> clk that drives the controller itself. Add support for these clks
> as they're required in all designs.
>
On Thu, Jul 07, 2016 at 03:21:05PM -0700, Stephen Boyd wrote:
> The msm chipidea controller uses two main clks, an AHB clk to
> read/write the MMIO registers and a core clk called the system
> clk that drives the controller itself. Add support for these clks
> as they're required in all designs.
>
Hi Tiffany,
My apologies for the delay, but here is my review at last:
On 05/30/2016 09:52 AM, Tiffany Lin wrote:
> This patch add g/s_selection support for MT8173
>
> Signed-off-by: Tiffany Lin
> ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 74
>
Hi Tiffany,
My apologies for the delay, but here is my review at last:
On 05/30/2016 09:52 AM, Tiffany Lin wrote:
> This patch add g/s_selection support for MT8173
>
> Signed-off-by: Tiffany Lin
> ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 74
>
> 1
On Jul 9, 2016 1:37 AM, "Ingo Molnar" wrote:
>
>
> * Dave Hansen wrote:
>
> > On 07/08/2016 12:18 AM, Ingo Molnar wrote:
> >
> > > So the question is, what is user-space going to do? Do any glibc patches
> > > exist? How are the user-space library side APIs going
On Jul 9, 2016 1:37 AM, "Ingo Molnar" wrote:
>
>
> * Dave Hansen wrote:
>
> > On 07/08/2016 12:18 AM, Ingo Molnar wrote:
> >
> > > So the question is, what is user-space going to do? Do any glibc patches
> > > exist? How are the user-space library side APIs going to look like?
> >
> > My goal at
Hi Krzysztof,
On 07/09/2016 01:47 AM, Krzysztof Kozlowski wrote:
Enable more drivers for IP blocks for existing Exynos7 and upcoming
Exynos5433:
1. SPI,
2. Watchdog,
3. USB: DWC3, Exynos EHCI and OHCI,
4. Exynos ADC,
5. Samsung PWM.
These are already used by Exynos7 Espresso board or will be
Hi Krzysztof,
On 07/09/2016 01:47 AM, Krzysztof Kozlowski wrote:
Enable more drivers for IP blocks for existing Exynos7 and upcoming
Exynos5433:
1. SPI,
2. Watchdog,
3. USB: DWC3, Exynos EHCI and OHCI,
4. Exynos ADC,
5. Samsung PWM.
These are already used by Exynos7 Espresso board or will be
Hi Hans,
On Fri, 2016-07-08 at 13:44 +0200, Hans Verkuil wrote:
> On 07/07/2016 12:16 PM, tiffany lin wrote:
> > Hi Hans,
> >
> >
> > On Wed, 2016-07-06 at 15:19 +0200, Hans Verkuil wrote:
> >> Hi Tiffany,
> >>
> >> I plan to review this patch series on Friday, but one obvious question is
> >>
Hi Hans,
On Fri, 2016-07-08 at 13:44 +0200, Hans Verkuil wrote:
> On 07/07/2016 12:16 PM, tiffany lin wrote:
> > Hi Hans,
> >
> >
> > On Wed, 2016-07-06 at 15:19 +0200, Hans Verkuil wrote:
> >> Hi Tiffany,
> >>
> >> I plan to review this patch series on Friday, but one obvious question is
> >>
We've had a nicely calm week, which is what I expected - the last rc
really was bigger just due to random timing issues, and not some
worrying pattern about this release cycle. Whew.
Anyway, there's a couple of regressions still being looked at, but
unless anything odd happens, this is going to
We've had a nicely calm week, which is what I expected - the last rc
really was bigger just due to random timing issues, and not some
worrying pattern about this release cycle. Whew.
Anyway, there's a couple of regressions still being looked at, but
unless anything odd happens, this is going to
> improve the system]
> >
> > url:https://github.com/0day-ci/linux/commits/Dan-Williams/replace-
> pcommit-with-ADR-or-directed-flushing/20160710-113558
> > base: https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> libnvdimm-for-next
> > config: i3
uild test ERROR on next-20160708]
> > [cannot apply to v4.7-rc6]
> > [if your patch is applied to the wrong git tree, please drop us a note to
> > help
> improve the system]
> >
> > url:https://github.com/0day-ci/linux/commits/Dan-Williams/replace-
> pcommit-with-A
Hi Arnd,
On 2016/6/28 17:34, Arnd Bergmann wrote:
> On Tuesday, June 28, 2016 5:21:19 PM CEST Dongpo Li wrote:
>> On 2016/6/15 5:20, Arnd Bergmann wrote:
>>> On Tuesday, June 14, 2016 9:17:44 PM CEST Li Dongpo wrote:
On 2016/6/13 17:06, Arnd Bergmann wrote:
> On Monday, June 13, 2016
Hi Arnd,
On 2016/6/28 17:34, Arnd Bergmann wrote:
> On Tuesday, June 28, 2016 5:21:19 PM CEST Dongpo Li wrote:
>> On 2016/6/15 5:20, Arnd Bergmann wrote:
>>> On Tuesday, June 14, 2016 9:17:44 PM CEST Li Dongpo wrote:
On 2016/6/13 17:06, Arnd Bergmann wrote:
> On Monday, June 13, 2016
On Thu, Jul 07, 2016 at 03:21:03PM -0700, Stephen Boyd wrote:
> The core framework already handles setting this parameter with a
> platform quirk. Add the appropriate flag so that we always set
> AHBBURST to 0. Technically DT should be doing this, but we always
> do it for msm chipidea devices so
On Thu, Jul 07, 2016 at 03:21:03PM -0700, Stephen Boyd wrote:
> The core framework already handles setting this parameter with a
> platform quirk. Add the appropriate flag so that we always set
> AHBBURST to 0. Technically DT should be doing this, but we always
> do it for msm chipidea devices so
I'm very surprised that there was a BERT table on an Atom machine. More details
about the machine please. Also BIOS version.
Sent from my iPhone
> On Jul 10, 2016, at 18:43, kernel test robot wrote:
>
>
> FYI, we noticed the following commit:
>
>
I'm very surprised that there was a BERT table on an Atom machine. More details
about the machine please. Also BIOS version.
Sent from my iPhone
> On Jul 10, 2016, at 18:43, kernel test robot wrote:
>
>
> FYI, we noticed the following commit:
>
>
On Thu, Jul 07, 2016 at 03:21:02PM -0700, Stephen Boyd wrote:
> We're not properly marking the glue layer/wrapper device as
> runtime active, so runtime PM believes that the hardware state is
> inactive when we call pm_runtime_enable() in this driver. This
> causes a problem when the glue layer
On Thu, Jul 07, 2016 at 03:21:02PM -0700, Stephen Boyd wrote:
> We're not properly marking the glue layer/wrapper device as
> runtime active, so runtime PM believes that the hardware state is
> inactive when we call pm_runtime_enable() in this driver. This
> causes a problem when the glue layer
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> kexec_locate_mem_hole will be used by the PowerPC kexec_file_load
> implementation to find free memory for the purgatory stack.
>
> Signed-off-by: Thiago Jung Bauermann
> Cc: Eric Biederman
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> kexec_locate_mem_hole will be used by the PowerPC kexec_file_load
> implementation to find free memory for the purgatory stack.
>
> Signed-off-by: Thiago Jung Bauermann
> Cc: Eric Biederman
> Cc: Dave Young
> ---
> include/linux/kexec.h |
On 2016/7/8 22:48, Jiri Olsa wrote:
On Thu, Jul 07, 2016 at 05:34:44AM +, Wang Nan wrote:
SNIP
ret = TEST_FAIL;
- err = do_test(evlist, opts.mmap_pages, _count,
+ err = do_test(evlist, aux_evlist, opts.mmap_pages,
+ _sample_count, _sample_count,
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Adapt all callers to the new function prototype.
>
> In addition, change the type of kexec_buf.buffer from char * to void *.
> There is no particular reason for it to be a char *, and the change
> allows us to get rid of 3 existing casts to
On 2016/7/8 22:48, Jiri Olsa wrote:
On Thu, Jul 07, 2016 at 05:34:44AM +, Wang Nan wrote:
SNIP
ret = TEST_FAIL;
- err = do_test(evlist, opts.mmap_pages, _count,
+ err = do_test(evlist, aux_evlist, opts.mmap_pages,
+ _sample_count, _sample_count,
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Adapt all callers to the new function prototype.
>
> In addition, change the type of kexec_buf.buffer from char * to void *.
> There is no particular reason for it to be a char *, and the change
> allows us to get rid of 3 existing casts to
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Allow architectures to specify a different memory walking function for
> kexec_add_buffer. x86 uses iomem to track reserved memory ranges, but
> PowerPC uses the memblock subsystem.
>
> Signed-off-by: Thiago Jung Bauermann
Hi Rob,
After merging the drm-msm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/hdmi/hdmi.c:523:15: error: initialization from incompatible
pointer type [-Werror=incompatible-pointer-types]
.hw_params = msm_hdmi_audio_hw_params,
^
On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Allow architectures to specify a different memory walking function for
> kexec_add_buffer. x86 uses iomem to track reserved memory ranges, but
> PowerPC uses the memblock subsystem.
>
> Signed-off-by: Thiago Jung Bauermann
> Cc: Eric
Hi Rob,
After merging the drm-msm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/hdmi/hdmi.c:523:15: error: initialization from incompatible
pointer type [-Werror=incompatible-pointer-types]
.hw_params = msm_hdmi_audio_hw_params,
^
Hi,
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> Hi,
>
> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng wrote:
> > There are many AML tables
Hi,
> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
>
> Hi,
>
> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng wrote:
> > There are many AML tables reporting wrong initial lid
On Thu, Jul 07, 2016 at 03:21:01PM -0700, Stephen Boyd wrote:
> Some phys for the chipidea controller are controlled via the ULPI
> viewport. Add support for the ULPI bus so that these sorts of
> phys can be probed and read/written automatically without having
> to duplicate the viewport logic in
On Thu, Jul 07, 2016 at 03:21:01PM -0700, Stephen Boyd wrote:
> Some phys for the chipidea controller are controlled via the ULPI
> viewport. Add support for the ULPI bus so that these sorts of
> phys can be probed and read/written automatically without having
> to duplicate the viewport logic in
On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
>
> FYI, we noticed the following commit:
>
> https://github.com/0day-ci/linux
> Vegard-Nossum/ext4-validate-number-of-clusters-in-group/20160708-041426
> commit 5405511e1a984ab644fa9e29a0d3d958b835ab75 ("ext4: validate number
On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
>
> FYI, we noticed the following commit:
>
> https://github.com/0day-ci/linux
> Vegard-Nossum/ext4-validate-number-of-clusters-in-group/20160708-041426
> commit 5405511e1a984ab644fa9e29a0d3d958b835ab75 ("ext4: validate number
The commit adds the device tree binding documentation for the mediatek
auxadc found on Mediatek MT2701.
Thermal gets auxadc sample data by iio device.
So the commit changes auxadc device tree binding documentation from
/soc/mediatek/auxadc.txt to /iio/adc/mt65xx_auxadc.txt.
Signed-off-by: Zhiyong
On 07/08/16 at 11:48am, Thiago Jung Bauermann wrote:
> Am Donnerstag, 07 Juli 2016, 14:12:45 schrieb Dave Young:
> > If so maybe change a bit from your precious mentioned 7 args proposal like
> > below?
> >
> > struct kexec_file_fd {
> > enum kexec_file_type;
> > int fd;
> > }
> >
> >
The commit adds the device tree binding documentation for the mediatek
auxadc found on Mediatek MT2701.
Thermal gets auxadc sample data by iio device.
So the commit changes auxadc device tree binding documentation from
/soc/mediatek/auxadc.txt to /iio/adc/mt65xx_auxadc.txt.
Signed-off-by: Zhiyong
On 07/08/16 at 11:48am, Thiago Jung Bauermann wrote:
> Am Donnerstag, 07 Juli 2016, 14:12:45 schrieb Dave Young:
> > If so maybe change a bit from your precious mentioned 7 args proposal like
> > below?
> >
> > struct kexec_file_fd {
> > enum kexec_file_type;
> > int fd;
> > }
> >
> >
Add Mediatek auxadc driver based on iio.
It will register a device in iio and support iio.
So thermal can read auxadc channel to sample data by iio device.
It is tested successfully on mt2701 platform.
Mt8173 and mt6577 platforms are not tested.
But the expectation is compatible.
Signed-off-by:
Add Mediatek auxadc driver based on iio.
It will register a device in iio and support iio.
So thermal can read auxadc channel to sample data by iio device.
It is tested successfully on mt2701 platform.
Mt8173 and mt6577 platforms are not tested.
But the expectation is compatible.
Signed-off-by:
This series includes three patches:
1.Change the device tree binding documentation.
2.Add auxadc driver based on linux iio.
3.Add auxadc nodes in the mediatek MT2701 dtsi file.
changes in patch v3:
1).Add '#' before 'io-channel-cells' and change 'auxadc@' to 'adc@' in auxadc
binding document.
This series includes three patches:
1.Change the device tree binding documentation.
2.Add auxadc driver based on linux iio.
3.Add auxadc nodes in the mediatek MT2701 dtsi file.
changes in patch v3:
1).Add '#' before 'io-channel-cells' and change 'auxadc@' to 'adc@' in auxadc
binding document.
[Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900] On
11/07/2016 (Mon 10:30) Wan Zongshun wrote:
>
>
> On 2016年07月11日 05:56, Paul Gortmaker wrote:
> >On Sun, Jul 10, 2016 at 3:27 AM, Wan Zongshun wrote
> >>This driver is to add reset support for nuc900
[Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900] On
11/07/2016 (Mon 10:30) Wan Zongshun wrote:
>
>
> On 2016年07月11日 05:56, Paul Gortmaker wrote:
> >On Sun, Jul 10, 2016 at 3:27 AM, Wan Zongshun wrote
> >>This driver is to add reset support for nuc900 series,
>
Hi Hans,
On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote:
> On 05/30/2016 02:29 PM, Tiffany Lin wrote:
> > Add V4L2_PIX_FMT_MT21 documentation
> >
> > Signed-off-by: Tiffany Lin
> > ---
> > Documentation/DocBook/media/v4l/pixfmt.xml |6 ++
> > 1 file
Hi Hans,
On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote:
> On 05/30/2016 02:29 PM, Tiffany Lin wrote:
> > Add V4L2_PIX_FMT_MT21 documentation
> >
> > Signed-off-by: Tiffany Lin
> > ---
> > Documentation/DocBook/media/v4l/pixfmt.xml |6 ++
> > 1 file changed, 6 insertions(+)
> >
Hi Jan,
On Fri, 2016-07-08 at 12:17 +0200, Jan Lübbe wrote:
> On Do, 2016-06-30 at 15:14 +0800, HS Liao wrote:
> [...]
> > +Required properties:
> > +- compatible: Must be "mediatek,mt8173-gce"
> > +- reg: Address range of the GCE unit
> > +- interrupts: The interrupt signal from the GCE block
>
Hi Jan,
On Fri, 2016-07-08 at 12:17 +0200, Jan Lübbe wrote:
> On Do, 2016-06-30 at 15:14 +0800, HS Liao wrote:
> [...]
> > +Required properties:
> > +- compatible: Must be "mediatek,mt8173-gce"
> > +- reg: Address range of the GCE unit
> > +- interrupts: The interrupt signal from the GCE block
>
1 - 100 of 466 matches
Mail list logo