On 26/03/2021 23:48, abhin...@codeaurora.org wrote:
Hi Dmitry
On 2021-03-26 13:36, Dmitry Baryshkov wrote:
On 26/03/2021 21:05, abhin...@codeaurora.org wrote:
Hi Dmitry
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
There is no reason to set clock parents manually, use device tree to
assign DS
On Fri, Mar 26, 2021 at 5:33 PM Rob Clark wrote:
>
> On Fri, Mar 26, 2021 at 4:48 PM Rob Herring wrote:
> >
> > On Fri, Mar 26, 2021 at 4:13 PM Rob Clark wrote:
> > >
> > > On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
> > > >
> > > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
> >
On Fri, Mar 26, 2021 at 4:48 PM Rob Herring wrote:
>
> On Fri, Mar 26, 2021 at 4:13 PM Rob Clark wrote:
> >
> > On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
> > >
> > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
> > > >
> > > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
> >
From: Jeremy Cline
Start on documentation for the Nouveau device structure and the NVIF
client structure it uses. This documentation is not complete as the
structures are non-trivial and I am not familiar with large portions of
them.
Signed-off-by: Jeremy Cline
Signed-off-by: Lyude Paul
---
d
From: Jeremy Cline
In order to use the resource-managed allocation of a struct drm_device
instance, it is recommended to embed the drm_device instance within the
driver-specific structure.
As there is already a helper to convert a drm_device to a nouveau_drm
struct, this adds an inverse function
From: Jeremy Cline
Make use of the devm_drm_dev_alloc() API to bind the lifetime of
nouveau_drm structure to the drm_device. This is important because a
reference to nouveau_drm is accessible from drm_device, which is
provided to a number of DRM layer callbacks that can run after the
deallocation
On Fri, Mar 26, 2021 at 4:13 PM Rob Clark wrote:
>
> On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
> >
> > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
> > >
> > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
> > > >
> > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding
> > > >
This enables the adreno-specific SMMU path that sets HUPCF so
(user-managed) page faults don't wedge the GPU.
Signed-off-by: Eric Anholt
---
We've been seeing a flaky test per day or so in Mesa CI where the
kernel gets wedged after an iommu fault turns into CP errors. With
this patch, the CI is
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
Signed-off-by: Eric Anholt
---
We've b
Hi Rob,
On Fri, 26 Mar 2021 15:01:34 -0600 Rob Herring wrote:
>
> On Tue, Feb 23, 2021 at 2:26 PM Rob Herring wrote:
> >
> > On Thu, 18 Feb 2021 16:28:37 +0100, Maxime Ripard wrote:
> > > For some reason, unevaluatedProperties doesn't work and
> > > additionalProperties is required. Fix it by
26.03.2021 22:10, Mikko Perttunen пишет:
> On 3/26/21 8:31 PM, Dmitry Osipenko wrote:
>> 26.03.2021 17:54, Mikko Perttunen пишет:
>>>
>>> Lockdep doesn't seem to be liking dev_name() for the name, and I think
>>> allocating a string for this purpose seems a bit overkill, so I'll keep
>>> the lock n
On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote:
>
> On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
> >
> > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
> > >
> > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding
> > > wrote:
> > > >
> > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Ro
This patch series is:
Reviewed-by: Lyude Paul
Btw - in the future if you need to send a respin of multiple patches, you need
to send it as it's own separate series instead of replying to the previous one
(one-off respins can just be posted as replies though), otherwise patchwork
won't pick it up
Reviewed-by: Lyude Paul
On Wed, 2020-12-02 at 19:02 -0500, Jeremy Cline wrote:
> nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code
> back to the caller. On failures, ttm_bo_init() invokes the provided
> destructor which should de-initialize and free the memory.
>
> Thus, w
On Mon, Mar 22, 2021 at 07:50:31PM +0100, Daniel Mack wrote:
> This adds documentation for a new ILI9163 based, SPI connected display.
>
> Signed-off-by: Daniel Mack
> ---
> .../bindings/display/ilitek,ili9163.yaml | 70 +++
As this is panel chip, put it in panel/.
> 1 fil
pushed! thanks for the patch
On Thu, 2021-03-25 at 14:06 -0400, Eryk Brol wrote:
> [why]
> MST topology print was missing fec logging and pdt printed
> as an int wasn't clear. vcpi and payload info was printed as an
> arbitrary series of ints which requires user to know the ordering
> of the print
On Tue, Feb 23, 2021 at 2:26 PM Rob Herring wrote:
>
> On Thu, 18 Feb 2021 16:28:37 +0100, Maxime Ripard wrote:
> > For some reason, unevaluatedProperties doesn't work and
> > additionalProperties is required. Fix it by switching to
> > additionalProperties.
> >
> > Signed-off-by: Maxime Ripard
>
Hi Dmitry
On 2021-03-26 13:36, Dmitry Baryshkov wrote:
On 26/03/2021 21:05, abhin...@codeaurora.org wrote:
Hi Dmitry
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
There is no reason to set clock parents manually, use device tree to
assign DSI/display clock parents to DSI PHY clocks. Dropping t
And finally, convert all of the code in drm_dp_mst_topology.c over to using
drm_err() and drm_dbg*(). Note that this refactor would have been a lot
more complicated to have tried writing a coccinelle script for, so this
whole thing was done by hand.
v2:
* Fix line-wrapping in drm_dp_mst_atomic_che
Next step in the conversion, move everything in drm_dp_dual_mode_helper.c
over to using drm_err() and drm_dbg_kms(). This was done using the
following cocci script:
@@
expression list expr;
@@
(
- DRM_DEBUG_KMS(expr);
+ drm_dbg_kms(dev, expr);
|
- DRM_ERROR(expr);
+ drm_err(dev,
Checkpatch was complaining about this - there's no need for us to print
errors when kzalloc() fails, as kzalloc() will already WARN for us. So,
let's fix that before converting things to make checkpatch happy.
Signed-off-by: Lyude Paul
Cc: Robert Foss
---
drivers/gpu/drm/drm_dp_mst_topology.c |
Since this is one of the few functions in drm_dp_mst_topology.c that
doesn't have any way of getting access to a drm_device, let's pass the
drm_dp_mst_topology_mgr down to this function so that it can use
drm_dbg_kms().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c |
Now that we've added a back-pointer to drm_device to drm_dp_aux, made
drm_dp_aux available to any functions in drm_dp_helper.c which need to
print to the kernel log, and ensured all of our logging uses a consistent
format, let's do the final step of the conversion and actually move
everything over
Another function to pass drm_device * down to so we can start using the
drm_dbg_*() in the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff -
So that we can start using drm_dbg_*() throughout the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +---
drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++-
include/drm/drm_dp_dual_mode_helper.h | 4 ++--
3 files changed, 14
Another function we need to pass drm_device down to in order to start using
drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4 inserti
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll
need to be able to access the DRM device in the dual mode DP helpers as
well. Note however that since drm_dp_dual_mode_detect() can be called with
DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down
th
Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to using drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
include/drm/drm_dp_dual_mode_helpe
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_help
Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want
to make sure that we can also add ratelimited versions of these macros in
order to retain some of the previous debugging output behavior we had.
However, as I was preparing to do this I noticed that the current
rate limited
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display b
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for d
As pointed out by the documentation for drm_dp_aux_register(),
drm_dp_aux_init() should be used in situations where the AUX channel for a
display driver can potentially be registered before it's respective DRM
driver. This is the case with Tegra, since the DP aux channel exists as a
platform device
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 26 ++---
1 file changed, 18 insertions(+), 8 deletions(-)
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/br
* Make sure that struct members are referred to using @, otherwise they
won't be formatted as such
* Make sure to refer to other struct types using & so they link back to
each struct's definition
* Make sure to precede constant values with % so they're formatted
correctly
Signed-off-by: Lyud
Since it's been asked quite a few times on some of the various DP
related patch series I've submitted to use the new DRM printk helpers,
and it technically wasn't really trivial to do this before due to the
lack of a consistent way to find a drm_device for an AUX channel, this
patch series aims to
On 26/03/2021 21:05, abhin...@codeaurora.org wrote:
Hi Dmitry
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
There is no reason to set clock parents manually, use device tree to
assign DSI/display clock parents to DSI PHY clocks. Dropping this manual
setup allows us to drop repeating code and to
https://bugzilla.kernel.org/show_bug.cgi?id=212077
--- Comment #14 from Bat Malin (bat_ma...@abv.bg) ---
Thank you Alex for your engagement! Could you please include the patch in the
next 5.11.11 release so I could test the patch, sorry but I am not allowed to
compile a kernel on this machine.
--
Nevermind, I think I screwed this up locally.
Alex
On Fri, Mar 26, 2021 at 4:07 PM Alex Deucher wrote:
>
> Looks like this got accidently dropped.
>
> Fixes: 2cbcb78c9ee5 ("Merge tag 'amd-drm-next-5.13-2021-03-23' of
> https://gitlab.freedesktop.org/agd5f/linux into drm-next")
> Signed-off-by:
Looks like this got accidently dropped.
Fixes: 2cbcb78c9ee5 ("Merge tag 'amd-drm-next-5.13-2021-03-23' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next")
Signed-off-by: Alex Deucher
Cc: daniel.vet...@ffwll.ch
---
drivers/gpu/drm/amd/display/dc/irq/dcn21/irq_service_dcn21.c | 4
On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote:
>
> On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
> >
> > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding
> > wrote:
> > >
> > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote:
> > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlck
Am 2021-03-26 um 5:38 a.m. schrieb Qu Huang:
> On 2021/1/28 5:50, Felix Kuehling wrote:
>> Am 2021-01-27 um 7:33 a.m. schrieb Qu Huang:
>>> Amdgpu driver uses 4-byte data type as DQM fence memory,
>>> and transmits GPU address of fence memory to microcode
>>> through query status PM4 message. Howev
[AMD Public Use]
On Thu, Feb 18, 2021 at 11:15 PM Alex Deucher wrote:
>>
>> Hi Dave, Daniel,
>>
>> Fixes for 5.12.
>>
>> The following changes since commit 4c3a3292730c56591472717d8c5c0faf74f6c6bb:
>>
>> drm/amd/display: fix unused variable warning (2021-02-05 09:49:44
>> +1000)
>>
>> are avai
On 3/26/21 8:31 PM, Dmitry Osipenko wrote:
26.03.2021 17:54, Mikko Perttunen пишет:
Lockdep doesn't seem to be liking dev_name() for the name, and I think
allocating a string for this purpose seems a bit overkill, so I'll keep
the lock name as is if there are no objections.
What does "liking"
The pull request you sent on Fri, 26 Mar 2021 13:34:03 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-03-26
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f944d061f847b0ccf0ebc095b5a6ba9ea9caec4e
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
26.03.2021 17:54, Mikko Perttunen пишет:
>
> Lockdep doesn't seem to be liking dev_name() for the name, and I think
> allocating a string for this purpose seems a bit overkill, so I'll keep
> the lock name as is if there are no objections.
What does "liking" mean?
[AMD Official Use Only - Internal Distribution Only]
Hi Lyude,
Yes, I would appreciate it if you could push this to drm-misc-next for me.
Thank you for your comments and review!
Best,
Eryk
From: Lyude Paul
Sent: Thursday, March 25, 2021 6:30 PM
To: Brol, Eryk ;
On Thu, Feb 18, 2021 at 11:15 PM Alex Deucher wrote:
>
> Hi Dave, Daniel,
>
> Fixes for 5.12.
>
> The following changes since commit 4c3a3292730c56591472717d8c5c0faf74f6c6bb:
>
> drm/amd/display: fix unused variable warning (2021-02-05 09:49:44 +1000)
>
> are available in the Git repository at:
Hi Dmitry
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
There is no reason to set clock parents manually, use device tree to
assign DSI/display clock parents to DSI PHY clocks. Dropping this
manual
setup allows us to drop repeating code and to move registration of hw
clock providers to generic
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
msm_dsi_pll_set_usecase() function is not used outside of individual
DSI
PHY drivers, so drop it in favour of calling the the respective
set_usecase functions directly.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/d
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 3 +++
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 6 --
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 6 --
driv
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
With the current upstream driver the msm_dsi_phy_type enum does not
make
much sense: all DSI PHYs are probed using the dt bindings, the phy type
is not passed between drivers. Use quirks in phy individual PHY drivers
to differentiate minor harware dif
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
DSI PHY init callback would either map dsi_phy_regulator or
dsi_phy_lane
depending on the PHY type. Replace those callbacks with configuration
options governing mapping those regions.
Signed-off-by: Dmitry Baryshkov
This is a nice cleanup which wil
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
Move all PLL-related callbacks into struct msm_dsi_phy_cfg. This limits
the amount of data in the struct msm_dsi_pll.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi.h | 6 --
drivers/gp
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
Add devm_clk_hw_register_divider() - devres version of
clk_hw_register_divider().
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
include/linux/clk-provider.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/i
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
Add devm_clk_hw_register_mux() - devres-managed version of
clk_hw_register_mux().
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/clk/clk-mux.c| 35 +++
include/linux/clk-provider.h |
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
The only PLL using multiple enable sequences is the 28nm PLL, which
just
does the single step in the loop. Push that support back into the PLL
code.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/phy/dsi_p
Hi Dmitry
On 2021-03-24 08:18, Dmitry Baryshkov wrote:
From: Daniel Palmer
Add a devm helper for clk_hw_register_fixed_factor() so that drivers
that internally
register fixed factor clocks for things like dividers don't need to
manually unregister
them on remove or if probe fails.
Signed-off-
On Fri 26 Mar 10:24 CDT 2021, Rob Clark wrote:
> On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
> >
> > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding
> > wrote:
> > >
> > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote:
> > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke
On Thu, 2021-03-25 at 23:14 -0400, Fangzhi Zuo wrote:
> 8b/10b encoding format requires to reserve the first slot for
> recording metadata. Real data transmission starts from the second slot,
> with a total of available 63 slots available.
>
> In 128b/132b encoding format, metadata is transmitted
On Wed, Mar 24, 2021 at 07:50:01PM +0300, Dmitry Osipenko wrote:
> 24.03.2021 19:42, Thierry Reding пишет:
> > On Wed, Mar 24, 2021 at 06:45:30PM +0300, Dmitry Osipenko wrote:
> >> 24.03.2021 18:02, Thierry Reding пишет:
> >>> On Wed, Mar 24, 2021 at 05:41:08PM +0300, Dmitry Osipenko wrote:
>
On Fri, Mar 26, 2021 at 02:54:22PM +, Simon Ser wrote:
> LGTM, thanks!
>
> Reviewed-by: Simon Ser
>
> Let me know if you need me to push this to drm-misc-next.
I do have commit access for drm-misc-next, but I was thinking that I
could take this through the drm/tegra tree along with the subs
On Thu, Mar 25, 2021 at 03:01:29PM -0700, Navare, Manasi wrote:
> On Fri, Mar 19, 2021 at 11:27:59PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 19, 2021 at 02:26:24PM -0700, Navare, Manasi wrote:
> > > On Fri, Mar 19, 2021 at 11:12:41PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Mar 19, 2021 at 0
26.03.2021 17:51, Thierry Reding пишет:
> From: Thierry Reding
>
> The hardware cursor on Tegra186 differs slightly from the implementation
> on older SoC generations. In particular the new implementation relies on
> software for clipping the cursor against the screen. Fortunately, atomic
> KMS a
On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote:
>
> On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding
> wrote:
> >
> > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote:
> > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke
> > > wrote:
> > > >
> > > > On Tue, Mar 16, 2021 at 02:08:19P
On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding wrote:
>
> On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote:
> > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke wrote:
> > >
> > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote:
> > > > The sc7180-trogdor-pompom board m
Hi,
On Fri, Mar 26, 2021 at 11:47:58AM +0200, Jani Nikula wrote:
> On Tue, 23 Mar 2021, Ankit Nautiyal wrote:
> > Currently the FRL training mode (Concurrent, Sequential) and
> > training type (Normal, Extended) are not defined properly and
> > are passed as bool values in drm_helpers for pcon
>
On 2021-03-24 4:23 p.m., Alex Deucher wrote:
On Wed, Mar 17, 2021 at 11:25 AM Werner Sembach
wrote:
When encoder validation of a display mode fails, retry with less bandwidth
heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
to support 4k60Hz output, which previous
On 3/22/21 5:19 PM, Mikko Perttunen wrote:
On 22.3.2021 16.48, Dmitry Osipenko wrote:
22.03.2021 17:46, Thierry Reding пишет:
On Mon, Jan 11, 2021 at 02:59:59PM +0200, Mikko Perttunen wrote:
To avoid false lockdep warnings, give each client lock a different
lock class, passed from the initiali
LGTM, thanks!
Reviewed-by: Simon Ser
Let me know if you need me to push this to drm-misc-next.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Thierry Reding
Clarify when a fixed IOV address can be used and when a buffer has to
be mapped before the IOVA can be used.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/plane.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/
From: Thierry Reding
Tegra194 has a special physical address bit that enables some memory
swizzling logic to support different sector layouts. Support the bit
that selects the sector layout which is passed in the framebuffer
modifier.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.
From: Thierry Reding
In order to be able to attach planes to all possible display controllers
the exact number of CRTCs must be known. Keep track of the number of the
display controllers that register during initialization.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 22 +++
From: Thierry Reding
Add a debug message to let the user know when a framebuffer modifier is
not supported.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 01939c57fc7
From: Thierry Reding
These callbacks can be used by client drivers to run code during early
init and during late exit. Early init callbacks are run prior to the
regular init callbacks while late exit callbacks run after the regular
exit callbacks.
Signed-off-by: Thierry Reding
---
drivers/gpu/
From: Thierry Reding
The hardware cursor on Tegra186 differs slightly from the implementation
on older SoC generations. In particular the new implementation relies on
software for clipping the cursor against the screen. Fortunately, atomic
KMS already computes clipped coordinates for (cursor) pla
From: Thierry Reding
Tegra186 and later support a higher maximum resolution than earlier
chips, so make sure to reflect that in the mode configuration.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dc.c | 6 ++
drivers/gpu/drm/tegra/drm.c | 13 ++---
drivers/gpu/drm/teg
From: Thierry Reding
Inherit the DMA mask from host1x (on Tegra210 and earlier) or the
display hub (on Tegra186 and later). This is necessary in order to
properly map buffers without SMMU support and use the maximum IOVA
space available with SMMU support.
Signed-off-by: Thierry Reding
---
driv
From: Thierry Reding
Rather than open-coding the vendor extraction operation, use the newly
introduced helper macro.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/arm/malidp_planes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/
Hi Monk,
I can't disagree more.
The fundamental problem here is that we have pushed a design without
validating if it really fits into the concepts the Linux kernel mandates
here.
My mistake was that I haven't pushed back hard enough on the initial
design resulting in numerous cycles of try
From: Thierry Reding
When working with framebuffer modifiers, it can be useful to extract the
vendor identifier or check a modifier against a given vendor identifier.
Add one macro that extracts the vendor identifier and a helper to check
a modifier against a given vendor identifier.
v2: add mac
From: Thierry Reding
Hi,
this fixes a couple of oddities like slightly off DMA masks and add
support for hardware cursors on newer chips as well as support for the
sector layout bit in NVIDIA framebuffer modifiers.
The first patch in this set is a small helper that I think might be
useful to ot
Pushed:
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=3aa6031deefa9a2c056af2182af02d3dc5df1067
On Fri, 26 Mar 2021 at 13:20, Adrien Grassein wrote:
>
> Hi,
> this patch set adds the support of the Lontium lt8912 MIPI to HDMI
> bridge in the kernel.
>
> It's only support the video part, no
Hi Kieran,
On Mon, Mar 22, 2021 at 04:35:34PM +, Kieran Bingham wrote:
> Create rcar_du_group_atomic_check() and rcar_du_group_atomic_setup()
> functions to track and apply group state through the DRM atomic state.
> The use_count field is moved from the rcar_du_group structure to an
> enabled
And demote non-conformant header
Fixes the following W=1 kernel build warning(s):
drivers/hid/intel-ish-hid/ishtp-fw-loader.c:46: warning: Enum value
'LOADER_CMD_XFER_QUERY' not described in enum 'ish_loader_commands'
drivers/hid/intel-ish-hid/ishtp-fw-loader.c:46: warning: Enum value
'LOADER
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
[RESEND] contains no functional changes. Only 18 of 25 patches
actually made it to the list during the first attempt.
Lee Jones (25):
HID: intel
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Lee Jones (25):
HID: intel-ish-hid: Remove unused variable 'err'
HID: ishtp-hid-client: Move variable to where it's actually used
HID: intel-i
On 3/23/21 12:16 PM, Thierry Reding wrote:
On Mon, Jan 11, 2021 at 03:00:01PM +0200, Mikko Perttunen wrote:
Show the number of pending waiters in the debugfs status file.
This is useful for testing to verify that waiters do not leak
or accumulate incorrectly.
Signed-off-by: Mikko Perttunen
---
On Fri, 26 Mar 2021, Lee Jones wrote:
> On Fri, 26 Mar 2021, Jonathan Cameron wrote:
>
> > On Wed, 24 Mar 2021 17:33:39 +
> > Lee Jones wrote:
> >
> > > This set is part of a larger effort attempting to clean-up W=1
> > > kernel builds, which are currently overwhelmingly riddled with
> > >
On Fri, 26 Mar 2021, Jonathan Cameron wrote:
> On Wed, 24 Mar 2021 17:33:39 +
> Lee Jones wrote:
>
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
>
> Lee, it's a bit novel to c
On Fri, Mar 26, 2021 at 2:31 PM Jani Nikula wrote:
>
> On Fri, 26 Mar 2021, Daniel Vetter wrote:
> > The rough plan we discussed somewhat ad-hoc with Jani&Rodrigo (Joonas was
> > out this week, but back next) is that they send out a pull with what's
> > there right now. Then once both this branch
On Fri, Mar 26, 2021 at 10:09:30PM +0800, Carlis wrote:
> From: "carlis.zhang_cp"
>
> Change '16 bit' to '16-bit' for a same style.
Why? This is up to the author.
>
> Signed-off-by: carlis.zhang_cp
Please use a real name, not an email-alias as a name.
thanks,
greg k-h
From: "carlis.zhang_cp"
Change '16 bit' to '16-bit' for a same style.
Signed-off-by: carlis.zhang_cp
---
drivers/staging/fbtft/fbtft-bus.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c
b/drivers/staging/fbtft/fbtft-bus.c
index 63c6
On Fri, 26 Mar 2021, Daniel Vetter wrote:
> The rough plan we discussed somewhat ad-hoc with Jani&Rodrigo (Joonas was
> out this week, but back next) is that they send out a pull with what's
> there right now. Then once both this branch here and the -gt-next pull are
> in drm-next they will backme
https://bugzilla.kernel.org/show_bug.cgi?id=212449
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
While testing support for large (> 256 bytes) EDIDs on the Renesas
Koelsch board I noticed that the adv7511 bridge driver only read the
first two blocks.
The media V4L2 version for the adv7511 (drivers/media/i2c/adv7511-v4l2.c)
handled this correctly.
Besides a simple bug when setting the segment
Hi Dave,
topic/i915-gem-next-2021-03-26:
special i915-gem-next pull as requested
- Conversion to dma_resv_locking, obj->mm.lock is gone (Maarten, with
help from Thomas Hellström)
- watchdog (Tvrtko, one patch to cancel individual request from Chris)
- legacy ioctl cleanup (Jason+Ashutosh)
- i91
1 - 100 of 138 matches
Mail list logo
