On 04/09/2014 06:19 PM, Nishanth Menon wrote:
On 04/09/2014 10:16 AM, Roger Quadros wrote:
OMAP3 doesn't contain l3_init_clkdm clock domain. Use the
proper clock domains for USB Host and USB TLL modules.
Gets rid of the following warnings during boot
omap_hwmod: usb_host_hs: could not
OMAP3 doesn't contain l3_init_clkdm clock domain. Use the
proper clock domains for USB Host and USB TLL modules.
Gets rid of the following warnings during boot
omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
On Wed, Apr 9, 2014 at 3:20 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
In the kernel there are basically two patterns to implement object
oriented code in C. You can either embedded a set of function pointers
s/embedded/embed
in a struct along with other members or
On 10/04/2014 at 08:15:49 +0900, Simon Horman wrote :
On Wed, Apr 09, 2014 at 08:04:09PM +0200, Alexandre Belloni wrote:
Now that the PWM core is able to set the period and polarity based on
the lookup table, add those to PWM_LOOKUP to ease their usage.
I would prefer if this change was
From: Sergei Shtylyov
It doesn't do any pin muxing. It switches SoC internal USB signals between
USB controllers. The pins remain the same.
Doesn't something like that already happen for the companion USB1
controllers for USB2 ports?
That also doesn't sound like you are changing the PHY.
Hello Alexandre,
Thanks a lot for your feedback.
On 04/10/2014 09:36 AM, Alexandre Courbot wrote:
On Wed, Apr 9, 2014 at 3:20 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
In the kernel there are basically two patterns to implement object
oriented code in C. You can
On 10-04-2014 13:20, David Laight wrote:
It doesn't do any pin muxing. It switches SoC internal USB signals between
USB controllers. The pins remain the same.
Doesn't something like that already happen for the companion USB1
controllers for USB2 ports?
Did you mean USB 1.1 and USB
On 10/04/14 11:49, Sergei Shtylyov wrote:
On 10-04-2014 13:20, David Laight wrote:
It doesn't do any pin muxing. It switches SoC internal USB
signals between
USB controllers. The pins remain the same.
Doesn't something like that already happen for the companion USB1
controllers for
On Thu, 2014-04-10 at 11:34 +0200, Javier Martinez Canillas wrote:
On 04/10/2014 09:36 AM, Alexandre Courbot wrote:
Since having the operations maybe?
Yes, since I'm not a native english speaker I sometimes miss some obvious
grammatical errors. I'll fix those when posting the final
From: Ben Dooks
On 10/04/14 11:49, Sergei Shtylyov wrote:
On 10-04-2014 13:20, David Laight wrote:
It doesn't do any pin muxing. It switches SoC internal USB
signals between
USB controllers. The pins remain the same.
Doesn't something like that already happen for the companion
On 10/04/14 12:14, David Laight wrote:
From: Ben Dooks
On 10/04/14 11:49, Sergei Shtylyov wrote:
On 10-04-2014 13:20, David Laight wrote:
It doesn't do any pin muxing. It switches SoC internal USB
signals between
USB controllers. The pins remain the same.
Doesn't something like that
Hello Andy,
On Thu, Apr 10, 2014 at 1:00 PM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
On Thu, 2014-04-10 at 11:34 +0200, Javier Martinez Canillas wrote:
On 04/10/2014 09:36 AM, Alexandre Courbot wrote:
Since having the operations maybe?
Yes, since I'm not a native
On Wednesday 09 April 2014 09:53 PM, Russell King - ARM Linux wrote:
On Tue, Apr 08, 2014 at 08:23:39PM +0530, Sekhar Nori wrote:
On Friday 04 April 2014 03:48 PM, Russell King - ARM Linux wrote:
On Fri, Apr 04, 2014 at 03:40:29PM +0530, Sekhar Nori wrote:
diff --git
On Thu, Apr 10, 2014 at 05:26:15PM +0530, Sekhar Nori wrote:
On Wednesday 09 April 2014 09:53 PM, Russell King - ARM Linux wrote:
That is required because as part of the enable sequence, we write to the
lockdown registers to clear out anything that may be there before we
enable the L2
On Wednesday 09 April 2014 10:22 PM, Santosh Shilimkar wrote:
On Wednesday 09 April 2014 12:33 PM, Russell King - ARM Linux wrote:
On Tue, Apr 08, 2014 at 11:17:17AM -0400, Santosh Shilimkar wrote:
On Tuesday 08 April 2014 10:53 AM, Sekhar Nori wrote:
On Friday 04 April 2014 03:48 PM, Russell
On Thursday 10 April 2014 05:33 PM, Russell King - ARM Linux wrote:
On Thu, Apr 10, 2014 at 05:26:15PM +0530, Sekhar Nori wrote:
On Wednesday 09 April 2014 09:53 PM, Russell King - ARM Linux wrote:
That is required because as part of the enable sequence, we write to the
lockdown registers to
On 10-04-2014 15:14, David Laight wrote:
It doesn't do any pin muxing. It switches SoC internal USB
signals between
USB controllers. The pins remain the same.
Doesn't something like that already happen for the companion USB1
controllers for USB2 ports?
Did you mean USB 1.1 and
This patch removes extcon_set_cable_state() and replace all calls of
this function witch extcon_set_cable_state_(), which is faster version.
This is first step of changing extcon API to faster and safer.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-class.c|
This patch modifies extcon_get_edev_by_phandle() function, to match
extcon device by devicetree node. This modification needed to add
field 'node' in extcon_dev structure, and fill it in probe function
of each extcon provider driver.
This patch replaces also extcon_get_extcon_dev() function with
This patch improves extcon client API to get rid of ugly functions operating
on name strings. It gives independency from naming convention in extcon
provider drivers. Names given at provider registration are now used only
for sysfs, debugs, and to support platforms using legacy devicetree
This patch adds check if pdata is NULL, to avoid NULL pointer dereference
when platform data is not available. After this changes, in described
situation driver will be configured with default values.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-max77693.c |2
This patch modifies extcon-adc-jack driver to use initialization data from
devicetree, when platform data is not available. It allows to define cable list
with ADC value ranges for each of them in devicetree bindings.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
This patch modifies extcon-gpio driver to use initialization data from
devicetree if platform data is not available. It allows to set controller
and cable names, and another parameters from devicetree bindings.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-gpio.c
This patch simplifies extcon_updata_state() function. There is greatly
simplified kobject_uevent preparation. Also meaning of variable passed
to raw_notifier_call_chain() (and in effect to _call_per_cable()) has
changed. Now positions on ones in variable 'val' in _call_per_cable()
indicates
This patch removes cable array example form extcon code, to avoid
littering driver namespace. Now it's located in extcon documentation.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
Documentation/extcon/extcon.txt | 108 +++
Added check if pointer to edev is not NULL, and updated documentation of index
parameter. Function extcon_find_cable_index() has been deleted and cannot be
used to retrieve cable number.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-class.c |9 ++---
1
This patch removes two functions, extcon_find_cable_index() and
extcon_get_edev_by_phandle(). They are not longer needed, since
extcon client API has changed to be oriented on extcon_cable instead
of extcon_dev.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
This patch changes charger-manager bindings to be compatible with
new extcon bindings.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
.../bindings/power_supply/charger-manager.txt | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git
This patch adds extcon devicetree bindings. Documentation describes in general
client and provider bindings, and contains detailed desctiprion of bindings
for each extcon provider.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
.../devicetree/bindings/extcon/extcon-adc-jack.txt | 60
This patchset adds many improvements to extcon class driver and extcon
provider drivers. It changes extcon API to faster and safer by replaceing
function taking extcon and cable names with functions working with
structures representing this objects.
It adds more advanced devicetree support which
On Thursday 10 April 2014 05:46 PM, Sekhar Nori wrote:
This will work. NS_LOCKDOWN is required for L2C-220 as well and so I was
thinking about adding a new l2c220_enable() which will set the
NS_LOCKDOWN and then call l2c_enable()
Here is a patch for what I was saying above.
diff --git
This patch adds check if pdata is NULL, to avoid NULL pointer dereference
when platform data is not available. After this changes, in described
situation driver will be configured with default values.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/extcon/extcon-max8997.c |2
On Thu, Apr 10, 2014 at 06:57:05PM +0530, Sekhar Nori wrote:
On Thursday 10 April 2014 05:46 PM, Sekhar Nori wrote:
This will work. NS_LOCKDOWN is required for L2C-220 as well and so I was
thinking about adding a new l2c220_enable() which will set the
NS_LOCKDOWN and then call l2c_enable()
Hi Wolfram,
On Wednesday 09 April 2014 06:07 PM, Wolfram Sang wrote:
On Wed, Apr 09, 2014 at 04:06:48PM +0530, Sourav Poddar wrote:
I2c core supports defualt probing functionality for devices not registered
through
dt/board files. If there are any client driver registered, i2c core will try
On 04/01/2014 08:06 AM, Peter Ujfalusi wrote:
Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high
priority channels, like audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
This looks good, though another way to do it would be to leave default
to Queue 0. Put audio
On 04/01/2014 08:06 AM, Peter Ujfalusi wrote:
To improve latency with cyclic DMA operation it is preferred to
use different eventq/tc than the default which is used by all
other drivers (mmc, spi, i2c, etc).
When preparing the cyclic dma ask for non default queue for the
channel which is
On Sun, Apr 6, 2014 at 4:58 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Now that you have sent your changes for v3.15 to Torvalds, here are some
changes for the OMAP GPIO driver targeted to v3.16. Mostly improvements
so nothing here is -rc material.
I like this series
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
The GPIO OMAP driver supports different OMAP SoC families and
not all of them have the needed support to use the linear IRQ
domain mapping like OMAP1 that use the legacy domain mapping.
But this special check is not necessary
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
The gpiochip_add() function can fail if the chip cannot
be registered so the return value has to be checked and
the error propagated in case it happens.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
The ARCH_OMAP config option was used to built the GPIO OMAP
driver but this is not consistent with the rest of the GPIO
drivers that have their own Kconfig option.
Also, this make it harder to add dependencies or reverse
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
Converts the GPIO OMAP driver to register its chained irq
handler and irqchip using the helpers in the gpiolib core.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpio/Kconfig | 1
On Thu, Apr 10, 2014 at 7:39 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
+#ifdef CONFIG_ARCH_OMAP1
+ /*
+ * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop
+ * irq_alloc_descs() since a
Hi,
On Thu, Apr 10, 2014 at 03:16:43PM +0200, Robert Baldyga wrote:
+struct extcon_cable *extcon_get_cable_by_name(struct device *dev,
+ const char *name)
+{
+ return of_extcon_get_cable_by_name(dev-of_node, name);
+}
Hello Linus and Santosh,
On Thu, Apr 10, 2014 at 7:45 PM, Linus Walleij linus.wall...@linaro.org wrote:
On Thu, Apr 10, 2014 at 7:39 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
On Sunday 06 April 2014 10:58 AM, Javier Martinez Canillas wrote:
+#ifdef CONFIG_ARCH_OMAP1
+ /*
+
Hi,
On Thu, Apr 10, 2014 at 07:29:26PM +0200, Linus Walleij wrote:
On Sun, Apr 6, 2014 at 4:58 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Now that you have sent your changes for v3.15 to Torvalds, here are some
changes for the OMAP GPIO driver targeted to v3.16.
Hello Aaro,
Thanks a lot for testing the series!
On Thu, Apr 10, 2014 at 9:30 PM, Aaro Koskinen aaro.koski...@iki.fi wrote:
Hi,
On Thu, Apr 10, 2014 at 07:29:26PM +0200, Linus Walleij wrote:
On Sun, Apr 6, 2014 at 4:58 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Hi,
On Thu, Apr 10, 2014 at 10:17:44PM +0200, Javier Martinez Canillas wrote:
The same happens also on Nokia 770:
[0.118896] genirq: Setting trigger mode 0 for irq 128 failed
(gpio_irq_type+0x0/0x220)
I don't have those errors when booting on my DM3730 IGEPv2 board but
it seems
On Tue, Mar 25, 2014 at 11:48:47AM -0700, Tony Lindgren wrote:
The lack of pm_runtime_resume handling for the device state leads into
device wake-up interrupts not working after a while for runtime PM.
Also, serial-omap is confused about the use of device_may_wakeup.
The checks for
On Tue, Apr 01, 2014 at 05:44:19PM -0500, Felipe Balbi wrote:
current algorithm in allocate_free_irq() is O(n),
by just keeping track of last allocated IRQ with a
simple unsigned integer, we can find a free IRQ
in O(1).
Signed-off-by: Felipe Balbi ba...@ti.com
---
compile-tested only as
On 04/01/2014 08:06 AM, Peter Ujfalusi wrote:
We only support DEV_TO_MEM or MEM_TO_DEV directions with edma driver and the
check for the direction has been already done in the function calling
edma_config_pset().
The error reporting is redundant and also the else if () can be removed.
NAK.
Hi Peter,
Other than patches 8/14 and 10/14 which I responded to, you could add my
Acked-by, or add it to the series itself once you make the changes and
drop 10.
Acked-by: Joel Fernandes jo...@ti.com
Thanks,
-Joel
On 04/01/2014 08:06 AM, Peter Ujfalusi wrote:
Hi,
This is basically a
Hi Joerg,
On Wednesday 09 April 2014 17:08:31 Joerg Roedel wrote:
On Tue, Apr 08, 2014 at 05:02:37PM +0200, Laurent Pinchart wrote:
On Tuesday 08 April 2014 15:43:22 Joerg Roedel wrote:
Who is someone in this case?
That's exactly the problem :-) The ARM DMA API implementation doesn't
On N900 there are nice LEDs that show the state of the
sys_clkreq and sys_off_mode pins.
These LEDs go low when the system enters deeper idle
states. The left LED shows the state of the sys_clkreq
pin, and goes off during retention idle. The right LED
shows the state of sys_off_mode pin and both
Enable CPUidle so it's easier for maintainers to notice
if some future code changes cause regressions.
Cc: Kevin Hilman khil...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
We are currently disabling the init of voltage scaling
for device tree. With the voltage scaling problems fixed
for omap3 in general, there's no need to disable the voltage
scaling init for device tree based booting.
Cc: Kevin Hilman khil...@linaro.org
Cc: Nishanth Menon n...@ti.com
Cc: Paul
Since we set up device wake-up interrupts as pinctrl-single
interrupts, we now must use the standard request_irq and
related functions to manage them.
If the pin interrupts are enabled for some pins at boot,
the wake-up events can show up as constantly pending
at least on omaps and will hang the
While debugging legacy mode vs device tree booted PM regressions,
I noticed that omap3 is not toggling sys_clkreq and sys_off_mode
pins like it should.
The sys_clkreq and sys_off_mode pins are not toggling because of
the following issues:
1. The default polarity for the sys_off_mode pin is
Currently we're attempting to use a static value for the
voltctrl register that only works for controlling the PMIC
over I2C4. For using sys_off_mode signaling, we need to update
update clksetup, voltsetup1, voltsetup2 and voltctrl registers
dynamically depending on the idle state.
So let's fix
Hi all,
As we're planning to make omap3 device tree only soon, I was poking
around and noticed that PM is not working properly. As we're planning
to drop about 20k lines of code, I just had to try to fix this so we
know what is going on and don't have to go back. I was pretty bummed
out to find
I noticed a regression where the omap sys_clkreq signal will never
trigger for omap3 when booted with device tree while it triggers
when booted in legacy mode. This means voltage scaling does not
do anything when booted with device tree.
Turns out the reason is we fail to initialize the
From: Tero Kristo t-kri...@ti.com
There is a solitary write to this register every wakeup from off-mode,
which isn't doing anything, so remove it.
Also note that modifying this register trashes any attempted
voltage scaling configuration and the change probably should
never have gotten merged in
We've had deeper idle states working on omaps for few years now,
but only in the legacy mode. When booted with device tree, the
wake-up events did not have a chance to work until commit
3e6cee1786a1 (pinctrl: single: Add support for wake-up interrupts)
that recently got merged. In addition to that
Almost certainly any sane board has the twl4030 has the I2C4
pins connected as those are needed for voltage control during
idle. If the I2C4 lines are not properly muxed, any voltage
scaling over I2C4 will fail.
Let's mux those pins by default, the boards that are not using
them can still
Commit c589eb3869a8 (ARM: OMAP3: VC: calculate ramp times)
started using regulator slew rates for calculating the idle
mode start-up times. This works fine for I2C4 controlled
regulator scaling as the regulators are never completely
turned off.
For sys_off_mode pin controlled PMIC scripts, the
* Tony Lindgren t...@atomide.com [140410 16:52]:
On N900 there are nice LEDs that show the state of the
sys_clkreq and sys_off_mode pins.
Here's a work in progress related twl4030 script for N900
to play with, I think it can be made more generic though.
This scales vdd_core to zero during off
On Thursday 10 April 2014 07:10 PM, Russell King - ARM Linux wrote:
On Thu, Apr 10, 2014 at 06:57:05PM +0530, Sekhar Nori wrote:
On Thursday 10 April 2014 05:46 PM, Sekhar Nori wrote:
This will work. NS_LOCKDOWN is required for L2C-220 as well and so I was
thinking about adding a new
66 matches
Mail list logo
