[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPM=9txM=0Rd8sP56X1v2sXhAYiRJDoz-j8+N0wXpam-+kYJ8Q@mail.gmail.com>
Date: Tue, 15 Jul 2014 14:35:19 +1000
From: Dave Airlie <airlied@...il.com>
To: Christian König <deathsimple@...afone.de>
Cc: Jerome Glisse <j.glisse@...il.com>,
"Bridgman, John" <John.Bridgman@....com>,
"Lewycky, Andrew" <Andrew.Lewycky@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"Deucher, Alexander" <Alexander.Deucher@....com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH 00/83] AMD HSA kernel driver
On 14 July 2014 18:37, Christian König <deathsimple@...afone.de> wrote:
>> I vote for HSA module that expose ioctl and is an intermediary with the
>> kernel driver that handle the hardware. This gives a single point for
>> HSA hardware and yes this enforce things for any hardware manufacturer.
>> I am more than happy to tell them that this is it and nothing else if
>> they want to get upstream.
>
> I think we should still discuss this single point of entry a bit more.
>
> Just to make it clear the plan is to expose all physical HSA capable devices
> through a single /dev/hsa device node to userspace.
This is why we don't design kernel interfaces in secret foundations,
and expect anyone to like them.
So before we go any further, how is this stuff planned to work for
multiple GPUs/accelerators?
Do we have a userspace to exercise this interface so we can see how
such a thing would look?
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists