* [PATCH 1/2] arch/arm/mach-omap2/dma.c: Convert IS_ERR result to PTR_ERR
From: Jarkko Nikula @ 2011-01-27 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296143347-17508-1-git-send-email-julia@diku.dk>
On Thu, 27 Jan 2011 16:49:06 +0100
Julia Lawall <julia@diku.dk> wrote:
> diff -u -p a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
> --- a/arch/arm/mach-omap2/dma.c
> +++ b/arch/arm/mach-omap2/dma.c
> @@ -264,7 +264,7 @@ static int __init omap2_system_dma_init_
> if (IS_ERR(od)) {
> pr_err("%s: Cant build omap_device for %s:%s.\n",
> __func__, name, oh->name);
> - return IS_ERR(od);
> + return PTR_ERR(od);
> }
>
FWIW,
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
^ permalink raw reply
* HIGHMEM is broken when working in SMP V6 mode
From: Russell King - ARM Linux @ 2011-01-27 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101271337410.8580@xanadu.home>
On Thu, Jan 27, 2011 at 01:40:37PM -0500, Nicolas Pitre wrote:
> On Thu, 27 Jan 2011, Russell King - ARM Linux wrote:
>
> > On Mon, Jan 24, 2011 at 02:58:07PM -0500, Nicolas Pitre wrote:
> > > /*
> > > + * The reason for kmap_high_get() is to ensure that the currently kmap'd
> > > + * page usage count does not decrease to zero while we're using its
> > > + * existing virtual mapping in an atomic context. With a VIVT cache this
> > > + * is essential to do, but with a VIPT cache this is only an optimization
> > > + * so not to pay the price of establishing a second mapping if an existing
> > > + * one can be used. However, on platforms without hardware TLB maintainence
> > > + * broadcast, we simply cannot use ARCH_NEEDS_KMAP_HIGH_GET at all since
> > > + * the locking involved must also disable IRQs which is incompatible with
> > > + * the IPI mechanism used by global TLB operations.
> > > + */
> > > +#define ARCH_NEEDS_KMAP_HIGH_GET
> > > +#if defined(CONFIG_SMP) && defined(CONFIG_CPU_TLB_V6)
> > > +#undef ARCH_NEEDS_KMAP_HIGH_GET
> > > +#if defined(CONFIG_HIGHMEM) && defined(CONFIG_CPU_CACHE_VIVT)
> > > +#error "The sum of feature in your kernel config cannot be supported together"
> > > +#endif
> >
> > This is wrong. Take a moment to consider a kernel supporting an ARMv6
> > VIPT aliasing cache CPU and ARMv7 SMP. Don't we need kmap_high_get()
> > for ARMv6 VIPT aliasing cache?
>
> We don't support highmem on aliasing VIPT. Highmem gets disabled at run
> time on aliasing VIPT platforms.
Correct. But a kernel which has this configuration:
CONFIG_SMP=y
CONFIG_HIGHMEM=y
CONFIG_CPU_V6=y
CONFIG_CPU_V7=y
CONFIG_CPU_32v6=y
CONFIG_CPU_32v7=y
CONFIG_CPU_CACHE_V6=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_TLB_V6=y
CONFIG_CPU_TLB_V7=y
This disables ARCH_NEEDS_KMAP_HIGH_GET in this kernel, which can be used on
ARMv6 VIPT non-aliasing, VIPT aliasing, as well as SMP stuff.
If we don't need ARCH_NEEDS_KMAP_HIGH_GET on V6 and V7, we should just not
enable it for those at all.
^ permalink raw reply
* [PATCH v2 15/28] ARM: tegra: irq: Add debugfs file to show wake irqs
From: Stephen Boyd @ 2011-01-27 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295834493-5019-16-git-send-email-ccross@android.com>
On 01/23/2011 06:01 PM, Colin Cross wrote:
>
> +static int __init tegra_irq_debug_init(void)
> +{
> + struct dentry *d;
> +
> + d = debugfs_create_file("wake_irq", S_IRUGO, NULL, NULL,
> + &tegra_wake_irq_debug_fops);
> + if (!d) {
> + pr_info("Failed to create suspend_mode debug file\n");
Does this want to be a pr_err()?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* HIGHMEM is broken when working in SMP V6 mode
From: Nicolas Pitre @ 2011-01-27 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110127190411.GA1597@n2100.arm.linux.org.uk>
On Thu, 27 Jan 2011, Russell King - ARM Linux wrote:
> On Thu, Jan 27, 2011 at 01:40:37PM -0500, Nicolas Pitre wrote:
> > On Thu, 27 Jan 2011, Russell King - ARM Linux wrote:
> >
> > > On Mon, Jan 24, 2011 at 02:58:07PM -0500, Nicolas Pitre wrote:
> > > > /*
> > > > + * The reason for kmap_high_get() is to ensure that the currently kmap'd
> > > > + * page usage count does not decrease to zero while we're using its
> > > > + * existing virtual mapping in an atomic context. With a VIVT cache this
> > > > + * is essential to do, but with a VIPT cache this is only an optimization
> > > > + * so not to pay the price of establishing a second mapping if an existing
> > > > + * one can be used. However, on platforms without hardware TLB maintainence
> > > > + * broadcast, we simply cannot use ARCH_NEEDS_KMAP_HIGH_GET at all since
> > > > + * the locking involved must also disable IRQs which is incompatible with
> > > > + * the IPI mechanism used by global TLB operations.
> > > > + */
> > > > +#define ARCH_NEEDS_KMAP_HIGH_GET
> > > > +#if defined(CONFIG_SMP) && defined(CONFIG_CPU_TLB_V6)
> > > > +#undef ARCH_NEEDS_KMAP_HIGH_GET
> > > > +#if defined(CONFIG_HIGHMEM) && defined(CONFIG_CPU_CACHE_VIVT)
> > > > +#error "The sum of feature in your kernel config cannot be supported together"
> > > > +#endif
> > >
> > > This is wrong. Take a moment to consider a kernel supporting an ARMv6
> > > VIPT aliasing cache CPU and ARMv7 SMP. Don't we need kmap_high_get()
> > > for ARMv6 VIPT aliasing cache?
> >
> > We don't support highmem on aliasing VIPT. Highmem gets disabled at run
> > time on aliasing VIPT platforms.
>
> Correct. But a kernel which has this configuration:
>
> CONFIG_SMP=y
> CONFIG_HIGHMEM=y
> CONFIG_CPU_V6=y
> CONFIG_CPU_V7=y
> CONFIG_CPU_32v6=y
> CONFIG_CPU_32v7=y
> CONFIG_CPU_CACHE_V6=y
> CONFIG_CPU_CACHE_VIPT=y
> CONFIG_CPU_CACHE_V7=y
> CONFIG_CPU_CACHE_VIPT=y
> CONFIG_CPU_TLB_V6=y
> CONFIG_CPU_TLB_V7=y
>
> This disables ARCH_NEEDS_KMAP_HIGH_GET in this kernel, which can be used on
> ARMv6 VIPT non-aliasing, VIPT aliasing, as well as SMP stuff.
Yes.
On a VIPT aliasing target, highmem gets disabled at run time. So no
issue there.
Otherwise, on VIPT, it is not essential to have
ARCH_NEEDS_KMAP_HIGH_GET.
> If we don't need ARCH_NEEDS_KMAP_HIGH_GET on V6 and V7, we should just not
> enable it for those at all.
As I said in the patch comment, ARCH_NEEDS_KMAP_HIGH_GET is still a nice
optimization on VIPT. It avoids the creation of a second mapping and TLB
usage when an existing mapping from the pkmap array can be reused right
away. But if our kernel config indicates that we might run on a target
lacking hw TLB broadcast then we have to compromize and give up on that
optimization.
Nicolas
^ permalink raw reply
* [PATCH-V2] OMAP3EVM:FIX: Reset the smsc911x ethernet controller in board_init
From: Kevin Hilman @ 2011-01-27 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19F8576C6E063C45BE387C64729E739404BD7BE3F4@dbde02.ent.ti.com>
"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
>> -----Original Message-----
>> From: Hiremath, Vaibhav
>> Sent: Tuesday, January 25, 2011 8:53 PM
>> To: linux-omap at vger.kernel.org
>> Cc: Hiremath, Vaibhav; Varadarajan, Charulatha
>> Subject: [PATCH-V2] OMAP3EVM:FIX: Reset the smsc911x ethernet controller
>> in board_init
>>
>> With addition of hwmod support to gpio, the ethernet controller
>> goes undetected for OMAP35xEVM. So explicitly assert the reset signal to
>> ethernet controller smsc911x -
>>
>> - GPIO7 (>=RevG version of EVM's)
>> - GPIO64 (<=RevD version of EVM's)
>>
>> This patch is based on intial version from Charulatha V, reference
>> to original discussion -
>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg35784.html
>> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
>> Signed-off-by: Charulatha V <charu@ti.com>
>> Tested-by: Kevin Hilman <khilman@ti.com>
>> ---
>> Since Kevin reported that this patch doesn't get applied cleanly,
>> so I am reposting it again after making sure that it gets applied cleanly.
>>
> [Hiremath, Vaibhav] Oops, missed linux-arm-kernel list, adding here.
>
> Not sure whether I need to repost keeping linux-arm-kernel?
Yes, please repost.
Kevin
>
>> arch/arm/mach-omap2/board-omap3evm.c | 39
>> +++++++++++++++++++++++++++++++++-
>> 1 files changed, 38 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
>> omap2/board-omap3evm.c
>> index 323c380..97e0f65 100644
>> --- a/arch/arm/mach-omap2/board-omap3evm.c
>> +++ b/arch/arm/mach-omap2/board-omap3evm.c
>> @@ -58,6 +58,13 @@
>> #define OMAP3EVM_ETHR_ID_REV 0x50
>> #define OMAP3EVM_ETHR_GPIO_IRQ 176
>> #define OMAP3EVM_SMSC911X_CS 5
>> +/*
>> + * Eth Reset signal
>> + * 64 = Generation 1 (<=RevD)
>> + * 7 = Generation 2 (>=RevE)
>> + */
>> +#define OMAP3EVM_GEN1_ETHR_GPIO_RST 64
>> +#define OMAP3EVM_GEN2_ETHR_GPIO_RST 7
>>
>> static u8 omap3_evm_version;
>>
>> @@ -124,10 +131,15 @@ static struct platform_device
>> omap3evm_smsc911x_device = {
>>
>> static inline void __init omap3evm_init_smsc911x(void)
>> {
>> - int eth_cs;
>> + int eth_cs, eth_rst;
>> struct clk *l3ck;
>> unsigned int rate;
>>
>> + if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
>> + eth_rst = OMAP3EVM_GEN1_ETHR_GPIO_RST;
>> + else
>> + eth_rst = OMAP3EVM_GEN2_ETHR_GPIO_RST;
>> +
>> eth_cs = OMAP3EVM_SMSC911X_CS;
>>
>> l3ck = clk_get(NULL, "l3_ck");
>> @@ -136,6 +148,27 @@ static inline void __init
>> omap3evm_init_smsc911x(void)
>> else
>> rate = clk_get_rate(l3ck);
>>
>> + /* Configure ethernet controller reset gpio */
>> + if (cpu_is_omap3430()) {
>> + if (gpio_request(eth_rst, "SMSC911x gpio") < 0) {
>> + pr_err(KERN_ERR "Failed to request %d for smsc911x\n",
>> + eth_rst);
>> + return;
>> + }
>> +
>> + if (gpio_direction_output(eth_rst, 1) < 0) {
>> + pr_err(KERN_ERR "Failed to set direction of %d for" \
>> + " smsc911x\n", eth_rst);
>> + return;
>> + }
>> + /* reset pulse to ethernet controller*/
>> + usleep_range(150, 220);
>> + gpio_set_value(eth_rst, 0);
>> + usleep_range(150, 220);
>> + gpio_set_value(eth_rst, 1);
>> + usleep_range(1, 2);
>> + }
>> +
>> if (gpio_request(OMAP3EVM_ETHR_GPIO_IRQ, "SMSC911x irq") < 0) {
>> printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
>> OMAP3EVM_ETHR_GPIO_IRQ);
>> @@ -658,6 +691,10 @@ static struct omap_board_mux board_mux[] __initdata =
>> {
>> OMAP_PIN_OFF_WAKEUPENABLE),
>> OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
>> OMAP_PIN_OFF_INPUT_PULLUP |
>> OMAP_PIN_OFF_OUTPUT_LOW),
>> + OMAP3_MUX(SYS_BOOT5, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
>> + OMAP_PIN_OFF_NONE),
>> + OMAP3_MUX(GPMC_WAIT2, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
>> + OMAP_PIN_OFF_NONE),
>> { .reg_offset = OMAP_MUX_TERMINATOR },
>> };
>> #endif
>> --
>> 1.6.2.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/5] OMAP3EVM: Board bug fixes/enhancements
From: Kevin Hilman @ 2011-01-27 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19F8576C6E063C45BE387C64729E739404BD7BE82E@dbde02.ent.ti.com>
Hi Vaibhav,
"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
[...]
>>
>> > OMAP3EVM: Made backlight GPIO default state to off
>> > OMAP3EVM: Set TSC wakeup option in pad config
>>
>> And this one doesn't apply as it seems to apply on top of code that
>> doesn't exist upstream.
>>
>
> You should first apply Ethernet-reset patch first, and then all
> patches will get applied cleanly. I have tested it here at my end.
OK, sorry to have missed that one.
In the future, dependencies need to be clearly stated in the patch 0
cover letter. When reviewers/maintainers are looking at lots of
patches, it is not easy to keep context for all the patches and series
arriving on the list. Additional information such as dependencies and
change history are extremely valuable to reviewers & maintainers.
> Since you already acked Ethernet patch, I thought it will make its way
> to mainline before all these patches. And also while posting, I posted
> Ethernet patch again first and then this series.
It will likely make it's way upstream sooner since it's a regression
fix, however, it is not yet queued anywhere so dependencies on it should
be clearly stated here.
Thanks,
Kevin
^ permalink raw reply
* [PATCH-V2] OMAP3EVM:FIX: Reset the smsc911x ethernet controller in board_init
From: Kevin Hilman @ 2011-01-27 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19F8576C6E063C45BE387C64729E739404BD7BE3F4@dbde02.ent.ti.com>
"Hiremath, Vaibhav" <hvaibhav@ti.com> writes:
>> -----Original Message-----
>> From: Hiremath, Vaibhav
>> Sent: Tuesday, January 25, 2011 8:53 PM
>> To: linux-omap at vger.kernel.org
>> Cc: Hiremath, Vaibhav; Varadarajan, Charulatha
>> Subject: [PATCH-V2] OMAP3EVM:FIX: Reset the smsc911x ethernet controller
>> in board_init
>>
>> With addition of hwmod support to gpio, the ethernet controller
>> goes undetected for OMAP35xEVM. So explicitly assert the reset signal to
>> ethernet controller smsc911x -
>>
>> - GPIO7 (>=RevG version of EVM's)
>> - GPIO64 (<=RevD version of EVM's)
>>
>> This patch is based on intial version from Charulatha V, reference
>> to original discussion -
>> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg35784.html
>> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
>> Signed-off-by: Charulatha V <charu@ti.com>
>> Tested-by: Kevin Hilman <khilman@ti.com>
>> ---
>> Since Kevin reported that this patch doesn't get applied cleanly,
>> so I am reposting it again after making sure that it gets applied cleanly.
>>
> [Hiremath, Vaibhav] Oops, missed linux-arm-kernel list, adding here.
>
> Not sure whether I need to repost keeping linux-arm-kernel?
>
Also, did you post the smc911x driver fix yet that is needed for testing
with newer kernels?
Kevin
^ permalink raw reply
* [PATCHv2] msm: serial: Add MSM8960 serial support
From: Stepan Moskovchenko @ 2011-01-27 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295663921-32723-1-git-send-email-stepanm@codeaurora.org>
Add the device definitions and platform data to support
the console serial port on MSM8960 Simulator and RUMI3
targets.
Change-Id: I6681a446ed1e1fce62bb52af879110228e907c5e
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
V2: Minor cosmetic changes
* Change the order of some fields based on Russell's rules
* Update copyright header
arch/arm/mach-msm/Makefile | 2 +-
arch/arm/mach-msm/board-msm8960.c | 22 +++++++++
arch/arm/mach-msm/devices-msm8960.c | 85 +++++++++++++++++++++++++++++++++++
arch/arm/mach-msm/devices.h | 3 +
4 files changed, 111 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-msm/devices-msm8960.c
diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile
index e3e38064..57b3062 100644
--- a/arch/arm/mach-msm/Makefile
+++ b/arch/arm/mach-msm/Makefile
@@ -25,7 +25,7 @@ obj-$(CONFIG_MACH_HALIBUT) += board-halibut.o devices-msm7x00.o
obj-$(CONFIG_ARCH_MSM7X30) += board-msm7x30.o devices-msm7x30.o
obj-$(CONFIG_ARCH_QSD8X50) += board-qsd8x50.o devices-qsd8x50.o
obj-$(CONFIG_ARCH_MSM8X60) += board-msm8x60.o
-obj-$(CONFIG_ARCH_MSM8960) += board-msm8960.o
+obj-$(CONFIG_ARCH_MSM8960) += board-msm8960.o devices-msm8960.o
obj-$(CONFIG_ARCH_MSM7X30) += gpiomux-v1.o gpiomux.o
obj-$(CONFIG_ARCH_QSD8X50) += gpiomux-8x50.o gpiomux-v1.o gpiomux.o
diff --git a/arch/arm/mach-msm/board-msm8960.c b/arch/arm/mach-msm/board-msm8960.c
index 2b09573..ef80f46 100644
--- a/arch/arm/mach-msm/board-msm8960.c
+++ b/arch/arm/mach-msm/board-msm8960.c
@@ -27,6 +27,8 @@
#include <mach/board.h>
#include <mach/msm_iomap.h>
+#include "devices.h"
+
static void __init msm8960_map_io(void)
{
msm_map_msm8960_io();
@@ -54,15 +56,35 @@ static void __init msm8960_init_irq(void)
}
}
+static struct platform_device *sim_devices[] __initdata = {
+ &msm8960_device_uart_gsbi2,
+};
+
+static struct platform_device *rumi3_devices[] __initdata = {
+ &msm8960_device_uart_gsbi5,
+};
+
+static void __init msm8960_sim_init(void)
+{
+ platform_add_devices(sim_devices, ARRAY_SIZE(sim_devices));
+}
+
+static void __init msm8960_rumi3_init(void)
+{
+ platform_add_devices(rumi3_devices, ARRAY_SIZE(rumi3_devices));
+}
+
MACHINE_START(MSM8960_SIM, "QCT MSM8960 SIMULATOR")
.map_io = msm8960_map_io,
.init_irq = msm8960_init_irq,
.timer = &msm_timer,
+ .init_machine = msm8960_sim_init,
MACHINE_END
MACHINE_START(MSM8960_RUMI3, "QCT MSM8960 RUMI3")
.map_io = msm8960_map_io,
.init_irq = msm8960_init_irq,
.timer = &msm_timer,
+ .init_machine = msm8960_rumi3_init,
MACHINE_END
diff --git a/arch/arm/mach-msm/devices-msm8960.c b/arch/arm/mach-msm/devices-msm8960.c
new file mode 100644
index 0000000..d9e1f26
--- /dev/null
+++ b/arch/arm/mach-msm/devices-msm8960.c
@@ -0,0 +1,85 @@
+/* Copyright (c) 2011, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+
+#include <linux/dma-mapping.h>
+#include <mach/irqs-8960.h>
+#include <mach/board.h>
+
+#include "devices.h"
+
+#define MSM_GSBI2_PHYS 0x16100000
+#define MSM_UART2DM_PHYS (MSM_GSBI2_PHYS + 0x40000)
+
+#define MSM_GSBI5_PHYS 0x16400000
+#define MSM_UART5DM_PHYS (MSM_GSBI5_PHYS + 0x40000)
+
+static struct resource resources_uart_gsbi2[] = {
+ {
+ .start = GSBI2_UARTDM_IRQ,
+ .end = GSBI2_UARTDM_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = MSM_UART2DM_PHYS,
+ .end = MSM_UART2DM_PHYS + PAGE_SIZE - 1,
+ .name = "uart_resource",
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MSM_GSBI2_PHYS,
+ .end = MSM_GSBI2_PHYS + PAGE_SIZE - 1,
+ .name = "gsbi_resource",
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+struct platform_device msm8960_device_uart_gsbi2 = {
+ .name = "msm_serial",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(resources_uart_gsbi2),
+ .resource = resources_uart_gsbi2,
+};
+
+static struct resource resources_uart_gsbi5[] = {
+ {
+ .start = GSBI5_UARTDM_IRQ,
+ .end = GSBI5_UARTDM_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = MSM_UART5DM_PHYS,
+ .end = MSM_UART5DM_PHYS + PAGE_SIZE - 1,
+ .name = "uart_resource",
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MSM_GSBI5_PHYS,
+ .end = MSM_GSBI5_PHYS + PAGE_SIZE - 1,
+ .name = "gsbi_resource",
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+struct platform_device msm8960_device_uart_gsbi5 = {
+ .name = "msm_serial",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(resources_uart_gsbi5),
+ .resource = resources_uart_gsbi5,
+};
diff --git a/arch/arm/mach-msm/devices.h b/arch/arm/mach-msm/devices.h
index 87c70bf..e2643b3 100644
--- a/arch/arm/mach-msm/devices.h
+++ b/arch/arm/mach-msm/devices.h
@@ -22,6 +22,9 @@ extern struct platform_device msm_device_uart1;
extern struct platform_device msm_device_uart2;
extern struct platform_device msm_device_uart3;
+extern struct platform_device msm8960_device_uart_gsbi2;
+extern struct platform_device msm8960_device_uart_gsbi5;
+
extern struct platform_device msm_device_sdc1;
extern struct platform_device msm_device_sdc2;
extern struct platform_device msm_device_sdc3;
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH] msm: Clean up useless ifdefs
From: Stepan Moskovchenko @ 2011-01-27 20:13 UTC (permalink / raw)
To: linux-arm-kernel
Remove ifdefs that do nothing, either from having the code
between them previously removed, or from having been
accidentally added to the wrong file.
Change-Id: I94aac2cb24e23ba7f8b4b158ce6653dc3b786989
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
arch/arm/mach-msm/board-halibut.c | 2 --
arch/arm/mach-msm/board-mahimahi.c | 2 --
arch/arm/mach-msm/board-msm7x27.c | 8 --------
arch/arm/mach-msm/board-msm7x30.c | 6 ------
arch/arm/mach-msm/board-qsd8x50.c | 4 ----
arch/arm/mach-msm/board-sapphire.c | 2 --
arch/arm/mach-msm/board-trout.c | 2 --
arch/arm/mach-msm/include/mach/msm_iomap-7x00.h | 6 ------
8 files changed, 0 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-msm/board-halibut.c b/arch/arm/mach-msm/board-halibut.c
index 75dabb1..18a3c97 100644
--- a/arch/arm/mach-msm/board-halibut.c
+++ b/arch/arm/mach-msm/board-halibut.c
@@ -93,8 +93,6 @@ static void __init halibut_map_io(void)
}
MACHINE_START(HALIBUT, "Halibut Board (QCT SURF7200A)")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = 0x10000100,
.fixup = halibut_fixup,
.map_io = halibut_map_io,
diff --git a/arch/arm/mach-msm/board-mahimahi.c b/arch/arm/mach-msm/board-mahimahi.c
index ef3ebf2..7a9a03e 100644
--- a/arch/arm/mach-msm/board-mahimahi.c
+++ b/arch/arm/mach-msm/board-mahimahi.c
@@ -74,8 +74,6 @@ static void __init mahimahi_map_io(void)
extern struct sys_timer msm_timer;
MACHINE_START(MAHIMAHI, "mahimahi")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = 0x20000100,
.fixup = mahimahi_fixup,
.map_io = mahimahi_map_io,
diff --git a/arch/arm/mach-msm/board-msm7x27.c b/arch/arm/mach-msm/board-msm7x27.c
index e7a76ef..16d7580 100644
--- a/arch/arm/mach-msm/board-msm7x27.c
+++ b/arch/arm/mach-msm/board-msm7x27.c
@@ -130,8 +130,6 @@ static void __init msm7x2x_map_io(void)
}
MACHINE_START(MSM7X27_SURF, "QCT MSM7x27 SURF")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = PHYS_OFFSET + 0x100,
.map_io = msm7x2x_map_io,
.init_irq = msm7x2x_init_irq,
@@ -140,8 +138,6 @@ MACHINE_START(MSM7X27_SURF, "QCT MSM7x27 SURF")
MACHINE_END
MACHINE_START(MSM7X27_FFA, "QCT MSM7x27 FFA")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = PHYS_OFFSET + 0x100,
.map_io = msm7x2x_map_io,
.init_irq = msm7x2x_init_irq,
@@ -150,8 +146,6 @@ MACHINE_START(MSM7X27_FFA, "QCT MSM7x27 FFA")
MACHINE_END
MACHINE_START(MSM7X25_SURF, "QCT MSM7x25 SURF")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = PHYS_OFFSET + 0x100,
.map_io = msm7x2x_map_io,
.init_irq = msm7x2x_init_irq,
@@ -160,8 +154,6 @@ MACHINE_START(MSM7X25_SURF, "QCT MSM7x25 SURF")
MACHINE_END
MACHINE_START(MSM7X25_FFA, "QCT MSM7x25 FFA")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = PHYS_OFFSET + 0x100,
.map_io = msm7x2x_map_io,
.init_irq = msm7x2x_init_irq,
diff --git a/arch/arm/mach-msm/board-msm7x30.c b/arch/arm/mach-msm/board-msm7x30.c
index 0707cc0..dc9fac1 100644
--- a/arch/arm/mach-msm/board-msm7x30.c
+++ b/arch/arm/mach-msm/board-msm7x30.c
@@ -105,8 +105,6 @@ static void __init msm7x30_map_io(void)
}
MACHINE_START(MSM7X30_SURF, "QCT MSM7X30 SURF")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = PHYS_OFFSET + 0x100,
.map_io = msm7x30_map_io,
.init_irq = msm7x30_init_irq,
@@ -115,8 +113,6 @@ MACHINE_START(MSM7X30_SURF, "QCT MSM7X30 SURF")
MACHINE_END
MACHINE_START(MSM7X30_FFA, "QCT MSM7X30 FFA")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = PHYS_OFFSET + 0x100,
.map_io = msm7x30_map_io,
.init_irq = msm7x30_init_irq,
@@ -125,8 +121,6 @@ MACHINE_START(MSM7X30_FFA, "QCT MSM7X30 FFA")
MACHINE_END
MACHINE_START(MSM7X30_FLUID, "QCT MSM7X30 FLUID")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = PHYS_OFFSET + 0x100,
.map_io = msm7x30_map_io,
.init_irq = msm7x30_init_irq,
diff --git a/arch/arm/mach-msm/board-qsd8x50.c b/arch/arm/mach-msm/board-qsd8x50.c
index 29ef683..b464d48 100644
--- a/arch/arm/mach-msm/board-qsd8x50.c
+++ b/arch/arm/mach-msm/board-qsd8x50.c
@@ -195,8 +195,6 @@ static void __init qsd8x50_init(void)
}
MACHINE_START(QSD8X50_SURF, "QCT QSD8X50 SURF")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = PHYS_OFFSET + 0x100,
.map_io = qsd8x50_map_io,
.init_irq = qsd8x50_init_irq,
@@ -205,8 +203,6 @@ MACHINE_START(QSD8X50_SURF, "QCT QSD8X50 SURF")
MACHINE_END
MACHINE_START(QSD8X50A_ST1_5, "QCT QSD8X50A ST1.5")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = PHYS_OFFSET + 0x100,
.map_io = qsd8x50_map_io,
.init_irq = qsd8x50_init_irq,
diff --git a/arch/arm/mach-msm/board-sapphire.c b/arch/arm/mach-msm/board-sapphire.c
index 8919ffb..6781ca8 100644
--- a/arch/arm/mach-msm/board-sapphire.c
+++ b/arch/arm/mach-msm/board-sapphire.c
@@ -105,8 +105,6 @@ static void __init sapphire_map_io(void)
MACHINE_START(SAPPHIRE, "sapphire")
/* Maintainer: Brian Swetland <swetland@google.com> */
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = PHYS_OFFSET + 0x100,
.fixup = sapphire_fixup,
.map_io = sapphire_map_io,
diff --git a/arch/arm/mach-msm/board-trout.c b/arch/arm/mach-msm/board-trout.c
index 73f1460..8448687 100644
--- a/arch/arm/mach-msm/board-trout.c
+++ b/arch/arm/mach-msm/board-trout.c
@@ -92,8 +92,6 @@ static void __init trout_map_io(void)
}
MACHINE_START(TROUT, "HTC Dream")
-#ifdef CONFIG_MSM_DEBUG_UART
-#endif
.boot_params = 0x10000100,
.fixup = trout_fixup,
.map_io = trout_map_io,
diff --git a/arch/arm/mach-msm/include/mach/msm_iomap-7x00.h b/arch/arm/mach-msm/include/mach/msm_iomap-7x00.h
index 1e75ed7..8f99d97 100644
--- a/arch/arm/mach-msm/include/mach/msm_iomap-7x00.h
+++ b/arch/arm/mach-msm/include/mach/msm_iomap-7x00.h
@@ -126,10 +126,4 @@
#define MSM_AD5_SIZE (SZ_1M*13)
-#if defined(CONFIG_ARCH_MSM7X30)
-#define MSM_GCC_BASE IOMEM(0xF8009000)
-#define MSM_GCC_PHYS 0xC0182000
-#define MSM_GCC_SIZE SZ_4K
-#endif
-
#endif
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* Locking in the clk API
From: Saravana Kannan @ 2011-01-27 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110127085438.GA25239@n2100.arm.linux.org.uk>
On 01/27/2011 12:54 AM, Russell King - ARM Linux wrote:
> On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
>> I'm not too familiar with serial/tty, does anyone know if the
>> .set_termios needs to be atmoic? If not, we could just change
>> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.
>
> The locking is there to protect against the interrupt handler accessing
> the port->* stuff (which seems to have been forgotten by the cpm driver).
>
> I don't see any reason why clk_set_rate() needs to be under the spinlock
> there - we need the reprogramming of the baud rate within the spinlock
> on 8250 because of DLAB bit hiding the data registers. It's also a good
> idea that it _is_ within the spinlock along with uart_update_timeout()
> to ensure timeouts and the baud rate are updated together.
For internal tree purposes, does .set_termios need to be atomic? Can it
grab mutexes instead of spinlock?
Going back to the topic, how about CPU freq drivers possibly using
clk_set_rate() to change freq? Do you think that's not the case or a
concern?
All,
Do any one of your mach's control CPU freq using clk_set_rate() and does
it need to be atomic? CPUfreq doesn't need it to be atomic. So, you will
need clk_set_rate() to be atomic only if you try to use it to lower CPU
freq very late during idle/suspend.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH v2 18/28] ARM: tegra: add CPU_IDLE driver
From: Stephen Boyd @ 2011-01-27 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295834493-5019-19-git-send-email-ccross@android.com>
On 01/23/2011 06:01 PM, Colin Cross wrote:
>
> +static int __init tegra_cpuidle_debug_init(void)
> +{
> + struct dentry *dir;
> + struct dentry *d;
> +
> + dir = debugfs_create_dir("cpuidle", NULL);
> + if (!dir)
> + return -ENOMEM;
> +
> + d = debugfs_create_file("lp2", S_IRUGO, dir, NULL,
> + &tegra_lp2_debug_ops);
> + if (!d)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +#endif
> +
> +late_initcall(tegra_cpuidle_debug_init);
Will this compile with CONFIG_DEBUG_FS=n?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH] MFD: DaVinci: Fix voice codec device name
From: Liam Girdwood @ 2011-01-27 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296134916-25742-1-git-send-email-prakash.pm@ti.com>
On Thu, 2011-01-27 at 18:58 +0530, Manjunathappa, Prakash wrote:
> Fix the device name in DaVinci Voice Codec MFD driver to load
> davinci-vcif and cq93vc codec client drivers.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
> ---
> This patch applies to Linus's tree at [1].
>
> [1] http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> ---
> drivers/mfd/davinci_voicecodec.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mfd/davinci_voicecodec.c b/drivers/mfd/davinci_voicecodec.c
> index 33c923d..fdd8a1b 100644
> --- a/drivers/mfd/davinci_voicecodec.c
> +++ b/drivers/mfd/davinci_voicecodec.c
> @@ -118,12 +118,12 @@ static int __init davinci_vc_probe(struct platform_device *pdev)
>
> /* Voice codec interface client */
> cell = &davinci_vc->cells[DAVINCI_VC_VCIF_CELL];
> - cell->name = "davinci_vcif";
> + cell->name = "davinci-vcif";
> cell->driver_data = davinci_vc;
>
> /* Voice codec CQ93VC client */
> cell = &davinci_vc->cells[DAVINCI_VC_CQ93VC_CELL];
> - cell->name = "cq93vc";
> + cell->name = "cq93vc-codec";
> cell->driver_data = davinci_vc;
>
> ret = mfd_add_devices(&pdev->dev, pdev->id, davinci_vc->cells,
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
^ permalink raw reply
* [alsa-devel] [PATCH] ASoC: DaVinci: fix kernel panic due to uninitialized platform_data
From: Liam Girdwood @ 2011-01-27 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296136063-31625-1-git-send-email-prakash.pm@ti.com>
On Thu, 2011-01-27 at 19:17 +0530, Manjunathappa, Prakash wrote:
> This patch fixes the Kernel panic issue on accessing davinci_vc in
> cq93vc_probe function. struct davinci_vc is part of platform device's
> private driver data(codec->dev->p->driver_data) and this is populated
> by DaVinci Voice Codec MFD driver.
>
> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com>
> ---
> This patch applies to Linus's tree at [1].
>
> [1] http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> ---
> sound/soc/codecs/cq93vc.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c
> index 46dbfd0..347a567 100644
> --- a/sound/soc/codecs/cq93vc.c
> +++ b/sound/soc/codecs/cq93vc.c
> @@ -153,7 +153,7 @@ static int cq93vc_resume(struct snd_soc_codec *codec)
>
> static int cq93vc_probe(struct snd_soc_codec *codec)
> {
> - struct davinci_vc *davinci_vc = codec->dev->platform_data;
> + struct davinci_vc *davinci_vc = snd_soc_codec_get_drvdata(codec);
>
> davinci_vc->cq93vc.codec = codec;
> codec->control_data = davinci_vc;
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
^ permalink raw reply
* [GIT PULL] ARM Tegra fixes for 2.6.38
From: Linus Torvalds @ 2011-01-27 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim6zcdn8FgUTa7OO=_4B3x5CiHxWr_g=uR0m4zX@mail.gmail.com>
On Thu, Jan 27, 2011 at 3:41 PM, Colin Cross <ccross@google.com> wrote:
>
> Please pull fixes for the Tegra machine from:
>
> ?http://android.git.kernel.org/kernel/tegra.git for-linus
I don't do http fetching. My life is too short. If there isn't a
native git server, make one.
Linus
^ permalink raw reply
* Locking in the clk API
From: Russell King - ARM Linux @ 2011-01-27 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D41D5EC.6030405@codeaurora.org>
On Thu, Jan 27, 2011 at 12:30:36PM -0800, Saravana Kannan wrote:
> On 01/27/2011 12:54 AM, Russell King - ARM Linux wrote:
>> On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
>>> I'm not too familiar with serial/tty, does anyone know if the
>>> .set_termios needs to be atmoic? If not, we could just change
>>> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.
>>
>> The locking is there to protect against the interrupt handler accessing
>> the port->* stuff (which seems to have been forgotten by the cpm driver).
>>
>> I don't see any reason why clk_set_rate() needs to be under the spinlock
>> there - we need the reprogramming of the baud rate within the spinlock
>> on 8250 because of DLAB bit hiding the data registers. It's also a good
>> idea that it _is_ within the spinlock along with uart_update_timeout()
>> to ensure timeouts and the baud rate are updated together.
>
> For internal tree purposes, does .set_termios need to be atomic? Can it
> grab mutexes instead of spinlock?
I think I already answered that question above where I said "protect
against the interrupt handler accessing the port->* stuff".
> Going back to the topic, how about CPU freq drivers possibly using
> clk_set_rate() to change freq? Do you think that's not the case or a
> concern?
CPUfreq drivers probably should busy-wait until the CPU PLL has locked
if the CPU is allowed to continue running while the PLL relocks. Some
implementations will halt the CPU while the PLL is transitioning and
that's really not unreasonable to do.
I think some even require the code to be running out of SRAM and SDRAM
remain untouched while the PLL is transitioning (omap maybe?)
^ permalink raw reply
* [PATCH] msm: Clean up useless ifdefs
From: Daniel Walker @ 2011-01-27 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296159202-13980-1-git-send-email-stepanm@codeaurora.org>
On Thu, 2011-01-27 at 12:13 -0800, Stepan Moskovchenko wrote:
> Remove ifdefs that do nothing, either from having the code
> between them previously removed, or from having been
> accidentally added to the wrong file.
>
> Change-Id: I94aac2cb24e23ba7f8b4b158ce6653dc3b786989
> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
You need to drop the Change-Id: ..
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH] msm: Clean up useless ifdefs
From: David Brown @ 2011-01-27 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296161064.28965.10.camel@c-dwalke-linux.qualcomm.com>
On Thu, Jan 27 2011, Daniel Walker wrote:
> On Thu, 2011-01-27 at 12:13 -0800, Stepan Moskovchenko wrote:
>> Remove ifdefs that do nothing, either from having the code
>> between them previously removed, or from having been
>> accidentally added to the wrong file.
>>
>> Change-Id: I94aac2cb24e23ba7f8b4b158ce6653dc3b786989
>> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
>
> You need to drop the Change-Id: ..
If there aren't any other concerns raised, I can pull these off when I
pull in these changes. But, yes, in generall, they shouldn't be
present.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* locomo.c: factor out "sendbyte" from locomo_m62332_senddata
From: H Hartley Sweeten @ 2011-01-27 20:52 UTC (permalink / raw)
To: linux-arm-kernel
The locomo_m62332_senddata function sends a three byte i2c message to
an attached DAC. Each of the three byte transfers, and associated ACK,
is individually coded in the function.
Factor out the "sendbyte" code to make locomo_m62332_senddata more
legible.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
---
diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index a026a6b..25a9642 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -660,15 +660,56 @@ static void locomo_m62332_sendbit(void *mapbase, int bit)
udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4.0 usec */
}
+static int locomo_m62332_sendbyte(void *mapbase, unsigned char data)
+{
+ unsigned int r;
+ int i;
+
+ /* Send the data */
+ for (i = 1; i <= 8; i++)
+ locomo_m62332_sendbit(mapbase, data >> (8 - i));
+
+ /* Check A bit */
+ r = locomo_readl(mapbase + LOCOMO_DAC);
+ r &= ~(LOCOMO_DAC_SCLOEB);
+ locomo_writel(r, mapbase + LOCOMO_DAC);
+ udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
+ udelay(DAC_SCL_LOW_HOLD_TIME); /* 4.7 usec */
+ r = locomo_readl(mapbase + LOCOMO_DAC);
+ r &= ~(LOCOMO_DAC_SDAOEB);
+ locomo_writel(r, mapbase + LOCOMO_DAC);
+ udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
+ r = locomo_readl(mapbase + LOCOMO_DAC);
+ r |= LOCOMO_DAC_SCLOEB;
+ locomo_writel(r, mapbase + LOCOMO_DAC);
+ udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
+ udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4.7 usec */
+ if (locomo_readl(mapbase + LOCOMO_DAC) & LOCOMO_DAC_SDAOEB)
+ return -ETIMEDOUT; /* High is error */
+
+ return 0;
+}
+
void locomo_m62332_senddata(struct locomo_dev *ldev, unsigned int dac_data, int channel)
{
struct locomo *lchip = locomo_chip_driver(ldev);
int i;
- unsigned char data;
+ unsigned char data[3];
unsigned int r;
void *mapbase = lchip->base;
unsigned long flags;
+ /*
+ * 0 = slave address and W bit (LSB is W bit)
+ * 1 = sub address (LSB is channel select)
+ * channel = 0 : ch1 select
+ * = 1 : ch2 select
+ * 2 = DAC data
+ */
+ data[0] = (M62332_SLAVE_ADDR << 1) | M62332_W_BIT;
+ data[1] = M62332_SUB_ADDR + channel;
+ data[2] = dac_data;
+
spin_lock_irqsave(&lchip->lock, flags);
/* Start */
@@ -684,85 +725,15 @@ void locomo_m62332_senddata(struct locomo_dev *ldev, unsigned int dac_data, int
udelay(DAC_START_HOLD_TIME); /* 5.0 usec */
udelay(DAC_DATA_HOLD_TIME); /* 300 nsec */
- /* Send slave address and W bit (LSB is W bit) */
- data = (M62332_SLAVE_ADDR << 1) | M62332_W_BIT;
- for (i = 1; i <= 8; i++) {
- locomo_m62332_sendbit(mapbase, data >> (8 - i));
+ /* Send the data and check for each ACK */
+ for (i = 0; i < 3; i++) {
+ if (locomo_m62332_sendbyte(mapbase, data[i])) {
+ printk(KERN_WARNING "locomo: m62332_senddata Error %d\n",
+ i+1);
+ break;
+ }
}
- /* Check A bit */
- r = locomo_readl(mapbase + LOCOMO_DAC);
- r &= ~(LOCOMO_DAC_SCLOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
- udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
- udelay(DAC_SCL_LOW_HOLD_TIME); /* 4.7 usec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
- r &= ~(LOCOMO_DAC_SDAOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
- udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
- r |= LOCOMO_DAC_SCLOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
- udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
- udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4.7 usec */
- if (locomo_readl(mapbase + LOCOMO_DAC) & LOCOMO_DAC_SDAOEB) { /* High is error */
- printk(KERN_WARNING "locomo: m62332_senddata Error 1\n");
- goto out;
- }
-
- /* Send Sub address (LSB is channel select) */
- /* channel = 0 : ch1 select */
- /* = 1 : ch2 select */
- data = M62332_SUB_ADDR + channel;
- for (i = 1; i <= 8; i++) {
- locomo_m62332_sendbit(mapbase, data >> (8 - i));
- }
-
- /* Check A bit */
- r = locomo_readl(mapbase + LOCOMO_DAC);
- r &= ~(LOCOMO_DAC_SCLOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
- udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
- udelay(DAC_SCL_LOW_HOLD_TIME); /* 4.7 usec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
- r &= ~(LOCOMO_DAC_SDAOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
- udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
- r |= LOCOMO_DAC_SCLOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
- udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
- udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4.7 usec */
- if (locomo_readl(mapbase + LOCOMO_DAC) & LOCOMO_DAC_SDAOEB) { /* High is error */
- printk(KERN_WARNING "locomo: m62332_senddata Error 2\n");
- goto out;
- }
-
- /* Send DAC data */
- for (i = 1; i <= 8; i++) {
- locomo_m62332_sendbit(mapbase, dac_data >> (8 - i));
- }
-
- /* Check A bit */
- r = locomo_readl(mapbase + LOCOMO_DAC);
- r &= ~(LOCOMO_DAC_SCLOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
- udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
- udelay(DAC_SCL_LOW_HOLD_TIME); /* 4.7 usec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
- r &= ~(LOCOMO_DAC_SDAOEB);
- locomo_writel(r, mapbase + LOCOMO_DAC);
- udelay(DAC_LOW_SETUP_TIME); /* 300 nsec */
- r = locomo_readl(mapbase + LOCOMO_DAC);
- r |= LOCOMO_DAC_SCLOEB;
- locomo_writel(r, mapbase + LOCOMO_DAC);
- udelay(DAC_HIGH_SETUP_TIME); /* 1000 nsec */
- udelay(DAC_SCL_HIGH_HOLD_TIME); /* 4.7 usec */
- if (locomo_readl(mapbase + LOCOMO_DAC) & LOCOMO_DAC_SDAOEB) { /* High is error */
- printk(KERN_WARNING "locomo: m62332_senddata Error 3\n");
- }
-
-out:
/* stop */
r = locomo_readl(mapbase + LOCOMO_DAC);
r &= ~(LOCOMO_DAC_SCLOEB);
^ permalink raw reply related
* Locking in the clk API
From: Alan Cox @ 2011-01-27 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110127204354.GB1597@n2100.arm.linux.org.uk>
> > For internal tree purposes, does .set_termios need to be atomic? Can it
> > grab mutexes instead of spinlock?
>
> I think I already answered that question above where I said "protect
> against the interrupt handler accessing the port->* stuff".
I'm not sure you answered it correctly however as the locking nowdays is
a bit different.
Architecturally the termios handling doesn't need a spin lock nor is it
called under one. In fact it's vital this is the case because of USB.
I see nothing in the 2.6.37 cpm_uart code that isn't trivially fixable.
There is already a mutex protecting termios serialization so all you seem
to need to do is call clk_set_rate after rather than before dropping the
lock surely ?
Oh if you are looking at the cpm_uart code and care about it the following
in the code isn't safe as tty could possibly go NULL and be freed under
you.
struct tty_struct *tty = port->state->port.tty;
and you ought to be doing
tty = tty_port_tty_get(&port->state->port);
if (tty)
blah;
tty_kref_put(tty); /* put NULL is a no-op anyway */
probably in the main irq handler and pass tty to the helpers that need it.
Alan
^ permalink raw reply
* Locking in the clk API
From: Russell King - ARM Linux @ 2011-01-27 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110127210729.79eef2c1@lxorguk.ukuu.org.uk>
On Thu, Jan 27, 2011 at 09:07:29PM +0000, Alan Cox wrote:
> > > For internal tree purposes, does .set_termios need to be atomic? Can it
> > > grab mutexes instead of spinlock?
> >
> > I think I already answered that question above where I said "protect
> > against the interrupt handler accessing the port->* stuff".
>
> I'm not sure you answered it correctly however as the locking nowdays is
> a bit different.
>
> Architecturally the termios handling doesn't need a spin lock nor is it
> called under one. In fact it's vital this is the case because of USB.
It needs to protect against the read_status_mask and ignore_status_mask
being read half-way through an update by the interrupt handler, otherwise
you can end up with god-knows-what coming through from each termios
change.
Eg, you could see an effective CREAD flip when the state of CREAD wasn't
actually changed.
^ permalink raw reply
* Locking in the clk API
From: Russell King - ARM Linux @ 2011-01-27 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110127210729.79eef2c1@lxorguk.ukuu.org.uk>
On Thu, Jan 27, 2011 at 09:07:29PM +0000, Alan Cox wrote:
> > > For internal tree purposes, does .set_termios need to be atomic? Can it
> > > grab mutexes instead of spinlock?
> >
> > I think I already answered that question above where I said "protect
> > against the interrupt handler accessing the port->* stuff".
>
> I'm not sure you answered it correctly however as the locking nowdays is
> a bit different.
Oh, and the other bit to this is protecting the hardware against two
concurrent accesses if that's what's required.
Eg, 8250 having characters written to the 'transmit' register while
DLAB is set, thereby corrupting the divisor being programmed into it.
There's other UARTs which shouldn't have FIFOs loaded while the UART
is disabled across an update.
Can you guarantee without locks that writes to the UART registers by
the interrupt handler won't happen while the .set_termios is
reprogramming the UART?
^ permalink raw reply
* [PATCH] MMCI: don't read command response when invalid
From: Chris Ball @ 2011-01-27 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110127153332.GA14591@void.printf.net>
On Thu, Jan 27, 2011 at 03:33:32PM +0000, Chris Ball wrote:
> Hi Russell,
>
> On Thu, Jan 27, 2011 at 12:19:01PM +0000, Russell King - ARM Linux wrote:
> > FYI, I've now merged this into the ARM devel tree for the time being so
> > it doesn't get forgotten - which means it'll appear in linux-next at some
> > point if it isn't already there. (Mainly so I don't have to keep on
> > adding the patch.)
> >
> > Once you push it into mainline, I'll drop my copy.
>
> Okay. Sent this to Linus yesterday, just waiting for him to pull.
> (It's been in linux-next for the last two weeks.)
It's present in mainline now.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH] MMCI: don't read command response when invalid
From: Russell King - ARM Linux @ 2011-01-27 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110127212814.GA21801@void.printf.net>
On Thu, Jan 27, 2011 at 09:28:14PM +0000, Chris Ball wrote:
> On Thu, Jan 27, 2011 at 03:33:32PM +0000, Chris Ball wrote:
> > Hi Russell,
> >
> > On Thu, Jan 27, 2011 at 12:19:01PM +0000, Russell King - ARM Linux wrote:
> > > FYI, I've now merged this into the ARM devel tree for the time being so
> > > it doesn't get forgotten - which means it'll appear in linux-next at some
> > > point if it isn't already there. (Mainly so I don't have to keep on
> > > adding the patch.)
> > >
> > > Once you push it into mainline, I'll drop my copy.
> >
> > Okay. Sent this to Linus yesterday, just waiting for him to pull.
> > (It's been in linux-next for the last two weeks.)
>
> It's present in mainline now.
Thanks, dropped from my tree now.
^ permalink raw reply
* [PATCH v2 18/28] ARM: tegra: add CPU_IDLE driver
From: Colin Cross @ 2011-01-27 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D41D7C2.3080608@codeaurora.org>
On Thu, Jan 27, 2011 at 12:38 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 01/23/2011 06:01 PM, Colin Cross wrote:
>>
>> +static int __init tegra_cpuidle_debug_init(void)
>> +{
>> + ? ? struct dentry *dir;
>> + ? ? struct dentry *d;
>> +
>> + ? ? dir = debugfs_create_dir("cpuidle", NULL);
>> + ? ? if (!dir)
>> + ? ? ? ? ? ? return -ENOMEM;
>> +
>> + ? ? d = debugfs_create_file("lp2", S_IRUGO, dir, NULL,
>> + ? ? ? ? ? ? &tegra_lp2_debug_ops);
>> + ? ? if (!d)
>> + ? ? ? ? ? ? return -ENOMEM;
>> +
>> + ? ? return 0;
>> +}
>> +#endif
>> +
>> +late_initcall(tegra_cpuidle_debug_init);
>
> Will this compile with CONFIG_DEBUG_FS=n?
Yes. All debugfs ops return ERR_PTR(-ENODEV) if CONFIG_DEBUG_FS=n, so
tegra_cpuidle_debug_init will do nothing and return 0.
^ permalink raw reply
* [PATCH v2 18/28] ARM: tegra: add CPU_IDLE driver
From: Colin Cross @ 2011-01-27 22:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=o5o2_4Ur2GTS=0XSoYqFMYqSF99aU9N_wxWuu@mail.gmail.com>
On Thu, Jan 27, 2011 at 1:51 PM, Colin Cross <ccross@android.com> wrote:
> On Thu, Jan 27, 2011 at 12:38 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>> On 01/23/2011 06:01 PM, Colin Cross wrote:
>>>
>>> +static int __init tegra_cpuidle_debug_init(void)
>>> +{
>>> + ? ? struct dentry *dir;
>>> + ? ? struct dentry *d;
>>> +
>>> + ? ? dir = debugfs_create_dir("cpuidle", NULL);
>>> + ? ? if (!dir)
>>> + ? ? ? ? ? ? return -ENOMEM;
>>> +
>>> + ? ? d = debugfs_create_file("lp2", S_IRUGO, dir, NULL,
>>> + ? ? ? ? ? ? &tegra_lp2_debug_ops);
>>> + ? ? if (!d)
>>> + ? ? ? ? ? ? return -ENOMEM;
>>> +
>>> + ? ? return 0;
>>> +}
>>> +#endif
>>> +
>>> +late_initcall(tegra_cpuidle_debug_init);
>>
>> Will this compile with CONFIG_DEBUG_FS=n?
>
> Yes. ?All debugfs ops return ERR_PTR(-ENODEV) if CONFIG_DEBUG_FS=n, so
> tegra_cpuidle_debug_init will do nothing and return 0.
>
Oops no, it will not compile. Will fix.
^ 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