| Message ID | 1444504485-25790-1-git-send-email-wsa@the-dreams.de (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 687dfe660a3eddbd40335694beb0896e26b5bbd9 |
| Headers | show |
On Sat, Oct 10, 2015 at 08:14:45PM +0100, Wolfram Sang wrote: > From: Wolfram Sang <wsa+renesas@sang-engineering.com> > > Actviate HDMI output of the RCar DU (and LVDS while we are here). > Enable the HDMI encoder chip found on Lager/Koelsch boards. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Thanks, I have queued this up for v4.4. Is a similar change appropriate for multi_v7_defconfig? -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Is a similar change appropriate for multi_v7_defconfig?
As modules, I'd assume. I'll cook something.
Thanks, Simon.
On Mon, Oct 12, 2015 at 07:38:06AM +0100, Wolfram Sang wrote: > > Is a similar change appropriate for multi_v7_defconfig? > > As modules, I'd assume. I'll cook something. Yes, I think that would be best; thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Wolfram, Thank you for the patch. On Saturday 10 October 2015 20:14:45 Wolfram Sang wrote: > From: Wolfram Sang <wsa+renesas@sang-engineering.com> > > Actviate HDMI output of the RCar DU (and LVDS while we are here). > Enable the HDMI encoder chip found on Lager/Koelsch boards. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > > This is the final bit needed to get HDMI output with an shmobile_defconfig > built kernel. The other bits were renesas-devel-20151008-v4.3-rc4 plus some > I2C patches, which are already in my for-next or soon in my for-current > branches. The complete branch can be found here: > > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git > renesas/rcar-hdmi-output > > Tested with a Lager board and using both I2C/IIC. Based on my testings in > Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch. > Laurent may prove me wrong ;) I've tried to reproduce the problem tonight and couldn't, even without your recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that configuration and make sure to report any issue I can find. > arch/arm/configs/shmobile_defconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/configs/shmobile_defconfig > b/arch/arm/configs/shmobile_defconfig index 0bdeb4925be477..3aef019c0de789 > 100644 > --- a/arch/arm/configs/shmobile_defconfig > +++ b/arch/arm/configs/shmobile_defconfig > @@ -140,7 +140,10 @@ CONFIG_VIDEO_RENESAS_VSP1=y > CONFIG_VIDEO_ADV7180=y > CONFIG_VIDEO_ML86V7667=y > CONFIG_DRM=y > +CONFIG_DRM_I2C_ADV7511=y > CONFIG_DRM_RCAR_DU=y > +CONFIG_DRM_RCAR_HDMI=y > +CONFIG_DRM_RCAR_LVDS=y > CONFIG_FB_SH_MOBILE_LCDC=y > CONFIG_FB_SH_MOBILE_MERAM=y > # CONFIG_LCD_CLASS_DEVICE is not set
> > Tested with a Lager board and using both I2C/IIC. Based on my testings in > > Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch. > > Laurent may prove me wrong ;) > > I've tried to reproduce the problem tonight and couldn't, even without your > recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that > configuration and make sure to report any issue I can find. Thanks for testing! The good news of your message is that HDMI works on Koelsch, too :)
Hi Laurent, On Wed, Oct 14, 2015 at 3:09 AM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: >> Tested with a Lager board and using both I2C/IIC. Based on my testings in >> Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch. >> Laurent may prove me wrong ;) > > I've tried to reproduce the problem tonight and couldn't, even without your > recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that > configuration and make sure to report any issue I can find. The Koelsch that failed has a much newer U-Boot (b653737dfca2), which only enables the MSTP clocks that are really needed, while you and I have much older versions (I have b6af5fcc8dfc). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Geert, On Wed, Oct 14, 2015 at 4:07 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Laurent, > > On Wed, Oct 14, 2015 at 3:09 AM, Laurent Pinchart > <laurent.pinchart@ideasonboard.com> wrote: >>> Tested with a Lager board and using both I2C/IIC. Based on my testings in >>> Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch. >>> Laurent may prove me wrong ;) >> >> I've tried to reproduce the problem tonight and couldn't, even without your >> recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that >> configuration and make sure to report any issue I can find. > > The Koelsch that failed has a much newer U-Boot (b653737dfca2), which > only enables the MSTP clocks that are really needed, while you and I have > much older versions (I have b6af5fcc8dfc). With the new CPG-MSSR driver it should be possible to disable unused MSTP clocks in the kernel during boot without too much trouble, right? Of course it is not something that is needed right away, but DT architecture wise it seems possible to squeeze that in without having to update the DT binding. Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Magnus, On Wed, Oct 14, 2015 at 9:44 AM, Magnus Damm <magnus.damm@gmail.com> wrote: > On Wed, Oct 14, 2015 at 4:07 PM, Geert Uytterhoeven > <geert@linux-m68k.org> wrote: >> On Wed, Oct 14, 2015 at 3:09 AM, Laurent Pinchart >> <laurent.pinchart@ideasonboard.com> wrote: >>>> Tested with a Lager board and using both I2C/IIC. Based on my testings in >>>> Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch. >>>> Laurent may prove me wrong ;) >>> >>> I've tried to reproduce the problem tonight and couldn't, even without your >>> recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that >>> configuration and make sure to report any issue I can find. >> >> The Koelsch that failed has a much newer U-Boot (b653737dfca2), which >> only enables the MSTP clocks that are really needed, while you and I have >> much older versions (I have b6af5fcc8dfc). > > With the new CPG-MSSR driver it should be possible to disable unused > MSTP clocks in the kernel during boot without too much trouble, right? > Of course it is not something that is needed right away, but DT > architecture wise it seems possible to squeeze that in without having > to update the DT binding. Unused clocks are already disabled by the clock framework, but that happens at late_initcall() time, i.e. after i2c probing. Or do you mean disabling them upfront? There are some clocks that must not be disabled. Some of them are not documented. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Geert, On Wed, Oct 14, 2015 at 4:54 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Magnus, > > On Wed, Oct 14, 2015 at 9:44 AM, Magnus Damm <magnus.damm@gmail.com> wrote: >> On Wed, Oct 14, 2015 at 4:07 PM, Geert Uytterhoeven >> <geert@linux-m68k.org> wrote: >>> On Wed, Oct 14, 2015 at 3:09 AM, Laurent Pinchart >>> <laurent.pinchart@ideasonboard.com> wrote: >>>>> Tested with a Lager board and using both I2C/IIC. Based on my testings in >>>>> Dublin with a Koelsch board, I'd be very surprised if it fails with Koelsch. >>>>> Laurent may prove me wrong ;) >>>> >>>> I've tried to reproduce the problem tonight and couldn't, even without your >>>> recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with that >>>> configuration and make sure to report any issue I can find. >>> >>> The Koelsch that failed has a much newer U-Boot (b653737dfca2), which >>> only enables the MSTP clocks that are really needed, while you and I have >>> much older versions (I have b6af5fcc8dfc). >> >> With the new CPG-MSSR driver it should be possible to disable unused >> MSTP clocks in the kernel during boot without too much trouble, right? >> Of course it is not something that is needed right away, but DT >> architecture wise it seems possible to squeeze that in without having >> to update the DT binding. > > Unused clocks are already disabled by the clock framework, but that > happens at late_initcall() time, i.e. after i2c probing. Oh, right.. > Or do you mean disabling them upfront? > There are some clocks that must not be disabled. Some of them are not > documented. Disabling them upfront with sparse documentation seems fun, but also a bit like asking for trouble. =) So disabling clocks upfront may be a troublesome but good way to trigger incorrect dependencies, and unless I'm mistaken it should give the same behaviour as the updated u-boot version, right? Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Magnus, On Wed, Oct 14, 2015 at 10:09 AM, Magnus Damm <magnus.damm@gmail.com> wrote: >> Or do you mean disabling them upfront? >> There are some clocks that must not be disabled. Some of them are not >> documented. > > Disabling them upfront with sparse documentation seems fun, but also a > bit like asking for trouble. =) I have hackish code that does it for all boards I have, and use it actively. > So disabling clocks upfront may be a troublesome but good way to > trigger incorrect dependencies, and unless I'm mistaken it should give > the same behaviour as the updated u-boot version, right? More or less (U-Boot still keeps a few enabled for its own use, e.g. Ethernet). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> The Koelsch that failed has a much newer U-Boot (b653737dfca2), which > only enables the MSTP clocks that are really needed, while you and I have > much older versions (I have b6af5fcc8dfc). What Laurent saw was a 1 byte shift in the transferreed EDID data. So, most likely not a MSTP clock related problem ;)
Hi Geert, On Wed, Oct 14, 2015 at 5:22 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > Hi Magnus, > > On Wed, Oct 14, 2015 at 10:09 AM, Magnus Damm <magnus.damm@gmail.com> wrote: >>> Or do you mean disabling them upfront? >>> There are some clocks that must not be disabled. Some of them are not >>> documented. >> >> Disabling them upfront with sparse documentation seems fun, but also a >> bit like asking for trouble. =) > > I have hackish code that does it for all boards I have, and use it actively. Seems like a good feature to me! >> So disabling clocks upfront may be a troublesome but good way to >> trigger incorrect dependencies, and unless I'm mistaken it should give >> the same behaviour as the updated u-boot version, right? > > More or less (U-Boot still keeps a few enabled for its own use, e.g. Ethernet). So it fails to cleanup after itself then... But by disabling clocks upfront I guess you can be even more aggressive. Anyway, it would be nice to see that feature upstream at some point. Let me know if there is anything I can do to help!! Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Geert, On Wednesday 14 October 2015 09:07:41 Geert Uytterhoeven wrote: > On Wed, Oct 14, 2015 at 3:09 AM, Laurent Pinchart wrote: > >> Tested with a Lager board and using both I2C/IIC. Based on my testings in > >> Dublin with a Koelsch board, I'd be very surprised if it fails with > >> Koelsch. Laurent may prove me wrong ;) > > > > I've tried to reproduce the problem tonight and couldn't, even without > > your recent i2c-rcar patches :-/ I'll keep running tests on Koelsch with > > that configuration and make sure to report any issue I can find. > > The Koelsch that failed has a much newer U-Boot (b653737dfca2), which > only enables the MSTP clocks that are really needed, while you and I have > much older versions (I have b6af5fcc8dfc). It failed on my Koelsch before, and I have never updated U-Boot on it.
On 10/14/2015 3:22 PM, Geert Uytterhoeven wrote: > Hi Magnus, > > On Wed, Oct 14, 2015 at 10:09 AM, Magnus Damm <magnus.damm@gmail.com> wrote: >>> Or do you mean disabling them upfront? >>> There are some clocks that must not be disabled. Some of them are not >>> documented. >> >> Disabling them upfront with sparse documentation seems fun, but also a >> bit like asking for trouble. =) > > I have hackish code that does it for all boards I have, and use it actively. > >> So disabling clocks upfront may be a troublesome but good way to >> trigger incorrect dependencies, and unless I'm mistaken it should give >> the same behaviour as the updated u-boot version, right? > > More or less (U-Boot still keeps a few enabled for its own use, e.g. Ethernet). AFAIK, in some recent versions of Gen2 BSP, all the devices (including all devices enabled by u-boot for its processing, like Ethernet, TMU, serial) will be turned off right before jumping to kernel start address. > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds > -- > To unsubscribe from this list: send the line "unsubscribe linux-sh" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 14 October 2015 19:11:12 Khiem Nguyen wrote: > On 10/14/2015 3:22 PM, Geert Uytterhoeven wrote: > > On Wed, Oct 14, 2015 at 10:09 AM, Magnus Damm wrote: > >>> Or do you mean disabling them upfront? > >>> There are some clocks that must not be disabled. Some of them are not > >>> documented. > >> > >> Disabling them upfront with sparse documentation seems fun, but also a > >> bit like asking for trouble. =) > > > > I have hackish code that does it for all boards I have, and use it > > actively. > > > >> So disabling clocks upfront may be a troublesome but good way to > >> trigger incorrect dependencies, and unless I'm mistaken it should give > >> the same behaviour as the updated u-boot version, right? > > > > More or less (U-Boot still keeps a few enabled for its own use, e.g. > > Ethernet). > > AFAIK, in some recent versions of Gen2 BSP, all the devices (including > all devices enabled by u-boot for its processing, like Ethernet, TMU, > serial) will be turned off right before jumping to kernel start address. Would it make sense to keep the serial port enabled in order to support early printk ?
On 10/14/2015 7:55 PM, Laurent Pinchart wrote: > On Wednesday 14 October 2015 19:11:12 Khiem Nguyen wrote: >> On 10/14/2015 3:22 PM, Geert Uytterhoeven wrote: >>> On Wed, Oct 14, 2015 at 10:09 AM, Magnus Damm wrote: >>>>> Or do you mean disabling them upfront? >>>>> There are some clocks that must not be disabled. Some of them are not >>>>> documented. >>>> >>>> Disabling them upfront with sparse documentation seems fun, but also a >>>> bit like asking for trouble. =) >>> >>> I have hackish code that does it for all boards I have, and use it >>> actively. >>> >>>> So disabling clocks upfront may be a troublesome but good way to >>>> trigger incorrect dependencies, and unless I'm mistaken it should give >>>> the same behaviour as the updated u-boot version, right? >>> >>> More or less (U-Boot still keeps a few enabled for its own use, e.g. >>> Ethernet). >> >> AFAIK, in some recent versions of Gen2 BSP, all the devices (including >> all devices enabled by u-boot for its processing, like Ethernet, TMU, >> serial) will be turned off right before jumping to kernel start address. > > Would it make sense to keep the serial port enabled in order to support early > printk ? > I don't think early printk is supported in Gen2 BSP, which is base on LTSI 3.10. Geert has introduced early printk support for Gen2 in Nov 2014. Maybe, we need to consider this point for Gen3. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Oct 14, 2015 at 3:18 PM, Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com> wrote: >>> AFAIK, in some recent versions of Gen2 BSP, all the devices (including >>> all devices enabled by u-boot for its processing, like Ethernet, TMU, >>> serial) will be turned off right before jumping to kernel start address. >> >> Would it make sense to keep the serial port enabled in order to support >> early >> printk ? >> > > I don't think early printk is supported in Gen2 BSP, which is base on LTSI > 3.10. > Geert has introduced early printk support for Gen2 in Nov 2014. > > Maybe, we need to consider this point for Gen3. INTC-RT, MFIS, INTC-SYS, IRQC, and SCIF0 are left enabled, according to the U-Boot sources. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/14/2015 8:32 PM, Geert Uytterhoeven wrote: > On Wed, Oct 14, 2015 at 3:18 PM, Khiem Nguyen > <khiem.nguyen.xt@rvc.renesas.com> wrote: >>>> AFAIK, in some recent versions of Gen2 BSP, all the devices (including >>>> all devices enabled by u-boot for its processing, like Ethernet, TMU, >>>> serial) will be turned off right before jumping to kernel start address. >>> >>> Would it make sense to keep the serial port enabled in order to support >>> early >>> printk ? >>> >> >> I don't think early printk is supported in Gen2 BSP, which is base on LTSI >> 3.10. >> Geert has introduced early printk support for Gen2 in Nov 2014. >> >> Maybe, we need to consider this point for Gen3. > > INTC-RT, MFIS, INTC-SYS, IRQC, and SCIF0 are left enabled, according > to the U-Boot sources. Yes, you are right. Above devices were left enabled. Especially, some interrupt controller devices need to keep ON to ensure system operation while transferring to kernel boot. > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds > -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig index 0bdeb4925be477..3aef019c0de789 100644 --- a/arch/arm/configs/shmobile_defconfig +++ b/arch/arm/configs/shmobile_defconfig @@ -140,7 +140,10 @@ CONFIG_VIDEO_RENESAS_VSP1=y CONFIG_VIDEO_ADV7180=y CONFIG_VIDEO_ML86V7667=y CONFIG_DRM=y +CONFIG_DRM_I2C_ADV7511=y CONFIG_DRM_RCAR_DU=y +CONFIG_DRM_RCAR_HDMI=y +CONFIG_DRM_RCAR_LVDS=y CONFIG_FB_SH_MOBILE_LCDC=y CONFIG_FB_SH_MOBILE_MERAM=y # CONFIG_LCD_CLASS_DEVICE is not set