[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[Fabio Estevam]

Select CONFIG_DRM_ETNAVIV, so that GPU support can be enabled by default.

Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
 arch/arm/configs/imx_v6_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 2d5253d..be08ce7 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -231,6 +231,7 @@ CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
 CONFIG_DRM_IMX_TVE=y
 CONFIG_DRM_IMX_LDB=y
 CONFIG_DRM_IMX_HDMI=y
+CONFIG_DRM_ETNAVIV=y
 CONFIG_FB_MXS=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_L4F00242T03=y
-- 
1.9.1

[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[Shawn Guo]

On Mon, Dec 21, 2015 at 04:44:02PM -0200, Fabio Estevam wrote:
> Select CONFIG_DRM_ETNAVIV, so that GPU support can be enabled by default.
> 
> Signed-off-by: Fabio Estevam <festevam@gmail.com>
> ---
>  arch/arm/configs/imx_v6_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
> index 2d5253d..be08ce7 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -231,6 +231,7 @@ CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
>  CONFIG_DRM_IMX_TVE=y
>  CONFIG_DRM_IMX_LDB=y
>  CONFIG_DRM_IMX_HDMI=y
> +CONFIG_DRM_ETNAVIV=y

I do not have this Kconfig option on my tree yet.

Shawn

>  CONFIG_FB_MXS=y
>  CONFIG_LCD_CLASS_DEVICE=y
>  CONFIG_LCD_L4F00242T03=y
> -- 
> 1.9.1
> 
> 

[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[Fabio Estevam]

On Tue, Dec 22, 2015 at 10:21 AM, Shawn Guo <shawnguo@kernel.org> wrote:

> I do not have this Kconfig option on my tree yet.

Yes, I know, but would this cause any issue?

This would allow etnaviv to be functional by default on 4.5. Otherwise
we should wait for 4.6.

[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[Lucas Stach]

Am Dienstag, den 22.12.2015, 10:30 -0200 schrieb Fabio Estevam:
> On Tue, Dec 22, 2015 at 10:21 AM, Shawn Guo <shawnguo@kernel.org>
> wrote:
> 
> > I do not have this Kconfig option on my tree yet.
> 
> Yes, I know, but would this cause any issue?
> 
> This would allow etnaviv to be functional by default on 4.5.
> Otherwise
> we should wait for 4.6.
> 
I don't see a need to rush this. We can always enable it in the -rc
phase of 4.5 is we desire.
But to be honest I would like to give etnaviv a cycle to stabilize
until we enable it by default. With i.MX6QP now hitting the street and
basically no testing of etnaviv being done there until now, I would
rather not have it in the defconfig just now. It's not like it's hard
for people willing to test this to enable a single Kconfig option...

Regards,
Lucas

[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[Fabio Estevam]

On Tue, Dec 22, 2015 at 10:47 AM, Lucas Stach <l.stach@pengutronix.de> wrote:

> I don't see a need to rush this. We can always enable it in the -rc
> phase of 4.5 is we desire.
> But to be honest I would like to give etnaviv a cycle to stabilize
> until we enable it by default. With i.MX6QP now hitting the street and
> basically no testing of etnaviv being done there until now, I would
> rather not have it in the defconfig just now. It's not like it's hard
> for people willing to test this to enable a single Kconfig option...

Ok, let's enable it in 4.5-rc1.

[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[Russell King - ARM Linux]

On Tue, Dec 22, 2015 at 01:47:34PM +0100, Lucas Stach wrote:
> But to be honest I would like to give etnaviv a cycle to stabilize
> until we enable it by default. With i.MX6QP now hitting the street and
> basically no testing of etnaviv being done there until now, I would
> rather not have it in the defconfig just now. It's not like it's hard
> for people willing to test this to enable a single Kconfig option...

I already have an iMX6QP uSOM for the Hummingboard/Cubox-i, but I've
been holding back testing it because (from what I've seen of the QP
patches) I think it needs different settings for stuff like pinmux
and similar?

If the QP stuff gets into the kernel soon, I'll throw the uSOM onto
one of the many hummingboards I have here and add it into the etnaviv
test pool.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[Russell King - ARM Linux]

On Tue, Dec 22, 2015 at 12:53:00PM +0000, Russell King - ARM Linux wrote:
> On Tue, Dec 22, 2015 at 01:47:34PM +0100, Lucas Stach wrote:
> > But to be honest I would like to give etnaviv a cycle to stabilize
> > until we enable it by default. With i.MX6QP now hitting the street and
> > basically no testing of etnaviv being done there until now, I would
> > rather not have it in the defconfig just now. It's not like it's hard
> > for people willing to test this to enable a single Kconfig option...
> 
> I already have an iMX6QP uSOM for the Hummingboard/Cubox-i, but I've
> been holding back testing it because (from what I've seen of the QP
> patches) I think it needs different settings for stuff like pinmux
> and similar?
> 
> If the QP stuff gets into the kernel soon, I'll throw the uSOM onto
> one of the many hummingboards I have here and add it into the etnaviv
> test pool.

I'm told by Jon that it's (basically) not as simple as that for several
reasons, mainly u-boot related, and u-boot is now one hell of a mess.

Apparently, Jon tried to submit u-boot support for Hummingboards upstream,
but it was rejected by u-boot developers saying "they didn't like it and
it wasn't "proper" with no information on how they wanted it fixed.".

When Jon tried pushing them privately, they said "they would only accept
"finished" patches."

However, u-boot people subsequently took _incomplete_ patches from someone
else to support _just_ the iMX6D Hummingboard.  The result is that the
SDRAM controller is incorrectly setup for the other versions of the
Hummingboards.

Overall, this means that SolidRun's u-boot is now significantly different
from mainline u-boot - and now u-boot needs additional modification to
support the QP parts.  I suspect Jon will just have to say "screw mainline
u-boot, we're keeping our own vendor branch of it."  He doesn't want to,
he wants to be a good open source citizen, but when faced with this kind
of politics, I can see why people decide to say "screw contributing to
mainline" and keep their own vendor trees.

So... I'm going to have to wait for Jon to find time to spin up patches
for SolidRun's u-boot branch as well before I can do any testing with
the iMX6QP hardware.

In other words, I've no idea if or when I'll be able to use the iMX6QP
hardware I have, because open source projects sometimes become political
and suck.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[Fabio Estevam]

Hi Russell and Jon,

On Tue, Dec 22, 2015 at 1:02 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> I'm told by Jon that it's (basically) not as simple as that for several
> reasons, mainly u-boot related, and u-boot is now one hell of a mess.
>
> Apparently, Jon tried to submit u-boot support for Hummingboards upstream,
> but it was rejected by u-boot developers saying "they didn't like it and
> it wasn't "proper" with no information on how they wanted it fixed.".
>
> When Jon tried pushing them privately, they said "they would only accept
> "finished" patches."
>
> However, u-boot people subsequently took _incomplete_ patches from someone
> else to support _just_ the iMX6D Hummingboard.  The result is that the
> SDRAM controller is incorrectly setup for the other versions of the
> Hummingboards.

It seems the information you got from Jon is not correct.

We do support several versions of Hummingboard and Cubox-i (at least
for the board models I have access to) in mainline U-boot.

The SDRAM is correctly setup depending on the board type:
http://git.denx.de/?p=u-boot.git;a=history;f=board/solidrun/mx6cuboxi/mx6cuboxi.c;h=fc37f1eef06da5147e5403d4272d220836c9cfbc;hb=HEAD

Like you said in the past only the old mx6d hummingboard was
supported, but we are in better shape now and the old support has been
removed.

> Overall, this means that SolidRun's u-boot is now significantly different
> from mainline u-boot - and now u-boot needs additional modification to
> support the QP parts.  I suspect Jon will just have to say "screw mainline
> u-boot, we're keeping our own vendor branch of it."  He doesn't want to,
> he wants to be a good open source citizen, but when faced with this kind
> of politics, I can see why people decide to say "screw contributing to
> mainline" and keep their own vendor trees.

We already have support for mx6qpsabreauto support in U-boot mainline:
configs/mx6qpsabreauto_defconfig

> So... I'm going to have to wait for Jon to find time to spin up patches
> for SolidRun's u-boot branch as well before I can do any testing with
> the iMX6QP hardware.

Jon,

I don't have access to a mx6qp solidrun board. Feel free to contact me
directly if you need help on porting U-boot mainline to this board.

Regards,

Fabio Estevam

[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[Russell King - ARM Linux]

Jon is busy at the moment, and I expect will reply in a few hours or
so.

On Tue, Dec 22, 2015 at 01:31:53PM -0200, Fabio Estevam wrote:
> It seems the information you got from Jon is not correct.

I suspect Jon is in a better position to comment about what works and
what doesn't, as he's doing the customer facing support for SolidRun,
and has to deal with people trying to run stock u-boot on SolidRun's
hardware.

_Especially_ when he gets regular reports from users trying to run
Fedora 23 on SolidRun platforms, which ships with mainline u-boot,
and it fails to work because mainline u-boot gets stuff wrong.  The
telling thing for Jon is that when he gets users to switch to SR's
u-boot, the problems magically vanish.

> We do support several versions of Hummingboard and Cubox-i (at least
> for the board models I have access to) in mainline U-boot.

Maybe, rather than this "vendors are evil, we must write our own patches
which are independent of the vendor" attitude, maybe people ought to
work _with_ vendors?  Jon is an open source guy, he was working on OLPC
before he switched to the SolidRun platforms, first as a hobby and later
as their kernel and uboot maintainer.  He's not an evil vendor!

> The SDRAM is correctly setup depending on the board type:
> http://git.denx.de/?p=u-boot.git;a=history;f=board/solidrun/mx6cuboxi/mx6cuboxi.c;h=fc37f1eef06da5147e5403d4272d220836c9cfbc;hb=HEAD
> 
> Like you said in the past only the old mx6d hummingboard was
> supported, but we are in better shape now and the old support has been
> removed.

Jon is aware of what's in mainline u-boot, and the memory timings there
are wrong.  For a start, the highest DDR clock rate is 1066MHz, not
1600MHz that you have in mainline u-boot.  So you're overclocking the
SDRAM.

I know that Jon has put a _lot_ of effort into getting the SDRAM setup
stable on SolidRun hardware to eliminate hangs and other problems, and
it seems the attitude is "we don't care about that, we're mainline, we
know better."

So, excuse me if I trust Jon's comments about uboot more than anyone
elses.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[Fabio Estevam]

On Tue, Dec 22, 2015 at 2:16 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Jon is busy at the moment, and I expect will reply in a few hours or
> so.
>
> On Tue, Dec 22, 2015 at 01:31:53PM -0200, Fabio Estevam wrote:
>> It seems the information you got from Jon is not correct.
>
> I suspect Jon is in a better position to comment about what works and
> what doesn't, as he's doing the customer facing support for SolidRun,
> and has to deal with people trying to run stock u-boot on SolidRun's
> hardware.
>
> _Especially_ when he gets regular reports from users trying to run
> Fedora 23 on SolidRun platforms, which ships with mainline u-boot,
> and it fails to work because mainline u-boot gets stuff wrong.  The
> telling thing for Jon is that when he gets users to switch to SR's
> u-boot, the problems magically vanish.

That's a good feedback. I will review the DDR3 settings in mainline
U-boot against SolidRun's tree.

> Jon is aware of what's in mainline u-boot, and the memory timings there
> are wrong.  For a start, the highest DDR clock rate is 1066MHz, not
> 1600MHz that you have in mainline u-boot.  So you're overclocking the
> SDRAM.

No, we don't:

    /* Limit mem_speed for MX6D/MX6Q */
    if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D)) {
        if (mem_speed > 1066)
            mem_speed = 1066; /* 1066 MT/s */

> I know that Jon has put a _lot_ of effort into getting the SDRAM setup
> stable on SolidRun hardware to eliminate hangs and other problems, and
> it seems the attitude is "we don't care about that, we're mainline, we
> know better."

Would be wonderful to have these changes upstreamed.

[PATCH] ARM: imx_v6_v7_defconfig: Enable GPU support

[Jon Nettleton]

On Tue, Dec 22, 2015 at 5:38 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Tue, Dec 22, 2015 at 2:16 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> Jon is busy at the moment, and I expect will reply in a few hours or
>> so.
>>
>> On Tue, Dec 22, 2015 at 01:31:53PM -0200, Fabio Estevam wrote:
>>> It seems the information you got from Jon is not correct.
>>
>> I suspect Jon is in a better position to comment about what works and
>> what doesn't, as he's doing the customer facing support for SolidRun,
>> and has to deal with people trying to run stock u-boot on SolidRun's
>> hardware.
>>
>> _Especially_ when he gets regular reports from users trying to run
>> Fedora 23 on SolidRun platforms, which ships with mainline u-boot,
>> and it fails to work because mainline u-boot gets stuff wrong.  The
>> telling thing for Jon is that when he gets users to switch to SR's
>> u-boot, the problems magically vanish.

This is correct.  This first started showing up when Yocto switched to
mainline u-boot and I was getting mysterious reports of boot hangs and
reboot crashes.

>
> That's a good feedback. I will review the DDR3 settings in mainline
> U-boot against SolidRun's tree.
>
>> Jon is aware of what's in mainline u-boot, and the memory timings there
>> are wrong.  For a start, the highest DDR clock rate is 1066MHz, not
>> 1600MHz that you have in mainline u-boot.  So you're overclocking the
>> SDRAM.
>
> No, we don't:
>
>     /* Limit mem_speed for MX6D/MX6Q */
>     if (is_cpu_type(MXC_CPU_MX6Q) || is_cpu_type(MXC_CPU_MX6D)) {
>         if (mem_speed > 1066)
>             mem_speed = 1066; /* 1066 MT/s */

Then why is this setup?

static struct mx6_ddr3_cfg mem_ddr_2g = {
        .mem_speed = 1600,

I don't understand why you force platform vendors to dig through
layers to find some random generic override outside their board file?
Especially when comments like,

/*
 * This section requires the differentiation between Solidrun mx6 boards, but
 * for now, it will configure only for the mx6dual hummingboard version.
 */

are left in.  This inconsistency just makes delving into what is
actually going on in the boot-loader an un-necessary drain of my time
because I have to verify every single bit of abstraction is doing the
correct thing.

>
>> I know that Jon has put a _lot_ of effort into getting the SDRAM setup
>> stable on SolidRun hardware to eliminate hangs and other problems, and
>> it seems the attitude is "we don't care about that, we're mainline, we
>> know better."
>
> Would be wonderful to have these changes upstreamed.

It would be great but I just don't have the time.  I had the time when
upstream was refusing to deal with SPL for the iMX6.  Trying to
migrate to upstream now means I have to rework, and review our entire
patchset of bug fixes.  Not to mention there are 2 more sets of boards
and another microsom that need to be supported and  there is still no
fastboot option for the iMX6 available, and I don't consider falcon
boot an alternative because it is too limited.

I understand a lot of work has been put in to make the iMX6 support
better in u-boot but that was done at the expense of not having
properly QA'd vendor platform support.  So now to get upstream ready
to be used by our customers we need to spend time and money validating
that upstream u-boot works as well as the version we are shipping.  I
am not saying this to complain but to point out that if u-boot wants
to not constantly deal with vendor forks they need to be way more
accepting of vendor input.

Fabio this is no way directed at you.  I appreciate all the work that
you have done.  I just wish it didn't have to be you doing the work.
I would have much rather had this all go upstream back when we were
doing the initial bringup.

-Jon