On Apr 8, 2014 12:02 AM, "Rob Clark" <robdclark(a)gmail.com> wrote:
On Mon, Apr 7, 2014 at 11:43 PM, Liam <liam.bulkley(a)gmail.com> wrote:
>
> On Apr 7, 2014 10:58 PM, "Rob Clark" <robdclark(a)gmail.com> wrote:
>>
>> On Sun, Mar 23, 2014 at 11:03 AM, Liam <liam.bulkley(a)gmail.com> wrote:
>> >
>> > On Mar 23, 2014 6:44 AM, "Peter Robinson"
<pbrobinson(a)gmail.com>
wrote:
>> >>
>> >> > I don't have an issue with ARM (or PPC) builds of the
workstation,
>> >> > but
>> >> > I don't think we should decide to make them officially
supported
>> >> > platforms
>> >> > before we feel very certain there is a viable community and
ecosystem
>> >> > around
>> >> > them to make the product workable medium to long term on those
>> >> > platforms.
>> >> > This means of cause the basic lithmus test of having the shell
'work'
>> >> > on
>> >> > a specific
>> >> > piece of hardware, but also there needs to be a viable roadmap
for
>> >> > that
>> >> > hardware
>> >> > going forward. I mean I don't want a situation where we
declare
ARM
>> >> > supported
>> >> > because someone got a build working on a specific dev board, only
to
>> >> > have the
>> >> > manufacturer of that devboard switch GPU provider in the next
>> >> > iteration
>> >> > and leave
>> >> > us without a working open driver.
>> >>
>> >> Believe me you are not alone in that regard, it's a discussion the
ARM
>> >> people have on a regular basis. We've already
had one vendor and
>> >> another SoC go from hero to zero in a short period of time :-)
>> >>
>> >> > Rob Clark is doing stellar work on Freedreno and the new Broadcom
>> >> > source
>> >> > code release
>> >> > is good news in this regard, but I think I personally need to
feel
>> >> > that
>> >> > a
>> >> > officially supported ARM platform needs to be something we can
>> >> > believe
>> >> > will
>> >> > continue to exist and not a one shot 'the stars aligned for
us'
>> >> > situation.
>> >>
>> >> Personally I'm not sure either of those are of much value. The
QCom
>> >> devices are primarily used in phones which aren't really targets
for
>> >> Fedora ARM. There's currently one dev board I'm aware of and
it's
not
>> >> widely available and it's not currently
anywhere on our roadmap when
>> >> it comes to the kernel.
>> >>
>> > I'm guessing you're referring to this:
http://mydragonboard.org/db8074/
>> > Although listed as a SoM, it looks like the carrier
board is optional
>> > with
>> > the 12V jack.
>> > No idea about the availability, though, but should certainly be
capable
>> > of
>> > running any of the workstation products... if it can actually run
any
of
>> > the
>> > workstation products...
>>
>> fyi:
>> dragonboard:
>>
http://shop.intrinsyc.com/products/snapdragon-800-series-apq8074-based-dr...
>> ifc6410:
>>
http://www.inforcelive.com/index.php?route=product/product&filter_nam...
>>
>> Both are running (the same) f20 userspace + latest mesa/libdrm +
>> xf86-video-freedreno (sorry, I'm lagging on updating for review
>> comments for the .spec file) + custom kernel. Gnome-shell works
>> perfectly. As do most of the games packaged in fedora that I have
>> tried. (xonotic, supertuxkart, etc)
>>
>> f21 should have a new enough mesa. For just gnome-shell 10.1.x should
>> be enough.. for games, you'll want newer. The missing piece is an
>> upstream kernel. But we are getting there.
>>
>> BR,
>> -R
>
> To be clear, you're saying f20 currently supports the apq8074? The newer
> kernel would be needed to make gaming a possibility, but not for
hardware
> enablement?
well, not quite.. what is missing from f20 userspace amounts to:
* xf86-video-freedreno
* newer mesa & libdrm
The remaining improvements vs mesa 10.1 (for games, etc) are all
userspace (mesa) and are all on mesa master.
For anyone who has a dragonboard/ifc6410/etc, for f20 I recommend:
http://blog.kwizart.fr/post/2014/03/02/163-mesa-10.2-from-git-for-Fedora-20
(but I expect this all to be in f21)
... and that's why I asked:)
Thanks for the clarification.
> Do you know if f20 is enough for the SoM as well?
userspace should be the same for the SoM. But for upstream kernel
maybe there is need for a different .dts file.
(but that said, I think the dragonboard is just the SoM + carrier
board, so maybe from kernel perspective it looks the same as the full
dragonboard)
It was device tree that I was mainly thinking about and given how board
specific those files are, I wasnt sure that even if it was literally, as
you say above, that it could still be enabled with the same dts.
Best/Liam