ARM: imx_v6_v7_defconfig: Enable GPU support

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

---
 arch/arm/configs/imx_v6_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

index 2d5253d..be08ce7 100644
@@ -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

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.

Am Dienstag, den 22.12.2015, 10:30 -0200 schrieb Fabio Estevam:

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

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

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.

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.

Hi Russell and Jon,

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.

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

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

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

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.

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!

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.

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

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 */

Would be wonderful to have these changes upstreamed.

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.

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.

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