Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
To avoid any possible use after free.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
No point to try recovery if device is gone, it's meaningless.
I think that this should go into the device specific recovery function
and not in the scheduler.
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdg
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #21 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286915
https://gitlab.com/gitlab-org/gitlab/-/issues/286916
https://gitlab.com/gitlab-org/gitlab/-/issues/286917
https://gitlab.com/gitlab-org/g
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
It's needed to drop iommu backed pages on device unplug
before device's IOMMU group is released.
It would be cleaner if we could do the whole handling in TTM. I also
need to double check what you are doing with this function.
Christian.
Sign
On 11/21/20 7:23 PM, Matthew Wilcox wrote:
> On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com wrote:
>> The fixer review is
>> https://reviews.llvm.org/D91789
>>
>> A run over allyesconfig for x86_64 finds 62 issues, 5 are false positives.
>> The false positives are caused by macros pass
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #22 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/286988
https://gitlab.com/gitlab-org/gitlab/-/issues/286989
https://gitlab.com/gitlab-org/gitlab/-/issues/286990
https://gitlab.com/gitlab-org/g
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #23 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/287043
https://gitlab.com/gitlab-org/gitlab/-/issues/287044
https://gitlab.com/gitlab-org/gitlab/-/issues/287045
https://gitlab.com/gitlab-org/g
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #24 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/287072
https://gitlab.com/gitlab-org/gitlab/-/issues/287073
https://gitlab.com/gitlab-org/gitlab/-/issues/287074
https://gitlab.com/gitlab-org/g
On 11/22/20 6:56 AM, Matthew Wilcox wrote:
> On Sun, Nov 22, 2020 at 06:46:46AM -0800, Tom Rix wrote:
>> On 11/21/20 7:23 PM, Matthew Wilcox wrote:
>>> On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com wrote:
The fixer review is
https://reviews.llvm.org/D91789
A run ove
On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote:
> > > > This series aims to fix almost all
On 11/21/20 9:10 AM, Joe Perches wrote:
> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
>> A difficult part of automating commits is composing the subsystem
>> preamble in the commit log. For the ongoing effort of a fixer producing
>> one or two fixes a release the use of 'treewide:'
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #25 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/287105
https://gitlab.com/gitlab-org/gitlab/-/issues/287106
https://gitlab.com/gitlab-org/gitlab/-/issues/287107
https://gitlab.com/gitlab-org/g
On Sun, 2020-11-22 at 08:10 -0800, Tom Rix wrote:
> On 11/22/20 6:56 AM, Matthew Wilcox wrote:
> > On Sun, Nov 22, 2020 at 06:46:46AM -0800, Tom Rix wrote:
> > > On 11/21/20 7:23 PM, Matthew Wilcox wrote:
> > > > On Sat, Nov 21, 2020 at 08:50:58AM -0800, t...@redhat.com
> > > > wrote:
> > > > > The
https://bugzilla.kernel.org/show_bug.cgi?id=210303
Bug ID: 210303
Summary: Ryzen 3 PRO 4350G GPU Failed to updateMST allocation
table
Product: Drivers
Version: 2.5
Kernel Version: 5.9.9
Hardware: IA-64
O
https://bugzilla.kernel.org/show_bug.cgi?id=210303
--- Comment #1 from mkkot (marcin2...@gmail.com) ---
Created attachment 293767
--> https://bugzilla.kernel.org/attachment.cgi?id=293767&action=edit
xrandr
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugzilla.kernel.org/show_bug.cgi?id=210303
--- Comment #2 from mkkot (marcin2...@gmail.com) ---
Created attachment 293769
--> https://bugzilla.kernel.org/attachment.cgi?id=293769&action=edit
glxgears info
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=210303
--- Comment #3 from mkkot (marcin2...@gmail.com) ---
Created attachment 293771
--> https://bugzilla.kernel.org/attachment.cgi?id=293771&action=edit
xorg log (not from the time when it happened)
--
You are receiving this mail because:
You are w
https://bugzilla.kernel.org/show_bug.cgi?id=210303
--- Comment #4 from mkkot (marcin2...@gmail.com) ---
Created attachment 293773
--> https://bugzilla.kernel.org/attachment.cgi?id=293773&action=edit
lsmod
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=210303
--- Comment #5 from mkkot (marcin2...@gmail.com) ---
Created attachment 293775
--> https://bugzilla.kernel.org/attachment.cgi?id=293775&action=edit
lspci
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #26 from swebwaer (gosesen...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/287175
https://gitlab.com/gitlab-org/gitlab/-/issues/287176
https://gitlab.com/gitlab-org/gitlab/-/issues/287177
https://gitlab.com/gitlab-org/g
https://bugzilla.kernel.org/show_bug.cgi?id=210303
--- Comment #6 from mkkot (marcin2...@gmail.com) ---
Xorg configuration files have nothing to do with this problem, but currently I
have:
/etc/X11/xorg.conf.d/10-monitor.conf
Section "Monitor"
Identifier "HDMI-1"
Option "Primary" "False"
https://bugzilla.kernel.org/show_bug.cgi?id=210303
--- Comment #7 from mkkot (marcin2...@gmail.com) ---
Created attachment 293777
--> https://bugzilla.kernel.org/attachment.cgi?id=293777&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=210303
--- Comment #8 from mkkot (marcin2...@gmail.com) ---
Created attachment 293779
--> https://bugzilla.kernel.org/attachment.cgi?id=293779&action=edit
DDC proble of monitor and TV
--
You are receiving this mail because:
You are watching the assig
https://bugzilla.kernel.org/show_bug.cgi?id=205675
All Event Live Here (fasix52...@tjuln.com) changed:
What|Removed |Added
CC||fasix52...@tj
On Sun, 2020-11-22 at 08:17 -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R
On Sun, 2020-11-22 at 08:33 -0800, Tom Rix wrote:
> On 11/21/20 9:10 AM, Joe Perches wrote:
> > On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> > > A difficult part of automating commits is composing the subsystem
> > > preamble in the commit log. For the ongoing effort of a fixer prod
On Sun, 2020-11-22 at 08:49 -0800, James Bottomley wrote:
> We can enforce sysfs_emit going forwards
> using tools like checkpatch
It's not really possible for checkpatch to find or warn about
sysfs uses of sprintf. checkpatch is really just a trivial
line-by-line parser and it has no concept of c
On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> Please tell me
> our reward for all this effort isn't a single missing error print.
There were quite literally dozens of logical defects found
by the fallthrough additions. Very few were logging only.
_
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #28 from All Event Live Here (fasix52...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/287301
https://gitlab.com/gitlab-org/gitlab/-/issues/287302
https://gitlab.com/gitlab-org/gitlab/-/issues/287303
https://gitlab.com/g
On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > Please tell me our reward for all this effort isn't a single
> > missing error print.
>
> There were quite literally dozens of logical defects found
> by the fallthrough additions.
On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > Please tell me our reward for all this effort isn't a single
> > > missing error print.
> >
> > There were quite lit
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #29 from All Event Live Here (fasix52...@tjuln.com) ---
https://www.pexels.com/@broncos-vs-dolphins-live-free-nfl-2020-online-6230764
https://www.pexels.com/@dolphin-vs-broncos-live-free-nfl-2020-6230776
https://www.pexels.com/@charger
On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 10:21 -0800, James Bottomley wrote:
> > > > Please tell me our reward for all this effort isn't a s
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #30 from All Event Live Here (fasix52...@tjuln.com) ---
https://www.pexels.com/@live-broncos-vs-dolphins-livestream-free-6230961
https://www.pexels.com/@live-chargers-vs-jets-livestream-free-6230973
https://www.pexels.com/@live-colts-v
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #31 from All Event Live Here (fasix52...@tjuln.com) ---
https://gitlab.com/gitlab-org/gitlab/-/issues/287479
https://gitlab.com/gitlab-org/gitlab/-/issues/287481
https://gitlab.com/gitlab-org/gitlab/-/issues/287482
https://gitlab.com/g
Hi Gustavo,
On Fri, Nov 20, 2020 at 12:35:17PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
>
> Link: https://github.com/KSPP/linux/
On Fri, Nov 20, 2020 at 12:35:54PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
>
> Link: https://github.com/KSPP/linux/issues/115
>
Hi Gustavo,
On Fri, Nov 20, 2020 at 12:40:32PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of letting the code fall
> through to the next case.
>
> Link: https://github.com/KSPP/linux/
Hi James.
> > > If none of the 140 patches here fix a real bug, and there is no
> > > change to machine code then it sounds to me like a W=2 kind of a
> > > warning.
> >
> > FWIW, this series has found at least one bug so far:
> > https://lore.kernel.org/lkml/CAFCwf11izHF=g1mGry1fE5kvFFFrxzhPSM6q
On Sun, 2020-11-22 at 21:35 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
> wrote:
> > Well, it's a problem in an error leg, sure, but it's not a really
> > compelling reason for a 141 patch series, is it? All that fixing
> > this error will do is get the driver to
On Mon, 2020-11-23 at 09:54 +1100, Finn Thain wrote:
> But is anyone keeping score of the regressions? If unreported bugs
> count, what about unreported regressions?
Well, I was curious about the former (obviously no tool will tell me
about the latter), so I asked git what patches had a fall-throu
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #32 from All Event Live Here (fasix52...@tjuln.com) ---
https://www.pexels.com/@live-raiders-vs-chiefs-livestream-free-6231452
https://www.pexels.com/@live-chiefs-vs-raiders-livestream-free-nfl-6231462
https://www.pexels.com/@live-raid
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #33 from All Event Live Here (fasix52...@tjuln.com) ---
https://www.cwu.edu/ce/sites/cts.cwu.edu.ce/files/webform/Raiders-v-Chiefs-liv-hd-tv-01_0.html
https://www.cwu.edu/ce/sites/cts.cwu.edu.ce/files/webform/Raiders-v-Chiefs-liv-hd-tv
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #34 from All Event Live Here (fasix52...@tjuln.com) ---
https://www.cwu.edu/ce/sites/cts.cwu.edu.ce/files/webform/Chiefs-v-Raiders-live-50.html
https://www.cwu.edu/ce/sites/cts.cwu.edu.ce/files/webform/Chiefs-v-Raiders-live-51.html
htt
On Mon, 2020-11-23 at 09:33 +1100, Finn Thain wrote:
> On Sun, 22 Nov 2020, Joe Perches wrote:
> > But provably correct conversions IMO _should_ be done and IMO churn
> > considerations should generally have less importance.
[]
> Moreover, the patch review workload for skilled humans is being gen
EMC driver will become mandatory after turning it into interconnect
provider because interconnect users, like display controller driver, will
fail to probe using newer device-trees that have interconnect properties.
Thus make EMC driver to probe even if timings are missing in device-tree.
Signed-o
HI Tomeu,
On Wed, 7 Oct 2020 at 19:49, Clément Péron wrote:
>
> Hi Tomeu,
>
> On Wed, 7 Oct 2020 at 10:58, Tomeu Vizoso wrote:
> >
> > Hi Clément,
> >
> > Have just noticed that my Pine H64 board hangs when I try to set the
> > performance governor for the GPU devfreq.
> >
> > Is this a known bu
Now Internal and External memory controllers are memory interconnection
providers. This allows us to use interconnect API for tuning of memory
configuration. EMC driver now supports OPPs and DVFS. MC driver now
supports tuning of memory arbitration latency, which needs to be done
for ISO memory cli
Add interconnect properties to the Memory Controller, External Memory
Controller and the Display Controller nodes in order to describe hardware
interconnection.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra124.dtsi | 25 +
1 file changed, 25 insertions(+)
di
Add modularization support to the Tegra124 EMC driver, which now can be
compiled as a loadable kernel module.
Note that EMC clock must be registered at clk-init time, otherwise PLLM
will be disabled as unused clock at boot time if EMC driver is compiled
as a module. Hence add a prepare/complete ca
This patch moves ACTMON driver away from generating OPP table by itself,
transitioning it to use the table which comes from device-tree. This
change breaks compatibility with older device-trees and brings support
for the interconnect framework to the driver. This is a mandatory change
which needs t
Now Internal and External memory controllers are memory interconnection
providers. This allows us to use interconnect API for tuning of memory
configuration. EMC driver now supports OPPs and DVFS.
Tested-by: Nicolas Chauvet
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/Kconfig
Previously we were using count-weight of the T124 for T30 in order to
get EMC clock rate that was reasonable for T30. In fact the count-weight
should be x2 times smaller on T30, but then devfreq was producing a bit
too low EMC clock rate for ISO memory clients, like display controller
for example.
This series brings initial support for memory interconnect to Tegra20,
Tegra30 and Tegra124 SoCs.
For the starter only display controllers and devfreq devices are getting
interconnect API support, others could be supported later on. The display
controllers have the biggest demand for interconnect
Add interconnect properties to the Memory Controller, External Memory
Controller and the Display Controller nodes in order to describe hardware
interconnection.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra30.dtsi | 27 ++-
1 file changed, 26 insertions(+), 1
Remove tegra20-devfreq in order to replace it with a EMC_STAT based
devfreq driver. Previously we were going to use MC_STAT based
tegra20-devfreq driver because EMC_STAT wasn't working properly, but
now that problem is resolved. This resolves complications imposed by
the removed driver since it was
It's useful to know the total number of underflow events and currently
the debug stats are getting reset each time CRTC is being disabled. Let's
account the overall number of events that doesn't get a reset.
Tested-by: Peter Geis
Tested-by: Nicolas Chauvet
Signed-off-by: Dmitry Osipenko
---
dr
Display controller (DC) performs isochronous memory transfers, and thus,
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.
The Memory
Fix the size of Tegra20 EMC registers, which should be twice bigger.
Acked-by: Krzysztof Kozlowski
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dts
Add EMC OPP tables and interconnect paths that will be used for
dynamic memory bandwidth scaling based on memory utilization statistics.
Update board device-trees by removing unsupported EMC OPPs.
Note that ACTMON watches all memory interconnect paths, but we use a
single CPU-READ interconnect pat
Add nvidia,memory-controller to the Tegra20 External Memory Controller
node. This allows to perform a direct lookup of the Memory Controller
instead of walking up the whole tree. This puts Tegra20 device-tree on
par with Tegra30+.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi
On Sun, Nov 22, 2020 at 7:22 PM James Bottomley
wrote:
>
> Well, it's a problem in an error leg, sure, but it's not a really
> compelling reason for a 141 patch series, is it? All that fixing this
> error will do is get the driver to print "oh dear there's a problem"
> under four more conditions
Document opp-supported-hw property, which is not strictly necessary to
have on Tegra20, but it's very convenient to have because all other SoC
core devices will use hardware versioning, and thus, it's good to maintain
the consistency.
Signed-off-by: Dmitry Osipenko
---
.../bindings/memory-contro
Add EMC OPP DVFS tables and update board device-trees by removing
unsupported OPPs.
Signed-off-by: Dmitry Osipenko
---
.../boot/dts/tegra20-acer-a500-picasso.dts| 5 +
arch/arm/boot/dts/tegra20-colibri.dtsi| 4 +
arch/arm/boot/dts/tegra20-paz00.dts | 4 +
.../arm/boot
Add interconnect properties to the Memory Controller, External Memory
Controller and the Display Controller nodes in order to describe hardware
interconnection.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 26 +-
1 file changed, 25 insertions(+), 1
Add EMC OPP DVFS/DFS tables and interconnect paths that will be used for
dynamic memory bandwidth scaling based on memory utilization statistics.
Update board device-trees by removing unsupported EMC OPPs.
Note that ACTMON watches all memory interconnect paths, but we use a
single CPU-READ interco
Support hardware versioning, which is now required for Tegra20 EMC OPP.
Clean up OPP table initialization by using a error code returned by OPP
API for judging about the OPP table presence in a device-tree and remove
OPP regulator initialization because we're now going to use power domain
instead o
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #35 from All Event Live Here (fasix52...@tjuln.com) ---
https://www.cwu.edu/ce/sites/cts.cwu.edu.ce/files/webform/Chiefs-v-Raiders-live-61.html
https://www.cwu.edu/ce/sites/cts.cwu.edu.ce/files/webform/Chiefs-v-Raiders-live-62.html
htt
HI Krzysztof,
20. 11. 17. 오전 2:53에 Krzysztof Kozlowski 이(가) 쓴 글:
> The Exynos DRM uses Common Clock Framework thus it cannot be built on
> platforms without it (e.g. compile test on MIPS with RALINK and
> SOC_RT305X):
>
> /usr/bin/mips-linux-gnu-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in
https://bugzilla.kernel.org/show_bug.cgi?id=205675
--- Comment #36 from All Event Live Here (fasix52...@tjuln.com) ---
https://www.cwu.edu/ce/sites/cts.cwu.edu.ce/files/webform/Chiefs-v-Raiders-live-61.html
https://www.cwu.edu/ce/sites/cts.cwu.edu.ce/files/webform/Chiefs-v-Raiders-live-62.html
htt
[AMD Public Use]
+Alex.
We have one following patch to fix this. Please check.
a069a9eb73f8 drm/amdgpu: fix a warning in amdgpu_ras.c (v2)
Regards,
Guchun
-Original Message-
From: kernel test robot
Sent: Saturday, November 21, 2020 2:02 PM
To: Chen, Guchun
Cc: kbuild-...@lists.01.or
Hi Laurentiu,
On Fri, 2020-11-20 at 16:38 +0200, Laurentiu Palcu wrote:
> Hi Liu Ying,
>
> I gave this a first look but, since this is a huge piece of code and I'm not
> very familiar with DPU, I'll probably give it another pass next week.
>
> Anyway, some comments/questions inline.
>
> On Thu,
On 11/21/20 9:15 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Uff, one page for each exported DMA-buf? That's not something we can do.
We need to find a different approach here.
Can't w
On 11/21/20 9:13 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Fixes oops.
That file doesn't even exist any more. What oops should this fix?
Which file ?
We set dma_address to NULL in every other place after unmap. This is so that
if dma address was already unm
On 11/22/20 6:57 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
No point to try recovery if device is gone, it's meaningless.
I think that this should go into the device specific recovery function and not
in the scheduler.
The timeout timer is rearmed here, so
Hi Sylwester,
On 11/12/20 11:09 PM, Sylwester Nawrocki wrote:
>
> This patchset adds interconnect API support for the Exynos SoC "samsung,
> exynos-bus" compatible devices, which already have their corresponding
> exynos-bus driver in the devfreq subsystem. Complementing the devfreq
> driver wit
Hi Dmitry,
On 11/23/20 9:27 AM, Dmitry Osipenko wrote:
> This patch moves ACTMON driver away from generating OPP table by itself,
> transitioning it to use the table which comes from device-tree. This
> change breaks compatibility with older device-trees and brings support
> for the interconnect f
On 11/23/20 9:27 AM, Dmitry Osipenko wrote:
> Remove tegra20-devfreq in order to replace it with a EMC_STAT based
> devfreq driver. Previously we were going to use MC_STAT based
> tegra20-devfreq driver because EMC_STAT wasn't working properly, but
> now that problem is resolved. This resolves comp
Am 20.11.20 um 15:42 schrieb Maxime Ripard:
The current HVS muxing code will consider the CRTCs in a given state to
setup their muxing in the HVS, and disable the other CRTCs muxes.
However, it's valid to only update a single CRTC with a state, and in this
situation we would mux out a CRTC tha
79 matches
Mail list logo
