The Alchemy platform code registers the SMBus device using the virtual
address of its registers instead of the physical one -- fix this, taking
into account that actually the whole megabyte is decoded by any of the
programmable serial controllers (one of which is SMBus), and that all the
Alchemy peripherals are directly mappable into KSEG1 kernel space and
therefore ioremap() call would just boil down to CKSEG1ADDR() invocation.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Since 43cc71eed1, the platform
modalias is prefixed with "platform:". Add MODULE_ALIAS() to the
hotpluggable I2C platform drivers, to allow module auto loading.
[ db: add some more drivers ]
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Convert the i2c-au1550 bus driver to platform driver, and
register a platform device for the Alchemy Db/Pb series of
boards.
Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Zero-bytes transfers would leave the bus transaction unfinished
(no i2c stop is sent), with the following transfer actually
sending the slave address to the previously addressed device,
resulting in weird device failures (e.g. reset minute register
values in my RTC).
This patch instructs the controller to send an I2C STOP right after
the slave address in case of a zero-byte transfer.
Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Fix a "mis-used register" problem on the AMD MIPS Alchemy au1550
I2C interface.
In summary, the programmable serial controller seems to hang the kernel
when I send a single 'address' byte on the I2C bus. The patch
essentially uses the PSC_SMBSTAT register's TE (transmit FIFO empty)
bit to check when the transmit FIFO is empty, instead of using the
PSC_SMBEVNT register's TU (transmit underflow) bit. Using the TE bit
fixed the hang problem.
Signed-off-by: Chris David <cd@chrisdavid.com>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
i2c: Constify i2c_algorithm declarations, part 2
Make struct i2c_algorithm declarations const in all i2c bus drivers
where it is possible.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
i2c-au1550: Add SMBus functionality flag
Add SMBus functionality flag, so we can use eeprom and similar
drivers.
Signed-off-by: Domen Puncer <domen.puncer@ultra.si>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
i2c-au1550: Fix timeout problem
Fix from Jordan Crouse:
If the transmit and recieve FIFOS are not empty, forceably flush them
rather then waiting for them to drain on their own.
This solves at least a problem reported by Clem Taylor:
http://www.linux-mips.org/archives/linux-mips/2006-05/msg00240.html
(1% of I2C transactions would timeout)
Signed-off-by: Domen Puncer <domen.puncer@ultra.si>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are no more users of i2c_algorithm.id, so we can finally drop
this structure member.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The name member of the i2c_algorithm is never used, although all
drivers conscientiously fill it. We can drop it completely, this
structure doesn't need to have a name.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Files that don't use CONFIG_* stuff shouldn't include config.h
Files that use CONFIG_* stuff should include config.h
It's that simple. ;-)
Signed-off-by: Alexey Dobriyan <adobriyan@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
