I am trying to get the full-speed USB host working on an custom AM3517
device with the 3.18.12 kernel. The hardware works (a 2.6.37 kernel has
been used for testing).
Does anyone have any experience of 3.18 (or similarly recent kernel on
an AM3517 system) or have any pointers as where to start
On 21/05/15 06:06, Paul Walmsley wrote:
Enable falls under the critical clocks discussion that is ongoing. I
assume that this is some sort of critical clock that can't be turned off?
It only needs to be enabled for this particular display IP subsystem to
function:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22/05/15 16:50, Felipe Balbi wrote:
Hi,
On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
I am trying to get the full-speed USB host working on an custom
AM3517 device with the 3.18.12 kernel. The hardware works (a
2.6.37 kernel
Allow users of remoteproc the ability to get a handle to an rproc by
passing a phandle supplied in the user's device tree node. This is
useful in situations that require manual booting of the rproc.
This patch uses the code removed by commit 40e575b1d0b3 (remoteproc:
remove the get_by_name/put
Hi,
This patch series is v4 of the series to add a wkup_m3_rproc driver
for TI AM335xi and AM437x SoCs. This family of SoCs contains an ARM
Cortex M3 coprocessor that is responsible for low-level power tasks
that cannot be handled by the main ARM Cortex A8 so firmware running
from the CM3 can be
Hi,
On Fri, May 22, 2015 at 11:13:22PM +0300, Ben Dooks wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22/05/15 16:50, Felipe Balbi wrote:
Hi,
On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
I am trying to get the full-speed USB host working on an custom
The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap
tags/omap-for-v4.2/dt-pt1
for you to fetch changes up to
From: Suman Anna s-a...@ti.com
The rproc_da_to_va API is currently used to perform any device to
kernel address translations to meet the different needs of the remoteproc
core/drivers (eg: loading). The functionality is achieved within the
remoteproc core, and is limited only for carveouts
Add a remoteproc driver to load the firmware and boot a small
Wakeup M3 processor present on TI AM33xx and AM43xx SoCs. This
Wakeup M3 remote processor is an integrated Cortex M3 that allows
the SoC to enter the lowest possible power state by taking control
from the MPU after it has gone into its
Add the device tree bindings document for the TI Wakeup M3 remote
processor devices on AM33xx and AM43xx SoCs. These devices are used
to offload low-level power management functionality, and are handled
by the wkup_m3 remoteproc driver.
Signed-off-by: Suman Anna s-a...@ti.com
Signed-off-by: Dave
Roger,
On Wednesday 20 May 2015 07:17 PM, Roger Quadros wrote:
Kishon,
On 20/05/15 16:19, Kishon Vijay Abraham I wrote:
Hi Roger,
On Tuesday 12 May 2015 09:37 PM, Roger Quadros wrote:
SATA_PLL_SOFT_RESET bit of CTRL_CORE_SMA_SW_0 must be toggled
between a SATA DPLL unlock and re-lock to
From: Yegor Yefremov yegorsli...@googlemail.com
This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI
signals.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
.../devicetree/bindings/serial/omap_serial.txt |9 +
drivers/tty/serial/Kconfig
On Thu, May 21, 2015 at 06:48:33PM -0500, Michael Welling wrote:
So after reverting this patch I found there is a issue in that it is difficult
to determine when a transfer is complete to properly drive the chipselect from
within the transfer_one function.
Is unprepare_message() a suitable
Hi,
On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
I am trying to get the full-speed USB host working on an custom AM3517
device with the 3.18.12 kernel. The hardware works (a 2.6.37 kernel has
been used for testing).
Does anyone have any experience of 3.18 (or similarly recent
Kishon,
On 22/05/15 14:34, Kishon Vijay Abraham I wrote:
Roger,
On Wednesday 20 May 2015 07:17 PM, Roger Quadros wrote:
Kishon,
On 20/05/15 16:19, Kishon Vijay Abraham I wrote:
Hi Roger,
On Tuesday 12 May 2015 09:37 PM, Roger Quadros wrote:
SATA_PLL_SOFT_RESET bit of CTRL_CORE_SMA_SW_0
On Thursday 21 May 2015 15:59:38 Tony Lindgren wrote:
Here's this pull request updated for the randconfig errors found
by Arnd.
The following changes since commit 030bbdbf4c833bc69f502eae58498bc5572db736:
Linux 4.1-rc3 (2015-05-10 15:12:29 -0700)
are available in the git repository
The omap_gpio_irq_type() can do only configuration of GPIO IRQ
triggering type, because now OMAP GPIO driver has implemented
.irq_startup()/.irq_shutdown() which are responsible for
GPIO bank enabling and pin direction configuration.
Hence, remove redundant code and omap_gpio_init_irq() which is
This patch fixes following issue:
- GPIOn is used as IRQ by some dev, for example PCF8575.INT - gpio6.11
- PCFx driver knows nothing about type of IRQ line (GPIO or not)
so it doesn't request gpio and just do request_irq()
- If gpio6.11 will be exported through the sysfs and then un-xeported
The GPIO Chip and GPIO IRQ Chip functionality are essentially orthogonal,
so GPIO Chip implementation shouldn't touch GPIO IRQ specific registers
and vise versa.
Hence, rework omap_gpio_request:
- don't reset GPIO IRQ triggering type to IRQ_TYPE_NONE, because
GPIO irqchip should be responsible
Now there are some points related to Runtime PM usage:
1) bank state doesn't need to be checked in places where
Rintime PM is used, bacause Runtime PM maintains its
own usage counter:
if (!BANK_USED(bank))
pm_runtime_get_sync(bank-dev);
so, it's safe to drop such checks.
2)
The omap_gpio_irq_startup() can be called at time when:
- corresponding GPIO has been requested already and in this case
it has to be configured as input already. If not - return with -EINVAL
and do not try to re-configure it as it could be unsafe.
- corresponding GPIO is free: reconfigure GPIO as
The h3 LCD driver fails to link when tps65010 is configured
as a loadable module:
drivers/built-in.o: In function `h3_panel_disable':
debugfs.c:(.text+0x206ac): undefined reference to `tps65010_set_gpio_out_value'
debugfs.c:(.text+0x206cc): undefined reference to `tps65010_set_gpio_out_value'
Hi Tony,
As I promised in [1] I've prepared a new series for OMAP GPIO driver.
Patches 1-2 are bug fixes.
Patches 3-6 is attempt (RFC/RFT) to rework OMAP GPIO driver taking into account
that GPIO Chip and GPIO IRQ Chip functionality are mostly orthogonal.
Patch 7 is second attempt (RFC/RFT) to
The GPIO Chip and GPIO IRQ Chip functionality are essentially orthogonal,
so GPIO IRQ Chip implementation shouldn't touch GPIO specific
registers and vise versa.
Hence, rework omap_gpio_irq_shutdown and try to touch only irqs specific
registers:
- don't configure GPIO as input (it, actually,
The GPIO bank will be kept powered in case if input parameters
are invalid or error occurred in omap_gpio_irq_type.
Hence, fix it by ensuring that GPIO bank will be unpowered
in case of errors and add additional check of value returned
from omap_set_gpio_triggering().
Signed-off-by: Grygorii
On Wednesday 20 May 2015 15:36:04 Tony Lindgren wrote:
Clean-up for omaps for v4.2 merge window:
Drop more omap3 legacy board-*.c files for v4.2. This time we're
dropping the board files for beagle, overo and cm-t35.
The reason for dropping these now rather than later is that now
we can
On 05/22/2015 07:16 AM, yegorsli...@googlemail.com wrote:
From: Yegor Yefremov yegorsli...@googlemail.com
This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI
signals.
Signed-off-by: Yegor Yefremov yegorsli...@googlemail.com
---
* Nishanth Menon n...@ti.com [150522 08:36]:
On 05/22/2015 07:16 AM, yegorsli...@googlemail.com wrote:
From: Yegor Yefremov yegorsli...@googlemail.com
This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI
signals.
Signed-off-by: Yegor Yefremov
On Fri, May 22, 2015 at 01:25:44PM +0100, Mark Brown wrote:
On Thu, May 21, 2015 at 06:48:33PM -0500, Michael Welling wrote:
So after reverting this patch I found there is a issue in that it is
difficult
to determine when a transfer is complete to properly drive the chipselect
from
* Grygorii Strashko grygorii.stras...@linaro.org [150522 07:37]:
Hi Tony,
As I promised in [1] I've prepared a new series for OMAP GPIO driver.
Great!
Patches 1-2 are bug fixes.
Patches 3-6 is attempt (RFC/RFT) to rework OMAP GPIO driver taking into
account
that GPIO Chip and GPIO
Hi,
* Grygorii Strashko grygorii.stras...@linaro.org [150522 07:37]:
The omap_gpio_irq_type() can do only configuration of GPIO IRQ
triggering type, because now OMAP GPIO driver has implemented
.irq_startup()/.irq_shutdown() which are responsible for
GPIO bank enabling and pin direction
On Fri, May 22, 2015 at 08:16:47PM +0200, Uwe Kleine-König wrote:
On Fri, Apr 24, 2015 at 11:18:40AM +0200, Uwe Kleine-König wrote:
[dropped Varadarajan Charulatha and Shubhrajyoti D from the addressees
because the ti mailserver doesn't know them :-(, added Felipe instead]
On Thu, Apr
On Fri, May 22, 2015 at 09:52:13AM -0700, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [150522 08:36]:
On 05/22/2015 07:16 AM, yegorsli...@googlemail.com wrote:
From: Yegor Yefremov yegorsli...@googlemail.com
This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI
* Felipe Balbi ba...@ti.com [150522 10:41]:
On Fri, May 22, 2015 at 09:52:13AM -0700, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [150522 08:36]:
On 05/22/2015 07:16 AM, yegorsli...@googlemail.com wrote:
From: Yegor Yefremov yegorsli...@googlemail.com
This patch permits to
Not tainted
4.1.0-rc4-next-20150522-00021-g6d8613e #94
[6.182800] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[6.189422] task: c09b0678 ti: c09aa000 task.ti: c09aa000
[6.195129] PC is at omap_gpio_irq_handler+0x9c/0x234
[6.200469] LR is at trace_hardirqs_off+0x14/0x18
35 matches
Mail list logo
