[PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Daniel Drake]

The OLPC XO-1.5 does not use the standard port wiring suggested
in the viafb driver.

This is required for the upcoming OLPC DCON and via-camera drivers,
to be submitted soon.

Signed-off-by: Daniel Drake <dsd@laptop.org>
---
 drivers/video/via/via-core.c |   25 +++++++++++++++++++++++++
 1 files changed, 25 insertions(+), 0 deletions(-)

diff --git a/drivers/video/via/via-core.c b/drivers/video/via/via-core.c
index 08390fe..a0efb8f 100644
--- a/drivers/video/via/via-core.c
+++ b/drivers/video/via/via-core.c
@@ -16,6 +16,10 @@
 #include <linux/interrupt.h>
 #include <linux/platform_device.h>
 
+#ifdef CONFIG_OLPC
+#include <asm/olpc.h>
+#endif
+
 /*
  * The default port config.
  */
@@ -28,6 +32,21 @@ static const struct via_port_cfg adap_configs[] = {
 	{ 0, 0, 0, 0 }
 };
 
+#ifdef CONFIG_OLPC
+/*
+ * The OLPC XO-1.5 puts the camera power and reset lines onto
+ * GPIO 2C.  The configuration for 26 is also modified.
+ */
+static const struct via_port_cfg olpc_adap_configs[] = {
+	[VIA_PORT_26]	= { VIA_PORT_I2C,  VIA_MODE_I2C, VIASR, 0x26 },
+	[VIA_PORT_31]	= { VIA_PORT_I2C,  VIA_MODE_I2C, VIASR, 0x31 },
+	[VIA_PORT_25]	= { VIA_PORT_GPIO, VIA_MODE_GPIO, VIASR, 0x25 },
+	[VIA_PORT_2C]	= { VIA_PORT_GPIO, VIA_MODE_GPIO, VIASR, 0x2c },
+	[VIA_PORT_3D]	= { VIA_PORT_GPIO, VIA_MODE_GPIO, VIASR, 0x3d },
+	{ 0, 0, 0, 0 }
+};
+#endif
+
 /*
  * We currently only support one viafb device (will there ever be
  * more than one?), so just declare it globally here.
@@ -575,6 +594,12 @@ static int __devinit via_pci_probe(struct pci_dev *pdev,
 	global_dev.pdev = pdev;
 	global_dev.chip_type = ent->driver_data;
 	global_dev.port_cfg = adap_configs;
+
+#ifdef CONFIG_OLPC
+	if (machine_is_olpc())
+		global_dev.port_cfg = olpc_adap_configs;
+#endif
+
 	spin_lock_init(&global_dev.reg_lock);
 	ret = via_pci_setup_mmio(&global_dev);
 	if (ret)
-- 
1.7.2.2

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Florian Tobias Schandinat]

Daniel Drake schrieb:
> The OLPC XO-1.5 does not use the standard port wiring suggested
> in the viafb driver.
> 
> This is required for the upcoming OLPC DCON and via-camera drivers,
> to be submitted soon.

Why? What happens if this patch is not applied?
Please understand, that I, as a maintainer, try to avoid platform specific code 
as much as possible so a little explanation would be good.


Thanks,

Florian Tobias Schandinat

> Signed-off-by: Daniel Drake <dsd@laptop.org>
> ---
>  drivers/video/via/via-core.c |   25 +++++++++++++++++++++++++
>  1 files changed, 25 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/video/via/via-core.c b/drivers/video/via/via-core.c
> index 08390fe..a0efb8f 100644
> --- a/drivers/video/via/via-core.c
> +++ b/drivers/video/via/via-core.c
> @@ -16,6 +16,10 @@
>  #include <linux/interrupt.h>
>  #include <linux/platform_device.h>
>  
> +#ifdef CONFIG_OLPC
> +#include <asm/olpc.h>
> +#endif
> +
>  /*
>   * The default port config.
>   */
> @@ -28,6 +32,21 @@ static const struct via_port_cfg adap_configs[] = {
>  	{ 0, 0, 0, 0 }
>  };
>  
> +#ifdef CONFIG_OLPC
> +/*
> + * The OLPC XO-1.5 puts the camera power and reset lines onto
> + * GPIO 2C.  The configuration for 26 is also modified.
> + */
> +static const struct via_port_cfg olpc_adap_configs[] = {
> +	[VIA_PORT_26]	= { VIA_PORT_I2C,  VIA_MODE_I2C, VIASR, 0x26 },
> +	[VIA_PORT_31]	= { VIA_PORT_I2C,  VIA_MODE_I2C, VIASR, 0x31 },
> +	[VIA_PORT_25]	= { VIA_PORT_GPIO, VIA_MODE_GPIO, VIASR, 0x25 },
> +	[VIA_PORT_2C]	= { VIA_PORT_GPIO, VIA_MODE_GPIO, VIASR, 0x2c },
> +	[VIA_PORT_3D]	= { VIA_PORT_GPIO, VIA_MODE_GPIO, VIASR, 0x3d },
> +	{ 0, 0, 0, 0 }
> +};
> +#endif
> +
>  /*
>   * We currently only support one viafb device (will there ever be
>   * more than one?), so just declare it globally here.
> @@ -575,6 +594,12 @@ static int __devinit via_pci_probe(struct pci_dev *pdev,
>  	global_dev.pdev = pdev;
>  	global_dev.chip_type = ent->driver_data;
>  	global_dev.port_cfg = adap_configs;
> +
> +#ifdef CONFIG_OLPC
> +	if (machine_is_olpc())
> +		global_dev.port_cfg = olpc_adap_configs;
> +#endif
> +
>  	spin_lock_init(&global_dev.reg_lock);
>  	ret = via_pci_setup_mmio(&global_dev);
>  	if (ret)

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Daniel Drake]

On 21 September 2010 18:15, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> Why? What happens if this patch is not applied?
> Please understand, that I, as a maintainer, try to avoid platform specific
> code as much as possible so a little explanation would be good.

Without the patch, the GPIO/I2C lines are not set up correctly so
we're unable to access the hardware connected there.

Daniel

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Florian Tobias Schandinat]

(cc'ed Jon)

Daniel Drake schrieb:
> On 21 September 2010 18:15, Florian Tobias Schandinat
> <FlorianSchandinat@gmx.de> wrote:
>> Why? What happens if this patch is not applied?
>> Please understand, that I, as a maintainer, try to avoid platform specific
>> code as much as possible so a little explanation would be good.
> 
> Without the patch, the GPIO/I2C lines are not set up correctly so
> we're unable to access the hardware connected there.

*after a deeper look at the patch*
Hm, one of my patches enables 0x26 also as I2C. So the only difference between 
the current config and your config is whether 0x2c is GPIO or I2C where your 
version make a lot more sense.
Jon, do you agree that this should become the default config?
Handling a GPIO device as such and not as an I2C device sounds right to me, 
although we have to take care about the old code which is doing so.


Thanks,

Florian Tobias Schandinat

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Daniel Drake]

On 21 September 2010 18:54, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> *after a deeper look at the patch*
> Hm, one of my patches enables 0x26 also as I2C. So the only difference
> between the current config and your config is whether 0x2c is GPIO or I2C
> where your version make a lot more sense.
> Jon, do you agree that this should become the default config?
> Handling a GPIO device as such and not as an I2C device sounds right to me,
> although we have to take care about the old code which is doing so.

Jon, ping :)

Something possibly of relevance:
In addition to enabling the camera and DCON, changing the port config
of 0x2c from VIA_MODE_I2C to VIA_MODE_GPIO makes a fairly substantial
difference in the viafb init paths for XO-1.5.

On linus master, before making the change in my patch, viafb init
takes a long time, maybe 10 seconds. With linux-next 20100924, it
takes 2.5 seconds. After the patch, it takes 0.07 seconds.

Timings from linux-next:

[    1.021495] VIA Graphics Intergration Chipset framebuffer 2.4 initializing
[    1.029309] viafb 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    2.970023] viafb_init_dvi_size: DVI panel size undetected!
[    3.475728] Console: switching to colour frame buffer device 100x40

And from the same kernel with the port config adjusted:

[    1.025436] VIA Graphics Intergration Chipset framebuffer 2.4 initializing
[    1.033234] viafb 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    1.057799] viafb_init_dvi_size: DVI panel size undetected!
[    1.090548] Console: switching to colour frame buffer device 100x40

So, changing this value makes a pretty significant difference. If you
changed it globally I'm wondering if you'd be breaking current non-XO
systems, for example you'd be presumably affecting the behaviour of
viafb_lvds_trasmitter_identify()

At the same time, I don't fully understand what these port configs
actually are, so I might be far off point.

Daniel

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Florian Tobias Schandinat]

Daniel Drake schrieb:
> On 21 September 2010 18:54, Florian Tobias Schandinat
> <FlorianSchandinat@gmx.de> wrote:
>> *after a deeper look at the patch*
>> Hm, one of my patches enables 0x26 also as I2C. So the only difference
>> between the current config and your config is whether 0x2c is GPIO or I2C
>> where your version make a lot more sense.
>> Jon, do you agree that this should become the default config?
>> Handling a GPIO device as such and not as an I2C device sounds right to me,
>> although we have to take care about the old code which is doing so.
> 
> Jon, ping :)
> 
> Something possibly of relevance:
> In addition to enabling the camera and DCON, changing the port config
> of 0x2c from VIA_MODE_I2C to VIA_MODE_GPIO makes a fairly substantial
> difference in the viafb init paths for XO-1.5.
> 
> On linus master, before making the change in my patch, viafb init
> takes a long time, maybe 10 seconds. With linux-next 20100924, it
> takes 2.5 seconds. After the patch, it takes 0.07 seconds.
> 
> Timings from linux-next:
> 
> [    1.021495] VIA Graphics Intergration Chipset framebuffer 2.4 initializing
> [    1.029309] viafb 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [    2.970023] viafb_init_dvi_size: DVI panel size undetected!
> [    3.475728] Console: switching to colour frame buffer device 100x40
> 
> And from the same kernel with the port config adjusted:
> 
> [    1.025436] VIA Graphics Intergration Chipset framebuffer 2.4 initializing
> [    1.033234] viafb 0000:00:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [    1.057799] viafb_init_dvi_size: DVI panel size undetected!
> [    1.090548] Console: switching to colour frame buffer device 100x40
> 
> So, changing this value makes a pretty significant difference. If you
> changed it globally I'm wondering if you'd be breaking current non-XO
> systems, for example you'd be presumably affecting the behaviour of
> viafb_lvds_trasmitter_identify()

You're right, we may not only change the entry. The device code also needs to be 
changed. The situation is like this:
0x2c are essentially two GPIO ports but those can be used to emulate one I2C 
port. At the moment it is only used as I2C port with a little hack in the I2C 
code. I believe it would be good to change it to always be a GPIO port (as that 
is what it really is, at least for all documented IGPs) and emulate I2C on top 
of that if needed. Sadly VIAs emulation (using 2 pins) differs from the generic 
one in i2c-gpio.c (using 1 pin), so we can't reuse that but the emulation code 
shouldn't be much code anyway.
I hope that this change is simple enough to get it right without testing as I 
don't have any device with a I2C device on port 0x2c.
But I hope we can get a bit faster than 2.5 seconds.


Regards,

Florian Tobias Schandinat

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Daniel Drake]

On 26 September 2010 16:50, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> You're right, we may not only change the entry. The device code also needs
> to be changed. The situation is like this:
> 0x2c are essentially two GPIO ports but those can be used to emulate one I2C
> port. At the moment it is only used as I2C port with a little hack in the
> I2C code. I believe it would be good to change it to always be a GPIO port
> (as that is what it really is, at least for all documented IGPs) and emulate
> I2C on top of that if needed. Sadly VIAs emulation (using 2 pins) differs
> from the generic one in i2c-gpio.c (using 1 pin), so we can't reuse that but
> the emulation code shouldn't be much code anyway.
> I hope that this change is simple enough to get it right without testing as
> I don't have any device with a I2C device on port 0x2c.
> But I hope we can get a bit faster than 2.5 seconds.

Either way, we need to change it for the XO-1.5 for camera and DCON support.

Would it be possible to take something similar to the patch that I
posted earlier, until the changes you describe above are made?

Thanks,
Daniel

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Jonathan Corbet]

Sorry if I'm slow...*you* try giving talks in Germany and Japan in the
same week and we'll see how responsive you are...:)

On Sun, 26 Sep 2010 17:50:41 +0200
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:

> You're right, we may not only change the entry. The device code also needs to be 
> changed. The situation is like this:
> 0x2c are essentially two GPIO ports but those can be used to emulate one I2C 
> port. At the moment it is only used as I2C port with a little hack in the I2C 
> code. I believe it would be good to change it to always be a GPIO port (as that 
> is what it really is, at least for all documented IGPs) and emulate I2C on top 
> of that if needed. Sadly VIAs emulation (using 2 pins) differs from the generic 
> one in i2c-gpio.c (using 1 pin), so we can't reuse that but the emulation code 
> shouldn't be much code anyway.

When I first set up the GPIO/I2C code, I tried to configure it "the way
it's always been," in the hope of not breaking anything.  I'd always
figured that people would want to change things, which is why the code
is done the way it is.  Of course, I never got around to implementing
the configuration-time (or even runtime) selection mechanism.  But I
did always figure that OLPC would need a non-standard configuration.

Florian, I'm not sure what you're saying about changing how the ports
are used.  All of the ports are essentially the same, regardless of
what they are called; you either have two GPIOs, or you have one for
i2c data, the other for the clock.  There are some minor differences in
how the ports are programmed, but it's pretty much insignificant.

Daniel, 0x2C *has* to be GPIO on the XO - that's the power/reset pair
for the camera sensor.  That's a little non-standard; I think normal
configurations use it for (i2c) communications to the monitor.  So I
think I understand what you're seeing: if the port is i2c, the driver
tries (unsuccessfully) to talk over it, confusing the camera in the
process.  If it's GPIO, those attempts fail immediately and it moves on.

Make sense?

jon

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Florian Tobias Schandinat]

Hi Jon,

Jonathan Corbet schrieb:
> Sorry if I'm slow...*you* try giving talks in Germany and Japan in the
> same week and we'll see how responsive you are...:)
> 
> On Sun, 26 Sep 2010 17:50:41 +0200
> Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
> 
>> You're right, we may not only change the entry. The device code also needs to be 
>> changed. The situation is like this:
>> 0x2c are essentially two GPIO ports but those can be used to emulate one I2C 
>> port. At the moment it is only used as I2C port with a little hack in the I2C 
>> code. I believe it would be good to change it to always be a GPIO port (as that 
>> is what it really is, at least for all documented IGPs) and emulate I2C on top 
>> of that if needed. Sadly VIAs emulation (using 2 pins) differs from the generic 
>> one in i2c-gpio.c (using 1 pin), so we can't reuse that but the emulation code 
>> shouldn't be much code anyway.
> 
> When I first set up the GPIO/I2C code, I tried to configure it "the way
> it's always been," in the hope of not breaking anything.  I'd always
> figured that people would want to change things, which is why the code
> is done the way it is.  Of course, I never got around to implementing
> the configuration-time (or even runtime) selection mechanism.  But I
> did always figure that OLPC would need a non-standard configuration.
> 
> Florian, I'm not sure what you're saying about changing how the ports
> are used.  All of the ports are essentially the same, regardless of
> what they are called; you either have two GPIOs, or you have one for
> i2c data, the other for the clock.  There are some minor differences in
> how the ports are programmed, but it's pretty much insignificant.

Jon, do you claim that 0x26 and 0x31 are essentially the same as the the GPIO ports?
I am no specialist on this but this is how I understand the GPIO pins work:
Each pin has one status, data and output enable bit. As long as output enable is
set (not set to 0) the pin is actively driven high or low depending on what is
in the data bit. Reading the status bit while output enable is set is pretty
senseless as we either read what we write or (on bus collision) the result is
undefined. Reading when output enable is not set works as expected.
In contrast I2C is defined with a bus voltage and we have only the possibility
to drive the pins low or tristated. When tristated we can read the bus (high if
no other/slave devices drives it low).
After having a look at the relevant openchrome code (ViaI2C3):
http://openchrome.org/trac/browser/trunk/src/via_i2c.c
as well as VIAs X-Server (as far as I can decipher it) and assuming that this 
code was tested I am confident that our code is broken (for example we never set 
output enable back to 0). So I think we should just enable GPIO on that port as 
I2C on it looks very broken anyway.
I plan to test whether a correct implementation can be done on top of GPIO. 
That's probably just for the get_* functions set the direction to input,
read the bit and return (maybe setting up an open drain as described in gpio.txt 
before all this), for set_* functions set the direction to output with
the desired value and return.
The only problem I have is that I probably do not have a way to actually test 
whether the end result works, but maybe I'm lucky and suddenly a device will be 
detected that currently is not.


Thanks,

Florian Tobias Schandinat

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Jonathan Corbet]

Slow response, sorry.  Happily, I'm actually done crossing oceans for a
little bit...

On Mon, 27 Sep 2010 06:55:16 +0200
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:

> Jon, do you claim that 0x26 and 0x31 are essentially the same as the the GPIO ports?

From a programming point of view, yes.  There may be some electrical
differences.

> After having a look at the relevant openchrome code (ViaI2C3):
> http://openchrome.org/trac/browser/trunk/src/via_i2c.c
> as well as VIAs X-Server (as far as I can decipher it) and assuming that this 
> code was tested I am confident that our code is broken (for example we never set 
> output enable back to 0). So I think we should just enable GPIO on that port as 
> I2C on it looks very broken anyway.

I'm confused...you're talking about 26/31 still?

I2c works fine on 0x31; that's how the via-camera driver talks to the
sensor.

> I plan to test whether a correct implementation can be done on top of GPIO. 

You could do that, but, if you look at what's there, that's essentially
what's done now - it's a bitbanging driver.  So I'm not quite sure what
you would change.

Sorry if I'm being slow.

jon

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Daniel Drake]

On 26 September 2010 22:52, Jonathan Corbet <corbet@lwn.net> wrote:
> Daniel, 0x2C *has* to be GPIO on the XO - that's the power/reset pair
> for the camera sensor.  That's a little non-standard; I think normal
> configurations use it for (i2c) communications to the monitor.  So I
> think I understand what you're seeing: if the port is i2c, the driver
> tries (unsuccessfully) to talk over it, confusing the camera in the
> process.  If it's GPIO, those attempts fail immediately and it moves on.

You may be right, but I've identified a more prominent reason why
via-camera fails to initialize:

Linux currently has port 0x2C as VIA_MODE_I2C in via-core.c.
During initialization, via-gpio.c iterates over all ports and ignores
the ones that are not VIA_MODE_GPIO.
So 0x2c is ignored by via-gpio since it is marked as I2C. As you point
out, the GPIOs we need are behind 0x2c, so they are never
probed/enabled.

Florian, the via-camera driver is in linux-next and the maintainer
indicates it'll go to Linus within a day or 2.
This is the last issue preventing the driver from working on XO-1.5.
Do you have any thoughts on our next steps?

Thanks,
Daniel

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Jonathan Corbet]

On Wed, 27 Oct 2010 16:08:54 +0100
Daniel Drake <dsd@laptop.org> wrote:

> Linux currently has port 0x2C as VIA_MODE_I2C in via-core.c.
> During initialization, via-gpio.c iterates over all ports and ignores
> the ones that are not VIA_MODE_GPIO.
> So 0x2c is ignored by via-gpio since it is marked as I2C. As you point
> out, the GPIOs we need are behind 0x2c, so they are never
> probed/enabled.
> 
> Florian, the via-camera driver is in linux-next and the maintainer
> indicates it'll go to Linus within a day or 2.
> This is the last issue preventing the driver from working on XO-1.5.
> Do you have any thoughts on our next steps?

...and now it's in mainline at last.  That took rather longer than I
had expected.

I had always figured that the default settings for those ports would
not suit everybody; it was just a matter of how they could be
customized.  Options would seem to be:

 - OLPC carries a small patch which configures the port properly.

 - A set of configuration options is added allowing the port type to be
   set when the kernel is configured.

 - The ports could be changed from the default configuration with a
   boot-time command-line option.

That last option might be what works best for OLPC; those systems seem
to need several lines of special boot options anyway.  It wouldn't be
that hard to hack up...anybody got a better idea?

(Of course, option 4 is "OLPC doesn't repurpose i2c ports in strange
ways, but I figured it's a bit late for that one :)

jon

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Daniel Drake]

On 28 October 2010 19:51, Jonathan Corbet <corbet@lwn.net> wrote:
> I had always figured that the default settings for those ports would
> not suit everybody; it was just a matter of how they could be
> customized.  Options would seem to be:
>
>  - OLPC carries a small patch which configures the port properly.

I'm trying to get generic distro kernels to work, so not so keen on this one

>  - A set of configuration options is added allowing the port type to be
>   set when the kernel is configured.

ditto

>  - The ports could be changed from the default configuration with a
>   boot-time command-line option.
> That last option might be what works best for OLPC; those systems seem
> to need several lines of special boot options anyway.  It wouldn't be
> that hard to hack up...anybody got a better idea?

I'm hoping to get rid of that requirement for the reasons above, and
I'm wondering if we've already got that far (Florian said he had it
booting on his XO-1.5, although maybe he figured out the magic
parameters and is using them)...

So I don't really like any of these solutions. I think we should
program this info from inside the kernel (like in my original patch,
although I'm open for nicer ways to do the same thing)

Daniel

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Jonathan Corbet]

On Thu, 28 Oct 2010 22:54:23 +0100
Daniel Drake <dsd@laptop.org> wrote:

> So I don't really like any of these solutions. I think we should
> program this info from inside the kernel (like in my original patch,
> although I'm open for nicer ways to do the same thing)

Could you refresh my memory on that original patch?

I guess we could put something into the via-core initialization that
says:

	if (machine_is_olpc())
		turn_02c_to_gpio();

That covers only your case, and not that of anybody else who will have
wired up a board differently, but we can let them generalize it when
they run into trouble :)

Objections to that approach?

jon

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Daniel Drake]

On 28 October 2010 23:04, Jonathan Corbet <corbet@lwn.net> wrote:
> Could you refresh my memory on that original patch?
>
> I guess we could put something into the via-core initialization that
> says:
>
>        if (machine_is_olpc())
>                turn_02c_to_gpio();
>
> That covers only your case, and not that of anybody else who will have
> wired up a board differently, but we can let them generalize it when
> they run into trouble :)

Thats pretty much what I posted:
http://www.spinics.net/lists/linux-fbdev/msg01681.html

I now realise that all the #ifdefs are unnecessary, the code should be
there unconditionally and the compiler will remove it on non-OLPC
kernels.

The other option we have is to detect the XO-1.5 using DMI. That's the
more conventional way of detecting a specific platform in the kernel.
Florian, what do you think?

Daniel

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Daniel Drake]

On 29 October 2010 15:03, Daniel Drake <dsd@laptop.org> wrote:
> I now realise that all the #ifdefs are unnecessary, the code should be
> there unconditionally and the compiler will remove it on non-OLPC
> kernels.
>
> The other option we have is to detect the XO-1.5 using DMI. That's the
> more conventional way of detecting a specific platform in the kernel.
> Florian, what do you think?

Bump

Florian, still hoping for your input on this, and a review of the S/R
infrastructure patches posted recently.

Thanks,
Daniel

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Florian Tobias Schandinat]

Hi,

Daniel Drake schrieb:
> On 29 October 2010 15:03, Daniel Drake <dsd@laptop.org> wrote:
>> I now realise that all the #ifdefs are unnecessary, the code should be
>> there unconditionally and the compiler will remove it on non-OLPC
>> kernels.
>>
>> The other option we have is to detect the XO-1.5 using DMI. That's the
>> more conventional way of detecting a specific platform in the kernel.
>> Florian, what do you think?
> 
> Bump
> 
> Florian, still hoping for your input on this, and a review of the S/R
> infrastructure patches posted recently.

sorry for the delay, but I'm very busy at the moment.
I already pushed those patches forward to my -next branch and it should be in 
the linux-next branch of today.
I'm still not happy with how GPIO or more precisely I2C on GPIO ports is 
handled. But given that I don't have much time at the moment and that there are 
more important things in viafb that require work and most important that I don't 
see any opportunity/hardware to test whether the current (or an alternative) 
implementation allows I2C devices work on port 2C pushing this patch forward 
seems reasonable. I only removed the #ifdefs as you suggested in your last email 
to make the code more readable.
The other two patches were good.


Thanks,

Florian Tobias Schandinat

Re: [PATCH 2/2] viafb: Add OLPC XO-1.5 port configs

[Daniel Drake]

On 11 November 2010 16:01, Florian Tobias Schandinat
<FlorianSchandinat@gmx.de> wrote:
> sorry for the delay, but I'm very busy at the moment.
> I already pushed those patches forward to my -next branch and it should be
> in the linux-next branch of today.
> I'm still not happy with how GPIO or more precisely I2C on GPIO ports is
> handled. But given that I don't have much time at the moment and that there
> are more important things in viafb that require work and most important that
> I don't see any opportunity/hardware to test whether the current (or an
> alternative) implementation allows I2C devices work on port 2C pushing this
> patch forward seems reasonable. I only removed the #ifdefs as you suggested
> in your last email to make the code more readable.
> The other two patches were good.

Thanks!
I'm open to testing new approaches if/when they appear.

Daniel