The omap_i2c_remove function may not be needed after
device exit so the memory could be freed.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
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
Use INIT_COMPLETION instead of init_completion in transfer.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
- Add Felipe's reviewed-by tag
drivers/i2c/busses/i2c-omap.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
Remove the definition of SYSS_RESETDONE_MASK and use the
one in omap_hwmod.h.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
- Add Felipe's reviewed by tag
drivers/i2c/busses/i2c-omap.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote:
A quick reaction of my guts say, we simply enable 5V/HPD_IRQ during
probe and disable during remove.
HDMI enable/disable via /sysfs/ and HPD (de)assertion, switch only
HDMI_PHY on/off.
The user selecting Autodetect and Configure option
On 28 June 2012 19:01, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote:
On 28 June 2012 17:33, Andy Green andy.gr...@linaro.org wrote:
If Jassi's alright with it we might have a go at implementing this, but can
you define a bit more about how
On 28 June 2012 20:44, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote:
A quick reaction of my guts say, we simply enable 5V/HPD_IRQ during
probe and disable during remove.
HDMI enable/disable via /sysfs/ and HPD (de)assertion, switch only
On 06/28/12 22:45, the mail apparently from Steven Rostedt included:
On Thu, 2012-06-28 at 14:18 +, Arnd Bergmann wrote:
It's been a while since we discussed these patches, but Steven Rostedt
just tripped over the same problem and the patches work for
him, so he says Tested-by: Steven
+Paul, Benoit and Kevin
On Wed, Jun 27, 2012 at 11:11:32, N, Mugunthan V wrote:
-Original Message-
From: N, Mugunthan V
Sent: Thursday, June 07, 2012 9:52 PM
To: 'linux-omap@vger.kernel.org'
Cc: 'linux-arm-ker...@lists.infradead.org'
Subject: how to specify dma_mask and
On Thu, 2012-06-28 at 20:44 +0530, Jassi Brar wrote:
I won't press further with my Utopian ideas, but I think we need to
segregate 5V/HPD enabling from PHY enabling somehow. Because that is
already failing slow but otherwise perfectly legit displays (like
Andy's HPD taking 700ms TV)
Yes, I
As per recent discussion on the linux-omap list, we are
moving in the direction where, we will have only architecture,
ARCH_OMAP2PLUS and all devices/platforms will be treated
as a SoC underneath.
So the first step in this direction is to adopt this change
for all new devices getting in,
On Thu, Jun 28, 2012 at 20:35:38, Cousson, Benoit wrote:
Hi Vaibhav,
One small comment.
On 06/28/2012 04:59 PM, Vaibhav Hiremath wrote:
The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions
Hi Franky,
On 06/27/2012 08:03 PM, Franky Lin wrote:
On 06/27/2012 04:43 PM, Jon Hunter wrote:
Hi Franky,
On 06/25/2012 03:52 PM, Franky Lin wrote:
Hi Kevin, Tarun,
We are using the expansion connector A on Panda board to mount a SDIO
WiFi dongle on MMC2 with a level triggered interrupt
On Thu, Jun 28, 2012 at 20:35:38, Cousson, Benoit wrote:
Hi Vaibhav,
One small comment.
On 06/28/2012 04:59 PM, Vaibhav Hiremath wrote:
The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions
On 06/27/2012 07:41 PM, Franky Lin wrote:
On 06/26/2012 08:37 PM, Kevin Hilman wrote:
Franky Lin fran...@broadcom.com writes:
I noticed Kevin raised some similar cases on other platforms and also
provided two patches in the patch mail thread. But unfortunately those
two patches doesn't help
On 06/28/2012 05:39 PM, Hiremath, Vaibhav wrote:
On Thu, Jun 28, 2012 at 20:35:38, Cousson, Benoit wrote:
Hi Vaibhav,
One small comment.
On 06/28/2012 04:59 PM, Vaibhav Hiremath wrote:
The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4,
AM33XX PRCM architecture is different that any OMAP family
of devices, so it is required to have separate implementation
to handle AM33XX module enable/disable, reset assert/deassert
functionality.
This patch adds wrapper api's in omap_hwmod framework to
access prm/cm for AM33XX family of devices.
On 28 June 2012 20:57, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-06-28 at 20:44 +0530, Jassi Brar wrote:
it has, some user action should enable it while 'making the device
ready for new display'.
IOW, how do you envision an OMAP4 based tablet with HDMI port react to
display
On Tue, May 29, 2012 at 15:26:40, Hiremath, Vaibhav wrote:
From: Paul Walmsley p...@pwsan.com
OMAP3, OMAP4 and AM33xx share some common data like, clksel_rate
oscillator clock input (Virtual clock nodes), required for
clock tree; so move common data to common data file so that it
can be
Hi
On Thu, 28 Jun 2012, Bedia, Vaibhav wrote:
On Wed, Jun 27, 2012 at 11:11:32, N, Mugunthan V wrote:
-Original Message-
From: N, Mugunthan V
Sent: Thursday, June 07, 2012 9:52 PM
To: 'linux-omap@vger.kernel.org'
Cc: 'linux-arm-ker...@lists.infradead.org'
Subject: how
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Tony
The following changes since commit 6b16351acbd415e66ba16bf7d473ece1574cf0bc:
Linux 3.5-rc4 (2012-06-24 12:53:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git
On Thu, 28 Jun 2012, Tony Lindgren wrote:
Looks like the tag name or git branch to pull is missing above?
There's just the git tree.
Thanks, sorry about that, looks like my script got ahead of the k.org git
mirrors :-( New pull req sent.
- Paul
--
To unsubscribe from this list: send the
Hi,
On Wed, Jun 27, 2012 at 11:11 AM, N, Mugunthan V mugunthan...@ti.com wrote:
-Original Message-
From: N, Mugunthan V
Sent: Thursday, June 07, 2012 9:52 PM
To: 'linux-omap@vger.kernel.org'
Cc: 'linux-arm-ker...@lists.infradead.org'
Subject: how to specify dma_mask and
Hi,
On Thu, Jun 28, 2012 at 8:41 PM, Shubhrajyoti D shubhrajy...@ti.com wrote:
Use INIT_COMPLETION instead of init_completion in transfer.
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
- Add Felipe's reviewed-by tag
On 28 June 2012 21:18, Jassi Brar jaswinder.si...@linaro.org wrote:
On 28 June 2012 20:57, Tomi Valkeinen tomi.valkei...@ti.com wrote:
By the way, when the device is in system suspend, we surely won't detect
the HPD even if we kept the HPD always enabled. So there we'll miss the
HPD
Hi Paul,
On Thu, Jun 28, 2012 at 21:22:54, Paul Walmsley wrote:
[...]
dma_mask and coherent_dma_mask can be specified during
device creation. See usb_musb_init() in arch/arm/mach-omap2/usb-musb.c
for an example.
Thanks for pointing this out. Should omap_device_build() start handling
On Thu, 28 Jun 2012, Bedia, Vaibhav wrote:
On Thu, Jun 28, 2012 at 21:22:54, Paul Walmsley wrote:
[...]
dma_mask and coherent_dma_mask can be specified during
device creation. See usb_musb_init() in arch/arm/mach-omap2/usb-musb.c
for an example.
Thanks for pointing this out.
On Thu, Jun 28, 2012 at 22:02:46, Paul Walmsley wrote:
On Thu, 28 Jun 2012, Bedia, Vaibhav wrote:
On Thu, Jun 28, 2012 at 21:22:54, Paul Walmsley wrote:
[...]
dma_mask and coherent_dma_mask can be specified during
device creation. See usb_musb_init() in
Hi Tony, Afzal,
On 06/28/2012 07:32 AM, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120628 02:36]:
Hi Tony,
On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote:
The last patch in this series causes onenand not to show
up on my n900. I believe the problem has been there earlier
commit 164e0cbf60 (ARM: OMAP3/4: consolidate cpuidle Makefile) added
an OMAP-specific dependency from CPU_IDLE to CONFIG_PM. This causes
some randconfig warnings when CONFIG_PM has unmet dependencies:
warning: (ARCH_OMAP3 ARCH_OMAP4) selects PM which has unmet direct
dependencies (PM_SLEEP ||
From: Jean Pihet j-pi...@ti.com
Disable the module option for POWER_AVS since this is currently not
supported.
This patch fixes these error in the case POWER_AVS is set to 'm':
arch/arm/mach-omap2/built-in.o: In function `sr_class3_configure':
In order for suspend/resume dependencies to work correctly, I2C has to
be initialized (more specifically, registered with the driver core)
before MMC. Without this, the MMC driver fails to adjust the VMMC
regulator (using i2c writes) during the suspend path.
Problem found testing suspend/resume
Tony, here are hopefully the last couple PM-related fixes for v3.5-rc.
Both of these fix suspend/resume/wakeup problems on OMAP3 or OMAP4.
Thanks,
Kevin
Kevin Hilman (2):
ARM: OMAP2: Overo: init I2C before MMC to fix MMC suspend/resume
failure
ARM: OMAP4: TWL6030: ensure sys_nirq1 is
The SYS_NIRQ1 pin is the interupt line for the PMIC part of the TWL6030
and interrupts from the PMIC are needed as wakeup sources.
Ensure this pin is mux'd as input and has wakeup enabled so PMIC
interupts (e.g. RTC) can be used as wakeup sources.
Tested on OMAP4430/Panda.
Signed-off-by: Kevin
Add the OMAP CPUFreq driver to the list of files in the OMAP Power
Management section.
I've already been maintaining this driver, this just makes it
official.
Signed-off-by: Kevin Hilman khil...@ti.com
---
MAINTAINERS |1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS
CF Adad cfa...@rocketmail.com writes:
[...]
I bring these questions here, as the crash's call stack shares so many
similarities to the SLAB crash discussed
http://thread.gmane.org/gmane.linux.ports.arm.omap/78039/;, that I
think they're related. At the very least, the EMAC to EMAC
Jean Pihet jean.pi...@newoldbits.com writes:
Hi Rajendra,
On Wed, Jun 20, 2012 at 10:57 AM, Rajendra Nayak rna...@ti.com wrote:
Jean,
On Wednesday 20 June 2012 02:22 PM, Rajendra Nayak wrote:
Hi Jean,
On Wednesday 20 June 2012 02:16 PM, Rajendra Nayak wrote:
On Wednesday 20 June 2012
Boards that have OneNAND devices but only support the async read and write modes
show that the OneNAND operating frequency is 0 MHz on boot. For example, the
OMAP3430 SDP shows the following:
omap2-onenand: initializing on CS2, phys base 0x2000, virtual base
c88c, freq 0 MHz
This series
A platform function pointer for getting the frequency of a OneNAND device
was added so that a platform could specify a custom function for returning
the frequency and not just rely on the OneNAND version to determine the
frequency. However, this platform function pointer is not currently being
Boards that have OneNAND devices but only support the async read and write modes
show that the OneNAND operating frequency is 0 MHz on boot. For example, the
OMAP3430 SDP shows the following:
omap2-onenand: initializing on CS2, phys base 0x2000, virtual base
c88c, freq 0 MHz
This is
Hi Tony, Afzal,
On 06/28/2012 11:43 AM, Jon Hunter wrote:
Hi Tony, Afzal,
On 06/28/2012 07:32 AM, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120628 02:36]:
Hi Tony,
On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote:
The last patch in this series causes onenand not to show
On 06/28/2012 08:42 AM, Jon Hunter wrote:
On 06/27/2012 07:41 PM, Franky Lin wrote:
On 06/26/2012 08:37 PM, Kevin Hilman wrote:
Franky Lin fran...@broadcom.com writes:
I noticed Kevin raised some similar cases on other platforms and also
provided two patches in the patch mail thread. But
Hi Shubhrajyoti,
Shubhrajyoti Datta omaplinuxker...@gmail.com writes:
Hi Kevin,
Thanks for the patch ,
a doubt below
Thanks for the review.
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
On 06/28/2012 04:24 PM, Franky Lin wrote:
On 06/28/2012 08:42 AM, Jon Hunter wrote:
On 06/27/2012 07:41 PM, Franky Lin wrote:
On 06/26/2012 08:37 PM, Kevin Hilman wrote:
Franky Lin fran...@broadcom.com writes:
I noticed Kevin raised some similar cases on other platforms and also
provided
Hi Kevin,
Thanks for the message! I did not realize the issue with the wake-ups affected
the EMAC, but I have been running my kernel with 'nohlt' since we transitioned
to linux-omap-3.4rcX several weeks back. It was required to keep the kernel
from crashing on boot. Running with that option
On 06/28/2012 02:55 PM, Jon Hunter wrote:
Ok. Any way to manually reset the wlan module to deactivate the gpio
when it is hung? I am wondering if the gpio is deactivated if the board
comes back to life, indicating it is stuck in the interrupt somewhere.
The only way I can think of is removing
On 06/28/2012 05:53 PM, Franky Lin wrote:
On 06/28/2012 02:55 PM, Jon Hunter wrote:
Ok. Any way to manually reset the wlan module to deactivate the gpio
when it is hung? I am wondering if the gpio is deactivated if the board
comes back to life, indicating it is stuck in the interrupt
On 06/28/2012 03:59 PM, Jon Hunter wrote:
On 06/28/2012 05:53 PM, Franky Lin wrote:
I found one interesting thing. When I added the print info to see when
runtime_suspend/resume get called, it seems like the suspend/resume is
unbalance during boot. Resume got called more than suspend. So I
'Acked-by: mant...@ti.com'
'Tested-by: mant...@ti.com'
Regards,
Mantesh
-Original Message-
From: Russ Dill [mailto:russ.d...@gmail.com] On Behalf Of Dill, Russ
Sent: Wednesday, June 27, 2012 9:00 PM
To: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
On 06/28/2012 06:10 PM, Franky Lin wrote:
On 06/28/2012 03:59 PM, Jon Hunter wrote:
On 06/28/2012 05:53 PM, Franky Lin wrote:
I found one interesting thing. When I added the print info to see when
runtime_suspend/resume get called, it seems like the suspend/resume is
unbalance during boot.
On 06/28/2012 06:10 PM, Franky Lin wrote:
On 06/28/2012 03:59 PM, Jon Hunter wrote:
On 06/28/2012 05:53 PM, Franky Lin wrote:
I found one interesting thing. When I added the print info to see when
runtime_suspend/resume get called, it seems like the suspend/resume is
unbalance during boot.
On 06/28/2012 06:10 PM, Franky Lin wrote:
On 06/28/2012 03:59 PM, Jon Hunter wrote:
On 06/28/2012 05:53 PM, Franky Lin wrote:
I found one interesting thing. When I added the print info to see when
runtime_suspend/resume get called, it seems like the suspend/resume is
unbalance during boot.
Hi Rob, Grant,
Benoit suggested that I ask your opinion on the below.
Basically, I am trying to understand if there is any reason not to
enable OF_DYNAMIC. More details below on the exact scenario I am trying
to solve. OF_DYNAMIC seems to provide a good solution for me.
Thanks
Jon
On
On 06/28/2012 04:54 PM, Jon Hunter wrote:
I am wondering if this could be the bug ... on start-up I see that we do
a context restore on bank1 during the probe which is before we have done
the first suspend! In other words, we could restore a bad/uninitialised
context for bank1. In the case of
commit 99b59df0 ARM: OMAP3: PM: fix shared PRCM interrupt leave disabled at boot
set the IRQ_NOAUTOEN flag to the PCRM IO-chain irq to avoid this
interrupt until the PM core code is ready to handle the interrupts.
It seems that this is not needed anymore after the OMAP PRCM I/O chain
code
No, it should be init_completion(dev-cmd_complete); in probe, we need to
initialize the wait queue, which will be used when using complete(..)
-Original Message-
From: linux-i2c-ow...@vger.kernel.org [mailto:linux-i2c-ow...@vger.kernel.org]
On Behalf Of ABRAHAM, KISHON VIJAY
Sent:
On Fri, Jun 29, 2012 at 6:29 AM, Franky Lin fran...@broadcom.com wrote:
On 06/28/2012 04:54 PM, Jon Hunter wrote:
I am wondering if this could be the bug ... on start-up I see that we do
a context restore on bank1 during the probe which is before we have done
the first suspend! In other
On Friday 29 June 2012 03:25 AM, Kevin Hilman wrote:
Hi Shubhrajyoti,
Shubhrajyoti Datta omaplinuxker...@gmail.com writes:
Hi Kevin,
Thanks for the patch ,
a doubt below
Thanks for the review.
On Wed, Jun 27, 2012 at 7:15 AM, Kevin Hilman khil...@ti.com wrote:
In omap_i2c_xfer(), ensure
The following series adds some code to generate legal, locally administered
MAC addresses from OMAP4 CPU Die ID fuse data, and then adds an api to
devices.c allowing board files to register device paths for network devices
that wish to use them.
On PandaBoard / ES, two devices have no board-level
From: Andy Green a...@warmcat.com
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:40:70:f0:12:06
for the ethernet device on my Panda.
The MAC address space
From: Andy Green a...@warmcat.com
This exposes a new API in devices.c that lets a board register
a list of device paths representing network devices that have
no arrangements for their MAC address to be set by the board.
It watches network device registrations via a notifier and
gives the
From: Andy Green a...@warmcat.com
This provides the board-specific device paths needed to get
the panda boardfile working with the MAC address fixup api.
On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series
101 - 163 of 163 matches
Mail list logo
