Re: [PATCH] i2c-ali1535: enable SPARC support
Hi David, On Tue, 27 Dec 2011 14:17:59 -0500 (EST), David Miller wrote: From: corentin.labbe corentin.la...@geomatys.fr Date: Thu, 24 Nov 2011 12:01:36 +0100 The i2c-ali1535 driver don't work on SPARC, this is because it assumes that ioport address are 16bits wide (address stored with an unsigned short). But on SPARC arch, ioports are mapped in memory and so are stored with an unsigned long. This patch corrects this by using pci_resource_start for getting IOMEM base address, then reading the SMBBA of the i2c busse and using together for I/O access. I like to thanks Jean DELVARE for reviewing of my patch. Thanks Signed-off-by: LABBE Corentin corentin.la...@geomatys.fr Jean has asked for some more changes, please follow his suggestions and resubmit, thanks. Actually I ended up doing the changes myself, and the patch is queued for 3.3 already: http://khali.linux-fr.org/devel/linux-3/jdelvare-i2c/i2c-ali1535-enable-sparc-support.patch Please let me know quickly if you see anything wrong there. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-ali1535: enable SPARC support
From: Jean Delvare kh...@linux-fr.org Date: Thu, 5 Jan 2012 20:51:05 +0100 Hi David, On Tue, 27 Dec 2011 14:17:59 -0500 (EST), David Miller wrote: From: corentin.labbe corentin.la...@geomatys.fr Date: Thu, 24 Nov 2011 12:01:36 +0100 The i2c-ali1535 driver don't work on SPARC, this is because it assumes that ioport address are 16bits wide (address stored with an unsigned short). But on SPARC arch, ioports are mapped in memory and so are stored with an unsigned long. This patch corrects this by using pci_resource_start for getting IOMEM base address, then reading the SMBBA of the i2c busse and using together for I/O access. I like to thanks Jean DELVARE for reviewing of my patch. Thanks Signed-off-by: LABBE Corentin corentin.la...@geomatys.fr Jean has asked for some more changes, please follow his suggestions and resubmit, thanks. Actually I ended up doing the changes myself, and the patch is queued for 3.3 already: http://khali.linux-fr.org/devel/linux-3/jdelvare-i2c/i2c-ali1535-enable-sparc-support.patch Please let me know quickly if you see anything wrong there. Using the raw PCI config register value in the non-IO case is always wrong and non-portable. You need to ioremap the thing using the PCI resource if it's not IO and therefore MEM. More easier, if non-IO is really not expected, would be to fail the probe if we don't find IORESOURCE_IO set. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-ali1535: enable SPARC support
On Thu, 05 Jan 2012 14:55:10 -0500 (EST), David Miller wrote: From: Jean Delvare kh...@linux-fr.org Date: Thu, 5 Jan 2012 20:51:05 +0100 Actually I ended up doing the changes myself, and the patch is queued for 3.3 already: http://khali.linux-fr.org/devel/linux-3/jdelvare-i2c/i2c-ali1535-enable-sparc-support.patch Please let me know quickly if you see anything wrong there. Using the raw PCI config register value in the non-IO case is always wrong and non-portable. You need to ioremap the thing using the PCI resource if it's not IO and therefore MEM. More easier, if non-IO is really not expected, would be to fail the probe if we don't find IORESOURCE_IO set. It's indeed not expected, and failing is what Corentin's original patch was doing. I had him change (actually did the change myself with his approval) to limit the risk of regression. I don't expect MEM but maybe no resource type at all (i.e. BAR 0 unused.) The rationale is that old PC boards use the same PCI chipset and we were not able to find any tester. I have no idea what the PCI resources look like on these machines, but I know the driver used to work OK, so the strategy is to make the new code behave the same as the original code if things don't look as expected. We can revisit if/when we find a tester with ALI1535 on x86. -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] i2c: Convert to DEFINE_PCI_DEVICE_TABLE
On Wed, 28 Dec 2011 20:48:32 +0800, Axel Lin wrote:
Convert static struct pci_device_id *[] to static DEFINE_PCI_DEVICE_TABLE
tables.
Use DEFINE_PCI_DEVICE_TABLE ensures we make the pci_device_id table const
and marked as __devinitconst.
This also fixes some warnings from checkpatch:
e.g.
WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id
#1096: FILE: i2c/busses/i2c-intel-mid.c:1096:
+static struct pci_device_id intel_mid_i2c_ids[] = {
Signed-off-by: Axel Lin axel@gmail.com
Cc: Rudolf Marek r.ma...@assembler.cz
Cc: Jean Delvare kh...@linux-fr.org
Cc: Ben Dooks ben-li...@fluff.org
Cc: Olof Johansson o...@lixom.net
Cc: Mark M. Hoffman mhoff...@lightlink.com
Cc: Dirk Brandewie dirk.brande...@gmail.com
Cc: Tomoya MORINAGA tomoya-li...@dsn.lapis-semi.com
Cc: Wolfram Sang w.s...@pengutronix.de
Cc: Feng Tang feng.t...@intel.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
Cc: linux-i2c@vger.kernel.org
---
This resend updates the change log.
This patch is against linux-next tree.
Axel
drivers/i2c/busses/i2c-ali1563.c |2 +-
drivers/i2c/busses/i2c-ali15x3.c |2 +-
drivers/i2c/busses/i2c-amd756.c|2 +-
drivers/i2c/busses/i2c-amd8111.c |2 +-
drivers/i2c/busses/i2c-designware-pcidrv.c |2 +-
drivers/i2c/busses/i2c-eg20t.c |2 +-
drivers/i2c/busses/i2c-hydra.c |2 +-
drivers/i2c/busses/i2c-i801.c |2 +-
drivers/i2c/busses/i2c-intel-mid.c |2 +-
drivers/i2c/busses/i2c-nforce2.c |2 +-
drivers/i2c/busses/i2c-pasemi.c|2 +-
drivers/i2c/busses/i2c-piix4.c |2 +-
drivers/i2c/busses/i2c-pxa-pci.c |2 +-
drivers/i2c/busses/i2c-sis5595.c |2 +-
drivers/i2c/busses/i2c-sis630.c|2 +-
drivers/i2c/busses/i2c-sis96x.c|2 +-
drivers/i2c/busses/i2c-via.c |2 +-
drivers/i2c/busses/i2c-viapro.c|2 +-
drivers/i2c/busses/scx200_acb.c|2 +-
19 files changed, 19 insertions(+), 19 deletions(-)
(...)
Applied, thanks!
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-ali1535: enable SPARC support
From: Jean Delvare kh...@linux-fr.org Date: Thu, 5 Jan 2012 21:06:00 +0100 On Thu, 05 Jan 2012 14:55:10 -0500 (EST), David Miller wrote: Using the raw PCI config register value in the non-IO case is always wrong and non-portable. You need to ioremap the thing using the PCI resource if it's not IO and therefore MEM. More easier, if non-IO is really not expected, would be to fail the probe if we don't find IORESOURCE_IO set. It's indeed not expected, and failing is what Corentin's original patch was doing. I had him change (actually did the change myself with his approval) to limit the risk of regression. I don't expect MEM but maybe no resource type at all (i.e. BAR 0 unused.) The rationale is that old PC boards use the same PCI chipset and we were not able to find any tester. I have no idea what the PCI resources look like on these machines, but I know the driver used to work OK, so the strategy is to make the new code behave the same as the original code if things don't look as expected. We can revisit if/when we find a tester with ALI1535 on x86. Ok. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP/I2C - Fix timeout problem during suspend.
NeilBrown ne...@suse.de writes: On Wed, 04 Jan 2012 14:19:48 -0800 Kevin Hilman khil...@ti.com wrote: +Felipe NeilBrown ne...@suse.de writes: On a board with OMAP3 processor and TWL4030 Power management, we need to talk to the TWL4030 during late suspend but cannot because the I2C interrupt is disabled (as late suspend disables interrupt). I'm not convinced this is the right solution to this problem. IMO, this problem is caused by the MUSB driver being broken for suspend/resume. I've reported this problem (and an RFC/PATCH) already[1], but I don't think the driver has been fixed. Can you try my patch[1] to see if it fixes your problem as well? Kevin [1] http://marc.info/?l=linux-omapm=132252827112721w=2 Yes... and no. I reverted my patch to confirm that the timeout messages come back which they did. I then applied your patch and the suspend was nice and smooth again with no timeouts. So that is good. However immediately after I wake it up I get: [ 109.193054] Powerdomain (core_pwrdm) didn't enter target state 1 [ 109.199310] Could not enter target state in pm_suspend whereas with my patch in place I get: [ 123.666046] Successfully put all powerdomains to target state Following this hint I looked into current draw. With my patch I get a suspend-time current draw of 60-80mA (which is still too high..). With your patch in place I get 120mA or more (about 4 tests, definitely at least 30mA difference). I measure this by checking the 'charge_now' reported by the bq27000 in the battery. This is without the usb cable plugged in. Strange... without the usb cable plugged in, runtime PM should kick in and suspend the device long before system suspend happens so that there shouldn't be anything for the MUSB driver to do during system suspend. With usb plugged in your version has the positive effect that charging continues while in suspend while with mine it doesn't. But I don't think that justifies the extra current drain :-) The reason I implemented it that way was because I understood that with a cable plugged in, you cant reliabaly suspend (or resume) MUSB due to HW bugs/limitations. Hopefully Felipe can chime in here to clarify. So I'll be sticking with my patch for now. My next problem I need to resolve relates to i2c and the charger as well. When entering suspend the various twl4030 interrupts are disabled by not masked. This means they can still fire but are not handled until after suspend. This effectively blocks other interrupts from the twl4030 that I actually want (like the RTC alarm). I think there are at least 3 or 4 bugs in here making it rather hard to sort out. However I think I will want to mask interrupt sources when they are disabled. To mask the interrupts I need to talk to the twl4030 over i2c. And this means that I need the i2c interrupt to still be working. So I feel that my patch might be more generally useful. However I confess that there is a lot here that I don't completely understand, and I might have a different opinion tomorrow. I think your patch is probably useful also, but would like to see the MUSB driver issues better clarified and fixed as well. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] I2C: OMAP: misc. updates for v3.3
Hi Ben, Here's a few OMAP I2C updates for the v3.3 merge window. Thanks, Kevin The following changes since commit 3f6b2a8bd6e4ff43269d89066a9fe06a0e5ba961: I2C: OMAP: correct SYSC register offset for OMAP4 (2011-12-13 11:35:56 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.3/i2c/misc Benoit Cousson (1): i2c: OMAP: Add DT support for i2c controller Jan Weitzel (1): I2C: OMAP: NACK without STP Documentation/devicetree/bindings/i2c/omap-i2c.txt | 30 ++ drivers/i2c/busses/i2c-omap.c | 108 +--- 2 files changed, 99 insertions(+), 39 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
