On Mon, Jul 29, 2024 at 02:34:25PM -0400, Lyude Paul wrote:
> On Fri, 2024-07-26 at 15:40 +0200, Daniel Vetter wrote:
> > On Thu, Jul 25, 2024 at 03:35:18PM -0400, Lyude Paul wrote:
> > > On Tue, 2024-07-16 at 11:25 +0200, Daniel Vetter wrote:
> > > > On Mon, Jul 15, 2024 at 02:05:49PM -0300, Danie
On Fri, 2024-07-26 at 15:40 +0200, Daniel Vetter wrote:
> On Thu, Jul 25, 2024 at 03:35:18PM -0400, Lyude Paul wrote:
> > On Tue, 2024-07-16 at 11:25 +0200, Daniel Vetter wrote:
> > > On Mon, Jul 15, 2024 at 02:05:49PM -0300, Daniel Almeida wrote:
> > > > Hi Sima!
> > > >
> > > >
> > > > >
> > >
On Thu, Jul 25, 2024 at 03:35:18PM -0400, Lyude Paul wrote:
> On Tue, 2024-07-16 at 11:25 +0200, Daniel Vetter wrote:
> > On Mon, Jul 15, 2024 at 02:05:49PM -0300, Daniel Almeida wrote:
> > > Hi Sima!
> > >
> > >
> > > >
> > > > Yeah I'm not sure a partially converted driver where the main drive
On Tue, 2024-07-16 at 11:25 +0200, Daniel Vetter wrote:
> On Mon, Jul 15, 2024 at 02:05:49PM -0300, Daniel Almeida wrote:
> > Hi Sima!
> >
> >
> > >
> > > Yeah I'm not sure a partially converted driver where the main driver is
> > > still C really works, that pretty much has to throw out all the
On 7/23/24 5:06 PM, Boris Brezillon wrote:
Hi Steve,
On Mon, 15 Jul 2024 10:12:16 +0100
Steven Price wrote:
I note it also shows that the "panthor_regs.rs" would ideally be shared.
For arm64 we have been moving to generating system register descriptions
from a text source (see arch/arm64/t
We did discuss this, but I've come to the conclusion that's the wrong
approach. Converting is going to need to track kernel closely as there
are lots of dependencies with the various rust abstractions needed. If
we just copy over the C driver, that's an invitation to diverge and
accumulate tech
On Wed, Jul 24, 2024 at 3:54 PM Steven Price wrote:
>
> I'd be quite keen for the "fork" to live in the upstream kernel. My
> preference is for the two drivers to sit side-by-side. I'm not sure
> whether that's a common view though.
It is supposed to be against the usual rules/guidelines, but we
On 24/07/2024 15:27, Daniel Almeida wrote:
> Hi Steven!
>
>> On 24 Jul 2024, at 10:54, Steven Price wrote:
>>
>> [1] Although I have to admit for a debugging feature like devcoredump
>> there might well be pressure to implement this in C as well purely so
>> that customer issues can be debugged…
Hi Steven!
> On 24 Jul 2024, at 10:54, Steven Price wrote:
>
> [1] Although I have to admit for a debugging feature like devcoredump
> there might well be pressure to implement this in C as well purely so
> that customer issues can be debugged…
FYI: I picked devcoredump because it was self-cont
On 24/07/2024 14:15, Rob Herring wrote:
> On Wed, Jul 24, 2024 at 3:59 AM Steven Price wrote:
>>
>> Hi Boris,
>>
>> On 23/07/2024 17:06, Boris Brezillon wrote:
>>> Hi Steve,
>>>
>>> On Mon, 15 Jul 2024 10:12:16 +0100
>>> Steven Price wrote:
>>>
I note it also shows that the "panthor_regs.rs"
On Wed, Jul 24, 2024 at 3:59 AM Steven Price wrote:
>
> Hi Boris,
>
> On 23/07/2024 17:06, Boris Brezillon wrote:
> > Hi Steve,
> >
> > On Mon, 15 Jul 2024 10:12:16 +0100
> > Steven Price wrote:
> >
> >> I note it also shows that the "panthor_regs.rs" would ideally be shared.
> >> For arm64 we ha
Hi Boris,
Sounds like we're violently agreeing with each other ;) Just want to
reply to a couple of points.
On 24/07/2024 11:44, Boris Brezillon wrote:
> Hi Steve,
>
> On Wed, 24 Jul 2024 09:59:36 +0100
> Steven Price wrote:
>
>> Hi Boris,
>>
>> On 23/07/2024 17:06, Boris Brezillon wrote:
>>>
Hi Steve,
On Wed, 24 Jul 2024 09:59:36 +0100
Steven Price wrote:
> Hi Boris,
>
> On 23/07/2024 17:06, Boris Brezillon wrote:
> > Hi Steve,
> >
> > On Mon, 15 Jul 2024 10:12:16 +0100
> > Steven Price wrote:
> >
> >> I note it also shows that the "panthor_regs.rs" would ideally be shared.
>
Hi Boris,
On 23/07/2024 17:06, Boris Brezillon wrote:
> Hi Steve,
>
> On Mon, 15 Jul 2024 10:12:16 +0100
> Steven Price wrote:
>
>> I note it also shows that the "panthor_regs.rs" would ideally be shared.
>> For arm64 we have been moving to generating system register descriptions
>> from a text
The script (and the panthor_regs.rs file it generates) is at
https://gitlab.collabora.com/dwlsalmeida/for-upstream/-/commit/783be55acf8d3352901798efb0118cce43e7f60b
As you can see, it’s all regexes. It works, but I agree
that it’s simpler to generate something more idiomatic by hand.
— Daniel
Hi Steve,
On Mon, 15 Jul 2024 10:12:16 +0100
Steven Price wrote:
> I note it also shows that the "panthor_regs.rs" would ideally be shared.
> For arm64 we have been moving to generating system register descriptions
> from a text source (see arch/arm64/tools/sysreg) - I'm wondering whether
> some
On Tue, Jul 23, 2024 at 3:41 PM Daniel Almeida
wrote:
>
> Hi Alice, thanks for the review!
>
>
> >> +fn alloc_mem(&mut self, size: usize) -> Option<*mut u8> {
> >> +assert!(size % 8 == 0, "Allocation size must be 8-byte
> >> aligned");
> >> +if isize::try_from(size
Hi Alice, thanks for the review!
>> +fn alloc_mem(&mut self, size: usize) -> Option<*mut u8> {
>> +assert!(size % 8 == 0, "Allocation size must be 8-byte
>> aligned");
>> +if isize::try_from(size).unwrap() == isize::MAX {
>> +return None;
>> +
On Thu, Jul 11, 2024 at 12:52 AM Daniel Almeida
wrote:
>
> Dump the state of the GPU. This feature is useful for debugging purposes.
> ---
> Hi everybody!
>
> For those looking for a branch instead, see [0].
>
> I know this patch has (possibly many) issues. It is meant as a
> discussion around the
On Mon, Jul 15, 2024 at 11:12 AM Steven Price wrote:
> >>> +
> >>> +pub(crate) const GPU_ID: GpuRegister = GpuRegister(0x0);
> >>> +pub(crate) const fn gpu_arch_major(x: u64) -> GpuRegister {
> >>> +GpuRegister((x) >> 28)
> >>> +}
> >>> +pub(crate) const fn gpu_arch_minor(x: u64) -> GpuRegiste
On Mon, Jul 15, 2024 at 02:05:49PM -0300, Daniel Almeida wrote:
> Hi Sima!
>
>
> >
> > Yeah I'm not sure a partially converted driver where the main driver is
> > still C really works, that pretty much has to throw out all the type
> > safety in the interfaces.
> >
> > What I think might work i
Hi Sima!
>
> Yeah I'm not sure a partially converted driver where the main driver is
> still C really works, that pretty much has to throw out all the type
> safety in the interfaces.
>
> What I think might work is if such partial drivers register as full rust
> drivers, and then largely delega
On 12/07/2024 15:35, Daniel Almeida wrote:
> Hi Steven, thanks for the review!
>
>>
>> This is defining the ABI to userspace and as such we'd need a way of
>> exporting this for userspace tools to use. The C approach is a header in
>> include/uabi. I'd also suggest making it obvious this enum can'
On Thu, Jul 11, 2024 at 02:01:18AM +0200, Danilo Krummrich wrote:
> (+Sima)
>
> Hi Daniel,
>
> On 7/11/24 12:50 AM, Daniel Almeida wrote:
> > Dump the state of the GPU. This feature is useful for debugging purposes.
> > ---
> > Hi everybody!
> >
> > For those looking for a branch instead, see [0
On Sat, Jul 13, 2024 at 2:48 AM Dave Airlie wrote:
>
> I think I'm on the uapi should remain in C for now, we define uapi
> types with the kernel types and we have downstream tools to scan and
> parse them to deal with alignments and padding (I know FEX relies on
> it), so I think we should be bin
Hi Dave,
>
> I think I'm on the uapi should remain in C for now, we define uapi
> types with the kernel types and we have downstream tools to scan and
> parse them to deal with alignments and padding (I know FEX relies on
> it), so I think we should be bindgen from uapi headers into rust for
> no
On Sat, 13 Jul 2024 at 01:32, Danilo Krummrich wrote:
>
> On Fri, Jul 12, 2024 at 12:13:15PM -0300, Daniel Almeida wrote:
> >
> >
> > > On 12 Jul 2024, at 11:53, Danilo Krummrich wrote:
> > >
> > > You could also just define those structures in a C header directly and
> > > use it
> > > from Rus
On Fri, Jul 12, 2024 at 12:13:15PM -0300, Daniel Almeida wrote:
>
>
> > On 12 Jul 2024, at 11:53, Danilo Krummrich wrote:
> >
> > You could also just define those structures in a C header directly and use
> > it
> > from Rust, can't you?
> >
>
>
> Sure, I am open to any approach here. Altho
> On 12 Jul 2024, at 11:53, Danilo Krummrich wrote:
>
> You could also just define those structures in a C header directly and use it
> from Rust, can't you?
>
Sure, I am open to any approach here. Although this looks a bit reversed to me.
i.e.: why should I declare these structs in a sepa
On Fri, Jul 12, 2024 at 11:35:25AM -0300, Daniel Almeida wrote:
> Hi Steven, thanks for the review!
>
> >
> > This is defining the ABI to userspace and as such we'd need a way of
> > exporting this for userspace tools to use. The C approach is a header in
> > include/uabi. I'd also suggest making
Hi Steven, thanks for the review!
>
> This is defining the ABI to userspace and as such we'd need a way of
> exporting this for userspace tools to use. The C approach is a header in
> include/uabi. I'd also suggest making it obvious this enum can't be
> rearranged (e.g. a comment, or assigning sp
Hi Daniel,
I'm not a Rust expert so I'll have to defer to others on Rust-style.
I'll try to concentrate on Mali-specific parts. Apologies if you feel
this is too early, but hopefully it gives some ideas on how to improve
before it actually gets merged.
On 10/07/2024 23:50, Daniel Almeida wrote:
>
Hi Liviu,
> Hi Daniel,
>
> I know this is an RFC, but are you trying to avoid Cc-ing Panthor maintainers
> by mistake or by choice? I will be away on sabbatical from next week, but
> Steven Price at least would be interested in having a look.
Definitely by mistake. Boris is my coworker, but ever
On Wed, Jul 10, 2024 at 07:50:06PM -0300, Daniel Almeida wrote:
> Dump the state of the GPU. This feature is useful for debugging purposes.
> ---
> Hi everybody!
Hi Daniel,
I know this is an RFC, but are you trying to avoid Cc-ing Panthor maintainers
by mistake or by choice? I will be away on sab
(+Sima)
Hi Daniel,
On 7/11/24 12:50 AM, Daniel Almeida wrote:
Dump the state of the GPU. This feature is useful for debugging purposes.
---
Hi everybody!
For those looking for a branch instead, see [0].
I know this patch has (possibly many) issues. It is meant as a
discussion around the GEM a
Dump the state of the GPU. This feature is useful for debugging purposes.
---
Hi everybody!
For those looking for a branch instead, see [0].
I know this patch has (possibly many) issues. It is meant as a
discussion around the GEM abstractions for now. In particular, I am
aware of the series intro
36 matches
Mail list logo
