Hi Tony, Jon,
On Thu, Jun 28, 2012 at 22:13:37, Hunter, Jon wrote:
On 06/28/2012 07:32 AM, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120628 02:36]:
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
Hi Kevin,
On Thursday 28 June 2012 10:31 PM, Kevin Hilman wrote:
In order for suspend/resume dependencies to work correctly, I2C has to
be initialized (more specifically, registered with the driver core)
before MMC.
Agree.
Without this, the MMC driver fails to adjust the VMMC
regulator
On Wed, 2012-06-27 at 19:34 +0530, jaswinder.si...@linaro.org wrote:
From: Jassi Brar jaswinder.si...@linaro.org
State change of HDMI PHY could potentially take many millisecs, we can do
better by protecting things in hdmi_set_phy_pwr() with a mutex rather than
a spin_lock_irqsave.
On Wed, May 30, 2012 at 3:16 PM, Ohad Ben-Cohen o...@wizery.com wrote:
In this case, I was more wondering between using a class to a device type.
I recall seeing a thread where
someone said classes were on the way out and shouldn't be used but I
can't find it anymore.
I also remembered a
On Friday 29 June 2012, Andy Green wrote:
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
On Friday 29 June 2012, Andy Green wrote:
+static int omap_panda_netdev_event(struct notifier_block *this,
+ unsigned long event, void
*ptr)
+{
+ struct net_device *dev = ptr;
+ struct sockaddr sa;
+ int n;
+
+ if
On 06/29/12 16:51, the mail apparently from Arnd Bergmann included:
On Friday 29 June 2012, Andy Green wrote:
+static int omap_panda_netdev_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ struct net_device *dev = ptr;
* Andy Green andy.gr...@linaro.org [120628 22:59]:
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
...
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -530,3 +530,42 @@ void __init
ensure pm_runtime_put() is called, on pm_runtime_get_sync()
failure.
Without this, after a failed call, the runtime PM usecount will have
been incremented, but not decremented causing the usecount to never
reach zero after a failure. Thanks to Kevin for educating about it.
This patch adds missing CONTROL_SMART2IO_PADCONF_2 register
definition
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
.../include/mach/ctrl_module_pad_core_44xx.h | 45
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git
The OMAP4 EHCI controller has the following defect (errata ID i687):
Title:
USB TLL Hold Timing Violation
Description:
There is a timing hold violation on an internal logic on
the clock USB TLL path resulting in a systematic connection
failure on the TLL link
On 06/29/12 17:05, the mail apparently from Tony Lindgren included:
* Andy Green andy.gr...@linaro.org [120628 22:59]:
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
...
--- a/arch/arm/mach-omap2/id.c
+++
* Andy Green andy.gr...@linaro.org [120628 22:59]:
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
On 06/29/12 17:40, the mail apparently from Tony Lindgren included:
* Andy Green andy.gr...@linaro.org [120628 22:59]:
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
On Thu, 2012-06-28 at 20:00 +0530, Archit Taneja wrote:
Replace the DISPC fuctions used to configure LCD channel related manager
parameters with dss_mgr_set_lcd_config() in APPLY. This function ensures that
the DISPC registers are written at the right time by using the shadow register
From: Felipe Balbi ba...@ti.com
trivial patch, no functional changes
If the fifo is disabled or fifo_size is 0 the num_bytes
is set to 1. Else it is set to fifo_size or in case of a
draining interrupt the remaining bytes in the buff stat.
So the zero check is redundant and can be safely
From: Felipe Balbi ba...@ti.com
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 28
1 files changed, 16
From: Felipe Balbi ba...@ti.com
we can ack stat and complete the command from
the errata handling itself.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 16 +---
1 files changed, 13 insertions(+), 3
From: Felipe Balbi ba...@ti.com
instead of having multiple return points, use
a goto statement to make that clearer.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20
1 files changed, 8
From: Felipe Balbi ba...@ti.com
stat BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing stat from
all omap_i2c_ack_stat() calls.
Code snippet (extremely simplified):
if (stat NACK) {
...
omap_i2c_ack_stat(dev, stat NACK);
}
if (stat RDR) {
...
From: Felipe Balbi ba...@ti.com
The patch intends to decrease the indentation level on the
data handling
by using the fact that else of if (dev-buf_len) is same as
if (!dev-buf_len)
if (dev-buf_len) {
aaa;
} else {
bbb;
break;
}
to
if (!dev-buf_len) {
bbb;
From: Felipe Balbi ba...@ti.com
that way we can ignore TX IRQs while in receiver
mode and ignore RX IRQs while in transmitter mode.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |9 +
1 files changed, 9
From: Felipe Balbi ba...@ti.com
that's a nice helper from drivers core which
will give us the exact IRQ number, instead
of a pointer to an IRQ resource.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 12
From: Felipe Balbi ba...@ti.com
otherwise we could get our IRQ line disabled due
to many spurious IRQs.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
From: Felipe Balbi ba...@ti.com
this will make sure that we execute at least once.
No functional changes otherwise.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 20 ++--
1 files changed, 14
From: Felipe Balbi ba...@ti.com
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git
From: Felipe Balbi ba...@ti.com
re-factor the common parts to a separate function,
so that code is easier to read and understand.
No functional changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 204
From: Felipe Balbi ba...@ti.com
that helps deleting some boiler plate code
and lets driver-core manage our resources
for us.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 40
From: Felipe Balbi ba...@ti.com
omap_i2c_dev is allocated with kzalloc(),
so we need not initialize b_hw to zero.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |4 +---
1 files changed, 1 insertions(+), 3
From: Felipe Balbi ba...@ti.com
Make it not depend on ISR's local variables
in order to make it easier to re-factor the
transmit data loop.
Also since we are waiting for XUDF just before
writing data lets not flag the underflow.
This is anyways going to go once we write
the data.
Signed-off-by:
From: Felipe Balbi ba...@ti.com
This patch will try to avoid the usage of
draining feature by reconfiguring the FIFO
the start condition of each message based
on the message's size.
By doing that, we will be better utilizing
the FIFO when doing big transfers.
While at that also drop the now
I have dropped a few patches from the series and also
tested every single patch on my pandaboard.
There's still lots of work to be done on the i2c-omap.c
driver but it's now easier to read, IMO.
Changes since v1:
- removed tabification on patch 6/17
- removed dev_err() which was
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,
On Friday 29 June 2012 03:42 PM, Tomi Valkeinen wrote:
On Thu, 2012-06-28 at 20:00 +0530, Archit Taneja wrote:
Replace the DISPC fuctions used to configure LCD channel related manager
parameters with dss_mgr_set_lcd_config() in APPLY. This function ensures that
the DISPC registers are written
On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
Use tiled buffers for rotated/reflected scanout, with CRTC and plane
properties as the interface for userspace to configure rotation.
Signed-off-by: Rob Clark r...@ti.com
+/* this should probably be in
Currently the I2C core reports only a negative number on errors.
However some of the users in case of errors want to re-transfer only
the remaining bytes.
The patch series tries to add a actual field to the msg which
can be checked by the user.
Also a patch to implement the actual bytes
In i2c_smbus_xfer_emulated initialise the actual bytes
to zero.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/i2c-core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index a6ad32b..fa7f799 100644
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 shubhrajy...@ti.com
Signed-off-by:
From: Felipe Balbi ba...@ti.com
this is important in cases where client driver
wants to know how many bytes were actually
transferred.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 +
1 files changed, 5
Hi Paul,
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
As omap1 and omap2 will never be compiled together, due to
different compiler flags, so we can simply make
cpu_class_is_omap2() = true, for all non-omap1 platforms.
In order to fix build error from plat-omap/sram.c file,
omap_type() function is encapsulated under #ifdef CONFIG_ARCH_OMAP2PLUS.
From: Wenbiao Wang ww...@ti.com
OTG clock usb_otg_hs_ick used a incorrect parent l3_div_ck.
Correct it to use the right colck otg_60m_gfclk as its
parent.
Signed-off-by: Wenbiao Wang ww...@ti.com
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 15
* Andy Green andy.gr...@linaro.org [120628 23:00]:
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -486,6 +486,15 @@ static void omap4_panda_init_rev(void)
}
}
+/*
+ * These device paths represent onboard network devices which have
+ *
Shubhrajyoti D shubhrajy...@ti.com writes:
ensure pm_runtime_put() is called, on pm_runtime_get_sync()
failure.
Without this, after a failed call, the runtime PM usecount will have
been incremented, but not decremented causing the usecount to never
reach zero after a
* Andy Green andy.gr...@linaro.org [120629 03:12]:
On 06/29/12 17:40, the mail apparently from Tony Lindgren included:
This is a bit similar to platform data callback functions that we are
trying to get rid of. And as the question how do we replace platform
data callback functions is still
On Fri, Jun 29, 2012 at 5:46 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote:
From: Rob Clark r...@ti.com
Use tiled buffers for rotated/reflected scanout, with CRTC and plane
properties as the interface for userspace to configure rotation.
On Fri, 29 Jun 2012 16:35:25 +0530, Shubhrajyoti D wrote:
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.
On Fri, 29 Jun 2012 16:35:27 +0530, Shubhrajyoti D wrote:
In i2c_smbus_xfer_emulated initialise the actual bytes
to zero.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/i2c-core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
* Benoit Cousson b-cous...@ti.com [120628 08:46]:
On 06/28/2012 05:39 PM, Hiremath, Vaibhav wrote:
On Thu, Jun 28, 2012 at 20:35:38, Cousson, Benoit wrote:
OMAP4 does not have the SDRC but the EMIF like TI8XX.
Benoit,
This selection is happening for SOC_OMAP2420 and not for OMAP4.
+Paul
Javier Martinez Canillas jav...@dowhile0.org writes:
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
On Friday 29 June 2012 05:32 PM, Kevin Hilman wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
ensure pm_runtime_put() is called, on pm_runtime_get_sync()
failure.
Without this, after a failed call, the runtime PM usecount will have
been incremented, but not decremented
On Fri, 29 Jun 2012 14:40:02 +0200, Jean Delvare wrote:
On Fri, 29 Jun 2012 16:35:27 +0530, Shubhrajyoti D wrote:
In i2c_smbus_xfer_emulated initialise the actual bytes
to zero.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/i2c-core.c |4 ++--
1 files
* Kevin Hilman khil...@ti.com [120628 09:49]:
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
* Kevin Hilman khil...@ti.com [120628 10:00]:
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
On Friday 29 June 2012 06:27 PM, Jean Delvare wrote:
drivers/gpu/drm/nouveau/nouveau_bios.c:3535:3: warning: (near initialization
for ‘msg[1].actual’) [enabled by default]
This needs to be all fixed (converted to C99-style struct
initialization) before your patch is considered for inclusion.
On Fri, 29 Jun 2012 18:42:08 +0530, Shubhrajyoti wrote:
On Friday 29 June 2012 06:27 PM, Jean Delvare wrote:
drivers/gpu/drm/nouveau/nouveau_bios.c:3535:3: warning: (near
initialization for ‘msg[1].actual’) [enabled by default]
This needs to be all fixed (converted to C99-style struct
On Fri, Jun 29, 2012 at 2:55 PM, Kevin Hilman khil...@ti.com wrote:
+Paul
Javier Martinez Canillas jav...@dowhile0.org writes:
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
Tony,
Here is the EMIF driver DT support which was kept on hold for the driver
to get merged. The series has been already reviewed on the list.
v4:
Fixed the DT config flag and rebased against 3.5-rc4
v3:
Rebased against the 3.5-rc2
This series adds device tree support for TI EMIF SDRAM
From: Aneesh V ane...@ti.com
EMIF - External Memory Interface - is an SDRAM controller used in
TI SoCs. EMIF supports, based on the IP revision, one or more of
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
of the EMIF IP and memory parts attached to it.
Reviewed-by: Benoit
From: Aneesh V ane...@ti.com
device tree bindings for LPDDR2 SDRAM memories compliant
to JESD209-2 standard.
The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
for specifying the AC timing parameters of the memory device at
different speed-bins.
Reviewed-by: Benoit Cousson
From: Aneesh V ane...@ti.com
Device tree data for the EMIF sdram controllers in OMAP4
and LPDDR2 memory devices attached to OMAP4 boards.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by:
From: Aneesh V ane...@ti.com
Device tree support for the EMIF driver.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
[santosh.shilim...@ti.com: Rebased against
On Friday 29 June 2012, Tony Lindgren wrote:
* Andy Green andy.gr...@linaro.org [120629 03:12]:
2. Is this really how we want to pass the board generated mac addresses
and other dynamically generated data to the drivers that are device
tree based?
The issue is that both these
Greg,
On Tue, Jun 26, 2012 at 1:19 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jun 26, 2012 at 10:56 AM, Rajendra Nayak rna...@ti.com wrote:
On Tuesday 26 June 2012 10:53 AM, Shilimkar, Santosh wrote:
On Tue, Jun 26, 2012 at 10:49 AM, Rajendra Nayakrna...@ti.com wrote:
Am 28.06.2012 17:09, schrieb Daniel Mack:
On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
Just to clarify from AM335x perspective,
In case of AM335x, since the patches and complete BasePort support is still
not present in the Mainline (neither in Linus's tree not in linux-omap), you
need to
* Arnd Bergmann a...@arndb.de [120629 06:50]:
On Friday 29 June 2012, Tony Lindgren wrote:
* Andy Green andy.gr...@linaro.org [120629 03:12]:
2. Is this really how we want to pass the board generated mac addresses
and other dynamically generated data to the drivers that are device
On 06/29/12 21:55, the mail apparently from Tony Lindgren included:
* Arnd Bergmann a...@arndb.de [120629 06:50]:
On Friday 29 June 2012, Tony Lindgren wrote:
* Andy Green andy.gr...@linaro.org [120629 03:12]:
2. Is this really how we want to pass the board generated mac addresses
and
Shubhrajyoti shubhrajy...@ti.com writes:
On Friday 29 June 2012 05:32 PM, Kevin Hilman wrote:
Shubhrajyoti D shubhrajy...@ti.com writes:
ensure pm_runtime_put() is called, on pm_runtime_get_sync()
failure.
Without this, after a failed call, the runtime PM usecount will have
On 06/29/12 21:45, the mail apparently from Arnd Bergmann included:
On Friday 29 June 2012, Tony Lindgren wrote:
* Andy Green andy.gr...@linaro.org [120629 03:12]:
2. Is this really how we want to pass the board generated mac addresses
and other dynamically generated data to the drivers
commit 99b59df0 (ARM: OMAP3: PM: fix shared PRCM interrupt leave
disabled at boot) added IRQ_NOAUTOEN to the PRCM interrupt so it could
be enabled later if needed. However, this commit was partially undone
when merging the IO daisy chain rework in 9a17d88e (Merge tag
'omap-devel-c-for-3.6' of
Javier Martinez Canillas martinez.jav...@gmail.com writes:
On Fri, Jun 29, 2012 at 2:55 PM, Kevin Hilman khil...@ti.com wrote:
+Paul
Javier Martinez Canillas jav...@dowhile0.org writes:
commit 99b59df0 ARM: OMAP3: PM: fix shared PRCM interrupt leave disabled at
boot
set the IRQ_NOAUTOEN
Hi Afzal,
On 06/29/2012 01:15 AM, Mohammed, Afzal wrote:
Hi Tony, Jon,
On Thu, Jun 28, 2012 at 22:13:37, Hunter, Jon wrote:
On 06/28/2012 07:32 AM, Tony Lindgren wrote:
* Mohammed, Afzal af...@ti.com [120628 02:36]:
On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote:
The last patch
* Kevin Hilman khil...@ti.com [120629 07:08]:
commit 99b59df0 (ARM: OMAP3: PM: fix shared PRCM interrupt leave
disabled at boot) added IRQ_NOAUTOEN to the PRCM interrupt so it could
be enabled later if needed. However, this commit was partially undone
when merging the IO daisy chain rework in
On Friday 29 June 2012, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [120629 06:50]:
On Friday 29 June 2012, Tony Lindgren wrote:
* Andy Green andy.gr...@linaro.org [120629 03:12]:
2. Is this really how we want to pass the board generated mac addresses
and other dynamically
On Friday 29 June 2012, Andy Green wrote:
On 06/29/12 21:45, the mail apparently from Arnd Bergmann included:
On Friday 29 June 2012, Tony Lindgren wrote:
In case we have a device tree, we should just be using the USB binding
to find the specific device node, and add the property there.
On 27/06/12 13:07, Hiremath, Vaibhav wrote:
Omap2plus_defconfig should work for you, you should get linux prompt with
ramdisk image (which I use). Just to be more clear, and for your reference I
am pasting steps which I use for testing,
Build Steps:
- make ARCH=arm
* Arnd Bergmann a...@arndb.de [120629 07:37]:
On Friday 29 June 2012, Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [120629 06:50]:
On Friday 29 June 2012, Tony Lindgren wrote:
* Andy Green andy.gr...@linaro.org [120629 03:12]:
2. Is this really how we want to pass the board
On Friday 29 June 2012, Tony Lindgren wrote:
A lot of devices already provide the mac address in the device tree,
wherever that comes from. Ideally that would always be possible but
never necessary.
I'm not sure what it takes to add the link for the device node in the
usb probing
On Wed, 27 Jun 2012, Russ Dill wrote:
From: Russ Dill russ.d...@gmail.com
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' (1fcb57d0) fixes
an issue where the ULPI PHYs were not held in reset while initializing
the EHCI controller. However, it also changes behavior in
omap-usb-host.c
On 06/28/2012 11:07 PM, DebBarma, Tarun Kanti wrote:
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
When an inbound message arrives, the rpmsg core looks up its
associated endpoint and invokes the registered callback.
If a message arrives while its endpoint is being removed (because
the rpmsg driver was removed, or a recovery of a remote processor
has kicked in) we must ensure atomicity, i.e.:
When inbound messages arrive, rpmsg core looks up their associated
endpoint (by destination address) and then invokes their callback.
We've made sure that endpoints will never be de-allocated after they
were found by rpmsg core, but we also need to protect against the
(rare) scenario where the
Currently the gpio _runtime_resume/suspend functions are calling the
get_context_loss_count() platform function if the function is populated for
a gpio bank. This function is used to determine if the gpio bank logic state
needs to be restored due to a power transition. This function will be
On Thu, Jun 28, 2012 at 20:39:08, Daniel Mack wrote:
On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
Just to clarify from AM335x perspective,
In case of AM335x, since the patches and complete BasePort support is still
not present in the Mainline (neither in Linus's tree not in
On Fri, Jun 29, 2012 at 19:24:04, Yegor Yefremov wrote:
Am 28.06.2012 17:09, schrieb Daniel Mack:
On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
Just to clarify from AM335x perspective,
In case of AM335x, since the patches and complete BasePort support is still
not present in the
On Fri, Jun 29, 2012 at 19:50:45, Mark Jackson wrote:
On 27/06/12 13:07, Hiremath, Vaibhav wrote:
Omap2plus_defconfig should work for you, you should get linux prompt with
ramdisk image (which I use). Just to be more clear, and for your reference
I am pasting steps which I use for
On 29.06.2012 19:33, Hiremath, Vaibhav wrote:
On Thu, Jun 28, 2012 at 20:39:08, Daniel Mack wrote:
On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
Just to clarify from AM335x perspective,
In case of AM335x, since the patches and complete BasePort support is still
not present in the Mainline
On Sat, Jun 30, 2012 at 00:04:53, Daniel Mack wrote:
On 29.06.2012 19:33, Hiremath, Vaibhav wrote:
On Thu, Jun 28, 2012 at 20:39:08, Daniel Mack wrote:
On 27.06.2012 14:13, Hiremath, Vaibhav wrote:
Just to clarify from AM335x perspective,
In case of AM335x, since the patches and
On Fri, 29 Jun 2012, Kevin Hilman wrote:
commit 99b59df0 (ARM: OMAP3: PM: fix shared PRCM interrupt leave
disabled at boot) added IRQ_NOAUTOEN to the PRCM interrupt so it could
be enabled later if needed. However, this commit was partially undone
when merging the IO daisy chain rework in
Hi
On Wed, 27 Jun 2012, Rajendra Nayak wrote:
As part of Common Clk Framework (CCF) the clk_enable() operation
was split into a clk_prepare() which could sleep, and a clk_enable()
which should never sleep. Similarly the clk_disable() was
split into clk_disable() and clk_unprepare(). This was
Hi
On Fri, 29 Jun 2012, Paul Walmsley wrote:
This patch generates quite a few checkpatch warnings:
WARNING: please, no space before tabs
#294: FILE: arch/arm/mach-omap2/clock3xxx_data.c:3479:
+^ICLK(NULL, ^Imcbsp4_ick,^Imcbsp2_ick,^ICK_3XXX),$
etc.
Please fix these.
The 80
Hi
On Wed, 27 Jun 2012, Rajendra Nayak wrote:
Moving to Common clk framework for OMAP would mean we no longer use
internal lookup mechanism like omap_clk_get_by_name().
get rid of all its usage mostly from hwmod and omap_device
code.
Also use IS_ERR_OR_NULL() for error checking.
Moving
Hi
On Wed, 27 Jun 2012, Rajendra Nayak wrote:
While we move to Common Clk Framework (CCF), direct deferencing of struct
clk wouldn't be possible anymore. Hence get rid of all such instances
in the current clock code and use macros/helpers similar to the ones that
are provided by CCF.
On 06/29/2012 10:22 AM, Jon Hunter wrote:
Currently the gpio _runtime_resume/suspend functions are calling the
get_context_loss_count() platform function if the function is populated for
a gpio bank. This function is used to determine if the gpio bank logic state
needs to be restored due to a
+ Benoît who is the maintainer of this file
+ the linux-arm-kernel mailing list, which should be cc'ed on all OMAP
patches
On Fri, 29 Jun 2012, Ruslan Bilovol wrote:
From: Wenbiao Wang ww...@ti.com
OTG clock usb_otg_hs_ick used a incorrect parent l3_div_ck.
Correct it to use the right
The wake-up power domain is an alway-on power domain and so this power domain
does not have a power state status (PM_PWSTST_xxx) register that indicates the
current state. However, during the registering of the wake-up power domain the
state of the domain is queried by calling pwrdm_read_pwrst().
Note: Re-sending with updated kernel doc.
The wake-up power domain is an alway-on power domain and so this power domain
does not have a power state status (PM_PWSTST_xxx) register that indicates the
current state. However, during the registering of the wake-up power domain the
state of the domain
On Fri, Jun 29, 2012 at 07:16:19PM +0530, Shilimkar, Santosh wrote:
Greg,
On Tue, Jun 26, 2012 at 1:19 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jun 26, 2012 at 10:56 AM, Rajendra Nayak rna...@ti.com wrote:
On Tuesday 26 June 2012 10:53 AM, Shilimkar, Santosh
On 06/29/2012 04:07 PM, Greg Kroah-Hartman wrote:
On Fri, Jun 29, 2012 at 07:16:19PM +0530, Shilimkar, Santosh wrote:
Greg,
On Tue, Jun 26, 2012 at 1:19 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jun 26, 2012 at 10:56 AM, Rajendra Nayak rna...@ti.com wrote:
On Tuesday
On Wed, Jun 20, 2012 at 4:31 PM, Tony Lindgren t...@atomide.com wrote:
* Ruslan Bilovol ruslan.bilo...@ti.com [120612 10:42]:
If the clocks are enabled and we want to enable them again
omap4430_phy_set_clk disables them.
Fix this - so now if we try to enable already enabled clocks
it
1 - 100 of 110 matches
Mail list logo
