| Message ID | 1450723442-1518-1-git-send-email-festevam@gmail.com |
|---|---|
| State | New |
| Headers | show |
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 > >
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.
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
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.
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.
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.
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
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.
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.
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
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
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(+)