On 2/29/2012 12:47 PM, Adrian Hunter wrote:
Most parts of the enable / disable API are no longer used and
can be removed.
Cc: Rajendra Nayakrna...@ti.com
Cc: Venkatraman Ssvenk...@ti.com
Cc: Kukjin Kimkgene@samsung.com
Cc: Thomas Abrahamthomas.abra...@linaro.org
Cc: Kyungmin
The patch set focuses on extending remoteproc's virtio support: we're
putting behind the single rpmsg virtio device limitation, and allowing
firmwares to publish any number of virtio devices and of any type.
This allows us to reuse the existing virtio drivers with remote processor
backends.
For
At this point remoteproc can only register a single VIRTIO_ID_RPMSG virtio
device.
This limitation is going away soon: remoteproc is getting support for
registering any number of virtio devices and of any type (as
published by the firmware of the remote processor).
Rename remoteproc_rpmsg.c to
The resource table is an array of 'struct fw_resource' members, where
each resource entry is expressed as a single member of that array.
This approach got us this far, but it has a few drawbacks:
1. Different resource entries end up overloading the same members of 'struct
fw_resource' with
Boot the remote processor only after setting up the virtqueues,
and shut it down before deleting them.
Remote processors should obey virtio status changes, and
therefore not manipulate/trigger the virtqueues while the virtio
driver isn't ready, but it's just safer not to rely on that
(plus a vq
Now that remoteproc supports any number of virtio devices,
the previous sanity check in omap_rproc_mbox_callback
doesn't make sense anymore.
Remove that so we can start supporting multiple vdevs.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
Cc: Brian Swetland swetl...@google.com
Cc: Iliyan
Remove the hardcoded vring alignment of 4096 bytes,
and instead utilize tha vring alignment as specified in
the resource table.
This is needed for remote processors that have rigid
memory requirement, and which have found the alignment of
4096 bytes to be excessively big.
Signed-off-by: Ohad
rproc_handle_resources() looks for the resource table and then
invokes a resource handler function which it took as a parameter.
This works, but it's a bit unintuitive to follow.
Instead of passing around function pointers, this patch changes
rproc_handle_resource() to just find and return the
Now that the resource table supports publishing a virtio device
in a single resource entry, firmware images can start supporting
more than a single vdev.
This patch removes the single vdev limitation of the remoteproc
framework so multi-vdev firmwares can be leveraged: VDEV resource
entries are
From: Mythri P K mythr...@ti.com
Currently TX_PHY is put to TX_ON(transmission state) on receiving HPD.
It just ensures that the TV is connected but does not guarantee
that TMDS data lines and clock lines are up and ready for transmission.
Which although is very rare scenario has a potential to
On 01/03/12 10:08, Subhash Jadavani wrote:
On 2/29/2012 12:47 PM, Adrian Hunter wrote:
Most parts of the enable / disable API are no longer used and
can be removed.
Cc: Rajendra Nayakrna...@ti.com
Cc: Venkatraman Ssvenk...@ti.com
Cc: Kukjin Kimkgene@samsung.com
Cc: Thomas
On Thu, 2012-03-01 at 12:31 +0530, Rajendra Nayak wrote:
On Wednesday 29 February 2012 08:55 PM, Tero Kristo wrote:
Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
from kernel config, however enabling this option breaks the OMAP kernel
completely and it can't be
On Thu, 2012-03-01 at 12:22 +0530, Rajendra Nayak wrote:
On Wednesday 29 February 2012 07:56 PM, Tero Kristo wrote:
From: Vishwanath BSvishwanath...@ti.com
Enable IO Wake up for OMAP3 as part of PM Init. Currently this has been
managed in cpuidle path which is not the right place.
On Thu, 2012-03-01 at 12:19 +0530, Rajendra Nayak wrote:
On Wednesday 29 February 2012 07:56 PM, Tero Kristo wrote:
From: Vishwanath BSvishwanath...@ti.com
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File.
Signed-off-by: Vishwanath
On Thursday 01 March 2012 01:58 PM, Tero Kristo wrote:
On Thu, 2012-03-01 at 12:19 +0530, Rajendra Nayak wrote:
On Wednesday 29 February 2012 07:56 PM, Tero Kristo wrote:
From: Vishwanath BSvishwanath...@ti.com
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM
On Wed, Feb 29, 2012 at 11:07 PM, Tony Lindgren t...@atomide.com wrote:
Hi Santosh,
Looks like OMAP4_ERRATA_I688 still has one more issue:
Modules won't build at least with the attached randconfig
generated file.
Can you please take a look at how to deal with it?
Maybe omap_bus_sync
From: Ilya Yanok ya...@emcraft.com
AM35xx SoCs include DaVinci EMAC IP. Initialization code in
board-am3517evm.c is pretty board independent and will work for any
AM35xx based board so move this code to it's own file to be reused by
other boards.
Signed-off-by: Ilya Yanok ya...@emcraft.com
Add support for the EMAC Ethernet controller in the AM35xx SoC.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
arch/arm/mach-omap2/board-cm-t3517.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
On Wed, Feb 29, 2012 at 05:25:06PM +0200, Tero Kristo wrote:
Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
from kernel config, however enabling this option breaks the OMAP kernel
completely and it can't be used.
No it does not. Look:
irq_alloc_descs(start,
On Thu, 2012-03-01 at 09:46 +, Russell King - ARM Linux wrote:
On Wed, Feb 29, 2012 at 05:25:06PM +0200, Tero Kristo wrote:
Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
from kernel config, however enabling this option breaks the OMAP kernel
completely and it
On 3/1/2012 1:51 PM, Adrian Hunter wrote:
On 01/03/12 10:08, Subhash Jadavani wrote:
On 2/29/2012 12:47 PM, Adrian Hunter wrote:
Most parts of the enable / disable API are no longer used and
can be removed.
Cc: Rajendra Nayakrna...@ti.com
Cc: Venkatraman Ssvenk...@ti.com
Cc: Kukjin
On Thu, Mar 01, 2012 at 07:07:01, Paul Walmsley wrote:
Hi
a question -
On Sun, 25 Dec 2011, Vaibhav Hiremath wrote:
+static struct powerdomain mpu_33xx_pwrdm = {
+ .name = mpu_pwrdm,
+ .voltdm = { .name = mpu },
+ .prcm_partition =
On Thu, Mar 01, 2012 at 07:14:24, Paul Walmsley wrote:
Hi
some other observations:
On Sun, 25 Dec 2011, Vaibhav Hiremath wrote:
+static struct powerdomain per_33xx_pwrdm = {
+ .name = per_pwrdm,
+ .voltdm = { .name = core },
+
On Sat, Feb 4, 2012 at 7:43 PM, Grazvydas Ignotas nota...@gmail.com wrote:
These patches try address isp1704_charger crash in a different way
than 772aed45b604, which broke runtime_pm for me.
Felipe Contreras, oculd you test isp1704_charger with these?
Ping. These still apply cleanly and are
Hi,
On Thu, 2012-03-01 at 13:44 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Currently TX_PHY is put to TX_ON(transmission state) on receiving HPD.
It just ensures that the TV is connected but does not guarantee
that TMDS data lines and clock lines are up and ready for
The main patch in this set is the PHY burnout fix, which implements a fix for
a hardware bug in the OMAP4 HDMI PHY which may cause physical damage to the
board if the HDMI PHY is already enabled when the HDMI cable is plugged in. The
possible damage breaks HDMI output hardware, otherwise the board
The GPIO 60 on 4430sdp and Panda is not HPD GPIO, as currently marked in
the board files, but CT_CP_HPD, which is used to enable/disable HPD
functionality.
This patch renames the GPIO.
Backported from 3932a32fcf5393f8be70ac99dc718ad7ad0a415b
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Instead of freeing the GPIOs individually, use gpio_free_array().
Backported from 575753e3bea3b67eef8e454fb87f719e3f7da599
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|3 +--
Both Panda and 4430SDP use GPIO 63 as HDMI hot-plug-detect. Configure
this GPIO in the board files.
Backported from aa74274b464d4aa24703963ac89a0ee942d5d267
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|
A hardware bug in the OMAP4 HDMI PHY may cause physical damage to the
board if the HDMI PHY is already enabled when the HDMI cable is plugged
in. The possible damage breaks HDMI output, otherwise the board is
unaffected.
This patch solves the problem by adding hot-plug-detection into the HDMI
IP
From: Rob Clark r...@ti.com
The OMAPDSS: HDMI: PHY burnout fix commit switched the HDMI driver
over to using a GPIO for plug detect. Unfortunately the -detect()
method was not also updated, causing HDMI to no longer work for the
omapdrm driver (because it would actually check if a connection was
hdmi_hpd pin is muxed to INPUT and PULLUP, but the pin is not
currently used, and in the future when it is used, the pin is used as a
GPIO and is board specific, not an OMAP4 wide thing.
So remove the muxing for now.
Backported from 7bb122d155f742fe2d79849090c825be7b4a247e
Signed-off-by: Tomi
The HDMI GPIO pins LS_OE and CT_CP_HPD are not currently configured.
This patch configures them as output pins.
Backported from 78a1ad8f12db70b8b0a4548b90704de08ee216ce
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
This series is for 3.0 stable.
The main patch in this set is the PHY burnout fix, which implements a fix for
a hardware bug in the OMAP4 HDMI PHY which may cause physical damage to the
board if the HDMI PHY is already enabled when the HDMI cable is plugged in. The
possible damage breaks HDMI
Use default regn and regm2 dividers in the hdmi driver if the board file
does not define them.
Pandaboard's board file was missing the dividers, causing HDMI output
not to work, so this patch fixes the problem.
Backported from 8d88767a4377171752c22ac39bcb2b505eb751da
Cc: Mythri P K
Instead of freeing the GPIOs individually, use gpio_free_array().
Backported from 575753e3bea3b67eef8e454fb87f719e3f7da599
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|3 +--
hdmi_hpd pin is muxed to INPUT and PULLUP, but the pin is not
currently used, and in the future when it is used, the pin is used as a
GPIO and is board specific, not an OMAP4 wide thing.
So remove the muxing for now.
Backported from 7bb122d155f742fe2d79849090c825be7b4a247e
Signed-off-by: Tomi
The GPIO 60 on 4430sdp and Panda is not HPD GPIO, as currently marked in
the board files, but CT_CP_HPD, which is used to enable/disable HPD
functionality.
This patch renames the GPIO.
Backported from 3932a32fcf5393f8be70ac99dc718ad7ad0a415b
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Both Panda and 4430SDP use GPIO 63 as HDMI hot-plug-detect. Configure
this GPIO in the board files.
Backported from aa74274b464d4aa24703963ac89a0ee942d5d267
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c|
A hardware bug in the OMAP4 HDMI PHY may cause physical damage to the
board if the HDMI PHY is already enabled when the HDMI cable is plugged
in. The possible damage breaks HDMI output, otherwise the board is
unaffected.
This patch solves the problem by adding hot-plug-detection into the HDMI
IP
The HDMI GPIO pins LS_OE and CT_CP_HPD are not currently configured.
This patch configures them as output pins.
Backported from 78a1ad8f12db70b8b0a4548b90704de08ee216ce
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
On Wed, Feb 29, 2012 at 12:47 PM, Adrian Hunter adrian.hun...@intel.com wrote:
Most parts of the enable / disable API are no longer used and
can be removed.
Cc: Rajendra Nayak rna...@ti.com
Cc: Venkatraman S svenk...@ti.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Thomas Abraham
This is useful when we have broken type2 compliant IPs' where
the softreset shift is not the same as SYSC_TYPE2_SOFTRESET_SHIFT
and hence is overridden using sysc_fields-srst_shift.
We have atleast one such instance now with onchip keypad on OMAP5
which has a different softreset shift as compared
On 3/1/2012 2:47 PM, Rajendra Nayak wrote:
This is useful when we have broken type2 compliant IPs' where
the softreset shift is not the same as SYSC_TYPE2_SOFTRESET_SHIFT
and hence is overridden using sysc_fields-srst_shift.
We have atleast one such instance now with onchip keypad on OMAP5
* Shilimkar, Santosh santosh.shilim...@ti.com [120301 00:38]:
On Wed, Feb 29, 2012 at 11:07 PM, Tony Lindgren t...@atomide.com wrote:
Hi Santosh,
Looks like OMAP4_ERRATA_I688 still has one more issue:
Modules won't build at least with the attached randconfig
generated file.
Can you
Hi Ohad,
On Monday 27 February 2012 09:00:51 Ohad Ben-Cohen wrote:
On Mon, Feb 27, 2012 at 12:47 AM, Laurent Pinchart wrote:
I'm asking about the probe deferral mechanism. The omap3-isp driver will
still call iommu_attach_device() in its probe function. What will happen
then ? Will it
Hi Laurent,
On Thu, Mar 1, 2012 at 6:37 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
I'll try that then. How expensive is the iommu_attach_device() (and detach)
operation in terms of CPU time ?
omap_iommu_attach() basically enables the iommu clock and configures
that IP block.
We have resolved our issue with the help of PaulM at TI. The driver does work,
the trouble was with the way the data was being masked in the buffer. We
posted a detailed explanation on the E2E forum (link above) that you may review
if interested. Thanks.
--
To unsubscribe from this list:
* With certain SD cards timeouts like the following have been seen
due to an improper calculation of the dto value:
mmcblk0: error -110 transferring data, sector 4126233, nr 8,
card status 0xc00
* By removing the dto calculation and setting the timeout value
to the maximum specified by
Hi all,
Looks like we need one fix to what's currently queued up in
dt-part2 branch for omaps. And we can make board-generic more
readable by cutting down the ifdefs.
Regards,
Tony
---
Tony Lindgren (2):
ARM: OMAP2+: Fix build error when only ARCH_OMAP2/3 or 4 is selected
ARM:
Otherwise we'll get undefined reference to `gic_of_init' or
undefined reference to `omap_intc_of_init'.
This was caused by commit fbf75da733e82bb17a01e1b907b0e40d9c028823
(ARM: OMAP2+: board-generic: Use of_irq_init API).
Signed-off-by: Tony Lindgren t...@atomide.com
---
We need just one ifdef for each ARCH_OMAP2/3/4.
Also remove the comment about i2c twl driver as it's
pretty obvious that we still need some platform data
until drivers are converted to device tree.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c | 76
Hi all,
This series adds gpio_find_by_name() that allows finding
GPIOs on specific gpio_chips. As the GPIO numbers can be
dynamic, it's hard to find the GPIO numbers from drivers
using them directly.
So far we've dealt with this using platform specific callbacks,
but that is messy. This series
Currently there is no way for drivers to request a GPIO on a particular
gpio chip. This makes it hard to support multiple GPIO controllers
with dynamic GPIO and interrupt numbering, such as with CONFIG_SPARSE_IRQ.
Make it easier for device drivers to find GPIOs on a specific gpio_chip
by adding
We can now remove the setting of GPIO pins with callbacks
as the drivers can access a GPIO offset on a named gpio_chip
directly with gpio_find_by_chip_name().
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-3430sdp.c | 13
There's no need to use callbacks for this, we can
do it directly between MMC driver and twl6030.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Chris Ball c...@laptop.org
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-4430sdp.c| 45
Use gpio_find_by_chip_name() to find the GPIO pins as they can
be dynamically allocated on various gpio_chips.
Note that we don't want to touch the platform data as it can
now specify the GPIO offset on a named gpio_chip.
This removes the need to use callbacks to set the GPIO pins
in platform
* Rajendra Nayak rna...@ti.com [120224 20:14]:
On Saturday 25 February 2012 06:03 AM, Tony Lindgren wrote:
Hi,
* Rajendra Nayakrna...@ti.com [120224 01:27]:
omap_hsmmc_late_init() adds deferred (if any) mmc devices which are
dependent on twl4030-gpio device to be available.
If
Hello,
I have a variscite OM44 (omap4 4460 SOM) that I need to rotate the
display on but I cannot make it work.
I am currently using kernel 3.1.5 and the Ubuntu 11.10 from Linaro.
I have tried each of these ways to make it work:
1. From the command line as root the command 'xrandr -o left'
Afzal Mohammed af...@ti.com writes:
Specify voltage in ranges for regulator. Range
used is tolerance specified for OPP.
This helps to achieve DVFS with a wider range of
regulators.
Cc: Kevin Hilman khil...@ti.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Matt Porter mpor...@ti.com writes:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter mpor...@ti.com
[...]
Hello Deepthi,
On Wed, Feb 29, 2012 at 10:15 PM, Deepthi Dharwar
deep...@linux.vnet.ibm.com wrote:
Hi Rob,
On 03/01/2012 06:12 AM, Robert Lee wrote:
Make necessary changes to implement time keeping and irq enabling
in the core cpuidle code. This will allow the removal of these
Hi,
On Thu, Mar 01, 2012 at 12:36:57PM -0800, Kevin Hilman wrote:
Matt Porter mpor...@ti.com writes:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and
On Wed, Feb 29, 2012 at 6:42 PM, Robert Lee rob@linaro.org wrote:
This patch series moves various functionality duplicated in platform
cpuidle drivers to the core cpuidle driver. Also, the platform irq
disabling was removed as it appears that all calls into
cpuidle_call_idle will have
I'm seeing weird read errors on a DM3730. Has anyone seen anything like
this before?
Environment:
factory images from
http://cumulus.gumstix.org/images/angstrom/factory/2011-08-30-1058/
loaded onto and MMC card on a
Gumstix WaterStorm on a Chestnut board
Commands:
dd if=/dev/urandom
+Tero
Kevin Hilman khil...@ti.com writes:
Afzal Mohammed af...@ti.com writes:
Specify voltage in ranges for regulator. Range
used is tolerance specified for OPP.
This helps to achieve DVFS with a wider range of
regulators.
Cc: Kevin Hilman khil...@ti.com
Cc: Sekhar Nori nsek...@ti.com
On Wed, 29 Feb 2012 13:13:31 Tony Lindgren wrote:
* Arnd Bergmann a...@arndb.de [120229 12:35]:
On Wednesday 29 February 2012, Tony Lindgren wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
omap1
Janusz Krzysztofik (7):
ARM: OMAP1: ams-delta: register
Rajendra Nayak rna...@ti.com writes:
On Wednesday 29 February 2012 07:56 PM, Tero Kristo wrote:
From: Vishwanath BSvishwanath...@ti.com
Enable IO Wake up for OMAP3 as part of PM Init. Currently this has been
managed in cpuidle path which is not the right place. Subsequent patch
will remove
We have both a CompuLab CM-T3517 and a Technexion TAM-3517 at the shop. Both
boards provide dual Ethernet support in an identical fashion. One port uses
the onboard EMAC tied to an SMSC LAN87xx series PHY. The other is the old
trusty SMSC LAN911X hooked up to the GPMC.
Both boards support
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [120301 13:56]:
Any chance for the continuation series [1] as well as two section
mismatch related fixes [2] [3] getting your attention? NB, that
continuation series needs another section mismatch fix, which I was
planing to submit once there was
* Felipe Balbi ba...@ti.com [120223 00:15]:
Hi,
On Wed, Feb 22, 2012 at 02:09:37PM -0800, Tony Lindgren wrote:
From 54c4785b8d274f8d282b4243945ae0b17edf4686 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Wed, 22 Feb 2012 13:03:07 -0800
Subject: [PATCH] cbus: Fix
Hi,
* Daniel Mack zon...@gmail.com [120217 05:13]:
ping? Could anyone care for queueing this please?
I suggest Rajendra queue up omap_hsmmc.c patches as he's already
patching it.
Regards,
Tony
On Thu, Dec 29, 2011 at 2:22 PM, Daniel Mack zon...@gmail.com wrote:
On 12/23/2011 04:40 PM,
On Wed, Feb 29, 2012 at 22:23, Paul Walmsley p...@pwsan.com wrote:
b/arch/arm/mach-omap2/powerdomain.c
index 8a18d1b..89000d3 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -339,8 +339,8 @@ int pwrdm_add_clkdm(struct powerdomain *pwrdm, struct
On Thu, 1 Mar 2012, Rajendra Nayak wrote:
This is useful when we have broken type2 compliant IPs' where
the softreset shift is not the same as SYSC_TYPE2_SOFTRESET_SHIFT
and hence is overridden using sysc_fields-srst_shift.
We have atleast one such instance now with onchip keypad on OMAP5
From: Jon Hunter jon-hun...@ti.com
Here are a couple minor OMAP3+ fixes I stumbled across.
Jon Hunter (2):
ARM: OMAP: DMA: Fix DMA channel end definition for OMAP36xx-PLUS
devices
ARM: OMAP: Remove definition cpu_is_omap4430()
arch/arm/mach-omap2/dma.c |4 ++--
From: Jon Hunter jon-hun...@ti.com
I recently noticed there are a couple bugs in the OMAP2-PLUS DMA driver code.
1. The CCDN DMA register is valid for all OMAP devices from OMAP3630 onwards.
For OMAP3630+ devices the CCDN register is the upper register in the DMA
register map and so is
From: Jon Hunter jon-hun...@ti.com
The definition cpu_is_omap4430() always returns 0 even when CONFIG_ARCH_OMAP4
is enabled. This macro should be removed and the macro cpu_is_omap443x() should
be used where needed for OMAP4430 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Hi
On Thu, 1 Mar 2012, Hiremath, Vaibhav wrote:
I am not sure whether we access these bits explicitly. If I understand
correctly, API's which access these bits are not being called from
anywhere, For example,
omap4_pwrdm_read_mem_retst
omap4_pwrdm_set_mem_retst
On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
Use gpio_find_by_chip_name() to find the GPIO pins as they can
be dynamically allocated on various gpio_chips.
Note that we don't want to touch the platform data as it can
now specify the GPIO offset on a named gpio_chip.
This removes the
Tested on Samsung-SoC
Tested-by: Jaehoon Chung jh80.ch...@samsung.com
On 02/29/2012 04:17 PM, Adrian Hunter wrote:
Most parts of the enable / disable API are no longer used and
can be removed.
Cc: Rajendra Nayak rna...@ti.com
Cc: Venkatraman S svenk...@ti.com
Cc: Kukjin Kim
On Fri, Mar 02, 2012 at 11:19:40, Paul Walmsley wrote:
Hi
On Thu, 1 Mar 2012, Hiremath, Vaibhav wrote:
I am not sure whether we access these bits explicitly. If I understand
correctly, API's which access these bits are not being called from
anywhere, For example,
On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
We can now remove the setting of GPIO pins with callbacks
as the drivers can access a GPIO offset on a named gpio_chip
directly with gpio_find_by_chip_name().
Cc: Rajendra Nayakrna...@ti.com
Signed-off-by: Tony Lindgrent...@atomide.com
---
On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
There's no need to use callbacks for this, we can
do it directly between MMC driver and twl6030.
Cc: Samuel Ortizsa...@linux.intel.com
Cc: Chris Ballc...@laptop.org
Cc: Rajendra Nayakrna...@ti.com
Signed-off-by: Tony
Hi,
On Thu, 1 Mar 2012, Hiremath, Vaibhav wrote:
The initialization used in the patch is correct. Unfortunately, the TRM
is incorrect here. I have already raised this issue with respective
folks and soon it will get corrected.
thanks for looking into this. Could you add a brief comment or
On Fri, Mar 02, 2012 at 12:02:31, Paul Walmsley wrote:
Hi,
On Thu, 1 Mar 2012, Hiremath, Vaibhav wrote:
The initialization used in the patch is correct. Unfortunately, the TRM
is incorrect here. I have already raised this issue with respective
folks and soon it will get corrected.
+Chris queues all MMC patches including omap_hsmmc.
Ping ?
On Fri, Mar 2, 2012 at 5:41 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
* Daniel Mack zon...@gmail.com [120217 05:13]:
ping? Could anyone care for queueing this please?
I suggest Rajendra queue up omap_hsmmc.c patches as he's
On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
Use gpio_find_by_chip_name() to find the GPIO pins as they can
be dynamically allocated on various gpio_chips.
Note that we don't want to touch the platform data as it can
now specify the GPIO offset on a named gpio_chip.
This removes the
87 matches
Mail list logo
