Am 01.12.20 um 13:33 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 13:14 schrieb Christian König:
Am 01.12.20 um 12:30 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 11:34 schrieb Christian König:
[...]
In patch 6 of this series, there's ast cursor code that acquires
two BO's reservation locks
Hi
Am 01.12.20 um 13:38 schrieb Christian König:
Am 01.12.20 um 13:33 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 13:14 schrieb Christian König:
Am 01.12.20 um 12:30 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 11:34 schrieb Christian König:
[...]
In patch 6 of this series, there's ast cu
Hi
Am 01.12.20 um 13:51 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 13:38 schrieb Christian König:
Am 01.12.20 um 13:33 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 13:14 schrieb Christian König:
Am 01.12.20 um 12:30 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 11:34 schrieb Christian Kö
Quoting Matthew Auld (2020-11-27 12:06:08)
> Same old gem_create but with now with extensions support. This is needed
> to support various upcoming usecases. For now we use the extensions
> mechanism to support setting an immutable-priority-list of potential
> placements, at creation time.
>
> If
Am 01.12.20 um 13:53 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 13:51 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 13:38 schrieb Christian König:
Am 01.12.20 um 13:33 schrieb Thomas Zimmermann:
Hi
Am 01.12.20 um 13:14 schrieb Christian König:
Am 01.12.20 um 12:30 schrieb Thomas Zimmerman
Daniel added a warning for this, but we were abusing that behavior here.
Signed-off-by: Christian König
Fixes: 57fcd550eb15 ("drm/ttm: Warn on pinning without holding a reference")
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/driver
On 01/12/2020 12:55, Chris Wilson wrote:
Quoting Matthew Auld (2020-11-27 12:06:08)
Same old gem_create but with now with extensions support. This is needed
to support various upcoming usecases. For now we use the extensions
mechanism to support setting an immutable-priority-list of potential
pl
Hi
Am 01.12.20 um 14:05 schrieb tiantao (H):
在 2020/12/1 20:36, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 13:26 schrieb tiantao (H):
在 2020/12/1 20:17, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 12:55 schrieb Tian Tao:
Assign local variable to struct drm_device *dev because they are
used mu
On Thu, 5 Nov 2020 02:43:57 +0300, Dmitry Osipenko wrote:
> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces
> power consumption and heating of the Tegra chips. Tegra SoC has multiple
> hardware units which belong to a core power domain of the SoC and share
> the core voltag
On Thu, Nov 26, 2020 at 8:43 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/kv_dpm.c: In function
> ‘kv_dpm_powergate_uvd’:
> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/kv_dpm.c:1678:6: warning:
> variable ‘ret’ set but n
On Sun, Nov 22, 2020 at 08:17:03AM -0800, Kees Cook wrote:
> On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote:
> > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote:
> > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gusta
On Mon, Nov 23, 2020 at 05:32:51PM -0800, Nick Desaulniers wrote:
> On Sun, Nov 22, 2020 at 8:17 AM Kees Cook wrote:
> >
> > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote:
> > > If none of the 140 patches here fix a real bug, and there is no change
> > > to machine code then it so
Hi
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Two W=1 string related warnings.
- Using strncpy to copy string without null-termination generates a
warning. Use memcpy to copy only the relevant chars
- Fix a potential bug with a very long string, subtract one from the
length to make room
Hi
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fix warnings:
- drop kernel-doc for the two debug functions to avoid the warnings
- delete unused code
v2:
- Updated subject (Lee)
Signed-off-by: Sam Ravnborg
Cc: Thomas Zimemrmann
Cc: Sam Ravnborg
Cc: "Gustavo A. R. Silva"
Cc: Daniel Vetter
Hi Sam
Am 29.11.20 um 22:52 schrieb Sam Ravnborg:
Hi Thomas.
On Sun, Nov 29, 2020 at 10:59:22AM +0100, Thomas Zimmermann wrote:
Am 28.11.20 um 23:41 schrieb Sam Ravnborg:
Fix following W=1 warnings:
- Fix set but not nused variables which was used only for logging.
s/nused/used
s/which w
Am 01.12.20 um 14:12 schrieb Maxime Ripard:
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.
Signed-off-by: Maxime Ripard
Looks correct.
Reviewed-b
Hi Nikhil,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.10-rc6
next-20201201]
[cannot apply to drm/drm-next]
[If
Hi, Vinod:
Vinod Koul 於 2020年11月30日 週一 下午6:34寫道：
>
> On 17-11-20, 07:14, Chun-Kuang Hu wrote:
> > mtk_mipi_dsi_phy is currently placed inside mediatek drm driver, but it's
> > more suitable to place a phy driver into phy driver folder, so move
> > mtk_mipi_dsi_phy driver into phy driver folder.
>
On Tue, Dec 01, 2020 at 05:17:20PM +0300, Dmitry Osipenko wrote:
> 01.12.2020 16:57, Mark Brown пишет:
> > [1/1] regulator: Allow skipping disabled regulators in
> > regulator_check_consumers()
> > (no commit info)
> Could you please hold on this patch? It won't be needed in a v2, which
>
On 30/11/2020 11:53, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Nov 24, 2020 at 02:45:15PM +0200, Tomi Valkeinen wrote:
>> Add address-cells & size-cells to DSI nodes so that board files do not
>> need to define them.
>
> How about adding ports too, while at it ?
On 20:59-20201130, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Mon, Nov 30, 2020 at 12:04:27PM +0200, Tomi Valkeinen wrote:
> > On 30/11/2020 12:02, Tomi Valkeinen wrote:
> > > On 30/11/2020 11:47, Laurent Pinchart wrote:
> > >
> > Hasn't Boris commented in his review of v1 that bus flags shou
On 11:45-20201130, Laurent Pinchart wrote:
> Hi Nikhil,
>
> Thank you for the patch.
>
> On Thu, Nov 19, 2020 at 09:31:32PM +0530, Nikhil Devshatwar wrote:
> > Remove the old code to iterate over the bridge chain, as this is
> > already done by the framework.
> > The bridge state should have the
On 11:46-20201130, Laurent Pinchart wrote:
> Hi Nikhil,
>
> On Mon, Nov 30, 2020 at 12:05:03PM +0530, Nikhil Devshatwar wrote:
> > On 14:51-20201125, Tomi Valkeinen wrote:
> > > On 19/11/2020 18:01, Nikhil Devshatwar wrote:
> > > > Remove the old code to iterate over the bridge chain, as this is
>
On 30/11/2020 11:58, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Nov 24, 2020 at 02:45:19PM +0200, Tomi Valkeinen wrote:
>> The OMAP DSI command mode panel driver used to send page & column
>> address before each frame update, and this code was moved into the DSI
>
On 30/11/2020 12:00, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Nov 24, 2020 at 02:45:20PM +0200, Tomi Valkeinen wrote:
>> The VC handling has gotten quite tangled up. As the first step to clean
>> it up, lets define that we only support a single DSI peripheral (w
On 11/27/20 2:25 PM, Chris Wilson wrote:
Quoting Matthew Auld (2020-11-27 12:06:08)
Same old gem_create but with now with extensions support. This is needed
to support various upcoming usecases. For now we use the extensions
mechanism to support setting an immutable-priority-list of potential
p
On 01/12/2020 02:17, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Nov 24, 2020 at 02:45:22PM +0200, Tomi Valkeinen wrote:
>> The "channel" usage in omap dsi driver is super confusing. We have three
>> different "channels":
>>
>> 1) DSI virtual channel ID. This is a
On 01/12/2020 02:22, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Nov 24, 2020 at 02:45:26PM +0200, Tomi Valkeinen wrote:
>> We have a useless 'if' in the dsicm_bl_update_status(), a left over from
>> the conversion to DRM model. Drop the if.
>>
>> Signed-off-by: To
On 01/12/2020 02:23, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Nov 24, 2020 at 02:45:27PM +0200, Tomi Valkeinen wrote:
>> Add a panel database to the driver instead of reading propertes from DT
>> data. This is similar to panel-simple, and I believe it's more fut
On 01/12/2020 02:27, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Nov 24, 2020 at 02:45:28PM +0200, Tomi Valkeinen wrote:
>> Drop unneeded includes.
>>
>> Signed-off-by: Tomi Valkeinen
>> ---
>> drivers/gpu/drm/panel/panel-dsi-cm.c | 5 -
>> 1 file changed, 5
On 01/12/2020 02:31, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Nov 24, 2020 at 02:45:29PM +0200, Tomi Valkeinen wrote:
>> Move structs and defines to a private dsi.h header file to make dsi.c a
>> bit easier to navigate. Also move the (now) private structs and de
On 01/12/2020 02:36, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Nov 24, 2020 at 02:45:34PM +0200, Tomi Valkeinen wrote:
>> As we now have a fixed setup for VCs (VC0 for video stream, VC1 for
>> commands), we can simplify the VC setup.
>>
>> Signed-off-by: Tomi Val
input_bus_flags are specified in drm_bridge_timings (legacy) as well
as drm_bridge_state->input_bus_cfg.flags
The flags from the timings will be deprecated. Bridges are supposed
to validate and set the bridge state flags from atomic_check.
Implement atomic_check hook for the same.
Signed-off-by:
This series moves the tidss to using new connectoe model, where the
SoC driver (tidss) creates the connector and all the bridges are
attached with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
Since the bridges do not create the connector, the bus_format and
bus_flag is set via atomic hooks.
Support f
With new connector model, tfp410 will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support format negotiations hooks in the drm_bridge_funcs.
Use helper functions for state management.
Output format is expected to be MEDIA_BUS_FMT_FIXED
Inpu
When removing the tidss driver, there is a warning reported by
kernel about an unhandled interrupt for mhdp driver.
[ 43.238895] irq 31: nobody cared (try booting with the "irqpoll" option)
... [snipped backtrace]
[ 43.330735] handlers:
[ 43.333020] [<5367c4f9>] irq_default_primary_h
input_bus_flags are specified in drm_bridge_timings (legacy) as well
as drm_bridge_state->input_bus_cfg.flags
The flags from the timings will be deprecated. Bridges are supposed
to validate and set the bridge state flags from atomic_check.
Signed-off-by: Nikhil Devshatwar
---
drivers/gpu/drm/br
With new connector model, mhdp bridge will not create the connector and
SoC driver will rely on format negotiation to setup the encoder format.
Support minimal format negotiations hooks in the drm_bridge_funcs.
Complete format negotiation can be added based on EDID data.
This patch adds the minima
Remove the old code to iterate over the bridge chain, as this is
already done by the framework.
The bridge state should have the negotiated bus format and flags.
Use these from the bridge's state.
If the bridge does not support format negotiation, error out
and fail.
Signed-off-by: Nikhil Devshatw
To be able to support connector operations across multiple
bridges, it is recommended that the connector should be
created by the SoC driver instead of the bridges.
Modify the tidss modesetting initialization sequence to
create the connector and attach bridges with flag
DRM_BRIDGE_ATTACH_NO_CONNEC
Hi guys,
we are currently debugging a problem with some on screen artifacts and
I'm wondering if we have some sort of kmsdump tool already?
E.g. similar like kmsgrab which gets a reference to the DMA-buf file
descriptor which is currently displayed and then mmaping that or
importing it into
On Tue, Dec 1, 2020 at 11:27 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 01.12.20 um 11:00 schrieb Daniel Vetter:
> > On Tue, Dec 1, 2020 at 10:40 AM Thomas Zimmermann
> > wrote:
> >>
> >> Hi
> >>
> >> Am 01.12.20 um 10:10 schrieb Daniel Vetter:
> >>> On Tue, Dec 1, 2020 at 9:32 AM Thomas Zimmerma
Hi Daniel,
I've just pushed a minor TTM cleanup and dim is complaining that
drm-intel/drm-intel-gt-next merge into drm-tip failed.
Investigating that looks like something completely unrelated and I don't
know the Intel code well enough to fix it myself.
How to we proceed?
Thanks,
Christian
On Tue, Dec 1, 2020 at 2:32 PM Christian König
wrote:
>
> Daniel added a warning for this, but we were abusing that behavior here.
>
> Signed-off-by: Christian König
> Fixes: 57fcd550eb15 ("drm/ttm: Warn on pinning without holding a reference")
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 4 +++-
On Tue, Dec 1, 2020 at 5:58 PM Christian König wrote:
>
> Hi Daniel,
>
> I've just pushed a minor TTM cleanup and dim is complaining that
> drm-intel/drm-intel-gt-next merge into drm-tip failed.
>
> Investigating that looks like something completely unrelated and I don't
> know the Intel code well
On Tue, Dec 1, 2020 at 6:22 PM Daniel Vetter wrote:
>
> On Tue, Dec 1, 2020 at 5:58 PM Christian König
> wrote:
> >
> > Hi Daniel,
> >
> > I've just pushed a minor TTM cleanup and dim is complaining that
> > drm-intel/drm-intel-gt-next merge into drm-tip failed.
> >
> > Investigating that looks
On Fri, Nov 27, 2020 at 05:35:28PM +0100, Daniel Vetter wrote:
> Purely conjecture, but I think the original locking inversion with the
> legacy page flip code between flipping and ttm's bo move function
> shoudn't exist anymore with atomic: With atomic the bo pinning and
> actual modeset commit is
On Tue, Dec 1, 2020 at 6:56 AM Kevin Tang wrote:
>
> Hi Rob,
>
> Rob Herring 于2020年12月1日周二 上午4:31写道：
>>
>> On Mon, Nov 30, 2020 at 7:29 AM Kevin Tang wrote:
>> >
>> > From: Kevin Tang
>> >
>> > Adds MIPI DSI Master and MIPI DSI-PHY (D-PHY)
>> > support for Unisoc's display subsystem.
>> >
>> >
On Tue, Dec 1, 2020 at 12:36 AM Kevin Tang wrote:
>
> Hi Rob
>
> Rob Herring 于2020年12月1日周二 上午4:29写道：
> >
> > On Mon, Nov 30, 2020 at 7:28 AM Kevin Tang wrote:
> > >
> > > From: Kevin Tang
> >
> > Once again, DT patches must Cc the DT list if you want them reviewed.
> Ok, i will add DT list to m
Am 01.12.20 um 17:58 schrieb Daniel Vetter:
On Tue, Dec 1, 2020 at 2:32 PM Christian König
wrote:
Daniel added a warning for this, but we were abusing that behavior here.
Signed-off-by: Christian König
Fixes: 57fcd550eb15 ("drm/ttm: Warn on pinning without holding a reference")
---
drivers/
On Thu, Nov 26, 2020 at 8:44 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c: In
> function ‘dm_dtn_log_append_v’:
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:345:2:
> war
Hi,
On Mon, Nov 30, 2020 at 10:26 AM Sam Ravnborg wrote:
>
> When applying a patch to add the BOE NV110WTM-N61 panel I forgot
> to add the changes that added flags to drm_display_mode.
Sorry, I didn't mean to make more work for you!
> Signed-off-by: Sam Ravnborg
> Fixes: a96ee0f6b58d ("drm: p
Am 01.12.20 um 19:42 schrieb Alex Deucher:
On Thu, Nov 26, 2020 at 8:44 AM Lee Jones wrote:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c: In
function ‘dm_dtn_log_append_v’:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu
Am 30.11.20 um 21:56 schrieb Zack Rusin:
On Nov 25, 2020, at 07:59, Christian König
wrote:
According to Daniel VMWGFX doesn't support DMA-buf anyway.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
On Tue, Dec 1, 2020 at 1:59 PM Christian König wrote:
>
> Am 01.12.20 um 19:42 schrieb Alex Deucher:
> > On Thu, Nov 26, 2020 at 8:44 AM Lee Jones wrote:
> >> Fixes the following W=1 kernel build warning(s):
> >>
> >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c: In
> >>
On 30/11/2020 11:46, Laurent Pinchart wrote:
> Hi Nikhil,
>
> On Mon, Nov 30, 2020 at 12:05:03PM +0530, Nikhil Devshatwar wrote:
>> On 14:51-20201125, Tomi Valkeinen wrote:
>>> On 19/11/2020 18:01, Nikhil Devshatwar wrote:
Remove the old code to iterate over the bridge chain, as this is
On Tue, 1 Dec 2020, Mikulas Patocka wrote:
> When I try to run Xorg (from Debian 9) with the kernel 5.10-rc6, it
> doesn't work at all, I get this crash:
I tried to rux Xorg on another machine (with up-to-date Debian ports) and
it didn't crash on unplug.
Mikulas
___
Hi Doug,
On Tue, Dec 01, 2020 at 10:53:17AM -0800, Doug Anderson wrote:
> Hi,
>
> On Mon, Nov 30, 2020 at 10:26 AM Sam Ravnborg wrote:
> >
> > When applying a patch to add the BOE NV110WTM-N61 panel I forgot
> > to add the changes that added flags to drm_display_mode.
>
> Sorry, I didn't mean t
Before drm got helpers for removing conflicting pci framebuffer devices
we implemented something known as "stealth" mode which allowed vmwgfx
to run even if it couldn't reserve pci resources. We can just switch
to regular drm helpers instead of keeping the stealth mode alive as
it makes our code a
Throttling was used before fencing to implement early vsync
support in the xorg state tracker a long time ago. The xorg
state tracker has been removed years ago and no one else
has ever used throttling. It's time to remove this code,
it hasn't been used or tested in years.
Signed-off-by: Zack Rusi
From: Roland Scheidegger
Reviewed-by: Zack Rusin
Signed-off-by: Roland Scheidegger
Signed-off-by: Zack Rusin
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2daa6ee673f7..55e3e2ef5f18 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5712,6 +57
Instead of doing it in multiple spots lets centralize the code
to handle pci resources. This also cleans up the error
handling a bit and will make it a lot easier to add additional
svga versions to the driver.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Roland Scheidegger
We can't be setting the display_id register to an invalid value
because that makes our device reset the fb which causes nasty
flicker (due to destruction and creation of a new fb).
Also we can't be using the BITS_PER_PIXEL register if the
8BIT_EMULATION is not supported.
Signed-off-by: Zack Rusin
Going forward the svga device might reuse mmio for general
register accesses, in order to prepare for that we need to
cleanup our naming and handling of fifo specific mmio reads
and writes. As part of this work lets switch to managed
mapping of the fifo mmio to make the error handling cleaner.
Sig
To cleanup some of the error handling and prepare for some
other work lets switch to a managed drm device. It will
let us get a better handle on some of the error paths.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdb
Lets try to cleanup the usage of the term FIFO which we used for
both our MMIO based cmd queue processing and for general
command processing which could have been using command buffers
interface. We're going to rename the functions which are processing
commands (and work either via MMIO or command
On 30/11/2020 22:57, Dmitry Osipenko wrote:
> 01.12.2020 00:17, Jon Hunter пишет:
>> Hi Dmitry,
>>
>> On 23/11/2020 00:27, Dmitry Osipenko wrote:
>>> Add EMC OPP DVFS tables and update board device-trees by removing
>>> unsupported OPPs.
>>>
>>> Signed-off-by: Dmitry Osipenko
>> This change is ge
I forgot to add these when posting up the support for BOE
NV110WTM-N61. Add them now.
Fixes: a96ee0f6b58d ("drm: panel: simple: Add BOE NV110WTM-N61")
Signed-off-by: Douglas Anderson
Cc: Douglas Anderson
Cc: Sam Ravnborg
Cc: Thierry Reding
Cc: dri-devel@lists.freedesktop.org
---
Changes in v
Hi,
On Tue, Dec 1, 2020 at 12:28 PM Sam Ravnborg wrote:
>
> Hi Doug,
>
> On Tue, Dec 01, 2020 at 10:53:17AM -0800, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Nov 30, 2020 at 10:26 AM Sam Ravnborg wrote:
> > >
> > > When applying a patch to add the BOE NV110WTM-N61 panel I forgot
> > > to add t
In commit 131f909ad55f ("drm: panel: simple: Fixup the struct
panel_desc kernel doc") I transitioned the more deeply nested
kerneldoc comments into the inline style. Apparently it is desirable
to continue the job and move _everything_ in this struct to inline.
Let's do it.
While doing this, we al
Hi,
On Sun, Nov 29, 2020 at 2:10 PM Sam Ravnborg wrote:
>
> Hi Douglas,
> On Mon, Nov 09, 2020 at 05:00:55PM -0800, Douglas Anderson wrote:
> > When I run:
> > scripts/kernel-doc -rst drivers/gpu/drm/panel/panel-simple.c
> >
> > I see that several of the kernel-doc entries aren't showing up bec
https://bugzilla.kernel.org/show_bug.cgi?id=201539
fawz (f...@negentropy.io) changed:
What|Removed |Added
CC||f...@negentropy.io
--- Commen
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #58 from fawz (f...@negentropy.io) ---
Created attachment 293895
--> https://bugzilla.kernel.org/attachment.cgi?id=293895&action=edit
patch to fix pwm1_enable being stuck to AUTO for some gpu smu7 and vega10
Seems to work fine for s
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #59 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 293903
--> https://bugzilla.kernel.org/attachment.cgi?id=293903&action=edit
possible fix
The attached patch should fix it.
--
You are receiving this mail because
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #60 from MasterCATZ (masterc...@hotmail.com) ---
seems a bit random for me 5.8.17-050817-generic
sometimes I can spend weeks with fan control then all of a sudden I find it
hitting 100deg because it keeps spinning back down to 20% ra
Update the qos remap only if the client type changes for the plane.
This will avoid unnecessary register programming and also avoid log
spam from the dpu_vbif_set_qos_remap() function.
changes in v2:
- get rid of the dirty flag and simplify the logic to call
_dpu_plane_set_qos_remap()
Signed-
Hi Zack,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on tegra-drm/drm/tegra/for-next linus/master v5.10-rc6]
[cannot apply to drm-exynos/exynos-drm-next drm-tip/drm-tip drm/drm-next
next-20201201]
[If your patch is
> -Original Message-
> From: Jason Gunthorpe
> Sent: Tuesday, December 01, 2020 4:39 PM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig
> ; Vetter, Daniel
>
> Subject: Re: [PATC
On Tue, Dec 01, 2020 at 06:24:56PM +0100, Daniel Vetter wrote:
> On Tue, Dec 1, 2020 at 6:22 PM Daniel Vetter wrote:
> >
> > On Tue, Dec 1, 2020 at 5:58 PM Christian König
> > wrote:
> > >
> > > Hi Daniel,
> > >
> > > I've just pushed a minor TTM cleanup and dim is complaining that
> > > drm-int
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #61 from MasterCATZ (masterc...@hotmail.com) ---
Now it just runs 100% @ 300mhz core 100mhz memory @ ~60deg
aio@aio:/sys/class/drm/card0/device/hwmon/hwmon1$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
Vcore: 1.38 V
Vsoc
To cleanup some of the error handling and prepare for some
other work lets switch to a managed drm device. It will
let us get a better handle on some of the error paths.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdb
Hi Zack,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on tegra-drm/drm/tegra/for-next linus/master v5.10-rc6]
[cannot apply to drm-exynos/exynos-drm-next drm-tip/drm-tip drm/drm-next
next-20201201]
[If your patch
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #62 from MasterCATZ (masterc...@hotmail.com) ---
HEAD is now at 1398820fee51 Linux 5.9.9
aio@aio:/SnapRaidArray/DATA/git/linux-stable$ git apply --stat
/SnapRaidArray/DATA/Downloads/
Display all 583 possibilities? (y or n)
aio@aio:/Sna
https://bugzilla.kernel.org/show_bug.cgi?id=201539
--- Comment #63 from Alex Deucher (alexdeuc...@gmail.com) ---
yes, you'll need to adjust the path for pre 5.10 kernels.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
Hi
Am 02.12.20 um 03:54 schrieb tiantao (H):
在 2020/12/2 10:06, tiantao (H) 写道:
在 2020/12/1 21:44, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 14:05 schrieb tiantao (H):
在 2020/12/1 20:36, Thomas Zimmermann 写道:
Hi
Am 01.12.20 um 13:26 schrieb tiantao (H):
在 2020/12/1 20:17, Thomas Zim
Hi
Am 01.12.20 um 12:20 schrieb Mikulas Patocka:
On Tue, 1 Dec 2020, Thomas Zimmermann wrote:
Hi
Am 30.11.20 um 19:39 schrieb Mikulas Patocka:
On Mon, 30 Nov 2020, Daniel Vetter wrote:
On Mon, Nov 30, 2020 at 09:31:15AM -0500, Mikulas Patocka wrote:
The framebuffer driver supports pr
101 - 186 of 186 matches
Mail list logo
