Hopefully a lot less. Well, how is it incomplete? Have you tried working from 2.6.21 and using Giorgio's CruxPPC patches to make a more modern kernel? Do you want to write the generic GPIO driver for us? :D

There is a porting process (perpetual and messy.. this is Linux, remember) to move systems from the old ppc/ directory to the powerpc/ directory. You shouldn't be using anything from ppc/ if you can help it.

Therefore, if there is something missing, and you really miss it, it would be nice to know so it can be put into powerpc/ files :)

Certainly any GPIO work and the patch for the bitbanging i2c driver there, would go into powerpc/ and it would never, ever be accepted for inclusion into ppc/.

However even though bitbanging I2C over GPIO is super-great solution, we're talking Linux solutions here, and Kevin's using QNX (or hopes to..). I don't think writing QNX drivers is hard at all (in fact.. much simpler) but there probably won't be the generic GPIO interface to start from (but then again, there wasn't in Linux before 2 weeks ago..)

_________________
Matt Sealey

You don't have to pull on the SDA PIN since you are the master. The slave shifts the bits only when you generates an edge on the SCL bus (this is roughly the concept...). So it's not CPU consuming (I will check this point again).


Thanks for the details, but I already know how to do it. ;-)

If you use the struct mpc52xx_gpio each member can be easily set this way:

config->simple_gpioe
config->simple_ode
...

I'm only not sure of one thing, do I bypass the data-cache by doing this ? I assume it does but Neko, perhaps you can help me here... :-)
Stellae

I'm not a QNX specialist, but I agree, accessing registers shouldn't (I said shouldn't ;-)) be very hard.

=> but there probably won't be the generic GPIO interface to start from (but then again, there wasn't in Linux before 2 weeks...

I'm lost here. The method I've shown doesn't use a generic GPIO interface (it just fills registers). Do I miss something ?
To be honnest I've not tried 2.6.21 with Giorgio's CruxPPC patches for the moment. One of the reasons is that I use a 2.6.19_rc6_efika kernel with minor modifications (remember I patched the fb_ddc.c file to add debug support for my DVI IF (7" screen)). However, I could probably apply it to the 2.6.21 without any problem.

One mpc52xx.h is 462 lines and the other one is 290... Perhaps it's for compatibility reasons I haven't check in details.

I can (try to) write a generic GPIO driver and why not with "bitbang" I2C support (if possible). I develop it as a loadable module for the moment, but why not merging it to the kernel source after ?

I'm busy since I work also on the screen for the portable EFIKA (schematics are ready ;-)) but I will be happy to try.

Stellae

It's not for you, it's for them :)
They're chip registers so they should not be cached if you specify your variable as __iomem, like this;.
The correct way to get the MBAR under arch/powerpc is
2.6.21 has a hardware-independant GPIO API - it basically defines a few simple functions (gpio_read_value, gpio_direction_output, that kind of thing) and accepts a pin value (which is implementation dependant), for instance, messing with registers directly gets turned into
Don't worry, I'm writing one now, since it's so easy even someone as braindead as me can do it :)

_________________
Matt Sealey

Thanks Neko for these details concerning MBAR.
Absolutely, I wrote one of those "GPIO drivers" for a NIOS II (softcore from Altera) yesterday morning in less that 10 minutes. ;-)

When I said 100~200 lines, it was for the bit-bang I2C emulation written from scratch...

I wait for your patch, my time will be better spent switching from 2.6.19 to 2.6.21.

Stellae

:)
Don't wait too long. In my quest to "do this right" I have stumbled on the developers of the GPIO framework and people who already have written comprehensive GPIO handling on the 52xx platform..

I have my idea for it and I will code that anyway, but it would be best to re-use other peoples' work rather than conflict with it.

That said.. there is a very good case for ignoring them and coding it how I want it to be, just to get the i2c bitbanging driver to work fast.

Might make a decision today :)

_________________
Matt Sealey

FYI, there should be a gpio node in the dt to get the address, anything driver that justs hacks things like getting offset in asm-ppc/mpc52xx.h and such horrible things will just never be merged (and asm-ppc/mpc52xx.h will dissapear soon anyway ...) Getting the mbar and adding the offset is not right either ...

The original device tree of the efika doesn't have such a node ... so read the bindings docs and write a bootscript that properly adds the node and its required properties.


If you don't mind having a hacked-up driver just for your purpose, have a look
at i2c-parport-light.c for an example how to use the generic bit bang algo, you basically just need to provide a setsda(...) and setscl(...) and the getsda(...) and getscl(...) functions.
And yes, to be fully i2c compliant scl must be bidir too ! But if that's the only master on the bus you can get away without it. Use simulated open drain output, when scl is set to '0', use output '0', when set to '1' use as input and let the pullup bring the bus line high.

Well, you should mpc52xx_find_and_map() the gpio node for sure, but it's not in the device tree.

It's not like you don't make that same 'bug' in your own drivers Sylvain :)

_________________
Matt Sealey

Which one ?

The only "driver" where I did this is the AC97, and I didn't try to push it upstream exactly for that reason ...
I will never push a new driver that use such a hack.

I may "tolerate" in it in efika.c, but even if I do it will be with a major comment in the code saying how I despise that portion of code and how this should be fixed in the efika FW itself.

I don't think it's very mature to mark your code as critical of the hardware vendors. We know this stuff should be in the firmware, and truthfully .. commenting on it in such a way ("come on bplan!!") does very little to make it happen.

I personally don't see a great deal of problem committing the audio driver into the tree, and fixing up any device tree in efika.c (and doing the 'enable PSC2 as AC97' fix somewhere in there too).

Once the device tree is fixed in later firmwares you don't have to have any trouble, but I would really recommend against tracking Linux against our firmware. It is not up to Linux, or even bplan or Genesi, to force users to upgrade for the minor pleasure of having the hardware described more correctly, and any fixes for previous firmwares completely removed.

_________________
Matt Sealey

I agree, but I just gave a quick (and yes, dirty) way to make some tests with the GPIO at the beginning of this post (you can call this a hack if you want... ;-)). It was absolutely NOT written to be merged this way in the kernel. When I submitted the idea of a kernel module, I obviously thought writing a clean driver and also take care of the IRDA functionality (both shared on PS6 => this is an issue). Nevertheless, it's always nice to test some hardware features quickly (in my case needed for another project as I said before). Spending more time on the GPIO is not my immediate priority (and this is probably the situation of peoples who develop HW devices for the EFIKA (or even for other platforms)). But sharing solutions (in a friendly environment) should always be positive.
On my side I stop any I2C protocol discussion(s) here. If somebody wants all the details I suggest that he/she reads the I2C specification from Philips/NXP (should be available for free...). I don't give a 100% I2C compliant software solution here, "it's a workaround". And for the purists, I'm also pretty sure that all the electrical requirements given in the specification are often not meet in "prototyping designs".

Since knickels wants to drive 1 or more sensors (slave) from the EFIKA (master) I've suggested to keep SCL as output only to make it easier, nothing more.
Thanks. It could be a good starting point for people looking at a working implementation ;-).

Stellae