From: luo penghao
The existence of offset is meaningless, so it should be deleted.
The clang_analyzer complains as follows:
Value stored to 'offset' is never read
Reported-by: Zeal Robot
Signed-off-by: luo penghao
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 8
1 file changed,
From: luo penghao
This value will be overwritten by the following if statement, even
if the if is not executed, the value will not be used
The clang_analyzer complains as follows:
Value stored to 'port_mask' is never read
Reported-by: Zeal Robot
Signed-off-by: luo penghao
---
The "edid" struct member is only used during probe() and it's freed
right away. There is no point in storing a freed pointer for the
whole life of the driver.
Signed-off-by: Dan Carpenter
---
v2: use __maybe_unused annotation to silence an unused variable warning
depending on the .config
On Wed, Dec 8, 2021 at 2:20 AM Rob Herring wrote:
>
> On Mon, Dec 6, 2021 at 11:49 PM Jagan Teki wrote:
> >
> > Add of_get_non_port_child() helper that can be used to lookup
> > non port child nodes.
> >
> > Some OF graphs don't require 'ports' to represent the next output
> > instead, it simply
On Fri, Nov 12, 2021 at 4:49 AM Vincent Whitchurch
wrote:
>
> On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
> > Dynamic-Debug can do 2nd exceedingly well:
> >
> > A- all work is behind jump-label's NOOP, zero off cost.
> > B- exact site selectivity, precisely the useful traffic.
> >
Quoting Rob Clark (2021-12-07 13:57:52)
> From: Rob Clark
>
> Otherwise we don't get another shot at it if the bridge probes before
> the dsi host is registered. It seems like this is what *most* (but not
> all) of the other bridges do.
>
> It looks like this was missed in the conversion to
Add MDP_RDMA driver for MT8195. MDP_RDMA is the DMA engine of
the ovl_adaptor component.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 7 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
Add driver data of mt8195 vdosys1 to mediatek-drm.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index
Add mmsys config API. The config API is used for config mmsys reg.
Some mmsys regs need to be setting according to the HW engine binding
to the mmsys simultaneously.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 62 ++
Add merge start/stop API for cmdq support. The ovl_adaptor merges
are configured with each drm plane update. Need to enable/disable
merge with cmdq making sure all the settings taken effect in the
same vblank.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
ETHDR is a part of ovl_adaptor.
ETHDR is designed for HDR video and graphics conversion in the external
display path. It handles multiple HDR input types and performs tone
mapping, color space/color format conversion, and then combine
different layers, output the required HDR or SDR signal to the
Add vdosys1 reset control bit for MT8195 platform.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
include/dt-bindings/reset/mt8195-resets.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/dt-bindings/reset/mt8195-resets.h
Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
the component exists in the path.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 16
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 30 ---
Add cmdq support for mtk-mmsys config API.
The mmsys config register settings need to take effect with the other
HW settings(like OVL_ADAPTOR...) at the same vblanking time.
If we use CPU to write the mmsys reg, we can't guarantee all the
settings can be written in the same vblanking time.
Cmdq
MT8195 vdosys1 has more than 32 reset bits and a different reset base
than other chips. Modify mmsys for support 64 bit and different reset
base.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h | 1 +
drivers/soc/mediatek/mtk-mmsys.c| 21 -
MT8195 vdosys1 merge1 to merge4 have HW mute function.
Add MERGE additional mute property description.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
Acked-By: AngeloGioacchino Del Regno
---
.../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 4
1 file changed, 4
Add vdosys1 ETHDR definition.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
.../display/mediatek/mediatek,ethdr.yaml | 147 ++
1 file changed, 147 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
diff
Add mt8195 vdosys1 clock driver name and routing table to
the driver data of mtk-mmsys.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 136 +
drivers/soc/mediatek/mtk-mmsys.c | 10 ++
include/linux/soc/mediatek/mtk-mmsys.h | 2 +
3 files
Add display node for vdosys1.
Signed-off-by: Nancy.Lin
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 222 +++
1 file changed, 222 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index
This is a preparation for adding support for mt8195 vdosys1 mutex.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements,
so change it to support multi-bit control.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mutex.c |
MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
only one drm driver register as the drm device.
Each drm driver binds its own component. The last bind drm driver
allocates and registers the drm device to drm core.
Add ovl_adaptor driver for MT8195.
Ovl_adaptor is an encapsulated module and designed for simplified
DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and
an ETHDR. Two RDMAs merge into one layer, so this module support 4
layers.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
Add merge new advance config API. The original merge API is
mtk_ddp_comp_funcs function prototype. The API interface parameters
cannot be modified, so add a new config API for extension. This is
the preparation for ovl_adaptor merge control.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
Add merge async reset control in mtk_merge_stop. Async hw doesn't do self
reset on each sof signal(start of frame), so need to reset the async to
clear the hw status for the next merge start.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 4
1 file changed, 4
Add plane color encoding information for color space conversion.
It's a preparation for adding support for mt8195 ovl_adaptor mdp_rdma
csc control.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_plane.h |
Add merge mute/unmute setting for MT8195.
MT8195 Vdosys1 merge1~merge4 support HW mute function.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 13 +
1 file changed, 13 insertions(+)
diff --git
Add vdosys1 RDMA definition.
Signed-off-by: Nancy.Lin
---
.../arm/mediatek/mediatek,mdp-rdma.yaml | 77 +++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,mdp-rdma.yaml
diff --git
Add mtk-mutex support for mt8195 vdosys1.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mutex.c | 54
1 file changed, 54 insertions(+)
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.
Add DRM and these modules support by the patches below:
Changes in v10:
- refine ethdr reset control using
devm_reset_control_array_get_optional_exclusive
- fix ovl_adaptor
dma_fence_chain_find_seqno only ever returns the top fence in the
chain or an unsignalled fence. Hence if we request a seqno that
is already signalled it returns a NULL fence. Some callers are
not prepared to handle this, like the syncobj transfer functions
for example.
This behavior is "new"
Hi Philipp,
Thanks for the review.
On Tue, 2021-11-30 at 10:46 +0100, Philipp Zabel wrote:
> Hi Nancy,
>
> On Tue, 2021-11-30 at 11:35 +0800, Nancy.Lin wrote:
> [...]
> > +void mtk_ethdr_stop(struct device *dev)
> > +{
> > + struct mtk_ethdr *priv = dev_get_drvdata(dev);
> > + struct
From: tommy-huang
Add more gfx reset control for ast2600.
Signed-off-by: tommy-huang
---
arch/arm/boot/dts/aspeed-g6.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index e38c3742761b..b92b24609660
Add new CRT reset define for ast2600.
Reported-by: kernel test robot
Signed-off-by: Tommy Haung
---
include/dt-bindings/clock/ast2600-clock.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/clock/ast2600-clock.h
b/include/dt-bindings/clock/ast2600-clock.h
index
From: tommy-huang
Add AST2600 chip support and setting.
Signed-off-by: tommy-huang
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index
From: tommy-huang
Add more reset and clock select code for AST2600.
The gfx_flags parameter was added for chip caps idenified.
Signed-off-by: tommy-huang
---
drivers/gpu/drm/aspeed/aspeed_gfx.h | 16 +++-
drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 16
From: Joel Stanley
The GFX device is present in the AST2600 SoC.
Signed-off-by: Joel Stanley
Signed-off-by: tommy-huang
---
arch/arm/boot/dts/aspeed-g6.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
From: Joel Stanley
Enable the GFX device with a framebuffer memory region.
Signed-off-by: Joel Stanley
Signed-off-by: tommy-huang
---
arch/arm/boot/dts/aspeed-ast2600-evb.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
v5:
Add lost reset define.
v4:
Add necessary reset control for ast2600.
Add chip caps for futher use.
These code are test on AST2500 and AST2600 by below steps.
1. Add below config to turn VT and LOGO on.
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
From: tommy-huang
Add interrupt clear register define for further chip support.
Signed-off-by: tommy-huang
---
drivers/gpu/drm/aspeed/aspeed_gfx.h | 1 +
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git
On 2021-11-30 12:49 p.m., Qingyang Zhou wrote:
Dear Felix:
This patch is not auto-generated, and as a matter of fact, it is
requested by the Linux Community.
As you can see from my email address, I am a researcher from the
University of Minnesota, and because of the unpleasant event that
dma_fence_chain_find_seqno only ever returns the top fence in the
chain or an unsignalled fence. Hence if we request a seqno that
is already signalled it returns a NULL fence. Some callers are
not prepared to handle this, like the syncobj transfer functions
for example.
This behavior is "new"
On 11/25/2021 10:01 AM, Dmitry Baryshkov wrote:
Commit 739b4e7756d3 ("drm/msm/dsi: Fix an error code in
msm_dsi_modeset_init()") changed msm_dsi_modeset_init() to return an
error code in case msm_dsi_manager_validate_current_config() returns
false. However this is not an error case, but a
Currently the msm_dp_*** functions implement the same sequence which would
happen when drm_bridge is used. hence get rid of this intermediate layer
and align with the drm_bridge usage to avoid customized implementation.
Signed-off-by: Kuogee Hsieh
Changes in v2:
-- revise commit text
-- rename
On 12/7/2021 09:53, Adrian Larumbe wrote:
Beginning with DG2, all successive devices will require GuC FW to be
present and loaded at probe() time. This change alters error handling in
the FW init and load functions so that the driver's probe() function will
fail if GuC could not be loaded.
We
From: Laura Abbott
Consolodate everything under an @kernel.org address.
Signed-off-by: Laura Abbott
---
Sumit, can you take this through your tree?
---
.mailmap| 3 +++
MAINTAINERS | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host. Simplify the code path by using panel-bridge
driver (already selected in Kconfig) and dropping support for
handling the panel directly.
The DSI subsystem does not fully fall into the pre-enable/enable system
of callbacks, since typically DSI device bridge drivers expect to be
able to communicate with DSI devices at the pre-enable() callback. The
reason is that for some DSI hosts enabling the video stream would
prevent other
Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host.
The later functionality is already suppurted by the panel-bridge driver,
which wraps drm panel into the drm bridge instance. Using it
Hi,
On Tue, Dec 7, 2021 at 1:52 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Otherwise we don't get another shot at it if the bridge probes before
> the dsi host is registered. It seems like this is what *most* (but not
> all) of the other bridges do.
>
> It looks like this was missed in the
From: Rob Clark
Otherwise we don't get another shot at it if the bridge probes before
the dsi host is registered. It seems like this is what *most* (but not
all) of the other bridges do.
It looks like this was missed in the conversion to attach dsi host at
probe time.
Fixes: c3b75d4734cb
Hi,
On Tue, Dec 7, 2021 at 1:33 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Otherwise we don't get another shot at it if the bridge probes before
> the dsi host is registered. It seems like this is what *most* (but not
> all) of the other bridges do.
>
> It looks like this was missed in the
From: Rob Clark
Otherwise we don't get another shot at it if the bridge probes before
the dsi host is registered. It seems like this is what *most* (but not
all) of the other bridges do.
It looks like this was missed in the conversion to attach dsi host at
probe time.
Fixes: c3b75d4734cb
Hi, John.
On 12/7/21 21:46, John Harrison wrote:
On 11/29/2021 12:22, Thomas Hellström wrote:
With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can
On Mon, Dec 6, 2021 at 11:49 PM Jagan Teki wrote:
>
> Add of_get_non_port_child() helper that can be used to lookup
> non port child nodes.
>
> Some OF graphs don't require 'ports' to represent the next output
> instead, it simply adds a child node on a given parent node. This
> helper lookup
Beginning with DG2, all successive devices will require GuC FW to be
present and loaded at probe() time. This change alters error handling in
the FW init and load functions so that the driver's probe() function will
fail if GuC could not be loaded.
Signed-off-by: Adrian Larumbe
---
There is a pretty obvious typo in there:
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -359,7 +359,7 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct
nouveau_channel *chan, bool e
fobj = dma_resv_shared_list(resv);
}
On 12/7/21 19:08, Daniel Vetter wrote:
Once more an entire week behind on mails, but this looked interesting
enough.
On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote:
On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote:
Am 01.12.21 um 13:16 schrieb Thomas Hellström
On 11/29/2021 12:22, Thomas Hellström wrote:
With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can be used to snapshot relevant state at request
> There is a pretty obvious typo in there:
>
> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
> @@ -359,7 +359,7 @@ nouveau_fence_sync(struct nouveau_bo *nvbo, struct
> nouveau_channel *chan, bool e
> fobj =
Dne torek, 07. december 2021 ob 21:26:50 CET je Doug Anderson napisal(a):
> Hi,
>
> On Tue, Dec 7, 2021 at 12:03 PM Rob Clark wrote:
> > From: Rob Clark
> >
> > Otherwise we don't get another shot at it if the bridge probes before
> > the dsi host is registered. It seems like this is what
Hi,
On Tue, Dec 7, 2021 at 12:03 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Otherwise we don't get another shot at it if the bridge probes before
> the dsi host is registered. It seems like this is what *most* (but not
> all) of the other bridges do.
>
> It looks like this was missed in the
On Sat, 27 Nov 2021 04:19:08 +0100, Marek Vasut wrote:
> Add Team Source Display TST043015CMHX 4.3" 480x272 DPI panel
> compatible string.
>
> Signed-off-by: Marek Vasut
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---
>
On Sat, 27 Nov 2021 04:19:07 +0100, Marek Vasut wrote:
> Add vendor prefix for Team Source Display Technology Co., Ltd.
>
> Signed-off-by: Marek Vasut
> Cc: Rob Herring
> Cc: Sam Ravnborg
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---
> NOTE: All the documentation
From: John Harrison
If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't let that happen.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
---
From: John Harrison
Lots of testing is done with the DEBUG_GEM config option enabled but
not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
which are not hugely useful. Enabling full DEBUG_GUC also spews lots
of other detailed output that is not generally desired. However,
From: John Harrison
It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained separately.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
From: John Harrison
Fix a potential null pointer dereference, improve debug crash reports,
improve code separation.
v2: Reposting as reduced set of patches due to CI failures.
Signed-off-by: John Harrison
John Harrison (3):
drm/i915/uc: Allow platforms to have GuC but not HuC
From: Vinay Belgaumkar
By default, GT (and GuC) run at RPn. Requesting for RP0
before firmware load can speed up DMA and HuC auth as well.
In addition to writing to 0xA008, we also need to enable
swreq in 0xA024 so that Punit will pay heed to our request.
Signed-off-by: Vinay Belgaumkar
---
On 12/1/2021 2:51 PM, Dmitry Baryshkov wrote:
Client driven prefetch (CDP) is properly setup only for SSPP REC0
currently. Enable client driven prefetch also for SSPP REC1.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 12
Hi Tommy,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v5.16-rc4]
[also build test ERROR on next-20211207]
[cannot apply to joel-aspeed/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
From: Rob Clark
Otherwise we don't get another shot at it if the bridge probes before
the dsi host is registered. It seems like this is what *most* (but not
all) of the other bridges do.
It looks like this was missed in the conversion to attach dsi host at
probe time.
Fixes: c3b75d4734cb
> On Thu, Dec 02, 2021 at 11:01:32AM -0500, Rodrigo Siqueira wrote:
> > In the DC driver, we have multiple acronyms that are not obvious
> > most of
> > the time; the same idea is valid for amdgpu. This commit introduces
> > a DC
> > and amdgpu glossary in order to make it easier to navigate
On Mon, Dec 06, 2021 at 12:52:51PM -0600, Alex Sierra wrote:
> The intention is to test device coherent type pages that have been
> called through get user pages with PIN_LONGTERM flag set.
>
> Signed-off-by: Alex Sierra
> tools/testing/selftests/vm/Makefile| 2 +-
>
On 12/1/2021 2:51 PM, Dmitry Baryshkov wrote:
Add DPU_SSPP_CSC_ANY denoting any CSC block. As we are at it, rewrite
DPU_SSPP_SCALER (any scaler) to use BIT(x) instead of hand-coded
bitshifts.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
+ Dan C for awareness as this is a follow up of our discussion on
https://lore.kernel.org/linux-arm-msm/c1537b326b654f05be247ca61d21e...@codeaurora.org/T/
On 12/1/2021 2:51 PM, Dmitry Baryshkov wrote:
The _dpu_hw_sspp_setup_scaler3 (hw_sspp->setup_scaler) does not use pe
argument. Let's remove
On 12/1/2021 2:51 PM, Dmitry Baryshkov wrote:
Scaler and pixel_ext configuration does not contain a long living state,
it is used only during plane update, so remove these two fiels from
dpu_plane_state and allocate them on stack.
s/fiels/fields
apart from that,
Reviewed-by: Abhinav Kumar
Can the DRM maintainers accept this Reviewed by patch?
Links to the Reviewed by patch:
https://lkml.org/lkml/2021/10/27/982
https://lore.kernel.org/all/1635366613-22507-1-git-send-email-george.kenn...@oracle.com/
Thank you,
George
On 10/28/2021 4:05 AM, Geert Uytterhoeven wrote:
On Wed,
> Please test if that patch changes anything.
Looks like the driver is not functional after applying that patch. As
soon as the display manager is supposed to start I get a black screen
with just a (working) mouse pointer. VT switching doesn't work after
that point.
I got the following warning
Current DP drivers have regulators, clocks, irq and phy are grouped
together within a function and executed not in a symmetric manner.
This increase difficulty of code maintenance and limited code scalability.
This patch divided the driver life cycle of operation into four states,
resume
On Tue, Dec 07, 2021 at 06:32:06PM +0100, Karol Herbst wrote:
> On Tue, Dec 7, 2021 at 10:52 AM Christian König
> wrote:
> >
> > Am 06.12.21 um 19:37 schrieb Dan Moulding:
> > > On 04.12.21 17:40, Stefan Fritsch wrote:
> > >> Hi,
> > >>
> > >> when updating from 5.14 to 5.15 on a system with
On Thu, Dec 02, 2021 at 02:26:58PM -0800, Stephen Boyd wrote:
> This series is from discussion we had on reordering the device lists for
> drm shutdown paths[1]. I've introduced an 'aggregate' bus that we put
> the aggregate device onto and then we probe the aggregate device once
> all the
On Tue, Dec 07, 2021 at 02:26:05PM +0200, Heikki Krogerus wrote:
> +Hans and Imre
> [...]
>
> Originally I wanted an API that we could use to pass all the details
> that we have in the USB Type-C drivers (that would be the
> configuration and status) to the GPU drivers, but Hans was against
> that
On Thu, Dec 02, 2021 at 11:01:32AM -0500, Rodrigo Siqueira wrote:
> In the DC driver, we have multiple acronyms that are not obvious most of
> the time; the same idea is valid for amdgpu. This commit introduces a DC
> and amdgpu glossary in order to make it easier to navigate through our
> driver.
On Mon, Dec 06, 2021 at 05:00:46PM +, Matthew Auld wrote:
> On Mon, 6 Dec 2021 at 15:18, Maarten Lankhorst
> wrote:
> >
> > On 06-12-2021 14:13, Matthew Auld wrote:
> > > On Mon, 29 Nov 2021 at 13:57, Maarten Lankhorst
> > > wrote:
> > >> Big delta, but boils down to moving set_pages to
Once more an entire week behind on mails, but this looked interesting
enough.
On Fri, Dec 03, 2021 at 03:18:01PM +0100, Thomas Hellström wrote:
> On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote:
> > Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel):
> > >
> > > On 12/1/21 12:25,
On Tue, Nov 30, 2021 at 05:33:09PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-11-19 17:04:00 [+0100], Daniel Vetter wrote:
> > Yeah if we can simplify this with reverts then I'm all for this.
> >
> > Acked-by: Daniel Vetter
> >
> > I've asked drm/i915 maintainers to check
>
> Thanks.
On Thu, Dec 02, 2021 at 09:17:37AM -0500, George Kennedy wrote:
>
>
> On 11/25/2021 10:27 AM, Daniel Vetter wrote:
> > On Mon, Nov 22, 2021 at 10:29:05AM -0500, George Kennedy wrote:
> > >
> > > On 11/19/2021 9:25 AM, Jani Nikula wrote:
> > > > On Fri, 19 Nov 2021, Daniel Vetter 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
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
On Tue, Dec 7, 2021 at 10:52 AM Christian König
wrote:
>
> Am 06.12.21 um 19:37 schrieb Dan Moulding:
> > On 04.12.21 17:40, Stefan Fritsch wrote:
> >> Hi,
> >>
> >> when updating from 5.14 to 5.15 on a system with NVIDIA GP108 [GeForce
> >> GT 1030] (NV138) and Ryzen 9 3900XT using kde/plasma on
On 11/24/21 04:02, Marek Vasut wrote:
On 10/24/21 1:04 AM, Marek Vasut wrote:
On 10/17/21 7:40 PM, Sam Ravnborg wrote:
Hi Marek,
Hi,
On Sun, Oct 17, 2021 at 07:29:51PM +0200, Marek Vasut wrote:
On 10/17/21 6:49 PM, Sam Ravnborg wrote:
[...]
+ /*
+ * Encoder might sample data on
On Tue 07 Dec 08:56 PST 2021, Hans de Goede wrote:
> Hi all,
>
> On 12/7/21 13:26, Heikki Krogerus wrote:
> > +Hans and Imre
> >
> > On Mon, Dec 06, 2021 at 02:31:40PM -0800, Bjorn Andersson wrote:
> >> On Thu 07 Oct 03:17 PDT 2021, Heikki Krogerus wrote:
> >>> On Wed, Oct 06, 2021 at
https://bugzilla.kernel.org/show_bug.cgi?id=215223
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
Hi Ammar,
On Tue, Dec 07, 2021 at 10:54:59AM +0700, Ammar Faizi wrote:
> Hello,
>
> I found warnings in the stable tree.
>
> Commit: a2547651bc896f95a3680a6a0a27401e7c7a1080 ("Linux 5.15.6")
>
> There are two unique warn locations:
>
> ammarfaizi2@integral2:~$ sudo dmesg -Sr | grep -oiE
On Fri, Dec 03, 2021 at 12:51:44PM +0900, Shunsuke Mie wrote:
> Hi maintainers,
>
> Could you please review this patch series?
Why is it RFC?
I'm confused why this is useful?
This can't do copy from MMIO memory, so it shouldn't be compatible
with things like Gaudi - does something prevent
Hi,
On Tue, Dec 7, 2021 at 8:52 AM Philip Chen wrote:
>
> Hi
>
> On Tue, Dec 7, 2021 at 8:13 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Mon, Dec 6, 2021 at 5:44 PM Philip Chen wrote:
> > >
> > > Hi
> > >
> > > On Mon, Dec 6, 2021 at 4:29 PM Douglas Anderson
> > > 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
> >> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
> >> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
> >>
On 2021-11-17 14:33, Sascha Hauer wrote:
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed
for the HDMI port. add support for these to the driver for boards which
have them supplied by switchable regulators.
Signed-off-by: Sascha Hauer
---
Hi all,
On 12/7/21 13:26, Heikki Krogerus wrote:
> +Hans and Imre
>
> On Mon, Dec 06, 2021 at 02:31:40PM -0800, Bjorn Andersson wrote:
>> On Thu 07 Oct 03:17 PDT 2021, Heikki Krogerus wrote:
>>> On Wed, Oct 06, 2021 at 01:26:35PM -0700, Prashant Malani wrote:
(CC+ Heikki)
>> [..]
On
Hi
On Tue, Dec 7, 2021 at 8:13 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Dec 6, 2021 at 5:44 PM Philip Chen wrote:
> >
> > Hi
> >
> > On Mon, Dec 6, 2021 at 4:29 PM Douglas Anderson
> > wrote:
> > >
> > > When we added the support for the AUX channel in commit 13afcdd7277e
> > >
From: Matthew Auld
If the device needs 64K minimum GTT pages for device local-memory,
like on XEHPSDV, then we need to fail the allocation if we can't
meet it, instead of falling back to 4K pages, otherwise we can't
safely support the insertion of device local-memory pages for
this vm, since the
1 - 100 of 191 matches
Mail list logo
