On 16-10-16, 23:59, Masahiro Yamada wrote:
> + cluster0_opp: opp_table {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp@24500 {
> + opp-hz = /bits/ 64 <24500>;
> + clock-latency-ns = <300>;
On 10/18/2016 01:08 PM, Daniel Golle wrote:
> Hi Neil,
>
> great to see progress towards supporting OX820!
> The NAND driver I hacked up for Kernel 4.1 and 4.4 in OpenWrt/LEDE
> looks very similar, see
>
> https://git.lede-project.org/?p=lede/dangole/staging.git;a=blob;f=target/linux/oxnas/files/
Linus,
Please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
# HEAD: 0e60439c22ec551e9b5780eba73ddfeb63ab63d9 Merge branch 'mm/pkeys'
into x86/urgent, to pick up pkeys fix
Misc fixes, plus hw-enablement
Add support for programmable MAC impedance configuration
Signed-off-by: Mugunthan V N
---
drivers/net/phy/dp83867.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 91177a4..1b63924 100644
--- a/drivers/
The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.
Signed-off-by: Mugunthan V N
---
arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
1 file changed, 2 insertions(
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts
b/arch/arm/boot/dts
Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.
Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.
Add documention of ti,min-output-impedance and ti,max-output-impedance
which can be used to correct MAC impedance mismatch using phy extended
registers.
Signed-off-by: Mugunthan V N
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 12
1 file changed, 12 insertions(+)
diff
Linus,
Please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
# HEAD: 54e23845e965898f65f76aba79fa9db76d830fa9 alarmtimer: Remove unused
but set variable
Remove an unused variable.
Thanks,
Linus,
Please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
# HEAD: 9cfb38a7ba5a9c27c1af8093fb1af4b699c0a441 sched/fair: Fix sched
domains NULL dereference in select_idle_sibling()
Fix a crash that
Commit 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on
errata-affected core") adds code to execute cache maintenance instructions
in the kernel on behalf of userland on CPUs with certain ARM CPU errata.
It turns out that the address hasn't been checked to be a valid user
space add
On Fri, Oct 14, 2016 at 01:29:18PM -0500, Eric W. Biederman wrote:
>
> Adrei Vagin pointed out that time to executue propagate_umount can go
> non-linear (and take a ludicrious amount of time) when the mount
> propogation trees of the mounts to be unmunted by a lazy unmount
> overlap.
>
> Solve t
On 18/10/16 10:07, Peter Zijlstra wrote:
> On Mon, Oct 17, 2016 at 11:52:39PM +0100, Dietmar Eggemann wrote:
[...]
>> Using for_each_online_cpu(i) instead of for_each_possible_cpu(i) in
>> online_fair_sched_group() works on this machine, i.e. the .tg_load_avg
>> of system.slice tg is 0 after star
Call trace:
[] __switch_to+0x80/0x98
[] __schedule+0x314/0x854
[] schedule+0x48/0xa4
[] schedule_timeout+0x158/0x2c8
[] io_schedule_timeout+0xbc/0x14c
[] wait_iff_congested+0x1d4/0x1ec
[] shrink_inactive_list+0x530/0x760
[] shrink_lruvec+0x534/0x76c
[] shrink_zone+0x88/0x1b8
[] do_try_to_free_page
On Tue, Oct 18, 2016 at 11:29:37AM +0100, Matt Fleming wrote:
> On Tue, 11 Oct, at 11:24:53AM, Matt Fleming wrote:
> >
> > That's a lot more costly cross-DIE migrations. I think this patch is
> > along the right lines, but there's something fishy happening on this
> > box.
>
> I wasn't really abl
On Wed, Oct 12, 2016 at 09:41:36AM +0200, Vincent Guittot wrote:
> ok. In fact, I have noticed another regression with tip/sched/core and
> hackbench while looking at yours.
> I have bisect to :
> 10e2f1acd0 ("sched/core: Rewrite and improve select_idle_siblings")
>
> hackbench -P -g 1
>
>
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 0130669966bf337b616d559d5405614c0a4ae313 Merge tag
'perf-urgent-for-mingo-20161017' of
git://git.kernel.org/pub/scm/linux/kernel/git
Commit 63f53dea0c9866e9 ("mm: warn about allocations which stall for
too long") is a great step for reducing possibility of silent hang up
problem caused by memory allocation stalls. For example, below is a
report where write() request got stuck because it cannot invoke the
OOM killer due to GFP_NO
Am 18.10.2016 um 12:54 schrieb Jani Nikula :
> On Mon, 17 Oct 2016, Stephen Hemminger wrote:
>> From: Stephen Hemminger
>>
>> Update UIO documentation to include basic information about
>> uio_hv_generic.
>
> How about converting to Sphinx/reStructuredText first...? It's not a big
> file...
>
Linus,
Please pull the latest locking-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-for-linus
# HEAD: 5f43086bb9224987010460dcf3dee68fbd4f574d locking, fs/locks: Add
missing file_sem locks
Two fixes:
- a file locks fix (missin
On Mon, 17 Oct 2016, Stephen Hemminger wrote:
> From: Stephen Hemminger
>
> Update UIO documentation to include basic information about
> uio_hv_generic.
How about converting to Sphinx/reStructuredText first...? It's not a big
file...
BR,
Jani.
>
> Signed-off-by: Stephen Hemminger
> ---
>
On Mon, 17 Oct 2016, Luck, Tony wrote:
> On Tue, Oct 18, 2016 at 01:20:36AM +0200, Thomas Gleixner wrote:
> > It's certainly not perfect (missing L2 etc.), but clearly avoids exactly
> > the above issues. And it would allow you to utilize the 256 groups in an
> > understandable way.
>
> If you hea
On 21 September 2016 at 08:57, Yangbo Lu wrote:
> This patchset is used to fix a host version register bug in the
> T4240-R1.0-R2.0
> eSDHC controller. To match the SoC version and revision, 10 previous version
> patchsets had tried many methods but all of them were rejected by reviewers.
> Such
Hi Sinan,
On Wed, Jun 29, 2016 at 04:27:37AM -0400, Sinan Kaya wrote:
> Since commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> the penalty values are calculated on the fly rather than boot time.
>
> This works fine for PCI interrupts but not so well for the ISA interrupts.
> W
Hi Rafael,
On 2016-10-10 14:36, Rafael J. Wysocki wrote:
[...]
One more update after some conversations during LinuxCon Europe.
The main point was to make it possible for device_link_add() to figure out the
initial state of the link instead of expecting the caller to provide it which
might no
Em Tue, 18 Oct 2016 13:35:39 +0300
Jani Nikula escreveu:
> On Tue, 18 Oct 2016, Mauro Carvalho Chehab wrote:
> > Em Tue, 18 Oct 2016 13:01:01 +0300
> > Jani Nikula escreveu:
> >
> >> On Tue, 18 Oct 2016, Jonathan Corbet wrote:
> >> > So I raised this topic in talks at both Kernel Recipes a
On Tue, 18 Oct 2016 08:56:05 +0200
Christoph Hellwig wrote:
> Hi all,
>
> this is my spin at sorting out the long lock hold times in
> __purge_vmap_area_lazy. It is based on the patch from Joel sent this
> week. I don't have any good numbers for it, but it survived an
> xfstests run on XFS whi
On Tue, Oct 18, 2016 at 11:33:59AM +0100, Chris Wilson wrote:
> On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote:
> > This is how everyone seems to already use them, but let's make that
> > explicit.
>
> mm/page_alloc.c: alloc_large_system_hash() is perhaps the exception to
> the
On Tue, 18 Oct 2016, Mauro Carvalho Chehab wrote:
> Em Tue, 18 Oct 2016 13:01:01 +0300
> Jani Nikula escreveu:
>
>> On Tue, 18 Oct 2016, Jonathan Corbet wrote:
>> > So I raised this topic in talks at both Kernel Recipes and LinuxCon
>> > Europe, and nobody threw things at me. I have come to sus
On Mon, Oct 17, 2016 at 06:33:15PM +0100, Mark Rutland wrote:
> On Mon, Oct 17, 2016 at 03:48:13PM +0100, Mark Rutland wrote:
> > On Fri, Oct 14, 2016 at 11:42:25AM +0100, Mark Rutland wrote:
> > > When CONFIG_THREAD_INFO_IN_TASK is selected, the current_thread_info()
> > > macro relies on current
On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote:
> This is how everyone seems to already use them, but let's make that
> explicit.
mm/page_alloc.c: alloc_large_system_hash() is perhaps the exception to
the rule.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Oct 18, 2016 at 11:45:48AM +0200, Vincent Guittot wrote:
> On 18 October 2016 at 11:07, Peter Zijlstra wrote:
> > So aside from funny BIOSes, this should also show up when creating
> > cgroups when you have offlined a few CPUs, which is far more common I'd
> > think.
>
> The problem is al
On Tue, 11 Oct, at 11:24:53AM, Matt Fleming wrote:
>
> That's a lot more costly cross-DIE migrations. I think this patch is
> along the right lines, but there's something fishy happening on this
> box.
I wasn't really able to track down why this machine regressed, and the
patch shows enough impro
On 18 October 2016 at 11:47, Maxime Ripard
wrote:
> Hi,
>
> On Tue, Oct 18, 2016 at 11:03:02AM +0200, Ulf Hansson wrote:
>> On 18 October 2016 at 10:43, Maxime Ripard
>> wrote:
>> > mmc_regulator_get_supply might silently fail if the regulators are not
>> > found, which is the right thing to do s
On 18 October 2016 at 11:25, Takashi Iwai wrote:
> On Mon, 17 Oct 2016 18:23:59 +0200,
> Ard Biesheuvel wrote:
>>
>> Commit 49d9e77e72cf ("ALSA: hda - Fix system panic when DMA > 40 bits
>> for Nvidia audio controllers") simply disabled any DMA exceeding 32
>> bits for NVidia devices, even though
Commit-ID: 5f43086bb9224987010460dcf3dee68fbd4f574d
Gitweb: http://git.kernel.org/tip/5f43086bb9224987010460dcf3dee68fbd4f574d
Author: Peter Zijlstra
AuthorDate: Sat, 8 Oct 2016 10:12:28 +0200
Committer: Ingo Molnar
CommitDate: Tue, 18 Oct 2016 12:21:28 +0200
locking, fs/locks: Add mis
Commit-ID: 55a76b59b5fef408442e16121faa9eb00a65fd50
Gitweb: http://git.kernel.org/tip/55a76b59b5fef408442e16121faa9eb00a65fd50
Author: Josh Poimboeuf
AuthorDate: Thu, 13 Oct 2016 16:26:15 -0500
Committer: Ingo Molnar
CommitDate: Tue, 18 Oct 2016 12:21:16 +0200
locking/rwsem/x86: Add st
On Mon, 17 Oct 2016 18:23:59 +0200,
Ard Biesheuvel wrote:
>
> Commit 49d9e77e72cf ("ALSA: hda - Fix system panic when DMA > 40 bits
> for Nvidia audio controllers") simply disabled any DMA exceeding 32
> bits for NVidia devices, even though they are capable of performing
> DMA up to 40 bits. On so
On Tue, Oct 18, 2016 at 10:39:16AM +0100, Peter Griffin wrote:
> This patch enables the STi ALSA drivers found on STi platforms
> as well as the simple-card driver which is a dependency to have
> working sound.
>
> Signed-off-by: Peter Griffin
> Acked-by: Lee Jones
> Cc: arnaud.pouliq...@st.com
Em Tue, 18 Oct 2016 13:01:01 +0300
Jani Nikula escreveu:
> On Tue, 18 Oct 2016, Jonathan Corbet wrote:
> > So I raised this topic in talks at both Kernel Recipes and LinuxCon
> > Europe, and nobody threw things at me. I have come to suspect that I'm
> > worrying a little too much about it; mayb
On Tuesday, October 18, 2016 9:47:31 AM CEST Haggai Eran wrote:
> On 10/18/2016 1:05 AM, Arnd Bergmann wrote:
> > @@ -1309,7 +1311,7 @@ static bool validate_net_dev(struct net_device
> > *net_dev,
> > static struct net_device *cma_get_net_dev(struct ib_cm_event *ib_event,
> >
Hi Robert, Ard,
Sorry for the delay in getting to this; I've been travelling a lot
lately and in the meantime this managed to get buried in my inbox.
On Thu, Oct 06, 2016 at 06:11:14PM +0200, Robert Richter wrote:
> On 06.10.16 11:00:33, Ard Biesheuvel wrote:
> > On 6 October 2016 at 10:52, Rober
Linus,
Please pull the latest irq-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-for-linus
# HEAD: d102eb5c1ac5e6743b1c6d145c06a25d98ad1375 irqchip/gicv3: Handle loop
timeout proper
Three irqchip driver fixes.
Thanks,
Ingo
Provides runtime PM callbacks to enable and disable clock resources
when idle. Also support system PM callbacks to be called during system
suspend and resume.
Signed-off-by: Pramod Gurav
---
Tested on DB410C.
Changes in v4:
- Remove calls to sdhci_runtime_resume_host/sdhci_runtime_suspend_host
Linus,
Please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
# HEAD: a705e07b9c80df27b6bb12f7a4cd4cf4ed2f728b cpu/hotplug: Use distinct
name for cpu_hotplug.dep_map
A CPU hotplug debuggability fix and
On Tue, 11 Oct, at 11:39:57AM, Matt Fleming wrote:
> On Tue, 11 Oct, at 10:44:25AM, Dietmar Eggemann wrote:
> >
> > [...]
> >
> > Yeah, you're right. But I can't see any significant difference. IMHO,
> > it's all in the noise.
> >
> > (A) Performance counter stats for 'perf bench sched messaging
From: Zhao Lei
Currently, each container shared one copy of coredump setting
with the host system, if host system changed the setting, each
running containers will be affected.
Same story happened when container changed core_pattern, both
host and other container will be affected.
For container
This patchset includes following function points:
1: Let usermodehelper function possible to set pid namespace
done by: [PATCH v3.1 1/3] Make call_usermodehelper_exec possible
to set pid namespace.
2: Let pipe_type core_pattern write dump into container's rootfs
done by: [PATCH v3.1 2/3] L
On 10/18/2016 11:56 AM, Karel Zak wrote:
> On Mon, Oct 17, 2016 at 12:20:30PM +0200, Hannes Reinecke wrote:
>> The GPT specification requires that the alternate GPT is at the
>> end of the disk. However, if a Software RAID1 is enabled the RAID
>> metadata typically placed at the end of the disk, an
From: Zhao Lei
Currently when we set core_pattern to a pipe, the pipe program is
forked by kthread running with root's permission, and write dumpfile
into host's filesystem.
Same thing happened for container, the dumper and dumpfile are also
in host(not in container).
It have following program:
From: Zhao Lei
Current call_usermodehelper_exec() can not set pid namespace for
the executed program, because we need addition fork to make pid
namespace active.
This patch add above function for call_usermodehelper_exec().
When init_intermediate callback return -EAGAIN, the usermodehelper
will
On Tuesday, October 18, 2016 11:57:33 AM CEST Ilya Dryomov wrote:
> It already got silenced by initializing at declaration in one of the
> downstream trees, so I'd rather we do
>
> @@ -3756,7 +3819,7 @@ static void rbd_watch_cb(void *arg, u64
> notify_id, u64 cookie,
> struct rbd_device *r
Hi Russell,
On Tue, Oct 18, 2016 at 10:24:22AM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 18, 2016 at 10:29:33AM +0200, Maxime Ripard wrote:
> > The Allwinner display engine doesn't have any kind of hardware help to deal
> > with TV overscan.
>
> I'm not sure I follow. My understanding
Add cpu feature for ring 3 monitor/mwait.
Set HWCAP2 1st bit during init.
Signed-off-by: Grzegorz Andrejczuk
---
arch/x86/include/asm/cpufeatures.h | 2 ++
arch/x86/kernel/cpu/intel.c| 4
2 files changed, 6 insertions(+)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/i
Add HWCAP2 for x86 and reserve its 1st bit to expose
Xeon Phi ring 3 monitor/mwait to userspace apps.
Signed-off-by: Grzegorz Andrejczuk
---
arch/x86/include/asm/elf.h | 9 +
arch/x86/include/uapi/asm/hwcap2.h | 7 +++
arch/x86/kernel/cpu/common.c | 3 +++
3 files chang
If processor is Intel Xeon Phi we enable user-level mwait feature.
Enabling this feature suppreses invalid-opcode error, when MONITOR/MWAIT
is called from ring 3.
Signed-off-by: Grzegorz Andrejczuk
---
Documentation/kernel-parameters.txt | 5 +
arch/x86/kernel/cpu/intel.c | 35 +
Intel Xeon Phi x200 (codenamed Knights Landing) has MSR
MISC_THD_FEATURE_ENABLE 0x140.
Setting 2nd bit of this register makes MONITOR and MWAIT instructions
do not cause invalid-opcode exception when called from ring different
than 0.
Hex Dec NameScope
140H 320 MISC_THD_F
These patches enable Intel Xeon Phi x200 feature to use MONITOR/MWAIT
instruction in ring 3 (userspace) Patches set MSR 0x140 for all logical CPUs.
Then expose it as CPU feature and introduces elf HWCAP capability for x86.
Reference (the solution is temporary MSR definition will be in next SDM
doc
On Tue, 18 Oct 2016, Jonathan Corbet wrote:
> So I raised this topic in talks at both Kernel Recipes and LinuxCon
> Europe, and nobody threw things at me. I have come to suspect that I'm
> worrying a little too much about it; maybe we should go ahead and move
> the documents and see who screams.
On Tue, Oct 18, 2016 at 03:12:45PM +0800, zhouxianr...@huawei.com wrote:
> From: z00281421
>
> bdi flusher may enter page alloc slow path due to writepage and kmalloc.
> in that case the flusher as a direct reclaimer should not be throttled here
> because it can not to reclaim clean file pages o
On Tue, Oct 18, 2016 at 12:10 AM, Arnd Bergmann wrote:
> When building with gcc-4.9 -Wmaybe-uninitialized, we get a bogus
> warning in rbd_watch_cb, as the variable is not used at all
> in the one case in which it is not initialized first:
>
> drivers/block/rbd.c: In function ‘rbd_watch_cb’:
> dri
On Mon, Oct 17, 2016 at 12:20:30PM +0200, Hannes Reinecke wrote:
> The GPT specification requires that the alternate GPT is at the
> end of the disk. However, if a Software RAID1 is enabled the RAID
> metadata typically placed at the end of the disk, and the actual
> size of the disk is decreased b
Since:
commit 6556bdacf646fcaa0586123ba85412de1c8f0eee
Author: Marcin Niestroj
Date: Fri Sep 9 10:42:02 2016 +0200
mfd: tps65217: Add support for IRQs
I get an build failure on pcc64le for allmodconfig:
ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
scripts/Makefile.mo
On 14/10/16 19:41, Douglas Anderson wrote:
We've got a delay loop waiting for secondary CPUs. That loop uses
loops_per_jiffy. However, loops_per_jiffy doesn't actually mean how
many tight loops make up a jiffy on all architectures. It is quite
common to see things like this in the boot log:
Hi,
On Tue, Oct 18, 2016 at 11:03:02AM +0200, Ulf Hansson wrote:
> On 18 October 2016 at 10:43, Maxime Ripard
> wrote:
> > mmc_regulator_get_supply might silently fail if the regulators are not
> > found, which is the right thing to do since both these regulators are
> > optional.
> >
> > However
On 18 October 2016 at 11:07, Peter Zijlstra wrote:
> On Mon, Oct 17, 2016 at 11:52:39PM +0100, Dietmar Eggemann wrote:
>>
>> Something looks weird related to the use of for_each_possible_cpu(i) in
>> online_fair_sched_group() on my i5-3320M CPU (4 logical cpus).
>>
>> In case I print out cpu id an
Acked-by: CK Hu
On Tue, 2016-10-18 at 16:23 +0800, Bibby Hsieh wrote:
> If we want to set the hardware OD to relay mode,
> we have to set OD_CFG register rather than
> OD_RELAYMODE; otherwise, the system will access
> the wrong address.
>
> Fixes: 7216436420414144646f5d8343d061355fd23483 ("drm/m
On 10/13/2016 02:59 PM, Michal Hocko wrote:
From: Michal Hocko
__GFP_THISNODE is documented to enforce the allocation to be satisified
from the requested node with no fallbacks or placement policy
enforcements. policy_zonelist seemingly breaks this semantic if the
current policy is MPOL_MBIND a
This patch enables the STi ALSA drivers found on STi platforms
as well as the simple-card driver which is a dependency to have
working sound.
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
Cc: arnaud.pouliq...@st.com
Cc: broo...@kernel.org
---
arch/arm/configs/multi_v7_defconfig | 3 +++
1 fi
Hi,
On 17/10/16 10:25, Peter Zijlstra wrote:
> On Mon, Oct 17, 2016 at 08:38:57AM +0200, luca abeni wrote:
>
> > > Yes, there currently is no existing schedulability analysis for
> > > multi-processor EDF with random affinities (as far as I know)
> > Correction: it looks like I was wrong, and the
Make REMOTEPROC core a selectable kconfig option, and update
remoteproc client drivers to 'depends on' the core. This avoids
some nasty Kconfig recursive dependency issues. Also when using
menuconfig client drivers will be hidden until the core has been
enabled.
Documentation/kbuild/kconfig-langua
This patch adds the slim core rproc driver to the STi section
of the MAINTAINERS file.
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7..78b7f8b 100644
--- a/MAINTAINERS
+++ b/MAINTAINE
This patch adds the DT binding documentation for the FDMA constroller
found on STi based chipsets from STMicroelectronics.
Signed-off-by: Ludovic Barre
Signed-off-by: Peter Griffin
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/dma/st_fdma.txt | 87 +++
1 file
This patch adds support for the Flexible Direct Memory Access (FDMA) core
driver. The FDMA is a slim core CPU with a dedicated firmware.
It is a general purpose DMA controller capable of supporting 16
independent DMA channels. Data moves maybe from memory to memory
or between memory and paced laten
On Tue, Oct 18, 2016 at 12:13:37AM +0200, Arnd Bergmann wrote:
> The newly introduced soc_pcmcia_regulator_set() function sometimes returns
> without setting its return code, as shown by this warning:
>
> drivers/pcmcia/soc_common.c: In function 'soc_pcmcia_regulator_set':
> drivers/pcmcia/soc_com
Now that remoteproc core is selectable it needs to be enabled
in the multi_v7 build.
Signed-off-by: Peter Griffin
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 437d074..
This header file will also be used by the dma xbar driver in the
future.
Signed-off-by: Ludovic Barre
Signed-off-by: Peter Griffin
---
drivers/dma/st_fdma.h | 249 ++
1 file changed, 249 insertions(+)
create mode 100644 drivers/dma/st_fdma.h
dif
The st231 remote coprocessors are found on all STi chipsets.
Signed-off-by: Peter Griffin
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 538c326..0a06af9 100644
--- a/arc
This DMA controller is found on all STi chipsets.
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_v7_defconfig
index 0a06af9..ce9ab5a 100644
This patch adds the FDMA driver files to the STi
section of the maintainers file.
Signed-off-by: Peter Griffin
Acked-by: Lee Jones
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 78b7f8b..e93762d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -
slim core is used as a basis for many IPs in the STi
chipsets such as fdma and demux. To avoid duplicating
the elf loading code in each device driver a slim
rproc driver has been created.
This driver is designed to be used by other device drivers
such as fdma, or demux whose IP is based around a s
Hi Vinod and Bjorn,
This patchset adds support for the Flexible Direct Memory Access (FDMA) core
found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU
with a dedicated firmware. It is a general purpose DMA controller supporting
16 independent channels and data can be moved fro
> @@ -1908,7 +1908,7 @@ void wb_workfn(struct work_struct *work)
> long pages_written;
>
> set_worker_desc("flush-%s", dev_name(wb->bdi->dev));
> - current->flags |= PF_SWAPWRITE;
If flags carries PF_LESS_THROTTLE before modified, then you
have to restore it.
> + current->f
On 16 October 2016 at 17:56, Vegard Nossum wrote:
> We need an explicit dependency on FAULT_INJECTION in order to keep
> FAIL_MMC_REQUEST (and subsequent entries) inside the FAULT_INJECTION
> menu.
>
> Fixes: 28ff4fda9e5b ("mmc: kconfig: replace FAULT_INJECTION with
> FAULT_INJECTION_DEBUG_FS")
>
On Mon, Oct 17, 2016 at 06:56:13PM -0700, Stephen Boyd wrote:
> The state of USB ChipIdea support on Qualcomm's platforms is not great.
> The DT description of these devices requires up to three different nodes
> for what amounts to be the same hardware block, when there should really
> only be one
Commit-ID: 1c7df9c183278052aedc3dcb9fecb8bf2b24a659
Gitweb: http://git.kernel.org/tip/1c7df9c183278052aedc3dcb9fecb8bf2b24a659
Author: Peter Zijlstra
AuthorDate: Sat, 8 Oct 2016 10:12:28 +0200
Committer: Ingo Molnar
CommitDate: Tue, 18 Oct 2016 11:19:05 +0200
locking, fs/locks: Add mis
On Mon 17-10-16 22:15:29, Christoph Hellwig wrote:
> Thanks Arnd, this looks fine to me:
>
> Reviewed-by: Christoph Hellwig
Thanks! I have pulled the patch into my tree and will push it to Linus.
Honza
--
Jan Kara
SUSE Labs, CR
On Tue, Oct 18, 2016 at 3:38 AM, Ming Lei wrote:
> On Tue, Oct 18, 2016 at 12:04 AM, Sedat Dilek wrote:
>> Hi Linus,
>>
>> not sure whom to address on this issue.
>>
>> I have built Linux v4.9-rc1, v4.8.2 and v4.4.25 kernels (in this
>> order) this morning.
>>
>> Building a Linux v4.8.2 under Lin
2016-10-18 17:24 GMT+08:00 Ingo Molnar :
>
> * Wanpeng Li wrote:
>
>> ===
>> [ INFO: suspicious RCU usage. ]
>> 4.8.0+ #24 Not tainted
>> ---
>> ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check()
>> usage!
>>
>> o
On Mon, Oct 17, 2016 at 6:46 PM, Linus Torvalds
wrote:
> On Mon, Oct 17, 2016 at 9:04 AM, Sedat Dilek wrote:
>>
>> not sure whom to address on this issue.
>>
>> I have built Linux v4.9-rc1, v4.8.2 and v4.4.25 kernels (in this
>> order) this morning.
>>
>> Building a Linux v4.8.2 under Linux v4.9-
On Tue, Oct 18, 2016 at 10:29:33AM +0200, Maxime Ripard wrote:
> The Allwinner display engine doesn't have any kind of hardware help to deal
> with TV overscan.
I'm not sure I follow. My understanding (from reading the CEA specs)
is that TVs are expected to overscan the image, so the upper left,
* Wanpeng Li wrote:
> ===
> [ INFO: suspicious RCU usage. ]
> 4.8.0+ #24 Not tainted
> ---
> ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check()
> usage!
>
> other info that might help us debug this:
>
> RCU u
Hi
On 09/14/2016 03:27 PM, Peter Griffin wrote:
> This IP is only found on STiH415/6 silicon and support
> for these SoCs is being removed from the kernel.
>
> Signed-off-by: Peter Griffin
> Cc:
Acked-by: Patrice Chotard
Applied on STi-defconfig-for-4.10 branch
Thanks
> ---
> arch/arm/con
Am Sonntag, 16. Oktober 2016, 21:49:43 schrieb Paul Kocialkowski:
> Hi,
>
> Le mardi 27 septembre 2016 à 13:53 -0700, Vagrant Cascadian a écrit :
> > This essentially mimics what was done with rk3288-veyron-minnie in
> > commit 984926781122f034d5bc9962815d135b6c4a8e1d.
> >
> > The eMMC of the spe
On Monday, 17 October 2016 19:39:57 BST Andreas Schwab wrote:
> On Okt 17 2016, Paul Burton wrote:
> > Could you share the device tree from your system?
>
> This is the contents of chosen/linux,stdout-path on the systems I have:
>
> chosen/linux,stdout-path
> "/pci@f000/ATY,
On 10/18/2016 1:05 AM, Arnd Bergmann wrote:
> @@ -1309,7 +1311,7 @@ static bool validate_net_dev(struct net_device *net_dev,
> static struct net_device *cma_get_net_dev(struct ib_cm_event *ib_event,
> const struct cma_req_info *req)
> {
> - struct socka
If a device tree specified a preferred device for kernel console output
via the stdout-path or linux,stdout-path chosen node properties there's
no guarantee that it will have specified a device for which we have a
driver. It may also be the case that we do have a driver but it doesn't
call of_conso
On Tuesday 18 October 2016 02:15 PM, Patrice Chotard wrote:
>
>
> On 10/18/2016 09:47 AM, Patrice Chotard wrote:
>> Hi
>>
>> On 09/23/2016 05:06 PM, Rob Herring wrote:
>>> On Wed, Sep 14, 2016 at 02:27:39PM +0100, Peter Griffin wrote:
This phy is only used on STiH415/6 based silicon, and s
Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
This is a simple memory mapped NAND controller with single chip select and
software ECC.
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/mtd/oxnas-nand.txt | 24
drivers/mtd/nand/Kconfig
On Mon, Oct 17, 2016 at 11:52:39PM +0100, Dietmar Eggemann wrote:
>
> Something looks weird related to the use of for_each_possible_cpu(i) in
> online_fair_sched_group() on my i5-3320M CPU (4 logical cpus).
>
> In case I print out cpu id and the cpu masks inside the
> for_each_possible_cpu(i)
>
701 - 800 of 883 matches
Mail list logo
