On Tue, 8 Sep 2020 at 18:41, Hans Verkuil wrote:
>
> On 01/09/2020 08:22, Sam McNally wrote:
> > From: Hans Verkuil
> >
> > Signed-off-by: Hans Verkuil
> > [sa...@chromium.org:
> > - rebased
> > - removed polling-related changes
> > - moved the calls to drm_dp_cec_(un)set_edid() into the next
On Wed, 2 Sep 2020 at 04:12, Lyude Paul wrote:
>
> Super minor nitpicks:
>
> On Tue, 2020-09-01 at 16:22 +1000, Sam McNally wrote:
> > From: Hans Verkuil
> >
> > Signed-off-by: Hans Verkuil
> > [sa...@chromium.org:
> > - rebased
> > - removed polling-related changes
> > - moved the calls to d
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 Miklos has queued, these tree virtio patches for shared memory
> > region in his tree as part of virtiofs dax patch series.
> >
> > I am hoping this
Thanks. I'm retesting with these changes now; I'll also apply analogous
changes where applicable to the other x86 platform driver I have out for
review.
On 9/2/20 1:37 PM, Andy Shevchenko wrote:
External email: Use caution opening links or attachments
On Wed, Sep 2, 2020 at 8:37 PM Daniel Da
>Better guess. Secondary CSC registers are from 0xF.
>
>Signed-off-by: Martin Cerveny
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-
On Tue, 2020-09-08 at 11:43 +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:
>
> http://git.infradead.org/us
[Sorry for the late response]
On 8/21/20 11:06 AM, David Hildenbrand wrote:
> On 03.08.20 07:03, Dan Williams wrote:
>> @@ -37,109 +45,94 @@ int dev_dax_kmem_probe(struct device *dev)
>> * could be mixed in a node with faster memory, causing
>> * unavoidable performance issues.
>>
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..9367ac801f0c 100644
>> --- a/drivers/gpu/drm/i915/i915_scatterlist.h
>> +++ b/drivers/gpu/drm/i915/i915_scatterlist.h
>> @@ -27,13 +27,19
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 please clarify the current status
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..9367ac801f0c 100644
>
On Mon, Sep 07, 2020 at 11:29:06AM -0700, Florian Fainelli wrote:
>
>
> On 9/7/2020 10:43 AM, Jim Quinlan wrote:
> > On Mon, Sep 7, 2020 at 5:16 AM Lorenzo Pieralisi
> > wrote:
> > >
> > > On Thu, Aug 27, 2020 at 09:29:59AM -0400, Jim Quinlan wrote:
> > > > On Thu, Aug 27, 2020 at 2:35 AM Chris
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()
>
Does it make sense to have timeout in microseconds?
On Thu, 2020-09-03 at 10:01 +0200, Maxime Ripard wrote:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> The VEC and PV3 are left out for now, since it will require a more specific
> clock setup.
>
> Reviewed-by: Dave Stevenson
> Teste
05.09.2020 13:34, Mikko Perttunen пишет:
> + job->timeout = min(args->timeout_us / 1000, 1U);
> + if (job->timeout == 0)
> + job->timeout = 1;
clamp()
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freede
On Mon, 7 Sep 2020, Ville Syrjälä wrote:
> On Fri, Sep 04, 2020 at 12:21:26AM -0700, Zwane Mwaikambo wrote:
> > I observed this when unplugging a DP monitor whilst a computer is asleep
> > and then waking it up. This left DP chardev nodes still being present on
> > the filesystem and accessing t
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 defined in the public
>> header. T
> In the function intel_vgpu_reg_rw_edid of gvt/kvmgt.c, pos can get equal to
> NULL for GPUs that do not
> properly support EDID. …
* I propose to reconsider the previous patch subject once more.
* Did the script “checkpatch.pl” point any adjustment possibilities out
for the change descriptio
On Tue, 2020-09-01 at 13:07 +0900, Hoegeun Kwon wrote:
> Hi everyone,
>
> There is a problem that the output does not work at a resolution
> exceeding FHD. To solve this, we need to adjust the bvb clock at a
> resolution exceeding FHD.
>
> Rebased on top of next-20200708 and [1].
>
> [1] : [PATC
Hi Hoegeun,
On Mon, Sep 07, 2020 at 08:49:12PM +0900, Hoegeun Kwon wrote:
> On 9/3/20 5:00 PM, Maxime Ripard wrote:
> > Hi everyone,
> >
> > Here's a (pretty long) series to introduce support in the VC4 DRM driver
> > for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
> >
05.09.2020 13:34, Mikko Perttunen пишет:
> +int tegra_drm_ioctl_channel_submit(struct drm_device *drm, void *data,
> +struct drm_file *file)
> +{
> + struct tegra_drm_file *fpriv = file->driver_priv;
> + struct drm_tegra_channel_submit *args = data;
> + s
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 relocations need to be
patched? Could you pl
In the function intel_vgpu_reg_rw_edid of gvt/kvmgt.c, pos can get equal to
NULL for GPUs that do not
properly support EDID. In those cases, when pos gets passed to the handle_edid
functions, it
gets added a short offset then it's dereferenced in memcpy's, leading to a
kernel
oops: null pointer
>"Allwinner V3s" has secondary video layer (VI).
>Decoded video is displayed in wrong colors until
>secondary CSC registers are programmed correctly.
>
>Signed-off-by: Martin Cerveny
Following tag should be added:
Fixes: 883029390550 ("drm/sun4i: Add DE2 CSC library")
Reviewed-by: Jernej Skrabec
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,
> +struct drm_te
Why is dri-devel on here? And linaro-mm-sig?
Quoting Roja Rani Yarubandi (2020-09-07 06:07:31)
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index dead5db3315a..b3609760909f 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i
On Tue, 2020-09-01 at 13:07 +0900, Hoegeun Kwon wrote:
> To use QHD or higher, we need to modify the pixel_bvb_clk value. So
> add register to control this clock.
>
> Signed-off-by: Hoegeun Kwon
> ---
> drivers/clk/bcm/clk-raspberrypi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/d
Reviewed-by: Alyssa Rosenzweig
> This adds the required GPU quirks, including the quirk in the PWR registers
> at the GPU
> reset time and the IOMMU quirk for shareability issues observed on G52 in
> Amlogic G12B SoCs.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/panfrost/panfros
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 *tegra = drm->dev_private;
> + struct
On Tue, 8 Sep 2020, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On 8/10/20 11:21 AM, kernel test robot wrote:
> > From: kernel test robot
> >
> > drivers/video/fbdev/core/fbcon.c:3509:8-16: WARNING: use scnprintf or
> > sprintf
> > drivers/video/fbdev/core/fbcon.c:3484:8-16: WARNING: use scn
> Since the documentation of the GPU cores are not public, we do not know what
> does these
> values, but they permit having a fully functional GPU running with Panfrost.
Since this is Amlogic magic, not specifically GPU, I'd rephrase this as
"Since the Amlogic's integration of the GPU cores with
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.
Wouldn't it be a good idea to make both
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 of error.
Maybe it would be better if dr
Quoting Kuogee Hsieh (2020-09-04 12:54:39)
> add event thread to execute events serially from event queue. Also
> timeout mode is supported which allow an event be deferred to be
> executed at later time. Both link and phy compliant tests had been
> done successfully.
>
> Changes in v2:
> - Fix p
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 s
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 +-
dri
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:
>
> http://git.infradead
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 semico
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 DP_EXTENDED_RECEIVER_CAP_FI
laurent,
Please review or give some feedback.
On Tue, Aug 25, 2020 at 7:57 PM Vinay Simha B N wrote:
> laurent,
>
> Please review or give some feedback.
>
> On Thu, Aug 13, 2020 at 9:09 PM Vinay Simha B N
> wrote:
> >
> > laurent,
> >
> > The code sequence was a problem. *num_inputs_fmts =
> >
Remove duplicate header which is included twice.
Signed-off-by: Chen Zhou
---
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hwseq.c
index a5d75
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
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
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
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
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(-)
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
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
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
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
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 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
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: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 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 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 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 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 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 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: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
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
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
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
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 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
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 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 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 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 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 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 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
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
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
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
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
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
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 ++
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
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 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,
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
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
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
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 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 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
-
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 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
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
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
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
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
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 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
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
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
1 - 100 of 140 matches
Mail list logo
