Re: [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
On Friday 18 January 2013 10:45 PM, Tony Lindgren wrote:
Hi,
* Santosh Shilimkar santosh.shilim...@ti.com [130118 07:30]:
From: Benoit Cousson b-cous...@ti.com
Adding the hwmod data for OMAP54xx platforms.
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+/* bb2d */
+static struct omap_hwmod_irq_info omap54xx_bb2d_irqs[] = {
+ { .irq = 125 + OMAP54XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
...
+/* c2c */
+static struct omap_hwmod_irq_info omap54xx_c2c_irqs[] = {
+ { .irq = 88 + OMAP54XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
...
+static struct omap_hwmod_dma_info omap54xx_c2c_sdma_reqs[] = {
+ { .dma_req = 68 + OMAP54XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+static struct omap_hwmod_addr_space omap54xx_elm_addrs[] = {
+ {
+ .pa_start = 0x48078000,
+ .pa_end = 0x48078fff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
...
+static struct omap_hwmod_addr_space omap54xx_emif1_addrs[] = {
+ {
+ .pa_start = 0x4c00,
+ .pa_end = 0x4c0003ff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
As discussed earlier on this list, let's not duplicate the standard
resources here as they already are supposed to come from device tree.
Whatever issues prevent us from dropping the duplicate data here need
to be fixed. I believe Benoit already had some scripts/patches for
that and was just waiting for the DMA binding to get merged?
Will have a loot at it. DMA binding pull request narrowly missed
3.8 but should get into 3.9.
Regards
santosh
--
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 07/10] ARM: OMAP5: clock data: Add OMAP54XX full clock tree and headers
On Friday 18 January 2013 10:49 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130118 07:30]: From: Rajendra Nayak rna...@ti.com Add the clock tree related data for OMAP54xx platforms. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Benoit Cousson b-cous...@ti.com [santosh.shilim...@ti.com: Generated es2.0 data] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- As mentioned in the summary, this patch will be updated once the movement of clock data to drivers/clock is clear. Yes let's first fix up the issues prevent us from moving all the cclock*_data.c files to live under drivers/clock/omap. It seems that fixing this issue boils down to rearranging some clock related headers in arch/arm/mach-omap2, and then populating some of the clock data dynamically. Or am I missing something? Am not sure of all the dependencies. Since clock data is using the low level prm/cm APIs, all those needs to be exported some how to move the data. Paul can comment better on it. Regards, Santosh -- 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] i2c: omap: fix draining irq handling
HI, On Sun, Jan 20, 2013 at 08:37:02PM +0200, Aaro Koskinen wrote: Commit 0bdfe0cb803dce699ff337c35d8e97ac355fa417 (i2c: omap: sanitize exit path) changed the interrupt handler to exit early and complete the transfer after the draining IRQ is handled. As a result, the ARDY may not be cleared properly, and it may cause all future I2C transfers to timeout with timeout waiting for bus ready. This is reproducible at least with N900 when twl4030_gpio makes a long write ( FIFO size) during the probe (http://marc.info/?l=linux-omapm=135818882610432w=2). The fix is to continue until we get ARDY interrupt that completes the transfer. Tested with 3.8-rc4 + N900: 20 boots in a row without errors; without the patch the problem triggers after few reboots. fair enough, but ... Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- drivers/i2c/busses/i2c-omap.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 832f16e..4cc2f05 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -963,7 +963,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) i2c_omap_errata_i207(dev, stat); omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR); - break; + continue; ... when we get draining Interrupt, it means we're receiving the last few bytes, meaning that by the time we handle it there's nothing pending to be transferred. I would rather wait for ARDY before exiting omap_i2c_xfer_msg() rather than here. Specially since that was the programming model suggested by our IP engineers. Such handling is part of my other patchset and can be easily ported. OTOH, we might decide to go with this during this -rc and fix it all up for v3.9 on my other patchset. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] ASoC: omap: rx51: Use snd_soc_register_card and add module alias for autoloading driver
Hi,
On 01/20/2013 04:04 AM, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali.ro...@gmail.com
This is really welcome.
It would be even better if we would have commit message...
Also for ASoC patches please CC alsa-devel and the maintainers so they will
also have a chance to review.
There are still couple of things which can improve the rx51 machine driver:
- Switch to use devm_gpio_request_one() so we can remove the failure handling.
- I would introduce platform data for this driver to pass the GPIO numbers.
This is especially important for the RX51_SPEAKER_AMP_TWL_GPIO since it is in
twl4030 and the GPIO range now allocated dynamically so the (192 + 7) might
not be valid anymore.
--
Péter
---
sound/soc/omap/rx51.c | 50
+
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/sound/soc/omap/rx51.c b/sound/soc/omap/rx51.c
index d921ddb..82e3aae 100644
--- a/sound/soc/omap/rx51.c
+++ b/sound/soc/omap/rx51.c
@@ -391,10 +391,9 @@ static struct snd_soc_card rx51_sound_card = {
.num_configs = ARRAY_SIZE(rx51_codec_conf),
};
-static struct platform_device *rx51_snd_device;
-
-static int __init rx51_soc_init(void)
+static int rx51_soc_probe(struct platform_device *pdev)
{
+ struct snd_soc_card *card = rx51_sound_card;
int err;
if (!machine_is_nokia_rx51())
@@ -409,22 +408,18 @@ static int __init rx51_soc_init(void)
if (err)
goto err_gpio_eci_sw;
- rx51_snd_device = platform_device_alloc(soc-audio, -1);
- if (!rx51_snd_device) {
- err = -ENOMEM;
- goto err1;
- }
-
- platform_set_drvdata(rx51_snd_device, rx51_sound_card);
+ card-dev = pdev-dev;
- err = platform_device_add(rx51_snd_device);
- if (err)
- goto err2;
+ err = snd_soc_register_card(card);
+ if (err) {
+ dev_err(pdev-dev, snd_soc_register_card failed (%d)\n, err);
+ goto err_snd;
+ }
return 0;
-err2:
- platform_device_put(rx51_snd_device);
-err1:
+
+err_snd:
+ card-dev = NULL;
gpio_free(RX51_ECI_SW_GPIO);
err_gpio_eci_sw:
gpio_free(RX51_TVOUT_SEL_GPIO);
@@ -433,19 +428,34 @@ err_gpio_tvout_sel:
return err;
}
-static void __exit rx51_soc_exit(void)
+static int rx51_soc_remove(struct platform_device *pdev)
{
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+
snd_soc_jack_free_gpios(rx51_av_jack, ARRAY_SIZE(rx51_av_jack_gpios),
rx51_av_jack_gpios);
- platform_device_unregister(rx51_snd_device);
+ snd_soc_unregister_card(card);
+ card-dev = NULL;
+
gpio_free(RX51_ECI_SW_GPIO);
gpio_free(RX51_TVOUT_SEL_GPIO);
+
+ return 0;
}
-module_init(rx51_soc_init);
-module_exit(rx51_soc_exit);
+static struct platform_driver rx51_soc_driver = {
+ .driver = {
+ .name = rx51-audio,
+ .owner = THIS_MODULE,
+ },
+ .probe = rx51_soc_probe,
+ .remove = rx51_soc_remove,
+};
+
+module_platform_driver(rx51_soc_driver);
MODULE_AUTHOR(Nokia Corporation);
MODULE_DESCRIPTION(ALSA SoC Nokia RX-51);
MODULE_LICENSE(GPL);
+MODULE_ALIAS(platform:rx51-audio);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] ARM: OMAP2+: AM33XX: Misc fixes/updates
V == Bedia, Vaibhav vaibhav.be...@ti.com writes: Hi, Vaibhav Bedia (9): ARM: OMAP2+: AM33XX: CM: Get rid of unncessary header inclusions ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags ARM: OMAP2+: AM33XX: hwmod: Fixup cpgmac0 hwmod entry ARM: OMAP2+: AM33XX: hwmod: Update the WKUP-M3 hwmod with reset status bit ARM: OMAP2+: AM33XX: Update the hardreset API ARM: DTS: AM33XX: Add nodes for OCMC RAM and WKUP-M3 ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs V Any comments on these before I resend addressing the comments from Sergei? Wouldn't the ocmram/wkup dt nodes need a reg property to define their size as I indirectly mentioned here: http://thread.gmane.org/gmane.linux.ports.arm.omap/91405/focus=92061 -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fix audio on Nokia RX-51
Hi, On 01/20/2013 04:04 AM, Pali Rohár wrote: This patch series updating rx51 sound driver, using snd_soc_register_card, adding module alias for autoloading kernel driver and registring sound driver in rx51 board code. Pali Rohár (2): ASoC: omap: rx51: Use snd_soc_register_card and add module alias for autoloading driver ARM: OMAP: rx51: Register audio device Can you reverse the order of the patches so we will avoid to have non working audio between the two patch? arch/arm/mach-omap2/board-rx51-peripherals.c | 11 ++ sound/soc/omap/rx51.c| 50 +++--- 2 files changed, 41 insertions(+), 20 deletions(-) -- 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
[PATCH] usb: musb: fix context save over suspend.
The standard suspend sequence involves runtime_resuming devices before suspending the system. So just saving context in runtime_suspend and restoring it in runtime resume isn't enough. We must also save in suspend and restore in resume. Without this patch, and OMAP3 system with off_mode enabled will find the musb port non-functional after suspend/resume. With the patch it works perfectly. Signed-off-by: NeilBrown ne...@suse.de diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index fd34867..b6ccc02 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev) } spin_unlock_irqrestore(musb-lock, flags); + musb_save_context(musb); return 0; } @@ -2234,6 +2235,8 @@ static int musb_resume_noirq(struct device *dev) * unless for some reason the whole soc powered down or the USB * module got reset through the PSC (vs just being disabled). */ + struct musb *musb = dev_to_musb(dev); + musb_restore_context(musb); return 0; } signature.asc Description: PGP signature
Re: [PATCH 0/5] staging: tidspbridge: for 3.9
On Mon, Jan 21, 2013 at 10:25:24AM +0300, Dan Carpenter wrote: On Thu, Jan 17, 2013 at 04:47:46PM -0800, Greg Kroah-Hartman wrote: On Thu, Jan 10, 2013 at 03:36:57AM -0600, Omar Ramirez Luna wrote: Patches for staging-next, fixing comments and suggestions provided by Chen Gang. There is an additional scm patch, that removes hardcoded defines related to direct register handling for SCM, it was dependent on changes that already made it to mainline. What is the status on getting this out of the staging tree? What needs to be done still? Why can't tidspbridge be built as a module? The Kconfig help files aren't very informative. Huh. Ignore me. I don't know what I was looking at before. Both the things I said were wrong. Sorry for the noise. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/9] ARM: OMAP2+: AM33XX: Misc fixes/updates
Hi Peter, On Mon, Jan 21, 2013 at 14:33:20, Peter Korsgaard wrote: V == Bedia, Vaibhav vaibhav.be...@ti.com writes: Hi, Vaibhav Bedia (9): ARM: OMAP2+: AM33XX: CM: Get rid of unncessary header inclusions ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags ARM: OMAP2+: AM33XX: hwmod: Fixup cpgmac0 hwmod entry ARM: OMAP2+: AM33XX: hwmod: Update the WKUP-M3 hwmod with reset status bit ARM: OMAP2+: AM33XX: Update the hardreset API ARM: DTS: AM33XX: Add nodes for OCMC RAM and WKUP-M3 ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs V Any comments on these before I resend addressing the comments from Sergei? Wouldn't the ocmram/wkup dt nodes need a reg property to define their size as I indirectly mentioned here: http://thread.gmane.org/gmane.linux.ports.arm.omap/91405/focus=92061 My apologies. I missed your comment on that patch and just responded to it. Will add the reg property for the DT nodes in the next version. Regards, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC v2 16/18] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Peter,
On Thu, Jan 17, 2013 at 19:57:20, Peter Korsgaard wrote:
V == Vaibhav Bedia vaibhav.be...@ti.com writes:
Hi,
V +static void am33xx_pm_firmware_cb(const struct firmware *fw, void
*context)
V +{
V + struct wkup_m3_context *wkup_m3_context = context;
V + struct platform_device *pdev = to_platform_device(wkup_m3_context-dev);
V + int ret = 0;
V +
V + /* no firmware found */
V + if (!fw) {
V + dev_err(wkup_m3_context-dev, request_firmware failed\n);
V + goto err;
V + }
V +
V + memcpy((void *)wkup_m3_context-code, fw-data, fw-size);
A size check would be good. I don't know much about the finer details
about the m3 and how it is connected, but don't you need to ensure data
is flushed before resetting the m3?
Will add the reg property in the next version. The wkup-m3 memory is coming via
ioremap() so AFAIK it should be ok. I realized that I do need to replace the
memcpy()
with memcpy_toio() here.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] OF: Introduce Device Tree resolve support.
Hi David
On Jan 21, 2013, at 6:48 AM, David Gibson wrote:
On Fri, Jan 04, 2013 at 09:31:09PM +0200, Pantelis Antoniou wrote:
Introduce support for dynamic device tree resolution.
Using it, it is possible to prepare a device tree that's
been loaded on runtime to be modified and inserted at the kernel
live tree.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
.../devicetree/dynamic-resolution-notes.txt| 25 ++
drivers/of/Kconfig | 9 +
drivers/of/Makefile| 1 +
drivers/of/resolver.c | 394
+
include/linux/of.h | 17 +
5 files changed, 446 insertions(+)
create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt
create mode 100644 drivers/of/resolver.c
diff --git a/Documentation/devicetree/dynamic-resolution-notes.txt
b/Documentation/devicetree/dynamic-resolution-notes.txt
new file mode 100644
index 000..0b396c4
--- /dev/null
+++ b/Documentation/devicetree/dynamic-resolution-notes.txt
@@ -0,0 +1,25 @@
+Device Tree Dynamic Resolver Notes
+--
+
+This document describes the implementation of the in-kernel
+Device Tree resolver, residing in drivers/of/resolver.c and is a
+companion document to Documentation/devicetree/dt-object-internal.txt[1]
+
+How the resolver works
+--
+
+The resolver is given as an input an arbitrary tree compiled with the
+proper dtc option and having a /plugin/ tag. This generates the
+appropriate __fixups__ __local_fixups__ nodes as described in [1].
+
+In sequence the resolver works by the following steps:
+
+1. Get the maximum device tree phandle value from the live tree + 1.
+2. Adjust all the local phandles of the tree to resolve by that amount.
+3. Using the __local__fixups__ node information adjust all local references
+ by the same amount.
+4. For each property in the __fixups__ node locate the node it references
+ in the live tree. This is the label used to tag the node.
+5. Retrieve the phandle of the target of the fixup.
+5. For each fixup in the property locate the node:property:offset location
+ and replace it with the phandle value.
Hrm. So, I'm really still not convinced by this approach.
First, I think it's unwise to allow overlays to change
essentially anything in the base tree, rather than having the base
tree define sockets of some sort where things can be attached.
One could say that the labels define the sockets. It's not just things
to be attached, properties might have to change, or something more complex,
as we've found out in practice.
As far as the unwise part, a good deal of care has been taken so that
people that don't use the overlay functionality have absolutely no
overhead, or anything modified in the way they use DT.
Second, even allowing overlays to change anything, I don't see
a lot of reason to do this kind of resolution within the kernel and
with data stored in the dtb itself, rather than doing the resolution
in userspace from an annotated overlay dts or dtb, then inserting the
fully resolved product into the kernel. In either case, the overlay
needs to be constructed with pretty intimate knowledge of the base
tree.
Fair enough, but that's one more thing of user-space crud to drag along, which
will get enabled pretty late in the boot sequence. Meaning a whole bunch of
devices,
like consoles, and root filesystems on the devices that need an overlay to
operate
won't work easily enough.
That said, I have some implementation comments below.
[snip]
+/**
+ * Find a subtree's maximum phandle value.
+ */
+static phandle __of_get_tree_max_phandle(struct device_node *node,
+phandle max_phandle)
+{
+struct device_node *child;
+
+if (node-phandle != 0 node-phandle != OF_PHANDLE_ILLEGAL
+node-phandle max_phandle)
+max_phandle = node-phandle;
+
+__for_each_child_of_node(node, child)
+max_phandle = __of_get_tree_max_phandle(child, max_phandle);
Recursion is best avoided given the kernel's limited stack space.
This is also trivial to implement non-recursively, using the allnext
pointer.
The caller passes a tree that's not yet been inserted in the live tree.
So there's no allnodes pointer yet. Care has been taken for the function
to not have excessive local variables. I would guess about 20-32 bytes for
the stack frame + the local variables, so with a 4K stack we would overflow at
a
nest level of 128, which has a pretty slim chance for a real system.
+
+return max_phandle;
+}
+
+/**
+ * Find live tree's maximum phandle value.
+ */
+static phandle of_get_tree_max_phandle(void)
+{
+struct device_node *node;
+phandle phandle;
+
+/* get root node */
+node = of_find_node_by_path(/);
+if (node ==
[PATCH] OMAP: omap4-panda: add UART2 muxing for WiLink shared transport
Add the UART2 muxing data to the board file (this used to be,
erroneously, done in the bootloader).
Cc: stable sta...@vger.kernel.org [3.7]
Signed-off-by: Luciano Coelho coe...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 5c8e9ce..769c1fe 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -397,6 +397,12 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP_PULL_ENA),
OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ /* UART2 - BT/FM/GPS shared transport */
+ OMAP4_MUX(UART2_CTS,OMAP_PIN_INPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_RTS,OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_RX, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_TX, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
--
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
Re: [PATCH] usb: musb: fix context save over suspend.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Neil, On 01/21/13 11:28, NeilBrown wrote: The standard suspend sequence involves runtime_resuming devices before suspending the system. So just saving context in runtime_suspend and restoring it in runtime resume isn't enough. We must also save in suspend and restore in resume. Without this patch, and OMAP3 system with off_mode enabled will find the musb port non-functional after suspend/resume. With the patch it works perfectly. Hmmm... Some time ago, this has been removed in 5d193ce8 (usb: musb: PM: fix context save/restore in suspend/resume path) Am I missing something? Or things changed and now this patch is correct? Signed-off-by: NeilBrown ne...@suse.de diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c index fd34867..b6ccc02 100644 --- a/drivers/usb/musb/musb_core.c +++ b/drivers/usb/musb/musb_core.c @@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev) } spin_unlock_irqrestore(musb-lock, flags); + musb_save_context(musb); return 0; } @@ -2234,6 +2235,8 @@ static int musb_resume_noirq(struct device *dev) * unless for some reason the whole soc powered down or the USB * module got reset through the PSC (vs just being disabled). */ + struct musb *musb = dev_to_musb(dev); + musb_restore_context(musb); return 0; } - -- Regards, Igor. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQ/SjTAAoJEBDE8YO64EfaHrsP/2bl4rP6L/tWLSZ+rNEdz6B+ Qo+HVOhnTVsOxgWbbd5VrfhE28jLoFGMslrLuI+geeCcJ1zgwNsahG9C11bygyfu 54hQgkmaxDJPDKAlalcy7VK9C6tOTgQV5iSbuRlemttK879dTrb+33zP6idn5+zK kxptY38fpmyojnl8gJiVa6Plik/apQcVr+GIx8CMwj+YQC5vkdg7cUEWyngfyk2C W0U4NceroS8NSjRbcFV3V6Q912TVjKzl+B2yxVD0OBaSK4BpHEncDBXiVx8APq87 4nDeBB5gDXi1rtN3YjcfDaFu0me5qzpYc3JFFidvdLTdXIdvxDzjHgMqsZB8ZBYC R0e5PtIw/62I90d63JkXZXVRTB7JeZsGfZFY2R7MxBab9or8zz0OyYwGWoW63vzH oFrwmAkWoD0IEKcfc8+dd99eicgZrmQL6FDWrEMsX+RS34LRtVU30SVAudRhY+CR MhNCjKyFySwx7wqkGgJl1ECl0Y6U4ua0v4bv7kdE6eyrgbQIkiGliSJ7DhWBPcP6 iMIOTwC7+LwPYP/MX2uYR3DXDfI0XwiqdtyzhD9LJe4PRol8zjozS2j0Y7FriItw jFqsgCgwDc9j8ufcpXf5ZynJYnlCG0iLuAPEUugZot83/CpxgU++A8cuHqUrOnhH 76L95rflUTkpiQ76ffP7 =jqXb -END PGP SIGNATURE- -- 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 13/15] drivers/usb/musb/omap2430.c: adjust duplicate test
From: Julia Lawall julia.law...@lip6.fr
Delete successive tests to the same location. Data is the just previously
allocated and tested value. Test the result of the allocation made here
instead.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@s exists@
local idexpression y;
expression x,e;
@@
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
... when != \(y = e\|y += e\|y -= e\|y |= e\|y = e\|y++\|y--\|y\)
when != \(XT_GETPAGE(...,y)\|WMI_CMD_BUF(...)\)
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
The previous code could be further simplified by removing the
initializations of ret to -ENOMEM, as is absent in this case. But that is
probably for another patch.
drivers/usb/musb/omap2430.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index da00af4..533c4fd 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -545,7 +545,7 @@ static int omap2430_probe(struct platform_device *pdev)
}
config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
- if (!data) {
+ if (!config) {
dev_err(pdev-dev,
failed to allocate musb hdrc config\n);
goto err2;
--
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 13/15] drivers/usb/musb/omap2430.c: adjust duplicate test
Hi,
On Mon, Jan 21, 2013 at 02:02:57PM +0100, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Delete successive tests to the same location. Data is the just previously
allocated and tested value. Test the result of the allocation made here
instead.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@s exists@
local idexpression y;
expression x,e;
@@
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
... when != \(y = e\|y += e\|y -= e\|y |= e\|y = e\|y++\|y--\|y\)
when != \(XT_GETPAGE(...,y)\|WMI_CMD_BUF(...)\)
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
Already in my tree ;-)
commit b37457d80bc3e2a6bb86a6036c572574614a7631
Author: Sergei Shtylyov sshtyl...@ru.mvista.com
Date: Tue Jan 8 22:11:14 2013 +0300
usb: musb: omap2430: fix wrong devm_kzalloc() result check
Commit 00a0b1d58af873d842580dcac55f3b156c3a4077 (usb: musb: omap: Add device
tree support for omap musb glue) assigns result of devm_kzalloc() call to
the 'config' variable but then checks for NULL the 'data' variable (already
checked after previous call). Thus we risk a kernel oops further when data
pointed by 'config' is written to by subsequent of_property_read_u32() calls
iff the allocation happens to fail...
Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index b15bb05..bb48796 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -543,7 +543,7 @@ static int omap2430_probe(struct platform_device *pdev)
}
config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
- if (!data) {
+ if (!config) {
dev_err(pdev-dev,
failed to allocate musb hdrc config\n);
goto err2;
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
[...]
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 01ce462..f7de9eb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -39,6 +39,7 @@
#include omap_device.h
#include gpmc.h
#include gpmc-nand.h
+#include gpmc-onenand.h
#define DEVICE_NAME omap-gpmc
@@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct
platform_device *pdev,
}
#endif
+#ifdef CONFIG_MTD_ONENAND
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ u32 val;
+ struct omap_onenand_platform_data *gpmc_onenand_data;
+
+ if (of_property_read_u32(child, reg, val) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ gpmc_onenand_data = devm_kzalloc(pdev-dev, sizeof(*gpmc_onenand_data),
+ GFP_KERNEL);
+ if (!gpmc_onenand_data)
+ return -ENOMEM;
+
+ gpmc_onenand_data-cs = val;
+ gpmc_onenand_data-of_node = child;
+ gpmc_onenand_data-dma_channel = -1;
+
+ if (!of_property_read_u32(child, dma-channel, val))
+ gpmc_onenand_data-dma_channel = val;
+
+ gpmc_onenand_init(gpmc_onenand_data);
+
+ return 0;
+}
+#else
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ return 0;
+}
+#endif
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
This doesn't look right to me:
+ for_each_node_by_name(child, onenand) {
+ ret = gpmc_probe_onenand_child(pdev, child);
+ of_node_put(child);
+ if (ret 0)
+ return ret;
+ }
for_each_node_by_name automatically calls of_node_put on each node once passed,
and as far as I can tell, gpmc_probe_onenand_child doesn't do anything that'd
increment a node's refcount.
As far as I can see, you only need the of_node_put in the error case:
for_each_node_by_name(child, onenand) {
ret = gpmc_probe_onenand_child(pdev, child);
if (ret 0) {
of_node_put(child);
return ret;
}
}
Have I missed something here?
return 0;
}
#else
--
1.7.8.6
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OPP usage fixes for RCU locking
On Monday, January 21, 2013 02:45:32 PM MyungJoo Ham wrote: On Sat, Jan 19, 2013 at 7:28 AM, Rafael J. Wysocki r...@sisk.pl wrote: On Friday, January 18, 2013 01:52:31 PM Nishanth Menon wrote: Hi, Despite being documented in function documentation and in Documentation/power/opp.txt, many of the users of OPP APIs dont honor RCU lock usage appropriately. This recently appeared in IRC discussion earlier today [1]. I did an audit of current usage and the following series is a result of this. NOTE: 1. The patch PM / devfreq: exynos4_bus: honor RCU lock usage has only been build tested as I dont have an exynos platform to try it on. I have tried to make it as least intrusive as possible and at least reviewed to ensure I haven't screwed anything up. Other than this, I have added appropriate tested by information in requisite patches. Thanks for the fixes. MyungJoo, do you want me to take the devfreq ones too? Rafael Yes, please take RCU-OPP patches. Having those patches splitted doesn't seem beneficial. OK, I will take them. I'll let other devfreq patches be based on this after you get them applied. OK Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: mach-omap2: apply the errata at run time rather
Signed-off-by: srinidhi kasagar srinidhi.kasa...@stericsson.com --- arch/arm/mach-omap2/sleep44xx.S | 25 + 1 files changed, 21 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S index 88ff83a..071ca1f 100644 --- a/arch/arm/mach-omap2/sleep44xx.S +++ b/arch/arm/mach-omap2/sleep44xx.S @@ -157,11 +157,19 @@ skip_scu_gp_set: ldrne r0, [r8, #L2X0_SAVE_OFFSET1]@ memory. cmp r0, #3 bne do_WFI -#ifdef CONFIG_PL310_ERRATA_727915 + /* Check for PL310_ERRATA_727915 */ + bl l2x0_get_rtl_release + cmp r0, #0x4 + beq dosmc + cmp r0, #0x5 + beq dosmc + b nosmc +dosmc: mov r0, #0x03 mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX DO_SMC -#endif + +nosmc: bl omap4_get_l2cache_base mov r2, r0 ldr r0, =0x @@ -171,11 +179,20 @@ wait: ldr r1, =0x andsr0, r0, r1 bne wait -#ifdef CONFIG_PL310_ERRATA_727915 + + /* Check for PL310_ERRATA_727915 */ + bl l2x0_get_rtl_release + cmp r0, #0x4 + beq dosmc2 + cmp r0, #0x5 + beq dosmc2 + b nosmc2 +dosmc2: mov r0, #0x00 mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX DO_SMC -#endif + +nosmc2: l2x_sync: bl omap4_get_l2cache_base mov r2, r0 -- 1.7.2.dirty -- 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 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
The OMAP glue has been modified to get PHY by phandle for dt boot.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 3628a50..08709cf 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -346,7 +346,12 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- musb-xceiv = devm_usb_get_phy(dev, 0);
+ if (dev-parent-of_node)
+ musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent,
+ usb_phy, 0);
Why dev-parent and not just dev?
+ else
+ musb-xceiv = devm_usb_get_phy(dev, 0);
+
if (IS_ERR_OR_NULL(musb-xceiv)) {
pr_err(HS USB OTG: no transceiver configured\n);
return -ENODEV;
--
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/6] usb: otg: add device tree support to otg library
On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a
device node phandle value. This function will return a pointer to
the phy on success, -EPROBE_DEFER if there is a device_node for the phandle,
but the phy has not been added, or a ERR_PTR() otherwise.
Cc: Marc Kleine-Budde m...@pengutronix.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/otg.c | 77
+++
include/linux/usb/phy.h |8 +
2 files changed, 85 insertions(+)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index dbf2043..e9799bb 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -13,7 +13,9 @@
#include linux/export.h
#include linux/err.h
#include linux/device.h
+#include linux/module.h
#include linux/slab.h
+#include linux/of.h
#include linux/usb/otg.h
@@ -34,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct device *dev,
u8 index)
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__of_usb_find_phy(struct device_node *node)
+{
+ struct usb_phy *phy;
+
+ list_for_each_entry(phy, phy_list, head) {
+ if (node != phy-dev-of_node)
+ continue;
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static void devm_usb_phy_release(struct device *dev, void *res)
{
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -109,6 +125,67 @@ err0:
}
EXPORT_SYMBOL(usb_get_phy);
+ /**
+ * devm_usb_get_phy_by_phandle - find the USB PHY by phandle
+ * @dev - device that requests this phy
+ * @phandle - name of the property holding the phy phandle value
+ * @index - the index of the phy
+ *
+ * Returns the phy driver associated with the given phandle value,
+ * after getting a refcount to it, -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. While at that, it also associates the device with
+ * the phy using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+ const char *phandle, u8 index)
+{
+ struct usb_phy *phy = NULL, **ptr;
+ unsigned long flags;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, phandle, index);
+ if (!node) {
+ dev_dbg(dev, failed to get %s phandle in %s node\n, phandle,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr) {
+ dev_dbg(dev, failed to allocate memory for devres\n);
+ return ERR_PTR(-ENOMEM);
+ }
I fail to understand why you need ptr at all and why do devres_alloc()
for it.
+
+ spin_lock_irqsave(phy_lock, flags);
+
+ phy = __of_usb_find_phy(node);
+ if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
+ phy = ERR_PTR(-EPROBE_DEFER);
+ devres_free(ptr);
+ goto err0;
+ }
+
+ *ptr = phy;
+ devres_add(dev, ptr);
+
+ get_device(phy-dev);
+
+err0:
+ spin_unlock_irqrestore(phy_lock, flags);
+
+ return phy;
+}
+EXPORT_SYMBOL(devm_usb_get_phy_by_phandle);
+
--
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: board-zoom: Do not request LCD panel enable GPIO from twl4030
The pin in question is muxed between GPIO7 and PWM1. For backlight control
there is a custom code in board-zoom-display to control the backlight.
No need to request the GPIO7 - which was failing since the way it is
requested no longer valid: twl's gpio range is allocated dynamically.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Tony,
This patch is generated on top of my previous series for audio/pwm support:
http://www.spinics.net/lists/linux-omap/msg85085.html
Regards,
Peter
arch/arm/mach-omap2/board-zoom-peripherals.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index f4ea926..0745bd9 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -38,8 +38,6 @@
#define OMAP_ZOOM_TSC2004_IRQ_GPIO (153)
#define OMAP_ZOOM_WLAN_IRQ_GPIO(162)
-#define LCD_PANEL_ENABLE_GPIO (7 + OMAP_MAX_GPIO_LINES)
-
/* Zoom2 has Qwerty keyboard*/
static uint32_t board_keymap[] = {
KEY(0, 0, KEY_E),
@@ -243,23 +241,15 @@ static struct omap_tw4030_pdata omap_twl4030_audio_data =
{
static int zoom_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- int ret;
-
/* gpio + 0 is mmc0_cd (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
omap_hsmmc_late_init(mmc);
- ret = gpio_request_one(LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW,
- lcd enable);
- if (ret)
- pr_err(Failed to get LCD_PANEL_ENABLE_GPIO (gpio%d).\n,
- LCD_PANEL_ENABLE_GPIO);
-
/* Audio setup */
omap_twl4030_audio_data.jack_detect = gpio + 2;
omap_twl4030_audio_init(Zoom2, omap_twl4030_audio_data);
- return ret;
+ return 0;
}
static struct twl4030_gpio_platform_data zoom_gpio_data = {
--
1.8.1.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP3 ISP: Simplify clock usage
Hi Mike, On Monday 14 January 2013 17:10:15 Mike Turquette wrote: Quoting Laurent Pinchart (2013-01-08 05:43:52) Hello, Now that the OMAP3 supports the common clock framework, clock rate back-propagation is available for the ISP clocks. Instead of setting the cam_mclk parent clock rate to control the cam_mclk clock rate, we can mark the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting back-propagation, and set the cam_mclk rate directly. This simplifies the ISP clocks configuration. I'm pleased to see this feature get used on OMAP. Plus your driver gets a negative diffstat :) Reviewed-by: Mike Turquette mturque...@linaro.org Thanks. Would you like to take the arch/ patch in your tree, or should I push it through the linux-media tree along with the omap3isp patch ? Laurent Pinchart (2): ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5 omap3isp: Set cam_mclk rate directly arch/arm/mach-omap2/cclock3xxx_data.c | 10 +- drivers/media/platform/omap3isp/isp.c | 18 ++ drivers/media/platform/omap3isp/isp.h |8 +++- 3 files changed, 14 insertions(+), 22 deletions(-) -- Regards, Laurent Pinchart -- 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 5/6] usb: otg: add device tree support to otg library
On Monday 21 January 2013 06:51 PM, Roger Quadros wrote:
On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a
device node phandle value. This function will return a pointer to
the phy on success, -EPROBE_DEFER if there is a device_node for the phandle,
but the phy has not been added, or a ERR_PTR() otherwise.
Cc: Marc Kleine-Budde m...@pengutronix.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/otg.c | 77 +++
include/linux/usb/phy.h |8 +
2 files changed, 85 insertions(+)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index dbf2043..e9799bb 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -13,7 +13,9 @@
#include linux/export.h
#include linux/err.h
#include linux/device.h
+#include linux/module.h
#include linux/slab.h
+#include linux/of.h
#include linux/usb/otg.h
@@ -34,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct device *dev, u8
index)
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__of_usb_find_phy(struct device_node *node)
+{
+ struct usb_phy *phy;
+
+ list_for_each_entry(phy, phy_list, head) {
+ if (node != phy-dev-of_node)
+ continue;
+
+ return phy;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+
static void devm_usb_phy_release(struct device *dev, void *res)
{
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -109,6 +125,67 @@ err0:
}
EXPORT_SYMBOL(usb_get_phy);
+ /**
+ * devm_usb_get_phy_by_phandle - find the USB PHY by phandle
+ * @dev - device that requests this phy
+ * @phandle - name of the property holding the phy phandle value
+ * @index - the index of the phy
+ *
+ * Returns the phy driver associated with the given phandle value,
+ * after getting a refcount to it, -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. While at that, it also associates the device with
+ * the phy using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+ const char *phandle, u8 index)
+{
+ struct usb_phy *phy = NULL, **ptr;
+ unsigned long flags;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, phandle, index);
+ if (!node) {
+ dev_dbg(dev, failed to get %s phandle in %s node\n, phandle,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr) {
+ dev_dbg(dev, failed to allocate memory for devres\n);
+ return ERR_PTR(-ENOMEM);
+ }
I fail to understand why you need ptr at all and why do devres_alloc()
for it.
Thats how we create a managed device resource. You can have a look at
Documentation/driver-model/devres.txt and drivers/base/devres.c.
I'm not sure if that is what you are looking for :-P
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: [RFC PATCH 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
Hi, On Monday 21 January 2013 06:48 PM, Roger Quadros wrote: On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote: The OMAP glue has been modified to get PHY by phandle for dt boot. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- drivers/usb/musb/omap2430.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 3628a50..08709cf 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -346,7 +346,12 @@ static int omap2430_musb_init(struct musb *musb) * up through ULPI. TWL4030-family PMICs include one, * which needs a driver, drivers aren't always needed. */ - musb-xceiv = devm_usb_get_phy(dev, 0); + if (dev-parent-of_node) + musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent, + usb_phy, 0); Why dev-parent and not just dev? Right now MUSB core is not converted to dt and hence we don't have separate dt node for MUSB core. So the PHY information is added to the glue dt data. 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
[PATCH] usb: phy: samsung: Remove __devinit, __devexit_p and __exit annotations
Dropping __devinit, __devexit_p, __exit annotations since they are
nop and no longer supported.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/phy/samsung-usbphy.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
index 30aebb5..6b30809 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -343,7 +343,7 @@ static inline const struct samsung_usbphy_drvdata
platform_get_device_id(pdev)-driver_data;
}
-static int __devinit samsung_usbphy_probe(struct platform_device *pdev)
+static int samsung_usbphy_probe(struct platform_device *pdev)
{
struct samsung_usbphy *sphy;
struct samsung_usbphy_data *pdata = pdev-dev.platform_data;
@@ -405,7 +405,7 @@ static int __devinit samsung_usbphy_probe(struct
platform_device *pdev)
return usb_add_phy(sphy-phy, USB_PHY_TYPE_USB2);
}
-static int __exit samsung_usbphy_remove(struct platform_device *pdev)
+static int samsung_usbphy_remove(struct platform_device *pdev)
{
struct samsung_usbphy *sphy = platform_get_drvdata(pdev);
@@ -456,7 +456,7 @@ MODULE_DEVICE_TABLE(platform, samsung_usbphy_driver_ids);
static struct platform_driver samsung_usbphy_driver = {
.probe = samsung_usbphy_probe,
- .remove = __devexit_p(samsung_usbphy_remove),
+ .remove = samsung_usbphy_remove,
.id_table = samsung_usbphy_driver_ids,
.driver = {
.name = samsung-usbphy,
--
1.7.6.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 3/4] ARM: OMAP2: MUSB: Specify omap4 has mailbox
Added has_mailbox to the musb platform data to specify that omap uses
an external mailbox (in control module) to communicate with the musb
core during device connect and disconnect.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |3 +++
include/linux/usb/musb.h |2 ++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 7b33b37..9d27e3f 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,6 +85,9 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
+ if (cpu_is_omap44xx())
+ musb_plat.has_mailbox = true;
+
if (soc_is_am35xx()) {
oh_name = am35x_otg_hs;
name = musb-am35x;
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..053c268 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,8 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8 mode;
+ u8 has_mailbox:1;
+
/* for clk_get() */
const char *clock;
--
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/4] usb: musb: add driver for control module
Added a new driver for the usb part of control module. This has an API to power on the USB2 phy and an API to write to the mailbox depending on whether MUSB has to act in host mode or in device mode. Writing to control module registers for doing the above task which was previously done in omap glue and in omap-usb2 phy is removed. Changes from v1: * renamed get_omap_control_dev to omap_get_control_dev * created and exported a single API (omap_control_usb_set_mode) to change the usb mode * Before writing to the otghs_control regster, the value from otghs_control regster is read and only the appropriate bits are set. * In omap_init_control_usb, the indentation is now reduced as per Felipe's suggestion. Changes from RFC: * Used #if IS_ENABLED(CONFIG_OMAP_CONTROL_USB) instead of #if (defined(CONFIG_OMAP_CONTROL_USB) || \ defined(CONFIG_OMAP_CONTROL_USB_MODULE)) * return -EADDRNOTAVAIL if devm_request_and_ioremap fails. * Removed the dt data from this patch series (I'll send that as a separate series). * added ctrl_module binding to usb otg glue and usb phy in the Documentaion. This binding is not planned to be used until an actual requirement for it arises. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv Did basic enumeration testing in omap4 panda and omap3 beagle. Kishon Vijay Abraham I (4): drivers: usb: phy: add a new driver for usb part of control module ARM: OMAP: devices: create device for usb part of control module ARM: OMAP2: MUSB: Specify omap4 has mailbox drivers: usb: start using the control module driver Documentation/devicetree/bindings/usb/omap-usb.txt | 30 ++- Documentation/devicetree/bindings/usb/usb-phy.txt | 12 +- arch/arm/mach-omap2/devices.c | 45 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 -- arch/arm/mach-omap2/usb-musb.c |3 + drivers/usb/musb/Kconfig |1 + drivers/usb/musb/omap2430.c| 64 ++ drivers/usb/musb/omap2430.h|9 - drivers/usb/phy/Kconfig| 10 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-control-usb.c | 238 drivers/usb/phy/omap-usb2.c| 38 +--- include/linux/usb/musb.h |2 + include/linux/usb/omap_control_usb.h | 71 ++ include/linux/usb/omap_usb.h |4 +- 15 files changed, 439 insertions(+), 102 deletions(-) create mode 100644 drivers/usb/phy/omap-control-usb.c create mode 100644 include/linux/usb/omap_control_usb.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 2/4] ARM: OMAP: devices: create device for usb part of control module
A seperate driver has been added to handle the usb part of control
module. A device for the above driver is created here, using the register
address information to be used by the driver for powering on the PHY and
for writing to the mailbox.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/devices.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 5e304d0..edc5ec2 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -20,6 +20,7 @@
#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
#include linux/platform_data/omap_ocp2scp.h
+#include linux/usb/omap_control_usb.h
#include asm/mach-types.h
#include asm/mach/map.h
@@ -254,6 +255,49 @@ static inline void omap_init_camera(void)
#endif
}
+#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
+static struct omap_control_usb_platform_data omap4_control_usb_pdata = {
+ .has_mailbox = true,
+};
+
+struct resource omap4_control_usb_res[] = {
+ {
+ .name = control_dev_conf,
+ .start = 0x4a002300,
+ .end= 0x4a002303,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = otghs_control,
+ .start = 0x4a00233c,
+ .end= 0x4a00233f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device omap4_control_usb = {
+ .name = omap-control-usb,
+ .id = -1,
+ .dev = {
+ .platform_data = omap4_control_usb_pdata,
+ },
+ .num_resources = 2,
+ .resource = omap4_control_usb_res,
+};
+
+static inline void __init omap_init_control_usb(void)
+{
+ if (!cpu_is_omap44xx())
+ return;
+
+ if (platform_device_register(omap4_control_usb))
+ pr_err(Error registering omap_control_usb device\n);
+}
+
+#else
+static inline void omap_init_control_usb(void) { }
+#endif /* CONFIG_OMAP_CONTROL_USB */
+
int __init omap4_keyboard_init(struct omap4_keypad_platform_data
*sdp4430_keypad_data, struct omap_board_data *bdata)
{
@@ -721,6 +765,7 @@ static int __init omap2_init_devices(void)
omap_init_mbox();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
+ omap_init_control_usb();
omap_init_dmic();
omap_init_mcpdm();
omap_init_mcspi();
--
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/4] drivers: usb: start using the control module driver
Start using the control module driver for powering on the PHY and for
writing to the mailbox instead of writing to the control module
registers on their own.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt |4 ++
Documentation/devicetree/bindings/usb/usb-phy.txt |7 +--
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13
drivers/usb/musb/Kconfig |1 +
drivers/usb/musb/omap2430.c| 64 +++-
drivers/usb/musb/omap2430.h|9 ---
drivers/usb/phy/Kconfig|1 +
drivers/usb/phy/omap-usb2.c| 38 +++-
include/linux/usb/omap_usb.h |4 +-
9 files changed, 40 insertions(+), 101 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index ead6ba9..8bedbba 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -3,6 +3,9 @@ OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
OMAP MUSB GLUE
- compatible : Should be ti,omap4-musb or ti,omap3-musb
- ti,hwmods : must be usb_otg_hs
+ - ti,has_mailbox : to specify that omap uses an external mailbox
+ (in control module) to communicate with the musb core during device connect
+ and disconnect.
- multipoint : Should be 1 indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
- num_eps : Specifies the number of endpoints. This is also a
@@ -24,6 +27,7 @@ SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = ti,omap4-musb;
ti,hwmods = usb_otg_hs;
+ ti,has_mailbox;
multipoint = 1;
num_eps = 16;
ram_bits = 12;
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 2466b6f..48761a2 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -4,9 +4,7 @@ OMAP USB2 PHY
Required properties:
- compatible: Should be ti,omap-usb2
- - reg : Address and length of the register set for the device. Also
-add the address of control module dev conf register until a driver for
-control module is added
+ - reg : Address and length of the register set for the device.
Optional properties:
- ctrl_module : phandle of the control module used by PHY driver to power on
@@ -16,7 +14,6 @@ This is usually a subnode of ocp2scp to which it is connected.
usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
- reg = 0x4a0ad080 0x58,
- 0x4a002300 0x4;
+ reg = 0x4a0ad080 0x58;
ctrl_module = omap_control_usb;
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 129d508..103f4ba 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2698,13 +2698,6 @@ static struct resource omap44xx_usb_phy_and_pll_addrs[]
= {
.end= 0x4a0ae000,
.flags = IORESOURCE_MEM,
},
- {
- /* XXX: Remove this once control module driver is in place */
- .name = ctrl_dev,
- .start = 0x4a002300,
- .end= 0x4a002303,
- .flags = IORESOURCE_MEM,
- },
{ }
};
@@ -6152,12 +6145,6 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab7ff,
.flags = ADDR_TYPE_RT
},
- {
- /* XXX: Remove this once control module driver is in place */
- .pa_start = 0x4a00233c,
- .pa_end = 0x4a00233f,
- .flags = ADDR_TYPE_RT
- },
{ }
};
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 23a0b7f..de6e5ce 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -11,6 +11,7 @@ config USB_MUSB_HDRC
select NOP_USB_XCEIV if (SOC_TI81XX || SOC_AM33XX)
select TWL4030_USB if MACH_OMAP_3430SDP
select TWL6030_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA
+ select OMAP_CONTROL_USB if MACH_OMAP_4430SDP || MACH_OMAP4_PANDA
select USB_OTG_UTILS
help
Say Y here if your system has a dual role high speed USB
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index da00af4..bf6cfe0 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -37,6 +37,7 @@
#include linux/err.h
#include linux/delay.h
#include linux/usb/musb-omap.h
+#include linux/usb/omap_control_usb.h
#include musb_core.h
#include omap2430.h
@@ -46,7 +47,7 @@ struct omap2430_glue {
struct
[PATCH v2 1/4] drivers: usb: phy: add a new driver for usb part of control module
Added a new driver for the usb part of control module. This has an API
to power on the USB2 phy and an API to write to the mailbox depending on
whether MUSB has to act in host mode or in device mode.
Writing to control module registers for doing the above task which was
previously done in omap glue and in omap-usb2 phy will be removed.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 26 ++-
Documentation/devicetree/bindings/usb/usb-phy.txt |5 +
drivers/usb/phy/Kconfig|9 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/omap-control-usb.c | 238
include/linux/usb/omap_control_usb.h | 71 ++
6 files changed, 349 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/phy/omap-control-usb.c
create mode 100644 include/linux/usb/omap_control_usb.h
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 29a043e..ead6ba9 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP GLUE
+OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
OMAP MUSB GLUE
- compatible : Should be ti,omap4-musb or ti,omap3-musb
@@ -16,6 +16,10 @@ OMAP MUSB GLUE
- power : Should be 50. This signifies the controller can supply upto
100mA when operating in host mode.
+Optional properties:
+ - ctrl_module : phandle of the control module this glue uses to write to
+ mailbox
+
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = ti,omap4-musb;
@@ -23,6 +27,7 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
multipoint = 1;
num_eps = 16;
ram_bits = 12;
+ ctrl_module = omap_control_usb;
};
Board specific device node entry
@@ -31,3 +36,22 @@ Board specific device node entry
mode = 3;
power = 50;
};
+
+OMAP CONTROL USB
+
+Required properties:
+ - compatible: Should be ti,omap-control-usb
+ - reg : Address and length of the register set for the device. It contains
+ the address of control_dev_conf and otghs_control.
+ - reg-names: The names of the register addresses corresponding to the
registers
+ filled in reg.
+ - ti,has_mailbox: This is used to specify if the platform has mailbox in
+ control module.
+
+omap_control_usb: omap-control-usb@4a002300 {
+ compatible = ti,omap-control-usb;
+ reg = 0x4a002300 0x4,
+ 0x4a00233c 0x4;
+ reg-names = control_dev_conf, otghs_control;
+ ti,has_mailbox;
+};
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 80d4148..2466b6f 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -8,10 +8,15 @@ Required properties:
add the address of control module dev conf register until a driver for
control module is added
+Optional properties:
+ - ctrl_module : phandle of the control module used by PHY driver to power on
+ the PHY.
+
This is usually a subnode of ocp2scp to which it is connected.
usb2phy@4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58,
0x4a002300 0x4;
+ ctrl_module = omap_control_usb;
};
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 36a85b6..20479e8 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -14,6 +14,15 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config OMAP_CONTROL_USB
+ tristate OMAP CONTROL USB Driver
+ depends on ARCH_OMAP2PLUS
+ help
+ Enable this to add support for the USB part present in the control
+ module. This driver has API to power on the PHY and to write to the
+ mailbox. The mailbox is present only in omap4 and the register to
+ power on the PHY is present in omap4 and omap5.
+
config USB_ISP1301
tristate NXP ISP1301 USB transceiver support
depends on USB || USB_GADGET
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index ec304f6..ee97767 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,6 +5,7 @@
ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
+obj-$(CONFIG_OMAP_CONTROL_USB) += omap-control-usb.o
obj-$(CONFIG_USB_ISP1301) += isp1301.o
obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
diff --git a/drivers/usb/phy/omap-control-usb.c
b/drivers/usb/phy/omap-control-usb.c
new file mode 100644
index 000..e8fd85c
--- /dev/null
+++ b/drivers/usb/phy/omap-control-usb.c
@@ -0,0 +1,238 @@
+/*
+ * omap-control-usb.c - The USB part of control module.
+ *
+ * Copyright (C) 2013
Question regarding broadcast timer/cpuidle and /proc/interrupts
Hi All, I have a question regarding the behavior of cpuidle on pandaboard. 1. cpuidle is enabled 2. The deep idle states seem to be reach for i in $(find /sys/devices/system/cpu -name usage); do echo $i : $(cat $i); done /sys/devices/system/cpu/cpu0/cpuidle/state0/usage : 7049 /sys/devices/system/cpu/cpu0/cpuidle/state1/usage : 17 /sys/devices/system/cpu/cpu0/cpuidle/state2/usage : 1341 /sys/devices/system/cpu/cpu1/cpuidle/state0/usage : 6318 /sys/devices/system/cpu/cpu1/cpuidle/state1/usage : 17 /sys/devices/system/cpu/cpu1/cpuidle/state2/usage : 1341 3. Regarding the cpuidle driver code : the state1 and state2 are coupled states where the broadcast timer is used instead of the local timer. I assume this is because they go down when we reach these idle states. 4. The content of /proc/interrupts shows no broadcast timer used at all. ... IPI1: 0 0 Timer broadcast interrupts ... Shouldn't be the broadcast timer used sometimes ? or did I miss something ? Thanks. -- Daniel -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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 5/6] usb: otg: add device tree support to otg library
On 01/21/2013 03:34 PM, kishon wrote:
On Monday 21 January 2013 06:51 PM, Roger Quadros wrote:
On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote:
Added an API devm_usb_get_phy_by_phandle(), to get usb phy by passing a
device node phandle value. This function will return a pointer to
the phy on success, -EPROBE_DEFER if there is a device_node for the
phandle,
but the phy has not been added, or a ERR_PTR() otherwise.
Cc: Marc Kleine-Budde m...@pengutronix.de
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/otg.c | 77
+++
include/linux/usb/phy.h |8 +
2 files changed, 85 insertions(+)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index dbf2043..e9799bb 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -13,7 +13,9 @@
#include linux/export.h
#include linux/err.h
#include linux/device.h
+#include linux/module.h
#include linux/slab.h
+#include linux/of.h
#include linux/usb/otg.h
@@ -34,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct
device *dev, u8 index)
return ERR_PTR(-ENODEV);
}
+static struct usb_phy *__of_usb_find_phy(struct device_node *node)
+{
+struct usb_phy *phy;
+
+list_for_each_entry(phy, phy_list, head) {
+if (node != phy-dev-of_node)
+continue;
+
+return phy;
+}
+
+return ERR_PTR(-ENODEV);
+}
+
static void devm_usb_phy_release(struct device *dev, void *res)
{
struct usb_phy *phy = *(struct usb_phy **)res;
@@ -109,6 +125,67 @@ err0:
}
EXPORT_SYMBOL(usb_get_phy);
+ /**
+ * devm_usb_get_phy_by_phandle - find the USB PHY by phandle
+ * @dev - device that requests this phy
+ * @phandle - name of the property holding the phy phandle value
+ * @index - the index of the phy
+ *
+ * Returns the phy driver associated with the given phandle value,
+ * after getting a refcount to it, -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded. While at that, it also associates the device with
+ * the phy using devres. On driver detach, release function is invoked
+ * on the devres data, then, devres data is freed.
+ *
+ * For use by USB host and peripheral drivers.
+ */
+struct usb_phy *devm_usb_get_phy_by_phandle(struct device *dev,
+const char *phandle, u8 index)
+{
+struct usb_phy*phy = NULL, **ptr;
+unsigned longflags;
+struct device_node *node;
+
+if (!dev-of_node) {
+dev_dbg(dev, device does not have a device node entry\n);
+return ERR_PTR(-EINVAL);
+}
+
+node = of_parse_phandle(dev-of_node, phandle, index);
+if (!node) {
+dev_dbg(dev, failed to get %s phandle in %s node\n, phandle,
+dev-of_node-full_name);
+return ERR_PTR(-ENODEV);
+}
+
+ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
+if (!ptr) {
+dev_dbg(dev, failed to allocate memory for devres\n);
+return ERR_PTR(-ENOMEM);
+}
I fail to understand why you need ptr at all and why do devres_alloc()
for it.
Thats how we create a managed device resource. You can have a look at
Documentation/driver-model/devres.txt and drivers/base/devres.c.
OK, I get it now. You might want to update the text file too since you
are adding a automagically managed interface.
regards,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
On 01/21/2013 03:41 PM, kishon wrote: Hi, On Monday 21 January 2013 06:48 PM, Roger Quadros wrote: On 01/16/2013 05:01 PM, Kishon Vijay Abraham I wrote: The OMAP glue has been modified to get PHY by phandle for dt boot. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- drivers/usb/musb/omap2430.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 3628a50..08709cf 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -346,7 +346,12 @@ static int omap2430_musb_init(struct musb *musb) * up through ULPI. TWL4030-family PMICs include one, * which needs a driver, drivers aren't always needed. */ -musb-xceiv = devm_usb_get_phy(dev, 0); +if (dev-parent-of_node) +musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent, +usb_phy, 0); Why dev-parent and not just dev? Right now MUSB core is not converted to dt and hence we don't have separate dt node for MUSB core. So the PHY information is added to the glue dt data. OK. Got it :). -- cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
Hi Santosh
We can also remove all the next data:
omap54xx_l4_abe__aess_dma,
omap54xx_l4_abe__dmic_dma,
omap54xx_l4_abe__mcasp_dma,
omap54xx_l4_abe__mcbsp1_dma,
omap54xx_l4_abe__mcbsp2_dma,
omap54xx_l4_abe__mcbsp3_dma,
omap54xx_l4_abe__mcpdm_dma,
omap54xx_l4_abe__slimbus1_dma,
omap54xx_l4_abe__timer5_dma,
omap54xx_l4_abe__timer6_dma,
omap54xx_l4_abe__timer7_dma,
omap54xx_l4_abe__timer8_dma,
omap54xx_l4_abe__wd_timer3_dma,
It was needed in the past due to the way the lockup between DT data and
hwmod was done but Peter clean it up in 3.8.
For AESS we just need the last memory bank due to hwmod code for
SYS_CONFIG access.
Best regards,
Sebastien
On 01/21/2013 09:11 AM, Santosh Shilimkar wrote:
On Friday 18 January 2013 10:45 PM, Tony Lindgren wrote:
Hi,
* Santosh Shilimkar santosh.shilim...@ti.com [130118 07:30]:
From: Benoit Cousson b-cous...@ti.com
Adding the hwmod data for OMAP54xx platforms.
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+/* bb2d */
+static struct omap_hwmod_irq_info omap54xx_bb2d_irqs[] = {
+{ .irq = 125 + OMAP54XX_IRQ_GIC_START },
+{ .irq = -1 }
+};
...
+/* c2c */
+static struct omap_hwmod_irq_info omap54xx_c2c_irqs[] = {
+{ .irq = 88 + OMAP54XX_IRQ_GIC_START },
+{ .irq = -1 }
+};
...
+static struct omap_hwmod_dma_info omap54xx_c2c_sdma_reqs[] = {
+{ .dma_req = 68 + OMAP54XX_DMA_REQ_START },
+{ .dma_req = -1 }
+};
+static struct omap_hwmod_addr_space omap54xx_elm_addrs[] = {
+{
+.pa_start= 0x48078000,
+.pa_end= 0x48078fff,
+.flags= ADDR_TYPE_RT
+},
+{ }
+};
...
+static struct omap_hwmod_addr_space omap54xx_emif1_addrs[] = {
+{
+.pa_start= 0x4c00,
+.pa_end= 0x4c0003ff,
+.flags= ADDR_TYPE_RT
+},
+{ }
+};
As discussed earlier on this list, let's not duplicate the standard
resources here as they already are supposed to come from device tree.
Whatever issues prevent us from dropping the duplicate data here need
to be fixed. I believe Benoit already had some scripts/patches for
that and was just waiting for the DMA binding to get merged?
Will have a loot at it. DMA binding pull request narrowly missed
3.8 but should get into 3.9.
Regards
santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] ARM: OMAP5: clock data: Add OMAP54XX full clock tree and headers
On Monday 21 January 2013 07:57 PM, Sebastien Guiriec wrote: Hi Santosh, I check the tree with Audio and it is working. Just a comment for the addition of ABE DPLL locking like for OMAP4. Excellent. Can you send the update please? I will fold that in. Regards santosh -- 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: Question regarding broadcast timer/cpuidle and /proc/interrupts
On Monday 21 January 2013 07:47 PM, Daniel Lezcano wrote: Hi All, I have a question regarding the behavior of cpuidle on pandaboard. 1. cpuidle is enabled 2. The deep idle states seem to be reach for i in $(find /sys/devices/system/cpu -name usage); do echo $i : $(cat $i); done /sys/devices/system/cpu/cpu0/cpuidle/state0/usage : 7049 /sys/devices/system/cpu/cpu0/cpuidle/state1/usage : 17 /sys/devices/system/cpu/cpu0/cpuidle/state2/usage : 1341 /sys/devices/system/cpu/cpu1/cpuidle/state0/usage : 6318 /sys/devices/system/cpu/cpu1/cpuidle/state1/usage : 17 /sys/devices/system/cpu/cpu1/cpuidle/state2/usage : 1341 3. Regarding the cpuidle driver code : the state1 and state2 are coupled states where the broadcast timer is used instead of the local timer. I assume this is because they go down when we reach these idle states. Thats correct. Local timer are not wakeup capable and hence we switch to a wakeup capable broadcast timer. 4. The content of /proc/interrupts shows no broadcast timer used at all. ... IPI1: 0 0 Timer broadcast interrupts ... Shouldn't be the broadcast timer used sometimes ? or did I miss something ? There might be an issue with status updating. Just look for gptimer1 interrupts. if they are incrementing then, broadcast is being used but just the status update isn't happening some how. regards santosh -- 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: Question regarding broadcast timer/cpuidle and /proc/interrupts
On 01/21/2013 03:38 PM, Santosh Shilimkar wrote: On Monday 21 January 2013 07:47 PM, Daniel Lezcano wrote: Hi All, I have a question regarding the behavior of cpuidle on pandaboard. 1. cpuidle is enabled 2. The deep idle states seem to be reach for i in $(find /sys/devices/system/cpu -name usage); do echo $i : $(cat $i); done /sys/devices/system/cpu/cpu0/cpuidle/state0/usage : 7049 /sys/devices/system/cpu/cpu0/cpuidle/state1/usage : 17 /sys/devices/system/cpu/cpu0/cpuidle/state2/usage : 1341 /sys/devices/system/cpu/cpu1/cpuidle/state0/usage : 6318 /sys/devices/system/cpu/cpu1/cpuidle/state1/usage : 17 /sys/devices/system/cpu/cpu1/cpuidle/state2/usage : 1341 3. Regarding the cpuidle driver code : the state1 and state2 are coupled states where the broadcast timer is used instead of the local timer. I assume this is because they go down when we reach these idle states. Thats correct. Local timer are not wakeup capable and hence we switch to a wakeup capable broadcast timer. 4. The content of /proc/interrupts shows no broadcast timer used at all. ... IPI1: 0 0 Timer broadcast interrupts ... Shouldn't be the broadcast timer used sometimes ? or did I miss something ? There might be an issue with status updating. Just look for gptimer1 interrupts. if they are incrementing then, broadcast is being used but just the status update isn't happening some how. Is it the interrupt 69 ? 29:293395 GIC twd 41: 0 0 GIC l3-dbg-irq 42: 0 0 GIC l3-app-irq 44: 0 0 GIC DMA 69: 61 0 GIC gp_timer 88: 0 0 GIC i2c.9 89: 0 0 GIC i2c.10 93: 0 0 GIC i2c.11 94: 0 0 GIC i2c.12 106: 93 0 GIC OMAP UART2 169: 0 0 PRCM hwmod_io IPI0: 0 0 Timer broadcast interrupts IPI1: 1424 1260 Rescheduling interrupts IPI2: 0 0 Function call interrupts IPI3:81 90 Single function call interrupts IPI4: 0 0 CPU stop interrupts Err: 0 regards santosh -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
On Monday 21 January 2013 01:41 PM, Santosh Shilimkar wrote:
On Friday 18 January 2013 10:45 PM, Tony Lindgren wrote:
Hi,
* Santosh Shilimkar santosh.shilim...@ti.com [130118 07:30]:
From: Benoit Cousson b-cous...@ti.com
Adding the hwmod data for OMAP54xx platforms.
--- /dev/null
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+/* bb2d */
+static struct omap_hwmod_irq_info omap54xx_bb2d_irqs[] = {
+{ .irq = 125 + OMAP54XX_IRQ_GIC_START },
+{ .irq = -1 }
+};
...
+/* c2c */
+static struct omap_hwmod_irq_info omap54xx_c2c_irqs[] = {
+{ .irq = 88 + OMAP54XX_IRQ_GIC_START },
+{ .irq = -1 }
+};
...
+static struct omap_hwmod_dma_info omap54xx_c2c_sdma_reqs[] = {
+{ .dma_req = 68 + OMAP54XX_DMA_REQ_START },
+{ .dma_req = -1 }
+};
+static struct omap_hwmod_addr_space omap54xx_elm_addrs[] = {
+{
+.pa_start= 0x48078000,
+.pa_end= 0x48078fff,
+.flags= ADDR_TYPE_RT
+},
+{ }
+};
...
+static struct omap_hwmod_addr_space omap54xx_emif1_addrs[] = {
+{
+.pa_start= 0x4c00,
+.pa_end= 0x4c0003ff,
+.flags= ADDR_TYPE_RT
+},
+{ }
+};
As discussed earlier on this list, let's not duplicate the standard
resources here as they already are supposed to come from device tree.
Whatever issues prevent us from dropping the duplicate data here need
to be fixed. I believe Benoit already had some scripts/patches for
that and was just waiting for the DMA binding to get merged?
Will have a loot at it. DMA binding pull request narrowly missed
3.8 but should get into 3.9.
So I looked at this one with help of Rajendra. We can get rid of the
IRQ and DMA data(needs DMA biding updates) easily. The address
space though is needed since hwmod code uses it to setup the
sysconfig registers.
Extracting that from DT code seems to be really expensive and
ugly [1]. I am yet to try out DMA lines removal but that seems
to be doable by pulling Vinod'd DMA engine branch and updating
DT file.
Whats your suggestion on address space part ?
Regards,
Santosh
[1] HACK address extraction with DT.
---
arch/arm/mach-omap2/omap_hwmod.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 4653efb..f54b9d4 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -138,6 +138,7 @@
#include linux/spinlock.h
#include linux/slab.h
#include linux/bootmem.h
+#include linux/of.h
#include clock.h
#include omap_hwmod.h
@@ -2335,7 +2336,12 @@ static int _shutdown(struct omap_hwmod *oh)
static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data)
{
struct omap_hwmod_addr_space *mem;
- void __iomem *va_start;
+ void __iomem *va_start = NULL;
+ struct device_node *np;
+ unsigned long start = 0, size = 0;
+ const void *reg_prop;
+ const char *p;
+
if (!oh)
return;
@@ -2349,15 +2355,32 @@ static void __init _init_mpu_rt_base(struct
omap_hwmod *oh, void *data)
if (!mem) {
pr_debug(omap_hwmod: %s: no MPU register target found\n,
oh-name);
- return;
+ /*Check in Device Tree blob*/
+ for_each_child_of_node(of_find_node_by_name(NULL, ocp), np) {
+ printk(np-name=%s\n, np-name);
+ if(of_find_property(np, ti,hwmods, NULL)) {
+ p = of_get_property(np, ti,hwmods, NULL);
+ if (!strcmp(p, oh-name)) {
+ reg_prop = of_get_property(np, reg, NULL);
+ start = of_read_number(reg_prop, 1);
+ size = of_read_number(reg_prop + 4, 1);
+ }
+ }
+ }
+ } else {
+ start = mem-pa_start;
+ size = mem-pa_end - mem-pa_start;
}
- va_start = ioremap(mem-pa_start, mem-pa_end - mem-pa_start);
+ if (!start)
+ return;
+
+ va_start = ioremap(start, size);
if (!va_start) {
pr_err(omap_hwmod: %s: Could not ioremap\n, oh-name);
return;
}
-
+
pr_debug(omap_hwmod: %s: MPU register target at va %p\n,
oh-name, va_start);
--
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
[GIT PULL] ARM: OMAP: some clock/hwmod fixes for v3.8-rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-fixes-b-for-v3.8-rc for you to fetch changes up to bdcc61275232db897ba831f87a16df98ab248571: ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function calls (2013-01-18 16:48:16 -0700) - A few OMAP integration fixes for v3.8-rc, for OMAP4 audio and OMAP2 reboot. Basic test logs are available here: http://www.pwsan.com/omap/testlogs/prcm_fixes_c_v3.8-rc/20130121073904/ - vmlinux object size (delta in bytes from test_v3.8-rc4 (7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619)): text data bsstotal kernel 0000 am33xx_only +8 +240 +32 n800_multi_omap2xxx +4 -80 -4 n800_only_a 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0000 omap1_defconfig_5912osk_only -8 +800 omap2plus_defconfig +4 +240 +28 omap2plus_defconfig_2430sdp_only -8 +800 omap2plus_defconfig_cpupm -8 +800 omap2plus_defconfig_no_pm -8 +800 omap2plus_defconfig_omap2_4_only -16 +1600 omap2plus_defconfig_omap3_4_only -8 +800 rmk_omap3430_ldp_allnoconfig 0000 rmk_omap3430_ldp_oldconfig -8 +800 rmk_omap4430_sdp_allnoconfig -16 +1600 rmk_omap4430_sdp_oldconfig Jon Hunter (1): ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function calls Peter Ujfalusi (2): ARM: OMAP4: clock data: Lock ABE DPLL on all revisions ARM: OMAP4: hwmod_data: Correct IDLEMODE for McPDM arch/arm/mach-omap2/cclock2420_data.c |2 ++ arch/arm/mach-omap2/cclock2430_data.c |2 ++ arch/arm/mach-omap2/cclock44xx_data.c | 13 ++--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 +- 4 files changed, 15 insertions(+), 8 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQ/WYEAAoJEMePsQ0LvSpLjwcP/3ZgPMHcwk+/rdSOtCF9BR4V BFc9GSyUnj5jJMmVo2yixHgM6hnf0nqP9lEHW6wYaqFF7wb6swo5mKCsK3VErgF/ xJXL1j9DmdnnF+uUeoRmKlNkQ2y2+zkbHCBY8A6zxzKQMYW6xSwkhM1Jdmw55Vxn ROgPXuzjOnXUsTtodYsVkW/3hGNKCxoP8/hH7M+GcQVql9Iebh2E/efW67pSFTvp ChisfYiHWJWzDso8FfKkLwYHSZfK5qq3KNFgRq2n0xuxEsJMGqM5rKaQypJ6LMK/ ExvPgFAhgHnsSvtESNWAKsAXDtVvr2z/HYPIsoCVYUy7C33P857uQpbIXuD4gS4w CLon1M9k4Wpuzd4Da/WY6O8L6goCrTuL7Cx1ayWBmvZNDpwNAUVQi8k1Ei9vcFiv N3vxutc/QrYQ11x7uNe2A8XWp8fsVvwQ6+XiVk96ZXgKe+Fc1COOz17lMyxhJqdo PhAXvnvo5avzDueiu4AluFkIwsNl5vDqphkxqhOdlDzcuZHN4dzguoN/fKIbSXfy fKS6GXDwU1vTTpvzbefdDUiVU+rEi9HIbXv8tkXp5FPnAs0YLD0vdbC6bIeUFO1K S7AW075XkmB04VYPZeUh6vBCBjoWXYClMyIzeEEVvAxOTEHMi3+nZn7jIel7uVMa l0wEGhU+lY3MHfbHdmh2 =1k3b -END PGP SIGNATURE- -- 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.8-rc4
On 16:32-20130121, Mark Jackson wrote: Vaibhav / Matt On 20/01/13 21:38, Paul Walmsley wrote: [...] Failing tests: needing local investigation (may be due to testbed issues) - Boot tests: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 - Not yet part of the automated test suite - Nishanth Menon Vaibhav Hiremath report that it works for them * May be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test Does anyone know when the BeagleBone support is going to be fixed in mainline ? I've just tried the latest linux-next git, and no joy. However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone Are we just waiting for Matt's DMA stuff to be accepted ? for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8-rc4 tag see: http://pastebin.com/bGNxJnZJ build configuration: compiler: $ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. U-boot: git://git.denx.de/u-boot.git v2013.01-rc3 config: am335x_evm_config kernel: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v3.8-rc4 config: omap2plus_defconfig -- Regards, Nishanth Menon -- 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.8-rc4
Vaibhav / Matt On 20/01/13 21:38, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.8-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/ snip Failing tests: needing investigation Boot tests: * am335xbone: hangs after Starting kernel - Cause unknown - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html snip Failing tests: needing local investigation (may be due to testbed issues) - Boot tests: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 - Not yet part of the automated test suite - Nishanth Menon Vaibhav Hiremath report that it works for them * May be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test Does anyone know when the BeagleBone support is going to be fixed in mainline ? I've just tried the latest linux-next git, and no joy. However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone Are we just waiting for Matt's DMA stuff to be accepted ? Cheers Mark J. -- 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 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
Hi Mark,
On Mon, Jan 21, 2013 at 9:30 AM, Mark Rutland mark.rutl...@arm.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 01ce462..f7de9eb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -39,6 +39,7 @@
#include omap_device.h
#include gpmc.h
#include gpmc-nand.h
+#include gpmc-onenand.h
#define DEVICE_NAME omap-gpmc
@@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct
platform_device *pdev,
}
#endif
+#ifdef CONFIG_MTD_ONENAND
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ u32 val;
+ struct omap_onenand_platform_data *gpmc_onenand_data;
+
+ if (of_property_read_u32(child, reg, val) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ gpmc_onenand_data = devm_kzalloc(pdev-dev,
sizeof(*gpmc_onenand_data),
+ GFP_KERNEL);
+ if (!gpmc_onenand_data)
+ return -ENOMEM;
+
+ gpmc_onenand_data-cs = val;
+ gpmc_onenand_data-of_node = child;
+ gpmc_onenand_data-dma_channel = -1;
+
+ if (!of_property_read_u32(child, dma-channel, val))
+ gpmc_onenand_data-dma_channel = val;
+
+ gpmc_onenand_init(gpmc_onenand_data);
+
+ return 0;
+}
+#else
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ return 0;
+}
+#endif
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
This doesn't look right to me:
+ for_each_node_by_name(child, onenand) {
+ ret = gpmc_probe_onenand_child(pdev, child);
+ of_node_put(child);
+ if (ret 0)
+ return ret;
+ }
for_each_node_by_name automatically calls of_node_put on each node once
passed,
and as far as I can tell, gpmc_probe_onenand_child doesn't do anything that'd
increment a node's refcount.
As far as I can see, you only need the of_node_put in the error case:
for_each_node_by_name(child, onenand) {
ret = gpmc_probe_onenand_child(pdev, child);
if (ret 0) {
of_node_put(child);
return ret;
}
}
Have I missed something here?
Mmm... perhaps I've overlooked that code.
After some digging through source and reading for_each_node_by_name()
it seems to me you're right.
@Daniel: It seems this would also apply to the NAND binding.
What do you think?
--
Ezequiel
--
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.8-rc4
On Mon, Jan 21, 2013 at 04:32:13PM +, Mark Jackson wrote: Vaibhav / Matt On 20/01/13 21:38, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.8-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/ snip Failing tests: needing investigation Boot tests: * am335xbone: hangs after Starting kernel - Cause unknown - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html snip Failing tests: needing local investigation (may be due to testbed issues) - Boot tests: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 - Not yet part of the automated test suite - Nishanth Menon Vaibhav Hiremath report that it works for them * May be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test Does anyone know when the BeagleBone support is going to be fixed in mainline ? Hi Mark, I'm not sure what needs to be fixed. The only thing my edma dmaengine series adds is new features (specifically, mmc and spi dma support). I would suspect some boot problem specific to Paul's configuration if it's hanging. I just booted current mainline with an omap2plus_defconfig build on my bone a5 and it came up fine. I've just tried the latest linux-next git, and no joy. However, Matt's edma-dmaengine-am33xx-v5 branch on github seems to be working:- Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-rc3-61978-g108da76-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11-git-00497-ge48bf89) ) #7 SMP Mon Jan 21 15:52:14 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone Are we just waiting for Matt's DMA stuff to be accepted ? For the features I listed above, yes. Also Mark Greer's crypto patches for AM33xx depend on that series as does a patch series (not ready yet) that I have to support the Bone audio capes. There's a dependency I'm working through in a separate thread on lkml since the dmaengine edma series requires the proposed dma_get_channel_caps() api...still discussing that implementation. -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 0/2] OMAP3 ISP: Simplify clock usage
* Laurent Pinchart laurent.pinch...@ideasonboard.com [130121 05:37]: Hi Mike, On Monday 14 January 2013 17:10:15 Mike Turquette wrote: Quoting Laurent Pinchart (2013-01-08 05:43:52) Hello, Now that the OMAP3 supports the common clock framework, clock rate back-propagation is available for the ISP clocks. Instead of setting the cam_mclk parent clock rate to control the cam_mclk clock rate, we can mark the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting back-propagation, and set the cam_mclk rate directly. This simplifies the ISP clocks configuration. I'm pleased to see this feature get used on OMAP. Plus your driver gets a negative diffstat :) Reviewed-by: Mike Turquette mturque...@linaro.org Thanks. Would you like to take the arch/ patch in your tree, or should I push it through the linux-media tree along with the omap3isp patch ? The arch/arm/*omap* clock changes need to be queued by Paul to avoid potential stupid merge conflicts when the clock data gets moved to live under drivers/clk/omap. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
* Santosh Shilimkar santosh.shilim...@ti.com [130121 07:09]: So I looked at this one with help of Rajendra. We can get rid of the IRQ and DMA data(needs DMA biding updates) easily. The address space though is needed since hwmod code uses it to setup the sysconfig registers. OK great. The address space tinkering in hwmod code should be moved to be done in the drivers. As discussed earlier, there should be a driver specific reset function driver_xyz_reset() in the driver header file so the hwmod code can call it too in a late_initcall if no driver is loaded. Extracting that from DT code seems to be really expensive and ugly [1]. I am yet to try out DMA lines removal but that seems to be doable by pulling Vinod'd DMA engine branch and updating DT file. The overhead here does not matter as it should only happen in a late_initcall and only for some of the drivers. For that to happen we just need to go through the list of modules not yet probed. We also need to have some locking in the driver specific reset function to avoid races with the loadable modules. Whats your suggestion on address space part ? Let's add the code to hwmod to extract it from DT so hwmod code can call the driver specific reset function defined in the driver header. That way we can start moving the driver code out of hwmod one driver at a time. Note that the ioremapping should be done in the driver specific reset function, not in hwmod code. We just need to pass the iorange in a struct resource to the driver specific reset function. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: fix draining irq handling
Hi, On Mon, Jan 21, 2013 at 10:44:31AM +0200, Felipe Balbi wrote: On Sun, Jan 20, 2013 at 08:37:02PM +0200, Aaro Koskinen wrote: Commit 0bdfe0cb803dce699ff337c35d8e97ac355fa417 (i2c: omap: sanitize exit path) changed the interrupt handler to exit early and complete the transfer after the draining IRQ is handled. As a result, the ARDY may not be cleared properly, and it may cause all future I2C transfers to timeout with timeout waiting for bus ready. This is reproducible at least with N900 when twl4030_gpio makes a long write ( FIFO size) during the probe (http://marc.info/?l=linux-omapm=135818882610432w=2). The fix is to continue until we get ARDY interrupt that completes the transfer. Tested with 3.8-rc4 + N900: 20 boots in a row without errors; without the patch the problem triggers after few reboots. fair enough, but ... Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- drivers/i2c/busses/i2c-omap.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 832f16e..4cc2f05 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -963,7 +963,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) i2c_omap_errata_i207(dev, stat); omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR); - break; + continue; ... when we get draining Interrupt, it means we're receiving the last few bytes, meaning that by the time we handle it there's nothing pending to be transferred. I would rather wait for ARDY before exiting omap_i2c_xfer_msg() rather than here. Specially since that was the programming model suggested by our IP engineers. Such handling is part of my other patchset and can be easily ported. OTOH, we might decide to go with this during this -rc and fix it all up for v3.9 on my other patchset. Completing through ARDY interrupt has been known to work reliably for years. So for 3.8-rc I would prefer to just restore the old behaviour. A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] ARM: OMAP5: clock data: Add OMAP54XX full clock tree and headers
* Santosh Shilimkar santosh.shilim...@ti.com [130121 00:16]: On Friday 18 January 2013 10:49 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130118 07:30]: From: Rajendra Nayak rna...@ti.com Add the clock tree related data for OMAP54xx platforms. Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Benoit Cousson b-cous...@ti.com [santosh.shilim...@ti.com: Generated es2.0 data] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- As mentioned in the summary, this patch will be updated once the movement of clock data to drivers/clock is clear. Yes let's first fix up the issues prevent us from moving all the cclock*_data.c files to live under drivers/clock/omap. It seems that fixing this issue boils down to rearranging some clock related headers in arch/arm/mach-omap2, and then populating some of the clock data dynamically. Or am I missing something? Am not sure of all the dependencies. Since clock data is using the low level prm/cm APIs, all those needs to be exported some how to move the data. Paul can comment better on it. It seems that we should be able to export some omap specific functions from drivers/clk/omap for that. 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: OMAP baseline test results for v3.8-rc4
On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8-rc4 tag Yep, I also could boot 3.8-rc3 using ramfs, no problem. Thanks, Richard -- 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: OMAP2+: fix build break for omapdrm
* Rob Clark robdcl...@gmail.com [130120 07:40]: Fixes compile break with 3.8-rc4. Signed-off-by: Rob Clark robdcl...@gmail.com Thanks applying into omap-for-v3.8-rc4/fixes. Regards, Tony --- arch/arm/mach-omap2/drm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c index 4c7566c..2a2cfa8 100644 --- a/arch/arm/mach-omap2/drm.c +++ b/arch/arm/mach-omap2/drm.c @@ -25,6 +25,7 @@ #include linux/dma-mapping.h #include linux/platform_data/omap_drm.h +#include soc.h #include omap_device.h #include omap_hwmod.h @@ -56,7 +57,7 @@ static int __init omap_init_drm(void) oh-name); } - platform_data.omaprev = GET_OMAP_REVISION(); + platform_data.omaprev = GET_OMAP_TYPE; return platform_device_register(omap_drm_device); -- 1.8.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: omap4-panda: add UART2 muxing for WiLink shared transport
* Luciano Coelho coe...@ti.com [130121 03:18]:
Add the UART2 muxing data to the board file (this used to be,
erroneously, done in the bootloader).
Cc: stable sta...@vger.kernel.org [3.7]
Signed-off-by: Luciano Coelho coe...@ti.com
Thanks applying into omap-for-v3.8-rc4/fixes.
Regards,
Tony
---
arch/arm/mach-omap2/board-omap4panda.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 5c8e9ce..769c1fe 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -397,6 +397,12 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP_PULL_ENA),
OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ /* UART2 - BT/FM/GPS shared transport */
+ OMAP4_MUX(UART2_CTS,OMAP_PIN_INPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_RTS,OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_RX, OMAP_PIN_INPUT | OMAP_MUX_MODE0),
+ OMAP4_MUX(UART2_TX, OMAP_PIN_OUTPUT | OMAP_MUX_MODE0),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
--
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
Re: [PATCH 3/4] ARM: mach-omap2: apply the errata at run time rather
* srinidhi kasagar srinidhi.kasa...@stericsson.com [130121 05:19]: Forgot to complete the subject and add the description? Regards, Tony Signed-off-by: srinidhi kasagar srinidhi.kasa...@stericsson.com --- arch/arm/mach-omap2/sleep44xx.S | 25 + 1 files changed, 21 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S index 88ff83a..071ca1f 100644 --- a/arch/arm/mach-omap2/sleep44xx.S +++ b/arch/arm/mach-omap2/sleep44xx.S @@ -157,11 +157,19 @@ skip_scu_gp_set: ldrne r0, [r8, #L2X0_SAVE_OFFSET1]@ memory. cmp r0, #3 bne do_WFI -#ifdef CONFIG_PL310_ERRATA_727915 + /* Check for PL310_ERRATA_727915 */ + bl l2x0_get_rtl_release + cmp r0, #0x4 + beq dosmc + cmp r0, #0x5 + beq dosmc + b nosmc +dosmc: mov r0, #0x03 mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX DO_SMC -#endif + +nosmc: bl omap4_get_l2cache_base mov r2, r0 ldr r0, =0x @@ -171,11 +179,20 @@ wait: ldr r1, =0x andsr0, r0, r1 bne wait -#ifdef CONFIG_PL310_ERRATA_727915 + + /* Check for PL310_ERRATA_727915 */ + bl l2x0_get_rtl_release + cmp r0, #0x4 + beq dosmc2 + cmp r0, #0x5 + beq dosmc2 + b nosmc2 +dosmc2: mov r0, #0x00 mov r12, #OMAP4_MON_L2X0_DBG_CTRL_INDEX DO_SMC -#endif + +nosmc2: l2x_sync: bl omap4_get_l2cache_base mov r2, r0 -- 1.7.2.dirty -- 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.8-rc4
On Mon, Jan 21, 2013 at 06:20:03PM +, Richard Cochran wrote: On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8-rc4 tag Yep, I also could boot 3.8-rc3 using ramfs, no problem. Do you use appended dtb? The only different that jumped out at me first Paul's reported hang is he uses appended dtb and I boot my boards with a single uImage and multiple dtbs the traditional DT way. -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
[PATCH] ARM: OMAP2+: Fix section warning for omap_init_ocp2scp()
Otherwise we will get:
WARNING: vmlinux.o(.text+0x1d4f0): Section mismatch in reference from the
function omap_init_ocp2scp() to the function .init.text:omap_device_build()
The function omap_init_ocp2scp() references
the function __init omap_device_build().
This is often because omap_init_ocp2scp lacks a __init
annotation or the annotation of omap_device_build is wrong.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -639,7 +639,7 @@ static int count_ocp2scp_devices(struct omap_ocp2scp_dev
*ocp2scp_dev)
return cnt;
}
-static void omap_init_ocp2scp(void)
+static void __init omap_init_ocp2scp(void)
{
struct omap_hwmod *oh;
struct platform_device *pdev;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: some clock/hwmod fixes for v3.8-rc
* Paul Walmsley p...@pwsan.com [130121 08:04]: Hi Tony, The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-fixes-b-for-v3.8-rc for you to fetch changes up to bdcc61275232db897ba831f87a16df98ab248571: ARM: OMAP2: Fix missing omap2xxx_clkt_vps_late_init function calls (2013-01-18 16:48:16 -0700) A few OMAP integration fixes for v3.8-rc, for OMAP4 audio and OMAP2 reboot. Basic test logs are available here: http://www.pwsan.com/omap/testlogs/prcm_fixes_c_v3.8-rc/20130121073904/ Thanks pulling into omap-for-v3.8-rc4/fixes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: fix draining irq handling
Hi, On Mon, Jan 21, 2013 at 08:01:59PM +0200, Aaro Koskinen wrote: Hi, On Mon, Jan 21, 2013 at 10:44:31AM +0200, Felipe Balbi wrote: On Sun, Jan 20, 2013 at 08:37:02PM +0200, Aaro Koskinen wrote: Commit 0bdfe0cb803dce699ff337c35d8e97ac355fa417 (i2c: omap: sanitize exit path) changed the interrupt handler to exit early and complete the transfer after the draining IRQ is handled. As a result, the ARDY may not be cleared properly, and it may cause all future I2C transfers to timeout with timeout waiting for bus ready. This is reproducible at least with N900 when twl4030_gpio makes a long write ( FIFO size) during the probe (http://marc.info/?l=linux-omapm=135818882610432w=2). The fix is to continue until we get ARDY interrupt that completes the transfer. Tested with 3.8-rc4 + N900: 20 boots in a row without errors; without the patch the problem triggers after few reboots. fair enough, but ... Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- drivers/i2c/busses/i2c-omap.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 832f16e..4cc2f05 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -963,7 +963,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id) i2c_omap_errata_i207(dev, stat); omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR); - break; + continue; ... when we get draining Interrupt, it means we're receiving the last few bytes, meaning that by the time we handle it there's nothing pending to be transferred. I would rather wait for ARDY before exiting omap_i2c_xfer_msg() rather than here. Specially since that was the programming model suggested by our IP engineers. Such handling is part of my other patchset and can be easily ported. OTOH, we might decide to go with this during this -rc and fix it all up for v3.9 on my other patchset. Completing through ARDY interrupt has been known to work reliably for years. So for 3.8-rc I would prefer to just restore the old behaviour. fair enough, I'll rebase my patchset on top of $SUBJECT -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: board-zoom: Do not request LCD panel enable GPIO from twl4030
* Peter Ujfalusi peter.ujfal...@ti.com [130121 05:30]: The pin in question is muxed between GPIO7 and PWM1. For backlight control there is a custom code in board-zoom-display to control the backlight. No need to request the GPIO7 - which was failing since the way it is requested no longer valid: twl's gpio range is allocated dynamically. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi Tony, This patch is generated on top of my previous series for audio/pwm support: http://www.spinics.net/lists/linux-omap/msg85085.html Can you do a pull request for me for all the arch/arm/*omap* parts against v3.8-rc4 for the v3.9 merge window? That way you can also merge the same branch into ASoC tree if needed as long as you keep your arch/arm/*omap* branch immutable. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] arm: omap2: gpmc: add DT bindings for OneNAND
* Ezequiel Garcia elezegar...@gmail.com [130121 09:00]:
Hi Mark,
On Mon, Jan 21, 2013 at 9:30 AM, Mark Rutland mark.rutl...@arm.com wrote:
[...]
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 01ce462..f7de9eb 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -39,6 +39,7 @@
#include omap_device.h
#include gpmc.h
#include gpmc-nand.h
+#include gpmc-onenand.h
#define DEVICE_NAME omap-gpmc
@@ -1259,6 +1260,43 @@ static int gpmc_probe_nand_child(struct
platform_device *pdev,
}
#endif
+#ifdef CONFIG_MTD_ONENAND
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ u32 val;
+ struct omap_onenand_platform_data *gpmc_onenand_data;
+
+ if (of_property_read_u32(child, reg, val) 0) {
+ dev_err(pdev-dev, %s has no 'reg' property\n,
+ child-full_name);
+ return -ENODEV;
+ }
+
+ gpmc_onenand_data = devm_kzalloc(pdev-dev,
sizeof(*gpmc_onenand_data),
+ GFP_KERNEL);
+ if (!gpmc_onenand_data)
+ return -ENOMEM;
+
+ gpmc_onenand_data-cs = val;
+ gpmc_onenand_data-of_node = child;
+ gpmc_onenand_data-dma_channel = -1;
+
+ if (!of_property_read_u32(child, dma-channel, val))
+ gpmc_onenand_data-dma_channel = val;
+
+ gpmc_onenand_init(gpmc_onenand_data);
+
+ return 0;
+}
+#else
+static int gpmc_probe_onenand_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ return 0;
+}
+#endif
+
static int gpmc_probe_dt(struct platform_device *pdev)
{
int ret;
@@ -1276,6 +1314,12 @@ static int gpmc_probe_dt(struct platform_device
*pdev)
return ret;
}
This doesn't look right to me:
+ for_each_node_by_name(child, onenand) {
+ ret = gpmc_probe_onenand_child(pdev, child);
+ of_node_put(child);
+ if (ret 0)
+ return ret;
+ }
for_each_node_by_name automatically calls of_node_put on each node once
passed,
and as far as I can tell, gpmc_probe_onenand_child doesn't do anything
that'd
increment a node's refcount.
As far as I can see, you only need the of_node_put in the error case:
for_each_node_by_name(child, onenand) {
ret = gpmc_probe_onenand_child(pdev, child);
if (ret 0) {
of_node_put(child);
return ret;
}
}
Have I missed something here?
Mmm... perhaps I've overlooked that code.
After some digging through source and reading for_each_node_by_name()
it seems to me you're right.
@Daniel: It seems this would also apply to the NAND binding.
What do you think?
Would prefer this done as a fix against the omap-for-v3.9/gpmc
branch before we apply Ezequiel's patches.
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: OMAP baseline test results for v3.8-rc4
On Mon, Jan 21, 2013 at 01:24:19PM -0500, Matt Porter wrote:
On Mon, Jan 21, 2013 at 06:20:03PM +, Richard Cochran wrote:
On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote:
for MMC filesystem - we need the edma series. for a ramdisk, I am able
to boot up to shell with 3.8-rc4 tag
Yep, I also could boot 3.8-rc3 using ramfs, no problem.
Do you use appended dtb? The only different that jumped out at me first
Paul's reported hang is he uses appended dtb and I boot my boards with a
single uImage and multiple dtbs the traditional DT way.
No, not appended. I have a u-boot that supports dtb:
U-Boot SPL 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20)
U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20)
and using the omap2plus_defconfig, with a minicom script like the one
below, and it works just fine.
HTH,
Richard
verbose on
send setenv ipaddr 192.168.1.77
send setenv serverip 192.168.1.12
send setenv netmask 255.255.255.0
send setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw
initrd=0x8200,16MB ramdisk_size=16384 earlyprintk=serial
send tftp 8100 uImage
expect {
U-Boot#
}
send tftp 8200 beaglebone-initrd.gz
expect {
U-Boot#
}
send tftp 8000 am335x-bone.dtb
expect {
U-Boot#
}
send bootm 8100 - 8000
--
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] omap: DT node Timer iteration fix
* Jon Hunter jon-hun...@ti.com [130109 14:15]: Hi Pantelis, On 01/08/2013 07:31 AM, Pantelis Antoniou wrote: The iterator correctly handles of_node_put() calls. Remove it before continue'ing the loop. Without this patch you get: Thanks for the fix! May be worth mentioning that this will only be seen with CONFIG_OF_DYNAMIC (and explains why I did not catch this one!). Thanks I'll update the description and apply into omap-for-v3.8-rc4/fixes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: board-zoom: Do not request LCD panel enable GPIO from twl4030
* Tony Lindgren t...@atomide.com [130121 10:35]: * Peter Ujfalusi peter.ujfal...@ti.com [130121 05:30]: The pin in question is muxed between GPIO7 and PWM1. For backlight control there is a custom code in board-zoom-display to control the backlight. No need to request the GPIO7 - which was failing since the way it is requested no longer valid: twl's gpio range is allocated dynamically. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- Hi Tony, This patch is generated on top of my previous series for audio/pwm support: http://www.spinics.net/lists/linux-omap/msg85085.html Can you do a pull request for me for all the arch/arm/*omap* parts against v3.8-rc4 for the v3.9 merge window? That way you can also merge the same branch into ASoC tree if needed as long as you keep your arch/arm/*omap* branch immutable. Probably needs to be several branches though, at least the .dts changes should be separate for Benoit. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP3 ISP: Simplify clock usage
Hi Tony, On Monday 21 January 2013 09:18:12 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [130121 05:37]: On Monday 14 January 2013 17:10:15 Mike Turquette wrote: Quoting Laurent Pinchart (2013-01-08 05:43:52) Hello, Now that the OMAP3 supports the common clock framework, clock rate back-propagation is available for the ISP clocks. Instead of setting the cam_mclk parent clock rate to control the cam_mclk clock rate, we can mark the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting back-propagation, and set the cam_mclk rate directly. This simplifies the ISP clocks configuration. I'm pleased to see this feature get used on OMAP. Plus your driver gets a negative diffstat :) Reviewed-by: Mike Turquette mturque...@linaro.org Thanks. Would you like to take the arch/ patch in your tree, or should I push it through the linux-media tree along with the omap3isp patch ? The arch/arm/*omap* clock changes need to be queued by Paul to avoid potential stupid merge conflicts when the clock data gets moved to live under drivers/clk/omap. OK. The omap3isp patch can go through Paul's tree as well, it won't conflict with other changes to the driver in this merge window. Paul, can you take both patches together ? If so I'll send you a pull request. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP3 ISP: Simplify clock usage
Quoting Laurent Pinchart (2013-01-21 10:54:38) Hi Tony, On Monday 21 January 2013 09:18:12 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [130121 05:37]: On Monday 14 January 2013 17:10:15 Mike Turquette wrote: Quoting Laurent Pinchart (2013-01-08 05:43:52) Hello, Now that the OMAP3 supports the common clock framework, clock rate back-propagation is available for the ISP clocks. Instead of setting the cam_mclk parent clock rate to control the cam_mclk clock rate, we can mark the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting back-propagation, and set the cam_mclk rate directly. This simplifies the ISP clocks configuration. I'm pleased to see this feature get used on OMAP. Plus your driver gets a negative diffstat :) Reviewed-by: Mike Turquette mturque...@linaro.org Thanks. Would you like to take the arch/ patch in your tree, or should I push it through the linux-media tree along with the omap3isp patch ? The arch/arm/*omap* clock changes need to be queued by Paul to avoid potential stupid merge conflicts when the clock data gets moved to live under drivers/clk/omap. OK. The omap3isp patch can go through Paul's tree as well, it won't conflict with other changes to the driver in this merge window. Paul, can you take both patches together ? If so I'll send you a pull request. +1 I don't take in driver changes/adaptations through the clk tree unless it is necessary to avoid painful conflicts or merge ordering issues. This has only happened a few times for MFD devices, etc. Typically the clk-next branch is only used for changes to the clk framework core or clk drivers. Regards, Mike -- Regards, Laurent Pinchart -- 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.8-rc4
Matt == Matt Porter mpor...@ti.com writes: Matt On Mon, Jan 21, 2013 at 04:32:13PM +, Mark Jackson wrote: Does anyone know when the BeagleBone support is going to be fixed in mainline ? Matt Hi Mark, Matt I'm not sure what needs to be fixed. The only thing my edma dmaengine Matt series adds is new features (specifically, mmc and spi dma support). Matt I would suspect some boot problem specific to Paul's configuration Matt if it's hanging. I just booted current mainline with an Matt omap2plus_defconfig build on my bone a5 and it came up fine. It also works here. I have noticed issues with nfs boot and recent mainline when powered from the USB cable though. I suspect we're getting close to the power limit. -- Bye, Peter Korsgaard -- 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.8-rc4
Matt == Matt Porter mpor...@ti.com writes: Matt On Mon, Jan 21, 2013 at 06:20:03PM +, Richard Cochran wrote: On Mon, Jan 21, 2013 at 10:45:10AM -0600, Nishanth Menon wrote: for MMC filesystem - we need the edma series. for a ramdisk, I am able to boot up to shell with 3.8-rc4 tag Yep, I also could boot 3.8-rc3 using ramfs, no problem. Matt Do you use appended dtb? The only different that jumped out at me first Matt Paul's reported hang is he uses appended dtb and I boot my boards with a Matt single uImage and multiple dtbs the traditional DT way. It works for me with appended dtb as well. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: AM33XX: Add ELM node
Philip == Philip Avinash avinashphi...@ti.com writes:
Philip From: Philip, Avinash avinashphi...@ti.com
Philip Add ELM data node to AM33XX device tree file.
Philip Signed-off-by: Philip Avinash avinashphi...@ti.com
Philip ---
Philip arch/arm/boot/dts/am33xx.dtsi |8
Philip 1 file changed, 8 insertions(+)
Philip diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
Philip index c2f14e8..eaef5e7 100644
Philip --- a/arch/arm/boot/dts/am33xx.dtsi
Philip +++ b/arch/arm/boot/dts/am33xx.dtsi
Philip @@ -385,5 +385,13 @@
Philipmac-address = [ 00 00 00 00 00 00 ];
Philip};
Philip};
Philip +
Philip + elm: elm@4808 {
Philip + compatible = ti,am33xx-elm;
Please drop the tab after compatible.
Other than that it looks goood.
Acked-by: Peter Korsgaard jac...@sunsite.dk
--
Bye, Peter Korsgaard
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: AM33XX: Add GPMC node
Philip == Philip Avinash avinashphi...@ti.com writes:
Philip From: Philip, Avinash avinashphi...@ti.com
Philip Add GPMC data node to AM33XX device tree file.
Philip Signed-off-by: Philip Avinash avinashphi...@ti.com
Philip ---
Philip arch/arm/boot/dts/am33xx.dtsi | 12
Philip 1 file changed, 12 insertions(+)
Philip diff --git a/arch/arm/boot/dts/am33xx.dtsi
b/arch/arm/boot/dts/am33xx.dtsi
Philip index eaef5e7..f4209d8 100644
Philip --- a/arch/arm/boot/dts/am33xx.dtsi
Philip +++ b/arch/arm/boot/dts/am33xx.dtsi
Philip @@ -393,5 +393,17 @@
Philipti,hwmods = elm;
Philipstatus = disabled;
Philip};
Philip +
Philip + gpmc: gpmc@5000 {
Philip + compatible = ti,am3352-gpmc;
Philip + ti,hwmods = gpmc;
Philip + reg = 0x5000 0x2000;
Philip + interrupts = 100;
Philip + num-cs = 8;
Next to Jan's comment about am335x having 7 cs signals, I just realized
the difference in compatible string between the gpmc and elm. The gpmc
refers to a real device (which is afaik how it should be done), but the
elm compatible is simply ti,am33xx-elm.
Presumably it should have been ti,am3352-elm in the binding instead?
Other than that it looks fine.
Acked-by: Peter Korsgaard jac...@sunsite.dk
--
Bye, Peter Korsgaard
--
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 07/10] ARM: OMAP5: clock data: Add OMAP54XX full clock tree and headers
Hi Santosh, I have push under the omap-audio gitorious two patches on top of your series. One for adding the ABE DPLL and a second for the remove of Audio DMA addresses. https://gitorious.org/omap-audio/linux-audio/commits/base/omap5_es2_data I will try to check Display tomorrow. Sebastien On 01/21/2013 03:31 PM, Santosh Shilimkar wrote: On Monday 21 January 2013 07:57 PM, Sebastien Guiriec wrote: Hi Santosh, I check the tree with Audio and it is working. Just a comment for the addition of ABE DPLL locking like for OMAP4. Excellent. Can you send the update please? I will fold that in. Regards santosh -- 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: musb: fix context save over suspend.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 21 Jan 2013 13:38:59 +0200 Igor Grinberg grinb...@compulab.co.il
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Neil,
On 01/21/13 11:28, NeilBrown wrote:
The standard suspend sequence involves runtime_resuming
devices before suspending the system.
So just saving context in runtime_suspend and restoring it
in runtime resume isn't enough. We must also save in suspend
and restore in resume.
Without this patch, and OMAP3 system with off_mode enabled will find
the musb port non-functional after suspend/resume. With the patch it
works perfectly.
Hmmm... Some time ago, this has been removed in
5d193ce8 (usb: musb: PM: fix context save/restore in suspend/resume path)
Am I missing something? Or things changed and now this patch is correct?
Hi Igor,
thanks for alerting me to that patch does anyone else get the feeling
that power management to too complex to be understood by a mere human?
That commit (5d193ce8) suggests that the musb-hdrc device is an
'omap_device', or maybe has a PM domain set to something else.
However it isn't/doesn't. dev-pm_domain is NULL. So no PM domain layer
will ever call the musb_core musb_runtime_suspend/resume.
The parent device - musb-omap2430 - is an omap device, does have pm_domain
set, and does have its omap2430_runtime_suspend/resume called for system
suspend and so the context for that device is saved and restored.
However that doesn't help the context for musb-hdrc.
Whether musb ever was an omap_device is beyond my archaeological skills to
determine.
Kevin: Was musb-hdrc ever a device with a pm_domain? or was it only ever
the various possible parents that had domains?
Are you able to defend your earlier patch in today's kernel? It
certainly causes my device not to work properly.
Thanks,
NeilBrown
Signed-off-by: NeilBrown ne...@suse.de
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index fd34867..b6ccc02 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2225,6 +2225,7 @@ static int musb_suspend(struct device *dev)
}
spin_unlock_irqrestore(musb-lock, flags);
+ musb_save_context(musb);
return 0;
}
@@ -2234,6 +2235,8 @@ static int musb_resume_noirq(struct device *dev)
* unless for some reason the whole soc powered down or the USB
* module got reset through the PSC (vs just being disabled).
*/
+ struct musb *musb = dev_to_musb(dev);
+ musb_restore_context(musb);
return 0;
}
- --
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQ/SjTAAoJEBDE8YO64EfaHrsP/2bl4rP6L/tWLSZ+rNEdz6B+
Qo+HVOhnTVsOxgWbbd5VrfhE28jLoFGMslrLuI+geeCcJ1zgwNsahG9C11bygyfu
54hQgkmaxDJPDKAlalcy7VK9C6tOTgQV5iSbuRlemttK879dTrb+33zP6idn5+zK
kxptY38fpmyojnl8gJiVa6Plik/apQcVr+GIx8CMwj+YQC5vkdg7cUEWyngfyk2C
W0U4NceroS8NSjRbcFV3V6Q912TVjKzl+B2yxVD0OBaSK4BpHEncDBXiVx8APq87
4nDeBB5gDXi1rtN3YjcfDaFu0me5qzpYc3JFFidvdLTdXIdvxDzjHgMqsZB8ZBYC
R0e5PtIw/62I90d63JkXZXVRTB7JeZsGfZFY2R7MxBab9or8zz0OyYwGWoW63vzH
oFrwmAkWoD0IEKcfc8+dd99eicgZrmQL6FDWrEMsX+RS34LRtVU30SVAudRhY+CR
MhNCjKyFySwx7wqkGgJl1ECl0Y6U4ua0v4bv7kdE6eyrgbQIkiGliSJ7DhWBPcP6
iMIOTwC7+LwPYP/MX2uYR3DXDfI0XwiqdtyzhD9LJe4PRol8zjozS2j0Y7FriItw
jFqsgCgwDc9j8ufcpXf5ZynJYnlCG0iLuAPEUugZot83/CpxgU++A8cuHqUrOnhH
76L95rflUTkpiQ76ffP7
=jqXb
-END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iQIVAwUBUP21WDnsnt1WYoG5AQIQlQ/+LlXi1ZRXKtO/oj/u4iqs7DL8PNcZX6C7
j7Rrx8nxd2C15pEnxvOYIrojLTrXqz3bgE9NmBvYOYY+dj2/+CaS7RJsTR0gYJi0
AMkLT9k6+edUJ79KtIRmeqbnPEnujOWHkBdg2dLrm4PpYmGUmc8VGeE3+mh3La97
ssZm4gYbip6TPzB4MdvTbhkxbEXJidOcgBJrsdTvMXB8HkZ30Wq6/YELtYoYNpZo
rn+CbQo5Dd0bUb8fQ3Fd5unfXqx5N5txBslwK8JgSA3L7l96d3+q9UOfBg/PsUJJ
WrnFahv11lypajHtnCnXb3z+TsGgV4v46aUZ4Yk+tkwVv81nbORHTRGoaLReRMG2
Sii/xYeugOuhnJI//07yWrnLfunFbJJyHmfZARz/6kKNoIPrZwRDmVeO3+Iu/39R
zmwvJDTqONwenXnZEmxqrON0E/Y8V6hdNlGZdFYIypJr/Ym2rp+R+qcRyEwQxAYi
7h1mACvXE7tYCCoBi+fN5hFaF2VQeN1QqJMTimQjqnkgaI2jQ4Zm7zMCUKREhGPu
3TTvOwuFGM+bwb2eKsW+4zSzebdepXaNjSPCmHSKU++5SVcOMNiZyKlrvoW8znM4
/1Ea+3CmkHqAhmja5Fly4NYL2fdy/NhfIqZI2yIrTAG58iIankQjBHysqAcGrvQp
TplHj7osO40=
=G91I
-END PGP SIGNATURE-
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±¢f©{ayº ÊÚë,j¢f£¢·hàz¹ ®w¥¢¸
¢·¦j:+v¨wèjØm¶ÿ¾«êçzZ+ùÝ¢jú!¶i
Re: [PATCH 13/15] drivers/usb/musb/omap2430.c: adjust duplicate test
On 21-01-2013 17:02, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Delete successive tests to the same location. Data is the just previously
allocated and tested value. Test the result of the allocation made here
instead.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@s exists@
local idexpression y;
expression x,e;
@@
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
... when != \(y = e\|y += e\|y -= e\|y |= e\|y = e\|y++\|y--\|y\)
when != \(XT_GETPAGE(...,y)\|WMI_CMD_BUF(...)\)
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
The previous code could be further simplified by removing the
initializations of ret to -ENOMEM, as is absent in this case. But that is
probably for another patch.
I've already sent such patch and Felipe has queued it.
drivers/usb/musb/omap2430.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index da00af4..533c4fd 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -545,7 +545,7 @@ static int omap2430_probe(struct platform_device *pdev)
}
config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
- if (!data) {
+ if (!config) {
Same about this change. You're a bit late this time. :-)
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: [PATCH 2/2] ARM: OMAP2+: omap2plus_defconfig: enable CMA allocator
On Wed, Dec 19, 2012 at 1:33 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: The OMAP framebuffer driver now uses the standard dma allocator instead of the (now removed) omap specific vram allocator. Enable the Contiguous Memory Allocator by default to allow large dma memory buffers allocation. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- arch/arm/configs/omap2plus_defconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index da530a0..dc4789e 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -64,6 +64,7 @@ CONFIG_MAC80211=m CONFIG_MAC80211_RC_PID=y CONFIG_MAC80211_RC_DEFAULT_PID=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug +CONFIG_CMA=y CONFIG_CONNECTOR=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y -- Hi Tony, Are you considering adding this patch and ARM: OMAP2+: omap2plus_defconfig: enable TFP410 chip support [1] to the 3.8-rc series or 3.9? These patches have been acked by Tomi and are necessary to have framebuffer video working on many OMAP3 based boards. Thanks a lot and best regards, Javier [1]: https://patchwork.kernel.org/patch/1895451/ -- 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.8-rc4
Hi guys, Regarding the AM33xx test failures with appended DTBs, it would be very helpful if especially the TI people could try reproducing the problem. Otherwise it's going to cause problems with merging any new AM33xx patches, since I won't be able to test them without additional work. Plus, this is something that used to work up until d01e4afd, so something isn't right. You'll need to use the bootloader that TI originally shipped with the BeagleBones: U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) This is because many folks don't replace their bootloader. I do plan to add a test with a recent version of u-boot, but the kernel should not be dependent on the bootloader in any way to work correctly. If it is, then we need to document what u-boot version the kernel started to work with. The Kconfig that I use is here: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only It's possible that there's something wrong with the Kconfig. It's basically just omap2plus_defconfig, but with all OMAP support for non-AM33xx turned off, and with the appended DTB and ATAG compatibility options turned on. Let's try to do this ASAP. That way, if it's some bootloader dependency or bug in the kernel, some fix can be merged during the v3.8-rc series, which is rapidly drawing to a close. - 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 1/3] mtd nand : onfi need to be probed in 8 bits mode
Hi Matthieu,
On Wed, 16 Jan 2013, Paul Walmsley wrote:
On Wed, 16 Jan 2013, Matthieu CASTET wrote:
Paul Walmsley a écrit :
On Wed, 2 Jan 2013, Matthieu CASTET wrote:
which did not get merged because Tony requested that it should be
based on top of his cleanup work (which takes priority over adding new
features):
http://thread.gmane.org/gmane.linux.ports.arm.omap/88550/focus=88549
Could you please update this omap3 nand : use NAND_BUSWIDTH_AUTO patch
on v3.8-rc2 and repost?
Do you know when this patchset will be submited to mtd ?
I think I will wait it is merged in mtd and redo my patch after that.
As far as I know, it was merged during the v3.8 merge window. So it's
already in mainline.
Any progress on updating and resending your omap3 nand : use
NAND_BUSWIDTH_AUTO patch? We're in danger of missing the 3.9 merge
window if it takes too much longer.
- Paul
OMAP4 PM bootloader dependency problems
Hi Tero, Rajendra, Santosh, As we've discussed, there are known bootloader dependencies with the OMAP4 PM retention idle code, introduced in v3.8. Boards booted with u-boot versions even as recent as 2011 won't enter retention idle correctly; for example: http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/pm/4430es2panda/4430es2panda_log.txt The right thing for you all to do is what was done for OMAP3: to add code to correctly reset and initialize these on-chip devices. However, since it's already late in the v3.8-rc cycle, this seems unlikely to happen in time for the v3.8 release -- and that's assuming that you guys are working on this, which I'm unsure of. Barring that, what I'd like to see is a patch for v3.8-rc fixes that adds a warning, printed to the kernel console, during boot. The warning should state that the OMAP4 PM code only works with certain bootloaders, and should identify the minimum u-boot release needed for OMAP4 full-chip retention idle to work. Could you guys please put that together ASAP so we can get it merged during the v3.8-rc cycle? Otherwise we're going to frustrate users when people expect PM to work correctly with their existing bootloaders. The least we can do for them is warn them that problems exist. This should take priority over any new features. - Paul -- Forwarded message -- Date: Mon, 7 Jan 2013 18:40:02 + (UTC) From: Paul Walmsley p...@pwsan.com To: madhusudhan.go...@elektrobit.com Cc: linux-omap@vger.kernel.org, t-kri...@ti.com, rna...@ti.com Subject: RE: Querry on UART wakeup on Linux 3.8-rc1 Hi, On Sun, 6 Jan 2013, madhusudhan.go...@elektrobit.com wrote: Could someone point me if it has been working in any of the releases ? Serial wakeup from retention suspend seems to work on the OMAP4460 Panda-ES here as of v3.8-rc1, with a really recent U-boot[*]: http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/pm/4460pandaes/4460pandaes_log.txt http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/README.txt (There are some warnings present from the power state debugging code, so there's probably something that could use a closer look.) The problem is, you need a really recent bootloader for this to work. This is because the mainline kernel is missing code to idle several on-chip devices (IVAHD, DSP, etc.). This can be seen with the OMAP4430 boot logs: http://www.pwsan.com/omap/testlogs/test_v3.8-rc1/20121228031713/pm/4430es2panda/4430es2panda_log.txt That board is running an older bootloader - from July 2012! The hope is that some of the folks still working for TI can post the appropriate reset and idle code for these devices. Or at least, we'd better add a console warning to the OMAP44xx PM init code that warns about the bootloader dependencies. Any comments from the TI folks here? - Paul Thanks, Gowda -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] Sent: 01. tammikuuta 2013 22:08 To: linux-omap@vger.kernel.org Subject: Querry on UART wakeup on Linux 3.8-rc1 Hi, I tried to wakeup OMAP430 ES2.1 Panda from static suspend retention using console uart2, it doesn't wakeup. But could configure GPIO_121 button to wake up from retention fine. On the serial uart side I have manually enabled wakeup by echo enabled /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup I could see the wakeup enable bit (114) of uart irrx pad register is being set properly before it does static suspend fine. Should I need to do any more thing to get it work? Thanks, Gowda -- 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 -- 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: reset handling in am335x hwmod data
Hi
On Thu, 10 Jan 2013, Peter Korsgaard wrote:
Paul == Paul Walmsley p...@pwsan.com writes:
Paul Probably the DTS is the right place, since this is a board- and
Paul bootloader-specific quirk. The original intention was to allow
Paul board files to set this HWMOD_INIT_NO_RESET flag themselves - see
Paul mach-omap2/ omap_hwmod.c:omap_hwmod_no_setup_reset(). But since
Paul we've deprecated the board files, the DT data seems like the
Paul right place.
Paul It probably shouldn't be a GPIO-specific property. Other devices
Paul like DSS will also need some kind of 'no-init-reset' property,
Paul since on many commercial devices, it's expected that some kind of
Paul splash screen will be presented by the bootloader and stay on
Paul during the boot process.
I tried changing omap_device_build_from_dt() to call
omap_hwmod_no_setup_reset() on the corresponding hwmod if a
ti,no-init-reset was present, but that doesn't work as the hwmod reset
happens quite a bit earlier (in omap_hwmod_setup_all()). Do you have
idea how I could work around this or is that the future reset change you
referred to above?
For AM33xx, since there's no board file, you'll need to modify the kernel
source. You can set the HWMOD_INIT_NO_RESET flag on the GPIO IP blocks
that should have their reset skipped, in
mach-omap2/omap_hwmod_33xx_data.c.
In the medium term, we'll deal with this with the late reset change that
was described earlier. Here's an experimental patch in case you want to
play with it, which I wouldn't recommend since it has known flaws, and
also we're not yet at the point where we can switch to late reset in
mainline yet, mostly because folks have been more interested in pushing
new features than doing cleanup work.
- Paul
From 109751e4621f692466f6156e10c3647317f51c9c Mon Sep 17 00:00:00 2001
From: Paul Walmsley p...@pwsan.com
Date: Sun, 20 Jan 2013 21:35:00 -0700
Subject: [PATCH] EXPERIMENTAL: ARM: OMAP2+: hwmod: move device reset later in
the boot
EXPERIMENTAL: is full of bugs; also requires hwmod device topology patch.
XXX Fix documentation around omap_hwmod_init_*()
XXX can init be moved to device enable as well?
---
arch/arm/mach-omap2/io.c | 25 +-
arch/arm/mach-omap2/omap_hwmod.c | 626 +-
arch/arm/mach-omap2/omap_hwmod.h | 24 +-
arch/arm/mach-omap2/timer.c |4 +-
4 files changed, 299 insertions(+), 380 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 2c3fdd6..a170c98 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -359,23 +359,20 @@ static int __init _omap2_init_reprogram_sdrc(void)
return v;
}
-static int _set_hwmod_postsetup_state(struct omap_hwmod *oh, void *data)
-{
- return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
-}
-
static void __init omap_hwmod_init_postsetup(void)
{
- u8 postsetup_state;
-
- /* Set the default postsetup state for all hwmods */
-#ifdef CONFIG_PM_RUNTIME
- postsetup_state = _HWMOD_STATE_IDLE;
-#else
- postsetup_state = _HWMOD_STATE_ENABLED;
+#ifndef CONFIG_PM_RUNTIME
+ /*
+* Until we have a real OMAP bus, and the drivers can enable
+* and disable the devices themselves, we're stuck with
+* runtime PM as a device enable/disable mechanism. But if
+* runtime PM has been configured out, then we're left with no
+* way to control the device integration, so just enable
+* everything so the kernel doesn't crash when it tries to
+* touch a device that hasn't been enabled.
+*/
+ omap_hwmod_enable_all();
#endif
- omap_hwmod_for_each(_set_hwmod_postsetup_state, postsetup_state);
-
omap_pm_if_early_init();
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4653efb..52578a7 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1542,13 +1542,12 @@ static int _init_clkdm(struct omap_hwmod *oh)
* _init_clocks - clk_get() all clocks associated with this hwmod. Retrieve as
* well the clockdomain.
* @oh: struct omap_hwmod *
- * @data: not used; pass NULL
*
* Called by omap_hwmod_setup_*() (after omap2_clk_init()).
* Resolves all clock names embedded in the hwmod. Returns 0 on
* success, or a negative error code on failure.
*/
-static int _init_clocks(struct omap_hwmod *oh, void *data)
+static int _init_clocks(struct omap_hwmod *oh)
{
int ret = 0;
@@ -1879,12 +1878,15 @@ static int _ocp_softreset(struct omap_hwmod *oh)
!(oh-class-sysc-sysc_flags SYSC_HAS_SOFTRESET))
return -ENOENT;
+ /* XXX Check some flag to ensure clocks enabled etc */
+#if 0
/* clocks must be on for this operation */
if (oh-_state != _HWMOD_STATE_ENABLED) {
pr_warn(omap_hwmod: %s: reset can only be entered from enabled
state\n,
oh-name);
Re: [PATCH 0/2] OMAP3 ISP: Simplify clock usage
On Mon, 21 Jan 2013, Laurent Pinchart wrote: OK. The omap3isp patch can go through Paul's tree as well, it won't conflict with other changes to the driver in this merge window. Paul, can you take both patches together ? If so I'll send you a pull request. Yes I'll take them, as long as they won't cause conflicts outside of arch/arm/mach-omap2. Otherwise the OMAP3 ISP patch should wait until the early v3.9-rc integration fixes timeframe. - 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 6/6] OF: Introduce DT overlay support.
On Fri, Jan 04, 2013 at 09:31:10PM +0200, Pantelis Antoniou wrote:
Introduce DT overlay support.
Using this functionality it is possible to dynamically overlay a part of
the kernel's tree with another tree that's been dynamically loaded.
It is also possible to remove node and properties.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
Documentation/devicetree/overlay-notes.txt | 179 +++
drivers/of/Kconfig | 10 +
drivers/of/Makefile| 1 +
drivers/of/overlay.c | 831
+
include/linux/of.h | 107
5 files changed, 1128 insertions(+)
create mode 100644 Documentation/devicetree/overlay-notes.txt
create mode 100644 drivers/of/overlay.c
diff --git a/Documentation/devicetree/overlay-notes.txt
b/Documentation/devicetree/overlay-notes.txt
new file mode 100644
index 000..5289cbb
--- /dev/null
+++ b/Documentation/devicetree/overlay-notes.txt
@@ -0,0 +1,179 @@
+Device Tree Overlay Notes
+-
+
+This document describes the implementation of the in-kernel
+device tree overlay functionality residing in drivers/of/overlay.c and is a
+companion document to Documentation/devicetree/dt-object-internal.txt[1]
+Documentation/devicetree/dynamic-resolution-notes.txt[2]
+
+How overlays work
+-
+
+A Device Tree's overlay purpose is to modify the kernel's live tree, and
+have the modification affecting the state of the the kernel in a way that
+is reflecting the changes.
Um.. I'm having a great deal of trouble parsing that sentence.
+Since the kernel mainly deals with devices, any new device node that result
+in an active device should have it created while if the device node is either
+disabled or removed all together, the affected device should be deregistered.
+
+Lets take an example where we have a foo board with the following base tree
+which is taken from [1].
+
+ foo.dts
-
+ /* FOO platform */
+ / {
+ compatible = corp,foo;
+
+ /* shared resources */
+ res: res {
+ };
+
+ /* On chip peripherals */
+ ocp: ocp {
+ /* peripherals that are always instantiated */
+ peripheral1 { ... };
+ }
+ };
+ foo.dts
-
+
+The overlay bar.dts, when loaded (and resolved as described in [2]) should
+
+ bar.dts
-
+/plugin/;/* allow undefined label references and record them */
+/ {
+ /* various properties for loader use; i.e. part id etc. */
+ fragment@0 {
+ target = ocp;
+ __overlay__ {
+ /* bar peripheral */
+ bar {
+ compatible = corp,bar;
+ ... /* various properties and child nodes */
+ }
+ };
+ };
+};
+ bar.dts
-
+
+result in foo+bar.dts
+
+ foo+bar.dts
-
+ /* FOO platform + bar peripheral */
+ / {
+ compatible = corp,foo;
+
+ /* shared resources */
+ res: res {
+ };
+
+ /* On chip peripherals */
+ ocp: ocp {
+ /* peripherals that are always instantiated */
+ peripheral1 { ... };
+
+ /* bar peripheral */
+ bar {
+ compatible = corp,bar;
+ ... /* various properties and child nodes */
+ }
+ }
+ };
+ foo+bar.dts
-
+
+As a result of the the overlay, a new device node (bar) has been created
+so a bar platform device will be registered and if a matching device driver
+is loaded the device will be created as expected.
Hrm. This all seems rather complicated. Maybe it needs to be, but
I'm not entirely convinced yet.
One other point - both of these patches are assuming that the overlay
is in the live tree format, but it still needs a bunch of extra
mangling. Would it simplify things to just go straight from the
overlay in flat tree form to modifications to the system-wide live
tree.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
Re: [PATCH 5/6] OF: Introduce Device Tree resolve support.
On Mon, Jan 21, 2013 at 12:59:15PM +0200, Pantelis Antoniou wrote: Hi David On Jan 21, 2013, at 6:48 AM, David Gibson wrote: On Fri, Jan 04, 2013 at 09:31:09PM +0200, Pantelis Antoniou wrote: Introduce support for dynamic device tree resolution. Using it, it is possible to prepare a device tree that's been loaded on runtime to be modified and inserted at the kernel live tree. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- .../devicetree/dynamic-resolution-notes.txt| 25 ++ drivers/of/Kconfig | 9 + drivers/of/Makefile| 1 + drivers/of/resolver.c | 394 + include/linux/of.h | 17 + 5 files changed, 446 insertions(+) create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt create mode 100644 drivers/of/resolver.c diff --git a/Documentation/devicetree/dynamic-resolution-notes.txt b/Documentation/devicetree/dynamic-resolution-notes.txt new file mode 100644 index 000..0b396c4 --- /dev/null +++ b/Documentation/devicetree/dynamic-resolution-notes.txt @@ -0,0 +1,25 @@ +Device Tree Dynamic Resolver Notes +-- + +This document describes the implementation of the in-kernel +Device Tree resolver, residing in drivers/of/resolver.c and is a +companion document to Documentation/devicetree/dt-object-internal.txt[1] + +How the resolver works +-- + +The resolver is given as an input an arbitrary tree compiled with the +proper dtc option and having a /plugin/ tag. This generates the +appropriate __fixups__ __local_fixups__ nodes as described in [1]. + +In sequence the resolver works by the following steps: + +1. Get the maximum device tree phandle value from the live tree + 1. +2. Adjust all the local phandles of the tree to resolve by that amount. +3. Using the __local__fixups__ node information adjust all local references + by the same amount. +4. For each property in the __fixups__ node locate the node it references + in the live tree. This is the label used to tag the node. +5. Retrieve the phandle of the target of the fixup. +5. For each fixup in the property locate the node:property:offset location + and replace it with the phandle value. Hrm. So, I'm really still not convinced by this approach. First, I think it's unwise to allow overlays to change essentially anything in the base tree, rather than having the base tree define sockets of some sort where things can be attached. One could say that the labels define the sockets. It's not just things to be attached, properties might have to change, or something more complex, as we've found out in practice. Hrm. I know a number of these have come up previously in that big thread, but can you summarise some of these cases here. If things need modification in the base tree that still seems to me like the base tree hasn't properly described the socket arrangement (I realise that allowing such descriptions may require extensions to some of our device tree conventions). As far as the unwise part, a good deal of care has been taken so that people that don't use the overlay functionality have absolutely no overhead, or anything modified in the way they use DT. Yeah, that's not what I'm concerned about. I'm concerned about hard to debug problems because some subtle change in the base tree or the overlay or both causes the overlay to alter something in the base tree it really shouldn't. Second, even allowing overlays to change anything, I don't see a lot of reason to do this kind of resolution within the kernel and with data stored in the dtb itself, rather than doing the resolution in userspace from an annotated overlay dts or dtb, then inserting the fully resolved product into the kernel. In either case, the overlay needs to be constructed with pretty intimate knowledge of the base tree. Fair enough, but that's one more thing of user-space crud to drag along, which will get enabled pretty late in the boot sequence. Meaning a whole bunch of devices, like consoles, and root filesystems on the devices that need an overlay to operate won't work easily enough. Hrm. But doesn't your scheme already require userspace to identify the hardware and load the overlay? So why is having it resolve the overlay significantly harder? AFAICT devices wanted early can be handled in several possible ways without having the resolved in kernel: an initramfs is the most obvious, but for things you want really early, it should be possible to do the resolution from the platform's bootloader update tool - so the pre-resolved overlay gets bundled with the kernel/initrd/whatever to get fired up from the bootloader. That said, I have some implementation comments below.
Re: [PATCH 3/4] ARM: mach-omap2: apply the errata at run time rather
On Mon, Jan 21, 2013 at 19:22:37 +0100, Tony Lindgren wrote: * srinidhi kasagar srinidhi.kasa...@stericsson.com [130121 05:19]: Forgot to complete the subject and add the description? No :) It has the subject, but description is intentionally skipped because subject has all the meaning and it is a part of the series of patches I sent.. regards/srinidhi -- 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 3/4] ARM: mach-omap2: apply the errata at run time rather
On Tuesday 22 January 2013 11:31 AM, Srinidhi Kasagar wrote: On Mon, Jan 21, 2013 at 19:22:37 +0100, Tony Lindgren wrote: * srinidhi kasagar srinidhi.kasa...@stericsson.com [130121 05:19]: Forgot to complete the subject and add the description? No :) It has the subject, but description is intentionally skipped because subject has all the meaning and it is a part of the series of patches I sent.. ARM: mach-omap2: apply the errata at run time rather Subject doesn't have all the meaning till you read the series ;) Like, this is Pl310 XYZ errata etc. Anyway once you sort out the concerns from RMK and with a few lines of description on subject patch, you can add my ack on OMAP patches. Thanks a lot for doing this. Regards, Santosh -- 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 3/4] ARM: mach-omap2: apply the errata at run time rather
On Tue, Jan 22, 2013 at 07:43:24 +0100, Santosh Shilimkar wrote: On Tuesday 22 January 2013 11:31 AM, Srinidhi Kasagar wrote: On Mon, Jan 21, 2013 at 19:22:37 +0100, Tony Lindgren wrote: * srinidhi kasagar srinidhi.kasa...@stericsson.com [130121 05:19]: Forgot to complete the subject and add the description? No :) It has the subject, but description is intentionally skipped because subject has all the meaning and it is a part of the series of patches I sent.. ARM: mach-omap2: apply the errata at run time rather Subject doesn't have all the meaning till you read the series ;) Like, this is Pl310 XYZ errata etc. Anyway once you sort out the concerns from RMK and with a few lines of description on subject patch, you can add my ack on OMAP patches. thanks, the description part will be fixed. Can you check RMK's comment on set_debug patch, patch 1/4? I need your comment on that to roll it over because set_debug is something which is OMAP specific.. Thanks a lot for doing this. Regards, Santosh -- 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
