On Fri, Aug 20, 2021 at 11:33 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> In file included from drivers/gpu/drm/i915/i915_debugfs.c:39:
> drivers/gpu/drm/i915/gt/intel_gt_requests.h:9:10: fatal error:
On Thu, Aug 19, 2021 at 04:52:38PM -0500, Rob Herring wrote:
> On Thu, Aug 19, 2021 at 5:12 AM Krzysztof Kozlowski
> wrote:
> >
> > Use common enum instead of oneOf and correct indentation warning:
> > realtek,rt1015p.yaml:18:7: [warning] wrong indentation: expected 4 but
> > found 6 (indentati
Hi Linus,
Regularly scheduled fixes. The ttm one solves a problem of GPU drivers
failing to load if debugfs is off in Kconfig, otherwise the i915 and
mediatek, and amdgpu fixes all fairly normal.
nouveau has a couple of display fixes, but it has a fix for a
longstanding race condition in it's mem
On 19-08-21, 16:55, Ulf Hansson wrote:
> Right, that sounds reasonable.
>
> We already have pm_genpd_opp_to_performance_state() which translates
> an OPP to a performance state. This function invokes the
> ->opp_to_performance_state() for a genpd. Maybe we need to allow a
> genpd to not have ->opp
On 19-08-21, 22:35, Dmitry Osipenko wrote:
> 19.08.2021 16:07, Ulf Hansson пишет:
> > In the other scenario where a consumer driver prefers to *not* call
> > pm_runtime_resume_and_get() in its ->probe(), because it doesn't need
> > to power on the device to complete probing, then we don't want to v
Hi, Bjorn,
On Fri, Aug 20, 2021 at 5:52 AM Bjorn Helgaas wrote:
>
> On Mon, Aug 09, 2021 at 01:59:01PM -0500, Bjorn Helgaas wrote:
> > On Tue, Aug 03, 2021 at 12:06:44PM -0500, Bjorn Helgaas wrote:
> > > On Sat, Jul 24, 2021 at 05:30:02PM +0800, Huacai Chen wrote:
> > > > On Sat, Jul 24, 2021 at
19.08.2021 19:31, Thierry Reding пишет:
>> The "device" representation is internal to the kernel. It's okay to me
>> to have PLLs represented by a device, it's a distinct h/w by itself.
>>
>> CCF supports managing of clock's RPM and it requires to have clock to be
>> backed by a device. That's what
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from drivers/gpu/drm/i915/i915_debugfs.c:39:
drivers/gpu/drm/i915/gt/intel_gt_requests.h:9:10: fatal error: stddef.h: No
such file or directory
9 | #include
|
lima_vm_print() isn't used, so remove it
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/lima/lima_vm.c | 29 -
drivers/gpu/drm/lima/lima_vm.h | 1 -
2 files changed, 30 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_vm.c b/drivers/gpu/drm/lima/lima_vm.c
index 2
On 8/18/2021 11:16 PM, Matthew Brost wrote:
Rather than processing 1 G2H at a time and re-queuing the work queue if
more messages exist, process all the G2H in a single pass of the work
queue.
Signed-off-by: Matthew Brost
Cc: Daniel Vetter
Cc: Michal Wajdeczko
Reviewed-by: Daniele Ceraol
On Thu, Aug 19, 2021 at 05:01:03PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > Don't drop ce->guc_active.lock when unwinding a context after reset.
> > At one point we had to drop this because of a lock inversion but that is
> > no longer the case. I
On 8/19/2021 4:53 PM, Matthew Brost wrote:
On Thu, Aug 19, 2021 at 04:54:00PM -0700, Daniele Ceraolo Spurio wrote:
On 8/18/2021 11:16 PM, Matthew Brost wrote:
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmit
On 8/18/2021 11:16 PM, Matthew Brost wrote:
Don't drop ce->guc_active.lock when unwinding a context after reset.
At one point we had to drop this because of a lock inversion but that is
no longer the case. It is much safer to hold the lock so let's do that.
Fixes: eb5e7da736f3 ("drm/i915/guc:
On Thu, Aug 19, 2021 at 04:54:00PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > When unwinding requests on a reset context, if other requests in the
> > context are in the priority list the requests could be resubmitted out
> > of seqno order. Travers
On 8/18/2021 11:16 PM, Matthew Brost wrote:
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list to
Hi, Nancy:
Nancy.Lin 於 2021年8月18日 週三 下午5:18寫道：
>
> Add vdosys1 MERGE definition.
>
> Signed-off-by: Nancy.Lin
> ---
> .../devicetree/bindings/display/mediatek/mediatek,merge.yaml| 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/
Hi, Jason:
jason-jh.lin 於 2021年8月19日 週四 上午10:23寫道：
>
> DSC is designed for real-time systems with real-time compression,
> transmission, decompression and display.
> The DSC standard is a specification of the algorithms used for
> compressing and decompressing image display streams, including
> t
Hi, Jason:
jason-jh.lin 於 2021年8月19日 週四 上午10:24寫道：
>
> Adjust to the alphabetic order for the define, function, struct
> and array in mediatek-drm driver
>
> Signed-off-by: jason-jh.lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 133 ++--
> drivers/gpu/drm/mediatek/mt
On Wed, Aug 18, 2021 at 11:34:51AM +0200, Daniel Vetter wrote:
> On Wed, Aug 18, 2021 at 9:45 AM Gal Pressman wrote:
> >
> > Hey all,
> >
> > Currently, the RDMA subsystem can only work with dynamic dmabuf
> > attachments, which requires the RDMA device to support on-demand-paging
> > (ODP) which
On 7/26/2021 20:17, Matthew Brost wrote:
Like in the case of several other selftests, generating lots of requests
in a loop takes a bit longer with GuC submission. Increase a timeout in
i915_gem_contexts selftest to take this into account.
Signed-off-by: Matthew Brost
Reviewed-by: John Harriso
19.08.2021 20:03, Thierry Reding пишет:
> On Tue, Aug 17, 2021 at 04:27:40AM +0300, Dmitry Osipenko wrote:
>> The SDHCI on Tegra belongs to the core power domain and we're going to
>> enable GENPD support for the core domain. Now SDHCI must be resumed using
>> runtime PM API in order to initialize
On 8/17/21 11:43 AM, Raphael Gallais-Pou wrote:
On 7/2/21 8:07 PM, Marek Vasut wrote:
On 7/2/21 11:23 AM, Raphael Gallais-Pou wrote:
Hello Marek,
Hi,
Sorry for the late answer.
No worries, take your time
On 6/30/21 2:35 AM, Marek Vasut wrote:
On 6/29/21 1:58 PM, Raphael GALLAIS-POU -
19.08.2021 19:31, Thierry Reding пишет:
> Also, I don't think the tegra- prefix is necessary here. The parent node
> is already identified as Tegra via the compatible string.
>
> In the case of CAR, I'd imagine something like:
>
> clocks {
> sclk {
>
19.08.2021 19:54, Thierry Reding пишет:
> On Wed, Aug 18, 2021 at 08:11:03PM +0300, Dmitry Osipenko wrote:
>> 18.08.2021 19:42, Thierry Reding пишет:
>>> On Wed, Aug 18, 2021 at 06:05:21PM +0300, Dmitry Osipenko wrote:
18.08.2021 17:07, Thierry Reding пишет:
> On Tue, Aug 17, 2021 at 04:27
On Thu, Aug 19, 2021 at 5:12 AM Krzysztof Kozlowski
wrote:
>
> Use common enum instead of oneOf and correct indentation warning:
> realtek,rt1015p.yaml:18:7: [warning] wrong indentation: expected 4 but
> found 6 (indentation)
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> .../devicetree/bindi
On Mon, Aug 09, 2021 at 01:59:01PM -0500, Bjorn Helgaas wrote:
> On Tue, Aug 03, 2021 at 12:06:44PM -0500, Bjorn Helgaas wrote:
> > On Sat, Jul 24, 2021 at 05:30:02PM +0800, Huacai Chen wrote:
> > > On Sat, Jul 24, 2021 at 8:10 AM Bjorn Helgaas wrote:
> > > > Thanks for the above; that was helpfu
On Thu, Aug 19, 2021 at 02:31:51PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > A small race that could result in incorrect accounting of the number
> > of outstanding G2H. Basically prior to this patch we did not increment
> > the number of outstandi
On 8/18/2021 11:16 PM, Matthew Brost wrote:
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This was incorrect as the conte
On Thu, 19 Aug 2021 20:48:44 +0800, yangcong wrote:
> The auo,b101uan08.3 panel (already supported by this driver) has
> a 3.3V rail that needs to be turned on. For previous users of
> this panel this voltage was directly output by pmic. On a new
> user (the not-yet-upstream sc7180-trogdor-mrbland
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.
The "Board Parameters" members of the structs:
struct atom_smc_dpm_info_v4_5
struct atom_smc_dp
Am 2021-08-19 um 2:00 p.m. schrieb Sierra Guiza, Alejandro (Alex):
>
> On 8/18/2021 2:28 PM, Ralph Campbell wrote:
>> On 8/17/21 5:35 PM, Felix Kuehling wrote:
>>> Am 2021-08-17 um 8:01 p.m. schrieb Ralph Campbell:
On 8/12/21 11:31 PM, Alex Sierra wrote:
> From: Ralph Campbell
>
>
On Thu, Aug 19, 2021 at 10:33:43AM +0530, Lazar, Lijo wrote:
> On 8/19/2021 5:29 AM, Kees Cook wrote:
> > On Wed, Aug 18, 2021 at 05:12:28PM +0530, Lazar, Lijo wrote:
> > >
> > > On 8/18/2021 11:34 AM, Kees Cook wrote:
> > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time
On 8/19/21 11:33 AM, Tom Lendacky wrote:
There was some talk about this on the mailing list where TDX and SEV may
need to be differentiated, so we wanted to reserve a range of values per
technology. I guess I can remove them until they are actually needed.
In TDX also we have similar require
19.08.2021 16:07, Ulf Hansson пишет:
> On Wed, 18 Aug 2021 at 17:43, Dmitry Osipenko wrote:
>>
>> 18.08.2021 13:08, Ulf Hansson пишет:
>>> On Wed, 18 Aug 2021 at 11:50, Viresh Kumar wrote:
On 18-08-21, 11:41, Ulf Hansson wrote:
> On Wed, 18 Aug 2021 at 11:14, Viresh Kumar
> wr
On 8/19/21 4:55 AM, Christoph Hellwig wrote:
> On Fri, Aug 13, 2021 at 11:59:23AM -0500, Tom Lendacky wrote:
>> +static inline bool prot_guest_has(unsigned int attr)
>
> No reall need to have this inline. In fact I'd suggest we havea the
> prototype in a common header so that everyone must implem
On 8/19/21 4:52 AM, Christoph Hellwig wrote:
> On Fri, Aug 13, 2021 at 11:59:22AM -0500, Tom Lendacky wrote:
>> While the name suggests this is intended mainly for guests, it will
>> also be used for host memory encryption checks in place of sme_active().
>
> Which suggest that the name is not goo
On Thu, Aug 19, 2021 at 01:47:57PM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 19, 2021 at 09:19:08AM -0700, Kees Cook wrote:
> > On Thu, Aug 19, 2021 at 09:27:16AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Aug 17, 2021 at 11:05:26PM -0700, Kees Cook wrote:
> > > > In preparation for FORTIFY_SOUR
On Wed, Aug 18, 2021 at 01:20:54PM +0200, Heiko Carstens wrote:
> On Sat, Aug 14, 2021 at 02:46:27PM +0200, Heiko Carstens wrote:
> > Hello,
> >
> > I have Fedora 33 running, and with the Fedore kernel update from 5.11
> > series to 5.12 my external monitor was not detected anymore. Same is
> > tr
On 8/18/2021 2:28 PM, Ralph Campbell wrote:
On 8/17/21 5:35 PM, Felix Kuehling wrote:
Am 2021-08-17 um 8:01 p.m. schrieb Ralph Campbell:
On 8/12/21 11:31 PM, Alex Sierra wrote:
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that
complicates the
code for put_pag
On Wed, Aug 18, 2021 at 09:10:39PM +0300, Jani Nikula wrote:
> The DP 2.0 128b/132b channel coding uses TX FFE presets instead of
> vswing and pre-emphasis.
>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c
On Thu, Aug 19, 2021 at 10:52:53AM +0100, Christoph Hellwig wrote:
> Which suggest that the name is not good to start with. Maybe protected
> hardware, system or platform might be a better choice?
Yah, coming up with a proper name here hasn't been easy.
prot_guest_has() is not the first variant.
Hi Colin,
On Thu, Aug 19, 2021 at 02:38:39PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Don't populate the array ext_div on the stack but instead it
> static const. Makes the object code smaller by 118 bytes:
>
> Before:
>textdatabss dechex filename
> 39449 1750
On Fri, Aug 13, 2021 at 01:43:20PM +0300, Jani Nikula wrote:
> Extend the use of extended receiver cap at 0x2200 to cover
> MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides
> the DP 2.0 128b/132b channel encoding cap.
>
> Cc: Manasi Navare
> Signed-off-by: Jani Nikula
> --
Hi Maxime,
a few comments in the following that I hope you will find useful.
Sam
On Thu, Aug 19, 2021 at 03:44:53PM +0200, Maxime Ripard wrote:
> The drm_helper_hpd_irq_event() function is iterating over all the
> connectors when an hotplug event is detected.
>
> During that iteration,
On Tue, Aug 17, 2021 at 04:27:40AM +0300, Dmitry Osipenko wrote:
> The SDHCI on Tegra belongs to the core power domain and we're going to
> enable GENPD support for the core domain. Now SDHCI must be resumed using
> runtime PM API in order to initialize the SDHCI power state. The SDHCI
> clock rate
On Wed, Aug 18, 2021 at 08:11:03PM +0300, Dmitry Osipenko wrote:
> 18.08.2021 19:42, Thierry Reding пишет:
> > On Wed, Aug 18, 2021 at 06:05:21PM +0300, Dmitry Osipenko wrote:
> >> 18.08.2021 17:07, Thierry Reding пишет:
> >>> On Tue, Aug 17, 2021 at 04:27:27AM +0300, Dmitry Osipenko wrote:
> >>> [
On Wed, Aug 18, 2021 at 09:10:36PM +0300, Jani Nikula wrote:
> The bw code equals link_rate / 0.27 Gbps only for 8b/10b link
> rates. Handle DP 2.0 UHBR rates as special cases, though this is not
> pretty.
Ugh. So if I'm reading the spec right the behaviour of this
register now changes dynamically
On Thu, Aug 19, 2021 at 09:19:08AM -0700, Kees Cook wrote:
> On Thu, Aug 19, 2021 at 09:27:16AM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 17, 2021 at 11:05:26PM -0700, Kees Cook wrote:
> > > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > > field bounds checking for m
test upstream panel
Signed-off-by: yangcong
---
drivers/gpu/drm/panel/panel-truly-nt35597.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
b/drivers/gpu/drm/panel/panel-truly-nt35597.c
index b24b92d93ea5..e3cd37025c12 100644
--
On 8/19/21 4:46 AM, Christoph Hellwig wrote:
> On Fri, Aug 13, 2021 at 11:59:21AM -0500, Tom Lendacky wrote:
>> +#define PATTR_MEM_ENCRYPT 0 /* Encrypted memory */
>> +#define PATTR_HOST_MEM_ENCRYPT 1 /* Host encrypted
>> memory */
>> +#define PATTR_GUEST_MEM_ENC
On Wed, Aug 18, 2021 at 07:57:04PM +0300, Dmitry Osipenko wrote:
> 18.08.2021 19:39, Thierry Reding пишет:
> >> We don't have a platform device for CaR. I don't see how it's going to
> >> work. We need to create a platform device for each RPM-capable clock
> >> because that's how RPM works. The com
On Thu, Aug 19, 2021 at 04:19:37PM +0300, Kalle Valo wrote:
> Kees Cook writes:
>
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memset(), avoid intentionally writing across
> > neighboring fields.
> >
> > Use memset_startat() so memset()
On 19/08/2021 16:36, Robert Foss wrote:
Both PINGPONG4 and PINGPONG5 IRQ registers are using the
same address, which is incorrect. PINGPONG4 should use the
register offset 30, and PINGPONG5 should use the register
offset 31 according to the downstream driver.
Fixes: 667e9985ee24 ("drm/msm/dpu: r
On Thu, Aug 19, 2021 at 09:27:16AM -0300, Jason Gunthorpe wrote:
> On Tue, Aug 17, 2021 at 11:05:26PM -0700, Kees Cook wrote:
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memset(), avoid intentionally writing across
> > neighboring fields.
On Thu, Aug 19, 2021 at 04:04:50PM +0200, Ulf Hansson wrote:
> On Thu, 19 Aug 2021 at 15:21, Thierry Reding wrote:
> >
> > On Tue, Aug 17, 2021 at 04:27:39AM +0300, Dmitry Osipenko wrote:
> > > The PWM on Tegra belongs to the core power domain and we're going to
> > > enable GENPD support for the
On Thu, Aug 19, 2021 at 01:14:55AM +0800, Kai-Heng Feng wrote:
> Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
> fast+narrow link on eDP again and fall back to the old max strategy on
> failure"), the screen starts to have wobbly effect.
>
> Commit a5c936add6a2 ("drm/i915/dp
On 2021-08-19 5:30 a.m., Daniel Vetter wrote:
On Wed, Aug 18, 2021 at 10:51:00AM -0400, Andrey Grodzovsky wrote:
On 2021-08-18 10:42 a.m., Daniel Vetter wrote:
On Wed, Aug 18, 2021 at 10:36:32AM -0400, Andrey Grodzovsky wrote:
On 2021-08-18 10:32 a.m., Daniel Vetter wrote:
On Wed, Aug 18, 2
Hi, Jason:
jason-jh.lin 於 2021年8月19日 週四 上午10:23寫道：
>
> Add DISP_REG prefix for the define of register offset to
> make the difference from the define of register value.
>
Reviewed-by: Chun-Kuang Hu
> Signed-off-by: jason-jh.lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 57 +++
Hi, Jason:
jason-jh.lin 於 2021年8月19日 週四 上午10:23寫道：
>
> Remove the unsed define in mtk_drm_ddp_comp.c
Reviewed-by: Chun-Kuang Hu
>
> Signed-off-by: jason-jh.lin
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/
Hi, Jason:
jason-jh.lin 於 2021年8月19日 週四 上午10:23寫道：
>
> Add mtk-mutex support for mt8195 vdosys0.
>
> Signed-off-by: jason-jh.lin
> ---
> drivers/soc/mediatek/mtk-mutex.c | 98 +++-
> 1 file changed, 95 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/soc/mediat
On Thu, 2021-08-19 at 15:51 +0100, Colin Ian King wrote:
> it still makes sense for these kind of
> janitorial changes as it makes sense to constify arrays when they are
> read-only and making them static is sensible for const data.
I'm not disagreeing. Marking unmodifiable arrays as const is gen
Hi, Jason:
jason-jh.lin 於 2021年8月19日 週四 上午10:23寫道：
>
> 1. There are 2 mmsys, namely vdosys0 and vdosys1 in mt8195.
>Each of them is bound to a display pipeline, so add their
>definition in mtk-mmsys documentation with 2 compatibles.
>
> 2. Add description for power-domain property.
>
> Si
On Thu, 19 Aug 2021 at 08:17, Viresh Kumar wrote:
>
> On 18-08-21, 18:55, Dmitry Osipenko wrote:
> > 18.08.2021 12:41, Ulf Hansson пишет:
> >
> > Either way gives the equal result. The new callback allows to remove the
> > boilerplate dev_pm_opp_set_rate(clk_get_rate() code from the rpm-resume
> >
On 19/08/2021 15:40, Joe Perches wrote:
> On Thu, 2021-08-19 at 14:54 +0100, Colin Ian King wrote:
>> On 19/08/2021 14:51, Joe Perches wrote:
>>> On Thu, 2021-08-19 at 14:38 +0100, Colin King wrote:
From: Colin Ian King
Don't populate the array ext_div on the stack but instead it
>>
Quoting Zhenyu Wang (2021-08-19 11:29:29)
> On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > > Any updates on this? I'd really hate to miss this merge window.
> > >
> > > I'm still waiting for our validation team's report on this.
On Thu, 2021-08-19 at 14:54 +0100, Colin Ian King wrote:
> On 19/08/2021 14:51, Joe Perches wrote:
> > On Thu, 2021-08-19 at 14:38 +0100, Colin King wrote:
> > > From: Colin Ian King
> > >
> > > Don't populate the array ext_div on the stack but instead it
> > > static const. Makes the object code
On Thu, 19 Aug 2021 at 04:13, yunfei.d...@mediatek.com
wrote:
>
> Hi Ezequiel,
>
> Thanks for your suggestion.
>
> On Wed, 2021-08-18 at 11:11 -0300, Ezequiel Garcia wrote:
> > +danvet
> >
> > Hi,
> >
> > On Tue, 10 Aug 2021 at 23:58, Yunfei Dong
> > wrote:
> > >
> > > This series adds support fo
Commitc7d30623540b ("drm/vc4: hdmi: Remove unused struct") removed the
references to the vc4_hdmi_audio_widgets and vc4_hdmi_audio_routes
structures, but not the structures themselves resulting in two warnings.
Remove it.
Fixes: c7d30623540b ("drm/vc4: hdmi: Remove unused struct")
Reported-by: ker
On Thu, 19 Aug 2021 at 15:21, Thierry Reding wrote:
>
> On Tue, Aug 17, 2021 at 04:27:39AM +0300, Dmitry Osipenko wrote:
> > The PWM on Tegra belongs to the core power domain and we're going to
> > enable GENPD support for the core domain. Now PWM must be resumed using
> > runtime PM API in order
We've had many silent hangs where the kernel would look like it just
stalled due to the access to one of the HDMI registers while the
controller was disabled.
Add a warning if we're about to do that so that it's at least not silent
anymore.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripar
Similarly to what we encountered with the detect hook with DRM, nothing
actually prevents any of the CEC callback from being run while the HDMI
output is disabled.
However, this is an issue since any register access to the controller
when it's powered down will result in a silent hang.
Let's make
In order to ease further additions to the CEC enable and disable, let's
split the function into two functions, one to enable and the other to
disable.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 73 --
1 file chan
Since our pre_crtc_configure hook returned void, we didn't implement a
goto-based error path handling, leading to errors like failing to put
back the device in pm_runtime in all the error paths, but also failing
to disable the pixel clock if clk_set_min_rate on the HSM clock fails.
Move to a goto-
In the bind hook, we actually need the device to have the HSM clock
running during the final part of the display initialisation where we
reset the controller and initialise the CEC component.
Failing to do so will result in a complete, silent, hang of the CPU.
Fixes: 411efa18e4b0 ("drm/vc4: hdmi:
We already depend on runtime PM to get the power domains and clocks for
most of the devices supported by the vc4 driver, so let's just select it
to make sure it's there, and remove the ifdef.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/Kconfig| 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c |
Hi,
This series aims at fixing a complete and silent hang when one tries to use CEC
while the display output is off.
This can be tested with:
echo off > /sys/class/drm/card0-HDMI-A-1/status
cec-ctl --tuner -p 1.0.0.0
cec-compliance
This series addresses it by making sure the HDMI controller is
On 19/08/2021 14:51, Joe Perches wrote:
> On Thu, 2021-08-19 at 14:38 +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> Don't populate the array ext_div on the stack but instead it
>> static const. Makes the object code smaller by 118 bytes:
>>
>> Before:
>> textdatabss dec
On Thu, 2021-08-19 at 14:38 +0100, Colin King wrote:
> From: Colin Ian King
>
> Don't populate the array ext_div on the stack but instead it
> static const. Makes the object code smaller by 118 bytes:
>
> Before:
> textdatabss dechex filename
> 39449 17500128 57077
The drm_helper_hpd_irq_event() function is iterating over all the
connectors when an hotplug event is detected.
During that iteration, it will call each connector detect function and
figure out if its status changed.
Finally, if any connector changed, it will notify the user-space and the
clients
The drm_helper_hpd_irq_event() documentation states that this function
is "useful for drivers which can't or don't track hotplug interrupts for
each connector." and that "Drivers which support hotplug interrupts for
each connector individually and which have a more fine-grained detect
logic should
From: Colin Ian King
Don't populate the array ext_div on the stack but instead it
static const. Makes the object code smaller by 118 bytes:
Before:
textdatabss dechex filename
39449 17500128 57077 def5 ./drivers/gpu/drm/bridge/tc358767.o
After:
textdata
Both PINGPONG4 and PINGPONG5 IRQ registers are using the
same address, which is incorrect. PINGPONG4 should use the
register offset 30, and PINGPONG5 should use the register
offset 31 according to the downstream driver.
Fixes: 667e9985ee24 ("drm/msm/dpu: replace IRQ lookup with the data in hw
cat
On Tue, Aug 17, 2021 at 04:27:39AM +0300, Dmitry Osipenko wrote:
> The PWM on Tegra belongs to the core power domain and we're going to
> enable GENPD support for the core domain. Now PWM must be resumed using
> runtime PM API in order to initialize the PWM power state. The PWM clock
> rate must be
On Wed, 18 Aug 2021 at 17:43, Dmitry Osipenko wrote:
>
> 18.08.2021 13:08, Ulf Hansson пишет:
> > On Wed, 18 Aug 2021 at 11:50, Viresh Kumar wrote:
> >>
> >> On 18-08-21, 11:41, Ulf Hansson wrote:
> >>> On Wed, 18 Aug 2021 at 11:14, Viresh Kumar
> >>> wrote:
> What we need here is just con
On Thu, 19 Aug 2021 17:29:43 +0800, yangcong wrote:
> The auo,b101uan08.3 panel (already supported by this driver) has
> a 3.3V rail that needs to be turned on. For previous users of
> this panel this voltage was directly output by pmic. On a new
> user (the not-yet-upstream sc7180-trogdor-mrbland
On Tue, Aug 17, 2021 at 11:05:26PM -0700, Kees Cook wrote:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memset(), avoid intentionally writing across
> neighboring fields.
>
> Add struct_group() to mark region of struct mlx5_ib_mr that should
On 8/19/21 11:34 AM, Matthew Auld wrote:
This should give a more complete view of the various bits of internal
resource manager state, for device local-memory.
v2(Thomas):
- Move the region printing into a nice helper
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
For the series (2/
Commit 55b68fb856b5 ("drm/omap: squash omapdrm sub-modules into one")
removes the config OMAP2_DSS in ./drivers/gpu/drm/omapdrm/dss/Kconfig,
while moving the other configs into./drivers/gpu/drm/omapdrm/Kconfig, but
misses to remove an obsolete selection of OMAP2_DSS in config DRM_OMAP.
Hence, ./sc
Commit 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D
V3.x+") adds the config DRM_V3D, which depends on "ARCH_BCMSTB".
Although, a bit confusing: all Broadcom architectures in
./arch/arm/mach-bcm/Kconfig have the prefix "ARCH_BCM", except for
ARCH_BRCMSTB, i.e., the config for
Commit 89d4f98ae90d ("ARM: remove zte zx platform") removes the config
ARCH_ZX. So, since then, the DRM Support for ZTE SoCs (config DRM_ZTE)
depends on this removed config ARCH_ZX and cannot be selected.
Fortunately, ./scripts/checkkconfigsymbols.py detects this and warns:
ARCH_ZX
Referencing fi
commit 1f0f01515172 ("drm/rockchip: Add support for Rockchip Soc RGB
output interface") accidently adds to select the non-existing config
DRM_RGB in ./drivers/gpu/drm/rockchip/Kconfig.
Luckily, ./scripts/checkkconfigsymbols.py warns on non-existing configs:
DRM_RGB
Referencing files: drivers/gpu/
Commit 04ed8459f334 ("drm/amdgpu: remove chash") removes the chash
architecture and its corresponding config CHASH.
There is still a reference to CHASH in the config DRM_AMDGPU in
./drivers/gpu/drm/Kconfig.
Remove this obsolete reference to config CHASH.
Signed-off-by: Lukas Bulwahn
---
driver
Dear DRM maintainers,
The script ./scripts/checkkconfigsymbols.py warns on invalid references to
Kconfig symbols (often, minor typos, name confusions or outdated references).
This patch series addresses all issues reported by
./scripts/checkkconfigsymbols.py
in ./drivers/gpu/ for Kconfig and Mak
On Thu, Aug 19, 2021 at 12:53 PM Desmond Cheong Zhi Xi
wrote:
>
> On 18/8/21 7:02 pm, Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 03:38:22PM +0800, Desmond Cheong Zhi Xi wrote:
> >> In a future patch, a read lock on drm_device.master_rwsem is
> >> held in the ioctl handler before the check fo
On 18/8/21 7:02 pm, Daniel Vetter wrote:
On Wed, Aug 18, 2021 at 03:38:22PM +0800, Desmond Cheong Zhi Xi wrote:
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this produces the following lockdep splat:
[AMD Official Use Only]
Hi Daniel
>> Why can't we stop the scheduler thread first, so that there's guaranteed no
>> race? I've recently had a lot of discussions with panfrost folks about their
>> reset that spawns across engines, and without stopping the scheduler thread
>> first before you to
Use common enum instead of oneOf and correct indentation warning:
realtek,rt1015p.yaml:18:7: [warning] wrong indentation: expected 4 but found
6 (indentation)
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/sound/realtek,rt1015p.yaml | 6 +++---
1 file changed, 3 inser
Correct indentation warning:
ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but found
8 (indentation)
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/display/panel/ilitek,ili9341.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a
On Thu, 22 Jul 2021, Daniel Thompson wrote:
> Currently there are (at least) two problems in the way pwm_bl starts
> managing the enable_gpio pin. Both occur when the backlight is initially
> off and the driver finds the pin not already in output mode and, as a
> result, unconditionally switches i
Depending on a given HVS output (HVS to PixelValves) and input (planes
attached to a channel) load, the HVS needs for the core clock to be
raised above its boot time default.
Failing to do so will result in a vblank timeout and a stalled display
pipeline.
Signed-off-by: Maxime Ripard
---
driver
1 - 100 of 126 matches
Mail list logo
