Hi Tony,
On Monday 22 October 2012 09:49 PM, Tony Lindgren wrote:
* Sourav Poddar [121022 00:30]:
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -194,6 +194,27 @@
0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT
| MODE0 */
On Tue, 23 Oct 2012, Paul Walmsley wrote:
> As Kevin mentioned earlier, this is unfortunately not true for those of us
> with earlier BeagleBoards:
er, BeagleBones, rather...
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@v
On Mon, 22 Oct 2012, Matt Porter wrote:
> I've mentioned this a few times in various threads...no need to use
> appended DTB on a current U-Boot. Some of us are indeed booting this way
> with the DTB properly passed separately from the bootloader and chosen
> filled out by the bootloader. And yes,
On Mon, Oct 22, 2012 at 01:48:37PM -0500, Jon Hunter wrote:
>
> On 10/22/2012 01:35 PM, Paul Walmsley wrote:
> > (including the lists in my reply this time, oops; also adding some more
> > detail)
> >
> > On Mon, 22 Oct 2012, Jon Hunter wrote:
> >
> >> On 10/20/2012 04:26 PM, Paul Walmsley wrot
+Igor
Paul Walmsley writes:
> Here are some basic OMAP test results for Linux v3.7-rc2.
> Logs and other details at:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
[...]
> * 37xx EVM: CORE not entering dynamic off-idle
> - Cause unknown; dynamic retention-idle seems
Hi Tomi,
Thanks for reviewing!
On 10/22/2012 02:40 AM, Tomi Valkeinen wrote:
On 2012-10-16 04:27, Ricardo Neri wrote:
Creating the accessory devices, such as audio, from the HDMI driver
allows to regard HDMI as a single entity with audio an display
functionality. This intends to follow the des
Kevin Hilman writes:
> From: Kevin Hilman
>
> After commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 (ARM: OMAP2+:
> PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
> using an existing CPU device, not the omap_device for MPU-SS.
>
> First, fix the board file to use get_cpu_d
Hi Tomi,
On 10/22/2012 02:22 AM, Tomi Valkeinen wrote:
On 2012-10-16 04:27, Ricardo Neri wrote:
Using devm_ioremap provides better memory handling and improves
readability.
Signed-off-by: Ricardo Neri
---
drivers/video/omap2/dss/hdmi.c | 11 +++
1 files changed, 7 insertions(+),
From: Kevin Hilman
After commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 (ARM: OMAP2+:
PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
using an existing CPU device, not the omap_device for MPU-SS.
First, fix the board file to use get_cpu_device() as required by the
above co
On Mon, Oct 22, 2012 at 7:05 PM, Kevin Hilman
wrote:
> However, in light of RT throttling, this a correctness issue for process
> accounting, so I agree that this should be done for all platforms
> instead of providing an optional 'needs suspend' version of the API,
> even though it means printk
Matt Porter writes:
> On Sat, Oct 20, 2012 at 06:58:10PM +, Paul Walmsley wrote:
>> On Sat, 20 Oct 2012, Richard Cochran wrote:
>>
>> > On Sat, Oct 20, 2012 at 06:12:35PM +, Paul Walmsley wrote:
>> > > Just tried omap2plus_defconfig here and the board didn't boot,
>> > > confirming
>>
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 fixes for example the bug introduced by commit
> 6c31b2150ff96755d
* Kevin Hilman [121022 13:35]:
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -444,12 +445,13 @@ static struct omap_board_mux board_mux[] __in
Quoting Strashko, Grygorii (2012-10-19 03:34:19)
> Hi Mike,
>
> > In addition to removing CK_443X/CK_446X you could also get rid of struct
> > omap_clk completely (arch/arm/plat-omap/include/plat/clkdev_omap.h) and
> > the CLK macro by changing the clk array to be of type struct clk_lookup
> > and
On Sun, Oct 21, 2012 at 02:52:13PM +0300, Kasatkin, Dmitry wrote:
> Hello,
>
> I got only 3 patches out of 7.
> Can you please re-submit them also to linux-cry...@vger.kernel.org
> That is a list where crypto drivers are discussed.
Okay, I will CC you and the linux-crypto on the entire series whe
Kevin Hilman writes:
> Paul Walmsley writes:
>
>> Hi Kevin
>>
>> On Fri, 19 Oct 2012, Paul Walmsley wrote:
>>
>>> On Thu, 18 Oct 2012, Paul Walmsley wrote:
>>>
>>> > Here are some basic OMAP test results for Linux v3.7-rc1.
>>> > Logs and other details at
>>> > http://www.pwsan.com/omap/testlo
Kevin Hilman writes:
> Aaro Koskinen writes:
>
>> Hi,
>>
>> On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote:
>>> On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote:
>>> > FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c
>>> > omap_i2c.1: timeout waiting for
* Péter Ujfalusi [121022 04:42]:
> Hi Tony,
>
> On 10/18/2012 12:00 PM, Benoit Cousson wrote:
> > On 10/18/2012 11:25 AM, Peter Ujfalusi wrote:
> >> Fixes the following errors:
> >> [2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
> >> [2.324432] omap-mcbsp 49024000.mcbsp: inv
On n900 uart1 pins are not not used for uart, instead they are
used to connect to a cell modem over ssi. Looks like we're
currently missing these signal names for 3430 for some reason,
and only have some of them listed for 3630. Obviously the signals
are there for 3430 if n900 is using them and the
Commit 8f31cefe (ARM: OMAP2+: select PINCTRL in Kconfig)
added select PINCTRL, but accdentally added it to a wrong
location.
We want to select if for ARCH_OMAP2PLUS, not for
ARCH_OMAP2PLUS_TYPICAL.
Signed-off-by: Tony Lindgren
---
0 files changed
diff --git a/arch/arm/mach-omap2/Kconfig b/arch
Hi all,
I noticed these two issues while testing some pinctrl
related changes.
Regards,
Tony
---
Tony Lindgren (2):
ARM: OMAP2+: Fix location of select PINCTRL
ARM: OMAP3: Fix 3430 legacy mux names for ssi1 signals.
0 files changed
--
Signature
--
To unsubscribe from this list
From: Kevin Hilman
After commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 (ARM: OMAP2+:
PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
using an existing CPU device, not the omap_device for MPU-SS.
First, fix the board file to use get_cpu_device() as required by the
above co
On Mon, Oct 22, 2012 at 07:53:06PM +, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Mark A. Greer wrote:
>
> > On Sat, Oct 20, 2012 at 07:40:44PM +, Paul Walmsley wrote:
> > > On Fri, 19 Oct 2012, Mark A. Greer wrote:
> > >
> > > > From: "Mark A. Greer"
> > > >
> > > > Add the DMA informa
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how t
On DT driven boards, the gpmc node will match the driver. Hence, there's
no need to do that unconditionally from the initcall.
Signed-off-by: Daniel Mack
---
arch/arm/mach-omap2/gpmc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpm
Signed-off-by: Daniel Mack
---
arch/arm/mach-omap2/gpmc-nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 8607735..c3616c6 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-n
This is a series of patches to support GPMC peripherals on OMAP boards.
Depends on Linus' master +
omap-next (branch omap-for-v3.8/cleanup-headers-gpmc)
The only supported peripheral for now is NAND, but other types would be
easy to add.
In order to make the gpmc driver the 'hub' for all sub-nod
Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.
For non-DT boards, this change has no effect.
Signed-off-by: Dan
On Mon, 22 Oct 2012, Mark A. Greer wrote:
> On Sat, Oct 20, 2012 at 07:40:44PM +, Paul Walmsley wrote:
> > On Fri, 19 Oct 2012, Mark A. Greer wrote:
> >
> > > From: "Mark A. Greer"
> > >
> > > Add the DMA information for the OMAP2 SHA module.
> > >
> > > CC: Paul Walmsley
> > > Signed-off
On 19.10.2012 17:34, Afzal Mohammed wrote:
> Hi Daniel,
>
> On Thursday 11 October 2012 05:15 PM, Daniel Mack wrote:
>
>> Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I
>> would like to augment this to make GPMC attached NAND probable in DT, in
>> case this is still an ope
On Mon, 22 Oct 2012, Mark A. Greer wrote:
> On Sat, Oct 20, 2012 at 07:40:19PM +, Paul Walmsley wrote:
>
> > > static void omap_init_sham(void)
> > > {
> > > - if (cpu_is_omap24xx()) {
> > > - sham_device.resource = omap2_sham_resources;
> > > - sham_device.num_resources = om
On Sun, Oct 21, 2012 at 11:58:36AM +0530, Santosh Shilimkar wrote:
> Mark,
Hi Santosh.
> On Saturday 20 October 2012 03:23 AM, Mark A. Greer wrote:
> >From: "Mark A. Greer"
> >
> >This series updates the crypto omap-sham driver and supporting
> >infrastructure.
> >
> >Notes:
> >
> >a) Based on c
On Sat, Oct 20, 2012 at 07:34:51PM +, Paul Walmsley wrote:
> On Fri, 19 Oct 2012, Mark A. Greer wrote:
>
> > From: "Mark A. Greer"
> >
> > This series updates the crypto omap-sham driver and supporting
> > infrastructure.
>
> Looks pretty good; this will make it easier for us to migrate the
On Sat, Oct 20, 2012 at 07:40:44PM +, Paul Walmsley wrote:
> On Fri, 19 Oct 2012, Mark A. Greer wrote:
>
> > From: "Mark A. Greer"
> >
> > Add the DMA information for the OMAP2 SHA module.
> >
> > CC: Paul Walmsley
> > Signed-off-by: Mark A. Greer
>
> This can probably be combined with t
On Sat, Oct 20, 2012 at 07:40:19PM +, Paul Walmsley wrote:
> Hi
Hi Paul.
> a few comments:
>
> On Fri, 19 Oct 2012, Mark A. Greer wrote:
>
> > From: "Mark A. Greer"
> >
> > Convert the device data for the OMAP2 SHAM crypto IP from
> > explicit platform_data to hwmod. When bit 1 (OMAP24XX
On 10/22/2012 01:36 PM, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Paul Walmsley wrote:
>
>> On Mon, 22 Oct 2012, Jon Hunter wrote:
>>
>>> and toolchain used for any failures.
>>
>> This would indeed be useful and will try to figure out a good way to add
>> that information.
>
> Just realized
On 10/22/2012 01:35 PM, Paul Walmsley wrote:
> (including the lists in my reply this time, oops; also adding some more
> detail)
>
> On Mon, 22 Oct 2012, Jon Hunter wrote:
>
>> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
>>
>>> Failing tests: fixed by posted patches
>>> ---
On Mon, 22 Oct 2012, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Jon Hunter wrote:
>
> > and toolchain used for any failures.
>
> This would indeed be useful and will try to figure out a good way to add
> that information.
Just realized that some of this appears in the beginning of the bootlog
(including the lists in my reply this time, oops; also adding some more
detail)
On Mon, 22 Oct 2012, Jon Hunter wrote:
> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
>
> > Failing tests: fixed by posted patches
> > --
> >
> > Boot tests:
> >
> > * AM335x Bea
Paul Walmsley writes:
> Hi Kevin
>
> On Fri, 19 Oct 2012, Paul Walmsley wrote:
>
>> On Thu, 18 Oct 2012, Paul Walmsley wrote:
>>
>> > Here are some basic OMAP test results for Linux v3.7-rc1.
>> > Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
>
> ...
>
>> > Failing
On 10/22/2012 07:06 PM, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Benoit Cousson wrote:
>
>> What is CGRM? Is it a typo?
>
> That's the OMAP1 Clock Generation and Reset Module that contains the
> ARM_SYSST register:
Outch, that's pretty old stuff. Thanks for the clarification.
Regards,
Benoi
On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet wrote:
> Hi,
>
> On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley wrote:
>> Hi Jean
>>
>> On Fri, 19 Oct 2012, Paul Walmsley wrote:
>>
>>> On Thu, 18 Oct 2012, Paul Walmsley wrote:
>>>
>>> > Here are some basic OMAP test results for Linux v3.7-rc1.
>>> >
Aaro Koskinen writes:
> Hi,
>
> On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote:
>> On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote:
>> > FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c
>> > omap_i2c.1: timeout waiting for bus ready). After several reboo
On Mon, 22 Oct 2012, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Jon Hunter wrote:
>
> > I am not seeing this on my omap4430 panda. I have an OMAP4430 ES2.3 and
> > I am using u-boot release 2012.10. What do you have?
>
> It's documented in the bootlog:
>
> http://www.pwsan.com/omap/testlogs/te
Hi Jon
On Mon, 22 Oct 2012, Jon Hunter wrote:
> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
>
> ...
>
> > Other:
> >
> > * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
> > - Unknown cause; could be due to the lack of hierarchical enable/disable
> > in hwmod code
>
On Mon, 22 Oct 2012, Benoit Cousson wrote:
> What is CGRM? Is it a typo?
That's the OMAP1 Clock Generation and Reset Module that contains the
ARM_SYSST register:
http://www.ti.com/lit/ug/spru678a/spru678a.pdf
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
th
+Colin Cross, Barry Song also
Felipe Balbi writes:
> The scheduler imposes a requirement to sched_clock()
> which is to stop the clock during suspend, if we don't
> do that IRQ threads will be rescheduled in the future
> which might cause transfers to timeout depending on
> how driver is written
Peter Zijlstra writes:
> On Fri, 2012-10-19 at 16:54 -0700, Kevin Hilman wrote:
>
>> So I did the same thing for my ARM SoC, and it definitley stops the RT
>> throttling.
>>
>> However, it has the undesriable (IMO) side effect of making timed printk
>> output rather unhelpful for debugging sus
* Jon Hunter [121022 09:30]:
> On 10/20/2012 04:26 PM, Paul Walmsley wrote:
> >
> > * 2430sdp: vfp_reload_hw oops during MMC initialization
> > - Kernel attempts to save FP registers that don't exist; fix posted:
> > - http://www.spinics.net/lists/arm-kernel/msg200646.html
Has that one bee
Hi Paul,
On 10/20/2012 04:26 PM, Paul Walmsley wrote:
>
> Here are some basic OMAP test results for Linux v3.7-rc2.
> Logs and other details at:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/
>
>
> Passing tests
> -
>
> Boot to userspace: 3517evm, 3530es3
* Sourav Poddar [121022 00:30]:
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -194,6 +194,27 @@
> 0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT
> | MODE0 */
> >;
> };
> +
> + keypad_pins: pinmux_keypad_p
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: om
On Sat, 2012-10-20 at 17:20 +, Paul Walmsley wrote:
> Hello Venkatraman,
>
> On Thu, 18 Oct 2012, Paul Walmsley wrote:
>
> > Here are some basic OMAP test results for Linux v3.7-rc1.
> > Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
>
> ...
>
> > Failing tests:
Hi,
On Sat, Oct 20, 2012 at 8:14 AM, Paul Walmsley wrote:
> Hi Jean
>
> On Fri, 19 Oct 2012, Paul Walmsley wrote:
>
>> On Thu, 18 Oct 2012, Paul Walmsley wrote:
>>
>> > Here are some basic OMAP test results for Linux v3.7-rc1.
>> > Logs and other details at http://www.pwsan.com/omap/testlogs/test
Hi Paul,
On 10/20/2012 04:26 PM, Paul Walmsley wrote:
...
> Other:
>
> * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
> - Unknown cause; could be due to the lack of hierarchical enable/disable
> in hwmod code
I am not seeing this on my omap4430 panda. I have an O
Hi Sourav,
On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> Adapt keypad to use pinctrl framework.
>
> Tested on omap4430 sdp with 3.7-rc1 kernel.
I do not see anything in the driver that would directly use pinctrl. Is
there a better place to select default pin configuration; may
Hi Benoit,
On 10/22/2012 04:11 PM, Benoit Cousson wrote:
Hi Seb,
Good work. Thanks for that series.
Just update it with all the acked-by you've got from the TI driver folks
+ the minor comment and I'll pull it in the for_3.8/dts branch.
That's a detail but you should update the subject with "
On Monday 22 October 2012 07:36 PM, Felipe Balbi wrote:
> can you also check if echo mem > /sys/power/state works ? Don't forget
> to enable UART wakeups with:
>
> echo enabled > /sys/devices/platform/omap_uart.2/power/wakeup
> echo enabled > /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup
Hi,
On Mon, Oct 22, 2012 at 07:36:31PM +0530, Shubhrajyoti Datta wrote:
> 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
Hi Seb,
Good work. Thanks for that series.
Just update it with all the acked-by you've got from the TI driver folks
+ the minor comment and I'll pull it in the for_3.8/dts branch.
That's a detail but you should update the subject with "ARM: dts: OMAP5:
XXX" prefix for consistency with the latest
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
Hi Sebestien,
On Monday 22 October 2012 06:26 PM, Sourav wrote:
On Monday 22 October 2012 06:20 PM, Benoit Cousson wrote:
On 10/22/2012 02:27 PM, Sourav wrote:
Hi Benoit,
On Monday 22 October 2012 05:37 PM, Benoit Cousson wrote:
On 10/22/2012 01:57 PM, Benoit Cousson wrote:
Hi Sourav,
On 10
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 turn
On Mon, Oct 22, 2012 at 03:59:28PM +0300, Felipe Balbi wrote:
> prepare() is supposed to prevent new children from
> being registered. On the MMC subsystem, children
> (new cards) registration starts with the card
> detect IRQ.
>
> Move card detect IRQ disabling to prepare() so that
> no new cards
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
will only contain the bits which were enabled on
IRQENABLE_SET and that will break when we need to
poll for a certain bit which wasn't enabled as an
IRQ source.
One such case is after we finish
Hi,
On Mon, Oct 22, 2012 at 03:05:20PM +0200, Benoit Cousson wrote:
> On 10/22/2012 02:28 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Oct 22, 2012 at 02:27:20PM +0200, Benoit Cousson wrote:
> >> Hi Felipe,
> >>
> >> On 10/22/2012 11:46 AM, Felipe Balbi wrote:
> >>> on OMAP4+ we want to read I
Currently, omap4 keypad mux settings are done in the board file.
Populate the mux settings in the dts file for the keypad to
work via dt.
Tested on omap4430 sdp with 3.7-rc1.
Cc: Felipe Balbi
Signed-off-by: Sourav Poddar
---
v1->v2
change the hex letter to lower case.
arch/arm/boot/dts/omap4-s
Adapt keypad to use pinctrl framework.
Tested on omap4430 sdp with 3.7-rc1 kernel.
Cc: Felipe Balbi
Cc: Dmitry Torokhov
Signed-off-by: Sourav Poddar
---
v1->v2
- Added "PROBE_DEFER" check
drivers/input/keyboard/omap4-keypad.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions
On 10/22/2012 02:28 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Oct 22, 2012 at 02:27:20PM +0200, Benoit Cousson wrote:
>> Hi Felipe,
>>
>> On 10/22/2012 11:46 AM, Felipe Balbi wrote:
>>> on OMAP4+ we want to read IRQSTATUS_RAW register,
>>> instead of IRQSTATUS. The reason being that IRQSTATUS
>>>
prepare() is supposed to prevent new children from
being registered. On the MMC subsystem, children
(new cards) registration starts with the card
detect IRQ.
Move card detect IRQ disabling to prepare() so that
no new cards will be registered while we're trying
to suspend.
Likewise, move card dete
On Monday 22 October 2012 06:20 PM, Benoit Cousson wrote:
On 10/22/2012 02:27 PM, Sourav wrote:
Hi Benoit,
On Monday 22 October 2012 05:37 PM, Benoit Cousson wrote:
On 10/22/2012 01:57 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/22/2012 01:16 PM, Sourav wrote:
Hi Sebastien,
On Monday 22 Octob
On 10/22/2012 02:27 PM, Sourav wrote:
> Hi Benoit,
> On Monday 22 October 2012 05:37 PM, Benoit Cousson wrote:
>> On 10/22/2012 01:57 PM, Benoit Cousson wrote:
>>> Hi Sourav,
>>>
>>> On 10/22/2012 01:16 PM, Sourav wrote:
Hi Sebastien,
On Monday 22 October 2012 03:52 PM, Sebastien Guiriec
On Mon, Oct 22, 2012 at 05:57:00PM +0530, Sourav wrote:
> Hi Benoit,
> On Monday 22 October 2012 05:37 PM, Benoit Cousson wrote:
> >On 10/22/2012 01:57 PM, Benoit Cousson wrote:
> >>Hi Sourav,
> >>
> >>On 10/22/2012 01:16 PM, Sourav wrote:
> >>>Hi Sebastien,
> >>>On Monday 22 October 2012 03:52 PM,
Hi,
On Mon, Oct 22, 2012 at 02:27:20PM +0200, Benoit Cousson wrote:
> Hi Felipe,
>
> On 10/22/2012 11:46 AM, Felipe Balbi wrote:
> > on OMAP4+ we want to read IRQSTATUS_RAW register,
> > instead of IRQSTATUS. The reason being that IRQSTATUS
> > will only contain the bits which were enabled on
> >
Hi Felipe,
On 10/22/2012 11:46 AM, Felipe Balbi wrote:
> on OMAP4+ we want to read IRQSTATUS_RAW register,
> instead of IRQSTATUS. The reason being that IRQSTATUS
> will only contain the bits which were enabled on
> IRQENABLE_SET and that will break when we need to
> poll for a certain bit which w
Hi Benoit,
On Monday 22 October 2012 05:37 PM, Benoit Cousson wrote:
On 10/22/2012 01:57 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/22/2012 01:16 PM, Sourav wrote:
Hi Sebastien,
On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree
Hi,
On Mon, Oct 22, 2012 at 02:54:37PM +0300, Felipe Balbi wrote:
> The scheduler imposes a requirement to sched_clock()
> which is to stop the clock during suspend, if we don't
> do that IRQ threads will be rescheduled in the future
> which might cause transfers to timeout depending on
> how driv
Hi Paul,
What is CGRM? Is it a typo?
Regards,
Benoit
On 10/16/2012 03:32 AM, Paul Walmsley wrote:
> This series removes the omap_prcm_get_reset_sources() function. This
> was exported from arch/arm/mach-omap2/prcm.c for use by the OMAP
> watchdog driver to report the "boot reason". This seri
Hi,
On Saturday 20 October 2012 03:54 AM, Kevin Hilman wrote:
From: Kevin Hilman
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a "no idle" option
during
On 10/22/2012 01:57 PM, Benoit Cousson wrote:
> Hi Sourav,
>
> On 10/22/2012 01:16 PM, Sourav wrote:
>> Hi Sebastien,
>> On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
>>> Add base address and interrupt line inside Device Tree data for
>> Incomplete sentence!
>>> Signed-off-by: Sebas
The scheduler imposes a requirement to sched_clock()
which is to stop the clock during suspend, if we don't
do that IRQ threads will be rescheduled in the future
which might cause transfers to timeout depending on
how driver is written.
This became an issue on OMAP when we converted omap-i2c.c
to
Hi Sourav,
On 10/22/2012 01:16 PM, Sourav wrote:
> Hi Sebastien,
> On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
>> Add base address and interrupt line inside Device Tree data for
> Incomplete sentence!
>> Signed-off-by: Sebastien Guiriec
>> ---
>> arch/arm/boot/dts/omap5.dtsi |
Hi Tony,
On 10/18/2012 12:00 PM, Benoit Cousson wrote:
> On 10/18/2012 11:25 AM, Peter Ujfalusi wrote:
>> Fixes the following errors:
>> [2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
>> [2.324432] omap-mcbsp 49024000.mcbsp: invalid rx DMA channel
>>
>> Which is because we fa
Hi Sebastien,
On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
Add base address and interrupt line inside Device Tree data for
Incomplete sentence!
Signed-off-by: Sebastien Guiriec
---
arch/arm/boot/dts/omap5.dtsi | 16 ++--
1 file changed, 14 insertions(+), 2 dele
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
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec
---
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.
Add base address and interrupt line inside Device Tree data for
OMAP5.
Signed-off-by: Sebastien Guiriec
---
arch/arm/boot/dts/omap5.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 413df94..b643cd3 100644
---
Add base address and interrupt line inside Device Tree data for
Signed-off-by: Sebastien Guiriec
---
arch/arm/boot/dts/omap5.dtsi | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 6c22e1b..413
Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the
address space
and interrupt line description inside dtsi file for OMAP5. This serie is
updating the
current OMAP5 IP with missing entry.
It has been tested on OMAP5 with 3.7-audio-display feature tree.
- MMC is probing
Add base address and interrupt line inside Device Tree data for
OMAP5
Signed-off-by: Sebastien Guiriec
---
arch/arm/boot/dts/omap5.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 42c78be..9e39f9f 10064
I found it works only with
fdt addr 0x9000
and precompiled linaro u-boot
On Mon, Oct 22, 2012 at 7:29 AM, kishon wrote:
> Hi,
>
>
> On Monday 22 October 2012 03:58 AM, Constantine Shulyupin wrote:
>>
>> Hi,
>>
>> Tell me please, which u-boot and u-boot configuration to use to boot
>> latest k
It's impossible to have Arbitration Lost,
Read Overflow, and Tranmist Underflow all
asserted at the same time.
Those error conditions are mutually exclusive
so what the code should be doing, instead, is
check each error flag separataly.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-oma
On Fri, 2012-10-19 at 16:54 -0700, Kevin Hilman wrote:
> So I did the same thing for my ARM SoC, and it definitley stops the RT
> throttling.
>
> However, it has the undesriable (IMO) side effect of making timed printk
> output rather unhelpful for debugging suspend/resume since printk time
> s
From: Shubhrajyoti D
In case of a NACK, it's wise to tell our clients
drivers about how many bytes were actually transferred.
Support this by adding an extra field to the struct
i2c_msg which gets incremented the amount of bytes
actually transferred.
Signed-off-by: Shubhrajyoti D
Signed-off-by
Later patches will come adding support for
reporting amount of bytes transferred so that
client drivers can count how many bytes are
left to transfer.
This is useful mostly in case of NACKs when
client driver wants to know exactly which
byte got NACKed so it doesn't have to resend
all bytes again.
this is important in cases where client driver
wants to know how many bytes were actually
transferred.
There is one trick here: if transfer is completed,
meaning I2C_CNT reaches zero, then ARDY will be
asserted to let SW know that it can program a
new transfer.
When ARDY is asserted, I2C_CNT is r
on OMAP4+ we want to read IRQSTATUS_RAW register,
instead of IRQSTATUS. The reason being that IRQSTATUS
will only contain the bits which were enabled on
IRQENABLE_SET and that will break when we need to
poll for a certain bit which wasn't enabled as an
IRQ source.
One such case is after we finish
PM callbacks pass our device pointer as argument
and we don't need to access the platform_device
just to dereference that down to dev->drvdata.
instead, just use dev_get_drvdata() directly.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 6 ++
1 file changed, 2 insertions(+)
In case we loop on IRQ handler until stat is
finally zero, we would end up in a situation
where all I2C transfers would misteriously
timeout because we were not calling complete()
in that situation.
Fix the issue by moving omap_i2c_complete_cmd()
call inside the 'out' label.
Signed-off-by: Felipe
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 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/buss
1 - 100 of 112 matches
Mail list logo
