Felix need to comment as well, but I don't think that this will work
that easily.
By changing the entry from 1 to 0 your are also changing the size of the
structure.
Regards,
Christian.
Am 18.02.22 um 04:09 schrieb cgel@gmail.com:
From: Changcheng Deng
There is a regular need in the
Am 18.02.22 um 04:08 schrieb Qiang Yu:
On Thu, Feb 17, 2022 at 8:22 PM Christian König
wrote:
Am 17.02.22 um 11:58 schrieb Qiang Yu:
On Thu, Feb 17, 2022 at 6:39 PM Christian König
wrote:
Am 17.02.22 um 11:13 schrieb Qiang Yu:
On Thu, Feb 17, 2022 at 5:46 PM Christian König
wrote:
Am
Hello David Yat Sin,
The patch 42c6c48214b7: "drm/amdkfd: CRIU checkpoint and restore
queue mqds" from Jan 25, 2021, leads to the following Smatch static
checker warning:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_mqd_manager_v9.c:344
restore_mqd()
error: 'ctl_stack_size' from
innolux,n140hca-eac is a eDP-based LCD panel. This panel has 1920x1080
resolution in 14-inch TFT panel.
Signed-off-by: Rex Nie
---
.../display/panel/innolux,n140hca-eac.yaml| 43 +++
drivers/gpu/drm/panel/panel-edp.c | 26 +++
2 files changed, 69
On Thu 17 Feb 17:03 PST 2022, Doug Anderson wrote:
> Hi,
>
> On Thu, Feb 10, 2022 at 3:58 AM Sankeerth Billakanti
> wrote:
> >
> > + backlight_3v3_regulator: backlight-3v3-regulator {
> > + compatible = "regulator-fixed";
> > + regulator-name =
On Tue, Feb 01, 2022 at 04:11:22PM +0530, Ramalingam C wrote:
Details of the 64k pagesize support added as part of DG2 enabling and its
implicit impact on the uAPI.
v2: improvised the Flat-CCS documentation [Danvet & CQ]
v3: made only for 64k pagesize support
Signed-off-by: Ramalingam C
cc:
Robert Beckett writes:
> From: Matthew Auld
>
> On discrete platforms like DG2, we need to support a minimum page size
> of 64K when dealing with device local-memory. This is quite tricky for
> various reasons, so try to document the new implicit uapi for this.
>
> v3: fix typos and less
On Thu, Feb 17, 2022 at 12:00:05PM -0500, Steven Rostedt wrote:
>
> I personally believe that there's potential that this can be helpful and we
> will want to merge it.
>
> But, what I believe Ted is trying to say is, if you do not know if the
> report is a bug or not, please do not ask the
On Thu 17 Feb 19:10 CST 2022, Dmitry Baryshkov wrote:
> On 16/02/2022 05:16, Abhinav Kumar wrote:
> >
> >
> > On 2/15/2022 6:03 PM, Bjorn Andersson wrote:
> > > On Tue 15 Feb 19:34 CST 2022, Abhinav Kumar wrote:
> > >
> > > >
> > > >
> > > > On 2/15/2022 4:20 PM, Dmitry Baryshkov wrote:
> >
Hi Sascha:
On 2/17/22 22:06, Heiko Stübner wrote:
Am Donnerstag, 17. Februar 2022, 14:58:23 CET schrieb Sascha Hauer:
Hi Andy,
Please trim the context in your answers to the relevant parts, it makes
it easier to find the things you said.
On Thu, Feb 17, 2022 at 08:00:11PM +0800, Andy Yan
Hi Tvrtko,
>
> On 17/02/2022 07:50, Vivek Kasireddy wrote:
> > While looking for next holes suitable for an allocation, although,
> > it is highly unlikely, make sure that the DECLARE_NEXT_HOLE_ADDR
> > macro is using a valid node before it extracts the rb_node from it.
>
> Was the need for
From: Changcheng Deng
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use "flexible array members" for these cases. The older
style of one-element or zero-length arrays should no
On Thu, Feb 17, 2022 at 8:22 PM Christian König
wrote:
>
> Am 17.02.22 um 11:58 schrieb Qiang Yu:
> > On Thu, Feb 17, 2022 at 6:39 PM Christian König
> > wrote:
> >>
> >>
> >> Am 17.02.22 um 11:13 schrieb Qiang Yu:
> >>> On Thu, Feb 17, 2022 at 5:46 PM Christian König
> >>> wrote:
> Am
On 16/02/2022 05:16, Abhinav Kumar wrote:
On 2/15/2022 6:03 PM, Bjorn Andersson wrote:
On Tue 15 Feb 19:34 CST 2022, Abhinav Kumar wrote:
On 2/15/2022 4:20 PM, Dmitry Baryshkov wrote:
On Tue, 15 Feb 2022 at 23:21, Abhinav Kumar
wrote:
On 2/15/2022 10:42 AM, Dmitry Baryshkov wrote:
On
Felix Kuehling writes:
> Am 2022-02-16 um 07:26 schrieb Jason Gunthorpe:
>> The other place that needs careful audit is all the callers using
>> vm_normal_page() - they must all be able to accept a ZONE_DEVICE page
>> if we don't set pte_devmap.
>
> How much code are we talking about here? A
Hi,
On Thu, Feb 10, 2022 at 3:58 AM Sankeerth Billakanti
wrote:
>
> + backlight_3v3_regulator: backlight-3v3-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "backlight_3v3_regulator";
> +
> + regulator-min-microvolt =
Implement .atomic_check callback which prevents user space from setting
unsupported mode. The tc_edp_common_atomic_check() variant is already
prepared for DSI-to-DPI mode addition, which has different frequency
limits.
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc:
The tc_set_video_mode() sets up both common and (e)DP video mode settings of
the bridge chip. Split the function into tc_set_common_video_mode() to set
the common settings and tc_set_edp_video_mode() to set the (e)DP specific
settings. No functional change.
Signed-off-by: Marek Vasut
Cc: Jonas
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
currently supported. It is possible to find out the mode in which the
bridge should be operated by testing connected endpoints in DT.
Port allocation:
port@0
The bridge ops are specific to the bridge configuration, move them
into tc_probe_edp_bridge_endpoint() to permit cleaner addition of
DSI-to-DPI mode. No functional change.
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Sam Ravnborg
This bit of code is (e)DP and aux I2C link specific, move it into
tc_aux_link_setup() to permit cleaner addition of DSI-to-DPI mode.
No functional change.
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Sam Ravnborg
---
V2: - New
to guarantee the
DSI clock lane is running before accessing the hardware. In case Xtal
is attached to the chip, this change has no effect.
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Sam Ravnborg
---
V2: - Rebase on next-20220217
Cc: Laurent Pinchart
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Sam Ravnborg
---
V2: - Rebase on next-20220217 and new patches in this series
---
drivers/gpu/drm/bridge/tc358767.c | 339 +-
1 file changed, 332 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
currently supported. In order to support the rest of the modes without
making the tc_probe() overly long, split the bridge endpoint parsing
into dedicated
These functions are specific to (e)DP output initialization and
operation, add specific tc_edp_ prefix to those functions to
discern them from DPI output functions that will be added later
in this series. No functional change.
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Use the atomic version of the enable/disable operations to continue the
transition to the atomic API. This will be needed to access the mode
from the atomic state.
Signed-off-by: Marek Vasut
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc: Maxime Ripard
Cc: Neil Armstrong
Cc: Sam Ravnborg
---
V2:
Ripard
Cc: Neil Armstrong
Cc: Rob Herring
Cc: Sam Ravnborg
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
V2: - Rebase on next-20220217
---
.../devicetree/bindings/display/bridge/toshiba,tc358767.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Clean up the driver,
switch to atomic ops, and add support for the DSI-to-DPI mode in
addition to already supported DPI-to-(e)DP mode.
Cc: Jonas Karlman
Cc: Laurent Pinchart
Cc:
On Thu, Feb 17, 2022 at 04:12:20PM -0500, Felix Kuehling wrote:
> I'm thinking of a more theoretical approach: Instead of auditing all users,
> I'd ask, what are the invariants that a vm_normal_page should have. Then
> check, whether our DEVICE_COHERENT pages satisfy them. But maybe the concept
>
On 16/02/2022 04:34, Abhinav Kumar wrote:
On 2/15/2022 4:20 PM, Dmitry Baryshkov wrote:
On Tue, 15 Feb 2022 at 23:21, Abhinav Kumar
wrote:
On 2/15/2022 10:42 AM, Dmitry Baryshkov wrote:
On Tue, 15 Feb 2022 at 20:42, Abhinav Kumar
wrote:
On 2/15/2022 9:28 AM, Bjorn Andersson wrote:
On
On Mon, Feb 07, 2022 at 03:07:43PM +0530, Ramalingam C wrote:
When we are swapping out the local memory obj on flat-ccs capable platform,
we need to capture the ccs data too along with main meory and we need to
restore it when we are swapping in the content.
Extracting and restoring the CCS
On 16/02/2022 10:19, Abhinav Kumar wrote:
On 2/15/2022 9:14 PM, Bjorn Andersson wrote:
On Tue 15 Feb 20:38 CST 2022, Abhinav Kumar wrote:
On 2/15/2022 6:14 PM, Bjorn Andersson wrote:
On Tue 15 Feb 11:42 CST 2022, Abhinav Kumar wrote:
On 2/15/2022 9:28 AM, Bjorn Andersson wrote:
On
Hi Andi,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.17-rc4
next-20220217]
[If your patch is applied to the wrong git
From: John Harrison
Some G2H handlers were reading the context id field from the payload
before checking the payload met the minimum length required.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
From: John Harrison
The LRC descriptor pool is going away. So, stop using it as a check for
context registration, use the GuC id instead (being the thing that
actually gets registered with the GuC).
Also, rename the set/clear/query helper functions for context id
mappings to better reflect
From: John Harrison
The LRC descriptor pool is going away. So, stop using it as a check
for whether submission has been initialised or not.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 +---
From: John Harrison
The next GuC firmware release includes some significant backwards
breaking API changes. One such is that there is no longer an LRC
descriptor pool. A bunch of prep work for that change can be done in
advance - the descriptor pool was being used for things it shouldn't
really
From: John Harrison
The CTB registration process changed significantly a while back using
a single KLV based H2G. So drop the original and now obsolete H2G
definitions.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 2 --
1 file changed, 2 deletions(-)
From: John Harrison
The LRC descriptor pool is going away. Further, the function that was
populating it was also doing a bunch of logic about the context
registration sequence. So, split that code apart into separate state
setup and try to register functions. Note that some of those 'try to
From: John Harrison
The LRC descriptor pool is going away. So, stop naming context ids as
descriptor pool indecies.
While at it, add a bunch of missing line feeds to some error messages.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56 +--
From: John Harrison
The LRC descriptor pool is going away. So, stop using it as the limit
for how many context ids are available.
While at it, also update a kzalloc(sizeof()*count) to be a
kcalloc(count,size).
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_context.c
From: John Harrison
The LRC descriptor was being initialised early on in the context
registration sequence. It could then be determined that the actual
registration needs to be delayed and the descriptor would be wiped
out. This is inefficient, so move the setup to later in the process
after the
Hi,
On Thu, Feb 10, 2022 at 3:58 AM Sankeerth Billakanti
wrote:
>
> +_gpios {
> + edp_bl_power: edp-bl-power {
> + pins = "gpio7";
> + function = "normal";
> + qcom,drive-strength = ;
As far as I can tell you're lacking:
#include
...which is
DP AUX transactions can consist of many short operations. There's no
need to power things up/down in short intervals.
I pick an arbitrary 100ms; for the systems I'm testing (Rockchip
RK3399), runtime-PM transitions only take a few microseconds.
Signed-off-by: Brian Norris
---
Changes in v3:
-
If the display is not enable()d, then we aren't holding a runtime PM
reference here. Thus, it's easy to accidentally cause a hang, if user
space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
Let's get a runtime PM reference, and check that we "see" the panel.
Don't force any panel
On 2022-02-18 01:12:02, Dmitry Baryshkov wrote:
> On 18/02/2022 00:54, Marijn Suijten wrote:
> > On 2021-11-16 11:52:46, Vinod Koul wrote:
> >> In SDM845, DSC can be enabled by writing to pingpong block registers, so
> >> add support for DSC in hw_pp
> >
> > Nit: I don't think the ", so add
On 2022-02-10 16:04:20, Vinod Koul wrote:
> For DSC to work we typically need a 2,2,1 configuration. This should
> suffice for resolutions up to 4k. For more resolutions like 8k this won't
> work.
>
> Also, it is better to use 2 LMs and DSC instances as half width results
> in lesser power
Replace "missing structure" with "missing num_dspp field" in the title?
On 2022-02-10 16:04:19, Vinod Koul wrote:
> Somehow documentation for dspp was missed, so add that
>
> Signed-off-by: Vinod Koul
> ---
> drivers/gpu/drm/msm/msm_drv.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On 2022-02-10 16:04:17, Vinod Koul wrote:
> We need to configure the encoder for DSC configuration and calculate DSC
> parameters for the given timing so this patch adds that support by
> adding dpu_encoder_prep_dsc() which is invoked when DSC is enabled.
>
> Signed-off-by: Vinod Koul
> ---
>
On 2022-02-10 16:04:16, Vinod Koul wrote:
> Later gens of hardware have DSC bits moved to hw_ctl, so configure these
> bits so that DSC would work there as well
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Vinod Koul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 11 ++-
>
On 18/02/2022 00:54, Marijn Suijten wrote:
On 2021-11-16 11:52:46, Vinod Koul wrote:
In SDM845, DSC can be enabled by writing to pingpong block registers, so
add support for DSC in hw_pp
Nit: I don't think the ", so add support for DSC in XXX" part in this
and other commit messages add
On 17/02/2022 19:15, Lyude Paul wrote:
Hi! Sorry for the late reply, I had to take some time off work unexpectedly.
This is normal (although not great TBH, I'm not sure we should be printing an
error message for that), it's the result of fwupd trying to probe the MST hub
to see if it's a
Quoting Qing Wang (2022-02-14 17:55:39)
> From: Wang Qing
>
> Use the helper function time_is_{before,after}_jiffies() to improve
> code readability.
>
> Signed-off-by: Wang Qing
> ---
Applied to clk-next
Hi Vinod,
I seem to have sent this review to v3 instead of the repost of v4. It
should still apply the same, hope that's no issue.
- Marijn
On 2022-02-17 22:54:38, Marijn Suijten wrote:
> On 2021-11-16 11:52:46, Vinod Koul wrote:
> > In SDM845, DSC can be enabled by writing to pingpong block
On 2021-11-16 11:52:46, Vinod Koul wrote:
> In SDM845, DSC can be enabled by writing to pingpong block registers, so
> add support for DSC in hw_pp
Nit: I don't think the ", so add support for DSC in XXX" part in this
and other commit messages add anything. You've already stated that in
the
On Fri, 18 Feb 2022 at 00:36, Kuogee Hsieh wrote:
>
> Widebus feature will transmit two pixel data per pixel clock to interface.
> Timing engine provides driving force for this purpose. This patch base
> on HPG (Hardware Programming Guide) to revise timing engine register
> setting to accommodate
On Fri, 18 Feb 2022 at 00:36, Kuogee Hsieh wrote:
>
> To improve code readability, this patch replace BIT(x) with
> correspond register bit define string
>
> Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 +---
> 1
On 2022-02-10 16:04:20, Vinod Koul wrote:
> For DSC to work we typically need a 2,2,1 configuration. This should
> suffice for resolutions up to 4k. For more resolutions like 8k this won't
> work.
>
> Also, it is better to use 2 LMs and DSC instances as half width results
> in lesser power
On Fri, 18 Feb 2022 at 00:36, Kuogee Hsieh wrote:
>
> The “DP timing” requires the active region to be defined in the
> bottom-right corner of the frame dimensions which is different
> with DSI. Therefore both display_h_end and display_v_end need
> to be adjusted accordingly. However current
On Thu, Feb 17, 2022 at 11:02:53PM +0300, Dmitry Osipenko wrote:
> 17.02.2022 22:16, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > Hi all,
> >
> > this is the userspace part of the kernel patches that were recently
> > merged into drm-next:
> >
> >
Widebus feature will transmit two pixel data per pixel clock to interface.
This feature now is required to be enabled to easy migrant to higher
resolution applications in future. However since some legacy chipsets
does not support this feature, this feature is enabled base on chip's
hardware
The “DP timing” requires the active region to be defined in the
bottom-right corner of the frame dimensions which is different
with DSI. Therefore both display_h_end and display_v_end need
to be adjusted accordingly. However current implementation has
only display_h_end adjusted.
Signed-off-by:
Widebus feature will transmit two pixel data per pixel clock to interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine register
setting to accommodate both widebus and non widebus application. Also
horizontal
To improve code readability, this patch replace BIT(x) with
correspond register bit define string
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git
revise widebus timing engine programming and enable widebus feature base on chip
Kuogee Hsieh (4):
drm/msm/dpu: adjust display_v_end for eDP and DP
drm/msm/dpu: replace BIT(x) with correspond marco define string
drm/msm/dpu: revise timing engine programming to support widebus
feature
The pull request you sent on Fri, 18 Feb 2022 06:02:24 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-02-18
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b3d971ec25346d6890e9e8f05b63f758cfcef8c5
Thank you!
--
Deet-doot-dot, I am a bot.
From: John Harrison
A flag query helper was actually writing to the flags word rather than
just reading. Fix that. Also update the function's comment as it was
out of date.
NB: No need for a 'Fixes' tag. The test was only ever used inside a
BUG_ON during context registration. Rather than
On Fri, Feb 18, 2022 at 12:12:21AM +0530, Ramalingam C wrote:
From: Matt Roper
DG2 supports a 5th display output which the hardware refers to as "TC1,"
even though it isn't a Type-C output. This behaves similarly to the TC1
on past platforms with just a couple minor differences:
* DG2's TC1
Am 2022-02-16 um 07:26 schrieb Jason Gunthorpe:
The other place that needs careful audit is all the callers using
vm_normal_page() - they must all be able to accept a ZONE_DEVICE page
if we don't set pte_devmap.
How much code are we talking about here? A quick search finds 26
call-sites in 12
On 2/3/22 13:23, Maxime Ripard wrote:
On Tue, Dec 07, 2021 at 06:32:38PM +0100, Marek Vasut wrote:
On 12/7/21 18:03, Laurent Pinchart wrote:
On Tue, Dec 07, 2021 at 05:47:29PM +0100, Marek Vasut wrote:
On 12/7/21 17:43, Laurent Pinchart wrote:
[...]
diff --git
Hi Andi,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.17-rc4
next-20220217]
[If your patch is applied to the wrong git
On Wed, Feb 16, 2022 at 09:36:02AM +, Hogander, Jouni wrote:
On Wed, 2022-02-16 at 10:50 +0200, Ville Syrjälä wrote:
On Tue, Feb 15, 2022 at 11:21:54AM +0530, Ramalingam C wrote:
> From: Jouni Högander
>
> Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E
> port. Correct
On Mon, Feb 14, 2022 at 12:56:58PM +0200, Mika Westerberg wrote:
> On Mon, Feb 14, 2022 at 09:52:02AM +0100, Lukas Wunner wrote:
> > On Mon, Feb 14, 2022 at 09:34:26AM +0200, Mika Westerberg wrote:
> > > On Fri, Feb 11, 2022 at 03:45:46PM -0600, Bjorn Helgaas wrote:
> > > > My expectation is that
Hi Geert,
On Tue, Feb 15, 2022 at 05:52:18PM +0100, Geert Uytterhoeven wrote:
> Hi all,
>
> A long outstanding issue with the DRM subsystem has been the lack of
> support for low-color displays, as used typically on older desktop
> systems and small embedded displays.
This is one of the
Hi Geert,
>
> C1 is color-indexed, which can be any two colors.
> R1 is light-on-dark.
> D1 is dark-on-light.
It would be nice to have this explained in the fourcc.h file,
preferably with a little more verbosity than the current explanations.
Sam
Hi Geert,
> > > + switch (fb->format->depth) {
> >
> > The depth field is deprecated. It's probably better to use
> > fb->format->format and test against 4CC codes.
>
> The reason I checked for depth instead of a 4CC code is that the only
> thing that matters here is the number of bits per
Add logic for wbvind_on_all_cpus for non-x86 platforms.
v2(Michael Cheng): Change logic to if platform is not x86, then
we add pr_warn for calling wbvind_on_all_cpus.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/drm_cache.c | 2 --
include/drm/drm_cache.h | 6 ++
drm_cache.h now handles calls to wbinvd_on_all_cpus.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index
Add drm_cache.h to additionals files that calls wbinvd_on_all_cpus and
remove un-needed header files.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff
This series moves the logic for wbvind_on_all_cpus to drm_cache. The logic
changes a little here, if platform is not x86 then we throw out a warning
for when wbvind_on_all_cpus is being called.
v2(Michael Cheng): Move and redo logic for wbvind_on_all_cpus. Also
add
On 2/16/2022 10:34 PM, Dmitry Baryshkov wrote:
On 17/02/2022 01:05, Kuogee Hsieh wrote:
Widebus feature will transmit two pixel data per pixel clock to
interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing
The 2022 X.Org Foundation elections are rapidly approaching. We will be
forwarding instructions on the nomination process to membership in the
near future.
Please note that only current members can vote in the upcoming election,
and that the deadline for new memberships or renewals to vote in the
On 2/10/2022 2:34 AM, Vinod Koul wrote:
Display Stream Compression (DSC) parameters need to be calculated. Add
helpers and struct msm_display_dsc_config in msm_drv for this
msm_display_dsc_config uses drm_dsc_config for DSC parameters.
Signed-off-by: Vinod Koul
As we spoke during the sync
17.02.2022 22:16, Thierry Reding пишет:
> From: Thierry Reding
>
> Hi all,
>
> this is the userspace part of the kernel patches that were recently
> merged into drm-next:
>
> https://patchwork.freedesktop.org/series/92378/
>
> The goal is to provide a userspace implementation of the UAPI
Hi Linus,
Regular fixes for rc5, nothing really stands out, mostly some amdgpu
and i915 fixes with mediatek, radeon and some misc fixes.
Dave.
drm-fixes-2022-02-18:
drm fixes for 5.17-rc5
cma-helper:
- set VM_DONTEXPAND
atomic:
- error handling fix.
mediatek:
- fix probe defer loop with
On 2/17/2022 11:36 AM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-02-17 10:35:30)
Since DRM_DEBUG_DP is deprecated in favor of drm_dbg_dp(NULL, ...),
this patch replace all DRM_DEBUG_DP with drm_dbg_dp().
Changes in v4:
-- replace (strucr drm_dev *)NULL with drm_dev
Why can't the
Hi everyone,
Thanks to the amazing work Rodrigo does mentoring students (which
introduces them to GNU/Linux in general and X.Org/fd.o in particular) it
looks like we might have some potential GSoC candidates this year.
The last time we ran an X.Org GSoC, back in 2020, our amazing student,
Hi Andi,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.17-rc4
next-20220217]
[If your patch is applied to the wrong git
Hi Sui,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on robh/for-next v5.17-rc4 next-20220217]
[cannot apply to mripard/sunxi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
Hi Sui,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on robh/for-next v5.17-rc4 next-20220217]
[cannot apply to mripard/sunxi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Tue, Feb 15, 2022 at 11:21:54AM +0530, Ramalingam C wrote:
From: Jouni Högander
Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E
port. Correct offset is 0x64C14.
Fix this by handling PHY_E port seprately.
order of the patch here is wrong. This patch should come before
Quoting Kuogee Hsieh (2022-02-17 10:35:30)
> Since DRM_DEBUG_DP is deprecated in favor of drm_dbg_dp(NULL, ...),
> this patch replace all DRM_DEBUG_DP with drm_dbg_dp().
>
> Changes in v4:
> -- replace (strucr drm_dev *)NULL with drm_dev
Why can't the platform device be used?
On Tue, Feb 15, 2022 at 11:21:53AM +0530, Ramalingam C wrote:
From: Matt Roper
Our early understanding of DG2 was incorrect; since the 5th display
isn't actually a Type-C output, 38.4 MHz input clocks are never used on
this platform and we can drop the corresponding MPLLB tables.
Cc: Anusha
From: Thierry Reding
This test will attempt to use the VIC to blit one surface to another
and perform a vertical flip.
Signed-off-by: Thierry Reding
---
tests/tegra/meson.build | 9 ++
tests/tegra/vic-flip.c | 333
2 files changed, 342 insertions(+)
From: Thierry Reding
This test will attempt to use the VIC to blit from one surface to
another.
Signed-off-by: Thierry Reding
---
tests/tegra/meson.build | 9 ++
tests/tegra/vic-blit.c | 333
2 files changed, 342 insertions(+)
create mode 100644
From: Thierry Reding
This test will attempt to use VIC to clear a surface.
Signed-off-by: Thierry Reding
---
tests/tegra/meson.build | 9 +++
tests/tegra/vic-clear.c | 173
2 files changed, 182 insertions(+)
create mode 100644
From: Thierry Reding
The Video Image Composer (VIC) 4.2 can be found on NVIDIA Tegra194 SoCs.
It uses a different class (C5B6) that is slightly incompatible with the
class found on earlier generations, although it is backwards compatible
with the class implemented on Tegra186 (B1B6).
From: Thierry Reding
The Video Image Composer (VIC) 4.1 can be found on NVIDIA Tegra186 SoCs.
It uses a different class (B1B6) that is slightly incompatible with the
class found on earlier generations.
Signed-off-by: Thierry Reding
---
tests/tegra/meson.build | 2 +
tests/tegra/vic.c
From: Thierry Reding
The Video Image Composer (VIC) 4.0 can be found on NVIDIA Tegra210 SoCs.
It uses a different class (B0B6) that is slightly incompatible with the
class found on earlier generations.
Signed-off-by: Thierry Reding
---
tests/tegra/meson.build | 2 +
tests/tegra/vic.c
From: Thierry Reding
The Video Image Composer (VIC) 3.0 can be found on NVIDIA Tegra124 SoCs.
Signed-off-by: Thierry Reding
---
tegra/private.h | 6 +
tests/tegra/meson.build | 2 +
tests/tegra/vic.c | 8 +-
tests/tegra/vic30.c | 458
1 - 100 of 303 matches
Mail list logo
