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
On Wed, Jan 4, 2012 at 5:44 AM, Kevin Hilman wrote:
> Shubhrajyoti D writes:
>
>> Currently the runtime functions are compiled regardless
>> of CONFIG_PM_RUNTIME flag. This patch intends to fix the same by
>> using SET_RUNTIME_PM_OPS.
>>
>> Cc : Keshava Munegowda
>> Signed-off-by: Shubhrajyoti D
Hi Grant
On Tue, Apr 3, 2012 at 1:10 AM, Grant Likely wrote:
> On Sat, 31 Mar 2012 17:06:55 +0530, Shubhrajyoti D
> 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
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 re
Hi Felipe,
On Wed, Apr 11, 2012 at 5:02 PM, Felipe Balbi 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 re
Hi Felipe,
On Wed, Apr 11, 2012 at 5:05 PM, Felipe Balbi 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
>> ---
>> drivers/i2c/busses/i2c-omap.c | 11 ---
>> 1 files
Hi Kevin,
Thanks for your review,
On Tue, Apr 17, 2012 at 7:15 PM, Kevin Hilman wrote:
> Shubhrajyoti D 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.
>
>>
On Wed, Apr 18, 2012 at 8:43 PM, Shubhrajyoti 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
Date: Wed, 4 Apr 2012 16:32:37 +05
On Fri, Apr 20, 2012 at 8:37 PM, Tero Kristo wrote:
> On Fri, 2012-04-20 at 20:21 +0530, Datta, Shubhrajyoti wrote:
>> On Fri, Apr 20, 2012 at 8:13 PM, Tero Kristo wrote:
>> > On Fri, 2012-04-20 at 06:55 -0700, Kevin Hilman wrote:
>> >> Tero Kristo writes:
>> >>
>> >> [...]
>> >>
>> >> >> I trie
Hi Edurardo,
A few doubts,
On Fri, May 25, 2012 at 1:55 PM, Eduardo Valentin
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 mail
On Fri, Jun 1, 2012 at 4:29 AM, Kevin Hilman wrote:
> Shubhrajyoti D 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 Tassleh
Hi Vaibhav,
On Tue, Jan 24, 2012 at 10:32 AM, Bedia, Vaibhav 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
On Wed, Feb 8, 2012 at 4:34 PM, Luciano Coelho 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 h
Hi ,
On Tue, Feb 14, 2012 at 3:45 PM, Tasslehoff Kjappfot
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 fo
Hello,
On Fri, Feb 17, 2012 at 5:49 PM, Tasslehoff Kjappfot
wrote:
> From 0195dcf606b0ad069d8b5bc56cb877ff65ebea22 Mon Sep 17 00:00:00 2001
>
> From: Tasslehoff Kjappfot
> Date: Mon, 6 Feb 2012 14:14:23 +0100
> Subject: [PATCH] i2c: fix missing handling of errata I2C_OMAP3_1P153
>
> i2c_probe s
On Fri, Feb 17, 2012 at 8:19 PM, Bernhard Walle 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
> This patch fixes the problem
Hi Grant,
On Wed, Mar 28, 2012 at 3:28 AM, Grant Likely wrote:
> On Mon, 26 Mar 2012 19:14:35 +0530, Shubhrajyoti D
> 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 t
Hi Igor,
On Wed, Mar 28, 2012 at 4:43 PM, Igor Grinberg 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_s
Hi Tarun,
On Wed, Mar 28, 2012 at 2:15 PM, DebBarma, Tarun Kanti
wrote:
> On Mon, Mar 26, 2012 at 7:14 PM, Shubhrajyoti D wrote:
>> From: Benoit Cousson
>>
>> bus_num was used to reference the mcspi controller instance in a fixed array.
>> Remove this array and store this information directly i
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 eve
On Mon, Jun 18, 2012 at 9:00 PM, Wolfram Sang wrote:
> On Mon, Jun 18, 2012 at 08:00:28PM +0530, Shubhrajyoti D wrote:
>> From: Felipe Balbi
>>
>> 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 u
On Wed, Jun 20, 2012 at 7:44 PM, Tony Lindgren wrote:
> * Shubhrajyoti [120620 06:06]:
>> On Wednesday 20 June 2012 04:02 PM, Tony Lindgren wrote:
>> > * Shubhrajyoti D [120618 07:35]:
>> >> From: Jon Hunter
>> >>
>> >> The OMAP3530 is based upon the same silicon as the OMAP3430 and so the I2C
On Mon, Jun 25, 2012 at 3:21 PM, Felipe Balbi 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
Hi Kevin,
Thanks for the patch ,
a doubt below
On Wed, Jun 27, 2012 at 7:15 AM, Kevin Hilman 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
On Wed, Jun 27, 2012 at 7:13 AM, Kevin Hilman wrote:
> Shubhrajyoti D 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 f
On Mon, Jul 2, 2012 at 5:26 PM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jun 29, 2012 at 03:43:26PM +0530, Shubhrajyoti D wrote:
>> From: Felipe Balbi
>>
>> 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-facto
On Thu, Jun 28, 2012 at 8:41 PM, Shubhrajyoti D 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 inste
On Wed, Jul 18, 2012 at 4:43 PM, Laurent Pinchart
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: Lau
On Mon, Jul 30, 2012 at 1:10 PM, Shilimkar, Santosh
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 i
On Mon, Aug 20, 2012 at 12:25 PM, Shilimkar, Santosh
wrote:
> On Mon, Aug 20, 2012 at 12:08 PM, S, Venkatraman wrote:
>>
>> On Fri, Aug 17, 2012 at 11:43 PM, Puttagunta, Viswanath
>> wrote:
[...]
>> >>> Signed-off-by: Semen Protsenko
>> >>
>> >> The implementation looks fine, but can we simply
Hi Venkat,
Some doubts below.
On Sat, Aug 18, 2012 at 12:22 AM, Venkatraman S 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
On Wed, Aug 22, 2012 at 10:29 PM, Mark Brown
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 th
On Tue, Oct 23, 2012 at 11:27 PM, Felipe Balbi 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)
>> >> {
>> >&
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi 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 tra
On Thu, Oct 25, 2012 at 2:30 PM, Felipe Balbi 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
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi 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 in
On Mon, Oct 22, 2012 at 3:16 PM, Felipe Balbi wrote:
> just a cleanup patch trying to make exit path
> more straightforward. No changes otherwise.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/i2c/busses/i2c-omap.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletion
On Wed, Oct 31, 2012 at 2:29 PM, 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 r
On Fri, Nov 2, 2012 at 4:37 PM, Felipe Balbi 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
>
> very good. I haven't read the err
On Fri, Nov 2, 2012 at 4:36 PM, Felipe Balbi 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 r
On Mon, Nov 5, 2012 at 2:34 PM, Felipe Balbi 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 < O
On 11/5/12, Cousson, Benoit 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);
>> -
On Tue, Nov 6, 2012 at 2:33 PM, Mark Brown
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.
>
>
On Tue, Nov 6, 2012 at 5:31 AM, Kevin Hilman
wrote:
> Jean Pihet 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 pow
On Tue, Nov 6, 2012 at 2:52 PM, Mark Brown
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.
>
>
On Tue, Nov 6, 2012 at 10:01 PM, Paul Walmsley wrote:
>
> This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc.
> This commit causes I2C timeouts to appear on several OMAP3430/3530-based
> boards:
>
> http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2
> http://marc.info/?l=linu
On Mon, Nov 5, 2012 at 5:53 PM, Shubhrajyoti D 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
On Thu, Nov 15, 2012 at 1:46 PM, Jean Pihet wrote:
> Hi Shubhrajyoti,
>
> On Thu, Nov 15, 2012 at 8:34 AM, Shubhrajyoti D 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 complet
On Thu, Nov 15, 2012 at 12:20 AM, Wolfram Sang 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
On Fri, Nov 16, 2012 at 7:50 PM, Wolfram Sang 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
>> co
On Mon, Nov 26, 2012 at 2:44 PM, Felipe Balbi 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 l
On Mon, Nov 26, 2012 at 5:22 PM, Felipe Balbi 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 ne
On Mon, Nov 26, 2012 at 11:31 PM, Dmitry Torokhov
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 obje
On Mon, Dec 10, 2012 at 8:49 PM, Jack Mitchell 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 i
On Wed, Sep 12, 2012 at 7:14 PM, Wolfram Sang 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 det
Hi Kevin,
On Fri, Sep 14, 2012 at 2:15 AM, Kevin Hilman
wrote:
> From: Kevin Hilman
>
> 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
>
On Fri, Sep 14, 2012 at 7:37 PM, Kevin Hilman
wrote:
> Shubhrajyoti Datta writes:
>
>> Hi Kevin,
>>
>> On Fri, Sep 14, 2012 at 2:15 AM, Kevin Hilman
>> wrote:
>>> From: Kevin Hilman
>>>
>>> On some platforms, bootloaders are known to do
On Thu, Sep 20, 2012 at 12:04 PM, Pantelis Antoniou
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
> ---
looks good
Acked-by: Shubhrajyoti D
--
To unsubscribe from thi
On Thu, Sep 20, 2012 at 9:38 PM, Jean Pihet 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
On Fri, Sep 21, 2012 at 5:05 PM, Felipe Balbi 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.
>
>
On Fri, Sep 21, 2012 at 7:48 PM, Kevin Hilman
wrote:
> Shubhrajyoti D writes:
>
[...]
>>
>> Signed-off-by: Shubhrajyoti D
>> ---
>> - functional testing on omap4sdp
>> - Verified idle and suspend path hits off on beagle.
>
> Tested-by: Kevin Hilman
>
> This fixes the console hang I was seeing o
On Wed, Oct 10, 2012 at 5:48 PM, Kalle Jokiniemi
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
On Fri, Oct 12, 2012 at 10:13 PM, Kevin Hilman
wrote:
> "Strashko, Grygorii" 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
>> (om
. 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 driv
On Mon, Oct 15, 2012 at 2:46 PM, Kalle Jokiniemi
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
On Mon, Oct 15, 2012 at 7:21 AM, Paul Walmsley 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
On Tue, Oct 16, 2012 at 8:53 PM, Sebastien Guiriec 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
On Mon, Oct 22, 2012 at 3:52 PM, Sebastien Guiriec wrote:
> Add base address and interrupt line inside Device Tree data for
> OMAP5
Looks good to me.
Thanks ,
Reviewed-by: Shubhrajyoti D
>
> Signed-off-by: Sebastien Guiriec
> ---
> arch/arm/boot/dts/omap5.dtsi | 14 --
> 1 file c
On Mon, Oct 22, 2012 at 7:00 PM, Felipe Balbi 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 un
On Tue, Oct 23, 2012 at 3:16 AM, Kevin Hilman
wrote:
> Tero Kristo 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 fixe
On Tue, Oct 23, 2012 at 9:39 PM, Kevin Hilman
wrote:
> Shubhrajyoti Datta 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 mo
On Tue, Oct 23, 2012 at 10:48 PM, Felipe Balbi 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 tra
On Tue, Oct 23, 2012 at 11:27 PM, Felipe Balbi 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)
>> >> {
>> >&
73 matches
Mail list logo
