* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-10-30 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZysB2mxj5wZfE0N+iwTE-_AXbOV0bKRP5kSo=1hieKGg@mail.gmail.com>
On Tue, Oct 30, 2012 at 03:16:02PM +0100, Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 3:07 PM, Mark Brown
> > Essentially all the patches I'm seeing adding pinctrl are totally
> > mindless, most of them are just doing the initial setup on boot and not
> > doing any active management at runtime at all.
> I concludes in some other mails that all Ux500 drivers
> will need to handle atleast two states (default and sleep)
> and some a third state (idle).
Right, that's the other common option and obviously it's just an
extension of the simple hogs which maps very nicely onto the existing PM
states for devices.
> And this is what we're doing in our patches.
> Arguably it can all be pushed to power domains, but that
> will as said mandate all affected systems to implement
> power domains, and effectively moving code from
> drivers/* to arch/arm/* in our case atleast.
As soon as they start adding clock support and so on, yes. Obviously if
they don't want to use any of the features that are offloaded like this
then they could happily ignore it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/1a4adf30/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] ARM: highbank: use common irqchip_init
From: Rob Herring @ 2012-10-30 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351608860-24617-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
Now that we have common irqchip init, use it on highbank platform.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
arch/arm/mach-highbank/highbank.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index 40e36a5..27b77da 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -18,6 +18,7 @@
#include <linux/dma-mapping.h>
#include <linux/io.h>
#include <linux/irq.h>
+#include <linux/irqchip.h>
#include <linux/irqdomain.h>
#include <linux/of.h>
#include <linux/of_irq.h>
@@ -82,11 +83,6 @@ void highbank_set_cpu_jump(int cpu, void *jump_addr)
HB_JUMP_TABLE_PHYS(cpu) + 15);
}
-const static struct of_device_id irq_match[] = {
- { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
- {}
-};
-
#ifdef CONFIG_CACHE_L2X0
static void highbank_l2x0_disable(void)
{
@@ -97,7 +93,7 @@ static void highbank_l2x0_disable(void)
static void __init highbank_init_irq(void)
{
- of_irq_init(irq_match);
+ irqchip_init();
#ifdef CONFIG_CACHE_L2X0
/* Enable PL310 L2 Cache controller */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] irqchip: Move ARM VIC to drivers/irqchip
From: Rob Herring @ 2012-10-30 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351608860-24617-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
Now that we have drivers/irqchip, move VIC irqchip to drivers/irqchip.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
arch/arm/common/Kconfig | 15 ---------------
arch/arm/common/Makefile | 1 -
drivers/irqchip/Kconfig | 15 +++++++++++++++
drivers/irqchip/Makefile | 1 +
arch/arm/common/vic.c => drivers/irqchip/irq-vic.c | 0
drivers/irqchip/irqchip.c | 14 ++++++++++++++
drivers/irqchip/irqchip.h | 1 +
7 files changed, 31 insertions(+), 16 deletions(-)
rename arch/arm/common/vic.c => drivers/irqchip/irq-vic.c (100%)
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 7bf52b2..9353184 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -1,18 +1,3 @@
-config ARM_VIC
- bool
- select IRQ_DOMAIN
- select MULTI_IRQ_HANDLER
-
-config ARM_VIC_NR
- int
- default 4 if ARCH_S5PV210
- default 3 if ARCH_S5PC100
- default 2
- depends on ARM_VIC
- help
- The maximum number of VICs available in the system, for
- power management.
-
config ICST
bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 4104b82..dc8dd0d 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -2,7 +2,6 @@
# Makefile for the linux kernel.
#
-obj-$(CONFIG_ARM_VIC) += vic.o
obj-$(CONFIG_ICST) += icst.o
obj-$(CONFIG_SA1111) += sa1111.o
obj-$(CONFIG_PCI_HOST_VIA82C505) += via82c505.o
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 2d7f350..d80e5c7 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -9,3 +9,18 @@ config ARM_GIC
config GIC_NON_BANKED
bool
+
+config ARM_VIC
+ bool
+ select IRQ_DOMAIN
+ select MULTI_IRQ_HANDLER
+
+config ARM_VIC_NR
+ int
+ default 4 if ARCH_S5PV210
+ default 3 if ARCH_S5PC100
+ default 2
+ depends on ARM_VIC
+ help
+ The maximum number of VICs available in the system, for
+ power management.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 94118db..9c7f91e 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_IRQCHIP) += irqchip.o
obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
obj-$(CONFIG_ARCH_MVEBU) += irq-armada-370-xp.o
obj-$(CONFIG_ARM_GIC) += irq-gic.o
+obj-$(CONFIG_ARM_VIC) += irq-vic.o
diff --git a/arch/arm/common/vic.c b/drivers/irqchip/irq-vic.c
similarity index 100%
rename from arch/arm/common/vic.c
rename to drivers/irqchip/irq-vic.c
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index 3f37397..0872cd7 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -24,6 +24,20 @@ static const struct of_device_id irqchip_of_match[] __initconst = {
.data = gic_of_init,
},
#endif
+#ifdef CONFIG_ARM_VIC
+ {
+ .compatible = "arm,versatile-vic",
+ .data = vic_of_init,
+ },
+ {
+ .compatible = "arm,pl190-vic",
+ .data = vic_of_init,
+ },
+ {
+ .compatible = "arm,pl190-vic",
+ .data = vic_of_init,
+ },
+#endif
#ifdef CONFIG_ARCH_BCM2835
{
.compatible = "brcm,bcm2835-armctrl-ic",
diff --git a/drivers/irqchip/irqchip.h b/drivers/irqchip/irqchip.h
index 62773ab3..8b8c2b2 100644
--- a/drivers/irqchip/irqchip.h
+++ b/drivers/irqchip/irqchip.h
@@ -15,5 +15,6 @@ int bcm2835_irqchip_init(struct device_node *node, struct device_node *parent);
int armada_370_xp_mpic_of_init(struct device_node *node,
struct device_node *parent);
int gic_of_init(struct device_node *node, struct device_node *parent);
+int vic_of_init(struct device_node *node, struct device_node *parent);
#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/3] irqchip: Move ARM GIC to drivers/irqchip
From: Rob Herring @ 2012-10-30 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351608860-24617-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
Now that we have drivers/irqchip, move GIC irqchip to drivers/irqchip. This
is necessary to share the GIC with arm and arm64.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
arch/arm/common/Kconfig | 8 --------
arch/arm/common/Makefile | 1 -
drivers/irqchip/Kconfig | 8 ++++++++
drivers/irqchip/Makefile | 1 +
arch/arm/common/gic.c => drivers/irqchip/irq-gic.c | 0
drivers/irqchip/irqchip.c | 10 ++++++++++
drivers/irqchip/irqchip.h | 1 +
7 files changed, 20 insertions(+), 9 deletions(-)
rename arch/arm/common/gic.c => drivers/irqchip/irq-gic.c (100%)
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 45ceeb0..7bf52b2 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -1,11 +1,3 @@
-config ARM_GIC
- bool
- select IRQ_DOMAIN
- select MULTI_IRQ_HANDLER
-
-config GIC_NON_BANKED
- bool
-
config ARM_VIC
bool
select IRQ_DOMAIN
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..4104b82 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -2,7 +2,6 @@
# Makefile for the linux kernel.
#
-obj-$(CONFIG_ARM_GIC) += gic.o
obj-$(CONFIG_ARM_VIC) += vic.o
obj-$(CONFIG_ICST) += icst.o
obj-$(CONFIG_SA1111) += sa1111.o
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 88b0929..2d7f350 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -1,3 +1,11 @@
config IRQCHIP
def_bool y
depends on OF_IRQ
+
+config ARM_GIC
+ bool
+ select IRQ_DOMAIN
+ select MULTI_IRQ_HANDLER
+
+config GIC_NON_BANKED
+ bool
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 5148ffd..94118db 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_IRQCHIP) += irqchip.o
obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
obj-$(CONFIG_ARCH_MVEBU) += irq-armada-370-xp.o
+obj-$(CONFIG_ARM_GIC) += irq-gic.o
diff --git a/arch/arm/common/gic.c b/drivers/irqchip/irq-gic.c
similarity index 100%
rename from arch/arm/common/gic.c
rename to drivers/irqchip/irq-gic.c
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index f36d423..3f37397 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -14,6 +14,16 @@
#include "irqchip.h"
static const struct of_device_id irqchip_of_match[] __initconst = {
+#ifdef CONFIG_ARM_GIC
+ {
+ .compatible = "arm,cortex-a15-gic",
+ .data = gic_of_init,
+ },
+ {
+ .compatible = "arm,cortex-a9-gic",
+ .data = gic_of_init,
+ },
+#endif
#ifdef CONFIG_ARCH_BCM2835
{
.compatible = "brcm,bcm2835-armctrl-ic",
diff --git a/drivers/irqchip/irqchip.h b/drivers/irqchip/irqchip.h
index 0a0d7af..62773ab3 100644
--- a/drivers/irqchip/irqchip.h
+++ b/drivers/irqchip/irqchip.h
@@ -14,5 +14,6 @@
int bcm2835_irqchip_init(struct device_node *node, struct device_node *parent);
int armada_370_xp_mpic_of_init(struct device_node *node,
struct device_node *parent);
+int gic_of_init(struct device_node *node, struct device_node *parent);
#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/7] Move GIC and VIC to drivers/irqchip
From: Rob Herring @ 2012-10-30 14:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <rob.herring@calxeda.com>
I think I had this action from San Francisco Linaro Connect. Well, better
late than never... Now we need to move GIC for use by arm64.
This series builds on Thomas Petazzoni's series adding a common irqchip
init function[1] and moves the ARM GIC and VIC irqchip code to
drivers/irqchip.
Tested on highbank and compiled on all defconfigs.
Rob
[1] http://www.spinics.net/lists/arm-kernel/msg203687.html
Rob Herring (3):
irqchip: Move ARM GIC to drivers/irqchip
irqchip: Move ARM VIC to drivers/irqchip
ARM: highbank: use common irqchip_init
arch/arm/common/Kconfig | 23 -------------------
arch/arm/common/Makefile | 2 --
arch/arm/mach-highbank/highbank.c | 8 ++-----
drivers/irqchip/Kconfig | 23 +++++++++++++++++++
drivers/irqchip/Makefile | 2 ++
arch/arm/common/gic.c => drivers/irqchip/irq-gic.c | 0
arch/arm/common/vic.c => drivers/irqchip/irq-vic.c | 0
drivers/irqchip/irqchip.c | 24 ++++++++++++++++++++
drivers/irqchip/irqchip.h | 2 ++
9 files changed, 53 insertions(+), 31 deletions(-)
rename arch/arm/common/gic.c => drivers/irqchip/irq-gic.c (100%)
rename arch/arm/common/vic.c => drivers/irqchip/irq-vic.c (100%)
--
1.7.10.4
^ permalink raw reply
* [PATCH v3] Visstrim SM10: Use mo_version to decide board video mode.
From: javier Martin @ 2012-10-30 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACKLOr0HO4OapJk_-ktWcfwcnVD1MLfL6MF1bbaVUHjD5LVuJg@mail.gmail.com>
On 28 September 2012 15:06, javier Martin
<javier.martin@vista-silicon.com> wrote:
> Hi Mauro,
> this patch should originally go via arm-soc but it has a dependency on
> support for coda video codec which is already in your tree.
>
> Now that we've got Sascha's ack could you merge this patch through your tree?
>
> Regards.
>
Hi Sascha,
it seems Mauro missed to apply this patch through his tree.
Moreover, 1 month later from my submission I think it should already
apply to arm-soc.
Could you please merge it?
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Vaibhav Hiremath @ 2012-10-30 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB51E84@DBDE01.ent.ti.com>
On 10/30/2012 6:09 PM, Hiremath, Vaibhav wrote:
> On Tue, Oct 30, 2012 at 17:17:00, Paul Walmsley wrote:
>> cc Vaibhav Hiremath
>>
>> On Tue, 30 Oct 2012, Mark Jackson wrote:
>>
>>> At what point is booting from MMC on the BeagleBone going to start working ?
>>>
>>> I only ask, since, by default, a new BeagleBone is setup to boot from
>>> MMC, so anyone testing a new kernel will probably expect the same setup
>>> to work.
>>
>> BeagleBone boots initramfs from MMC now, which is what mine was shipped to
>> do. Are you asking about rootfs on MMC? If so, Vaibhav would have a
>> better sense of this than I.
>>
>
> Mark,
>
> MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
> already submitted to the list recently. So MMC support will come along with
> EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
>
>
> If you refer to the Matt's repo, you should get all the patches required to
> boot MMC support -
>
> https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3
>
>
I just tested this branch (+ one fix which Matt provided [1]) on
BeagleBone, and MMC is working without any issues. I have tested with
rootFS on MMC card.
[1] - http://www.spinics.net/lists/linux-omap/msg79911.html
Thanks,
Vaibhav
>
> Thanks,
> Vaibhav
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: am33xx: Add PRM warm reset/reboot support
From: Paul Walmsley @ 2012-10-30 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351504747-10554-1-git-send-email-hvaibhav@ti.com>
On Mon, 29 Oct 2012, Vaibhav Hiremath wrote:
> This patch adds reboot capability to all AM33XX based boards/EVM's,
> by asserting PRM warm reset bit on 'reboot' command.
>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Tested-by: Daniel Mack <zonque@gmail.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Afzal Mohammed <afzal@ti.com>
Sounds like you're already planning to do this - but could you rebase this
on the 3.8 PRCM cleanup branch that was sent in a separate mail?
thanks,
- Paul
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-10-30 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdapQJY0aoam741O0fb8EeM9BLk_Psq5TaPG84J7wEvCLw@mail.gmail.com>
On Tue, Oct 30, 2012 at 03:02:23PM +0100, Linus Walleij wrote:
> I worry that we will end up with power/resource domain
> code that start to look like this:
> suspend()
> switch (device.id) {
> case DEV_FOO:
> clk_disable();
> pinctrl_set_state();
> power_domain_off();
> case DEV_BAR:
Well, if we're doing that then either we'd presumably either get the
same result if we open code it in the drivers or whoever wrote the
resource domain code for the platform should be creating multiple
domains.
> Another effect is that moving all resource handling to
> power domains is that if we do that for a widely shared
> device driver like the PL011 that mandates that power
> domains need to be implemented for U300, Ux500,
> Nomadik, SPEAr 13xx, 3xx, 6xx, Versatile, Versatile
> Express, Integrator (AP & CP) and BCM2835. Probably
> more.
> Basically power (resource) domains have the side-effect
> of in this light not doing one thing (power domains) but
> instead imposing all-or-nothing imperialistic characteristics.
For me that's happening anyway with explicit control, just in different
places - for example the Freescale guys have had issues with IPs shared
between m68k and i.MX requiring that stub clocks be provided on m68k for
things that are always on there and similarly with all the platforms
that get affected when some widely used chip acquires regulator support.
It seems easier to organise things if the platform has responsibility
for coordinating this stuff than if we add stuff in the drivers.
> I worry that the per-SoC power domain implementation
> which will live in arch/arm/mach-* as of today will become
> the new board file problem, overburdening the arch/* tree.
> Maybe I'm mistaken as to the size of these things,
> but just doing ls arch/arm/mach-omap2/powerdomain*
> makes me start worrying.
One thing to remember is that OMAP has some of the most featureful
hardware out there in terms of software control for power so it's
unlikely to ever get much more complex than that. IME most SoCs
are very much simpler than that and should be able to punt lots of
stuff to device tree data.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/050eb2e6/attachment.sig>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Linus Walleij @ 2012-10-30 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030140714.GO4511@opensource.wolfsonmicro.com>
On Tue, Oct 30, 2012 at 3:07 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> Essentially all the patches I'm seeing adding pinctrl are totally
> mindless, most of them are just doing the initial setup on boot and not
> doing any active management at runtime at all.
None of the Ux500 pinctrl patches are like that.
I concludes in some other mails that all Ux500 drivers
will need to handle atleast two states (default and sleep)
and some a third state (idle).
And this is what we're doing in our patches.
Arguably it can all be pushed to power domains, but that
will as said mandate all affected systems to implement
power domains, and effectively moving code from
drivers/* to arch/arm/* in our case atleast.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] leds: leds-gpio: adopt pinctrl support
From: AnilKumar, Chimata @ 2012-10-30 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaeu3JaLqSbqETT=D0mdUu5VpwRpS_Xohd6M963rw8QMg@mail.gmail.com>
On Wed, Oct 03, 2012 at 18:06:10, Linus Walleij wrote:
> On Wed, Oct 3, 2012 at 12:52 PM, AnilKumar, Chimata <anilkumar@ti.com> wrote:
> > On Tue, Oct 02, 2012 at 01:29:37, Linus Walleij wrote:
>
> >> This is what we're doing for ux500 and should be a good model.
> >
> > I have looked into this, but not seen any named modes.
>
> OK maybe it's not easy to find. If you look into:
> arch/arm/mach-ux500/board-mop500-pins.c
> you find our work in progress. Note that this is not (yet)
> using device tree. (We want to migrate all our pinctrl
> stuff first, then do DT.)
>
> So for example this macro:
>
> #define DB8500_PIN(pin,conf,dev) \
> PIN_MAP_CONFIGS_PIN_DEFAULT(dev, "pinctrl-db8500", pin, conf)
>
> Will define a config for the "default" mode for a certain
> pin.
>
> This:
>
> #define DB8500_PIN_SLEEP(pin, conf, dev) \
> PIN_MAP_CONFIGS_PIN(dev, PINCTRL_STATE_SLEEP, "pinctrl-db8500", \
> pin, conf)
>
> Will mutatis mutandis define a "sleep" mode for a pin.
>
> Sorry for the macros. We'll get rid of them in the DT.
> (Now that Stephen has patched in preprocessing it will
> even look good.)
>
Hi Linus Walleij/Tony,
I completely understood this named modes, I have added named
modes like this in am335x-xxx.dts files
am33xx_pinmux: pinmux at 44e10800 {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&user_leds_s0>;
pinctrl-1 = <&user_leds_s1>;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins = <
0x54 0x7 /* gpmc_a5.gpio1_21, OUTPUT | MODE7 */
0x58 0x17 /* gpmc_a6.gpio1_22, OUT PULLUP | MODE7 */
0x5c 0x7 /* gpmc_a7.gpio1_23, OUTPUT | MODE7 */
0x60 0x17 /* gpmc_a8.gpio1_24, OUT PULLUP | MODE7 */
>;
};
user_leds_s1: user_leds_s1 {
pinctrl-single,pins = <
0x54 0x2e /* gpmc_a5.gpio1_21, INPUT | MODE7 */
0x58 0x2e /* gpmc_a6.gpio1_22, INPUT | MODE7 */
0x5c 0x2e /* gpmc_a7.gpio1_23, INPUT | MODE7 */
0x60 0x2e /* gpmc_a8.gpio1_24, INPUT | MODE7 */
>;
};
};
I think "pinctrl-1" state will be used in driver
suspend/resume calls.
I have the pinmux/conf settings for default state but fully
optimized pinmux/conf values in idle & suspend states are not
available yet. Even though if I add here, I am unable to test
these pins in suspend state because suspend/resume of AM35xx
is not added yet
I have two options now
- add only default states for now, I can add reset of
the state details once suspend/resume is supported.
- add same values in all the states, modify those once
suspend/resume is added for AM335x.
Thanks
AnilKumar
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Linus Walleij @ 2012-10-30 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030114949.GC28722@arwen.pp.htv.fi>
On Tue, Oct 30, 2012 at 12:49 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Tue, Oct 30, 2012 at 11:24:10AM +0000, Mark Brown wrote:
>> We need some place to put the SoC integration; power domains seem like
>> the obvious place to me but YMMV. Nothing about having this out of the
>
> except that pin muxing has nothing to do with power domain. To me that
> sounds like an abuse of the API.
It could be renamed to "power resources" or something as long as
it's related to resource handling related to the PM calls.
But I worry that it violates the Unix principle to do one thing and one
thing only.
A device power resource framework goes in the opposite direction,
trying to do a lot of unrelated things in a central place as opposed
to distributing the task.
>> drivers requires that this be done by individual subsystems in isolation
>> from each other. Half the point here is that for the reusable IPs this
>> stuff often isn't driver specific at all, it's often more about the SoC
>> integration than it is about the driver and so you'll get a consistent
>> pattern for most IPs on the SoC.
>
> and all of that SoC-specific detail is already hidden behind power
> domains, runtime PM, pinctrl, clk API, regulator framework, etc.
I agree.
pinctrl has already done a fair job at trying to be abstract in the
states requested from the core, in <linux/pinctrl/pinctrl-state.h>.
And I accept the idea to try to centralize more as well, maybe
as a helpful struct and some inlines for the pinctrl core. I think
this is enough, and pushing all handles into central code creates
a problem elsewhere.
(But I'm not so certain ... so I might just
change opinion one of those days depending on what
arguments will be made.)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-10-30 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030114949.GC28722@arwen.pp.htv.fi>
On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 11:24:10AM +0000, Mark Brown wrote:
> > We need some place to put the SoC integration; power domains seem like
> > the obvious place to me but YMMV. Nothing about having this out of the
> except that pin muxing has nothing to do with power domain. To me that
> sounds like an abuse of the API.
Well, we can call the API Archibald if we like... what I mean is
something that sits in the system below the device in pretty much
exactly the way that power domains do.
> > drivers requires that this be done by individual subsystems in isolation
> > from each other. Half the point here is that for the reusable IPs this
> > stuff often isn't driver specific at all, it's often more about the SoC
> > integration than it is about the driver and so you'll get a consistent
> > pattern for most IPs on the SoC.
> and all of that SoC-specific detail is already hidden behind power
> domains, runtime PM, pinctrl, clk API, regulator framework, etc.
That's all getting rather open coded, especially if you're going to get
down to a situation where you have varying ordering constraints between
the different APIs on different SoCs.
> > > How can you make sure that this will work for at least 50% of the
> > > drivers ? You just can't. We don't know the implementation details of
> > > every arch/soc/platform supported by Linux today to make that decision.
> > Well, we've managed to get along for rather a long time with essentially
> > all architectures implementing this stuff by doing static setup for the
> > pins on boot. That does suggest we can get a reasonably long way with
> and this is one of the issues we're all trying to solve today so we have
> single zImage approach for the ARM port.
I don't see the relevance of single zImage here; device tree is supposed
to solve that one.
> > something simple, and it does seem to match up with how things usually
> > look at an electrical level too.
> simple ? I really doubt it. Just look at the amount of code duplication
> the ARM port had (still has in some places) to handle platform-specific
> details.
What I'm saying here is that I'm concerned about us ending up with more
code duplication...
> It turned out that drivers weren't very portable when they had to do
> platform-specific initialization, we were all abusing platform_data to
> pass strings and/or function pointers down to drivers and so on.
> I'm concerned if we hide pinctrl under e.g. power domains (as said
> above, it sounds like an abuse of the API to me) we will end up with a
> situation like above. Maybe not as bad, but still weird-looking.
Well, nothing's going to stop that happening if people are determined
enough - one could equally see that there'll be flags getting passed to
control the ordering of calls if things are open coded. I would expect
that with a power domain style approach any data would be being passed
directly and bypassing the driver completely.
> > It seems fairly obvious that if we need to add identical bolier plate
> > code to lots of drivers we're doing something wrong, it's just churn for
> > little practical gain and a problem if we ever decide to change how this
> > stuff works in the future.
> I wouldn't consider it boilerplate if you remember that each driver
> might have different requirements regarding how all of those details
> need to be handled.
Essentially all the patches I'm seeing adding pinctrl are totally
mindless, most of them are just doing the initial setup on boot and not
doing any active management at runtime at all.
> We have to consider power consumption, ordering of calls, proper IP
> setup, IP reuse on multiple platforms (even multiple ARCHes), etc etc,
> and to get that right outside of the driver - who's the only class that
> actually knows what it needs to do with its resources - will just be too
> complex and error-prone.
A big part of my point here is that it's not at all clear to me that it
is the driver which knows what's going on. For SoC-specific IPs you can
be confident about how the SoC integration looks but for IPs that get
reused widely this becomes less true.
> I would strongly suggest starting with explicit calls to pinctrl, clk
> API, etc and if we can really prove later that 95% of the users are
> "standard", then we can factor code out, but making that assumption now
> is quite risky IMHO.
Like I say I think we're already seeing a pattern here, the code going
into most drivers looks *very* similar with lots of the drivers simply
calling get_select_default().
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/7fc0e92f/attachment.sig>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Paul Walmsley @ 2012-10-30 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210301313190.12697@utopia.booyaka.com>
On Tue, 30 Oct 2012, Paul Walmsley wrote:
> Based on a very quick look, I'd say the original patch 3db11fe is broken.
> I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is
> honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for
> omap2plus_defconfig.
So in fact to follow up on this, looks like one of two changes are needed:
1. Revert 3db11fe
or
2. If CONFIG_CPU_IDLE=n, the driver needs to call disable_hlt() in place
of the pm_qos constraint add, and call enable_hlt() in place of the pm_qos
constraint remove.
Jean, could you please pick a solution and send a patch for the 3.7-rc
timeframe, to fix the bug in 3db11fe?
?
- Paul
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Linus Walleij @ 2012-10-30 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030113407.GA24335@sirena.org.uk>
On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
>> Moving this handling to bus code or anywhere else
>> invariably implies that resource acquisition/release order
>> does not matter, and my point is that it does.
>
> Doing this in the buses is definitely wrong, as you say it's not bus
> specific. I do however think we can usefully do this stuff in a SoC
> specific place like a power domain, keeping the SoC integration code
> together and out of the drivers. IME the SoCs where you need to do
> different things for different IPs shoudl mostly still get some reuse
> out of such an approach.
Talking to Kevin Hilman today he was also stressing that
power domains is a good thing for handling resources, especially
when replacing prior hacks in the custom clk code. However
he pointed specifically to clocks and voltages, which may
be true.
What worries me is when knowledge of the hardware which
is traditionally a concern for the device driver start to
bubble up to the power domain (or better renamed resource
domain if use like this, as Felipe points out).
I worry that we will end up with power/resource domain
code that start to look like this:
suspend()
switch (device.id) {
case DEV_FOO:
clk_disable();
pinctrl_set_state();
power_domain_off();
case DEV_BAR:
pinctrl_set_state();
clk_disable();
// Always-on domain
case DEV_BAZ:
pinctrl_set_state();
clk_disable();
power_domain_off();
case ...
Mutate the above with silicon errata, specific tweaks etc that
Felipe was mentioning.
What is happening is that device-specific behaviour which
traditionally handled in the driver is now inside the
power/resource domain.
I agree that if the domain was doing the same thing for each
piece of hardware, this would be the right thing to do,
and I think the in-kernel examples are all "simple",
e.g. arch/arm/mach-omap2/powerdomain* is all about
power domains and nothing else, and the notifiers used
by SHmobile is all about clock gating and nothing else.
Another effect is that moving all resource handling to
power domains is that if we do that for a widely shared
device driver like the PL011 that mandates that power
domains need to be implemented for U300, Ux500,
Nomadik, SPEAr 13xx, 3xx, 6xx, Versatile, Versatile
Express, Integrator (AP & CP) and BCM2835. Probably
more.
None of which has power domains (upstream) as
of today. Some of which (U300, Ux500, Nomadik,
SPEAr, Integrator, BCM2835) implement pin control.
Basically power (resource) domains have the side-effect
of in this light not doing one thing (power domains) but
instead imposing all-or-nothing imperialistic characteristics.
While avoiding a set of distributed, optional pinctrl hooks,
it mandates a central piece of upfront powerdomain
boilerplate to be present in each and every platform that
wants to control its pins.
I think the lesser of two evils is the distributed approach,
and then I'm talking about pinctrl only, disregarding the
fact that clocks and power domains are basically subject to
the same kind of argument. I still buy into the concept of
using power domains for exactly power domains only.
Arguably this is an elegance opinion...
I worry that the per-SoC power domain implementation
which will live in arch/arm/mach-* as of today will become
the new board file problem, overburdening the arch/* tree.
Maybe I'm mistaken as to the size of these things,
but just doing ls arch/arm/mach-omap2/powerdomain*
makes me start worrying.
Yours,
Linus Walleij
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Paul Walmsley @ 2012-10-30 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030125419.GG29095@arwen.pp.htv.fi>
On Tue, 30 Oct 2012, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 12:50:52PM +0000, Paul Walmsley wrote:
> > certainly PM-idle related, given that the problem goes away by reverting
> > Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc "ARM: OMAP: convert
> > I2C driver to PM QoS for MPU latency constraints".
> >
> > The problem is consistent and easy to reproduce here.
>
> I don't doubt that :-) What I think, however, is that PM QoS just made
> the problem a bit easier to trigger for whatever reason. Maybe because
> pm qos defers constraint updates, or something similar ?
Based on a very quick look, I'd say the original patch 3db11fe is broken.
I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is
honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for
omap2plus_defconfig.
- Paul
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Paul Walmsley @ 2012-10-30 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508F59FB.7080400@ti.com>
On Tue, 30 Oct 2012, Vaibhav Hiremath wrote:
> On 10/30/2012 8:06 AM, Paul Walmsley wrote:
>
> > * AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> > - Due to GPMC missing support for DT
> > - Temporary workaround at http://www.spinics.net/lists/arm-kernel/msg200787.html
> > - May be fixed now, pending retest:
> > - http://marc.info/?l=linux-omap&m=135082257727502&w=2
> >
>
> This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform
> and its booting up for me without any issues.
> Jon had submitted another patch which fixes boot issue on Bone.
>
> https://patchwork.kernel.org/patch/1606471/
Please don't worry about this one at the moment. This one isn't part of
the automated test suite, so it requires further effort from me to
re-test. I've marked it as such in the README. Will try to re-test by
v3.7-rc4.
- Paul
^ permalink raw reply
* [PATCH] at91sam9m10g45-ek: rename leds to match board
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-30 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121029212826.GA6203@piout.net>
On 22:28 Mon 29 Oct , Alexandre Belloni wrote:
>
> On Mon, Oct 29, 2012 at 05:14:45PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote :
> > No here it's different teh same HW have different revision
> >
> > m10g45es
> > m10ekes
> > 9g45ekes
> >
> > the m10ekes is the first one and the leds does match
> >
> > So I agree we can put a comment in the c or the dts about it but do not change
> > the content as the board support is like this for really long time
> > And I do not want to ebd-up with 2 or 3 dts jsut for lesd naming
> > That I will have to maintain
> >
>
> From my discussion with atmel last week, I understood that the only
> publicly available board is the m10g45ek. Support for the other boards
> you mention is actually being dropped and you can't find them on ATMEL's
> website anymore.
>
> So, I agree you should support only one configuration but at least, let
> it be the one for the current board.
sorry no
we touch dts only if this is a bug this is a comestic change
Best Regards,
J.
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Felipe Balbi @ 2012-10-30 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210301239310.12697@utopia.booyaka.com>
Hi,
On Tue, Oct 30, 2012 at 12:50:52PM +0000, Paul Walmsley wrote:
> On Tue, 30 Oct 2012, Felipe Balbi wrote:
>
> > the wmb() patch should help, but you said it doesn't, right ?
>
> Correct. Not sure why you think that would help; the problem is almost
because of how the driver is behaving...
The only way for omap_i2c_wait_for_bb() to timeout is if the bus is
really still busy; meaning that either transfer hasn't fully completed
(some data still in FIFO), or we didn't send STOP or Repeated START
condition on the bus.
> certainly PM-idle related, given that the problem goes away by reverting
> Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc "ARM: OMAP: convert
> I2C driver to PM QoS for MPU latency constraints".
>
> The problem is consistent and easy to reproduce here.
I don't doubt that :-) What I think, however, is that PM QoS just made
the problem a bit easier to trigger for whatever reason. Maybe because
pm qos defers constraint updates, or something similar ?
> > without seeing debugging information on the failing case, it'll be very
> > difficult to sort this one out provided noone else seems to be able to
> > reproduce it.
>
> Aaro sees it also, so it's definitely not a local artifact.
Again I don't doubt it.
> It's not very surprising that the problem doesn't appear with the extra
> logging enabled, since the extra logging presumably keeps the system out
> of idle.
>
> Anyway, you are welcome to the userspace, bootloader, and X-loader here if
> you would like to try to reproduce it. They've been sent to Jean and
> Kevin and Shubhrajyoti already. Simply request it and I will send links.
I can have a look, sure, but I don't have the same platform as you have.
I have a beagle XM revB (according to the stickers on the board) which I
could use to try to reproduce, if I manage to, then hooray :-)
In that case, please give me also a link to your uImage so I can make
sure to use the exact same setup.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/14ae2ba0/attachment.sig>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Paul Walmsley @ 2012-10-30 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030123254.GD29095@arwen.pp.htv.fi>
On Tue, 30 Oct 2012, Felipe Balbi wrote:
> the wmb() patch should help, but you said it doesn't, right ?
Correct. Not sure why you think that would help; the problem is almost
certainly PM-idle related, given that the problem goes away by reverting
Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc "ARM: OMAP: convert
I2C driver to PM QoS for MPU latency constraints".
The problem is consistent and easy to reproduce here.
> without seeing debugging information on the failing case, it'll be very
> difficult to sort this one out provided noone else seems to be able to
> reproduce it.
Aaro sees it also, so it's definitely not a local artifact.
It's not very surprising that the problem doesn't appear with the extra
logging enabled, since the extra logging presumably keeps the system out
of idle.
Anyway, you are welcome to the userspace, bootloader, and X-loader here if
you would like to try to reproduce it. They've been sent to Jean and
Kevin and Shubhrajyoti already. Simply request it and I will send links.
- Paul
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Hiremath, Vaibhav @ 2012-10-30 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210301143420.12697@utopia.booyaka.com>
On Tue, Oct 30, 2012 at 17:17:00, Paul Walmsley wrote:
> cc Vaibhav Hiremath
>
> On Tue, 30 Oct 2012, Mark Jackson wrote:
>
> > At what point is booting from MMC on the BeagleBone going to start working ?
> >
> > I only ask, since, by default, a new BeagleBone is setup to boot from
> > MMC, so anyone testing a new kernel will probably expect the same setup
> > to work.
>
> BeagleBone boots initramfs from MMC now, which is what mine was shipped to
> do. Are you asking about rootfs on MMC? If so, Vaibhav would have a
> better sense of this than I.
>
Mark,
MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
already submitted to the list recently. So MMC support will come along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
If you refer to the Matt's repo, you should get all the patches required to
boot MMC support -
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3
Thanks,
Vaibhav
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Felipe Balbi @ 2012-10-30 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210301216330.12697@utopia.booyaka.com>
Hi,
On Tue, Oct 30, 2012 at 12:17:11PM +0000, Paul Walmsley wrote:
> On Mon, 29 Oct 2012, Felipe Balbi wrote:
>
> > that's too bad :-(
> >
> > Can you compile with:
> >
> > CONFIG_I2C_DEBUG_CORE=y
> > CONFIG_I2C_DEBUG_ALGO=y
> > CONFIG_I2C_DEBUG_BUS=y
> > CONFIG_DEFAULT_MESSAGE_LOGLEVEL=9
> >
> > so that I can see all transfers ?
>
> Log is below.
that's working. It only helps to let me know we have a race somewhere,
and if it is what I'm thinking, the wmb() patch should help, but you
said it doesn't, right ?
without seeing debugging information on the failing case, it'll be very
difficult to sort this one out provided noone else seems to be able to
reproduce it.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/7cf1545c/attachment.sig>
^ permalink raw reply
* [PATCH 1/4] net: mvneta: driver for Marvell Armada 370/XP network unit
From: Thomas Petazzoni @ 2012-10-30 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABMQnVLBCU-2C6DbKsXAVPanWx=oQnjE7Tpi2q5bgpYJ9SQt-A@mail.gmail.com>
Dear Nobuhiro Iwamatsu,
On Tue, 30 Oct 2012 21:07:34 +0900, Nobuhiro Iwamatsu wrote:
> I tested this driver on OpenBlocks AX3 and worked fine.
Thanks.
> I will send a patch which support DT for OpenBlocks AX3.
I was also about to prepare a patch doing that, but I was waiting for
the network driver itself to be merged, and also the basic OpenBlocks
AX3 support as well.
> Tested-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 6/8] serial: xilinx_uartps: kill CONFIG_OF conditional
From: Josh Cartwright @ 2012-10-30 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351721190.git.josh.cartwright@ni.com>
The Zynq platform requires the use of CONFIG_OF. Remove the #ifdef
conditionals in the uartps driver.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
---
drivers/tty/serial/xilinx_uartps.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
index b627363..23efe17 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -946,15 +946,11 @@ static int __devinit xuartps_probe(struct platform_device *pdev)
struct resource *res, *res2;
int clk = 0;
-#ifdef CONFIG_OF
const unsigned int *prop;
prop = of_get_property(pdev->dev.of_node, "clock", NULL);
if (prop)
clk = be32_to_cpup(prop);
-#else
- clk = *((unsigned int *)(pdev->dev.platform_data));
-#endif
if (!clk) {
dev_err(&pdev->dev, "no clock specified\n");
return -ENODEV;
@@ -1044,16 +1040,11 @@ static int xuartps_resume(struct platform_device *pdev)
}
/* Match table for of_platform binding */
-
-#ifdef CONFIG_OF
static struct of_device_id xuartps_of_match[] __devinitdata = {
{ .compatible = "xlnx,xuartps", },
{}
};
MODULE_DEVICE_TABLE(of, xuartps_of_match);
-#else
-#define xuartps_of_match NULL
-#endif
static struct platform_driver xuartps_platform_driver = {
.probe = xuartps_probe, /* Probe method */
--
1.8.0
^ permalink raw reply related
* [PATCH 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
From: Omar Ramirez Luna @ 2012-10-30 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121029175228.GD11908@atomide.com>
Tony,
On 29 October 2012 12:52, Tony Lindgren <tony@atomide.com> wrote:
>> --- /dev/null
>> +++ b/include/linux/platform_data/omap_mailbox.h
>> @@ -0,0 +1,105 @@
>
> This file should only contain pure platform data needed
> by the core omap code to pass to the mailbox driver.
Ok, looking at it closely, this header file is related to the API
itself, there is nothing that could be actually considered as pure
platform data, the structures are related with the mailbox framework
and even if I split this file into two, the additional header would
end up including the "platform_data" header unless I move
save/restore_ctx functions and then export them as symbols for the
API.
So, it might be better for the entire file to sit in
linux/include/mailbox/ then.
> The mailbox API header should be somewhere else,
> like include/linux/mailbox/mailbox-omap.h or similar.
Ok.
> But shouldn't this all now be handled by using the
> remoteproc framework?
Remoteproc doesn't handle the mailbox hardware directly, it still
relies in the mailbox framework for the low level communications.
E.g.: Proc1 has a message (virtqueue msg) queued to Proc2, uses
mailbox msg to generate an interrupt to Proc2, Proc2 queries the
message (virtqueue) based on the mailbox message received.
Regards,
Omar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox