Re: AM335x BeagleBone SPI Issues
On Mon, Dec 10, 2012 at 8:49 PM, Jack Mitchell m...@communistcode.co.uk wrote:
On 10/12/12 14:59, Felipe Balbi wrote:
Hi,
On Mon, Dec 10, 2012 at 02:50:16PM +, Jack Mitchell wrote:
On Mon, Dec 10, 2012 at 01:23:09PM +, Jack Mitchell wrote:
Hi,
I am currently having issues with the SPI driver on the beaglebone
using the 3.7-rc8 kernel[1]. I have probed the SPI pins and I have
found that writing works however reading doesn't. When using DMA the
program seems to lock hard and no data is sent on the bus. I am
testing the bus using spidev and the spidev_test[2] application,
however I first came across spi issues with a custom spi driver which
stopped working when I transitioned from 3.2-psp to 3.7-rc8.
The current output I am seeing from the spidev_test program is just a
series of 0x00 data, which looks to me like no data is getting in at
all. The spidev_test program is not using DMA as the buffer size is
too low, so I forced the dma on when buffer size is 1 and the
program hangs hard with the system still responding to other
commands.I have briged the pins 18 and 21 on the BeagleBone P9
header.
Has anyone seen issues like this, or if not if someone could please
test the latest 3.7-rc8 from [1] and let me know if it works for them
and the issue is at my end.
To get spidev working with devicetree I applied the patch from [3]
and changed the dtb as in the patch pasted below.
[1] https://github.com/beagleboard/kernel/tree/3.7
[2] http://lxr.linux.no/#linux+v3.6.9/Documentation/spi/spidev_test.c
[3]
http://www.mail-archive.com/spi-devel-general@lists.sourceforge.net/msg09958.html
do you have any debugging output from that driver ? It would be cool to
see if DMA is at least being kicked properly for small transfers.
When I run the spidev program with dma for transfers 1, the program
hangs and the only output in dmesg is:
[ 12.613952] libphy: 4a101000.mdio:00 - Link is Up - 100/Full
Last line from initial log in [2]
[ 47.669202] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
[ 47.669246] spidev spi1.0: setup mode 0, 8 bits/w, 2400 Hz max --
0
[ 47.669260] spidev spi1.0: spi mode 00
[ 47.669283] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
[ 47.669300] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max
-- 0
[ 47.669312] spidev spi1.0: 16 bits per word
[ 47.669330] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
[ 47.669347] spidev spi1.0: setup mode 0, 16 bits/w, 2400 Hz max
-- 0
[ 47.669358] spidev spi1.0: 2400 Hz (max)
[ 47.673811] spidev spi1.0: setup: speed 2400, sample leading
edge, clk normal
The initial dmesg statup log is at [2].
can you apply the debugging patch below to spi driver and show me the
output again ?
Note that I'm allowing DMA for as small as 1-byte transfers (as you
needed) and I'm also disabling DMA Request line before calling
complete() as I think the current way could race, but likely wouldn't
cause issues. Anyway, please show me the output.
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 3542fdc..d2b1af2 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -108,7 +108,7 @@ struct omap2_mcspi_dma {
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
* cache operations; better heuristics consider wordsize and bitrate.
*/
-#define DMA_MIN_BYTES 160
+#define DMA_MIN_BYTES 1
/*
@@ -298,10 +298,11 @@ static void omap2_mcspi_rx_callback(void *data)
struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master);
struct omap2_mcspi_dma *mcspi_dma =
mcspi-dma_channels[spi-chip_select];
- complete(mcspi_dma-dma_rx_completion);
-
/* We must disable the DMA RX request */
+ dev_info(spi-dev, Disabling RX Request Line\n);
omap2_mcspi_set_dma_req(spi, 1, 0);
+
+ complete(mcspi_dma-dma_rx_completion);
}
static void omap2_mcspi_tx_callback(void *data)
@@ -310,10 +311,11 @@ static void omap2_mcspi_tx_callback(void *data)
struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master);
struct omap2_mcspi_dma *mcspi_dma =
mcspi-dma_channels[spi-chip_select];
- complete(mcspi_dma-dma_tx_completion);
-
/* We must disable the DMA TX request */
+ dev_info(spi-dev, Disabling TX Request Line\n);
omap2_mcspi_set_dma_req(spi, 0, 0);
+
+ complete(mcspi_dma-dma_tx_completion);
}
static void omap2_mcspi_tx_dma(struct spi_device *spi,
@@ -328,6 +330,7 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
void __iomem*chstat_reg;
struct omap2_mcspi_cs *cs = spi-controller_state;
+ dev_info(spi-dev, kicking TX DMA\n);
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma =
Re: [PATCH] i2c: omap: Remove the OMAP_I2C_FLAG_RESET_REGS_POSTIDLE flag
On Mon, Nov 26, 2012 at 2:44 PM, Felipe Balbi ba...@ti.com wrote: - OMAP_I2C_FLAG_BUS_SHIFT_2, + .flags = OMAP_I2C_FLAG_BUS_SHIFT_2, if it's not used anymore, how about removing its definition too ? Just updated the patch , thanks. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] i2c: omap: Remove the OMAP_I2C_IP_VERSION_*
On Mon, Nov 26, 2012 at 5:22 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Nov 26, 2012 at 05:09:42PM +0530, Shubhrajyoti D wrote: The OMAP_I2C_IP_VERSION_1 and OMAP_I2C_IP_VERSION_2 was needed as on VER2 we were not reading all the 32-bits. Since now that we read the hi register we do not need the OMAP_I2C_IP_VERSION_*. Delete the same. The custom reset is also changed to detect VER2 based on the scheme. looks like this should become a series IMO. First patch would move the macros to common header, second patch would switch the Reset part to use those macros and third patch gets rid of OMAP_I2C_IP_VERSION_* other than that, looks very good to me. OK will respin it accordingly. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Input: omap4-keypad: Remove the OMAP4_KBD_SYSCONFIG and OMAP4_KBD_SYSSTATUS
On Mon, Nov 26, 2012 at 11:31 PM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Mon, Nov 26, 2012 at 04:21:19PM +0530, Shubhrajyoti D wrote: The macros OMAP4_KBD_SYSSTATUS and OMAP4_KBD_SYSSTATUS are not used so remove them. They document the existing registers and do not add bloat to the generated objects so let's leave them be. The objective of the patch is not to prevent bloat. Actually these registers have power/system impact so it was decided that the drivers will not configure the sysc registers (infact not define). Currently hwmod configures the registers. To be safe I thought of deleting it. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] i2c: omap: Move the remove constraint
On Fri, Nov 16, 2012 at 7:50 PM, Wolfram Sang w.s...@pengutronix.de wrote: On Thu, Nov 15, 2012 at 02:19:21PM +0530, Shubhrajyoti D wrote: Currently we just queue the transfer and release the qos constraints, however we do not wait for the transfer to complete to release the constraint. Move the remove constraint after the bus busy as we are sure that the transfers are completed by then. Acked-by: Jean Pihet j-pi...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Applied to for-next. Please let me know if it should go to for-current. I feel for-next should be fine. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] i2c: omap: Move the remove constraint
On Thu, Nov 15, 2012 at 1:46 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Hi Shubhrajyoti, On Thu, Nov 15, 2012 at 8:34 AM, Shubhrajyoti D shubhrajy...@ti.com wrote: Currently we just queue the transfer and release the qos constraints, however we donot wait for the transfer Typo: donot Just fixed and resent. to complete to release the constraint. Move the remove constraint after the bus busy as we are sure that the transfers are completed by then. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Looks good! Acked-by: Jean Pihet j-pi...@ti.com Thanks for review. Regards, Jean -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: omap: don't save a value only needed for read-clearing
On Thu, Nov 15, 2012 at 12:20 AM, Wolfram Sang w.s...@pengutronix.de wrote: This makes one of my code analyzers happy and makes me a part of the anything open source which we could all be using ? :-) 'my' as in 'one of those I am using'. It was cppcheck which found that flaw. Its use for kernel code is limited, but it does find one or the other thing. sparse did not complain though. So it seems it helps to run multiple static tools:-) -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 0/7] i2c: omap: updates
On Mon, Nov 5, 2012 at 5:53 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: Does the followiing - Make the revision a 32- bit consisting of rev_lo amd rev_hi each of 16 bits. - Also use the revision register for the erratum i207. - Refactor the i2c_omap_init code. Adds a patch to remove the hardcoding sysc register. Instead read register ,reset and then writeback the read value. Also more cleanup is possible will check on that subsequently. Previous discussions can be found http://www.spinics.net/lists/linux-omap/msg81265.html Tested on OMAP4430sdp ,4460 ,omap3630 ,3430 and omap2430. For omap2 testing the below patch was used [PATCH] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set If there are no further comments can this be considered for next. Thanks and Regards, -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi: omap2-mcspi: Reorder the wait_for_completion for tx
On Tue, Nov 6, 2012 at 2:33 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 06, 2012 at 02:30:19PM +0530, Shubhrajyoti D wrote: The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] changed the wait_for_completion order. Move the wait so that the rx doesnot wait for the tx to complete. Applied, thanks. Thanks Mark, -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Tue, Nov 6, 2012 at 5:31 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: [...] I ran some intensive stress tests on the I2C and ... unfortunately I could not trigger the problem. It looks like the issue is caused by some transient situation where the CORE and/or I2C is in a low power state. FYI... I just ran across what appears to be the same bug on 3430/n900 during suspend/resume testing. With CPUidle enabled, this happens every time. Reverting the I2C QoS patch makes it work again. I think we should defer the release of the constraints Does this help http://www.mail-archive.com/linux-omap@vger.kernel.org/msg79841.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spi: omap2-mcspi: Reorder the wait_for_completion for tx
On Tue, Nov 6, 2012 at 2:52 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 06, 2012 at 02:47:27PM +0530, Shubhrajyoti D wrote: The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] changed the wait_for_completion order. Move the wait so that the rx doesnot wait for the tx to complete. Is this a resend of the patch I just applied, or is it something different? No please ignore this one. Something wrong at my end it got sent twice. Please ignore. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
On Tue, Nov 6, 2012 at 10:01 PM, Paul Walmsley p...@pwsan.com wrote: This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc. This commit causes I2C timeouts to appear on several OMAP3430/3530-based boards: http://marc.info/?l=linux-arm-kernelm=135071372426971w=2 http://marc.info/?l=linux-arm-kernelm=135067558415214w=2 http://marc.info/?l=linux-arm-kernelm=135216013608196w=2 and appears to have been sent for merging before one of its prerequisites was merged: http://marc.info/?l=linux-arm-kernelm=135219411617621w=2 Not a comment however was curious does merging the dependency. make the issue go away? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/7] i2c: omap: Fix the revision register read
On Mon, Nov 5, 2012 at 2:34 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Nov 05, 2012 at 02:04:56PM +0530, Shubhrajyoti wrote: @@ -1155,7 +1187,7 @@ omap_i2c_probe(struct platform_device *pdev) dev-fifo_size = (dev-fifo_size / 2); - if (dev-rev OMAP_I2C_REV_ON_3630_4430) + if (dev-rev OMAP_I2C_REV_ON_3630) dev-b_hw = 1; /* Enable hardware fixes */ looks like this was applicable to 4430 too, what happened ? No actually this can be deleted completely once the start - transaction - stop sequence recommendation is followed. yes, but we're not there just yet and this patch is changing the behavior No , earlier we were truncating the register for omap4 so OMAP_I2C_REV_ON_3630_4430 was there if we read both hi and lo for omap4 then we donot find 3630 and 4430 value to be similar. In this case the behavior is same as earlier also it enabled this for lower than 3630 and the same holds good even now. So in essence, Earlier OMAP_I2C_REV_ON_3630_4430 is named to OMAP_I2C_REV_ON_3630 and omap4 rev will have a 32bit value which is greater. of the driver in ways which don't belong to $SUBJECT. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 8/8] i2c: omap: cleanup the sysc write
On 11/5/12, Cousson, Benoit b-cous...@ti.com wrote: On 11/5/2012 3:25 PM, Felipe Balbi wrote: Hi, On Mon, Nov 05, 2012 at 07:53:45PM +0530, Shubhrajyoti wrote: On Monday 05 November 2012 07:44 PM, Felipe Balbi wrote: - dev-syscstate); -} not sure if this will work. What about the first time you call reset() ? won't SYSC just contain the reset values ? No actually the hwmod sets the value. ahaaa, ok good. Let's get an Ack from Benoit, then. Well, in fact, I'm a little bit surprised that we still have to hack the there was an attempt [1] the pdata stuff may have issues with dt having to deal with more pdata [2] SYSC directly without using an omap_device API. Paul was not happy with omap device api [3] As far as the patch is concerned it is only getting rid of the hard coded flags and the rev check. I know that we have to do some weird stuff for reseting that IP, but didn't we already exposed something to allow that? Regards, Benoit [1] http://www.spinics.net/lists/linux-i2c/msg06810.html [2] http://www.spinics.net/lists/linux-i2c/msg06937.html [3] http://www.spinics.net/lists/linux-i2c/msg06943.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207
On Fri, Nov 2, 2012 at 4:37 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Nov 02, 2012 at 04:09:45PM +0530, Shubhrajyoti D wrote:
The errata i207 is enabled for 2430 and 3xxx. Use the revision check
to enable the erratum instead.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
very good. I haven't read the errata but from a code standpoint, it
looks good:
Reviewed-by: Felipe Balbi ba...@ti.com
Also I post to this the flag may be deleted.
From: Shubhrajyoti D shubhrajy...@ti.com
Date: Fri, 2 Nov 2012 16:34:08 +0530
Subject: [PATCH] ARM: i2c: omap: Remove the i207 errata flag
The commit [i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207]
uses the revision id instead of the flag. So the flag can be safely removed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |3 +--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |9 +++--
drivers/i2c/busses/i2c-omap.c |3 +--
include/linux/i2c-omap.h |1 -
4 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c455e41..b79ccf6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -76,8 +76,7 @@ static struct omap_hwmod_class i2c_class = {
static struct omap_i2c_dev_attr i2c_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_BUS_SHIFT_2 |
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2 |
OMAP_I2C_FLAG_FORCE_19200_INT_CLK,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f67b7ee..943222c4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -791,8 +791,7 @@ static struct omap_hwmod omap3xxx_dss_venc_hwmod = {
/* I2C1 */
static struct omap_i2c_dev_attr i2c1_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
@@ -818,8 +817,7 @@ static struct omap_hwmod omap3xxx_i2c1_hwmod = {
/* I2C2 */
static struct omap_i2c_dev_attr i2c2_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
-OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
@@ -845,8 +843,7 @@ static struct omap_hwmod omap3xxx_i2c2_hwmod = {
/* I2C3 */
static struct omap_i2c_dev_attr i2c3_dev_attr = {
.fifo_depth = 64, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
-OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dd97c14..87970fa 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1029,8 +1029,7 @@ static const struct i2c_algorithm omap_i2c_algo = {
#ifdef CONFIG_OF
static struct omap_i2c_bus_platform_data omap3_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
-OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index df804ba..5c88187 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@ -21,7 +21,6 @@
#define OMAP_I2C_FLAG_SIMPLE_CLOCK BIT(1)
#define OMAP_I2C_FLAG_16BIT_DATA_REG BIT(2)
#define OMAP_I2C_FLAG_RESET_REGS_POSTIDLE BIT(3)
-#define OMAP_I2C_FLAG_APPLY_ERRATA_I207BIT(4)
#define OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLKBIT(5)
#define OMAP_I2C_FLAG_FORCE_19200_INT_CLK BIT(6)
/* how the CPU address bus must be translated for I2C unit access */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c: omap: Fix the revision register read
On Fri, Nov 2, 2012 at 4:36 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Nov 02, 2012 at 04:09:44PM +0530, Shubhrajyoti D wrote:
The revision register on OMAP4 is a 16-bit lo and a 16-bit
hi. Currently the driver reads only the lower 8-bits.
Fix the same by preventing the truncating of the rev register
for OMAP4.
Also use the scheme bit ie bit-14 of the hi register to know if it
is OMAP_I2C_IP_VERSION_2.
On platforms previous to OMAP4 the offset 0x04 is IE register whose
bit-14 reset value is 0, the code uses the same to its advantage.
Also since the omap_i2c_read_reg uses reg_map_ip_* a raw_readw is done
to fetch the revision register.
The dev-regs is populated after reading the rev_hi. A NULL check
has been added in the resume handler to prevent the access before
the setting of the regs.
tested on which platforms ?
omap4430 , 4460 and omap3.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 59
-
1 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..d8e7709 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -49,9 +49,10 @@
#define OMAP_I2C_OMAP1_REV_2 0x20
/* I2C controller revisions present on specific hardware */
-#define OMAP_I2C_REV_ON_2430 0x36
-#define OMAP_I2C_REV_ON_3430_35300x3C
-#define OMAP_I2C_REV_ON_3630_44300x40
+#define OMAP_I2C_REV_ON_2430 0x0036
are you sure this are the contents on 2430 ? Have you actually ran this
code on that platform ?
I did not run on 2430. Will try to get a platform and run.
However the current code already has and uses the same value so
I feel it should be fine.:-)
+#define OMAP_I2C_REV_ON_3430_35300x003C
+#define OMAP_I2C_REV_ON_3630 0x0040
likewise for these two.
I verified that the 3630 returns 0x40 on my beaglexM.
+#define OMAP_I2C_REV_ON_4430_PLUS0x5042
what about 4460, 4470, 3530, etc etc etc ?
@@ -490,7 +491,7 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev
*dev, u8 size, bool is_rx)
omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
- if (dev-rev OMAP_I2C_REV_ON_3630_4430)
+ if (dev-rev OMAP_I2C_REV_ON_3630)
dev-b_hw = 1; /* Enable hardware fixes */
/* calculate wakeup latency constraint for MPU */
@@ -1052,6 +1053,14 @@ static const struct of_device_id omap_i2c_of_match[]
= {
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
#endif
+#define OMAP_I2C_SCHEME(rev) (rev 0xc000) 14
you miss () there to make sure no other operations will take higher
precedence when using this macro.
Indeed. Thanks.
@@ -1130,7 +1136,31 @@ omap_i2c_probe(struct platform_device *pdev)
if (IS_ERR_VALUE(r))
goto err_free_mem;
- dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
+ /*
+ * Read the Rev hi bit-[15:14] ie scheme this is 1 indicates ver2.
+ * On omap3 Offset 4 is IE Reg the bit [15:14] is XDR_IE which is 0
+ * at reset. Also since the omap_i2c_read_reg uses reg_map_ip_* a
+ * raw_readw is done.
+ */
+ rev = __raw_readw(dev-base + 0x04);
+
+ switch (OMAP_I2C_SCHEME(rev)) {
+ case 0:
define macros for these two cases.
OK
+ dev-regs = (u8 *)reg_map_ip_v1;
+ dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
+ minor = OMAP_I2C_REV_SCHEME_0_MAJOR(dev-rev);
+ major = OMAP_I2C_REV_SCHEME_0_MAJOR(dev-rev);
+ break;
wrong indentation.
Yes will fix.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] i2c: omap: Fix the revision register read
On Wed, Oct 31, 2012 at 2:29 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: The revision register on OMAP4 is a 16-bit lo and a 16-bit hi. Currently the driver reads only the lower 8-bits. Fix the same by preventing the truncating of the rev register for OMAP4. Also use the scheme bit ie bit-14 of the hi register to know if it is OMAP_I2C_IP_VERSION_2. On platforms previous to OMAP4 the offset 0x04 is IE register whose bit-14 reset value is 0, the code uses the same to its advantage. The dev-regs is populated after reading the rev_hi. A NULL check has been added in the resume handler to prevent the access before the setting of the regs. tested on omap4sdp, omap3630 based beagle , omap3430sdp. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] i2c: omap: re-factor omap_i2c_init function
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Oct 25, 2012 at 12:06:51PM +0530, Shubhrajyoti D wrote:
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
v2 - add the iestate 0 check back.
- Remove a stray change.
- Applies on top of Felipe's patches.
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3636 beagle both idle and suspend.
Functional testing on omap4sdp.
drivers/i2c/busses/i2c-omap.c | 71
++--
1 files changed, 32 insertions(+), 39 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5e5cefb..3d400b1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -209,7 +209,6 @@ struct omap_i2c_dev {
u16 pscstate;
u16 scllstate;
u16 sclhstate;
- u16 bufstate;
u16 syscstate;
u16 westate;
u16 errata;
@@ -285,9 +284,31 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
}
}
+static void __omap_i2c_init(struct omap_i2c_dev *dev)
+{
+
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+
+ /* SCL low and high time values */
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ /* Take the I2C module out of reset: */
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
a few blank lines in this function wouldn't hurt and they would help
with readability.
Will add .
+ /*
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (dev-iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+}
+
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -337,11 +358,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
dev-westate = OMAP_I2C_WE_ALL;
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- dev-westate);
remove the comment too since now that's done by some other function ?
}
}
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -426,28 +444,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
sclh = fclk_rate / (dev-speed * 2) - 7 + psc;
}
- /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
-
- /* SCL low and high time values */
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
-
- /* Take the I2C module out of reset: */
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
-
/* Enable interrupts */
dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) |
((dev-fifo_size) ? (OMAP_I2C_IE_RDR |
OMAP_I2C_IE_XDR) : 0);
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
- if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- dev-pscstate = psc;
- dev-scllstate = scll;
- dev-sclhstate = sclh;
- dev-bufstate = buf;
- }
+
+ dev-pscstate = psc;
+ dev-scllstate = scll;
+ dev-sclhstate = sclh;
+
+ __omap_i2c_init(dev);
+
return 0;
}
@@ -1268,23 +1276,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
- if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
- omap_i2c_write_reg(_dev,
Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered
On Thu, Oct 25, 2012 at 2:30 PM, Felipe Balbi ba...@ti.com wrote:
if we allow compiler reorder our writes, we could
fall into a situation where dev-buf_len is reset
for no apparent reason.
This bug was found with a simple script which would
transfer data to an i2c client from 1 to 1024 bytes
(a simple for loop), when we got to transfer sizes
bigger than the fifo size, dev-buf_len was reset
to zero before we had an oportunity to handle XDR
Interrupt. Because dev-buf_len was zero, we entered
omap_i2c_transmit_data() to transfer zero bytes,
which would mean we would just silently exit
omap_i2c_transmit_data() without actually writing
anything to DATA register. That would cause XDR
IRQ to trigger forever and we would never transfer
the remaining bytes.
After adding the memory barrier, we also drop resetting
dev-buf_len to zero in omap_i2c_xfer_msg() because
both omap_i2c_transmit_data() and omap_i2c_receive_data()
will act until dev-buf_len reaches zero, rendering the
other write in omap_i2c_xfer_msg() redundant.
This patch has been tested with pandaboard for a few
iterations of the script mentioned above.
looks good to me
Acked-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
This bug has been there forever, but it's quite annoying.
I think it deserves being pushed upstream during this -rc
cycle, but if Wolfram decides to wait until v3.8, I don't
mind.
drivers/i2c/busses/i2c-omap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..1ec4e6e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -521,6 +521,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
/* REVISIT: Could the STB bit of I2C_CON be used with probing? */
dev-buf = msg-buf;
dev-buf_len = msg-len;
+ wmb();
omap_i2c_write_reg(dev, OMAP_I2C_CNT_REG, dev-buf_len);
@@ -579,7 +580,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
*/
timeout = wait_for_completion_timeout(dev-cmd_complete,
OMAP_I2C_TIMEOUT);
- dev-buf_len = 0;
if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
omap_i2c_init(dev);
--
1.8.0
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] i2c: omap: re-factor omap_i2c_init function
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi ba...@ti.com wrote:
[...]
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (dev-iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+}
+
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -337,11 +358,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
dev-westate = OMAP_I2C_WE_ALL;
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- dev-westate);
remove the comment too since now that's done by some other function ?
The comment is applicable to the OMAP_I2C_WE_ALL value.
So I thought it could be kept.
dont feel strongly though.
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] i2c: omap: reorder exit path of omap_i2c_xfer_msg()
On Mon, Oct 22, 2012 at 3:16 PM, Felipe Balbi ba...@ti.com wrote:
just a cleanup patch trying to make exit path
more straightforward. No changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index c07d9c4..bea0277 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -505,6 +505,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
{
struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
unsigned long timeout;
+ int ret;
u16 w;
dev_dbg(dev-dev, addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n,
@@ -582,31 +583,38 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
dev-buf_len = 0;
if (timeout == 0) {
dev_err(dev-dev, controller timed out\n);
- omap_i2c_init(dev);
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto err_i2c_init;
}
- if (likely(!dev-cmd_err))
- return 0;
-
/* We have an error */
if (dev-cmd_err (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
OMAP_I2C_STAT_XUDF)) {
- omap_i2c_init(dev);
- return -EIO;
+ ret = -EIO;
+ goto err_i2c_init;
}
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
if (msg-flags I2C_M_IGNORE_NAK)
return 0;
+
if (stop) {
w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
w |= OMAP_I2C_CON_STP;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
}
- return -EREMOTEIO;
+
+ ret = -EREMOTEIO;
+ goto err;
This adds reset to nack may be that can be removed.
}
- return -EIO;
+
+ return 0;
+
+err_i2c_init:
+ omap_i2c_init(dev);
+
+err:
+ return ret;
}
--
1.8.0.rc0
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: omap: re-factor omap_i2c_init function
On Tue, Oct 23, 2012 at 11:27 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Oct 23, 2012 at 11:26:15PM +0530, Shubhrajyoti Datta wrote:
@@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device
*dev)
{
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
- if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG,
_dev-scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG,
_dev-sclhstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG,
_dev-syscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
- * Don't write to this register if the IE state is 0 as it can
- * cause deadlock.
- */
- if (_dev-iestate)
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
this part is not on __omap_i2c_init() so you're potentially causing a
regression here.
iestate is set at init so cannot be zero. so the check was removed.
Hmm thinking a little more, there is a case that I missed the resume
handler may get called before
the omap_i2c_init will restore the check and send another version.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
On Tue, Oct 23, 2012 at 3:16 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Tero Kristo t-kri...@ti.com writes: When waking up from off-mode, some IP blocks are reset automatically by hardware. For this reason, software must wait until the reset has completed before attempting to access the IP block. This patch fixes for example the bug introduced by commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c (mmc: omap_hsmmc: remove access to SYSCONFIG register), in which the MMC IP block is reset during off-mode entry, but the code expects the module to be already available during the execution of context restore. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Venkatraman S svenk...@ti.com I can confirm that this patch the regression in my OMAP3 PM tests where suspend test (to retention or off) failed if ran after the off-idle test. Tested-by: Kevin Hilman khil...@ti.com on 3530/Overo, 3730/OveroSTORM, 3730/Beagle-xM on 3630/Beagle works. However on 3430 on idle path didnot work. let me know if i am missing some thing. Thanks Tero for the fix, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
On Tue, Oct 23, 2012 at 9:39 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Shubhrajyoti Datta omaplinuxker...@gmail.com writes: [...] Could you please explain what worked and didn't work on each platforms? Also, which 3430 did you test on? If it's SDP, then it has a UART1 console, correct? idle mode set autosuspend for uart sleep off count didnt increment on 3430sdp. hope not hitting any setup at my end. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: omap: re-factor omap_i2c_init function
On Tue, Oct 23, 2012 at 10:48 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Oct 23, 2012 at 08:57:19PM +0530, Shubhrajyoti D wrote:
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
Applies on Felipe's series
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3636 beagle both idle and suspend.
Functional testing on omap4sdp.
drivers/i2c/busses/i2c-omap.c | 68
+
1 files changed, 28 insertions(+), 40 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5e5cefb..338cee7 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -209,7 +209,6 @@ struct omap_i2c_dev {
u16 pscstate;
u16 scllstate;
u16 sclhstate;
- u16 bufstate;
u16 syscstate;
u16 westate;
u16 errata;
@@ -285,9 +284,26 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
}
}
+static void __omap_i2c_init(struct omap_i2c_dev *dev)
+{
+
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+
+ /* SCL low and high time values */
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+ if (dev-rev = OMAP_I2C_REV_ON_3430_3530)
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ /* Take the I2C module out of reset: */
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+
+}
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -337,11 +353,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
dev-westate = OMAP_I2C_WE_ALL;
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- dev-westate);
}
}
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev-flags OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -426,28 +439,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
sclh = fclk_rate / (dev-speed * 2) - 7 + psc;
}
- /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
-
- /* SCL low and high time values */
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
-
- /* Take the I2C module out of reset: */
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
-
/* Enable interrupts */
dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) |
((dev-fifo_size) ? (OMAP_I2C_IE_RDR |
OMAP_I2C_IE_XDR) : 0);
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
- if (dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- dev-pscstate = psc;
- dev-scllstate = scll;
- dev-sclhstate = sclh;
- dev-bufstate = buf;
- }
+
+ dev-pscstate = psc;
+ dev-scllstate = scll;
+ dev-sclhstate = sclh;
+
+ __omap_i2c_init(dev);
+
return 0;
}
@@ -1136,7 +1139,7 @@ omap_i2c_probe(struct platform_device *pdev)
if (IS_ERR_VALUE(r))
goto err_free_mem;
- dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
+ dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff;
trailing change. not part of $SUBJECT
my mistake will remove.
dev-errata = 0;
@@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
- if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev-scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev-sclhstate);
-
Re: [PATCH] i2c: omap: re-factor omap_i2c_init function
On Tue, Oct 23, 2012 at 11:27 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Oct 23, 2012 at 11:26:15PM +0530, Shubhrajyoti Datta wrote:
@@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device
*dev)
{
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
- if (_dev-flags OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev-pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG,
_dev-scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG,
_dev-sclhstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev-bufstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG,
_dev-syscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev-westate);
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
- }
-
- /*
- * Don't write to this register if the IE state is 0 as it can
- * cause deadlock.
- */
- if (_dev-iestate)
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev-iestate);
this part is not on __omap_i2c_init() so you're potentially causing a
regression here.
iestate is set at init so cannot be zero. so the check was removed.
so you never read it back ? Then you need to add a note for that in
changelog, since this is a behavior change ;-)
Indeed will do.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM/dts: omap5: Update I2C with address space and interrupts
On Mon, Oct 22, 2012 at 3:52 PM, Sebastien Guiriec s-guir...@ti.com wrote:
Add base address and interrupt line inside Device Tree data for
OMAP5
Looks good to me.
Thanks ,
Reviewed-by: Shubhrajyoti D shubhrajy...@ti.com
Signed-off-by: Sebastien Guiriec s-guir...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 9e39f9f..6c22e1b 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -192,6 +192,8 @@
i2c1: i2c@4807 {
compatible = ti,omap4-i2c;
+ reg = 0x4807 0x100;
+ interrupts = 0 56 0x4;
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c1;
@@ -199,6 +201,8 @@
i2c2: i2c@48072000 {
compatible = ti,omap4-i2c;
+ reg = 0x48072000 0x100;
+ interrupts = 0 57 0x4;
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c2;
@@ -206,20 +210,26 @@
i2c3: i2c@4806 {
compatible = ti,omap4-i2c;
+ reg = 0x4806 0x100;
+ interrupts = 0 61 0x4;
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c3;
};
- i2c4: i2c@4807A000 {
+ i2c4: i2c@4807a000 {
compatible = ti,omap4-i2c;
+ reg = 0x4807a000 0x100;
+ interrupts = 0 62 0x4;
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c4;
};
- i2c5: i2c@4807C000 {
+ i2c5: i2c@4807c000 {
compatible = ti,omap4-i2c;
+ reg = 0x4807c000 0x100;
+ interrupts = 0 60 0x4;
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c5;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] I2C patches for v3.8 merge window
On Mon, Oct 22, 2012 at 7:00 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Mon, Oct 22, 2012 at 12:46:50PM +0300, Felipe Balbi wrote: Hi guys, here's another series for OMAP I2C driver. There are a few cleanups and one very nice new feature: we can now report how many bytes we transferred until NACK. Note that the implemementation for OMAP-I2C turned out to be a little more complex then I expected, mainly because of the way I2C_CNT register behaves and because of the very buggy register usage on that driver. I have boot tested all patches on beagle xM (3630) and pandaboard rev A3 (4430), will send boot-logs if anyone wants to see. tested the below branch on omap4430sdp , panda , omap3430sdp. Doing simple i2ctools . Tested-by : Shubhrajyoti D shubhrajy...@ti.com All patches are available at [1] if anyone wants an easy way to test the patches. [1] git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git i2c-transferred-bytes-on-NACK forgot to mention, with [1] I could veridy suspend to ram with boards mentioned above. [1] http://marc.info/?l=linux-arm-kernelm=135090724817604w=2 Felipe Balbi (7): i2c: omap: no need to access platform_device i2c: omap: reorder exit path of omap_i2c_xfer_msg() i2c: omap: fix error checking i2c: omap: also complete() when stat becomes zero i2c: omap: introduce and use OMAP_I2C_IP_VERSION_3 i2c: omap: wait for transfer completion before sending STP bit i2c: omap: implement handling for 'transferred' bytes Shubhrajyoti D (1): i2c: add 'transferred' field to struct i2c_msg arch/arm/mach-omap2/i2c.c | 3 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +- drivers/i2c/busses/i2c-omap.c | 156 - include/linux/i2c-omap.h | 1 + include/uapi/linux/i2c.h | 1 + 5 files changed, 89 insertions(+), 74 deletions(-) -- 1.8.0.rc0 -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: omap: adopt pinctrl support
On Tue, Oct 16, 2012 at 8:53 PM, Sebastien Guiriec s-guir...@ti.com wrote: Some GPIO expanders need some early pin control muxing. Due to legacy boards sometimes the driver uses subsys_initcall instead of module_init. This patch takes advantage of defer probe feature and pin control in order to wait until pin control probing before GPIO driver probing. It has been tested on OMAP5 board with TCA6424 driver. log: [0.482299] omap_i2c i2c.15: could not find pctldev for node /ocp/pinmux@4a00 2840/pinmux_i2c5_pins, deferring probe [0.482330] platform i2c.15: Driver omap_i2c requests probe deferral [0.484466] Advanced Linux Sound Architecture Driver Initialized. [4.746917] omap_i2c i2c.15: bus 4 rev2.4.0 at 100 kHz [4.755279] gpiochip_find_base: found new base at 477 [4.761169] gpiochip_add: registered GPIOs 477 to 500 on device: tca6424a Thanks, Acked-by: Shubhrajyoti D shubhrajy...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: omap: revert i2c: omap: switch to threaded IRQ support
On Mon, Oct 15, 2012 at 7:21 AM, Paul Walmsley p...@pwsan.com wrote: Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde (i2c: omap: switch to threaded IRQ support) causes communication with I2C devices to fail after system suspend/resume on all OMAP3 devices: Could you tell me which omap3 platform On Beagle Xm after mount /dev/mmcblk /mmcfs # mount /dev/mmcblk0p2 /mmcfs/ [ 412.480041] kjournald starting. Commit interval 5 seconds [ 412.490020] EXT3-fs (mmcblk0p2): using internal journal [ 412.495605] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode # # cd /mmcfs/ # # # ls bin omap3_usb_prcm.sh usb_prcm.sh dev omap3_usbhs_off.shusb_uhh_show.sh etc omap3_usbhs_on.sh usb_uhh_tll.sh init proc usbhs_clk_disable.sh lib readmem.dat usbhs_clk_enable.sh lost+foundroot usbhs_set_sm.sh mnt sbin usbhs_show.sh modules sys usr msc tmp var omap3_ehcidump.sh usb_omap3.sh # # # echo mem /sys/power/state [ 464.785461] PM: Syncing filesystems ... done. [ 464.791442] PM: Preparing system for mem sleep [ 464.798034] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 464.827301] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 464.858703] PM: Entering mem sleep [ 464.862304] Suspending console(s) (use no_console_suspend to debug) [ 464.994415] PM: suspend of devices complete after 121.002 msecs [ 464.998107] PM: late suspend of devices complete after 3.662 msecs [ 465.003173] PM: noirq suspend of devices complete after 5.004 msecs [ 465.003173] Disabling non-boot CPUs ... [ 466.225585] Successfully put all powerdomains to target state [ 466.228942] PM: noirq resume of devices complete after 3.051 msecs [ 466.232421] PM: early resume of devices complete after 2.349 msecs [ 467.492645] PM: resume of devices complete after 1260.131 msecs [ 467.546936] PM: Finishing wakeup. [ 467.550415] Restarting tasks ... done. # # # cat /debug/pm_debug/count | grep per_pwrdm per_pwrdm (ON),OFF:7,RET:0,INA:0,ON:8,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_clkdm-per_pwrdm (17) # echo mem /sys/power/state [ 1492.225311] PM: Syncing filesystems ... done. [ 1492.232177] PM: Preparing system for mem sleep [ 1492.238830] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 1492.268188] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 1492.299804] PM: Entering mem sleep [ 1492.303375] Suspending console(s) (use no_console_suspend to debug) [ 1492.435333] PM: suspend of devices complete after 120.880 msecs [ 1492.439025] PM: late suspend of devices complete after 3.692 msecs [ 1492.444091] PM: noirq suspend of devices complete after 5.004 msecs [ 1492.444091] Disabling non-boot CPUs ... [ 1493.745544] Successfully put all powerdomains to target state [ 1493.748901] PM: noirq resume of devices complete after 3.051 msecs [ 1493.752319] PM: early resume of devices complete after 2.319 msecs [ 1494.794067] PM: resume of devices complete after 1041.625 msecs [ 1494.848388] PM: Finishing wakeup. [ 1494.851867] Restarting tasks ... done. # # # cat /debug/pm_debug/count | grep per_pwrdm per_pwrdm (ON),OFF:8,RET:0,INA:0,ON:9,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 per_clkdm-per_pwrdm (17) # Anyways will retry with fs on mmc. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume
On Mon, Oct 15, 2012 at 2:46 PM, Kalle Jokiniemi kalle.jokini...@jollamobile.com wrote: ma, 2012-10-15 kello 09:21 +0300, Kalle Jokiniemi kirjoitti: Hi, pe, 2012-10-12 kello 14:46 +, Strashko, Grygorii kirjoitti: Hi Kevin, yep, [1] is the same fix - thanks. Hi Kalle, i've applied these changes and PM runtime fix on top of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git (omap2plus_defconfig) Could you check it with your use case, pls? (just to be sure that idea is right) Odd, it's not working. I'll add some debug prints to see what happens there. Well, seems after enabling irq 23 in the resume_noirq, someone does i2c_xfer and there is consequent flood of i2c_xfers and interrupts. If there is continuous xfers, you could enable debug LL and see who is queuing the transfers. Not sure now how these IRQ numbers get mapped these days, my debug print says it's irq number 72 (UART1 from TRM) that is flooding (although it's printed from the i2c-omap isr function, so it's still I2C bus irq...). Can you do a cat /proc/interrupts The irq enabling (in resume_noirq) is still slightly progressing after the flooding starts, but my watchdog kicks in before we get to the finish. Attached my debug prints patch and log. I used also no_console_suspend boot option. - Kalle -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume
On Fri, Oct 12, 2012 at 10:13 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Strashko, Grygorii grygorii.stras...@ti.com writes: Hi Kevin, yep, [1] is the same fix - thanks. Hi Kalle, i've applied these changes and PM runtime fix on top of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git (omap2plus_defconfig) Could you check it with your use case, pls? (just to be sure that idea is right) I think the ideas is right, but [1] introduces more potential problems since it disables the IRQ at the INTC well before being disabled at the device. I fail to see this point. Current driver supports master mode only. So unless there is a msg queued by the core. May be no interrupts should fire. what I mean msg - conf - intr - completion/error - autosuspend. With runtime PM autosuspend timeouts, that means any IRQs firing during the autosuspend delay will be lost, which basically nullifies the use of autosuspend. so I do not expect any interrupts between completion/error - autosuspend. Since Shubhrajyoti didn't respond to my runtime PM comments on the original patch, my apologies for the delay. I'll respin this patch by moving the INTC disable/enable into the runtime PM callbacks and make the changelog a bit more clear. Grygorii, that pm_runtime_resume() change is needed to. Can you spin a patch with just that change with a nice descriptive changelog about why it is needed? Thanks. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
On Sat, Oct 13, 2012 at 12:10 AM, Kevin Hilman khil...@deeprootsystems.com wrote: From: Kevin Hilman khil...@ti.com Currently, runtime PM is used to keep the device enabled only during active transfers and for a configurable runtime PM autosuspend timout after an xfer. In addition to idling the device, driver's -runtime_suspend() method currently disables device interrupts when idle. However, on some SoCs (notably OMAP4+), the I2C hardware may shared with other coprocessors. This means that the MPU will still recieve interrupts if a coprocessor is using the I2C device. To avoid this, also disable interrupts at the MPU INTC when idling the device in -runtime_suspend() (and re-enable them in -runtime_resume().) This part based on an original patch from Shubhrajyoti Datta. NOTE: for proper sharing the I2C with a coprocessor, this driver still needs hwspinlock support added. This change is also meant to address an issue reported by Kalle Jokiniemi where I2C bus interrupt may be enabled before an I2C device interrupt handler (e.g. just after noirq resume phase) causing an interrupt flood on the I2C bus interrupt before the device interrupt is enabled (e.g. interrupts coming from devices on I2C connected PMIC before the PMIC chained hanlder is enabled.) This problem is addresed by ensuring that the I2C bus interrupt left disabled until an I2C xfer is requested. Looks good to me. Will wait for Kalle though. Cc: Kalle Jokiniemi kalle.jokini...@jollamobile.com Cc: Grygorii Strashko grygorii.stras...@ti.com Cc: Shubhrajyoti Datta shubhrajy...@ti.com, Cc: Huzefa Kankroliwala huzef...@ti.com Cc: Nishanth Menon n...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com --- drivers/i2c/busses/i2c-omap.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index db31eae..e6413e8 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1255,6 +1255,7 @@ static int omap_i2c_runtime_suspend(struct device *dev) /* Flush posted write */ omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + disable_irq(_dev-irq); return 0; } @@ -1275,6 +1276,8 @@ static int omap_i2c_runtime_resume(struct device *dev) omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); } + enable_irq(_dev-irq); + /* * Don't write to this register if the IE state is 0 as it can * cause deadlock. -- 1.7.9.2 -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume
On Wed, Oct 10, 2012 at 5:48 PM, Kalle Jokiniemi kalle.jokini...@jollamobile.com wrote: The resume_noirq enables interrupts one-by-one starting from first one. Now if the wake up event for suspend came from i2c device, the i2c bus irq gets enabled before the threaded i2c device irq, causing a flood of i2c bus interrupts as the threaded irq that should clear the event is not enabled yet. Fixed the issue by adding suspend_noirq and resume_early functions that keep i2c bus interrupts disabled until resume_noirq has run completely. Issue was detected doing a wake up from autosleep with twl4030 power key on N9. Patch tested on N9. Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com Thanks for rebasing however since you were actually interested in one of the older stable releases how about cc stable? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
On Thu, Sep 20, 2012 at 9:38 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat API to the new PM QoS API. Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY class of PM QoS. The resulting MPU constraints are used by cpuidle to decide the next power state of the MPU subsystem. The I2C device latency timing is derived from the FIFO size and the clock speed and so is applicable to all OMAP SoCs. Agree thanks for doing that. Signed-off-by: Jean Pihet j-pi...@ti.com --- Rebased on git://git.pengutronix.de/git/wsa/linux.git, branch i2c-embedded/for-next thanks , tested with i2c tools on omap4sdp and omap3sdp Acked-by: Shubhrajyoti D shubhrajy...@ti.com --- arch/arm/plat-omap/i2c.c | 21 - drivers/i2c/busses/i2c-omap.c | 32 ++-- include/linux/i2c-omap.h |1 - 3 files changed, 18 insertions(+), 36 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] serial: omap: fix the overrun case
On Fri, Sep 21, 2012 at 5:05 PM, Felipe Balbi ba...@ti.com wrote: On Fri, Sep 21, 2012 at 04:46:52PM +0530, Shubhrajyoti wrote: On Friday 21 September 2012 04:30 PM, Felipe Balbi wrote: On Fri, Sep 21, 2012 at 03:52:56PM +0530, Shubhrajyoti D wrote: [...] it it is ! BRK_ERROR_BITS I return. That's what I mean. rlsi handler is basically taking care of those bits... So how come we get RLSI IRQ when those bits aren't set ? Meaning, you shouldn't ever need that check, right ? Ideally, whenever that handler is called, it's because BRK_ERROR_BITS are set. Maybe add a WARN_ONCE() kinda thing just to see if that will ever really happen ?? hmm yes. will get back. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] serial: omap: fix the overrun case
On Fri, Sep 21, 2012 at 7:48 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
[...]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
- functional testing on omap4sdp
- Verified idle and suspend path hits off on beagle.
Tested-by: Kevin Hilman khil...@ti.com
This fixes the console hang I was seeing on 3530/Overo.
Thanks for the test.
Could you test the v2
http://www.spinics.net/lists/arm-kernel/msg197050.html
I have removed the redundant check.
Thanks,
Thanks,
Kevin
drivers/tty/serial/omap-serial.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index a0d4460..bc22a2b 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -334,6 +334,13 @@ static unsigned int check_modem_status(struct
uart_omap_port *up)
static void serial_omap_rlsi(struct uart_omap_port *up, unsigned int lsr)
{
unsigned int flag;
+ unsigned char ch = 0;
+
+ if (!(lsr UART_LSR_BRK_ERROR_BITS))
+ return;
+
+ if (likely(lsr UART_LSR_DR))
+ ch = serial_in(up, UART_RX);
up-port.icount.rx++;
flag = TTY_NORMAL;
--
To unsubscribe from this list: send the line unsubscribe linux-serial in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP i2c: pinctrl-ify i2c-omap.c
On Thu, Sep 20, 2012 at 12:04 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Add support for pinctrl mux settings in the OMAP I2C driver. If no such pinctl bindings are found a warning message is printed. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- looks good Acked-by: Shubhrajyoti D shubhrajy...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RTC: TWL: ensure all interrupts are disabled during probe
Hi Kevin, On Fri, Sep 14, 2012 at 2:15 AM, Kevin Hilman khil...@deeprootsystems.com wrote: From: Kevin Hilman khil...@ti.com On some platforms, bootloaders are known to do some interesting RTC programming. Without going into the obscurities as to why this may be the case, suffice it to say the the driver should not make any assumptions about the state of the RTC when the driver loads. In particular, the driver probe should be sure that all interrupts are disabled until otherwise programmed. This was discovered when finding bursty I2C traffic every second on Overo platforms. This I2C overhead was keeping the SoC from hitting deep power states. The cause was found to be the RTC firing every second on the I2C-connected TWL PMIC. Special thanks to Felipe Balbi for suggesting to look for a rogue driver as the source of the I2C traffic rather than the I2C driver itself. Special thanks to Steve Sakoman for helping track down the source of the continuous RTC interrups on the Overo boards. Tested that the continuous interrupt issue after doing a i2c mm on omap4sdp. This patch solves the issue. thanks, Cc: Felipe Balbi ba...@ti.com Cc: Steve Sakoman st...@sakoman.com Signed-off-by: Kevin Hilman khil...@ti.com --- Patch applies to v3.6-rc5 drivers/rtc/rtc-twl.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c index c5d06fe..9277d94 100644 --- a/drivers/rtc/rtc-twl.c +++ b/drivers/rtc/rtc-twl.c @@ -495,6 +495,11 @@ static int __devinit twl_rtc_probe(struct platform_device *pdev) if (ret 0) goto out1; + /* ensure interrupts are disabled, bootloaders can be strange */ + ret = twl_rtc_write_u8(0, REG_RTC_INTERRUPTS_REG); + if (ret 0) + dev_warn(pdev-dev, unable to disable interrupt\n); + Now that it is always 0 can the below read be removed as it is redundant now. /* init cached IRQ enable bits */ ret = twl_rtc_read_u8(rtc_irq_bits, REG_RTC_INTERRUPTS_REG); if (ret 0) -- 1.7.9.2 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RTC: TWL: ensure all interrupts are disabled during probe
On Fri, Sep 14, 2012 at 7:37 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Shubhrajyoti Datta omaplinuxker...@gmail.com writes: Hi Kevin, On Fri, Sep 14, 2012 at 2:15 AM, Kevin Hilman khil...@deeprootsystems.com wrote: From: Kevin Hilman khil...@ti.com On some platforms, bootloaders are known to do some interesting RTC programming. Without going into the obscurities as to why this may be the case, suffice it to say the the driver should not make any assumptions about the state of the RTC when the driver loads. In particular, the driver probe should be sure that all interrupts are disabled until otherwise programmed. This was discovered when finding bursty I2C traffic every second on Overo platforms. This I2C overhead was keeping the SoC from hitting deep power states. The cause was found to be the RTC firing every second on the I2C-connected TWL PMIC. Special thanks to Felipe Balbi for suggesting to look for a rogue driver as the source of the I2C traffic rather than the I2C driver itself. Special thanks to Steve Sakoman for helping track down the source of the continuous RTC interrups on the Overo boards. Tested that the continuous interrupt issue after doing a i2c mm on omap4sdp. This patch solves the issue. thanks, Cc: Felipe Balbi ba...@ti.com Cc: Steve Sakoman st...@sakoman.com Signed-off-by: Kevin Hilman khil...@ti.com --- Patch applies to v3.6-rc5 drivers/rtc/rtc-twl.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c index c5d06fe..9277d94 100644 --- a/drivers/rtc/rtc-twl.c +++ b/drivers/rtc/rtc-twl.c @@ -495,6 +495,11 @@ static int __devinit twl_rtc_probe(struct platform_device *pdev) if (ret 0) goto out1; + /* ensure interrupts are disabled, bootloaders can be strange */ + ret = twl_rtc_write_u8(0, REG_RTC_INTERRUPTS_REG); + if (ret 0) + dev_warn(pdev-dev, unable to disable interrupt\n); + Now that it is always 0 can the below read be removed as it is redundant now. Possibly, but I don't know this HW well enough to know if there are any persistent bits in that register on any of the various derivations of this PMIC. Since this read-back value is used throughout the driver, I decided not to mess with it when doing this targetted fix. Indeed makes sense. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 00/23]I2C big cleanup
On Wed, Sep 12, 2012 at 7:14 PM, Wolfram Sang w.s...@pengutronix.de wrote: On Wed, Sep 12, 2012 at 12:18:50PM +0200, Wolfram Sang wrote: I donot see the warning. Am I missing something? I deleted my logfiles already. Ignore it for now, if it comes up again with your new series, I will give a more detailed pointer. Sorry, the section mismatch was not related to I2C it seems: Thanks for the report just sent a patch fixing that. WARNING: vmlinux.o(.data+0x30958): Section mismatch in reference from the variable rx51_si4713_dev to the (unknown reference) .init.data:(unknown) The variable rx51_si4713_dev references the (unknown reference) __initdata (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console Got it with an allnoconfig and then selecting MMU and OMAP. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlBQkbsACgkQD27XaX1/VRtbuACgkBa0lOIN551eec9TSetVPsCE Ew0AoKizKon3DIILpERWJIwzAXdgRVDc =T4Yq -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/3] spi: omap2-mcspi: spi cleanups
On Wed, Aug 22, 2012 at 10:29 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, Aug 22, 2012 at 11:35:11AM +0530, Shubhrajyoti D wrote: This patch does the following Calls the pm_runtime_* functions directly. Remove the MOD_REG_BIT macro usage thereby removiing un-needed branch. At remove dont use the autosuspend runtime calls. Applied all, thanks. thanks. The following changes since commit 23dcfa61bac244e1200ff9ad19c6e9144dcb6bb5: Merge branch 'akpm' (Andrew's patch-bomb) (2012-08-21 17:22:22 -0700) When sending pull requests please always base them off a tag of some kind, normally one of Linus' is a good option if you've no special needs. This one looks like it's based off -next so can't be pulled into any other tree, -next is rebased daily. Actually there was a patch in your tree that I sent which is not yet in linus tree so I rebased it to linux-next to avoid any merge conflicts. Henceforth I will rebase it to your tree. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] mmc: omap_hsmmc: remove access to SYSCONFIG register
Hi Venkat,
Some doubts below.
On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S svenk...@ti.com wrote:
SYSCONFIG register of HSMMC IP is managed by the omap hwmod
abstraction layer.
At init only right?
Resetting the IP and configuring the correct
SYSCONFIG mode is centrally managed by hwmod.
Remove code which manipulates IP reset and SYSCONFIG directly in the
driver.
I am not sure if mmc needs a reset.
However IMHO
In case it needs a reset
the hwmod way could be to use omap_hwmod_reset
However I fear it may be an issue with dt.
or
may be sysc could be restored something like [1]
if it doesnt need reset even the check for the SYSSTATUS could be
considered for removal.
[1] http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg12041.html
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 24 ++--
1 file changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index da4f5a7..4bc55ac 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -44,7 +44,6 @@
#include plat/cpu.h
/* OMAP HSMMC Host Controller Registers */
-#define OMAP_HSMMC_SYSCONFIG 0x0010
#define OMAP_HSMMC_SYSSTATUS 0x0014
#define OMAP_HSMMC_CON 0x002C
#define OMAP_HSMMC_BLK 0x0104
@@ -576,21 +575,8 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
if (host-context_loss == context_loss)
return 1;
- /* Wait for hardware reset */
- timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
- while ((OMAP_HSMMC_READ(host-base, SYSSTATUS) RESETDONE) !=
RESETDONE
-time_before(jiffies, timeout))
- ;
-
- /* Do software reset */
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG, SOFTRESET);
- timeout = jiffies + msecs_to_jiffies(MMC_TIMEOUT_MS);
- while ((OMAP_HSMMC_READ(host-base, SYSSTATUS) RESETDONE) !=
RESETDONE
-time_before(jiffies, timeout))
- ;
-
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ if (!OMAP_HSMMC_READ(host-base, SYSSTATUS) RESETDONE)
+ return 1;
Should this check be removed.
if (host-pdata-controller_flags OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
if (host-power_mode != MMC_POWER_OFF
@@ -1593,10 +1579,6 @@ static void omap_hsmmc_conf_bus_power(struct
omap_hsmmc_host *host)
value = OMAP_HSMMC_READ(host-base, CAPA);
OMAP_HSMMC_WRITE(host-base, CAPA, value | capa);
- /* Set the controller to AUTO IDLE mode */
- value = OMAP_HSMMC_READ(host-base, SYSCONFIG);
- OMAP_HSMMC_WRITE(host-base, SYSCONFIG, value | AUTOIDLE);
-
/* Set SD bus power bit */
set_sd_bus_power(host);
}
@@ -1654,8 +1636,6 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
pm_runtime_get_sync(host-dev);
- seq_printf(s, SYSCONFIG:\t0x%08x\n,
- OMAP_HSMMC_READ(host-base, SYSCONFIG));
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
seq_printf(s, HCTL:\t\t0x%08x\n,
--
1.7.11.1.25.g0e18bef
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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-hsmmc: Implementation of i761 errata
On Mon, Aug 20, 2012 at 12:25 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Mon, Aug 20, 2012 at 12:08 PM, S, Venkatraman svenk...@ti.com wrote: On Fri, Aug 17, 2012 at 11:43 PM, Puttagunta, Viswanath vi...@ti.com wrote: [...] Signed-off-by: Semen Protsenko semen.protse...@ti.com The implementation looks fine, but can we simply not set the errata flag and make this as default behaviour ? I suppose the documented behaviour with CSRE and RSP10 is independent of the errata.. Also, please send it to the linux-mmc list as well. Vish We don't know if this errata effects OMAP5 as well. So, I think we should only do this if we are OMAP4. That's precisely why the code shouldn't check for cpu_() flags. There are other OMAP variants as well and we can't check all of them What I mean is to make the check for RSP10 and CSRE all the time as part of the IRQ check. Then it equally applies to silcon with or without errata. Apart from above comment, please don't add the cpu_is_xxx() check inside device driver. You can pass that information from platform code while registering the MMC controllers using a flag and then just use that flag to enable/disable errata in the driver. The other option is to check something like MMCHS_HL_REV to get the ip revision and decide. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rmk back but still recovering (was Re: Reminder - rmk still on vacation)
On Mon, Jul 30, 2012 at 1:10 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: [...] Why? The DMA driver itself is optional. That was Tony's point too. Unfortunately MMC and SPI driver don't work today without DMA. Some works needs to be done to support polling mode and am bit skeptical if it is really worth it. Same case be with other SDMA supported drivers mostly. Russell, Tony, Can I request to include the DMA MMC changes into this merge window ? We have many cleanups and new patches waiting to be queued up for next (3.7) merge window, and it'd be easier if they are implemented on top of the DMA changes, so that it gets tested together, and don't create merge conflicts. I am looking into implementing polling mode, which might take some time. Thanks Venkat. For the SPI driver as well I heard from Shubro (in cc) that he is looking into polling mode. I had a patch in case of errors falling back to poll mode http://www.spinics.net/lists/linux-omap/msg74417.html IMHO, we should merge the OMAP DMA engine support which is now sufficiently tested and has been in linux-next for some time. Polling mode and ASOC related issues can be then debugged directly on mainline. For the time being, the SOC patch which Tony merged in linux-omap master can be included along with rest of the OMAP DMA engine patches to have working kernel. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 3/3] i2c: omap: Add support for I2C_M_STOP message flag
On Wed, Jul 18, 2012 at 4:43 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Shubhrajyoti, On Wednesday 18 July 2012 11:49:24 Shubhrajyoti wrote: On Tuesday 26 June 2012 07:47 PM, Laurent Pinchart wrote: Generate a stop condition after each message marked with I2C_M_STOP. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/i2c/busses/i2c-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 801df60..cf1bda0 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -545,6 +545,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, if (dev-speed 400) w |= OMAP_I2C_CON_OPMODE_HS; + if (msg-flags I2C_M_STOP) + stop = 1; How about patching omap_i2c_xfer (caller) instead. There are some debug prints of stop above that will not reflect the real value. omap_i2c_xfer() doesn't look at the content of individual messages, I thought it was cleaner not to modify that. OK fair enough. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv11 0/6] I2C cleanups
On Thu, Jun 28, 2012 at 8:41 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: This is a minimal cleanup series. If there are no further comments can this series be queued? The patch series does the following - Bus busy recovery mechanism. - Make the i2c use SET_RUNTIME_PM_OPS - Use INIT_COMPLETION instead of init_completion - the reset patch is dropped will try to rework it as per the review comments recieved. This applies on Wolfram's i2c-embedded/for-next branch. Functional testing on omap4430 , 4460 panda and omap3sdp. The following changes since commit 0f009a914b40be8786fa67b1f4345cacc263b48c: i2c: tegra: make all resource allocation through devm_* (2012-06-13 16:01:38 +0200) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git for_next/omap/minimal_cleanup Jon Hunter (1): i2c: omap: Correct I2C revision for OMAP3 Shubhrajyoti D (4): i2c: omap: Optimise the remove code i2c: omap: Use SET_RUNTIME_PM_OPS i2c: omap: Do not initialise the completion everytime i2c: omap: Remove the definition of SYSS_RESETDONE_MASK Vikram Pandita (1): i2c: omap: Recover from Bus Busy condition drivers/i2c/busses/i2c-omap.c | 60 1 files changed, 42 insertions(+), 18 deletions(-) -- 1.7.5.4 -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 06/17] i2c: omap: split out [XR]DR and [XR]RDY
On Mon, Jul 2, 2012 at 5:26 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Fri, Jun 29, 2012 at 03:43:26PM +0530, Shubhrajyoti D wrote:
From: Felipe Balbi ba...@ti.com
While they do pretty much the same thing, there
are a few peculiarities. Specially WRT erratas,
it's best to split those out and re-factor the
read/write loop to another function which both
cases call.
This last part will be done on another patch.
While at that, also avoid an unncessary register
read since dev-fifo_len will always contain the
correct amount of data to be transferred.
this statement isn't valid anymore, but I'd like it to be. See below
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 126
++--
1 files changed, 94 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 359ee08..45bd731 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -820,36 +820,64 @@ complete:
return IRQ_HANDLED;
}
- if (stat (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
+ if (stat OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
+ if (dev-fifo_size)
+ num_bytes = (omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG) 8)
+ 0x3F;
I wanted to avoid reading registers if we don't have to. This value will
be sitting in dev-buf_len.
Yes will fix this and resend.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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: OMAP: xfer: fix runtime PM get/put balance on error
Hi Kevin, Thanks for the patch , a doubt below On Wed, Jun 27, 2012 at 7:15 AM, Kevin Hilman khil...@ti.com wrote: In omap_i2c_xfer(), ensure pm_runtime_put() is called, even on failure. So the failure means that the usecount is incremented. However the device was not enabled. In that case could we consider void pm_runtime_put_noidle(struct device *dev); - decrement the device's usage counter Which will only decrement the counter and does not try to disable it. However I am not sure what happens if you try to disable an already disabled device. Without this, after a failed xfer, the runtime PM usecount will have been incremented, but not decremented Agree. causing the usecount to never reach zero after a failure. This keeps the device always runtime PM enabled which keeps the enclosing power domain active, and prevents full-chip retention/off from happening during idle. Cc: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com --- This patch applies to current i2c-embedded/for-next branch drivers/i2c/busses/i2c-omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 9895fa7..b105733 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -582,7 +582,7 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) r = pm_runtime_get_sync(dev-dev); if (IS_ERR_VALUE(r)) - return r; + goto out; r = omap_i2c_wait_for_bb(dev); if (r 0) -- 1.7.9.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/11] I2C: OMAP: Handle error check for pm runtime
On Wed, Jun 27, 2012 at 7:13 AM, Kevin Hilman khil...@ti.com wrote: Shubhrajyoti D shubhrajy...@ti.com writes: If PM runtime get_sync fails return with the error so that no further reads/writes goes through the interface. This will avoid possible abort. Add a error message in case of failure with the cause of the failure. Reviewed-by: Kevin Hilman khil...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com This patch introduced a regression where the runtime PM usecount will never reach zero and so CORE retention is prevented after any xfer failures... --- -v10 Use IS_ERR_VALUE -v9 Fix the error handling drivers/i2c/busses/i2c-omap.c | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 44e8cfa..c39b72f 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -585,7 +585,9 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) int i; int r; - pm_runtime_get_sync(dev-dev); + r = pm_runtime_get_sync(dev-dev); + if (IS_ERR_VALUE(r)) + return r; This return should be 'goto out' so the runtime PM usecount is decremented by the 'put'. Otherwise, after failure, the usecount remains non-zero, so the device is considered 'active' and keeps the containing power domain active. I found this on a 3730/OveroSTORM where the suspend/resume of MMC fails because I2C is already suspended. After the suspend though, the CORE powerdomain never again hits retention, and I tracked it down to this. I'll send a separate patch to fix this shortly. Thanks, 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 3/8] I2C: OMAP: use devm_* functions
On Mon, Jun 25, 2012 at 3:21 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Jun 21, 2012 at 03:38:44PM +0530, Shubhrajyoti D wrote: The various devm_* functions allocate memory that is released when a driver detaches. This patch uses devm_kzalloc, devm_request_and_ioremap for data that is allocated in the probe function of a platform device and is only freed in the remove function. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com this looks a lot like: http://marc.info/?l=linux-omapm=133969143407572w=2 I wonder why wasn't that one used instead ? Indeed will drop this one from the series. In fact, missed the irq part. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 06/13] I2C: OMAP: Correct I2C revision for OMAP3
On Wed, Jun 20, 2012 at 7:44 PM, Tony Lindgren t...@atomide.com wrote:
* Shubhrajyoti shubhrajy...@ti.com [120620 06:06]:
On Wednesday 20 June 2012 04:02 PM, Tony Lindgren wrote:
* Shubhrajyoti D shubhrajy...@ti.com [120618 07:35]:
From: Jon Hunter jon-hun...@ti.com
The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
revision is the same for 3430 and 3530. However, the OMAP3630 device has
the
same I2C revision as OMAP4. Correct the revision definition to reflect
this.
This patch is based on work done by Jon Hunter jon-hun...@ti.com
Changes from his patch
- Update OMAP_I2C_REV_ON_3430 also to reflect that it is same as 3530
...
/* timeout waiting for the controller to respond */
#define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
@@ -298,7 +298,7 @@ static int omap_i2c_reset(struct omap_i2c_dev *dev)
omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
SYSC_AUTOIDLE_MASK);
- } else if (dev-rev = OMAP_I2C_REV_ON_3430) {
+ } else if (dev-rev = OMAP_I2C_REV_ON_3430_3530) {
dev-syscstate = SYSC_AUTOIDLE_MASK;
dev-syscstate |= SYSC_ENAWAKEUP_MASK;
dev-syscstate |= (SYSC_IDLEMODE_SMART
Having to patch all over the place for these revision defines leads
into unmaintainable code as new SoCs get added.
Please instead just check the revision once during init, then set
up some feature bits like I2C_OMAP_NEEDS_XYZ_RESET that the runtime
code can check.
Even now at probe
dev-rev is set by reading the rev register.
The (macro)name used to identify is only changed.
Also all the ips need reset the difference is that 2430 has less bits eg
only autoidle and reset.
So a flag needs reset may not be meaningful.
Hmm OK so this is a cosmetic/readability fix..
Yes
..but your earlier patch now spreads the checking of revision
to the new non-init function omap_i2c_reset.
Why don't you just do this cosmetic/readability rename fix
before your 03/13 patch?
OK thats doable.I can reorder the patch.
Then set the already existing
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE during init for some
revisions and use that instead of the rev check in
omap_i2c_reset?
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE is a hwmod flag whose intention is to find
know if it can lose context after idle.
The rev check that we have is because post reset( triggered by driver)
to know if we have to restore only autoidle or other bits like clockactivity
sidle , enable wakeup .
Tony
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 13/13] I2C: OMAP: simplify omap_i2c_ack_stat()
On Mon, Jun 18, 2012 at 9:00 PM, Wolfram Sang w.s...@pengutronix.de wrote:
On Mon, Jun 18, 2012 at 08:00:28PM +0530, Shubhrajyoti D wrote:
From: Felipe Balbi ba...@ti.com
stat BIT(1) is the same as BIT(1),
Not true. I'd guess you are missing some context in the patch
description.
See the explanation , hope I understood your concern correctly.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70277.html
so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by : Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6a79089..bac6305 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -763,7 +763,7 @@ static int errata_omap3_i462(struct omap_i2c_dev *dev,
u16 *stat, int *err)
while (--timeout !(*stat OMAP_I2C_STAT_XUDF)) {
if (*stat (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, *stat (OMAP_I2C_STAT_XRDY |
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
return -ETIMEDOUT;
}
@@ -824,10 +824,11 @@ complete:
*/
if (stat (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, stat
- (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
- OMAP_I2C_STAT_ARDY));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR |
+ OMAP_I2C_STAT_ARDY));
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
@@ -874,8 +875,8 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR));
continue;
}
@@ -922,8 +923,8 @@ complete:
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
- omap_i2c_ack_stat(dev,
- stat (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR));
continue;
}
--
1.7.5.4
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv10 00/11] I2C fixes
On Fri, Jun 1, 2012 at 4:29 AM, Kevin Hilman khil...@ti.com wrote: Shubhrajyoti D shubhrajy...@ti.com writes: The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - In case of i2c remove register access was done without any get_sync fix the same. - Folds a patch from Tasslehoff to prevent any merge conflicts. - Prevents the XDUF flag to be set if the underflow condition is not met. - As per discussion in [1] .Adds a patch to rename the 1p153 errata and use the unique id instead as the section number in the recent errata docs has changed. v9: Fix the comments from Wolfram Sang v10: Add a patch from Neil to the series. Fix kevin comments update the patches with comments. Shubhrajyoti, thanks for the updates. Wolfgang, with these updates and testing a bit better described, I'm OK with you merging it. Merging it now will give it plenty of time to bake in linux-next and get more test exposure. Agree, These are only fixes can it be considered for rc3? Thanks and Regards, Shubhrajyoti Thanks, Kevin [1] http://www.spinics.net/lists/linux-i2c/msg07607.html Tested on omap4sdp and omap3sdp. - Did functional tests read write on both the platforms. - Off mode and retention on OMAP3 - On OMAP4 just did echo mem /sys/power/state and wakeup. Did see. [ 1360.595855] Successfully put all powerdomains to target state However didnt see the ret count for other than mpu_pwrdm increase. I think power support for omap4 is minimal. The following changes since commit b48b2c3e50433ff6f7e46186daa7f986bd960215: openrisc: use generic strnlen_user() function (2012-05-27 21:00:32 -0700) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git i2c_omap-fixes Neil Brown (1): OMAP/I2C - Fix timeout problem during suspend. Shubhrajyoti D (9): I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME I2C: OMAP: Fix the mismatch of pm_runtime enable and disable I2C: OMAP: Fix the interrupt clearing in OMAP4 I2C: OMAP: Prevent the register access after pm_runtime_put in probe I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero I2C: OMAP: Fix the crash in i2c remove I2C: OMAP: Handle error check for pm runtime I2C: OMAP: Do not set the XUDF(Transmit underflow) if the underflow is not reached I2C: OMAP: Rename the 1p153 to the erratum id i462 Tasslehoff Kjappfot (1): I2C: OMAP: prevent the overwrite of the errata flags drivers/i2c/busses/i2c-omap.c | 129 - 1 files changed, 63 insertions(+), 66 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 07/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
Hi Edurardo,
A few doubts,
On Fri, May 25, 2012 at 1:55 PM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
Created a new platform driver for the platform device created by the
control module mfd core, wrt usb. This driver has API's to power on/off
the phy and the API's to write to musb mailbox.
(p.s. the mailbox for musb in omap4 is present in system control
module)
[kis...@ti.com: wrote the original API's related to USB functions]
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/usb/otg/Kconfig | 13
drivers/usb/otg/Makefile | 1 +
drivers/usb/otg/omap4-usb-phy.c | 130
+
include/linux/usb/omap4_usb_phy.h | 53 +++
4 files changed, 197 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/otg/omap4-usb-phy.c
create mode 100644 include/linux/usb/omap4_usb_phy.h
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..e2840f1 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,19 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP4_USB_PHY
+ tristate Texas Instruments OMAP4+ USB pin control driver
+ depends on MFD_OMAP_CONTROL
+ help
+ If you say yes here you get support for the Texas Instruments
+ OMAP4+ USB pin control driver. The register set is part of system
+ control module.
+
+ USB phy in OMAP configures control module register for powering on
+ the phy, configuring VBUSVALID, AVALID, IDDIG and SESSEND. For
+ performing the above mentioned configuration, API's are added in
+ by this children of the control module driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..60c8c83 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP4_USB_PHY) += omap4-usb-phy.o
obj-$(CONFIG_NOP_USB_XCEIV) += nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT) += ulpi_viewport.o
diff --git a/drivers/usb/otg/omap4-usb-phy.c b/drivers/usb/otg/omap4-usb-phy.c
new file mode 100644
index 000..a29ea45
--- /dev/null
+++ b/drivers/usb/otg/omap4-usb-phy.c
@@ -0,0 +1,130 @@
+/*
+ * OMAP4 system control module driver, USB control children
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Contact:
+ * Kishon Vijay Abraham I kis...@ti.com
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/mfd/omap_control.h
+#include linux/usb/omap4_usb_phy.h
+
+/**
+ * omap4_usb_phy_power - power on/off the phy using control module reg
+ * @dev: struct device *
+ * @on: 0 or 1, based on powering on or off the PHY
Could it be bool ?
+ *
+ * omap_usb2 can call this API to power on or off the PHY.
+ */
+int omap4_usb_phy_power(struct device *dev, int on)
+{
+ u32 val;
+ int ret;
+
+ if (on) {
+ ret = omap_control_readl(dev, CONTROL_DEV_CONF, val);
+ if (!ret (val PHY_PD)) {
+ ret = omap_control_writel(dev, ~PHY_PD,
+ CONTROL_DEV_CONF);
+ /* XXX: add proper documentation for this delay */
+ mdelay(200);
Also does it have to be a busy one?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] ARM: OMAP4 device off support
On Fri, Apr 20, 2012 at 8:37 PM, Tero Kristo t-kri...@ti.com wrote:
On Fri, 2012-04-20 at 20:21 +0530, Datta, Shubhrajyoti wrote:
On Fri, Apr 20, 2012 at 8:13 PM, Tero Kristo t-kri...@ti.com wrote:
On Fri, 2012-04-20 at 06:55 -0700, Kevin Hilman wrote:
Tero Kristo t-kri...@ti.com writes:
[...]
I tried your branch on gp/emu devices but could not reproduce this
issue.
My observation is that while resuming, omap_hsmmc.1 eMMC is
trying to turn on phoenix vaux1 regulator via i2c which fails due
to controller timeout.
Note: eMMC is present only on sdp/blaze
Did you try this with off-mode enabled and did you check the device
actually goes to off? (see pm_debug/count and verify core off count is
increasing.) And as said, I was only able to see this problem on a blaze
device, panda works fine. But yes, you are probably right and it is not
an MMC driver issue but I2C.
Can you try the patch below? It sounds like the same problem.
Doesn't help with this one. I guess I2C loses context during device off
and it is not restored properly.
-Tero
Could you try the following patch
https://lkml.org/lkml/2012/3/30/345
That does the trick, after this it is working fine on blaze, and this
also fixes the timeout issues seen on panda board (meaning wake-up from
device off is much faster.)
Thats great.
Feel free to try the following.
I2C conditional restore
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66859.html
Also cooked a below rfc/untested patch for mmc restore.
From c28ec76f8a20c3ce59b72245ab9f3bc293b1ac43 Mon Sep 17 00:00:00 2001
From: Shubhrajyoti D shubhrajy...@ti.com
Date: Mon, 23 Apr 2012 11:52:54 +0530
Subject: [RFC PATCH] hsmmc: omap: Support for device off
Attempt to have device off support. Current the function hsmmc_get_context_loss
is made NULL for OMAP4. Remove it as post Terro's patches context may be lost.
Also it is good to have no assumptions of the context loss in the
driver.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/hsmmc.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index b0268ea..2361f24 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -32,17 +32,11 @@ static u16 control_mmc1;
#define HSMMC_NAME_LEN 9
-#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
-
static int hsmmc_get_context_loss(struct device *dev)
{
return omap_pm_get_dev_context_loss_count(dev);
}
-#else
-#define hsmmc_get_context_loss NULL
-#endif
-
static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] UART: OMAP: Cut the clock in the error cases
On Wed, Apr 18, 2012 at 8:43 PM, Shubhrajyoti shubhrajy...@ti.com wrote:
Kevin
Yes agree completely. Will describe that in the changelog.
--
Does the following changelog look ok?
From 37fdc2d40c9b2b19b8c5a9a4b8f7dd547d420f55 Mon Sep 17 00:00:00 2001
From: Shubhrajyoti D shubhrajy...@ti.com
Date: Wed, 4 Apr 2012 16:32:37 +0530
Subject: [PATCH] UART: OMAP: call pm_runtime_put/autosuspend in the error cases
In the error cases the runtime_put call is missed. This patch intends to fix the
same. In case dma request fails, we fall back to the nondma mode so after
enabling the threshold call put_autosuspend.
Cc: Govindraj.R govindraj.r...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/tty/serial/omap-serial.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index fe099bb..10e80bb 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -319,6 +319,8 @@ static void serial_omap_start_tx(struct uart_port *port)
if (ret 0) {
serial_omap_enable_ier_thri(up);
+ pm_runtime_mark_last_busy(up-pdev-dev);
+ pm_runtime_put_autosuspend(up-pdev-dev);
return;
}
}
@@ -1029,8 +1031,10 @@ static int serial_omap_poll_get_char(struct
uart_port *port)
pm_runtime_get_sync(up-pdev-dev);
status = serial_in(up, UART_LSR);
- if (!(status UART_LSR_DR))
+ if (!(status UART_LSR_DR)) {
+ pm_runtime_put(up-pdev-dev);
return NO_POLL_CHAR;
+ }
status = serial_in(up, UART_RX);
pm_runtime_put(up-pdev-dev);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 04/18] I2C: OMAP: I2C register restore only if context is lost
Hi Kevin,
Thanks for your review,
On Tue, Apr 17, 2012 at 7:15 PM, Kevin Hilman khil...@ti.com wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
Currently i2c register restore is done always.
Adding conditional restore.
The i2c register restore is done only if the context is lost.
OK, minor comment below.
Also remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
The definition is removed, but I don't see any of the users removed.
If the users were cleaned up earlier in the series, then the removal of
this should be done with that, or as a separate patch. I don't see why
it belongs with this patch.
I have not removed the users actually the macro was redefined.
I have instead used the definition in omap_hwmod.h which gets added
when I include omap_device.h
Let me know if you prefer a separate patch?
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/plat-omap/i2c.c | 3 ++
drivers/i2c/busses/i2c-omap.c | 52
++--
include/linux/i2c-omap.h | 1 +
3 files changed, 38 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index db071bc..4ccab07 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -179,6 +179,9 @@ static inline int omap2_i2c_add_bus(int bus_id)
*/
if (cpu_is_omap34xx())
pdata-set_mpu_wkup_lat =
omap_pm_set_max_mpu_wakeup_lat_compat;
+
+ pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
+
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a882558..45389db 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,6 +43,7 @@
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
+#include plat/omap_device.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -157,9 +158,6 @@ enum {
#define OMAP_I2C_SYSTEST_SDA_I (1 1) /* SDA line
sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0) /* SDA line
drive out */
-/* OCP_SYSSTATUS bit definitions */
-#define SYSS_RESETDONE_MASK (1 0)
-
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK (0x3 8)
#define SYSC_SIDLEMODE_MASK (0x3 3)
@@ -184,6 +182,7 @@ struct omap_i2c_dev {
u32 latency; /* maximum mpu wkup latency */
void (*set_mpu_wkup_lat)(struct device *dev,
long latency);
+ int (*get_context_loss_count)(struct device *dev);
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -206,6 +205,7 @@ struct omap_i2c_dev {
u16 syscstate;
u16 westate;
u16 errata;
+ int dev_lost_count;
};
static const u8 reg_map_ip_v1[] = {
@@ -1025,6 +1025,7 @@ omap_i2c_probe(struct platform_device *pdev)
dev-speed = pdata-clkrate;
dev-flags = pdata-flags;
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
+ dev-get_context_loss_count = pdata-get_context_loss_count;
dev-dtrev = pdata-rev;
}
@@ -1151,12 +1152,32 @@ omap_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_RUNTIME
+static void omap_i2c_restore(struct omap_i2c_dev *dev)
+{
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev-pscstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev-scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev-sclhstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev-bufstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ /*
+ * Don't write to this register if the IE state is 0 as it can
+ * cause deadlock.
+ */
+ if (dev-iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev-iestate);
+
+}
static int omap_i2c_runtime_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
u16 iv;
+ if (_dev-get_context_loss_count)
+ _dev-dev_lost_count = _dev-get_context_loss_count(dev);
+
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
if (_dev-dtrev == OMAP_I2C_IP_VERSION_2)
omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR, 1);
@@
Re: [PATCHv7 01/18] I2C: OMAP: make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME
Hi Felipe, On Wed, Apr 11, 2012 at 5:02 PM, Felipe Balbi ba...@ti.com wrote: On Wed, Apr 11, 2012 at 04:42:39PM +0530, Shubhrajyoti D wrote: The functions omap_i2c_unidle/idle are called from omap_i2c_runtime_resume and omap_i2c_runtime_suspend which is compiled for CONFIG_PM_RUNTIME. This patch removes the omap_i2c_unidle/idle functions and folds them into the runtime callbacks. This fixes the below warn when CONFIG_PM_RUNTIME is not defined CC arch/arm/mach-omap2/board-ti8168evm.o drivers/i2c/busses/i2c-omap.c:272: warning: 'omap_i2c_unidle' defined but not used drivers/i2c/busses/i2c-omap.c:293: warning: 'omap_i2c_idle' defined but not used CC net/ipv4/ip_forward.o Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com how about just moving them into the #ifdef ? /me thinks it's easier to read with the function. Matter of taste though, it's not that much code. Kevin preferred folding into the runtime functions. http://www.spinics.net/lists/linux-omap/msg62764.html Don't feel strongly though. -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 14/18] I2C: OMAP: Use SET_RUNTIME_PM_OPS
Hi Felipe,
On Wed, Apr 11, 2012 at 5:05 PM, Felipe Balbi ba...@ti.com wrote:
On Wed, Apr 11, 2012 at 04:42:52PM +0530, Shubhrajyoti D wrote:
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dd65416..28de1d2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1217,15 +1217,12 @@ static int omap_i2c_runtime_resume(struct device
*dev)
return 0;
}
+#endif
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
-#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
-#else
-#define OMAP_I2C_PM_OPS NULL
-#endif
I think you should keep this define, otherwise the pm pointer will
always be valid.
Will correct it .
Thanks,
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 16/18] I2C: OMAP: fix missing handling of errata I2C_OMAP3_1P153
Hi Jon, + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev= OMAP_I2C_REV_ON_3430_3530) dev-errata |= I2C_OMAP3_1P153; The errata ID is not correct. I believe that 1P153 is referring to the section number in the errata doc and not the errata ID. The errata ID should be i451 in the latest OMAP34xx and OMAP36xx docs. Please can you update this? The section number changed in the latest errata docs and it took me a minute to find this. Do you mind if that is a separate patch? Cheers Jon -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 0/3] spi: omap2-mcspi: driver updates
Hi Grant On Tue, Apr 3, 2012 at 1:10 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Sat, 31 Mar 2012 17:06:55 +0530, Shubhrajyoti D shubhrajy...@ti.com wrote: The patch series does the following cleanups - Makes the driver use autosuspend - Folds Benoit's bus_num removal patch in the series - The tmp variable is used to write this can be optimised as it is not needed if the value is directly written. Acknowledge Tarun for the suggestion. This is also available through git : git://gitorious.org/linus-tree/linus-tree.git branch : spi_next Rebased to Grant's spi/next branch. Merged, thanks. Thanks , BTW, it's easier to pull if you put the branch after the git URL (I can cut and paste all at once): git://gitorious.org/linus-tree/linus-tree.git spi_next git request-pull can be your friend here. OK good idea will do that. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] spi/omap: Remove bus_num usage for instance index
Hi Tarun, On Wed, Mar 28, 2012 at 2:15 PM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Mon, Mar 26, 2012 at 7:14 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: From: Benoit Cousson b-cous...@ti.com bus_num was used to reference the mcspi controller instance in a fixed array. Remove this array and store this information directly inside drvdata structure. bus_num is now just set if the pdev-id is present or with -1 for dynamic allocation by SPI core, but the driver does not access it anymore. Clean some bad comments format, and remove un-needed space. Signed-off-by: Benoit Cousson b-cous...@ti.com [Cleanup the OMAP2_MCSPI_MAX_CTRL macro as it is not needed anymore] Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/spi/spi-omap2-mcspi.c | 75 ++-- 1 files changed, 34 insertions(+), 41 deletions(-) diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c index bb9274c..7785091 100644 --- a/drivers/spi/spi-omap2-mcspi.c +++ b/drivers/spi/spi-omap2-mcspi.c @@ -45,9 +45,6 @@ snip tmp = OMAP2_MCSPI_WAKEUPENABLE_WKEN; mcspi_write_reg(master, OMAP2_MCSPI_WAKEUPENABLE, tmp); - omap2_mcspi_ctx[master-bus_num - 1].wakeupenable = tmp; + ctx-wakeupenable = tmp; Can't we get rid of tmp now? For example: ctx-wakeupenable = OMAP2_MCSPI_WAKEUPENABLE_WKEN; mcspi_write_reg(master, OMAP2_MCSPI_WAKEUPENABLE, ctx-wakeupenable); Yes the tmp variable could be optimized since it is in addition to the $SUBJECT will do it in a separate patch . Is that fine? -- Tarun -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend broken on 3.3?
Hi Joe, After digging a bit further I found that the problem isn't lost characters or character corruption at all... The UART is actually at 430KBaud (not 900KBaud as I mentioned earlier). How did you verify that register read? The data received is very bursty (i.e. sets of messages every second or so), containing a sync sequence to indicate a start of packet. The received bytes should be: 0x01, 0x52, 0x41 rest of packet. This works 100% of the time on 3.2, but on 3.3 I sometimes (but not always) get: 0x01, 0x00, 0x52, 0x41. i.e. there is a NULL/0x00 inserted after the first character. All this is tested using a very simple userspace application thats reads data from ttyO1. Any ideas? Should I kick open a new thread as it's not really to do with suspend anymore? Is there any flow control you are using? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
Hi Igor, On Wed, Mar 28, 2012 at 4:43 PM, Igor Grinberg grinb...@compulab.co.il wrote: Hi Shubhrajyoti, On 03/28/12 12:03, Shubhrajyoti wrote: On Tuesday 27 March 2012 07:38 PM, Igor Grinberg wrote: When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Why so ? Whats the error otherwise ? Otherwise, we get a very confusing warnings: Yes I guessed so thanks for the patch. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] spi: omap2-mcspi: driver updates
Hi Grant, On Wed, Mar 28, 2012 at 3:28 AM, Grant Likely grant.lik...@secretlab.ca wrote: On Mon, 26 Mar 2012 19:14:35 +0530, Shubhrajyoti D shubhrajy...@ti.com wrote: The patch series does the following cleanups - Converts the spi to module_platform_driver - Use the devm functions so that the freeing need not be done in the driver. - Makes the driver use autosuspend - Folds Benoit's bus_num removal patch in the series Changes from the previous version - Makes the driver use autosuspend - Folds Benoit's bus_num removal patch in the series This is also available through git : git://gitorious.org/linus-tree/linus-tree.git branch : spi Hi Shubhrajyoti, I'll queue these ones up for v3.5 unless you make the argument that they are bug fixes that must go into v3.4. No thats fine if targeted for v3.5 . Thanks, g. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] i2c: fix missing handling of errata I2C_OMAP3_1P153
Hello, On Fri, Feb 17, 2012 at 5:49 PM, Tasslehoff Kjappfot tasskj...@gmail.com wrote: From 0195dcf606b0ad069d8b5bc56cb877ff65ebea22 Mon Sep 17 00:00:00 2001 From: Tasslehoff Kjappfot tasskj...@gmail.com Date: Mon, 6 Feb 2012 14:14:23 +0100 Subject: [PATCH] i2c: fix missing handling of errata I2C_OMAP3_1P153 i2c_probe set the dev-errata flag, but omap_i2c_init cleared the flag again. Move the errata handling to i2c_probe. Looks good to me. Reviewed-by: Shubhrajyoti D shubhrajy...@ti.com Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 801df60..d609ae2 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -468,11 +468,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* Take the I2C module out of reset: */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); - dev-errata = 0; - - if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) - dev-errata |= I2C_OMAP_ERRATA_I207; - /* Enable interrupts */ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | @@ -1058,6 +1053,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430) dev-errata |= I2C_OMAP3_1P153; -- 1.7.5.4 -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mtd: omap2: Release memory region in .remove function
On Fri, Feb 17, 2012 at 8:19 PM, Bernhard Walle wa...@corscience.de wrote: When the driver is compiled as module, it's not possible to unload and reload the driver again: omap2-nand: probe of omap2-nand.0 failed with error -16 Looks right to me Reviewed-by: Shubhrajyoti D shubhrajy...@ti.com This patch fixes the problem because it releases the memory region, so that it can be requested again. Signed-off-by: Bernhard Walle wa...@corscience.de --- drivers/mtd/nand/omap2.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c index b3a883e..7dfcf68 100644 --- a/drivers/mtd/nand/omap2.c +++ b/drivers/mtd/nand/omap2.c @@ -1132,6 +1132,7 @@ static int omap_nand_remove(struct platform_device *pdev) /* Release NAND device, its internal structures and partitions */ nand_release(info-mtd); iounmap(info-nand.IO_ADDR_R); + release_mem_region(info-phys_base, NAND_IO_SIZE); kfree(info-mtd); return 0; } -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] i2c: fix missing handling of errata I2C_OMAP3_1P153
Hi , On Tue, Feb 14, 2012 at 3:45 PM, Tasslehoff Kjappfot tasskj...@gmail.com wrote: Sorry about the bad mails. First time I use git send-email to follow up on a patch, and it seems I need to read up a bit more on it. Anyway. This patch is tested on our custom board based on Beagleboard rev C3. thanks for the testing . may be include it in the changelogs . Just a suggestion not an objection to the patch. From 7c1e2c14bccb16c20dc7d93088b12ac6e6e351a3 Mon Sep 17 00:00:00 2001 From: Tasslehoff Kjappfot tasskj...@gmail.com Date: Mon, 6 Feb 2012 14:14:23 +0100 Subject: [PATCH] i2c: fix missing handling of errata I2C_OMAP3_1P153 i2c_prope Nitpick : probe set the dev-errata flag, but omap_i2c_init cleared the flag again. Move the errata handling to i2c_probe. Signed-off-by: Tasslehoff Kjappfot tasskj...@gmail.com --- drivers/i2c/busses/i2c-omap.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 801df60..d609ae2 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -468,11 +468,6 @@ static int omap_i2c_init(struct omap_i2c_dev *dev) /* Take the I2C module out of reset: */ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN); - dev-errata = 0; - - if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) - dev-errata |= I2C_OMAP_ERRATA_I207; - /* Enable interrupts */ dev-iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY | OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK | @@ -1058,6 +1053,11 @@ omap_i2c_probe(struct platform_device *pdev) dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) 0xff; + dev-errata = 0; + + if (dev-flags OMAP_I2C_FLAG_APPLY_ERRATA_I207) + dev-errata |= I2C_OMAP_ERRATA_I207; + if (dev-rev = OMAP_I2C_REV_ON_3430) dev-errata |= I2C_OMAP3_1P153; -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap 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: OMAP: fix build breakage when CONFIG_OF is not set
On Wed, Feb 8, 2012 at 4:34 PM, Luciano Coelho coe...@ti.com wrote: On Wed, 2012-02-08 at 12:59 +0200, Felipe Balbi wrote: On Wed, Feb 08, 2012 at 12:56:52PM +0200, Luciano Coelho wrote: Since commit 6145197be6cc0583fa1a2f4ec1079d366137061e, building we generally like to see the commit subject here too. And adding the abbreviated commit instead of the full sha1, wouldn't hurt either ;-) Ok, different practices. :) However there was already a discurssion. Anyways thanks for the patch. http://permalink.gmane.org/gmane.linux.ports.arm.omap/69796 I'll send v2. I think there was already a fix for this. http://www.spinics.net/lists/linux-omap/msg63151.html Anyways thanks for the patch. i2c_omap.c breaks if CONFIG_OF is not set: drivers/i2c/busses/i2c-omap.c: In function 'omap_i2c_probe': drivers/i2c/busses/i2c-omap.c:1021: error: 'omap_i2c_of_match' undeclared (first use in this function) drivers/i2c/busses/i2c-omap.c:1021: error: (Each undeclared identifier is reported only once drivers/i2c/busses/i2c-omap.c:1021: error: for each function it appears in.) This is because the definition of omap_i2c_of_match is #ifdef'd on CONFIG_OF, but the usage of it is not. Since the places where omap_ic2_of_match are prepared to get NULL pointers if CONFIG_OF is not defined, we can simply define it to NULL. Cc: Benoit Cousson b-cous...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com after fixing the commit log, you can add: Reviewed-by: Felipe Balbi ba...@ti.com if you want. Thanks for your quick review! -- Cheers, Luca. -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/2] watchdog : omap_wdt : Implement WDIOC_GETBOOTSTATUS for omap3+
Hi Vaibhav, On Tue, Jan 24, 2012 at 10:32 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Mon, Jan 23, 2012 at 16:43:07, Datta, Shubhrajyoti wrote: This patch intends to implement the WDIOC_GETBOOTSTATUS ioctl for the omap3 and omap4. Instead of just returning the register content why not parse the RSTST register value and check if it's really a watchdog reset or not? That is what is done for 24xx and below cpus. So I thought of extending it. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/watchdog/omap_wdt.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c index 4b33e3f..5395a4c 100644 --- a/drivers/watchdog/omap_wdt.c +++ b/drivers/watchdog/omap_wdt.c @@ -229,7 +229,7 @@ static long omap_wdt_ioctl(struct file *file, unsigned int cmd, if (cpu_is_omap16xx()) return put_user(__raw_readw(ARM_SYSST), (int __user *)arg); - if (cpu_is_omap24xx()) + if (cpu_is_omap24xx() || cpu_is_omap34xx() || cpu_is_omap44xx()) return put_user(omap_prcm_get_reset_sources(), (int __user *)arg); return put_user(0, (int __user *)arg); -- 1.7.1 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/3]OMAP4: Keypad support
Hi, Any comments on this series. Thanking you, With Regards, Shubhro -Original Message- From: shubhrajy...@ti.com [mailto:shubhrajy...@ti.com] Sent: Monday, December 27, 2010 11:22 AM To: linux-omap@vger.kernel.org; linux-in...@vger.kernel.org Cc: Shubhrajyoti D Subject: [PATCH 0/3]OMAP4: Keypad support From: Shubhrajyoti D a0393...@india.ti.com Adding the keypad 4430sdp board support and PM runtime change. Tested on 4430sdp. Abraham Arce (1): OMAP4:keypad: PM runtime Benoit Cousson (1): OMAP4: hwmod data: Add keypad in the hwmod database Syed Rafiuddin (1): OMAP4: keypad: Add the board support. arch/arm/mach-omap2/board-4430sdp.c| 89 arch/arm/mach-omap2/devices.c | 41 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 70 ++ drivers/input/keyboard/omap4-keypad.c |8 +++ 4 files changed, 208 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
