Re: [git pull] drm fixes for 5.19-rc7

["Vivi, Rodrigo" <rodrigo.vivi@intel.com>]

On Sat, 2022-07-16 at 15:08 -0700, Linus Torvalds wrote:
> On Sat, Jul 16, 2022 at 2:35 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > 
> > That said, even those type simplifications do not fix the
> > fundamental
> > issue. That "DIV_ROUND_UP()" still ends up being a 64-bit divide,
> > although now it's at least a "64-by-32" bit divide.
> 
> Hmm. The "DIV_ROUND_UP()" issue could be solved by just making the
> rule be that the max_segment size is always a power of two.
> 
> Then you don't need the (expensive!) DIV_ROUND_UP(), and can just use
> the regular "round_up()" that works on powers-of-two.
> 
> And the simplest way to do that is to just make "max_segments" be
> 2GB.
> 
> The whole "round_down(UINT_MAX, page_alignment)" seems entirely
> pointless. Do you really want segments that are some odd number just
> under the 4GB mark, and force expensive divides?

I fully agree with you that if we have only things at 32bit we could
use the round up and avoid the division.

> 
> For consistency, I used the same value in
> i915_rsgt_from_buddy_resource(). I have no idea if that makes sense.
> 
> Anyway, the attached patch is COMPLETELY UNTESTED. But it at least
> seems to compile. Maybe.

Thanks. We should check this.

Meanwhile I'd like to say that the team had worked already to fix the
horrible 32 vs 64 bits inconsistency and the build breakage already.

The fix [1] was merged Jul 13.

[1] https://patchwork.freedesktop.org/patch/493637/?series=106260&rev=1

I'm the one to blame for not having
propagated this along with the latest drm-intel-fixes round.

Please accept my apologies.

I will check right now why this was missed on my side and check how to
propagate quickly.

Sorry,
Rodrigo.

> 
>                   Linus