Re: [radeon-alex:amd-20.45 1953/2427] drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c:83:5: warning: no previous prototype for function 'dce60_get_dp_ref_freq_khz'

[Mauro Rossi]

Hello,
the mentioned branch requires the following commit, but it is already
applied in 5.10 released kernel,
so I really do not know what next step here.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8c4e4fd607b17973e54a7e9cc4c275b12ab7308e

Mauro

On Tue, Dec 15, 2020 at 11:24 AM kernel test robot  wrote:

> tree:   git://people.freedesktop.org/~agd5f/linux.git amd-20.45
> head:   a3950d94b046fb206e58fd3ec717f071c0203ba3
> commit: e809646e73921328d66a2fbfddf067b9cdb30998 [1953/2427]
> drm/amd/display: enable SI support in the Kconfig (v2)
> config: x86_64-randconfig-a001-20201214 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
> a29ecca7819a6ed4250d3689b12b1f664bb790d7)
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install x86_64 cross compiling tool for clang build
> # apt-get install binutils-x86-64-linux-gnu
> git remote add radeon-alex git://
> people.freedesktop.org/~agd5f/linux.git
> git fetch --no-tags radeon-alex amd-20.45
> git checkout e809646e73921328d66a2fbfddf067b9cdb30998
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross
> ARCH=x86_64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
>
> All warnings (new ones prefixed by >>):
>
> >>
> drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c:83:5:
> warning: no previous prototype for function 'dce60_get_dp_ref_freq_khz'
> [-Wmissing-prototypes]
>int dce60_get_dp_ref_freq_khz(struct clk_mgr *clk_mgr_base)
>^
>
>  drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c:83:1:
> note: declare 'static' if the function is not intended to be used outside
> of this translation unit
>int dce60_get_dp_ref_freq_khz(struct clk_mgr *clk_mgr_base)
>^
>static
>1 warning generated.
>
> vim +/dce60_get_dp_ref_freq_khz +83
> drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dce60/dce60_clk_mgr.c
>
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   82
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11  @83  int
> dce60_get_dp_ref_freq_khz(struct clk_mgr *clk_mgr_base)
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   84  {
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   85 struct clk_mgr_internal
> *clk_mgr = TO_CLK_MGR_INTERNAL(clk_mgr_base);
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   86 int dprefclk_wdivider;
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   87 int dp_ref_clk_khz;
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   88 int target_div;
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   89
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   90 /* DCE6 has no
> DPREFCLK_CNTL to read DP Reference Clock source */
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   91
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   92 /* Read the
> mmDENTIST_DISPCLK_CNTL to get the currently
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   93  * programmed DID
> DENTIST_DPREFCLK_WDIVIDER*/
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   94
>  REG_GET(DENTIST_DISPCLK_CNTL, DENTIST_DPREFCLK_WDIVIDER,
> _wdivider);
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   95
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   96 /* Convert
> DENTIST_DPREFCLK_WDIVIDERto actual divider*/
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   97 target_div =
> dentist_get_divider_from_did(dprefclk_wdivider);
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   98
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11   99 /* Calculate the current
> DFS clock, in kHz.*/
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11  100     dp_ref_clk_khz =
> (DENTIST_DIVIDER_RANGE_SCALE_FACTOR
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11  101     *
> clk_mgr->base.dentist_vco_freq_khz) / target_div;
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11  102
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11  103 return
> dce_adjust_dp_ref_freq_for_ss(clk_mgr, dp_ref_clk_khz);
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11  104  }
> 2428ad5c6ece1a6 Mauro Rossi 2020-07-11  105
>
> :: The code at line 83 was first introduced by commit
> :: 2428ad5c6ece1a6861278c01c5e71c8ea258f3d9 drm/amd/display:
> dc/clk_mgr: add support for SI parts (v2)
>
> :: TO: Mauro Rossi 
> :: CC: Yang Xiong 
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] xf86drm: add drmOpenByFB

[Mauro Rossi]

OpenByFB is introduced to overcome GPU driver loading order issue
on a device with multiple GPUs, e.g. Intel iGPU and Nvidia dGPU
where the first drmfb kernel module loaded will become device file
/dev/dri/card0 and the second will become /dev/dri/card1

The use case is to prefer Intel iGPU over dGPU, or viceversa,
in a deterministic and reliable manner.

OpenByFB function opens the DRM device with specified fb and node type,
thus enabling gralloc to open the correct device node of the primary fb,
regardless of the GPU driver loading order.

Signed-off-by: Chih-Wei Huang 
---
 core-symbols.txt |  1 +
 xf86drm.c| 42 ++
 xf86drm.h|  1 +
 3 files changed, 44 insertions(+)

diff --git a/core-symbols.txt b/core-symbols.txt
index 1ff4ecaa..6bf8c70d 100644
--- a/core-symbols.txt
+++ b/core-symbols.txt
@@ -146,6 +146,7 @@ drmModeSetCursor2
 drmModeSetPlane
 drmMsg
 drmOpen
+drmOpenByFB
 drmOpenControl
 drmOpenOnce
 drmOpenOnceWithType
diff --git a/xf86drm.c b/xf86drm.c
index b49d42f7..229a54bf 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -793,6 +793,48 @@ drm_public int drmOpenRender(int minor)
 return drmOpenMinor(minor, 0, DRM_NODE_RENDER);
 }
 
+/**
+ * Open the DRM device with specified type of specified framebuffer.
+ *
+ * Looks up the associated DRM device with specified type of the
+ * specified framebuffer and opens it.
+ *
+ * \param fb the index of framebuffer.
+ * \param type the device node type to open, PRIMARY, CONTROL or RENDER
+ *
+ * \return a file descriptor on success, or a negative value on error.
+ *
+ */
+drm_public int drmOpenByFB(int fb, int type)
+{
+#ifdef __linux__
+DIR *sysdir;
+struct dirent *ent;
+char buf[64];
+const char *name = drmGetMinorName(type);
+int fd = -1, len = strlen(name);
+
+snprintf(buf, sizeof(buf), "/sys/class/graphics/fb%d/device/drm", fb);
+sysdir = opendir(buf);
+if (!sysdir)
+return -errno;
+
+while ((ent = readdir(sysdir))) {
+if (!strncmp(ent->d_name, name, len)) {
+snprintf(buf, sizeof(buf), "%s/%s", DRM_DIR_NAME, ent->d_name);
+fd = open(buf, O_RDWR | O_CLOEXEC, 0);
+break;
+}
+}
+
+closedir(sysdir);
+return fd;
+#else
+#warning "Missing implementation of drmOpenByFB"
+return -EINVAL;
+#endif
+}
+
 /**
  * Free the version information returned by drmGetVersion().
  *
diff --git a/xf86drm.h b/xf86drm.h
index 7b85079a..d45d696f 100644
--- a/xf86drm.h
+++ b/xf86drm.h
@@ -605,6 +605,7 @@ extern int   drmOpenWithType(const char *name, 
const char *busid,
 
 extern int   drmOpenControl(int minor);
 extern int   drmOpenRender(int minor);
+extern int   drmOpenByFB(int fb, int type);
 extern int   drmClose(int fd);
 extern drmVersionPtr drmGetVersion(int fd);
 extern drmVersionPtr drmGetLibVersion(int fd);
-- 
2.25.1

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

[PATCH] drm/edid: fix building error

[Mauro Rossi]

Fixes the following building error:

CC [M]  drivers/gpu/drm/drm_edid.o
~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c: In function 
'cea_mode_alternate_timings':
~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c:3275:2: error: call to 
'__compiletime_assert_3282'
declared with attribute error: BUILD_BUG_ON failed: cea_mode_for_vic(8)->vtotal 
!= 262 || cea_mode_for_vic(9)->vtotal != 262 || cea_mode_for_vic(12)->vtotal != 
262 || cea_mode_for_vic(13)->vtotal != 262 || cea_mode_for_vic(23)->vtotal != 
312 || cea_mode_for_vic(24)->vtotal != 312 || cea_mode_for_vic(27)->vtotal != 
312 || cea_mode_for_vic(28)->vtotal != 312
make[4]: *** [~/pie-x86_kernel/kernel/scripts/Makefile.build:265: 
drivers/gpu/drm/drm_edid.o] Error 1

Fixes: 7befe62 ("drm/edid: Abstract away cea_edid_modes[]")
Signed-off-by: Mauro Rossi 
---
 drivers/gpu/drm/drm_edid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 99769d6c9f84..805fb004c8eb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3211,7 +3211,7 @@ static u8 *drm_find_cea_extension(const struct edid *edid)
return cea;
 }
 
-static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
+static __always_inline const struct drm_display_mode *cea_mode_for_vic(u8 vic)
 {
BUILD_BUG_ON(1 + ARRAY_SIZE(edid_cea_modes_1) - 1 != 127);
BUILD_BUG_ON(193 + ARRAY_SIZE(edid_cea_modes_193) - 1 != 219);
-- 
2.20.1

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

Re: [PATCH] libdrm: Convert to Android.mk to Android.bp

[Mauro Rossi]

On Wed, Sep 25, 2019 at 6:17 PM John Stultz  wrote:

> On Wed, Sep 25, 2019 at 3:39 AM Eric Engestrom 
> wrote:
> >
> > On Tuesday, 2019-09-24 23:09:08 -0700, John Stultz wrote:
> > > On Tue, Sep 24, 2019 at 4:30 PM John Stultz 
> wrote:
> > > > On Tue, Sep 24, 2019 at 3:24 PM Rob Herring  wrote:
> > > > > Trying to maintain something that works across more than 3
> releases or
> > > > > so is painful. I don't think android-x86 folks have the bandwidth
> to
> > > > > maintain things older than that *and* update to newer versions. So
> I
> > > > > think only supporting the n latest releases is good.
> > > > >
> > > > > Are .bp files for master/Q compatible back to N (or O)? IIRC, at
> least
> > > > > for the first couple of releases with .bp files, they seemed to
> have
> > > > > incompatible changes.
> > > >
> > > > I think there have possibly been some incompatible changes, as I know
> > > > early w/ bp files things were more in flux. That said, there haven't
> > > > been many changes to the libdrm bp files since the conversion was
> > > > first done in 2017 (so Android O). I'll checkout N and validate so I
> > > > can provide a more concrete assurance.
> > >
> > > Ah. Crud. You're right. The bp syntax has shifted enough over time to
> > > cause problems w/ the current file when building against older Android
> > > releases.   N falls over pretty hard, and O and even P have issues w/
> > > "recovery_available: ", and "prebuilt_etc" syntax.  So my proposed
> > > commit message mischaracterizes the state of older builds. Apologies!
> > >
> > > I'll try to reach out to the android devs to see if there's any sort
> > > of compat magic that can be done to keep things working on older
> > > versions. That said, I'm still torn, as without this the current
> > > libdrm/master code is broken with AOSP/master and Q.  Its frustrating
> > > we have to have this seemingly exclusive trade off.
> > >
> > > I'm curious if folks might be willing to consider something like an
> > > upstream branch to preserve the build bits that work with prior
> > > Android releases? Or any other ideas?
> >
> > Is _not_ deleting Android.mk an option?
>
> Yea, the trouble is O and P will pick up the Android.bp files by
> default, so you'd still see the issues or you'd run into duplicate
> targets. I'm hoping I can still find some conditional magic tricks for
> Android.bp.  I need to look at Mauro's patches though.
>
> > That would have the obvious cost of duplicating the build system
> > maintenance effort, but if that's the only way to not drop support for
> > everything before Q...
>
> Yea, I'm not eager to have two android build systems in the tree.
> Having just one is duplicative enough.
>
> > (fwiw, my ack only applies with "reasonable" support of previous
> > versions :] )
>
> Of course, I'm not planning on submitting this change further until I
> can find something better.  Apologies again for my assumptions that it
> would work with older bp implementations.  My only defence is, in
> trying to validate w/ older releases yesterday, my build system pulled
> down 135G of data and now my repo is somehow unshallowed and taking 4
> times the amount of disk space it was using w/ just AOSP/master. :P So
> validating across AOSP versions is no trivial thing.
>
> thanks
> -john
>

For O & P builds if module names collision is avoided,
could Android.bp and Android.mk coexist in the same project?

Could it be possible to use Android.bp for all libdrm targets
but data/Android.bp,
removed and replaced by ./Android.mk with dummy module name and stripped
down to just install /system/vendor/etc/hwdata/amdgpu.ids target ?

If what I'm thinking may work, I could give it a try and report back

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

Re: [PATCH] libdrm: Convert to Android.mk to Android.bp

[Mauro Rossi]

Hello

On Wed, Sep 25, 2019 at 12:39 PM Eric Engestrom 
wrote:

> On Tuesday, 2019-09-24 23:09:08 -0700, John Stultz wrote:
> > On Tue, Sep 24, 2019 at 4:30 PM John Stultz 
> wrote:
> > > On Tue, Sep 24, 2019 at 3:24 PM Rob Herring  wrote:
> > > > Trying to maintain something that works across more than 3 releases
> or
> > > > so is painful. I don't think android-x86 folks have the bandwidth to
> > > > maintain things older than that *and* update to newer versions. So I
> > > > think only supporting the n latest releases is good.
>

N is not a problem, per se, but if there are non supported Blueprint module
types used
it will not be possible to actually replicate Android.mk build rules to
Android.bp and the build will be missing some targets (for example is not
possible to install prebuilt files to $OUT)


> > > >
> > > > Are .bp files for master/Q compatible back to N (or O)? IIRC, at
> least
> > > > for the first couple of releases with .bp files, they seemed to have
> > > > incompatible changes.
> > >
> > > I think there have possibly been some incompatible changes, as I know
> > > early w/ bp files things were more in flux. That said, there haven't
> > > been many changes to the libdrm bp files since the conversion was
> > > first done in 2017 (so Android O). I'll checkout N and validate so I
> > > can provide a more concrete assurance.
> >
> > Ah. Crud. You're right. The bp syntax has shifted enough over time to
> > cause problems w/ the current file when building against older Android
> > releases.   N falls over pretty hard, and O and even P have issues w/
> > "recovery_available: ", and "prebuilt_etc" syntax.  So my proposed
> > commit message mischaracterizes the state of older builds. Apologies!
>

I confirm that when trying drm_hwcomposer master build with oreo-x86
(Android O based)
I had to do manual procedures relying on Android.mk preliminary build +
Android.bp build [1] with some ugly workaround [2]

Procedure:

First build with Android.mk versions on drm_hwcomposer and libdrm
because /system/vendor/etc/hwdata/amdgpu.ids target required prebuild_etc
module type
then I used used Android.bp branches of drm_hwcomposer and libdrm

[1] https://github.com/maurossi/drm/commits/blueprint_oreo-x86 NOTE:
inspired by AOSP fa32e29 "Convert to Android.bp

[2]
https://github.com/maurossi/drm/commit/8727ddbd29e592a54ac234be99f63f262d0ff529


> >
> > I'll try to reach out to the android devs to see if there's any sort
> > of compat magic that can be done to keep things working on older
> > versions. That said, I'm still torn, as without this the current
> > libdrm/master code is broken with AOSP/master and Q.  Its frustrating
> > we have to have this seemingly exclusive trade off.
> >
> > I'm curious if folks might be willing to consider something like an
> > upstream branch to preserve the build bits that work with prior
> > Android releases? Or any other ideas?
>
> Is _not_ deleting Android.mk an option?
>
> That would have the obvious cost of duplicating the build system
> maintenance effort, but if that's the only way to not drop support for
> everything before Q...
>
> (fwiw, my ack only applies with "reasonable" support of previous
> versions :] )
>

Hi Eric,
in my case with both Android.mk and Android.bp the build is failing with
duplicated module name error
Mauro
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] android: libdrm_platform: add liblog shared dependency

[Mauro Rossi]

Here is patch using include 
which should suffice for the purpose.
Cheers

Mauro

On Mon, Apr 22, 2019 at 11:46 AM Mauro Rossi  wrote:
>
> Hi Emil, Chih-Wei,
>
> what about the series of latest three patches we have in oreo-x86 branch?
>
> [oreo-x86 branch]
> http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=history;f=Android.mk;h=f832b24e99007c75ce3a8d9a3ece34d4e475e957;hb=refs/heads/oreo-x86
>
> My doubt is about the one "android: make libdrm*.so available to the
> vendor partition",
> should we keep it (and send to mesa/drm) so that we will simply have
> our x86 branches aligned to mesa/drm,
> or should we skip it in both cases?
>
> Once this is assessed I will either send the series of 3 or just the
> android logging one.
> Mauro
>
> Mauro
>
> On Wed, Apr 17, 2019 at 7:50 PM Emil Velikov  wrote:
> >
> > On Mon, 18 Mar 2019 at 13:32, Tapani Pälli  wrote:
> > > On 3/18/19 3:25 PM, Robert Foss wrote:
> > > > Hey,
> > > >
> > > > On 3/18/19 2:11 PM, Mauro Rossi wrote:
> > > >> Hi,
> > > >>
> > > >> On Mon, Mar 18, 2019 at 10:58 AM Robert Foss
> > > >>  wrote:
> > > >>>
> > > >>> Hey Mauro,
> > > >>>
> > > >>> On 3/18/19 9:38 AM, Mauro Rossi wrote:
> > > >>>> Hi Robert,
> > > >>>>
> > > >>>> On Mon, Mar 18, 2019 at 9:21 AM Robert Foss
> > > >>>>  wrote:
> > > >>>>>
> > > >>>>> On a second note, this does not apply on libdrm/master due
> > > >>>>> to:
> > > >>>>>
> > > >>>>> LOCAL_SHARED_LIBRARIES := \
> > > >>>>>   libcutils
> > > >>>>
> > > >>>> Sorry, we have an additional Google patch, not present in 
> > > >>>> libdrm/master
> > > >>>> that adds libdrm_platform module, but it is for a specific Google
> > > >>>> issue. [1]
> > > >>>>
> > > >>>> However with libdrm module we have both liblog and libcutils shared
> > > >>>> dependencies
> > > >>>>
> > > >>>> [1]
> > > >>>> http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=8ccbfeab9fb2bddf4585339a0bcbea2f1e3ffa1e
> > > >>>>
> > > >>>
> > > >>> Do you know if [1] causes incompatibility issues with earlier android
> > > >>> verions?
> > > >>> If not I would suggest upstreaming it too.
> > > >>
> > > >> I used those patches to build with nougat-x86 and there was no issue.
> > > >>
> > > >> To be precise I did a double rookie mistake, because 
> > > >> __android_log_vprint
> > > >> not used in upstream libdrm and libdrm_platform not used either.
> > > >>
> > > >> Now starting from my mistakes, let's see if there is anything useful
> > > >> to libdrm project
> > > >>
> > > >> In our builds Chih-Wei Huang said that libdrm_platform is not used,
> > > >> meaning not added to packages list,
> > > >> however with oreo-x86 the build error appeared and the liblog 
> > > >> dependency.
> > > >>
> > > >>   __android_log_vprint is used with __ANDROID__ braces
> > > >> in a special patch [2] by Chih-Wei Huang which adds capability to
> > > >> print logs
> > > >> in logcat
> > > >>
> > > >> If it's not too invasive in libdrm, it could be useful.
> > > >> Cheers
> > > >> Mauro
> > > >>
> > > >> [2]
> > > >> http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commitdiff;h=bcee43063ffd52a8677029c9ae6f4203563460f4;hp=81d7264033db4946a3bf1ee82eb6c21260f9
> > > >>
> > > >
> > > > [2] Seems like a good idea to me.
> > > > Logcat really is the only intended path for logging on Android, and
> > > > redirecting our logs there does make sense to me.
> > > >
> > > > But, I'm not sure about I like the way [2] disregards log-levels in
> > > > drmMsg().
> > > >
> > >
> > > Yeah, I think it's a good idea. I see that in mesa we include
> > > "android/log.h", not "log/log.h", will need to make 

Re: [PATCH] android: libdrm_platform: add liblog shared dependency

[Mauro Rossi]

Hi Emil, Chih-Wei,

what about the series of latest three patches we have in oreo-x86 branch?

[oreo-x86 branch]
http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=history;f=Android.mk;h=f832b24e99007c75ce3a8d9a3ece34d4e475e957;hb=refs/heads/oreo-x86

My doubt is about the one "android: make libdrm*.so available to the
vendor partition",
should we keep it (and send to mesa/drm) so that we will simply have
our x86 branches aligned to mesa/drm,
or should we skip it in both cases?

Once this is assessed I will either send the series of 3 or just the
android logging one.
Mauro

Mauro

On Wed, Apr 17, 2019 at 7:50 PM Emil Velikov  wrote:
>
> On Mon, 18 Mar 2019 at 13:32, Tapani Pälli  wrote:
> > On 3/18/19 3:25 PM, Robert Foss wrote:
> > > Hey,
> > >
> > > On 3/18/19 2:11 PM, Mauro Rossi wrote:
> > >> Hi,
> > >>
> > >> On Mon, Mar 18, 2019 at 10:58 AM Robert Foss
> > >>  wrote:
> > >>>
> > >>> Hey Mauro,
> > >>>
> > >>> On 3/18/19 9:38 AM, Mauro Rossi wrote:
> > >>>> Hi Robert,
> > >>>>
> > >>>> On Mon, Mar 18, 2019 at 9:21 AM Robert Foss
> > >>>>  wrote:
> > >>>>>
> > >>>>> On a second note, this does not apply on libdrm/master due
> > >>>>> to:
> > >>>>>
> > >>>>> LOCAL_SHARED_LIBRARIES := \
> > >>>>>   libcutils
> > >>>>
> > >>>> Sorry, we have an additional Google patch, not present in libdrm/master
> > >>>> that adds libdrm_platform module, but it is for a specific Google
> > >>>> issue. [1]
> > >>>>
> > >>>> However with libdrm module we have both liblog and libcutils shared
> > >>>> dependencies
> > >>>>
> > >>>> [1]
> > >>>> http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=8ccbfeab9fb2bddf4585339a0bcbea2f1e3ffa1e
> > >>>>
> > >>>
> > >>> Do you know if [1] causes incompatibility issues with earlier android
> > >>> verions?
> > >>> If not I would suggest upstreaming it too.
> > >>
> > >> I used those patches to build with nougat-x86 and there was no issue.
> > >>
> > >> To be precise I did a double rookie mistake, because __android_log_vprint
> > >> not used in upstream libdrm and libdrm_platform not used either.
> > >>
> > >> Now starting from my mistakes, let's see if there is anything useful
> > >> to libdrm project
> > >>
> > >> In our builds Chih-Wei Huang said that libdrm_platform is not used,
> > >> meaning not added to packages list,
> > >> however with oreo-x86 the build error appeared and the liblog dependency.
> > >>
> > >>   __android_log_vprint is used with __ANDROID__ braces
> > >> in a special patch [2] by Chih-Wei Huang which adds capability to
> > >> print logs
> > >> in logcat
> > >>
> > >> If it's not too invasive in libdrm, it could be useful.
> > >> Cheers
> > >> Mauro
> > >>
> > >> [2]
> > >> http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commitdiff;h=bcee43063ffd52a8677029c9ae6f4203563460f4;hp=81d7264033db4946a3bf1ee82eb6c21260f9
> > >>
> > >
> > > [2] Seems like a good idea to me.
> > > Logcat really is the only intended path for logging on Android, and
> > > redirecting our logs there does make sense to me.
> > >
> > > But, I'm not sure about I like the way [2] disregards log-levels in
> > > drmMsg().
> > >
> >
> > Yeah, I think it's a good idea. I see that in mesa we include
> > "android/log.h", not "log/log.h", will need to make sure we get that
> > correctly, maybe older versions did "log/log.h"?
> >
> I would also be in favour of adding logcat support to libdrm.
>
> Mauro, please respin when you have the time.
>
> Thanks
> Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] android: libdrm_platform: add liblog shared dependency

[Mauro Rossi]

Hi,

I can try replacing  with ,
but I would like to get confirmation from Chih-Wei, the original author of [1]

Mauro

[1] 
http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=9d2a4cc3a16b5b464fda0a0c321dd1f5acadaa33


On Mon, Mar 18, 2019 at 2:32 PM Tapani Pälli  wrote:
>
>
>
> On 3/18/19 3:25 PM, Robert Foss wrote:
> > Hey,
> >
> > On 3/18/19 2:11 PM, Mauro Rossi wrote:
> >> Hi,
> >>
> >> On Mon, Mar 18, 2019 at 10:58 AM Robert Foss
> >>  wrote:
> >>>
> >>> Hey Mauro,
> >>>
> >>> On 3/18/19 9:38 AM, Mauro Rossi wrote:
> >>>> Hi Robert,
> >>>>
> >>>> On Mon, Mar 18, 2019 at 9:21 AM Robert Foss
> >>>>  wrote:
> >>>>>
> >>>>> On a second note, this does not apply on libdrm/master due
> >>>>> to:
> >>>>>
> >>>>> LOCAL_SHARED_LIBRARIES := \
> >>>>>   libcutils
> >>>>
> >>>> Sorry, we have an additional Google patch, not present in libdrm/master
> >>>> that adds libdrm_platform module, but it is for a specific Google
> >>>> issue. [1]
> >>>>
> >>>> However with libdrm module we have both liblog and libcutils shared
> >>>> dependencies
> >>>>
> >>>> [1]
> >>>> http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=8ccbfeab9fb2bddf4585339a0bcbea2f1e3ffa1e
> >>>>
> >>>
> >>> Do you know if [1] causes incompatibility issues with earlier android
> >>> verions?
> >>> If not I would suggest upstreaming it too.
> >>
> >> I used those patches to build with nougat-x86 and there was no issue.
> >>
> >> To be precise I did a double rookie mistake, because __android_log_vprint
> >> not used in upstream libdrm and libdrm_platform not used either.
> >>
> >> Now starting from my mistakes, let's see if there is anything useful
> >> to libdrm project
> >>
> >> In our builds Chih-Wei Huang said that libdrm_platform is not used,
> >> meaning not added to packages list,
> >> however with oreo-x86 the build error appeared and the liblog dependency.
> >>
> >>   __android_log_vprint is used with __ANDROID__ braces
> >> in a special patch [2] by Chih-Wei Huang which adds capability to
> >> print logs
> >> in logcat
> >>
> >> If it's not too invasive in libdrm, it could be useful.
> >> Cheers
> >> Mauro
> >>
> >> [2]
> >> http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commitdiff;h=bcee43063ffd52a8677029c9ae6f4203563460f4;hp=81d7264033db4946a3bf1ee82eb6c21260f9
> >>
> >
> > [2] Seems like a good idea to me.
> > Logcat really is the only intended path for logging on Android, and
> > redirecting our logs there does make sense to me.
> >
> > But, I'm not sure about I like the way [2] disregards log-levels in
> > drmMsg().
> >
>
> Yeah, I think it's a good idea. I see that in mesa we include
> "android/log.h", not "log/log.h", will need to make sure we get that
> correctly, maybe older versions did "log/log.h"?
>
> // Tapani
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] android: libdrm_platform: add liblog shared dependency

[Mauro Rossi]

Hi,

On Mon, Mar 18, 2019 at 10:58 AM Robert Foss  wrote:
>
> Hey Mauro,
>
> On 3/18/19 9:38 AM, Mauro Rossi wrote:
> > Hi Robert,
> >
> > On Mon, Mar 18, 2019 at 9:21 AM Robert Foss  
> > wrote:
> >>
> >> On a second note, this does not apply on libdrm/master due
> >> to:
> >>
> >> LOCAL_SHARED_LIBRARIES := \
> >>  libcutils
> >
> > Sorry, we have an additional Google patch, not present in libdrm/master
> > that adds libdrm_platform module, but it is for a specific Google issue. [1]
> >
> > However with libdrm module we have both liblog and libcutils shared 
> > dependencies
> >
> > [1] 
> > http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=8ccbfeab9fb2bddf4585339a0bcbea2f1e3ffa1e
>
> Do you know if [1] causes incompatibility issues with earlier android verions?
> If not I would suggest upstreaming it too.

I used those patches to build with nougat-x86 and there was no issue.

To be precise I did a double rookie mistake, because __android_log_vprint
not used in upstream libdrm and libdrm_platform not used either.

Now starting from my mistakes, let's see if there is anything useful
to libdrm project

In our builds Chih-Wei Huang said that libdrm_platform is not used,
meaning not added to packages list,
however with oreo-x86 the build error appeared and the liblog dependency.

 __android_log_vprint is used with __ANDROID__ braces
in a special patch [2] by Chih-Wei Huang which adds capability to print logs
in logcat

If it's not too invasive in libdrm, it could be useful.
Cheers
Mauro

[2] 
http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commitdiff;h=bcee43063ffd52a8677029c9ae6f4203563460f4;hp=81d7264033db4946a3bf1ee82eb6c21260f9

>
> >
> > Mauro
> >
> >>
> >> My thinking is that libcutils probably can be replaced with liblog,
> >> but I'm not 100% sure.
> >>
> >>
> >> Rob.
> >>
> >> On 3/18/19 9:09 AM, Robert Foss wrote:
> >>> This is probably a good idea!
> >>>
> >>>
> >>> Reviewed-by: Robert Foss 
> >>>
> >>> On 3/17/19 9:54 PM, Mauro Rossi wrote:
> >>>> Hi,
> >>>> I used the option --subject-prefix="PATCH libdrm"
> >>>> but it did not go as expected.
> >>>>
> >>>> Anyway, the patch is for Android build of mesa/drm
> >>>> Mauro
> >>>>
> >>>> On Sun, Mar 17, 2019 at 9:50 PM Mauro Rossi  
> >>>> wrote:
> >>>>>
> >>>>> Fixes the following building error:
> >>>>>
> >>>>> FAILED:
> >>>>> $(OUT)/obj/SHARED_LIBRARIES/libdrm_platform_intermediates/LINKED/libdrm_platform.so
> >>>>>
> >>>>> ...
> >>>>> external/libdrm/xf86drm.c:146: error: undefined reference to
> >>>>> '__android_log_vprint'
> >>>>> clang.real: error: linker command failed with exit code 1 (use -v to see
> >>>>> invocation)
> >>>>>
> >>>>> Signed-off-by: Mauro Rossi 
> >>>>> ---
> >>>>>Android.mk | 3 +++
> >>>>>1 file changed, 3 insertions(+)
> >>>>>
> >>>>> diff --git a/Android.mk b/Android.mk
> >>>>> index f2c78bc1..f832b24e 100644
> >>>>> --- a/Android.mk
> >>>>> +++ b/Android.mk
> >>>>> @@ -61,6 +61,9 @@ LOCAL_EXPORT_C_INCLUDE_DIRS := \
> >>>>>   $(LOCAL_PATH) \
> >>>>>   $(LOCAL_PATH)/include/drm
> >>>>>
> >>>>> +LOCAL_SHARED_LIBRARIES := \
> >>>>> +   liblog
> >>>>> +
> >>>>>LOCAL_C_INCLUDES := \
> >>>>>   $(LOCAL_PATH)/include/drm
> >>>>>
> >>>>> --
> >>>>> 2.19.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
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] android: libdrm_platform: add liblog shared dependency

[Mauro Rossi]

Hi Robert,

On Mon, Mar 18, 2019 at 9:21 AM Robert Foss  wrote:
>
> On a second note, this does not apply on libdrm/master due
> to:
>
> LOCAL_SHARED_LIBRARIES := \
> libcutils

Sorry, we have an additional Google patch, not present in libdrm/master
that adds libdrm_platform module, but it is for a specific Google issue. [1]

However with libdrm module we have both liblog and libcutils shared dependencies

[1] 
http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=8ccbfeab9fb2bddf4585339a0bcbea2f1e3ffa1e

Mauro

>
> My thinking is that libcutils probably can be replaced with liblog,
> but I'm not 100% sure.
>
>
> Rob.
>
> On 3/18/19 9:09 AM, Robert Foss wrote:
> > This is probably a good idea!
> >
> >
> > Reviewed-by: Robert Foss 
> >
> > On 3/17/19 9:54 PM, Mauro Rossi wrote:
> >> Hi,
> >> I used the option --subject-prefix="PATCH libdrm"
> >> but it did not go as expected.
> >>
> >> Anyway, the patch is for Android build of mesa/drm
> >> Mauro
> >>
> >> On Sun, Mar 17, 2019 at 9:50 PM Mauro Rossi  wrote:
> >>>
> >>> Fixes the following building error:
> >>>
> >>> FAILED:
> >>> $(OUT)/obj/SHARED_LIBRARIES/libdrm_platform_intermediates/LINKED/libdrm_platform.so
> >>>
> >>> ...
> >>> external/libdrm/xf86drm.c:146: error: undefined reference to
> >>> '__android_log_vprint'
> >>> clang.real: error: linker command failed with exit code 1 (use -v to see
> >>> invocation)
> >>>
> >>> Signed-off-by: Mauro Rossi 
> >>> ---
> >>>   Android.mk | 3 +++
> >>>   1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/Android.mk b/Android.mk
> >>> index f2c78bc1..f832b24e 100644
> >>> --- a/Android.mk
> >>> +++ b/Android.mk
> >>> @@ -61,6 +61,9 @@ LOCAL_EXPORT_C_INCLUDE_DIRS := \
> >>>  $(LOCAL_PATH) \
> >>>  $(LOCAL_PATH)/include/drm
> >>>
> >>> +LOCAL_SHARED_LIBRARIES := \
> >>> +   liblog
> >>> +
> >>>   LOCAL_C_INCLUDES := \
> >>>  $(LOCAL_PATH)/include/drm
> >>>
> >>> --
> >>> 2.19.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

Re: [PATCH] android: libdrm_platform: add liblog shared dependency

[Mauro Rossi]

Hi,
I used the option --subject-prefix="PATCH libdrm"
but it did not go as expected.

Anyway, the patch is for Android build of mesa/drm
Mauro

On Sun, Mar 17, 2019 at 9:50 PM Mauro Rossi  wrote:
>
> Fixes the following building error:
>
> FAILED: 
> $(OUT)/obj/SHARED_LIBRARIES/libdrm_platform_intermediates/LINKED/libdrm_platform.so
> ...
> external/libdrm/xf86drm.c:146: error: undefined reference to 
> '__android_log_vprint'
> clang.real: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
> Signed-off-by: Mauro Rossi 
> ---
>  Android.mk | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Android.mk b/Android.mk
> index f2c78bc1..f832b24e 100644
> --- a/Android.mk
> +++ b/Android.mk
> @@ -61,6 +61,9 @@ LOCAL_EXPORT_C_INCLUDE_DIRS := \
> $(LOCAL_PATH) \
> $(LOCAL_PATH)/include/drm
>
> +LOCAL_SHARED_LIBRARIES := \
> +   liblog
> +
>  LOCAL_C_INCLUDES := \
> $(LOCAL_PATH)/include/drm
>
> --
> 2.19.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] android: libdrm_platform: add liblog shared dependency

[Mauro Rossi]

Fixes the following building error:

FAILED: 
$(OUT)/obj/SHARED_LIBRARIES/libdrm_platform_intermediates/LINKED/libdrm_platform.so
...
external/libdrm/xf86drm.c:146: error: undefined reference to 
'__android_log_vprint'
clang.real: error: linker command failed with exit code 1 (use -v to see 
invocation)

Signed-off-by: Mauro Rossi 
---
 Android.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Android.mk b/Android.mk
index f2c78bc1..f832b24e 100644
--- a/Android.mk
+++ b/Android.mk
@@ -61,6 +61,9 @@ LOCAL_EXPORT_C_INCLUDE_DIRS := \
$(LOCAL_PATH) \
$(LOCAL_PATH)/include/drm
 
+LOCAL_SHARED_LIBRARIES := \
+   liblog
+
 LOCAL_C_INCLUDES := \
$(LOCAL_PATH)/include/drm
 
-- 
2.19.1

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

Re: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Mauro Rossi]

Hi all,

I just wanted to share that I'm conducting "newbie" tests on oreo-x86 with
drm_hwcomposer, gbm_gralloc and libdrm with latest gralloc_handle.h

and the results are good on nouveau, provided that some changes in
drmresources are applied to avoid throwing errors for non connected
connectors,

i965 completes bootanimation, but surfaceflinger is killed when trying to
draw status bar and menu bar (annoying but true)

amdgpu (bonaire which supports atomic drm) is affected by problems in
setting the correct mode on display (only txt cursor is shown) and there
are SIGSEGV MAPERR at libskia trying to draw pixels.

There are also errors logged by drm_hwcomposer code, which I'm not much
able to interpret/analyze correctly.

I would like to open issues on drm_hwcomposer with the details and logs
when I encounter them, may I use gitlab or bugzilla for these
drm_hwcomposer specific issues?

Thanks for instructions

Another question is for Intel and Chromeos developers: are you planning to
update your minigbm projects to the new common gralloc_handle.h handle
structure in latest libdrm?

I'm asking because freedesktop drm_hwcomposer (hwctwo) moved to new libdrm
gralloc_handle.h handle
and it would make sense for minigbm to evolve accordingly,

and I'd like to try them in oreo-x86 as a like-for-like replacement option
for gbm_gralloc

Thank for any info

Mauro Rossi

Il 04 mag 2018 14:48, "Robert Foss" <robert.f...@collabora.com> ha scritto:

Heya,


On 2018-05-04 12:51, Daniel Stone wrote:
> Hi,
>
> On 3 May 2018 at 20:12, Sean Paul <seanp...@chromium.org> wrote:
>> On Thu, May 03, 2018 at 08:30:18PM +0200, Daniel Vetter wrote:
>>> On Thu, May 3, 2018 at 5:04 PM, Sean Paul <seanp...@chromium.org> wrote:
>>>> If you're still reading, I'll point out a couple other things:
>>>> - There is a bug tracker on the gitlab instance, feel free to add
>>>>bugs/features/etc to it.
>>>> - I've added a TODO list to the wiki, but in typing this, realized
it's probably
>>>>better to file bugs for each item. So please ignore the TODO wiki
entry.
>>>
>>> Any plans to wire up autobuilder or maybe even functional CI to the
>>> gitlab instance? That's where stuff gets really cool (and I think a
>>> lot of people will see the value of abandoning dri-devel much more,
>>> beyond the better S/N ratio).
>>
>> Not as far as I know. A fun afternoon project might be to hook up
clang-format
>> verification as a merge request hook. Aside from that, I think proper
(or even
>> improper/simple) CI would require more effort than we have resources.
>
> That should be pretty easy as a .gitlab-ci.yml. I'm working on getting
> support for qemu into the existing runner that we have, so it would be
> entirely possible to run a drm-hwc on a 'real' kernel, if you have
> something you can test under qemu.

I'm currently working on getting something like this up and running for
normal feature development on my local machine.

That being said AOSP is a fast moving target. So we would have to pin the
AOSP version and maybe bump it every year or so. I guess that goes for
the kernel,mesa & libdrm as well.


Rob.


>
> For on-hardware testing (e.g. run it on freedreno + vc4 + ...), that's
> a whole other topic that we don't currently cover.
>
> Cheers,
> Daniel
> ___
> 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: [drm_hwc] PSA: drm_hwc submissions via gitlab

[Mauro Rossi]

Il 04 mag 2018 19:51, "Alistair Strachan" <astrac...@google.com> ha scritto:

On Fri, May 4, 2018 at 10:35 AM Sean Paul <seanp...@chromium.org> wrote:

> On Fri, May 04, 2018 at 05:19:50PM +, Mauro Rossi wrote:

[snip]

> > Another question is for Intel and Chromeos developers: are you planning
> to
>
> update your minigbm projects to the new common gralloc_handle.h handle
> > structure in latest libdrm?
> >
>
> I assume yes, but I'm not hooked in to what's happening with minigbm.
>

+1. We can take this to another thread. The main issue is that minigbm
assumes a 1:1 planes to handles paradigm, the new generic handle does not.


Thanks for the info

This allows testing an hwcomposer.minigbm (by just changing some makefile
rules and build as separate project) separately from hwcomposer.drm
In order to select hwcomposer.drm+gralloc.gbm vs
hwcomposer.minigbm+gralloc.minigbm I use init.sh and a boot cmdline
parameter.

When testing drm_hwcomposer+ (chromeos minigbm or intel minigbm) two week
ago I was getting SIGABRT no suitable EGL config.

I will repeat tests with cros/gralloc_drm_handle.h handle now supported via
platformminigbm on amdgpu (requires patch on minigbm), i965 and nouveau.

Mauro

Mauro


> I'm asking because freedesktop drm_hwcomposer (hwctwo) moved to new libdrm
> > gralloc_handle.h handle
> > and it would make sense for minigbm to evolve accordingly,
> >
> > and I'd like to try them in oreo-x86 as a like-for-like replacement
> option
> > for gbm_gralloc
>
> Did you see the latest patches from Alistair Strachan to add minigbm as a
> supported platform? That might do what you want.
>

Thanks, they will suffice for now,  however minigbm was now put in
diverging track from common libdrm gralloc handle.


If we move to the common handle, my changes can be dropped. That's the
goal, it's just not possible right now.


Were those the only specificity introduced in hwc?

Is there documentation on the differences in composition of planes among
driver platforms?

Why is amdgpu the only platform (among the ones supporting atomic) for
which drm mode setting is not working with hwc, is there some difference in
amdgpu drm implementation? [Just a hint, I'll open bug on gitlab]

I'll keep an eye on AOSP minigbm, cros minigbm and intel minigbm to see
if/when they'll be updated to use new gralloc handle.

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

Re: [drm_hwcomposer] [PATCH] Take Connection state into account. (v2)

[Mauro Rossi]

Il 08/gen/2018 09:46 PM, "Sean Paul" <seanp...@chromium.org> ha scritto:

On Mon, Jan 08, 2018 at 03:41:49PM -0500, Sean Paul wrote:
> On Sat, Jan 06, 2018 at 12:59:58AM +0100, Mauro Rossi wrote:
> > Porting of original commit 76fb87e675 of Jim Bish in android-ia master
to fdo
> >
> > Original commit message:
> > "There are various places where we should be really taking connection
> > state into account before querying the properties or assuming it
> > as primary. This patch fixes them."
> >
> > (v2) checks on connection state are applied for both internal and
external
> > connectors, in order to select the correct primary, as opposed to
setting,
> > independently from its state, the first connector as primary
> >
> > This is essential to avoid following logcat errors on integrated and
dedicated GPUs:
> >
> > ... 2245  2245 E hwc-drm-resources: Could not find a suitable
encoder/crtc for display 2
> > ... 2245  2245 E hwc-drm-resources: Failed CreateDisplayPipe 56 with -19
> > ... 2245  2245 E hwcomposer-drm: Can't initialize Drm object -19
> >
> > Tested with i965 on Sandybridge and nouveau on GT120, GT610
> > ---
> >  drmresources.cpp | 9 +++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drmresources.cpp b/drmresources.cpp
> > index 32dd376..d582cfe 100644
> > --- a/drmresources.cpp
> > +++ b/drmresources.cpp
> > @@ -159,7 +159,7 @@ int DrmResources::Init() {
> >
> >// First look for primary amongst internal connectors
> >for (auto  : connectors_) {
> > -if (conn->internal() && !found_primary) {
> > +if (conn->state() == DRM_MODE_CONNECTED && conn->internal() &&
!found_primary) {

One more thing. How do you know this is the right thing to do? What if the
internal panel is not connected initially, but becomes connected in the
future?
IIUC, you'll end up numbering it incorrectly.

Sean


Unfortunately I don't have knowledge/experience about the drm mode code,
but analyzing logs in nouveau with dedicated GPU shows a problem in current
code.

You are asking if taking connection state into account will work in dynamic
scenario of plugging/unplugging cable/conn,
but let's start from acknowledging that current code results in 'no screen
output', because it bails out too soon, and taking connection state into
account allows to boot with nouveau, which is the goal of having moved
drm_hwcomposer to fd.o

IMHO to bo able to boot Android drm_hwcomposer+gbm_gralloc with nouveau is
a substantial improvement



> >conn->set_display(0);
> >found_primary = true;
> >  } else {
> > @@ -170,7 +170,7 @@ int DrmResources::Init() {
> >
> >// Then look for primary amongst external connectors
> >for (auto  : connectors_) {
> > -if (conn->external() && !found_primary) {
> > +if (conn->state() == DRM_MODE_CONNECTED && conn->external() &&
!found_primary) {
>
> These 2 lines exceed the max character limit. Did you run clang-format?
>
> Anyways, I think it'd be nice to add a connected() helper to the connector
> object which would look cleaner and solve the long lines.
>
> Sean


Thanks for feedback, we will have a look with Robert to improve coding style

>
> >conn->set_display(0);
> >found_primary = true;
> >  }
> > @@ -288,6 +288,11 @@ int DrmResources::TryEncoderForDisplay(int
display, DrmEncoder *enc) {
> >
> >  int DrmResources::CreateDisplayPipe(DrmConnector *connector) {
> >int display = connector->display();
> > +
> > +  // skip not connected
> > +  if (connector->state() == DRM_MODE_DISCONNECTED)
> > +return 0;
> > +
> >/* Try to use current setup first */
> >if (connector->encoder()) {
> >  int ret = TryEncoderForDisplay(display, connector->encoder());
> > --
> > 2.14.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS

--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm_hwcomposer] [PATCH] Take Connection state into account. (v2)

[Mauro Rossi]

Porting of original commit 76fb87e675 of Jim Bish in android-ia master to fdo

Original commit message:
"There are various places where we should be really taking connection
state into account before querying the properties or assuming it
as primary. This patch fixes them."

(v2) checks on connection state are applied for both internal and external
connectors, in order to select the correct primary, as opposed to setting,
independently from its state, the first connector as primary

This is essential to avoid following logcat errors on integrated and dedicated 
GPUs:

... 2245  2245 E hwc-drm-resources: Could not find a suitable encoder/crtc for 
display 2
... 2245  2245 E hwc-drm-resources: Failed CreateDisplayPipe 56 with -19
... 2245  2245 E hwcomposer-drm: Can't initialize Drm object -19

Tested with i965 on Sandybridge and nouveau on GT120, GT610
---
 drmresources.cpp | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drmresources.cpp b/drmresources.cpp
index 32dd376..d582cfe 100644
--- a/drmresources.cpp
+++ b/drmresources.cpp
@@ -159,7 +159,7 @@ int DrmResources::Init() {
 
   // First look for primary amongst internal connectors
   for (auto  : connectors_) {
-if (conn->internal() && !found_primary) {
+if (conn->state() == DRM_MODE_CONNECTED && conn->internal() && 
!found_primary) {
   conn->set_display(0);
   found_primary = true;
 } else {
@@ -170,7 +170,7 @@ int DrmResources::Init() {
 
   // Then look for primary amongst external connectors
   for (auto  : connectors_) {
-if (conn->external() && !found_primary) {
+if (conn->state() == DRM_MODE_CONNECTED && conn->external() && 
!found_primary) {
   conn->set_display(0);
   found_primary = true;
 }
@@ -288,6 +288,11 @@ int DrmResources::TryEncoderForDisplay(int display, 
DrmEncoder *enc) {
 
 int DrmResources::CreateDisplayPipe(DrmConnector *connector) {
   int display = connector->display();
+
+  // skip not connected
+  if (connector->state() == DRM_MODE_DISCONNECTED)
+return 0;
+
   /* Try to use current setup first */
   if (connector->encoder()) {
 int ret = TryEncoderForDisplay(display, connector->encoder());
-- 
2.14.1

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

[drm_hwcomposer] [PATCH] Update external connectors list

[Mauro Rossi]

DVID, DVII and VGA are required by discrete and integrated GPUs
---
 drmconnector.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drmconnector.cpp b/drmconnector.cpp
index 247f56b..145518f 100644
--- a/drmconnector.cpp
+++ b/drmconnector.cpp
@@ -73,7 +73,9 @@ bool DrmConnector::internal() const {
 }
 
 bool DrmConnector::external() const {
-  return type_ == DRM_MODE_CONNECTOR_HDMIA;
+  return type_ == DRM_MODE_CONNECTOR_HDMIA || type_ == 
DRM_MODE_CONNECTOR_DisplayPort ||
+ type_ == DRM_MODE_CONNECTOR_DVID || type_ == DRM_MODE_CONNECTOR_DVII 
||
+ type_ == DRM_MODE_CONNECTOR_VGA;
 }
 
 bool DrmConnector::valid_type() const {
-- 
2.14.1

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

Re: [drm_hwcomposer PATCH] Take Connection state into account. (v2)

[Mauro Rossi]

2018-01-03 12:16 GMT+01:00 Robert Foss <robert.f...@collabora.com>:

> Hey Mauro,
>
> Thanks for the patch! It builds and looks good to me, but I have some
> suggestions however.
>
>
> On Wed, 2018-01-03 at 11:10 +0100, Mauro Rossi wrote:
> > These changes avoid following logcat error on integrated and
> > dedicated GPUs:
> >
> > ... 2245  2245 E hwc-drm-resources: Could not find a suitable
> > encoder/crtc for display 2
> > ... 2245  2245 E hwc-drm-resources: Failed CreateDisplayPipe 56 with
> > -19
> > ... 2245  2245 E hwcomposer-drm: Can't initialize Drm object -19
>
> It isn't quite clear clear which errors belong to which changes,
> to make this patch a bit more bisectable it would be nice to see
> independent commits created for each error.
>

Hi Robert,

In this case I honestly do not think that splitting would add too much
value,
original commit (v1) is  well documented in [1] and tackles with bug in
drmresources.cpp
which currently fails to find workable crtc -> encoder -> display output
combination
for integrated and dedicated GPUs. Besides that it was also adding
DisplayPort drm mode connector type

So changes in drmresources.cpp belong to solving "Could not find a suitable
encoder/crtc for display X" problem,
which is a show stopper for enabling mainline graphics in android-x86

Other developers observed independently that the current implementation is
"embedded oriented" and only checks the first display output,
isn't it?

The only change I did in drmconnector.cpp is to account for the additional
external drm mode connectors types
which were missing (DVID, DVII, VGA) . One question on my side: Do we need
more?

Besides these minor types lists discussions, I would propose you to check
with Jim Bish if he should have the credit for the patch
and review the coding of his changes.



> >
> > (v1) There are various places where we should be really taking
> > connection
> > state into account before querying the properties or assuming it
> > as primary. This patch fixes them.
> >
> > BUG=None.
> > TEST=System boots up and shows UI.
> >
> > (v1) Signed-off-by: Jim Bish <jim.b...@intel.com>
> >
> > (v2) porting of original commit 76fb87e675 of android-ia master
> > with additional external connector types (DisplayPort, DVID, DVII,
> > VGA)
> > Tested with i965 on Sandybridge and nouveau on GT120, GT610
>
> The commit message isn't really following the usual format. It doesn't
> need to include a changelog (that is typically placed between the "---"
> markers in the email instead),
> and it is missing a signoff from the submitter (you).
>

Sorry I don't have a signature, as usually my patches need sign-off from
professionals,
I'm a (crash test dummy) hobbyist..really :-)

Maybe Rob Herring, Qiang Yu  or Chih-Wei could review and sign-off the
proposed patch



> The BUG and TEST fields are not strictly required either, but aren't a
> problem.
>

That part is the original Jim Bish commit message [1], my changes version
is (v2)
Sorry if I was not clear enought


>
> > ---
> >  drmconnector.cpp | 4 +++-
> >  drmresources.cpp | 9 +++--
> >  2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drmconnector.cpp b/drmconnector.cpp
> > index 247f56b..145518f 100644
> > --- a/drmconnector.cpp
> > +++ b/drmconnector.cpp
> > @@ -73,7 +73,9 @@ bool DrmConnector::internal() const {
> >  }
> >
> >  bool DrmConnector::external() const {
> > -  return type_ == DRM_MODE_CONNECTOR_HDMIA;
> > +  return type_ == DRM_MODE_CONNECTOR_HDMIA || type_ ==
> > DRM_MODE_CONNECTOR_DisplayPort ||
> > + type_ == DRM_MODE_CONNECTOR_DVID || type_ ==
> > DRM_MODE_CONNECTOR_DVII ||
> > + type_ == DRM_MODE_CONNECTOR_VGA;
> >  }
>
> The changes to external() should probably be broken out into it's own
> commit, since external() is called elsewhere changes to it _could_
> introduce issues.
>

Will you check the code, involving Jim Bish if necessary, about these
potential issues?
I am available to perform changes/tests, but the original maker will be
better.
Cheers

Mauro


> >
> >  bool DrmConnector::valid_type() const {
> > diff --git a/drmresources.cpp b/drmresources.cpp
> > index 32dd376..d582cfe 100644
> > --- a/drmresources.cpp
> > +++ b/drmresources.cpp
> > @@ -159,7 +159,7 @@ int DrmResources::Init() {
> >
> >// First look for primary amongst internal connectors
> >for (auto  : connectors_) {
> > -if (conn->internal() && !found_primary) {
> > +if (conn->state() == DRM_MODE_CONNECTED && conn

[drm_hwcomposer PATCH] Take Connection state into account. (v2)

[Mauro Rossi]

These changes avoid following logcat error on integrated and dedicated GPUs: 

... 2245  2245 E hwc-drm-resources: Could not find a suitable encoder/crtc for 
display 2
... 2245  2245 E hwc-drm-resources: Failed CreateDisplayPipe 56 with -19
... 2245  2245 E hwcomposer-drm: Can't initialize Drm object -19

(v1) There are various places where we should be really taking connection
state into account before querying the properties or assuming it
as primary. This patch fixes them.

BUG=None.
TEST=System boots up and shows UI.

(v1) Signed-off-by: Jim Bish 

(v2) porting of original commit 76fb87e675 of android-ia master
with additional external connector types (DisplayPort, DVID, DVII, VGA)
Tested with i965 on Sandybridge and nouveau on GT120, GT610
---
 drmconnector.cpp | 4 +++-
 drmresources.cpp | 9 +++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drmconnector.cpp b/drmconnector.cpp
index 247f56b..145518f 100644
--- a/drmconnector.cpp
+++ b/drmconnector.cpp
@@ -73,7 +73,9 @@ bool DrmConnector::internal() const {
 }
 
 bool DrmConnector::external() const {
-  return type_ == DRM_MODE_CONNECTOR_HDMIA;
+  return type_ == DRM_MODE_CONNECTOR_HDMIA || type_ == 
DRM_MODE_CONNECTOR_DisplayPort ||
+ type_ == DRM_MODE_CONNECTOR_DVID || type_ == DRM_MODE_CONNECTOR_DVII 
||
+ type_ == DRM_MODE_CONNECTOR_VGA;
 }
 
 bool DrmConnector::valid_type() const {
diff --git a/drmresources.cpp b/drmresources.cpp
index 32dd376..d582cfe 100644
--- a/drmresources.cpp
+++ b/drmresources.cpp
@@ -159,7 +159,7 @@ int DrmResources::Init() {
 
   // First look for primary amongst internal connectors
   for (auto  : connectors_) {
-if (conn->internal() && !found_primary) {
+if (conn->state() == DRM_MODE_CONNECTED && conn->internal() && 
!found_primary) {
   conn->set_display(0);
   found_primary = true;
 } else {
@@ -170,7 +170,7 @@ int DrmResources::Init() {
 
   // Then look for primary amongst external connectors
   for (auto  : connectors_) {
-if (conn->external() && !found_primary) {
+if (conn->state() == DRM_MODE_CONNECTED && conn->external() && 
!found_primary) {
   conn->set_display(0);
   found_primary = true;
 }
@@ -288,6 +288,11 @@ int DrmResources::TryEncoderForDisplay(int display, 
DrmEncoder *enc) {
 
 int DrmResources::CreateDisplayPipe(DrmConnector *connector) {
   int display = connector->display();
+
+  // skip not connected
+  if (connector->state() == DRM_MODE_DISCONNECTED)
+return 0;
+
   /* Try to use current setup first */
   if (connector->encoder()) {
 int ret = TryEncoderForDisplay(display, connector->encoder());
-- 
2.14.1

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

Re: [PATCH] android: amdgpu: move asic id table to a separate file

[Mauro Rossi]

2017-07-27 10:30 GMT+02:00 Chih-Wei Huang <cwhu...@android-x86.org>:
>> 2017-07-26 17:27 GMT+02:00 Emil Velikov <emil.l.veli...@gmail.com>:
>>> On 25 July 2017 at 08:28, Chih-Wei Huang <cwhu...@android-x86.org> wrote:
>>>> Hi Mauro,
>>>> Please note AMDGPU_ASIC_ID_TABLE
>>>> should be a path in the target device (i.e., Android).
>>>> So using $(LIBDRM_TOP) is incorrect.
>>>>
>>>> Actually I've sent a fix for it about one week ago.
>>>>
>>> Did you sent v2 of the patch? I cannot see any in my inbox.
>
> OK. I re-submitted v2 patch to replace
> /etc with /system/etc.
>
> 2017-07-27 1:36 GMT+08:00 Mauro Rossi <issor.or...@gmail.com>:
>> This one has conceptual error and is to be dropped.
>>
>> The ones submitted by Chih-Wei are here:
>>
>> https://github.com/maurossi/drm/commits/2.4.82_android-x86
>>
>> where in the (v2) of the second I just replaced /etc path with 
>> $(TARGET_OUT_ETC)
>
> No. TARGET_OUT_ETC is still the host path.
> (which is out/target/product/$target/system/etc )

I had this kind of doubt,
I think there is a precedent we can use to support original 2of2 patch (v1)

https://github.com/robherring/libpciaccess/blob/master/Android.mk

where /etc/hwdata was the folder used at runtime for pci.ids

So original 2of2 patch is signed-off by Chih-Wei and me.

Mauro

>
>> Chih-Wei if you like the (v2) could you please resubmit to dri-devel
>> using [PATCH libdrm] in the title?
>
> --
> Chih-Wei
> Android-x86 project
> http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] android: amdgpu: move asic id table to a separate file

[Mauro Rossi]

Hi,

after git-send I noticed that libdrm patches in drii-devel are
prefixed by [ PATCH libdrm ]

Please consider that this is a libdrm patch.
Mauro


2017-07-22 11:01 GMT+02:00 Mauro Rossi <issor.or...@gmail.com>:
> Changes in Android.mk makefile to avoid building errors in mesa
> due to missing LOCAL_CFLAGS variable definition for
> AMDGPU_ASIC_ID_TABLE and ASIC_ID_TABLE_NUM_ENTRIES
>
> Fixes: 7e6bf88cac ("amdgpu: move asic id table to a separate file")
> ---
>  amdgpu/Android.mk | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
> index bf0611ba..270680bb 100644
> --- a/amdgpu/Android.mk
> +++ b/amdgpu/Android.mk
> @@ -10,5 +10,13 @@ LOCAL_SHARED_LIBRARIES := libdrm
>
>  LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
>
> +ASIC_ID_TABLE_NUM_ENTRIES := $(shell egrep -ci '^[0-9a-f]{4},.*[0-9a-f]+,' \
> +   $(LIBDRM_TOP)/data/amdgpu.ids)
> +
> +LOCAL_CFLAGS += -DAMDGPU_ASIC_ID_TABLE=\"$(LIBDRM_TOP)/data/amdgpu.ids\" \
> +   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(ASIC_ID_TABLE_NUM_ENTRIES)
> +
> +$(intermediates)/amdgpu_asic_id.o: $(LIBDRM_TOP)/data/amdgpu.ids
> +
>  include $(LIBDRM_COMMON_MK)
>  include $(BUILD_SHARED_LIBRARY)
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] android: amdgpu: move asic id table to a separate file

[Mauro Rossi]

Changes in Android.mk makefile to avoid building errors in mesa
due to missing LOCAL_CFLAGS variable definition for
AMDGPU_ASIC_ID_TABLE and ASIC_ID_TABLE_NUM_ENTRIES

Fixes: 7e6bf88cac ("amdgpu: move asic id table to a separate file")
---
 amdgpu/Android.mk | 8 
 1 file changed, 8 insertions(+)

diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
index bf0611ba..270680bb 100644
--- a/amdgpu/Android.mk
+++ b/amdgpu/Android.mk
@@ -10,5 +10,13 @@ LOCAL_SHARED_LIBRARIES := libdrm
 
 LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
 
+ASIC_ID_TABLE_NUM_ENTRIES := $(shell egrep -ci '^[0-9a-f]{4},.*[0-9a-f]+,' \
+   $(LIBDRM_TOP)/data/amdgpu.ids)
+
+LOCAL_CFLAGS += -DAMDGPU_ASIC_ID_TABLE=\"$(LIBDRM_TOP)/data/amdgpu.ids\" \
+   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(ASIC_ID_TABLE_NUM_ENTRIES)
+
+$(intermediates)/amdgpu_asic_id.o: $(LIBDRM_TOP)/data/amdgpu.ids
+
 include $(LIBDRM_COMMON_MK)
 include $(BUILD_SHARED_LIBRARY)
-- 
2.11.0

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

[PATCH 2/2] amdgpu: add Android build support

[Mauro Rossi]

---
 amdgpu/Android.mk | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 amdgpu/Android.mk

diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
new file mode 100644
index 000..469df1b
--- /dev/null
+++ b/amdgpu/Android.mk
@@ -0,0 +1,18 @@
+LOCAL_PATH := $(call my-dir)
+include $(CLEAR_VARS)
+
+# Import variables LIBDRM_AMDGPU_FILES, LIBDRM_AMDGPU_H_FILES
+include $(LOCAL_PATH)/Makefile.sources
+
+LOCAL_MODULE := libdrm_amdgpu
+LOCAL_MODULE_TAGS := optional
+
+LOCAL_SHARED_LIBRARIES := libdrm
+
+LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
+LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
+
+LOCAL_CFLAGS := \
+   -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1
+
+include $(BUILD_SHARED_LIBRARY)
-- 
2.1.4

[PATCH 1/2] amdgpu: add Makefile.sources

[Mauro Rossi]

---
 amdgpu/Makefile.am  | 18 --
 amdgpu/Makefile.sources | 15 +++
 2 files changed, 19 insertions(+), 14 deletions(-)
 create mode 100644 amdgpu/Makefile.sources

diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
index ed97803..37f7198 100644
--- a/amdgpu/Makefile.am
+++ b/amdgpu/Makefile.am
@@ -22,6 +22,8 @@
 # Authors:
 #Jérôme Glisse 

+include Makefile.sources
+
 AM_CFLAGS = \
$(WARN_CFLAGS) -Wno-switch-enum \
-I$(top_srcdir) \
@@ -33,22 +35,10 @@ libdrm_amdgpu_ladir = $(libdir)
 libdrm_amdgpu_la_LDFLAGS = -version-number 1:0:0 -no-undefined
 libdrm_amdgpu_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@

-libdrm_amdgpu_la_SOURCES = \
-   amdgpu.h \
-   amdgpu_bo.c \
-   amdgpu_cs.c \
-   amdgpu_device.c \
-   amdgpu_gpu_info.c \
-   amdgpu_internal.h \
-   amdgpu_vamgr.c \
-   util_hash.c \
-   util_hash.h \
-   util_hash_table.c \
-   util_hash_table.h
+libdrm_amdgpu_la_SOURCES = $(LIBDRM_AMDGPU_FILES)

 libdrm_amdgpuincludedir = ${includedir}/libdrm
-libdrm_amdgpuinclude_HEADERS = \
-   amdgpu.h
+libdrm_amdgpuinclude_HEADERS = $(LIBDRM_AMDGPU_H_FILES)

 pkgconfigdir = @pkgconfigdir@
 pkgconfig_DATA = libdrm_amdgpu.pc
diff --git a/amdgpu/Makefile.sources b/amdgpu/Makefile.sources
new file mode 100644
index 000..c359f17
--- /dev/null
+++ b/amdgpu/Makefile.sources
@@ -0,0 +1,15 @@
+LIBDRM_AMDGPU_FILES := \
+   amdgpu.h \
+   amdgpu_bo.c \
+   amdgpu_cs.c \
+   amdgpu_device.c \
+   amdgpu_gpu_info.c \
+   amdgpu_internal.h \
+   amdgpu_vamgr.c \
+   util_hash.c \
+   util_hash.h \
+   util_hash_table.c \
+   util_hash_table.h
+
+LIBDRM_AMDGPU_H_FILES := \
+   amdgpu.h
-- 
2.1.4