On 2022-02-14 12:50 a.m., Jonathan Gray wrote:
On Mon, Feb 14, 2022 at 12:05:44AM -0700, Ted Bullock wrote:
On 2022-02-13 11:02 p.m., Jonathan Gray wrote:
On Sun, Feb 13, 2022 at 12:22:38PM -0700, Ted Bullock wrote:
On 2022-02-12 6:46 p.m., Jonathan Gray wrote:
I will review further when
On Mon, Feb 14, 2022 at 12:05:44AM -0700, Ted Bullock wrote:
>
> On 2022-02-13 11:02 p.m., Jonathan Gray wrote:
> > On Sun, Feb 13, 2022 at 12:22:38PM -0700, Ted Bullock wrote:
> > > On 2022-02-12 6:46 p.m., Jonathan Gray wrote:
> > > > I will review further when you drop the function.
> > >
> >
On 2022-02-13 11:02 p.m., Jonathan Gray wrote:
On Sun, Feb 13, 2022 at 12:22:38PM -0700, Ted Bullock wrote:
On 2022-02-12 6:46 p.m., Jonathan Gray wrote:
I will review further when you drop the function.
Alright try this again,
I have committed some parts of this, with one commit per
On Sun, Feb 13, 2022 at 12:22:38PM -0700, Ted Bullock wrote:
> On 2022-02-12 6:46 p.m., Jonathan Gray wrote:
> > I will review further when you drop the function.
>
> Alright try this again,
I have committed some parts of this, with one commit per specific issue.
pa_memex NULL test
sparc64
On 2022-02-12 6:46 p.m., Jonathan Gray wrote:
> I will review further when you drop the function.
Alright try this again,
diff b5c3be43fcdaf7cbd7d070c07746b451413f6b4a
453e49da7f0804392d6d51fb578cfd8255f4fb77
blob - a2d53f752bccb1ab54993ec2a7d5791ec2216e0a
blob +
On Sat, Feb 12, 2022 at 02:42:16PM -0700, Ted Bullock wrote:
> On 2022-02-11 7:16 p.m., Jonathan Gray wrote:
> > I'm not so keen on another function and putting bar information into
> > local arrays seems odd.
>
> Are there technical reasons for not wanting a function? I know that
> pulling in
On 2022-02-11 7:16 p.m., Jonathan Gray wrote:
> On Fri, Feb 11, 2022 at 06:42:11PM -0700, Ted Bullock wrote:
>>
>> There is more to this function that I think is problematic,
>> especially from a MI point of view but I thought I would leave it
>> off here. Below is a diff that resolves all my
On Fri, Feb 11, 2022 at 06:42:11PM -0700, Ted Bullock wrote:
> Hey,
>
> I've found some problems with the radeondrm initialization
> codepath (radeon_kms.c). Before I start, I should mention that I am
> working on some diffs to remove a bunch of the sparc64 MD ifdef's as
> well. In
Hey,
I've found some problems with the radeondrm initialization
codepath (radeon_kms.c). Before I start, I should mention that I am
working on some diffs to remove a bunch of the sparc64 MD ifdef's as
well. In radeondrm_attach_kms:
starting from line 545
==
#define
