rking
correctly as these boards use a GPIO with the ethernet chips. Also
checked /proc/interrupts to ensure GPIO interrupt counts are
incrementing as expected.
[1] http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git
Jon Hunter (4):
gpio/omap: free irq domain in probe() failure
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
probe does fail. Furthermore, the local variable "ret" is not needed
and so remove this.
Signed-off-by: Jon Hunter
---
drivers/gpio/gpio-oma
-triggered since only edge-triggered gpios can generate
wakeup events. Therefore, the old context restores of the same
registers present later in the code is not needed any more.
Remove them.
Signed-off-by: Tarun Kanti DebBarma
Signed-off-by: Jon Hunter
---
drivers/gpio/gpio-omap.c |4
state.
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/gpio/gpio-omap.txt |7 --
drivers/gpio/gpio-omap.c | 25 +---
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
of the first set bit, to find all the set
bits.
This optimisation was suggested-by and developed in collaboration
with Felipe Balbi.
Cc: Felipe Balbi
Signed-off-by: Jon Hunter
---
drivers/gpio/gpio-omap.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a
Add the "ti,gpio-always-on" property to the appropriate GPIO banks to
indicate which banks are always powered and will never lose logic state.
Cc: Benoit Cousson
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2420.dtsi |4
arch/arm/boot/dts/omap2430.dtsi |4
On 04/04/2013 03:35 PM, Tony Lindgren wrote:
> * Jon Hunter [130404 13:21]:
>> Add the "ti,gpio-always-on" property to the appropriate GPIO banks to
>> indicate which banks are always powered and will never lose logic state.
>
> This patch should be queued by B
On 04/05/2013 01:35 AM, Santosh Shilimkar wrote:
> On Friday 05 April 2013 01:46 AM, Jon Hunter wrote:
>> Main change is ensuring that the state of a gpio bank is restored when
>> booting with device-tree. The rest of the patches are clean-ups and one
>> optimisation.
>
Add device-tree node for the 128MB NOR on the OMAP3423-SDP board.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap3430-sdp.dts | 51 +++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
b/arch/arm/boot/dts
Add device-tree node for the 64MB NOR on the OMAP2420-H4 board.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2420-h4.dts | 46 +
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420-h4.dts
b/arch/arm/boot/dts/omap2420-h4.dts
The GPMC timing properties for device-tree have been updated by adding
a "-ns" or "-ps" suffix to indicate the units of time the property
represents (as suggested by Rob Herring). Therefore, update the timing
property names for the OMAP3430 SDP NAND and ONENAND devices.
Signe
On 04/07/2013 08:17 PM, Jon Hunter wrote:
> Add device-tree node for the 128MB NOR on the OMAP3423-SDP board.
Bugger ... it seems I have invented and new board. OMAP3423 SDP
does not exist. Fixed below.
Jon
>From 4f486b5dddc5d960d786504b4e3e97a28b63c1c0 Mon Sep 17 00:00:00 2001
Fro
+ gpmc,adv-wr-off-ns = <48>;
> + gpmc,oe-on-ns = <54>;
> + gpmc,oe-off-ns = <168>;
> + gpmc,we-on-ns = <54>;
> + gpmc,we-off-ns = <168>;
> + gpmc,rd-cycle-ns = <186>;
> +
The GPMC timing properties for device-tree have been updated
by adding a "-ns" or "-ps" suffix to indicate the units of
time the property represents. Therefore, update the timing
property names for TI GPMC NAND example.
Signed-off-by: Jon Hunter
---
.../devicetree/bindin
[1] comments.gmane.org/gmane.linux.ports.arm.omap/92192
>From ed3e66bcd4c0cb3df4cb70e75c45fa4462f70565 Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Wed, 10 Apr 2013 11:44:44 -0500
Subject: [PATCH] ARM: dts: OMAP4: Fix ethernet IRQ for OMAP4 boards
Commit ff5c9059 (ARM: dts: OMAP3+: Correct gpio #interrupts-c
On 04/10/2013 02:39 PM, Linus Walleij wrote:
> On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter wrote:
>
>> When booting with device-tree the function pointer for detecting context
>> loss is not populated. Ideally, the pm_runtime framework should be
>> enhanced to all
On 04/10/2013 02:33 PM, Linus Walleij wrote:
> On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter 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
>> probe does fail
On 04/10/2013 02:44 PM, Linus Walleij wrote:
> On Wed, Apr 10, 2013 at 9:41 PM, Jon Hunter wrote:
>> On 04/10/2013 02:39 PM, Linus Walleij wrote:
>>> On Thu, Apr 4, 2013 at 10:16 PM, Jon Hunter wrote:
>>>
>>>> When booting with device-tree the function poi
On 04/10/2013 01:20 PM, Tony Lindgren wrote:
> * Jon Hunter [130410 10:35]:
>> Hi Tony,
>>
>> On 04/09/2013 04:23 PM, Tony Lindgren wrote:
>>> Hi Jon,
>>>
>>> Looks like at least 4430sdp nfsroot got broken with commit
>>> ff5c9059 (ARM:
On 04/10/2013 03:54 PM, Tony Lindgren wrote:
> * Jon Hunter [130410 13:47]:
>>
>> On 04/10/2013 01:20 PM, Tony Lindgren wrote:
>>> * Jon Hunter [130410 10:35]:
>>>> Hi Tony,
>>>>
>>>> On 04/09/2013 04:23 PM, Tony Lindgren wrote:
>&
On 04/10/2013 06:58 PM, Javier Martinez Canillas wrote:
> On Wed, Apr 10, 2013 at 7:31 PM, Jon Hunter wrote:
>> Hi Tony,
>>
>> On 04/09/2013 04:23 PM, Tony Lindgren wrote:
>>> Hi Jon,
>>>
>>> Looks like at least 4430sdp nfsroot got broken with com
On 03/19/2013 08:30 AM, Santosh Shilimkar wrote:
> OMAP hwmod layer does the reset of the IPs in early code so that
> we have SOC in sane state. To do the soft-reset, it needs to ioremap()
> the ip address space to be able to write to sysconfig registers.
>
> But there are few hwmod which doesn't
On 04/11/2013 10:54 AM, Santosh Shilimkar wrote:
> On Thursday 11 April 2013 06:48 PM, Andreas Fenkart wrote:
>> Hi Santosh,
>>
>> I submitted the following patch a while back.
>> https://patchwork.kernel.org/patch/1886421/
>>
>> As already said, the patch is straight forward, but without it,
>> w
On 04/12/2013 07:06 PM, Tony Lindgren wrote:
> * Tony Lindgren [130410 15:32]:
>> * Jon Hunter [130410 15:30]:
>>>
>>> Are you saying that you want to use the version with that is using the
>>> pre-processor definitions? I was thinking that may be we could
On 04/15/2013 08:27 AM, Grant Likely wrote:
> On Tue, 19 Mar 2013 11:35:48 -0500, Jon Hunter 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-tr
On 04/13/2013 11:50 AM, Tony Lindgren wrote:
> * Jon Hunter [130412 19:22]:
>>
>> On 04/12/2013 07:06 PM, Tony Lindgren wrote:
>>> * Tony Lindgren [130410 15:32]:
>>>> * Jon Hunter [130410 15:30]:
>>>>>
>>>>> Are you saying
On 04/15/2013 11:57 AM, Jon Hunter wrote:
>
> On 04/13/2013 11:50 AM, Tony Lindgren wrote:
>> * Jon Hunter [130412 19:22]:
>>>
>>> On 04/12/2013 07:06 PM, Tony Lindgren wrote:
>>>> * Tony Lindgren [130410 15:32]:
>>>>> * Jon Hunter [130
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
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
>> wrote:
>>
>>> Is the following inlined patch [1] what you were thinking that would
>>> be the right approach?
>>
>> This looks sort of OK, b
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
>>> wrote:
>>>
>>>> Is the following
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
>
On 04/15/2013 04:27 PM, Tony Lindgren wrote:
> * Jon Hunter [130415 11:15]:
...
>> From 56598ba51a75481b050433bb38b7ae31a5ed4ae8 Mon Sep 17 00:00:00 2001
>> From: Jon Hunter
>> Date: Mon, 15 Apr 2013 13:06:54 -0500
>> Subject: [PATCH] gpio/omap: ensure gpio contex
On 04/16/2013 01:06 PM, Tony Lindgren wrote:
> * Jon Hunter [130416 10:19]:
>>
>> On 04/15/2013 04:27 PM, Tony Lindgren wrote:
>>> * Jon Hunter [130415 11:15]:
>>
>> ...
>>
>>>> From 56598ba51a75481b050433bb38b7ae31a5ed4ae8 Mon Sep 17 00:00
On 04/16/2013 01:40 PM, Stephen Warren wrote:
> On 04/15/2013 05:04 PM, Jon Hunter wrote:
>>
>> On 04/15/2013 05:16 PM, Stephen Warren wrote:
>>> On 04/15/2013 03:40 PM, Jon Hunter wrote:
> ...
>>>> mmc {
>>>>label =
On 04/16/2013 02:27 PM, Jon Hunter wrote:
...
> Right. In the DT case though, if someone does provide the IRQ and GPIO
> IDs then at least they would use a different xlate function. Another
> option to consider would be defining the #interrupt-cells = <3> where we
> would hav
On 04/16/2013 05:11 PM, Stephen Warren wrote:
> On 04/16/2013 01:27 PM, Jon Hunter wrote:
>>
>> On 04/16/2013 01:40 PM, Stephen Warren wrote:
>>> On 04/15/2013 05:04 PM, Jon Hunter wrote:
> ...
>>>> If some driver is calling gpio_request() directly, th
On 04/16/2013 07:41 PM, Javier Martinez Canillas wrote:
> On Wed, Apr 17, 2013 at 1:14 AM, Jon Hunter wrote:
>>
>> On 04/16/2013 05:11 PM, Stephen Warren wrote:
>>> On 04/16/2013 01:27 PM, Jon Hunter wrote:
>>>>
>>>> On 04/16/2013 01:40 PM, Stephen
On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
...
> There are so many patches flying around in this thread that I missed it :-)
>
> Sorry about that...
No problem.
>> I was trying to see if we could find a common solution that everyone
>> could use as it seems that ideally we should
On 04/17/2013 07:05 AM, Javier Martinez Canillas wrote:
...
> Yes, in fact I just realized that for_each_node_by_name() expand to:
>
> #define for_each_node_by_name(dn, name) \
> for (dn = of_find_node_by_name(NULL, name); dn; \
> dn = of_find_node_by_name(dn, name))
>
> w
On 04/17/2013 08:42 AM, Javier Martinez Canillas wrote:
> On Wed, Apr 17, 2013 at 3:25 PM, Jon Hunter wrote:
>>
>> On 04/17/2013 02:55 AM, Javier Martinez Canillas wrote:
>>
>> ...
>>
>>> There are so many patches flying around in this thread tha
On 04/17/2013 09:07 AM, Javier Martinez Canillas wrote:
> On 04/17/2013 03:48 PM, Jon Hunter wrote:
>>
>> On 04/17/2013 07:05 AM, Javier Martinez Canillas wrote:
>>
>> ...
>>
>>> Yes, in fact I just realized that for_each_node_by_name() expand to:
>
On 04/17/2013 11:37 AM, Javier Martinez Canillas wrote:
> The GPMC DT probe function use for_each_node_by_name() to search
> child device nodes of the GPMC controller. But this function does
> not use the GPMC device node as the root of the search and instead
> search across the complete Device Tr
On 04/17/2013 02:09 PM, Dan Murphy wrote:
> The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
> are different.
>
> Abstract away the pinmux and the LED definitions for the two boards.
Just a heads-up but you should base this upon Benoit's for_3.10 branch
[1] as there is now
for gpio banks that could lose their state regardless
of whether we are booting with device-tree or not.
Reported-by: Tony Lindgren
Signed-off-by: Jon Hunter
Tested-by: Tony Lindgren
---
drivers/gpio/gpio-omap.c | 53 +-
1 file changed, 43
device node as the search root so the
> search will be restricted to its children.
>
> Reported-by: Lars Poeschel
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Changes since v1 (suggested by Jon Hunter):
> - Split the search for GPMC child nodes and only w
On 04/17/2013 05:10 PM, Javier Martinez Canillas wrote:
> On 04/17/2013 11:27 PM, Jon Hunter wrote:
>>
>> On 04/17/2013 03:34 PM, Javier Martinez Canillas wrote:
>>> The GPMC DT probe function use for_each_node_by_name() to search
>>> child device nodes of the G
@@
> reg = <0x48086000 0x80>;
> interrupts = <0 46 0x4>;
> ti,hwmods = "timer10";
> + ti,timer-pwm;
> };
>
> timer11: timer@48088000 {
M
On 04/17/2013 06:23 PM, Suman Anna wrote:
> Some instances of the DMTIMER peripheral on OMAP4+ devices have the
> ability to interrupt the on-chip image processor unit (IPU) subsystem
> (a common name for the dual Cortex-M3 subsystem on OMAP4 or the dual
> Cortex-M4 subsystem on OMAP5) in addition
On 04/17/2013 07:04 PM, Jon Hunter wrote:
>
> On 04/17/2013 06:23 PM, Suman Anna wrote:
>> Some instances of the DMTIMER peripheral on OMAP4+ devices have the
>> ability to interrupt the on-chip image processor unit (IPU) subsystem
>> (a common name for the dual Cortex-
On 04/18/2013 03:22 AM, Santosh Shilimkar wrote:
> On Thursday 18 April 2013 02:01 AM, Jon Hunter wrote:
>> Commit a2797be (gpio/omap: force restore if context loss is not
>> detectable) broke gpio support for OMAP when booting with device-tree
>> because a restore of t
On 04/18/2013 01:21 PM, Anna, Suman wrote:
> Jon,
>
>>
>> On 04/17/2013 07:04 PM, Jon Hunter wrote:
>>>
>>> On 04/17/2013 06:23 PM, Suman Anna wrote:
>>>> Some instances of the DMTIMER peripheral on OMAP4+ devices have the
>>>>
On 04/18/2013 02:03 PM, Christoph Fritz wrote:
> Hi
>
> I'm trying to setup nand support for an omap3 board for linux-next
> (next-20130417). This is my approach so far:
>
>
> +&gpmc {
> + ranges = <0 0 0x3000 0x100>;
> + nand@0,0 {
> + reg = <0 0 0xff>;
On 04/18/2013 03:23 PM, Christoph Fritz wrote:
> Hi Jon
>
> On Thu, 2013-04-18 at 14:39 -0500, Jon Hunter wrote:
>> On 04/18/2013 02:03 PM, Christoph Fritz wrote:
>
>> I had put the complete size in here so ...
>>
>> +
Hi Kevin,
On 04/18/2013 04:34 PM, Kevin Hilman wrote:
> Hi Jon,
>
> Jon Hunter writes:
>
>> Commit a2797be (gpio/omap: force restore if context loss is not
>> detectable) broke gpio support for OMAP when booting with device-tree
>> because a restore of the gpio c
On 04/18/2013 05:48 PM, Christoph Fritz wrote:
> On Thu, 2013-04-18 at 17:28 -0500, Jon Hunter wrote:
>> On 04/18/2013 03:23 PM, Christoph Fritz wrote:
>
>
>>> OMAP3_EVM # md 0x6E60 7
>>> 6e60: 1800 00141400 00141400 0f010f01...
On 04/18/2013 06:24 PM, Jon Hunter wrote:
>
> On 04/18/2013 05:48 PM, Christoph Fritz wrote:
>> On Thu, 2013-04-18 at 17:28 -0500, Jon Hunter wrote:
>>> On 04/18/2013 03:23 PM, Christoph Fritz wrote:
>>
>>
>>>> OMAP3_EVM # md 0x6E60 7
>&
On 04/18/2013 06:10 PM, Jon Hunter wrote:
> On 04/18/2013 04:34 PM, Kevin Hilman wrote:
...
>> Why not just init context right here if bank->loses_context &&
>> !bank->context_valid?
I really like this idea a lot. It can really clean-up the code
and really make it
On 04/18/2013 07:34 PM, Jon Hunter wrote:
>
> On 04/18/2013 06:10 PM, Jon Hunter wrote:
>> On 04/18/2013 04:34 PM, Kevin Hilman wrote:
>
> ...
>
>>> Why not just init context right here if bank->loses_context &&
>>> !bank->context_valid?
&g
On 04/19/2013 04:01 AM, Christoph Fritz wrote:
> On Thu, 2013-04-18 at 18:26 -0500, Jon Hunter wrote:
>> On 04/18/2013 06:24 PM, Jon Hunter wrote:
>
>>>> To get the values right for dt-GPMC-NAND-Config, here are the GPMC
>>>> config registers for chip-select 0
On 04/19/2013 07:02 AM, Christoph Fritz wrote:
> On Fri, 2013-04-19 at 11:01 +0200, Christoph Fritz wrote:
>
>> This is how u-boot GPMC config differs from final kernel configuration:
>>
>>
>> u-boot: GPMC_CONFIG1: 0x6e60: 0x1800
>> kernel: 0x1800
>
On 04/19/2013 09:53 AM, Christoph Fritz wrote:
> On Fri, 2013-04-19 at 09:00 -0500, Jon Hunter wrote:
>> On 04/19/2013 07:02 AM, Christoph Fritz wrote:
>>> so I hacked the missing values to omap2_nand_gpmc_retime():
>>>
>>> From 8868823925441a824fe0d31436144
On 04/19/2013 10:48 AM, Tony Lindgren wrote:
> * Jon Hunter [130419 08:41]:
>> On 04/19/2013 09:53 AM, Christoph Fritz wrote:
>>> -static int omap2_nand_gpmc_retime(
>>> - struct omap_nand_platform_data *gpmc_nand_data,
>>>
On 04/22/2013 03:54 AM, Andreas Fenkart wrote:
> When a gpio interrupt is masked, the gpio event will still be latched in
> the interrupt status register so when you unmask it later you may get an
> interrupt straight away. However, if the interrupt is disabled then gpio
> events occurring will no
On 04/22/2013 03:54 AM, Andreas Fenkart wrote:
> When a gpio interrupt is masked, the gpio event will still be latched in
> the interrupt status register so when you unmask it later you may get an
> interrupt straight away. However, if the interrupt is disabled then gpio
> events occurring will no
On 04/22/2013 03:54 AM, Andreas Fenkart wrote:
> When a gpio interrupt is masked, the gpio event will still be latched in
> the interrupt status register so when you unmask it later you may get an
> interrupt straight away. However, if the interrupt is disabled then gpio
> events occurring will no
On 04/26/2013 02:27 AM, Linus Walleij wrote:
> On Wed, Apr 17, 2013 at 5:41 PM, Stephen Warren wrote:
>> On 04/16/2013 05:14 PM, Jon Hunter wrote:
>
>>>> c) I have the feeling that hooking the of_xlate function for this is a
>>>> bit of an abuse of the fun
On 04/26/2013 02:31 AM, Linus Walleij wrote:
> On Wed, Apr 17, 2013 at 2:41 AM, Javier Martinez Canillas
> wrote:
>
> So:
>
>> +static int omap_gpio_irq_domain_xlate(struct irq_domain *d,
>> + struct device_node *ctrlr,
>> +
.10/gpmc branch.
Javier Martinez Canillas (3):
Documentation: dt: update TI GPMC ethernet binding properties
ARM: OMAP2+: only search for GPMC DT child nodes on probe
ARM: OMAP2+: only WARN if a GPMC child probe function fail
Jon Hunter (1):
Documentation: dt: update p
t)
to list the property "gpmc,device-nand" as a required property and also
updated the example. However, this property is redundant and not needed
because the GPMC child device node for NAND is called "nand". Therefore,
remove this property.
Signed-off-by: Jon Hunter
---
Doc
ate IRQs: -12
>>>>>> [2.300140] retu-mfd: probe of 2-0001 failed with error -12
>>>>>>
>>>>>> The error is coming from regmap code. According to git bisect, it is
>>>>>> caused by:
>>>>>>
>>>>>
On 22/05/13 22:20, Aaro Koskinen wrote:
> On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote:
>> On 21/05/13 18:39, Aaro Koskinen wrote:
>>> On Mon, May 20, 2013 at 10:46:21AM -0700, Tony Lindgren wrote:
>>>> * Tony Lindgren [130516 14:50]:
>&g
On 23/05/13 21:13, Aaro Koskinen wrote:
> On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote:
>> On 22/05/13 22:20, Aaro Koskinen wrote:
>>> On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote:
>>>> On 21/05/13 18:39, Aaro Koskinen wrote:
>>&g
On 26/05/13 20:07, Aaro Koskinen wrote:
> On Thu, May 23, 2013 at 08:02:05PM +0100, Jon Hunter wrote:
>> On 22/05/13 22:20, Aaro Koskinen wrote:
>>> On Tue, May 21, 2013 at 08:37:16PM +0100, Jon Hunter wrote:
>>>> On 21/05/13 18:39, Aaro Koskinen wrote:
>>&g
imer.c
> @@ -220,7 +220,7 @@ static int __init omap_dm_timer_init_one(struct
> omap_dm_timer *timer,
>int posted)
> {
> char name[10]; /* 10 = sizeof("gptXX_Xck0") */
> - const char *oh_name;
> + const char *oh_name = NU
On 27/05/13 15:37, Afzal Mohammed wrote:
> AM43x 32K counter binding.
>
> Signed-off-by: Afzal Mohammed
> ---
> Documentation/devicetree/bindings/arm/omap/counter.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/counter.txt
> b/Documentat
On 27/05/13 15:37, Afzal Mohammed wrote:
> AM43x timer bindings.
>
> Signed-off-by: Afzal Mohammed
> ---
> Documentation/devicetree/bindings/arm/omap/timer.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
> b/Documentation/dev
On 28/05/13 23:05, Stephen Warren wrote:
> On 05/28/2013 03:25 PM, Jon Hunter wrote:
>>
>> On 27/05/13 15:37, Afzal Mohammed wrote:
>>> AM43x timer bindings.
>>>
>>> Signed-off-by: Afzal Mohammed
>>> ---
>>> Documentation/devicetr
On 29/05/13 19:55, Aaro Koskinen wrote:
> Hi,
>
> On Tue, May 28, 2013 at 07:42:41PM +0100, Jon Hunter wrote:
>> Care to share the log?
>
> Below are three logs from 3.10-rc3 / Nokia 770. I did not even compile
> Retu this time, as it has nothing to do with GPIO IRQs
On 29/05/13 22:29, Jon Hunter wrote:
>
> On 29/05/13 19:55, Aaro Koskinen wrote:
>> Hi,
>>
>> On Tue, May 28, 2013 at 07:42:41PM +0100, Jon Hunter wrote:
>>> Care to share the log?
>>
>> Below are three logs from 3.10-rc3 / Nokia 770. I did not even
On 12/12/2012 09:06 PM, NeilBrown wrote:
>
> [Thierry: question for you near the end - thanks]
>
> On Wed, 12 Dec 2012 10:08:28 -0600 Jon Hunter wrote:
>
>> Hi Neil,
>>
>> On 12/12/2012 02:24 AM, NeilBrown wrote:
>>>
>>>
>>> This pa
On 12/12/2012 10:33 PM, NeilBrown wrote:
> On Thu, 13 Dec 2012 14:06:35 +1100 NeilBrown wrote:
>
+ omap_dm_timer_enable(omap->dm_timer);
>>>
>>> Do you need to call omap_dm_timer_enable here? _set_load and _set_match
>>> will enable the timer. So this should not be necessary.
>>
>> True.
On 12/13/2012 08:58 AM, Will Deacon wrote:
> Hi Jon,
>
> On Wed, Dec 12, 2012 at 09:43:04PM +0000, Jon Hunter wrote:
>> The Cross Trigger Interface (CTI) helpers in cti.h include definitions
>> for the Coresight Lock Access Register (LAR) and Lock Status Register
>>
On 12/13/2012 11:41 AM, Will Deacon wrote:
> On Wed, Dec 12, 2012 at 09:43:05PM +0000, Jon Hunter wrote:
>> Adds a device-tree binding for the ARM Cross Trigger Interface (CTI).
>> The ARM Cross Trigger Interface provides a way to route events between
>> processor mod
On 12/13/2012 09:08 AM, Will Deacon wrote:
> On Wed, Dec 12, 2012 at 09:43:06PM +0000, Jon Hunter wrote:
>> Convert the Cross Trigger Interface (CTI) helpers in cti.h into a
>> AMBA bus driver so that we can use device-tree to look-up the hardware
>> specific information suc
for OMAP2+ devices.
I have dropped the patch to fix a build error for OMAP4 in the
timer code as Olof already has this fix merged.
----
Jon Hunter (2):
ARM: OMAP2+: Fix realtime_counter_init warning in timer.c
ARM: AM335x: Fix
+ PMU code and so remove it.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/pmu.c |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index 250d909..eb78ae7 100644
--- a/arch/arm/mach-omap2/pmu.c
+++ b/arch/arm/mach-omap2/pmu.c
@@ -11,8
The system memory node for the OMAP2420 H4 was incorrectly defined as
start address followed by end address, instead of start address and
size. No noticable side-effects were observed but fix this for
correctness.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2420-h4.dts |2 +-
1 file
Add device-tree PMU support for OMAP2, OMAP3 and OMAP4460.
Tested with PERF on OMAP3430 Beagle Board and OMAP4460 Panda Board.
Boot tested only on OMAP2420 H4.
Jon Hunter (2):
ARM: OMAP2+: Prepare for device-tree PMU support
ARM: dts: OMAP2+: Add PMU nodes
arch/arm/boot/dts/omap2.dtsi
driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/pmu.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index eb78ae7..6e620eb
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot
On 12/14/2012 03:18 PM, Jon Hunter wrote:
> Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
>
> Please note that the node for OMAP4460 has been placed in a separate
> header file for OMAP4460, because the node is not compatible with
> OMAP4430.
>
> Signed-off-by: Jon
Add device-tree PMU support for OMAP2, OMAP3 and OMAP4460.
Tested with PERF on OMAP3430 Beagle Board and OMAP4460 Panda Board.
Boot tested only on OMAP2420 H4.
Jon Hunter (2):
ARM: OMAP2+: Prepare for device-tree PMU support
ARM: dts: OMAP2+: Add PMU nodes
arch/arm/boot/dts/omap2.dtsi
driver) and so ensure that this
indicated on boot with or without device-tree.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/pmu.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c
index eb78ae7..1a0799c
Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
Please note that the node for OMAP4460 has been placed in a separate
header file for OMAP4460, because the node is not compatible with
OMAP4430.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot
Commit 0d9250c (ARM: dts: omap4-panda: Add pinmux configuration for
HDMI) added a new device-tree source file for Rev A4 of the OMAP4430
Panda board but it did not add this version to the makefile. Hence,
add this file to the makefile.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/Makefile
On 12/17/2012 02:16 AM, Benoit Cousson wrote:
> Hi Jon,
>
> On 12/14/2012 10:18 PM, Jon Hunter wrote:
>> Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
>>
>> Please note that the node for OMAP4460 has been placed in a separate
>> header file for OMAP4460, b
On 12/17/2012 10:20 AM, Mark Rutland wrote:
> On Thu, Dec 13, 2012 at 07:21:30PM +0000, Jon Hunter wrote:
>>
>> On 12/13/2012 11:41 AM, Will Deacon wrote:
>>> On Wed, Dec 12, 2012 at 09:43:05PM +, Jon Hunter wrote:
>>>> Adds a device-tree binding for
On 12/17/2012 10:38 AM, Mark Rutland wrote:
> On Fri, Dec 14, 2012 at 09:26:37PM +0000, Jon Hunter wrote:
>> Add PMU nodes for OMAP2, OMAP3 and OMAP4460 devices.
>>
>> Please note that the node for OMAP4460 has been placed in a separate
>> header file for OMAP44
Add device-tree PMU support for OMAP2, OMAP3 and OMAP4460. OMAP4430
is not included because PMU is not currently supported on this device
due to absence of a cross-trigger interface driver.
Tested with PERF on OMAP3430 Beagle Board and OMAP4460 Panda Board.
Boot tested only on OMAP2420 H4.
Jon
absence of a cross-trigger
interface driver.
Signed-off-by: Jon Hunter
---
arch/arm/boot/dts/omap2.dtsi |5 +
arch/arm/boot/dts/omap3.dtsi |6 ++
arch/arm/boot/dts/omap4-panda-es.dts |2 ++
arch/arm/boot/dts/omap4460.dtsi | 18 ++
4
901 - 1000 of 1176 matches
Mail list logo
