On Sun, Apr 14, 2013 at 12:29:46AM -0400, Rob Clark wrote:
On Sat, Apr 13, 2013 at 5:45 PM, Thierry Reding
[...]
I had been thinking about this on and off for a while, but I haven't
come up with anything concrete. Ideally we could just have some kind of
event that userspace would listen
On Monday 15 April 2013 10:36 AM, Hiremath, Vaibhav wrote:
-Original Message-
From: Shilimkar, Santosh
Sent: Wednesday, April 10, 2013 5:02 PM
[..]
From b95dd33fe59b8e77727eb3b1717d763bbf9a2893 Mon Sep 17 00:00:00
2001
From: Sricharan R r.sricha...@ti.com
Date: Fri, 5 Apr 2013
Hi Stephen,
Could you please add:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next
to linux-next to include new stuff coming from Rob?
Thanks,
Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
The USB PHY needs AUXCLK3 to operate. Provide this information
as well.
Also provide pin multiplexer information for the USB host
pins.
This patch depends on OMAP clock binding introduced in
Hi Tony,
On 2013-04-03 18:46, Tony Lindgren wrote:
Tony, I've split these patches as follows:
Platform data header file changes:
git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
Board file changes (based on header changes):
git://gitorious.org/linux-omap-dss2/linux.git
On Mon, Apr 01, 2013 at 11:21:12PM +0100, Rob Herring wrote:
From: Rob Herring rob.herr...@calxeda.com
This converts arm and arm64 to use CLKSRC_OF DT based initialization for
the arch timer. A new function arch_timer_arch_init is added to allow for
arch specific setup.
This has a side
On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
the PHY with or without using phandle. To obtain a reference
On 04/13/2013 09:27 PM, Christoph Fritz wrote:
Hi
while testing an omap3 board with device tree support I stumbled upon a
bug which is due to wrong initialization order of twl-core and
twl-regulator (I suppose): In the boot process they get loaded way too
late so that a lot of drivers before
On 21:35 Mon 07 Jan , Arnd Bergmann wrote:
(Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
On Monday 07 January 2013, Tony Lindgren wrote:
At the end of the line, some kind of hardware glue is going to be needed.
I just feel that drawing from a sample size of 1 (maybe 2
Hi,
On Monday 15 April 2013 03:50 PM, Grant Likely wrote:
On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
Added a generic PHY framework that provides a set of APIs for the PHY drivers
to create/destroy a PHY and APIs for the PHY users to obtain a reference to
On Mon, 2013-04-15 at 13:20 +0300, Grygorii Strashko wrote:
On 04/13/2013 09:27 PM, Christoph Fritz wrote:
Hi
while testing an omap3 board with device tree support I stumbled upon a
bug which is due to wrong initialization order of twl-core and
twl-regulator (I suppose): In the boot
Hi Dave,
As agreed, here's the pull request for omap display.
One thing to note is that the panel platform data cleanups require changes to
the board files, which go through linux-omap tree. Merging only either the tag
in this pull request, or the board file changes, will give a kernel that
On 04/15/2013 01:56 PM, Christoph Fritz wrote:
On Mon, 2013-04-15 at 13:20 +0300, Grygorii Strashko wrote:
On 04/13/2013 09:27 PM, Christoph Fritz wrote:
Hi
while testing an omap3 board with device tree support I stumbled upon a
bug which is due to wrong initialization order of twl-core
On Beagle xM Rev. Ax/Bx, the USB power enable GPIO logic is
reversed when compared to other revisions i.e. it is
active high instead of active low.
Use the beagle_config.usb_pwr_level flag correctly so that
the power regulator can be configured at runtime.
Signed-off-by: Roger Quadros
On Sun, Apr 14, 2013 at 10:53 PM, Linus Walleij
linus.wall...@linaro.org wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that would
be the right approach?
Hi Linus, thanks a lot for
On 04/15/2013 12:36 PM, Kishon Vijay Abraham I wrote:
On Monday 15 April 2013 03:50 PM, Grant Likely wrote:
On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
Added a generic PHY framework that provides a set of APIs for the PHY
drivers
to create/destroy a PHY
On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. To obtain a reference to the PHY
Don't select NOP_USB_XCEIV. Instead, board config
must select USB_PHY and the appropriate PHY driver.
Also add a hint in Kconfig so that users enabling
this driver manually enable the right PHY drivers as well.
Gets rid of the below warnings when USB_EHCI_HCD_OMAP
is enabled.
warning:
As the USB PHY layer never returns NULL we don't need
to check for that condition.
If we fail to get the PHY device it could be due
to missing USB PHY drivers. Give this hint to the user
in the error message.
CC: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Roger Quadros rog...@ti.com
---
Hi Kevin,
On Thu, Apr 11, 2013 at 19:45:33, Kevin Hilman wrote:
Kevin Hilman khil...@linaro.org writes:
Bedia, Vaibhav vaibhav.be...@ti.com writes:
Hi Sourav,
On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote:
[...]
Yes, had a look at that and found your situation similar to
Hi Kevin,
On Thursday 11 April 2013 07:45 PM, Kevin Hilman wrote:
Kevin Hilmankhil...@linaro.org writes:
Bedia, Vaibhavvaibhav.be...@ti.com writes:
Hi Sourav,
On Wed, Apr 10, 2013 at 15:13:44, Poddar, Sourav wrote:
[...]
Yes, had a look at that and found your situation similar to UART.
On Mon, 15 Apr 2013 16:06:37 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Monday 15 April 2013 03:50 PM, Grant Likely wrote:
On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
Added a generic PHY framework that provides a set of APIs for the
Hi,
On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or
On Saturday 13 April 2013, Rob Clark wrote:
On Mon, Mar 4, 2013 at 1:46 PM, Tony Lindgren t...@atomide.com wrote:
drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of
`__mod_of_device_table'
drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
Hi,
On Monday 15 April 2013 05:56 PM, Grant Likely wrote:
On Mon, 15 Apr 2013 16:06:37 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Monday 15 April 2013 03:50 PM, Grant Likely wrote:
On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
Added a
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
This will not work for Rev Cx boards because of reversed logic
for USB_POWER_Enable.
CC: BenoƮt Cousson b-cous...@ti.com
Signed-off-by:
On 04/15/2013 03:35 PM, Roger Quadros wrote:
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
This will not work for Rev Cx boards because of reversed logic
for USB_POWER_Enable.
Hi Mark, Liam, All
Our target is to reuse common DVFS framework proposed by Mike Turquette
in http://lwn.net/Articles/540422/ and cpufreq-cpu0.c for all TI SoC and
minimize creation of any TI specific APIs or modules.
The common DVFS framework solution is based on assumption that Regulator,
In some cases the regulators may be organized in a chain like:
-regA-regB-regC
where regA is supplier for regB and regB is supplier for regC.
Currently it would be possible to reconfigure regA and regC at same time
form different contexts, because each regulator has it own mutex.
But in some
On Tue, 19 Mar 2013 11:35:48 -0500, Jon Hunter jon-hun...@ti.com wrote:
Adds a function to read the various GPMC chip-select settings from
device-tree and store them in the gpmc_settings structure.
Update the GPMC device-tree binding documentation to describe these
options.
Signed-off-by:
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Following patch series introduces the Adaptive Body-Bias
LDO driver, which handles LDOs voltage during OPP change routine.
Current implementation is based on patch series from
Mike Turquette:
http://marc.info/?l=linux-omapm=134931341818379w=2
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add DT ABB data for OMAP36xx family of devices.
Data is based on OMAP36XX TRM document.
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
Documentation/devicetree/bindings/power/abb.txt | 38 +++
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add DT ABB data for OMAP44xx family of devices.
Data is based on OMAP44xx TRM document.
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
arch/arm/boot/dts/omap4.dtsi| 22 ++
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Add DT ABB data for OMAP543x family of devices.
Data is based on OMAP543x TRM document.
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 39 +++
1 file changed,
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
This patch introduces aliases for SYS clock nedded for ABB
driver, which will be introduced in the following patch.
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
arch/arm/mach-omap2/cclock3xxx_data.c |1 +
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Patch introduces the Adaptive Body-Bias LDO driver,
which handles LDOs voltage during OPP change routine.
Current implementation is based on patch series from
Mike Turquette:
http://marc.info/?l=linux-omapm=134931341818379w=2
ABB can operate in
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Patch adds debugfs entry for each ABB:
/sys/kernel/debug/ABB device name
This entry is read-only. It prints current state of ABB.
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
---
drivers/regulator/abb-regulator.c | 74
On Mon, Apr 15, 2013 at 04:03:35PM +0300, Grygorii Strashko wrote:
To achieve this goal:
- abstract regulator locking out into helper functions;
- use the root Regulator (which has no supply defined, like regA) in chain to
protect the whole chain;
- implement regulator chain locking scheme
On Fri, Apr 12, 2013 at 05:25:07PM -0700, Tony Lindgren wrote:
Selecting CONFIG_DMADEVICES is optional, and we must
be able to continue even without DMA. Otherwise things
like omap4430sdp nfsroot will fail if DMA is not
selected.
Applied, thanks.
signature.asc
Description: Digital
Hi Mark,
On 04/15/2013 06:50 PM, Mark Brown wrote:
In addition, such locking scheme allows to have access to the supplier
regulator API from inside child's (consumer) regulator API.
I've still not seen any use case articulated for doing this...
Use case is introduced in ABB series:
On 04/12/2013 04:54 PM, Nishanth Menon wrote:
OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. This is especially true for board specific
clocks initially. The fixed clocks are
* Grygorii Strashko grygorii.stras...@ti.com [130415 04:05]:
On 04/15/2013 01:56 PM, Christoph Fritz wrote:
On Mon, 2013-04-15 at 13:20 +0300, Grygorii Strashko wrote:
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1014,7 +1014,18 @@ static struct
Quoting Andrii Tseglytskyi (2013-04-15 06:28:10)
Cc: Mike Turquette mturque...@linaro.org
Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Signed-off-by: Mike Turquette mturque...@linaro.org
It is very strange to Cc me and include my Signed-off-by. Go ahead and
drop my SoB. I'll
On 04/13/2013 07:35 PM, Javier Martinez Canillas wrote:
...
Is the following inlined patch [1] what you were thinking that would
be the right approach?
...
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
...
+static int omap_gpio_irq_request(struct irq_data *d)
+{
+
On 04/15/2013 08:27 AM, Grant Likely wrote:
On Tue, 19 Mar 2013 11:35:48 -0500, Jon Hunter jon-hun...@ti.com wrote:
Adds a function to read the various GPMC chip-select settings from
device-tree and store them in the gpmc_settings structure.
Update the GPMC device-tree binding documentation
On 04/13/2013 11:50 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130412 19:22]:
On 04/12/2013 07:06 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130410 15:32]:
* Jon Hunter jon-hun...@ti.com [130410 15:30]:
Are you saying that you want to use the version with that
On 04/14/2013 02:53 PM, Linus Walleij wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that would
be the right approach?
This looks sort of OK, but I'm still struggling with the
On Mon, Apr 15, 2013 at 07:21:25PM +0300, Andrii Tseglytskyi wrote:
On 04/15/2013 06:50 PM, Mark Brown wrote:
In addition, such locking scheme allows to have access to the supplier
regulator API from inside child's (consumer) regulator API.
I've still not seen any use case articulated for
On 4/15/2013 12:50 AM, Mark Jackson wrote:
On 11/02/13 19:52, Mugunthan V N wrote:
The CPSW switch can act as Dual EMAC by segregating the switch ports
using VLAN and port VLAN as per the TRM description in
14.3.2.10.2 Dual Mac Mode
Following CPSW components will be common for both the
On 4/15/2013 12:46 AM, Mark Jackson wrote:
On 11/02/13 19:52, Mugunthan V N wrote:
This patch series implements Dual EMAC mode implementation of CPSW
which acts as two standalone EMAC by segregating the switch using VIDs
and port VLAN
Mugunthan V N (3):
driver: net: ethernet: davinci_cpdma:
On 15/04/13 18:07, Mugunthan V N wrote:
On 4/15/2013 12:46 AM, Mark Jackson wrote:
snip
Notice that at the end, the nfs link appears to come back ok, but
the ps command never completes.
Any ideas of what's going on ?
I have tried ping on both the interface fine. Will verify with ps again
Dual EMAC slave VLAN id must be got from slave node instead of cpsw node as
VLAN id for each slave will be different.
Reported-by: Mark Jackson mpfj-l...@mimc.co.uk
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c |2 +-
1 file changed, 1 insertion(+), 1
On 4/15/2013 10:58 PM, Mark Jackson wrote:
On 15/04/13 18:07, Mugunthan V N wrote:
On 4/15/2013 12:46 AM, Mark Jackson wrote:
snip
Notice that at the end, the nfs link appears to come back ok, but
the ps command never completes.
Any ideas of what's going on ?
I have tried ping on both
On 15/04/13 18:34, Mugunthan V N wrote:
On 4/15/2013 10:58 PM, Mark Jackson wrote:
On 15/04/13 18:07, Mugunthan V N wrote:
On 4/15/2013 12:46 AM, Mark Jackson wrote:
snip
Notice that at the end, the nfs link appears to come back ok, but
the ps command never completes.
Any ideas of what's
On 04/15/2013 11:57 AM, Jon Hunter wrote:
On 04/13/2013 11:50 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130412 19:22]:
On 04/12/2013 07:06 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130410 15:32]:
* Jon Hunter jon-hun...@ti.com [130410 15:30]:
Are you
From: Mugunthan V N mugunthan...@ti.com
Date: Mon, 15 Apr 2013 23:01:28 +0530
Dual EMAC slave VLAN id must be got from slave node instead of cpsw node as
VLAN id for each slave will be different.
Reported-by: Mark Jackson mpfj-l...@mimc.co.uk
Signed-off-by: Mugunthan V N mugunthan...@ti.com
On Mon, Apr 15, 2013 at 11:22 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 04/12/2013 04:54 PM, Nishanth Menon wrote:
OMAP clock data is located in arch/arm/mach-omap2/cclockXYZ_data.c.
However, this presents an obstacle for using these clock nodes in
Device Tree definitions. This is
On Mon, 15 Apr 2013 17:56:10 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi,
On Monday 15 April 2013 05:04 PM, Grant Likely wrote:
On Wed, 20 Mar 2013 14:42:00 +0530, Kishon Vijay Abraham I kis...@ti.com
wrote:
The PHY framework provides a set of APIs for the PHY drivers to
On 04/15/2013 11:53 AM, Stephen Warren wrote:
On 04/13/2013 07:35 PM, Javier Martinez Canillas wrote:
...
Is the following inlined patch [1] what you were thinking that would
be the right approach?
...
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
...
+static int
* Tomi Valkeinen tomi.valkei...@ti.com [130415 02:34]:
Hi Tony,
On 2013-04-03 18:46, Tony Lindgren wrote:
Tony, I've split these patches as follows:
Platform data header file changes:
git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
Board file changes (based on
* Jon Hunter jon-hun...@ti.com [130415 11:15]:
On 04/15/2013 11:57 AM, Jon Hunter wrote:
On 04/13/2013 11:50 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [130412 19:22]:
On 04/12/2013 07:06 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130410 15:32]:
* Jon
Hi Vaibhav,
Bedia, Vaibhav vaibhav.be...@ti.com writes:
[...]
So, my proposal is that Sourav remove that flag from the AM33xx hwmod
when he removes this feature.
Apologies for the delayed response. I was out of office for a couple of
days.
I don't recall the exact kernel version in which
On 04/15/2013 11:58 AM, Stephen Warren wrote:
On 04/14/2013 02:53 PM, Linus Walleij wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that would
be the right approach?
This looks sort
On 04/15/2013 04:40 PM, Jon Hunter wrote:
On 04/15/2013 11:58 AM, Stephen Warren wrote:
On 04/14/2013 02:53 PM, Linus Walleij wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that
Andrii Tseglytskyi andrii.tseglyts...@ti.com writes:
From: Andrii.Tseglytskyi andrii.tseglyts...@ti.com
Following patch series introduces the Adaptive Body-Bias
LDO driver, which handles LDOs voltage during OPP change routine.
Current implementation is based on patch series from
Mike
Jon Hunter jon-hun...@ti.com writes:
On 04/10/2013 02:33 PM, Linus Walleij wrote:
On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter jon-hun...@ti.com wrote:
Currently the IRQ domain is not freed once allocated, in the case where
omap_gpio_probe() fails. Therefore, ensure we free the domain if the
On 04/15/2013 03:40 PM, Jon Hunter wrote:
On 04/15/2013 11:58 AM, Stephen Warren wrote:
On 04/14/2013 02:53 PM, Linus Walleij wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following inlined patch [1] what you were thinking that
On 04/15/2013 05:16 PM, Stephen Warren wrote:
On 04/15/2013 03:40 PM, Jon Hunter wrote:
On 04/15/2013 11:58 AM, Stephen Warren wrote:
On 04/14/2013 02:53 PM, Linus Walleij wrote:
On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas
martinez.jav...@gmail.com wrote:
Is the following
Hi Ohad,
On Mon, 15 Apr 2013 09:28:17 +0300 Ohad Ben-Cohen o...@wizery.com wrote:
Could you please add:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next
to linux-next to include new stuff coming from Rob?
Well, you could tell me something about it. Like what is in
On 2013-04-16 00:20, Tony Lindgren wrote:
So, to recap, the common header changes are located in:
git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers
And the branch for linux-omap is:
git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/board-cleanup
After merging those,
70 matches
Mail list logo