On Tuesday 17 September 2013 11:08 AM, Joel Fernandes wrote:
On 09/17/2013 12:08 AM, Sekhar Nori wrote:
[..]
I still cannot find any users of edma in the device tree sources either
in linux-next or linus/master. Why cannot this wait until v3.13?
I understand this affects only DT users of
On Tue, 2013-09-17 at 09:26 +0300, Luca Coelho wrote:
Both patches look good to me, though I didn't have the time to retest
them.
Actually I don't even have a Blaze device anymore, so I can't really
test the second patch. :(
--
Luca.
--
To unsubscribe from this list: send the line unsubscribe
Hi Tony,
Both patches look good to me, though I didn't have the time to retest
them.
--
Cheers,
Luca.
On Fri, 2013-09-13 at 12:09 -0700, Tony Lindgren wrote:
Commit b42b9181 (ARM: OMAP2+: Remove board-omap4panda.c)
removed legacy booting in favor of device tree based booting
for pandaboard.
The struct hdmi_ip_data contains information related to HDMI wrapper, PLL, PHY
and core sub-blocks. Now that each of these sub blocks has it's own struct,
hdmi_ip_data serves no purpose. The mutex lock in the struct was also never
used.
Remove this struct to make things cleaner.
Signed-off-by:
The OMAP4 HDMI encoder driver(hdmi4.c) contains timings tables, and helper
functions which can be used as is by the OMAP5/DRA7x encoder driver. Move these
to hdmi_common.c so that it's not replicated in the future.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/Makefile
Keep only OMAP4 HDMI core block related structs and enums in ti_hdmi_4xxx_ip.h,
move the rest to ti_hdmi.h. This holds all library specific data which will be
shared between OMAP4 and OMAP5/DRA7x HDMI encoder drivers.
Move the duplicate register read/write/wait_for_bit_change functions in the
The hdmi4 driver has edid macros that aren't used at all. Remove them.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/hdmi4.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi4.c b/drivers/video/omap2/dss/hdmi4.c
index
HDMI wrapper is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
existing functions from ti_hdmi_4xxx_ip.c to a separate file. These funcs are
called directly from the hdmi driver rather than hdmi_ip_ops funtion pointer
calls.
Add new wrapper funcs which can be used by other hdmi
Split hdmi address space in order to get base addresses of hdmi submodules by
name. This is just a demonstration patch for the hdmi refactoring to work. The
address data should belong to the hdmi DT node.
Signed-off-by: Archit Taneja arc...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |
The HDMI IP in OMAP4 DSS is present in a few other TI SoCs which don't have a
Display Subsystem similar to what's in OMAP. The original driver was designed
to provide ops such that it could be plugged into a different display subsytem
in some other SoC. These other SoCs, however, never got their
HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
existing PLL functions from ti_hdmi_4xxx_ip.c and hdmi.c to a separate file.
These funcs are called directly from the hdmi driver rather than hdmi_ip_ops
function pointer calls.
Add the PLL library function declarations to
After removing wrapper, pll and phy funcs from ti_hdmi_4xxx_ip.c, we are left
with OMAP4 HDMI core functions. Use these directly in hdmi.c rather than using
hdmi_ip_ops. Rename the core functions with a 'hdmi4' suffix.
We used to have hdmi_ip_ops so that one could support HDMI within a TI SoC
HDMI PHY is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
existing functions from ti_hdmi_4xxx_ip.c to a separate file. These funcs are
called directly from the hdmi driver rather than hdmi_ip_ops function pointer
calls.
Add the PHY library function declarations to ti_hdmi.h. These
Add flags for the interrupts present in HDMI wrapper block, these will be used
to configure HDMI_IRQENABLE_SET/CLEAR and HDMI_IRQSTATUS registers.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/hdmi_phy.c | 3 ---
drivers/video/omap2/dss/ti_hdmi.h | 15 +++
Quoting Archit Taneja (2013-09-17 00:06:28)
HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
existing PLL functions from ti_hdmi_4xxx_ip.c and hdmi.c to a separate file.
These funcs are called directly from the hdmi driver rather than hdmi_ip_ops
function pointer calls.
On 17/09/13 12:38, Mike Turquette wrote:
Quoting Archit Taneja (2013-09-17 00:06:28)
HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
existing PLL functions from ti_hdmi_4xxx_ip.c and hdmi.c to a separate file.
These funcs are called directly from the hdmi driver rather
On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner t...@linutronix.de wrote:
So why can't you make use of irq domains and have the whole routing
business implemented sanely?
What's needed is in gic_init_bases():
if (of_property_read(node, routable_irqs, nr_routable_irqs) {
If code is to be copied into and area (such as SRAM) and run,
it needs to be marked as exec. Currently only an ARM version
of this exists.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/include/asm/io.h | 2 ++
include/asm-generic/iomap.h | 5 +
2 files changed, 7 insertions(+)
This enables CONFIG_PIE for omap2plus_defconfig and adds
an am33xx PIE section group. This is necessary for am33xx
suspend/resume code as it is written in C.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/configs/omap2plus_defconfig | 1 +
arch/arm/kernel/pie.lds.S| 1 +
2
From: Vaibhav Bedia vaibhav.be...@ti.com
AM335x supports various low power modes as documented
in section 8.1.4.3 of the AM335x TRM which is available
@ http://www.ti.com/litv/pdf/spruh73f
DeepSleep0 mode offers the lowest power mode with limited
wakeup sources without a system reboot and is
Add support to ARM for embedding PIEs into the kernel, loading them into
genalloc pools (such as SRAM) and executing them. Support for ARM means
performing R_ARM_RELATIVE fixups within the .rel.dyn section.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/Kconfig | 1 +
The SRAM is for use by the MPU. Marking it as such makes it
easier for PM initialization code to locate the SRAM in order to
load a PIE section into it.
Additionally, set the map-exec flag to allow code to be run
from SRAM. This is necessary for suspend/resume.
Signed-off-by: Russ Dill
Add a helper that generates a short snippet of code that updates PIE
relocations, loads the stack pointer and calls a C (or asm) function.
The code gets placed into a PIE section.
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/include/asm/suspend.h | 25 +
1 file
This adds support for updating PIE relocations under ARM. This
is necessary in the case that the same PIE must run both with
virtual mapping (MMU enabled) and physical mapping (MMU
disabled).
Signed-off-by: Russ Dill russ.d...@ti.com
---
arch/arm/include/asm/pie.h | 42 +
Under certain arches (ARM) function pointers cannot be
used naively. Specifically, for thumb functions, their 0 bit
is set, but they are contained on a word aligned address.
Add a fncpy macro to perform function copies correctly
along with two helpers, fnptr_to_address, and fnptr_translate.
Now that there is an _exec version of ioremap, add devm support for it.
Signed-off-by: Russ Dill russ.d...@ti.com
---
include/linux/device.h | 17 -
include/linux/io.h | 4 +++
lib/devres.c | 97 --
3 files changed, 114
This patch adds support for and demonstrates the usage of an embedded
position independent executable (PIE). The goal is to allow the use of C
code in situations where carefully written position independent assembly
was previously required.
The example used is the suspend/resume code for the
This commit adds support for embedding PIEs into the kernel, loading them
into genalloc sections, performing necessary relocations, and running code
from them. This allows platforms that need to run code from SRAM, such
an during suspend/resume, to develop that code in C instead of assembly.
This is necessary for platforms that use SRAM to execute suspend/resume stubs.
Signed-off-by: Russ Dill russ.d...@ti.com
---
Documentation/devicetree/bindings/misc/sram.txt | 4
drivers/misc/sram.c | 13 -
include/linux/platform_data/sram.h
On Wed, Sep 4, 2013 at 9:03 AM, George Cherian george.cher...@ti.com wrote:
This patch series
- removes the irq_demux_work
- Uses devm_request_threaded_irq
- Call the user handler iff gpio_to_irq is done.
v1 -- v2
Split v1 to 3 patches
v2 -- v3
Hi Tony,
On 13/09/2013 17:27, Tony Lindgren wrote:
* Koen Kooi k...@dominion.thruhere.net [130912 11:43]:
The pinmux is specified in am335x-bone-common.dtsi to be reused by the eMMC
cape.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 22
Hi Koen,
On 12/09/2013 20:35, Koen Kooi wrote:
Here are two patches to fix MMC on beaglebone, one fixes card detect on BBW,
the other adds the eMMC entry for BBB and its fixed regulator. After that mmc1
gets a nice speed boost by moving to 4-bit mode and LED triggers get assigned.
This series
Hi Suman,
On 08/08/2013 17:44, Suman Anna wrote:
On 08/08/2013 09:34 AM, Kumar Gala wrote:
On Aug 7, 2013, at 3:08 PM, Suman Anna wrote:
On 08/07/2013 12:41 PM, Kumar Gala wrote:
On Aug 7, 2013, at 11:59 AM, Suman Anna wrote:
Kumar,
Logic has been added to the OMAP2+ mailbox code to
CONFIDENTIAL TRUST REPLY .
Dear Friend,
I am contacting you to assist me in the transfer of $6,200,000.00 into your
personal bank account for our benefit, this transaction is confidential and we
MUST remain fiducially in all our dealings since I cannot execute this
On Tue, Sep 17, 2013 at 2:43 PM, Russ Dill russ.d...@ti.com wrote:
+++ b/arch/alpha/include/asm/fncpy.h
@@ -0,0 +1 @@
+#include asm-generic/fncpy.h
Please add
generic-y += fncpy.h
to arch/arch/include/asm/Kbuild instead.
Gr{oetje,eeting}s,
Geert
--
Geert
Hi Nishant,
On Monday 16 September 2013 08:56 PM, Nishanth Menon wrote:
On 09/16/2013 08:48 AM, Afzal Mohammed wrote:
From: Ambresh K ambr...@ti.com
Add the data file to describe clock domains in AM43x SoC.
OMAP4 clockdomain operations is being reused here.
Signed-off-by: Ambresh K
On 09/17/2013 01:05 AM, Sekhar Nori wrote:
[..]
mixed messages. In short, we aim for consistency with situation today,
not tomorrow.
What you're asking to do infact breaks consistency with the rest of the code.
Well, ideally we support second CC even with DT to be consistent all
around.
On 09/17/2013 09:31 AM, Afzal Mohammed wrote:
Hi Nishant,
On Monday 16 September 2013 08:56 PM, Nishanth Menon wrote:
On 09/16/2013 08:48 AM, Afzal Mohammed wrote:
From: Ambresh K ambr...@ti.com
Add the data file to describe clock domains in AM43x SoC.
OMAP4 clockdomain operations is
On Tuesday 17 September 2013 17:48:59 you wrote:
On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
More power supply drivers depends on vbus events and without
it they not working. Power supply drivers using
usb_register_notifier, so to deliver events it is needed to
call
* Tero Kristo t-kri...@ti.com [130829 06:24]:
The OMAP clock driver now supports DPLL clock type. This patch also
adds support for DT DPLL nodes.
...
+- reg-names : array of the register names for controlling the device, sorted
+ in the same order as the reg property.
+ control -
Hi,
On Thu, Sep 12, 2013 at 04:17:08PM +0530, Vivek Gautam wrote:
On Thu, Sep 12, 2013 at 4:06 PM, Roger Quadros rog...@ti.com wrote:
Hi Kishon,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
There can be systems which does not have a external usb_phy, so get
usb_phy only if
* Dave Martin dave.mar...@arm.com [130916 10:18]:
On Sat, Sep 14, 2013 at 10:37:12AM +0100, Pali Rohár wrote:
On Sunday 08 September 2013 09:43:29 Pali Rohár wrote:
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r11, lr}
+ mov r12, r0 @ Copy the secure service ID
+ mov
On Wed, Sep 04, 2013 at 02:27:06PM +0530, Kishon Vijay Abraham I wrote:
On Tuesday 03 September 2013 09:20 PM, Greg KH wrote:
On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote:
Hi Greg,
On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote:
Hi,
On Mon, Aug
On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
diff --git a/drivers/usb/phy/phy-twl4030-usb.c
b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int
On Tuesday 17 September 2013 17:43:31 Tony Lindgren wrote:
* Dave Martin dave.mar...@arm.com [130916 10:18]:
On Sat, Sep 14, 2013 at 10:37:12AM +0100, Pali Rohár wrote:
On Sunday 08 September 2013 09:43:29 Pali Rohár wrote:
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r11, lr}
On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
On Tuesday 17 September 2013 17:48:59 you wrote:
On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
More power supply drivers depends on vbus events and without
it they not working. Power supply drivers using
On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
More power supply drivers depends on vbus events and without it they not
working. Power supply drivers using usb_register_notifier, so to deliver
events it is needed to call atomic_notifier_call_chain.
So without atomic notifier
* Tomi Valkeinen tomi.valkei...@ti.com [130829 06:40]:
The DPI and SDI platform devices are currently created with the ID of
-1. The ID doesn't currently affect anything.
However, we have added regulator supply entries for omapdss_dpi.0 and
omapdss_sdi.0 to the board files, although these
CNTFREQ isn't pre-programmed on DRA7 just like O5, so provide the
same. Without a valid value arch_timer_init results in div0 crash.
Providing the same is a safer alternative.
Cc: R Sricharan r.sricha...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Sourav Poddar sourav.pod...@ti.com
Cc: Santosh
CNTFREQ isn't pre-programmed on DRA7 just like O5, so provide the
timer frequency via DT. Without a valid value arch_timer_init results
in div0 crash.
Cc: R Sricharan r.sricha...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Sourav Poddar sourav.pod...@ti.com
Acked-by: Santosh Shilimkar
On Tuesday 17 September 2013 12:47 PM, Nishanth Menon wrote:
CNTFREQ isn't pre-programmed on DRA7 just like O5, so provide the
same. Without a valid value arch_timer_init results in div0 crash.
s/same/timer frequency via DT
Providing the same is a safer alternative.
Above statement won't be
Hi,
has anyone ever successfully using gpio-pcf857x.c driver with 16-bit
gpio expanders ? We're having some issues here where toggling the last
gpio pin (gpio 15) on a PCF8575 device causes platform to hang and I
can't come up with any explanation of why would it hang...
Any hints ?
cheers
--
On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
On Tuesday 17 September 2013 17:48:59 you wrote:
On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
More power supply drivers depends on vbus events and
Hi,
This is an updated series for adding the device tree support to
the OMAP hwspinlock driver. The series is based on 3.12-rc1, and
includes patches on hwspinlock driver, OMAP hwmod data files and
OMAP DTS files. The updated series adds new patches to enable the
hwspinlock driver on OMAP5 and
All the platform-specific hwlock driver implementations need the
number of locks and the associated base id for registering the
locks present within a hwspinlock device with the driver core.
These two variables are represented by 'hwlock-num-locks' and
'hwlock-base-id' properties. The
AM33XX device family also supports hwspinlocks. The IP
is identical to that of OMAP4/OMAP5, except for the
number of locks.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwspinlock/Kconfig
The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.
This particular issue is seen rather easily on AM33XX, since the
module wakeup is software
Add the hwspinlock device tree node for OMAP4 family
of SoCs.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..a8cc274 100644
---
On Tue, Sep 17, 2013 at 3:02 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 17/09/13 12:38, Mike Turquette wrote:
Quoting Archit Taneja (2013-09-17 00:06:28)
HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
existing PLL functions from ti_hdmi_4xxx_ip.c and hdmi.c to a
Add the missing sysc configuration to the AM335 spinlock hwmod
data. This ensures that smart-idle is enabled whenever the module
is enabled by the driver.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 13 +
1 file changed, 13 insertions(+)
Add the hwspinlock device tree node for AM33xx family
of SoCs.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index f9c5da9..4371257 100644
---
Add the hwspinlock device tree node for OMAP5 SoCs.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 07be2cd..449be92 100644
---
Add the hwmod data for the spinlock IP in OMAP5 SoC.
This is needed to be able to enable the OMAP spinlock
support for OMAP5.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 44 ++
1 file changed, 44 insertions(+)
diff --git
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna s-a...@ti.com
---
Hi,
My question is related to the drivers/mmc/host/omap_hsmmc.c host
controller compatibility with SDXC for the OMAP35x?
Reading the TRM for OMAP35x:
http://www.ti.com/lit/ug/spruf98x/spruf98x.pdf
It's said that:
- Full compliance with SD command/response sets as defined in the SD
Memory Card
Hi Benoit,
On 08/08/2013 17:44, Suman Anna wrote:
On 08/08/2013 09:34 AM, Kumar Gala wrote:
On Aug 7, 2013, at 3:08 PM, Suman Anna wrote:
On 08/07/2013 12:41 PM, Kumar Gala wrote:
On Aug 7, 2013, at 11:59 AM, Suman Anna wrote:
Kumar,
Logic has been added to the OMAP2+ mailbox code to
Hi Linus,
On Tuesday 17 September 2013 14:51:48 Linus Walleij wrote:
On Wed, Sep 4, 2013 at 9:03 AM, George Cherian wrote:
This patch series
- removes the irq_demux_work
- Uses devm_request_threaded_irq
- Call the user handler iff gpio_to_irq is done.
v1
* Pali Rohár pali.ro...@gmail.com [130917 09:01]:
On Tuesday 17 September 2013 17:43:31 Tony Lindgren wrote:
Have you guys checked how this works with the recently posted
[PATCH v6 0/5] ARM: support for Trusted Foundations secure
monitor series?
this code looks like some Tegra and
* Pali Rohár pali.ro...@gmail.com [130710 06:06]:
--- a/arch/arm/mach-omap2/board-rx51.c
+++ b/arch/arm/mach-omap2/board-rx51.c
This file will be gone as soon as we're moving to device
tree based booting. So let's do this in more future proof
way.
+/**
+ * rx51_secure_dispatcher: Routine to
* Kevin Hilman khil...@linaro.org [130826 17:17]:
Tony Lindgren t...@atomide.com writes:
Kevin,
* Wei Yongjun weiyj...@gmail.com [130704 06:48]:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function omap_device_alloc() returns ERR_PTR()
and never returns
* Josh Boyer jwbo...@redhat.com [130904 06:46]:
The board-omap3evm.c file unconditionally calls usb_nop_xceiv_register but
doesn't ensure this is built-in. This can lead to build failures like:
arch/arm/mach-omap2/built-in.o: In function `omap3_evm_init':
* Suman Anna s-a...@ti.com [130823 09:50]:
+ OMAP mailing list
Tony,
Can you pick up this minor cleanup patch?
regards
Suman
On 08/21/2013 09:10 PM, Jingoo Han wrote:
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to
* Kevin Hilman khil...@linaro.org [130827 09:01]:
Vladimir Murzin murzi...@gmail.com writes:
We call cpu_cluster_pm_enter for dev-cpu == 0 only, but
cpu_cluster_pm_exit called without that check.
Because of that unhandled page fault may happen:
[3.803405] Unable to handle kernel
* Aaro Koskinen aaro.koski...@iki.fi [130907 16:10]:
Hi,
On Fri, Sep 06, 2013 at 10:34:05PM +0200, Pali Rohár wrote:
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rx51-camera.c
[...]
Ping, can you review this patch v2?
I don't think Tony will accept any new board stuff for
* Luca Coelho l...@coelho.fi [130916 23:35]:
On Tue, 2013-09-17 at 09:26 +0300, Luca Coelho wrote:
Both patches look good to me, though I didn't have the time to retest
them.
Actually I don't even have a Blaze device anymore, so I can't really
test the second patch. :(
OK no problem,
On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Rohár wrote:
On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Rohár wrote:
On Tuesday 17 September 2013 17:48:59 you wrote:
On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Rohár wrote:
76 matches
Mail list logo
