viafb: Do not probe for LVDS/TMDS on OLPC XO-1.5
in [Kernel]
|
Prev: jump label: sort jump table at build-time
Next: suppress verbose debug messages: change printk() to DEBUG_MSG()
From: Florian Tobias Schandinat on 9 Apr 2010 17:50 Jonathan Corbet schrieb: > From: Chris Ball <cjb(a)laptop.org> > > The i2c transactions involved in detecting LVDS (9 seconds) and TMDS > (16 seconds) add an extra 25 seconds to viafb load time on the XO-1.5. I don't like the idea of OLPC specific code. Isn't there any way to speed this up in general? There is not yet even an option for OLPC_XO_1_5 (in contrast to CONFIG_OLPC) in mainline. Is such a thing planned? I can't really see anything that would speak for accepting this patch now in current mainline, sorry. Thanks, Florian Tobias Schandinat > [jc: minor merge conflict fixed] > Signed-off-by: Chris Ball <cjb(a)laptop.org> > --- > drivers/video/via/hw.c | 4 ++++ > drivers/video/via/lcd.c | 4 ++++ > 2 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c > index 7be462e..47ba09a 100644 > --- a/drivers/video/via/hw.c > +++ b/drivers/video/via/hw.c > @@ -2054,6 +2054,10 @@ static void init_gfx_chip_info(struct pci_dev *pdev, > > static void init_tmds_chip_info(void) > { > +#ifdef CONFIG_OLPC_XO_1_5 > + if (machine_is_olpc()) > + return; > +#endif > viafb_tmds_trasmitter_identify(); > > if (INTERFACE_NONE == viaparinfo->chip_info->tmds_chip_info. > diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c > index e0e2310..37a9746 100644 > --- a/drivers/video/via/lcd.c > +++ b/drivers/video/via/lcd.c > @@ -208,6 +208,10 @@ static bool lvds_identify_integratedlvds(void) > > int viafb_lvds_trasmitter_identify(void) > { > +#ifdef CONFIG_OLPC_XO_1_5 > + if (machine_is_olpc()) > + return FAIL; > +#endif > viaparinfo->shared->i2c_stuff.i2c_port = I2CPORTINDEX; > if (viafb_lvds_identify_vt1636()) { > viaparinfo->chip_info->lvds_chip_info.i2c_port = I2CPORTINDEX; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jonathan Corbet on 9 Apr 2010 20:30 On Fri, 09 Apr 2010 23:40:55 +0200 Florian Tobias Schandinat <FlorianSchandinat(a)gmx.de> wrote: > I don't like the idea of OLPC specific code. Isn't there any way to > speed this up in general? Architecture-specific code happens. OLPCs are wired differently; if you go trying to do LVDS out those GPIO ports on an OLPC, you'll not end up talking to the hardware you think you're talking to. The best thing to do is to avoid it altogether. > There is not yet even an option for OLPC_XO_1_5 (in contrast to > CONFIG_OLPC) in mainline. Is such a thing planned? Yes, it is. That's part of the remaining OLPC support code which has also been brought forward to 2.6.34 with the intention of mainlining it. > I can't really see anything that would speak for accepting this patch > now in current mainline, sorry. If you can come up with a better solution to the problem, I'm all ears. But without it you'll have a hard time running mainline kernels on XO 1.5 systems. It is all coming, but the OLPC folks are scrambling to get everything together; I don't think we really need to make things harder for them. That said, machine_is_olpc() is properly defined for all configurations, so the #ifdefs can (and should) come out. jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Tobias Schandinat on 9 Apr 2010 20:50 Jonathan Corbet schrieb: > On Fri, 09 Apr 2010 23:40:55 +0200 > Florian Tobias Schandinat <FlorianSchandinat(a)gmx.de> wrote: > >> I don't like the idea of OLPC specific code. Isn't there any way to >> speed this up in general? > > Architecture-specific code happens. OLPCs are wired differently; if > you go trying to do LVDS out those GPIO ports on an OLPC, you'll not > end up talking to the hardware you think you're talking to. The best > thing to do is to avoid it altogether. *sigh* I feared it would be something like this. >> There is not yet even an option for OLPC_XO_1_5 (in contrast to >> CONFIG_OLPC) in mainline. Is such a thing planned? > > Yes, it is. That's part of the remaining OLPC support code which has > also been brought forward to 2.6.34 with the intention of mainlining it. > >> I can't really see anything that would speak for accepting this patch >> now in current mainline, sorry. > > If you can come up with a better solution to the problem, I'm all > ears. But without it you'll have a hard time running mainline kernels > on XO 1.5 systems. It is all coming, but the OLPC folks are scrambling > to get everything together; I don't think we really need to make things > harder for them. Sadly no as you probably know the OLPC hardware much better than me. However I do not intend to give the OLPC folks a hard time. > That said, machine_is_olpc() is properly defined for all > configurations, so the #ifdefs can (and should) come out. I'm not sure I get you right here. If you talk about removing the defines and only letting the machine check that is something that I would accept now. If this is not what you meant I think it would be better to move this patch to the series adding the config option. Thanks, Florian Tobias Schandinat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jonathan Corbet on 9 Apr 2010 21:00 On Sat, 10 Apr 2010 02:42:52 +0200 Florian Tobias Schandinat <FlorianSchandinat(a)gmx.de> wrote: > > That said, machine_is_olpc() is properly defined for all > > configurations, so the #ifdefs can (and should) come out. > > I'm not sure I get you right here. If you talk about removing the > defines and only letting the machine check that is something that I > would accept now. Yes, that is what I mean; the ifdefs don't need to be there. Had I thought that through I would have removed them before posting the patch. jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Harald Welte on 10 Apr 2010 03:10
Hi Florian, On Fri, Apr 09, 2010 at 11:40:55PM +0200, Florian Tobias Schandinat wrote: > >The i2c transactions involved in detecting LVDS (9 seconds) and TMDS > >(16 seconds) add an extra 25 seconds to viafb load time on the XO-1.5. > > I don't like the idea of OLPC specific code. Isn't there any way to > speed this up in general? I'm quite sure it can be sped up at least a bit... however: > There is not yet even an option for OLPC_XO_1_5 (in contrast to > CONFIG_OLPC) in mainline. Is such a thing planned? > I can't really see anything that would speak for accepting this > patch now in current mainline, sorry. I think there is little choice in this matter. It is a _very_ uncommon hardware design decision to attach anything but the DDC to one of the I2C ports of the graphics chip, and the assumption that there is only DDC connected is made in VIA's BIOS (not used in OLPC), the linux framebuffer driver, as well as VIA's own Xorg driver and I believe as well in OpenChrome, too :( OLPC has told me that the particular chip that is attached to I2C is also very timing sensitive and not 100% I2C compliant, so I think it is the safe choice to not try to do DDC on that port for the OLPC 1.5. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |