Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
Hi Thomas, On Wed, Aug 28, 2019 at 12:51:40PM +0200, Thomas Zimmermann wrote: > Hi > > Am 28.08.19 um 11:37 schrieb Rong Chen: > > Hi Thomas, > > > > On 8/28/19 1:16 AM, Thomas Zimmermann wrote: > >> Hi > >> > >> Am 27.08.19 um 14:33 schrieb Chen, Rong A: > >>> Both patches have little impact on the performance from our side. > >> Thanks for testing. Too bad they doesn't solve the issue. > >> > >> There's another patch attached. Could you please tests this as well? > >> Thanks a lot! > >> > >> The patch comes from Daniel Vetter after discussing the problem on IRC. > >> The idea of the patch is that the old mgag200 code might display much > >> less frames that the generic code, because mgag200 only prints from > >> non-atomic context. If we simulate this with the generic code, we should > >> see roughly the original performance. > >> > >> > > > > It's cool, the patch "usecansleep.patch" can fix the issue. > > Thank you for testing. But don't get too excited, because the patch > simulates a bug that was present in the original mgag200 code. A > significant number of frames are simply skipped. That is apparently the > reason why it's faster. Thanks for the detailed info, so the original code skips time-consuming work inside atomic context on purpose. Is there any space to optmise it? If 2 scheduled update worker are handled at almost same time, can one be skipped? Thanks, Feng > > Best regards > Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108973] The game Evil Twin segfaults when loading saved state.
https://bugs.freedesktop.org/show_bug.cgi?id=108973 Timothy Arceri changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |INVALID --- Comment #2 from Timothy Arceri --- No reply so closing. -- 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 v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware): > On 9/3/19 10:51 PM, Dave Hansen wrote: >> On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote: >>> So the question here should really be, can we determine already at mmap >>> time whether backing memory will be unencrypted and adjust the *real* >>> vma->vm_page_prot under the mmap_sem? >>> >>> Possibly, but that requires populating the buffer with memory at mmap >>> time rather than at first fault time. >> I'm not connecting the dots. >> >> vma->vm_page_prot is used to create a VMA's PTEs regardless of if they >> are created at mmap() or fault time. If we establish a good >> vma->vm_page_prot, can't we just use it forever for demand faults? > > With SEV I think that we could possibly establish the encryption flags > at vma creation time. But thinking of it, it would actually break with > SME where buffer content can be moved between encrypted system memory > and unencrypted graphics card PCI memory behind user-space's back. > That would imply killing all user-space encrypted PTEs and at fault > time set up new ones pointing to unencrypted PCI memory.. Well my problem is where do you see encrypted system memory here? At least for AMD GPUs all memory accessed must be unencrypted and that counts for both system as well as PCI memory. So I don't get why we can't assume always unencrypted and keep it like that. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/3] Send a hotplug when edid changes
On Tue, 2019-09-03 at 17:49 +0200, Daniel Vetter wrote: > On Tue, Sep 03, 2019 at 11:49:23AM +, Lisovskiy, Stanislav wrote: > > On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote: > > > > > > > > In fact I was wrong - when it worked, it was using exactly > > > > > those > > > > > patches :). With clean drm-tip - it seems to work > > > > > ocassionally > > > > > and it > > > > > doesn't update the actual display edid and other stuff, so > > > > > even > > > > > when > > > > > displays are changed we still see the old info/edid from > > > > > userspace. > > > > > > > > > > We always get a hpd irq when suspend/resume however it > > > > > doesn't > > > > > always > > > > > result in uevent being sent. So there is a real need in those > > > > > patches. > > > > > > > > > > > > > Just decided to "ping" this discussion again. The issue is > > > > already > > > > some > > > > years old and still nothing is fixed. I do agree that may be > > > > something > > > > needs to be fixed/changed here in those patches, but something > > > > must > > > > be > > > > agreed at least I guess, as discussions themself do not fix > > > > bugs. > > > > Currently those patches address a particular issue which > > > > occurs, if > > > > display is changed during suspend. > > > > On ocassional basis, userspace might not get a hotplug event at > > > > all, > > > > causing different kind of problems(like wrong mode set on > > > > display > > > > or > > > > diaply not working at all). Also some kms_chamelium hotplug > > > > tests > > > > fail > > > > because of that. > > > > > > I still think we'll long-term regret this if we just duct-tape > > > more > > > stuff > > > on top, instead of giving userspace a more informative uevent. > > > This > > > will > > > send more uevents to userspace, so maybe then userspace tries to > > > filter > > > more and be clever, which never works, and we're back to tears. > > > > But here we actually do need a uevent as currently we don't get any > > at > > all, if edid changes during suspend. If userspace will try to > > filter > > this out - it's just stupid, however we still need to do things > > correctly. > > > > > > > > Anyway, on the approach itself: It's extremely i915 specific, and > > > it > > > requires that all drivers roll out drm_edid_equal checks and not > > > forget to > > > increment the epoch counter. > > > > > > What I had in mind is that when we set the edid for a connector > > > with > > > drm_connector_update_edid_property() or whatever, then the epoch > > > counter > > > would auto-increment if anything has changed. Similarly (long- > > > term > > > idea at > > > least) if anything important with DP registers has changed. > > > > > > Can't we do that, instead of this sub-optimal solution of > > > requiring > > > all > > > drivers to roll out lots of code? > > > > 1) We update edid in intel_dp_set_edid, which is called from > > intel_dp_detect(drm_connector_helper_funcs->detect_ctx hook) which > > is > > called from drm_helper_probe_detect. That one is called either from > > specific intel_encoder->hotplug hook in i915_hotplug_work_func or > > by > > userspace request during reprobe. > > > > 2) Previously we were simply updating edid in intel_dp_set_edid > > without > > caring if it is the same or not and hotplug event was sent only > > once > > connection_status had changed. > > > > 3) drm_connector_update_edid_property is called from connector- > > > get_modes hook(lets say intel_dp_get_modes fo dp) however it > > > simply > > > > uses results of > > drm_helper_probe_detect so without actual comparison it would not > > be > > able to detect if we really need to update epoch_counter or not. > > > > Because as I said currently intel_dp_set_edid simply assigns it > > without > > checking, so that way you will get epoch_counter updated every > > time, > > i.e exactly what you wanted to avoid here. > > > > So we really need someway to determine if edid had changed, instead > > of > > simply assigning it all the time - that is why I had to make this > > function. > > update_edid is the thing which changes the userspace visible edid. We > can > check there with the previous userspace visible edid, and if it's > different, increase the epoch counter. If we never call update_edid > then > userspace won't see the changed edid (it might see the changed mode > list > or whatever), so doing that is pretty much a requirement for > correctness. > > The higher levels should notice the epoch counter change (you might > not > have captured all of them, there's a bunch between ioctl, poll worker > and > sysfs iirc), and send out the uevent. > > Why does that not work? Sure this will work, but still we need somehow to be able to determine this "if it's different" state. In your solution we just move that comparison to drm_connector_update_edid_property, which is quite fine for me. I would say that yes, this idea may be is even better because drivers won't need to
Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
On Wed, Sep 4, 2019 at 10:35 AM Feng Tang wrote: > > Hi Daniel, > > On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote: > > On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann > > wrote: > > > > > > Hi > > > > > > Am 04.09.19 um 08:27 schrieb Feng Tang: > > > >> Thank you for testing. But don't get too excited, because the patch > > > >> simulates a bug that was present in the original mgag200 code. A > > > >> significant number of frames are simply skipped. That is apparently the > > > >> reason why it's faster. > > > > > > > > Thanks for the detailed info, so the original code skips time-consuming > > > > work inside atomic context on purpose. Is there any space to optmise it? > > > > If 2 scheduled update worker are handled at almost same time, can one be > > > > skipped? > > > > > > To my knowledge, there's only one instance of the worker. Re-scheduling > > > the worker before a previous instance started, will not create a second > > > instance. The worker's instance will complete all pending updates. So in > > > some way, skipping workers already happens. > > > > So I think that the most often fbcon update from atomic context is the > > blinking cursor. If you disable that one you should be back to the old > > performance level I think, since just writing to dmesg is from process > > context, so shouldn't change. > > Hmm, then for the old driver, it should also do the most update in > non-atomic context? > > One other thing is, I profiled that updating a 3MB shadow buffer needs > 20 ms, which transfer to 150 MB/s bandwidth. Could it be related with > the cache setting of DRM shadow buffer? say the orginal code use a > cachable buffer? Hm, that would indicate the write-combining got broken somewhere. This should definitely be faster. Also we shouldn't transfer the hole thing, except when scrolling ... > > https://unix.stackexchange.com/questions/3759/how-to-stop-cursor-from-blinking > > > > Bunch of tricks, but tbh I haven't tested them. > > Thomas has suggested to disable curson by > echo 0 > /sys/devices/virtual/graphics/fbcon/cursor_blink > > We tried that way, and no change for the performance data. Huh, if there's other atomic contexts for fbcon update then I'm not aware ... and if it's all the updates, then you wouldn't see a hole lot on your screen, neither with the old or new fbdev support in mgag200. I'm a bit confused ... -Daniel > > Thanks, > Feng > > > > > In any case, I still strongly advice you don't print anything to dmesg > > or fbcon while benchmarking, because dmesg/printf are anything but > > fast, especially if a gpu driver is involved. There's some efforts to > > make the dmesg/printk side less painful (untangling the console_lock > > from printk), but fundamentally printing to the gpu from the kernel > > through dmesg/fbcon won't be cheap. It's just not something we > > optimize beyond "make sure it works for emergencies". > > -Daniel > > > > > > > > Best regards > > > Thomas > > > > > > > > > > > Thanks, > > > > Feng > > > > > > > >> > > > >> Best regards > > > >> Thomas > > > > ___ > > > > dri-devel mailing list > > > > dri-devel@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > > > > -- > > > Thomas Zimmermann > > > Graphics Driver Developer > > > SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany > > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah > > > HRB 21284 (AG Nürnberg) > > > > > > ___ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
On Wed, Sep 4, 2019 at 6:32 PM Russell King - ARM Linux admin
wrote:
>
> On Wed, Sep 04, 2019 at 05:45:20PM +0800, Cheng-yi Chiang wrote:
> > On Wed, Sep 4, 2019 at 5:28 PM Neil Armstrong
> > wrote:
> > >
> > > Hi,
> > >
> > > On 04/09/2019 11:09, Cheng-yi Chiang wrote:
> > > > Hi,
> > > >
> > > > On Tue, Sep 3, 2019 at 5:53 PM Neil Armstrong
> > > > wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> > > >>> From: Yakir Yang
> > > >>>
> > > >>> When transmitting IEC60985 linear PCM audio, we configure the
> > > >>> Audio 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)
> > > >>>
> > > >>> Signed-off-by: Yakir Yang
> > > >>> Signed-off-by: Cheng-Yi Chiang
> > > >>> ---
> > > >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59
> > > >>> +++
> > > >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20
> > > >>> 2 files changed, 79 insertions(+)
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > >>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > >>> index bd65d0479683..34d46e25d610 100644
> > > >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > >>> @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int
> > > >>> freq, unsigned long pixel_clk)
> > > >>> return n;
> > > >>> }
> > > >>>
> > > >>> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
> > > >>> +{
> > > >>> + u8 aud_schnl_samplerate;
> > > >>> + u8 aud_schnl_8;
> > > >>> +
> > > >>> + /* These registers are on RK3288 using version 2.0a. */
> > > >>> + if (hdmi->version != 0x200a)
> > > >>> + return;
> > > >>
> > > >> Are these limited to the 2.0a version *in* RK3288, or 2.0a version on
> > > >> all
> > > >> SoCs ?
> > > >>
> > > >
> > > > In the original patch by Yakir,
> > > >
> > > > https://lore.kernel.org/patchwork/patch/539653/ (sorry, I should
> > > > have added this link in the "after the cut" note)
> > > >
> > > > The fix is limited to version 2.0.
> > > > Since I am only testing on RK3288 with 2.0a, I change the check to 2.0a
> > > > only.
> > > > I can not test 2.0a version on other SoCs.
> > > > The databook I have at hand is 2.0a (not specific to RK3288) so I
> > > > think all 2.0a should have this register.
> > > >
> > > > As for other version like version 1.3 on iMX6, there is no such
> > > > register, as stated by Russell
> > > >
> > > > http://lkml.iu.edu/hypermail/linux/kernel/1501.3/06268.html.
> > >
> > > Russell assumes the registers are not present on the iMX6 IP not having
> > > the I2S registers, but they are present on the IPs configured with I2S
> > > at any versions.
> >
> > I see. Thanks for the check.
> >
> > >
> > > My databook version (1.40.a) specifies :
> > >
> > > fc_audschnls0 to fc_audschnls8
> > >
> > > ```
> > > When transmitting IEC60958 linear PCM audio, this 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).
> > > ```
> > >
> > > But the databook Revision History shows these registers were present
> > > since version 1.10a.
> > >
> > > I propose you remove the version check, but you only setup these
> > > registers when I2S is enabled:
> > > (hdmi_readb(hdmi, HDMI_CONFIG0_ID) & HDMI_CONFIG0_I2S) until a AHBAUDDMA
> > > user needs this,
> > > with a small comment explaining the situation.
> >
> > I see. Sound like a good plan.
> > In sum, I will add
> > set_channel_status()
> > in dw_hdmi.c
> > And in the beginning of this function,
> > check it is using I2S
> > (hdmi_readb(hdmi, HDMI_CONFIG0_ID) & HDMI_CONFIG0_I2S)
> > with a comment explaining the situation.
> >
> > And let dw-hdmi-audio-i2s dw_hdmi_i2s_hw_params() to call this
> > function after dw_hdmi_set_sample_rate, with word length (or
> > sample_bit) passed it as argument.
>
> If you're going to do it this way, there's little point having the
> check. The dw-hdmi-audio-i2s device will only be created if that
> ID bit is already set. So, provided set_channel_status() (which
> should probably be dw_hdmi_set_channel_status()) is only called from
> the I2S driver, then everything should be fine without such a check.
> However, it is worth noting in the docbook comments above the function
> that it is only for I2S setups.
>
I see. Yes it is simpler.
Thanks for the suggestion!
Will fix in v2.
> > I have not tested setting this register here as
Re: [PATCH 4/7] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix
On 03/09/2019 18:24, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Mon, Sep 02, 2019 at 03:53:56PM +0300, Tomi Valkeinen wrote:
>> From: Jyri Sarha
>>
>> Implement CTM color management property for OMAP CRTC using DSS
>> overlay manager's Color Phase Rotation matrix. The CPR matrix does not
>> exactly match the CTM property documentation. On DSS the CPR matrix is
>> applied after gamma table look up. However, it seems stupid to add a
>> custom property just for that.
>
> In that case the DRM documentation should be updated to mention that
> both options are allowed.
>
Ok, if that is alright. But if we do that, then I guess all the drivers
implementing CTM should document the point where it is applied in the
pipeline.
>> Signed-off-by: Jyri Sarha
>> Signed-off-by: Tomi Valkeinen
>> ---
>> drivers/gpu/drm/omapdrm/omap_crtc.c | 39 +++--
>> 1 file changed, 37 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> index 3c5ddbf30e97..d63213dd7d83 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> @@ -391,6 +391,32 @@ static void omap_crtc_manual_display_update(struct
>> work_struct *data)
>> }
>> }
>>
>> +static s16 omap_crtc_S31_32_to_s2_8(s64 coef)
>> +{
>> +uint64_t sign_bit = 1ULL << 63;
>> +uint64_t cbits = (uint64_t) coef;
>
> s/uint64_t/u64/ for both lines as we're dealing with kernel code. And
> there's no need for a space before coef.
>
>> +s16 ret = clamp_val(((cbits & ~sign_bit) >> 24), 0, 0x1FF);
>> +
>> +if (cbits & sign_bit)
>> +ret = -ret;
>> +
>> +return ret;
>
> Can't this be simplified to
>
> s16 ret = (coef >> 24) & 0x1ff;
>
> return coef < 0 ? -ret : ret;
>
No. Clamping is different thing. If the original value is greater than
what we can present with our 2 magnitude bit, we want to use the maximum
value, not something that we may have in the LSB end of bits. e.g if
user-space tries to set the value to 2.0 (= 0x200) we rather present it
as 1.996 (= 0x1FF) than 0.0 (= 0x000).
>> +}
>> +
>> +static void omap_crtc_cpr_coefs_from_ctm(const struct drm_color_ctm *ctm,
>> + struct omap_dss_cpr_coefs *cpr)
>> +{
>> +cpr->rr = omap_crtc_S31_32_to_s2_8(ctm->matrix[0]);
>> +cpr->rg = omap_crtc_S31_32_to_s2_8(ctm->matrix[1]);
>> +cpr->rb = omap_crtc_S31_32_to_s2_8(ctm->matrix[2]);
>> +cpr->gr = omap_crtc_S31_32_to_s2_8(ctm->matrix[3]);
>> +cpr->gg = omap_crtc_S31_32_to_s2_8(ctm->matrix[4]);
>> +cpr->gb = omap_crtc_S31_32_to_s2_8(ctm->matrix[5]);
>> +cpr->br = omap_crtc_S31_32_to_s2_8(ctm->matrix[6]);
>> +cpr->bg = omap_crtc_S31_32_to_s2_8(ctm->matrix[7]);
>> +cpr->bb = omap_crtc_S31_32_to_s2_8(ctm->matrix[8]);
>> +}
>> +
>> static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
>> {
>> struct omap_drm_private *priv = crtc->dev->dev_private;
>> @@ -402,7 +428,16 @@ static void omap_crtc_write_crtc_properties(struct
>> drm_crtc *crtc)
>> info.default_color = 0x00;
>> info.trans_enabled = false;
>> info.partial_alpha_enabled = false;
>> -info.cpr_enable = false;
>> +
>> +if (crtc->state->ctm) {
>> +struct drm_color_ctm *ctm =
>> +(struct drm_color_ctm *) crtc->state->ctm->data;
>> +
>> +info.cpr_enable = true;
>> +omap_crtc_cpr_coefs_from_ctm(ctm, _coefs);
>
> As an optimisation it would be nice to only write the coefficients when
> they actually change. That could be implemented on top of this series.
>
E.g. apply this ?
- if (crtc->state->ctm)
+ if (crtc->state->color_mgmt_changed && crtc->state->ctm)
>> +} else {
>> +info.cpr_enable = false;
>> +}
>>
>> priv->dispc_ops->mgr_setup(priv->dispc, omap_crtc->channel, );
>> }
>> @@ -836,7 +871,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
>> if (priv->dispc_ops->mgr_gamma_size(priv->dispc, channel)) {
>> unsigned int gamma_lut_size = 256;
>>
>> -drm_crtc_enable_color_mgmt(crtc, 0, false, gamma_lut_size);
>> +drm_crtc_enable_color_mgmt(crtc, 0, true, gamma_lut_size);
>> drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
>> }
>>
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] x86/mm: Export force_dma_unencrypted
On 9/4/19 8:58 AM, Christoph Hellwig wrote: On Tue, Sep 03, 2019 at 10:46:18PM +0200, Thomas Hellström (VMware) wrote: What I mean with "from an engineering perspective" is that drivers would end up with a non-trivial amount of code supporting purely academic cases: Setups where software rendering would be faster than gpu accelerated, and setups on platforms where the driver would never run anyway because the device would never be supported on that platform... And actually work on cases you previously called academic and which now matter to you because your employer has a suddent interest in SEV. Academic really is in the eye of the beholder (and of those who pay the bills). But in this particular case we *do* adhere to the dma api, at least as far as we can. But we're missing functionality. That is not really true. The dma API can't handle faulting of coherent pages which is what this series is really all about supporting also with SEV active. To handle the case where we move graphics buffers or send them to swap space while user-space have them mapped. And the only thing we need to support the fault handler is to add an offset to the dma_mmap_* APIs. Which I had planned to do for Christian (one of the few grapics developers who actually tries to play well with the rest of the kernel instead of piling hacks over hacks like many others) anyway, but which hasn't happened yet. That sounds great. Is there anything I can do to help out? I thought this was more or less a dead end since the current dma_mmap_ API requires the mmap_sem to be held in write mode (modifying the vma->vm_flags) whereas fault() only offers read mode. But that would definitely work. Still, I need a way forward and my questions weren't really answered by this. This is pretty demanding. If you "need" a way forward just work with all the relevant people instead of piling ob local hacks. But I think that was what I was trying to initiate. The question was "If it's the latter, then I would like to reiterate that it would be better that we work to come up with a long term plan to add what's missing to the DMA api to help graphics drivers use coherent memory?" And since you NAK'd the original patches, I was sort of hoping for a point in the right direction. Thanks, Thomas
Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
On 9/4/19 10:19 AM, Thomas Hellström (VMware) wrote: Hi, Christian, On 9/4/19 9:33 AM, Koenig, Christian wrote: Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware): On 9/3/19 10:51 PM, Dave Hansen wrote: On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote: So the question here should really be, can we determine already at mmap time whether backing memory will be unencrypted and adjust the *real* vma->vm_page_prot under the mmap_sem? Possibly, but that requires populating the buffer with memory at mmap time rather than at first fault time. I'm not connecting the dots. vma->vm_page_prot is used to create a VMA's PTEs regardless of if they are created at mmap() or fault time. If we establish a good vma->vm_page_prot, can't we just use it forever for demand faults? With SEV I think that we could possibly establish the encryption flags at vma creation time. But thinking of it, it would actually break with SME where buffer content can be moved between encrypted system memory and unencrypted graphics card PCI memory behind user-space's back. That would imply killing all user-space encrypted PTEs and at fault time set up new ones pointing to unencrypted PCI memory.. Well my problem is where do you see encrypted system memory here? At least for AMD GPUs all memory accessed must be unencrypted and that counts for both system as well as PCI memory. We're talking SME now right? The current SME setup is that if a device's DMA mask says it's capable of addressing the encryption bit, coherent memory will be encrypted. The memory controllers will decrypt for the device on the fly. Otherwise coherent memory will be decrypted. So I don't get why we can't assume always unencrypted and keep it like that. I see two reasons. First, it would break with a real device that signals it's capable of addressing the encryption bit. Second I can imagine unaccelerated setups (something like vkms using prime feeding a VNC connection) where we actually want the TTM buffers encrypted to protect data. But at least the latter reason is way far out in the future. So for me I'm ok with that if that works for you? Hmm, BTW, Are you sure the AMD GPUs use unencrypted system memory rather than relying on the memory controllers to decrypt? In that case it seems strange that they get away with encrypted TTM PTEs, whereas vmwgfx don't... /Thomas /Thomas Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
On Wed, Sep 4, 2019 at 2:00 AM Neil Armstrong wrote:
>
> Hi,
>
> Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
> > Hi,
> >
> > On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> >> From: Yakir Yang
> >>
> >> When transmitting IEC60985 linear PCM audio, we configure the
> >> Audio 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)
> >>
> >> Signed-off-by: Yakir Yang
> >> Signed-off-by: Cheng-Yi Chiang
> >> ---
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20
> >> 2 files changed, 79 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> index bd65d0479683..34d46e25d610 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int freq,
> >> unsigned long pixel_clk)
> >> return n;
> >> }
> >>
> >> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
> >> +{
> >> +u8 aud_schnl_samplerate;
> >> +u8 aud_schnl_8;
> >> +
> >> +/* These registers are on RK3288 using version 2.0a. */
> >> +if (hdmi->version != 0x200a)
> >> +return;
> >
> > Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
> > SoCs ?
>
> After investigations, Amlogic sets these registers on their 2.0a version
> aswell, and Jernej (added in Cc) reported me Allwinner sets them on their
> < 2.0a and > 2.0a IPs versions.
>
> Can you check on the Rockchip IP versions in RK3399 ?
>
Sorry, the RK3399 board I am using is using DP, not HDMI.
But I found that on rockchip's tree at
https://github.com/rockchip-linux/kernel/commit/924f480383c982da9908fb96d6bbb580b25545a5#diff-f74b4cfb23436a137a9338a5af3fbb3dR172
There is such register setting, so I think RK3399 should have the same register.
> For reference, the HDMI 1.4a IP version allwinner setups is:
> https://github.com/Allwinner-Homlet/H3-BSP4.4-linux/blob/master/drivers/video/fbdev/sunxi/disp2/hdmi/hdmi_bsp_sun8iw7.c#L531-L539
> (registers a "scrambled" but a custom bit can reset to the original mapping,
> 0x1066 ... 0x106f)
I see.. so 1.4 has this register.
I can modify the check to be >= 1.4 then.
Will fix in v2.
Thanks!
>
> Neil
>
> >
> >> +
> >> +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;
> >> +
> >> +/* This means word length is 16 bit. Refer to IEC60958-3 page 12. */
> >> +aud_schnl_8 |= 2 << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET;
> >> +
> >> +hdmi_writeb(hdmi, aud_schnl_8, HDMI_FC_AUDSCHNLS8);
> >> +}
> >> +
> >> static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
> >> unsigned long pixel_clk, unsigned int sample_rate)
> >> {
> >> @@ -620,6 +677,8 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi
> >> *hdmi,
> >> hdmi->audio_cts = cts;
> >> hdmi_set_cts_n(hdmi, cts, hdmi->audio_enable ? n : 0);
> >> spin_unlock_irq(>audio_lock);
> >> +
> >> +hdmi_set_schnl(hdmi);
> >> }
> >>
> >> static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
> >> diff --git
Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
On Wed, Sep 4, 2019 at 2:08 AM Jernej Škrabec wrote:
>
> Hi!
>
> Dne torek, 03. september 2019 ob 20:00:33 CEST je Neil Armstrong napisal(a):
> > Hi,
> >
> > Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
> > > Hi,
> > >
> > > On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> > >> From: Yakir Yang
> > >>
> > >> When transmitting IEC60985 linear PCM audio, we configure the
> > >> Audio 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)
> > >>
> > >> Signed-off-by: Yakir Yang
> > >> Signed-off-by: Cheng-Yi Chiang
> > >> ---
> > >>
> > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++
> > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20
> > >> 2 files changed, 79 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> > >> bd65d0479683..34d46e25d610 100644
> > >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >> @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int
> > >> freq, unsigned long pixel_clk)>>
> > >>return n;
> > >>
> > >> }
> > >>
> > >> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
> > >> +{
> > >> + u8 aud_schnl_samplerate;
> > >> + u8 aud_schnl_8;
> > >> +
> > >> + /* These registers are on RK3288 using version 2.0a. */
> > >> + if (hdmi->version != 0x200a)
> > >> + return;
> > >
> > > Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
> > > SoCs ?
> >
> > After investigations, Amlogic sets these registers on their 2.0a version
> > aswell, and Jernej (added in Cc) reported me Allwinner sets them on their
> > < 2.0a and > 2.0a IPs versions.
> >
> > Can you check on the Rockchip IP versions in RK3399 ?
> >
> > For reference, the HDMI 1.4a IP version allwinner setups is:
> > https://github.com/Allwinner-Homlet/H3-BSP4.4-linux/blob/master/drivers/vide
> > o/fbdev/sunxi/disp2/hdmi/hdmi_bsp_sun8iw7.c#L531-L539 (registers a
> > "scrambled" but a custom bit can reset to the original mapping, 0x1066 ...
> > 0x106f)
>
> For easier reading, here is similar, but annotated version: http://ix.io/1Ub6
> Check function bsp_hdmi_audio().
>
> Unless there is a special reason, you can just remove that check.
>
Thanks for the great reference.
I also see that I need to set the word length according to the desired
value passed by dw_hdmi_i2s_hw_params in dw-hdmi-i2s-audio.c.
Will fix in v2.
> Best regards,
> Jernej
>
> >
> > Neil
> >
> > >> +
> > >> + 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;
> > >> +
> > >> + /* This means word length is 16 bit. Refer to IEC60958-3 page 12.
> */
> > >> + aud_schnl_8 |= 2 << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET;
> > >> +
> > >> + hdmi_writeb(hdmi, aud_schnl_8, HDMI_FC_AUDSCHNLS8);
> > >> +}
> > >> +
> > >>
> > >> static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
> > >>
> > >>unsigned long pixel_clk, unsigned int sample_rate)
> > >>
> > >> {
> > >>
> > >> @@ -620,6 +677,8 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi
> > >> *hdmi,>>
> > >>hdmi->audio_cts = cts;
> > >>hdmi_set_cts_n(hdmi,
Re: [PATCH v3 0/3] Send a hotplug when edid changes
On Wed, 2019-09-04 at 11:23 +0200, Daniel Vetter wrote: > > > Sure this will work, but still we need somehow to be able to > > determine > > this "if it's different" state. In your solution we just move that > > comparison to drm_connector_update_edid_property, which is quite > > fine > > for me. > > Yes we need to compare edid somewhere, that much is clear. I'm not > disputing that. I just want something where we don't have to roll > this out > over all the drivers, because that's a hopeless endeavour. > > > I would say that yes, this idea may be is even better because > > drivers won't need to implement this comparison in encoder->hotplug > > in > > each driver. > > However: > > we still need a comparison in > > drm_connector_update_edid_property(drm_edid_equal) and also I'm not > > sure we can send a hotplug event based on that as > > drm_connector_update_edid_property seems > > to get called only during connector init or during reprobe from > > userspace from connector->get_modes hook. > > Also it is called from drm_kms_helper_hotplug_event from, but this > > one > > is called from i915 only if connection status had changed. > > So ditch the optimization to only call ->get_modes when called from > userspace? We've been talking about this one too in the past ... > > I'd really like a solution where it will work for most drivers out of > the > box. So I guess the conclusion would be to try to use drm_connector_update_edid_property that way we will avoid duplicating drm_edid_equal code in all drivers. However this might require ensuring that drm_connector_update_edid_property is always called when we get a hotplug, so there we can check if edid had changed and send uevent, if needed. - Stanislav > -Daniel > > > > > - Stanislav > > > > > > > -Daniel > > > > > > > > > > > Cheers, > > > > > > > > Stanislav > > > > > > > > > > > > > -Daniel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Stanislav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Stanislav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, Daniel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Stanislav > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Daniel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stanislav Lisovskiy (3): > > > > > > > > > > > > > > > drm: Add helper to compare edids. > > > > > > > > > > > > > > > drm: Introduce change counter to > > > > > > > > > > > > > > > drm_connector > > > > > > > > > > > > > > > drm/i915: Send hotplug event if edid > > > > > > > > > > > > > > > had > > > > > > > > > > > > > > > changed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > drivers/gpu/drm/drm_connector.c > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > 1 + > > > > > > > > > > > > > > > drivers/gpu/drm/drm_edid.c > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > 33 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > drivers/gpu/drm/drm_probe_helper.c > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > 29 > > > > > > > > > > > > > > > +++- > > > > > > > > > > > > > > > - > > > > > > > > > > > > > > > drivers/gpu/drm/i915/display/intel_dp.c > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > 16 > > > > > > > > > > > > > > > +- > > > > > > > > > > > > > > > drivers/gpu/drm/i915/display/intel_hdmi. > > > > > > > > > > > > > > > c > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > 16 > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > drivers/gpu/drm/i915/display/intel_hotpl > > > > > > > > > > > > > > > ug.c > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 21 > > > > > > > > > > > > > > > ++ > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > include/drm/drm_connector.h > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > 3 ++ > > > > > > > > > > > > > > > include/drm/drm_edid.h > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > 9 > > > > > > > > > > > > > > > ++ > > > > > > > > > > > > > > > 8 files changed, 117 insertions(+), 11 > > > > > > > > > > > > > > > deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > 2.17.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
On 9/4/19 9:53 AM, Daniel Vetter wrote: On Wed, Sep 4, 2019 at 8:49 AM Thomas Hellström (VMware) wrote: On 9/4/19 1:15 AM, Andy Lutomirski wrote: But, reading this, I have more questions: Can’t you get rid of cvma by using vmf_insert_pfn_prot()? It looks like that, although there are comments in the code about serious performance problems using VM_PFNMAP / vmf_insert_pfn() with write-combining and PAT, so that would require some serious testing with hardware I don't have. But I guess there is definitely room for improvement here. Ideally we'd like to be able to change the vma->vm_page_prot within fault(). But we can Just a quick comment on this: It's the repeated (per-pfn/pte) lookup of the PAT tables, which are dead slow. If you have a struct io_mapping then that can be done once, and then just blindly inserted. See remap_io_mapping in i915. -Daniel Thanks, Daniel. Indeed looks a lot like remap_pfn_range(), but usable at fault time? /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
Hi Am 04.09.19 um 08:27 schrieb Feng Tang: >> Thank you for testing. But don't get too excited, because the patch >> simulates a bug that was present in the original mgag200 code. A >> significant number of frames are simply skipped. That is apparently the >> reason why it's faster. > > Thanks for the detailed info, so the original code skips time-consuming > work inside atomic context on purpose. Is there any space to optmise it? > If 2 scheduled update worker are handled at almost same time, can one be > skipped? To my knowledge, there's only one instance of the worker. Re-scheduling the worker before a previous instance started, will not create a second instance. The worker's instance will complete all pending updates. So in some way, skipping workers already happens. Best regards Thomas > > Thanks, > Feng > >> >> Best regards >> Thomas > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature
Re: gnome-shell stuck because of amdgpu driver [5.3 RC5]
On Wed, Sep 04, 2019 at 09:17:16AM +0800, Hillf Danton wrote: > Daniel Vetter > >> > >> Now 11:01pm and "gnome shell stuck warning" not appear since 19:17. So > >> looks like issue happens only when computer blocked and monitor in > >> power save mode. > > > > I'd bet on runtime pm or some other power saving feature in amdgpu > > shutting the interrupt handling down before we've handled all the > > interrupts. That would then result in a stuck fence. > > > > Do we already know which fence is stuck? > > It is welcomed to shed a thread of light on how to collect/print that info. > Say line:xxx-yyy in path/to/amdgpu/zzz.c 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 ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
On Wed, Sep 4, 2019 at 4:33 AM Jonas Karlman wrote:
>
> On 2019-09-03 20:08, Jernej Škrabec wrote:
> > Hi!
> >
> > Dne torek, 03. september 2019 ob 20:00:33 CEST je Neil Armstrong napisal(a):
> >> Hi,
> >>
> >> Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
> >>> Hi,
> >>>
> >>> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> From: Yakir Yang
>
> When transmitting IEC60985 linear PCM audio, we configure the
> Audio 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)
>
> Signed-off-by: Yakir Yang
> Signed-off-by: Cheng-Yi Chiang
> ---
>
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20
> 2 files changed, 79 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> bd65d0479683..34d46e25d610 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int
> freq, unsigned long pixel_clk)>>
> return n;
>
> }
>
> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
> +{
> + u8 aud_schnl_samplerate;
> + u8 aud_schnl_8;
> +
> + /* These registers are on RK3288 using version 2.0a. */
> + if (hdmi->version != 0x200a)
> + return;
> >>> Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
> >>> SoCs ?
> >> After investigations, Amlogic sets these registers on their 2.0a version
> >> aswell, and Jernej (added in Cc) reported me Allwinner sets them on their
> >> < 2.0a and > 2.0a IPs versions.
> >>
> >> Can you check on the Rockchip IP versions in RK3399 ?
> >>
> >> For reference, the HDMI 1.4a IP version allwinner setups is:
> >> https://github.com/Allwinner-Homlet/H3-BSP4.4-linux/blob/master/drivers/vide
> >> o/fbdev/sunxi/disp2/hdmi/hdmi_bsp_sun8iw7.c#L531-L539 (registers a
> >> "scrambled" but a custom bit can reset to the original mapping, 0x1066 ...
> >> 0x106f)
> > For easier reading, here is similar, but annotated version:
> > http://ix.io/1Ub6
> > Check function bsp_hdmi_audio().
> >
> > Unless there is a special reason, you can just remove that check.
>
> Agree, this check should not be needed, AUDSCHNLS7 used to be configured in
> my old
> multi-channel patches that have seen lot of testing on Amlogic, Allwinner and
> Rockchip SoCs.
>
As stated in previous mail, I will modify the check for version >=1.4
since I know that 1.3 does not have such register, at least on iMX6.
> >
> > Best regards,
> > Jernej
> >
> >> Neil
> >>
> +
> + 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;
> +
> + /* This means word length is 16 bit. Refer to IEC60958-3 page 12. */
> + aud_schnl_8 |= 2 << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET;
>
> This looks wrong, user can use 16 and 24 bit wide audio streams.
>
Thanks for spotting this issue.
I will fix it in v2 (following how http://ix.io/1Ub6 set it for 16 and 24 bit)
> +
> +
Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
On Wed, 4 Sep 2019 at 19:17, Daniel Vetter wrote: > > On Wed, Sep 4, 2019 at 10:35 AM Feng Tang wrote: > > > > Hi Daniel, > > > > On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote: > > > On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann > > > wrote: > > > > > > > > Hi > > > > > > > > Am 04.09.19 um 08:27 schrieb Feng Tang: > > > > >> Thank you for testing. But don't get too excited, because the patch > > > > >> simulates a bug that was present in the original mgag200 code. A > > > > >> significant number of frames are simply skipped. That is apparently > > > > >> the > > > > >> reason why it's faster. > > > > > > > > > > Thanks for the detailed info, so the original code skips > > > > > time-consuming > > > > > work inside atomic context on purpose. Is there any space to optmise > > > > > it? > > > > > If 2 scheduled update worker are handled at almost same time, can one > > > > > be > > > > > skipped? > > > > > > > > To my knowledge, there's only one instance of the worker. Re-scheduling > > > > the worker before a previous instance started, will not create a second > > > > instance. The worker's instance will complete all pending updates. So in > > > > some way, skipping workers already happens. > > > > > > So I think that the most often fbcon update from atomic context is the > > > blinking cursor. If you disable that one you should be back to the old > > > performance level I think, since just writing to dmesg is from process > > > context, so shouldn't change. > > > > Hmm, then for the old driver, it should also do the most update in > > non-atomic context? > > > > One other thing is, I profiled that updating a 3MB shadow buffer needs > > 20 ms, which transfer to 150 MB/s bandwidth. Could it be related with > > the cache setting of DRM shadow buffer? say the orginal code use a > > cachable buffer? > > Hm, that would indicate the write-combining got broken somewhere. This > should definitely be faster. Also we shouldn't transfer the hole > thing, except when scrolling ... First rule of fbcon usage, you are always effectively scrolling. Also these devices might be on a PCIE 1x piece of wet string, not sure if the numbers reflect that. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
potential regression in drm/mgag200
Hi, While doing some changes to x86's pat code and thus having 'debugpat', I noticed some weird behavior in a server running linux-next as of -- yes, reverting does 'fix' the issue: 90f479ae51a (drm/mgag200: Replace struct mga_fbdev with generic framebuffer emulation) Where the following splat is seen over and over endlessly for the same range: x86/PAT: Overlap at 0xd000-0xd100 x86/PAT: reserve_memtype added [mem 0xd000-0xd02f], track write-combining, req write-combining, ret write-combining x86/PAT: free_memtype request [mem 0xd000-0xd02f] And all these are doing ioremap from drm_fb_helper_dirty_work(): [ 114.330825] reserve_memtype+0x1b0/0x410 [ 114.330829] ? ttm_bo_kmap+0x1d7/0x270 [ttm] [ 114.330830] __ioremap_caller.constprop.14+0xf6/0x300 [ 114.330832] ? soft_cursor+0x1f9/0x220 [ 114.330835] ttm_bo_kmap+0x1d7/0x270 [ttm] [ 114.330838] ? ttm_bo_del_sub_from_lru+0x29/0x40 [ttm] [ 114.330841] drm_gem_vram_kmap+0x54/0x70 [drm_vram_helper] [ 114.330842] drm_gem_vram_object_vmap+0x23/0x40 [drm_vram_helper] [ 114.330853] drm_gem_vmap+0x1f/0x60 [drm] [ 114.477697] drm_client_buffer_vmap+0x1d/0x30 [drm] [ 114.477703] drm_fb_helper_dirty_work+0x92/0x180 [drm_kms_helper] [ 114.477706] process_one_work+0x1f4/0x3e0 [ 114.477707] worker_thread+0x2d/0x3e0 Before, the same range was also added, but only once, and fwiw it was the same either with 24 or 32 bpp. Any thoughts? Thanks, Davidlohr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Adreno crash on i.MX53 running 5.3-rc6
Hi, I tried this and it works with patches 4+5 from Rob's series and changing gpummu to use sg_phys(sg) instead of sg->dma_address (dma_address isn't set now that dma_map_sg isn't used). Jonathan On 9/3/19 11:22 AM, Rob Clark wrote: On Mon, Sep 2, 2019 at 11:03 AM Fabio Estevam wrote: Hi Robin, On Mon, Sep 2, 2019 at 11:45 AM Robin Murphy wrote: Try 0036bc73ccbe - that looks like something that CONFIG_DMA_API_DEBUG should have been screaming about anyway. Thanks for your suggestion. I can successfully boot after reverting the following commits: commit 141db5703c887f46957615cd6616ca28fe4691e0 (HEAD) Author: Fabio Estevam Date: Mon Sep 2 14:58:18 2019 -0300 Revert "drm/msm: stop abusing dma_map/unmap for cache" This reverts commit 0036bc73ccbe7e600a3468bf8e8879b122252274. commit fa5b1f620f2984c254877d6049214c39c24c8207 Author: Fabio Estevam Date: Mon Sep 2 14:56:01 2019 -0300 Revert "drm/msm: Use the correct dma_sync calls in msm_gem" This reverts commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c. Rob, What would be the recommended approach for fixing this? We need a direct way to handle cache, so we can stop trying to trick DMA API into doing what we want. Something like this is what I had in mind: https://patchwork.freedesktop.org/series/65211/ I guess I could respin that. I'm not really sure of any other way to have things working on the different combinations of archs and dma_ops that we have. Lately fixing one has been breaking another. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/10] [v10] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel
Hi Sam：
sorry，My reply was late.
I commited to the following commit (d6781e490179 - (HEAD -> tmp, tag:
drm-misc-next-2019-08-03) drm/pl111: Drop special pads config check (3
weeks ago) )
I don't know why you executed the error.
- Can you paste your mistakes?
I used the following command to join patch.
0005-v5-2-2-drm-panel-Add-Boe-Himax8279d-MIPI-DSI-LCD-pan.patch did
not change the code.
I just adjusted the form of commit according to your suggestions.
so you can skip this patch.
Thank you for your guidance. If there are any questions. I hope you
can point them out. I will modify it very quickly.
Thanks.
Sam Ravnborg 于2019年8月3日周六 下午10:37写道：
>
> Hi Jerry.
>
> On Sat, Aug 03, 2019 at 10:40:44AM +0800, Jerry Han wrote:
> > V1: https://patchwork.freedesktop.org/patch/287425/
> > V2: https://patchwork.freedesktop.org/patch/289843/
> > V3: https://patchwork.freedesktop.org/patch/290393/
> > V4: https://patchwork.freedesktop.org/patch/290396/
> > V5: https://patchwork.freedesktop.org/patch/291131/ (only modify
> > commit message Added changelog, no files modified)
> > V6: https://patchwork.freedesktop.org/patch/291650/
> > V7: https://patchwork.freedesktop.org/patch/294141/
> > V8: https://patchwork.freedesktop.org/patch/301925/
> > V9: https://patchwork.freedesktop.org/patch/320514/
>
> > From 63bcc4f1e72713eca14c4b08e62bc3c07e67904a Mon Sep 17 00:00:00 2001
> > From: Jerry Han
> > Date: Thu, 1 Aug 2019 15:52:35 +0800
> > Subject: [PATCH 02/10] [v2,2/2] drm/panel: Add Boe Himax8279d MIPI-DSI LCD
> > panel
> >
> > Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
> > panel.
> >
> > V2:
> > - Use SPDX identifier (Sam)
> > - Use necessary header files replace drmP.h (Sam)
> > - Delete unnecessary header files #include (Sam)
> > - Specifies a GPIOs array to control the reset timing,
> > instead of reading "dsi-reset-sequence" data from DTS (Sam)
> > - Delete backlight_disable() function when already disabled (Sam)
> > - Use devm_of_find_backlight() replace of_find_backlight_by_node()
> > (Sam)
> > - Move the necessary data in the DTS to the current file,
> > like porch, display_mode and Init code etc. (Sam)
> > - Add compatible device "boe,himax8279d10p" (Sam)
> >
> > V1:
> > - Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
> > panel.
>
> Something went wrong when you tried to submit v10.
> Please try again.
>
> Sam
>
>
> >
> > Signed-off-by: Jerry Han
> > Cc: Jitao Shi
> > Cc: Nick Sanders
> > Cc: YH Lin
> > Cc: Rock wang
> > ---
> > drivers/gpu/drm/panel/Makefile |2 +-
> > drivers/gpu/drm/panel/panel-boe-himax8279d.c | 1201 --
> > 2 files changed, 842 insertions(+), 361 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index 1aef9d72c7a6..29c57e915ee6 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -1,5 +1,6 @@
> > # SPDX-License-Identifier: GPL-2.0
> > obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
> > +obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
> > obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
> > obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
> > obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) +=
> > panel-feiyang-fy07024di26a30d.o
> > @@ -30,6 +31,5 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) +=
> > panel-sharp-lq101r1sx01.o
> > obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
> > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> > -obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
> > obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
> > obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> > diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> > b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> > index 2788bdda69ec..836a9cbc5891 100644
> > --- a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> > +++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
> > @@ -1,319 +1,76 @@
> > // SPDX-License-Identifier: GPL-2.0
> > /*
> > - * Copyright (c) 2019, Huaqin Electronics Co., Ltd
> > + * Copyright (c) 2019, Huaqin Telecom Technology Co., Ltd
> > + *
> > + * Author: Jerry Han
> > *
> > - * This program is free software; you can redistribute it and/or modify
> > - * it under the terms of the GNU General Public License as published by
> > - * the Free Software Foundation; either version 2 of the License, or
> > - * (at your option) any later version.
> > */
> >
> > #include
> > -#include
> > +#include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > +
> > +#include
> > #include
> >
> > -#include
> > -#include
> > +#include
> > #include
> > #include
> > +#include
> > +#include
> >
> > #include
> > -#include
> >
> > -struct dsi_cmd_desc {
>
Re: [PATCH] backlight: ipaq_micro: Make structure micro_bl_props constant
On Tue, 3 Sep 2019 at 21:49, Daniel Thompson wrote:
>
> On Tue, Aug 13, 2019 at 10:12:51AM +0100, Daniel Thompson wrote:
> > On Tue, Aug 13, 2019 at 02:28:55PM +0530, Nishka Dasgupta wrote:
> > > Static structure micro_bl_props, having type backlight_properties, is
> > > used only once, when it is passed as the last argument to function
> > > devm_backlight_device_register(). devm_backlight_device_register() is
> > > defined with its last parameter being declared constant. Hence make
> > > micro_bl_props itself constant as well.
> > > Issue found with Coccinelle.
> >
> > Did you do any review to see if this pattern occurs in other backlight
> > drivers (it looks to me like the same pattern appears in
> > rave-sp-backlight.c... do the tools bring that one out as well).
>
> Ping?
Sorry, did my reply not go through?
I had said:
No, the Coccinelle script I'm using doesn't flag any other backlight
drivers. It's possible that the script just missed something. Which
structure in rave-sp-backlight.c could potentially be made const?
Thanking you,
Nishka
>
>
> Daniel.
>
>
> > > Signed-off-by: Nishka Dasgupta
> > > ---
> > > drivers/video/backlight/ipaq_micro_bl.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/video/backlight/ipaq_micro_bl.c
> > > b/drivers/video/backlight/ipaq_micro_bl.c
> > > index 1123f67c12b3..85b16cc82878 100644
> > > --- a/drivers/video/backlight/ipaq_micro_bl.c
> > > +++ b/drivers/video/backlight/ipaq_micro_bl.c
> > > @@ -44,7 +44,7 @@ static const struct backlight_ops micro_bl_ops = {
> > > .update_status = micro_bl_update_status,
> > > };
> > >
> > > -static struct backlight_properties micro_bl_props = {
> > > +static const struct backlight_properties micro_bl_props = {
> > > .type = BACKLIGHT_RAW,
> > > .max_brightness = 255,
> > > .power = FB_BLANK_UNBLANK,
> > > --
> > > 2.19.1
> > >
___
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 Tue, 3 Sep 2019 11:48:12 +0500 From: Mikhail Gavrilov > On Fri, 30 Aug 2019 at 08:30, Hillf Danton wrote: > > > > Add a warning to show if it makes sense in field: neither regression nor > > problem will have been observed with the warning printed. > > I caught the problem. > > > [21793.094289] [ cut here ] > [21793.094296] gnome shell stuck warning > [21793.094391] WARNING: CPU: 14 PID: 1768 at > drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:332 > Thanks Mike. Describe the problems you are experiencing please. Say is the screen locked up? Machine lockedup? Anything unnormal after you see the warning? Hillf ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
On Wed, Sep 4, 2019 at 8:49 AM Thomas Hellström (VMware) wrote: > On 9/4/19 1:15 AM, Andy Lutomirski wrote: > > But, reading this, I have more questions: > > > > Can’t you get rid of cvma by using vmf_insert_pfn_prot()? > > It looks like that, although there are comments in the code about > serious performance problems using VM_PFNMAP / vmf_insert_pfn() with > write-combining and PAT, so that would require some serious testing with > hardware I don't have. But I guess there is definitely room for > improvement here. Ideally we'd like to be able to change the > vma->vm_page_prot within fault(). But we can Just a quick comment on this: It's the repeated (per-pfn/pte) lookup of the PAT tables, which are dead slow. If you have a struct io_mapping then that can be done once, and then just blindly inserted. See remap_io_mapping in i915. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
Hi Daniel, On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote: > On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann wrote: > > > > Hi > > > > Am 04.09.19 um 08:27 schrieb Feng Tang: > > >> Thank you for testing. But don't get too excited, because the patch > > >> simulates a bug that was present in the original mgag200 code. A > > >> significant number of frames are simply skipped. That is apparently the > > >> reason why it's faster. > > > > > > Thanks for the detailed info, so the original code skips time-consuming > > > work inside atomic context on purpose. Is there any space to optmise it? > > > If 2 scheduled update worker are handled at almost same time, can one be > > > skipped? > > > > To my knowledge, there's only one instance of the worker. Re-scheduling > > the worker before a previous instance started, will not create a second > > instance. The worker's instance will complete all pending updates. So in > > some way, skipping workers already happens. > > So I think that the most often fbcon update from atomic context is the > blinking cursor. If you disable that one you should be back to the old > performance level I think, since just writing to dmesg is from process > context, so shouldn't change. Hmm, then for the old driver, it should also do the most update in non-atomic context? One other thing is, I profiled that updating a 3MB shadow buffer needs 20 ms, which transfer to 150 MB/s bandwidth. Could it be related with the cache setting of DRM shadow buffer? say the orginal code use a cachable buffer? > > https://unix.stackexchange.com/questions/3759/how-to-stop-cursor-from-blinking > > Bunch of tricks, but tbh I haven't tested them. Thomas has suggested to disable curson by echo 0 > /sys/devices/virtual/graphics/fbcon/cursor_blink We tried that way, and no change for the performance data. Thanks, Feng > > In any case, I still strongly advice you don't print anything to dmesg > or fbcon while benchmarking, because dmesg/printf are anything but > fast, especially if a gpu driver is involved. There's some efforts to > make the dmesg/printk side less painful (untangling the console_lock > from printk), but fundamentally printing to the gpu from the kernel > through dmesg/fbcon won't be cheap. It's just not something we > optimize beyond "make sure it works for emergencies". > -Daniel > > > > > Best regards > > Thomas > > > > > > > > Thanks, > > > Feng > > > > > >> > > >> Best regards > > >> Thomas > > > ___ > > > dri-devel mailing list > > > dri-devel@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > > > -- > > Thomas Zimmermann > > Graphics Driver Developer > > SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah > > HRB 21284 (AG Nürnberg) > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/virtio: fix command submission with objects but without fence.
Only call virtio_gpu_array_add_fence if we actually have a fence.
Fixes: da758d51968a ("drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing")
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 595fa6ec2d58..7fd2851f7b97 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -339,11 +339,12 @@ static void virtio_gpu_queue_fenced_ctrl_buffer(struct
virtio_gpu_device *vgdev,
goto again;
}
- if (fence)
+ if (fence) {
virtio_gpu_fence_emit(vgdev, hdr, fence);
- if (vbuf->objs) {
- virtio_gpu_array_add_fence(vbuf->objs, >f);
- virtio_gpu_array_unlock_resv(vbuf->objs);
+ if (vbuf->objs) {
+ virtio_gpu_array_add_fence(vbuf->objs, >f);
+ virtio_gpu_array_unlock_resv(vbuf->objs);
+ }
}
notify = virtio_gpu_queue_ctrl_buffer_locked(vgdev, vbuf);
spin_unlock(>ctrlq.qlock);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=109246 --- Comment #27 from Michel Dänzer --- Disabling input probing in the monitor isn't a full workaround for me (with an HP EliteDisplay E242, in case it matters). The monitor stays off, but there's still a hotplug event, which requires me to re-arrange the windows of my GNOME session every time after unlocking it. So this is still kind of a DC showstopper for me. -- 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 RFC v4 01/16] drm: Add drm_minor_for_each
On Tue, Sep 03, 2019 at 04:43:45PM -0400, Kenny Ho wrote:
> On Tue, Sep 3, 2019 at 4:12 PM Daniel Vetter wrote:
> > On Tue, Sep 3, 2019 at 9:45 PM Kenny Ho wrote:
> > > On Tue, Sep 3, 2019 at 3:57 AM Daniel Vetter wrote:
> > > > Iterating over minors for cgroups sounds very, very wrong. Why do we
> > > > care
> > > > whether a buffer was allocated through kms dumb vs render nodes?
> > > >
> > > > I'd expect all the cgroup stuff to only work on drm_device, if it does
> > > > care about devices.
> > > >
> > > > (I didn't look through the patch series to find out where exactly you're
> > > > using this, so maybe I'm off the rails here).
> > >
> > > I am exposing this to remove the need to keep track of a separate list
> > > of available drm_device in the system (to remove the registering and
> > > unregistering of drm_device to the cgroup subsystem and just use
> > > drm_minor as the single source of truth.) I am only filtering out the
> > > render nodes minor because they point to the same drm_device and is
> > > confusing.
> > >
> > > Perhaps I missed an obvious way to list the drm devices without
> > > iterating through the drm_minors? (I probably jumped to the minors
> > > because $major:$minor is the convention to address devices in cgroup.)
> >
> > Create your own if there's nothing, because you need to anyway:
> > - You need special locking anyway, we can't just block on the idr lock
> > for everything.
> > - This needs to refcount drm_device, no the minors.
> >
> > Iterating over stuff still feels kinda wrong still, because normally
> > the way we register/unregister userspace api (and cgroups isn't
> > anything else from a drm driver pov) is by adding more calls to
> > drm_dev_register/unregister. If you put a drm_cg_register/unregister
> > call in there we have a clean separation, and you can track all the
> > currently active devices however you want. Iterating over objects that
> > can be hotunplugged any time tends to get really complicated really
> > quickly.
>
> Um... I thought this is what I had previously. Did I misunderstood
> your feedback from v3? Doesn't drm_minor already include all these
> facilities so isn't creating my own kind of reinventing the wheel?
> (as I did previously?) drm_minor_register is called inside
> drm_dev_register so isn't leveraging existing drm_minor facilities
> much better solution?
Hm the previous version already dropped out of my inbox, so hard to find
it again. And I couldn't find this in archieves. Do you have pointers?
I thought the previous version did cgroup init separately from drm_device
setup, and I guess I suggested that it should be moved int
drm_dev_register/unregister?
Anyway, I don't think reusing the drm_minor registration makes sense,
since we want to be on the drm_device, not on the minor. Which is a bit
awkward for cgroups, which wants to identify devices using major.minor
pairs. But I guess drm is the first subsystem where 1 device can be
exposed through multiple minors ...
Tejun, any suggestions on this?
Anyway, I think just leveraging existing code because it can be abused to
make it fit for us doesn't make sense. E.g. for the kms side we also don't
piggy-back on top of drm_minor_register (it would be technically
possible), but instead we have drm_modeset_register_all().
-Daniel
>
> Kenny
>
> >
> >
> > >
> > > Kenny
> > >
> > > > -Daniel
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/drm_drv.c | 19 +++
> > > > > drivers/gpu/drm/drm_internal.h | 4
> > > > > include/drm/drm_drv.h | 4
> > > > > 3 files changed, 23 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > > > index 862621494a93..000cddabd970 100644
> > > > > --- a/drivers/gpu/drm/drm_drv.c
> > > > > +++ b/drivers/gpu/drm/drm_drv.c
> > > > > @@ -254,11 +254,13 @@ struct drm_minor *drm_minor_acquire(unsigned
> > > > > int minor_id)
> > > > >
> > > > > return minor;
> > > > > }
> > > > > +EXPORT_SYMBOL(drm_minor_acquire);
> > > > >
> > > > > void drm_minor_release(struct drm_minor *minor)
> > > > > {
> > > > > drm_dev_put(minor->dev);
> > > > > }
> > > > > +EXPORT_SYMBOL(drm_minor_release);
> > > > >
> > > > > /**
> > > > > * DOC: driver instance overview
> > > > > @@ -1078,6 +1080,23 @@ int drm_dev_set_unique(struct drm_device *dev,
> > > > > const char *name)
> > > > > }
> > > > > EXPORT_SYMBOL(drm_dev_set_unique);
> > > > >
> > > > > +/**
> > > > > + * drm_minor_for_each - Iterate through all stored DRM minors
> > > > > + * @fn: Function to be called for each pointer.
> > > > > + * @data: Data passed to callback function.
> > > > > + *
> > > > > + * The callback function will be called for each @drm_minor entry,
> > > > > passing
> > > > > + * the minor, the entry and @data.
> > > > > + *
> > > > > + * If @fn returns anything other than %0, the iteration stops and
> > > > > that
> > > > > + * value is returned from this
Re: [PATCH AUTOSEL 4.19 044/167] drm/amdgpu: validate user pitch alignment
On 2019-09-03 10:16 p.m., Daniel Vetter wrote: > On Tue, Sep 3, 2019 at 10:01 PM Sasha Levin wrote: >> On Tue, Sep 03, 2019 at 07:03:47PM +0200, Greg KH wrote: >>> On Tue, Sep 03, 2019 at 06:40:43PM +0200, Michel Dänzer wrote: On 2019-09-03 6:23 p.m., Sasha Levin wrote: > From: Yu Zhao > > [ Upstream commit 89f23b6efef554766177bf51aa754bce14c3e7da ] Hold your horses! This commit and c4a32b266da7bb702e60381ca0c35eaddbc89a6c had to be reverted, as they caused regressions. See commits 25ec429e86bb790e40387a550f0501d0ac55a47c & 92b0730eaf2d549fdfb10ecc8b71f34b9f472c12 . This isn't bolstering confidence in how these patches are selected... >>> >>> The patch _itself_ said to be backported to the stable trees from 4.2 >>> and newer. Why wouldn't we be confident in doing this? >>> >>> If the patch doesn't want to be backported, then do not add the cc: >>> stable line to it... >> >> This patch was picked because it has a stable tag, which you presumably >> saw as your Reviewed-by tag is in the patch. This is why it was >> backported; it doesn't take AI to backport patches tagged for stable... The patches did point to gaps in validation of ioctl parameters passed in by userspace. Unfortunately, they turned out to be too strict, causing valid parameters to spuriously fail. If that wasn't the case, and the patches didn't have stable tags, maybe we'd be having a discussion about why they didn't have the tags now... >> The revert of this patch, however: >> >> 1. Didn't have a stable tag. I guess it didn't occur to me that was necessary, as the patches got reverted within days. >> 2. Didn't have a "Fixes:" tag. >> 3. Didn't have the usual "the reverts commit ..." string added by git >> when one does a revert. I suspect that's because there were no stable commit hashes to reference, see below. >> Which is why we still kick patches for review, even though they had a >> stable tag, just so people could take a look and confirm we're not >> missing anything - like we did here. >> >> I'm not sure what you expected me to do differently here. Yeah, sorry, I didn't realize it's tricky for scripts to recognize that the patches have been reverted in this case. > Yeah this looks like fail on the revert side, they need to reference > the reverted commit somehow ... > > Alex, why got this dropped? Is this more fallout from the back > shuffling you're doing between your internal branches behind the > firewall, and the public history? I do suspect that was at least a contributing factor. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
Hi,
On Tue, Sep 3, 2019 at 5:53 PM Neil Armstrong wrote:
>
> Hi,
>
> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> > From: Yakir Yang
> >
> > When transmitting IEC60985 linear PCM audio, we configure the
> > Audio 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)
> >
> > Signed-off-by: Yakir Yang
> > Signed-off-by: Cheng-Yi Chiang
> > ---
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20
> > 2 files changed, 79 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index bd65d0479683..34d46e25d610 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int freq,
> > unsigned long pixel_clk)
> > return n;
> > }
> >
> > +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
> > +{
> > + u8 aud_schnl_samplerate;
> > + u8 aud_schnl_8;
> > +
> > + /* These registers are on RK3288 using version 2.0a. */
> > + if (hdmi->version != 0x200a)
> > + return;
>
> Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
> SoCs ?
>
In the original patch by Yakir,
https://lore.kernel.org/patchwork/patch/539653/ (sorry, I should
have added this link in the "after the cut" note)
The fix is limited to version 2.0.
Since I am only testing on RK3288 with 2.0a, I change the check to 2.0a only.
I can not test 2.0a version on other SoCs.
The databook I have at hand is 2.0a (not specific to RK3288) so I
think all 2.0a should have this register.
As for other version like version 1.3 on iMX6, there is no such
register, as stated by Russell
http://lkml.iu.edu/hypermail/linux/kernel/1501.3/06268.html.
So at least we should check the version.
Maybe we can set the criteria as version 2.0 or above to make it a safe patch ?
If there is the same need on other SoC with version < 2.0, it can be
added later.
Presumably, there will be databook of that version to help confirming
this setting.
Thanks!
> > +
> > + 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;
> > +
> > + /* This means word length is 16 bit. Refer to IEC60958-3 page 12. */
> > + aud_schnl_8 |= 2 << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET;
> > +
> > + hdmi_writeb(hdmi, aud_schnl_8, HDMI_FC_AUDSCHNLS8);
> > +}
> > +
> > static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
> > unsigned long pixel_clk, unsigned int sample_rate)
> > {
> > @@ -620,6 +677,8 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi
> > *hdmi,
> > hdmi->audio_cts = cts;
> > hdmi_set_cts_n(hdmi, cts, hdmi->audio_enable ? n : 0);
> > spin_unlock_irq(>audio_lock);
> > +
> > + hdmi_set_schnl(hdmi);
> > }
> >
> > static void hdmi_init_clk_regenerator(struct dw_hdmi *hdmi)
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > index 6988f12d89d9..619ebc1c8354 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h
> > @@
Re: [RFC][PATCH] drm: kirin: Fix dsi probe/attach logic
On 03.09.2019 18:18, John Stultz wrote: > On Mon, Sep 2, 2019 at 6:22 AM Andrzej Hajda wrote: >> On 30.08.2019 19:00, Rob Clark wrote: >>> On Thu, Aug 29, 2019 at 11:52 PM Andrzej Hajda wrote: Of course it seems you have different opinion what is the right thing in this case, so if you convince us that your approach is better one can revert the patch. >>> I guess my strongest / most immediate opinion is to not break other >>> existing adv75xx bridge users. >> >> It is pity that breakage happened, and next time we should be more >> strict about testing other platforms, before patch acceptance. >> >> But reverting it now will break also platform which depend on it. > I'm really of no opinion of which approach is better here, but I will > say that when a patch breaks previously working boards, that's a > regression and justifying that some other board is now enabled that > would be broken by the revert (of a patch that is not yet upstream) > isn't really a strong argument. > > I'm happy to work with folks to try to fixup the kirin driver if this > patch really is the right approach, but we need someone to do the same > for the db410c, and I don't think its fair to just dump that work onto > folks under the threat of the board breaking. These drivers should be fixed anyway - assumption that drm_bridge/drm_panel will be registered before the bus it is attached to is just incorrect. So instead of reverting, fixing and then re-applying the patch I have gently proposed shorter path. If you prefer long path we can try to go this way. Matt, is the pure revert OK for you or is it possible to prepare some workaround allowing cooperation with both approaches? Regards Andrzej > > thanks > -john > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm tree with the kbuild tree
Hi all,
Today's linux-next merge of the drm tree got conflicts in:
drivers/gpu/drm/amd/display/dc/calcs/Makefile
drivers/gpu/drm/amd/display/dc/dml/Makefile
drivers/gpu/drm/amd/display/dc/dsc/Makefile
between commit:
30851871d5ab ("kbuild: change *FLAGS_.o to take the path relative
to $(obj)")
from the kbuild tree and commit:
0f0727d971f6 ("drm/amd/display: readd -msse2 to prevent Clang from emitting
libcalls to undefined SW FP routines")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/display/dc/calcs/Makefile
index d930df63772c,16614d73a5fc..
--- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
@@@ -32,9 -32,13 +32,13 @@@ endi
calcs_ccflags := -mhard-float -msse $(cc_stack_align)
+ ifdef CONFIG_CC_IS_CLANG
+ calcs_ccflags += -msse2
+ endif
+
-CFLAGS_dcn_calcs.o := $(calcs_ccflags)
-CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
-CFLAGS_dcn_calc_math.o := $(calcs_ccflags) -Wno-tautological-compare
+CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_ccflags)
-Wno-tautological-compare
BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o
diff --cc drivers/gpu/drm/amd/display/dc/dml/Makefile
index 83792e2c0f0e,95fd2beca80c..
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@@ -32,16 -32,25 +32,20 @@@ endi
dml_ccflags := -mhard-float -msse $(cc_stack_align)
+ ifdef CONFIG_CC_IS_CLANG
+ dml_ccflags += -msse2
+ endif
+
-CFLAGS_display_mode_lib.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
ifdef CONFIG_DRM_AMD_DC_DCN2_0
-CFLAGS_display_mode_vba.o := $(dml_ccflags)
-CFLAGS_display_mode_vba_20.o := $(dml_ccflags)
-CFLAGS_display_rq_dlg_calc_20.o := $(dml_ccflags)
-CFLAGS_display_mode_vba_20v2.o := $(dml_ccflags)
-CFLAGS_display_rq_dlg_calc_20v2.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20.o := $(dml_ccflags)
endif
-ifdef CONFIG_DRM_AMD_DCN3AG
-CFLAGS_display_mode_vba_3ag.o := $(dml_ccflags)
-endif
-CFLAGS_dml1_display_rq_dlg_calc.o := $(dml_ccflags)
-CFLAGS_display_rq_dlg_helpers.o := $(dml_ccflags)
-CFLAGS_dml_common_defs.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/dml1_display_rq_dlg_calc.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/display_rq_dlg_helpers.o := $(dml_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dml/dml_common_defs.o := $(dml_ccflags)
DML = display_mode_lib.o display_rq_dlg_helpers.o dml1_display_rq_dlg_calc.o \
dml_common_defs.o
diff --cc drivers/gpu/drm/amd/display/dc/dsc/Makefile
index c3922d6e7696,17db603f2d1f..
--- a/drivers/gpu/drm/amd/display/dc/dsc/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dsc/Makefile
@@@ -9,9 -9,14 +9,13 @@@ endi
dsc_ccflags := -mhard-float -msse $(cc_stack_align)
+ ifdef CONFIG_CC_IS_CLANG
+ dsc_ccflags += -msse2
+ endif
+
-CFLAGS_rc_calc.o := $(dsc_ccflags)
-CFLAGS_rc_calc_dpi.o := $(dsc_ccflags)
-CFLAGS_codec_main_amd.o := $(dsc_ccflags)
-CFLAGS_dc_dsc.o := $(dsc_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dsc/rc_calc.o := $(dsc_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dsc/rc_calc_dpi.o := $(dsc_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/dsc/dc_dsc.o := $(dsc_ccflags)
DSC = dc_dsc.o rc_calc.o rc_calc_dpi.o
pgpIrfWsl3LDd.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108979] Graphical glitch of popupping missing texture on Mesa version >18.0.5 (Padoka Stable + Unstable/Oibaf/ubuntu-x-swat PPAs)
https://bugs.freedesktop.org/show_bug.cgi?id=108979 --- Comment #6 from Timothy Arceri --- Is this still a 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
Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
Hi,
On 04/09/2019 11:09, Cheng-yi Chiang wrote:
> Hi,
>
> On Tue, Sep 3, 2019 at 5:53 PM Neil Armstrong wrote:
>>
>> Hi,
>>
>> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
>>> From: Yakir Yang
>>>
>>> When transmitting IEC60985 linear PCM audio, we configure the
>>> Audio 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)
>>>
>>> Signed-off-by: Yakir Yang
>>> Signed-off-by: Cheng-Yi Chiang
>>> ---
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20
>>> 2 files changed, 79 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> index bd65d0479683..34d46e25d610 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>>> @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int freq,
>>> unsigned long pixel_clk)
>>> return n;
>>> }
>>>
>>> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
>>> +{
>>> + u8 aud_schnl_samplerate;
>>> + u8 aud_schnl_8;
>>> +
>>> + /* These registers are on RK3288 using version 2.0a. */
>>> + if (hdmi->version != 0x200a)
>>> + return;
>>
>> Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
>> SoCs ?
>>
>
> In the original patch by Yakir,
>
> https://lore.kernel.org/patchwork/patch/539653/ (sorry, I should
> have added this link in the "after the cut" note)
>
> The fix is limited to version 2.0.
> Since I am only testing on RK3288 with 2.0a, I change the check to 2.0a only.
> I can not test 2.0a version on other SoCs.
> The databook I have at hand is 2.0a (not specific to RK3288) so I
> think all 2.0a should have this register.
>
> As for other version like version 1.3 on iMX6, there is no such
> register, as stated by Russell
>
> http://lkml.iu.edu/hypermail/linux/kernel/1501.3/06268.html.
Russell assumes the registers are not present on the iMX6 IP not having
the I2S registers, but they are present on the IPs configured with I2S
at any versions.
My databook version (1.40.a) specifies :
fc_audschnls0 to fc_audschnls8
```
When transmitting IEC60958 linear PCM audio, this 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).
```
But the databook Revision History shows these registers were present since
version 1.10a.
I propose you remove the version check, but you only setup these registers when
I2S is enabled:
(hdmi_readb(hdmi, HDMI_CONFIG0_ID) & HDMI_CONFIG0_I2S) until a AHBAUDDMA user
needs this,
with a small comment explaining the situation.
Neil
>
> So at least we should check the version.
> Maybe we can set the criteria as version 2.0 or above to make it a safe patch
> ?
> If there is the same need on other SoC with version < 2.0, it can be
> added later.
> Presumably, there will be databook of that version to help confirming
> this setting.
>
> Thanks!
>>> +
>>> + 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.
>>> + */
>>> +
Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
On Wed, Sep 04, 2019 at 05:09:29PM +0800, Cheng-yi Chiang wrote:
> Hi,
>
> On Tue, Sep 3, 2019 at 5:53 PM Neil Armstrong wrote:
> >
> > Hi,
> >
> > On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> > > From: Yakir Yang
> > >
> > > When transmitting IEC60985 linear PCM audio, we configure the
> > > Audio 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)
> > >
> > > Signed-off-by: Yakir Yang
> > > Signed-off-by: Cheng-Yi Chiang
> > > ---
> > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++
> > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20
> > > 2 files changed, 79 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > index bd65d0479683..34d46e25d610 100644
> > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > > @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int
> > > freq, unsigned long pixel_clk)
> > > return n;
> > > }
> > >
> > > +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
> > > +{
> > > + u8 aud_schnl_samplerate;
> > > + u8 aud_schnl_8;
> > > +
> > > + /* These registers are on RK3288 using version 2.0a. */
> > > + if (hdmi->version != 0x200a)
> > > + return;
> >
> > Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
> > SoCs ?
> >
>
> In the original patch by Yakir,
>
> https://lore.kernel.org/patchwork/patch/539653/ (sorry, I should
> have added this link in the "after the cut" note)
>
> The fix is limited to version 2.0.
> Since I am only testing on RK3288 with 2.0a, I change the check to 2.0a only.
> I can not test 2.0a version on other SoCs.
> The databook I have at hand is 2.0a (not specific to RK3288) so I
> think all 2.0a should have this register.
>
> As for other version like version 1.3 on iMX6, there is no such
> register, as stated by Russell
>
> http://lkml.iu.edu/hypermail/linux/kernel/1501.3/06268.html.
It's likely more to do with how the IP is configured rather than the
version. The big difference between dw-hdmi used in iMX6 and elsewhere
is that iMX6 uses a built-in AHB audio interface and not I2S. Elsewhere
uses I2S.
I2S does not have the capability to convey channel status information
(which is required by HDMI). With AHB, it is encoded into the data in
memory.
So, I think this setup should be done in the I2S driver and not in the
core driver.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #65 from tempel.jul...@gmail.com --- @Nicholas Since this commit, the modesetting driver shows the same behavior as xf86-video-amdgpu: https://gitlab.freedesktop.org/xorg/xserver/commit/f0d78b47ac49977a6007f5fe081f00c6eb19a12e So, now only xwayland isn't affected. But I think this can very well be just because Wayland compositors yet don't support turning compositing off in fullscreen. We might see the same effect as on Xorg, where keeping some compositors enabled seems to "fix" the issue (at the cost of high input latency, other performance issues and non-functional FreeSync). -- 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 4/7] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix
Hi Jyri,
On Wed, Sep 04, 2019 at 10:17:00AM +0300, Jyri Sarha wrote:
> On 03/09/2019 18:24, Laurent Pinchart wrote:
> > On Mon, Sep 02, 2019 at 03:53:56PM +0300, Tomi Valkeinen wrote:
> >> From: Jyri Sarha
> >>
> >> Implement CTM color management property for OMAP CRTC using DSS
> >> overlay manager's Color Phase Rotation matrix. The CPR matrix does not
> >> exactly match the CTM property documentation. On DSS the CPR matrix is
> >> applied after gamma table look up. However, it seems stupid to add a
> >> custom property just for that.
> >
> > In that case the DRM documentation should be updated to mention that
> > both options are allowed.
>
> Ok, if that is alright. But if we do that, then I guess all the drivers
> implementing CTM should document the point where it is applied in the
> pipeline.
Whatever solution we end up picking, I think it should at least be
discussed with a broader upstream audience and not just swept under the
omapdrm carpet :-)
> >> Signed-off-by: Jyri Sarha
> >> Signed-off-by: Tomi Valkeinen
> >> ---
> >> drivers/gpu/drm/omapdrm/omap_crtc.c | 39 +++--
> >> 1 file changed, 37 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> index 3c5ddbf30e97..d63213dd7d83 100644
> >> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> @@ -391,6 +391,32 @@ static void omap_crtc_manual_display_update(struct
> >> work_struct *data)
> >>}
> >> }
> >>
> >> +static s16 omap_crtc_S31_32_to_s2_8(s64 coef)
> >> +{
> >> + uint64_t sign_bit = 1ULL << 63;
> >> + uint64_t cbits = (uint64_t) coef;
> >
> > s/uint64_t/u64/ for both lines as we're dealing with kernel code. And
> > there's no need for a space before coef.
> >
> >> + s16 ret = clamp_val(((cbits & ~sign_bit) >> 24), 0, 0x1FF);
> >> +
> >> + if (cbits & sign_bit)
> >> + ret = -ret;
> >> +
> >> + return ret;
> >
> > Can't this be simplified to
> >
> > s16 ret = (coef >> 24) & 0x1ff;
> >
> > return coef < 0 ? -ret : ret;
> >
>
> No. Clamping is different thing. If the original value is greater than
> what we can present with our 2 magnitude bit, we want to use the maximum
> value, not something that we may have in the LSB end of bits. e.g if
> user-space tries to set the value to 2.0 (= 0x200) we rather present it
> as 1.996 (= 0x1FF) than 0.0 (= 0x000).
Of course, my bad.
Perhaps a stupid question, should we reject out of range values at
atomic check time ?
> >> +}
> >> +
> >> +static void omap_crtc_cpr_coefs_from_ctm(const struct drm_color_ctm *ctm,
> >> + struct omap_dss_cpr_coefs *cpr)
> >> +{
> >> + cpr->rr = omap_crtc_S31_32_to_s2_8(ctm->matrix[0]);
> >> + cpr->rg = omap_crtc_S31_32_to_s2_8(ctm->matrix[1]);
> >> + cpr->rb = omap_crtc_S31_32_to_s2_8(ctm->matrix[2]);
> >> + cpr->gr = omap_crtc_S31_32_to_s2_8(ctm->matrix[3]);
> >> + cpr->gg = omap_crtc_S31_32_to_s2_8(ctm->matrix[4]);
> >> + cpr->gb = omap_crtc_S31_32_to_s2_8(ctm->matrix[5]);
> >> + cpr->br = omap_crtc_S31_32_to_s2_8(ctm->matrix[6]);
> >> + cpr->bg = omap_crtc_S31_32_to_s2_8(ctm->matrix[7]);
> >> + cpr->bb = omap_crtc_S31_32_to_s2_8(ctm->matrix[8]);
> >> +}
> >> +
> >> static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
> >> {
> >>struct omap_drm_private *priv = crtc->dev->dev_private;
> >> @@ -402,7 +428,16 @@ static void omap_crtc_write_crtc_properties(struct
> >> drm_crtc *crtc)
> >>info.default_color = 0x00;
> >>info.trans_enabled = false;
> >>info.partial_alpha_enabled = false;
> >> - info.cpr_enable = false;
> >> +
> >> + if (crtc->state->ctm) {
> >> + struct drm_color_ctm *ctm =
> >> + (struct drm_color_ctm *) crtc->state->ctm->data;
> >> +
> >> + info.cpr_enable = true;
> >> + omap_crtc_cpr_coefs_from_ctm(ctm, _coefs);
> >
> > As an optimisation it would be nice to only write the coefficients when
> > they actually change. That could be implemented on top of this series.
>
> E.g. apply this ?
>
> - if (crtc->state->ctm)
> + if (crtc->state->color_mgmt_changed && crtc->state->ctm)
Something like that, but .mgr_setup() should then be taught not to write
unchanged CTM tables to registers. Do you think it would be worth it ?
> >> + } else {
> >> + info.cpr_enable = false;
> >> + }
> >>
> >>priv->dispc_ops->mgr_setup(priv->dispc, omap_crtc->channel, );
> >> }
> >> @@ -836,7 +871,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
> >>if (priv->dispc_ops->mgr_gamma_size(priv->dispc, channel)) {
> >>unsigned int gamma_lut_size = 256;
> >>
> >> - drm_crtc_enable_color_mgmt(crtc, 0, false, gamma_lut_size);
> >> + drm_crtc_enable_color_mgmt(crtc, 0, true, gamma_lut_size);
> >>drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
> >>}
> >>
--
Regards,
Laurent Pinchart
Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
On Wed, Sep 4, 2019 at 1:15 PM Dave Airlie wrote: > > On Wed, 4 Sep 2019 at 19:17, Daniel Vetter wrote: > > > > On Wed, Sep 4, 2019 at 10:35 AM Feng Tang wrote: > > > > > > Hi Daniel, > > > > > > On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote: > > > > On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann > > > > wrote: > > > > > > > > > > Hi > > > > > > > > > > Am 04.09.19 um 08:27 schrieb Feng Tang: > > > > > >> Thank you for testing. But don't get too excited, because the patch > > > > > >> simulates a bug that was present in the original mgag200 code. A > > > > > >> significant number of frames are simply skipped. That is > > > > > >> apparently the > > > > > >> reason why it's faster. > > > > > > > > > > > > Thanks for the detailed info, so the original code skips > > > > > > time-consuming > > > > > > work inside atomic context on purpose. Is there any space to > > > > > > optmise it? > > > > > > If 2 scheduled update worker are handled at almost same time, can > > > > > > one be > > > > > > skipped? > > > > > > > > > > To my knowledge, there's only one instance of the worker. > > > > > Re-scheduling > > > > > the worker before a previous instance started, will not create a > > > > > second > > > > > instance. The worker's instance will complete all pending updates. So > > > > > in > > > > > some way, skipping workers already happens. > > > > > > > > So I think that the most often fbcon update from atomic context is the > > > > blinking cursor. If you disable that one you should be back to the old > > > > performance level I think, since just writing to dmesg is from process > > > > context, so shouldn't change. > > > > > > Hmm, then for the old driver, it should also do the most update in > > > non-atomic context? > > > > > > One other thing is, I profiled that updating a 3MB shadow buffer needs > > > 20 ms, which transfer to 150 MB/s bandwidth. Could it be related with > > > the cache setting of DRM shadow buffer? say the orginal code use a > > > cachable buffer? > > > > Hm, that would indicate the write-combining got broken somewhere. This > > should definitely be faster. Also we shouldn't transfer the hole > > thing, except when scrolling ... > > First rule of fbcon usage, you are always effectively scrolling. > > Also these devices might be on a PCIE 1x piece of wet string, not sure > if the numbers reflect that. pcie 1x 1.0 is 250MB/s, so yeah with a bit of inefficiency and overhead not entirely out of the question that 150MB/s is actually the hw limit. If it's really pcie 1x 1.0, no idea where to check that. Also might be worth to double-check that the gpu pci bar is listed as wc in debugfs/x86/pat_memtype_list. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ 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]
Daniel Vetter >> >> Now 11:01pm and "gnome shell stuck warning" not appear since 19:17. So >> looks like issue happens only when computer blocked and monitor in >> power save mode. > > I'd bet on runtime pm or some other power saving feature in amdgpu > shutting the interrupt handling down before we've handled all the > interrupts. That would then result in a stuck fence. > > Do we already know which fence is stuck? It is welcomed to shed a thread of light on how to collect/print that info. Say line:xxx-yyy in path/to/amdgpu/zzz.c Thanks Hillf ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Sep 3 (gpu/drm/amd/display/)
On 9/3/19 3:17 AM, Stephen Rothwell wrote: > Hi all, > > News: I will only be doing 1 more release before I leave for Kernel > Summit (there may be some reports on Thursday, but I doubt I will have > time to finish the full release) and then no more until Sept 30. > > Changes since 20190902: > on i386: CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.o ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_ipp_create’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:641:3: error: implicit declaration of function ‘kzalloc’; did you mean ‘d_alloc’? [-Werror=implicit-function-declaration] kzalloc(sizeof(struct dcn10_ipp), GFP_KERNEL); ^~~ d_alloc ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:641:3: warning: initialization makes pointer from integer without a cast [-Wint-conversion] ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_dpp_create’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:658:3: warning: initialization makes pointer from integer without a cast [-Wint-conversion] kzalloc(sizeof(struct dcn20_dpp), GFP_KERNEL); ^~~ ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:668:2: error: implicit declaration of function ‘kfree’; did you mean ‘ida_free’? [-Werror=implicit-function-declaration] kfree(dpp); ^ ida_free ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_aux_engine_create’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:677:3: warning: initialization makes pointer from integer without a cast [-Wint-conversion] kzalloc(sizeof(struct aux_engine_dce110), GFP_KERNEL); ^~~ ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_i2c_hw_create’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:712:3: warning: initialization makes pointer from integer without a cast [-Wint-conversion] kzalloc(sizeof(struct dce_i2c_hw), GFP_KERNEL); ^~~ CC [M] drivers/gpu/drm/i915/display/intel_atomic_plane.o ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_validate_bandwidth’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:1068:38: warning: initialization makes pointer from integer without a cast [-Wint-conversion] display_e2e_pipe_params_st *pipes = kzalloc(dc->res_pool->pipe_count * sizeof(display_e2e_pipe_params_st), GFP_KERNEL); ^~~ ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_clock_source_create’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:1126:3: warning: initialization makes pointer from integer without a cast [-Wint-conversion] kzalloc(sizeof(struct dce110_clk_src), GFP_KERNEL); ^~~ ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_hubp_create’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:1146:3: warning: initialization makes pointer from integer without a cast [-Wint-conversion] kzalloc(sizeof(struct dcn21_hubp), GFP_KERNEL); ^~~ ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_hubbub_create’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:1164:32: warning: initialization makes pointer from integer without a cast [-Wint-conversion] struct dcn20_hubbub *hubbub = kzalloc(sizeof(struct dcn20_hubbub), ^~~ ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_opp_create’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:1192:3: warning: initialization makes pointer from integer without a cast [-Wint-conversion] kzalloc(sizeof(struct dcn20_opp), GFP_KERNEL); ^~~ ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_timing_generator_create’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:1209:3: warning: initialization makes pointer from integer without a cast [-Wint-conversion] kzalloc(sizeof(struct optc), GFP_KERNEL); ^~~ ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_mpc_create’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:1228:28: warning: initialization makes pointer from integer without a cast [-Wint-conversion] struct dcn20_mpc *mpc20 = kzalloc(sizeof(struct dcn20_mpc), ^~~ ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c: In function ‘dcn21_pp_smu_create’: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_resource.c:1333:32: warning: initialization makes pointer from integer without a cast [-Wint-conversion] struct pp_smu_funcs *pp_smu =
Re: [PATCH] drm/vkms: Use alpha value to blend values.
On Mon, Sep 02, 2019 at 03:28:58PM +0300, Ville Syrjälä wrote:
> On Sat, Aug 31, 2019 at 06:25:46PM +0100, Sidong Yang wrote:
> > Use alpha value to blend source value and destination value Instead of
> > just overwrite with source value.
> >
> > Signed-off-by: Sidong Yang
> > ---
> > drivers/gpu/drm/vkms/vkms_composer.c | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index d5585695c64d..b776185e5cb5 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -75,6 +75,9 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> > int y_limit = y_src + h_dst;
> > int x_limit = x_src + w_dst;
> >
> > + u8 *src, *dst;
> > + u32 alpha, inv_alpha;
>
> These could all live in a tighter scope.
Hi, Ville.
Thank you for reviewing my patch.
I think that's good idea and I'll do that in next version.
I found some patch in mailing list that is similar with this patch.
So should I drop this patch and find other thing?
Sidong.
>
> Apart from that lgtm
> Reviewed-by: Ville Syrjälä
>
> > +
> > for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
> > for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
> > offset_dst = dest_composer->offset
> > @@ -84,8 +87,14 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> > + (i * src_composer->pitch)
> > + (j * src_composer->cpp);
> >
> > - memcpy(vaddr_dst + offset_dst,
> > - vaddr_src + offset_src, sizeof(u32));
> > + src = vaddr_src + offset_src;
> > + dst = vaddr_dst + offset_dst;
> > + alpha = src[3] + 1;
> > + inv_alpha = 256 - src[3];
> > + dst[0] = (alpha * src[0] + inv_alpha * dst[0]) >> 8;
> > + dst[1] = (alpha * src[1] + inv_alpha * dst[1]) >> 8;
> > + dst[2] = (alpha * src[2] + inv_alpha * dst[2]) >> 8;
> > + dst[3] = 0xff;
> > }
> > i_dst++;
> > }
> > --
> > 2.20.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
Hi, Christian, On 9/4/19 9:33 AM, Koenig, Christian wrote: Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware): On 9/3/19 10:51 PM, Dave Hansen wrote: On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote: So the question here should really be, can we determine already at mmap time whether backing memory will be unencrypted and adjust the *real* vma->vm_page_prot under the mmap_sem? Possibly, but that requires populating the buffer with memory at mmap time rather than at first fault time. I'm not connecting the dots. vma->vm_page_prot is used to create a VMA's PTEs regardless of if they are created at mmap() or fault time. If we establish a good vma->vm_page_prot, can't we just use it forever for demand faults? With SEV I think that we could possibly establish the encryption flags at vma creation time. But thinking of it, it would actually break with SME where buffer content can be moved between encrypted system memory and unencrypted graphics card PCI memory behind user-space's back. That would imply killing all user-space encrypted PTEs and at fault time set up new ones pointing to unencrypted PCI memory.. Well my problem is where do you see encrypted system memory here? At least for AMD GPUs all memory accessed must be unencrypted and that counts for both system as well as PCI memory. We're talking SME now right? The current SME setup is that if a device's DMA mask says it's capable of addressing the encryption bit, coherent memory will be encrypted. The memory controllers will decrypt for the device on the fly. Otherwise coherent memory will be decrypted. So I don't get why we can't assume always unencrypted and keep it like that. I see two reasons. First, it would break with a real device that signals it's capable of addressing the encryption bit. Second I can imagine unaccelerated setups (something like vkms using prime feeding a VNC connection) where we actually want the TTM buffers encrypted to protect data. But at least the latter reason is way far out in the future. So for me I'm ok with that if that works for you? /Thomas Regards, Christian.
Re: [PATCH 6/7] drm/omap: dss: platform_register_drivers() to dss.c and remove core.c
On 03/09/2019 18:34, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> Missing "Move" in the subject after "dss: " ?
>
That was intentional to keep the subject short enough. But it looks like
it is just bellow 76 chars (80 - 4 char indent) even with "Move" added
to it.
BR,
Jyri
> On Mon, Sep 02, 2019 at 03:53:58PM +0300, Tomi Valkeinen wrote:
>> From: Jyri Sarha
>>
>> The core.c just for registering the drivers is kind of useless. Let's
>> get rid of it and register the dss drivers in dss.c.
>>
>> Signed-off-by: Jyri Sarha
>> Signed-off-by: Tomi Valkeinen
>
> Reviewed-by: Laurent Pinchart
>
>> ---
>> drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
>> drivers/gpu/drm/omapdrm/dss/core.c | 55
>> drivers/gpu/drm/omapdrm/dss/dss.c| 37 +++
>> 3 files changed, 38 insertions(+), 56 deletions(-)
>> delete mode 100644 drivers/gpu/drm/omapdrm/dss/core.c
>>
>> diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile
>> b/drivers/gpu/drm/omapdrm/dss/Makefile
>> index 904101c5e79d..5950c3f52c2e 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/Makefile
>> +++ b/drivers/gpu/drm/omapdrm/dss/Makefile
>> @@ -6,7 +6,7 @@ omapdss-base-y := base.o display.o dss-of.o output.o
>>
>> obj-$(CONFIG_OMAP2_DSS) += omapdss.o
>> # Core DSS files
>> -omapdss-y := core.o dss.o dispc.o dispc_coefs.o \
>> +omapdss-y := dss.o dispc.o dispc_coefs.o \
>> pll.o video-pll.o
>> omapdss-$(CONFIG_OMAP2_DSS_DPI) += dpi.o
>> omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
>> diff --git a/drivers/gpu/drm/omapdrm/dss/core.c
>> b/drivers/gpu/drm/omapdrm/dss/core.c
>> deleted file mode 100644
>> index 6ac497b63711..
>> --- a/drivers/gpu/drm/omapdrm/dss/core.c
>> +++ /dev/null
>> @@ -1,55 +0,0 @@
>> -// SPDX-License-Identifier: GPL-2.0-only
>> -/*
>> - * Copyright (C) 2009 Nokia Corporation
>> - * Author: Tomi Valkeinen
>> - *
>> - * Some code and ideas taken from drivers/video/omap/ driver
>> - * by Imre Deak.
>> - */
>> -
>> -#define DSS_SUBSYS_NAME "CORE"
>> -
>> -#include
>> -#include
>> -#include
>> -
>> -#include "omapdss.h"
>> -#include "dss.h"
>> -
>> -/* INIT */
>> -static struct platform_driver * const omap_dss_drivers[] = {
>> -_dsshw_driver,
>> -_dispchw_driver,
>> -#ifdef CONFIG_OMAP2_DSS_DSI
>> -_dsihw_driver,
>> -#endif
>> -#ifdef CONFIG_OMAP2_DSS_VENC
>> -_venchw_driver,
>> -#endif
>> -#ifdef CONFIG_OMAP4_DSS_HDMI
>> -_hdmi4hw_driver,
>> -#endif
>> -#ifdef CONFIG_OMAP5_DSS_HDMI
>> -_hdmi5hw_driver,
>> -#endif
>> -};
>> -
>> -static int __init omap_dss_init(void)
>> -{
>> -return platform_register_drivers(omap_dss_drivers,
>> - ARRAY_SIZE(omap_dss_drivers));
>> -}
>> -
>> -static void __exit omap_dss_exit(void)
>> -{
>> -platform_unregister_drivers(omap_dss_drivers,
>> -ARRAY_SIZE(omap_dss_drivers));
>> -}
>> -
>> -module_init(omap_dss_init);
>> -module_exit(omap_dss_exit);
>> -
>> -MODULE_AUTHOR("Tomi Valkeinen ");
>> -MODULE_DESCRIPTION("OMAP2/3 Display Subsystem");
>> -MODULE_LICENSE("GPL v2");
>> -
>> diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
>> b/drivers/gpu/drm/omapdrm/dss/dss.c
>> index e226324adb69..41d495a360d8 100644
>> --- a/drivers/gpu/drm/omapdrm/dss/dss.c
>> +++ b/drivers/gpu/drm/omapdrm/dss/dss.c
>> @@ -1598,3 +1598,40 @@ struct platform_driver omap_dsshw_driver = {
>> .suppress_bind_attrs = true,
>> },
>> };
>> +
>> +/* INIT */
>> +static struct platform_driver * const omap_dss_drivers[] = {
>> +_dsshw_driver,
>> +_dispchw_driver,
>> +#ifdef CONFIG_OMAP2_DSS_DSI
>> +_dsihw_driver,
>> +#endif
>> +#ifdef CONFIG_OMAP2_DSS_VENC
>> +_venchw_driver,
>> +#endif
>> +#ifdef CONFIG_OMAP4_DSS_HDMI
>> +_hdmi4hw_driver,
>> +#endif
>> +#ifdef CONFIG_OMAP5_DSS_HDMI
>> +_hdmi5hw_driver,
>> +#endif
>> +};
>> +
>> +static int __init omap_dss_init(void)
>> +{
>> +return platform_register_drivers(omap_dss_drivers,
>> + ARRAY_SIZE(omap_dss_drivers));
>> +}
>> +
>> +static void __exit omap_dss_exit(void)
>> +{
>> +platform_unregister_drivers(omap_dss_drivers,
>> +ARRAY_SIZE(omap_dss_drivers));
>> +}
>> +
>> +module_init(omap_dss_init);
>> +module_exit(omap_dss_exit);
>> +
>> +MODULE_AUTHOR("Tomi Valkeinen ");
>> +MODULE_DESCRIPTION("OMAP2/3/4/5 Display Subsystem");
>> +MODULE_LICENSE("GPL v2");
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann wrote: > > Hi > > Am 04.09.19 um 08:27 schrieb Feng Tang: > >> Thank you for testing. But don't get too excited, because the patch > >> simulates a bug that was present in the original mgag200 code. A > >> significant number of frames are simply skipped. That is apparently the > >> reason why it's faster. > > > > Thanks for the detailed info, so the original code skips time-consuming > > work inside atomic context on purpose. Is there any space to optmise it? > > If 2 scheduled update worker are handled at almost same time, can one be > > skipped? > > To my knowledge, there's only one instance of the worker. Re-scheduling > the worker before a previous instance started, will not create a second > instance. The worker's instance will complete all pending updates. So in > some way, skipping workers already happens. So I think that the most often fbcon update from atomic context is the blinking cursor. If you disable that one you should be back to the old performance level I think, since just writing to dmesg is from process context, so shouldn't change. https://unix.stackexchange.com/questions/3759/how-to-stop-cursor-from-blinking Bunch of tricks, but tbh I haven't tested them. In any case, I still strongly advice you don't print anything to dmesg or fbcon while benchmarking, because dmesg/printf are anything but fast, especially if a gpu driver is involved. There's some efforts to make the dmesg/printk side less painful (untangling the console_lock from printk), but fundamentally printing to the gpu from the kernel through dmesg/fbcon won't be cheap. It's just not something we optimize beyond "make sure it works for emergencies". -Daniel > > Best regards > Thomas > > > > > Thanks, > > Feng > > > >> > >> Best regards > >> Thomas > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah > HRB 21284 (AG Nürnberg) > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
Hi, Dave, On 9/4/19 1:10 AM, Dave Hansen wrote: Thomas, this series has garnered a nak and a whole pile of thoroughly confused reviewers. Could you take another stab at this along with a more ample changelog explaining the context of the problem? I suspect that's a better place to start than having us all piece together the disparate parts of the thread. Sure. I was just trying to follow up on the emails to get a better understanding what got people confused in the first place. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: panel-lvds: Potential Oops in probe error handling
The "lvds->backlight" pointer could be NULl if of_parse_phandle()
returns NULL.
Fixes: 7c9dff5bd643 ("drm: panels: Add LVDS panel driver")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/panel/panel-lvds.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lvds.c
b/drivers/gpu/drm/panel/panel-lvds.c
index ad47cc95459e..3b4eb959e994 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -272,7 +272,8 @@ static int panel_lvds_probe(struct platform_device *pdev)
return 0;
error:
- put_device(>backlight->dev);
+ if (lvds->backlight)
+ put_device(>backlight->dev);
return ret;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
On Wed, Sep 04, 2019 at 05:45:20PM +0800, Cheng-yi Chiang wrote:
> On Wed, Sep 4, 2019 at 5:28 PM Neil Armstrong wrote:
> >
> > Hi,
> >
> > On 04/09/2019 11:09, Cheng-yi Chiang wrote:
> > > Hi,
> > >
> > > On Tue, Sep 3, 2019 at 5:53 PM Neil Armstrong
> > > wrote:
> > >>
> > >> Hi,
> > >>
> > >> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> > >>> From: Yakir Yang
> > >>>
> > >>> When transmitting IEC60985 linear PCM audio, we configure the
> > >>> Audio 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)
> > >>>
> > >>> Signed-off-by: Yakir Yang
> > >>> Signed-off-by: Cheng-Yi Chiang
> > >>> ---
> > >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++
> > >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20
> > >>> 2 files changed, 79 insertions(+)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >>> index bd65d0479683..34d46e25d610 100644
> > >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > >>> @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int
> > >>> freq, unsigned long pixel_clk)
> > >>> return n;
> > >>> }
> > >>>
> > >>> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
> > >>> +{
> > >>> + u8 aud_schnl_samplerate;
> > >>> + u8 aud_schnl_8;
> > >>> +
> > >>> + /* These registers are on RK3288 using version 2.0a. */
> > >>> + if (hdmi->version != 0x200a)
> > >>> + return;
> > >>
> > >> Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
> > >> SoCs ?
> > >>
> > >
> > > In the original patch by Yakir,
> > >
> > > https://lore.kernel.org/patchwork/patch/539653/ (sorry, I should
> > > have added this link in the "after the cut" note)
> > >
> > > The fix is limited to version 2.0.
> > > Since I am only testing on RK3288 with 2.0a, I change the check to 2.0a
> > > only.
> > > I can not test 2.0a version on other SoCs.
> > > The databook I have at hand is 2.0a (not specific to RK3288) so I
> > > think all 2.0a should have this register.
> > >
> > > As for other version like version 1.3 on iMX6, there is no such
> > > register, as stated by Russell
> > >
> > > http://lkml.iu.edu/hypermail/linux/kernel/1501.3/06268.html.
> >
> > Russell assumes the registers are not present on the iMX6 IP not having
> > the I2S registers, but they are present on the IPs configured with I2S
> > at any versions.
>
> I see. Thanks for the check.
>
> >
> > My databook version (1.40.a) specifies :
> >
> > fc_audschnls0 to fc_audschnls8
> >
> > ```
> > When transmitting IEC60958 linear PCM audio, this 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).
> > ```
> >
> > But the databook Revision History shows these registers were present since
> > version 1.10a.
> >
> > I propose you remove the version check, but you only setup these registers
> > when I2S is enabled:
> > (hdmi_readb(hdmi, HDMI_CONFIG0_ID) & HDMI_CONFIG0_I2S) until a AHBAUDDMA
> > user needs this,
> > with a small comment explaining the situation.
>
> I see. Sound like a good plan.
> In sum, I will add
> set_channel_status()
> in dw_hdmi.c
> And in the beginning of this function,
> check it is using I2S
> (hdmi_readb(hdmi, HDMI_CONFIG0_ID) & HDMI_CONFIG0_I2S)
> with a comment explaining the situation.
>
> And let dw-hdmi-audio-i2s dw_hdmi_i2s_hw_params() to call this
> function after dw_hdmi_set_sample_rate, with word length (or
> sample_bit) passed it as argument.
If you're going to do it this way, there's little point having the
check. The dw-hdmi-audio-i2s device will only be created if that
ID bit is already set. So, provided set_channel_status() (which
should probably be dw_hdmi_set_channel_status()) is only called from
the I2S driver, then everything should be fine without such a check.
However, it is worth noting in the docbook comments above the function
that it is only for I2S setups.
> I have not tested setting this register here as in the original patch
> it was set in hdmi_set_clk_regenerator.
> I will test it and update in my v2.
>
> Thanks again to everyone for the prompt reply and help.
>
> >
> > Neil
> >
> > >
> > > So at least we should check the version.
> > > Maybe we can set the criteria as version 2.0 or above to make it a safe
> > > patch ?
> > > If there is the same need on other SoC with version < 2.0, it can be
> > >
Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
Am 04.09.19 um 10:19 schrieb Thomas Hellström (VMware): > Hi, Christian, > > On 9/4/19 9:33 AM, Koenig, Christian wrote: >> Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware): >>> On 9/3/19 10:51 PM, Dave Hansen wrote: On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote: > So the question here should really be, can we determine already at > mmap > time whether backing memory will be unencrypted and adjust the *real* > vma->vm_page_prot under the mmap_sem? > > Possibly, but that requires populating the buffer with memory at mmap > time rather than at first fault time. I'm not connecting the dots. vma->vm_page_prot is used to create a VMA's PTEs regardless of if they are created at mmap() or fault time. If we establish a good vma->vm_page_prot, can't we just use it forever for demand faults? >>> With SEV I think that we could possibly establish the encryption flags >>> at vma creation time. But thinking of it, it would actually break with >>> SME where buffer content can be moved between encrypted system memory >>> and unencrypted graphics card PCI memory behind user-space's back. >>> That would imply killing all user-space encrypted PTEs and at fault >>> time set up new ones pointing to unencrypted PCI memory.. >> Well my problem is where do you see encrypted system memory here? >> >> At least for AMD GPUs all memory accessed must be unencrypted and that >> counts for both system as well as PCI memory. > > We're talking SME now right? > > The current SME setup is that if a device's DMA mask says it's capable > of addressing the encryption bit, coherent memory will be encrypted. > The memory controllers will decrypt for the device on the fly. > Otherwise coherent memory will be decrypted. > >> >> So I don't get why we can't assume always unencrypted and keep it >> like that. > > I see two reasons. First, it would break with a real device that > signals it's capable of addressing the encryption bit. Why? Because we don't use dma_mmap_coherent()? I've already talked with Christoph that we probably want to switch TTM over to using that instead to also get rid of the ttm_io_prot() hack. Regards, Christian. > > Second I can imagine unaccelerated setups (something like vkms using > prime feeding a VNC connection) where we actually want the TTM buffers > encrypted to protect data. > > But at least the latter reason is way far out in the future. > > So for me I'm ok with that if that works for you? > > /Thomas > > >> >> Regards, >> Christian. > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
On 9/4/19 1:15 AM, Andy Lutomirski wrote: On Sep 3, 2019, at 3:15 PM, Thomas Hellström (VMware) wrote: On 9/4/19 12:08 AM, Thomas Hellström (VMware) wrote: On 9/3/19 11:46 PM, Andy Lutomirski wrote: On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware) wrote: On 9/3/19 10:51 PM, Dave Hansen wrote: On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote: So the question here should really be, can we determine already at mmap time whether backing memory will be unencrypted and adjust the *real* vma->vm_page_prot under the mmap_sem? Possibly, but that requires populating the buffer with memory at mmap time rather than at first fault time. I'm not connecting the dots. vma->vm_page_prot is used to create a VMA's PTEs regardless of if they are created at mmap() or fault time. If we establish a good vma->vm_page_prot, can't we just use it forever for demand faults? With SEV I think that we could possibly establish the encryption flags at vma creation time. But thinking of it, it would actually break with SME where buffer content can be moved between encrypted system memory and unencrypted graphics card PCI memory behind user-space's back. That would imply killing all user-space encrypted PTEs and at fault time set up new ones pointing to unencrypted PCI memory.. Or, are you concerned that if an attempt is made to demand-fault page that's incompatible with vma->vm_page_prot that we have to SEGV? And it still requires knowledge whether the device DMA is always unencrypted (or if SEV is active). I may be getting mixed up on MKTME (the Intel memory encryption) and SEV. Is SEV supported on all memory types? Page cache, hugetlbfs, anonymous? Or just anonymous? SEV AFAIK encrypts *all* memory except DMA memory. To do that it uses a SWIOTLB backed by unencrypted memory, and it also flips coherent DMA memory to unencrypted (which is a very slow operation and patch 4 deals with caching such memory). I'm still lost. You have some fancy VMA where the backing pages change behind the application's back. This isn't particularly novel -- plain old anonymous memory and plain old mapped files do this too. Can't you all the insert_pfn APIs and call it a day? What's so special that you need all this magic? ISTM you should be able to allocate memory that's addressable by the device (dma_alloc_coherent() or whatever) and then map it into user memory just like you'd map any other page. I feel like I'm missing something here. Yes, so in this case we use dma_alloc_coherent(). With SEV, that gives us unencrypted pages. (Pages whose linear kernel map is marked unencrypted). With SME that (typcially) gives us encrypted pages. In both these cases, vm_get_page_prot() returns an encrypted page protection, which lands in vma->vm_page_prot. In the SEV case, we therefore need to modify the page protection to unencrypted. Hence we need to know whether we're running under SEV and therefore need to modify the protection. If not, the user-space PTE would incorrectly have the encryption flag set. I’m still confused. You got unencrypted pages with an unencrypted PFN. Why do you need to fiddle? You have a PFN, and you’re inserting it with vmf_insert_pfn(). This should just work, no? OK now I see what causes the confusion. With SEV, the encryption state is, while *physically* encoded in an address bit, from what I can tell, not *logically* encoded in the pfn, but in the page_prot for cpu mapping purposes. That is, page_to_pfn() returns the same pfn whether the page is encrypted or unencrypted. Hence nobody can't tell from the pfn whether the page is unencrypted or encrypted. For device DMA address purposes, the encryption status is encoded in the dma address by the dma layer in phys_to_dma(). There doesn’t seem to be any real funny business in dma_mmap_attrs() or dma_common_mmap(). No, from what I can tell the call in these functions to dma_pgprot() generates an incorrect page protection since it doesn't take unencrypted coherent memory into account. I don't think anybody has used these functions yet with SEV. But, reading this, I have more questions: Can’t you get rid of cvma by using vmf_insert_pfn_prot()? It looks like that, although there are comments in the code about serious performance problems using VM_PFNMAP / vmf_insert_pfn() with write-combining and PAT, so that would require some serious testing with hardware I don't have. But I guess there is definitely room for improvement here. Ideally we'd like to be able to change the vma->vm_page_prot within fault(). But we can Would it make sense to add a vmf_insert_dma_page() to directly do exactly what you’re trying to do? Yes, but as a longer term solution I would prefer a general dma_pgprot() exported, so that we could, in a dma-compliant way, use coherent pages with other apis, like kmap_atomic_prot() and vmap(). That is, basically split coherent page allocation in two steps: Allocation and mapping. And
Re: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
Hi Am 04.09.19 um 10:35 schrieb Feng Tang: > Hi Daniel, > > On Wed, Sep 04, 2019 at 10:11:11AM +0200, Daniel Vetter wrote: >> On Wed, Sep 4, 2019 at 8:53 AM Thomas Zimmermann wrote: >>> >>> Hi >>> >>> Am 04.09.19 um 08:27 schrieb Feng Tang: > Thank you for testing. But don't get too excited, because the patch > simulates a bug that was present in the original mgag200 code. A > significant number of frames are simply skipped. That is apparently the > reason why it's faster. Thanks for the detailed info, so the original code skips time-consuming work inside atomic context on purpose. Is there any space to optmise it? If 2 scheduled update worker are handled at almost same time, can one be skipped? >>> >>> To my knowledge, there's only one instance of the worker. Re-scheduling >>> the worker before a previous instance started, will not create a second >>> instance. The worker's instance will complete all pending updates. So in >>> some way, skipping workers already happens. >> >> So I think that the most often fbcon update from atomic context is the >> blinking cursor. If you disable that one you should be back to the old >> performance level I think, since just writing to dmesg is from process >> context, so shouldn't change. > > Hmm, then for the old driver, it should also do the most update in > non-atomic context? > > One other thing is, I profiled that updating a 3MB shadow buffer needs > 20 ms, which transfer to 150 MB/s bandwidth. Could it be related with > the cache setting of DRM shadow buffer? say the orginal code use a > cachable buffer? > > >> >> https://unix.stackexchange.com/questions/3759/how-to-stop-cursor-from-blinking >> >> Bunch of tricks, but tbh I haven't tested them. > > Thomas has suggested to disable curson by > echo 0 > /sys/devices/virtual/graphics/fbcon/cursor_blink > > We tried that way, and no change for the performance data. There are several ways of disabling the cursor. On my test system, I entered tput civis before the test and got better performance. Did you try this as well? Best regards Thomas > > Thanks, > Feng > >> >> In any case, I still strongly advice you don't print anything to dmesg >> or fbcon while benchmarking, because dmesg/printf are anything but >> fast, especially if a gpu driver is involved. There's some efforts to >> make the dmesg/printk side less painful (untangling the console_lock >> from printk), but fundamentally printing to the gpu from the kernel >> through dmesg/fbcon won't be cheap. It's just not something we >> optimize beyond "make sure it works for emergencies". >> -Daniel >> >>> >>> Best regards >>> Thomas >>> Thanks, Feng > > Best regards > Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >>> -- >>> Thomas Zimmermann >>> Graphics Driver Developer >>> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany >>> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah >>> HRB 21284 (AG Nürnberg) >>> >>> ___ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 0/3] Send a hotplug when edid changes
On Wed, Sep 04, 2019 at 08:36:46AM +, Lisovskiy, Stanislav wrote: > On Tue, 2019-09-03 at 17:49 +0200, Daniel Vetter wrote: > > On Tue, Sep 03, 2019 at 11:49:23AM +, Lisovskiy, Stanislav wrote: > > > On Tue, 2019-09-03 at 11:40 +0200, Daniel Vetter wrote: > > > > > > > > > > In fact I was wrong - when it worked, it was using exactly > > > > > > those > > > > > > patches :). With clean drm-tip - it seems to work > > > > > > ocassionally > > > > > > and it > > > > > > doesn't update the actual display edid and other stuff, so > > > > > > even > > > > > > when > > > > > > displays are changed we still see the old info/edid from > > > > > > userspace. > > > > > > > > > > > > We always get a hpd irq when suspend/resume however it > > > > > > doesn't > > > > > > always > > > > > > result in uevent being sent. So there is a real need in those > > > > > > patches. > > > > > > > > > > > > > > > > Just decided to "ping" this discussion again. The issue is > > > > > already > > > > > some > > > > > years old and still nothing is fixed. I do agree that may be > > > > > something > > > > > needs to be fixed/changed here in those patches, but something > > > > > must > > > > > be > > > > > agreed at least I guess, as discussions themself do not fix > > > > > bugs. > > > > > Currently those patches address a particular issue which > > > > > occurs, if > > > > > display is changed during suspend. > > > > > On ocassional basis, userspace might not get a hotplug event at > > > > > all, > > > > > causing different kind of problems(like wrong mode set on > > > > > display > > > > > or > > > > > diaply not working at all). Also some kms_chamelium hotplug > > > > > tests > > > > > fail > > > > > because of that. > > > > > > > > I still think we'll long-term regret this if we just duct-tape > > > > more > > > > stuff > > > > on top, instead of giving userspace a more informative uevent. > > > > This > > > > will > > > > send more uevents to userspace, so maybe then userspace tries to > > > > filter > > > > more and be clever, which never works, and we're back to tears. > > > > > > But here we actually do need a uevent as currently we don't get any > > > at > > > all, if edid changes during suspend. If userspace will try to > > > filter > > > this out - it's just stupid, however we still need to do things > > > correctly. > > > > > > > > > > > Anyway, on the approach itself: It's extremely i915 specific, and > > > > it > > > > requires that all drivers roll out drm_edid_equal checks and not > > > > forget to > > > > increment the epoch counter. > > > > > > > > What I had in mind is that when we set the edid for a connector > > > > with > > > > drm_connector_update_edid_property() or whatever, then the epoch > > > > counter > > > > would auto-increment if anything has changed. Similarly (long- > > > > term > > > > idea at > > > > least) if anything important with DP registers has changed. > > > > > > > > Can't we do that, instead of this sub-optimal solution of > > > > requiring > > > > all > > > > drivers to roll out lots of code? > > > > > > 1) We update edid in intel_dp_set_edid, which is called from > > > intel_dp_detect(drm_connector_helper_funcs->detect_ctx hook) which > > > is > > > called from drm_helper_probe_detect. That one is called either from > > > specific intel_encoder->hotplug hook in i915_hotplug_work_func or > > > by > > > userspace request during reprobe. > > > > > > 2) Previously we were simply updating edid in intel_dp_set_edid > > > without > > > caring if it is the same or not and hotplug event was sent only > > > once > > > connection_status had changed. > > > > > > 3) drm_connector_update_edid_property is called from connector- > > > > get_modes hook(lets say intel_dp_get_modes fo dp) however it > > > > simply > > > > > > uses results of > > > drm_helper_probe_detect so without actual comparison it would not > > > be > > > able to detect if we really need to update epoch_counter or not. > > > > > > Because as I said currently intel_dp_set_edid simply assigns it > > > without > > > checking, so that way you will get epoch_counter updated every > > > time, > > > i.e exactly what you wanted to avoid here. > > > > > > So we really need someway to determine if edid had changed, instead > > > of > > > simply assigning it all the time - that is why I had to make this > > > function. > > > > update_edid is the thing which changes the userspace visible edid. We > > can > > check there with the previous userspace visible edid, and if it's > > different, increase the epoch counter. If we never call update_edid > > then > > userspace won't see the changed edid (it might see the changed mode > > list > > or whatever), so doing that is pretty much a requirement for > > correctness. > > > > The higher levels should notice the epoch counter change (you might > > not > > have captured all of them, there's a bunch between ioctl, poll worker > > and > > sysfs iirc), and send out the uevent. > >
Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
On Wed, Sep 4, 2019 at 5:28 PM Neil Armstrong wrote:
>
> Hi,
>
> On 04/09/2019 11:09, Cheng-yi Chiang wrote:
> > Hi,
> >
> > On Tue, Sep 3, 2019 at 5:53 PM Neil Armstrong
> > wrote:
> >>
> >> Hi,
> >>
> >> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
> >>> From: Yakir Yang
> >>>
> >>> When transmitting IEC60985 linear PCM audio, we configure the
> >>> Audio 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)
> >>>
> >>> Signed-off-by: Yakir Yang
> >>> Signed-off-by: Cheng-Yi Chiang
> >>> ---
> >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++
> >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20
> >>> 2 files changed, 79 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> index bd65d0479683..34d46e25d610 100644
> >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >>> @@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int
> >>> freq, unsigned long pixel_clk)
> >>> return n;
> >>> }
> >>>
> >>> +static void hdmi_set_schnl(struct dw_hdmi *hdmi)
> >>> +{
> >>> + u8 aud_schnl_samplerate;
> >>> + u8 aud_schnl_8;
> >>> +
> >>> + /* These registers are on RK3288 using version 2.0a. */
> >>> + if (hdmi->version != 0x200a)
> >>> + return;
> >>
> >> Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
> >> SoCs ?
> >>
> >
> > In the original patch by Yakir,
> >
> > https://lore.kernel.org/patchwork/patch/539653/ (sorry, I should
> > have added this link in the "after the cut" note)
> >
> > The fix is limited to version 2.0.
> > Since I am only testing on RK3288 with 2.0a, I change the check to 2.0a
> > only.
> > I can not test 2.0a version on other SoCs.
> > The databook I have at hand is 2.0a (not specific to RK3288) so I
> > think all 2.0a should have this register.
> >
> > As for other version like version 1.3 on iMX6, there is no such
> > register, as stated by Russell
> >
> > http://lkml.iu.edu/hypermail/linux/kernel/1501.3/06268.html.
>
> Russell assumes the registers are not present on the iMX6 IP not having
> the I2S registers, but they are present on the IPs configured with I2S
> at any versions.
I see. Thanks for the check.
>
> My databook version (1.40.a) specifies :
>
> fc_audschnls0 to fc_audschnls8
>
> ```
> When transmitting IEC60958 linear PCM audio, this 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).
> ```
>
> But the databook Revision History shows these registers were present since
> version 1.10a.
>
> I propose you remove the version check, but you only setup these registers
> when I2S is enabled:
> (hdmi_readb(hdmi, HDMI_CONFIG0_ID) & HDMI_CONFIG0_I2S) until a AHBAUDDMA user
> needs this,
> with a small comment explaining the situation.
I see. Sound like a good plan.
In sum, I will add
set_channel_status()
in dw_hdmi.c
And in the beginning of this function,
check it is using I2S
(hdmi_readb(hdmi, HDMI_CONFIG0_ID) & HDMI_CONFIG0_I2S)
with a comment explaining the situation.
And let dw-hdmi-audio-i2s dw_hdmi_i2s_hw_params() to call this
function after dw_hdmi_set_sample_rate, with word length (or
sample_bit) passed it as argument.
I have not tested setting this register here as in the original patch
it was set in hdmi_set_clk_regenerator.
I will test it and update in my v2.
Thanks again to everyone for the prompt reply and help.
>
> Neil
>
> >
> > So at least we should check the version.
> > Maybe we can set the criteria as version 2.0 or above to make it a safe
> > patch ?
> > If there is the same need on other SoC with version < 2.0, it can be
> > added later.
> > Presumably, there will be databook of that version to help confirming
> > this setting.
> >
> > Thanks!
> >>> +
> >>> + 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 =
Re: [BACKPORT 4.14.y 1/8] drm/i915/fbdev: Actually configure untiled displays
On Tue, Sep 03, 2019 at 02:55:26PM +0800, Baolin Wang wrote:
> From: Chris Wilson
>
> If we skipped all the connectors that were not part of a tile, we would
> leave conn_seq=0 and conn_configured=0, convincing ourselves that we
> had stagnated in our configuration attempts. Avoid this situation by
> starting conn_seq=ALL_CONNECTORS, and repeating until we find no more
> connectors to configure.
>
> Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration on
> stagnation")
> Reported-by: Maarten Lankhorst
> Signed-off-by: Chris Wilson
> Cc: Maarten Lankhorst
> Reviewed-by: Maarten Lankhorst
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190215123019.32283-1-ch...@chris-wilson.co.uk
> Cc: # v3.19+
> Signed-off-by: Baolin Wang
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
What is the git commit id of this patch in Linus's tree?
Can you please add that as the first line of the changelog like is done
with all other stable patches? That way I can verify that what you
posted here is the correct one.
Please fix the up for all of these and resend.
thanks,
greg k-h
___
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 #24 from rol...@rptd.ch --- (In reply to Matt Turner from comment #23) > Can you make an apitrace of the application that demonstrates the problem? I can only try RenderDoc. But can you export an API trace with 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
[Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 --- Comment #25 from Matt Turner --- (In reply to rol...@rptd.ch from comment #24) > (In reply to Matt Turner from comment #23) > > Can you make an apitrace of the application that demonstrates the problem? > > I can only try RenderDoc. But can you export an API trace with it? A RenderDoc trace would probably be fine. Any way to reproduce it would be fine. -- 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 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #26 from Marko Popovic --- (In reply to Mathieu Belanger from comment #25) > I confirm that a system wide nongg do not fix random surprise crash I get on > filezilla and phpstorm. > > Switching to system wide nodma (that sound scary on the performance side) Yes but that unfortunately is exactly what "solved" the sdma0 freezes for me. Let's hope that a proper fix comes as soon as possible! -- 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 3/3] drm/atomic: Rename crtc_state->pageflip_flags to async_flip
On 2019-09-03 3:06 p.m., Daniel Vetter wrote: > It's the only flag anyone actually cares about. Plus if we're unlucky, > the atomic ioctl might need a different flag for async flips. So > better to abstract this away from the uapi a bit. > > Cc: Maarten Lankhorst > Cc: Michel Dänzer > Cc: Alex Deucher > Cc: Adam Jackson > Cc: Sean Paul > Cc: David Airlie > Signed-off-by: Daniel Vetter > Cc: Maxime Ripard > Cc: Daniel Vetter > Cc: Nicholas Kazlauskas > Cc: Leo Li > Cc: Harry Wentland > Cc: David Francis > Cc: Mario Kleiner > Cc: Bhawanpreet Lakha > Cc: Ben Skeggs > Cc: "Christian König" > Cc: Ilia Mirkin > Cc: Sam Ravnborg > Cc: Chris Wilson > --- Series is: Reviewed-by: Nicholas Kazlauskas I would like to see a new flag eventually show up for atomic as well, but the existing one is effectively broken at this point and I would hope that no userspace is setting it expecting that it actually does something. At this point we don't really gain anything from enabling atomic in DDX I think, most drivers already make use of DRM helpers to map these legacy IOCTLs to atomic anyway. Nicholas Kazlauskas > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++--- > drivers/gpu/drm/drm_atomic_helper.c | 2 +- > drivers/gpu/drm/drm_atomic_state_helper.c | 2 +- > drivers/gpu/drm/nouveau/dispnv50/wndw.c | 4 ++-- > include/drm/drm_crtc.h| 8 > 5 files changed, 10 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 0a71ed1e7762..2f0ef0820f00 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -5756,8 +5756,7 @@ static void amdgpu_dm_commit_planes(struct > drm_atomic_state *state, >* change FB pitch, DCC state, rotation or mirroing. >*/ > bundle->flip_addrs[planes_count].flip_immediate = > - (crtc->state->pageflip_flags & > - DRM_MODE_PAGE_FLIP_ASYNC) != 0 && > + crtc->state->async_flip && > acrtc_state->update_type == UPDATE_TYPE_FAST; > > timestamp_ns = ktime_get_ns(); > @@ -6334,7 +6333,7 @@ static void amdgpu_dm_atomic_commit_tail(struct > drm_atomic_state *state) > amdgpu_dm_enable_crtc_interrupts(dev, state, true); > > for_each_new_crtc_in_state(state, crtc, new_crtc_state, j) > - if (new_crtc_state->pageflip_flags & DRM_MODE_PAGE_FLIP_ASYNC) > + if (new_crtc_state->async_flip) > wait_for_vblank = false; > > /* update planes when needed per crtc*/ > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index e9c6112e7f73..1e5293eb66e3 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -3263,7 +3263,7 @@ static int page_flip_common(struct drm_atomic_state > *state, > return PTR_ERR(crtc_state); > > crtc_state->event = event; > - crtc_state->pageflip_flags = flags; > + crtc_state->async_flip = flags & DRM_MODE_PAGE_FLIP_ASYNC; > > plane_state = drm_atomic_get_plane_state(state, plane); > if (IS_ERR(plane_state)) > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c > b/drivers/gpu/drm/drm_atomic_state_helper.c > index 46dc264a248b..d0a937fb0c56 100644 > --- a/drivers/gpu/drm/drm_atomic_state_helper.c > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c > @@ -128,7 +128,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct > drm_crtc *crtc, > state->zpos_changed = false; > state->commit = NULL; > state->event = NULL; > - state->pageflip_flags = 0; > + state->async_flip = false; > > /* Self refresh should be canceled when a new update is available */ > state->active = drm_atomic_crtc_effectively_active(state); > diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c > b/drivers/gpu/drm/nouveau/dispnv50/wndw.c > index 2db029371c91..5193b6257061 100644 > --- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c > @@ -267,7 +267,7 @@ nv50_wndw_atomic_check_acquire(struct nv50_wndw *wndw, > bool modeset, > asyw->image.pitch[0] = fb->base.pitches[0]; > } > > - if (!(asyh->state.pageflip_flags & DRM_MODE_PAGE_FLIP_ASYNC)) > + if (!asyh->state.async_flip) > asyw->image.interval = 1; > else > asyw->image.interval = 0; > @@ -383,7 +383,7 @@ nv50_wndw_atomic_check_lut(struct nv50_wndw *wndw, > } > > /* Can't do an immediate flip while changing the LUT. */ > - asyh->state.pageflip_flags &= ~DRM_MODE_PAGE_FLIP_ASYNC; > + asyh->state.async_flip = false; > } > >
Re: DRM_MODE_CONNECTOR_PANEL? [Was: drm/panel: Add and fill drm_panel type field]
Hi Sam, On Sat, Aug 24, 2019 at 05:02:34PM +0300, Laurent Pinchart wrote: > On Sat, Aug 24, 2019 at 11:54:21AM +0200, Sam Ravnborg wrote: > > On Fri, Aug 23, 2019 at 10:32:44PM +0300, Laurent Pinchart wrote: > >> Add a type field to the drm_panel structure to report the panel type, > >> using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS, > >> eDP, DSI and DPI). This will be used to initialise the corresponding > >> connector type. > > > > As discussed on irc before applying this we should evaluate the > > idea to introduce DRM_MODE_CONNECTOR_PANEL > > Thank you for bringing it up. > > > Today we have: > > DRM_MODE_CONNECTOR_DPI > > DRM_MODE_CONNECTOR_DBI > > DRM_MODE_CONNECTOR_SPI > > DRM_MODE_CONNECTOR_LVDS > > > > The question if what benefit ig gives to distingush between the > > different ways panels are connected. > > > > For example for VGA and HDMI there is a physical connector involved so > > here it make good sense. > > But why should userspace care if the panel is connected via DPI or LVDS? > > > > The more generic DRM_MODE_CONNECTOR_PANEL would be equally descriptive. > > > > We will also start to see new drivers where there will be support > > for more than one type of connector interface. > > > > Like for example ili9322: > > - 8-bit serial RGB interface > > - 24-bit parallel RGB interface > > - 8-bit ITU-R BT.601 interface > > - 8-bit ITU-R BT.656 interface > > > > Adding DRM_MODE_CONNECTOR_PANEL may create an xkcd 927 situation. > > But we should then deprecate _DPI, _DBI, _SPI, _LVDS. > > _DBI doesn't exist, but we also have _eDP. > > The discussions originated from the fact that a number of drivers > incorrectly report their connector type for panels today (including > reporting DRM_MODE_CONNECTOR_Unknown), and they can't be fixed without a > risk or breaking userspace, especially as the connector type is also > used to name the connector (it would at least break command line mode > setting as reported by Nicolas Ferre). It also makes it difficult for a > driver to exhibit the right behaviour on new systems (that don't need to > care about backward compatibility) without breaking the already > supported systems. > > There were also recent discussions about adding a _DBI connector type, > which will increase this mess. I pointed out in a few IRC discussions > that I think the different connector types for panels were a mistake, > and that we should have gone for DRM_MODE_CONNECTOR_PANEL in the first > place. It's of course too late to fix this, but going forward, instead > of introducing a _DBI connector type, I think we'd be much better off > with _PANEL. Do you think it makes sense to merge this patch, regardless of the outcome of the DRM_MODE_CONNECTOR_PANEL panel discussion (which looks like a lack of discussion at the moment...) ? The patch allows exposing the correct panel type to userspace, without hindering in any way a future addition of DRM_MODE_CONNECTOR_PANEL. > >> Update all panel drivers accordingly. The panel-simple driver only > >> specifies the type for the known to be LVDS panels, while all other > >> panels are left as unknown and will be converted on a case-by-case > >> basis as they all need to be carefully reviewed. > >> > >> Signed-off-by: Laurent Pinchart > >> --- > >> Changes since v1: > >> > >> - Rename the type field to connector_type > >> - Pass the type to the drm_panel_init() function > >> - Keep connector type as unknown for non-LVDS panels in panel-simple > >> - Flag the toshiba_lt089ac29000 panel as LVDS as reported by Boris > >> --- > >> drivers/gpu/drm/drm_panel.c | 5 +++- > >> drivers/gpu/drm/panel/panel-arm-versatile.c | 3 ++- > >> .../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 ++- > >> drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 3 ++- > >> drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 3 ++- > >> drivers/gpu/drm/panel/panel-innolux-p079zca.c | 3 ++- > >> .../gpu/drm/panel/panel-jdi-lt070me05000.c| 3 ++- > >> .../drm/panel/panel-kingdisplay-kd097d04.c| 2 +- > >> drivers/gpu/drm/panel/panel-lg-lb035q02.c | 3 ++- > >> drivers/gpu/drm/panel/panel-lg-lg4573.c | 3 ++- > >> drivers/gpu/drm/panel/panel-lvds.c| 3 ++- > >> drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 3 ++- > >> drivers/gpu/drm/panel/panel-novatek-nt39016.c | 3 ++- > >> .../drm/panel/panel-olimex-lcd-olinuxino.c| 3 ++- > >> .../gpu/drm/panel/panel-orisetech-otm8009a.c | 3 ++- > >> .../drm/panel/panel-osd-osd101t2587-53ts.c| 2 +- > >> .../drm/panel/panel-panasonic-vvx10f034n00.c | 2 +- > >> .../drm/panel/panel-raspberrypi-touchscreen.c | 3 ++- > >> drivers/gpu/drm/panel/panel-raydium-rm67191.c | 3 ++- > >> drivers/gpu/drm/panel/panel-raydium-rm68200.c | 3 ++- > >> .../drm/panel/panel-rocktech-jh057n00900.c| 3 ++- > >> drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 3 ++- > >> drivers/gpu/drm/panel/panel-samsung-ld9040.c |
Re: [PATCH AUTOSEL 4.19 044/167] drm/amdgpu: validate user pitch alignment
On 2019-09-04 2:08 p.m., Sasha Levin wrote: > > FWIW, I've added another test to my scripts to try and catch these cases > (Revert "%s"). It'll slow down the scripts a bit but it's better to get > it right rather than to be done quickly :) Indeed, thanks! And again sorry for the brouhaha, I just honestly didn't realize before how tricky this case was for the scripts. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Use alpha value to blend values.
On Wed, Sep 04, 2019 at 08:27:07AM +0100, Sidong Yang wrote:
> On Mon, Sep 02, 2019 at 03:28:58PM +0300, Ville Syrjälä wrote:
> > On Sat, Aug 31, 2019 at 06:25:46PM +0100, Sidong Yang wrote:
> > > Use alpha value to blend source value and destination value Instead of
> > > just overwrite with source value.
> > >
> > > Signed-off-by: Sidong Yang
> > > ---
> > > drivers/gpu/drm/vkms/vkms_composer.c | 13 +++--
> > > 1 file changed, 11 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> > > b/drivers/gpu/drm/vkms/vkms_composer.c
> > > index d5585695c64d..b776185e5cb5 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > > @@ -75,6 +75,9 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> > > int y_limit = y_src + h_dst;
> > > int x_limit = x_src + w_dst;
> > >
> > > + u8 *src, *dst;
> > > + u32 alpha, inv_alpha;
> >
> > These could all live in a tighter scope.
>
> Hi, Ville.
>
> Thank you for reviewing my patch.
> I think that's good idea and I'll do that in next version.
> I found some patch in mailing list that is similar with this patch.
> So should I drop this patch and find other thing?
Probably best if you discuss that with whoever sent that other patch.
>
> Sidong.
>
> >
> > Apart from that lgtm
> > Reviewed-by: Ville Syrjälä
> >
> > > +
> > > for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
> > > for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
> > > offset_dst = dest_composer->offset
> > > @@ -84,8 +87,14 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> > >+ (i * src_composer->pitch)
> > >+ (j * src_composer->cpp);
> > >
> > > - memcpy(vaddr_dst + offset_dst,
> > > -vaddr_src + offset_src, sizeof(u32));
> > > + src = vaddr_src + offset_src;
> > > + dst = vaddr_dst + offset_dst;
> > > + alpha = src[3] + 1;
> > > + inv_alpha = 256 - src[3];
> > > + dst[0] = (alpha * src[0] + inv_alpha * dst[0]) >> 8;
> > > + dst[1] = (alpha * src[1] + inv_alpha * dst[1]) >> 8;
> > > + dst[2] = (alpha * src[2] + inv_alpha * dst[2]) >> 8;
> > > + dst[3] = 0xff;
> > > }
> > > i_dst++;
> > > }
> > > --
> > > 2.20.1
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204725] black screen
https://bugzilla.kernel.org/show_bug.cgi?id=204725 --- Comment #52 from Dmitri Seletski (drj...@gmail.com) --- Created attachment 284845 --> https://bugzilla.kernel.org/attachment.cgi?id=284845=edit dmesg 001 as per request, dmesg output -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: panel-lvds: Potential Oops in probe error handling
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
---
v2: Use backlight_put(). Thanks, Laurent!
drivers/gpu/drm/panel/panel-lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lvds.c
b/drivers/gpu/drm/panel/panel-lvds.c
index ad47cc95459e..05e8885db7ed 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -272,7 +272,7 @@ static int panel_lvds_probe(struct platform_device *pdev)
return 0;
error:
- put_device(>backlight->dev);
+ backlight_put(lvds->backlight);
return ret;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #28 from Pierre-Eric Pelloux-Prayer --- Regarding sdma ring hangs: if you still have access to the affected machine using ssh, it would be helpful to add a comment with the following information: - the last dmesg lines (at least the "[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout, signaled seq=9871, emitted seq=9873" one) - the output of : umr -R sdma0 (or sdma1 depending on which one failed) Thanks! -- 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: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500
On Thu, Aug 15, 2019 at 11:14:17AM +, Wen He wrote:
>
>
> > -Original Message-
> > From: Liviu Dudau
> > Sent: 2019年7月22日 17:33
> > To: Wen He
> > Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> > brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> >
> > Subject: Re: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS interface
> > configuration for Mali DP500
> >
> > Caution: EXT Email
> >
> > On Mon, Jul 22, 2019 at 02:12:08AM +, Wen He wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Liviu Dudau
> > > > Sent: 2019年7月19日 19:46
> > > > To: Wen He
> > > > Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org;
> > > > brian.star...@arm.com; airl...@linux.ie; dan...@ffwll.ch; Leo Li
> > > >
> > > > Subject: [EXT] Re: [v2 1/3] drm/arm/mali-dp: Add display QoS
> > > > interface configuration for Mali DP500
> > > >
> > > > Caution: EXT Email
> > > >
> > > > On Fri, Jul 19, 2019 at 05:54:45PM +0800, Wen He wrote:
> > > > > Configure the display Quality of service (QoS) levels priority if
> > > > > the optional property node "arm,malidp-aqros-value" is defined in DTS
> > file.
> > > > >
> > > > > QoS signaling using AQROS and AWQOS AXI interface signals, the
> > > > > AQROS is driven from the "RQOS" register, so needed to program the
> > > > > RQOS register to avoid the 4k resolution flicker issue on the LS1028A
> > platform.
> > > > >
> > > > > Signed-off-by: Wen He
> > > > > ---
> > > > > change in v2:
> > > > > - modify some content based on feedback from maintainers
> > > > >
> > > > > drivers/gpu/drm/arm/malidp_drv.c | 6 ++
> > > > > drivers/gpu/drm/arm/malidp_hw.c | 13 +
> > > > > drivers/gpu/drm/arm/malidp_hw.h | 3 +++
> > > > > drivers/gpu/drm/arm/malidp_regs.h | 10 ++
> > > > > 4 files changed, 32 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > > > > b/drivers/gpu/drm/arm/malidp_drv.c
> > > > > index f25ec4382277..61c49a0668a7 100644
> > > > > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > > > > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > > > > @@ -818,6 +818,12 @@ static int malidp_bind(struct device *dev)
> > > > >
> > > > > malidp->core_id = version;
> > > > >
> > > > > + ret = of_property_read_u32(dev->of_node,
> > > > > + "arm,malidp-arqos-value",
> > > > > + >arqos_value);
> > > > > + if (ret)
> > > > > + hwdev->arqos_value = 0x0;
> > > >
> > > > Is zero the default value that you want? I thought it was 0x00010001.
> > >
> > > Actually, the register default value always is 0x00010001(can be found in
> > > RM
> > document).
> >
> > Exactly, but with your code you are overwriting it to 0 if the DT doesn't
> > have
> > the arm,malidp-arqos-value property.
> >
> > >
> > > >
> > > > > +
> > > > > /* set the number of lines used for output of RGB data */
> > > > > ret = of_property_read_u8_array(dev->of_node,
> > > > >
> > > > > "arm,malidp-output-port-lines", diff --git
> > > > > a/drivers/gpu/drm/arm/malidp_hw.c
> > > > > b/drivers/gpu/drm/arm/malidp_hw.c index 50af399d7f6f..323683b1e9f7
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/arm/malidp_hw.c
> > > > > +++ b/drivers/gpu/drm/arm/malidp_hw.c
> > > > > @@ -374,6 +374,19 @@ static void malidp500_modeset(struct
> > > > malidp_hw_device *hwdev, struct videomode *
> > > > > malidp_hw_setbits(hwdev, MALIDP_DISP_FUNC_ILACED,
> > > > MALIDP_DE_DISPLAY_FUNC);
> > > > > else
> > > > > malidp_hw_clearbits(hwdev,
> > MALIDP_DISP_FUNC_ILACED,
> > > > > MALIDP_DE_DISPLAY_FUNC);
> > > > > +
> > > > > + /*
> > > > > + * Program the RQoS register to avoid 4k resolution flicker
> > > > > + * on the LS1028A.
> > > > > + */
> > > > > + if (hwdev->arqos_value) {
> > > > > + val = hwdev->arqos_value;
> > > > > +
> > > > > + if (mode->pixelclock == 59400)
> > > >
> > > > If I remember correctly, you declare the pixelclocks in the device
> > > > tree, so I wonder if this is needed here. We should just set what
> > > > value was in the DT regardless of the pixelclock, and then you
> > > > manipulate the DT to choose one of your fixed resolutions and also set
> > > > the
> > QoS value.
> > >
> > > Yes, you remember correctly, but
> > > 1. declare the pixelclocks in the device tree.
> > > About this, I was hoping to discuss it with you. I want to implement
> > > another patch that just declare 27MHz reference clock in the device
> > > tree and add a fake clock subsystem to enable/display prepare to set PLL.
> > > I
> > am thinking what to do next.
> > > As I remember, I sent out a patch that "Disable checking for required
> > > pixel clock", I think should be cancel it.
> > >
> > > 2. declare the fixed resolutions list in DTS.
> > > Yes, Although I put four resolutions for supported list in DTS file,
> > >
[Bug 111459] AMDg black screen
https://bugs.freedesktop.org/show_bug.cgi?id=111459 --- Comment #4 from peter m --- Thread with similar problem https://bugs.freedesktop.org/show_bug.cgi?id=109628 -- 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 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #14 from peter m --- Thread with similar problem https://bugs.freedesktop.org/show_bug.cgi?id=111459 -- 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: Adreno crash on i.MX53 running 5.3-rc6
On 04/09/2019 01:12, Rob Clark wrote:
On Tue, Sep 3, 2019 at 12:31 PM Fabio Estevam wrote:
Hi Jonathan,
On Tue, Sep 3, 2019 at 4:25 PM Jonathan Marek wrote:
Hi,
I tried this and it works with patches 4+5 from Rob's series and
changing gpummu to use sg_phys(sg) instead of sg->dma_address
(dma_address isn't set now that dma_map_sg isn't used).
Thanks for testing it. I haven't had a chance to test it yet.
Rob,
I assume your series is targeted to 5.4, correct?
maybe, although Christoph Hellwig didn't seem like a big fan of
exposing cache ops, and would rather add a new allocation API for
uncached pages.. so I'm not entirely sure what the way forward will
be.
TBH, the use of map/unmap looked reasonable in the context of
"start/stop using these pages for stuff which may include DMA", so even
if it was cheekily ignoring sg->dma_address I'm not sure I'd really
consider it "abuse" - in comparison, using sync without a prior map
unquestionably violates the API, and means that CONFIG_DMA_API_DEBUG
will be rendered useless with false positives if this driver is active
while trying to debug something else.
The warning referenced in 0036bc73ccbe represents something being
unmapped which didn't match a corresponding map - from what I can make
of get_pages()/put_pages() it looks like that would need msm_obj->flags
or msm_obj->sgt to change during the lifetime of the object, neither of
which sounds like a thing that should legitimately happen. Are you sure
this isn't all just hiding a subtle bug elsewhere? After all, if what
was being unmapped wasn't right, who says that what's now being synced is?
Robin.
In the mean time, it is a bit ugly, but I guess something like this should work:
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 7263f4373f07..5a6a79fbc9d6 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -52,7 +52,7 @@ static void sync_for_device(struct msm_gem_object *msm_obj)
{
struct device *dev = msm_obj->base.dev->dev;
-if (get_dma_ops(dev)) {
+if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
dma_sync_sg_for_device(dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
} else {
@@ -65,7 +65,7 @@ static void sync_for_cpu(struct msm_gem_object *msm_obj)
{
struct device *dev = msm_obj->base.dev->dev;
-if (get_dma_ops(dev)) {
+if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
dma_sync_sg_for_cpu(dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
} else {
BR,
-R
If this is the case, what we should do about the i.MX5 regression on 5.3?
Would a revert of the two commits be acceptable in 5.3 in order to
avoid the regression?
Please advise.
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 50/94] drm/amdgpu: fix dma_fence_wait without reference
From: Christian König
[ Upstream commit 42068e1ef961c719f967dbbb4ddcb394a0ba7917 ]
We need to grab a reference to the fence we wait for.
Signed-off-by: Christian König
Reviewed-by: Chunming Zhou
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 27 ++---
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index a28a3d722ba29..62298ae5c81c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -535,21 +535,24 @@ int amdgpu_ctx_wait_prev_fence(struct amdgpu_ctx *ctx,
struct drm_sched_entity *entity)
{
struct amdgpu_ctx_entity *centity = to_amdgpu_ctx_entity(entity);
- unsigned idx = centity->sequence & (amdgpu_sched_jobs - 1);
- struct dma_fence *other = centity->fences[idx];
+ struct dma_fence *other;
+ unsigned idx;
+ long r;
- if (other) {
- signed long r;
- r = dma_fence_wait(other, true);
- if (r < 0) {
- if (r != -ERESTARTSYS)
- DRM_ERROR("Error (%ld) waiting for fence!\n",
r);
+ spin_lock(>ring_lock);
+ idx = centity->sequence & (amdgpu_sched_jobs - 1);
+ other = dma_fence_get(centity->fences[idx]);
+ spin_unlock(>ring_lock);
- return r;
- }
- }
+ if (!other)
+ return 0;
- return 0;
+ r = dma_fence_wait(other, true);
+ if (r < 0 && r != -ERESTARTSYS)
+ DRM_ERROR("Error (%ld) waiting for fence!\n", r);
+
+ dma_fence_put(other);
+ return r;
}
void amdgpu_ctx_mgr_init(struct amdgpu_ctx_mgr *mgr)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 35/94] drm/omap: Fix port lookup for SDI output
From: Laurent Pinchart
[ Upstream commit 8090f7eb318d4241625449252db2741e7703e027 ]
When refactoring port lookup for DSS outputs, commit d17eb4537a7e
("drm/omap: Factor out common init/cleanup code for output devices")
incorrectly hardcoded usage of DT port 0. This breaks operation for SDI
(which uses the DT port 1) and DPI outputs other than DPI0 (which are
not used in mainline DT sources).
Fix this by using the port number from the output omap_dss_device
of_ports field.
Fixes: d17eb4537a7e ("drm/omap: Factor out common init/cleanup code for output
devices")
Signed-off-by: Laurent Pinchart
Signed-off-by: Tomi Valkeinen
Link:
https://patchwork.freedesktop.org/patch/msgid/20190821183226.13784-1-laurent.pinch...@ideasonboard.com
Tested-by: Aaro Koskinen
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/omapdrm/dss/output.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/output.c
b/drivers/gpu/drm/omapdrm/dss/output.c
index de0f882f0f7b0..14b41de44ebcd 100644
--- a/drivers/gpu/drm/omapdrm/dss/output.c
+++ b/drivers/gpu/drm/omapdrm/dss/output.c
@@ -4,6 +4,7 @@
* Author: Archit Taneja
*/
+#include
#include
#include
#include
@@ -20,7 +21,8 @@ int omapdss_device_init_output(struct omap_dss_device *out)
{
struct device_node *remote_node;
- remote_node = of_graph_get_remote_node(out->dev->of_node, 0, 0);
+ remote_node = of_graph_get_remote_node(out->dev->of_node,
+ ffs(out->of_ports) - 1, 0);
if (!remote_node) {
dev_dbg(out->dev, "failed to find video sink\n");
return 0;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.2 36/94] drm/virtio: use virtio_max_dma_size
From: Gerd Hoffmann [ Upstream commit 9b2a0a1ef66f96bf34921a3865581eca32ff05ec ] We must make sure our scatterlist segments are not too big, otherwise we might see swiotlb failures (happens with sev, also reproducable with swiotlb=force). Suggested-by: Laszlo Ersek Signed-off-by: Gerd Hoffmann Reviewed-by: Laszlo Ersek Link: http://patchwork.freedesktop.org/patch/msgid/2019082210.27165-1-kra...@redhat.com Signed-off-by: Sasha Levin --- drivers/gpu/drm/virtio/virtgpu_object.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index b2da31310d24c..09b526518f5a6 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -204,6 +204,7 @@ int virtio_gpu_object_get_sg_table(struct virtio_gpu_device *qdev, .interruptible = false, .no_wait_gpu = false }; + size_t max_segment; /* wtf swapping */ if (bo->pages) @@ -215,8 +216,13 @@ int virtio_gpu_object_get_sg_table(struct virtio_gpu_device *qdev, if (!bo->pages) goto out; - ret = sg_alloc_table_from_pages(bo->pages, pages, nr_pages, 0, - nr_pages << PAGE_SHIFT, GFP_KERNEL); + max_segment = virtio_max_dma_size(qdev->vdev); + max_segment &= PAGE_MASK; + if (max_segment > SCATTERLIST_MAX_SEGMENT) + max_segment = SCATTERLIST_MAX_SEGMENT; + ret = __sg_alloc_table_from_pages(bo->pages, pages, nr_pages, 0, + nr_pages << PAGE_SHIFT, + max_segment, GFP_KERNEL); if (ret) goto out; return 0; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #15 from peter m --- (In reply to peter m from comment #14) > Thread with similar problem > > https://bugs.freedesktop.org/show_bug.cgi?id=111459 In my case, screen became black after entering password in welcome screen. -- 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 AUTOSEL 5.2 58/94] drm/amd/powerplay: correct Vega20 dpm level related settings
From: Evan Quan
[ Upstream commit 83e09d5bddbee749fc83063890244397896a1971 ]
Correct the settings for auto mode and skip the unnecessary
settings for dcefclk and fclk.
Signed-off-by: Evan Quan
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../drm/amd/powerplay/hwmgr/vega20_hwmgr.c| 60 +--
1 file changed, 54 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
index 9b9f87b84910c..d98fe481cd365 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
@@ -2288,12 +2288,16 @@ static int vega20_force_dpm_highest(struct pp_hwmgr
*hwmgr)
data->dpm_table.soc_table.dpm_state.soft_max_level =
data->dpm_table.soc_table.dpm_levels[soft_level].value;
- ret = vega20_upload_dpm_min_level(hwmgr, 0x);
+ ret = vega20_upload_dpm_min_level(hwmgr, FEATURE_DPM_GFXCLK_MASK |
+FEATURE_DPM_UCLK_MASK |
+FEATURE_DPM_SOCCLK_MASK);
PP_ASSERT_WITH_CODE(!ret,
"Failed to upload boot level to highest!",
return ret);
- ret = vega20_upload_dpm_max_level(hwmgr, 0x);
+ ret = vega20_upload_dpm_max_level(hwmgr, FEATURE_DPM_GFXCLK_MASK |
+FEATURE_DPM_UCLK_MASK |
+FEATURE_DPM_SOCCLK_MASK);
PP_ASSERT_WITH_CODE(!ret,
"Failed to upload dpm max level to highest!",
return ret);
@@ -2326,12 +2330,16 @@ static int vega20_force_dpm_lowest(struct pp_hwmgr
*hwmgr)
data->dpm_table.soc_table.dpm_state.soft_max_level =
data->dpm_table.soc_table.dpm_levels[soft_level].value;
- ret = vega20_upload_dpm_min_level(hwmgr, 0x);
+ ret = vega20_upload_dpm_min_level(hwmgr, FEATURE_DPM_GFXCLK_MASK |
+FEATURE_DPM_UCLK_MASK |
+FEATURE_DPM_SOCCLK_MASK);
PP_ASSERT_WITH_CODE(!ret,
"Failed to upload boot level to highest!",
return ret);
- ret = vega20_upload_dpm_max_level(hwmgr, 0x);
+ ret = vega20_upload_dpm_max_level(hwmgr, FEATURE_DPM_GFXCLK_MASK |
+FEATURE_DPM_UCLK_MASK |
+FEATURE_DPM_SOCCLK_MASK);
PP_ASSERT_WITH_CODE(!ret,
"Failed to upload dpm max level to highest!",
return ret);
@@ -2342,14 +2350,54 @@ static int vega20_force_dpm_lowest(struct pp_hwmgr
*hwmgr)
static int vega20_unforce_dpm_levels(struct pp_hwmgr *hwmgr)
{
+ struct vega20_hwmgr *data =
+ (struct vega20_hwmgr *)(hwmgr->backend);
+ uint32_t soft_min_level, soft_max_level;
int ret = 0;
- ret = vega20_upload_dpm_min_level(hwmgr, 0x);
+ /* gfxclk soft min/max settings */
+ soft_min_level =
+ vega20_find_lowest_dpm_level(&(data->dpm_table.gfx_table));
+ soft_max_level =
+ vega20_find_highest_dpm_level(&(data->dpm_table.gfx_table));
+
+ data->dpm_table.gfx_table.dpm_state.soft_min_level =
+ data->dpm_table.gfx_table.dpm_levels[soft_min_level].value;
+ data->dpm_table.gfx_table.dpm_state.soft_max_level =
+ data->dpm_table.gfx_table.dpm_levels[soft_max_level].value;
+
+ /* uclk soft min/max settings */
+ soft_min_level =
+ vega20_find_lowest_dpm_level(&(data->dpm_table.mem_table));
+ soft_max_level =
+ vega20_find_highest_dpm_level(&(data->dpm_table.mem_table));
+
+ data->dpm_table.mem_table.dpm_state.soft_min_level =
+ data->dpm_table.mem_table.dpm_levels[soft_min_level].value;
+ data->dpm_table.mem_table.dpm_state.soft_max_level =
+ data->dpm_table.mem_table.dpm_levels[soft_max_level].value;
+
+ /* socclk soft min/max settings */
+ soft_min_level =
+ vega20_find_lowest_dpm_level(&(data->dpm_table.soc_table));
+ soft_max_level =
+ vega20_find_highest_dpm_level(&(data->dpm_table.soc_table));
+
+ data->dpm_table.soc_table.dpm_state.soft_min_level =
+ data->dpm_table.soc_table.dpm_levels[soft_min_level].value;
+ data->dpm_table.soc_table.dpm_state.soft_max_level =
+ data->dpm_table.soc_table.dpm_levels[soft_max_level].value;
+
+ ret = vega20_upload_dpm_min_level(hwmgr, FEATURE_DPM_GFXCLK_MASK |
+FEATURE_DPM_UCLK_MASK |
+
[Bug 111459] AMDg black screen
https://bugs.freedesktop.org/show_bug.cgi?id=111459 --- Comment #3 from peter m --- Unfortunately I don't know how to apply this patch/patches. Updated to new kernel 5.2.11-200.fc30.x86_64, problem still exists. Sep 04 19:45:23 kernel: WARNING: CPU: 2 PID: 1014 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:854 dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu] Sep 04 19:45:23 kernel: Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 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 ip_tables sunrpc snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep snd_seq ccp snd_seq_device snd_pcm snd_timer kvm snd irqbypass joydev soundcore sp5100_tco i2c_piix4 crct10dif_pclmul wmi_bmof crc32_pclmul k10temp ghash_clmulni_intel pcc_cpufreq gpio_amdpt gpio_generic acpi_cpufreq amdgpu amd_iommu_v2 gpu_sched i2c_algo_bit ttm drm_kms_helper crc32c_intel drm r8169 wmi video pinctrl_amd Sep 04 19:45:23 kernel: CPU: 2 PID: 1014 Comm: InputThread Not tainted 5.2.11-200.fc30.x86_64 #1 Sep 04 19:45:23 kernel: Hardware name: Gigabyte Technology Co., Ltd. A320M-S2H V2/A320M-S2H V2-CF, BIOS F2 12/25/2018 Sep 04 19:45:23 kernel: RIP: 0010:dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu] Sep 04 19:45:23 kernel: Code: 83 c8 ff e9 85 af f9 ff 48 c7 c7 f8 20 78 c0 e8 e8 27 a6 f0 0f 0b 83 c8 ff e9 6f af f9 ff 48 c7 c7 f8 20 78 c0 e8 d2 27 a6 f0 <0f> 0b 80 bb 93 01 00 00 00 75 05 e9 c9 d3 f9 ff 48 8b 83 80 02 00 Sep 04 19:45:23 kernel: RSP: 0018:9ba201da3a00 EFLAGS: 00010246 Sep 04 19:45:23 kernel: RAX: 0024 RBX: 8a12ce72c000 RCX: 0006 Sep 04 19:45:23 kernel: RDX: RSI: 0082 RDI: 8a12d8a97900 Sep 04 19:45:23 kernel: RBP: 8a12ce72c000 R08: 0001 R09: 03f9 Sep 04 19:45:23 kernel: R10: b2bf03e0 R11: 0003 R12: 8a12caef81b8 Sep 04 19:45:23 kernel: R13: 8a12caef9bc8 R14: 8a12caef81b8 R15: 8a12b8420200 Sep 04 19:45:23 kernel: FS: 7fc4cec4b700() GS:8a12d8a8() knlGS: Sep 04 19:45:23 kernel: CS: 0010 DS: ES: CR0: 80050033 Sep 04 19:45:23 kernel: CR2: 7f19f6f298a0 CR3: 0001fb7e4000 CR4: 003406e0 Sep 04 19:45:23 kernel: Call Trace: Sep 04 19:45:23 kernel: dcn10_pipe_control_lock.part.0+0x69/0x70 [amdgpu] Sep 04 19:45:23 kernel: dc_stream_set_cursor_attributes+0x121/0x170 [amdgpu] Sep 04 19:45:23 kernel: handle_cursor_update.isra.0+0x1af/0x310 [amdgpu] Sep 04 19:45:23 kernel: drm_atomic_helper_async_commit+0x63/0xd0 [drm_kms_helper] Sep 04 19:45:23 kernel: drm_atomic_helper_commit+0xdb/0x110 [drm_kms_helper] Sep 04 19:45:23 kernel: drm_atomic_helper_update_plane+0xec/0x100 [drm_kms_helper] Sep 04 19:45:23 kernel: drm_mode_cursor_universal+0x12c/0x240 [drm] Sep 04 19:45:23 kernel: drm_mode_cursor_common+0xc9/0x220 [drm] Sep 04 19:45:23 kernel: ? drm_mode_setplane+0x2a0/0x2a0 [drm] Sep 04 19:45:23 kernel: drm_mode_cursor_ioctl+0x4d/0x70 [drm] Sep 04 19:45:23 kernel: drm_ioctl_kernel+0xaa/0xf0 [drm] Sep 04 19:45:23 kernel: drm_ioctl+0x208/0x390 [drm] Sep 04 19:45:23 kernel: ? drm_mode_setplane+0x2a0/0x2a0 [drm] Sep 04 19:45:23 kernel: amdgpu_drm_ioctl+0x49/0x80 [amdgpu] Sep 04 19:45:23 kernel: do_vfs_ioctl+0x405/0x660 Sep 04 19:45:23 kernel: ksys_ioctl+0x5e/0x90 Sep 04 19:45:23 kernel: ? ksys_read+0xc4/0xe0 Sep 04 19:45:23 kernel: __x64_sys_ioctl+0x16/0x20 Sep 04 19:45:23 kernel: do_syscall_64+0x5f/0x1a0 Sep 04 19:45:23 kernel: ? page_fault+0x8/0x30 Sep 04 19:45:23 kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Sep 04 19:45:23 kernel: RIP: 0033:0x7fc4f687e1fb Sep 04 19:45:23 kernel: Code: 0f 1e fa 48 8b 05 8d dc 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 5d dc 0c 00 f7 d8 64 89 01 48 Sep 04 19:45:23 kernel: RSP: 002b:7fc4cec492e8 EFLAGS: 3246 ORIG_RAX: 0010 Sep 04 19:45:23 kernel: RAX: ffda RBX: 7fc4cec49320 RCX: 7fc4f687e1fb Sep 04 19:45:23 kernel: RDX: 7fc4cec49320 RSI: c01c64a3 RDI: 0010 Sep 04 19:45:23 kernel: RBP: c01c64a3 R08: 0276 R09: 0001 Sep 04 19:45:23 kernel: R10: R11: 3246 R12: 5591448cec60 Sep 04 19:45:23 kernel: R13: 0010 R14: 027a R15: 0155 Sep 04 19:45:23 kernel: ---[ end trace 5a51309b874ce6f0 ]--- Sep 04 19:45:23 kernel: [drm] pstate TEST_DEBUG_DATA: 0x3FF6 Sep 04 19:45:23 kernel: [ cut here ] -- You are receiving this mail
[PATCH] drm/msm: Use the correct dma_sync calls harder
From: Rob Clark
Looks like the dma_sync calls don't do what we want on armv7 either.
Fixes:
Unable to handle kernel paging request at virtual address 50001000
pgd = (ptrval)
[50001000] *pgd=
Internal error: Oops: 805 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc6-00271-g9f159ae07f07 #4
Hardware name: Freescale i.MX53 (Device Tree Support)
PC is at v7_dma_clean_range+0x20/0x38
LR is at __dma_page_cpu_to_dev+0x28/0x90
pc : []lr : []psr: 2013
sp : d80b5a88 ip : de96c000 fp : d840ce6c
r10: r9 : 0001 r8 : d843e010
r7 : r6 : 8000 r5 : ddb6c000 r4 :
r3 : 003f r2 : 0040 r1 : 50008000 r0 : 50001000
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 70004019 DAC: 0051
Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
Signed-off-by: Rob Clark
Fixes: 3de433c5b38a ("drm/msm: Use the correct dma_sync calls in msm_gem")
Tested-by: Fabio Estevam
---
drivers/gpu/drm/msm/msm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 7263f4373f07..5a6a79fbc9d6 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -52,7 +52,7 @@ static void sync_for_device(struct msm_gem_object *msm_obj)
{
struct device *dev = msm_obj->base.dev->dev;
- if (get_dma_ops(dev)) {
+ if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
dma_sync_sg_for_device(dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
} else {
@@ -65,7 +65,7 @@ static void sync_for_cpu(struct msm_gem_object *msm_obj)
{
struct device *dev = msm_obj->base.dev->dev;
- if (get_dma_ops(dev)) {
+ if (get_dma_ops(dev) && IS_ENABLED(CONFIG_ARM64)) {
dma_sync_sg_for_cpu(dev, msm_obj->sgt->sgl,
msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
} else {
--
2.21.0
Re: [PATCH v2 1/4] x86/mm: Export force_dma_unencrypted
On 9/4/19 2:22 PM, Christoph Hellwig wrote: On Wed, Sep 04, 2019 at 09:32:30AM +0200, Thomas Hellström (VMware) wrote: That sounds great. Is there anything I can do to help out? I thought this was more or less a dead end since the current dma_mmap_ API requires the mmap_sem to be held in write mode (modifying the vma->vm_flags) whereas fault() only offers read mode. But that would definitely work. We'll just need to split into a setup and faul phase. I have some sketches from a while ago, let me dust them off so that you can try them. I'd be happy to. Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] ast, mgag200: Map console BO while it's being displayed
On Wed, Sep 4, 2019 at 7:14 PM Davidlohr Bueso wrote: > On Wed, 04 Sep 2019, Daniel Vetter wrote: > >I'm also not sure whether we have a real problem here, it's just debug > >noise that we're fighting here? > > It is non stop debug noise as the memory range in question is being added + > deleted over and over. I doubt we want to be burning cycles like this. Yeah the proper fix is setting up an io_mapping in ttm (or drivers) so the pat tracking is cached, and then using the right pte wrangling functions. But that's a lot more involved fix, and from all the testing we've done the pte rewriting itself doesn't seem to be the biggest issue with mgag200 being slow ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V4] drm: Add LTTPR defines for DP 1.4a
DP 1.4a specification defines Link Training Tunable PHY Repeater (LTTPR) which is required to add support for systems with Thunderbolt or other repeater devices. Changes since V3: - Replace spaces by tabs Changes since V2: - Drop the kernel-doc comment - Reorder LTTPR according to register offset Changes since V1: - Adjusts registers names to be aligned with spec and the rest of the file - Update spec comment from 1.4 to 1.4a Cc: Abdoulaye Berthe Cc: Harry Wentland Cc: Leo Li Cc: Jani Nikula Cc: Manasi Navare Cc: Ville Syrjälä Signed-off-by: Rodrigo Siqueira Signed-off-by: Abdoulaye Berthe Reviewed-by: Harry Wentland --- include/drm/drm_dp_helper.h | 25 + 1 file changed, 25 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 8364502f92cf..5abed96a1cb1 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -966,6 +966,31 @@ #define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET 0x69494 #define DP_HDCP_2_2_REG_DBG_OFFSET 0x69518 +/* Link Training (LT)-tunable Physical Repeaters - DP 1.4a */ +#define DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV0xf +#define DP_MAX_LINK_RATE_PHY_REPEATER 0xf0001 +#define DP_PHY_REPEATER_CNT0xf0002 +#define DP_PHY_REPEATER_MODE 0xf0003 +#define DP_MAX_LANE_COUNT_PHY_REPEATER 0xf0004 +#define DP_PHY_REPEATER_EXTENDED_WAIT_TIMEOUT 0xf0005 +#define DP_TRAINING_PATTERN_SET_PHY_REPEATER1 0xf0010 +#define DP_TRAINING_LANE0_SET_PHY_REPEATER10xf0011 +#define DP_TRAINING_LANE1_SET_PHY_REPEATER10xf0012 +#define DP_TRAINING_LANE2_SET_PHY_REPEATER10xf0013 +#define DP_TRAINING_LANE3_SET_PHY_REPEATER10xf0014 +#define DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1 0xf0020 +#define DP_TRANSMITTER_CAPABILITY_PHY_REPEATER10xf0021 +#define DP_LANE0_1_STATUS_PHY_REPEATER10xf0030 +#define DP_LANE2_3_STATUS_PHY_REPEATER10xf0031 +#define DP_LANE_ALIGN_STATUS_UPDATED_PHY_REPEATER1 0xf0032 +#define DP_ADJUST_REQUEST_LANE0_1_PHY_REPEATER10xf0033 +#define DP_ADJUST_REQUEST_LANE2_3_PHY_REPEATER10xf0034 +#define DP_SYMBOL_ERROR_COUNT_LANE0_PHY_REPEATER1 0xf0035 +#define DP_SYMBOL_ERROR_COUNT_LANE1_PHY_REPEATER1 0xf0037 +#define DP_SYMBOL_ERROR_COUNT_LANE2_PHY_REPEATER1 0xf0039 +#define DP_SYMBOL_ERROR_COUNT_LANE3_PHY_REPEATER1 0xf003b +#define DP_FEC_STATUS_PHY_REPEATER10xf0290 + /* DP HDCP message start offsets in DPCD address space */ #define DP_HDCP_2_2_AKE_INIT_OFFSETDP_HDCP_2_2_REG_RTX_OFFSET #define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET DP_HDCP_2_2_REG_CERT_RX_OFFSET -- 2.23.0 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: potential regression in drm/mgag200
Hi Am 04.09.19 um 08:49 schrieb Davidlohr Bueso: > Hi, > > While doing some changes to x86's pat code and thus having 'debugpat', I > noticed > some weird behavior in a server running linux-next as of -- yes, > reverting does 'fix' > the issue: > > 90f479ae51a (drm/mgag200: Replace struct mga_fbdev with generic > framebuffer emulation) > > Where the following splat is seen over and over endlessly for the same > range: > > x86/PAT: Overlap at 0xd000-0xd100 > x86/PAT: reserve_memtype added [mem 0xd000-0xd02f], track > write-combining, req write-combining, ret write-combining > x86/PAT: free_memtype request [mem 0xd000-0xd02f] > > And all these are doing ioremap from drm_fb_helper_dirty_work(): > > [ 114.330825] reserve_memtype+0x1b0/0x410 > [ 114.330829] ? ttm_bo_kmap+0x1d7/0x270 [ttm] > [ 114.330830] __ioremap_caller.constprop.14+0xf6/0x300 > [ 114.330832] ? soft_cursor+0x1f9/0x220 > [ 114.330835] ttm_bo_kmap+0x1d7/0x270 [ttm] > [ 114.330838] ? ttm_bo_del_sub_from_lru+0x29/0x40 [ttm] > [ 114.330841] drm_gem_vram_kmap+0x54/0x70 [drm_vram_helper] > [ 114.330842] drm_gem_vram_object_vmap+0x23/0x40 [drm_vram_helper] > [ 114.330853] drm_gem_vmap+0x1f/0x60 [drm] > [ 114.477697] drm_client_buffer_vmap+0x1d/0x30 [drm] > [ 114.477703] drm_fb_helper_dirty_work+0x92/0x180 [drm_kms_helper] > [ 114.477706] process_one_work+0x1f4/0x3e0 > [ 114.477707] worker_thread+0x2d/0x3e0 > > Before, the same range was also added, but only once, and fwiw it was > the same either > with 24 or 32 bpp. > > Any thoughts? Thanks for reporting. The original code kept around memory mappings for a longer time, while the new code remapped frequently. I've just submitted a patch set that restores the old behavior. [1] Fixes the problem on my test machine. Best regards Thomas [1] https://patchwork.freedesktop.org/series/66210/ > > Thanks, > Davidlohr -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
On 9/4/19 1:10 PM, Koenig, Christian wrote: Am 04.09.19 um 10:19 schrieb Thomas Hellström (VMware): Hi, Christian, On 9/4/19 9:33 AM, Koenig, Christian wrote: Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware): On 9/3/19 10:51 PM, Dave Hansen wrote: On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote: So the question here should really be, can we determine already at mmap time whether backing memory will be unencrypted and adjust the *real* vma->vm_page_prot under the mmap_sem? Possibly, but that requires populating the buffer with memory at mmap time rather than at first fault time. I'm not connecting the dots. vma->vm_page_prot is used to create a VMA's PTEs regardless of if they are created at mmap() or fault time. If we establish a good vma->vm_page_prot, can't we just use it forever for demand faults? With SEV I think that we could possibly establish the encryption flags at vma creation time. But thinking of it, it would actually break with SME where buffer content can be moved between encrypted system memory and unencrypted graphics card PCI memory behind user-space's back. That would imply killing all user-space encrypted PTEs and at fault time set up new ones pointing to unencrypted PCI memory.. Well my problem is where do you see encrypted system memory here? At least for AMD GPUs all memory accessed must be unencrypted and that counts for both system as well as PCI memory. We're talking SME now right? The current SME setup is that if a device's DMA mask says it's capable of addressing the encryption bit, coherent memory will be encrypted. The memory controllers will decrypt for the device on the fly. Otherwise coherent memory will be decrypted. So I don't get why we can't assume always unencrypted and keep it like that. I see two reasons. First, it would break with a real device that signals it's capable of addressing the encryption bit. Why? Because we don't use dma_mmap_coherent()? Well, assuming always unencrypted would obviously break on a real device with encrypted coherent memory? dma_mmap_coherent() would work from the encryption point of view (although I think it's currently buggy and will send out an RFC for what I believe is a fix for that). I've already talked with Christoph that we probably want to switch TTM over to using that instead to also get rid of the ttm_io_prot() hack. OK, would that mean us ditching other memory modes completely? And on-the-fly caching transitions? or is it just for the special case of cached coherent memory? Do we need to cache the coherent kernel mappings in TTM as well, for ttm_bo_kmap()? /Thomas Regards, Christian. Second I can imagine unaccelerated setups (something like vkms using prime feeding a VNC connection) where we actually want the TTM buffers encrypted to protect data. But at least the latter reason is way far out in the future. So for me I'm ok with that if that works for you? /Thomas Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111551] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout
https://bugs.freedesktop.org/show_bug.cgi?id=111551 Christian König changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #5 from Christian König --- amdgpu is known to not work on arm64 until very recently. So it is not a supprise that this isn't working. Please switch to a newer kernel and re-test. Apart from that there isn't much we can do about 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
[PATCH v3 3/2] drm/panel: panel-simple: Set OSD070T1718 panel type
The OSD070T1718 is a DPI panel, set its type accordingly.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4b92b27eba86..5d487686d25c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2398,6 +2398,7 @@ static const struct panel_desc
osddisplays_osd070t1718_19ts = {
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
};
static const struct drm_display_mode pda_91_00156_a0_mode = {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107538] Intel-gpu-tools 1.23 tag fails compilation on Clang due to implicit declaration of function
https://bugs.freedesktop.org/show_bug.cgi?id=107538 Matt Roper changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Matt Roper --- As you noted, Lucas landed a patch shortly after the 1.23 release that addressed this. Since that time an official 1.24 release has come out, so I don't believe there's anything further that needs to be done with this bug. Closing as resolved. -- 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 -next] fbdev: omapfb: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot Signed-off-by: YueHaibing --- drivers/video/fbdev/omap2/omapfb/vrfb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/vrfb.c b/drivers/video/fbdev/omap2/omapfb/vrfb.c index 819e0bc..ee0dd4c 100644 --- a/drivers/video/fbdev/omap2/omapfb/vrfb.c +++ b/drivers/video/fbdev/omap2/omapfb/vrfb.c @@ -339,9 +339,7 @@ static int __init vrfb_probe(struct platform_device *pdev) int i; /* first resource is the register res, the rest are vrfb contexts */ - - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); - vrfb_base = devm_ioremap_resource(>dev, mem); + vrfb_base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(vrfb_base)) return PTR_ERR(vrfb_base); -- 2.7.4
Re: [PATCH v2 1/4] x86/mm: Export force_dma_unencrypted
On Wed, Sep 04, 2019 at 09:32:30AM +0200, Thomas Hellström (VMware) wrote: > That sounds great. Is there anything I can do to help out? I thought this > was more or less a dead end since the current dma_mmap_ API requires the > mmap_sem to be held in write mode (modifying the vma->vm_flags) whereas > fault() only offers read mode. But that would definitely work. We'll just need to split into a setup and faul phase. I have some sketches from a while ago, let me dust them off so that you can try them. > "If it's the latter, then I would like to reiterate that it would be better > that we work to come up with a long term plan to add what's missing to the > DMA api to help graphics drivers use coherent memory?" I don't think we need a long term plan. We've been adding features on an as-needed basis. And now that we have siginificanty less implementations of the API this actually becomes much easier as well.
[Bug 111551] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout
https://bugs.freedesktop.org/show_bug.cgi?id=111551 --- Comment #6 from yanhua <78666...@qq.com> --- As far as I know, arm64 does not support wc memory. and We have already turn the wc flag as newer kernel version does. -- 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] drm/nouveau: add missing single_release()
When using single_open() for opening, single_release() should be
used, otherwise there is a memory leak.
This is detected by Coccinelle semantic patch.
Fixes: 6e9fc177399f ("drm/nouveau/debugfs: add copy of sysfs pstate interface
ported to debugfs")
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 7dfbbbc1beea..35695f493271 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -202,6 +202,7 @@ static const struct file_operations nouveau_pstate_fops = {
.open = nouveau_debugfs_pstate_open,
.read = seq_read,
.write = nouveau_debugfs_pstate_set,
+ .release = single_release,
};
static struct drm_info_list nouveau_debugfs_list[] = {
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #66 from Michel Dänzer --- (In reply to tempel.julian from comment #65) > Since this commit, the modesetting driver shows the same behavior as > xf86-video-amdgpu: > https://gitlab.freedesktop.org/xorg/xserver/commit/ > f0d78b47ac49977a6007f5fe081f00c6eb19a12e Hmm, could the property update be part of the legacy => atomic compatibility code in the kernel? > So, now only xwayland isn't affected. But I think this can very well be just > because Wayland compositors yet don't support turning compositing off in > fullscreen. They still use page flipping though, similar to TearFree. Which Wayland compositor(s) have you tried? -- 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 v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
On Wed, Sep 4, 2019 at 12:38 PM Thomas Hellström (VMware) wrote: > > On 9/4/19 9:53 AM, Daniel Vetter wrote: > > On Wed, Sep 4, 2019 at 8:49 AM Thomas Hellström (VMware) > > wrote: > >> On 9/4/19 1:15 AM, Andy Lutomirski wrote: > >>> But, reading this, I have more questions: > >>> > >>> Can’t you get rid of cvma by using vmf_insert_pfn_prot()? > >> It looks like that, although there are comments in the code about > >> serious performance problems using VM_PFNMAP / vmf_insert_pfn() with > >> write-combining and PAT, so that would require some serious testing with > >> hardware I don't have. But I guess there is definitely room for > >> improvement here. Ideally we'd like to be able to change the > >> vma->vm_page_prot within fault(). But we can > > Just a quick comment on this: It's the repeated (per-pfn/pte) lookup > > of the PAT tables, which are dead slow. If you have a struct > > io_mapping then that can be done once, and then just blindly inserted. > > See remap_io_mapping in i915. > > -Daniel > > Thanks, Daniel. > > Indeed looks a lot like remap_pfn_range(), but usable at fault time? Yeah we call it from our fault handler. It's essentially vm_insert_pfn except the pat track isn't there, but instead relies on the pat tracking io_mapping has done already. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111551] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout
https://bugs.freedesktop.org/show_bug.cgi?id=111551 --- Comment #3 from Christian König --- As far as I can see this is a really large box with multiple GPUs installed. The SDMA rarely locks up, especially not while executing page table updates. So there is most likely something wrong with the hardware here. Are you sure that the power supply is large enough for that system? What system/platform is that? Could this be a coherency 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
[PATCH -next] fbdev/sa1100fb: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/video/fbdev/sa1100fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/sa1100fb.c b/drivers/video/fbdev/sa1100fb.c
index ae2bcfe..4428cef 100644
--- a/drivers/video/fbdev/sa1100fb.c
+++ b/drivers/video/fbdev/sa1100fb.c
@@ -1156,7 +1156,6 @@ static struct sa1100fb_info *sa1100fb_init_fbinfo(struct
device *dev)
static int sa1100fb_probe(struct platform_device *pdev)
{
struct sa1100fb_info *fbi;
- struct resource *res;
int ret, irq;
if (!dev_get_platdata(>dev)) {
@@ -1172,8 +1171,7 @@ static int sa1100fb_probe(struct platform_device *pdev)
if (!fbi)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- fbi->base = devm_ioremap_resource(>dev, res);
+ fbi->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(fbi->base))
return PTR_ERR(fbi->base);
--
2.7.4
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #27 from Mathieu Belanger --- It did fix it for me too. -- 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: panel-lvds: Potential Oops in probe error handling
On Wed, Sep 04, 2019 at 02:50:57PM +0300, Laurent Pinchart wrote: > > error: > > - put_device(>backlight->dev); > > + if (lvds->backlight) > > + put_device(>backlight->dev); > > How about simply > > - put_device(>backlight->dev); > + backlight_put(lvds->backlight); Yeah. That's cleaner. I will resend. regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
On 9/4/19 2:35 PM, Thomas Hellström (VMware) wrote: I've already talked with Christoph that we probably want to switch TTM over to using that instead to also get rid of the ttm_io_prot() hack. OK, would that mean us ditching other memory modes completely? And on-the-fly caching transitions? or is it just for the special case of cached coherent memory? Do we need to cache the coherent kernel mappings in TTM as well, for ttm_bo_kmap()? Reading this again, I wanted to point out that I'm not against this. Just curious. /Thomas
Re: [PATCH v2 1/3] drm/amd: be quiet when no SAD block is found
On 2019-09-04 5:12 a.m., Jean Delvare wrote:
> It is fine for displays without audio functionality to not provide
> any SAD block in their EDID. Do not log an error in that case,
> just return quietly.
>
> This fixes half of bug fdo#107825:
> https://bugs.freedesktop.org/show_bug.cgi?id=107825
>
> Signed-off-by: Jean Delvare
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Harry Wentland
> Cc: Leo Li
Reviewed-by: Harry Wentland
Harry
> ---
> No change since v1.
>
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|4 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|4 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |4 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |4 ++--
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c |7 +++
> 5 files changed, 11 insertions(+), 12 deletions(-)
>
> --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 2019-07-08
> 00:41:56.0 +0200
> +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 2019-08-30
> 14:28:46.081682223 +0200
> @@ -1345,10 +1345,10 @@ static void dce_v10_0_audio_write_sad_re
> }
>
> sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> - if (sad_count <= 0) {
> + if (sad_count < 0)
> DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> + if (sad_count <= 0)
> return;
> - }
> BUG_ON(!sads);
>
> for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 2019-07-08
> 00:41:56.0 +0200
> +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 2019-08-30
> 14:29:27.276205310 +0200
> @@ -1371,10 +1371,10 @@ static void dce_v11_0_audio_write_sad_re
> }
>
> sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> - if (sad_count <= 0) {
> + if (sad_count < 0)
> DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> + if (sad_count <= 0)
> return;
> - }
> BUG_ON(!sads);
>
> for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 2019-07-08
> 00:41:56.0 +0200
> +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 2019-08-30
> 17:58:53.613953458 +0200
> @@ -1248,10 +1248,10 @@ static void dce_v6_0_audio_write_sad_reg
> }
>
> sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> - if (sad_count <= 0) {
> + if (sad_count < 0)
> DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> + if (sad_count <= 0)
> return;
> - }
>
> for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> u32 tmp = 0;
> --- linux-5.2.orig/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 2019-07-08
> 00:41:56.0 +0200
> +++ linux-5.2/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 2019-08-30
> 14:29:01.948883708 +0200
> @@ -1298,10 +1298,10 @@ static void dce_v8_0_audio_write_sad_reg
> }
>
> sad_count = drm_edid_to_sad(amdgpu_connector_edid(connector), );
> - if (sad_count <= 0) {
> + if (sad_count < 0)
> DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> + if (sad_count <= 0)
> return;
> - }
> BUG_ON(!sads);
>
> for (i = 0; i < ARRAY_SIZE(eld_reg_to_type); i++) {
> --- linux-5.2.orig/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> 2019-07-08 00:41:56.0 +0200
> +++ linux-5.2/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> 2019-08-30 14:31:03.086421910 +0200
> @@ -98,11 +98,10 @@ enum dc_edid_status dm_helpers_parse_edi
> (struct edid *) edid->raw_edid);
>
> sad_count = drm_edid_to_sad((struct edid *) edid->raw_edid, );
> - if (sad_count <= 0) {
> - DRM_INFO("SADs count is: %d, don't need to read it\n",
> - sad_count);
> + if (sad_count < 0)
> + DRM_ERROR("Couldn't read SADs: %d\n", sad_count);
> + if (sad_count <= 0)
> return result;
> - }
>
> edid_caps->audio_mode_count = sad_count < DC_MAX_AUDIO_DESC_COUNT ?
> sad_count : DC_MAX_AUDIO_DESC_COUNT;
> for (i = 0; i < edid_caps->audio_mode_count; ++i) {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BACKPORT 4.14.y 1/8] drm/i915/fbdev: Actually configure untiled displays
On Tue, 03 Sep 2019, Baolin Wang wrote:
> From: Chris Wilson
>
> If we skipped all the connectors that were not part of a tile, we would
> leave conn_seq=0 and conn_configured=0, convincing ourselves that we
> had stagnated in our configuration attempts. Avoid this situation by
> starting conn_seq=ALL_CONNECTORS, and repeating until we find no more
> connectors to configure.
>
> Fixes: 754a76591b12 ("drm/i915/fbdev: Stop repeating tile configuration on
> stagnation")
> Reported-by: Maarten Lankhorst
> Signed-off-by: Chris Wilson
> Cc: Maarten Lankhorst
> Reviewed-by: Maarten Lankhorst
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190215123019.32283-1-ch...@chris-wilson.co.uk
> Cc: # v3.19+
> Signed-off-by: Baolin Wang
Please look into the scripts to avoid picking up stuff that has
subsequently been reverted:
commit 9fa246256e09dc30820524401cdbeeaadee94025
Author: Dave Airlie
Date: Wed Apr 24 10:47:56 2019 +1000
Revert "drm/i915/fbdev: Actually configure untiled displays"
This reverts commit d179b88deb3bf6fed4991a31fd6f0f2cad21fab5.
This commit is documented to break userspace X.org modesetting driver in
certain configurations.
The X.org modesetting userspace driver is broken. No fixes are available
yet. In order for this patch to be applied it either needs a config option or a
workaround developed.
This has been reported a few times, saying it's a userspace problem is
clearly against the regression rules.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109806
Signed-off-by: Dave Airlie
Cc: # v3.19+
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index da2d309..14eb8a0 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -326,8 +326,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper
> *fb_helper,
> bool *enabled, int width, int height)
> {
> struct drm_i915_private *dev_priv = to_i915(fb_helper->dev);
> - unsigned long conn_configured, conn_seq, mask;
> unsigned int count = min(fb_helper->connector_count, BITS_PER_LONG);
> + unsigned long conn_configured, conn_seq;
> int i, j;
> bool *save_enabled;
> bool fallback = true, ret = true;
> @@ -345,10 +345,9 @@ static bool intel_fb_initial_config(struct drm_fb_helper
> *fb_helper,
> drm_modeset_backoff();
>
> memcpy(save_enabled, enabled, count);
> - mask = GENMASK(count - 1, 0);
> + conn_seq = GENMASK(count - 1, 0);
> conn_configured = 0;
> retry:
> - conn_seq = conn_configured;
> for (i = 0; i < count; i++) {
> struct drm_fb_helper_connector *fb_conn;
> struct drm_connector *connector;
> @@ -361,7 +360,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper
> *fb_helper,
> if (conn_configured & BIT(i))
> continue;
>
> - if (conn_seq == 0 && !connector->has_tile)
> + /* First pass, only consider tiled connectors */
> + if (conn_seq == GENMASK(count - 1, 0) && !connector->has_tile)
> continue;
>
> if (connector->status == connector_status_connected)
> @@ -465,8 +465,10 @@ static bool intel_fb_initial_config(struct drm_fb_helper
> *fb_helper,
> conn_configured |= BIT(i);
> }
>
> - if ((conn_configured & mask) != mask && conn_configured != conn_seq)
> + if (conn_configured != conn_seq) { /* repeat until no more are found */
> + conn_seq = conn_configured;
> goto retry;
> + }
>
> /*
>* If the BIOS didn't enable everything it could, fall back to have the
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/2] drm/panel: Add and fill drm_panel type field
Add a type field to the drm_panel structure to report the panel type,
using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
eDP, DSI and DPI). This will be used to initialise the corresponding
connector type.
Update all panel drivers accordingly. The panel-simple driver only
specifies the type for the known to be LVDS panels, while all other
panels are left as unknown and will be converted on a case-by-case
basis as they all need to be carefully reviewed.
Signed-off-by: Laurent Pinchart
Reviewed-by: Boris Brezillon
---
Changes since v2:
- Add missing comma at end of line
Changes since v1:
- Rename the type field to connector_type
- Pass the type to the drm_panel_init() function
- Keep connector type as unknown for non-LVDS panels in panel-simple
- Flag the toshiba_lt089ac29000 panel as LVDS as reported by Boris
---
drivers/gpu/drm/drm_panel.c | 5 +++-
drivers/gpu/drm/panel/panel-arm-versatile.c | 3 ++-
.../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 ++-
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 3 ++-
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 3 ++-
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 3 ++-
.../gpu/drm/panel/panel-jdi-lt070me05000.c| 3 ++-
.../drm/panel/panel-kingdisplay-kd097d04.c| 2 +-
drivers/gpu/drm/panel/panel-lg-lb035q02.c | 3 ++-
drivers/gpu/drm/panel/panel-lg-lg4573.c | 3 ++-
drivers/gpu/drm/panel/panel-lvds.c| 3 ++-
drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 3 ++-
drivers/gpu/drm/panel/panel-novatek-nt39016.c | 3 ++-
.../drm/panel/panel-olimex-lcd-olinuxino.c| 3 ++-
.../gpu/drm/panel/panel-orisetech-otm8009a.c | 3 ++-
.../drm/panel/panel-osd-osd101t2587-53ts.c| 2 +-
.../drm/panel/panel-panasonic-vvx10f034n00.c | 2 +-
.../drm/panel/panel-raspberrypi-touchscreen.c | 3 ++-
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 3 ++-
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 3 ++-
.../drm/panel/panel-rocktech-jh057n00900.c| 3 ++-
drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 3 ++-
drivers/gpu/drm/panel/panel-samsung-ld9040.c | 3 ++-
drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 3 ++-
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 3 ++-
.../gpu/drm/panel/panel-samsung-s6e63j0x03.c | 3 ++-
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 3 ++-
drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 3 ++-
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 3 ++-
.../gpu/drm/panel/panel-sharp-lq101r1sx01.c | 3 ++-
.../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 3 ++-
.../gpu/drm/panel/panel-sharp-ls043t1le01.c | 2 +-
drivers/gpu/drm/panel/panel-simple.c | 26 ++-
drivers/gpu/drm/panel/panel-sitronix-st7701.c | 3 ++-
.../gpu/drm/panel/panel-sitronix-st7789v.c| 3 ++-
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 3 ++-
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 3 ++-
drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 3 ++-
drivers/gpu/drm/panel/panel-tpo-tpg110.c | 3 ++-
drivers/gpu/drm/panel/panel-truly-nt35597.c | 3 ++-
include/drm/drm_panel.h | 12 -
41 files changed, 112 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index ba2fad4c9648..ed7985c0535a 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -46,16 +46,19 @@ static LIST_HEAD(panel_list);
* @panel: DRM panel
* @dev: parent device of the panel
* @funcs: panel operations
+ * @connector_type: the connector type (DRM_MODE_CONNECTOR_*) corresponding to
+ * the panel interface
*
* Initialize the panel structure for subsequent registration with
* drm_panel_add().
*/
void drm_panel_init(struct drm_panel *panel, struct device *dev,
- const struct drm_panel_funcs *funcs)
+ const struct drm_panel_funcs *funcs, int connector_type)
{
INIT_LIST_HEAD(>list);
panel->dev = dev;
panel->funcs = funcs;
+ panel->connector_type = connector_type;
}
EXPORT_SYMBOL(drm_panel_init);
diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c
b/drivers/gpu/drm/panel/panel-arm-versatile.c
index a4333ed0f20c..a0574dc03e16 100644
--- a/drivers/gpu/drm/panel/panel-arm-versatile.c
+++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
@@ -350,7 +350,8 @@ static int versatile_panel_probe(struct platform_device
*pdev)
dev_info(dev, "panel mounted on IB2 daughterboard\n");
}
- drm_panel_init(>panel, dev, _panel_drm_funcs);
+ drm_panel_init(>panel, dev, _panel_drm_funcs,
+ DRM_MODE_CONNECTOR_DPI);
return drm_panel_add(>panel);
}
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index 7d5d7455bc01..98f184b81187 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++
[PATCH v3 0/2] drm/panel: Extend panels to report their types
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. 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 .../gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 3 +- drivers/gpu/drm/bridge/cdns-dsi.c | 3 +- drivers/gpu/drm/bridge/lvds-encoder.c | 3 +- drivers/gpu/drm/bridge/panel.c| 69 --- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 +- drivers/gpu/drm/drm_panel.c | 5 +- drivers/gpu/drm/ingenic/ingenic-drm.c | 4 +- drivers/gpu/drm/mcde/mcde_dsi.c | 4 +- drivers/gpu/drm/panel/panel-arm-versatile.c | 3 +- .../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 +- drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 3 +- drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 3 +- drivers/gpu/drm/panel/panel-innolux-p079zca.c | 3 +- .../gpu/drm/panel/panel-jdi-lt070me05000.c| 3 +- .../drm/panel/panel-kingdisplay-kd097d04.c| 2 +- drivers/gpu/drm/panel/panel-lg-lb035q02.c | 3 +- drivers/gpu/drm/panel/panel-lg-lg4573.c | 3 +- drivers/gpu/drm/panel/panel-lvds.c| 3 +- drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 3 +- drivers/gpu/drm/panel/panel-novatek-nt39016.c | 3 +- .../drm/panel/panel-olimex-lcd-olinuxino.c| 3 +- .../gpu/drm/panel/panel-orisetech-otm8009a.c | 3 +- .../drm/panel/panel-osd-osd101t2587-53ts.c| 2 +- .../drm/panel/panel-panasonic-vvx10f034n00.c | 2 +- .../drm/panel/panel-raspberrypi-touchscreen.c | 3 +- drivers/gpu/drm/panel/panel-raydium-rm67191.c | 3 +- drivers/gpu/drm/panel/panel-raydium-rm68200.c | 3 +- .../drm/panel/panel-rocktech-jh057n00900.c| 3 +- drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 3 +- drivers/gpu/drm/panel/panel-samsung-ld9040.c | 3 +- drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 3 +- drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 3 +- .../gpu/drm/panel/panel-samsung-s6e63j0x03.c | 3 +- drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 3 +- drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 3 +- drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 3 +- .../gpu/drm/panel/panel-sharp-lq101r1sx01.c | 3 +- .../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 3 +- .../gpu/drm/panel/panel-sharp-ls043t1le01.c | 2 +- drivers/gpu/drm/panel/panel-simple.c | 26 ++- drivers/gpu/drm/panel/panel-sitronix-st7701.c | 3 +- .../gpu/drm/panel/panel-sitronix-st7789v.c| 3 +- drivers/gpu/drm/panel/panel-sony-acx565akm.c | 3 +- drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 3 +- drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 3 +- drivers/gpu/drm/panel/panel-tpo-tpg110.c | 3 +-
[PATCH v3 2/2] drm/bridge: panel: Infer connector type from panel by default
The drm panel bridge creates a connector using a connector type
explicitly passed by the display controller or bridge driver that
instantiates the panel bridge. Now that drm_panel reports its connector
type, we can use it to avoid passing an explicit (and often incorrect)
connector type to drm_panel_bridge_add() and
devm_drm_panel_bridge_add().
Several drivers report incorrect or unknown connector types to
userspace. Reporting a different type may result in a breakage. For that
reason, rename (devm_)drm_panel_bridge_add() to
(devm_)drm_panel_bridge_add_typed(), and add new
(devm_)drm_panel_bridge_add() functions that use the panel connector
type. Update all callers of (devm_)drm_panel_bridge_add() to the _typed
function, they will be converted one by one after testing.
The panel drivers have been updated with the following Coccinelle
semantic patch, with manual inspection and fixes to indentation.
@@
expression bridge;
expression dev;
expression panel;
identifier type;
@@
(
-bridge = drm_panel_bridge_add(panel, type);
+bridge = drm_panel_bridge_add_typed(panel, type);
|
-bridge = devm_drm_panel_bridge_add(dev, panel, type);
+bridge = devm_drm_panel_bridge_add_typed(dev, panel, type);
)
Signed-off-by: Laurent Pinchart
Reviewed-by: Boris Brezillon
---
Changes since v2:
- Fix a typo in the commit message
Changes since v1:
- Add and use _typed variants
---
.../gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 3 +-
drivers/gpu/drm/bridge/cdns-dsi.c | 3 +-
drivers/gpu/drm/bridge/lvds-encoder.c | 3 +-
drivers/gpu/drm/bridge/panel.c| 69 ---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 3 +-
drivers/gpu/drm/ingenic/ingenic-drm.c | 4 +-
drivers/gpu/drm/mcde/mcde_dsi.c | 4 +-
drivers/gpu/drm/pl111/pl111_drv.c | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 4 +-
drivers/gpu/drm/rockchip/rockchip_rgb.c | 3 +-
drivers/gpu/drm/stm/ltdc.c| 4 +-
drivers/gpu/drm/tilcdc/tilcdc_external.c | 4 +-
drivers/gpu/drm/tve200/tve200_drv.c | 4 +-
drivers/gpu/drm/vc4/vc4_dpi.c | 3 +-
drivers/gpu/drm/vc4/vc4_dsi.c | 4 +-
include/drm/drm_bridge.h | 11 +--
16 files changed, 93 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 375fa84c548b..121b62682d80 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -107,7 +107,8 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
*dev, int endpoint)
output->encoder.possible_crtcs = 0x1;
if (panel) {
- bridge = drm_panel_bridge_add(panel,
DRM_MODE_CONNECTOR_Unknown);
+ bridge = drm_panel_bridge_add_typed(panel,
+ DRM_MODE_CONNECTOR_Unknown);
if (IS_ERR(bridge))
return PTR_ERR(bridge);
}
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
b/drivers/gpu/drm/bridge/cdns-dsi.c
index 6166dca6be81..3a5bd4e7fd1e 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -956,7 +956,8 @@ static int cdns_dsi_attach(struct mipi_dsi_host *host,
panel = of_drm_find_panel(np);
if (!IS_ERR(panel)) {
- bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DSI);
+ bridge = drm_panel_bridge_add_typed(panel,
+ DRM_MODE_CONNECTOR_DSI);
} else {
bridge = of_drm_find_bridge(dev->dev.of_node);
if (!bridge)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 2ab2c234f26c..e2132a8d5106 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -106,7 +106,8 @@ static int lvds_encoder_probe(struct platform_device *pdev)
}
lvds_encoder->panel_bridge =
- devm_drm_panel_bridge_add(dev, panel, DRM_MODE_CONNECTOR_LVDS);
+ devm_drm_panel_bridge_add_typed(dev, panel,
+ DRM_MODE_CONNECTOR_LVDS);
if (IS_ERR(lvds_encoder->panel_bridge))
return PTR_ERR(lvds_encoder->panel_bridge);
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 6cffeb4a42f2..f4e293e7cf64 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -134,8 +134,6 @@ static const struct drm_bridge_funcs
panel_bridge_bridge_funcs = {
* just calls the appropriate functions from _panel.
*
* @panel: The drm_panel being wrapped. Must be non-NULL.
- * @connector_type: The DRM_MODE_CONNECTOR_* for the connector to be
- * created.
*
* For drivers converting from directly using drm_panel: The expected
* usage
[PATCH] drm: Use EOPNOTSUPP, not ENOTSUPP
- it's what we recommend in our docs:
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
- it's the overwhelmingly used error code for "operation not
supported", at least in drm core (slightly less so in drivers):
$ git grep EOPNOTSUP -- drivers/gpu/drm/*c | wc -l
83
$ git grep ENOTSUP -- drivers/gpu/drm/*c | wc -l
5
- include/linux/errno.h makes it fairly clear that these are for nfsv3
(plus they also have error codes above 512, which is the block with
some special behaviour ...)
/* Defined for the NFSv3 protocol */
If the above isn't reflecting current practice, then I guess we should
at least update the docs.
Cc: José Roberto de Souza
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: Alex Deucher
Cc: Andres Rodriguez
Cc: Noralf Trønnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_edid.c | 6 +++---
drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 82a4ceed3fcf..12c783f4d956 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3719,7 +3719,7 @@ cea_db_offsets(const u8 *cea, int *start, int *end)
if (*end < 4 || *end > 127)
return -ERANGE;
} else {
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
}
return 0;
@@ -4188,7 +4188,7 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
**sads)
if (cea_revision(cea) < 3) {
DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
}
if (cea_db_offsets(cea, , )) {
@@ -4249,7 +4249,7 @@ int drm_edid_to_speaker_allocation(struct edid *edid, u8
**sadb)
if (cea_revision(cea) < 3) {
DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
}
if (cea_db_offsets(cea, , )) {
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index c4ee2709a6f3..f8154316a3b0 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -955,7 +955,7 @@ static int mipi_dbi_typec1_command(struct mipi_dbi *dbi, u8
*cmd,
int ret;
if (mipi_dbi_command_is_read(dbi, *cmd))
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
MIPI_DBI_DEBUG_COMMAND(*cmd, parameters, num);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Use EOPNOTSUPP, not ENOTSUPP
Den 04.09.2019 16.39, skrev Daniel Vetter: > - it's what we recommend in our docs: > > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values > > - it's the overwhelmingly used error code for "operation not > supported", at least in drm core (slightly less so in drivers): > > $ git grep EOPNOTSUP -- drivers/gpu/drm/*c | wc -l > 83 > $ git grep ENOTSUP -- drivers/gpu/drm/*c | wc -l > 5 > > - include/linux/errno.h makes it fairly clear that these are for nfsv3 > (plus they also have error codes above 512, which is the block with > some special behaviour ...) > > /* Defined for the NFSv3 protocol */ > > If the above isn't reflecting current practice, then I guess we should > at least update the docs. > > Cc: José Roberto de Souza > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: Alex Deucher > Cc: Andres Rodriguez > Cc: Noralf Trønnes > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_edid.c | 6 +++--- > drivers/gpu/drm/drm_mipi_dbi.c | 2 +- > 2 files changed, 4 insertions(+), 4 deletions(-) > Acked-by: Noralf Trønnes Ben Hutchings made this comment[1] in a thread about use of ENOTSUPP in drivers: glibc's strerror() returns these strings for ENOTSUPP and EOPNOTSUPP respectively: "Unknown error 524" "Operation not supported" So at least for errors returned to userspace EOPNOTSUPP makes sense. Noralf. [1] https://patchwork.ozlabs.org/patch/309627/#690997 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/vram: Add kmap ref-counting to GEM VRAM objects
The kmap and kunmap operations of GEM VRAM buffers can now be called
in interleaving pairs. The first call to drm_gem_vram_kmap() maps the
buffer's memory to kernel address space and the final call to
drm_gem_vram_kunmap() unmaps the memory. Intermediate calls to these
functions increment or decrement a reference counter.
This change allows for keeping buffer memory mapped for longer and
minimizes the amount of changes to TLB, page tables, etc.
Signed-off-by: Thomas Zimmermann
Cc: Davidlohr Bueso
---
drivers/gpu/drm/drm_gem_vram_helper.c | 74 ---
include/drm/drm_gem_vram_helper.h | 19 +++
2 files changed, 75 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index fd751078bae1..6c7912092876 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -26,7 +26,11 @@ static void drm_gem_vram_cleanup(struct drm_gem_vram_object
*gbo)
* TTM buffer object in 'bo' has already been cleaned
* up; only release the GEM object.
*/
+
+ WARN_ON(gbo->kmap_use_count);
+
drm_gem_object_release(>bo.base);
+ mutex_destroy(>kmap_lock);
}
static void drm_gem_vram_destroy(struct drm_gem_vram_object *gbo)
@@ -100,6 +104,8 @@ static int drm_gem_vram_init(struct drm_device *dev,
if (ret)
goto err_drm_gem_object_release;
+ mutex_init(>kmap_lock);
+
return 0;
err_drm_gem_object_release:
@@ -283,6 +289,34 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo)
}
EXPORT_SYMBOL(drm_gem_vram_unpin);
+static void *drm_gem_vram_kmap_locked(struct drm_gem_vram_object *gbo,
+ bool map, bool *is_iomem)
+{
+ int ret;
+ struct ttm_bo_kmap_obj *kmap = >kmap;
+
+ if (gbo->kmap_use_count > 0)
+ goto out;
+
+ if (kmap->virtual || !map)
+ goto out;
+
+ ret = ttm_bo_kmap(>bo, 0, gbo->bo.num_pages, kmap);
+ if (ret)
+ return ERR_PTR(ret);
+
+out:
+ if (!kmap->virtual) {
+ if (is_iomem)
+ *is_iomem = false;
+ return NULL; /* not mapped; don't increment ref */
+ }
+ ++gbo->kmap_use_count;
+ if (is_iomem)
+ return ttm_kmap_obj_virtual(kmap, is_iomem);
+ return kmap->virtual;
+}
+
/**
* drm_gem_vram_kmap() - Maps a GEM VRAM object into kernel address space
* @gbo: the GEM VRAM object
@@ -304,40 +338,44 @@ void *drm_gem_vram_kmap(struct drm_gem_vram_object *gbo,
bool map,
bool *is_iomem)
{
int ret;
- struct ttm_bo_kmap_obj *kmap = >kmap;
-
- if (kmap->virtual || !map)
- goto out;
+ void *virtual;
- ret = ttm_bo_kmap(>bo, 0, gbo->bo.num_pages, kmap);
+ ret = mutex_lock_interruptible(>kmap_lock);
if (ret)
return ERR_PTR(ret);
+ virtual = drm_gem_vram_kmap_locked(gbo, map, is_iomem);
+ mutex_unlock(>kmap_lock);
-out:
- if (!is_iomem)
- return kmap->virtual;
- if (!kmap->virtual) {
- *is_iomem = false;
- return NULL;
- }
- return ttm_kmap_obj_virtual(kmap, is_iomem);
+ return virtual;
}
EXPORT_SYMBOL(drm_gem_vram_kmap);
-/**
- * drm_gem_vram_kunmap() - Unmaps a GEM VRAM object
- * @gbo: the GEM VRAM object
- */
-void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo)
+static void drm_gem_vram_kunmap_locked(struct drm_gem_vram_object *gbo)
{
struct ttm_bo_kmap_obj *kmap = >kmap;
+ if (WARN_ON_ONCE(!gbo->kmap_use_count))
+ return;
+ if (--gbo->kmap_use_count > 0)
+ return;
+
if (!kmap->virtual)
return;
ttm_bo_kunmap(kmap);
kmap->virtual = NULL;
}
+
+/**
+ * drm_gem_vram_kunmap() - Unmaps a GEM VRAM object
+ * @gbo: the GEM VRAM object
+ */
+void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo)
+{
+ mutex_lock(>kmap_lock);
+ drm_gem_vram_kunmap_locked(gbo);
+ mutex_unlock(>kmap_lock);
+}
EXPORT_SYMBOL(drm_gem_vram_kunmap);
/**
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index ac217d768456..8c08bc87b788 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -34,11 +34,30 @@ struct vm_area_struct;
* backed by VRAM. It can be used for simple framebuffer devices with
* dedicated memory. The buffer object can be evicted to system memory if
* video memory becomes scarce.
+ *
+ * GEM VRAM objects perform reference counting for pin and mapping
+ * operations. So a buffer object that has been pinned N times with
+ * drm_gem_vram_pin() must be unpinned N times with
+ * drm_gem_vram_unpin(). The same applies to pairs of
+ * drm_gem_vram_kmap() and drm_gem_vram_kunmap().
*/
struct drm_gem_vram_object {
