RE: [PATCH v2] leds: leds-gpio: adopt pinctrl support
+Don Aisheng On Tue, Sep 11, 2012 at 01:10:12, Linus Walleij wrote: On Sat, Sep 1, 2012 at 10:16 AM, AnilKumar Ch anilku...@ti.com wrote: Adopt pinctrl support to leds-gpio driver based on leds-gpio device pointer, pinctrl driver configure SoC pins to GPIO mode according to definitions provided in .dts file. Signed-off-by: AnilKumar Ch anilku...@ti.com So looking back at this after Stephen posed a real good question, when you say configure SoC pins to GPIO mode, does that mean anything else than to mux them into GPIO mode? pinctrl-single.c driver sets mux mode as well as pin configuration like pull-up/pull-down, input/output and slew rate. In that case, have you considered augmenting pinctrl-single.c to implement .gpio_request_enable() .gpio_disable_free() and maybe also .gpio_set_direction() in its struct pinmux_ops pinmux backend? If not, why? Recently, I have gone through the details on implementing gpio_request_enable in pinctrl-single driver. To add this functionality we have to add gpio_range's to pinctrl driver. AM335x EVM supports total 128 GPIO pins (4 banks) and these are randomly distributed across AM33XX SoC pins. These are the concerns/questions I have:- 1. I haven't added yet but it will come to more than 30-40 pinctrl_gpio_range entries 2. If the silicon package is changed then these will change. 3. If the GPIO driver is common for multiple SoCs then these entries will be more more over SoC specific and driver has to change every time the gpio_range changes. I have gone through the Don Aisheng patch series, which adds pinctrl_dt_add_gpio_ranges support but not accepted yet. With this patch series we can overcome the driver changes. 4. The current pinctrl driver has support for these APIs pinctrl_request_gpio(), pinctrl_free_gpio(), pinctrl_gpio_direction_input/output() no API for slew rate control, pulled down/up control how can we handle this? 5. pinctrl-single driver has to modify to provide separate handles for pinmux and pinconfig. And we need separate pin configuration bit masks and values/flags to take care of pull-up/down, slew rate, receiver in/out and mux mode control. 6. This is for my understanding, on which node do we have to add pinctrl data i.e., pin mux-mode data. In leds-gpio node (mostly not) and if it is in gpio node then how can we pass pinmux data with the existing API pinctrl_request_gpio(gpio);? Here we are passing only gpio number. Few more driver patches are pending along with this (leds-gpio DT data additions according to this patch, similarly other drivers like matrix keypad and volume keys) Thanks AnilKumar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V5 2/5] OMAPDSS: Create new debug config options
The config option CONFIG_OMAP2_DSS_DEBUG_SUPPORT has been removed and replaced
with CONFIG_OMAP2_DSS_DEBUG and CONFIG_OMAP2_DSS_DEBUGFS. CONFIG_OMAP2_DSS_DEBUG
enables DEBUG flag and CONFIG_OMAP2_DSS_DEBUGFS enables creation of debugfs for
OMAPDSS. Both the config options are disabled by default and can be enabled
independently of one another as per convenience.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
changes from V4 to V5
* added depends on DEBUG_FS to OMAP2_DSS_DEBUGFS defintion in Kconfig so that
CONFIG_OMAP2_DSS_DEBUGFS check become cleaner
drivers/video/omap2/dss/Kconfig | 22 --
drivers/video/omap2/dss/Makefile |2 +-
drivers/video/omap2/dss/core.c |6 +++---
drivers/video/omap2/dss/dss.c|2 +-
drivers/video/omap2/dss/dss.h|2 +-
5 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/Kconfig b/drivers/video/omap2/dss/Kconfig
index 80f5390..7052487 100644
--- a/drivers/video/omap2/dss/Kconfig
+++ b/drivers/video/omap2/dss/Kconfig
@@ -18,16 +18,26 @@ config OMAP2_VRAM_SIZE
You can also set this with vram=bytes kernel argument, or
in the board file.
-config OMAP2_DSS_DEBUG_SUPPORT
-bool Debug support
- default y
+config OMAP2_DSS_DEBUG
+ bool Debug support
+ default n
+ help
+ This enables printing of debug messages. Alternatively, debug messages
+ can also be enabled by setting CONFIG_DYNAMIC_DEBUG and then setting
+ appropriate flags in debugfs/dynamic_debug/control.
+
+config OMAP2_DSS_DEBUGFS
+ bool Debugfs filesystem support
+ depends on DEBUG_FS
+ default n
help
- This enables debug messages. You need to enable printing
- with 'debug' module parameter.
+ This enables debugfs for OMAPDSS at debugfs/omapdss. This enables
+ querying about clock configuration and register configuration of dss,
+ dispc, dsi, hdmi and rfbi.
config OMAP2_DSS_COLLECT_IRQ_STATS
bool Collect DSS IRQ statistics
- depends on OMAP2_DSS_DEBUG_SUPPORT
+ depends on OMAP2_DSS_DEBUGFS
default n
help
Collect DSS IRQ statistics, printable via debugfs.
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index 86493e3..4070191 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -8,4 +8,4 @@ omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi.o \
hdmi_panel.o ti_hdmi_4xxx_ip.o
-ccflags-$(CONFIG_OMAP2_DSS_DEBUG_SUPPORT) += -DDEBUG
+ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index b2af72d..826d64f 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -138,7 +138,7 @@ int dss_set_min_bus_tput(struct device *dev, unsigned long
tput)
return 0;
}
-#if defined(CONFIG_DEBUG_FS) defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
+#if defined(CONFIG_OMAP2_DSS_DEBUGFS)
static int dss_debug_show(struct seq_file *s, void *unused)
{
void (*func)(struct seq_file *) = s-private;
@@ -193,7 +193,7 @@ int dss_debugfs_create_file(const char *name, void
(*write)(struct seq_file *))
return 0;
}
-#else /* CONFIG_DEBUG_FS CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
+#else /* CONFIG_OMAP2_DSS_DEBUGFS */
static inline int dss_initialize_debugfs(void)
{
return 0;
@@ -205,7 +205,7 @@ int dss_debugfs_create_file(const char *name, void
(*write)(struct seq_file *))
{
return 0;
}
-#endif /* CONFIG_DEBUG_FS CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
+#endif /* CONFIG_OMAP2_DSS_DEBUGFS */
/* PLATFORM DEVICE */
static int omap_dss_pm_notif(struct notifier_block *b, unsigned long v, void
*d)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 2ab1c3e..3954742 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -746,7 +746,7 @@ static void dss_runtime_put(void)
}
/* DEBUGFS */
-#if defined(CONFIG_DEBUG_FS) defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
+#if defined(CONFIG_OMAP2_DSS_DEBUGFS)
void dss_debug_dump_clocks(struct seq_file *s)
{
dss_dump_clocks(s);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index ffbba7e..685275e 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -301,7 +301,7 @@ enum dss_hdmi_venc_clk_source_select
dss_get_hdmi_venc_clk_source(void);
const char *dss_get_generic_clk_source_name(enum omap_dss_clk_source clk_src);
void dss_dump_clocks(struct seq_file *s);
-#if defined(CONFIG_DEBUG_FS) defined(CONFIG_OMAP2_DSS_DEBUG_SUPPORT)
+#if defined(CONFIG_OMAP2_DSS_DEBUGFS)
void dss_debug_dump_clocks(struct seq_file *s);
#endif
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
On Mon, Oct 1, 2012 at 9:03 AM, AnilKumar, Chimata anilku...@ti.com wrote: I have gone through the Don Aisheng patch series, which adds pinctrl_dt_add_gpio_ranges support but not accepted yet. With this patch series we can overcome the driver changes. OK then this is the direction we need to go. 4. The current pinctrl driver has support for these APIs pinctrl_request_gpio(), pinctrl_free_gpio(), pinctrl_gpio_direction_input/output() no API for slew rate control, pulled down/up control how can we handle this? You are not supposed to handle that from the GPIO level of the API. That is supposed to be handled by pinctrl. These two subsystems are orthogonal, with the exception of the above calls. If you need to pass more information between the GPIO and pinctrl interfaces it usually means you're doing something wrong. The reason why pinctrl was created in the first place was that Grant didn't like that we started to shoehorn all kind of pin control into the GPIO subsystem. 5. pinctrl-single driver has to modify to provide separate handles for pinmux and pinconfig. And we need separate pin configuration bit masks and values/flags to take care of pull-up/down, slew rate, receiver in/out and mux mode control. OK that is typical pinctrl driver implementation work. I hope Tony can advice on this? 6. This is for my understanding, on which node do we have to add pinctrl data i.e., pin mux-mode data. In leds-gpio node (mostly not) and if it is in gpio node then how can we pass pinmux data with the existing API pinctrl_request_gpio(gpio);? Here we are passing only gpio number. So with the pinctrl_request_gpio() call you are requesting a single pin to be used as GPIO, nothing else. No additional data should be passed with that call. Implementing it is up to the pinctrl driver, the pinctrl subsystem API does not say anything about how this should be done, but there are a few examples. The pinctrl maps of muxes and config from the pin control subsystem are for entire devices, and the single-pin GPIO reservation API is orthogonal to this, please consult Documentation/pinctrl.txt if you are uncertain about what I mean with this, I've really tried to explain it there. The docs were recently amended to reflect some corner-case GPIO uses, see e.g.: http://marc.info/?l=linux-arm-kernelm=134763067415678w=2 Few more driver patches are pending along with this (leds-gpio DT data additions according to this patch, similarly other drivers like matrix keypad and volume keys) OK so the threshold is that we need to get it right for the first one and then the others will look good too. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: OMAP: DMA: Move plat/dma hearder to platform_data/dma-omap
On Sat, Sep 29, 2012 at 10:27 PM, Tony Lindgren t...@atomide.com wrote: * Jon Hunter jon-hun...@ti.com [120928 12:36]: On 09/28/2012 10:54 AM, Russell King - ARM Linux wrote: On Fri, Sep 28, 2012 at 08:05:38AM -0700, Tony Lindgren wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120928 08:02]: On Fri, Sep 28, 2012 at 8:25 PM, Tony Lindgren t...@atomide.com wrote: * Lokesh Vutla lokeshvu...@ti.com [120928 06:41]: Move plat/dma.h header to platform_data/dma-omap.h as part of the single zImage work. Hmm there's no platform data in this header, just exported things for drivers to use. So it should not be placed into platform_data. Maybe it should be #include asm/mach/dma-omap.h for now? I wasn't sure either when the file was placed under platform-data. I agree for now we can keep it mach layer but than means OMAP1 and OMAP2+ DMA header and source code needs to be split. That is not so straight forward. No need for that, the path I'm suggesting is located under arch/arm/include/asm/mach, it's not same as include mach/dma-omap.h. With DMA engine conversion hopefully, we might get rid of the header eventually, but for now not sure whether we should go ahead and follow the splitting part. Thoughts ? No need for splitting anything :) The other possible location would be just include linux/dma-omap.h, but as we all know that will be going away, asm/mach/dma-omap.h is probably better. No, not asm/mach/anything, please. Let's try to get headers into the right place second time around. This header appears to contain: 1. definitions for DMA signals, used by drivers. This can be eliminated by using DT, platform data, or IORESOURCE_DMA (that's in preference order) which then means that these definitions can live in a header file in arch/arm/mach-omap*/ if at all. 2. data definitions and structures used by drivers using the legacy OMAP DMA API. So, it doesn't contain platform data (as said above). It's not an API definition between core ARM code and ARM platform code, so that rules out arch/arm/include/asm/mach. Obviously arch/arm/include/asm is out of the question too. I don't think we have a clear cut place for this to live - and lets be clear that this file will eventually be going away _anyway_ when OMAP is converted 100% to DMA engine. So, where to put the file? At the moment, I don't know, it doesn't seem to have an obvious home other than where it currently is, which then gets in the way of the single kernel work. I am having the same problem with the OMAP dmtimer platform driver that the legacy DMA driver has. It is slightly worse as currently it is pure custom platform driver. Obviously long-term it would be best to create a generic timer driver in drivers/timer/ that other devices and architectures could use but we are a long way from that. I know that this is ugly and has probably already been shot-down, but as a short-term fix, has creating arch/arm/plat-omap/include/plat-omap been NAK'ed for such problematic drivers? Sounds like that's the way to go then. What we did not want to do is just move all the files blindly there, but for these files that seems like the way to go until they are just regular device drivers. Ok, Ill follow this. ll move plat/dma.h to plat-omap/dma-omap.h Thanks Lokesh 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: rcu self-detected stall messages on OMAP3, 4 boards
On Sat, Sep 22, 2012 at 11:59 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: rcu: Fix day-one dyntick-idle stall-warning bug As mentioned in another thread this solves the same problem for ux500. Reported/Tested-by: Linus Walleij linus.wall...@linaro.org But now it appears that this commit didn't make it into v3.6 so it definately needs to be tagged with Cc: sta...@kernel.org before it gets merged since the stall warnings are kinda scary. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] usb: dwc3-omap: use of_platform API to create dwc3 core pdev
Hi, On Fri, Sep 28, 2012 at 07:01:04PM +0530, ABRAHAM, KISHON VIJAY wrote: Hi, On Fri, Sep 28, 2012 at 6:27 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Fri, Sep 28, 2012 at 06:23:10PM +0530, Kishon Vijay Abraham I wrote: Used of_platform_populate() to populate dwc3 core platform_device from device tree data. Since now the allocation of unique device id is handled be of_*, removed the call to dwc3_get_device_id. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com I think it's best if you split the use of device_for_each_child() from this patch. So first do the device_for_each_child() part, then later use of_platform_populate(). I think it's better to have it both together as of_platform_populate will create the device and the device_for_each_child() part will delete it on error conditions and during driver removal. In this patch the first device_for_each_child() comes in error condition and it is not needed if we have not created the device using of_platform_populate. We are already parent of a device and we already handle child removal manually. You can change the current implementation to use device_for_each_child() and on a later patch introduce of_platform_populate(). -- balbi signature.asc Description: Digital signature
[PATCH] usb: otg: Resolving a config conflict between omap4030_usb/omap6030 and usb_musb_omap2plus
From: Jerome Kurtz jrm.ku...@gmail.com When I try to compile with TWL6030_USB=y, TWL4030_USB=y and USB_MUSB_OMAP2PLUS=m, I get the following error: drivers/built-in.o: In function `twl4030_usb_irq': /home/xxx/kernel/linux/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl6030_usb_irq': /home/xxx/kernel/linux/drivers/usb/otg/twl6030-usb.c:272: undefined reference to `omap_musb_mailbox' /home/xxx/kernel/linux/drivers/usb/otg/twl6030-usb.c:277: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl6030_usbotg_irq': /home/xxx/kernel/linux/drivers/usb/otg/twl6030-usb.c:306: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /home/xxx/kernel/linux/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' make: *** [vmlinux] Error 1 To solve this we must add to depends of TWL4030_USB and TWL6030_USB the option : USB_MUSB_OMAP2PLUS as done here. Signed-off-by: Jerome Kurtz jrm.ku...@gmail.com --- drivers/usb/otg/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index 13fd1ddf..62ea57b 100644 --- a/drivers/usb/otg/Kconfig +++ b/drivers/usb/otg/Kconfig @@ -58,7 +58,7 @@ config USB_ULPI_VIEWPORT config TWL4030_USB tristate TWL4030 USB Transceiver Driver - depends on TWL4030_CORE REGULATOR_TWL4030 + depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL4030 @@ -68,7 +68,7 @@ config TWL4030_USB config TWL6030_USB tristate TWL6030 USB Transceiver Driver - depends on TWL4030_CORE + depends on TWL4030_CORE USB_MUSB_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL6030 -- 1.7.2.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] usb: otg: Resolving a config conflict between omap4030_usb/omap6030 and usb_musb_omap2plus
Hello, From: Jerome Kurtz jrm.ku...@gmail.com When I try to compile with TWL6030_USB=y, TWL4030_USB=y and USB_MUSB_OMAP2PLUS=m, I get the following error: there is an earlier patch here: https://patchwork.kernel.org/patch/1370291/ and an alternative fix here: https://patchwork.kernel.org/patch/1409671/ regards, p. drivers/built-in.o: In function `twl4030_usb_irq': /home/xxx/kernel/linux/drivers/usb/otg/twl4030-usb.c:518: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl6030_usb_irq': /home/xxx/kernel/linux/drivers/usb/otg/twl6030-usb.c:272: undefined reference to `omap_musb_mailbox' /home/xxx/kernel/linux/drivers/usb/otg/twl6030-usb.c:277: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl6030_usbotg_irq': /home/xxx/kernel/linux/drivers/usb/otg/twl6030-usb.c:306: undefined reference to `omap_musb_mailbox' drivers/built-in.o: In function `twl4030_usb_phy_init': /home/xxx/kernel/linux/drivers/usb/otg/twl4030-usb.c:540: undefined reference to `omap_musb_mailbox' make: *** [vmlinux] Error 1 To solve this we must add to depends of TWL4030_USB and TWL6030_USB the option : USB_MUSB_OMAP2PLUS as done here. Signed-off-by: Jerome Kurtz jrm.ku...@gmail.com --- drivers/usb/otg/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig index 13fd1ddf..62ea57b 100644 --- a/drivers/usb/otg/Kconfig +++ b/drivers/usb/otg/Kconfig @@ -58,7 +58,7 @@ config USB_ULPI_VIEWPORT config TWL4030_USB tristate TWL4030 USB Transceiver Driver - depends on TWL4030_CORE REGULATOR_TWL4030 + depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL4030 @@ -68,7 +68,7 @@ config TWL4030_USB config TWL6030_USB tristate TWL6030 USB Transceiver Driver - depends on TWL4030_CORE + depends on TWL4030_CORE USB_MUSB_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the USB OTG transceiver on TWL6030 -- Peter Meerwald +43-664-218 (mobile) -- 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: Help needed with remaining plat headers
Hi, On 09/28/2012 09:58 AM, Vutla, Lokesh wrote: Hi, I see a module build failure in linux-next tree. Any one else facing this issue or I am missing something. Using master branch on git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Below is the log . $ make modules -j 10 ERROR: snd_hwparams_to_dma_slave_config [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_pointer [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_open [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_close [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_get_chan [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_trigger [sound/soc/omap/snd-soc-omap.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 I have sent a patch fixing this (which also affect other platforms as well): http://mailman.alsa-project.org/pipermail/alsa-devel/2012-October/055902.html -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 0/8] ARM: OMAP4: Add PMU Support
On Mon, Sep 24, 2012 at 10:45:06PM +0100, Jon Hunter wrote: On 09/20/2012 04:09 PM, Will Deacon wrote: On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote: Have queued most of these for 3.7 with the exception of the OMAP4430 CTI-related patches (which look to me like 3.8 material) and the PM runtime suspend/resume patch (which looks to me like 3.7-rc material) -- assuming this series makes it in for 3.7 ... Ok, thanks for queueing what you did. Jon -- could you pick the pieces up from what's left please and shout if you need anything from me? Yes will do. Great, thanks! Do you want me to do anything with my perf/omap4 branch? Now that we have 3.6, I can try rebasing it but I don't know if it's worth the effort if some of the patches are being reworked. Of course, I'm happy to pick newer versions if they're available. Cheers, Will -- 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 7/7] usb: dwc3: core: add dt support for dwc3 core
Added dwc3 support for dwc3 core and update the documentation with
device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt | 23 +++
drivers/usb/dwc3/core.c| 14 --
2 files changed, 35 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
new file mode 100644
index 000..9ec9316
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -0,0 +1,23 @@
+synopsys DWC3 CORE
+
+DWC3- USB3 CONTROLLER
+
+Required properties:
+ - compatible: must be synopsys,dwc3
+ - reg : Address and length of the register set for the device
+ - interrupts: Interrupts used by the dwc3 controller.
+ - interrupt-parent: the phandle for the interrupt controller that
+ services interrupts for this device.
+
+Optional properties:
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+
+This is usually a subnode to DWC3 glue to which it is connected.
+
+dwc3@4a03 {
+ compatible = synopsys,dwc3;
+ reg = 0x4a03 0xcfff;
+ interrupts = 0 92 4
+ interrupt-parent = gic
+ tx-fifo-resize;
+};
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 08a5738..4335a17 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -484,8 +484,7 @@ static int __devinit dwc3_probe(struct platform_device
*pdev)
else
dwc-maximum_speed = DWC3_DCFG_SUPERSPEED;
- if (of_get_property(node, tx-fifo-resize, NULL))
- dwc-needs_fifo_resize = true;
+ dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize);
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
@@ -602,11 +601,22 @@ static int __devexit dwc3_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id of_dwc3_match[] = {
+ {
+ .compatible = synopsys,dwc3
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_dwc3_match);
+#endif
+
static struct platform_driver dwc3_driver = {
.probe = dwc3_probe,
.remove = __devexit_p(dwc3_remove),
.driver = {
.name = dwc3,
+ .of_match_table = of_match_ptr(of_dwc3_match),
},
};
--
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/7] usb: dwc3-omap: use of_platform API to create dwc3 core pdev
Used of_platform_populate() to populate dwc3 core platform_device
from device tree data. Since now the allocation of unique device id is
handled be of_*, removed the call to dwc3_get_device_id.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 52 --
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index e335da3..cb4037a 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -47,6 +47,7 @@
#include linux/ioport.h
#include linux/io.h
#include linux/of.h
+#include linux/of_platform.h
#include core.h
@@ -130,7 +131,6 @@ struct dwc3_omap {
/* device lock */
spinlock_t lock;
- struct platform_device *dwc3;
struct device *dev;
int irq;
@@ -218,12 +218,10 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
struct dwc3_omap_data *pdata = pdev-dev.platform_data;
struct device_node *node = pdev-dev.of_node;
- struct platform_device *dwc3;
struct dwc3_omap*omap;
struct resource *res;
struct device *dev = pdev-dev;
- int devid;
int size;
int ret = -ENOMEM;
int irq;
@@ -260,34 +258,19 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
return -ENOMEM;
}
- devid = dwc3_get_device_id();
- if (devid 0)
- return -ENODEV;
-
- dwc3 = platform_device_alloc(dwc3, devid);
- if (!dwc3) {
- dev_err(dev, couldn't allocate dwc3 device\n);
- goto err1;
- }
-
context = devm_kzalloc(dev, resource_size(res), GFP_KERNEL);
if (!context) {
dev_err(dev, couldn't allocate dwc3 context memory\n);
- goto err2;
+ return -ENOMEM;
}
spin_lock_init(omap-lock);
- dma_set_coherent_mask(dwc3-dev, dev-coherent_dma_mask);
- dwc3-dev.parent = dev;
- dwc3-dev.dma_mask = dev-dma_mask;
- dwc3-dev.dma_parms = dev-dma_parms;
omap-resource_size = resource_size(res);
omap-context = context;
omap-dev = dev;
omap-irq = irq;
omap-base = base;
- omap-dwc3 = dwc3;
reg = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
@@ -332,7 +315,7 @@ static int __devinit dwc3_omap_probe(struct platform_device
*pdev)
if (ret) {
dev_err(dev, failed to request IRQ #%d -- %d\n,
omap-irq, ret);
- goto err2;
+ return ret;
}
/* enable all IRQs */
@@ -351,35 +334,20 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_SET_1, reg);
- ret = platform_device_add_resources(dwc3, pdev-resource,
- pdev-num_resources);
- if (ret) {
- dev_err(dev, couldn't add resources to dwc3 device\n);
- goto err2;
- }
-
- ret = platform_device_add(dwc3);
- if (ret) {
- dev_err(dev, failed to register dwc3 device\n);
- goto err2;
+ if (node) {
+ ret = of_platform_populate(node, NULL, NULL, dev);
+ if (ret) {
+ dev_err(pdev-dev,
+ failed to add create dwc3 core\n);
+ return ret;
+ }
}
return 0;
-
-err2:
- platform_device_put(dwc3);
-
-err1:
- dwc3_put_device_id(devid);
-
- return ret;
}
static int __devexit dwc3_omap_remove(struct platform_device *pdev)
{
- struct dwc3_omap*omap = platform_get_drvdata(pdev);
-
- dwc3_put_device_id(omap-dwc3-id);
device_for_each_child(pdev-dev, NULL, dwc3_omap_remove_core);
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] usb: dwc3-omap: Add an API to write to dwc mailbox
Add an API in the omap glue layer to write to the mailbox register which
can be used by comparator driver(twl). To pass the detection of the attached
device (signified by VBUS, ID) to the dwc3 core, dwc3 core has to write
to the mailbox regiter.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 59 +
include/linux/usb/dwc3-omap.h | 30 +
2 files changed, 89 insertions(+)
create mode 100644 include/linux/usb/dwc3-omap.h
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index d417bec..c19affa 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,6 +43,7 @@
#include linux/spinlock.h
#include linux/platform_device.h
#include linux/platform_data/dwc3-omap.h
+#include linux/usb/dwc3-omap.h
#include linux/pm_runtime.h
#include linux/dma-mapping.h
#include linux/ioport.h
@@ -126,6 +127,8 @@ struct dwc3_omap {
u32 dma_status:1;
};
+struct dwc3_omap *_omap;
+
static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
{
return readl(base + offset);
@@ -136,6 +139,56 @@ static inline void dwc3_omap_writel(void __iomem *base,
u32 offset, u32 value)
writel(value, base + offset);
}
+void dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+{
+ u32 val;
+ struct dwc3_omap*omap = _omap;
+
+ switch (status) {
+ case OMAP_DWC3_ID_GROUND:
+ dev_dbg(omap-dev, ID GND\n);
+
+ val = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
+ val = ~(USBOTGSS_UTMI_OTG_STATUS_IDDIG
+ | USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_SESSEND);
+ val |= USBOTGSS_UTMI_OTG_STATUS_SESSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_POWERPRESENT;
+ dwc3_omap_writel(omap-base, USBOTGSS_UTMI_OTG_STATUS, val);
+ break;
+
+ case OMAP_DWC3_VBUS_VALID:
+ dev_dbg(omap-dev, VBUS Connect\n);
+
+ val = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
+ val = ~USBOTGSS_UTMI_OTG_STATUS_SESSEND;
+ val |= USBOTGSS_UTMI_OTG_STATUS_IDDIG
+ | USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_SESSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_POWERPRESENT;
+ dwc3_omap_writel(omap-base, USBOTGSS_UTMI_OTG_STATUS, val);
+ break;
+
+ case OMAP_DWC3_ID_FLOAT:
+ case OMAP_DWC3_VBUS_OFF:
+ dev_dbg(omap-dev, VBUS Disconnect\n);
+
+ val = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
+ val = ~(USBOTGSS_UTMI_OTG_STATUS_SESSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
+ | USBOTGSS_UTMI_OTG_STATUS_POWERPRESENT);
+ val |= USBOTGSS_UTMI_OTG_STATUS_SESSEND
+ | USBOTGSS_UTMI_OTG_STATUS_IDDIG;
+ dwc3_omap_writel(omap-base, USBOTGSS_UTMI_OTG_STATUS, val);
+ break;
+
+ default:
+ dev_dbg(omap-dev, ID float\n);
+ }
+
+ return;
+}
+EXPORT_SYMBOL_GPL(dwc3_omap_mailbox);
static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
{
@@ -256,6 +309,12 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
omap-irq = irq;
omap-base = base;
+ /*
+* REVISIT if we ever have two instances of the wrapper, we will be
+* in big trouble
+*/
+ _omap = omap;
+
pm_runtime_enable(dev);
ret = pm_runtime_get_sync(dev);
if (ret 0) {
diff --git a/include/linux/usb/dwc3-omap.h b/include/linux/usb/dwc3-omap.h
new file mode 100644
index 000..6ebcf73
--- /dev/null
+++ b/include/linux/usb/dwc3-omap.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2011-2012 by Texas Instruments
+ *
+ * The Inventra Controller Driver for Linux is free software; you
+ * can redistribute it and/or modify it under the terms of the GNU
+ * General Public License version 2 as published by the Free Software
+ * Foundation.
+ */
+
+#ifndef __DWC3_OMAP_H__
+#define __DWC3_OMAP_H__
+
+enum omap_dwc3_vbus_id_status {
+ OMAP_DWC3_UNKNOWN = 0,
+ OMAP_DWC3_ID_GROUND,
+ OMAP_DWC3_ID_FLOAT,
+ OMAP_DWC3_VBUS_VALID,
+ OMAP_DWC3_VBUS_OFF,
+};
+
+#if (defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_DWC3_MODULE))
+void dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status);
+#else
+static inline void dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+{
+ return;
+}
+#endif
+
+#endif /* __DWC3_OMAP_H__ */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[PATCH v2 3/7] usb: dwc3-omap: use runtime API's to enable clocks
Before accessing any register, runtime API's should be invoked to enable
the clocks. runtime API's are added here to prevent abort during register
access.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index cb4037a..850a0cf 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,6 +43,7 @@
#include linux/spinlock.h
#include linux/platform_device.h
#include linux/platform_data/dwc3-omap.h
+#include linux/pm_runtime.h
#include linux/dma-mapping.h
#include linux/ioport.h
#include linux/io.h
@@ -272,6 +273,13 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
omap-irq = irq;
omap-base = base;
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (ret 0) {
+ dev_err(dev, get_sync failed with err %d\n, ret);
+ return ret;
+ }
+
reg = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
utmi_mode = of_get_property(node, utmi-mode, size);
@@ -348,6 +356,8 @@ static int __devinit dwc3_omap_probe(struct platform_device
*pdev)
static int __devexit dwc3_omap_remove(struct platform_device *pdev)
{
+ pm_runtime_put_sync(pdev-dev);
+ pm_runtime_disable(pdev-dev);
device_for_each_child(pdev-dev, NULL, dwc3_omap_remove_core);
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] usb: dwc3-omap: add dt support
This patch series adds dt support to dwc3 core and fixes few minor stuff in dwc3-omap glue to get dwc3 working. While at that it also uses *of_platform* to create the child device (dwc3-core) and fixes to use runtime API's to enable clock and write to SYSCONFIG register. Changes from v1: * made device_for_each_child() as a seperate patch * made all other minor fixes wrt typos and function renames This patch series is developed on: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git dwc3 Kishon Vijay Abraham I (7): usb: dwc3-omap: use device_for_each_child to handle child removal usb: dwc3-omap: use of_platform API to create dwc3 core pdev usb: dwc3-omap: use runtime API's to enable clocks usb: dwc3-omap: Remove explicit writes to SYSCONFIG register usb: dwc3-omap: Add an API to write to dwc mailbox usb: dwc3-omap: Minor fixes to get dt working usb: dwc3: core: add dt support for dwc3 core Documentation/devicetree/bindings/usb/dwc3.txt | 23 drivers/usb/dwc3/core.c| 14 +- drivers/usb/dwc3/dwc3-omap.c | 167 +--- include/linux/usb/dwc3-omap.h | 30 + 4 files changed, 158 insertions(+), 76 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt create mode 100644 include/linux/usb/dwc3-omap.h -- 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 1/7] usb: dwc3-omap: use device_for_each_child to handle child removal
Used device_for_each_child() to handle child device (dwc3 core) removal
during devexit of dwc3 omap.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 479dc04..e335da3 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -204,6 +204,15 @@ static irqreturn_t dwc3_omap_interrupt(int irq, void
*_omap)
return IRQ_HANDLED;
}
+static int dwc3_omap_remove_core(struct device *dev, void *c)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ platform_device_unregister(pdev);
+
+ return 0;
+}
+
static int __devinit dwc3_omap_probe(struct platform_device *pdev)
{
struct dwc3_omap_data *pdata = pdev-dev.platform_data;
@@ -370,9 +379,8 @@ static int __devexit dwc3_omap_remove(struct
platform_device *pdev)
{
struct dwc3_omap*omap = platform_get_drvdata(pdev);
- platform_device_unregister(omap-dwc3);
-
dwc3_put_device_id(omap-dwc3-id);
+ device_for_each_child(pdev-dev, NULL, dwc3_omap_remove_core);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] usb: dwc3-omap: Minor fixes to get dt working
Includes few minor fixes in dwc3-omap like populating the compatible
string in a correct way, extracting the utmi-mode property properly and
changing the index of get_irq since irq of core is removed from hwmod
entry.
Also updated the documentation with dwc3-omap device tree binding
information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index c19affa..25bd847 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -277,13 +277,13 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, omap);
- irq = platform_get_irq(pdev, 1);
+ irq = platform_get_irq(pdev, 0);
if (irq 0) {
dev_err(dev, missing IRQ resource\n);
return -EINVAL;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, missing memory base resource\n);
return -EINVAL;
@@ -326,7 +326,7 @@ static int __devinit dwc3_omap_probe(struct platform_device
*pdev)
utmi_mode = of_get_property(node, utmi-mode, size);
if (utmi_mode size == sizeof(*utmi_mode)) {
- reg |= *utmi_mode;
+ reg |= be32_to_cpup(utmi_mode);
} else {
if (!pdata) {
dev_dbg(dev, missing platform data\n);
@@ -398,7 +398,7 @@ static int __devexit dwc3_omap_remove(struct
platform_device *pdev)
static const struct of_device_id of_dwc3_matach[] = {
{
- ti,dwc3,
+ .compatible = ti,dwc3
},
{ },
};
--
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 4/7] usb: dwc3-omap: Remove explicit writes to SYSCONFIG register
The runtime API's takes care of setting the SYSCONFIG register with
appropriate values. Hence explicit writes to SYSCONFIG register is
removed.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 850a0cf..d417bec 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -77,23 +77,6 @@
/* SYSCONFIG REGISTER */
#define USBOTGSS_SYSCONFIG_DMADISABLE (1 16)
-#define USBOTGSS_SYSCONFIG_STANDBYMODE(x) ((x) 4)
-
-#define USBOTGSS_STANDBYMODE_FORCE_STANDBY 0
-#define USBOTGSS_STANDBYMODE_NO_STANDBY1
-#define USBOTGSS_STANDBYMODE_SMART_STANDBY 2
-#define USBOTGSS_STANDBYMODE_SMART_WAKEUP 3
-
-#define USBOTGSS_STANDBYMODE_MASK (0x03 4)
-
-#define USBOTGSS_SYSCONFIG_IDLEMODE(x) ((x) 2)
-
-#define USBOTGSS_IDLEMODE_FORCE_IDLE 0
-#define USBOTGSS_IDLEMODE_NO_IDLE 1
-#define USBOTGSS_IDLEMODE_SMART_IDLE 2
-#define USBOTGSS_IDLEMODE_SMART_WAKEUP 3
-
-#define USBOTGSS_IDLEMODE_MASK (0x03 2)
/* IRQ_EOI REGISTER */
#define USBOTGSS_IRQ_EOI_LINE_NUMBER (1 0)
@@ -309,15 +292,6 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
reg = dwc3_omap_readl(omap-base, USBOTGSS_SYSCONFIG);
omap-dma_status = !!(reg USBOTGSS_SYSCONFIG_DMADISABLE);
- /* Set No-Idle and No-Standby */
- reg = ~(USBOTGSS_STANDBYMODE_MASK
- | USBOTGSS_IDLEMODE_MASK);
-
- reg |= (USBOTGSS_SYSCONFIG_STANDBYMODE(USBOTGSS_STANDBYMODE_NO_STANDBY)
- | USBOTGSS_SYSCONFIG_IDLEMODE(USBOTGSS_IDLEMODE_NO_IDLE));
-
- dwc3_omap_writel(omap-base, USBOTGSS_SYSCONFIG, reg);
-
ret = devm_request_irq(dev, omap-irq, dwc3_omap_interrupt, 0,
dwc3-omap, omap);
if (ret) {
--
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
[PATCHv3 0/4] Add mfd driver for smsc-ece1099 chip
Add a smsc-ece1099 mfd driver which will work as keypad scan device or a gpio expander device. Patch 1 creates the parent mfd driver. Patch 2 add keypad support. Patch 3 adds dts support for keypad in omap5 dts file. Patch 4 add gpio expansion driver for chip (RFC). Cc: Benoit Cousson b-cous...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com G, Manjunath Kondaiah (1): Input: keypad: Add smsc ece1099 keypad driver Sourav Poddar (3): mfd: smsc: Add support for smsc gpio io/keypad driver arm/dts: omap5-evm: Add keypad support gpio: smscece: Add support for gpio IO expander feature Documentation/smsc_ece1099.txt | 56 arch/arm/boot/dts/omap5-evm.dts | 95 +++ drivers/gpio/Kconfig |7 + drivers/gpio/Makefile|1 + drivers/gpio/gpio-smscece.c | 381 ++ drivers/input/keyboard/Kconfig | 11 + drivers/input/keyboard/Makefile |1 + drivers/input/keyboard/smsc-ece1099-keypad.c | 304 drivers/mfd/Kconfig | 12 + drivers/mfd/Makefile |1 + drivers/mfd/smsc-ece1099.c | 113 include/linux/mfd/smsc.h | 109 12 files changed, 1091 insertions(+), 0 deletions(-) create mode 100644 Documentation/smsc_ece1099.txt create mode 100644 drivers/gpio/gpio-smscece.c create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c create mode 100644 drivers/mfd/smsc-ece1099.c create mode 100644 include/linux/mfd/smsc.h -- 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
[PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
smsc ece1099 is a keyboard scan or gpio expansion device. The patch create keypad and gpio expander child for this multi function smsc driver. Tested on omap5430 evm with 3.6-rc6 custom kernel. Cc: Samuel Ortiz sa...@linux.intel.com Cc: Benoit Cousson b-cous...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sourav Poddar sourav.pod...@ti.com --- Changes since v2: - Change the cache type, max register assignment - remove of_device_table, since i2c based device gets probed according to i2c_device_id through dt. - Modify the remove function - Minor return patch cleanups. Documentation/smsc_ece1099.txt | 56 drivers/mfd/Kconfig| 12 drivers/mfd/Makefile |1 + drivers/mfd/smsc-ece1099.c | 113 include/linux/mfd/smsc.h | 109 ++ 5 files changed, 291 insertions(+), 0 deletions(-) create mode 100644 Documentation/smsc_ece1099.txt create mode 100644 drivers/mfd/smsc-ece1099.c create mode 100644 include/linux/mfd/smsc.h diff --git a/Documentation/smsc_ece1099.txt b/Documentation/smsc_ece1099.txt new file mode 100644 index 000..6b492e8 --- /dev/null +++ b/Documentation/smsc_ece1099.txt @@ -0,0 +1,56 @@ +What is smsc-ece1099? +-- + +The ECE1099 is a 40-Pin 3.3V Keyboard Scan Expansion +or GPIO Expansion device. The device supports a keyboard +scan matrix of 23x8. The device is connected to a Master +via the SMSC BC-Link interface or via the SMBus. +Keypad scan Input(KSI) and Keypad Scan Output(KSO) signals +are multiplexed with GPIOs. + +Interrupt generation + + +Interrupts can be generated by an edge detection on a GPIO +pin or an edge detection on one of the bus interface pins. +Interrupts can also be detected on the keyboard scan interface. +The bus interrupt pin (BC_INT# or SMBUS_INT#) is asserted if +any bit in one of the Interrupt Status registers is 1 and +the corresponding Interrupt Mask bit is also 1. + +In order for software to determine which device is the source +of an interrupt, it should first read the Group Interrupt Status Register +to determine which Status register group is a source for the interrupt. +Software should read both the Status register and the associated Mask register, +then AND the two values together. Bits that are 1 in the result of the AND +are active interrupts. Software clears an interrupt by writing a 1 to the +corresponding bit in the Status register. + +Communication Protocol +-- + +- SMbus slave Interface + The host processor communicates with the ECE1099 device + through a series of read/write registers via the SMBus + interface. SMBus is a serial communication protocol between + a computer host and its peripheral devices. The SMBus data + rate is 10KHz minimum to 400 KHz maximum + +- Slave Bus Interface + The ECE1099 device SMBus implementation is a subset of the + SMBus interface to the host. The device is a slave-only SMBus device. + The implementation in the device is a subset of SMBus since it + only supports four protocols. + + The Write Byte, Read Byte, Send Byte, and Receive Byte protocols are the + only valid SMBus protocols for the device. + +- BC-LinkTM Interface + The BC-Link is a proprietary bus that allows communication + between a Master device and a Companion device. The Master + device uses this serial bus to read and write registers + located on the Companion device. The bus comprises three signals, + BC_CLK, BC_DAT and BC_INT#. The Master device always provides the + clock, BC_CLK, and the Companion device is the source for an + independent asynchronous interrupt signal, BC_INT#. The ECE1099 + supports BC-Link speeds up to 24MHz. diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index b1a1462..dedc874 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -385,6 +385,18 @@ config MFD_T7L66XB help Support for Toshiba Mobile IO Controller T7L66XB +config MFD_SMSC + bool Support for the SMSC ECE1099 series chips + depends on I2C=y + select MFD_CORE + select REGMAP_I2C + help +If you say yes here you get support for the +ece1099 chips from SMSC. + +To compile this driver as a module, choose M here: the +module will be called smsc. + config MFD_TC6387XB bool Support Toshiba TC6387XB depends on ARM HAVE_CLK diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 79dd22d..3323345 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -77,6 +77,7 @@ obj-$(CONFIG_EZX_PCAP)+= ezx-pcap.o obj-$(CONFIG_MCP) += mcp-core.o obj-$(CONFIG_MCP_SA11X0) += mcp-sa11x0.o obj-$(CONFIG_MCP_UCB1200) += ucb1x00-core.o
[PATCHv3 2/4] Input: keypad: Add smsc ece1099 keypad driver
From: G, Manjunath Kondaiah manj...@ti.com
SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
supports a keypad scan matrix of 23*8.This driver uses this
device as a keypad driver.
Tested on omap5430 evm with 3.6-rc6 custom kernel.
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
Changes since v2:
- Replace magic numbers through driver variable.
- Provide comments for some initialisation done in probe.
drivers/input/keyboard/Kconfig | 11 +
drivers/input/keyboard/Makefile |1 +
drivers/input/keyboard/smsc-ece1099-keypad.c | 304 ++
3 files changed, 316 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index c50fa75..b03a39c 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -593,6 +593,17 @@ config KEYBOARD_TWL4030
To compile this driver as a module, choose M here: the
module will be called twl4030_keypad.
+config KEYBOARD_SMSC
+ tristate SMSC ECE1099 keypad support
+ depends on I2C
+ help
+ Say Y here if your board use the smsc keypad controller
+ for omap5 defconfig. It's safe to say enable this
+ even on boards that don't use the keypad controller.
+
+ To compile this driver as a module, choose M here: the
+ module will be called smsc-ece1099-keypad.
+
config KEYBOARD_XTKBD
tristate XT keyboard
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 44e7600..0f2aa26 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X)+=
tc3589x-keypad.o
obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
+obj-$(CONFIG_KEYBOARD_SMSC)+= smsc-ece1099-keypad.o
obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
diff --git a/drivers/input/keyboard/smsc-ece1099-keypad.c
b/drivers/input/keyboard/smsc-ece1099-keypad.c
new file mode 100644
index 000..15dc147
--- /dev/null
+++ b/drivers/input/keyboard/smsc-ece1099-keypad.c
@@ -0,0 +1,304 @@
+/*
+ * SMSC_ECE1099 Keypad driver
+ *
+ * Copyright (C) 2012 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 version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/i2c.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/input.h
+#include linux/gpio.h
+#include linux/slab.h
+#include linux/jiffies.h
+#include linux/input/matrix_keypad.h
+#include linux/delay.h
+#include linux/mfd/core.h
+#include linux/mfd/smsc.h
+#include linux/of_gpio.h
+#include linux/of.h
+
+#define KEYPRESS_TIME 200
+
+struct smsc_keypad {
+ struct smsc *smsc;
+ struct matrix_keymap_data *keymap_data;
+ unsigned int last_key_state[16];
+ unsigned int last_col;
+ unsigned int last_key_ms[16];
+ unsigned short *keymap;
+ struct i2c_client *client;
+ struct input_dev *input;
+ int rows, cols;
+ int row_shift;
+ bool no_autorepeat;
+ unsignedirq;
+ struct device *dev;
+};
+
+static void smsc_kp_scan(struct smsc_keypad *kp)
+{
+ struct input_dev *input = kp-input;
+ int i, j;
+ int row, col;
+ int temp, code;
+ unsigned int new_state[16];
+ unsigned int bits_changed;
+ int this_ms;
+
+ smsc_write(kp-dev, SMSC_KP_INT_MASK, 0x00);
+ smsc_write(kp-dev, SMSC_KP_INT_STAT, 0xFF);
+
+ /* Scan for row and column */
+ for (i = 0; i kp-cols; i++) {
+ smsc_write(kp-dev, SMSC_KP_OUT, SMSC_KSO_EVAL + i);
+ /* Read Row Status */
+ smsc_read(kp-dev, SMSC_KP_IN, temp);
+ if (temp == 0xFF)
+ continue;
+
+ col = i;
+ for (j = 0; j kp-rows; j++) {
+ if ((temp 0x01) != 0x00) {
+ temp = temp 1;
+ continue;
+ }
+
+ row = j;
+ new_state[col] = (1 row);
+ bits_changed = kp-last_key_state[col] ^ new_state[col];
+ this_ms = jiffies_to_msecs(jiffies);
+
[PATCHv3 3/4] arm/dts: omap5-evm: Add keypad support
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Tested on omap5430 evm with 3.6-rc6 custom kernel.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Tested on omap5430 sdp with 3.66 custom kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Changes since v2:
- Change the compatible string name.
arch/arm/boot/dts/omap5-evm.dts | 95 +++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 200c39a..2d8903b 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -18,3 +18,98 @@
reg = 0x8000 0x4000; /* 1 GB */
};
};
+
+i2c5 {
+ clock-frequency = 40;
+
+ smsc@38 {
+ compatible = smscece1099;
+ reg = 0x38;
+ clock = 0x13;
+ keypad {
+ compatible = smsc,keypad;
+ interrupt-parent = gpio5;
+ interrupts = 23; /* gpio line 151 */
+ keypad,num-rows = 8;
+ keypad,num-columns = 16;
+ linux,keymap = 0x20041 /* KEY_F7 */
+ 0x30001 /* KEY_ESC */
+ 0x4003e /* KEY_F4 */
+ 0x50022 /* KEY_G */
+ 0x70023 /* KEY_H */
+ 0x9009a /* KEY_CYCLEWINDOWS */
+ 0xc000e /* KEY_BACKSPACE */
+ 0xd0057 /* KEY_F11 */
+ 0xe009f /* KEY_FORWARD */
+ 0xf006e /* KEY_INSERT */
+ 0x1020036 /* KEY_RIGHTSHIFT */
+ 0x1030011 /* KEY_W */
+ 0x1040010 /* KEY_Q */
+ 0x1050012 /* KEY_E */
+ 0x1070013 /* KEY_R */
+ 0x1080016 /* KEY_U */
+ 0x10c0017 /* KEY_I */
+ 0x10d0067 /* KEY_UP */
+ 0x10e0018 /* KEY_O */
+ 0x10f0019 /* KEY_LEFT */
+ 0x2020003 /* KEY_2 */
+ 0x2040004 /* KEY_1 */
+ 0x2050005 /* KEY_3 */
+ 0x2070008 /* KEY_4 */
+ 0x2080009 /* KEY_7 */
+ 0x20b0064 /* KEY_8 */
+ 0x20c006c /* KEY_RIGHTALT */
+ 0x20d000a /* KEY_DOWN */
+ 0x20e0001 /* KEY_0 */
+ 0x20f006a /* KEY_RIGHT */
+ 0x3010061 /* KEY_RIGHTCTRL */
+ 0x302001f /* KEY_S */
+ 0x303001e /* KEY_A */
+ 0x3040020 /* KEY_D */
+ 0x3050021 /* KEY_F */
+ 0x3070024 /* KEY_J */
+ 0x3080025 /* KEY_K */
+ 0x30c001c /* KEY_ENTER */
+ 0x30d0026 /* KEY_L */
+ 0x30e0027 /* KEY_SEMICOLON */
+ 0x42a /* KEY_LEFTSHIFT */
+ 0x402002d /* KEY_X */
+ 0x403002c /* KEY_Z */
+ 0x404002e /* KEY_C */
+ 0x405002f /* KEY_V */
+ 0x4070032 /* KEY_M */
+ 0x4080033 /* KEY_COMMA */
+ 0x40c0039 /* KEY_SPACE */
+ 0x40d0033 /* KEY_DOT */
+ 0x40e0035 /* KEY_SLASH */
+ 0x40f006b /* KEY_END */
+ 0x501001d /* KEY_LEFTCTRL */
+ 0x5020040 /* KEY_F6 */
+ 0x503000f /* KEY_TAB */
+ 0x504003d /* KEY_F3 */
+ 0x5050014 /* KEY_T */
+ 0x5070015 /* KEY_Y */
+ 0x508001a /*
[RFC/PATCHv3 4/4] gpio: smscece: Add support for gpio IO expander feature
smsc can be used as an gpio io expander device also. So adding
support for configuring smsc pins as a gpio.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Changes since v2:
- Update the license.
- Minor ret patch changes.
drivers/gpio/Kconfig|7 +
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-smscece.c | 381 +++
3 files changed, 389 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/gpio-smscece.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ba7926f..68ea0a4 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -444,6 +444,13 @@ config GPIO_ADP5588_IRQ
Say yes here to enable the adp5588 to be used as an interrupt
controller. It requires the driver to be built in the kernel.
+config GPIO_SMSCECE
+ tristate SMSCECE 1099 I2C GPIO expander
+ depends on I2C
+ help
+ This option enables support for 18 GPIOs found
+ on SMSC ECE 1099 GPIO Expanders.
+
comment PCI GPIO expanders:
config GPIO_CS5535
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 153cace..7c803c5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
obj-$(CONFIG_GPIO_AB8500) += gpio-ab8500.o
obj-$(CONFIG_GPIO_ADP5520) += gpio-adp5520.o
obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
+obj-$(CONFIG_GPIO_SMSCECE) += gpio-smscece.o
obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
diff --git a/drivers/gpio/gpio-smscece.c b/drivers/gpio/gpio-smscece.c
new file mode 100644
index 000..54e377a
--- /dev/null
+++ b/drivers/gpio/gpio-smscece.c
@@ -0,0 +1,381 @@
+/*
+ * GPIO Chip driver for smsc
+ * SMSC I/O Expander and QWERTY Keypad Controller
+ *
+ * Copyright (C) 2012 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 version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/interrupt.h
+#include linux/irqdomain.h
+#include linux/irq.h
+#include linux/mfd/smsc.h
+#include linux/err.h
+
+struct smsc_gpio {
+ struct device *dev;
+ struct smsc *smsc;
+ struct gpio_chip gpio_chip;
+ struct mutex lock; /* protect cached dir, dat_out */
+ /* protect serialized access to the interrupt controller bus */
+ struct mutex irq_lock;
+ struct irq_domain *irq_domain;
+ unsigned gpio_start;
+ int type;
+ int flags;
+ int irq;
+ int irq_base;
+ unsigned int gpio_base;
+ unsigned int dat_out[5];
+ unsigned int dir[5];
+ unsigned int irq_trig_fall[5];
+ unsigned int irq_trig_raise[5];
+ unsigned int int_en[5];
+ unsigned int irq_mask[5];
+ unsigned int irq_stat[5];
+};
+
+static int smsc_gpio_get_value(struct gpio_chip *chip, unsigned off)
+{
+ struct smsc_gpio *sg =
+ container_of(chip, struct smsc_gpio, gpio_chip);
+ unsigned int get;
+ return !!(smsc_read(sg-dev,
+ (SMSC_GPIO_DATA_IN_START + SMSC_BANK(off)) SMSC_BIT(off),
+ get));
+}
+
+static void smsc_gpio_set_value(struct gpio_chip *chip,
+ unsigned off, int val)
+{
+ unsigned bank, bit;
+ struct smsc_gpio *sg =
+ container_of(chip, struct smsc_gpio, gpio_chip);
+
+ bank = SMSC_BANK(off);
+ bit = SMSC_BIT(off);
+
+ mutex_lock(sg-lock);
+ if (val)
+ sg-dat_out[bank] |= bit;
+ else
+ sg-dat_out[bank] = ~bit;
+
+ smsc_write(sg-dev, SMSC_GPIO_DATA_OUT_START + bank,
+ sg-dat_out[bank]);
+ mutex_unlock(sg-lock);
+}
+
+static int smsc_gpio_direction_input(struct gpio_chip *chip, unsigned off)
+{
+ unsigned int reg;
+ struct smsc_gpio *sg =
+ container_of(chip, struct smsc_gpio, gpio_chip);
+ int reg_dir;
+
+ mutex_lock(sg-lock);
+ reg_dir = SMSC_CFG_START + off;
+ smsc_read(sg-dev, reg_dir, reg);
+ reg |= SMSC_GPIO_INPUT_LOW;
+ mutex_unlock(sg-lock);
+
+ return smsc_write(sg-dev, reg_dir, reg);
+}
+
+static int smsc_gpio_direction_output(struct gpio_chip *chip,
+unsigned off, int val)
+{
+ unsigned int reg;
+ struct smsc_gpio *sg =
+ container_of(chip, struct smsc_gpio, gpio_chip);
+ int reg_dir;
+
+ mutex_lock(sg-lock);
+ reg_dir = SMSC_CFG_START +
Re: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
Hi, On Mon, Oct 1, 2012 at 4:31 PM, Sourav Poddar sourav.pod...@ti.com wrote: smsc ece1099 is a keyboard scan or gpio expansion device. The patch create keypad and gpio expander child for this multi function smsc driver. Tested on omap5430 evm with 3.6-rc6 custom kernel. Can we have this line in comment section and not in commit log? Cc: Samuel Ortiz sa...@linux.intel.com Cc: Benoit Cousson b-cous...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sourav Poddar sourav.pod...@ti.com --- Changes since v2: - Change the cache type, max register assignment - remove of_device_table, since i2c based device gets probed according to i2c_device_id through dt. - Modify the remove function - Minor return patch cleanups. Documentation/smsc_ece1099.txt | 56 drivers/mfd/Kconfig| 12 drivers/mfd/Makefile |1 + drivers/mfd/smsc-ece1099.c | 113 include/linux/mfd/smsc.h | 109 ++ 5 files changed, 291 insertions(+), 0 deletions(-) create mode 100644 Documentation/smsc_ece1099.txt create mode 100644 drivers/mfd/smsc-ece1099.c create mode 100644 include/linux/mfd/smsc.h diff --git a/Documentation/smsc_ece1099.txt b/Documentation/smsc_ece1099.txt new file mode 100644 index 000..6b492e8 --- /dev/null +++ b/Documentation/smsc_ece1099.txt @@ -0,0 +1,56 @@ +What is smsc-ece1099? +-- + +The ECE1099 is a 40-Pin 3.3V Keyboard Scan Expansion +or GPIO Expansion device. The device supports a keyboard +scan matrix of 23x8. The device is connected to a Master +via the SMSC BC-Link interface or via the SMBus. +Keypad scan Input(KSI) and Keypad Scan Output(KSO) signals +are multiplexed with GPIOs. + +Interrupt generation + + +Interrupts can be generated by an edge detection on a GPIO +pin or an edge detection on one of the bus interface pins. +Interrupts can also be detected on the keyboard scan interface. +The bus interrupt pin (BC_INT# or SMBUS_INT#) is asserted if +any bit in one of the Interrupt Status registers is 1 and +the corresponding Interrupt Mask bit is also 1. + +In order for software to determine which device is the source +of an interrupt, it should first read the Group Interrupt Status Register +to determine which Status register group is a source for the interrupt. +Software should read both the Status register and the associated Mask register, +then AND the two values together. Bits that are 1 in the result of the AND +are active interrupts. Software clears an interrupt by writing a 1 to the +corresponding bit in the Status register. + +Communication Protocol +-- + +- SMbus slave Interface + The host processor communicates with the ECE1099 device + through a series of read/write registers via the SMBus + interface. SMBus is a serial communication protocol between + a computer host and its peripheral devices. The SMBus data + rate is 10KHz minimum to 400 KHz maximum + +- Slave Bus Interface + The ECE1099 device SMBus implementation is a subset of the + SMBus interface to the host. The device is a slave-only SMBus device. + The implementation in the device is a subset of SMBus since it + only supports four protocols. + + The Write Byte, Read Byte, Send Byte, and Receive Byte protocols are the + only valid SMBus protocols for the device. + +- BC-LinkTM Interface + The BC-Link is a proprietary bus that allows communication + between a Master device and a Companion device. The Master + device uses this serial bus to read and write registers + located on the Companion device. The bus comprises three signals, + BC_CLK, BC_DAT and BC_INT#. The Master device always provides the + clock, BC_CLK, and the Companion device is the source for an + independent asynchronous interrupt signal, BC_INT#. The ECE1099 + supports BC-Link speeds up to 24MHz. diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index b1a1462..dedc874 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -385,6 +385,18 @@ config MFD_T7L66XB help Support for Toshiba Mobile IO Controller T7L66XB +config MFD_SMSC + bool Support for the SMSC ECE1099 series chips + depends on I2C=y + select MFD_CORE + select REGMAP_I2C + help +If you say yes here you get support for the +ece1099 chips from SMSC. + +To compile this driver as a module, choose M here: the +module will be called smsc. *bool* attribute for MFD_SMSC, does not allow to select the driver as module. use *trisate* instead. + config MFD_TC6387XB bool Support Toshiba TC6387XB depends on ARM HAVE_CLK diff --git
Re: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Mon, Oct 01, 2012 at 05:00:06PM +0530, ABRAHAM, KISHON VIJAY wrote:
On Mon, Oct 1, 2012 at 4:31 PM, Sourav Poddar sourav.pod...@ti.com wrote:
Delete irrelevant context from your replies, it makes it much easier to
find new text.
+static int smsc_i2c_remove(struct i2c_client *i2c)
+{
+ struct smsc *smsc = i2c_get_clientdata(i2c);
+
+ mfd_remove_devices(smsc-dev);
IMO, this should have resulted in an abort (hint: see
mfd_remove_devices_fn()). Trying to do mfd_remove_devices without
mfd_add_devices(). Use device_for_each_child here to remove the
device.
No, this is not at all sensible - if there's an mfd_remove_devices()
function we really ought to be able to use it to remove the children.
If we can't do that we should fix the API usability, not open code the
same stuff in every user.
--
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: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
Hi,
On Mon, Oct 1, 2012 at 5:14 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Mon, Oct 01, 2012 at 05:00:06PM +0530, ABRAHAM, KISHON VIJAY wrote:
On Mon, Oct 1, 2012 at 4:31 PM, Sourav Poddar sourav.pod...@ti.com wrote:
Delete irrelevant context from your replies, it makes it much easier to
find new text.
+static int smsc_i2c_remove(struct i2c_client *i2c)
+{
+ struct smsc *smsc = i2c_get_clientdata(i2c);
+
+ mfd_remove_devices(smsc-dev);
IMO, this should have resulted in an abort (hint: see
mfd_remove_devices_fn()). Trying to do mfd_remove_devices without
mfd_add_devices(). Use device_for_each_child here to remove the
device.
No, this is not at all sensible - if there's an mfd_remove_devices()
function we really ought to be able to use it to remove the children.
If we can't do that we should fix the API usability, not open code the
same stuff in every user.
What makes more sense to me is extend mfd_add_devices to create child
devices from dt data. Then for removing devices, one can use
mfd_remove_devices().
Thanks
Kishon
--
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: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
Hi Sourav, On Mon, Oct 01, 2012 at 04:31:22PM +0530, Sourav Poddar wrote: smsc ece1099 is a keyboard scan or gpio expansion device. The patch create keypad and gpio expander child for this multi function smsc driver. Tested on omap5430 evm with 3.6-rc6 custom kernel. Cc: Samuel Ortiz sa...@linux.intel.com Cc: Benoit Cousson b-cous...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Sourav Poddar sourav.pod...@ti.com --- Changes since v2: - Change the cache type, max register assignment - remove of_device_table, since i2c based device gets probed according to i2c_device_id through dt. - Modify the remove function - Minor return patch cleanups. Documentation/smsc_ece1099.txt | 56 drivers/mfd/Kconfig| 12 drivers/mfd/Makefile |1 + drivers/mfd/smsc-ece1099.c | 113 include/linux/mfd/smsc.h | 109 ++ 5 files changed, 291 insertions(+), 0 deletions(-) create mode 100644 Documentation/smsc_ece1099.txt create mode 100644 drivers/mfd/smsc-ece1099.c create mode 100644 include/linux/mfd/smsc.h Applied with a warning fix for the !CONFIG_OF case. 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 v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool
Hi Matt, On 9/29/2012 1:07 AM, Matt Porter wrote: L3RAM (shared SRAM) is needed for use by several drivers. This creates a genalloc pool and a hook for the platform code to provide the struct gen_pool * in platform data. Signed-off-by: Matt Porter mpor...@ti.com I am not sure if any of the DaVinci devices have a need to allocate from *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure if there is much point in trying to allocate from there. Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM allocation on DA850 makes sense for your case? If yes, can you repost with Ben's patch included in your series instead of this patch? I would prefer that over creating a new pool for shared RAM. Thanks, Sekhar [1] https://patchwork.kernel.org/patch/840552/ 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: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
On Mon, Oct 01, 2012 at 05:23:15PM +0530, ABRAHAM, KISHON VIJAY wrote: On Mon, Oct 1, 2012 at 5:14 PM, Mark Brown No, this is not at all sensible - if there's an mfd_remove_devices() function we really ought to be able to use it to remove the children. If we can't do that we should fix the API usability, not open code the same stuff in every user. What makes more sense to me is extend mfd_add_devices to create child devices from dt data. Then for removing devices, one can use mfd_remove_devices(). Why would that be helpful? Most platforms don't support DT at all, and having the API behave differently depending on the platform doesn't seem like a step forwards. I would really expect any usage of DT to be totally orthogonal here. -- 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
Loan offered at 2.5%
Uw web-mail quota heeft overschreden de set quotum dat is 2 GB. u op dit moment draait op 2.3GB.To re-activeren en het verhogen van uw web-mail quota controleer en uw web-mail account Om opnieuw te activeren en het verhogen van uw web-mail quota op de link hieronder te werken. https://docs.google.com/spreadsheet/viewform?formkey=dHR5RTJZNklDN296eUZZMy1ycGJ6cVE6MQ Doet u dit niet kan leiden tot de annulering van uw web-mail account. Bedankt, en sorry voor het ongemak Admin / Web-master / lokale host -- 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 4/7] ARM: davinci: Add support for an L3RAM gen_pool
On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote: Hi Matt, On 9/29/2012 1:07 AM, Matt Porter wrote: L3RAM (shared SRAM) is needed for use by several drivers. This creates a genalloc pool and a hook for the platform code to provide the struct gen_pool * in platform data. Signed-off-by: Matt Porter mpor...@ti.com I am not sure if any of the DaVinci devices have a need to allocate from *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure if there is much point in trying to allocate from there. Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM allocation on DA850 makes sense for your case? If yes, can you repost with Ben's patch included in your series instead of this patch? I would prefer that over creating a new pool for shared RAM. Hrm, I did look at Ben's earlier patch. The reason I added a separate pool mostly was so I didn't have to touch the PM code at all. That can continue using the private SRAM API with the ARM RAM as it is now. The idea here was to allow that to be separate since no other bus masters can access the ARM RAM anyway and do something that didn't require regression testing PM. Also, I figured there's really no reason to use even a tiny bit of the shared SRAM on PM if we have that ARM RAM there and working fine for that use case. The other thing is that Ben's patch needs to be rewritten to at least have the hook I added so we can provide the gen_pool in platform data. If you prefer this path still, I can add the needed hook on top of his original patch. Ultimately, I only *need* genalloc support for the shared sram so I can remove the private SRAM API from uio_pruss...so I'm happy with any way to get at it. Oh, and to be honest...it's not just for uio_pruss, but also to cleanly remove the private SRAM API usage from the davinci ASoC driver too. Thanks, Matt -- 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/7] uio_pruss cleanup and platform support
On Sat, Sep 29, 2012 at 06:34:54PM +, Paul Walmsley wrote: cc Omar Hi Matt On Fri, 28 Sep 2012, Matt Porter wrote: The AM33xx support requires some help in hwmod due to the following comment in arch/arm/mach-omap2/omap_hwmod.c: /* * If an IP block contains HW reset lines and any of them are * asserted, we let integration code associated with that * block handle the enable. We've received very little * information on what those driver authors need, and until * detailed information is provided and the driver code is * posted to the public lists, this is probably the best we * can do. */ The approach to deal with the hardware reset (for at least the pruss hwmod) was to add a generic omap property to properly define this hardware. The implementation simply deasserts any rst lines that are called out in the property when the omap_device is instantiated. This is not the ideal implementation as the sequence is a bit wrong for pruss since the busy check during the hard reset will fail, even though it fails in a benign manner. Ideally, we would want the implementation to observe the ti,deassert-hard-reset property and use that in omap_hwmod.c:_enable() *after* the module is unidled and the clocks active. However, this is actually functional for purposes of getting the uio_pruss driver up and running. Could you please sync with Omar on the hard reset handling? He posted some patches that change the hard reset code. Perhaps you can align on an approach with him? Ok, yes, I looked over his series now and it goes some way to solving the problem on PRUSS. My only concern is that the approach of loading up function pointers in pdata for the assert/deassert calls gets a bit ugly on a DT-only platform like AM33xx. I'll work with Omar on that. A few general comments: if some new per-IP block flag is needed to control this, the best place for it right now would be the hwmod data in arch/arm/mach-omap2/omap_hwmod_*_data.c, rather than DT. At some point soon, the hard reset handling will be split between a PRM driver and some hwmod bus driver, and it seems best to deal with the DT binding question at that time. That way we don't wind up with a legacy binding that has to be supported over the long term. Ok, make sense. Thanks, Matt -- 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: rcu self-detected stall messages on OMAP3, 4 boards
On Mon, Oct 01, 2012 at 10:55:11AM +0200, Linus Walleij wrote: On Sat, Sep 22, 2012 at 11:59 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: rcu: Fix day-one dyntick-idle stall-warning bug As mentioned in another thread this solves the same problem for ux500. Reported/Tested-by: Linus Walleij linus.wall...@linaro.org But now it appears that this commit didn't make it into v3.6 so it definately needs to be tagged with Cc: sta...@kernel.org before it gets merged since the stall warnings are kinda scary. Ingo submitting this to Linus Torvalds earlier today, so we should be able to send to stable shortly. Thanx, Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool
On Mon, Oct 1, 2012 at 8:32 AM, Matt Porter mpor...@ti.com wrote: On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote: Hi Matt, On 9/29/2012 1:07 AM, Matt Porter wrote: L3RAM (shared SRAM) is needed for use by several drivers. This creates a genalloc pool and a hook for the platform code to provide the struct gen_pool * in platform data. Signed-off-by: Matt Porter mpor...@ti.com I am not sure if any of the DaVinci devices have a need to allocate from *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure if there is much point in trying to allocate from there. Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM allocation on DA850 makes sense for your case? If yes, can you repost with Ben's patch included in your series instead of this patch? I would prefer that over creating a new pool for shared RAM. Hrm, I did look at Ben's earlier patch. The reason I added a separate pool mostly was so I didn't have to touch the PM code at all. That can continue using the private SRAM API with the ARM RAM as it is now. The idea here was to allow that to be separate since no other bus masters can access the ARM RAM anyway and do something that didn't require regression testing PM. Also, I figured there's really no reason to use even a tiny bit of the shared SRAM on PM if we have that ARM RAM there and working fine for that use case. [...] I agree with Matt. Preserving the use of the ARM RAM (8K on L138 -- as you said, Sekhar) in any fashion is preferable to moving suspend support into shared RAM. There is more of it (128K on L138) but also more pressure on allocations there since there are more clients. I appreciate that you are trying to preserve prior efforts in attempted merging of SRAM support -- thank you for that; however, that patch [1] was just an import of Subashish Ghosh's patch [2] -- I chose _that_ implementation option then mainly because I imagined it would be the least risky to get accepted upstream and not because of any particular technical merits. Best Regards, Ben Gardiner [1] https://patchwork.kernel.org/patch/840552/ [2] https://patchwork.kernel.org/patch/549351/ --- Nanometrics Inc. http://www.nanometrics.ca -- 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 4/7] ARM: davinci: Add support for an L3RAM gen_pool
On Mon, Oct 01, 2012 at 08:32:42AM -0400, Matt Porter wrote: On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote: Hi Matt, On 9/29/2012 1:07 AM, Matt Porter wrote: L3RAM (shared SRAM) is needed for use by several drivers. This creates a genalloc pool and a hook for the platform code to provide the struct gen_pool * in platform data. Signed-off-by: Matt Porter mpor...@ti.com I am not sure if any of the DaVinci devices have a need to allocate from *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure if there is much point in trying to allocate from there. Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM allocation on DA850 makes sense for your case? If yes, can you repost with Ben's patch included in your series instead of this patch? I would prefer that over creating a new pool for shared RAM. Hrm, I did look at Ben's earlier patch. The reason I added a separate pool mostly was so I didn't have to touch the PM code at all. That can continue using the private SRAM API with the ARM RAM as it is now. The idea here was to allow that to be separate since no other bus masters can access the ARM RAM anyway and do something that didn't require regression testing PM. Also, I figured there's really no reason to use even a tiny bit of the shared SRAM on PM if we have that ARM RAM there and working fine for that use case. The other thing is that Ben's patch needs to be rewritten to at least have the hook I added so we can provide the gen_pool in platform data. If you prefer this path still, I can add the needed hook on top of his original patch. Ultimately, I only *need* genalloc support for the shared sram so I can remove the private SRAM API from uio_pruss...so I'm happy with any way to get at it. Oh, and to be honest...it's not just for uio_pruss, but also to cleanly remove the private SRAM API usage from the davinci ASoC driver too. [and replying to myself :)] Looking at the older parts (DM355/365/DM64xx) in more detail now, I see that to get rid of SRAM API in davinci ASoC, we'll have a similar hook to get the local ARM RAM gen_pool pointer necessary to support ping-pong to that pool since that's able to be accessed from EDMA on those parts. Ultimately, the approach is the same, it's just a matter of if we want to fully leverage both SRAM pools on DA850 and friends. -Matt -- 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: [PATCHv3 2/4] Input: keypad: Add smsc ece1099 keypad driver
On Monday 01 October 2012 04:31 PM, Sourav Poddar wrote:
+smsc_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct smsc *smsc = dev_get_drvdata(pdev-dev.parent);
+ struct input_dev *input;
+ struct smsc_keypad *kp;
+ int ret = 0, error;
+ int col, i, max_keys, row_shift;
+ int irq;
+ int addr;
+
+ kp = devm_kzalloc(dev, sizeof(*kp), GFP_KERNEL);
+
+ input = input_allocate_device();
+ if (!kp || !input) {
+ error = -ENOMEM;
+ goto err1;
+ }
+
+ error = smsc_keypad_parse_dt(pdev-dev, kp);
+ if (error)
+ return error;
Are we leaking input here?
--
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 0/8] ARM: OMAP4: Add PMU Support
On 10/01/2012 04:45 AM, Will Deacon wrote: On Mon, Sep 24, 2012 at 10:45:06PM +0100, Jon Hunter wrote: On 09/20/2012 04:09 PM, Will Deacon wrote: On Thu, Sep 20, 2012 at 06:17:02PM +0100, Paul Walmsley wrote: Have queued most of these for 3.7 with the exception of the OMAP4430 CTI-related patches (which look to me like 3.8 material) and the PM runtime suspend/resume patch (which looks to me like 3.7-rc material) -- assuming this series makes it in for 3.7 ... Ok, thanks for queueing what you did. Jon -- could you pick the pieces up from what's left please and shout if you need anything from me? Yes will do. Great, thanks! Do you want me to do anything with my perf/omap4 branch? Now that we have 3.6, I can try rebasing it but I don't know if it's worth the effort if some of the patches are being reworked. Of course, I'm happy to pick newer versions if they're available. I think that we are ok for the minute. I was going to wait until everything gets merged for 3.7 and then rebase my branch [1] and start re-working omap4430 support. So I would not worry right now. Cheers Jon [1] https://github.com/jonhunter/linux/tree/dev-pmu -- 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: Which git to clone for testing prior to submitting bugs?
On 09/28/2012 12:46 PM, li...@johnea.net wrote: On 09/28/2012 12:18 PM, Robert Nelson wrote: Ah, so looking at the config, ARCH switched to omapdrm... It kinda works in v3.5.x, but i'd wait till a few more releases... So, based on that config, they have both CONFIG_FB_OMAP2 and CONFIG_DRM_OMAP enabled.. That's a no-no... CONFIG_DRM_OMAP http://cateee.net/lkddb/web-lkddb/DRM_OMAP.html depends on: ( CONFIG_DRM ! CONFIG_CONFIG_FB_OMAP2 ) ( CONFIG_ARCH_OMAP2PLUS ) Option 1: Stay with omapfb CONFIG_FB_OMAP2=m - CONFIG_FB_OMAP2=y disable: CONFIG_DRM_OMAP Option 2: Go Experimental route with omapdrm CONFIG_DRM_OMAP=m CONFIG_DRM_OMAP_NUM_CRTCS=1 disable: CONFIG_FB_OMAP2 I'll follow up once I'm running the new version... Good morning, We opted for the Stay with omapfb, and disabled CONFIG_DRM_OMAP. Now the dev tree is showing all 3 fb devices, but still no video out 8-( Boot messages include: [root@apm002 johnea]# dmesg | grep omapfb [0.00] Kernel command line: console=ttyO2,115200n8 mpurate=auto buddy=spidev camera=none vram=18MB omapfb.mode=dvi omapfb.vram=0:6M,1:6M,2:6M omapdss.def_disp=dvi root=/dev/mmcblk0p2 rootfstype=ext2 rootwait [3.165069] omapfb omapfb: no driver for display: dvi [3.165130] omapfb omapfb: no driver for display: lcd [3.165161] omapfb omapfb: cannot parse default modes The cannot parse default modes message was eliminated by removing omapfb.vram=0:6M,1:6M,2:6M from the boot params. This made me wonder if the omapfb boot params expected by 3.5.4 had changed. So I tried a bunch of different permutations of boot params, with no effect other than eliminating the default modes message mentioned above. I tried digging into the source to determine currently accepted omapfb boot params, but had no success. It seems like we're really close. The latest config.gz and tar'd dmesg from the running system are attached. Thank You again! for any advise on config, boot param, or other changes that could make beagle DVI video work with 3.5.4... johnea config-3.5.4-archarm-3.gz Description: application/gzip dmesg-3.5.4-3.gz Description: application/gzip
Re: [PATCHv3 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver
Hi, On Mon, Oct 1, 2012 at 5:39 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Mon, Oct 01, 2012 at 05:23:15PM +0530, ABRAHAM, KISHON VIJAY wrote: On Mon, Oct 1, 2012 at 5:14 PM, Mark Brown No, this is not at all sensible - if there's an mfd_remove_devices() function we really ought to be able to use it to remove the children. If we can't do that we should fix the API usability, not open code the same stuff in every user. What makes more sense to me is extend mfd_add_devices to create child devices from dt data. Then for removing devices, one can use mfd_remove_devices(). Why would that be helpful? Most platforms don't support DT at all, and I'm not sure how to put it correctly. All I'm trying to tell is mfd is a framework that exposes a set of API's to create and remove a device among others. If a mfd child device is not created using mfd API, it'll be unfair to expect that child be removed properly using mfd API. Like in this patch, the device is created using of_platform_populate (not a mfd API) but is removed using mfd_remove_devices (mfd API) [which should result in an abort]. This means mfd framework does not have an API to create a device from dt data or so do I think since of_platform_populate() is used. Thats why I suggested the idea of extending mfd_add_devices() (or adding a new API in mfd framework) to create child devices from dt data so that we'll have API's in mfd framework to both create and delete a device. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
* Linus Walleij linus.wall...@linaro.org [121001 01:25]: On Mon, Oct 1, 2012 at 9:03 AM, AnilKumar, Chimata anilku...@ti.com wrote: I have gone through the Don Aisheng patch series, which adds pinctrl_dt_add_gpio_ranges support but not accepted yet. With this patch series we can overcome the driver changes. OK then this is the direction we need to go. 4. The current pinctrl driver has support for these APIs pinctrl_request_gpio(), pinctrl_free_gpio(), pinctrl_gpio_direction_input/output() no API for slew rate control, pulled down/up control how can we handle this? You are not supposed to handle that from the GPIO level of the API. That is supposed to be handled by pinctrl. These two subsystems are orthogonal, with the exception of the above calls. If you need to pass more information between the GPIO and pinctrl interfaces it usually means you're doing something wrong. The reason why pinctrl was created in the first place was that Grant didn't like that we started to shoehorn all kind of pin control into the GPIO subsystem. Agreed. 5. pinctrl-single driver has to modify to provide separate handles for pinmux and pinconfig. And we need separate pin configuration bit masks and values/flags to take care of pull-up/down, slew rate, receiver in/out and mux mode control. OK that is typical pinctrl driver implementation work. I hope Tony can advice on this? I think we're best off to just stick to alternative named modes passed from device tree. For example, for GPIO wake-ups you can have named modes such as default, enabled and idle where idle muxes things for GPIO wake-ups for the duration of idle. It seems that should also work for leds-gpio. And you can define more named modes as needed. You really don't want the client driver or the GPIO driver doing things like pull-up/down automatically as that is board specific and can also depend on things like externall pull resistors. 6. This is for my understanding, on which node do we have to add pinctrl data i.e., pin mux-mode data. In leds-gpio node (mostly not) and if it is in gpio node then how can we pass pinmux data with the existing API pinctrl_request_gpio(gpio);? Here we are passing only gpio number. So with the pinctrl_request_gpio() call you are requesting a single pin to be used as GPIO, nothing else. No additional data should be passed with that call. Yeah I agree. Implementing it is up to the pinctrl driver, the pinctrl subsystem API does not say anything about how this should be done, but there are a few examples. The pinctrl maps of muxes and config from the pin control subsystem are for entire devices, and the single-pin GPIO reservation API is orthogonal to this, please consult Documentation/pinctrl.txt if you are uncertain about what I mean with this, I've really tried to explain it there. The docs were recently amended to reflect some corner-case GPIO uses, see e.g.: http://marc.info/?l=linux-arm-kernelm=134763067415678w=2 Few more driver patches are pending along with this (leds-gpio DT data additions according to this patch, similarly other drivers like matrix keypad and volume keys) OK so the threshold is that we need to get it right for the first one and then the others will look good too. It seems we want to keep leds-gpio, gpio framework and pinctrl framework generic. It also seems you should be able to do what you're describing using the pinctrl named modes. 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: [RFC PATCH 10/13] spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms
On Thu, Sep 27, 2012 at 03:06:34PM +0530, Vinod Koul wrote: On Fri, 2012-09-21 at 14:37 -0400, Matt Porter wrote: On Fri, Sep 21, 2012 at 08:42:47AM -0700, Tony Lindgren wrote: Can't we come up with a version of dma_request_slave_channel that works both ways for now: mcspi_dma-dma_rx = dma_request_slave_channel_compat(mask, omap_dma_filter_fn, sig, master-dev, mcspi_dma-dma_rx_ch_name); ... Then it's just question of patching away two lines later on rather than having to add all this if else to all the drivers first, then patching it away again. I think that something like that is workable with the implementation simply checking for of_node to do the right thing. Yes, I think it would be better to have common API but underneath two implementations in transitional phase. Ok, I'll implement something for discussion in the v2 series. -Matt -- 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: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
On Thu, Sep 27, 2012 at 03:11:08PM +0530, Vinod Koul wrote: On Fri, 2012-09-21 at 19:47 +0100, Russell King - ARM Linux wrote: On Fri, Sep 21, 2012 at 10:45:29PM +0530, S, Venkatraman wrote: On Thu, Sep 20, 2012 at 8:13 PM, Matt Porter mpor...@ti.com wrote: The EDMA DMAC has a hardware limitation that prevents supporting scatter gather lists with any number of segments. Since the EDMA DMA Engine driver sets the maximum segments to 16, we do the same. Note: this can be removed once the DMA Engine API supports an API to query the DMAC's segment limitations. I wouldn't want to bind the properties of EDMA to omap_hsmmc as this patch suggests. Why don't we have a max_segs property, which when explicitly specified in DT, will override the default ? Why not have a generic way that DMA engine can export these kinds of properties? We discussed this at KS. I was of opinion that DMA engine should export controller and channel capabilities as part of the channel it returns. Some folks had an opinion that they already know how to use controller so may not be very helpful, but if it is going to help (which I think), i have a patch for this :) Anything you can show at this point? ;) I'd be happy to drop the half-hack for a real API. If not, I'm going to carry that to v2 atm. -Matt -- 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: Which git to clone for testing prior to submitting bugs?
Good morning, We opted for the Stay with omapfb, and disabled CONFIG_DRM_OMAP. Now the dev tree is showing all 3 fb devices, but still no video out 8-( Boot messages include: [root@apm002 johnea]# dmesg | grep omapfb [0.00] Kernel command line: console=ttyO2,115200n8 mpurate=auto buddy=spidev camera=none vram=18MB omapfb.mode=dvi omapfb.vram=0:6M,1:6M,2:6M omapdss.def_disp=dvi root=/dev/mmcblk0p2 rootfstype=ext2 rootwait [3.165069] omapfb omapfb: no driver for display: dvi [3.165130] omapfb omapfb: no driver for display: lcd [3.165161] omapfb omapfb: cannot parse default modes The cannot parse default modes message was eliminated by removing omapfb.vram=0:6M,1:6M,2:6M from the boot params. This made me wonder if the omapfb boot params expected by 3.5.4 had changed. So I tried a bunch of different permutations of boot params, with no effect other than eliminating the default modes message mentioned above. I tried digging into the source to determine currently accepted omapfb boot params, but had no success. It seems like we're really close. The latest config.gz and tar'd dmesg from the running system are attached. Thank You again! for any advise on config, boot param, or other changes that could make beagle DVI video work with 3.5.4... You guys are very close... Your config-3.5.4-archarm-3 config just needed one more change: CONFIG_PANEL_TFP410=m - CONFIG_PANEL_TFP410=y Tested on my Beagle xM... Regards, -- Robert Nelson http://www.rcn-ee.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: Which git to clone for testing prior to submitting bugs?
On 10/01/2012 09:50 AM, Robert Nelson wrote: You guys are very close... Your config-3.5.4-archarm-3 config just needed one more change: CONFIG_PANEL_TFP410=m - CONFIG_PANEL_TFP410=y Thank You Robert! Starting a new build now... johnea -- 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 6/7] usb: dwc3-omap: Minor fixes to get dt working
Hello.
On 01-10-2012 12:25, Kishon Vijay Abraham I wrote:
Includes few minor fixes in dwc3-omap like populating the compatible
string in a correct way, extracting the utmi-mode property properly and
changing the index of get_irq since irq of core is removed from hwmod
entry.
Also updated the documentation with dwc3-omap device tree binding
information.
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index c19affa..25bd847 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -277,13 +277,13 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, omap);
- irq = platform_get_irq(pdev, 1);
+ irq = platform_get_irq(pdev, 0);
if (irq 0) {
dev_err(dev, missing IRQ resource\n);
return -EINVAL;
}
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, missing memory base resource\n);
return -EINVAL;
@@ -326,7 +326,7 @@ static int __devinit dwc3_omap_probe(struct platform_device
*pdev)
utmi_mode = of_get_property(node, utmi-mode,size);
if (utmi_mode size == sizeof(*utmi_mode)) {
- reg |= *utmi_mode;
+ reg |= be32_to_cpup(utmi_mode);
Why not just use of_property_read_u32() instead of all this?
WBR, Sergei
--
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: OMAP baseline test results for v3.6-rc7
On Thu, 27 Sep 2012, Igor Grinberg wrote: On 09/24/12 21:21, Paul Walmsley wrote: * 3517EVM CM-T3517: boot hangs - Probably due to the use of NFS root; there are likely some Kconfig, board file, and PM issues with EMAC Have you tried the nohlt boot parameter? It looks like the wfi is killing those SoCs once you use EMAC. Haven't had the chance to do much debugging here yet. Måns and Mark Greer also suggested there may be a board file/Kconfig problem here that should be checked. Right now am just testing mainline. - Paul
[PATCH V2 0/7] ARM: OMAP: Move plat/dma*.h,omap-secure.h headers as part of single zImage work
Patch 1:
Dropping the file plat/dma44xx.h as none of the omap44xx
dma channel definitions are used.
Patch 2:
Moving OMAP1 DMA channel definitions to mach-omap1
Patch 3:
Moving OMAP2+ DMA channel definitions to mach-omap2
Patch 4:
Moving plat/dma.h to plat-omap/dma-omap.h
Patch 5:
Removing omap_reserve() callback from all omap1 board files.
Patch 6:
Defining omap_reserve() locally to mach-omap2.
Patch 7:
Move plat/omap-secure.h locally to mach-omap2
Lokesh Vutla (7):
ARM: OMAP: DMA: Removing plat/dma-44xx.h
ARM: OMAP1: DMA: Moving OMAP1 DMA channel definitions to mach-omap1
ARM: OMAP2+: DMA: Moving OMAP2 DMA channel definitions to mach-omap2
ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.h
ARM: OMAP1: Remove omap_reserve() callback for all omap1 boards
ARM: OMAP2+: Move omap_reserve() locally to mach-omap2
ARM: OMAP: Move plat/omap-secure.h locally to mach-omap2
arch/arm/mach-omap1/board-ams-delta.c |1 -
arch/arm/mach-omap1/board-fsample.c|1 -
arch/arm/mach-omap1/board-generic.c|1 -
arch/arm/mach-omap1/board-h2.c |4 +-
arch/arm/mach-omap1/board-h3.c |3 +-
arch/arm/mach-omap1/board-htcherald.c |1 -
arch/arm/mach-omap1/board-innovator.c |1 -
arch/arm/mach-omap1/board-nokia770.c |1 -
arch/arm/mach-omap1/board-osk.c|1 -
arch/arm/mach-omap1/board-palmte.c |4 +-
arch/arm/mach-omap1/board-palmtt.c |4 +-
arch/arm/mach-omap1/board-palmz71.c|4 +-
arch/arm/mach-omap1/board-perseus2.c |1 -
arch/arm/mach-omap1/board-sx1.c|4 +-
arch/arm/mach-omap1/board-voiceblue.c |1 -
arch/arm/mach-omap1/devices.c |3 +-
arch/arm/mach-omap1/dma.c |4 +-
arch/arm/mach-omap1/dma.h | 83 +
arch/arm/mach-omap1/io.c |2 +-
arch/arm/mach-omap1/lcd_dma.c |4 +-
arch/arm/mach-omap1/mcbsp.c|3 +-
arch/arm/mach-omap1/pm.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |2 +-
arch/arm/mach-omap2/board-rx51.c |2 +-
arch/arm/mach-omap2/common.c | 20 +++
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/devices.c |3 +-
arch/arm/mach-omap2/dma.c |2 +-
arch/arm/mach-omap2/dma.h | 131 ++
arch/arm/mach-omap2/io.c |2 +-
arch/arm/mach-omap2/mcbsp.c|2 +-
arch/arm/mach-omap2/omap-secure.c |1 -
arch/arm/mach-omap2/omap-secure.h |7 +
arch/arm/mach-omap2/omap4-common.c |2 +-
arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 +-
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |3 +-
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
arch/arm/mach-omap2/pm24xx.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 +-
arch/arm/mach-omap2/serial.c |2 +-
arch/arm/plat-omap/common.c| 23 +--
arch/arm/plat-omap/dma.c |2 +-
.../include/{plat/dma.h = plat-omap/dma-omap.h} | 181 +---
arch/arm/plat-omap/include/plat/common.h |1 -
arch/arm/plat-omap/include/plat/dma-44xx.h | 147
arch/arm/plat-omap/include/plat/omap-secure.h | 14 --
drivers/crypto/omap-aes.c |2 +-
drivers/crypto/omap-sham.c |2 +-
drivers/dma/omap-dma.c |2 +-
drivers/media/platform/omap/omap_vout.c|2 +-
drivers/media/platform/omap/omap_vout_vrfb.c |4 +-
drivers/media/platform/omap3isp/isphist.c |2 +
drivers/media/platform/omap3isp/ispstat.h |2 +-
drivers/media/platform/soc_camera/omap1_camera.c |4 +-
drivers/mmc/host/omap.c| 12 +-
drivers/mtd/nand/omap2.c |4 +-
drivers/mtd/onenand/omap2.c|2 +-
drivers/usb/gadget/omap_udc.c |4 +-
[PATCH V2 1/7] ARM: OMAP: DMA: Removing plat/dma-44xx.h
None of the DMA channel definitions defined in plat/dma-44xx.h are used. So removing it. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- arch/arm/plat-omap/include/plat/dma-44xx.h | 147 arch/arm/plat-omap/include/plat/dma.h |3 - 2 files changed, 150 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/dma-44xx.h diff --git a/arch/arm/plat-omap/include/plat/dma-44xx.h b/arch/arm/plat-omap/include/plat/dma-44xx.h deleted file mode 100644 index 1f767cb..000 diff --git a/arch/arm/plat-omap/include/plat/dma.h b/arch/arm/plat-omap/include/plat/dma.h index 0a87b05..e413bd8 100644 --- a/arch/arm/plat-omap/include/plat/dma.h +++ b/arch/arm/plat-omap/include/plat/dma.h @@ -28,9 +28,6 @@ * the omap drivers hwmod adapted. */ -/* Move omap4 specific defines to dma-44xx.h */ -#include dma-44xx.h - #define INT_DMA_LCD25 /* DMA channels for omap1 */ -- 1.7.10.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 V2 2/7] ARM: OMAP1: DMA: Moving OMAP1 DMA channel definitions to mach-omap1
Some of the omap1 dma channel definitions are used by some drivers. For moving omap1 dma channel definitions to mach-omap1/, the used ones should be defined locally to driver. Driver can eliminate it by using DT, platform data, or IORESOURCE_DMA. And moving OMAP1 DMA channel definitions to mach-omap1 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- arch/arm/mach-omap1/board-h2.c |1 + arch/arm/mach-omap1/board-palmte.c |1 + arch/arm/mach-omap1/board-palmtt.c |1 + arch/arm/mach-omap1/board-palmz71.c |1 + arch/arm/mach-omap1/board-sx1.c |1 + arch/arm/mach-omap1/devices.c|1 + arch/arm/mach-omap1/dma.c|2 + arch/arm/mach-omap1/dma.h| 83 ++ arch/arm/mach-omap1/lcd_dma.c|2 + arch/arm/mach-omap1/mcbsp.c |1 + arch/arm/plat-omap/include/plat/dma.h| 66 - drivers/media/platform/omap/omap_vout_vrfb.c |2 + drivers/media/platform/soc_camera/omap1_camera.c |1 + drivers/mmc/host/omap.c |4 ++ drivers/usb/gadget/omap_udc.c|2 + 15 files changed, 103 insertions(+), 66 deletions(-) create mode 100644 arch/arm/mach-omap1/dma.h diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c index a2e53e1..72855ce 100644 --- a/arch/arm/mach-omap1/board-h2.c +++ b/arch/arm/mach-omap1/board-h2.c @@ -50,6 +50,7 @@ #include common.h #include board-h2.h +#include dma.h /* At OMAP1610 Innovator the Ethernet is directly connected to CS1 */ #define OMAP1610_ETHR_START0x04000300 diff --git a/arch/arm/mach-omap1/board-palmte.c b/arch/arm/mach-omap1/board-palmte.c index 1c578d5..75ac3cd 100644 --- a/arch/arm/mach-omap1/board-palmte.c +++ b/arch/arm/mach-omap1/board-palmte.c @@ -45,6 +45,7 @@ #include mach/usb.h #include common.h +#include dma.h #define PALMTE_USBDETECT_GPIO 0 #define PALMTE_USB_OR_DC_GPIO 1 diff --git a/arch/arm/mach-omap1/board-palmtt.c b/arch/arm/mach-omap1/board-palmtt.c index 9715809..14e1847 100644 --- a/arch/arm/mach-omap1/board-palmtt.c +++ b/arch/arm/mach-omap1/board-palmtt.c @@ -45,6 +45,7 @@ #include mach/usb.h #include common.h +#include dma.h #define PALMTT_USBDETECT_GPIO 0 #define PALMTT_CABLE_GPIO 1 diff --git a/arch/arm/mach-omap1/board-palmz71.c b/arch/arm/mach-omap1/board-palmz71.c index e311032..e403bc9 100644 --- a/arch/arm/mach-omap1/board-palmz71.c +++ b/arch/arm/mach-omap1/board-palmz71.c @@ -47,6 +47,7 @@ #include mach/usb.h #include common.h +#include dma.h #define PALMZ71_USBDETECT_GPIO 0 #define PALMZ71_PENIRQ_GPIO6 diff --git a/arch/arm/mach-omap1/board-sx1.c b/arch/arm/mach-omap1/board-sx1.c index 13bf2cc..1248fcc 100644 --- a/arch/arm/mach-omap1/board-sx1.c +++ b/arch/arm/mach-omap1/board-sx1.c @@ -45,6 +45,7 @@ #include mach/usb.h #include common.h +#include dma.h /* Write to I2C device */ int sx1_i2c_write_byte(u8 devaddr, u8 regoffset, u8 value) diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c index 0cc54dd..890db8f 100644 --- a/arch/arm/mach-omap1/devices.c +++ b/arch/arm/mach-omap1/devices.c @@ -30,6 +30,7 @@ #include common.h #include clock.h +#include dma.h #if defined(CONFIG_SND_SOC) || defined(CONFIG_SND_SOC_MODULE) diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c index 29007fe..40f1dc4 100644 --- a/arch/arm/mach-omap1/dma.c +++ b/arch/arm/mach-omap1/dma.c @@ -30,6 +30,8 @@ #include mach/irqs.h +#include dma.h + #define OMAP1_DMA_BASE (0xfffed800) #define OMAP1_LOGICAL_DMA_CH_COUNT 17 #define OMAP1_DMA_STRIDE 0x40 diff --git a/arch/arm/mach-omap1/dma.h b/arch/arm/mach-omap1/dma.h new file mode 100644 index 000..da6345d --- /dev/null +++ b/arch/arm/mach-omap1/dma.h @@ -0,0 +1,83 @@ +/* + * OMAP1 DMA channel definitions + * + * 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; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __OMAP1_DMA_CHANNEL_H +#define __OMAP1_DMA_CHANNEL_H + +/* DMA channels for omap1 */ +#define OMAP_DMA_NO_DEVICE 0 +#define OMAP_DMA_MCSI1_TX 1 +#define OMAP_DMA_MCSI1_RX 2
[PATCH V2 3/7] ARM: OMAP2+: DMA: Moving OMAP2+ DMA channel definitions to mach-omap2
Similar to omap1, some of the omap2+ dma channel definitions are used by some drivers. For moving omap2+ dma channel definitions to mach-omap2/, the used ones should be defined locally to driver. Drivers can eliminate it using DT, platform data, or IORESOURCE_DMA And moving omap2+ DMA channel definitions to mach-omap2 Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- arch/arm/mach-omap2/devices.c |1 + arch/arm/mach-omap2/dma.h | 131 .../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |1 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 + arch/arm/plat-omap/include/plat/dma.h | 110 drivers/media/platform/omap3isp/isphist.c |2 + drivers/mmc/host/omap.c|6 + drivers/mtd/nand/omap2.c |2 + drivers/usb/musb/tusb6010_omap.c |7 ++ 9 files changed, 151 insertions(+), 110 deletions(-) create mode 100644 arch/arm/mach-omap2/dma.h diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index d092d2a8..998152c 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -34,6 +34,7 @@ #include mux.h #include control.h #include devices.h +#include dma.h #define L3_MODULES_MAX_LEN 12 #define L3_MODULES 3 diff --git a/arch/arm/mach-omap2/dma.h b/arch/arm/mach-omap2/dma.h new file mode 100644 index 000..eba80db --- /dev/null +++ b/arch/arm/mach-omap2/dma.h @@ -0,0 +1,131 @@ +/* + * OMAP2PLUS DMA channel definitions + * + * 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; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef __OMAP2PLUS_DMA_CHANNEL_H +#define __OMAP2PLUS_DMA_CHANNEL_H + + +/* DMA channels for 24xx */ +#define OMAP24XX_DMA_NO_DEVICE 0 +#define OMAP24XX_DMA_XTI_DMA 1 /* S_DMA_0 */ +#define OMAP24XX_DMA_EXT_DMAREQ0 2 /* S_DMA_1 */ +#define OMAP24XX_DMA_EXT_DMAREQ1 3 /* S_DMA_2 */ +#define OMAP24XX_DMA_GPMC 4 /* S_DMA_3 */ +#define OMAP24XX_DMA_GFX 5 /* S_DMA_4 */ +#define OMAP24XX_DMA_DSS 6 /* S_DMA_5 */ +#define OMAP242X_DMA_VLYNQ_TX 7 /* S_DMA_6 */ +#define OMAP24XX_DMA_EXT_DMAREQ2 7 /* S_DMA_6 */ +#define OMAP24XX_DMA_CWT 8 /* S_DMA_7 */ +#define OMAP24XX_DMA_AES_TX9 /* S_DMA_8 */ +#define OMAP24XX_DMA_AES_RX10 /* S_DMA_9 */ +#define OMAP24XX_DMA_DES_TX11 /* S_DMA_10 */ +#define OMAP24XX_DMA_DES_RX12 /* S_DMA_11 */ +#define OMAP24XX_DMA_SHA1MD5_RX13 /* S_DMA_12 */ +#define OMAP34XX_DMA_SHA2MD5_RX13 /* S_DMA_12 */ +#define OMAP242X_DMA_EXT_DMAREQ2 14 /* S_DMA_13 */ +#define OMAP242X_DMA_EXT_DMAREQ3 15 /* S_DMA_14 */ +#define OMAP242X_DMA_EXT_DMAREQ4 16 /* S_DMA_15 */ +#define OMAP242X_DMA_EAC_AC_RD 17 /* S_DMA_16 */ +#define OMAP242X_DMA_EAC_AC_WR 18 /* S_DMA_17 */ +#define OMAP242X_DMA_EAC_MD_UL_RD 19 /* S_DMA_18 */ +#define OMAP242X_DMA_EAC_MD_UL_WR 20 /* S_DMA_19 */ +#define OMAP242X_DMA_EAC_MD_DL_RD 21 /* S_DMA_20 */ +#define OMAP242X_DMA_EAC_MD_DL_WR 22 /* S_DMA_21 */ +#define OMAP242X_DMA_EAC_BT_UL_RD 23 /* S_DMA_22 */ +#define OMAP242X_DMA_EAC_BT_UL_WR 24 /* S_DMA_23 */ +#define OMAP242X_DMA_EAC_BT_DL_RD 25 /* S_DMA_24 */ +#define OMAP242X_DMA_EAC_BT_DL_WR 26 /* S_DMA_25 */ +#define OMAP243X_DMA_EXT_DMAREQ3 14 /* S_DMA_13 */ +#define OMAP24XX_DMA_SPI3_TX0 15 /* S_DMA_14 */ +#define OMAP24XX_DMA_SPI3_RX0 16 /* S_DMA_15 */ +#define OMAP24XX_DMA_MCBSP3_TX 17 /* S_DMA_16 */ +#define OMAP24XX_DMA_MCBSP3_RX 18 /* S_DMA_17 */ +#define OMAP24XX_DMA_MCBSP4_TX 19 /* S_DMA_18 */ +#define OMAP24XX_DMA_MCBSP4_RX 20 /* S_DMA_19 */ +#define OMAP24XX_DMA_MCBSP5_TX 21 /* S_DMA_20 */ +#define OMAP24XX_DMA_MCBSP5_RX 22 /* S_DMA_21 */ +#define OMAP24XX_DMA_SPI3_TX1 23 /* S_DMA_22 */ +#define OMAP24XX_DMA_SPI3_RX1 24 /* S_DMA_23 */ +#define OMAP243X_DMA_EXT_DMAREQ4 25 /* S_DMA_24
[PATCH V2 5/7] ARM: OMAP1: Remove omap_reserve() callback for all omap1 boards
omap_reserve() is a stub for omap1. So dropping omap_reserve callback from all OMAP1 board files. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- arch/arm/mach-omap1/board-ams-delta.c |1 - arch/arm/mach-omap1/board-fsample.c |1 - arch/arm/mach-omap1/board-generic.c |1 - arch/arm/mach-omap1/board-h2.c|1 - arch/arm/mach-omap1/board-h3.c|1 - arch/arm/mach-omap1/board-htcherald.c |1 - arch/arm/mach-omap1/board-innovator.c |1 - arch/arm/mach-omap1/board-nokia770.c |1 - arch/arm/mach-omap1/board-osk.c |1 - arch/arm/mach-omap1/board-palmte.c|1 - arch/arm/mach-omap1/board-palmtt.c|1 - arch/arm/mach-omap1/board-palmz71.c |1 - arch/arm/mach-omap1/board-perseus2.c |1 - arch/arm/mach-omap1/board-sx1.c |1 - arch/arm/mach-omap1/board-voiceblue.c |1 - 15 files changed, 15 deletions(-) diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c index 9518bf5..e50b022 100644 --- a/arch/arm/mach-omap1/board-ams-delta.c +++ b/arch/arm/mach-omap1/board-ams-delta.c @@ -613,7 +613,6 @@ MACHINE_START(AMS_DELTA, Amstrad E3 (Delta)) .atag_offset= 0x100, .map_io = ams_delta_map_io, .init_early = omap1_init_early, - .reserve= omap_reserve, .init_irq = omap1_init_irq, .init_machine = ams_delta_init, .init_late = ams_delta_init_late, diff --git a/arch/arm/mach-omap1/board-fsample.c b/arch/arm/mach-omap1/board-fsample.c index 4b6de70..acd3ba6 100644 --- a/arch/arm/mach-omap1/board-fsample.c +++ b/arch/arm/mach-omap1/board-fsample.c @@ -362,7 +362,6 @@ MACHINE_START(OMAP_FSAMPLE, OMAP730 F-Sample) .atag_offset= 0x100, .map_io = omap_fsample_map_io, .init_early = omap1_init_early, - .reserve= omap_reserve, .init_irq = omap1_init_irq, .init_machine = omap_fsample_init, .init_late = omap1_init_late, diff --git a/arch/arm/mach-omap1/board-generic.c b/arch/arm/mach-omap1/board-generic.c index 4ec579f..608e7d2 100644 --- a/arch/arm/mach-omap1/board-generic.c +++ b/arch/arm/mach-omap1/board-generic.c @@ -81,7 +81,6 @@ MACHINE_START(OMAP_GENERIC, Generic OMAP1510/1610/1710) .atag_offset= 0x100, .map_io = omap16xx_map_io, .init_early = omap1_init_early, - .reserve= omap_reserve, .init_irq = omap1_init_irq, .init_machine = omap_generic_init, .init_late = omap1_init_late, diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c index 4c2cb8e..fdc847d 100644 --- a/arch/arm/mach-omap1/board-h2.c +++ b/arch/arm/mach-omap1/board-h2.c @@ -459,7 +459,6 @@ MACHINE_START(OMAP_H2, TI-H2) .atag_offset= 0x100, .map_io = omap16xx_map_io, .init_early = omap1_init_early, - .reserve= omap_reserve, .init_irq = omap1_init_irq, .init_machine = h2_init, .init_late = omap1_init_late, diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c index 3e638b8..2768f99 100644 --- a/arch/arm/mach-omap1/board-h3.c +++ b/arch/arm/mach-omap1/board-h3.c @@ -452,7 +452,6 @@ MACHINE_START(OMAP_H3, TI OMAP1710 H3 board) .atag_offset= 0x100, .map_io = omap16xx_map_io, .init_early = omap1_init_early, - .reserve= omap_reserve, .init_irq = omap1_init_irq, .init_machine = h3_init, .init_late = omap1_init_late, diff --git a/arch/arm/mach-omap1/board-htcherald.c b/arch/arm/mach-omap1/board-htcherald.c index 87ab208..bd0d6fd 100644 --- a/arch/arm/mach-omap1/board-htcherald.c +++ b/arch/arm/mach-omap1/board-htcherald.c @@ -600,7 +600,6 @@ MACHINE_START(HERALD, HTC Herald) .atag_offset= 0x100, .map_io = htcherald_map_io, .init_early = omap1_init_early, - .reserve= omap_reserve, .init_irq = omap1_init_irq, .init_machine = htcherald_init, .init_late = omap1_init_late, diff --git a/arch/arm/mach-omap1/board-innovator.c b/arch/arm/mach-omap1/board-innovator.c index db5f7d2..1b7a62e 100644 --- a/arch/arm/mach-omap1/board-innovator.c +++ b/arch/arm/mach-omap1/board-innovator.c @@ -454,7 +454,6 @@ MACHINE_START(OMAP_INNOVATOR, TI-Innovator) .atag_offset= 0x100, .map_io = innovator_map_io, .init_early = omap1_init_early, - .reserve= omap_reserve, .init_irq = omap1_init_irq, .init_machine = innovator_init, .init_late = omap1_init_late, diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c index 7d5c06d..6b24394 100644 --- a/arch/arm/mach-omap1/board-nokia770.c +++ b/arch/arm/mach-omap1/board-nokia770.c @@ -251,7 +251,6 @@
[PATCH V2 4/7] ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.h
Move plat/dma.h to plat-omap/dma-omap.h as part of single
zImage work
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/mach-omap1/board-h2.c |2 +-
arch/arm/mach-omap1/board-h3.c |2 +-
arch/arm/mach-omap1/board-palmte.c |2 +-
arch/arm/mach-omap1/board-palmtt.c |2 +-
arch/arm/mach-omap1/board-palmz71.c |2 +-
arch/arm/mach-omap1/board-sx1.c |2 +-
arch/arm/mach-omap1/devices.c |2 +-
arch/arm/mach-omap1/dma.c |2 +-
arch/arm/mach-omap1/io.c|2 +-
arch/arm/mach-omap1/lcd_dma.c |2 +-
arch/arm/mach-omap1/mcbsp.c |2 +-
arch/arm/mach-omap1/pm.c|2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c|2 +-
arch/arm/mach-omap2/board-rx51.c|2 +-
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/dma.c |2 +-
arch/arm/mach-omap2/io.c|2 +-
arch/arm/mach-omap2/mcbsp.c |2 +-
arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
arch/arm/mach-omap2/pm24xx.c|2 +-
arch/arm/mach-omap2/pm34xx.c|2 +-
arch/arm/mach-omap2/serial.c|2 +-
arch/arm/plat-omap/common.c |2 +-
arch/arm/plat-omap/dma.c|2 +-
arch/arm/plat-omap/include/{plat/dma.h = plat-omap/dma-omap.h} |2 +-
drivers/crypto/omap-aes.c |2 +-
drivers/crypto/omap-sham.c |2 +-
drivers/dma/omap-dma.c |2 +-
drivers/media/platform/omap/omap_vout.c |2 +-
drivers/media/platform/omap/omap_vout_vrfb.c|2 +-
drivers/media/platform/omap3isp/ispstat.h |2 +-
drivers/media/platform/soc_camera/omap1_camera.c|3 +--
drivers/mmc/host/omap.c |2 +-
drivers/mtd/nand/omap2.c|2 +-
drivers/mtd/onenand/omap2.c |2 +-
drivers/usb/gadget/omap_udc.c |2 +-
drivers/usb/musb/tusb6010_omap.c|2 +-
drivers/video/omap/lcdc.c |2 +-
drivers/video/omap/omapfb_main.c|2 +-
drivers/video/omap/sossi.c |2 +-
48 files changed, 48 insertions(+), 49 deletions(-)
rename arch/arm/plat-omap/include/{plat/dma.h = plat-omap/dma-omap.h} (99%)
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 72855ce..4c2cb8e 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -39,8 +39,8 @@
#include asm/mach/map.h
#include mach/mux.h
-#include plat/dma.h
#include plat/tc.h
+#include plat-omap/dma-omap.h
#include mach/irda.h
#include linux/platform_data/keypad-omap.h
#include mach/flash.h
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index fa98327..3e638b8 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -43,7 +43,7 @@
#include mach/mux.h
#include plat/tc.h
#include linux/platform_data/keypad-omap.h
-#include plat/dma.h
+#include plat-omap/dma-omap.h
#include mach/flash.h
#include mach/hardware.h
diff --git a/arch/arm/mach-omap1/board-palmte.c
b/arch/arm/mach-omap1/board-palmte.c
index 75ac3cd..eac94c2 100644
--- a/arch/arm/mach-omap1/board-palmte.c
+++ b/arch/arm/mach-omap1/board-palmte.c
@@ -37,7 +37,7 @@
#include mach/flash.h
#include mach/mux.h
#include plat/tc.h
-#include plat/dma.h
+#include plat-omap/dma-omap.h
#include
[PATCH V2 6/7] ARM: OMAP2+: Move omap_reserve() locally to mach-omap2
omap_reserve() callback is defned only for mach-omap2.
So, moving definition of omap_reserve() to mach-omap2.
This helps is moving plat/omap_secure.h local to
mach-omap2
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/mach-omap2/common.c | 20
arch/arm/mach-omap2/common.h |1 +
arch/arm/plat-omap/common.c | 21 -
arch/arm/plat-omap/include/plat/common.h |1 -
4 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 17950c6..4ce0d63 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -16,8 +16,11 @@
#include linux/init.h
#include linux/clk.h
#include linux/io.h
+#include linux/platform_data/dsp-omap.h
#include plat/clock.h
+#include plat/omap-secure.h
+#include plat/vram.h
#include soc.h
#include iomap.h
@@ -200,3 +203,20 @@ void __init omap5_map_io(void)
omap5_map_common_io();
}
#endif
+
+/*
+ * Stub function for OMAP2 so that common files
+ * continue to build when custom builds are used
+ */
+int __weak omap_secure_ram_reserve_memblock(void)
+{
+ return 0;
+}
+
+void __init omap_reserve(void)
+{
+ omap_vram_reserve_sdram_memblock();
+ omap_dsp_reserve_sdram_memblock();
+ omap_secure_ram_reserve_memblock();
+ omap_barrier_reserve_memblock();
+}
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 7045e4d..e84c589 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -338,6 +338,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
struct omap2_hsmmc_info;
extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
+extern void omap_reserve(void);
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index b388e87..aa23d49 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -17,32 +17,11 @@
#include linux/dma-mapping.h
#include plat/common.h
-#include plat/vram.h
-#include linux/platform_data/dsp-omap.h
#include plat-omap/dma-omap.h
-#include plat/omap-secure.h
-
-void __init omap_reserve(void)
-{
- omap_vram_reserve_sdram_memblock();
- omap_dsp_reserve_sdram_memblock();
- omap_secure_ram_reserve_memblock();
- omap_barrier_reserve_memblock();
-}
-
void __init omap_init_consistent_dma_size(void)
{
#ifdef CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE
init_consistent_dma_size(CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE 20);
#endif
}
-
-/*
- * Stub function for OMAP2 so that common files
- * continue to build when custom builds are used
- */
-int __weak omap_secure_ram_reserve_memblock(void)
-{
- return 0;
-}
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index d1cb6f5..cb337c3 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -34,7 +34,6 @@ extern int __init omap_init_clocksource_32k(void __iomem
*vbase);
extern void __init omap_check_revision(void);
-extern void omap_reserve(void);
extern int omap_dss_reset(struct omap_hwmod *);
void omap_sram_init(void);
--
1.7.10.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 V2 7/7] ARM: OMAP: Move plat/omap-secure.h locally to mach-omap2
Moving plat/omap-secure.h locally to mach-omap2/
as part of single zImage work
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/mach-omap2/common.c |2 +-
arch/arm/mach-omap2/omap-secure.c |1 -
arch/arm/mach-omap2/omap-secure.h |7 +++
arch/arm/mach-omap2/omap4-common.c|2 +-
arch/arm/plat-omap/include/plat/omap-secure.h | 14 --
5 files changed, 9 insertions(+), 17 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/omap-secure.h
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 4ce0d63..b0f21b7 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -19,7 +19,6 @@
#include linux/platform_data/dsp-omap.h
#include plat/clock.h
-#include plat/omap-secure.h
#include plat/vram.h
#include soc.h
@@ -27,6 +26,7 @@
#include common.h
#include sdrc.h
#include control.h
+#include omap-secure.h
/* Global address base setup code */
diff --git a/arch/arm/mach-omap2/omap-secure.c
b/arch/arm/mach-omap2/omap-secure.c
index a004cb9..98624fe 100644
--- a/arch/arm/mach-omap2/omap-secure.c
+++ b/arch/arm/mach-omap2/omap-secure.c
@@ -18,7 +18,6 @@
#include asm/cacheflush.h
#include asm/memblock.h
-#include plat/omap-secure.h
#include omap-secure.h
static phys_addr_t omap_secure_memblock_base;
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index c90a435..0e72917 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -52,6 +52,13 @@ extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32
nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
+extern int omap_secure_ram_reserve_memblock(void);
+#ifdef CONFIG_OMAP4_ERRATA_I688
+extern int omap_barrier_reserve_memblock(void);
+#else
+static inline void omap_barrier_reserve_memblock(void)
+{ }
+#endif
#endif /* __ASSEMBLER__ */
#endif /* OMAP_ARCH_OMAP_SECURE_H */
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index e1f2897..ae57b63 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -26,7 +26,6 @@
#include asm/memblock.h
#include plat/sram.h
-#include plat/omap-secure.h
#include plat/mmc.h
#include omap-wakeupgen.h
@@ -35,6 +34,7 @@
#include common.h
#include hsmmc.h
#include omap4-sar-layout.h
+#include omap-secure.h
#ifdef CONFIG_CACHE_L2X0
static void __iomem *l2cache_base;
diff --git a/arch/arm/plat-omap/include/plat/omap-secure.h
b/arch/arm/plat-omap/include/plat/omap-secure.h
deleted file mode 100644
index 0e4acd2..000
--
1.7.10.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
[GIT PULL] OMAP DSS for v3.7
Hi Florian, Here are omapdss changes for 3.7 merge window. There's something funny with the diff stat, though. I can see a few changes there that I have not made, for example to drivers/video/console/fbcon.c. I believe they come from my Merge branch 'fbdev-for-linus' of git://github.com/schandinat/linux-2.6, although I don't know why they show up in the diff stat. Merge with v3.6 goes without conflicts, but there will be some conflicts with OMAP platform stuff, at least according to linux-next reports. Those conflicts are trivial, though. Tomi The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d: Linux 3.6-rc4 (2012-09-01 10:39:58 -0700) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.7 for you to fetch changes up to 13b1ba7de8d0ecc42e4f9c002d5b0c1a48f05e58: OMAPDSS: add missing include for string.h (2012-09-28 10:03:03 +0300) Omapdss driver changes for the 3.7 merge window. Notable changes: * Basic writeback support for DISPC level. Writeback is not yet usable, though, as we need higher level code to actually expose the writeback feature to userspace. * Rewriting the omapdss output drivers. We're trying to remove the hard links between the omapdss and the panels, and this rewrite work moves us closer to that goal. * Cleanup and restructuring patches that have been made while working on device tree support for omapdss. Device tree support is still some way ahead, but these patches are good cleanups in themselves. * Basic OMAP5 DSS support for DPI and DSI outputs. * Workaround for the problem that GFX overlay's fifo is too small for high resolution scenarios, causing underflows. * Cleanups that remove dependencies to omap platform code. Archit Taneja (70): OMAPDSS: APPLY: Constify timings argument in dss_mgr_set_timings OMAPDSS: DPI: Add locking for DPI interface OMAPDSS: Displays: Add locking in generic DPI panel driver OMAPDSS: DPI: Maintain our own timings field in driver data OMAPDSS: DPI displays: Take care of panel timings in the driver itself OMAPDSS: DSI: Maintain own copy of timings in driver data OMAPDSS: DSI: Add function to set panel size for command mode panels OMAPDSS: DSI: Update manager timings on a manual update OMAPDSS: HDMI: Use our own omap_video_timings field when setting interface timings OMAPDSS: HDMI: Add locking for hdmi interface set timing functions OMAPDSS: SDI: Create a function to set timings OMAPDSS: SDI: Maintain our own timings field in driver data OMAPDSS: VENC: Split VENC into interface and panel driver OMAPDSS: VENC: Maintain our own timings field in driver data OMAPDSS: RFBI: Remove partial update support OMAPDSS: RFBI: Add function to set panel size OMAPDSS: DSI: Maintain copy of pixel format in driver data OMAPDSS: RFBI: Maintain copy of pixel size in driver data OMAPDSS: RFBI: Maintain copy of number of data lines in driver data OMAPDSS: DPI: Maintain copy of number of data lines in driver data OMAPDSS: SDI: Maintain copy of data pairs in driver data OMAPDSS: DSI: Maintain copy of operation mode in driver data OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timings OMAPDSS: DSI: Maintain copy of video mode timings in driver data OMAPDSS: RFBI: Maitain copy of rfbi timings in driver data OMAPDSS: VENC: Maintain copy of venc type in driver data OMAPDSS: VENC: Maintian copy of video output polarity info in private data OMAPFB: Clear framebuffers before they are registered OMAPDSS: Add basic omap5 features to dss and dispc OMAPDSS: DSI: Pass dsi platform device wherever possible OMAPDSS: APPLY: Remove omap_dss_device references in wait_for_go functions OMAPDSS: outputs: Create a new entity called outputs OMAPDSS: outputs: Create and register output instances OMAPDSS: output: Add set/unset device ops for omap_dss_output OMAPDSS: APPLY: Add manager set/unset output ops for omap_overlay_manager OMAPDSS: Remove manager-device references OMAP_VOUT: Remove manager-device references OMAPFB: remove manager-device references OMAPDRM: Remove manager-device references OMAPDSS: Create links between managers, outputs and devices OMAPDSS: DPI: Replace dssdev-manager with dssdev-output-manager references OMAPDSS: DSI: Remove dsi_pdev_map global struct OMAPDSS: DSI: Replace dssdev-manager with dssdev-output-manager references OMAPDSS: SDI: Replace dssdev-manager with dssdev-output-manager references OMAPDSS: RFBI: Replace dssdev-manager with dssdev-output-manager references OMAPDSS: VENC: Replace dssdev-manager with dssdev-output-manager references
OMAP baseline test results for v3.6
Here are some basic OMAP test results for Linux v3.6. Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.6/ Passing tests - Boot to userspace: 2420n800, 2430sdp, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk PM ret/off, suspend + dynamic idle: 3530es3beagle, 3730beaglexm Failing tests: fixed by posted patches -- PM tests: * 4430ES2 Panda: UART corruption during long transmit buffers - Presumably due to either a missing hardware workaround or a bug in the OMAP serial driver - Corruption disappears after this series is applied: http://www.spinics.net/lists/arm-kernel/msg192995.html * Unknown whether these are an actual fix, or just mask the problem Other: * RCU stall messages appear if boards are booted into a minimal userspace and left to sit for a few minutes - Not shown in the current test logs - Fixed by http://marc.info/?l=linux-arm-kernelm=134835120600590w=2 * 2420N800: powers down 30 seconds after boot - Presumably due to missing CBUS patches for watchdog control Failing tests: needing investigation Boot tests: * CM-T3517: L3 in-band error with IPSS during boot - Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2 - Longstanding issue; does not occur on the 3517EVM * 3517EVM CM-T3517: boot hangs - Probably due to the use of NFS root; there are likely some Kconfig, board file, and PM issues with EMAC PM tests: * 37xx EVM: CORE not entering dynamic off-idle - Cause unknown; dynamic retention-idle seems to work; system suspend to off works * 3730 Beagle XM: does not serial wake from off-idle suspend when console UART doesn't clock gate (debug ignore_loglevel) - Not shown in the current test logs; cause unknown Kernel size/memory differences -- vmlinux object size (delta in bytes from test_v3.5 (28a33cbc24e4256c143dce96c7d93bf423229f92)): textdata bss total kernel +106549 +17784 +2380 +126713 2430_testconfig +38971 +5296+920 +45187 5912osk_testconfig +98563 +30344-316 +128591 am33xx_testconfig +63542 +14584 +1992 +80118 n800_b_testconfig +58180 +14808 +1988 +74976 n800_multi_omap2xxx +39388 +15672 +1960 +57020 n800_testconfig +49048 +5328+920 +55296 omap1510_defconfig +45816 +5264+952 +52032 omap1_defconfig +42090 +15360-156 +57294 omap2_4_testconfig +121890 +23480 +2884 +148254 omap2plus_defconfig +125042 +23624 +2884 +151550 omap2plus_defconfig_cpupm +54593 +21360-380 +75573 omap2plus_no_pm +83137 +23760-316 +106581 omap3_4_testconfig +55217 +21576 +1036 +77829 omap3_testconfig +62061 +18840 +4 +80905 omap4_testconfig +86789 +21608 +1380 +109777 rmk_omap3430_ldp_oldconfig +96177 -14216+208 +82169 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from test_v3.5 (28a33cbc24e4256c143dce96c7d93bf423229f92)) avail rsrvd high freed board kconfig -72k72k . . 2420n800 omap2plus_defconfig -156k 156k . 8k 2430sdpomap2plus_defconfig -156k 156k . . 3517evmomap2plus_defconfig -156k 156k . 8k 3530es3beagle omap2plus_defconfig -156k 156k . 8k 3730beaglexm omap2plus_defconfig -156k 156k . 8k 37xxevmomap2plus_defconfig -160k 160k . 8k 4430es2panda omap2plus_defconfig -56k56k . 4k 5912oskomap2plus_defconfig -156k 156k . . cmt3517omap2plus_defconfig - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] leds: leds-gpio: adopt pinctrl support
On Mon, Oct 1, 2012 at 5:44 PM, Tony Lindgren t...@atomide.com wrote: OK that is typical pinctrl driver implementation work. I hope Tony can advice on this? I think we're best off to just stick to alternative named modes passed from device tree. For example, for GPIO wake-ups you can have named modes such as default, enabled and idle where idle muxes things for GPIO wake-ups for the duration of idle. It seems that should also work for leds-gpio. And you can define more named modes as needed. This is what we're doing for ux500 and should be a good model. You really don't want the client driver or the GPIO driver doing things like pull-up/down automatically as that is board specific and can also depend on things like externall pull resistors. Nope. We've had instances of people getting bad leakage because of pulling down a line where there is already a pull-down resistor on the board :-( OK so the threshold is that we need to get it right for the first one and then the others will look good too. It seems we want to keep leds-gpio, gpio framework and pinctrl framework generic. It also seems you should be able to do what you're describing using the pinctrl named modes. I think so too. 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: OMAP baseline test results for v3.6
On Mon, 1 Oct 2012, Paul Walmsley wrote: Kernel size/memory differences -- vmlinux object size (delta in bytes from test_v3.5 (28a33cbc24e4256c143dce96c7d93bf423229f92)): textdata bss total kernel +106549 +17784 +2380 +126713 2430_testconfig +38971 +5296+920 +45187 5912osk_testconfig +98563 +30344-316 +128591 am33xx_testconfig +63542 +14584 +1992 +80118 n800_b_testconfig +58180 +14808 +1988 +74976 n800_multi_omap2xxx +39388 +15672 +1960 +57020 n800_testconfig +49048 +5328+920 +55296 omap1510_defconfig +45816 +5264+952 +52032 omap1_defconfig +42090 +15360-156 +57294 omap2_4_testconfig +121890 +23480 +2884 +148254 omap2plus_defconfig +125042 +23624 +2884 +151550 omap2plus_defconfig_cpupm +54593 +21360-380 +75573 omap2plus_no_pm +83137 +23760-316 +106581 omap3_4_testconfig +55217 +21576 +1036 +77829 omap3_testconfig +62061 +18840 +4 +80905 omap4_testconfig +86789 +21608 +1380 +109777 rmk_omap3430_ldp_oldconfig +96177 -14216+208 +82169 rmk_omap4430_sdp_oldconfig One comment about some of these vmlinux sizes. Due to the way the configs are generated, the AM33xx data is being included into some of the kernels that shouldn't have it. So for configs like omap3_4_testconfig or omap2_4_testconfig, that AM33xx data accounts for about 12K of the 'data' column that wasn't intended. Kconfig handling in the scripts here needs some work; with luck, will address that during this development cycle. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which git to clone for testing prior to submitting bugs?
On 10/01/2012 09:57 AM, li...@johnea.net wrote: On 10/01/2012 09:50 AM, Robert Nelson wrote: You guys are very close... Your config-3.5.4-archarm-3 config just needed one more change: CONFIG_PANEL_TFP410=m - CONFIG_PANEL_TFP410=y That did it! We've got X running on BeagleboardxM DVI with 3.5.4. We're also starting testing of 3.6.0 this afternoon, since it's official now. Although the main thing for my application was having buddy=spidev and working DVI video in the same kernel, which we now have with 3.5.4. Thank you again Robert for your patient support! johnea -- 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/5] [media] omap3isp: Fix compilation error in ispreg.h
Commit c49f34bc (ARM: OMAP2+ Move SoC specific headers to be local to mach-omap2) moved omap34xx.h to mach-omap2. This broke omap3isp, as it includes omap34xx.h. Instead of moving omap34xx to platform_data, simply add the two definitions the driver needs and remove the include altogether. Signed-off-by: Ido Yariv i...@wizery.com --- drivers/media/platform/omap3isp/ispreg.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/omap3isp/ispreg.h b/drivers/media/platform/omap3isp/ispreg.h index 084ea77..e2c57f3 100644 --- a/drivers/media/platform/omap3isp/ispreg.h +++ b/drivers/media/platform/omap3isp/ispreg.h @@ -27,13 +27,13 @@ #ifndef OMAP3_ISP_REG_H #define OMAP3_ISP_REG_H -#include plat/omap34xx.h - - #define CM_CAM_MCLK_HZ 17280 /* Hz */ /* ISP Submodules offset */ +#define L4_34XX_BASE 0x4800 +#define OMAP3430_ISP_BASE (L4_34XX_BASE + 0xBC000) + #define OMAP3ISP_REG_BASE OMAP3430_ISP_BASE #define OMAP3ISP_REG(offset) (OMAP3ISP_REG_BASE + (offset)) -- 1.7.11.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 v2 2/5] iommu/omap: Merge iommu2.h into iommu.h
Since iommu is not supported on OMAP1 and will not likely to ever be
supported, merge plat/iommu2.h into iommu.h so only one file would have
to move to platform_data/ as part of the single zImage effort.
Signed-off-by: Ido Yariv i...@wizery.com
---
arch/arm/plat-omap/include/plat/iommu.h | 88 +++--
arch/arm/plat-omap/include/plat/iommu2.h | 96
2 files changed, 83 insertions(+), 101 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/iommu2.h
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 68b5f03..7e8c7b6 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -13,6 +13,12 @@
#ifndef __MACH_IOMMU_H
#define __MACH_IOMMU_H
+#include linux/io.h
+
+#if defined(CONFIG_ARCH_OMAP1)
+#error iommu for this processor not implemented yet
+#endif
+
struct iotlb_entry {
u32 da;
u32 pa;
@@ -159,11 +165,70 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 3)
#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 4)
-#if defined(CONFIG_ARCH_OMAP1)
-#error iommu for this processor not implemented yet
-#else
-#include plat/iommu2.h
-#endif
+/*
+ * MMU Register offsets
+ */
+#define MMU_REVISION 0x00
+#define MMU_SYSCONFIG 0x10
+#define MMU_SYSSTATUS 0x14
+#define MMU_IRQSTATUS 0x18
+#define MMU_IRQENABLE 0x1c
+#define MMU_WALKING_ST 0x40
+#define MMU_CNTL 0x44
+#define MMU_FAULT_AD 0x48
+#define MMU_TTB0x4c
+#define MMU_LOCK 0x50
+#define MMU_LD_TLB 0x54
+#define MMU_CAM0x58
+#define MMU_RAM0x5c
+#define MMU_GFLUSH 0x60
+#define MMU_FLUSH_ENTRY0x64
+#define MMU_READ_CAM 0x68
+#define MMU_READ_RAM 0x6c
+#define MMU_EMU_FAULT_AD 0x70
+
+#define MMU_REG_SIZE 256
+
+/*
+ * MMU Register bit definitions
+ */
+#define MMU_LOCK_BASE_SHIFT10
+#define MMU_LOCK_BASE_MASK (0x1f MMU_LOCK_BASE_SHIFT)
+#define MMU_LOCK_BASE(x) \
+ ((x MMU_LOCK_BASE_MASK) MMU_LOCK_BASE_SHIFT)
+
+#define MMU_LOCK_VICT_SHIFT4
+#define MMU_LOCK_VICT_MASK (0x1f MMU_LOCK_VICT_SHIFT)
+#define MMU_LOCK_VICT(x) \
+ ((x MMU_LOCK_VICT_MASK) MMU_LOCK_VICT_SHIFT)
+
+#define MMU_CAM_VATAG_SHIFT12
+#define MMU_CAM_VATAG_MASK \
+ ((~0UL MMU_CAM_VATAG_SHIFT) MMU_CAM_VATAG_SHIFT)
+#define MMU_CAM_P (1 3)
+#define MMU_CAM_V (1 2)
+#define MMU_CAM_PGSZ_MASK 3
+#define MMU_CAM_PGSZ_1M(0 0)
+#define MMU_CAM_PGSZ_64K (1 0)
+#define MMU_CAM_PGSZ_4K(2 0)
+#define MMU_CAM_PGSZ_16M (3 0)
+
+#define MMU_RAM_PADDR_SHIFT12
+#define MMU_RAM_PADDR_MASK \
+ ((~0UL MMU_RAM_PADDR_SHIFT) MMU_RAM_PADDR_SHIFT)
+#define MMU_RAM_ENDIAN_SHIFT 9
+#define MMU_RAM_ENDIAN_MASK(1 MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ENDIAN_BIG (1 MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ENDIAN_LITTLE (0 MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ELSZ_SHIFT 7
+#define MMU_RAM_ELSZ_MASK (3 MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_8 (0 MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_16(1 MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_32(2 MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_NONE (3 MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_MIXED_SHIFT6
+#define MMU_RAM_MIXED_MASK (1 MMU_RAM_MIXED_SHIFT)
+#define MMU_RAM_MIXED MMU_RAM_MIXED_MASK
/*
* utilities for super page(16MB, 1MB, 64KB and 4KB)
@@ -218,4 +283,17 @@ omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf,
ssize_t len);
extern size_t
omap_dump_tlb_entries(struct omap_iommu *obj, char *buf, ssize_t len);
+/*
+ * register accessors
+ */
+static inline u32 iommu_read_reg(struct omap_iommu *obj, size_t offs)
+{
+ return __raw_readl(obj-regbase + offs);
+}
+
+static inline void iommu_write_reg(struct omap_iommu *obj, u32 val, size_t
offs)
+{
+ __raw_writel(val, obj-regbase + offs);
+}
+
#endif /* __MACH_IOMMU_H */
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
deleted file mode 100644
index d4116b5..000
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ /dev/null
@@ -1,96 +0,0 @@
-/*
- * omap iommu: omap2 architecture specific definitions
- *
- * Copyright (C) 2008-2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU hiroshi.d...@nokia.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __MACH_IOMMU2_H
-#define __MACH_IOMMU2_H
-
-#include linux/io.h
-
-/*
- * MMU Register offsets
- */
-#define MMU_REVISION 0x00
[PATCH v2 4/5] arm: omap: Move iommu/iovmm headers to platform_data
Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.
Signed-off-by: Ido Yariv i...@wizery.com
---
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/iommu2.c| 2 +-
arch/arm/mach-omap2/omap-iommu.c| 2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +-
drivers/iommu/omap-iommu-debug.c| 4 ++--
drivers/iommu/omap-iommu.c | 2 +-
drivers/iommu/omap-iovmm.c | 4 ++--
drivers/media/platform/omap3isp/isp.h | 5 +++--
drivers/media/platform/omap3isp/ispvideo.c | 6 --
.../plat/iommu.h = include/linux/platform_data/iommu-omap.h| 0
.../plat/iovmm.h = include/linux/platform_data/iovmm-omap.h| 0
12 files changed, 17 insertions(+), 14 deletions(-)
rename arch/arm/plat-omap/include/plat/iommu.h =
include/linux/platform_data/iommu-omap.h (100%)
rename arch/arm/plat-omap/include/plat/iovmm.h =
include/linux/platform_data/iovmm-omap.h (100%)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..6cd0c2a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -126,7 +126,7 @@ static struct platform_device omap2cam_device = {
#if defined(CONFIG_IOMMU_API)
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
static struct resource omap3isp_resources[] = {
{
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index c986880..82f9174 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -18,7 +18,7 @@
#include linux/slab.h
#include linux/stringify.h
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
/*
* omap2 architecture specific register bit definitions
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index df298d4..a6a4ff8 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -13,7 +13,7 @@
#include linux/module.h
#include linux/platform_device.h
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
#include soc.h
#include common.h
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 2857772..35ebf14 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -26,8 +26,8 @@
#include plat/mmc.h
#include linux/platform_data/asoc-ti-mcbsp.h
#include linux/platform_data/spi-omap2-mcspi.h
+#include linux/platform_data/iommu-omap.h
#include plat/dmtimer.h
-#include plat/iommu.h
#include am35xx.h
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..5850b3e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -27,10 +27,10 @@
#include plat/dma.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/platform_data/asoc-ti-mcbsp.h
+#include linux/platform_data/iommu-omap.h
#include plat/mmc.h
#include plat/dmtimer.h
#include plat/common.h
-#include plat/iommu.h
#include omap_hwmod_common_data.h
#include cm1_44xx.h
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index a0b0309..8c1e30b 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -19,8 +19,8 @@
#include linux/platform_device.h
#include linux/debugfs.h
-#include plat/iommu.h
-#include plat/iovmm.h
+#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/iovmm-omap.h
#include plat/iopgtable.h
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 80844b3..6100334 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -24,7 +24,7 @@
#include asm/cacheflush.h
-#include plat/iommu.h
+#include linux/platform_data/iommu-omap.h
#include plat/iopgtable.h
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index b362fb5..b5ac2cd 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -21,8 +21,8 @@
#include asm/cacheflush.h
#include asm/mach/map.h
-#include plat/iommu.h
-#include plat/iovmm.h
+#include linux/platform_data/iommu-omap.h
+#include linux/platform_data/iovmm-omap.h
#include plat/iopgtable.h
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 8be7487..62c76f9 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -34,8 +34,9 @@
#include linux/platform_device.h
#include linux/wait.h
#include linux/iommu.h
-#include plat/iommu.h
-#include plat/iovmm.h
+
[PATCH v2 5/5] arm: omap: Move iopgtable header to drivers/iommu/
The iopgtable header file is only used by the iommu iovmm drivers, so move it to drivers/iommu/, as part of the single zImage effort. Signed-off-by: Ido Yariv i...@wizery.com --- drivers/iommu/omap-iommu-debug.c | 3 +-- drivers/iommu/omap-iommu.c | 3 +-- .../include/plat/iopgtable.h = drivers/iommu/omap-iopgtable.h | 0 drivers/iommu/omap-iovmm.c | 3 +-- 4 files changed, 3 insertions(+), 6 deletions(-) rename arch/arm/plat-omap/include/plat/iopgtable.h = drivers/iommu/omap-iopgtable.h (100%) diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c index 8c1e30b..84dbfd2 100644 --- a/drivers/iommu/omap-iommu-debug.c +++ b/drivers/iommu/omap-iommu-debug.c @@ -22,8 +22,7 @@ #include linux/platform_data/iommu-omap.h #include linux/platform_data/iovmm-omap.h -#include plat/iopgtable.h - +#include omap-iopgtable.h #include omap-iommu.h #define MAXCOLUMN 100 /* for short messages */ diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index 6100334..1ca33b0 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -26,8 +26,7 @@ #include linux/platform_data/iommu-omap.h -#include plat/iopgtable.h - +#include omap-iopgtable.h #include omap-iommu.h #define for_each_iotlb_cr(obj, n, __i, cr) \ diff --git a/arch/arm/plat-omap/include/plat/iopgtable.h b/drivers/iommu/omap-iopgtable.h similarity index 100% rename from arch/arm/plat-omap/include/plat/iopgtable.h rename to drivers/iommu/omap-iopgtable.h diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c index b5ac2cd..2820e3a 100644 --- a/drivers/iommu/omap-iovmm.c +++ b/drivers/iommu/omap-iovmm.c @@ -24,8 +24,7 @@ #include linux/platform_data/iommu-omap.h #include linux/platform_data/iovmm-omap.h -#include plat/iopgtable.h - +#include omap-iopgtable.h #include omap-iommu.h static struct kmem_cache *iovm_area_cachep; -- 1.7.11.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 v2 3/5] iommu/omap: Make some definitions local
Move some of the definitions in plat/iommu.h that can be made local to
either drivers/iommu or arch/arm/mach-omap2. This minimizes the number
of global definitions once plat/iommu.h moves to platform_data/ as part
of the single zImage effort.
Signed-off-by: Ido Yariv i...@wizery.com
---
arch/arm/mach-omap2/iommu2.c| 6
arch/arm/plat-omap/include/plat/iommu.h | 55 --
drivers/iommu/omap-iommu-debug.c| 2 ++
drivers/iommu/omap-iommu.c | 2 ++
drivers/iommu/omap-iommu.h | 59 +
drivers/iommu/omap-iovmm.c | 2 ++
6 files changed, 71 insertions(+), 55 deletions(-)
create mode 100644 drivers/iommu/omap-iommu.h
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..c986880 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -65,6 +65,12 @@
((pgsz) == MMU_CAM_PGSZ_64K) ? 0x :\
((pgsz) == MMU_CAM_PGSZ_4K) ? 0xf000 : 0)
+/* IOMMU errors */
+#define OMAP_IOMMU_ERR_TLB_MISS(1 0)
+#define OMAP_IOMMU_ERR_TRANS_FAULT (1 1)
+#define OMAP_IOMMU_ERR_EMU_MISS(1 2)
+#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 3)
+#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 4)
static void __iommu_set_twl(struct omap_iommu *obj, bool on)
{
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 7e8c7b6..35a0245 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -77,11 +77,6 @@ struct cr_regs {
};
};
-struct iotlb_lock {
- short base;
- short vict;
-};
-
/* architecture specific functions */
struct iommu_functions {
unsigned long version;
@@ -145,26 +140,6 @@ struct omap_iommu_arch_data {
struct omap_iommu *iommu_dev;
};
-#ifdef CONFIG_IOMMU_API
-/**
- * dev_to_omap_iommu() - retrieves an omap iommu object from a user device
- * @dev: iommu client device
- */
-static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
-{
- struct omap_iommu_arch_data *arch_data = dev-archdata.iommu;
-
- return arch_data-iommu_dev;
-}
-#endif
-
-/* IOMMU errors */
-#define OMAP_IOMMU_ERR_TLB_MISS(1 0)
-#define OMAP_IOMMU_ERR_TRANS_FAULT (1 1)
-#define OMAP_IOMMU_ERR_EMU_MISS(1 2)
-#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 3)
-#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 4)
-
/*
* MMU Register offsets
*/
@@ -192,16 +167,6 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
/*
* MMU Register bit definitions
*/
-#define MMU_LOCK_BASE_SHIFT10
-#define MMU_LOCK_BASE_MASK (0x1f MMU_LOCK_BASE_SHIFT)
-#define MMU_LOCK_BASE(x) \
- ((x MMU_LOCK_BASE_MASK) MMU_LOCK_BASE_SHIFT)
-
-#define MMU_LOCK_VICT_SHIFT4
-#define MMU_LOCK_VICT_MASK (0x1f MMU_LOCK_VICT_SHIFT)
-#define MMU_LOCK_VICT(x) \
- ((x MMU_LOCK_VICT_MASK) MMU_LOCK_VICT_SHIFT)
-
#define MMU_CAM_VATAG_SHIFT12
#define MMU_CAM_VATAG_MASK \
((~0UL MMU_CAM_VATAG_SHIFT) MMU_CAM_VATAG_SHIFT)
@@ -257,32 +222,12 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
/*
* global functions
*/
-extern u32 omap_iommu_arch_version(void);
-
-extern void omap_iotlb_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e);
-
-extern int
-omap_iopgtable_store_entry(struct omap_iommu *obj, struct iotlb_entry *e);
-
-extern int omap_iommu_set_isr(const char *name,
-int (*isr)(struct omap_iommu *obj, u32 da, u32 iommu_errs,
- void *priv),
-void *isr_priv);
-
extern void omap_iommu_save_ctx(struct device *dev);
extern void omap_iommu_restore_ctx(struct device *dev);
extern int omap_install_iommu_arch(const struct iommu_functions *ops);
extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
-extern int omap_foreach_iommu_device(void *data,
- int (*fn)(struct device *, void *));
-
-extern ssize_t
-omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf, ssize_t len);
-extern size_t
-omap_dump_tlb_entries(struct omap_iommu *obj, char *buf, ssize_t len);
-
/*
* register accessors
*/
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index f55fc5d..a0b0309 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -24,6 +24,8 @@
#include plat/iopgtable.h
+#include omap-iommu.h
+
#define MAXCOLUMN 100 /* for short messages */
static DEFINE_MUTEX(iommu_debug_lock);
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index d0b1234..80844b3 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -28,6 +28,8 @@
#include plat/iopgtable.h
+#include omap-iommu.h
+
#define for_each_iotlb_cr(obj, n, __i, cr)
Re: [PATCH] ARM: OMAP: omap_device: fix return value check in omap_device_build_ss()
Wei Yongjun weiyj...@gmail.com writes: From: Wei Yongjun yongjun_...@trendmicro.com.cn In case of error, the function omap_device_alloc() returns ERR_PTR() and never returns NULL pointer. The NULL test in the return value check should be replaced with IS_ERR(). dpatch engine is used to auto generated this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/omap_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index c490240..3f62de6 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -671,7 +671,7 @@ struct platform_device __init *omap_device_build_ss(const char *pdev_name, int p dev_set_name(pdev-dev, %s, pdev-name); od = omap_device_alloc(pdev, ohs, oh_cnt, pm_lats, pm_lats_cnt); - if (!od) + if (IS_ERR(od)) goto odbs_exit1; ret = platform_device_add_data(pdev, pdata, pdata_len); -- 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: OMAP baseline test results for v3.6-rc7
On Thu, 27 Sep 2012, Igor Grinberg wrote: Have you tried the nohlt boot parameter? It looks like the wfi is killing those SoCs once you use EMAC. Just tried with nohlt. Didn't help on CM-T3517 with either NFS or MMC root, nor with the 3517EVM with NFS root. But I was able to get the 3517EVM booting to userspace with MMC root. Looks like the CM-T3517 board file is missing the MMC setup code, so would guess that adding that back in would help. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: fix return value check in beagle_opp_init()
Wei Yongjun weiyj...@gmail.com writes:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function omap_device_get_by_hwmod_name()
returns ERR_PTR() not NULL pointer. The NULL test in the return
value check should be replaced with IS_ERR().
dpatch engine is used to auto generated this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Acked-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 6202fc7..a548d70 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -466,7 +466,7 @@ static void __init beagle_opp_init(void)
mpu_dev = omap_device_get_by_hwmod_name(mpu);
iva_dev = omap_device_get_by_hwmod_name(iva);
- if (!mpu_dev || !iva_dev) {
+ if (IS_ERR(mpu_dev) || IS_ERR(iva_dev)) {
pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
__func__, mpu_dev, iva_dev);
return;
--
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: Beagleboard xM crashes when being set to 800MHz with smartreflex on linux-omap-3.6-rc6
Maximilian Schwerin maximilian.schwe...@tigris.de writes: Hi, I've just built a linux-omap kernel at 3.6-rc6 using omap2plus_defconfig as basis for the kernel config. When I enable smartreflex and switch to 800MHz via echo 1 /sys/kernel/debug/smartreflex/smartreflex_core/autocomp echo 1 /sys/kernel/debug/smartreflex/smartreflex_mpu_iva/autocomp cpufreq-set -f 800MHz the board crashes. If I switch to 800MHz and enable smartreflex later nothing happens. This used to work in my 3.3 based kernel. SmartReflex is kwown to be unstable in mainline and there are several errata that still need fixing for it to be stable. I strongly recommend you simply leave SR disabled. 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 V2 0/7] ARM: OMAP: Move plat/dma*.h,omap-secure.h headers as part of single zImage work
* Lokesh Vutla lokeshvu...@ti.com [121001 11:48]: Patch 1: Dropping the file plat/dma44xx.h as none of the omap44xx dma channel definitions are used. Patch 2: Moving OMAP1 DMA channel definitions to mach-omap1 Patch 3: Moving OMAP2+ DMA channel definitions to mach-omap2 Patch 4: Moving plat/dma.h to plat-omap/dma-omap.h Patch 5: Removing omap_reserve() callback from all omap1 board files. Patch 6: Defining omap_reserve() locally to mach-omap2. Patch 7: Move plat/omap-secure.h locally to mach-omap2 Lokesh Vutla (7): ARM: OMAP: DMA: Removing plat/dma-44xx.h ARM: OMAP1: DMA: Moving OMAP1 DMA channel definitions to mach-omap1 ARM: OMAP2+: DMA: Moving OMAP2 DMA channel definitions to mach-omap2 ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.h ARM: OMAP1: Remove omap_reserve() callback for all omap1 boards ARM: OMAP2+: Move omap_reserve() locally to mach-omap2 ARM: OMAP: Move plat/omap-secure.h locally to mach-omap2 Thanks, I'll be applying these probably at -rc1. If anybody has better ideas for the move of plat/dma.h to plat-omap/dma-omap.h, please yell out now. 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
