On Thu, Sep 10, 2020 at 06:35:21AM +0800, Chun-Kuang Hu wrote:
> Hi, Andrzej & Neil:
>
> Enric Balletbo i Serra 於 2020年8月26日 週三
> 下午4:53寫道：
>
> >
> > Convert mtk_dpi to a bridge driver with built-in encoder support for
> > compatibility with existing component drivers.
> >
>
> This is a
On Wed, Sep 09, 2020 at 08:19:00PM +0800, Zheng Bin wrote:
> Fixes coccicheck warning:
>
> drivers/gpu/drm/bridge/tc358775.c:488:2-3: Unneeded semicolon
>
> Signed-off-by: Zheng Bin
Queued for 5.10, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/bridge/tc358775.c | 2 +-
> 1 file
On Thu, 10 Sep 2020 at 00:07, Jeremy Cline wrote:
>
> On Wed, Sep 09, 2020 at 10:22:14AM +0200, Karol Herbst wrote:
> > On Wed, Sep 9, 2020 at 6:06 AM Ben Skeggs wrote:
> > >
> > > On Thu, 13 Aug 2020 at 06:50, Jeremy Cline wrote:
> > > >
> > > > Commit d32656373857 ("drm/nouveau/therm/gp100:
https://bugzilla.kernel.org/show_bug.cgi?id=209163
--- Comment #8 from Satish patel (satish...@outlook.in) ---
(In reply to Christian König from comment #6)
> You are running out of VRAM, not system memory.
>
> Can you test this on an up to date kernel as well?
Is there any way to restrict not
Hi all,
Today's linux-next merge of the extcon tree got a conflict in:
MAINTAINERS
between commit:
f61249dddecc ("MAINTAINERS: Add entry for i.MX 8MQ DCSS driver")
from the drm-misc tree and commit:
d0e3c25150dd ("MAINTAINERS: Add entry for NXP PTN5150A CC driver")
from the extcon
https://bugzilla.kernel.org/show_bug.cgi?id=209163
--- Comment #7 from Satish patel (satish...@outlook.in) ---
Created attachment 292449
--> https://bugzilla.kernel.org/attachment.cgi?id=292449=edit
VRAM Utilization screen shot
It's attached VRAM Utilization error screen shot as output of -
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.
v2: Rebased patch on top of
For the two armada patches.
Reviewed-by: Dave Airlie
On Sat, 5 Sep 2020 at 00:40, Daniel Vetter wrote:
>
> Also remove the now no longer needed build bug on since that's already
> not needed anymore with drmm_add_final_kfree. Conversion to managed
> drm_device cleanup is easy, the final
On Tue, Sep 8, 2020 at 12:07 AM Gerd Hoffmann wrote:
>
>
> Gerd Hoffmann (3):
> drm/virtio: use drmm_mode_config_init
> drm/virtio: return virtio_gpu_queue errors
> drm/virtio: add virtio_gpu_cmd_unref_resource error handling
>
lgtm +/- nits:
- add a simple "why" in the first commit
On Wed, Sep 9, 2020 at 2:28 AM Daniel Vetter wrote:
> On Wed, Sep 9, 2020 at 11:27 AM Daniel Vetter wrote:
> >
> > On Wed, Sep 09, 2020 at 09:13:11AM +0200, Miklos Szeredi wrote:
> > > On Wed, Sep 9, 2020 at 9:04 AM Gerd Hoffmann
> wrote:
> > > >
> > > > On Wed, Sep 02, 2020 at 05:00:25PM
Hi Laurent,
> > Author: Kuninori Morimoto
> > Date: Tue Sep 8 09:34:11 2020 +0900
> >
> > dt-bindings: display: renesas: dw-hdmi: Tidyup example compatible
> >
> > The DT example erronously uses the "renesas,r8a7795-dw-hdmi", when the
> > correct value is
Debug amdgpu_dm could be a complicated task, therefore, this commit adds
tracepoints in some convenient functions such as plane and connector
check inside amdgpu_dm.
Co-developed-by: Nicholas Kazlauskas
Signed-off-by: Nicholas Kazlauskas
Signed-off-by: Rodrigo Siqueira
---
amdgpu_dc_rreg and amdgpu_dc_wreg are very similar, for this reason,
this commits abstract these two events by using DECLARE_EVENT_CLASS and
create an instance of it for each one of these events.
Signed-off-by: Rodrigo Siqueira
---
.../amd/display/amdgpu_dm/amdgpu_dm_trace.h | 55
Debug issues related to display can be a challenge due to the complexity
around this topic and different source of information might help in this
process. We already have support for tracepoints inside the display
component, i.e., we have the basic functionalities available and we just
need to
This commit introduces a trace mechanism for struct pipe_ctx by adding a
middle layer struct in the amdgpu_dm_trace.h for capturing the most
important data from struct pipe_ctx and showing its data via tracepoint.
This tracepoint was added to dc.c and dcn10_hw_sequencer, however, it
can be added
On Wed, 2020-09-09 at 19:36 -0300, Jason Gunthorpe wrote:
> On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
> > fallthrough to a separate case/default label break; isn't very readable.
> >
> > Convert pseudo-keyword fallthrough; statements to a simple break; when
> > the next label
Hi, Andrzej & Neil:
Enric Balletbo i Serra 於 2020年8月26日 週三 下午4:53寫道：
>
> Convert mtk_dpi to a bridge driver with built-in encoder support for
> compatibility with existing component drivers.
>
This is a DRM-bridge related patch, how do you think about it?
Regards,
Chun-Kuang.
> Reviewed-by:
Hi, Andrzej & Neil:
Enric Balletbo i Serra 於 2020年8月26日 週三 下午4:53寫道：
>
> This is really a cosmetic change just to make a bit more readable the
> code after convert the driver to drm_bridge. The bridge variable name
> will be used by the encoder drm_bridge, and the chained bridge will be
> named
On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
> index eea0f453cfb6..8aac5bc60f4c 100644
> --- a/crypto/tcrypt.c
> +++ b/crypto/tcrypt.c
> @@ -2464,7 +2464,7 @@ static int do_test(const char *alg, u32 type, u32 mask,
> int m, u32
On 9/9/20 15:06, Joe Perches wrote:
> fallthrough to a separate case/default label break; isn't very readable.
>
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is break;
>
> Found
On Fri, Aug 28, 2020 at 02:13:31PM +0300, Robert Chiras (OSS) wrote:
> From: Robert Chiras
>
> Add documentation for a new property: 'fsl,clock-drop-level'.
>
> Signed-off-by: Robert Chiras
> ---
> Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml | 4
> 1 file changed, 4
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$ grep-2.5.4 -rP --include=*.[ch] -n
On Wed, 2020-09-09 at 21:36 +0300, Ville Syrjälä wrote:
> On Wed, Sep 09, 2020 at 02:26:11PM -0400, Lyude Paul wrote:
> > On Wed, 2020-09-09 at 21:20 +0300, Ville Syrjälä wrote:
> > > On Wed, Sep 09, 2020 at 12:33:09PM -0400, Lyude Paul wrote:
> > > > We just added a new helper for DPCD
On Wed, Sep 09, 2020 at 02:26:11PM -0400, Lyude Paul wrote:
> On Wed, 2020-09-09 at 21:20 +0300, Ville Syrjälä wrote:
> > On Wed, Sep 09, 2020 at 12:33:09PM -0400, Lyude Paul wrote:
> > > We just added a new helper for DPCD retrieval to drm_dp_helper.c (which
> > > also
> > > handles grabbing the
https://bugzilla.kernel.org/show_bug.cgi?id=209163
--- Comment #6 from Christian König (christian.koe...@amd.com) ---
You are running out of VRAM, not system memory.
Can you test this on an up to date kernel as well?
--
You are receiving this mail because:
You are watching the assignee of the
On Wed, 2020-09-09 at 21:20 +0300, Ville Syrjälä wrote:
> On Wed, Sep 09, 2020 at 12:33:09PM -0400, Lyude Paul wrote:
> > We just added a new helper for DPCD retrieval to drm_dp_helper.c (which
> > also
> > handles grabbing the extended receiver caps), we should probably make use
> > of
> > it
On Wed, Sep 09, 2020 at 12:33:09PM -0400, Lyude Paul wrote:
> We just added a new helper for DPCD retrieval to drm_dp_helper.c (which also
> handles grabbing the extended receiver caps), we should probably make use of
> it here
Someone should really rework this whole thing so that the driver can
https://bugzilla.kernel.org/show_bug.cgi?id=209163
--- Comment #5 from Satish patel (satish...@outlook.in) ---
(In reply to Christian König from comment #4)
> This is expected behavior, your application tries to use more memory than
> physical available:
>
> [71804.930003] [drm:amdgpu_cs_ioctl
We just added a new helper for DPCD retrieval to drm_dp_helper.c (which also
handles grabbing the extended receiver caps), we should probably make use of
it here
On Wed, 2020-09-09 at 14:31 +0800, Koba Ko wrote:
> On Thu, Aug 27, 2020 at 1:30 PM Koba Ko wrote:
> > Currently, DRM get the
On 09/09, Daniel Vetter wrote:
> On Wed, Sep 9, 2020 at 1:01 PM Melissa Wen wrote:
> >
> > Hi Daniel,
> >
> > looks good to me, just a few things inline.
> >
> > On 09/04, Daniel Vetter wrote:
> > > This means we also need to slightly restructure the exit code, so that
> > > final cleanup of the
Hi Kieran,
On Wed, Sep 09, 2020 at 05:06:01PM +0100, Kieran Bingham wrote:
> On 09/09/2020 13:08, Ville Syrjälä wrote:
> > On Tue, Sep 08, 2020 at 05:05:48PM +0100, Kieran Bingham wrote:
> >> On 08/09/2020 16:52, Laurent Pinchart wrote:
> >>> On Tue, Sep 08, 2020 at 04:42:58PM +0100, Kieran
Hi Ville, Laurent,
On 09/09/2020 13:08, Ville Syrjälä wrote:
> On Tue, Sep 08, 2020 at 05:05:48PM +0100, Kieran Bingham wrote:
>> Hi Laurent,
>>
>> On 08/09/2020 16:52, Laurent Pinchart wrote:
>>> Hi Kieran,
>>>
>>> On Tue, Sep 08, 2020 at 04:42:58PM +0100, Kieran Bingham wrote:
On
On Fri, 28 Aug 2020 11:37:45 +0530, Viresh Kumar wrote:
> This cleans up some of the user code around calls to
> dev_pm_opp_of_remove_table().
>
> All the patches can be picked by respective maintainers directly except
> for the last patch, which needs the previous two to get merged first.
>
>
On Wed, Sep 9, 2020 at 4:45 PM Daniel Thompson
wrote:
>
> On Mon, Sep 07, 2020 at 09:50:18AM +0200, Daniel Vetter wrote:
> > On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote:
> > > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote:
> > > > Some displays need the low
Hi Laurentiu,
On Mo, 2020-08-31 at 14:24 +0300, Laurentiu Palcu wrote:
> Hi Lucas, Sam,
>
> On Mon, Aug 31, 2020 at 12:37:23PM +0200, Lucas Stach wrote:
> > Hi Laurentiu,
> >
> > On Fr, 2020-08-28 at 11:36 +0300, Laurentiu Palcu wrote:
> > > Hi Lucas,
> > >
> > > I was wondering about the
Hi Georgi,
On 09.09.2020 11:07, Georgi Djakov wrote:
> On 8/28/20 17:49, Sylwester Nawrocki wrote:
>> On 30.07.2020 14:28, Sylwester Nawrocki wrote:
>>> On 09.07.2020 23:04, Rob Herring wrote:
On Thu, Jul 02, 2020 at 06:37:19PM +0200, Sylwester Nawrocki wrote:
> Add documentation for new
On Mon, Sep 07, 2020 at 09:50:18AM +0200, Daniel Vetter wrote:
> On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote:
> > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote:
> > > Some displays need the low end of the curve cropped in order to make
> > > them happy. In that
On Wed, Sep 09, 2020 at 10:22:14AM +0200, Karol Herbst wrote:
> On Wed, Sep 9, 2020 at 6:06 AM Ben Skeggs wrote:
> >
> > On Thu, 13 Aug 2020 at 06:50, Jeremy Cline wrote:
> > >
> > > Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
> > > new gp1xx temperature sensor")
Acked-by: Christian König for the series.
Am 09.09.20 um 15:07 schrieb Zheng Bin:
Zheng Bin (8):
drm/amd/amdgpu: fix comparison pointer to bool warning in gfx_v9_0.c
drm/amd/amdgpu: fix comparison pointer to bool warning in gfx_v10_0.c
drm/amd/amdgpu: fix comparison pointer to bool
On 09/09/2020 10:16, Tvrtko Ursulin wrote:
On 08/09/2020 23:43, Tom Murphy wrote:
On Tue, 8 Sep 2020 at 16:56, Tvrtko Ursulin
wrote:
On 08/09/2020 16:44, Logan Gunthorpe wrote:
On 2020-09-08 9:28 a.m., Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
The GPU 'CONFIG' registers used to work around hardware issues are
cleared on reset so need to be programmed every time the GPU is reset.
However panfrost_device_reset() failed to do this.
To avoid this in future instead move the call to
panfrost_gpu_init_quirks() to panfrost_gpu_power_on() so
Hi,
On 09/09/2020 14:23, Steven Price wrote:
> On 08/09/2020 16:18, Neil Armstrong wrote:
>> The T820, G31 & G52 GPUs integratewd by Amlogic in the respective GXM,
>> G12A/SM1 & G12B
>> SoCs needs a quirk in the PWR registers at the GPU reset time.
>>
>> Since the documentation of the GPU cores
On 09/09/2020 14:23, Steven Price wrote:
> Subject: s/BROKEN_NS/BROKEN_SH/
Thanks,
Neil
>
> Steve
>
> On 08/09/2020 16:18, Neil Armstrong wrote:
>> The coherency integration of the IOMMU in the Mali-G52 found in the Amlogic
>> G12B SoCs
>> is broken and leads to constant and random faults
On 09/09/2020 14:23, Steven Price wrote:
> On 08/09/2020 16:18, Neil Armstrong wrote:
>> The T820, G31 & G52 GPUs integratewd by Amlogic in the respective GXM,
>> G12A/SM1 & G12B
>> SoCs needs a quirk in the PWR registers at the GPU reset time.
>>
>> This adds a callback in the device compatible
Subject: s/BROKEN_NS/BROKEN_SH/
Steve
On 08/09/2020 16:18, Neil Armstrong wrote:
The coherency integration of the IOMMU in the Mali-G52 found in the Amlogic
G12B SoCs
is broken and leads to constant and random faults from the IOMMU.
Disabling shareability completely fixes the issue.
On 08/09/2020 16:18, Neil Armstrong wrote:
The T820, G31 & G52 GPUs integratewd by Amlogic in the respective GXM, G12A/SM1
& G12B
SoCs needs a quirk in the PWR registers at the GPU reset time.
Since the documentation of the GPU cores are not public, we do not know what
does these
values, but
On 08/09/2020 16:18, Neil Armstrong wrote:
The T820, G31 & G52 GPUs integratewd by Amlogic in the respective GXM, G12A/SM1
& G12B
SoCs needs a quirk in the PWR registers at the GPU reset time.
This adds a callback in the device compatible struct of permit this.
Signed-off-by: Neil Armstrong
On 08/09/2020 16:18, Neil Armstrong wrote:
Add a pgtbl_quirks entry in the compatible specific table to permit specyfying
IOMMU
quirks for platforms.
Signed-off-by: Neil Armstrong
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.h | 3 +++
On Tue, Sep 8, 2020 at 6:05 PM Kieran Bingham
wrote:
>
> Hi Laurent,
>
> On 08/09/2020 16:52, Laurent Pinchart wrote:
> > Hi Kieran,
> >
> > On Tue, Sep 08, 2020 at 04:42:58PM +0100, Kieran Bingham wrote:
> >> On 06/08/2020 03:26, Laurent Pinchart wrote:
> >>> When creating a frame buffer, the
On Tue, Sep 08, 2020 at 05:05:48PM +0100, Kieran Bingham wrote:
> Hi Laurent,
>
> On 08/09/2020 16:52, Laurent Pinchart wrote:
> > Hi Kieran,
> >
> > On Tue, Sep 08, 2020 at 04:42:58PM +0100, Kieran Bingham wrote:
> >> On 06/08/2020 03:26, Laurent Pinchart wrote:
> >>> When creating a frame
This means we also need to slightly restructure the exit code, so that
final cleanup of the drm_device is triggered by unregistering the
platform device. Note that devres is both clean up when the driver is
unbound (not the case for vgem, we don't bind), and also when unregistering
the device
Hi Paul,
I looked a bit at this patch
On Sat, Aug 22, 2020 at 6:33 PM Paul Cercueil wrote:
> +config DRM_MIPI_DBI_SPI
> + tristate "SPI host support for MIPI DBI"
> + depends on DRM && OF && SPI
I think you want to depend on SPI_HOST actually.
> + struct gpio_desc *dc;
On Sat, Aug 22, 2020 at 6:33 PM Paul Cercueil wrote:
> Add documentation for the Device Tree node for LCD panels based on the
> NewVision NV3052C controller.
>
> v2: - Support backlight property
> - Add *-supply properties for the 5 different power supplies.
> Either they must all be
Hi Paul,
just a drive-by comment:
On Sat, Aug 22, 2020 at 6:33 PM Paul Cercueil wrote:
> + gpiod_set_value_cansleep(priv->reset_gpiod, 0);
> + usleep_range(20, 1000);
> + gpiod_set_value_cansleep(priv->reset_gpiod, 1);
This implies that the reset line is active low.
I would
On Wed, Sep 9, 2020 at 1:01 PM Melissa Wen wrote:
>
> Hi Daniel,
>
> looks good to me, just a few things inline.
>
> On 09/04, Daniel Vetter wrote:
> > This means we also need to slightly restructure the exit code, so that
> > final cleanup of the drm_device is triggered by unregistering the
> >
On Tuesday, 2020-09-08 09:54 Neil Armstrong wrote:
> Shanghai Top Display Optolelectronics Co., Ltd is a display manufacturer
> from Shanghai.
> Web site of the company: http://www.shtdo.com/
>
> Signed-off-by: Neil Armstrong
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2
This patch adds support for reporting sclk values for Radeon GPUs, where
supported.
Signed-off-by: Sandeep Raghuraman
---
drivers/gpu/drm/radeon/radeon_pm.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
On Tue, Sep 8, 2020 at 5:43 AM Christoph Hellwig wrote:
>
> And because I like replying to myself so much, here is a link to the
> version with the arm cleanup patch applied. Unlike the previous two
> attempts this has at least survived very basic sanity testing:
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=209163
--- Comment #4 from Christian König (christian.koe...@amd.com) ---
This is expected behavior, your application tries to use more memory than
physical available:
[71804.930003] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Not enough memory for
command
Hi Daniel,
looks good to me, just a few things inline.
On 09/04, Daniel Vetter wrote:
> This means we also need to slightly restructure the exit code, so that
> final cleanup of the drm_device is triggered by unregistering the
> platform device. Note that devres is both clean up when the driver
Hi all,
I was wondering whether you could give me an advise on how to proceed further
with the following issue as I'm preparing to upstream the next set of patches
for the iMX8MQ display controller(DCSS). The display controller has 3 planes,
each with 2 CSCs and one degamma LUT. The CSCs are in
https://bugzilla.kernel.org/show_bug.cgi?id=209163
Satish patel (satish...@outlook.in) changed:
What|Removed |Added
Component|Video(DRI - non Intel) |Other
On 04/09/2020 13:00, Frank Wunderlich wrote:
From: Frank Wunderlich
mt7623a has no graphics support so move nodes from generic mt7623.dtsi
to mt7623n.dtsi
Fixes: 1f6ed224594 ("arm: dts: mt7623: add Mali-450 device node")
Suggested-by: David Woodhouse
Signed-off-by: Frank Wunderlich
On 04/09/2020 13:00, Frank Wunderlich wrote:
From: Alex Ryabchenko
GPU needs additional regulator, add it to devicetree of bpi-r2
Signed-off-by: Alex Ryabchenko
Signed-off-by: Frank Wunderlich
Applied to v5.9-next/dts32
Thanks!
---
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts |
On 04/09/2020 13:00, Frank Wunderlich wrote:
From: Ryder Lee
Add display subsystem related device nodes for MT7623.
Cc: Chun-Kuang Hu
Signed-off-by: chunhui dai
Signed-off-by: Bibby Hsieh
Signed-off-by: Ryder Lee
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
Applied
On 09/09/2020 11:29, Matthias Brugger wrote:
On 19/08/2020 10:17, Frank Wunderlich wrote:
From: Frank Wunderlich
mt7623a has no graphics support so move nodes from generic mt7623.dtsi
to mt7623n.dtsi
Fixes: 1f6ed224594 ("arm: dts: mt7623: add Mali-450 device node")
Suggested-by: David
On 19/08/2020 10:17, Frank Wunderlich wrote:
From: Frank Wunderlich
mt7623a has no graphics support so move nodes from generic mt7623.dtsi
to mt7623n.dtsi
Fixes: 1f6ed224594 ("arm: dts: mt7623: add Mali-450 device node")
Suggested-by: David Woodhouse
Signed-off-by: Frank Wunderlich
On 19/08/2020 10:17, Frank Wunderlich wrote:
From: Ryder Lee
Add display subsystem related device nodes for MT7623.
Cc: Chun-Kuang Hu
Signed-off-by: chunhui dai
Signed-off-by: Bibby Hsieh
Signed-off-by: Ryder Lee
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
Applied
On Wed, Sep 9, 2020 at 11:27 AM Daniel Vetter wrote:
>
> On Wed, Sep 09, 2020 at 09:13:11AM +0200, Miklos Szeredi wrote:
> > On Wed, Sep 9, 2020 at 9:04 AM Gerd Hoffmann wrote:
> > >
> > > On Wed, Sep 02, 2020 at 05:00:25PM -0700, Gurchetan Singh wrote:
> > > > On Wed, Sep 2, 2020 at 3:15 PM
On Wed, Sep 09, 2020 at 09:13:11AM +0200, Miklos Szeredi wrote:
> On Wed, Sep 9, 2020 at 9:04 AM Gerd Hoffmann wrote:
> >
> > On Wed, Sep 02, 2020 at 05:00:25PM -0700, Gurchetan Singh wrote:
> > > On Wed, Sep 2, 2020 at 3:15 PM Vivek Goyal wrote:
> > >
> > > > Hi Gurchetan,
> > > >
> > > > Now
On 09/09, Daniel Vetter wrote:
> This means we also need to slightly restructure the exit code, so that
> final cleanup of the drm_device is triggered by unregistering the
> platform device. Note that devres is both clean up when the driver is
> unbound (not the case for vkms, we don't bind), and
This means we also need to slightly restructure the exit code, so that
final cleanup of the drm_device is triggered by unregistering the
platform device. Note that devres is both clean up when the driver is
unbound (not the case for vkms, we don't bind), and also when unregistering
the device
On 08/09/2020 23:43, Tom Murphy wrote:
On Tue, 8 Sep 2020 at 16:56, Tvrtko Ursulin
wrote:
On 08/09/2020 16:44, Logan Gunthorpe wrote:
On 2020-09-08 9:28 a.m., Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915
index
Am 09.09.20 um 09:57 schrieb Tian Tao:
Fix kernel-doc warnings.
drivers/gpu/drm/scheduler/sched_fence.c:110: warning: Function parameter or
member 'f' not described in 'drm_sched_fence_release_scheduled'
drivers/gpu/drm/scheduler/sched_fence.c:110: warning: Excess function
parameter 'fence'
ping for review
Am 13.08.20 um 15:51 schrieb Thomas Zimmermann:
> Since converting the ast driver to atomic modesettting, modesetting
> occationally locks up the graphics hardware and turns the display
> permanently dark. This happens once or twice per 10 mode switches.
> Investigation shows that
On 9/9/20 5:20 AM, Dmitry Osipenko wrote:
05.09.2020 13:34, Mikko Perttunen пишет:
Hi all,
here's a second revision of the Host1x/TegraDRM UAPI proposal,
hopefully with most issues from v1 resolved, and also with
an implementation. There are still open issues with the
implementation:
* Relocs
On 9/9/20 2:36 AM, Dmitry Osipenko wrote:
05.09.2020 13:34, Mikko Perttunen пишет:
Hi all,
here's a second revision of the Host1x/TegraDRM UAPI proposal,
hopefully with most issues from v1 resolved, and also with
an implementation. There are still open issues with the
implementation:
Could
On 9/9/20 5:34 AM, Dmitry Osipenko wrote:
09.09.2020 05:10, Dmitry Osipenko пишет:
05.09.2020 13:34, Mikko Perttunen пишет:
+ job->timeout = min(args->timeout_us / 1000, 1U);
+ if (job->timeout == 0)
+ job->timeout = 1;
clamp()
Will fix.
Does it make
On 9/9/20 5:06 AM, Dmitry Osipenko wrote:
05.09.2020 13:34, Mikko Perttunen пишет:
+int tegra_drm_ioctl_channel_open(struct drm_device *drm, void *data,
+struct drm_file *file)
+{
+ struct tegra_drm_file *fpriv = file->driver_priv;
+ struct tegra_drm
On 9/9/20 4:24 AM, Dmitry Osipenko wrote:
09.09.2020 04:13, Dmitry Osipenko пишет:
...
How many sync points would use an average job? Maybe it should be better
to have the predefined array of sync points within the struct
drm_tegra_channel_submit?
The same question regarding the commands.
On Wed, Sep 9, 2020 at 6:06 AM Ben Skeggs wrote:
>
> On Thu, 13 Aug 2020 at 06:50, Jeremy Cline wrote:
> >
> > Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
> > new gp1xx temperature sensor") added support for reading finer-grain
> > temperatures, but continued to
On 9/9/20 3:47 AM, Dmitry Osipenko wrote:
05.09.2020 13:34, Mikko Perttunen пишет:
+static int submit_process_bufs(struct drm_device *drm, struct gather_bo *bo,
+ struct tegra_drm_job_data *job_data,
+ struct tegra_drm_channel_ctx *ctx,
On 9/9/20 3:16 AM, Dmitry Osipenko wrote:
05.09.2020 13:34, Mikko Perttunen пишет:
...
+static int vic_power_on(struct tegra_drm_client *client)
+{
+ struct vic *vic = to_vic(client);
+
+ return pm_runtime_get_sync(vic->dev);
Please keep in mind that RPM needs to be put in a case
On 9/9/20 2:45 AM, Dmitry Osipenko wrote:
05.09.2020 13:34, Mikko Perttunen пишет:
...
+/* Submission */
+
+/** Patch address of the specified mapping in the submitted gather. */
+#define DRM_TEGRA_SUBMIT_BUF_WRITE_RELOC (1<<0)
Shouldn't the kernel driver be aware about what
On 9/9/20 3:07 AM, Dmitry Osipenko wrote:
05.09.2020 17:53, Mikko Perttunen пишет:
...
Hello, Mikko!
What do you think about to open-code all the host1x structs by moving
them all out into the public linux/host1x.h? Then we could inline all
these trivial single-line functions by having them
Am 04.09.20 um 16:39 schrieb Daniel Vetter:
> Because it is.
Absolutely.
Acked-by: Thomas Zimmermann
>
> v2: Delete now unused crtc funcs (0day)
>
> Cc: Eugeniy Paltsev
> Signed-off-by: Daniel Vetter
> Cc: Alexey Brodkin
> ---
> MAINTAINERS | 2
On 09/09/2020 09:20, Sam McNally wrote:
> With DP v2.0 errata E5, CEC tunneling can be supported through an MST
> topology.
>
> There are some minor differences for CEC tunneling through an MST
> topology compared to CEC tunneling to an SST port:
> - CEC IRQs are delivered via a sink event notify
DP MST DDC I2C devices are not parented to their connectors. This makes
it challenging to associate the ddc i2c device with its connector from
userspace. With further refactoring, this can be changed, but in the
meantime, follow the pattern of commit e1a29c6c5955 ("drm: Add ddc link
in sysfs
With DP v2.0 errata E5, CEC tunneling can be supported through an MST
topology.
There are some minor differences for CEC tunneling through an MST
topology compared to CEC tunneling to an SST port:
- CEC IRQs are delivered via a sink event notify message
- CEC-related DPCD registers are accessed
Sink event notify messages are used for MST CEC IRQs. Add parsing
support for sink event notify messages in preparation for handling MST
CEC IRQs.
Signed-off-by: Sam McNally
---
(no changes since v1)
drivers/gpu/drm/drm_dp_mst_topology.c | 37 ++-
From: Hans Verkuil
These are required for the CEC MST support.
Signed-off-by: Hans Verkuil
Signed-off-by: Sam McNally
---
(no changes since v1)
drivers/gpu/drm/drm_dp_mst_topology.c | 6 ++
include/drm/drm_dp_mst_helper.h | 4
2 files changed, 6 insertions(+), 4 deletions(-)
From: Hans Verkuil
For adapters behind an MST hub use the correct AUX channel.
Signed-off-by: Hans Verkuil
[sa...@chromium.org: rebased, removing redundant changes]
Signed-off-by: Sam McNally
---
(no changes since v1)
drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
On Tue, 8 Sep 2020 at 18:08, Hans Verkuil wrote:
>
> Hi Sam,
>
> On 01/09/2020 08:22, Sam McNally wrote:
> > With DP v2.0 errata E5, CEC tunneling can be supported through an MST
> > topology.
>
> Oh wow, this is finally supported in the spec. Very nice to see this.
> Also very nice to see that
Hi,
> --- a/include/uapi/drm/virtgpu_drm.h
kernel <-> userspace API.
> --- a/include/uapi/linux/virtio_gpu.h
host <-> guest API.
Please create sepparate patches for these.
thanks,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Hi,
> +enum virtio_gpu_shm_id {
> + VIRTIO_GPU_SHM_ID_UNDEFINED = 0,
> + VIRTIO_GPU_SHM_ID_HOST_VISIBLE = 1
> +};
I think this is also not in the virtio spec update.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
05.09.2020 13:34, Mikko Perttunen пишет:
> Hi all,
>
> here's a second revision of the Host1x/TegraDRM UAPI proposal,
> hopefully with most issues from v1 resolved, and also with
> an implementation. There are still open issues with the
> implementation:
>
> * Relocs are now handled on TegraDRM
From: Randy Dunlap
Fix spellos of "function" in drivers/gpu/drm/amd/display/.
Signed-off-by: Randy Dunlap
Cc: Harry Wentland
Cc: Leo Li
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/dc/dml/dcn20/display_rq_dlg_calc_20.h |2 +-
On Tue, Sep 08, 2020 at 11:43:45AM +0200, Christoph Hellwig wrote:
> And because I like replying to myself so much, here is a link to the
> version with the arm cleanup patch applied. Unlike the previous two
> attempts this has at least survived very basic sanity testing:
>
>
On Mon, 24 Aug 2020 21:55:57 -0700, Joe Perches wrote:
> There are many comma separated statements in the kernel.
> See:https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2008201856110.2524@hadrien/
>
> Convert the comma separated statements that are in if/do/while blocks
> to use braces and
On Thu, Aug 27, 2020 at 1:30 PM Koba Ko wrote:
>
> Currently, DRM get the capability of the mst hub only from DP_DPCD_REV and
> get the slower speed even the mst hub can run in the faster speed.
>
> As per DP-1.3, First check DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT.
> If
1 - 100 of 136 matches
Mail list logo
