Re: [PATCH] drm/drm_fb_helper: fix fbdev with sparc64

[Thomas Zimmermann]

Hi

Am 09.07.20 um 21:30 schrieb Sam Ravnborg:
> Mark reported that sparc64 would panic while booting using qemu.
> Mark bisected this to a patch that introduced generic fbdev emulation to
> the bochs DRM driver.
> Mark pointed out that a similar bug was fixed before where
> the sys helpers was replaced by cfb helpers.
> 
> The culprint here is that the framebuffer reside in IO memory which
> requires SPARC ASI_PHYS (physical) loads and stores.
> 
> The current bohcs DRM driver uses a shadow buffer.
> So all copying to the framebuffer happens in
> drm_fb_helper_dirty_blit_real().
> 
> The fix is to replace the memcpy with memcpy_toio() from io.h.
> 
> memcpy_toio() uses writeb() where the original fbdev code
> used sbus_memcpy_toio(). The latter uses sbus_writeb().
> 
> The difference between writeb() and sbus_memcpy_toio() is
> that writeb() writes bytes in little-endian, where sbus_writeb() writes
> bytes in big-endian. As endian does not matter for byte writes they are
> the same. So we can safely use memcpy_toio() here.
> 
> For many architectures memcpy_toio() is a simple memcpy().
> One sideeffect that is unknow is if this has any impact on other
> architectures.
> So far the analysis tells that this change is OK for other arch's.
> but testing would be good.
> 
> Signed-off-by: Sam Ravnborg 
> Reported-by: Mark Cave-Ayland 
> Tested-by: Mark Cave-Ayland 
> Cc: Mark Cave-Ayland 
> Cc: Thomas Zimmermann 
> Cc: Gerd Hoffmann 
> Cc: "David S. Miller" 
> Cc: sparcli...@vger.kernel.org

So this actually is a problem in practice. Do you know how userspace
handles this?

For this patch

Acked-by: Thomas Zimmermann 

but I'd like to have someone with more architecture expertise ack this
as well.

Best regards
Thomas

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 5609e164805f..4d05b0ab1592 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct 
> drm_fb_helper *fb_helper,
>   unsigned int y;
>  
>   for (y = clip->y1; y < clip->y2; y++) {
> - memcpy(dst, src, len);
> + memcpy_toio(dst, src, len);
>   src += fb->pitches[0];
>   dst += fb->pitches[0];
>   }
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 2/2] display/drm/bridge: TC358775 DSI/LVDS driver

[Andrzej Hajda]

On 07.07.2020 10:25, Vinay Simha B N wrote:
> Andrzej,
>
> Please suggest.
>
> In general it should be in the reverse-order RESX then STBY, But
> As per the spec Datasheet Power off sequence is this Page 149, Section 
> Power Supply On and Off Sequence
>
> regulators
> STBY
> RESX
>
> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwiBmeWb2brqAhXO7HMBHZgaCTUQFjACegQIBxAB&url=https%3A%2F%2Fdownload.t-firefly.com%2Fproduct%2FRK3399%2FDocs%2FChip%2520Specifications%2FTC358774XBG_75XBG_V1%25204nm.pdf&usg=AOvVaw2kBuPv8FaZBNynGWCQHEfc
>  
> 
>

I guess you misread the diagram, it should be read from left to 
right(not top-bottom), and you have power off sequence:

RESX

STDBY

VDDC

VDD_LVDS

VDDIO


> Regarding data-lanes
> -data-lanes value does appear later from the mdp->dsi0 tree
> -We need to pick dynamically data-lanes of the dsi set, based on this 
> we need to set in the bridge.
> Otherwise we are already setting in dsi0 ports as <0 1 2 3> , again we 
> need to set it in the bridge tree.
> - There is no helper function to get the data-lanes of the DSI


The code asks for proper helper, but since there is no such I think it 
can stay as is.


Regards

Andrzej


>
> On Tue, Jul 7, 2020 at 12:15 PM Andrzej Hajda  > wrote:
>
>
> On 04.07.2020 11:24, Vinay Simha BN wrote:
> > This driver is tested with two panels individually with
> Apq8016-IFC6309 board
> >
> 
> https://protect2.fireeye.com/url?k=fe87a8ec-a3e0ecca-fe8623a3-0cc47a31384a-ffbc547df1141490&q=1&u=https%3A%2F%2Fwww.inforcecomputing.com%2Fproducts%2Fsingle-board-computers-sbc%2Fqualcomm-snapdragon-410-inforce-6309-micro-sbc
> >
> > 1. 1366x768@60 auo,b101xtn01 data-mapping = "jeida-24"
> > 2. 800x480@60 innolux,at070tn92 data-mapping = "vesa-24"
> >
> > - added SPDX identifier license
> > - updated alphabetic order of headers
> > - replaced u32 instead of uint32_t
> > - magic number to macros for CLRSI and mux registers
> > - mdelay to usleep_range
> > - added bus_formats
> > - removed drm_connector_status
> > - regulator enable and disable with proper orders and delays
> >    as per the spec
> > - devm_drm_panel_bridge_add method used instead of panel
> >    description modified
> > - dual port implemented
> > - panel->connector_type removed
> > - ~vsdelay dynamic value set based on the
> >    calculation of dsi speed, output speed, blanking
> > - help modified
> > - display_timings naming local variables
> > - check for bus_formats unsupported
> > - error handling enpoint data-lanes
> > - Kconfig proper indentation
> > - GENMASK and FIELD_PREP used
> > - bus_formats handeld in mode_valid
> > - MODE_CLOCK_HIGH handled properly
> > - len initialized
> > - static function for mode_valid
> >
> > Signed-off-by: Vinay Simha BN  >
> > ---
> > v1:
> >   Initial version
> >
> > v2:
> > * Andrzej Hajda review comments incorporated
> >    SPDX identifier
> >    development debug removed
> >    alphabetic order headers
> >    u32 instead of unit32_t
> >    magic numbers to macros for CLRSI and mux registers
> >    ignored return value
> >
> > * Laurent Pinchart review comments incorporated
> >    mdelay to usleep_range
> >    bus_formats added
> >
> > v3:
> > * Andrzej Hajda review comments incorporated
> >    drm_connector_status removed
> >    u32 rev removed and local variabl is used
> >    regulator enable disable with proper orders and delays
> >    as per the spec
> >    devm_drm_panel_bridge_add method used instead of panel
> >    description modified
> >    dual port implemented
> >
> > v4:
> > * Sam Ravnborg review comments incorporated
> >    panel->connector_type removed
> >
> > * Reported-by: kernel test robot  >
> >    parse_dt to static function
> >    removed the if (endpoint), since data-lanes has to be
> >    present for dsi dts ports
> >
> > v5:
> >    ~vsdelay dynamic value set based on the
> >    calculation of dsi speed, output speed, blanking
> >
> > v6:
> > * Sam Ravnborg review comments incorporated
> >    help modified
> >    display_timings naming local variables
> >    check for bus_formats unsupported
> >    error handling enpoin

Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can

[Doug Anderson]

Hi,

On Thu, Jul 9, 2020 at 8:43 PM Steev Klimaszewski  wrote:
>
>
> On 7/9/20 10:17 PM, Steev Klimaszewski wrote:
> >
> > On 7/9/20 10:12 PM, Steev Klimaszewski wrote:
> >>
> >> On 7/9/20 9:14 PM, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Thu, Jul 9, 2020 at 6:38 PM Doug Anderson 
> >>> wrote:
>  Hi,
> 
>  On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski
>   wrote:
> > Hi Doug,
> >
> > I've been testing 5.8 and linux-next on the Lenovo Yoga C630, and
> > with this patch applied, there is really bad banding on the display.
> >
> > I'm really bad at explaining it, but you can see the differences
> > in the following:
> >
> > 24bit (pre-5.8) - https://dev.gentoo.org/~steev/files/image0.jpg
> >
> > 18bit (5.8/linux-next) -
> > https://dev.gentoo.org/~steev/files/image1.jpg
>  Presumably this means that your panel is defined improperly? If the
>  panel reports that it's a 6 bits per pixel panel but it's actually an
>  8 bits per pixel panel then you'll run into this problem.
> 
>  I would have to assume you have a bunch of out of tree patches to
>  support your hardware since I don't see any device trees in linuxnext
>  (other than cheza) that use this bridge chip.  Otherwise I could try
>  to check and confirm that was the problem.
> >>> Ah, interesting.  Maybe you have the panel:
> >>>
> >>> boe,nv133fhm-n61
> >>>
> >>> As far as I can tell from the datasheet (I have the similar
> >>> boe,nv133fhm-n62) this is a 6bpp panel.  ...but if you feed it 8bpp
> >>> the banding goes away!  Maybe the panel itself knows how to dither???
> >>> ...or maybe the datasheet / edid are wrong and this is actually an
> >>> 8bpp panel.  Seems unlikely...
> >>>
> >>> In any case, one fix is to pick
> >>> ,
> >>>
> >>> though right now that patch is only enabled for sc7180.  Maybe you
> >>> could figure out how to apply it to your hardware?
> >>>
> >>> ...another fix would be to pretend that your panel is 8bpp even though
> >>> it's actually 6bpp.  Ironically if anyone ever tried to configure BPP
> >>> from the EDID they'd go back to 6bpp.  You can read the EDID of your
> >>> panel with this:
> >>>
> >>> bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
> >>> i2cdump ${bus} 0x50 i
> >>>
> >>> When I do that and then decode it on the "boe,nv133fhm-n62" panel, I
> >>> find:
> >>>
> >>> 6 bits per primary color channel
> >>>
> >>> -Doug
> >>
> >>
> >> Hi Doug,
> >>
> >> Decoding it does show be to boe,nv133fhm-n61 - and yeah it does say
> >> it's 6-bit according to panelook's specs for it.
>
>
> I derped again...
>
> root@c630:~# bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
> root@c630:~# i2cdump ${bus} 0x50 i > edid
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-16, address 0x50, mode i2c block
> Continue? [Y/n]
> root@c630:~# edid-decode edid
> edid-decode (hex):
>
> 00 ff ff ff ff ff ff 00 09 e5 d1 07 00 00 00 00
> 01 1c 01 04 a5 1d 11 78 0a 1d b0 a6 58 54 9e 26
> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
> 01 01 01 01 01 01 c0 39 80 18 71 38 28 40 30 20
> 36 00 26 a5 10 00 00 1a 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 1a 00 00 00 fe 00 42
> 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe
> 00 4e 56 31 33 33 46 48 4d 2d 4e 36 31 0a 00 9a
>
> 03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb
> fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73
> 44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61
> 92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2
> 66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70
> 43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc
> 45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3
> 30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29
>
> 
>
> EDID version: 1.4
> Manufacturer: BOE Model 2001 Serial Number 0
> Made in week 1 of 2018
> Digital display
> 8 bits per primary color channel
> DisplayPort interface
> Maximum image size: 29 cm x 17 cm
> Gamma: 2.20
> Supported color formats: RGB 4:4:4, YCrCb 4:4:4
> First detailed timing includes the native pixel format and preferred
> refresh rate
> Color Characteristics
>Red:   0.6484, 0.3447
>Green: 0.3310, 0.6181
>Blue:  0.1503, 0.0615
>White: 0.3125, 0.3281
> Established Timings I & II: none
> Standard Timings: none
> Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm
> 1920 1968 2000 2200 ( 48  32 200)
> 1080 1083 1089 1120 (  3   6  31)
> +hsync -vsync
> VertFreq: 60.000 Hz, HorFreq: 67.200 kHz
> Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 1a  
> Alphanumeric Data String: BOE CQ
> Alphanumeric Data String: NV133FHM-N61
> Checksum: 0x9a
>
> 
>
> Unknown EDID Extension Block 0x03
>03 26 0a 77 ab 1c 05 71 6f 1

linux-next: manual merge of the drm tree with the drm-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c

between commit:

  c564b8601ae9 ("drm/amdgpu: add TMR destory function for psp")

from the drm-fixes tree and commit:

  3bda8acd974e ("drm/amdgpu/sriov: Add clear vf fw support")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
index ef3269c43d4f,9342a9e8cadf..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
@@@ -1825,6 -1866,9 +1912,7 @@@ static int psp_hw_fini(void *handle
  {
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
struct psp_context *psp = &adev->psp;
 -  void *tmr_buf;
 -  void **pptr;
+   int ret;
  
if (psp->adev->psp.ta_fw) {
psp_ras_terminate(psp);
@@@ -1833,10 -1877,16 +1921,15 @@@
}
  
psp_asd_unload(psp);
+   ret = psp_clear_vf_fw(psp);
+   if (ret) {
+   DRM_ERROR("PSP clear vf fw!\n");
+   return ret;
+   }
  
 +  psp_tmr_terminate(psp);
psp_ring_destroy(psp, PSP_RING_TYPE__KM);
  
 -  pptr = amdgpu_sriov_vf(psp->adev) ? &tmr_buf : NULL;
 -  amdgpu_bo_free_kernel(&psp->tmr_bo, &psp->tmr_mc_addr, pptr);
amdgpu_bo_free_kernel(&psp->fw_pri_bo,
  &psp->fw_pri_mc_addr, &psp->fw_pri_buf);
amdgpu_bo_free_kernel(&psp->fence_buf_bo,


pgpZcVw3o1s2W.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can

[Doug Anderson]

Hi,

On Thu, Jul 9, 2020 at 6:38 PM Doug Anderson  wrote:
>
> Hi,
>
> On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski  wrote:
> >
> > Hi Doug,
> >
> > I've been testing 5.8 and linux-next on the Lenovo Yoga C630, and with this 
> > patch applied, there is really bad banding on the display.
> >
> > I'm really bad at explaining it, but you can see the differences in the 
> > following:
> >
> > 24bit (pre-5.8) - https://dev.gentoo.org/~steev/files/image0.jpg
> >
> > 18bit (5.8/linux-next) - https://dev.gentoo.org/~steev/files/image1.jpg
>
> Presumably this means that your panel is defined improperly?  If the
> panel reports that it's a 6 bits per pixel panel but it's actually an
> 8 bits per pixel panel then you'll run into this problem.
>
> I would have to assume you have a bunch of out of tree patches to
> support your hardware since I don't see any device trees in linuxnext
> (other than cheza) that use this bridge chip.  Otherwise I could try
> to check and confirm that was the problem.

Ah, interesting.  Maybe you have the panel:

boe,nv133fhm-n61

As far as I can tell from the datasheet (I have the similar
boe,nv133fhm-n62) this is a 6bpp panel.  ...but if you feed it 8bpp
the banding goes away!  Maybe the panel itself knows how to dither???
...or maybe the datasheet / edid are wrong and this is actually an
8bpp panel.  Seems unlikely...

In any case, one fix is to pick
,
though right now that patch is only enabled for sc7180.  Maybe you
could figure out how to apply it to your hardware?

...another fix would be to pretend that your panel is 8bpp even though
it's actually 6bpp.  Ironically if anyone ever tried to configure BPP
from the EDID they'd go back to 6bpp.  You can read the EDID of your
panel with this:

bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/')
i2cdump ${bus} 0x50 i

When I do that and then decode it on the "boe,nv133fhm-n62" panel, I find:

6 bits per primary color channel

-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes for 5.8-rc5

[pr-tracker-bot]

The pull request you sent on Fri, 10 Jul 2020 11:13:41 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-10

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/42f82040ee66db13525dc6f14b8559890b2f4c1c

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can

[Doug Anderson]

Hi,

On Thu, Jul 9, 2020 at 6:19 PM Steev Klimaszewski  wrote:
>
> Hi Doug,
>
> I've been testing 5.8 and linux-next on the Lenovo Yoga C630, and with this 
> patch applied, there is really bad banding on the display.
>
> I'm really bad at explaining it, but you can see the differences in the 
> following:
>
> 24bit (pre-5.8) - https://dev.gentoo.org/~steev/files/image0.jpg
>
> 18bit (5.8/linux-next) - https://dev.gentoo.org/~steev/files/image1.jpg

Presumably this means that your panel is defined improperly?  If the
panel reports that it's a 6 bits per pixel panel but it's actually an
8 bits per pixel panel then you'll run into this problem.

I would have to assume you have a bunch of out of tree patches to
support your hardware since I don't see any device trees in linuxnext
(other than cheza) that use this bridge chip.  Otherwise I could try
to check and confirm that was the problem.

-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_fb_helper: fix fbdev with sparc64

[kernel test robot]

Hi Sam,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-exynos/exynos-drm-next 
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.8-rc4 
next-20200709]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Sam-Ravnborg/drm-drm_fb_helper-fix-fbdev-with-sparc64/20200710-033231
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-s021-20200709 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-37-gc9676a3b-dirty
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/drm_fb_helper.c:386:29: sparse: sparse: incorrect type in 
>> argument 1 (different address spaces) @@ expected void volatile 
>> [noderef] __iomem * @@ got void *dst @@
>> drivers/gpu/drm/drm_fb_helper.c:386:29: sparse: expected void volatile 
>> [noderef] __iomem *
>> drivers/gpu/drm/drm_fb_helper.c:386:29: sparse: got void *dst

vim +386 drivers/gpu/drm/drm_fb_helper.c

   373  
   374  static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper 
*fb_helper,
   375struct drm_clip_rect *clip)
   376  {
   377  struct drm_framebuffer *fb = fb_helper->fb;
   378  unsigned int cpp = fb->format->cpp[0];
   379  size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
   380  void *src = fb_helper->fbdev->screen_buffer + offset;
   381  void *dst = fb_helper->buffer->vaddr + offset;
   382  size_t len = (clip->x2 - clip->x1) * cpp;
   383  unsigned int y;
   384  
   385  for (y = clip->y1; y < clip->y2; y++) {
 > 386  memcpy_toio(dst, src, len);
   387  src += fb->pitches[0];
   388  dst += fb->pitches[0];
   389  }
   390  }
   391  

---
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

[git pull] drm fixes for 5.8-rc5

[Dave Airlie]

Hi Linus,

I've been off most of the week, but some fixes have piled up. Seems a
bit busier than last week, but they are pretty spread out across a
bunch of drivers, none of them seem that big or worried me too much.

Regards,
Dave.

drm-fixes-2020-07-10:
drm fixes for 5.8-rc5

amdgpu:
- Fix a suspend/resume issue with PSP
- Backlight fix for Renoir
- Fix for gpu recovery debugging

radeon:
- Fix a double free in error path

i915:
- fbc fencing fix
- debugfs panic fix
- gem vma constuction fix
- gem pin under vm->nutex fix

nouveau:
- SVM fixes
- display fixes

meson:
- OSD burst length fixes

hibmc:
- runtime warning fix

mediatek:
- cmdq, mmsys fixes
- visibility check fixes
The following changes since commit dcb7fd82c75ee2d6e6f9d8cc71c52519ed52e258:

  Linux 5.8-rc4 (2020-07-05 16:20:22 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-10

for you to fetch changes up to 38794a5465b752118098e36cf95c59083f9f1f88:

  Merge tag 'amd-drm-fixes-5.8-2020-07-09' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-07-10
07:02:02 +1000)


drm fixes for 5.8-rc5

amdgpu:
- Fix a suspend/resume issue with PSP
- Backlight fix for Renoir
- Fix for gpu recovery debugging

radeon:
- Fix a double free in error path

i915:
- fbc fencing fix
- debugfs panic fix
- gem vma constuction fix
- gem pin under vm->nutex fix

nouveau:
- SVM fixes
- display fixes

meson:
- OSD burst length fixes

hibmc:
- runtime warning fix

mediatek:
- cmdq, mmsys fixes
- visibility check fixes


Aaron Ma (1):
  drm/amd/display: add dmcub check on RENOIR

Ben Skeggs (2):
  drm/nouveau/kms/nv50-: bail from nv50_audio_disable() early if
audio not enabled
  drm/nouveau/i2c/g94-: increase NV_PMGR_DP_AUXCTL_TRANSACTREQ timeout

Bernard Zhao (1):
  drm/mediatek: Remove unnecessary conversion to bool

Chris Wilson (4):
  drm/i915: Skip stale object handle for debugfs per-file-stats
  drm/i915: Drop vm.ref for duplicate vma on construction
  drm/i915: Also drop vm.ref along error paths for vma construction
  drm/i915/gt: Pin the rings before marking active

Dave Airlie (5):
  Merge tag 'mediatek-drm-fixes-5.8' of
https://git.kernel.org/.../chunkuang.hu/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2020-07-08' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'linux-5.8' of git://github.com/skeggsb/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2020-07-08' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'amd-drm-fixes-5.8-2020-07-09' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Enric Balletbo i Serra (3):
  drm/mediatek: Remove debug messages for function calls
  drm/mediatek: mtk_mt8173_hdmi_phy: Remove unnused const variables
  drm/mediatek: mtk_hdmi: Remove debug messages for function calls

Hsin-Yi Wang (2):
  drm/mediatek: Fix device passed to cmdq
  drm/mediatek: Check plane visibility in atomic_update

Huang Rui (2):
  drm/amdgpu: asd function needs to be unloaded in suspend phase
  drm/amdgpu: add TMR destory function for psp

Marek Olšák (1):
  drm/amdgpu: don't do soft recovery if gpu_recovery=0

Martin Blumenstingl (1):
  drm/meson: viu: fix setting the OSD burst length in
VIU_OSD1_FIFO_CTRL_STAT

Matthias Brugger (1):
  drm/mediatek: Delete not used of_device_get_match_data

Ralph Campbell (2):
  drm/nouveau/svm: fix migrate page regression
  drm/nouveau/nouveau: fix page fault on device private memory

Tom Rix (1):
  drm/radeon: fix double free

Ville Syrjälä (1):
  drm/i915/fbc: Fix fence_y_offset handling

YueHaibing (1):
  drm/mediatek: Fix Kconfig warning

Zenghui Yu (1):
  drm/hisilicon/hibmc: Move drm_fbdev_generic_setup() down to
avoid the splat

 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 63 --
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c|  5 +-
 drivers/gpu/drm/i915/display/intel_display.c   | 11 
 drivers/gpu/drm/i915/display/intel_display.h   |  1 +
 drivers/gpu/drm/i915/display/intel_fbc.c   | 32 ---
 drivers/gpu/drm/i915/gt/intel_context.c| 12 ++---
 drivers/gpu/drm/i915/i915_debugfs.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h|  6 +--
 drivers/gpu/drm/i915/i915_vma.c| 15 +++---
 drivers/gpu/drm/mediatek/Kconfig   |  2 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c|  8 +--
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  6 +--
 drivers/gpu/drm/mediatek/mtk_drm_plane.c   | 25 +
 drivers/gpu/drm/mediatek/mtk_dsi.c |  5 +-
 drivers/gpu/drm

Re: [PATCH v3 2/3] dt-bindings: display: convert samsung, s6e8aa0 to DT Schema

[Rob Herring]

On Sat, 04 Jul 2020 12:28:05 +0200, Sam Ravnborg wrote:
> v2:
>   - Add missing types (Rob)
>   - Fix example to specify panel@0 (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Rob Herring 
> Cc: Andrzej Hajda 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/samsung,s6e8aa0.txt |  56 --
>  .../display/panel/samsung,s6e8aa0.yaml| 100 ++
>  2 files changed, 100 insertions(+), 56 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/3] dt-bindings: display: convert panel bindings to DT Schema

[Rob Herring]

On Sat, Jul 04, 2020 at 12:34:08PM +0200, Sam Ravnborg wrote:
> On Sat, Jul 04, 2020 at 12:28:03PM +0200, Sam Ravnborg wrote:
> > This patch-set convert 3 of the remaining panel bindings to yaml.
> > 
> > This is a follow-up on v2 that converted a lot of panel bindings:
> > https://lore.kernel.org/dri-devel/20200408195109.32692-1-...@ravnborg.org/
> > All was applied except for the reaming three patches included here.
> > 
> > One binding is a DSI binding so just added to panel-simple-dsi.
> > The other two bindings addressed review feedback from Rob.
> > 
> > Sebastian Reichel has a pending patch to address the remaining
> > panel binding in display/panel/
> > 
> > All bindings pass dt-binding-check.
> > Based on top of drm-misc-next.
> > 
> > Sam
> > 
> > 
> > Sam Ravnborg (3):
> >   dt-bindings: display: convert innolux,p079zca to DT Schema
> >   dt-bindings: display: convert samsung,s6e8aa0 to DT Schema
> >   dt-bindings: display: convert sharp,lq101r1sx01 to DT Schema
> 
> git format-patch adds a space after the ',' - in the subject.
> This is often a good idea, but not for binding files.
> Will fix when I apply - if I do not forget that is..

Sure about that? I'm pretty sure it's dri-devel doing it. Look at 
lore.kernel.org copies for different lists. I've been fighting with that 
first in patchwork (which had this bug) and then in b4 (which is where 
it got nailed down to dri-devel).

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] dt-bindings: display: convert innolux, p079zca to DT Schema

[Rob Herring]

On Sat, 04 Jul 2020 12:28:04 +0200, Sam Ravnborg wrote:
> As the binding matches panel-simple-dsi, added the compatible to the
> panel-simple-dsi list.
> With this change enable-gpios is now optional.
> 
> v2:
>   - It is a DSI panel, add it to panel-simple-dsi (Rob)
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Rob Herring 
> Cc: Chris Zhong 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> ---
>  .../display/panel/innolux,p079zca.txt | 22 ---
>  .../display/panel/panel-simple-dsi.yaml   |  2 ++
>  2 files changed, 2 insertions(+), 22 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 4/5] dt-bindings: display: imx: add bindings for DCSS

[Rob Herring]

On Thu, Jul 09, 2020 at 07:47:32PM +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu 
> 
> Add bindings for iMX8MQ Display Controller Subsystem.
> 
> Signed-off-by: Laurentiu Palcu 
> ---
>  .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 84 +++
>  1 file changed, 84 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml 
> b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> new file mode 100644
> index ..a951409cf76d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> @@ -0,0 +1,84 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 NXP
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: iMX8MQ Display Controller Subsystem (DCSS)
> +
> +maintainers:
> +  - Laurentiu Palcu 
> +
> +description:
> +
> +  The DCSS (display controller sub system) is used to source up to three
> +  display buffers, compose them, and drive a display using HDMI 2.0a(with 
> HDCP
> +  2.2) or MIPI-DSI. The DCSS is intended to support up to 4kp60 displays. 
> HDR10
> +  image processing capabilities are included to provide a solution capable of
> +  driving next generation high dynamic range displays.
> +
> +properties:
> +  compatible:
> +const: nxp,imx8mq-dcss
> +
> +  reg:
> +items:
> +  - description: DCSS base address and size, up to IRQ steer start
> +  - description: DCSS BLKCTL base address and size
> +
> +  interrupts:
> +items:
> +  - description: Context loader completion and error interrupt
> +  - description: DTG interrupt used to signal context loader trigger time
> +  - description: DTG interrupt for Vblank
> +
> +  interrupt-names:
> +items:
> +  - const: ctxld
> +  - const: ctxld_kick
> +  - const: vblank
> +
> +  clocks:
> +items:
> +  - description: Display APB clock for all peripheral PIO access 
> interfaces
> +  - description: Display AXI clock needed by DPR, Scaler, RTRAM_CTRL
> +  - description: RTRAM clock
> +  - description: Pixel clock, can be driver either by HDMI phy clock or 
> MIPI
> +  - description: DTRC clock, needed by video decompressor
> +
> +  clock-names:
> +items:
> +  - const: apb
> +  - const: axi
> +  - const: rtrm
> +  - const: pix
> +  - const: dtrc
> +
> +  port:
> +type: object
> +description:
> +  A port node pointing to the input port of a HDMI/DP or MIPI display 
> bridge.

additionalProperties: false

With that,

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RFC v6 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties

[Rob Herring]

On Thu, Jul 02, 2020 at 06:37:19PM +0200, Sylwester Nawrocki wrote:
> Add documentation for new optional properties in the exynos bus nodes:
> samsung,interconnect-parent, #interconnect-cells, bus-width.
> These properties allow to specify the SoC interconnect structure which
> then allows the interconnect consumer devices to request specific
> bandwidth requirements.
> 
> Signed-off-by: Artur Świgoń 
> Signed-off-by: Sylwester Nawrocki 
> ---
> Changes for v6:
>  - added dts example of bus hierarchy definition and the interconnect
>consumer,
>  - added new bus-width property.
> 
> Changes for v5:
>  - exynos,interconnect-parent-node renamed to samsung,interconnect-parent
> ---
>  .../devicetree/bindings/devfreq/exynos-bus.txt | 68 
> +-
>  1 file changed, 66 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> index e71f752..4035e3e 100644
> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -51,6 +51,13 @@ Optional properties only for parent bus device:
>  - exynos,saturation-ratio: the percentage value which is used to calibrate
>   the performance count against total cycle count.
>  
> +Optional properties for interconnect functionality (QoS frequency 
> constraints):
> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
> +  passive devices should point to same node as the exynos,parent-bus 
> property.

Adding vendor specific properties for a common binding defeats the 
point.

> +- #interconnect-cells: should be 0.
> +- bus-width: the interconnect bus width in bits, default value is 8 when this
> +  property is missing.

Your bus is 8-bits or 4-bits as the example?

> +
>  Detailed correlation between sub-blocks and power line according to Exynos 
> SoC:
>  - In case of Exynos3250, there are two power line as following:
>   VDD_MIF |--- DMC
> @@ -135,7 +142,7 @@ Detailed correlation between sub-blocks and power line 
> according to Exynos SoC:
>   |--- PERIC (Fixed clock rate)
>   |--- FSYS  (Fixed clock rate)
>  
> -Example1:
> +Example 1:
>   Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
>   power line (regulator). The MIF (Memory Interface) AXI bus is used to
>   transfer data between DRAM and CPU and uses the VDD_MIF regulator.
> @@ -184,7 +191,7 @@ Example1:
>   |L5   |20 |20  |40 |30 |   ||100 |
>   --
>  
> -Example2 :
> +Example 2:
>   The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
>   is listed below:
>  
> @@ -419,3 +426,60 @@ Example2 :
>   devfreq = <&bus_leftbus>;
>   status = "okay";
>   };
> +
> +Example 3:
> + An interconnect path "bus_display -- bus_leftbus -- bus_dmc" on
> + Exynos4412 SoC with video mixer as an interconnect consumer device.
> +
> + soc {
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_dmc_opp_table>;
> + bus-width = <4>;
> + #interconnect-cells = <0>;
> + status = "disabled";
> + };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + samsung,interconnect-parent = <&bus_dmc>;
> + #interconnect-cells = <0>;
> + status = "disabled";
> + };
> +
> + bus_display: bus_display {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_ACLK160>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_display_opp_table>;
> + samsung,interconnect-parent = <&bus_leftbus>;
> + #interconnect-cells = <0>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + /* ... */
> + }
> +
> + bus_leftbus_opp_table: opp_table3 {
> + compatible = "operating-points-v2";
> + /* ... */
> + };
> +
> + bus_display_opp_table: opp_table4 {
> + compatible = "operating-points-v2";
> + /* .. */
> + };
> +
> + &mixer {
> +   

Re: [PATCH v7 1/2] dt-binding: Add DSI/LVDS TC358775 bridge bindings

[Rob Herring]

On Sat, 04 Jul 2020 14:54:39 +0530, Vinay Simha BN wrote:
> - converted from .txt to .yaml
> - dual-link lvds port added and implemented
> - dsi data-lanes property removed, it will be picked
>   from dsi0 ports
> - VESA/JEIDA formats picked from panel-lvds dts
> - proper indentation
> - single-link and dual-link lvds description and
>   examples are added
> - license modified to (GPL-2.0-only OR BSD-2-Clause)
> 
> Signed-off-by: Vinay Simha BN 
> 
> ---
> v1:
>  Initial version wast .txt file
> 
> v2:
>  From txt to yaml file format
> 
> v3:
> * Andrzej Hajda review comments incorporated
>   dual port lvds implemented
> 
> * Laurent Pinchart review comments incorporated
>   dsi lanes property removed and it is dynamically
>   picked from the dsi ports
>   VESA/JEIDA format picked from panel-lvds dts
> 
> v4:
> * Sam Ravnborg review comments incorporated
>   }' is indented properly in examples data-lanes
>   description for single-link and dual-link lvds
> 
> v5:
> * Sam Ravnborg review comments incorporated
>   license modified to (GPL-2.0-only OR BSD-2-Clause)
>   changelog added
> ---
>  .../display/bridge/toshiba,tc358775.yaml  | 215 ++
>  1 file changed, 215 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1] drm/msm: Fix a null pointer access in msm_gem_shrinker_count()

[Akhil P Oommen]

Adding an msm_gem_object object to the inactive_list before completing
its initialization is a bad idea because shrinker may pick it up from the
inactive_list. Fix this by making sure that the initialization is complete
before moving the msm_obj object to the inactive list.

This patch fixes the below error:
[10027.553044] Unable to handle kernel NULL pointer dereference at virtual 
address 0068
[10027.573305] Mem abort info:
[10027.590160]   ESR = 0x9606
[10027.597905]   EC = 0x25: DABT (current EL), IL = 32 bits
[10027.614430]   SET = 0, FnV = 0
[10027.624427]   EA = 0, S1PTW = 0
[10027.632722] Data abort info:
[10027.638039]   ISV = 0, ISS = 0x0006
[10027.647459]   CM = 0, WnR = 0
[10027.654345] user pgtable: 4k pages, 39-bit VAs, pgdp=0001e3a6a000
[10027.672681] [0068] pgd=000198c31003, pud=000198c31003, 
pmd=
[10027.693900] Internal error: Oops: 9606 [#1] PREEMPT SMP
[10027.738261] CPU: 3 PID: 214 Comm: kswapd0 Tainted: G S5.4.40 
#1
[10027.745766] Hardware name: Qualcomm Technologies, Inc. SC7180 IDP (DT)
[10027.752472] pstate: 80c9 (Nzcv daif +PAN +UAO)
[10027.757409] pc : mutex_is_locked+0x14/0x2c
[10027.761626] lr : msm_gem_shrinker_count+0x70/0xec
[10027.766454] sp : ffc011323ad0
[10027.769867] x29: ffc011323ad0 x28: ffe677e4b878
[10027.775324] x27: 0cc0 x26: 
[10027.780783] x25: ff817114a708 x24: 0008
[10027.786242] x23: ff8023ab7170 x22: 0001
[10027.791701] x21: ff817114a080 x20: 0119
[10027.797160] x19: 0068 x18: 03bc
[10027.802621] x17: 04a34210 x16: 00c0
[10027.808083] x15:  x14: 
[10027.813542] x13: ffe677e0a3c0 x12: 
[10027.819000] x11:  x10: ff8174b94340
[10027.824461] x9 :  x8 : 
[10027.829919] x7 : 01fc x6 : ffc011323c88
[10027.835373] x5 : 0001 x4 : ffc011323d80
[10027.840832] x3 : 0477b348 x2 : 
[10027.846290] x1 : ffc011323b68 x0 : 0068
[10027.851748] Call trace:
[10027.854264]  mutex_is_locked+0x14/0x2c
[10027.858121]  msm_gem_shrinker_count+0x70/0xec
[10027.862603]  shrink_slab+0xc0/0x4b4
[10027.866187]  shrink_node+0x4a8/0x818
[10027.869860]  kswapd+0x624/0x890
[10027.873097]  kthread+0x11c/0x12c
[10027.876424]  ret_from_fork+0x10/0x18
[10027.880102] Code: f9000bf3 910003fd aa0003f3 d503201f (f9400268)
[10027.886362] ---[ end trace df5849a1a3543251 ]---
[10027.891518] Kernel panic - not syncing: Fatal exception

Signed-off-by: Akhil P Oommen 
---
 drivers/gpu/drm/msm/msm_gem.c | 36 +---
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 6277fde..f63bb7e 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -994,10 +994,8 @@ int msm_gem_new_handle(struct drm_device *dev, struct 
drm_file *file,
 
 static int msm_gem_new_impl(struct drm_device *dev,
uint32_t size, uint32_t flags,
-   struct drm_gem_object **obj,
-   bool struct_mutex_locked)
+   struct drm_gem_object **obj)
 {
-   struct msm_drm_private *priv = dev->dev_private;
struct msm_gem_object *msm_obj;
 
switch (flags & MSM_BO_CACHE_MASK) {
@@ -1023,15 +1021,6 @@ static int msm_gem_new_impl(struct drm_device *dev,
INIT_LIST_HEAD(&msm_obj->submit_entry);
INIT_LIST_HEAD(&msm_obj->vmas);
 
-   if (struct_mutex_locked) {
-   WARN_ON(!mutex_is_locked(&dev->struct_mutex));
-   list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
-   } else {
-   mutex_lock(&dev->struct_mutex);
-   list_add_tail(&msm_obj->mm_list, &priv->inactive_list);
-   mutex_unlock(&dev->struct_mutex);
-   }
-
*obj = &msm_obj->base;
 
return 0;
@@ -1041,6 +1030,7 @@ static struct drm_gem_object *_msm_gem_new(struct 
drm_device *dev,
uint32_t size, uint32_t flags, bool struct_mutex_locked)
 {
struct msm_drm_private *priv = dev->dev_private;
+   struct msm_gem_object *msm_obj;
struct drm_gem_object *obj = NULL;
bool use_vram = false;
int ret;
@@ -1061,14 +1051,15 @@ static struct drm_gem_object *_msm_gem_new(struct 
drm_device *dev,
if (size == 0)
return ERR_PTR(-EINVAL);
 
-   ret = msm_gem_new_impl(dev, size, flags, &obj, struct_mutex_locked);
+   ret = msm_gem_new_impl(dev, size, flags, &obj);
if (ret)
goto fail;
 
+   msm_obj = to_msm_bo(obj);
+
if (use_vram) {
struct msm_gem_vma *vma;
struct page **pages;
-   struct msm_gem_object *msm_obj = to_msm_bo(obj);
 
mutex_lock(&msm_obj->l

Re: [PATCH v8 0/6] Add support for DisplayPort driver on SnapDragon

[Rob Herring]

On Tue, Jun 30, 2020 at 11:45:01AM -0700, Tanmay Shah wrote:
> These patches add Display-Port driver on SnapDragon/msm hardware.
> This series also contains device-tree bindings for msm DP driver.
> It also contains Makefile and Kconfig changes to compile msm DP driver.
> 
> The block diagram of DP driver is shown below:
> 
> 
>  +-+
>  |DRM FRAMEWORK|
>  +--+--+
> |
>+v+
>| DP DRM  |
>+++
> |
>+v+
>  ++|   DP+--++--+
>  ++---+| DISPLAY |+---+  |  |
>  |++-+-+-+|  |  |
>  ||  | |  |  |  |
>  ||  | |  |  |  |
>  ||  | |  |  |  |
>  vv  v v  v  v  v
>  +--+ +--+ +---+ ++ ++ +---+ +-+
>  |  DP  | |  DP  | |DP | | DP | | DP | |DP | | DP  |
>  |PARSER| | HPD  | |AUX| |LINK| |CTRL| |PHY| |POWER|
>  +--+---+ +---+--+ +---+ ++ +--+-+ +-+-+ +-+
> |  | |
>  +--v---+ +v-v+
>  |DEVICE| |  DP   |
>  | TREE | |CATALOG|
>  +--+ +---+---+
>   |
>   +---v+
>   |CTRL/PHY|
>   |   HW   |
>   ++
> 
> Changes in v7:
> 
> - Modify cover letter description and fix title.
> - Introduce dp-controller.yaml for common bindings across SOC
> - Rename dp-sc7180.yaml to dp-controller-sc7180.yaml for SC7180 bindings
> - Rename compatible string to qcom,sc7180-dp
> - Add assigned-clocks and assigned-clock-parents properties in bindings
> - Remove redundant code from driver
> - Extend series to include HPD detection logic
> 
> Changes in v8:
> 
> - Add MDSS AHB clock in bindings 
> - Replace mode->vrefresh use with drm_mode_vrefresh API
> - Remove redundant aux config code from parser and aux module
> - Assign default max lanes if data-lanes property is not available
> - Fix use-after-free during DP driver remove
> - Unregister hardware clocks during driver cleanup
> 
> This series depends-on:
>   https://patchwork.freedesktop.org/patch/366159/

If a single patch is a dependency, please coordinate your work and send 
as 1 series.

To put it another way, I'm just going to ignore this series until the 
dependency is sorted out.
 
>   https://patchwork.freedesktop.org/patch/369859/

Probably the same goes for this too, but I care less as it's not the 
binding...

> 
> Chandan Uddaraju (4):
>   dt-bindings: msm/dp: add bindings of DP/DP-PLL driver for Snapdragon
>   drm: add constant N value in helper file
>   drm/msm/dp: add displayPort driver support
>   drm/msm/dp: add support for DP PLL driver
> 
> Jeykumar Sankaran (1):
>   drm/msm/dpu: add display port support in DPU
> 
> Tanmay Shah (1):
>   drm/msm/dp: Add Display Port HPD feature
> 
>  .../display/msm/dp-controller-sc7180.yaml |  144 ++
>  .../bindings/display/msm/dp-controller.yaml   |   61 +
>  .../bindings/display/msm/dpu-sc7180.yaml  |   11 +
>  drivers/gpu/drm/i915/display/intel_display.c  |2 +-
>  drivers/gpu/drm/msm/Kconfig   |   16 +
>  drivers/gpu/drm/msm/Makefile  |   14 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |   29 +-
>  .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  |8 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   83 +-
>  drivers/gpu/drm/msm/dp/dp_aux.c   |  510 +
>  drivers/gpu/drm/msm/dp/dp_aux.h   |   29 +
>  drivers/gpu/drm/msm/dp/dp_catalog.c   | 1060 ++
>  drivers/gpu/drm/msm/dp/dp_catalog.h   |  104 +
>  drivers/gpu/drm/msm/dp/dp_ctrl.c  | 1707 +
>  drivers/gpu/drm/msm/dp/dp_ctrl.h  |   35 +
>  drivers/gpu/drm/msm/dp/dp_display.c   | 1017 ++
>  drivers/gpu/drm/msm/dp/dp_display.h   |   31 +
>  drivers/gpu/drm/msm/dp/dp_drm.c   |  168 ++
>  drivers/gpu/drm/msm/dp/dp_drm.h   |   18 +
>  drivers/gpu/drm/msm/dp/dp_hpd.c   |   69 +
>  drivers/gpu/drm/msm/dp/dp_hpd.h   |   79 +
>  drivers/gpu/drm/msm/dp/dp_link.c  | 1216 
>  drivers/gpu/drm/msm/dp/dp_link.h  |  132 ++
>  drivers/gpu/drm/msm/dp/dp_panel.c |  490 +
>  drivers/gpu/drm/msm/dp/dp_panel.h |   95 +
>  drivers/gpu/drm/msm/dp/dp_parser.c|  267 +++
>  drivers/gpu/drm/msm/dp/dp_parser.h|  138 ++
>  drivers/gpu/drm/msm/dp/dp_pll.c   |   99 +
>  drivers/gpu/drm/msm/dp/dp_pll.h   |   61 +
>  drivers/gpu/drm/msm/

[PATCH v4 2/7] drm: msm: a6xx: send opp instead of a frequency

[Akhil P Oommen]

From: Sharat Masetty 

This patch changes the plumbing to send the devfreq recommended opp rather
than the frequency. Also consolidate and rearrange the code in a6xx to set
the GPU frequency and the icc vote in preparation for the upcoming
changes for GPU->DDR scaling votes.

Signed-off-by: Sharat Masetty 
Signed-off-by: Akhil P Oommen 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 73 ---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h |  2 +-
 drivers/gpu/drm/msm/msm_gpu.c |  3 +-
 drivers/gpu/drm/msm/msm_gpu.h |  3 +-
 4 files changed, 38 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 21e77d6..233afea 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -103,17 +103,31 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
 }
 
-static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
+void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp)
 {
-   struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
-   struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
-   struct msm_gpu *gpu = &adreno_gpu->base;
-   int ret;
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+   struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
+   u32 perf_index;
+   unsigned long gpu_freq;
+   int ret = 0;
+
+   gpu_freq = dev_pm_opp_get_freq(opp);
+
+   if (gpu_freq == gmu->freq)
+   return;
+
+   for (perf_index = 0; perf_index < gmu->nr_gpu_freqs - 1; perf_index++)
+   if (gpu_freq == gmu->gpu_freqs[perf_index])
+   break;
+
+   gmu->current_perf_index = perf_index;
+   gmu->freq = gmu->gpu_freqs[perf_index];
 
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
 
gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
-   ((3 & 0xf) << 28) | index);
+   ((3 & 0xf) << 28) | perf_index);
 
/*
 * Send an invalid index as a vote for the bus bandwidth and let the
@@ -136,38 +150,6 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int 
index)
icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
 }
 
-void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq)
-{
-   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
-   struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
-   struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
-   u32 perf_index = 0;
-
-   if (freq == gmu->freq)
-   return;
-
-   for (perf_index = 0; perf_index < gmu->nr_gpu_freqs - 1; perf_index++)
-   if (freq == gmu->gpu_freqs[perf_index])
-   break;
-
-   gmu->current_perf_index = perf_index;
-   gmu->freq = gmu->gpu_freqs[perf_index];
-
-   /*
-* This can get called from devfreq while the hardware is idle. Don't
-* bring up the power if it isn't already active
-*/
-   if (pm_runtime_get_if_in_use(gmu->dev) == 0)
-   return;
-
-   if (gmu->legacy)
-   __a6xx_gmu_set_freq(gmu, perf_index);
-   else
-   a6xx_hfi_set_freq(gmu, perf_index);
-
-   pm_runtime_put(gmu->dev);
-}
-
 unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -839,6 +821,19 @@ static void a6xx_gmu_force_off(struct a6xx_gmu *gmu)
a6xx_gmu_rpmh_off(gmu);
 }
 
+static void a6xx_gmu_set_initial_freq(struct msm_gpu *gpu, struct a6xx_gmu 
*gmu)
+{
+   struct dev_pm_opp *gpu_opp;
+   unsigned long gpu_freq = gmu->gpu_freqs[gmu->current_perf_index];
+
+   gpu_opp = dev_pm_opp_find_freq_exact(&gpu->pdev->dev, gpu_freq, true);
+   if (IS_ERR_OR_NULL(gpu_opp))
+   return;
+
+   a6xx_gmu_set_freq(gpu, gpu_opp);
+   dev_pm_opp_put(gpu_opp);
+}
+
 int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
 {
struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
@@ -899,7 +894,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
 
/* Set the GPU to the current freq */
if (gmu->legacy)
-   __a6xx_gmu_set_freq(gmu, gmu->current_perf_index);
+   a6xx_gmu_set_initial_freq(gpu, gmu);
else
a6xx_hfi_set_freq(gmu, gmu->current_perf_index);
 
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index 7239b8b..03ba60d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -63,7 +63,7 @@ void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum 
a6xx_gmu_oob_state state);
 int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
 void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu);
 
-void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq);
+void a6xx_gmu_set

[PATCH v4 6/7] arm64: dts: qcom: sc7180: Add interconnects property for GPU

[Akhil P Oommen]

From: Sharat Masetty 

This patch adds the interconnects property to the GPU node. This enables
the GPU->DDR path bandwidth voting.

Signed-off-by: Sharat Masetty 
Signed-off-by: Akhil P Oommen 
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 31b9217..a567297 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1470,6 +1470,8 @@
operating-points-v2 = <&gpu_opp_table>;
qcom,gmu = <&gmu>;
 
+   interconnects = <&gem_noc MASTER_GFX3D &mc_virt 
SLAVE_EBI1>;
+
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 7/7] arm64: dts: qcom: sc7180: Add opp-peak-kBps to GPU opp

[Akhil P Oommen]

From: Sharat Masetty 

Add opp-peak-kBps bindings to the GPU opp table, listing the peak
GPU -> DDR bandwidth requirement for each opp level. This will be
used to scale the DDR bandwidth along with the GPU frequency dynamically.

Signed-off-by: Sharat Masetty 
Reviewed-by: Matthias Kaehlcke 
Signed-off-by: Akhil P Oommen 
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index a567297..8567e9e 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1478,36 +1478,43 @@
opp-8 {
opp-hz = /bits/ 64 <8>;
opp-level = 
;
+   opp-peak-kBps = <8532000>;
};
 
opp-65000 {
opp-hz = /bits/ 64 <65000>;
opp-level = 
;
+   opp-peak-kBps = <7216000>;
};
 
opp-56500 {
opp-hz = /bits/ 64 <56500>;
opp-level = ;
+   opp-peak-kBps = <5412000>;
};
 
opp-43000 {
opp-hz = /bits/ 64 <43000>;
opp-level = 
;
+   opp-peak-kBps = <5412000>;
};
 
opp-35500 {
opp-hz = /bits/ 64 <35500>;
opp-level = ;
+   opp-peak-kBps = <3072000>;
};
 
opp-26700 {
opp-hz = /bits/ 64 <26700>;
opp-level = 
;
+   opp-peak-kBps = <3072000>;
};
 
opp-18000 {
opp-hz = /bits/ 64 <18000>;
opp-level = 
;
+   opp-peak-kBps = <1804000>;
};
};
};
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 1/7] dt-bindings: drm/msm/gpu: Document gpu opp table

[Akhil P Oommen]

From: Sharat Masetty 

Update documentation to list the gpu opp table bindings including the
newly added "opp-peak-kBps" needed for GPU-DDR bandwidth scaling.

Signed-off-by: Sharat Masetty 
Acked-by: Rob Herring 
Signed-off-by: Akhil P Oommen 
---
 .../devicetree/bindings/display/msm/gpu.txt| 28 ++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index fd779cd..1af0ff1 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -112,6 +112,34 @@ Example a6xx (with GMU):
interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>;
interconnect-names = "gfx-mem";
 
+   gpu_opp_table: opp-table {
+   compatible = "operating-points-v2";
+
+   opp-43000 {
+   opp-hz = /bits/ 64 <43000>;
+   opp-level = ;
+   opp-peak-kBps = <5412000>;
+   };
+
+   opp-35500 {
+   opp-hz = /bits/ 64 <35500>;
+   opp-level = ;
+   opp-peak-kBps = <3072000>;
+   };
+
+   opp-26700 {
+   opp-hz = /bits/ 64 <26700>;
+   opp-level = ;
+   opp-peak-kBps = <3072000>;
+   };
+
+   opp-18000 {
+   opp-hz = /bits/ 64 <18000>;
+   opp-level = ;
+   opp-peak-kBps = <1804000>;
+   };
+   };
+
qcom,gmu = <&gmu>;
 
zap-shader {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 3/7] drm: msm: a6xx: set gpu freq through hfi

[Akhil P Oommen]

Newer targets support changing gpu frequency through HFI. So
use that wherever supported instead of the legacy method.

Signed-off-by: Akhil P Oommen 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 233afea..b547339 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -121,6 +121,12 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
dev_pm_opp *opp)
if (gpu_freq == gmu->gpu_freqs[perf_index])
break;
 
+   if (!gmu->legacy) {
+   a6xx_hfi_set_freq(gmu, gmu->current_perf_index);
+   icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+   return;
+   }
+
gmu->current_perf_index = perf_index;
gmu->freq = gmu->gpu_freqs[perf_index];
 
@@ -893,10 +899,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
enable_irq(gmu->hfi_irq);
 
/* Set the GPU to the current freq */
-   if (gmu->legacy)
-   a6xx_gmu_set_initial_freq(gpu, gmu);
-   else
-   a6xx_hfi_set_freq(gmu, gmu->current_perf_index);
+   a6xx_gmu_set_initial_freq(gpu, gmu);
 
/*
 * "enable" the GX power domain which won't actually do anything but it
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 0/7] Add support for GPU DDR BW scaling

[Akhil P Oommen]

This is mostly a rebase of Sharat's patches [1] on the tip of msm-next branch.
Changes compared to v3:
1. Rebased on top of Jonathan's patch which adds support for changing
gpu freq through hfi on newer targets. Created patch 1 to make
this the generic approach of setting gpu freq on newer targets.
2. As suggested by Rob, left the icc_path intact for pre-a6xx
GPUs.

As mentioned in [1], these patches have dependency on Georgi's series from
opp/linux-next [2] and also Sibi's patch which adds a helper function to
set and clear ddr bandwidth vote [2].

[1] https://patchwork.freedesktop.org/series/75291/
[2] 
https://kernel.googlesource.com/pub/scm/linux/kernel/git/vireshk/pm/+log/opp/linux-next/

Akhil P Oommen (1):
  drm: msm: a6xx: set gpu freq through hfi

Sharat Masetty (6):
  dt-bindings: drm/msm/gpu: Document gpu opp table
  drm: msm: a6xx: send opp instead of a frequency
  drm: msm: a6xx: use dev_pm_opp_set_bw to scale DDR
  arm64: dts: qcom: SDM845: Enable GPU DDR bw scaling
  arm64: dts: qcom: sc7180: Add interconnects property for GPU
  arm64: dts: qcom: sc7180: Add opp-peak-kBps to GPU opp

 .../devicetree/bindings/display/msm/gpu.txt|  28 ++
 arch/arm64/boot/dts/qcom/sc7180.dtsi   |   9 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi   |   9 ++
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  | 105 +++--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h  |   2 +-
 drivers/gpu/drm/msm/msm_gpu.c  |   3 +-
 drivers/gpu/drm/msm/msm_gpu.h  |   3 +-
 7 files changed, 106 insertions(+), 53 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 4/7] drm: msm: a6xx: use dev_pm_opp_set_bw to scale DDR

[Akhil P Oommen]

From: Sharat Masetty 

This patches replaces the previously used static DDR vote and uses
dev_pm_opp_set_bw() to scale GPU->DDR bandwidth along with scaling
GPU frequency. Also since the icc path voting is handled completely
in the opp driver, remove the icc_path handle and its usage in the
drm driver.

Signed-off-by: Sharat Masetty 
Signed-off-by: Akhil P Oommen 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index b547339..6fbfd7d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -123,7 +123,7 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
dev_pm_opp *opp)
 
if (!gmu->legacy) {
a6xx_hfi_set_freq(gmu, gmu->current_perf_index);
-   icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+   dev_pm_opp_set_bw(&gpu->pdev->dev, opp);
return;
}
 
@@ -149,11 +149,7 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
dev_pm_opp *opp)
if (ret)
dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
 
-   /*
-* Eventually we will want to scale the path vote with the frequency but
-* for now leave it at max so that the performance is nominal.
-*/
-   icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
+   dev_pm_opp_set_bw(&gpu->pdev->dev, opp);
 }
 
 unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
@@ -840,6 +836,19 @@ static void a6xx_gmu_set_initial_freq(struct msm_gpu *gpu, 
struct a6xx_gmu *gmu)
dev_pm_opp_put(gpu_opp);
 }
 
+static void a6xx_gmu_set_initial_bw(struct msm_gpu *gpu, struct a6xx_gmu *gmu)
+{
+   struct dev_pm_opp *gpu_opp;
+   unsigned long gpu_freq = gmu->gpu_freqs[gmu->current_perf_index];
+
+   gpu_opp = dev_pm_opp_find_freq_exact(&gpu->pdev->dev, gpu_freq, true);
+   if (IS_ERR_OR_NULL(gpu_opp))
+   return;
+
+   dev_pm_opp_set_bw(&gpu->pdev->dev, gpu_opp);
+   dev_pm_opp_put(gpu_opp);
+}
+
 int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
 {
struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
@@ -864,7 +873,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
}
 
/* Set the bus quota to a reasonable value for boot */
-   icc_set_bw(gpu->icc_path, 0, MBps_to_icc(3072));
+   a6xx_gmu_set_initial_bw(gpu, gmu);
 
/* Enable the GMU interrupt */
gmu_write(gmu, REG_A6XX_GMU_AO_HOST_INTERRUPT_CLR, ~0);
@@ -1040,7 +1049,7 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
a6xx_gmu_shutdown(gmu);
 
/* Remove the bus vote */
-   icc_set_bw(gpu->icc_path, 0, 0);
+   dev_pm_opp_set_bw(&gpu->pdev->dev, NULL);
 
/*
 * Make sure the GX domain is off before turning off the GMU (CX)
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 5/7] arm64: dts: qcom: SDM845: Enable GPU DDR bw scaling

[Akhil P Oommen]

From: Sharat Masetty 

This patch adds the interconnects property for the gpu node and the
opp-peak-kBps property to the opps of the gpu opp table. This should
help enable DDR bandwidth scaling dynamically and proportionally to the
GPU frequency.

Signed-off-by: Sharat Masetty 
Signed-off-by: Akhil P Oommen 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 8eb5a31..5e9561a 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -3515,42 +3515,51 @@
 
qcom,gmu = <&gmu>;
 
+   interconnects = <&mem_noc MASTER_GFX3D &mem_noc 
SLAVE_EBI1>;
+
gpu_opp_table: opp-table {
compatible = "operating-points-v2";
 
opp-71000 {
opp-hz = /bits/ 64 <71000>;
opp-level = 
;
+   opp-peak-kBps = <7216000>;
};
 
opp-67500 {
opp-hz = /bits/ 64 <67500>;
opp-level = 
;
+   opp-peak-kBps = <7216000>;
};
 
opp-59600 {
opp-hz = /bits/ 64 <59600>;
opp-level = 
;
+   opp-peak-kBps = <622>;
};
 
opp-52000 {
opp-hz = /bits/ 64 <52000>;
opp-level = ;
+   opp-peak-kBps = <622>;
};
 
opp-41400 {
opp-hz = /bits/ 64 <41400>;
opp-level = 
;
+   opp-peak-kBps = <4068000>;
};
 
opp-34200 {
opp-hz = /bits/ 64 <34200>;
opp-level = ;
+   opp-peak-kBps = <2724000>;
};
 
opp-25700 {
opp-hz = /bits/ 64 <25700>;
opp-level = 
;
+   opp-peak-kBps = <1648000>;
};
};
};
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/drm_fb_helper: fix fbdev with sparc64

[Sam Ravnborg]

Mark reported that sparc64 would panic while booting using qemu.
Mark bisected this to a patch that introduced generic fbdev emulation to
the bochs DRM driver.
Mark pointed out that a similar bug was fixed before where
the sys helpers was replaced by cfb helpers.

The culprint here is that the framebuffer reside in IO memory which
requires SPARC ASI_PHYS (physical) loads and stores.

The current bohcs DRM driver uses a shadow buffer.
So all copying to the framebuffer happens in
drm_fb_helper_dirty_blit_real().

The fix is to replace the memcpy with memcpy_toio() from io.h.

memcpy_toio() uses writeb() where the original fbdev code
used sbus_memcpy_toio(). The latter uses sbus_writeb().

The difference between writeb() and sbus_memcpy_toio() is
that writeb() writes bytes in little-endian, where sbus_writeb() writes
bytes in big-endian. As endian does not matter for byte writes they are
the same. So we can safely use memcpy_toio() here.

For many architectures memcpy_toio() is a simple memcpy().
One sideeffect that is unknow is if this has any impact on other
architectures.
So far the analysis tells that this change is OK for other arch's.
but testing would be good.

Signed-off-by: Sam Ravnborg 
Reported-by: Mark Cave-Ayland 
Tested-by: Mark Cave-Ayland 
Cc: Mark Cave-Ayland 
Cc: Thomas Zimmermann 
Cc: Gerd Hoffmann 
Cc: "David S. Miller" 
Cc: sparcli...@vger.kernel.org
---
 drivers/gpu/drm/drm_fb_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5609e164805f..4d05b0ab1592 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct 
drm_fb_helper *fb_helper,
unsigned int y;
 
for (y = clip->y1; y < clip->y2; y++) {
-   memcpy(dst, src, len);
+   memcpy_toio(dst, src, len);
src += fb->pitches[0];
dst += fb->pitches[0];
}
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu and radeon drm-fixes-5.8

[Alex Deucher]

Hi Dave, Daniel,

Fixes for 5.8.

The following changes since commit dcb7fd82c75ee2d6e6f9d8cc71c52519ed52e258:

  Linux 5.8-rc4 (2020-07-05 16:20:22 -0700)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.8-2020-07-09

for you to fetch changes up to f4892c327a8e5df7ce16cab40897daf90baf6bec:

  drm/amdgpu: don't do soft recovery if gpu_recovery=0 (2020-07-09 14:42:49 
-0400)


amd-drm-fixes-5.8-2020-07-09:

amdgpu:
- Fix a suspend/resume issue with PSP
- Backlight fix for Renoir
- Fix for gpu recovery debugging

radeon:
- Fix a double free in error path


Aaron Ma (1):
  drm/amd/display: add dmcub check on RENOIR

Huang Rui (2):
  drm/amdgpu: asd function needs to be unloaded in suspend phase
  drm/amdgpu: add TMR destory function for psp

Marek Olšák (1):
  drm/amdgpu: don't do soft recovery if gpu_recovery=0

Tom Rix (1):
  drm/radeon: fix double free

 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c   |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c   | 63 +--
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  2 +-
 drivers/gpu/drm/radeon/ci_dpm.c   |  7 ++-
 4 files changed, 65 insertions(+), 10 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/24] scsi: aacraid: commsup: Fix a bunch of function header issues

[Lee Jones]

Some parameters not documented.  Others misspelled.

Also, functions must follow directly after the header that documents them.

Fixes the following W=1 kernel build warning(s):

 drivers/scsi/aacraid/commsup.c:223: warning: Function parameter or member 
'scmd' not described in 'aac_fib_alloc_tag'
 drivers/scsi/aacraid/commsup.c:421: warning: Function parameter or member 
'qid' not described in 'aac_queue_get'
 drivers/scsi/aacraid/commsup.c:421: warning: Function parameter or member 
'hw_fib' not described in 'aac_queue_get'
 drivers/scsi/aacraid/commsup.c:421: warning: Excess function parameter 
'priority' description in 'aac_queue_get'
 drivers/scsi/aacraid/commsup.c:421: warning: Excess function parameter 'fib' 
description in 'aac_queue_get'
 drivers/scsi/aacraid/commsup.c:943: warning: Function parameter or member 
'fibptr' not described in 'aac_fib_complete'
 drivers/scsi/aacraid/commsup.c:943: warning: Excess function parameter 'fib' 
description in 'aac_fib_complete'
 drivers/scsi/aacraid/commsup.c:1061: warning: Excess function parameter 'dev' 
description in 'AIF_SNIFF_TIMEOUT'
 drivers/scsi/aacraid/commsup.c:1061: warning: Excess function parameter 
'fibptr' description in 'AIF_SNIFF_TIMEOUT'
 drivers/scsi/aacraid/commsup.c:2428: warning: Function parameter or member 
'data' not described in 'aac_command_thread'
 drivers/scsi/aacraid/commsup.c:2428: warning: Excess function parameter 'dev' 
description in 'aac_command_thread'

Cc: Adaptec OEM Raid Solutions 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: "PMC-Sierra, Inc" 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/scsi/aacraid/commsup.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c
index 8ee4e1abe568d..adbdc3b7c7a70 100644
--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -214,6 +214,7 @@ int aac_fib_setup(struct aac_dev * dev)
 /**
  * aac_fib_alloc_tag-allocate a fib using tags
  * @dev: Adapter to allocate the fib for
+ * @scmd: SCSI command
  *
  * Allocate a fib from the adapter fib pool using tags
  * from the blk layer.
@@ -405,8 +406,8 @@ static int aac_get_entry (struct aac_dev * dev, u32 qid, 
struct aac_entry **entr
  * aac_queue_get   -   get the next free QE
  * @dev: Adapter
  * @index: Returned index
- * @priority: Priority of fib
- * @fib: Fib to associate with the queue entry
+ * @qid: Queue number
+ * @hw_fib: Fib to associate with the queue entry
  * @wait: Wait if queue full
  * @fibptr: Driver fib object to go with fib
  * @nonotify: Don't notify the adapter
@@ -934,7 +935,7 @@ int aac_fib_adapter_complete(struct fib *fibptr, unsigned 
short size)
 
 /**
  * aac_fib_complete-   fib completion handler
- * @fib: FIB to complete
+ * @fibptr: FIB to complete
  *
  * Will do all necessary work to complete a FIB.
  */
@@ -1049,6 +1050,7 @@ static void aac_handle_aif_bu(struct aac_dev *dev, struct 
aac_aifcmd *aifcmd)
}
 }
 
+#define AIF_SNIFF_TIMEOUT  (500*HZ)
 /**
  * aac_handle_aif  -   Handle a message from the firmware
  * @dev: Which adapter this fib is from
@@ -1057,8 +1059,6 @@ static void aac_handle_aif_bu(struct aac_dev *dev, struct 
aac_aifcmd *aifcmd)
  * This routine handles a driver notify fib from the adapter and
  * dispatches it to the appropriate routine for handling.
  */
-
-#define AIF_SNIFF_TIMEOUT  (500*HZ)
 static void aac_handle_aif(struct aac_dev * dev, struct fib * fibptr)
 {
struct hw_fib * hw_fib = fibptr->hw_fib_va;
@@ -2416,7 +2416,7 @@ static int aac_send_hosttime(struct aac_dev *dev, struct 
timespec64 *now)
 
 /**
  * aac_command_thread  -   command processing thread
- * @dev: Adapter to monitor
+ * @data: Adapter to monitor
  *
  * Waits on the commandready event in it's queue. When the event gets set
  * it will pull FIBs off it's queue. It will continue to pull FIBs off
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix compare functions provided for sorting

[Chris Wilson]

Quoting Sudeep Holla (2020-07-09 16:49:31)
> Both cmp_u32 and cmp_u64 are comparing the pointers instead of the value
> at those pointers. This will result in incorrect/unsorted list. Fix it
> by deferencing the pointers before comparison.
> 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/gpu/drm/i915/gt/selftest_rps.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> Hi,
> 
> I am not sure if I can put 2 fixes tags, but these are the ones affected.
> 
> Fixes: 4ba74e53ada3 ("drm/i915/selftests: Verify frequency scaling with RPS")
> Fixes: 8757797ff9c9 ("drm/i915/selftests: Repeat the rps clock frequency 
> measurement")

Might as well tag the fixes, just in case anyone wants to use the tests.
 
> I made similar mistake and after I fixed it, just looked if there are any
> similar bugs and found this.
> 
> Regards,
> Sudeep
> 
> diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c 
> b/drivers/gpu/drm/i915/gt/selftest_rps.c
> index 5049c3dd08a6..c91981e75ebf 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_rps.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
> @@ -44,9 +44,9 @@ static int cmp_u64(const void *A, const void *B)
>  {
> const u64 *a = A, *b = B;
>  
> -   if (a < b)
> +   if (*a < *b)
> return -1;
> -   else if (a > b)
> +   else if (*a > *b)
> return 1;

Oh my golly gosh.

Thanks, thanks and thrice thanks.
Reviewed-by: Chris Wilson 

I better double check all my qsort-compare funcs for similar brianfarts.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 2/5] drm/imx: Add initial support for DCSS on iMX8MQ

[Laurentiu Palcu]

From: Laurentiu Palcu 

This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
Some of its capabilities include:
 * 4K@60fps;
 * HDR10;
 * one graphics and 2 video pipelines;
 * on-the-fly decompression of compressed video and graphics;

The reference manual can be found here:
https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM

The current patch adds only basic functionality: one primary plane for
graphics, linear, tiled and super-tiled buffers support (no graphics
decompression yet), no HDR10 and no video planes.

Video planes support and HDR10 will be added in subsequent patches once
per-plane de-gamma/CSC/gamma support is in.

Signed-off-by: Laurentiu Palcu 
---
 drivers/gpu/drm/imx/Kconfig|   2 +
 drivers/gpu/drm/imx/Makefile   |   1 +
 drivers/gpu/drm/imx/dcss/Kconfig   |   9 +
 drivers/gpu/drm/imx/dcss/Makefile  |   6 +
 drivers/gpu/drm/imx/dcss/dcss-blkctl.c |  70 +++
 drivers/gpu/drm/imx/dcss/dcss-crtc.c   | 219 +++
 drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 424 +
 drivers/gpu/drm/imx/dcss/dcss-dev.c| 314 ++
 drivers/gpu/drm/imx/dcss/dcss-dev.h| 177 ++
 drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 +
 drivers/gpu/drm/imx/dcss/dcss-drv.c| 138 +
 drivers/gpu/drm/imx/dcss/dcss-dtg.c| 409 
 drivers/gpu/drm/imx/dcss/dcss-kms.c| 177 ++
 drivers/gpu/drm/imx/dcss/dcss-kms.h|  43 ++
 drivers/gpu/drm/imx/dcss/dcss-plane.c  | 405 
 drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 +
 drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++
 17 files changed, 3962 insertions(+)
 create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig
 create mode 100644 drivers/gpu/drm/imx/dcss/Makefile
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c

diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 207bf7409dfb..6231048aa5aa 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -39,3 +39,5 @@ config DRM_IMX_HDMI
depends on DRM_IMX
help
  Choose this if you want to use HDMI on i.MX6.
+
+source "drivers/gpu/drm/imx/dcss/Kconfig"
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 21cdcc2faabc..b644deffe948 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
 obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
 
 obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
+obj-$(CONFIG_DRM_IMX_DCSS) += dcss/
diff --git a/drivers/gpu/drm/imx/dcss/Kconfig b/drivers/gpu/drm/imx/dcss/Kconfig
new file mode 100644
index ..988979bc22cc
--- /dev/null
+++ b/drivers/gpu/drm/imx/dcss/Kconfig
@@ -0,0 +1,9 @@
+config DRM_IMX_DCSS
+   tristate "i.MX8MQ DCSS"
+   select RESET_CONTROLLER
+   select IMX_IRQSTEER
+   select DRM_KMS_CMA_HELPER
+   depends on DRM && ARCH_MXC
+   help
+ Choose this if you have a NXP i.MX8MQ based system and want to use the
+ Display Controller Subsystem. This option enables DCSS support.
diff --git a/drivers/gpu/drm/imx/dcss/Makefile 
b/drivers/gpu/drm/imx/dcss/Makefile
new file mode 100644
index ..8c7c8da42792
--- /dev/null
+++ b/drivers/gpu/drm/imx/dcss/Makefile
@@ -0,0 +1,6 @@
+imx-dcss-objs := dcss-drv.o dcss-dev.o dcss-blkctl.o dcss-ctxld.o dcss-dtg.o \
+dcss-ss.o dcss-dpr.o dcss-scaler.o dcss-kms.o 
dcss-crtc.o \
+dcss-plane.o
+
+obj-$(CONFIG_DRM_IMX_DCSS) += imx-dcss.o
+
diff --git a/drivers/gpu/drm/imx/dcss/dcss-blkctl.c 
b/drivers/gpu/drm/imx/dcss/dcss-blkctl.c
new file mode 100644
index ..c9b54bb2692d
--- /dev/null
+++ b/drivers/gpu/drm/imx/dcss/dcss-blkctl.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include 
+#include 
+#include 
+
+#include "dcss-dev.h"
+
+#define DCSS_BLKCTL_RESET_CTRL 0x00
+#define   B_CLK_RESETN BIT(0)
+#define   APB_CLK_RESETN   BIT(1)
+#define   P_CLK_RESETN BIT(2)
+#define   RTR_CLK_RESETN   BIT(4)
+#define DCSS_BLKCTL_CONTROL0   0x10
+#define   HDMI_MIPI_CLK_SELBIT(0)
+#define   DISPMIX_REFCLK_SEL_POS   4
+#define   DISPMI

[PATCH v5 3/5] drm/imx/dcss: add component framework functionality

[Laurentiu Palcu]

From: Laurentiu Palcu 

Component framework is needed by HDP driver.

Signed-off-by: Laurentiu Palcu 
---
 drivers/gpu/drm/imx/dcss/dcss-drv.c | 89 ++---
 drivers/gpu/drm/imx/dcss/dcss-kms.c | 14 -
 drivers/gpu/drm/imx/dcss/dcss-kms.h |  4 +-
 3 files changed, 80 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/imx/dcss/dcss-drv.c 
b/drivers/gpu/drm/imx/dcss/dcss-drv.c
index 8dc2f85c514b..09d0ac28e28a 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-drv.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-drv.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "dcss-dev.h"
@@ -14,6 +15,8 @@
 struct dcss_drv {
struct dcss_dev *dcss;
struct dcss_kms_dev *kms;
+
+   bool is_componentized;
 };
 
 struct dcss_dev *dcss_drv_dev_to_dcss(struct device *dev)
@@ -30,30 +33,18 @@ struct drm_device *dcss_drv_dev_to_drm(struct device *dev)
return mdrv ? &mdrv->kms->base : NULL;
 }
 
-static int dcss_drv_platform_probe(struct platform_device *pdev)
+static int dcss_drv_init(struct device *dev, bool componentized)
 {
-   struct device *dev = &pdev->dev;
-   struct device_node *remote;
struct dcss_drv *mdrv;
int err = 0;
-   bool hdmi_output = true;
-
-   if (!dev->of_node)
-   return -ENODEV;
-
-   remote = of_graph_get_remote_node(dev->of_node, 0, 0);
-   if (!remote)
-   return -ENODEV;
-
-   hdmi_output = !of_device_is_compatible(remote, "fsl,imx8mq-nwl-dsi");
-
-   of_node_put(remote);
 
mdrv = kzalloc(sizeof(*mdrv), GFP_KERNEL);
if (!mdrv)
return -ENOMEM;
 
-   mdrv->dcss = dcss_dev_create(dev, hdmi_output);
+   mdrv->is_componentized = componentized;
+
+   mdrv->dcss = dcss_dev_create(dev, componentized);
if (IS_ERR(mdrv->dcss)) {
err = PTR_ERR(mdrv->dcss);
goto err;
@@ -61,7 +52,7 @@ static int dcss_drv_platform_probe(struct platform_device 
*pdev)
 
dev_set_drvdata(dev, mdrv);
 
-   mdrv->kms = dcss_kms_attach(mdrv->dcss);
+   mdrv->kms = dcss_kms_attach(mdrv->dcss, componentized);
if (IS_ERR(mdrv->kms)) {
err = PTR_ERR(mdrv->kms);
goto dcss_shutoff;
@@ -79,19 +70,73 @@ static int dcss_drv_platform_probe(struct platform_device 
*pdev)
return err;
 }
 
-static int dcss_drv_platform_remove(struct platform_device *pdev)
+static void dcss_drv_deinit(struct device *dev, bool componentized)
 {
-   struct dcss_drv *mdrv = dev_get_drvdata(&pdev->dev);
+   struct dcss_drv *mdrv = dev_get_drvdata(dev);
 
if (!mdrv)
-   return 0;
+   return;
 
-   dcss_kms_detach(mdrv->kms);
+   dcss_kms_detach(mdrv->kms, componentized);
dcss_dev_destroy(mdrv->dcss);
 
-   dev_set_drvdata(&pdev->dev, NULL);
+   dev_set_drvdata(dev, NULL);
 
kfree(mdrv);
+}
+
+static int dcss_drv_bind(struct device *dev)
+{
+   return dcss_drv_init(dev, true);
+}
+
+static void dcss_drv_unbind(struct device *dev)
+{
+   return dcss_drv_deinit(dev, true);
+}
+
+static const struct component_master_ops dcss_master_ops = {
+   .bind   = dcss_drv_bind,
+   .unbind = dcss_drv_unbind,
+};
+
+static int compare_of(struct device *dev, void *data)
+{
+   return dev->of_node == data;
+}
+
+static int dcss_drv_platform_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct component_match *match = NULL;
+   struct device_node *remote;
+
+   if (!dev->of_node)
+   return -ENODEV;
+
+   remote = of_graph_get_remote_node(dev->of_node, 0, 0);
+   if (!remote)
+   return -ENODEV;
+
+   if (of_device_is_compatible(remote, "fsl,imx8mq-nwl-dsi")) {
+   of_node_put(remote);
+   return dcss_drv_init(dev, false);
+   }
+
+   drm_of_component_match_add(dev, &match, compare_of, remote);
+   of_node_put(remote);
+
+   return component_master_add_with_match(dev, &dcss_master_ops, match);
+}
+
+static int dcss_drv_platform_remove(struct platform_device *pdev)
+{
+   struct dcss_drv *mdrv = dev_get_drvdata(&pdev->dev);
+
+   if (mdrv->is_componentized)
+   component_master_del(&pdev->dev, &dcss_master_ops);
+   else
+   dcss_drv_deinit(&pdev->dev, false);
 
return 0;
 }
diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c 
b/drivers/gpu/drm/imx/dcss/dcss-kms.c
index 3ca49d0a3e61..bb009f3a878f 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dcss-dev.h"
 #include "dcss-kms.h"
@@ -106,7 +107,7 @@ static int dcss_kms_setup_encoder(struct dcss_kms_dev *kms)
return drm_bridge_attach(encoder, bridge, NULL, 0);
 }
 
-struct dcss_kms_dev *dcss_kms_attach(struct dcss_dev *dcss)
+struct dcss_kms_dev *dcss_kms_attach(struct dcss

[PATCH v5 0/4] Add support for iMX8MQ Display Controller Subsystem

[Laurentiu Palcu]

From: Laurentiu Palcu 

Hi,

This patchset adds initial DCSS support for iMX8MQ chip. Initial support
includes only graphics plane support (no video planes), no HDR10 capabilities,
no graphics decompression (only linear, tiled and super-tiled buffers allowed).

Support for the rest of the features will be added incrementally, in subsequent
patches.

The patchset was tested with both HDP driver (in the downstream tree) and the 
upstream
MIPI-DSI driver (with a couple of patches on top, to make it work correctly 
with DCSS).

Thanks,
Laurentiu

Changes in v5:
 * Rebased to latest;
 * Took out component framework support and made it a separate patch so
   that people can still test with HDP driver, which makes use of it.
   But the idea is to get rid of it once HDP driver's next versions
   will remove component framework as well;
 * Slight improvement to modesetting: avoid cutting off the pixel clock
   if the new mode and the old one are equal. Also, in this case, is
   not necessary to wait for DTG to shut off. This would allow to switch
   from 8b RGB to 12b YUV422, for example, with no interruptions (at least
   from DCSS point of view);
 * Do not fire off CTXLD when going to suspend, unless it still has
   entries that need to be committed to DCSS;
 * Addressed Rob's comments on bindings;

Changes in v4:
 * Addressed Lucas and Philipp's comments:
   * Added DRM_KMS_CMA_HELPER dependency in Kconfig;
   * Removed usage of devm_ functions since I'm already doing all the
 clean-up in the submodules_deinit();
   * Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush();
   * Removed en_completion variable from dcss_crtc since this was
 introduced mainly to avoid vblank timeout warnings which were fixed
 by arming the vblank event in flush() instead of begin();
   * Removed clks_on and irq_enabled flags since all the calls to
 enabling/disabling clocks and interrupts were balanced;
   * Removed the custom atomic_commit callback and used the DRM core
 helper and, in the process, got rid of a workqueue that wasn't
 necessary anymore;
   * Fixed some minor DT binding issues flagged by Philipp;
   * Some other minor changes suggested by Lucas;
 * Removed YUV formats from the supported formats as these cannot work
   without the HDR10 module CSCs and LUTs. Will add them back when I
   will add support for video planes;

Changes in v3:
 * rebased to latest linux-next and made it compile as drmP.h was
   removed;
 * removed the patch adding the VIDEO2_PLL clock. It's already applied;
 * removed an unnecessary 50ms sleep in the dcss_dtg_sync_set();
 * fixed a a spurious hang reported by Lukas Hartmann and encountered
   by me several times;
 * mask DPR and DTG interrupts by default, as they may come enabled from
   U-boot;

Changes in v2:
 * Removed '0x' in node's unit-address both in DT and yaml;
 * Made the address region size lowercase, to be consistent;
 * Removed some left-over references to P010;
 * Added a Kconfig dependency of DRM && ARCH_MXC. This will also silence 
compilation
   issues reported by kbuild for other architectures;

Laurentiu Palcu (5):
  drm/imx: compile imx directory by default
  drm/imx: Add initial support for DCSS on iMX8MQ
  drm/imx/dcss: add component framework functionality
  dt-bindings: display: imx: add bindings for DCSS
  arm64: dts: imx8mq: add DCSS node

 .../bindings/display/imx/nxp,imx8mq-dcss.yaml |  84 ++
 arch/arm64/boot/dts/freescale/imx8mq.dtsi |  23 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/imx/Kconfig   |   2 +
 drivers/gpu/drm/imx/Makefile  |   1 +
 drivers/gpu/drm/imx/dcss/Kconfig  |   9 +
 drivers/gpu/drm/imx/dcss/Makefile |   6 +
 drivers/gpu/drm/imx/dcss/dcss-blkctl.c|  70 ++
 drivers/gpu/drm/imx/dcss/dcss-crtc.c  | 219 +
 drivers/gpu/drm/imx/dcss/dcss-ctxld.c | 424 +
 drivers/gpu/drm/imx/dcss/dcss-dev.c   | 314 +++
 drivers/gpu/drm/imx/dcss/dcss-dev.h   | 177 
 drivers/gpu/drm/imx/dcss/dcss-dpr.c   | 562 
 drivers/gpu/drm/imx/dcss/dcss-drv.c   | 183 
 drivers/gpu/drm/imx/dcss/dcss-dtg.c   | 409 +
 drivers/gpu/drm/imx/dcss/dcss-kms.c   | 185 
 drivers/gpu/drm/imx/dcss/dcss-kms.h   |  43 +
 drivers/gpu/drm/imx/dcss/dcss-plane.c | 405 +
 drivers/gpu/drm/imx/dcss/dcss-scaler.c| 826 ++
 drivers/gpu/drm/imx/dcss/dcss-ss.c| 180 
 20 files changed, 4123 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
 create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig
 create mode 100644 drivers/gpu/drm/imx/dcss/Makefile
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c
 create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c
 create mode 100644 dri

[PATCH v5 5/5] arm64: dts: imx8mq: add DCSS node

[Laurentiu Palcu]

From: Laurentiu Palcu 

This patch adds the node for iMX8MQ Display Controller Subsystem.

Signed-off-by: Laurentiu Palcu 
---
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 978f8122c0d2..022720cdf6ed 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1040,6 +1040,29 @@
#size-cells = <1>;
ranges = <0x32c0 0x32c0 0x40>;
 
+   dcss: display-controller@32e0 {
+   compatible = "nxp,imx8mq-dcss";
+   reg = <0x32e0 0x2d000>, <0x32e2f000 0x1000>;
+   interrupts = <6>, <8>, <9>;
+   interrupt-names = "ctxld", "ctxld_kick", 
"vblank";
+   interrupt-parent = <&irqsteer>;
+   clocks = <&clk IMX8MQ_CLK_DISP_APB_ROOT>,
+<&clk IMX8MQ_CLK_DISP_AXI_ROOT>,
+<&clk IMX8MQ_CLK_DISP_RTRM_ROOT>,
+<&clk IMX8MQ_VIDEO2_PLL_OUT>,
+<&clk IMX8MQ_CLK_DISP_DTRC>;
+   clock-names = "apb", "axi", "rtrm", "pix", 
"dtrc";
+   assigned-clocks = <&clk IMX8MQ_CLK_DISP_AXI>,
+ <&clk IMX8MQ_CLK_DISP_RTRM>,
+ <&clk 
IMX8MQ_VIDEO2_PLL1_REF_SEL>;
+   assigned-clock-parents = <&clk 
IMX8MQ_SYS1_PLL_800M>,
+<&clk 
IMX8MQ_SYS1_PLL_800M>,
+<&clk IMX8MQ_CLK_27M>;
+   assigned-clock-rates = <8>,
+  <4>;
+   status = "disabled";
+   };
+
irqsteer: interrupt-controller@32e2d000 {
compatible = "fsl,imx8m-irqsteer", 
"fsl,imx-irqsteer";
reg = <0x32e2d000 0x1000>;
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 4/5] dt-bindings: display: imx: add bindings for DCSS

[Laurentiu Palcu]

From: Laurentiu Palcu 

Add bindings for iMX8MQ Display Controller Subsystem.

Signed-off-by: Laurentiu Palcu 
---
 .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 84 +++
 1 file changed, 84 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml

diff --git a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml 
b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
new file mode 100644
index ..a951409cf76d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
@@ -0,0 +1,84 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 NXP
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: iMX8MQ Display Controller Subsystem (DCSS)
+
+maintainers:
+  - Laurentiu Palcu 
+
+description:
+
+  The DCSS (display controller sub system) is used to source up to three
+  display buffers, compose them, and drive a display using HDMI 2.0a(with HDCP
+  2.2) or MIPI-DSI. The DCSS is intended to support up to 4kp60 displays. HDR10
+  image processing capabilities are included to provide a solution capable of
+  driving next generation high dynamic range displays.
+
+properties:
+  compatible:
+const: nxp,imx8mq-dcss
+
+  reg:
+items:
+  - description: DCSS base address and size, up to IRQ steer start
+  - description: DCSS BLKCTL base address and size
+
+  interrupts:
+items:
+  - description: Context loader completion and error interrupt
+  - description: DTG interrupt used to signal context loader trigger time
+  - description: DTG interrupt for Vblank
+
+  interrupt-names:
+items:
+  - const: ctxld
+  - const: ctxld_kick
+  - const: vblank
+
+  clocks:
+items:
+  - description: Display APB clock for all peripheral PIO access interfaces
+  - description: Display AXI clock needed by DPR, Scaler, RTRAM_CTRL
+  - description: RTRAM clock
+  - description: Pixel clock, can be driver either by HDMI phy clock or 
MIPI
+  - description: DTRC clock, needed by video decompressor
+
+  clock-names:
+items:
+  - const: apb
+  - const: axi
+  - const: rtrm
+  - const: pix
+  - const: dtrc
+
+  port:
+type: object
+description:
+  A port node pointing to the input port of a HDMI/DP or MIPI display 
bridge.
+
+examples:
+  - |
+dcss: display-controller@32e0 {
+compatible = "nxp,imx8mq-dcss";
+reg = <0x32e0 0x2d000>, <0x32e2f000 0x1000>;
+interrupts = <6>, <8>, <9>;
+interrupt-names = "ctxld", "ctxld_kick", "vblank";
+interrupt-parent = <&irqsteer>;
+clocks = <&clk 248>, <&clk 247>, <&clk 249>,
+ <&clk 254>,<&clk 122>;
+clock-names = "apb", "axi", "rtrm", "pix", "dtrc";
+assigned-clocks = <&clk 107>, <&clk 109>, <&clk 266>;
+assigned-clock-parents = <&clk 78>, <&clk 78>, <&clk 3>;
+assigned-clock-rates = <8>,
+   <4>;
+port {
+dcss_out: endpoint {
+remote-endpoint = <&hdmi_in>;
+};
+};
+};
+
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 1/5] drm/imx: compile imx directory by default

[Laurentiu Palcu]

From: Laurentiu Palcu 

Currently the drm/imx/ directory is compiled only if DRM_IMX is set. Adding a
new IMX related IP in the same directory would need DRM_IMX to be set, which 
would
bring in also IPUv3 core driver...

The current patch would allow adding new IPs in the imx/ directory without 
needing
to set DRM_IMX.

Signed-off-by: Laurentiu Palcu 
---
 drivers/gpu/drm/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c0e5a7e5953..c4d12e756c63 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -100,7 +100,7 @@ obj-$(CONFIG_DRM_MSM) += msm/
 obj-$(CONFIG_DRM_TEGRA) += tegra/
 obj-$(CONFIG_DRM_STM) += stm/
 obj-$(CONFIG_DRM_STI) += sti/
-obj-$(CONFIG_DRM_IMX) += imx/
+obj-y  += imx/
 obj-$(CONFIG_DRM_INGENIC) += ingenic/
 obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
 obj-$(CONFIG_DRM_MESON)+= meson/
-- 
2.23.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/1] dt-bindings: fix simple-framebuffer example

[Rob Herring]

On Sat, Jul 4, 2020 at 3:26 PM Sam Ravnborg  wrote:
>
> On Sat, Jul 04, 2020 at 11:03:21PM +0200, Geert Uytterhoeven wrote:
> > Hi Sam,
> >
> > Thanks for your patch!
> >
> > On Sat, Jul 4, 2020 at 4:37 PM Sam Ravnborg  wrote:
> > > Now that dt-extract-example gained support for using root nodes
> > > in examples, update the example for the simple-frambuffer binding to use 
> > > it.
> >
> > simple-framebuffer
> Thanks, will fix.
>
> >
> > > This gives us a better example and kill a long standing warning:
> > >
> > > simple-framebuffer.example.dts:23.16-39.11:
> > > Warning (chosen_node_is_root): /example-0/chosen: chosen node must be at 
> > > root node
> > >
> > > Note: To get the update dt-extract-example execute:
> > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
> > > --upgrade
> > >
> > > Signed-off-by: Sam Ravnborg 
> >
> > > --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> > > +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
> > > @@ -152,28 +152,29 @@ additionalProperties: false
> > >
> > >  examples:
> > >- |
> > > -aliases {
> > > -  display0 = &lcdc0;
> >
> > Why drop the aliases example?
> I did not see it had any value for the binding that the example shall
> demonstrate. But it was not somthing I have given much thought of.

I don't think anything actually supports 'display' aliases and it is
beyond the scope of this binding, so I'd drop.

stdout-path should be dropped too as it points to this.

Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3 7/7] drm/msm/a6xx: Add support for using system cache(LLC)

[Jordan Crouse]

On Fri, Jul 03, 2020 at 09:04:49AM -0700, Rob Clark wrote:
> On Fri, Jul 3, 2020 at 7:53 AM Sai Prakash Ranjan
>  wrote:
> >
> > Hi Will,
> >
> > On 2020-07-03 19:07, Will Deacon wrote:
> > > On Mon, Jun 29, 2020 at 09:22:50PM +0530, Sai Prakash Ranjan wrote:
> > >> diff --git a/drivers/gpu/drm/msm/msm_iommu.c
> > >> b/drivers/gpu/drm/msm/msm_iommu.c
> > >> index f455c597f76d..bd1d58229cc2 100644
> > >> --- a/drivers/gpu/drm/msm/msm_iommu.c
> > >> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> > >> @@ -218,6 +218,9 @@ static int msm_iommu_map(struct msm_mmu *mmu,
> > >> uint64_t iova,
> > >>  iova |= GENMASK_ULL(63, 49);
> > >>
> > >>
> > >> +if (mmu->features & MMU_FEATURE_USE_SYSTEM_CACHE)
> > >> +prot |= IOMMU_SYS_CACHE_ONLY;
> > >
> > > Given that I think this is the only user of IOMMU_SYS_CACHE_ONLY, then
> > > it
> > > looks like it should actually be a property on the domain because we
> > > never
> > > need to configure it on a per-mapping basis within a domain, and
> > > therefore
> > > it shouldn't be exposed by the IOMMU API as a prot flag.
> > >
> > > Do you agree?
> > >
> >
> > GPU being the only user is for now, but there are other clients which
> > can use this.
> > Plus how do we set the memory attributes if we do not expose this as
> > prot flag?
> 
> It does appear that the downstream kgsl driver sets this for basically
> all mappings.. well there is some conditional stuff around
> DOMAIN_ATTR_USE_LLC_NWA but it seems based on the property of the
> domain.  (Jordan may know more about what that is about.)  But looks
> like there are a lot of different paths into iommu_map in kgsl so I
> might have missed something.

Downstream does set it universally. There are some theoretical use cases
where it might be beneficial to set it on a per-mapping basis with a bunch
of hinting from userspace and nobody has tried to characterize this on real
hardware so it is not clear to me if it is worth it.

I think a domain wide attribute works for now but if a compelling per-mapping
use case does comes down the pipeline we need to have a backup in mind -
possibly a prot flag to disable NWA?

Jordan

> Assuming there isn't some case where we specifically don't want to use
> the system cache for some mapping, I think it could be a domain
> attribute that sets an io_pgtable_cfg::quirks flag
> 
> BR,
> -R

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panfrost: fix ref count leak in panfrost_job_hw_submit

[Steven Price]

On 09/07/2020 16:44, Rob Herring wrote:

On Sun, Jun 14, 2020 at 12:27 AM Navid Emamdoost
 wrote:


in panfrost_job_hw_submit, pm_runtime_get_sync is called which
increments the counter even in case of failure, leading to incorrect
ref count. In case of failure, decrement the ref count before returning.

Signed-off-by: Navid Emamdoost 
---
  drivers/gpu/drm/panfrost/panfrost_job.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 7914b1570841..89ac84667eb1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -147,11 +147,10 @@ static void panfrost_job_hw_submit(struct panfrost_job 
*job, int js)

 ret = pm_runtime_get_sync(pfdev->dev);
 if (ret < 0)
-   return;
+   goto out;


If the get failed, I don't think we want to do a put.


The pm_runtime_get_sync() does actually always increment the reference 
(even when returning a failure), but actually I don't think we want it 
here anyway, as I think I explained before[1].
 [1] 
https://lore.kernel.org/dri-devel/272650ba-2c44-9084-7829-b04023eba...@arm.com




 if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js {
-   pm_runtime_put_sync_autosuspend(pfdev->dev);


This is a correct change - we don't want the put here. (Although this 
should never happen).



-   return;
+   goto out;
 }

 cfg = panfrost_mmu_as_get(pfdev, &job->file_priv->mmu);
@@ -184,6 +183,9 @@ static void panfrost_job_hw_submit(struct panfrost_job 
*job, int js)
 job, js, jc_head);

 job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START);


So we start the job here and then...


+out:
+   pm_runtime_put_sync_autosuspend(pfdev->dev);


...turn off clocks/power here. Typically, you'd be fine as autosuspend
has a delay by default, but userspace is free to change the delay to
0.


+   return;


A return at the end of the function with no argument is pointless.

Steve


  }

  static void panfrost_acquire_object_fences(struct drm_gem_object **bos,
--
2.17.1



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0

[Hans de Goede]

Hi,

On 7/9/20 4:50 PM, Andy Shevchenko wrote:

On Wed, Jul 08, 2020 at 11:14:22PM +0200, Hans de Goede wrote:

The datasheet specifies that programming the base_unit part of the
ctrl register to 0 results in a contineous low signal.

Adjust the get_state method to reflect this by setting pwm_state.period
to 1 and duty_cycle to 0.


...


+   if (freq == 0) {
+   /* In this case the PWM outputs a continous low signal */



+   state->period = 1;


I guess this should be something like half of the range (so base unit calc
will give 128). Because with period = 1 (too small) it will give too small
base unit (if apply) and as a result we get high frequency pulses.


You are right, that if after this the user only changes the duty-cycle
things will work very poorly, we will end up with a base_unit value of
e.g 65535 and then have almost no duty-cycle resolution at all.

How about using a value here which results in a base_unit value of
256 (for 16 bit base-unit registers), that is the highest frequency we
can do while still having full duty-cycle resolution and it also
is the power-on-reset value, so using a higher period which translates
to a base_unit value of 256 (the por calue) seems like a sensible thing to do.

Uwe what do you think about this?

Regards,

Hans






+   state->duty_cycle = 0;
+   } else {
state->period = NSEC_PER_SEC / (unsigned long)freq;
+   on_time_div *= state->period;
+   do_div(on_time_div, 255);
+   state->duty_cycle = on_time_div;
+   }




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panfrost: fix ref count leak in panfrost_job_hw_submit

[Rob Herring]

On Sun, Jun 14, 2020 at 12:27 AM Navid Emamdoost
 wrote:
>
> in panfrost_job_hw_submit, pm_runtime_get_sync is called which
> increments the counter even in case of failure, leading to incorrect
> ref count. In case of failure, decrement the ref count before returning.
>
> Signed-off-by: Navid Emamdoost 
> ---
>  drivers/gpu/drm/panfrost/panfrost_job.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
> b/drivers/gpu/drm/panfrost/panfrost_job.c
> index 7914b1570841..89ac84667eb1 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> @@ -147,11 +147,10 @@ static void panfrost_job_hw_submit(struct panfrost_job 
> *job, int js)
>
> ret = pm_runtime_get_sync(pfdev->dev);
> if (ret < 0)
> -   return;
> +   goto out;

If the get failed, I don't think we want to do a put.

>
> if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js {
> -   pm_runtime_put_sync_autosuspend(pfdev->dev);
> -   return;
> +   goto out;
> }
>
> cfg = panfrost_mmu_as_get(pfdev, &job->file_priv->mmu);
> @@ -184,6 +183,9 @@ static void panfrost_job_hw_submit(struct panfrost_job 
> *job, int js)
> job, js, jc_head);
>
> job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START);

So we start the job here and then...

> +out:
> +   pm_runtime_put_sync_autosuspend(pfdev->dev);

...turn off clocks/power here. Typically, you'd be fine as autosuspend
has a delay by default, but userspace is free to change the delay to
0.

> +   return;
>  }
>
>  static void panfrost_acquire_object_fences(struct drm_gem_object **bos,
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/20] Documentation: kbuild/kconfig-language: eliminate duplicated word

[Masahiro Yamada]

On Wed, Jul 8, 2020 at 3:06 AM Randy Dunlap  wrote:
>
> Drop the doubled word "the".
>
> Signed-off-by: Randy Dunlap 
> Cc: Jonathan Corbet 
> Cc: linux-...@vger.kernel.org
> Cc: Masahiro Yamada 



I guess this series will go in via the doc sub-system.

If so, please feel free to add:

Acked-by: Masahiro Yamada 






> Cc: Michal Marek 
> Cc: linux-kbu...@vger.kernel.org
> ---
>  Documentation/kbuild/kconfig-language.rst |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20200701.orig/Documentation/kbuild/kconfig-language.rst
> +++ linux-next-20200701/Documentation/kbuild/kconfig-language.rst
> @@ -681,7 +681,7 @@ translate Kconfig logic into boolean for
>  find dead code / features (always inactive), 114 dead features were found in
>  Linux using this methodology [1]_ (Section 8: Threats to validity).
>
> -Confirming this could prove useful as Kconfig stands as one of the the 
> leading
> +Confirming this could prove useful as Kconfig stands as one of the leading
>  industrial variability modeling languages [1]_ [2]_. Its study would help
>  evaluate practical uses of such languages, their use was only theoretical
>  and real world requirements were not well understood. As it stands though



--
Best Regards
Masahiro Yamada
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH 2/2] drm/amdgpu: stop allocating dummy GTT nodes v2

[Chauhan, Madhav]

[AMD Public Use]

-Original Message-
From: Christian König  
Sent: Thursday, July 9, 2020 8:40 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Chauhan, Madhav 
Subject: [PATCH 2/2] drm/amdgpu: stop allocating dummy GTT nodes v2

Now that TTM is fixed up we can finally stop that nonsense.

v2: Update the documentation as well.

LGTM, Reviewed-by: Madhav Chauhan 

Regards,
Madhav

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 106 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  18 +++-
 2 files changed, 43 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 2c20d23d62d1..0c44352ad5eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -150,60 +150,7 @@ static int amdgpu_gtt_mgr_fini(struct ttm_mem_type_manager 
*man)
  */
 bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_mem_reg *mem)  {
-   struct amdgpu_gtt_node *node = mem->mm_node;
-
-   return (node->node.start != AMDGPU_BO_INVALID_OFFSET);
-}
-
-/**
- * amdgpu_gtt_mgr_alloc - allocate new ranges
- *
- * @man: TTM memory type manager
- * @tbo: TTM BO we need this range for
- * @place: placement flags and restrictions
- * @mem: the resulting mem object
- *
- * Allocate the address space for a node.
- */
-static int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
-   struct ttm_buffer_object *tbo,
-   const struct ttm_place *place,
-   struct ttm_mem_reg *mem)
-{
-   struct amdgpu_device *adev = amdgpu_ttm_adev(man->bdev);
-   struct amdgpu_gtt_mgr *mgr = man->priv;
-   struct amdgpu_gtt_node *node = mem->mm_node;
-   enum drm_mm_insert_mode mode;
-   unsigned long fpfn, lpfn;
-   int r;
-
-   if (amdgpu_gtt_mgr_has_gart_addr(mem))
-   return 0;
-
-   if (place)
-   fpfn = place->fpfn;
-   else
-   fpfn = 0;
-
-   if (place && place->lpfn)
-   lpfn = place->lpfn;
-   else
-   lpfn = adev->gart.num_cpu_pages;
-
-   mode = DRM_MM_INSERT_BEST;
-   if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
-   mode = DRM_MM_INSERT_HIGH;
-
-   spin_lock(&mgr->lock);
-   r = drm_mm_insert_node_in_range(&mgr->mm, &node->node, mem->num_pages,
-   mem->page_alignment, 0, fpfn, lpfn,
-   mode);
-   spin_unlock(&mgr->lock);
-
-   if (!r)
-   mem->start = node->node.start;
-
-   return r;
+   return mem->mm_node != NULL;
 }
 
 /**
@@ -214,7 +161,7 @@ static int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager 
*man,
  * @place: placement flags and restrictions
  * @mem: the resulting mem object
  *
- * Dummy, allocate the node but no space for it yet.
+ * GTT accounting and GART node allocation if necessary.
  */
 static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager *man,
  struct ttm_buffer_object *tbo, @@ -234,29 +181,37 
@@ static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager *man,
atomic64_sub(mem->num_pages, &mgr->available);
spin_unlock(&mgr->lock);
 
+   if (!place->lpfn) {
+   mem->mm_node = NULL;
+   mem->start = AMDGPU_BO_INVALID_OFFSET;
+   return 0;
+   }
+
node = kzalloc(sizeof(*node), GFP_KERNEL);
if (!node) {
r = -ENOMEM;
goto err_out;
}
 
-   node->node.start = AMDGPU_BO_INVALID_OFFSET;
-   node->node.size = mem->num_pages;
node->tbo = tbo;
-   mem->mm_node = node;
 
-   if (place->fpfn || place->lpfn || place->flags & TTM_PL_FLAG_TOPDOWN) {
-   r = amdgpu_gtt_mgr_alloc(man, tbo, place, mem);
-   if (unlikely(r)) {
-   kfree(node);
-   mem->mm_node = NULL;
-   goto err_out;
-   }
-   } else {
-   mem->start = node->node.start;
-   }
+   spin_lock(&mgr->lock);
+   r = drm_mm_insert_node_in_range(&mgr->mm, &node->node, mem->num_pages,
+   mem->page_alignment, 0, place->fpfn,
+   place->lpfn, DRM_MM_INSERT_BEST);
+   spin_unlock(&mgr->lock);
+
+   if (unlikely(r))
+   goto err_free;
+
+   mem->mm_node = node;
+   mem->start = node->node.start;
 
return 0;
+
+err_free:
+   kfree(node);
+
 err_out:
atomic64_add(mem->num_pages, &mgr->available);
 
@@ -279,17 +234,14 @@ static void amdgpu_gtt_mgr_del(struct 
ttm_mem_type_manager *man,
struct amdgpu_gtt_mgr *mgr = man->priv;
struct amdgpu_gtt_node *node = mem->mm_node;
 
-   if (!node)
-   return;
-
-   spin_lock(&

RE: [PATCH 1/2] drm/ttm: further cleanup ttm_mem_reg handling

[Chauhan, Madhav]

[AMD Public Use]

-Original Message-
From: Christian König  
Sent: Thursday, July 9, 2020 8:40 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: Chauhan, Madhav 
Subject: [PATCH 1/2] drm/ttm: further cleanup ttm_mem_reg handling

Stop touching the backend private pointer alltogether and make sure we never 
put the same mem twice by.

Signed-off-by: Christian König 

Thanks for clarification earlier, Looks fine to me.
Reviewed-by: Madhav Chauhan 

---
 drivers/gpu/drm/ttm/ttm_bo.c| 46 +++--
 include/drm/ttm/ttm_bo_driver.h |  2 --
 2 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 
0c13fe96c7e3..7be36b9996ed 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -312,7 +312,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
if (bdev->driver->move_notify)
bdev->driver->move_notify(bo, evict, mem);
bo->mem = *mem;
-   mem->mm_node = NULL;
goto moved;
}
}
@@ -616,7 +615,6 @@ static void ttm_bo_release(struct kref *kref)
ttm_bo_cleanup_memtype_use(bo);
dma_resv_unlock(bo->base.resv);
 
-   BUG_ON(bo->mem.mm_node != NULL);
atomic_dec(&ttm_bo_glob.bo_count);
dma_fence_put(bo->moving);
if (!ttm_bo_uses_embedded_gem_object(bo))
@@ -843,12 +841,29 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
return ret;
 }
 
+static int ttm_bo_mem_get(struct ttm_buffer_object *bo,
+ const struct ttm_place *place,
+ struct ttm_mem_reg *mem)
+{
+   struct ttm_mem_type_manager *man = &bo->bdev->man[mem->mem_type];
+
+   mem->mm_node = NULL;
+   if (!man->func || !man->func->get_node)
+   return 0;
+
+   return man->func->get_node(man, bo, place, mem); }
+
 void ttm_bo_mem_put(struct ttm_buffer_object *bo, struct ttm_mem_reg *mem)  {
struct ttm_mem_type_manager *man = &bo->bdev->man[mem->mem_type];
 
-   if (mem->mm_node)
-   (*man->func->put_node)(man, mem);
+   if (!man->func || !man->func->put_node)
+   return;
+
+   man->func->put_node(man, mem);
+   mem->mm_node = NULL;
+   mem->mem_type = TTM_PL_SYSTEM;
 }
 EXPORT_SYMBOL(ttm_bo_mem_put);
 
@@ -902,7 +917,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
 
ticket = dma_resv_locking_ctx(bo->base.resv);
do {
-   ret = (*man->func->get_node)(man, bo, place, mem);
+   ret = ttm_bo_mem_get(bo, place, mem);
if (likely(!ret))
break;
if (unlikely(ret != -ENOSPC))
@@ -1032,7 +1047,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (unlikely(ret))
return ret;
 
-   mem->mm_node = NULL;
for (i = 0; i < placement->num_placement; ++i) {
const struct ttm_place *place = &placement->placement[i];
struct ttm_mem_type_manager *man;
@@ -1044,20 +1058,16 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
 
type_found = true;
-   mem->mm_node = NULL;
-   if (mem->mem_type == TTM_PL_SYSTEM)
-   return 0;
-
-   man = &bdev->man[mem->mem_type];
-   ret = (*man->func->get_node)(man, bo, place, mem);
+   ret = ttm_bo_mem_get(bo, place, mem);
if (ret == -ENOSPC)
continue;
if (unlikely(ret))
goto error;
 
+   man = &bdev->man[mem->mem_type];
ret = ttm_bo_add_move_fence(bo, man, mem, ctx->no_wait_gpu);
if (unlikely(ret)) {
-   (*man->func->put_node)(man, mem);
+   ttm_bo_mem_put(bo, mem);
if (ret == -EBUSY)
continue;
 
@@ -1076,12 +1086,8 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
 
type_found = true;
-   mem->mm_node = NULL;
-   if (mem->mem_type == TTM_PL_SYSTEM)
-   return 0;
-
ret = ttm_bo_mem_force_space(bo, place, mem, ctx);
-   if (ret == 0 && mem->mm_node)
+   if (likely(!ret))
return 0;
 
if (ret && ret != -EBUSY)
@@ -1129,7 +1135,7 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object 
*bo,
goto out_unlock;
ret = ttm_bo_handle_move_mem(bo, &mem, false, ctx);
 out_unlock:
-   if (ret && mem.mm_node)
+   if (ret)
ttm_bo_mem_put(bo, &mem);
return ret;
 }
@@ -1144,7 +1150,7 @@ static bool ttm_bo_places

Re: [PATCH v4 00/15] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

[Sam Ravnborg]

Hi,
On Thu, Jul 09, 2020 at 04:40:56PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 7/9/20 4:14 PM, Sam Ravnborg wrote:
> > Hi Hans.
> > 
> > On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
> > > Hi All,
> > > 
> > > Here is v4 of my patch series converting the i915 driver's code for
> > > controlling the panel's backlight with an external PWM controller to
> > > use the atomic PWM API. See below for the changelog.
> > 
> > Why is it that i915 cannot use the pwm_bl driver for backlight?
> > I have not studied the code - just wondering.
> 
> The intel_panel.c code deals with 7 different types of PWM controllers
> which are built into the GPU + support for external PWM controllers
> through the kernel's PWM subsystem.
> 
> pwm_bl will work for the external PWM controller case, but not for
> the others. On top of that the intel_panel code integrates which
> the video BIOS, getting things like frequency, minimum value
> and if the range is inverted (0% duty == backlight brightness max).
> I'm not even sure if pwm_bl supports all of this, but even if it
> does the intel_panel code handles this in a unified manner for
> all supported PWM controllers, including the ones which are
> an integral part of the GPU.

Thanks for the explanation.
This is a more complicated world than the usual embedded case with a
single pwm, no BIOS etc. So it makes sense.

Sam

> 
> Regards,
> 
> Hans
> 
> 
> 
> > > Initially the plan was for this series to consist of 2 parts:
> > > 1. convert the pwm-crc driver to support the atomic PWM API and
> > > 2. convert the i915 driver's PWM code to use the atomic PWM API.
> > > 
> > > But during testing I've found a number of bugs in the pwm-lpss and I
> > > found that the acpi_lpss code needs some special handling because of
> > > some ugliness found in most Cherry Trail DSDTs.
> > > 
> > > So now this series has grown somewhat large and consists of 4 parts:
> > > 
> > > 1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness
> > > 2. various fixes to the pwm-lpss driver
> > > 3. convert the pwm-crc driver to support the atomic PWM API and
> > > 4. convert the i915 driver's PWM code to use the atomic PWM API
> > > 
> > > The involved acpi_lpss and pwm drivers do not see a whole lot of churn,
> > > so the plan is to merge this all through drm-intel-next-queued (dinq)
> > > once all the patches are reviewed / have acks.
> > > 
> > > In v4 the ACPI patches have been Acked by Rafael and the i915 patches
> > > have been acked by Jani. So that just leaves the PWM patches.
> > > 
> > > Uwe can I get your ok / ack for merging this through the dinq branch
> > > once you have acked al the PWM patches ?
> > > 
> > > This series has been tested (and re-tested after adding various bug-fixes)
> > > extensively. It has been tested on the following devices:
> > > 
> > > -Asus T100TA  BYT + CRC-PMIC PWM
> > > -Toshiba WT8-A  BYT + CRC-PMIC PWM
> > > -Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM
> > > -Asus T100HA  CHT + CRC-PMIC PWM
> > > -Terra Pad 1061  BYT + LPSS PWM
> > > -Trekstor Twin 10.1 BYT + LPSS PWM
> > > -Asus T101HA  CHT + CRC-PMIC PWM
> > > -GPD Pocket  CHT + CRC-PMIC PWM
> > > 
> > > Changelog:
> > > 
> > > Changes in v2:
> > > - Fix coverletter subject
> > > - Drop accidentally included debugging patch
> > > - "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only 
> > > once (
> > >- Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX
> > > 
> > > Changes in v3:
> > > - "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit 
> > > register value"
> > >- Use base_unit_range - 1 as maximum value for the clamp()
> > > - "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state 
> > > on resume"
> > >- This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the 
> > > PWM"
> > >  patch from previous versions of this patch-set, which really was a 
> > > hack
> > >  working around the resume issue which this patch fixes properly.
> > > - PATCH v3 6 - 11 pwm-crc changes:
> > >- Various small changes resulting from the reviews by Andy and Uwe,
> > >  including some refactoring of the patches to reduce the amount of 
> > > churn
> > >  in the patch-set
> > > 
> > > Changes in v4:
> > > - "[PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 
> > > 0"
> > >- This is a new patch in v4 of this patchset
> > > - "[PATCH v4 12/16] pwm: crc: Implement get_state() method"
> > >- Use DIV_ROUND_UP when calculating the period and duty_cycle values
> > > - "[PATCH v4 16/16] drm/i915: panel: Use atomic PWM API for devs with an 
> > > external PWM controller"
> > >- Add a note to the commit message about the changes in 
> > > pwm_disable_backlight()
> > >- Use the pwm_set/get_relative_duty_cycle() helpers
> > > 
> > > Regards,
> > > 
> > > Hans
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lis

Re: [PATCH v2] drm/msm: handle for EPROBE_DEFER for of_icc_get

[Rob Clark]

On Thu, Jul 9, 2020 at 7:35 AM Jonathan Marek  wrote:
>
> Check for errors instead of silently not using icc if the msm driver
> probes before the interconnect driver.
>
> Allow ENODATA for ocmem path, as it is optional and this error
> is returned when "gfx-mem" path is provided but not "ocmem".
>
> Remove the WARN_ON in msm_gpu_cleanup because INIT_LIST_HEAD won't have
> been called on the list yet when going through the defer error path.
>
> Changes in v2:
> * Changed to not only check for EPROBE_DEFER
>
> Signed-off-by: Jonathan Marek 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 17 ++---
>  drivers/gpu/drm/msm/msm_gpu.c   |  2 --
>  2 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 89673c7ed473..0f5217202eb5 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -940,12 +940,20 @@ static int adreno_get_pwrlevels(struct device *dev,
>  */
> gpu->icc_path = of_icc_get(dev, NULL);
> }
> -   if (IS_ERR(gpu->icc_path))
> +   if (IS_ERR(gpu->icc_path)) {
> +   ret = PTR_ERR(gpu->icc_path);
> gpu->icc_path = NULL;
> +   return ret;
> +   }
>
> gpu->ocmem_icc_path = of_icc_get(dev, "ocmem");
> -   if (IS_ERR(gpu->ocmem_icc_path))
> +   if (IS_ERR(gpu->ocmem_icc_path)) {
> +   ret = PTR_ERR(gpu->ocmem_icc_path);
> gpu->ocmem_icc_path = NULL;
> +   /* allow -ENODATA, ocmem icc is optional */
> +   if (ret != -ENODATA)
> +   return ret;
> +   }
>
> return 0;
>  }
> @@ -996,6 +1004,7 @@ int adreno_gpu_init(struct drm_device *drm, struct 
> platform_device *pdev,
> struct adreno_platform_config *config = pdev->dev.platform_data;
> struct msm_gpu_config adreno_gpu_config  = { 0 };
> struct msm_gpu *gpu = &adreno_gpu->base;
> +   int ret;
>
> adreno_gpu->funcs = funcs;
> adreno_gpu->info = adreno_info(config->rev);
> @@ -1007,7 +1016,9 @@ int adreno_gpu_init(struct drm_device *drm, struct 
> platform_device *pdev,
>
> adreno_gpu_config.nr_rings = nr_rings;
>
> -   adreno_get_pwrlevels(&pdev->dev, gpu);
> +   ret = adreno_get_pwrlevels(&pdev->dev, gpu);
> +   if (ret)
> +   return ret;
>
> pm_runtime_set_autosuspend_delay(&pdev->dev,
> adreno_gpu->info->inactive_period);
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index a22d30622306..ccf9a0dd9706 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -959,8 +959,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
>
> DBG("%s", gpu->name);
>
> -   WARN_ON(!list_empty(&gpu->active_list));
> -

hmm, not a huge fan of removing the WARN_ON().. can we just init the
list head earlier?

BR,
-R

> for (i = 0; i < ARRAY_SIZE(gpu->rb); i++) {
> msm_ringbuffer_destroy(gpu->rb[i]);
> gpu->rb[i] = NULL;
> --
> 2.26.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/ttm: further cleanup ttm_mem_reg handling

[Christian König]

Stop touching the backend private pointer alltogether and
make sure we never put the same mem twice by.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c| 46 +++--
 include/drm/ttm/ttm_bo_driver.h |  2 --
 2 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0c13fe96c7e3..7be36b9996ed 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -312,7 +312,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
if (bdev->driver->move_notify)
bdev->driver->move_notify(bo, evict, mem);
bo->mem = *mem;
-   mem->mm_node = NULL;
goto moved;
}
}
@@ -616,7 +615,6 @@ static void ttm_bo_release(struct kref *kref)
ttm_bo_cleanup_memtype_use(bo);
dma_resv_unlock(bo->base.resv);
 
-   BUG_ON(bo->mem.mm_node != NULL);
atomic_dec(&ttm_bo_glob.bo_count);
dma_fence_put(bo->moving);
if (!ttm_bo_uses_embedded_gem_object(bo))
@@ -843,12 +841,29 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
return ret;
 }
 
+static int ttm_bo_mem_get(struct ttm_buffer_object *bo,
+ const struct ttm_place *place,
+ struct ttm_mem_reg *mem)
+{
+   struct ttm_mem_type_manager *man = &bo->bdev->man[mem->mem_type];
+
+   mem->mm_node = NULL;
+   if (!man->func || !man->func->get_node)
+   return 0;
+
+   return man->func->get_node(man, bo, place, mem);
+}
+
 void ttm_bo_mem_put(struct ttm_buffer_object *bo, struct ttm_mem_reg *mem)
 {
struct ttm_mem_type_manager *man = &bo->bdev->man[mem->mem_type];
 
-   if (mem->mm_node)
-   (*man->func->put_node)(man, mem);
+   if (!man->func || !man->func->put_node)
+   return;
+
+   man->func->put_node(man, mem);
+   mem->mm_node = NULL;
+   mem->mem_type = TTM_PL_SYSTEM;
 }
 EXPORT_SYMBOL(ttm_bo_mem_put);
 
@@ -902,7 +917,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
 
ticket = dma_resv_locking_ctx(bo->base.resv);
do {
-   ret = (*man->func->get_node)(man, bo, place, mem);
+   ret = ttm_bo_mem_get(bo, place, mem);
if (likely(!ret))
break;
if (unlikely(ret != -ENOSPC))
@@ -1032,7 +1047,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (unlikely(ret))
return ret;
 
-   mem->mm_node = NULL;
for (i = 0; i < placement->num_placement; ++i) {
const struct ttm_place *place = &placement->placement[i];
struct ttm_mem_type_manager *man;
@@ -1044,20 +1058,16 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
 
type_found = true;
-   mem->mm_node = NULL;
-   if (mem->mem_type == TTM_PL_SYSTEM)
-   return 0;
-
-   man = &bdev->man[mem->mem_type];
-   ret = (*man->func->get_node)(man, bo, place, mem);
+   ret = ttm_bo_mem_get(bo, place, mem);
if (ret == -ENOSPC)
continue;
if (unlikely(ret))
goto error;
 
+   man = &bdev->man[mem->mem_type];
ret = ttm_bo_add_move_fence(bo, man, mem, ctx->no_wait_gpu);
if (unlikely(ret)) {
-   (*man->func->put_node)(man, mem);
+   ttm_bo_mem_put(bo, mem);
if (ret == -EBUSY)
continue;
 
@@ -1076,12 +1086,8 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
 
type_found = true;
-   mem->mm_node = NULL;
-   if (mem->mem_type == TTM_PL_SYSTEM)
-   return 0;
-
ret = ttm_bo_mem_force_space(bo, place, mem, ctx);
-   if (ret == 0 && mem->mm_node)
+   if (likely(!ret))
return 0;
 
if (ret && ret != -EBUSY)
@@ -1129,7 +1135,7 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object 
*bo,
goto out_unlock;
ret = ttm_bo_handle_move_mem(bo, &mem, false, ctx);
 out_unlock:
-   if (ret && mem.mm_node)
+   if (ret)
ttm_bo_mem_put(bo, &mem);
return ret;
 }
@@ -1144,7 +1150,7 @@ static bool ttm_bo_places_compat(const struct ttm_place 
*places,
for (i = 0; i < num_placement; i++) {
const struct ttm_place *heap = &places[i];
 
-   if (mem->mm_node && (mem->start < heap->fpfn ||
+   if ((mem->start < heap->fpfn ||
 (heap->lpfn != 0 && (mem->start + mem->num_pages) > 
heap->lpfn))

[PATCH 2/2] drm/amdgpu: stop allocating dummy GTT nodes v2

[Christian König]

Now that TTM is fixed up we can finally stop that nonsense.

v2: Update the documentation as well.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 106 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  18 +++-
 2 files changed, 43 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 2c20d23d62d1..0c44352ad5eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -150,60 +150,7 @@ static int amdgpu_gtt_mgr_fini(struct ttm_mem_type_manager 
*man)
  */
 bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_mem_reg *mem)
 {
-   struct amdgpu_gtt_node *node = mem->mm_node;
-
-   return (node->node.start != AMDGPU_BO_INVALID_OFFSET);
-}
-
-/**
- * amdgpu_gtt_mgr_alloc - allocate new ranges
- *
- * @man: TTM memory type manager
- * @tbo: TTM BO we need this range for
- * @place: placement flags and restrictions
- * @mem: the resulting mem object
- *
- * Allocate the address space for a node.
- */
-static int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
-   struct ttm_buffer_object *tbo,
-   const struct ttm_place *place,
-   struct ttm_mem_reg *mem)
-{
-   struct amdgpu_device *adev = amdgpu_ttm_adev(man->bdev);
-   struct amdgpu_gtt_mgr *mgr = man->priv;
-   struct amdgpu_gtt_node *node = mem->mm_node;
-   enum drm_mm_insert_mode mode;
-   unsigned long fpfn, lpfn;
-   int r;
-
-   if (amdgpu_gtt_mgr_has_gart_addr(mem))
-   return 0;
-
-   if (place)
-   fpfn = place->fpfn;
-   else
-   fpfn = 0;
-
-   if (place && place->lpfn)
-   lpfn = place->lpfn;
-   else
-   lpfn = adev->gart.num_cpu_pages;
-
-   mode = DRM_MM_INSERT_BEST;
-   if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
-   mode = DRM_MM_INSERT_HIGH;
-
-   spin_lock(&mgr->lock);
-   r = drm_mm_insert_node_in_range(&mgr->mm, &node->node, mem->num_pages,
-   mem->page_alignment, 0, fpfn, lpfn,
-   mode);
-   spin_unlock(&mgr->lock);
-
-   if (!r)
-   mem->start = node->node.start;
-
-   return r;
+   return mem->mm_node != NULL;
 }
 
 /**
@@ -214,7 +161,7 @@ static int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager 
*man,
  * @place: placement flags and restrictions
  * @mem: the resulting mem object
  *
- * Dummy, allocate the node but no space for it yet.
+ * GTT accounting and GART node allocation if necessary.
  */
 static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager *man,
  struct ttm_buffer_object *tbo,
@@ -234,29 +181,37 @@ static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager 
*man,
atomic64_sub(mem->num_pages, &mgr->available);
spin_unlock(&mgr->lock);
 
+   if (!place->lpfn) {
+   mem->mm_node = NULL;
+   mem->start = AMDGPU_BO_INVALID_OFFSET;
+   return 0;
+   }
+
node = kzalloc(sizeof(*node), GFP_KERNEL);
if (!node) {
r = -ENOMEM;
goto err_out;
}
 
-   node->node.start = AMDGPU_BO_INVALID_OFFSET;
-   node->node.size = mem->num_pages;
node->tbo = tbo;
-   mem->mm_node = node;
 
-   if (place->fpfn || place->lpfn || place->flags & TTM_PL_FLAG_TOPDOWN) {
-   r = amdgpu_gtt_mgr_alloc(man, tbo, place, mem);
-   if (unlikely(r)) {
-   kfree(node);
-   mem->mm_node = NULL;
-   goto err_out;
-   }
-   } else {
-   mem->start = node->node.start;
-   }
+   spin_lock(&mgr->lock);
+   r = drm_mm_insert_node_in_range(&mgr->mm, &node->node, mem->num_pages,
+   mem->page_alignment, 0, place->fpfn,
+   place->lpfn, DRM_MM_INSERT_BEST);
+   spin_unlock(&mgr->lock);
+
+   if (unlikely(r))
+   goto err_free;
+
+   mem->mm_node = node;
+   mem->start = node->node.start;
 
return 0;
+
+err_free:
+   kfree(node);
+
 err_out:
atomic64_add(mem->num_pages, &mgr->available);
 
@@ -279,17 +234,14 @@ static void amdgpu_gtt_mgr_del(struct 
ttm_mem_type_manager *man,
struct amdgpu_gtt_mgr *mgr = man->priv;
struct amdgpu_gtt_node *node = mem->mm_node;
 
-   if (!node)
-   return;
-
-   spin_lock(&mgr->lock);
-   if (node->node.start != AMDGPU_BO_INVALID_OFFSET)
+   if (node) {
+   spin_lock(&mgr->lock);
drm_mm_remove_node(&node->node);
-   spin_unlock(&mgr->lock);
-   atomic64_add(mem->num_pages, &mgr->available);
+   spin_unlock(&mgr->lock);
+

Re: [PATCH v4 00/15] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

[Hans de Goede]

Hi,

On 7/9/20 4:14 PM, Sam Ravnborg wrote:

Hi Hans.

On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:

Hi All,

Here is v4 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below for the changelog.


Why is it that i915 cannot use the pwm_bl driver for backlight?
I have not studied the code - just wondering.


The intel_panel.c code deals with 7 different types of PWM controllers
which are built into the GPU + support for external PWM controllers
through the kernel's PWM subsystem.

pwm_bl will work for the external PWM controller case, but not for
the others. On top of that the intel_panel code integrates which
the video BIOS, getting things like frequency, minimum value
and if the range is inverted (0% duty == backlight brightness max).
I'm not even sure if pwm_bl supports all of this, but even if it
does the intel_panel code handles this in a unified manner for
all supported PWM controllers, including the ones which are
an integral part of the GPU.

Regards,

Hans




Initially the plan was for this series to consist of 2 parts:
1. convert the pwm-crc driver to support the atomic PWM API and
2. convert the i915 driver's PWM code to use the atomic PWM API.

But during testing I've found a number of bugs in the pwm-lpss and I
found that the acpi_lpss code needs some special handling because of
some ugliness found in most Cherry Trail DSDTs.

So now this series has grown somewhat large and consists of 4 parts:

1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness
2. various fixes to the pwm-lpss driver
3. convert the pwm-crc driver to support the atomic PWM API and
4. convert the i915 driver's PWM code to use the atomic PWM API

The involved acpi_lpss and pwm drivers do not see a whole lot of churn,
so the plan is to merge this all through drm-intel-next-queued (dinq)
once all the patches are reviewed / have acks.

In v4 the ACPI patches have been Acked by Rafael and the i915 patches
have been acked by Jani. So that just leaves the PWM patches.

Uwe can I get your ok / ack for merging this through the dinq branch
once you have acked al the PWM patches ?

This series has been tested (and re-tested after adding various bug-fixes)
extensively. It has been tested on the following devices:

-Asus T100TA  BYT + CRC-PMIC PWM
-Toshiba WT8-A  BYT + CRC-PMIC PWM
-Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM
-Asus T100HA  CHT + CRC-PMIC PWM
-Terra Pad 1061  BYT + LPSS PWM
-Trekstor Twin 10.1 BYT + LPSS PWM
-Asus T101HA  CHT + CRC-PMIC PWM
-GPD Pocket  CHT + CRC-PMIC PWM

Changelog:

Changes in v2:
- Fix coverletter subject
- Drop accidentally included debugging patch
- "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (
   - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX

Changes in v3:
- "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register 
value"
   - Use base_unit_range - 1 as maximum value for the clamp()
- "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on 
resume"
   - This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM"
 patch from previous versions of this patch-set, which really was a hack
 working around the resume issue which this patch fixes properly.
- PATCH v3 6 - 11 pwm-crc changes:
   - Various small changes resulting from the reviews by Andy and Uwe,
 including some refactoring of the patches to reduce the amount of churn
 in the patch-set

Changes in v4:
- "[PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0"
   - This is a new patch in v4 of this patchset
- "[PATCH v4 12/16] pwm: crc: Implement get_state() method"
   - Use DIV_ROUND_UP when calculating the period and duty_cycle values
- "[PATCH v4 16/16] drm/i915: panel: Use atomic PWM API for devs with an external 
PWM controller"
   - Add a note to the commit message about the changes in 
pwm_disable_backlight()
   - Use the pwm_set/get_relative_duty_cycle() helpers

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 04/16] pwm: lpss: Add range limit check for the base_unit register value

[Hans de Goede]

Hi,

On 7/9/20 4:21 PM, Andy Shevchenko wrote:

On Thu, Jul 09, 2020 at 03:23:13PM +0200, Hans de Goede wrote:

On 7/9/20 2:53 PM, Andy Shevchenko wrote:

On Wed, Jul 08, 2020 at 11:14:20PM +0200, Hans de Goede wrote:

When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.

But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.


And I don't see how you can get duty 100% / 0% (I don't remember which one is
equivalent to 0 in base unit) after this change. IIRC the problem here that
base unit when non-zero is always being added to the counter and it will
trigger the change of output at some point which is not what we want for 100% /
0% cases.


The base_unit controls the output frequency, not the duty-cycle. So clamping
the base_unit, as calculated from the period here, which also only configures
output-frequency does not impact the duty-cycle at all.

note that AFAICT currently no (in kernel) users actually try to set a period 
value
which would hit the clamp, so for existing users the clamp is a no-op. I just
added it to this patch-set for correctness sake and because userspace
(sysfs interface) users could in theory set out of range values.

As for the duty-cycle thing, first of all let me say that that is a
question / issue which is completely orthogonal to this patch, this
patch only impacts the period/output frequency NOT the duty-cycle,


Unfortunately the base unit settings affects duty cycle.

Documentation says about integer part and fractional, where integer is
8 bit and this what's being compared to on time divisor. Thus, if on time
divisor is 255 and base unit is 1 (in integer part) or 0.25, we can't get 0%.
(It looks like if 'on time divisor MOD base unit == 0' we won't get 0%)


With that said, the documentation is not really helpful here,
we need to set the on_time_div to 255 to get a duty-cycle close to 0
(and to 0 to get a duty cycle of 100%) but if setting this to 255 gives
us a duty-cycle of really really 0%, or just close to 0% is uncleaer.


It depends on base unit value.


We could do a separate patch add ing a hack where if the user asks for
0% duty-cycle we program the base_unit to 0, but that seems like a bad
idea for 2 reasons:



1. If the user really wants the output to be constantly 0 the user should
just disable the pwm


I can't take this as an argument. Disabling PWM is orthogonal to what duty 
cycle is.


2. New base_unit values are latched and not applied until the counter
overflows, with a base_unit of 0 the counter never overflows. I have
not tested this but I would not be surprised if after programming a
base_unit value of 0, we are unable to ever change the value again
through any other means then power-cycling the PWM controller.
Even if I could test this on some revisions, we already know that
not all revisions work the same wrt the latching. So it is best to
just never set base_unit to 0, that is just a recipe asking for trouble.


This what doc says about zeros:
• Programming either the PWM_base_unit value or the PWM_on_time_divisor to ‘0’
will generate an always zero output.

So, what I'm talking seems about correlation between base unit and on time
divisor rather than zeros.

I agree with this patch.
Reviewed-by: Andy Shevchenko 


Thank you.


When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:

base_unit &= (base_unit_range - 1);

But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.


It would be nice to have an example of calculus here.


This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).


Eventually I sat and wrote all this on paper. I see now that the problem
is in out of range of the period. And strongly we should clamp rather period
to the supported range, but your solution is an equivalent.


Right, the advantage of doing the clamping on the register value is that we
avoid some tricky math with possible rounding errors and which is different
per controller revision because the number of bits in the base unit being
different per controller revision.


...


+   base_unit = clamp_t(unsigned long long, base_unit, 1,
+   base_unit_range - 1);


A nit: one line.

Re: [Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea

[Christian König]

Am 09.07.20 um 14:31 schrieb Daniel Vetter:

On Thu, Jul 9, 2020 at 2:11 PM Daniel Stone  wrote:

On Thu, 9 Jul 2020 at 09:05, Daniel Vetter  wrote:

On Thu, Jul 09, 2020 at 08:36:43AM +0100, Daniel Stone wrote:

On Tue, 7 Jul 2020 at 21:13, Daniel Vetter  wrote:

Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.

Thanks for writing this up! I wonder if any of the notes from my reply
to the previous-version thread would be helpful to more explicitly
encode the carrot of dma-fence's positive guarantees, rather than just
the stick of 'don't do this'. ;) Either way, this is:

I think the carrot should go into the intro section for dma-fence, this
section here is very much just the "don't do this" part. The previous
patches have an attempt at encoding this a bit, maybe see whether there's
a place for your reply (or parts of it) to fit?

Sounds good to me.


Acked-by: Daniel Stone 


What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads or workloads where userspace fencing is allowed.

... or whether we just say that you can never use dma-fence in
conjunction with userptr.

Uh userptr is entirely different thing. That one is ok. It's userpsace
fences or gpu futexes or future fences or whatever we want to call them.
Or is there some other confusion here?.

I mean generating a dma_fence from a batch which will try to page in
userptr. Given that userptr could be backed by absolutely anything at
all, it doesn't seem smart to allow fences to rely on a pointer to an
mmap'ed NFS file. So it seems like batches should be mutually
exclusive between arbitrary SVM userptr and generating a dma-fence?

Locking is Tricky (tm) but essentially what at least amdgpu does is
pull in the backing storage before we publish any dma-fence. And then
some serious locking magic to make sure that doesn't race with a core
mm invalidation event. So for your case here the cs ioctl just blocks
until the nfs pages are pulled in.


Yeah, we had some iterations until all was settled.

Basic idea is the following:
1. Have a sequence counter increased whenever a change to the page 
tables happens.

2. During CS grab the current value of this counter.
3. Get all the pages you need in an array.
4. Prepare CS, grab the low level lock the MM notifier waits for and 
double check the counter.
5. If the counter is still the same all is well and the DMA-fence pushed 
to the hardware.

6. If the counter has changed repeat.

Can result in a nice live lock when you constantly page things in/out, 
but that is expected behavior.


Christian.



Once we've committed for the dma-fence it's only the other way round,
i.e. core mm will stall on the dma-fence if it wants to throw out
these pages again. More or less at least. That way we never have a
dma-fence depending upon any core mm operations. The only pain here is
that this severely limits what you can do in the critical path towards
signalling a dma-fence, because the tldr is "no interacting with core
mm at all allowed".


Speaking of entirely different things ... the virtio-gpu bit really
doesn't belong in this patch.

Oops, dunno where I lost that as a sparate patch. Will split out again :-(
-Daniel


Cheers,
Daniel





___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object

[Christian König]

Am 09.07.20 um 15:54 schrieb Steven Price:

On 09/07/2020 09:48, Christian König wrote:

Am 08.07.20 um 18:19 schrieb Daniel Vetter:

On Wed, Jul 8, 2020 at 6:11 PM Daniel Vetter  wrote:
On Wed, Jul 8, 2020 at 5:05 PM Christian König 
 wrote:

Am 08.07.20 um 17:01 schrieb Daniel Vetter:
On Wed, Jul 8, 2020 at 4:37 PM Christian König 
 wrote:

Am 08.07.20 um 11:54 schrieb Daniel Vetter:

On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote:

Am 07.07.20 um 20:35 schrieb Chris Wilson:

Quoting lepton (2020-07-07 19:17:51)
On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson 
 wrote:

Quoting lepton (2020-07-07 18:05:21)
On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson 
 wrote:
If we assign obj->filp, we believe that the create vgem 
bo is native and
allow direct operations like mmap() assuming it behaves 
as backed by a
shmemfs inode. When imported from a dmabuf, the 
obj->pages are
not always meaningful and the shmemfs backing store 
misleading.


Note, that regular mmap access to a vgem bo is via the 
dumb buffer API,

and that rejects attempts to mmap an imported dmabuf,
What do you mean by "regular mmap access" here?  It looks 
like vgem is
using vgem_gem_dumb_map as .dumb_map_offset callback then 
it doesn't call

drm_gem_dumb_map_offset

As I too found out, and so had to correct my story telling.

By regular mmap() access I mean mmap on the vgem bo [via 
the dumb buffer
API] as opposed to mmap() via an exported dma-buf fd. I had 
to look at

igt to see how it was being used.
Now it seems your fix is to disable "regular mmap" on 
imported dma buf
for vgem. I am not really a graphic guy, but then the api 
looks like:
for a gem handle, user space has to guess to find out the 
way to mmap
it. If user space guess wrong, then it will fail to mmap. Is 
this the

expected way
for people to handle gpu buffer?
You either have a dumb buffer handle, or a dma-buf fd. If you 
have the
handle, you have to use the dumb buffer API, there's no other 
way to
mmap it. If you have the dma-buf fd, you should mmap it 
directly. Those

two are clear.

It's when you import the dma-buf into vgem and create a 
handle out of
it, that's when the handle is no longer first class and 
certain uAPI

[the dumb buffer API in particular] fail.

It's not brilliant, as you say, it requires the user to 
remember the
difference between the handles, but at the same time it does 
prevent
them falling into coherency traps by forcing them to use the 
right
driver to handle the object, and have to consider the 
additional ioctls

that go along with that access.
Yes, Chris is right. Mapping DMA-buf through the mmap() APIs 
of an importer

is illegal.

What we could maybe try to do is to redirect this mmap() API 
call on the
importer to the exporter, but I'm pretty sure that the fs 
layer wouldn't

like that without changes.
We already do that, there's a full helper-ified path from I 
think shmem
helpers through prime helpers to forward this all. Including 
handling

buffer offsets and all the other lolz back&forth.
Oh, that most likely won't work correctly with unpinned DMA-bufs 
and

needs to be avoided.

Each file descriptor is associated with an struct address_space. 
And
when you mmap() through the importer by redirecting the system 
call to
the exporter you end up with the wrong struct address_space in 
your VMA.


That in turn can go up easily in flames when the exporter tries to
invalidate the CPU mappings for its DMA-buf while moving it.

Where are we doing this? My last status was that this is forbidden.

Hm I thought we're doing all that already, but looking at the code
again we're only doing this when opening a new drm fd or dma-buf fd.
So the right file->f_mapping is always set at file creation time.

And we indeed don't frob this more when going another indirection 
...

Maybe we screwed up something somewhere :-/

Also I thought the mapping is only taken after the vma is 
instatiated,
otherwise the tricks we're playing with dma-buf already wouldn't 
work:
dma-buf has the buffer always at offset 0, whereas gem drm_fd 
mmap has

it somewhere else. We already adjust vma->vm_pgoff, so I'm wondering
whether we could adjust vm_file too. Or is that the thing that's
forbidden?

Yes, exactly. Modifying vm_pgoff is harmless, tons of code does that.

But changing vma->vm_file, that's something I haven't seen before and
most likely could blow up badly.

Ok, I read the shmem helpers again, I think those are the only ones
which do the importer mmap -> dma_buf_mmap() forwarding, and hence
break stuff all around here.

They also remove the vma->vm_pgoff offset, which means
unmap_mapping_range wont work anyway. I guess for drivers which use
shmem helpers the hard assumption is that a) can't use p2p dma and b)
pin everything into system memory.

So not a problem. But something to keep in mind. I'll try to do a
kerneldoc patch to note this somewhere. btw on that, did the
timeline/syncobj documentation patch land by now? Just trying to make
sure that doe

Re: [PATCH v4 00/15] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API

[Sam Ravnborg]

Hi Hans.

On Wed, Jul 08, 2020 at 11:14:16PM +0200, Hans de Goede wrote:
> Hi All,
> 
> Here is v4 of my patch series converting the i915 driver's code for
> controlling the panel's backlight with an external PWM controller to
> use the atomic PWM API. See below for the changelog.

Why is it that i915 cannot use the pwm_bl driver for backlight?
I have not studied the code - just wondering.

Sam

> 
> Initially the plan was for this series to consist of 2 parts:
> 1. convert the pwm-crc driver to support the atomic PWM API and
> 2. convert the i915 driver's PWM code to use the atomic PWM API.
> 
> But during testing I've found a number of bugs in the pwm-lpss and I
> found that the acpi_lpss code needs some special handling because of
> some ugliness found in most Cherry Trail DSDTs.
> 
> So now this series has grown somewhat large and consists of 4 parts:
> 
> 1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness
> 2. various fixes to the pwm-lpss driver
> 3. convert the pwm-crc driver to support the atomic PWM API and
> 4. convert the i915 driver's PWM code to use the atomic PWM API
> 
> The involved acpi_lpss and pwm drivers do not see a whole lot of churn,
> so the plan is to merge this all through drm-intel-next-queued (dinq)
> once all the patches are reviewed / have acks.
> 
> In v4 the ACPI patches have been Acked by Rafael and the i915 patches
> have been acked by Jani. So that just leaves the PWM patches.
> 
> Uwe can I get your ok / ack for merging this through the dinq branch
> once you have acked al the PWM patches ?
> 
> This series has been tested (and re-tested after adding various bug-fixes)
> extensively. It has been tested on the following devices:
> 
> -Asus T100TA  BYT + CRC-PMIC PWM
> -Toshiba WT8-A  BYT + CRC-PMIC PWM
> -Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM
> -Asus T100HA  CHT + CRC-PMIC PWM
> -Terra Pad 1061  BYT + LPSS PWM
> -Trekstor Twin 10.1 BYT + LPSS PWM
> -Asus T101HA  CHT + CRC-PMIC PWM
> -GPD Pocket  CHT + CRC-PMIC PWM
> 
> Changelog:
> 
> Changes in v2:
> - Fix coverletter subject
> - Drop accidentally included debugging patch
> - "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only 
> once (
>   - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX
> 
> Changes in v3:
> - "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit 
> register value"
>   - Use base_unit_range - 1 as maximum value for the clamp()
> - "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on 
> resume"
>   - This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM"
> patch from previous versions of this patch-set, which really was a hack
> working around the resume issue which this patch fixes properly.
> - PATCH v3 6 - 11 pwm-crc changes:
>   - Various small changes resulting from the reviews by Andy and Uwe,
> including some refactoring of the patches to reduce the amount of churn
> in the patch-set
> 
> Changes in v4:
> - "[PATCH v4 06/16] pwm: lpss: Correct get_state result for base_unit == 0"
>   - This is a new patch in v4 of this patchset
> - "[PATCH v4 12/16] pwm: crc: Implement get_state() method"
>   - Use DIV_ROUND_UP when calculating the period and duty_cycle values
> - "[PATCH v4 16/16] drm/i915: panel: Use atomic PWM API for devs with an 
> external PWM controller"
>   - Add a note to the commit message about the changes in 
> pwm_disable_backlight()
>   - Use the pwm_set/get_relative_duty_cycle() helpers
> 
> Regards,
> 
> Hans
> 
> ___
> 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/2] drm/virtio: Remove open-coded commit-tail function

[Sam Ravnborg]

On Thu, Jul 09, 2020 at 02:33:39PM +0200, Daniel Vetter wrote:
> Exactly matches the one in the helpers.
> 
> This avoids me having to roll out dma-fence critical section
> annotations to this copy.
> 
> Signed-off-by: Daniel Vetter 
> Cc: David Airlie 
> Cc: Gerd Hoffmann 
> Cc: virtualizat...@lists.linux-foundation.org
> ---
>  drivers/gpu/drm/virtio/virtgpu_display.c | 20 
>  1 file changed, 20 deletions(-)
Very nice catch:
Reviewed-by: Sam Ravnborg 

> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index f3ce49c5a34c..af55b334be2f 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -314,25 +314,6 @@ virtio_gpu_user_framebuffer_create(struct drm_device 
> *dev,
>   return &virtio_gpu_fb->base;
>  }
>  
> -static void vgdev_atomic_commit_tail(struct drm_atomic_state *state)
> -{
> - struct drm_device *dev = state->dev;
> -
> - drm_atomic_helper_commit_modeset_disables(dev, state);
> - drm_atomic_helper_commit_modeset_enables(dev, state);
> - drm_atomic_helper_commit_planes(dev, state, 0);
> -
> - drm_atomic_helper_fake_vblank(state);
> - drm_atomic_helper_commit_hw_done(state);
> -
> - drm_atomic_helper_wait_for_vblanks(dev, state);
> - drm_atomic_helper_cleanup_planes(dev, state);
> -}
> -
> -static const struct drm_mode_config_helper_funcs virtio_mode_config_helpers 
> = {
> - .atomic_commit_tail = vgdev_atomic_commit_tail,
> -};
> -
>  static const struct drm_mode_config_funcs virtio_gpu_mode_funcs = {
>   .fb_create = virtio_gpu_user_framebuffer_create,
>   .atomic_check = drm_atomic_helper_check,
> @@ -346,7 +327,6 @@ void virtio_gpu_modeset_init(struct virtio_gpu_device 
> *vgdev)
>   drm_mode_config_init(vgdev->ddev);
>   vgdev->ddev->mode_config.quirk_addfb_prefer_host_byte_order = true;
>   vgdev->ddev->mode_config.funcs = &virtio_gpu_mode_funcs;
> - vgdev->ddev->mode_config.helper_private = &virtio_mode_config_helpers;
>  
>   /* modes will be validated against the framebuffer size */
>   vgdev->ddev->mode_config.min_width = XRES_MIN;
> -- 
> 2.27.0
> 
> ___
> 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/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object

[Steven Price]

On 09/07/2020 09:48, Christian König wrote:

Am 08.07.20 um 18:19 schrieb Daniel Vetter:

On Wed, Jul 8, 2020 at 6:11 PM Daniel Vetter  wrote:
On Wed, Jul 8, 2020 at 5:05 PM Christian König 
 wrote:

Am 08.07.20 um 17:01 schrieb Daniel Vetter:
On Wed, Jul 8, 2020 at 4:37 PM Christian König 
 wrote:

Am 08.07.20 um 11:54 schrieb Daniel Vetter:

On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote:

Am 07.07.20 um 20:35 schrieb Chris Wilson:

Quoting lepton (2020-07-07 19:17:51)
On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson 
 wrote:

Quoting lepton (2020-07-07 18:05:21)
On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson 
 wrote:
If we assign obj->filp, we believe that the create vgem bo 
is native and
allow direct operations like mmap() assuming it behaves as 
backed by a

shmemfs inode. When imported from a dmabuf, the obj->pages are
not always meaningful and the shmemfs backing store 
misleading.


Note, that regular mmap access to a vgem bo is via the dumb 
buffer API,

and that rejects attempts to mmap an imported dmabuf,
What do you mean by "regular mmap access" here?  It looks 
like vgem is
using vgem_gem_dumb_map as .dumb_map_offset callback then it 
doesn't call

drm_gem_dumb_map_offset

As I too found out, and so had to correct my story telling.

By regular mmap() access I mean mmap on the vgem bo [via the 
dumb buffer
API] as opposed to mmap() via an exported dma-buf fd. I had 
to look at

igt to see how it was being used.
Now it seems your fix is to disable "regular mmap" on imported 
dma buf
for vgem. I am not really a graphic guy, but then the api 
looks like:
for a gem handle, user space has to guess to find out the way 
to mmap
it. If user space guess wrong, then it will fail to mmap. Is 
this the

expected way
for people to handle gpu buffer?
You either have a dumb buffer handle, or a dma-buf fd. If you 
have the
handle, you have to use the dumb buffer API, there's no other 
way to
mmap it. If you have the dma-buf fd, you should mmap it 
directly. Those

two are clear.

It's when you import the dma-buf into vgem and create a handle 
out of
it, that's when the handle is no longer first class and certain 
uAPI

[the dumb buffer API in particular] fail.

It's not brilliant, as you say, it requires the user to 
remember the
difference between the handles, but at the same time it does 
prevent

them falling into coherency traps by forcing them to use the right
driver to handle the object, and have to consider the 
additional ioctls

that go along with that access.
Yes, Chris is right. Mapping DMA-buf through the mmap() APIs of 
an importer

is illegal.

What we could maybe try to do is to redirect this mmap() API 
call on the
importer to the exporter, but I'm pretty sure that the fs layer 
wouldn't

like that without changes.
We already do that, there's a full helper-ified path from I think 
shmem
helpers through prime helpers to forward this all. Including 
handling

buffer offsets and all the other lolz back&forth.

Oh, that most likely won't work correctly with unpinned DMA-bufs and
needs to be avoided.

Each file descriptor is associated with an struct address_space. And
when you mmap() through the importer by redirecting the system 
call to
the exporter you end up with the wrong struct address_space in 
your VMA.


That in turn can go up easily in flames when the exporter tries to
invalidate the CPU mappings for its DMA-buf while moving it.

Where are we doing this? My last status was that this is forbidden.

Hm I thought we're doing all that already, but looking at the code
again we're only doing this when opening a new drm fd or dma-buf fd.
So the right file->f_mapping is always set at file creation time.

And we indeed don't frob this more when going another indirection ...
Maybe we screwed up something somewhere :-/

Also I thought the mapping is only taken after the vma is instatiated,
otherwise the tricks we're playing with dma-buf already wouldn't work:
dma-buf has the buffer always at offset 0, whereas gem drm_fd mmap has
it somewhere else. We already adjust vma->vm_pgoff, so I'm wondering
whether we could adjust vm_file too. Or is that the thing that's
forbidden?

Yes, exactly. Modifying vm_pgoff is harmless, tons of code does that.

But changing vma->vm_file, that's something I haven't seen before and
most likely could blow up badly.

Ok, I read the shmem helpers again, I think those are the only ones
which do the importer mmap -> dma_buf_mmap() forwarding, and hence
break stuff all around here.

They also remove the vma->vm_pgoff offset, which means
unmap_mapping_range wont work anyway. I guess for drivers which use
shmem helpers the hard assumption is that a) can't use p2p dma and b)
pin everything into system memory.

So not a problem. But something to keep in mind. I'll try to do a
kerneldoc patch to note this somewhere. btw on that, did the
timeline/syncobj documentation patch land by now? Just trying to make
sure that doesn't get lost for another few months or so :-/

Ok, 

Re: [PATCH v4 05/16] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume

[Hans de Goede]

Hi,

On 7/9/20 3:36 PM, Andy Shevchenko wrote:

On Wed, Jul 08, 2020 at 11:14:21PM +0200, Hans de Goede wrote:

Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.

This problem has been masked so far because the main consumer
(the i915 driver) was always making duty-cycle changes on resume.
With the conversion of the i915 driver to the atomic PWM API the
driver now only disables/enables the PWM on suspend/resume leaving
the output-freq and duty as is, triggering this problem.

The LPSS PWM controller has a mechanism where the ctrl register value
and the actual base-unit and on-time-div values used are latched. When
software sets the SW_UPDATE bit then at the end of the current PWM cycle,
the new values from the ctrl-register will be latched into the actual
registers, and the SW_UPDATE bit will be cleared.

The problem is that before this commit our suspend/resume handling
consisted of simply saving the PWM ctrl register on suspend and
restoring it on resume, without setting the PWM_SW_UPDATE bit.
When the controller has lost its state over a suspend/resume and thus
has been reset to the defaults, just restoring the register is not
enough. We must also set the SW_UPDATE bit to tell the controller to
latch the restored values into the actual registers.

Fixing this problem is not as simple as just or-ing in the value which
is being restored with SW_UPDATE. If the PWM was enabled before we must
write the new settings + PWM_SW_UPDATE before setting PWM_ENABLE.
We must also wait for PWM_SW_UPDATE to become 0 again and depending on the
model we must do this either before or after the setting of PWM_ENABLE.

All the necessary logic for doing this is already present inside
pwm_lpss_apply(), so instead of duplicating this inside the resume
handler, this commit makes the resume handler use pwm_lpss_apply() to
restore the settings when necessary. This fixes the output-freq and
duty-cycle being reset to their defaults on resume.


...


+static int __pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+   const struct pwm_state *state, bool from_resume)
  {
struct pwm_lpss_chip *lpwm = to_lpwm(chip);
int ret;
  
  	if (state->enabled) {

if (!pwm_is_enabled(pwm)) {
-   pm_runtime_get_sync(chip->dev);
+   if (!from_resume)
+   pm_runtime_get_sync(chip->dev);
+
ret = pwm_lpss_is_updating(pwm);
if (ret) {
-   pm_runtime_put(chip->dev);
+   if (!from_resume)
+   pm_runtime_put(chip->dev);
+
return ret;
}
pwm_lpss_prepare(lpwm, pwm, state->duty_cycle, 
state->period);
pwm_lpss_cond_enable(pwm, lpwm->info->bypass == false);
ret = pwm_lpss_wait_for_update(pwm);
if (ret) {
-   pm_runtime_put(chip->dev);
+   if (!from_resume)
+   pm_runtime_put(chip->dev);
+
return ret;
}
pwm_lpss_cond_enable(pwm, lpwm->info->bypass == true);



}
} else if (pwm_is_enabled(pwm)) {
pwm_lpss_write(pwm, pwm_lpss_read(pwm) & ~PWM_ENABLE);
-   pm_runtime_put(chip->dev);
+
+   if (!from_resume)
+   pm_runtime_put(chip->dev);
}


I'm wondering if splitting more will make this look better, like:

...
if (from_resume) {
ret = pwm_lpss_prepare_enable(...); // whatever name you think 
suits better
} else {
pm_runtime_get_sync(...);
ret = pwm_lpss_prepare_enable(...);
if (ret)
pm_runtime_put(...);
}
...



That is a good idea, I like it. We already had multiple pm_runtime_put() calls
before for the error handlig and this patch did not make it any better.

So adding a pwm_lpss_prepare_enable() helper (the name works for)
will also cleanup the original code. I will add this helper as
a separate preparation patch for this one in v5 of the patch-set.

Regards,

Hans

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 04/16] pwm: lpss: Add range limit check for the base_unit register value

[Hans de Goede]

Hi,

On 7/9/20 2:53 PM, Andy Shevchenko wrote:

On Wed, Jul 08, 2020 at 11:14:20PM +0200, Hans de Goede wrote:

When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.

But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.


And I don't see how you can get duty 100% / 0% (I don't remember which one is
equivalent to 0 in base unit) after this change. IIRC the problem here that
base unit when non-zero is always being added to the counter and it will
trigger the change of output at some point which is not what we want for 100% /
0% cases.


The base_unit controls the output frequency, not the duty-cycle. So clamping
the base_unit, as calculated from the period here, which also only configures
output-frequency does not impact the duty-cycle at all.

note that AFAICT currently no (in kernel) users actually try to set a period 
value
which would hit the clamp, so for existing users the clamp is a no-op. I just
added it to this patch-set for correctness sake and because userspace
(sysfs interface) users could in theory set out of range values.

As for the duty-cycle thing, first of all let me say that that is a
question / issue which is completely orthogonal to this patch, this
patch only impacts the period/output frequency NOT the duty-cycle,

With that said, the documentation is not really helpful here,
we need to set the on_time_div to 255 to get a duty-cycle close to 0
(and to 0 to get a duty cycle of 100%) but if setting this to 255 gives
us a duty-cycle of really really 0%, or just close to 0% is uncleaer.

We could do a separate patch add ing a hack where if the user asks for
0% duty-cycle we program the base_unit to 0, but that seems like a bad
idea for 2 reasons:

1. If the user really wants the output to be constantly 0 the user should
just disable the pwm

2. New base_unit values are latched and not applied until the counter
overflows, with a base_unit of 0 the counter never overflows. I have
not tested this but I would not be surprised if after programming a
base_unit value of 0, we are unable to ever change the value again
through any other means then power-cycling the PWM controller.
Even if I could test this on some revisions, we already know that
not all revisions work the same wrt the latching. So it is best to
just never set base_unit to 0, that is just a recipe asking for trouble.


When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:

base_unit &= (base_unit_range - 1);

But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.


It would be nice to have an example of calculus here.


This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).


Eventually I sat and wrote all this on paper. I see now that the problem
is in out of range of the period. And strongly we should clamp rather period
to the supported range, but your solution is an equivalent.


Right, the advantage of doing the clamping on the register value is that we
avoid some tricky math with possible rounding errors and which is different
per controller revision because the number of bits in the base unit being
different per controller revision.


Only question is about the 100% / 0% duty cycle.


See my answer to that above.


Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Signed-off-by: Hans de Goede 
---
Changes in v3:
- Change upper limit of clamp to (base_unit_range - 1)
- Add Fixes tag
---
  drivers/pwm/pwm-lpss.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 43b1fc634af1..80d0f9c64f9d 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -97,6 +97,9 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
struct pwm_device *pwm,
freq *= base_unit_range;
  
  	base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);

+   /* base_unit must not be 0 and we also want to avoid overflowing it */



+   base_unit = clamp_t(unsigned long long, base_unit, 1,
+   base_unit_range - 1);


A nit: one line.


Doesn't fit in 80 chars, I guess we could make this one line now with the new 
100 chars
limit, but that does make it harder t

Re: [PATCH] fbtft-bus.c: Removing that prohibited space before ')'

[kernel test robot]

Hi K,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v5.8-rc4 next-20200709]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/B-K-Karthik/fbtft-bus-c-Removing-that-prohibited-space-before/20200627-125315
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
92cd1b5d65f5c67147c7da39a3c2ad7e6ff81027
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-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
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=sparc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> drivers/staging/fbtft/fbtft-bus.c:65:53: error: macro 
>> "define_fbtft_write_reg" requires 4 arguments, but only 3 given
  65 | define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
 | ^
   drivers/staging/fbtft/fbtft-bus.c:14: note: macro "define_fbtft_write_reg" 
defined here
  14 | #define define_fbtft_write_reg(func, buffer_type, data_type, 
modifier)\
 | 
>> drivers/staging/fbtft/fbtft-bus.c:65:23: error: expected ';' before 'void'
  65 | define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
 |   ^
 |   ;
   drivers/staging/fbtft/fbtft-bus.c:67:57: error: macro 
"define_fbtft_write_reg" requires 4 arguments, but only 3 given
  67 | define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
 | ^
   drivers/staging/fbtft/fbtft-bus.c:14: note: macro "define_fbtft_write_reg" 
defined here
  14 | #define define_fbtft_write_reg(func, buffer_type, data_type, 
modifier)\
 | 
   drivers/staging/fbtft/fbtft-bus.c:67:23: error: expected ';' before 'void'
  67 | define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
 |   ^
 |   ;
  68 | 
  69 | void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
 |    

vim +/define_fbtft_write_reg +65 drivers/staging/fbtft/fbtft-bus.c

64  
  > 65  define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
66  define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
67  define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
68  

---
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 v7 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message

[Anshuman Gupta]

On 2020-07-02 at 20:07:36 +0530, Anshuman Gupta wrote:
> On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote:
> > On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta
> >  wrote:
> > >
> > > On 2020-06-23 at 21:29:05 +0530, Sean Paul wrote:
> > > Hi Sean,
> > > I am new to DP MST stuff, I am looking to DP MST spec DP v1.2a.
> > > I have looked the entire series, i will take up this opportunity to review
> > > the series from HDCP over DP MST POV.
> > > I think theoretically this series should work or Gen12 as well, as DP MST 
> > > streams
> > > are getting encrypted by QUERY_STREAM_ENCRYPTION_STATUS reply tranaction 
> > > msg
> > > (generating Stream State Signature L’).
> > > I will test this on Gen12 H/W with DP MST support and will provide my 
> > > inputs.
> > >
> > > Meanwhile while going through DP MST v1.2a specs(Page 262) came to know 
> > > about
> > > a DP irq vector LINK_SERVICE_IRQ_VECTOR_ESI0 (02005h),
> > > Bit 2 : STREAM_STATUS_CHANGED.
> > > When this bit set to ‘1’ indicates the source must re-check the Stream 
> > > Status
> > > with the QUERY_STREAM_ENCRYPTION_STATUS message.
> > > Currently i feel this irq support is missing, do we require to support
> > > above IRQ vector for DP MST stream encryption.
> > >
> > 
> > Hi Anshuman,
> > Thank you for your comments.
> > 
> > QUERY_STREAM_ENCRYPTION_STATUS is not necessary for HDCP 1.x, I added
> > this as a safety check to ensure that the streams were being
> > encrypted. As such, the existing integrity checks in place for DP are
> > sufficient to satisfy spec. When HDCP 2.2 support is added for MST,
> > handling QSES will need to be addressed to meet spec. Note also that
> > we're not validating the QSES signature for the same reason.
> Thanks sean for the explanation,
> overall patch looks good to me but i have couple of doubt see below.
> > 
> > Sean
> > 
> > 
> > > Thanks,
> > > Anshuman Gupta.
> > >
> > > > From: Sean Paul 
> > > >
> > > > Used to query whether an MST stream is encrypted or not.
> > > >
> > > > Signed-off-by: Sean Paul 
> > > >
> > > > Link: 
> > > > https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
> > > >  #v4
> > > > Link: 
> > > > https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
> > > >  #v5
> > > > Link: 
> > > > https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-s...@poorly.run
> > > >  #v6
> > > >
> > > > Changes in v4:
> > > > -Added to the set
> > > > Changes in v5:
> > > > -None
> > > > Changes in v6:
> > > > -Use FIELD_PREP to generate request buffer bitfields (Lyude)
> > > > -Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
> > > > Changes in v7:
> > > > -None
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_mst_topology.c | 142 ++
> > > >  .../drm/selftests/test-drm_dp_mst_helper.c|  17 +++
> > > >  include/drm/drm_dp_helper.h   |   3 +
> > > >  include/drm/drm_dp_mst_helper.h   |  44 ++
> > > >  4 files changed, 206 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index b2f5a84b4cfb..fc68478eaeb4 100644
> > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > @@ -20,11 +20,13 @@
> > > >   * OF THIS SOFTWARE.
> > > >   */
> > > >
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -419,6 +421,22 @@ drm_dp_encode_sideband_req(const struct 
> > > > drm_dp_sideband_msg_req_body *req,
> > > >   memcpy(&buf[idx], req->u.i2c_write.bytes, 
> > > > req->u.i2c_write.num_bytes);
> > > >   idx += req->u.i2c_write.num_bytes;
> > > >   break;
> > > > + case DP_QUERY_STREAM_ENC_STATUS: {
> > > > + const struct drm_dp_query_stream_enc_status *msg;
> > > > +
> > > > + msg = &req->u.enc_status;
> > > > + buf[idx] = msg->stream_id;
> > > > + idx++;
> > > > + memcpy(&buf[idx], msg->client_id, sizeof(msg->client_id));
> > > > + idx += sizeof(msg->client_id);
> > > > + buf[idx] = 0;
> > > > + buf[idx] |= FIELD_PREP(GENMASK(1, 0), msg->stream_event);
> > > > + buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
> > > > + buf[idx] |= FIELD_PREP(GENMASK(4, 3), 
> > > > msg->stream_behavior);
> > > > + buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
> > > > + idx++;
> > > > + }
> > > > + break;
> > > >   }
> > > >   raw->cur_len = idx;
> > > >  }
> > > > @@ -547,6 +565,20 @@ drm_dp_decode_sideband_req(const struct 
> > > > drm_dp_sideband_msg_tx *raw,
> > > >   return -ENOMEM;
> > > >   }
> > > >   break;
> > > > + case

Re: [PATCH 2/2] drm/virtio: Remove open-coded commit-tail function

[Gerd Hoffmann]

On Thu, Jul 09, 2020 at 02:33:39PM +0200, Daniel Vetter wrote:
> Exactly matches the one in the helpers.
> 
> This avoids me having to roll out dma-fence critical section
> annotations to this copy.
> 
> Signed-off-by: Daniel Vetter 
> Cc: David Airlie 
> Cc: Gerd Hoffmann 
> Cc: virtualizat...@lists.linux-foundation.org

Acked-by: Gerd Hoffmann 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/9] drm: Add privacy-screen class and connector properties

[Hans de Goede]

Hi,

On 7/8/20 11:25 PM, Alex Deucher wrote:

On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede  wrote:


Hi All,

Here is the privacy-screen related code which we discussed a while ago.
This series consists of a number of different parts:

1. A new version of Rajat's privacy-screen connector properties patch,
this adds new userspace API in the form of new properties

2. Since on most devices the privacy screen is actually controlled by
some vendor specific ACPI/WMI interface which has a driver under
drivers/platform/x86, we need some "glue" code to make this functionality
available to KMS drivers. Patches 3-5 add a new privacy-screen class for
this, which allows non KMS drivers (and possibly KMS drivers too) to
register a privacy-screen device and also adds an interface for KMS drivers
to get access to the privacy-screen associated with a specific connector.
This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
kernel, including separate includes for consumers and providers(drivers).

3. Some drm_connector helper functions to keep the actual changes needed
for this in individual KMS drivers as small as possible (patch 6).

4. Make the thinkpad_acpi code register a privacy-screen device on
ThinkPads with a privacy-screen (patches 7-8)

5. Make the i915 driver export the privacy-screen functionality through
the connector properties on the eDP connector.


Care to create a patch 10 for amdgpu?  Lenovo sells AMD thinkpads with
a privacy screen as well, presumably it works
the same way.


Yes the AMD based Thinkpads should work the same way.

We will need similar changes for amdgpu and very likely also for
nouveau. The problem is I don't really have hw to test this.

Do you have access to a recent thinkpad with amdgpu ? It does not need
to have a privacy screen, as long as it is new enough that the ACPI
tables have the GSSS and  methods you can test by ignoring
the presence bit for the privacy-screen, I use this little change for
that:

From 9438bababe77dfccbade5c2377bdc7d6a777a6c6 Mon Sep 17 00:00:00 2001
From: Hans de Goede 
Date: Wed, 27 May 2020 14:38:42 +0200
Subject: [PATCH] platform/x86: thinkpad_acpi: Hack to allow testing
 on devices without a privacy-screen

Hack to allow testing on devices without a privacy-screen.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/drm_privacy_screen_x86.c | 4 
 drivers/platform/x86/thinkpad_acpi.c | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c 
b/drivers/gpu/drm/drm_privacy_screen_x86.c
index f486d9087819..87725766a90d 100644
--- a/drivers/gpu/drm/drm_privacy_screen_x86.c
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -41,7 +41,11 @@ static bool __init detect_thinkpad_privacy_screen(void)
if (ACPI_FAILURE(status))
return false;

+#if 1
+   return true;
+#else
return (output & 0x1) ? true : false;
+#endif
 }

 static const struct arch_init_data arch_init_data[] __initconst = {
diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index 1583c18f7f77..92aad746d1f8 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9747,8 +9747,8 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct 
*iibm)
if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
return -EIO;

-   if (!(output & 0x1))
-   return 0;
+// if (!(output & 0x1))
+// return 0;

lcdshadow_dev = drm_privacy_screen_register(&tpacpi_pdev->dev,
&lcdshadow_ops);
--
2.26.2


So if you have a machine with an AMDGPU and with the mentioned ACPI methods,
then you should be able to implement this yourself. You can read/write the new
props under X11 with xrandr. And you monitor if the changes make it to the
hardware by doing:

cat /proc/acpi/ibm/lcdshadow

And you can simulate external changes (like through a hotkey handled by the 
embedded-controller) by doing:

echo 0 > /proc/acpi/ibm/lcdshadow
echo 1 > /proc/acpi/ibm/lcdshadow

When you do this you should see udev change events for the properties, you
can test for those by doing:

sudo udevadm monitor -u -p

###

With all that said, I can take a shot at blindly implementing this for amdgpu
but I would greatly prefer an actually tested patch, even if it is tested in
the way described above. When the patch is ready you can just send it to me
and I'll add my s-o-b and add it as patch 10 in the patch-set for the next
version.

Regards,

Hans



I was a bit in doubt if I should calls this series a RFC, or just call
it v1, since there is no real userspace code using this yet. It was
tested using xrandr property access and udevadm event monitoring.
I do expect / hope we will have patches for a userspace consumer of the
new properties (mutter) ready soon.

But since the code is completely ready, including API documentation,
I've

Re: [Intel-gfx] [PATCH v7 17/17] drm/i915: Add HDCP 1.4 support for MST connectors

[Anshuman Gupta]

On 2020-07-09 at 16:07:12 +0530, Ramalingam C wrote:
> On 2020-06-23 at 11:59:07 -0400, Sean Paul wrote:
> > From: Sean Paul 
> > 
> > Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
> > MST. Everything except for toggling the HDCP signalling and HDCP 2.2
> > support is the same as the DP case, so we'll re-use those callbacks
> > 
> > Cc: Juston Li 
> > Signed-off-by: Sean Paul 
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
> >  #v1
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
> >  #v2
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-s...@poorly.run
> >  #v3
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-s...@poorly.run
> >  #v4
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-s...@poorly.run
> >  #v5
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-s...@poorly.run
> >  #v6
> > 
> > Changes in v2:
> > -Toggle HDCP from encoder disable/enable
> > -Don't disable HDCP on MST connector destroy, leave that for encoder
> >  disable, just ensure the check_work routine isn't running any longer
> > Changes in v3:
> > -Place the shim in the new intel_dp_hdcp.c file (Ville)
> > Changes in v4:
> > -Actually use the mst shim for mst connections (Juston)
> > -Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
> > Changes in v5:
> > -Add sleep on disable signalling to match hdmi delay
> > Changes in v6:
> > -Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
> >  don't have hardware to test it
> > Changes in v7:
> > -Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam)
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 66 +++-
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c  | 18 ++
> >  drivers/gpu/drm/i915/display/intel_hdcp.c|  2 +-
> >  3 files changed, 84 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
> > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > index 43446a6cae8d..3f67bd27fc3c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > @@ -7,10 +7,12 @@
> >   */
> >  
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> >  #include "intel_display_types.h"
> > +#include "intel_ddi.h"
> >  #include "intel_dp.h"
> >  #include "intel_hdcp.h"
> >  
> > @@ -618,6 +620,65 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim 
> > = {
> > .protocol = HDCP_PROTOCOL_DP,
> >  };
> >  
> > +static int
> > +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port 
> > *intel_dig_port,
> > +   enum transcoder cpu_transcoder,
> > +   bool enable)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> > +   int ret;
> > +
> > +   if (!enable)
> > +   usleep_range(6, 60); /* Bspec says >= 6us */
> > +
> > +   ret = intel_ddi_toggle_hdcp_signalling(&intel_dig_port->base,
> > +  cpu_transcoder, enable);
> Sean,
> 
> This function toggles the TRANS_DDI_HDCP_SIGNALLING (9th)bit of 
> TRANS_DDI_FUNC_CTL(tran)
> But in the hw specification this bit is mentioned to be ignored for non
> HDMI/DVI modes of the TRANS DDI.
> 
> Any reason why we need this? Did you try with out this function?
> 
> Apart from that Patch looks good to me.
IMHO it seems we are still missing to enable the Multistream HDCP Select
bit (5) in TRANS_DDI_FUNC_CTL register which is required to enable the
stream encryption.

Thanks,
Anshuman Gupta.
> 
> -Ram
> 
> > +   if (ret)
> > +   drm_dbg_kms(&i915->drm, "%s HDCP signalling failed (%d)\n",
> > + enable ? "Enable" : "Disable", ret);
> > +   return ret;
> > +}
> > +
> > +static
> > +bool intel_dp_mst_hdcp_check_link(struct intel_digital_port 
> > *intel_dig_port,
> > + struct intel_connector *connector)
> > +{
> > +   struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> > +   struct intel_dp *intel_dp = &intel_dig_port->dp;
> > +   struct drm_dp_query_stream_enc_status_ack_reply reply;
> > +   int ret;
> > +
> > +   if (!intel_dp_hdcp_check_link(intel_dig_port, connector))
> > +   return false;
> > +
> > +   ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
> > + connector->port, &reply);
> > +   if (ret) {
> > +   drm_dbg_kms(&i915->drm,
> > +   "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
> > +   connector->base.base.id, connector->base.name, ret);
> > +   return false;
> > +   }
> > +
> > +   return reply.auth_completed && reply.encryption_enabled;
> > +}
> > +
> > 

[PATCH 2/2] drm/virtio: Remove open-coded commit-tail function

[Daniel Vetter]

Exactly matches the one in the helpers.

This avoids me having to roll out dma-fence critical section
annotations to this copy.

Signed-off-by: Daniel Vetter 
Cc: David Airlie 
Cc: Gerd Hoffmann 
Cc: virtualizat...@lists.linux-foundation.org
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index f3ce49c5a34c..af55b334be2f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -314,25 +314,6 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
return &virtio_gpu_fb->base;
 }
 
-static void vgdev_atomic_commit_tail(struct drm_atomic_state *state)
-{
-   struct drm_device *dev = state->dev;
-
-   drm_atomic_helper_commit_modeset_disables(dev, state);
-   drm_atomic_helper_commit_modeset_enables(dev, state);
-   drm_atomic_helper_commit_planes(dev, state, 0);
-
-   drm_atomic_helper_fake_vblank(state);
-   drm_atomic_helper_commit_hw_done(state);
-
-   drm_atomic_helper_wait_for_vblanks(dev, state);
-   drm_atomic_helper_cleanup_planes(dev, state);
-}
-
-static const struct drm_mode_config_helper_funcs virtio_mode_config_helpers = {
-   .atomic_commit_tail = vgdev_atomic_commit_tail,
-};
-
 static const struct drm_mode_config_funcs virtio_gpu_mode_funcs = {
.fb_create = virtio_gpu_user_framebuffer_create,
.atomic_check = drm_atomic_helper_check,
@@ -346,7 +327,6 @@ void virtio_gpu_modeset_init(struct virtio_gpu_device 
*vgdev)
drm_mode_config_init(vgdev->ddev);
vgdev->ddev->mode_config.quirk_addfb_prefer_host_byte_order = true;
vgdev->ddev->mode_config.funcs = &virtio_gpu_mode_funcs;
-   vgdev->ddev->mode_config.helper_private = &virtio_mode_config_helpers;
 
/* modes will be validated against the framebuffer size */
vgdev->ddev->mode_config.min_width = XRES_MIN;
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

[Daniel Vetter]

Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.

What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads or workloads where userspace fencing is allowed.

v2: Now with dot graph!

v3: Typo (Dave Airlie)

Acked-by: Christian König 
Acked-by: Daniel Stone 
Cc: Jesse Natalie 
Cc: Steve Pronovost 
Cc: Jason Ekstrand 
Cc: Felix Kuehling 
Cc: Mika Kuoppala 
Cc: Thomas Hellstrom 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 Documentation/driver-api/dma-buf.rst | 70 
 1 file changed, 70 insertions(+)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index f8f6decde359..100bfd227265 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -178,3 +178,73 @@ DMA Fence uABI/Sync File
 .. kernel-doc:: include/linux/sync_file.h
:internal:
 
+Indefinite DMA Fences
+
+
+At various times &dma_fence with an indefinite time until dma_fence_wait()
+finishes have been proposed. Examples include:
+
+* Future fences, used in HWC1 to signal when a buffer isn't used by the display
+  any longer, and created with the screen update that makes the buffer visible.
+  The time this fence completes is entirely under userspace's control.
+
+* Proxy fences, proposed to handle &drm_syncobj for which the fence has not yet
+  been set. Used to asynchronously delay command submission.
+
+* Userspace fences or gpu futexes, fine-grained locking within a command buffer
+  that userspace uses for synchronization across engines or with the CPU, which
+  are then imported as a DMA fence for integration into existing winsys
+  protocols.
+
+* Long-running compute command buffers, while still using traditional end of
+  batch DMA fences for memory management instead of context preemption DMA
+  fences which get reattached when the compute job is rescheduled.
+
+Common to all these schemes is that userspace controls the dependencies of 
these
+fences and controls when they fire. Mixing indefinite fences with normal
+in-kernel DMA fences does not work, even when a fallback timeout is included to
+protect against malicious userspace:
+
+* Only the kernel knows about all DMA fence dependencies, userspace is not 
aware
+  of dependencies injected due to memory management or scheduler decisions.
+
+* Only userspace knows about all dependencies in indefinite fences and when
+  exactly they will complete, the kernel has no visibility.
+
+Furthermore the kernel has to be able to hold up userspace command submission
+for memory management needs, which means we must support indefinite fences 
being
+dependent upon DMA fences. If the kernel also support indefinite fences in the
+kernel like a DMA fence, like any of the above proposal would, there is the
+potential for deadlocks.
+
+.. kernel-render:: DOT
+   :alt: Indefinite Fencing Dependency Cycle
+   :caption: Indefinite Fencing Dependency Cycle
+
+   digraph "Fencing Cycle" {
+  node [shape=box bgcolor=grey style=filled]
+  kernel [label="Kernel DMA Fences"]
+  userspace [label="userspace controlled fences"]
+  kernel -> userspace [label="memory management"]
+  userspace -> kernel [label="Future fence, fence proxy, ..."]
+
+  { rank=same; kernel userspace }
+   }
+
+This means that the kernel might accidentally create deadlocks
+through memory management dependencies which userspace is unaware of, which
+randomly hangs workloads until the timeout kicks in. Workloads, which from
+userspace's perspective, do not contain a deadlock.  In such a mixed fencing
+architecture there is no single entity with knowledge of all dependencies.
+Thefore preventing such deadlocks from within the kernel is not possible.
+
+The only solution to avoid dependencies loops is by not allowing indefinite
+fences in the kernel. This means:
+
+* No future fences, proxy fences or userspace fences imported as DMA fences,
+  with or without a timeout.
+
+* No DMA fences that signal end of batchbuffer for command submission where
+  userspace is allowed to use userspace fencing or long running compute
+  workloads. This also means no implicit fencing for shared buffers in these
+  cases.
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea

[Daniel Vetter]

On Thu, Jul 9, 2020 at 2:11 PM Daniel Stone  wrote:
>
> On Thu, 9 Jul 2020 at 09:05, Daniel Vetter  wrote:
> > On Thu, Jul 09, 2020 at 08:36:43AM +0100, Daniel Stone wrote:
> > > On Tue, 7 Jul 2020 at 21:13, Daniel Vetter  wrote:
> > > > Comes up every few years, gets somewhat tedious to discuss, let's
> > > > write this down once and for all.
> > >
> > > Thanks for writing this up! I wonder if any of the notes from my reply
> > > to the previous-version thread would be helpful to more explicitly
> > > encode the carrot of dma-fence's positive guarantees, rather than just
> > > the stick of 'don't do this'. ;) Either way, this is:
> >
> > I think the carrot should go into the intro section for dma-fence, this
> > section here is very much just the "don't do this" part. The previous
> > patches have an attempt at encoding this a bit, maybe see whether there's
> > a place for your reply (or parts of it) to fit?
>
> Sounds good to me.
>
> > > Acked-by: Daniel Stone 
> > >
> > > > What I'm not sure about is whether the text should be more explicit in
> > > > flat out mandating the amdkfd eviction fences for long running compute
> > > > workloads or workloads where userspace fencing is allowed.
> > >
> > > ... or whether we just say that you can never use dma-fence in
> > > conjunction with userptr.
> >
> > Uh userptr is entirely different thing. That one is ok. It's userpsace
> > fences or gpu futexes or future fences or whatever we want to call them.
> > Or is there some other confusion here?.
>
> I mean generating a dma_fence from a batch which will try to page in
> userptr. Given that userptr could be backed by absolutely anything at
> all, it doesn't seem smart to allow fences to rely on a pointer to an
> mmap'ed NFS file. So it seems like batches should be mutually
> exclusive between arbitrary SVM userptr and generating a dma-fence?

Locking is Tricky (tm) but essentially what at least amdgpu does is
pull in the backing storage before we publish any dma-fence. And then
some serious locking magic to make sure that doesn't race with a core
mm invalidation event. So for your case here the cs ioctl just blocks
until the nfs pages are pulled in.

Once we've committed for the dma-fence it's only the other way round,
i.e. core mm will stall on the dma-fence if it wants to throw out
these pages again. More or less at least. That way we never have a
dma-fence depending upon any core mm operations. The only pain here is
that this severely limits what you can do in the critical path towards
signalling a dma-fence, because the tldr is "no interacting with core
mm at all allowed".

> Speaking of entirely different things ... the virtio-gpu bit really
> doesn't belong in this patch.

Oops, dunno where I lost that as a sparate patch. Will split out again :-(
-Daniel

>
> Cheers,
> 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: [Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea

[Daniel Stone]

On Thu, 9 Jul 2020 at 09:05, Daniel Vetter  wrote:
> On Thu, Jul 09, 2020 at 08:36:43AM +0100, Daniel Stone wrote:
> > On Tue, 7 Jul 2020 at 21:13, Daniel Vetter  wrote:
> > > Comes up every few years, gets somewhat tedious to discuss, let's
> > > write this down once and for all.
> >
> > Thanks for writing this up! I wonder if any of the notes from my reply
> > to the previous-version thread would be helpful to more explicitly
> > encode the carrot of dma-fence's positive guarantees, rather than just
> > the stick of 'don't do this'. ;) Either way, this is:
>
> I think the carrot should go into the intro section for dma-fence, this
> section here is very much just the "don't do this" part. The previous
> patches have an attempt at encoding this a bit, maybe see whether there's
> a place for your reply (or parts of it) to fit?

Sounds good to me.

> > Acked-by: Daniel Stone 
> >
> > > What I'm not sure about is whether the text should be more explicit in
> > > flat out mandating the amdkfd eviction fences for long running compute
> > > workloads or workloads where userspace fencing is allowed.
> >
> > ... or whether we just say that you can never use dma-fence in
> > conjunction with userptr.
>
> Uh userptr is entirely different thing. That one is ok. It's userpsace
> fences or gpu futexes or future fences or whatever we want to call them.
> Or is there some other confusion here?.

I mean generating a dma_fence from a batch which will try to page in
userptr. Given that userptr could be backed by absolutely anything at
all, it doesn't seem smart to allow fences to rely on a pointer to an
mmap'ed NFS file. So it seems like batches should be mutually
exclusive between arbitrary SVM userptr and generating a dma-fence?

Speaking of entirely different things ... the virtio-gpu bit really
doesn't belong in this patch.

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea

[Christian König]

Am 07.07.20 um 22:12 schrieb Daniel Vetter:

Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.

What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads or workloads where userspace fencing is allowed.

v2: Now with dot graph!

Cc: Jesse Natalie 
Cc: Steve Pronovost 
Cc: Jason Ekstrand 
Cc: Felix Kuehling 
Cc: Mika Kuoppala 
Cc: Thomas Hellstrom 
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris Wilson 
Cc: Maarten Lankhorst 
Cc: Christian König 
Signed-off-by: Daniel Vetter 


Acked-by: Christian König 


---
  Documentation/driver-api/dma-buf.rst | 70 
  drivers/gpu/drm/virtio/virtgpu_display.c | 20 ---
  2 files changed, 70 insertions(+), 20 deletions(-)

diff --git a/Documentation/driver-api/dma-buf.rst 
b/Documentation/driver-api/dma-buf.rst
index f8f6decde359..037ba0078bb4 100644
--- a/Documentation/driver-api/dma-buf.rst
+++ b/Documentation/driver-api/dma-buf.rst
@@ -178,3 +178,73 @@ DMA Fence uABI/Sync File
  .. kernel-doc:: include/linux/sync_file.h
 :internal:
  
+Idefinite DMA Fences

+
+
+At various times &dma_fence with an indefinite time until dma_fence_wait()
+finishes have been proposed. Examples include:
+
+* Future fences, used in HWC1 to signal when a buffer isn't used by the display
+  any longer, and created with the screen update that makes the buffer visible.
+  The time this fence completes is entirely under userspace's control.
+
+* Proxy fences, proposed to handle &drm_syncobj for which the fence has not yet
+  been set. Used to asynchronously delay command submission.
+
+* Userspace fences or gpu futexes, fine-grained locking within a command buffer
+  that userspace uses for synchronization across engines or with the CPU, which
+  are then imported as a DMA fence for integration into existing winsys
+  protocols.
+
+* Long-running compute command buffers, while still using traditional end of
+  batch DMA fences for memory management instead of context preemption DMA
+  fences which get reattached when the compute job is rescheduled.
+
+Common to all these schemes is that userspace controls the dependencies of 
these
+fences and controls when they fire. Mixing indefinite fences with normal
+in-kernel DMA fences does not work, even when a fallback timeout is included to
+protect against malicious userspace:
+
+* Only the kernel knows about all DMA fence dependencies, userspace is not 
aware
+  of dependencies injected due to memory management or scheduler decisions.
+
+* Only userspace knows about all dependencies in indefinite fences and when
+  exactly they will complete, the kernel has no visibility.
+
+Furthermore the kernel has to be able to hold up userspace command submission
+for memory management needs, which means we must support indefinite fences 
being
+dependent upon DMA fences. If the kernel also support indefinite fences in the
+kernel like a DMA fence, like any of the above proposal would, there is the
+potential for deadlocks.
+
+.. kernel-render:: DOT
+   :alt: Indefinite Fencing Dependency Cycle
+   :caption: Indefinite Fencing Dependency Cycle
+
+   digraph "Fencing Cycle" {
+  node [shape=box bgcolor=grey style=filled]
+  kernel [label="Kernel DMA Fences"]
+  userspace [label="userspace controlled fences"]
+  kernel -> userspace [label="memory management"]
+  userspace -> kernel [label="Future fence, fence proxy, ..."]
+
+  { rank=same; kernel userspace }
+   }
+
+This means that the kernel might accidentally create deadlocks
+through memory management dependencies which userspace is unaware of, which
+randomly hangs workloads until the timeout kicks in. Workloads, which from
+userspace's perspective, do not contain a deadlock.  In such a mixed fencing
+architecture there is no single entity with knowledge of all dependencies.
+Thefore preventing such deadlocks from within the kernel is not possible.
+
+The only solution to avoid dependencies loops is by not allowing indefinite
+fences in the kernel. This means:
+
+* No future fences, proxy fences or userspace fences imported as DMA fences,
+  with or without a timeout.
+
+* No DMA fences that signal end of batchbuffer for command submission where
+  userspace is allowed to use userspace fencing or long running compute
+  workloads. This also means no implicit fencing for shared buffers in these
+  cases.
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index f3ce49c5a34c..af55b334be2f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -314,25 +314,6 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
return &virtio_gpu_fb->base;
  }
  
-static 

[PATCH v7 00/12] PCI: brcmstb: enable PCIe for STB chips

[Jim Quinlan]

Patchset Summary:
  Enhance a PCIe host controller driver.  Because of its unusual design
  we are foced to change dev->dma_pfn_offset into a more general role
  allowing multiple offsets.  See the 'v1' notes below for more info.

v7:
  Commit: "device core: Introduce DMA range map, supplanting ..."
  -- remove second kcalloc/copy in device.c (AndyS)
  -- use PTR_ERR_OR_ZERO() and PHYS_PFN() (AndyS)
  -- indentation, sizeof(struct ...) => sizeof(*r) (AndyS)
  -- add pfn.h definitions: PFN_DMA_ADDR(), DMA_ADDR_PFN() (AndyS)
  -- Fixed compile error in "sun6i_csi.c" (kernel test robot)
  Commit "ata: ahci_brcm: Fix use of BCM7216 reset controller"
  -- correct name of function in the commit msg (SergeiS)
  
v6:
  Commit "device core: Introduce DMA range map":
  -- of_dma_get_range() now takes a single argument and returns either
 NULL, a valid map, or an ERR_PTR. (Robin)
  -- offsets are no longer a PFN value but an actual address. (Robin)
  -- the bus_dma_region struct stores the range size instead of
 the cpu_end and pci_end values. (Robin)
  -- devices that were setting a single offset with no boundaries
 have been modified to have boundaries; in a few places
 where this informatino was unavilable a /* FIXME: ... */
 comment was added. (Robin)
  -- dma_attach_offset_range() can be called when an offset
 map already exists; if it's range is already present
 nothing is done and success is returned. (Robin)
  All commits:
  -- Man name/style/corrections/etc changed (Bjorn)
  -- rebase to Torvalds master

v5:
  Commit "device core: Introduce multiple dma pfn offsets"
  -- in of/address.c: "map_size = 0" => "*map_size = 0"
  -- use kcalloc instead of kzalloc (AndyS)
  -- use PHYS_ADDR_MAX instead of "~(phys_addr_t)0"
  Commit "PCI: brcmstb: Set internal memory viewport sizes"
  -- now gives error on missing dma-ranges property.
  Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
  -- removed "Allof:" from brcm,scb-sizes definition (RobH)
  All Commits:
  -- indentation style, use max chars 100 (AndyS)
  -- rebased to torvalds master

v4:
  Commit "device core: Introduce multiple dma pfn offsets"
  -- of_dma_get_range() does not take a dev param but instead
 takes two "out" params: map and map_size.  We do this so
 that the code that parses dma-ranges is separate from
 the code that modifies 'dev'.   (Nicolas)
  -- the separate case of having a single pfn offset has
 been removed and is now processed by going through the
 map array. (Nicolas)
  -- move attach_uniform_dma_pfn_offset() from of/address.c to
 dma/mapping.c so that it does not depend on CONFIG_OF. (Nicolas)
  -- devm_kcalloc => devm_kzalloc (DanC)
  -- add/fix assignment to dev->dma_pfn_offset_map for func
 attach_uniform_dma_pfn_offset() (DanC, Nicolas)
  -- s/struct dma_pfn_offset_region/struct bus_dma_region/ (Nicolas)
  -- s/attach_uniform_dma_pfn_offset/dma_attach_uniform_pfn_offset/
  -- s/attach_dma_pfn_offset_map/dma_attach_pfn_offset_map/
  -- More use of PFN_{PHYS,DOWN,UP}. (AndyS)
  Commit "of: Include a dev param in of_dma_get_range()"
  -- this commit was sqaushed with "device core: Introduce ..."

v3:
  Commit "device core: Introduce multiple dma pfn offsets"
  Commit "arm: dma-mapping: Invoke dma offset func if needed"
  -- The above two commits have been squashed.  More importantly,
 the code has been modified so that the functionality for
 multiple pfn offsets subsumes the use of dev->dma_pfn_offset.
 In fact, dma_pfn_offset is removed and supplanted by
 dma_pfn_offset_map, which is a pointer to an array.  The
 more common case of a uniform offset is now handled as
 a map with a single entry, while cases requiring multiple
 pfn offsets use a map with multiple entries.  Code paths
 that used to do this:

 dev->dma_pfn_offset = mydrivers_pfn_offset;

 have been changed to do this:

 attach_uniform_dma_pfn_offset(dev, pfn_offset);

  Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
  -- Add if/then clause for required props: resets, reset-names (RobH)
  -- Change compatible list from const to enum (RobH)
  -- Change list of u32-tuples to u64 (RobH)

  Commit "of: Include a dev param in of_dma_get_range()"
  -- modify of/unittests.c to add NULL param in of_dma_get_range() call.

  Commit "device core: Add ability to handle multiple dma offsets"
  -- align comment in device.h (AndyS).
  -- s/cpu_beg/cpu_start/ and s/dma_beg/dma_start/ in struct
 dma_pfn_offset_region (AndyS).

v2:
Commit: "device core: Add ability to handle multiple dma offsets"
  o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
  o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
  o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
  o dev->dma_pfn_map => dev->dma_pfn_offset_map
  o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
  o In device.h: s/co

Re: drm/ast something ate high-res modes (5.3->5.6 regression)

[Ilpo Järvinen]

On Wed, 8 Jul 2020, Thomas Zimmermann wrote:

> Hi
> 
> Am 08.07.20 um 12:05 schrieb Ilpo Järvinen:
> > Hi,
> > 
> > After upgrading kernel from 5.3 series to 5.6.16 something seems to 
> > prevent me from achieving high resolutions with the ast driver.
> 
> Thanks for reporting. It's not a bug, but a side effect of atomic
> modesetting.
> 
> During pageflips, the old code used to kick out the currently displayed
> framebuffer and then load in the new one. If that failed, the display
> went garbage.
> 
> In v5.6-rc1, we merged atomic modesetting for ast. This means that
> screen updates are more reliable, but we have to over-commit resources.
> Specifically, we have to reserve space for two buffers in video memory
> while a pageflip happens. 1920x1200@32 are ~9MiB of framebuffer memory.
> If your device has 16 MiB of VRAM, there's no space left for the second
> framebuffer. Hence, the resolution is no longer supported.
> 
> On the positive side, you can now use Wayland compositors with ast.
> Atomic modesetting adds the necessary interfaces.

Ok, thanks for the info although it's quite disappointing (not the first 
time to lose features with kms, migrating to it made me to lose dpms) ;-).

As it's quite annoying to lose a high resolution mode (or be stuck in 
some old kernel), would it be technically feasible to make the framebuffer 
allocation asymmetrical? That is, the switch to high-res mode would get
rejected when it would be into the smaller of the two buffers but not when 
the arrangement is the other way around?


-- 
 i.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm/ast something ate high-res modes (5.3->5.6 regression)

[Ilpo Järvinen]

On Wed, 8 Jul 2020, Thomas Zimmermann wrote:

> Am 08.07.20 um 16:26 schrieb Daniel Vetter:
> > On Wed, Jul 8, 2020 at 4:22 PM Thomas Zimmermann  
> > wrote:
> >>
> >> Am 08.07.20 um 15:46 schrieb Ilpo Järvinen:
> >>> On Wed, 8 Jul 2020, Thomas Zimmermann wrote:
> >>>
>  Am 08.07.20 um 12:05 schrieb Ilpo Järvinen:
> >
> > After upgrading kernel from 5.3 series to 5.6.16 something seems to
> > prevent me from achieving high resolutions with the ast driver.
> 
>  Thanks for reporting. It's not a bug, but a side effect of atomic
>  modesetting.
> 
>  During pageflips, the old code used to kick out the currently displayed
>  framebuffer and then load in the new one. If that failed, the display
>  went garbage.
> 
>  In v5.6-rc1, we merged atomic modesetting for ast. This means that
>  screen updates are more reliable, but we have to over-commit resources.
>  Specifically, we have to reserve space for two buffers in video memory
>  while a pageflip happens. 1920x1200@32 are ~9MiB of framebuffer memory.
>  If your device has 16 MiB of VRAM, there's no space left for the second
>  framebuffer. Hence, the resolution is no longer supported.
> 
>  On the positive side, you can now use Wayland compositors with ast.
>  Atomic modesetting adds the necessary interfaces.
> >>>
> >>> Ok, thanks for the info although it's quite disappointing (not the first
> >>> time to lose features with kms, migrating to it made me to lose dpms) ;-).
> > 
> > kms still has dpms, not sure what you mean here? Maybe some driver
> > doesn't implement it.

Yes I know (it related only to in-kernel ast driver lacking it).

> >>> As it's quite annoying to lose a high resolution mode (or be stuck in
> >>> some old kernel), would it be technically feasible to make the framebuffer
> >>> allocation asymmetrical? That is, the switch to high-res mode would get
> >>> rejected when it would be into the smaller of the two buffers but not when
> >>> the arrangement is the other way around?
> >>
> >> I'm not sure what you mean here, but generally, there's no way of fixing
> >> this without performance penalty.
> >>
> >> The screen resolution is only programmed once. Later updates only
> >> require pageflips. For each pageflip, atomic modesetting requires the
> >> new and the old framebuffer in video memory at the same time. These two
> >> framebuffers are typically allocated once by Gnome/KDE/etc compositors,
> >> and compositors go back and forth between them. It's basically double
> >> buffering.

Ah, so there is a technical obstacle. I thought that those 2nd copies of 
buffers are only necessary during a switch from one resolution to another 
one.

> > You can do high-res mode I think, maybe needs a driver option to allow
> > it to avoid upsetting existing compositors. Roughly:
> > 1. dpms off
> > 2. allocate big buffer
> > 3. dpms on in high res mode with that single buffer
> > 
> > Pageflip will fail ofc with ENOSPC, but kms itself doesn't disallow
> > this. We could even implement this fairly generic, with a setcap flag,
> > which makes the probe helpers _not_ filter out modes which wouldn't
> > fit at least 2 framebuffers at the same time.

I cannot really understand full impact of this (what would not work).

> Technically you can hack up something, but what's the benefit for the
> overall ecosystem?
> 
> In my other reply, I was rather talking about replacing VRAM helpers
> with SHMEM helpers. That would imply a memcpy from system into video
> memory on each pageflip.
> 
> OTOH, ast currently recommends using a shadow framebuffer, so userspace
> probably already does the memcpy somewhere. And now that SHMEM helpers
> can easily do cached page mappings, the performance difference might not
> be significant. Maybe I should give it a try.

I'd highly appreciate that (but I guess I might quite small minority
when it comes to "ecosystems" :-)). And I wouldn't be too worried about 
performance penalty.


-- 
 i.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v7 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

[Jim Quinlan]

The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs.  It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.

The function of_dma_get_range() has been modified so that it takes a single
argument -- the device node -- and returns a map, NULL, or an error code.
The map is an array that holds the information regarding the DMA regions.
Each range entry contains the address offset, the cpu_start address, the
dma_start address, and the size of the region.

of_dma_configure() is the typical manner to set range offsets but there are
a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
driver code.  These cases now invoke the function
dma_attach_offset_range(dev, cpu_addr, dma_addr, size).

Signed-off-by: Jim Quinlan 
---
 arch/arm/include/asm/dma-mapping.h|  9 +-
 arch/arm/mach-keystone/keystone.c | 17 ++--
 arch/sh/drivers/pci/pcie-sh7786.c |  9 +-
 arch/sh/kernel/dma-coherent.c | 16 ++--
 arch/x86/pci/sta2x11-fixup.c  |  7 +-
 drivers/acpi/arm64/iort.c |  5 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c |  7 +-
 drivers/iommu/io-pgtable-arm.c|  2 +-
 .../platform/sunxi/sun4i-csi/sun4i_csi.c  |  6 +-
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  |  5 +-
 drivers/of/address.c  | 95 ++-
 drivers/of/device.c   | 47 +
 drivers/of/of_private.h   |  9 +-
 drivers/of/unittest.c | 35 +--
 drivers/remoteproc/remoteproc_core.c  |  2 +-
 .../staging/media/sunxi/cedrus/cedrus_hw.c|  8 +-
 drivers/usb/core/message.c|  4 +-
 drivers/usb/core/usb.c|  2 +-
 include/linux/device.h|  4 +-
 include/linux/dma-direct.h| 10 +-
 include/linux/dma-mapping.h   | 37 
 include/linux/pfn.h   |  2 +
 kernel/dma/coherent.c | 10 +-
 kernel/dma/mapping.c  | 53 +++
 24 files changed, 277 insertions(+), 124 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca34..b7cdde9fb83d 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -35,8 +35,9 @@ static inline const struct dma_map_ops 
*get_arch_dma_ops(struct bus_type *bus)
 #ifndef __arch_pfn_to_dma
 static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
 {
-   if (dev)
-   pfn -= dev->dma_pfn_offset;
+   if (dev && dev->dma_range_map)
+   pfn -= DMA_ADDR_PFN(dma_offset_from_phys_addr(dev, 
PFN_PHYS(pfn)));
+
return (dma_addr_t)__pfn_to_bus(pfn);
 }
 
@@ -44,8 +45,8 @@ static inline unsigned long dma_to_pfn(struct device *dev, 
dma_addr_t addr)
 {
unsigned long pfn = __bus_to_pfn(addr);
 
-   if (dev)
-   pfn += dev->dma_pfn_offset;
+   if (dev && dev->dma_range_map)
+   pfn += DMA_ADDR_PFN(dma_offset_from_dma_addr(dev, addr));
 
return pfn;
 }
diff --git a/arch/arm/mach-keystone/keystone.c 
b/arch/arm/mach-keystone/keystone.c
index 638808c4e122..a1a19781983b 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -8,6 +8,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,8 +25,6 @@
 
 #include "keystone.h"
 
-static unsigned long keystone_dma_pfn_offset __read_mostly;
-
 static int keystone_platform_notifier(struct notifier_block *nb,
  unsigned long event, void *data)
 {
@@ -38,9 +37,12 @@ static int keystone_platform_notifier(struct notifier_block 
*nb,
return NOTIFY_BAD;
 
if (!dev->of_node) {
-   dev->dma_pfn_offset = keystone_dma_pfn_offset;
-   dev_err(dev, "set dma_pfn_offset%08lx\n",
-   dev->dma_pfn_offset);
+   int ret = dma_attach_offset_range(dev, KEYSTONE_HIGH_PHYS_START,
+ KEYSTONE_LOW_PHYS_START,
+ KEYSTONE_HIGH_PHYS_SIZE);
+   dev_err(dev, "set dma_offset%08llx%s\n",
+   KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START,
+   ret ? " failed" : "");
}
return NOTIFY_OK;
 }
@@ -51,11 +53,8 @@ static struct notifier_block platform_nb = {
 
 static void __init keystone_init(void)
 {
-   if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
-   keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
-  KEYSTONE_LOW_PHYS_START);
+   if (PHYS_OFFSE

drm/ast something ate high-res modes (5.3->5.6 regression)

[Ilpo Järvinen]

Hi,

After upgrading kernel from 5.3 series to 5.6.16 something seems to 
prevent me from achieving high resolutions with the ast driver.

With 5.6.16:

$ xrandr
Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1920 x 2048
VGA-1 connected primary 1600x1200+0+0 (normal left inverted right x axis y 
axis) 519mm x 324mm
   1600x1200 60.00* 
   1680x1050 59.95  
   1280x1024 75.0260.02  
   1440x900  59.89  
   1280x800  59.81  
   1024x768  75.0360.00  
   800x600   75.0060.32  
   640x480   75.0059.94  
   1920x1200_60.0  59.95  

If I try to change to that manually added high-res mode, I get:
xrandr: Configure crtc 0 failed

With 5.3 series I've this:

Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 2048
VGA-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y 
axis) 519mm x 324mm
   1920x1200 59.95*+
   1600x1200 60.00  
   1680x1050 59.95  
   1280x1024 75.0260.02  
   1440x900  59.89  
   1280x800  59.81  
   1024x768  75.0360.00  
   800x600   75.0060.32  
   640x480   75.0059.94  
   1920x1200_60.0  59.95  

As I've had issues in getting EDID reliably from the monitor, I provide it 
on kernel command-line (the one dumped from the monitor I use). In 
addition, I've another workaround for past issues related to EDID which 
always adds that 1920x1200_60.0 mode but now I cannot use even it to
enter a high-res mode.

If you need some additional info or want me to test a patch, just let me 
know (but some delay is expected in testing patches). Thanks.


-- 
 i.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/4] drm/msm: dsi: Use OPP API to set clk/perf state

[Rajendra Nayak]

On SDM845 and SC7180 DSI needs to express a performance state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.

dev_pm_opp_set_rate() is designed to be equivalent to clk_set_rate()
for devices without an OPP table, hence the change works fine
on devices/platforms which only need to set a clock rate.

Signed-off-by: Rajendra Nayak 
Reviewed-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 11ae5b8..0a14c4a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -111,6 +112,9 @@ struct msm_dsi_host {
struct clk *pixel_clk_src;
struct clk *byte_intf_clk;
 
+   struct opp_table *opp_table;
+   bool has_opp_table;
+
u32 byte_clk_rate;
u32 pixel_clk_rate;
u32 esc_clk_rate;
@@ -512,9 +516,10 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host)
DBG("Set clk rates: pclk=%d, byteclk=%d",
msm_host->mode->clock, msm_host->byte_clk_rate);
 
-   ret = clk_set_rate(msm_host->byte_clk, msm_host->byte_clk_rate);
+   ret = dev_pm_opp_set_rate(&msm_host->pdev->dev,
+ msm_host->byte_clk_rate);
if (ret) {
-   pr_err("%s: Failed to set rate byte clk, %d\n", __func__, ret);
+   pr_err("%s: dev_pm_opp_set_rate failed %d\n", __func__, ret);
return ret;
}
 
@@ -658,6 +663,8 @@ int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host)
 
 void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
 {
+   /* Drop the performance state vote */
+   dev_pm_opp_set_rate(&msm_host->pdev->dev, 0);
clk_disable_unprepare(msm_host->esc_clk);
clk_disable_unprepare(msm_host->pixel_clk);
if (msm_host->byte_intf_clk)
@@ -1879,6 +1886,19 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}
 
+   msm_host->opp_table = dev_pm_opp_set_clkname(&pdev->dev, "byte");
+   if (IS_ERR(msm_host->opp_table))
+   return PTR_ERR(msm_host->opp_table);
+   /* OPP table is optional */
+   ret = dev_pm_opp_of_add_table(&pdev->dev);
+   if (!ret) {
+   msm_host->has_opp_table = true;
+   } else if (ret != -ENODEV) {
+   dev_err(&pdev->dev, "invalid OPP table in device tree\n");
+   dev_pm_opp_put_clkname(msm_host->opp_table);
+   return ret;
+   }
+
init_completion(&msm_host->dma_comp);
init_completion(&msm_host->video_comp);
mutex_init(&msm_host->dev_mutex);
@@ -1914,6 +1934,9 @@ void msm_dsi_host_destroy(struct mipi_dsi_host *host)
mutex_destroy(&msm_host->cmd_mutex);
mutex_destroy(&msm_host->dev_mutex);
 
+   if (msm_host->has_opp_table)
+   dev_pm_opp_of_remove_table(&msm_host->pdev->dev);
+   dev_pm_opp_put_clkname(msm_host->opp_table);
pm_runtime_disable(&msm_host->pdev->dev);
 }
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/4] drm/msm/dpu: Use OPP API to set clk/perf state

[Rajendra Nayak]

On some qualcomm platforms DPU needs to express a performance state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.

Signed-off-by: Rajendra Nayak 
Reviewed-by: Rob Clark 
Reviewed-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c |  3 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 27 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |  4 
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 7c230f7..b36919d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -218,7 +219,7 @@ static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms 
*kms, u64 rate)
rate = core_clk->max_rate;
 
core_clk->rate = rate;
-   return msm_dss_clk_set_rate(core_clk, 1);
+   return dev_pm_opp_set_rate(&kms->pdev->dev, core_clk->rate);
 }
 
 static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 680527e..2d5e8e8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1025,11 +1026,24 @@ static int dpu_bind(struct device *dev, struct device 
*master, void *data)
if (!dpu_kms)
return -ENOMEM;
 
+   dpu_kms->opp_table = dev_pm_opp_set_clkname(dev, "core");
+   if (IS_ERR(dpu_kms->opp_table))
+   return PTR_ERR(dpu_kms->opp_table);
+   /* OPP table is optional */
+   ret = dev_pm_opp_of_add_table(dev);
+   if (!ret) {
+   dpu_kms->has_opp_table = true;
+   } else if (ret != -ENODEV) {
+   dev_err(dev, "invalid OPP table in device tree\n");
+   dev_pm_opp_put_clkname(dpu_kms->opp_table);
+   return ret;
+   }
+
mp = &dpu_kms->mp;
ret = msm_dss_parse_clock(pdev, mp);
if (ret) {
DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
-   return ret;
+   goto err;
}
 
platform_set_drvdata(pdev, dpu_kms);
@@ -1043,6 +1057,11 @@ static int dpu_bind(struct device *dev, struct device 
*master, void *data)
 
priv->kms = &dpu_kms->base;
return ret;
+err:
+   if (dpu_kms->has_opp_table)
+   dev_pm_opp_of_remove_table(dev);
+   dev_pm_opp_put_clkname(dpu_kms->opp_table);
+   return ret;
 }
 
 static void dpu_unbind(struct device *dev, struct device *master, void *data)
@@ -1057,6 +1076,10 @@ static void dpu_unbind(struct device *dev, struct device 
*master, void *data)
 
if (dpu_kms->rpm_enabled)
pm_runtime_disable(&pdev->dev);
+
+   if (dpu_kms->has_opp_table)
+   dev_pm_opp_of_remove_table(dev);
+   dev_pm_opp_put_clkname(dpu_kms->opp_table);
 }
 
 static const struct component_ops dpu_ops = {
@@ -1082,6 +1105,8 @@ static int __maybe_unused dpu_runtime_suspend(struct 
device *dev)
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
struct dss_module_power *mp = &dpu_kms->mp;
 
+   /* Drop the performance state vote */
+   dev_pm_opp_set_rate(dev, 0);
rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (rc)
DPU_ERROR("clock disable failed rc:%d\n", rc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index a3b122b..7400cd7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -128,6 +128,10 @@ struct dpu_kms {
 
struct platform_device *pdev;
bool rpm_enabled;
+
+   struct opp_table *opp_table;
+   bool has_opp_table;
+
struct dss_module_power mp;
 
/* reference count bandwidth requests, so we know when we can
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 4/4] arm64: dts: sc7180: Add DSI and MDP OPP tables and power-domains

[Rajendra Nayak]

Add the OPP tables for DSI and MDP based on the perf state/clk
requirements, and add the power-domains property to specify the
scalable power domain.

Signed-off-by: Rajendra Nayak 
Reviewed-by: Matthias Kaehlcke 
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 49 
 1 file changed, 49 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 2be81a2..1ce895f 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2642,6 +2642,8 @@
   <1920>,
   <1920>,
   <1920>;
+   operating-points-v2 = <&mdp_opp_table>;
+   power-domains = <&rpmhpd SC7180_CX>;
 
interrupt-parent = <&mdss>;
interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
@@ -2659,6 +2661,31 @@
};
};
};
+
+   mdp_opp_table: mdp-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   required-opps = 
<&rpmhpd_opp_low_svs>;
+   };
+
+   opp-3 {
+   opp-hz = /bits/ 64 <3>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+   opp-34500 {
+   opp-hz = /bits/ 64 <34500>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-46000 {
+   opp-hz = /bits/ 64 <46000>;
+   required-opps = 
<&rpmhpd_opp_nom>;
+   };
+   };
+
};
 
dsi0: dsi@ae94000 {
@@ -2682,6 +2709,9 @@
  "iface",
  "bus";
 
+   operating-points-v2 = <&dsi_opp_table>;
+   power-domains = <&rpmhpd SC7180_CX>;
+
phys = <&dsi_phy>;
phy-names = "dsi";
 
@@ -2707,6 +2737,25 @@
};
};
};
+
+   dsi_opp_table: dsi-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-18750 {
+   opp-hz = /bits/ 64 <18750>;
+   required-opps = 
<&rpmhpd_opp_low_svs>;
+   };
+
+   opp-3 {
+   opp-hz = /bits/ 64 <3>;
+   required-opps = 
<&rpmhpd_opp_svs>;
+   };
+
+   opp-35800 {
+   opp-hz = /bits/ 64 <35800>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+   };
};
 
dsi_phy: dsi-phy@ae94400 {
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/4] arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains

[Rajendra Nayak]

Add the OPP tables for DSI and MDP based on the perf state/clk
requirements, and add the power-domains property to specify the
scalable power domain.

Signed-off-by: Rajendra Nayak 
Reviewed-by: Matthias Kaehlcke 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 59 
 1 file changed, 59 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index fee50d9..3efdd70 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -3296,6 +3296,35 @@
#power-domain-cells = <1>;
};
 
+   dsi_opp_table: dsi-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-1920 {
+   opp-hz = /bits/ 64 <1920>;
+   required-opps = <&rpmhpd_opp_min_svs>;
+   };
+
+   opp-18000 {
+   opp-hz = /bits/ 64 <18000>;
+   required-opps = <&rpmhpd_opp_low_svs>;
+   };
+
+   opp-27500 {
+   opp-hz = /bits/ 64 <27500>;
+   required-opps = <&rpmhpd_opp_svs>;
+   };
+
+   opp-32858 {
+   opp-hz = /bits/ 64 <32858>;
+   required-opps = <&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-35800 {
+   opp-hz = /bits/ 64 <35800>;
+   required-opps = <&rpmhpd_opp_nom>;
+   };
+   };
+
mdss: mdss@ae0 {
compatible = "qcom,sdm845-mdss";
reg = <0 0x0ae0 0 0x1000>;
@@ -3340,6 +3369,8 @@
  <&dispcc 
DISP_CC_MDSS_VSYNC_CLK>;
assigned-clock-rates = <3>,
   <1920>;
+   operating-points-v2 = <&mdp_opp_table>;
+   power-domains = <&rpmhpd SDM845_CX>;
 
interrupt-parent = <&mdss>;
interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
@@ -3364,6 +3395,30 @@
};
};
};
+
+   mdp_opp_table: mdp-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-1920 {
+   opp-hz = /bits/ 64 <1920>;
+   required-opps = 
<&rpmhpd_opp_min_svs>;
+   };
+
+   opp-171428571 {
+   opp-hz = /bits/ 64 <171428571>;
+   required-opps = 
<&rpmhpd_opp_low_svs>;
+   };
+
+   opp-34400 {
+   opp-hz = /bits/ 64 <34400>;
+   required-opps = 
<&rpmhpd_opp_svs_l1>;
+   };
+
+   opp-43000 {
+   opp-hz = /bits/ 64 <43000>;
+   required-opps = 
<&rpmhpd_opp_nom>;
+   };
+   };
};
 
dsi0: dsi@ae94000 {
@@ -3386,6 +3441,8 @@
  "core",
  "iface",
  "bus";
+   operating-points-v2 = <&dsi_opp_table>;
+   power-domains = <&rpmhpd SDM845_CX>;
 
phys = <&dsi0_phy>;
phy-names = "dsi";
@@ -3450,6 +3507,8 @@
  "core",
  "iface",
  "bus";
+   operating-points-v2 = <&dsi_opp_table>;
+   power-domains = <&rpmhpd SDM845_CX>;
 
phys = <&dsi1_phy>;
phy-names = "dsi";
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH v3 0/4] DVFS support for dpu and dsi

[Rajendra Nayak]

Changes in v3
- Added dev_pm_opp_put_clkname() in the error path

Changes in v2
- Patch 2: Dropped dsi_link_clk_set_rate_6g_v2 and dsi_link_clk_disable_6g_v2 
as suggested by Matthias

These patches add DVFS support for DPU and DSI.

These patches have no other dependency. Patch 1 and 2 will need to be merged in
via the MSM DRM tree.

DT patches will need to land via the msm tree.

Rajendra Nayak (4):
  drm/msm/dpu: Use OPP API to set clk/perf state
  drm/msm: dsi: Use OPP API to set clk/perf state
  arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains
  arm64: dts: sc7180: Add DSI and MDP OPP tables and power-domains

 arch/arm64/boot/dts/qcom/sc7180.dtsi  | 49 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi  | 59 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c |  3 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 27 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |  4 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c| 27 +++-
 6 files changed, 165 insertions(+), 4 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 13/17] drm/i915: Plumb port through hdcp init

[Ramalingam C]

On 2020-06-23 at 11:59:03 -0400, Sean Paul wrote:
> From: Sean Paul 
> 
> This patch plumbs port through hdcp init instead of relying on
> intel_attached_encoder() to return a non-NULL encoder which won't work
> for MST connectors.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Sean Paul 
Reviewed-by: Ramalingam C 

> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-13-s...@poorly.run
>  #v5
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-13-s...@poorly.run
>  #v6
> 
> Changes in v5:
> -Added to the set
> Changes in v6:
> -None
> Changes in v7:
> -None
> ---
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c |  3 ++-
>  drivers/gpu/drm/i915/display/intel_hdcp.c| 11 ++-
>  drivers/gpu/drm/i915/display/intel_hdcp.h|  2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c|  2 +-
>  4 files changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 0e06a1066d61..e26a45f880cb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -630,7 +630,8 @@ int intel_dp_init_hdcp(struct intel_digital_port 
> *intel_dig_port,
>   return 0;
>  
>   if (!intel_dp_is_edp(intel_dp))
> - return intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
> + return intel_hdcp_init(intel_connector, port,
> +&intel_dp_hdcp_shim);
>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 5679877c6b4c..d79d4142aea7 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -1955,6 +1955,7 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum 
> transcoder cpu_transcoder)
>  }
>  
>  static int initialize_hdcp_port_data(struct intel_connector *connector,
> +  enum port port,
>const struct intel_hdcp_shim *shim)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> @@ -1962,8 +1963,7 @@ static int initialize_hdcp_port_data(struct 
> intel_connector *connector,
>   struct hdcp_port_data *data = &hdcp->port_data;
>  
>   if (INTEL_GEN(dev_priv) < 12)
> - data->fw_ddi =
> - 
> intel_get_mei_fw_ddi_index(intel_attached_encoder(connector)->port);
> + data->fw_ddi = intel_get_mei_fw_ddi_index(port);
>   else
>   /*
>* As per ME FW API expectation, for GEN 12+, fw_ddi is filled
> @@ -2033,14 +2033,14 @@ void intel_hdcp_component_init(struct 
> drm_i915_private *dev_priv)
>   }
>  }
>  
> -static void intel_hdcp2_init(struct intel_connector *connector,
> +static void intel_hdcp2_init(struct intel_connector *connector, enum port 
> port,
>const struct intel_hdcp_shim *shim)
>  {
>   struct drm_i915_private *i915 = to_i915(connector->base.dev);
>   struct intel_hdcp *hdcp = &connector->hdcp;
>   int ret;
>  
> - ret = initialize_hdcp_port_data(connector, shim);
> + ret = initialize_hdcp_port_data(connector, port, shim);
>   if (ret) {
>   drm_dbg_kms(&i915->drm, "Mei hdcp data init failed\n");
>   return;
> @@ -2050,6 +2050,7 @@ static void intel_hdcp2_init(struct intel_connector 
> *connector,
>  }
>  
>  int intel_hdcp_init(struct intel_connector *connector,
> + enum port port,
>   const struct intel_hdcp_shim *shim)
>  {
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> @@ -2060,7 +2061,7 @@ int intel_hdcp_init(struct intel_connector *connector,
>   return -EINVAL;
>  
>   if (is_hdcp2_supported(dev_priv))
> - intel_hdcp2_init(connector, shim);
> + intel_hdcp2_init(connector, port, shim);
>  
>   ret =
>   drm_connector_attach_content_protection_property(&connector->base,
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h 
> b/drivers/gpu/drm/i915/display/intel_hdcp.h
> index 86bbaec120cc..1bbf5b67ed0a 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
> @@ -22,7 +22,7 @@ enum transcoder;
>  void intel_hdcp_atomic_check(struct drm_connector *connector,
>struct drm_connector_state *old_state,
>struct drm_connector_state *new_state);
> -int intel_hdcp_init(struct intel_connector *connector,
> +int intel_hdcp_init(struct intel_connector *connector, enum port port,
>   const struct intel_hdcp_shim *hdcp_shim);
>  int intel_hdcp_enable(struct intel_connector *connector,
> enum transcoder cpu_transcoder, u8 content_type);
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/int

RE: [PATCH v7 14/17] drm/i915: Add connector to hdcp_shim->check_link()

[C, Ramalingam]

> -Original Message-
> From: Sean Paul 
> Sent: Tuesday, June 23, 2020 9:29 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Li, Juston ; C, Ramalingam
> ; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
> ; daniel.vet...@ffwll.ch; Sean Paul
> 
> Subject: [PATCH v7 14/17] drm/i915: Add connector to hdcp_shim->check_link()
> 
> From: Sean Paul 
> 
> Currently we derive the connector from digital port in check_link(). For MST, 
> this
> isn't sufficient since the digital port passed into the function can have 
> multiple
> connectors downstream. This patch adds connector to the check_link()
> arguments so we have it when we need it.
> 
> Signed-off-by: Sean Paul 
Reviewed-by: Ramalingam C 

> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-
> s...@poorly.run #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-
> s...@poorly.run #v5
> Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-
> 14-s...@poorly.run #v6
> 
> Changes in v4:
> -Added to the set
> Changes in v5:
> -None
> Changes in v6:
> -None
> Changes in v7:
> -None
> ---
>  drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c   | 3 ++-
>  drivers/gpu/drm/i915/display/intel_hdcp.c  | 2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c  | 5 ++---
>  4 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 811085ef3fba..94211b8fc159 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -318,7 +318,8 @@ struct intel_hdcp_shim {
>bool enable);
> 
>   /* Ensures the link is still protected */
> - bool (*check_link)(struct intel_digital_port *intel_dig_port);
> + bool (*check_link)(struct intel_digital_port *intel_dig_port,
> +struct intel_connector *connector);
> 
>   /* Detects panel's hdcp capability. This is optional for HDMI. */
>   int (*hdcp_capable)(struct intel_digital_port *intel_dig_port, diff 
> --git
> a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index e26a45f880cb..43446a6cae8d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -223,7 +223,8 @@ int intel_dp_hdcp_toggle_signalling(struct
> intel_digital_port *intel_dig_port,  }
> 
>  static
> -bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port)
> +bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port,
> +   struct intel_connector *connector)
>  {
>   struct drm_i915_private *i915 = to_i915(intel_dig_port-
> >base.base.dev);
>   ssize_t ret;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index d79d4142aea7..6bd0e4616ee1 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -953,7 +953,7 @@ static int intel_hdcp_check_link(struct intel_connector
> *connector)
>   goto out;
>   }
> 
> - if (hdcp->shim->check_link(intel_dig_port)) {
> + if (hdcp->shim->check_link(intel_dig_port, connector)) {
>   if (hdcp->value !=
> DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
>   intel_hdcp_update_value(connector,
> 
>   DRM_MODE_CONTENT_PROTECTION_ENABLED, true); diff --git
> a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index ca71ee3dd1c7..b12f1af0611d 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1546,11 +1546,10 @@ int intel_hdmi_hdcp_toggle_signalling(struct
> intel_digital_port *intel_dig_port,  }
> 
>  static
> -bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port)
> +bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port,
> + struct intel_connector *connector)
>  {
>   struct drm_i915_private *i915 = to_i915(intel_dig_port-
> >base.base.dev);
> - struct intel_connector *connector =
> - intel_dig_port->hdmi.attached_connector;
>   enum port port = intel_dig_port->base.port;
>   enum transcoder cpu_transcoder = connector->hdcp.cpu_transcoder;
>   int ret;
> --
> Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v7 12/17] drm/i915: Factor out HDCP shim functions from dp for use by dp_mst

[C, Ramalingam]

> -Original Message-
> From: Sean Paul 
> Sent: Tuesday, June 23, 2020 9:29 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Li, Juston ; C, Ramalingam
> ; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
> ; daniel.vet...@ffwll.ch; Sean Paul
> 
> Subject: [PATCH v7 12/17] drm/i915: Factor out HDCP shim functions from dp
> for use by dp_mst
> 
> From: Sean Paul 
> 
> These functions are all the same for dp and dp_mst, so move them into a
> dedicated file for both sst and mst to use.
> 
> Signed-off-by: Sean Paul 
Reviewed-by: Ramalingam C 

> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-
> 11-s...@poorly.run #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-12-
> s...@poorly.run #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-12-
> s...@poorly.run #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-12-
> s...@poorly.run #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-12-
> s...@poorly.run #v5
> Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-
> 12-s...@poorly.run #v6
> 
> Changes in v2:
> -None
> Changes in v3:
> -Created intel_dp_hdcp.c for the shared functions to live (Ville) Changes in 
> v4:
> -Rebased on new drm logging change
> Changes in v5:
> -None
> Changes in v6:
> -None
> Changes in v7:
> -Rebased patch
> ---
>  drivers/gpu/drm/i915/Makefile|   1 +
>  drivers/gpu/drm/i915/display/intel_dp.c  | 606 +-
>  drivers/gpu/drm/i915/display/intel_dp.h  |   3 +
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 636 +++
>  4 files changed, 641 insertions(+), 605 deletions(-)  create mode 100644
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 41a27fd5dbc7..cba4ddb95ab1 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -233,6 +233,7 @@ i915-y += \
>   display/intel_ddi.o \
>   display/intel_dp.o \
>   display/intel_dp_aux_backlight.o \
> + display/intel_dp_hdcp.o \
>   display/intel_dp_link_training.o \
>   display/intel_dp_mst.o \
>   display/intel_dsi.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d98e45a09c28..78ce5e41d559 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -38,7 +38,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> 
>  #include "i915_debugfs.h"
> @@ -6396,609 +6395,6 @@ void intel_dp_encoder_suspend(struct
> intel_encoder *intel_encoder)
>   edp_panel_vdd_off_sync(intel_dp);
>  }
> 
> -static void intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp, int 
> timeout)
> -{
> - long ret;
> -
> -#define C (hdcp->cp_irq_count_cached != atomic_read(&hdcp->cp_irq_count))
> - ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
> -msecs_to_jiffies(timeout));
> -
> - if (!ret)
> - DRM_DEBUG_KMS("Timedout at waiting for CP_IRQ\n");
> -}
> -
> -static
> -int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> - u8 *an)
> -{
> - struct drm_i915_private *i915 = to_i915(intel_dig_port-
> >base.base.dev);
> - u8 aksv[DRM_HDCP_KSV_LEN] = {};
> - ssize_t dpcd_ret;
> -
> - dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux,
> DP_AUX_HDCP_AN,
> -  an, DRM_HDCP_AN_LEN);
> - if (dpcd_ret != DRM_HDCP_AN_LEN) {
> - drm_dbg_kms(&i915->drm,
> - "Failed to write An over DP/AUX (%zd)\n",
> - dpcd_ret);
> - return dpcd_ret >= 0 ? -EIO : dpcd_ret;
> - }
> -
> - /*
> -  * Since Aksv is Oh-So-Secret, we can't access it in software. So we
> -  * send an empty buffer of the correct length through the DP helpers. On
> -  * the other side, in the transfer hook, we'll generate a flag based on
> -  * the destination address which will tickle the hardware to output the
> -  * Aksv on our behalf after the header is sent.
> -  */
> - dpcd_ret = drm_dp_dpcd_write(&intel_dig_port->dp.aux,
> DP_AUX_HDCP_AKSV,
> -  aksv, DRM_HDCP_KSV_LEN);
> - if (dpcd_ret != DRM_HDCP_KSV_LEN) {
> - drm_dbg_kms(&i915->drm,
> - "Failed to write Aksv over DP/AUX (%zd)\n",
> - dpcd_ret);
> - return dpcd_ret >= 0 ? -EIO : dpcd_ret;
> - }
> - return 0;
> -}
> -
> -static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
> -u8 *bksv)
> -{
> - struct drm_i915_private *i

RE: [PATCH v7 11/17] drm/i915: Use ddi_update_pipe in intel_dp_mst

[C, Ramalingam]

> -Original Message-
> From: Sean Paul 
> Sent: Tuesday, June 23, 2020 9:29 PM
> To: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Li, Juston ; C, Ramalingam
> ; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
> ; daniel.vet...@ffwll.ch; Sean Paul
> 
> Subject: [PATCH v7 11/17] drm/i915: Use ddi_update_pipe in intel_dp_mst
> 
> From: Sean Paul 
> 
> In order to act upon content_protection property changes, we'll need to
> implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe for
> this
> 
> Signed-off-by: Sean Paul 
Reviewed-by: Ramalingam C 

> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-
> 10-s...@poorly.run #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-11-
> s...@poorly.run #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-11-
> s...@poorly.run #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-11-
> s...@poorly.run #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-11-
> s...@poorly.run #v5
> Link: https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-
> 11-s...@poorly.run #v6
> 
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -None
> Changes in v7:
> -None
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c| 11 ++-
>  drivers/gpu/drm/i915/display/intel_dp.h |  6 ++
>  drivers/gpu/drm/i915/display/intel_dp_mst.c |  1 +
>  3 files changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 536299f902b9..29f1f552e8d8 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3907,13 +3907,14 @@ static void intel_ddi_update_pipe_dp(struct
> intel_atomic_state *state,
>   intel_panel_update_backlight(state, encoder, crtc_state, conn_state);  }
> 
> -static void intel_ddi_update_pipe(struct intel_atomic_state *state,
> -   struct intel_encoder *encoder,
> -   const struct intel_crtc_state *crtc_state,
> -   const struct drm_connector_state
> *conn_state)
> +void intel_ddi_update_pipe(struct intel_atomic_state *state,
> +struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +const struct drm_connector_state *conn_state)
>  {
> 
> - if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
> + !intel_encoder_is_mst(encoder))
>   intel_ddi_update_pipe_dp(state, encoder, crtc_state,
>conn_state);
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 0a8950f744f6..6352c7e97e3b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -17,6 +17,7 @@ struct drm_encoder;
>  struct drm_i915_private;
>  struct drm_modeset_acquire_ctx;
>  struct drm_dp_vsc_sdp;
> +struct intel_atomic_state;
>  struct intel_connector;
>  struct intel_crtc_state;
>  struct intel_digital_port;
> @@ -128,4 +129,9 @@ static inline unsigned int intel_dp_unused_lane_mask(int
> lane_count)
> 
>  u32 intel_dp_mode_to_fec_clock(u32 mode_clock);
> 
> +void intel_ddi_update_pipe(struct intel_atomic_state *state,
> +struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state,
> +const struct drm_connector_state *conn_state);
> +
>  #endif /* __INTEL_DP_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 9308b5920780..0675825dcc20 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -836,6 +836,7 @@ intel_dp_create_fake_mst_encoder(struct
> intel_digital_port *intel_dig_port, enum
>   intel_encoder->compute_config_late =
> intel_dp_mst_compute_config_late;
>   intel_encoder->disable = intel_mst_disable_dp;
>   intel_encoder->post_disable = intel_mst_post_disable_dp;
> + intel_encoder->update_pipe = intel_ddi_update_pipe;
>   intel_encoder->pre_pll_enable = intel_mst_pre_pll_enable_dp;
>   intel_encoder->pre_enable = intel_mst_pre_enable_dp;
>   intel_encoder->enable = intel_mst_enable_dp;
> --
> Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 17/17] drm/i915: Add HDCP 1.4 support for MST connectors

[Ramalingam C]

On 2020-06-23 at 11:59:07 -0400, Sean Paul wrote:
> From: Sean Paul 
> 
> Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
> MST. Everything except for toggling the HDCP signalling and HDCP 2.2
> support is the same as the DP case, so we'll re-use those callbacks
> 
> Cc: Juston Li 
> Signed-off-by: Sean Paul 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
>  #v1
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
>  #v2
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-s...@poorly.run
>  #v3
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-s...@poorly.run
>  #v4
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-s...@poorly.run
>  #v5
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-s...@poorly.run
>  #v6
> 
> Changes in v2:
> -Toggle HDCP from encoder disable/enable
> -Don't disable HDCP on MST connector destroy, leave that for encoder
>  disable, just ensure the check_work routine isn't running any longer
> Changes in v3:
> -Place the shim in the new intel_dp_hdcp.c file (Ville)
> Changes in v4:
> -Actually use the mst shim for mst connections (Juston)
> -Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
> Changes in v5:
> -Add sleep on disable signalling to match hdmi delay
> Changes in v6:
> -Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
>  don't have hardware to test it
> Changes in v7:
> -Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam)
> ---
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 66 +++-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c  | 18 ++
>  drivers/gpu/drm/i915/display/intel_hdcp.c|  2 +-
>  3 files changed, 84 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 43446a6cae8d..3f67bd27fc3c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -7,10 +7,12 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
>  #include "intel_display_types.h"
> +#include "intel_ddi.h"
>  #include "intel_dp.h"
>  #include "intel_hdcp.h"
>  
> @@ -618,6 +620,65 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = 
> {
>   .protocol = HDCP_PROTOCOL_DP,
>  };
>  
> +static int
> +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port 
> *intel_dig_port,
> + enum transcoder cpu_transcoder,
> + bool enable)
> +{
> + struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> + int ret;
> +
> + if (!enable)
> + usleep_range(6, 60); /* Bspec says >= 6us */
> +
> + ret = intel_ddi_toggle_hdcp_signalling(&intel_dig_port->base,
> +cpu_transcoder, enable);
Sean,

This function toggles the TRANS_DDI_HDCP_SIGNALLING (9th)bit of 
TRANS_DDI_FUNC_CTL(tran)
But in the hw specification this bit is mentioned to be ignored for non
HDMI/DVI modes of the TRANS DDI.

Any reason why we need this? Did you try with out this function?

Apart from that Patch looks good to me.

-Ram

> + if (ret)
> + drm_dbg_kms(&i915->drm, "%s HDCP signalling failed (%d)\n",
> +   enable ? "Enable" : "Disable", ret);
> + return ret;
> +}
> +
> +static
> +bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *intel_dig_port,
> +   struct intel_connector *connector)
> +{
> + struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> + struct intel_dp *intel_dp = &intel_dig_port->dp;
> + struct drm_dp_query_stream_enc_status_ack_reply reply;
> + int ret;
> +
> + if (!intel_dp_hdcp_check_link(intel_dig_port, connector))
> + return false;
> +
> + ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
> +   connector->port, &reply);
> + if (ret) {
> + drm_dbg_kms(&i915->drm,
> + "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
> + connector->base.base.id, connector->base.name, ret);
> + return false;
> + }
> +
> + return reply.auth_completed && reply.encryption_enabled;
> +}
> +
> +static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
> + .write_an_aksv = intel_dp_hdcp_write_an_aksv,
> + .read_bksv = intel_dp_hdcp_read_bksv,
> + .read_bstatus = intel_dp_hdcp_read_bstatus,
> + .repeater_present = intel_dp_hdcp_repeater_present,
> + .read_ri_prime = intel_dp_hdcp_read_ri_prime,
> + .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
> + .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
> + .r

Re: [PATCH v2 11/22] drm: mxsfb: Stop using DRM simple display pipeline helper

[Stefan Agner]

Hi Laurent,

On 2020-06-16 03:50, Laurent Pinchart wrote:
> Hi Stefan,
> 
> On Thu, Jun 11, 2020 at 09:33:11PM +0200, Stefan Agner wrote:
>> On 2020-05-30 05:10, Laurent Pinchart wrote:
>> > The DRM simple display pipeline helper only supports a single plane. In
>> > order to prepare for support of the alpha plane on i.MX6SX and i.MX7,
>> > move away from the helper. No new feature is added.
>> >
>> > Signed-off-by: Laurent Pinchart 
>> > ---
>> > Changes since v1:
>> >
>> > - Move after mxsfb_crtc.c rename to mxsfb_kms.c
>> > ---
>> >  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 108 +++---
>> >  drivers/gpu/drm/mxsfb/mxsfb_drv.h |  23 ++--
>> >  drivers/gpu/drm/mxsfb/mxsfb_kms.c | 184 +++---
>> >  3 files changed, 197 insertions(+), 118 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> > b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> > index 204c1e52e9aa..a8da92976d13 100644
>> > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> > @@ -10,22 +10,23 @@
>> >
>> >  #include 
>> >  #include 
>> > +#include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >  #include 
>> > -#include 
>> >
>> > -#include 
>> >  #include 
>> > -#include 
>> > +#include 
>> > +#include 
>> >  #include 
>> >  #include 
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >  #include 
>> >  #include 
>> > -#include 
>> >  #include 
>> >
>> >  #include "mxsfb_drv.h"
>> > @@ -57,17 +58,6 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
>> >},
>> >  };
>> >
>> > -static const uint32_t mxsfb_formats[] = {
>> > -  DRM_FORMAT_XRGB,
>> > -  DRM_FORMAT_RGB565
>> > -};
>> > -
>> > -static struct mxsfb_drm_private *
>> > -drm_pipe_to_mxsfb_drm_private(struct drm_simple_display_pipe *pipe)
>> > -{
>> > -  return container_of(pipe, struct mxsfb_drm_private, pipe);
>> > -}
>> > -
>> >  void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
>> >  {
>> >if (mxsfb->clk_axi)
>> > @@ -90,77 +80,6 @@ static const struct drm_mode_config_helper_funcs
>> > mxsfb_mode_config_helpers = {
>> >.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
>> >  };
>> >
>> > -static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
>> > -struct drm_crtc_state *crtc_state,
>> > -struct drm_plane_state *plane_state)
>> > -{
>> > -  struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
>> > -  struct drm_device *drm = pipe->plane.dev;
>> > -
>> > -  pm_runtime_get_sync(drm->dev);
>> > -  mxsfb_crtc_enable(mxsfb);
>> > -}
>> > -
>> > -static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
>> > -{
>> > -  struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
>> > -  struct drm_device *drm = pipe->plane.dev;
>> > -  struct drm_crtc *crtc = &pipe->crtc;
>> > -  struct drm_pending_vblank_event *event;
>> > -
>> > -  mxsfb_crtc_disable(mxsfb);
>> > -  pm_runtime_put_sync(drm->dev);
>> > -
>> > -  spin_lock_irq(&drm->event_lock);
>> > -  event = crtc->state->event;
>> > -  if (event) {
>> > -  crtc->state->event = NULL;
>> > -  drm_crtc_send_vblank_event(crtc, event);
>> > -  }
>> > -  spin_unlock_irq(&drm->event_lock);
>> > -}
>> > -
>> > -static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
>> > -struct drm_plane_state *plane_state)
>> > -{
>> > -  struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
>> > -
>> > -  mxsfb_plane_atomic_update(mxsfb, plane_state);
>> > -}
>> > -
>> > -static int mxsfb_pipe_enable_vblank(struct drm_simple_display_pipe *pipe)
>> > -{
>> > -  struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
>> > -
>> > -  /* Clear and enable VBLANK IRQ */
>> > -  mxsfb_enable_axi_clk(mxsfb);
>> > -  writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
>> > -  writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_SET);
>> > -  mxsfb_disable_axi_clk(mxsfb);
>> > -
>> > -  return 0;
>> > -}
>> > -
>> > -static void mxsfb_pipe_disable_vblank(struct drm_simple_display_pipe 
>> > *pipe)
>> > -{
>> > -  struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
>> > -
>> > -  /* Disable and clear VBLANK IRQ */
>> > -  mxsfb_enable_axi_clk(mxsfb);
>> > -  writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_CLR);
>> > -  writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
>> > -  mxsfb_disable_axi_clk(mxsfb);
>> > -}
>> > -
>> > -static struct drm_simple_display_pipe_funcs mxsfb_funcs = {
>> > -  .enable = mxsfb_pipe_enable,
>> > -  .disable= mxsfb_pipe_disable,
>> > -  .update = mxsfb_pipe_update,
>> > -  .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
>> > -  .enable_vblank  = mxsfb_pipe_enable_vblank,
>> > -  .disable_vblank = mxsfb_pipe_disable_vblank,
>> > -};
>> > -
>> >  static int mxsfb_attach_bridge(struct mxsfb_drm_private *mxsfb

Re: [PATCH v7 10/17] drm/i915: Support DP MST in enc_to_dig_port() function

[Ramalingam C]

On 2020-06-23 at 11:59:00 -0400, Sean Paul wrote:
> From: Sean Paul 
> 
> Although DP_MST fake encoders are not subclassed from digital ports,
> they are associated with them. Support these encoders.
> 
> Signed-off-by: Sean Paul 
Reviewed-by: Ramalingam C 

> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
>  #v1
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-10-s...@poorly.run
>  #v2
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-10-s...@poorly.run
>  #v3
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-10-s...@poorly.run
>  #v4
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-10-s...@poorly.run
>  #v5
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-10-s...@poorly.run
>  #v6
> 
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -None
> Changes in v7:
> -None
> ---
>  .../drm/i915/display/intel_display_types.h| 21 ---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 1503403a808b..811085ef3fba 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1525,6 +1525,18 @@ static inline bool intel_encoder_is_dig_port(struct 
> intel_encoder *encoder)
>   }
>  }
>  
> +static inline bool intel_encoder_is_mst(struct intel_encoder *encoder)
> +{
> + return encoder->type == INTEL_OUTPUT_DP_MST;
> +}
> +
> +static inline struct intel_dp_mst_encoder *
> +enc_to_mst(struct intel_encoder *encoder)
> +{
> + return container_of(&encoder->base, struct intel_dp_mst_encoder,
> + base.base);
> +}
> +
>  static inline struct intel_digital_port *
>  enc_to_dig_port(struct intel_encoder *encoder)
>  {
> @@ -1533,6 +1545,8 @@ enc_to_dig_port(struct intel_encoder *encoder)
>   if (intel_encoder_is_dig_port(intel_encoder))
>   return container_of(&encoder->base, struct intel_digital_port,
>   base.base);
> + else if (intel_encoder_is_mst(intel_encoder))
> + return enc_to_mst(encoder)->primary;
>   else
>   return NULL;
>  }
> @@ -1543,13 +1557,6 @@ intel_attached_dig_port(struct intel_connector 
> *connector)
>   return enc_to_dig_port(intel_attached_encoder(connector));
>  }
>  
> -static inline struct intel_dp_mst_encoder *
> -enc_to_mst(struct intel_encoder *encoder)
> -{
> - return container_of(&encoder->base, struct intel_dp_mst_encoder,
> - base.base);
> -}
> -
>  static inline struct intel_dp *enc_to_intel_dp(struct intel_encoder *encoder)
>  {
>   return &enc_to_dig_port(encoder)->dp;
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] efi: avoid error message when booting under Xen

[Jürgen Groß]

On 28.06.20 10:50, Jürgen Groß wrote:

Ping?

On 10.06.20 16:10, Juergen Gross wrote:

efifb_probe() will issue an error message in case the kernel is booted
as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid
that message by calling efi_mem_desc_lookup() only if EFI_PARAVIRT
isn't set.

Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes 
when mapping the FB")

Signed-off-by: Juergen Gross 
---
  drivers/video/fbdev/efifb.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 65491ae74808..f5eccd1373e9 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -453,7 +453,7 @@ static int efifb_probe(struct platform_device *dev)
  info->apertures->ranges[0].base = efifb_fix.smem_start;
  info->apertures->ranges[0].size = size_remap;
-    if (efi_enabled(EFI_BOOT) &&
+    if (efi_enabled(EFI_BOOT) && !efi_enabled(EFI_PARAVIRT) &&
  !efi_mem_desc_lookup(efifb_fix.smem_start, &md)) {
  if ((efifb_fix.smem_start + efifb_fix.smem_len) >
  (md.phys_addr + (md.num_pages << EFI_PAGE_SHIFT))) {





In case I see no reaction from the maintainer for another week I'll take
this patch through the Xen tree.


Juergen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object

[Christian König]

Am 08.07.20 um 18:11 schrieb Daniel Vetter:

On Wed, Jul 8, 2020 at 5:05 PM Christian König  wrote:

Am 08.07.20 um 17:01 schrieb Daniel Vetter:

On Wed, Jul 8, 2020 at 4:37 PM Christian König  wrote:

Am 08.07.20 um 11:54 schrieb Daniel Vetter:

On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote:

Am 07.07.20 um 20:35 schrieb Chris Wilson:

Quoting lepton (2020-07-07 19:17:51)

On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson  wrote:

Quoting lepton (2020-07-07 18:05:21)

On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson  wrote:

If we assign obj->filp, we believe that the create vgem bo is native and
allow direct operations like mmap() assuming it behaves as backed by a
shmemfs inode. When imported from a dmabuf, the obj->pages are
not always meaningful and the shmemfs backing store misleading.

Note, that regular mmap access to a vgem bo is via the dumb buffer API,
and that rejects attempts to mmap an imported dmabuf,

What do you mean by "regular mmap access" here?  It looks like vgem is
using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call
drm_gem_dumb_map_offset

As I too found out, and so had to correct my story telling.

By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer
API] as opposed to mmap() via an exported dma-buf fd. I had to look at
igt to see how it was being used.

Now it seems your fix is to disable "regular mmap" on imported dma buf
for vgem. I am not really a graphic guy, but then the api looks like:
for a gem handle, user space has to guess to find out the way to mmap
it. If user space guess wrong, then it will fail to mmap. Is this the
expected way
for people to handle gpu buffer?

You either have a dumb buffer handle, or a dma-buf fd. If you have the
handle, you have to use the dumb buffer API, there's no other way to
mmap it. If you have the dma-buf fd, you should mmap it directly. Those
two are clear.

It's when you import the dma-buf into vgem and create a handle out of
it, that's when the handle is no longer first class and certain uAPI
[the dumb buffer API in particular] fail.

It's not brilliant, as you say, it requires the user to remember the
difference between the handles, but at the same time it does prevent
them falling into coherency traps by forcing them to use the right
driver to handle the object, and have to consider the additional ioctls
that go along with that access.

Yes, Chris is right. Mapping DMA-buf through the mmap() APIs of an importer
is illegal.

What we could maybe try to do is to redirect this mmap() API call on the
importer to the exporter, but I'm pretty sure that the fs layer wouldn't
like that without changes.

We already do that, there's a full helper-ified path from I think shmem
helpers through prime helpers to forward this all. Including handling
buffer offsets and all the other lolz back&forth.

Oh, that most likely won't work correctly with unpinned DMA-bufs and
needs to be avoided.

Each file descriptor is associated with an struct address_space. And
when you mmap() through the importer by redirecting the system call to
the exporter you end up with the wrong struct address_space in your VMA.

That in turn can go up easily in flames when the exporter tries to
invalidate the CPU mappings for its DMA-buf while moving it.

Where are we doing this? My last status was that this is forbidden.

Hm I thought we're doing all that already, but looking at the code
again we're only doing this when opening a new drm fd or dma-buf fd.
So the right file->f_mapping is always set at file creation time.

And we indeed don't frob this more when going another indirection ...
Maybe we screwed up something somewhere :-/

Also I thought the mapping is only taken after the vma is instatiated,
otherwise the tricks we're playing with dma-buf already wouldn't work:
dma-buf has the buffer always at offset 0, whereas gem drm_fd mmap has
it somewhere else. We already adjust vma->vm_pgoff, so I'm wondering
whether we could adjust vm_file too. Or is that the thing that's
forbidden?

Yes, exactly. Modifying vm_pgoff is harmless, tons of code does that.

But changing vma->vm_file, that's something I haven't seen before and
most likely could blow up badly.

Ok, I read the shmem helpers again, I think those are the only ones
which do the importer mmap -> dma_buf_mmap() forwarding, and hence
break stuff all around here.

They also remove the vma->vm_pgoff offset, which means
unmap_mapping_range wont work anyway. I guess for drivers which use
shmem helpers the hard assumption is that a) can't use p2p dma and b)
pin everything into system memory.

So not a problem. But something to keep in mind. I'll try to do a
kerneldoc patch to note this somewhere. btw on that, did the
timeline/syncobj documentation patch land by now? Just trying to make
sure that doesn't get lost for another few months or so :-/


I still haven't found time to double check the documentation and most 
likely won't in quite a while.


Sorry for that, but yeah you know

Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object

[Christian König]

Am 08.07.20 um 18:19 schrieb Daniel Vetter:

On Wed, Jul 8, 2020 at 6:11 PM Daniel Vetter  wrote:

On Wed, Jul 8, 2020 at 5:05 PM Christian König  wrote:

Am 08.07.20 um 17:01 schrieb Daniel Vetter:

On Wed, Jul 8, 2020 at 4:37 PM Christian König  wrote:

Am 08.07.20 um 11:54 schrieb Daniel Vetter:

On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote:

Am 07.07.20 um 20:35 schrieb Chris Wilson:

Quoting lepton (2020-07-07 19:17:51)

On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson  wrote:

Quoting lepton (2020-07-07 18:05:21)

On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson  wrote:

If we assign obj->filp, we believe that the create vgem bo is native and
allow direct operations like mmap() assuming it behaves as backed by a
shmemfs inode. When imported from a dmabuf, the obj->pages are
not always meaningful and the shmemfs backing store misleading.

Note, that regular mmap access to a vgem bo is via the dumb buffer API,
and that rejects attempts to mmap an imported dmabuf,

What do you mean by "regular mmap access" here?  It looks like vgem is
using vgem_gem_dumb_map as .dumb_map_offset callback then it doesn't call
drm_gem_dumb_map_offset

As I too found out, and so had to correct my story telling.

By regular mmap() access I mean mmap on the vgem bo [via the dumb buffer
API] as opposed to mmap() via an exported dma-buf fd. I had to look at
igt to see how it was being used.

Now it seems your fix is to disable "regular mmap" on imported dma buf
for vgem. I am not really a graphic guy, but then the api looks like:
for a gem handle, user space has to guess to find out the way to mmap
it. If user space guess wrong, then it will fail to mmap. Is this the
expected way
for people to handle gpu buffer?

You either have a dumb buffer handle, or a dma-buf fd. If you have the
handle, you have to use the dumb buffer API, there's no other way to
mmap it. If you have the dma-buf fd, you should mmap it directly. Those
two are clear.

It's when you import the dma-buf into vgem and create a handle out of
it, that's when the handle is no longer first class and certain uAPI
[the dumb buffer API in particular] fail.

It's not brilliant, as you say, it requires the user to remember the
difference between the handles, but at the same time it does prevent
them falling into coherency traps by forcing them to use the right
driver to handle the object, and have to consider the additional ioctls
that go along with that access.

Yes, Chris is right. Mapping DMA-buf through the mmap() APIs of an importer
is illegal.

What we could maybe try to do is to redirect this mmap() API call on the
importer to the exporter, but I'm pretty sure that the fs layer wouldn't
like that without changes.

We already do that, there's a full helper-ified path from I think shmem
helpers through prime helpers to forward this all. Including handling
buffer offsets and all the other lolz back&forth.

Oh, that most likely won't work correctly with unpinned DMA-bufs and
needs to be avoided.

Each file descriptor is associated with an struct address_space. And
when you mmap() through the importer by redirecting the system call to
the exporter you end up with the wrong struct address_space in your VMA.

That in turn can go up easily in flames when the exporter tries to
invalidate the CPU mappings for its DMA-buf while moving it.

Where are we doing this? My last status was that this is forbidden.

Hm I thought we're doing all that already, but looking at the code
again we're only doing this when opening a new drm fd or dma-buf fd.
So the right file->f_mapping is always set at file creation time.

And we indeed don't frob this more when going another indirection ...
Maybe we screwed up something somewhere :-/

Also I thought the mapping is only taken after the vma is instatiated,
otherwise the tricks we're playing with dma-buf already wouldn't work:
dma-buf has the buffer always at offset 0, whereas gem drm_fd mmap has
it somewhere else. We already adjust vma->vm_pgoff, so I'm wondering
whether we could adjust vm_file too. Or is that the thing that's
forbidden?

Yes, exactly. Modifying vm_pgoff is harmless, tons of code does that.

But changing vma->vm_file, that's something I haven't seen before and
most likely could blow up badly.

Ok, I read the shmem helpers again, I think those are the only ones
which do the importer mmap -> dma_buf_mmap() forwarding, and hence
break stuff all around here.

They also remove the vma->vm_pgoff offset, which means
unmap_mapping_range wont work anyway. I guess for drivers which use
shmem helpers the hard assumption is that a) can't use p2p dma and b)
pin everything into system memory.

So not a problem. But something to keep in mind. I'll try to do a
kerneldoc patch to note this somewhere. btw on that, did the
timeline/syncobj documentation patch land by now? Just trying to make
sure that doesn't get lost for another few months or so :-/

Ok, so maybe it is a problem. Because there is a drm_gem_shmem_purge()
which uses un

Re: [PATCH 02/25] dma-fence: prime lockdep annotations

[Daniel Vetter]

Hi Jason,

Below the paragraph I've added after our discussions around dma-fences
outside of drivers/gpu. Good enough for an ack on this, or want something
changed?

Thanks, Daniel

> + * Note that only GPU drivers have a reasonable excuse for both requiring
> + * &mmu_interval_notifier and &shrinker callbacks at the same time as having 
> to
> + * track asynchronous compute work using &dma_fence. No driver outside of
> + * drivers/gpu should ever call dma_fence_wait() in such contexts.


On Tue, Jul 07, 2020 at 10:12:06PM +0200, Daniel Vetter wrote:
> Two in one go:
> - it is allowed to call dma_fence_wait() while holding a
>   dma_resv_lock(). This is fundamental to how eviction works with ttm,
>   so required.
> 
> - it is allowed to call dma_fence_wait() from memory reclaim contexts,
>   specifically from shrinker callbacks (which i915 does), and from mmu
>   notifier callbacks (which amdgpu does, and which i915 sometimes also
>   does, and probably always should, but that's kinda a debate). Also
>   for stuff like HMM we really need to be able to do this, or things
>   get real dicey.
> 
> Consequence is that any critical path necessary to get to a
> dma_fence_signal for a fence must never a) call dma_resv_lock nor b)
> allocate memory with GFP_KERNEL. Also by implication of
> dma_resv_lock(), no userspace faulting allowed. That's some supremely
> obnoxious limitations, which is why we need to sprinkle the right
> annotations to all relevant paths.
> 
> The one big locking context we're leaving out here is mmu notifiers,
> added in
> 
> commit 23b68395c7c78a764e8963fc15a7cfd318bf187f
> Author: Daniel Vetter 
> Date:   Mon Aug 26 22:14:21 2019 +0200
> 
> mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end
> 
> that one covers a lot of other callsites, and it's also allowed to
> wait on dma-fences from mmu notifiers. But there's no ready-made
> functions exposed to prime this, so I've left it out for now.
> 
> v2: Also track against mmu notifier context.
> 
> v3: kerneldoc to spec the cross-driver contract. Note that currently
> i915 throws in a hard-coded 10s timeout on foreign fences (not sure
> why that was done, but it's there), which is why that rule is worded
> with SHOULD instead of MUST.
> 
> Also some of the mmu_notifier/shrinker rules might surprise SoC
> drivers, I haven't fully audited them all. Which is infeasible anyway,
> we'll need to run them with lockdep and dma-fence annotations and see
> what goes boom.
> 
> v4: A spelling fix from Mika
> 
> v5: #ifdef for CONFIG_MMU_NOTIFIER. Reported by 0day. Unfortunately
> this means lockdep enforcement is slightly inconsistent, it won't spot
> GFP_NOIO and GFP_NOFS allocations in the wrong spot if
> CONFIG_MMU_NOTIFIER is disabled in the kernel config. Oh well.
> 
> v5: Note that only drivers/gpu has a reasonable (or at least
> historical) excuse to use dma_fence_wait() from shrinker and mmu
> notifier callbacks. Everyone else should either have a better memory
> manager model, or better hardware. This reflects discussions with
> Jason Gunthorpe.
> 
> Cc: Jason Gunthorpe 
> Cc: Felix Kuehling 
> Cc: kernel test robot 
> Reviewed-by: Thomas Hellström  (v4)
> Cc: Mika Kuoppala 
> Cc: Thomas Hellstrom 
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-...@lists.freedesktop.org
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Cc: Christian König 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/driver-api/dma-buf.rst |  6 
>  drivers/dma-buf/dma-fence.c  | 46 
>  drivers/dma-buf/dma-resv.c   |  8 +
>  include/linux/dma-fence.h|  1 +
>  4 files changed, 61 insertions(+)
> 
> diff --git a/Documentation/driver-api/dma-buf.rst 
> b/Documentation/driver-api/dma-buf.rst
> index 05d856131140..f8f6decde359 100644
> --- a/Documentation/driver-api/dma-buf.rst
> +++ b/Documentation/driver-api/dma-buf.rst
> @@ -133,6 +133,12 @@ DMA Fences
>  .. kernel-doc:: drivers/dma-buf/dma-fence.c
> :doc: DMA fences overview
>  
> +DMA Fence Cross-Driver Contract
> +~~~
> +
> +.. kernel-doc:: drivers/dma-buf/dma-fence.c
> +   :doc: fence cross-driver contract
> +
>  DMA Fence Signalling Annotations
>  
>  
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 0005bc002529..af1d8ea926b3 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -64,6 +64,52 @@ static atomic64_t dma_fence_context_counter = 
> ATOMIC64_INIT(1);
>   *   &dma_buf.resv pointer.
>   */
>  
> +/**
> + * DOC: fence cross-driver contract
> + *
> + * Since &dma_fence provide a cross driver contract, all drivers must follow 
> the
> + * same rules:
> + *
> + * * Fences must complete in a reasonable time. Fences which represent 
> kernels
> + *   and shaders submitted by userspace, which could run foreve

Re: [Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea

[Daniel Vetter]

On Thu, Jul 09, 2020 at 08:36:43AM +0100, Daniel Stone wrote:
> Hi,
> 
> On Tue, 7 Jul 2020 at 21:13, Daniel Vetter  wrote:
> > Comes up every few years, gets somewhat tedious to discuss, let's
> > write this down once and for all.
> 
> Thanks for writing this up! I wonder if any of the notes from my reply
> to the previous-version thread would be helpful to more explicitly
> encode the carrot of dma-fence's positive guarantees, rather than just
> the stick of 'don't do this'. ;) Either way, this is:

I think the carrot should go into the intro section for dma-fence, this
section here is very much just the "don't do this" part. The previous
patches have an attempt at encoding this a bit, maybe see whether there's
a place for your reply (or parts of it) to fit?

> Acked-by: Daniel Stone 
> 
> > What I'm not sure about is whether the text should be more explicit in
> > flat out mandating the amdkfd eviction fences for long running compute
> > workloads or workloads where userspace fencing is allowed.
> 
> ... or whether we just say that you can never use dma-fence in
> conjunction with userptr.

Uh userptr is entirely different thing. That one is ok. It's userpsace
fences or gpu futexes or future fences or whatever we want to call them.
Or is there some other confusion here?.
-Daniel


> 
> Cheers,
> 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: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

[Daniel Vetter]

On Thu, Jul 09, 2020 at 08:29:21AM +0100, Daniel Stone wrote:
> Hi,
> Jumping in after a couple of weeks where I've paged most everything
> out of my brain ...
> 
> On Fri, 19 Jun 2020 at 10:43, Daniel Vetter  wrote:
> > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > > The proposed patches might very well encode the wrong contract, that's
> > > > all up for discussion. But fundamentally questioning that we need one
> > > > is missing what upstream is all about.
> > >
> > > Then I have not clearly communicated, as my opinion is not that
> > > validation is worthless, but that the implementation is enshrining a
> > > global property on a low level primitive that prevents it from being
> > > used elsewhere. And I want to replace completion [chains] with fences, and
> > > bio with fences, and closures with fences, and what other equivalencies
> > > there are in the kernel. The fence is as central a locking construct as
> > > struct completion and deserves to be a foundational primitive provided
> > > by kernel/ used throughout all drivers for discrete problem domains.
> > >
> > > This is narrowing dma_fence whereby adding
> > >   struct lockdep_map *dma_fence::wait_map
> > > and annotating linkage, allows you to continue to specify that all
> > > dma_fence used for a particular purpose must follow common rules,
> > > without restricting the primitive for uses outside of this scope.
> >
> > Somewhere else in this thread I had discussions with Jason Gunthorpe about
> > this topic. It might maybe change somewhat depending upon exact rules, but
> > his take is very much "I don't want dma_fence in rdma". Or pretty close to
> > that at least.
> >
> > Similar discussions with habanalabs, they're using dma_fence internally
> > without any of the uapi. Discussion there has also now concluded that it's
> > best if they remove them, and simply switch over to a wait_queue or
> > completion like every other driver does.
> >
> > The next round of the patches already have a paragraph to at least
> > somewhat limit how non-gpu drivers use dma_fence. And I guess actual
> > consensus might be pointing even more strongly at dma_fence being solely
> > something for gpus and closely related subsystem (maybe media) for syncing
> > dma-buf access.
> >
> > So dma_fence as general replacement for completion chains I think just
> > wont happen.
> >
> > What might make sense is if e.g. the lockdep annotations could be reused,
> > at least in design, for wait_queue or completion or anything else
> > really. I do think that has a fair chance compared to the automagic
> > cross-release annotations approach, which relied way too heavily on
> > guessing where barriers are. My experience from just a bit of playing
> > around with these patches here and discussing them with other driver
> > maintainers is that accurately deciding where critical sections start and
> > end is a job for humans only. And if you get it wrong, you will have a
> > false positive.
> >
> > And you're indeed correct that if we'd do annotations for completions and
> > wait queues, then that would need to have a class per semantically
> > equivalent user, like we have lockdep classes for mutexes, not just one
> > overall.
> >
> > But dma_fence otoh is something very specific, which comes with very
> > specific rules attached - it's not a generic wait_queue at all. Originally
> > it did start out as one even, but it is a very specialized wait_queue.
> >
> > So there's imo two cases:
> >
> > - Your completion is entirely orthogonal of dma_fences, and can never ever
> >   block a dma_fence. Don't use dma_fence for this, and no problem. It's
> >   just another wait_queue somewhere.
> >
> > - Your completion can eventually, maybe through lots of convolutions and
> >   depdencies, block a dma_fence. In that case full dma_fence rules apply,
> >   and the only thing you can do with a custom annotation is make the rules
> >   even stricter. E.g. if a sub-timeline in the scheduler isn't allowed to
> >   take certain scheduler locks. But the userspace visible/published fence
> >   do take them, maybe as part of command submission or retirement.
> >   Entirely hypotethical, no idea any driver actually needs this.
> 
> I don't claim to understand the implementation of i915's scheduler and
> GEM handling, and it seems like there's some public context missing
> here. But to me, the above is a good statement of what I (and a lot of
> other userspace) have been relying on - that dma-fence is a very
> tightly scoped thing which is very predictable but in extremis.
> 
> It would be great to have something like this enshrined in dma-fence
> documentation, visible to both kernel and external users. The
> properties we've so far been assuming for the graphics pipeline -
> covering production & execution of vertex/fragment workloads on the
> GPU, framebuffer display, and to the extent this is necessary
> involving compute - are something like this:
> 
> A single dma-fen

Re: [PATCH v2] drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs

[Philippe CORNU]

On 7/8/20 7:08 PM, Angelo Ribeiro wrote:
> Hi,
> 
> Is this patch good to go?
> @dan...@ffwll.ch, @Philippe CORNU
> 
> Was already tested by @Yannick FERTRE
> and @Adrian Pop
> on https://lkml.org/lkml/2020/4/6/691 .
> 
> Thanks,
> Angelo
> 
> From: Yannick
> FERTRE 
> Date: Wed, Jun 24, 2020 at 16:35:04
> 
>> Hello Angelo,
>> thanks for the patch.
>> Tested-by: Yannick Fertre 
>> Tested OK on STM32MP1-DISCO, DSI v1.31
>>
>> Best regards
>>
>>
>> On 4/6/20 3:49 PM, Angelo Ribeiro wrote:
>>> Add support for the video pattern generator (VPG) BER pattern mode and
>>> configuration in runtime.
>>>
>>> This enables using the debugfs interface to manipulate the VPG after
>>> the pipeline is set.
>>> Also, enables the usage of the VPG BER pattern.
>>>
>>> Changes in v2:
>>> - Added VID_MODE_VPG_MODE
>>> - Solved incompatible return type on __get and __set
>>>
>>> Reported-by: kbuild test robot 
>>> Reported-by: Adrian Pop 
>>> Cc: Gustavo Pimentel 
>>> Cc: Joao Pinto 
>>> Cc: Jose Abreu 
>>> Signed-off-by: Angelo Ribeiro 
>>> ---
>>>drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 98 
>>> ---
>>>1 file changed, 90 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
>>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> index b18351b..9de3645 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> @@ -91,6 +91,7 @@
>>>#define VID_MODE_TYPE_BURST  0x2
>>>#define VID_MODE_TYPE_MASK   0x3
>>>#define VID_MODE_VPG_ENABLE  BIT(16)
>>> +#define VID_MODE_VPG_MODE  BIT(20)
>>>#define VID_MODE_VPG_HORIZONTAL  BIT(24)
>>>
>>>#define DSI_VID_PKT_SIZE 0x3c
>>> @@ -221,6 +222,21 @@
>>>#define PHY_STATUS_TIMEOUT_US1
>>>#define CMD_PKT_STATUS_TIMEOUT_US2
>>>
>>> +#ifdef CONFIG_DEBUG_FS
>>> +#define VPG_DEFS(name, dsi) \
>>> +   ((void __force *)&((*dsi).vpg_defs.name))
>>> +
>>> +#define REGISTER(name, mask, dsi) \
>>> +   { #name, VPG_DEFS(name, dsi), mask, dsi }
>>> +
>>> +struct debugfs_entries {
>>> +   const char  *name;
>>> +   bool*reg;
>>> +   u32 mask;
>>> +   struct dw_mipi_dsi  *dsi;
>>> +};
>>> +#endif /* CONFIG_DEBUG_FS */
>>> +
>>>struct dw_mipi_dsi {
>>> struct drm_bridge bridge;
>>> struct mipi_dsi_host dsi_host;
>>> @@ -238,9 +254,12 @@ struct dw_mipi_dsi {
>>>
>>>#ifdef CONFIG_DEBUG_FS
>>> struct dentry *debugfs;
>>> -
>>> -   bool vpg;
>>> -   bool vpg_horizontal;
>>> +   struct debugfs_entries *debugfs_vpg;
>>> +   struct {
>>> +   bool vpg;
>>> +   bool vpg_horizontal;
>>> +   bool vpg_ber_pattern;
>>> +   } vpg_defs;
>>>#endif /* CONFIG_DEBUG_FS */
>>>
>>> struct dw_mipi_dsi *master; /* dual-dsi master ptr */
>>> @@ -530,9 +549,11 @@ static void dw_mipi_dsi_video_mode_config(struct 
>>> dw_mipi_dsi *dsi)
>>> val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;
>>>
>>>#ifdef CONFIG_DEBUG_FS
>>> -   if (dsi->vpg) {
>>> +   if (dsi->vpg_defs.vpg) {
>>> val |= VID_MODE_VPG_ENABLE;
>>> -   val |= dsi->vpg_horizontal ? VID_MODE_VPG_HORIZONTAL : 0;
>>> +   val |= dsi->vpg_defs.vpg_horizontal ?
>>> +  VID_MODE_VPG_HORIZONTAL : 0;
>>> +   val |= dsi->vpg_defs.vpg_ber_pattern ? VID_MODE_VPG_MODE : 0;
>>> }
>>>#endif /* CONFIG_DEBUG_FS */
>>>
>>> @@ -961,6 +982,68 @@ static const struct drm_bridge_funcs 
>>> dw_mipi_dsi_bridge_funcs = {
>>>
>>>#ifdef CONFIG_DEBUG_FS
>>>
>>> +int dw_mipi_dsi_debugfs_write(void *data, u64 val)
>>> +{
>>> +   struct debugfs_entries *vpg = data;
>>> +   struct dw_mipi_dsi *dsi;
>>> +   u32 mode_cfg;
>>> +
>>> +   if (!vpg)
>>> +   return -ENODEV;
>>> +
>>> +   dsi = vpg->dsi;
>>> +
>>> +   *vpg->reg = (bool)val;
>>> +
>>> +   mode_cfg = dsi_read(dsi, DSI_VID_MODE_CFG);
>>> +
>>> +   if (*vpg->reg)
>>> +   mode_cfg |= vpg->mask;
>>> +   else
>>> +   mode_cfg &= ~vpg->mask;
>>> +
>>> +   dsi_write(dsi, DSI_VID_MODE_CFG, mode_cfg);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +int dw_mipi_dsi_debugfs_show(void *data, u64 *val)
>>> +{
>>> +   struct debugfs_entries *vpg = data;
>>> +
>>> +   if (!vpg)
>>> +   return -ENODEV;
>>> +
>>> +   *val = *vpg->reg;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +DEFINE_DEBUGFS_ATTRIBUTE(fops_x32, dw_mipi_dsi_debugfs_show,
>>> +dw_mipi_dsi_debugfs_write, "%llu\n");
>>> +
>>> +static void debugfs_create_files(void *data)
>>> +{
>>> +   struct dw_mipi_dsi *dsi = data;
>>> +   struct debugfs_entries debugfs[] = {
>>> +   REGISTER(vpg, VID_MODE_VPG_ENABLE, dsi),
>>> +   REGISTER(vpg_horizontal, VID_MODE_VPG_HORIZONTAL, dsi),
>>> +   REGISTER

Re: [PATCH] drm/exynos: gem: Fix sparse warning

[Krzysztof Kozlowski]

On Tue, Jul 07, 2020 at 01:08:59PM +0200, Marek Szyprowski wrote:
> Add a proper cast on the exynos_gem->kvaddr assignment to avoid a sparse 
> warning.
> 
> Reported-by: kernel test robot 
> Fixes: 9940d9d93406 ("drm/exynos: gem: Get rid of the internal 'pages' array")
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 01/25] dma-fence: basic lockdep annotations

[Daniel Vetter]

On Thu, Jul 09, 2020 at 08:32:41AM +0100, Daniel Stone wrote:
> Hi,
> 
> On Wed, 8 Jul 2020 at 16:13, Daniel Vetter  wrote:
> > On Wed, Jul 8, 2020 at 4:57 PM Christian König  
> > wrote:
> > > Could we merge this controlled by a separate config option?
> > >
> > > This way we could have the checks upstream without having to fix all the
> > > stuff before we do this?
> >
> > Since it's fully opt-in annotations nothing blows up if we don't merge
> > any annotations. So we could start merging the first 3 patches. After
> > that the fun starts ...
> >
> > My rough idea was that first I'd try to tackle display, thus far
> > there's 2 actual issues in drivers:
> > - amdgpu has some dma_resv_lock in commit_tail, plus a kmalloc. I
> > think those should be fairly easy to fix (I'd try a stab at them even)
> > - vmwgfx has a full on locking inversion with dma_resv_lock in
> > commit_tail, and that one is functional. Not just reading something
> > which we can safely assume to be invariant anyway (like the tmz flag
> > for amdgpu, or whatever it was).
> >
> > I've done a pile more annotations patches for other atomic drivers
> > now, so hopefully that flushes out any remaining offenders here. Since
> > some of the annotations are in helper code worst case we might need a
> > dev->mode_config.broken_atomic_commit flag to disable them. At least
> > for now I have 0 plans to merge any of these while there's known
> > unsolved issues. Maybe if some drivers take forever to get fixed we
> > can then apply some duct-tape for the atomic helper annotation patch.
> > Instead of a flag we can also copypasta the atomic_commit_tail hook,
> > leaving the annotations out and adding a huge warning about that.
> 
> How about an opt-in drm_driver DRIVER_DEADLOCK_HAPPY flag? At first
> this could just disable the annotations and nothing else, but as we
> see the annotations gaining real-world testing and maturity, we could
> eventually make it taint the kernel.

You can do that pretty much per-driver, since the annotations are pretty
much per-driver. No annotations in your code, no lockdep splat. Only if
there's some dma_fence_begin/end_signalling() calls is there even the
chance of a problem.

E.g. this round has the i915 patch dropped and *trar* intel-gfx-ci is
happy (or well at least a lot happier, there's some noise in there that's
probably not from my stuff).

So I guess if amd wants this, we could do an DRM_AMDGPU_MOAR_LOCKDEP
Kconfig or similar. I haven't tested, but I think as long as we don't
merge any of the amdgpu specific patches, there's no splat in amdgpu. So
with that I think that's plenty enough opt-in for each driver. The only
problem is a bit shared helper code like atomic helpers and drm scheduler.
There we might need some opt-out (I don't think merging makes sense when
most of the users are still broken).
-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

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=207383

--- Comment #52 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to rtmasura+kernel from comment #51)
> that didn't read well, with vblank_mode off for XFWM I don't have this issue
> at all.

That just avoids the problem by not doing any page flips.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea

[Daniel Stone]

Hi,

On Tue, 7 Jul 2020 at 21:13, Daniel Vetter  wrote:
> Comes up every few years, gets somewhat tedious to discuss, let's
> write this down once and for all.

Thanks for writing this up! I wonder if any of the notes from my reply
to the previous-version thread would be helpful to more explicitly
encode the carrot of dma-fence's positive guarantees, rather than just
the stick of 'don't do this'. ;) Either way, this is:
Acked-by: Daniel Stone 

> What I'm not sure about is whether the text should be more explicit in
> flat out mandating the amdkfd eviction fences for long running compute
> workloads or workloads where userspace fencing is allowed.

... or whether we just say that you can never use dma-fence in
conjunction with userptr.

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 01/25] dma-fence: basic lockdep annotations

[Daniel Stone]

Hi,

On Wed, 8 Jul 2020 at 16:13, Daniel Vetter  wrote:
> On Wed, Jul 8, 2020 at 4:57 PM Christian König  
> wrote:
> > Could we merge this controlled by a separate config option?
> >
> > This way we could have the checks upstream without having to fix all the
> > stuff before we do this?
>
> Since it's fully opt-in annotations nothing blows up if we don't merge
> any annotations. So we could start merging the first 3 patches. After
> that the fun starts ...
>
> My rough idea was that first I'd try to tackle display, thus far
> there's 2 actual issues in drivers:
> - amdgpu has some dma_resv_lock in commit_tail, plus a kmalloc. I
> think those should be fairly easy to fix (I'd try a stab at them even)
> - vmwgfx has a full on locking inversion with dma_resv_lock in
> commit_tail, and that one is functional. Not just reading something
> which we can safely assume to be invariant anyway (like the tmz flag
> for amdgpu, or whatever it was).
>
> I've done a pile more annotations patches for other atomic drivers
> now, so hopefully that flushes out any remaining offenders here. Since
> some of the annotations are in helper code worst case we might need a
> dev->mode_config.broken_atomic_commit flag to disable them. At least
> for now I have 0 plans to merge any of these while there's known
> unsolved issues. Maybe if some drivers take forever to get fixed we
> can then apply some duct-tape for the atomic helper annotation patch.
> Instead of a flag we can also copypasta the atomic_commit_tail hook,
> leaving the annotations out and adding a huge warning about that.

How about an opt-in drm_driver DRIVER_DEADLOCK_HAPPY flag? At first
this could just disable the annotations and nothing else, but as we
see the annotations gaining real-world testing and maturity, we could
eventually make it taint the kernel.

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

[Daniel Stone]

Hi,
Jumping in after a couple of weeks where I've paged most everything
out of my brain ...

On Fri, 19 Jun 2020 at 10:43, Daniel Vetter  wrote:
> On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > The proposed patches might very well encode the wrong contract, that's
> > > all up for discussion. But fundamentally questioning that we need one
> > > is missing what upstream is all about.
> >
> > Then I have not clearly communicated, as my opinion is not that
> > validation is worthless, but that the implementation is enshrining a
> > global property on a low level primitive that prevents it from being
> > used elsewhere. And I want to replace completion [chains] with fences, and
> > bio with fences, and closures with fences, and what other equivalencies
> > there are in the kernel. The fence is as central a locking construct as
> > struct completion and deserves to be a foundational primitive provided
> > by kernel/ used throughout all drivers for discrete problem domains.
> >
> > This is narrowing dma_fence whereby adding
> >   struct lockdep_map *dma_fence::wait_map
> > and annotating linkage, allows you to continue to specify that all
> > dma_fence used for a particular purpose must follow common rules,
> > without restricting the primitive for uses outside of this scope.
>
> Somewhere else in this thread I had discussions with Jason Gunthorpe about
> this topic. It might maybe change somewhat depending upon exact rules, but
> his take is very much "I don't want dma_fence in rdma". Or pretty close to
> that at least.
>
> Similar discussions with habanalabs, they're using dma_fence internally
> without any of the uapi. Discussion there has also now concluded that it's
> best if they remove them, and simply switch over to a wait_queue or
> completion like every other driver does.
>
> The next round of the patches already have a paragraph to at least
> somewhat limit how non-gpu drivers use dma_fence. And I guess actual
> consensus might be pointing even more strongly at dma_fence being solely
> something for gpus and closely related subsystem (maybe media) for syncing
> dma-buf access.
>
> So dma_fence as general replacement for completion chains I think just
> wont happen.
>
> What might make sense is if e.g. the lockdep annotations could be reused,
> at least in design, for wait_queue or completion or anything else
> really. I do think that has a fair chance compared to the automagic
> cross-release annotations approach, which relied way too heavily on
> guessing where barriers are. My experience from just a bit of playing
> around with these patches here and discussing them with other driver
> maintainers is that accurately deciding where critical sections start and
> end is a job for humans only. And if you get it wrong, you will have a
> false positive.
>
> And you're indeed correct that if we'd do annotations for completions and
> wait queues, then that would need to have a class per semantically
> equivalent user, like we have lockdep classes for mutexes, not just one
> overall.
>
> But dma_fence otoh is something very specific, which comes with very
> specific rules attached - it's not a generic wait_queue at all. Originally
> it did start out as one even, but it is a very specialized wait_queue.
>
> So there's imo two cases:
>
> - Your completion is entirely orthogonal of dma_fences, and can never ever
>   block a dma_fence. Don't use dma_fence for this, and no problem. It's
>   just another wait_queue somewhere.
>
> - Your completion can eventually, maybe through lots of convolutions and
>   depdencies, block a dma_fence. In that case full dma_fence rules apply,
>   and the only thing you can do with a custom annotation is make the rules
>   even stricter. E.g. if a sub-timeline in the scheduler isn't allowed to
>   take certain scheduler locks. But the userspace visible/published fence
>   do take them, maybe as part of command submission or retirement.
>   Entirely hypotethical, no idea any driver actually needs this.

I don't claim to understand the implementation of i915's scheduler and
GEM handling, and it seems like there's some public context missing
here. But to me, the above is a good statement of what I (and a lot of
other userspace) have been relying on - that dma-fence is a very
tightly scoped thing which is very predictable but in extremis.

It would be great to have something like this enshrined in dma-fence
documentation, visible to both kernel and external users. The
properties we've so far been assuming for the graphics pipeline -
covering production & execution of vertex/fragment workloads on the
GPU, framebuffer display, and to the extent this is necessary
involving compute - are something like this:

A single dma-fence with no dependencies represents (the tail of) a
unit of work, which has been all but committed to the hardware. Once
committed to the hardware, this work will complete (successfully or in
error) in bounded time. The unit of work referred to 

Re: [PATCH] drm/aspeed: Call drm_fbdev_generic_setup after drm_dev_register

[Thomas Zimmermann]

Am 09.07.20 um 08:51 schrieb Joel Stanley:
> On Wed, 1 Jul 2020 at 09:10, Sam Ravnborg  wrote:
>>
>> Hi Guenter.
>>
>> On Tue, Jun 30, 2020 at 05:10:02PM -0700, Guenter Roeck wrote:
>>> The following backtrace is seen when running aspeed G5 kernels.
>>>
>>> WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_fb_helper.c:2233 
>>> drm_fbdev_generic_setup+0x138/0x198
>>> aspeed_gfx 1e6e6000.display: Device has not been registered.
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc3 #1
>>> Hardware name: Generic DT based system
>>> Backtrace:
>>> [<8010d6d0>] (dump_backtrace) from [<8010d9b8>] (show_stack+0x20/0x24)
>>> r7:0009 r6:6153 r5: r4:8119fa94
>>> [<8010d998>] (show_stack) from [<80b8cb98>] (dump_stack+0xcc/0xec)
>>> [<80b8cacc>] (dump_stack) from [<80123ef0>] (__warn+0xd8/0xfc)
>>> r7:0009 r6:80e62ed0 r5: r4:974c3ccc
>>> [<80123e18>] (__warn) from [<80123f98>] (warn_slowpath_fmt+0x84/0xc4)
>>> r9:0009 r8:806a0140 r7:08b9 r6:80e62ed0 r5:80e631f8 r4:974c2000
>>> [<80123f18>] (warn_slowpath_fmt) from [<806a0140>] 
>>> (drm_fbdev_generic_setup+0x138/0x198)
>>> r9:0001 r8:9758fc10 r7:9758fc00 r6: r5:0020 r4:9768a000
>>> [<806a0008>] (drm_fbdev_generic_setup) from [<806d4558>] 
>>> (aspeed_gfx_probe+0x204/0x32c)
>>> r7:9758fc00 r6: r5: r4:9768a000
>>> [<806d4354>] (aspeed_gfx_probe) from [<806dfca0>] 
>>> (platform_drv_probe+0x58/0xa8)
>>>
>>> Since commit 1aed9509b29a6 ("drm/fb-helper: Remove return value from
>>> drm_fbdev_generic_setup()"), drm_fbdev_generic_setup() must be called
>>> after drm_dev_register() to avoid the warning. Do that.
>>>
>>> Fixes: 1aed9509b29a6 ("drm/fb-helper: Remove return value from 
>>> drm_fbdev_generic_setup()")
>>> Signed-off-by: Guenter Roeck 
>>
>> I thought we had this fixed already - but could not find the patch.
>> Must have been another driver then.
>>
>> Acked-by: Sam Ravnborg 
>>
>> I assume Joel Stanley will pick up this patch.
> 
> I do not have the drm maintainer tools set up at the moment. Could one
> of the other maintainers put this in the drm-misc tree?

Added to drm-misc-fixes

Best regards
Thomas

> 
> Acked-by: Joel Stanley 
> 
> Cheers,
> 
> Joel
> 
>>
>> Sam
>>
>>> ---
>>>  drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c 
>>> b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
>>> index 6b27242b9ee3..bca3fcff16ec 100644
>>> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
>>> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
>>> @@ -173,8 +173,6 @@ static int aspeed_gfx_load(struct drm_device *drm)
>>>
>>>   drm_mode_config_reset(drm);
>>>
>>> - drm_fbdev_generic_setup(drm, 32);
>>> -
>>>   return 0;
>>>  }
>>>
>>> @@ -225,6 +223,7 @@ static int aspeed_gfx_probe(struct platform_device 
>>> *pdev)
>>>   if (ret)
>>>   goto err_unload;
>>>
>>> + drm_fbdev_generic_setup(&priv->drm, 32);
>>>   return 0;
>>>
>>>  err_unload:
>>> --
>>> 2.17.1
>>>
>>> ___
>>> 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
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

drm: BUG: unable to handle page fault for address: 17ec6000

[Paul Menzel]

Dear Linux folks,


Building Linux v5.8-rc4-25-gbfe91da29bfad with Clang/LLD 
1:11~++20200701093119+ffee8040534-1~exp1 from Debian experimental for 
32-bit (`ARCH=i386`), starting Weston (Wayland) or X.Org Server results 
in non-working screen, and Linux shows the trace below [1].



[  502.044997] BUG: unable to handle page fault for address: 17ec6000
[  502.045650] #PF: supervisor write access in kernel mode
[  502.046301] #PF: error_code(0x0002) - not-present page
[  502.046956] *pde =  
[  502.047612] Oops: 0002 [#1] SMP

[  502.048269] CPU: 0 PID: 2125 Comm: Xorg.wrap Not tainted 
5.8.0-rc4-00105-g4da71f1ee6263 #141
[  502.048967] Hardware name: System manufacturer System Product Name/F2A85-M 
PRO, BIOS 6601 11/25/2014
[  502.049686] EIP: __srcu_read_lock+0x11/0x20
[  502.050413] Code: 83 e0 03 50 56 68 72 c6 99 dd 68 46 c6 99 dd e8 3a c8 fe ff 83 
c4 10 eb ce 0f 1f 44 00 00 55 89 e5 8b 48 68 8b 40 7c 83 e1 01 <64> ff 04 88 f0 
83 44 24 fc 00 89 c8 5d c3 90 0f 1f 44 00 00 55 89
[  502.052027] EAX:  EBX: f36671b8 ECX:  EDX: 0286
[  502.052856] ESI: f3f94eb8 EDI: f3e51c00 EBP: f303dd9c ESP: f303dd9c
[  502.053695] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246
[  502.054543] CR0: 80050033 CR2: 17ec6000 CR3: 2eea2000 CR4: 000406d0
[  502.055402] Call Trace:
[  502.056275]  drm_minor_acquire+0x6f/0x140 [drm]
[  502.057162]  drm_stub_open+0x2e/0x110 [drm]
[  502.058049]  chrdev_open+0xdd/0x1e0
[  502.058937]  do_dentry_open+0x21d/0x330
[  502.059828]  vfs_open+0x23/0x30
[  502.060718]  path_openat+0x947/0xd60
[  502.061610]  ? unlink_anon_vmas+0x53/0x120
[  502.062504]  do_filp_open+0x6d/0x100
[  502.063404]  ? __alloc_fd+0x73/0x140
[  502.064305]  do_sys_openat2+0x1b3/0x2a0
[  502.065217]  __ia32_sys_openat+0x90/0xb0
[  502.066128]  ? prepare_exit_to_usermode+0xa/0x20
[  502.067046]  do_fast_syscall_32+0x68/0xd0
[  502.067970]  do_SYSENTER_32+0x12/0x20
[  502.068902]  entry_SYSENTER_32+0x9f/0xf2
[  502.069839] EIP: 0xb7ef14f9
[  502.070764] Code: Bad RIP value.
[  502.071689] EAX: ffda EBX: ff9c ECX: bfa6a2ac EDX: 8002
[  502.072654] ESI:  EDI: b7ed1000 EBP: bfa6b2c8 ESP: bfa6a1c0
[  502.073630] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS: 0246
[  502.074615] Modules linked in: af_packet k10temp r8169 realtek i2c_piix4 
snd_hda_codec_realtek snd_hda_codec_generic ohci_pci ohci_hcd ehci_pci 
snd_hda_codec_hdmi ehci_hcd radeon i2c_algo_bit snd_hda_intel ttm 
snd_intel_dspcfg snd_hda_codec drm_kms_helper snd_hda_core snd_pcm cfbimgblt 
cfbcopyarea cfbfillrect snd_timer sysimgblt syscopyarea sysfillrect snd 
fb_sys_fops xhci_pci xhci_hcd soundcore acpi_cpufreq drm 
drm_panel_orientation_quirks agpgart ipv6 nf_defrag_ipv6
[  502.077895] CR2: 17ec6000
[  502.079050] ---[ end trace ced4517b63a6db26 ]---
[  502.080214] EIP: __srcu_read_lock+0x11/0x20
[  502.081392] Code: 83 e0 03 50 56 68 72 c6 99 dd 68 46 c6 99 dd e8 3a c8 fe ff 83 
c4 10 eb ce 0f 1f 44 00 00 55 89 e5 8b 48 68 8b 40 7c 83 e1 01 <64> ff 04 88 f0 
83 44 24 fc 00 89 c8 5d c3 90 0f 1f 44 00 00 55 89
[  502.083891] EAX:  EBX: f36671b8 ECX:  EDX: 0286
[  502.085148] ESI: f3f94eb8 EDI: f3e51c00 EBP: f303dd9c ESP: f303dd9c
[  502.086406] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246
[  502.087675] CR0: 80050033 CR2: 17ec6000 CR3: 2eea2000 CR4: 000406d0



$ dmesg | ./scripts/decodecode
[ 55.784870] Code: 83 e0 03 50 56 68 ca c6 99 cf 68 9e c6 99 cf e8 3a c8 fe ff 83 c4 
10 eb ce 0f 1f 44 00 00 55 89 e5 8b 48 68 8b 40 7c 83 e1 01 <64> ff 04 88 f0 83 
44 24 fc 00 89 c8 5d c3 90 0f 1f 44 00 00 55 89
All code

   0:   83 e0 03and$0x3,%eax
   3:   50  push   %eax
   4:   56  push   %esi
   5:   68 ca c6 99 cf  push   $0xcf99c6ca
   a:   68 9e c6 99 cf  push   $0xcf99c69e
   f:   e8 3a c8 fe ff  call   0xfffec84e
  14:   83 c4 10add$0x10,%esp
  17:   eb ce   jmp0xffe7
  19:   0f 1f 44 00 00  nopl   0x0(%eax,%eax,1)
  1e:   55  push   %ebp
  1f:   89 e5   mov%esp,%ebp
  21:   8b 48 68mov0x68(%eax),%ecx
  24:   8b 40 7cmov0x7c(%eax),%eax
  27:   83 e1 01and$0x1,%ecx
  2a:*  64 ff 04 88 incl   %fs:(%eax,%ecx,4)<-- 
trapping instruction
  2e:   f0 83 44 24 fc 00   lock addl $0x0,-0x4(%esp)
  34:   89 c8   mov%ecx,%eax
  36:   5d  pop%ebp
  37:	c3   	ret
  38:	90   	nop

  39:   0f 1f 44 00 00  nopl   0x0(%eax,%eax,1)
  3e:   55  push   %ebp
  3f:   89  .byte 0x89

Code starting with the faulting instruction
===
   0:   64 ff 04 88 incl   %fs:(%eax,%ecx,4)
   4:   f0 83 44 24 fc 00   lock addl $

general protection fault in dma_buf_release

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:9e50b94b Add linux-next specific files for 20200703
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=121cf75510
kernel config:  https://syzkaller.appspot.com/x/.config?x=f99cc0faa1476ed6
dashboard link: https://syzkaller.appspot.com/bug?extid=4342719956b367864c91
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1467c5e310
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=153f228310

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4342719956b367864...@syzkaller.appspotmail.com

RBP: 000103d6 R08: 0001 R09: 004002c8
R10:  R11: 0246 R12: 00402170
R13: 00402200 R14:  R15: 
general protection fault, probably for non-canonical address 
0xdc17:  [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x00b8-0x00bf]
CPU: 1 PID: 6798 Comm: syz-executor223 Not tainted 
5.8.0-rc3-next-20200703-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:dma_buf_release+0x51/0x3f0 drivers/dma-buf/dma-buf.c:63
Code: 03 80 3c 02 00 0f 85 30 03 00 00 48 8b ad e8 00 00 00 48 b8 00 00 00 00 
00 fc ff df 48 8d bd b8 00 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 
3c 03 0f 8e e3 02 00 00 8b 9d b8 00 00 00
RSP: 0018:c90001b87aa0 EFLAGS: 00010206
RAX: dc00 RBX: 847e30a0 RCX: 81c58a83
RDX: 0017 RSI: 847e30b0 RDI: 00b8
RBP:  R08: 0001 R09: 88808a53c80b
R10:  R11:  R12: 88808b7dc550
R13: 88808b7dc4d8 R14: 88808b7dc520 R15: 
FS:  01f09880() GS:8880ae70() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 006cc090 CR3: a87d2000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 __dentry_kill+0x42b/0x640 fs/dcache.c:584
 dentry_kill fs/dcache.c:705 [inline]
 dput+0x725/0xbc0 fs/dcache.c:878
 path_put+0x2d/0x60 fs/namei.c:496
 alloc_file_pseudo+0x20d/0x250 fs/file_table.c:236
 dma_buf_getfile drivers/dma-buf/dma-buf.c:439 [inline]
 dma_buf_export+0x5d8/0xae0 drivers/dma-buf/dma-buf.c:555
 udmabuf_create+0xb9d/0xe30 drivers/dma-buf/udmabuf.c:228
 udmabuf_ioctl_create_list drivers/dma-buf/udmabuf.c:284 [inline]
 udmabuf_ioctl+0x265/0x2c0 drivers/dma-buf/udmabuf.c:299
 vfs_ioctl fs/ioctl.c:48 [inline]
 ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
 __do_sys_ioctl fs/ioctl.c:762 [inline]
 __se_sys_ioctl fs/ioctl.c:760 [inline]
 __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:367
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x441229
Code: Bad RIP value.
RSP: 002b:7ffe24394848 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX:  RCX: 00441229
RDX: 2000 RSI: 40087543 RDI: 0004
RBP: 000103d6 R08: 0001 R09: 004002c8
R10:  R11: 0246 R12: 00402170
R13: 00402200 R14:  R15: 
Modules linked in:
---[ end trace 1a68562902844a66 ]---
RIP: 0010:dma_buf_release+0x51/0x3f0 drivers/dma-buf/dma-buf.c:63
Code: 03 80 3c 02 00 0f 85 30 03 00 00 48 8b ad e8 00 00 00 48 b8 00 00 00 00 
00 fc ff df 48 8d bd b8 00 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 
3c 03 0f 8e e3 02 00 00 8b 9d b8 00 00 00
RSP: 0018:c90001b87aa0 EFLAGS: 00010206
RAX: dc00 RBX: 847e30a0 RCX: 81c58a83
RDX: 0017 RSI: 847e30b0 RDI: 00b8
RBP:  R08: 0001 R09: 88808a53c80b
R10:  R11:  R12: 88808b7dc550
R13: 88808b7dc4d8 R14: 88808b7dc520 R15: 
FS:  01f09880() GS:8880ae70() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 006cc090 CR3: a87d2000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://list

[PATCH v4 56/78] drm/vc4: hdmi: Store the encoder type in the variant structure

[Maxime Ripard]

The vc4 CRTC will use the encoder type to control its output clock
muxing. However, this will be different from HDMI0 to HDMI1, so let's
store our type in the variant structure so that we can support multiple
controllers later on.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
 drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index a50220bfd5dd..c50241170d7e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1268,7 +1268,7 @@ static int vc4_hdmi_bind(struct device *dev, struct 
device *master, void *data)
 
dev_set_drvdata(dev, vc4_hdmi);
encoder = &vc4_hdmi->encoder.base.base;
-   vc4_hdmi->encoder.base.type = VC4_ENCODER_TYPE_HDMI0;
+   vc4_hdmi->encoder.base.type = variant->encoder_type;
vc4_hdmi->pdev = pdev;
vc4_hdmi->variant = variant;
 
@@ -1447,6 +1447,7 @@ static int vc4_hdmi_dev_remove(struct platform_device 
*pdev)
 }
 
 static const struct vc4_hdmi_variant bcm2835_variant = {
+   .encoder_type   = VC4_ENCODER_TYPE_HDMI0,
.registers  = vc4_hdmi_fields,
.num_registers  = ARRAY_SIZE(vc4_hdmi_fields),
 
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 0c32dc46d289..0d529db4b3ab 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -27,6 +27,9 @@ struct vc4_hdmi;
 struct vc4_hdmi_register;
 
 struct vc4_hdmi_variant {
+   /* Encoder Type for that controller */
+   enum vc4_encoder_type encoder_type;
+
/* List of the registers available on that variant */
const struct vc4_hdmi_register *registers;
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel