[PATCH 2/2] msm: gpio: Add gpiomux calls to request and free.
Add gpiomux get and put calls to msmgpio request and free,
in order to allow gpio lines to be properly reference-counted
and power-managed.
Signed-off-by: Gregory Bean
---
arch/arm/mach-msm/gpio.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-msm/gpio.c b/arch/arm/mach-msm/gpio.c
index fd899a1..ea93ecb 100644
--- a/arch/arm/mach-msm/gpio.c
+++ b/arch/arm/mach-msm/gpio.c
@@ -21,6 +21,7 @@
#include
#include
#include "gpio_hw.h"
+#include "gpiomux.h"
#include "proc_comm.h"
#include "smd_private.h"
@@ -157,6 +158,16 @@ static int msm_gpio_to_irq(struct gpio_chip *chip,
unsigned offset)
return MSM_GPIO_TO_INT(chip->base + offset);
}
+static int msm_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+return msm_gpiomux_get(chip->base + offset);
+}
+
+static void msm_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+msm_gpiomux_put(chip->base + offset);
+}
+
struct msm_gpio_chip msm_gpio_chips[] = {
{
.regs = {
@@ -177,6 +188,8 @@ struct msm_gpio_chip msm_gpio_chips[] = {
.direction_input = msm_gpio_direction_input,
.direction_output = msm_gpio_direction_output,
.to_irq = msm_gpio_to_irq,
+ .request = msm_gpio_request,
+ .free = msm_gpio_free,
}
},
{
@@ -202,6 +215,8 @@ struct msm_gpio_chip msm_gpio_chips[] = {
.direction_input = msm_gpio_direction_input,
.direction_output = msm_gpio_direction_output,
.to_irq = msm_gpio_to_irq,
+ .request = msm_gpio_request,
+ .free = msm_gpio_free,
}
},
{
@@ -228,6 +243,8 @@ struct msm_gpio_chip msm_gpio_chips[] = {
.direction_input = msm_gpio_direction_input,
.direction_output = msm_gpio_direction_output,
.to_irq = msm_gpio_to_irq,
+ .request = msm_gpio_request,
+ .free = msm_gpio_free,
}
},
{
@@ -249,6 +266,8 @@ struct msm_gpio_chip msm_gpio_chips[] = {
.direction_input = msm_gpio_direction_input,
.direction_output = msm_gpio_direction_output,
.to_irq = msm_gpio_to_irq,
+ .request = msm_gpio_request,
+ .free = msm_gpio_free,
}
},
{
@@ -274,6 +293,8 @@ struct msm_gpio_chip msm_gpio_chips[] = {
.direction_input = msm_gpio_direction_input,
.direction_output = msm_gpio_direction_output,
.to_irq = msm_gpio_to_irq,
+ .request = msm_gpio_request,
+ .free = msm_gpio_free,
}
},
{
@@ -306,6 +327,8 @@ struct msm_gpio_chip msm_gpio_chips[] = {
.direction_input = msm_gpio_direction_input,
.direction_output = msm_gpio_direction_output,
.to_irq = msm_gpio_to_irq,
+ .request = msm_gpio_request,
+ .free = msm_gpio_free,
}
},
#if defined(CONFIG_ARCH_QSD8X50) || defined(CONFIG_ARCH_MSM7X30)
@@ -333,6 +356,8 @@ struct msm_gpio_chip msm_gpio_chips[] = {
.direction_input = msm_gpio_direction_input,
.direction_output = msm_gpio_direction_output,
.to_irq = msm_gpio_to_irq,
+ .request = msm_gpio_request,
+ .free = msm_gpio_free,
}
},
{
@@ -359,6 +384,8 @@ struct msm_gpio_chip msm_gpio_chips[] = {
.direction_input = msm_gpio_direction_input,
.direction_output = msm_gpio_direction_output,
.to_irq = msm_gpio_to_irq,
+ .request = msm_gpio_request,
+ .free = msm_gpio_free,
}
},
#endif
--
1.7.0.4
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] msm: Install the Google-Android gpio driver.
From: Arve Hjønnevåg
As part of the ongoing effort to converge on a common code base,
adopt the Google-Android msmgpio driver, as it has a stronger pedigree
than the previous submission from codeaurora.
Cc: Arve Hjønnevåg
Signed-off-by: Gregory Bean
---
arch/arm/mach-msm/Makefile |3 +
arch/arm/mach-msm/gpio.c| 627 +++
arch/arm/mach-msm/gpio_hw.h | 277 +++
3 files changed, 907 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-msm/gpio.c
create mode 100644 arch/arm/mach-msm/gpio_hw.h
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index 2263b8f..c95d19a 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -22,3 +22,6 @@ obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o
devices-qsd8x50.o
obj-$(CONFIG_ARCH_MSM7X30) += gpiomux-7x30.o gpiomux-v1.o gpiomux.o
obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o gpiomux-v1.o gpiomux.o
obj-$(CONFIG_ARCH_MSM8X60) += gpiomux-8x60.o gpiomux-v2.o gpiomux.o
+ifndef CONFIG_MSM_V2_TLMM
+obj-y += gpio.o
+endif
diff --git a/arch/arm/mach-msm/gpio.c b/arch/arm/mach-msm/gpio.c
new file mode 100644
index 000..fd899a1
--- /dev/null
+++ b/arch/arm/mach-msm/gpio.c
@@ -0,0 +1,627 @@
+/* linux/arch/arm/mach-msm/gpio.c
+ *
+ * Copyright (C) 2007 Google, Inc.
+ * Copyright (c) 2009-2010, Code Aurora Forum. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "gpio_hw.h"
+#include "proc_comm.h"
+#include "smd_private.h"
+
+#define FIRST_GPIO_IRQ MSM_GPIO_TO_INT(0)
+
+enum {
+ GPIO_DEBUG_SLEEP = 1U << 0,
+};
+static int msm_gpio_debug_mask;
+module_param_named(debug_mask, msm_gpio_debug_mask, int,
+ S_IRUGO | S_IWUSR | S_IWGRP);
+
+#define MSM_GPIO_BROKEN_INT_CLEAR 1
+
+struct msm_gpio_regs {
+ void __iomem *out;
+ void __iomem *in;
+ void __iomem *int_status;
+ void __iomem *int_clear;
+ void __iomem *int_en;
+ void __iomem *int_edge;
+ void __iomem *int_pos;
+ void __iomem *oe;
+};
+
+struct msm_gpio_chip {
+ spinlock_t lock;
+ struct gpio_chipchip;
+ struct msm_gpio_regsregs;
+#if MSM_GPIO_BROKEN_INT_CLEAR
+ unsignedint_status_copy;
+#endif
+ unsigned intboth_edge_detect;
+ unsigned intint_enable[2]; /* 0: awake, 1: sleep */
+};
+
+static int msm_gpio_write(struct msm_gpio_chip *msm_chip,
+ unsigned offset, unsigned on)
+{
+ unsigned b = 1U << offset;
+ unsigned v;
+
+ v = readl(msm_chip->regs.out);
+ if (on)
+ writel(v | b, msm_chip->regs.out);
+ else
+ writel(v & (~b), msm_chip->regs.out);
+ return 0;
+}
+
+static void msm_gpio_update_both_edge_detect(struct msm_gpio_chip *msm_chip)
+{
+ int loop_limit = 100;
+ unsigned pol, val, val2, intstat;
+ do {
+ val = readl(msm_chip->regs.in);
+ pol = readl(msm_chip->regs.int_pos);
+ pol = (pol & ~msm_chip->both_edge_detect) |
+ (~val & msm_chip->both_edge_detect);
+ writel(pol, msm_chip->regs.int_pos);
+ intstat = readl(msm_chip->regs.int_status);
+ val2 = readl(msm_chip->regs.in);
+ if (((val ^ val2) & msm_chip->both_edge_detect & ~intstat) == 0)
+ return;
+ } while (loop_limit-- > 0);
+ printk(KERN_ERR "msm_gpio_update_both_edge_detect, "
+ "failed to reach stable state %x != %x\n", val, val2);
+}
+
+static int msm_gpio_clear_detect_status(struct msm_gpio_chip *msm_chip,
+ unsigned offset)
+{
+ unsigned b = BIT(offset);
+
+#if MSM_GPIO_BROKEN_INT_CLEAR
+ /* Save interrupts that already triggered before we loose them. */
+ /* Any interrupt that triggers between the read of int_status */
+ /* and the write to int_clear will still be lost though. */
+ msm_chip->int_status_copy |= readl(msm_chip->regs.int_status);
+ msm_chip->int_status_copy &= ~b;
+#endif
+ writel(b, msm_chip->regs.int_clear);
+ msm_gpio_update_both_edge_detect(msm_chip);
+ return 0;
+}
+
+static int msm_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+ struct msm_gpio_chip *msm_chip;
+ unsigned long irq_flags;
+
+ msm_chip = container_of(chip, struct msm_gpio_chip, chip);
Re: [PATCH 0/1] input: keyboard: add qci keyboard driver
On Mon, Aug 30, 2010 at 02:22:10PM -0400, Neil Leeder wrote: > On 8/27/2010 6:33 PM, Dmitry Torokhov wrote: > >No, this is crazy... This is a twin-brother of the touchpad driver and > >I really do not understand why chip claiming to have PS/2 interface > >(3 ports if I were to believe the diagram) would not allow us talk to > >the devices... > > I didn't provide a key bit of information, sorry. The keyboard is > not attached to the EC's PS/2 port. It is on a matrix of GPIOs. And still you are using only one GPIO in your driver? While WPCE775x does seem to have matrix keypad support I think that you are using one of the 3 PS/2 ports, like your touchpad does. > > I was trying to explain that even though the firmware on the EC uses > 0xF4 written over i2c to initialize it, it doesn't appear to support > other PS/2 commands directed to the keyboard on the GPIO matrix. > The device is initialized with 0xf4; the device is supposed to respond with 0xfa; I wonder what scancodes the device reports... It smells strongly of PS/2. Also, it is not controller that supports PS/2 commands but rather the device itself so I am still hopeful that we could make use of the standard drivers. Wan, you worked at Nuvoton, do you know if wpce775 fully supports PS/2 interface? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pm_qos: Add system bus performance parameter
mark gross writes: > On Fri, Aug 27, 2010 at 07:55:37PM -0700, Saravana Kannan wrote: >> mark gross wrote: >> >On Fri, Aug 27, 2010 at 01:10:55AM -0700, skan...@codeaurora.org wrote: >> >>Ignoring other details for now, the biggest problem with throughput/KBps >> >>units is that PM QoS can't handle it well in its current state. For KBps >> >>the requests should be added together before it's "enforced". Just picking >> >>the maximum won't work optimally. >> > >> >well then current pm_qos code for network throughput takes the max. >> >> I don't know how the network throughput is enforced, but if the unit >> is KBps and it's just doing a Max, then I think it's broken. If two >> clients request 50 KBps and your network can go till 200 KBps, you >> would still be requesting 50 KBps when you could have requested 100 >> KBps. >> >> Any specific reason PM QoS doesn't support a "summation" "comparitor"? > > PM_QoS could do a summation, but keep in mind it pm_qos not qos. pm_qos > is a best effort thing to constrain power management throttling, not > provide a true quality of service or deadline scheduling support. For me (and I think Saravana too), this is still all about power, but it's closely tied to QoS. For things like busses, which are inherently shared, PM is tightly coupled with "true" QoS, so I'm not sure I fully follow the distinction being made between PM QoS and QoS. Seems like the tradeoff is always between power and performance. > If you stick to the full up quality of service mentality you quickly get > into discussions just like those around memory over commit. Its really > hard to know when best effort or hard QoS is appropriate. > > If you are trying to use pm_qos as a true qos interface then, its > definitely not up to the task. > > example: you have one 100Mb NIC in your box. With PM QoS you could > have 4 user mode applications requesting 100Mbs PM_Q0S. In this case > the right thing to do is to constrain the NIC PM to keep it full on and > the PHY going as fast as it can. But you'll never get 400Mbs out of the > thing. > > So far only max and min really have made sense for pm_qos but, if a case > pops up where summation makes more sense for aggregating the pm_qos > requests then I'm open to it. Using your example above, what if the 4 apps all request 10Mb/s? What is best effort? Leave the NIC in 10Mb/s mode, or bump up the power state to 100Mb/s mode? This decision is both QoS and PM related. Without summation, the 'max' request is still 10Mb/s so you would keep the lower power state. But you also know that none of the clients will get their requested rate. There's some gray area here since there is a choice. Was the point of the request to keep the NIC at the *power-state* needed for 10Mb/s (a PM request) or was the request saying the app wanted at least 10Mb/s (a QoS request.) My understanding is that PM QoS is intended to limit power-state throttling. IOW, in the absence of PM QoS requests, the PM core code is free to throttle the power of the devices/subsystems/busses etc. If requests are present, it is no longer free to throttle blindly. The question here seems to be whether or not the PM core code should also be free to increase the power state to meet a combination of PM QoS requests. To me this is still PM related. Just like in race-to-idle for the CPU, it might be better for overall power to go to the highter state for a burst and then be able to fully throttle again. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] input: keyboard: add qci keyboard driver
On 8/27/2010 6:33 PM, Dmitry Torokhov wrote: No, this is crazy... This is a twin-brother of the touchpad driver and I really do not understand why chip claiming to have PS/2 interface (3 ports if I were to believe the diagram) would not allow us talk to the devices... I didn't provide a key bit of information, sorry. The keyboard is not attached to the EC's PS/2 port. It is on a matrix of GPIOs. I was trying to explain that even though the firmware on the EC uses 0xF4 written over i2c to initialize it, it doesn't appear to support other PS/2 commands directed to the keyboard on the GPIO matrix. -- Neil -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
