* Re: 2.6.16-mm1 leaks in dvb playback (found)
From: David S. Miller @ 2006-03-30 23:28 UTC (permalink / raw)
To: adrian; +Cc: akpm, linux-kernel, ak
In-Reply-To: <20060330231131.GA25029@smop.co.uk>
From: Adrian Bridgett <adrian@smop.co.uk>
Date: Fri, 31 Mar 2006 00:11:31 +0100
> On Thu, Mar 30, 2006 at 23:58:30 +0100 (+0100), adrian wrote:
> > What I thought was just one patch was actually two and it was the
> > other patch causing the problem - "Do not lose accepted socket when
> > -ENFILE/-EMFILE".
>
> Hmm - it looks like it was meant to be reverted in 2.6.16-rc1-mm4,5 FWIW.
So is the current version in Linus's tree causing this problem?
Yes, in the middle while initially doing development on that patch
there were many bad leaks, but later on those were all fixed.
^ permalink raw reply
* Re: [Bugme-new] [Bug 6311] New: libata/sata_sil Oops on boot
From: Andrew Morton @ 2006-03-30 23:27 UTC (permalink / raw)
To: bugme-daemon; +Cc: linux-ide, Jeff Garzik, sndoc, Tejun Heo
In-Reply-To: <200603302303.k2UN3CT8031412@fire-2.osdl.org>
bugme-daemon@bugzilla.kernel.org wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6311
>
> Summary: libata/sata_sil Oops on boot
> Kernel Version: Debian 2.6.16-1-k7
> Status: NEW
> Severity: blocking
> Owner: jgarzik@pobox.com
> Submitter: sndoc@free.fr
>
>
> Most recent kernel where this bug did not occur:
> Similar reports on lkml seems to indicate everything was ok with 2.6.13
> (http://lkml.org/lkml/2006/1/17/306)
>
> Distribution:
> Debian unstable
>
> Hardware Environment:
> - Asus A7N8X delux / NForce2 chipset / SATA Silicon Image 3112A
> - Sata device 1 : Plextor PX 755 SA (Dvd recorder)
> - Everything is ok under an alternative OS.
>
> Software Environment:
> - Debian unstable, kernel 2.6.16, libata 1.20
> - not using the nvidia binary module.
>
> Steps to reproduce: boot...
>
> Problem Description:
>
> On boot, with libata.atapi_enabled=1
> - Sata device detected, sata_sil loaded, sata link up OK
> - Indicates an " abnormal status 0x78 on port 0xE0918087"
> - After claiming that "ata1 is slow to respond, please be patient" and letting
> some other kernel booting stuff go their way, libata finally Oops and dump a
> stack trace.
> - Boot process still continue and the computer is usable afterward
> - However trying to rmmod libata (after having removed sata_sil) hangs
> indefinitely.
>
> Trying with libata.fua=0 gives the same results
> Trying with sata_sil.slow_down=1 gives the same results
> Trying with both : same
>
> Trying to boot with libata.atapi_enabled=0, removing the modules, then reloading
> them with libata.atapi_enabled=1 gives the same results except that the error
> messages are thrown to the console and the keybord stops working...
>
>
> Here is the dmesg, from a boot with
> libata.atapi_enabled=1
> libata.fua=0
> sata_sil.slow_down=1
>
> dmesg
> -------------------------------------------------
> sata_sil 0000:01:0b.0: version 0.9
> ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
> ACPI: PCI Interrupt 0000:01:0b.0[A] -> Link [APC3] -> GSI 18 (level, high) ->
> IRQ 201
> ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 22
> ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [APCJ] -> GSI 22 (level, high) ->
> IRQ 177
> PCI: Setting latency timer of device 0000:00:06.0 to 64
> ata1: SATA max UDMA/100 cmd 0xE0918080 ctl 0xE091808A bmdma 0xE0918000 irq 201
> ata2: SATA max UDMA/100 cmd 0xE09180C0 ctl 0xE09180CA bmdma 0xE0918008 irq 201
> input: PS2++ Logitech MX Mouse as /class/input/input2
> ata1: SATA link up 1.5 Gbps (SStatus 113)
> intel8x0_measure_ac97_clock: measured 50672 usecs
> intel8x0: clocking to 47382
> ata1: dev 0 cfg 49:0f00 82:0000 83:0000 84:0000 85:0000 86:0000 87:0000 88:001f
> ata1: dev 0 ATAPI, max UDMA/66
> ata1(0): applying bridge limits
> ata1(0): applying Seagate errata fix (mod15write workaround)
> ata1: dev 0 configured for UDMA/66
> scsi0 : sata_sil
> ata2: SATA link down (SStatus 0)
> scsi1 : sata_sil
> ATA: abnormal status 0x78 on port 0xE0918087
> ATA: abnormal status 0x78 on port 0xE0918087
> ATA: abnormal status 0x78 on port 0xE0918087
> ATA: abnormal status 0x78 on port 0xE0918087
> ts: Compaq touchscreen protocol output
> ata1 is slow to respond, please be patient
> ata1: command 0xa0 timeout, stat 0xf8 host_stat 0x0
> ata1: translated ATA stat/err 0xf8/00 to SCSI SK/ASC/ASCQ 0xb/47/00
> Adding 2000084k swap on /dev/hda3. Priority:-1 extents:1 across:2000084k
> EXT3 FS on hda2, internal journal
> device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel@redhat.com
> kjournald starting. Commit interval 5 seconds
> EXT3 FS on hda4, internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [AP3C] -> GSI 20 (level, high) ->
> IRQ 193
> ata1 failed to respond (30 secs)
> ATA: abnormal status 0xF8 on port 0xE0918087
> Assertion failed! qc->flags &
> ATA_QCFLAG_ACTIVE,drivers/scsi/libata-core.c,ata_qc_complete,line=3631
> ata1: translated ATA stat/err 0xf8/00 to SCSI SK/ASC/ASCQ 0xb/47/00
> Unable to handle kernel NULL pointer dereference at virtual address 000000cc
> printing eip:
> e084f9c3
> *pde = 00000000
> Oops: 0000 [#1]
> Modules linked in: dm_mod tsdev analog gameport snd_intel8x0 snd_ac97_codec
> snd_ac97_bus snd_mpu401 snd_mpu401_uart snd_pcm_oss snd_mixer_oss snd_rawmidi
> snd_seq_device sata_sil snd_pcm snd_timer psmouse nvidia_agp 3c59x parport_pc
> parport snd soundcore ehci_hcd ohci_hcd serio_raw mii ide_cd cdrom i2c_nforce2
> floppy snd_page_alloc agpgart rtc usbcore forcedeth i2c_core pcspkr shpchp
> pci_hotplug ohci1394 ieee1394 ext3 jbd mbcache ide_disk amd74xx generic ide_core
> sata_nv libata scsi_mod evdev mousedev
> CPU: 0
> EIP: 0060:[<e084f9c3>] Not tainted VLI
> EFLAGS: 00010046 (2.6.16-1-k7 #1)
> EIP is at scsi_device_unbusy+0xb/0x31 [scsi_mod]
> eax: deeed74c ebx: df362400 ecx: ffffffff edx: 00000000
> esi: 00000046 edi: 00000202 ebp: df363b60 esp: dfaedf08
> ds: 007b es: 007b ss: 0068
> Process ata/0 (pid: 810, threadinfo=dfaec000 task=df98b560)
> Stack: <0>00000000 df362400 e084a238 df362400 deeed74c 00000000 00000202 deeed74c
> e08399d0 df363b60 deeed280 e08357ef deeed74c deeed280 deeed280 00000000
> 00000202 deeed74c e0835f2b deeed74c deeed280 deeed800 dfaf9660 00000293
> Call Trace:
> [<e084a238>] scsi_finish_command+0x13/0xbf [scsi_mod]
> [<e08399d0>] atapi_sense_complete+0x20/0x25 [libata]
> [<e08357ef>] ata_qc_complete+0x1ba/0x1d1 [libata]
> [<e0835f2b>] ata_poll_qc_complete+0x88/0x91 [libata]
> [<b0121a95>] run_workqueue+0x64/0x94
> [<e0835f34>] atapi_packet_task+0x0/0x127 [libata]
> [<b0121b39>] worker_thread+0x0/0x10f
> [<b0121c18>] worker_thread+0xdf/0x10f
> [<b011361e>] default_wake_function+0x0/0x15
> [<b0124139>] kthread+0x94/0xc1
> [<b01240a5>] kthread+0x0/0xc1
> [<b0101005>] kernel_thread_helper+0x5/0xb
> Code: d0 88 46 09 0f b6 55 06 66 0f b6 45 07 c1 e2 08 01 d0 66 89 46 04 83 c4 20
> 89 f8 5b 5e 5f 5d c3 56 53 8b 5c 24 0c 8b 13 9c 5e fa <8b> 82 cc 00 00 00 ff 4a
> 54 83 e8 05 83 f8 02 77 0d 83 7a 58 00
> <6>ACPI: Power Button (FF) [PWRF]
> ACPI: Power Button (CM) [PWRB]
> ------------------------
It's one of those might-be-ata, might-be-scsi bugs.
It appears that scsi_device.host contains garbage in scsi_device_unbusy().
At a guess I'd say that ata hasn't got enough stuff initialised to be
calling scsi_device_unbusy().
Once we've sorted that out, we need to work out why you got that assertion
failure.
Once we've done that, we need to work out why ATA isn't working.
I guess it would be helpful if you could determine whether 2.6.13 indeed
works OK on your machine as well.
^ permalink raw reply
* Re: linux-2.6-xen kernels and initrds
From: Andrew D. Ball @ 2006-03-30 23:27 UTC (permalink / raw)
To: xen-devel
I may be seeing the same problem. It looks like something is messed up
with the way the kernel modules are versioned or their symbol tables,
but I don't know quite enough to finish figuring out what's wrong at the
moment.
Here's some of the error messages I saw while trying to boot:
==
Mounting sysfs
Creating /dev
Starting udev
Loading scsi_mod.ko module
scsi_mod: no version for "struct_module" found: kernel tainted.
Loading sd_mod.ko module
SCSI subsystem initialized
sd_mod: Unknown symbol scsi_print_sense_hdr
Loading libata.ko module
sd_mod: Unknown symbol scsi_mode_sense
insmod: error inserting '/lib/sd_mod.ko': -1 Unknown symbol in module
sd_mod: Unknown symbol scsi_device_get
Loading ata_piix.ko module
sd_mod: Unknown symbol scsi_get_sense_info_fld
insmod: error inserting '/lib/libata.ko': -1 Unknown symbol in module
==
If I do objdump -x on sd_mod from /lib/modules/2.6.16-xen I see several
lines like this:
00000000 *UND* 00000000 scsi_print_sense_hdr
in the symbol table dump. This is one of the symbols that the initrd
complained about.
Any help fixing this would be appreciated. I can post more output if
needed.
Thanks!
Andrew
==============
Andrew D. Ball <aball@us.ibm.com>
David F. Barrera wrote:
> I have a question regarding the building of the unified xen kernel
> (linux-2.6-xen) and the use of initrd. In the past I built both xen0
> and xenU kernels; the xen0 default configurations had SCSI and Fusion
> MPT support compiled into the kernel. Now, they are built as modules.
> The problem is that I am unable to boot the xen kernel built that way,
> even though I am building an initrd. I have machines running both SLES
> and FC that are exhibiting this problem. The question is, do I need to
> do something special to build the initrds? In SuSE, I typically just
> used the 'mkinitrd' command; in FC4, I do it like this: "mkinitrd -v -f
> --with=aacraid --with=sd_mod --with=scsi_mod initrd-2.6.16-xen
> 2.6.16-xen". At any rate, nothing has worked to this point.
>
> The SCSI device support help page in 'make menuconfig' states 'do not
> compile this as a module if your root file system (the one containing
> the directory /) is located on a SCSI device.', which is the case in my
> setup. But I have seen it where the distros compile it as module, and
> the initrd takes care of it.
>
> Any help would be appreciated.
>
^ permalink raw reply
* Re: [PATCH] isd200: limit to BLK_DEV_IDE
From: Randy.Dunlap @ 2006-03-30 23:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: Randy.Dunlap, Beber, Greg KH, linux-kernel, stable, beber, akpm
In-Reply-To: <Pine.LNX.4.64.0603301446340.27203@g5.osdl.org>
On Thu, 30 Mar 2006, Linus Torvalds wrote:
> On Thu, 30 Mar 2006, Randy.Dunlap wrote:
> >
> > Limit USB_STORAGE_ISD200 to whatever BLK_DEV_IDE and USB_STORAGE
> > are set to (y, m) since isd200 calls ide_fix_driveid() in the
> > BLK_DEV_IDE code.
> >
> > Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> > ---
> > drivers/usb/storage/Kconfig | 2 +-
> > 1 files changed, 1 insertion(+), 1 deletion(-)
> >
> > --- linux-2616-z.orig/drivers/usb/storage/Kconfig
> > +++ linux-2616-z/drivers/usb/storage/Kconfig
> > @@ -48,7 +48,7 @@ config USB_STORAGE_FREECOM
> >
> > config USB_STORAGE_ISD200
> > bool "ISD-200 USB/ATA Bridge support"
> > - depends on USB_STORAGE && BLK_DEV_IDE
> > + depends on USB_STORAGE && (BLK_DEV_IDE=y || BLK_DEV_IDE=m && USB_STORAGE=m)
>
> Hmm. That expression is _really_ hard to figure out.
Yes, I just modeled it on some other similar Kconfigs.
> It would be more logical to make it
>
> depends on USB_STORAGE && (BLK_DEV_IDE=y || BLK_DEV_IDE=USB_STORAGE)
>
> or, even more preferably, split up the rules as two separate dependencies:
>
> depends on USB_STORAGE
> depends on BLK_DEV_IDE=y || BLK_DEV_IDE=USB_STORAGE
>
> (where that second thing really _should_ be expressible as
>
> depends on BLK_DEV_IDE >= USB_STORAGE
>
> but the kconfig language doesn't support that syntax..)
In some way, the original line made sense to me:
depends on USB_STORAGE && BLK_DEV_IDE
where we have: =y && =m
so if USB_STORAGE_ISD200 were a tristate, it would have been limited
to 'm', but since it's a bool, it's not limited.
New patch is below.
--
From: Randy Dunlap <rdunlap@xenotime.net>
Limit USB_STORAGE_ISD200 to whatever BLK_DEV_IDE and USB_STORAGE
are set to (y, m) since isd200 calls ide_fix_driveid() in the
BLK_DEV_IDE code.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
drivers/usb/storage/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
--- linux-2616-z.orig/drivers/usb/storage/Kconfig
+++ linux-2616-z/drivers/usb/storage/Kconfig
@@ -48,7 +48,8 @@ config USB_STORAGE_FREECOM
config USB_STORAGE_ISD200
bool "ISD-200 USB/ATA Bridge support"
- depends on USB_STORAGE && BLK_DEV_IDE
+ depends on USB_STORAGE
+ depends on BLK_DEV_IDE=y || BLK_DEV_IDE=USB_STORAGE
---help---
Say Y here if you want to use USB Mass Store devices based
on the In-Systems Design ISD-200 USB/ATA bridge.
^ permalink raw reply
* [PATCH] i2c: pca954x I2C mux driver
From: Kumar Gala @ 2006-03-30 23:11 UTC (permalink / raw)
To: khali; +Cc: linux-kernel, lm-sensors, Greg KH
In-Reply-To: <Pine.LNX.4.44.0603301700160.10117-100000@gate.crashing.org>
Driver for the Phillips pca954x I2C mux/switches devices. These devices handle
the fact that a number of I2C devices have limited address selection capablities
and systems may end up having to mux to access all the I2C devices.
The driver uses the i2c virtual adapter support to make each mux/switch port
look like its own i2c bus.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 735344d2f587938da9012070f881b725269c4dc9
tree a12c50c7f3d34b44e33397863dc7e57f8fd0e3ec
parent 862cbc263e3d3e44028d7465a912847cf5366163
author Kumar Gala <galak@kernel.crashing.org> Thu, 30 Mar 2006 17:05:14 -0600
committer Kumar Gala <galak@kernel.crashing.org> Thu, 30 Mar 2006 17:05:14 -0600
drivers/i2c/chips/Kconfig | 10 +
drivers/i2c/chips/Makefile | 1
drivers/i2c/chips/pca954x.c | 320 +++++++++++++++++++++++++++++++++++++++++++
include/linux/i2c-id.h | 1
4 files changed, 332 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 7aa5c38..894c95e 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -56,6 +56,16 @@ config SENSORS_PCA9539
This driver can also be built as a module. If so, the module
will be called pca9539.
+config SENSORS_PCA954x
+ tristate "Philips PCA954x I2C Mux/switches"
+ depends on I2C && I2C_VIRT && EXPERIMENTAL
+ help
+ If you say yes here you get support for the Philips PCA954x
+ I2C mux/switch devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca954x.
+
config SENSORS_PCF8591
tristate "Philips PCF8591"
depends on I2C && EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 779868e..e69190d 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o
obj-$(CONFIG_SENSORS_MAX6875) += max6875.o
obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
+obj-$(CONFIG_SENSORS_PCA954x) += pca954x.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
diff --git a/drivers/i2c/chips/pca954x.c b/drivers/i2c/chips/pca954x.c
new file mode 100644
index 0000000..f300493
--- /dev/null
+++ b/drivers/i2c/chips/pca954x.c
@@ -0,0 +1,320 @@
+/*
+ * pca954x.c - Part of lm_sensors, Linux kernel modules for hardware
+ * monitoring
+ * This module supports the PCA954x series of I2C multiplexer/switch chips
+ * made by Philips Semiconductors. This includes the
+ * PCA9540, PCA9542, PCA9543, PCA9544, PCA9545, PCA9546, PCA9547 and PCA9548.
+ *
+ * These chips are all controlled via the I2C bus itself, and all have a
+ * single 8-bit register (normally at 0x70). The upstream "parent" bus fans
+ * out to two, four, or eight downstream busses or channels; which of these
+ * are selected is determined by the chip type and register contents. A
+ * mux can select only one sub-bus at a time; a switch can select any
+ * combination simultaneously.
+ *
+ * Based on:
+ * pca954x.c from Ken Harrenstien
+ * Copyright (C) 2004 Google, Inc. (Ken Harrenstien)
+ *
+ * Based on:
+ * i2c-virtual_cb.c from Brian Kuschak <bkuschak@yahoo.com>
+ * and
+ * pca9540.c from Jean Delvare <khali@linux-fr.org>, which was
+ * based on pcf8574.c from the same project by Frodo Looijaard,
+ * Philip Edelbrock, Dan Eaton and Aurelien Jarno.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+
+#define PCA954X_MAX_NCHANS 8
+
+static struct i2c_driver pca954x_driver;
+
+/* Addresses to scan: none. These chip cannot be detected. */
+static unsigned short normal_i2c[] = { I2C_CLIENT_END };
+
+/* Chip type must normally be specified using a parameter of the form
+ "force_pca9544=0,0x70"
+ The following declares the possible types.
+*/
+I2C_CLIENT_INSMOD_8(pca9540, pca9542, pca9543, pca9544,
+ pca9545, pca9546, pca9547, pca9548);
+
+struct pca954x_chipdef {
+ enum chips type;
+ const char *name;
+ u8 nchans;
+ u8 enable; /* used for muxes only */
+ enum muxtype { pca954x_ismux = 0, pca954x_isswi } muxtype;
+};
+
+/* Provide specs for the PCA954x types we know about */
+static struct pca954x_chipdef pca954x_chipdefs[] = {
+ {
+ .type = pca9540,
+ .name = "pca9540",
+ .nchans = 2,
+ .enable = 0x4,
+ .muxtype = pca954x_ismux,
+ },
+ {
+ .type = pca9542,
+ .name = "pca9542",
+ .nchans = 2,
+ .enable = 0x4,
+ .muxtype = pca954x_ismux,
+ },
+ {
+ .type = pca9543,
+ .name = "pca9543",
+ .nchans = 2,
+ .enable = 0x0,
+ .muxtype = pca954x_isswi,
+ },
+ {
+ .type = pca9544,
+ .name = "pca9544",
+ .nchans = 4,
+ .enable = 0x4,
+ .muxtype = pca954x_ismux,
+ },
+ {
+ .type = pca9545,
+ .name = "pca9545",
+ .nchans = 4,
+ .enable = 0x0,
+ .muxtype = pca954x_isswi,
+ },
+ {
+ .type = pca9546,
+ .name = "pca9546",
+ .nchans = 4,
+ .enable = 0x0,
+ .muxtype = pca954x_isswi,
+ },
+ {
+ .type = pca9547,
+ .name = "pca9547",
+ .nchans = 8,
+ .enable = 0x8,
+ .muxtype = pca954x_ismux,
+ },
+ {
+ .type = pca9548,
+ .name = "pca9548",
+ .nchans = 8,
+ .enable = 0x0,
+ .muxtype = pca954x_isswi,
+ },
+};
+
+struct pca954x_data {
+ struct i2c_client client;
+ unsigned int chip_offset;
+ u8 last_chan;
+ struct i2c_adapter *virt_adapters[PCA954X_MAX_NCHANS];
+};
+
+static int pca954x_xfer(struct i2c_adapter *adap,
+ struct i2c_client *client, int read_write, u8 * val)
+{
+ int ret = -ENODEV;
+
+ if (adap->algo->master_xfer) {
+ struct i2c_msg msg;
+ char buf[1];
+
+ msg.addr = client->addr;
+ msg.flags = (read_write == I2C_SMBUS_READ ? I2C_M_RD : 0);
+ msg.len = 1;
+ buf[0] = *val;
+ msg.buf = buf;
+ ret = adap->algo->master_xfer(adap, &msg, 1);
+ } else if (adap->algo->smbus_xfer) {
+ union i2c_smbus_data data;
+ ret = adap->algo->smbus_xfer(adap,
+ client->addr,
+ client->flags & I2C_M_TEN,
+ read_write,
+ *val, I2C_SMBUS_BYTE, &data);
+ }
+
+ return ret;
+}
+
+static int pca954x_select_chan(struct i2c_adapter *adap,
+ struct i2c_client *client, u32 chan)
+{
+ struct pca954x_data *data = i2c_get_clientdata(client);
+ struct pca954x_chipdef *chip = &pca954x_chipdefs[data->chip_offset];
+ u8 regval = 0;
+ int ret = 0;
+
+ /* we make switches look like muxes, not sure how to be smarter */
+ if (chip->muxtype == pca954x_ismux)
+ regval = chan | chip->enable;
+ else
+ regval = 1 << chan;
+
+ /* Only select the channel if its different from the last channel */
+ if (data->last_chan != chan) {
+ ret = pca954x_xfer(adap, client, I2C_SMBUS_WRITE, ®val);
+ data->last_chan = chan;
+ }
+
+ return ret;
+}
+
+static int pca954x_deselect_mux(struct i2c_adapter *adap,
+ struct i2c_client *client, u32 value)
+{
+ /* We never deselect, just stay on the last channel we selected */
+ return 0;
+}
+
+static int pca954x_detect(struct i2c_adapter *bus, int address, int kind)
+{
+ int i, n;
+ struct i2c_client *client;
+ struct pca954x_data *data;
+ int ret = -ENODEV;
+
+ if (!i2c_check_functionality(bus, I2C_FUNC_SMBUS_BYTE))
+ goto err;
+
+ if (!(data = kzalloc(sizeof(struct pca954x_data), GFP_KERNEL))) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ client = &data->client;
+ client->addr = address;
+ client->adapter = bus;
+ client->driver = &pca954x_driver;
+ client->flags = 0;
+ i2c_set_clientdata(client, data);
+ if (kind < 0) {
+ dev_err(&bus->dev, "Attempted ill-advised probe at addr 0x%x\n",
+ address);
+ goto exit_free;
+ }
+
+ /* Read the mux register at addr. This does two things: it verifies
+ that the mux is in fact present, and fetches its current
+ contents for possible use with a future deselect algorithm.
+ */
+ if ((i = i2c_smbus_read_byte(client)) < 0) {
+ dev_warn(&bus->dev, "pca954x failed to read reg at 0x%x\n",
+ address);
+ goto exit_free;
+ }
+
+ if (kind == any_chip) {
+ dev_warn(&bus->dev, "pca954x needs advice on chip type - "
+ "wildly guessing 0x%x is a PCA9540\n", address);
+ kind = pca9540;
+ }
+
+ /* Look up in table */
+ for (i = sizeof(pca954x_chipdefs) / sizeof(pca954x_chipdefs[0]);
+ --i >= 0;) {
+ if (pca954x_chipdefs[i].type == kind)
+ break;
+ }
+ if (i < 0) {
+ dev_err(&bus->dev, "Internal error: unknown kind (%d)\n", kind);
+ goto exit_free;
+ }
+
+ data->chip_offset = i;
+
+ if ((ret = i2c_attach_client(client)))
+ goto exit_free;
+
+ /* Now create virtual busses and adapters for them */
+ for (i = 0; i < pca954x_chipdefs[data->chip_offset].nchans; i++) {
+ data->virt_adapters[i] =
+ i2c_add_virt_adapter(bus, client, i,
+ &pca954x_select_chan,
+ &pca954x_deselect_mux);
+ if (data->virt_adapters[i] == NULL) {
+ ret = -ENODEV;
+ goto virt_reg_failed;
+ }
+ }
+
+ dev_info(&client->dev,
+ "Registered %d virtual busses for I2C %s %s\n", i,
+ pca954x_chipdefs[data->chip_offset].muxtype == pca954x_ismux ?
+ "mux" : "switch", pca954x_chipdefs[data->chip_offset].name);
+
+ return 0;
+
+virt_reg_failed:
+ for (n = 0; n < i; n++)
+ i2c_del_virt_adapter(data->virt_adapters[n]);
+ i2c_detach_client(client);
+exit_free:
+ kfree(data);
+err:
+ return ret;
+}
+
+static int pca954x_attach_adapter(struct i2c_adapter *adapter)
+{
+ return i2c_probe(adapter, &addr_data, pca954x_detect);
+}
+
+static int pca954x_detach_client(struct i2c_client *client)
+{
+ struct pca954x_data *data = i2c_get_clientdata(client);
+ struct pca954x_chipdef *chip = &pca954x_chipdefs[data->chip_offset];
+ int i, err;
+
+ for (i = 0; i < chip->nchans; ++i) {
+ if (data->virt_adapters[i]) {
+ if ((err =
+ i2c_del_virt_adapter(data->virt_adapters[i])))
+ return err;
+ data->virt_adapters[i] = NULL;
+ }
+ }
+
+ if ((err = i2c_detach_client(client)))
+ return err;
+
+ kfree(data);
+ return 0;
+}
+
+static struct i2c_driver pca954x_driver = {
+ .driver = {
+ .name = "pca954x",
+ },
+ .id = I2C_DRIVERID_PCA954X,
+ .attach_adapter = pca954x_attach_adapter,
+ .detach_client = pca954x_detach_client,
+};
+
+static int __init pca954x_init(void)
+{
+ return i2c_add_driver(&pca954x_driver);
+}
+
+static void __exit pca954x_exit(void)
+{
+ i2c_del_driver(&pca954x_driver);
+}
+
+module_init(pca954x_init);
+module_exit(pca954x_exit);
+
+MODULE_AUTHOR("Kumar Gala <galak@kernel.crashing.org>");
+MODULE_DESCRIPTION("PCA954X I2C mux/switch driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/i2c-id.h b/include/linux/i2c-id.h
index 66d5533..f8f7f20 100644
--- a/include/linux/i2c-id.h
+++ b/include/linux/i2c-id.h
@@ -112,6 +112,7 @@
#define I2C_DRIVERID_X1205 82 /* Xicor/Intersil X1205 RTC */
#define I2C_DRIVERID_PCF8563 83 /* Philips PCF8563 RTC */
#define I2C_DRIVERID_RS5C372 84 /* Ricoh RS5C372 RTC */
+#define I2C_DRIVERID_PCA954X 85 /* pca954x I2C mux/switch */
#define I2C_DRIVERID_I2CDEV 900
#define I2C_DRIVERID_ARP 902 /* SMBus ARP Client */
^ permalink raw reply related
* RE: Fw: [Bugme-new] [Bug 6307] New: Bug hwclock in kernel 2.6.16
From: Luck, Tony @ 2006-03-30 23:22 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <20060330112531.1959b11e.akpm@osdl.org>
>> Subject: [Bugme-new] [Bug 6307] New: Bug hwclock in kernel 2.6.16
>...
>> Most recent kernel where this bug did not occur: Kernel 2.6.8-2-itanium-smp
>> (Defauld in Debian 3.1)
>
>I can't reproduce this with kernel.org 2.6.15 on an HP rx2600.
My HP rx2620, HP zx2000 and Intel Tiger are all running 2.6.16-gitlatest and
none of them hang on hwclock or ntpdate either.
The config file listed in the bugzilla has a zillion differences from
arch/ia64/defconfig ... and chance of trying with a kernel based on
this config?
-Tony
^ permalink raw reply
* Hotplug only coldplugs...
From: Matthew Percival @ 2006-03-30 23:21 UTC (permalink / raw)
To: linux-hotplug
G'Day,
I hope it is OK to post these sorts of questions here; I was not sure
where it should be taken.
I have been trying to set up diethotplug for an embedded system, but
have not had any success with actually hotplugging devices. The only
devices that are to be attached are a compact flash memory device and a
USB flash memory, which will always be on hda1 and sda1 respectively.
After much playing around with the scripts, I have been able to get the
USB memory to mount when `/etc/init.d/hotplug start' is called, which
seems to be a good start, but I have not been able to get any effect
outside of this case. I have not spend much time on compact flash yet,
which is why the scripts for it are not yet working.
In one test I tried, I left the device plugged in, unmounted it, and
run `hotplug usb', but nothing seemed to happen --- I even added an echo
statement the the start of /etc/hotplug/usb.rc, but did not see it.
Since coldplugging works, I would assume my scripts are all correctly
set up, so I am a little stuck on what the problem could be. In
addition, /proc/sys/kernel/hotplug says hotplug needs to be
at /sbin/hotplug, which it is, but when I replace hotplug with a script
that merely echoes any arguments it receives, and try plugging in the
device, there is no response. Perhaps this is to be expected, but it
seems odd to me.
If anyone could offer any advice to what I should try doing here, it
would be most appreciated.
Thanks,
Matthew Percival
PS When the system is used as a USB device rather than a USB host, can
hotplug be used somehow to identify when it is connected to a host? I
have not been able to find anything saying it can, but I can always
hope.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: [PATCH] gitk: Use git wrapper to run git-ls-remote.
From: Johannes Schindelin @ 2006-03-30 23:20 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne2o8lr.l0.mdw@metalzone.distorted.org.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 752 bytes --]
Hi,
On Thu, 30 Mar 2006, Mark Wooding wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>
> > Does anybody know what is going on?
>
> I'll try staring at the Tcl source code some time. I'm rather too busy
> tonight, though.
>
> There's also some very strange geometry management oddness going on in
> gitk. I'll try to sort that out too.
That has been discussed. My feeling is that this is a bug of Tk with
regard to rootless X servers. I never came around to do a proper patch,
but I have explicit -height and -width arguments to all frames and
panedwindows.
If you want to start working on it, I attached my current patch, which is
good enough for me, but note that it changes the geometry subtly everytime
gitk is called...
Hth,
Dscho
[-- Attachment #2: Type: TEXT/plain, Size: 1642 bytes --]
[PATCH] gitk: make geometry less weird on cygwin and macosx
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
gitk | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index 03cd475..7339069 100755
--- a/gitk
+++ b/gitk
@@ -373,13 +373,13 @@ proc makewindow {rargs} {
set geometry(ctexth) [expr {($texth - 8) /
[font metrics $textfont -linespace]}]
}
- frame .ctop.top
+ frame .ctop.top -height $geometry(canvh)
frame .ctop.top.bar
pack .ctop.top.bar -side bottom -fill x
set cscroll .ctop.top.csb
scrollbar $cscroll -command {allcanvs yview} -highlightthickness 0
pack $cscroll -side right -fill y
- panedwindow .ctop.top.clist -orient horizontal -sashpad 0 -handlesize 4
+ panedwindow .ctop.top.clist -orient horizontal -sashpad 0 -handlesize 4 -height $geometry(canvh)
pack .ctop.top.clist -side top -fill both -expand 1
.ctop add .ctop.top
set canv .ctop.top.clist.canv
@@ -449,9 +449,10 @@ proc makewindow {rargs} {
# for making sure type==Exact whenever loc==Pickaxe
trace add variable findloc write findlocchange
- panedwindow .ctop.cdet -orient horizontal
+ panedwindow .ctop.cdet -orient horizontal \
+ -height [expr $geometry(ctexth)*$linespc+4]
.ctop add .ctop.cdet
- frame .ctop.cdet.left
+ frame .ctop.cdet.left -width [expr $geometry(ctextw)*[font measure $textfont "0"]+8]
set ctext .ctop.cdet.left.ctext
text $ctext -bg white -state disabled -font $textfont \
-width $geometry(ctextw) -height $geometry(ctexth) \
^ permalink raw reply related
* [patch] fix extra page ref count in follow_hugetlb_page
From: Chen, Kenneth W @ 2006-03-30 23:19 UTC (permalink / raw)
To: linux-mm; +Cc: akpm, 'Adam Litke'
"[PATCH] optimize follow_hugetlb_page" breaks mlock on hugepage areas.
I mis-interpret pages argument and made get_page() unconditional. It
should only get a ref count when "pages" argument is non-null.
Credit goes to Adam Litke who spotted the bug.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
Acked-by: Adam Litke <agl@us.ibm.com>
--- ./mm/hugetlb.c.orig 2006-03-30 15:54:20.000000000 -0800
+++ ./mm/hugetlb.c 2006-03-30 15:54:56.000000000 -0800
@@ -555,9 +555,10 @@ int follow_hugetlb_page(struct mm_struct
pfn_offset = (vaddr & ~HPAGE_MASK) >> PAGE_SHIFT;
page = pte_page(*pte);
same_page:
- get_page(page);
- if (pages)
+ if (pages) {
+ get_page(page);
pages[i] = page + pfn_offset;
+ }
if (vmas)
vmas[i] = vma;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [OT] Non-GCC compilers used for linux userspace
From: Rob Landley @ 2006-03-30 23:16 UTC (permalink / raw)
To: Nix
Cc: Kyle Moffett, Eric Piel, Jan Engelhardt, mmazur, linux-kernel,
llh-discuss
In-Reply-To: <87odznsi98.fsf@hades.wkstn.nix>
On Thursday 30 March 2006 5:02 pm, Nix wrote:
> > Keep in mind that the main use of tcc these days is to turn c into a
> > scripting language. Just start your C file with
> >
> > #!/usr/bin/tcc -run
>
> I feel distinctly queasy. (I can't easily think of a less suitable language
> for scripting than C, either: perhaps COBOL...)
No, the queasy bit is when you realize that you can stick library linkage
directives on that command line and thus you can dynamically compile and run
X apps.
They have examples of doing this. :)
> > And notice that #! is a preprocessor comment line as far as tcc is
> > concerned. :)
>
> I noticed that, but I didn't think anyone actually *used* tcc for this.
It's not exactly "what it's for", but it's up there.
Rob
--
Never bet against the cheap plastic solution.
^ permalink raw reply
* Re: [openib-general] updated InfiniBand 2.6.17 merge plans
From: Sean Hefty @ 2006-03-30 23:18 UTC (permalink / raw)
To: Roland Dreier; +Cc: openib-general, linux-kernel
In-Reply-To: <ada1wwj1r7r.fsf@cisco.com>
Roland Dreier wrote:
> * RDMA CM. In my git tree at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git rdma_cm
>
> None of the users of this code look are to merge, and it looks like
> there's some changes in the design happening now. Seems like this
> can and should wait for 2.6.18.
Does it make sense to merge the first two patches of that patch series?
1. Provide common handling for marshalling data between userspace clients and
kernel mode Infiniband drivers.
2. Extend the Infiniband CM to include private data comparisons as part of its
connection request matching process.
This would make it easier to keep the openib tree in sync with the kernel.
- Sean
^ permalink raw reply
* Re: Suspend2-2.2.2 for 2.6.16.
From: Nigel Cunningham @ 2006-03-30 23:14 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Pavel Machek, Mark Lord, linux-kernel
In-Reply-To: <200603301413.06408.rjw@sisk.pl>
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
Hi.
On Thursday 30 March 2006 22:13, Rafael J. Wysocki wrote:
> Hi,
>
> On Thursday 30 March 2006 11:39, Nigel Cunningham wrote:
> > On Thursday 30 March 2006 19:34, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > On Wednesday 29 March 2006 12:50, Nigel Cunningham wrote:
> > > > Don't bother suggesting that to x86_64 owners: compilation is
> > > > currently broken in vbetool/lrmi.c (at least).
> >
> > I get:
>
> Please try the Makefile that I use on x86_64 (attached).
Am I right in guessing that I don't need to anymore, given the other emails on
this thread?
Regards,
Nigel
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ANNOUNCE: mdadm 2.4 - A tool for managing Soft RAID under Linux
From: Maurice Hilarius @ 2006-03-30 23:12 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <17451.24526.329349.962585@cse.unsw.edu.au>
Neil Brown wrote:
> I am pleased to announce the availability of
> mdadm version 2.4
> ..
>
> Release 2.4 primarily adds support for increasing the number of
> devices in a RAID5 array, which requires 2.6.17 (or some -rc or -mm
> prerelease).
> ..
Is there a corresponding means to increase the size of a file system to
use this?
> - Allow --monitor to work with arrays with >28 devices
>
So, how DO we get past the old 26 device "alphabet limit" ?
Thanks, as always, for the great work, Neil.
--
With our best regards,
Maurice W. Hilarius Telephone: 01-780-456-9771
Hard Data Ltd. FAX: 01-780-456-9772
11060 - 166 Avenue email:maurice@harddata.com
Edmonton, AB, Canada http://www.harddata.com/
T5X 1Y3
^ permalink raw reply
* [lm-sensors] [PATCH] i2c: pca954x I2C mux driver
From: Kumar Gala @ 2006-03-30 23:11 UTC (permalink / raw)
To: khali; +Cc: linux-kernel, lm-sensors, Greg KH
In-Reply-To: <Pine.LNX.4.44.0603301700160.10117-100000@gate.crashing.org>
Driver for the Phillips pca954x I2C mux/switches devices. These devices handle
the fact that a number of I2C devices have limited address selection capablities
and systems may end up having to mux to access all the I2C devices.
The driver uses the i2c virtual adapter support to make each mux/switch port
look like its own i2c bus.
Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---
commit 735344d2f587938da9012070f881b725269c4dc9
tree a12c50c7f3d34b44e33397863dc7e57f8fd0e3ec
parent 862cbc263e3d3e44028d7465a912847cf5366163
author Kumar Gala <galak at kernel.crashing.org> Thu, 30 Mar 2006 17:05:14 -0600
committer Kumar Gala <galak at kernel.crashing.org> Thu, 30 Mar 2006 17:05:14 -0600
drivers/i2c/chips/Kconfig | 10 +
drivers/i2c/chips/Makefile | 1
drivers/i2c/chips/pca954x.c | 320 +++++++++++++++++++++++++++++++++++++++++++
include/linux/i2c-id.h | 1
4 files changed, 332 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index 7aa5c38..894c95e 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -56,6 +56,16 @@ config SENSORS_PCA9539
This driver can also be built as a module. If so, the module
will be called pca9539.
+config SENSORS_PCA954x
+ tristate "Philips PCA954x I2C Mux/switches"
+ depends on I2C && I2C_VIRT && EXPERIMENTAL
+ help
+ If you say yes here you get support for the Philips PCA954x
+ I2C mux/switch devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called pca954x.
+
config SENSORS_PCF8591
tristate "Philips PCF8591"
depends on I2C && EXPERIMENTAL
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 779868e..e69190d 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o
obj-$(CONFIG_SENSORS_MAX6875) += max6875.o
obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
+obj-$(CONFIG_SENSORS_PCA954x) += pca954x.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
diff --git a/drivers/i2c/chips/pca954x.c b/drivers/i2c/chips/pca954x.c
new file mode 100644
index 0000000..f300493
--- /dev/null
+++ b/drivers/i2c/chips/pca954x.c
@@ -0,0 +1,320 @@
+/*
+ * pca954x.c - Part of lm_sensors, Linux kernel modules for hardware
+ * monitoring
+ * This module supports the PCA954x series of I2C multiplexer/switch chips
+ * made by Philips Semiconductors. This includes the
+ * PCA9540, PCA9542, PCA9543, PCA9544, PCA9545, PCA9546, PCA9547 and PCA9548.
+ *
+ * These chips are all controlled via the I2C bus itself, and all have a
+ * single 8-bit register (normally at 0x70). The upstream "parent" bus fans
+ * out to two, four, or eight downstream busses or channels; which of these
+ * are selected is determined by the chip type and register contents. A
+ * mux can select only one sub-bus at a time; a switch can select any
+ * combination simultaneously.
+ *
+ * Based on:
+ * pca954x.c from Ken Harrenstien
+ * Copyright (C) 2004 Google, Inc. (Ken Harrenstien)
+ *
+ * Based on:
+ * i2c-virtual_cb.c from Brian Kuschak <bkuschak at yahoo.com>
+ * and
+ * pca9540.c from Jean Delvare <khali at linux-fr.org>, which was
+ * based on pcf8574.c from the same project by Frodo Looijaard,
+ * Philip Edelbrock, Dan Eaton and Aurelien Jarno.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+
+#define PCA954X_MAX_NCHANS 8
+
+static struct i2c_driver pca954x_driver;
+
+/* Addresses to scan: none. These chip cannot be detected. */
+static unsigned short normal_i2c[] = { I2C_CLIENT_END };
+
+/* Chip type must normally be specified using a parameter of the form
+ "force_pca9544=0,0x70"
+ The following declares the possible types.
+*/
+I2C_CLIENT_INSMOD_8(pca9540, pca9542, pca9543, pca9544,
+ pca9545, pca9546, pca9547, pca9548);
+
+struct pca954x_chipdef {
+ enum chips type;
+ const char *name;
+ u8 nchans;
+ u8 enable; /* used for muxes only */
+ enum muxtype { pca954x_ismux = 0, pca954x_isswi } muxtype;
+};
+
+/* Provide specs for the PCA954x types we know about */
+static struct pca954x_chipdef pca954x_chipdefs[] = {
+ {
+ .type = pca9540,
+ .name = "pca9540",
+ .nchans = 2,
+ .enable = 0x4,
+ .muxtype = pca954x_ismux,
+ },
+ {
+ .type = pca9542,
+ .name = "pca9542",
+ .nchans = 2,
+ .enable = 0x4,
+ .muxtype = pca954x_ismux,
+ },
+ {
+ .type = pca9543,
+ .name = "pca9543",
+ .nchans = 2,
+ .enable = 0x0,
+ .muxtype = pca954x_isswi,
+ },
+ {
+ .type = pca9544,
+ .name = "pca9544",
+ .nchans = 4,
+ .enable = 0x4,
+ .muxtype = pca954x_ismux,
+ },
+ {
+ .type = pca9545,
+ .name = "pca9545",
+ .nchans = 4,
+ .enable = 0x0,
+ .muxtype = pca954x_isswi,
+ },
+ {
+ .type = pca9546,
+ .name = "pca9546",
+ .nchans = 4,
+ .enable = 0x0,
+ .muxtype = pca954x_isswi,
+ },
+ {
+ .type = pca9547,
+ .name = "pca9547",
+ .nchans = 8,
+ .enable = 0x8,
+ .muxtype = pca954x_ismux,
+ },
+ {
+ .type = pca9548,
+ .name = "pca9548",
+ .nchans = 8,
+ .enable = 0x0,
+ .muxtype = pca954x_isswi,
+ },
+};
+
+struct pca954x_data {
+ struct i2c_client client;
+ unsigned int chip_offset;
+ u8 last_chan;
+ struct i2c_adapter *virt_adapters[PCA954X_MAX_NCHANS];
+};
+
+static int pca954x_xfer(struct i2c_adapter *adap,
+ struct i2c_client *client, int read_write, u8 * val)
+{
+ int ret = -ENODEV;
+
+ if (adap->algo->master_xfer) {
+ struct i2c_msg msg;
+ char buf[1];
+
+ msg.addr = client->addr;
+ msg.flags = (read_write = I2C_SMBUS_READ ? I2C_M_RD : 0);
+ msg.len = 1;
+ buf[0] = *val;
+ msg.buf = buf;
+ ret = adap->algo->master_xfer(adap, &msg, 1);
+ } else if (adap->algo->smbus_xfer) {
+ union i2c_smbus_data data;
+ ret = adap->algo->smbus_xfer(adap,
+ client->addr,
+ client->flags & I2C_M_TEN,
+ read_write,
+ *val, I2C_SMBUS_BYTE, &data);
+ }
+
+ return ret;
+}
+
+static int pca954x_select_chan(struct i2c_adapter *adap,
+ struct i2c_client *client, u32 chan)
+{
+ struct pca954x_data *data = i2c_get_clientdata(client);
+ struct pca954x_chipdef *chip = &pca954x_chipdefs[data->chip_offset];
+ u8 regval = 0;
+ int ret = 0;
+
+ /* we make switches look like muxes, not sure how to be smarter */
+ if (chip->muxtype = pca954x_ismux)
+ regval = chan | chip->enable;
+ else
+ regval = 1 << chan;
+
+ /* Only select the channel if its different from the last channel */
+ if (data->last_chan != chan) {
+ ret = pca954x_xfer(adap, client, I2C_SMBUS_WRITE, ®val);
+ data->last_chan = chan;
+ }
+
+ return ret;
+}
+
+static int pca954x_deselect_mux(struct i2c_adapter *adap,
+ struct i2c_client *client, u32 value)
+{
+ /* We never deselect, just stay on the last channel we selected */
+ return 0;
+}
+
+static int pca954x_detect(struct i2c_adapter *bus, int address, int kind)
+{
+ int i, n;
+ struct i2c_client *client;
+ struct pca954x_data *data;
+ int ret = -ENODEV;
+
+ if (!i2c_check_functionality(bus, I2C_FUNC_SMBUS_BYTE))
+ goto err;
+
+ if (!(data = kzalloc(sizeof(struct pca954x_data), GFP_KERNEL))) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ client = &data->client;
+ client->addr = address;
+ client->adapter = bus;
+ client->driver = &pca954x_driver;
+ client->flags = 0;
+ i2c_set_clientdata(client, data);
+ if (kind < 0) {
+ dev_err(&bus->dev, "Attempted ill-advised probe at addr 0x%x\n",
+ address);
+ goto exit_free;
+ }
+
+ /* Read the mux register at addr. This does two things: it verifies
+ that the mux is in fact present, and fetches its current
+ contents for possible use with a future deselect algorithm.
+ */
+ if ((i = i2c_smbus_read_byte(client)) < 0) {
+ dev_warn(&bus->dev, "pca954x failed to read reg at 0x%x\n",
+ address);
+ goto exit_free;
+ }
+
+ if (kind = any_chip) {
+ dev_warn(&bus->dev, "pca954x needs advice on chip type - "
+ "wildly guessing 0x%x is a PCA9540\n", address);
+ kind = pca9540;
+ }
+
+ /* Look up in table */
+ for (i = sizeof(pca954x_chipdefs) / sizeof(pca954x_chipdefs[0]);
+ --i >= 0;) {
+ if (pca954x_chipdefs[i].type = kind)
+ break;
+ }
+ if (i < 0) {
+ dev_err(&bus->dev, "Internal error: unknown kind (%d)\n", kind);
+ goto exit_free;
+ }
+
+ data->chip_offset = i;
+
+ if ((ret = i2c_attach_client(client)))
+ goto exit_free;
+
+ /* Now create virtual busses and adapters for them */
+ for (i = 0; i < pca954x_chipdefs[data->chip_offset].nchans; i++) {
+ data->virt_adapters[i] + i2c_add_virt_adapter(bus, client, i,
+ &pca954x_select_chan,
+ &pca954x_deselect_mux);
+ if (data->virt_adapters[i] = NULL) {
+ ret = -ENODEV;
+ goto virt_reg_failed;
+ }
+ }
+
+ dev_info(&client->dev,
+ "Registered %d virtual busses for I2C %s %s\n", i,
+ pca954x_chipdefs[data->chip_offset].muxtype = pca954x_ismux ?
+ "mux" : "switch", pca954x_chipdefs[data->chip_offset].name);
+
+ return 0;
+
+virt_reg_failed:
+ for (n = 0; n < i; n++)
+ i2c_del_virt_adapter(data->virt_adapters[n]);
+ i2c_detach_client(client);
+exit_free:
+ kfree(data);
+err:
+ return ret;
+}
+
+static int pca954x_attach_adapter(struct i2c_adapter *adapter)
+{
+ return i2c_probe(adapter, &addr_data, pca954x_detect);
+}
+
+static int pca954x_detach_client(struct i2c_client *client)
+{
+ struct pca954x_data *data = i2c_get_clientdata(client);
+ struct pca954x_chipdef *chip = &pca954x_chipdefs[data->chip_offset];
+ int i, err;
+
+ for (i = 0; i < chip->nchans; ++i) {
+ if (data->virt_adapters[i]) {
+ if ((err + i2c_del_virt_adapter(data->virt_adapters[i])))
+ return err;
+ data->virt_adapters[i] = NULL;
+ }
+ }
+
+ if ((err = i2c_detach_client(client)))
+ return err;
+
+ kfree(data);
+ return 0;
+}
+
+static struct i2c_driver pca954x_driver = {
+ .driver = {
+ .name = "pca954x",
+ },
+ .id = I2C_DRIVERID_PCA954X,
+ .attach_adapter = pca954x_attach_adapter,
+ .detach_client = pca954x_detach_client,
+};
+
+static int __init pca954x_init(void)
+{
+ return i2c_add_driver(&pca954x_driver);
+}
+
+static void __exit pca954x_exit(void)
+{
+ i2c_del_driver(&pca954x_driver);
+}
+
+module_init(pca954x_init);
+module_exit(pca954x_exit);
+
+MODULE_AUTHOR("Kumar Gala <galak at kernel.crashing.org>");
+MODULE_DESCRIPTION("PCA954X I2C mux/switch driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/i2c-id.h b/include/linux/i2c-id.h
index 66d5533..f8f7f20 100644
--- a/include/linux/i2c-id.h
+++ b/include/linux/i2c-id.h
@@ -112,6 +112,7 @@
#define I2C_DRIVERID_X1205 82 /* Xicor/Intersil X1205 RTC */
#define I2C_DRIVERID_PCF8563 83 /* Philips PCF8563 RTC */
#define I2C_DRIVERID_RS5C372 84 /* Ricoh RS5C372 RTC */
+#define I2C_DRIVERID_PCA954X 85 /* pca954x I2C mux/switch */
#define I2C_DRIVERID_I2CDEV 900
#define I2C_DRIVERID_ARP 902 /* SMBus ARP Client */
^ permalink raw reply related
* Re: 2.6.16-mm1 leaks in dvb playback (found)
From: Adrian Bridgett @ 2006-03-30 23:11 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, David S. Miller, Andi Kleen
In-Reply-To: <20060330225830.GA24009@smop.co.uk>
On Thu, Mar 30, 2006 at 23:58:30 +0100 (+0100), adrian wrote:
> What I thought was just one patch was actually two and it was the
> other patch causing the problem - "Do not lose accepted socket when
> -ENFILE/-EMFILE".
Hmm - it looks like it was meant to be reverted in 2.6.16-rc1-mm4,5 FWIW.
Adrian
^ permalink raw reply
* Re: [openib-general] updated InfiniBand 2.6.17 merge plans
From: Roland Dreier @ 2006-03-30 23:11 UTC (permalink / raw)
To: openib-general; +Cc: linux-kernel
In-Reply-To: <ada1wwj1r7r.fsf@cisco.com>
Oh yeah, one other thing I plan to merge unless someone objects:
* Get rid of option for building IPoIB and mthca debug output unless EMBEDDED=y
- R.
^ permalink raw reply
* RE: ACPI_DEBUG_PRINT and ACPI_WARNING
From: Moore, Robert @ 2006-03-30 23:11 UTC (permalink / raw)
To: Moore, Robert, Brown, Len, linux-acpi
Next question would be, do the various unix flavors all have a similar
mechanism?
So, we could have something like:
ACPI_ERROR -> KERN_ERR
ACPI_WARNING -> KERN_WARNING
ACPI_EXCEPTION -> KERN_ERR?
ACPI_INFO -> KERN_INFO
ACPI_DEBUG_PRINT -> KERN_DEBUG
> -----Original Message-----
> From: Moore, Robert
> Sent: Wednesday, March 29, 2006 3:06 PM
> To: Brown, Len; linux-acpi@vger.kernel.org
> Subject: RE: ACPI_DEBUG_PRINT and ACPI_WARNING
>
> You would like an OSL interface that gets passed the debug level and
can
> map this to the host debug/error levels?
>
> > -----Original Message-----
> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> > owner@vger.kernel.org] On Behalf Of Brown, Len
> > Sent: Wednesday, March 29, 2006 2:58 PM
> > To: linux-acpi@vger.kernel.org
> > Subject: ACPI_DEBUG_PRINT and ACPI_WARNING
> >
> >
> > I think we have a problem with both ACPI_DEBUG_PRINT and
ACPI_WARNING
> > and how these ACPI core macros work on Linux.
> >
> > ACPI_WARNING is an improvement over the past where all the
> > ACPI_DEBUG_PRINT messages went away on a production kernel.
> >
> > ACPI_DEBUG_PRINT is very handy in that via acpi_ut_print()
> > you can turn them on and off on your debug kernel depending
> > on the level and section of code.
> >
> > But both funnel through osl.c where there is no native Linux
> > print level associated with the message, and thus if it gets
> > that far, it unconditionaly gets printed to the screen and
> > log buffer, no mater how the system has been administered
> > to handle messages of different levels.
> >
> > ie. the kernel.h levels are not used:
> >
> > #define KERN_EMERG "<0>" /* system is unusable
> > */
> > #define KERN_ALERT "<1>" /* action must be taken
immediately
> > */
> > #define KERN_CRIT "<2>" /* critical conditions
> > */
> > #define KERN_ERR "<3>" /* error conditions
> > */
> > #define KERN_WARNING "<4>" /* warning conditions
> > */
> > #define KERN_NOTICE "<5>" /* normal but significant
condition
> > */
> > #define KERN_INFO "<6>" /* informational
> > */
> > #define KERN_DEBUG "<7>" /* debug-level messages
> > */
> >
> > thoughts?
> >
> > -Len
> > -
> > To unsubscribe from this list: send the line "unsubscribe
linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [LARTC] tcsim
From: Larry Brigman @ 2006-03-30 23:11 UTC (permalink / raw)
To: lartc
I know that tcng is old but I have a question about it.
Was there ever a way to inject real traffic into the simulation,
something like the
output of tcpreplay?
Thanks,
Larry
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [PATCH][UPDATE] i2c: Add support for virtual I2C adapters
From: Kumar Gala @ 2006-03-30 23:05 UTC (permalink / raw)
To: khali; +Cc: linux-kernel, lm-sensors, Greg KH
Virtual adapters are useful to handle multiplexed I2C bus topologies, by
presenting each multiplexed segment as a I2C adapter. Typically, either
a mux (or switch) exists which is an I2C device on the parent bus. One
selects a given child bus via programming the mux and then all the devices
on that bus become present on the parent bus. The intent is to allow
multiple devices of the same type to exist in a system which would normally
have address conflicts.
Since virtual adapters will get registered in an I2C client's detect
function we have to expose versions of i2c_{add,del}_adapter for
i2c_{add,del}_virt_adapter to call that don't lock.
Additionally, i2c_virt_master_xfer (and i2c_virt_smbus_xfer) acquire
the parent->bus_lock and call the parent's master_xfer directly. This
is because on a i2c_virt_master_xfer we have issue an i2c write on
the parent bus to select the given virtual adapter, then do the i2c
operation on the parent bus, followed by another i2c write on the
parent to deslect the virtual adapter.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit 862cbc263e3d3e44028d7465a912847cf5366163
tree 2c91bad8eb66cab9727f3071831a916ada41edf8
parent 5d4fe2c1ce83c3e967ccc1ba3d580c1a5603a866
author Kumar Gala <galak@kernel.crashing.org> Thu, 30 Mar 2006 17:03:42 -0600
committer Kumar Gala <galak@kernel.crashing.org> Thu, 30 Mar 2006 17:03:42 -0600
drivers/i2c/Kconfig | 9 ++
drivers/i2c/Makefile | 1
drivers/i2c/i2c-core.c | 42 ++++++++----
drivers/i2c/i2c-virt.c | 173 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/i2c-id.h | 2 +
include/linux/i2c.h | 20 ++++++
6 files changed, 234 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 24383af..b8a8fc1 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -34,6 +34,15 @@ config I2C_CHARDEV
This support is also available as a module. If so, the module
will be called i2c-dev.
+config I2C_VIRT
+ tristate "I2C virtual adapter support"
+ depends on I2C
+ help
+ Say Y here if you want the I2C core to support the ability to have
+ virtual adapters. Virtual adapters are useful to handle multiplexed
+ I2C bus topologies, by presenting each multiplexed segment as a
+ I2C adapter.
+
source drivers/i2c/algos/Kconfig
source drivers/i2c/busses/Kconfig
source drivers/i2c/chips/Kconfig
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 71c5a85..4467db2 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_I2C) += i2c-core.o
+obj-$(CONFIG_I2C_VIRT) += i2c-virt.o
obj-$(CONFIG_I2C_CHARDEV) += i2c-dev.o
obj-y += busses/ chips/ algos/
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 45e2cdf..64c1c9e 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -150,22 +150,31 @@ static struct device_attribute dev_attr_
*/
int i2c_add_adapter(struct i2c_adapter *adap)
{
+ int res;
+
+ mutex_lock(&core_lists);
+ res = i2c_add_adapter_nolock(adap);
+ mutex_unlock(&core_lists);
+
+ return res;
+}
+
+int i2c_add_adapter_nolock(struct i2c_adapter *adap)
+{
int id, res = 0;
struct list_head *item;
struct i2c_driver *driver;
- mutex_lock(&core_lists);
-
if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) == 0) {
res = -ENOMEM;
- goto out_unlock;
+ goto out;
}
res = idr_get_new(&i2c_adapter_idr, adap, &id);
if (res < 0) {
if (res == -EAGAIN)
res = -ENOMEM;
- goto out_unlock;
+ goto out;
}
adap->nr = id & MAX_ID_MASK;
@@ -203,21 +212,29 @@ int i2c_add_adapter(struct i2c_adapter *
driver->attach_adapter(adap);
}
-out_unlock:
- mutex_unlock(&core_lists);
+out:
return res;
}
-
int i2c_del_adapter(struct i2c_adapter *adap)
{
+ int res;
+
+ mutex_lock(&core_lists);
+ res = i2c_del_adapter_nolock(adap);
+ mutex_unlock(&core_lists);
+
+ return res;
+}
+
+int i2c_del_adapter_nolock(struct i2c_adapter *adap)
+{
struct list_head *item, *_n;
struct i2c_adapter *adap_from_list;
struct i2c_driver *driver;
struct i2c_client *client;
int res = 0;
- mutex_lock(&core_lists);
/* First make sure that this adapter was ever added */
list_for_each_entry(adap_from_list, &adapters, list) {
@@ -228,7 +245,7 @@ int i2c_del_adapter(struct i2c_adapter *
pr_debug("i2c-core: attempting to delete unregistered "
"adapter [%s]\n", adap->name);
res = -EINVAL;
- goto out_unlock;
+ goto out;
}
list_for_each(item,&drivers) {
@@ -238,7 +255,7 @@ int i2c_del_adapter(struct i2c_adapter *
dev_err(&adap->dev, "detach_adapter failed "
"for driver [%s]\n",
driver->driver.name);
- goto out_unlock;
+ goto out;
}
}
@@ -251,7 +268,7 @@ int i2c_del_adapter(struct i2c_adapter *
dev_err(&adap->dev, "detach_client failed for client "
"[%s] at address 0x%02x\n", client->name,
client->addr);
- goto out_unlock;
+ goto out;
}
}
@@ -272,8 +289,7 @@ int i2c_del_adapter(struct i2c_adapter *
dev_dbg(&adap->dev, "adapter [%s] unregistered\n", adap->name);
- out_unlock:
- mutex_unlock(&core_lists);
+out:
return res;
}
diff --git a/drivers/i2c/i2c-virt.c b/drivers/i2c/i2c-virt.c
new file mode 100644
index 0000000..2bd9ea3
--- /dev/null
+++ b/drivers/i2c/i2c-virt.c
@@ -0,0 +1,173 @@
+/*
+ * i2c-virtual.c - Virtual I2C bus driver.
+ *
+ * Simplifies access to complex multiplexed I2C bus topologies, by presenting
+ * each multiplexed bus segment as a virtual I2C adapter. Supports multi-level
+ * mux'ing (mux behind a mux).
+ *
+ * Based on:
+ * i2c-virtual.c from Copyright (c) 2004 Google, Inc. (Ken Harrenstien)
+ * i2c-virtual.c from Brian Kuschak <bkuschak@yahoo.com>
+ * which was:
+ * Adapted from i2c-adap-ibm_ocp.c
+ * Original file Copyright 2000-2002 MontaVista Software Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/i2c-id.h>
+
+struct i2c_virt_priv {
+ struct i2c_adapter *parent_adap;
+ struct i2c_client *client; /* The mux chip/device */
+
+ u32 id; /* the mux id */
+
+ /* fn which enables the mux */
+ int (*select) (struct i2c_adapter *, struct i2c_client *, u32);
+
+ /* fn which disables the mux */
+ int (*deselect) (struct i2c_adapter *, struct i2c_client *, u32);
+};
+
+#define VIRT_TIMEOUT (HZ/2)
+#define VIRT_RETRIES 3
+
+static int
+i2c_virt_master_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
+{
+ struct i2c_virt_priv *priv = adap->algo_data;
+ struct i2c_adapter *parent = priv->parent_adap;
+ int ret;
+
+ /* Grab the lock for the parent adapter. We already hold the lock for
+ the virtual adapter. Then select the right mux port and perform
+ the transfer.
+ */
+
+ mutex_lock(&parent->bus_lock);
+ if ((ret = priv->select(parent, priv->client, priv->id)) >= 0) {
+ ret = parent->algo->master_xfer(parent, msgs, num);
+ }
+ priv->deselect(parent, priv->client, priv->id);
+ mutex_unlock(&parent->bus_lock);
+
+ return ret;
+}
+
+static int
+i2c_virt_smbus_xfer(struct i2c_adapter *adap, u16 addr,
+ unsigned short flags, char read_write,
+ u8 command, int size, union i2c_smbus_data *data)
+{
+ struct i2c_virt_priv *priv = adap->algo_data;
+ struct i2c_adapter *parent = priv->parent_adap;
+ int ret;
+
+ /* Grab the lock for the parent adapter. We already hold the lock for
+ the virtual adapter. Then select the right mux port and perform
+ the transfer.
+ */
+
+ mutex_lock(&parent->bus_lock);
+ if ((ret = priv->select(parent, priv->client, priv->id)) == 0) {
+ ret = parent->algo->smbus_xfer(parent, addr, flags,
+ read_write, command, size, data);
+ }
+ priv->deselect(parent, priv->client, priv->id);
+ mutex_unlock(&parent->bus_lock);
+
+ return ret;
+}
+
+/* return the parent's functionality for the virtual adapter */
+static u32 i2c_virt_functionality(struct i2c_adapter *adap)
+{
+ struct i2c_virt_priv *priv = adap->algo_data;
+ struct i2c_adapter *parent = priv->parent_adap;
+
+ return parent->algo->functionality(parent);
+}
+
+struct i2c_adapter *
+i2c_add_virt_adapter(struct i2c_adapter *parent, struct i2c_client *client,
+ u32 mux_val,
+ int (*select_cb) (struct i2c_adapter *,
+ struct i2c_client *, u32),
+ int (*deselect_cb) (struct i2c_adapter *,
+ struct i2c_client *, u32))
+{
+ struct i2c_adapter *adap;
+ struct i2c_virt_priv *priv;
+ struct i2c_algorithm *algo;
+
+ if (!(adap = kzalloc(sizeof(struct i2c_adapter)
+ + sizeof(struct i2c_virt_priv)
+ + sizeof(struct i2c_algorithm), GFP_KERNEL)))
+ return NULL;
+
+ priv = (struct i2c_virt_priv *)(adap + 1);
+ algo = (struct i2c_algorithm *)(priv + 1);
+
+ /* Set up private adapter data */
+ priv->parent_adap = parent;
+ priv->client = client;
+ priv->id = mux_val;
+ priv->select = select_cb;
+ priv->deselect = deselect_cb;
+
+ /* Need to do algo dynamically because we don't know ahead
+ of time what sort of physical adapter we'll be dealing with.
+ */
+ algo->master_xfer = (parent->algo->master_xfer
+ ? i2c_virt_master_xfer : NULL);
+ algo->smbus_xfer = (parent->algo->smbus_xfer
+ ? i2c_virt_smbus_xfer : NULL);
+ algo->functionality = i2c_virt_functionality;
+
+ /* Now fill out new adapter structure */
+ snprintf(adap->name, sizeof(adap->name),
+ "Virtual I2C (i2c-%d, mux %02x:%02x)",
+ i2c_adapter_id(parent), client->addr, mux_val);
+ adap->id = I2C_HW_VIRT | i2c_adapter_id(parent);
+ adap->algo = algo;
+ adap->algo_data = priv;
+ adap->timeout = VIRT_TIMEOUT;
+ adap->retries = VIRT_RETRIES;
+ adap->dev.parent = &parent->dev;
+
+ if (i2c_add_adapter_nolock(adap) < 0) {
+ kfree(adap);
+ return NULL;
+ }
+
+ printk(KERN_NOTICE "i2c-%d: Virtual I2C bus "
+ "(Physical bus i2c-%d, multiplexer 0x%02x port %d)\n",
+ i2c_adapter_id(adap), i2c_adapter_id(parent),
+ client->addr, mux_val);
+
+ return adap;
+}
+
+int i2c_del_virt_adapter(struct i2c_adapter *adap)
+{
+ int ret;
+
+ if ((ret = i2c_del_adapter_nolock(adap)) < 0)
+ return ret;
+ kfree(adap);
+
+ return 0;
+}
+
+EXPORT_SYMBOL_GPL(i2c_add_virt_adapter);
+EXPORT_SYMBOL_GPL(i2c_del_virt_adapter);
+
+MODULE_AUTHOR("Kumar Gala <galak@kernel.crashing.org>");
+MODULE_DESCRIPTION("Virtual I2C driver for multiplexed I2C busses");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/i2c-id.h b/include/linux/i2c-id.h
index c8b81f4..66d5533 100644
--- a/include/linux/i2c-id.h
+++ b/include/linux/i2c-id.h
@@ -265,4 +265,6 @@
#define I2C_HW_SAA7146 0x060000 /* SAA7146 video decoder bus */
#define I2C_HW_SAA7134 0x090000 /* SAA7134 video decoder bus */
+#define I2C_HW_VIRT 0x80000000 /* a virtual adapter */
+
#endif /* LINUX_I2C_ID_H */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 1635ee2..ba41f97 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -294,6 +294,10 @@ struct i2c_client_address_data {
extern int i2c_add_adapter(struct i2c_adapter *);
extern int i2c_del_adapter(struct i2c_adapter *);
+/* Assume the caller has the core_list lock already */
+extern int i2c_add_adapter_nolock(struct i2c_adapter *);
+extern int i2c_del_adapter_nolock(struct i2c_adapter *);
+
extern int i2c_register_driver(struct module *, struct i2c_driver *);
extern int i2c_del_driver(struct i2c_driver *);
@@ -440,6 +444,22 @@ union i2c_smbus_data {
#define I2C_SMBUS_I2C_BLOCK_DATA 6
#define I2C_SMBUS_BLOCK_PROC_CALL 7 /* SMBus 2.0 */
+/*
+ * Called to create a 'virtual' i2c bus which represents a multiplexed bus
+ * segment. The client and mux_val are passed to the select and deselect
+ * callback functions to perform hardware-specific mux control.
+ *
+ * The caller is expected to have the core_lists lock
+ */
+struct i2c_adapter *
+i2c_add_virt_adapter(struct i2c_adapter *parent, struct i2c_client *client,
+ u32 mux_val,
+ int (*select_cb) (struct i2c_adapter *,
+ struct i2c_client *, u32),
+ int (*deselect_cb) (struct i2c_adapter *,
+ struct i2c_client *, u32));
+
+int i2c_del_virt_adapter(struct i2c_adapter *adap);
/* ----- commands for the ioctl like i2c_command call:
* note that additional calls are defined in the algorithm and hw
^ permalink raw reply related
* Re: [patch 1/1] pc-speaker: add SND_SILENT
From: Edgar Toernig @ 2006-03-30 23:07 UTC (permalink / raw)
To: Vojtech Pavlik
Cc: Bodo Eggert, Joseph Fannin, Stas Sergeev, dtor_core, Linux kernel
In-Reply-To: <20060328185147.GA6475@suse.cz>
Vojtech Pavlik wrote:
>
> On Tue, Mar 28, 2006 at 08:43:35PM +0200, Bodo Eggert wrote:
> > On Tue, 28 Mar 2006, Joseph Fannin wrote:
> >
> > > I would think the ideal situation would be to make every ALSA
> > > device capable of acting as the console bell (defaulting to muted,
> > > like every other ALSA mixer control). Then only pcspkr would be the
> > > odd case (though maybe a common one).
> > >
> > > I dunno if there's a reasonably easy way to do that (without
> > > changing every ALSA driver) though.
> >
> > I think that should be done using a userspace input device if possible.
>
> It certainly is. That way configuring the exact sound it makes would
> also possible. The latency might be a problem, though.
Latency is no problem. I'm using a userspace daemon to emulate
the console beeper for about 6 months now and it work's very well.
The daemon listens on /dev/input/eventX and when receiving a
SND_TONE it opens /dev/dspY (a cheap USB-speaker), produces its
bing and closes the audio dev after some seconds with no SND_TONE.
Latency isn't noticable and memory footprint is small.
Sure, if ALSA could emit console beeps on any audio device even if
it is in use I would definitely use it and trash the USB-speaker.
But the userspace daemon is OK...
Ciao, ET.
PS:
<rant>
It would have been even better if Shuttle had connected the beeper
output of the IT87 to the beeper input of the ALC650 in the first
place. But no, this thing is totally silent - no piezo beeper, no
routing to the sound codec, no POST-beeps, nothing.
Why are manufacturers doing such silly things?
</rant>
^ permalink raw reply
* Re: sata controllers status=0x51 { DriveReady SeekComplete Error } error=0x84 { DriveStatusError BadCRC }
From: mitchell laks @ 2006-03-30 23:07 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <442C14A8.4030606@dgreaves.com>
David Greaves <david <at> dgreaves.com> writes:
>
> Check out the linux-ide archive for my (and others) reports.
I just read them and weeped.
>
> I've had lots of issues like this - spurious and IMHO incorrect error
> messages. Only certain types of disk access cause them - xfs_repair and
> rsync seem to tickle it.
Interesting. rsync for me.
> With 2.6.15 I had lots of *very* scary moments with multiple disk
> failures on a raid5 during xfs_repair.
> I think it's down to the 'basic' error handling in the libata code and
> certain disks/controllers being loose with the protocol. They then
> identified problems in 'fua' (IIRC) handling which was pulled for 2.6.16.
>
> 2.6.16 seems to be much better (fewer 'odd' errors reported and md
> doesn't mind)
"Fewer" - oh oh. Can you quantify this for me? I seem to be getting around
8-9 /10 days = or averaging about 1 per rsync.
I should check to see if the distribution is Poisson like distribution :).
I have not lost my raid1 yet. lucky me.
I am now very worried.
I need to do some testing off line with the new kernel before
putting out the fix.
Is your experience also with an Asus board with a via vt8237 powered
sata connector?
Would you suggest I try the promise sata connector instead, before
I try to move
over to the newer kernel? Or both?
Could you give me more of your experience?
Thanks,
Mitchell
Thanks
^ permalink raw reply
* [lm-sensors] [PATCH][UPDATE] i2c: Add support for virtual I2C
From: Kumar Gala @ 2006-03-30 23:05 UTC (permalink / raw)
To: khali; +Cc: linux-kernel, lm-sensors, Greg KH
Virtual adapters are useful to handle multiplexed I2C bus topologies, by
presenting each multiplexed segment as a I2C adapter. Typically, either
a mux (or switch) exists which is an I2C device on the parent bus. One
selects a given child bus via programming the mux and then all the devices
on that bus become present on the parent bus. The intent is to allow
multiple devices of the same type to exist in a system which would normally
have address conflicts.
Since virtual adapters will get registered in an I2C client's detect
function we have to expose versions of i2c_{add,del}_adapter for
i2c_{add,del}_virt_adapter to call that don't lock.
Additionally, i2c_virt_master_xfer (and i2c_virt_smbus_xfer) acquire
the parent->bus_lock and call the parent's master_xfer directly. This
is because on a i2c_virt_master_xfer we have issue an i2c write on
the parent bus to select the given virtual adapter, then do the i2c
operation on the parent bus, followed by another i2c write on the
parent to deslect the virtual adapter.
Signed-off-by: Kumar Gala <galak at kernel.crashing.org>
---
commit 862cbc263e3d3e44028d7465a912847cf5366163
tree 2c91bad8eb66cab9727f3071831a916ada41edf8
parent 5d4fe2c1ce83c3e967ccc1ba3d580c1a5603a866
author Kumar Gala <galak at kernel.crashing.org> Thu, 30 Mar 2006 17:03:42 -0600
committer Kumar Gala <galak at kernel.crashing.org> Thu, 30 Mar 2006 17:03:42 -0600
drivers/i2c/Kconfig | 9 ++
drivers/i2c/Makefile | 1
drivers/i2c/i2c-core.c | 42 ++++++++----
drivers/i2c/i2c-virt.c | 173 ++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/i2c-id.h | 2 +
include/linux/i2c.h | 20 ++++++
6 files changed, 234 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 24383af..b8a8fc1 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -34,6 +34,15 @@ config I2C_CHARDEV
This support is also available as a module. If so, the module
will be called i2c-dev.
+config I2C_VIRT
+ tristate "I2C virtual adapter support"
+ depends on I2C
+ help
+ Say Y here if you want the I2C core to support the ability to have
+ virtual adapters. Virtual adapters are useful to handle multiplexed
+ I2C bus topologies, by presenting each multiplexed segment as a
+ I2C adapter.
+
source drivers/i2c/algos/Kconfig
source drivers/i2c/busses/Kconfig
source drivers/i2c/chips/Kconfig
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 71c5a85..4467db2 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_I2C) += i2c-core.o
+obj-$(CONFIG_I2C_VIRT) += i2c-virt.o
obj-$(CONFIG_I2C_CHARDEV) += i2c-dev.o
obj-y += busses/ chips/ algos/
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 45e2cdf..64c1c9e 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -150,22 +150,31 @@ static struct device_attribute dev_attr_
*/
int i2c_add_adapter(struct i2c_adapter *adap)
{
+ int res;
+
+ mutex_lock(&core_lists);
+ res = i2c_add_adapter_nolock(adap);
+ mutex_unlock(&core_lists);
+
+ return res;
+}
+
+int i2c_add_adapter_nolock(struct i2c_adapter *adap)
+{
int id, res = 0;
struct list_head *item;
struct i2c_driver *driver;
- mutex_lock(&core_lists);
-
if (idr_pre_get(&i2c_adapter_idr, GFP_KERNEL) = 0) {
res = -ENOMEM;
- goto out_unlock;
+ goto out;
}
res = idr_get_new(&i2c_adapter_idr, adap, &id);
if (res < 0) {
if (res = -EAGAIN)
res = -ENOMEM;
- goto out_unlock;
+ goto out;
}
adap->nr = id & MAX_ID_MASK;
@@ -203,21 +212,29 @@ int i2c_add_adapter(struct i2c_adapter *
driver->attach_adapter(adap);
}
-out_unlock:
- mutex_unlock(&core_lists);
+out:
return res;
}
-
int i2c_del_adapter(struct i2c_adapter *adap)
{
+ int res;
+
+ mutex_lock(&core_lists);
+ res = i2c_del_adapter_nolock(adap);
+ mutex_unlock(&core_lists);
+
+ return res;
+}
+
+int i2c_del_adapter_nolock(struct i2c_adapter *adap)
+{
struct list_head *item, *_n;
struct i2c_adapter *adap_from_list;
struct i2c_driver *driver;
struct i2c_client *client;
int res = 0;
- mutex_lock(&core_lists);
/* First make sure that this adapter was ever added */
list_for_each_entry(adap_from_list, &adapters, list) {
@@ -228,7 +245,7 @@ int i2c_del_adapter(struct i2c_adapter *
pr_debug("i2c-core: attempting to delete unregistered "
"adapter [%s]\n", adap->name);
res = -EINVAL;
- goto out_unlock;
+ goto out;
}
list_for_each(item,&drivers) {
@@ -238,7 +255,7 @@ int i2c_del_adapter(struct i2c_adapter *
dev_err(&adap->dev, "detach_adapter failed "
"for driver [%s]\n",
driver->driver.name);
- goto out_unlock;
+ goto out;
}
}
@@ -251,7 +268,7 @@ int i2c_del_adapter(struct i2c_adapter *
dev_err(&adap->dev, "detach_client failed for client "
"[%s] at address 0x%02x\n", client->name,
client->addr);
- goto out_unlock;
+ goto out;
}
}
@@ -272,8 +289,7 @@ int i2c_del_adapter(struct i2c_adapter *
dev_dbg(&adap->dev, "adapter [%s] unregistered\n", adap->name);
- out_unlock:
- mutex_unlock(&core_lists);
+out:
return res;
}
diff --git a/drivers/i2c/i2c-virt.c b/drivers/i2c/i2c-virt.c
new file mode 100644
index 0000000..2bd9ea3
--- /dev/null
+++ b/drivers/i2c/i2c-virt.c
@@ -0,0 +1,173 @@
+/*
+ * i2c-virtual.c - Virtual I2C bus driver.
+ *
+ * Simplifies access to complex multiplexed I2C bus topologies, by presenting
+ * each multiplexed bus segment as a virtual I2C adapter. Supports multi-level
+ * mux'ing (mux behind a mux).
+ *
+ * Based on:
+ * i2c-virtual.c from Copyright (c) 2004 Google, Inc. (Ken Harrenstien)
+ * i2c-virtual.c from Brian Kuschak <bkuschak at yahoo.com>
+ * which was:
+ * Adapted from i2c-adap-ibm_ocp.c
+ * Original file Copyright 2000-2002 MontaVista Software Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/i2c-id.h>
+
+struct i2c_virt_priv {
+ struct i2c_adapter *parent_adap;
+ struct i2c_client *client; /* The mux chip/device */
+
+ u32 id; /* the mux id */
+
+ /* fn which enables the mux */
+ int (*select) (struct i2c_adapter *, struct i2c_client *, u32);
+
+ /* fn which disables the mux */
+ int (*deselect) (struct i2c_adapter *, struct i2c_client *, u32);
+};
+
+#define VIRT_TIMEOUT (HZ/2)
+#define VIRT_RETRIES 3
+
+static int
+i2c_virt_master_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
+{
+ struct i2c_virt_priv *priv = adap->algo_data;
+ struct i2c_adapter *parent = priv->parent_adap;
+ int ret;
+
+ /* Grab the lock for the parent adapter. We already hold the lock for
+ the virtual adapter. Then select the right mux port and perform
+ the transfer.
+ */
+
+ mutex_lock(&parent->bus_lock);
+ if ((ret = priv->select(parent, priv->client, priv->id)) >= 0) {
+ ret = parent->algo->master_xfer(parent, msgs, num);
+ }
+ priv->deselect(parent, priv->client, priv->id);
+ mutex_unlock(&parent->bus_lock);
+
+ return ret;
+}
+
+static int
+i2c_virt_smbus_xfer(struct i2c_adapter *adap, u16 addr,
+ unsigned short flags, char read_write,
+ u8 command, int size, union i2c_smbus_data *data)
+{
+ struct i2c_virt_priv *priv = adap->algo_data;
+ struct i2c_adapter *parent = priv->parent_adap;
+ int ret;
+
+ /* Grab the lock for the parent adapter. We already hold the lock for
+ the virtual adapter. Then select the right mux port and perform
+ the transfer.
+ */
+
+ mutex_lock(&parent->bus_lock);
+ if ((ret = priv->select(parent, priv->client, priv->id)) = 0) {
+ ret = parent->algo->smbus_xfer(parent, addr, flags,
+ read_write, command, size, data);
+ }
+ priv->deselect(parent, priv->client, priv->id);
+ mutex_unlock(&parent->bus_lock);
+
+ return ret;
+}
+
+/* return the parent's functionality for the virtual adapter */
+static u32 i2c_virt_functionality(struct i2c_adapter *adap)
+{
+ struct i2c_virt_priv *priv = adap->algo_data;
+ struct i2c_adapter *parent = priv->parent_adap;
+
+ return parent->algo->functionality(parent);
+}
+
+struct i2c_adapter *
+i2c_add_virt_adapter(struct i2c_adapter *parent, struct i2c_client *client,
+ u32 mux_val,
+ int (*select_cb) (struct i2c_adapter *,
+ struct i2c_client *, u32),
+ int (*deselect_cb) (struct i2c_adapter *,
+ struct i2c_client *, u32))
+{
+ struct i2c_adapter *adap;
+ struct i2c_virt_priv *priv;
+ struct i2c_algorithm *algo;
+
+ if (!(adap = kzalloc(sizeof(struct i2c_adapter)
+ + sizeof(struct i2c_virt_priv)
+ + sizeof(struct i2c_algorithm), GFP_KERNEL)))
+ return NULL;
+
+ priv = (struct i2c_virt_priv *)(adap + 1);
+ algo = (struct i2c_algorithm *)(priv + 1);
+
+ /* Set up private adapter data */
+ priv->parent_adap = parent;
+ priv->client = client;
+ priv->id = mux_val;
+ priv->select = select_cb;
+ priv->deselect = deselect_cb;
+
+ /* Need to do algo dynamically because we don't know ahead
+ of time what sort of physical adapter we'll be dealing with.
+ */
+ algo->master_xfer = (parent->algo->master_xfer
+ ? i2c_virt_master_xfer : NULL);
+ algo->smbus_xfer = (parent->algo->smbus_xfer
+ ? i2c_virt_smbus_xfer : NULL);
+ algo->functionality = i2c_virt_functionality;
+
+ /* Now fill out new adapter structure */
+ snprintf(adap->name, sizeof(adap->name),
+ "Virtual I2C (i2c-%d, mux %02x:%02x)",
+ i2c_adapter_id(parent), client->addr, mux_val);
+ adap->id = I2C_HW_VIRT | i2c_adapter_id(parent);
+ adap->algo = algo;
+ adap->algo_data = priv;
+ adap->timeout = VIRT_TIMEOUT;
+ adap->retries = VIRT_RETRIES;
+ adap->dev.parent = &parent->dev;
+
+ if (i2c_add_adapter_nolock(adap) < 0) {
+ kfree(adap);
+ return NULL;
+ }
+
+ printk(KERN_NOTICE "i2c-%d: Virtual I2C bus "
+ "(Physical bus i2c-%d, multiplexer 0x%02x port %d)\n",
+ i2c_adapter_id(adap), i2c_adapter_id(parent),
+ client->addr, mux_val);
+
+ return adap;
+}
+
+int i2c_del_virt_adapter(struct i2c_adapter *adap)
+{
+ int ret;
+
+ if ((ret = i2c_del_adapter_nolock(adap)) < 0)
+ return ret;
+ kfree(adap);
+
+ return 0;
+}
+
+EXPORT_SYMBOL_GPL(i2c_add_virt_adapter);
+EXPORT_SYMBOL_GPL(i2c_del_virt_adapter);
+
+MODULE_AUTHOR("Kumar Gala <galak at kernel.crashing.org>");
+MODULE_DESCRIPTION("Virtual I2C driver for multiplexed I2C busses");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/i2c-id.h b/include/linux/i2c-id.h
index c8b81f4..66d5533 100644
--- a/include/linux/i2c-id.h
+++ b/include/linux/i2c-id.h
@@ -265,4 +265,6 @@
#define I2C_HW_SAA7146 0x060000 /* SAA7146 video decoder bus */
#define I2C_HW_SAA7134 0x090000 /* SAA7134 video decoder bus */
+#define I2C_HW_VIRT 0x80000000 /* a virtual adapter */
+
#endif /* LINUX_I2C_ID_H */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 1635ee2..ba41f97 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -294,6 +294,10 @@ struct i2c_client_address_data {
extern int i2c_add_adapter(struct i2c_adapter *);
extern int i2c_del_adapter(struct i2c_adapter *);
+/* Assume the caller has the core_list lock already */
+extern int i2c_add_adapter_nolock(struct i2c_adapter *);
+extern int i2c_del_adapter_nolock(struct i2c_adapter *);
+
extern int i2c_register_driver(struct module *, struct i2c_driver *);
extern int i2c_del_driver(struct i2c_driver *);
@@ -440,6 +444,22 @@ union i2c_smbus_data {
#define I2C_SMBUS_I2C_BLOCK_DATA 6
#define I2C_SMBUS_BLOCK_PROC_CALL 7 /* SMBus 2.0 */
+/*
+ * Called to create a 'virtual' i2c bus which represents a multiplexed bus
+ * segment. The client and mux_val are passed to the select and deselect
+ * callback functions to perform hardware-specific mux control.
+ *
+ * The caller is expected to have the core_lists lock
+ */
+struct i2c_adapter *
+i2c_add_virt_adapter(struct i2c_adapter *parent, struct i2c_client *client,
+ u32 mux_val,
+ int (*select_cb) (struct i2c_adapter *,
+ struct i2c_client *, u32),
+ int (*deselect_cb) (struct i2c_adapter *,
+ struct i2c_client *, u32));
+
+int i2c_del_virt_adapter(struct i2c_adapter *adap);
/* ----- commands for the ioctl like i2c_command call:
* note that additional calls are defined in the algorithm and hw
^ permalink raw reply related
* [U-Boot-Users] [PATCH] SPI relocation fix
From: Wolfgang Denk @ 2006-03-30 23:05 UTC (permalink / raw)
To: u-boot
In-Reply-To: <11437528271561-git-send-email-davidho@nanometrics.ca>
In message <11437528271561-git-send-email-davidho@nanometrics.ca> you wrote:
> Signed-off-by: David Ho <davidho@nanometrics.ca>
No CHANGELOG entry. No description what you're doing and why.
> + if (!mpc8xx_new_core()) {
> + /* Disable relocation */
> + spi->spi_rpbase = 0;
> + }
Also, I don't like the name "mpc8xx_new_core". What's "new"? It is
not exactly new by today, and will definitely not be new any more in
a year from now.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Obviously, a major malfunction has occurred."
-- Steve Nesbitt, voice of Mission Control, January 28,
1986, as the shuttle Challenger exploded within view
of the grandstands.
^ permalink raw reply
* Re: [PATCH] isd200: limit to BLK_DEV_IDE
From: Linus Torvalds @ 2006-03-30 23:03 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Beber, Greg KH, linux-kernel, stable, beber, akpm
In-Reply-To: <Pine.LNX.4.58.0603301431560.26598@shark.he.net>
On Thu, 30 Mar 2006, Randy.Dunlap wrote:
>
> Limit USB_STORAGE_ISD200 to whatever BLK_DEV_IDE and USB_STORAGE
> are set to (y, m) since isd200 calls ide_fix_driveid() in the
> BLK_DEV_IDE code.
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> ---
> drivers/usb/storage/Kconfig | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2616-z.orig/drivers/usb/storage/Kconfig
> +++ linux-2616-z/drivers/usb/storage/Kconfig
> @@ -48,7 +48,7 @@ config USB_STORAGE_FREECOM
>
> config USB_STORAGE_ISD200
> bool "ISD-200 USB/ATA Bridge support"
> - depends on USB_STORAGE && BLK_DEV_IDE
> + depends on USB_STORAGE && (BLK_DEV_IDE=y || BLK_DEV_IDE=m && USB_STORAGE=m)
Hmm. That expression is _really_ hard to figure out.
It would be more logical to make it
depends on USB_STORAGE && (BLK_DEV_IDE=y || BLK_DEV_IDE=USB_STORAGE)
or, even more preferably, split up the rules as two separate dependencies:
depends on USB_STORAGE
depends on BLK_DEV_IDE=y || BLK_DEV_IDE=USB_STORAGE
(where that second thing really _should_ be expressible as
depends on BLK_DEV_IDE >= USB_STORAGE
but the kconfig language doesn't support that syntax..)
Linus
^ permalink raw reply
* Re: Hook collie frontlight into sysfs
From: Richard Purdie @ 2006-03-30 22:59 UTC (permalink / raw)
To: Pavel Machek; +Cc: lenz, kernel list, patches, Bompart Cedric
In-Reply-To: <20060330114609.GA14505@elf.ucw.cz>
On Thu, 2006-03-30 at 13:46 +0200, Pavel Machek wrote:
> Hook backlight handling into backlight subsystem, so that backlight is
> controllable using /sys . I had to shuffle code around a bit in order
> to avoid prototypes.
Hi Pavel,
There are a few issues with this. Firstly,
CC arch/arm/common/locomo.o
arch/arm/common/locomo.c: In function `locomo_frontlight_set':
arch/arm/common/locomo.c:1061: error: `LOCOMO_ALC_EN' undeclared (first use in this function)
arch/arm/common/locomo.c:1061: error: (Each undeclared identifier is reported only once
arch/arm/common/locomo.c:1061: error: for each function it appears in.)
make[1]: *** [arch/arm/common/locomo.o] Error 1
> diff --git a/drivers/video/backlight/locomolcd.c b/drivers/video/backlight/locomolcd.c
> index 60831bb..a95cd25 100644
> --- a/drivers/video/backlight/locomolcd.c
> +++ b/drivers/video/backlight/locomolcd.c
> @@ -105,6 +106,38 @@ void locomolcd_power(int on)
> }
> EXPORT_SYMBOL(locomolcd_power);
>
> +
> +static int current_intensity;
> +
> +static int set_intensity(struct backlight_device *bd, int intensity)
> +{
> + switch (intensity) {
> + /* AC and non-AC are handled differently, but produce same results in sharp code? */
> + case 0: locomo_frontlight_set(locomolcd_dev, 0, 0, 161); break;
> + case 1: locomo_frontlight_set(locomolcd_dev, 117, 0, 161); break;
> + case 2: locomo_frontlight_set(locomolcd_dev, 163, 0, 148); break;
> + case 3: locomo_frontlight_set(locomolcd_dev, 194, 0, 161); break;
> + case 4: locomo_frontlight_set(locomolcd_dev, 194, 1, 161); break;
> +
> + default:
> + locomo_frontlight_set(locomolcd_dev, intensity, 0, 148); break;
> + }
> + current_intensity = intensity;
> + return 0;
> +}
That default statement gives cause for concern. Should it not return
-EINVAL for intensities outside of 0-4?
> +static int get_intensity(struct backlight_device *bd)
> +{
> + return current_intensity;
> +}
> +
> +static struct backlight_properties locomobl_data = {
> + .owner = THIS_MODULE,
> + .get_brightness = get_intensity,
> + .set_brightness = set_intensity,
> + .max_brightness = 5,
Maximum brightness is 4 above?
> +};
> +
> static int poodle_lcd_probe(struct locomo_dev *dev)
> {
> unsigned long flags;
> @@ -147,8 +183,13 @@ static int __init poodle_lcd_init(void)
>
> #ifdef CONFIG_SA1100_COLLIE
> sa1100fb_lcd_power = locomolcd_power;
> +
> + backlight_device_register("collie-bl", NULL, &locomobl_data);
> #endif
> return 0;
> }
Could this be changed to:
#ifdef CONFIG_SA1100_COLLIE
sa1100fb_lcd_power = locomolcd_power;
#endif
backlight_device_register("locomo-bl", NULL, &locomobl_data);
return 0;
This means that it will also present a backlight interface on poodle. In
fact I've already helped a poodle user test this and it works!
Also note that there are some backlight interface changes sitting in -mm
(see the linux-fbdev-devel mailing list) which this patch isn't covered
by. If this patch gets merged first, I'll make sure it gets adapted to
the new interface though (which actually brings some benefits like power
attribute implementation for free).
Cheers,
Richard
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.