<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Sascha:<br>
    </p>
    <div class="moz-cite-prefix">On 3/16/22 20:22, Andy Yan wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:f9d57503-1ac6-61c6-5fda-1a78b6e7270a@rock-chips.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>Hi Sascha and Daniel:<br>
      </p>
      <div class="moz-cite-prefix">On 3/16/22 15:40, Sascha Hauer wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:20220316074001.GP405@pengutronix.de">
        <pre class="moz-quote-pre" wrap="">On Tue, Mar 15, 2022 at 02:46:35PM +0800, Andy Yan wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Hi Sascha:

On 3/11/22 16:33, Sascha Hauer wrote:
</pre>
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">From: Andy Yan <a class="moz-txt-link-rfc2396E" href="mailto:andy.yan@rock-chips.com" moz-do-not-send="true"><andy.yan@rock-chips.com></a>

The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
It replaces the VOP unit found in the older Rockchip SoCs.

This driver has been derived from the downstream Rockchip Kernel and
heavily modified:

- All nonstandard DRM properties have been removed
- dropped struct vop2_plane_state and pass around less data between
   functions
- Dropped all DRM_FORMAT_* not known on upstream
- rework register access to get rid of excessively used macros
- Drop all waiting for framesyncs

The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB
board. Overlay support is tested with the modetest utility. AFBC support
on the cluster windows is tested with weston-simple-dmabuf-egl on
weston using the (yet to be upstreamed) panfrost driver support.
</pre>
          </blockquote>
          <pre class="moz-quote-pre" wrap="">Do we need some modification to test AFBC by weston-simple-dma-egl ?
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">By default weston-simple-dma-egl uses DRM_FORMAT_XRGB8888 which in the
panfrost driver ends up as PIPE_FORMAT_B8G8R8_UNORM and
panfrost_afbc_format() returns PIPE_FORMAT_NONE for that. Change the
format to DRM_FORMAT_ABGR8888 using weston-simple-dma-egl -f 0x34324241.
This ends up as PIPE_FORMAT_R8G8B8A8_UNORM in panfrost_afbc_format()
which is a supported format.

</pre>
      </blockquote>
      <p>I also try weston-simple-dmabuf-egl -f 0x34324241 command,</p>
      <p>but I got this output log from weston[0]:</p>
      <div class="de1">Layer 5 (pos 0x50000000): </div>
      <div class="de1"> View 0 (role xdg_toplevel, PID 375, surface ID
        3, top-level window 'simple-dmabuf-egl' of
        org.freedesktop.weston. </div>
      <div class="de1">simple-dmabuf-egl, 0xaaaad08275e0): </div>
      <div class="de1"> position: (871, 174) -> (1127, 430) </div>
      <div class="de1"> [not opaque] </div>
      <div class="de1"> outputs: 0 (HDMI-A-1) (primary) </div>
      <div class="de1"> dmabuf buffer </div>
      <div class="de1"> format: 0x34324241 ABGR8888 </div>
      <div class="de1"> modifier: ARM_BLOCK_SIZE=16x16,MODE=YTR|SPARSE
        (0x800000000000051) </div>
      <div class="de1"> </div>
      <div class="de1">Layer 6 (pos 0x2): </div>
      <div class="de1"> View 0 (role (null), PID 372, surface ID 18,
        background for output HDMI-A-1, 0xaaaad0863520): </div>
      <div class="de1"> position: (0, 0) -> (1920, 1080) </div>
      <div class="de1"> [fully opaque] </div>
      <div class="de1"> outputs: 0 (HDMI-A-1) (primary) </div>
      <div class="de1"> [buffer not available] </div>
      <div class="de1"> </div>
      <div class="de1"> [repaint] preparing state for output HDMI-A-1
        (0) </div>
      <div class="de1"> [repaint] trying planes-only build state </div>
      <div class="de1"> [view] evaluating view 0xaaaad083b0f0 for output
        HDMI-A-1 (0) </div>
      <div class="de1"> [view] not assigning view 0xaaaad083b0f0 to
        plane (no buffer available) </div>
      <div class="de1"> [view] failing state generation: placing view
        0xaaaad083b0f0 to renderer not allowed </div>
      <div class="de1"> [repaint] could not build planes-only state,
        trying mixed </div>
      <div class="de1"> [state] using renderer FB ID 73 for mixed mode
        for output HDMI-A-1 (0) </div>
      <div class="de1"> [state] scanout will use for zpos 0 </div>
      <div class="de1"> [view] evaluating view 0xaaaad083b0f0 for output
        HDMI-A-1 (0) </div>
      <div class="de1"> [view] not assigning view 0xaaaad083b0f0 to
        plane (no buffer available) </div>
      <div class="de1"> [view] view 0xaaaad083b0f0 will be placed on the
        renderer </div>
      <div class="de1"> [view] evaluating view 0xaaaad08275e0 for output
        HDMI-A-1 (0) </div>
      <div class="de1"> [plane] started with zpos 18446744073709551615 </div>
      <div class="de1"> [view] view 0xaaaad08275e0 will be placed on the
        renderer </div>
      <div class="de1"> [view] evaluating view 0xaaaad0863520 for output
        HDMI-A-1 (0) </div>
      <div class="de1"> [view] not assigning view 0xaaaad0863520 to
        plane (no buffer available) </div>
      <div class="de1"> [view] not assigning view 0xaaaad0863520 to
        plane (occluded by renderer views) </div>
      <p> [view] view 0xaaaad0863520 will be placed on the renderer</p>
      <p><br>
      </p>
      <p>From the log we can find that Layer5 view 0(0xaaaad08275e0) is
        the afbc view rendered by Panfrost.</p>
      <p>But it at last put on a render not a afbc window of vop  "view]
        view 0xaaaad083b0f0 will be placed on the renderer "</p>
      <p>The output message from sys/kernel/debug/dri/state can also
        provide that only non-AFBC window smart0-win0 is used.</p>
      <p>It seems that it failed in  weston
        drm_output_prepare_plane_view.</p>
      <p>Maybe I need a deeper dig.<br>
      </p>
    </blockquote>
    <p><br>
    </p>
    <p>After a deeper dig, I found it failed from <br>
    </p>
    <p>drm_fb_get_from_dmabuf {</p>
    <p><br>
    </p>
    <p>.......</p>
    <p>/* XXX: TODO:<br>
               *<br>
               * Currently the buffer is rejected if any dmabuf
      attribute<br>
               * flag is set.  This keeps us from passing an inverted /<br>
               * interlaced / bottom-first buffer (or any other type
      that may<br>
               * be added in the future) through to an overlay. 
      Ultimately,<br>
               * these types of buffers should be handled through buffer<br>
               * transforms and not as spot-checks requiring specific<br>
               * knowledge. */<br>
              if (dmabuf->attributes.flags) {<br>
                      drm_debug(backend, "\t\t\t\t invlid flag 0x%x\n",
      dmabuf->attributes.flags);<br>
                      return NULL;<br>
              }<br>
      <br>
    </p>
    <p>}</p>
    <p>After some grep search, I found the flag is set  at
      create_dmabuf_buffer by weston-simple-dmabuf-egl itself.</p>
    <p>So I run this test with -g: weston-simple-dmabuf-egl -f
      0x34324241 -g</p>
    <p>From the log I can see this view is go to a  overlay plane, but
      it doesn't appear on the screen.</p>
    <p>Cat the dri state, I can see Cluster1-win0 this afbc window is
      enabled.</p>
    <p>So I guess there is something wrong with the vop2 configuration.</p>
    <p>I dump registers of OVERLAY and Cluster1-win0 and
      Smart0-win0(Primary plane)</p>
    <p>I found a obvious  error in 0x604(OVERLAY_LAYER_SEL) register,
      the configuration value</p>
    <p>is 0x54763513.</p>
    <p>I am not sure if you know clearly about this register:</p>
    <p>Every four bits of this register select a
      Window(Cluster0,Cluster1, Esmart0, Esmart1, Smart0. Smart1)</p>
    <p>for layer0 to layer 5 from bottom to top.<br>
    </p>
    <p>0: Cluster0</p>
    <p>1: Cluster1:</p>
    <p>2: Esmart0</p>
    <p>3: Smart0</p>
    <p>6: Esmart1</p>
    <p>7: Smart1</p>
    <p>And one window can only be selected by one layer at a time.</p>
    <p>So when I change this register to 0x54762513, the square draw by
      weston-simple-dmabuf-egl appeared on the top of the weston
      background on screen.</p>
    <p><br>
    </p>
    <p>So Sascha, please check the logic of you map the window and
      layer.<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:f9d57503-1ac6-61c6-5fda-1a78b6e7270a@rock-chips.com">
      <p> </p>
      <p>[0] <a class="moz-txt-link-freetext"
          href="https://pastebin.com/8CfiP7u1" moz-do-not-send="true">https://pastebin.com/8CfiP7u1</a><br>
      </p>
      <blockquote type="cite"
        cite="mid:20220316074001.GP405@pengutronix.de">
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">I have a buildroot system with weston-10.0.9 and mesa 21.3.5.

After launch weston, I run weston-simple-dmabuf-egl, but from the output

of sys/kernel/debug/dri/0/state, the weston is still use Smart0-win0, which
is

a non-AFBC window.

Do i need to modify the vop2 driver to set one Cluster window as primary
plane?
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">I never used a Cluster window as primary plane.

Sascha

</pre>
      </blockquote>
    </blockquote>
  </body>
</html>