> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index e32ef3f01fe8..b13b1cbcac29 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -1785,7 +1785,7 @@ static int i801_probe(struct pci_dev *dev, const struct
> pci_device_id *id)
>
On Wed, Sep 09, 2020 at 09:41:37PM +0800, YueHaibing wrote:
> Kbuild warns when this file is built as a loadable module:
>
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/gpu/drm/panel/panel-samsung-s6e63m0.o
>
> Add the missing license/author/description tags.
>
> Fixes: b7b23e447687
On Wed, Sep 9, 2020 at 5:03 PM Lucas Stach wrote:
>
> 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
Em Wed, 09 Sep 2020 13:06:39 -0700
Joe Perches escreveu:
> 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 b
drm-misc-fixes-2020-09-09:
drm-misc-fixes for v5.9-rc5:
- Fix double free in virtio.
- Add missing put_device in sun4i, and other fixes.
- Small ingenic fixes.
- Handle sun4i alpha on lowest plane correctly.
- Remove output->enabled from virtio, as it should use crtc_state.
- Fix tve200 enable/disa
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 DRM-br
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 chan
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: in
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 u
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 tree
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&action=edit
VRAM Utilization screen shot
It's attached VRAM Utilization error screen shot as output o
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 Khaled
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 drm_dev
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 messag
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 -0700
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 "renesas,r8a7795-hdmi".
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
---
.../gpu/drm/amd/disp
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 expa
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 to
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 is
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: C
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 n
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 num_m
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 usi
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 inse
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
"fallthrou
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 retri
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 e
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 b
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 here
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 [a
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 capabili
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 d
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 Bingha
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 06/08/2020
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.
>
> Th
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 end
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 plans
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") adde
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 war
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
b/drivers/gpu
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 tha
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 ar
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 from
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 s
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.
Signed-o
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 t
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 +++
drivers/gpu/drm/panfrost
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 dri
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 buffe
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 (very
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;
This
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 pr
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
> > p
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
b/dr
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:
>
> http://git.infradead.org/user
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 s
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 i
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 fr
https://bugzilla.kernel.org/show_bug.cgi?id=209163
Satish patel (satish...@outlook.in) changed:
What|Removed |Added
Component|Video(DRI - non Intel) |Other
Pr
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
Appli
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 | 13
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 to
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 Woodh
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
Appli
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 to
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 Vive
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 Mi
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 a
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 (very
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 b7b59328cb76..9367ac
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' descr
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 you
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 sens
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.
Wo
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 repor
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 o
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 relo
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 def
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 create
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 vi
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 ++-
include/drm/drm_dp_mst
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 +++
1
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 my
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
https://lists.fre
1 - 100 of 140 matches
Mail list logo
