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 n
+Chris queues all MMC patches including omap_hsmmc.
Ping ?
On Fri, Mar 2, 2012 at 5:41 AM, Tony Lindgren wrote:
> Hi,
>
> * Daniel Mack [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.
>
> Re
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 corr
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
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 Ortiz
Cc: Chris Ball
Cc: Rajendra Nayak
Signed-off-by: Tony Lindgren
---
[..]
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
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 Nayak
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-34
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,
> >
> >
Tested on Samsung-SoC
Tested-by: Jaehoon Chung
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
> Cc: Venkatraman S
> Cc: Kukjin Kim
> Cc: Thomas Abraham
> Cc: Kyungmin Park
> Cc: Sekhar Nor
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 n
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
>
From: Jon Hunter
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
---
arch/arm/plat-omap/include/plat/cpu.h |2 -
From: Jon Hunter
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 used to define the ch
From: Jon Hunter
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 ++--
arch/arm/plat-omap/include
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 OM
On Wed, Feb 29, 2012 at 22:23, Paul Walmsley 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
> clockdomain *c
Hi,
* Daniel Mack [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 wrote:
> > On 12/23/2011 04:40 PM, T Krishnamoorthy, Balaji wrot
* Felipe Balbi [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
> > Date: Wed, 22 Feb 2012 13:03:07 -0800
> > Subject: [PATCH] cbus: Fix lines for Nokia 770
* Janusz Krzysztofik [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 a stable base fo
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 bo
Rajendra Nayak writes:
> On Wednesday 29 February 2012 07:56 PM, Tero Kristo wrote:
>> From: Vishwanath BS
>>
>> 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 IO Daisy chain handling
On Wed, 29 Feb 2012 13:13:31 Tony Lindgren wrote:
> * Arnd Bergmann [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: registe
+Tero
Kevin Hilman writes:
> Afzal Mohammed 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
>> Cc: Sekhar Nori
>> Signed-off-by: Afzal Mohammed
>
>
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
On Wed, Feb 29, 2012 at 6:42 PM, Robert Lee 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 already called loca
Hi,
On Thu, Mar 01, 2012 at 12:36:57PM -0800, Kevin Hilman wrote:
> Matt Porter 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 vddva
Hello Deepthi,
On Wed, Feb 29, 2012 at 10:15 PM, Deepthi Dharwar
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
>> functionalities from various
Matt Porter 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
[...]
> /*
> * Initialize sm
Afzal Mohammed 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
> Cc: Sekhar Nori
> Signed-off-by: Afzal Mohammed
Thanks, will queue this with the CPUfreq cha
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'
T
* Rajendra Nayak [120224 20:14]:
> On Saturday 25 February 2012 06:03 AM, Tony Lindgren wrote:
> >Hi,
> >
> >* Rajendra Nayak [120224 01:27]:
> >>omap_hsmmc_late_init() adds deferred (if any) mmc devices which are
> >>dependent on twl4030-gpio device to be available.
> >>If twl4030-gpio is built
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 dat
There's no need to use callbacks for this, we can
do it directly between MMC driver and twl6030.
Cc: Samuel Ortiz
Cc: Chris Ball
Cc: Rajendra Nayak
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c| 45 +---
arch/arm/mach-omap2/board-omap4panda
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
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-3430sdp.c | 13 -
arch/arm/mach-oma
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 tw
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 re
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
---
arch/arm/mach-omap2/board-generic.c | 76 +++
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
---
arch/arm/mach-omap2/board-generic.c |
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: OMAP
* 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
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: s
Hi Laurent,
On Thu, Mar 1, 2012 at 6:37 PM, Laurent Pinchart
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.
I suspect it's negligible but
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 i
* Shilimkar, Santosh [120301 00:38]:
> On Wed, Feb 29, 2012 at 11:07 PM, Tony Lindgren 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
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
Ni
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 Wed, Feb 29, 2012 at 12:47 PM, Adrian Hunter wrote:
> Most parts of the enable / disable API are no longer used and
> can be removed.
>
> Cc: Rajendra Nayak
> Cc: Venkatraman S
> Cc: Kukjin Kim
> Cc: Thomas Abraham
> Cc: Kyungmin Park
> Cc: Sekhar Nori
> Cc: Kevin Hilman
> Signed-off-by:
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
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|3 +++
arch/arm/mach-om
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 d
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
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|3 +++
arch/arm/mach-omap2/board-om
"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
Acked-by: Tony Lindgren
Instead of freeing the GPIOs individually, use gpio_free_array().
Backported from 575753e3bea3b67eef8e454fb87f719e3f7da599
Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|3 +--
arch/arm/mach-omap2/board-omap4panda.c |3 +--
2 files cha
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
Acked-by: To
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 out
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
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|3 +++
arch/arm/mach-om
"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
From: Rob Clark
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
detected
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 d
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
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|3 +++
arch/arm/mach-omap2/board-om
Instead of freeing the GPIOs individually, use gpio_free_array().
Backported from 575753e3bea3b67eef8e454fb87f719e3f7da599
Signed-off-by: Tomi Valkeinen
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/board-4430sdp.c|3 +--
arch/arm/mach-omap2/board-omap4panda.c |3 +--
2 files cha
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
Acked-by: Tony Lindgren
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 boar
Hi,
On Thu, 2012-03-01 at 13:44 +0530, mythr...@ti.com wrote:
> From: Mythri P K
>
> 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.
On Sat, Feb 4, 2012 at 7:43 PM, Grazvydas Ignotas 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 needed to solv
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 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_part
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 Nayak
Cc: Venkatraman S
Cc: Kukjin Kim
Cc: Thomas Abraham
Cc: Kyungmin Par
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 a
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
Add support for the EMAC Ethernet controller in the AM35xx SoC.
Signed-off-by: Igor Grinberg
---
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
b/arch/arm/mach-omap2/board-cm-t3517.c
index f36d6
From: Ilya Yanok
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
Signed-off-by: Igor Grinberg
---
v3:
On Wed, Feb 29, 2012 at 11:07 PM, Tony Lindgren 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 should be an
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 BS
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File.
Signed-off-by:
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 BS
> >
> > Since IO Daisychain modifies only PRM registers, it makes sense to move
> > it to PRM File.
> >
> > Signed-off-by: Vishwanath BS
> > Tested-by: Govin
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 BS
> >
> > 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
>
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
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 Nayak
>> Cc: Venkatraman S
>> Cc: Kukjin Kim
>> Cc: Thomas Abraham
>> Cc: Kyungmin Park
>> Cc: Sekhar Nori
From: Mythri P K
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 damage the HDMI
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 pa
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 re
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 Ben-
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
Cc: Brian Swetland
Cc: Iliyan Malchev
Cc: Arnd Bergmann
Cc: Grant L
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 ac
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 dif
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 re
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 e
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 Nayak
Cc: Venkatraman S
Cc: Kukjin Kim
Cc: Thomas Abraham
Cc: Kyungmin Park
Cc: Sekhar Nori
Cc: Kevin Hilman
Signed-off-by: Adrian Hunter
---
arch/arm/mach-exy
87 matches
Mail list logo
