On 08/17/2012 12:32 AM, Hiremath, Vaibhav wrote:
On Thu, Aug 16, 2012 at 22:27:42, Hunter, Jon wrote:
On 08/15/2012 04:13 AM, Vaibhav Hiremath wrote:
On 7/14/2012 3:56 AM, Jon Hunter wrote:
OMAP3 devices may or may not have security features enabled. Security
enabled
devices are known
Hi Afzal,
Sorry for the delay, I have been out of the office.
On 08/06/2012 08:38 AM, Mohammed, Afzal wrote:
Hi Tony, Jon,
On Wed, Jul 11, 2012 at 12:17:25, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120710 10:20]:
The DT node should simply have the information required
| GPMC_HAS_WR_DATA_MUX_BUS;
printk(KERN_INFO GPMC revision %d.%d\n, (l 4) 0x0f, l 0x0f);
/* Set smart idle mode and automatic L3 clock gating */
l = gpmc_read_reg(GPMC_SYSCONFIG);
Reviewed-by: Jon Hunter jon-hun...@ti.com
Thanks!
Jon
--
To unsubscribe from this list: send the line unsubscribe
, const struct gpmc_timings *t);
extern int gpmc_cs_request(int cs, unsigned long size, unsigned long *base);
extern void gpmc_cs_free(int cs);
Reviewed-by: Jon Hunter jon-hun...@ti.com
Thanks!
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
Hi Afzal,
On 08/21/2012 05:45 AM, Afzal Mohammed wrote:
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime
Hi Afzal,
On 08/27/2012 05:37 AM, Mohammed, Afzal wrote:
On Thu, Aug 23, 2012 at 08:28:44, Hunter, Jon wrote:
[snip]
I understand that this is based upon how timings for onenand and tusb
are being calculated today, but I am not sure that this is the way to go
for all devices. Personally, I
. Although this is a regression from
the original code it only impacts performance and so is not needed for stable.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |3 +--
arch/arm/plat-omap/dmtimer.c | 14 +-
arch/arm/plat-omap
runs test #3 and #4 for
each available timer
Jon Hunter (10):
ARM: OMAP3+: Implement timer workaround for errata i103 and i767
ARM: OMAP: Fix timer posted mode support
ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations
ARM: OMAP2/3: Define HWMOD software reset status
for the dmtimer. Currently the watchdog driver does
not read the counter register and so no workaround is necessary.
Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |9 +++
arch/arm
. Therefore, remove one of the SYSC register definitions for the
DMTIMERs and ensure the appropriate register fields are defined for all
DMTIMERs.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 27 ++-
1 file changed, 6
of the DMTIMER
TISTAT register (referred to as the SYSS register in HWMOD). Add the
appropriate HWMOD definitions so that HWMOD will check the software reset
status when performing a software reset of the DMTIMER.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2
does not have the
clock-activity field and so when we reset the timer for an OMAP1 device we
only need to configure the idle-mode field in the TIOCP_CFG register.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 40 +
arch/arm
H4, OMAP3430 Beagle and OMAP4430 Panda that HWMOD is
configuring the dmtimer OCP_CFG register as expected for clock-events timer.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 13 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
have separate interrupt enable/disable registers and so this will not work.
Therefore, add a dedicated function to disable interrupts.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 31 +
arch/arm/plat-omap/include/plat
structure. So instead of looking up the clock again used the clock handle
that stored in the omap_dm_timer structure.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm/plat-omap
timer, the function omap_dm_timer_reset() is now only being called for OMAP1
devices and OMAP1 does not use timer1 as a system timer. Therefore, remove the
check in omap_dm_timer_reset() so that timer1 is reset for OMAP1 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap
that is also being passed to the above
functions and therefore we do not need to pass the posted variable separately.
Therefore, simplify the above functions by removing the posted variable as an
argument as this is not necessary.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c
Hi Afzal,
On 09/05/2012 07:37 AM, Afzal Mohammed wrote:
Add gpmc hwmod and associated interconnect data
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 18 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 18 +++
the above as ...
WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name);
return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
+}
+postcore_initcall(omap_gpmc_init);
+
static irqreturn_t gpmc_handle_irq(int irq, void *dev)
{
int i;
Otherwise ...
Reviewed-by: Jon Hunter
Hi Afzal,
On 09/05/2012 07:37 AM, Afzal Mohammed wrote:
Create a minimal driver out of gpmc code.
Responsibilities handled by earlier gpmc
initialization is now achieved in probe.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
Cheers
Jon
On 09/06/2012 07:57 AM, Vaibhav Hiremath wrote:
On 9/6/2012 12:34 AM, Jon Hunter wrote:
Currently the dmtimer posted mode is being enabled when the function
__omap_dm_timer_reset() is called. This function is only being called for
OMAP1 timers and OMAP2+ timers that are being used
On 09/06/2012 07:58 AM, Vaibhav Hiremath wrote:
On 9/6/2012 12:34 AM, Jon Hunter wrote:
The OMAP dmtimer driver does not currently have a function to disable the
timer interrupts. For some timer instances the timer interrupt enable
function can be used to disable the interrupts because
On 09/06/2012 09:06 AM, Jon Hunter wrote:
On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
On 9/6/2012 12:34 AM, Jon Hunter wrote:
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer registers
after wakeup (OMAP3/4)
i767: Delay needed to read some GP
On 09/06/2012 09:42 AM, Jon Hunter wrote:
On 09/06/2012 09:06 AM, Jon Hunter wrote:
On 09/06/2012 12:07 AM, Vaibhav Hiremath wrote:
On 9/6/2012 12:34 AM, Jon Hunter wrote:
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer registers
after wakeup
On 09/06/2012 09:20 AM, Jon Hunter wrote:
On 09/06/2012 07:57 AM, Vaibhav Hiremath wrote:
On 9/6/2012 12:34 AM, Jon Hunter wrote:
Currently the dmtimer posted mode is being enabled when the function
__omap_dm_timer_reset() is called. This function is only being called for
OMAP1 timers
On 09/06/2012 08:45 AM, Rob Herring wrote:
On 07/23/2012 10:24 AM, Jon Hunter wrote:
[snip]
Do you have any inputs on the above? Does it make sense to reserve timer
resources for kernel system timers in device-tree?
This issue is not unique to omap. So if we do specify clockevent
Hi Tony,
On 08/30/2012 03:14 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120816 08:05]:
On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
Did we get conclude on this? I haven't got anything further on this
thread, this may block baseport support for the new devices in omap2
On 09/07/2012 03:56 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120907 13:27]:
Hi Tony,
On 08/30/2012 03:14 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120816 08:05]:
On 08/15/2012 04:11 AM, Vaibhav Hiremath wrote:
Did we get conclude on this? I haven't got
runtime PM.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2
/074153.html
Cc: Ming Lei ming@canonical.com
Cc: Will Deacon will.dea...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/pmu.c |9 -
1 file changed, 8
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Jon Hunter (6):
ARM: OMAP3: Add debugss HWMOD data
ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD
ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS
ARM: OMAP2+: PMU: Add runtime
, OMAP4460 and OMAP4470 devices can use the same list of HWMODs to create
the PMU device that is using by OMAP3.
Cc: Ming Lei ming@canonical.com
Cc: Will Deacon will.dea...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Jon
-by: Will Deacon will.dea...@arm.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/pmu.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 1de52ed..7c137be 100644
--- a/arch/arm/mach-omap2/pmu.c
Hilman to de-clutter devices.c.
Cc: Ming Lei ming@canonical.com
Cc: Will Deacon will.dea...@arm.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/Makefile
/ Omap4 on pandabo...@googlegroups.com.
Ming's original patch was called arm: omap4: support pmu [1] and has been
renamed and modified by Jon Hunter. There main differences from the original
patch are ...
1. Instead of only configuring the CTI interrupt once during boot, the
interrupts
-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/pmu.c | 49 +++--
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 7fbaa3f..ca158f0 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b
On 09/07/2012 05:22 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120905 12:05]:
The dmtimer functions to read and write the dmtimer registers are currently
defined as follows ...
static inline u32 __omap_dm_timer_read(struct omap_dm_timer *timer, u32 reg
board XM
dts file [1].
[1] http://marc.info/?l=linux-omapm=134695790516943w=2
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts |6 -
arch/arm/boot/dts/omap3-beagle.dts| 46 +
arch/arm/boot/dts/twl4030.dtsi
].
V2 changes
- Rebased upon of devel-dt
- Corrected copyright date in omap3-beagle.dts file
- Added LED support after verifing that Beagle and Beagle XM have the same LED
configuration
[1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git devel-dt
Signed-off-by: Jon Hunter jon-hun
On 09/10/2012 07:58 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120910 15:00]:
On 09/07/2012 05:22 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120905 12:05]:
The dmtimer functions to read and write the dmtimer registers are currently
defined as follows ...
static
Hi Henry
On 7/1/2011 1:10 PM, hong zhang wrote:
List,
I try to get gpio_191 ping interrupted on panda but never succeeded. What I do
is
1. set 0x410b on dpm_emu19 register to enable interrupt and wakeup
on gpio_191
2. set bit 31 to 1 on GPIO_IRQSTATUS_SET_0 register at 0x4805d034
3. set
From: Jon Hunter jon-hun...@ti.com
Various clock fixes for OMAP3 and OMAP4 devices.
Plus one debug patch (if anyone is interested).
Jon Hunter (4):
OMAP4: Add missing clock divider for OCP_ABE_ICLK
OMAP3+: use DPLLs recalc function instead of omap2_get_dpll_rate
OMAP3+: Update DPLL Fint
From: Jon Hunter jon-hun...@ti.com
The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
parent clock of the AESS_FCLK is the ABE_FCLK...
ABE_FCLK -- AESS_FCLK -- OCP_ABE_ICLK
The AESS_FCLK and OCP_ABE_ICLK clocks both have dividers which
determine their operational frequency. However
the REGM4XEN bit.
The REGM4XEN bit is only implemented for the ABE DPLL on OMAP4 and so
only dpll_abe_ck uses omap4_dpll_regm4xen_round_rate() and
omap4_dpll_regm4xen_recalc() functions.
Signed-off-by: Mike Turquette mturque...@ti.com
Tested-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2
From: Mike Turquette mturque...@ti.com
omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly. Instead
use the struct clk pointer's round_rate function to allow for DPLL's with
special needs.
Also the rounded rate can differ from target rate, so to better reflect
reality set clk-rate
From: Jon Hunter jon-hun...@ti.com
This is a continuation of Mike Turquette's patch OMAP3+: use
DPLL's round_rate when setting rate.
omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
omap2_get_dpll_rate() explicitly. It may be necessary for some
DPLLs to use a different function
From: Jon Hunter jon-hun...@ti.com
The OMAP36xx and OMAP4xxx DPLLs have a different internal reference
clock frequency (fint) operating range than OMAP3430. Update the
dpll_test_fint() function to check for the correct frequency ranges
for OMAP36xx and OMAP4xxx.
For OMAP36xx and OMAP4xxx devices
From: Jon Hunter jon-hun...@ti.com
Add a debugfs node called summary to /sys/kernel/debug/clock/
that displays a quick summary of all clocks registered in the
clocks structure. The format of the output from this node is:
clock-name parent-name rate usecount
This debugfs node was very helpful
Hi Paul,
On 7/15/2011 3:21, Paul Walmsley wrote:
cc'ing Benoît
Hi Jon
On Thu, 14 Jul 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
parent clock of the AESS_FCLK is the ABE_FCLK...
ABE_FCLK -- AESS_FCLK
Hi Paul,
On 7/15/2011 3:16, Paul Walmsley wrote:
Hi Jon
On Thu, 14 Jul 2011, Jon Hunter wrote:
From: Jon Hunterjon-hun...@ti.com
Various clock fixes for OMAP3 and OMAP4 devices.
Plus one debug patch (if anyone is interested).
Jon Hunter (4):
OMAP4: Add missing clock divider
On 7/15/2011 9:34, Jon Hunter wrote:
2). The ocp_abe_iclk is an interface clock and is not a parent to any
other functional clock and therefore, is not driving any internal logic
in a peripheral which would have a direct impact of the speed of that
peripheral. However, there does appear
On 7/18/2011 15:57, Jon Hunter wrote:
On further inspection of the clock44xx_data.c, it appears that all
interface clocks are called xxx_fck and not xxx_ick. I will ask Benoit
about this. However, this particular clock we are dealing with here is
an interface clock.
Actually, the above
On 09/11/2012 11:34 AM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120911 09:26]:
On 09/10/2012 07:58 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120910 15:00]:
On 09/07/2012 05:22 PM, Tony Lindgren wrote:
* Jon Hunter jon-hun...@ti.com [120905 12:05]:
The dmtimer
Oops meant to have Paul on the TO! Jon
On 09/10/2012 10:23 AM, Jon Hunter wrote:
To enable PMU with runtime PM support on OMAP3 devices we need to be able to
dynamically enable and disable the debug sub-system at runtime. By adding
HWMOD
data for the debug sub-system for OMAP3, we can build
...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Signed-off-by: Jon Hunter jon-hun
: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Jon Hunter (2):
of: Add generic device tree DMA helpers
dmaengine: add helper function to request a slave DMA channel
Documentation/devicetree/bindings/dma/dma.txt | 62 +++
drivers/dma/dmaengine.c | 16
: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Documentation/devicetree/bindings
a bug when using a GP-timer as the
clock-source!
V2 changes:
- Remove use of device-tree alias property
- Migrate OMAP timers to request timers by property instead of device ID
- Include OMAP2 support
Jon Hunter (7):
ARM: dts: OMAP: Add timer nodes
ARM: OMAP3: Dynamically disable secure timer
aliases for the same clocks to only
temporary until device-tree migration is complete. Then we can remove the legacy
aliases. Hence, I have marked the legacy aliases with a TODO to remove them.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 12
on which timers support a PWM
output.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
.../devicetree/bindings/arm/omap/timer.txt | 30 ++
arch/arm/boot/dts/am33xx.dtsi | 61 +
arch/arm/boot/dts/omap2.dtsi
- DMTIMERs 5-8
Please note that for OMAP3+, timer8 has the ability to interrupt the DSP and
generate a PWM output.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap1/timer.c|2 +-
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |9
with this feature.
Therefore, add a new API called omap_dm_timer_request_by_cap() that allows
drivers to request a timer by capability.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 53 +
arch/arm/plat-omap/include/plat/dmtimer.h
/gmane.linux.ports.arm.omap/79203
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|1 +
arch/arm/mach-omap2/timer.c | 35 +++
3 files changed, 37 insertions(+)
diff
attribute
flags.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c | 96 +-
arch/arm/plat-omap/dmtimer.c | 41 +++---
2 files changed, 112 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b
instead of the default.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 20124d7..68a5c3b 100644
--- a/arch/arm
On 09/13/2012 06:31 PM, Jon Hunter wrote:
This series adds device-tree support for the timers on OMAP2+ devices
including AM33xx.
One more comment. This has been tested on v3.6-rc5 and rebased on top of
Tony's devel-dt branch.
Cheers
Jon
--
To unsubscribe from this list: send the line
explains why
I did not catch this when testing on OMAP2420.
Fix the clock flags for these aliases for correctness.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2
Hi Arnd,
On 09/14/2012 04:43 AM, Arnd Bergmann wrote:
On Thursday 13 September 2012, Jon Hunter wrote:
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
I think
On 09/14/2012 08:32 AM, Arnd Bergmann wrote:
On Friday 14 September 2012, Jon Hunter wrote:
On 09/14/2012 04:43 AM, Arnd Bergmann wrote:
+
+Client drivers should specify the DMA property using a phandle to the
controller
+followed by DMA controller specific data.
+
+Required property
/gmane.linux.ports.arm.omap/73622
[3] http://marc.info/?l=linux-omapm=133582085008539w=2
Jon Hunter (2):
of: Add generic device tree DMA helpers
dmaengine: add helper function to request a slave DMA channel
Documentation/devicetree/bindings/dma/dma.txt | 80 +
drivers/dma
...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Signed-off-by: Jon Hunter jon-hun
Bergmann a...@arndb.de
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Documentation/devicetree/bindings/dma/dma.txt | 80 +
drivers/of/Makefile |2 +-
drivers/of/dma.c
On 09/14/2012 11:28 AM, Stephen Warren wrote:
On 09/13/2012 04:00 PM, Jon Hunter wrote:
This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
to add some basic helpers to retrieve a DMA controller device_node and the
DMA request/channel information.
diff --git
On 09/14/2012 10:26 AM, Arnd Bergmann wrote:
On Friday 14 September 2012, Jon Hunter wrote:
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
-cells required (no fallback anymore)
- another check in of_dma_xlate_onenumbercell() function
[1] http://article.gmane.org/gmane.linux.drivers.devicetree/12022
[2] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
[3] http://marc.info/?l=linux-omapm=133582085008539w=2
Jon Hunter (2
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/dma/dmaengine.c | 16
include/linux/dmaengine.h |6 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 3491654..9b466da 100644
--- a/drivers/dma/dmaengine.c
...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Reviewed-by: Arnd Bergmann a...@arndb.de
Reviewed-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
Documentation
Hi Paul,
On 09/20/2012 12:13 PM, Paul Walmsley wrote:
On Wed, 19 Sep 2012, Paul Walmsley wrote:
On Mon, 10 Sep 2012, Jon Hunter wrote:
To enable PMU with runtime PM support on OMAP3 devices we need to be able to
dynamically enable and disable the debug sub-system at runtime. By adding
Hi Paul,
On 09/20/2012 12:14 PM, Paul Walmsley wrote:
Hi
On Mon, 10 Sep 2012, Jon Hunter wrote:
When CPU-idle is enabled, the MPU sub-system will transition to low power
states during idle periods. If the PMU is active and the MPU sub-system
transitions to a low power state
On 09/20/2012 11:59 AM, Paul Walmsley wrote:
Hi
On Mon, 10 Sep 2012, Jon Hunter wrote:
From: Ming Lei ming@canonical.com
For OMAP4430 there are no dedicate PMU interrupts, however, PMU events can be
routed to via the CTI IRQs. This allows tools such as PERF and OPROFILE to
work
). The definition
of the PMU interrupts on OMAP2/3 devices is missing the OMAP_INTC_START offset
and so this is causing the allocation of PMU interrupts to fail on OMAP2/3
devices. So add the offset to fix this.
This is patch is based upon the Tony's master branch for OMAP.
Signed-off-by: Jon Hunter jon-hun
Hi Paul,
On 09/20/2012 12:17 PM, Paul Walmsley wrote:
Hi Jon, Will, Ming, et al.,
Have queued most of these for 3.7 with the exception of the OMAP4430
CTI-related patches (which look to me like 3.8 material) and the PM
runtime suspend/resume patch (which looks to me like 3.7-rc
Hi Will,
On 09/20/2012 04:09 PM, Will Deacon wrote:
On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote:
Hi Jon, Will, Ming, et al.,
Hi Paul,
Have queued most of these for 3.7 with the exception of the OMAP4430
CTI-related patches (which look to me like 3.8 material) and the
Hi Vinod,
On 09/17/2012 10:13 PM, Vinod Koul wrote:
On Mon, 2012-09-17 at 23:36 +0100, Russell King - ARM Linux wrote:
I believe that Jon is on vacation this week, so if this is the only issue
holding up the merge, maybe you can change this in his patch directly, or
I can send an updated
-by: Matt Porter mpor...@ti.com
Acked-by: Jon Hunter jon-hun...@ti.com
Thanks for catching and fixing these!
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
vinod.k...@intel.com
Cc: Dan Williams d...@fb.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/of/dma.c | 60 +++---
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index 19ad37c..4bed490
Hi All,
I appear to be having problems receiving emails being sent to me by the
mailing lists. I did not receive any of the responses to this patch set,
but I know see online that there have been a few responses. So sorry for
not responding.
I have been complaining to our IT department but all
Hi Rob,
On 09/13/2012 06:31 PM, Jon Hunter wrote:
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID
On 09/20/2012 06:53 PM, Tony Lindgren wrote:
* Benoit Cousson b-cous...@ti.com [120919 19:24]:
Hi Tony,
I was about to take the DTS patch, but was wondering if you will pull
the driver changes for 3.7.
I suggest that you do a separate branch on top of Paul's hwmod series
when he posts
Hi Afzal,
On 09/19/2012 08:23 AM, Afzal Mohammed wrote:
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime
Hi Afzal,
On 09/27/2012 05:07 AM, Mohammed, Afzal wrote:
Hi Jon,
On Thu, Sep 27, 2012 at 08:54:22, Hunter, Jon wrote:
On 09/19/2012 08:23 AM, Afzal Mohammed wrote:
+Dependency of peripheral timings on gpmc timings:
+
+cs_on: t_ceasu
Thanks for adding these details. Could be good to
Hi Tony,
On 09/27/2012 03:26 PM, Tony Lindgren wrote:
Please see below a status update on the remaining problem
plat headers.
Note that all patches should be against current linux next
in this case.
[snip]
dmtimer.h
Jon, can you do a patch for dmtimer.h?
Yes, I will look into this.
On 09/28/2012 10:54 AM, Russell King - ARM Linux wrote:
On Fri, Sep 28, 2012 at 08:05:38AM -0700, Tony Lindgren wrote:
* Shilimkar, Santosh santosh.shilim...@ti.com [120928 08:02]:
On Fri, Sep 28, 2012 at 8:25 PM, Tony Lindgren t...@atomide.com wrote:
* Lokesh Vutla lokeshvu...@ti.com
On 09/28/2012 01:51 PM, Vaibhav Hiremath wrote:
On 9/26/2012 10:23 PM, Jon Hunter wrote:
On 09/20/2012 06:53 PM, Tony Lindgren wrote:
* Benoit Cousson b-cous...@ti.com [120919 19:24]:
Hi Tony,
I was about to take the DTS patch, but was wondering if you will pull
the driver changes
On 09/28/2012 01:51 PM, Vaibhav Hiremath wrote:
On 9/26/2012 10:23 PM, Jon Hunter wrote:
On 09/20/2012 06:53 PM, Tony Lindgren wrote:
* Benoit Cousson b-cous...@ti.com [120919 19:24]:
Hi Tony,
I was about to take the DTS patch, but was wondering if you will pull
the driver changes
On 09/28/2012 01:51 PM, Vaibhav Hiremath wrote:
[snip]
Jon,
Sorry for delayed response, But I tried using your omap_test application
to validate this patch series, but it is failing for me.
How did you test it? Are you running same test application at your end?
I am debugging this
On 10/01/2012 04:45 AM, Will Deacon wrote:
On Mon, Sep 24, 2012 at 10:45:06PM +0100, Jon Hunter wrote:
On 09/20/2012 04:09 PM, Will Deacon wrote:
On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote:
Have queued most of these for 3.7 with the exception of the OMAP4430
CTI-related
Hi Tony,
On 10/04/2012 05:04 PM, Tony Lindgren wrote:
We can move this from plat to be local to plat-omap
for common ARM zImage support.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/clock.c |3 -
arch/arm/mach-omap1/clock_data.c |
that is a mistake? If so the below fixes this.
Cheers
Jon
From 16db11f3373bc6e03254c4d1d92ee762f69cbacc Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Wed, 1 Aug 2012 09:36:13 -0600
Subject: [PATCH] ARM: OMAP3: fix workaround for EMU clockdomain
Commit b71c721 (ARM: OMAP2
101 - 200 of 1153 matches
Mail list logo
