On Wed, Jul 29, 2020 at 11:12 AM Ankit Baluni
wrote:
>
> Added a missing comma and changed 'it it useful' to 'it is useful'.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Ankit Baluni
> ---
> Changes in -v2:
> -Remove space before ':' in subject line.
>
>
On 07/28/20 at 04:07pm, David Hildenbrand wrote:
> On 28.07.20 15:48, Baoquan He wrote:
> > On 06/30/20 at 04:26pm, David Hildenbrand wrote:
> >> Let's move the split comment regarding bootmem allocations and memory
> >> holes, especially in the context of ZONE_MOVABLE, to the PageReserved()
> >>
From: Ioana-Ruxandra Stăncioi
Include in uapi/linux/seg6_iptunnel.h to fix the
following linux/seg6_iptunnel.h compilation error:
invalid application of 'sizeof' to incomplete type 'struct ipv6hdr'
head = sizeof(struct ipv6hdr);
^~
This is to allow including
On 28-07-20, 17:37, Alex Elder wrote:
> On 7/27/20 1:32 PM, Gustavo A. R. Silva wrote:
> > Replace the existing /* fall through */ comments and its variants with
> > the new pseudo-keyword macro fallthrough[1].
> >
> > [1]
> >
This patch series adds support for AMD Fam17h RAPL counters. As per
AMD PPR, Fam17h support RAPL counters to monitor power usage. The RAPL
counter operates as with Intel RAPL. Therefore, it is beneficial to
re-use existing framework for Intel, especially to allow existing tools
to seamlessly run
On Wed, Jul 29, 2020 at 4:44 PM Weiyi Lu wrote:
>
> The en_mask actually is a combination of divider enable mask
> and pll enable bit(bit0).
> Before this patch, we enabled both divider mask and bit0 in prepare(),
> but only cleared the bit0 in unprepare().
> Now, setting the enable
MSRs in the rest of this file are sorted by their addresses; fixing the
two outliers.
No functional changes.
Signed-off-by: Victor Ding
---
arch/x86/include/asm/msr-index.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/msr-index.h
This patch changes the static struct rapl_msr_priv to a pointer to allow
using a different set of of RAPL MSR interface, preparing for supporting
AMD's RAPL MSR interface.
No functional changes.
Signed-off-by: Victor Ding
---
drivers/powercap/intel_rapl_msr.c | 33
This patch enables AMD Fam17h RAPL support for the power capping
framework. The support is as per AMD Fam17h Model31h (Zen2) and
model 00-ffh (Zen1) PPR.
Tested by comparing the results of following two sysfs entries and the
values directly read from corresponding MSRs via /dev/cpu/[x]/msr:
Hi Stanley,
On 2020-07-29 18:26, Stanley Chu wrote:
Hi Can,
On Wed, 2020-07-29 at 16:43 +0800, Can Guo wrote:
Hi Stanley,
On 2020-07-29 10:40, Stanley Chu wrote:
> In ufshcd_suspend(), after clk-gating is suspended and link is set
> as Hibern8 state, ufshcd_hold() is still possibly invoked
The following commit has been merged into the sched/fifo branch of tip:
Commit-ID: 4fd5750af02ab7bba7c58a073060cc1da8a69173
Gitweb:
https://git.kernel.org/tip/4fd5750af02ab7bba7c58a073060cc1da8a69173
Author:Peter Zijlstra
AuthorDate:Mon, 20 Jul 2020 23:49:18 +02:00
Signed-off-by: Jack Mitchell
---
drivers/power/supply/axp20x_battery.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/power/supply/axp20x_battery.c
b/drivers/power/supply/axp20x_battery.c
index fe96f77bffa7..8ce4ebe7ccd5 100644
---
On Wed, Jul 29, 2020 at 01:19:50PM +0530, Ankit Baluni wrote:
> Removed braces for a 'if' condition as it contain only single line &
> there is no need for braces for such case according to coding style
> rules.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Ankit Baluni
>
> ---
> Changes in
On Wed, Jul 29, 2020 at 4:44 PM Weiyi Lu wrote:
>
> In all MediaTek PLL design, bit0 of CON0 register is always
> the enable bit.
> However, there's a special case of usbpll on MT8192.
> The enable bit of usbpll is moved to bit2 of other register.
> Add configurable en_reg and pll_en_bit for
This patch adds the bindings for the Programmable Real-Time Unit
and Industrial Communication Subsystem (PRU-ICSS) present on various
TI SoCs. The IP is present on multiple TI SoC architecture families
including the OMAP architecture SoCs such as AM33xx, AM437x and
AM57xx; and on a Keystone 2
From: Suman Anna
The AM437x SoCs have two different PRU-ICSS subsystems: PRU-ICSS1
and a smaller PRU-ICSS0. Enhance the PRUSS platform driver to support
both the PRU-ICSS sub-systems on these SoCs.
The PRU-ICSS1 on AM437x is very similar to the PRU-ICSS on AM33xx
except for few minor
Hi,
The Programmable Real-Time Unit and Industrial Communication Subsystem
(PRU-ICSS) is present on various TI SoCs. The IP is present on multiple TI SoC
architecture families including the OMAP architecture SoCs such as AM33xx,
AM437x and AM57xx; and on a Keystone 2 architecture based 66AK2G
On Wed, Jul 29, 2020 at 6:51 PM Nicolas Boichat wrote:
>
> On Wed, Jul 29, 2020 at 4:44 PM Weiyi Lu wrote:
> >
> > The en_mask actually is a combination of divider enable mask
> > and pll enable bit(bit0).
> > Before this patch, we enabled both divider mask and bit0 in prepare(),
> > but only
From: Suman Anna
The 66AK2G SoC supports two PRU-ICSS instances, named PRUSS0 and PRUSS1,
each of which has two PRU processor cores. The two PRU-ICSS instances
are identical to each other with few minor SoC integration differences,
and are very similar to the PRU-ICSS1 of AM57xx/AM43xx. The
From: Suman Anna
The AM57xx family of SoCs supports two PRU-ICSS instances, each of
which has two PRU processor cores. The two PRU-ICSS instances are
identical to each other, and are very similar to the PRU-ICSS1 of
AM33xx/AM43xx except for a few minor differences like the RAM sizes
and the
From: Suman Anna
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS
processor subsystem capable of supporting Gigabit Ethernet, and is
commonly referred to as ICSSG. These SoCs contain typically three
ICSSG instances named ICSSG0, ICSSG1 and ICSSG2. The three ICSSGs are
From: Suman Anna
The Programmable Real-Time Unit - Industrial Communication
Subsystem (PRU-ICSS) is present on various TI SoCs such as
AM335x or AM437x or the Keystone 66AK2G. Each SoC can have
one or more PRUSS instances that may or may not be identical.
For example, AM335x SoCs have a single
Hi all,
After merging the printk tree, today's linux-next build (powerpc
allyesconfig) failed like this:
In file included from include/linux/printk.h:10,
from include/linux/kernel.h:15,
from include/asm-generic/bug.h:20,
from
mei driver has sub modules, those are not
listed via scripts/get_maintainer.pl when using asterisk:
drivers/misc/mei/*
The correct notation is:
drivers/misc/mei/
Cc: Joe Perches
Cc: Gustavo A. R. Silva
Signed-off-by: Tomas Winkler
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1
Use constraint to enforce the period sizes which are validated in
Android BSP.
Signed-off-by: Brent Lu
---
sound/soc/intel/atom/sst-mfld-platform-pcm.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c
From: Yu-Hsuan Hsu
The CRAS server does not set the period size in hw_param so ALSA will
calculate a value for period size which is based on the buffer size
and other parameters. The value may not always be aligned with Atom's
dsp design so a constraint is added to make sure the board always has
Two different constraints are implemented: one is in platform's CPU
DAI to enforce period sizes which are already used in Android BSP. The
other is in Atom Chromebook's machine driver to use 240 as period size.
Brent Lu (1):
ASoC: intel: atom: Add period size constraint
Yu-Hsuan Hsu (1):
Em Wed, Jul 29, 2020 at 01:47:01AM +0530, kajoljain escreveu:
>
>
> On 7/28/20 10:56 PM, Ian Rogers wrote:
> > On Tue, Jul 28, 2020 at 5:36 AM Arnaldo Carvalho de Melo
> > wrote:
> >>
> >> Em Sun, Jul 19, 2020 at 08:13:17PM +0200, Jiri Olsa escreveu:
> >>> So far compute_single function relies
To improve the general usefulness of the IRQ state trace events with
KCSAN enabled, save and restore the trace information when entering and
exiting the KCSAN runtime as well as when generating a KCSAN report.
Without this, reporting the IRQ trace events (whether via a KCSAN report
or outside of
Refactor the IRQ trace events fields, used for printing information
about the IRQ trace events, into a separate struct 'irqtrace_events'.
This improves readability by separating the information only used in
reporting, as well as enables (simplified) storing/restoring of
irqtrace_events snapshots.
On Tue, Jul 28, 2020 at 11:56:38AM +0100, David Howells wrote:
> Peter Zijlstra wrote:
>
> > > Please do not _undo_ the changes; just add the API you need.
> >
> > add_return and sub_return are horrible interface for refcount, which is
> > the problem.
> >
> > If you meant: refcount_dec(), but
On 29. 07. 20, 10:19, 张云海 wrote:
> On 2020/7/29 16:11, Jiri Slaby wrote:
>> But the loop checks for the overflow:
>> if (vgacon_scrollback_cur->tail >= vgacon_scrollback_cur->size)
>> vgacon_scrollback_cur->tail = 0;
>>
>> So the first 2 iterations would write to the end of the buffer
On Wed, Jul 29, 2020 at 07:03:04PM +0800, Brent Lu wrote:
> Use constraint to enforce the period sizes which are validated in
> Android BSP.
>
> Signed-off-by: Brent Lu
> ---
> sound/soc/intel/atom/sst-mfld-platform-pcm.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git
On Wed, Jul 29, 2020 at 07:03:03PM +0800, Brent Lu wrote:
> Two different constraints are implemented: one is in platform's CPU
> DAI to enforce period sizes which are already used in Android BSP. The
> other is in Atom Chromebook's machine driver to use 240 as period size.
One nit to one patch.
> -Original Message-
> From: Christoph Hellwig [mailto:h...@lst.de]
> Sent: Wednesday, July 29, 2020 12:23 AM
> To: Song Bao Hua (Barry Song)
> Cc: Christoph Hellwig ; m.szyprow...@samsung.com;
> robin.mur...@arm.com; w...@kernel.org; ganapatrao.kulka...@cavium.com;
>
Hi all,
After merging the net-next tree, today's linux-next build (i386 defconfig)
failed like this:
x86_64-linux-gnu-ld: net/core/fib_rules.o: in function `fib_rules_lookup':
fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match'
x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8):
High order memory stuff within trace could introduce OOM, use kvmalloc instead.
traced_probes invoked oom-killer:
gfp_mask=0x140c0c0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),
order=2, oom_score_adj=-1
traced_probes cpuset=system-background mems_allowed=0
CPU: 3 PID: 588 Comm:
The kernel test robot points out two harmless warnings in the
mmp clk drivers:
drivers/clk/mmp/clk-pxa168.c:68:13: warning: no previous prototype for
'pxa168_clk_init' [-Wmissing-prototypes]
drivers/clk/mmp/clk-pxa910.c:66:13: warning: no previous prototype for
'pxa910_clk_init'
da29e4810dea298
> commit: f962396ce29244d9a64f241481fa73fa370404c3 ARM: davinci: support
> multiplatform build for ARM v5
> date: 11 months ago
> config: arm-randconfig-r012-20200729 (attached as .config)
> compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget
On Wed, Jul 29, 2020 at 01:11:20PM +0200, pet...@infradead.org wrote:
> Subject: locking/refcount: Provide __refcount API to obtain the old value
> From: Peter Zijlstra
> Date: Wed Jul 29 13:00:57 CEST 2020
>
> David requested means to obtain the old/previous value from the
> refcount API for
`uref->usage_index` is not always being properly checked, causing
hiddev_ioctl_usage() to go out of bounds under some cases. Fix it.
Reported-by: syzbot+34ee1b45d88571c2f...@syzkaller.appspotmail.com
Link:
https://syzkaller.appspot.com/bug?id=f2aebe90b8c56806b050a20b36f51ed6acabe802
Reviewed-by:
Sorry! There was a gateway issue on my system while posting v5, due to
which some patches did not make it through. Resending...
This patch series enables kdump support for kexec_file_load system
call (kexec -s -p) on PPC64. The changes are inspired from kexec-tools
code but heavily modified for
Some architectures may have special memory regions, within the given
memory range, which can't be used for the buffer in a kexec segment.
Implement weak arch_kexec_locate_mem_hole() definition which arch code
may override, to take care of special regions, while trying to locate
a memory hole.
In kexec case, the kernel to be loaded uses the same memory layout as
the running kernel. So, passing on the DT of the running kernel would
be good enough.
But in case of kdump, different memory ranges are needed to manage
loading the kdump kernel, booting into it and exporting the elfcore
of the
Some of the kexec_file_load code isn't PPC64 specific. Move PPC64
specific code from kexec/file_load.c to kexec/file_load_64.c. Also,
rename purgatory/trampoline.S to purgatory/trampoline_64.S in the
same spirit. No functional changes.
Signed-off-by: Hari Bathini
Tested-by: Pingfan Liu
Currently, numa & prom are the users of drmem lmb walk code. Loading
kdump with kexec_file also needs to walk the drmem LMBs to setup the
usable memory ranges for kdump kernel. But there are couple of issues
in using the code as is. One, walk_drmem_lmb() code is built into the
.init section
crashkernel region could have an overlap with special memory regions
like opal, rtas, tce-table & such. These regions are referred to as
exclude memory ranges. Setup this ranges during image probe in order
to avoid them while finding the buffer for different kdump segments.
Override
From: Prarit Bhargava
printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
timestamp to printk messages. The local hardware clock loses time each
day making it difficult to determine exactly when an issue has occurred in
the kernel log, and making it difficult to determine
On Tue, Jul 28, 2020 at 08:11:43AM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Instead of traversing memblock.memory regions to find memory_start and
> memory_end, simply query memblock_{start,end}_of_DRAM().
>
> Signed-off-by: Mike Rapoport
> ---
> arch/h8300/kernel/setup.c| 8
Though kdump kernel boots from loaded address, the first 64KB of it is
copied down to real 0. So, setup a backup region and let purgatory
copy the first 64KB of crashed kernel into this backup region before
booting into kdump kernel. Update reserve map with backup region and
crashed kernel's
Kdump kernel, used for capturing the kernel core image, is supposed
to use only specific memory regions to avoid corrupting the image to
be captured. The regions are crashkernel range - the memory reserved
explicitly for kdump kernel, memory used for the tce-table, the OPAL
region and RTAS region
Prepare elf headers for the crashing kernel's core file using
crash_prepare_elf64_headers() and pass on this info to kdump
kernel by updating its command line with elfcorehdr parameter.
Also, add elfcorehdr location to reserve map to avoid it from
being stomped on while booting.
Signed-off-by:
The kexec purgatory has to run in real mode. Only the first memory
block maybe accessible in real mode. And, unlike the case with panic
kernel, no memory is set aside for regular kexec load. Another thing
to note is, the memory for crashkernel is reserved at an offset of
128MB. So, when
While initrd, elfcorehdr and backup regions are already added to the
reserve map, there are a few missing regions that need to be added to
the memory reserve map. Add them here. And now that all the changes
to load panic kernel are in place, claim likewise.
Signed-off-by: Hari Bathini
Tested-by:
Kernel built with CONFIG_PPC_EARLY_DEBUG_OPAL enabled expects r8 & r9
to be filled with OPAL base & entry addresses respectively. Setting
these registers allows the kernel to perform OPAL calls before the
device tree is parsed.
Signed-off-by: Hari Bathini
Reviewed-by: Thiago Jung Bauermann
---
From: Prarit Bhargava
printk.time=1/CONFIG_PRINTK_TIME=1 adds a unmodified local hardware clock
timestamp to printk messages. The local hardware clock loses time each
day making it difficult to determine exactly when an issue has occurred in
the kernel log, and making it difficult to determine
On Tue, Jul 28, 2020 at 01:33:55PM +1000, Nicholas Piggin wrote:
> Cc: Jonas Bonn
> Cc: Stefan Kristiansson
> Cc: Stafford Horne
> Cc: openr...@lists.librecores.org
> Signed-off-by: Nicholas Piggin
> ---
> arch/openrisc/include/asm/mmu_context.h | 8 +++-
> arch/openrisc/mm/tlb.c
On Wed, Jul 29, 2020 at 09:03:11PM +1000, Stephen Rothwell wrote:
>
> After merging the printk tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
Hi Stephen:
This loop was introduced recently by the powerpc tree with
High order memory stuff within trace could introduce OOM, use kvmalloc instead.
Please find the bellowing for the call stack we run across in an android
system. The scenario happens when traced_probes is woken up to get a large
quantity of trace even if free memory is even higher than
On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote:
> This mail needs to be saent to sta...@vger.kernel.org (now cc'd).
>
> Greg et al: please backport 2df3bae9a6543e90042291707b8db0cbfbae9ee9
Now backported, thanks.
greg k-h
raw_cmd_copyout() is potentially copying uninitialized kernel stack memory
since it is initializing `cmd` by assignment, which may cause the compiler
to leave uninitialized holes in this structure. Fix it by using memcpy()
instead.
Cc: sta...@vger.kernel.org
Suggested-by: Dan Carpenter
* Tony Lindgren [200728 08:23]:
> * H. Nikolaus Schaller [200727 20:51]:
> > Hi Tony,
> > after trying v5.8-rc7 the Pyra boot hangs after ca. 3 seconds
> > (a little random what the last log line is).
> >
> > I could bisect it to:
> >
> > 6cfcd5563b4fadbf49ba8fa481978e5e86d30322 is the first
On Wed, Jul 29, 2020 at 01:51:19PM +0200, Greg KH wrote:
> On Mon, Jul 27, 2020 at 11:00:14AM -0400, Mike Snitzer wrote:
> > This mail needs to be saent to sta...@vger.kernel.org (now cc'd).
> >
> > Greg et al: please backport 2df3bae9a6543e90042291707b8db0cbfbae9ee9
>
> Now backported, thanks.
On Thu, Jul 23, 2020 at 9:20 PM Rob Herring wrote:
>
> On Thu, Jul 23, 2020 at 02:32:07PM +0530, Jagan Teki wrote:
> > ROCKPi 4 has 3 variants of hardware platforms called
> > ROCKPi 4A, 4B, and 4C.
> >
> > - ROCKPi 4A has no Wif/BT.
> > - ROCKPi 4B has AP6256 Wifi/BT, PoE.
> > - ROCKPi 4C has
Hi Chen,
On Wed, Jul 29, 2020 at 11:52:39AM +0800, chenzhou wrote:
> On 2020/7/28 1:30, Catalin Marinas wrote:
> > Anyway, there are two series solving slightly different issues with
> > kdump reservations:
> >
> > 1. This series which relaxes the crashkernel= allocation to go anywhere
> >in
This adds touchscreen capabilities to the Lumia 950.
Signed-off-by: Konrad Dybcio
---
.../dts/qcom/msm8992-msft-lumia-talkman.dts | 28 +++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8992-msft-lumia-talkman.dts
This will be required to support touchscreen on Lumia
devices.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/msm8992.dtsi | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8992.dtsi
b/arch/arm64/boot/dts/qcom/msm8992.dtsi
This is a very basic dwc3 configuration (no PHYs yet),
but it works.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/msm8994.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994.dtsi
This is a very basic dwc3 configuration (no PHYs yet),
but it works.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/msm8992.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8992.dtsi
This is required for the platforms to function after the recent
driver cleanup and also is the current coding style.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/msm8992.dtsi | 2 ++
arch/arm64/boot/dts/qcom/msm8994.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git
All Kitakami devices seem to use the Synaptics RMI4
touchscreen attached to the same i2c bus. Configure and
enable it.
Signed-off-by: Konrad Dybcio
---
.../qcom/msm8994-sony-xperia-kitakami.dtsi| 45 ++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git
This series brings support for:
* sdhci2 on 8992/4
* BLSP_I2C1 (a seemingly WP-exclusive i2c bus) for 8992
* Synaptics RMI4 touchscreen for Sony Kitakami and MSFT L950
* DWC3 USB for msm8992/4 (doesn't work on Lumias, they use custom
circuitry)
* Missing clocks for 8994 GCC needed for USB
And
Add SDHCI2 to enable use of uSD cards on msm8994.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/msm8994.dtsi | 58 +++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994.dtsi
b/arch/arm64/boot/dts/qcom/msm8994.dtsi
index
This enables the use of uSD cards.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami.dtsi
This will let us use SD cards on our devices.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/msm8992.dtsi | 58 +++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8992.dtsi
b/arch/arm64/boot/dts/qcom/msm8992.dtsi
index
This change adds GDSCs, resets and most of the missing
clocks to the msm8994 GCC driver. The remaining ones
are of local_vote_clk and gate_clk type, which are not
yet supported upstream. Also reorder them to match the
original downstream driver.
Clocks have been switched from using parent_names
On Wed, 29 Jul 2020 09:50:21 +1000
Alexey Kardashevskiy wrote:
>
>
> On 29/07/2020 03:42, Greg Kurz wrote:
> > Hi Alexey,
> >
> > Working on 9p now ?!? ;-)
>
> No, I am running syzkaller and seeing things :)
>
:)
>
> > Cc'ing Dominique Martinet who appears to be the person who takes care
The following commit has been merged into the sched/core branch of tip:
Commit-ID: e65855a52b479f98674998cb23b21ef5a8144b04
Gitweb:
https://git.kernel.org/tip/e65855a52b479f98674998cb23b21ef5a8144b04
Author:Qais Yousef
AuthorDate:Thu, 16 Jul 2020 12:03:47 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 13685c4a08fca9dd76bf53bfcbadc044ab2a08cb
Gitweb:
https://git.kernel.org/tip/13685c4a08fca9dd76bf53bfcbadc044ab2a08cb
Author:Qais Yousef
AuthorDate:Thu, 16 Jul 2020 12:03:45 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: 1f73d1abe5836bd8ffe747ff5cb7561b17ce5bc6
Gitweb:
https://git.kernel.org/tip/1f73d1abe5836bd8ffe747ff5cb7561b17ce5bc6
Author:Qais Yousef
AuthorDate:Thu, 16 Jul 2020 12:03:46 +01:00
Add the Texas Instruments bq27z561 battery monitor to the bq27xxx
binding.
Acked-by: Rob Herring
Signed-off-by: Dan Murphy
---
v5 - Rebased on power-next and changed bq27561->bq27z561
Documentation/devicetree/bindings/power/supply/bq27xxx.yaml | 1 +
1 file changed, 1 insertion(+)
diff
Wouldn't be myself if I didn't forget that
Fixes: aec89f78cf01 (clk: qcom: Add support for msm8994 global clock controller)
Konrad
On Wed, Jul 29, 2020 at 02:35:31AM +0200, Samuel Thibault wrote:
> The nasty TODO items are done.
>
> Signed-off-by: Samuel Thibault
Now applied, thanks for all of the work so far.
I will be glad to merge patches for this subsystem to Linus if you want
me to collect them. If so, feel free to
Add the Texas Instruments bq28z610 battery monitor to the bq27xxx
binding.
Acked-by: Rob Herring
Signed-off-by: Dan Murphy
---
Documentation/devicetree/bindings/power/supply/bq27xxx.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
Add the Texas Instruments BQ27z561 battery monitor. The register address
map is laid out the same as compared to other devices within the file.
The battery status register has differing bits to determine if the
battery is full, discharging or dead.
Signed-off-by: Dan Murphy
---
Add the Texas Instruments BQ28z610 battery monitor.
The register address map is laid out the same as compared to other
devices within the file.
The battery status register bits are similar to the bq27z561 but they
are different compared to other fuel gauge devices within this file.
The BLK_CTRL according to HW design is basically the wrapper of the entire
function specific group of IPs and holds GPRs that usually cannot be placed
into one specific IP from that group. Some of these GPRs are used to control
some clocks, other some resets, others some very specific function
Add hdmi blk_ctrl clocks and resets in the i.MX8MP clock
driver to be picked up by the clk-blk-ctrl driver.
Signed-off-by: Abel Vesa
---
drivers/clk/imx/clk-blk-ctrl.c | 4 +++
drivers/clk/imx/clk-imx8mp.c | 63 ++
2 files changed, 67 insertions(+)
These will be used by the imx8mp for blk-ctrl driver.
Signed-off-by: Abel Vesa
---
include/dt-bindings/reset/imx8mp-reset.h | 28
1 file changed, 28 insertions(+)
diff --git a/include/dt-bindings/reset/imx8mp-reset.h
b/include/dt-bindings/reset/imx8mp-reset.h
In the reference manual the actual name is Audio BLK_CTRL.
Lets make it more obvious here by renaming from audiomix to audio_blk_ctrl.
Signed-off-by: Abel Vesa
---
include/dt-bindings/clock/imx8mp-clock.h | 120 +++
1 file changed, 60 insertions(+), 60 deletions(-)
These will be used by the imx8mp for blk-ctrl driver.
Signed-off-by: Abel Vesa
---
include/dt-bindings/reset/imx8mp-reset.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/dt-bindings/reset/imx8mp-reset.h
b/include/dt-bindings/reset/imx8mp-reset.h
index 2e8c910..fca0c9bff
Some of the features of the media_ctrl will be used by some
different drivers in a way those drivers will know best, so adding the
syscon compatible we allow those to do just that. Only the resets
and the clocks are registered bit the clk-blk-ctrl driver.
Signed-off-by: Abel Vesa
---
These will be used by the imx8mp for blk-ctrl driver.
Signed-off-by: Abel Vesa
---
include/dt-bindings/clock/imx8mp-clock.h | 40
1 file changed, 40 insertions(+)
diff --git a/include/dt-bindings/clock/imx8mp-clock.h
b/include/dt-bindings/clock/imx8mp-clock.h
These will be used by the imx8mp for blk-ctrl driver.
Signed-off-by: Abel Vesa
---
include/dt-bindings/clock/imx8mp-clock.h | 28
1 file changed, 28 insertions(+)
diff --git a/include/dt-bindings/clock/imx8mp-clock.h
b/include/dt-bindings/clock/imx8mp-clock.h
Some of the features of the audio_ctrl will be used by some
different drivers in a way those drivers will know best, so adding the
syscon compatible we allow those to do just that. Only the resets
and the clocks are registered bit the clk-blk-ctrl driver.
Signed-off-by: Abel Vesa
---
Add media blk_ctrl clocks and resets in the i.MX8MP clock
driver to be picked up by the clk-blk-ctrl driver.
Signed-off-by: Abel Vesa
---
drivers/clk/imx/clk-blk-ctrl.c | 4 +++
drivers/clk/imx/clk-imx8mp.c | 68 ++
2 files changed, 72 insertions(+)
The hdmi BLK_CTRL ids have been moved to imx8mp-reset.h
Signed-off-by: Abel Vesa
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 9de2aa1..daa1769 100644
According to the RM, the CCGR101 is shared for the following root clocks:
- AUDIO_AHB_CLK_ROOT
- AUDIO_AXI_CLK_ROOT
- SAI2_CLK_ROOT
- SAI3_CLK_ROOT
- SAI5_CLK_ROOT
- SAI6_CLK_ROOT
- SAI7_CLK_ROOT
- PDM_CLK_ROOT
Signed-off-by: Abel Vesa
---
drivers/clk/imx/clk-imx8mp.c | 12 +++-
1 file
These will be used imx8mp for blk-ctrl driver.
Signed-off-by: Abel Vesa
---
include/dt-bindings/reset/imx8mp-reset.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/dt-bindings/reset/imx8mp-reset.h
b/include/dt-bindings/reset/imx8mp-reset.h
index 13e56dd..c1ca79c
On i.MX8MP, there is a new type of IP which is called BLK_CTRL in
RM and usually is comprised of some GPRs that are considered too
generic to be part of any dedicated IP from that specific subsystem.
In general, some of the GPRs have some clock bits, some have reset bits,
so in order to be able
901 - 1000 of 1239 matches
Mail list logo
