Re: [PATCH] mfd: Palmas: Remove code which is not necessary for a device tree boot
On Mon, Jun 17, 2013 at 11:16:02AM +0530, J Keerthy wrote:
Remove code which is not necessary for a device tree boot.
Boot tested on OMAP5-UEVM board.
Signed-off-by: J Keerthy j-keer...@ti.com
This looks good to me!
Acked-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/mfd/palmas.c | 106
--
1 files changed, 0 insertions(+), 106 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 53e9fe6..62fa728 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -25,77 +25,6 @@
#include linux/mfd/palmas.h
#include linux/of_platform.h
-enum palmas_ids {
- PALMAS_PMIC_ID,
- PALMAS_GPIO_ID,
- PALMAS_LEDS_ID,
- PALMAS_WDT_ID,
- PALMAS_RTC_ID,
- PALMAS_PWRBUTTON_ID,
- PALMAS_GPADC_ID,
- PALMAS_RESOURCE_ID,
- PALMAS_CLK_ID,
- PALMAS_PWM_ID,
- PALMAS_USB_ID,
-};
-
-static struct resource palmas_rtc_resources[] = {
- {
- .start = PALMAS_RTC_ALARM_IRQ,
- .end= PALMAS_RTC_ALARM_IRQ,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static const struct mfd_cell palmas_children[] = {
- {
- .name = palmas-pmic,
- .id = PALMAS_PMIC_ID,
- },
- {
- .name = palmas-gpio,
- .id = PALMAS_GPIO_ID,
- },
- {
- .name = palmas-leds,
- .id = PALMAS_LEDS_ID,
- },
- {
- .name = palmas-wdt,
- .id = PALMAS_WDT_ID,
- },
- {
- .name = palmas-rtc,
- .id = PALMAS_RTC_ID,
- .resources = palmas_rtc_resources[0],
- .num_resources = ARRAY_SIZE(palmas_rtc_resources),
- },
- {
- .name = palmas-pwrbutton,
- .id = PALMAS_PWRBUTTON_ID,
- },
- {
- .name = palmas-gpadc,
- .id = PALMAS_GPADC_ID,
- },
- {
- .name = palmas-resource,
- .id = PALMAS_RESOURCE_ID,
- },
- {
- .name = palmas-clk,
- .id = PALMAS_CLK_ID,
- },
- {
- .name = palmas-pwm,
- .id = PALMAS_PWM_ID,
- },
- {
- .name = palmas-usb,
- .id = PALMAS_USB_ID,
- }
-};
-
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] =
{
{
.reg_bits = 8,
@@ -311,7 +240,6 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
int ret = 0, i;
unsigned int reg, addr;
int slave;
- struct mfd_cell *children;
pdata = dev_get_platdata(i2c-dev);
@@ -472,42 +400,8 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
return ret;
}
- children = kmemdup(palmas_children, sizeof(palmas_children),
-GFP_KERNEL);
- if (!children) {
- ret = -ENOMEM;
- goto err_irq;
- }
-
- children[PALMAS_PMIC_ID].platform_data = pdata-pmic_pdata;
- children[PALMAS_PMIC_ID].pdata_size = sizeof(*pdata-pmic_pdata);
-
- children[PALMAS_GPADC_ID].platform_data = pdata-gpadc_pdata;
- children[PALMAS_GPADC_ID].pdata_size = sizeof(*pdata-gpadc_pdata);
-
- children[PALMAS_RESOURCE_ID].platform_data = pdata-resource_pdata;
- children[PALMAS_RESOURCE_ID].pdata_size =
- sizeof(*pdata-resource_pdata);
-
- children[PALMAS_USB_ID].platform_data = pdata-usb_pdata;
- children[PALMAS_USB_ID].pdata_size = sizeof(*pdata-usb_pdata);
-
- children[PALMAS_CLK_ID].platform_data = pdata-clk_pdata;
- children[PALMAS_CLK_ID].pdata_size = sizeof(*pdata-clk_pdata);
-
- ret = mfd_add_devices(palmas-dev, -1,
- children, ARRAY_SIZE(palmas_children),
- NULL, 0,
- regmap_irq_get_domain(palmas-irq_data));
- kfree(children);
-
- if (ret 0)
- goto err_devices;
-
return ret;
-err_devices:
- mfd_remove_devices(palmas-dev);
err_irq:
regmap_del_irq_chip(palmas-irq, palmas-irq_data);
err:
--
1.7.5.4
--
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/2] ARM: dts: add AM33XX MMC support
* Felipe Balbi ba...@ti.com [130615 08:12]: fair enough, then let's just add those interrupts to hwmod which will, eventually, let us drop all of that data from hwmod. Nope, we're already dropping the duplicate data from hwmod for am33xx and omap4. See omap-for-v3.11/cleanup branch. Regards, 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
RE: [PATCH v6] ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes
Hi Benoit,
-Original Message-
From: J, KEERTHY
Sent: Thursday, June 13, 2013 10:19 PM
To: Cousson, Benoit
Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@wwwdotorg.org;
swar...@nvidia.com; sa...@linux.intel.com; g...@slimlogic.co.uk;
lee.jo...@linaro.org; devicetree-disc...@lists.ozlabs.org
Subject: RE: [PATCH v6] ARM: dts: OMAP5: Add Palmas MFD node and
regulator nodes
Hi Benoit,
-Original Message-
From: J, KEERTHY
Sent: Thursday, June 13, 2013 10:00 AM
To: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org
Cc: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca;
swar...@wwwdotorg.org; swar...@nvidia.com; sa...@linux.intel.com;
g...@slimlogic.co.uk; lee.jo...@linaro.org; J, KEERTHY
Subject: [PATCH v6] ARM: dts: OMAP5: Add Palmas MFD node and
regulator
nodes
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Could you please pull this patch?
A gentle ping on this patch.
Regards,
Keerthy
Regards,
Keerthy
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
Signed-off-by: J Keerthy j-keer...@ti.com
Reviewed-by: Stephen Warren swar...@nvidia.com
---
V6:
Changed the order of properties.
V5:
Corrected the IRQ_TYPE flag for OMAP5 board.
V4:
Removed splitting Palmas node.
V3:
Moved the entire Palmas device tree node to board file.
arch/arm/boot/dts/omap5-uevm.dts | 167
++
1 files changed, 167 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..3d0b7b6 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,171 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ compatible = ti,palmas;
+ interrupts = GIC_SPI 7 IRQ_TYPE_NONE; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ reg = 0x48;
+ interrupt-controller;
+ #interrupt-cells = 2;
+
+ palmas_pmic {
+ compatible = ti,palmas-pmic;
+ interrupt-parent = palmas;
+ interrupts = 14 IRQ_TYPE_NONE;
+ interrupt-name = short-irq;
+
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-name = smps45;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-name = smps6;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-name = smps7;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-name = smps8;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-name = smps9;
+
Re: [PATCH] gpio/omap: omap_gpio_init_context stub must be inline
On Fri, May 31, 2013 at 5:59 PM, Arnd Bergmann a...@arndb.de wrote:
The bug fix 352a2d5bf gpio/omap: ensure gpio context is initialised
has caused a new warning for omap1_defconfig:
drivers/gpio/gpio-omap.c:1465:13: warning: 'omap_gpio_init_context' defined
but not used [-Wunused-function]
static void omap_gpio_init_context(struct gpio_bank *p) {}
^
The solution is to mark the stub function as 'static inline' so
it gets left out of the build when unused.
Signed-off-by: Arnd Bergmann a...@arndb.de
Patch applied with Tony's and Santosh's ACKs.
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] mfd: Palmas: Remove code which is not necessary for a device tree boot
On Monday 17 June 2013 11:16 AM, J Keerthy wrote: Remove code which is not necessary for a device tree boot. Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com Looks good to me. Acked-by: Laxman Dewangan ldewan...@nvidia.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] gpio: Enable pcf857x GPIO expander for Device Tree
Hi Linus,
On Thursday 06 June 2013 07:35 PM, Archit Taneja wrote:
Add code to parse the GPIO expander Device Tree node and extract platform data
out of it, and populate the struct 'pcf857x_platform_data' maintained by the
driver. This enables devices to reference the gpio expander from Device Tree.
Add DT binding info in Documentation.
Any comments on this patch?
Thanks,
Archit
CC: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Archit Taneja arc...@ti.com
---
.../devicetree/bindings/gpio/gpio-pcf857x.txt | 44 +
drivers/gpio/gpio-pcf857x.c| 57 --
2 files changed, 97 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
new file mode 100644
index 000..0556512
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
@@ -0,0 +1,44 @@
+PCF857x I2C based GPIO controller bindings
+
+Required properties:
+- compatible:
+ - nxp,pca9670 for NXP PCA9670 8 bit I/O expander
+ - nxp,pca9672 for NXP PCA9672 8 bit I/O expander with interrupt
+ - nxp,pca9674 for NXP PCA9672 8 bit I/O expander with interrupt
+ - nxp,pca8574 for NXP PCA8574 8 bit I/O expander with interrupt
+ - nxp,pca8575 for NXP PCA8575 16 bit I/O expander with interrupt
+ - nxp,pca9671 for NXP PCA9671 16 bit I/O expander
+ - nxp,pca9673 for NXP PCA9673 16 bit I/O expander with interrupt
+ - nxp,pca9675 for NXP PCA9675 16 bit I/O expander with interrupt
+ - ti,pcf8574 for TI PCF8574 8 bit I/O expander with interrupt
+ - ti,pcf8574a for TI PCF8574A 8 bit I/O expander with interrupt
+ - ti,pcf8575 for TI PCF8575 16 bit I/O expander with interrupt
+ - ti,tca9554 for TI TCA9554 8 bit I/O expander with interrupt
+ - maxim,max7328 for MAXIM MAX7328 8 bit I/O expander with interrupt
+ - maxim,max7329 for MAXIM MAX7329 8 bit I/O expander with interrupt
+- gpio-controller : Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two.
+ - first cell is the pin number.
+ - second cell is unused.
+- interrupt-controller: Mark the device node as an interrupt controller.
+- #interrupt-cells : Should be two.
+ - first cell is the GPIO number.
+ - second cell is unused.
+- reg: I2C address of the chip.
+
+Device speific properties:
+- n_latch: optional bit-inverse of initial register value; if
+ you leave this initialized to zero the driver will act
+ like the chip was just reset.
+
+Example:
+
+pcf8575: pcf8575 {
+ compatible = ti,pcf8575;
+ gpio-controller;
+ #gpio-cells = 2;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 0x20;
+ n_latch = 0x0;
+};
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index e8faf53..3435790 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -21,6 +21,7 @@
#include linux/kernel.h
#include linux/slab.h
#include linux/gpio.h
+#include linux/of.h
#include linux/i2c.h
#include linux/i2c/pcf857x.h
#include linux/interrupt.h
@@ -255,17 +256,42 @@ fail:
/*-*/
+static struct pcf857x_platform_data *of_gpio_pcf857x(struct device *dev)
+{
+ struct pcf857x_platform_data *pdata;
+ int r;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+
+ pdata-gpio_base = -1;
+
+ r = of_property_read_u32(dev-of_node, n_latch, pdata-n_latch);
+ if (r) {
+ dev_dbg(dev, couldn't find n-latch, use default\n);
+ pdata-n_latch = 0;
+ }
+
+ return pdata;
+}
+
static int pcf857x_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct pcf857x_platform_data*pdata;
+ struct device_node *node;
struct pcf857x *gpio;
int status;
pdata = client-dev.platform_data;
- if (!pdata) {
+ node = client-dev.of_node;
+
+ if (!pdata node)
+ pdata = of_gpio_pcf857x(client-dev);
+
+ if (!pdata)
dev_dbg(client-dev, no platform data\n);
- }
/* Allocate, initialize, and register this gpio_chip. */
gpio = devm_kzalloc(client-dev, sizeof(*gpio), GFP_KERNEL);
@@ -420,10 +446,33 @@ static int pcf857x_remove(struct i2c_client *client)
return status;
}
+static const struct of_device_id pcf857x_dt_ids[] = {
+ { .compatible = nxp,pca9670, },
+ { .compatible = nxp,pca9672, },
+ { .compatible = nxp,pca9674, },
+ { .compatible = nxp,pca8574, },
+ { .compatible = nxp,pca8575, },
+ { .compatible = nxp,pca9671, },
+ { .compatible = nxp,pca9673,
Re: Request for OMAPDSS testing
On 16/06/13 15:28, Igor Grinberg wrote: Although one thing is missing from the tfp410 driver is the PD GPIO polarity. I had to adjust it locally to get the DVI working. The original polarity was high = disabled, low = enabled. Hmm, but this is missing from the old driver also, isn't it? At least with a quick glance the old and new tfp410 drivers do the same thing with the PD gpio. Well, we were driving the PD GPIO from the board file... Ah, I see. That was inverted PD handling was removed in 3.5, by accident as far as I see. So DVI on cm-t35 has been broken since? I wonder how that should be fixed... The tfp410 driver handles it correctly, as the PD gpio is active low (i.e. high == tfp410 enabled), so having it inverted is a board specific thing. Do you know what is the reason to have it inverted? There seems to be OF_GPIO_ACTIVE_LOW, but I'm not sure how it should be used, as I don't see anyone setting that flag... And supporting that would mean, in principle, that every driver should support inverting the gpio with every gpio they have. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
On Friday 14 June 2013 07:28 PM, Ming Lei wrote: On Fri, Jun 14, 2013 at 9:31 PM, Ming Lei tom.leim...@gmail.com wrote: On Thu, Jun 13, 2013 at 6:12 PM, Sricharan R r.sricha...@ti.com wrote: On Thursday 13 June 2013 02:51 PM, Sricharan R wrote: Hi Tony, On Wednesday 12 June 2013 10:44 PM, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [130612 09:37]: * Ming Lei tom.leim...@gmail.com [130603 08:34]: Hi, On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren t...@atomide.com wrote: We can now boot with device tree. If you don't want to update u-boot, you can boot with appended DTB with the following instructions: 1. Make sure you have the appended DTB support in .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y 2. Build the zImage $ ARCH=arm CROSS_COMPILE=... make zImage 3. Build the device tree blobs $ ARCH=arm CROSS_COMPILE=... make dtbs 4. Append the correct panda dtb to zImage Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb or omap4-panda-es.dtb. $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb /tmp/appended 5. Use mkimage to produce the appended device tree uImage $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ -n Linux -d /tmp/appended /tmp/uImage I followed the above steps and tried devicetree on Pandaboard against 3.10.0-rc3-next-20130528, and the board will hang during boot, but works well with legacy mode. Hardware: Pandaboard A1 dtb: omap4-panda.dtb See 'dmesg' on below link: http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg Hmm looks like it boots to init. Maybe add initcall_debug to the cmdline in case there's some late_initcall that causes the issue. It's probably some trivial issue causing it. Sricharan, maybe give this a quick try if you have the original pandaboard? I only have pandaboard es. Regards, Tony I tried your cleanup branch omap-for-v3.11/cleanup on panda board and it booted to prompt fine. Hardware: Pandaboard A1 dtb: omap4-panda.dtb git pull on linux-next branch was not working though. Ok, tested in linux-next as well and it booted fine with DTB. HW: OMAP4430ES2.1 PANDA A1 version DTB: OMAP4-PANDA.DTB Booted with ramdisk and mmc FS commit c04efed734409f5a44715b54a6ca1b54b0ccf215 Author: Stephen Rothwell s...@canb.auug.org.au Date: Fri Jun 7 16:40:02 2013 +1000 Add linux-next specific files for 20130607 Looks linux-next-20130607 is broken, see below: LD [M] drivers/usb/gadget/g_ncm.o drivers/usb/musb/omap2430.c: In function 'omap2430_probe': drivers/usb/musb/omap2430.c:571:2: error: 'musb_resources' undeclared (first use in this function) drivers/usb/musb/omap2430.c:571:2: note: each undeclared identifier is reported only once for each function it appears in drivers/usb/musb/omap2430.c:571:2: error: bit-field 'anonymous' width not an integer constant drivers/usb/musb/omap2430.c:585:4: error: bit-field 'anonymous' width not an integer constant make[3]: *** [drivers/usb/musb/omap2430.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [drivers/usb/musb] Error 2 make[2]: *** Waiting for unfinished jobs make[1]: *** [drivers/usb] Error 2 make: *** [drivers] Error 2 install kernel and modules DEPMOD 3.10.0-rc4-next-20130607+ Even I disable musb so that kernel building is OK, but the kernel with dtb still can't boot, see attachment 'dmesg' and config. Thanks, I am not sure how both of us are different. I was testing 20130607 with an omap2plusdefconfig. Also i was using a minimal busy box file system.. Is there anything specific FS that you want me to try ? I am using the latest u-boot version. U-Boot SPL 2013.07-rc1-00010-gdfdb3d3 (Jun 17 2013 - 13:09:51) OMAP4430 ES2.1 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.07-rc1-00010-gdfdb3d3 (Jun 17 2013 - 13:09:51) CPU : OMAP4430 ES2.1 Board: OMAP4 Panda I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0 Using default environment In:serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 0 Panda # Panda # setenv bootargs root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x8160,20M ramdisk_size=20480 earlyprintk Panda # mmc dev 0 mmc0 is current device Panda # fatload mmc 0 0x8030 uImage reading uImage 4394007 bytes read in 300 ms (14 MiB/s) Panda # fatload mmc 0 0x8160 bb.raw reading bb.raw 1024 bytes read in 722 ms (13.5 MiB/s) Panda # bootm 0x8030 ## Booting kernel from Legacy Image at 8030 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4393943 Bytes = 4.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00]
Re: OMAP4 Panda DVI problem
Hi Tomi, On 06/14/2013 04:52 PM, Tomi Valkeinen wrote: Hi Tony, Roger, I recently raised the i2c issue with reading EDID from a DVI monitor on Panda, when booting with DT. I just couldn't get reading EDID work at all reliably. I now see problems with non-DT also. Booting with 3.10-rc5, with DSS compiled into the kernel, reading EDID fails during the boot. I can later read the EDID fine from userspace. With help from Roger, we found the issue. DVI cable has a +5V line, that the source (i.e. Panda) has to provide. This +5V is required to read EDID, but according to the documentation I think it's actually required to show video also (although I guess this could depend on the monitor). I think for OMAP3 boards the +5V is always-on (I haven't looked at OMAP3 boards yet, though). For Panda, the +5V comes from DC_HST_5V, controlled with a GPIO, which is used for USB and currently managed by USB in arch/arm/mach-omap2/usb-host.c, which creates a fixed voltage hsusbX_vcc regulator. So, basically, if USB is disabled, DVI doesn't work. This is why I see problems with DT (no USB), and non-DT (USB enabled after DVI is enabled). To fix this properly I need to add regulator handling to the DVI driver, and we need to share the same supply with USB and DVI. However, while the above shouldn't be particularly difficult, it's still not simple. And additional complications come with DT boot, as DSS doesn't support DT yet. We have the hack that enables DSS for Panda and SDP board when booting with DT, but I don't think it's possible to manage the shared regulator easily in that setup (ie. USB and the regulator being described in DT, DSS and DVI added the old way in dss-common.c). So I think the simplest solution is to make DC_HST_5V always-on. This should be fixed for 3.10 also. I am fine with this. Any idea if DC_HST_5V is a big power sink if it's always enabled? If it's a big one, I could look at how to hack the DVI driver so that it would find the regulator. I'm quite sure I won't be neat, though. DC_HST_5V is going to be active if USB is active. So I wouldn't be much worried if this supply is left always ON for people needing USB host ethernet. (NOTE, ethernet is part of the same USB hub chip) cheers, -roger -- 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/6] ARM: OMAP2+: Remove board-omap4panda.c
Sricharan R r.sricha...@ti.com writes: Hi, [...] Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.10.0-rc4-next-20130607 (a0393807@uda0393807) (gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-57) ) #18 SMP Mon Jun 17 12:55:05 IST 2013 [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] cma: CMA: reserved 16 MiB at ae80 [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] OMAP4430 ES2.1 [0.00] PERCPU: Embedded 9 pages/cpu @c15d5000 s13440 r8192 d15232 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260368 [0.00] Kernel command line: root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x8160,20M ramdisk_size=20480 earlyprintk [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 987436K/1047552K available (5619K kernel code, 603K rwdata, 1908K rodata, 393K init, 5521K bss, 60116K reserved, 269312K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc07620e8 (7529 kB) [0.00] .init : 0xc0763000 - 0xc07c5480 ( 394 kB) [0.00] .data : 0xc07c6000 - 0xc085ccc8 ( 604 kB) [0.00].bss : 0xc085ccc8 - 0xc0dc10f0 (5522 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] OMAP clockevent source: timer1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] OMAP clocksource: 32k_counter at 32768 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 3695 kB [0.00] per task-struct memory footprint: 1152 bytes [0.001403] Calibrating delay loop... 1191.11 BogoMIPS (lpj=5955584) [0.079742] pid_max: default: 32768 minimum: 301 [0.080535] Security Framework initialized [0.080780] Mount-cache hash table entries: 512 [0.085571] CPU: Testing write buffer coherency: ok [0.087493] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.087829] Setting up static identity map for 0xc0556058 - 0xc05560c8 [0.087890] L310 cache controller enabled [0.087921] l2x0: 16 ways, CACHE_ID 0x41c4, AUX_CTRL 0x7e47, Cache size: 1048576 B [0.093048] CPU1: Booted secondary processor [0.177764] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.178283] Brought up 2 CPUs [0.178314] SMP: Total of 2 processors activated (2387.96 BogoMIPS). [0.178314] CPU: All CPU(s) started in SVC mode. [0.181152] devtmpfs: initialized [0.254455] pinctrl core: initialized pinctrl subsystem [0.258117] regulator-dummy: no parameters [0.261657] NET: Registered protocol family 16 [0.270538] DMA: preallocated 256 KiB pool for atomic coherent allocations [0.272033] omap-gpmc omap-gpmc: GPMC revision 6.0 [0.281036] OMAP GPIO hardware version 0.1 [0.295837] omap_mux_init: Add partition: #1: core, flags: 3 [0.298095] omap_mux_init: Add partition: #2: wkup, flags: 3 [0.298309] error setting wl12xx data: -38 [0.298583] omap_mux_get_by_name: Could not find signal sys_nirq [0.303375] omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx [0.384521] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers. [0.384521] hw-breakpoint: maximum watchpoint size is 4 bytes. [0.398803] OMAP DMA hardware revision 0.0 [0.402832] ARM PMU: not yet supported on OMAP4430 due to missing CTI driver [0.449371] bio: create slab bio-0 at 0 [0.514038] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [0.515258] vwl1271: 1800 mV [0.516174] hsusb1_reset: 3300
Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
On Mon, Jun 17, 2013 at 4:06 PM, Arnaud Patard arnaud.pat...@rtp-net.org wrote: Sricharan R r.sricha...@ti.com writes: I hoped to have missed some mails and that people were testing pandabard support with full support but given what I see, the ethernet support is not there yet. This thread is about removing the non-DT boot. I see some contradiction here. Please, look again at what Thomas said in the IGEP thread: breaking existing support is bad and removing non-DT boot for panda with not-working ethernet would exactly to that. +1 Even no any USB support on Sricharan's setting. Yeah, I'm aware that some extra patches are being developped like the omap clocks one: https://patchwork.kernel.org/patch/2541331/ but they don't seem to be in -next. So, again, please, wait that all needed bits are merged mainline before killing non-DT support (or provide 'mixed' support like what is/was done on kirkwood) Agree, please don't be too quick, :-) Thanks, -- Ming Lei -- 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/6] ARM: OMAP2+: Remove board-omap4panda.c
* Arnaud Patard arnaud.pat...@rtp-net.org [130617 01:13]: I hoped to have missed some mails and that people were testing pandabard support with full support but given what I see, the ethernet support is not there yet. This thread is about removing the non-DT boot. I see some contradiction here. Please, look again at what Thomas said in the IGEP thread: breaking existing support is bad and removing non-DT boot for panda with not-working ethernet would exactly to that. Hmm yes I guess the panda needs the aux clock and there are various patches posted for that for quite a while but have not gotten merged. When I did my patches it seemed that Nishant's and my solution for getting the auxclk via DT was acceptable. Then Mike started doing all the clocks in DT and things changed. Mike, got any solution for us for v3.11 for the DT defined auxclk? Yeah, I'm aware that some extra patches are being developped like the omap clocks one: https://patchwork.kernel.org/patch/2541331/ but they don't seem to be in -next. So, again, please, wait that all needed bits are merged mainline before killing non-DT support (or provide 'mixed' support like what is/was done on kirkwood) The ethernet issue can be fixed with the legacy mode support in the worst case, but probably just adding a clock alias for it does the trick. I'd rather not postpone making omap4 DT only because I think at this point fixing the any DT related issues is way less work compared to maintaining and testing both legacy boot and DT boot. Regards, 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
Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
* Ming Lei tom.leim...@gmail.com [130617 01:22]: On Mon, Jun 17, 2013 at 4:06 PM, Arnaud Patard arnaud.pat...@rtp-net.org wrote: Sricharan R r.sricha...@ti.com writes: I hoped to have missed some mails and that people were testing pandabard support with full support but given what I see, the ethernet support is not there yet. This thread is about removing the non-DT boot. I see some contradiction here. Please, look again at what Thomas said in the IGEP thread: breaking existing support is bad and removing non-DT boot for panda with not-working ethernet would exactly to that. +1 Even no any USB support on Sricharan's setting. That's also related to the auxclk. Let's see what Mike says before we start adding back any legacy hacks for it. Yeah, I'm aware that some extra patches are being developped like the omap clocks one: https://patchwork.kernel.org/patch/2541331/ but they don't seem to be in -next. So, again, please, wait that all needed bits are merged mainline before killing non-DT support (or provide 'mixed' support like what is/was done on kirkwood) Agree, please don't be too quick, :-) Too quick? The basic DT based booting has been working for a few years now to some extent on omaps :) Regards, 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
Re: Request for OMAPDSS testing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/17/13 10:08, Tomi Valkeinen wrote:
On 16/06/13 15:28, Igor Grinberg wrote:
Although one thing is missing from the tfp410 driver is
the PD GPIO polarity. I had to adjust it locally to get the DVI working.
The original polarity was high = disabled, low = enabled.
Hmm, but this is missing from the old driver also, isn't it? At least
with a quick glance the old and new tfp410 drivers do the same thing
with the PD gpio.
Well, we were driving the PD GPIO from the board file...
Ah, I see. That was inverted PD handling was removed in 3.5, by accident
as far as I see. So DVI on cm-t35 has been broken since?
Well, we have applied the below patches since then (the patches are against
3.7),
but haven't had time to send it upstream...
I wonder how that should be fixed... The tfp410 driver handles it
correctly, as the PD gpio is active low (i.e. high == tfp410 enabled),
so having it inverted is a board specific thing. Do you know what is the
reason to have it inverted?
Yes, the reason for this is the sb-t35 (the baseboard) which has the TFP410
in 3.3V domain, but the cm-t3530/3730 are in 1.8V domain.
This means that the line must be shifted.
Now for some reason hardware guys used an inverter as the level shifter
instead of a simple buffer. So now it is shifted and inverted...
There seems to be OF_GPIO_ACTIVE_LOW, but I'm not sure how it should be
used, as I don't see anyone setting that flag... And supporting that
would mean, in principle, that every driver should support inverting the
gpio with every gpio they have.
Might be worth to consider adding this functionality to the GPIOLIB?
Meanwhile, I think the simplest way would be to add a boolean
like OF_GPIO_ACTIVE_LOW, as we have hardware that needs it.
If you think the patches are conceptually fine,
I can rebase them on top of your tree with the new drivers and
submit properly.
- --
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
iQIcBAEBAgAGBQJRvstaAAoJEBDE8YO64EfatIMQAJbAO7rkQNTlTwL4qkANZV7h
v1msnUbjuiGr5hb34UX07b3lBoIXkI9Uqt6rC25vbIDZPW8EaKmMwLle87aXpAVI
QsA8wujQx7p1S9oLjVSdu1AZeQZv4vHBZPU5R/xlOGocbs2TgJ1/Pn4eYVKDHW9Q
Sv3wHwiZgkwOT+7nAe7mAmuLsWl62rxF94Psw4imC9M35wpxat9hXWaIJPu6WwRS
DdaySlfxasG9aMg/CMCxf8Cjcmk4cKjJ8vRVhmW0J1ISuUofSfxiL6K611bTjaqb
oCO8qTxThLebTlvW6LrVZ8Etcr4HAp2zG6o0ZZmdYxMROJ9feMhJgZ7dIwUSOlK5
OSwAyfGsG1m4EqnfokgRx6Eg+ur2VirqZ6NcXEt5ljHHfnu4VeY/glHpSnfuwsN8
e27tSlJXv15EXEcASFqaujDUzV7qPYYcLYy5Wssjg9V/RTZoT3kHhouNnE5/doP+
d7qC/nheG6O3iT2cT4OMcnBi9nywaOR7ogMgauGZjDCB9pLrvTe4iBJFgfa2CkC3
QlB8lD8+tUXC6kGhlYv9RaZy/MP8CQWAYCel0k4vbjAB/KvY0KNHMpwmTzfGALhB
LI2/swhSpE6+0q3M3tylds15HQCmNSmO/1AVRdvgrJQXZbGz8PBCuxH7QqInS/ob
JXjx9lUaw9tRsVQKcqPp
=5nPt
-END PGP SIGNATURE-
From 4eaa3d23ba484370c6b709ff21ca764a47033f34 Mon Sep 17 00:00:00 2001
From: Dmitry Lifshitz lifsh...@compulab.co.il
Date: Wed, 9 Jan 2013 14:04:08 +0200
Subject: [PATCH] OMAPDSS: TFP410: support edge select pin strap
Pin 9 (EDGE/HTPLG) of tfp410 DVI transmitter is used (when I2C is
disabled) to control the data sampling on the rising or falling
edge of the pixel clock.
OMAP DSS timings for tfp410 should be adjusted according to
the chip pin strap to avoid various visual artifacts in the DVI output.
Enhance the tfp410 driver platform data with the flag to modify
default tfp410 timing settings according to the chip pin strap.
Signed-off-by: Dmitry Lifshitz lifsh...@compulab.co.il
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
drivers/video/omap2/displays/panel-tfp410.c |8
include/video/omap-panel-tfp410.h |3 +++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tfp410.c b/drivers/video/omap2/displays/panel-tfp410.c
index e611ebd..77ce139 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -115,6 +115,14 @@ static int tfp410_probe(struct omap_dss_device *dssdev)
ddata-pd_gpio = pdata-power_down_gpio;
ddata-invert_pd_gpio = pdata-invert_pd_gpio;
i2c_bus_num = pdata-i2c_bus_num;
+
+ /*
+ * If the data latch occur on the rising edge of the pixel
+ * clock, then the data strobe should be on the falling edge.
+ */
+ if (pdata-latch_on_rising_edge)
+ dssdev-panel.timings.data_pclk_edge =
+ OMAPDSS_DRIVE_SIG_FALLING_EDGE;
} else {
ddata-pd_gpio = -EINVAL;
i2c_bus_num = -1;
diff --git a/include/video/omap-panel-tfp410.h b/include/video/omap-panel-tfp410.h
index cd1061e..f5424aa 100644
--- a/include/video/omap-panel-tfp410.h
+++ b/include/video/omap-panel-tfp410.h
@@ -27,11 +27,14 @@ struct omap_dss_device;
* @i2c_bus_num: i2c bus id for the panel
* @power_down_gpio: gpio number for PD pin (or -EINVAL if not available)
* @invert_pd_gpio: invert PD pin logic level (0 - is a power on state)
+ * @latch_on_rising_edge : select the edge (0 - falling, 1 - rising) of the input clock
+ *
[PATCH V2 0/3] Fix to clk framework while handling orphan clks
From: Ambresh K ambr...@ti.com On a possible HW bug or in-correct configuration of MUX register's in bootloader; might return a value greater than available parent clocks for a MUX clk. Sensing invalid parent index, clk_mux_get_parent returns -EINVALID. Due to function's u8 return type it will get converted into signed value, thus causing following pointer dereference on test platform. M[0.00] dra7xx_clk_init: clk init (gpu_core_gclk_mux)^M ^M[0.00] Unable to handle kernel NULL pointer dereference at virtual address ^M ^M[0.00] pgd = c0004000^M ^M[0.00] [] *pgd=^M ^M[0.00] Internal error: Oops: 5 [#1] SMP ARM^M ^M[0.00] Modules linked in:^M ^M[0.00] CPU: 0Not tainted (3.8.4-gb746a7c-dirty #59)^M ^M[0.00] PC is at strcmp+0x8/0x34^M Changes since v1: - Fixed review comments. - Fixed return type of .get_parent callback function. Ambresh K (3): clk: fix clk_mux_get_parent return's signed value clk: skip re-parenting orphan clk ARM: OMAP2+: clk: Fix return type of callbacks arch/arm/mach-omap2/clkt_clksel.c |2 +- arch/arm/mach-omap2/clkt_dpll.c |2 +- arch/arm/mach-omap2/clock.h |4 ++-- drivers/clk/clk-mux.c |2 +- drivers/clk/clk.c | 16 +++- include/linux/clk-provider.h |6 +++--- 6 files changed, 23 insertions(+), 9 deletions(-) -- 1.7.4.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
[PATCH V2 2/3] clk: skip re-parenting orphan clk
From: Ambresh K ambr...@ti.com
If clk is same as orphan clk then skip the iteration, there
by avoiding unnecessary look-up.
Signed-off-by: Ambresh K ambr...@ti.com
---
drivers/clk/clk.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 2842450..57bb94a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1633,6 +1633,10 @@ int __clk_init(struct device *dev, struct clk *clk)
* this clock
*/
hlist_for_each_entry_safe(orphan, tmp2, clk_orphan_list, child_node) {
+ /* Skip if clk is same as orphan clk */
+ if (!strcmp(clk-name, orphan-name))
+ continue;
+
if (orphan-ops-get_parent) {
i = orphan-ops-get_parent(orphan-hw);
if (i 0) {
--
1.7.4.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: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
On Mon, Jun 17, 2013 at 4:27 PM, Tony Lindgren t...@atomide.com wrote: Too quick? The basic DT based booting has been working for a few years now to some extent on omaps :) I mean it is OK to drop legacy mode now if it won't break old system. Otherwise, it is better to slow down the dropping legacy patch so that the board won't be one brick for us old board users, :-) Thanks, -- Ming Lei -- 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 V2 1/3] clk: fix clk_mux_get_parent return's signed value
From: Ambresh K ambr...@ti.com
clk_mux_get_parent should return an error if the value read
from the register is erroneous.
Currently if the value read is greater than the number of
available parents clk_mux_get_parent return's signed error
which will result in NULL pointer dereferencing in the
calling functions.
Signed-off-by: Ambresh K ambr...@ti.com
---
drivers/clk/clk-mux.c|2 +-
drivers/clk/clk.c| 12 +++-
include/linux/clk-provider.h |6 +++---
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 61c..001b4df 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -29,7 +29,7 @@
#define to_clk_mux(_hw) container_of(_hw, struct clk_mux, hw)
-static u8 clk_mux_get_parent(struct clk_hw *hw)
+static int clk_mux_get_parent(struct clk_hw *hw)
{
struct clk_mux *mux = to_clk_mux(hw);
int num_parents = __clk_get_num_parents(hw-clk);
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index edf3fe1..2842450 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1281,7 +1281,7 @@ EXPORT_SYMBOL_GPL(clk_get_parent);
static struct clk *__clk_init_parent(struct clk *clk)
{
struct clk *ret = NULL;
- u8 index;
+ int index;
/* handle the trivial cases */
@@ -1309,6 +1309,11 @@ static struct clk *__clk_init_parent(struct clk *clk)
*/
index = clk-ops-get_parent(clk-hw);
+ if (index 0) {
+ pr_err(%s: clk(%s) invalid parent index(%d)\n,
+ __func__, clk-name, index);
+ goto out;
+ }
if (!clk-parents)
clk-parents =
@@ -1630,6 +1635,11 @@ int __clk_init(struct device *dev, struct clk *clk)
hlist_for_each_entry_safe(orphan, tmp2, clk_orphan_list, child_node) {
if (orphan-ops-get_parent) {
i = orphan-ops-get_parent(orphan-hw);
+ if (i 0) {
+ pr_err_once(%s: clk(%s) has invalid parent\n,
+ __func__, orphan-name);
+ continue;
+ }
if (!strcmp(clk-name, orphan-parent_names[i]))
__clk_reparent(orphan, clk);
continue;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1ec14a7..b01cbdb 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -79,8 +79,8 @@ struct clk_hw;
* @round_rate:Given a target rate as input, returns the closest rate
actually
* supported by the clock.
*
- * @get_parent:Queries the hardware to determine the parent of a
clock. The
- * return value is a u8 which specifies the index corresponding to
+ * @get_parent:Queries the hardware to determine the parent of a
clock. The
+ * return value which specifies the index corresponding to
* the parent clock. This index can be applied to either the
* .parent_names or .parents arrays. In short, this function
* translates the parent value read from hardware into an array
@@ -127,7 +127,7 @@ struct clk_ops {
long(*round_rate)(struct clk_hw *hw, unsigned long,
unsigned long *);
int (*set_parent)(struct clk_hw *hw, u8 index);
- u8 (*get_parent)(struct clk_hw *hw);
+ int (*get_parent)(struct clk_hw *hw);
int (*set_rate)(struct clk_hw *hw, unsigned long,
unsigned long);
void(*init)(struct clk_hw *hw);
--
1.7.4.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
[PATCH V2 3/3] ARM: OMAP2+: clk: Fix return type of callbacks
From: Ambresh K ambr...@ti.com
clk_ops's .get_parent member data return's signed value.
Signed-off-by: Ambresh K ambr...@ti.com
---
arch/arm/mach-omap2/clkt_clksel.c |2 +-
arch/arm/mach-omap2/clkt_dpll.c |2 +-
arch/arm/mach-omap2/clock.h |4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_clksel.c
b/arch/arm/mach-omap2/clkt_clksel.c
index 0ec9f6f..2773657 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -303,7 +303,7 @@ u32 omap2_clksel_round_rate_div(struct clk_hw_omap *clk,
* way to return an error, so if we encounter an error, just WARN()
* and pretend that we know that we're doing.
*/
-u8 omap2_clksel_find_parent_index(struct clk_hw *hw)
+int omap2_clksel_find_parent_index(struct clk_hw *hw)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
const struct clksel *clks;
diff --git a/arch/arm/mach-omap2/clkt_dpll.c b/arch/arm/mach-omap2/clkt_dpll.c
index 924c230..54b8c49 100644
--- a/arch/arm/mach-omap2/clkt_dpll.c
+++ b/arch/arm/mach-omap2/clkt_dpll.c
@@ -186,7 +186,7 @@ static int _dpll_test_mult(int *m, int n, unsigned long
*new_rate,
}
/* Public functions */
-u8 omap2_init_dpll_parent(struct clk_hw *hw)
+int omap2_init_dpll_parent(struct clk_hw *hw)
{
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
u32 v;
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 7aa32cd..2784087 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -384,7 +384,7 @@ void __init omap2_clk_disable_clkdm_control(void);
u32 omap2_clksel_round_rate_div(struct clk_hw_omap *clk,
unsigned long target_rate,
u32 *new_div);
-u8 omap2_clksel_find_parent_index(struct clk_hw *hw);
+int omap2_clksel_find_parent_index(struct clk_hw *hw);
unsigned long omap2_clksel_recalc(struct clk_hw *hw, unsigned long
parent_rate);
long omap2_clksel_round_rate(struct clk_hw *hw, unsigned long target_rate,
unsigned long *parent_rate);
@@ -396,7 +396,7 @@ int omap2_clksel_set_parent(struct clk_hw *hw, u8
field_val);
extern void omap2_clkt_iclk_allow_idle(struct clk_hw_omap *clk);
extern void omap2_clkt_iclk_deny_idle(struct clk_hw_omap *clk);
-u8 omap2_init_dpll_parent(struct clk_hw *hw);
+int omap2_init_dpll_parent(struct clk_hw *hw);
unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk);
int omap2_dflt_clk_enable(struct clk_hw *hw);
--
1.7.4.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: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
* Ming Lei tom.leim...@gmail.com [130617 01:47]: On Mon, Jun 17, 2013 at 4:27 PM, Tony Lindgren t...@atomide.com wrote: Too quick? The basic DT based booting has been working for a few years now to some extent on omaps :) I mean it is OK to drop legacy mode now if it won't break old system. Otherwise, it is better to slow down the dropping legacy patch so that the board won't be one brick for us old board users, :-) Right, the plan is be able to use it naturally. The USB auxclk issue is fixable for DT boot, we just need to decide what's the best way to fix it. Regards, 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
Re: [PATCH] gpio: Enable pcf857x GPIO expander for Device Tree
On Thu, Jun 6, 2013 at 4:05 PM, Archit Taneja arc...@ti.com wrote: Add code to parse the GPIO expander Device Tree node and extract platform data out of it, and populate the struct 'pcf857x_platform_data' maintained by the driver. This enables devices to reference the gpio expander from Device Tree. Add DT binding info in Documentation. CC: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Archit Taneja arc...@ti.com (...) +++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt @@ -0,0 +1,44 @@ +PCF857x I2C based GPIO controller bindings + +Required properties: +- compatible: + - nxp,pca9670 for NXP PCA9670 8 bit I/O expander + - nxp,pca9672 for NXP PCA9672 8 bit I/O expander with interrupt + - nxp,pca9674 for NXP PCA9672 8 bit I/O expander with interrupt + - nxp,pca8574 for NXP PCA8574 8 bit I/O expander with interrupt + - nxp,pca8575 for NXP PCA8575 16 bit I/O expander with interrupt + - nxp,pca9671 for NXP PCA9671 16 bit I/O expander + - nxp,pca9673 for NXP PCA9673 16 bit I/O expander with interrupt + - nxp,pca9675 for NXP PCA9675 16 bit I/O expander with interrupt + - ti,pcf8574 for TI PCF8574 8 bit I/O expander with interrupt + - ti,pcf8574a for TI PCF8574A 8 bit I/O expander with interrupt + - ti,pcf8575 for TI PCF8575 16 bit I/O expander with interrupt + - ti,tca9554 for TI TCA9554 8 bit I/O expander with interrupt + - maxim,max7328 for MAXIM MAX7328 8 bit I/O expander with interrupt + - maxim,max7329 for MAXIM MAX7329 8 bit I/O expander with interrupt +- gpio-controller : Marks the device node as a GPIO controller. +- #gpio-cells : Should be two. + - first cell is the pin number. + - second cell is unused. I guess you're adding this because the generic GPIO bindings use it and of_gpio_simple_xlate() depends on this two-cell layout. Make a reference to the generic GPIO bindings and note that the second cell is *NOT* unused, as it is used in the GPIOlib! +- interrupt-controller: Mark the device node as an interrupt controller. +- #interrupt-cells : Should be two. + - first cell is the GPIO number. Surely it is the IRQ number and not the GPIO number. The fact that the IRQ originates in a GPIO controller does not matter. + - second cell is unused. So why do you add it? Usually this is used for trigger flags. Are you planning to add this later, i.e. does the chip support this, and if it doesn't then get rid of this flag. +- reg: I2C address of the chip. + +Device speific properties: +- n_latch: optional bit-inverse of initial register value; if + you leave this initialized to zero the driver will act + like the chip was just reset. Explain what happens if you do *not* leave it as zero and what the bits mean in that case. 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 v3 1/2] spi: omap2-mcspi: Move bytes per word calculation to the function
On Fri, Jun 14, 2013 at 07:12:07PM +0300, Illia Smyrnov wrote: Introduce mcspi_bytes_per_word function as replacement for the next code fragment: Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v3 2/2] spi: omap2-mcspi: Add FIFO buffer support
On Fri, Jun 14, 2013 at 07:12:08PM +0300, Illia Smyrnov wrote: The MCSPI controller has a built-in FIFO buffer to unload the DMA or interrupt handler and improve data throughput. This patch adds FIFO buffer support for SPI transfers in DMA mode. This looks good but doesn't apply against my topic/omap branch - can you please check and resend? Probably something that applies against -next will be fine. signature.asc Description: Digital signature
Re: [PATCH 2/6] ARM: OMAP2+: Remove board-omap4panda.c
Tony Lindgren t...@atomide.com writes: Hi, * Arnaud Patard arnaud.pat...@rtp-net.org [130617 01:13]: I hoped to have missed some mails and that people were testing pandabard support with full support but given what I see, the ethernet support is not there yet. This thread is about removing the non-DT boot. I see some contradiction here. Please, look again at what Thomas said in the IGEP thread: breaking existing support is bad and removing non-DT boot for panda with not-working ethernet would exactly to that. Hmm yes I guess the panda needs the aux clock and there are various patches posted for that for quite a while but have not gotten merged. yes, it needs aux clock, see: https://lkml.org/lkml/2013/4/19/124 When I did my patches it seemed that Nishant's and my solution for getting the auxclk via DT was acceptable. Then Mike started doing all the clocks in DT and things changed. Mike, got any solution for us for v3.11 for the DT defined auxclk? Yeah, I'm aware that some extra patches are being developped like the omap clocks one: https://patchwork.kernel.org/patch/2541331/ but they don't seem to be in -next. So, again, please, wait that all needed bits are merged mainline before killing non-DT support (or provide 'mixed' support like what is/was done on kirkwood) The ethernet issue can be fixed with the legacy mode support in the worst case, but probably just adding a clock alias for it does the trick. I'd rather not postpone making omap4 DT only because I think at this point fixing the any DT related issues is way less work compared to maintaining and testing both legacy boot and DT boot. I understand your concerns but, please, cope with reality: the clock work is not in -next so this tends to make me think it won't reach 3.11. We're at -rc6 after all. Telling users that their system doesn't have any network because it was easier to maintain, is not something they will understand imho. Regards, Arnaud -- 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 v7 0/9] Generic PHY Framework
Hi, On 06/13/2013 10:43 AM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on linux mainline tree. Changes from v6 * corrected few typos in Documentation * Changed PHY Subsystem to *bool* in Kconfig (to avoid compilation errors when PHY Subsystem is kept as module and the dependent modules are built-in) * Added if pm_runtime_enabled check before runtime pm calls. Looks good, feel free to add: Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com for patches 1...3/9, 5...7/9 and Tested-by: Sylwester Nawrocki s.nawro...@samsung.com for patch 1/9 Hopefully we can gather more Acks and merge it for 3.11. I have already used this API for our MIPI CSI-2/DSIM DPHYs driver, the RFC patch series can be found at [1]. Thanks, Sylwester [1] http://www.spinics.net/lists/arm-kernel/msg251666.html -- 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/6] ARM: OMAP2+: Remove board-omap4panda.c
* Arnaud Patard arnaud.pat...@rtp-net.org [130617 02:52]: Tony Lindgren t...@atomide.com writes: I understand your concerns but, please, cope with reality: the clock work is not in -next so this tends to make me think it won't reach 3.11. We're at -rc6 after all. Telling users that their system doesn't have any network because it was easier to maintain, is not something they will understand imho. Right, like I said: the idea is to have it usable with DT. And USB and Ethernet certainly are part of what I call usable. So is MMC, WLAN and DSS. I've certainly spent quite a bit of time on making sure panda works with DT, and I can assure you that fixing the USB extclock is easier than supporting the legacy boot with DT :) This issue can also be fixed with a clock alias if we don't have DT defined clocks ready for v3.11. It may take a few days for us to have the solution. But get getting a clock to a driver certainly is not a showstopper here. After all, that's what all drivers already do. Regards, 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
Re: [GIT PULL 2/6] omap cleanup for v3.11 merge window
* Olof Johansson o...@lixom.net [130614 14:34]: On Wed, Jun 12, 2013 at 11:24:33AM -0700, Tony Lindgren wrote: The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e: Linux 3.10-rc4 (2013-06-02 17:11:17 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/cleanup-signed for you to fetch changes up to 09182ab11b49b67d04598b19eb89cf0bbd672a60: ARM: OMAP4: hwmod data: Remove irq entries from mcspi, mmc hwmods (2013-06-12 09:41:46 -0700) Move omap4 over to device tree based booting. This allows us to get rid a big pile of platform init code for things that are already handled by device tree related code. As am33xx is already device tree based, we can also remove the same data for am33xx. Hm. This one has a somewhat silly conflict with the am33xx hwmod fix for uart2. I.e. the fix is reverted since the code is no longer needed -- data comes from device tree. Please double-check my merge resolution on it though. Thanks yes that should not be needed any longer in the hwmod data. Regards, 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
Re: [GIT PULL 6/6] omap5 data for v3.11 merge window
* Olof Johansson o...@lixom.net [130614 14:42]: On Wed, Jun 12, 2013 at 11:24:35AM -0700, Tony Lindgren wrote: The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10: Linux 3.10-rc5 (2013-06-08 17:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/omap5-signed for you to fetch changes up to 6503a8e109a639760408f874c1251060d563942e: ARM: OMAP5: Remove unused include for ocp2scp (2013-06-09 21:17:15 -0700) Pulled. Thanks. 25 files changed, 8982 insertions(+), 55 deletions(-) Owwie. This is already the squeezed down version with irq and dma data left out like we also did for am33xx and omap4. Unfortunately getting things moved to DT and to live under drivers will take a while, and we decided to deal with moving clocks to drivers first so hwmod will have to wait a bit. Regards, 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
Re: [GIT PULL] move omap mailbox to drivers for v3.11
* Suman Anna s-a...@ti.com [130613 08:09]: On 06/12/2013 08:37 PM, Felipe Balbi wrote: Hi, On Wed, Jun 12, 2013 at 04:58:26PM -0500, Suman Anna wrote: The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10: Linux 3.10-rc5 (2013-06-08 17:41:04 -0700) are available in the git repository at: g...@github.com:sumananna/mailbox.git tags/omap-mailbox-for-v3.11 Tony might not have an ssh account on github, when sending pull requests make sure to use the git read-only URL. Thanks for the tip, Felipe. Tony, please use git://github.com/sumananna/mailbox.git tags/omap-mailbox-for-v3.11 Thanks, pulling into omap-for-v3.11/mailbox. Regards, 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
Re: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree binding
Grant, Rob, Can one of you please take a look at this patch and see if you have any comments on the binding definition? Joel, Ideally the bindings are described before they are used or along with its usage. In that aspect, this patch is present too far back in the series. Can you please fix this if you get to posting another version. I think I gave the same comment on v9 as well. On 6/15/2013 8:02 AM, Joel A Fernandes wrote: From: Matt Porter m...@ti.com The binding definition is based on the generic DMA controller binding. Joel: Droped reserved and queue DT entries from Documentation for now from the original patch series. Signed-off-by: Matt Porter mpor...@ti.com Signed-off-by: Joel A Fernandes joelag...@ti.com --- Documentation/devicetree/bindings/dma/ti-edma.txt | 26 + 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt new file mode 100644 index 000..ada0018 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -0,0 +1,26 @@ +TI EDMA + +Required properties: +- compatible : ti,edma3 +- ti,hwmods: Name of the hwmods associated to the EDMA ti,hwmods should be optional, no? hwmod is not present on DaVinci where EDMA is also used. If it is not optional then these bindings wont work there. Thanks, Sekhar -- 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: [GIT PULL] OMAP: PM: remove OMAP-specific no_console_suspend handling
* Kevin Hilman khil...@linaro.org [130613 15:18]: Tony, Please pull this OMAP PM cleanup for v3.11. Thanks, Kevin The following changes since commit f722406faae2d073cc1d01063d1123c35425939e: Linux 3.10-rc1 (2013-05-11 17:14:08 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.11/cleanup/pm for you to fetch changes up to 4b7ec5accecdb136c7afaf8739a06d5335cc05aa: arm: omap2+: omap_device: remove no_idle_on_suspend (2013-05-16 07:09:09 -0700) OMAP: PM: the serial core + driver can no handle no_console_suspend support without any SoC specific handlding or SoC-specific DT bindings. Remove the now unused SoC specifics for OMAP. Thanks pulling into omap-for-v3.11/pm-serial. Regards, 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
Re: N900 device tree conversion: how to do first step
* Pavel Machek pa...@ucw.cz [130614 14:34]: * Pavel Machek pa...@ucw.cz [130613 16:14]: No, there really are two instances of mux registers even on omap3, but I missed that earlier while reading the docs, and with the legacy mux framework it does not matter which mux domain it is. But it matters for pinctrl-single as it ioremaps the ranges separately. Yes, you are right, with debugging prints it was easy to fix. OK cool. This is not a good way of doing muxing, hogging all the pins under omap3_pmx_core will make it impossible to unload pinctrl-single as a module, which is not nice for distros and developers. Does omap4 do it correctly? I don't see how that works :-(. Just group the pins for each device using them. You can do: $ grep hsmmc1 /sys/kernel/debug/omap_mux/board/core And then you get the mmc1 pin settings that you can place under mmc1 entry in your board specific .dts file. Anyway... here's my current version, and thanks for all the help. I guess I'll need to figure out clocks next, because I'd really like to have video going on device. Well DSS is still using pdata based init because of the DT bindings are not ready yet. Regards, 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
Re: OMAP4 Panda DVI problem
* Roger Quadros rog...@ti.com [130617 01:18]: Hi Tomi, On 06/14/2013 04:52 PM, Tomi Valkeinen wrote: Hi Tony, Roger, I recently raised the i2c issue with reading EDID from a DVI monitor on Panda, when booting with DT. I just couldn't get reading EDID work at all reliably. I now see problems with non-DT also. Booting with 3.10-rc5, with DSS compiled into the kernel, reading EDID fails during the boot. I can later read the EDID fine from userspace. With help from Roger, we found the issue. DVI cable has a +5V line, that the source (i.e. Panda) has to provide. This +5V is required to read EDID, but according to the documentation I think it's actually required to show video also (although I guess this could depend on the monitor). I think for OMAP3 boards the +5V is always-on (I haven't looked at OMAP3 boards yet, though). For Panda, the +5V comes from DC_HST_5V, controlled with a GPIO, which is used for USB and currently managed by USB in arch/arm/mach-omap2/usb-host.c, which creates a fixed voltage hsusbX_vcc regulator. So, basically, if USB is disabled, DVI doesn't work. This is why I see problems with DT (no USB), and non-DT (USB enabled after DVI is enabled). To fix this properly I need to add regulator handling to the DVI driver, and we need to share the same supply with USB and DVI. However, while the above shouldn't be particularly difficult, it's still not simple. And additional complications come with DT boot, as DSS doesn't support DT yet. We have the hack that enables DSS for Panda and SDP board when booting with DT, but I don't think it's possible to manage the shared regulator easily in that setup (ie. USB and the regulator being described in DT, DSS and DVI added the old way in dss-common.c). You should be able to get the regulator based on the name just fine from the drivers even if one driver is using DT and one is not. That is as long as the regulator is defined. Then the regulator fwk will track the usecount properly. So I think the simplest solution is to make DC_HST_5V always-on. This should be fixed for 3.10 also. I am fine with this. For a short term fix I'm fine with that, but please investigate using the regulator, it might be simpler than you think. Any idea if DC_HST_5V is a big power sink if it's always enabled? If it's a big one, I could look at how to hack the DVI driver so that it would find the regulator. I'm quite sure I won't be neat, though. DC_HST_5V is going to be active if USB is active. So I wouldn't be much worried if this supply is left always ON for people needing USB host ethernet. (NOTE, ethernet is part of the same USB hub chip) Of course power management will suffer, but it's currently not working with EHCI anyways AFAIK. Regards, 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
Re: OMAP4 Panda DVI problem
On 17/06/13 14:18, Tony Lindgren wrote: You should be able to get the regulator based on the name just fine from the drivers even if one driver is using DT and one is not. That is as long as the regulator is defined. Then the regulator fwk will track the usecount properly. Doesn't the regulator need to be bound to a device for the driver to use the proper name for the regulator? I mean, in this case the dvi driver wants to get a regulator named vdd_5v (or something like that, I'm not sure what's the proper name). The USB host driver uses a name vcc, while the real name of the regulator is hsusbX_vcc. If DVI driver wanted to use the regulator, it'd need to get hsusbX_vcc. Which, I presume, would work, but is board specific and hacky, and it makes handling EPROBE_DEFER a bit more difficult. Then again, maybe that's still simpler than making the regulator always-on, as there are complications with that approach also, which we are currently studying. So I think the simplest solution is to make DC_HST_5V always-on. This should be fixed for 3.10 also. I am fine with this. For a short term fix I'm fine with that, but please investigate using the regulator, it might be simpler than you think. I'll have a look, maybe there's something I'm missing. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP4 Panda DVI problem
* Tomi Valkeinen tomi.valkei...@ti.com [130617 04:34]: On 17/06/13 14:18, Tony Lindgren wrote: You should be able to get the regulator based on the name just fine from the drivers even if one driver is using DT and one is not. That is as long as the regulator is defined. Then the regulator fwk will track the usecount properly. Doesn't the regulator need to be bound to a device for the driver to use the proper name for the regulator? I mean, in this case the dvi driver wants to get a regulator named vdd_5v (or something like that, I'm not sure what's the proper name). The USB host driver uses a name vcc, while the real name of the regulator is hsusbX_vcc. I think that's for looking up regulators based on the dev entry, and also name based lookup should work. But maybe I'm confusing it with the clock framework. If you need to bind it to a device, you can do that too dynamically I'd assume. If DVI driver wanted to use the regulator, it'd need to get hsusbX_vcc. Which, I presume, would work, but is board specific and hacky, and it makes handling EPROBE_DEFER a bit more difficult. Then again, maybe that's still simpler than making the regulator always-on, as there are complications with that approach also, which we are currently studying. So I think the simplest solution is to make DC_HST_5V always-on. This should be fixed for 3.10 also. I am fine with this. For a short term fix I'm fine with that, but please investigate using the regulator, it might be simpler than you think. I'll have a look, maybe there's something I'm missing. Yes might be worth checking. Regards, 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
Re: OMAP4 Panda DVI problem
On 06/17/2013 02:27 PM, Tomi Valkeinen wrote: On 17/06/13 14:18, Tony Lindgren wrote: You should be able to get the regulator based on the name just fine from the drivers even if one driver is using DT and one is not. That is as long as the regulator is defined. Then the regulator fwk will track the usecount properly. Doesn't the regulator need to be bound to a device for the driver to use the proper name for the regulator? I mean, in this case the dvi driver wants to get a regulator named vdd_5v (or something like that, I'm not sure what's the proper name). The USB host driver uses a name vcc, while the real name of the regulator is hsusbX_vcc. Right. I think if the regulator is not bound to any device then you can get it just by supply name. http://lxr.free-electrons.com/source/drivers/regulator/core.c#L1175 But the USB PHY driver will always try to get the regulator for it's device that has supply name vcc. cheers, -roger -- 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 01/22] mfd/ti_am335x_tscadc: remove regmap
On 06/14/2013 03:53 PM, Mark Brown wrote: On Tue, Jun 11, 2013 at 04:34:53PM +0200, Sebastian Andrzej Siewior wrote: It does give you tracepoints and debugfs. If it's making things at all complicated we need to look at why that is and figure out how to fix that since it's probably an issue for other users. debugfs are tracepoints is our offer? Let me check the price one more time. A simply mmio read does right now: - lock + unlock. each time you chase another pointer plus enable/disable interrupts plus you have to save flags in another structure. - _regmap_read() We check a few variables and then we go after reg_read and we end up in _regmap_raw_read(). Here we call _regmap_range_lookup() which should return NULL. Next thing we invoke map-format.format_reg(). Finally we can call map-bus-read() which brings us to regmap_mmio_read(). At the end we invoke map-format.parse_val(). write looks most likely the same. A simple register read invokes 5 functions pointers. I am not counting the function arguments in between and I am also not counting the number of arguments which are involved and take pointer as well. This is a lot of stuff that is done for a simple read of an mmio. I understand that most of this may not be expensive in total if it comes to SPI or I2C and all the goodies like reg caching and one interface which deals with SPI and I2C. I also understand that some chips have a non standard interface and are either BE or LE. We have similar things on USB where people wired the BUS wrongly either at the BUS level or at the SoC level so some PowerPC have an in-core ehci controller but its registers are BE and not LE like it should be. The solution here was variable check a simple swap() in that case. I like abstractions but this gone a little too far I think. This is a lot of for a simple mmio access. In terms of performance: If I add a trace point to my read and write I have still less code which is called and it can be disabled. This regmap overhead is always there chasing pointers. As I said before: I doubt that you get this regmap access in an one GiB network driver and in turn remove their trace points to register access. Please don't get me wrong: It is still nice for slow buses and this ADC driver isn't anything close to high performance like a 1GiB network driver but it adds a lot of unwanted overhead which I prefer not to have. Sebastian -- 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] gpio: Enable pcf857x GPIO expander for Device Tree
Hi,
On Monday 17 June 2013 02:35 PM, Linus Walleij wrote:
On Thu, Jun 6, 2013 at 4:05 PM, Archit Taneja arc...@ti.com wrote:
Add code to parse the GPIO expander Device Tree node and extract platform data
out of it, and populate the struct 'pcf857x_platform_data' maintained by the
driver. This enables devices to reference the gpio expander from Device Tree.
Add DT binding info in Documentation.
CC: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Archit Taneja arc...@ti.com
(...)
+++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
@@ -0,0 +1,44 @@
+PCF857x I2C based GPIO controller bindings
+
+Required properties:
+- compatible:
+ - nxp,pca9670 for NXP PCA9670 8 bit I/O expander
+ - nxp,pca9672 for NXP PCA9672 8 bit I/O expander with interrupt
+ - nxp,pca9674 for NXP PCA9672 8 bit I/O expander with interrupt
+ - nxp,pca8574 for NXP PCA8574 8 bit I/O expander with interrupt
+ - nxp,pca8575 for NXP PCA8575 16 bit I/O expander with interrupt
+ - nxp,pca9671 for NXP PCA9671 16 bit I/O expander
+ - nxp,pca9673 for NXP PCA9673 16 bit I/O expander with interrupt
+ - nxp,pca9675 for NXP PCA9675 16 bit I/O expander with interrupt
+ - ti,pcf8574 for TI PCF8574 8 bit I/O expander with interrupt
+ - ti,pcf8574a for TI PCF8574A 8 bit I/O expander with interrupt
+ - ti,pcf8575 for TI PCF8575 16 bit I/O expander with interrupt
+ - ti,tca9554 for TI TCA9554 8 bit I/O expander with interrupt
+ - maxim,max7328 for MAXIM MAX7328 8 bit I/O expander with interrupt
+ - maxim,max7329 for MAXIM MAX7329 8 bit I/O expander with interrupt
+- gpio-controller : Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two.
+ - first cell is the pin number.
+ - second cell is unused.
I guess you're adding this because the generic GPIO bindings use it and
of_gpio_simple_xlate() depends on this two-cell layout.
Thanks for the review. I'm new to this and clearly lacking some
knowledge here.
Make a reference to the generic GPIO bindings and note that the
second cell is *NOT* unused, as it is used in the GPIOlib!
Right, my mistake. Just a query, there is an example in gpio.txt in the
gpio bindings documentation which sets #gpio-cells as 1. Is this is a
wrong example, or are 1 cell gpio controllers valid?
+- interrupt-controller: Mark the device node as an interrupt controller.
+- #interrupt-cells : Should be two.
+ - first cell is the GPIO number.
Surely it is the IRQ number and not the GPIO number.
The fact that the IRQ originates in a GPIO controller does not
matter.
Okay, I took gpio-omap.txt as reference(in other words, copy-pasted from
there), I guess 'first cell is the GPIO number' means that a slave
having it's interrupt line connected to an omap gpio bank has to mention
the gpio number in the first cell.
About this chip, a change in any of it's GPIOs configured as inputs will
generate an interrupt, then it's up to the driver to figure out which
GPIOs changed and handle their corresponding irqs. So shouldn't a device
connected to the chip describe the gpio number within the pcf857x chip
as it's first cell?
I've made a hypothetical example of a pcf8575 chip, which has it's
interrupt line connected to an omap gpio, and pcf8575's 7th gpio is
connected to 'pcf_slave'. The pcf_slave's driver requests for an
interrupt. Is this the correct way to describe this? :
pcf: pcf8575@23 {
compatible = ti,pcf8575;
reg = 0x23;
gpio-controller;
#gpio-cells = 2;
#interrupt-controller;
#interrupt-cells = 1;
interrupt-parent = gpio2; /* an omap gpio bank */
interrupts = 2 8; /* gpio line 34, low triggered*/
};
pcf_slave: slave {
...
...
#interrupt-parent = pcf;
interrupts = 7; /* connected to 7th IO pin of pcf857x*/
};
+ - second cell is unused.
So why do you add it? Usually this is used for trigger flags.
Are you planning to add this later, i.e. does the chip support this,
and if it doesn't then get rid of this flag.
I haven't used the chip for interrupts, but going through the driver and
it's platform_data struct for board files, I don't see any trigger
information needed. I'll remove it.
+- reg: I2C address of the chip.
+
+Device speific properties:
+- n_latch: optional bit-inverse of initial register value; if
+ you leave this initialized to zero the driver will act
+ like the chip was just reset.
Explain what happens if you do *not* leave it as zero and what the
bits mean in that case.
I'll do that. Apologies for the trivial issues.
Thanks,
Archit
--
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 v2] mfd: Palmas: Remove code which is not necessary for a device tree boot
Remove code which is not necessary for a device tree boot.
Boot tested on OMAP5-UEVM board.
Signed-off-by: J Keerthy j-keer...@ti.com
Acked-by: Laxman Dewangan ldewan...@nvidia.com
Acked-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/mfd/palmas.c | 106 --
1 files changed, 0 insertions(+), 106 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 53e9fe6..62fa728 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -25,77 +25,6 @@
#include linux/mfd/palmas.h
#include linux/of_platform.h
-enum palmas_ids {
- PALMAS_PMIC_ID,
- PALMAS_GPIO_ID,
- PALMAS_LEDS_ID,
- PALMAS_WDT_ID,
- PALMAS_RTC_ID,
- PALMAS_PWRBUTTON_ID,
- PALMAS_GPADC_ID,
- PALMAS_RESOURCE_ID,
- PALMAS_CLK_ID,
- PALMAS_PWM_ID,
- PALMAS_USB_ID,
-};
-
-static struct resource palmas_rtc_resources[] = {
- {
- .start = PALMAS_RTC_ALARM_IRQ,
- .end= PALMAS_RTC_ALARM_IRQ,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static const struct mfd_cell palmas_children[] = {
- {
- .name = palmas-pmic,
- .id = PALMAS_PMIC_ID,
- },
- {
- .name = palmas-gpio,
- .id = PALMAS_GPIO_ID,
- },
- {
- .name = palmas-leds,
- .id = PALMAS_LEDS_ID,
- },
- {
- .name = palmas-wdt,
- .id = PALMAS_WDT_ID,
- },
- {
- .name = palmas-rtc,
- .id = PALMAS_RTC_ID,
- .resources = palmas_rtc_resources[0],
- .num_resources = ARRAY_SIZE(palmas_rtc_resources),
- },
- {
- .name = palmas-pwrbutton,
- .id = PALMAS_PWRBUTTON_ID,
- },
- {
- .name = palmas-gpadc,
- .id = PALMAS_GPADC_ID,
- },
- {
- .name = palmas-resource,
- .id = PALMAS_RESOURCE_ID,
- },
- {
- .name = palmas-clk,
- .id = PALMAS_CLK_ID,
- },
- {
- .name = palmas-pwm,
- .id = PALMAS_PWM_ID,
- },
- {
- .name = palmas-usb,
- .id = PALMAS_USB_ID,
- }
-};
-
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
{
.reg_bits = 8,
@@ -311,7 +240,6 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
int ret = 0, i;
unsigned int reg, addr;
int slave;
- struct mfd_cell *children;
pdata = dev_get_platdata(i2c-dev);
@@ -472,42 +400,8 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
return ret;
}
- children = kmemdup(palmas_children, sizeof(palmas_children),
- GFP_KERNEL);
- if (!children) {
- ret = -ENOMEM;
- goto err_irq;
- }
-
- children[PALMAS_PMIC_ID].platform_data = pdata-pmic_pdata;
- children[PALMAS_PMIC_ID].pdata_size = sizeof(*pdata-pmic_pdata);
-
- children[PALMAS_GPADC_ID].platform_data = pdata-gpadc_pdata;
- children[PALMAS_GPADC_ID].pdata_size = sizeof(*pdata-gpadc_pdata);
-
- children[PALMAS_RESOURCE_ID].platform_data = pdata-resource_pdata;
- children[PALMAS_RESOURCE_ID].pdata_size =
- sizeof(*pdata-resource_pdata);
-
- children[PALMAS_USB_ID].platform_data = pdata-usb_pdata;
- children[PALMAS_USB_ID].pdata_size = sizeof(*pdata-usb_pdata);
-
- children[PALMAS_CLK_ID].platform_data = pdata-clk_pdata;
- children[PALMAS_CLK_ID].pdata_size = sizeof(*pdata-clk_pdata);
-
- ret = mfd_add_devices(palmas-dev, -1,
- children, ARRAY_SIZE(palmas_children),
- NULL, 0,
- regmap_irq_get_domain(palmas-irq_data));
- kfree(children);
-
- if (ret 0)
- goto err_devices;
-
return ret;
-err_devices:
- mfd_remove_devices(palmas-dev);
err_irq:
regmap_del_irq_chip(palmas-irq, palmas-irq_data);
err:
--
1.7.5.4
--
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 3/4] MFD: Palmas: Add SMPS10_BOOST feature
The SMPS10 regulator is not presesnt in all the variants of the PALMAS PMIC family. Hence adding a feature to distingush between them. Signed-off-by: J Keerthy j-keer...@ti.com --- drivers/mfd/palmas.c |3 ++- drivers/regulator/palmas-regulator.c |3 +++ include/linux/mfd/palmas.h |4 3 files changed, 9 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c index 261beb5..ad00c18 100644 --- a/drivers/mfd/palmas.c +++ b/drivers/mfd/palmas.c @@ -231,7 +231,8 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c, palmas_set_pdata_irq_flag(i2c, pdata); } -static unsigned int palmas_features = PALMAS_PMIC_FEATURE_INTERRUPT; +static unsigned int palmas_features = PALMAS_PMIC_FEATURE_INTERRUPT | + PALMAS_PMIC_FEATURE_SMPS10_BOOST; static unsigned int tps659038_features; diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c index 3ae44ac..1ae1e83 100644 --- a/drivers/regulator/palmas-regulator.c +++ b/drivers/regulator/palmas-regulator.c @@ -838,6 +838,9 @@ static int palmas_regulators_probe(struct platform_device *pdev) continue; ramp_delay_support = true; break; + case PALMAS_REG_SMPS10: + if (!PALMAS_PMIC_HAS(palmas, SMPS10_BOOST)) + continue; } if ((id == PALMAS_REG_SMPS6) || (id == PALMAS_REG_SMPS8)) diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h index 1b5b5f3..2a9f4d6 100644 --- a/include/linux/mfd/palmas.h +++ b/include/linux/mfd/palmas.h @@ -38,10 +38,14 @@ * PALMAS_PMIC_FEATURE_INTERRUPT - used when the PMIC has Interrupt line going * to an application processor. * + * PALMAS_PMIC_FEATURE_SMPS10_BOOST - used when the PMIC provides SMPS10 boost + * voltage supply. + * * PALMAS_PMIC_HAS(b, f) - macro to check if a bandgap device is capable of a * specific feature (above) or not. Return non-zero, if yes. */ #define PALMAS_PMIC_FEATURE_INTERRUPT BIT(0) +#define PALMAS_PMIC_FEATURE_SMPS10_BOOST BIT(1) #define PALMAS_PMIC_HAS(b, f) \ ((b)-features PALMAS_PMIC_FEATURE_ ## f) -- 1.7.5.4 -- 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 v10 5/8] dmaengine: edma: Add TI EDMA device tree binding
On Friday 14 June 2013 21:32:47 Joel A Fernandes wrote: diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt new file mode 100644 index 000..ada0018 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -0,0 +1,26 @@ +TI EDMA + +Required properties: +- compatible : ti,edma3 +- ti,hwmods: Name of the hwmods associated to the EDMA +- ti,edma-regions: Number of regions +- ti,edma-slots: Number of slots + +Optional properties: +- ti,edma-xbar-event-map: Crossbar event to channel map You need to list #dma-cells as required here, and which values are accepted by the driver (I suppose only 1). You should also explain the format of the dma-specifier for a slave here for each possible value of #dma-cells. For each of the standard properties (reg, interrupts, dma-channels), list whether they are optional or required. Since the example has three interrupts, you should probably list how many interrupts need to be specified (minimum and maximum if the number is variable) and in what order to expect them. Arnd -- 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/4] MFD: Palmas: Add Interrupt feature
Palmas PMICs have an INT line. This line is one single
Interrupt line to the application processor. The interrupt
feature enables to selectively request irq for only those
specific chips which have INT line connected to a valid
IRQ line of the application processor.
Signed-off-by: J Keerthy j-keer...@ti.com
---
drivers/mfd/palmas.c | 32 +---
include/linux/mfd/palmas.h | 14 ++
2 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 62fa728..d06ce62 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -231,6 +231,16 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
palmas_set_pdata_irq_flag(i2c, pdata);
}
+static unsigned int palmas_features = PALMAS_PMIC_FEATURE_INTERRUPT;
+
+static const struct of_device_id of_palmas_match_tbl[] = {
+ {
+ .compatible = ti,palmas,
+ .data = palmas_features,
+ },
+ { },
+};
+
static int palmas_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
@@ -238,8 +248,9 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
struct palmas_platform_data *pdata;
struct device_node *node = i2c-dev.of_node;
int ret = 0, i;
- unsigned int reg, addr;
+ unsigned int reg, addr, *features;
int slave;
+ const struct of_device_id *match;
pdata = dev_get_platdata(i2c-dev);
@@ -261,9 +272,17 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
i2c_set_clientdata(i2c, palmas);
palmas-dev = i2c-dev;
- palmas-id = id-driver_data;
palmas-irq = i2c-irq;
+ match = of_match_device(of_match_ptr(of_palmas_match_tbl), i2c-dev);
+
+ if (match) {
+ features = (unsigned int *)match-data;
+ palmas-features = *features;
+ } else {
+ return -ENODATA;
+ }
+
for (i = 0; i PALMAS_NUM_CLIENTS; i++) {
if (i == 0)
palmas-i2c_clients[i] = i2c;
@@ -290,6 +309,9 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
}
}
+ if (!PALMAS_PMIC_HAS(palmas, INTERRUPT))
+ goto no_int;
+
/* Change interrupt line output polarity */
if (pdata-irq_flags IRQ_TYPE_LEVEL_HIGH)
reg = PALMAS_POLARITY_CTRL_INT_POLARITY;
@@ -316,6 +338,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (ret 0)
goto err;
+no_int:
slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE);
addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE,
PALMAS_PRIMARY_SECONDARY_PAD1);
@@ -427,11 +450,6 @@ static const struct i2c_device_id palmas_i2c_id[] = {
};
MODULE_DEVICE_TABLE(i2c, palmas_i2c_id);
-static struct of_device_id of_palmas_match_tbl[] = {
- { .compatible = ti,palmas, },
- { /* end */ }
-};
-
static struct i2c_driver palmas_i2c_driver = {
.driver = {
.name = palmas,
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 8f21daf..1b5b5f3 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -32,6 +32,19 @@
((a) == PALMAS_CHIP_ID))
#define is_palmas_charger(a) ((a) == PALMAS_CHIP_CHARGER_ID)
+/**
+ * DOC: Palmas PMIC feature types
+ *
+ * PALMAS_PMIC_FEATURE_INTERRUPT - used when the PMIC has Interrupt line going
+ * to an application processor.
+ *
+ * PALMAS_PMIC_HAS(b, f) - macro to check if a bandgap device is capable of a
+ * specific feature (above) or not. Return non-zero, if yes.
+ */
+#define PALMAS_PMIC_FEATURE_INTERRUPT BIT(0)
+#define PALMAS_PMIC_HAS(b, f) \
+ ((b)-features PALMAS_PMIC_FEATURE_ ## f)
+
struct palmas_pmic;
struct palmas_gpadc;
struct palmas_resource;
@@ -46,6 +59,7 @@ struct palmas {
/* Stored chip id */
int id;
+ unsigned int features;
/* IRQ Data */
int irq;
u32 irq_mask;
--
1.7.5.4
--
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 4/4] regulator: Palmas: Add TPS659038 support
Signed-off-by: J Keerthy j-keer...@ti.com
---
.../devicetree/bindings/regulator/palmas-pmic.txt |1 +
drivers/regulator/palmas-regulator.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index d5a3086..5115cd7 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -7,6 +7,7 @@ Required properties:
ti,twl6037-pmic
ti,tps65913-pmic
ti,tps65914-pmic
+ ti,tps659038-pmic
and also the generic series names
ti,palmas-pmic
- interrupt-parent : The parent interrupt controller which is palmas.
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 1ae1e83..d0c8785 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -1054,6 +1054,7 @@ static struct of_device_id of_palmas_match_tbl[] = {
{ .compatible = ti,tps65913-pmic, },
{ .compatible = ti,tps65914-pmic, },
{ .compatible = ti,tps80036-pmic, },
+ { .compatible = ti,tps659038-pmic, },
{ /* end */ }
};
--
1.7.5.4
--
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 0/4] MFD: Palmas: Add TPS659038 PMIC to supported devices of Palmas
The Patch series adds TPS659038 PMIC support in the palmas mfd/voltage driver. The TPS659038 has almost the same registers as of the earlier supported variants of PALMAS family such as the TWL6035. The critical differences between TPS659038 and TWL6035 being: 1) TPS659038 has nothing related to battery charging and back up battery stuff. 2) TPS659038 does not have does not have SMPS10(Boost) step up convertor. 3) TPS659038 does not have Battery detection and anything related to battery. 4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing when compared to TWL6035. The patch series is based on the patch: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90598.html J Keerthy (4): MFD: Palmas: Add Interrupt feature mfd: Palmas: Add TPS659038 PMIC support MFD: Palmas: Add SMPS10_BOOST feature regulator: Palmas: Add TPS659038 support Documentation/devicetree/bindings/mfd/palmas.txt |2 + .../devicetree/bindings/regulator/palmas-pmic.txt |1 + drivers/mfd/palmas.c | 39 drivers/regulator/palmas-regulator.c |4 ++ include/linux/mfd/palmas.h | 18 + 5 files changed, 57 insertions(+), 7 deletions(-) -- 1.7.5.4 -- 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 2/4] mfd: Palmas: Add TPS659038 PMIC support
The Patch adds TPS659038 PMIC support in the palmas mfd driver.
The TPS659038 has almost the same registers as of the earlier
supported variants of PALMAS family such as the TWL6035.
The critical differences between TPS659038 and TWL6035 being:
1) TPS659038 has nothing related to battery charging and back up battery stuff.
2) TPS659038 does not have does not have SMPS10(Boost) step up convertor.
3) TPS659038 does not have Battery detection and anything related to battery.
4) SD card detection, Battery presence detection, Vibrator, USB OTG are missing
when compared to TWL6035.
Signed-off-by: J Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/mfd/palmas.txt |2 ++
drivers/mfd/palmas.c |6 ++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index 7bcd59c..89cb773 100644
--- a/Documentation/devicetree/bindings/mfd/palmas.txt
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -5,6 +5,7 @@ twl6035 (palmas)
twl6037 (palmas)
tps65913 (palmas)
tps65914 (palmas)
+tps659038
Required properties:
- compatible : Should be from the list
@@ -14,6 +15,7 @@ Required properties:
ti,tps65913
ti,tps65914
ti,tps80036
+ ti,tps659038
and also the generic series names
ti,palmas
- interrupt-controller : palmas has its own internal IRQs
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index d06ce62..261beb5 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -233,11 +233,17 @@ static void palmas_dt_to_pdata(struct i2c_client *i2c,
static unsigned int palmas_features = PALMAS_PMIC_FEATURE_INTERRUPT;
+static unsigned int tps659038_features;
+
static const struct of_device_id of_palmas_match_tbl[] = {
{
.compatible = ti,palmas,
.data = palmas_features,
},
+ {
+ .compatible = ti,tps659038,
+ .data = tps659038_features,
+ },
{ },
};
--
1.7.5.4
--
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] mfd: Palmas: Remove code which is not necessary for a device tree boot
Hi, On Mon, Jun 17, 2013 at 05:17:58PM +0530, J Keerthy wrote: Remove code which is not necessary for a device tree boot. Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Laxman Dewangan ldewan...@nvidia.com Acked-by: Graeme Gregory g...@slimlogic.co.uk --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) Applied to mfd-next, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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
[PATCH v2 1/2] ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm
The powerdomain framework currently expects all powerdomains to be associated
with
a corresponding voltagedomain. For some SoCs' (like the already existing AM33xx
family, or for the upcoming AM437x and DRA7 SoCs') which
do not have a Voltage controller/Voltage Processor (neither the SR I2C
bus to communicate with the PMIC) there is no need for a Powerdomain to have
a voltage domain association since there is no auto-scaling of voltages possible
using the voltage FSM.
Extend the arch operations to add an api which the powerdomain core can
then use to identify if a voltdm lookup and association for a powerdomain
is really needed.
Acked-by: Nishanth Menon n...@ti.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/powerdomain.c |5 +
arch/arm/mach-omap2/powerdomain.h |2 ++
2 files changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 86babd7..e233dfc 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -102,6 +102,10 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
if (_pwrdm_lookup(pwrdm-name))
return -EEXIST;
+ if (arch_pwrdm arch_pwrdm-pwrdm_has_voltdm)
+ if (!arch_pwrdm-pwrdm_has_voltdm())
+ goto skip_voltdm;
+
voltdm = voltdm_lookup(pwrdm-voltdm.name);
if (!voltdm) {
pr_err(powerdomain: %s: voltagedomain %s does not exist\n,
@@ -111,6 +115,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
pwrdm-voltdm.ptr = voltdm;
INIT_LIST_HEAD(pwrdm-voltdm_node);
voltdm_add_pwrdm(voltdm, pwrdm);
+skip_voltdm:
spin_lock_init(pwrdm-_lock);
list_add(pwrdm-node, pwrdm_list);
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 140c360..9701ad5 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -166,6 +166,7 @@ struct powerdomain {
* @pwrdm_disable_hdwr_sar: Disable Hardware Save-Restore feature for a pd
* @pwrdm_set_lowpwrstchange: Enable pd transitions from a shallow to deep
sleep
* @pwrdm_wait_transition: Wait for a pd state transition to complete
+ * @pwrdm_has_voltdm: Check if a voltdm association is needed
*
* Regarding @pwrdm_set_lowpwrstchange: On the OMAP2 and 3-family
* chips, a powerdomain's power state is not allowed to directly
@@ -196,6 +197,7 @@ struct pwrdm_ops {
int (*pwrdm_disable_hdwr_sar)(struct powerdomain *pwrdm);
int (*pwrdm_set_lowpwrstchange)(struct powerdomain *pwrdm);
int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
+ int (*pwrdm_has_voltdm)(void);
};
int pwrdm_register_platform_funcs(struct pwrdm_ops *custom_funcs);
--
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
[PATCH v2 0/2] Remove unused voltagedomain data for AM33xx
Hi, The powerdomain framework currently expects to always have a voltagedomain associated with a given powerdomain. We already have AM33xx which has no Voltage Controller/Voltage Processor as part of PRCM. There are more SoCs' to follow starting with AM437x and DRA7xx which do not have VC/VP. All these SoCs', hence do not support any form of auto-scaling of voltages, that was possible on earlier OMAPs' using the VFSM to trigger an i2c communication to the PMIC automatically on hitting a low power state. Instead of adding dummy voltage domain data files, like was done for the AM33xx case, make the powerdomain framework aware of the fact that some SoCs' might not really have support for auto-scaling of voltages in hw. Patches are based of 3.10-rc6 and are boot tested on am335x bone. Rajendra Nayak (2): ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm ARM: AM33xx: Remove the unused voltagedomain data arch/arm/mach-omap2/Makefile |1 - arch/arm/mach-omap2/io.c |1 - arch/arm/mach-omap2/powerdomain.c |5 +++ arch/arm/mach-omap2/powerdomain.h |2 ++ arch/arm/mach-omap2/prm33xx.c |7 arch/arm/mach-omap2/voltage.h |1 - arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 - 7 files changed, 14 insertions(+), 46 deletions(-) delete mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c -- 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
[PATCH v2 2/2] ARM: AM33xx: Remove the unused voltagedomain data
Now that there is a way to tell the powerdomain core about
missing voltage domain auto-scaling control in SoCs', get rid of the dummy
voltage domain data populated for AM33xx devices.
Acked-by: Nishanth Menon n...@ti.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/Makefile |1 -
arch/arm/mach-omap2/io.c |1 -
arch/arm/mach-omap2/prm33xx.c |7
arch/arm/mach-omap2/voltage.h |1 -
arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 -
5 files changed, 7 insertions(+), 46 deletions(-)
delete mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 55a9d67..a4f1d2a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -125,7 +125,6 @@ obj-$(CONFIG_ARCH_OMAP3)+=
voltagedomains3xxx_data.o
obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common)
obj-$(CONFIG_ARCH_OMAP4) += voltagedomains44xx_data.o
obj-$(CONFIG_SOC_AM33XX) += $(voltagedomain-common)
-obj-$(CONFIG_SOC_AM33XX)+= voltagedomains33xx_data.o
obj-$(CONFIG_SOC_OMAP5)+= $(voltagedomain-common)
# OMAP powerdomain framework
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 09abf99..50b93df 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -577,7 +577,6 @@ void __init am33xx_init_early(void)
omap2_set_globals_cm(AM33XX_L4_WK_IO_ADDRESS(AM33XX_PRCM_BASE), NULL);
omap3xxx_check_revision();
ti81xx_check_features();
- am33xx_voltagedomains_init();
am33xx_powerdomains_init();
am33xx_clockdomains_init();
am33xx_hwmod_init();
diff --git a/arch/arm/mach-omap2/prm33xx.c b/arch/arm/mach-omap2/prm33xx.c
index 44c0d72..7204407 100644
--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -320,6 +320,12 @@ static int am33xx_pwrdm_wait_transition(struct powerdomain
*pwrdm)
return 0;
}
+static int am33xx_check_vcvp(void)
+{
+ /* No VC/VP on am33xx devices */
+ return 0;
+}
+
struct pwrdm_ops am33xx_pwrdm_operations = {
.pwrdm_set_next_pwrst = am33xx_pwrdm_set_next_pwrst,
.pwrdm_read_next_pwrst = am33xx_pwrdm_read_next_pwrst,
@@ -335,4 +341,5 @@ struct pwrdm_ops am33xx_pwrdm_operations = {
.pwrdm_set_mem_onst = am33xx_pwrdm_set_mem_onst,
.pwrdm_set_mem_retst= am33xx_pwrdm_set_mem_retst,
.pwrdm_wait_transition = am33xx_pwrdm_wait_transition,
+ .pwrdm_has_voltdm = am33xx_check_vcvp,
};
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index a0ce4f1..9bf796d 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -169,7 +169,6 @@ int omap_voltage_late_init(void);
extern void omap2xxx_voltagedomains_init(void);
extern void omap3xxx_voltagedomains_init(void);
-extern void am33xx_voltagedomains_init(void);
extern void omap44xx_voltagedomains_init(void);
struct voltagedomain *voltdm_lookup(const char *name);
diff --git a/arch/arm/mach-omap2/voltagedomains33xx_data.c
b/arch/arm/mach-omap2/voltagedomains33xx_data.c
deleted file mode 100644
index 965458d..000
--- a/arch/arm/mach-omap2/voltagedomains33xx_data.c
+++ /dev/null
@@ -1,43 +0,0 @@
-/*
- * AM33XX voltage domain data
- *
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation version 2.
- *
- * This program is distributed as is WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-
-#include voltage.h
-
-static struct voltagedomain am33xx_voltdm_mpu = {
- .name = mpu,
-};
-
-static struct voltagedomain am33xx_voltdm_core = {
- .name = core,
-};
-
-static struct voltagedomain am33xx_voltdm_rtc = {
- .name = rtc,
-};
-
-static struct voltagedomain *voltagedomains_am33xx[] __initdata = {
- am33xx_voltdm_mpu,
- am33xx_voltdm_core,
- am33xx_voltdm_rtc,
- NULL,
-};
-
-void __init am33xx_voltagedomains_init(void)
-{
- voltdm_init(voltagedomains_am33xx);
-}
--
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 v2 0/2] Remove unused voltagedomain data for AM33xx
On Monday 17 June 2013 09:16 AM, Rajendra Nayak wrote: Hi, The powerdomain framework currently expects to always have a voltagedomain associated with a given powerdomain. We already have AM33xx which has no Voltage Controller/Voltage Processor as part of PRCM. There are more SoCs' to follow starting with AM437x and DRA7xx which do not have VC/VP. All these SoCs', hence do not support any form of auto-scaling of voltages, that was possible on earlier OMAPs' using the VFSM to trigger an i2c communication to the PMIC automatically on hitting a low power state. Instead of adding dummy voltage domain data files, like was done for the AM33xx case, make the powerdomain framework aware of the fact that some SoCs' might not really have support for auto-scaling of voltages in hw. Patches are based of 3.10-rc6 and are boot tested on am335x bone. Rajendra Nayak (2): ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm ARM: AM33xx: Remove the unused voltagedomain data arch/arm/mach-omap2/Makefile |1 - arch/arm/mach-omap2/io.c |1 - arch/arm/mach-omap2/powerdomain.c |5 +++ arch/arm/mach-omap2/powerdomain.h |2 ++ arch/arm/mach-omap2/prm33xx.c |7 arch/arm/mach-omap2/voltage.h |1 - arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 - 7 files changed, 14 insertions(+), 46 deletions(-) delete mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c Nice !! FWIW, Acked-by: Santosh Shilimkar santosh.shilim...@ti.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
[PATCH] ARM: dts: omap3-beagle: fix the USB phy node
I haven't tested this but it should not work the way it is now. The
format for of_parse_phandle() is usuall phandle index not the other
way around.
Cc: Benoît Cousson b-cous...@ti.com
Cc: Roger Quadros rog...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/omap3-beagle.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 6eec699..a12e9b0 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -128,7 +128,7 @@
};
usbhsehci {
- phys = 0 hsusb2_phy;
+ phys = hsusb2_phy 0;
};
twl_gpio {
--
1.8.3.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
[PATCH v4] spi: omap2-mcspi: Add FIFO buffer support
The MCSPI controller has a built-in FIFO buffer to unload the DMA or interrupt
handler and improve data throughput. This patch adds FIFO buffer support for SPI
transfers in DMA mode.
For SPI transfers in DMA mode, the largest possible FIFO buffer size will be
calculated and set up. The FIFO won't be used for the SPI transfers in DMA mode
if: calculated FIFO buffer size is less then 2 bytes or the FIFO buffer size
isn't multiple of the SPI word length.
Signed-off-by: Illia Smyrnov illia.smyr...@ti.com
---
v4:
* rebased on topic/omap branch
drivers/spi/spi-omap2-mcspi.c | 147 -
1 files changed, 130 insertions(+), 17 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 5a93a0d..6802806 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -38,12 +38,15 @@
#include linux/pm_runtime.h
#include linux/of.h
#include linux/of_device.h
+#include linux/gcd.h
#include linux/spi/spi.h
#include linux/platform_data/spi-omap2-mcspi.h
#define OMAP2_MCSPI_MAX_FREQ 4800
+#define OMAP2_MCSPI_MAX_FIFODEPTH 64
+#define OMAP2_MCSPI_MAX_FIFOWCNT 0x
#define SPI_AUTOSUSPEND_TIMEOUT2000
#define OMAP2_MCSPI_REVISION 0x00
@@ -53,6 +56,7 @@
#define OMAP2_MCSPI_WAKEUPENABLE 0x20
#define OMAP2_MCSPI_SYST 0x24
#define OMAP2_MCSPI_MODULCTRL 0x28
+#define OMAP2_MCSPI_XFERLEVEL 0x7c
/* per-channel banks, 0x14 bytes each, first is: */
#define OMAP2_MCSPI_CHCONF00x2c
@@ -62,6 +66,7 @@
#define OMAP2_MCSPI_RX00x3c
/* per-register bitmasks: */
+#define OMAP2_MCSPI_IRQSTATUS_EOW BIT(17)
#define OMAP2_MCSPI_MODULCTRL_SINGLE BIT(0)
#define OMAP2_MCSPI_MODULCTRL_MS BIT(2)
@@ -82,10 +87,13 @@
#define OMAP2_MCSPI_CHCONF_IS BIT(18)
#define OMAP2_MCSPI_CHCONF_TURBO BIT(19)
#define OMAP2_MCSPI_CHCONF_FORCE BIT(20)
+#define OMAP2_MCSPI_CHCONF_FFETBIT(27)
+#define OMAP2_MCSPI_CHCONF_FFERBIT(28)
#define OMAP2_MCSPI_CHSTAT_RXS BIT(0)
#define OMAP2_MCSPI_CHSTAT_TXS BIT(1)
#define OMAP2_MCSPI_CHSTAT_EOT BIT(2)
+#define OMAP2_MCSPI_CHSTAT_TXFFE BIT(3)
#define OMAP2_MCSPI_CHCTRL_EN BIT(0)
@@ -128,6 +136,7 @@ struct omap2_mcspi {
struct omap2_mcspi_dma *dma_channels;
struct device *dev;
struct omap2_mcspi_regs ctx;
+ int fifo_depth;
unsigned intpin_dir:1;
};
@@ -257,6 +266,58 @@ static void omap2_mcspi_set_master_mode(struct spi_master
*master)
ctx-modulctrl = l;
}
+static void omap2_mcspi_set_fifo(const struct spi_device *spi,
+ struct spi_transfer *t, int enable)
+{
+ struct spi_master *master = spi-master;
+ struct omap2_mcspi_cs *cs = spi-controller_state;
+ struct omap2_mcspi *mcspi;
+ unsigned int wcnt;
+ int fifo_depth, bytes_per_word;
+ u32 chconf, xferlevel;
+
+ mcspi = spi_master_get_devdata(master);
+
+ chconf = mcspi_cached_chconf0(spi);
+ if (enable) {
+ bytes_per_word = mcspi_bytes_per_word(cs-word_len);
+ if (t-len % bytes_per_word != 0)
+ goto disable_fifo;
+
+ fifo_depth = gcd(t-len, OMAP2_MCSPI_MAX_FIFODEPTH);
+ if (fifo_depth 2 || fifo_depth % bytes_per_word != 0)
+ goto disable_fifo;
+
+ wcnt = t-len / bytes_per_word;
+ if (wcnt OMAP2_MCSPI_MAX_FIFOWCNT)
+ goto disable_fifo;
+
+ xferlevel = wcnt 16;
+ if (t-rx_buf != NULL) {
+ chconf |= OMAP2_MCSPI_CHCONF_FFER;
+ xferlevel |= (fifo_depth - 1) 8;
+ } else {
+ chconf |= OMAP2_MCSPI_CHCONF_FFET;
+ xferlevel |= fifo_depth - 1;
+ }
+
+ mcspi_write_reg(master, OMAP2_MCSPI_XFERLEVEL, xferlevel);
+ mcspi_write_chconf0(spi, chconf);
+ mcspi-fifo_depth = fifo_depth;
+
+ return;
+ }
+
+disable_fifo:
+ if (t-rx_buf != NULL)
+ chconf = ~OMAP2_MCSPI_CHCONF_FFER;
+ else
+ chconf = ~OMAP2_MCSPI_CHCONF_FFET;
+
+ mcspi_write_chconf0(spi, chconf);
+ mcspi-fifo_depth = 0;
+}
+
static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
{
struct spi_master *spi_cntrl = mcspi-master;
@@ -373,7 +434,7 @@ omap2_mcspi_rx_dma(struct spi_device *spi, struct
spi_transfer *xfer,
{
struct omap2_mcspi *mcspi;
struct omap2_mcspi_dma *mcspi_dma;
- unsigned intcount;
+ unsigned intcount, dma_count;
u32 l;
int elements = 0;
Re: [PATCH v3 2/2] spi: omap2-mcspi: Add FIFO buffer support
On 06/17/2013 12:16 PM, Mark Brown wrote: On Fri, Jun 14, 2013 at 07:12:08PM +0300, Illia Smyrnov wrote: The MCSPI controller has a built-in FIFO buffer to unload the DMA or interrupt handler and improve data throughput. This patch adds FIFO buffer support for SPI transfers in DMA mode. This looks good but doesn't apply against my topic/omap branch - can you please check and resend? Probably something that applies against -next will be fine. I fixed it and sent v4 of spi: omap2-mcspi: Add FIFO buffer support patch. -- 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 0/2] Remove unused voltagedomain data for AM33xx
Hi, On Mon, Jun 17, 2013 at 18:46:21, Nayak, Rajendra wrote: The powerdomain framework currently expects to always have a voltagedomain associated with a given powerdomain. We already have AM33xx which has no Voltage Controller/Voltage Processor as part of PRCM. There are more SoCs' to follow starting with AM437x and DRA7xx which do not have VC/VP. All these SoCs', hence do not support any form of auto-scaling of voltages, that was possible on earlier OMAPs' using the VFSM to trigger an i2c communication to the PMIC automatically on hitting a low power state. Instead of adding dummy voltage domain data files, like was done for the AM33xx case, make the powerdomain framework aware of the fact that some SoCs' might not really have support for auto-scaling of voltages in hw. Patches are based of 3.10-rc6 and are boot tested on am335x bone. Tested-by: Afzal Mohammed af...@ti.com (am335x evm) Regards Afzal -- 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
[GIT PULL] omapdss changes for 3.11, part 1/2
The following changes since commit 317ddd256b9c24b0d78fa8018f80f1e495481a10: Linux 3.10-rc5 (2013-06-08 17:41:04 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.11-1 for you to fetch changes up to 595470a7853848cb971d5ee3fed443b1e3aa0d1b: OMAPDSS: gracefully disable overlay at error (2013-06-17 14:00:56 +0300) OMAP display subsystem changes for 3.11 (part 1/2) This is the first part of OMAP DSS changes for 3.11. This part contains fixes, cleanups and reorganizations that are not directly related to the new DSS device model that is added in part 2, although many of the reorganizations are made to make the part 2 possible. There should not be any functional changes visible to the user except the few bug fixes. The main new internal features: - Display (dis)connect support, which allows us to explicitly (dis)connect a whole display pipeline - Panel list, which allows us to operate without the specific DSS bus - Combine omap_dss_output to omap_dss_device, so that we have one generic entity for display pipeline blocks Emil Goode (1): OMAPDSS: Remove kfree for memory allocated with devm_kzalloc Sergey Kibrik (1): OMAPDSS: gracefully disable overlay at error Tomi Valkeinen (36): OMAPDSS: add pdata-default_display_name OMAPDSS: only probe pdata if there's one OMAPDSS: add omap_dss_find_output() OMAPDSS: add omap_dss_find_output_by_node() OMAPDSS: fix dss_get_ctx_loss_count for DT OMAPDSS: clean up dss_[ovl|mgr]_get_device() OMAPDSS: add helpers to get mgr or output from display OMAPDSS: split overlay manager creation OMAPDRM: fix overlay manager handling OMAPDSS: Implement display (dis)connect support OMAPDSS: CORE: use devm_regulator_get OMAPDSS: DSI: cleanup regulator init OMAPDSS: DPI: cleanup pll regulator init OMAPDSS: DPI: fix regulators for DT OMAPDSS: HDMI: add hdmi_init_regulator OMAPDSS: SDI: clean up regulator init OMAPDSS: SDI: fix regulators for DT OMAPDSS: VENC: clean up regulator init OMAPDSS: add videomode conversion support OMAPDSS: remove dssdev uses in trivial cases OMAPDSS: add panel list OMAPDSS: use the panel list in omap_dss_get_next_device OMAPDSS: don't use dss bus in suspend/resume OMAPDSS: implement display sysfs without dss bus OMAPDSS: Add panel dev pointer to dssdev OMAPDSS: remove omap_dss_start/stop_device() OMAPDSS: combine omap_dss_output into omap_dss_device OMAPDSS: omapdss.h: add owner field to omap_dss_device OMAPDSS: add module_get/put to omap_dss_get/put_device() OMAPDSS: add THIS_MODULE owner to DSS outputs OMAPDSS: output: increase refcount in find_output funcs OMAPFB: use EPROBE_DEFER if default display is not present OMAPDSS: HDMI: clean up PHY power handling OMAPDSS: HDMI clean up hpd_gpio OMAPDSS: remove unused fields in omap_dss_device OMAPDSS: remove dispc's dependency to VENC/HDMI drivers/gpu/drm/omapdrm/omap_crtc.c| 46 +++- drivers/gpu/drm/omapdrm/omap_drv.c | 21 +- drivers/gpu/drm/omapdrm/omap_drv.h | 1 + drivers/video/omap2/displays/panel-acx565akm.c | 16 +- drivers/video/omap2/displays/panel-generic-dpi.c | 26 +-- .../omap2/displays/panel-lgphilips-lb035q02.c | 10 +- drivers/video/omap2/displays/panel-n8x0.c | 30 +-- .../omap2/displays/panel-nec-nl8048hl11-01b.c | 4 +- drivers/video/omap2/displays/panel-picodlp.c | 34 ++- .../video/omap2/displays/panel-sharp-ls037v7dw01.c | 10 +- drivers/video/omap2/displays/panel-taal.c | 164 +++--- drivers/video/omap2/displays/panel-tfp410.c| 32 +-- .../video/omap2/displays/panel-tpo-td043mtea1.c| 36 +-- drivers/video/omap2/dss/Kconfig| 1 + drivers/video/omap2/dss/apply.c| 47 ++-- drivers/video/omap2/dss/core.c | 108 + drivers/video/omap2/dss/dispc-compat.c | 3 +- drivers/video/omap2/dss/dispc.c| 24 +- drivers/video/omap2/dss/display-sysfs.c| 154 +++-- drivers/video/omap2/dss/display.c | 246 ++--- drivers/video/omap2/dss/dpi.c | 131 +-- drivers/video/omap2/dss/dsi.c | 135 +-- drivers/video/omap2/dss/dss.c | 3 +- drivers/video/omap2/dss/dss.h | 35 +-- drivers/video/omap2/dss/dss_features.c | 1 - drivers/video/omap2/dss/hdmi.c | 107 - drivers/video/omap2/dss/manager-sysfs.c| 47 ++-- drivers/video/omap2/dss/manager.c
[GIT PULL] omapdss changes for 3.11, part 2/2
The following changes since commit 595470a7853848cb971d5ee3fed443b1e3aa0d1b: OMAPDSS: gracefully disable overlay at error (2013-06-17 14:00:56 +0300) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.11-2 for you to fetch changes up to c545b59515cca4ccaf920e12582a43836cddaa2b: OMAPDSS: panels: add Kconfig comment (2013-06-17 14:33:21 +0300) OMAP display subsystem changes for 3.11 (part 2/2) This is the second part of OMAP DSS changes for 3.11. This part contains the new DSS device model support. The current OMAP panel drivers use a custom DSS bus, and there's a hard limit of one external display block per video pipeline. In the new DSS device model the devices/drivers are made according to the control bus of the display block, usually platform, i2c or spi. The display blocks can also be chained so that we can have separate drivers for setups with both external encoder and panel. To allow the current board files, which use the old style panels, to function, the old display drivers are left in their current state, and new ones are added to drivers/video/omap2/displays-new/. When the board files have been converted to use the new style panels, we can remove the old code. This is planned to happen in v3.12. Having to support two very different DSS device models makes the driver somewhat confusing in some parts, and prevents us from properly cleaning up some other parts. These cleanups will be done when the old code is removed. The new device model is designed with CDF (Common Display Framework) in mind. While CDF is still under work, the new DSS device model should be much more similar to CDF's model than the old device model, which should make the eventual conversion to CDF much easier. Tomi Valkeinen (23): OMAPDSS: public omapdss_register_output() OMAPDSS: modify get/find functions to go through the device chain OMAPDSS: add OMAP_DISPLAY_TYPE_DVI drm/omap: DVI connector fix OMAPDSS: DPI: Add ops OMAPDSS: SDI: Add ops OMAPDSS: DVI: Add ops OMAPDSS: AnalogTV: Add ops OMAPDSS: HDMI: Add ops OMAPDSS: DSI: Add ops OMAPDSS: Add new TFP410 Encoder driver OMAPDSS: Add new TPD12S015 Encoder driver OMAPDSS: Add new DVI Connector driver OMAPDSS: Add new HDMI Connector driver OMAPDSS: Add new Analog TV Connector driver OMAPDSS: Add new simple DPI panel driver OMAPDSS: Add new DSI Command Mode panel driver OMAPDSS: Add Sony ACX565AKM panel driver OMAPDSS: Add LG.Philips LB035Q02 panel driver OMAPDSS: Add Sharp LS037V7DW01 panel driver OMAPDSS: Add TPO TD043MTEA1 panel driver OMAPDSS: Add NEC NL8048HL11 panel driver OMAPDSS: panels: add Kconfig comment drivers/gpu/drm/omapdrm/omap_drv.c |6 +- drivers/video/omap2/Kconfig|1 + drivers/video/omap2/Makefile |1 + drivers/video/omap2/displays-new/Kconfig | 73 ++ drivers/video/omap2/displays-new/Makefile | 12 + .../video/omap2/displays-new/connector-analog-tv.c | 265 drivers/video/omap2/displays-new/connector-dvi.c | 351 + drivers/video/omap2/displays-new/connector-hdmi.c | 375 ++ drivers/video/omap2/displays-new/encoder-tfp410.c | 267 .../video/omap2/displays-new/encoder-tpd12s015.c | 395 ++ drivers/video/omap2/displays-new/panel-dpi.c | 270 drivers/video/omap2/displays-new/panel-dsi-cm.c| 1336 .../omap2/displays-new/panel-lgphilips-lb035q02.c | 358 ++ .../omap2/displays-new/panel-nec-nl8048hl11.c | 394 ++ .../omap2/displays-new/panel-sharp-ls037v7dw01.c | 324 + .../omap2/displays-new/panel-sony-acx565akm.c | 865 + .../omap2/displays-new/panel-tpo-td043mtea1.c | 646 ++ drivers/video/omap2/displays/Kconfig |2 +- drivers/video/omap2/dss/apply.c| 14 +- drivers/video/omap2/dss/display.c |1 + drivers/video/omap2/dss/dpi.c | 74 +- drivers/video/omap2/dss/dsi.c | 97 +- drivers/video/omap2/dss/dss.h |4 - drivers/video/omap2/dss/hdmi.c | 238 +++- drivers/video/omap2/dss/output.c | 15 +- drivers/video/omap2/dss/rfbi.c |4 +- drivers/video/omap2/dss/sdi.c | 82 +- drivers/video/omap2/dss/venc.c | 76 +- include/video/omap-panel-data.h| 209 +++ include/video/omapdss.h| 192 ++- 30 files changed, 6911 insertions(+), 36 deletions(-) create mode 100644 drivers/video/omap2/displays-new/Kconfig create mode 100644
Re: [PATCH] ARM: dts: omap3-beagle: fix the USB phy node
On 06/17/2013 03:27 PM, Sebastian Andrzej Siewior wrote:
index 6eec699..a12e9b0 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -128,7 +128,7 @@
};
usbhsehci {
- phys = 0 hsusb2_phy;
+ phys = hsusb2_phy 0;
};
twl_gpio {
Wait. Or does it mean that the first phy is deactivated and we add
phyhandle 0 (which is the root node) to skip it?
I assume that now since we don't have a cells property (like
#gpio-cells for the gpio lookup).
So ignore it please…
Sebastian
--
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: dts: omap3-beagle: fix the USB phy node
On 06/17/2013 04:54 PM, Sebastian Andrzej Siewior wrote:
On 06/17/2013 03:27 PM, Sebastian Andrzej Siewior wrote:
index 6eec699..a12e9b0 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -128,7 +128,7 @@
};
usbhsehci {
-phys = 0 hsusb2_phy;
+phys = hsusb2_phy 0;
};
twl_gpio {
Wait. Or does it mean that the first phy is deactivated and we add
phyhandle 0 (which is the root node) to skip it?
Right, it is a list of PHY phandles and the first one is not used so 0
I assume that now since we don't have a cells property (like
#gpio-cells for the gpio lookup).
So ignore it please…
OK.
cheers,
-roger
--
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 0/2] Remove unused voltagedomain data for AM33xx
Rajendra Nayak rna...@ti.com writes: Hi, The powerdomain framework currently expects to always have a voltagedomain associated with a given powerdomain. We already have AM33xx which has no Voltage Controller/Voltage Processor as part of PRCM. There are more SoCs' to follow starting with AM437x and DRA7xx which do not have VC/VP. All these SoCs', hence do not support any form of auto-scaling of voltages, that was possible on earlier OMAPs' using the VFSM to trigger an i2c communication to the PMIC automatically on hitting a low power state. Instead of adding dummy voltage domain data files, like was done for the AM33xx case, make the powerdomain framework aware of the fact that some SoCs' might not really have support for auto-scaling of voltages in hw. Patches are based of 3.10-rc6 and are boot tested on am335x bone. Rajendra Nayak (2): ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm ARM: AM33xx: Remove the unused voltagedomain data Thanks, queuing up this series with ack from Santosh and tested-by from Afzal. I'll try, but not sure if it can make it for v3.11. Kevin -- 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 v10 5/8] dmaengine: edma: Add TI EDMA device tree binding
Hi Sekhar,
-Original Message-
From: Nori, Sekhar
Sent: Monday, June 17, 2013 6:01 AM
To: Fernandes, Joel A; Grant Likely; Rob Herring
Cc: Tony Lindgren; Matt Porter; Vinod Koul; Mark Brown; Cousson, Benoit;
Russell King; Rob Landley; Andrew Morton; Jason Kridner; Koen Kooi;
Devicetree Discuss; Linux OMAP List; Linux ARM Kernel List; Linux DaVinci
Kernel List; Linux Kernel Mailing List; Linux Documentation List; Linux MMC
List; Linux SPI Devel List; Arnd Bergmann
Subject: Re: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree
binding
Grant, Rob,
Can one of you please take a look at this patch and see if you have any
comments on the binding definition?
Joel,
Ideally the bindings are described before they are used or along with its
usage. In that aspect, this patch is present too far back in the series. Can
you
please fix this if you get to posting another version. I think I gave the same
comment on v9 as well.
[Joel] Yes, sure, I will make a note to push this up the series during the next
posting.
Thanks,
Joel
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
[RFC] Add support for am33xx which has two musb ports
Hi Felipe, so with these two I can use the second port on my am335x-evm in hostmode. After the second ports gets noticed by Linux I see over and over: |musb_bus_suspend 2457: trying to suspend as a_wait_bcon while active Which disappears once I plug in a device and does not come back after I unplug it. Port 0 in device seems to run as well. On the first time i see | CAUTION: musb: Babble Interrupt Occurred | g_ncm gadget: high-speed config #1: CDC Ethernet (NCM) and on the second time I plug it in there is no such babble error. Maybe there is some kind of init missing here. Any comments? Sebastian -- 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 2/2] musb: musb: dsps: determine the number of instances at runtime
There is no need to hardcode the number of instances here. It is better to
determine them at runtime. Even if the device provides two instances one
might only want to use one of them.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_dsps.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index d9ff390..0ac9934 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -110,8 +110,6 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8 poll_seconds;
- /* number of musb instances */
- u8 instances;
};
/**
@@ -124,6 +122,7 @@ struct dsps_glue {
struct timer_list timer[2]; /* otg_workaround timer */
unsigned long last_timer[2];/* last timer data for each instance */
u32 __iomem *usb_ctrl[2];
+ u8 instances;
};
#defineDSPS_AM33XX_CONTROL_MODULE_PHYS_0 0x44e10620
@@ -646,6 +645,23 @@ static int dsps_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, glue);
+ i = 1;
+ do {
+ iomem = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!iomem) {
+ i--;
+ break;
+ }
+ i++;
+ } while (1);
+
+ glue-instances = i;
+ if (glue-instances 1) {
+ dev_err(pdev-dev, Need atleast iomem for one port.\n);
+ ret = -EINVAL;
+ goto err1_5;
+ }
+
/* enable the usbss clocks */
pm_runtime_enable(pdev-dev);
@@ -656,7 +672,7 @@ static int dsps_probe(struct platform_device *pdev)
}
/* create the child platform device for all instances of musb */
- for (i = 0; i wrp-instances ; i++) {
+ for (i = 0; i glue-instances; i++) {
ret = dsps_create_musb_pdev(glue, i);
if (ret != 0) {
dev_err(pdev-dev, failed to create child pdev\n);
@@ -673,6 +689,7 @@ static int dsps_probe(struct platform_device *pdev)
pm_runtime_put(pdev-dev);
err2:
pm_runtime_disable(pdev-dev);
+err1_5:
kfree(glue-wrp);
err1:
kfree(glue);
@@ -682,11 +699,10 @@ static int dsps_probe(struct platform_device *pdev)
static int dsps_remove(struct platform_device *pdev)
{
struct dsps_glue *glue = platform_get_drvdata(pdev);
- const struct dsps_musb_wrapper *wrp = glue-wrp;
int i;
/* delete the child platform device */
- for (i = 0; i wrp-instances ; i++)
+ for (i = 0; i glue-instances; i++)
platform_device_unregister(glue-musb[i]);
/* disable usbss clocks */
@@ -702,10 +718,9 @@ static int dsps_suspend(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev-parent);
struct dsps_glue *glue = platform_get_drvdata(pdev);
- const struct dsps_musb_wrapper *wrp = glue-wrp;
int i;
- for (i = 0; i wrp-instances; i++)
+ for (i = 0; i glue-instances; i++)
musb_dsps_phy_control(glue, i, 0);
return 0;
@@ -715,10 +730,9 @@ static int dsps_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev-parent);
struct dsps_glue *glue = platform_get_drvdata(pdev);
- const struct dsps_musb_wrapper *wrp = glue-wrp;
int i;
- for (i = 0; i wrp-instances; i++)
+ for (i = 0; i glue-instances; i++)
musb_dsps_phy_control(glue, i, 1);
return 0;
@@ -755,7 +769,6 @@ static const struct dsps_musb_wrapper ti81xx_driver_data = {
.rxep_bitmap= (0xfffe 16),
.musb_core_offset = 0x400,
.poll_seconds = 2,
- .instances = 1,
};
static const struct platform_device_id musb_dsps_id_table[] = {
--
1.8.3.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
[PATCH 1/2] musb: musb: dsps: support multiple instances
If we specify right now more than once instance then we attempt to add
the platform device twice. The nop driver does not mind the second add
because it checks for it and returns without a word. At removal time a
segfault is likely because the first intance clean ups the phy and
second, well, goes boom.
This patchs adds two dummy device node to the am33xx for the dummy phy
which we have now. During probe time, we grab the phy based on the
device node if we have one. If not, we use the same hack we used so far.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
arch/arm/boot/dts/am33xx.dtsi | 8
drivers/usb/musb/musb_dsps.c | 18 +-
include/linux/usb/musb.h | 1 +
3 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 8e1248f..30d0d45 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -341,6 +341,14 @@
port1-mode = 3;
power = 250;
ti,hwmods = usb_otg_hs;
+ phys = nopphy0 nopphy1;
+ };
+
+ nopphy0: usbphy@0 {
+ compatible = usb-nop-xceiv;
+ };
+ nopphy1: usbphy@1 {
+ compatible = usb-nop-xceiv;
};
mac: ethernet@4a10 {
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e1b661d..d9ff390 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -415,9 +415,14 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb-mregs += wrp-musb_core_offset;
- /* NOP driver needs change if supporting dual instance */
- usb_nop_xceiv_register();
- musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
+ if (!glue-dev-of_node) {
+ /* This hack works only for a single instance. */
+ usb_nop_xceiv_register();
+ musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
+ } else {
+ musb-xceiv = devm_usb_get_phy_by_phandle(glue-dev, phys,
+ musb-config-instance);
+ }
if (IS_ERR_OR_NULL(musb-xceiv))
return -EPROBE_DEFER;
@@ -449,7 +454,8 @@ static int dsps_musb_init(struct musb *musb)
return 0;
err0:
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ if (!glue-dev-of_node)
+ usb_nop_xceiv_unregister();
return status;
}
@@ -466,7 +472,8 @@ static int dsps_musb_exit(struct musb *musb)
/* NOP driver needs change if supporting dual instance */
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ if (!glue-dev-of_node)
+ usb_nop_xceiv_unregister();
return 0;
}
@@ -570,6 +577,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue, u8
id)
of_property_read_u32(np, res_name, (u32 *)pdata-mode);
of_property_read_u32(np, power, (u32 *)pdata-power);
config-multipoint = of_property_read_bool(np, multipoint);
+ config-instance = id;
pdata-config = config;
}
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..e027705 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -83,6 +83,7 @@ struct musb_hdrc_config {
u8 vendor_stat __deprecated; /* vendor status reg witdh */
u8 dma_req_chan __deprecated; /* bitmask for required dma
channels */
u8 ram_bits; /* ram address size */
+ u8 instance;
struct musb_hdrc_eps_bits *eps_bits __deprecated;
#ifdef CONFIG_BLACKFIN
--
1.8.3.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: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree binding
Hi Arnd, -Original Message- From: Arnd Bergmann [mailto:a...@arndb.de] Sent: Monday, June 17, 2013 6:13 AM To: Fernandes, Joel A Cc: Tony Lindgren; Nori, Sekhar; Matt Porter; Grant Likely; Rob Herring; Vinod Koul; Mark Brown; Cousson, Benoit; Russell King; Rob Landley; Andrew Morton; Jason Kridner; Koen Kooi; Devicetree Discuss; Linux OMAP List; Linux ARM Kernel List; Linux DaVinci Kernel List; Linux Kernel Mailing List; Linux Documentation List; Linux MMC List; Linux SPI Devel List Subject: Re: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree binding On Friday 14 June 2013 21:32:47 Joel A Fernandes wrote: diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt new file mode 100644 index 000..ada0018 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -0,0 +1,26 @@ +TI EDMA + +Required properties: +- compatible : ti,edma3 +- ti,hwmods: Name of the hwmods associated to the EDMA +- ti,edma-regions: Number of regions +- ti,edma-slots: Number of slots + +Optional properties: +- ti,edma-xbar-event-map: Crossbar event to channel map You need to list #dma-cells as required here, and which values are accepted by the driver (I suppose only 1). You should also explain the format of the dma-specifier for a slave here for each possible value of #dma-cells. For each of the standard properties (reg, interrupts, dma-channels), list whether they are optional or required. Since the example has three interrupts, you should probably list how many interrupts need to be specified (minimum and maximum if the number is variable) and in what order to expect them. [Joel] Thanks for the suggestion, I updated it and it looks like this now: Required properties: - compatible : ti,edma3 - ti,hwmods: Name of the hwmods associated to the EDMA - ti,edma-regions: Number of regions - ti,edma-slots: Number of slots - #dma-cells: Should be set to 1 Clients should use a single number per DMA channel request. - dma-channels: Specify total DMA channels per CC - reg: Memory map for accessing module - interrupt-parent: Interrupt controller the interrupt is routed through - interrupts: Exactly 3 interrupts need to be specified in the order: 1. Transfer completion interrupt. 2. Memory protection interrupt. 3. Error interrupt. Optional properties: - ti,edma-xbar-event-map: Crossbar event to channel map Hope this looks ok. I will respin this patch and repost it in the next series spin. Thanks, Joel -- 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 0/3] omap_hsmmc DT DMA Client support
On Friday 14 June 2013 11:40 PM, Joel A Fernandes wrote: Resending on Matt's new email, thanks. On Fri, Jun 14, 2013 at 1:10 PM, Joel A Fernandes agnel.j...@gmail.com wrote: Hi, On Wed, Mar 6, 2013 at 7:37 AM, Matt Porter mpor...@ti.com wrote: On Tue, Mar 05, 2013 at 09:26:01PM +, Arnd Bergmann wrote: On Tuesday 05 March 2013, Matt Porter wrote: Changes since v1: - rebase to 3.9-rc1, previous dependencies upstream This series adds DT DMA Engine Client support to the omap_hsmmc. It leverages the generic DMA OF helpers in -next and the dma_request_slave_channel_compat() wrapper introduced in the AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms booting via DT. These platforms include omap2/3/4/5 and am33xx. These patches were split out from the v5 version of the AM33XX DMA series and split from the EDMA-specific omap_hsmmc changes. The description seems stale, but the patches all look good to me. I guess they can now get merged in any order. Acked-by: Arnd Bergmann a...@arndb.de Yes, missed updating that to indicating that those are now in 3.9-rc1. If there are no more changes, could this patch please be merged in for 3.10 or if not, could Matt please update the description as requested and repost? Hi Joel, mmc: omap_hsmmc: Skip platform_get_resource_byname() for dt case mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() got merged in 3.10 rc5 mmc: omap_hsmmc: add generic DMA request support to the DT binding should go along with edma dts patch series Thanks, Joel -- 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] mfd: Palmas: Remove code which is not necessary for a device tree boot
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Samuel Ortiz Sent: Monday, June 17, 2013 6:41 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; ldewan...@nvidia.com; g...@slimlogic.co.uk Subject: Re: [PATCH v2] mfd: Palmas: Remove code which is not necessary for a device tree boot Hi, On Mon, Jun 17, 2013 at 05:17:58PM +0530, J Keerthy wrote: Remove code which is not necessary for a device tree boot. Boot tested on OMAP5-UEVM board. Signed-off-by: J Keerthy j-keer...@ti.com Acked-by: Laxman Dewangan ldewan...@nvidia.com Acked-by: Graeme Gregory g...@slimlogic.co.uk --- drivers/mfd/palmas.c | 106 -- 1 files changed, 0 insertions(+), 106 deletions(-) Applied to mfd-next, thanks. Thanks Samuel! Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 -- 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 01/22] mfd/ti_am335x_tscadc: remove regmap
On Mon, Jun 17, 2013 at 01:41:40PM +0200, Sebastian Andrzej Siewior wrote: On 06/14/2013 03:53 PM, Mark Brown wrote: It does give you tracepoints and debugfs. If it's making things at all complicated we need to look at why that is and figure out how to fix that since it's probably an issue for other users. debugfs are tracepoints is our offer? Let me check the price one more time. OK... This is a lot of for a simple mmio access. In terms of performance: If I add a trace point to my read and write I have still less code which is called and it can be disabled. This regmap overhead is always there chasing pointers. Equally well what you're implementing here is support for something that's typically implemented with an I2C or SPI control interface so you're already going to be quite a way ahead of the norm. This is part of what's confusing me, usually for this application things aren't that bad performance wise even on a massively slower bus. If all you're saying here is that there's some overhead that's fine if a bit surprising, but the way you're talking made it sound like there was some issue that made the API actually unusable. As I said before: I doubt that you get this regmap access in an one GiB network driver and in turn remove their trace points to register access. Well, of course for that sort of thing the general trick is not to talk to the hardware at all and do as much as possible with memory that the hardware can DMA - there's actually still non-trivial costs in talking over the buses. Please don't get me wrong: It is still nice for slow buses and this ADC driver isn't anything close to high performance like a 1GiB network driver but it adds a lot of unwanted overhead which I prefer not to have. OK, but equally well remember that from a subsystem maintainer point of view having things factored out is a win in itself; for example with the MFDs locking on the register I/O has been a persistent issue in the past. signature.asc Description: Digital signature
Re: [PATCH 1/4] MFD: Palmas: Add Interrupt feature
On Mon, Jun 17, 2013 at 05:39:11PM +0530, J Keerthy wrote: Palmas PMICs have an INT line. This line is one single Interrupt line to the application processor. The interrupt feature enables to selectively request irq for only those specific chips which have INT line connected to a valid IRQ line of the application processor. Does the support for the interrupt line need to be explicitly flagged like this or can the driver not simply support an interrupt line not being configured? That would also support cases where the hardware has an interrupt line but the system integrator has opeted not to connect it for some reason which seems generally more flexible than doing things on a chip ID basis. +/** + * DOC: Palmas PMIC feature types + * Is DOC: normal kerneldoc? signature.asc Description: Digital signature
Re: [PATCH v4] spi: omap2-mcspi: Add FIFO buffer support
On Mon, Jun 17, 2013 at 04:31:06PM +0300, Illia Smyrnov wrote: The MCSPI controller has a built-in FIFO buffer to unload the DMA or interrupt handler and improve data throughput. This patch adds FIFO buffer support for SPI transfers in DMA mode. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree binding
On Monday 17 June 2013, Fernandes, Joel A wrote: [Joel] Thanks for the suggestion, I updated it and it looks like this now: Required properties: - compatible : ti,edma3 - ti,hwmods: Name of the hwmods associated to the EDMA - ti,edma-regions: Number of regions - ti,edma-slots: Number of slots - #dma-cells: Should be set to 1 Clients should use a single number per DMA channel request. That still does not say what that number refers to. Is it a channel number, or a request line number, or something completely different? Arnd -- 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 v10 5/8] dmaengine: edma: Add TI EDMA device tree binding
-Original Message- From: Arnd Bergmann [mailto:a...@arndb.de] Sent: Monday, June 17, 2013 11:20 AM To: Fernandes, Joel A Cc: Tony Lindgren; Nori, Sekhar; Matt Porter; Grant Likely; Rob Herring; Vinod Koul; Mark Brown; Cousson, Benoit; Russell King; Rob Landley; Andrew Morton; Jason Kridner; Koen Kooi; Devicetree Discuss; Linux OMAP List; Linux ARM Kernel List; Linux DaVinci Kernel List; Linux Kernel Mailing List; Linux Documentation List; Linux MMC List; Linux SPI Devel List Subject: Re: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree binding On Monday 17 June 2013, Fernandes, Joel A wrote: [Joel] Thanks for the suggestion, I updated it and it looks like this now: Required properties: - compatible : ti,edma3 - ti,hwmods: Name of the hwmods associated to the EDMA - ti,edma-regions: Number of regions - ti,edma-slots: Number of slots - #dma-cells: Should be set to 1 Clients should use a single number per DMA channel request. That still does not say what that number refers to. Is it a channel number, or a request line number, or something completely different? [Joel] Ah! Will fix, it's a channel number. Thanks, Joel -- 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
[GIT PULL] OMAP: PM: voltagedomain cleanup for v3.11
The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git tags/omap-pm-v3.11/voltdm for you to fetch changes up to 63b0420c85096d4bb1a3ba365dbf6b970a58b8f7: ARM: AM33xx: Remove the unused voltagedomain data (2013-06-17 07:26:44 -0700) OMAP: PM: remove requirement for voltage domain data; remove dummy data Rajendra Nayak (2): ARM: OMAP2+: Powerdomain: Remove the need to always have a voltdm associated to a pwrdm ARM: AM33xx: Remove the unused voltagedomain data arch/arm/mach-omap2/Makefile | 1 - arch/arm/mach-omap2/io.c | 1 - arch/arm/mach-omap2/powerdomain.c | 5 arch/arm/mach-omap2/powerdomain.h | 2 ++ arch/arm/mach-omap2/prm33xx.c | 7 + arch/arm/mach-omap2/voltage.h | 1 - arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 --- 7 files changed, 14 insertions(+), 46 deletions(-) delete mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c -- 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 v5 1/3] ARM: OMAP2+: gpmc: Converts GPMC driver to pm_runtime capable
From: avinash philip avinashphi...@ti.com
Support for pm_runtime add to GPMC driver.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Pekon Gupta pe...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/gpmc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index fb6f241..1380cee 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -30,6 +30,7 @@
#include linux/of_mtd.h
#include linux/of_device.h
#include linux/mtd/nand.h
+#include linux/pm_runtime.h
#include linux/platform_data/mtd-nand-omap2.h
@@ -1594,7 +1595,8 @@ static int gpmc_probe(struct platform_device *pdev)
return PTR_ERR(gpmc_l3_clk);
}
- clk_prepare_enable(gpmc_l3_clk);
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_get_sync(pdev-dev);
gpmc_dev = pdev-dev;
@@ -1634,7 +1636,7 @@ static int gpmc_probe(struct platform_device *pdev)
rc = gpmc_probe_dt(pdev);
if (rc 0) {
- clk_disable_unprepare(gpmc_l3_clk);
+ pm_runtime_put_sync(pdev-dev);
clk_put(gpmc_l3_clk);
dev_err(gpmc_dev, failed to probe DT parameters\n);
return rc;
@@ -1647,6 +1649,8 @@ static int gpmc_remove(struct platform_device *pdev)
{
gpmc_free_irq();
gpmc_mem_exit();
+ pm_runtime_put_sync(pdev-dev);
+ pm_runtime_disable(pdev-dev);
gpmc_dev = NULL;
return 0;
}
--
1.8.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
[PATCH v5 3/3] mtd: devices: elm: Low power transition support
From: avinash philip avinashphi...@ti.com
ELM is used for locating bit-flip errors in when using BCH ECC scheme.
This patch adds suspend/resume support for leaf level ELM driver,
And also provides ELM register context save restore support, so that
configurations are preserved across hardware power-off/on transitions.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/devices/elm.c | 117 ++
1 file changed, 117 insertions(+)
diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index dccef9f..e6a7b89 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -20,14 +20,21 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/of.h
+#include linux/sched.h
#include linux/pm_runtime.h
#include linux/platform_data/elm.h
+#define ELM_SYSCONFIG 0x010
#define ELM_IRQSTATUS 0x018
#define ELM_IRQENABLE 0x01c
#define ELM_LOCATION_CONFIG0x020
#define ELM_PAGE_CTRL 0x080
#define ELM_SYNDROME_FRAGMENT_00x400
+#define ELM_SYNDROME_FRAGMENT_10x404
+#define ELM_SYNDROME_FRAGMENT_20x408
+#define ELM_SYNDROME_FRAGMENT_30x40c
+#define ELM_SYNDROME_FRAGMENT_40x410
+#define ELM_SYNDROME_FRAGMENT_50x414
#define ELM_SYNDROME_FRAGMENT_60x418
#define ELM_LOCATION_STATUS0x800
#define ELM_ERROR_LOCATION_0 0x880
@@ -56,12 +63,27 @@
#define SYNDROME_FRAGMENT_REG_SIZE 0x40
#define ERROR_LOCATION_SIZE0x100
+struct elm_registers {
+ u32 elm_irqenable;
+ u32 elm_sysconfig;
+ u32 elm_location_config;
+ u32 elm_page_ctrl;
+ u32 elm_syndrome_fragment_6[ERROR_VECTOR_MAX];
+ u32 elm_syndrome_fragment_5[ERROR_VECTOR_MAX];
+ u32 elm_syndrome_fragment_4[ERROR_VECTOR_MAX];
+ u32 elm_syndrome_fragment_3[ERROR_VECTOR_MAX];
+ u32 elm_syndrome_fragment_2[ERROR_VECTOR_MAX];
+ u32 elm_syndrome_fragment_1[ERROR_VECTOR_MAX];
+ u32 elm_syndrome_fragment_0[ERROR_VECTOR_MAX];
+};
+
struct elm_info {
struct device *dev;
void __iomem *elm_base;
struct completion elm_completion;
struct list_head list;
enum bch_ecc bch_type;
+ struct elm_registers elm_regs;
};
static LIST_HEAD(elm_devices);
@@ -385,6 +407,100 @@ static int elm_remove(struct platform_device *pdev)
return 0;
}
+/**
+ * elm_context_save
+ * saves ELM configurations to preserve them across Hardware powered-down
+ */
+static int elm_context_save(struct elm_info *info)
+{
+ struct elm_registers *regs = info-elm_regs;
+ enum bch_ecc bch_type = info-bch_type;
+ u32 offset = 0, i;
+
+ regs-elm_irqenable = elm_read_reg(info, ELM_IRQENABLE);
+ regs-elm_sysconfig = elm_read_reg(info, ELM_SYSCONFIG);
+ regs-elm_location_config = elm_read_reg(info, ELM_LOCATION_CONFIG);
+ regs-elm_page_ctrl = elm_read_reg(info, ELM_PAGE_CTRL);
+ for (i = 0; i ERROR_VECTOR_MAX; i++) {
+ offset = i * SYNDROME_FRAGMENT_REG_SIZE;
+ switch (bch_type) {
+ case BCH8_ECC:
+ regs-elm_syndrome_fragment_3[i] = elm_read_reg(info,
+ ELM_SYNDROME_FRAGMENT_3 + offset);
+ regs-elm_syndrome_fragment_2[i] = elm_read_reg(info,
+ ELM_SYNDROME_FRAGMENT_2 + offset);
+ case BCH4_ECC:
+ regs-elm_syndrome_fragment_1[i] = elm_read_reg(info,
+ ELM_SYNDROME_FRAGMENT_1 + offset);
+ regs-elm_syndrome_fragment_0[i] = elm_read_reg(info,
+ ELM_SYNDROME_FRAGMENT_0 + offset);
+ default:
+ return -EINVAL;
+ }
+ /* ELM SYNDROME_VALID bit in SYNDROME_FRAGMENT_6[] needs
+* to be saved for all BCH schemes*/
+ regs-elm_syndrome_fragment_6[i] = elm_read_reg(info,
+ ELM_SYNDROME_FRAGMENT_6 + offset);
+ }
+ return 0;
+}
+
+/**
+ * elm_context_restore
+ * writes configurations saved duing power-down back into ELM registers
+ */
+static int elm_context_restore(struct elm_info *info)
+{
+ struct elm_registers *regs = info-elm_regs;
+ enum bch_ecc bch_type = info-bch_type;
+ u32 offset = 0, i;
+
+ elm_write_reg(info, ELM_IRQENABLE, regs-elm_irqenable);
+ elm_write_reg(info, ELM_SYSCONFIG, regs-elm_sysconfig);
+ elm_write_reg(info, ELM_LOCATION_CONFIG, regs-elm_location_config);
+ elm_write_reg(info, ELM_PAGE_CTRL, regs-elm_page_ctrl);
+ for (i = 0; i ERROR_VECTOR_MAX; i++) {
+ offset =
[PATCH v5 2/3] arm: gpmc: Low power transition support
From: avinash philip avinashphi...@ti.com
GPMC is hardware controller for external memory interfaces.
This patch adds suspend/resume support for GPMC driver.
It also preserves GPMC register configurations across device low-power states
in which GPMC hardware can be powered-off.
gpmc_suspend()/gpmc_resume() are called by default by core PM framework as part
of driver's runtime PM callbacks.
Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 1380cee..9b579d0 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1655,6 +1655,24 @@ static int gpmc_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int gpmc_suspend(struct device *dev)
+{
+ omap3_gpmc_save_context();
+ pm_runtime_put_sync(dev);
+ return 0;
+}
+
+static int gpmc_resume(struct device *dev)
+{
+ pm_runtime_get_sync(dev);
+ omap3_gpmc_restore_context();
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(gpmc_pm_ops, gpmc_suspend, gpmc_resume);
+
static struct platform_driver gpmc_driver = {
.probe = gpmc_probe,
.remove = gpmc_remove,
@@ -1662,6 +1680,7 @@ static struct platform_driver gpmc_driver = {
.name = DEVICE_NAME,
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(gpmc_dt_ids),
+ .pm = gpmc_pm_ops,
},
};
@@ -1724,7 +1743,6 @@ static irqreturn_t gpmc_handle_irq(int irq, void *dev)
return IRQ_HANDLED;
}
-#ifdef CONFIG_ARCH_OMAP3
static struct omap3_gpmc_regs gpmc_context;
void omap3_gpmc_save_context(void)
@@ -1789,4 +1807,3 @@ void omap3_gpmc_restore_context(void)
}
}
}
-#endif /* CONFIG_ARCH_OMAP3 */
--
1.8.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
[PATCH v5 0/3] suspend/resume support for OMAP nand driver
This patch series adds runtime PM support (specifically suspend/resume) for GPMC and ELM drivers. [Patch 1/3]: Adds pm_runtime calls to handle GPMC module probe and remove [Patch 2/3]: Adds GPMC suspend/resume support. [Patch 3/3]: Adds ELM suspend/resume support. Tested on am335x-evm with NAND flash support, using following: echo devices /sys/power/pm_test echo mem /sys/power/state echo core/sys/power/pm_test echo mem /sys/power/state Changes since v4: - added save/restore to ELM suspend/resume - removed #ifdef CONFIG_ARCH_OMAP3 - updated changelog to be more descriptive Changes Since v3: - CONFIG_PM - CONFIG_PM_SLEEP - using struct dev_pm_ops via driver-pm, instead of struct platform_driver - rebased to 3.10-rc5 Changes Since v2: - Remove calll back of nand_suspend from omap2 nand driver, as the same call already done from suspend activity mtd class driver. [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/91405 avinash philip (3): ARM: OMAP2+: gpmc: Converts GPMC driver to pm_runtime capable arm: gpmc: Low power transition support mtd: devices: elm: Low power transition support arch/arm/mach-omap2/gpmc.c | 29 +-- drivers/mtd/devices/elm.c | 117 + 2 files changed, 142 insertions(+), 4 deletions(-) -- 1.8.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: [GIT PULL] mailbox driver framework for v3.10 merge window
On Sun, Jun 16, 2013 at 03:14:01PM -0500, Suman Anna wrote: Hi Tan, On 06/14/2013 04:32 AM, LF.Tan wrote: Hi Suman Thanks for your reply. I have took a look the patches you've mentioned in [1]. It is totally new framework from what is located in linux-next git tree now. Yes, that is correct. The framework is different, but functionality wise, you should be able to achieve the same (and a bit more). I noticed that we had accidentally merged the previous version of the framework, since it was never intended to sit in linux-next given the redesign underway. I dropped it on Friday, so it wasn't included in the latest build of linux-next, and should not be part of it from here on out. -Olof -- 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/dts: Add basic support for gta04 (Openmoko next generation) board.
Signed-off-by: Marek Belisko marek.beli...@open-nandra.com
---
Resending because patch wasn't applied yet and was first time sent
in January.
arch/arm/boot/dts/omap3-gta04.dts | 94 +++
1 file changed, 94 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-gta04.dts
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
new file mode 100644
index 000..9e7e3ec
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2013 Marek Belisko marek.beli...@open-nandra.com
+ *
+ * Based on omap3-beagle-xm.dts
+ *
+ * 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.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = OMAP3 GTA04;
+ compatible = ti,omap3-gta04, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512 MB */
+ };
+
+ gpio-keys {
+ compatible = gpio-keys;
+ #address-cells = 1;
+ #size-cells = 0;
+ aux-button {
+ label = AUX;
+ linux,code = 169;
+ gpios = gpio1 7 1;
+ gpio-key,wakeup;
+ };
+ };
+};
+
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+/include/ twl4030.dtsi
+
+i2c2 {
+ clock-frequency = 40;
+ /* Pressure Sensor */
+ bmp085@77 {
+ compatible = bosch,bmp085;
+ reg = 0x77;
+ };
+
+ /* leds */
+ tca6507@45 {
+ compatible = ti,tca6507;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x45;
+
+ gta04_led0: red_aux@0 {
+ label = gta04:red:aux;
+ reg = 0x0;
+ };
+
+ gta04_led1: green_aux@1 {
+ label = gta04:green:aux;
+ reg = 0x1;
+ };
+
+ gta04_led3: red_power@3 {
+ label = gta04:red:power;
+ reg = 0x3;
+ linux,default-trigger = default-on;
+ };
+
+ gta04_led4: green_power@4 {
+ label = gta04:green:power;
+ reg = 0x4;
+ };
+ };
+};
+
+i2c3 {
+ clock-frequency = 10;
+};
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ bus-width = 4;
+};
+
--
1.8.1.2
--
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
[no subject]
Loan Syndicacion Am AFG Guaranty Trust Bank, zu strukturieren wir Kreditlinien treffen Sie unsere Kunden spezifischen geschäftlichen Anforderungen und einen deutlichen Mehrwert für unsere Kunden Unternehmen. eine Division der AFG Finance und Private Bank plc. Wenn Sie erwägen, eine große Akquisition oder ein Großprojekt sind, können Sie brauchen eine erhebliche Menge an Kredit. AFG Guaranty Trust Bank setzen können zusammen das Syndikat, das die gesamte Kredit schnürt für Sie. Als Bank mit internationaler Reichweite, sind wir gekommen, um Darlehen zu identifizieren Syndizierungen als Teil unseres Kerngeschäfts und durch spitzte diese Zeile aggressiv sind wir an einem Punkt, wo wir kommen, um als erkannt haben Hauptakteur in diesem Bereich. öffnen Sie ein Girokonto heute mit einem Minimum Bankguthaben von 500 £ und Getup zu £ 10.000 als Darlehen und auch den Hauch einer Chance und gewann die Sterne Preis von £ 500.000 in die sparen und gewinnen promo in may.aply jetzt. mit dem Folowing Informationen über Rechtsanwalt steven lee das Konto Offizier. FULL NAME; Wohnadresse; E-MAIL-ADRESSE; Telefonnummer; Nächsten KINS; MUTTER MAIDEN NAME; Familienstand; BÜROADRESSE; ALTERNATIVE Telefonnummer; TO @ yahoo.com bar.stevenlee NOTE; ALLE Darlehen sind für 10JAHRE RATE VALID ANGEBOT ENDET BALD SO JETZT HURRY -- 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] mfd: twl4030: allow IRQ wake enable to succeed on subchip IRQs
Hi Kevin, On Fri, May 31, 2013 at 02:44:54PM -0700, Kevin Hilman wrote: The genirq IRQ wake method will default to failure if the irq_chip does not provide a set_wake method. However, for TWL4030 sub-chip IRQs, we want the wake enable to succeed even though we don't provide a set_wake method. This allows sub-chip IRQs to still be flagged as wakeup capable, and allow them to wakeup from suspend (or abort suspend if they fire during suspend.) To fix, use the IRQCHIP_SKIP_SET_WAKE flag in the irq_chip. Signed-off-by: Kevin Hilman khil...@linaro.org --- drivers/mfd/twl4030-irq.c | 1 + 1 file changed, 1 insertion(+) Applied to mfd-next, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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 v10 5/8] dmaengine: edma: Add TI EDMA device tree binding
On 6/17/2013 9:10 PM, Fernandes, Joel A wrote: Hi Arnd, -Original Message- From: Arnd Bergmann [mailto:a...@arndb.de] Sent: Monday, June 17, 2013 6:13 AM To: Fernandes, Joel A Cc: Tony Lindgren; Nori, Sekhar; Matt Porter; Grant Likely; Rob Herring; Vinod Koul; Mark Brown; Cousson, Benoit; Russell King; Rob Landley; Andrew Morton; Jason Kridner; Koen Kooi; Devicetree Discuss; Linux OMAP List; Linux ARM Kernel List; Linux DaVinci Kernel List; Linux Kernel Mailing List; Linux Documentation List; Linux MMC List; Linux SPI Devel List Subject: Re: [PATCH v10 5/8] dmaengine: edma: Add TI EDMA device tree binding On Friday 14 June 2013 21:32:47 Joel A Fernandes wrote: diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt new file mode 100644 index 000..ada0018 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -0,0 +1,26 @@ +TI EDMA + +Required properties: +- compatible : ti,edma3 +- ti,hwmods: Name of the hwmods associated to the EDMA +- ti,edma-regions: Number of regions +- ti,edma-slots: Number of slots + +Optional properties: +- ti,edma-xbar-event-map: Crossbar event to channel map You need to list #dma-cells as required here, and which values are accepted by the driver (I suppose only 1). You should also explain the format of the dma-specifier for a slave here for each possible value of #dma-cells. For each of the standard properties (reg, interrupts, dma-channels), list whether they are optional or required. Since the example has three interrupts, you should probably list how many interrupts need to be specified (minimum and maximum if the number is variable) and in what order to expect them. [Joel] Thanks for the suggestion, I updated it and it looks like this now: Required properties: - compatible : ti,edma3 - ti,hwmods: Name of the hwmods associated to the EDMA I have already asked for ti,hwmods to be made optional. Please see my comment from yesterday. Thanks, Sekhar -- 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 0/2] ARM: AM33XX: clock: Add debugSS data to clk and hwmod database
This patch adds DebugSS data to clock-tree and hwmod data files. Changes from RFC/V1 (No code change): - Based on comments, we have to follow DT and loadable module approach for debugSS module as well, so separated out 2 patches of clock-tree and hwmod data addition from the RFC patch-series. - Added Paul's Ack on clock-tree patch. - Rebased on top of Benoit's for-3.11/dts branch. Link to original RFC - http://archive.arm.linux.org.uk/lurker/message/20130304.113554.53c9ec25.en.html Vaibhav Hiremath (2): ARM: AM33XX: clock: Add debugSS clock nodes ARM: AM33XX: hwmod: Add hwmod data for debugSS arch/arm/mach-omap2/cclock33xx_data.c | 47 +-- arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 69 +++- 2 files changed, 89 insertions(+), 27 deletions(-) -- 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] ARM: AM33XX: clock: Add debugSS clock nodes
Represent debugSS clock interface as provided in
CM_WKUP_DEBUGSS_CLKCTRL register, includes
- Clock gate for optional DEBUG_CLKA and DBGSYSCLK
- Clock Mux for TRC_PMD and STM_PMD
- Clock divider for STM and TPIU
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/cclock33xx_data.c | 47 +---
1 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index af3544c..6fd0ed1 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -431,15 +431,11 @@ DEFINE_STRUCT_CLK(aes0_fck, dpll_core_ck_parents,
clk_ops_null);
* - Driver code is not yet migrated to use hwmod/runtime pm
* - Modules outside kernel access (to disable them by default)
*
- * - debugss
* - mmu (gfx domain)
* - cefuse
* - usbotg_fck (its additional clock and not really a modulemode)
* - ieee5000
*/
-DEFINE_CLK_GATE(debugss_ick, dpll_core_m4_ck, dpll_core_m4_ck, 0x0,
- AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, AM33XX_MODULEMODE_SWCTRL_SHIFT,
- 0x0, NULL);
DEFINE_CLK_GATE(mmu_fck, dpll_core_m4_ck, dpll_core_m4_ck, 0x0,
AM33XX_CM_GFX_MMUDATA_CLKCTRL, AM33XX_MODULEMODE_SWCTRL_SHIFT,
@@ -863,6 +859,42 @@ static struct clk_hw_omap wdt1_fck_hw = {
DEFINE_STRUCT_CLK(wdt1_fck, wdt_ck_parents, gpio_fck_ops);
/*
+ * debugss optional clocks
+ */
+DEFINE_CLK_GATE(dbg_sysclk_ck, sys_clkin_ck, sys_clkin_ck,
+ 0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
+ AM33XX_OPTFCLKEN_DBGSYSCLK_SHIFT, 0x0, NULL);
+
+DEFINE_CLK_GATE(dbg_clka_ck, dpll_core_m4_ck, dpll_core_m4_ck,
+ 0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
+ AM33XX_OPTCLK_DEBUG_CLKA_SHIFT, 0x0, NULL);
+
+static const char *stm_pmd_clock_mux_ck_parents[] = {
+ dbg_sysclk_ck, dbg_clka_ck,
+};
+
+DEFINE_CLK_MUX(stm_pmd_clock_mux_ck, stm_pmd_clock_mux_ck_parents, NULL, 0x0,
+ AM33XX_CM_WKUP_DEBUGSS_CLKCTRL, AM33XX_STM_PMD_CLKSEL_SHIFT,
+ AM33XX_STM_PMD_CLKSEL_WIDTH, 0x0, NULL);
+
+DEFINE_CLK_MUX(trace_pmd_clk_mux_ck, stm_pmd_clock_mux_ck_parents, NULL, 0x0,
+ AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
+ AM33XX_TRC_PMD_CLKSEL_SHIFT,
+ AM33XX_TRC_PMD_CLKSEL_WIDTH, 0x0, NULL);
+
+DEFINE_CLK_DIVIDER(stm_clk_div_ck, stm_pmd_clock_mux_ck,
+ stm_pmd_clock_mux_ck, 0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
+ AM33XX_STM_PMD_CLKDIVSEL_SHIFT,
+ AM33XX_STM_PMD_CLKDIVSEL_WIDTH, CLK_DIVIDER_POWER_OF_TWO,
+ NULL);
+
+DEFINE_CLK_DIVIDER(trace_clk_div_ck, trace_pmd_clk_mux_ck,
+ trace_pmd_clk_mux_ck, 0x0, AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
+ AM33XX_TRC_PMD_CLKDIVSEL_SHIFT,
+ AM33XX_TRC_PMD_CLKDIVSEL_WIDTH, CLK_DIVIDER_POWER_OF_TWO,
+ NULL);
+
+/*
* clkdev
*/
static struct omap_clk am33xx_clks[] = {
@@ -899,7 +931,6 @@ static struct omap_clk am33xx_clks[] = {
CLK(481cc000.d_can, NULL, dcan0_fck),
CLK(NULL, dcan1_fck,dcan1_fck),
CLK(481d.d_can, NULL, dcan1_fck),
- CLK(NULL, debugss_ick, debugss_ick),
CLK(NULL, pruss_ocp_gclk, pruss_ocp_gclk),
CLK(NULL, mcasp0_fck, mcasp0_fck),
CLK(NULL, mcasp1_fck, mcasp1_fck),
@@ -942,6 +973,12 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, clkout2_div_ck, clkout2_div_ck),
CLK(NULL, timer_32k_ck, clkdiv32k_ick),
CLK(NULL, timer_sys_ck, sys_clkin_ck),
+ CLK(NULL, dbg_sysclk_ck,dbg_sysclk_ck),
+ CLK(NULL, dbg_clka_ck, dbg_clka_ck),
+ CLK(NULL, stm_pmd_clock_mux_ck, stm_pmd_clock_mux_ck),
+ CLK(NULL, trace_pmd_clk_mux_ck, trace_pmd_clk_mux_ck),
+ CLK(NULL, stm_clk_div_ck, stm_clk_div_ck),
+ CLK(NULL, trace_clk_div_ck, trace_clk_div_ck),
};
--
1.7.0.4
--
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 2/2] ARM: AM33XX: hwmod: Add hwmod data for debugSS
In the original hwmod data file, DebugSS entry was disabled,
since we didn't (and do not) have SW to control it.
This patch enables it back with right data, so that it can be
controlled by different ways; and the suggested method it to
have modular driver for debugSS as well.
Refer to the link for more discussion on handling of debugSS -
https://patchwork.kernel.org/patch/2212111/
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 69 +++-
1 files changed, 47 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 075f7cc..2a4bf69 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -416,7 +416,6 @@ static struct omap_hwmod am33xx_adc_tsc_hwmod = {
*
*- cEFUSE (doesn't fall under any ocp_if)
*- clkdiv32k
- *- debugss
*- ocp watch point
*/
#if 0
@@ -460,27 +459,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = {
},
};
-/*
- * 'debugss' class
- * debug sub system
- */
-static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
- .name = debugss,
-};
-
-static struct omap_hwmod am33xx_debugss_hwmod = {
- .name = debugss,
- .class = am33xx_debugss_hwmod_class,
- .clkdm_name = l3_aon_clkdm,
- .main_clk = debugss_ick,
- .prcm = {
- .omap4 = {
- .clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
/* ocpwp */
static struct omap_hwmod_class am33xx_ocpwp_hwmod_class = {
.name = ocpwp,
@@ -598,6 +576,34 @@ static struct omap_hwmod am33xx_ocmcram_hwmod = {
},
};
+/*
+ * 'debugss' class
+ * debug sub system
+ */
+static struct omap_hwmod_opt_clk debugss_opt_clks[] = {
+ { .role = dbg_sysclk, .clk = dbg_sysclk_ck },
+ { .role = dbg_clka, .clk = dbg_clka_ck },
+};
+
+static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
+ .name = debugss,
+};
+
+static struct omap_hwmod am33xx_debugss_hwmod = {
+ .name = debugss,
+ .class = am33xx_debugss_hwmod_class,
+ .clkdm_name = l3_aon_clkdm,
+ .main_clk = trace_clk_div_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .opt_clks = debugss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(debugss_opt_clks),
+};
+
/* 'smartreflex' class */
static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = {
.name = smartreflex,
@@ -2382,6 +2388,24 @@ static struct omap_hwmod_ocp_if am33xx_l3_main__gfx = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l3_main - debugss */
+static struct omap_hwmod_addr_space am33xx_debugss_addrs[] = {
+ {
+ .pa_start = 0x4b00,
+ .pa_end = 0x4b00 + SZ_16M - 1,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+static struct omap_hwmod_ocp_if am33xx_l3_main__debugss = {
+ .master = am33xx_l3_main_hwmod,
+ .slave = am33xx_debugss_hwmod,
+ .clk= dpll_core_m4_ck,
+ .addr = am33xx_debugss_addrs,
+ .user = OCP_USER_MPU,
+};
+
/* l4 wkup - smartreflex0 */
static struct omap_hwmod_addr_space am33xx_smartreflex0_addrs[] = {
{
@@ -3533,6 +3557,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
am33xx_pruss__l3_main,
am33xx_wkup_m3__l4_wkup,
am33xx_gfx__l3_main,
+ am33xx_l3_main__debugss,
am33xx_l4_wkup__wkup_m3,
am33xx_l4_wkup__control,
am33xx_l4_wkup__smartreflex0,
--
1.7.0.4
--
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] MFD: Palmas: Add Interrupt feature
Hi Mark, Thanks for the review. -Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Monday, June 17, 2013 9:46 PM To: J, KEERTHY Cc: linux-omap@vger.kernel.org; ldewan...@nvidia.com; sa...@linux.intel.com; grant.lik...@secretlab.ca; swar...@nvidia.com; linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; g...@slimlogic.co.uk Subject: Re: [PATCH 1/4] MFD: Palmas: Add Interrupt feature On Mon, Jun 17, 2013 at 05:39:11PM +0530, J Keerthy wrote: Palmas PMICs have an INT line. This line is one single Interrupt line to the application processor. The interrupt feature enables to selectively request irq for only those specific chips which have INT line connected to a valid IRQ line of the application processor. Does the support for the interrupt line need to be explicitly flagged like this or can the driver not simply support an interrupt line not being configured? That would also support cases where the hardware has an interrupt line but the system integrator has opeted not to connect it for some reason which seems generally more flexible than doing things on a chip ID basis. I understand your point. The IRQ is passed from device tree node. Say if the chip for some reason is not connected to any valid IRQ line the driver might end up requesting for a wrong IRQ line. So should I be validating the irq entry populated from device tree? Explicitly checking on chip ID helps to avoid wrongly populated Device tree data. +/** + * DOC: Palmas PMIC feature types + * Is DOC: normal kerneldoc? Normal kerneldoc I shall remove DOC: Regards, Keerthy -- 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 v10 0/8] DMA Engine support for AM33XX
Joel, When you respin this, please base on top of Prabhakar's clean-up titled: ARM: edma: Convert to devm_* api. Or better still, include his patch in your series. Thanks, Sekhar -- 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
