Re: [PATCH 9/9] drm/amdgpu: Lock the attached dmabuf in unpopulate
Am 14.04.21 um 08:46 schrieb Felix Kuehling:
amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The dmabuf->resv
must not be held by the caller or dma_buf_detach will deadlock. This is
probably not the right fix. I get a recursive lock warning with the
reservation held in ttm_bo_release. Should unmap_attachment move to
backend_unbind instead?
Yes probably, but I'm really wondering if we should call unpopulate
without holding the reservation lock.
Christian.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 936b3cfdde55..257750921eed 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1216,9 +1216,22 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_device
*bdev,
if (ttm->sg && gtt->gobj->import_attach) {
struct dma_buf_attachment *attach;
+ bool locked;
attach = gtt->gobj->import_attach;
+ /* FIXME: unpopulate can be called during bo_destroy.
+* The dmabuf->resv must not be held by the caller or
+* dma_buf_detach will deadlock. This is probably not
+* the right fix. I get a recursive lock warning with the
+* reservation held in ttm_bo_releas.. Should
+* unmap_attachment move to backend_unbind instead?
+*/
+ locked = dma_resv_is_locked(attach->dmabuf->resv);
+ if (!locked)
+ dma_resv_lock(attach->dmabuf->resv, NULL);
dma_buf_unmap_attachment(attach, ttm->sg, DMA_BIDIRECTIONAL);
+ if (!locked)
+ dma_resv_unlock(attach->dmabuf->resv);
ttm->sg = NULL;
return;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Hi Am 07.04.21 um 21:49 schrieb Felix Kuehling: On 2021-04-07 3:34 p.m., Felix Kuehling wrote: On 2021-04-07 7:25 a.m., Christian König wrote: + /* + * Don't verify access for KFD BOs. They don't have a GEM + * object associated with them. + */ + if (bo->kfd_bo) + goto out; Who does the access verification now? This is somewhat confusing. I took this check as-is, including the comment, from amdgpu's verify_access function. The verify_access function was called by ttm_bo_mmap. It returned 0 and ttm_bo_mmap did the mapping. This is probably a left-over from when we mapped BOs using /dev/kfd. We changed this to use /dev/dri/renderD* a long time ago to fix CPU mapping invalidations on memory evictions. I think we can let GEM do the access check. Ok, good to know. Thomas can you remove the extra handling in a separate prerequisite patch? If anybody then bisects to this patch we at least know what to do to get it working again. FWIW, I ran KFDTest test with this shortcut removed on current amd-staging-drm-next + my HMM patch series, and it didn't seem to cause any issues. Wait, I celebrated too soon. I was running the wrong kernel. I do see some failures where access is being denied. I need to do more debugging to figure out what's causing that. Any news here? I saw the patch at [1], which removes the kfd_bo test. Can I assume that the series addresses the issue? Best regards Thomas [1] https://patchwork.freedesktop.org/patch/427516/?series=88822&rev=1 Regards, Felix Regards, Felix Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tue, 13 Apr 2021 16:11:29 +0200
Daniel Vetter wrote:
> On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> > On Tue, 13 Apr 2021 11:49:03 +0200
> > Daniel Vetter wrote:
> >
> > > It's very confusing for userspace to have to deal with inconsistencies
> > > here, and some drivers screwed this up a bit. Most just ommitted the
> > > format list when they meant to say that only linear modifier is
> > > allowed, but some also meant that only implied modifiers are
> > > acceptable (because actually none of the planes registered supported
> > > modifiers).
> > >
> > > Now that this is all done consistently across all drivers, document
> > > the rules and enforce it in the drm core.
> > >
> > > Cc: Pekka Paalanen
> > > Signed-off-by: Daniel Vetter
> > > Cc: Maarten Lankhorst
> > > Cc: Maxime Ripard
> > > Cc: Thomas Zimmermann
> > > Cc: David Airlie
> > > Cc: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/drm_plane.c | 16 +++-
> > > include/drm/drm_mode_config.h | 2 ++
> > > 2 files changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > index 0dd43882fe7c..16a7e3e57f7f 100644
> > > --- a/drivers/gpu/drm/drm_plane.c
> > > +++ b/drivers/gpu/drm/drm_plane.c
> > > @@ -128,6 +128,11 @@
> > > * pairs supported by this plane. The blob is a struct
> > > * drm_format_modifier_blob. Without this property the plane doesn't
> > > * support buffers with modifiers. Userspace cannot change this
> > > property.
> > > + *
> > > + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
> > > + * capability for general modifier support. If this flag is set then
> > > every
> > > + * plane will have the IN_FORMATS property, even when it only
> > > supports
> > > + * DRM_FORMAT_MOD_LINEAR.
> >
> > Ooh, that's even better. But isn't that changing the meaning of the
> > cap? Isn't the cap older than IN_FORMATS?
>
> Hm indeed. But also how exactly are you going to user modifiers without
> IN_FORMATS ... it's a bit hard.
Easy for at least one specific case, as Daniel Stone said in IRC. Use
GBM to allocate using the no-modifiers API but specify USE_LINEAR. That
basically gives you MOD_LINEAR buffer. Then you can try to make a DRM
FB for it using AddFB2-with-modifiers.
Does anyone do this, I have no idea.
Actually, I think this semantic change is fine. Old userspace did not
know that the cap means all planes have IN_FORMATS, so they can deal
with IN_FORMATS missing, but if it is never missing, no problem.
It could be a problem with new userspace and old kernel, but that's by
definition not a kernel bug, right? Just... inconvenient for userspace
as they can't make full use of the flag and need to keep the fallback
path for missing IN_FORMATS.
As long as there are KMS drivers that don't support modifiers, generic
userspace probably needs the fallback path anyway.
> I think this is all because we've enabled
> modifiers piece-by-piece and never across the entire thing (e.g. with
> compositor and protocols), so the missing pieces only became apparent
> later on.
>
> I'm not sure whether compositors really want to support this, I guess
> worst case we could disable the cap on these old kernels.
>
> > What about the opposite? Is it allowed to have even a single IN_FORMATS
> > if you don't have the cap?
>
> That direction is enforced since 5.1, because some drivers screwed it up
> and confusion in userspace ensued.
>
> Should I add a bug that on kernels older than 5.1 the situation is more
> murky and there's lots of bugs?
Yes, that would help to set expectations.
I'm currently on Debian stable FWIW, so 4.19 based kernel with I don't
know what patches.
On Tue, 13 Apr 2021 16:19:10 +0200
Daniel Vetter wrote:
> On Tue, Apr 13, 2021 at 04:11:29PM +0200, Daniel Vetter wrote:
> >
> > Should I add a bug that on kernels older than 5.1 the situation is more
> > murky and there's lots of bugs?
>
> I guess we should recommend to userspace that if they spot an
> inconsistency between IN_FORMATS across planes and the cap then maybe they
> want to disable modifier support because it might be all kinds of broken?
Yes please!
--
> >
> > > */
> > >
> > > static unsigned int drm_num_planes(struct drm_device *dev)
> > > @@ -277,8 +282,14 @@ static int __drm_universal_plane_init(struct
> > > drm_device *dev,
> > > format_modifier_count++;
> > > }
> > >
> > > - if (format_modifier_count)
> > > + /* autoset the cap and check for consistency across all planes */
> > > + if (format_modifier_count) {
> > > + WARN_ON(!config->allow_fb_modifiers &&
> > > + !list_empty(&config->plane_list));
> >
> > What does this mean?
>
> If allow_fb_modifiers isn't set yet (we do that in the line below) and we
> are _not_ the first plane that gets added to the driver (that's done
> towards the end of the function) then that m
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
On Wed, 14 Apr 2021 at 08:13, Neil Armstrong wrote:
>
> Hi Rob,
>
> Le 13/04/2021 à 22:21, Robert Foss a écrit :
> > Hey Neil & Phong,
> >
> > Thanks for submitting this series!
> >
> >> +
> >> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
> >> + .attach = it66121_bridge_attach,
> >> + .enable = it66121_bridge_enable,
> >> + .disable = it66121_bridge_disable,
> >> + .mode_set = it66121_bridge_mode_set,
> >> + .mode_valid = it66121_bridge_mode_valid,
> >> + .detect = it66121_bridge_detect,
> >> + .get_edid = it66121_bridge_get_edid,
> >> + .atomic_get_output_bus_fmts =
> >> it66121_bridge_atomic_get_output_bus_fmts,
> >> + .atomic_get_input_bus_fmts =
> >> it66121_bridge_atomic_get_input_bus_fmts,
> >> +};
> >
> > I would like to see an implementation of HPD, since it is supported by
> > the hardware[1] (and required by the documentation). IRQ status bit 0
> > seems to be the responsible for notifying us about hot plug detection
> > events.
>
> It's implemented in the IRQ handler with the IT66121_INT_STATUS1_HPD_STATUS
> event.
>
I didn't even get that far :)
Either way, the HPD support should be exposed in drm_bridge_funcs
(.hpd_enable, .hpd_disable (and possibly .hpd_notify)) and
drm_bridge.ops (DRM_BRIDGE_OP_HPD).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
On 14/04/2021 10:06, Robert Foss wrote:
> On Wed, 14 Apr 2021 at 08:13, Neil Armstrong wrote:
>>
>> Hi Rob,
>>
>> Le 13/04/2021 à 22:21, Robert Foss a écrit :
>>> Hey Neil & Phong,
>>>
>>> Thanks for submitting this series!
>>>
+
+static const struct drm_bridge_funcs it66121_bridge_funcs = {
+ .attach = it66121_bridge_attach,
+ .enable = it66121_bridge_enable,
+ .disable = it66121_bridge_disable,
+ .mode_set = it66121_bridge_mode_set,
+ .mode_valid = it66121_bridge_mode_valid,
+ .detect = it66121_bridge_detect,
+ .get_edid = it66121_bridge_get_edid,
+ .atomic_get_output_bus_fmts =
it66121_bridge_atomic_get_output_bus_fmts,
+ .atomic_get_input_bus_fmts =
it66121_bridge_atomic_get_input_bus_fmts,
+};
>>>
>>> I would like to see an implementation of HPD, since it is supported by
>>> the hardware[1] (and required by the documentation). IRQ status bit 0
>>> seems to be the responsible for notifying us about hot plug detection
>>> events.
>>
>> It's implemented in the IRQ handler with the IT66121_INT_STATUS1_HPD_STATUS
>> event.
>>
>
> I didn't even get that far :)
>
> Either way, the HPD support should be exposed in drm_bridge_funcs
> (.hpd_enable, .hpd_disable (and possibly .hpd_notify)) and
> drm_bridge.ops (DRM_BRIDGE_OP_HPD).
>
Indeed I forgot these calls in the NO_CONNECTOR implementation...
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] dt-bindings: display: bridge: add it66121 bindings
On 13/04/2021 18:03, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Mon, Apr 12, 2021 at 05:46:46PM +0200, Neil Armstrong wrote:
>> From: Phong LE
>>
>> Add the ITE bridge HDMI it66121 bindings.
>>
>> Signed-off-by: Phong LE
>> Signed-off-by: Neil Armstrong
>> ---
>> .../bindings/display/bridge/ite,it66121.yaml | 123 ++
>> 1 file changed, 123 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
>> b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
>> new file mode 100644
>> index ..61ed6dc7740b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
>> @@ -0,0 +1,123 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: ITE it66121 HDMI bridge Device Tree Bindings
>> +
>> +maintainers:
>> + - Phong LE
>> + - Neil Armstrong
>> +
>> +description: |
>> + The IT66121 is a high-performance and low-power single channel HDMI
>> + transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward
>> compatible
>> + to DVI 1.0 specifications.
>> +
>> +properties:
>> + compatible:
>> +const: ite,it66121
>> +
>> + reg:
>> +maxItems: 1
>> +description: base I2C address of the device
>
> You can drop the description.
Done
>
>> +
>> + reset-gpios:
>> +maxItems: 1
>> +description: GPIO connected to active low reset
>> +
>> + vrf12-supply:
>> +description: Regulator for 1.2V analog core power.
>> +
>> + vcn33-supply:
>> +description: Regulator for 3.3V digital core power.
>> +
>> + vcn18-supply:
>> +description: Regulator for 1.8V IO core power.
>> +
>> + interrupts:
>> +maxItems: 1
>> +
>> + ports:
>> +$ref: /schemas/graph.yaml#/properties/ports
>> +
>> +properties:
>> + port@0:
>> +$ref: /schemas/graph.yaml#/$defs/port-base
>> +unevaluatedProperties: false
>> +description: DPI input port.
>> +
>> +properties:
>> + endpoint:
>> +$ref: /schemas/graph.yaml#/$defs/endpoint-base
>> +unevaluatedProperties: false
>> +
>> +properties:
>> + bus-width:
>> +description:
>> + Endpoint bus width.
>> +enum:
>> + - 12 # 12 data lines connected and dual-edge mode
>> + - 24 # 24 data lines connected and single-edge mode
>> +default: 24
>> +
>> + port@1:
>> +$ref: /schemas/graph.yaml#/properties/port
>> +description: HDMI Connector port.
>> +
>> +required:
>> + - port@0
>> + - port@1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - reset-gpios
>> + - vrf12-supply
>> + - vcn33-supply
>> + - vcn18-supply
>> + - interrupts
>> + - ports
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> +i2c {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>
> It's customary to indent DT examples with 4 spaces.
Done
>
>> +
>> + it66121hdmitx: it66121hdmitx@4c {
>> +compatible = "ite,it66121";
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&ite_pins_default>;
>> +vcn33-supply = <&mt6358_vcn33_wifi_reg>;
>> +vcn18-supply = <&mt6358_vcn18_reg>;
>> +vrf12-supply = <&mt6358_vrf12_reg>;
>> +reset-gpios = <&pio 160 1 /* GPIO_ACTIVE_LOW */>;
>
> You can #include the necessary headers at the top of the example, and
> use GPIO_ACTIVE_LOW and IRQ_TYPE_LEVEL_LOW to replace the numerical
> values.
Done
>
> Reviewed-by: Laurent Pinchart
Thanks,
Neil
>
>> +interrupt-parent = <&pio>;
>> +interrupts = <4 8 /* IRQ_TYPE_LEVEL_LOW */>;
>> +reg = <0x4c>;
>> +
>> +ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> +reg = <0>;
>> +it66121_in: endpoint {
>> + bus-width = <12>;
>> + remote-endpoint = <&display_out>;
>> +};
>> + };
>> +
>> + port@1 {
>> +reg = <1>;
>> +hdmi_conn_out: endpoint {
>> + remote-endpoint = <&hdmi_conn_in>;
>> +};
>> + };
>> +};
>> + };
>> +};
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
Le mer. 14 avril 2021 à 8:17, Neil Armstrong a écrit : Hi, Le 13/04/2021 à 22:56, Paul Cercueil a écrit : Hi Neil, I get build failures locally: drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_hw_reset’: drivers/gpu/drm/bridge/ite-it66121.c:242:2: error: implicit declaration of function ‘gpiod_set_value’ [-Werror=implicit-function-declaration] 242 | gpiod_set_value(ctx->gpio_reset, 1); | ^~~ drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_probe’: drivers/gpu/drm/bridge/ite-it66121.c:1016:16: error: implicit declaration of function ‘FIELD_GET’; did you mean ‘FOLL_GET’? [-Werror=implicit-function-declaration] 1016 | revision_id = FIELD_GET(IT66121_REVISION_MASK, device_ids[1]); | ^ | FOLL_GET Nothing difficult to fix, but the includes should be added nonetheless. Exact, I got the CI build failures, I'll fix these for v4. Were you able to test on your setup ? The v2 always forced DDR mode, with this v3, I also switch to normal 24input mode, but totally untested. I will try to find some time today to test after work. -Paul Thanks, Neil Cheers, -Paul Le lun. 12 avril 2021 à 17:46, Neil Armstrong a écrit : From: Phong LE This commit is a simple driver for bridge HMDI it66121. The input format is RBG and there is no color conversion. Audio, HDCP and CEC are not supported yet. Signed-off-by: Phong LE Signed-off-by: Neil Armstrong --- drivers/gpu/drm/bridge/Kconfig |8 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/ite-it66121.c | 1081 ++ 3 files changed, 1090 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index e4110d6ca7b3..6915c38fa459 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC HDMI signals Please say Y if you have such hardware. +config DRM_ITE_IT66121 +tristate "ITE IT66121 HDMI bridge" +depends on OF +select DRM_KMS_HELPER +select REGMAP_I2C +help + Support for ITE IT66121 HDMI bridge. + config DRM_LVDS_CODEC tristate "Transparent LVDS encoders and decoders support" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 86e7acc76f8d..4f725753117c 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o +obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o obj-y += analogix/ obj-y += cadence/ diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c new file mode 100644 index ..73af49b29dfa --- /dev/null +++ b/drivers/gpu/drm/bridge/ite-it66121.c @@ -0,0 +1,1081 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2020 BayLibre, SAS + * Author: Phong LE + * Copyright (C) 2018-2019, Artem Mygaiev + * Copyright (C) 2017, Fresco Logic, Incorporated. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#define IT66121_VENDOR_ID0_REG0x00 +#define IT66121_VENDOR_ID1_REG0x01 +#define IT66121_DEVICE_ID0_REG0x02 +#define IT66121_DEVICE_ID1_REG0x03 + +#define IT66121_VENDOR_ID00x54 +#define IT66121_VENDOR_ID10x49 +#define IT66121_DEVICE_ID00x12 +#define IT66121_DEVICE_ID10x06 +#define IT66121_REVISION_MASKGENMASK(7, 4) +#define IT66121_DEVICE_ID1_MASKGENMASK(3, 0) + +#define IT66121_MASTER_SEL_REG0x10 +#define IT66121_MASTER_SEL_HOSTBIT(0) + +#define IT66121_AFE_DRV_REG0x61 +#define IT66121_AFE_DRV_RSTBIT(4) +#define IT66121_AFE_DRV_PWDBIT(5) + +#define IT66121_INPUT_MODE_REG0x70 +#define IT66121_INPUT_MODE_RGB(0 << 6) +#define IT66121_INPUT_MODE_YUV422BIT(6) +#define IT66121_INPUT_MODE_YUV444(2 << 6) +#define IT66121_INPUT_MODE_CCIR656BIT(4) +#define IT66121_INPUT_MODE_SYNCEMBBIT(3) +#define IT66121_INPUT_MODE_DDRBIT(2) + +#define IT66121_INPUT_CSC_REG0x72 +#define IT66121_INPUT_CSC_ENDITHERBIT(7) +#define IT66121_INPUT_CSC_ENUDFILTERBIT(6) +#define IT66121_INPUT_CSC_DNFREE_GOBIT(5) +#define IT66121_INPUT_CSC_RGB_TO_YUV0x02 +#define IT66121_INPUT_CSC_YUV_TO_RGB0x03 +#define IT66121_INPUT_CSC_NO_CONV0x00 + +#define IT66121_AFE_XP_REG
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
Hi Neil,
On Wed, Apr 14, 2021 at 10:08:46AM +0200, Neil Armstrong wrote:
> On 14/04/2021 10:06, Robert Foss wrote:
> > On Wed, 14 Apr 2021 at 08:13, Neil Armstrong
> > wrote:
> >> Le 13/04/2021 à 22:21, Robert Foss a écrit :
> >>> Hey Neil & Phong,
> >>>
> >>> Thanks for submitting this series!
> >>>
> +
> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
> + .attach = it66121_bridge_attach,
> + .enable = it66121_bridge_enable,
> + .disable = it66121_bridge_disable,
> + .mode_set = it66121_bridge_mode_set,
> + .mode_valid = it66121_bridge_mode_valid,
> + .detect = it66121_bridge_detect,
> + .get_edid = it66121_bridge_get_edid,
> + .atomic_get_output_bus_fmts =
> it66121_bridge_atomic_get_output_bus_fmts,
> + .atomic_get_input_bus_fmts =
> it66121_bridge_atomic_get_input_bus_fmts,
> +};
> >>>
> >>> I would like to see an implementation of HPD, since it is supported by
> >>> the hardware[1] (and required by the documentation). IRQ status bit 0
> >>> seems to be the responsible for notifying us about hot plug detection
> >>> events.
> >>
> >> It's implemented in the IRQ handler with the
> >> IT66121_INT_STATUS1_HPD_STATUS event.
> >
> > I didn't even get that far :)
> >
> > Either way, the HPD support should be exposed in drm_bridge_funcs
> > (.hpd_enable, .hpd_disable (and possibly .hpd_notify)) and
> > drm_bridge.ops (DRM_BRIDGE_OP_HPD).
>
> Indeed I forgot these calls in the NO_CONNECTOR implementation...
For new bridges, you should no implement connector creation, only the
DRM_BRIDGE_ATTACH_NO_CONNECTOR case should be supported.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] drm/amdgpu: Implement mmap as GEM object function
Am 2021-04-14 um 3:44 a.m. schrieb Thomas Zimmermann: > Hi > > Am 07.04.21 um 21:49 schrieb Felix Kuehling: >> On 2021-04-07 3:34 p.m., Felix Kuehling wrote: >>> On 2021-04-07 7:25 a.m., Christian König wrote: + /* + * Don't verify access for KFD BOs. They > don't have a GEM + * object associated with them. + */ + if (bo->kfd_bo) + goto out; >>> Who does the access verification now? >> This is somewhat confusing. >> >> I took this check as-is, including the comment, from amdgpu's >> verify_access function. The verify_access function was called by >> ttm_bo_mmap. It returned 0 and ttm_bo_mmap did the mapping. > This is probably a left-over from when we mapped BOs using /dev/kfd. > We > changed this to use /dev/dri/renderD* a long time ago to fix CPU > mapping > invalidations on memory evictions. I think we can let GEM do the > access > check. Ok, good to know. Thomas can you remove the extra handling in a separate prerequisite patch? If anybody then bisects to this patch we at least know what to do to get it working again. >>> >>> FWIW, I ran KFDTest test with this shortcut removed on current >>> amd-staging-drm-next + my HMM patch series, and it didn't seem to >>> cause any issues. >> >> Wait, I celebrated too soon. I was running the wrong kernel. I do see >> some failures where access is being denied. I need to do more debugging > >> to figure out what's causing that. > > Any news here? I saw the patch at [1], which removes the kfd_bo test. > Can I assume that the series addresses the issue? Yes, that series fixes the problem. I need to pester more people to review it. Regards, Felix > > Best regards > Thomas > > [1] https://patchwork.freedesktop.org/patch/427516/?series=88822&rev=1 > >> >> Regards, >> Felix >> >> >>> >>> Regards, >>> Felix >>> >>> Regards, Christian. >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: remove useless function
On 2021.04.13 14:18:48 +0800, Jiapeng Chong wrote:
> Fix the following clang warning:
>
> drivers/gpu/drm/i915/gvt/gtt.c:590:20: warning: unused function
> 'ppgtt_set_guest_root_entry' [-Wunused-function].
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index 897c007..a01ff44 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -587,12 +587,6 @@ static void _ppgtt_set_root_entry(struct intel_vgpu_mm
> *mm,
> entry, index, false, 0, mm->vgpu);
> }
>
> -static inline void ppgtt_set_guest_root_entry(struct intel_vgpu_mm *mm,
> - struct intel_gvt_gtt_entry *entry, unsigned long index)
> -{
> - _ppgtt_set_root_entry(mm, entry, index, true);
> -}
> -
> static inline void ppgtt_set_shadow_root_entry(struct intel_vgpu_mm *mm,
> struct intel_gvt_gtt_entry *entry, unsigned long index)
> {
> --
Reviewed-by: Zhenyu Wang
Thanks for covering me on this! Queue this up.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2, 0/5] Revert "mailbox: mediatek: remove implementation related to atomic_exec"
On 12/04/2021 17:29, Jassi Brar wrote: > On Mon, Apr 12, 2021 at 6:18 AM Yongqiang Niu > wrote: >> >> This series base linux 5.12-rc2 >> these patches will cause home ui flick when cursor moved, >> there is no fix solution yet, revert these patches first. >> >> change since v1: >> add mtk-gce.txt and dts modification >> >> Yongqiang Niu (5): >> Revert "drm/mediatek: Make sure previous message done or be aborted >> before send" >> Revert "mailbox: mediatek: remove implementation related to >> atomic_exec" >> Revert "dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells value" >> Revert "arm64: dts: mediatek: mt8183: fix gce incorrect mbox-cells >> value" >> arm64: dts: mediatek: mt8183: add gce information for mmsys >> >> .../devicetree/bindings/mailbox/mtk-gce.txt| 2 +- >> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 5 +- >> drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 1 - >> drivers/mailbox/mtk-cmdq-mailbox.c | 80 >> +++--- >> 4 files changed, 76 insertions(+), 12 deletions(-) >> > Please break the patchsets (this and the other 3) into mailbox only > and platform specific ones. > Also, it would help if there are some acked/reviewed by some mtk folks > especially when reverting patches. > I'd prefer to have DT and mailbox patches together as otherwise the burden on me to find out which patches in the driver are needed, and to check if these got accepted, gets higher. Regards, Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/12] drm/vc4: Don't set allow_fb_modifiers explicitly
On Tue, Apr 13, 2021 at 11:49:02AM +0200, Daniel Vetter wrote: > Since > > commit 890880ddfdbe256083170866e49c87618b706ac7 > Author: Paul Kocialkowski > Date: Fri Jan 4 09:56:10 2019 +0100 > > drm: Auto-set allow_fb_modifiers when given modifiers at plane init > > this is done automatically as part of plane init, if drivers set the > modifier list correctly. Which is the case here. > > Signed-off-by: Daniel Vetter > Cc: Eric Anholt > Cc: Maxime Ripard Acked-by: Maxime Ripard Thanks! Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/12] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Tue, Apr 13, 2021 at 11:49:03AM +0200, Daniel Vetter wrote: > It's very confusing for userspace to have to deal with inconsistencies > here, and some drivers screwed this up a bit. Most just ommitted the > format list when they meant to say that only linear modifier is > allowed, but some also meant that only implied modifiers are > acceptable (because actually none of the planes registered supported > modifiers). > > Now that this is all done consistently across all drivers, document > the rules and enforce it in the drm core. > > Cc: Pekka Paalanen > Signed-off-by: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter Acked-by: Maxime Ripard Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
It's very confusing for userspace to have to deal with inconsistencies
here, and some drivers screwed this up a bit. Most just ommitted the
format list when they meant to say that only linear modifier is
allowed, but some also meant that only implied modifiers are
acceptable (because actually none of the planes registered supported
modifiers).
Now that this is all done consistently across all drivers, document
the rules and enforce it in the drm core.
v2:
- Make the capability a link (Simon)
- Note that all is lost before 5.1.
Acked-by: Maxime Ripard
Cc: Simon Ser
Reviewed-by: Lucas Stach
Cc: Pekka Paalanen
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 18 +-
include/drm/drm_mode_config.h | 2 ++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 0dd43882fe7c..20c7a1665414 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -128,6 +128,13 @@
* pairs supported by this plane. The blob is a struct
* drm_format_modifier_blob. Without this property the plane doesn't
* support buffers with modifiers. Userspace cannot change this property.
+ *
+ * Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
+ * capability for general modifier support. If this flag is set then every
+ * plane will have the IN_FORMATS property, even when it only supports
+ * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
+ * various bugs in this area with inconsistencies between the capability
+ * flag and per-plane properties.
*/
static unsigned int drm_num_planes(struct drm_device *dev)
@@ -277,8 +284,14 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
format_modifier_count++;
}
- if (format_modifier_count)
+ /* autoset the cap and check for consistency across all planes */
+ if (format_modifier_count) {
+ WARN_ON(!config->allow_fb_modifiers &&
+ !list_empty(&config->plane_list));
config->allow_fb_modifiers = true;
+ } else {
+ WARN_ON(config->allow_fb_modifiers);
+ }
plane->modifier_count = format_modifier_count;
plane->modifiers = kmalloc_array(format_modifier_count,
@@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device
*dev,
* drm_universal_plane_init() to let the DRM managed resource infrastructure
* take care of cleanup and deallocation.
*
+ * Drivers supporting modifiers must set @format_modifiers on all their planes,
+ * even those that only support DRM_FORMAT_MOD_LINEAR.
+ *
* Returns:
* Zero on success, error code on failure.
*/
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index ab424ddd7665..1ddf7783fdf7 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -909,6 +909,8 @@ struct drm_mode_config {
* @allow_fb_modifiers:
*
* Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
+* Note that drivers should not set this directly, it is automatically
+* set in drm_universal_plane_init().
*
* IMPORTANT:
*
--
2.31.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/12] drm/imx: Don't set allow_fb_modifiers explicitly
On Wed, Apr 14, 2021 at 10:24:22AM +0800, Liu Ying wrote: > Hi Daniel, > > On Tue, 2021-04-13 at 16:14 +0200, Lucas Stach wrote: > > Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter: > > > On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote: > > > > Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter: > > > > > Since > > > > > > > > > > commit 890880ddfdbe256083170866e49c87618b706ac7 > > > > > Author: Paul Kocialkowski > > > > > Date: Fri Jan 4 09:56:10 2019 +0100 > > > > > > > > > > drm: Auto-set allow_fb_modifiers when given modifiers at plane > > > > > init > > > > > > > > > > this is done automatically as part of plane init, if drivers set the > > > > > modifier list correctly. Which is the case here. > > > > > > > > > > This one actually set it twice on top of what drm_plane_init does, so > > > > > double-redundant! > > > > > > > > That's not true. imx-dcss and imx-drm are two totally separate drivers. > > > > Maybe we should move imx-drm into its own ipuv3 directory one day to > > > > make this more clear. Change is still correct, though. > > > > > > Hm I greeped for drm_universal_plane_init and didn't find anythinf for the > > > imx main driver ... where are planes set up for that? Need to review that > > > they have the modifiers listed in all cases. > > > > That's in drivers/gpu/drm/imx/ipuv3-plane.c and modifiers are always > > set on plane init. Oh I didn't grep for the new drmm_universal_plane_alloc. Thanks for pointing this out. > > > > Regards, > > Lucas > > > > > > Reviewed-by: Lucas Stach > > > > > > > > > Signed-off-by: Daniel Vetter > > > > > Cc: Philipp Zabel > > > > > Cc: Shawn Guo > > > > > Cc: Sascha Hauer > > > > > Cc: Pengutronix Kernel Team > > > > > Cc: Fabio Estevam > > > > > Cc: NXP Linux Team > > > > > Cc: linux-arm-ker...@lists.infradead.org > > > > > --- > > > > > drivers/gpu/drm/imx/dcss/dcss-kms.c | 1 - > > > > > drivers/gpu/drm/imx/imx-drm-core.c | 1 - > > Nit: Since this patch touches two totally separate drivers(imx-dcss and > imx-drm), it would be good to split it into two patches. I think if you expect that, then you need to move the imx-drm driver into a subdirectory like dcss. And like e.g. drm/msm works too. As-is this is just kinda confusing for people not involved in imx. -Daniel > > Thanks, > Liu Ying > > > > > > 2 files changed, 2 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > > > b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > > > index b549ce5e7607..37ae68a7fba5 100644 > > > > > --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > > > +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c > > > > > @@ -52,7 +52,6 @@ static void dcss_kms_mode_config_init(struct > > > > > dcss_kms_dev *kms) > > > > > config->min_height = 1; > > > > > config->max_width = 4096; > > > > > config->max_height = 4096; > > > > > - config->allow_fb_modifiers = true; > > > > > config->normalize_zpos = true; > > > > > > > > > > > > > > > > > > > > > > > > > config->funcs = &dcss_drm_mode_config_funcs; > > > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > > > > b/drivers/gpu/drm/imx/imx-drm-core.c > > > > > index 2ded8e4f32d0..8be4edaec958 100644 > > > > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > > > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > > > > @@ -209,7 +209,6 @@ static int imx_drm_bind(struct device *dev) > > > > > drm->mode_config.max_height = 4096; > > > > > drm->mode_config.funcs = &imx_drm_mode_config_funcs; > > > > > drm->mode_config.helper_private = &imx_drm_mode_config_helpers; > > > > > - drm->mode_config.allow_fb_modifiers = true; > > > > > drm->mode_config.normalize_zpos = true; > > > > > > > > > > > > > > > > > > > > > > > > > ret = drmm_mode_config_init(drm); > > > > > -- 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 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
On Wed, Apr 14, 2021 at 02:46:20AM -0400, Felix Kuehling wrote:
> Pages in SG BOs were not allocated by TTM. So don't count them against
> TTM's pages limit.
>
> Signed-off-by: Felix Kuehling
This sounds like papering over the lack of shrinker in ttm. Do we
guarantee that someone else has already accounted these buffers against
the ttm memory hard-limit anywhere? If not I think this needs to wait for
the shrinker work to get solid, since fixing the double-accounting for
this is probably not worth it.
-Daniel
> ---
> drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index 5d8820725b75..e8b8c3257392 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
> if (ttm_tt_is_populated(ttm))
> return 0;
>
> - atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
> - if (bdev->pool.use_dma32)
> - atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
> + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> + atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
> + if (bdev->pool.use_dma32)
> + atomic_long_add(ttm->num_pages,
> + &ttm_dma32_pages_allocated);
> + }
>
> while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit ||
> atomic_long_read(&ttm_dma32_pages_allocated) >
> @@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
> return 0;
>
> error:
> - atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> - if (bdev->pool.use_dma32)
> - atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
> + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> + atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> + if (bdev->pool.use_dma32)
> + atomic_long_sub(ttm->num_pages,
> + &ttm_dma32_pages_allocated);
> + }
> return ret;
> }
> EXPORT_SYMBOL(ttm_tt_populate);
> @@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev, struct
> ttm_tt *ttm)
> else
> ttm_pool_free(&bdev->pool, ttm);
>
> - atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> - if (bdev->pool.use_dma32)
> - atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
> + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> + atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> + if (bdev->pool.use_dma32)
> + atomic_long_sub(ttm->num_pages,
> + &ttm_dma32_pages_allocated);
> + }
>
> ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_POPULATED;
> }
> --
> 2.31.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
> Am 14.04.21 um 08:48 schrieb Felix Kuehling:
> > Pages in SG BOs were not allocated by TTM. So don't count them against
> > TTM's pages limit.
> >
> > Signed-off-by: Felix Kuehling
>
> Reviewed-by: Christian König
>
> Going to pick that one up for inclusion in drm-misc-next.
See my other email, but why do we need this? A bit more explanation is imo
needed here at least, since we still need to guarantee that allocations
don't over the limit in total for all gpu buffers together. At least until
the shrinker has landed.
And this here just opens up the barn door without any explanation why it's
ok.
-Daniel
>
> Regards,
> Christian.
>
> > ---
> > drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
> > 1 file changed, 18 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> > index 5d8820725b75..e8b8c3257392 100644
> > --- a/drivers/gpu/drm/ttm/ttm_tt.c
> > +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> > @@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
> > if (ttm_tt_is_populated(ttm))
> > return 0;
> > - atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
> > - if (bdev->pool.use_dma32)
> > - atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
> > + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> > + atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
> > + if (bdev->pool.use_dma32)
> > + atomic_long_add(ttm->num_pages,
> > + &ttm_dma32_pages_allocated);
> > + }
> > while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit ||
> >atomic_long_read(&ttm_dma32_pages_allocated) >
> > @@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
> > return 0;
> > error:
> > - atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > - if (bdev->pool.use_dma32)
> > - atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
> > + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> > + atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > + if (bdev->pool.use_dma32)
> > + atomic_long_sub(ttm->num_pages,
> > + &ttm_dma32_pages_allocated);
> > + }
> > return ret;
> > }
> > EXPORT_SYMBOL(ttm_tt_populate);
> > @@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev, struct
> > ttm_tt *ttm)
> > else
> > ttm_pool_free(&bdev->pool, ttm);
> > - atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > - if (bdev->pool.use_dma32)
> > - atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
> > + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> > + atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > + if (bdev->pool.use_dma32)
> > + atomic_long_sub(ttm->num_pages,
> > + &ttm_dma32_pages_allocated);
> > + }
> > ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_POPULATED;
> > }
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
Am 14.04.21 um 11:15 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
Am 14.04.21 um 08:48 schrieb Felix Kuehling:
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
Going to pick that one up for inclusion in drm-misc-next.
See my other email, but why do we need this? A bit more explanation is imo
needed here at least, since we still need to guarantee that allocations
don't over the limit in total for all gpu buffers together. At least until
the shrinker has landed.
And this here just opens up the barn door without any explanation why it's
ok.
The SG based BOs might not even be backed by pages. E.g. exported VRAM.
So either they are exported by a driver which should have accounted for
the allocation, exported by TTM which already did the accounting or
doesn't even point to pages at all.
This is really a bug fix to recreate the behavior we had before moving
the accounting to this place.
Christian.
-Daniel
Regards,
Christian.
---
drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5d8820725b75..e8b8c3257392 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
if (ttm_tt_is_populated(ttm))
return 0;
- atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_add(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit ||
atomic_long_read(&ttm_dma32_pages_allocated) >
@@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
return 0;
error:
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
return ret;
}
EXPORT_SYMBOL(ttm_tt_populate);
@@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev, struct
ttm_tt *ttm)
else
ttm_pool_free(&bdev->pool, ttm);
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_POPULATED;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cchristian.koenig%40amd.com%7C3075d7fd16644322a13608d8ff25d59b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637539885255795187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KOnHA1CbNFjjMZR2rgHmGkH%2B7C84YCtA6u9V1wBAay4%3D&reserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v3)
On Wed, Apr 14, 2021 at 06:36:55AM +, Zhang, Tina wrote: > Hi Gerd, > > Speaking of the modifier, we notice that the virtio-gpu driver's > mode_config.allow_fb_modifiers = false, which means virtio-gpu doesn't > support modifier. With mode_config.allow_fb_modifiers=false, the DRM > Modifier API would fail. > > So, do you know if there is any concern about letting virito-gpu allow > modifiers? Thanks. Well, virtio-gpu must also provide a list of modifiers then. We need some way for virtio-gpu to figure which modifiers are supported by the host and which are not. Otherwise we could list LINEAR only which doesn't buy us much ;) Not sure whenever virglrenderer allows that already (via VIRGL_CCMD*QUERY* or via virgl caps). If not we could define a new modifiers capability for that, which could then be used for both virgl and non-virgl mode. take care, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/4] drm/vkms: init plane using drmm_universal_plane_alloc
On Tue, Apr 13, 2021 at 04:50:08AM -0300, Melissa Wen wrote:
> By using drmm_universal_plane_alloc instead of
> drm_universal_plane_init, we let the DRM infrastructure handles
> resource allocation and cleanup. We can also get rid of some
> code repetitions for plane cleanup, improving code maintainability
> in vkms.
>
> Signed-off-by: Melissa Wen
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_drv.h| 8 ++--
> drivers/gpu/drm/vkms/vkms_output.c | 19 +--
> drivers/gpu/drm/vkms/vkms_plane.c | 29 +++--
> 3 files changed, 22 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 35540c7c4416..70fb79621617 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -37,6 +37,10 @@ struct vkms_plane_state {
> struct vkms_composer *composer;
> };
>
> +struct vkms_plane {
> + struct drm_plane base;
> +};
> +
> /**
> * vkms_crtc_state - Driver specific CRTC state
> * @base: base CRTC state
> @@ -114,8 +118,8 @@ int vkms_crtc_init(struct drm_device *dev, struct
> drm_crtc *crtc,
>
> int vkms_output_init(struct vkms_device *vkmsdev, int index);
>
> -struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> - enum drm_plane_type type, int index);
> +struct vkms_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> +enum drm_plane_type type, int index);
>
> /* CRC Support */
> const char *const *vkms_get_crc_sources(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/vkms/vkms_output.c
> b/drivers/gpu/drm/vkms/vkms_output.c
> index f5f6f15c362c..6979fbc7f821 100644
> --- a/drivers/gpu/drm/vkms/vkms_output.c
> +++ b/drivers/gpu/drm/vkms/vkms_output.c
> @@ -39,7 +39,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
> struct drm_connector *connector = &output->connector;
> struct drm_encoder *encoder = &output->encoder;
> struct drm_crtc *crtc = &output->crtc;
> - struct drm_plane *primary, *cursor = NULL;
> + struct vkms_plane *primary, *cursor = NULL;
> int ret;
> int writeback;
>
> @@ -49,15 +49,13 @@ int vkms_output_init(struct vkms_device *vkmsdev, int
> index)
>
> if (vkmsdev->config->cursor) {
> cursor = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_CURSOR, index);
> - if (IS_ERR(cursor)) {
> - ret = PTR_ERR(cursor);
> - goto err_cursor;
> - }
> + if (IS_ERR(cursor))
> + return PTR_ERR(cursor);
> }
>
> - ret = vkms_crtc_init(dev, crtc, primary, cursor);
> + ret = vkms_crtc_init(dev, crtc, &primary->base, &cursor->base);
> if (ret)
> - goto err_crtc;
> + return ret;
>
> ret = drm_connector_init(dev, connector, &vkms_connector_funcs,
>DRM_MODE_CONNECTOR_VIRTUAL);
> @@ -100,12 +98,5 @@ int vkms_output_init(struct vkms_device *vkmsdev, int
> index)
> err_connector:
> drm_crtc_cleanup(crtc);
>
> -err_crtc:
> - if (vkmsdev->config->cursor)
> - drm_plane_cleanup(cursor);
> -
> -err_cursor:
> - drm_plane_cleanup(primary);
> -
> return ret;
> }
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 6d310d31b75d..135140f8e87a 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -86,7 +86,6 @@ static void vkms_plane_reset(struct drm_plane *plane)
> static const struct drm_plane_funcs vkms_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> - .destroy= drm_plane_cleanup,
> .reset = vkms_plane_reset,
> .atomic_duplicate_state = vkms_plane_duplicate_state,
> .atomic_destroy_state = vkms_plane_destroy_state,
> @@ -191,18 +190,14 @@ static const struct drm_plane_helper_funcs
> vkms_primary_helper_funcs = {
> .cleanup_fb = vkms_cleanup_fb,
> };
>
> -struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> - enum drm_plane_type type, int index)
> +struct vkms_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> +enum drm_plane_type type, int index)
> {
> struct drm_device *dev = &vkmsdev->drm;
> const struct drm_plane_helper_funcs *funcs;
> - struct drm_plane *plane;
> + struct vkms_plane *plane;
> const u32 *formats;
> - int ret, nformats;
> -
> - plane = kzalloc(sizeof(*plane), GFP_KERNEL);
> - if (!plane)
> - return ERR_PTR(-ENOMEM);
> + int nformats;
>
> if (type == DRM_PLANE_TYPE_CURSOR) {
> formats = vkms_cursor_formats;
> @@ -214,16 +209,14 @@ struct drm_plane *vkms_pla
Re: [PATCH v3 2/4] drm/vkms: rename cursor to plane on ops of planes composition
On Tue, Apr 13, 2021 at 04:53:43AM -0300, Melissa Wen wrote:
> Generalize variables and function names used for planes composition
> (from cursor to plane), since we will reuse the operations for both
> cursor and overlay types.
>
> No functional change.
>
> Signed-off-by: Melissa Wen
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 66c6842d70db..be8f1d33c645 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -125,26 +125,26 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> }
> }
>
> -static void compose_cursor(struct vkms_composer *cursor_composer,
> -struct vkms_composer *primary_composer,
> +static void compose_planes(struct vkms_composer *primary_composer,
> +struct vkms_composer *plane_composer,
> void *vaddr_out)
> {
> - struct drm_gem_object *cursor_obj;
> - struct drm_gem_shmem_object *cursor_shmem_obj;
> + struct drm_gem_object *plane_obj;
> + struct drm_gem_shmem_object *plane_shmem_obj;
>
> - cursor_obj = drm_gem_fb_get_obj(&cursor_composer->fb, 0);
> - cursor_shmem_obj = to_drm_gem_shmem_obj(cursor_obj);
> + plane_obj = drm_gem_fb_get_obj(&plane_composer->fb, 0);
> + plane_shmem_obj = to_drm_gem_shmem_obj(plane_obj);
>
> - if (WARN_ON(!cursor_shmem_obj->vaddr))
> + if (WARN_ON(!plane_shmem_obj->vaddr))
> return;
>
> - blend(vaddr_out, cursor_shmem_obj->vaddr,
> - primary_composer, cursor_composer);
> + blend(vaddr_out, plane_shmem_obj->vaddr,
> + primary_composer, plane_composer);
> }
>
> -static int compose_planes(void **vaddr_out,
> - struct vkms_composer *primary_composer,
> - struct vkms_composer *cursor_composer)
> +static int composite(void **vaddr_out,
> + struct vkms_composer *primary_composer,
> + struct vkms_composer *cursor_composer)
> {
> struct drm_framebuffer *fb = &primary_composer->fb;
> struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> @@ -164,7 +164,7 @@ static int compose_planes(void **vaddr_out,
> memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
>
> if (cursor_composer)
> - compose_cursor(cursor_composer, primary_composer, *vaddr_out);
> + compose_planes(primary_composer, cursor_composer, *vaddr_out);
>
> return 0;
> }
> @@ -222,7 +222,7 @@ void vkms_composer_worker(struct work_struct *work)
> if (wb_pending)
> vaddr_out = crtc_state->active_writeback;
>
> - ret = compose_planes(&vaddr_out, primary_composer, cursor_composer);
> + ret = composite(&vaddr_out, primary_composer, cursor_composer);
> if (ret) {
> if (ret == -EINVAL && !wb_pending)
> kfree(vaddr_out);
> --
> 2.30.2
>
--
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 4/7] drm/ttm: move the page_alignment into the BO
On Tue, 13 Apr 2021 at 14:53, Christian König
wrote:
>
> The alignment is a constant property and shouldn't change.
>
> Signed-off-by: Christian König
What is page alignment here? Is it just for HW restrictions, say if it
requires 64K pages with the same physical alignment for VRAM or
something? But then wouldn't it make more sense for that to remain as
a property of the resource, and not the object? Or am I
misunderstanding something?
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 +++--
> drivers/gpu/drm/radeon/radeon_object.h | 2 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 3 +--
> drivers/gpu/drm/ttm/ttm_range_manager.c | 5 ++---
> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 15 ---
> include/drm/ttm/ttm_bo_api.h | 1 +
> include/drm/ttm/ttm_resource.h | 1 -
> 10 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index b443907afcea..f1c397be383d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -763,7 +763,7 @@ int amdgpu_gem_op_ioctl(struct drm_device *dev, void
> *data,
> void __user *out = u64_to_user_ptr(args->value);
>
> info.bo_size = robj->tbo.base.size;
> - info.alignment = robj->tbo.mem.page_alignment << PAGE_SHIFT;
> + info.alignment = robj->tbo.page_alignment << PAGE_SHIFT;
> info.domains = robj->preferred_domains;
> info.domain_flags = robj->flags;
> amdgpu_bo_unreserve(robj);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> index 8860545344c7..c026972ca9a1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> @@ -136,7 +136,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
> *man,
>
> spin_lock(&mgr->lock);
> r = drm_mm_insert_node_in_range(&mgr->mm, &node->node, mem->num_pages,
> - mem->page_alignment, 0, place->fpfn,
> + tbo->page_alignment, 0, place->fpfn,
> place->lpfn, DRM_MM_INSERT_BEST);
> spin_unlock(&mgr->lock);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> index 9ac37569823f..ae4a68db87c0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> @@ -184,7 +184,7 @@ static inline unsigned amdgpu_bo_ngpu_pages(struct
> amdgpu_bo *bo)
>
> static inline unsigned amdgpu_bo_gpu_page_alignment(struct amdgpu_bo *bo)
> {
> - return (bo->tbo.mem.page_alignment << PAGE_SHIFT) /
> AMDGPU_GPU_PAGE_SIZE;
> + return (bo->tbo.page_alignment << PAGE_SHIFT) / AMDGPU_GPU_PAGE_SIZE;
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index 1fc7ec0b8915..38b1995d0d6c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -392,7 +392,8 @@ static int amdgpu_vram_mgr_new(struct
> ttm_resource_manager *man,
> /* default to 2MB */
> pages_per_node = (2UL << (20UL - PAGE_SHIFT));
> #endif
> - pages_per_node = max((uint32_t)pages_per_node,
> mem->page_alignment);
> + pages_per_node = max((uint32_t)pages_per_node,
> +tbo->page_alignment);
> num_nodes = DIV_ROUND_UP(mem->num_pages, pages_per_node);
> }
>
> @@ -431,7 +432,7 @@ static int amdgpu_vram_mgr_new(struct
> ttm_resource_manager *man,
>
> for (; pages_left; ++i) {
> unsigned long pages = min(pages_left, pages_per_node);
> - uint32_t alignment = mem->page_alignment;
> + uint32_t alignment = tbo->page_alignment;
>
> if (pages == pages_per_node)
> alignment = pages_per_node;
> diff --git a/drivers/gpu/drm/radeon/radeon_object.h
> b/drivers/gpu/drm/radeon/radeon_object.h
> index 9896d8231fe5..fd4116bdde0f 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.h
> +++ b/drivers/gpu/drm/radeon/radeon_object.h
> @@ -119,7 +119,7 @@ static inline unsigned radeon_bo_ngpu_pages(struct
> radeon_bo *bo)
>
> static inline unsigned radeon_bo_gpu_page_alignment(struct radeon_bo *bo)
> {
> - return (bo->tbo.mem.page_alignment << PAGE_SHIFT) /
> RADEON_GPU_PAGE_SIZE;
> + return (bo->tbo.page_alignment << PAGE_SHIFT) / RADEON_GPU_PAGE_SIZE;
> }
>
> /**
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.
Re: [PATCH v3 3/4] drm/vkms: add XRGB planes composition
On Tue, Apr 13, 2021 at 04:54:52AM -0300, Melissa Wen wrote:
> Add support for composing XRGB888 planes in addition to the
> ARGB format. In the case of an XRGB plane at the top, the
> composition consists of just copying the RGB values of a
> pixel from src to dst, without the need for alpha blending
> operations for each pixel.
>
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 22 ++
> drivers/gpu/drm/vkms/vkms_plane.c| 7 ---
> 2 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index be8f1d33c645..7fe1fdb3af39 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -4,6 +4,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -76,6 +77,11 @@ static void alpha_blending(const u8 *argb_src, u8
> *argb_dst)
> argb_dst[3] = 0xFF;
> }
>
> +static void x_blending(const u8 *xrgb_src, u8 *xrgb_dst)
> +{
> + memcpy(xrgb_dst, xrgb_src, sizeof(u8) * 3);
Don't we need to clear the alpha channel, or is that done already when we
allocate the buffer? Looking at the code we have I think we have a few
more bugs there to fix.
I also just realized that we don't support when the primary plane isn't
exactly matching our output size. So that's another thing to maybe fix -
with your new x_blending here what we could do is essentially blend the
primary plane onto the black background (allocated with all zeros) like we
blend the other planes.
Minimally I'd add a comment above that we rely on alpha being cleared in
the target buffer or something like that for stable crc values.
Anyway, work for another patch set.
> +}
> +
> /**
> * blend - blend value at vaddr_src with value at vaddr_dst
> * @vaddr_dst: destination address
> @@ -91,7 +97,8 @@ static void alpha_blending(const u8 *argb_src, u8 *argb_dst)
> */
> static void blend(void *vaddr_dst, void *vaddr_src,
> struct vkms_composer *dst_composer,
> - struct vkms_composer *src_composer)
> + struct vkms_composer *src_composer,
> + void (*pixel_blend)(const u8 *, u8 *))
> {
> int i, j, j_dst, i_dst;
> int offset_src, offset_dst;
> @@ -119,7 +126,7 @@ static void blend(void *vaddr_dst, void *vaddr_src,
>
> pixel_src = (u8 *)(vaddr_src + offset_src);
> pixel_dst = (u8 *)(vaddr_dst + offset_dst);
> - alpha_blending(pixel_src, pixel_dst);
> + pixel_blend(pixel_src, pixel_dst);
Since it's all one file, did you check whether gcc inlines the two
functions calls here? If we do actual function calls for each blend it's
going to be a lot slower. Maybe worth checking, and perhaps we need to
throw some ineline hints (like always_inline or something like that) on
both the blend function and the alpha_blending and x_blending helpers.
Cursor is generally tiny, but when we start "blending" the primary plane
into the black background, then performance really starts to matter.
Anyway that's all stuff for later tuning.
Reviewed-by: Daniel Vetter
> }
> i_dst++;
> }
> @@ -131,6 +138,8 @@ static void compose_planes(struct vkms_composer
> *primary_composer,
> {
> struct drm_gem_object *plane_obj;
> struct drm_gem_shmem_object *plane_shmem_obj;
> + struct drm_framebuffer *fb = &plane_composer->fb;
> + void (*pixel_blend)(const u8 *p_src, u8 *p_dst);
>
> plane_obj = drm_gem_fb_get_obj(&plane_composer->fb, 0);
> plane_shmem_obj = to_drm_gem_shmem_obj(plane_obj);
> @@ -138,8 +147,13 @@ static void compose_planes(struct vkms_composer
> *primary_composer,
> if (WARN_ON(!plane_shmem_obj->vaddr))
> return;
>
> - blend(vaddr_out, plane_shmem_obj->vaddr,
> - primary_composer, plane_composer);
> + if (fb->format->format == DRM_FORMAT_ARGB)
> + pixel_blend = &alpha_blending;
> + else
> + pixel_blend = &x_blending;
> +
> + blend(vaddr_out, plane_shmem_obj->vaddr, primary_composer,
> + plane_composer, pixel_blend);
> }
>
> static int composite(void **vaddr_out,
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 135140f8e87a..da4251aff67f 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -16,8 +16,9 @@ static const u32 vkms_formats[] = {
> DRM_FORMAT_XRGB,
> };
>
> -static const u32 vkms_cursor_formats[] = {
> +static const u32 vkms_plane_formats[] = {
> DRM_FORMAT_ARGB,
> + DRM_FORMAT_XRGB
> };
>
> static struct drm_plane_state *
> @@ -200,8 +201,8 @@ struct vkms_plane *vkms_plane_init(struct vkms_device
> *vkmsdev,
> int nformats;
>
> if (type == DRM_PLANE_TYPE_CURSOR) {
> - format
Re: [PATCH 4/7] drm/ttm: move the page_alignment into the BO
Am 14.04.21 um 11:46 schrieb Matthew Auld:
On Tue, 13 Apr 2021 at 14:53, Christian König
wrote:
The alignment is a constant property and shouldn't change.
Signed-off-by: Christian König
What is page alignment here? Is it just for HW restrictions, say if it
requires 64K pages with the same physical alignment for VRAM or
something? But then wouldn't it make more sense for that to remain as
a property of the resource, and not the object? Or am I
misunderstanding something?
The page_alignment (bad name btw) is the physical base alignment of the
allocation.
I want to make resource allocation optional in the mid term, and this is
the only information we currently don't have otherwise.
The most sense would it make in the placement, since it is really an
allocation restriction. But I would need to rework the placement
handling in amdgpu for this to be consistent first.
Regards,
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 +++--
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 3 +--
drivers/gpu/drm/ttm/ttm_range_manager.c | 5 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 15 ---
include/drm/ttm/ttm_bo_api.h | 1 +
include/drm/ttm/ttm_resource.h | 1 -
10 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index b443907afcea..f1c397be383d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -763,7 +763,7 @@ int amdgpu_gem_op_ioctl(struct drm_device *dev, void *data,
void __user *out = u64_to_user_ptr(args->value);
info.bo_size = robj->tbo.base.size;
- info.alignment = robj->tbo.mem.page_alignment << PAGE_SHIFT;
+ info.alignment = robj->tbo.page_alignment << PAGE_SHIFT;
info.domains = robj->preferred_domains;
info.domain_flags = robj->flags;
amdgpu_bo_unreserve(robj);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 8860545344c7..c026972ca9a1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -136,7 +136,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
spin_lock(&mgr->lock);
r = drm_mm_insert_node_in_range(&mgr->mm, &node->node, mem->num_pages,
- mem->page_alignment, 0, place->fpfn,
+ tbo->page_alignment, 0, place->fpfn,
place->lpfn, DRM_MM_INSERT_BEST);
spin_unlock(&mgr->lock);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 9ac37569823f..ae4a68db87c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -184,7 +184,7 @@ static inline unsigned amdgpu_bo_ngpu_pages(struct
amdgpu_bo *bo)
static inline unsigned amdgpu_bo_gpu_page_alignment(struct amdgpu_bo *bo)
{
- return (bo->tbo.mem.page_alignment << PAGE_SHIFT) /
AMDGPU_GPU_PAGE_SIZE;
+ return (bo->tbo.page_alignment << PAGE_SHIFT) / AMDGPU_GPU_PAGE_SIZE;
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 1fc7ec0b8915..38b1995d0d6c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -392,7 +392,8 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager
*man,
/* default to 2MB */
pages_per_node = (2UL << (20UL - PAGE_SHIFT));
#endif
- pages_per_node = max((uint32_t)pages_per_node,
mem->page_alignment);
+ pages_per_node = max((uint32_t)pages_per_node,
+tbo->page_alignment);
num_nodes = DIV_ROUND_UP(mem->num_pages, pages_per_node);
}
@@ -431,7 +432,7 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager
*man,
for (; pages_left; ++i) {
unsigned long pages = min(pages_left, pages_per_node);
- uint32_t alignment = mem->page_alignment;
+ uint32_t alignment = tbo->page_alignment;
if (pages == pages_per_node)
alignment = pages_per_node;
diff --git a/drivers/gpu/drm/radeon/radeon_object.h
b/drivers/gpu/drm/radeon/radeon_object.h
index 9896d8231fe5..fd4116bdde0f 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -119,7 +119,7 @@ static inline unsigned radeon_bo_ngpu_pages(st
Re: [PATCH v3 4/4] drm/vkms: add overlay support
On Tue, Apr 13, 2021 at 04:56:02AM -0300, Melissa Wen wrote:
> Add support to overlay plane, in addition to primary and cursor
> planes. In this approach, the plane composition still requires an
> active primary plane and planes are composed associatively in the
> order: (primary <- overlay) <- cursor
>
> It enables to run the following IGT tests successfully:
> - kms_plane_cursor:
> - pipe-A-[overlay, primary, viewport]-size-[64, 128, 256]
> - kms_atomic:
> - plane-overlay-legacy
> and preserves the successful execution of kms_cursor_crc,
> kms_writeback and kms_flip
>
> Signed-off-by: Melissa Wen
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 27 +--
> drivers/gpu/drm/vkms/vkms_drv.c | 5 +
> drivers/gpu/drm/vkms/vkms_drv.h | 1 +
> drivers/gpu/drm/vkms/vkms_output.c | 11 ++-
> drivers/gpu/drm/vkms/vkms_plane.c| 14 +++---
> 5 files changed, 44 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 7fe1fdb3af39..73ce1d381737 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -158,11 +158,12 @@ static void compose_planes(struct vkms_composer
> *primary_composer,
>
> static int composite(void **vaddr_out,
Ok this was done in patch 2, but I think the names here need a bit
improvement. composite is a noun, not a verb, but this function does
stuff, so we need a verb. Also I feel like compose_planes (i.e. the
original name) reflects better what it actually does.
>struct vkms_composer *primary_composer,
> - struct vkms_composer *cursor_composer)
> + struct vkms_crtc_state *crtc_state)
> {
> struct drm_framebuffer *fb = &primary_composer->fb;
> struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> struct drm_gem_shmem_object *shmem_obj = to_drm_gem_shmem_obj(gem_obj);
> + int i;
>
> if (!*vaddr_out) {
> *vaddr_out = kzalloc(shmem_obj->base.size, GFP_KERNEL);
> @@ -177,8 +178,14 @@ static int composite(void **vaddr_out,
>
> memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
>
> - if (cursor_composer)
> - compose_planes(primary_composer, cursor_composer, *vaddr_out);
> + /* If there are other planes besides primary, we consider the active
> + * planes should be in z-order and compose them associatively:
> + * ((primary <- overlay) <- cursor)
> + */
> + for (i = 1; i < crtc_state->num_active_planes; i++)
> + compose_planes(primary_composer,
Ofc that then clashes with compose_planes here, but this function only
composes a single plane. So the plural plane_s_ is kinda wrong, and we
could just call this function compose_plane. I think with that bikeshed
this reads a bit better. So please adjust that in patch 2 (keep the r-b)
and this here also lgtm.
Reviewed-by: Daniel Vetter
> +crtc_state->active_planes[i]->composer,
> +*vaddr_out);
>
> return 0;
> }
> @@ -200,7 +207,7 @@ void vkms_composer_worker(struct work_struct *work)
> struct drm_crtc *crtc = crtc_state->base.crtc;
> struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> struct vkms_composer *primary_composer = NULL;
> - struct vkms_composer *cursor_composer = NULL;
> + struct vkms_plane_state *act_plane = NULL;
> bool crc_pending, wb_pending;
> void *vaddr_out = NULL;
> u32 crc32 = 0;
> @@ -224,11 +231,11 @@ void vkms_composer_worker(struct work_struct *work)
> if (!crc_pending)
> return;
>
> - if (crtc_state->num_active_planes >= 1)
> - primary_composer = crtc_state->active_planes[0]->composer;
> -
> - if (crtc_state->num_active_planes == 2)
> - cursor_composer = crtc_state->active_planes[1]->composer;
> + if (crtc_state->num_active_planes >= 1) {
> + act_plane = crtc_state->active_planes[0];
> + if (act_plane->base.plane->type == DRM_PLANE_TYPE_PRIMARY)
> + primary_composer = act_plane->composer;
> + }
>
> if (!primary_composer)
> return;
> @@ -236,7 +243,7 @@ void vkms_composer_worker(struct work_struct *work)
> if (wb_pending)
> vaddr_out = crtc_state->active_writeback;
>
> - ret = composite(&vaddr_out, primary_composer, cursor_composer);
> + ret = composite(&vaddr_out, primary_composer, crtc_state);
> if (ret) {
> if (ret == -EINVAL && !wb_pending)
> kfree(vaddr_out);
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 2173b82606f6..027ffe759440 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -44,6 +44,10 @@ static bool enable_writeback = true;
> module_param_named(enable_writeback, en
Re: [PATCH 5/7] drm/ttm: add ttm_sys_manager
On Tue, 13 Apr 2021 at 14:53, Christian König
wrote:
>
> Add a separate manager for the system domain and make function tables
> mandatory.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/Makefile | 2 +-
> drivers/gpu/drm/ttm/ttm_device.c | 17 +-
> drivers/gpu/drm/ttm/ttm_module.h | 3 ++
> drivers/gpu/drm/ttm/ttm_resource.c| 10 ++
> drivers/gpu/drm/ttm/ttm_sys_manager.c | 46 +++
> 5 files changed, 53 insertions(+), 25 deletions(-)
> create mode 100644 drivers/gpu/drm/ttm/ttm_sys_manager.c
>
> diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
> index 40e5e9da7953..f906b22959cf 100644
> --- a/drivers/gpu/drm/ttm/Makefile
> +++ b/drivers/gpu/drm/ttm/Makefile
> @@ -4,7 +4,7 @@
>
> ttm-y := ttm_tt.o ttm_bo.o ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
> ttm_execbuf_util.o ttm_range_manager.o ttm_resource.o ttm_pool.o \
> - ttm_device.o
> + ttm_device.o ttm_sys_manager.o
> ttm-$(CONFIG_AGP) += ttm_agp_backend.o
>
> obj-$(CONFIG_DRM_TTM) += ttm.o
> diff --git a/drivers/gpu/drm/ttm/ttm_device.c
> b/drivers/gpu/drm/ttm/ttm_device.c
> index 1f2024164d72..39956e08b4c3 100644
> --- a/drivers/gpu/drm/ttm/ttm_device.c
> +++ b/drivers/gpu/drm/ttm/ttm_device.c
> @@ -165,21 +165,6 @@ int ttm_device_swapout(struct ttm_device *bdev, struct
> ttm_operation_ctx *ctx,
> }
> EXPORT_SYMBOL(ttm_device_swapout);
>
> -static void ttm_init_sysman(struct ttm_device *bdev)
> -{
> - struct ttm_resource_manager *man = &bdev->sysman;
> -
> - /*
> -* Initialize the system memory buffer type.
> -* Other types need to be driver / IOCTL initialized.
> -*/
> - man->use_tt = true;
> -
> - ttm_resource_manager_init(man, 0);
> - ttm_set_driver_manager(bdev, TTM_PL_SYSTEM, man);
> - ttm_resource_manager_set_used(man, true);
> -}
> -
> static void ttm_device_delayed_workqueue(struct work_struct *work)
> {
> struct ttm_device *bdev =
> @@ -222,7 +207,7 @@ int ttm_device_init(struct ttm_device *bdev, struct
> ttm_device_funcs *funcs,
>
> bdev->funcs = funcs;
>
> - ttm_init_sysman(bdev);
> + ttm_sys_man_init(bdev);
> ttm_pool_init(&bdev->pool, dev, use_dma_alloc, use_dma32);
>
> bdev->vma_manager = vma_manager;
> diff --git a/drivers/gpu/drm/ttm/ttm_module.h
> b/drivers/gpu/drm/ttm/ttm_module.h
> index d7cac5d4b835..26564a98958f 100644
> --- a/drivers/gpu/drm/ttm/ttm_module.h
> +++ b/drivers/gpu/drm/ttm/ttm_module.h
> @@ -34,7 +34,10 @@
> #define TTM_PFX "[TTM] "
>
> struct dentry;
> +struct ttm_device;
>
> extern struct dentry *ttm_debugfs_root;
>
> +int ttm_sys_man_init(struct ttm_device *bdev);
> +
> #endif /* _TTM_MODULE_H_ */
> diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
> b/drivers/gpu/drm/ttm/ttm_resource.c
> index 04f2eef653ab..a6900b82f31a 100644
> --- a/drivers/gpu/drm/ttm/ttm_resource.c
> +++ b/drivers/gpu/drm/ttm/ttm_resource.c
> @@ -33,9 +33,6 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
> ttm_manager_type(bo->bdev, res->mem_type);
>
> res->mm_node = NULL;
> - if (!man->func || !man->func->alloc)
> - return 0;
> -
> return man->func->alloc(man, bo, place, res);
> }
>
> @@ -44,9 +41,7 @@ void ttm_resource_free(struct ttm_buffer_object *bo, struct
> ttm_resource *res)
> struct ttm_resource_manager *man =
> ttm_manager_type(bo->bdev, res->mem_type);
>
> - if (man->func && man->func->free)
> - man->func->free(man, res);
> -
> + man->func->free(man, res);
> res->mm_node = NULL;
> res->mem_type = TTM_PL_SYSTEM;
> }
> @@ -139,7 +134,6 @@ void ttm_resource_manager_debug(struct
> ttm_resource_manager *man,
> drm_printf(p, " use_type: %d\n", man->use_type);
> drm_printf(p, " use_tt: %d\n", man->use_tt);
> drm_printf(p, " size: %llu\n", man->size);
> - if (man->func && man->func->debug)
> - (*man->func->debug)(man, p);
> + man->func->debug(man, p);
Can we drop this one? It looks like nouveau has manager_funcs without
the .debug hook? Like nouveau_gart_manager?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2] drm/doc/rfc: i915 DG1 uAPI
On Tue, Apr 13, 2021 at 12:47:06PM +0100, Matthew Auld wrote:
> Add an entry for the new uAPI needed for DG1.
>
> v2(Daniel):
> - include the overall upstreaming plan
> - add a note for mmap, there are differences here for TTM vs i915
> - bunch of other suggestions from Daniel
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Daniel Vetter
> Cc: Dave Airlie
Bunch more thoughts below, I think we're getting there. Thanks for doing
this.
> ---
> Documentation/gpu/rfc/i915_gem_lmem.h | 151
> Documentation/gpu/rfc/i915_gem_lmem.rst | 119 +++
> Documentation/gpu/rfc/index.rst | 4 +
> 3 files changed, 274 insertions(+)
> create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
> create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
>
> diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h
> b/Documentation/gpu/rfc/i915_gem_lmem.h
> new file mode 100644
> index ..6ae13209d7ef
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_gem_lmem.h
> @@ -0,0 +1,151 @@
> +/* The new query_id for struct drm_i915_query_item */
> +#define DRM_I915_QUERY_MEMORY_REGIONS 0xdeadbeaf
> +
> +/**
> + * enum drm_i915_gem_memory_class
> + */
> +enum drm_i915_gem_memory_class {
Are we really going with enum in uapi? I thought that was frought with
peril since the integer type of enum is quite a bit up to compilers. But
maybe I'm just scared.
> + /** @I915_MEMORY_CLASS_SYSTEM: system memory */
> + I915_MEMORY_CLASS_SYSTEM = 0,
> + /** @I915_MEMORY_CLASS_DEVICE: device local-memory */
> + I915_MEMORY_CLASS_DEVICE,
> +};
> +
> +/**
> + * struct drm_i915_gem_memory_class_instance
> + */
> +struct drm_i915_gem_memory_class_instance {
> + /** @memory_class: see enum drm_i915_gem_memory_class */
> + __u16 memory_class;
> +
> + /** @memory_instance: which instance */
> + __u16 memory_instance;
> +};
> +
> +/**
> + * struct drm_i915_memory_region_info
> + *
> + * Describes one region as known to the driver.
> + */
> +struct drm_i915_memory_region_info {
> + /** @region: class:instance pair encoding */
> + struct drm_i915_gem_memory_class_instance region;
> +
> + /** @rsvd0: MBZ */
> + __u32 rsvd0;
> +
> + /** @caps: MBZ */
> + __u64 caps;
> +
> + /** @flags: MBZ */
> + __u64 flags;
> +
> + /** @probed_size: Memory probed by the driver (-1 = unknown) */
> + __u64 probed_size;
> +
> + /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
> + __u64 unallocated_size;
> +
> + /** @rsvd1: MBZ */
> + __u64 rsvd1[8];
I guess this is for future stuff that becomes relevant with multi-tile?
Might be worth explaining in 1-2 words why we reserve a pile here. Also
it doesn't matter ofc for performance here :-)
> +};
> +
> +/**
> + * struct drm_i915_query_memory_regions
> + *
> + * Region info query enumerates all regions known to the driver by filling in
> + * an array of struct drm_i915_memory_region_info structures.
I guess this works with the usual 1. query number of regions 2. get them
all two-step ioctl flow? Worth explaining here.
> + */
> +struct drm_i915_query_memory_regions {
> + /** @num_regions: Number of supported regions */
> + __u32 num_regions;
> +
> + /** @rsvd: MBZ */
> + __u32 rsvd[3];
> +
> + /** @regions: Info about each supported region */
> + struct drm_i915_memory_region_info regions[];
> +};
Hm don't we need a query ioctl for this too?
> +
> +#define DRM_I915_GEM_CREATE_EXT 0xdeadbeaf
> +#define DRM_IOCTL_I915_GEM_CREATE_EXTDRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_CREATE_EXT, struct drm_i915_gem_create_ext)
> +
> +/**
> + * struct drm_i915_gem_create_ext
I think some explanation here that all new bo flags will be added here,
and that in general we're phasing out the various SET/GET ioctls.
> + */
> +struct drm_i915_gem_create_ext {
> + /**
> + * @size: Requested size for the object.
> + *
> + * The (page-aligned) allocated size for the object will be returned.
> + */
> + __u64 size;
> + /**
> + * @handle: Returned handle for the object.
> + *
> + * Object handles are nonzero.
> + */
> + __u32 handle;
> + /** @flags: MBZ */
> + __u32 flags;
> + /**
> + * @extensions:
> + * For I915_GEM_CREATE_EXT_SETPARAM extension usage see both:
> + * struct drm_i915_gem_create_ext_setparam.
> + * struct drm_i915_gem_object_param for the possible parameters.
> + */
> +#define I915_GEM_CREATE_EXT_SETPARAM 0
> + __u64 extensions;
> +};
> +
> +/**
> + * struct drm_i915_gem_object_param
> + */
> +struct drm_i915_gem_object_param {
> + /** @handle: Object handle (0 for I915_GEM_CREATE_EXT_SETPARAM) */
Uh no, this looks like leftovers having a separate SETPARAM ioctl. That's
pretty bad design, and we (well Jason) is doing serious surgery to undo
that mistakes. Please remove.
> + __u32 ha
Re: [PATCH 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
> Am 14.04.21 um 11:15 schrieb Daniel Vetter:
> > On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
> > > Am 14.04.21 um 08:48 schrieb Felix Kuehling:
> > > > Pages in SG BOs were not allocated by TTM. So don't count them against
> > > > TTM's pages limit.
> > > >
> > > > Signed-off-by: Felix Kuehling
> > > Reviewed-by: Christian König
> > >
> > > Going to pick that one up for inclusion in drm-misc-next.
> > See my other email, but why do we need this? A bit more explanation is imo
> > needed here at least, since we still need to guarantee that allocations
> > don't over the limit in total for all gpu buffers together. At least until
> > the shrinker has landed.
> >
> > And this here just opens up the barn door without any explanation why it's
> > ok.
>
> The SG based BOs might not even be backed by pages. E.g. exported VRAM.
>
> So either they are exported by a driver which should have accounted for the
> allocation, exported by TTM which already did the accounting or doesn't even
> point to pages at all.
>
> This is really a bug fix to recreate the behavior we had before moving the
> accounting to this place.
Throw that into the commit message and a-b: me. Ideally with a Fixes: line
or so pointing at the offending commit that broke stuff. Commit messages
should really go into more detail when there's an entire story behind a
small change like this one.
-Daniel
>
> Christian.
>
> > -Daniel
> >
> > > Regards,
> > > Christian.
> > >
> > > > ---
> > > >drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
> > > >1 file changed, 18 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> > > > index 5d8820725b75..e8b8c3257392 100644
> > > > --- a/drivers/gpu/drm/ttm/ttm_tt.c
> > > > +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> > > > @@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
> > > > if (ttm_tt_is_populated(ttm))
> > > > return 0;
> > > > - atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
> > > > - if (bdev->pool.use_dma32)
> > > > - atomic_long_add(ttm->num_pages,
> > > > &ttm_dma32_pages_allocated);
> > > > + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> > > > + atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
> > > > + if (bdev->pool.use_dma32)
> > > > + atomic_long_add(ttm->num_pages,
> > > > + &ttm_dma32_pages_allocated);
> > > > + }
> > > > while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit
> > > > ||
> > > >atomic_long_read(&ttm_dma32_pages_allocated) >
> > > > @@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
> > > > return 0;
> > > >error:
> > > > - atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > > > - if (bdev->pool.use_dma32)
> > > > - atomic_long_sub(ttm->num_pages,
> > > > &ttm_dma32_pages_allocated);
> > > > + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> > > > + atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > > > + if (bdev->pool.use_dma32)
> > > > + atomic_long_sub(ttm->num_pages,
> > > > + &ttm_dma32_pages_allocated);
> > > > + }
> > > > return ret;
> > > >}
> > > >EXPORT_SYMBOL(ttm_tt_populate);
> > > > @@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev,
> > > > struct ttm_tt *ttm)
> > > > else
> > > > ttm_pool_free(&bdev->pool, ttm);
> > > > - atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > > > - if (bdev->pool.use_dma32)
> > > > - atomic_long_sub(ttm->num_pages,
> > > > &ttm_dma32_pages_allocated);
> > > > + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> > > > + atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > > > + if (bdev->pool.use_dma32)
> > > > + atomic_long_sub(ttm->num_pages,
> > > > + &ttm_dma32_pages_allocated);
> > > > + }
> > > > ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_POPULATED;
> > > >}
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cchristian.koenig%40amd.com%7C3075d7fd16644322a13608d8ff25d59b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637539885255795187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KOnHA1CbNFjjMZR2rgHmGkH%2B7C84YCtA6u9V1wBAay4%3D&reserved=0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.c
Re: [PATCH 5/7] drm/ttm: add ttm_sys_manager
Am 14.04.21 um 12:05 schrieb Matthew Auld:
On Tue, 13 Apr 2021 at 14:53, Christian König
wrote:
Add a separate manager for the system domain and make function tables
mandatory.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/Makefile | 2 +-
drivers/gpu/drm/ttm/ttm_device.c | 17 +-
drivers/gpu/drm/ttm/ttm_module.h | 3 ++
drivers/gpu/drm/ttm/ttm_resource.c| 10 ++
drivers/gpu/drm/ttm/ttm_sys_manager.c | 46 +++
5 files changed, 53 insertions(+), 25 deletions(-)
create mode 100644 drivers/gpu/drm/ttm/ttm_sys_manager.c
diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index 40e5e9da7953..f906b22959cf 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -4,7 +4,7 @@
ttm-y := ttm_tt.o ttm_bo.o ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
ttm_execbuf_util.o ttm_range_manager.o ttm_resource.o ttm_pool.o \
- ttm_device.o
+ ttm_device.o ttm_sys_manager.o
ttm-$(CONFIG_AGP) += ttm_agp_backend.o
obj-$(CONFIG_DRM_TTM) += ttm.o
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 1f2024164d72..39956e08b4c3 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -165,21 +165,6 @@ int ttm_device_swapout(struct ttm_device *bdev, struct
ttm_operation_ctx *ctx,
}
EXPORT_SYMBOL(ttm_device_swapout);
-static void ttm_init_sysman(struct ttm_device *bdev)
-{
- struct ttm_resource_manager *man = &bdev->sysman;
-
- /*
-* Initialize the system memory buffer type.
-* Other types need to be driver / IOCTL initialized.
-*/
- man->use_tt = true;
-
- ttm_resource_manager_init(man, 0);
- ttm_set_driver_manager(bdev, TTM_PL_SYSTEM, man);
- ttm_resource_manager_set_used(man, true);
-}
-
static void ttm_device_delayed_workqueue(struct work_struct *work)
{
struct ttm_device *bdev =
@@ -222,7 +207,7 @@ int ttm_device_init(struct ttm_device *bdev, struct
ttm_device_funcs *funcs,
bdev->funcs = funcs;
- ttm_init_sysman(bdev);
+ ttm_sys_man_init(bdev);
ttm_pool_init(&bdev->pool, dev, use_dma_alloc, use_dma32);
bdev->vma_manager = vma_manager;
diff --git a/drivers/gpu/drm/ttm/ttm_module.h b/drivers/gpu/drm/ttm/ttm_module.h
index d7cac5d4b835..26564a98958f 100644
--- a/drivers/gpu/drm/ttm/ttm_module.h
+++ b/drivers/gpu/drm/ttm/ttm_module.h
@@ -34,7 +34,10 @@
#define TTM_PFX "[TTM] "
struct dentry;
+struct ttm_device;
extern struct dentry *ttm_debugfs_root;
+int ttm_sys_man_init(struct ttm_device *bdev);
+
#endif /* _TTM_MODULE_H_ */
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
index 04f2eef653ab..a6900b82f31a 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -33,9 +33,6 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
ttm_manager_type(bo->bdev, res->mem_type);
res->mm_node = NULL;
- if (!man->func || !man->func->alloc)
- return 0;
-
return man->func->alloc(man, bo, place, res);
}
@@ -44,9 +41,7 @@ void ttm_resource_free(struct ttm_buffer_object *bo, struct
ttm_resource *res)
struct ttm_resource_manager *man =
ttm_manager_type(bo->bdev, res->mem_type);
- if (man->func && man->func->free)
- man->func->free(man, res);
-
+ man->func->free(man, res);
res->mm_node = NULL;
res->mem_type = TTM_PL_SYSTEM;
}
@@ -139,7 +134,6 @@ void ttm_resource_manager_debug(struct ttm_resource_manager
*man,
drm_printf(p, " use_type: %d\n", man->use_type);
drm_printf(p, " use_tt: %d\n", man->use_tt);
drm_printf(p, " size: %llu\n", man->size);
- if (man->func && man->func->debug)
- (*man->func->debug)(man, p);
+ man->func->debug(man, p);
Can we drop this one? It looks like nouveau has manager_funcs without
the .debug hook? Like nouveau_gart_manager?
Ah! I thought that was another check for !man, but you are right that
will break nouveau.
Thanks,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
Am 14.04.21 um 12:26 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
Am 14.04.21 um 11:15 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
Am 14.04.21 um 08:48 schrieb Felix Kuehling:
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
Going to pick that one up for inclusion in drm-misc-next.
See my other email, but why do we need this? A bit more explanation is imo
needed here at least, since we still need to guarantee that allocations
don't over the limit in total for all gpu buffers together. At least until
the shrinker has landed.
And this here just opens up the barn door without any explanation why it's
ok.
The SG based BOs might not even be backed by pages. E.g. exported VRAM.
So either they are exported by a driver which should have accounted for the
allocation, exported by TTM which already did the accounting or doesn't even
point to pages at all.
This is really a bug fix to recreate the behavior we had before moving the
accounting to this place.
Throw that into the commit message and a-b: me. Ideally with a Fixes: line
or so pointing at the offending commit that broke stuff. Commit messages
should really go into more detail when there's an entire story behind a
small change like this one.
Sorry I though that this would be obvious :)
I've already pushed the patch in the morning, but going to keep that in
mind for the next time.
Christian.
-Daniel
Christian.
-Daniel
Regards,
Christian.
---
drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5d8820725b75..e8b8c3257392 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
if (ttm_tt_is_populated(ttm))
return 0;
- atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_add(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit ||
atomic_long_read(&ttm_dma32_pages_allocated) >
@@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
return 0;
error:
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
return ret;
}
EXPORT_SYMBOL(ttm_tt_populate);
@@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev, struct
ttm_tt *ttm)
else
ttm_pool_free(&bdev->pool, ttm);
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_POPULATED;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cchristian.koenig%40amd.com%7C3075d7fd16644322a13608d8ff25d59b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637539885255795187%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KOnHA1CbNFjjMZR2rgHmGkH%2B7C84YCtA6u9V1wBAay4%3D&reserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/modifiers: Enforce consistency between the cap an IN_FORMATS
On Wed, 14 Apr 2021 11:08:15 +0200
Daniel Vetter wrote:
> It's very confusing for userspace to have to deal with inconsistencies
> here, and some drivers screwed this up a bit. Most just ommitted the
> format list when they meant to say that only linear modifier is
> allowed, but some also meant that only implied modifiers are
> acceptable (because actually none of the planes registered supported
> modifiers).
>
> Now that this is all done consistently across all drivers, document
> the rules and enforce it in the drm core.
>
> v2:
> - Make the capability a link (Simon)
> - Note that all is lost before 5.1.
>
> Acked-by: Maxime Ripard
> Cc: Simon Ser
> Reviewed-by: Lucas Stach
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane.c | 18 +-
> include/drm/drm_mode_config.h | 2 ++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 0dd43882fe7c..20c7a1665414 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -128,6 +128,13 @@
> * pairs supported by this plane. The blob is a struct
> * drm_format_modifier_blob. Without this property the plane doesn't
> * support buffers with modifiers. Userspace cannot change this property.
> + *
> + * Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
> + * capability for general modifier support. If this flag is set then
> every
> + * plane will have the IN_FORMATS property, even when it only supports
> + * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have
> been
> + * various bugs in this area with inconsistencies between the capability
> + * flag and per-plane properties.
> */
>
> static unsigned int drm_num_planes(struct drm_device *dev)
> @@ -277,8 +284,14 @@ static int __drm_universal_plane_init(struct drm_device
> *dev,
> format_modifier_count++;
> }
>
> - if (format_modifier_count)
> + /* autoset the cap and check for consistency across all planes */
> + if (format_modifier_count) {
> + WARN_ON(!config->allow_fb_modifiers &&
> + !list_empty(&config->plane_list));
> config->allow_fb_modifiers = true;
> + } else {
> + WARN_ON(config->allow_fb_modifiers);
> + }
>
> plane->modifier_count = format_modifier_count;
> plane->modifiers = kmalloc_array(format_modifier_count,
> @@ -360,6 +373,9 @@ static int __drm_universal_plane_init(struct drm_device
> *dev,
> * drm_universal_plane_init() to let the DRM managed resource infrastructure
> * take care of cleanup and deallocation.
> *
> + * Drivers supporting modifiers must set @format_modifiers on all their
> planes,
> + * even those that only support DRM_FORMAT_MOD_LINEAR.
> + *
> * Returns:
> * Zero on success, error code on failure.
> */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index ab424ddd7665..1ddf7783fdf7 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -909,6 +909,8 @@ struct drm_mode_config {
>* @allow_fb_modifiers:
>*
>* Whether the driver supports fb modifiers in the ADDFB2.1 ioctl call.
> + * Note that drivers should not set this directly, it is automatically
> + * set in drm_universal_plane_init().
>*
>* IMPORTANT:
>*
Acked-by: Pekka Paalanen
Thanks,
pq
pgpAjoXL9AIt9.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
On Wed, Apr 14, 2021 at 12:49 PM Christian König
wrote:
>
> Am 14.04.21 um 12:26 schrieb Daniel Vetter:
> > On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
> >> Am 14.04.21 um 11:15 schrieb Daniel Vetter:
> >>> On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
> Am 14.04.21 um 08:48 schrieb Felix Kuehling:
> > Pages in SG BOs were not allocated by TTM. So don't count them against
> > TTM's pages limit.
> >
> > Signed-off-by: Felix Kuehling
> Reviewed-by: Christian König
>
> Going to pick that one up for inclusion in drm-misc-next.
> >>> See my other email, but why do we need this? A bit more explanation is imo
> >>> needed here at least, since we still need to guarantee that allocations
> >>> don't over the limit in total for all gpu buffers together. At least until
> >>> the shrinker has landed.
> >>>
> >>> And this here just opens up the barn door without any explanation why it's
> >>> ok.
> >> The SG based BOs might not even be backed by pages. E.g. exported VRAM.
> >>
> >> So either they are exported by a driver which should have accounted for the
> >> allocation, exported by TTM which already did the accounting or doesn't
> >> even
> >> point to pages at all.
> >>
> >> This is really a bug fix to recreate the behavior we had before moving the
> >> accounting to this place.
> > Throw that into the commit message and a-b: me. Ideally with a Fixes: line
> > or so pointing at the offending commit that broke stuff. Commit messages
> > should really go into more detail when there's an entire story behind a
> > small change like this one.
>
> Sorry I though that this would be obvious :)
>
> I've already pushed the patch in the morning, but going to keep that in
> mind for the next time.
I'll keep reminding you to pls elaborate more in commit messages, it's
coming up every once in a while :-)
Also in general I think a few days of letting patches soak out there,
especially shared code, is good curtesy. Some folks demand 2 weeks,
which I think is too much, but less than 24h just means you're
guaranteed to leave out half the globe with their feedback. Which
isn't great.
Driver code I don't care since there you know all the stakeholders ofc.
-Daniel
>
> Christian.
>
> > -Daniel
> >
> >> Christian.
> >>
> >>> -Daniel
> >>>
> Regards,
> Christian.
>
> > ---
> > drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
> > 1 file changed, 18 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> > index 5d8820725b75..e8b8c3257392 100644
> > --- a/drivers/gpu/drm/ttm/ttm_tt.c
> > +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> > @@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
> > if (ttm_tt_is_populated(ttm))
> > return 0;
> > - atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
> > - if (bdev->pool.use_dma32)
> > - atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
> > + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> > + atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
> > + if (bdev->pool.use_dma32)
> > + atomic_long_add(ttm->num_pages,
> > + &ttm_dma32_pages_allocated);
> > + }
> > while (atomic_long_read(&ttm_pages_allocated) >
> > ttm_pages_limit ||
> > atomic_long_read(&ttm_dma32_pages_allocated) >
> > @@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
> > return 0;
> > error:
> > - atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > - if (bdev->pool.use_dma32)
> > - atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
> > + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> > + atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > + if (bdev->pool.use_dma32)
> > + atomic_long_sub(ttm->num_pages,
> > + &ttm_dma32_pages_allocated);
> > + }
> > return ret;
> > }
> > EXPORT_SYMBOL(ttm_tt_populate);
> > @@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev,
> > struct ttm_tt *ttm)
> > else
> > ttm_pool_free(&bdev->pool, ttm);
> > - atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > - if (bdev->pool.use_dma32)
> > - atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
> > + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> > + atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> > + if (bdev->pool.use_dma32)
> > + atomic_long_sub(ttm->num_pages,
> > + &ttm_dma32_pages_allocated);
> > + }
> > ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_
Re: [PATCH 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
Am 14.04.21 um 14:25 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 12:49 PM Christian König
wrote:
Am 14.04.21 um 12:26 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
Am 14.04.21 um 11:15 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
Am 14.04.21 um 08:48 schrieb Felix Kuehling:
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
Going to pick that one up for inclusion in drm-misc-next.
See my other email, but why do we need this? A bit more explanation is imo
needed here at least, since we still need to guarantee that allocations
don't over the limit in total for all gpu buffers together. At least until
the shrinker has landed.
And this here just opens up the barn door without any explanation why it's
ok.
The SG based BOs might not even be backed by pages. E.g. exported VRAM.
So either they are exported by a driver which should have accounted for the
allocation, exported by TTM which already did the accounting or doesn't even
point to pages at all.
This is really a bug fix to recreate the behavior we had before moving the
accounting to this place.
Throw that into the commit message and a-b: me. Ideally with a Fixes: line
or so pointing at the offending commit that broke stuff. Commit messages
should really go into more detail when there's an entire story behind a
small change like this one.
Sorry I though that this would be obvious :)
I've already pushed the patch in the morning, but going to keep that in
mind for the next time.
I'll keep reminding you to pls elaborate more in commit messages, it's
coming up every once in a while :-)
Well, describing stuff in a commit message which is obvious is just
redundant.
I can of course explain the whole background of the code in question in
the commit message, but for obvious bug fixes like this it is just overkill.
Also in general I think a few days of letting patches soak out there,
especially shared code, is good curtesy. Some folks demand 2 weeks,
which I think is too much, but less than 24h just means you're
guaranteed to leave out half the globe with their feedback. Which
isn't great.
Well for structural changes I certainly agree, but not for a bug fix
which adds a missing check for a special case.
Christian.
Driver code I don't care since there you know all the stakeholders ofc.
-Daniel
Christian.
-Daniel
Christian.
-Daniel
Regards,
Christian.
---
drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5d8820725b75..e8b8c3257392 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
if (ttm_tt_is_populated(ttm))
return 0;
- atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_add(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit ||
atomic_long_read(&ttm_dma32_pages_allocated) >
@@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
return 0;
error:
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
return ret;
}
EXPORT_SYMBOL(ttm_tt_populate);
@@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev, struct
ttm_tt *ttm)
else
ttm_pool_free(&bdev->pool, ttm);
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
ttm->page_flags &= ~TTM_PAGE_FLAG_PRIV_POPULATED;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.or
Re: [PATCH 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
On Wed, Apr 14, 2021 at 2:43 PM Christian König
wrote:
>
> Am 14.04.21 um 14:25 schrieb Daniel Vetter:
> > On Wed, Apr 14, 2021 at 12:49 PM Christian König
> > wrote:
> >> Am 14.04.21 um 12:26 schrieb Daniel Vetter:
> >>> On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
> Am 14.04.21 um 11:15 schrieb Daniel Vetter:
> > On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
> >> Am 14.04.21 um 08:48 schrieb Felix Kuehling:
> >>> Pages in SG BOs were not allocated by TTM. So don't count them against
> >>> TTM's pages limit.
> >>>
> >>> Signed-off-by: Felix Kuehling
> >> Reviewed-by: Christian König
> >>
> >> Going to pick that one up for inclusion in drm-misc-next.
> > See my other email, but why do we need this? A bit more explanation is
> > imo
> > needed here at least, since we still need to guarantee that allocations
> > don't over the limit in total for all gpu buffers together. At least
> > until
> > the shrinker has landed.
> >
> > And this here just opens up the barn door without any explanation why
> > it's
> > ok.
> The SG based BOs might not even be backed by pages. E.g. exported VRAM.
>
> So either they are exported by a driver which should have accounted for
> the
> allocation, exported by TTM which already did the accounting or doesn't
> even
> point to pages at all.
>
> This is really a bug fix to recreate the behavior we had before moving
> the
> accounting to this place.
> >>> Throw that into the commit message and a-b: me. Ideally with a Fixes: line
> >>> or so pointing at the offending commit that broke stuff. Commit messages
> >>> should really go into more detail when there's an entire story behind a
> >>> small change like this one.
> >> Sorry I though that this would be obvious :)
> >>
> >> I've already pushed the patch in the morning, but going to keep that in
> >> mind for the next time.
> > I'll keep reminding you to pls elaborate more in commit messages, it's
> > coming up every once in a while :-)
>
> Well, describing stuff in a commit message which is obvious is just
> redundant.
>
> I can of course explain the whole background of the code in question in
> the commit message, but for obvious bug fixes like this it is just overkill.
>
> > Also in general I think a few days of letting patches soak out there,
> > especially shared code, is good curtesy. Some folks demand 2 weeks,
> > which I think is too much, but less than 24h just means you're
> > guaranteed to leave out half the globe with their feedback. Which
> > isn't great.
>
> Well for structural changes I certainly agree, but not for a bug fix
> which adds a missing check for a special case.
Well if it's a bugfix should at least indicate that, and regression
fixes should come with Fixes: tags. Obvious for you who screamed at
the code is generally not implying it's obvious for anyone else. So
yeah I think in general more explanations would be good.
-Daniel
>
> Christian.
>
> >
> > Driver code I don't care since there you know all the stakeholders ofc.
> > -Daniel
> >
> >> Christian.
> >>
> >>> -Daniel
> >>>
> Christian.
>
> > -Daniel
> >
> >> Regards,
> >> Christian.
> >>
> >>> ---
> >>> drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
> >>> 1 file changed, 18 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c
> >>> b/drivers/gpu/drm/ttm/ttm_tt.c
> >>> index 5d8820725b75..e8b8c3257392 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> >>> @@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
> >>>if (ttm_tt_is_populated(ttm))
> >>>return 0;
> >>> - atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
> >>> - if (bdev->pool.use_dma32)
> >>> - atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
> >>> + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> >>> + atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
> >>> + if (bdev->pool.use_dma32)
> >>> + atomic_long_add(ttm->num_pages,
> >>> + &ttm_dma32_pages_allocated);
> >>> + }
> >>>while (atomic_long_read(&ttm_pages_allocated) >
> >>> ttm_pages_limit ||
> >>> atomic_long_read(&ttm_dma32_pages_allocated) >
> >>> @@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
> >>>return 0;
> >>> error:
> >>> - atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
> >>> - if (bdev->pool.use_dma32)
> >>> - atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
> >>> + if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
> >>> + atomic_long_sub(ttm->num_pages, &ttm_pages_
Re: [PATCH 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
Am 14.04.21 um 14:47 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 2:43 PM Christian König
wrote:
Am 14.04.21 um 14:25 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 12:49 PM Christian König
wrote:
Am 14.04.21 um 12:26 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
Am 14.04.21 um 11:15 schrieb Daniel Vetter:
On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
Am 14.04.21 um 08:48 schrieb Felix Kuehling:
Pages in SG BOs were not allocated by TTM. So don't count them against
TTM's pages limit.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
Going to pick that one up for inclusion in drm-misc-next.
See my other email, but why do we need this? A bit more explanation is imo
needed here at least, since we still need to guarantee that allocations
don't over the limit in total for all gpu buffers together. At least until
the shrinker has landed.
And this here just opens up the barn door without any explanation why it's
ok.
The SG based BOs might not even be backed by pages. E.g. exported VRAM.
So either they are exported by a driver which should have accounted for the
allocation, exported by TTM which already did the accounting or doesn't even
point to pages at all.
This is really a bug fix to recreate the behavior we had before moving the
accounting to this place.
Throw that into the commit message and a-b: me. Ideally with a Fixes: line
or so pointing at the offending commit that broke stuff. Commit messages
should really go into more detail when there's an entire story behind a
small change like this one.
Sorry I though that this would be obvious :)
I've already pushed the patch in the morning, but going to keep that in
mind for the next time.
I'll keep reminding you to pls elaborate more in commit messages, it's
coming up every once in a while :-)
Well, describing stuff in a commit message which is obvious is just
redundant.
I can of course explain the whole background of the code in question in
the commit message, but for obvious bug fixes like this it is just overkill.
Also in general I think a few days of letting patches soak out there,
especially shared code, is good curtesy. Some folks demand 2 weeks,
which I think is too much, but less than 24h just means you're
guaranteed to leave out half the globe with their feedback. Which
isn't great.
Well for structural changes I certainly agree, but not for a bug fix
which adds a missing check for a special case.
Well if it's a bugfix should at least indicate that, and regression
fixes should come with Fixes: tags. Obvious for you who screamed at
the code is generally not implying it's obvious for anyone else. So
yeah I think in general more explanations would be good.
Ok, seconded. The missing Fixes tag is a good point and the wording
doesn't made it clear that this is a bug fix.
Going to keep that in mind.
Christian.
-Daniel
Christian.
Driver code I don't care since there you know all the stakeholders ofc.
-Daniel
Christian.
-Daniel
Christian.
-Daniel
Regards,
Christian.
---
drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5d8820725b75..e8b8c3257392 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -317,9 +317,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
if (ttm_tt_is_populated(ttm))
return 0;
- atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_add(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_add(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_add(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
while (atomic_long_read(&ttm_pages_allocated) > ttm_pages_limit ||
atomic_long_read(&ttm_dma32_pages_allocated) >
@@ -350,9 +353,12 @@ int ttm_tt_populate(struct ttm_device *bdev,
return 0;
error:
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pages_allocated);
+ if (!(ttm->page_flags & TTM_PAGE_FLAG_SG)) {
+ atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
+ if (bdev->pool.use_dma32)
+ atomic_long_sub(ttm->num_pages,
+ &ttm_dma32_pages_allocated);
+ }
return ret;
}
EXPORT_SYMBOL(ttm_tt_populate);
@@ -382,9 +388,12 @@ void ttm_tt_unpopulate(struct ttm_device *bdev, struct
ttm_tt *ttm)
else
ttm_pool_free(&bdev->pool, ttm);
- atomic_long_sub(ttm->num_pages, &ttm_pages_allocated);
- if (bdev->pool.use_dma32)
- atomic_long_sub(ttm->num_pages, &ttm_dma32_pag
Re: [PATCH 07/18] drm/vc4: hdmi: Add full range RGB helper
Hi Thomas,
On Mon, Apr 12, 2021 at 11:44:05AM +0200, Thomas Zimmermann wrote:
>
>
> Am 17.03.21 um 16:43 schrieb Maxime Ripard:
> > We're going to need to tell whether we want to run with a full or
> > limited range RGB output in multiple places in the code, so let's create
> > a helper that will return whether we need with full range or not.
> >
> > Signed-off-by: Maxime Ripard
>
> Acked-by: Thomas Zimmermann
>
> although with a comments
>
> > ---
> > drivers/gpu/drm/vc4/vc4_hdmi.c | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index eee9751009c2..fc545072b173 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -95,6 +95,15 @@
> > #define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
> > +static bool vc4_hdmi_is_full_range_rgb(struct vc4_hdmi *vc4_hdmi,
> > + const struct drm_display_mode *mode)
> > +{
> > + struct vc4_hdmi_encoder *vc4_encoder = &vc4_hdmi->encoder;
> > +
> > + return !vc4_encoder->hdmi_monitor ||
>
> Is this ever being called from non-HDMI code? If not, I'd put an
> drm_WARN_ONCE around this check.
I'm not sure we need to worry about this, it's a static function in the
HDMI controller driver so it can't be called from anywhere else
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/18] drm/vc4: hdmi: Define colorspace matrices
Am 17.03.21 um 16:43 schrieb Maxime Ripard:
The current CSC setup code for the BCM2711 uses a sequence of register
writes to configure the CSC depending on whether we output using a full
or limited range.
However, with the upcoming introduction of the YUV output, we're going
to add new matrices to perform the conversions, so we should switch to
something a bit more flexible that takes the matrix as an argument and
programs the CSC accordingly.
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 77 +-
1 file changed, 48 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index b0e0cb533944..9614de7303b8 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -525,6 +525,50 @@ static void vc4_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_CSC_CTL, csc_ctl);
}
+
+/*
+ * If we need to output Full Range RGB, then use the unity matrix
+ *
+ * [ 1 0 0 0]
+ * [ 0 1 0 0]
+ * [ 0 0 1 0]
+ *
+ * Matrix is signed 2p13 fixed point, with signed 9p6 offsets
+ */
+static const u16 vc5_hdmi_csc_full_rgb_unity[3][4] = {
+ { 0x2000, 0x, 0x, 0x },
+ { 0x, 0x2000, 0x, 0x },
+ { 0x, 0x, 0x2000, 0x },
+};
+
+/*
+ * CEA VICs other than #1 require limited range RGB output unless
+ * overridden by an AVI infoframe. Apply a colorspace conversion to
+ * squash 0-255 down to 16-235. The matrix here is:
+ *
+ * [ 0.8594 0 0 16]
+ * [ 0 0.8594 0 16]
+ * [ 0 0 0.8594 16]
+ *
+ * Matrix is signed 2p13 fixed point, with signed 9p6 offsets
+ */
+static const u16 vc5_hdmi_csc_full_rgb_to_limited_rgb[3][4] = {
+ { 0x1b80, 0x, 0x, 0x0400 },
+ { 0x, 0x1b80, 0x, 0x0400 },
+ { 0x, 0x, 0x1b80, 0x0400 },
+};
+
+static void vc5_hdmi_set_csc_coeffs(struct vc4_hdmi *vc4_hdmi,
+ const u16 coeffs[3][4])
+{
+ HDMI_WRITE(HDMI_CSC_12_11, (coeffs[0][1] << 16) | coeffs[0][0]);
+ HDMI_WRITE(HDMI_CSC_14_13, (coeffs[0][3] << 16) | coeffs[0][2]);
+ HDMI_WRITE(HDMI_CSC_22_21, (coeffs[1][1] << 16) | coeffs[1][0]);
+ HDMI_WRITE(HDMI_CSC_24_23, (coeffs[1][3] << 16) | coeffs[1][2]);
+ HDMI_WRITE(HDMI_CSC_32_31, (coeffs[2][1] << 16) | coeffs[2][0]);
+ HDMI_WRITE(HDMI_CSC_34_33, (coeffs[2][3] << 16) | coeffs[2][2]);
+}
+
static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
const struct drm_display_mode *mode)
{
@@ -533,35 +577,10 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
- if (vc4_hdmi_is_full_range_rgb(vc4_hdmi, mode)) {
- /* CEA VICs other than #1 requre limited range RGB
-* output unless overridden by an AVI infoframe.
-* Apply a colorspace conversion to squash 0-255 down
-* to 16-235. The matrix here is:
-*
-* [ 0.8594 0 0 16]
-* [ 0 0.8594 0 16]
-* [ 0 0 0.8594 16]
-* [ 0 0 0 1]
-* Matrix is signed 2p13 fixed point, with signed 9p6 offsets
-*/
- HDMI_WRITE(HDMI_CSC_12_11, (0x << 16) | 0x1b80);
- HDMI_WRITE(HDMI_CSC_14_13, (0x0400 << 16) | 0x);
- HDMI_WRITE(HDMI_CSC_22_21, (0x1b80 << 16) | 0x);
- HDMI_WRITE(HDMI_CSC_24_23, (0x0400 << 16) | 0x);
- HDMI_WRITE(HDMI_CSC_32_31, (0x << 16) | 0x);
- HDMI_WRITE(HDMI_CSC_34_33, (0x0400 << 16) | 0x1b80);
- } else {
- /* Still use the matrix for full range, but make it unity.
-* Matrix is signed 2p13 fixed point, with signed 9p6 offsets
-*/
- HDMI_WRITE(HDMI_CSC_12_11, (0x << 16) | 0x2000);
- HDMI_WRITE(HDMI_CSC_14_13, (0x << 16) | 0x);
- HDMI_WRITE(HDMI_CSC_22_21, (0x2000 << 16) | 0x);
- HDMI_WRITE(HDMI_CSC_24_23, (0x << 16) | 0x);
- HDMI_WRITE(HDMI_CSC_32_31, (0x << 16) | 0x);
- HDMI_WRITE(HDMI_CSC_34_33, (0x << 16) | 0x2000);
- }
+ if (vc4_hdmi_is_full_range_rgb(vc4_hdmi, mode))
+ vc5_hdmi_set_csc_coeffs(vc4_hdmi, &vc5_hdmi_csc_full_rgb_unity);
+ else
+ vc5_hdmi_set_csc_coeffs(vc4_hdmi,
&vc5_hdmi_csc_full_rgb_to_limited_rgb);
HDMI_WRITE(HDMI_CSC_CTL, csc_ctl);
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
Re: [PATCH 14/18] drm/vc4: hdmi: Change CSC callback prototype
Am 17.03.21 um 16:43 schrieb Maxime Ripard:
In order to support the YUV output, we'll need the atomic state to know
what is the state of the associated property in the CSC setup callback.
Let's change the prototype of that callback to allow us to access it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +++-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 9614de7303b8..56b5654c820f 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -490,6 +490,7 @@ static void vc4_hdmi_bridge_post_crtc_powerdown(struct
drm_bridge *bridge,
}
static void vc4_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
+ struct drm_atomic_state *state,
With the line length updated to 100 characters, this might just fit onto
the previous line. Anyway
Acked-by: Thomas Zimmermann
const struct drm_display_mode *mode)
{
u32 csc_ctl;
@@ -570,6 +571,7 @@ static void vc5_hdmi_set_csc_coeffs(struct vc4_hdmi
*vc4_hdmi,
}
static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
+ struct drm_atomic_state *state,
const struct drm_display_mode *mode)
{
u32 csc_ctl = VC5_MT_CP_CSC_CTL_ENABLE |
VC4_SET_FIELD(VC4_HD_CSC_CTL_MODE_CUSTOM,
@@ -860,7 +862,7 @@ static void vc4_hdmi_bridge_pre_crtc_enable(struct
drm_bridge *bridge,
struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
if (vc4_hdmi->variant->csc_setup)
- vc4_hdmi->variant->csc_setup(vc4_hdmi, mode);
+ vc4_hdmi->variant->csc_setup(vc4_hdmi, state, mode);
HDMI_WRITE(HDMI_FIFO_CTL, VC4_HDMI_FIFO_CTL_MASTER_SLAVE_N);
}
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index d03c849d6ea0..cf5e58a08eb4 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -78,6 +78,7 @@ struct vc4_hdmi_variant {
/* Callback to enable / disable the CSC */
void (*csc_setup)(struct vc4_hdmi *vc4_hdmi,
+ struct drm_atomic_state *state,
const struct drm_display_mode *mode);
/* Callback to configure the video timings in the HDMI block */
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/18] drm/vc4: hdmi: Rework the infoframe prototype
Am 17.03.21 um 16:43 schrieb Maxime Ripard:
In order to support a YUV output, we're going to need to have access to
the bridge state in the vc4_hdmi_set_avi_infoframe function. Since we
also need the connector state in that function, let's pass the full
atomic state.
While we're at it, since all those functions actually need the vc4_hdmi
structure, let's pass it instead of the drm_encoder.
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 38 --
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 56b5654c820f..83e44cf44d65 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -330,10 +330,10 @@ static int vc4_hdmi_stop_packet(struct drm_encoder
*encoder,
BIT(packet_id)), 100);
}
-static void vc4_hdmi_write_infoframe(struct drm_encoder *encoder,
+static void vc4_hdmi_write_infoframe(struct vc4_hdmi *vc4_hdmi,
union hdmi_infoframe *frame)
{
- struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+ struct drm_encoder *encoder = &vc4_hdmi->encoder.base.base;
u32 packet_id = frame->any.type - 0x80;
const struct vc4_hdmi_register *ram_packet_start =
&vc4_hdmi->variant->registers[HDMI_RAM_PACKET_START];
@@ -381,11 +381,13 @@ static void vc4_hdmi_write_infoframe(struct drm_encoder
*encoder,
DRM_ERROR("Failed to wait for infoframe to start: %d\n", ret);
}
-static void vc4_hdmi_set_avi_infoframe(struct drm_encoder *encoder)
+static void vc4_hdmi_set_avi_infoframe(struct vc4_hdmi *vc4_hdmi,
+ struct drm_atomic_state *state)
{
- struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+ struct drm_encoder *encoder = &vc4_hdmi->encoder.base.base;
struct drm_connector *connector = &vc4_hdmi->connector;
- struct drm_connector_state *cstate = connector->state;
+ struct drm_connector_state *cstate =
+ drm_atomic_get_new_connector_state(state, connector);
struct drm_crtc *crtc = encoder->crtc;
const struct drm_display_mode *mode = &crtc->state->adjusted_mode;
union hdmi_infoframe frame;
@@ -406,10 +408,10 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder
*encoder)
drm_hdmi_avi_infoframe_bars(&frame.avi, cstate);
- vc4_hdmi_write_infoframe(encoder, &frame);
+ vc4_hdmi_write_infoframe(vc4_hdmi, &frame);
}
-static void vc4_hdmi_set_spd_infoframe(struct drm_encoder *encoder)
+static void vc4_hdmi_set_spd_infoframe(struct vc4_hdmi *vc4_hdmi)
{
union hdmi_infoframe frame;
int ret;
@@ -422,12 +424,11 @@ static void vc4_hdmi_set_spd_infoframe(struct drm_encoder
*encoder)
frame.spd.sdi = HDMI_SPD_SDI_PC;
- vc4_hdmi_write_infoframe(encoder, &frame);
+ vc4_hdmi_write_infoframe(vc4_hdmi, &frame);
}
-static void vc4_hdmi_set_audio_infoframe(struct drm_encoder *encoder)
+static void vc4_hdmi_set_audio_infoframe(struct vc4_hdmi *vc4_hdmi)
{
- struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
union hdmi_infoframe frame;
hdmi_audio_infoframe_init(&frame.audio);
@@ -437,21 +438,19 @@ static void vc4_hdmi_set_audio_infoframe(struct
drm_encoder *encoder)
frame.audio.sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
frame.audio.channels = vc4_hdmi->audio.channels;
- vc4_hdmi_write_infoframe(encoder, &frame);
+ vc4_hdmi_write_infoframe(vc4_hdmi, &frame);
}
-static void vc4_hdmi_set_infoframes(struct drm_encoder *encoder)
+static void vc4_hdmi_set_infoframes(struct vc4_hdmi *vc4_hdmi, struct
drm_atomic_state *state)
{
- struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
-
- vc4_hdmi_set_avi_infoframe(encoder);
- vc4_hdmi_set_spd_infoframe(encoder);
+ vc4_hdmi_set_avi_infoframe(vc4_hdmi, state);
+ vc4_hdmi_set_spd_infoframe(vc4_hdmi);
/*
* If audio was streaming, then we need to reenabled the audio
* infoframe here during encoder_enable.
*/
if (vc4_hdmi->audio.streaming)
- vc4_hdmi_set_audio_infoframe(encoder);
+ vc4_hdmi_set_audio_infoframe(vc4_hdmi);
}
static void vc4_hdmi_bridge_post_crtc_disable(struct drm_bridge *bridge,
@@ -921,7 +920,7 @@ static void vc4_hdmi_bridge_post_crtc_enable(struct
drm_bridge *bridge,
HDMI_WRITE(HDMI_RAM_PACKET_CONFIG,
VC4_HDMI_RAM_PACKET_ENABLE);
- vc4_hdmi_set_infoframes(encoder);
+ vc4_hdmi_set_infoframes(vc4_hdmi, state);
}
vc4_hdmi_recenter_fifo(vc4_hdmi);
@@ -1184,7 +1183,6 @@ static int vc4_hdmi_audio_hw_params(struct
snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct vc4_hdmi
Re: [PATCH 4/7] drm/ttm: move the page_alignment into the BO
On Wed, 14 Apr 2021 at 10:57, Christian König
wrote:
>
> Am 14.04.21 um 11:46 schrieb Matthew Auld:
> > On Tue, 13 Apr 2021 at 14:53, Christian König
> > wrote:
> >> The alignment is a constant property and shouldn't change.
> >>
> >> Signed-off-by: Christian König
> > What is page alignment here? Is it just for HW restrictions, say if it
> > requires 64K pages with the same physical alignment for VRAM or
> > something? But then wouldn't it make more sense for that to remain as
> > a property of the resource, and not the object? Or am I
> > misunderstanding something?
>
> The page_alignment (bad name btw) is the physical base alignment of the
> allocation.
>
> I want to make resource allocation optional in the mid term, and this is
> the only information we currently don't have otherwise.
>
> The most sense would it make in the placement, since it is really an
> allocation restriction. But I would need to rework the placement
> handling in amdgpu for this to be consistent first.
>
> Regards,
> Christian.
>
> >
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 +-
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 +++--
> >> drivers/gpu/drm/radeon/radeon_object.h | 2 +-
> >> drivers/gpu/drm/ttm/ttm_bo.c | 3 +--
> >> drivers/gpu/drm/ttm/ttm_range_manager.c | 5 ++---
> >> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 15 ---
> >> include/drm/ttm/ttm_bo_api.h | 1 +
> >> include/drm/ttm/ttm_resource.h | 1 -
> >> 10 files changed, 19 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >> index b443907afcea..f1c397be383d 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> >> @@ -763,7 +763,7 @@ int amdgpu_gem_op_ioctl(struct drm_device *dev, void
> >> *data,
> >> void __user *out = u64_to_user_ptr(args->value);
> >>
> >> info.bo_size = robj->tbo.base.size;
> >> - info.alignment = robj->tbo.mem.page_alignment <<
> >> PAGE_SHIFT;
> >> + info.alignment = robj->tbo.page_alignment << PAGE_SHIFT;
> >> info.domains = robj->preferred_domains;
> >> info.domain_flags = robj->flags;
> >> amdgpu_bo_unreserve(robj);
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> >> index 8860545344c7..c026972ca9a1 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> >> @@ -136,7 +136,7 @@ static int amdgpu_gtt_mgr_new(struct
> >> ttm_resource_manager *man,
> >>
> >> spin_lock(&mgr->lock);
> >> r = drm_mm_insert_node_in_range(&mgr->mm, &node->node,
> >> mem->num_pages,
> >> - mem->page_alignment, 0,
> >> place->fpfn,
> >> + tbo->page_alignment, 0,
> >> place->fpfn,
> >> place->lpfn, DRM_MM_INSERT_BEST);
> >> spin_unlock(&mgr->lock);
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> >> index 9ac37569823f..ae4a68db87c0 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> >> @@ -184,7 +184,7 @@ static inline unsigned amdgpu_bo_ngpu_pages(struct
> >> amdgpu_bo *bo)
> >>
> >> static inline unsigned amdgpu_bo_gpu_page_alignment(struct amdgpu_bo *bo)
> >> {
> >> - return (bo->tbo.mem.page_alignment << PAGE_SHIFT) /
> >> AMDGPU_GPU_PAGE_SIZE;
> >> + return (bo->tbo.page_alignment << PAGE_SHIFT) /
> >> AMDGPU_GPU_PAGE_SIZE;
> >> }
> >>
> >> /**
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> >> index 1fc7ec0b8915..38b1995d0d6c 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> >> @@ -392,7 +392,8 @@ static int amdgpu_vram_mgr_new(struct
> >> ttm_resource_manager *man,
> >> /* default to 2MB */
> >> pages_per_node = (2UL << (20UL - PAGE_SHIFT));
> >> #endif
> >> - pages_per_node = max((uint32_t)pages_per_node,
> >> mem->page_alignment);
> >> + pages_per_node = max((uint32_t)pages_per_node,
> >> +tbo->page_alignment);
> >> num_nodes = DIV_ROUND_UP(mem->num_pages, pages_per_node);
> >> }
> >>
> >> @@ -431,7 +432,7 @@ static int amdgpu_vram_mgr_new(struct
> >> ttm_resource_manager *man,
> >>
> >> for (; pages_left; ++i) {
> >> unsigned long pages =
Re: [PATCH 8/9] drm/ttm: Don't count pages in SG BOs against pages_limit
Am 2021-04-14 um 8:25 a.m. schrieb Daniel Vetter: >> Sorry I though that this would be obvious :) >> >> I've already pushed the patch in the morning, but going to keep that in >> mind for the next time. > I'll keep reminding you to pls elaborate more in commit messages, it's > coming up every once in a while :-) It was actually my patch and commit message. I was not aware of the history of this bug or the fact that it was a regression. Otherwise I would have included a "Fixes:" tag. From my point of view it was just a pretty obvious problem exposed when testing my DMA mapping patch series for KFD. Regards, Felix > > Also in general I think a few days of letting patches soak out there, > especially shared code, is good curtesy. Some folks demand 2 weeks, > which I think is too much, but less than 24h just means you're > guaranteed to leave out half the globe with their feedback. Which > isn't great. > > Driver code I don't care since there you know all the stakeholders ofc. > -Daniel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2, 0/5] Revert "mailbox: mediatek: remove implementation related to atomic_exec"
On Wed, Apr 14, 2021 at 3:51 AM Matthias Brugger wrote: > > > > On 12/04/2021 17:29, Jassi Brar wrote: > > On Mon, Apr 12, 2021 at 6:18 AM Yongqiang Niu > > wrote: > >> > >> This series base linux 5.12-rc2 > >> these patches will cause home ui flick when cursor moved, > >> there is no fix solution yet, revert these patches first. > >> > >> change since v1: > >> add mtk-gce.txt and dts modification > >> > >> Yongqiang Niu (5): > >> Revert "drm/mediatek: Make sure previous message done or be aborted > >> before send" > >> Revert "mailbox: mediatek: remove implementation related to > >> atomic_exec" > >> Revert "dt-bindings: mailbox: mtk-gce: fix incorrect mbox-cells value" > >> Revert "arm64: dts: mediatek: mt8183: fix gce incorrect mbox-cells > >> value" > >> arm64: dts: mediatek: mt8183: add gce information for mmsys > >> > >> .../devicetree/bindings/mailbox/mtk-gce.txt| 2 +- > >> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 5 +- > >> drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 1 - > >> drivers/mailbox/mtk-cmdq-mailbox.c | 80 > >> +++--- > >> 4 files changed, 76 insertions(+), 12 deletions(-) > >> > > Please break the patchsets (this and the other 3) into mailbox only > > and platform specific ones. > > Also, it would help if there are some acked/reviewed by some mtk folks > > especially when reverting patches. > > > > I'd prefer to have DT and mailbox patches together as otherwise the burden on > me > to find out which patches in the driver are needed, and to check if these got > accepted, gets higher. > I meant the patches that need to go via mailbox tree (controller) and the rest. thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209345] [nouveau] unknown chipset (0f22d0a1) (nVidia Tesla K80)
https://bugzilla.kernel.org/show_bug.cgi?id=209345 --- Comment #12 from Alexander von Gluck (kallis...@unixzen.com) --- A new motherboard later.. and after enabling 64-bit PCIe stuff the card posts. ArchLinux 5.11.13 [4.689213] nouveau :0d:00.0: enabling device ( -> 0002) [4.689343] nouveau :0d:00.0: unknown chipset (0f22d0a1) [4.690686] nouveau :0e:00.0: enabling device ( -> 0002) [4.690758] nouveau :0e:00.0: unknown chipset (0f22d0a1) 0d:00.0 3D controller: NVIDIA Corporation GK210GL [Tesla K80] (rev a1) Subsystem: NVIDIA Corporation Device 106c Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [420 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 Capabilities: [900 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: 0 Kernel modules: nouveau 0e:00.0 3D controller: NVIDIA Corporation GK210GL [Tesla K80] (rev a1) Subsystem: NVIDIA Corporation Device 106c Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [420 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 Capabilities: [900 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: 0 Kernel modules: nouveau -- You may reply to this email to add a comment. 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
Re: [Intel-gfx] [PATCH 03/19] drm/i915: Create stolen memory region from local memory
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_info/drm_dbg; userspace likely doesn't care about stolen.
- mem->type is only setup after the region probe, so setting the name
as stolen-local or stolen-system based on this value won't work. Split
system vs local stolen setup to fix this.
- kill all the region->devmem/is_devmem stuff. We already differentiate
the different types of stolen so such things shouldn't be needed
anymore.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 99 +++---
drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 3 +
drivers/gpu/drm/i915/i915_pci.c| 2 +-
drivers/gpu/drm/i915/i915_reg.h| 1 +
drivers/gpu/drm/i915/intel_memory_region.c | 6 ++
drivers/gpu/drm/i915/intel_memory_region.h | 5 +-
6 files changed, 102 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index b0597de206de..56dd58bef5ee 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -10,6 +10,7 @@
#include
#include
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
#include "i915_drv.h"
#include "i915_gem_stolen.h"
@@ -121,6 +122,14 @@ static int i915_adjust_stolen(struct drm_i915_private
*i915,
}
}
+ /*
+* With device local memory, we don't need to check the address range,
+* this is device memory physical address, could overlap with system
+* memory.
+*/
+ if (HAS_LMEM(i915))
+ return 0;
+
/*
* Verify that nothing else uses this physical address. Stolen
* memory should be reserved by the BIOS and hidden from the
@@ -374,8 +383,9 @@ static void icl_get_stolen_reserved(struct drm_i915_private
*i915,
}
}
-static int i915_gem_init_stolen(struct drm_i915_private *i915)
+static int i915_gem_init_stolen(struct intel_memory_region *mem)
{
+ struct drm_i915_private *i915 = mem->i915;
struct intel_uncore *uncore = &i915->uncore;
resource_size_t reserved_base, stolen_top;
resource_size_t reserved_total, reserved_size;
@@ -396,10 +406,10 @@ static int i915_gem_init_stolen(struct drm_i915_private
*i915)
return 0;
}
- if (resource_size(&intel_graphics_stolen_res) == 0)
+ if (resource_size(&mem->region) == 0)
return 0;
- i915->dsm = intel_graphics_stolen_res;
+ i915->dsm = mem->region;
if (i915_adjust_stolen(i915, &i915->dsm))
return 0;
@@ -684,23 +694,36 @@ static int _i915_gem_object_stolen_init(struct
intel_memory_region *mem,
return ret;
}
+struct intel_memory_region *i915_stolen_region(struct drm_i915_private *i915)
+{
+ if (HAS_LMEM(i915))
+ return i915->mm.regions[INTEL_REGION_STOLEN_LMEM];
+
+ return i915->mm.regions[INTEL_REGION_STOLEN_SMEM];
+}
Could be a bikeshedding comment only - especially since I think this
path gets very little used at runtime so it is most likely pointless to
fiddle with it, but it just strikes me a bit not fully elegant to do:
i915_gem_object_create_stolen
-> i915_gem_object_create_region
-> i915_stolen_region
And end up in here, when alternative could be at driver init:
i915->stolen_region_id = HAS_LMEM() ? ... : ...;
i915_gem_object_create_stolen
->
i915_gem_object_create_region(i915->mm.regions[i915->stolen_region_id]);
Or pointer to region. Would avoid having to export i915_stolen_region as
well.
Or is i915->dsm already the right thing? Because..
+
struct drm_i915_gem_object *
i915_gem_object_create_stolen(struct drm_i915_private *i915,
resource_size_t size)
{
- return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_STOLEN_SMEM],
+ return i915_gem_object_create_region(i915_stolen_region(i915),
size, I915_BO_ALLOC_CONTIGUOUS);
}
static int init_stolen(struct intel_memory_region *mem)
{
- intel_memory_region_set_name(mem, "stolen");
+ if (HAS_LMEM(mem->i915)) {
+ if (!io_mapping_init_wc(&mem->iomap,
+ mem->io_start,
+ resource_size(&mem->region)))
+ return -EIO;
+ }
/*
* Initialise stolen early so that we may reserve preallocated
* objects for the BIOS to KMS transition.
*/
- return i915_gem_init_stolen(mem->i915);
+ return i915_gem_init_stolen(mem);
... I find the mem region init paths a bit convoluted, stolen
especially, and struggle to fig
[Bug 209345] [nouveau] unknown chipset (0f22d0a1) (nVidia Tesla K80)
https://bugzilla.kernel.org/show_bug.cgi?id=209345 --- Comment #13 from Ilia Mirkin (imir...@alum.mit.edu) --- See comment #3 - it explains what you need to copy in nouveau to try to load it. -- You may reply to this email to add a comment. 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
Re: [Intel-gfx] [PATCH 04/19] drm/i915/stolen: treat stolen local as normal local memory
On 12/04/2021 10:05, Matthew Auld wrote:
Underneath it's the same stuff, so things like the PTE_LM bits for the
GTT should just keep working as-is.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index ce1c83c13d05..017db8f71130 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -19,7 +19,10 @@ const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops =
{
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
{
- return obj->ops == &i915_gem_lmem_obj_ops;
+ struct intel_memory_region *mr = obj->mm.region;
+
+ return mr && (mr->type == INTEL_MEMORY_LOCAL ||
+ mr->type == INTEL_MEMORY_STOLEN_LOCAL);
}
struct drm_i915_gem_object *
Passable I guess. Although there is also i915_gem_object_is_stolen so it
is not immediately clear what are the semantics of
i915_gem_object_is_lmem vs that one. Almost like we need more
"hierarchy" in region types, or flags of some sort, but I haven't looked
at the callers to have a good idea what would work best.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 05/19] drm/i915/stolen: enforce the min_page_size contract
On 12/04/2021 10:05, Matthew Auld wrote: From: CQ Tang Since stolen can now be device local-memory underneath, we should try to enforce any min_page_size restrictions when allocating pages. Signed-off-by: CQ Tang Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c index 56dd58bef5ee..f713eabb7671 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c @@ -677,7 +677,8 @@ static int _i915_gem_object_stolen_init(struct intel_memory_region *mem, if (!stolen) return -ENOMEM; - ret = i915_gem_stolen_insert_node(i915, stolen, size, 4096); + ret = i915_gem_stolen_insert_node(i915, stolen, size, + mem->min_page_size); if (ret) goto err_free; @@ -817,8 +818,8 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_i915_private *i915, /* KISS and expect everything to be page-aligned */ if (GEM_WARN_ON(size == 0) || - GEM_WARN_ON(!IS_ALIGNED(size, I915_GTT_PAGE_SIZE)) || - GEM_WARN_ON(!IS_ALIGNED(stolen_offset, I915_GTT_MIN_ALIGNMENT))) + GEM_WARN_ON(!IS_ALIGNED(size, mem->min_page_size)) || + GEM_WARN_ON(!IS_ALIGNED(stolen_offset, mem->min_page_size))) return ERR_PTR(-EINVAL); stolen = kzalloc(sizeof(*stolen), GFP_KERNEL); Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 06/19] drm/i915/stolen: pass the allocation flags
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index f713eabb7671..49a2dfcc8ba7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -633,14 +633,15 @@ static const struct drm_i915_gem_object_ops
i915_gem_object_stolen_ops = {
static int __i915_gem_object_create_stolen(struct intel_memory_region *mem,
struct drm_i915_gem_object *obj,
- struct drm_mm_node *stolen)
+ struct drm_mm_node *stolen,
+ unsigned int flags)
{
static struct lock_class_key lock_class;
unsigned int cache_level;
int err;
drm_gem_private_object_init(&mem->i915->drm, &obj->base, stolen->size);
- i915_gem_object_init(obj, &i915_gem_object_stolen_ops, &lock_class, 0);
+ i915_gem_object_init(obj, &i915_gem_object_stolen_ops, &lock_class,
flags);
obj->stolen = stolen;
obj->read_domains = I915_GEM_DOMAIN_CPU | I915_GEM_DOMAIN_GTT;
@@ -682,7 +683,7 @@ static int _i915_gem_object_stolen_init(struct
intel_memory_region *mem,
if (ret)
goto err_free;
- ret = __i915_gem_object_create_stolen(mem, obj, stolen);
+ ret = __i915_gem_object_create_stolen(mem, obj, stolen, flags);
if (ret)
goto err_remove;
@@ -840,7 +841,8 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_i915_private *i915,
goto err_stolen;
}
- ret = __i915_gem_object_create_stolen(mem, obj, stolen);
+ ret = __i915_gem_object_create_stolen(mem, obj, stolen,
+ I915_BO_ALLOC_CONTIGUOUS);
if (ret)
goto err_object_free;
Are all stolen objects always contiguous or only ones allocated by
i915_gem_object_create_stolen_for_preallocated? If former should
__i915_gem_object_create_stolen just set the flag without the need to
pass it in?
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209345] [nouveau] unknown chipset (0f22d0a1) (nVidia Tesla K80)
https://bugzilla.kernel.org/show_bug.cgi?id=209345 --- Comment #14 from Ilia Mirkin (imir...@alum.mit.edu) --- Also, wow, BAR1 = 16GB?? Normally it's like 256MB. No wonder your TB setup had issues. -- You may reply to this email to add a comment. 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 resend 0/9] drm: Add privacy-screen class and connector properties
Hi All, Here is the privacy-screen related code which I last posted in August of last year. To the best of my knowledge there is consensus about / everyone is in agreement with the new userspace API (2 connector properties) this patch-set add (patch 1 of the series). The blocker the last time was that there were no userspace users of the new properties and as a rule we don't add new drm userspace API without users. There now is GNOME userspace code using the new properties: https://hackmd.io/@3v1n0/rkyIy3BOw The new API works as designed for this userspace user and the branches mentioned at the above link add the following features to GNOME: 1. Showing an OSD notification when the privacy-screen is toggled on/off through hotkeys handled by the embedded-controller 2. Allowing control of the privacy-screen from the GNOME control-panel, including the on/off slider shown there updating to match the hw-setting when the setting is changed with the control-panel open. 3. Restoring the last user-setting at login This series consists of a number of different parts: 1. A new version of Rajat's privacy-screen connector properties patch, this adds new userspace API in the form of new properties 2. Since on most devices the privacy screen is actually controlled by some vendor specific ACPI/WMI interface which has a driver under drivers/platform/x86, we need some "glue" code to make this functionality available to KMS drivers. Patches 2-4 add a new privacy-screen class for this, which allows non KMS drivers (and possibly KMS drivers too) to register a privacy-screen device and also adds an interface for KMS drivers to get access to the privacy-screen associated with a specific connector. This is modelled similar to how we deal with e.g. PWMs and GPIOs in the kernel, including separate includes for consumers and providers(drivers). 3. Some drm_connector helper functions to keep the actual changes needed for this in individual KMS drivers as small as possible (patch 5). 4. Make the thinkpad_acpi code register a privacy-screen device on ThinkPads with a privacy-screen (patches 6-8) 5. Make the i915 driver export the privacy-screen functionality through the connector properties on the eDP connector. I believe that it would be best to merge the entire series, including the thinkpad_acpi changes through drm-misc in one go. As the pdx86 subsys maintainer I hereby give my ack for merging the thinkpad_acpi changes through drm-misc. There is one small caveat with this series, which it is good to be aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads with an eprivacy screen, until the thinkpad_acpi driver is loaded. This means that initrd generation tools will need to be updated to include thinkpad_acpi when the i915 driver is added to the initrd. Without this the loading of the i915 driver will be delayed to after the switch to real rootfs. Regards, Hans Hans de Goede (8): drm: Add privacy-screen class drm/privacy-screen: Add X86 specific arch init code drm/privacy-screen: Add notifier support drm/connector: Add a drm_connector privacy-screen helper functions platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once platform/x86: thinkpad_acpi: Register a privacy-screen device drm/i915: Add privacy-screen support Rajat Jain (1): drm/connector: Add support for privacy-screen properties (v4) Documentation/gpu/drm-kms-helpers.rst| 15 + Documentation/gpu/drm-kms.rst| 2 + MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 5 + drivers/gpu/drm/Makefile | 4 + drivers/gpu/drm/drm_atomic_uapi.c| 4 + drivers/gpu/drm/drm_connector.c | 214 drivers/gpu/drm/drm_privacy_screen.c | 493 +++ drivers/gpu/drm/drm_privacy_screen_x86.c | 82 +++ drivers/gpu/drm/i915/display/intel_display.c | 5 + drivers/gpu/drm/i915/display/intel_dp.c | 10 + drivers/gpu/drm/i915/i915_pci.c | 12 + drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/thinkpad_acpi.c | 131 +++-- include/drm/drm_connector.h | 56 +++ include/drm/drm_privacy_screen_consumer.h| 32 ++ include/drm/drm_privacy_screen_driver.h | 84 include/drm/drm_privacy_screen_machine.h | 46 ++ 18 files changed, 1162 insertions(+), 42 deletions(-) create mode 100644 drivers/gpu/drm/drm_privacy_screen.c create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c create mode 100644 include/drm/drm_privacy_screen_consumer.h create mode 100644 include/drm/drm_privacy_screen_driver.h create mode 100644 include/drm/drm_privacy_screen_machine.h -- 2.31.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesk
[PATCH resend 2/9] drm: Add privacy-screen class
On some new laptops the LCD panel has a builtin electronic privacy-screen. We want to export this functionality as a property on the drm connector object. But often this functionality is not exposed on the GPU but on some other (ACPI) device. This commit adds a privacy-screen class allowing the driver for these other devices to register themselves as a privacy-screen provider; and allowing the drm/kms code to get a privacy-screen provider associated with a specific GPU/connector combo. Signed-off-by: Hans de Goede --- Documentation/gpu/drm-kms-helpers.rst | 15 + MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 5 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_privacy_screen.c | 426 ++ include/drm/drm_privacy_screen_consumer.h | 27 ++ include/drm/drm_privacy_screen_driver.h | 80 include/drm/drm_privacy_screen_machine.h | 41 +++ 8 files changed, 603 insertions(+) create mode 100644 drivers/gpu/drm/drm_privacy_screen.c create mode 100644 include/drm/drm_privacy_screen_consumer.h create mode 100644 include/drm/drm_privacy_screen_driver.h create mode 100644 include/drm/drm_privacy_screen_machine.h diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 389892f36185..5d8715d2f998 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -423,3 +423,18 @@ Legacy CRTC/Modeset Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c :export: + +Privacy-screen class + + +.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c + :doc: overview + +.. kernel-doc:: include/drm/drm_privacy_screen_driver.h + :internal: + +.. kernel-doc:: include/drm/drm_privacy_screen_machine.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c + :export: diff --git a/MAINTAINERS b/MAINTAINERS index 7c45120759e6..8220295b2670 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6129,6 +6129,14 @@ F: drivers/gpu/drm/drm_panel.c F: drivers/gpu/drm/panel/ F: include/drm/drm_panel.h +DRM PRIVACY-SCREEN CLASS +M: Hans de Goede +L: dri-devel@lists.freedesktop.org +S: Maintained +T: git git://anongit.freedesktop.org/drm/drm-misc +F: drivers/gpu/drm/drm_privacy_screen* +F: include/drm/drm_privacy_screen* + DRM TTM SUBSYSTEM M: Christian Koenig M: Huang Rui diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3c16bd1afd87..da25ff3a0a34 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -474,3 +474,8 @@ config DRM_PANEL_ORIENTATION_QUIRKS config DRM_LIB_RANDOM bool default n + +# Separate option, used by drivers outside of drivers/gpu/drm +config DRM_PRIVACY_SCREEN + tristate + default n diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 5279db4392df..9a802605249d 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -62,6 +62,7 @@ obj-$(CONFIG_DRM) += drm.o obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o +obj-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o obj-y += arm/ obj-$(CONFIG_DRM_TTM) += ttm/ obj-$(CONFIG_DRM_SCHED)+= scheduler/ diff --git a/drivers/gpu/drm/drm_privacy_screen.c b/drivers/gpu/drm/drm_privacy_screen.c new file mode 100644 index ..6296fd46156c --- /dev/null +++ b/drivers/gpu/drm/drm_privacy_screen.c @@ -0,0 +1,426 @@ +// SPDX-License-Identifier: MIT +/* + * Copyright (C) 2020 Red Hat, Inc. + * + * Authors: + * Hans de Goede + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/** + * DOC: overview + * + * This class allows non KMS drivers, from e.g. drivers/platform/x86 to + * register a privacy-screen device, which the KMS drivers can then use + * to implement the standard privacy-screen properties, see + * :ref:`Standard Connector Properties`. + * + * KMS drivers using a privacy-screen class device are advised to use the + * drm_connector_attach_privacy_screen_provider() and + * drm_connector_update_privacy_screen() helpers for dealing with this. + */ + +#define to_drm_privacy_screen(dev) \ + container_of(dev, struct drm_privacy_screen, dev) + +static DEFINE_MUTEX(drm_privacy_screen_lookup_lock); +static LIST_HEAD(drm_privacy_screen_lookup_list); + +static DEFINE_MUTEX(drm_privacy_screen_devs_lock); +static LIST_HEAD(drm_privacy_screen_devs); + +/*** drm_privacy_screen_machine.h functions ***/ + +/** + * drm_privacy_screen_lookup_add - add an entry to the static privacy-screen + *lookup list + * @lookup: lookup list entry to add + * + * Add an entry to the static privacy-screen lookup list. Note the + * &struct list_head which is part of the &struct drm_privacy_scr
[PATCH resend 1/9] drm/connector: Add support for privacy-screen properties (v4)
From: Rajat Jain
Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.
Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
"privacy-screen hw-state", to deal with devices where the OS might be
locked out of making state changes
- Write kerneldoc explaining how the 2 properties work together, what
happens when changes to the state are made outside of the DRM code's
control, etc.
Changes in v3 (Hans de Goede)
- Some small tweaks to the kerneldoc describing the 2 properties
Changes in v4 (Hans de Goede)
- Change the "Enabled, locked" and "Disabled, locked" hw-state enum value
names to "Enabled-locked" and "Disabled-locked". The xrandr command shows
all possible enum values separated by commas in its output, so having a
comma in an enum name is not a good idea.
- Do not add a privacy_screen_hw_state member to drm_connector_state
since this property is immutable its value must be directly stored in the
obj->properties->values array
Signed-off-by: Rajat Jain
Co-authored-by: Hans de Goede
Acked-by: Pekka Paalanen
Reviewed-by: Mario Limonciello
Signed-off-by: Hans de Goede
---
Documentation/gpu/drm-kms.rst | 2 +
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 101 ++
include/drm/drm_connector.h | 44 +
4 files changed, 151 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 87e5023e3f55..36943f2b0c5d 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -475,6 +475,8 @@ Property Types and Blob Property Support
.. kernel-doc:: drivers/gpu/drm/drm_property.c
:export:
+.. _standard_connector_properties:
+
Standard Connector Properties
-
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 268bb69c2e2f..d5339b683156 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -796,6 +796,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
fence_ptr);
} else if (property == connector->max_bpc_property) {
state->max_requested_bpc = val;
+ } else if (property == connector->privacy_screen_sw_state_property) {
+ state->privacy_screen_sw_state = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -873,6 +875,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = 0;
} else if (property == connector->max_bpc_property) {
*val = state->max_requested_bpc;
+ } else if (property == connector->privacy_screen_sw_state_property) {
+ *val = state->privacy_screen_sw_state;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..ca8a76decd4c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1244,6 +1244,46 @@ static const struct drm_prop_enum_list dp_colorspaces[]
= {
* For DVI-I and TVout there is also a matching property "select
subconnector"
* allowing to switch between signal types.
* DP subconnector corresponds to a downstream port.
+ *
+ * privacy-screen sw-state, privacy-screen hw-state:
+ * These 2 optional properties can be used to query the state of the
+ * electronic privacy screen that is available on some displays; and in
+ * some cases also control the state. If a driver implements these
+ * properties then both properties must be present.
+ *
+ * "privacy-screen hw-state" is read-only and reflects the actual state
+ * of the privacy-screen, possible values: "Enabled", "Disabled,
+ * "Enabled-locked", "Disabled-locked". The locked states indicate
+ * that the state cannot be changed through the DRM API. E.g. there
+ * might be devices where the firmware-setup options, or a hardware
+ * slider-switch, offer always on / off modes.
+ *
+ * "privacy-screen sw-state" can be set to change the privacy-screen state
+ * when not locked. In this case the driver must update the hw-state
+ * property to reflect the new state on completion of the commit of the
+ * sw-state property. Setting the sw-state property when the hw-state is
+ * locked must be interpreted by the driver as a request to change the
+ * state to the set state when the hw-state becomes unlocked. E.g. if
+ * "privacy-screen hw-state" is "Enabled-locked" and the sw-state
+ * gets set t
[PATCH resend 3/9] drm/privacy-screen: Add X86 specific arch init code
Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.
This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Makefile | 5 +-
drivers/gpu/drm/drm_privacy_screen_x86.c | 82
include/drm/drm_privacy_screen_machine.h | 5 ++
3 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 9a802605249d..75166bd53e00 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -58,11 +58,14 @@ drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/
+drm_privacy_screen_helper-y := drm_privacy_screen.o
+drm_privacy_screen_helper-$(CONFIG_X86) += drm_privacy_screen_x86.o
+obj-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen_helper.o
+
obj-$(CONFIG_DRM) += drm.o
obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o
obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
-obj-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
obj-y += arm/
obj-$(CONFIG_DRM_TTM) += ttm/
obj-$(CONFIG_DRM_SCHED)+= scheduler/
diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c
b/drivers/gpu/drm/drm_privacy_screen_x86.c
new file mode 100644
index ..f486d9087819
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede
+ */
+
+#include
+#include
+
+static struct drm_privacy_screen_lookup arch_lookup;
+
+struct arch_init_data {
+ struct drm_privacy_screen_lookup lookup;
+ bool (*detect)(void);
+};
+
+static acpi_status __init acpi_set_handle(acpi_handle handle, u32 level,
+ void *context, void **return_value)
+{
+ *(acpi_handle *)return_value = handle;
+ return AE_CTRL_TERMINATE;
+}
+
+static bool __init detect_thinkpad_privacy_screen(void)
+{
+ union acpi_object obj = { .type = ACPI_TYPE_INTEGER };
+ struct acpi_object_list args = { .count = 1, .pointer = &obj, };
+ acpi_handle ec_handle = NULL;
+ unsigned long long output;
+ acpi_status status;
+
+ /* Get embedded-controller handle */
+ status = acpi_get_devices("PNP0C09", acpi_set_handle, NULL, &ec_handle);
+ if (ACPI_FAILURE(status) || !ec_handle)
+ return false;
+
+ /* And call the privacy-screen get-status method */
+ status = acpi_evaluate_integer(ec_handle, "HKEY.GSSS", &args, &output);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ return (output & 0x1) ? true : false;
+}
+
+static const struct arch_init_data arch_init_data[] __initconst = {
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+ {
+ .lookup = {
+ .dev_id = NULL,
+ .con_id = NULL,
+ .provider = "thinkpad_acpi",
+ },
+ .detect = detect_thinkpad_privacy_screen,
+ },
+#endif
+};
+
+void __init drm_privacy_screen_arch_init(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(arch_init_data); i++) {
+ if (!arch_init_data[i].detect())
+ continue;
+
+ pr_info("Found '%s' privacy-screen provider\n",
+ arch_init_data[i].lookup.provider);
+
+ /* Make a copy because arch_init_data is __initconst */
+ arch_lookup = arch_init_data[i].lookup;
+ drm_privacy_screen_lookup_add(&arch_lookup);
+ break;
+ }
+}
+
+void __exit drm_privacy_screen_arch_exit(void)
+{
+ if (arch_lookup.provider)
+ drm_privacy_screen_lookup_remove(&arch_lookup);
+}
diff --git a/include/drm/drm_privacy_screen_machine.h
b/include/drm/drm_privacy_screen_machine.h
index 55f4b4fd8e4e..0d2f2a443e8c 100644
--- a/include/drm/drm_privacy_screen_machine.h
+++ b/include/drm/drm_privacy_screen_machine.h
@@ -31,11 +31,16 @@ struct drm_privacy_screen_lookup {
void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup *lookup);
void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup
*lookup);
+#ifdef CONFIG_X86
+void drm_privacy_screen_arch_init(void);
+void drm_privacy_screen_arch_exit(void);
+#else
static inline void drm_privacy_screen_arch_init(void)
{
}
static inline void drm_privacy_screen_arch_exit(void)
{
}
+#endif
#endif
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/
[PATCH resend 4/9] drm/privacy-screen: Add notifier support
Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_privacy_screen.c | 67 +++
include/drm/drm_privacy_screen_consumer.h | 5 ++
include/drm/drm_privacy_screen_driver.h | 4 ++
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/drm_privacy_screen.c
b/drivers/gpu/drm/drm_privacy_screen.c
index 6296fd46156c..7e78b4068e8f 100644
--- a/drivers/gpu/drm/drm_privacy_screen.c
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -254,6 +254,49 @@ void drm_privacy_screen_get_state(struct
drm_privacy_screen *priv,
}
EXPORT_SYMBOL(drm_privacy_screen_get_state);
+/**
+ * drm_privacy_screen_register_notifier - register a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Register a notifier with the privacy-screen to be notified of changes made
+ * to the privacy-screen state from outside of the privacy-screen class.
+ * E.g. the state may be changed by the hardware itself in response to a
+ * hotkey press.
+ *
+ * The notifier is called with no locks held. The new hw_state and sw_state
+ * can be retrieved using the drm_privacy_screen_get_state() function.
+ * A pointer to the drm_privacy_screen's struct is passed as the void *data
+ * argument of the notifier_block's notifier_call.
+ *
+ * The notifier will NOT be called when changes are made through
+ * drm_privacy_screen_set_sw_state(). It is only called for external changes.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&priv->notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_register_notifier);
+
+/**
+ * drm_privacy_screen_unregister_notifier - unregister a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Unregister a notifier registered with
drm_privacy_screen_register_notifier().
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+ struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&priv->notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_unregister_notifier);
+
/*** drm_privacy_screen_driver.h functions ***/
static ssize_t sw_state_show(struct device *dev,
@@ -352,6 +395,7 @@ struct drm_privacy_screen *drm_privacy_screen_register(
return ERR_PTR(-ENOMEM);
mutex_init(&priv->lock);
+ BLOCKING_INIT_NOTIFIER_HEAD(&priv->notifier_head);
priv->dev.class = &drm_privacy_screen_class;
priv->dev.parent = parent;
@@ -399,6 +443,29 @@ void drm_privacy_screen_unregister(struct
drm_privacy_screen *priv)
}
EXPORT_SYMBOL(drm_privacy_screen_unregister);
+/**
+ * drm_privacy_screen_call_notifier_chain - notify consumers of state change
+ * @priv: Privacy screen to register the notifier with
+ *
+ * A privacy-screen provider driver can call this functions upon external
+ * changes to the privacy-screen state. E.g. the state may be changed by the
+ * hardware itself in response to a hotkey press.
+ * This function must be called without holding the privacy-screen lock.
+ * the driver must update sw_state and hw_state to reflect the new state before
+ * calling this function.
+ * The expected behavior from the driver upon receiving an external state
+ * change event is: 1. Take the lock; 2. Update sw_state and hw_state;
+ * 3. Release the lock. 4. Call drm_privacy_screen_call_notifier_chain().
+ */
+void drm_privacy_screen_call_notifier_chain(struct drm_privacy_screen *priv)
+{
+ if (WARN_ON(mutex_is_locked(&priv->lock)))
+ return;
+
+ blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
+}
+EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
+
static int __init drm_privacy_screen_init(void)
{
int ret;
diff --git a/include/drm/drm_privacy_screen_consumer.h
b/include/drm/drm_privacy_screen_consumer.h
index 169ba72bd60d..1f33dc1457ff 100644
--- a/include/drm/drm_privacy_screen_consumer.h
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -24,4 +24,9 @@ void drm_privacy_screen_get_state(struct drm_privacy_screen
*priv,
enum drm_privacy_screen_status *sw_state_ret,
enum drm_privacy_screen_status *hw_state_ret);
+int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+struct notifier_block *nb);
+int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+ struct notif
[PATCH resend 6/9] platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper
Factor the extended hotkey handling out of hotkey_notify_hotkey() and
into a new hotkey_notify_extended_hotkey() helper.
This is a preparation patch for adding support the privacy-screen hotkey
toggle (which needs some special handling, it should NOT send an evdev
key-event to userspace...).
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 30 ++--
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 0d9e2ddbf904..683c175cc28a 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3878,6 +3878,24 @@ static bool
adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
}
}
+static bool hotkey_notify_extended_hotkey(const u32 hkey)
+{
+ unsigned int scancode;
+
+ /* Extended keycodes start at 0x300 and our offset into the map
+* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
+* will be positive, but might not be in the correct range.
+*/
+ scancode = (hkey & 0xfff) - (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
+ if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
+ scancode < TPACPI_HOTKEY_MAP_LEN) {
+ tpacpi_input_send_key(scancode);
+ return true;
+ }
+
+ return false;
+}
+
static bool hotkey_notify_hotkey(const u32 hkey,
bool *send_acpi_ev,
bool *ignore_acpi_ev)
@@ -3912,17 +3930,7 @@ static bool hotkey_notify_hotkey(const u32 hkey,
return adaptive_keyboard_hotkey_notify_hotkey(scancode);
case 3:
- /* Extended keycodes start at 0x300 and our offset into the map
-* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
-* will be positive, but might not be in the correct range.
-*/
- scancode -= (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
- if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
- scancode < TPACPI_HOTKEY_MAP_LEN) {
- tpacpi_input_send_key(scancode);
- return true;
- }
- break;
+ return hotkey_notify_extended_hotkey(hkey);
}
return false;
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH resend 5/9] drm/connector: Add a drm_connector privacy-screen helper functions
Add 2 drm_connector privacy-screen helper functions:
1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen status.
2. drm_connector_update_privacy_screen(), Check if the passed in atomic
state contains a privacy-screen sw_state change for the connector and if
it does, call drm_privacy_screen_set_sw_state() with the new sw_state.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 113
include/drm/drm_connector.h | 12
2 files changed, 125 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ca8a76decd4c..958a332374af 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -20,6 +20,7 @@
* OF THIS SOFTWARE.
*/
+#include
#include
#include
#include
@@ -27,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -451,6 +453,11 @@ void drm_connector_cleanup(struct drm_connector *connector)
DRM_CONNECTOR_REGISTERED))
drm_connector_unregister(connector);
+ if (connector->privacy_screen) {
+ drm_privacy_screen_put(connector->privacy_screen);
+ connector->privacy_screen = NULL;
+ }
+
if (connector->tile_group) {
drm_mode_put_tile_group(dev, connector->tile_group);
connector->tile_group = NULL;
@@ -530,6 +537,10 @@ int drm_connector_register(struct drm_connector *connector)
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(connector->dev);
+ if (connector->privacy_screen)
+ drm_privacy_screen_register_notifier(connector->privacy_screen,
+ &connector->privacy_screen_notifier);
+
goto unlock;
err_debugfs:
@@ -558,6 +569,11 @@ void drm_connector_unregister(struct drm_connector
*connector)
return;
}
+ if (connector->privacy_screen)
+ drm_privacy_screen_unregister_notifier(
+ connector->privacy_screen,
+ &connector->privacy_screen_notifier);
+
if (connector->funcs->early_unregister)
connector->funcs->early_unregister(connector);
@@ -2353,6 +2369,103 @@ drm_connector_attach_privacy_screen_properties(struct
drm_connector *connector)
}
EXPORT_SYMBOL(drm_connector_attach_privacy_screen_properties);
+static void drm_connector_update_privacy_screen_properties(
+ struct drm_connector *connector)
+{
+ enum drm_privacy_screen_status sw_state, hw_state;
+
+ drm_privacy_screen_get_state(connector->privacy_screen,
+&sw_state, &hw_state);
+
+ connector->state->privacy_screen_sw_state = sw_state;
+ drm_object_property_set_value(&connector->base,
+ connector->privacy_screen_hw_state_property, hw_state);
+}
+
+static int drm_connector_privacy_screen_notifier(
+ struct notifier_block *nb, unsigned long action, void *data)
+{
+ struct drm_connector *connector =
+ container_of(nb, struct drm_connector, privacy_screen_notifier);
+ struct drm_device *dev = connector->dev;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ drm_connector_update_privacy_screen_properties(connector);
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ drm_sysfs_connector_status_event(connector,
+ connector->privacy_screen_sw_state_property);
+ drm_sysfs_connector_status_event(connector,
+ connector->privacy_screen_hw_state_property);
+
+ return NOTIFY_DONE;
+}
+
+/**
+ * drm_connector_attach_privacy_screen_provider - attach a privacy-screen to
+ *the connector
+ * @connector: connector to attach the privacy-screen to
+ * @priv: drm_privacy_screen to attach
+ *
+ * Create and attach the standard privacy-screen properties and register
+ * a generic notifier for generating sysfs-connector-status-events
+ * on external changes to the privacy-screen status.
+ * This function takes ownership of the passed in drm_privacy_screen and will
+ * call drm_privacy_screen_put() on it when the connector is destroyed.
+ */
+void drm_connector_attach_privacy_screen_provider(
+ struct drm_connector *connector, struct drm_privacy_screen *priv)
+{
+ connector->privacy_screen = priv;
+ connector->privacy_screen_notifier.notifier_call =
+ drm_connector_privacy_screen_notifier;
+
+ drm_connector_create_privacy_screen_properties(connector);
+ drm_connector_update_privacy_screen_properties(connector);
+ drm_connector_attach_privacy_screen_properties(connector
[PATCH resend 7/9] platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 683c175cc28a..fe919700b8ae 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9759,19 +9759,15 @@ static struct ibm_struct battery_driver_data = {
* LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
*/
+static acpi_handle lcdshadow_get_handle;
+static acpi_handle lcdshadow_set_handle;
static int lcdshadow_state;
static int lcdshadow_on_off(bool state)
{
- acpi_handle set_shadow_handle;
int output;
- if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "",
&set_shadow_handle))) {
- pr_warn("Thinkpad ACPI has no %s interface.\n", "");
- return -EIO;
- }
-
- if (!acpi_evalf(set_shadow_handle, &output, NULL, "dd", (int)state))
+ if (!acpi_evalf(lcdshadow_set_handle, &output, NULL, "dd", (int)state))
return -EIO;
lcdshadow_state = state;
@@ -9789,15 +9785,17 @@ static int lcdshadow_set(bool on)
static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
{
- acpi_handle get_shadow_handle;
+ acpi_status status1, status2;
int output;
- if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "GSSS",
&get_shadow_handle))) {
+ status1 = acpi_get_handle(hkey_handle, "GSSS", &lcdshadow_get_handle);
+ status2 = acpi_get_handle(hkey_handle, "", &lcdshadow_set_handle);
+ if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
lcdshadow_state = -ENODEV;
return 0;
}
- if (!acpi_evalf(get_shadow_handle, &output, NULL, "dd", 0)) {
+ if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0)) {
lcdshadow_state = -EIO;
return -EIO;
}
--
2.31.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH resend 8/9] platform/x86: thinkpad_acpi: Register a privacy-screen device
Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.
Registering a privacy-screen device with the new privacy-screen class
code will also allow the GPU driver to get a handle to it and export
the privacy-screen setting as a property on the DRM connector object
for the LCD panel. This DRM connector property is news standardized
interface which all user-space code should use to query and control
the privacy-screen.
Signed-off-by: Hans de Goede
---
Changes in v2:
- Make the new lcdshadow_set_sw_state, lcdshadow_get_hw_state and
lcdshadow_ops symbols static
- Update state and call drm_privacy_screen_call_notifier_chain()
when the state is changed by pressing the Fn + D hotkey combo
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/thinkpad_acpi.c | 91
2 files changed, 67 insertions(+), 25 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 461ec61530eb..404d80f99a03 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -485,6 +485,7 @@ config THINKPAD_ACPI
depends on ACPI_VIDEO || ACPI_VIDEO = n
depends on BACKLIGHT_CLASS_DEVICE
select ACPI_PLATFORM_PROFILE
+ select DRM_PRIVACY_SCREEN
select HWMON
select NVRAM
select NEW_LEDS
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index fe919700b8ae..766c6d64b0fb 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -73,6 +73,7 @@
#include
#include
#include
+#include
/* ThinkPad CMOS commands */
#define TP_CMOS_VOLUME_DOWN0
@@ -156,6 +157,7 @@ enum tpacpi_hkey_event_t {
TP_HKEY_EV_VOL_UP = 0x1015, /* Volume up or unmute */
TP_HKEY_EV_VOL_DOWN = 0x1016, /* Volume down or unmute */
TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
+ TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard on/off */
/* Reasons for waking up from S3/S4 */
TP_HKEY_EV_WKUP_S3_UNDOCK = 0x2304, /* undock requested, S3 */
@@ -3882,6 +3884,12 @@ static bool hotkey_notify_extended_hotkey(const u32 hkey)
{
unsigned int scancode;
+ switch (hkey) {
+ case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
+ tpacpi_driver_event(hkey);
+ return true;
+ }
+
/* Extended keycodes start at 0x300 and our offset into the map
* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
* will be positive, but might not be in the correct range.
@@ -9759,30 +9767,40 @@ static struct ibm_struct battery_driver_data = {
* LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
*/
+static struct drm_privacy_screen *lcdshadow_dev;
static acpi_handle lcdshadow_get_handle;
static acpi_handle lcdshadow_set_handle;
-static int lcdshadow_state;
-static int lcdshadow_on_off(bool state)
+static int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
+ enum drm_privacy_screen_status state)
{
int output;
+ if (WARN_ON(!mutex_is_locked(&priv->lock)))
+ return -EIO;
+
if (!acpi_evalf(lcdshadow_set_handle, &output, NULL, "dd", (int)state))
return -EIO;
- lcdshadow_state = state;
+ priv->hw_state = priv->sw_state = state;
return 0;
}
-static int lcdshadow_set(bool on)
+static void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
{
- if (lcdshadow_state < 0)
- return lcdshadow_state;
- if (lcdshadow_state == on)
- return 0;
- return lcdshadow_on_off(on);
+ int output;
+
+ if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
+ return;
+
+ priv->hw_state = priv->sw_state = output & 0x1;
}
+static const struct drm_privacy_screen_ops lcdshadow_ops = {
+ .set_sw_state = lcdshadow_set_sw_state,
+ .get_hw_state = lcdshadow_get_hw_state,
+};
+
static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
{
acpi_status status1, status2;
@@ -9790,36 +9808,44 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct
*iibm)
status1 = acpi_get_handle(hkey_handle, "GSSS", &lcdshadow_get_handle);
status2 = acpi_get_handle(hkey_handle, "", &lcdshadow_set_handle);
- if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
- lcdshadow_state = -ENODEV;
+ if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2))
return 0;
- }
- if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0)) {
- lcdshadow_state = -EIO;
+ if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
return -EIO;
- }
-
[PATCH resend 9/9] drm/i915: Add privacy-screen support
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.
One thing which stands out here is the addition of these 2 lines to
intel_atomic_commit_tail:
for_each_new_connector_in_state(&state->base, connector, ...
drm_connector_update_privacy_screen(connector, state);
It may seem more logical to instead take care of updating the
privacy-screen state by marking the crtc as needing a modeset and then
do this in both the encoder update_pipe (for fast-sets) and enable
(for full modesets) callbacks. But ATM these callbacks only get passed
the new connector_state and these callbacks are all called after
drm_atomic_helper_swap_state() at which point there is no way to get
the old state from the new state.
Without access to the old state, we do not know if the sw_state of
the privacy-screen has changes so we would need to call
drm_privacy_screen_set_sw_state() unconditionally. This is undesirable
since all current known privacy-screen providers use ACPI calls which
are somewhat expensive to make.
Also, as all providers use ACPI calls, rather then poking GPU registers,
there is no need to order this together with other encoder operations.
Since no GPU poking is involved having this as a separate step of the
commit process actually is the logical thing to do.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +
drivers/gpu/drm/i915/display/intel_dp.c | 10 ++
drivers/gpu/drm/i915/i915_pci.c | 12
3 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 411b46c012f8..620d11d6bb31 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10169,6 +10169,8 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
struct drm_device *dev = state->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc_state *new_crtc_state, *old_crtc_state;
+ struct drm_connector_state *new_connector_state;
+ struct drm_connector *connector;
struct intel_crtc *crtc;
u64 put_domains[I915_MAX_PIPES] = {};
intel_wakeref_t wakeref = 0;
@@ -10266,6 +10268,9 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_color_load_luts(new_crtc_state);
}
+ for_each_new_connector_in_state(&state->base, connector,
new_connector_state, i)
+ drm_connector_update_privacy_screen(connector, &state->base);
+
/*
* Now that the vblank has passed, we can go ahead and program the
* optimal watermarks on platforms that need two-step watermark
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6750949aa261..8ca3909e2ec9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include "g4x_dp.h"
@@ -5178,6 +5179,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
struct drm_connector *connector = &intel_connector->base;
struct drm_display_mode *fixed_mode = NULL;
struct drm_display_mode *downclock_mode = NULL;
+ struct drm_privacy_screen *privacy_screen;
bool has_dpcd;
enum pipe pipe = INVALID_PIPE;
struct edid *edid;
@@ -5268,6 +5270,14 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
fixed_mode->hdisplay, fixed_mode->vdisplay);
}
+ privacy_screen = drm_privacy_screen_get(&dev->pdev->dev, NULL);
+ if (!IS_ERR(privacy_screen)) {
+ drm_connector_attach_privacy_screen_provider(connector,
+privacy_screen);
+ } else if (PTR_ERR(privacy_screen) != -ENODEV) {
+ drm_warn(&dev_priv->drm, "Error getting privacy-screen\n");
+ }
+
return true;
out_vdd_off:
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 480553746794..95426e365400 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -26,6 +26,7 @@
#include
#include
+#include
#include
#include "display/intel_fbdev.h"
@@ -1064,6 +1065,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
{
struct intel_device_info *intel_info =
(struct intel_device_info *) ent->driver_data;
+ struct drm_privacy_screen *privacy_screen;
int err;
if (intel_info->require_force_probe &&
@@ -1092,7 +1094,17 @@ static int i915_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (vga_switcheroo_client_probe_defer(pdev))
return -EPROBE_DEFER;
+
Re: [PATCH 9/9] drm/amdgpu: Lock the attached dmabuf in unpopulate
Am 2021-04-14 um 3:33 a.m. schrieb Christian König:
> Am 14.04.21 um 08:46 schrieb Felix Kuehling:
>> amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The
>> dmabuf->resv
>> must not be held by the caller or dma_buf_detach will deadlock. This is
>> probably not the right fix. I get a recursive lock warning with the
>> reservation held in ttm_bo_release. Should unmap_attachment move to
>> backend_unbind instead?
>
> Yes probably, but I'm really wondering if we should call unpopulate
> without holding the reservation lock.
There is an error handling code path in ttm_tt_populate that calls
unpopulate. I believe that has to be holding the reservation lock. The
other cases (destroy and swapout) do not hold the lock, AIUI.
Regards,
Felix
>
> Christian.
>
>>
>> Signed-off-by: Felix Kuehling
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> index 936b3cfdde55..257750921eed 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
>> @@ -1216,9 +1216,22 @@ static void amdgpu_ttm_tt_unpopulate(struct
>> ttm_device *bdev,
>> if (ttm->sg && gtt->gobj->import_attach) {
>> struct dma_buf_attachment *attach;
>> + bool locked;
>> attach = gtt->gobj->import_attach;
>> + /* FIXME: unpopulate can be called during bo_destroy.
>> + * The dmabuf->resv must not be held by the caller or
>> + * dma_buf_detach will deadlock. This is probably not
>> + * the right fix. I get a recursive lock warning with the
>> + * reservation held in ttm_bo_releas.. Should
>> + * unmap_attachment move to backend_unbind instead?
>> + */
>> + locked = dma_resv_is_locked(attach->dmabuf->resv);
>> + if (!locked)
>> + dma_resv_lock(attach->dmabuf->resv, NULL);
>> dma_buf_unmap_attachment(attach, ttm->sg, DMA_BIDIRECTIONAL);
>> + if (!locked)
>> + dma_resv_unlock(attach->dmabuf->resv);
>> ttm->sg = NULL;
>> return;
>> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/amdkfd: Remove legacy code not acquiring VMs
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
ROCm user mode has acquired VMs from DRM file descriptors for as long
as it supported the upstream KFD. Legacy code to support older versions
of ROCm is not needed any more.
Reviewed-by: Philip Yang
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 4 --
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 50 ---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 27 --
3 files changed, 10 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 14f68c028126..5ffb07b02810 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -234,14 +234,10 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct kgd_dev *dst, struct kgd_dev *s
})
/* GPUVM API */
-int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, u32 pasid,
- void **vm, void **process_info,
- struct dma_fence **ef);
int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
struct file *filp, u32 pasid,
void **vm, void **process_info,
struct dma_fence **ef);
-void amdgpu_amdkfd_gpuvm_destroy_process_vm(struct kgd_dev *kgd, void *vm);
void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *vm);
uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void *vm);
int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index e93850f2f3b1..36012229ccc1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1037,41 +1037,6 @@ static int init_kfd_vm(struct amdgpu_vm *vm, void **process_info,
return ret;
}
-int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, u32 pasid,
- void **vm, void **process_info,
- struct dma_fence **ef)
-{
- struct amdgpu_device *adev = get_amdgpu_device(kgd);
- struct amdgpu_vm *new_vm;
- int ret;
-
- new_vm = kzalloc(sizeof(*new_vm), GFP_KERNEL);
- if (!new_vm)
- return -ENOMEM;
-
- /* Initialize AMDGPU part of the VM */
- ret = amdgpu_vm_init(adev, new_vm, AMDGPU_VM_CONTEXT_COMPUTE, pasid);
- if (ret) {
- pr_err("Failed init vm ret %d\n", ret);
- goto amdgpu_vm_init_fail;
- }
-
- /* Initialize KFD part of the VM and process info */
- ret = init_kfd_vm(new_vm, process_info, ef);
- if (ret)
- goto init_kfd_vm_fail;
-
- *vm = (void *) new_vm;
-
- return 0;
-
-init_kfd_vm_fail:
- amdgpu_vm_fini(adev, new_vm);
-amdgpu_vm_init_fail:
- kfree(new_vm);
- return ret;
-}
-
int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
struct file *filp, u32 pasid,
void **vm, void **process_info,
@@ -1138,21 +1103,6 @@ void amdgpu_amdkfd_gpuvm_destroy_cb(struct amdgpu_device *adev,
}
}
-void amdgpu_amdkfd_gpuvm_destroy_process_vm(struct kgd_dev *kgd, void *vm)
-{
- struct amdgpu_device *adev = get_amdgpu_device(kgd);
- struct amdgpu_vm *avm = (struct amdgpu_vm *)vm;
-
- if (WARN_ON(!kgd || !vm))
- return;
-
- pr_debug("Destroying process vm %p\n", vm);
-
- /* Release the VM context */
- amdgpu_vm_fini(adev, avm);
- kfree(vm);
-}
-
void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *vm)
{
struct amdgpu_device *adev = get_amdgpu_device(kgd);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index d4241d29ea94..d97e330a5022 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -935,9 +935,6 @@ static void kfd_process_destroy_pdds(struct kfd_process *p)
pdd->dev->kgd, pdd->vm);
fput(pdd->drm_file);
}
- else if (pdd->vm)
- amdgpu_amdkfd_gpuvm_destroy_process_vm(
-pdd->dev->kgd, pdd->vm);
if (pdd->qpd.cwsr_kaddr && !pdd->qpd.cwsr_base)
free_pages((unsigned long)pdd->qpd.cwsr_kaddr,
@@ -1375,19 +1372,18 @@ int kfd_process_device_init_vm(struct kfd_process_device *pdd,
struct kfd_dev *dev;
int ret;
+ if (!drm_file)
+ return -EINVAL;
+
if (pdd->vm)
- return drm_file ? -EBUSY : 0;
+ return -EBUSY;
p = pdd->process;
dev = pdd->dev;
- if (drm_file)
- ret = amdgpu_amdkfd_gpuvm_acquire_process_vm(
- dev->kgd, drm_file, p->pasid,
- &pdd->vm, &p->kgd_process_info, &p->ef);
- else
- ret = amdgpu_amdkfd_gpuvm_create_process_vm(dev->kgd, p->pasid,
- &pdd->vm, &p->kgd_process_info, &p->ef);
+ ret = amdgpu_amdkfd_gpuvm_acquire_process_vm(
+ dev->kgd, drm_file, p->pasid,
+ &pdd->vm, &p->kgd_process_info, &p->ef);
if (ret) {
pr_err("Failed to create process VM object\n");
return ret;
@@ -1409,8 +1405,6 @@ int kfd_process_device_init_vm(struct kfd_process_device *pdd,
err_init_cwsr:
err_reserve_ib_mem:
kfd_process_device_free_bos(pdd);
- if (!drm_file)
- amdgpu_amdkfd_gpuvm_destroy_process_vm(dev->kgd, pdd->vm);
pd
Re: [Intel-gfx] [PATCH 08/19] drm/i915: Return error value when bo not in LMEM for discrete
On 12/04/2021 10:05, Matthew Auld wrote:
From: Mohammed Khajapasha
Return EREMOTE value when frame buffer object is not backed by LMEM
for discrete. If Local memory is supported by hardware the framebuffer
backing gem objects should be from local memory.
Signed-off-by: Mohammed Khajapasha
---
drivers/gpu/drm/i915/display/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 411b46c012f8..57b06d8728af 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -63,6 +63,7 @@
#include "display/intel_vdsc.h"
#include "display/intel_vrr.h"
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_object.h"
#include "gt/intel_rps.h"
@@ -11279,11 +11280,20 @@ intel_user_framebuffer_create(struct drm_device *dev,
struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
struct drm_mode_fb_cmd2 mode_cmd = *user_mode_cmd;
+ struct drm_i915_private *i915;
obj = i915_gem_object_lookup(filp, mode_cmd.handles[0]);
if (!obj)
return ERR_PTR(-ENOENT);
+ /* object is backed with LMEM for discrete */
+ i915 = to_i915(obj->base.dev);
+ if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj)) {
+ /* object is "remote", not in local memory */
+ i915_gem_object_put(obj);
+ return ERR_PTR(-EREMOTE);
I am a fan of rich errnos and this one feels appropriately descriptive,
but please get an ack from Daniel or so.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
+ }
+
fb = intel_framebuffer_create(obj, &mode_cmd);
i915_gem_object_put(obj);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/amdkfd: Use drm_priv to pass VM from KFD to amdgpu
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
to access the BO through the corresponding file descriptor.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 14 ++--
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 69 +++
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 +-
3 files changed, 50 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 5ffb07b02810..0d59bebd92af 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -236,20 +236,20 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct kgd_dev *dst, struct kgd_dev *s
/* GPUVM API */
int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
struct file *filp, u32 pasid,
- void **vm, void **process_info,
+ void **process_info,
struct dma_fence **ef);
-void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *vm);
-uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void *vm);
+void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *drm_priv);
+uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void *drm_priv);
int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
struct kgd_dev *kgd, uint64_t va, uint64_t size,
- void *vm, struct kgd_mem **mem,
+ void *drm_priv, struct kgd_mem **mem,
uint64_t *offset, uint32_t flags);
int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *size);
int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
- struct kgd_dev *kgd, struct kgd_mem *mem, void *vm);
+ struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv);
int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
- struct kgd_dev *kgd, struct kgd_mem *mem, void *vm);
+ struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv);
int amdgpu_amdkfd_gpuvm_sync_memory(
struct kgd_dev *kgd, struct kgd_mem *mem, bool intr);
int amdgpu_amdkfd_gpuvm_map_gtt_bo_to_kernel(struct kgd_dev *kgd,
@@ -260,7 +260,7 @@ int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct kgd_dev *kgd,
struct kfd_vm_fault_info *info);
int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev *kgd,
struct dma_buf *dmabuf,
- uint64_t va, void *vm,
+ uint64_t va, void *drm_priv,
struct kgd_mem **mem, uint64_t *size,
uint64_t *mmap_offset);
int amdgpu_amdkfd_get_tile_config(struct kgd_dev *kgd,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 36012229ccc1..95442bcd60fb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -951,6 +951,13 @@ static int process_update_pds(struct amdkfd_process_info *process_info,
return 0;
}
+static struct amdgpu_vm *drm_priv_to_vm(struct drm_file *drm_priv)
+{
+ struct amdgpu_fpriv *fpriv = drm_priv->driver_priv;
+
+ return &fpriv->vm;
+}
+
static int init_kfd_vm(struct amdgpu_vm *vm, void **process_info,
struct dma_fence **ef)
{
@@ -1039,15 +1046,19 @@ static int init_kfd_vm(struct amdgpu_vm *vm, void **process_info,
int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
struct file *filp, u32 pasid,
- void **vm, void **process_info,
+ void **process_info,
struct dma_fence **ef)
{
struct amdgpu_device *adev = get_amdgpu_device(kgd);
- struct drm_file *drm_priv = filp->private_data;
- struct amdgpu_fpriv *drv_priv = drm_priv->driver_priv;
- struct amdgpu_vm *avm = &drv_priv->vm;
+ struct amdgpu_fpriv *drv_priv;
+ struct amdgpu_vm *avm;
int ret;
+ ret = amdgpu_file_to_fpriv(filp, &drv_priv);
+ if (ret)
+ return ret;
+ avm = &drv_priv->vm;
+
/* Already a compute VM? */
if (avm->process_info)
return -EINVAL;
@@ -1062,7 +1073,7 @@ int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
if (ret)
return ret;
- *vm = (void *)avm;
+ amdgpu_vm_set_task_info(avm);
return 0;
}
@@ -1103,15 +1114,17 @@ void amdgpu_amdkfd_gpuvm_destroy_cb(struct amdgpu_device *adev,
}
}
-void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *vm)
+void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *drm_priv)
{
struct amdgpu_device *adev = get_amdgpu_device(kgd);
- struct amdgpu_vm *avm = (struct amdgpu_vm *)vm;
+ struct amdgpu_vm *avm;
- if (WARN_ON(!kgd || !vm))
+ if (WARN_ON(!kgd || !drm_priv))
return;
- pr_debug("Releasing process vm %p\n", vm);
+ avm = drm_priv_to_vm(drm_priv);
+
+ pr_debug("Releasing process vm %p\n", avm);
/* The original pasid of amdgpu vm has already been
* released during making a amdgpu vm to a compute vm
@@ -1122,9 +1135,9 @@ void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *vm)
amdgpu_vm_release_compute(adev, avm);
}
-uint64_
Re: [Intel-gfx] [PATCH 11/19] drm/i915: Update the helper to set correct mapping
On 12/04/2021 10:05, Matthew Auld wrote:
From: Venkata Sandeep Dhanalakota
Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.
Cc: Matthew Auld
Cc: CQ Tang
Suggested-by: Michal Wajdeczko
Signed-off-by: Venkata Sandeep Dhanalakota
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ++-
drivers/gpu/drm/i915/gt/intel_engine_pm.c| 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
drivers/gpu/drm/i915/gt/intel_ring.c | 9 ++---
drivers/gpu/drm/i915/gt/selftest_context.c | 3 ++-
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
drivers/gpu/drm/i915/gt/selftest_lrc.c | 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 4 +++-
drivers/gpu/drm/i915/i915_drv.h | 11 +--
drivers/gpu/drm/i915/selftests/igt_spinner.c | 4 ++--
11 files changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index efe935f80c1a..b79568d370f5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -664,7 +664,8 @@ static int init_status_page(struct intel_engine_cs *engine)
if (ret)
goto err;
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(obj,
+ i915_coherent_map_type(engine->i915,
obj, true));
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
goto err_unpin;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 7c9af86fdb1e..47f4397095e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -23,7 +23,7 @@ static void dbg_poison_ce(struct intel_context *ce)
if (ce->state) {
struct drm_i915_gem_object *obj = ce->state->obj;
- int type = i915_coherent_map_type(ce->engine->i915);
+ int type = i915_coherent_map_type(ce->engine->i915, obj, true);
void *map;
if (!i915_gem_object_trylock(obj))
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e86897cde984..aafe2a4df496 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -903,7 +903,9 @@ lrc_pre_pin(struct intel_context *ce,
GEM_BUG_ON(!i915_vma_is_pinned(ce->state));
*vaddr = i915_gem_object_pin_map(ce->state->obj,
-
i915_coherent_map_type(ce->engine->i915) |
+
i915_coherent_map_type(ce->engine->i915,
+ ce->state->obj,
+ false) |
I915_MAP_OVERRIDE);
return PTR_ERR_OR_ZERO(*vaddr);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
b/drivers/gpu/drm/i915/gt/intel_ring.c
index aee0a77c77e0..3cf6c7e68108 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring.c
@@ -53,9 +53,12 @@ int intel_ring_pin(struct intel_ring *ring, struct
i915_gem_ww_ctx *ww)
if (i915_vma_is_map_and_fenceable(vma))
addr = (void __force *)i915_vma_pin_iomap(vma);
- else
- addr = i915_gem_object_pin_map(vma->obj,
-
i915_coherent_map_type(vma->vm->i915));
+ else {
+ int type = i915_coherent_map_type(vma->vm->i915, vma->obj,
false);
+
+ addr = i915_gem_object_pin_map(vma->obj, type);
+ }
+
if (IS_ERR(addr)) {
ret = PTR_ERR(addr);
goto err_ring;
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index b9bdd1d23243..26685b927169 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -88,7 +88,8 @@ static int __live_context_size(struct intel_engine_cs *engine)
goto err;
vaddr = i915_gem_object_pin_map_unlocked(ce->state->obj,
-
i915_coherent_map_type(engine->i915));
+
i915_coherent_map_type(engine->i915,
+
ce->state->obj, false));
if (IS_ERR(vaddr)) {
err = PTR_ERR(vaddr);
intel_context_unpin(ce);
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 746985971c3a..5b63d4df8c93 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -69,7 +69,7 @@ stati
Re: [Intel-gfx] [PATCH 12/19] drm/i915/lmem: Bypass aperture when lmem is available
On 12/04/2021 10:05, Matthew Auld wrote:
From: Anusha Srivatsa
In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.
v2:
gmch is only relevant for much older hw, therefore we can drop the
has_aperture check since it should always be present on such platforms.
(Chris)
Cc: Ville Syrjälä
Cc: Dhinakaran Pandiyan
Cc: Maarten Lankhorst
Cc: Chris P Wilson
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Cc: Daniele Ceraolo Spurio
Cc: CQ Tang
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 22 +++---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 15 +++
drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 5 +
drivers/gpu/drm/i915/i915_vma.c| 19 +--
4 files changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 2b37959da747..4af40229f5ec 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -139,14 +139,22 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
size = mode_cmd.pitches[0] * mode_cmd.height;
size = PAGE_ALIGN(size);
- /* If the FB is too big, just don't use it since fbdev is not very
-* important and we should probably use that space with FBC or other
-* features. */
obj = ERR_PTR(-ENODEV);
- if (size * 2 < dev_priv->stolen_usable_size)
- obj = i915_gem_object_create_stolen(dev_priv, size);
- if (IS_ERR(obj))
- obj = i915_gem_object_create_shmem(dev_priv, size);
+ if (HAS_LMEM(dev_priv)) {
+ obj = i915_gem_object_create_lmem(dev_priv, size,
+ I915_BO_ALLOC_CONTIGUOUS);
Has to be contiguous? Question for display experts I guess.
[Comes back later.] Ah for iomap? Put a comment to that effect perhaps?
+ } else {
+ /*
+* If the FB is too big, just don't use it since fbdev is not
very
+* important and we should probably use that space with FBC or
other
+* features.
+*/
+ if (size * 2 < dev_priv->stolen_usable_size)
+ obj = i915_gem_object_create_stolen(dev_priv, size);
+ if (IS_ERR(obj))
+ obj = i915_gem_object_create_shmem(dev_priv, size);
+ }
Could we keep the IS_ERR ordered allocation order to save having to
re-indent? Bike shed so optional..
+
if (IS_ERR(obj)) {
drm_err(&dev_priv->drm, "failed to allocate framebuffer\n");
return PTR_ERR(obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 017db8f71130..f44bdd08f7cb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -17,6 +17,21 @@ const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops =
{
.release = i915_gem_object_release_memory_region,
};
+void __iomem *
+i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
+ unsigned long n,
+ unsigned long size)
+{
+ resource_size_t offset;
+
+ GEM_BUG_ON(!i915_gem_object_is_contiguous(obj));
+
+ offset = i915_gem_object_get_dma_address(obj, n);
+ offset -= obj->mm.region->region.start;
+
+ return io_mapping_map_wc(&obj->mm.region->iomap, offset, size);
+}
+
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
{
struct intel_memory_region *mr = obj->mm.region;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
index 036d53c01de9..fac6bc5a5ebb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
@@ -14,6 +14,11 @@ struct intel_memory_region;
extern const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops;
+void __iomem *
+i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
+ unsigned long n,
+ unsigned long size);
+
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj);
struct drm_i915_gem_object *
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 07490db51cdc..e24d33aecac4 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -27,6 +27,7 @@
#include "display/intel_frontbuffer.h"
+#include "gem/i915_gem_lmem.h"
#include "gt/intel_engine.h"
#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_gt.h"
@@ -448,9 +449,11 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
void __iomem *ptr;
int err;
- if (GEM_WARN_ON(!i915_vma_is_map_and_fenceable(vma))) {
- err = -ENODEV;
- goto err;
+ if (!i915_
[Bug 209345] [nouveau] unknown chipset (0f22d0a1) (nVidia Tesla K80)
https://bugzilla.kernel.org/show_bug.cgi?id=209345 --- Comment #15 from Alexander von Gluck (kallis...@unixzen.com) --- Applied my patch above to ArchLinux (5.11.13-arch1-1) and gave it a whirl. Got a little information from nouveou before the system hard locks up. nouveau :0d:00.0: enabling device ( -> 0002) nouveau :0d:00.0: NVIDIA GK120 (0f22d0a1) nouveau :0d:00.0: bios: version 80.21.1f.00.01 nouveau :0d:00.0: fb: 11520 MiB GDDR5 (hard crash) I might get more information from serial... however, ran into an unrelated issue. Cooling! The Tesla K80 got up to 175F+ at idle and I had to shut things down. Need to rig some better cooling solution. -- You may reply to this email to add a comment. 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
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
On 14/04/2021 10:16, Laurent Pinchart wrote:
> Hi Neil,
>
> On Wed, Apr 14, 2021 at 10:08:46AM +0200, Neil Armstrong wrote:
>> On 14/04/2021 10:06, Robert Foss wrote:
>>> On Wed, 14 Apr 2021 at 08:13, Neil Armstrong
>>> wrote:
Le 13/04/2021 à 22:21, Robert Foss a écrit :
> Hey Neil & Phong,
>
> Thanks for submitting this series!
>
>> +
>> +static const struct drm_bridge_funcs it66121_bridge_funcs = {
>> + .attach = it66121_bridge_attach,
>> + .enable = it66121_bridge_enable,
>> + .disable = it66121_bridge_disable,
>> + .mode_set = it66121_bridge_mode_set,
>> + .mode_valid = it66121_bridge_mode_valid,
>> + .detect = it66121_bridge_detect,
>> + .get_edid = it66121_bridge_get_edid,
>> + .atomic_get_output_bus_fmts =
>> it66121_bridge_atomic_get_output_bus_fmts,
>> + .atomic_get_input_bus_fmts =
>> it66121_bridge_atomic_get_input_bus_fmts,
>> +};
>
> I would like to see an implementation of HPD, since it is supported by
> the hardware[1] (and required by the documentation). IRQ status bit 0
> seems to be the responsible for notifying us about hot plug detection
> events.
It's implemented in the IRQ handler with the
IT66121_INT_STATUS1_HPD_STATUS event.
>>>
>>> I didn't even get that far :)
>>>
>>> Either way, the HPD support should be exposed in drm_bridge_funcs
>>> (.hpd_enable, .hpd_disable (and possibly .hpd_notify)) and
>>> drm_bridge.ops (DRM_BRIDGE_OP_HPD).
>>
>> Indeed I forgot these calls in the NO_CONNECTOR implementation...
>
> For new bridges, you should no implement connector creation, only the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR case should be supported.
>
Right, time to make a clean bridge-only implementation then !
Thanks for your feedbacks,
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 19/19] drm/i915/gtt/dgfx: place the PD in LMEM
On 12/04/2021 10:05, Matthew Auld wrote:
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 -
drivers/gpu/drm/i915/gt/intel_gtt.c | 27 +--
drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index f83496836f0f..11fb5df45a0f 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -712,7 +712,10 @@ struct i915_ppgtt *gen8_ppgtt_create(struct intel_gt *gt)
*/
ppgtt->vm.has_read_only = !IS_GEN_RANGE(gt->i915, 11, 12);
- ppgtt->vm.alloc_pt_dma = alloc_pt_dma;
+ if (HAS_LMEM(gt->i915))
+ ppgtt->vm.alloc_pt_dma = alloc_pt_lmem;
+ else
+ ppgtt->vm.alloc_pt_dma = alloc_pt_dma;
err = gen8_init_scratch(&ppgtt->vm);
if (err)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index d386b89e2758..1eeeab45445c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -7,10 +7,23 @@
#include
+#include "gem/i915_gem_lmem.h"
#include "i915_trace.h"
#include "intel_gt.h"
#include "intel_gtt.h"
+struct drm_i915_gem_object *alloc_pt_lmem(struct i915_address_space *vm, int sz)
+{
+ struct drm_i915_gem_object *obj;
+
+ obj = i915_gem_object_create_lmem(vm->i915, sz, 0);
+
+ /* ensure all dma objects have the same reservation class */
+ if (!IS_ERR(obj))
+ obj->base.resv = &vm->resv;
+ return obj;
+}
+
struct drm_i915_gem_object *alloc_pt_dma(struct i915_address_space *vm, int
sz)
{
struct drm_i915_gem_object *obj;
@@ -27,9 +40,14 @@ struct drm_i915_gem_object *alloc_pt_dma(struct
i915_address_space *vm, int sz)
int map_pt_dma(struct i915_address_space *vm, struct drm_i915_gem_object *obj)
{
+ enum i915_map_type type;
void *vaddr;
- vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
+ type = I915_MAP_WB;
+ if (i915_gem_object_is_lmem(obj))
+ type = I915_MAP_WC;
Not trusting the "always coherent" helper from earlier in the series?
Regards,
Tvrtko
+
+ vaddr = i915_gem_object_pin_map_unlocked(obj, type);
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
@@ -39,9 +57,14 @@ int map_pt_dma(struct i915_address_space *vm, struct drm_i915_gem_object *obj)
int map_pt_dma_locked(struct i915_address_space *vm, struct drm_i915_gem_object *obj)
{
+ enum i915_map_type type;
void *vaddr;
- vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ type = I915_MAP_WB;
+ if (i915_gem_object_is_lmem(obj))
+ type = I915_MAP_WC;
+
+ vaddr = i915_gem_object_pin_map(obj, type);
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 40e486704558..44ce27c51631 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -527,6 +527,7 @@ int setup_scratch_page(struct i915_address_space *vm);
void free_scratch(struct i915_address_space *vm);
struct drm_i915_gem_object *alloc_pt_dma(struct i915_address_space *vm, int sz);
+struct drm_i915_gem_object *alloc_pt_lmem(struct i915_address_space *vm, int
sz);
struct i915_page_table *alloc_pt(struct i915_address_space *vm);
struct i915_page_directory *alloc_pd(struct i915_address_space *vm);
struct i915_page_directory *__alloc_pd(int npde);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/amdkfd: Allow access for mmapping KFD BOs
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
DRM allows access automatically when it creates a GEM handle for a BO.
KFD BOs don't have GEM handles, so KFD needs to manage access manually.
After reading drm vma manager, I understand it uses rbtree to
store all GPU drm file handle when calling drm_vma_node_allow,
drm_vma_node_is_allowed/drm_vma_node_verify_access is checked when
creating mapping, I don't understand how application uses this,
but seems we need call drm_vma_node_allow when
amdgpu_amdkfd_gpuvm_map_memory_to_gpu, to add mapping GPUs drm
file handle to vma manager.
Regards,
Philip
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 3 ++-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 19 ++-
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 8 +---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 7 ---
4 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 0d59bebd92af..7c8c5e469707 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -245,7 +245,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
void *drm_priv, struct kgd_mem **mem,
uint64_t *offset, uint32_t flags);
int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
- struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *size);
+ struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv,
+ uint64_t *size);
int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv);
int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 95442bcd60fb..e7d61ec966b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1232,6 +1232,12 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
domain_string(alloc_domain), ret);
goto err_bo_create;
}
+ ret = drm_vma_node_allow(&gobj->vma_node, drm_priv);
+ if (ret) {
+ pr_debug("Failed to allow vma node access. ret %d\n",
+ ret);
pr_debug("Failed to allow vma node access. ret %d\n", ret);
It's within 80 columns.
Philip
+ goto err_node_allow;
+ }
bo = gem_to_amdgpu_bo(gobj);
if (bo_type == ttm_bo_type_sg) {
bo->tbo.sg = sg;
@@ -1261,6 +1267,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
allocate_init_user_pages_failed:
remove_kgd_mem_from_kfd_bo_list(*mem, avm->process_info);
+ drm_vma_node_revoke(&gobj->vma_node, drm_priv);
+err_node_allow:
amdgpu_bo_unref(&bo);
/* Don't unreserve system mem limit twice */
goto err_reserve_limit;
@@ -1278,7 +1286,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
}
int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
- struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *size)
+ struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv,
+ uint64_t *size)
{
struct amdkfd_process_info *process_info = mem->process_info;
unsigned long bo_size = mem->bo->tbo.base.size;
@@ -1355,6 +1364,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
}
/* Free the BO*/
+ drm_vma_node_revoke(&mem->bo->tbo.base.vma_node, drm_priv);
drm_gem_object_put(&mem->bo->tbo.base);
mutex_destroy(&mem->lock);
kfree(mem);
@@ -1666,6 +1676,7 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev *kgd,
struct amdgpu_vm *avm = drm_priv_to_vm(drm_priv);
struct drm_gem_object *obj;
struct amdgpu_bo *bo;
+ int ret;
if (dma_buf->ops != &amdgpu_dmabuf_ops)
/* Can't handle non-graphics buffers */
@@ -1686,6 +1697,12 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev *kgd,
if (!*mem)
return -ENOMEM;
+ ret = drm_vma_node_allow(&obj->vma_node, drm_priv);
+ if (ret) {
+ kfree(mem);
+ return ret;
+ }
+
if (size)
*size = amdgpu_bo_size(bo);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 43de260b2230..8fc18de7cff4 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1328,7 +1328,8 @@ static int kfd_ioctl_alloc_memory_of_gpu(struct file *filep,
return 0;
err_free:
- amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd, (struct kgd_mem *)mem, NULL);
+ amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd, (struct kgd_mem *)mem,
+ pdd->vm, NULL);
err_unlock:
mutex_unlock(&p->mutex);
return err;
@@ -1365,7 +1366,7 @@ static int kfd_ioctl_free_memory_of_gpu(struct file *filep,
}
ret = amdgpu_amdkfd_gpuvm_free_memory_of_gpu(dev->kgd,
- (struct kgd_mem *)mem, &size);
+ (struct kgd_mem *)mem, pdd->vm, &size);
/* If freeing the buffer failed, leave the handle in place for
* clean-up during process tear-down.
@@ -1721,7 +1722,8 @@ static int kfd_ioctl_imp
Re: [PATCH 4/4] drm/amdgpu: Remove verify_access shortcut for KFD BOs
On 2021-04-07 7:12 p.m., Felix Kuehling
wrote:
This shortcut is no longer needed with access managed progerly by KFD.
Reviewed-by: Philip Yang
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 936b3cfdde55..4947dfe9aa70 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -165,13 +165,6 @@ static int amdgpu_verify_access(struct ttm_buffer_object *bo, struct file *filp)
{
struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
- /*
- * Don't verify access for KFD BOs. They don't have a GEM
- * object associated with them.
- */
- if (abo->kfd_bo)
- return 0;
-
if (amdgpu_ttm_tt_get_usermm(bo->ttm))
return -EPERM;
return drm_vma_node_verify_access(&abo->tbo.base.vma_node,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/amdkfd: Allow access for mmapping KFD BOs
Am 2021-04-14 um 11:37 a.m. schrieb philip yang:
>
>
> On 2021-04-07 7:12 p.m., Felix Kuehling wrote:
>> DRM allows access automatically when it creates a GEM handle for a BO.
>> KFD BOs don't have GEM handles, so KFD needs to manage access manually.
>
> After reading drm vma manager, I understand it uses rbtree to store
> all GPU drm file handle when calling drm_vma_node_allow,
> drm_vma_node_is_allowed/drm_vma_node_verify_access is checked when
> creating mapping, I don't understand how application uses this, but
> seems we need call drm_vma_node_allow when
> amdgpu_amdkfd_gpuvm_map_memory_to_gpu, to add mapping GPUs drm file
> handle to vma manager.
>
The drm file handle is used for CPU mapping of BOs using mmap by the
Thunk. It uses on the file handle of the GPU where the BO was allocated.
It doesn't matter what other GPUs map the BO in their device page table.
Therefore we don't need to call drm_vma_node_allow in
amdgpu_amdkfd_gpuvm_map_memory_to_gpu.
I will add an explanation in the commit description about how user mode
depends on this access permission.
Regards,
Felix
> Regards,
>
> Philip
>
>> Signed-off-by: Felix Kuehling
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 3 ++-
>> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 19 ++-
>> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 8 +---
>> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 7 ---
>> 4 files changed, 29 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> index 0d59bebd92af..7c8c5e469707 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> @@ -245,7 +245,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
>> void *drm_priv, struct kgd_mem **mem,
>> uint64_t *offset, uint32_t flags);
>> int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
>> -struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *size);
>> +struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv,
>> +uint64_t *size);
>> int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
>> struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv);
>> int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> index 95442bcd60fb..e7d61ec966b6 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> @@ -1232,6 +1232,12 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
>> domain_string(alloc_domain), ret);
>> goto err_bo_create;
>> }
>> +ret = drm_vma_node_allow(&gobj->vma_node, drm_priv);
>> +if (ret) {
>> +pr_debug("Failed to allow vma node access. ret %d\n",
>> + ret);
>
> pr_debug("Failed to allow vma node access. ret %d\n", ret);
>
> It's within 80 columns.
>
> Philip
>
>> +goto err_node_allow;
>> +}
>> bo = gem_to_amdgpu_bo(gobj);
>> if (bo_type == ttm_bo_type_sg) {
>> bo->tbo.sg = sg;
>> @@ -1261,6 +1267,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
>>
>> allocate_init_user_pages_failed:
>> remove_kgd_mem_from_kfd_bo_list(*mem, avm->process_info);
>> +drm_vma_node_revoke(&gobj->vma_node, drm_priv);
>> +err_node_allow:
>> amdgpu_bo_unref(&bo);
>> /* Don't unreserve system mem limit twice */
>> goto err_reserve_limit;
>> @@ -1278,7 +1286,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
>> }
>>
>> int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
>> -struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *size)
>> +struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv,
>> +uint64_t *size)
>> {
>> struct amdkfd_process_info *process_info = mem->process_info;
>> unsigned long bo_size = mem->bo->tbo.base.size;
>> @@ -1355,6 +1364,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
>> }
>>
>> /* Free the BO*/
>> +drm_vma_node_revoke(&mem->bo->tbo.base.vma_node, drm_priv);
>> drm_gem_object_put(&mem->bo->tbo.base);
>> mutex_destroy(&mem->lock);
>> kfree(mem);
>> @@ -1666,6 +1676,7 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev
>> *kgd,
>> struct amdgpu_vm *avm = drm_priv_to_vm(drm_priv);
>> struct drm_gem_object *obj;
>> struct amdgpu_bo *bo;
>> +int ret;
>>
>> if (dma_buf->ops != &amdgpu_dmabuf_ops)
>> /* Can't handle non-graphics buffers */
>> @@ -1686,6 +1697,12 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev
>> *kgd,
>> if (!*mem)
>> return -ENOMEM;
>>
>> +ret = drm_vma_node_allow(&obj->vma_node, drm_priv);
>> +if (ret) {
>> +kfree(mem);
>> +return ret;
>> +}
>> +
>> if (size)
>> *size = amdgpu_bo_size(bo);
>
Re: [PATCH 2/4] drm/amdkfd: Use drm_priv to pass VM from KFD to amdgpu
Am 2021-04-14 um 11:21 a.m. schrieb philip yang:
>
>
> On 2021-04-07 7:12 p.m., Felix Kuehling wrote:
>> amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
>> to access the BO through the corresponding file descriptor.
>>
>> Signed-off-by: Felix Kuehling
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 14 ++--
>> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 69 +++
>> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 +-
>> 3 files changed, 50 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> index 5ffb07b02810..0d59bebd92af 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
>> @@ -236,20 +236,20 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct
>> kgd_dev *dst, struct kgd_dev *s
>> /* GPUVM API */
>> int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
>> struct file *filp, u32 pasid,
>> -void **vm, void **process_info,
>> +void **process_info,
>> struct dma_fence **ef);
>> -void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void *vm);
>> -uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void *vm);
>> +void amdgpu_amdkfd_gpuvm_release_process_vm(struct kgd_dev *kgd, void
>> *drm_priv);
>> +uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void *drm_priv);
>> int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
>> struct kgd_dev *kgd, uint64_t va, uint64_t size,
>> -void *vm, struct kgd_mem **mem,
>> +void *drm_priv, struct kgd_mem **mem,
>> uint64_t *offset, uint32_t flags);
>> int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
>> struct kgd_dev *kgd, struct kgd_mem *mem, uint64_t *size);
>> int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
>> -struct kgd_dev *kgd, struct kgd_mem *mem, void *vm);
>> +struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv);
>> int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
>> -struct kgd_dev *kgd, struct kgd_mem *mem, void *vm);
>> +struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv);
>> int amdgpu_amdkfd_gpuvm_sync_memory(
>> struct kgd_dev *kgd, struct kgd_mem *mem, bool intr);
>> int amdgpu_amdkfd_gpuvm_map_gtt_bo_to_kernel(struct kgd_dev *kgd,
>> @@ -260,7 +260,7 @@ int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct kgd_dev
>> *kgd,
>>struct kfd_vm_fault_info *info);
>> int amdgpu_amdkfd_gpuvm_import_dmabuf(struct kgd_dev *kgd,
>>struct dma_buf *dmabuf,
>> - uint64_t va, void *vm,
>> + uint64_t va, void *drm_priv,
>>struct kgd_mem **mem, uint64_t *size,
>>uint64_t *mmap_offset);
>> int amdgpu_amdkfd_get_tile_config(struct kgd_dev *kgd,
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> index 36012229ccc1..95442bcd60fb 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
>> @@ -951,6 +951,13 @@ static int process_update_pds(struct
>> amdkfd_process_info *process_info,
>> return 0;
>> }
>>
>> +static struct amdgpu_vm *drm_priv_to_vm(struct drm_file *drm_priv)
>> +{
>> +struct amdgpu_fpriv *fpriv = drm_priv->driver_priv;
>> +
>> +return &fpriv->vm;
>> +}
>> +
>> static int init_kfd_vm(struct amdgpu_vm *vm, void **process_info,
>> struct dma_fence **ef)
>> {
>> @@ -1039,15 +1046,19 @@ static int init_kfd_vm(struct amdgpu_vm *vm, void
>> **process_info,
>>
>> int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
>> struct file *filp, u32 pasid,
>> - void **vm, void **process_info,
>> + void **process_info,
>> struct dma_fence **ef)
>> {
>> struct amdgpu_device *adev = get_amdgpu_device(kgd);
>> -struct drm_file *drm_priv = filp->private_data;
>> -struct amdgpu_fpriv *drv_priv = drm_priv->driver_priv;
>> -struct amdgpu_vm *avm = &drv_priv->vm;
>> +struct amdgpu_fpriv *drv_priv;
>> +struct amdgpu_vm *avm;
>> int ret;
>>
>> +ret = amdgpu_file_to_fpriv(filp, &drv_priv);
>> +if (ret)
>> +return ret;
>> +avm = &drv_priv->vm;
>> +
>> /* Already a compute VM? */
>> if (avm->process_info)
>> return -EINVAL;
>> @@ -1062,7 +1073,7 @@ int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct
>> kgd_dev *kgd,
>> if (ret)
>> return ret;
>>
>> -
Re: [Intel-gfx] [PATCH 11/19] drm/i915: Update the helper to set correct mapping
On Wed, 14 Apr 2021 at 16:22, Tvrtko Ursulin
wrote:
>
>
> On 12/04/2021 10:05, Matthew Auld wrote:
> > From: Venkata Sandeep Dhanalakota
> >
> > Determine the possible coherent map type based on object location,
> > and if target has llc or if user requires an always coherent
> > mapping.
> >
> > Cc: Matthew Auld
> > Cc: CQ Tang
> > Suggested-by: Michal Wajdeczko
> > Signed-off-by: Venkata Sandeep Dhanalakota
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ++-
> > drivers/gpu/drm/i915/gt/intel_engine_pm.c| 2 +-
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
> > drivers/gpu/drm/i915/gt/intel_ring.c | 9 ++---
> > drivers/gpu/drm/i915/gt/selftest_context.c | 3 ++-
> > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
> > drivers/gpu/drm/i915/gt/selftest_lrc.c | 4 +++-
> > drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +++-
> > drivers/gpu/drm/i915/gt/uc/intel_huc.c | 4 +++-
> > drivers/gpu/drm/i915/i915_drv.h | 11 +--
> > drivers/gpu/drm/i915/selftests/igt_spinner.c | 4 ++--
> > 11 files changed, 36 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index efe935f80c1a..b79568d370f5 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -664,7 +664,8 @@ static int init_status_page(struct intel_engine_cs
> > *engine)
> > if (ret)
> > goto err;
> >
> > - vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
> > + vaddr = i915_gem_object_pin_map(obj,
> > + i915_coherent_map_type(engine->i915,
> > obj, true));
> > if (IS_ERR(vaddr)) {
> > ret = PTR_ERR(vaddr);
> > goto err_unpin;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > index 7c9af86fdb1e..47f4397095e5 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > @@ -23,7 +23,7 @@ static void dbg_poison_ce(struct intel_context *ce)
> >
> > if (ce->state) {
> > struct drm_i915_gem_object *obj = ce->state->obj;
> > - int type = i915_coherent_map_type(ce->engine->i915);
> > + int type = i915_coherent_map_type(ce->engine->i915, obj,
> > true);
> > void *map;
> >
> > if (!i915_gem_object_trylock(obj))
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index e86897cde984..aafe2a4df496 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -903,7 +903,9 @@ lrc_pre_pin(struct intel_context *ce,
> > GEM_BUG_ON(!i915_vma_is_pinned(ce->state));
> >
> > *vaddr = i915_gem_object_pin_map(ce->state->obj,
> > -
> > i915_coherent_map_type(ce->engine->i915) |
> > +
> > i915_coherent_map_type(ce->engine->i915,
> > +
> > ce->state->obj,
> > + false) |
> >I915_MAP_OVERRIDE);
> >
> > return PTR_ERR_OR_ZERO(*vaddr);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
> > b/drivers/gpu/drm/i915/gt/intel_ring.c
> > index aee0a77c77e0..3cf6c7e68108 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> > @@ -53,9 +53,12 @@ int intel_ring_pin(struct intel_ring *ring, struct
> > i915_gem_ww_ctx *ww)
> >
> > if (i915_vma_is_map_and_fenceable(vma))
> > addr = (void __force *)i915_vma_pin_iomap(vma);
> > - else
> > - addr = i915_gem_object_pin_map(vma->obj,
> > -
> > i915_coherent_map_type(vma->vm->i915));
> > + else {
> > + int type = i915_coherent_map_type(vma->vm->i915, vma->obj,
> > false);
> > +
> > + addr = i915_gem_object_pin_map(vma->obj, type);
> > + }
> > +
> > if (IS_ERR(addr)) {
> > ret = PTR_ERR(addr);
> > goto err_ring;
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
> > b/drivers/gpu/drm/i915/gt/selftest_context.c
> > index b9bdd1d23243..26685b927169 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_context.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_context.c
> > @@ -88,7 +88,8 @@ static int __live_context_size(struct intel_engine_cs
> > *engine)
> > goto err;
> >
> > vaddr = i915_gem_object_pin_map_unlocked(ce->state->obj,
> > -
> > i915_coherent_map_type(engine->i915));
> > +
> > i915_coherent_map_type(engine->i915,
> > +
Re: [PATCH 03/30] drm/tegra: Don't register DP AUX channels before connectors
On Fri, Feb 19, 2021 at 04:52:59PM -0500, Lyude Paul wrote: > As pointed out by the documentation for drm_dp_aux_register(), > drm_dp_aux_init() should be used in situations where the AUX channel for a > display driver can potentially be registered before it's respective DRM > driver. This is the case with Tegra, since the DP aux channel exists as a > platform device instead of being a grandchild of the DRM device. > > Since we're about to add a backpointer to a DP AUX channel's respective DRM > device, let's fix this so that we don't potentially allow userspace to use > the AUX channel before we've associated it with it's DRM connector. > > Signed-off-by: Lyude Paul > --- > drivers/gpu/drm/tegra/dpaux.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c > index 105fb9cdbb3b..ea56c6ec25e4 100644 > --- a/drivers/gpu/drm/tegra/dpaux.c > +++ b/drivers/gpu/drm/tegra/dpaux.c > @@ -534,9 +534,7 @@ static int tegra_dpaux_probe(struct platform_device *pdev) > dpaux->aux.transfer = tegra_dpaux_transfer; > dpaux->aux.dev = &pdev->dev; > > - err = drm_dp_aux_register(&dpaux->aux); > - if (err < 0) > - return err; > + drm_dp_aux_init(&dpaux->aux); I just noticed that this change causes an error on some setups that I haven't seen before. The problem is that the SOR driver tries to grab a reference to the I2C device to make sure it doesn't go away while it has a pointer to it. However, since now the I2C adapter hasn't been registered yet, I get this: [ 15.013969] kobject: '(null)' (5c903e43): is not initialized, yet kobject_get() is being called. I recall that you wanted to make this change so that a backpointer to the DRM device could be added (I think that's patch 15 of the series), but I didn't see that patch get merged, so it's a bit difficult to try and fix this up. Has the situation changed? Do we no longer need the backpointer? If we still want it, what's the plan for merging the change? Should I work under the assumption that patch will make it in sometime and try to fix this on top of that? I'm thinking that perhaps we can move the I2C adapter registration into drm_dp_aux_init() since that's independent of the DRM device. It would also make a bit more sense from the Tegra driver's point of view where all devices would be created during the ->probe() path, and only during the ->init() path would the connection between DRM device and DRM DP AUX device be established. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] drm: bridge: add it66121 driver
Hi Neil, Le mer. 14 avril 2021 à 8:17, Neil Armstrong a écrit : Hi, Le 13/04/2021 à 22:56, Paul Cercueil a écrit : Hi Neil, I get build failures locally: drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_hw_reset’: drivers/gpu/drm/bridge/ite-it66121.c:242:2: error: implicit declaration of function ‘gpiod_set_value’ [-Werror=implicit-function-declaration] 242 | gpiod_set_value(ctx->gpio_reset, 1); | ^~~ drivers/gpu/drm/bridge/ite-it66121.c: In function ‘it66121_probe’: drivers/gpu/drm/bridge/ite-it66121.c:1016:16: error: implicit declaration of function ‘FIELD_GET’; did you mean ‘FOLL_GET’? [-Werror=implicit-function-declaration] 1016 | revision_id = FIELD_GET(IT66121_REVISION_MASK, device_ids[1]); | ^ | FOLL_GET Nothing difficult to fix, but the includes should be added nonetheless. Exact, I got the CI build failures, I'll fix these for v4. Were you able to test on your setup ? The v2 always forced DDR mode, with this v3, I also switch to normal 24input mode, but totally untested. It triggers a warning: [ 277.870247] WARNING: CPU: 0 PID: 310 at drivers/gpu/drm/drm_bridge.c:892 drm_atomic_bridge_chain_check+0x304/0x324 [ 277.870290] Modules linked in: [ 277.870306] CPU: 0 PID: 310 Comm: modetest Tainted: GW 5.12.0-rc7-opendingux-00121-g828a3020b5d3 #371 [ 277.870322] Stack : 83f62580 80163b58 0004 b1f39d7e 83581a9c 80ab42b0 [ 277.870367] 808a 808a 835c82f0 808a0dab 80ab42b0 0001 83581a48 b1f39d7e [ 277.870412] 807e9030 00b8 835818fc 7875676e [ 277.870456] 3130302d 80abaa43 80abaa9f 672d3132 808a 8000 0009 037c [ 277.870500] 82a2d0f8 83043b80 fffc 2098 80ab [ 277.870544] ... [ 277.870556] Call Trace: [ 277.870560] [<80109010>] show_stack+0x40/0x128 [ 277.870588] [<80123350>] __warn+0xe0/0x154 [ 277.870608] [<80123428>] warn_slowpath_fmt+0x64/0xb8 [ 277.870625] [<80504e70>] drm_atomic_bridge_chain_check+0x304/0x324 [ 277.870642] [<804e3244>] drm_atomic_helper_check_modeset+0x9f4/0xc58 [ 277.870667] [<804e4338>] drm_atomic_helper_check+0x20/0xa8 [ 277.870685] [<80503644>] drm_atomic_check_only+0x538/0x98c [ 277.870700] [<80503ab4>] drm_atomic_commit+0x1c/0x70 [ 277.870716] [<8051c3e4>] drm_mode_atomic_ioctl+0x920/0xb44 [ 277.870736] [<804f033c>] drm_ioctl+0x20c/0x3d8 [ 277.870754] [<80283658>] sys_ioctl+0x358/0x860 [ 277.870772] [<801107ec>] syscall_common+0x34/0x58 [ 277.870795] ---[ end trace e973f3b21c63aa1d ]--- That causes my atomic commit to fail, so I can't test it further. Cheers, -Paul Thanks, Neil Cheers, -Paul Le lun. 12 avril 2021 à 17:46, Neil Armstrong a écrit : From: Phong LE This commit is a simple driver for bridge HMDI it66121. The input format is RBG and there is no color conversion. Audio, HDCP and CEC are not supported yet. Signed-off-by: Phong LE Signed-off-by: Neil Armstrong --- drivers/gpu/drm/bridge/Kconfig |8 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/ite-it66121.c | 1081 ++ 3 files changed, 1090 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ite-it66121.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index e4110d6ca7b3..6915c38fa459 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -74,6 +74,14 @@ config DRM_LONTIUM_LT9611UXC HDMI signals Please say Y if you have such hardware. +config DRM_ITE_IT66121 +tristate "ITE IT66121 HDMI bridge" +depends on OF +select DRM_KMS_HELPER +select REGMAP_I2C +help + Support for ITE IT66121 HDMI bridge. + config DRM_LVDS_CODEC tristate "Transparent LVDS encoders and decoders support" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index 86e7acc76f8d..4f725753117c 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o +obj-$(CONFIG_DRM_ITE_IT66121) += ite-it66121.o obj-y += analogix/ obj-y += cadence/ diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c new file mode 100644 index ..73af49b29dfa --- /dev/null +++ b/drivers/gpu/drm/bridge/ite-it66121.c @@ -0,0 +1,1081 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2020 BayLibre, SAS + * Author: Phong LE + * Copyright (C) 2018-2019, Artem Mygaiev + * Copyright (C) 2017, Fresco Logic, Incorporated. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#in
Re: [PATCH v2 2/3] drm/msm/dp: do not re initialize of audio_comp at display_disable()
On 2021-04-13 20:17, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-04-13 16:11:30)
At dongle unplug, dp initializes audio_comp followed by sending
disconnect
event notification to audio and to make sure audio had shutdown
completely
by wait for audio completion notification at display_disable(). This
patch
Is this dp_display_disable()? Doubtful that display_disable() is the
function we're talking about.
yes
will not re initialize audio_comp at display_disable() if audio
shutdown
is triggered by dongle unplugged.
This commit text seems to say the why before the what, where why is "dp
initializes audio_comp followed by sending disconnect.." and the what
is
"this patch will no re-initialized audio_comp...". Can you reorder this
so the what comes before the why?
ok
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 0ba71c7..1d71c95 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -894,8 +894,10 @@ static int dp_display_disable(struct
dp_display_private *dp, u32 data)
/* wait only if audio was enabled */
if (dp_display->audio_enabled) {
/* signal the disconnect event */
- reinit_completion(&dp->audio_comp);
- dp_display_handle_plugged_change(dp_display, false);
+ if (dp->hpd_state != ST_DISCONNECT_PENDING) {
+ reinit_completion(&dp->audio_comp);
Why is this reinitialized here at all? Wouldn't it make more sense to
initialize the completion once at cable plug in and then not initialize
the completion anywhere else? Or initialize the completion whenever
dp_display->audio_enabled is set to true and then only wait for the
completion here if that boolean is true? Or initialize the completion
when dp_display_handle_plugged_change() is passed true for the
'plugged'
argument?
yes, i think it is better approach, this will take care of both unplug
and suspend.
I started reading the code and quickly got lost figuring out how
dp_display_handle_plugged_change() worked and the interaction between
the dp display code and the audio codec embedded in here. There seem to
be a couple of conditions that cut off things early, like
dp_display->audio_enabled and audio->engine_on. Why? Why does
dp_display_signal_audio_complete() call complete_all() vs. just
complete()? Please help! :(
+ dp_display_handle_plugged_change(dp_display,
false);
I think it's this way because dp_hpd_unplug_handle() is the function
that sets the hpd_state to ST_DISCONNECT_PENDING and then reinitializes
the completion (why?) and calls dp_display_handle_plugged_change(). So
the commit text could say that reinitializing the completion again here
at dp_display_disable() is racing with the audio code in the case that
dp_hpd_unplug_handle() already called
dp_display_handle_plugged_change() and it would make more sense. But
the
question still stands why that race even exists in the first place vs.
initializing the completion variable in only one place unconditionally
when the cable is connected, in dp_hpd_plug_handle() or
dp_display_post_enable().
+ }
if (!wait_for_completion_timeout(&dp->audio_comp,
HZ * 5))
DRM_ERROR("audio comp timeout\n");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/57] Rid W=1 warnings from Staging
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Lee Jones (57): staging: r8192U_core: Remove two unused variables 'ret' and 'reset_status' staging: android: ashmem: Supply description for 'new_range' staging: comedi_8254: Fix descriptions for 'i8254' and 'iobase' staging: r8192U_core: Do not use kernel-doc formatting for !kernel-doc headers staging: r819xU_phy: Remove some local variables from the stack staging: r819xU_cmdpkt: Remove functionless method 'cmpk_handle_query_config_rx' staging: wlan-ng: cfg80211: Move large struct onto the heap staging: rtw_ioctl_set: Move 'channel_table' to the only place it's used staging: rtl8188eu: core: rtw_ieee80211: Fix incorrectly documented function staging: rtl8723bs: core: rtw_mlme: Remove a bunch of unused variables staging: rtl8723bs: core: rtw_mlme_ext: Deal with a bunch of unused variables staging: rtl8712: rtl871x_mp_ioctl: Remove a bunch of unused tables staging: rtl8723bs: core: rtw_recv: Mark debug variable as __maybe_unused staging: rtl8188eu: core: rtw_security: Fix some formatting and misdocumentation staging: rtl8723bs: core: rtw_security: Demote non-conformant kernel-doc header staging: rtl8723bs: core: rtw_sta_mgt: Remove unused variable 'psta' staging: rtl8723bs: core: rtw_sta_mgt: Return error value directly staging: octeon: ethernet-tx: Fix formatting issue in function header staging: rtl8723bs: core: rtw_wlan_util: Remove unused variable 'start_seq' staging: rtl8712: rtl871x_mp_ioctl: Move a large data struct onto the heap staging: iio: frequency: ad9834: Provide missing description for 'devid' staging: nvec: Fix a bunch of kernel-doc issues staging: ks7010: ks_hostif: Remove a bunch of unused variables staging: fwserial: Demote a whole host of kernel-doc abuses staging: sm750fb: sm750_accel: Provide description for 'accel' and fix function naming staging: most: net: Fix some kernel-doc formatting issues staging: vt6655: upc: Suppress set but not used warning in macro staging: rtl8192u: ieee80211_softmac: Move a large data struct onto the heap staging: most: dim2: Provide missing descriptions and fix doc-rot staging: rtl8723bs: core: rtw_ieee80211: Remove seemingly pointless copy staging: rtl8723bs: core: rtw_mlme: 'retry' is only used if REJOIN is set staging: rtl8723bs: core: rtw_mlme_ext: 'evt_seq' is only used if CHECK_EVENT_SEQ is set staging: most: i2c: Fix a little doc-rot staging: most: dim2: hal: Fix one kernel-doc header and demote two non-conforming ones staging: most: dim2: hal: Demote non-conformant kernel-doc headers staging: axis-fifo: axis-fifo: Fix some formatting issues staging: rtl8188eu: os_dep: ioctl_linux: Move 2 large data buffers into the heap staging: fbtft: fb_ili9320: Remove unused variable 'ret' staging: rtl8723bs: core: rtw_ieee80211: Fix incorrectly named function staging: rtl8723bs: hal: odm_NoiseMonitor: Remove unused variable and dead code staging: rtl8188eu: os_dep: mon: Demote non-conforming kernel-doc headers staging: rtl8188eu: os_dep: rtw_android: Demote kernel-doc abuse staging: rtl8723bs: hal: rtl8723b_hal_init: Remove unused variable and dead code staging: rtl8723bs: hal: rtl8723b_phycfg: Fix a bunch of misnamed functions staging: rtl8723bs: hal: sdio_halinit: 'start' is only used if debug is enabled staging: rtl8723bs: hal: sdio_ops: Mark used 'err' as __maybe_unused and remove another staging: rtl8723bs: os_dep: ioctl_cfg80211: 'ack' is used when debug is enabled staging: comedi: drivers: jr3_pci: Remove set but unused variable 'min_full_scale' staging: comedi: drivers: ni_tio: Fix slightly broken kernel-doc and demote others staging: comedi: drivers: ni_routes: Demote non-conforming kernel-doc headers staging: axis-fifo: axis-fifo: Fix function naming in the documentation staging: rtl8723bs: hal: odm_NoiseMonitor: Remove unused variable 'func_start' staging: rtl8723bs: core: rtw_mlme_ext: Move very large data buffer onto the heap staging: rtl8723bs: hal: rtl8723b_hal_init: Mark a bunch of debug variables as __maybe_unused staging: comedi: drivers: ni_mio_common: Move 'range_ni_E_ao_ext' to where it is used staging: comedi: drivers: comedi_isadma: Fix misspelling of 'dma_chan1' staging: rtl8723bs: hal: sdio_halinit: Remove unused variable 'ret' drivers/staging/android/ashmem.c | 1 + drivers/staging/axis-fifo/axis-fifo.c | 18 +-- drivers/staging/comedi/drivers/comedi_8254.c | 3 +- .../staging/comedi/drivers/comedi_isadma.c| 2 +- drivers/staging/comedi/drivers/jr3_pci.c | 3 +- .../staging/comedi/drivers/ni_mio_common.c| 9 -- drivers/staging/comedi/drivers/ni_routes.c| 6 +- drivers/staging/come
[PATCH 38/57] staging: fbtft: fb_ili9320: Remove unused variable 'ret'
Fixes the following W=1 kernel build warning(s):
drivers/staging/fbtft/fb_ili9320.c: In function ‘read_devicecode’:
drivers/staging/fbtft/fb_ili9320.c:25:6: warning: variable ‘ret’ set but not
used [-Wunused-but-set-variable]
Cc: Greg Kroah-Hartman
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-stag...@lists.linux.dev
Signed-off-by: Lee Jones
---
drivers/staging/fbtft/fb_ili9320.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ili9320.c
b/drivers/staging/fbtft/fb_ili9320.c
index f2e72d14431db..f0ebc40857b34 100644
--- a/drivers/staging/fbtft/fb_ili9320.c
+++ b/drivers/staging/fbtft/fb_ili9320.c
@@ -22,11 +22,10 @@
static unsigned int read_devicecode(struct fbtft_par *par)
{
- int ret;
u8 rxbuf[8] = {0, };
write_reg(par, 0x);
- ret = par->fbtftops.read(par, rxbuf, 4);
+ par->fbtftops.read(par, rxbuf, 4);
return (rxbuf[2] << 8) | rxbuf[3];
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/18] Make vfio_mdev type safe
On Tue, 6 Apr 2021 16:40:23 -0300 Jason Gunthorpe wrote: > vfio_mdev has a number of different objects: mdev_parent, mdev_type and > mdev_device. > > Unfortunately the types of these have been erased in various places > throughout the API, and this makes it very hard to understand this code or > maintain it by the time it reaches all of the drivers. > > This series puts in all the types and aligns some of the design with the > driver core standard for a driver core bus driver: > > - Replace 'struct device *' with 'struct mdev_device * > - Replace 'struct device *' with 'struct mdev_type *' and >mtype_get_parent_dev() > - Replace 'struct kobject *' with 'struct mdev_type *' > > Now that types are clear it is easy to spot a few places that have > duplicated information. > > More significantly we can now understand how to directly fix the > obfuscated 'kobj->name' matching by realizing the the kobj is a mdev_type, > which is linked to the supported_types_list provided by the driver, and > thus the core code can directly return the array indexes all the drivers > actually want. > > v2: > - Use a mdev_type local in mdev_create_sysfs_files > - Rename the goto unwind labels in mdev_device_free() > - Reorder patches, annotate reviewed-by's thanks all > v1: https://lore.kernel.org/r/0-v1-7dedf20b2b75+4f785-vfio2_...@nvidia.com > > Jason Gunthorpe (18): > vfio/mdev: Fix missing static's on MDEV_TYPE_ATTR's > vfio/mdev: Do not allow a mdev_type to have a NULL parent pointer > vfio/mdev: Add missing typesafety around mdev_device > vfio/mdev: Simplify driver registration > vfio/mdev: Use struct mdev_type in struct mdev_device > vfio/mdev: Expose mdev_get/put_parent to mdev_private.h > vfio/mdev: Add missing reference counting to mdev_type > vfio/mdev: Reorganize mdev_device_create() > vfio/mdev: Add missing error handling to dev_set_name() > vfio/mdev: Remove duplicate storage of parent in mdev_device > vfio/mdev: Add mdev/mtype_get_type_group_id() > vfio/mtty: Use mdev_get_type_group_id() > vfio/mdpy: Use mdev_get_type_group_id() > vfio/mbochs: Use mdev_get_type_group_id() > vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV > vfio/gvt: Use mdev_get_type_group_id() > vfio/mdev: Remove kobj from mdev_parent_ops->create() > vfio/mdev: Correct the function signatures for the > mdev_type_attributes > > .../driver-api/vfio-mediated-device.rst | 9 +- > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/gvt/gvt.c| 41 ++--- > drivers/gpu/drm/i915/gvt/gvt.h| 4 +- > drivers/gpu/drm/i915/gvt/kvmgt.c | 7 +- > drivers/s390/cio/vfio_ccw_ops.c | 17 +- > drivers/s390/crypto/vfio_ap_ops.c | 14 +- > drivers/vfio/mdev/mdev_core.c | 174 +++--- > drivers/vfio/mdev/mdev_driver.c | 19 +- > drivers/vfio/mdev/mdev_private.h | 40 ++-- > drivers/vfio/mdev/mdev_sysfs.c| 59 +++--- > drivers/vfio/mdev/vfio_mdev.c | 29 +-- > drivers/vfio/vfio_iommu_type1.c | 25 +-- > include/linux/mdev.h | 80 +--- > samples/vfio-mdev/mbochs.c| 55 +++--- > samples/vfio-mdev/mdpy.c | 56 +++--- > samples/vfio-mdev/mtty.c | 66 ++- > 17 files changed, 313 insertions(+), 383 deletions(-) Applied to vfio next branch for v5.13. Thanks! Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/30] drm/tegra: Don't register DP AUX channels before connectors
On Wed, 2021-04-14 at 18:49 +0200, Thierry Reding wrote: > On Fri, Feb 19, 2021 at 04:52:59PM -0500, Lyude Paul wrote: > > As pointed out by the documentation for drm_dp_aux_register(), > > drm_dp_aux_init() should be used in situations where the AUX channel for a > > display driver can potentially be registered before it's respective DRM > > driver. This is the case with Tegra, since the DP aux channel exists as a > > platform device instead of being a grandchild of the DRM device. > > > > Since we're about to add a backpointer to a DP AUX channel's respective > > DRM > > device, let's fix this so that we don't potentially allow userspace to use > > the AUX channel before we've associated it with it's DRM connector. > > > > Signed-off-by: Lyude Paul > > --- > > drivers/gpu/drm/tegra/dpaux.c | 11 ++- > > 1 file changed, 6 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c > > index 105fb9cdbb3b..ea56c6ec25e4 100644 > > --- a/drivers/gpu/drm/tegra/dpaux.c > > +++ b/drivers/gpu/drm/tegra/dpaux.c > > @@ -534,9 +534,7 @@ static int tegra_dpaux_probe(struct platform_device > > *pdev) > > dpaux->aux.transfer = tegra_dpaux_transfer; > > dpaux->aux.dev = &pdev->dev; > > > > - err = drm_dp_aux_register(&dpaux->aux); > > - if (err < 0) > > - return err; > > + drm_dp_aux_init(&dpaux->aux); > > I just noticed that this change causes an error on some setups that I > haven't seen before. The problem is that the SOR driver tries to grab a > reference to the I2C device to make sure it doesn't go away while it has > a pointer to it. > > However, since now the I2C adapter hasn't been registered yet, I get > this: > > [ 15.013969] kobject: '(null)' (5c903e43): is not > initialized, yet kobject_get() is being called. > > I recall that you wanted to make this change so that a backpointer to > the DRM device could be added (I think that's patch 15 of the series), > but I didn't see that patch get merged, so it's a bit difficult to try > and fix this up. I'm pretty sure I already merged the tegra change in drm-misc-next, so if it's causing issues you probably should send out a revert for now and I can r-b it so we can figure out a better solution for this in the mean time > Has the situation changed? Do we no longer need the backpointer? If we > still want it, what's the plan for merging the change? Should I work > under the assumption that patch will make it in sometime and try to fix > this on top of that? yes we do still need the backpointer - I'm just still working on getting reviews for some of the other parts of this series, and have been on PTO/busy with a couple of other things. > > I'm thinking that perhaps we can move the I2C adapter registration into > drm_dp_aux_init() since that's independent of the DRM device. Yeah this makes sense for me - I can try to make this change on the next respin of this series. What kind of setup were you able to reproduce issues on this with btw? > It would > also make a bit more sense from the Tegra driver's point of view where > all devices would be created during the ->probe() path, and only during > the ->init() path would the connection between DRM device and DRM DP AUX > device be established. > > Thierry -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [RFC PATCH v2] drm/doc/rfc: i915 DG1 uAPI
+mesa-dev and some Intel mesa people.
On Wed, Apr 14, 2021 at 5:23 AM Daniel Vetter wrote:
>
> On Tue, Apr 13, 2021 at 12:47:06PM +0100, Matthew Auld wrote:
> > Add an entry for the new uAPI needed for DG1.
> >
> > v2(Daniel):
> > - include the overall upstreaming plan
> > - add a note for mmap, there are differences here for TTM vs i915
> > - bunch of other suggestions from Daniel
> >
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: Daniel Vetter
> > Cc: Dave Airlie
>
> Bunch more thoughts below, I think we're getting there. Thanks for doing
> this.
>
> > ---
> > Documentation/gpu/rfc/i915_gem_lmem.h | 151
> > Documentation/gpu/rfc/i915_gem_lmem.rst | 119 +++
> > Documentation/gpu/rfc/index.rst | 4 +
> > 3 files changed, 274 insertions(+)
> > create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h
> > create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst
> >
> > diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h
> > b/Documentation/gpu/rfc/i915_gem_lmem.h
> > new file mode 100644
> > index ..6ae13209d7ef
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc/i915_gem_lmem.h
> > @@ -0,0 +1,151 @@
> > +/* The new query_id for struct drm_i915_query_item */
> > +#define DRM_I915_QUERY_MEMORY_REGIONS 0xdeadbeaf
> > +
> > +/**
> > + * enum drm_i915_gem_memory_class
> > + */
> > +enum drm_i915_gem_memory_class {
>
> Are we really going with enum in uapi? I thought that was frought with
> peril since the integer type of enum is quite a bit up to compilers. But
> maybe I'm just scared.
It looks to me like it's a __u16 below. That should be fine. We
don't really need to give the enum type a name in that case, though.
> > + /** @I915_MEMORY_CLASS_SYSTEM: system memory */
> > + I915_MEMORY_CLASS_SYSTEM = 0,
> > + /** @I915_MEMORY_CLASS_DEVICE: device local-memory */
> > + I915_MEMORY_CLASS_DEVICE,
> > +};
> > +
> > +/**
> > + * struct drm_i915_gem_memory_class_instance
> > + */
> > +struct drm_i915_gem_memory_class_instance {
> > + /** @memory_class: see enum drm_i915_gem_memory_class */
> > + __u16 memory_class;
> > +
> > + /** @memory_instance: which instance */
> > + __u16 memory_instance;
> > +};
> > +
> > +/**
> > + * struct drm_i915_memory_region_info
> > + *
> > + * Describes one region as known to the driver.
> > + */
> > +struct drm_i915_memory_region_info {
> > + /** @region: class:instance pair encoding */
> > + struct drm_i915_gem_memory_class_instance region;
> > +
> > + /** @rsvd0: MBZ */
> > + __u32 rsvd0;
> > +
> > + /** @caps: MBZ */
> > + __u64 caps;
> > +
> > + /** @flags: MBZ */
> > + __u64 flags;
> > +
> > + /** @probed_size: Memory probed by the driver (-1 = unknown) */
> > + __u64 probed_size;
> > +
> > + /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
> > + __u64 unallocated_size;
> > +
> > + /** @rsvd1: MBZ */
> > + __u64 rsvd1[8];
>
> I guess this is for future stuff that becomes relevant with multi-tile?
> Might be worth explaining in 1-2 words why we reserve a pile here. Also
> it doesn't matter ofc for performance here :-)
>
> > +};
> > +
> > +/**
> > + * struct drm_i915_query_memory_regions
> > + *
> > + * Region info query enumerates all regions known to the driver by filling
> > in
> > + * an array of struct drm_i915_memory_region_info structures.
>
> I guess this works with the usual 1. query number of regions 2. get them
> all two-step ioctl flow? Worth explaining here.
>
> > + */
> > +struct drm_i915_query_memory_regions {
> > + /** @num_regions: Number of supported regions */
> > + __u32 num_regions;
> > +
> > + /** @rsvd: MBZ */
> > + __u32 rsvd[3];
> > +
> > + /** @regions: Info about each supported region */
> > + struct drm_i915_memory_region_info regions[];
> > +};
>
> Hm don't we need a query ioctl for this too?
>
> > +
> > +#define DRM_I915_GEM_CREATE_EXT 0xdeadbeaf
> > +#define DRM_IOCTL_I915_GEM_CREATE_EXTDRM_IOWR(DRM_COMMAND_BASE +
> > DRM_I915_GEM_CREATE_EXT, struct drm_i915_gem_create_ext)
> > +
> > +/**
> > + * struct drm_i915_gem_create_ext
>
> I think some explanation here that all new bo flags will be added here,
> and that in general we're phasing out the various SET/GET ioctls.
>
> > + */
> > +struct drm_i915_gem_create_ext {
> > + /**
> > + * @size: Requested size for the object.
> > + *
> > + * The (page-aligned) allocated size for the object will be returned.
> > + */
> > + __u64 size;
> > + /**
> > + * @handle: Returned handle for the object.
> > + *
> > + * Object handles are nonzero.
> > + */
> > + __u32 handle;
> > + /** @flags: MBZ */
> > + __u32 flags;
> > + /**
> > + * @extensions:
> > + * For I915_GEM_CREATE_EXT_SETPARAM extension usage see both:
> > + * struct drm_i915_gem_create_ext_setparam.
> > + *
[v1 1/3] drm/dp: Add DisplayPort aux backlight control support
Add panel backlight control using DPCD registers on the DisplayPort aux
channel.
Signed-off-by: Rajeev Nandan
---
drivers/gpu/drm/Kconfig| 8 ++
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_dp_aux_backlight.c | 191 +
include/drm/drm_dp_aux_backlight.h | 29 +
4 files changed, 229 insertions(+)
create mode 100644 drivers/gpu/drm/drm_dp_aux_backlight.c
create mode 100644 include/drm/drm_dp_aux_backlight.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 85b79a7f..01f8a48 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -177,6 +177,14 @@ config DRM_DP_CEC
Note: not all adapters support this feature, and even for those
that do support this they often do not hook up the CEC pin.
+config DRM_DP_AUX_BACKLIGHT
+ bool "Enable DisplayPort aux backlight control support"
+ depends on DRM
+ select DRM_KMS_HELPER
+ help
+ Choose this option if you want to use panel backlight control
+ using DPCD registers on the DisplayPort aux channel.
+
config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 926adef..e41e40f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -53,6 +53,7 @@ drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) +=
drm_fb_helper.o
drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
+drm_kms_helper-$(CONFIG_DRM_DP_AUX_BACKLIGHT) += drm_dp_aux_backlight.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += selftests/
diff --git a/drivers/gpu/drm/drm_dp_aux_backlight.c
b/drivers/gpu/drm/drm_dp_aux_backlight.c
new file mode 100644
index 000..2fc4ffb
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_aux_backlight.c
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+#include
+
+static int drm_dp_aux_brightness_set(struct backlight_device *bd)
+{
+ struct drm_dp_aux_backlight *pdata = bl_get_data(bd);
+ u16 brightness = bd->props.brightness;
+ u8 val[2] = { 0x0 };
+ int ret = 0;
+
+ if (!pdata->enabled)
+ return 0;
+
+ if (bd->props.power != FB_BLANK_UNBLANK ||
+ bd->props.fb_blank != FB_BLANK_UNBLANK ||
+ bd->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+ brightness = 0;
+
+ val[0] = brightness >> 8;
+ val[1] = brightness & 0xff;
+ ret = drm_dp_dpcd_write(pdata->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
+ val, sizeof(val));
+ if (ret < 0)
+ return ret;
+
+ return ret;
+}
+
+static int drm_dp_aux_brightness_get(struct backlight_device *bd)
+{
+ struct drm_dp_aux_backlight *pdata = bl_get_data(bd);
+ u8 val[2] = { 0x0 };
+ int ret = 0;
+
+ if (!pdata->enabled)
+ return 0;
+
+ if (bd->props.power != FB_BLANK_UNBLANK ||
+ bd->props.fb_blank != FB_BLANK_UNBLANK ||
+ bd->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+ return 0;
+
+ ret = drm_dp_dpcd_read(pdata->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
+ &val, sizeof(val));
+ if (ret < 0)
+ return ret;
+
+ return (val[0] << 8 | val[1]);
+}
+
+static const struct backlight_ops aux_bl_ops = {
+ .update_status = drm_dp_aux_brightness_set,
+ .get_brightness = drm_dp_aux_brightness_get,
+};
+
+/**
+ * drm_dp_aux_backlight_enable() - Enable DP aux backlight
+ * @aux_bl: the DP aux backlight to enable
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_aux_backlight_enable(struct drm_dp_aux_backlight *aux_bl)
+{
+ u8 val = 0;
+ int ret;
+
+ if (!aux_bl)
+ return -EINVAL;
+
+ if (aux_bl->enabled)
+ return 0;
+
+ /* Set backlight control mode */
+ ret = drm_dp_dpcd_readb(aux_bl->aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
+ &val);
+ if (ret < 0)
+ return ret;
+
+ val &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+ val |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+ ret = drm_dp_dpcd_writeb(aux_bl->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
+val);
+ if (ret < 0)
+ return ret;
+
+ /* Enable backlight */
+ ret = drm_dp_dpcd_readb(aux_bl->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
+ &val);
+ if (ret < 0)
+ return ret;
+
+ val |= DP_EDP_BACKLIGHT_ENABLE;
+ ret = drm_dp_dpcd_writeb(aux_bl->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
+val);
+ if (ret < 0)
+ return ret;
+
[v1 3/3] drm/bridge: ti-sn65dsi86: Add DisplayPort aux backlight support
Add support to control the backlight of the eDP panel connected to
the ti-sn65dsi86 bridge through aux channel.
Signed-off-by: Rajeev Nandan
---
drivers/gpu/drm/bridge/Kconfig| 1 +
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 26 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6..e556ec22 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -239,6 +239,7 @@ config DRM_TI_SN65DSI86
select REGMAP_I2C
select DRM_PANEL
select DRM_MIPI_DSI
+ select DRM_DP_AUX_BACKLIGHT
help
Texas Instruments SN65DSI86 DSI to eDP Bridge driver
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index f27306c..813d067 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -126,6 +127,7 @@
* @panel:Our panel.
* @enable_gpio: The GPIO we toggle to enable the bridge.
* @supplies: Data for bulk enabling/disabling our regulators.
+ * @backlight:The DP aux backlight device.
* @dp_lanes: Count of dp_lanes we're using.
* @ln_assign:Value to program to the LN_ASSIGN register.
* @ln_polrs: Value for the 4-bit LN_POLRS field of SN_ENH_FRAME_REG.
@@ -154,6 +156,7 @@ struct ti_sn_bridge {
struct drm_panel*panel;
struct gpio_desc*enable_gpio;
struct regulator_bulk_data supplies[SN_REGULATOR_SUPPLY_NUM];
+ struct drm_dp_aux_backlight *backlight;
int dp_lanes;
u8 ln_assign;
u8 ln_polrs;
@@ -431,6 +434,8 @@ static void ti_sn_bridge_disable(struct drm_bridge *bridge)
{
struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
+ drm_dp_aux_backlight_disable(pdata->backlight);
+
drm_panel_disable(pdata->panel);
/* disable video stream */
@@ -819,6 +824,8 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
VSTREAM_ENABLE);
drm_panel_enable(pdata->panel);
+
+ drm_dp_aux_backlight_enable(pdata->backlight);
}
static void ti_sn_bridge_pre_enable(struct drm_bridge *bridge)
@@ -1215,6 +1222,7 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct ti_sn_bridge *pdata;
+ struct drm_dp_aux_backlight *aux_bl;
int ret;
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
@@ -1294,9 +1302,27 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
drm_bridge_add(&pdata->bridge);
+ if (of_find_property(pdata->dev->of_node, "use-aux-backlight", NULL)) {
+ aux_bl = devm_kzalloc(pdata->dev, sizeof(*aux_bl), GFP_KERNEL);
+ if (!aux_bl) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ aux_bl->dev = pdata->dev;
+ aux_bl->aux = &pdata->aux;
+ ret = drm_dp_aux_backlight_register("ti-sn-aux-backlight",
aux_bl);
+ if (ret)
+ goto out;
+ pdata->backlight = aux_bl;
+ }
+
ti_sn_debugfs_init(pdata);
return 0;
+
+out:
+ pm_runtime_disable(pdata->dev);
+ return ret;
}
static int ti_sn_bridge_remove(struct i2c_client *client)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v1 0/3] drm: Add support for backlight control of eDP panel on ti-sn65dsi86 bridge
The backlight level of an eDP panel can be controlled through the AUX channel using DPCD registers of the panel. The capability for the Source device to adjust backlight characteristics within the panel, using the Sink device DPCD registers is indicated by the TCON_BACKLIGHT_ADJUSTMENT_CAPABLE bit in the EDP_GENERAL_CAPABILITY_1 register (DPCD Address 701h, bit0). In this configuration, the eDP TCON receives the backlight level information from the host, through the AUX channel. The changes in this patch series do the following: - Add drm_dp_aux_backlight_ APIs to support backlight control using DPCD registers on the DisplayPort AUX channel. The current version only supports backlight brightness control by the EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB registers (DPCD Addresses 722h-723h). - Add support for backlight control of the eDP panel connected to the ti-sn65dsi86 bridge. Rajeev Nandan (3): drm/dp: Add DisplayPort aux backlight control support dt-bindings: drm/bridge: ti-sn65dsi86: Document use-aux-backlight drm/bridge: ti-sn65dsi86: Add DisplayPort aux backlight support .../bindings/display/bridge/ti,sn65dsi86.yaml | 8 + drivers/gpu/drm/Kconfig| 8 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 26 +++ drivers/gpu/drm/drm_dp_aux_backlight.c | 191 + include/drm/drm_dp_aux_backlight.h | 29 7 files changed, 264 insertions(+) create mode 100644 drivers/gpu/drm/drm_dp_aux_backlight.c create mode 100644 include/drm/drm_dp_aux_backlight.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v1 2/3] dt-bindings: drm/bridge: ti-sn65dsi86: Document use-aux-backlight
If the panel connected to the bridge supports backlight control
using DPCD registers on the DisplayPort aux channel, setting
"use-aux-backlight" property in the bridge node will enable the
registration of a DP aux backlight device from the bridge driver.
Signed-off-by: Rajeev Nandan
---
.../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
index 26932d2..c8d8c00 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml
@@ -58,6 +58,12 @@ properties:
clock-names:
const: refclk
+ use-aux-backlight:
+type: boolean
+description:
+ The panel backlight to be controlled using DPCD registers on
+ the DP aux channel.
+
gpio-controller: true
'#gpio-cells':
const: 2
@@ -188,6 +194,8 @@ examples:
no-hpd;
+use-aux-backlight;
+
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/msm/dp: check sink_count before update is_connected status
Link status is different from display connected status in the case
of something like an Apple dongle where the type-c plug can be
connected, and therefore the link is connected, but no sink is
connected until an HDMI cable is plugged into the dongle.
The sink_count of DPCD of dongle will increase to 1 once an HDMI
cable is plugged into the dongle so that display connected status
will become true. This checking also apply at pm_resume.
Fixes: 94e58e2d06e3 ("drm/msm/dp: reset dp controller only at boot up and
pm_resume")
Reported-by: Stephen Boyd
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 5a39da6..0ba71c7 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -586,10 +586,8 @@ static int dp_connect_pending_timeout(struct
dp_display_private *dp, u32 data)
mutex_lock(&dp->event_mutex);
state = dp->hpd_state;
- if (state == ST_CONNECT_PENDING) {
- dp_display_enable(dp, 0);
+ if (state == ST_CONNECT_PENDING)
dp->hpd_state = ST_CONNECTED;
- }
mutex_unlock(&dp->event_mutex);
@@ -669,10 +667,8 @@ static int dp_disconnect_pending_timeout(struct
dp_display_private *dp, u32 data
mutex_lock(&dp->event_mutex);
state = dp->hpd_state;
- if (state == ST_DISCONNECT_PENDING) {
- dp_display_disable(dp, 0);
+ if (state == ST_DISCONNECT_PENDING)
dp->hpd_state = ST_DISCONNECTED;
- }
mutex_unlock(&dp->event_mutex);
@@ -1272,7 +1268,12 @@ static int dp_pm_resume(struct device *dev)
status = dp_catalog_link_is_connected(dp->catalog);
- if (status)
+ /*
+* can not declared display is connected unless
+* HDMI cable is plugged in and sink_count of
+* dongle become 1
+*/
+ if (status && dp->link->sink_count)
dp->dp_display.is_connected = true;
else
dp->dp_display.is_connected = false;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm/msm/dp: initialize audio_comp when audio starts
Initialize audio_comp when audio starts and wait for audio_comp at
dp_display_disable(). This will take care of both dongle unplugged
and display off (suspend) cases.
Changes in v2:
-- add dp_display_start_audio()
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_audio.c | 1 +
drivers/gpu/drm/msm/dp/dp_display.c | 13 -
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
b/drivers/gpu/drm/msm/dp/dp_audio.c
index 82a8673..52994f2 100644
--- a/drivers/gpu/drm/msm/dp/dp_audio.c
+++ b/drivers/gpu/drm/msm/dp/dp_audio.c
@@ -527,6 +527,7 @@ int dp_audio_hw_params(struct device *dev,
dp_audio_setup_acr(audio);
dp_audio_safe_to_exit_level(audio);
dp_audio_enable(audio, true);
+ dp_display_start_audio(dp_display);
dp_display->audio_enabled = true;
end:
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 0ba71c7..8a69bcd 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -177,6 +177,14 @@ static int dp_del_event(struct dp_display_private
*dp_priv, u32 event)
return 0;
}
+void dp_display_start_audio(struct msm_dp *dp_display)
+{
+ struct dp_display_private *dp;
+
+ dp = container_of(dp_display, struct dp_display_private, dp_display);
+
+ reinit_completion(&dp->audio_comp);
+}
void dp_display_signal_audio_complete(struct msm_dp *dp_display)
{
@@ -648,10 +656,6 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
/* start sentinel checking in case of missing uevent */
dp_add_event(dp, EV_DISCONNECT_PENDING_TIMEOUT, 0, DP_TIMEOUT_5_SECOND);
- /* signal the disconnect event early to ensure proper teardown */
- reinit_completion(&dp->audio_comp);
- dp_display_handle_plugged_change(g_dp_display, false);
-
dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK |
DP_DP_IRQ_HPD_INT_MASK, true);
@@ -894,7 +898,6 @@ static int dp_display_disable(struct dp_display_private
*dp, u32 data)
/* wait only if audio was enabled */
if (dp_display->audio_enabled) {
/* signal the disconnect event */
- reinit_completion(&dp->audio_comp);
dp_display_handle_plugged_change(dp_display, false);
if (!wait_for_completion_timeout(&dp->audio_comp,
HZ * 5))
diff --git a/drivers/gpu/drm/msm/dp/dp_display.h
b/drivers/gpu/drm/msm/dp/dp_display.h
index 6092ba1..55fe0d4 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.h
+++ b/drivers/gpu/drm/msm/dp/dp_display.h
@@ -34,6 +34,7 @@ int dp_display_get_modes(struct msm_dp *dp_display,
int dp_display_request_irq(struct msm_dp *dp_display);
bool dp_display_check_video_test(struct msm_dp *dp_display);
int dp_display_get_test_bpp(struct msm_dp *dp_display);
+void dp_display_start_audio(struct msm_dp *dp_display);
void dp_display_signal_audio_complete(struct msm_dp *dp_display);
#endif /* _DP_DISPLAY_H_ */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/msm/dp: check main link status before start aux read
Quoting Kuogee Hsieh (2021-04-13 16:11:44)
> Make sure main link is in connection state before start aux
> read/write operation to avoid unnecessary long delay due to
> main link had been unplugged.
>
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_aux.c | 5 +
> drivers/gpu/drm/msm/dp/dp_link.c | 20 +++-
> 2 files changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
> index 7c22bfe..fae3806 100644
> --- a/drivers/gpu/drm/msm/dp/dp_aux.c
> +++ b/drivers/gpu/drm/msm/dp/dp_aux.c
> @@ -343,6 +343,11 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
>
> mutex_lock(&aux->mutex);
>
> + if (!dp_catalog_link_is_connected(aux->catalog)) {
> + ret = -ETIMEDOUT;
> + goto unlock_exit;
> + }
I get a crash here sometimes when plugging and unplugging an apple HDMI
dongle during suspend/resume. I guess device power management
(dp_pm_suspend()) is happening in parallel with aux transfers from the
kthread. Why doesn't the aux communication start reporting NAKs once the
cable is disconnected?
[ 366.210058] hdmi-audio-codec hdmi-audio-codec.15.auto: calling
platform_pm_suspend+0x0/0x60 @ 7175, parent: ae9.displayport-controller
[ 366.222825] hdmi-audio-codec hdmi-audio-codec.15.auto:
platform_pm_suspend+0x0/0x60 returned 0 after 1 usecs
[ 366.232939] msm-dp-display ae9.displayport-controller: calling
dp_pm_suspend+0x0/0x80 @ 7175, parent: ae0.mdss
[ 366.244006] msm-dp-display ae9.displayport-controller:
dp_pm_suspend+0x0/0x80 returned 0 after 79 usecs
[ 366.254025] msm_dsi ae94000.dsi: calling pm_runtime_force_suspend+0x0/0xb4 @
7175, parent: ae0.mdss
[ 366.263669] msm_dsi ae94000.dsi: pm_runtime_force_suspend+0x0/0xb4 returned
0 after 0 usecs
[ 366.272290] panel-simple panel: calling platform_pm_suspend+0x0/0x60 @ 7175,
parent: platform
[ 366.272501] ti_sn65dsi86 2-002d: calling pm_runtime_force_suspend+0x0/0xb4 @
176, parent: i2c-2
[ 366.281055] panel-simple panel: platform_pm_suspend+0x0/0x60 returned 0
after 0 usecs
[ 366.281081] leds mmc1::: calling led_suspend+0x0/0x4c @ 7175, parent:
7c4000.sdhci
[ 366.290065] ti_sn65dsi86 2-002d: pm_runtime_force_suspend+0x0/0xb4 returned
0 after 0 usecs
[ 366.298046] leds mmc1::: led_suspend+0x0/0x4c returned 0 after 1 usecs
[ 366.302994] Internal error: synchronous external abort: 9610 [#1]
PREEMPT SMP
[ 366.303006] Modules linked in: vhost_vsock vmw_vsock_virtio_transport_common
vsock vhost rfcomm algif_hash algif_skcipher af_alg xt_cgroup uinput
xt_MASQUERADE venus_enc hci_uart venus_dec btqca cros_ec_typec typec bluetooth
qcom_spmi_adc5 snd_soc_sc7180 qcom_spmi_temp_alarm ecdh_generic
qcom_spmi_adc_tm5 qcom_vadc_common snd_soc_qcom_common ecc snd_soc_rt5682_i2c
snd_soc_rt5682 snd_soc_rl6231 venus_core v4l2_mem2mem snd_soc_lpass_sc7180
snd_soc_lpass_hdmi snd_soc_lpass_cpu snd_soc_lpass_platform snd_soc_max98357a
fuse iio_trig_sysfs cros_ec_sensors cros_ec_sensors_ring cros_ec_lid_angle
cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf cros_ec_sensorhub
lzo_rle lzo_compress zram ath10k_snoc ath10k_core ath mac80211 cfg80211
cdc_ether usbnet r8152 mii uvcvideo videobuf2_vmalloc joydev
[ 366.303211] CPU: 0 PID: 224 Comm: dp_hpd_handler Not tainted 5.4.109 #27
[ 366.303216] Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
[ 366.303225] pstate: 60c9 (nZCv daif +PAN +UAO)
[ 366.303234] pc : dp_catalog_link_is_connected+0x20/0x34
[ 366.303244] lr : dp_aux_transfer+0x44/0x284
[ 366.303250] sp : ffc011bfbbe0
[ 366.303254] x29: ffc011bfbbe0 x28:
[ 366.303262] x27: 000c x26: ff896f8212bc
[ 366.303269] x25: 0001 x24: 0001
[ 366.303275] x23: 0020 x22: ff896ff82118
[ 366.303282] x21: ffc011bfbc50 x20: ff896ff82090
[ 366.303289] x19: ff896ffc3598 x18:
[ 366.303295] x17: x16: 0001
[ 366.303303] x15: x14: 02ef
[ 366.303311] x13: 0400 x12: ffeb896ea060
[ 366.303317] x11: x10:
[ 366.303324] x9 : ff896f061100 x8 : ffc010582204
[ 366.303331] x7 : 00b2b5593519 x6 : 003033ff
[ 366.303338] x5 : x4 : 0001
[ 366.303345] x3 : ff896ff432a1 x2 :
[ 366.303352] x1 : 0119 x0 : ff896ffc3598
[ 366.303360] Call trace:
[ 366.303367] dp_catalog_link_is_connected+0x20/0x34
[ 366.303374] dp_aux_transfer+0x44/0x284
[ 366.303387] drm_dp_dpcd_access+0x8c/0x11c
[ 366.303393] drm_dp_dpcd_read+0x64/0x10c
[ 366.303399] dp_link_process_request+0x94/0xaf8
[ 366.303405] dp_display_usbpd_attention_cb+0x38/0x140
[ 366.303411] hpd_event_thread+0x3f0/0x48c
[ 366.303426] kthread+0x140/0x17c
[ 366.303439] ret_from_fork+0x1
Re: [PATCH v2 1/3] drm/msm/dp: check sink_count before update is_connected status
Quoting Kuogee Hsieh (2021-04-14 14:02:34)
> Link status is different from display connected status in the case
> of something like an Apple dongle where the type-c plug can be
> connected, and therefore the link is connected, but no sink is
> connected until an HDMI cable is plugged into the dongle.
> The sink_count of DPCD of dongle will increase to 1 once an HDMI
> cable is plugged into the dongle so that display connected status
> will become true. This checking also apply at pm_resume.
>
> Fixes: 94e58e2d06e3 ("drm/msm/dp: reset dp controller only at boot up and
> pm_resume")
> Reported-by: Stephen Boyd
> Reviewed-by: Stephen Boyd
> Tested-by: Stephen Boyd
> Signed-off-by: Kuogee Hsieh
> ---
Can you please thread your emailed patches? I see them all as toplevel
messages in my inbox :(
> drivers/gpu/drm/msm/dp/dp_display.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 5a39da6..0ba71c7 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -586,10 +586,8 @@ static int dp_connect_pending_timeout(struct
> dp_display_private *dp, u32 data)
> mutex_lock(&dp->event_mutex);
>
> state = dp->hpd_state;
> - if (state == ST_CONNECT_PENDING) {
> - dp_display_enable(dp, 0);
> + if (state == ST_CONNECT_PENDING)
> dp->hpd_state = ST_CONNECTED;
> - }
>
> mutex_unlock(&dp->event_mutex);
>
> @@ -669,10 +667,8 @@ static int dp_disconnect_pending_timeout(struct
> dp_display_private *dp, u32 data
> mutex_lock(&dp->event_mutex);
>
> state = dp->hpd_state;
> - if (state == ST_DISCONNECT_PENDING) {
> - dp_display_disable(dp, 0);
> + if (state == ST_DISCONNECT_PENDING)
> dp->hpd_state = ST_DISCONNECTED;
> - }
>
> mutex_unlock(&dp->event_mutex);
>
> @@ -1272,7 +1268,12 @@ static int dp_pm_resume(struct device *dev)
>
> status = dp_catalog_link_is_connected(dp->catalog);
>
> - if (status)
> + /*
> +* can not declared display is connected unless
> +* HDMI cable is plugged in and sink_count of
> +* dongle become 1
> +*/
> + if (status && dp->link->sink_count)
> dp->dp_display.is_connected = true;
> else
> dp->dp_display.is_connected = false;
With this patch applied things still go wrong for me sometimes. I can
connect the apple dongle and then disconnect the apple dongle, instead
of connect and disconnect the HDMI cable, and sometimes the external
display doesn't come on. I'm still investigating but just wanted to let
you know.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm/msm/dp: initialize audio_comp when audio starts
Quoting Kuogee Hsieh (2021-04-14 14:02:50)
> Initialize audio_comp when audio starts and wait for audio_comp at
> dp_display_disable(). This will take care of both dongle unplugged
> and display off (suspend) cases.
>
> Changes in v2:
> -- add dp_display_start_audio()
>
> Signed-off-by: Kuogee Hsieh
Looking better. Thanks!
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
> b/drivers/gpu/drm/msm/dp/dp_display.c
> index 0ba71c7..8a69bcd 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -177,6 +177,14 @@ static int dp_del_event(struct dp_display_private
> *dp_priv, u32 event)
>
> return 0;
> }
> +void dp_display_start_audio(struct msm_dp *dp_display)
Please unstick this from previous function by adding a newline above.
> +{
> + struct dp_display_private *dp;
> +
> + dp = container_of(dp_display, struct dp_display_private, dp_display);
> +
> + reinit_completion(&dp->audio_comp);
> +}
>
> void dp_display_signal_audio_complete(struct msm_dp *dp_display)
> {
> @@ -648,10 +656,6 @@ static int dp_hpd_unplug_handle(struct
> dp_display_private *dp, u32 data)
> /* start sentinel checking in case of missing uevent */
> dp_add_event(dp, EV_DISCONNECT_PENDING_TIMEOUT, 0,
> DP_TIMEOUT_5_SECOND);
>
> - /* signal the disconnect event early to ensure proper teardown */
This doesn't need to be done early anymore? Please mention why in the
commit text.
> - reinit_completion(&dp->audio_comp);
> - dp_display_handle_plugged_change(g_dp_display, false);
> -
> dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_INT_MASK |
> DP_DP_IRQ_HPD_INT_MASK, true);
>
> @@ -894,7 +898,6 @@ static int dp_display_disable(struct dp_display_private
> *dp, u32 data)
> /* wait only if audio was enabled */
> if (dp_display->audio_enabled) {
> /* signal the disconnect event */
> - reinit_completion(&dp->audio_comp);
> dp_display_handle_plugged_change(dp_display, false);
> if (!wait_for_completion_timeout(&dp->audio_comp,
> HZ * 5))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/3] Add devcoredump support for DPU
This series adds support to use devcoredump for DPU driver. It introduces the msm_disp_snapshot module which assists in the capturing of register dumps during error scenarios. When a display related error happens, the msm_disp_snapshot module captures all the relevant register dumps along with the snapshot of the drm atomic state and triggers a devcoredump. changes in v4: - rename dpu_dbg to msm_disp_snapshot and move it to msm/disp - start using a list of blocks to store the hardware block information - cleanup block allocation and freeing logic to simplify it Abhinav Kumar (3): drm: allow drm_atomic_print_state() to accept any drm_printer drm/msm: add support to take dpu snapshot drm/msm: add disp snapshot points across dpu driver drivers/gpu/drm/drm_atomic.c | 28 +++- drivers/gpu/drm/drm_atomic_uapi.c | 4 +- drivers/gpu/drm/drm_crtc_internal.h| 4 +- drivers/gpu/drm/msm/Makefile | 2 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 18 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 14 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 61 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 5 + drivers/gpu/drm/msm/disp/msm_disp_snapshot.c | 161 ++ drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 167 +++ drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 181 + drivers/gpu/drm/msm/dp/dp_catalog.c| 12 ++ drivers/gpu/drm/msm/dp/dp_catalog.h| 4 + drivers/gpu/drm/msm/dp/dp_display.c| 29 drivers/gpu/drm/msm/dp/dp_display.h| 1 + drivers/gpu/drm/msm/dsi/dsi.c | 5 + drivers/gpu/drm/msm/dsi/dsi.h | 4 + drivers/gpu/drm/msm/dsi/dsi_host.c | 19 +++ drivers/gpu/drm/msm/msm_drv.c | 29 +++- drivers/gpu/drm/msm/msm_drv.h | 2 + drivers/gpu/drm/selftests/test-drm_framebuffer.c | 1 + 23 files changed, 743 insertions(+), 18 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.c create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.h create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] drm: allow drm_atomic_print_state() to accept any drm_printer
Currently drm_atomic_print_state() internally allocates and uses a
drm_info printer. Allow it to accept any drm_printer type so that
the API can be leveraged even for taking drm snapshot.
Rename the drm_atomic_print_state() to drm_atomic_print_new_state()
so that it reflects its functionality better.
changes in v4:
- none
Reported-by: kernel test robot
Signed-off-by: Abhinav Kumar
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic.c | 28 +++-
drivers/gpu/drm/drm_atomic_uapi.c| 4 +++-
drivers/gpu/drm/drm_crtc_internal.h | 4 +++-
drivers/gpu/drm/selftests/test-drm_framebuffer.c | 1 +
4 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index dda6005..7041a26 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1,6 +1,7 @@
/*
* Copyright (C) 2014 Red Hat
* Copyright (C) 2014 Intel Corp.
+ * Copyright (c) 2020-2021, The Linux Foundation. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -1573,9 +1574,20 @@ int __drm_atomic_helper_set_config(struct drm_mode_set
*set,
}
EXPORT_SYMBOL(__drm_atomic_helper_set_config);
-void drm_atomic_print_state(const struct drm_atomic_state *state)
+/**
+ * drm_atomic_print_new_state - prints drm atomic state
+ * @state: atomic configuration to check
+ * @p: drm printer
+ *
+ * This functions prints the drm atomic state snapshot using the drm printer
+ * which is passed to it. This snapshot can be used for debugging purposes.
+ *
+ * Note that this function looks into the new state objects and hence its not
+ * safe to be used after the call to drm_atomic_helper_commit_hw_done().
+ */
+void drm_atomic_print_new_state(const struct drm_atomic_state *state,
+ struct drm_printer *p)
{
- struct drm_printer p = drm_info_printer(state->dev->dev);
struct drm_plane *plane;
struct drm_plane_state *plane_state;
struct drm_crtc *crtc;
@@ -1584,17 +1596,23 @@ void drm_atomic_print_state(const struct
drm_atomic_state *state)
struct drm_connector_state *connector_state;
int i;
+ if (!p) {
+ DRM_ERROR("invalid drm printer\n");
+ return;
+ }
+
DRM_DEBUG_ATOMIC("checking %p\n", state);
for_each_new_plane_in_state(state, plane, plane_state, i)
- drm_atomic_plane_print_state(&p, plane_state);
+ drm_atomic_plane_print_state(p, plane_state);
for_each_new_crtc_in_state(state, crtc, crtc_state, i)
- drm_atomic_crtc_print_state(&p, crtc_state);
+ drm_atomic_crtc_print_state(p, crtc_state);
for_each_new_connector_in_state(state, connector, connector_state, i)
- drm_atomic_connector_print_state(&p, connector_state);
+ drm_atomic_connector_print_state(p, connector_state);
}
+EXPORT_SYMBOL(drm_atomic_print_new_state);
static void __drm_state_dump(struct drm_device *dev, struct drm_printer *p,
bool take_locks)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 268bb69..c340a67 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -2,6 +2,7 @@
* Copyright (C) 2014 Red Hat
* Copyright (C) 2014 Intel Corp.
* Copyright (C) 2018 Intel Corp.
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -1321,6 +1322,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
struct drm_out_fence_state *fence_state;
int ret = 0;
unsigned int i, j, num_fences;
+ struct drm_printer p = drm_info_printer(dev->dev);
/* disallow for drivers not supporting atomic: */
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
@@ -1453,7 +1455,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
ret = drm_atomic_nonblocking_commit(state);
} else {
if (drm_debug_enabled(DRM_UT_STATE))
- drm_atomic_print_state(state);
+ drm_atomic_print_new_state(state, &p);
ret = drm_atomic_commit(state);
}
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 54d4cf1..1ca51ad 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -5,6 +5,7 @@
* Jesse Barnes
* Copyright © 2014 Intel Corporation
* Daniel Vetter
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and ass
[PATCH v4 2/3] drm/msm: add support to take dpu snapshot
Add the msm_disp_snapshot module which adds supports to dump dpu
registers and capture the drm atomic state which can be used in
case of error conditions.
changes in v4:
- rename dpu_dbg to msm_disp_snapshot and move it to msm/disp
- start using a list of blocks to store the hardware block information
- cleanup block allocation and freeing logic to simplify it
Reported-by: kernel test robot
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 61
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 5 +
drivers/gpu/drm/msm/disp/msm_disp_snapshot.c | 161 +++
drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 167
drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 181 ++
drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++
drivers/gpu/drm/msm/dp/dp_catalog.h | 4 +
drivers/gpu/drm/msm/dp/dp_display.c | 29
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
drivers/gpu/drm/msm/dsi/dsi.c | 5 +
drivers/gpu/drm/msm/dsi/dsi.h | 4 +
drivers/gpu/drm/msm/dsi/dsi_host.c| 19 +++
drivers/gpu/drm/msm/msm_drv.c | 29 +++-
drivers/gpu/drm/msm/msm_drv.h | 2 +
16 files changed, 682 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.c
create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.h
create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 610d630..65d86ce 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -77,6 +77,8 @@ msm-y := \
disp/dpu1/dpu_plane.o \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
+ disp/msm_disp_snapshot.o \
+ disp/msm_disp_snapshot_util.o \
msm_atomic.o \
msm_atomic_tracepoints.o \
msm_debugfs.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 4dfd8a2..0f9f0a5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -1,5 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
*/
#ifndef _DPU_HW_CATALOG_H
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 88e9cc3..7529566 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -798,6 +798,67 @@ static void dpu_irq_uninstall(struct msm_kms *kms)
dpu_core_irq_uninstall(dpu_kms);
}
+void dpu_kms_mdp_snapshot(struct drm_device *dev)
+{
+ int i;
+ struct msm_drm_private *priv;
+ struct dpu_kms *dpu_kms;
+ struct dpu_mdss_cfg *cat;
+ struct dpu_hw_mdp *top;
+ struct msm_disp_state *disp_state;
+ char name[SZ_128];
+
+ priv = dev->dev_private;
+ dpu_kms = to_dpu_kms(priv->kms);
+ disp_state = dpu_kms->disp_state;
+
+ cat = dpu_kms->catalog;
+ top = dpu_kms->hw_mdp;
+
+ pm_runtime_get_sync(&dpu_kms->pdev->dev);
+
+ /* dump CTL sub-blocks HW regs info */
+ for (i = 0; i < cat->ctl_count; i++) {
+ snprintf(name, SZ_128, "ctl_%d", i);
+ msm_disp_snapshot_add_block(disp_state, name, cat->ctl[i].len,
+ dpu_kms->mmio + cat->ctl[i].base);
+ }
+
+ /* dump DSPP sub-blocks HW regs info */
+ for (i = 0; i < cat->dspp_count; i++) {
+ snprintf(name, SZ_128, "dspp_%d", i);
+ msm_disp_snapshot_add_block(disp_state, name, cat->dspp[i].len,
+ dpu_kms->mmio + cat->dspp[i].base);
+ }
+
+ /* dump INTF sub-blocks HW regs info */
+ for (i = 0; i < cat->intf_count; i++) {
+ snprintf(name, SZ_128, "intf_%d", i);
+ msm_disp_snapshot_add_block(disp_state, name, cat->intf[i].len,
+ dpu_kms->mmio + cat->intf[i].base);
+ }
+
+ /* dump PP sub-blocks HW regs info */
+ for (i = 0; i < cat->pingpong_count; i++) {
+ snprintf(name, SZ_128, "ping-pong_%d", i);
+ msm_disp_snapshot_add_block(disp_state, name,
cat->pingpong[i].len,
+ dpu_kms->mmio + cat->pingpong[i].base);
+ }
+
+ /* dump SSPP sub-blocks HW regs info */
+ for (i = 0; i < cat->sspp_count; i++) {
+ snprintf(name, SZ_128, "sspp_%d", i);
+ msm_disp_snapshot_add_block(disp_state, name, cat->sspp[i].len,
+
[PATCH v4 3/3] drm/msm: add disp snapshot points across dpu driver
Add snapshot points across dpu driver to trigger dumps when critical
errors are hit.
changes in v4:
- change the callers to use the new snapshot macro
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 14 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 8 +++-
3 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 8d94205..39b2df9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Copyright (c) 2014-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014-2018, 2020-2021 The Linux Foundation. All rights
reserved.
* Copyright (C) 2013 Red Hat
* Author: Rob Clark
*/
@@ -26,6 +26,7 @@
#include "dpu_crtc.h"
#include "dpu_trace.h"
#include "dpu_core_irq.h"
+#include "disp/msm_disp_snapshot.h"
#define DPU_DEBUG_ENC(e, fmt, ...) DPU_DEBUG("enc%d " fmt,\
(e) ? (e)->base.base.id : -1, ##__VA_ARGS__)
@@ -1336,6 +1337,13 @@ static void dpu_encoder_underrun_callback(struct
drm_encoder *drm_enc,
DPU_ATRACE_BEGIN("encoder_underrun_callback");
atomic_inc(&phy_enc->underrun_cnt);
+
+ /* trigger dump only on the first underrun */
+ if (atomic_read(&phy_enc->underrun_cnt) == 1) {
+ pr_err("triggering dump\n");
+ MSM_DISP_SNAPSHOT(drm_enc->dev);
+ }
+
trace_dpu_enc_underrun_cb(DRMID(drm_enc),
atomic_read(&phy_enc->underrun_cnt));
DPU_ATRACE_END("encoder_underrun_callback");
@@ -1565,19 +1573,23 @@ static void dpu_encoder_helper_hw_reset(struct
dpu_encoder_phys *phys_enc)
struct dpu_encoder_virt *dpu_enc;
struct dpu_hw_ctl *ctl;
int rc;
+ struct drm_encoder *drm_enc;
dpu_enc = to_dpu_encoder_virt(phys_enc->parent);
ctl = phys_enc->hw_ctl;
+ drm_enc = phys_enc->parent;
if (!ctl->ops.reset)
return;
- DRM_DEBUG_KMS("id:%u ctl %d reset\n", DRMID(phys_enc->parent),
+ DRM_DEBUG_KMS("id:%u ctl %d reset\n", DRMID(drm_enc),
ctl->idx);
rc = ctl->ops.reset(ctl);
- if (rc)
+ if (rc) {
DPU_ERROR_ENC(dpu_enc, "ctl %d reset failure\n", ctl->idx);
+ MSM_DISP_SNAPSHOT(drm_enc->dev);
+ }
phys_enc->enable_state = DPU_ENC_ENABLED;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index b2be39b..f587985 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Copyright (c) 2015-2018 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2015-2018, 2020-2021 The Linux Foundation. All rights
reserved.
*/
#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
@@ -11,6 +11,7 @@
#include "dpu_core_irq.h"
#include "dpu_formats.h"
#include "dpu_trace.h"
+#include "disp/msm_disp_snapshot.h"
#define DPU_DEBUG_CMDENC(e, fmt, ...) DPU_DEBUG("enc%d intf%d " fmt, \
(e) && (e)->base.parent ? \
@@ -191,10 +192,13 @@ static int _dpu_encoder_phys_cmd_handle_ppdone_timeout(
to_dpu_encoder_phys_cmd(phys_enc);
u32 frame_event = DPU_ENCODER_FRAME_EVENT_ERROR;
bool do_log = false;
+ struct drm_encoder *drm_enc;
if (!phys_enc->hw_pp)
return -EINVAL;
+ drm_enc = phys_enc->parent;
+
cmd_enc->pp_timeout_report_cnt++;
if (cmd_enc->pp_timeout_report_cnt == PP_TIMEOUT_MAX_TRIALS) {
frame_event |= DPU_ENCODER_FRAME_EVENT_PANEL_DEAD;
@@ -203,7 +207,7 @@ static int _dpu_encoder_phys_cmd_handle_ppdone_timeout(
do_log = true;
}
- trace_dpu_enc_phys_cmd_pdone_timeout(DRMID(phys_enc->parent),
+ trace_dpu_enc_phys_cmd_pdone_timeout(DRMID(drm_enc),
phys_enc->hw_pp->idx - PINGPONG_0,
cmd_enc->pp_timeout_report_cnt,
atomic_read(&phys_enc->pending_kickoff_cnt),
@@ -212,12 +216,12 @@ static int _dpu_encoder_phys_cmd_handle_ppdone_timeout(
/* to avoid flooding, only log first time, and "dead" time */
if (do_log) {
DRM_ERROR("id:%d pp:%d kickoff timeout %d cnt %d koff_cnt %d\n",
- DRMID(phys_enc->parent),
+ DRMID(drm_enc),
phys_enc->hw_pp->idx - PINGPONG_0,
phys_enc->hw_ctl->idx - CTL_0,
cmd_enc->pp_timeout_report_cnt,
atomic_read(&phys_enc->pendi
Re: [PATCH] drm/virtio: Create Dumb BOs as guest Blobs (v3)
On Mon, Apr 12, 2021 at 10:36 PM Vivek Kasireddy
wrote:
> If support for Blob resources is available, then dumb BOs created
> by the driver can be considered as guest Blobs.
>
> v2: Don't skip transfer and flush commands as part of plane update
> as the device may have created a shared mapping. (Gerd)
>
> v3: Don't create dumb BOs as Guest blobs if Virgl is enabled. (Gurchetan)
>
I think it is a good start and advances QEMU blobs. Improvements are
always possible, but may be made at a future time.
Acked-by: Gurchetan Singh
>
> Cc: Gerd Hoffmann
> Signed-off-by: Vivek Kasireddy
> ---
> drivers/gpu/drm/virtio/virtgpu_gem.c| 8
> drivers/gpu/drm/virtio/virtgpu_object.c | 3 +++
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c
> b/drivers/gpu/drm/virtio/virtgpu_gem.c
> index 8502400b2f9c..2de61b63ef91 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_gem.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
> @@ -64,6 +64,7 @@ int virtio_gpu_mode_dumb_create(struct drm_file
> *file_priv,
> {
> struct drm_gem_object *gobj;
> struct virtio_gpu_object_params params = { 0 };
> + struct virtio_gpu_device *vgdev = dev->dev_private;
> int ret;
> uint32_t pitch;
>
> @@ -79,6 +80,13 @@ int virtio_gpu_mode_dumb_create(struct drm_file
> *file_priv,
> params.height = args->height;
> params.size = args->size;
> params.dumb = true;
> +
> + if (vgdev->has_resource_blob && !vgdev->has_virgl_3d) {
> + params.blob_mem = VIRTGPU_BLOB_MEM_GUEST;
> + params.blob_flags = VIRTGPU_BLOB_FLAG_USE_SHAREABLE;
> + params.blob = true;
> + }
> +
> ret = virtio_gpu_gem_create(file_priv, dev, ¶ms, &gobj,
> &args->handle);
> if (ret)
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index 4ff1ec28e630..f648b0e24447 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -254,6 +254,9 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
> }
>
> if (params->blob) {
> + if (params->blob_mem == VIRTGPU_BLOB_MEM_GUEST)
> + bo->guest_blob = true;
> +
> virtio_gpu_cmd_resource_create_blob(vgdev, bo, params,
> ents, nents);
> } else if (params->virgl) {
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/3] drm/msm: add support to take dpu snapshot
On 15/04/2021 02:11, Abhinav Kumar wrote:
Add the msm_disp_snapshot module which adds supports to dump dpu
registers and capture the drm atomic state which can be used in
case of error conditions.
changes in v4:
- rename dpu_dbg to msm_disp_snapshot and move it to msm/disp
- start using a list of blocks to store the hardware block information
- cleanup block allocation and freeing logic to simplify it
Reported-by: kernel test robot
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 61
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 5 +
drivers/gpu/drm/msm/disp/msm_disp_snapshot.c | 161 +++
drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 167
drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 181 ++
drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++
drivers/gpu/drm/msm/dp/dp_catalog.h | 4 +
drivers/gpu/drm/msm/dp/dp_display.c | 29
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
drivers/gpu/drm/msm/dsi/dsi.c | 5 +
drivers/gpu/drm/msm/dsi/dsi.h | 4 +
drivers/gpu/drm/msm/dsi/dsi_host.c| 19 +++
drivers/gpu/drm/msm/msm_drv.c | 29 +++-
drivers/gpu/drm/msm/msm_drv.h | 2 +
Generic suggestion: Could you please split this patch, separating core
snapshotting functionality, dpu1, dsi and dp changes? This would ease
reviewing.
16 files changed, 682 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.c
create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.h
create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 610d630..65d86ce 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -77,6 +77,8 @@ msm-y := \
disp/dpu1/dpu_plane.o \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
+ disp/msm_disp_snapshot.o \
+ disp/msm_disp_snapshot_util.o \
If snapshotting is going to be used by dsi/dp, what about landing it
into the top drivers/gpu/drm/msm dir? This way we'd point that it is a
generic piece of code shared between all drm/msm drivers.
msm_atomic.o \
msm_atomic_tracepoints.o \
msm_debugfs.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 4dfd8a2..0f9f0a5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -1,5 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights reserved.
*/
#ifndef _DPU_HW_CATALOG_H
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 88e9cc3..7529566 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -798,6 +798,67 @@ static void dpu_irq_uninstall(struct msm_kms *kms)
dpu_core_irq_uninstall(dpu_kms);
}
+void dpu_kms_mdp_snapshot(struct drm_device *dev)
+{
+ int i;
+ struct msm_drm_private *priv;
+ struct dpu_kms *dpu_kms;
+ struct dpu_mdss_cfg *cat;
+ struct dpu_hw_mdp *top;
+ struct msm_disp_state *disp_state;
+ char name[SZ_128];
+
+ priv = dev->dev_private;
+ dpu_kms = to_dpu_kms(priv->kms);
+ disp_state = dpu_kms->disp_state;
+
+ cat = dpu_kms->catalog;
+ top = dpu_kms->hw_mdp;
+
+ pm_runtime_get_sync(&dpu_kms->pdev->dev);
+
+ /* dump CTL sub-blocks HW regs info */
+ for (i = 0; i < cat->ctl_count; i++) {
+ snprintf(name, SZ_128, "ctl_%d", i);
snprintf(name, sizeof(name), "ctl_%d", i);
(the same bellow)
+ msm_disp_snapshot_add_block(disp_state, name, cat->ctl[i].len,
+ dpu_kms->mmio + cat->ctl[i].base);
+ }
+
+ /* dump DSPP sub-blocks HW regs info */
+ for (i = 0; i < cat->dspp_count; i++) {
+ snprintf(name, SZ_128, "dspp_%d", i);
+ msm_disp_snapshot_add_block(disp_state, name, cat->dspp[i].len,
+ dpu_kms->mmio + cat->dspp[i].base);
+ }
+
+ /* dump INTF sub-blocks HW regs info */
+ for (i = 0; i < cat->intf_count; i++) {
+ snprintf(name, SZ_128, "intf_%d", i);
+ msm_disp_snapshot_add_block(disp_state, name, cat->intf[i].len,
+ dpu_kms->mmio + cat->intf[i].base);
+ }
+
+ /* dump PP sub-blocks HW regs info */
+ for (i = 0; i < cat
Re: [PATCH v2 11/14] drm/bridge: ti-sn65dsi86: Power things properly for reading the EDID
Hi Andrzej,
On Tue, Apr 06, 2021 at 06:52:07PM +0200, Andrzej Hajda wrote:
> Hello again after easter,
>
> I have looked little bit more at sn65* driver and its application to
> have better background.
>
> I miss only info what panel do you have, how it is enabled/power controlled.
>
> W dniu 01.04.2021 o 16:57, Doug Anderson pisze:
> > On Thu, Apr 1, 2021 at 4:12 AM Andrzej Hajda wrote:
> >> W dniu 31.03.2021 o 16:48, Doug Anderson pisze:
> >>> On Wed, Mar 31, 2021 at 4:08 AM Andrzej Hajda wrote:
> W dniu 30.03.2021 o 04:53, Douglas Anderson pisze:
> > eDP panels won't provide their EDID unless they're powered on. Let's
> > chain a power-on before we read the EDID. This roughly matches what
> > was done in 'parade-ps8640.c'.
> >
> > NOTE: The old code attempted to call pm_runtime_get_sync() before
> > reading the EDID. While that was enough to power the bridge chip on,
> > it wasn't enough to talk to the panel for two reasons:
> > 1. Since we never ran the bridge chip's pre-enable then we never set
> > the bit to ignore HPD. This meant the bridge chip didn't even
> > _try_
> > to go out on the bus and communicate with the panel.
> > 2. Even if we fixed things to ignore HPD, the EDID still wouldn't read
> > if the panel wasn't on.
> >
> > One thing that's a bit odd here is taking advantage of the EDID that
> > the core might have cached for us. See the patch ("drm/edid: Use the
> > cached EDID in drm_get_edid() if eDP"). We manage to get at the cache
> > by:
> > - Instantly failing aux transfers if we're not powered.
> > - If the first read of the EDID fails we try again after powering.
> >
> > Fixes: 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over
> > DDC")
> > Signed-off-by: Douglas Anderson
> > ---
> > Depending on what people think of the other patches in this series,
> > some of this could change.
> > - If everyone loves the "runtime PM" in the panel driver then we
> > could, in theory, put the pre-enable chaining straight in the "aux
> > transfer" function.
> > - If everyone hates the EDID cache moving to the core then we can
> > avoid some of the awkward flow of things and keep the EDID cache in
> > the sn65dsi86 driver.
>
> I wonder if this shouldn't be solved in the core - ie caller of
> get_modes callback should be responsible for powering up the pipeline,
> otherwise we need to repeat this stuff in every bridge/panel driver.
>
> Any thoughts?
> >>>
> >>> Yeah, I did look at this a little bit. Presumably it would only make
> >>> sense to do it for eDP connections since:
> >>>
> >>> a) The concept of reading an EDID doesn't make sense for things like MIPI.
> >>
> >> I guess you mean MIPI DSI
> >
> > Yes, sorry! I'll try to be more clear.
> >
> >> and yes I agree, more generally it usually(!)
> >> doesn't make sense for any setup with fixed display panel.
> >>
> >> On the other hand there are DSI/HDMI or DSI/DP adapters which usually
> >> have EDID reading logic.
> >>
> >> And the concept makes sense for most connectors accepting external
> >> displays: HDMI, DP, MHL, VGA...
> >
> > So, actually, IMO the concept doesn't make sense for anything with an
> > external connector. Here's the logic for a handful of connectors:
> >
> > 1. MIPI DSI: there is no EDID so this doesn't make sense.
> >
> > 2. An external connector (HDMI, DP, etc): the display that's plugged
> > in is externally powered so doesn't need us to power it up to read the
> > EDID. By definition, when the HPD signal is asserted then it's OK to
> > read the EDID and we don't even know if a display is plugged in until
> > HPD is asserted. Thus no special power sequencing is needed to read
> > the EDID. (Yes, we need to make sure that the eDP controller itself
> > is powered, but that doesn't seem like it's the core's business).
>
> Not true IMO, even if external device is powered on, you must enable
> EDID-reader logic.
Sure, but I think Doug was referring to powering up the device connected
to the SN65DSI86 output. When that device (from a DT and DRM bridge
point of view) is an external connector, it means that the hardware
device is an external HDMI/DP sink, and we have no way to control its
power. The SN65DSI86 itself of course needs to be powered.
> I guess it is not uncommon to have different power states for EDID
> reading and bridge/panel pre-enablement (especially in embedded world).
> In fact there are setups where EDID-reader is totally different device
> than the bridge itself, and these devices should be
> powered/enabled/operational only for time of EDID reading.
>
> > 3. eDP: this is where it matters. This is because:
> >
> > 3a) eDP displays aren't powered all the time. If you just boot up or
> > you blank your screen, likely the display has no power at all.
> >
> > 3b) Because the display
Re: [PATCH v3 12/12] drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare
Hi Doug,
Thank you for the patch.
On Fri, Apr 02, 2021 at 03:28:46PM -0700, Douglas Anderson wrote:
> Unpreparing and re-preparing a panel can be a really heavy
> operation. Panels datasheets often specify something on the order of
> 500ms as the delay you should insert after turning off the panel
> before turning it on again. In addition, turning on a panel can have
> delays on the order of 100ms - 200ms before the panel will assert HPD
> (AKA "panel ready"). The above means that we should avoid turning a
> panel off if we're going to turn it on again shortly.
>
> The above becomes a problem when we want to read the EDID of a
> panel. The way that ordering works is that userspace wants to read the
> EDID of the panel _before_ fully enabling it so that it can set the
> initial mode correctly. However, we can't read the EDID until we power
> it up. This leads to code that does this dance (like
> ps8640_bridge_get_edid()):
>
> 1. When userspace requests EDID / the panel modes (through an ioctl),
>we power on the panel just enough to read the EDID and then power
>it off.
> 2. Userspace then turns the panel on.
>
> There's likely not much time between step #1 and #2 and so we want to
> avoid powering the panel off and on again between those two steps.
>
> Let's use Runtime PM to help us. We'll move the existing prepare() and
> unprepare() to be runtime resume() and runtime suspend(). Now when we
> want to prepare() or unprepare() we just increment or decrement the
> refcount. We'll default to a 1 second autosuspend delay which seems
> sane given the typical delays we see for panels.
>
> A few notes:
> - It seems the existing unprepare() and prepare() are defined to be
> no-ops if called extra times. We'll preserve that behavior.
The prepare and unprepare calls are supposed to be balanced, which
should allow us to drop this check. Do you have a reason to suspect that
it may not be the case ?
> - This is a slight change in the ABI of simple panel. If something was
> absolutely relying on the unprepare() to happen instantly that
> simply won't be the case anymore. I'm not aware of anyone relying on
> that behavior, but if there is someone then we'll need to figure out
> how to enable (or disable) this new delayed behavior selectively.
> - In order for this to work we now have a hard dependency on
> "PM". From memory this is a legit thing to assume these days and we
> don't have to find some fallback to keep working if someone wants to
> build their system without "PM".
Sounds fine to me.
The code looks good to me. Possibly with the prepared check removed,
Reviewed-by: Laurent Pinchart
> Signed-off-by: Douglas Anderson
> ---
>
> (no changes since v1)
>
> drivers/gpu/drm/panel/Kconfig| 1 +
> drivers/gpu/drm/panel/panel-simple.c | 93 +---
> 2 files changed, 73 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 4894913936e9..ef87d92cdf49 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -80,6 +80,7 @@ config DRM_PANEL_SIMPLE
> tristate "support for simple panels"
> depends on OF
> depends on BACKLIGHT_CLASS_DEVICE
> + depends on PM
> select VIDEOMODE_HELPERS
> help
> DRM panel driver for dumb panels that need at most a regulator and
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index be312b5c04dd..6b22872b3281 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -175,6 +176,8 @@ struct panel_simple {
> bool enabled;
> bool no_hpd;
>
> + bool prepared;
> +
> ktime_t prepared_time;
> ktime_t unprepared_time;
>
> @@ -334,19 +337,31 @@ static int panel_simple_disable(struct drm_panel *panel)
> return 0;
> }
>
> +static int panel_simple_suspend(struct device *dev)
> +{
> + struct panel_simple *p = dev_get_drvdata(dev);
> +
> + gpiod_set_value_cansleep(p->enable_gpio, 0);
> + regulator_disable(p->supply);
> + p->unprepared_time = ktime_get();
> +
> + return 0;
> +}
> +
> static int panel_simple_unprepare(struct drm_panel *panel)
> {
> struct panel_simple *p = to_panel_simple(panel);
> + int ret;
>
> - if (p->prepared_time == 0)
> + /* Unpreparing when already unprepared is a no-op */
> + if (!p->prepared)
> return 0;
>
> - gpiod_set_value_cansleep(p->enable_gpio, 0);
> -
> - regulator_disable(p->supply);
> -
> - p->prepared_time = 0;
> - p->unprepared_time = ktime_get();
> + pm_runtime_mark_last_busy(panel->dev);
> + ret = pm_runtime_put_autosuspend(panel->dev);
> + if (ret < 0)
> + return ret;
> + p->prepared = false;
>
> return 0;
> }
> @@ -376,22 +3
Re: [PATCH v4 2/3] drm/msm: add support to take dpu snapshot
Hi Dmitry
Thanks for the review.
On 2021-04-14 17:16, Dmitry Baryshkov wrote:
On 15/04/2021 02:11, Abhinav Kumar wrote:
Add the msm_disp_snapshot module which adds supports to dump dpu
registers and capture the drm atomic state which can be used in
case of error conditions.
changes in v4:
- rename dpu_dbg to msm_disp_snapshot and move it to msm/disp
- start using a list of blocks to store the hardware block
information
- cleanup block allocation and freeing logic to simplify it
Reported-by: kernel test robot
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile | 2 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 61
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 5 +
drivers/gpu/drm/msm/disp/msm_disp_snapshot.c | 161
+++
drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 167
drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 181
++
drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++
drivers/gpu/drm/msm/dp/dp_catalog.h | 4 +
drivers/gpu/drm/msm/dp/dp_display.c | 29
drivers/gpu/drm/msm/dp/dp_display.h | 1 +
drivers/gpu/drm/msm/dsi/dsi.c | 5 +
drivers/gpu/drm/msm/dsi/dsi.h | 4 +
drivers/gpu/drm/msm/dsi/dsi_host.c| 19 +++
drivers/gpu/drm/msm/msm_drv.c | 29 +++-
drivers/gpu/drm/msm/msm_drv.h | 2 +
Generic suggestion: Could you please split this patch, separating core
snapshotting functionality, dpu1, dsi and dp changes? This would ease
reviewing.
Core snapshotting functionality does include calling into the individual
driver's snapshot function.
So the diffstat which you are seeing in the dpu1/dsi and dp are just
their snapshotting functions and nothing else.
16 files changed, 682 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.c
create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.h
create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c
diff --git a/drivers/gpu/drm/msm/Makefile
b/drivers/gpu/drm/msm/Makefile
index 610d630..65d86ce 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -77,6 +77,8 @@ msm-y := \
disp/dpu1/dpu_plane.o \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
+ disp/msm_disp_snapshot.o \
+ disp/msm_disp_snapshot_util.o \
If snapshotting is going to be used by dsi/dp, what about landing it
into the top drivers/gpu/drm/msm dir? This way we'd point that it is a
generic piece of code shared between all drm/msm drivers.
I dont have a strong preference of drm/msm Vs drm/msm/disp. I just put
them here
based on Rob's comment on the prev patchset
https://patchwork.freedesktop.org/patch/427690/?series=82942&rev=3
msm_atomic.o \
msm_atomic_tracepoints.o \
msm_debugfs.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 4dfd8a2..0f9f0a5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -1,5 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0-only */
-/* Copyright (c) 2015-2018, The Linux Foundation. All rights
reserved.
+/* Copyright (c) 2015-2018, 2020 The Linux Foundation. All rights
reserved.
*/
#ifndef _DPU_HW_CATALOG_H
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 88e9cc3..7529566 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -798,6 +798,67 @@ static void dpu_irq_uninstall(struct msm_kms
*kms)
dpu_core_irq_uninstall(dpu_kms);
}
+void dpu_kms_mdp_snapshot(struct drm_device *dev)
+{
+ int i;
+ struct msm_drm_private *priv;
+ struct dpu_kms *dpu_kms;
+ struct dpu_mdss_cfg *cat;
+ struct dpu_hw_mdp *top;
+ struct msm_disp_state *disp_state;
+ char name[SZ_128];
+
+ priv = dev->dev_private;
+ dpu_kms = to_dpu_kms(priv->kms);
+ disp_state = dpu_kms->disp_state;
+
+ cat = dpu_kms->catalog;
+ top = dpu_kms->hw_mdp;
+
+ pm_runtime_get_sync(&dpu_kms->pdev->dev);
+
+ /* dump CTL sub-blocks HW regs info */
+ for (i = 0; i < cat->ctl_count; i++) {
+ snprintf(name, SZ_128, "ctl_%d", i);
snprintf(name, sizeof(name), "ctl_%d", i);
(the same bellow)
Rob just mentioned to me on IRC to move this snprintf inside
msm_disp_snapshot_add_block(). I am planning to do that in the next
patchset.
With that will fix this too.
+ msm_disp_snapshot_add_block(disp_state, name, cat->ctl[i].len,
+ dpu_kms->mmio + cat->ctl[i].base);
+ }
+
+ /* d
Re: [PATCH v2 11/14] drm/bridge: ti-sn65dsi86: Power things properly for reading the EDID
Hi,
On Tue, Apr 6, 2021 at 9:52 AM Andrzej Hajda wrote:
>
> Hello again after easter,
Sorry, I was out last week and I'm just getting back to this now.
> I have looked little bit more at sn65* driver and its application to
> have better background.
>
> I miss only info what panel do you have, how it is enabled/power controlled.
I am personally working on "sc7180-trogdor" boards right now
(arch/arm64/boot/dts/qcom/sc7180-trogdor*.dts). However I believe that
this patch series also enables proper EDID reading on
"sdm850-lenovo-yoga-c630.dts". That board, while also a Qualcomm
board, has completely different heritage than the trogdor ones. It's a
laptop that ships with Windows and (as far as I know) was designed
mostly independently.
On the trogdor boards the bridge has some power rails and an enable
line hooked up to it and the bridge itself can work when these rails
are turned on. The panel is on a separate power rail and you can't
talk to the panel at all until it's powered on and then asserts HPD to
us to say it finished its boot sequence.
> W dniu 01.04.2021 o 16:57, Doug Anderson pisze:
> > Hi,
> >
> > On Thu, Apr 1, 2021 at 4:12 AM Andrzej Hajda wrote:
> >>
> >> W dniu 31.03.2021 o 16:48, Doug Anderson pisze:
> >>> Hi,
> >>>
> >>> On Wed, Mar 31, 2021 at 4:08 AM Andrzej Hajda wrote:
> W dniu 30.03.2021 o 04:53, Douglas Anderson pisze:
> > eDP panels won't provide their EDID unless they're powered on. Let's
> > chain a power-on before we read the EDID. This roughly matches what
> > was done in 'parade-ps8640.c'.
> >
> > NOTE: The old code attempted to call pm_runtime_get_sync() before
> > reading the EDID. While that was enough to power the bridge chip on,
> > it wasn't enough to talk to the panel for two reasons:
> > 1. Since we never ran the bridge chip's pre-enable then we never set
> > the bit to ignore HPD. This meant the bridge chip didn't even
> > _try_
> > to go out on the bus and communicate with the panel.
> > 2. Even if we fixed things to ignore HPD, the EDID still wouldn't read
> > if the panel wasn't on.
> >
> > One thing that's a bit odd here is taking advantage of the EDID that
> > the core might have cached for us. See the patch ("drm/edid: Use the
> > cached EDID in drm_get_edid() if eDP"). We manage to get at the cache
> > by:
> > - Instantly failing aux transfers if we're not powered.
> > - If the first read of the EDID fails we try again after powering.
> >
> > Fixes: 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over
> > DDC")
> > Signed-off-by: Douglas Anderson
> > ---
> > Depending on what people think of the other patches in this series,
> > some of this could change.
> > - If everyone loves the "runtime PM" in the panel driver then we
> > could, in theory, put the pre-enable chaining straight in the "aux
> > transfer" function.
> > - If everyone hates the EDID cache moving to the core then we can
> > avoid some of the awkward flow of things and keep the EDID cache in
> > the sn65dsi86 driver.
> I wonder if this shouldn't be solved in the core - ie caller of
> get_modes callback should be responsible for powering up the pipeline,
> otherwise we need to repeat this stuff in every bridge/panel driver.
>
> Any thoughts?
> >>> Yeah, I did look at this a little bit. Presumably it would only make
> >>> sense to do it for eDP connections since:
> >>>
> >>> a) The concept of reading an EDID doesn't make sense for things like MIPI.
> >> I guess you mean MIPI DSI
> > Yes, sorry! I'll try to be more clear.
> >
> >
> >> and yes I agree, more generally it usually(!)
> >> doesn't make sense for any setup with fixed display panel.
> >>
> >> On the other hand there are DSI/HDMI or DSI/DP adapters which usually
> >> have EDID reading logic.
> >>
> >> And the concept makes sense for most connectors accepting external
> >> displays: HDMI, DP, MHL, VGA...
> > So, actually, IMO the concept doesn't make sense for anything with an
> > external connector. Here's the logic for a handful of connectors:
> >
> > 1. MIPI DSI: there is no EDID so this doesn't make sense.
> >
> > 2. An external connector (HDMI, DP, etc): the display that's plugged
> > in is externally powered so doesn't need us to power it up to read the
> > EDID. By definition, when the HPD signal is asserted then it's OK to
> > read the EDID and we don't even know if a display is plugged in until
> > HPD is asserted. Thus no special power sequencing is needed to read
> > the EDID. (Yes, we need to make sure that the eDP controller itself
> > is powered, but that doesn't seem like it's the core's business).
>
> Not true IMO, even if external device is powered on, you must enable
> EDID-reader logic.
>
> I guess it is not uncommon to have different power states for EDID
> reading and bridge/panel pre-enablement (especially
