Hi,
On 18/03/15 11:06, Jyri Sarha wrote:
I think the patches 1-5 are ready for merging. See the details below.
I applied these on top of v4.0-rc3, booted up BBB, and loaded the modules.
After doing that and waiting a few secs:
# ./s-bbb.sh
[ 15.237139] sysrq: SysRq : Changing Loglevel
[
On 03/23/2015 05:00 PM, Petr Kulhavy wrote:
If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan-edesc was not freed.
This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted,
On 12:19-20150324, Roger Quadros wrote:
We need to enable EXTCON_USB_GPIO_USB and not
EXTCON_GPIO_USB.
Fixes: c08a54c0ebeb (ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB)
Reported-by: Nishant Menon n...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/configs
On 03/23/2015 05:45 PM, Petr Kulhavy wrote:
Hi Peter,
I've just posted a patch to the community, you should have received another
email from me just a few minutes ago.
Basically there should be a kfree in terminate_all() just before echan-edesc
is set to NULL.
The reason is that at that
On 03/23/2015 10:35 PM, Petr Kulhavy wrote:
The data parameter passed indirectly to the edma_callback() should be
edma_chan and not the dma_chan.
This bug was so far harmless since the offset of struct dma_chan within struct
edma_chan is 0. However as soon as someone changes struct edma_chan
Hi Eliad,
On 03/18/2015 06:38 PM, Eliad Peller wrote:
Add device-tree support to the wlcore (wl12xx/wl18xx)
driver.
Update the current users to use the bindings instead
of pdata-quirks.
Finally, remove the deprecated wl12xx_platform_data
struct (along with the da850 board file code that
still
On Mon, Mar 23, 2015 at 05:38:44PM -0500, Doug Kehn wrote:
When wakeirq is not used/enabled, no wakeirq for uart0 is output for
all TTY as the log message is generated before the port line is
initialized.
[0.802656] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[0.811700]
We need to enable EXTCON_USB_GPIO_USB and not
EXTCON_GPIO_USB.
Fixes: c08a54c0ebeb (ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB)
Reported-by: Nishant Menon n...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/configs/omap2plus_defconfig | 2 +-
1 file changed, 1
On Tue, 3 Mar 2015 15:12:02 +0530 Keerthy j-keer...@ti.com wrote:
Add external 32k clock feature. The internal clock will be gated during
suspend.
Hence make use of the external 32k clock so that rtc is functional accross
suspend/resume.
...
@@ -446,6 +449,7 @@ static const struct
On Tue 2015-03-24 12:30:34, Eduardo Valentin wrote:
On Sun, Jan 18, 2015 at 09:24:47PM +0100, Pavel Machek wrote:
When periodic mode is not enabled, it is neccessary to force reads.
Signed-off-by: Pavel Machek pa...@ucw.cz
This is a malformed patch. here is patch output (or git am)
When periodic mode is not enabled, it is neccessary to force reads.
Signed-off-by: Pavel Machek pa...@ucw.cz
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 62a5d44..ec533e7 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
DRA7xxx contains a very similar DSS to OMAP5. The main differences are:
* no DSI or RFBI support.
* 1 or 2 dedicated video PLLs.
* need to do additional configuration to the DRA7 CONTROL module.
DRA72xx has only one video PLL, and DRA74xx has two.
Signed-off-by: Tomi Valkeinen
Hi,
This series adds the arch/arm/ side of the display support for DRA7 (DRA72x,
DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards
is added.
This series is v2, and is based on Tero's [PATCHv5 00/35] ARM: OMAP2+:
PRCM/SCM cleanups against 4.0-rc series. The difference
DRA72 EVM has a HDMI output. This patch adds the device tree nodes
required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra72-evm.dts | 110
1 file changed, 110 insertions(+)
diff
DESHDCP clock is needed on DRA7 based SoCs to enable the DSS IP. That
clock is an odd one, as it is not supposed to be any kind of core clock
for DSS, and we don't even support HDCP, but the clock is still needed
even for the HWMOD framework to be able to reset the DSS IP.
As there's no support
Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
nodes required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 +
1 file changed, 81 insertions(+)
We need set-rate-parent flags for the display's clock path so that the
DSS driver can change the clock rate of the PLL.
This patchs adds the ti,set-rate-parent flag to 'dss_dss_clk' clock
node, which is only a gate clock, allowing the setting of the clock rate
to propagate to the PLL.
Add platform code to detect DRA7 DSS.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 9868d0bc7805..6ab13d18c636 100644
---
Simplify the DSS detection logic by creating a list of the omapdss
compat strings, instead of checking each separately with an 'if'.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 29 ++---
1 file changed, 14 insertions(+), 15
Add a new Linux clock for DRA7 based SoCs to control DESHDCP clock.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 5 +
arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
Set DSS core hwmod as the parent for all the DSS submodules.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
On 03/24/15 14:50, Tomi Valkeinen wrote:
Hi,
On 18/03/15 11:06, Jyri Sarha wrote:
I think the patches 1-5 are ready for merging. See the details below.
I applied these on top of v4.0-rc3, booted up BBB, and loaded the modules.
After doing that and waiting a few secs:
# ./s-bbb.sh
[
Quoting Tero Kristo (2015-03-24 12:06:41)
Hi Mike,
Here are the TI clock driver patches meant for 4.1 merge window.
Some simple data fixes, dm81xx FAPLL changes, and a generic TI clock
driver register access fix taken from the PRCM/SCM set I have posted to
linux-omap list earlier.
Here are some basic OMAP test results for Linux v4.0-rc5.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v4.0-rc5/20150324122259/
Test summary
Build: uImage:
Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only,
On 03/20/2015 01:31 PM, Jyri Sarha wrote:
Set rule constraints to allow only combinations of sample-rate,
sample-format, and channels counts that can be played/captured with
reasonable sample-rate accuracy.
The logic with tdm-slots and serializers (=i2s data wires) goes like
this: The first
On Tue, Mar 24, 2015 at 09:26:48AM -0500, Nishanth Menon wrote:
On 12:19-20150324, Roger Quadros wrote:
We need to enable EXTCON_USB_GPIO_USB and not
EXTCON_GPIO_USB.
Fixes: c08a54c0ebeb (ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB)
Reported-by: Nishant Menon n...@ti.com
* Tony Lindgren t...@atomide.com [150323 08:58]:
* Tero Kristo t-kri...@ti.com [150323 06:25]:
This code is generating these compile time warnings for me:
CC drivers/clk/ti/fapll.o
drivers/clk/ti/fapll.c: In function ‘ti_fapll_synth_set_rate’:
drivers/clk/ti/fapll.c:394:5:
On 09:31-20150324, Ard Biesheuvel wrote:
On 24 March 2015 at 01:45, Simon Horman ho...@verge.net.au wrote:
Hi Ard,
I have observe what appears to be a build regression in next-20150323
caused by 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page).
# make
...
arm-unknown
On 11:44-20150324, Felipe Balbi wrote:
On Tue, Mar 24, 2015 at 09:26:48AM -0500, Nishanth Menon wrote:
On 12:19-20150324, Roger Quadros wrote:
We need to enable EXTCON_USB_GPIO_USB and not
EXTCON_GPIO_USB.
Fixes: c08a54c0ebeb (ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB
On Tue, Mar 24, 2015 at 11:57:54AM -0500, Nishanth Menon wrote:
On 11:44-20150324, Felipe Balbi wrote:
On Tue, Mar 24, 2015 at 09:26:48AM -0500, Nishanth Menon wrote:
On 12:19-20150324, Roger Quadros wrote:
We need to enable EXTCON_USB_GPIO_USB and not
EXTCON_GPIO_USB.
Fixes
On Sun, Jan 18, 2015 at 09:24:47PM +0100, Pavel Machek wrote:
When periodic mode is not enabled, it is neccessary to force reads.
Signed-off-by: Pavel Machek pa...@ucw.cz
This is a malformed patch. here is patch output (or git am)
patching file drivers/thermal/ti-soc-thermal/ti-bandgap.c
On Fri, Mar 20, 2015 at 01:31:08PM +0200, Jyri Sarha wrote:
Set rule constraints to allow only combinations of sample-rate,
sample-format, and channels counts that can be played/captured with
reasonable sample-rate accuracy.
Applied, thanks.
signature.asc
Description: Digital signature
On 03/16/2015 12:40 PM, Peter Ujfalusi wrote:
Hi,
This series will fix the following error during boot (both DT and legacy boot):
[0.307739] omap_hwmod: mcbsp2: _wait_target_ready failed: -16
[0.307769] omap_hwmod: mcbsp2: cannot be enabled for reset (3)
The clock definitions/aliases
Hi Mike,
Here are the TI clock driver patches meant for 4.1 merge window.
Some simple data fixes, dm81xx FAPLL changes, and a generic TI clock
driver register access fix taken from the PRCM/SCM set I have posted to
linux-omap list earlier.
-Tero
On 03/14/2015 12:58 AM, Suman Anna wrote:
Hi Tero,
Please find couple of cleanup/fixes on the DT clock aliases
for the GPTimers. Patches are based on 4.0-rc1 and following
is the summary of the changes,
1. Patch 1 is a cleanup for OMAP4
2. Patch 2 fixes the failures for OMAP5 if
On 03/20/2015 08:44 PM, Tero Kristo wrote:
There is a case where NULL can be a valid return value for
ti_clk_get_reg_addr, specifically the case where both the provider index
and register offsets are zero. In this case, the current error checking
against a NULL pointer will fail. Thus, change
On 03/24/2015 06:37 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [150323 08:58]:
* Tero Kristo t-kri...@ti.com [150323 06:25]:
This code is generating these compile time warnings for me:
CC drivers/clk/ti/fapll.o
drivers/clk/ti/fapll.c: In function
On 03/24/2015 01:06 PM, Paul Walmsley wrote:
On Mon, 16 Mar 2015, Suman Anna wrote:
GPTimer 4 is a regular timer and not a secure timer, so fix
the hwmod to use the correct hwmod class (even though there
are no differences in the class definition itself).
Signed-off-by: Suman Anna
hi Nikita,
On Tue, Mar 24, 2015 at 1:37 PM, Nikita Kiryanov nik...@compulab.co.il wrote:
Hi Eliad,
On 03/18/2015 06:38 PM, Eliad Peller wrote:
Add device-tree support to the wlcore (wl12xx/wl18xx)
driver.
Update the current users to use the bindings instead
of pdata-quirks.
Finally,
On 24/03/15 16:28, Jyri Sarha wrote:
I tried first with 3.19 and then with 4.0-rc5, checked the boot and then
the modetest, but I could not reproduce the trace above.
In my config I just have CONFIG_DRM=m and CONFIG_DRM_I2C_NXP_TDA998X=m
on top of plain omap2plus_defconfig. Should I take
On Mon, Mar 23, 2015 at 02:39:39PM -0500, Nishanth Menon wrote:
BeagleBoard-X15 has capability for a fan and has an onboard TMP102
temperature sensor as well. This allows us to create a new thermal
zone (called, un-imaginatively board), and allows us to use some
active cooling as temperatures
On 03/24/15 17:16, Tomi Valkeinen wrote:
On 24/03/15 16:28, Jyri Sarha wrote:
I tried first with 3.19 and then with 4.0-rc5, checked the boot and then
the modetest, but I could not reproduce the trace above.
In my config I just have CONFIG_DRM=m and CONFIG_DRM_I2C_NXP_TDA998X=m
on top of
Hijack external connectors helper funcs to filter modes. TILCDC crtc
wants to have its say on which modes are valid. There appears to be no
trivial way to do that directly from crtc. This patch goes and hijacks
the external connectors helper functions and puts its own mode_valid()
function there.
Hi Tero,
On 03/20/2015 01:44 PM, Kristo, Tero wrote:
This patch creates an l4_wkup interconnect for AM43xx, and moves some of
the generic peripherals under it. System control module nodes are moved
under this new interconnect also, and the SCM clock layout is changed
to use the renamed SCM
On Mon, 16 Mar 2015, Suman Anna wrote:
GPTimer 4 is a regular timer and not a secure timer, so fix
the hwmod to use the correct hwmod class (even though there
are no differences in the class definition itself).
Signed-off-by: Suman Anna s-a...@ti.com
This one results in compiler warnings:
On Mon, 16 Mar 2015, Suman Anna wrote:
Add the hwmod data for GPTimers 13, 14, 15 and 16. All these
timers are present in the L4PER3 clock domain.
The corresponding DT nodes are already present but disabled.
Signed-off-by: Suman Anna s-a...@ti.com
---
47 matches
Mail list logo
