Previously, the 1GHz variants were marked as a turbo,
because that variant has reduced thermal operating range.
Now that the thermal throttling is in place, it should be
safe to remove the turbo-mode from the 1GHz variants, because
the CPU will automatically slow if the thermal limit is reached.
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any
issue:
Reported-and-tested-by: syzbot+99ed55100402022a6...@syzkaller.appspotmail.com
Tested on:
commit: d9d05217 io_uring: stop SQPOLL submit on creator's death
git tree:
Hi Adam,
> Am 09.01.2021 um 17:39 schrieb Adam Ford :
>
> Previously, the 1GHz variants were marked as a turbo,
> because that variant has reduced thermal operating range.
>
> Now that the thermal throttling is in place, it should be
> safe to remove the turbo-mode from the 1GHz variants,
On Sat, Jan 9, 2021 at 10:39 AM Adam Ford wrote:
>
> Previously, the 1GHz variants were marked as a turbo,
> because that variant has reduced thermal operating range.
>
> Now that the thermal throttling is in place, it should be
> safe to remove the turbo-mode from the 1GHz variants, because
>
SDM630 and MSM8998 are among the SoCs that use Qualcomm's implementation
of SMMUv2 which has already proven to be problematic over the years. Add
their compatibles to the lookup list to prevent the platforms from being
shut down by the hypervisor at MMU probe.
Signed-off-by: Konrad Dybcio
Am 2021-01-08 18:22, schrieb Saravana Kannan:
On Fri, Jan 8, 2021 at 12:16 AM Michael Walle wrote:
Am 2021-01-08 02:24, schrieb Saravana Kannan:
> The device link device's name was of the form:
> --
>
> This can cause name collision as reported here [1] as device names are
> not globally
On Sat, Jan 9, 2021 at 5:33 PM Josh Poimboeuf wrote:
>
> > > > Did you push it (oh ah push it push it really really really good...)
> > > > to your remote Git please :-).
> > >
> > > I thought I already pushed it pretty good ;-) do you not see it?
> > >
> > >
Hi
> Gesendet: Samstag, 09. Januar 2021 um 12:26 Uhr
> Von: matthias@kernel.org
> Changes in v2:
> - check for CONFIG_OF
> - add Fixes tag
> --- a/drivers/regulator/mt6323-regulator.c
> +++ b/drivers/regulator/mt6323-regulator.c
> @@ -406,9 +406,18 @@ static const struct platform_device_id
On Wed, Jan 06, 2021 at 08:33:50PM +, Wei Liu wrote:
> Just like MSI/MSI-X, IO-APIC interrupts are remapped by Microsoft
> Hypervisor when Linux runs as the root partition. Implement an IRQ chip
> to handle mapping and unmapping of IO-APIC interrupts.
>
> Use custom functions for mapping and
On 09/01/2021 16:27, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:36bbbd0e Merge branch 'rcu/urgent' of git://git.kernel.org..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=149afeeb50
> kernel config:
Previously, the 1GHz variants were marked as a turbo,
because that variant has reduced thermal operating range.
Now that the thermal throttling is in place, it should be
safe to remove the turbo-mode from the 1GHz variants, because
the CPU will automatically slow if the thermal limit is reached.
On Wed, Jan 06, 2021 at 08:33:49PM +, Wei Liu wrote:
> We are about to implement an irqchip for IO-APIC when Linux runs as root
> on Microsoft Hypervisor. At the same time we would like to reuse
> existing code as much as possible.
>
> Move mp_chip_data to io_apic.h and make a few helper
> > > Did you push it (oh ah push it push it really really really good...)
> > > to your remote Git please :-).
> >
> > I thought I already pushed it pretty good ;-) do you not see it?
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git
> > objtool-vmlinux
> >
> >
On Sat, Jan 09, 2021 at 12:38:13AM -0300, Matheus Castello wrote:
>
>
> Em 12/29/2020 6:17 PM, Cristian Ciocaltea escreveu:
> > Add Clock Management Unit for Actions Semi S500 SoC.
> >
> > Signed-off-by: Cristian Ciocaltea
> > Reviewed-by: Manivannan Sadhasivam
[...]
> Tested-by: Matheus
SDM630 and MSM8998 are among the SoCs that use Qualcomm's implementation
of SMMUv2 which has already proven to be problematic over the years. Add
their compatibles to the lookup list to prevent the platforms from being
shut down by the hypervisor at MMU probe.
Signed-off-by: Konrad Dybcio
From: Konrad Dybcio
Add missing SoC IDs for Snapdragon 630-family platforms.
Signed-off-by: Konrad Dybcio
Tested-by: AngeloGioacchino Del Regno
---
drivers/soc/qcom/socinfo.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
Add missing SoC IDs for Snapdragon 835-family platforms.
Signed-off-by: Konrad Dybcio
Tested-by: AngeloGioacchino Del Regno
---
drivers/soc/qcom/socinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index
This is the usual way of handling pin configuration upstream now, so
align to it.
Signed-off-by: Konrad Dybcio
Tested-by: AngeloGioacchino Del Regno
---
arch/arm64/boot/dts/qcom/msm8998-pins.dtsi | 108 -
arch/arm64/boot/dts/qcom/msm8998.dtsi | 106 +++-
Some components (like PCIe) are not used on all devices and
with a certain firmware configuration they might end up triggering
a force reboot or a Synchronous Abort.
This commit brings no functional difference as the nodes are
enabled on devices which didn't disable them previously.
This patch series brings some minor, but important fixes to the MSM8998
DTSI, including renaming I2C hosts to match the correct scheme, adding DMA
to them, merging the -pins.dtsi into the main one and adding capacity-dmips-mhz
to CPU cores. Some components were also disabled by default (with no
Add DMA properties to I2C hosts to allow for DMA transfers.
Signed-off-by: Konrad Dybcio
Tested-by: AngeloGioacchino Del Regno
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
The BLSP2-connected interfaces started from 0 which is.. misleading
to say the least.. the clock names corresponding to these started
from 1, so let's align to that so as to reduce confusion.
Signed-off-by: Konrad Dybcio
Tested-by: AngeloGioacchino Del Regno
---
Add capacity-dmips-mhz to ensure the scheduler can efficiently
make use of the big.LITTLE core configuration.
Signed-off-by: Konrad Dybcio
Tested-by: AngeloGioacchino Del Regno
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 8
1 file changed, 8 insertions(+)
diff --git
On Sat, Jan 09, 2021 at 04:54:22PM +0100, Andrew Lunn wrote:
> On Sat, Jan 09, 2021 at 03:46:01PM +, Russell King - ARM Linux admin
> wrote:
> > On Thu, Jan 07, 2021 at 05:54:28PM +0100, Andrew Lunn wrote:
> > > On Wed, Jan 06, 2021 at 04:37:48PM +0100, Pali Rohár wrote:
> > > > From: Russell
Hello,
syzbot found the following issue on:
HEAD commit:36bbbd0e Merge branch 'rcu/urgent' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=149afeeb50
kernel config: https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224
Hello,
syzbot found the following issue on:
HEAD commit:f6e7a024 Merge tag 'arc-5.11-rc3' of git://git.kernel.org/..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=11a9a760d0
kernel config: https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224
On Sat, Jan 9, 2021 at 5:07 PM Josh Poimboeuf wrote:
>
> On Sat, Jan 09, 2021 at 04:46:21PM +0100, Sedat Dilek wrote:
> > On Sat, Jan 9, 2021 at 4:36 PM Josh Poimboeuf wrote:
> > >
> > > On Sat, Jan 09, 2021 at 03:54:20PM +0100, Sedat Dilek wrote:
> > > > I am interested in having Clang LTO
On 09/01/2021 11:50, Hillf Danton wrote:
> Sat, 09 Jan 2021 00:29:16 -0800
>> syzbot found the following issue on:
>>
>> HEAD commit:71c061d2 Merge tag 'for-5.11-rc2-tag' of git://git.kernel...
>> git tree: upstream
>> console output:
On 06/12/2020 16:01, Pavel Begunkov wrote:
> On 21/11/2020 14:37, Pavel Begunkov wrote:
>> The problem here is that iov_iter_is_*() helpers check types for
>> equality, but all iterate_* helpers do bitwise ands. This confuses
>> compilers, so even if some cases were handled separately with
>>
The dt-bindings/power/qcom-rpmpd.h header is being included in this
DT but the RPMPD OPP table declarations were using open-coded values:
use the definitions found in the aforementioned header.
Signed-off-by: AngeloGioacchino Del Regno
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 20
On Sat, Jan 09, 2021 at 04:46:21PM +0100, Sedat Dilek wrote:
> On Sat, Jan 9, 2021 at 4:36 PM Josh Poimboeuf wrote:
> >
> > On Sat, Jan 09, 2021 at 03:54:20PM +0100, Sedat Dilek wrote:
> > > I am interested in having Clang LTO (Clang-CFI) for x86-64 working and
> > > help with testing.
> > >
> >
iter_file_splice_write() may spawn bvec segments with zero-length. In
preparation for prohibiting them, filter out by hand at splice level.
Reviewed-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
---
fs/splice.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
Add a helper function calculating the number of bvec segments we need to
allocate to construct a bio. It doesn't change anything functionally,
but will be used to not duplicate special cases in the future.
Reviewed-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
---
fs/block_dev.c |
The block layer spends quite a while in blkdev_direct_IO() to copy and
initialise bio's bvec. However, if we've already got a bvec in the input
iterator it might be reused in some cases, i.e. when new
ITER_BVEC_FLAG_FIXED flag is set. Simple tests show considerable
performance boost, and it also
iov_iter_advance() is heavily used, but implemented through generic
means. For bvecs there is a specifically crafted function for that, so
use bvec_iter_advance() instead, it's faster and slimmer.
Reviewed-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
---
lib/iov_iter.c | 19
zero-length bvec segments are allowed in general, but not handled by bio
and down the block layer so filtered out. This inconsistency may be
confusing and prevent from optimisations. As zero-length segments are
useless and places that were generating them are patched, declare them
not allowed.
Direct IO does not operate on the current working set of pages managed
by the kernel, so it should not be accounted as memory stall to PSI
infrastructure.
The block layer and iomap direct IO use bio_iov_iter_get_pages()
to build bios, and they are the only users of it, so to avoid PSI
tracking
From: Christoph Hellwig
This saves one memory allocation, and ensures the bvecs aren't freed
before the AIO completion. This will allow the lower level code to be
optimized so that it can avoid allocating another bvec array.
Signed-off-by: Christoph Hellwig
Signed-off-by: Pavel Begunkov
---
Currently, when iomap and block direct IO gets a bvec based iterator
the bvec will be copied, with all other accounting that takes much
CPU time and causes additional allocation for larger bvecs. The
patchset makes it to reuse the passed in iter bvec.
[1,2] are forbidding zero-length bvec
Currently, if I/O is enqueued for async execution direct paths of
generic_file_{read,write}_iter() will always revert the iter. There are
no users expecting that, and that is also costly. Leave iterators as is
on -EIOCBQUEUED.
Signed-off-by: Pavel Begunkov
---
mm/filemap.c | 6 --
1 file
On Fri, Jan 8, 2021 at 1:37 PM Andreas Kemnade wrote:
>
> Hi,
>
> On Fri, 8 Jan 2021 13:17:06 -0600
> Adam Ford wrote:
>
> > On Mon, Dec 7, 2020 at 8:01 AM Tony Lindgren wrote:
> > >
> > > * Doug Anderson [201204 16:43]:
> > > > Hi,
> > > >
> > > > On Fri, Dec 4, 2020 at 8:14 AM Andreas
Linux https://bit.ly/2JY7Ueo Steven Newbury
I might as well be dead, but I could kill you instead. - PJ Harvey
If you brutalize the world around you, you also brutalize yourself. - Flanders
Falling in Love is a trick our genes pull on our otherwise perceptive mind to
hoodwink us
iov_iter_bvec() initialises iterators well, no need to pre-zero it
beforehand as done in fd_execute_rw_aio(). Compilers can't optimise it
out and generate extra code for that (confirmed with assembly).
Signed-off-by: Pavel Begunkov
---
drivers/target/target_core_file.c | 2 +-
1 file changed, 1
lo_rw_aio() knows what iocb.ki_complete it set, so instead of an
expensive indirect call it can call lo_rw_aio_complete() directly.
Signed-off-by: Pavel Begunkov
---
drivers/block/loop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/loop.c
On Sat, Jan 09, 2021 at 03:46:01PM +, Russell King - ARM Linux admin wrote:
> On Thu, Jan 07, 2021 at 05:54:28PM +0100, Andrew Lunn wrote:
> > On Wed, Jan 06, 2021 at 04:37:48PM +0100, Pali Rohár wrote:
> > > From: Russell King
> > >
> > > Some GPON SFP modules (e.g. Ubiquiti U-Fiber
On Fri, Jan 08, 2021 at 07:47:17AM +, Rantala, Tommi T. (Nokia - FI/Espoo)
wrote:
Hi Greg,
Can you cherry-pick these to 4.19.y & 5.4.y:
commit e06689bf57017ac022ccf0f2a5071f760821ce0f
Author: Alexey Dobriyan
Date: Wed Dec 4 16:49:59 2019 -0800
proc: change ->nlink under
On Sat, Jan 9, 2021 at 4:36 PM Josh Poimboeuf wrote:
>
> On Sat, Jan 09, 2021 at 03:54:20PM +0100, Sedat Dilek wrote:
> > I am interested in having Clang LTO (Clang-CFI) for x86-64 working and
> > help with testing.
> >
> > I tried the Git tree mentioned in [3]
> > (together with changes from ).
On Thu, Jan 07, 2021 at 05:54:28PM +0100, Andrew Lunn wrote:
> On Wed, Jan 06, 2021 at 04:37:48PM +0100, Pali Rohár wrote:
> > From: Russell King
> >
> > Some GPON SFP modules (e.g. Ubiquiti U-Fiber Instant) have set both
> > SFP_OPTIONS_LOS_INVERTED and SFP_OPTIONS_LOS_NORMAL bits in their
On Mon, 3 Aug 2020 00:42:31 +0900, Katsuhiro Suzuki wrote:
> This patch enables HDMI sound (I2S0) and Analog sound (I2S1) which
> are defined in rk3328.dtsi, and replace SPDIF nodes.
>
> We can use SPDIF pass-through with suitable ALSA settings and on
> mpv or other media players.
> - Settings:
On Sat, 19 Dec 2020 22:05:00 +0100, Johan Jonker wrote:
> Recently introduced async probe on mmc devices can shuffle block IDs.
> Pin them to fixed values to ease booting in environments where UUIDs
> are not practical. Use newly introduced aliases for mmcblk devices from [1].
>
> [1]
On Fri, 31 Jul 2020 21:33:24 +0530, Jagan Teki wrote:
> RK3399 boards like ROC-RK3399-PC is using MP8859 DC/DC converter
> for 12V supply.
>
> roc-rk3399-pc initially used 12V fixed regulator for this supply,
> but the below commit has switched to use MP8859.
>
> commit
On Mon, 10 Aug 2020 18:16:19 +0900, Katsuhiro Suzuki wrote:
> This patch adds 'disabled' SPDIF sound node and related settings
> for rk3399-rockpro64.
>
> There are 2 reasons:
> - All RK3399 dma-bus channels have been already used by I2S0/1/2
> - RockPro64 does not have SPDIF optical nor
On Fri, 8 Jan 2021 17:10:34 +0200, Demetris Ierokipides wrote:
> Demetris Ierokipides (2):
> ARM: dts: rockchip: add gpu node to rk3288-miqi
> ARM: dts: rockchip: add extra cpu opp points to rk3288-miqi
>
> arch/arm/boot/dts/rk3288-miqi.dts | 17 +
> 1 file changed, 17
On Sat, 15 Aug 2020 13:51:10 +0100, Marc Zyngier wrote:
> Recent changes to the way PCI DT nodes are parsed are now enforcing
> the presence of a "device_type" property, which has been mandated
> since... forever. This has the unfortunate effect of breaking
> non-compliant systems, and those using
On Sun, 6 Dec 2020 11:37:08 +0100, Johan Jonker wrote:
> With the conversion of syscon.yaml minItems for compatibles
> was set to 2. Current Rockchip dtsi files only use "syscon" for
> QoS registers. Add Rockchip QoS compatibles for rk3066/rk3188
> to reduce notifications produced with:
>
> make
On Wed, 30 Sep 2020 14:56:27 -0400, Simon South wrote:
> On Pinebook Pro laptops with an NVMe SSD installed, prevent random
> crashes in the NVMe driver by not attempting to use a PCIe link speed
> higher than that supported by the RK3399 SoC.
>
> See commit 712fa1777207 ("arm64: dts: rockchip:
On Sat, Jan 09, 2021 at 03:54:20PM +0100, Sedat Dilek wrote:
> I am interested in having Clang LTO (Clang-CFI) for x86-64 working and
> help with testing.
>
> I tried the Git tree mentioned in [3]
> (together with changes from ).
>
> I only see in my build-log...
>
>
diff --git a/Makefile b/Makefile
index 71968b4bb313..450ebe152806 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 5
PATCHLEVEL = 4
-SUBLEVEL = 87
+SUBLEVEL = 88
EXTRAVERSION =
NAME = Kleptomaniac Octopus
diff --git a/drivers/dma/at_hdmac.c
I'm announcing the release of the 5.10.6 kernel.
All users of the 5.10 kernel series must upgrade.
The updated 5.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-5.10.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml
b/Documentation/devicetree/bindings/rtc/rtc.yaml
index 8acd2de3de3a..d30dc045aac6 100644
--- a/Documentation/devicetree/bindings/rtc/rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/rtc.yaml
@@ -63,6 +63,11 @@ properties:
diff --git a/Makefile b/Makefile
index e636c2143295..b2c939f289c2 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 19
-SUBLEVEL = 165
+SUBLEVEL = 166
EXTRAVERSION =
NAME = "People's Front"
diff --git a/drivers/dma/at_hdmac.c
I'm announcing the release of the 4.14.214 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.14.y
and can be browsed at the normal kernel.org git web
I'm announcing the release of the 5.4.88 kernel.
All users of the 5.4 kernel series must upgrade.
The updated 5.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-5.4.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 4.19.166 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.19.y
and can be browsed at the normal kernel.org git web
diff --git a/Makefile b/Makefile
index d059e257b976..d36b8f4228a4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 213
+SUBLEVEL = 214
EXTRAVERSION =
NAME = Petit Gorille
diff --git
I'm announcing the release of the 4.9.250 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Makefile b/Makefile
index ef1c9929cdcc..525d7ec7249d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 249
+SUBLEVEL = 250
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/powerpc/sysdev/mpic_msgr.c
diff --git a/Makefile b/Makefile
index 15560bbc07f6..c600c076d2c6 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 249
+SUBLEVEL = 250
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/powerpc/sysdev/mpic_msgr.c
I'm announcing the release of the 4.4.250 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
Sometimes, when dm-crypt executes decryption in a tasklet, we may get the
following on a kasan-enabled kernel:
[ 397.613621][ C74]
==
[ 397.621794][ C74] BUG: KASAN: use-after-free in
Hello Zhang,
On Tue, 8 Dec 2020 20:45:23 +0800, Xiaohui Zhang
wrote:
> From: Zhang Xiaohui
>
> mwifiex_config_scan() calls memcpy() without checking
> the destination size may trigger a buffer overflower,
> which a local user could use to cause denial of service
> or the execution of
On Fri, Dec 11, 2020 at 7:46 PM 'Sami Tolvanen' via Clang Built Linux
wrote:
>
> This patch series adds support for building the kernel with Clang's
> Link Time Optimization (LTO). In addition to performance, the primary
> motivation for LTO is to allow Clang's Control-Flow Integrity (CFI)
> to
On Sat, 2021-01-09 at 14:55 +0100, AngeloGioacchino Del Regno wrote:
> Add support for the GT9286 chip, tested on F(x)Tec Pro1 (MSM8998).
Can you please add this test information to the commit message for the
goodix.c patch?
Feel free to add my:
Reviewed-by: Bastien Nocera
to both patches when
On 07.01.21 23:19, Dave Chinner wrote:
On Sun, Jan 03, 2021 at 05:03:33PM +0100, Donald Buczek wrote:
On 02.01.21 23:44, Dave Chinner wrote:
On Sat, Jan 02, 2021 at 08:12:56PM +0100, Donald Buczek wrote:
On 31.12.20 22:59, Dave Chinner wrote:
On Thu, Dec 31, 2020 at 12:48:56PM +0100, Donald
On Fri, Jan 08, 2021 at 08:45:44PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 08, 2021 at 04:10:51PM +0100, Vincent Guittot wrote:
> > Also, there is another problem (that I'm investigating) which is that
> > this_rq()->avg_idle is stalled when your cpu is busy. Which means that
> > this avg_idle
Am Freitag, 18. Dezember 2020, 13:05:27 CET schrieb Johan Jonker:
> The watchdog compatible strings are suppose to be SoC orientated.
> In the more recently added Rockchip SoC dtsi files only
> the fallback string "snps,dw-wdt" is used, so add the following
> compatible strings:
>
>
The Awinic AW9523(B) is a multi-function I2C gpio expander in a
TQFN-24L package, featuring PWM (max 37mA per pin, or total max
power 3.2Watts) for LED driving capability.
It has two ports with 8 pins per port (for a total of 16 pins),
configurable as either PWM with 1/256 stepping or GPIO
This adds support for the Awinic AW9523/AW9523B I2C GPIO Expander, as
found in the F(x)Tec Pro1 smartphone (there, it's used to drive a
keyboard matrix).
This driver was tested on the aforementioned smartphone.
AngeloGioacchino Del Regno (2):
pinctrl: Add driver for Awinic AW9523/B I2C GPIO
Add bindings for the Awinic AW9523/AW9523B I2C GPIO Expander driver.
Signed-off-by: AngeloGioacchino Del Regno
---
.../pinctrl/awinic,aw9523-pinctrl.yaml| 111 ++
1 file changed, 111 insertions(+)
create mode 100644
On Fri, Jan 08, 2021 at 09:21:48PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 08, 2021 at 10:27:38AM +, Mel Gorman wrote:
>
> > 1. avg_scan_cost is now based on the average scan cost of a rq but
> >avg_idle is still scaled to the domain size. This is a bit problematic
> >because it's
Support for this chip was added to the goodix driver: add the
DT binding for it.
Signed-off-by: AngeloGioacchino Del Regno
---
Documentation/devicetree/bindings/input/touchscreen/goodix.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
Add support for the GT9286 chip, tested on F(x)Tec Pro1 (MSM8998).
AngeloGioacchino Del Regno (2):
input: goodix: Add support for Goodix GT9286 chip
dt-bindings: ts: goodix: Add binding for GT9286 IC
Documentation/devicetree/bindings/input/touchscreen/goodix.yaml | 1 +
The Goodix GT9286 is a capacitive touch sensor IC based on GT1x.
This chip can be found on a number of smartphones, including the
F(x)tec Pro 1 and the Elephone U.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/input/touchscreen/goodix.c | 2 ++
1 file changed, 2 insertions(+)
diff
The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value
directly, but the same value was also being specified in the
dsi_pll_regs struct pll_lockdet_rate variable: let's use it!
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 3 ++-
1 file
The VCO rate was being miscalculated due to a big overlook during
the process of porting this driver from downstream to upstream:
here we are really recalculating the rate of the VCO by reading
the appropriate registers and returning a real frequency, while
downstream the driver was doing
The DSI 10nm PLL driver was apparently ported from downstream, but some
of its "features" were not ported over, for a good reason.
Pity is that the removal of the downstream dependencies broke the clock
calculation logic for this driver and that made it impossible to use any
DSI display on at
DRM_DEV_ERROR should be used across this entire source: convert the
pr_err prints to the first as a cleanup.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
The number of fractional registers bits is known and already set in
the frac_bits variable of the dsi_pll_config struct here in 10nm:
remove the TODO by simply using that variable.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 4 ++--
1 file
Am Samstag, 19. Dezember 2020, 12:26:50 CET schrieb Johan Jonker:
> Add more rga compatible properties.
>
> "rockchip,px30-rga", "rockchip,rk3288-rga"
> "rockchip,rk3328-rga", "rockchip,rk3288-rga"
> "rockchip,rk3368-rga", "rockchip,rk3288-rga"
>
> make ARCH=arm64 dt_binding_check
>
In function dsi_pll_calc_dec_frac we are calculating the decimal
div start parameter by dividing the decimal multiple by the
fractional multiplier: the remainder of that operation is stored
to then get programmed to the fractional divider registers of
the PLL.
It's useless to call div_u64_rem to
The GPU PLL0 is not a fixed PLL and the rate can be set on it:
this is necessary especially on boards which bootloader is setting
a very low rate on this PLL before booting Linux, which would be
unsuitable for postdividing to reach the maximum allowed Adreno GPU
frequency of 710MHz (or, actually,
All of the GPLLs in the MSM8998 Global Clock Controller are Fabia PLLs
and not generic alphas: this was producing bad effects over the entire
clock tree of MSM8998, where any GPLL child clock was declaring a false
clock rate, due to their parent also showing the same.
The issue resides in the
This GDSC enables (or cuts!) power to the Multimedia Subsystem IOMMU
(mmss smmu), which has bootloader pre-set secure contexts.
In the event of a complete power loss, the secure contexts will be
reset and the hypervisor will crash the SoC.
To prevent this, and get a working multimedia subsystem,
The GPU GX GDSC has GPU_GX_BCR reset and gfx3d_clk CXC, as stated
on downstream kernels (and as verified upstream, because otherwise
random lockups happen).
Also, add PWRSTS_RET and NO_RET_PERIPH: also as found downstream,
and also as verified here, to avoid GPU related lockups it is
necessary to
Hardware clock gating is supported on some of the clocks declared in
there: ignoring that it does exist may lead to unstabilities on some
firmwares.
Add the HWCG registers where applicable to stop potential crashes.
This was verified on a smartphone shipped with a recent MSM8998
firmware, which
This clock enables the GPLL0 output to the multimedia subsystem
clock controller.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/clk/qcom/gcc-msm8998.c | 17 +
include/dt-bindings/clock/qcom,gcc-msm8998.h | 1 +
2 files changed, 18 insertions(+)
diff
To achieve CPR-Hardened functionality this clock must be on: add it
in order to be able to get it managed by the CPR3 driver.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/clk/qcom/gcc-msm8998.c | 20
include/dt-bindings/clock/qcom,gcc-msm8998.h | 1
The pixel and byte clocks rate should not be cached, as a VCO shutdown
may clear the frequency setup and this may not be set again due to the
cached rate being present.
This will also be useful when shadow clocks will be implemented in
the DSI PLL for seamless timing/resolution switch.
The GPU IOMMU depends on this clock and the hypervisor will crash
the SoC if this clock gets disabled because the secure contexts
that have been set on this IOMMU by the bootloader will become
unaccessible (or they get reset).
Mark this clock as critical to avoid this issue when the Adreno
GPU is
This patch series fixes some issues with the MSM8998 clocks and, in
particular, brings a very important fix to the GCC PLLs.
These fixes are enhancing this SoC's stability and also makes it
possible to eventually enable the Adreno GPU (with proper clock
scaling) and other components.
This patch
201 - 300 of 385 matches
Mail list logo
