RE: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
On Tue, Sep 04, 2012 at 15:47:59, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> On 09/04/2012 05:42 AM, Vaibhav Hiremath wrote:
> > On 9/3/2012 8:16 PM, Benoit Cousson wrote:
> >> Hi Peter,
> >>
> >> The overall series looks good to me, but I do have a couple of comments.
> >>
> >> On 08/29/2012 03:31 PM, Peter Ujfalusi wrote:
> >>> The McBSP IP within OMAP2420 and 2430 is different we need to create
> >>> separate
> >>> dtsi files for them.
> >>>
> >>> Signed-off-by: Peter Ujfalusi
> >>> ---
> >>> arch/arm/boot/dts/omap2420.dtsi | 39 ++
> >>> arch/arm/boot/dts/omap2430.dtsi | 83
> >>> +++
> >>> 2 files changed, 122 insertions(+), 0 deletions(-)
> >>> create mode 100644 arch/arm/boot/dts/omap2420.dtsi
> >>> create mode 100644 arch/arm/boot/dts/omap2430.dtsi
> >>>
> >>> diff --git a/arch/arm/boot/dts/omap2420.dtsi
> >>> b/arch/arm/boot/dts/omap2420.dtsi
> >>> new file mode 100644
> >>> index 000..f375c68
> >>> --- /dev/null
> >>> +++ b/arch/arm/boot/dts/omap2420.dtsi
> >>> @@ -0,0 +1,39 @@
> >>> +/*
> >>> + * Device Tree Source for OMAP2420 SoC
> >>> + *
> >>> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> >>
> >> Nit: 2012
> >>
> >>> + *
> >>> + * This file is licensed under the terms of the GNU General Public
> >>> License
> >>> + * version 2. This program is licensed "as is" without any warranty of
> >>> any
> >>> + * kind, whether express or implied.
> >>> + */
> >>> +
> >>> +/include/ "omap2.dtsi"
> >>> +
> >>> +/ {
> >>> + compatible = "ti,omap2420", "ti,omap2";
> >>> +
> >>> + ocp {
> >>> + mcbsp1: mcbsp@48074000 {
> >>> + compatible = "ti,omap2420-mcbsp";
> >>> + reg = <0x48074000 0xff>;
> >>> + reg-names = "mpu";
> >>> + interrupts = <0 59 0x4>, /* TX interrupt */
> >>> + <0 60 0x4>; /* RX interrupt */
> >>
> >> That one is not correct because it does comply with the interrupt
> >> controller specifier that require only one cell:
> >>
> >>intc: interrupt-controller@4820 {
> >>compatible = "ti,omap2-intc";
> >>interrupt-controller;
> >>#interrupt-cells = <1>;
> >> ...
> >>
> >> The one you are using is for GIC IRQ controller.
> >> It works probably because we are using hwmod so far :-)
> >>
> >
> > I think now we should kill the resource overwrite path, and should
> > respect and use resources passed from DT.
> >
> > Benoit,
> > Did you get a chance to validate patch submitted towards this??
>
> Not yet, but we discussed that with Peter and since he does have these
> patches for DT, he'll be able to test your series with the McBSP changes.
>
Great.
> I still want to update a couple of DTS to test that on some other IPs.
>
Ohh ok. Please let me know if I can help you here by any means.
I am equipped with AM37xEVM, BeagleBoard and Panda.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP: Compilation error: omapzoom kernel tree
Hello, Which branch should i use from TI[1] tree? I need to boot linux with linaro-nano. I tried: p-linux-omap-3.4 branch but i am getting compilation error for omap4plus_pm_min_defconfig and omap2plus_defconfig: /home/arm/work/kernel/mywork/linux.git/arch/arm/mm/proc-v7.S: Assembler messages: /home/arm/work/kernel/mywork/linux.git/arch/arm/mm/proc-v7.S:260: Error: selected processor does not support ARM mode `smc #0' /home/arm/work/kernel/mywork/linux.git/arch/arm/mm/proc-v7.S:260: Error: selected processor does not support ARM mode `smc #0' make[2]: *** [arch/arm/mm/proc-v7.o] Error 1 Can somebody help? -- viresh [1] http://omapzoom.org/?p=kernel/omap.git;a=summary -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: Fix array size for irq_target_cpu
On Wed, Sep 5, 2012 at 5:33 AM, Tony Lindgren wrote: > > If NR_IRQS is less than MAX_IRQS, we end up writing past the > irq_target_cpu array in omap_wakeupgen_init(): > > /* Associate all the IRQs to boot CPU like GIC init does. */ > for (i = 0; i < max_irqs; i++) > irq_target_cpu[i] = boot_cpu; > > This can happen if SPARSE_IRQ is enabled as by default NR_IRQS is > set to 16. Without this patch we're overwriting other data during > the boot. > > Signed-off-by: Tony Lindgren > Looks good. Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
Dear Bryan Wu,
> On Sat, Sep 1, 2012 at 4:16 PM, AnilKumar Ch wrote:
> > Adopt pinctrl support to leds-gpio driver based on leds-gpio
> > device pointer, pinctrl driver configure SoC pins to GPIO
> > mode according to definitions provided in .dts file.
>
> Thanks for this, actually Marek Vasut submitted a similar patch
> before. I'm pretty fine with this patch.
Thanks for submitting this actually ... I didn't have time to properly
investigate this.
> But without proper DT setting, it will also give us warning I think.
> or we can provide some dummy functions as a temp solution as Shawn
> pointed out before.
But this driver is also used on hardware that's not yet coverted to DT, so I'd
say dev_warn() if CONFIG_OF is enabled and otherwise simply go on ? Actually,
can we not skip whole this pinctrl thing if CONFIG_OF is disabled? Actually
(2),
what's the relationship between OF and pinctrl?
> -Bryan
>
> > Signed-off-by: AnilKumar Ch
> > ---
> >
> > Changes from v1:
> > - Seperated from "Add DT for AM33XX devices" patch series
> > - Incorporated Tony's comments on v1
> >
> > * Changed to warning message instead od error return
> >
> > drivers/leds/leds-gpio.c |7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> > index c032b21..ad577f4 100644
> > --- a/drivers/leds/leds-gpio.c
> > +++ b/drivers/leds/leds-gpio.c
> > @@ -20,6 +20,7 @@
> >
> > #include
> > #include
> > #include
> >
> > +#include
> >
> > struct gpio_led_data {
> >
> > struct led_classdev cdev;
> >
> > @@ -236,8 +237,14 @@ static int __devinit gpio_led_probe(struct
> > platform_device *pdev)
> >
> > {
> >
> > struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
> > struct gpio_leds_priv *priv;
> >
> > + struct pinctrl *pinctrl;
> >
> > int i, ret = 0;
> >
> > + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> > + if (IS_ERR(pinctrl))
> > + dev_warn(&pdev->dev,
> > + "pins are not configured from the driver\n");
> > +
> >
> > if (pdata && pdata->num_leds) {
> >
> > priv = devm_kzalloc(&pdev->dev,
> >
> > sizeof_gpio_leds_priv(pdata->num_leds),
> >
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-leds" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
On Sat, Sep 1, 2012 at 4:16 PM, AnilKumar Ch wrote:
> Adopt pinctrl support to leds-gpio driver based on leds-gpio
> device pointer, pinctrl driver configure SoC pins to GPIO
> mode according to definitions provided in .dts file.
>
Thanks for this, actually Marek Vasut submitted a similar patch
before. I'm pretty fine with this patch.
But without proper DT setting, it will also give us warning I think.
or we can provide some dummy functions as a temp solution as Shawn
pointed out before.
-Bryan
> Signed-off-by: AnilKumar Ch
> ---
> Changes from v1:
> - Seperated from "Add DT for AM33XX devices" patch series
> - Incorporated Tony's comments on v1
> * Changed to warning message instead od error return
>
> drivers/leds/leds-gpio.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index c032b21..ad577f4 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> struct gpio_led_data {
> struct led_classdev cdev;
> @@ -236,8 +237,14 @@ static int __devinit gpio_led_probe(struct
> platform_device *pdev)
> {
> struct gpio_led_platform_data *pdata = pdev->dev.platform_data;
> struct gpio_leds_priv *priv;
> + struct pinctrl *pinctrl;
> int i, ret = 0;
>
> + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(pinctrl))
> + dev_warn(&pdev->dev,
> + "pins are not configured from the driver\n");
> +
> if (pdata && pdata->num_leds) {
> priv = devm_kzalloc(&pdev->dev,
> sizeof_gpio_leds_priv(pdata->num_leds),
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-leds" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Bryan Wu
Kernel Developer+86.186-168-78255 Mobile
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ
* Tony Lindgren [120830 17:53]: > Remove hardcoded IRQs in irqs.h and related files as these > are no longer needed. Here's a version that actually boots properly on omap2/3/4. Note that for omap4 also patch "[PATCH] ARM: OMAP4: Fix array size for irq_target_cpu" is needed. Regards, Tony From: Tony Lindgren Date: Mon, 27 Aug 2012 17:43:01 -0700 Subject: [PATCH] ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ Remove hardcoded IRQs in irqs.h and related files as these are no longer needed. Signed-off-by: Tony Lindgren diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h index 7e60a69..4cdb08c 100644 --- a/arch/arm/mach-omap2/common.h +++ b/arch/arm/mach-omap2/common.h @@ -26,12 +26,13 @@ #define __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H #ifndef __ASSEMBLER__ +#include #include #include #include #include -#define OMAP_INTC_START0 +#define OMAP_INTC_STARTNR_IRQS #ifdef CONFIG_SOC_OMAP2420 extern void omap242x_map_common_io(void); diff --git a/arch/arm/mach-omap2/include/mach/irqs.h b/arch/arm/mach-omap2/include/mach/irqs.h index 44dab77..ba5282c 100644 --- a/arch/arm/mach-omap2/include/mach/irqs.h +++ b/arch/arm/mach-omap2/include/mach/irqs.h @@ -1,5 +1,3 @@ /* * arch/arm/mach-omap2/include/mach/irqs.h */ - -#include diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index dd36eba..d15a4a6 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -25,6 +25,7 @@ config ARCH_OMAP2PLUS bool "TI OMAP2/3/4" select CLKDEV_LOOKUP select GENERIC_IRQ_CHIP + select SPARSE_IRQ select OMAP_DM_TIMER select USE_OF select PROC_DEVICETREE if PROC_FS diff --git a/arch/arm/plat-omap/include/plat/irqs-44xx.h b/arch/arm/plat-omap/include/plat/irqs-44xx.h deleted file mode 100644 index 518322c..000 --- a/arch/arm/plat-omap/include/plat/irqs-44xx.h +++ /dev/null @@ -1,144 +0,0 @@ -/* - * OMAP4 Interrupt lines definitions - * - * Copyright (C) 2009-2010 Texas Instruments, Inc. - * - * Santosh Shilimkar (santosh.shilim...@ti.com) - * Benoit Cousson (b-cous...@ti.com) - * - * This file is automatically generated from the OMAP hardware databases. - * We respectfully ask that any modifications to this file be coordinated - * with the public linux-omap@vger.kernel.org mailing list and the - * authors above to ensure that the autogeneration scripts are kept - * up-to-date with the file contents. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#ifndef __ARCH_ARM_MACH_OMAP2_OMAP44XX_IRQS_H -#define __ARCH_ARM_MACH_OMAP2_OMAP44XX_IRQS_H - -/* OMAP44XX IRQs numbers definitions */ -#define OMAP44XX_IRQ_LOCALTIMER29 -#define OMAP44XX_IRQ_LOCALWDT 30 - -#define OMAP44XX_IRQ_GIC_START 32 - -#define OMAP44XX_IRQ_PL310 (0 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_CTI0 (1 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_CTI1 (2 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_ELM (4 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SYS_1N(7 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SECURITY_EVENTS (8 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_L3_DBG(9 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_L3_APP(10 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_PRCM (11 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_0(12 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_1(13 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_2(14 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SDMA_3(15 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MCBSP4(16 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MCBSP1(17 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SR_MCU(18 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_SR_CORE (19 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GPMC (20 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_GFX (21 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MCBSP2(22 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MCBSP3(23 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_ISS_5 (24 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_DSS_DISPC (25 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_MAIL_U0 (26 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_C2C_SSCM_0(27 + OMAP44XX_IRQ_GIC_START) -#define OMAP44XX_IRQ_TESLA_MMU (28 +
Re: [PATCH 7/9] ARM: OMAP2+: Prepare for irqs.h removal
* Tony Lindgren [120830 17:53]:
> As the interrupts should only be defined in the platform_data, and
> eventually coming from device tree, there's no need to define them
> in header files.
>
> Let's remove the hardcoded references to irqs.h and fix up the includes
> so we don't rely on headers included in irqs.h. While at it, sort
> the includes the standard way.
Turns out this patch was not quite working with SPARSE_IRQ, we have
to add OMAP_INTC_START for that. Also fixed up is compile for
drivers/staging/tidspbridge. Updated patch below.
Regards,
Tony
From: Tony Lindgren
Date: Mon, 27 Aug 2012 17:43:01 -0700
Subject: [PATCH] ARM: OMAP2+: Prepare for irqs.h removal
As the interrupts should only be defined in the platform_data, and
eventually coming from device tree, there's no need to define them
in header files.
Let's remove the hardcoded references to irqs.h and fix up the includes
so we don't rely on headers included in irqs.h. Note that we're
defining OMAP_INTC_START as 0 to the interrupts. This will be needed
when we enable SPARSE_IRQ.
While at it, sort the includes the standard way, and add the trailing
commas where they are missing in the related data structures.
Note that for drivers/staging/tidspbridge we just define things
locally.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index cacc498..7e31981 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -28,19 +28,20 @@
#include
#include
-#include
#include
#include
#include
-#include "common.h"
#include
#include
#include
+#include
+
#include
#include
+#include "common.h"
#include "mux.h"
#include "hsmmc.h"
#include "common-board-devices.h"
@@ -231,7 +232,7 @@ static int __init omap2430_i2c_init(void)
sdp2430_i2c1_boardinfo[0].irq = gpio_to_irq(78);
omap_register_i2c_bus(1, 100, sdp2430_i2c1_boardinfo,
ARRAY_SIZE(sdp2430_i2c1_boardinfo));
- omap_pmic_init(2, 100, "twl4030", INT_24XX_SYS_NIRQ,
+ omap_pmic_init(2, 100, "twl4030", 7 + OMAP_INTC_START,
&sdp2430_twldata);
return 0;
}
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ee82604..31456ea 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -579,7 +579,7 @@ static int __init omap4_i2c_init(void)
TWL_COMMON_REGULATOR_V1V8 |
TWL_COMMON_REGULATOR_V2V1);
omap4_pmic_init("twl6030", &sdp4430_twldata,
- &twl6040_data, OMAP44XX_IRQ_SYS_2N);
+ &twl6040_data, 119 + OMAP44XX_IRQ_GIC_START);
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
ARRAY_SIZE(sdp4430_i2c_3_boardinfo));
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index c6d63d7..9bc0b94 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -298,8 +298,7 @@ static struct resource am3517_hecc_resources[] = {
.flags = IORESOURCE_MEM,
},
{
- .start = INT_35XX_HECC0_IRQ,
- .end= INT_35XX_HECC0_IRQ,
+ .start = 24 + OMAP_INTC_START,
.flags = IORESOURCE_IRQ,
},
};
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 30b7b01..350441a 100644
--- a/arch/arm/mach-omap2/board-cm-t3517.c
+++ b/arch/arm/mach-omap2/board-cm-t3517.c
@@ -38,13 +38,14 @@
#include
#include
-#include "common.h"
#include
#include
#include
+#include
#include
+#include "common.h"
#include "mux.h"
#include "control.h"
#include "common-board-devices.h"
@@ -89,8 +90,7 @@ static struct resource cm_t3517_hecc_resources[] = {
.flags = IORESOURCE_MEM,
},
{
- .start = INT_35XX_HECC0_IRQ,
- .end= INT_35XX_HECC0_IRQ,
+ .start = 24 + OMAP_INTC_START,
.flags = IORESOURCE_IRQ,
},
};
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index c8d4382..bd67c4c 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -16,8 +16,8 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 08471a3..c6440cb 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -23,19 +23,20 @@
#include
#include
#include
-
#include
+#include
#include
#include
-#include "common.h"
#include
#include
+#include
+
#include
#include
-#include
+#include "common.h"
#include "mux.h"
#include "hsm
Re: [PATCH 7/9] ARM: OMAP2+: Prepare for irqs.h removal
* Mohammed, Afzal [120904 01:47]:
> Hi Tony,
>
> On Fri, Aug 31, 2012 at 06:22:37, Tony Lindgren wrote:
> > As the interrupts should only be defined in the platform_data, and
> > eventually coming from device tree, there's no need to define them
> > in header files.
> >
> > Let's remove the hardcoded references to irqs.h and fix up the includes
> > so we don't rely on headers included in irqs.h. While at it, sort
> > the includes the standard way.
>
> > arch/arm/mach-omap2/gpmc.c | 11 +---
>
> > diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
>
> > /* GPMC register offsets */
> > #define GPMC_REVISION 0x00
> > #define GPMC_SYSCONFIG 0x10
> > @@ -846,16 +849,16 @@ static int __init gpmc_init(void)
> > l = OMAP2420_GPMC_BASE;
> > else
> > l = OMAP34XX_GPMC_BASE;
> > - gpmc_irq = INT_34XX_GPMC_IRQ;
> > + gpmc_irq = 20;
> > } else if (cpu_is_omap34xx()) {
> > ck = "gpmc_fck";
> > l = OMAP34XX_GPMC_BASE;
> > - gpmc_irq = INT_34XX_GPMC_IRQ;
> > + gpmc_irq = 20;
> > } else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
> > /* Base address and irq number are same for OMAP4/5 */
> > ck = "gpmc_ck";
> > l = OMAP44XX_GPMC_BASE;
> > - gpmc_irq = OMAP44XX_IRQ_GPMC;
> > + gpmc_irq = 20 + OMAP44XX_IRQ_GIC_START;
>
> I have a suggestion to avoid above hardcoded patching on gpmc.c.
> With driver conversion series it again would have to be patched.
>
>
> I have made a basic gpmc driver conversion, which is expected to
> be non-controversial. This was done over your devel-gpmc branch.
> It is working fine, has only 3 patches
>
> 1. Add hwmod entry
> 2. Adapt to hwmod
> 3. Basic driver conversion
>
> Here the basic driver gets resources and clk in driver probe
> using con-id "fck", it has no platform data as of now
>
> It is available
> @git://gitorious.org/x0148406-public/linux-kernel.git gpmc-simple-drv
Great, please post that. But let's get this cleanup out of the way
first. It's OK if we have to go back and forth a bit if it means
we can avoid dependencies between the patches as this is already
all over the place.
> Originally this was made on top of my series,
> "OMAP-GPMC: generic time calc, prepare for driver"
> It was modified so that it can be applied to your devel-gpmc branch.
>
> *I am not sending the patches now to avoid confusion by way of having
> too many patch series*
>
> In case you like this, let me know, I will post.
Yes please post the patches rebased on testing-cleanup branch that I
just pushed. That branch is not immutable yet though as we're waiting
to hear from Arnd regrading the first patch in the branch.
> As I am proceeding with Paul's suggestion on hwmod reset,
> I hope Paul can take the first one.
Let's first nail down the cleanup changes though..
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP4: Fix array size for irq_target_cpu
If NR_IRQS is less than MAX_IRQS, we end up writing past the irq_target_cpu array in omap_wakeupgen_init(): /* Associate all the IRQs to boot CPU like GIC init does. */ for (i = 0; i < max_irqs; i++) irq_target_cpu[i] = boot_cpu; This can happen if SPARSE_IRQ is enabled as by default NR_IRQS is set to 16. Without this patch we're overwriting other data during the boot. Signed-off-by: Tony Lindgren --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -47,7 +47,7 @@ static void __iomem *wakeupgen_base; static void __iomem *sar_base; static DEFINE_SPINLOCK(wakeupgen_lock); -static unsigned int irq_target_cpu[NR_IRQS]; +static unsigned int irq_target_cpu[MAX_IRQS]; static unsigned int irq_banks = MAX_NR_REG_BANKS; static unsigned int max_irqs = MAX_IRQS; static unsigned int omap_secure_apis; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/omap: hold a ref to the bo while waiting for flip
From: Rob Clark
Since the plane hasn't yet taken a reference, we need to hold a
reference while waiting to ensure the backing GEM bo doesn't get
freed from under us.
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_crtc.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_crtc.c
b/drivers/staging/omapdrm/omap_crtc.c
index dade3de..732f2ad 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -155,6 +155,7 @@ static void page_flip_cb(void *arg)
struct drm_crtc *crtc = arg;
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
struct drm_framebuffer *old_fb = omap_crtc->old_fb;
+ struct drm_gem_object *bo;
omap_crtc->old_fb = NULL;
@@ -165,6 +166,9 @@ static void page_flip_cb(void *arg)
* cycle.. for now go for correctness and later figure out speed..
*/
omap_plane_on_endwin(omap_crtc->plane, vblank_cb, crtc);
+
+ bo = omap_framebuffer_bo(crtc->fb, 0);
+ drm_gem_object_unreference_unlocked(bo);
}
static int omap_crtc_page_flip_locked(struct drm_crtc *crtc,
@@ -173,6 +177,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc *crtc,
{
struct drm_device *dev = crtc->dev;
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ struct drm_gem_object *bo;
DBG("%d -> %d", crtc->fb ? crtc->fb->base.id : -1, fb->base.id);
@@ -185,8 +190,15 @@ static int omap_crtc_page_flip_locked(struct drm_crtc
*crtc,
omap_crtc->event = event;
crtc->fb = fb;
- omap_gem_op_async(omap_framebuffer_bo(fb, 0), OMAP_GEM_READ,
- page_flip_cb, crtc);
+ /*
+* Hold a reference temporarily until the crtc is updated
+* and takes the reference to the bo. This avoids it
+* getting freed from under us:
+*/
+ bo = omap_framebuffer_bo(fb, 0);
+ drm_gem_object_reference(bo);
+
+ omap_gem_op_async(bo, OMAP_GEM_READ, page_flip_cb, crtc);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC update 0/2] dmaengine/ASoC: omap: Enable element mode in cyclic DMA
On Tue, 4 Sep 2012 15:08:00 Peter Ujfalusi wrote: > Hi Russell, > > Enable the element mode (thus allowing mono playback and probably unblocking > OMAP1, OMAP2420) in OMAP dmaengine and omap-pcm. > > Janusz: would it be possible for you to test Russell's series plus this on > OMAP1 to make sure that we do not broke it? Hi Peter, Russell, I'll be happy to make this test for you. This will take some time (I work away from home), but I expect to have it done by Monday. BTW, I haven't been following OMAP development very closely last weeks, and I didn't even know about the OMAP DMA engine availability. Which Linux version should I base my test on? Would 3.6-rc be OK? Or l-o master? Thanks, Janusz -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: remove unused hwmod function prototypes
On Tue, 4 Sep 2012, Igor Grinberg wrote: > Several hwmod function prototypes appear to not have an implementation > because the corresponding functions were removed or renamed. > Those prototypes are unneeded anymore - remove them. > > Signed-off-by: Igor Grinberg Thanks, queued for 3.7. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: remove unused hwmod function prototypes
Several hwmod function prototypes appear to not have an implementation because the corresponding functions were removed or renamed. Those prototypes are unneeded anymore - remove them. Signed-off-by: Igor Grinberg --- arch/arm/plat-omap/include/plat/omap_hwmod.h |7 --- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h index 6132972..a673f45 100644 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h @@ -591,9 +591,7 @@ int omap_hwmod_for_each(int (*fn)(struct omap_hwmod *oh, void *data), int __init omap_hwmod_setup_one(const char *name); int omap_hwmod_enable(struct omap_hwmod *oh); -int _omap_hwmod_enable(struct omap_hwmod *oh); int omap_hwmod_idle(struct omap_hwmod *oh); -int _omap_hwmod_idle(struct omap_hwmod *oh); int omap_hwmod_shutdown(struct omap_hwmod *oh); int omap_hwmod_assert_hardreset(struct omap_hwmod *oh, const char *name); @@ -626,11 +624,6 @@ int omap_hwmod_add_initiator_dep(struct omap_hwmod *oh, int omap_hwmod_del_initiator_dep(struct omap_hwmod *oh, struct omap_hwmod *init_oh); -int omap_hwmod_set_clockact_both(struct omap_hwmod *oh); -int omap_hwmod_set_clockact_main(struct omap_hwmod *oh); -int omap_hwmod_set_clockact_iclk(struct omap_hwmod *oh); -int omap_hwmod_set_clockact_none(struct omap_hwmod *oh); - int omap_hwmod_enable_wakeup(struct omap_hwmod *oh); int omap_hwmod_disable_wakeup(struct omap_hwmod *oh); -- 1.7.8.6 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
Hi > > > > >> AM335x uses NOP transceiver driver and need to enable > > > builtin PHY > > > > >> by writing into usb_ctrl register available in > system control > > > > >> module register space. This is being added at musb > glue driver > > > > >> layer untill a separate system control module driver is > > > available. > > > > >> > > > > >> Signed-off-by: Ajay Kumar Gupta > > > > >> Signed-off-by: Santhapuri, Damodar > > > > > >> Signed-off-by: Ravi Babu > > > > > > > > > > Kishon, you were adding a real phy driver for OMAP's internal > > > > > phy logic on one of your patches and I believe this will > > > conflict with > > > > > your changes, right ? > > > > > > > > Indeed. My final patch of that series removes some of the > > > > functions from omap_phy_internal.c (which was taken > care in the phy driver). > > > > > > > > > > How does this look to you ? Is this at least correct ? I > > > suppose the > > > > > correct way would be to actually have the system > control module > > > > > driver which we have been waiting, right ? > > > > > > > > Correct. I think once we have the system control module > driver in > > > > place, we'll have everything wrt control module register writes > > > > implemented in correct way. > > > > > > So $SUBJECT will pretty much be thrown away once we have > SCM driver, > > > in that case it's best to wait a bit longer and apply this series > > > once SCM driver is available and after your series too... > you agree > > > ? > > > > > > > Felipe, I am sure there are patches in this series[0/13], which are > > not dependent on this patch or control module, Can we pull in those > > patches (all dual instances support patches)? So that I can re-work > > and submit again? > > sure, will do, don't worry :-) Thanks. Then shall I rework patches [3/13 to 13/13] and re-submit only musb dual instances patches which are independent of control module. > > -- > balbi > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC 1/3] ASoC: dmaengine: Don't use runtime private data for dmaengine data
On Tue, Sep 04, 2012 at 04:26:28PM +0300, Peter Ujfalusi wrote: > Hi Takashi, > > On 09/04/2012 04:14 PM, Takashi Iwai wrote: > >> Ok, it might have been helpful in the conversion process, but for the final > >> patch it would be nice if you could replace > >> > >> struct snd_pcm_runtime *runtime = substream->runtime; > >> struct omap_runtime_data *prtd = runtime->private_data; > >> struct omap_pcm_dma_data *dma_data = prtd->dma_data; > >> with > >> struct omap_pcm_dma_data *dma_data = snd_dmaengine_pcm_get_data(substream); > >> > >> and in the hwparams callback use > >> > >> snd_dmaengine_pcm_set_data(substream, dma_data); > >> > >> and then drop patch 1 and 2 from the series. > > > > We discussed with Liam about the addition of new field in ALSA core, > > and concluded that a bit different approach, at least, more generic > > name is preferred, even if a new field is inevitably needed. > > > > So, eventually some change may happen in near future in ALSA core > > side, but still it'd be really helpful if the callers have been > > standardized beforehand with a helper function like above. > > If the omap-pcm dmaengine conversion works on all OMAP versions (from OMAP1 to > OMAP5) it is possible to avoid the additional field. > My main concern at the moment is if we will need two sets of drivers to > support OMAP1 and OMAP2/3/4/5. > In all case we use the same omap-mcbsp driver which would need deal with two > different type of ASoC platform driver (dmaengine and non-dmaengine). > I hope we get confirmation from Janusz soon regarding to OMAP1 with dmaengine > so we can plan on how to move forward. As the target for the DMA engine work is to kill off the OMAP private DMA APIs, then if OMAP1 doesn't work with the OMAP DMA engine driver, that's what needs fixing, rather than having two ASoC platform drivers. Note that time is ticking for the removal of the OMAP private DMA APIs (see feature-removal-schedule.txt) and it has to happen so that the next stage of the OMAP DMA engine conversion can happen - that is, to make the OMAP DMA engine support be a proper driver rather than just a DMA Engine to OMAP private DMA API conversion shim. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] drm: support for rotated scanout
From: Rob Clark
For drivers that can support rotated scanout, the extra parameter
checking in drm-core, while nice, tends to get confused. To solve
this drivers can set the crtc or plane invert_dimensions field so
that the dimension checking takes into account the rotation that
the driver is performing.
v1: original
v2: remove invert_dimensions from plane, at Ville's suggestion.
Userspace can give rotated src coordinates, so invert_dimensions
is not required for planes.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 46 +---
include/drm/drm_crtc.h |5 +
2 files changed, 35 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 08a7aa7..901de9a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -377,6 +377,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc
*crtc,
crtc->dev = dev;
crtc->funcs = funcs;
+ crtc->invert_dimensions = false;
mutex_lock(&dev->mode_config.mutex);
@@ -1852,6 +1853,7 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
DRM_DEBUG_KMS("[CRTC:%d]\n", crtc->base.id);
if (crtc_req->mode_valid) {
+ int hdisplay, vdisplay;
/* If we have a mode we need a framebuffer. */
/* If we pass -1, set the mode with the currently bound fb */
if (crtc_req->fb_id == -1) {
@@ -1887,14 +1889,20 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
- if (mode->hdisplay > fb->width ||
- mode->vdisplay > fb->height ||
- crtc_req->x > fb->width - mode->hdisplay ||
- crtc_req->y > fb->height - mode->vdisplay) {
- DRM_DEBUG_KMS("Invalid CRTC viewport %ux%u+%u+%u for fb
size %ux%u.\n",
- mode->hdisplay, mode->vdisplay,
- crtc_req->x, crtc_req->y,
- fb->width, fb->height);
+ hdisplay = mode->hdisplay;
+ vdisplay = mode->vdisplay;
+
+ if (crtc->invert_dimensions)
+ swap(hdisplay, vdisplay);
+
+ if (hdisplay > fb->width ||
+ vdisplay > fb->height ||
+ crtc_req->x > fb->width - hdisplay ||
+ crtc_req->y > fb->height - vdisplay) {
+ DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport
%ux%u+%d+%d%s.\n",
+ fb->width, fb->height,
+ hdisplay, vdisplay, crtc_req->x,
crtc_req->y,
+ crtc->invert_dimensions ? " (inverted)" :
"");
ret = -ENOSPC;
goto out;
}
@@ -3489,6 +3497,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
struct drm_framebuffer *fb;
struct drm_pending_vblank_event *e = NULL;
unsigned long flags;
+ int hdisplay, vdisplay;
int ret = -EINVAL;
if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS ||
@@ -3518,14 +3527,19 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
goto out;
fb = obj_to_fb(obj);
- if (crtc->mode.hdisplay > fb->width ||
- crtc->mode.vdisplay > fb->height ||
- crtc->x > fb->width - crtc->mode.hdisplay ||
- crtc->y > fb->height - crtc->mode.vdisplay) {
- DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport
%ux%u+%d+%d.\n",
- fb->width, fb->height,
- crtc->mode.hdisplay, crtc->mode.vdisplay,
- crtc->x, crtc->y);
+ hdisplay = crtc->mode.hdisplay;
+ vdisplay = crtc->mode.vdisplay;
+
+ if (crtc->invert_dimensions)
+ swap(hdisplay, vdisplay);
+
+ if (hdisplay > fb->width ||
+ vdisplay > fb->height ||
+ crtc->x > fb->width - hdisplay ||
+ crtc->y > fb->height - vdisplay) {
+ DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport
%ux%u+%d+%d%s.\n",
+ fb->width, fb->height, hdisplay, vdisplay,
crtc->x, crtc->y,
+ crtc->invert_dimensions ? " (inverted)" : "");
ret = -ENOSPC;
goto out;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index ced3625..7ba9b39 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -358,6 +358,9 @@ struct drm_crtc_funcs {
* @enabled: is this CRTC enabled?
* @mode: current mode timings
* @hwmode: mode timings as programmed to hw regs
+ * @invert_dimensions: for purposes of error checking crtc vs fb sizes,
+ *invert the width/height of the crtc. This is used if the
[PATCH 2/2] drm/omap: invert dimensions on crtc when rotated
From: Rob Clark
If rotated 90 or 270, we need to invert the dimensions used by drm
core for calculating if the dimensions of an attached fb are correct.
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_crtc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/staging/omapdrm/omap_crtc.c
b/drivers/staging/omapdrm/omap_crtc.c
index 98a10bc..dade3de 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -195,6 +195,13 @@ static int omap_crtc_set_property(struct drm_crtc *crtc,
struct drm_property *property, uint64_t val)
{
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ struct omap_drm_private *priv = crtc->dev->dev_private;
+
+ if (property == priv->rotation_prop) {
+ crtc->invert_dimensions =
+ !!(val & ((1LL << DRM_ROTATE_90) | (1LL <<
DRM_ROTATE_270)));
+ }
+
return omap_plane_set_property(omap_crtc->plane, property, val);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] cbus/retu drivers to mainline
Hi Aaro, On Mon, Sep 03, 2012 at 11:23:21PM +0300, Aaro Koskinen wrote: > This patch set introduces drivers for CBUS access and Retu multifunction > chip found on Nokia Internet Tablets (770, N800, N810). It would be > nice get these patches applied as the functionality of these devices is > severely lacking without Retu. E.g. watchdog support is mandatory at > least on Nokia N800, you cannot currently run the mainline kernel for > longer than ~60 seconds (there is no way to disable the watchdog). > > Drivers originate from linux-omap cbus branch and have been cleaned > up/rewritten around i2c and MFD core. > > Patches have been tested on top of 3.6-rc4 with Nokia N800 (watchdog > feeding works, power off shuts down the device, power button triggers > IRQs and input events). > > Changes since the RFC version > (http://marc.info/?l=linux-omap&m=134618967116737&w=2): > - added DT support for getting i2c-cbus GPIO pins > - merged n8x0 board file changes into i2c-cbus patch > - corrected typo in Kconfig for MFD_RETU > - added power off functionality to retu-mfd > - added IRQ functionality to retu-mfd > - added power button key driver > - some cleanups > > Aaro Koskinen (4): > i2c: introduce i2c-cbus driver > mfd: introduce retu-mfd driver > watchdog: introduce retu_wdt driver > input: misc: introduce retu-pwrbutton I had a look to the patches 1, 2 and 4, so for them Reviewed-by: Andi Shyti -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] of: Modify c_can binding documentation
On 09/02/2012 10:54 PM, AnilKumar Ch wrote: > Modify c_can binding documentation according to recent review comments > on device tree data addition patches. > > Signed-off-by: AnilKumar Ch Reviewed-by: Stephen Warren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] watchdog: omap_wdt: convert to new watchdog core
Convert omap_wdt to new watchdog core. On OMAP boards, there are usually
multiple watchdogs. Since the new watchdog core supports multiple
watchdogs, all watchdog drivers used on OMAP should be converted.
The legacy watchdog device node is still created, so this should not
break existing users.
Signed-off-by: Aaro Koskinen
---
drivers/watchdog/Kconfig|1 +
drivers/watchdog/omap_wdt.c | 268 ++-
2 files changed, 115 insertions(+), 154 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 0526c7a..212b566 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -232,6 +232,7 @@ config EP93XX_WATCHDOG
config OMAP_WATCHDOG
tristate "OMAP Watchdog"
depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
+ select WATCHDOG_CORE
help
Support for TI OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430 watchdog.
Say 'Y'
here to enable the OMAP1610/OMAP1710/OMAP2420/OMAP3430/OMAP4430
watchdog timer.
diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index fceec4f..a0c23ac 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -31,18 +31,14 @@
#include
#include
#include
-#include
#include
-#include
#include
#include
#include
#include
#include
#include
-#include
#include
-#include
#include
#include
#include
@@ -50,24 +46,20 @@
#include "omap_wdt.h"
-static struct platform_device *omap_wdt_dev;
-
static unsigned timer_margin;
module_param(timer_margin, uint, 0);
MODULE_PARM_DESC(timer_margin, "initial watchdog timeout (in seconds)");
-static unsigned int wdt_trgr_pattern = 0x1234;
-static DEFINE_SPINLOCK(wdt_lock);
-
struct omap_wdt_dev {
void __iomem*base; /* physical */
struct device *dev;
- int omap_wdt_users;
+ boolomap_wdt_users;
struct resource *mem;
- struct miscdevice omap_wdt_miscdev;
+ int wdt_trgr_pattern;
+ struct mutexlock; /* to avoid races with PM */
};
-static void omap_wdt_ping(struct omap_wdt_dev *wdev)
+static void __omap_wdt_ping(struct omap_wdt_dev *wdev)
{
void __iomem*base = wdev->base;
@@ -75,8 +67,8 @@ static void omap_wdt_ping(struct omap_wdt_dev *wdev)
while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
cpu_relax();
- wdt_trgr_pattern = ~wdt_trgr_pattern;
- __raw_writel(wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
+ wdev->wdt_trgr_pattern = ~wdev->wdt_trgr_pattern;
+ __raw_writel(wdev->wdt_trgr_pattern, (base + OMAP_WATCHDOG_TGR));
/* wait for posted write to complete */
while ((__raw_readl(base + OMAP_WATCHDOG_WPS)) & 0x08)
@@ -84,7 +76,7 @@ static void omap_wdt_ping(struct omap_wdt_dev *wdev)
/* reloaded WCRR from WLDR */
}
-static void omap_wdt_enable(struct omap_wdt_dev *wdev)
+static void __omap_wdt_enable(struct omap_wdt_dev *wdev)
{
void __iomem *base = wdev->base;
@@ -98,7 +90,7 @@ static void omap_wdt_enable(struct omap_wdt_dev *wdev)
cpu_relax();
}
-static void omap_wdt_disable(struct omap_wdt_dev *wdev)
+static void __omap_wdt_disable(struct omap_wdt_dev *wdev)
{
void __iomem *base = wdev->base;
@@ -112,18 +104,10 @@ static void omap_wdt_disable(struct omap_wdt_dev *wdev)
cpu_relax();
}
-static void omap_wdt_adjust_timeout(unsigned new_timeout)
-{
- if (new_timeout < TIMER_MARGIN_MIN)
- new_timeout = TIMER_MARGIN_DEFAULT;
- if (new_timeout > TIMER_MARGIN_MAX)
- new_timeout = TIMER_MARGIN_MAX;
- timer_margin = new_timeout;
-}
-
-static void omap_wdt_set_timeout(struct omap_wdt_dev *wdev)
+static void __omap_wdt_set_timeout(struct omap_wdt_dev *wdev,
+ unsigned int timeout)
{
- u32 pre_margin = GET_WLDR_VAL(timer_margin);
+ u32 pre_margin = GET_WLDR_VAL(timeout);
void __iomem *base = wdev->base;
/* just count up at 32 KHz */
@@ -135,16 +119,14 @@ static void omap_wdt_set_timeout(struct omap_wdt_dev
*wdev)
cpu_relax();
}
-/*
- * Allow only one task to hold it open
- */
-static int omap_wdt_open(struct inode *inode, struct file *file)
+static int omap_wdt_start(struct watchdog_device *wdog)
{
- struct omap_wdt_dev *wdev = platform_get_drvdata(omap_wdt_dev);
+ struct omap_wdt_dev *wdev = watchdog_get_drvdata(wdog);
void __iomem *base = wdev->base;
- if (test_and_set_bit(1, (unsigned long *)&(wdev->omap_wdt_users)))
- return -EBUSY;
+ mutex_lock(&wdev->lock);
+
+ wdev->omap_wdt_users = true;
pm_runtime_get_sync(wdev->dev);
@@ -156,115 +138,79 @@ static int omap_wdt_open(struct inode *inode, struct
file *file)
while (__raw_readl(base + OMAP_WATCHDOG_WPS) & 0x01)
cpu_relax();
-
Re: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
Hi, On Tue, Sep 04, 2012 at 02:04:15PM +, B, Ravi wrote: > > On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote: > > > Hi, > > > > > > On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi wrote: > > > > Hi, > > > > > > > > On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: > > > >> From: Santhapuri, Damodar > > > >> > > > >> AM335x uses NOP transceiver driver and need to enable > > builtin PHY > > > >> by writing into usb_ctrl register available in system control > > > >> module register space. This is being added at musb glue driver > > > >> layer untill a separate system control module driver is > > available. > > > >> > > > >> Signed-off-by: Ajay Kumar Gupta > > > >> Signed-off-by: Santhapuri, Damodar > > > >> Signed-off-by: Ravi Babu > > > > > > > > Kishon, you were adding a real phy driver for OMAP's internal phy > > > > logic on one of your patches and I believe this will > > conflict with > > > > your changes, right ? > > > > > > Indeed. My final patch of that series removes some of the functions > > > from omap_phy_internal.c (which was taken care in the phy driver). > > > > > > > > How does this look to you ? Is this at least correct ? I > > suppose the > > > > correct way would be to actually have the system control module > > > > driver which we have been waiting, right ? > > > > > > Correct. I think once we have the system control module driver in > > > place, we'll have everything wrt control module register writes > > > implemented in correct way. > > > > So $SUBJECT will pretty much be thrown away once we have SCM > > driver, in that case it's best to wait a bit longer and apply > > this series once SCM driver is available and after your > > series too... you agree ? > > > > Felipe, I am sure there are patches in this series[0/13], which are > not dependent on this patch or control module, Can we pull in those > patches (all dual instances support patches)? So that I can re-work > and submit again? sure, will do, don't worry :-) -- balbi signature.asc Description: Digital signature
RE: [PATCH v9 01/13] usb: musb: dsps: add phy control logic to glue
> On Fri, Aug 31, 2012 at 06:51:04PM +0530, ABRAHAM, KISHON VIJAY wrote: > > Hi, > > > > On Fri, Aug 31, 2012 at 5:53 PM, Felipe Balbi wrote: > > > Hi, > > > > > > On Fri, Aug 31, 2012 at 04:39:47PM +0530, Ravi Babu wrote: > > >> From: Santhapuri, Damodar > > >> > > >> AM335x uses NOP transceiver driver and need to enable > builtin PHY > > >> by writing into usb_ctrl register available in system control > > >> module register space. This is being added at musb glue driver > > >> layer untill a separate system control module driver is > available. > > >> > > >> Signed-off-by: Ajay Kumar Gupta > > >> Signed-off-by: Santhapuri, Damodar > > >> Signed-off-by: Ravi Babu > > > > > > Kishon, you were adding a real phy driver for OMAP's internal phy > > > logic on one of your patches and I believe this will > conflict with > > > your changes, right ? > > > > Indeed. My final patch of that series removes some of the functions > > from omap_phy_internal.c (which was taken care in the phy driver). > > > > > > How does this look to you ? Is this at least correct ? I > suppose the > > > correct way would be to actually have the system control module > > > driver which we have been waiting, right ? > > > > Correct. I think once we have the system control module driver in > > place, we'll have everything wrt control module register writes > > implemented in correct way. > > So $SUBJECT will pretty much be thrown away once we have SCM > driver, in that case it's best to wait a bit longer and apply > this series once SCM driver is available and after your > series too... you agree ? > Felipe, I am sure there are patches in this series[0/13], which are not dependent on this patch or control module, Can we pull in those patches (all dual instances support patches)? So that I can re-work and submit again? > -- > balbi > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
>From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller > 25MHz
Signed-off-by: Hebbar, Gururaja
---
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 eb3e4d5... 00c658b... M arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 c3e96a2... 0e14834... M drivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 30 +++-
3 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
"supply-name" examples are "vmmc", "vmmc_aux" etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index eb3e4d5..00c658b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -127,6 +127,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 << 0)
#define HSMMC_HAS_UPDATED_RESET(1 << 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 << 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c3e96a2..0e14834 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -63,6 +63,7 @@
#define VS18 (1 << 26)
#define VS30 (1 << 25)
+#define HSS(1 << 21)
#define SDVS18 (0x5 << 9)
#define SDVS30 (0x6 << 9)
#define SDVS33 (0x7 << 9)
@@ -90,6 +91,7 @@
#define MSBS (1 << 5)
#define BCE(1 << 1)
#define FOUR_BIT (1 << 1)
+#define HSPE (1 << 2)
#define DDR(1 << 19)
#define DW8(1 << 5)
#define CC 0x1
@@ -490,6 +492,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = &host->mmc->ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host->mmc), "Set clock to %uHz\n", ios->clock);
@@ -497,7 +500,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host->base, SYSCTL);
regval = regval & ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) << 6) | (DTO << 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv << 6) | (DTO << 16);
OMAP_HSMMC_WRITE(host->base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host->base, SYSCTL,
OMAP_HSMMC_READ(host->base, SYSCTL) | ICE);
@@ -508,6 +512,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
&& time_before(jiffies, timeout))
cpu_relax();
+ /*
+* Enable High-Speed Support
+* Pre-Requisites
+* - Controller should support High-Speed-Enable Bit
+* - Controller should not be using DDR Mode
+* - Controller should advertise that it supports High Speed
+*in capabilities register
+* - MMC/SD clock coming out of controller > 25MHz
+*/
+ if ((mmc_slot(host).features & HSMMC_HAS_HSPE_SUPPORT) &&
+ (ios->timing != MMC_TIMING_UHS_DDR50) &&
+ ((OMAP_HSMMC_READ(host->base, CAPA) & HSS) == HSS)) {
+ regval = OMAP_HSMMC_READ(host->base, HCTL);
+ if (clkdiv && (clk_get_rate(host->fclk)/clkdiv) > 2500)
+
[PATCH] mmc: omap_hsmmc: Pass on the suspend failure to the PM core
From: Vaibhav Bedia In some cases mmc_suspend_host() is not able to claim the host and proceed with the suspend process. The core returns -EBUSY to the host controller driver. Unfortunately, the host controller driver does not pass on this information to the PM core and hence the system suspend process continues. In these cases the MMC core gets to an unexpected state during resume and multiple issues related to MMC crop up. 1. Host controller driver starts accessing the device registers before the clocks are enabled which leads to a prefetch abort. 2. A file copy thread which was launched before suspend gets stuck due to the host not being reclaimed during resume. To avoid such problems pass on the -EBUSY status to the PM core from the host controller driver. With this change, MMC core suspend might still fail but it does not end up making the system unusable. Suspend gets aborted and the user can try suspending the system again. Signed-off-by: Vaibhav Bedia Signed-off-by: Hebbar, Gururaja --- :100644 100644 9afdd20... c3e96a2... M drivers/mmc/host/omap_hsmmc.c drivers/mmc/host/omap_hsmmc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 9afdd20..c3e96a2 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2054,6 +2054,7 @@ static int omap_hsmmc_suspend(struct device *dev) if (ret) dev_dbg(dev, "Unmask interrupt failed\n"); } + ret = -EBUSY; goto err; } -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC 1/3] ASoC: dmaengine: Don't use runtime private data for dmaengine data
Hi Takashi, On 09/04/2012 04:14 PM, Takashi Iwai wrote: >> Ok, it might have been helpful in the conversion process, but for the final >> patch it would be nice if you could replace >> >> struct snd_pcm_runtime *runtime = substream->runtime; >> struct omap_runtime_data *prtd = runtime->private_data; >> struct omap_pcm_dma_data *dma_data = prtd->dma_data; >> with >> struct omap_pcm_dma_data *dma_data = snd_dmaengine_pcm_get_data(substream); >> >> and in the hwparams callback use >> >> snd_dmaengine_pcm_set_data(substream, dma_data); >> >> and then drop patch 1 and 2 from the series. > > We discussed with Liam about the addition of new field in ALSA core, > and concluded that a bit different approach, at least, more generic > name is preferred, even if a new field is inevitably needed. > > So, eventually some change may happen in near future in ALSA core > side, but still it'd be really helpful if the callers have been > standardized beforehand with a helper function like above. If the omap-pcm dmaengine conversion works on all OMAP versions (from OMAP1 to OMAP5) it is possible to avoid the additional field. My main concern at the moment is if we will need two sets of drivers to support OMAP1 and OMAP2/3/4/5. In all case we use the same omap-mcbsp driver which would need deal with two different type of ASoC platform driver (dmaengine and non-dmaengine). I hope we get confirmation from Janusz soon regarding to OMAP1 with dmaengine so we can plan on how to move forward. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [RFC 1/3] ASoC: dmaengine: Don't use runtime private data for dmaengine data
At Mon, 03 Sep 2012 22:59:54 +0200,
Lars-Peter Clausen wrote:
>
> On 09/03/2012 10:43 PM, Russell King - ARM Linux wrote:
> > On Mon, Sep 03, 2012 at 10:25:49PM +0200, Lars-Peter Clausen wrote:
> >> On 09/03/2012 06:59 PM, Liam Girdwood wrote:
> >>> Use a dedicated member to store dmaengine data so that drivers can
> >>> use private data for their own purposes.
> >>>
> >>
> >> The idea was that we'll eventually get to a point where we won't need
> >> private
> >> data for the drivers using the generic dmaengine code. But for the
> >> transitional
> >> period there is snd_dmaengine_pcm_{set,get}_data which allows to attach
> >> driver
> >> private data to the dmaengine pcm. For an example see how the other users
> >> of
> >> dmaengine pcm handle this.
> >
> > That's fine if you are writing new drivers from scatch, or know the
> > driver you're converting inside-out. Neither applies here (I've
> > struggled to do anything with the OMAP audio stuff for many many
> > reasons.)
> >
> > I rather wish that people who did know the OMAP ASoC driver had stepped
> > up to this conversion, but alas they haven't.
> >
> > In any case, if you want people to use the this soc-dmaengine helper
> > then you have to make the conversion to it simple, and requiring
> > everyone to totally restructure their drivers to use it does not make
> > that process simple.
> >
> > What you have here is the result of several transformations to the
> > driver, which would _not_ have been possible without this first patch
> > from Liam.
>
> Ok, it might have been helpful in the conversion process, but for the final
> patch it would be nice if you could replace
>
> struct snd_pcm_runtime *runtime = substream->runtime;
> struct omap_runtime_data *prtd = runtime->private_data;
> struct omap_pcm_dma_data *dma_data = prtd->dma_data;
> with
> struct omap_pcm_dma_data *dma_data = snd_dmaengine_pcm_get_data(substream);
>
> and in the hwparams callback use
>
> snd_dmaengine_pcm_set_data(substream, dma_data);
>
> and then drop patch 1 and 2 from the series.
We discussed with Liam about the addition of new field in ALSA core,
and concluded that a bit different approach, at least, more generic
name is preferred, even if a new field is inevitably needed.
So, eventually some change may happen in near future in ALSA core
side, but still it'd be really helpful if the callers have been
standardized beforehand with a helper function like above.
thanks,
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC update 2/2] ASoC: omap-pcm: Do not check DMA sync_mode
OMAP dmaengine now supports element mode also in cyclic DMA so we do not
need to block non PACKET modes.
Signed-off-by: Peter Ujfalusi
---
sound/soc/omap/omap-pcm.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 50ae048..0f88db3 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -32,7 +32,6 @@
#include
#include
-#include /* needed just for OMAP_DMA_SYNC_PACKET */
#include "omap-pcm.h"
static const struct snd_pcm_hardware omap_pcm_hardware = {
@@ -83,15 +82,6 @@ static int omap_pcm_hw_params(struct snd_pcm_substream
*substream,
return 0;
prtd->dma_data = dma_data;
- /*
-* This is the only parameter we don't handle with DMA
-* engine - so we insist on OMAP_DMA_SYNC_PACKET here.
-*/
- if (dma_data->sync_mode != OMAP_DMA_SYNC_PACKET) {
- pr_warn("ALSA: omap-dma: DMA using non-packet mode?\n");
- return -EINVAL;
- }
-
req = dma_data->dma_req;
err = snd_dmaengine_pcm_open(substream, omap_dma_filter_fn, &req);
if (err)
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC update 1/2] dmaengine: omap: Support for element mode in cyclic DMA
When src_maxburst/dst_maxburst is set to 0 by the users of cyclic DMA (mostly audio) indicates that we should configure the omap DMA to element sync mode instead of packet mode. Signed-off-by: Peter Ujfalusi --- drivers/dma/omap-dma.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c index ae05618..b77a40d 100644 --- a/drivers/dma/omap-dma.c +++ b/drivers/dma/omap-dma.c @@ -413,7 +413,10 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic( d->dev_addr = dev_addr; d->fi = burst; d->es = es; - d->sync_mode = OMAP_DMA_SYNC_PACKET; + if (burst) + d->sync_mode = OMAP_DMA_SYNC_PACKET; + else + d->sync_mode = OMAP_DMA_SYNC_ELEMENT; d->sync_type = sync_type; d->periph_port = OMAP_DMA_PORT_MPUI; d->sg[0].addr = buf_addr; -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC update 0/2] dmaengine/ASoC: omap: Enable element mode in cyclic DMA
Hi Russell, Enable the element mode (thus allowing mono playback and probably unblocking OMAP1, OMAP2420) in OMAP dmaengine and omap-pcm. Janusz: would it be possible for you to test Russell's series plus this on OMAP1 to make sure that we do not broke it? Russell: we should wait for Janusz to test this on OMAP1. Based on the feedback we can plan on how to proceed with the dmaengine for OMAP audio. Regards, Peter --- Peter Ujfalusi (2): dmaengine: omap: Support for element mode in cyclic DMA ASoC: omap-pcm: Do not check DMA sync_mode drivers/dma/omap-dma.c| 5 - sound/soc/omap/omap-pcm.c | 10 -- 2 files changed, 4 insertions(+), 11 deletions(-) -- 1.7.12 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/23] OMAP UART patches
Hi, On Fri, Aug 24, 2012 at 01:40:47PM +0300, Felipe Balbi wrote: > Forgot to Cc greg initially, my bad a gentle ping on this series so we don't miss it for v3.7 merge window. Greg, let me know if you need me to resend. cheers > On Thu, Aug 23, 2012 at 01:32:40PM +0300, Felipe Balbi wrote: > > Hi guys, > > > > here's v3 and hopefully final version of this series. A whole bunch of new > > patches added but the good thing is that now I had another engineer's help > > to > > test, so he's got his Tested-by in all patches. > > > > Changes since v2: > > . Added a bunch of new patches > > . Fixed a problem where we would always return IRQ_NONE even though we > > handled IRQ > > > > Changes since v1: > > . improved commit log on patch 9/13 (formerly 10/13) > > . removed patch 2/13 > > . added a new patch switching from spin_lock_irqsave() to spin_lock > > and > > spin_unlock_irqrestore to spin_unlock > > > > Alan, if you prefer in pull request form, here it is: > > > > The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92: > > > > Linux 3.6-rc2 (2012-08-16 14:51:24 -0700) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git uart > > > > for you to fetch changes up to a29230f14d8466c9b8c25171715378bf52189453: > > > > serial: omap: enable RX and TX FIFO usage (2012-08-23 09:25:16 +0300) > > > > > > Felipe Balbi (20): > > serial: omap: define and use to_uart_omap_port() > > serial: omap: define helpers for pdata function pointers > > serial: omap: don't access the platform_device > > serial: omap: drop DMA support > > serial: add OMAP-specific defines > > serial: omap: simplify IRQ handling > > serial: omap: refactor receive_chars() into rdi/rlsi handlers > > serial: omap: move THRE check to transmit_chars() > > serial: omap: stick to put_autosuspend > > serial: omap: set dev->drvdata before enabling pm_runtime > > serial: omap: drop unnecessary check from remove > > serial: omap: make sure to suspend device before remove > > serial: omap: don't save IRQ flags on hardirq > > serial: omap: optimization with section annotations > > serial: omap: drop "inline" from IRQ handler prototype > > serial: omap: implement set_wake > > serial: omap: make sure to put() on poll_get_char > > serial: omap: remove unnecessary header and add a missing one > > serial: omap: move uart_omap_port definition to C file > > serial: omap: enable RX and TX FIFO usage > > > > Ruchika Kharwar (2): > > serial: omap: fix sequence of pm_runtime_* calls. > > serial: omap: unlock the port lock > > > > Vikram Pandita (1): > > serial: omap: fix software flow control > > > > arch/arm/mach-omap2/serial.c | 15 +- > > arch/arm/plat-omap/include/plat/omap-serial.h | 47 +- > > drivers/tty/serial/omap-serial.c | 808 > > ++ > > include/linux/serial_reg.h| 4 + > > 4 files changed, 330 insertions(+), 544 deletions(-) > > > > -- > > 1.7.12.rc3 > > > > -- > balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/4] i2c: introduce i2c-cbus driver
Hi, On Tue, Sep 04, 2012 at 12:31:42PM +0300, Aaro Koskinen wrote: > On Tue, Sep 04, 2012 at 12:05:07PM +0300, Felipe Balbi wrote: > > > + * CBUS I2C driver for Nokia Internet Tablets. > > [...] > > > this version misses the entire IRQ handling we already had on linux-omap > > tree, so it's quite a regression. > > There's no interrupts used in plain CBUS protocol/communication I think? > > But Retu MFD supports the GPIO IRQ. I added the code for this set. And > the power button driver (patch 4/4) is using this functionality: > > # cat /proc/interrupts > [...] > 204: 29 GPIO retu-mfd > 224: 29 RETU retu-pwrbutton oops, indeed. My bad. I looked at the wrong patch. Nevermind, this series looks good to me. FWIW: Acked-by: Felipe Balbi (for entire series) -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: OMAP4: Cleanup and move GIC outside of the OCP node
On 09/04/2012 07:47 AM, Shilimkar, Santosh wrote: > On Mon, Sep 3, 2012 at 9:20 AM, Benoit Cousson wrote: >> Remove a useless comment and move GIC controller outside >> of the OCP node since it does use the MPU internal bus and >> not the OCP. >> This will not change the functionality but will reflect the >> reality more accurately. >> >> Signed-off-by: Benoit Cousson >> --- >> > Make sense. > Acked-by: Santosh Shilimkar > Thanks Santosh, I'll update the patch with your ack are will add it after your series for Tony to pull. Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC
Hi Vaibhav,
On 09/04/2012 05:42 AM, Vaibhav Hiremath wrote:
> On 9/3/2012 8:16 PM, Benoit Cousson wrote:
>> Hi Peter,
>>
>> The overall series looks good to me, but I do have a couple of comments.
>>
>> On 08/29/2012 03:31 PM, Peter Ujfalusi wrote:
>>> The McBSP IP within OMAP2420 and 2430 is different we need to create
>>> separate
>>> dtsi files for them.
>>>
>>> Signed-off-by: Peter Ujfalusi
>>> ---
>>> arch/arm/boot/dts/omap2420.dtsi | 39 ++
>>> arch/arm/boot/dts/omap2430.dtsi | 83
>>> +++
>>> 2 files changed, 122 insertions(+), 0 deletions(-)
>>> create mode 100644 arch/arm/boot/dts/omap2420.dtsi
>>> create mode 100644 arch/arm/boot/dts/omap2430.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/omap2420.dtsi
>>> b/arch/arm/boot/dts/omap2420.dtsi
>>> new file mode 100644
>>> index 000..f375c68
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/omap2420.dtsi
>>> @@ -0,0 +1,39 @@
>>> +/*
>>> + * Device Tree Source for OMAP2420 SoC
>>> + *
>>> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
>>
>> Nit: 2012
>>
>>> + *
>>> + * This file is licensed under the terms of the GNU General Public License
>>> + * version 2. This program is licensed "as is" without any warranty of any
>>> + * kind, whether express or implied.
>>> + */
>>> +
>>> +/include/ "omap2.dtsi"
>>> +
>>> +/ {
>>> + compatible = "ti,omap2420", "ti,omap2";
>>> +
>>> + ocp {
>>> + mcbsp1: mcbsp@48074000 {
>>> + compatible = "ti,omap2420-mcbsp";
>>> + reg = <0x48074000 0xff>;
>>> + reg-names = "mpu";
>>> + interrupts = <0 59 0x4>, /* TX interrupt */
>>> +<0 60 0x4>; /* RX interrupt */
>>
>> That one is not correct because it does comply with the interrupt
>> controller specifier that require only one cell:
>>
>> intc: interrupt-controller@4820 {
>> compatible = "ti,omap2-intc";
>> interrupt-controller;
>> #interrupt-cells = <1>;
>> ...
>>
>> The one you are using is for GIC IRQ controller.
>> It works probably because we are using hwmod so far :-)
>>
>
> I think now we should kill the resource overwrite path, and should
> respect and use resources passed from DT.
>
> Benoit,
> Did you get a chance to validate patch submitted towards this??
Not yet, but we discussed that with Peter and since he does have these
patches for DT, he'll be able to test your series with the McBSP changes.
I still want to update a couple of DTS to test that on some other IPs.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] i2c: introduce i2c-cbus driver
On Tue, Sep 04, 2012 at 12:05:07PM +0300, Felipe Balbi wrote: > > + * CBUS I2C driver for Nokia Internet Tablets. [...] > this version misses the entire IRQ handling we already had on linux-omap > tree, so it's quite a regression. There's no interrupts used in plain CBUS protocol/communication I think? But Retu MFD supports the GPIO IRQ. I added the code for this set. And the power button driver (patch 4/4) is using this functionality: # cat /proc/interrupts [...] 204: 29 GPIO retu-mfd 224: 29 RETU retu-pwrbutton A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] i2c: introduce i2c-cbus driver
Hi,
On Mon, Sep 03, 2012 at 11:23:22PM +0300, Aaro Koskinen wrote:
> diff --git a/drivers/i2c/busses/i2c-cbus.c b/drivers/i2c/busses/i2c-cbus.c
> new file mode 100644
> index 000..bacf2a9
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-cbus.c
> @@ -0,0 +1,369 @@
> +/*
> + * CBUS I2C driver for Nokia Internet Tablets.
> + *
> + * Copyright (C) 2004-2010 Nokia Corporation
> + *
> + * Based on code written by Juha Yrjölä, David Weinehall, Mikko Ylinen and
> + * Felipe Balbi. Converted to I2C driver by Aaro Koskinen.
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License. See the file "COPYING" in the main directory of this
> + * archive for more details.
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct cbus_host {
> + /* host lock */
> + spinlock_t lock;
> +
> + struct device *dev;
> +
> + int clk_gpio;
> + int dat_gpio;
> + int sel_gpio;
> +};
> +
> +/**
> + * cbus_send_bit - sends one bit over the bus
> + * @host: the host we're using
> + * @bit: one bit of information to send
> + * @input: whether to set data pin as input after sending
> + */
> +static int cbus_send_bit(struct cbus_host *host, unsigned bit,
> + unsigned input)
> +{
> + int ret = 0;
> +
> + gpio_set_value(host->dat_gpio, bit ? 1 : 0);
> + gpio_set_value(host->clk_gpio, 1);
> +
> + /* The data bit is read on the rising edge of CLK */
> + if (input)
> + ret = gpio_direction_input(host->dat_gpio);
> +
> + gpio_set_value(host->clk_gpio, 0);
> +
> + return ret;
> +}
> +
> +/**
> + * cbus_send_data - sends @len amount of data over the bus
> + * @host: the host we're using
> + * @data: the data to send
> + * @len: size of the transfer
> + * @input: whether to set data pin as input after sending
> + */
> +static int cbus_send_data(struct cbus_host *host, unsigned data, unsigned
> len,
> + unsigned input)
> +{
> + int ret = 0;
> + int i;
> +
> + for (i = len; i > 0; i--) {
> + ret = cbus_send_bit(host, data & (1 << (i - 1)),
> + input && (i == 1));
> + if (ret < 0)
> + goto out;
> + }
> +
> +out:
> + return ret;
> +}
> +
> +/**
> + * cbus_receive_bit - receives one bit from the bus
> + * @host: the host we're using
> + */
> +static int cbus_receive_bit(struct cbus_host *host)
> +{
> + int ret;
> +
> + gpio_set_value(host->clk_gpio, 1);
> + ret = gpio_get_value(host->dat_gpio);
> + if (ret < 0)
> + goto out;
> + gpio_set_value(host->clk_gpio, 0);
> +
> +out:
> + return ret;
> +}
> +
> +/**
> + * cbus_receive_word - receives 16-bit word from the bus
> + * @host: the host we're using
> + */
> +static int cbus_receive_word(struct cbus_host *host)
> +{
> + int ret = 0;
> + int i;
> +
> + for (i = 16; i > 0; i--) {
> + int bit = cbus_receive_bit(host);
> +
> + if (bit < 0)
> + goto out;
> +
> + if (bit)
> + ret |= 1 << (i - 1);
> + }
> +
> +out:
> + return ret;
> +}
> +
> +/**
> + * cbus_transfer - transfers data over the bus
> + * @host: the host we're using
> + * @rw: read/write flag
> + * @dev: device address
> + * @reg: register address
> + * @data: if @rw == I2C_SBUS_WRITE data to send otherwise 0
> + */
> +static int cbus_transfer(struct cbus_host *host, char rw, unsigned dev,
> + unsigned reg, unsigned data)
> +{
> + unsigned long flags;
> + int ret;
> +
> + /* We don't want interrupts disturbing our transfer */
> + spin_lock_irqsave(&host->lock, flags);
> +
> + /* Reset state and start of transfer, SEL stays down during transfer */
> + gpio_set_value(host->sel_gpio, 0);
> +
> + /* Set the DAT pin to output */
> + gpio_direction_output(host->dat_gpio, 1);
> +
> + /* Send the device address */
> + ret = cbus_send_data(host, dev, 3, 0);
> + if (ret < 0) {
> + dev_dbg(host->dev, "failed sending device addr\n");
> + goto out;
> + }
> +
> + /* Send the rw flag */
> + ret = cbus_send_bit(host, rw == I2C_SMBUS_READ, 0);
> + if (ret < 0) {
> + dev_dbg(host->dev, "failed sending read/write flag\n");
> + goto out;
> + }
> +
> + /* Send the device address */
> + ret = cbus_send_data(host, reg, 5, rw == I2C_SMBUS_READ);
> + if (ret < 0) {
> + dev_dbg(host->dev, "failed sending register addr\n");
> +
RE: [PATCH 7/9] ARM: OMAP2+: Prepare for irqs.h removal
Hi Tony,
On Fri, Aug 31, 2012 at 06:22:37, Tony Lindgren wrote:
> As the interrupts should only be defined in the platform_data, and
> eventually coming from device tree, there's no need to define them
> in header files.
>
> Let's remove the hardcoded references to irqs.h and fix up the includes
> so we don't rely on headers included in irqs.h. While at it, sort
> the includes the standard way.
> arch/arm/mach-omap2/gpmc.c | 11 +---
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> /* GPMC register offsets */
> #define GPMC_REVISION0x00
> #define GPMC_SYSCONFIG 0x10
> @@ -846,16 +849,16 @@ static int __init gpmc_init(void)
> l = OMAP2420_GPMC_BASE;
> else
> l = OMAP34XX_GPMC_BASE;
> - gpmc_irq = INT_34XX_GPMC_IRQ;
> + gpmc_irq = 20;
> } else if (cpu_is_omap34xx()) {
> ck = "gpmc_fck";
> l = OMAP34XX_GPMC_BASE;
> - gpmc_irq = INT_34XX_GPMC_IRQ;
> + gpmc_irq = 20;
> } else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
> /* Base address and irq number are same for OMAP4/5 */
> ck = "gpmc_ck";
> l = OMAP44XX_GPMC_BASE;
> - gpmc_irq = OMAP44XX_IRQ_GPMC;
> + gpmc_irq = 20 + OMAP44XX_IRQ_GIC_START;
I have a suggestion to avoid above hardcoded patching on gpmc.c.
With driver conversion series it again would have to be patched.
I have made a basic gpmc driver conversion, which is expected to
be non-controversial. This was done over your devel-gpmc branch.
It is working fine, has only 3 patches
1. Add hwmod entry
2. Adapt to hwmod
3. Basic driver conversion
Here the basic driver gets resources and clk in driver probe
using con-id "fck", it has no platform data as of now
It is available
@git://gitorious.org/x0148406-public/linux-kernel.git gpmc-simple-drv
Originally this was made on top of my series,
"OMAP-GPMC: generic time calc, prepare for driver"
It was modified so that it can be applied to your devel-gpmc branch.
*I am not sending the patches now to avoid confusion by way of having
too many patch series*
In case you like this, let me know, I will post.
As I am proceeding with Paul's suggestion on hwmod reset,
I hope Paul can take the first one.
Regards
Afzal
RE: [PATCH 1/4] can: c_can: Adopt pinctrl support
On Tue, Sep 04, 2012 at 13:12:17, Marc Kleine-Budde wrote: > On 09/04/2012 08:14 AM, AnilKumar, Chimata wrote: > > Hi Marc, > > > > On Tue, Sep 04, 2012 at 02:12:04, Marc Kleine-Budde wrote: > >> On 09/03/2012 01:52 PM, AnilKumar Ch wrote: > >>> Adopt pinctrl support to c_can driver based on c_can device > >>> pointer, pinctrl driver configure SoC pins to d_can mode > >>> according to definitions provided in .dts file. > >>> > >>> In device specific device tree file 'pinctrl-names = "default";' > >>> and 'pinctrl-0 = <&d_can1_pins>;' needs to add to configure pins > >>> from c_can driver. d_can1_pins node contains the pinmux/config > >>> details of d_can L/H pins. > >> > >> Looks good, is the pinctrl property documented in the dt bindings already? > >> > > > > Yes, its here Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt > > Sorry, I meant not the generic pinctrl, but the c_can/d_can bindings > documentation (Documentation/devicetree/bindings/net/can/). > No, I have not included because those are pinctrl driver specific bindings. If the SoC supports pinmux/conf feature then those should be added according to pinctrl driver. If the SoC is not supported pinmux/config then this configuration is not required. Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] can: c_can: Adopt pinctrl support
On 09/04/2012 08:14 AM, AnilKumar, Chimata wrote: > Hi Marc, > > On Tue, Sep 04, 2012 at 02:12:04, Marc Kleine-Budde wrote: >> On 09/03/2012 01:52 PM, AnilKumar Ch wrote: >>> Adopt pinctrl support to c_can driver based on c_can device >>> pointer, pinctrl driver configure SoC pins to d_can mode >>> according to definitions provided in .dts file. >>> >>> In device specific device tree file 'pinctrl-names = "default";' >>> and 'pinctrl-0 = <&d_can1_pins>;' needs to add to configure pins >>> from c_can driver. d_can1_pins node contains the pinmux/config >>> details of d_can L/H pins. >> >> Looks good, is the pinctrl property documented in the dt bindings already? >> > > Yes, its here Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt Sorry, I meant not the generic pinctrl, but the c_can/d_can bindings documentation (Documentation/devicetree/bindings/net/can/). Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/4] can: c_can: Add d_can raminit support
On 09/04/2012 09:36 AM, Vaibhav Hiremath wrote:
>
>
> On 9/4/2012 11:44 AM, AnilKumar, Chimata wrote:
>> Hi Marc,
>>
>> On Tue, Sep 04, 2012 at 02:09:15, Marc Kleine-Budde wrote:
>>> On 09/03/2012 01:52 PM, AnilKumar Ch wrote:
Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM.
DCAN RAM holds all the message objects during transmission or
receiving of data. This initialization/de-initialization should
be done in synchronous with D_CAN clock.
Signed-off-by: AnilKumar Ch
---
drivers/net/can/c_can/c_can.c | 13
drivers/net/can/c_can/c_can.h |2 ++
drivers/net/can/c_can/c_can_platform.c | 10 +
include/linux/can/platform/c_can.h | 36
4 files changed, 61 insertions(+)
create mode 100644 include/linux/can/platform/c_can.h
diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index aa6c5eb..c175410 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -214,6 +214,12 @@ static inline void c_can_pm_runtime_put_sync(const
struct c_can_priv *priv)
pm_runtime_put_sync(priv->device);
}
+static inline void c_can_reset_ram(const struct c_can_priv *priv, bool
enable)
+{
+ if (priv->ram_init)
+ priv->ram_init(priv->instance, enable);
+}
+
static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
{
return (priv->tx_next & C_CAN_NEXT_MSG_OBJ_MASK) +
@@ -1071,6 +1077,8 @@ static int c_can_open(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
c_can_pm_runtime_get_sync(priv);
+ /* Initialize DCAN RAM */
+ c_can_reset_ram(priv, true);
/* open the can device */
err = open_candev(dev);
@@ -1099,6 +1107,8 @@ static int c_can_open(struct net_device *dev)
exit_irq_fail:
close_candev(dev);
exit_open_fail:
+ /* De-Initialize DCAN RAM */
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return err;
}
@@ -1112,6 +1122,9 @@ static int c_can_close(struct net_device *dev)
c_can_stop(dev);
free_irq(dev->irq, dev);
close_candev(dev);
+
+ /* De-Initialize DCAN RAM */
+ c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return 0;
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 1437a6d..5f6339c 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -166,6 +166,8 @@ struct c_can_priv {
unsigned int tx_echo;
void *priv; /* for board-specific data */
u16 irqstatus;
+ unsigned int instance;
+ void (*ram_init) (unsigned int instance, bool enable);
};
struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c
b/drivers/net/can/c_can/c_can_platform.c
index c351975..c6963b2 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -98,6 +99,7 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
struct net_device *dev;
struct c_can_priv *priv;
const struct of_device_id *match;
+ struct c_can_platform_data *pdata = NULL;
const struct platform_device_id *id;
struct pinctrl *pinctrl;
struct resource *mem;
@@ -179,6 +181,14 @@ static int __devinit c_can_plat_probe(struct
platform_device *pdev)
priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
priv->read_reg = c_can_plat_read_reg_aligned_to_16bit;
priv->write_reg = c_can_plat_write_reg_aligned_to_16bit;
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ dev_err(&pdev->dev, "d_can platform data missing\n");
+ ret = -EINVAL;
>>>
>>> Is the ram_init mandatory on all d_can? There might be non omap d_can users.
>>
>> As per AM335x specifications d_can module should have ram_init.
>> In that case it's better to print warning and break the switch.
>>
>
> As far as I know, "ram_init" is part of IP spec, how it is controlled
> does varies based on SoC integration.
Thanks for your insight. Leave the code as it is. If there is another
d_can user we know more and will improve/fix the code :)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pen
Re: [PATCH 2/4] can: c_can: Add d_can raminit support
On 9/4/2012 11:44 AM, AnilKumar, Chimata wrote:
> Hi Marc,
>
> On Tue, Sep 04, 2012 at 02:09:15, Marc Kleine-Budde wrote:
>> On 09/03/2012 01:52 PM, AnilKumar Ch wrote:
>>> Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM.
>>> DCAN RAM holds all the message objects during transmission or
>>> receiving of data. This initialization/de-initialization should
>>> be done in synchronous with D_CAN clock.
>>>
>>> Signed-off-by: AnilKumar Ch
>>> ---
>>> drivers/net/can/c_can/c_can.c | 13
>>> drivers/net/can/c_can/c_can.h |2 ++
>>> drivers/net/can/c_can/c_can_platform.c | 10 +
>>> include/linux/can/platform/c_can.h | 36
>>>
>>> 4 files changed, 61 insertions(+)
>>> create mode 100644 include/linux/can/platform/c_can.h
>>>
>>> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
>>> index aa6c5eb..c175410 100644
>>> --- a/drivers/net/can/c_can/c_can.c
>>> +++ b/drivers/net/can/c_can/c_can.c
>>> @@ -214,6 +214,12 @@ static inline void c_can_pm_runtime_put_sync(const
>>> struct c_can_priv *priv)
>>> pm_runtime_put_sync(priv->device);
>>> }
>>>
>>> +static inline void c_can_reset_ram(const struct c_can_priv *priv, bool
>>> enable)
>>> +{
>>> + if (priv->ram_init)
>>> + priv->ram_init(priv->instance, enable);
>>> +}
>>> +
>>> static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
>>> {
>>> return (priv->tx_next & C_CAN_NEXT_MSG_OBJ_MASK) +
>>> @@ -1071,6 +1077,8 @@ static int c_can_open(struct net_device *dev)
>>> struct c_can_priv *priv = netdev_priv(dev);
>>>
>>> c_can_pm_runtime_get_sync(priv);
>>> + /* Initialize DCAN RAM */
>>> + c_can_reset_ram(priv, true);
>>>
>>> /* open the can device */
>>> err = open_candev(dev);
>>> @@ -1099,6 +1107,8 @@ static int c_can_open(struct net_device *dev)
>>> exit_irq_fail:
>>> close_candev(dev);
>>> exit_open_fail:
>>> + /* De-Initialize DCAN RAM */
>>> + c_can_reset_ram(priv, false);
>>> c_can_pm_runtime_put_sync(priv);
>>> return err;
>>> }
>>> @@ -1112,6 +1122,9 @@ static int c_can_close(struct net_device *dev)
>>> c_can_stop(dev);
>>> free_irq(dev->irq, dev);
>>> close_candev(dev);
>>> +
>>> + /* De-Initialize DCAN RAM */
>>> + c_can_reset_ram(priv, false);
>>> c_can_pm_runtime_put_sync(priv);
>>>
>>> return 0;
>>> diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
>>> index 1437a6d..5f6339c 100644
>>> --- a/drivers/net/can/c_can/c_can.h
>>> +++ b/drivers/net/can/c_can/c_can.h
>>> @@ -166,6 +166,8 @@ struct c_can_priv {
>>> unsigned int tx_echo;
>>> void *priv; /* for board-specific data */
>>> u16 irqstatus;
>>> + unsigned int instance;
>>> + void (*ram_init) (unsigned int instance, bool enable);
>>> };
>>>
>>> struct net_device *alloc_c_can_dev(void);
>>> diff --git a/drivers/net/can/c_can/c_can_platform.c
>>> b/drivers/net/can/c_can/c_can_platform.c
>>> index c351975..c6963b2 100644
>>> --- a/drivers/net/can/c_can/c_can_platform.c
>>> +++ b/drivers/net/can/c_can/c_can_platform.c
>>> @@ -34,6 +34,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>>
>>> @@ -98,6 +99,7 @@ static int __devinit c_can_plat_probe(struct
>>> platform_device *pdev)
>>> struct net_device *dev;
>>> struct c_can_priv *priv;
>>> const struct of_device_id *match;
>>> + struct c_can_platform_data *pdata = NULL;
>>> const struct platform_device_id *id;
>>> struct pinctrl *pinctrl;
>>> struct resource *mem;
>>> @@ -179,6 +181,14 @@ static int __devinit c_can_plat_probe(struct
>>> platform_device *pdev)
>>> priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
>>> priv->read_reg = c_can_plat_read_reg_aligned_to_16bit;
>>> priv->write_reg = c_can_plat_write_reg_aligned_to_16bit;
>>> + pdata = pdev->dev.platform_data;
>>> + if (!pdata) {
>>> + dev_err(&pdev->dev, "d_can platform data missing\n");
>>> + ret = -EINVAL;
>>
>> Is the ram_init mandatory on all d_can? There might be non omap d_can users.
>
> As per AM335x specifications d_can module should have ram_init.
> In that case it's better to print warning and break the switch.
>
As far as I know, "ram_init" is part of IP spec, how it is controlled
does varies based on SoC integration.
Thanks,
Vaibhav
>>
>> Marc
>>
>>> + goto exit_free_device;
>>> + }
>>> + priv->ram_init = pdata->ram_init;
>>> + priv->instance = pdata->instance;
>>> break;
>>> default:
>>> ret = -EINVAL;
>>> diff --git a/include/linux/can/platform/c_can.h
>>> b/include/linux/can/platform/c_can.h
>>> new file mode 100644
>>> index 000..84b27d2
>>> --- /dev/null
>>> +++ b/include/linux/can/platform/c_can.h
>>> @@ -0,0 +1,36 @@
>>> +/*
>>> + * C_CAN
Re: [PATCH 3/4] ARM: AM33XX: board-generic: Add of_dev_auxdata to pass d_can raminit
On 09/04/2012 08:26 AM, AnilKumar, Chimata wrote:
> On Tue, Sep 04, 2012 at 01:41:14, Marc Kleine-Budde wrote:
>> On 09/03/2012 01:52 PM, AnilKumar Ch wrote:
>>> Add of_dev_auxdata to pass d_can raminit callback APIs to initialize
>>> d_can RAM. D_CAN RAM initialization bits are present in CONTROL module
>>> address space, which can be accessed by platform specific code. So
>>> callback functions are added to serve this purpose, this can done by
>>> using of_dev_auxdata.
>>>
>>> Callback API is added to of_dev_auxdata with different instance numbers
>>> for two instances of D_CAN IP. These callback functions are used to
>>> enable/disable D_CAN RAM from CAN driver.
>>>
>>> Signed-off-by: AnilKumar Ch
>>
>> This will be a more complicated. This patch will go over the arm tree,
>> but needs a header going via net.
>>
>
> Marc,
>
> I agree this is a bit complicated but this has to go along with
> this patch series otherwise build will break. If there are no
> changes required I will request Tony to ack it.
Yes, an Ack by Tony will help.
>
> Tony,
>
> If there are no changes required, could you please ack this patch
> so that this will go to linux-can tree.
Marc
>
> Thanks
> AnilKumar
>
>>
>>> ---
>>> arch/arm/mach-omap2/board-generic.c | 40
>>> ++-
>>> arch/arm/mach-omap2/control.h |4
>>> 2 files changed, 43 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/board-generic.c
>>> b/arch/arm/mach-omap2/board-generic.c
>>> index 6f93a20..b68e642 100644
>>> --- a/arch/arm/mach-omap2/board-generic.c
>>> +++ b/arch/arm/mach-omap2/board-generic.c
>>> @@ -15,6 +15,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include
>>> #include
>>> @@ -22,6 +23,8 @@
>>>
>>> #include
>>> #include "common.h"
>>> +#include "control.h"
>>> +#include "iomap.h"
>>> #include "common-board-devices.h"
>>>
>>> #if !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
>>> @@ -37,11 +40,46 @@ static struct of_device_id omap_dt_match_table[]
>>> __initdata = {
>>> { }
>>> };
>>>
>>> +void d_can_hw_raminit(unsigned int instance, bool enable)
>>> +{
>>> + u32 val;
>>> +
>>> + val = readl(AM33XX_CTRL_REGADDR(AM33XX_CONTROL_DCAN_RAMINIT));
>>> + if (enable) {
>>> + val &= ~AM33XX_DCAN_RAMINIT_START_MASK(instance);
>>> + val |= AM33XX_DCAN_RAMINIT_START_MASK(instance);
>>> + writel(val, AM33XX_CTRL_REGADDR(AM33XX_CONTROL_DCAN_RAMINIT));
>>> + } else {
>>> + val &= ~AM33XX_DCAN_RAMINIT_START_MASK(instance);
>>> + writel(val, AM33XX_CTRL_REGADDR(AM33XX_CONTROL_DCAN_RAMINIT));
>>> + }
>>> +}
>>> +
>>> +static struct c_can_platform_data d_can0_pdata = {
>>> + .ram_init = d_can_hw_raminit,
>>> + .instance = 0,
>>> +};
>>> +
>>> +static struct c_can_platform_data d_can1_pdata = {
>>> + .ram_init = d_can_hw_raminit,
>>> + .instance = 1,
>>> +};
>>> +
>>> +static const struct of_dev_auxdata am33xx_auxdata_lookup[] __initconst = {
>>> + OF_DEV_AUXDATA("bosch,d_can", 0x481cc000, NULL, &d_can0_pdata),
>>> + OF_DEV_AUXDATA("bosch,d_can", 0x481d, NULL, &d_can1_pdata),
>>> + { },
>>> +};
>>> +
>>> static void __init omap_generic_init(void)
>>> {
>>> omap_sdrc_init(NULL, NULL);
>>>
>>> - of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>>> + if (of_machine_is_compatible("ti,am33xx"))
>>> + of_platform_populate(NULL, omap_dt_match_table,
>>> + am33xx_auxdata_lookup, NULL);
>>> + else
>>> + of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>>> }
>>>
>>> #ifdef CONFIG_SOC_OMAP2420
>>> diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
>>> index b8cdc85..afd189b 100644
>>> --- a/arch/arm/mach-omap2/control.h
>>> +++ b/arch/arm/mach-omap2/control.h
>>> @@ -356,6 +356,10 @@
>>> #define AM33XX_CONTROL_STATUS_SYSBOOT1_SHIFT 22
>>> #define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3 << 22)
>>>
>>> +/* AM33XX DCAN bitfields */
>>> +#define AM33XX_CONTROL_DCAN_RAMINIT0x644
>>> +#define AM33XX_DCAN_RAMINIT_START_MASK(i) (1 << (i))
>>> +
>>> /* CONTROL OMAP STATUS register to identify OMAP3 features */
>>> #define OMAP3_CONTROL_OMAP_STATUS 0x044c
>>>
>>>
>>
>>
>> --
>> Pengutronix e.K. | Marc Kleine-Budde |
>> Industrial Linux Solutions| Phone: +49-231-2826-924 |
>> Vertretung West/Dortmund | Fax: +49-5121-206917- |
>> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
>>
>>
>
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 3/3] gpio-twl4030: updates the bindings for new dt properties
On Mon, Sep 3, 2012 at 3:54 PM, Florian Vaussard wrote: > Add the new properties to the documentation of bindings. > > Signed-off-by: Florian Vaussard Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] gpio-twl4030: new dt properties for BeagleBoard and omap3-EVM
On Mon, Sep 3, 2012 at 3:54 PM, Florian Vaussard wrote: > Add device tree properties for twl4030/gpio, according to the > platform data of corresponding boards. This enables the led > connected to LEDB output for both boards, as well as > pullups/pulldowns on GPIO for the BeagleBoard. > > Signed-off-by: Florian Vaussard Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] gpio-twl4030: get platform data from device tree
On Mon, Sep 3, 2012 at 3:54 PM, Florian Vaussard wrote: > Adds a number of missing properties to the device tree of > twl4030/gpio: > - "ti,use-leds" -> .use_leds > - "ti,debounce" -> .debounce > - "ti,mmc-cd"-> .mmc_cd > - "ti,pullups" -> .pullups > - "ti,pulldowns" -> .pulldowns > > Signed-off-by: Florian Vaussard Acked-by: Linus Walleij Tony will you carry this in the OMAP tree? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] gpio-twl4030: new dt properties for BeagleBoard and omap3-EVM
On 9/3/2012 7:24 PM, Florian Vaussard wrote:
> Add device tree properties for twl4030/gpio, according to the
> platform data of corresponding boards. This enables the led
> connected to LEDB output for both boards, as well as
> pullups/pulldowns on GPIO for the BeagleBoard.
>
> Signed-off-by: Florian Vaussard
> ---
> arch/arm/boot/dts/omap3-beagle.dts | 20
> arch/arm/boot/dts/omap3-evm.dts| 13 +
> 2 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts
> b/arch/arm/boot/dts/omap3-beagle.dts
> index cdcb98c..16bff8b 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -17,6 +17,14 @@
> device_type = "memory";
> reg = <0x8000 0x2000>; /* 512 MB */
> };
> +
> + leds {
> + compatible = "gpio-leds";
> + pmu_stat {
> + label = "beagleboard::pmu_stat";
> + gpios = <&twl_gpio 19 0>; /* LEDB */
> + };
> + };
> };
>
> &i2c1 {
> @@ -67,3 +75,15 @@
> &mmc3 {
> status = "disabled";
> };
> +
> +&twl_gpio {
> + ti,use-leds = "true";
> + /* pullups: BIT(1) */
> + ti,pullups = <2>;
> + /*
> + * pulldowns:
> + * BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
> + * BIT(15), BIT(16), BIT(17)
> + */
> + ti,pulldowns = <238020>;
Consider changing above value to hex presentation.
Otherwise looks ok to me, also I have tested it on OMAP3EVM.
Tested-&-Acked-By: Vaibhav Hiremath
Thanks,
Vaibhav
> +};
> diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
> index f349ee9..f1e18fe 100644
> --- a/arch/arm/boot/dts/omap3-evm.dts
> +++ b/arch/arm/boot/dts/omap3-evm.dts
> @@ -17,6 +17,15 @@
> device_type = "memory";
> reg = <0x8000 0x1000>; /* 256 MB */
> };
> +
> + leds {
> + compatible = "gpio-leds";
> + ledb {
> + label = "omap3evm::ledb";
> + gpios = <&twl_gpio 19 0>; /* LEDB */
> + linux,default-trigger = "default-on";
> + };
> + };
> };
>
> &i2c1 {
> @@ -46,3 +55,7 @@
> reg = <0x5c>;
> };
> };
> +
> +&twl_gpio {
> + ti,use-leds = "true";
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] gpio-twl4030: get platform data from device tree
On 9/3/2012 7:24 PM, Florian Vaussard wrote:
> Adds a number of missing properties to the device tree of
> twl4030/gpio:
> - "ti,use-leds" -> .use_leds
> - "ti,debounce" -> .debounce
> - "ti,mmc-cd"-> .mmc_cd
> - "ti,pullups" -> .pullups
> - "ti,pulldowns" -> .pulldowns
>
> Signed-off-by: Florian Vaussard
> ---
> drivers/gpio/gpio-twl4030.c | 86 +-
> 1 files changed, 59 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
> index 94256fe..dabe76b 100644
> --- a/drivers/gpio/gpio-twl4030.c
> +++ b/drivers/gpio/gpio-twl4030.c
> @@ -395,6 +395,33 @@ static int __devinit gpio_twl4030_debounce(u32 debounce,
> u8 mmc_cd)
>
> static int gpio_twl4030_remove(struct platform_device *pdev);
>
> +static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
> +{
> + struct twl4030_gpio_platform_data *omap_twl_info;
> + const char *of_use_leds;
> +
> + omap_twl_info = devm_kzalloc(dev, sizeof(*omap_twl_info), GFP_KERNEL);
> + if (!omap_twl_info)
> + return NULL;
> +
> + omap_twl_info->gpio_base = -1;
> +
> + of_property_read_string(dev->of_node, "ti,use-leds", &of_use_leds);
> + if (!strcmp(of_use_leds, "true"))
> + omap_twl_info->use_leds = true;
> +
You can replace this with
omap_twl_info->use_leds = of_property_read_bool(dev->of_node,
"ti,use-leds");
Otherwise looks OK to me, also I have tested it on OMAP3EVM.
Tested-&-Acked-By: Vaibhav Hiremath
Thanks,
Vaibhav
> + of_property_read_u32(dev->of_node, "ti,debounce",
> + &omap_twl_info->debounce);
> + of_property_read_u32(dev->of_node, "ti,mmc-cd",
> + (u32 *)&omap_twl_info->mmc_cd);
> + of_property_read_u32(dev->of_node, "ti,pullups",
> + &omap_twl_info->pullups);
> + of_property_read_u32(dev->of_node, "ti,pulldowns",
> + &omap_twl_info->pulldowns);
> +
> + return omap_twl_info;
> +}
> +
> static int __devinit gpio_twl4030_probe(struct platform_device *pdev)
> {
> struct twl4030_gpio_platform_data *pdata = pdev->dev.platform_data;
> @@ -423,39 +450,44 @@ static int __devinit gpio_twl4030_probe(struct
> platform_device *pdev)
> twl4030_gpio_irq_base = irq_base;
>
> no_irqs:
> - twl_gpiochip.base = -1;
> twl_gpiochip.ngpio = TWL4030_GPIO_MAX;
> twl_gpiochip.dev = &pdev->dev;
>
> - if (pdata) {
> - twl_gpiochip.base = pdata->gpio_base;
> + if (node)
> + pdata = of_gpio_twl4030(&pdev->dev);
>
> - /*
> - * NOTE: boards may waste power if they don't set pullups
> - * and pulldowns correctly ... default for non-ULPI pins is
> - * pulldown, and some other pins may have external pullups
> - * or pulldowns. Careful!
> - */
> - ret = gpio_twl4030_pulls(pdata->pullups, pdata->pulldowns);
> - if (ret)
> - dev_dbg(&pdev->dev, "pullups %.05x %.05x --> %d\n",
> - pdata->pullups, pdata->pulldowns,
> - ret);
> -
> - ret = gpio_twl4030_debounce(pdata->debounce, pdata->mmc_cd);
> - if (ret)
> - dev_dbg(&pdev->dev, "debounce %.03x %.01x --> %d\n",
> - pdata->debounce, pdata->mmc_cd,
> - ret);
> -
> - /*
> - * NOTE: we assume VIBRA_CTL.VIBRA_EN, in MODULE_AUDIO_VOICE,
> - * is (still) clear if use_leds is set.
> - */
> - if (pdata->use_leds)
> - twl_gpiochip.ngpio += 2;
> + if (pdata == NULL) {
> + dev_err(&pdev->dev, "Platform data is missing\n");
> + return -ENXIO;
> }
>
> + twl_gpiochip.base = pdata->gpio_base;
> +
> + /*
> + * NOTE: boards may waste power if they don't set pullups
> + * and pulldowns correctly ... default for non-ULPI pins is
> + * pulldown, and some other pins may have external pullups
> + * or pulldowns. Careful!
> + */
> + ret = gpio_twl4030_pulls(pdata->pullups, pdata->pulldowns);
> + if (ret)
> + dev_dbg(&pdev->dev, "pullups %.05x %.05x --> %d\n",
> + pdata->pullups, pdata->pulldowns,
> + ret);
> +
> + ret = gpio_twl4030_debounce(pdata->debounce, pdata->mmc_cd);
> + if (ret)
> + dev_dbg(&pdev->dev, "debounce %.03x %.01x --> %d\n",
> + pdata->debounce, pdata->mmc_cd,
> + ret);
> +
> + /*
> + * NOTE: we assume VIBRA_CTL.VIBRA_EN, in MODULE_AUDIO_VOICE,
> + * is (still) clear if use_leds is set.
> + */
> + if (pdata->use_leds)
> + twl_gpiochi
Re: [PATCH 4/4] can: c_can: Add d_can suspend resume support
On 09/04/2012 08:14 AM, AnilKumar, Chimata wrote:
> Marc,
>
> Thanks for the comments,
>
> On Tue, Sep 04, 2012 at 01:31:35, Marc Kleine-Budde wrote:
>> On 09/03/2012 01:52 PM, AnilKumar Ch wrote:
>>> Adds suspend resume support to DCAN driver which enables
>>> DCAN power down mode bit (PDR). Then DCAN will ack the local
>>> power-down mode by setting PDA bit in STATUS register.
>>>
>>> Also adds a status flag to know the status of DCAN module,
>>> whether it is opened or not.
>>
>> Use "ndev->flags & IFF_UP" for that. Have a look at the at91_can driver
>> [1]. I'm not sure if you need locking here.
>>
>
> Then I can use this to check the status, lock is not
> required.
>
>> [1] http://lxr.free-electrons.com/source/drivers/net/can/at91_can.c#L1198
>>
>>> Signed-off-by: AnilKumar Ch
>>> ---
>>> drivers/net/can/c_can/c_can.c | 78
>>>
>>> drivers/net/can/c_can/c_can.h |5 ++
>>> drivers/net/can/c_can/c_can_platform.c | 70 ++--
>>> 3 files changed, 150 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
>>> index c175410..36d5db4 100644
>>> --- a/drivers/net/can/c_can/c_can.c
>>> +++ b/drivers/net/can/c_can/c_can.c
>>> @@ -46,6 +46,9 @@
>>> #define IF_ENUM_REG_LEN11
>>> #define C_CAN_IFACE(reg, iface)(C_CAN_IF1_##reg + (iface) *
>>> IF_ENUM_REG_LEN)
>>>
>>> +/* control extension register D_CAN specific */
>>> +#define CONTROL_EX_PDR BIT(8)
>>> +
>>> /* control register */
>>> #define CONTROL_TEST BIT(7)
>>> #define CONTROL_CCEBIT(6)
>>> @@ -65,6 +68,7 @@
>>> #define TEST_BASIC BIT(2)
>>>
>>> /* status register */
>>> +#define STATUS_PDA BIT(10)
>>> #define STATUS_BOFFBIT(7)
>>> #define STATUS_EWARN BIT(6)
>>> #define STATUS_EPASS BIT(5)
>>> @@ -164,6 +168,9 @@
>>> /* minimum timeout for checking BUSY status */
>>> #define MIN_TIMEOUT_VALUE 6
>>>
>>> +/* Wait for ~1 sec for INIT bit */
>>> +#define INIT_WAIT_COUNT1000
>>
>> What unit? INIT_WAIT_MS would be a better name.
>>
>
> Sure, will change
>
>>> +
>>> /* napi related */
>>> #define C_CAN_NAPI_WEIGHT C_CAN_MSG_OBJ_RX_NUM
>>>
>>> @@ -1102,6 +1109,7 @@ static int c_can_open(struct net_device *dev)
>>>
>>> netif_start_queue(dev);
>>>
>>> + priv->is_opened = true;
>>> return 0;
>>>
>>> exit_irq_fail:
>>> @@ -1126,6 +1134,7 @@ static int c_can_close(struct net_device *dev)
>>> /* De-Initialize DCAN RAM */
>>> c_can_reset_ram(priv, false);
>>> c_can_pm_runtime_put_sync(priv);
>>> + priv->is_opened = false;
>>>
>>> return 0;
>>> }
>>> @@ -1154,6 +1163,75 @@ struct net_device *alloc_c_can_dev(void)
>>> }
>>> EXPORT_SYMBOL_GPL(alloc_c_can_dev);
>>>
>>> +#ifdef CONFIG_PM
>>> +int c_can_power_down(struct net_device *dev)
>>> +{
>>> + unsigned long time_out;
>>> + struct c_can_priv *priv = netdev_priv(dev);
>>> +
>>> + if (!priv->is_opened)
>>> + return 0;
>>
>> Should we add a BUG_ON(id->driver_data != BOSCH_D_CAN)?
>
> These APIs are called from platform driver where device type
> device type is verified. I think we have to add BUG_ON() in
> platform driver.
The platform driver returns if not on D_CAN and will not call this
function. But this functions are exported, so can be called by someone
else. So if the caller is not D_CAN, it's a bug.
>>> +
>>> + /* set `PDR` value so the device goes to power down mode */
>>> + priv->write_reg(priv, C_CAN_CTRL_EX_REG,
>>> + priv->read_reg(priv, C_CAN_CTRL_EX_REG) | CONTROL_EX_PDR);
>>
>> Please use an intermediate variable:
>>
>> u32 val;
>>
>> val = priv->read_reg(priv, C_CAN_CTRL_EX_REG);
>> val |= CONTROL_EX_PDR;
>> priv->write_reg(priv, C_CAN_CTRL_EX_REG, val);
>
> I will change
>
>>
>>> +
>>> + /* Wait for the PDA bit to get set */
>>> + time_out = jiffies + msecs_to_jiffies(INIT_WAIT_COUNT);
>>> + while (!(priv->read_reg(priv, C_CAN_STS_REG) & STATUS_PDA) &&
>>> + time_after(time_out, jiffies))
>>> + cpu_relax();
>>> +
>>> + if (time_after(jiffies, time_out))
>>> + return -ETIMEDOUT;
>>> +
>>> + c_can_stop(dev);
>>> +
>>> + /* De-initialize DCAN RAM */
>>> + c_can_reset_ram(priv, false);
>>> + c_can_pm_runtime_put_sync(priv);
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(c_can_power_down);
>>> +
>>> +int c_can_power_up(struct net_device *dev)
>>> +{
>>> + unsigned long time_out;
>>> + struct c_can_priv *priv = netdev_priv(dev);
>>> +
>>
>> BUG_ON?
>>
>>> + if (!priv->is_opened)
>>> + return 0;
>>> +
>>> + c_can_pm_runtime_get_sync(priv);
>>> + /* Initialize DCAN RAM */
>>> + c_can_reset_ram(priv, true);
>>> +
>>> + /* Clear PDR and INIT bits */
>>> + priv->write_reg(priv, C_CAN_CTRL_EX_REG,
>>> + priv->read_reg(priv, C_CAN_CTRL_EX_REG)
Re: [PATCH 0/8] OMAPDSS: Misc improvements
Hi Tony, Can you check the arch/arm patches below, and suggest how you'd like to go forward with them? Tomi On Thu, 2012-08-23 at 16:45 +0300, Tomi Valkeinen wrote: > Hi, > > This series contains miscellaneous improvements for omapdss, which I've made > while implementing device tree support for omapdss. This includes some changes > to arch/arm/: > > * remove OMAP4 HDMI gpio handling from board files > * add vdda_hdmi_dac supply for HDMI to twl-common.c > * remove DSS clock dividers from 4430sdp board file > > Tony, omapdss has dependencies to those changes, and the first change also has > a dependency to omapdss header file. Is it ok to merge them with other omapdss > changes? > > Chances for conflict are probably pretty small, 1st and 3rd change are > pure display stuff, and the 2nd adds the supply to a regulator not used by > anyone else than DSS. > > Tomi > > Tomi Valkeinen (8): > OMAPDSS: HDMI: Move GPIO handling to HDMI driver > OMAPDSS: HDMI: Add delay to wait for 5V power > OMAP4: TWL: add vdda_hdmi_dac regulator supply > OMAPDSS: HDMI: use vdda_hdmi_dac > OMAPDSS: Add DSI fclk maximum to dss_features > OMAPDSS: DSI: calculate dsi clock > OMAP: 4430SDP: remove DSI clock config from board file > OMAPDSS: fix use of dssdev->caps > > arch/arm/mach-omap2/board-4430sdp.c | 73 +--- > arch/arm/mach-omap2/board-omap4panda.c| 27 +- > arch/arm/mach-omap2/twl-common.c |6 ++ > drivers/video/omap2/displays/panel-n8x0.c |1 + > drivers/video/omap2/displays/panel-taal.c |8 ++ > drivers/video/omap2/dss/dsi.c | 131 > +++-- > drivers/video/omap2/dss/dss_features.c|2 + > drivers/video/omap2/dss/dss_features.h|1 + > drivers/video/omap2/dss/hdmi.c| 101 +- > drivers/video/omap2/dss/rfbi.c|1 - > include/video/omapdss.h |4 + > 11 files changed, 233 insertions(+), 122 deletions(-) > signature.asc Description: This is a digitally signed message part
