Re: linux-next: manual merge of the tip tree with the amdgpu tree
Hi all,
On Mon, 12 Oct 2020 15:15:27 +1100 Stephen Rothwell
wrote:
>
> On Wed, 23 Sep 2020 15:13:36 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> >
> > between commit:
> >
> > 59d7115dae02 ("drm/amdkfd: Move process doorbell allocation into kfd
> > device")
> >
> > from the amdgpu tree and commit:
> >
> > c7b6bac9c72c ("drm, iommu: Change type of pasid to u32")
> >
> > from the tip tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> >
> > diff --cc drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > index 739db04080d0,922ae138ab85..
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > @@@ -739,7 -723,8 +739,7 @@@ struct kfd_process
> > /* We want to receive a notification when the mm_struct is destroyed */
> > struct mmu_notifier mmu_notifier;
> >
> > - uint16_t pasid;
> > + u32 pasid;
> > - unsigned int doorbell_index;
> >
> > /*
> > * List of kfd_process_device structures,
>
> This is now a conflict between the tip tree and the drm tree.
This is now a conflict between the drm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpFW2B4RSgpZ.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/7] dt-bindings: display: mxsfb: Add a bus-width endpoint property
Hi Marek, On Sat, Oct 10, 2020 at 10:47:05AM +0200, Marek Vasut wrote: > On 10/10/20 1:58 AM, Laurent Pinchart wrote: > > Hi Marek, > > Hi, > > > On Wed, Oct 07, 2020 at 10:40:26AM +0200, Marek Vasut wrote: > >> On 10/7/20 3:24 AM, Laurent Pinchart wrote: > >> > >> [...] > >> > >>> + bus-width: > >>> +enum: [16, 18, 24] > >>> +description: | > >>> + The output bus width. This value overrides the > >>> configuration > >>> + derived from the connected device (encoder or panel). It > >>> should > >>> + only be specified when PCB routing of the data signals > >>> require a > >>> + different bus width on the LCDIF and the connected device. > >>> For > >>> + instance, when a 18-bit RGB panel has its R[5:0], G[5:0] > >>> and > >>> + B[5:0] signals connected to LCD_DATA[7:2], LCD_DATA[15:10] > >>> and > >>> + LCD_DATA[23:18] instead of LCD_DATA[5:0], LCD_DATA[11:6] > >>> and > >>> + LCD_DATA[17:12], bus-width should be set to 24. > >> > >> The iMX6 IPUv3 uses interface-pix-fmt which is a bit more flexible, but > >> I'm not sure whether it's the right way to go about this, see: > >> Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt > > > > I think specifying the bus with is better. It's a standard property, but > > more than that, a given bus width can carry different formats. For > > instance, a 24-bus could carry RGB666 data (with dithering for the > > LSBs). > > I think that's exactly what the interface-pix-fmt was trying to solve > for the IPUv3, there you could have e.g. both RGB666 and LVDS666 , which > were different. My point is that the driver should support multiple formats that can be carried over a given bus width, with the actual format to be used queried from the sink (usually a panel) instead of being hardcoded in DT. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v9 1/5] dt-bindings: display: Add support for Intel KeemBay Display
Hi Neil,
Thanks for your review, please see my reply inline.
> -Original Message-
> From: Neil Armstrong
> Sent: Friday, October 9, 2020 2:10 AM
> To: Chrisanthus, Anitha ; dri-
> de...@lists.freedesktop.org; devicet...@vger.kernel.org; Vetter, Daniel
>
> Cc: Dea, Edmund J ; s...@ravnborg.org
> Subject: Re: [PATCH v9 1/5] dt-bindings: display: Add support for Intel
> KeemBay Display
>
> Hi,
>
> On 09/10/2020 03:03, Anitha Chrisanthus wrote:
> > This patch adds bindings for Intel KeemBay Display
> >
> > v2: review changes from Rob Herring
> >
> > Signed-off-by: Anitha Chrisanthus
> > ---
> > .../bindings/display/intel,keembay-display.yaml| 99
> ++
> > 1 file changed, 99 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/intel,keembay-
> display.yaml b/Documentation/devicetree/bindings/display/intel,keembay-
> display.yaml
> > new file mode 100644
> > index 000..a38493d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/intel,keembay-
> display.yaml
> > @@ -0,0 +1,99 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/intel,keembay-
> display.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Devicetree bindings for Intel Keem Bay display controller
> > +
> > +maintainers:
> > + - Anitha Chrisanthus
> > + - Edmond J Dea
> > +
> > +properties:
> > + compatible:
> > +const: intel,kmb_display
> > +
> > + reg:
> > +items:
> > + - description: Lcd registers range
> > + - description: Mipi registers range
>
> Looking at the registers, the MIPI transceiver seems to be a separate IP,
> same for D-PHY which should have a proper PHY driver instead of beeing
> handled
> here.
>
The LCD, MIPI DSI, DPHY and MSSCAM as a group, are considered the display
subsystem for Keem Bay. As such, there are several interdependencies that make
splitting them up next to impossible and currently we do not have the resources
available for that effort.
> > + - description: Msscam registers range
>
> MSScam here seems to be a clock and reset controller for the LCD and MIPI
> IPs,
> thus should be handler out of DRM.
>
> > +
> > + reg-names:
> > +items:
> > + - const: lcd
> > + - const: mipi
> > + - const: msscam
> > +
> > + clocks:
> > +items:
> > + - description: LCD controller clock
> > + - description: Mipi DSI clock
> > + - description: Mipi DSI econfig clock
> > + - description: Mipi DSI config clock
> > + - description: System clock or pll0 clock
> > +
> > + clock-names:
> > +items:
> > + - const: clk_lcd
> > + - const: clk_mipi
> > + - const: clk_mipi_ecfg
> > + - const: clk_mipi_cfg
> > + - const: clk_pll0
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + encoder-slave:
> > +description: bridge node entry for mipi to hdmi converter
> > +
> > + port:
> > +type: object
> > +description: >
> > + Port node with one endpoint connected to mipi to hdmi converter
> node.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - clocks
> > + - clock-names
> > + - interrupts
> > + - encoder-slave
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +#define MOVISOC_KMB_MSS_AUX_LCD
> > +#define MOVISOC_KMB_MSS_AUX_MIPI_TX0
> > +#define MOVISOC_KMB_MSS_AUX_MIPI_ECFG
> > +#define MOVISOC_KMB_MSS_AUX_MIPI_CFG
> > +#define MOVISOC_KMB_A53_PLL_0_OUT_0
> > +display@2090 {
> > + compatible = "intel,keembay-display";
> > + reg = <0x2093 0x3000>,
> > +<0x2090 0x4000>,
> > +<0x2091 0x30>;
> > + reg-names = "lcd", "mipi", "msscam";
> > + interrupts = ;
> > + clocks = <_clk MOVISOC_KMB_MSS_AUX_LCD>,
> > + <_clk MOVISOC_KMB_MSS_AUX_MIPI_TX0>,
> > + <_clk MOVISOC_KMB_MSS_AUX_MIPI_ECFG>,
> > + <_clk MOVISOC_KMB_MSS_AUX_MIPI_CFG>,
> > + <_clk MOVISOC_KMB_A53_PLL_0_OUT_0>;
> > + clock-names = "clk_lcd", "clk_mipi", "clk_mipi_ecfg",
> > +"clk_mipi_cfg", "clk_pll0";
> > +
> > + encoder-slave = <>;
> > +
> > + port {
> > +dsi_output: endpoint {
> > +remote-endpoint = <_input>;
> > +};
> > + };
> > +};
> >
>
> Anitha, Daniel, this keembay driver should be architectured like other ARM-
> like display
> controllers, with separate drivers for MIPI DSI bridge and msscam clock &
> reset controller.
>
This driver was developed as part of the Keem Bay BSP targeting the LTS 5.4
Yocto kernel. It is part of our current production BSP release after extensive
testing.
At this time there are no plans to incorporate the
Re: [PATCH 1/2] drm/i915/dpcd_bl: uncheck PWM_PIN_CAP when detect eDP backlight capabilities
Completely zoned out on Ccing these patches to stable before submitting them,
but once they hit the mainline kernel you should be able to ask Greg to backport
them if you need. Anyway, pushed to drm-intel-next-queued. Thanks for the
patches!
On Fri, 2020-10-09 at 16:57 +0800, Aaron Ma wrote:
> BOE panel with ID 2270 claims both PWM_PIN_CAP and AUX_SET_CAP backlight
> control bits, but default chip backlight failed to control brightness.
>
> Check AUX_SET_CAP and proceed to check quirks or VBT backlight type.
> DPCD can control the brightness of this pannel.
>
> Signed-off-by: Aaron Ma
> ---
> drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe..308b14159b7c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -334,8 +334,7 @@ intel_dp_aux_display_control_capable(struct
> intel_connector *connector)
>* the panel can support backlight control over the aux channel
>*/
> if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
> - (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
> - !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
> {
> + (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
> drm_dbg_kms(>drm, "AUX Backlight Control Supported!\n");
> return true;
> }
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
On Mon, Oct 12, 2020 at 09:02:54PM +0100, Matthew Wilcox wrote: > On Mon, Oct 12, 2020 at 12:53:54PM -0700, Ira Weiny wrote: > > On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote: > > > On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote: > > > > kmap_atomic() is always preferred over kmap()/kmap_thread(). > > > > kmap_atomic() is _much_ more lightweight since its TLB invalidation is > > > > always CPU-local and never broadcast. > > > > > > > > So, basically, unless you *must* sleep while the mapping is in place, > > > > kmap_atomic() is preferred. > > > > > > But kmap_atomic() disables preemption, so the _ideal_ interface would map > > > it only locally, then on preemption make it global. I don't even know > > > if that _can_ be done. But this email makes it seem like kmap_atomic() > > > has no downsides. > > > > And that is IIUC what Thomas was trying to solve. > > > > Also, Linus brought up that kmap_atomic() has quirks in nesting.[1] > > > > >From what I can see all of these discussions support the need to have > > >something > > between kmap() and kmap_atomic(). > > > > However, the reason behind converting call sites to kmap_thread() are > > different > > between Thomas' patch set and mine. Both require more kmap granularity. > > However, they do so with different reasons and underlying implementations > > but > > with the _same_ resulting semantics; a thread local mapping which is > > preemptable.[2] Therefore they each focus on changing different call sites. > > > > While this patch set is huge I think it serves a valuable purpose to > > identify a > > large number of call sites which are candidates for this new semantic. > > Yes, I agree. My problem with this patch-set is that it ties it to > some Intel feature that almost nobody cares about. I humbly disagree. At this level the only thing this is tied to is the idea that there are additional memory protections available which can be enabled quickly on a per-thread basis. PKS on Intel is but 1 implementation of that. Even the kmap code only has knowledge that there is something which needs to be done special on a devm page. > > Maybe we should > care about it, but you didn't try very hard to make anyone care about > it in the cover letter. Ok my bad. We have customers who care very much about restricting access to the PMEM pages to prevent bugs in the kernel from causing permanent damage to their data/file systems. I'll reword the cover letter better. > > For a future patch-set, I'd like to see you just introduce the new > API. Then you can optimise the Intel implementation of it afterwards. > Those patch-sets have entirely different reviewers. I considered doing this. But this seemed more logical because the feature is being driven by PMEM which is behind the kmap interface not by the users of the API. I can introduce a patch set with a kmap_thread() call which does nothing if that is more palatable but it seems wrong to me to do so. Ira ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm: mxsfb: Primary plane format fix and enhancement
Hello, This small patch series fixes format switching for the primary plane, and adds support for the RGB888 format. There's not much else to tell, please see individual patches for details. Laurent Pinchart (2): drm: mxsfb: Fix format changes for primary plane drm: mxsfb: Add RGB888 support on the primary plane drivers/gpu/drm/mxsfb/mxsfb_drv.c | 5 + drivers/gpu/drm/mxsfb/mxsfb_kms.c | 29 + 2 files changed, 30 insertions(+), 4 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: mxsfb: Fix format changes for primary plane
The primary plane's format is configured in registers that have no
shadow support for live updates. They require the display to be fully
reconfigured in order to be updated. Force a mode set when the primary
plane format changes to ensure this.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 6d512f346918..7a69d9f3a875 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -407,14 +407,28 @@ static int mxsfb_plane_atomic_check(struct drm_plane
*plane,
{
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
struct drm_crtc_state *crtc_state;
+ int ret;
crtc_state = drm_atomic_get_new_crtc_state(plane_state->state,
>crtc);
- return drm_atomic_helper_check_plane_state(plane_state, crtc_state,
- DRM_PLANE_HELPER_NO_SCALING,
- DRM_PLANE_HELPER_NO_SCALING,
- false, true);
+ ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ false, true);
+ if (ret < 0)
+ return ret;
+
+ /*
+* Changing the primary plane format requires stopping the display
+* controller first. Force a full mode set to do so.
+*/
+ if (plane == mxsfb->crtc.primary &&
+ plane_state->visible && plane->state->visible &&
+ plane_state->fb->format != plane->state->fb->format)
+ crtc_state->mode_changed = true;
+
+ return 0;
}
static void mxsfb_plane_primary_atomic_update(struct drm_plane *plane,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: mxsfb: Add RGB888 support on the primary plane
The primary plane can support the packed 24-bit RGB888 format. Enable
it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 5 +
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 7 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index d52cf8a506a5..5ec10f0f6508 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -97,6 +97,11 @@ mxsfb_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
return ERR_PTR(-EINVAL);
}
+ if (info->cpp[0] == 3 && mode_cmd->width % 4) {
+ dev_dbg(dev->dev, "24-bit RGB format requires a width aligned
to 4\n");
+ return ERR_PTR(-EINVAL);
+ }
+
return drm_gem_fb_create(dev, file_priv, mode_cmd);
}
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 7a69d9f3a875..7a0d6bc58be0 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -75,6 +75,12 @@ static void mxsfb_set_formats(struct mxsfb_drm_private
*mxsfb)
ctrl |= CTRL_WORD_LENGTH_16;
ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
break;
+ case DRM_FORMAT_RGB888:
+ dev_dbg(drm->dev, "Setting up RGB888 mode\n");
+ ctrl |= CTRL_WORD_LENGTH_24;
+ /* Enable pixel packing, 4 pixels in 3 bytes. */
+ ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
+ break;
case DRM_FORMAT_XRGB:
dev_dbg(drm->dev, "Setting up XRGB mode\n");
ctrl |= CTRL_WORD_LENGTH_24;
@@ -523,6 +529,7 @@ static const struct drm_plane_funcs mxsfb_plane_funcs = {
static const uint32_t mxsfb_primary_plane_formats[] = {
DRM_FORMAT_RGB565,
+ DRM_FORMAT_RGB888,
DRM_FORMAT_XRGB,
};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/jsl: Split EHL/JSL platform info and PCI ids
On Wed, Oct 07, 2020 at 03:06:38PM +0530, Tejas Upadhyay wrote:
> Recently we came across requirement to identify EHL and JSL
> platform to program them differently. Thus Split the basic
> platform definition, macros, and PCI IDs to differentiate
> between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced
> with IS_JSL_EHL everywhere.
I think the one other place that will need to be updated with this split
is the definition of INTEL_UC_FIRMWARE_DEFS in
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c --- we'll need a new JASPERLAKE
entry there now that's a duplicate of the ELKHARTLAKE one.
There are also a couple minor conflicts with other patches that have
just landed on drm-tip, but aside from that this looks reasonable to me.
Matt
>
> Cc : Matt Roper
> Cc : Ville Syrjälä
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 +++---
> drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 8
> drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 16
> drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_workarounds.c| 4 ++--
> drivers/gpu/drm/i915/i915_drv.h| 7 ---
> drivers/gpu/drm/i915/i915_pci.c| 9 +
> drivers/gpu/drm/i915/intel_device_info.c | 1 +
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> drivers/gpu/drm/i915/intel_pch.c | 6 +++---
> include/drm/i915_pciids.h | 9 ++---
> 15 files changed, 53 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 4400e83f783f..096652921453 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -455,7 +455,7 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
> intel_encoder *encoder)
> intel_de_write(dev_priv, ICL_PORT_TX_DW2_GRP(phy), tmp);
>
> /* For EHL, TGL, set latency optimization for PCS_DW1 lanes */
> - if (IS_ELKHARTLAKE(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
> + if (IS_JSL_EHL(dev_priv) || (INTEL_GEN(dev_priv) >= 12)) {
> tmp = intel_de_read(dev_priv,
> ICL_PORT_PCS_DW1_AUX(phy));
> tmp &= ~LATENCY_OPTIM_MASK;
> @@ -612,7 +612,7 @@ gen11_dsi_setup_dphy_timings(struct intel_encoder
> *encoder,
> }
> }
>
> - if (IS_ELKHARTLAKE(dev_priv)) {
> + if (IS_JSL_EHL(dev_priv)) {
> for_each_dsi_phy(phy, intel_dsi->phys) {
> tmp = intel_de_read(dev_priv, ICL_DPHY_CHKN(phy));
> tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index cb93f6cf6d37..c6e87569b3d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2588,7 +2588,7 @@ static int intel_compute_max_dotclk(struct
> drm_i915_private *dev_priv)
> */
> void intel_update_max_cdclk(struct drm_i915_private *dev_priv)
> {
> - if (IS_ELKHARTLAKE(dev_priv)) {
> + if (IS_JSL_EHL(dev_priv)) {
> if (dev_priv->cdclk.hw.ref == 24000)
> dev_priv->max_cdclk_freq = 552000;
> else
> @@ -2815,7 +2815,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
> *dev_priv)
> dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
> dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
> dev_priv->cdclk.table = icl_cdclk_table;
> - } else if (IS_ELKHARTLAKE(dev_priv)) {
> + } else if (IS_JSL_EHL(dev_priv)) {
> dev_priv->display.set_cdclk = bxt_set_cdclk;
> dev_priv->display.bw_calc_min_cdclk = skl_bw_calc_min_cdclk;
> dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index 157d8c8c605a..d59ceaa2916a 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -188,7 +188,7 @@ static bool has_phy_misc(struct drm_i915_private *i915,
> enum phy phy)
>* PHY-B and may not even have instances of the register for the
>* other combo PHY's.
>*/
> - if (IS_ELKHARTLAKE(i915) ||
> + if (IS_JSL_EHL(i915) ||
> IS_ROCKETLAKE(i915))
> return phy < PHY_C;
>
> @@ -282,7 +282,7 @@ static bool icl_combo_phy_verify_state(struct
> drm_i915_private *dev_priv,
Re: [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value
On Mon, 2020-10-12 at 22:02 +, Vivi, Rodrigo wrote:
> > On Oct 12, 2020, at 2:47 PM, Lyude Paul wrote:
> >
> > Just pushed this, but it's not in drm-tip because it would seem that
> > rebuilding
> > drm-tip has failed, and the conflict doesn't appear to be from any of the
> > patches I pushed so I'm getting the feeling from the DRM maintainer docs I
> > should probably let one of the drm-misc-folks handle the conflict.
>
> conflicts solved. feel free to push now.
Thank you!
>
> For the drm-misc I simply went with the drm-misc-next solution and for the
> drm-intel
> I went with the drm-intel-next-queued one.
>
> > On Mon, 2020-10-12 at 13:50 -0400, Sean Paul wrote:
> > > On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul wrote:
> > > > On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> > > > > On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
> > > > > > So if I understand this correctly, it sounds like that some
> > > > > > Pixelbooks
> > > > > > boot up
> > > > > > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value,
> > > > > > without
> > > > > > the
> > > > > > panel actually having DPCD backlight controls enabled?
> > > > >
> > > > > It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
> > > > > backlight.enabled = false. By changing backlight.level = max,
> > > > > backlight.enabled is now set to true. This results in losing backlight
> > > > > control on boot (since the enable routine is no longer invoked).
> > > > >
> > > > Ahhh ok, I'm fine with that - review still stands :)
> > >
> > > Pinging intel maintainers, could someone please apply this?
> > >
> > >
> > > Sean
> > >
> > > > > Sean
> > > > >
> > > > > > If I'm understanding that correctly, then this patch looks good to
> > > > > > me:
> > > > > >
> > > > > > Reviewed-by: Lyude Paul
> > > > > >
> > > > > > On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > > > > > > From: Sean Paul
> > > > > > >
> > > > > > > In commit 79946723092b ("drm/i915: Assume 100% brightness when not
> > > > > > > in
> > > > > > > DPCD control mode"), we fixed the brightness level when DPCD
> > > > > > > control
> > > > > > > was
> > > > > > > not active to max brightness. This is as good as we can guess
> > > > > > > since
> > > > > > > most
> > > > > > > backlights go on full when uncontrolled.
> > > > > > >
> > > > > > > However in doing so we changed the semantics of the initial
> > > > > > > 'backlight.enabled' value. At least on Pixelbooks, they were
> > > > > > > relying
> > > > > > > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0
> > > > > > > on
> > > > > > > boot such that enabled would be false. This causes the device to
> > > > > > > be
> > > > > > > enabled when the brightness is set. Without this, brightness
> > > > > > > control
> > > > > > > doesn't work. So by changing brightness to max, we also flipped
> > > > > > > enabled
> > > > > > > to be true on boot.
> > > > > > >
> > > > > > > To fix this, make enabled a function of brightness and backlight
> > > > > > > control
> > > > > > > mechanism.
> > > > > > >
> > > > > > > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > > > > > DPCD
> > > > > > > control mode")
> > > > > > > Cc: Lyude Paul
> > > > > > > Cc: Jani Nikula
> > > > > > > Cc: Juha-Pekka Heikkila
> > > > > > > Cc: "Ville Syrjälä"
> > > > > > > Cc: Rodrigo Vivi
> > > > > > > Cc: Kevin Chowski >
> > > > > > > Signed-off-by: Sean Paul
> > > > > > > ---
> > > > > > > .../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
> > > > > > > -
> > > > > > > ---
> > > > > > > 1 file changed, 20 insertions(+), 11 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > index acbd7eb66cbe..036f504ac7db 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > > > @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct
> > > > > > > intel_dp
> > > > > > > *intel_dp, bool enable)
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > -/*
> > > > > > > - * Read the current backlight value from DPCD register(s) based
> > > > > > > - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > > > > > - */
> > > > > > > -static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > > > > > *connector)
> > > > > > > +static bool intel_dp_aux_backlight_dpcd_mode(struct
> > > > > > > intel_connector
> > > > > > > *connector)
> > > > > > > {
> > > > > > > struct intel_dp *intel_dp = intel_attached_dp(connector);
> > > > > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > > > - u8 read_val[2] = { 0x0 };
> > > > > > > u8 mode_reg;
> > > > > > > - u16 level = 0;
> > > > > > >
> > > > > > > if (drm_dp_dpcd_readb(_dp->aux,
> > > > > >
Re: [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value
> On Oct 12, 2020, at 2:47 PM, Lyude Paul wrote:
>
> Just pushed this, but it's not in drm-tip because it would seem that
> rebuilding
> drm-tip has failed, and the conflict doesn't appear to be from any of the
> patches I pushed so I'm getting the feeling from the DRM maintainer docs I
> should probably let one of the drm-misc-folks handle the conflict.
conflicts solved. feel free to push now.
For the drm-misc I simply went with the drm-misc-next solution and for the
drm-intel
I went with the drm-intel-next-queued one.
>
> On Mon, 2020-10-12 at 13:50 -0400, Sean Paul wrote:
>> On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul wrote:
>>> On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
> So if I understand this correctly, it sounds like that some Pixelbooks
> boot up
> with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without
> the
> panel actually having DPCD backlight controls enabled?
It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
backlight.enabled = false. By changing backlight.level = max,
backlight.enabled is now set to true. This results in losing backlight
control on boot (since the enable routine is no longer invoked).
>>> Ahhh ok, I'm fine with that - review still stands :)
>>
>> Pinging intel maintainers, could someone please apply this?
>>
>>
>> Sean
>>
Sean
> If I'm understanding that correctly, then this patch looks good to me:
>
> Reviewed-by: Lyude Paul
>
> On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
>> From: Sean Paul
>>
>> In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
>> DPCD control mode"), we fixed the brightness level when DPCD control
>> was
>> not active to max brightness. This is as good as we can guess since
>> most
>> backlights go on full when uncontrolled.
>>
>> However in doing so we changed the semantics of the initial
>> 'backlight.enabled' value. At least on Pixelbooks, they were relying
>> on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
>> boot such that enabled would be false. This causes the device to be
>> enabled when the brightness is set. Without this, brightness control
>> doesn't work. So by changing brightness to max, we also flipped
>> enabled
>> to be true on boot.
>>
>> To fix this, make enabled a function of brightness and backlight
>> control
>> mechanism.
>>
>> Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in
>> DPCD
>> control mode")
>> Cc: Lyude Paul
>> Cc: Jani Nikula
>> Cc: Juha-Pekka Heikkila
>> Cc: "Ville Syrjälä"
>> Cc: Rodrigo Vivi
>> Cc: Kevin Chowski >
>> Signed-off-by: Sean Paul
>> ---
>> .../drm/i915/display/intel_dp_aux_backlight.c | 31
>> ---
>> 1 file changed, 20 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> index acbd7eb66cbe..036f504ac7db 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
>> @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct
>> intel_dp
>> *intel_dp, bool enable)
>> }
>> }
>>
>> -/*
>> - * Read the current backlight value from DPCD register(s) based
>> - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
>> - */
>> -static u32 intel_dp_aux_get_backlight(struct intel_connector
>> *connector)
>> +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
>> *connector)
>> {
>> struct intel_dp *intel_dp = intel_attached_dp(connector);
>> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> - u8 read_val[2] = { 0x0 };
>> u8 mode_reg;
>> - u16 level = 0;
>>
>> if (drm_dp_dpcd_readb(_dp->aux,
>>DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
>> @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
>> intel_connector *connector)
>> drm_dbg_kms(>drm,
>> "Failed to read the DPCD register 0x%x\n",
>> DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
>> - return 0;
>> + return false;
>> }
>>
>> + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
>> +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
>> +}
>> +
>> +/*
>> + * Read the current backlight value from DPCD register(s) based
>> + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
>> + */
>> +static u32 intel_dp_aux_get_backlight(struct intel_connector
>> *connector)
Re: [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value
Just pushed this, but it's not in drm-tip because it would seem that rebuilding
drm-tip has failed, and the conflict doesn't appear to be from any of the
patches I pushed so I'm getting the feeling from the DRM maintainer docs I
should probably let one of the drm-misc-folks handle the conflict.
On Mon, 2020-10-12 at 13:50 -0400, Sean Paul wrote:
> On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul wrote:
> > On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> > > On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
> > > > So if I understand this correctly, it sounds like that some Pixelbooks
> > > > boot up
> > > > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without
> > > > the
> > > > panel actually having DPCD backlight controls enabled?
> > >
> > > It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
> > > backlight.enabled = false. By changing backlight.level = max,
> > > backlight.enabled is now set to true. This results in losing backlight
> > > control on boot (since the enable routine is no longer invoked).
> > >
> > Ahhh ok, I'm fine with that - review still stands :)
>
> Pinging intel maintainers, could someone please apply this?
>
>
> Sean
>
> > > Sean
> > >
> > > > If I'm understanding that correctly, then this patch looks good to me:
> > > >
> > > > Reviewed-by: Lyude Paul
> > > >
> > > > On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > > > > From: Sean Paul
> > > > >
> > > > > In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > > > DPCD control mode"), we fixed the brightness level when DPCD control
> > > > > was
> > > > > not active to max brightness. This is as good as we can guess since
> > > > > most
> > > > > backlights go on full when uncontrolled.
> > > > >
> > > > > However in doing so we changed the semantics of the initial
> > > > > 'backlight.enabled' value. At least on Pixelbooks, they were relying
> > > > > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> > > > > boot such that enabled would be false. This causes the device to be
> > > > > enabled when the brightness is set. Without this, brightness control
> > > > > doesn't work. So by changing brightness to max, we also flipped
> > > > > enabled
> > > > > to be true on boot.
> > > > >
> > > > > To fix this, make enabled a function of brightness and backlight
> > > > > control
> > > > > mechanism.
> > > > >
> > > > > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > > > DPCD
> > > > > control mode")
> > > > > Cc: Lyude Paul
> > > > > Cc: Jani Nikula
> > > > > Cc: Juha-Pekka Heikkila
> > > > > Cc: "Ville Syrjälä"
> > > > > Cc: Rodrigo Vivi
> > > > > Cc: Kevin Chowski >
> > > > > Signed-off-by: Sean Paul
> > > > > ---
> > > > > .../drm/i915/display/intel_dp_aux_backlight.c | 31
> > > > > ---
> > > > > 1 file changed, 20 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > index acbd7eb66cbe..036f504ac7db 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct
> > > > > intel_dp
> > > > > *intel_dp, bool enable)
> > > > > }
> > > > > }
> > > > >
> > > > > -/*
> > > > > - * Read the current backlight value from DPCD register(s) based
> > > > > - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > > > - */
> > > > > -static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > > > *connector)
> > > > > +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> > > > > *connector)
> > > > > {
> > > > > struct intel_dp *intel_dp = intel_attached_dp(connector);
> > > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > - u8 read_val[2] = { 0x0 };
> > > > > u8 mode_reg;
> > > > > - u16 level = 0;
> > > > >
> > > > > if (drm_dp_dpcd_readb(_dp->aux,
> > > > > DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> > > > > @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
> > > > > intel_connector *connector)
> > > > > drm_dbg_kms(>drm,
> > > > > "Failed to read the DPCD register 0x%x\n",
> > > > > DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> > > > > - return 0;
> > > > > + return false;
> > > > > }
> > > > >
> > > > > + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> > > > > +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> > > > > +}
> > > > > +
> > > > > +/*
> > > > > + * Read the current backlight value from DPCD register(s) based
> > > > > + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > > > + */
> > > > > +static u32
Re: [PATCH] drm/nouveau/kms: Fix NULL pointer dereference in nouveau_connector_detect_depth
Hi! Thanks for the catch, just one comment down below On Fri, 2020-10-09 at 21:11 +0300, Alexander Kapshuk wrote: > This oops manifests itself on the following hardware: > 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce G 103M] > (rev a1) > > Oct 09 14:17:46 lp-sasha kernel: BUG: kernel NULL pointer dereference, > address: > Oct 09 14:17:46 lp-sasha kernel: #PF: supervisor read access in kernel mode > Oct 09 14:17:46 lp-sasha kernel: #PF: error_code(0x) - not-present page > Oct 09 14:17:46 lp-sasha kernel: PGD 0 P4D 0 > Oct 09 14:17:46 lp-sasha kernel: Oops: [#1] SMP PTI > Oct 09 14:17:46 lp-sasha kernel: CPU: 1 PID: 191 Comm: systemd-udevd Not > tainted 5.9.0-rc8-next-20201009 #38 > Oct 09 14:17:46 lp-sasha kernel: Hardware name: Hewlett-Packard Compaq > Presario CQ61 Notebook PC/306A, BIOS F.03 03/23/2009 > Oct 09 14:17:46 lp-sasha kernel: RIP: > 0010:nouveau_connector_detect_depth+0x71/0xc0 [nouveau] > Oct 09 14:17:46 lp-sasha kernel: Code: 0a 00 00 48 8b 49 48 c7 87 b8 00 00 00 > 06 00 00 00 80 b9 4d 0a 00 00 00 75 1e 83 fa 41 75 05 48 85 c0 75 29 8b 81 10 > 0d 00 00 <39> 06 7c 25 f6 81 14 0d 00 00 02 75 b7 c3 80 b9 0c 0d 00 00 00 75 > Oct 09 14:17:46 lp-sasha kernel: RSP: 0018:c928f8c0 EFLAGS: 00010297 > Oct 09 14:17:46 lp-sasha kernel: RAX: 00014c08 RBX: 8880369d4000 > RCX: 8880369d3000 > Oct 09 14:17:46 lp-sasha kernel: RDX: 0040 RSI: > RDI: 8880369d4000 > Oct 09 14:17:46 lp-sasha kernel: RBP: 88800601cc00 R08: 8880051da298 > R09: 8226201a > Oct 09 14:17:46 lp-sasha kernel: R10: 88800469aa80 R11: 888004c84ff8 > R12: > Oct 09 14:17:46 lp-sasha kernel: R13: 8880051da000 R14: 2000 > R15: 0003 > Oct 09 14:17:46 lp-sasha kernel: FS: 7fd0192b3440() > GS:8880bc90() knlGS: > Oct 09 14:17:46 lp-sasha kernel: CS: 0010 DS: ES: CR0: > 80050033 > Oct 09 14:17:46 lp-sasha kernel: CR2: CR3: 04976000 > CR4: 06e0 > Oct 09 14:17:46 lp-sasha kernel: Call Trace: > Oct 09 14:17:46 lp-sasha kernel: nouveau_connector_get_modes+0x1e6/0x240 > [nouveau] > Oct 09 14:17:46 lp-sasha kernel: ? kfree+0xb9/0x240 > Oct 09 14:17:46 lp-sasha kernel: ? drm_connector_list_iter_next+0x7c/0xa0 > Oct 09 14:17:46 lp-sasha > kernel: drm_helper_probe_single_connector_modes+0x1ba/0x7c0 > Oct 09 14:17:46 lp-sasha kernel: drm_client_modeset_probe+0x27e/0x1360 > Oct 09 14:17:46 lp-sasha kernel: ? nvif_object_sclass_put+0xc/0x20 [nouveau] > Oct 09 14:17:46 lp-sasha kernel: ? nouveau_cli_init+0x3cc/0x440 [nouveau] > Oct 09 14:17:46 lp-sasha kernel: ? ktime_get_mono_fast_ns+0x49/0xa0 > Oct 09 14:17:46 lp-sasha kernel: ? nouveau_drm_open+0x4e/0x180 [nouveau] > Oct 09 14:17:46 lp-sasha > kernel: __drm_fb_helper_initial_config_and_unlock+0x3f/0x4a0 > Oct 09 14:17:46 lp-sasha kernel: ? drm_file_alloc+0x18f/0x260 > Oct 09 14:17:46 lp-sasha kernel: ? mutex_lock+0x9/0x40 > Oct 09 14:17:46 lp-sasha kernel: ? drm_client_init+0x110/0x160 > Oct 09 14:17:46 lp-sasha kernel: nouveau_fbcon_init+0x14d/0x1c0 [nouveau] > Oct 09 14:17:46 lp-sasha kernel: nouveau_drm_device_init+0x1c0/0x880 > [nouveau] > Oct 09 14:17:46 lp-sasha kernel: nouveau_drm_probe+0x11a/0x1e0 [nouveau] > Oct 09 14:17:46 lp-sasha kernel: pci_device_probe+0xcd/0x140 > Oct 09 14:17:46 lp-sasha kernel: really_probe+0xd8/0x400 > Oct 09 14:17:46 lp-sasha kernel: driver_probe_device+0x4a/0xa0 > Oct 09 14:17:46 lp-sasha kernel: device_driver_attach+0x9c/0xc0 > Oct 09 14:17:46 lp-sasha kernel: __driver_attach+0x6f/0x100 > Oct 09 14:17:46 lp-sasha kernel: ? device_driver_attach+0xc0/0xc0 > Oct 09 14:17:46 lp-sasha kernel: bus_for_each_dev+0x75/0xc0 > Oct 09 14:17:46 lp-sasha kernel: bus_add_driver+0x106/0x1c0 > Oct 09 14:17:46 lp-sasha kernel: driver_register+0x86/0xe0 > Oct 09 14:17:46 lp-sasha kernel: ? 0xa044e000 > Oct 09 14:17:46 lp-sasha kernel: do_one_initcall+0x48/0x1e0 > Oct 09 14:17:46 lp-sasha kernel: ? _cond_resched+0x11/0x60 > Oct 09 14:17:46 lp-sasha kernel: ? kmem_cache_alloc_trace+0x19c/0x1e0 > Oct 09 14:17:46 lp-sasha kernel: do_init_module+0x57/0x220 > Oct 09 14:17:46 lp-sasha kernel: __do_sys_finit_module+0xa0/0xe0 > Oct 09 14:17:46 lp-sasha kernel: do_syscall_64+0x33/0x40 > Oct 09 14:17:46 lp-sasha kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 > Oct 09 14:17:46 lp-sasha kernel: RIP: 0033:0x7fd01a060d5d > Oct 09 14:17:46 lp-sasha kernel: Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 > f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 > 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 70 0c 00 f7 d8 64 89 01 48 > Oct 09 14:17:46 lp-sasha kernel: RSP: 002b:7ffc8ad38a98 EFLAGS: 0246 > ORIG_RAX: 0139 > Oct 09 14:17:46 lp-sasha kernel: RAX: ffda RBX: 563f6e7fd530 > RCX: 7fd01a060d5d > Oct 09 14:17:46 lp-sasha kernel:
[PATCH] drm/amdgpu: fix semicolon.cocci warnings
From: kernel test robot
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:608:2-3: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
Fixes: b4a7db71ea06 ("drm/amdgpu: add per device user friendly xgmi events for
vega20")
CC: Jonathan Kim
Signed-off-by: kernel test robot
---
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: 02c3d98ce25b3e4f0b8e830be054c8f4f7f944c1
commit: b4a7db71ea060218529e6a4c660c37687ecb5669 [286/376] drm/amdgpu: add per
device user friendly xgmi events for vega20
amdgpu_pmu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c
@@ -605,7 +605,7 @@ int amdgpu_pmu_init(struct amdgpu_device
break;
default:
return 0;
- };
+ }
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next 286/376] drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:608:2-3: Unneeded semicolon
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next head: 02c3d98ce25b3e4f0b8e830be054c8f4f7f944c1 commit: b4a7db71ea060218529e6a4c660c37687ecb5669 [286/376] drm/amdgpu: add per device user friendly xgmi events for vega20 config: x86_64-randconfig-c002-20201012 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "coccinelle warnings: (new ones prefixed by >>)" >> drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c:608:2-3: Unneeded semicolon Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote: > On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote: > > kmap_atomic() is always preferred over kmap()/kmap_thread(). > > kmap_atomic() is _much_ more lightweight since its TLB invalidation is > > always CPU-local and never broadcast. > > > > So, basically, unless you *must* sleep while the mapping is in place, > > kmap_atomic() is preferred. > > But kmap_atomic() disables preemption, so the _ideal_ interface would map > it only locally, then on preemption make it global. I don't even know > if that _can_ be done. But this email makes it seem like kmap_atomic() > has no downsides. And that is IIUC what Thomas was trying to solve. Also, Linus brought up that kmap_atomic() has quirks in nesting.[1] >From what I can see all of these discussions support the need to have something between kmap() and kmap_atomic(). However, the reason behind converting call sites to kmap_thread() are different between Thomas' patch set and mine. Both require more kmap granularity. However, they do so with different reasons and underlying implementations but with the _same_ resulting semantics; a thread local mapping which is preemptable.[2] Therefore they each focus on changing different call sites. While this patch set is huge I think it serves a valuable purpose to identify a large number of call sites which are candidates for this new semantic. Ira [1] https://lore.kernel.org/lkml/CAHk-=wgbmwsTOKs23Z=71ebtruloeah2u3tnqt2athewvkb...@mail.gmail.com/ [2] It is important to note these implementations are not incompatible with each other. So I don't see yet another 'kmap_something()' being required. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 4/5] drm/i915/display: Add Nearest-neighbor based integer scaling support
Integer scaling (IS) is a nearest-neighbor upscaling technique that
simply scales up the existing pixels by an integer
(i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
works by filling in the missing color values in the upscaled image
with that of the coordinate-mapped nearest source pixel value.
Both IS and NN preserve the clarity of the original image. Integer
scaling is particularly useful for pixel art games that rely on
sharp, blocky images to deliver their distinctive look.
Introduce functions to configure the scaler filter coefficients to
enable nearest-neighbor filtering.
Bspec: 49247
changes since v4:
* Make cnl_coef_tap(), cnl_nearest_filter_coef() inline (Uma)
changes since v3:
* None
changes since v2:
* Move APIs from 5/5 into this patch.
* Change filter programming related function names to cnl_*, move
filter select bits related code into inline function (Ville)
changes since v1:
* Rearrange skl_scaler_setup_nearest_neighbor_filter() to iterate the
registers directly instead of the phases and taps (Ville)
changes since RFC:
* Refine the skl_scaler_setup_nearest_neighbor_filter() logic (Ville)
Reviewed-by: Uma Shankar
Signed-off-by: Shashank Sharma
Signed-off-by: Ankit Nautiyal
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/display/intel_display.c | 99
drivers/gpu/drm/i915/display/intel_display.h | 4 +
2 files changed, 103 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index cf1417ff54d7..871a1f44a2bd 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6285,6 +6285,105 @@ void skl_scaler_disable(const struct intel_crtc_state
*old_crtc_state)
skl_detach_scaler(crtc, i);
}
+static inline int cnl_coef_tap(int i)
+{
+ return i % 7;
+}
+
+static inline u16 cnl_nearest_filter_coef(int t)
+{
+ return t == 3 ? 0x0800 : 0x3000;
+}
+
+/**
+ * Theory behind setting nearest-neighbor integer scaling:
+ *
+ * 17 phase of 7 taps requires 119 coefficients in 60 dwords per set.
+ * The letter represents the filter tap (D is the center tap) and the number
+ * represents the coefficient set for a phase (0-16).
+ *
+ * ++++
+ * |Index value | Data value coeffient 1 | Data value coeffient 2 |
+ * ++++
+ * | 00h | B0| A0|
+ * ++++
+ * | 01h | D0| C0|
+ * ++++
+ * | 02h | F0| E0|
+ * ++++
+ * | 03h | A1| G0|
+ * ++++
+ * | 04h | C1| B1|
+ * ++++
+ * | ... | ... | ... |
+ * ++++
+ * | 38h | B16 | A16 |
+ * ++++
+ * | 39h | D16 | C16 |
+ * ++++
+ * | 3Ah | F16 | C16 |
+ * ++++
+ * | 3Bh |Reserved| G16 |
+ * ++++
+ *
+ * To enable nearest-neighbor scaling: program scaler coefficents with
+ * the center tap (Dxx) values set to 1 and all other values set to 0 as per
+ * SCALER_COEFFICIENT_FORMAT
+ *
+ */
+
+static void cnl_program_nearest_filter_coefs(struct drm_i915_private *dev_priv,
+enum pipe pipe, int id, int set)
+{
+ int i;
+
+ intel_de_write_fw(dev_priv, CNL_PS_COEF_INDEX_SET(pipe, id, set),
+ PS_COEE_INDEX_AUTO_INC);
+
+ for (i = 0; i < 17 * 7; i += 2) {
+ u32 tmp;
+ int t;
+
+ t = cnl_coef_tap(i);
+ tmp = cnl_nearest_filter_coef(t);
+
+ t = cnl_coef_tap(i + 1);
+ tmp |= cnl_nearest_filter_coef(t) << 16;
+
+ intel_de_write_fw(dev_priv, CNL_PS_COEF_DATA_SET(pipe, id, set),
+ tmp);
+ }
+
+
[PATCH v6 5/5] drm/i915: Enable scaling filter for plane and CRTC
GEN >= 10 hardware supports the programmable scaler filter.
Attach scaling filter property for CRTC and plane for GEN >= 10
hardwares and program scaler filter based on the selected filter
type.
changes since v3:
* None
changes since v2:
* Use updated functions
* Add ps_ctrl var to contain the full PS_CTRL register value (Ville)
* Duplicate the scaling filter in crtc and plane hw state (Ville)
changes since v1:
* None
Changes since RFC:
* Enable properties for GEN >= 10 platforms (Ville)
* Do not round off the crtc co-ordinate (Danial Stone, Ville)
* Add new functions to handle scaling filter setup (Ville)
* Remove coefficient set 0 hardcoding.
Reviewed-by: Uma Shankar
Signed-off-by: Shashank Sharma
Signed-off-by: Ankit Nautiyal
Signed-off-by: Pankaj Bharadiya
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 18 --
.../gpu/drm/i915/display/intel_display_types.h | 2 ++
drivers/gpu/drm/i915/display/intel_sprite.c| 15 +--
4 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 6bd8e6cdd477..3334ff253600 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -262,6 +262,7 @@ void intel_plane_copy_uapi_to_hw_state(struct
intel_plane_state *plane_state,
plane_state->hw.rotation = from_plane_state->uapi.rotation;
plane_state->hw.color_encoding = from_plane_state->uapi.color_encoding;
plane_state->hw.color_range = from_plane_state->uapi.color_range;
+ plane_state->hw.scaling_filter = from_plane_state->uapi.scaling_filter;
}
void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 871a1f44a2bd..0b2c462d6dfd 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6404,6 +6404,7 @@ static void skl_pfit_enable(const struct intel_crtc_state
*crtc_state)
int hscale, vscale;
unsigned long irqflags;
int id;
+ u32 ps_ctrl;
if (!crtc_state->pch_pfit.enabled)
return;
@@ -6420,10 +6421,16 @@ static void skl_pfit_enable(const struct
intel_crtc_state *crtc_state)
id = scaler_state->scaler_id;
+ ps_ctrl = skl_scaler_get_filter_select(crtc_state->hw.scaling_filter,
0);
+ ps_ctrl |= PS_SCALER_EN | scaler_state->scalers[id].mode;
+
spin_lock_irqsave(_priv->uncore.lock, irqflags);
- intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), PS_SCALER_EN |
- PS_FILTER_MEDIUM | scaler_state->scalers[id].mode);
+ skl_scaler_setup_filter(dev_priv, pipe, id, 0,
+ crtc_state->hw.scaling_filter);
+
+ intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), ps_ctrl);
+
intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, id),
PS_Y_PHASE(0) | PS_UV_RGB_PHASE(uv_rgb_vphase));
intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id),
@@ -13457,6 +13464,7 @@ intel_crtc_copy_uapi_to_hw_state(struct
intel_crtc_state *crtc_state)
crtc_state->hw.active = crtc_state->uapi.active;
crtc_state->hw.mode = crtc_state->uapi.mode;
crtc_state->hw.adjusted_mode = crtc_state->uapi.adjusted_mode;
+ crtc_state->hw.scaling_filter = crtc_state->uapi.scaling_filter;
intel_crtc_copy_uapi_to_hw_state_nomodeset(crtc_state);
}
@@ -13468,6 +13476,7 @@ static void intel_crtc_copy_hw_to_uapi_state(struct
intel_crtc_state *crtc_state
drm_atomic_set_mode_for_crtc(_state->uapi,
_state->hw.mode) < 0);
crtc_state->uapi.adjusted_mode = crtc_state->hw.adjusted_mode;
+ crtc_state->uapi.scaling_filter = crtc_state->hw.scaling_filter;
/* copy color blobs to uapi */
drm_property_replace_blob(_state->uapi.degamma_lut,
@@ -17062,6 +17071,11 @@ static int intel_crtc_init(struct drm_i915_private
*dev_priv, enum pipe pipe)
dev_priv->plane_to_crtc_mapping[i9xx_plane] = crtc;
}
+ if (INTEL_GEN(dev_priv) >= 10)
+ drm_crtc_create_scaling_filter_property(>base,
+ BIT(DRM_SCALING_FILTER_DEFAULT)
|
+
BIT(DRM_SCALING_FILTER_NEAREST_NEIGHBOR));
+
intel_color_init(crtc);
intel_crtc_crc_init(crtc);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b6b1ecfca652..cc63d549185b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -535,6 +535,7 @@ struct intel_plane_state {
unsigned int rotation;
enum
[PATCH v6 2/5] drm/drm-kms.rst: Add plane and CRTC scaling filter property documentation
Add documentation for newly introduced KMS plane and CRTC scaling filter properties. changes since v3: * None changes since v1: * None changes since RFC: * Add separate documentation for plane and CRTC. Reviewed-by: Uma Shankar Signed-off-by: Pankaj Bharadiya --- Documentation/gpu/drm-kms.rst | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 3c5ae4f6dfd2..8e4031afbb1b 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -518,6 +518,18 @@ Variable Refresh Properties .. kernel-doc:: drivers/gpu/drm/drm_connector.c :doc: Variable refresh properties +Plane Scaling Filter Property +--- + +.. kernel-doc:: drivers/gpu/drm/drm_plane.c + :doc: Plane scaling filter property + +CRTC Scaling Filter Property +--- + +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c + :doc: CRTC scaling filter property + Existing KMS Properties --- -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/5] drm/i915: Introduce scaling filter related registers and bit fields
Introduce scaler registers and bit fields needed to configure the
scaling filter in prgrammed mode and configure scaling filter
coefficients.
changes since v3:
* None
changes since v2:
* Change macro names to CNL_* and use +(set)*8 instead of adding
another trip through _PICK_EVEN (Ville).
changes since v1:
* None
changes since RFC:
* Parametrize scaler coeffient macros by 'set' (Ville)
Reviewed-by: Uma Shankar
Signed-off-by: Shashank Sharma
Signed-off-by: Ankit Nautiyal
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_reg.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 04c966a524ce..5819dc39d227 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7380,6 +7380,7 @@ enum {
#define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
#define PS_FILTER_MASK (3 << 23)
#define PS_FILTER_MEDIUM (0 << 23)
+#define PS_FILTER_PROGRAMMED (1 << 23)
#define PS_FILTER_EDGE_ENHANCE (2 << 23)
#define PS_FILTER_BILINEAR (3 << 23)
#define PS_VERT3TAP(1 << 21)
@@ -7394,6 +7395,10 @@ enum {
#define PS_VADAPT_MODE_MOST_ADAPT (3 << 5)
#define PS_PLANE_Y_SEL_MASK (7 << 5)
#define PS_PLANE_Y_SEL(plane) (((plane) + 1) << 5)
+#define PS_Y_VERT_FILTER_SELECT(set) ((set) << 4)
+#define PS_Y_HORZ_FILTER_SELECT(set) ((set) << 3)
+#define PS_UV_VERT_FILTER_SELECT(set) ((set) << 2)
+#define PS_UV_HORZ_FILTER_SELECT(set) ((set) << 1)
#define _PS_PWR_GATE_1A 0x68160
#define _PS_PWR_GATE_2A 0x68260
@@ -7456,6 +7461,17 @@ enum {
#define _PS_ECC_STAT_2B 0x68AD0
#define _PS_ECC_STAT_1C 0x691D0
+#define _PS_COEF_SET0_INDEX_1A0x68198
+#define _PS_COEF_SET0_INDEX_2A0x68298
+#define _PS_COEF_SET0_INDEX_1B0x68998
+#define _PS_COEF_SET0_INDEX_2B0x68A98
+#define PS_COEE_INDEX_AUTO_INC(1 << 10)
+
+#define _PS_COEF_SET0_DATA_1A 0x6819C
+#define _PS_COEF_SET0_DATA_2A 0x6829C
+#define _PS_COEF_SET0_DATA_1B 0x6899C
+#define _PS_COEF_SET0_DATA_2B 0x68A9C
+
#define _ID(id, a, b) _PICK_EVEN(id, a, b)
#define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\
_ID(id, _PS_1A_CTRL, _PS_2A_CTRL), \
@@ -7484,7 +7500,13 @@ enum {
#define SKL_PS_ECC_STAT(pipe, id) _MMIO_PIPE(pipe, \
_ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
_ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
+#define CNL_PS_COEF_INDEX_SET(pipe, id, set) _MMIO_PIPE(pipe,\
+ _ID(id, _PS_COEF_SET0_INDEX_1A, _PS_COEF_SET0_INDEX_2A)
+ (set) * 8, \
+ _ID(id, _PS_COEF_SET0_INDEX_1B, _PS_COEF_SET0_INDEX_2B)
+ (set) * 8)
+#define CNL_PS_COEF_DATA_SET(pipe, id, set) _MMIO_PIPE(pipe, \
+ _ID(id, _PS_COEF_SET0_DATA_1A, _PS_COEF_SET0_DATA_2A) +
(set) * 8, \
+ _ID(id, _PS_COEF_SET0_DATA_1B, _PS_COEF_SET0_DATA_2B) +
(set) * 8)
/* legacy palette */
#define _LGC_PALETTE_A 0x4a000
#define _LGC_PALETTE_B 0x4a800
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/5] drm: Introduce plane and CRTC scaling filter properties
Introduce per-plane and per-CRTC scaling filter properties to allow
userspace to select the driver's default scaling filter or
Nearest-neighbor(NN) filter for upscaling operations on CRTC and
plane.
Drivers can set up this property for a plane by calling
drm_plane_create_scaling_filter() and for a CRTC by calling
drm_crtc_create_scaling_filter().
NN filter works by filling in the missing color values in the upscaled
image with that of the coordinate-mapped nearest source pixel value.
NN filter for integer multiple scaling can be particularly useful for
for pixel art games that rely on sharp, blocky images to deliver their
distinctive look.
changes since v3:
* Refactor code, add new function for common code (Ville)
changes since v2:
* Create per-plane and per-CRTC scaling filter property (Ville)
changes since v1:
* None
changes since RFC:
* Add separate properties for plane and CRTC (Ville)
Reviewed-by: Uma Shankar
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/drm_atomic_uapi.c | 8 +++
drivers/gpu/drm/drm_crtc.c | 48 +++
drivers/gpu/drm/drm_crtc_internal.h | 3 +
drivers/gpu/drm/drm_plane.c | 90 +
include/drm/drm_crtc.h | 16 +
include/drm/drm_plane.h | 21 +++
6 files changed, 186 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 25c269bc4681..ef82009035e6 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return -EFAULT;
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+ } else if (property == crtc->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
} else {
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == crtc->scaling_filter_property)
+ *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
@@ -585,6 +589,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
sizeof(struct drm_rect),
);
return ret;
+ } else if (property == plane->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -643,6 +649,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
} else if (property == config->prop_fb_damage_clips) {
*val = (state->fb_damage_clips) ?
state->fb_damage_clips->base.id : 0;
+ } else if (property == plane->scaling_filter_property) {
+ *val = state->scaling_filter;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state,
property, val);
} else {
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index aecdd7ea26dc..d75536f820b5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -774,3 +774,51 @@ int drm_mode_crtc_set_obj_prop(struct drm_mode_object *obj,
return ret;
}
+
+/**
+ * DOC: CRTC scaling filter property
+ *
+ * SCALING_FILTER:
+ *
+ * Indicates scaling filter to be used for CRTC scaler
+ *
+ * The value of this property can be one of the following:
+ * Default:
+ * Driver's default scaling filter
+ * Nearest Neighbor:
+ * Nearest Neighbor scaling filter
+ *
+ * Drivers can set up this property for a CRTC by calling
+ * drm_crtc_create_scaling_filter_property
+ */
+
+/**
+ * drm_crtc_create_scaling_filter_property - create a new scaling filter
+ * property
+ *
+ * @crtc: drm CRTC
+ * @supported_filters: bitmask of supported scaling filters, must include
+ *BIT(DRM_SCALING_FILTER_DEFAULT).
+ *
+ * This function lets driver to enable the scaling filter property on a given
+ * CRTC.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
+ unsigned int supported_filters)
+{
+ struct drm_property *prop =
+ drm_create_scaling_filter_prop(crtc->dev, supported_filters);
+
+ if (IS_ERR(prop))
+ return PTR_ERR(prop);
+
+
[PATCH v6 0/5] Introduce drm scaling filter property
Earlier, I kept this series on hold since we wanted to have a reference userspace implementation in place. Now, Sameer has implemented Integer scaling in Kodi Retro gaming framework which demonstrate how Integer scaling gives distinctive look to pixel art games when played on higher resolution monitors. Kodi patches are reviewed and accepted for merge now. Here is the userspace patch series link: https://github.com/xbmc/xbmc/pull/18194 Background on Integer scaling: Integer scaling (IS) is a nearest-neighbor upscaling technique that simply scales up the existing pixels by an integer (i.e., whole number) multiplier. Nearest-neighbor (NN) interpolation works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest source pixel value. Both IS and NN preserve the clarity of the original image. In contrast, traditional upscaling algorithms, such as bilinear or bicubic interpolation, result in blurry upscaled images because they employ interpolation techniques that smooth out the transition from one pixel to another. Therefore, integer scaling is particularly useful for pixel art games that rely on sharp, blocky images to deliver their distinctive look. Many gaming communities have been asking for integer-mode scaling support, some links and background: https://software.intel.com/en-us/articles/integer-scaling-support-on-intel-graphics http://tanalin.com/en/articles/lossless-scaling/ https://community.amd.com/thread/209107 https://www.nvidia.com/en-us/geforce/forums/game-ready-drivers/13/1002/feature-request-nonblurry-upscaling-at-integer-rat/ * Changes in v6: - Rebase to latest drm-tip - Address review comments from Uma Pankaj Bharadiya (5): drm: Introduce plane and CRTC scaling filter properties drm/drm-kms.rst: Add plane and CRTC scaling filter property documentation drm/i915: Introduce scaling filter related registers and bit fields drm/i915/display: Add Nearest-neighbor based integer scaling support drm/i915: Enable scaling filter for plane and CRTC Documentation/gpu/drm-kms.rst | 12 ++ drivers/gpu/drm/drm_atomic_uapi.c | 8 ++ drivers/gpu/drm/drm_crtc.c| 48 +++ drivers/gpu/drm/drm_crtc_internal.h | 3 + drivers/gpu/drm/drm_plane.c | 90 ++ .../gpu/drm/i915/display/intel_atomic_plane.c | 1 + drivers/gpu/drm/i915/display/intel_display.c | 117 +- drivers/gpu/drm/i915/display/intel_display.h | 4 + .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_sprite.c | 15 ++- drivers/gpu/drm/i915/i915_reg.h | 22 include/drm/drm_crtc.h| 16 +++ include/drm/drm_plane.h | 21 13 files changed, 355 insertions(+), 4 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value
On Mon, 2020-10-12 at 13:50 -0400, Sean Paul wrote:
> On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul wrote:
> > On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> > > On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
> > > > So if I understand this correctly, it sounds like that some Pixelbooks
> > > > boot up
> > > > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without
> > > > the
> > > > panel actually having DPCD backlight controls enabled?
> > >
> > > It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
> > > backlight.enabled = false. By changing backlight.level = max,
> > > backlight.enabled is now set to true. This results in losing backlight
> > > control on boot (since the enable routine is no longer invoked).
> > >
> > Ahhh ok, I'm fine with that - review still stands :)
>
> Pinging intel maintainers, could someone please apply this?
oops, sorry about that. I can go ahead and push this
>
>
> Sean
>
> > > Sean
> > >
> > > > If I'm understanding that correctly, then this patch looks good to me:
> > > >
> > > > Reviewed-by: Lyude Paul
> > > >
> > > > On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > > > > From: Sean Paul
> > > > >
> > > > > In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > > > DPCD control mode"), we fixed the brightness level when DPCD control
> > > > > was
> > > > > not active to max brightness. This is as good as we can guess since
> > > > > most
> > > > > backlights go on full when uncontrolled.
> > > > >
> > > > > However in doing so we changed the semantics of the initial
> > > > > 'backlight.enabled' value. At least on Pixelbooks, they were relying
> > > > > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> > > > > boot such that enabled would be false. This causes the device to be
> > > > > enabled when the brightness is set. Without this, brightness control
> > > > > doesn't work. So by changing brightness to max, we also flipped
> > > > > enabled
> > > > > to be true on boot.
> > > > >
> > > > > To fix this, make enabled a function of brightness and backlight
> > > > > control
> > > > > mechanism.
> > > > >
> > > > > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > > > DPCD
> > > > > control mode")
> > > > > Cc: Lyude Paul
> > > > > Cc: Jani Nikula
> > > > > Cc: Juha-Pekka Heikkila
> > > > > Cc: "Ville Syrjälä"
> > > > > Cc: Rodrigo Vivi
> > > > > Cc: Kevin Chowski >
> > > > > Signed-off-by: Sean Paul
> > > > > ---
> > > > > .../drm/i915/display/intel_dp_aux_backlight.c | 31
> > > > > ---
> > > > > 1 file changed, 20 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > index acbd7eb66cbe..036f504ac7db 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > > @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct
> > > > > intel_dp
> > > > > *intel_dp, bool enable)
> > > > > }
> > > > > }
> > > > >
> > > > > -/*
> > > > > - * Read the current backlight value from DPCD register(s) based
> > > > > - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > > > - */
> > > > > -static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > > > *connector)
> > > > > +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> > > > > *connector)
> > > > > {
> > > > > struct intel_dp *intel_dp = intel_attached_dp(connector);
> > > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > - u8 read_val[2] = { 0x0 };
> > > > > u8 mode_reg;
> > > > > - u16 level = 0;
> > > > >
> > > > > if (drm_dp_dpcd_readb(_dp->aux,
> > > > > DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> > > > > @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
> > > > > intel_connector *connector)
> > > > > drm_dbg_kms(>drm,
> > > > > "Failed to read the DPCD register 0x%x\n",
> > > > > DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> > > > > - return 0;
> > > > > + return false;
> > > > > }
> > > > >
> > > > > + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> > > > > +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> > > > > +}
> > > > > +
> > > > > +/*
> > > > > + * Read the current backlight value from DPCD register(s) based
> > > > > + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > > > + */
> > > > > +static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > > > *connector)
> > > > > +{
> > > > > + struct intel_dp *intel_dp = intel_attached_dp(connector);
> > > > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > > + u8 read_val[2] = { 0x0 };
Re: [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value
On Tue, Sep 22, 2020 at 11:36 AM Lyude Paul wrote:
>
> On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> > On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
> > > So if I understand this correctly, it sounds like that some Pixelbooks
> > > boot up
> > > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
> > > panel actually having DPCD backlight controls enabled?
> >
> > It boots with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB == 0, which used to set
> > backlight.enabled = false. By changing backlight.level = max,
> > backlight.enabled is now set to true. This results in losing backlight
> > control on boot (since the enable routine is no longer invoked).
> >
> Ahhh ok, I'm fine with that - review still stands :)
Pinging intel maintainers, could someone please apply this?
Sean
>
> > Sean
> >
> > > If I'm understanding that correctly, then this patch looks good to me:
> > >
> > > Reviewed-by: Lyude Paul
> > >
> > > On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> > > > From: Sean Paul
> > > >
> > > > In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> > > > DPCD control mode"), we fixed the brightness level when DPCD control was
> > > > not active to max brightness. This is as good as we can guess since most
> > > > backlights go on full when uncontrolled.
> > > >
> > > > However in doing so we changed the semantics of the initial
> > > > 'backlight.enabled' value. At least on Pixelbooks, they were relying
> > > > on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> > > > boot such that enabled would be false. This causes the device to be
> > > > enabled when the brightness is set. Without this, brightness control
> > > > doesn't work. So by changing brightness to max, we also flipped enabled
> > > > to be true on boot.
> > > >
> > > > To fix this, make enabled a function of brightness and backlight control
> > > > mechanism.
> > > >
> > > > Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD
> > > > control mode")
> > > > Cc: Lyude Paul
> > > > Cc: Jani Nikula
> > > > Cc: Juha-Pekka Heikkila
> > > > Cc: "Ville Syrjälä"
> > > > Cc: Rodrigo Vivi
> > > > Cc: Kevin Chowski >
> > > > Signed-off-by: Sean Paul
> > > > ---
> > > > .../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
> > > > 1 file changed, 20 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > index acbd7eb66cbe..036f504ac7db 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct intel_dp
> > > > *intel_dp, bool enable)
> > > > }
> > > > }
> > > >
> > > > -/*
> > > > - * Read the current backlight value from DPCD register(s) based
> > > > - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > > - */
> > > > -static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > > *connector)
> > > > +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> > > > *connector)
> > > > {
> > > > struct intel_dp *intel_dp = intel_attached_dp(connector);
> > > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > - u8 read_val[2] = { 0x0 };
> > > > u8 mode_reg;
> > > > - u16 level = 0;
> > > >
> > > > if (drm_dp_dpcd_readb(_dp->aux,
> > > > DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> > > > @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
> > > > intel_connector *connector)
> > > > drm_dbg_kms(>drm,
> > > > "Failed to read the DPCD register 0x%x\n",
> > > > DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> > > > - return 0;
> > > > + return false;
> > > > }
> > > >
> > > > + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> > > > +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> > > > +}
> > > > +
> > > > +/*
> > > > + * Read the current backlight value from DPCD register(s) based
> > > > + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> > > > + */
> > > > +static u32 intel_dp_aux_get_backlight(struct intel_connector
> > > > *connector)
> > > > +{
> > > > + struct intel_dp *intel_dp = intel_attached_dp(connector);
> > > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > > + u8 read_val[2] = { 0x0 };
> > > > + u16 level = 0;
> > > > +
> > > > /*
> > > >* If we're not in DPCD control mode yet, the programmed
> > > > brightness
> > > >* value is meaningless and we should assume max brightness
> > > >*/
> > > > - if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
> > > > - DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
> > > > + if
Re: [2/2] drm/msm: Add support for GPU cooling
On Mon, Oct 12, 2020 at 07:03:51PM +0530, Akhil P Oommen wrote:
> On 10/10/2020 12:06 AM, m...@chromium.org wrote:
> > Hi Akhil,
> >
> > On Thu, Oct 08, 2020 at 10:39:07PM +0530, Akhil P Oommen wrote:
> > > Register GPU as a devfreq cooling device so that it can be passively
> > > cooled by the thermal framework.
> > >
> > > Signed-off-by: Akhil P Oommen
> > > ---
> > > drivers/gpu/drm/msm/msm_gpu.c | 13 -
> > > drivers/gpu/drm/msm/msm_gpu.h | 2 ++
> > > 2 files changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> > > index 55d1648..93ffd66 100644
> > > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > > @@ -14,6 +14,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > @@ -107,9 +108,18 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
> > > if (IS_ERR(gpu->devfreq.devfreq)) {
> > > DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
> > > devfreq\n");
> > > gpu->devfreq.devfreq = NULL;
> > > + return;
> > > }
> > > devfreq_suspend_device(gpu->devfreq.devfreq);
> > > +
> > > + gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
> > > + gpu->devfreq.devfreq);
> > > + if (IS_ERR(gpu->cooling)) {
> > > + DRM_DEV_ERROR(>pdev->dev,
> > > + "Couldn't register GPU cooling device\n");
> > > + gpu->cooling = NULL;
> > > + }
> > > }
> > > static int enable_pwrrail(struct msm_gpu *gpu)
> > > @@ -926,7 +936,6 @@ int msm_gpu_init(struct drm_device *drm, struct
> > > platform_device *pdev,
> > > msm_devfreq_init(gpu);
> > > -
> > > gpu->aspace = gpu->funcs->create_address_space(gpu, pdev);
> > > if (gpu->aspace == NULL)
> > > @@ -1005,4 +1014,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
> > > gpu->aspace->mmu->funcs->detach(gpu->aspace->mmu);
> > > msm_gem_address_space_put(gpu->aspace);
> > > }
> > > +
> > > + devfreq_cooling_unregister(gpu->cooling);
> >
> > Resources should be released in reverse order, otherwise the cooling device
> > could use resources that have already been freed.
> > Why do you think this is not the correct order? If you are thinking
> about devfreq struct, it is managed device resource.
I did not check specifically if changing the frequency really uses any of the
resources that are released previously, In any case it's not a good idea to
allow other parts of the kernel to use a half initialized/torn down device.
Even if it isn't a problem today someone could change the driver to use any
of these resources (or add a new one) in a frequency change, without even
thinking about the cooling device, just (rightfully) asuming that things are
set up and torn down in a sane order.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/fourcc: Add AXBXGXRX106106106106 format
v3 includes the Signed-off-by and Acked-by lines in the commit. No
other changes.
At this point, I'd need some help from a maintainer/committer to merge
this, I understand.
Daniel Vetter, are you happy to do this or does this work differently?
Many thanks,
Matteo
On Mon, Oct 12, 2020 at 05:40:43PM +0100, Matteo Franchin wrote:
> Add ABGR format with 10-bit components packed in 64-bit per pixel.
> This format can be used to handle
> VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
> architectures.
>
> Signed-off-by: Matteo Franchin
> Reviewed-by: Brian Starkey
> Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fourcc.c | 1 +
> include/uapi/drm/drm_fourcc.h | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 722c7ebe4e88..03262472059c 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -202,6 +202,7 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_XBGR16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
> { .format = DRM_FORMAT_ARGB16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_ABGR16161616F, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> + { .format = DRM_FORMAT_AXBXGXRX106106106106, .depth = 0,
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_RGB888_A8, .depth = 32,
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_BGR888_A8, .depth = 32,
> .num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> { .format = DRM_FORMAT_XRGB_A8, .depth = 32,
> .num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true
> },
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 6f0628eb13a6..d720f1e8ae5e 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -179,6 +179,12 @@ extern "C" {
> #define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
> A:R:G:B 16:16:16:16 little endian */
> #define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
> A:B:G:R 16:16:16:16 little endian */
>
> +/*
> + * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits
> + * of unused padding per component:
> + */
> +#define DRM_FORMAT_AXBXGXRX106106106106 fourcc_code('A', 'B', '1', '0') /*
> [63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian */
> +
> /* packed YCbCr */
> #define DRM_FORMAT_YUYV fourcc_code('Y', 'U', 'Y', 'V') /*
> [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
> #define DRM_FORMAT_YVYU fourcc_code('Y', 'V', 'Y', 'U') /*
> [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/fourcc: Add AXBXGXRX106106106106 format
Add ABGR format with 10-bit components packed in 64-bit per pixel.
This format can be used to handle
VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 on little-endian
architectures.
Signed-off-by: Matteo Franchin
Reviewed-by: Brian Starkey
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 722c7ebe4e88..03262472059c 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -202,6 +202,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_XBGR16161616F, .depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_ARGB16161616F, .depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_ABGR16161616F, .depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_AXBXGXRX106106106106, .depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_RGB888_A8, .depth = 32,
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_BGR888_A8, .depth = 32,
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_XRGB_A8, .depth = 32,
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 6f0628eb13a6..d720f1e8ae5e 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -179,6 +179,12 @@ extern "C" {
#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
A:R:G:B 16:16:16:16 little endian */
#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
A:B:G:R 16:16:16:16 little endian */
+/*
+ * RGBA format with 10-bit components packed in 64-bit per pixel, with 6 bits
+ * of unused padding per component:
+ */
+#define DRM_FORMAT_AXBXGXRX106106106106 fourcc_code('A', 'B', '1', '0') /*
[63:0] A:x:B:x:G:x:R:x 10:6:10:6:10:6:10:6 little endian */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
On 10/12/20 9:19 AM, Eric Biggers wrote: > On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote: >>> And I still don't really understand. After this patchset, there is still >>> code >>> nearly identical to the above (doing a temporary mapping just for a memcpy) >>> that >>> would still be using kmap_atomic(). >> I don't understand. You mean there would be other call sites calling: >> >> kmap_atomic() >> memcpy() >> kunmap_atomic() > Yes, there are tons of places that do this. Try 'git grep -A6 kmap_atomic' > and look for memcpy(). > > Hence why I'm asking what will be the "recommended" way to do this... > kunmap_thread() or kmap_atomic()? kmap_atomic() is always preferred over kmap()/kmap_thread(). kmap_atomic() is _much_ more lightweight since its TLB invalidation is always CPU-local and never broadcast. So, basically, unless you *must* sleep while the mapping is in place, kmap_atomic() is preferred. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote: > > > > And I still don't really understand. After this patchset, there is still > > code > > nearly identical to the above (doing a temporary mapping just for a memcpy) > > that > > would still be using kmap_atomic(). > > I don't understand. You mean there would be other call sites calling: > > kmap_atomic() > memcpy() > kunmap_atomic() Yes, there are tons of places that do this. Try 'git grep -A6 kmap_atomic' and look for memcpy(). Hence why I'm asking what will be the "recommended" way to do this... kunmap_thread() or kmap_atomic()? > And since I don't know the call site details if there are kmap_thread() calls > which are better off as kmap_atomic() calls I think it is worth converting > them. But I made the assumption that kmap users would already be calling > kmap_atomic() if they could (because it is more efficient). Not necessarily. In cases where either one is correct, people might not have put much thought into which of kmap() and kmap_atomic() they are using. - Eric ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/22] drm/msm: Do rpm get sooner in the submit path
On Mon, Oct 12, 2020 at 7:35 AM Daniel Vetter wrote:
>
> On Sun, Oct 11, 2020 at 07:09:34PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Unfortunately, due to an dev_pm_opp locking interaction with
> > mm->mmap_sem, we need to do pm get before aquiring obj locks,
> > otherwise we can have anger lockdep with the chain:
>
> tbh this sounds like a bug in that subsystem, since it means we cannot use
> said subsystem in mmap handlers either.
>
> So if you have some remapping unit or need to wake up your gpu to blt the
> buffer into system memory first, we're toast. That doesn't sound right. So
> maybe Cc: pm folks and figure out how to fix this long term properly? Imo
> not a good reason to hold up this patch set, since unwrangling mmap_sem
> tends to be work ...
+ a couple of PM folks
Looks like it has been this way for quite some time, so I guess the
overlap between things using dev_pm_opp and mmap is low..
fwiw, example splat so folks can see the locking interaction I am
talking about.. I suspect the pm_opp interaction with mm->mmap_sem is
from the debugfs calls while opp_table_lock is held?
[ 15.627855] ==
[ 15.634202] WARNING: possible circular locking dependency detected
[ 15.640550] 5.4.70 #41 Not tainted
[ 15.644050] --
[ 15.650397] chrome/1805 is trying to acquire lock:
[ 15.655314] ffed90720738 (opp_table_lock){+.+.}, at:
_find_opp_table+0x34/0x74
[ 15.663092]
[ 15.663092] but task is already holding lock:
[ 15.669082] ff80ff3911a8 (reservation_ww_class_mutex){+.+.},
at: submit_lock_objects+0x70/0x1ec
[ 15.678369]
[ 15.678369] which lock already depends on the new lock.
[ 15.678369]
[ 15.686764]
[ 15.686764] the existing dependency chain (in reverse order) is:
[ 15.694438]
[ 15.694438] -> #3 (reservation_ww_class_mutex){+.+.}:
[ 15.701146]__mutex_lock_common+0xec/0xc0c
[ 15.705978]ww_mutex_lock_interruptible+0x5c/0xc4
[ 15.711432]msm_gem_fault+0x2c/0x124
[ 15.715731]__do_fault+0x40/0x16c
[ 15.719766]handle_mm_fault+0x7cc/0xd98
[ 15.724337]do_page_fault+0x230/0x3b4
[ 15.728721]do_translation_fault+0x5c/0x78
[ 15.733558]do_mem_abort+0x4c/0xb4
[ 15.737680]el0_da+0x1c/0x20
[ 15.741266]
[ 15.741266] -> #2 (>mmap_sem){}:
[ 15.746809]__might_fault+0x70/0x98
[ 15.751022]compat_filldir+0xf8/0x48c
[ 15.755412]dcache_readdir+0x70/0x1dc
[ 15.759808]iterate_dir+0xd4/0x180
[ 15.763931]__arm64_compat_sys_getdents+0xa0/0x19c
[ 15.769476]el0_svc_common+0xa8/0x178
[ 15.773861]el0_svc_compat_handler+0x2c/0x40
[ 15.778868]el0_svc_compat+0x8/0x10
[ 15.783075]
[ 15.783075] -> #1 (>s_type->i_mutex_key#3){}:
[ 15.789788]down_write+0x54/0x16c
[ 15.793826]debugfs_remove_recursive+0x50/0x158
[ 15.799108]opp_debug_unregister+0x34/0x114
[ 15.804028]dev_pm_opp_put_opp_table+0xd0/0x14c
[ 15.809308]dev_pm_opp_put_clkname+0x3c/0x50
[ 15.814318]msm_dsi_host_destroy+0xb0/0xcc
[ 15.819149]dsi_destroy+0x40/0x58
[ 15.823184]dsi_bind+0x90/0x170
[ 15.827041]component_bind_all+0xf0/0x208
[ 15.831787]msm_drm_init+0x188/0x60c
[ 15.836084]msm_drm_bind+0x24/0x30
[ 15.840205]try_to_bring_up_master+0x15c/0x1a4
[ 15.845396]__component_add+0x98/0x14c
[ 15.849878]component_add+0x28/0x34
[ 15.854086]dp_display_probe+0x324/0x370
[ 15.858744]platform_drv_probe+0x90/0xb0
[ 15.863400]really_probe+0x134/0x2ec
[ 15.867699]driver_probe_device+0x64/0xfc
[ 15.872443]__device_attach_driver+0x8c/0xa4
[ 15.877459]bus_for_each_drv+0x90/0xd8
[ 15.881939]__device_attach+0xc0/0x148
[ 15.886420]device_initial_probe+0x20/0x2c
[ 15.891254]bus_probe_device+0x34/0x94
[ 15.895726]deferred_probe_work_func+0x78/0xb4
[ 15.900914]process_one_work+0x30c/0x5d0
[ 15.905573]worker_thread+0x240/0x3f0
[ 15.909959]kthread+0x144/0x154
[ 15.913809]ret_from_fork+0x10/0x18
[ 15.918016]
[ 15.918016] -> #0 (opp_table_lock){+.+.}:
[ 15.923660]__lock_acquire+0xee4/0x2450
[ 15.928230]lock_acquire+0x1cc/0x210
[ 15.932527]__mutex_lock_common+0xec/0xc0c
[ 15.937359]mutex_lock_nested+0x40/0x50
[ 15.941928]_find_opp_table+0x34/0x74
[ 15.946312]dev_pm_opp_find_freq_exact+0x2c/0xdc
[ 15.951680]a6xx_gmu_resume+0xc8/0xecc
[ 15.952812] fscrypt: AES-256-CTS-CBC using implementation "cts-cbc-aes-ce"
[ 15.956161]a6xx_pm_resume+0x148/0x200
[ 15.956166]adreno_resume+0x28/0x34
[ 15.956171]pm_generic_runtime_resume+0x34/0x48
[ 15.956174]__rpm_callback+0x70/0x10c
[ 15.956176]
Re: [PATCH] drm/panel: rm68200: fix mode to 50fps
On 9/25/20 4:16 PM, Yannick Fertre wrote:
> Compute new timings to get a framerate of 50fps with a pixel clock
> @54Mhz.
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/gpu/drm/panel/panel-raydium-rm68200.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> index 2b9e48b0a491..412c0dbcb2b6 100644
> --- a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm68200.c
> @@ -82,15 +82,15 @@ struct rm68200 {
> };
>
> static const struct drm_display_mode default_mode = {
> - .clock = 52582,
> + .clock = 54000,
> .hdisplay = 720,
> - .hsync_start = 720 + 38,
> - .hsync_end = 720 + 38 + 8,
> - .htotal = 720 + 38 + 8 + 38,
> + .hsync_start = 720 + 48,
> + .hsync_end = 720 + 48 + 9,
> + .htotal = 720 + 48 + 9 + 48,
> .vdisplay = 1280,
> .vsync_start = 1280 + 12,
> - .vsync_end = 1280 + 12 + 4,
> - .vtotal = 1280 + 12 + 4 + 12,
> + .vsync_end = 1280 + 12 + 5,
> + .vtotal = 1280 + 12 + 5 + 12,
> .flags = 0,
> .width_mm = 68,
> .height_mm = 122,
>
Hi Yannick,
Tested-by: Philippe Cornu
Thank you,
Philippe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v4 PATCH 0/2] fix scrolling of panel with small hfp or hbp
Hi, Jitao: Jitao Shi 於 2020年10月10日 週六 下午3:09寫道： > > Changes since v3: > - Revert v2, for v2 will cause some bridge ic no output. the cause >the video linetime doesn't match display mode from get mode. > - Make sure the horizontal_frontporch_byte and horizontal_backporch_byte >are > 0. Because v2 is merged into mainline, I think you should merge 1/2 and 2/2 to one patch which fix the problem caused by v2. Regards, Chun-Kuang. > > Jitao Shi (2): > Revert "drm/mediatek: dsi: Fix scrolling of panel with small hfp or > hbp" > drm/mediatek: dsi: fix scrolling of panel with small hfp or hbp > > drivers/gpu/drm/mediatek/mtk_dsi.c | 65 > +++--- > 1 file changed, 25 insertions(+), 40 deletions(-) > > -- > 2.12.5 > ___ > 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 1/4] drm/ttm: set the tt caching state at creation time
Am 12.10.20 um 16:14 schrieb Daniel Vetter:
On Mon, Oct 12, 2020 at 10:57:57AM +0200, Christian König wrote:
Ping? Anybody any more comments on this?
Otherwise I'm going to push it to drm-misc-next by tomorrow or so.
tbh the entire coherency/caching topic is imo a giantic mess in
drivers/gpu (mostly because we're half-fighting dma-api all the time). But
I don't have clear opinion where to go, hence *shrug*.
Well exactly that's why I'm doing the first step here by removing the
illusion that TTM can magically changing the caching of a BO :)
Christian.
-Daniel
Thanks,
Christian.
Am 08.10.20 um 11:31 schrieb Christian König:
All drivers can determine the tt caching state at creation time,
no need to do this on the fly during every validation.
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 11 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_sgdma.c| 13 -
drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 16 --
drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +-
drivers/gpu/drm/ttm/ttm_page_alloc.c | 26 -
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 20 ++---
drivers/gpu/drm/ttm/ttm_tt.c | 33 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 ++--
include/drm/ttm/ttm_caching.h | 34 ++
include/drm/ttm/ttm_tt.h | 16 --
13 files changed, 123 insertions(+), 60 deletions(-)
create mode 100644 include/drm/ttm/ttm_caching.h
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 213ef090bb0e..3c5ad69eff19 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -124,7 +124,7 @@ uint64_t amdgpu_gmc_agp_addr(struct ttm_buffer_object *bo)
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
struct ttm_dma_tt *ttm;
- if (bo->num_pages != 1 || bo->ttm->caching_state == tt_cached)
+ if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
return AMDGPU_BO_INVALID_OFFSET;
ttm = container_of(bo->ttm, struct ttm_dma_tt, ttm);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 399961035ae6..7f41a47e7353 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1292,7 +1292,9 @@ static void amdgpu_ttm_backend_destroy(struct
ttm_bo_device *bdev,
static struct ttm_tt *amdgpu_ttm_tt_create(struct ttm_buffer_object *bo,
uint32_t page_flags)
{
+ struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
struct amdgpu_ttm_tt *gtt;
+ enum ttm_caching caching;
gtt = kzalloc(sizeof(struct amdgpu_ttm_tt), GFP_KERNEL);
if (gtt == NULL) {
@@ -1300,8 +1302,13 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct
ttm_buffer_object *bo,
}
gtt->gobj = >base;
+ if (abo->flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC)
+ caching = ttm_write_combined;
+ else
+ caching = ttm_cached;
+
/* allocate space for the uninitialized page entries */
- if (ttm_sg_tt_init(>ttm, bo, page_flags)) {
+ if (ttm_sg_tt_init(>ttm, bo, page_flags, caching)) {
kfree(gtt);
return NULL;
}
@@ -1525,7 +1532,7 @@ uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt *ttm,
struct ttm_resource *mem)
if (mem && mem->mem_type == TTM_PL_TT) {
flags |= AMDGPU_PTE_SYSTEM;
- if (ttm->caching_state == tt_cached)
+ if (ttm->caching == ttm_cached)
flags |= AMDGPU_PTE_SNOOPED;
}
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3213429f8444..ad58d0af5141 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -918,7 +918,7 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct
ttm_buffer_object *bo,
if (!tt)
return NULL;
- ret = ttm_tt_init(tt, bo, page_flags);
+ ret = ttm_tt_init(tt, bo, page_flags, ttm_cached);
if (ret < 0)
goto err_ttm_tt_init;
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 806d9ec310f5..cd6fdebae795 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -5,6 +5,7 @@
#include "nouveau_drv.h"
#include "nouveau_mem.h"
#include "nouveau_ttm.h"
+#include "nouveau_bo.h"
struct nouveau_sgdma_be {
/* this has to be the first field so populate/unpopulated in
@@ -67,13 +68,23 @@ nouveau_sgdma_unbind(struct
Re: [PATCH v2 22/22] drm/msm: Don't implicit-sync if only a single ring
On Mon, Oct 12, 2020 at 7:40 AM Daniel Vetter wrote:
>
> On Sun, Oct 11, 2020 at 07:09:49PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Any cross-device sync use-cases *must* use explicit sync. And if there
> > is only a single ring (no-preemption), everything is FIFO order and
> > there is no need to implicit-sync.
> >
> > Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
> > is undefined when fences are not used to synchronize buffer usage across
> > contexts (which is the only case where multiple different priority rings
> > could come into play).
>
> Uh does this mean msm is broken on dri2/3 and wayland? Or I'm I just
> confused by your commit message?
No, I don't think so. If there is only a single priority level
ringbuffer (ie. no preemption to higher priority ring) then everything
is inherently FIFO order.
For cases where we are sharing buffers with something external to drm,
explicit sync will be used. And we don't implicit sync with display,
otherwise x11 (frontbuffer rendering) would not work
BR,
-R
> Since for these protocols we do expect implicit sync accross processes to
> work. Even across devices (and nvidia have actually provided quite a bunch
> of patches to make this work in i915 - ttm based drivers get this right,
> plus dumb scanout drivers using the right helpers also get this all
> right).
> -Daniel
>
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_gem_submit.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > index 3151a0ca8904..c69803ea53c8 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > @@ -277,7 +277,7 @@ static int submit_lock_objects(struct msm_gem_submit
> > *submit)
> > return ret;
> > }
> >
> > -static int submit_fence_sync(struct msm_gem_submit *submit, bool
> > no_implicit)
> > +static int submit_fence_sync(struct msm_gem_submit *submit, bool
> > implicit_sync)
> > {
> > int i, ret = 0;
> >
> > @@ -297,7 +297,7 @@ static int submit_fence_sync(struct msm_gem_submit
> > *submit, bool no_implicit)
> > return ret;
> > }
> >
> > - if (no_implicit)
> > + if (!implicit_sync)
> > continue;
> >
> > ret = msm_gem_sync_object(_obj->base, submit->ring->fctx,
> > @@ -768,7 +768,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> > *data,
> > if (ret)
> > goto out;
> >
> > - ret = submit_fence_sync(submit, !!(args->flags &
> > MSM_SUBMIT_NO_IMPLICIT));
> > + ret = submit_fence_sync(submit, (gpu->nr_rings > 1) &&
> > + !(args->flags & MSM_SUBMIT_NO_IMPLICIT));
> > if (ret)
> > goto out;
> >
> > --
> > 2.26.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 v2 22/22] drm/msm: Don't implicit-sync if only a single ring
On Sun, Oct 11, 2020 at 07:09:49PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Any cross-device sync use-cases *must* use explicit sync. And if there
> is only a single ring (no-preemption), everything is FIFO order and
> there is no need to implicit-sync.
>
> Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
> is undefined when fences are not used to synchronize buffer usage across
> contexts (which is the only case where multiple different priority rings
> could come into play).
Uh does this mean msm is broken on dri2/3 and wayland? Or I'm I just
confused by your commit message?
Since for these protocols we do expect implicit sync accross processes to
work. Even across devices (and nvidia have actually provided quite a bunch
of patches to make this work in i915 - ttm based drivers get this right,
plus dumb scanout drivers using the right helpers also get this all
right).
-Daniel
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gem_submit.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 3151a0ca8904..c69803ea53c8 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -277,7 +277,7 @@ static int submit_lock_objects(struct msm_gem_submit
> *submit)
> return ret;
> }
>
> -static int submit_fence_sync(struct msm_gem_submit *submit, bool no_implicit)
> +static int submit_fence_sync(struct msm_gem_submit *submit, bool
> implicit_sync)
> {
> int i, ret = 0;
>
> @@ -297,7 +297,7 @@ static int submit_fence_sync(struct msm_gem_submit
> *submit, bool no_implicit)
> return ret;
> }
>
> - if (no_implicit)
> + if (!implicit_sync)
> continue;
>
> ret = msm_gem_sync_object(_obj->base, submit->ring->fctx,
> @@ -768,7 +768,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> if (ret)
> goto out;
>
> - ret = submit_fence_sync(submit, !!(args->flags &
> MSM_SUBMIT_NO_IMPLICIT));
> + ret = submit_fence_sync(submit, (gpu->nr_rings > 1) &&
> + !(args->flags & MSM_SUBMIT_NO_IMPLICIT));
> if (ret)
> goto out;
>
> --
> 2.26.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 v2 07/22] drm/msm: Do rpm get sooner in the submit path
On Sun, Oct 11, 2020 at 07:09:34PM -0700, Rob Clark wrote: > From: Rob Clark > > Unfortunately, due to an dev_pm_opp locking interaction with > mm->mmap_sem, we need to do pm get before aquiring obj locks, > otherwise we can have anger lockdep with the chain: tbh this sounds like a bug in that subsystem, since it means we cannot use said subsystem in mmap handlers either. So if you have some remapping unit or need to wake up your gpu to blt the buffer into system memory first, we're toast. That doesn't sound right. So maybe Cc: pm folks and figure out how to fix this long term properly? Imo not a good reason to hold up this patch set, since unwrangling mmap_sem tends to be work ... -Daniel > > opp_table_lock --> >mmap_sem --> reservation_ww_class_mutex > > For an explicit fencing userspace, the impact should be minimal > as we do all the fence waits before this point. It could result > in some needless resumes in error cases, etc. > > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/msm/msm_gem_submit.c | 15 +-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c > b/drivers/gpu/drm/msm/msm_gem_submit.c > index 002130d826aa..a9422d043bfe 100644 > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > @@ -744,11 +744,20 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void > *data, > > ret = submit_lookup_objects(submit, args, file); > if (ret) > - goto out; > + goto out_pre_pm; > > ret = submit_lookup_cmds(submit, args, file); > if (ret) > - goto out; > + goto out_pre_pm; > + > + /* > + * Thanks to dev_pm_opp opp_table_lock interactions with mm->mmap_sem > + * in the resume path, we need to to rpm get before we lock objs. > + * Which unfortunately might involve powering up the GPU sooner than > + * is necessary. But at least in the explicit fencing case, we will > + * have already done all the fence waiting. > + */ > + pm_runtime_get_sync(>pdev->dev); > > /* copy_*_user while holding a ww ticket upsets lockdep */ > ww_acquire_init(>ticket, _ww_class); > @@ -825,6 +834,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void > *data, > > > out: > + pm_runtime_put(>pdev->dev); > +out_pre_pm: > submit_cleanup(submit); > if (has_ww_ticket) > ww_acquire_fini(>ticket); > -- > 2.26.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 1/2] drm: Ask whether drm_gem_get_pages() should clear the CPU cache
On Mon, Oct 12, 2020 at 11:51:30AM +0100, Chris Wilson wrote:
> On some processors (such as arch/x86), accessing a page via a WC PAT is
> bypassed if the page is physically tagged in the CPU cache, and the
> access is serviced by the cache instead -- which leads to incoherency
> should the physical page itself be accessed using DMA. In order to
> prevent the false cache sharing of the physical pages, we need to
> explicitly flush the cache lines of those pages.
>
> Signed-off-by: Chris Wilson
Hm I'd leave this out for now. dma-api/cache flushing, and especially on
x86 is kinda a mess. I'd just land v1 of your patch meanwhile for vgem.
-Daniel
> ---
> drivers/gpu/drm/drm_gem.c | 8 ++--
> drivers/gpu/drm/drm_gem_shmem_helper.c | 8 +++-
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
> drivers/gpu/drm/gma500/gtt.c| 2 +-
> drivers/gpu/drm/msm/msm_gem.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_gem.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
> drivers/gpu/drm/tegra/gem.c | 2 +-
> drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
> drivers/gpu/drm/vkms/vkms_gem.c | 2 +-
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
> include/drm/drm_gem.h | 2 +-
> 12 files changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 1da67d34e55d..1948855d69e6 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -40,6 +40,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -525,6 +526,7 @@ static void drm_gem_check_release_pagevec(struct pagevec
> *pvec)
> * drm_gem_get_pages - helper to allocate backing pages for a GEM object
> * from shmem
> * @obj: obj in question
> + * @clflush: whether to clear any CPU caches associated with the backing
> store
> *
> * This reads the page-array of the shmem-backing storage of the given gem
> * object. An array of pages is returned. If a page is not allocated or
> @@ -546,14 +548,13 @@ static void drm_gem_check_release_pagevec(struct
> pagevec *pvec)
> * drm_gem_object_init(), but not for those initialized with
> * drm_gem_private_object_init() only.
> */
> -struct page **drm_gem_get_pages(struct drm_gem_object *obj)
> +struct page **drm_gem_get_pages(struct drm_gem_object *obj, bool clflush)
> {
> struct address_space *mapping;
> struct page *p, **pages;
> struct pagevec pvec;
> int i, npages;
>
> -
> if (WARN_ON(!obj->filp))
> return ERR_PTR(-EINVAL);
>
> @@ -589,6 +590,9 @@ struct page **drm_gem_get_pages(struct drm_gem_object
> *obj)
> (page_to_pfn(p) >= 0x0010UL));
> }
>
> + if (clflush)
> + drm_clflush_pages(pages, npages);
> +
> return pages;
>
> fail:
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index fb11df7aced5..78a2eb77802b 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -152,7 +152,13 @@ static int drm_gem_shmem_get_pages_locked(struct
> drm_gem_shmem_object *shmem)
> if (shmem->pages_use_count++ > 0)
> return 0;
>
> - pages = drm_gem_get_pages(obj);
> + /*
> + * On some processors (such as arch/x86), accessing a page via a WC PAT
> + * is bypassed if the page is physically tagged in the CPU cache, and
> + * the access is serviced by the cache instead -- which leads to
> + * incoherency should the physical page itself be accessed using DMA.
> + */
> + pages = drm_gem_get_pages(obj, !shmem->map_cached);
> if (IS_ERR(pages)) {
> DRM_DEBUG_KMS("Failed to get pages (%ld)\n", PTR_ERR(pages));
> shmem->pages_use_count = 0;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index 67d9a2b9ea6a..d8279ea363b3 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -58,7 +58,7 @@ static void etnaviv_gem_scatterlist_unmap(struct
> etnaviv_gem_object *etnaviv_obj
> static int etnaviv_gem_shmem_get_pages(struct etnaviv_gem_object
> *etnaviv_obj)
> {
> struct drm_device *dev = etnaviv_obj->base.dev;
> - struct page **p = drm_gem_get_pages(_obj->base);
> + struct page **p = drm_gem_get_pages(_obj->base, false);
>
> if (IS_ERR(p)) {
> dev_dbg(dev->dev, "could not get pages: %ld\n", PTR_ERR(p));
> diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
> index 9278bcfad1bf..ada56aec7e68 100644
> --- a/drivers/gpu/drm/gma500/gtt.c
> +++ b/drivers/gpu/drm/gma500/gtt.c
> @@ -197,7 +197,7 @@ static int psb_gtt_attach_pages(struct gtt_range *gt)
>
> WARN_ON(gt->pages);
>
> - pages = drm_gem_get_pages(>gem);
> +
Re: [PATCH 3/3] drm/vkms: fbdev emulation support
On Mon, Oct 12, 2020 at 02:40:58PM +0200, Neil Armstrong wrote: > Hi, > > On 12/10/2020 13:24, Thomas Zimmermann wrote: > > Hi > > > > On Sat, 10 Oct 2020 01:21:56 +0200 Daniel Vetter > > wrote: > > > >> Hooray for generic fbdev support, making this a oneliner. We just > >> needed to fix preferred_depth fixed and the vmap support added first. > >> > >> Signed-off-by: Daniel Vetter > >> Cc: Rodrigo Siqueira > >> Cc: Melissa Wen > >> Cc: Haneen Mohammed > >> Cc: Daniel Vetter > >> --- > >> drivers/gpu/drm/vkms/vkms_drv.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c > >> b/drivers/gpu/drm/vkms/vkms_drv.c > >> index 6221e5040264..cc09e2df5cb1 100644 > >> --- a/drivers/gpu/drm/vkms/vkms_drv.c > >> +++ b/drivers/gpu/drm/vkms/vkms_drv.c > >> @@ -169,6 +169,8 @@ static int __init vkms_init(void) > >>if (ret) > >>goto out_devres; > >> > >> + drm_fbdev_generic_setup(_device->drm, 0); > >> + > > > > It feels strange to have console support in a driver for non-interactive > > systems. But OK, why not. I guess it helps with testing? Yeah I want to polish the igt fbdev testcase a bit, need a victim for fb device selction. vkms was the quickest way to get two fbdev instances into one box :-) Plus more code we could test using igt & vkms in gitlab CI, whenever we get around to that ... > It's weird because it the kernel is misconfigured and no console is specified > on the cmdline > this console could become the main console... > > It's a great feature, but couldn't this be a module parameter ? If you have vkms enabled in a distro, you're doing it wrong. Also, if you accidentally load vkms, then Xorg will happily bind to it (maybe in preference to the real fbdev driver that's there as a simplefb). So imo this problem isn't really new. -Daniel > > Neil > > > > > Acked-by: Thomas Zimmermann > > > > Best regards > > Thomas > > > >>return 0; > >> > >> out_devres: > > > > ___ > > 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 2/2] mm: introduce vma_set_file function v4
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on staging/staging-testing linus/master v5.9
next-20201012]
[cannot apply to mmotm/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/mm-mmap-fix-fput-in-error-path-v2/20201012-165336
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: arm-randconfig-r034-20201012 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/4ff869f185acba6d9c37ab6abdb0d9f93f31d15b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-K-nig/mm-mmap-fix-fput-in-error-path-v2/20201012-165336
git checkout 4ff869f185acba6d9c37ab6abdb0d9f93f31d15b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
arm-linux-gnueabi-ld: drivers/gpu/drm/vgem/vgem_drv.o: in function
`vgem_prime_mmap':
>> drivers/gpu/drm/vgem/vgem_drv.c:396: undefined reference to `vma_set_file'
arm-linux-gnueabi-ld: drivers/dma-buf/dma-buf.o: in function `dma_buf_mmap':
>> drivers/dma-buf/dma-buf.c:1163: undefined reference to `vma_set_file'
vim +396 drivers/gpu/drm/vgem/vgem_drv.c
380
381 static int vgem_prime_mmap(struct drm_gem_object *obj,
382 struct vm_area_struct *vma)
383 {
384 int ret;
385
386 if (obj->size < vma->vm_end - vma->vm_start)
387 return -EINVAL;
388
389 if (!obj->filp)
390 return -ENODEV;
391
392 ret = call_mmap(obj->filp, vma);
393 if (ret)
394 return ret;
395
> 396 vma_set_file(vma, obj->filp);
397 vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
398 vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
399
400 return 0;
401 }
402
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/17] s390/pci: Remove races against pte updates
On Mon, Oct 12, 2020 at 04:03:28PM +0200, Niklas Schnelle wrote:
> Hi Daniel,
>
> freshly back from my vacation I've just taken a look at your patch.
> First thanks for this fix and the detailed commit description.
> Definitely makes sense to fix this and you can add my
>
> Acked-by: Niklas Schnelle
>
> Content wise it all looks sane and clear and since Gerald did the testing,
> I would have applied it to our tree already, but I got some trivial
> checkpatch violations that probably apply to the whole series.
> I've commented them inline below.
> If you confirm there I can do the fixups when applying or you can resend.
>
> On 10/9/20 9:59 AM, Daniel Vetter wrote:
> > Way back it was a reasonable assumptions that iomem mappings never
> > change the pfn range they point at. But this has changed:
> >
> > - gpu drivers dynamically manage their memory nowadays, invalidating
> > ptes with unmap_mapping_range when buffers get moved
> >
> > - contiguous dma allocations have moved from dedicated carvetouts to
> > cma regions. This means if we miss the unmap the pfn might contain
> > pagecache or anon memory (well anything allocated with GFP_MOVEABLE)
> >
> > - even /dev/mem now invalidates mappings when the kernel requests that
> > iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
>
> The above commit mention should use the format
> 'commit 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
> region")'
> otherwise this results in a checkpatch ERROR.
>
> > ("/dev/mem: Revoke mappings when a driver claims the region")
> >
> > Accessing pfns obtained from ptes without holding all the locks is
> > therefore no longer a good idea. Fix this.
> >
> > Since zpci_memcpy_from|toio seems to not do anything nefarious with
> > locks we just need to open code get_pfn and follow_pfn and make sure
> > we drop the locks only after we've done. The write function also needs
>
> just a typo but just saw it "we're" instead of "we've"
>
> > the copy_from_user move, since we can't take userspace faults while
> > holding the mmap sem.
> >
> > Reviewed-by: Gerald Schaefer
> >
> No empty line after the Revied-by tag.
>
> > Signed-off-by: Daniel Vetter
>
> Your Signed-off-by mail address does not match the one you're sending from,
> this yields a checkpatch warning when using git am with your mail.
> This is probably just a silly misconfiguration but since Signed-offs
> are signatures should I change this to
> "Daniel Vetter " which is the one you're
> sending from and also in the MAINTAINERS file?
>
>
> > Cc: Jason Gunthorpe
> > Cc: Dan Williams
> > Cc: Kees Cook
> > Cc: Andrew Morton
> > Cc: John Hubbard
> > Cc: Jérôme Glisse
> > Cc: Jan Kara
> > Cc: Dan Williams
>
> The above Cc: line for Dan Williams is a duplicate
>
> > Cc: linux...@kvack.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-samsung-...@vger.kernel.org
> > Cc: linux-me...@vger.kernel.org
> > Cc: Niklas Schnelle
> > Cc: Gerald Schaefer
> > Cc: linux-s...@vger.kernel.org
> > --
> > v2: Move VM_IO | VM_PFNMAP checks around so they keep returning EINVAL
> > like before (Gerard)
>
> I think the above should go before the CC/Signed-off/Reviewev block.
This is a per-subsystem bikeshed :-) drivers/gpu definitely wants it
above, but most core subsystems want it below. I'll move it.
> > ---
> > arch/s390/pci/pci_mmio.c | 98 +++-
> > 1 file changed, 57 insertions(+), 41 deletions(-)
> >
> > diff --git a/arch/s390/pci/pci_mmio.c b/arch/s390/pci/pci_mmio.c
> > index 401cf670a243..1a6adbc68ee8 100644
> > --- a/arch/s390/pci/pci_mmio.c
> > +++ b/arch/s390/pci/pci_mmio.c
> > @@ -119,33 +119,15 @@ static inline int __memcpy_toio_inuser(void __iomem
> > *dst,
> > return rc;
> > }
> >
> > -static long get_pfn(unsigned long user_addr, unsigned long access,
> > - unsigned long *pfn)
> > -{
> > - struct vm_area_struct *vma;
> > - long ret;
> > -
> > - mmap_read_lock(current->mm);
> > - ret = -EINVAL;
> > - vma = find_vma(current->mm, user_addr);
> > - if (!vma)
> > - goto out;
> > - ret = -EACCES;
> > - if (!(vma->vm_flags & access))
> > - goto out;
> > - ret = follow_pfn(vma, user_addr, pfn);
> > -out:
> > - mmap_read_unlock(current->mm);
> > - return ret;
> > -}
> > -
> > SYSCALL_DEFINE3(s390_pci_mmio_write, unsigned long, mmio_addr,
> > const void __user *, user_buffer, size_t, length)
> > {
> > u8 local_buf[64];
> > void __iomem *io_addr;
> > void *buf;
> > - unsigned long pfn;
> > + struct vm_area_struct *vma;
> > + pte_t *ptep;
> > + spinlock_t *ptl;
>
> With checkpatch.pl --strict the above yields a complained
> "CHECK: spinlock_t definition without comment" but I think
> that's really okay since your commit description is very clear.
> Same oin line 277.
I think this is a falls positive, checkpatch doesn't realize that
SYSCALL_DEFINE3 is a function, not a structure.
Re: [Intel-gfx] [PATCH] drm/vgem: Replace vgem_object_funcs with the common drm shmem helper
Quoting Daniel Vetter (2020-10-12 15:12:50) > On Mon, Oct 12, 2020 at 03:01:09PM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2020-10-12 14:55:07) > > > On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson > > > wrote: > > > > Quoting Daniel Vetter (2020-10-09 17:16:06) > > > > > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson > > > > > wrote: > > > > > > > > > > > > vgem is a minimalistic driver that provides shmemfs objects to > > > > > > userspace that may then be used as an in-memory surface and > > > > > > transported > > > > > > across dma-buf to other drivers. Since it's introduction, > > > > > > drm_gem_shmem_helper now provides the same shmemfs facilities and > > > > > > so we > > > > > > can trim vgem to wrap the helper. > > > > > > > > > > > > Signed-off-by: Chris Wilson > > > > > > --- > > > > > > drivers/gpu/drm/Kconfig | 1 + > > > > > > drivers/gpu/drm/vgem/vgem_drv.c | 281 > > > > > > ++-- > > > > > > drivers/gpu/drm/vgem/vgem_drv.h | 11 -- > > > > > > 3 files changed, 13 insertions(+), 280 deletions(-) > > > > > > > > > > Nice diffstat :-) > > > > > > > > > > Reviewed-by: Daniel Vetter > > > > > > > > Unfortunately I had to drop the drm_gem_prime_mmap() since the existing > > > > expectation is that we hand the faulthandler off to shmemfs so we can > > > > release the module while the memory is exported. > > > > > > That sounds like a broken igt. Once we have refcounting for > > > outstanding dma_fence/buf or anything else we'll block unloading of > > > the module (not unbinding of the driver). Which one is that? > > > > The dma-buf is closed; all that remains is the mmap. Then from the > > perspective of the module, there is no reference back to the module > > since we delegate handling of the mmap back to the owner, the shmemfs > > builtin. That allows us to remove the module as its object code is no > > longer required. > > Oh I know how that's possible, I wonder about which testcase encodes that. > Because it really shouldn't, since that's quite far away from the rough > consensus that we cobbled together on dri-devel a few months ago about how > hotunplug should work. If it's a vgem test, meh, we can change that > whenever. But if it's a generic test that falls over on vgem, then we need > to teach it better assumptions. We intentionally copied the module unload behaviour from i915. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/ttm: set the tt caching state at creation time
On Mon, Oct 12, 2020 at 10:57:57AM +0200, Christian König wrote:
> Ping? Anybody any more comments on this?
>
> Otherwise I'm going to push it to drm-misc-next by tomorrow or so.
tbh the entire coherency/caching topic is imo a giantic mess in
drivers/gpu (mostly because we're half-fighting dma-api all the time). But
I don't have clear opinion where to go, hence *shrug*.
-Daniel
>
> Thanks,
> Christian.
>
> Am 08.10.20 um 11:31 schrieb Christian König:
> > All drivers can determine the tt caching state at creation time,
> > no need to do this on the fly during every validation.
> >
> > Signed-off-by: Christian König
> > Reviewed-by: Michael J. Ruhl
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 2 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 11 +--
> > drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
> > drivers/gpu/drm/nouveau/nouveau_sgdma.c| 13 -
> > drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
> > drivers/gpu/drm/radeon/radeon_ttm.c| 16 --
> > drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +-
> > drivers/gpu/drm/ttm/ttm_page_alloc.c | 26 -
> > drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 20 ++---
> > drivers/gpu/drm/ttm/ttm_tt.c | 33 +++--
> > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 ++--
> > include/drm/ttm/ttm_caching.h | 34 ++
> > include/drm/ttm/ttm_tt.h | 16 --
> > 13 files changed, 123 insertions(+), 60 deletions(-)
> > create mode 100644 include/drm/ttm/ttm_caching.h
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> > index 213ef090bb0e..3c5ad69eff19 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> > @@ -124,7 +124,7 @@ uint64_t amdgpu_gmc_agp_addr(struct ttm_buffer_object
> > *bo)
> > struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
> > struct ttm_dma_tt *ttm;
> > - if (bo->num_pages != 1 || bo->ttm->caching_state == tt_cached)
> > + if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
> > return AMDGPU_BO_INVALID_OFFSET;
> > ttm = container_of(bo->ttm, struct ttm_dma_tt, ttm);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > index 399961035ae6..7f41a47e7353 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > @@ -1292,7 +1292,9 @@ static void amdgpu_ttm_backend_destroy(struct
> > ttm_bo_device *bdev,
> > static struct ttm_tt *amdgpu_ttm_tt_create(struct ttm_buffer_object *bo,
> >uint32_t page_flags)
> > {
> > + struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
> > struct amdgpu_ttm_tt *gtt;
> > + enum ttm_caching caching;
> > gtt = kzalloc(sizeof(struct amdgpu_ttm_tt), GFP_KERNEL);
> > if (gtt == NULL) {
> > @@ -1300,8 +1302,13 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct
> > ttm_buffer_object *bo,
> > }
> > gtt->gobj = >base;
> > + if (abo->flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC)
> > + caching = ttm_write_combined;
> > + else
> > + caching = ttm_cached;
> > +
> > /* allocate space for the uninitialized page entries */
> > - if (ttm_sg_tt_init(>ttm, bo, page_flags)) {
> > + if (ttm_sg_tt_init(>ttm, bo, page_flags, caching)) {
> > kfree(gtt);
> > return NULL;
> > }
> > @@ -1525,7 +1532,7 @@ uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt *ttm,
> > struct ttm_resource *mem)
> > if (mem && mem->mem_type == TTM_PL_TT) {
> > flags |= AMDGPU_PTE_SYSTEM;
> > - if (ttm->caching_state == tt_cached)
> > + if (ttm->caching == ttm_cached)
> > flags |= AMDGPU_PTE_SNOOPED;
> > }
> > diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> > b/drivers/gpu/drm/drm_gem_vram_helper.c
> > index 3213429f8444..ad58d0af5141 100644
> > --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> > @@ -918,7 +918,7 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct
> > ttm_buffer_object *bo,
> > if (!tt)
> > return NULL;
> > - ret = ttm_tt_init(tt, bo, page_flags);
> > + ret = ttm_tt_init(tt, bo, page_flags, ttm_cached);
> > if (ret < 0)
> > goto err_ttm_tt_init;
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
> > b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
> > index 806d9ec310f5..cd6fdebae795 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
> > @@ -5,6 +5,7 @@
> > #include "nouveau_drv.h"
> > #include "nouveau_mem.h"
> > #include "nouveau_ttm.h"
> > +#include "nouveau_bo.h"
> > struct nouveau_sgdma_be {
> > /* this has to be the first field so populate/unpopulated in
> > @@ -67,13 +68,23
Re: [Intel-gfx] [PATCH] drm/vgem: Replace vgem_object_funcs with the common drm shmem helper
On Mon, Oct 12, 2020 at 03:01:09PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2020-10-12 14:55:07) > > On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson > > wrote: > > > Quoting Daniel Vetter (2020-10-09 17:16:06) > > > > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson > > > > wrote: > > > > > > > > > > vgem is a minimalistic driver that provides shmemfs objects to > > > > > userspace that may then be used as an in-memory surface and > > > > > transported > > > > > across dma-buf to other drivers. Since it's introduction, > > > > > drm_gem_shmem_helper now provides the same shmemfs facilities and so > > > > > we > > > > > can trim vgem to wrap the helper. > > > > > > > > > > Signed-off-by: Chris Wilson > > > > > --- > > > > > drivers/gpu/drm/Kconfig | 1 + > > > > > drivers/gpu/drm/vgem/vgem_drv.c | 281 > > > > > ++-- > > > > > drivers/gpu/drm/vgem/vgem_drv.h | 11 -- > > > > > 3 files changed, 13 insertions(+), 280 deletions(-) > > > > > > > > Nice diffstat :-) > > > > > > > > Reviewed-by: Daniel Vetter > > > > > > Unfortunately I had to drop the drm_gem_prime_mmap() since the existing > > > expectation is that we hand the faulthandler off to shmemfs so we can > > > release the module while the memory is exported. > > > > That sounds like a broken igt. Once we have refcounting for > > outstanding dma_fence/buf or anything else we'll block unloading of > > the module (not unbinding of the driver). Which one is that? > > The dma-buf is closed; all that remains is the mmap. Then from the > perspective of the module, there is no reference back to the module > since we delegate handling of the mmap back to the owner, the shmemfs > builtin. That allows us to remove the module as its object code is no > longer required. Oh I know how that's possible, I wonder about which testcase encodes that. Because it really shouldn't, since that's quite far away from the rough consensus that we cobbled together on dri-devel a few months ago about how hotunplug should work. If it's a vgem test, meh, we can change that whenever. But if it's a generic test that falls over on vgem, then we need to teach it better assumptions. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ingenic: Fix bad revert
On Mon, Oct 12, 2020 at 12:25:09PM +0200, Paul Cercueil wrote:
> Fix a badly reverted commit. The revert commit was cherry-picked from
> drm-misc-next to drm-misc-next-fixes, and in the process some unrelated
> code was added.
>
> Fixes: a3fb64c00d44 "Revert "gpu/drm: ingenic: Add option to mmap GEM buffers
> cached""
> Signed-off-by: Paul Cercueil
Acked-by: Daniel Vetter
And yes if you use git cherry-pick it'll do a 3 way merge, and
occasionally it's very tricky to resolve that properly. Especially when
you're not used to it.
What I tend to do to double check cerry-picks is git show both commits,
and compare the entire diff line-by-line to make sure I didn't misplace
anything.
Another trick is to use the raw patch instead of cherry-pick, since that
won't do a 3 way merge where you might get confused with other context and
fun stuff like that.
Cheers, Daniel
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 16
> 1 file changed, 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index 1be1235bd546..a3d1617d7c67 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -440,20 +440,6 @@ void ingenic_drm_plane_config(struct device *dev,
> }
> }
>
> -static void ingenic_drm_update_palette(struct ingenic_drm *priv,
> -const struct drm_color_lut *lut)
> -{
> - unsigned int i;
> -
> - for (i = 0; i < ARRAY_SIZE(priv->dma_hwdescs->palette); i++) {
> - u16 color = drm_color_lut_extract(lut[i].red, 5) << 11
> - | drm_color_lut_extract(lut[i].green, 6) << 5
> - | drm_color_lut_extract(lut[i].blue, 5);
> -
> - priv->dma_hwdescs->palette[i] = color;
> - }
> -}
> -
> static void ingenic_drm_plane_atomic_update(struct drm_plane *plane,
> struct drm_plane_state *oldstate)
> {
> @@ -464,8 +450,6 @@ static void ingenic_drm_plane_atomic_update(struct
> drm_plane *plane,
> dma_addr_t addr;
>
> if (state && state->fb) {
> - crtc_state = state->crtc->state;
> -
> addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
> width = state->src_w >> 16;
> height = state->src_h >> 16;
> --
> 2.28.0
>
--
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 2/2] mm: introduce vma_set_file function v4
Hi "Christian, I love your patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on staging/staging-testing linus/master hnaz-linux-mm/master v5.9 next-20201012] [cannot apply to mmotm/master] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Christian-K-nig/mm-mmap-fix-fput-in-error-path-v2/20201012-165336 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: sh-allmodconfig (attached as .config) compiler: sh4-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/4ff869f185acba6d9c37ab6abdb0d9f93f31d15b git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Christian-K-nig/mm-mmap-fix-fput-in-error-path-v2/20201012-165336 git checkout 4ff869f185acba6d9c37ab6abdb0d9f93f31d15b # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=sh If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): sh4-linux-ld: drivers/dma-buf/dma-buf.o: in function `dma_buf_mmap': >> (.text+0x8c4): undefined reference to `vma_set_file' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/vgem: Replace vgem_object_funcs with the common drm shmem helper
Quoting Daniel Vetter (2020-10-12 14:55:07) > On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson > wrote: > > Quoting Daniel Vetter (2020-10-09 17:16:06) > > > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson > > > wrote: > > > > > > > > vgem is a minimalistic driver that provides shmemfs objects to > > > > userspace that may then be used as an in-memory surface and transported > > > > across dma-buf to other drivers. Since it's introduction, > > > > drm_gem_shmem_helper now provides the same shmemfs facilities and so we > > > > can trim vgem to wrap the helper. > > > > > > > > Signed-off-by: Chris Wilson > > > > --- > > > > drivers/gpu/drm/Kconfig | 1 + > > > > drivers/gpu/drm/vgem/vgem_drv.c | 281 ++-- > > > > drivers/gpu/drm/vgem/vgem_drv.h | 11 -- > > > > 3 files changed, 13 insertions(+), 280 deletions(-) > > > > > > Nice diffstat :-) > > > > > > Reviewed-by: Daniel Vetter > > > > Unfortunately I had to drop the drm_gem_prime_mmap() since the existing > > expectation is that we hand the faulthandler off to shmemfs so we can > > release the module while the memory is exported. > > That sounds like a broken igt. Once we have refcounting for > outstanding dma_fence/buf or anything else we'll block unloading of > the module (not unbinding of the driver). Which one is that? The dma-buf is closed; all that remains is the mmap. Then from the perspective of the module, there is no reference back to the module since we delegate handling of the mmap back to the owner, the shmemfs builtin. That allows us to remove the module as its object code is no longer required. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/vgem: Replace vgem_object_funcs with the common drm shmem helper
On Mon, Oct 12, 2020 at 12:49 PM Chris Wilson wrote: > Quoting Daniel Vetter (2020-10-09 17:16:06) > > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson > > wrote: > > > > > > vgem is a minimalistic driver that provides shmemfs objects to > > > userspace that may then be used as an in-memory surface and transported > > > across dma-buf to other drivers. Since it's introduction, > > > drm_gem_shmem_helper now provides the same shmemfs facilities and so we > > > can trim vgem to wrap the helper. > > > > > > Signed-off-by: Chris Wilson > > > --- > > > drivers/gpu/drm/Kconfig | 1 + > > > drivers/gpu/drm/vgem/vgem_drv.c | 281 ++-- > > > drivers/gpu/drm/vgem/vgem_drv.h | 11 -- > > > 3 files changed, 13 insertions(+), 280 deletions(-) > > > > Nice diffstat :-) > > > > Reviewed-by: Daniel Vetter > > Unfortunately I had to drop the drm_gem_prime_mmap() since the existing > expectation is that we hand the faulthandler off to shmemfs so we can > release the module while the memory is exported. That sounds like a broken igt. Once we have refcounting for outstanding dma_fence/buf or anything else we'll block unloading of the module (not unbinding of the driver). Which one is that? > The other issue happens > to be for arch/x86 where just setting PAT=WC on the PTE does not flush > the cache for that page, and the CPU will preferentially use the cache. > That has caught us out more than once. Ah, the old disappointment around wc and dma-api on x86 I guess :-/ -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn
On Mon, Oct 12, 2020 at 12:47 PM Marek Szyprowski wrote: > > Hi Jason, > > On 09.10.2020 14:48, Jason Gunthorpe wrote: > > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > > > >> I'm not a mm/ expert, but, from what I understood from Daniel's patch > >> description is that this is unsafe *only if* __GFP_MOVABLE is used. > > No, it is unconditionally unsafe. The CMA movable mappings are > > specific VMAs that will have bad issues here, but there are other > > types too. > > I'm trying to follow this thread, but I really wonder what do you mean > by CMA movable mappings? If a buffer has been allocated from CMA and > used for DMA, it won't be moved in the memory. It will stay at the same > physical memory address all the time until freed by the owner. It just a > matter of proper usage count tracking to delay freeing if it is still > used somewhere. Yup. The problem is that this usage count tracking doesn't exist. And drivers could at least in theory treat CMA like vram and swap buffers in of it, so just refcounting the userspace vma isn't enough. In practice, right now, it might be enough for CMA drivers though (but there's more that's possible here). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.8 009/124] drm/nouveau/device: return error for unknown chipsets
From: Karol Herbst
commit c3e0276c31ca8c7b8615da890727481260d4676f upstream.
Previously the code relied on device->pri to be NULL and to fail probing
later. We really should just return an error inside nvkm_device_ctor for
unsupported GPUs.
Fixes: 24d5ff40a732 ("drm/nouveau/device: rework mmio mapping code to get rid
of second map")
Signed-off-by: Karol Herbst
Cc: dann frazier
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
Reviewed-by: Jeremy Cline
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20201006220528.13925-1-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -3149,6 +3149,7 @@ nvkm_device_ctor(const struct nvkm_devic
case 0x168: device->chip = _chipset; break;
default:
nvdev_error(device, "unknown chipset (%08x)\n", boot0);
+ ret = -ENODEV;
goto done;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.8 010/124] drm/nouveau/mem: guard against NULL pointer access in mem_del
From: Karol Herbst
commit d10285a25e29f13353bbf7760be8980048c1ef2f upstream.
other drivers seems to do something similar
Signed-off-by: Karol Herbst
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20201006220528.13925-2-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nouveau_mem.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -176,6 +176,8 @@ void
nouveau_mem_del(struct ttm_mem_reg *reg)
{
struct nouveau_mem *mem = nouveau_mem(reg);
+ if (!mem)
+ return;
nouveau_mem_fini(mem);
kfree(reg->mm_node);
reg->mm_node = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.4 10/85] drm/nouveau/mem: guard against NULL pointer access in mem_del
From: Karol Herbst
commit d10285a25e29f13353bbf7760be8980048c1ef2f upstream.
other drivers seems to do something similar
Signed-off-by: Karol Herbst
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20201006220528.13925-2-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nouveau_mem.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -176,6 +176,8 @@ void
nouveau_mem_del(struct ttm_mem_reg *reg)
{
struct nouveau_mem *mem = nouveau_mem(reg);
+ if (!mem)
+ return;
nouveau_mem_fini(mem);
kfree(reg->mm_node);
reg->mm_node = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.19 06/49] drm/nouveau/mem: guard against NULL pointer access in mem_del
From: Karol Herbst
commit d10285a25e29f13353bbf7760be8980048c1ef2f upstream.
other drivers seems to do something similar
Signed-off-by: Karol Herbst
Cc: dri-devel
Cc: Dave Airlie
Cc: sta...@vger.kernel.org
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20201006220528.13925-2-kher...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/nouveau/nouveau_mem.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -176,6 +176,8 @@ void
nouveau_mem_del(struct ttm_mem_reg *reg)
{
struct nouveau_mem *mem = nouveau_mem(reg);
+ if (!mem)
+ return;
nouveau_mem_fini(mem);
kfree(reg->mm_node);
reg->mm_node = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [2/2] drm/msm: Add support for GPU cooling
On 10/10/2020 12:06 AM, m...@chromium.org wrote:
Hi Akhil,
On Thu, Oct 08, 2020 at 10:39:07PM +0530, Akhil P Oommen wrote:
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/msm_gpu.c | 13 -
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 55d1648..93ffd66 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -107,9 +108,18 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
if (IS_ERR(gpu->devfreq.devfreq)) {
DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
devfreq\n");
gpu->devfreq.devfreq = NULL;
+ return;
}
devfreq_suspend_device(gpu->devfreq.devfreq);
+
+ gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
+ gpu->devfreq.devfreq);
+ if (IS_ERR(gpu->cooling)) {
+ DRM_DEV_ERROR(>pdev->dev,
+ "Couldn't register GPU cooling device\n");
+ gpu->cooling = NULL;
+ }
}
static int enable_pwrrail(struct msm_gpu *gpu)
@@ -926,7 +936,6 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
msm_devfreq_init(gpu);
-
gpu->aspace = gpu->funcs->create_address_space(gpu, pdev);
if (gpu->aspace == NULL)
@@ -1005,4 +1014,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
gpu->aspace->mmu->funcs->detach(gpu->aspace->mmu);
msm_gem_address_space_put(gpu->aspace);
}
+
+ devfreq_cooling_unregister(gpu->cooling);
Resources should be released in reverse order, otherwise the cooling device
could use resources that have already been freed.
Why do you think this is not the correct order? If you are thinking
about devfreq struct, it is managed device resource.
-Akhil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: ✓ Fi.CI.IGT: success for rm/i915: Add support for LTTPR non-transparent link training mode (rev2)
On Thu, Oct 08, 2020 at 08:02:09PM +, Patchwork wrote:
> == Series Details ==
>
> Series: rm/i915: Add support for LTTPR non-transparent link training mode
> (rev2)
> URL : https://patchwork.freedesktop.org/series/82449/
> State : success
Thanks for the reviews, patchset is pushed to -dinq.
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_9113_full -> Patchwork_18658_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
>
>
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_18658_full:
>
> ### IGT changes ###
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@gem_exec_capture@pi@vcs0}:
> - shard-skl: NOTRUN -> [INCOMPLETE][1]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18658/shard-skl9/igt@gem_exec_capture@p...@vcs0.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_18658_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_exec_suspend@basic-s0:
> - shard-iclb: [PASS][2] -> [INCOMPLETE][3] ([i915#1090] /
> [i915#1185])
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9113/shard-iclb2/igt@gem_exec_susp...@basic-s0.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18658/shard-iclb3/igt@gem_exec_susp...@basic-s0.html
>
> * igt@gem_huc_copy@huc-copy:
> - shard-tglb: [PASS][4] -> [SKIP][5] ([i915#2190])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9113/shard-tglb7/igt@gem_huc_c...@huc-copy.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18658/shard-tglb6/igt@gem_huc_c...@huc-copy.html
>
> * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup@wc:
> - shard-hsw: [PASS][6] -> [FAIL][7] ([i915#1888]) +1 similar
> issue
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9113/shard-hsw8/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-...@wc.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18658/shard-hsw2/igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-...@wc.html
>
> * igt@i915_pm_dc@dc6-psr:
> - shard-skl: [PASS][8] -> [FAIL][9] ([i915#454])
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9113/shard-skl7/igt@i915_pm...@dc6-psr.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18658/shard-skl10/igt@i915_pm...@dc6-psr.html
>
> * igt@kms_cursor_legacy@cursor-vs-flip-toggle:
> - shard-hsw: [PASS][10] -> [FAIL][11] ([i915#2370])
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9113/shard-hsw2/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18658/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html
>
> * igt@kms_draw_crc@draw-method-rgb565-render-untiled:
> - shard-skl: [PASS][12] -> [FAIL][13] ([i915#52] / [i915#54])
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9113/shard-skl2/igt@kms_draw_...@draw-method-rgb565-render-untiled.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18658/shard-skl8/igt@kms_draw_...@draw-method-rgb565-render-untiled.html
>
> * igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-untiled:
> - shard-snb: [PASS][14] -> [SKIP][15] ([fdo#109271])
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9113/shard-snb4/igt@kms_draw_...@draw-method-xrgb2101010-pwrite-untiled.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18658/shard-snb2/igt@kms_draw_...@draw-method-xrgb2101010-pwrite-untiled.html
>
> * igt@kms_flip@flip-vs-blocking-wf-vblank@a-dp1:
> - shard-kbl: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) +1
> similar issue
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9113/shard-kbl1/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-dp1.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18658/shard-kbl6/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-dp1.html
>
> * igt@kms_flip@flip-vs-blocking-wf-vblank@a-edp1:
> - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1982]) +5
> similar issues
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9113/shard-skl7/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-edp1.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18658/shard-skl5/igt@kms_flip@flip-vs-blocking-wf-vbl...@a-edp1.html
>
> * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1:
> - shard-skl: [PASS][20] -> [FAIL][21] ([i915#79])
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9113/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-edp1.html
>[21]:
>
Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly
On 10/10, Daniel Vetter wrote: > The only thing we support is xrgb. > > Signed-off-by: Daniel Vetter > Cc: Rodrigo Siqueira > Cc: Melissa Wen > Cc: Haneen Mohammed > Cc: Daniel Vetter > --- > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c > index 726801ab44d4..eb4007443706 100644 > --- a/drivers/gpu/drm/vkms/vkms_drv.c > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev) > dev->mode_config.max_height = YRES_MAX; > dev->mode_config.cursor_width = 512; > dev->mode_config.cursor_height = 512; > - dev->mode_config.preferred_depth = 24; > + dev->mode_config.preferred_depth = 32; nice catch! > dev->mode_config.helper_private = _mode_config_helpers; > > return vkms_output_init(vkmsdev, 0); > -- > 2.28.0 > Thanks, Reviewed-by: Melissa Wen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "video: fbdev: amba-clcd: Retire elder CLCD driver"
On 30/09/2020 11:43, Daniel Vetter wrote: > On Tue, Sep 29, 2020 at 01:51:36PM -0700, Peter Collingbourne wrote: >> On Tue, Sep 29, 2020 at 11:44 AM Daniel Vetter wrote: >>> >>> On Tue, Sep 29, 2020 at 7:49 PM Peter Collingbourne wrote: On Tue, Sep 29, 2020 at 9:52 AM Daniel Vetter wrote: > > On Tue, Sep 29, 2020 at 06:48:28PM +0200, Daniel Vetter wrote: >> On Tue, Sep 29, 2020 at 09:30:08AM -0700, Peter Collingbourne wrote: >>> On Tue, Sep 29, 2020 at 2:32 AM Daniel Vetter wrote: On Tue, Sep 29, 2020 at 09:28:56AM +0200, Neil Armstrong wrote: > Hi, > > On 28/09/2020 22:08, Peter Collingbourne wrote: >> Also revert the follow-up change "drm: pl111: Absorb the external >> register header". >> >> This reverts commits 7e4e589db76a3cf4c1f534eb5a09cc6422766b93 >> and 0fb8125635e8eb5483fb095f98dcf0651206a7b8. >> >> The fbdev driver is used by Android's FVP configuration. Using the >> DRM driver together with DRM's fbdev emulation results in a failure >> to boot Android. The root cause is that Android's generic fbdev >> userspace driver relies on the ability to set the pixel format via >> FBIOPUT_VSCREENINFO, which is not supported by fbdev emulation. > > Can't Android FVP use drm-hwcomposer instead ? >>> >>> Not without kernel changes. See e.g. >>> https://www.spinics.net/lists/dri-devel/msg255883.html >> >> That discussion seems to have died down with no further action. >> >> I also was kinda under the assumption that with Android these buffers >> would be allocated directly from dma-buf heaps/ion, so this all seems not >> that well baked out. The disagreement about whether these allocations should be made via the render node or via dma-buf/ion is one reason why it was hard to make progress on this, unfortunately. >>> >>> Yeah, using dumb buffer create to allocate random buffers for shared >>> software rendering isn't super popular move. >>> >>> But aside from all this, why is this blocking the migration from fbdev >>> to drm? With fbdev you don't have buffer allocations, nor dma-buf >>> support, and somehow android can boot. But on drm you can't boot if >>> these things are not available. That sounds like the bar for drm is >>> maybe a tad too high for simple dumb kms drivers like pl which are >>> just there to get a picture on the screen/panel. >> >> I would not intend to use dumb buffer create to allocate >> non-framebuffer-destined buffers for software rendering. >> >> With the generic fbdev driver any allocations not destined for the >> framebuffer use ashmem, which is how the driver avoids making huge >> allocations in fbdev space. I would intend to do something similar for >> DRM where framebuffer-destined allocations use dumb buffer create and >> non-framebuffer-destined allocations use dma-buf. At the time I >> prototyped this approach on the Android side [1] and together with my >> render-nodes-everywhere patch and some other hopefully-uncontroversial >> changes it worked and let me boot to the home screen. I would be very >> happy if this approach were allowed on render nodes so that Android >> FVP would be unblocked from moving off fbdev, but at the point where >> we left the thread off last time you weren't sure whether it would be >> acceptable [2]. >> >> One thing that I might not have mentioned on the thread last time was >> that render nodes have the advantage that unlike primary nodes, >> opening them does not take master if it is not already taken. This >> means that on Android, using primary nodes instead of render nodes in >> the process responsible for creating frame buffers creates a startup >> race condition for master between the hwcomposer process (which >> normally opens the primary node and is responsible for flipping >> frames) and the surfaceflinger process (which normally opens the >> render node and is responsible for drawing onto the framebuffer and >> exporting its frames to the composer). > > I still don't get how this works with fbdev, how do applications render > directly into the fbdev memory (when that's the target)? How is that fbdev > memory shared with them? I suspect they are users of the DRM_FBDEV_LEAK_PHYS_SMEM option... > > Since if the memory shared there isn't really a functional regression, > even if we haven't yet solved the "how can clients allocate > scanout-capable memory for simple displays" issue. Neil > -Daniel > >> >> Peter >> >> [1] >> https://chromium-review.googlesource.com/c/chromiumos/platform/minigbm/+/2438955 >> [2] https://www.spinics.net/lists/dri-devel/msg256559.html >> >>> -Daniel >>> Also, if we need to add more random fbdev ioctls to the drm fbdev emulation, then let's do that. Not keep fbdev drivers on life support for longer than necessary. >>> >>> That
Re: [PATCH 3/3] drm/vkms: fbdev emulation support
Hi, On 12/10/2020 13:24, Thomas Zimmermann wrote: > Hi > > On Sat, 10 Oct 2020 01:21:56 +0200 Daniel Vetter > wrote: > >> Hooray for generic fbdev support, making this a oneliner. We just >> needed to fix preferred_depth fixed and the vmap support added first. >> >> Signed-off-by: Daniel Vetter >> Cc: Rodrigo Siqueira >> Cc: Melissa Wen >> Cc: Haneen Mohammed >> Cc: Daniel Vetter >> --- >> drivers/gpu/drm/vkms/vkms_drv.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c >> b/drivers/gpu/drm/vkms/vkms_drv.c >> index 6221e5040264..cc09e2df5cb1 100644 >> --- a/drivers/gpu/drm/vkms/vkms_drv.c >> +++ b/drivers/gpu/drm/vkms/vkms_drv.c >> @@ -169,6 +169,8 @@ static int __init vkms_init(void) >> if (ret) >> goto out_devres; >> >> +drm_fbdev_generic_setup(_device->drm, 0); >> + > > It feels strange to have console support in a driver for non-interactive > systems. But OK, why not. I guess it helps with testing? It's weird because it the kernel is misconfigured and no console is specified on the cmdline this console could become the main console... It's a great feature, but couldn't this be a module parameter ? Neil > > Acked-by: Thomas Zimmermann > > Best regards > Thomas > >> return 0; >> >> out_devres: > > ___ > 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 2/3] drm/vkms: Switch to shmem helpers
Hi Daniel,
Thanks for this patch.
It took me a while to understand the update.
I run some tests and it looks good to me.
On 10/10, Daniel Vetter wrote:
> Inspired by a patch by Chris Wilson for vgem. Plus this gives us vmap
> at the gem bo level, which we need for generic fbdev emulation.
>
> Luckily shmem also tracks ->vaddr, so we just need to adjust the code
> all over a bit to make this fit.
>
> Also wire up handle_to_fd, dunno why that was missing.
>
> Signed-off-by: Daniel Vetter
> Cc: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Melissa Wen
> Cc: Haneen Mohammed
> ---
> drivers/gpu/drm/Kconfig | 1 +
> drivers/gpu/drm/vkms/Makefile | 1 -
> drivers/gpu/drm/vkms/vkms_composer.c | 17 +-
> drivers/gpu/drm/vkms/vkms_drv.c | 19 +-
> drivers/gpu/drm/vkms/vkms_drv.h | 26 ---
> drivers/gpu/drm/vkms/vkms_gem.c | 261 --
> drivers/gpu/drm/vkms/vkms_plane.c | 13 +-
> drivers/gpu/drm/vkms/vkms_writeback.c | 17 +-
> 8 files changed, 32 insertions(+), 323 deletions(-)
> delete mode 100644 drivers/gpu/drm/vkms/vkms_gem.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 9efb82caaa87..b796c118fc3b 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -287,6 +287,7 @@ config DRM_VKMS
> tristate "Virtual KMS (EXPERIMENTAL)"
> depends on DRM
> select DRM_KMS_HELPER
> + select DRM_GEM_SHMEM_HELPER
> select CRC32
> default n
> help
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index 333d3cead0e3..72f779cbfedd 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -4,7 +4,6 @@ vkms-y := \
> vkms_plane.o \
> vkms_output.o \
> vkms_crtc.o \
> - vkms_gem.o \
> vkms_composer.o \
> vkms_writeback.o
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 33c031f27c2c..66c6842d70db 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "vkms_drv.h"
> @@ -129,15 +130,15 @@ static void compose_cursor(struct vkms_composer
> *cursor_composer,
> void *vaddr_out)
> {
> struct drm_gem_object *cursor_obj;
> - struct vkms_gem_object *cursor_vkms_obj;
> + struct drm_gem_shmem_object *cursor_shmem_obj;
>
> cursor_obj = drm_gem_fb_get_obj(_composer->fb, 0);
> - cursor_vkms_obj = drm_gem_to_vkms_gem(cursor_obj);
> + cursor_shmem_obj = to_drm_gem_shmem_obj(cursor_obj);
>
> - if (WARN_ON(!cursor_vkms_obj->vaddr))
> + if (WARN_ON(!cursor_shmem_obj->vaddr))
> return;
>
> - blend(vaddr_out, cursor_vkms_obj->vaddr,
> + blend(vaddr_out, cursor_shmem_obj->vaddr,
> primary_composer, cursor_composer);
> }
>
> @@ -147,20 +148,20 @@ static int compose_planes(void **vaddr_out,
> {
> struct drm_framebuffer *fb = _composer->fb;
> struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> - struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(gem_obj);
> + struct drm_gem_shmem_object *shmem_obj = to_drm_gem_shmem_obj(gem_obj);
>
> if (!*vaddr_out) {
> - *vaddr_out = kzalloc(vkms_obj->gem.size, GFP_KERNEL);
> + *vaddr_out = kzalloc(shmem_obj->base.size, GFP_KERNEL);
> if (!*vaddr_out) {
> DRM_ERROR("Cannot allocate memory for output frame.");
> return -ENOMEM;
> }
> }
>
> - if (WARN_ON(!vkms_obj->vaddr))
> + if (WARN_ON(!shmem_obj->vaddr))
> return -EINVAL;
>
> - memcpy(*vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
> + memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
>
> if (cursor_composer)
> compose_cursor(cursor_composer, primary_composer, *vaddr_out);
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index eb4007443706..6221e5040264 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "vkms_drv.h"
> @@ -39,17 +40,7 @@ bool enable_cursor = true;
> module_param_named(enable_cursor, enable_cursor, bool, 0444);
> MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
>
> -static const struct file_operations vkms_driver_fops = {
> - .owner = THIS_MODULE,
> - .open = drm_open,
> - .mmap = drm_gem_mmap,
> - .unlocked_ioctl = drm_ioctl,
> - .compat_ioctl = drm_compat_ioctl,
> - .poll = drm_poll,
> - .read = drm_read,
> -
Re: [PATCH 1/4] drm/vc4: kms: Split the HVS muxing check in a separate function
Hi Maxime,
On 10/8/20 8:25 PM, Maxime Ripard wrote:
> The code that assigns HVS channels during atomic_check is starting to grow
> a bit big, let's move it into a separate function.
>
> Signed-off-by: Maxime Ripard
Thanks for this patch set, I checked all patches well works.
All patches:
Reviewed-by: Hoegeun Kwon
Tested-by: Hoegeun Kwon
Best regards,
Hoegeun
> ---
> drivers/gpu/drm/vc4/vc4_kms.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 149825ff5df8..846fe8b3cb7a 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -612,13 +612,13 @@ static const struct drm_private_state_funcs
> vc4_load_tracker_state_funcs = {
> #define NUM_OUTPUTS 6
> #define NUM_CHANNELS 3
>
> -static int
> -vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
> +static int vc4_pv_muxing_atomic_check(struct drm_device *dev,
> + struct drm_atomic_state *state)
> {
> unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
> struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> struct drm_crtc *crtc;
> - int i, ret;
> + unsigned int i;
>
> /*
>* Since the HVS FIFOs are shared across all the pixelvalves and
> @@ -691,6 +691,18 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> }
> }
>
> + return 0;
> +}
> +
> +static int
> +vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
> +{
> + int ret;
> +
> + ret = vc4_pv_muxing_atomic_check(dev, state);
> + if (ret)
> + return ret;
> +
> ret = vc4_ctm_atomic_check(dev, state);
> if (ret < 0)
> return ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] mm: introduce vma_set_file function v4
Hi "Christian, I love your patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on staging/staging-testing linus/master v5.9 next-20201009] [cannot apply to mmotm/master] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Christian-K-nig/mm-mmap-fix-fput-in-error-path-v2/20201012-165336 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: arm-randconfig-r025-20201012 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 9e72d3eaf38f217698f72cb8fdc969a6e72dad3a) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install arm cross compiling tool for clang build # apt-get install binutils-arm-linux-gnueabi # https://github.com/0day-ci/linux/commit/4ff869f185acba6d9c37ab6abdb0d9f93f31d15b git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Christian-K-nig/mm-mmap-fix-fput-in-error-path-v2/20201012-165336 git checkout 4ff869f185acba6d9c37ab6abdb0d9f93f31d15b # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> ld.lld: error: undefined symbol: vma_set_file >>> referenced by dma-buf.c >>> dma-buf/dma-buf.o:(dma_buf_mmap) in archive drivers/built-in.a --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu/drm/armada: fix unused parameter warning
On Mon, Oct 12, 2020 at 04:57:24AM -0700, Bernard Zhao wrote:
> Functions armada_drm_crtc_atomic_flush &
> armada_drm_crtc_atomic_enable don`t use the second parameter.
> So we may get warning like :
> warning: unused parameter ‘***’ [-Wunused-parameter].
> This change is to fix the compile warning with -Wunused-parameter.
Under what circumstances do we build the kernel with that warning
enabled?
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/armada/armada_crtc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c
> b/drivers/gpu/drm/armada/armada_crtc.c
> index 38dfaa46d306..fc8b922c3e44 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -427,7 +427,7 @@ static int armada_drm_crtc_atomic_check(struct drm_crtc
> *crtc,
> }
>
> static void armada_drm_crtc_atomic_begin(struct drm_crtc *crtc,
> - struct drm_crtc_state *old_crtc_state)
> + struct drm_crtc_state __attribute__((unused))
> *old_crtc_state)
> {
> struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
>
> @@ -441,7 +441,7 @@ static void armada_drm_crtc_atomic_begin(struct drm_crtc
> *crtc,
> }
>
> static void armada_drm_crtc_atomic_flush(struct drm_crtc *crtc,
> - struct drm_crtc_state *old_crtc_state)
> + struct drm_crtc_state __attribute__((unused))
> *old_crtc_state)
> {
> struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
>
> --
> 2.28.0
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vkms: fbdev emulation support
Hi On Sat, 10 Oct 2020 01:21:56 +0200 Daniel Vetter wrote: > Hooray for generic fbdev support, making this a oneliner. We just > needed to fix preferred_depth fixed and the vmap support added first. > > Signed-off-by: Daniel Vetter > Cc: Rodrigo Siqueira > Cc: Melissa Wen > Cc: Haneen Mohammed > Cc: Daniel Vetter > --- > drivers/gpu/drm/vkms/vkms_drv.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c > index 6221e5040264..cc09e2df5cb1 100644 > --- a/drivers/gpu/drm/vkms/vkms_drv.c > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > @@ -169,6 +169,8 @@ static int __init vkms_init(void) > if (ret) > goto out_devres; > > + drm_fbdev_generic_setup(_device->drm, 0); > + It feels strange to have console support in a driver for non-interactive systems. But OK, why not. I guess it helps with testing? Acked-by: Thomas Zimmermann Best regards Thomas > return 0; > > out_devres: ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/vkms: Switch to shmem helpers
On Sat, 10 Oct 2020 01:21:55 +0200 Daniel Vetter
wrote:
> Inspired by a patch by Chris Wilson for vgem. Plus this gives us vmap
> at the gem bo level, which we need for generic fbdev emulation.
>
> Luckily shmem also tracks ->vaddr, so we just need to adjust the code
> all over a bit to make this fit.
>
> Also wire up handle_to_fd, dunno why that was missing.
>
> Signed-off-by: Daniel Vetter
> Cc: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Melissa Wen
> Cc: Haneen Mohammed
> ---
> drivers/gpu/drm/Kconfig | 1 +
> drivers/gpu/drm/vkms/Makefile | 1 -
> drivers/gpu/drm/vkms/vkms_composer.c | 17 +-
> drivers/gpu/drm/vkms/vkms_drv.c | 19 +-
> drivers/gpu/drm/vkms/vkms_drv.h | 26 ---
> drivers/gpu/drm/vkms/vkms_gem.c | 261 --
> drivers/gpu/drm/vkms/vkms_plane.c | 13 +-
> drivers/gpu/drm/vkms/vkms_writeback.c | 17 +-
> 8 files changed, 32 insertions(+), 323 deletions(-)
Nice :)
> delete mode 100644 drivers/gpu/drm/vkms/vkms_gem.c
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 9efb82caaa87..b796c118fc3b 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -287,6 +287,7 @@ config DRM_VKMS
> tristate "Virtual KMS (EXPERIMENTAL)"
> depends on DRM
> select DRM_KMS_HELPER
> + select DRM_GEM_SHMEM_HELPER
> select CRC32
> default n
> help
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index 333d3cead0e3..72f779cbfedd 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -4,7 +4,6 @@ vkms-y := \
> vkms_plane.o \
> vkms_output.o \
> vkms_crtc.o \
> - vkms_gem.o \
> vkms_composer.o \
> vkms_writeback.o
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 33c031f27c2c..66c6842d70db 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "vkms_drv.h"
> @@ -129,15 +130,15 @@ static void compose_cursor(struct vkms_composer
> *cursor_composer,
> void *vaddr_out)
> {
> struct drm_gem_object *cursor_obj;
> - struct vkms_gem_object *cursor_vkms_obj;
> + struct drm_gem_shmem_object *cursor_shmem_obj;
>
> cursor_obj = drm_gem_fb_get_obj(_composer->fb, 0);
> - cursor_vkms_obj = drm_gem_to_vkms_gem(cursor_obj);
> + cursor_shmem_obj = to_drm_gem_shmem_obj(cursor_obj);
>
> - if (WARN_ON(!cursor_vkms_obj->vaddr))
> + if (WARN_ON(!cursor_shmem_obj->vaddr))
> return;
>
> - blend(vaddr_out, cursor_vkms_obj->vaddr,
> + blend(vaddr_out, cursor_shmem_obj->vaddr,
> primary_composer, cursor_composer);
> }
>
> @@ -147,20 +148,20 @@ static int compose_planes(void **vaddr_out,
> {
> struct drm_framebuffer *fb = _composer->fb;
> struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> - struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(gem_obj);
> + struct drm_gem_shmem_object *shmem_obj = to_drm_gem_shmem_obj(gem_obj);
>
> if (!*vaddr_out) {
> - *vaddr_out = kzalloc(vkms_obj->gem.size, GFP_KERNEL);
> + *vaddr_out = kzalloc(shmem_obj->base.size, GFP_KERNEL);
> if (!*vaddr_out) {
> DRM_ERROR("Cannot allocate memory for output frame.");
> return -ENOMEM;
> }
> }
>
> - if (WARN_ON(!vkms_obj->vaddr))
> + if (WARN_ON(!shmem_obj->vaddr))
> return -EINVAL;
>
> - memcpy(*vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
> + memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
>
> if (cursor_composer)
> compose_cursor(cursor_composer, primary_composer, *vaddr_out);
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index eb4007443706..6221e5040264 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "vkms_drv.h"
> @@ -39,17 +40,7 @@ bool enable_cursor = true;
> module_param_named(enable_cursor, enable_cursor, bool, 0444);
> MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
>
> -static const struct file_operations vkms_driver_fops = {
> - .owner = THIS_MODULE,
> - .open = drm_open,
> - .mmap = drm_gem_mmap,
> - .unlocked_ioctl = drm_ioctl,
> - .compat_ioctl = drm_compat_ioctl,
> - .poll = drm_poll,
> - .read = drm_read,
> - .llseek = no_llseek,
> - .release= drm_release,
> -};
>
Re: [PATCH 2/3] drm/vkms: Switch to shmem helpers
On Mon, 12 Oct 2020 11:59:03 +0100 Chris Wilson
wrote:
> Quoting Daniel Vetter (2020-10-10 00:21:55)
> > Inspired by a patch by Chris Wilson for vgem. Plus this gives us vmap
> > at the gem bo level, which we need for generic fbdev emulation.
> >
> > Luckily shmem also tracks ->vaddr, so we just need to adjust the code
> > all over a bit to make this fit.
> >
> > Also wire up handle_to_fd, dunno why that was missing.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Chris Wilson
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Rodrigo Siqueira
> > Cc: Melissa Wen
> > Cc: Haneen Mohammed
> > ---
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index 33c031f27c2c..66c6842d70db 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -5,6 +5,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
>
> > static void vkms_release(struct drm_device *dev)
> > {
> > @@ -91,9 +82,11 @@ static struct drm_driver vkms_driver = {
> > .driver_features= DRIVER_MODESET | DRIVER_ATOMIC |
> > DRIVER_GEM,
> > .release= vkms_release,
> > .fops = _driver_fops,
> > - .dumb_create= vkms_dumb_create,
> > + .dumb_create= drm_gem_shmem_dumb_create,
>
> Something worth pointing out is that will create an uncached (well WC)
> buffer, but since it is being exported with prime, that is probably for
I'd rather set .gem_create_object to drm_gem_shmem_create_object_cached() to
get cached memory. We already have other drivers that do this.
Best regards
Thomas
> the better. It might be worth using a memcpy_from_wc() for writeback/CRC
> calculations. E.g.
>
> > @@ -129,15 +130,15 @@ static void compose_cursor(struct vkms_composer
> > *cursor_composer,
> >void *vaddr_out)
> > {
> > + blend(vaddr_out, cursor_shmem_obj->vaddr,
> > primary_composer, cursor_composer);
> > }
> >
> > @@ -147,20 +148,20 @@ static int compose_planes(void **vaddr_out,
> > {
> > + memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
>
> would benefit from WC accessors.
>
> On the other hand, if the load is so small no one notices, it can wait.
>
> Do we have anything that uses vkms in CI?
>
> Reviewed-by: Chris Wilson
> -Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly
On Sat, 10 Oct 2020 01:21:54 +0200 Daniel Vetter wrote: > The only thing we support is xrgb. > > Signed-off-by: Daniel Vetter > Cc: Rodrigo Siqueira > Cc: Melissa Wen > Cc: Haneen Mohammed > Cc: Daniel Vetter Acked-by: Thomas Zimmermann > --- > drivers/gpu/drm/vkms/vkms_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c > index 726801ab44d4..eb4007443706 100644 > --- a/drivers/gpu/drm/vkms/vkms_drv.c > +++ b/drivers/gpu/drm/vkms/vkms_drv.c > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev) > dev->mode_config.max_height = YRES_MAX; > dev->mode_config.cursor_width = 512; > dev->mode_config.cursor_height = 512; > - dev->mode_config.preferred_depth = 24; > + dev->mode_config.preferred_depth = 32; > dev->mode_config.helper_private = _mode_config_helpers; > > return vkms_output_init(vkmsdev, 0); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/vkms: Switch to shmem helpers
Quoting Daniel Vetter (2020-10-10 00:21:55)
> Inspired by a patch by Chris Wilson for vgem. Plus this gives us vmap
> at the gem bo level, which we need for generic fbdev emulation.
>
> Luckily shmem also tracks ->vaddr, so we just need to adjust the code
> all over a bit to make this fit.
>
> Also wire up handle_to_fd, dunno why that was missing.
>
> Signed-off-by: Daniel Vetter
> Cc: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Rodrigo Siqueira
> Cc: Melissa Wen
> Cc: Haneen Mohammed
> ---
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 33c031f27c2c..66c6842d70db 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
> #include
> static void vkms_release(struct drm_device *dev)
> {
> @@ -91,9 +82,11 @@ static struct drm_driver vkms_driver = {
> .driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
> .release= vkms_release,
> .fops = _driver_fops,
> - .dumb_create= vkms_dumb_create,
> + .dumb_create= drm_gem_shmem_dumb_create,
Something worth pointing out is that will create an uncached (well WC)
buffer, but since it is being exported with prime, that is probably for
the better. It might be worth using a memcpy_from_wc() for writeback/CRC
calculations. E.g.
> @@ -129,15 +130,15 @@ static void compose_cursor(struct vkms_composer
> *cursor_composer,
>void *vaddr_out)
> {
> + blend(vaddr_out, cursor_shmem_obj->vaddr,
> primary_composer, cursor_composer);
> }
>
> @@ -147,20 +148,20 @@ static int compose_planes(void **vaddr_out,
> {
> + memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
would benefit from WC accessors.
On the other hand, if the load is so small no one notices, it can wait.
Do we have anything that uses vkms in CI?
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/vgem: Replace vgem_object_funcs with the common drm shmem helper
vgem is a minimalistic driver that provides shmemfs objects to
userspace that may then be used as an in-memory surface and transported
across dma-buf to other drivers. Since vgem's introduction,
drm_gem_shmem_helper now provides the same shmemfs facilities and so we
can trim vgem to wrap the helper.
v2: The gem prime mmap helper does not handle exchanging the vma->file,
so skip the conversion to the common prime helper and leave the patch
only converting to the common shmem helper.
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter #v1
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/vgem/vgem_drv.c | 284 +++-
drivers/gpu/drm/vgem/vgem_drv.h | 11 --
3 files changed, 25 insertions(+), 271 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 147d61b9674e..db2ff76638cd 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -278,6 +278,7 @@ source "drivers/gpu/drm/i915/Kconfig"
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
+ select DRM_GEM_SHMEM_HELPER
help
Choose this option to get a virtual graphics memory manager,
as used by Mesa's software renderer for enhanced performance.
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index f38dd590fa45..6811ac518509 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -38,6 +38,7 @@
#include
#include
+#include
#include
#include
#include
@@ -50,87 +51,11 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static const struct drm_gem_object_funcs vgem_gem_object_funcs;
-
static struct vgem_device {
struct drm_device drm;
struct platform_device *platform;
} *vgem_device;
-static void vgem_gem_free_object(struct drm_gem_object *obj)
-{
- struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
-
- kvfree(vgem_obj->pages);
- mutex_destroy(_obj->pages_lock);
-
- if (obj->import_attach)
- drm_prime_gem_destroy(obj, vgem_obj->table);
-
- drm_gem_object_release(obj);
- kfree(vgem_obj);
-}
-
-static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
-{
- struct vm_area_struct *vma = vmf->vma;
- struct drm_vgem_gem_object *obj = vma->vm_private_data;
- /* We don't use vmf->pgoff since that has the fake offset */
- unsigned long vaddr = vmf->address;
- vm_fault_t ret = VM_FAULT_SIGBUS;
- loff_t num_pages;
- pgoff_t page_offset;
- page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
-
- num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
-
- if (page_offset >= num_pages)
- return VM_FAULT_SIGBUS;
-
- mutex_lock(>pages_lock);
- if (obj->pages) {
- get_page(obj->pages[page_offset]);
- vmf->page = obj->pages[page_offset];
- ret = 0;
- }
- mutex_unlock(>pages_lock);
- if (ret) {
- struct page *page;
-
- page = shmem_read_mapping_page(
- file_inode(obj->base.filp)->i_mapping,
- page_offset);
- if (!IS_ERR(page)) {
- vmf->page = page;
- ret = 0;
- } else switch (PTR_ERR(page)) {
- case -ENOSPC:
- case -ENOMEM:
- ret = VM_FAULT_OOM;
- break;
- case -EBUSY:
- ret = VM_FAULT_RETRY;
- break;
- case -EFAULT:
- case -EINVAL:
- ret = VM_FAULT_SIGBUS;
- break;
- default:
- WARN_ON(PTR_ERR(page));
- ret = VM_FAULT_SIGBUS;
- break;
- }
-
- }
- return ret;
-}
-
-static const struct vm_operations_struct vgem_gem_vm_ops = {
- .fault = vgem_gem_fault,
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
static int vgem_open(struct drm_device *dev, struct drm_file *file)
{
struct vgem_file *vfile;
@@ -159,33 +84,15 @@ static void vgem_postclose(struct drm_device *dev, struct
drm_file *file)
kfree(vfile);
}
-static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
- unsigned long size)
+static struct drm_gem_shmem_object *__vgem_gem_create(struct drm_device *dev,
+ unsigned long size)
{
- struct drm_vgem_gem_object *obj;
- int ret;
-
- obj = kzalloc(sizeof(*obj), GFP_KERNEL);
- if (!obj)
- return ERR_PTR(-ENOMEM);
-
- obj->base.funcs =
[PATCH 1/2] drm: Ask whether drm_gem_get_pages() should clear the CPU cache
On some processors (such as arch/x86), accessing a page via a WC PAT is
bypassed if the page is physically tagged in the CPU cache, and the
access is serviced by the cache instead -- which leads to incoherency
should the physical page itself be accessed using DMA. In order to
prevent the false cache sharing of the physical pages, we need to
explicitly flush the cache lines of those pages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c | 8 ++--
drivers/gpu/drm/drm_gem_shmem_helper.c | 8 +++-
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 2 +-
drivers/gpu/drm/gma500/gtt.c| 2 +-
drivers/gpu/drm/msm/msm_gem.c | 2 +-
drivers/gpu/drm/omapdrm/omap_gem.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
drivers/gpu/drm/tegra/gem.c | 2 +-
drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
drivers/gpu/drm/vkms/vkms_gem.c | 2 +-
drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
include/drm/drm_gem.h | 2 +-
12 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1da67d34e55d..1948855d69e6 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -40,6 +40,7 @@
#include
#include
+#include
#include
#include
#include
@@ -525,6 +526,7 @@ static void drm_gem_check_release_pagevec(struct pagevec
*pvec)
* drm_gem_get_pages - helper to allocate backing pages for a GEM object
* from shmem
* @obj: obj in question
+ * @clflush: whether to clear any CPU caches associated with the backing store
*
* This reads the page-array of the shmem-backing storage of the given gem
* object. An array of pages is returned. If a page is not allocated or
@@ -546,14 +548,13 @@ static void drm_gem_check_release_pagevec(struct pagevec
*pvec)
* drm_gem_object_init(), but not for those initialized with
* drm_gem_private_object_init() only.
*/
-struct page **drm_gem_get_pages(struct drm_gem_object *obj)
+struct page **drm_gem_get_pages(struct drm_gem_object *obj, bool clflush)
{
struct address_space *mapping;
struct page *p, **pages;
struct pagevec pvec;
int i, npages;
-
if (WARN_ON(!obj->filp))
return ERR_PTR(-EINVAL);
@@ -589,6 +590,9 @@ struct page **drm_gem_get_pages(struct drm_gem_object *obj)
(page_to_pfn(p) >= 0x0010UL));
}
+ if (clflush)
+ drm_clflush_pages(pages, npages);
+
return pages;
fail:
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index fb11df7aced5..78a2eb77802b 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -152,7 +152,13 @@ static int drm_gem_shmem_get_pages_locked(struct
drm_gem_shmem_object *shmem)
if (shmem->pages_use_count++ > 0)
return 0;
- pages = drm_gem_get_pages(obj);
+ /*
+* On some processors (such as arch/x86), accessing a page via a WC PAT
+* is bypassed if the page is physically tagged in the CPU cache, and
+* the access is serviced by the cache instead -- which leads to
+* incoherency should the physical page itself be accessed using DMA.
+*/
+ pages = drm_gem_get_pages(obj, !shmem->map_cached);
if (IS_ERR(pages)) {
DRM_DEBUG_KMS("Failed to get pages (%ld)\n", PTR_ERR(pages));
shmem->pages_use_count = 0;
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 67d9a2b9ea6a..d8279ea363b3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -58,7 +58,7 @@ static void etnaviv_gem_scatterlist_unmap(struct
etnaviv_gem_object *etnaviv_obj
static int etnaviv_gem_shmem_get_pages(struct etnaviv_gem_object *etnaviv_obj)
{
struct drm_device *dev = etnaviv_obj->base.dev;
- struct page **p = drm_gem_get_pages(_obj->base);
+ struct page **p = drm_gem_get_pages(_obj->base, false);
if (IS_ERR(p)) {
dev_dbg(dev->dev, "could not get pages: %ld\n", PTR_ERR(p));
diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 9278bcfad1bf..ada56aec7e68 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -197,7 +197,7 @@ static int psb_gtt_attach_pages(struct gtt_range *gt)
WARN_ON(gt->pages);
- pages = drm_gem_get_pages(>gem);
+ pages = drm_gem_get_pages(>gem, false);
if (IS_ERR(pages))
return PTR_ERR(pages);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index c79828d31822..a7a67ef4e27e 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -102,7 +102,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
int
Re: [Intel-gfx] [PATCH] drm/vgem: Replace vgem_object_funcs with the common drm shmem helper
Quoting Daniel Vetter (2020-10-09 17:16:06) > On Fri, Oct 9, 2020 at 12:21 PM Chris Wilson wrote: > > > > vgem is a minimalistic driver that provides shmemfs objects to > > userspace that may then be used as an in-memory surface and transported > > across dma-buf to other drivers. Since it's introduction, > > drm_gem_shmem_helper now provides the same shmemfs facilities and so we > > can trim vgem to wrap the helper. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/Kconfig | 1 + > > drivers/gpu/drm/vgem/vgem_drv.c | 281 ++-- > > drivers/gpu/drm/vgem/vgem_drv.h | 11 -- > > 3 files changed, 13 insertions(+), 280 deletions(-) > > Nice diffstat :-) > > Reviewed-by: Daniel Vetter Unfortunately I had to drop the drm_gem_prime_mmap() since the existing expectation is that we hand the faulthandler off to shmemfs so we can release the module while the memory is exported. The other issue happens to be for arch/x86 where just setting PAT=WC on the PTE does not flush the cache for that page, and the CPU will preferentially use the cache. That has caught us out more than once. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/17] mm: Add unsafe_follow_pfn
Hi Jason, On 09.10.2020 14:48, Jason Gunthorpe wrote: > On Fri, Oct 09, 2020 at 02:37:23PM +0200, Mauro Carvalho Chehab wrote: > >> I'm not a mm/ expert, but, from what I understood from Daniel's patch >> description is that this is unsafe *only if* __GFP_MOVABLE is used. > No, it is unconditionally unsafe. The CMA movable mappings are > specific VMAs that will have bad issues here, but there are other > types too. I'm trying to follow this thread, but I really wonder what do you mean by CMA movable mappings? If a buffer has been allocated from CMA and used for DMA, it won't be moved in the memory. It will stay at the same physical memory address all the time until freed by the owner. It just a matter of proper usage count tracking to delay freeing if it is still used somewhere. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] drm/aspeed: fix Kconfig warning & subsequent build errors
kernel test robot reported build errors (undefined references)
that didn't make much sense. After reproducing them, there is also
a Kconfig warning that is the root cause of the build errors, so
fix that Kconfig problem.
Fixes this Kconfig warning:
WARNING: unmet direct dependencies detected for CMA
Depends on [n]: MMU [=n]
Selected by [m]:
- DRM_ASPEED_GFX [=m] && HAS_IOMEM [=y] && DRM [=m] && OF [=y] &&
(COMPILE_TEST [=y] || ARCH_ASPEED) && HAVE_DMA_CONTIGUOUS [=y]
and these dependent build errors:
(.text+0x10c8c): undefined reference to `start_isolate_page_range'
microblaze-linux-ld: (.text+0x10f14): undefined reference to
`test_pages_isolated'
microblaze-linux-ld: (.text+0x10fd0): undefined reference to
`undo_isolate_page_range'
Fixes: 76356a966e33 ("drm: aspeed: Clean up Kconfig options")
Reported-by: kernel test robot
Signed-off-by: Randy Dunlap
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: Daniel Vetter
Cc: Michal Simek
Cc: Andrew Morton
Cc: Mike Rapoport
Cc: linux...@kvack.org
Cc: linux-asp...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
---
First sent on 2020-09-07.
Feel free to fix the Kconfig warning some other way...
drivers/gpu/drm/aspeed/Kconfig |1 +
1 file changed, 1 insertion(+)
--- linux-next-20201009.orig/drivers/gpu/drm/aspeed/Kconfig
+++ linux-next-20201009/drivers/gpu/drm/aspeed/Kconfig
@@ -3,6 +3,7 @@ config DRM_ASPEED_GFX
tristate "ASPEED BMC Display Controller"
depends on DRM && OF
depends on (COMPILE_TEST || ARCH_ASPEED)
+ depends on MMU
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DMA_CMA if HAVE_DMA_CONTIGUOUS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 48/58] drivers/md: Utilize new kmap_thread()
On 2020/10/12 13:28, Ira Weiny wrote: > On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote: >> On 2020/10/10 03:50, ira.we...@intel.com wrote: >>> From: Ira Weiny >>> >>> These kmap() calls are localized to a single thread. To avoid the over >>> head of global PKRS updates use the new kmap_thread() call. >>> >> >> Hi Ira, >> >> There were a number of options considered. >> >> 1) Attempt to change all the thread local kmap() calls to kmap_atomic() >> 2) Introduce a flags parameter to kmap() to indicate if the mapping >> should be global or not >> 3) Change ~20-30 call sites to 'kmap_global()' to indicate that they >> require a global mapping of the pages >> 4) Change ~209 call sites to 'kmap_thread()' to indicate that the >> mapping is to be used within that thread of execution only >> >> >> I copied the above information from patch 00/58 to this message. The >> idea behind kmap_thread() is fine to me, but as you said the new api is >> very easy to be missed in new code (even for me). I would like to be >> supportive to option 2) introduce a flag to kmap(), then we won't forget >> the new thread-localized kmap method, and people won't ask why a >> _thread() function is called but no kthread created. > > Thanks for the feedback. > > I'm going to hold off making any changes until others weigh in. FWIW, I kind > of like option 2 as well. But there is already kmap_atomic() so it seemed > like > kmap_() was more in line with the current API. I understand it now, the idea is fine to me. Acked-by: Coly Li Thanks. Coly Li ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/msm/dp: add opp_table corner voting support base on dp_ink_clk rate
Set link rate by using OPP set rate api so that CX level will be set
accordingly based on the link rate.
Changes in v2:
-- remove dev from dp_ctrl_put() parameters
-- Add more information to commit message
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 27 ++
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
drivers/gpu/drm/msm/dp/dp_power.c | 44 ++---
drivers/gpu/drm/msm/dp/dp_power.h | 2 +-
4 files changed, 69 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 2e3e1917351f..bbd6e63f0c3f 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -76,6 +77,8 @@ struct dp_ctrl_private {
struct dp_parser *parser;
struct dp_catalog *catalog;
+ struct opp_table *opp_table;
+
struct completion idle_comp;
struct completion video_comp;
};
@@ -1836,6 +1839,7 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
struct dp_parser *parser)
{
struct dp_ctrl_private *ctrl;
+ int ret;
if (!dev || !panel || !aux ||
!link || !catalog) {
@@ -1849,6 +1853,20 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
return ERR_PTR(-ENOMEM);
}
+ ctrl->opp_table = dev_pm_opp_set_clkname(dev, "ctrl_link");
+ if (IS_ERR(ctrl->opp_table)) {
+ dev_err(dev, "invalid DP OPP table in device tree\n");
+ ctrl->opp_table = NULL;
+ } else {
+ /* OPP table is optional */
+ ret = dev_pm_opp_of_add_table(dev);
+ if (ret) {
+ dev_err(dev, "failed to add DP OPP table\n");
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
+ }
+
init_completion(>idle_comp);
init_completion(>video_comp);
@@ -1866,4 +1884,13 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev, struct
dp_link *link,
void dp_ctrl_put(struct dp_ctrl *dp_ctrl)
{
+ struct dp_ctrl_private *ctrl;
+
+ ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
+
+ if (ctrl->opp_table) {
+ dev_pm_opp_of_remove_table(ctrl->dev);
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
}
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 2372de2865e6..518778247464 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -688,7 +688,7 @@ static int dp_init_sub_modules(struct dp_display_private
*dp)
goto error;
}
- dp->power = dp_power_get(dp->parser);
+ dp->power = dp_power_get(dev, dp->parser);
if (IS_ERR(dp->power)) {
rc = PTR_ERR(dp->power);
DRM_ERROR("failed to initialize power, rc = %d\n", rc);
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
b/drivers/gpu/drm/msm/dp/dp_power.c
index 17c1fc6a2d44..9c4ea00a5f2a 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -8,12 +8,14 @@
#include
#include
#include
+#include
#include "dp_power.h"
#include "msm_drv.h"
struct dp_power_private {
struct dp_parser *parser;
struct platform_device *pdev;
+ struct device *dev;
struct clk *link_clk_src;
struct clk *pixel_provider;
struct clk *link_provider;
@@ -148,18 +150,51 @@ static int dp_power_clk_deinit(struct dp_power_private
*power)
return 0;
}
+static int dp_power_clk_set_link_rate(struct dp_power_private *power,
+ struct dss_clk *clk_arry, int num_clk, int enable)
+{
+ u32 rate;
+ int i, rc = 0;
+
+ for (i = 0; i < num_clk; i++) {
+ if (clk_arry[i].clk) {
+ if (clk_arry[i].type == DSS_CLK_PCLK) {
+ if (enable)
+ rate = clk_arry[i].rate;
+ else
+ rate = 0;
+
+ rc = dev_pm_opp_set_rate(power->dev, rate);
+ if (rc)
+ break;
+ }
+
+ }
+ }
+ return rc;
+}
+
static int dp_power_clk_set_rate(struct dp_power_private *power,
enum dp_pm_type module, bool enable)
{
int rc = 0;
struct dss_module_power *mp = >parser->mp[module];
- if (enable) {
- rc = msm_dss_clk_set_rate(mp->clk_config, mp->num_clk);
+ if (module == DP_CTRL_PM) {
+ rc = dp_power_clk_set_link_rate(power, mp->clk_config,
mp->num_clk, enable);
[PATCH v2] drm/msm/dp: fixes wrong connection state caused by failure of link train
Connection state is not set correctly happen when either failure of link
train due to cable unplugged in the middle of aux channel reading or
cable plugged in while in suspended state. This patch fixes these problems.
This patch also replace ST_SUSPEND_PENDING with ST_DISPLAY_OFF.
Changes in V2:
-- Add more information to commit message.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 43 +++--
drivers/gpu/drm/msm/dp/dp_panel.c | 5
2 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index fd16e12ab2f8..2372de2865e6 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -45,7 +45,7 @@ enum {
ST_CONNECT_PENDING,
ST_CONNECTED,
ST_DISCONNECT_PENDING,
- ST_SUSPEND_PENDING,
+ ST_DISPLAY_OFF,
ST_SUSPENDED,
};
@@ -489,7 +489,7 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
mutex_lock(>event_mutex);
state = dp->hpd_state;
- if (state == ST_SUSPEND_PENDING) {
+ if (state == ST_DISPLAY_OFF || state == ST_SUSPENDED) {
mutex_unlock(>event_mutex);
return 0;
}
@@ -511,14 +511,14 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
hpd->hpd_high = 1;
ret = dp_display_usbpd_configure_cb(>pdev->dev);
- if (ret) { /* failed */
+ if (ret) { /* link train failed */
hpd->hpd_high = 0;
dp->hpd_state = ST_DISCONNECTED;
+ } else {
+ /* start sentinel checking in case of missing uevent */
+ dp_add_event(dp, EV_CONNECT_PENDING_TIMEOUT, 0, tout);
}
- /* start sanity checking */
- dp_add_event(dp, EV_CONNECT_PENDING_TIMEOUT, 0, tout);
-
mutex_unlock(>event_mutex);
/* uevent will complete connection part */
@@ -563,11 +563,6 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
mutex_lock(>event_mutex);
state = dp->hpd_state;
- if (state == ST_SUSPEND_PENDING) {
- mutex_unlock(>event_mutex);
- return 0;
- }
-
if (state == ST_DISCONNECT_PENDING || state == ST_DISCONNECTED) {
mutex_unlock(>event_mutex);
return 0;
@@ -594,7 +589,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
*/
dp_display_usbpd_disconnect_cb(>pdev->dev);
- /* start sanity checking */
+ /* 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 */
@@ -634,7 +629,7 @@ static int dp_irq_hpd_handle(struct dp_display_private *dp,
u32 data)
/* irq_hpd can happen at either connected or disconnected state */
state = dp->hpd_state;
- if (state == ST_SUSPEND_PENDING) {
+ if (state == ST_DISPLAY_OFF) {
mutex_unlock(>event_mutex);
return 0;
}
@@ -1067,7 +1062,7 @@ static irqreturn_t dp_display_irq_handler(int irq, void
*dev_id)
}
if (hpd_isr_status & DP_DP_IRQ_HPD_INT_MASK) {
- /* delete connect pending event first */
+ /* stop sentinel connect pending checking */
dp_del_event(dp, EV_CONNECT_PENDING_TIMEOUT);
dp_add_event(dp, EV_IRQ_HPD_INT, 0, 0);
}
@@ -1188,19 +1183,19 @@ static int dp_pm_resume(struct device *dev)
mutex_lock(>event_mutex);
+ /* start from disconnected state */
+ dp->hpd_state = ST_DISCONNECTED;
+
dp_display_host_init(dp);
dp_catalog_ctrl_hpd_config(dp->catalog);
status = dp_catalog_hpd_get_state_status(dp->catalog);
- if (status) {
+ if (status)
dp->dp_display.is_connected = true;
- } else {
+ else
dp->dp_display.is_connected = false;
- /* make sure next resume host_init be called */
- dp->core_initialized = false;
- }
mutex_unlock(>event_mutex);
@@ -1222,6 +1217,9 @@ static int dp_pm_suspend(struct device *dev)
dp->hpd_state = ST_SUSPENDED;
+ /* host_init will be called at pm_resume */
+ dp->core_initialized = false;
+
mutex_unlock(>event_mutex);
return 0;
@@ -1351,6 +1349,7 @@ int msm_dp_display_enable(struct msm_dp *dp, struct
drm_encoder *encoder)
mutex_lock(_display->event_mutex);
+ /* stop sentinel checking */
dp_del_event(dp_display, EV_CONNECT_PENDING_TIMEOUT);
rc = dp_display_set_mode(dp, _display->dp_mode);
@@ -1378,7 +1377,8 @@ int msm_dp_display_enable(struct msm_dp *dp, struct
drm_encoder
Re: [PATCH v2] drm/msm/dp: add opp_table corner voting support base on dp_ink_clk rate
On 2020-10-06 00:31, Rajendra Nayak wrote:
On 10/4/2020 3:56 AM, Kuogee Hsieh wrote:
Set link rate by using OPP set rate api so that CX level will be set
accordingly based on the link rate.
Changes in v2:
-- remove dev from dp_ctrl_put() parameters
-- address review comments
This needs to go below '---' and should not be part of the
change log.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 26 +
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
drivers/gpu/drm/msm/dp/dp_power.c | 44
++---
drivers/gpu/drm/msm/dp/dp_power.h | 2 +-
4 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 2e3e1917351f..6eb9cdad1421 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -76,6 +77,8 @@ struct dp_ctrl_private {
struct dp_parser *parser;
struct dp_catalog *catalog;
+ struct opp_table *opp_table;
+
struct completion idle_comp;
struct completion video_comp;
};
@@ -1836,6 +1839,7 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev,
struct dp_link *link,
struct dp_parser *parser)
{
struct dp_ctrl_private *ctrl;
+ int ret;
if (!dev || !panel || !aux ||
!link || !catalog) {
@@ -1849,6 +1853,19 @@ struct dp_ctrl *dp_ctrl_get(struct device *dev,
struct dp_link *link,
return ERR_PTR(-ENOMEM);
}
+ ctrl->opp_table = dev_pm_opp_set_clkname(dev, "ctrl_link");
+ if (IS_ERR(ctrl->opp_table)) {
+ dev_err(dev, "invalid DP OPP table in device tree\n");
You do this regardless of an OPP table in DT, so for starters the error
message is wrong. Secondly this can return you a -EPROBE_DEFER if the
clock driver isn't ready yet.
So the ideal thing to do here, is return a PTR_ERR(ctrl->opp_table)
+ ctrl->opp_table = NULL;
+ } else {
+ /* OPP table is optional */
+ ret = dev_pm_opp_of_add_table(dev);
+ if (ret && ret != -ENODEV) {
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
+ }
+
init_completion(>idle_comp);
init_completion(>video_comp);
@@ -1866,4 +1883,13 @@ struct dp_ctrl *dp_ctrl_get(struct device
*dev, struct dp_link *link,
void dp_ctrl_put(struct dp_ctrl *dp_ctrl)
{
+ struct dp_ctrl_private *ctrl;
+
+ ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
+
+ if (ctrl->opp_table) {
+ dev_pm_opp_of_remove_table(ctrl->dev);
+ dev_pm_opp_put_clkname(ctrl->opp_table);
+ ctrl->opp_table = NULL;
+ }
}
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index e175aa3fd3a9..269f83550b46 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -698,7 +698,7 @@ static int dp_init_sub_modules(struct
dp_display_private *dp)
goto error;
}
- dp->power = dp_power_get(dp->parser);
+ dp->power = dp_power_get(dev, dp->parser);
if (IS_ERR(dp->power)) {
rc = PTR_ERR(dp->power);
DRM_ERROR("failed to initialize power, rc = %d\n", rc);
diff --git a/drivers/gpu/drm/msm/dp/dp_power.c
b/drivers/gpu/drm/msm/dp/dp_power.c
index 17c1fc6a2d44..9c4ea00a5f2a 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -8,12 +8,14 @@
#include
#include
#include
+#include
#include "dp_power.h"
#include "msm_drv.h"
struct dp_power_private {
struct dp_parser *parser;
struct platform_device *pdev;
+ struct device *dev;
struct clk *link_clk_src;
struct clk *pixel_provider;
struct clk *link_provider;
@@ -148,18 +150,51 @@ static int dp_power_clk_deinit(struct
dp_power_private *power)
return 0;
}
+static int dp_power_clk_set_link_rate(struct dp_power_private
*power,
+ struct dss_clk *clk_arry, int num_clk, int enable)
+{
+ u32 rate;
+ int i, rc = 0;
+
+ for (i = 0; i < num_clk; i++) {
+ if (clk_arry[i].clk) {
+ if (clk_arry[i].type == DSS_CLK_PCLK) {
+ if (enable)
+ rate = clk_arry[i].rate;
+ else
+ rate = 0;
+
+ rc = dev_pm_opp_set_rate(power->dev, rate);
I am not sure how this is expected to work when you have multiple link
clocks,
since you can only associate one of them with the OPP table which ends
up
getting scaled when you do a dev_pm_opp_set_rate()
Do you really have
[PATCH v3] drm/msm/dp: return correct connection status after suspend
During suspend, dp host controller and hpd block are disabled due to
both ahb and aux clock are disabled. Therefore hpd plug/unplug interrupts
will not be generated. At dp_pm_resume(), reinitialize both dp host
controller and hpd block so that hpd plug/unplug interrupts will be
generated and handled by driver so that hpd connection state is updated
correctly. This patch will fix link training flaky issues.
Changes in v2:
-- use container_of to cast correct dp_display_private pointer
at both dp_pm_suspend() and dp_pm_resume().
Changes in v3:
-- replace hpd_state atomic_t with u32
-- Add more information to commit message.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 13
drivers/gpu/drm/msm/dp/dp_catalog.h | 1 +
drivers/gpu/drm/msm/dp/dp_display.c | 117 +---
drivers/gpu/drm/msm/dp/dp_reg.h | 2 +
4 files changed, 72 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index b15b4ce4ba35..4963bfe6a472 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -572,6 +572,19 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog
*dp_catalog)
dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN);
}
+u32 dp_catalog_hpd_get_state_status(struct dp_catalog *dp_catalog)
+{
+ struct dp_catalog_private *catalog = container_of(dp_catalog,
+ struct dp_catalog_private, dp_catalog);
+ u32 status;
+
+ status = dp_read_aux(catalog, REG_DP_DP_HPD_INT_STATUS);
+ status >>= DP_DP_HPD_STATE_STATUS_BITS_SHIFT;
+ status &= DP_DP_HPD_STATE_STATUS_BITS_MASK;
+
+ return status;
+}
+
u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog)
{
struct dp_catalog_private *catalog = container_of(dp_catalog,
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 4b7666f1fe6f..6d257dbebf29 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -97,6 +97,7 @@ void dp_catalog_ctrl_enable_irq(struct dp_catalog
*dp_catalog, bool enable);
void dp_catalog_hpd_config_intr(struct dp_catalog *dp_catalog,
u32 intr_mask, bool en);
void dp_catalog_ctrl_hpd_config(struct dp_catalog *dp_catalog);
+u32 dp_catalog_hpd_get_state_status(struct dp_catalog *dp_catalog);
u32 dp_catalog_hpd_get_intr_status(struct dp_catalog *dp_catalog);
void dp_catalog_ctrl_phy_reset(struct dp_catalog *dp_catalog);
int dp_catalog_ctrl_update_vx_px(struct dp_catalog *dp_catalog, u8 v_level,
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index e175aa3fd3a9..fd16e12ab2f8 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -108,14 +108,12 @@ struct dp_display_private {
/* event related only access by event thread */
struct mutex event_mutex;
wait_queue_head_t event_q;
- atomic_t hpd_state;
+ u32 hpd_state;
u32 event_pndx;
u32 event_gndx;
struct dp_event event_list[DP_EVENT_Q_MAX];
spinlock_t event_lock;
- struct completion resume_comp;
-
struct dp_audio *audio;
};
@@ -490,7 +488,7 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
mutex_lock(>event_mutex);
- state = atomic_read(>hpd_state);
+ state = dp->hpd_state;
if (state == ST_SUSPEND_PENDING) {
mutex_unlock(>event_mutex);
return 0;
@@ -508,17 +506,14 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
return 0;
}
- if (state == ST_SUSPENDED)
- tout = DP_TIMEOUT_NONE;
-
- atomic_set(>hpd_state, ST_CONNECT_PENDING);
+ dp->hpd_state = ST_CONNECT_PENDING;
hpd->hpd_high = 1;
ret = dp_display_usbpd_configure_cb(>pdev->dev);
if (ret) { /* failed */
hpd->hpd_high = 0;
- atomic_set(>hpd_state, ST_DISCONNECTED);
+ dp->hpd_state = ST_DISCONNECTED;
}
/* start sanity checking */
@@ -539,10 +534,10 @@ static int dp_connect_pending_timeout(struct
dp_display_private *dp, u32 data)
mutex_lock(>event_mutex);
- state = atomic_read(>hpd_state);
+ state = dp->hpd_state;
if (state == ST_CONNECT_PENDING) {
dp_display_enable(dp, 0);
- atomic_set(>hpd_state, ST_CONNECTED);
+ dp->hpd_state = ST_CONNECTED;
}
mutex_unlock(>event_mutex);
@@ -567,7 +562,7 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
mutex_lock(>event_mutex);
- state = atomic_read(>hpd_state);
+ state = dp->hpd_state;
if (state == ST_SUSPEND_PENDING) {
mutex_unlock(>event_mutex);
return 0;
Re: [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize new kmap_thread()
-ira.we...@intel.com wrote: -
>To: "Andrew Morton" , "Thomas Gleixner"
>, "Ingo Molnar" , "Borislav
>Petkov" , "Andy Lutomirski" , "Peter
>Zijlstra"
>From: ira.we...@intel.com
>Date: 10/09/2020 09:52PM
>Cc: "Ira Weiny" , "Mike Marciniszyn"
>, "Dennis Dalessandro"
>, "Doug Ledford" ,
>"Jason Gunthorpe" , "Faisal Latif"
>, "Shiraz Saleem" ,
>"Bernard Metzler" , x...@kernel.org, "Dave Hansen"
>, "Dan Williams"
>, "Fenghua Yu" ,
>linux-...@vger.kernel.org, linux-ker...@vger.kernel.org,
>linux-nvd...@lists.01.org, linux-fsde...@vger.kernel.org,
>linux...@kvack.org, linux-kselft...@vger.kernel.org,
>linuxppc-...@lists.ozlabs.org, k...@vger.kernel.org,
>net...@vger.kernel.org, b...@vger.kernel.org,
>ke...@lists.infradead.org, linux-bca...@vger.kernel.org,
>linux-...@lists.infradead.org, de...@driverdev.osuosl.org,
>linux-...@vger.kernel.org, linux-...@vger.kernel.org,
>linux-s...@vger.kernel.org, target-de...@vger.kernel.org,
>linux-...@vger.kernel.org, ceph-de...@vger.kernel.org,
>linux-e...@vger.kernel.org, linux-...@kvack.org,
>io-ur...@vger.kernel.org, linux-er...@lists.ozlabs.org,
>linux...@lists.infradead.org, linux-ntfs-...@lists.sourceforge.net,
>reiserfs-de...@vger.kernel.org,
>linux-f2fs-de...@lists.sourceforge.net, linux-ni...@vger.kernel.org,
>cluster-de...@redhat.com, ecryp...@vger.kernel.org,
>linux-c...@vger.kernel.org, linux-bt...@vger.kernel.org,
>linux-...@lists.infradead.org, linux-r...@vger.kernel.org,
>amd-...@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
>intel-...@lists.freedesktop.org, drbd-...@tron.linbit.com,
>linux-bl...@vger.kernel.org, xen-de...@lists.xenproject.org,
>linux-cach...@redhat.com, samba-techni...@lists.samba.org,
>intel-wired-...@lists.osuosl.org
>Subject: [EXTERNAL] [PATCH RFC PKS/PMEM 10/58] drivers/rdma: Utilize
>new kmap_thread()
>
>From: Ira Weiny
>
>The kmap() calls in these drivers are localized to a single thread.
>To
>avoid the over head of global PKRS updates use the new kmap_thread()
>call.
>
>Cc: Mike Marciniszyn
>Cc: Dennis Dalessandro
>Cc: Doug Ledford
>Cc: Jason Gunthorpe
>Cc: Faisal Latif
>Cc: Shiraz Saleem
>Cc: Bernard Metzler
>Signed-off-by: Ira Weiny
>---
> drivers/infiniband/hw/hfi1/sdma.c | 4 ++--
> drivers/infiniband/hw/i40iw/i40iw_cm.c | 10 +-
> drivers/infiniband/sw/siw/siw_qp_tx.c | 14 +++---
> 3 files changed, 14 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/infiniband/hw/hfi1/sdma.c
>b/drivers/infiniband/hw/hfi1/sdma.c
>index 04575c9afd61..09d206e3229a 100644
>--- a/drivers/infiniband/hw/hfi1/sdma.c
>+++ b/drivers/infiniband/hw/hfi1/sdma.c
>@@ -3130,7 +3130,7 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata
>*dd, struct sdma_txreq *tx,
> }
>
> if (type == SDMA_MAP_PAGE) {
>- kvaddr = kmap(page);
>+ kvaddr = kmap_thread(page);
> kvaddr += offset;
> } else if (WARN_ON(!kvaddr)) {
> __sdma_txclean(dd, tx);
>@@ -3140,7 +3140,7 @@ int ext_coal_sdma_tx_descs(struct hfi1_devdata
>*dd, struct sdma_txreq *tx,
> memcpy(tx->coalesce_buf + tx->coalesce_idx, kvaddr, len);
> tx->coalesce_idx += len;
> if (type == SDMA_MAP_PAGE)
>- kunmap(page);
>+ kunmap_thread(page);
>
> /* If there is more data, return */
> if (tx->tlen - tx->coalesce_idx)
>diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c
>b/drivers/infiniband/hw/i40iw/i40iw_cm.c
>index a3b95805c154..122d7a5642a1 100644
>--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
>+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
>@@ -3721,7 +3721,7 @@ int i40iw_accept(struct iw_cm_id *cm_id, struct
>iw_cm_conn_param *conn_param)
> ibmr->device = iwpd->ibpd.device;
> iwqp->lsmm_mr = ibmr;
> if (iwqp->page)
>- iwqp->sc_qp.qp_uk.sq_base = kmap(iwqp->page);
>+ iwqp->sc_qp.qp_uk.sq_base = kmap_thread(iwqp->page);
> dev->iw_priv_qp_ops->qp_send_lsmm(>sc_qp,
> iwqp->ietf_mem.va,
> (accept.size +
> conn_param->private_data_len),
>@@ -3729,12 +3729,12 @@ int i40iw_accept(struct iw_cm_id *cm_id,
>struct iw_cm_conn_param *conn_param)
>
> } else {
> if (iwqp->page)
>- iwqp->sc_qp.qp_uk.sq_base = kmap(iwqp->page);
>+ iwqp->sc_qp.qp_uk.sq_base = kmap_thread(iwqp->page);
> dev->iw_priv_qp_ops->qp_send_lsmm(>sc_qp, NULL, 0, 0);
> }
>
> if (iwqp->page)
>- kunmap(iwqp->page);
>+ kunmap_thread(iwqp->page);
>
> iwqp->cm_id = cm_id;
> cm_node->cm_id = cm_id;
>@@ -4102,10 +4102,10 @@ static void i40iw_cm_event_connected(struct
>i40iw_cm_event *event)
> i40iw_cm_init_tsa_conn(iwqp, cm_node);
> read0 =
Re: [PATCH RFC PKS/PMEM 26/58] fs/zonefs: Utilize new kmap_thread()
On 2020/10/10 4:52, ira.we...@intel.com wrote: > From: Ira Weiny > > The kmap() calls in this FS are localized to a single thread. To avoid > the over head of global PKRS updates use the new kmap_thread() call. > > Cc: Damien Le Moal > Cc: Naohiro Aota > Signed-off-by: Ira Weiny > --- > fs/zonefs/super.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/zonefs/super.c b/fs/zonefs/super.c > index 8ec7c8f109d7..2fd6c86beee1 100644 > --- a/fs/zonefs/super.c > +++ b/fs/zonefs/super.c > @@ -1297,7 +1297,7 @@ static int zonefs_read_super(struct super_block *sb) > if (ret) > goto free_page; > > - super = kmap(page); > + super = kmap_thread(page); > > ret = -EINVAL; > if (le32_to_cpu(super->s_magic) != ZONEFS_MAGIC) > @@ -1349,7 +1349,7 @@ static int zonefs_read_super(struct super_block *sb) > ret = 0; > > unmap: > - kunmap(page); > + kunmap_thread(page); > free_page: > __free_page(page); > > acked-by: Damien Le Moal -- Damien Le Moal Western Digital Research ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/ttm: set the tt caching state at creation time
Ping? Anybody any more comments on this?
Otherwise I'm going to push it to drm-misc-next by tomorrow or so.
Thanks,
Christian.
Am 08.10.20 um 11:31 schrieb Christian König:
All drivers can determine the tt caching state at creation time,
no need to do this on the fly during every validation.
Signed-off-by: Christian König
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 11 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_sgdma.c| 13 -
drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 16 --
drivers/gpu/drm/ttm/ttm_agp_backend.c | 2 +-
drivers/gpu/drm/ttm/ttm_page_alloc.c | 26 -
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 20 ++---
drivers/gpu/drm/ttm/ttm_tt.c | 33 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 ++--
include/drm/ttm/ttm_caching.h | 34 ++
include/drm/ttm/ttm_tt.h | 16 --
13 files changed, 123 insertions(+), 60 deletions(-)
create mode 100644 include/drm/ttm/ttm_caching.h
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 213ef090bb0e..3c5ad69eff19 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -124,7 +124,7 @@ uint64_t amdgpu_gmc_agp_addr(struct ttm_buffer_object *bo)
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->bdev);
struct ttm_dma_tt *ttm;
- if (bo->num_pages != 1 || bo->ttm->caching_state == tt_cached)
+ if (bo->num_pages != 1 || bo->ttm->caching == ttm_cached)
return AMDGPU_BO_INVALID_OFFSET;
ttm = container_of(bo->ttm, struct ttm_dma_tt, ttm);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 399961035ae6..7f41a47e7353 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1292,7 +1292,9 @@ static void amdgpu_ttm_backend_destroy(struct
ttm_bo_device *bdev,
static struct ttm_tt *amdgpu_ttm_tt_create(struct ttm_buffer_object *bo,
uint32_t page_flags)
{
+ struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
struct amdgpu_ttm_tt *gtt;
+ enum ttm_caching caching;
gtt = kzalloc(sizeof(struct amdgpu_ttm_tt), GFP_KERNEL);
if (gtt == NULL) {
@@ -1300,8 +1302,13 @@ static struct ttm_tt *amdgpu_ttm_tt_create(struct
ttm_buffer_object *bo,
}
gtt->gobj = >base;
+ if (abo->flags & AMDGPU_GEM_CREATE_CPU_GTT_USWC)
+ caching = ttm_write_combined;
+ else
+ caching = ttm_cached;
+
/* allocate space for the uninitialized page entries */
- if (ttm_sg_tt_init(>ttm, bo, page_flags)) {
+ if (ttm_sg_tt_init(>ttm, bo, page_flags, caching)) {
kfree(gtt);
return NULL;
}
@@ -1525,7 +1532,7 @@ uint64_t amdgpu_ttm_tt_pde_flags(struct ttm_tt *ttm,
struct ttm_resource *mem)
if (mem && mem->mem_type == TTM_PL_TT) {
flags |= AMDGPU_PTE_SYSTEM;
- if (ttm->caching_state == tt_cached)
+ if (ttm->caching == ttm_cached)
flags |= AMDGPU_PTE_SNOOPED;
}
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3213429f8444..ad58d0af5141 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -918,7 +918,7 @@ static struct ttm_tt *bo_driver_ttm_tt_create(struct
ttm_buffer_object *bo,
if (!tt)
return NULL;
- ret = ttm_tt_init(tt, bo, page_flags);
+ ret = ttm_tt_init(tt, bo, page_flags, ttm_cached);
if (ret < 0)
goto err_ttm_tt_init;
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 806d9ec310f5..cd6fdebae795 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -5,6 +5,7 @@
#include "nouveau_drv.h"
#include "nouveau_mem.h"
#include "nouveau_ttm.h"
+#include "nouveau_bo.h"
struct nouveau_sgdma_be {
/* this has to be the first field so populate/unpopulated in
@@ -67,13 +68,23 @@ nouveau_sgdma_unbind(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
struct ttm_tt *
nouveau_sgdma_create_ttm(struct ttm_buffer_object *bo, uint32_t page_flags)
{
+ struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
+ struct nouveau_bo *nvbo = nouveau_bo(bo);
struct nouveau_sgdma_be *nvbe;
+ enum ttm_caching caching;
+
+ if (nvbo->force_coherent)
+ caching = ttm_uncached;
+ else if (drm->agp.bridge)
+ caching = ttm_write_combined;
+ else
+
[PATCH 1/2] mm: mmap: fix fput in error path v2
Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..."
adds a workaround for a bug in mmap_region.
As the comment states ->mmap() callback can change
vma->vm_file and so we might call fput() on the wrong file.
Revert the workaround and proper fix this in mmap_region.
v2: drop the extra if in dma_buf_mmap as well
Signed-off-by: Christian König
Reviewed-by: Jason Gunthorpe
---
drivers/dma-buf/dma-buf.c | 20 +++-
mm/mmap.c | 2 +-
2 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a6ba4d598f0e..08630d057cf2 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1143,9 +1143,6 @@ EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
- struct file *oldfile;
- int ret;
-
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -1163,22 +1160,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
return -EINVAL;
/* readjust the vma */
- get_file(dmabuf->file);
- oldfile = vma->vm_file;
- vma->vm_file = dmabuf->file;
+ fput(vma->vm_file);
+ vma->vm_file = get_file(dmabuf->file);
vma->vm_pgoff = pgoff;
- ret = dmabuf->ops->mmap(dmabuf, vma);
- if (ret) {
- /* restore old parameters on failure */
- vma->vm_file = oldfile;
- fput(dmabuf->file);
- } else {
- if (oldfile)
- fput(oldfile);
- }
- return ret;
-
+ return dmabuf->ops->mmap(dmabuf, vma);
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
diff --git a/mm/mmap.c b/mm/mmap.c
index 40248d84ad5f..3a2670d73355 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1852,8 +1852,8 @@ unsigned long mmap_region(struct file *file, unsigned
long addr,
return addr;
unmap_and_free_vma:
+ fput(vma->vm_file);
vma->vm_file = NULL;
- fput(file);
/* Undo any partial mapping done by a device driver. */
unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] mm: introduce vma_set_file function v4
Add the new vma_set_file() function to allow changing
vma->vm_file with the necessary refcount dance.
v2: add more users of this.
v3: add missing EXPORT_SYMBOL, rebase on mmap cleanup,
add comments why we drop the reference on two occasions.
v4: make it clear that changing an anonymous vma is illegal.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter (v2)
---
drivers/dma-buf/dma-buf.c | 3 +--
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 4 +---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 +--
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 5 +++--
drivers/gpu/drm/msm/msm_gem.c | 4 +---
drivers/gpu/drm/omapdrm/omap_gem.c | 3 +--
drivers/gpu/drm/vgem/vgem_drv.c| 3 +--
drivers/staging/android/ashmem.c | 6 +++---
include/linux/mm.h | 2 ++
mm/mmap.c | 12
10 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 08630d057cf2..8e6a114c6034 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1160,8 +1160,7 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
return -EINVAL;
/* readjust the vma */
- fput(vma->vm_file);
- vma->vm_file = get_file(dmabuf->file);
+ vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
return dmabuf->ops->mmap(dmabuf, vma);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index 312e9d58d5a7..10ce267c0947 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -145,10 +145,8 @@ static int etnaviv_gem_mmap_obj(struct etnaviv_gem_object
*etnaviv_obj,
* address_space (so unmap_mapping_range does what we want,
* in particular in the case of mmap'd dmabufs)
*/
- fput(vma->vm_file);
- get_file(etnaviv_obj->base.filp);
vma->vm_pgoff = 0;
- vma->vm_file = etnaviv_obj->base.filp;
+ vma_set_file(vma, etnaviv_obj->base.filp);
vma->vm_page_prot = vm_page_prot;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index fec0e1e3dc3e..8ce4c9e28b87 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -119,8 +119,7 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
struct vm_area_struct *
if (ret)
return ret;
- fput(vma->vm_file);
- vma->vm_file = get_file(obj->base.filp);
+ vma_set_file(vma, obj->base.filp);
return 0;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 3d69e51f3e4d..ec28a6cde49b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -893,8 +893,9 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
* requires avoiding extraneous references to their filp, hence why
* we prefer to use an anonymous file for their mmaps.
*/
- fput(vma->vm_file);
- vma->vm_file = anon;
+ vma_set_file(vma, anon);
+ /* Drop the initial creation reference, the vma is now holding one. */
+ fput(anon);
switch (mmo->mmap_type) {
case I915_MMAP_TYPE_WC:
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index de915ff6f4b4..a71f42870d5e 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -223,10 +223,8 @@ int msm_gem_mmap_obj(struct drm_gem_object *obj,
* address_space (so unmap_mapping_range does what we want,
* in particular in the case of mmap'd dmabufs)
*/
- fput(vma->vm_file);
- get_file(obj->filp);
vma->vm_pgoff = 0;
- vma->vm_file = obj->filp;
+ vma_set_file(vma, obj->filp);
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
}
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 979d53a93c2b..0d4542ff1d7d 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -564,9 +564,8 @@ int omap_gem_mmap_obj(struct drm_gem_object *obj,
* address_space (so unmap_mapping_range does what we want,
* in particular in the case of mmap'd dmabufs)
*/
- fput(vma->vm_file);
vma->vm_pgoff = 0;
- vma->vm_file = get_file(obj->filp);
+ vma_set_file(vma, obj->filp);
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
}
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
Re: [PATCH 1/6] mm: mmap: fix fput in error path
Am 10.10.20 um 00:25 schrieb Jason Gunthorpe: On Fri, Oct 09, 2020 at 03:04:20PM -0700, Andrew Morton wrote: On Fri, 9 Oct 2020 17:03:37 +0200 "Christian König" wrote: Patch "495c10cc1c0c CHROMIUM: dma-buf: restore args..." adds a workaround for a bug in mmap_region. As the comment states ->mmap() callback can change vma->vm_file and so we might call fput() on the wrong file. Revert the workaround and proper fix this in mmap_region. Doesn't this patch series address the same thing as https://lkml.kernel.org/r/20200916090733.31427-1-linmia...@huawei.com? Same basic issue, looks like both of these patches should be combined to plug it fully. Yes, agree completely. It's a different error path, but we need to fix both occasions. Christian. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] mm: introduce vma_set_file function v3
Am 09.10.20 um 17:14 schrieb Jason Gunthorpe:
On Fri, Oct 09, 2020 at 05:03:38PM +0200, Christian König wrote:
+/*
+ * Change backing file, only valid to use during initial VMA setup.
+ */
+void vma_set_file(struct vm_area_struct *vma, struct file *file)
+{
+ if (file)
+ get_file(file);
+
+ swap(vma->vm_file, file);
+
+ if (file)
+ fput(file);
+}
fput crashes when file is NULL so the error handling after
unmap_and_free_vma: can't handle this case, similarly vm_file can't be
NULL either.
So just simply:
swap(vma->vm_file, file);
get_file(vma->vm_file);
fput(file);
Will do?
I was considering this as well, yes.
Just let it crash if any of them are wrongly NULL.
Mhm, changing from anonymous to file backed or reverse is probably not
such a good idea.
So yes catching those problems early is probably the best approach we
could do.
Going to do this in v4 if nobody objects.
Regards,
Christian.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: document that user-space should avoid parsing EDIDs
On Fri, 9 Oct 2020 17:20:18 +0300 Ville Syrjälä wrote: > On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote: > > On Fri, 9 Oct 2020 16:10:25 +0300 > > Ville Syrjälä wrote: > > > > > On Fri, Oct 09, 2020 at 01:07:20PM +0100, Daniel Stone wrote: > > > > Hi, > > > > > > > > On Fri, 9 Oct 2020 at 10:24, Simon Ser wrote: > > > > > User-space should avoid parsing EDIDs for metadata already exposed via > > > > > other KMS interfaces and properties. For instance, user-space should > > > > > not > > > > > try to extract a list of modes from the EDID: the kernel might mutate > > > > > the mode list (because of link capabilities or quirks for instance). > > > > > > > > > > Other metadata not exposed by KMS can be parsed by user-space. This > > > > > includes for instance monitor identification (make/model/serial) and > > > > > supported color-spaces. > > > > > > > > So I take it the only way to get modes is through the connector's list > > > > of modes. That sounds reasonable enough to me, but I think to properly > > > > handle colour (e.g. CEA modes have different behaviour for > > > > limited/full range depending on which VIC they correspond to IIRC) > > > > > > If the mode has a VIC and that VIC is not 1, then it's limited range, > > > otherwise full range. There are fortunately no cases where you would > > > have the same exact timings corresponding to different quantization > > > range depending on the VIC. > > > > > > And the only reason the same timings could correspond to multiple VICs > > > is aspect ratio. Which is already exposed via the mode flags, assuming > > > the appropriate client cap is enabled. > > > > > > So I think the only reason to expose the VIC would be if userspace is > > > non-lazy and wants to manage its colors presicely, but is otherwise lazy > > > and doesn't want to figure out what the VIC of the mode is on its own. > > > > What would "figure out what the VIC of the mode is" require in userspace? > > > > A database of all VIC modes and then compare if the detailed timings match? > > > > Is that also how the kernel recognises that userspace wants to set a > > certain VIC mode instead of some arbitrary mode? > > Yes and yes. > > Note that atm we also don't have a way for userspace to say that it > wants to signal limited range to the sink but wants the kernel > to not do the full->limited range conversion. Ie. no way for userspace > to pass in pixels that are already in limited range. There was a patch > for that posted quite long ago, but it didn't go in. Thanks for the heads-up. If userspace uses all available KMS color management properties (CTM, LUTs, etc.) *and* the video mode implies limited range on the cable, at what point in the pixel pipeline does that conversion from full to limited range occur? That is something I expect to need codify into Weston at some point so that the complete pixel pipeline works as intended. Thanks, pq pgp5l27H9Fe6t.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()
On Fri, Oct 09, 2020 at 06:30:36PM -0700, Eric Biggers wrote:
> On Sat, Oct 10, 2020 at 01:39:54AM +0100, Matthew Wilcox wrote:
> > On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote:
> > > On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > > the over head of global PKRS updates use the new kmap_thread() call.
> > > >
> > > > @@ -2410,12 +2410,12 @@ static inline struct page
> > > > *f2fs_pagecache_get_page(
> > > >
> > > > static inline void f2fs_copy_page(struct page *src, struct page *dst)
> > > > {
> > > > - char *src_kaddr = kmap(src);
> > > > - char *dst_kaddr = kmap(dst);
> > > > + char *src_kaddr = kmap_thread(src);
> > > > + char *dst_kaddr = kmap_thread(dst);
> > > >
> > > > memcpy(dst_kaddr, src_kaddr, PAGE_SIZE);
> > > > - kunmap(dst);
> > > > - kunmap(src);
> > > > + kunmap_thread(dst);
> > > > + kunmap_thread(src);
> > > > }
> > >
> > > Wouldn't it make more sense to switch cases like this to kmap_atomic()?
> > > The pages are only mapped to do a memcpy(), then they're immediately
> > > unmapped.
> >
> > Maybe you missed the earlier thread from Thomas trying to do something
> > similar for rather different reasons ...
> >
> > https://lore.kernel.org/lkml/20200919091751.06...@linutronix.de/
>
> I did miss it. I'm not subscribed to any of the mailing lists it was sent to.
>
> Anyway, it shouldn't matter. Patchsets should be standalone, and not require
> reading random prior threads on linux-kernel to understand.
Sorry, but I did not think that the discussion above was directly related. If
I'm not mistaken, Thomas' work was directed at relaxing kmap_atomic() into
kmap_thread() calls. While interesting, it is not the point of this series. I
want to restrict kmap() callers into kmap_thread().
For this series it was considered to change the kmap_thread() call sites to
kmap_atomic(). But like I said in the cover letter kmap_atomic() is not the
same semantic. It is too strict. Perhaps I should have expanded that
explanation.
>
> And I still don't really understand. After this patchset, there is still code
> nearly identical to the above (doing a temporary mapping just for a memcpy)
> that
> would still be using kmap_atomic().
I don't understand. You mean there would be other call sites calling:
kmap_atomic()
memcpy()
kunmap_atomic()
?
> Is the idea that later, such code will be
> converted to use kmap_thread() instead? If not, why use one over the other?
The reason for the new call is that with PKS added behind kmap we have 3 levels
of mapping we want.
global kmap (can span threads and sleep)
'thread' kmap (can sleep but not span threads)
'atomic' kmap (can't sleep nor span threads [by definition])
As Matthew said perhaps 'global kmaps' may be best changed to vmaps? I just
don't know the details of every call site.
And since I don't know the call site details if there are kmap_thread() calls
which are better off as kmap_atomic() calls I think it is worth converting
them. But I made the assumption that kmap users would already be calling
kmap_atomic() if they could (because it is more efficient).
Ira
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/5] dt-bindings: display: Add support for Intel KeemBay Display
Hi Neil/Anitha.
On Fri, Oct 09, 2020 at 11:09:45AM +0200, Neil Armstrong wrote:
> Hi,
>
> On 09/10/2020 03:03, Anitha Chrisanthus wrote:
> > This patch adds bindings for Intel KeemBay Display
> >
> > v2: review changes from Rob Herring
> >
> > Signed-off-by: Anitha Chrisanthus
> > ---
> > .../bindings/display/intel,keembay-display.yaml| 99
> > ++
> > 1 file changed, 99 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> > b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> > new file mode 100644
> > index 000..a38493d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml
> > @@ -0,0 +1,99 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
(GPL-2.0-only OR BSD-2-Clause) for new bindings please.
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Devicetree bindings for Intel Keem Bay display controller
> > +
> > +maintainers:
> > + - Anitha Chrisanthus
> > + - Edmond J Dea
> > +
> > +properties:
> > + compatible:
> > +const: intel,kmb_display
> > +
> > + reg:
> > +items:
> > + - description: Lcd registers range
> > + - description: Mipi registers range
>
> Looking at the registers, the MIPI transceiver seems to be a separate IP,
> same for D-PHY which should have a proper PHY driver instead of beeing handled
> here.
Looking at the register definitiosn and the code the split in a display
block and a bridge block looks reasonable.
The bridge block would include the MIPI<->DSI part which includes the
PHY and the Msscam parts too. The PHY is an integrated part of the
MIPI<->DSI IP so really not eligeble for a dedicated node in the DT.
Likewise the Msscam, whatevet that is, is integrated with the
MIPI<->DSI.
So all in all:
- One display DT Schema
- One bridge DT Schema
The bridge DT Schema will then have an input port and an output port.
>
> > + - description: Msscam registers range
>
> MSScam here seems to be a clock and reset controller for the LCD and MIPI IPs,
> thus should be handler out of DRM.
Reading the register definitions and the code it looks very integrated
so as I wrote above, no dedicated DT Schema should be needed here.
>
> > +
> > + reg-names:
> > +items:
> > + - const: lcd
> > + - const: mipi
> > + - const: msscam
> > +
> > + clocks:
> > +items:
> > + - description: LCD controller clock
> > + - description: Mipi DSI clock
> > + - description: Mipi DSI econfig clock
> > + - description: Mipi DSI config clock
> > + - description: System clock or pll0 clock
> > +
> > + clock-names:
> > +items:
> > + - const: clk_lcd
> > + - const: clk_mipi
> > + - const: clk_mipi_ecfg
> > + - const: clk_mipi_cfg
> > + - const: clk_pll0
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + encoder-slave:
> > +description: bridge node entry for mipi to hdmi converter
This node should go, as we shall find the bridge using the ports.
> > +
> > + port:
> > +type: object
> > +description: >
> > + Port node with one endpoint connected to mipi to hdmi converter
> > node.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - clocks
> > + - clock-names
> > + - interrupts
> > + - encoder-slave
> > + - port
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +#define MOVISOC_KMB_MSS_AUX_LCD
> > +#define MOVISOC_KMB_MSS_AUX_MIPI_TX0
> > +#define MOVISOC_KMB_MSS_AUX_MIPI_ECFG
> > +#define MOVISOC_KMB_MSS_AUX_MIPI_CFG
> > +#define MOVISOC_KMB_A53_PLL_0_OUT_0
> > +display@2090 {
> > + compatible = "intel,keembay-display";
> > + reg = <0x2093 0x3000>,
> > +<0x2090 0x4000>,
> > +<0x2091 0x30>;
> > + reg-names = "lcd", "mipi", "msscam";
> > + interrupts = ;
> > + clocks = <_clk MOVISOC_KMB_MSS_AUX_LCD>,
> > + <_clk MOVISOC_KMB_MSS_AUX_MIPI_TX0>,
> > + <_clk MOVISOC_KMB_MSS_AUX_MIPI_ECFG>,
> > + <_clk MOVISOC_KMB_MSS_AUX_MIPI_CFG>,
> > + <_clk MOVISOC_KMB_A53_PLL_0_OUT_0>;
> > + clock-names = "clk_lcd", "clk_mipi", "clk_mipi_ecfg",
> > +"clk_mipi_cfg", "clk_pll0";
> > +
> > + encoder-slave = <>;
> > +
> > + port {
> > +dsi_output: endpoint {
> > +remote-endpoint = <_input>;
> > +};
> > + };
> > +};
> >
>
> Anitha, Daniel, this keembay driver should be architectured like other
> ARM-like display
> controllers, with separate drivers for MIPI DSI bridge and msscam clock &
> reset controller.
