Re: [PATCH v3 4/5] dma: cppi41: only allocate descriptor memory once
On 10/01/2013 06:57 PM, Daniel Mack wrote: That sound's like a good idea. Everything that make the driver smaller and easier to understand is certainly a good thing :) So we can drop this patch favor of your cleanup. However, I appreciate if you did it on top of the second round of patches I sent today please, because my resume() implementation uses DESCS_AREAS as well. Okay, no problem. Let me look at those and once they are merged I do the cleanup. Thanks, Daniel Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: musb: am35x: use SIMPLE_DEV_PM_OPS
On 30.09.2013 18:25, Felipe Balbi wrote: On Fri, Sep 27, 2013 at 08:47:10PM +0200, Daniel Mack wrote: So are you happy with this v2? It's just a cosmetic cleanup after all ... I can't see v2 anywhere... The only version I have is the one with DEV_PM_OPS still in it. Seen them this time? http://marc.info/?l=linux-usbm=138056774812520w=2 http://marc.info/?l=linux-usbm=138056774612517w=2 http://marc.info/?l=linux-usbm=138056775012522w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] dma: cppi41: move -EAGAIN in tear_down
* Daniel Mack | 2013-10-01 15:31:11 [+0200]:
In cppi41_tear_down_chan(), bail out earlier in case td_seen is unset
instead of popping another descriptor when td_desc_seen is also unset.
My system ran into WARN() condition multiple times when
cppi41_tear_down_chan() was called for channels that had all of
td_queued, td_seen and td_seen set to false.
Which one?
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/dma/cppi41.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 7747bf7..6decf34 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -586,6 +586,9 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
}
c-td_seen = 1;
}
+
+ if (c-td_retry)
+ return -EAGAIN;
So you return right away since the retry counter should be 0 here. And
then you want to get the TDDOWN bit set and retry. Hmmm.
Let me answer to you 0/3 on this.
}
if (!c-td_desc_seen) {
desc_phys = cppi41_pop_desc(cdd, c-q_comp_num);
@@ -606,8 +609,6 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
* descriptor before the TD we fetch it from enqueue, it has to be
* there waiting for us.
*/
- if (!c-td_seen c-td_retry)
- return -EAGAIN;
WARN_ON(!c-td_retry);
if (!c-td_desc_seen) {
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 03:19 PM, Balaji T K wrote: Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. Right. WLAN is supposed to use MMC5. But if you don't have Luca's patches, can you please ensure that those pins are muxed either as safe mode or as MMC5? Default seems to be safe mode, but you should cross check. Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP Shouldn't it be PIN_OUTPUT? Still I have no clue why it works on 4430 and not on 4460. Are you using the same bootloader image on both boards? if you are using vaux1, can you check the voltage levels, From dmesg you attached, vaux1 is set to 1.8V on omap4430 and to 2.8V on OMAP4460 4430 [2.425750] VAUX1_6030: 1000 -- 3000 mV at 1800 mV 4460 [2.244262] VAUX1_6030: 1000 -- 3000 mV at 2800 mV Nice catch. Not sure whether this is an issue, but worth looking into. Can you also check with MMC_DEBUG enabled for any clues. building 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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 00/15] Device Tree schemas and validation
On Tue, Oct 01, 2013 at 10:17:53AM -0500, Jon Loeliger wrote: Hi Rob, On 01/10/2013 15:17, Rob Herring wrote: On 10/01/2013 03:06 AM, Benoit Cousson wrote: + more DT maintainers folks Hi all, I know this is mostly boring user space code, but I was expecting a little bit of comments about at least the bindings syntax:-( I'd like to know if this is the right direction and if it worth pursuing in that direction. The idea was to have at least some base for further discussion during ARM KS 2013. I feel alone :-( If you have any comment, go ahead! Benoit, Sorry, I meant to ask earlier but forgot. Shouldn't this development be based on the upstream DTC repository and not the in-kernel copy of the DTC? Absolutely. Please work against upstream dtc. -- 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 pgpvQSOHC9Pwv.pgp Description: PGP signature
Re: [PATCH 3/3] dma: cppi41: move -EAGAIN in tear_down
Hi Sebastian, On 02.10.2013 10:29, Sebastian Andrzej Siewior wrote: * Daniel Mack | 2013-10-01 15:31:11 [+0200]: diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c index 7747bf7..6decf34 100644 --- a/drivers/dma/cppi41.c +++ b/drivers/dma/cppi41.c @@ -586,6 +586,9 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c) } c-td_seen = 1; } + +if (c-td_retry) +return -EAGAIN; So you return right away since the retry counter should be 0 here. And then you want to get the TDDOWN bit set and retry. Hmmm. Let me answer to you 0/3 on this. Thanks a lot for having a look! As I'm going to be off for a couple of days now, and only be able to read my mails sporadically, maybe you can also try the musb suspend functions on your hardware. I'll give you a quick wrap-up of how my test setup looks like. On an AM33xx board, I have a host-only (type A) connector with a USB memory stick plugged in. The relevant config settings are: CONFIG_USB_MUSB_HDRC=m # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_GADGET is not set CONFIG_USB_MUSB_DUAL_ROLE=y # CONFIG_USB_MUSB_TUSB6010 is not set # CONFIG_USB_MUSB_OMAP2PLUS is not set # CONFIG_USB_MUSB_AM35X is not set CONFIG_USB_MUSB_DSPS=m # CONFIG_USB_MUSB_UX500 is not set CONFIG_USB_MUSB_AM335X_CHILD=m # CONFIG_MUSB_PIO_ONLY is not set CONFIG_USB_TI_CPPI41_DMA=y CONFIG_TI_CPPI41=y Once the system is booted up and the USB media is detected, I send the system to sleep mode with cat mem /sys/power/state. After wakeup, I access the media by mounting and unmounting it once, then send the system back to sleep. Repeating the above cycle multiple times will sooner or later make the warning kick in without the discussed patch. Sometimes it happened on first try, sometimes it took me up to ~20 cycles to make it happen. I'd be curious whether you see the same behavior on your board as well, and whether the fix work for you, too. For reference, I just pushed my current working tree here: https://github.com/zonque/linux/tree/am33xx-3.12 Thanks, Daniel -- 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 00/15] Device Tree schemas and validation
Hi Jon, On 01/10/2013 17:17, Jon Loeliger wrote: Hi Rob, On 01/10/2013 15:17, Rob Herring wrote: On 10/01/2013 03:06 AM, Benoit Cousson wrote: + more DT maintainers folks Hi all, I know this is mostly boring user space code, but I was expecting a little bit of comments about at least the bindings syntax:-( I'd like to know if this is the right direction and if it worth pursuing in that direction. The idea was to have at least some base for further discussion during ARM KS 2013. I feel alone :-( If you have any comment, go ahead! Benoit, Sorry, I meant to ask earlier but forgot. Shouldn't this development be based on the upstream DTC repository and not the in-kernel copy of the DTC? Eventually, yes, but here the main point is to discuss the schema that will be used to defined bindings. In that case, the DTC patches code are mostly a proof of concept using the Linux kernel as example. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] dma: cppi41: more suspend/resume patches
* Daniel Mack | 2013-10-01 15:31:08 [+0200]: Patch #3, however, gives me headaches. I can't fully explain what's going on, but I can tell for sure that if fixes a problem that I stared on for many hours. The problem is that on resume, the musb core will detect that some of the suspended USB devices' endpoints are stalled. Which is something that is unrelated to the dma driver, it just seems to be an expected condition. That, however, makes the musb core call cppi41_dma_channel_abort() - cppi41_tear_down_chan(), which is an otherwise untravelled code path. When that function is called for a channel which has all of td_queued, td_seen and td_desc_seen set to FALSE, I'm always getting a warning like this: [ 17.105981] [ cut here ] [ 17.110861] WARNING: CPU: 0 PID: 122 at drivers/dma/cppi41.c:644 cppi41_dma_control+0x378/0x3f8 [cppi41]() This is WARN_ON(!cdd-chan_busy[desc_num]); at the end of cppi41_stop_chan() right? So you get the warning because you tried to stop a channel which was not busy. But then you should not be called at all because cppi41_dma_channel_abort() shouldn't call dma driver on idle channels. So it should complete at some point. Note that the line numbers don't match the current code in mainline due to some debugging code, but it should be clear where the warning comes from. With patch #3 applied, I made this problem go away, and I can suspend resume with all musb related drivers active just fine. The only issue I have is that I don't fully understand the reason, as it seems to me that my patch just changes the timing, and we're actually seeing a race condition here. Sebastian, can you give a comment on this? I'll post the musb patches that are necessary as well now, and I'd appreciate more testers here. How does your suspend resume thingy work? Is it completly shutdown i.e. powered off? According to you earlier patches I would assume so. In that case the request is not enqueued and there is nothing to be removed from the engine, right? With the change you somehow get an interrupt that cleans up that slot. If you trigger TD bits for a random channel you get atleast the teardown descriptor. But then you don't complain about the WARN_ON() about missing / wrong desc_phys. In general this works like this: - descriptor is busy / in progress. The TEAR-DOWN bits have to be set a few times. The hw returns the teardown descriptor and the descriptor that has been enqueued - descriptor is queued but not busy / in use Setting the TEAR-DOWN bit once seems to be enough. The hw returns _only_ the teardown descriptor. The transfer descriptor remains pushed onto the queue like it has been never consumed. A pop cleans it up, the complete queue is empty. (Warning: reading the queue counter leads to a pop! So checking if the queue counter increments after pushing something to it is a bad idea). The whole thing has been tested by manipulating the USB storage driver to enqueue more / less data then required by the protocol leading to a stall followed by an abort of the transfer. Let me re-do your suspend with the patches you made so far to check what is going on and if the normal transfer cancel is still working. Many thanks, Daniel Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 03/10] ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
Hi Tony,
On 09/24/2013 11:53 AM, Roger Quadros wrote:
The platform data bits can be inferred from the other members of
struct usbhs_phy_data. So get rid of the platform_data member.
Build the platform data for the PHY device in usbhs_init_phys() instead.
Signed-off-by: Roger Quadros rog...@ti.com
Could you please Ack this if OK?
cheers,
-roger
---
arch/arm/mach-omap2/board-omap3beagle.c |6 --
arch/arm/mach-omap2/usb-host.c | 11 ++-
arch/arm/mach-omap2/usb.h |1 -
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index f269184..8b9cd06 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -289,18 +289,12 @@ static struct regulator_consumer_supply
beagle_vsim_supply[] = {
static struct gpio_led gpio_leds[];
-/* PHY's VCC regulator might be added later, so flag that we need it */
-static struct usb_phy_gen_xceiv_platform_data hsusb2_phy_data = {
- .needs_vcc = true,
-};
-
static struct usbhs_phy_data phy_data[] = {
{
.port = 2,
.reset_gpio = 147,
.vcc_gpio = -1, /* updated in beagle_twl_gpio_setup */
.vcc_polarity = 1, /* updated in beagle_twl_gpio_setup */
- .platform_data = hsusb2_phy_data,
},
};
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index e83a6a4..78ac1c2 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -435,6 +435,7 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
struct platform_device *pdev;
char *phy_id;
struct platform_device_info pdevinfo;
+ struct usb_phy_gen_xceiv_platform_data nop_pdata;
for (i = 0; i num_phys; i++) {
@@ -455,11 +456,19 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
return -ENOMEM;
}
+ /* set platform data */
+ memset(nop_pdata, 0, sizeof(nop_pdata));
+ if (gpio_is_valid(phy-vcc_gpio))
+ nop_pdata.needs_vcc = true;
+ if (gpio_is_valid(phy-reset_gpio))
+ nop_pdata.needs_reset = true;
+ nop_pdata.type = USB_PHY_TYPE_USB2;
+
/* create a NOP PHY device */
memset(pdevinfo, 0, sizeof(pdevinfo));
pdevinfo.name = nop_name;
pdevinfo.id = phy-port;
- pdevinfo.data = phy-platform_data;
+ pdevinfo.data = nop_pdata;
pdevinfo.size_data =
sizeof(struct usb_phy_gen_xceiv_platform_data);
scnprintf(phy_id, MAX_STR, usb_phy_gen_xceiv.%d,
diff --git a/arch/arm/mach-omap2/usb.h b/arch/arm/mach-omap2/usb.h
index e7261eb..4ba2ae7 100644
--- a/arch/arm/mach-omap2/usb.h
+++ b/arch/arm/mach-omap2/usb.h
@@ -58,7 +58,6 @@ struct usbhs_phy_data {
int reset_gpio;
int vcc_gpio;
bool vcc_polarity; /* 1 active high, 0 active low */
- void *platform_data;
};
extern void usb_musb_init(struct omap_musb_board_data *board_data);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/10] ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes
Hi Tony,
On 09/24/2013 11:53 AM, Roger Quadros wrote:
The USB phy-nop nop driver expects the RESET line information
to be sent as a GPIO number via platform data. Adapt to that.
Signed-off-by: Roger Quadros rog...@ti.com
Need your Ack on this one as well.
cheers,
-roger
---
arch/arm/mach-omap2/usb-host.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 78ac1c2..10855eb 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -460,8 +460,7 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
memset(nop_pdata, 0, sizeof(nop_pdata));
if (gpio_is_valid(phy-vcc_gpio))
nop_pdata.needs_vcc = true;
- if (gpio_is_valid(phy-reset_gpio))
- nop_pdata.needs_reset = true;
+ nop_pdata.gpio_reset = phy-reset_gpio;
nop_pdata.type = USB_PHY_TYPE_USB2;
/* create a NOP PHY device */
@@ -483,14 +482,6 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int
num_phys)
usb_bind_phy(ehci-omap.0, phy-port - 1, phy_id);
- /* Do we need RESET regulator ? */
- if (gpio_is_valid(phy-reset_gpio)) {
- scnprintf(rail_name, MAX_STR,
- hsusb%d_reset, phy-port);
- usbhs_add_regulator(rail_name, phy_id, reset,
- phy-reset_gpio, 1);
- }
-
/* Do we need VCC regulator ? */
if (gpio_is_valid(phy-vcc_gpio)) {
scnprintf(rail_name, MAX_STR, hsusb%d_vcc, phy-port);
--
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: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On 10/01/2013 01:29 PM, Luca Coelho wrote: Hi, On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote: On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. I sent 2 patch series to add DT support for the on-board WLAN, but they were not applied, since there were some comments that required changes. I really don't have the time to revisit them now that I'm not with TI anymore, so I'm hoping someone else will pick them up at some point. I found this one in my email archive: [PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp Guess that is what you are referring to, right? Gr. AvS -- 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/3] dma: cppi41: move -EAGAIN in tear_down
On 10/02/2013 11:19 AM, Daniel Mack wrote: Hi Sebastian, Hi Daniel, On 02.10.2013 10:29, Sebastian Andrzej Siewior wrote: * Daniel Mack | 2013-10-01 15:31:11 [+0200]: Thanks a lot for having a look! As I'm going to be off for a couple of days now, and only be able to read my mails sporadically, maybe you can also try the musb suspend functions on your hardware. I'll give you a quick wrap-up of how my test setup looks like. On an AM33xx board, I have a host-only (type A) connector with a USB memory stick plugged in. The relevant config settings are: CONFIG_USB_MUSB_HDRC=m # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_GADGET is not set CONFIG_USB_MUSB_DUAL_ROLE=y # CONFIG_USB_MUSB_TUSB6010 is not set # CONFIG_USB_MUSB_OMAP2PLUS is not set # CONFIG_USB_MUSB_AM35X is not set CONFIG_USB_MUSB_DSPS=m # CONFIG_USB_MUSB_UX500 is not set CONFIG_USB_MUSB_AM335X_CHILD=m # CONFIG_MUSB_PIO_ONLY is not set CONFIG_USB_TI_CPPI41_DMA=y CONFIG_TI_CPPI41=y Once the system is booted up and the USB media is detected, I send the system to sleep mode with cat mem /sys/power/state. After wakeup, I access the media by mounting and unmounting it once, then send the system back to sleep. Okay. Going to sleep is probably easy, I need to figure out how to wakeup… Repeating the above cycle multiple times will sooner or later make the warning kick in without the discussed patch. Sometimes it happened on first try, sometimes it took me up to ~20 cycles to make it happen. Ah. Okay. I'd be curious whether you see the same behavior on your board as well, and whether the fix work for you, too. For reference, I just pushed my current working tree here: https://github.com/zonque/linux/tree/am33xx-3.12 Thanks. Thanks, Daniel Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] pwm-backlight: Use an optional power supply
On Tue, Oct 01, 2013 at 11:31:27PM +0200, Thierry Reding wrote: On Tue, Oct 01, 2013 at 02:59:43PM -0600, Stephen Warren wrote: OK, hopefully it (the regulator core) complains about the missing DT property though; I assume you're using regulator_get() not regulator_get_optional(), since the supply really is not optional. It doesn't always. There's a pr_warn() in _regulator_get(), but that's only for non-DT (since for DT, has_full_constraints is set to true in regulator_init_complete()). Actually that would mean that the regulator core will complain as long as init isn't complete. But since, like many other drivers, pwm-backlight could use deferred probing it's likely to end up being probed after init. So, part of the thing here is that nobody ever bothers actually creating the supplies even when the device fails to load without them - everyone is much more keen to complain about needing to do the work than actually provide the hookup even though it's generally pretty quick and simple to do so. That said we probably should still moan, I'll go and do that. signature.asc Description: Digital signature
Re: [PATCH v2 1/5] usb: musb: move port reset to worker
* Daniel Mack | 2013-10-01 15:39:53 [+0200]: musb_port_reset() sleeps, so we can't call it from atomic context. It is, however, called from places inside musb_hub_control() while musb-lock is held, which leads to a scheduling while atomic warning. I guess you are hit by the msleep(1) here. Fix this by moving the logic into a worker, and call it where the function was previously called directly. I *think* the better approach here would be to replace the msleep(1) by a busy loop. The thing is that you do now want to continue the operation and having the reset in progress. It should complete _right_ _now_ i.e. SET_PORT_FEATURE RESET is completed before the the next SET/GET request arrives and with a workqueue you can not guarantee this. Signed-off-by: Daniel Mack zon...@gmail.com Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]
On Wed, 2013-10-02 at 12:20 +0200, Arend van Spriel wrote: On 10/01/2013 01:29 PM, Luca Coelho wrote: Hi, On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote: On 10/01/2013 11:53 AM, Roger Quadros wrote: On 10/01/2013 12:49 PM, Roger Quadros wrote: Hi Arend, On 10/01/2013 11:05 AM, Arend van Spriel wrote: On 07/19/2013 12:57 PM, Arend van Spriel wrote: On 07/19/2013 12:49 PM, Roger Quadros wrote: On 07/19/2013 01:36 PM, Arend van Spriel wrote: On 07/18/2013 10:59 AM, Tony Lindgren wrote: Then for the SDIO with device tree, take a look at the following patches: [PATCH 0/3] WLAN support for omap4 when booted with devicetree http://comments.gmane.org/gmane.linux.ports.arm.omap/97522# I have been looking at the pandaboard patch in the series above and I do have a question. Among other things the patch adds these dt entries. +0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */ +0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */ If I look at the similar names in the deceased board-omap4panda.c: board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP), and in mux44xx.h: mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148 mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an explanation to it and it would help my understanding to know where this difference comes from. Hope you can help me out here. If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040. So, you need to subtract 0x40 from the offsets defined in mux44xx.h for pmx_core registers. That was what I was looking for. Thanks! Hi Roger, It has been a while, but I would like to pickup this thread. We have a couple of pandaboards used as test setup. These have an SDIO adapter hooked up to expansion connector A using MMC2. I have attached the patch file (just ignore platform_data stuff). Now on one board it works, but not for the other. I suspect a board issue so listing the two types that we use: PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope Any hints for me. Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you isolate it from your external SDIO adapter? On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi thing). OK, just realized that the expansion connector uses different pads for MMC2. However, you still need to make sure that the other pins (connected to on board WLAN chip) are not muxed as MMC2. I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I am not mistaken(?). Attached are the dmesg logs of the two boards. I sent 2 patch series to add DT support for the on-board WLAN, but they were not applied, since there were some comments that required changes. I really don't have the time to revisit them now that I'm not with TI anymore, so I'm hoping someone else will pick them up at some point. I found this one in my email archive: [PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp Guess that is what you are referring to, right? Yes, that one and also this (which implements DT in the driver itself): [PATCH v4 0/8] wilink: add device tree support http://mid.gmane.org/1375189476-21557-1-git-send-email-coe...@ti.com -- Luca. -- 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 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend
* Daniel Mack | 2013-10-01 15:39:54 [+0200]: Make musb_port_suspend() externally available, and call it when to host goes into suspend. This allows the core to go into suspend while a device is connected. Sorry for asking this stupid question but what is usally happening when the host goes to suspend and a device is connected? I think it is disconnected re-enumerated and resume and this not what you want, right? What happens if the device is unplugged while the host is suspended and not there on resume? Signed-off-by: Daniel Mack zon...@gmail.com Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] i2c: omap: Clear ARDY bit twice
Initially commit cb527ede1bf6ff2008a025606f25344b8ed7b4ac
i2c-omap: Double clear of ARDY status in IRQ handler
added a workaround for undocumented errata ProDB0017052.
But then commit 1d7afc95946487945cc7f5019b41255b72224b70
i2c: omap: ack IRQ in parts refactored code and missed
one of ARDY clearings. So current code violates errata.
It causes often i2c bus timeouts on my Pandaboard.
This patch adds a second clearing in place.
Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org
---
drivers/i2c/busses/i2c-omap.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6d8308d..9967a6f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -939,6 +939,9 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
/*
* ProDB0017052: Clear ARDY bit twice
*/
+ if (stat OMAP_I2C_STAT_ARDY)
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ARDY);
+
if (stat (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] dma: cppi41: more suspend/resume patches
On 02.10.2013 12:20, Sebastian Andrzej Siewior wrote:
* Daniel Mack | 2013-10-01 15:31:08 [+0200]:
Patch #3, however, gives me headaches. I can't fully explain what's
going on, but I can tell for sure that if fixes a problem that I stared
on for many hours.
The problem is that on resume, the musb core will detect that some of
the suspended USB devices' endpoints are stalled. Which is something
that is unrelated to the dma driver, it just seems to be an expected
condition. That, however, makes the musb core call
cppi41_dma_channel_abort() - cppi41_tear_down_chan(), which is
an otherwise untravelled code path. When that function is called for
a channel which has all of td_queued, td_seen and td_desc_seen set
to FALSE, I'm always getting a warning like this:
[ 17.105981] [ cut here ]
[ 17.110861] WARNING: CPU: 0 PID: 122 at drivers/dma/cppi41.c:644
cppi41_dma_control+0x378/0x3f8 [cppi41]()
This is
WARN_ON(!cdd-chan_busy[desc_num]);
at the end of cppi41_stop_chan() right?
No, as stated, the line numbers in the kernel message are somewhat off
due to added debugging code. What kicks in here is this one:
if (!c-td_desc_seen) {
desc_phys = cppi41_pop_desc(cdd, c-q_comp_num);
if (desc_phys) {
__iormb();
WARN_ON(c-desc_phys != desc_phys);
c-td_desc_seen = 1;
}
}
So you get the warning because
you tried to stop a channel which was not busy. But then you should not
be called at all because cppi41_dma_channel_abort() shouldn't call dma
driver on idle channels.
However, I see nothing that forbids you from calling
dmaengine_terminate_all() on idle channels. If that's not handled
properly by the cppi driver, I'd say it needs fixing.
How does your suspend resume thingy work? Is it completly shutdown
i.e. powered off? According to you earlier patches I would assume so. In
that case the request is not enqueued and there is nothing to be removed
from the engine, right?
No, my debugging showed that the channel has actually been prepared and
submitted before. It's just being torn down shortly after that. That's
what makes be believe in a race condition here.
With the change you somehow get an interrupt that cleans up that slot.
Timing, I presume.
The whole thing has been tested by manipulating the USB storage driver
to enqueue more / less data then required by the protocol leading to a
stall followed by an abort of the transfer. Let me re-do your suspend
with the patches you made so far to check what is going on and if the
normal transfer cancel is still working.
Ok, that sounds good.
Thanks,
Daniel
--
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] mfd: twl6030: Fix endianness problem in IRQ handler
From: Danke Xie d@sta.samsung.com
The current TWL 6030 IRQ handler assumes little endianness.
This change makes it endian-neutral.
Signed-off-by: Danke Xie d@sta.samsung.com
Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org
---
drivers/mfd/twl6030-irq.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 517eda8..1941dc6 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -178,6 +178,7 @@ static irqreturn_t twl6030_irq_thread(int irq, void *data)
u8 bytes[4];
u32 int_sts;
} sts;
+ u32 int_sts; /* sts.int_sts converted to CPU endianness */
struct twl6030_irq *pdata = data;
/* read INT_STS_A, B and C in one shot using a burst read */
@@ -196,8 +197,9 @@ static irqreturn_t twl6030_irq_thread(int irq, void *data)
if (sts.bytes[2] 0x10)
sts.bytes[2] |= 0x08;
- for (i = 0; sts.int_sts; sts.int_sts = 1, i++)
- if (sts.int_sts 0x1) {
+ int_sts = le32_to_cpu(sts.int_sts);
+ for (i = 0; int_sts; int_sts = 1, i++)
+ if (int_sts 0x1) {
int module_irq =
irq_find_mapping(pdata-irq_domain,
pdata-irq_mapping_tbl[i]);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend
On 02.10.2013 12:49, Sebastian Andrzej Siewior wrote: * Daniel Mack | 2013-10-01 15:39:54 [+0200]: Make musb_port_suspend() externally available, and call it when to host goes into suspend. This allows the core to go into suspend while a device is connected. Sorry for asking this stupid question but what is usally happening when the host goes to suspend and a device is connected? I think it is disconnected re-enumerated and resume and this not what you want, right? It is usually put into USB suspend and the host preserves its state. After resume, the usb storage driver, for example, will not register new partitions but expect things to be as they were before. That is, your previously mounted devices remain functional. However, the enumeration process has to be done again, because when the device looses power, it can't memorize its address. What happens if the device is unplugged while the host is suspended and not there on resume? That condition is detected and a full teardown of the connected drivers is conducted. Try what happens on your notebook when you do that. Embedded systems should behave just the same. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] usb: musb: move port reset to worker
On 02.10.2013 12:46, Sebastian Andrzej Siewior wrote: * Daniel Mack | 2013-10-01 15:39:53 [+0200]: musb_port_reset() sleeps, so we can't call it from atomic context. It is, however, called from places inside musb_hub_control() while musb-lock is held, which leads to a scheduling while atomic warning. I guess you are hit by the msleep(1) here. Yes. Fix this by moving the logic into a worker, and call it where the function was previously called directly. I *think* the better approach here would be to replace the msleep(1) by a busy loop. The thing is that you do now want to continue the operation and having the reset in progress. It should complete _right_ _now_ i.e. SET_PORT_FEATURE RESET is completed before the the next SET/GET request arrives and with a workqueue you can not guarantee this. Hmm, ok. I'm just not sure what time periods we're really sleeping for here. After all, we're blocking all interrupts from occuring while the lock is held. So my question is rather whether it's sensible at all to hold the lock while waiting. We might change some of the execution pathes to mutexes and waitqueues as well. Felipe? Thanks, Daniel -- 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/3] dma: cppi41: move -EAGAIN in tear_down
On 02.10.2013 12:25, Sebastian Andrzej Siewior wrote: On 10/02/2013 11:19 AM, Daniel Mack wrote: Once the system is booted up and the USB media is detected, I send the system to sleep mode with cat mem /sys/power/state. After wakeup, I access the media by mounting and unmounting it once, then send the system back to sleep. Okay. Going to sleep is probably easy, I need to figure out how to wakeup… Unless you pass no_console_suspend in your cmdline, you can just wake up the system via UART0. IOW, just press enter on the serial console. Daniel -- 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 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend
On 10/02/2013 01:14 PM, Daniel Mack wrote: On 02.10.2013 12:49, Sebastian Andrzej Siewior wrote: * Daniel Mack | 2013-10-01 15:39:54 [+0200]: Make musb_port_suspend() externally available, and call it when to host goes into suspend. This allows the core to go into suspend while a device is connected. Sorry for asking this stupid question but what is usally happening when the host goes to suspend and a device is connected? I think it is disconnected re-enumerated and resume and this not what you want, right? It is usually put into USB suspend and the host preserves its state. After resume, the usb storage driver, for example, will not register new partitions but expect things to be as they were before. That is, your previously mounted devices remain functional. However, the enumeration process has to be done again, because when the device looses power, it can't memorize its address. What happens if the device is unplugged while the host is suspended and not there on resume? That condition is detected and a full teardown of the connected drivers is conducted. Try what happens on your notebook when you do that. Embedded systems should behave just the same. I had the feeling that the USB device gets disconnected and re-enumerated on resume. But if you say that the ehci-hcd saves the state and keeps the device connected if it wasn't disconnected during suspend then there is no reason for musb to behave differently. Daniel Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend
On 02.10.2013 14:01, Sebastian Andrzej Siewior wrote: On 10/02/2013 01:14 PM, Daniel Mack wrote: On 02.10.2013 12:49, Sebastian Andrzej Siewior wrote: What happens if the device is unplugged while the host is suspended and not there on resume? That condition is detected and a full teardown of the connected drivers is conducted. Try what happens on your notebook when you do that. Embedded systems should behave just the same. I had the feeling that the USB device gets disconnected and re-enumerated on resume. Yes. The device looses its +5V power supply, so it has to be reset and re-enumerated on resume of course. It's just that USB drivers know about the state the device has to be put back into after resume, and don't assume the device was disconnected and reconnected. The latter would (for usb-storage) also cause paritions to be removed and added. But if you say that the ehci-hcd saves the state and keeps the device connected if it wasn't disconnected during suspend then there is no reason for musb to behave differently. Which it doesn't with my patches applied. I can mount a USB volume, put the system into suspend and access the contents after resume. Just the way it should be :) Daniel -- 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
32-bit access to 16-bit register on L4_PER
Recent commit 76bac1987ca181d54f8c9456d20997cb1020af2d OMAP: UART: Fix the revision register read changed UART_MVR 16-bit read to 32-bit. But pre-OMAP4 devices have 16-bit MVR register. Is it safe to assume that 32-bit access will return 0's in upper 16-bits in this case? -- Regards, Taras Kondratiuk -- 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/3] dma: cppi41: more suspend/resume patches
On 10/02/2013 01:07 PM, Daniel Mack wrote:
No, as stated, the line numbers in the kernel message are somewhat off
due to added debugging code. What kicks in here is this one:
if (!c-td_desc_seen) {
desc_phys = cppi41_pop_desc(cdd, c-q_comp_num);
if (desc_phys) {
__iormb();
WARN_ON(c-desc_phys != desc_phys);
c-td_desc_seen = 1;
}
}
Ach okay. So something completed but it wasn't the expected descriptor.
So you get the warning because
you tried to stop a channel which was not busy. But then you should not
be called at all because cppi41_dma_channel_abort() shouldn't call dma
driver on idle channels.
However, I see nothing that forbids you from calling
dmaengine_terminate_all() on idle channels. If that's not handled
properly by the cppi driver, I'd say it needs fixing.
No argue about that.
How does your suspend resume thingy work? Is it completly shutdown
i.e. powered off? According to you earlier patches I would assume so. In
that case the request is not enqueued and there is nothing to be removed
from the engine, right?
No, my debugging showed that the channel has actually been prepared and
submitted before. It's just being torn down shortly after that. That's
what makes be believe in a race condition here.
I see.
Thanks,
Daniel
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 09/10] usb: dwc3: omap: manage usb_otg_ss_refclk960m clock
On Mon, Sep 23, 2013 at 04:11:30PM +0300, Roger Quadros wrote: Hi Felipe, On 09/18/2013 03:49 PM, Roger Quadros wrote: usb_otg_ss_refclk960m is an optional functional clock to the UBS_OTG_SS module. So manage it in the driver. Just realized that usb_otg_ss_refclk960m is in fact functional clock to the PHY and not USB_OTG_SS module. The name is misleading. So please ignore patch 9 and 10. ignored. All others are fine, right ? -- balbi signature.asc Description: Digital signature
Re: [RFC 00/15] Device Tree schemas and validation
Benoit, Sorry, I meant to ask earlier but forgot. Shouldn't this development be based on the upstream DTC repository and not the in-kernel copy of the DTC? Eventually, yes, We should *start* there, though. but here the main point is to discuss the schema that will be used to defined bindings. In that case, the DTC patches code are mostly a proof of concept Sure; all that is fine. using the Linux kernel as example. Example?(*) We shouldn't churn the kernel. jdl (*) In the sense that *this* Universe is just one example from all known Universes? :-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 09/10] usb: dwc3: omap: manage usb_otg_ss_refclk960m clock
On 10/02/2013 04:11 PM, Felipe Balbi wrote: On Mon, Sep 23, 2013 at 04:11:30PM +0300, Roger Quadros wrote: Hi Felipe, On 09/18/2013 03:49 PM, Roger Quadros wrote: usb_otg_ss_refclk960m is an optional functional clock to the UBS_OTG_SS module. So manage it in the driver. Just realized that usb_otg_ss_refclk960m is in fact functional clock to the PHY and not USB_OTG_SS module. The name is misleading. So please ignore patch 9 and 10. ignored. All others are fine, right ? Yes. But I might have to rebase this on top of Phy framework stuff. 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 00/15] Device Tree schemas and validation
On Tue, Oct 01, 2013 at 03:54:20PM -0500, Rob Herring wrote: On Tue, Oct 1, 2013 at 10:06 AM, Benoit Cousson bcous...@baylibre.com wrote: Hi Rob, On 01/10/2013 15:17, Rob Herring wrote: On 10/01/2013 03:06 AM, Benoit Cousson wrote: + more DT maintainers folks Hi all, I know this is mostly boring user space code, but I was expecting a little bit of comments about at least the bindings syntax:-( I'd like to know if this is the right direction and if it worth pursuing in that direction. The idea was to have at least some base for further discussion during ARM KS 2013. I feel alone :-( If you have any comment, go ahead! Thanks for taking this on! This is interesting approach using the dts syntax, Well, this was discussed a little bit on the list, and it has the big advantage of re-using the parser already included in DTC for free. In term or readability, it avoids to re-defining a brand new syntax for people who are already familiar with the DTS one. but I worry that the validation will only be as good as the schema written and the review of the schema. Well, sure, but unfortunately, that will always be the case :-( The bindings definition being quite open, there is no easy way to ensure proper schema / bindings without careful review of the schema. There is no such thing as a free beer... Unfortunately :-) I think the schema needs to define the binding rather than define the checks. Then the schema can feed the validation checks. This format does not seem to me as easily being able to generate documentation from the schema which I believe is one of the goals. Indeed, but I think is it easy to generate any kind of readable format for the documentation purpose if needed from the actual format. Otherwise, we should consider a schema format based on kerneldoc type of syntax to improve readability. I'm just afraid it will become harder then to define complex schema. BTW, what kind of documentation are you expecting here? Is is a text that can be added on top of each schema? I would expect the schema to replace Documentation/devicetree/bindings/* over time. I think the thing that needs to be worked out here is how to add free form multi-line text. I'm not convinced that's a realistic goal. As I see it, the fundamental difference between a binding document and a formal schema is that a binding defines both the syntax required of a node, and its semantics, whereas a schema defines only syntax - the semantics still need to be defined somewhere. -- 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 pgp0yD2z4Q1JA.pgp Description: PGP signature
Re: [RFC 00/15] Device Tree schemas and validation
On Tue, Oct 01, 2013 at 08:17:42AM -0500, Rob Herring wrote: On 10/01/2013 03:06 AM, Benoit Cousson wrote: + more DT maintainers folks Hi all, I know this is mostly boring user space code, but I was expecting a little bit of comments about at least the bindings syntax:-( I'd like to know if this is the right direction and if it worth pursuing in that direction. The idea was to have at least some base for further discussion during ARM KS 2013. I feel alone :-( If you have any comment, go ahead! Thanks for taking this on! This is interesting approach using the dts syntax, but I worry that the validation will only be as good as the schema written and the review of the schema. I think the schema needs to define the binding rather than define the checks. Then the schema can feed the validation checks. This format does not seem to me as easily being able to generate documentation from the schema which I believe is one of the goals. I for one don't care to review the documentation and the schema for every binding. Hrm. I'm less optimistic about entirely replacing human-readable bindings with machine-readable schemas. But I do think the schema language needs to be substantially more flexible than the draft presented here. While I think a schema syntax which mirrors dts syntax makes a lot of sense, actually defining schemas as device trees doesn't seem quite right to me. -- 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 pgps4GNtO_6_u.pgp Description: PGP signature
Re: [RFC 01/15] scripts/dtc: fix most memory leaks in dtc
On Tue, Sep 24, 2013 at 06:52:07PM +0200, Benoit Cousson wrote:
From: Fabien Parent fpar...@baylibre.com
As noted elsewhere, please write patches against upstream dtc, not the
version in the kernel. git://git.kernel.org/pub/scm/utils/dtc/dtc.git
There are a few memory leaks in dtc which until now were not that important
since they were all in the parser and only one instance of the parser was run
per instance of dtc. The following commits will add a validation of dts
through
schema which have the same syntax as dts, i.e. the parser of dts will be
reused
to parse schema. The consequence is that instead of having the parser running
only one time for an instance of the dtc process, the parser will run
many many times and thus the leak that were not important until now becomes
urgent to fix.
Hrm, yeah. I'm aware that I haven't been very careful with memory
leaks within the parser. Essentially, I've been treating the process
as a pool allocator with exactly one pool - I've even considered
getting rid of those free()s we do have.
If the parser's going to be invoked repeatedly, then, yes, that
certainly needs fixing. Whether individually fixing each leak or
using a explicit pool allocator is a better option is less clear.
dtc-lexer: Do not duplicate the string which contains literals because the
string is directly converted afterward to an integer and is never used again.
livetree: Add a bunch of free helper functions to clean properly the
dt.
This is no good. Making this assumption is a layering violation - if
the parser was changed so that this literal wasn't converted until
after another token was read, the yytext value copied in here would no
longer be valid and would break horribly.
Signed-off-by: Fabien Parent fpar...@baylibre.com
Signed-off-by: Benoit Cousson bcous...@baylibre.com
---
scripts/dtc/dtc-lexer.l | 2 +-
scripts/dtc/dtc-lexer.lex.c_shipped | 2 +-
scripts/dtc/dtc.c | 1 +
scripts/dtc/dtc.h | 1 +
scripts/dtc/livetree.c | 108
+---
5 files changed, 105 insertions(+), 9 deletions(-)
diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
index 3b41bfc..4f63fbf 100644
--- a/scripts/dtc/dtc-lexer.l
+++ b/scripts/dtc/dtc-lexer.l
@@ -146,7 +146,7 @@ static int pop_input_file(void);
}
V1([0-9]+|0[xX][0-9a-fA-F]+)(U|L|UL|LL|ULL)? {
- yylval.literal = xstrdup(yytext);
+ yylval.literal = yytext;
DPRINT(Literal: '%s'\n, yylval.literal);
return DT_LITERAL;
}
diff --git a/scripts/dtc/dtc-lexer.lex.c_shipped
b/scripts/dtc/dtc-lexer.lex.c_shipped
index 2d30f41..5c0d27c 100644
--- a/scripts/dtc/dtc-lexer.lex.c_shipped
+++ b/scripts/dtc/dtc-lexer.lex.c_shipped
@@ -1054,7 +1054,7 @@ case 10:
YY_RULE_SETUP
#line 148 dtc-lexer.l
{
- yylval.literal = xstrdup(yytext);
+ yylval.literal = yytext;
DPRINT(Literal: '%s'\n, yylval.literal);
return DT_LITERAL;
}
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index a375683..215ae92 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -256,5 +256,6 @@ int main(int argc, char *argv[])
die(Unknown output format \%s\\n, outform);
}
+ free_dt(bi);
exit(0);
}
diff --git a/scripts/dtc/dtc.h b/scripts/dtc/dtc.h
index 3e42a07..9c45fd2 100644
--- a/scripts/dtc/dtc.h
+++ b/scripts/dtc/dtc.h
@@ -245,6 +245,7 @@ struct boot_info {
struct boot_info *build_boot_info(struct reserve_info *reservelist,
struct node *tree, uint32_t boot_cpuid_phys);
void sort_tree(struct boot_info *bi);
+void free_dt(struct boot_info *bi);
/* Checks */
diff --git a/scripts/dtc/livetree.c b/scripts/dtc/livetree.c
index b61465f..5c8692c 100644
--- a/scripts/dtc/livetree.c
+++ b/scripts/dtc/livetree.c
@@ -20,6 +20,10 @@
#include dtc.h
+static void free_node_list(struct node *n);
+static void free_node(struct node *n);
+static void free_property(struct property *p);
+
/*
* Tree building functions
*/
@@ -144,7 +148,7 @@ struct node *merge_nodes(struct node *old_node, struct
node *new_node)
/* Add new node labels to old node */
for_each_label_withdel(new_node-labels, l)
- add_label(old_node-labels, l-label);
+ add_label(old_node-labels, xstrdup(l-label));
/* Move properties from the new node to the old node. If there
* is a collision, replace the old value with the new */
@@ -156,7 +160,7 @@ struct node *merge_nodes(struct node *old_node, struct
node *new_node)
if (new_prop-deleted) {
delete_property_by_name(old_node, new_prop-name);
- free(new_prop);
+
Re: [RFC 00/15] Device Tree schemas and validation
On Tue, Oct 01, 2013 at 04:22:24PM -0600, Stephen Warren wrote:
On 09/24/2013 10:52 AM, Benoit Cousson wrote:
Hi All,
Following the discussion that happened during LCE-2013 and the email
thread started by Tomasz few months ago [1], here is a first attempt
to introduce:
- a schema language to define the bindings accurately
- DTS validation during device tree compilation in DTC itself
Sorry, this is probably going to sound a bit negative. Hopefully you
find it constructive though.
The syntax for a schema is the same as the one for dts. This choice has
been made to simplify its development, to maximize the code reuse and
finally because the format is human-readable.
I'm not convinced that's a good decision.
DT is a language for representing data.
The validation checks described by schemas are rules, or code, and not
static data.
So, while I'm sure it's possible to shoe-horn at least some reasonable
subset of DT validation into DT syntax itself, I feel it's unlikely to
yield something that's scalable enough.
I tend to agree.
For example, it's easy to specify that a property must be 2 cells long.
What if it could be any multiple of two? That's a lot of numbers to
explicitly enumerate as data. Sure, you can then invent syntax to
represent that specific rule (parameterized by 2), but what about the
next similar-but-different rule? The only approach I can think of to
that is to allow the schema to contain arbitrary expressions, which
would likely need to morph into arbitary statements not just
expressions. Once you're there, I think the schema would be better
represented as a programming language rather than as a data structure
that could have code hooked into it.
How to:
* Associate a schema to one or several nodes
As said earlier a schema can be used to validate one or several nodes
from a dts. To do this the compatible properties from the nodes which
should be validated must be present in the schema.
timer1: timer@4a318000 {
compatible = ti,omap3430-timer;
...
To write a schema which will validate OMAP Timers like the one above,
one may write the following schema:
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
What about DT nodes that don't have a compatible value? We certainly
have some of those already like /memory and /chosen. We should be able
to validate their schema too. This probably doesn't invalidate being
able to look things up by compatible value though; it just means we need
some additional mechanisms too.
More to the point, what about the properties of a node whose format is
defined not by this node's binding but by some other nodes binding.
e.g. the exact format of reg and ranges is at least partially
determined by the parent bus's binding, and interrupts is defined
partially by the interrupt parent's binding. gpio properties are
defined by a combination of a global binding and the gpio parent,
IIRC.
* Define constraints on properties
To define constraints on a property one has to create a node in a schema
which has as name the name of the property that one want to validate.
To specify constraints on the property ti,hwmods of OMAP Timers one
can write this schema:
/dts-v1/;
/ {
compatible = ti,omap[0-9]+-timer;
ti,hwmods {
...
};
compatible and ti,hwmods are both properties in the DT file. However, in
the schema above, one appears as a property, and one as a node. I don't
like that inconsistency. It'd be better if compatible was a node too.
Essentially what's going on here is that to describe the constraint on
a property, a node with corresponding name is defined to encode the
parameters of that constraint. It kind of works, but it's forced. It
also hits problems since nodes and properties are technically in
different namespaces, although they rarely collide in real cases.
If one want to use a regular as property name one can write this schema:
/dts-v1/;
/ {
compatible = abc;
def {
name = def[0-9];
Isn't it valid to have a property named name within the node itself?
How do you differentiate between specifying the node name and the name
property?
Or to look at it another way, how do you differentiate between nodes
representing encoded constraints for a property, and nodes
representing nodes directly.
What if the node name needs more validation than just a regex. For
example, suppose we want to validate the
unit-name-must-match-reg-address rule. We need to write some complex
expression using data extracted from reg to calculate the unit address.
Equally, the node name perhaps has to exist in some global list of
acceptable node names. It would be extremely tricky if not impossible to
do that with a regex.
...
};
};
Above one can see
Re: [PATCH v2 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend
On Wed, 2 Oct 2013, Daniel Mack wrote: On 02.10.2013 14:01, Sebastian Andrzej Siewior wrote: On 10/02/2013 01:14 PM, Daniel Mack wrote: On 02.10.2013 12:49, Sebastian Andrzej Siewior wrote: What happens if the device is unplugged while the host is suspended and not there on resume? That condition is detected and a full teardown of the connected drivers is conducted. Try what happens on your notebook when you do that. Embedded systems should behave just the same. I had the feeling that the USB device gets disconnected and re-enumerated on resume. Yes. The device looses its +5V power supply, so it has to be reset and re-enumerated on resume of course. It's just that USB drivers know about the state the device has to be put back into after resume, and don't assume the device was disconnected and reconnected. The latter would (for usb-storage) also cause paritions to be removed and added. This description may be slightly misleading. According to the USB spec, a device is not supposed to lose its +5V power supply during suspend. Therefore it does not need to be reset and re-enumerated upon resume. (Except that some devices don't handle suspend properly because of buggy firmware; they _do_ need to be reset.) Of course, some systems don't follow the spec. If they can't supply suspend power to the host controller and the USB bus, then the device _will_ need to be reset and re-enumerated. Some USB drivers (those which define a reset_resume method) are able to handle this -- they put the device back into the right state and then act as if nothing had happened. Others aren't; they get unbound and rebound just as though the device really had been disconnected and reconnected. Alan Stern -- 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: [LNG] [PATCH] mfd: twl6030: Fix endianness problem in IRQ handler
On Wed, 2 Oct 2013 14:08:44 +0300 Taras Kondratiuk taras.kondrat...@linaro.org wrote: From: Danke Xie d@sta.samsung.com The current TWL 6030 IRQ handler assumes little endianness. This change makes it endian-neutral. Signed-off-by: Danke Xie d@sta.samsung.com Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org --- this patch causes a new sparse warning: make C=2 CF=-D__CHECK_ENDIAN__ drivers/mfd/twl6030-irq.o ... CHECK drivers/mfd/twl6030-irq.c drivers/mfd/twl6030-irq.c:200:19: warning: cast to restricted __le32 does int_sts in the sts union need to be defined as __le32? Thanks, Kim -- 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 10/10] pwm-backlight: Allow backlight to remain disabled on boot
On Tue, Oct 01, 2013 at 12:50:51PM -0600, Stephen Warren wrote:
On 09/23/2013 03:41 PM, Thierry Reding wrote:
[...]
+ if (gpio_is_valid(pb-enable_gpio)) {
+ if (pb-enable_gpio_flags PWM_BACKLIGHT_GPIO_ACTIVE_LOW)
+ gpio_set_value(pb-enable_gpio, 0);
+ else
+ gpio_set_value(pb-enable_gpio, 1);
+ }
... That assumes that the backlight is on at boot, and hence presumably
after this patch still always turns on the backlight, only to turn it
off very quickly once the following code in this patch executes:
I was just going to fix this, but then saw that the code in .probe() is
actually this:
if (gpio_is_valid(pb-enable_gpio)) {
unsigned long flags;
if (pb-enable_gpio_flags PWM_BACKLIGHT_GPIO_ACTIVE_LOW)
flags = GPIOF_OUT_INIT_HIGH;
else
flags = GPIOF_OUT_INIT_LOW;
ret = gpio_request_one(pb-enable_gpio, flags, enable);
...
}
Which sets the backlight up to be disabled by default and is consistent
with the PWM and regulator setup. Only later, depending on the value of
boot_off it gets enabled (or stays disabled).
(and perhaps we also need to avoid turning the backlight off then on if
it was already on at boot)
That's true. Although I'm not sure if that's even possible. I think the
pinctrl driver doesn't touch the registers, but what about the GPIO and
PWM drivers. It might be impossible to always query the boot status and
set the internal state based on that. The easiest would probably be if
both the bootloader and the kernel use the same DT, in which case the
bootloader could set the backlight-boot-on property, in which case we
wouldn't need to do anything at .probe() time really.
Thierry
pgpeu0VkrWADK.pgp
Description: PGP signature
[PATCH] ARM: dts: AM33XX: add ethernet alias's for am33xx
Set the alias for ethernet0 and ethernet1 so that uBoot
can set the MAC address appropriately.
Currently uBoot cannot find the alias and there for does not set the
MAC address.
Signed-off-by: Dan Murphy dmur...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 553adc6..8aabaa0 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -30,6 +30,8 @@
usb1 = usb1;
phy0 = usb0_phy;
phy1 = usb1_phy;
+ ethernet0 = cpsw_emac0;
+ ethernet1 = cpsw_emac1;
};
cpus {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/15] Device Tree schemas and validation
On Wed, Oct 02, 2013 at 11:54:50PM +1000, David Gibson wrote: On Tue, Oct 01, 2013 at 03:54:20PM -0500, Rob Herring wrote: I would expect the schema to replace Documentation/devicetree/bindings/* over time. I think the thing that needs to be worked out here is how to add free form multi-line text. I'm not convinced that's a realistic goal. As I see it, the fundamental difference between a binding document and a formal schema is that a binding defines both the syntax required of a node, and its semantics, whereas a schema defines only syntax - the semantics still need to be defined somewhere. So long as the schema lets you include free form text to define the semantics I'm not sure there's an incompatibility there - the same document can cover both. signature.asc Description: Digital signature
Re: [LNG] [PATCH] mfd: twl6030: Fix endianness problem in IRQ handler
On 2 October 2013 19:43, Kim Phillips kim.phill...@linaro.org wrote: On Wed, 2 Oct 2013 14:08:44 +0300 Taras Kondratiuk taras.kondrat...@linaro.org wrote: From: Danke Xie d@sta.samsung.com The current TWL 6030 IRQ handler assumes little endianness. This change makes it endian-neutral. Signed-off-by: Danke Xie d@sta.samsung.com Signed-off-by: Taras Kondratiuk taras.kondrat...@linaro.org --- this patch causes a new sparse warning: make C=2 CF=-D__CHECK_ENDIAN__ drivers/mfd/twl6030-irq.o ... CHECK drivers/mfd/twl6030-irq.c drivers/mfd/twl6030-irq.c:200:19: warning: cast to restricted __le32 does int_sts in the sts union need to be defined as __le32? You are right. I will update the patch. -- Regards, Taras Kondratiuk -- 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 00/15] Device Tree schemas and validation
On Wed, Oct 02, 2013 at 07:08:41PM +0100, Mark Brown wrote: On Wed, Oct 02, 2013 at 11:54:50PM +1000, David Gibson wrote: On Tue, Oct 01, 2013 at 03:54:20PM -0500, Rob Herring wrote: I would expect the schema to replace Documentation/devicetree/bindings/* over time. I think the thing that needs to be worked out here is how to add free form multi-line text. I'm not convinced that's a realistic goal. As I see it, the fundamental difference between a binding document and a formal schema is that a binding defines both the syntax required of a node, and its semantics, whereas a schema defines only syntax - the semantics still need to be defined somewhere. So long as the schema lets you include free form text to define the semantics I'm not sure there's an incompatibility there - the same document can cover both. True, there's no reason the machine-readable schema and human-readable documentation can't be contained in the same file. -- 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 pgpv8VA08IhkS.pgp Description: PGP signature
Re: [PATCH] ARM: dts: AM33XX: add ethernet alias's for am33xx
On Wednesday 02 October 2013 12:58 PM, Dan Murphy wrote: Set the alias for ethernet0 and ethernet1 so that uBoot can set the MAC address appropriately. Currently uBoot cannot find the alias and there for does not set the MAC address. Signed-off-by: Dan Murphy dmur...@ti.com Tested this with beagle bone black. Tested-by: Mugunthan V N mugunthan...@ti.com Regards Mugunthan V N -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 03/10] ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
* Roger Quadros rog...@ti.com [131002 03:27]: Hi Tony, On 09/24/2013 11:53 AM, Roger Quadros wrote: The platform data bits can be inferred from the other members of struct usbhs_phy_data. So get rid of the platform_data member. Build the platform data for the PHY device in usbhs_init_phys() instead. Signed-off-by: Roger Quadros rog...@ti.com Could you please Ack this if OK? This should be OK for you guys to queue. You should coordinate the .dts changes with Benoit though. It might be best to have this branch as an immutable branch against -rc3 that we can all merge in as needed. For this patch: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/10] ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes
* Roger Quadros rog...@ti.com [131002 03:28]: Hi Tony, On 09/24/2013 11:53 AM, Roger Quadros wrote: The USB phy-nop nop driver expects the RESET line information to be sent as a GPIO number via platform data. Adapt to that. Signed-off-by: Roger Quadros rog...@ti.com Need your Ack on this one as well. Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] arm: Select NOP_USB_XCEIV if MACH_OMAP3EVM is enabled
arm builds have been failing on and off with arch/arm/mach-omap2/board-omap3evm.c:703: undefined reference to `usb_nop_xceiv_register' for several years. Current arm:allmodconfig build fails for this reason. Problem is that board-omap3evm.c is always build into the kernel. It calls usb_nop_xceiv_register(), which is built with NOP_USB_XCEIV, which in turn can be configured as module. This results in the observed build failure. Fix the problem once and for all by selecting NOP_USB_XCEIV if MACH_OMAP3EVM is enabled. Signed-off-by: Guenter Roeck li...@roeck-us.net --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b5fb5f7..0bc2cf4 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -265,6 +265,7 @@ config MACH_OMAP3EVM depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB + select NOP_USB_XCEIV config MACH_OMAP3517EVM bool OMAP3517/ AM3517 EVM board -- 1.7.9.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] ARM: OMAP2+: Add support for auxdata
For few things we're still going to be needing platform
data for device tree based drivers. Let's set up auxdata
handling and do it in pdata-quirks.c so we have all the
legacy calls in one place.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c |5 +
arch/arm/mach-omap2/common.h|3 ++-
arch/arm/mach-omap2/pdata-quirks.c | 11 ++-
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index a66575f..3017a9d 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -35,10 +35,7 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
static void __init omap_generic_init(void)
{
- omap_sdrc_init(NULL, NULL);
-
- of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
- pdata_quirks_init();
+ pdata_quirks_init(omap_dt_match_table);
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index fd059e0..c6aebf0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -288,7 +288,8 @@ static inline void omap4_cpu_resume(void)
#endif
-void pdata_quirks_init(void);
+void pdata_quirks_init(struct of_device_id *);
+void omap_pcs_legacy_init(int irq, void (*rearm)(void));
struct omap_sdrc_params;
extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d472db..c739631 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -11,6 +11,7 @@
#include linux/gpio.h
#include linux/init.h
#include linux/kernel.h
+#include linux/of_platform.h
#include linux/wl12xx.h
#include common.h
@@ -99,6 +100,10 @@ static void __init omap5_uevm_legacy_init(void)
}
#endif
+struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
+ { /* sentinel */ },
+};
+
static struct pdata_init pdata_quirks[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
{ nokia,omap3-n9, hsmmc2_internal_input_clk, },
@@ -114,10 +119,14 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ /* sentinel */ },
};
-void __init pdata_quirks_init(void)
+void __init pdata_quirks_init(struct of_device_id *omap_dt_match_table)
{
struct pdata_init *quirks = pdata_quirks;
+ omap_sdrc_init(NULL, NULL);
+ of_platform_populate(NULL, omap_dt_match_table,
+omap_auxdata_lookup, NULL);
+
while (quirks-compatible) {
if (of_machine_is_compatible(quirks-compatible)) {
if (quirks-fn)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM: dts: Fix pinctrl mask for omap3
The wake-up interrupt bit is available on omap3/4/5 processors
unlike what we claim. Without fixing it we cannot use it on
omap3 and the system configured for wake-up events will just
hang on wake-up.
Cc: Grygorii Strashko grygorii.stras...@ti.com
Cc: Benoît Cousson bcous...@baylibre.com
Cc: devicet...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3.dtsi |4 ++--
arch/arm/mach-omap2/mux.h |4 +---
include/dt-bindings/pinctrl/omap.h |4 +---
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..b41bd57 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -108,7 +108,7 @@
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7f1f;
+ pinctrl-single,function-mask = 0xff1f;
};
omap3_pmx_wkup: pinmux@0x48002a00 {
@@ -117,7 +117,7 @@
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7f1f;
+ pinctrl-single,function-mask = 0xff1f;
};
gpio1: gpio@4831 {
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 5d2080e..16f78a9 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -28,7 +28,7 @@
#define OMAP_PULL_UP (1 4)
#define OMAP_ALTELECTRICALSEL (1 5)
-/* 34xx specific mux bit defines */
+/* omap3/4/5 specific mux bit defines */
#define OMAP_INPUT_EN (1 8)
#define OMAP_OFF_EN(1 9)
#define OMAP_OFFOUT_EN (1 10)
@@ -36,8 +36,6 @@
#define OMAP_OFF_PULL_EN (1 12)
#define OMAP_OFF_PULL_UP (1 13)
#define OMAP_WAKEUP_EN (1 14)
-
-/* 44xx specific mux bit defines */
#define OMAP_WAKEUP_EVENT (1 15)
/* Active pin states */
diff --git a/include/dt-bindings/pinctrl/omap.h
b/include/dt-bindings/pinctrl/omap.h
index edbd250..bed35e3 100644
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -23,7 +23,7 @@
#define PULL_UP(1 4)
#define ALTELECTRICALSEL (1 5)
-/* 34xx specific mux bit defines */
+/* omap3/4/5 specific mux bit defines */
#define INPUT_EN (1 8)
#define OFF_EN (1 9)
#define OFFOUT_EN (1 10)
@@ -31,8 +31,6 @@
#define OFF_PULL_EN(1 12)
#define OFF_PULL_UP(1 13)
#define WAKEUP_EN (1 14)
-
-/* 44xx specific mux bit defines */
#define WAKEUP_EVENT (1 15)
/* Active pin states */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single
Hi all, Here's a respin of the pinctrl-single related patches to use chained irq as suggested by Linus W earlier. This series does not try to provide any generic automated solution yet, but works by doing a request_irq() for the wake-up pin, so it should be flexible enough for both manual control and automated solution. This series removes the last nasty blocker for making omap3 to be device tree only without causing nasty PM regressions. Assuming Linus W acks the drivers/pinctrl parts, I can provide those three patches in a separate immutable branch against v3.12-rc3 for Linus W to pull so I can merge them in too. This series is based on my earlier series [PATCH 0/4] Clean up legacy platform data handling for omaps for v3.13 as it has a dependency for the pdata quirks for passing the auxdata to the driver. Regards, Tony --- Tony Lindgren (6): ARM: dts: Fix pinctrl mask for omap3 ARM: OMAP2+: Add support for auxdata pinctrl: single: Prepare for supporting SoC specific features pinctrl: single: Add support for wake-up interrupts pinctrl: single: Add support for auxdata ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap .../devicetree/bindings/pinctrl/pinctrl-single.txt | 11 + arch/arm/boot/dts/omap3.dtsi |8 arch/arm/boot/dts/omap4.dtsi |4 arch/arm/mach-omap2/board-generic.c|5 arch/arm/mach-omap2/common.h |3 arch/arm/mach-omap2/mux.c |8 arch/arm/mach-omap2/mux.h |4 arch/arm/mach-omap2/pdata-quirks.c | 29 +- arch/arm/mach-omap2/prm3xxx.h |8 arch/arm/mach-omap2/prm44xx_54xx.h |8 arch/arm/mach-omap2/prm_common.c | 11 + drivers/pinctrl/pinctrl-single.c | 386 include/dt-bindings/pinctrl/omap.h |4 include/linux/platform_data/pinctrl-single.h | 12 + 14 files changed, 474 insertions(+), 27 deletions(-) create mode 100644 include/linux/platform_data/pinctrl-single.h -- 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: [PATCHv2 2/9] hwspinlock/omap: add support for dt nodes
Hi Mark, On Fri, Sep 27, 2013 at 05:06:38PM +0100, Kumar Gala wrote: On Sep 17, 2013, at 2:30 PM, Suman Anna wrote: HwSpinlock IP is present only on OMAP4 and other newer SoCs, which are all device-tree boot only. This patch adds the base support for parsing the DT nodes, and removes the code dealing with the traditional platform device instantiation. Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 31 +++ arch/arm/mach-omap2/Makefile | 3 -- arch/arm/mach-omap2/hwspinlock.c | 60 -- drivers/hwspinlock/omap_hwspinlock.c | 23 +++-- 4 files changed, 50 insertions(+), 67 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt delete mode 100644 arch/arm/mach-omap2/hwspinlock.c diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt new file mode 100644 index 000..235b7c5 --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt @@ -0,0 +1,31 @@ +OMAP4+ HwSpinlock Driver + + +Required properties: +- compatible: Currently supports only ti,omap4-hwspinlock for + OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs Currently supports is not something I expect to see in a binding document. That sounds like a description of the driver rather than the binding. How similar are these hardware modules? What are the differences? The IP is almost the same, they all have the same revision id. The number of locks (each represented by a register) though vary from one SoC to another (OMAP4, OMAP5, DRA7 have same number of locks, and AM33xx/AM43xx have a different number). The number of locks is directly read by the driver from a module register. There is no separate .data associated with the of_device_id table, so I used a single compatible property for all the SoCs. +- reg: Contains the hwspinlock register address range (base + address and length) Is there only one register bank for the hwlock module? The lock registers start at a certain offset (0x800) within the module register space, and the offsets for various registers are identical between all SoCs. +- ti,hwmods: Name of the hwmod associated with the hwspinlock device + +Common hwlock properties: +The following describes the usage of the common hwlock properties (defined in +Documentation/devicetree/bindings/hwlock/hwlock.txt) on OMAP. + +- hwlock-base-id: There are currently no OMAP SoCs with multiple + hwspinlock devices. The OMAP driver uses a default + base id value of 0 for the locks present within the + single hwspinlock device on all SoCs. Driver details should not leak into bindngs... OK, will remove the info on driver details. As mentioned in the other patch, I don't think this is the way to handle this. I think we need a phandle + args representation. This is an optional parameter for now and I was going to revise the description based on comments from Kumar Gala on this thread, but I will wait and adjust this based on the outcome on the first patch. +- hwlock-num-locks:This property is not required on OMAP SoCs, since the + number of locks present within a device can be deduced + from the SPINLOCK_SYSSTATUS device register. Huh? Why define this property at all here if we don't need it and don't use it? The common document should state that specific bindings may use it and should explicitly state if they do, rather than stating they don't... Yeah, I wasn't sure how to go about the split between the common file and the platform-specific bindings. I will clean this up and revise the common bindings. Thanks Suman -- 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: [PATCHv2 1/9] hwspinlock/core: add common dt bindings and OF helpers
Hi Mark, On 10/01/2013 03:36 AM, Mark Rutland wrote: Hi Suman, Apologies for replying to a subthread, due to an earlier mistake on my part I don't have the original to hand. No issues, thanks for your review. On Fri, Sep 27, 2013 at 05:04:22PM +0100, Kumar Gala wrote: On Sep 17, 2013, at 2:30 PM, Suman Anna wrote: All the platform-specific hwlock driver implementations need the number of locks and the associated base id for registering the locks present within a hwspinlock device with the driver core. These two variables are represented by 'hwlock-num-locks' and 'hwlock-base-id' properties. The documentation and OF helpers to retrieve these common properties have been added to the driver core. Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/hwlock/hwlock.txt | 26 + drivers/hwspinlock/hwspinlock_core.c | 61 +- include/linux/hwspinlock.h | 11 ++-- 3 files changed, 93 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt new file mode 100644 index 000..789930e --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt @@ -0,0 +1,26 @@ +Generic hwlock bindings +=== + +Generic bindings that are common to all the hwlock platform specific driver +implementations, the retrieved values are used for registering the device +specific parameters with the hwspinlock core. + +The validity and need of these common properties may vary from one driver +implementation to another. Look through the individual hwlock driver +binding documentations for identifying which are mandatory and which are +optional for that specific driver. + +Common properties: +- hwlock-base-id: Base Id for the locks for a particular hwlock device. + This property is used for representing a set of locks + present in a hwlock device with a unique base id in + the driver core. This property is mandatory ONLY if a + SoC has several hwlock devices. + + See documentation on struct hwspinlock_pdata in + linux/hwspinlock.h for more details. I don't like this, as it seems to be encoding a Linux implementation detail (the ID of the lock, which means that we have to have a numeric representation of each hwlock) in the device tree. I don't see why the ID within Linux should be a concern of the device tree binding. I think that whatever internal identifier we have in Linux (be it an integer or struct) should be allocated by Linux. If a driver needs to request specific hwlocks, then we should have a phandle + args representation for referring to a specific hwlock that bidnings can use, and some code for parsing that and returning a Linux-internal identifier/struct as we do with interrupts and clocks. This is based on gathering the information required by the platform implementation drivers for registering with the driver core. The driver core currently maintains all the locks from different instances as a radix tree, as it is simpler to manage when granting locks to users. The current version is based on allowing the platform implementation drivers to retrieve the required data for registering with the hwspinlock driver core. The users would either get a lock dynamically by requesting any free one (and extract the id thereafter to share with others), or a specific one which is currently by id. I agree that the phandle + args approach is best suited for requesting a specific one through DT, but I would think that the args would still have to be a relative lock number from 0 w.r.t a phandle. I will look into the feasibility of such an approach retaining the radix tree implementation, as this requires new OF friendly registration and request functions. + +- hwlock-num-locks:Number of locks present in a hwlock device. This + property is needed on hwlock devices, where the number + of supported locks within a hwlock device cannot be + read from a register. Hmm... this seems generic, but it doesn't allow for sparse ID spaces on the hwlock module. It should probably be common for the moment, but if we encounter a hwlock module with a sparse ID space, we'll need to come up with a way of handling sparse IDs (that might be device-specific). Agreed. diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c index 461a0d7..aec32e7 100644 --- a/drivers/hwspinlock/hwspinlock_core.c +++ b/drivers/hwspinlock/hwspinlock_core.c @@ -1,7 +1,7 @@ /* * Hardware spinlock framework * - * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com + * Copyright (C) 2010-2013 Texas
Re: [PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single
* Tony Lindgren t...@atomide.com [131002 22:25]: Hi all, Here's a respin of the pinctrl-single related patches to use chained irq as suggested by Linus W earlier. This series does not try to provide any generic automated solution yet, but works by doing a request_irq() for the wake-up pin, so it should be flexible enough for both manual control and automated solution. This series removes the last nasty blocker for making omap3 to be device tree only without causing nasty PM regressions. Assuming Linus W acks the drivers/pinctrl parts, I can provide those three patches in a separate immutable branch against v3.12-rc3 for Linus W to pull so I can merge them in too. This series is based on my earlier series [PATCH 0/4] Clean up legacy platform data handling for omaps for v3.13 as it has a dependency for the pdata quirks for passing the auxdata to the driver. Sorry I had some typos in my Cc addresses and this series did not get fully sent. Will resend it, sorry for the noise. Regards, Tony --- Tony Lindgren (6): ARM: dts: Fix pinctrl mask for omap3 ARM: OMAP2+: Add support for auxdata pinctrl: single: Prepare for supporting SoC specific features pinctrl: single: Add support for wake-up interrupts pinctrl: single: Add support for auxdata ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap .../devicetree/bindings/pinctrl/pinctrl-single.txt | 11 + arch/arm/boot/dts/omap3.dtsi |8 arch/arm/boot/dts/omap4.dtsi |4 arch/arm/mach-omap2/board-generic.c|5 arch/arm/mach-omap2/common.h |3 arch/arm/mach-omap2/mux.c |8 arch/arm/mach-omap2/mux.h |4 arch/arm/mach-omap2/pdata-quirks.c | 29 +- arch/arm/mach-omap2/prm3xxx.h |8 arch/arm/mach-omap2/prm44xx_54xx.h |8 arch/arm/mach-omap2/prm_common.c | 11 + drivers/pinctrl/pinctrl-single.c | 386 include/dt-bindings/pinctrl/omap.h |4 include/linux/platform_data/pinctrl-single.h | 12 + 14 files changed, 474 insertions(+), 27 deletions(-) create mode 100644 include/linux/platform_data/pinctrl-single.h -- 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 -- 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/6] pinctrl: single: Prepare for supporting SoC specific features
Let's replace is_pinconf with flags and add struct pcs_soc_data
so we can support SoC specific features like pin wake-up events.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: Grygorii Strashko grygorii.stras...@ti.com
Cc: Prakash Manjunathappa prakash...@ti.com
Cc: Haojian Zhuang haojian.zhu...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/pinctrl/pinctrl-single.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index a82ace4..f88d3d1 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -150,19 +150,27 @@ struct pcs_name {
};
/**
+ * struct pcs_soc_data - SoC specific settings
+ * @flags: initial SoC specific PCS_FEAT_xxx values
+ */
+struct pcs_soc_data {
+ unsigned flags;
+};
+
+/**
* struct pcs_device - pinctrl device instance
* @res: resources
* @base: virtual address of the controller
* @size: size of the ioremapped area
* @dev: device entry
* @pctl: pin controller device
+ * @flags: mask of PCS_FEAT_xxx values
* @mutex: mutex protecting the lists
* @width: bits per mux register
* @fmask: function register mask
* @fshift:function register shift
* @foff: value to turn mux off
* @fmax: max number of functions in fmask
- * @is_pinconf:whether supports pinconf
* @bits_per_pin:number of bits per pin
* @names: array of register names for pins
* @pins: physical pins on the SoC
@@ -183,6 +191,8 @@ struct pcs_device {
unsigned size;
struct device *dev;
struct pinctrl_dev *pctl;
+ unsigned flags;
+#define PCS_FEAT_PINCONF (1 0)
struct mutex mutex;
unsigned width;
unsigned fmask;
@@ -190,7 +200,6 @@ struct pcs_device {
unsigned foff;
unsigned fmax;
bool bits_per_mux;
- bool is_pinconf;
unsigned bits_per_pin;
struct pcs_name *names;
struct pcs_data pins;
@@ -206,6 +215,8 @@ struct pcs_device {
void (*write)(unsigned val, void __iomem *reg);
};
+#define PCS_HAS_PINCONF(pcs-flags PCS_FEAT_PINCONF)
+
static int pcs_pinconf_get(struct pinctrl_dev *pctldev, unsigned pin,
unsigned long *config);
static int pcs_pinconf_set(struct pinctrl_dev *pctldev, unsigned pin,
@@ -1060,7 +1071,7 @@ static int pcs_parse_pinconf(struct pcs_device *pcs,
struct device_node *np,
};
/* If pinconf isn't supported, don't parse properties in below. */
- if (!pcs-is_pinconf)
+ if (!PCS_HAS_PINCONF)
return 0;
/* cacluate how much properties are supported in current node */
@@ -1184,7 +1195,7 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device
*pcs,
(*map)-data.mux.group = np-name;
(*map)-data.mux.function = np-name;
- if (pcs-is_pinconf) {
+ if (PCS_HAS_PINCONF) {
res = pcs_parse_pinconf(pcs, np, function, map);
if (res)
goto free_pingroups;
@@ -1305,7 +1316,7 @@ static int pcs_parse_bits_in_pinctrl_entry(struct
pcs_device *pcs,
(*map)-data.mux.group = np-name;
(*map)-data.mux.function = np-name;
- if (pcs-is_pinconf) {
+ if (PCS_HAS_PINCONF) {
dev_err(pcs-dev, pinconf not supported\n);
goto free_pingroups;
}
@@ -1525,6 +1536,7 @@ static int pcs_probe(struct platform_device *pdev)
const struct of_device_id *match;
struct resource *res;
struct pcs_device *pcs;
+ const struct pcs_soc_data *soc;
int ret;
match = of_match_device(pcs_of_match, pdev-dev);
@@ -1541,7 +1553,8 @@ static int pcs_probe(struct platform_device *pdev)
INIT_LIST_HEAD(pcs-pingroups);
INIT_LIST_HEAD(pcs-functions);
INIT_LIST_HEAD(pcs-gpiofuncs);
- pcs-is_pinconf = match-data;
+ soc = match-data;
+ pcs-flags = soc-flags;
PCS_GET_PROP_U32(pinctrl-single,register-width, pcs-width,
register width not specified\n);
@@ -1610,7 +1623,7 @@ static int pcs_probe(struct platform_device *pdev)
pcs-desc.name = DRIVER_NAME;
pcs-desc.pctlops = pcs_pinctrl_ops;
pcs-desc.pmxops = pcs_pinmux_ops;
- if (pcs-is_pinconf)
+ if (PCS_HAS_PINCONF)
pcs-desc.confops = pcs_pinconf_ops;
pcs-desc.owner = THIS_MODULE;
@@ -1652,9 +1665,16 @@ static int pcs_remove(struct platform_device *pdev)
return 0;
}
+static const struct pcs_soc_data pinctrl_single = {
+};
+
+static const struct pcs_soc_data pinconf_single = {
+ .flags = PCS_FEAT_PINCONF,
+};
[PATCH 0/6] add support for omap wake-up interrupts via pinctrl-single, take2
Hi all, Here's a respin of the pinctrl-single related patches to use chained irq as suggested by Linus W earlier. This series does not try to provide any generic automated solution yet, but works by doing a request_irq() for the wake-up pin, so it should be flexible enough for both manual control and automated solution. This series removes the last nasty blocker for making omap3 to be device tree only without causing nasty PM regressions. Assuming Linus W acks the drivers/pinctrl parts, I can provide those three patches in a separate immutable branch against v3.12-rc3 for Linus W to pull so I can merge them in too. This series is based on my earlier series [PATCH 0/4] Clean up legacy platform data handling for omaps for v3.13 as it has a dependency for the pdata quirks for passing the auxdata to the driver. Regards, Tony --- Tony Lindgren (6): ARM: dts: Fix pinctrl mask for omap3 ARM: OMAP2+: Add support for auxdata pinctrl: single: Prepare for supporting SoC specific features pinctrl: single: Add support for wake-up interrupts pinctrl: single: Add support for auxdata ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap .../devicetree/bindings/pinctrl/pinctrl-single.txt | 11 + arch/arm/boot/dts/omap3.dtsi |8 arch/arm/boot/dts/omap4.dtsi |4 arch/arm/mach-omap2/board-generic.c|5 arch/arm/mach-omap2/common.h |3 arch/arm/mach-omap2/mux.c |8 arch/arm/mach-omap2/mux.h |4 arch/arm/mach-omap2/pdata-quirks.c | 29 +- arch/arm/mach-omap2/prm3xxx.h |8 arch/arm/mach-omap2/prm44xx_54xx.h |8 arch/arm/mach-omap2/prm_common.c | 11 + drivers/pinctrl/pinctrl-single.c | 386 include/dt-bindings/pinctrl/omap.h |4 include/linux/platform_data/pinctrl-single.h | 12 + 14 files changed, 474 insertions(+), 27 deletions(-) create mode 100644 include/linux/platform_data/pinctrl-single.h -- 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 1/6] ARM: dts: Fix pinctrl mask for omap3
The wake-up interrupt bit is available on omap3/4/5 processors
unlike what we claim. Without fixing it we cannot use it on
omap3 and the system configured for wake-up events will just
hang on wake-up.
Cc: Grygorii Strashko grygorii.stras...@ti.com
Cc: Benoît Cousson bcous...@baylibre.com
Cc: devicet...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3.dtsi |4 ++--
arch/arm/mach-omap2/mux.h |4 +---
include/dt-bindings/pinctrl/omap.h |4 +---
3 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7d95cda..b41bd57 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -108,7 +108,7 @@
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7f1f;
+ pinctrl-single,function-mask = 0xff1f;
};
omap3_pmx_wkup: pinmux@0x48002a00 {
@@ -117,7 +117,7 @@
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
- pinctrl-single,function-mask = 0x7f1f;
+ pinctrl-single,function-mask = 0xff1f;
};
gpio1: gpio@4831 {
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 5d2080e..16f78a9 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -28,7 +28,7 @@
#define OMAP_PULL_UP (1 4)
#define OMAP_ALTELECTRICALSEL (1 5)
-/* 34xx specific mux bit defines */
+/* omap3/4/5 specific mux bit defines */
#define OMAP_INPUT_EN (1 8)
#define OMAP_OFF_EN(1 9)
#define OMAP_OFFOUT_EN (1 10)
@@ -36,8 +36,6 @@
#define OMAP_OFF_PULL_EN (1 12)
#define OMAP_OFF_PULL_UP (1 13)
#define OMAP_WAKEUP_EN (1 14)
-
-/* 44xx specific mux bit defines */
#define OMAP_WAKEUP_EVENT (1 15)
/* Active pin states */
diff --git a/include/dt-bindings/pinctrl/omap.h
b/include/dt-bindings/pinctrl/omap.h
index edbd250..bed35e3 100644
--- a/include/dt-bindings/pinctrl/omap.h
+++ b/include/dt-bindings/pinctrl/omap.h
@@ -23,7 +23,7 @@
#define PULL_UP(1 4)
#define ALTELECTRICALSEL (1 5)
-/* 34xx specific mux bit defines */
+/* omap3/4/5 specific mux bit defines */
#define INPUT_EN (1 8)
#define OFF_EN (1 9)
#define OFFOUT_EN (1 10)
@@ -31,8 +31,6 @@
#define OFF_PULL_EN(1 12)
#define OFF_PULL_UP(1 13)
#define WAKEUP_EN (1 14)
-
-/* 44xx specific mux bit defines */
#define WAKEUP_EVENT (1 15)
/* Active pin states */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] ARM: OMAP2+: Add support for auxdata
For few things we're still going to be needing platform
data for device tree based drivers. Let's set up auxdata
handling and do it in pdata-quirks.c so we have all the
legacy calls in one place.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-generic.c |5 +
arch/arm/mach-omap2/common.h|3 ++-
arch/arm/mach-omap2/pdata-quirks.c | 11 ++-
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index a66575f..3017a9d 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -35,10 +35,7 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
static void __init omap_generic_init(void)
{
- omap_sdrc_init(NULL, NULL);
-
- of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
- pdata_quirks_init();
+ pdata_quirks_init(omap_dt_match_table);
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index fd059e0..c6aebf0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -288,7 +288,8 @@ static inline void omap4_cpu_resume(void)
#endif
-void pdata_quirks_init(void);
+void pdata_quirks_init(struct of_device_id *);
+void omap_pcs_legacy_init(int irq, void (*rearm)(void));
struct omap_sdrc_params;
extern void omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d472db..c739631 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -11,6 +11,7 @@
#include linux/gpio.h
#include linux/init.h
#include linux/kernel.h
+#include linux/of_platform.h
#include linux/wl12xx.h
#include common.h
@@ -99,6 +100,10 @@ static void __init omap5_uevm_legacy_init(void)
}
#endif
+struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
+ { /* sentinel */ },
+};
+
static struct pdata_init pdata_quirks[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
{ nokia,omap3-n9, hsmmc2_internal_input_clk, },
@@ -114,10 +119,14 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ /* sentinel */ },
};
-void __init pdata_quirks_init(void)
+void __init pdata_quirks_init(struct of_device_id *omap_dt_match_table)
{
struct pdata_init *quirks = pdata_quirks;
+ omap_sdrc_init(NULL, NULL);
+ of_platform_populate(NULL, omap_dt_match_table,
+omap_auxdata_lookup, NULL);
+
while (quirks-compatible) {
if (of_machine_is_compatible(quirks-compatible)) {
if (quirks-fn)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
The pin control registers can have interrupts for example
for device wake-up. These interrupts can be treated as a
chained interrupt controller as suggested earlier by
Linus Walleij linus.wall...@linaro.org.
This patch adds support for interrupts in a way that
should be pretty generic, and works for the omaps that
support wake-up interrupts. On omaps, there's an
interrupt enable and interrupt status bit for each pin.
The two pinctrl domains on omaps share a single interrupt
from the PRM chained interrupt handler. Support for
other similar hardware should be easy to add.
Note that this patch does not attempt to handle the
wake-up interrupts automatically unlike the earlier
patches. This patch allows the device drivers to do
a request_irq() on the wake-up pins as needed. I'll
try to do also a separate generic patch for handling
the wake-up events automatically.
Also note that as this patch makes the pinctrl-single
an irq controller, the current bindings need some
extra trickery to use interrupts from two different
interrupt controllers for the same driver. So it
might be worth waiting a little on the patches
enabling the wake-up interrupts from drivers as there
should be a generic way to handle it coming. And also
there's been discussion of interrupts-extended binding
for using interrupts from multiple interrupt controllers.
In any case, this patch should be ready to go allowing
handling the wake-up interrupts in a generic way, or
separately from the device drivers.
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: Grygorii Strashko grygorii.stras...@ti.com
Cc: Prakash Manjunathappa prakash...@ti.com
Cc: Roger Quadros rog...@ti.com
Cc: Haojian Zhuang haojian.zhu...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-ker...@vger.kernel.org
Cc: Benoît Cousson bcous...@baylibre.com
Cc: devicet...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
.../devicetree/bindings/pinctrl/pinctrl-single.txt | 11 +
drivers/pinctrl/pinctrl-single.c | 325
2 files changed, 336 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5a02e30..7069a0b 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -72,6 +72,13 @@ Optional properties:
/* pin base, nr pins gpio function */
pinctrl-single,gpio-range = range 0 3 0 range 3 9 1;
+- interrupt-controller : standard interrupt controller binding if using
+ interrupts for wake-up events for example. In this case pinctrl-single
+ is set up as a chained interrupt controller and the wake-up interrupts
+ can be requested by the drivers using request_irq().
+
+- #interrupt-cells : standard interrupt binding if using interrupts
+
This driver assumes that there is only one register for each pin (unless the
pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
specified in the pinctrl-bindings.txt document in this directory.
@@ -121,6 +128,8 @@ pmx_core: pinmux@4a100040 {
reg = 0x4a100040 0x0196;
#address-cells = 1;
#size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-controller;
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0x;
};
@@ -131,6 +140,8 @@ pmx_wkup: pinmux@4a31e040 {
reg = 0x4a31e040 0x0038;
#address-cells = 1;
#size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-controller;
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0x;
};
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index f88d3d1..b4ff055 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -15,10 +15,14 @@
#include linux/slab.h
#include linux/err.h
#include linux/list.h
+#include linux/interrupt.h
+
+#include linux/irqchip/chained_irq.h
#include linux/of.h
#include linux/of_device.h
#include linux/of_address.h
+#include linux/of_irq.h
#include linux/pinctrl/pinctrl.h
#include linux/pinctrl/pinmux.h
@@ -152,9 +156,15 @@ struct pcs_name {
/**
* struct pcs_soc_data - SoC specific settings
* @flags: initial SoC specific PCS_FEAT_xxx values
+ * @irq: optional interrupt for the controller
+ * @irq_enable_mask: optional SoC specific interrupt enable mask
+ * @irq_status_mask: optional SoC specific interrupt status mask
*/
struct pcs_soc_data {
unsigned flags;
+ int irq;
+ unsigned irq_enable_mask;
+ unsigned irq_status_mask;
};
/**
@@ -165,6 +175,7 @@ struct pcs_soc_data {
* @dev: device entry
* @pctl: pin controller device
* @flags: mask of PCS_FEAT_xxx values
+ * @lock: spinlock for register access
* @mutex: mutex protecting the lists
* @width: bits per mux register
* @fmask:
[PATCH 6/6] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: Grygorii Strashko grygorii.stras...@ti.com
Cc: Prakash Manjunathappa prakash...@ti.com
Cc: Roger Quadros rog...@ti.com
Cc: Haojian Zhuang haojian.zhu...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3.dtsi |4
arch/arm/boot/dts/omap4.dtsi |4
arch/arm/mach-omap2/mux.c |8 ++--
arch/arm/mach-omap2/pdata-quirks.c | 18 ++
arch/arm/mach-omap2/prm3xxx.h |8 +++-
arch/arm/mach-omap2/prm44xx_54xx.h |8 +++-
arch/arm/mach-omap2/prm_common.c | 11 +++
7 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index b41bd57..6e928e8 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -107,6 +107,8 @@
reg = 0x48002030 0x05cc;
#address-cells = 1;
#size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-controller;
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0xff1f;
};
@@ -116,6 +118,8 @@
reg = 0x48002a00 0x5c;
#address-cells = 1;
#size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-controller;
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0xff1f;
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 22d9f2b..0415d5e 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -114,6 +114,8 @@
reg = 0x4a100040 0x0196;
#address-cells = 1;
#size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-controller;
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0x7fff;
};
@@ -122,6 +124,8 @@
reg = 0x4a31e040 0x0038;
#address-cells = 1;
#size-cells = 0;
+ #interrupt-cells = 1;
+ interrupt-controller;
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0x7fff;
};
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index f82cf87..48094b58 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -811,6 +811,12 @@ int __init omap_mux_late_init(void)
}
}
+ omap_mux_dbg_init();
+
+ /* see pinctrl-single-omap for the wake-up interrupt handling */
+ if (of_have_populated_dt())
+ return 0;
+
ret = request_irq(omap_prcm_event_to_irq(io),
omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
hwmod_io, omap_mux_late_init);
@@ -818,8 +824,6 @@ int __init omap_mux_late_init(void)
if (ret)
pr_warning(mux: Failed to setup hwmod io irq %d\n, ret);
- omap_mux_dbg_init();
-
return 0;
}
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index c739631..1f047f4 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -14,6 +14,8 @@
#include linux/of_platform.h
#include linux/wl12xx.h
+#include linux/platform_data/pinctrl-single.h
+
#include common.h
#include common-board-devices.h
#include dss-common.h
@@ -100,7 +102,23 @@ static void __init omap5_uevm_legacy_init(void)
}
#endif
+static struct pcs_pdata pcs_pdata;
+
+void omap_pcs_legacy_init(int irq, void (*rearm)(void))
+{
+ pcs_pdata.irq = irq;
+ pcs_pdata.rearm = rearm;
+}
+
struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
+#ifdef CONFIG_ARCH_OMAP3
+ OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002030, 48002030.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap3-padconf, 0x48002a00, 48002a00.pinmux,
pcs_pdata),
+#endif
+#ifdef CONFIG_ARCH_OMAP4
+ OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a100040, 4a100040.pinmux,
pcs_pdata),
+ OF_DEV_AUXDATA(ti,omap4-padconf, 0x4a31e040, 4a31e040.pinmux,
pcs_pdata),
+#endif
{ /* sentinel */ },
};
diff --git a/arch/arm/mach-omap2/prm3xxx.h b/arch/arm/mach-omap2/prm3xxx.h
index 277f717..f8eb833 100644
--- a/arch/arm/mach-omap2/prm3xxx.h
+++ b/arch/arm/mach-omap2/prm3xxx.h
@@ -144,7 +144,13 @@ extern u32
[PATCH 5/6] pinctrl: single: Add support for auxdata
For omaps, we still have dependencies to the legacy code
for handling the PRM (Power Reset Management) interrupts,
and also for reconfiguring the io wake-up chain after
changes.
Let's pass the PRM interrupt and the rearm functions via
auxdata. Then when at some point we have a proper PRM
driver, we can get the interrupt via device tree and
set up the rearm function as exported function in the
PRM driver.
By using auxdata we can remove a dependency to the
wake-up events for converting omap3 to be device
tree only.
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: Grygorii Strashko grygorii.stras...@ti.com
Cc: Prakash Manjunathappa prakash...@ti.com
Cc: Roger Quadros rog...@ti.com
Cc: Haojian Zhuang haojian.zhu...@linaro.org
Cc: Linus Walleij linus.wall...@linaro.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/pinctrl/pinctrl-single.c | 23 +++
include/linux/platform_data/pinctrl-single.h | 12
2 files changed, 35 insertions(+)
create mode 100644 include/linux/platform_data/pinctrl-single.h
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index b4ff055..e7092e8 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -28,6 +28,8 @@
#include linux/pinctrl/pinmux.h
#include linux/pinctrl/pinconf-generic.h
+#include linux/platform_data/pinctrl-single.h
+
#include core.h
#include pinconf.h
@@ -159,12 +161,14 @@ struct pcs_name {
* @irq: optional interrupt for the controller
* @irq_enable_mask: optional SoC specific interrupt enable mask
* @irq_status_mask: optional SoC specific interrupt status mask
+ * @rearm: optional SoC specific wake-up rearm function
*/
struct pcs_soc_data {
unsigned flags;
int irq;
unsigned irq_enable_mask;
unsigned irq_status_mask;
+ void (*rearm)(void);
};
/**
@@ -1622,6 +1626,8 @@ static void pcs_irq_unmask(struct irq_data *d)
struct pcs_soc_data *pcs_soc = irq_data_get_irq_chip_data(d);
pcs_irq_set(pcs_soc, d-irq, true);
+ if (pcs_soc-rearm)
+ pcs_soc-rearm();
}
/**
@@ -1672,6 +1678,11 @@ static int pcs_irq_handle(struct pcs_soc_data *pcs_soc)
}
}
+ /*
+* For debugging on omaps, you may want to call pcs_soc-rearm()
+* here to see wake-up interrupts during runtime also.
+*/
+
return count;
}
@@ -1838,6 +1849,7 @@ static int pcs_probe(struct platform_device *pdev)
{
struct device_node *np = pdev-dev.of_node;
const struct of_device_id *match;
+ struct pcs_pdata *pdata;
struct resource *res;
struct pcs_device *pcs;
const struct pcs_soc_data *soc;
@@ -1952,6 +1964,17 @@ static int pcs_probe(struct platform_device *pdev)
if (pcs-socdata.irq)
pcs-flags |= PCS_FEAT_IRQ;
+ /* We still need auxdata for some omaps for PRM interrupts */
+ pdata = dev_get_platdata(pdev-dev);
+ if (pdata) {
+ if (pdata-rearm)
+ pcs-socdata.rearm = pdata-rearm;
+ if (pdata-irq) {
+ pcs-socdata.irq = pdata-irq;
+ pcs-flags |= PCS_FEAT_IRQ;
+ }
+ }
+
if (PCS_HAS_IRQ) {
ret = pcs_irq_init_chained_handler(pcs, np);
if (ret 0)
diff --git a/include/linux/platform_data/pinctrl-single.h
b/include/linux/platform_data/pinctrl-single.h
new file mode 100644
index 000..72eacda
--- /dev/null
+++ b/include/linux/platform_data/pinctrl-single.h
@@ -0,0 +1,12 @@
+/**
+ * irq:optional wake-up interrupt
+ * rearm: optional soc specific rearm function
+ *
+ * Note that the irq and rearm setup should come from device
+ * tree except for omap where there are still some dependencies
+ * to the legacy PRM code.
+ */
+struct pcs_pdata {
+ int irq;
+ void (*rearm)(void);
+};
--
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
