Re: Strange OMAP3 LCD display regression - bisected.
Hi, On 02/06/13 09:50, NeilBrown wrote: The details: I'm currently trying to move from a 3.7 kernel on my GTA04 to a 3.10-rc kernel (hopefully to have 3.10 fully working by the time it comes out..). I presume the panel driver is not in the mainline? Is there anything special with the panel, or is it just a dummy DPI panel that doesn't need any kind of configuration? Once I got it compiling and booting I found that while the display worked perfectly at boot, after it has been turned off (ioctl(FBIOBLANK)) and back on again, it is all white - no discernible image at all. I'll try blanking on my omap3 board with 3.10-rc (I think I haven't tried it). Did you check if the DSS hardware lost context (visible from the PM counters)? A suspend/resume cycle at this point might bring it back, but it is often shimmery (low vsync?) and once it had inverse colours. I had noticed that the panel which normally gets a 22153 kHz pixel clock was only getting a 21600 kHz clock. This turned out to be due to the fact that dpi_calc_dispc_cb rejects odd divisors, and it used to use a divisor of '3'. Normally panels should not be that picky. In my experience the pixel clock has to be very far from the nominal, until the panel start to fail. However, the code in dpi_calc_dispc_cb only rejects odd divisors, if the pixel clock is greater than 100MHz. So I don't understand how you're seeing it affect here. Are you sure the pclk is ~22MHz? I tried reverting the OMAPDSS: fix TV-out issue with DSI PLL patch from 3.10-rc as below, and it seems to behave better, returning from blank properly. This is without disabling the no odd divisors code. Odd, indeed. Without reverting the patch, the DSS uses a clock from the PRCM as func clock and for pixel clock. As the common clock framework is somehow involved in the breakage, maybe (pure guess) something related to the PRCM clock is configured wrong. And with reverting the above patch, DSS uses DSI PLL for fclk and pclk, and DSI PLL in turn only needs sysclk, so maybe the possible problem with PRCM doesn't affect this case. Tomi signature.asc Description: OpenPGP digital signature
Re: Strange OMAP3 LCD display regression - bisected.
Tomi, Odd, indeed. Without reverting the patch, the DSS uses a clock from the PRCM as func clock and for pixel clock. As the common clock framework is somehow involved in the breakage, maybe (pure guess) something related to the PRCM clock is configured wrong. So whats the specific PRCM clock thats used here? I can go check if there is something different in the way its modeled with/without common clk. regards, Rajendra And with reverting the above patch, DSS uses DSI PLL for fclk and pclk, and DSI PLL in turn only needs sysclk, so maybe the possible problem with PRCM doesn't affect this case. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] i2c: omap: correct usage of the interrupt enable register
We've been lucky not to have any interrupts fire during the suspend
path, otherwise we would have unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_suspend() function. In the other side kernel
writes saved interrupt flags to the I2C_IE register in
omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
during suspend.
This works for chips with version1 registers scheme. Interrupts are
disabled during suspend. For chips with version2 scheme registers
writting 0 to the I2C_IE register does nothing (because now the
I2C_IRQENABLE_SET register is located at this address). This register
is used to enable interrupts. For disabling interrupts
I2C_IRQENABLE_CLR register should be used.
Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
addresses, the interrupt enabling procedure is unchanged.
I've checked that interrupts in the i2c controller are still enabled
after writting 0 to the I2C_IRQENABLE_SET register. With this patch
interrupts are disabled in the omap_i2c_runtime_suspend() function.
Patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
tag: v3.10-rc2
Verified on OMAP4430.
Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..64c26f9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -180,6 +180,8 @@ enum {
#define I2C_OMAP_ERRATA_I207 (1 0)
#define I2C_OMAP_ERRATA_I462 (1 1)
+#define OMAP_I2C_IP_V2_INTERRUPTS_MASK 0x6FFF
+
struct omap_i2c_dev {
spinlock_t lock; /* IRQ synchronization */
struct device *dev;
@@ -193,6 +195,7 @@ struct omap_i2c_dev {
long latency);
u32 speed; /* Speed of bus in kHz */
u32 flags;
+ u16 scheme;
u16 cmd_err;
u8 *buf;
u8 *regs;
@@ -1082,7 +1085,7 @@ omap_i2c_probe(struct platform_device *pdev)
int irq;
int r;
u32 rev;
- u16 minor, major, scheme;
+ u16 minor, major;
/* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1159,8 +1162,8 @@ omap_i2c_probe(struct platform_device *pdev)
*/
rev = __raw_readw(dev-base + 0x04);
- scheme = OMAP_I2C_SCHEME(rev);
- switch (scheme) {
+ dev-scheme = OMAP_I2C_SCHEME(rev);
+ switch (dev-scheme) {
case OMAP_I2C_SCHEME_0:
dev-regs = (u8 *)reg_map_ip_v1;
dev-rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG);
@@ -1289,7 +1292,11 @@ static int omap_i2c_runtime_suspend(struct device *dev)
_dev-iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
- omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+ if (_dev-scheme == OMAP_I2C_SCHEME_0)
+ omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+ else
+ omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR,
+ OMAP_I2C_IP_V2_INTERRUPTS_MASK);
if (_dev-rev OMAP_I2C_OMAP1_REV_2) {
omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
--
1.8.2.rc2
--
To unsubscribe from this list: send the line unsubscribe 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: Strange OMAP3 LCD display regression - bisected.
On 03/06/13 10:33, Rajendra Nayak wrote: Tomi, Odd, indeed. Without reverting the patch, the DSS uses a clock from the PRCM as func clock and for pixel clock. As the common clock framework is somehow involved in the breakage, maybe (pure guess) something related to the PRCM clock is configured wrong. So whats the specific PRCM clock thats used here? I can go check if there is something different in the way its modeled with/without common clk. I don't know which OMAP version we're talking about, but I guess it's OMAP3xxx. From the TRM, it's DPLL4_ALWON_FCLKOUTM4X2 for OMAP34xx and OMAP36xx. Although that is a bit odd, as I think the x2 is only for OMAP34xx. Maybe the clock name is wrong for OMAP36xx on my TRM... Tomi signature.asc Description: OpenPGP digital signature
Re: Strange OMAP3 LCD display regression - bisected.
Hi Neil, On Sun, 2 Jun 2013, NeilBrown wrote: Any help anyone could provide here would be greatly appreciated. I'm happy to run any test patches you would like to suggest. Just for kicks, you might consider this patch: http://marc.info/?l=linux-arm-kernelm=136990713027683w=2 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 11/14] Documentation: dt: binding: omap: am43x timer
Hi Benoit,
On Wed, May 29, 2013 at 19:05:35, Cousson, Benoit wrote:
And in this case, you do not introduce any new revision.
There is no point to update the binding each time we add a new SoC
variant that will contain the exact same IP.
I think it will mainly confuse the user that will wonder what is
different in that version compare to the previous one, moreover we can
end up with hundred of entries for the exact same IP for nothing.
The real problem is due to the introduction of the SoC name in the
device compatible name. That does introduced a SoC level information
that is mostly irrelevant at device level. I can understand why it was
done for practical aspect when the IP version is not well identified,
but that can lead to this proliferation of new pointless bindings.
As opinions on $subject seems not yet to be conclusive, I plan to
rebase DTS patch (14/14) over your 'for_3.11/dts' branch (that makes
use of C preprocessor on OMAP DTS) and post separately dropping
11-14 patches, is that okay ?
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH v2 1/1] ARM : omap3 : fix wrong container_of in clock36xx.c
2013/5/31 Mike Turquette mturque...@linaro.org:
Quoting Jean-Philippe Francois (2013-05-30 01:50:27)
omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of the
clock
to be a clk_hw_omap. However, looking at cclock3xxx_data.c, all concerned
clock
have parent defined as clk_divider. Instead of using container_of to
eventually get
to the register and directly mess with the divider, change freq via
clk_set_rate,
and let the clock framework toggle the divider value.
Tested with 3.9 on dm3730.
Signed-off-by: Jean-Philippe Fran��ois jp.franc...@cynove.com
Did you use git-format-patch to create this patch? Its a bit nicer to
use that or if you just use diff then use diff -up or diff -uprN
(taken from Documentation/SubmittingPatches.txt).
It is easier for my build system to work with tarball + quilt patches, so
I am not working with git. I will look into the alternative you provided.
Also did you test this to make sure it works? I don't mean a boot test,
but actually disabling/re-enabling an HSDIVIDER on 3630? The previous
code just programmed the clksel field to 1, and this code divides the
rate by 2, then restores it. I just used that as an example in my
previous email and it needs to be verified that it works (though it
should if I remember this errata correctly).
Yes, it is exactly what happens on my board when using the camera, because
the sensor clock is provided by the SoC. So this patch works for this
particular clock.
If the asked frequency is the lower limit of the frequency range, then
asking for half the
frequency won't change the divider, but I think it is not a problem in practice.
If that testing is done and everything looks good then please add:
Acked-by: Mike Turquette mturque...@linaro.org
How should I proceed ? Should I just add the acked by below, or should
I resend the patch ?
Jean-Philippe François
Index: b/arch/arm/mach-omap2/clock36xx.c
===
--- a/arch/arm/mach-omap2/clock36xx.c
+++ b/arch/arm/mach-omap2/clock36xx.c
@@ -39,30 +39,25 @@
*/
int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk_hw *clk)
{
- struct clk_hw_omap *parent;
- struct clk_hw *parent_hw;
- u32 dummy_v, orig_v, clksel_shift;
int ret;
/* Clear PWRDN bit of HSDIVIDER */
ret = omap2_dflt_clk_enable(clk);
- parent_hw = __clk_get_hw(__clk_get_parent(clk-clk));
- parent = to_clk_hw_omap(parent_hw);
-
- /* Restore the dividers */
+ /* kick parent's clksel register after toggling PWRDN bit */
if (!ret) {
- clksel_shift = __ffs(parent-clksel_mask);
- orig_v = __raw_readl(parent-clksel_reg);
- dummy_v = orig_v;
-
- /* Write any other value different from the Read value */
- dummy_v ^= (1 clksel_shift);
- __raw_writel(dummy_v, parent-clksel_reg);
-
- /* Write the original divider */
- __raw_writel(orig_v, parent-clksel_reg);
+ struct clk *parent = clk_get_parent(clk-clk);
+ unsigned long parent_rate = clk_get_rate(parent);
+ ret = clk_set_rate(parent, parent_rate/2);
+ if(ret)
+ goto badfreq;
+ ret = clk_set_rate(parent, parent_rate);
+ if(ret)
+ goto badfreq;
}
+ return ret;
+ badfreq :
+ omap2_dflt_clk_disable(clk);
return ret;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Undeliverable Mail
No message body: h...@iberotelmakadisarayaresort.com Original message follows. -- To unsubscribe from this list: send the line unsubscribe 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: Strange OMAP3 LCD display regression - bisected.
2013/6/2 NeilBrown ne...@suse.de: Hi Tomi, Rajendra and other, I have run into a rather strange regression with the LCD panel display on my GTA04 (OMAP3630 based phone) that you might be able to help me with. I bisected down to two patches, neither of which cause the problem by themselves, but both together do. They are: commit bd0f5cc3641cb76ae8fa2cc4924c29da157f8b2d Author: Tomi Valkeinen tomi.valkei...@ti.com Date: Thu Dec 13 14:21:30 2012 +0200 OMAPDSS: fix TV-out issue with DSI PLL and commit f7f73aab3d5bd19ba0f72ff00fb6b3be28e1a4d3 Author: Rajendra Nayak rna...@ti.com Date: Fri Apr 27 16:27:51 2012 +0530 ARM: OMAP: clock: Switch to COMMON clk Yes - rather odd. Does this patch solve your issue ? https://patchwork.kernel.org/patch/2634161/ Regards, Jean-Philippe François The details: I'm currently trying to move from a 3.7 kernel on my GTA04 to a 3.10-rc kernel (hopefully to have 3.10 fully working by the time it comes out..). Once I got it compiling and booting I found that while the display worked perfectly at boot, after it has been turned off (ioctl(FBIOBLANK)) and back on again, it is all white - no discernible image at all. A suspend/resume cycle at this point might bring it back, but it is often shimmery (low vsync?) and once it had inverse colours. I had noticed that the panel which normally gets a 22153 kHz pixel clock was only getting a 21600 kHz clock. This turned out to be due to the fact that dpi_calc_dispc_cb rejects odd divisors, and it used to use a divisor of '3'. I disabled that code and then the screen would wake successfully resume from blank, but there was a strange artefact in the image. My display has a grey background with some blue text. On the lines that have text, the grey background had a very slight green tinge, especially when viewed at the right angle. I decided to try bisecting to find the cause of this, because I couldn't even begin to guess what it might be. I found: commit 2b8318881ddbcb67c5e8d2178b4228474944 Merge: e81d372 e7f5c9a Author: Linus Torvalds torva...@linux-foundation.org Date: Sat Dec 15 13:03:48 2012 -0800 Merge tag 'fbdev-for-3.8' of git://gitorious.org/linux-omap-dss2/linux Pull fbdev changes from Tomi Valkeinen: OMAPDSS changes, including: yes - a merge commit. Neither branch by itself caused the problem but the two together do. I then decided in for a penny, in for a pound and proceeded to bisect both branches, merging in the other one at each test point. This lead me to the two commits listed above. bd0f5cc3641cb76 merged with e81d372 has the problem, bd0f5cc3641cb76~1 merged with e81d372 is fine. Similarly f7f73aab3d5bd19b merged with e7f5c9a has the problem, while f7f73aab3d5bd19b~1 merged with e7f5c9a is fine. I tried reverting the OMAPDSS: fix TV-out issue with DSI PLL patch from 3.10-rc as below, and it seems to behave better, returning from blank properly. This is without disabling the no odd divisors code. I'm not really sure how it survives suspend, as suspend generally isn't reliable for me on 3.10-rc yet - haven't look into why as yet. Any help anyone could provide here would be greatly appreciated. I'm happy to run any test patches you would like to suggest. Thanks, NeilBrown diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c index 757b57f..4d4f775 100644 --- a/drivers/video/omap2/dss/dpi.c +++ b/drivers/video/omap2/dss/dpi.c @@ -62,7 +62,7 @@ static struct platform_device *dpi_get_dsidev(enum omap_channel channel) case OMAPDSS_VER_OMAP34xx_ES3: case OMAPDSS_VER_OMAP3630: case OMAPDSS_VER_AM35xx: - return NULL; +// return NULL; case OMAPDSS_VER_OMAP4430_ES1: case OMAPDSS_VER_OMAP4430_ES2: -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc1
On Tue, 21 May 2013, Kevin Hilman wrote: I also just noticed that 3730beaglexm has stopped waking from suspend via RTC (non-DT boot.) Waking from UART console still works. Worked fine on v3.9, so there's a regressions somewhere. Thanks Kevin, noted this in the logs. Please let me know when it starts working again. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange OMAP3 LCD display regression - bisected.
On Mon, 3 Jun 2013 10:24:18 +0300 Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Hi,
On 02/06/13 09:50, NeilBrown wrote:
The details:
I'm currently trying to move from a 3.7 kernel on my GTA04 to a 3.10-rc
kernel (hopefully to have 3.10 fully working by the time it comes out..).
I presume the panel driver is not in the mainline? Is there anything
special with the panel, or is it just a dummy DPI panel that doesn't
need any kind of configuration?
Not in mainline. If you are interested it is here:
http://git.neil.brown.name/?p=gta04.git;a=blob;f=drivers/video/omap2/displays/panel-tpo-td028ttec1.c;h=c127e47b88ff2822fc0f168ed6706e16d6115abf;hb=69c0e01e14bd9651a1768f8108d21d39334e724b
Needs lots of cleanup. Pokes at a bunch of SPI registers which I might have
documentation for somewhere but haven't had time to look at it yet.
Once I got it compiling and booting I found that while the display worked
perfectly at boot, after it has been turned off (ioctl(FBIOBLANK)) and back
on again, it is all white - no discernible image at all.
I'll try blanking on my omap3 board with 3.10-rc (I think I haven't
tried it). Did you check if the DSS hardware lost context (visible from
the PM counters)?
I turned on some debugging statements and the mentioned lost-context counters
in a way that suggested they were being handled correctly (save and restore
reported appropriately matching numbers).
A suspend/resume cycle at this point might bring it back, but it is often
shimmery (low vsync?) and once it had inverse colours.
I had noticed that the panel which normally gets a 22153 kHz pixel clock
was
only getting a 21600 kHz clock. This turned out to be due to the fact
that dpi_calc_dispc_cb rejects odd divisors, and it used to use a divisor
of
'3'.
Normally panels should not be that picky. In my experience the pixel
clock has to be very far from the nominal, until the panel start to fail.
As I said, it works fine at first boot. So the panel obviously copes. But
something weird happens at blank/unblack which is affect by the pixel clock
setting in a non-obvious way.
However, the code in dpi_calc_dispc_cb only rejects odd divisors, if the
pixel clock is greater than 100MHz. So I don't understand how you're
seeing it affect here. Are you sure the pclk is ~22MHz?
If think you got some maths wrong.
dpi_calc_dispc_cb() contains:
if (ctx-pck_min = 100) {
which isn't 100MHz, unless the units are 0.1KHz, which seems unlikely.
It looks to me like the units for pck_min is Hz, so the cut off is 1MHz.
So that should be:
if (ctx-pck_min = 1) {
??
I tried reverting the OMAPDSS: fix TV-out issue with DSI PLL patch from
3.10-rc as below, and it seems to behave better, returning from blank
properly. This is without disabling the no odd divisors code.
Odd, indeed. Without reverting the patch, the DSS uses a clock from the
PRCM as func clock and for pixel clock. As the common clock framework is
somehow involved in the breakage, maybe (pure guess) something related
to the PRCM clock is configured wrong.
And with reverting the above patch, DSS uses DSI PLL for fclk and pclk,
and DSI PLL in turn only needs sysclk, so maybe the possible problem
with PRCM doesn't affect this case.
I'll try the patch that Paul and Jean-Philippe suggested and report the
results.
Thanks
NeilBrown
signature.asc
Description: PGP signature
OMAP baseline test results for v3.10-rc2
Here are some basic OMAP test results for Linux v3.10-rc2.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc2/20130527225935/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a,
omap1_defconfig, omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only, omap2plus_defconfig,
omap2plus_defconfig_2430sdp_only
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig,
rmk_omap4430_sdp_oldconfig
Build: zImage:
Pass ( 1/ 1): omap2plus_defconfig
Boot to userspace:
FAIL ( 4/12): 2430sdp, 37xxevm, am335xbone, am335xbonelt
Pass ( 8/12): 2420n800, 3517evm, 3530es3beagle, 3730beaglexm,
4430es2panda, 4460pandaes, 5912osk, cmt3517
PM: chip retention via suspend:
FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda
Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes
PM: chip retention via dynamic idle:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM: chip off except CORE via suspend:
Pass ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle:
Pass ( 1/ 1): 3730beaglexm
PM: chip off via suspend:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
PM: chip off via dynamic idle:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
Failing tests: fixed by posted patches
--
Boot:
* ARMv6 OMAPs don't boot with omap2plus_defconfig
- missing Kconfig
- http://marc.info/?l=linux-omapm=136872761502689w=2
Failing tests: needing investigation
Boot tests:
* 3517EVM CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
- Not currently part of the automated test suite
* 37xx EVM: boot fails
- Cause unknown
Boot warnings:
* 2420N800: failed to get counter_32k resource
- omap2_sync32k_clocksource_init: failed to get counter_32k resource
- Cause unknown
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2
- Longstanding issue; does not occur on the 3517EVM
* 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup failure
- Cause unknown
- These IP blocks don't exist on OMAP3xxx/AM35xx chips
* 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure
- Cause unknown
PM tests:
* 2430sdp: power domains not entering retention
- Cause unknown
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate (debug ignore_loglevel)
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
* 4430es2panda: pwrdm state mismatch on CAM, DSS
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
- http://marc.info/?l=linux-arm-kernelm=136432340618226w=2
* 4430es2panda: MPU, ABE didn't enter target state
- New for v3.10-rc
* 4460pandaes: pwrdm state mismatch on DSS, ABE, IVAHD, TESLA
* 4460pandaes: chip not entering retention in dynamic idle
- Presumably 4430es2panda also fails this
- Suspend-to-RAM enters full chip retention
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter and Santosh Shilimkar report this does not appear with
the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
ES-level dependent
Failing tests: reported by others
-
- RTC wakeup from suspend broken on 3730beaglexm
- as of v3.10-rc1
- discussion here: http://marc.info/?l=linux-omapm=136915841625434w=2
vmlinux object size
(delta in bytes from test_v3.10-rc1
(f722406faae2d073cc1d01063d1123c35425939e)):
text data bsstotal kernel
-1064 +400-1024 am33xx_only
-532 +480 -484 n800_multi_omap2xxx
-532 +480 -484 n800_only_a
-628 +160 -612 omap1_defconfig
-628 +480 -580 omap1_defconfig_1510innovator_only
-660 +480 -612 omap1_defconfig_5912osk_only
-1156 +400-1116 omap2plus_defconfig
Re: [PATCH] arm: omap2: fix AM33xx hwmod infos for UART2
On Tue, 28 May 2013, Thomas Petazzoni wrote: The UART2 hwmod structure is pointing to the EDMA channels of UART1, which doesn't look right. This patch fixes this by making the UART2 hwmod structure to a new structure that lists the EDMA channels to be used by the UART2. Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Thanks Thomas, queued with Vaibhav's ack. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Strange OMAP3 LCD display regression - bisected.
On 03/06/13 11:57, NeilBrown wrote:
On Mon, 3 Jun 2013 10:24:18 +0300 Tomi Valkeinen tomi.valkei...@ti.com
I'll try blanking on my omap3 board with 3.10-rc (I think I haven't
tried it). Did you check if the DSS hardware lost context (visible from
the PM counters)?
I turned on some debugging statements and the mentioned lost-context counters
in a way that suggested they were being handled correctly (save and restore
reported appropriately matching numbers).
I was mostly interested in whether the DSS goes into OFF mode when you
blank the panel or not. If it does, and it doesn't work after unblank,
it could suggest that somehow the DSS registers are not restored correctly.
I did some testing on my Overo board (3430), and it works fine if I
blank the display, or suspend the device. However, I think I'm missing
something here, as the DSS domain just stays in ON-state, even if disabled.
A suspend/resume cycle at this point might bring it back, but it is often
shimmery (low vsync?) and once it had inverse colours.
I had noticed that the panel which normally gets a 22153 kHz pixel clock
was
only getting a 21600 kHz clock. This turned out to be due to the fact
that dpi_calc_dispc_cb rejects odd divisors, and it used to use a divisor
of
'3'.
Normally panels should not be that picky. In my experience the pixel
clock has to be very far from the nominal, until the panel start to fail.
As I said, it works fine at first boot. So the panel obviously copes. But
something weird happens at blank/unblack which is affect by the pixel clock
setting in a non-obvious way.
Right. You don't have the option to measure the pixel clock with an
oscilloscope?
However, the code in dpi_calc_dispc_cb only rejects odd divisors, if the
pixel clock is greater than 100MHz. So I don't understand how you're
seeing it affect here. Are you sure the pclk is ~22MHz?
If think you got some maths wrong.
dpi_calc_dispc_cb() contains:
if (ctx-pck_min = 100) {
which isn't 100MHz, unless the units are 0.1KHz, which seems unlikely.
It looks to me like the units for pck_min is Hz, so the cut off is 1MHz.
So that should be:
if (ctx-pck_min = 1) {
??
Indeed, it's plain wrong. The original patch introducing that limit is
b7f1fe541b01f6edaff0a5dd48027de6ac711ab6 , from which I copied the limit
to the new clock calculation. Both are from me, both are wrong. Sigh.
Thanks for pointing this out, I'll send a fix.
But, as I said earlier, I doubt that it affects your case. Especially if
the panel works after boot.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 1/1] ARM : omap3 : fix wrong container_of in clock36xx.c
On Thu, 30 May 2013, Jean-Philippe Francois wrote:
omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of the
clock
to be a clk_hw_omap. However, looking at cclock3xxx_data.c, all concerned
clock
have parent defined as clk_divider. Instead of using container_of to
eventually get
to the register and directly mess with the divider, change freq via
clk_set_rate,
and let the clock framework toggle the divider value.
Tested with 3.9 on dm3730.
Signed-off-by: Jean-Philippe Fran??ois jp.franc...@cynove.com
Queued for 3.10-rc fixes with Mike's ack, after fixing the checkpatch.pl
errors listed below. Please don't forget to run scripts/checkpatch.pl on
future patches -- Documentation/SubmittingPatches has more info about
this.
ERROR: space required before the open parenthesis '('
#59: FILE: arch/arm/mach-omap2/clock36xx.c:52:
+ if(ret)
ERROR: space required before the open parenthesis '('
#62: FILE: arch/arm/mach-omap2/clock36xx.c:55:
+ if(ret)
WARNING: please, no spaces at the start of a line
#67: FILE: arch/arm/mach-omap2/clock36xx.c:60:
+ badfreq :$
ERROR: space prohibited before that ':' (ctx:WxE)
#67: FILE: arch/arm/mach-omap2/clock36xx.c:60:
+ badfreq :
^
Updated patch follows.
- Paul
From: Jean-Philippe Francois jp.franc...@cynove.com
Date: Thu, 30 May 2013 10:50:27 +0200
Subject: [PATCH] ARM: omap3: clock: fix wrong container_of in clock36xx.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of
the clock to be a clk_hw_omap. However, looking at cclock3xxx_data.c,
all concerned clock have parent defined as clk_divider. Instead of
using container_of to eventually get to the register and directly mess
with the divider, change freq via clk_set_rate, and let the clock
framework toggle the divider value.
Tested with 3.9 on dm3730.
Signed-off-by: Jean-Philippe François jp.franc...@cynove.com
Acked-by: Mike Turquette mturque...@linaro.org
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/clock36xx.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/clock36xx.c b/arch/arm/mach-omap2/clock36xx.c
index 8f3bf4e..7f69fbb 100644
--- a/arch/arm/mach-omap2/clock36xx.c
+++ b/arch/arm/mach-omap2/clock36xx.c
@@ -39,30 +39,25 @@
*/
int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk_hw *clk)
{
- struct clk_hw_omap *parent;
- struct clk_hw *parent_hw;
- u32 dummy_v, orig_v, clksel_shift;
int ret;
/* Clear PWRDN bit of HSDIVIDER */
ret = omap2_dflt_clk_enable(clk);
- parent_hw = __clk_get_hw(__clk_get_parent(clk-clk));
- parent = to_clk_hw_omap(parent_hw);
-
- /* Restore the dividers */
+ /* kick parent's clksel register after toggling PWRDN bit */
if (!ret) {
- clksel_shift = __ffs(parent-clksel_mask);
- orig_v = __raw_readl(parent-clksel_reg);
- dummy_v = orig_v;
-
- /* Write any other value different from the Read value */
- dummy_v ^= (1 clksel_shift);
- __raw_writel(dummy_v, parent-clksel_reg);
-
- /* Write the original divider */
- __raw_writel(orig_v, parent-clksel_reg);
+ struct clk *parent = clk_get_parent(clk-clk);
+ unsigned long parent_rate = clk_get_rate(parent);
+ ret = clk_set_rate(parent, parent_rate/2);
+ if (ret)
+ goto badfreq;
+ ret = clk_set_rate(parent, parent_rate);
+ if (ret)
+ goto badfreq;
}
+ return ret;
+badfreq:
+ omap2_dflt_clk_disable(clk);
return ret;
}
--
1.7.10.4
Re: [PATCH 1/3] ARM: DTS: OMAP3: beagle/overo: mux console UART, enable wakeup
Hello Kevin,
On 06/01/2013 12:45 AM, Kevin Hilman wrote:
Ensure the console uart (UART3) on these boards is mux'd correctly, and
IO ring wakeup is enabled.
This is needed for serial console wakeups when using DT boot.
Signed-off-by: Kevin Hilman khil...@linaro.org
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 14 ++
arch/arm/boot/dts/omap3-beagle.dts| 12
arch/arm/boot/dts/omap3-overo.dtsi| 14 ++
3 files changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3046d1f..ca067b0 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -126,3 +126,17 @@
mode = 3;
power = 50;
};
+
+omap3_pmx_core {
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e 0x4100/* uart3_rx_irrx.uart3_rx_irrx WAKEUP |
INPUT | MODE0 */
+ 0x170 0x0 /* uart3_tx_irtx.uart3_tx_irtx OUTPUT |
MODE0 */
If you go through Benoit's tree, could you use the newly introduced
constants [1]? They are defined
in include/dt-bindings/pinctrl/omap.h. The above will look:
0x16e (PIN_INPUT | WAKEUP_EVENT | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx */
+ ;
+ };
+};
+
+uart3 {
+ pinctrl-names = default;
+ pinctrl-0 = uart3_pins;
+};
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 6eec699..b004372 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -95,6 +95,13 @@
0x1ae 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
;
};
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e 0x4100/* uart3_rx_irrx.uart3_rx_irrx WAKEUP |
INPUT | MODE0 */
+ 0x170 0x0 /* uart3_tx_irtx.uart3_tx_irtx OUTPUT |
MODE0 */
Same here
+ ;
+ };
};
i2c1 {
@@ -142,3 +149,8 @@
*/
ti,pulldowns = 0x03a1c4;
};
+
+uart3 {
+ pinctrl-names = default;
+ pinctrl-0 = uart3_pins;
+};
diff --git a/arch/arm/boot/dts/omap3-overo.dtsi
b/arch/arm/boot/dts/omap3-overo.dtsi
index a626c50..d63ed39 100644
--- a/arch/arm/boot/dts/omap3-overo.dtsi
+++ b/arch/arm/boot/dts/omap3-overo.dtsi
@@ -77,3 +77,17 @@
mode = 3;
power = 50;
};
+
+omap3_pmx_core {
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x16e 0x4100/* uart3_rx_irrx.uart3_rx_irrx WAKEUP |
INPUT | MODE0 */
+ 0x170 0x0 /* uart3_tx_irtx.uart3_tx_irtx OUTPUT |
MODE0 */
Same here
+ ;
+ };
+};
+
+uart3 {
+ pinctrl-names = default;
+ pinctrl-0 = uart3_pins;
+};
Regards,
Florian
[1] http://thread.gmane.org/gmane.linux.drivers.devicetree/36951
--
To unsubscribe from this list: send the line unsubscribe 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/1] ARM : omap3 : fix wrong container_of in clock36xx.c
On Mon, 3 Jun 2013, jean-philippe francois wrote: How should I proceed ? Should I just add the acked by below, or should I resend the patch ? It's been fixed up locally here. Mike, please speak up if I shouldn't apply your ack. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: DTS: OMAP3: beagle: enable user button via gpio_keys, enable wakeup
Hello Kevin,
On 06/01/2013 12:45 AM, Kevin Hilman wrote:
Using the gpio-keys bindings, configure the user button on Beagle
boards. Since the user button is enabled as a wakeup source, also
ensure the GPIO pin is mux'd correctly and has IO ring wakeups enabled,
so it can also wakeup from off mode.
Signed-off-by: Kevin Hilman khil...@linaro.org
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 25 +
arch/arm/boot/dts/omap3-beagle.dts| 25 +
2 files changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index ca067b0..c93c36f 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -57,6 +57,26 @@
ti,mcbsp = mcbsp2;
ti,codec = twl_audio;
};
+
+ gpio_keys {
+ compatible = gpio-keys;
+
+ user {
+ label = user;
+ gpios = gpio1 4 0;
Now you can also use GPIO constants (include/dt-bindings/gpio/gpio.h),
like this:
gpios = gpio1 4 GPIO_ACTIVE_HIGH;
+ linux,code = 0x114;
+ gpio-key,wakeup;
+ };
+
+ };
+};
+
+omap3_pmx_wkup {
+ gpio1_pins: pinmux_gpio1_pins {
+ pinctrl-single,pins =
+ 0x0e 0x4104 /* sys_boot2.gpio_4 WAKEUP | INPUT |
MODE4 */
As for patch 1, you can use pinctrl constants
+ ;
+ };
};
i2c1 {
@@ -140,3 +160,8 @@
pinctrl-names = default;
pinctrl-0 = uart3_pins;
};
+
+gpio1 {
+ pinctrl-names = default;
+ pinctrl-0 = gpio1_pins;
+};
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index b004372..c9794cb 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -71,6 +71,26 @@
reset-supply = hsusb2_reset;
vcc-supply = hsusb2_power;
};
+
+ gpio_keys {
+ compatible = gpio-keys;
+
+ user {
+ label = user;
+ gpios = gpio1 7 0;
GPIO constant
gpios = gpio7 7 GPIO_ACTIVE_HIGH;
+ linux,code = 0x114;
+ gpio-key,wakeup;
+ };
+
+ };
+};
+
+omap3_pmx_wkup {
+ gpio1_pins: pinmux_gpio1_pins {
+ pinctrl-single,pins =
+ 0x14 0x4104 /* sys_boot5.gpio_7 WAKEUP | INPUT |
MODE4 */
Same for pinctrl constant
+ ;
+ };
};
omap3_pmx_core {
@@ -154,3 +174,8 @@
pinctrl-names = default;
pinctrl-0 = uart3_pins;
};
+
+gpio1 {
+ pinctrl-names = default;
+ pinctrl-0 = gpio1_pins;
+};
Regards,
Florian
--
To unsubscribe from this list: send the line unsubscribe 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] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
Hello Kevin,
On 06/01/2013 12:45 AM, Kevin Hilman wrote:
On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP. Therefore, configure the defaults for the
SYS_NIRQ pin in the twl4030 DTS file.
Boards that hook up the twl4030 differently can easily override this
in their board-specific DTS file.
This allows RTC wake from off-mode to work again on OMAP3-based
platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM,
3530/Overo, 3730/Overo-STORM.
Signed-off-by: Kevin Hilman khil...@linaro.org
---
arch/arm/boot/dts/twl4030.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..c7fe9f6 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -13,6 +13,8 @@
compatible = ti,twl4030;
interrupt-controller;
#interrupt-cells = 1;
+ pinctrl-names = default;
+ pinctrl-0 = twl4030_pins;
rtc {
compatible = ti,twl4030-rtc;
@@ -92,3 +94,18 @@
#pwm-cells = 2;
};
};
+
+omap3_pmx_core {
Here you are making the TWL4030 to explicitly depend on OMAP3. Could
this chip be
used by another target? If the case, I would put this piece of code in
the files
including twl4030. Otherwise it's ok here.
+ /*
+* On most OMAP3 platforms, the twl4030 IRQ line is connected
+ * to the SYS_NIRQ line on OMAP. Therefore, configure the
+ * defaults for the SYS_NIRQ pin here. Boards that hook up
+ * the twl4030 differently can easily override this in their
+ * board-specific DTS file.
+*/
+ twl4030_pins: pinmux_twl4030_pins {
+ pinctrl-single,pins =
+ 0x1b0 0x4118 /* sys_nirq.sys_nirq WAKEUP | INPUT_PULLUP
| MODE 0 */
By using pinctrl constants:
0x1b0 (PIN_INPUT_PULLUP | WAKEUP_EN | MUX_MODE0)
/* sys_nirq.sys_nirq */
+ ;
+ };
+};
I will test this afternoon on an Overo.
Regards,
Florian
--
To unsubscribe from this list: send the line unsubscribe 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 11/14] Documentation: dt: binding: omap: am43x timer
Hi Afzal, On 06/03/2013 09:49 AM, Mohammed, Afzal wrote: Hi Benoit, On Wed, May 29, 2013 at 19:05:35, Cousson, Benoit wrote: And in this case, you do not introduce any new revision. There is no point to update the binding each time we add a new SoC variant that will contain the exact same IP. I think it will mainly confuse the user that will wonder what is different in that version compare to the previous one, moreover we can end up with hundred of entries for the exact same IP for nothing. The real problem is due to the introduction of the SoC name in the device compatible name. That does introduced a SoC level information that is mostly irrelevant at device level. I can understand why it was done for practical aspect when the IP version is not well identified, but that can lead to this proliferation of new pointless bindings. As opinions on $subject seems not yet to be conclusive, I plan to rebase DTS patch (14/14) over your 'for_3.11/dts' branch (that makes use of C preprocessor on OMAP DTS) and post separately dropping 11-14 patches, is that okay ? Yes, that sounds good to me. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP baseline test results for v3.10-rc3
Here are some basic OMAP test results for Linux v3.10-rc3.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc3/20130603032237/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a,
omap1_defconfig, omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only, omap2plus_defconfig,
omap2plus_defconfig_2430sdp_only
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig,
rmk_omap4430_sdp_oldconfig
Build: zImage:
Pass ( 1/ 1): omap2plus_defconfig
Boot to userspace:
FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
Pass ( 9/12): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 4430es2panda, 4460pandaes, 5912osk,
cmt3517
PM: chip retention via suspend:
FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda
Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes
PM: chip retention via dynamic idle:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM: chip off except CORE via suspend:
Pass ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle:
Pass ( 1/ 1): 3730beaglexm
PM: chip off via suspend:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
PM: chip off via dynamic idle:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
Failing tests: fixed by posted patches
--
(none)
Failing tests: needing investigation
Boot tests:
* 3517EVM CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
- Not currently part of the automated test suite
* 37xx EVM: boot fails
- Cause unknown
Boot warnings:
* 2420N800, 2430sdp: failed to get counter_32k resource
- omap2_sync32k_clocksource_init: failed to get counter_32k resource
- Cause unknown
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2
- Longstanding issue; does not occur on the 3517EVM
* 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup
failure
- Cause unknown
- These IP blocks don't exist on OMAP3xxx/AM35xx chips
* 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure
- Cause unknown
PM tests:
* 2430sdp: power domains not entering retention
- Cause unknown
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate (debug ignore_loglevel)
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
* 4430es2panda: pwrdm state mismatch on CAM, DSS
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
- http://marc.info/?l=linux-arm-kernelm=136432340618226w=2
* 4430es2panda: MPU, ABE didn't enter target state
- New for v3.10-rc
* 4460pandaes: pwrdm state mismatch on DSS, ABE, IVAHD, TESLA
* 4460pandaes: chip not entering retention in dynamic idle
- Presumably 4430es2panda also fails this
- Suspend-to-RAM enters full chip retention
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter and Santosh Shilimkar report this does not appear with
the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
ES-level dependent
Failing tests: reported by others
-
- RTC wakeup from suspend broken on 3730beaglexm
- as of v3.10-rc1
- discussion here: http://marc.info/?l=linux-omapm=136915841625434w=2
vmlinux object size
(delta in bytes from test_v3.10-rc2
(c7788792a5e7b0d5d7f96d0766b4cb6112d47d75)):
text data bsstotal kernel
+1848 -240+1824 am33xx_only
+856 -160 +840 n800_multi_omap2xxx
+888 -160 +872 n800_only_a
+57190 -8+5711 omap1_defconfig
+1627 -8 -8+1611 omap1_defconfig_1510innovator_only
+16270 -8+1619 omap1_defconfig_5912osk_only
+75201 +80296 +192 +155689 omap2plus_defconfig
+14022 +408 +64 +14494 omap2plus_defconfig_2430sdp_only
+94156 +82312
OMAP baseline test results for v3.10-rc4
Here are some basic OMAP test results for Linux v3.10-rc4.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.10-rc4/20130603034317/
Test summary
Build: uImage:
Pass (16/16): am33xx_only, n800_multi_omap2xxx, n800_only_a,
omap1_defconfig, omap1_defconfig_1510innovator_only,
omap1_defconfig_5912osk_only, omap2plus_defconfig,
omap2plus_defconfig_2430sdp_only
omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig,
rmk_omap4430_sdp_oldconfig
Build: zImage:
Pass ( 1/ 1): omap2plus_defconfig
Boot to userspace:
FAIL ( 3/12): 37xxevm, am335xbone, am335xbonelt
Pass ( 9/12): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 4430es2panda, 4460pandaes, 5912osk,
cmt3517
PM: chip retention via suspend:
FAIL ( 3/ 6): 2430sdp, 37xxevm, 4430es2panda
Pass ( 3/ 6): 3530es3beagle, 3730beaglexm, 4460pandaes
PM: chip retention via dynamic idle:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM: chip off except CORE via suspend:
Pass ( 1/ 1): 3730beaglexm
PM: chip off except CORE via dynamic idle:
Pass ( 1/ 1): 3730beaglexm
PM: chip off via suspend:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
PM: chip off via dynamic idle:
FAIL ( 3/ 4): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 1/ 4): 3530es3beagle
Failing tests: fixed by posted patches
--
(none)
Failing tests: needing investigation
Boot tests:
* 3517EVM CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
- Not currently part of the automated test suite
* 37xx EVM: boot fails
- Cause unknown
Boot warnings:
* 2420N800, 2430sdp: failed to get counter_32k resource
- omap2_sync32k_clocksource_init: failed to get counter_32k resource
- Cause unknown
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omapm=134833869730129w=2
- Longstanding issue; does not occur on the 3517EVM
* 2430SDP, 3730 Beagle XM, 3530 Beagle, 3517EVM, CM-T3517: {dmic,mcpdm} lookup
failure
- Cause unknown
- These IP blocks don't exist on OMAP3xxx/AM35xx chips
* 3730 Beagle XM, am335xbone, CM-T3517: uart4_rx.uart4_rx mux failure
- Cause unknown
PM tests:
* 2430sdp: power domains not entering retention
- Cause unknown
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate (debug ignore_loglevel)
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
* 4430es2panda: pwrdm state mismatch on CAM, DSS
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
- http://marc.info/?l=linux-arm-kernelm=136432340618226w=2
* 4430es2panda: MPU, ABE didn't enter target state
- New for v3.10-rc
* 4460pandaes: pwrdm state mismatch on DSS, ABE, IVAHD, TESLA
* 4460pandaes: chip not entering retention in dynamic idle
- Presumably 4430es2panda also fails this
- Suspend-to-RAM enters full chip retention
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter and Santosh Shilimkar report this does not appear with
the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
ES-level dependent
Failing tests: reported by others
-
- RTC wakeup from suspend broken on 3730beaglexm
- as of v3.10-rc1
- discussion here: http://marc.info/?l=linux-omapm=136915841625434w=2
vmlinux object size
(delta in bytes from test_v3.10-rc3
(e4aa937ec75df0eea0bee03bffa3303ad36c986b)):
text data bsstotal kernel
-32800 -328 am33xx_only
+6400 +64 n800_multi_omap2xxx
+3200 +32 n800_only_a
-51200 -512 omap1_defconfig
-51200 -512 omap1_defconfig_1510innovator_only
-51200 -512 omap1_defconfig_5912osk_only
-32800 -328 omap2plus_defconfig
-37600 -376 omap2plus_defconfig_2430sdp_only
-3280
Re: Strange OMAP3 LCD display regression - bisected.
On Mon, 3 Jun 2013 10:13:18 +0200 jean-philippe francois jp.franc...@cynove.com wrote: 2013/6/2 NeilBrown ne...@suse.de: Hi Tomi, Rajendra and other, I have run into a rather strange regression with the LCD panel display on my GTA04 (OMAP3630 based phone) that you might be able to help me with. I bisected down to two patches, neither of which cause the problem by themselves, but both together do. They are: commit bd0f5cc3641cb76ae8fa2cc4924c29da157f8b2d Author: Tomi Valkeinen tomi.valkei...@ti.com Date: Thu Dec 13 14:21:30 2012 +0200 OMAPDSS: fix TV-out issue with DSI PLL and commit f7f73aab3d5bd19ba0f72ff00fb6b3be28e1a4d3 Author: Rajendra Nayak rna...@ti.com Date: Fri Apr 27 16:27:51 2012 +0530 ARM: OMAP: clock: Switch to COMMON clk Yes - rather odd. Does this patch solve your issue ? https://patchwork.kernel.org/patch/2634161/ Yes. Thank you and Paul for pointing me to this patch. I apply it and the strange artefact goes away. Panel isn't 100% yet - sometimes uniform white again after resume from suspend, and I see [ 202.881500] omapdss APPLY error: cannot set timings for lcd: manager needs to be disabled [ 202.881530] omapdss APPLY error: cannot apply lcd config for lcd: manager needs to be disabled which I don't think I saw before, but I'm happy to track that down myself So you can add a Tested-by: NeilBrown ne...@suse.de to that patch if you like. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH] usb: dwc3: Addition of dr_mode dt property.
Hi Felipe,
On Thu, May 30, 2013 at 03:31:21PM -0500, Ruchika Kharwar wrote:
This patch adds an optional parameter dr_mode to the dwc3 core device node.
In the case the compile flag for the DWC3 controller is set to
USB_DWC3_DUAL_ROLE a device tree could restrain to either functionality of
host or gadget. In the case the device tree does not use this optional flag or
specifies it superfluously to drd the functionality will be that
of a dual role device.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |3 ++-
drivers/usb/dwc3/core.c| 20 +---
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 7a95c65..2f5d584 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -10,7 +10,8 @@ Required properties:
Optional properties:
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
-
+ - dr_mode: determines the mode of core. Supported modes are gadget, host
+ and drd.
This is usually a subnode to DWC3 glue to which it is connected.
dwc3@4a03 {
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..05c0c8b 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -378,6 +378,7 @@ static int dwc3_probe(struct platform_device *pdev)
void*mem;
u8 mode;
+ char*dr_mode;
mem = devm_kzalloc(dev, sizeof(*dwc) + DWC3_ALIGN_MASK, GFP_KERNEL);
if (!mem) {
@@ -520,9 +521,22 @@ static int dwc3_probe(struct platform_device *pdev)
mode = DWC3_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
mode = DWC3_MODE_DEVICE;
- else
- mode = DWC3_MODE_DRD;
-
+ else {
+ if (of_property_read_string(node, dr_mode, dr_mode))
+ mode = DWC3_MODE_DRD;
+ else {
+ if (strcmp(dr_mode, host) == 0)
+ mode = DWC3_MODE_HOST;
+ else if (strcmp(dr_mode, gadget) == 0)
+ mode = DWC3_MODE_DEVICE;
+ else if (strcmp(dr_mode, drd) == 0)
+ mode = DWC3_MODE_DRD;
+ else {
+ dev_err(dev, invalid dr_mode property
value\n);
+ goto err2;
+ }
+ }
+ }
switch (mode) {
case DWC3_MODE_DEVICE:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
--
1.7.5.4
this is more likely to be solved with a common property description for
the gadget layer. We have some prepared parts in the latest patch series:
[PATCH 1/7] USB: add devicetree helpers for determining dr_mode and phy_type
http://www.spinics.net/lists/linux-usb/msg86829.html
What do you think?
Thanks,
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe 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: Strange OMAP3 LCD display regression - bisected.
On 03/06/13 14:20, NeilBrown wrote: Panel isn't 100% yet - sometimes uniform white again after resume from suspend, and I see [ 202.881500] omapdss APPLY error: cannot set timings for lcd: manager needs to be disabled [ 202.881530] omapdss APPLY error: cannot apply lcd config for lcd: manager needs to be disabled which I don't think I saw before, but I'm happy to track that down myself One quite recent change was that omapdss only allows changing output config, including video timings, when the output is disabled. Changing timings when output is enabled did not work very reliably even before, but now omapdss makes sure it's not done. There may be a bug somewhere related to that. You only see those when resuming? Tomi signature.asc Description: OpenPGP digital signature
Re: [GIT PULL] omap dss board clean-up for v3.10 merge window
Hi, On 19/04/13 21:45, Olof Johansson wrote: Hi, On Wed, Apr 17, 2013 at 08:39:37PM -0700, Tony Lindgren wrote: The following changes since commit 07961ac7c0ee8b546658717034fe692fd12eefa9: Linux 3.9-rc5 (2013-03-31 15:12:43 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.10/dss-signed Merged, but not happy about it. As mentioned on IRC, I was going to let this one be until 3.11, but it sounds like it will cause regressions in DSS if we don't merge it. This is an indication that the work wasn't done right on the DSS rework. Ideally the old configurations through platform_data should have been left in for a release to give the boards a window to convert over without regressing functionality. Tomi, please don't do it this way in the future since it's painful for everybody to deal with. I have a somewhat similar situation again for 3.11 (or possibly for 3.12). I hope to hear from you what you think would be the best approach. The background is that the omap display subsystem has a bunch of panel drivers, and these drivers have used an OMAP DSS specific bus and driver model. For various reasons I'm now converting the panel drivers to be based on the panel's control bus, i.e. a panel controlled via i2c would be an i2c device/driver, a panel not controlled at all would be a platform device/driver, etc. The work involves changing the omapdss driver, converting the panel drivers to the new driver model, and changing the board files that use the panel. I see two main approaches to this: 1) Convert the panel drivers in-place, i.e. have a commit which changes a panel driver to the new model. This would mean that the instant the commit is in, the boards using the panel do not work until the board file has been changed. 2) Convert the panel to a new file, i.e. basically make a copy of the panel driver while converting it. This way the boards using the old panel drivers will continue working. (This is how I have my patches currently organized). Option 1) feels more natural, but if the arch and driver changes go through separate trees, there's a piece of history during the merge window where the displays won't work on the OMAP boards. Option 2) allows us to keep the boards always functional if the new panel drivers are merged in 3.11, and the board file changes are merged in 3.12. The downside is that it takes two kernel versions to get this in, and a third kernel version to finally remove all the old code. 3.11 and 3.12 would contain unused code, some of which will be in the kernel image (omapdss side changes) and some of which won't be compiled at all (the new panel drivers). Do you think option 2 and splitting the work into three kernel versions is the way to go? Do you have some other ideas how to organize the merge of these kind of changes? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/2] ARM: OMAP AM33XX: clock data: Enable clkout2 output on SoC pad
Salut Paul, On 05/29/2013 09:06 PM, Paul Walmsley wrote: Salut Benoît, On Mon, 27 May 2013, Benoit Cousson wrote: On 05/20/2013 04:47 AM, Paul Walmsley wrote: On Fri, 17 May 2013, Hiremath, Vaibhav wrote: Tony, Paul and Benoit, Any update on this series? Most of the changes are DT-related, so it should probably go in via Benoît. I'll ack the clock side, but have a comment on patch 2, to be sent shortly. I've tried to apply that patch, but unfortunately, it does depend on that one: https://patchwork.kernel.org/patch/2212081/ If you did not already pulled the first one I can take both with your acked-by. Otherwise, I can take only the DTS ones. Is that OK? Will ack that first patch now. Cool, Thanks Paul. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: dts: OMAP5: add PWM capability to timer nodes missing it
Hi Suman,
On 06/01/2013 12:17 AM, Anna, Suman wrote:
Benoit, Tony,
On 04/17/2013 06:23 PM, Suman Anna wrote:
OMAP5 has 6 timers (GPTimers 5, 6, 8 to 11) that are capable of PWM.
The PWM capability property is missing from the node definitions of
couple of timers, and this has been fixed.
Signed-off-by: Suman Anna s-a...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..0d155f5 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -422,6 +422,7 @@
interrupts = 0 41 0x4;
ti,hwmods = timer5;
ti,timer-dsp;
+ ti,timer-pwm;
};
timer6: timer@4013a000 {
@@ -458,6 +459,7 @@
reg = 0x4803e000 0x80;
interrupts = 0 45 0x4;
ti,hwmods = timer9;
+ ti,timer-pwm;
};
timer10: timer@48086000 {
@@ -465,6 +467,7 @@
reg = 0x48086000 0x80;
interrupts = 0 46 0x4;
ti,hwmods = timer10;
+ ti,timer-pwm;
};
timer11: timer@48088000 {
Make sure you copy the linux-arm and device-tree mailing lists.
Acked-by: Jon Hunter jon-hun...@ti.com
Can you include this patch in your next fixes pull request (if you haven't
already done so)? The other patch in the series is a feature change, but
this is a fix, and can go into 3.10 itself.
I've just sent a pull request with two fixes to Tony. Since -rc4 is
already there, I'll update it with this fix.
Tony,
I will resend a new pull-request rebased on -rc4 that will include this
new fix.
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
[PATCH v3] ARM: dts: AM43x: initial support
DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those
represented here are the minimal DT nodes necessary to get kernel
booting.
In DT nodes, ti,hwmod property has not been added, this would be
added along with PRCM support for AM43x.
Signed-off-by: Ankur Kishore a-kish...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
v3: Make use of C preprocessor, rebased over Benoit's 'for_3.11/dts' branch
v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer
arch/arm/boot/dts/am4372.dtsi | 68 +++
1 file changed, 68 insertions(+)
create mode 100644 arch/arm/boot/dts/am4372.dtsi
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
new file mode 100644
index 000..ddc1df7
--- /dev/null
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -0,0 +1,68 @@
+/*
+ * Device Tree Source for AM4372 SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/interrupt-controller/arm-gic.h
+
+#include skeleton.dtsi
+
+/ {
+ compatible = ti,am4372, ti,am43;
+ interrupt-parent = gic;
+
+
+ aliases {
+ serial0 = uart0;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a9;
+ };
+ };
+
+ gic: interrupt-controller@48241000 {
+ compatible = arm,cortex-a9-gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x48241000 0x1000,
+ 0x48240100 0x0100;
+ };
+
+ ocp {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ uart0: serial@44e09000 {
+ compatible = ti,am4372-uart,ti,omap2-uart;
+ reg = 0x44e09000 0x2000;
+ interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH;
+ };
+
+ timer1: timer@44e31000 {
+ compatible =
ti,am4372-timer-1ms,ti,am335x-timer-1ms;
+ reg = 0x44e31000 0x400;
+ interrupts = GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH;
+ ti,timer-alwon;
+ };
+
+ timer2: timer@4804 {
+ compatible = ti,am4372-timer,ti,am335x-timer;
+ reg = 0x4804 0x400;
+ interrupts = GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH;
+ };
+
+ counter32k: counter@44e86000 {
+ compatible =
ti,am4372-counter32k,ti,omap-counter32k;
+ reg = 0x44e86000 0x40;
+ };
+ };
+};
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] ARM: dts: AM33XX: Use existing constants for GPIOs
Use standard GPIO constants to enhance the readability of DT GPIOs.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/am335x-bone.dts |8
arch/arm/boot/dts/am335x-evm.dts | 14 +++---
arch/arm/boot/dts/am335x-evmsk.dts | 16
arch/arm/boot/dts/am33xx.dtsi |2 ++
4 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 0365e56..5bfb7dd 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -88,27 +88,27 @@
led@2 {
label = beaglebone:green:heartbeat;
- gpios = gpio1 21 0;
+ gpios = gpio1 21 GPIO_ACTIVE_HIGH;
linux,default-trigger = heartbeat;
default-state = off;
};
led@3 {
label = beaglebone:green:mmc0;
- gpios = gpio1 22 0;
+ gpios = gpio1 22 GPIO_ACTIVE_HIGH;
linux,default-trigger = mmc0;
default-state = off;
};
led@4 {
label = beaglebone:green:usr2;
- gpios = gpio1 23 0;
+ gpios = gpio1 23 GPIO_ACTIVE_HIGH;
default-state = off;
};
led@5 {
label = beaglebone:green:usr3;
- gpios = gpio1 24 0;
+ gpios = gpio1 24 GPIO_ACTIVE_HIGH;
default-state = off;
};
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9302773..b74dbdf 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -264,12 +264,12 @@
debounce-delay-ms = 5;
col-scan-delay-us = 2;
- row-gpios = gpio1 25 0/* Bank1, pin25 */
-gpio1 26 0/* Bank1, pin26 */
-gpio1 27 0; /* Bank1, pin27 */
+ row-gpios = gpio1 25 GPIO_ACTIVE_HIGH /* Bank1, pin25
*/
+gpio1 26 GPIO_ACTIVE_HIGH /* Bank1, pin26
*/
+gpio1 27 GPIO_ACTIVE_HIGH; /* Bank1, pin27
*/
- col-gpios = gpio1 21 0/* Bank1, pin21 */
-gpio1 22 0; /* Bank1, pin22 */
+ col-gpios = gpio1 21 GPIO_ACTIVE_HIGH /* Bank1, pin21
*/
+gpio1 22 GPIO_ACTIVE_HIGH; /* Bank1, pin22
*/
linux,keymap = 0x008b /* MENU */
0x019e /* BACK */
@@ -288,14 +288,14 @@
switch@9 {
label = volume-up;
linux,code = 115;
- gpios = gpio0 2 1;
+ gpios = gpio0 2 GPIO_ACTIVE_LOW;
gpio-key,wakeup;
};
switch@10 {
label = volume-down;
linux,code = 114;
- gpios = gpio0 3 1;
+ gpios = gpio0 3 GPIO_ACTIVE_LOW;
gpio-key,wakeup;
};
};
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 83ded8e..16d17d6 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -144,26 +144,26 @@
led@1 {
label = evmsk:green:usr0;
- gpios = gpio1 4 0;
+ gpios = gpio1 4 GPIO_ACTIVE_HIGH;
default-state = off;
};
led@2 {
label = evmsk:green:usr1;
- gpios = gpio1 5 0;
+ gpios = gpio1 5 GPIO_ACTIVE_HIGH;
default-state = off;
};
led@3 {
label = evmsk:green:mmc0;
- gpios = gpio1 6 0;
+ gpios = gpio1 6 GPIO_ACTIVE_HIGH;
linux,default-trigger = mmc0;
default-state = off;
};
led@4 {
label = evmsk:green:heartbeat;
- gpios = gpio1 7 0;
+ gpios = gpio1 7 GPIO_ACTIVE_HIGH;
linux,default-trigger = heartbeat;
default-state = off;
};
@@ -177,26 +177,26 @@
switch@1 {
label = button0;
linux,code = 0x100;
- gpios = gpio2 3 0;
+ gpios = gpio2 3
[PATCH v2 3/4] ARM: dts: AM33XX: Specific pinctrl header
The pinctrl IP inside the AM33XX family differs slightly from what is found on OMAP2+. Define a specific header to take account of the differences. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- include/dt-bindings/pinctrl/am33xx.h | 37 ++ 1 files changed, 37 insertions(+), 0 deletions(-) create mode 100644 include/dt-bindings/pinctrl/am33xx.h diff --git a/include/dt-bindings/pinctrl/am33xx.h b/include/dt-bindings/pinctrl/am33xx.h new file mode 100644 index 000..a3fddd4 --- /dev/null +++ b/include/dt-bindings/pinctrl/am33xx.h @@ -0,0 +1,37 @@ +/* + * This header provides constants specific to AM33XX pinctrl bindings. + */ + +#include include/dt-bindings/pinctrl/omap.h + +/* am33xx specific mux bit defines */ +#undef PULL_ENA +#undef INPUT_EN + +#define PULL_DISABLE (1 3) +#define INPUT_EN (1 5) +#define SLEWCTRL_FAST (1 6) + +/* update macro depending on INPUT_EN and PULL_ENA */ +#undef PIN_OUTPUT +#undef PIN_OUTPUT_PULLUP +#undef PIN_OUTPUT_PULLDOWN +#undef PIN_INPUT +#undef PIN_INPUT_PULLUP +#undef PIN_INPUT_PULLDOWN + +#define PIN_OUTPUT (PULL_DISABLE) +#define PIN_OUTPUT_PULLUP (PULL_UP) +#define PIN_OUTPUT_PULLDOWN0 +#define PIN_INPUT (INPUT_EN | PULL_DISABLE) +#define PIN_INPUT_PULLUP (INPUT_EN | PULL_UP) +#define PIN_INPUT_PULLDOWN (INPUT_EN) + +/* undef non-existing modes */ +#undef PIN_OFF_NONE +#undef PIN_OFF_OUTPUT_HIGH +#undef PIN_OFF_OUTPUT_LOW +#undef PIN_OFF_INPUT_PULLUP +#undef PIN_OFF_INPUT_PULLDOWN +#undef PIN_OFF_WAKEUPENABLE + -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] ARM: dts: AM33XX: Use pinctrl constants
Using constants for pinctrl allows a better readability, and removes
redundancy with comments.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
arch/arm/boot/dts/am335x-bone.dts | 18 +-
arch/arm/boot/dts/am335x-evm.dts | 58 ++--
arch/arm/boot/dts/am335x-evmsk.dts | 26
arch/arm/boot/dts/am33xx.dtsi |1 +
4 files changed, 52 insertions(+), 51 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5bfb7dd..fd48173 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -30,30 +30,30 @@
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
- 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
MODE7 */
- 0x58 0x17 /* gpmc_a6.gpio1_22,
OUTPUT_PULLUP | MODE7 */
- 0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT |
MODE7 */
- 0x60 0x17 /* gpmc_a8.gpio1_24,
OUTPUT_PULLUP | MODE7 */
+ 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a5.gpio1_21 */
+ 0x58 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a6.gpio1_22 */
+ 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a7.gpio1_23 */
+ 0x60 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a8.gpio1_24 */
;
};
i2c0_pins: pinmux_i2c0_pins {
pinctrl-single,pins =
- 0x188 0x30 /* i2c0_sda.i2c0_sda PULLUP |
INPUTENABLE | MODE0 */
- 0x18c 0x30 /* i2c0_scl.i2c0_scl PULLUP |
INPUTENABLE | MODE0 */
+ 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
;
};
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins =
- 0x170 0x30 /* uart0_rxd.uart0_rxd PULLUP |
INPUTENABLE | MODE0 */
- 0x174 0x00 /* uart0_txd.uart0_txd PULLDOWN
| MODE0 */
+ 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
+ 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
;
};
clkout2_pin: pinmux_clkout2_pin {
pinctrl-single,pins =
- 0x1b4 0x03 /* xdma_event_intr1.clkout2
OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT */
+ 0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
xdma_event_intr1.clkout2 */
;
};
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index b74dbdf..2c53247 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -30,65 +30,65 @@
matrix_keypad_s0: matrix_keypad_s0 {
pinctrl-single,pins =
- 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
MODE7 */
- 0x58 0x7/* gpmc_a6.gpio1_22, OUTPUT |
MODE7 */
- 0x64 0x27 /* gpmc_a9.gpio1_25, INPUT |
MODE7 */
- 0x68 0x27 /* gpmc_a10.gpio1_26, INPUT |
MODE7 */
- 0x6c 0x27 /* gpmc_a11.gpio1_27, INPUT |
MODE7 */
+ 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a5.gpio1_21 */
+ 0x58 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a6.gpio1_22 */
+ 0x64 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a9.gpio1_25 */
+ 0x68 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a10.gpio1_26 */
+ 0x6c (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a11.gpio1_27 */
;
};
volume_keys_s0: volume_keys_s0 {
pinctrl-single,pins =
- 0x150 0x27 /* spi0_sclk.gpio0_2, INPUT |
MODE7 */
- 0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7 */
+ 0x150 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
spi0_sclk.gpio0_2 */
+ 0x154 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
spi0_d0.gpio0_3 */
;
};
i2c0_pins: pinmux_i2c0_pins {
pinctrl-single,pins =
- 0x188 0x30 /* i2c0_sda.i2c0_sda PULLUP |
INPUTENABLE | MODE0 */
-
Re: [PATCH v3] ARM: dts: AM43x: initial support
On 06/03/2013 03:19 PM, Afzal Mohammed wrote:
DT source (minimal) for AM4372 SoC to represent AM43x SoC's. Those
represented here are the minimal DT nodes necessary to get kernel
booting.
In DT nodes, ti,hwmod property has not been added, this would be
added along with PRCM support for AM43x.
Signed-off-by: Ankur Kishore a-kish...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Thanks Afzal. I've just applied it in my branch.
Regards,
Benoit
---
v3: Make use of C preprocessor, rebased over Benoit's 'for_3.11/dts' branch
v2: Add gptimer 1ms, timer2, synctimer and remove twd local timer
arch/arm/boot/dts/am4372.dtsi | 68
+++
1 file changed, 68 insertions(+)
create mode 100644 arch/arm/boot/dts/am4372.dtsi
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
new file mode 100644
index 000..ddc1df7
--- /dev/null
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -0,0 +1,68 @@
+/*
+ * Device Tree Source for AM4372 SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include dt-bindings/interrupt-controller/arm-gic.h
+
+#include skeleton.dtsi
+
+/ {
+ compatible = ti,am4372, ti,am43;
+ interrupt-parent = gic;
+
+
+ aliases {
+ serial0 = uart0;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a9;
+ };
+ };
+
+ gic: interrupt-controller@48241000 {
+ compatible = arm,cortex-a9-gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x48241000 0x1000,
+ 0x48240100 0x0100;
+ };
+
+ ocp {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ uart0: serial@44e09000 {
+ compatible = ti,am4372-uart,ti,omap2-uart;
+ reg = 0x44e09000 0x2000;
+ interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH;
+ };
+
+ timer1: timer@44e31000 {
+ compatible =
ti,am4372-timer-1ms,ti,am335x-timer-1ms;
+ reg = 0x44e31000 0x400;
+ interrupts = GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH;
+ ti,timer-alwon;
+ };
+
+ timer2: timer@4804 {
+ compatible = ti,am4372-timer,ti,am335x-timer;
+ reg = 0x4804 0x400;
+ interrupts = GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH;
+ };
+
+ counter32k: counter@44e86000 {
+ compatible =
ti,am4372-counter32k,ti,omap-counter32k;
+ reg = 0x44e86000 0x40;
+ };
+ };
+};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/2] ARM: dts: omap4-panda: Update the LED support for the panda DTS
Hi Dan,
On 05/31/2013 05:44 PM, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
Thanks, I've just applied it in my branch.
Regards,
Benoit
---
v10 - Update gpio entries to use gpio macros -
https://patchwork.kernel.org/patch/2644561/
v9 - Removed comments for mux config -
https://patchwork.kernel.org/patch/2644391/
v8 - Rebase to latest and use pinctrl macros -
https://patchwork.kernel.org/patch/2629351/
v7 - Update headline to add spaces -
https://patchwork.kernel.org/patch/2583661/
v6 - Review comments updated - https://patchwork.kernel.org/patch/2582771/
v5 - Provide pincrtl phandle to the gpio-led driver -
https://patchwork.kernel.org/patch/2573981/
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index d5d144a..800fa4e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = 0x8000 0x4000; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
heartbeat {
label = pandaboard::status1;
gpios = gpio1 7 GPIO_ACTIVE_HIGH;
@@ -157,6 +162,15 @@
};
};
+omap4_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 */
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
+ ;
+ };
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index 5cfdf19..56c4354 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e (PIN_INPUT | MUX_MODE0)/* hdmi_sda.hdmi_sda */
;
};
+
+omap4_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins =
+ 0xb6 (PIN_OUTPUT | MUX_MODE3) /* gpio_110 */
+ ;
+ };
+};
+
+led_wkgpio_pins {
+ pinctrl-single,pins =
+ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
+ ;
+};
+
+leds {
+ pinctrl-0 =
+ led_gpio_pins
+ led_wkgpio_pins
+ ;
+
+ heartbeat {
+ gpios = gpio4 14 GPIO_ACTIVE_HIGH;
+ };
+ mmc {
+ gpios = gpio1 8 GPIO_ACTIVE_HIGH;
+ };
+};
--
To unsubscribe from this list: send the line unsubscribe 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 v1] ARM: dts: omap4-panda: Update the twl6040 gpio to macro definition
Hi Dan, On 05/31/2013 06:12 PM, Florian Vaussard wrote: Hello Dan, On 05/31/2013 05:45 PM, Dan Murphy wrote: Update the dt property ti,audpwron-gpio to use the gpio macro definition for GPIO_ACTIVE_HIGH. Signed-off-by: Dan Murphy dmur...@ti.com --- arch/arm/boot/dts/omap4-panda-common.dtsi |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 800fa4e..00cbaa5 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -190,7 +190,7 @@ /* IRQ# = 119 */ interrupts = GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_2N cascaded to gic */ interrupt-parent = gic; -ti,audpwron-gpio = gpio4 31 0; /* gpio line 127 */ +ti,audpwron-gpio = gpio4 31 GPIO_ACTIVE_HIGH; /* gpio line 127 */ vio-supply = v1v8; v2v1-supply = v2v1; I missed it during the conversion, thank you. Reviewed-by: Florian Vaussard florian.vauss...@epfl.ch I've just applied it with Florian's Reviewed-by. Thanks, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: dts fixes for 3.10-rc4
Hi Tony, On 05/31/2013 03:23 PM, Benoit Cousson wrote: Hi Tony, Please pull two DTS fixes for the next -rc. Please ignore that one. I'll send a new one with one more fix ASAP. Thanks, Benoit Thanks, Benoit The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b: Linus Torvalds (1): Linux 3.10-rc3 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git dts-fixes-for-3.10 Kevin Hilman (1): ARM: dts: omap4-panda|sdp: Fix mux for twl6030 IRQ pin and msecure line Lars Poeschel (1): ARM: dts: AM33xx: Fix properties on gpmc node arch/arm/boot/dts/am33xx.dtsi |4 ++-- arch/arm/boot/dts/omap4-panda-common.dtsi | 20 arch/arm/boot/dts/omap4-sdp.dts | 20 3 files changed, 42 insertions(+), 2 deletions(-) ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL v2] ARM: dts: OMAP fixes for 3.10-rc5
Hi Tony, Please pull three DTS fixes for the next -rc. Thanks, Benoit The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e: Linus Torvalds (1): Linux 3.10-rc4 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git dts-fixes-for-3.10 Kevin Hilman (1): ARM: dts: omap4-panda|sdp: Fix mux for twl6030 IRQ pin and msecure line Lars Poeschel (1): ARM: dts: AM33xx: Fix properties on gpmc node Suman Anna (1): ARM: dts: OMAP5: Fix missing PWM capability to timer nodes arch/arm/boot/dts/am33xx.dtsi |4 ++-- arch/arm/boot/dts/omap4-panda-common.dtsi | 20 arch/arm/boot/dts/omap4-sdp.dts | 20 arch/arm/boot/dts/omap5.dtsi |3 +++ 4 files changed, 45 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3] cpuidle: Improve governor Kconfig options
Each governor is suitable for different kernel configurations: the menu governor suits better for a tickless system, while the ladder governor fits better for a periodic timer tick system. The Kconfig does not allow to [un]select a governor, thus both are compiled in the kernel but the init order makes the menu governor to be the last one to be registered, so becoming the default. The only way to switch back to the ladder governor is to enable the sysfs governor switch in the kernel command line. Because it seems nobody complained about this, the menu governor is used by default most of the time on the system, having both governors is not really necessary on a tickless system but there isn't a config option to disable one or another governor. Create a submenu for cpuidle and add a label for each governor, so we can see the option in the menu config and enable/disable it. The governors will be enabled depending on the CONFIG_NO_HZ option: - If CONFIG_NO_HZ is set, then the menu governor is selected and the ladder governor is optional, defaulting to 'yes' - If CONFIG_NO_HZ is not set, then the ladder governor is selected and the menu governor is optional, defaulting to 'yes' Before this patch, the ARCH_NEEDS_CPU_IDLE_COUPLED option was wrongly not depending on the CPU_IDLE and the Kconfig for OMAP / TEGRA was not checking this dependency when setting the option. With this patch, the ARCH_NEEDS_CPU_IDLE_COUPLED has been moved under the CPU_IDLE option. The dependency has been fixed in the relevant arch's Kconfig. Signed-off-by: Daniel Lezcano daniel.lezc...@linaro.org --- V3: - Fixed Kconfig dependency between CPU_IDLE and ARCH_NEEDS_CPU_IDLE_COUPLED V2: - Set default values to 'yes' for the governors arch/arm/mach-omap2/Kconfig |2 +- arch/arm/mach-tegra/Kconfig |2 +- drivers/cpuidle/Kconfig | 16 +++- 3 files changed, 9 insertions(+), 11 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index f49cd51..831e89e 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -83,7 +83,7 @@ config ARCH_OMAP4 depends on ARCH_OMAP2PLUS depends on ARCH_MULTI_V7 select ARCH_HAS_OPP - select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP + select ARCH_NEEDS_CPU_IDLE_COUPLED if (SMP CPU_IDLE) select ARM_CPU_SUSPEND if PM select ARM_ERRATA_720789 select ARM_GIC diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index 84d72fc..04c6221 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -23,7 +23,7 @@ menu NVIDIA Tegra options config ARCH_TEGRA_2x_SOC bool Enable support for Tegra20 family - select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP + select ARCH_NEEDS_CPU_IDLE_COUPLED if (SMP CPU_IDLE) select ARM_ERRATA_720789 select ARM_ERRATA_754327 if SMP select ARM_ERRATA_764369 if SMP diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig index c4cc27e..e997f15 100644 --- a/drivers/cpuidle/Kconfig +++ b/drivers/cpuidle/Kconfig @@ -1,7 +1,9 @@ -config CPU_IDLE +menuconfig CPU_IDLE bool CPU idle PM support default y if ACPI || PPC_PSERIES + select CPU_IDLE_GOV_LADDER if (!NO_HZ !NO_HZ_IDLE) + select CPU_IDLE_GOV_MENU if (NO_HZ || NO_HZ_IDLE) help CPU idle is a generic framework for supporting software-controlled idle processor power management. It includes modular cross-platform @@ -9,9 +11,10 @@ config CPU_IDLE If you're using an ACPI-enabled platform, you should say Y here. +if CPU_IDLE + config CPU_IDLE_MULTIPLE_DRIVERS bool Support multiple cpuidle drivers -depends on CPU_IDLE default n help Allows the cpuidle framework to use different drivers for each CPU. @@ -19,24 +22,19 @@ config CPU_IDLE_MULTIPLE_DRIVERS states. If unsure say N. config CPU_IDLE_GOV_LADDER - bool - depends on CPU_IDLE + bool Ladder governor (for periodic timer tick) default y config CPU_IDLE_GOV_MENU - bool - depends on CPU_IDLE NO_HZ + bool Menu governor (for tickless system) default y config ARCH_NEEDS_CPU_IDLE_COUPLED def_bool n -if CPU_IDLE - config CPU_IDLE_CALXEDA bool CPU Idle Driver for Calxeda processors depends on ARCH_HIGHBANK help Select this to enable cpuidle on Calxeda processors. - endif -- 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 2/6] ARM: OMAP2+: Remove board-omap4panda.c
Hi, On Sat, May 18, 2013 at 3:17 AM, Tony Lindgren t...@atomide.com wrote: We can now boot with device tree. If you don't want to update u-boot, you can boot with appended DTB with the following instructions: 1. Make sure you have the appended DTB support in .config CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND=y 2. Build the zImage $ ARCH=arm CROSS_COMPILE=... make zImage 3. Build the device tree blobs $ ARCH=arm CROSS_COMPILE=... make dtbs 4. Append the correct panda dtb to zImage Depending on your hardware it's omap4-panda.dtb, omap4-panda-a4.dtb or omap4-panda-es.dtb. $ cat arch/arm/boot/zImage arch/arm/boot/dts/omap4-panda-es.dtb /tmp/appended 5. Use mkimage to produce the appended device tree uImage $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 \ -n Linux -d /tmp/appended /tmp/uImage I followed the above steps and tried devicetree on Pandaboard against 3.10.0-rc3-next-20130528, and the board will hang during boot, but works well with legacy mode. Hardware: Pandaboard A1 dtb: omap4-panda.dtb See 'dmesg' on below link: http://kernel.ubuntu.com/~ming/up/panda-dts.dmesg Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] extcon: add EXPORT_SYMBOL_GPL for exported functions
Added EXPORT_SYMBOL_GPL() for extcon_register_interest and extcon_register_notifier in order to avoid undefined reference error when building the consumer modules of extcon as _modules_. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- drivers/extcon/extcon-class.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c index 265d549..51a5f5f 100644 --- a/drivers/extcon/extcon-class.c +++ b/drivers/extcon/extcon-class.c @@ -541,6 +541,7 @@ int extcon_register_interest(struct extcon_specific_cable_nb *obj, return -ENODEV; } } +EXPORT_SYMBOL_GPL(extcon_register_interest); /** * extcon_unregister_interest() - Unregister the notifier registered by @@ -555,6 +556,7 @@ int extcon_unregister_interest(struct extcon_specific_cable_nb *obj) return raw_notifier_chain_unregister(obj-edev-nh, obj-internal_nb); } +EXPORT_SYMBOL_GPL(extcon_unregister_interest); /** * extcon_register_notifier() - Register a notifiee to get notified by -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] extcon: Add an API to get extcon device from dt node
Added an API of_extcon_get_extcon_dev() to be used by drivers to get
extcon device in the case of dt boot (this can be used instead of
extcon_get_extcon_dev()).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/extcon/extcon-class.c | 40
include/linux/extcon.h|8
2 files changed, 48 insertions(+)
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 60adc04..265d549 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -31,6 +31,7 @@
#include linux/extcon.h
#include linux/slab.h
#include linux/sysfs.h
+#include linux/of_platform.h
/*
* extcon_cable_name suggests the standard cable names for commonly used
@@ -392,6 +393,45 @@ int extcon_set_cable_state(struct extcon_dev *edev,
}
EXPORT_SYMBOL_GPL(extcon_set_cable_state);
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
+{
+ struct class_dev_iter iter;
+ struct device *extcon_dev;
+ struct device_node *node;
+ struct platform_device *extcon_parent_dev;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, extcon, index);
+ if (!node) {
+ dev_dbg(dev, failed to get phandle in %s node\n,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ extcon_parent_dev = of_find_device_by_node(node);
+ if (!extcon_parent_dev) {
+ dev_dbg(dev, unable to find device by node\n);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ class_dev_iter_init(iter, extcon_class, NULL, NULL);
+ while ((extcon_dev = class_dev_iter_next(iter))) {
+ if (extcon_dev-parent != extcon_parent_dev-dev)
+ continue;
+
+ class_dev_iter_exit(iter);
+ return dev_get_drvdata(extcon_dev);
+ }
+
+ class_dev_iter_exit(iter);
+ return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_extcon_dev);
+
/**
* extcon_get_extcon_dev() - Get the extcon device instance from the name
* @extcon_name: The extcon name provided with extcon_dev_register()
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index fcb51c8..3858bb9 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -182,6 +182,8 @@ struct extcon_specific_cable_nb {
*/
extern int extcon_dev_register(struct extcon_dev *edev, struct device *dev);
extern void extcon_dev_unregister(struct extcon_dev *edev);
+extern struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev,
+ int index);
extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
/*
@@ -292,6 +294,12 @@ static inline int extcon_set_cable_state(struct extcon_dev
*edev,
return 0;
}
+static inline struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev,
+ int index)
+{
+ return NULL;
+}
+
static inline struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name)
{
return NULL;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] usb: dwc3: omap: improve error handling of dwc3_omap_probe
Improved the error handling of dwc3_omap_probe so that on error
conditions dwc3_omap is left in the original state.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 34638b9..f8f76e6 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -347,7 +347,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(dev);
if (ret 0) {
dev_err(dev, get_sync failed with err %d\n, ret);
- return ret;
+ goto err0;
}
reg = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
@@ -376,7 +376,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, failed to request IRQ #%d -- %d\n,
omap-irq, ret);
- return ret;
+ goto err1;
}
dwc3_omap_enable_irqs(omap);
@@ -384,10 +384,21 @@ static int dwc3_omap_probe(struct platform_device *pdev)
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(pdev-dev, failed to create dwc3 core\n);
- return ret;
+ goto err2;
}
return 0;
+
+err2:
+ dwc3_omap_disable_irqs(omap);
+
+err1:
+ pm_runtime_put_sync(dev);
+
+err0:
+ pm_runtime_disable(dev);
+
+ return ret;
}
static int dwc3_omap_remove(struct platform_device *pdev)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[v3 PATCH 5/5] usb: dwc3: use extcon fwrk to receive connect/disconnect
Modified dwc3-omap to receive connect and disconnect notification using
extcon framework. Also did the necessary cleanups required after
adapting to extcon framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
Changes from v2:
* updated the Documentation with dwc3 dt binding information.
* used of_extcon_get_extcon_dev to get extcon device from device tree data.
Changes from v1:
* regulator enable/disable is now done here instead of palmas-usb as some users
of palmas-usb wont need regulator.
Documentation/devicetree/bindings/usb/omap-usb.txt |5 +
drivers/usb/dwc3/dwc3-omap.c | 118
include/linux/usb/dwc3-omap.h | 30 -
3 files changed, 104 insertions(+), 49 deletions(-)
delete mode 100644 include/linux/usb/dwc3-omap.h
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f3..f1c15f3 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -53,6 +53,11 @@ OMAP DWC3 GLUE
It should be set to 1 for HW mode and 2 for SW mode.
- ranges: the child address space are mapped 1:1 onto the parent address space
+Optional Properties:
+ - extcon : phandle for the extcon device omap dwc3 uses to detect
+ connect/disconnect events.
+ - vbus-supply : phandle to the regulator device tree node if needed.
+
Sub-nodes:
The dwc3 core should be added as subnode to omap dwc3 glue.
- dwc3 :
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index f8f76e6..e1aac90 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,13 +43,14 @@
#include linux/spinlock.h
#include linux/platform_device.h
#include linux/platform_data/dwc3-omap.h
-#include linux/usb/dwc3-omap.h
#include linux/pm_runtime.h
#include linux/dma-mapping.h
#include linux/ioport.h
#include linux/io.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/extcon.h
+#include linux/regulator/consumer.h
#include linux/usb/otg.h
@@ -124,9 +125,21 @@ struct dwc3_omap {
u32 utmi_otg_status;
u32 dma_status:1;
+
+ struct extcon_specific_cable_nb extcon_vbus_dev;
+ struct extcon_specific_cable_nb extcon_id_dev;
+ struct notifier_block vbus_nb;
+ struct notifier_block id_nb;
+
+ struct regulator*vbus_reg;
};
-static struct dwc3_omap*_omap;
+enum omap_dwc3_vbus_id_status {
+ OMAP_DWC3_ID_FLOAT,
+ OMAP_DWC3_ID_GROUND,
+ OMAP_DWC3_VBUS_OFF,
+ OMAP_DWC3_VBUS_VALID,
+};
static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
{
@@ -138,18 +151,23 @@ static inline void dwc3_omap_writel(void __iomem *base,
u32 offset, u32 value)
writel(value, base + offset);
}
-int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
+ enum omap_dwc3_vbus_id_status status)
{
- u32 val;
- struct dwc3_omap*omap = _omap;
-
- if (!omap)
- return -EPROBE_DEFER;
+ int ret;
+ u32 val;
switch (status) {
case OMAP_DWC3_ID_GROUND:
dev_dbg(omap-dev, ID GND\n);
+ if (omap-vbus_reg) {
+ ret = regulator_enable(omap-vbus_reg);
+ if (ret) {
+ dev_dbg(omap-dev, regulator enable failed\n);
+ return;
+ }
+ }
val = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
val = ~(USBOTGSS_UTMI_OTG_STATUS_IDDIG
| USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
@@ -172,6 +190,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
break;
case OMAP_DWC3_ID_FLOAT:
+ if (omap-vbus_reg)
+ regulator_disable(omap-vbus_reg);
+
case OMAP_DWC3_VBUS_OFF:
dev_dbg(omap-dev, VBUS Disconnect\n);
@@ -185,12 +206,9 @@ int dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
break;
default:
- dev_dbg(omap-dev, ID float\n);
+ dev_dbg(omap-dev, invalid state\n);
}
-
- return 0;
}
-EXPORT_SYMBOL_GPL(dwc3_omap_mailbox);
static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
{
@@ -282,6 +300,32 @@ static void dwc3_omap_disable_irqs(struct dwc3_omap *omap)
static u64 dwc3_omap_dma_mask = DMA_BIT_MASK(32);
+static int dwc3_omap_id_notifier(struct notifier_block *nb,
+ unsigned long event, void *ptr)
+{
+ struct dwc3_omap *omap = container_of(nb, struct dwc3_omap, id_nb);
+
+ if (event)
+ dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
+
[PATCH 0/5] dwc3: omap: adapt dwc3 to use extcon framework
The first three patches deals with cleanup of extcon inorder to get through compilation without any issues. It also adds an API to get extcon device from dt node which I felt was missing. The next two patches deals with adapt dwc3 to use extcon framework. The 4th patch (usb: dwc3: omap: improve error handling of dwc3_omap_probe) should have ideally been sent to Felipe, however since there will be merge conflicts with the 5th patch (usb: dwc3: use extcon fwrk to receive connect/disconnect) in this series, I've sent in the same series. Once this patch series get merged, dwc3 in omap would be functional in device mode. However there is still some discussion on modelling SMPS10 regulator. Once that gets finalized, dwc3 should be functional in host mode as well. Kishon Vijay Abraham I (5): extcon: Add an API to get extcon device from dt node extcon: Kconfig: Make extcon config type as bool extcon: add EXPORT_SYMBOL_GPL for exported functions usb: dwc3: omap: improve error handling of dwc3_omap_probe usb: dwc3: use extcon fwrk to receive connect/disconnect Documentation/devicetree/bindings/usb/omap-usb.txt |5 + drivers/extcon/Kconfig |2 +- drivers/extcon/extcon-class.c | 42 +++ drivers/usb/dwc3/dwc3-omap.c | 133 include/linux/extcon.h |8 ++ include/linux/usb/dwc3-omap.h | 30 - 6 files changed, 168 insertions(+), 52 deletions(-) delete mode 100644 include/linux/usb/dwc3-omap.h -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] extcon: Kconfig: Make extcon config type as bool
Changed the extcon config type to bool from module. Having extcon config type as module leads to some undefined reference to errors if the modules that uses these APIs are made as built-in and extcon as module. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- drivers/extcon/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig index 63f454e..ee9b7d4 100644 --- a/drivers/extcon/Kconfig +++ b/drivers/extcon/Kconfig @@ -1,5 +1,5 @@ menuconfig EXTCON - tristate External Connector Class (extcon) support + bool External Connector Class (extcon) support help Say Y here to enable external connector class (extcon) support. This allows monitoring external connectors by userspace -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] serial: omap: repair building without PM_SLEEP
On Sat, Jun 01, 2013 at 11:18:13AM +0200, Arnd Bergmann wrote: A recent bug fix in 3.10, ddd85e225c serial: omap: prevent runtime PM for no_console_suspend, introduced a regression from an obvious typo: I don't see that commit id, or commit, in Linus's tree at all. Where do you see it? drivers/tty/serial/omap-serial.c:1677:14: error: 'serial_omap_complete' undeclared here (not in a function) This changes the incorrectly added macro to the one that we need instead. Signed-off-by: Arnd Bergmann a...@arndb.de --- Please apply for 3.10-rc Really? It doesn't apply to 3.10-rc3 or -rc4 from what I can tell. confused, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] USB: PHY: Improve PHY selection logic
On Fri, May 31, 2013 at 02:29:01PM +0300, Roger Quadros wrote: Hi, Improve Kconfig so that the relevant PHY driver can be explicitely selected by the controller driver instead of relying on the user to do so. Detailed description in patch 1. Felipe needs to take these, not I. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] USB: ehci-omap: Reset dma_mask pointer on probe
On Thu, May 23, 2013 at 05:46:44PM +0300, Roger Quadros wrote: On 05/23/2013 05:11 PM, Alan Stern wrote: On Thu, 23 May 2013, Roger Quadros wrote: Device tree probed devices don't get dma_mask set. Previously we were setting the dma_mask pointer only if it was NULL. However, the address of 'omap_ehci_dma_mask' would change each time the module is unloaded and loaded back thus causing the devices dma_mask pointer to be invalid on the next load. This will cause page faults if any driver tries to access the old dma_mask pointer. Unconditionally re-setting the dma_mask pointer fixes this problem. diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 3d1491b..b33e306 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -146,8 +146,7 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) * Since shared usb code relies on it, set it here for now. * Once we have dma capability bindings this can go away. */ - if (!pdev-dev.dma_mask) - pdev-dev.dma_mask = omap_ehci_dma_mask; + pdev-dev.dma_mask = omap_ehci_dma_mask; Is this the solution that people have agreed on? There has been a lot of discussion on this topic. In particular, there has been talk about fixing it in the DT core. Fixing it in DT core would be best. Then please do that. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] serial: omap: repair building without PM_SLEEP
On Monday 03 June 2013, Greg Kroah-Hartman wrote: On Sat, Jun 01, 2013 at 11:18:13AM +0200, Arnd Bergmann wrote: A recent bug fix in 3.10, ddd85e225c serial: omap: prevent runtime PM for no_console_suspend, introduced a regression from an obvious typo: I don't see that commit id, or commit, in Linus's tree at all. Where do you see it? drivers/tty/serial/omap-serial.c:1677:14: error: 'serial_omap_complete' undeclared here (not in a function) This changes the incorrectly added macro to the one that we need instead. Signed-off-by: Arnd Bergmann a...@arndb.de --- Please apply for 3.10-rc Really? It doesn't apply to 3.10-rc3 or -rc4 from what I can tell. Sorry, my mistake. Since the bug was introduced as part of a bug fix I assumed it was in 3.10-rc but did not look carefully. The problem only exists in tty-next at the moment. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] serial: omap: repair building without PM_SLEEP
Greg Kroah-Hartman gre...@linuxfoundation.org writes: On Sat, Jun 01, 2013 at 11:18:13AM +0200, Arnd Bergmann wrote: A recent bug fix in 3.10, ddd85e225c serial: omap: prevent runtime PM for no_console_suspend, introduced a regression from an obvious typo: I don't see that commit id, or commit, in Linus's tree at all. Where do you see it? It's in linux-next (from your tty-next branch.) drivers/tty/serial/omap-serial.c:1677:14: error: 'serial_omap_complete' undeclared here (not in a function) This changes the incorrectly added macro to the one that we need instead. Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Kevin Hilman khil...@linaro.org --- Please apply for 3.10-rc Really? It doesn't apply to 3.10-rc3 or -rc4 from what I can tell. Right, this is -next material, not v3.10. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: twl-core: convert to module_init()
Strashko, Grygorii grygorii.stras...@ti.com writes: Hi Kevin, It's done alreday here: https://patchwork.kernel.org/patch/2477541/ - mfd: twl-core: convert to module_i2c_driver() (Samuel has taken this one) Excellent, thanks for pointing it out, somehow I missed that thread. My patch can be ignored. - and - https://patchwork.kernel.org/patch/2477561/ - i2c: omap: convert to module_platform_driver() (you can vote here - TWL can't be shifted without I2C) This one (combined with the first one) makes twl_rtc fail to initialize properly on OMAP3 DT boot, with an error like this: twl_rtc rtc.22: hctosys: invalid date/time Reverting that you get the expected result: twl_rtc rtc.22: setting system clock to 2000-01-01 00:00:00 UTC (946684800) I didn't debug any further, but for now, at least patch 2 needs a little more work/debug. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c: omap: convert to module_platform_driver()
Grygorii Strashko grygorii.stras...@ti.com writes: The OMAP I2C driver has a relation to pinctrl-single driver. As result, its probe will be deferred during system boot until late init time, because the pinctrl-single is initizalized as moudle/device init time. This, in turn, will delay initialization of all I2C devices (like mfd, I2C regulators and etc.) and cause boot delay (more over, it can broken initialization of drivers which are not ready to use deferred probe mechanism yet, for example DSS). There are no sense to keep OMAP I2C initialization on subsys init layer any more, hence shift it to module/device layer where the i2c -- pinctrl-single dependency is resolved in drivers/Makefile now. Cc: Wolfram Sang w...@the-dreams.de Cc: Ben Dooks (embedded platforms) ben-li...@fluff.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: linux-omap@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Testing this patch with PATCH 1/2, the twl_rtc driver fails to correctly initialize on OMAP3: twl_rtc rtc.22: hctosys: invalid date/time instead of the expected result: twl_rtc rtc.22: setting system clock to 2000-01-01 00:00:00 UTC (946684800) so something is still not right for the init sequence. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Cocci spatch ptr_ret.spatch
Thomas Meyer tho...@m3y3r.de writes: Signed-off-by: Thomas Meyer tho...@m3y3r.de Could use a changelog, but otherwise Acked-by: Kevin Hilman khil...@linaro.org --- diff -u -p a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -66,7 +66,7 @@ static int __init omap3_l3_init(void) WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name); - return IS_ERR(pdev) ? PTR_ERR(pdev) : 0; + return PTR_RET(pdev); } omap_postcore_initcall(omap3_l3_init); @@ -100,7 +100,7 @@ static int __init omap4_l3_init(void) WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name); - return IS_ERR(pdev) ? PTR_ERR(pdev) : 0; + return PTR_RET(pdev); } omap_postcore_initcall(omap4_l3_init); diff -u -p a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c --- a/arch/arm/mach-omap2/fb.c +++ b/arch/arm/mach-omap2/fb.c @@ -83,10 +83,7 @@ static int __init omap_init_vrfb(void) pdev = platform_device_register_resndata(NULL, omapvrfb, -1, res, num_res, NULL, 0); - if (IS_ERR(pdev)) - return PTR_ERR(pdev); - else - return 0; + return PTR_RET(pdev); } omap_arch_initcall(omap_init_vrfb); diff -u -p a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -1678,7 +1678,7 @@ static int __init omap_gpmc_init(void) pdev = omap_device_build(DEVICE_NAME, -1, oh, NULL, 0); WARN(IS_ERR(pdev), could not build omap_device for %s\n, oh_name); - return IS_ERR(pdev) ? PTR_ERR(pdev) : 0; + return PTR_RET(pdev); } omap_postcore_initcall(omap_gpmc_init); diff -u -p a/arch/arm/mach-omap2/pmu.c b/arch/arm/mach-omap2/pmu.c --- a/arch/arm/mach-omap2/pmu.c +++ b/arch/arm/mach-omap2/pmu.c @@ -54,10 +54,7 @@ static int __init omap2_init_pmu(unsigne WARN(IS_ERR(omap_pmu_dev), Can't build omap_device for %s.\n, dev_name); - if (IS_ERR(omap_pmu_dev)) - return PTR_ERR(omap_pmu_dev); - - return 0; + return PTR_RET(omap_pmu_dev); } static int __init omap_init_pmu(void) -- 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: [PATCH 1/3] ARM: DTS: OMAP3: beagle/overo: mux console UART, enable wakeup
Florian Vaussard florian.vauss...@epfl.ch writes:
Hello Kevin,
On 06/01/2013 12:45 AM, Kevin Hilman wrote:
Ensure the console uart (UART3) on these boards is mux'd correctly, and
IO ring wakeup is enabled.
This is needed for serial console wakeups when using DT boot.
Signed-off-by: Kevin Hilman khil...@linaro.org
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 14 ++
arch/arm/boot/dts/omap3-beagle.dts| 12
arch/arm/boot/dts/omap3-overo.dtsi| 14 ++
3 files changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 3046d1f..ca067b0 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -126,3 +126,17 @@
mode = 3;
power = 50;
};
+
+omap3_pmx_core {
+uart3_pins: pinmux_uart3_pins {
+pinctrl-single,pins =
+0x16e 0x4100/* uart3_rx_irrx.uart3_rx_irrx WAKEUP |
INPUT | MODE0 */
+0x170 0x0 /* uart3_tx_irtx.uart3_tx_irtx OUTPUT |
MODE0 */
If you go through Benoit's tree, could you use the newly introduced
constants [1]? They are defined
in include/dt-bindings/pinctrl/omap.h. The above will look:
0x16e (PIN_INPUT | WAKEUP_EVENT | MUX_MODE0)
/* uart3_rx_irrx.uart3_rx_irrx */
0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx */
Excellent, thanks for the pointer. I hadn't yet read through your
pre-processor series, but I really like the readability improvements.
I'll respin these on top of your changes.
Thanks,
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
Florian Vaussard florian.vauss...@epfl.ch writes:
Hello Kevin,
On 06/01/2013 12:45 AM, Kevin Hilman wrote:
On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP. Therefore, configure the defaults for the
SYS_NIRQ pin in the twl4030 DTS file.
Boards that hook up the twl4030 differently can easily override this
in their board-specific DTS file.
This allows RTC wake from off-mode to work again on OMAP3-based
platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM,
3530/Overo, 3730/Overo-STORM.
Signed-off-by: Kevin Hilman khil...@linaro.org
---
arch/arm/boot/dts/twl4030.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..c7fe9f6 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -13,6 +13,8 @@
compatible = ti,twl4030;
interrupt-controller;
#interrupt-cells = 1;
+pinctrl-names = default;
+pinctrl-0 = twl4030_pins;
rtc {
compatible = ti,twl4030-rtc;
@@ -92,3 +94,18 @@
#pwm-cells = 2;
};
};
+
+omap3_pmx_core {
Here you are making the TWL4030 to explicitly depend on OMAP3. Could
this chip be used by another target? If the case, I would put this
piece of code in the files including twl4030. Otherwise it's ok here.
I talked this over with Tony before posting. In theorry, it could be
used on other platforms. In practice, it's only used on OMAP. We can
easily move this to board files if needed later, but thought it would be
simpler to put it here. I'll let Benoit decide.
+/*
+ * On most OMAP3 platforms, the twl4030 IRQ line is connected
+ * to the SYS_NIRQ line on OMAP. Therefore, configure the
+ * defaults for the SYS_NIRQ pin here. Boards that hook up
+ * the twl4030 differently can easily override this in their
+ * board-specific DTS file.
+ */
+twl4030_pins: pinmux_twl4030_pins {
+pinctrl-single,pins =
+0x1b0 0x4118 /* sys_nirq.sys_nirq WAKEUP | INPUT_PULLUP
| MODE 0 */
By using pinctrl constants:
0x1b0 (PIN_INPUT_PULLUP | WAKEUP_EN | MUX_MODE0)
/* sys_nirq.sys_nirq */
Yup.
+;
+};
+};
I will test this afternoon on an Overo.
Thanks,
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: DTS: TWL4030: fix mux and wakeup for SYS_NIRQ line
On Mon, Jun 03, 2013 at 03:19:25PM -0700, Kevin Hilman wrote:
Florian Vaussard florian.vauss...@epfl.ch writes:
Hello Kevin,
On 06/01/2013 12:45 AM, Kevin Hilman wrote:
On most OMAP3 platforms, the twl4030 IRQ line is connected to the
SYS_NIRQ line on OMAP. Therefore, configure the defaults for the
SYS_NIRQ pin in the twl4030 DTS file.
Boards that hook up the twl4030 differently can easily override this
in their board-specific DTS file.
This allows RTC wake from off-mode to work again on OMAP3-based
platforms with twl4030. Tested on 3530/Beagle, 3730/Beagle-xM,
3530/Overo, 3730/Overo-STORM.
Signed-off-by: Kevin Hilman khil...@linaro.org
---
arch/arm/boot/dts/twl4030.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi
b/arch/arm/boot/dts/twl4030.dtsi
index b3034da..c7fe9f6 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -13,6 +13,8 @@
compatible = ti,twl4030;
interrupt-controller;
#interrupt-cells = 1;
+ pinctrl-names = default;
+ pinctrl-0 = twl4030_pins;
rtc {
compatible = ti,twl4030-rtc;
@@ -92,3 +94,18 @@
#pwm-cells = 2;
};
};
+
+omap3_pmx_core {
Here you are making the TWL4030 to explicitly depend on OMAP3. Could
this chip be used by another target? If the case, I would put this
piece of code in the files including twl4030. Otherwise it's ok here.
I talked this over with Tony before posting. In theorry, it could be
used on other platforms. In practice, it's only used on OMAP. We can
easily move this to board files if needed later, but thought it would be
simpler to put it here. I'll let Benoit decide.
What about omap boards that don't use the twl4030? eg I'm currently
tinkering with a board that uses a tps6507x...
thx,
Jason.
--
To unsubscribe from this list: send the line unsubscribe 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] rtc: rtc-twl: ensure IRQ is wakeup enabled
On Fri, 31 May 2013 15:37:07 -0700 Kevin Hilman khil...@linaro.org wrote:
Currently, the RTC IRQ is never wakeup-enabled so is not capable of
bringing the system out of suspend.
On OMAP platforms, we have gotten by without this because the TWL RTC
is on an I2C-connected chip which is capable of waking up the OMAP via
the IO ring when the OMAP is in low-power states.
However, if the OMAP suspends without hitting the low-power states
(and the IO ring is not enabled), RTC wakeups will not work because
the IRQ is not wakeup enabled.
To fix, ensure the RTC IRQ is wakeup enabled whenever the RTC alarm is
set.
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -213,12 +213,24 @@ static int mask_rtc_irq_bit(unsigned char bit)
static int twl_rtc_alarm_irq_enable(struct device *dev, unsigned enabled)
{
+ struct platform_device *pdev = to_platform_device(dev);
+ int irq = platform_get_irq(pdev, 0);
+ static bool twl_rtc_wake_enabled;
int ret;
- if (enabled)
+ if (enabled) {
ret = set_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
- else
+ if (device_can_wakeup(dev) !twl_rtc_wake_enabled) {
+ enable_irq_wake(irq);
+ twl_rtc_wake_enabled = true;
+ }
+ } else {
ret = mask_rtc_irq_bit(BIT_RTC_INTERRUPTS_REG_IT_ALARM_M);
+ if (twl_rtc_wake_enabled) {
+ disable_irq_wake(irq);
+ twl_rtc_wake_enabled = false;
+ }
+ }
Why do we need this (slightly racy) logic with twl_rtc_wake_enabled?
Other drivers don't do this.
Should we test device_may_wakeup() befre running disable_irq_wake()?
Most drivers seem to do this, but it's all a bit foggy.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
