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 c
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
Signed-off-by: Dave Gerlach
Acked
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 o
From: Suman Anna
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 allocated within the
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 AP
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 us
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 52dfcbfc94
-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
* Grygorii Strashko [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 IRQ Chip functionality
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
6.165496] Internal error: : 1028 [#1] SMP ARM
[6.170288] Modules linked in:
[6.173522] CPU: 0 PID: 0 Comm: swapper/0 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 ta
* Felipe Balbi [150522 10:41]:
> On Fri, May 22, 2015 at 09:52:13AM -0700, Tony Lindgren wrote:
> > * Nishanth Menon [150522 08:36]:
> > > On 05/22/2015 07:16 AM, yegorsli...@googlemail.com wrote:
> > > > From: Yegor Yefremov
> > > >
> > > > This patch permits to use GPIOs to control the CTS/RT
Hi,
* Grygorii Strashko [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 configuration.
>
> Hence, rem
On Fri, May 22, 2015 at 09:52:13AM -0700, Tony Lindgren wrote:
> * Nishanth Menon [150522 08:36]:
> > On 05/22/2015 07:16 AM, yegorsli...@googlemail.com wrote:
> > > From: Yegor Yefremov
> > >
> > > This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI
> > > signals.
> > >
> > >
* Nishanth Menon [150522 08:36]:
> On 05/22/2015 07:16 AM, yegorsli...@googlemail.com wrote:
> > From: Yegor Yefremov
> >
> > This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI
> > signals.
> >
> > Signed-off-by: Yegor Yefremov
> > ---
> > .../devicetree/bindings/serial/oma
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
>
On 05/22/2015 07:16 AM, yegorsli...@googlemail.com wrote:
> From: Yegor Yefremov
>
> This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI
> signals.
>
> Signed-off-by: Yegor Yefremov
> ---
> .../devicetree/bindings/serial/omap_serial.txt |9 +
> drivers/tty/serial/Kcon
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
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 f
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
th
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 reposi
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
n
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) S
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 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 Stra
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, shoul
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 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'
driv
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 mus
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 rec
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
From: Yegor Yefremov
This patch permits to use GPIOs to control the CTS/RTS/DTR/DSR/DCD/RI
signals.
Signed-off-by: Yegor Yefremov
---
.../devicetree/bindings/serial/omap_serial.txt |9 +
drivers/tty/serial/Kconfig |1 +
drivers/tty/serial/omap-serial.c
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 prev
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 deb
34 matches
Mail list logo
