Re: [PATCH 1/8] drm/ttm: turn ttm_bo_device.vma_manager into a pointer
Am 05.09.19 um 09:05 schrieb Gerd Hoffmann:
Rename the embedded struct vma_offset_manager, new name is _vma_manager.
ttm_bo_device.vma_manager changed to a pointer.
The ttm_bo_device_init() function gets an additional vma_manager
argument which allows to initialize ttm with a different vma manager.
When passing NULL the embedded _vma_manager is used.
All callers are updated to pass NULL, so the behavior doesn't change.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
include/drm/ttm/ttm_bo_driver.h | 8 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 +
drivers/gpu/drm/drm_vram_mm_helper.c| 1 +
drivers/gpu/drm/nouveau/nouveau_ttm.c | 1 +
drivers/gpu/drm/qxl/qxl_ttm.c | 1 +
drivers/gpu/drm/radeon/radeon_ttm.c | 1 +
drivers/gpu/drm/ttm/ttm_bo.c| 13 +
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 +
9 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index e88e00c6cbf2..e365434f92b3 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -441,7 +441,8 @@ extern struct ttm_bo_global {
*
* @driver: Pointer to a struct ttm_bo_driver struct setup by the driver.
* @man: An array of mem_type_managers.
- * @vma_manager: Address space manager
+ * @vma_manager: Address space manager (pointer)
+ * @_vma_manager: Address space manager (enbedded)
* lru_lock: Spinlock that protects the buffer+device lru lists and
* ddestroy lists.
* @dev_mapping: A pointer to the struct address_space representing the
@@ -464,7 +465,8 @@ struct ttm_bo_device {
/*
* Protected by internal locks.
*/
- struct drm_vma_offset_manager vma_manager;
+ struct drm_vma_offset_manager *vma_manager;
+ struct drm_vma_offset_manager _vma_manager;
/*
* Protected by the global:lru lock.
@@ -585,6 +587,7 @@ int ttm_bo_device_release(struct ttm_bo_device *bdev);
* @glob: A pointer to an initialized struct ttm_bo_global.
* @driver: A pointer to a struct ttm_bo_driver set up by the caller.
* @mapping: The address space to use for this bo.
+ * @vma_manager: A pointer to a vma manager or NULL.
* @file_page_offset: Offset into the device address space that is available
* for buffer data. This ensures compatibility with other users of the
* address space.
@@ -596,6 +599,7 @@ int ttm_bo_device_release(struct ttm_bo_device *bdev);
int ttm_bo_device_init(struct ttm_bo_device *bdev,
struct ttm_bo_driver *driver,
struct address_space *mapping,
+ struct drm_vma_offset_manager *vma_manager,
bool need_dma32);
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index fb09314bcfd4..34ee5d725faf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1728,6 +1728,7 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
r = ttm_bo_device_init(&adev->mman.bdev,
&amdgpu_bo_driver,
adev->ddev->anon_inode->i_mapping,
+ NULL,
adev->need_dma32);
if (r) {
DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c
b/drivers/gpu/drm/drm_vram_mm_helper.c
index c911781d6728..56fd1519eb35 100644
--- a/drivers/gpu/drm/drm_vram_mm_helper.c
+++ b/drivers/gpu/drm/drm_vram_mm_helper.c
@@ -172,6 +172,7 @@ int drm_vram_mm_init(struct drm_vram_mm *vmm, struct
drm_device *dev,
ret = ttm_bo_device_init(&vmm->bdev, &bo_driver,
dev->anon_inode->i_mapping,
+NULL,
true);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index f0daf958e03a..e67eb10843d1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -236,6 +236,7 @@ nouveau_ttm_init(struct nouveau_drm *drm)
ret = ttm_bo_device_init(&drm->ttm.bdev,
&nouveau_bo_driver,
dev->anon_inode->i_mapping,
+NULL,
drm->client.mmu.dmabits <= 32 ? true : false);
if (ret) {
NV_ERROR(drm, "error initialising bo driver, %d\n", ret);
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 9b24514c75aa..69da0eea6e4c 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -325,6 +325,7 @@ int qxl_ttm_init(struct qxl_device *qdev)
r = ttm_bo_device_init(&qdev->mman.bdev,
[Bug 105718] amdgpu reported fan speed looks too high (dual fan Sapphire Pulse Vega 56 and Sapphire RX 5700 XT)
https://bugs.freedesktop.org/show_bug.cgi?id=105718 --- Comment #7 from Andrew Sheldon --- (In reply to Shmerl from comment #5) > Actually, I've noticed another similar issue. I just got Sapphire Pulse RX > 5700 XT. It's also dual fan. > > According to this: > https://www.gamersnexus.net/hwreviews/3498-sapphire-rx-5700-xt-pulse-review > > The top level of fan rotation (at high load and more performance BIOS > setting) is around 1570 rpm. While sensors report that max is 3200 rpm for > me! > > And something like 50% load (of the fan) is shown as around 1600 RPM! > > So I'd say something is definitely off. It's almost like values from both > fans are added up, instead of showing actual one. You could use UPP (https://github.com/sibradzic/upp) so see what your the powerplay tables report is the maximum for fanspeed. On the MSI Evoke 5700 XT, mine reports a FanMaximumRpm of 3200. I believe in the case of the Evoke, that some benchmarks have shown it can get near 3200 RPM at max speed. I don't know if the driver impacts the values here, or if this is strictly based on the BIOS. But it might be helpful to see if that max matches what the sensors are reporting. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Xorg indefinitely hangs in kernelspace
Hi,
--verbose please. Do you see the same hang? Does the patch fix it?
> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
> @@ -97,8 +97,9 @@ int ttm_eu_reserve_buffers(struct ww_acq
> struct list_head *dups, bool del_lru)
[ ... ]
> + if (locked)
> + ttm_eu_backoff_reservation_reverse(list, entry);
Hmm, I think the patch is wrong. As far I know it is the qxl drivers's
job to call ttm_eu_backoff_reservation(). Doing that automatically in
ttm will most likely break other ttm users.
So I guess the call is missing in the qxl driver somewhere, most likely
in some error handling code path given that this bug is a relatively
rare event.
There is only a single ttm_eu_reserve_buffers() call in qxl.
So how about this?
--- cut here
diff --git a/drivers/gpu/drm/qxl/qxl_release.c
b/drivers/gpu/drm/qxl/qxl_release.c
index 312216caeea2..2f9950fa0b8d 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -262,18 +262,20 @@ int qxl_release_reserve_list(struct qxl_release *release,
bool no_intr)
ret = ttm_eu_reserve_buffers(&release->ticket, &release->bos,
!no_intr, NULL, true);
if (ret)
- return ret;
+ goto err_backoff;
list_for_each_entry(entry, &release->bos, tv.head) {
struct qxl_bo *bo = to_qxl_bo(entry->tv.bo);
ret = qxl_release_validate_bo(bo);
- if (ret) {
- ttm_eu_backoff_reservation(&release->ticket,
&release->bos);
- return ret;
- }
+ if (ret)
+ goto err_backoff;
}
return 0;
+
+err_backoff:
+ ttm_eu_backoff_reservation(&release->ticket, &release->bos);
+ return ret;
}
void qxl_release_backoff_reserve_list(struct qxl_release *release)
--- cut here
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111591] [radeonsi/Navi] The Bard's Tale IV causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=111591 --- Comment #1 from Timothy Arceri --- An apitrace of the problem would be helpful if you can get it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/lima: fix lima_gem_wait() return value
Oh, I was miss leading by the drm_gem_reservation_object_wait comments. Patch is: Reviewed-by: Qiang Yu I'll apply this patch to drm-misc-next. Current kernel release is 5.3-rc8, is it too late for this fix to go into the mainline 5.3 release? I'd like to know how to apply this fix for current rc kernels, by drm-misc-fixes? Can I push to drm-misc-fixes by dim or I can only push to drm-misc-next and drm-misc maintainer will pick fixes from it to drm-misc-fixes? Thanks, Qiang On Sun, Sep 8, 2019 at 10:48 AM Vasily Khoruzhick wrote: > > drm_gem_reservation_object_wait() returns 0 if it succeeds and -ETIME > if it timeouts, but lima driver assumed that 0 is error. > > Cc: sta...@vger.kernel.org > Signed-off-by: Vasily Khoruzhick > --- > drivers/gpu/drm/lima/lima_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c > index 477c0f73..b609dc030d6c 100644 > --- a/drivers/gpu/drm/lima/lima_gem.c > +++ b/drivers/gpu/drm/lima/lima_gem.c > @@ -342,7 +342,7 @@ int lima_gem_wait(struct drm_file *file, u32 handle, u32 > op, s64 timeout_ns) > timeout = drm_timeout_abs_to_jiffies(timeout_ns); > > ret = drm_gem_reservation_object_wait(file, handle, write, timeout); > - if (ret == 0) > + if (ret == -ETIME) > ret = timeout ? -ETIMEDOUT : -EBUSY; > > return ret; > -- > 2.23.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: bridge/dw_hdmi: add audio sample channel status setting
On Mon, Sep 9, 2019 at 2:38 AM Russell King - ARM Linux admin
wrote:
>
> On Thu, Sep 05, 2019 at 05:43:25PM +0800, Cheng-Yi Chiang wrote:
> > From: Yakir Yang
> >
> > When transmitting IEC60985 linear PCM audio, we configure the
> > Aduio Sample Channel Status information of all the channel
> > status bits in the IEC60958 frame.
> > Refer to 60958-3 page 10 for frequency, original frequency, and
> > wordlength setting.
> >
> > This fix the issue that audio does not come out on some monitors
> > (e.g. LG 22CV241)
> >
> > Note that these registers are only for interfaces:
> > I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
> > (AHBAUDDMA).
> > For S/PDIF interface this information comes from the stream.
> >
> > Currently this function dw_hdmi_set_channel_status is only called
> > from dw-hdmi-i2s-audio in I2S setup.
> >
> > Signed-off-by: Yakir Yang
> > Signed-off-by: Cheng-Yi Chiang
> > ---
> > Original patch by Yakir Yang is at
> >
> > https://lore.kernel.org/patchwork/patch/539653/
> >
> > Change from v1 to v2:
> > 1. Remove the version check because this will only be called by
> > dw-hdmi-i2s-audio, and the registers are available in I2S setup.
> > 2. Set these registers in dw_hdmi_i2s_hw_params.
> > 3. Fix the sample width setting so it can use 16 or 24 bits.
> >
> > .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 70 +++
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20 ++
> > include/drm/bridge/dw_hdmi.h | 2 +
> > 4 files changed, 93 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > index 34d8e837555f..b801a28b0f17 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > @@ -102,6 +102,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev,
> > void *data,
> > }
> >
> > dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
> > + dw_hdmi_set_channel_status(hdmi, hparms->sample_width);
> > dw_hdmi_set_channel_count(hdmi, hparms->channels);
> > dw_hdmi_set_channel_allocation(hdmi, hparms->cea.channel_allocation);
> >
>
> dw_hdmi_i2s_hw_params() is passed the channel status data in
> hparams->iec.status Rather than re-creating it afresh in the driver,
> I'd recommend programming the already supplied channel status data
> into the registers.
>
Hi Russell,
Thank you for pointing this out.
I did not realize that the status data is already set.
I will fix in v3 to make this patch much simpler.
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index bd65d0479683..d1daa369c8ae 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -582,6 +582,76 @@ static unsigned int hdmi_compute_n(unsigned int freq,
> > unsigned long pixel_clk)
> > return n;
> > }
> >
> > +/*
> > + * When transmitting IEC60958 linear PCM audio, these registers allow to
> > + * configure the channel status information of all the channel status
> > + * bits in the IEC60958 frame. For the moment this configuration is only
> > + * used when the I2S audio interface, General Purpose Audio (GPA),
> > + * or AHB audio DMA (AHBAUDDMA) interface is active
> > + * (for S/PDIF interface this information comes from the stream).
> > + */
> > +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
> > + unsigned int sample_width)
> > +{
> > + u8 aud_schnl_samplerate;
> > + u8 aud_schnl_8;
> > + u8 word_length_bits;
> > +
> > + switch (hdmi->sample_rate) {
> > + case 32000:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
> > + break;
> > + case 44100:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
> > + break;
> > + case 48000:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
> > + break;
> > + case 88200:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
> > + break;
> > + case 96000:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
> > + break;
> > + case 176400:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
> > + break;
> > + case 192000:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
> > + break;
> > + case 768000:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
> > + break;
> > + default:
> > + dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)\n",
> > + hdmi->sample_rate);
> > + return;
> > + }
> > +
> > + /* set channel status register */
> > + h
Re: [PATCH v2] drm: bridge/dw_hdmi: add audio sample channel status setting
On Mon, Sep 9, 2019 at 2:18 AM Jernej Škrabec wrote:
>
> Dne četrtek, 05. september 2019 ob 11:43:25 CEST je Cheng-Yi Chiang
> napisal(a):
> > From: Yakir Yang
> >
> > When transmitting IEC60985 linear PCM audio, we configure the
> > Aduio Sample Channel Status information of all the channel
> > status bits in the IEC60958 frame.
> > Refer to 60958-3 page 10 for frequency, original frequency, and
> > wordlength setting.
> >
> > This fix the issue that audio does not come out on some monitors
> > (e.g. LG 22CV241)
> >
> > Note that these registers are only for interfaces:
> > I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
> > (AHBAUDDMA).
> > For S/PDIF interface this information comes from the stream.
> >
> > Currently this function dw_hdmi_set_channel_status is only called
> > from dw-hdmi-i2s-audio in I2S setup.
> >
> > Signed-off-by: Yakir Yang
> > Signed-off-by: Cheng-Yi Chiang
> > ---
> > Original patch by Yakir Yang is at
> >
> > https://lore.kernel.org/patchwork/patch/539653/
> >
> > Change from v1 to v2:
> > 1. Remove the version check because this will only be called by
> > dw-hdmi-i2s-audio, and the registers are available in I2S setup.
> > 2. Set these registers in dw_hdmi_i2s_hw_params.
> > 3. Fix the sample width setting so it can use 16 or 24 bits.
> >
> > .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 70 +++
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20 ++
> > include/drm/bridge/dw_hdmi.h | 2 +
> > 4 files changed, 93 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index
> > 34d8e837555f..b801a28b0f17 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> > @@ -102,6 +102,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev,
> > void *data, }
> >
> > dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
> > + dw_hdmi_set_channel_status(hdmi, hparms->sample_width);
> > dw_hdmi_set_channel_count(hdmi, hparms->channels);
> > dw_hdmi_set_channel_allocation(hdmi, hparms-
> >cea.channel_allocation);
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > bd65d0479683..d1daa369c8ae 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -582,6 +582,76 @@ static unsigned int hdmi_compute_n(unsigned int freq,
> > unsigned long pixel_clk) return n;
> > }
> >
> > +/*
> > + * When transmitting IEC60958 linear PCM audio, these registers allow to
> > + * configure the channel status information of all the channel status
> > + * bits in the IEC60958 frame. For the moment this configuration is only
> > + * used when the I2S audio interface, General Purpose Audio (GPA),
> > + * or AHB audio DMA (AHBAUDDMA) interface is active
> > + * (for S/PDIF interface this information comes from the stream).
> > + */
> > +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
> > + unsigned int sample_width)
> > +{
> > + u8 aud_schnl_samplerate;
> > + u8 aud_schnl_8;
> > + u8 word_length_bits;
> > +
> > + switch (hdmi->sample_rate) {
> > + case 32000:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
> > + break;
> > + case 44100:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
> > + break;
> > + case 48000:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
> > + break;
> > + case 88200:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
> > + break;
> > + case 96000:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
> > + break;
> > + case 176400:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
> > + break;
> > + case 192000:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
> > + break;
> > + case 768000:
> > + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
> > + break;
> > + default:
> > + dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)
> \n",
> > + hdmi->sample_rate);
> > + return;
> > + }
> > +
> > + /* set channel status register */
> > + hdmi_modb(hdmi, aud_schnl_samplerate,
> HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
> > + HDMI_FC_AUDSCHNLS7);
> > +
> > + /*
> > + * Set original frequency to be the same as frequency.
> > + * Use one-complement value as stated in IEC60958-3 page 13.
> > + */
> > + aud_schnl_8 = (~aud_schnl_samplerate) <<
> > + HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
[PATCH v5 2/2] drm/bridge: Add NWL MIPI DSI host controller support
This adds initial support for the NWL MIPI DSI Host controller found on
i.MX8 SoCs.
It adds support for the i.MX8MQ but the same IP can be found on
e.g. the i.MX8QXP.
It has been tested on the Librem 5 devkit using mxsfb.
Signed-off-by: Guido Günther
Co-developed-by: Robert Chiras
Signed-off-by: Robert Chiras
Tested-by: Robert Chiras
---
drivers/gpu/drm/bridge/Kconfig | 2 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/nwl-dsi/Kconfig | 16 +
drivers/gpu/drm/bridge/nwl-dsi/Makefile | 4 +
drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c | 499
drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h | 65 +++
drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c | 696 +++
drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h | 112
8 files changed, 1395 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Kconfig
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/Makefile
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.h
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c
create mode 100644 drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.h
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 1cc9f502c1f2..7980b5c2156f 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -154,6 +154,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
source "drivers/gpu/drm/bridge/adv7511/Kconfig"
+source "drivers/gpu/drm/bridge/nwl-dsi/Kconfig"
+
source "drivers/gpu/drm/bridge/synopsys/Kconfig"
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf5a6f8..d9f6c0f77592 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -16,4 +16,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
new file mode 100644
index ..7fa678e3b5e2
--- /dev/null
+++ b/drivers/gpu/drm/bridge/nwl-dsi/Kconfig
@@ -0,0 +1,16 @@
+config DRM_NWL_MIPI_DSI
+ tristate "Northwest Logic MIPI DSI Host controller"
+ depends on DRM
+ depends on COMMON_CLK
+ depends on OF && HAS_IOMEM
+ select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
+ select DRM_PANEL_BRIDGE
+ select GENERIC_PHY_MIPI_DPHY
+ select MFD_SYSCON
+ select MULTIPLEXER
+ select REGMAP_MMIO
+ help
+ This enables the Northwest Logic MIPI DSI Host controller as
+ for example found on NXP's i.MX8 Processors.
+
diff --git a/drivers/gpu/drm/bridge/nwl-dsi/Makefile
b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
new file mode 100644
index ..804baf2f1916
--- /dev/null
+++ b/drivers/gpu/drm/bridge/nwl-dsi/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+nwl-mipi-dsi-y := nwl-drv.o nwl-dsi.o
+obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-mipi-dsi.o
+header-test-y += nwl-drv.h nwl-dsi.h
diff --git a/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
new file mode 100644
index ..9ff43d2de127
--- /dev/null
+++ b/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c
@@ -0,0 +1,499 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * i.MX8 NWL MIPI DSI host driver
+ *
+ * Copyright (C) 2017 NXP
+ * Copyright (C) 2019 Purism SPC
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "nwl-drv.h"
+#include "nwl-dsi.h"
+
+#define DRV_NAME "nwl-dsi"
+
+/* Possible platform specific clocks */
+#define NWL_DSI_CLK_CORE "core"
+
+static const struct regmap_config nwl_dsi_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = NWL_DSI_IRQ_MASK2,
+ .name = DRV_NAME,
+};
+
+struct nwl_dsi_platform_data {
+ int (*poweron)(struct nwl_dsi *dsi);
+ int (*poweroff)(struct nwl_dsi *dsi);
+ int (*select_input)(struct nwl_dsi *dsi);
+ int (*deselect_input)(struct nwl_dsi *dsi);
+ struct nwl_dsi_plat_clk_config clk_config[NWL_DSI_MAX_PLATFORM_CLOCKS];
+};
+
+static inline struct nwl_dsi *bridge_to_dsi(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct nwl_dsi, bridge);
+}
+
+static int nwl_dsi_set_platform_clocks(struct nwl_dsi *dsi, bool enable)
+{
+ struct device *dev = dsi->dev;
+ const char *id;
+ struct clk *clk;
+ size_t i;
+ unsigned long rate;
+ int ret, result = 0;
+
+ DRM_DEV_DEBUG_DRIVER(dev, "%s platform clocks\n",
+enable ? "enabling" : "disabling");
+ for (i = 0; i < ARRAY_SIZE(dsi->pdata->clk_config);
[PATCH v5 0/2] drm: bridge: Add NWL MIPI DSI host controller support
This adds initial support for the NWL MIPI DSI host controller found on i.MX8
SoCs.
It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
I only have imx8mq boards to test I omitted the platform data for other SoCs.
The code is based on NXPs BSP so I added Robert Chiras as
Co-authored-by.
The most notable changes over the BSP driver are
- Calculate HS mode timing from phy_configure_opts_mipi_dphy
- Perform all clock setup via DT
- Merge nwl-imx and nwl drivers
- Add B0 silion revision quirk
- become a bridge driver to hook into mxsfb (from what I read[0] DCSS, which
also can drive the nwl on the imx8mq will likely not become part of
imx-display-subsystem so it makes sense to make it drive a bridge for dsi as
well).
- Use panel_bridge to attach the panel
- Use multiplex framework instead of accessing syscon directly
This has been tested on a Librem 5 devkit using mxsfb with Robert's patches[1]
and the rocktech-jh057n00900 panel driver on next-20190807. The DCSS can later
on also act as input source too.
Changes from v4:
- Collect Reviewed-by: from Rob Herring, thanks!
https://lists.freedesktop.org/archives/dri-devel/2019-September/233979.html
- Spotted by kbuild test robot
https://lists.freedesktop.org/archives/dri-devel/2019-September/233860.html
https://lists.freedesktop.org/archives/dri-devel/2019-September/233863.html
- fix format string for size_t
- Use DIV64_U64_ROUND_UP to fix build on 32 bit architectures
We can't use simple shift sind d and n are similar in size and
we need full precision
- Fix debug cfg_t_post debug print out
- Avoid PSEC_PER_SEC
- Move timeout / overflow handling out of nwl_dsi_finish_transmission,
it would never end up being reported since the call to the function
was guarded by flags.
- Drop 'support for' from KConfig title to make it match the other
drivers in that submenu
Changes from v3:
- Per review comments by Robert Chiras
https://lists.freedesktop.org/archives/dri-devel/2019-August/232580.html
- Add Robert's {Signed-off,Tested}-by:
- Respect number of lanes when calculting bandwidth limits
- Drop duplicate NWL_DSI_ENABLE_MULT_PKTS setup
- Per testing by Rober Chiras
https://lists.freedesktop.org/archives/dri-devel/2019-August/233688.html
- Drop duplicate (and too early) drm_bridge_add() in nwl_dir_probe() that
made mxsfb fail to connect to the bridge since the panel_bridge was not up
yet. drm_bridge_add() happens in nwl_dsi_host_attach() where after the
panel_bridge was set up.
- Per review comments by Rob Herring on bindings
https://lists.freedesktop.org/archives/dri-devel/2019-August/233196.html
- drop description from power-domains and resets
- allow BSD 2 clause license as well
- make ports more specific
- add #address-cells, #size-cells as required
- use additionalProperties
- panel is of type object
Changes from v2:
- Per review comments by Rob Herring
https://lists.freedesktop.org/archives/dri-devel/2019-August/230448.html
- bindings:
- Simplify by restricting to fsl,imx8mq-nwl-dsi
- document reset lines
- add port@{0,1}
- use a real compatible string for the panel
- resets are required
- Per review comments by Arnd Bergmann
https://lists.freedesktop.org/archives/dri-devel/2019-August/230868.html
- Don't access iomuxc_gpr regs directly. This allows us to drop the
first patch in the series with the iomuxc_gpr field defines.
- Per review comments by Laurent Pinchart
Fix wording in bindings
- Add mux-controls to bindings
- Don't print error message on dphy probe deferral
Changes from v1:
- Per review comments by Sam Ravnborg
https://lists.freedesktop.org/archives/dri-devel/2019-July/228130.html
- Change binding docs to YAML
- build: Don't always visit imx-nwl/
- build: Add header-test-y
- Sort headers according to DRM convention
- Use drm_display_mode instead of videmode
- Per review comments by Fabio Estevam
https://lists.freedesktop.org/archives/dri-devel/2019-July/228299.html
- Don't restrict build to ARCH_MXC
- Drop unused includes
- Drop unreachable code in imx_nwl_dsi_bridge_mode_fixup()
- Drop remaining calls of dev_err() and use DRM_DEV_ERR()
consistently.
- Use devm_platform_ioremap_resource()
- Drop devm_free_irq() in probe() error path
- Use single line comments where sufficient
- Use instead of defining USEC_PER_SEC
- Make input source select imx8 specific
- Drop inclusion (after removal of get_unaligned_le32)
- Drop all EXPORT_SYMBOL_GPL() for functions used in the same module
but different source files.
- Drop nwl_dsi_enable_{rx,tx}_clock() by invoking clk_prepare_enable()
directly
- Remove pointless comment
- Laurent Pinchart
https://lists.freedesktop.org/archives/dri-devel/2019-July/228313.html
https://lists.freedesktop.org/archives/dri-devel/2019-July/228308.html
- Drop
[PATCH v5 1/2] dt-bindings: display/bridge: Add binding for NWL mipi dsi host controller
The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
Signed-off-by: Guido Günther
Tested-by: Robert Chiras
Reviewed-by: Rob Herring
---
.../bindings/display/bridge/nwl-dsi.yaml | 176 ++
1 file changed, 176 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
new file mode 100644
index ..31119c7885ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
@@ -0,0 +1,176 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/nwl-dsi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Northwest Logic MIPI-DSI controller on i.MX SoCs
+
+maintainers:
+ - Guido Gúnther
+ - Robert Chiras
+
+description: |
+ NWL MIPI-DSI host controller found on i.MX8 platforms. This is a dsi bridge
for
+ the SOCs NWL MIPI-DSI host controller.
+
+properties:
+ compatible:
+const: fsl,imx8mq-nwl-dsi
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+ clocks:
+items:
+ - description: DSI core clock
+ - description: RX_ESC clock (used in escape mode)
+ - description: TX_ESC clock (used in escape mode)
+ - description: PHY_REF clock
+
+ clock-names:
+items:
+ - const: core
+ - const: rx_esc
+ - const: tx_esc
+ - const: phy_ref
+
+ mux-controls:
+description:
+ mux controller node to use for operating the input mux
+
+ phys:
+maxItems: 1
+description:
+ A phandle to the phy module representing the DPHY
+
+ phy-names:
+items:
+ - const: dphy
+
+ power-domains:
+maxItems: 1
+
+ resets:
+items:
+ - description: dsi byte reset line
+ - description: dsi dpi reset line
+ - description: dsi esc reset line
+ - description: dsi pclk reset line
+
+ reset-names:
+items:
+ - const: byte
+ - const: dpi
+ - const: esc
+ - const: pclk
+
+ ports:
+type: object
+description:
+ A node containing DSI input & output port nodes with endpoint
+ definitions as documented in
+ Documentation/devicetree/bindings/graph.txt.
+properties:
+ port@0:
+type: object
+description:
+ Input port node to receive pixel data from the
+ display controller
+
+ port@1:
+type: object
+description:
+ DSI output port node to the panel or the next bridge
+ in the chain
+
+ '#address-cells':
+const: 1
+
+ '#size-cells':
+const: 0
+
+required:
+ - '#address-cells'
+ - '#size-cells'
+ - port@0
+ - port@1
+
+additionalProperties: false
+
+patternProperties:
+ "^panel@[0-9]+$":
+type: object
+
+required:
+ - '#address-cells'
+ - '#size-cells'
+ - clock-names
+ - clocks
+ - compatible
+ - interrupts
+ - mux-controls
+ - phy-names
+ - phys
+ - ports
+ - reg
+ - reset-names
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+
+ mipi_dsi: mipi_dsi@30a0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx8mq-nwl-dsi";
+ reg = <0x30A0 0x300>;
+ clocks = <&clk 163>, <&clk 244>, <&clk 245>, <&clk 164>;
+ clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
+ interrupts = <0 34 4>;
+ mux-controls = <&mux 0>;
+ power-domains = <&pgc_mipi>;
+ resets = <&src 0>, <&src 1>, <&src 2>, <&src 3>;
+ reset-names = "byte", "dpi", "esc", "pclk";
+ phys = <&dphy>;
+ phy-names = "dphy";
+
+ panel@0 {
+ compatible = "rocktech,jh057n00900";
+ reg = <0>;
+ port@0 {
+ panel_in: endpoint {
+ remote-endpoint = <&mipi_dsi_out>;
+ };
+ };
+ };
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+ reg = <0>;
+ mipi_dsi_in: endpoint {
+remote-endpoint = <&lcdif_mipi_dsi>;
+ };
+};
+port@1 {
+ reg = <1>;
+ mipi_dsi_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+};
+ };
+ };
--
2.23.0.rc1
[Bug 111591] [radeonsi/Navi] The Bard's Tale IV causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=111591 Bug ID: 111591 Summary: [radeonsi/Navi] The Bard's Tale IV causes a GPU hang Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: shtetl...@gmail.com QA Contact: dri-devel@lists.freedesktop.org When running the Bard's Tale IV, in the beginning of the game, if I turn around, it consistently is causing a GPU hang. And I see this in dmesg: [ 4246.501534] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out or interrupted! [ 4251.365674] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=178390, emitted seq=178392 [ 4251.365740] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process BardsTale4-Linu pid 7251 thread BardsTale4:cs0 pid 7292 [ 4251.365742] [drm] GPU recovery disabled. GPU: Sapphire Pulse RX 5700 XT Kernel: 5.3.0-rc8+ OpenGL renderer string: AMD NAVI10 (DRM 3.33.0, 5.3.0-rc8+, LLVM 10.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.3.0-devel (git-87fa8d9ebc) Game version: GOG, release 1.0.0 (version 4.20.1 / 32050). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111232] 3200 Memory Crash My System
https://bugs.freedesktop.org/show_bug.cgi?id=111232 --- Comment #6 from bibitocarlos --- Tried amd.iommu off but doesnt work, so it's something else. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] FBTFT: fb_agm1264k: usleep_range is preferred over udelay
This patch fixes the issue: FILE: drivers/staging/fbtft/fb_agm1264k-fl.c:88: CHECK: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst + udelay(20); Signed-off-by: Sreeram Veluthakkal --- drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c index ec97ad27..2dece71fd3b5 100644 --- a/drivers/staging/fbtft/fb_agm1264k-fl.c +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par) dev_dbg(par->info->device, "%s()\n", __func__); gpiod_set_value(par->gpio.reset, 0); - udelay(20); + usleep_range(20, 40); gpiod_set_value(par->gpio.reset, 1); mdelay(120); } -- 2.17.1
[Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 --- Comment #29 from Timothy Arceri --- (In reply to rol...@rptd.ch from comment #22) > Hi Marek, > > This is going to be complicated. The application is not yet free to use by > others (working on getting it to release shape). I would have to figure out > first how to break this down into a reproducible test case since I don't > know myself what triggers the bug. > > If you can think of some corner values to narrow down in what direction to > search I can fully mess with the source code over here. The faulty commit > talks about UBO maximum size so this might be a start. The OpenGL > Capabilities from the GPU is this: > > - UBO Maximum Block Size = 65536 > - UBO Buffer Offset Alignment = 4 > > So the maximum size used by the application is 65536 bytes. > > UBOs are used as shared buffers so blocks of data are placed next to each > other respecting alignment and updated. > > UBOs are created like this: > > glBindBuffer(GL_UNIFORM_BUFFER, pUBO) // <= done once > glBufferData(GL_UNIFORM_BUFFER, bufferSize, NULL, GL_DYNAMIC_DRAW) // <= > done once > glMapBufferRange(GL_UNIFORM_BUFFER, stride * elementCount, elementStride, > GL_WRITE_ONLY | GL_MAP_INVALIDATE_RANGE_BIT) // <= done for each data block > written > > Data then written and unmapped > > In particular this means a larger UBO is created once then individual blocks > are written to it using ranged mapping. Just a wield guess but could the > problem be related to this kind of usage pattern? UBOs are written to the shader cache, and shade cache items are kept in memory in a queue when all threads are busy compiling. If you have large UBOs this could indeed be your problem. The following merge request might be helpful. Are you able to give this a test? https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1852 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109048] [amdgpu] [apitrace] Penumbra Overture crash in radeonsi_dri.so on RX580
https://bugs.freedesktop.org/show_bug.cgi?id=109048 --- Comment #16 from Timothy Arceri --- Is this still a problem for you? Or have updates to GCC fixed it? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/2] drm/panel: Extend panels to report their types
Hi Sam, On Sun, Sep 08, 2019 at 07:17:48PM +0200, Sam Ravnborg wrote: > Hi Laurent. > > > > Laurent Pinchart (2): > > > drm/panel: Add and fill drm_panel type field > > > drm/bridge: panel: Infer connector type from panel by default > > > > Applied all three patches (despite this shortlog only shows two > > patches). > > I guess you noticed that I have been away a little. > This will continue for at least another week. > day-time job + some travelling ahead. No worries at all. Thanks for your work and for picking those patches, and have a safe (and if possible enjoyable) travel. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: gnome-shell stuck because of amdgpu driver [5.3 RC5]
On Thu, 5 Sep 2019 at 12:58, Daniel Vetter wrote: > > I think those fences are only emitted for CS, not display related. > Adding Christian König. More fresh kernel log with 5.3RC7 - the issue still happens. https://pastebin.com/tyxkWJYV -- Best Regards, Mike Gavrilov. On Thu, 5 Sep 2019 at 12:58, Daniel Vetter wrote: > > On Thu, Sep 5, 2019 at 12:27 AM Mikhail Gavrilov > wrote: > > > > On Wed, 4 Sep 2019 at 13:37, Daniel Vetter wrote: > > > > > > Extend your backtrac warning slightly like > > > > > > WARN(r, "we're stuck on fence %pS\n", fence->ops); > > > > > > Also adding Harry and Alex, I'm not really working on amdgpu ... > > > > [ 3511.998320] [ cut here ] > > [ 3511.998714] we're stuck on fence > > amdgpu_fence_ops+0x0/0xc220 [amdgpu]$ > > I think those fences are only emitted for CS, not display related. > Adding Christian König. > -Daniel > > > [ 3511.998991] WARNING: CPU: 10 PID: 1811 at > > drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:332 > > amdgpu_fence_wait_empty+0x1c6/0x240 [amdgpu] > > [ 3511.999009] Modules linked in: rfcomm fuse xt_CHECKSUM > > xt_MASQUERADE nf_nat_tftp nf_conntrack_tftp tun bridge stp llc > > nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_REJECT > > nf_reject_ipv6 ip6t_rpfilter ipt_REJECT nf_reject_ipv4 xt_conntrack > > ebtable_nat ip6table_nat ip6table_mangle ip6table_raw > > ip6table_security iptable_nat nf_nat iptable_mangle iptable_raw > > iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c > > ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables > > iptable_filter cmac bnep sunrpc vfat fat edac_mce_amd kvm_amd > > snd_hda_codec_realtek rtwpci snd_hda_codec_generic kvm ledtrig_audio > > snd_hda_codec_hdmi uvcvideo rtw88 videobuf2_vmalloc snd_hda_intel > > videobuf2_memops videobuf2_v4l2 irqbypass snd_usb_audio snd_hda_codec > > videobuf2_common crct10dif_pclmul snd_usbmidi_lib crc32_pclmul > > mac80211 snd_rawmidi videodev snd_hda_core ghash_clmulni_intel btusb > > snd_hwdep btrtl snd_seq btbcm btintel snd_seq_device eeepc_wmi > > bluetooth xpad joydev mc snd_pcm > > [ 3511.999076] asus_wmi ff_memless cfg80211 sparse_keymap video > > wmi_bmof ecdh_generic snd_timer ecc sp5100_tco k10temp snd i2c_piix4 > > ccp rfkill soundcore libarc4 gpio_amdpt gpio_generic acpi_cpufreq > > binfmt_misc ip_tables hid_logitech_hidpp hid_logitech_dj amdgpu > > amd_iommu_v2 gpu_sched ttm drm_kms_helper drm crc32c_intel igb dca > > nvme i2c_algo_bit nvme_core wmi pinctrl_amd > > [ 3511.999126] CPU: 10 PID: 1811 Comm: Xorg Not tainted > > 5.3.0-0.rc6.git2.1c.fc32.x86_64 #1 > > [ 3511.999131] Hardware name: System manufacturer System Product > > Name/ROG STRIX X470-I GAMING, BIOS 2703 08/20/2019 > > [ 3511.999253] RIP: 0010:amdgpu_fence_wait_empty+0x1c6/0x240 [amdgpu] > > [ 3511.999278] Code: fe ff ff 31 c0 c3 48 89 ef e8 36 29 04 cb 84 c0 > > 74 08 48 89 ef e8 8a a9 21 cb 48 8b 75 08 48 c7 c7 2c 16 86 c0 e8 82 > > b8 b9 ca <0f> 0b b8 ea ff ff ff 5d c3 e8 ec 57 c3 ca 84 c0 0f 85 6f ff > > ff ff > > [ 3511.999282] RSP: 0018:b9c04170f798 EFLAGS: 00210282 > > [ 3511.999288] RAX: RBX: 8d2ce5205a80 RCX: > > 0006 > > [ 3511.999292] RDX: 0007 RSI: 8d2c5bea4070 RDI: > > 8d2cfb5d9e00 > > [ 3511.999296] RBP: 8d28becae480 R08: 0331b36fd503 R09: > > > > [ 3511.999299] R10: R11: R12: > > 8d2ce520 > > [ 3511.999303] R13: R14: R15: > > 8d2ce154 > > [ 3511.999308] FS: 7f59a5bc6f00() GS:8d2cfb40() > > knlGS: > > [ 3511.999311] CS: 0010 DS: ES: CR0: 80050033 > > [ 3511.999315] CR2: 1108bc475960 CR3: 00075bf32000 CR4: > > 003406e0 > > [ 3511.999319] Call Trace: > > [ 3511.999394] amdgpu_pm_compute_clocks+0x70/0x5f0 [amdgpu] > > [ 3511.999503] dm_pp_apply_display_requirements+0x1a8/0x1c0 [amdgpu] > > [ 3511.999609] dce12_update_clocks+0xd8/0x110 [amdgpu] > > [ 3511.999712] dc_commit_state+0x414/0x590 [amdgpu] > > [ 3511.999725] ? find_held_lock+0x32/0x90 > > [ 3511.999832] amdgpu_dm_atomic_commit_tail+0xd18/0x1cf0 [amdgpu] > > [ 3511.999844] ? reacquire_held_locks+0xed/0x210 > > [ 3511.999859] ? ttm_eu_backoff_reservation+0xa5/0x160 [ttm] > > [ 3511.999866] ? find_held_lock+0x32/0x90 > > [ 3511.999872] ? find_held_lock+0x32/0x90 > > [ 3511.999881] ? __lock_acquire+0x247/0x1910 > > [ 3511.999893] ? find_held_lock+0x32/0x90 > > [ 3511.01] ? mark_held_locks+0x50/0x80 > > [ 3511.07] ? _raw_spin_unlock_irq+0x29/0x40 > > [ 3511.13] ? lockdep_hardirqs_on+0xf0/0x180 > > [ 3511.19] ? _raw_spin_unlock_irq+0x29/0x40 > > [ 3511.24] ? wait_for_completion_timeout+0x75/0x190 > > [ 3511.52] ? commit_tail+0x3c/0x70 [drm_kms_helper] > > [ 3511.66] commit_tail+0x3c/0x70 [drm_kms_helper] > > [ 3511.79] drm_atomic_helper_commit+0xe3/0x150 [drm_kms_
Re: [PATCH v2] drm: bridge/dw_hdmi: add audio sample channel status setting
On Thu, Sep 05, 2019 at 05:43:25PM +0800, Cheng-Yi Chiang wrote:
> From: Yakir Yang
>
> When transmitting IEC60985 linear PCM audio, we configure the
> Aduio Sample Channel Status information of all the channel
> status bits in the IEC60958 frame.
> Refer to 60958-3 page 10 for frequency, original frequency, and
> wordlength setting.
>
> This fix the issue that audio does not come out on some monitors
> (e.g. LG 22CV241)
>
> Note that these registers are only for interfaces:
> I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
> (AHBAUDDMA).
> For S/PDIF interface this information comes from the stream.
>
> Currently this function dw_hdmi_set_channel_status is only called
> from dw-hdmi-i2s-audio in I2S setup.
>
> Signed-off-by: Yakir Yang
> Signed-off-by: Cheng-Yi Chiang
> ---
> Original patch by Yakir Yang is at
>
> https://lore.kernel.org/patchwork/patch/539653/
>
> Change from v1 to v2:
> 1. Remove the version check because this will only be called by
> dw-hdmi-i2s-audio, and the registers are available in I2S setup.
> 2. Set these registers in dw_hdmi_i2s_hw_params.
> 3. Fix the sample width setting so it can use 16 or 24 bits.
>
> .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 70 +++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20 ++
> include/drm/bridge/dw_hdmi.h | 2 +
> 4 files changed, 93 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> index 34d8e837555f..b801a28b0f17 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> @@ -102,6 +102,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev, void
> *data,
> }
>
> dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
> + dw_hdmi_set_channel_status(hdmi, hparms->sample_width);
> dw_hdmi_set_channel_count(hdmi, hparms->channels);
> dw_hdmi_set_channel_allocation(hdmi, hparms->cea.channel_allocation);
>
dw_hdmi_i2s_hw_params() is passed the channel status data in
hparams->iec.status Rather than re-creating it afresh in the driver,
I'd recommend programming the already supplied channel status data
into the registers.
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index bd65d0479683..d1daa369c8ae 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -582,6 +582,76 @@ static unsigned int hdmi_compute_n(unsigned int freq,
> unsigned long pixel_clk)
> return n;
> }
>
> +/*
> + * When transmitting IEC60958 linear PCM audio, these registers allow to
> + * configure the channel status information of all the channel status
> + * bits in the IEC60958 frame. For the moment this configuration is only
> + * used when the I2S audio interface, General Purpose Audio (GPA),
> + * or AHB audio DMA (AHBAUDDMA) interface is active
> + * (for S/PDIF interface this information comes from the stream).
> + */
> +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
> + unsigned int sample_width)
> +{
> + u8 aud_schnl_samplerate;
> + u8 aud_schnl_8;
> + u8 word_length_bits;
> +
> + switch (hdmi->sample_rate) {
> + case 32000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
> + break;
> + case 44100:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
> + break;
> + case 48000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
> + break;
> + case 88200:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
> + break;
> + case 96000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
> + break;
> + case 176400:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
> + break;
> + case 192000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
> + break;
> + case 768000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
> + break;
> + default:
> + dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)\n",
> + hdmi->sample_rate);
> + return;
> + }
> +
> + /* set channel status register */
> + hdmi_modb(hdmi, aud_schnl_samplerate, HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
> + HDMI_FC_AUDSCHNLS7);
> +
> + /*
> + * Set original frequency to be the same as frequency.
> + * Use one-complement value as stated in IEC60958-3 page 13.
> + */
> + aud_schnl_8 = (~aud_schnl_samplerate) <<
> + HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
> +
> + /*
> + * Refer to IEC60958-3 page 12. We ca
Re: [PATCH v3 0/2] drm/panel: Extend panels to report their types
Hi Laurent. > > Laurent Pinchart (2): > > drm/panel: Add and fill drm_panel type field > > drm/bridge: panel: Infer connector type from panel by default > > Applied all three patches (despite this shortlog only shows two > patches). I guess you noticed that I have been away a little. This will continue for at least another week. day-time job + some travelling ahead. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/2] drm/panel: Extend panels to report their types
Hi Laurent. On Wed, Sep 04, 2019 at 04:28:02PM +0300, Laurent Pinchart wrote: > Hello, > > This series, whose previous version was named "[PATCH v2 0/4] drm/panel: > Extend panels to report their types" and is available at > https://www.spinics.net/lists/dri-devel/msg224579.html, allows panels to > report their type, in order to create drm_connector instances with > appropriate types in the upper layers. > > In patch 1/2 the drm_panel structure receives a new connector_type field > to report its type, set through drm_panel_init(), and all connector > drivers are updated accordingly. The panel-simple driver however only > reports the LVDS connector type for known-to-be-LVDS panels, while all > other leave the field initialised to 0, corresponding to > DRM_MODE_CONNECTOR_Unknown. Panels supported by that driver will need to > be reviewed one by one and their type updated. This was done to avoid > reporting an incorrect type, allowing upper layers to catch > DRM_MODE_CONNECTOR_Unknown and WARN() to trigger an update of the > corresponding panel. > > Patch 2/2 then modifies drm_panel_bridge_add() and its devm_ counterpart > to replace the connector type argument with the type reported by the > panel. This can't unfortunately be forced upon all drivers as several of > them hardcode a DRM_MODE_CONNECTOR_Unknown type, and would then change > the connector type reported to userspace, leading to possible breakages. > A new function, drm_panel_bridge_add_typed(), is added with the existing > behaviour of drm_panel_bridge_add() to create a panel bridge with a > forced connector type, and drivers are switched to using that function. > They should then be switched back one by one to drm_panel_bridge_add() > after careful review (and clever handling of the connector type change > issue). The drm_panel_bridge_add_typed() function is marked as > deprecated and should not be used in new code. > > During review of v2, the question of whether to introduce a new > DRM_MODE_CONNECTOR_PANEL was raised. This is still being discussed, but > such a change would still need to expose the existing panel types for > backward compatibility, and this series wouldn't hinder this in any way. > I thus believe that we should merge it sooner than later without waiting > for the DRM_MODE_CONNECTOR_PANEL discussion to settle. Agreed. > > The patches are available at > > git://linuxtv.org/pinchartl/media.git omapdrm/panels > > Laurent Pinchart (2): > drm/panel: Add and fill drm_panel type field > drm/bridge: panel: Infer connector type from panel by default Applied all three patches (despite this shortlog only shows two patches). Pushed to drm-misc-next. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/4] Add a generic driver for LED-based backlight
On 7/22/19 11:23 PM, Jacek Anaszewski wrote: > On 7/22/19 9:06 AM, Lee Jones wrote: >> On Thu, 18 Jul 2019, Jacek Anaszewski wrote: >> >>> On 7/17/19 4:15 PM, Jean-Jacques Hiblot wrote: This series aims to add a led-backlight driver, similar to pwm-backlight, but using a LED class device underneath. A few years ago (2015), Tomi Valkeinen posted a series implementing a backlight driver on top of a LED device: https://patchwork.kernel.org/patch/7293991/ https://patchwork.kernel.org/patch/7294001/ https://patchwork.kernel.org/patch/7293981/ The discussion stopped because Tomi lacked the time to work on it. changes in v4: - fix dev_err() messages and commit logs following the advices of Pavel - cosmetic changes (indents, getting rid of "? 1 : 0" in led_match_led_node()) changes in v3: - dt binding: don't limit the brightness range to 0-255. Use the range of the underlying LEDs. as a side-effect, all LEDs must now have the same range - driver: Adapt to dt binding update. - driver: rework probe() for clarity and remove the remaining goto. changes in v2: - handle more than one LED. - don't make the backlight device a child of the LED controller. - make brightness-levels and default-brightness-level optional - removed the option to use a GPIO enable. - removed the option to use a regulator. It should be handled by the LED core - don't make any change to the LED core (not needed anymore) Jean-Jacques Hiblot (2): leds: Add managed API to get a LED from a device driver dt-bindings: backlight: Add led-backlight binding Tomi Valkeinen (2): leds: Add of_led_get() and led_put() backlight: add led-backlight driver .../bindings/leds/backlight/led-backlight.txt | 28 ++ drivers/leds/led-class.c | 92 ++ drivers/video/backlight/Kconfig | 7 + drivers/video/backlight/Makefile | 1 + drivers/video/backlight/led_bl.c | 268 ++ include/linux/leds.h | 6 + 6 files changed, 402 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/backlight/led-backlight.txt create mode 100644 drivers/video/backlight/led_bl.c >>> >>> For the whole set: >>> >>> Acked-by: Jacek Anaszewski >>> >>> Lee - we need to create immutable branch for this set since there will >>> be some interfering changes in the LED core in this cycle. >>> >>> I can create the branch and send the pull request once we will >>> obtain the ack from Rob for DT bindings, unless you have other >>> preference. >> >> We also require a review to be conducted by Daniel Thompson. >> >> After which, an immutable branch sounds like a good idea. I'd like to >> create this myself if you don't mind. > > Sure, thanks. Unfortunately that hasn't happened and it will miss 5.4 merge window. Daniel, we need your ack for this patch set. -- Best regards, Jacek Anaszewski
Re: [PATCH v2] drm: panel-lvds: Potential Oops in probe error handling
Hi Dan.
On Wed, Sep 04, 2019 at 09:55:07PM +0300, Dan Carpenter wrote:
> The "lvds->backlight" pointer could be NULL in situations were
> of_parse_phandle() returns NULL. Also it's slightly cleaner to use
> backlight_put() which already has a check for NULL built in.
>
> Fixes: 7c9dff5bd643 ("drm: panels: Add LVDS panel driver")
> Signed-off-by: Dan Carpenter
A much better fix would be to introduce use of devm_of_find_backlight().
Then you do not have to worry about put().
Care to respin a v3 that does this?
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/5] Add HDMI jack support on RK3288
On Fri, Aug 30, 2019 at 10:55 AM Cheng-yi Chiang wrote: > > On Wed, Jul 17, 2019 at 6:28 PM Tzung-Bi Shih wrote: > > > > On Wed, Jul 17, 2019 at 4:33 PM Cheng-Yi Chiang > > wrote: > > > > > > This patch series supports HDMI jack reporting on RK3288, which uses > > > DRM dw-hdmi driver and hdmi-codec codec driver. > > > > > > The previous discussion about reporting jack status using hdmi-notifier > > > and drm_audio_component is at > > > > > > https://lore.kernel.org/patchwork/patch/1083027/ > > > > > > The new approach is to use a callback mechanism that is > > > specific to hdmi-codec. > > > > > > Changes from v4 to v5: > > > - synopsys/Kconfig: Remove the incorrect dependency change in v4. > > > - rockchip/Kconfig: Add dependency of hdmi-codec when it is really need > > > for jack support. > > > > > > Cheng-Yi Chiang (5): > > > ASoC: hdmi-codec: Add an op to set callback function for plug event > > > drm: bridge: dw-hdmi: Report connector status using callback > > > drm: dw-hdmi-i2s: Use fixed id for codec device > > > ASoC: rockchip_max98090: Add dai_link for HDMI > > > ASoC: rockchip_max98090: Add HDMI jack support > > > > > LGTM. > > > > Reviewed-by: Tzung-Bi Shih > > Hi Daniel, > Do you have further concern on this patch series related to hdmi-codec > and drm part ? > We would like to merge this patch series if possible. > They will be needed in many future chrome projects for HDMI audio jack > detection. > Thanks a lot! Hi Neil, I am not sure if this patch series is under your radar. Would you mind taking a look ? This patch series has been following great suggestions from various reviewers, so I hope it is fine now. Audio jack reporting for HDMI might not be needed for other OS, but it is a must on ChromeOS. We have many previous projects using different local patch sets to achieve HDMI jack reporting. I hope that we can achieve a proper way and really get the patches merged to mainline. Thanks a lot!
[Bug 111588] Framebuffer corruption when a fb which is not being scanned out gets removed
https://bugs.freedesktop.org/show_bug.cgi?id=111588
--- Comment #1 from Hans de Goede ---
I just realized I left out one bit of info which might be useful, to debug this
I added the following change to the kernel:
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 57564318ceea..4712bfb9ae05 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -464,6 +464,7 @@ int drm_mode_rmfb(struct drm_device *dev, u32 fb_id,
if (drm_framebuffer_read_refcount(fb) > 1) {
struct drm_mode_rmfb_work arg;
+ pr_err("drm_modr_rmfb calling drm_framebuffer_remove\n");
INIT_WORK_ONSTACK(&arg.work, drm_mode_rmfb_work_fn);
INIT_LIST_HEAD(&arg.fbs);
list_add_tail(&fb->filp_head, &arg.fbs);
@@ -471,8 +472,10 @@ int drm_mode_rmfb(struct drm_device *dev, u32 fb_id,
schedule_work(&arg.work);
flush_work(&arg.work);
destroy_work_on_stack(&arg.work);
- } else
+ } else {
+ pr_err("drm_modr_rmfb calling drm_framebuffer_put\n");
drm_framebuffer_put(fb);
+ }
return 0;
@@ -669,11 +672,13 @@ void drm_fb_release(struct drm_file *priv)
*/
list_for_each_entry_safe(fb, tfb, &priv->fbs, filp_head) {
if (drm_framebuffer_read_refcount(fb) > 1) {
+ pr_err("drm_fb_release calling
drm_framebuffer_remove\n");
list_move_tail(&fb->filp_head, &arg.fbs);
} else {
list_del_init(&fb->filp_head);
/* This drops the fpriv->fbs reference. */
+ pr_err("drm_fb_release calling drm_framebuffer_put\n");
drm_framebuffer_put(fb);
}
}
@@ -863,6 +868,8 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
if (plane->state->fb != fb)
continue;
+ pr_err("atomic_remove_fb found plane still using fb\n");
+
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
In the working case, so where we let the kernel do the fb cleanup itself, I
see:
Plymouth removes fb it creates to test for 32bpp support:
kernel: drm_modr_rmfb calling drm_framebuffer_put
gdm starts, does page-flipping, resulting in a number of:
kernel: drm_modr_rmfb calling drm_framebuffer_put
kernel: drm_modr_rmfb calling drm_framebuffer_put
...
lines
And then plymouth exits without any cleanup, so we get:
kernel: drm_fb_release calling drm_framebuffer_put
Followed by more:
kernel: drm_modr_rmfb calling drm_framebuffer_put
kernel: drm_modr_rmfb calling drm_framebuffer_put
...
>From gdm.
In the broken case, where ply_renderer_buffer_free() gets called on
plymouth-quit, I only see:
kernel: drm_modr_rmfb calling drm_framebuffer_put
kernel: drm_modr_rmfb calling drm_framebuffer_put
...
lines, wihch is expected as the fb is rmfb-ed before the fd is closed.
Note that we never hit:
@@ -863,6 +868,8 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
if (plane->state->fb != fb)
continue;
+ pr_err("atomic_remove_fb found plane still using fb\n");
+
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state)) {
ret = PTR_ERR(plane_state);
So AFAICT userspace is doing everything correctly even in the broken case.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111588] Framebuffer corruption when a fb which is not being scanned out gets removed
https://bugs.freedesktop.org/show_bug.cgi?id=111588 Bug ID: 111588 Summary: Framebuffer corruption when a fb which is not being scanned out gets removed Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: jwrdego...@fedoraproject.org This is a weird issue, which I noticed when working on this plymouth fix: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59 On boot to ensure a smooth handover of the framebuffer from plymouth to gdm the following happens: 1) plymouth starts, does an addfb, becomes master, set the fb as the fb the crtc should scanout 2) gdm starts tells plymouth to "deactivate", plymouth drops master (but does not exit) 3) gdm becomes master, installs its own fb to scanout, the fb being scanned out is now owned by gdm 4) gdm tells plymouth it may quit now 5) plymouth exits, without calling rmfb or closing the /dev/dri/card0 fd, relying on the kernel to cleanup 6) all is well The bug fix from the above merge requests make plymouth actually cleanup behind itself, this is necessary to avoid issues with hotunplug (see the plymouth MR for details). My first attempt at this simply made plymouth always do the cleanup, both on hotunplug and exit as that was the most straight forward to do. This changes the sequence to: 1-4) Idem as above 5) Plymouth internally calls src/plugins/renderers/drm/plugin.c: ply_renderer_buffer_free() this does: drmModeRmFB(...); munmap (buffer->map_address, buffer->map_size); destroy_dumb_buffer_request.handle = buffer->handle; drmIoctl (fd, DRM_IOCTL_MODE_DESTROY_DUMB, &destroy_dumb_buffer_request); Followed by calling close() on the fd. 6) Plymouth exits 7) 5 and/or 6 cause the gdm framebuffer being all messed up, it looks like a wrong pitch or tiling setting Note that when 5 is executed plymouth no longer is master and the fb being removed is no longer being scanned out, so this really should not be able to influence the current kms state, yet it does. This is 100% reproducable for me with Fedora 30 + master plymouth + 5.3.0-rc7 on a R7 250E (SAPPHIRE Ultimate Radeon R7 250) using the amdgpu driver. I know that the default is to use the radeon driver with the R7 250E, but I was using the amdgpu driver deliberately to reproduce: https://bugzilla.redhat.com/show_bug.cgi?id=1490490 For now I've modified the plymouth fix to only call ply_renderer_buffer_free() + close() on hot-unplug and to still leave cleanup to the kernel on exit, but it would be nice to get to the bottom of this. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 --- Comment #28 from rol...@rptd.ch --- I had deleted the cache already so I doubt this is the problem. I tried pulling all the shaders and trying to make a small console app just compiling them but so far no luck. I guess I need to check out the culprit commit to better narrow down what I need in the console app to show the problem. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110630] Random Horizontal green lines after screen resize
https://bugs.freedesktop.org/show_bug.cgi?id=110630 --- Comment #8 from Eugene Uzix --- Same issue on Radeon RX 580 Linux 5.2.0-2-amd64 #1 SMP Debian 5.2.9-1 (2019-08-18) Actual Debian Sid X.Org X Server 1.20.4, amdgpu 19.0.1 Openbox + compton Killing compton does not help. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
