All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denys Dmytriyenko <denis@denix.org>
To: rs@ti.com
Cc: Andrew Davis <afd@ti.com>,
	reatmon@ti.com, denys@ti.com, detheridge@ti.com,
	meta-ti@lists.yoctoproject.org
Subject: Re: [meta-ti] [master][PATCH v2] meta-ti-bsp: Graphics recipe overhaul
Date: Mon, 19 Dec 2022 16:32:35 -0500	[thread overview]
Message-ID: <20221219213235.GX22689@denix.org> (raw)
In-Reply-To: <J3EWMR.6Q68HWA4M8303@ti.com>

On Wed, Dec 14, 2022 at 02:26:07PM -0600, Randolph Sapp via lists.yoctoproject.org wrote:
> On Wed, Dec 14 2022 at 12:47:29 -06:00:00, Andrew Davis <afd@ti.com>
> wrote:
> >On 12/9/22 4:18 PM, Sapp, Randolph wrote:
> >>On Wed, Dec 7 2022 at 12:48:00 PM -0600, Andrew Davis
> >><afd@ti.com <mailto:afd@ti.com>> wrote:
> >>>Since the UM driver now RDEPENDS on the KM, could we also drop this
> >>>last line everywhere?
> >>
> >>Nope, we still need the one preferred provider line to indicate
> >>that rogue graphics are present. Now this could be replaced by a
> >>rogue-graphics machine feature instead if that's preferable, but
> >>something will need to signal the mesa switch.
> >>
> >
> >New machine feature sounds like the better route since it changes
> >the content of a package.
> >Using PREFERRED_PROVIDER for that doesn't seem right.
> 
> Fair enough, v4 will roll back to that method.

Can you please explain why existing machine feature cannot be re-used and a 
new one is needed here? Do you plan to use both side-by-side?


> On Wed, Dec 14 2022 at 12:47:29 -06:00:00, Andrew Davis <afd@ti.com>
> wrote:
> >
> >>On Wed, Dec 7 2022 at 12:48:00 PM -0600, Andrew Davis
> >><afd@ti.com <mailto:afd@ti.com>> wrote:
> >>>Bash? Are we sure we need that?
> >>
> >>Yes. The System V init script still needs it. Now could we look
> >>at removing that init script? Sure, so long as the device probe
> >>still works. What is actually taking care of that right now?
> >>It's not udev is it?
> >>
> >
> >The module/device probe is automatic now. At least for SGX that
> >script exists only
> >to run the single command "pvrsrvctl --start --no-module" which
> >loads some microcode.
> >We can have yocto build that service for us to run the command,
> >IIRC it will make
> >it into a systemd or sysv service for us based on what kinda
> >distro we are building.
> 
> If that's true rogue can drop it entirely. Updating to do that now.
> 
> On Wed, Dec 14 2022 at 12:47:29 -06:00:00, Andrew Davis <afd@ti.com>
> wrote:
> >
> >>On Wed, Dec 7 2022 at 12:48:00 PM -0600, Andrew Davis
> >><afd@ti.com <mailto:afd@ti.com>> wrote:
> >>>"ldflags already-stripped" should be the only skips we still need.
> >>
> >>Dev-so is required because of some of the symbolic links that
> >>are shipped. I'm fine dropping arch unless that breaks
> >>something.
> >>
> >>
> >
> >Ah, think that is /usr/lib/dri/pvr_dri.so, odd name, but yeah that
> >skip can
> >stay then. Lets try to drop "arch" at least.
> 
> Just found out the MIPS/RISC firmware bin trips the arch check so
> that has to stay.
> 
> If you don't mind, take a look at the v3 revision. I'm experimenting
> with using the binary_package class there. Not really sure how I
> feel about it, but it's at least less lines & steps than this
> revision.


  reply	other threads:[~2022-12-19 21:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-06 17:45 [master][PATCH v2] meta-ti-bsp: Graphics recipe overhaul Randolph Sapp
2022-12-07 17:15 ` Ryan Eatmon
2022-12-07 18:48 ` [meta-ti] " Andrew Davis
2022-12-09 22:18   ` Sapp, Randolph
2022-12-14  0:07     ` Denys Dmytriyenko
2022-12-14 18:47     ` Andrew Davis
2022-12-14 20:26       ` Sapp, Randolph
2022-12-19 21:32         ` Denys Dmytriyenko [this message]
2022-12-21 16:49           ` [EXTERNAL] " Sapp, Randolph
2022-12-22 22:47             ` Denys Dmytriyenko
2022-12-27 18:36               ` [EXTERNAL] " Sapp, Randolph
2023-01-04 23:07                 ` Denys Dmytriyenko
2023-01-11 19:33                   ` Sapp, Randolph
2023-01-11 19:37                     ` Andrew Davis
2022-12-14 18:03   ` Sapp, Randolph

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221219213235.GX22689@denix.org \
    --to=denis@denix.org \
    --cc=afd@ti.com \
    --cc=denys@ti.com \
    --cc=detheridge@ti.com \
    --cc=meta-ti@lists.yoctoproject.org \
    --cc=reatmon@ti.com \
    --cc=rs@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.