Hi
Am 18.02.25 um 20:32 schrieb Geert Uytterhoeven:
[...]
+args->bpp);
+ fallthrough;
+ case 12:
+ case 15:
+ case 30: /* see drm_gem_afbc_get_bpp() */
+ case 10:
Perhaps keep them sort
Hi
Am 18.02.25 um 16:57 schrieb Russell King (Oracle):
On Tue, Feb 18, 2025 at 03:23:29PM +0100, Thomas Zimmermann wrote:
Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
buffer size. No alignment required.
Signed-off-by: Thomas Zimmermann
Cc: Russell King
armada_pitch()
On Tue, Feb 18, 2025 at 03:28:03AM -0600, Aaron Kling via B4 Relay wrote:
> From: Aaron Kling
>
> Most kernel configs enable multiple Tegra SoC generations, causing this
> typo to go unnoticed. But in the case where a kernel config is strictly
> for Tegra186, this is a problem.
>
> Fixes: 989863
On Wed Feb 19, 2025 at 12:24 PM JST, John Hubbard wrote:
> On 2/18/25 5:21 PM, Alexandre Courbot wrote:
>> On Wed Feb 19, 2025 at 5:51 AM JST, Timur Tabi wrote:
>>> On Tue, 2025-02-18 at 22:16 +0900, Alexandre Courbot wrote:
> ...
>> More likely this would be something like:
>>
>>let SplitU64
Hi Karol,
On Sat, Feb 15, 2025 at 08:37:53AM +0100, Karol Herbst wrote:
> Please respect my wishes and put this statement as is into the tree.
I applied this patch, as is, to drm-misc-fixes.
I respect the reasons you have and that you do so out of firm belief, yet I'm
sad to see you leaving this
On Mon, Feb 17, 2025 at 10:31:21AM +0300, Dan Carpenter wrote:
> If "rpc" is an error pointer then return directly. Otherwise it leads
> to an error pointer dereference.
>
> Fixes: 50f290053d79 ("drm/nouveau: support handling the return of large GSP
> message")
> Signed-off-by: Dan Carpenter
A
On Tue, Feb 18, 2025 at 11:26:01AM +0100, Danilo Krummrich wrote:
> On Tue, Feb 18, 2025 at 11:46:26AM +1000, Dave Airlie wrote:
> > > 1. How to avoid unnecessary calls to try_access().
> > >
> > > This is why I made Boot0.read() take a &RevocableGuard<'_, Bar0> as
> > > argument. I
> > > think we
On 2/19/25 4:51 AM, Alexandre Courbot wrote:
Yes, that looks like the optimal way to do this actually. It also
doesn't introduce any overhead as the destructuring was doing both
high_half() and low_half() in sequence, so in some cases it might
even be more efficient.
I'd just like to find a bett
On Thu, 20 Feb 2025 at 06:22, John Hubbard wrote:
>
> On 2/19/25 4:51 AM, Alexandre Courbot wrote:
> > Yes, that looks like the optimal way to do this actually. It also
> > doesn't introduce any overhead as the destructuring was doing both
> > high_half() and low_half() in sequence, so in some cas
> On 19 Feb 2025, at 17:23, Dave Airlie wrote:
>
> On Thu, 20 Feb 2025 at 06:22, John Hubbard wrote:
>>
>> On 2/19/25 4:51 AM, Alexandre Courbot wrote:
>>> Yes, that looks like the optimal way to do this actually. It also
>>> doesn't introduce any overhead as the destructuring was doing both
On 2/19/25 3:13 PM, Daniel Almeida wrote:
On 19 Feb 2025, at 17:23, Dave Airlie wrote:
On Thu, 20 Feb 2025 at 06:22, John Hubbard wrote:
On 2/19/25 4:51 AM, Alexandre Courbot wrote:
Yes, that looks like the optimal way to do this actually. It also
doesn't introduce any overhead as the destruc
11 matches
Mail list logo
