* [PATCH] ARM: OMAP1: usb: fix sparse warnings
From: Paul Walmsley @ 2012-10-26 20:52 UTC (permalink / raw)
To: linux-arm-kernel
Resolve the following sparse warnings:
arch/arm/mach-omap1/usb.c:304:12: warning: symbol 'omap1_usb0_init' was not declared. Should it be static?
arch/arm/mach-omap1/usb.c:412:12: warning: symbol 'omap1_usb1_init' was not declared. Should it be static?
arch/arm/mach-omap1/usb.c:478:12: warning: symbol 'omap1_usb2_init' was not declared. Should it be static?
by declaring those functions as static. Also remove the unneeded
prototypes and related code from the plat/usb.h header file.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Felipe Balbi <balbi@ti.com>
---
Tony, care to take this one?
arch/arm/mach-omap1/usb.c | 6 +++---
arch/arm/plat-omap/include/plat/usb.h | 20 --------------------
2 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 84267ed..104fed3 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -301,7 +301,7 @@ static inline void otg_device_init(struct omap_usb_config *pdata)
#endif
-u32 __init omap1_usb0_init(unsigned nwires, unsigned is_device)
+static u32 __init omap1_usb0_init(unsigned nwires, unsigned is_device)
{
u32 syscon1 = 0;
@@ -409,7 +409,7 @@ u32 __init omap1_usb0_init(unsigned nwires, unsigned is_device)
return syscon1 << 16;
}
-u32 __init omap1_usb1_init(unsigned nwires)
+static u32 __init omap1_usb1_init(unsigned nwires)
{
u32 syscon1 = 0;
@@ -475,7 +475,7 @@ bad:
return syscon1 << 20;
}
-u32 __init omap1_usb2_init(unsigned nwires, unsigned alt_pingroup)
+static u32 __init omap1_usb2_init(unsigned nwires, unsigned alt_pingroup)
{
u32 syscon1 = 0;
diff --git a/arch/arm/plat-omap/include/plat/usb.h b/arch/arm/plat-omap/include/plat/usb.h
index 87ee140..669baa1 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -156,24 +156,4 @@ extern void ti81xx_musb_phy_power(u8 on);
#define USBPHY_OTGSESSEND_EN (1 << 20)
#define USBPHY_DATA_POLARITY (1 << 23)
-#if defined(CONFIG_ARCH_OMAP1) && defined(CONFIG_USB)
-u32 omap1_usb0_init(unsigned nwires, unsigned is_device);
-u32 omap1_usb1_init(unsigned nwires);
-u32 omap1_usb2_init(unsigned nwires, unsigned alt_pingroup);
-#else
-static inline u32 omap1_usb0_init(unsigned nwires, unsigned is_device)
-{
- return 0;
-}
-static inline u32 omap1_usb1_init(unsigned nwires)
-{
- return 0;
-
-}
-static inline u32 omap1_usb2_init(unsigned nwires, unsigned alt_pingroup)
-{
- return 0;
-}
-#endif
-
#endif /* __ASM_ARCH_OMAP_USB_H */
--
1.7.10.4
^ permalink raw reply related
* [PATCH v4] pwm: vt8500: Update vt8500 PWM driver support
From: Chris Brand @ 2012-10-26 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351100330-26072-1-git-send-email-linux@prisktech.co.nz>
Hi Tony,
> @@ -124,6 +156,12 @@ static int __devinit pwm_probe(struct
> platform_device *pdev)
> chip->chip.base = -1;
> chip->chip.npwm = VT8500_NR_PWMS;
>
> + chip->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR_OR_NULL(chip->clk)) {
> + dev_err(&pdev->dev, "clock source not specified\n");
> + return PTR_ERR(chip->clk);
> + }
> +
Do you want IS_ERR() rather than IS_ERR_OR_NULL() here ?
Otherwise you may return PTR_ERR(NULL).
Chris
^ permalink raw reply
* [PATCH] arm: mvebu: update defconfig with 3.7 changes
From: Jason @ 2012-10-26 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210262033.41250.arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
>On Wednesday 24 October 2012, Thomas Petazzoni wrote:
>> On Wed, 24 Oct 2012 10:39:42 +0200, Gregory CLEMENT wrote:
>> > On 10/23/2012 10:17 AM, Thomas Petazzoni wrote:
>> > > The split of 370 and XP into two Kconfig options and the
>multiplatform
>> > > kernel support has changed a few Kconfig symbols, so let's update
>the
>> > > mvebu_defconfig file with the latest changes.
>> >
>> > Indeed this patch fixes the mvebu_defconfig which was broken.
>> > But as now mvebu is part of multi_v7_defconfig, shouldn't we just
>> > removed mvebu_defconfig ?
>>
>> I think for now, SoC family specific defconfig files are still
>> accepted, so I'd prefer to keep mvebu_defconfig around. Multiplatform
>> is nice for users, but I prefer to build a mvebu-only kernel when I'm
>> doing kernel development.
>
>I'd certainly like to see that patch get merged. Should I just apply it
>to the fixes branch?
>
> Arnd
Please do. I have a few other fixes for v3.7 to do this w/e, but iirc they aren't fixing build breakage.
thx,
Jason.
^ permalink raw reply
* [PATCH 10/16] ARM: OMAP: Make omap_device local to mach-omap2
From: Paul Walmsley @ 2012-10-26 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026203741.GT11908@atomide.com>
On Fri, 26 Oct 2012, Tony Lindgren wrote:
> I've merged omap-for-v3.8/cleanup-headers into omap-for-v3.8/cleanup-prcm
> too now, so you should be able to use commit 7fc54fd3 as the base for
> further PRCM changes.
OK thanks, will do.
- Paul
^ permalink raw reply
* [PATCH 10/16] ARM: OMAP: Make omap_device local to mach-omap2
From: Tony Lindgren @ 2012-10-26 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210262016410.11258@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121026 13:20]:
> On Fri, 26 Oct 2012, Tony Lindgren wrote:
>
> > * Paul Walmsley <paul@pwsan.com> [121026 10:03]:
> > > On Fri, 26 Oct 2012, Tony Lindgren wrote:
> > >
> > > > Can you do a branch on top of omap-for-v3.8/cleanup-headers
> > > > with all these fixes that I can pull in?
> > >
> > > Yes, will do that today.
> >
> > OK thanks!
>
> Just sent the pull request. Are you planning to rebuild cleanup-prcm also
> when you pull those cleanup-headers fixes in? Am planning to send another
> PRCM cleanup pull request next week...
I've merged omap-for-v3.8/cleanup-headers into omap-for-v3.8/cleanup-prcm
too now, so you should be able to use commit 7fc54fd3 as the base for
further PRCM changes.
Regards,
Tony
^ permalink raw reply
* [PATCH] arm: mvebu: update defconfig with 3.7 changes
From: Arnd Bergmann @ 2012-10-26 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024161611.659b0989@skate>
On Wednesday 24 October 2012, Thomas Petazzoni wrote:
> On Wed, 24 Oct 2012 10:39:42 +0200, Gregory CLEMENT wrote:
> > On 10/23/2012 10:17 AM, Thomas Petazzoni wrote:
> > > The split of 370 and XP into two Kconfig options and the multiplatform
> > > kernel support has changed a few Kconfig symbols, so let's update the
> > > mvebu_defconfig file with the latest changes.
> >
> > Indeed this patch fixes the mvebu_defconfig which was broken.
> > But as now mvebu is part of multi_v7_defconfig, shouldn't we just
> > removed mvebu_defconfig ?
>
> I think for now, SoC family specific defconfig files are still
> accepted, so I'd prefer to keep mvebu_defconfig around. Multiplatform
> is nice for users, but I prefer to build a mvebu-only kernel when I'm
> doing kernel development.
I'd certainly like to see that patch get merged. Should I just apply it
to the fixes branch?
Arnd
^ permalink raw reply
* [GIT PULL] ARM: OMAP: fix build, sparse problems in cleanup-headers
From: Tony Lindgren @ 2012-10-26 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210262012250.11258@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121026 13:16]:
> Hi Tony,
>
> The following changes since commit 2da8a79f7d81853d00b6a00621aeef7545196084:
>
> Merge branch 'omap-for-v3.8/cleanup-headers-menelaus' into omap-for-v3.8/cleanup-headers (2012-10-25 12:21:48 -0700)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-fixes-a-for-3.8
>
> for you to fetch changes up to 97af08b6e10e06563309728ed2fe8fdd919c5a33:
>
> ARM: OMAP1: fix sparse warning added by commit 4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3 (2012-10-26 13:21:48 -0600)
>
> ----------------------------------------------------------------
> Several fixes for build failures and sparse warnings in the
> OMAP cleanup-headers branch. Intended for 3.8 cleanup.
>
> Basic build, boot, and PM test logs are available from here:
>
> http://www.pwsan.com/omap/testlogs/cleanup-headers-compile-fixes-3.8/20121026132711/
>
> Due to underlying problems in v3.7-rc2, several tests fail. These
> failures are unrelated to these patches.
Thanks pulling into omap-for-v3.8/cleanup-headers.
Regards,
Tony
> ----------------------------------------------------------------
> Paul Walmsley (3):
> ARM: OMAP2+: fix build breakage introduced by commit b7754452b3e27716347a528b47b0a1083af32520
> ARM: OMAP1: fix build breakage introduced by commit 25c7d49ed48b4843da7dea56a81ae7f620211ee0
> ARM: OMAP1: fix sparse warning added by commit 4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3
>
> arch/arm/mach-omap1/fpga.c | 1 +
> arch/arm/mach-omap1/pm_bus.c | 2 ++
> drivers/mtd/onenand/omap2.c | 36 ++++++++++++++++++++++++------------
> 3 files changed, 27 insertions(+), 12 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 10/16] ARM: OMAP: Make omap_device local to mach-omap2
From: Paul Walmsley @ 2012-10-26 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026171059.GG11908@atomide.com>
On Fri, 26 Oct 2012, Tony Lindgren wrote:
> * Paul Walmsley <paul@pwsan.com> [121026 10:03]:
> > On Fri, 26 Oct 2012, Tony Lindgren wrote:
> >
> > > Can you do a branch on top of omap-for-v3.8/cleanup-headers
> > > with all these fixes that I can pull in?
> >
> > Yes, will do that today.
>
> OK thanks!
Just sent the pull request. Are you planning to rebuild cleanup-prcm also
when you pull those cleanup-headers fixes in? Am planning to send another
PRCM cleanup pull request next week...
- Paul
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Michael Walle @ 2012-10-26 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026204505.762fbfca@skate>
Hi Thomas.
Am Freitag 26 Oktober 2012, 20:45:05 schrieb Thomas Petazzoni:
> Ah, this is interesting. It is not entirely surprising, since the gpio
> driver is new. Even though it re-uses most of the previous gpio driver,
> it is by far not impossible that there will be a few regressions.
>
> Could you add a few debug prints to see if you're looping *inside* the
> function (which I find pretty unlikely), or if the function gets called
> over and over again?
ah sorry, my bad. of course the handler is called forever:
mvebu_gpio_to_irq pin=8
mvebu_gpio_irq_set_type pin=8
mvebu_gpio_edge_irq_unmask
mvebu_gpio_irq_handler irq=103
mvebu_gpio_level_irq_mask irq=103
mvebu_gpio_irq_handler irq=100
mvebu_gpio_level_irq_mask irq=100
mvebu_gpio_irq_handler irq=101
mvebu_gpio_level_irq_mask irq=101
mvebu_gpio_irq_handler irq=102
mvebu_gpio_level_irq_mask irq=102
mvebu_gpio_irq_handler irq=103
mvebu_gpio_level_irq_mask irq=103
mvebu_gpio_irq_handler irq=112
mvebu_gpio_level_irq_mask irq=112
mvebu_gpio_irq_handler irq=103
mvebu_gpio_level_irq_mask irq=103
mvebu_gpio_irq_handler irq=103
mvebu_gpio_level_irq_mask irq=103
mvebu_gpio_irq_handler irq=103
mvebu_gpio_level_irq_mask irq=103
mvebu_gpio_irq_handler irq=103
mvebu_gpio_level_irq_mask irq=103
mvebu_gpio_irq_handler irq=103
mvebu_gpio_level_irq_mask irq=103
mvebu_gpio_irq_handler irq=103
mvebu_gpio_level_irq_mask irq=103
mvebu_gpio_irq_handler irq=103
mvebu_gpio_level_irq_mask irq=103
mvebu_gpio_irq_handler irq=103
[..]
> Could it be that the hang occurs during the
> initialization of the gpio-leds or gpio-keys drivers?
yeah, if i disable gpio-leds, gpio-keys and gpio-fan the hang will disappear.
But once i enable one of it the board hangs again.
> Also, even though I'm pretty sure it isn't going to fix your problem,
> note the following mvebu-gpio fix:
>
> http://article.gmane.org/gmane.linux.ports.arm.kernel/195018
thats already in andrew's tree.
--
michael
^ permalink raw reply
* [PATCH v2 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp
From: Tony Lindgren @ 2012-10-26 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026195958.GB29548@arwen.pp.htv.fi>
* Felipe Balbi <balbi@ti.com> [121026 13:07]:
> On Fri, Oct 26, 2012 at 10:21:41AM -0700, Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [121026 00:48]:
> > > On Friday 26 October 2012, Felipe Balbi wrote:
> > > > > +static void omap_init_ocp2scp(void)
> > > > > +{
> > > > > + struct omap_hwmod *oh;
> > > > > + struct platform_device *pdev;
> > > > > + int bus_id = -1, dev_cnt = 0, i;
> > > > > + struct omap_ocp2scp_dev *ocp2scp_dev;
> > > > > + const char *oh_name, *name;
> > > > > + struct omap_ocp2scp_platform_data *pdata;
> > > > > +
> > > > > + oh_name = "ocp2scp_usb_phy";
> > > > > + name = "omap-ocp2scp";
> > > >
> > > > how about adding checks here to return early case we're not running on
> > > > OMAP4 or OMAP5 ??
> > > >
> > >
> > > I suppose even OMAP4-only, since OMAP5 always has DT enabled.
> >
> > Hmm yes, currently omap_hwmod_lookup(oh_name) produces
> > bogus errors for other omaps as the hwmod data is only
> > there for omap4.
>
> shouldn't that be fixed too ? I mean, if data isn't just return -ENODEV
> or something similar.
Yes some kind of checking is needed here.
Regards,
Tony
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Felipe Balbi @ 2012-10-26 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025101212.GD21217@arwen.pp.htv.fi>
Hi,
On Thu, Oct 25, 2012 at 01:12:12PM +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 23, 2012 at 09:23:03PM +0200, Jean Pihet wrote:
> > On Tue, Oct 23, 2012 at 9:19 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > > On Mon, 22 Oct 2012, Jean Pihet wrote:
> > >
> > >> On Mon, Oct 22, 2012 at 6:12 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> > >>
> > >> > Do you have CPU_IDLE enabled?
> > >> FYI the issue is not present with CPU_IDLE enabled.
> > >
> > > Hmm, how can you tell? I thought you weren't able to reproduce it with
> > > CPU_IDLE disabled either?
> > I could not reproduce the issue, with and without CPU_IDLE enabled.
> > What puzzles me is that the PM QoS code only has influence on the
> > states chosen by cpuidle, so the change should not have any impact
> > with CPU_IDLE enabled. I reallt need to reproduce the issue.
> > Let me try with the same setup as yours (bootloader images,
> > omap2pus_defconfig, angstrom roots).
>
> I just sent a patch to fix a bug I found on OMAP4 panda but while
> reading this thread again, I think it could be that it's the same bug
> which is just easier to reproduce on Paul's setup.
>
> Paul, Aaro, can you see if [1] makes the problem go away ? that would be
> another reason to push [1] during this -rc cycle.
>
> [1] http://marc.info/?l=linux-omap&m=135115602407925&w=2
ping
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/fb79736f/attachment-0001.sig>
^ permalink raw reply
* [GIT PULL] ARM: OMAP: fix build, sparse problems in cleanup-headers
From: Paul Walmsley @ 2012-10-26 20:14 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony,
The following changes since commit 2da8a79f7d81853d00b6a00621aeef7545196084:
Merge branch 'omap-for-v3.8/cleanup-headers-menelaus' into omap-for-v3.8/cleanup-headers (2012-10-25 12:21:48 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-fixes-a-for-3.8
for you to fetch changes up to 97af08b6e10e06563309728ed2fe8fdd919c5a33:
ARM: OMAP1: fix sparse warning added by commit 4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3 (2012-10-26 13:21:48 -0600)
- ----------------------------------------------------------------
Several fixes for build failures and sparse warnings in the
OMAP cleanup-headers branch. Intended for 3.8 cleanup.
Basic build, boot, and PM test logs are available from here:
http://www.pwsan.com/omap/testlogs/cleanup-headers-compile-fixes-3.8/20121026132711/
Due to underlying problems in v3.7-rc2, several tests fail. These
failures are unrelated to these patches.
- ----------------------------------------------------------------
Paul Walmsley (3):
ARM: OMAP2+: fix build breakage introduced by commit b7754452b3e27716347a528b47b0a1083af32520
ARM: OMAP1: fix build breakage introduced by commit 25c7d49ed48b4843da7dea56a81ae7f620211ee0
ARM: OMAP1: fix sparse warning added by commit 4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3
arch/arm/mach-omap1/fpga.c | 1 +
arch/arm/mach-omap1/pm_bus.c | 2 ++
drivers/mtd/onenand/omap2.c | 36 ++++++++++++++++++++++++------------
3 files changed, 27 insertions(+), 12 deletions(-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJQiu6QAAoJEMePsQ0LvSpLY3IQAJtQgiBIsGvk8FuXULl0xmt2
qftIgTpJ2r4PazBa+I2s3CZmF32vGK3vl2TE4MO+GtACRNgcZEMOuy6I3R2jg9P7
vl8Q+rZJ/v32KtWDfKGqxr1VjkUFz4qf5lPw3AqxY4nwGabeV7Ni+ys4F3BvNvSR
l2PtFY1GZZ6l52znHEDMZv2WRnlHyX5G0EFfxIfAxuTIu17d0WIQuI3/ozbwtlp3
s2wbY0akZPOF+fiMtm9hT7qVHDpqUfvnu6P/7MD41EFzqKWgW9j5qVRNDl2LzWRn
008Hd4RX6wnTGZguk7lh/v42D1SSf1ls6RJv5rPDKyaXBzexYQUWsg8OC/F9B6iN
yFMdauSDu45gvY9wJJAUy47IYnhQTHQ5PfvccnmYnymK8QjIpM5rOqGr3qkQ/zyd
hMbFOxzN1aeGcojnrgiCSCiJYIDtit9gEBoz6DnEYlKqnIuH25OlJi5/uBJ3Y809
f+Es/ajvTnZrWWA4X44UlqfW1V0WCYfDqpuzAlZVMInKrexghT34bvjMs1gu4iNr
thnZYhb386L0nD62G2yeUJpsuone2gZpbq1WQ6Mg4PDBrnIibD6BuFsToRxFTRGB
q2ZfO2Nm21gHmnVivDqs8vo/xJjEn4j6CiKI8VaZUlGg7iu7rtN0Rf7W2YfjG+h/
noV2yTKqbmtdq8PGcG2/
=A1XA
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH 3/3] ARM: OMAP1: fix sparse warning added by commit 4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3
From: Paul Walmsley @ 2012-10-26 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026200413.16521.88985.stgit@dusk.lan>
Commit 4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3 ("ARM: OMAP: Make
plat/fpga.h local to arch/arm/plat-omap") results in a new warning from
sparse:
arch/arm/mach-omap1/fpga.c:147:6: warning: symbol 'omap1510_fpga_init_irq' was not declared. Should it be static?
Fix by adding a missing include.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap1/fpga.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap1/fpga.c b/arch/arm/mach-omap1/fpga.c
index 4ec220d..d940fac 100644
--- a/arch/arm/mach-omap1/fpga.c
+++ b/arch/arm/mach-omap1/fpga.c
@@ -32,6 +32,7 @@
#include <mach/hardware.h>
#include "iomap.h"
+#include "common.h"
static void fpga_mask_irq(struct irq_data *d)
{
^ permalink raw reply related
* [PATCH 2/3] ARM: OMAP1: fix build breakage introduced by commit 25c7d49ed48b4843da7dea56a81ae7f620211ee0
From: Paul Walmsley @ 2012-10-26 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026200413.16521.88985.stgit@dusk.lan>
Commit 25c7d49ed48b4843da7dea56a81ae7f620211ee0 ("ARM: OMAP: Make
omap_device local to mach-omap2") broke an OMAP5912-only build here:
arch/arm/mach-omap1/pm_bus.c: In function 'omap1_pm_runtime_init':
arch/arm/mach-omap1/pm_bus.c:69:2: error: implicit declaration of function
'cpu_class_is_omap1'
make[1]: *** [arch/arm/mach-omap1/pm_bus.o] Error 1
Fix by adding a missing include.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap1/pm_bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap1/pm_bus.c b/arch/arm/mach-omap1/pm_bus.c
index 16bf2f9..3f2d396 100644
--- a/arch/arm/mach-omap1/pm_bus.c
+++ b/arch/arm/mach-omap1/pm_bus.c
@@ -19,6 +19,8 @@
#include <linux/clk.h>
#include <linux/err.h>
+#include "soc.h"
+
#ifdef CONFIG_PM_RUNTIME
static int omap1_pm_runtime_suspend(struct device *dev)
{
^ permalink raw reply related
* [PATCH 1/3] ARM: OMAP2+: fix build breakage introduced by commit b7754452b3e27716347a528b47b0a1083af32520
From: Paul Walmsley @ 2012-10-26 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026200413.16521.88985.stgit@dusk.lan>
Commit b7754452b3e27716347a528b47b0a1083af32520 ("mtd: onenand: omap:
use pdata info instead of cpu_is") broke an OMAP3+4 build and an N800
multi-OMAP2xxx build here:
drivers/built-in.o: In function `omap2_onenand_probe':
drivers/mtd/onenand/omap2.c:742: undefined reference to `omap2_onenand_read_bufferram'
drivers/mtd/onenand/omap2.c:743: undefined reference to `omap2_onenand_write_bufferram'
drivers/mtd/onenand/omap2.c:742: undefined reference to `omap2_onenand_read_bufferram'
drivers/mtd/onenand/omap2.c:743: undefined reference to `omap2_onenand_write_bufferram'
...
drivers/built-in.o: In function `omap2_onenand_probe':
drivers/mtd/onenand/omap2.c:788: undefined reference to `omap3_onenand_read_bufferram'
drivers/mtd/onenand/omap2.c:788: undefined reference to `omap3_onenand_write_bufferram'
Fix by declaring static functions for the missing symbols, rather than
just prototypes.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Afzal Mohammed <afzal@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
drivers/mtd/onenand/omap2.c | 36 ++++++++++++++++++++++++------------
1 file changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 53069ae..99f96e1 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -445,13 +445,19 @@ out_copy:
#else
-int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
- unsigned char *buffer, int offset,
- size_t count);
+static int omap3_onenand_read_bufferram(struct mtd_info *mtd, int area,
+ unsigned char *buffer, int offset,
+ size_t count)
+{
+ return -ENOSYS;
+}
-int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
- const unsigned char *buffer,
- int offset, size_t count);
+static int omap3_onenand_write_bufferram(struct mtd_info *mtd, int area,
+ const unsigned char *buffer,
+ int offset, size_t count)
+{
+ return -ENOSYS;
+}
#endif
@@ -549,13 +555,19 @@ static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
#else
-int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
- unsigned char *buffer, int offset,
- size_t count);
+static int omap2_onenand_read_bufferram(struct mtd_info *mtd, int area,
+ unsigned char *buffer, int offset,
+ size_t count)
+{
+ return -ENOSYS;
+}
-int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
- const unsigned char *buffer,
- int offset, size_t count);
+static int omap2_onenand_write_bufferram(struct mtd_info *mtd, int area,
+ const unsigned char *buffer,
+ int offset, size_t count)
+{
+ return -ENOSYS;
+}
#endif
^ permalink raw reply related
* [PATCH 0/3] ARM: OMAP: fix build, sparse problems in cleanup-headers
From: Paul Walmsley @ 2012-10-26 20:08 UTC (permalink / raw)
To: linux-arm-kernel
Fix several build failures and a sparse warning in the linux-omap
omap-for-v3.8/cleanup-headers branch.
Basic test logs are here:
http://www.pwsan.com/omap/testlogs/cleanup-headers-compile-fixes-3.8/20121026132711/
Due to underlying problems in v3.7-rc2, several tests fail. The
failures are unrelated to these patches.
Intended for 3.8 cleanup.
- Paul
---
cleanup-headers-compile-fixes-3.8
text data bss dec hex filename
5452826 352260 121588 5926674 5a6f12 vmlinux.omap1_defconfig.orig
5452826 352260 121588 5926674 5a6f12 vmlinux.omap1_defconfig
Paul Walmsley (3):
ARM: OMAP2+: fix build breakage introduced by commit b7754452b3e27716347a528b47b0a1083af32520
ARM: OMAP1: fix build breakage introduced by commit 25c7d49ed48b4843da7dea56a81ae7f620211ee0
ARM: OMAP1: fix sparse warning added by commit 4c98dc6b8ef2f73bdbfa78186db9a76507ba9ea3
arch/arm/mach-omap1/fpga.c | 1 +
arch/arm/mach-omap1/pm_bus.c | 2 ++
drivers/mtd/onenand/omap2.c | 36 ++++++++++++++++++++++++------------
3 files changed, 27 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH v2 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp
From: Felipe Balbi @ 2012-10-26 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026172140.GJ11908@atomide.com>
On Fri, Oct 26, 2012 at 10:21:41AM -0700, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@arndb.de> [121026 00:48]:
> > On Friday 26 October 2012, Felipe Balbi wrote:
> > > > +static void omap_init_ocp2scp(void)
> > > > +{
> > > > + struct omap_hwmod *oh;
> > > > + struct platform_device *pdev;
> > > > + int bus_id = -1, dev_cnt = 0, i;
> > > > + struct omap_ocp2scp_dev *ocp2scp_dev;
> > > > + const char *oh_name, *name;
> > > > + struct omap_ocp2scp_platform_data *pdata;
> > > > +
> > > > + oh_name = "ocp2scp_usb_phy";
> > > > + name = "omap-ocp2scp";
> > >
> > > how about adding checks here to return early case we're not running on
> > > OMAP4 or OMAP5 ??
> > >
> >
> > I suppose even OMAP4-only, since OMAP5 always has DT enabled.
>
> Hmm yes, currently omap_hwmod_lookup(oh_name) produces
> bogus errors for other omaps as the hwmod data is only
> there for omap4.
shouldn't that be fixed too ? I mean, if data isn't just return -ENODEV
or something similar.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/f7cbc29e/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support
From: Felipe Balbi @ 2012-10-26 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026171655.GI11908@atomide.com>
Hi,
On Fri, Oct 26, 2012 at 10:16:55AM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [121025 23:55]:
> > On Thu, Oct 25, 2012 at 10:44:47AM -0700, Tony Lindgren wrote:
> > > * Felipe Balbi <balbi@ti.com> [121024 23:24]:
> > > > Hi,
> > > >
> > > > On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote:
> > > > > * Tony Lindgren <tony@atomide.com> [121016 09:53]:
> > > > > > * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > > > > > > ocp2scp was not having pdata support which makes *musb* fail for non-dt
> > > > > > > boot in OMAP platform. The pdata will have information about the devices
> > > > > > > that is connected to ocp2scp. ocp2scp driver will now make use of this
> > > > > > > information to create the devices that is attached to ocp2scp.
> > > > > > >
> > > > > > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> > > > > >
> > > > > > This fixes the regression on my panda es for musb port:
> > > > > >
> > > > > > Acked-by: Tony Lindgren <tony@atomide.com>
> > > > >
> > > > > Looks like nobody has picked this one up and we need it to
> > > > > fix the musb regression on omap, so I'll queue these up.
> > > >
> > > > I don't seem to have the patches around in any mailbox :-(
> > >
> > > Bounced them to you. Do you have any better ideas for the
> > > -rc cycle to fix the MUSB regression on omap4?
> >
> > Well, there are two regressions that I know of. One is caused by the
> > mode1 DMA changes, which I'll just revert, and the other is the
> > missing platform_data support on the new PHY driver which these patches
> > are supposed to solve, right ?
>
> Yes that's it AFAIK.
Kishon, any other patches I need to take to get MUSB working on v3.7 ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/57bda15d/attachment.sig>
^ permalink raw reply
* [RFC][PATCH 0/5] Introduce .get_voltage callback into voltdm
From: Mike Turquette @ 2012-10-26 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fw51hzcg.fsf@deeprootsystems.com>
Quoting Kevin Hilman (2012-10-26 11:17:51)
> Hi Mike,
>
> Mike Turquette <mturquette@ti.com> writes:
>
> > From: Mike Turquette <mturquette@linaro.org>
> >
> > This series creates a new callback for struct voltagedomain,
> > .get_voltage. This fetches the voltage from hardware, if possible, and
> > returns it to the caller. We use this call to populate
> > voltdm->nominal_volt at boot time.
>
> I pointed out a couple nitpicky things on individual patches, but
> otherwise this direction and motiviation for this series looks OK by me.
>
> Just some minor comments about the structure of the series. I tend to
> prefer combining the introduction of a new function with it's usage. It
> makes review and understanding much easier, IMO. If there are reasons
> to keep them separate, that's fine too. Just describe the reasons in
> the cover letter.
>
Will do. I've thought on this topic a bit more and this approach isn't
quite robust enough. For instance it assumes that the kernel's voltage
scaling approach (vp_forceupdate vs. vc_bypass) matches what the
bootloader does. This is of course an unsafe assumption.
Also I've seen the Android guys struggle with this a bit and I'd like to
review how they approached the problem before sending my next series.
Couple with upcoming travel I'm not sure how quickly I'll get a V2 on
the list.
Thanks for reviewing,
Mike
> Thanks,
>
> Kevin
^ permalink raw reply
* [PATCH 0/6] Initial Calxeda ECX-2000 support
From: Arnd Bergmann @ 2012-10-26 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351276988-28382-1-git-send-email-robherring2@gmail.com>
On Friday 26 October 2012, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> This series adds initial support for Calxeda A15 based ECX-2000 SOC. Most
> of the changes are shuffling of dts files to share common parts between
> highbank (ECX-1000) and ECX-2000 and abstracting out or removing SCU
> accesses as the A15 has no SCU registers.
>
> Although the highbank name really refers to 1st gen SOC, the highbank
> name in the kernel is now referring to both SOCs.
The patches all look good to me,
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH] at91sam9m10g45-ek: rename leds to match board
From: Alexandre Belloni @ 2012-10-26 19:29 UTC (permalink / raw)
To: linux-arm-kernel
The leds' name in the board file didn't match the names written on the
board itsef. This can be confusing when trying to use them for another
purpose.
Signed-off-by: Alexandre Belloni <alexandre.belloni@piout.net>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/at91sam9m10g45ek.dts | 12 ++++++------
arch/arm/mach-at91/board-sam9m10g45ek.c | 8 ++++----
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 15e1dd4..c58b628 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -93,20 +93,20 @@
leds {
compatible = "gpio-leds";
- d8 {
- label = "d8";
+ d3 {
+ label = "d3";
gpios = <&pioD 30 0>;
linux,default-trigger = "heartbeat";
};
- d6 {
- label = "d6";
+ d1 {
+ label = "d1";
gpios = <&pioD 0 1>;
linux,default-trigger = "nand-disk";
};
- d7 {
- label = "d7";
+ d2 {
+ label = "d2";
gpios = <&pioD 31 1>;
linux,default-trigger = "mmc0";
};
diff --git a/arch/arm/mach-at91/board-sam9m10g45ek.c b/arch/arm/mach-at91/board-sam9m10g45ek.c
index 3d48ec1..6d77687 100644
--- a/arch/arm/mach-at91/board-sam9m10g45ek.c
+++ b/arch/arm/mach-at91/board-sam9m10g45ek.c
@@ -413,19 +413,19 @@ static struct ac97c_platform_data ek_ac97_data = {
*/
static struct gpio_led ek_leds[] = {
{ /* "top" led, red, powerled */
- .name = "d8",
+ .name = "d3",
.gpio = AT91_PIN_PD30,
.default_trigger = "heartbeat",
},
{ /* "left" led, green, userled2, pwm3 */
- .name = "d6",
+ .name = "d1",
.gpio = AT91_PIN_PD0,
.active_low = 1,
.default_trigger = "nand-disk",
},
#if !(defined(CONFIG_LEDS_ATMEL_PWM) || defined(CONFIG_LEDS_ATMEL_PWM_MODULE))
{ /* "right" led, green, userled1, pwm1 */
- .name = "d7",
+ .name = "d2",
.gpio = AT91_PIN_PD31,
.active_low = 1,
.default_trigger = "mmc0",
@@ -440,7 +440,7 @@ static struct gpio_led ek_leds[] = {
static struct gpio_led ek_pwm_led[] = {
#if defined(CONFIG_LEDS_ATMEL_PWM) || defined(CONFIG_LEDS_ATMEL_PWM_MODULE)
{ /* "right" led, green, userled1, pwm1 */
- .name = "d7",
+ .name = "d2",
.gpio = 1, /* is PWM channel number */
.active_low = 1,
.default_trigger = "none",
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/7] ARM: EXYNOS: add support for EXYNOS5440 SoC
From: Tomasz Figa @ 2012-10-26 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351274153-3120-2-git-send-email-kgene.kim@samsung.com>
Hi Kgene,
Please see my comments inline.
On Saturday 27 of October 2012 02:55:48 Kukjin Kim wrote:
> This patch adds support for EXYNOS5440 SoC which is including
> Cortex-A15 Quad cores.
>
> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> ---
> arch/arm/mach-exynos/Kconfig | 20 ++++++
> arch/arm/mach-exynos/Makefile | 3 +-
> arch/arm/mach-exynos/common.c | 85
> ++++++++++++++++++++++++-- arch/arm/mach-exynos/common.h
> | 2 +
> arch/arm/mach-exynos/dev-uart.c | 14 ++++
> arch/arm/mach-exynos/include/mach/irqs.h | 5 ++
> arch/arm/mach-exynos/include/mach/map.h | 8 +++
> arch/arm/mach-exynos/include/mach/regs-pmu.h | 1 +
> arch/arm/mach-exynos/mach-exynos5-dt.c | 34 ++++++++---
> arch/arm/mach-exynos/mct.c | 15 +++++
> arch/arm/mach-exynos/setup-i2c0.c | 2 +-
> arch/arm/plat-samsung/include/plat/cpu.h | 8 +++
> arch/arm/plat-samsung/include/plat/devs.h | 1 +
> drivers/tty/serial/samsung.c | 3 +-
> 14 files changed, 184 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 1d0d083..c047aba 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -68,6 +68,16 @@ config SOC_EXYNOS5250
> help
> Enable EXYNOS5250 SoC support
>
> +config SOC_EXYNOS5440
> + bool "SAMSUNG EXYNOS5440"
> + default y
> + depends on ARCH_EXYNOS5
> + select ARM_ARCH_TIMER
> + select AUTO_ZRELADDR
> + select COMMON_CLK
> + help
> + Enable EXYNOS5440 SoC support
> +
> config EXYNOS4_MCT
> bool
> default y
> @@ -426,6 +436,16 @@ config MACH_EXYNOS5_DT
> Machine support for Samsung EXYNOS5 machine with device tree
> enabled. Select this if a fdt blob is available for the EXYNOS5 SoC
> based board.
>
> +config MACH_EXYNOS5440_DT
> + bool "SAMSUNG EXYNOS5440 Machine using device tree"
> + depends on ARCH_EXYNOS5
> + select ARM_AMBA
> + select SOC_EXYNOS5440
> + select USE_OF
> + help
> + Machine support for Samsung EXYNOS5440 machine with device tree
> enabled. + Select this if a fdt blob is available for the EXYNOS5440
> SoC based board. +
> if ARCH_EXYNOS4
>
> comment "Configuration for HSMMC 8-bit bus width"
> diff --git a/arch/arm/mach-exynos/Makefile
> b/arch/arm/mach-exynos/Makefile index ad66c9f4..92df758 100644
> --- a/arch/arm/mach-exynos/Makefile
> +++ b/arch/arm/mach-exynos/Makefile
> @@ -13,7 +13,7 @@ obj- :=
> # Core
>
> obj-$(CONFIG_ARCH_EXYNOS) += common.o
> -obj-$(CONFIG_ARCH_EXYNOS5) += clock-exynos5.o
> +obj-$(CONFIG_SOC_EXYNOS5250) += clock-exynos5.o
>
> obj-$(CONFIG_PM) += pm.o
> obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
> @@ -41,6 +41,7 @@ obj-$(CONFIG_MACH_SMDK4412) += mach-smdk4x12.o
>
> obj-$(CONFIG_MACH_EXYNOS4_DT) += mach-exynos4-dt.o
> obj-$(CONFIG_MACH_EXYNOS5_DT) += mach-exynos5-dt.o
> +obj-$(CONFIG_MACH_EXYNOS5440_DT) += mach-exynos5-dt.o
>
> # device support
>
> diff --git a/arch/arm/mach-exynos/common.c
> b/arch/arm/mach-exynos/common.c index fea1542..786d8f4 100644
> --- a/arch/arm/mach-exynos/common.c
> +++ b/arch/arm/mach-exynos/common.c
> @@ -57,9 +57,11 @@ static const char name_exynos4210[] = "EXYNOS4210";
> static const char name_exynos4212[] = "EXYNOS4212";
> static const char name_exynos4412[] = "EXYNOS4412";
> static const char name_exynos5250[] = "EXYNOS5250";
> +static const char name_exynos5440[] = "EXYNOS5440";
>
> static void exynos4_map_io(void);
> static void exynos5_map_io(void);
> +static void exynos5440_map_io(void);
> static void exynos5_init_clocks(int xtal);
> static void exynos_init_uarts(struct s3c2410_uartcfg *cfg, int no);
> static int exynos_init(void);
> @@ -94,6 +96,13 @@ static struct cpu_table cpu_ids[] __initdata = {
> .init_uarts = exynos_init_uarts,
> .init = exynos_init,
> .name = name_exynos5250,
> + }, {
> + .idcode = EXYNOS5440_SOC_ID,
> + .idmask = EXYNOS5_SOC_MASK,
> + .map_io = exynos5440_map_io,
> + .init_uarts = exynos_init_uarts,
> + .init = exynos_init,
> + .name = name_exynos5440,
> },
> };
>
> @@ -108,6 +117,15 @@ static struct map_desc exynos_iodesc[] __initdata =
> { },
> };
>
> +static struct map_desc exynos5440_iodesc[] __initdata = {
> + {
> + .virtual = (unsigned long)S5P_VA_CHIPID,
> + .pfn = __phys_to_pfn(EXYNOS5440_PA_CHIPID),
> + .length = SZ_4K,
> + .type = MT_DEVICE,
> + },
> +};
> +
> static struct map_desc exynos4_iodesc[] __initdata = {
> {
> .virtual = (unsigned long)S3C_VA_SYS,
> @@ -274,6 +292,25 @@ static struct map_desc exynos5_iodesc[] __initdata
> = { },
> };
>
> +static struct map_desc exynos5440_iodesc0[] __initdata = {
> + {
> + .virtual = (unsigned long)S3C_VA_UART,
> + .pfn = __phys_to_pfn(EXYNOS5440_PA_UART0),
> + .length = SZ_512K,
> + .type = MT_DEVICE,
> + }, {
> + .virtual = (unsigned long)S5P_VA_GIC_CPU,
> + .pfn = __phys_to_pfn(EXYNOS5440_PA_GIC_CPU),
> + .length = SZ_64K,
> + .type = MT_DEVICE,
> + }, {
> + .virtual = (unsigned long)S5P_VA_GIC_DIST,
> + .pfn = __phys_to_pfn(EXYNOS5440_PA_GIC_DIST),
> + .length = SZ_64K,
> + .type = MT_DEVICE,
> + },
> +};
> +
> void exynos4_restart(char mode, const char *cmd)
> {
> __raw_writel(0x1, S5P_SWRESET);
> @@ -281,11 +318,29 @@ void exynos4_restart(char mode, const char *cmd)
>
> void exynos5_restart(char mode, const char *cmd)
> {
> - __raw_writel(0x1, EXYNOS_SWRESET);
> + u32 val;
> + void __iomem *addr;
> +
> + if (of_machine_is_compatible("samsung,exynos5250")) {
> + val = 0x1;
> + addr = EXYNOS_SWRESET;
> + } else if (of_machine_is_compatible("samsung,exynos5440")) {
> + val = (0x10 << 20) | (0x1 << 16);
> + addr = EXYNOS5440_SWRESET;
> + } else {
> + pr_err("%s: cannot support non-DT\n", __func__);
> + return;
> + }
Why soc_is_XXX isn't used here? It should be faster and more correct than of_machine_is_compatible.
I can imagine the same board available with two different SoCs, for which of_machine_is_compatible wouldn't work.
> +
> + __raw_writel(val, addr);
> }
>
> void __init exynos_init_late(void)
> {
> + if (of_machine_is_compatible("samsung,exynos5440"))
> + /* to be supported later */
> + return;
Same here.
> exynos_pm_late_initcall();
> }
>
> @@ -298,7 +353,11 @@ void __init exynos_init_late(void)
> void __init exynos_init_io(struct map_desc *mach_desc, int size)
> {
> /* initialize the io descriptors we need for initialization */
> - iotable_init(exynos_iodesc, ARRAY_SIZE(exynos_iodesc));
> + if (of_machine_is_compatible("samsung,exynos5440"))
> + iotable_init(exynos5440_iodesc, ARRAY_SIZE(exynos5440_iodesc));
> + else
> + iotable_init(exynos_iodesc, ARRAY_SIZE(exynos_iodesc));
> +
Same here.
> if (mach_desc)
> iotable_init(mach_desc, size);
>
> @@ -364,6 +423,11 @@ static void __init exynos5_map_io(void)
> s3c_i2c2_setname("s3c2440-i2c");
> }
>
> +static void __init exynos5440_map_io(void)
> +{
> + iotable_init(exynos5440_iodesc0, ARRAY_SIZE(exynos5440_iodesc0));
> +}
> +
> static void __init exynos5_init_clocks(int xtal)
> {
> printk(KERN_DEBUG "%s: initializing clocks\n", __func__);
> @@ -587,6 +651,11 @@ static const struct of_device_id
> exynos4_dt_irq_match[] = { .data = combiner_of_init, },
> {},
> };
> +
> +static const struct of_device_id exynos5440_dt_irq_match[] = {
> + { .compatible = "arm,cortex-a15-gic", .data = gic_of_init, },
> + {},
> +};
> #endif
>
> void __init exynos4_init_irq(void)
> @@ -616,14 +685,18 @@ void __init exynos4_init_irq(void)
> void __init exynos5_init_irq(void)
> {
> #ifdef CONFIG_OF
> - of_irq_init(exynos4_dt_irq_match);
> + if (soc_is_exynos5440())
> + of_irq_init(exynos5440_dt_irq_match);
> + else
> + of_irq_init(exynos4_dt_irq_match);
This looks much better.
> #endif
> /*
> * The parameters of s5p_init_irq() are for VIC init.
> * Theses parameters should be NULL and 0 because EXYNOS4
> * uses GIC instead of VIC.
> */
> - s5p_init_irq(NULL, 0);
> + if (!soc_is_exynos5440())
> + s5p_init_irq(NULL, 0);
> }
>
> struct bus_type exynos_subsys = {
> @@ -646,7 +719,7 @@ static int __init exynos4_l2x0_cache_init(void)
> {
> int ret;
>
> - if (soc_is_exynos5250())
> + if (soc_is_exynos5250() || soc_is_exynos5440())
> return 0;
>
> ret = l2x0_of_init(L2_AUX_VAL, L2_AUX_MASK);
> @@ -714,6 +787,8 @@ static void __init exynos_init_uarts(struct
> s3c2410_uartcfg *cfg, int no)
>
> if (soc_is_exynos5250())
> s3c24xx_init_uartdevs("exynos4210-uart", exynos5_uart_resources, cfg,
> no); + else if (soc_is_exynos5440())
> + s3c24xx_init_uartdevs("exynos4210-uart", exynos5440_uart_resources,
> cfg, no); else
> s3c24xx_init_uartdevs("exynos4210-uart", exynos4_uart_resources, cfg,
> no); }
> diff --git a/arch/arm/mach-exynos/common.h
> b/arch/arm/mach-exynos/common.h index 7a4e0ea..99b88f8 100644
> --- a/arch/arm/mach-exynos/common.h
> +++ b/arch/arm/mach-exynos/common.h
> @@ -13,9 +13,11 @@
> #define __ARCH_ARM_MACH_EXYNOS_COMMON_H
>
> extern struct sys_timer exynos4_timer;
> +extern struct sys_timer exynos5_timer;
>
> struct map_desc;
> void exynos_init_io(struct map_desc *mach_desc, int size);
> +void exynos5440_init_io(struct map_desc *mach_desc, int size);
> void exynos4_init_irq(void);
> void exynos5_init_irq(void);
> void exynos4_restart(char mode, const char *cmd);
> diff --git a/arch/arm/mach-exynos/dev-uart.c
> b/arch/arm/mach-exynos/dev-uart.c index 2e85c02..95b887f 100644
> --- a/arch/arm/mach-exynos/dev-uart.c
> +++ b/arch/arm/mach-exynos/dev-uart.c
> @@ -76,3 +76,17 @@ struct s3c24xx_uart_resources
> exynos5_uart_resources[] __initdata = { .nr_resources =
> ARRAY_SIZE(exynos5_uart3_resource),
> },
> };
> +
> +EXYNOS_UART_RESOURCE(5440, 0)
> +EXYNOS_UART_RESOURCE(5440, 1)
> +
> +struct s3c24xx_uart_resources exynos5440_uart_resources[] __initdata =
> { + [0] = {
> + .resources = exynos5440_uart0_resource,
> + .nr_resources = ARRAY_SIZE(exynos5440_uart0_resource),
> + },
> + [1] = {
> + .resources = exynos5440_uart1_resource,
> + .nr_resources = ARRAY_SIZE(exynos5440_uart0_resource),
> + },
> +};
> diff --git a/arch/arm/mach-exynos/include/mach/irqs.h
> b/arch/arm/mach-exynos/include/mach/irqs.h index 35bced6..f43a96c
> 100644
> --- a/arch/arm/mach-exynos/include/mach/irqs.h
> +++ b/arch/arm/mach-exynos/include/mach/irqs.h
> @@ -333,6 +333,11 @@
> #define EXYNOS5_IRQ_FIMC_LITE1 IRQ_SPI(126)
> #define EXYNOS5_IRQ_RP_TIMER IRQ_SPI(127)
>
> +/* EXYNOS5440 */
> +
> +#define EXYNOS5440_IRQ_UART0 IRQ_SPI(2)
> +#define EXYNOS5440_IRQ_UART1 IRQ_SPI(3)
> +
> #define EXYNOS5_IRQ_PMU COMBINER_IRQ(1, 2)
>
> #define EXYNOS5_IRQ_SYSMMU_GSC0_0 COMBINER_IRQ(2, 0)
> diff --git a/arch/arm/mach-exynos/include/mach/map.h
> b/arch/arm/mach-exynos/include/mach/map.h index 8480849..d0602d3 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -53,12 +53,14 @@
> #define EXYNOS4_PA_ONENAND_DMA 0x0C600000
>
> #define EXYNOS_PA_CHIPID 0x10000000
> +#define EXYNOS5440_PA_CHIPID 0x00160000
>
> #define EXYNOS4_PA_SYSCON 0x10010000
> #define EXYNOS5_PA_SYSCON 0x10050100
>
> #define EXYNOS4_PA_PMU 0x10020000
> #define EXYNOS5_PA_PMU 0x10040000
> +#define EXYNOS5440_PA_PMU 0x00160000
>
> #define EXYNOS4_PA_CMU 0x10030000
> #define EXYNOS5_PA_CMU 0x10010000
> @@ -83,6 +85,8 @@
> #define EXYNOS4_PA_GIC_DIST 0x10490000
> #define EXYNOS5_PA_GIC_CPU 0x10482000
> #define EXYNOS5_PA_GIC_DIST 0x10481000
> +#define EXYNOS5440_PA_GIC_CPU 0x002E2000
> +#define EXYNOS5440_PA_GIC_DIST 0x002E1000
>
> #define EXYNOS4_PA_COREPERI 0x10500000
> #define EXYNOS4_PA_TWD 0x10500600
> @@ -281,6 +285,10 @@
> #define EXYNOS5_PA_UART3 0x12C30000
> #define EXYNOS5_SZ_UART SZ_256
>
> +#define EXYNOS5440_PA_UART0 0x000B0000
> +#define EXYNOS5440_PA_UART1 0x000C0000
> +#define EXYNOS5440_SZ_UART SZ_256
> +
> #define S3C_VA_UARTx(x) (S3C_VA_UART + ((x) * S3C_UART_OFFSET))
>
> #endif /* __ASM_ARCH_MAP_H */
> diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h
> b/arch/arm/mach-exynos/include/mach/regs-pmu.h index d4e392b..c0b74f3
> 100644
> --- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
> +++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
> @@ -31,6 +31,7 @@
>
> #define S5P_SWRESET S5P_PMUREG(0x0400)
> #define EXYNOS_SWRESET S5P_PMUREG(0x0400)
> +#define EXYNOS5440_SWRESET S5P_PMUREG(0x00C4)
>
> #define S5P_WAKEUP_STAT S5P_PMUREG(0x0600)
> #define S5P_EINT_WAKEUP_MASK S5P_PMUREG(0x0604)
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
> b/arch/arm/mach-exynos/mach-exynos5-dt.c index db1cd8e..7052f80 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -75,20 +75,24 @@ static const struct of_dev_auxdata
> exynos5250_auxdata_lookup[] __initconst = { {},
> };
>
> -static void __init exynos5250_dt_map_io(void)
> +static void __init exynos5_dt_map_io(void)
> {
> exynos_init_io(NULL, 0);
> - s3c24xx_init_clocks(24000000);
> +
> + if (of_machine_is_compatible("samsung,exynos5250"))
> + s3c24xx_init_clocks(24000000);
Again soc_is_XXX().
> }
>
> -static void __init exynos5250_dt_machine_init(void)
> +static void __init exynos5_dt_machine_init(void)
> {
> - of_platform_populate(NULL, of_default_bus_match_table,
> - exynos5250_auxdata_lookup, NULL);
> + if (of_machine_is_compatible("samsung,exynos5250"))
> + of_platform_populate(NULL, of_default_bus_match_table,
> + exynos5250_auxdata_lookup, NULL);
> }
>
> -static char const *exynos5250_dt_compat[] __initdata = {
> +static char const *exynos5_dt_compat[] __initdata = {
> "samsung,exynos5250",
> + "samsung,exynos5440",
> NULL
> };
Something doesn't seem right here. How do you distinguish between
MACH_EXYNOS5_DT and MACH_EXYNOS5440_DT if both have the same compatible
matches?
Those machines doesn't seem to share much definitions, so maybe a separate
mach-exynos5440-dt.c file would be a better approach?
> @@ -96,11 +100,23 @@ DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5
> (Flattened Device Tree)") /* Maintainer: Kukjin Kim
> <kgene.kim@samsung.com> */
> .init_irq = exynos5_init_irq,
> .smp = smp_ops(exynos_smp_ops),
> - .map_io = exynos5250_dt_map_io,
> + .map_io = exynos5_dt_map_io,
> .handle_irq = gic_handle_irq,
> - .init_machine = exynos5250_dt_machine_init,
> + .init_machine = exynos5_dt_machine_init,
> .init_late = exynos_init_late,
> .timer = &exynos4_timer,
> - .dt_compat = exynos5250_dt_compat,
> + .dt_compat = exynos5_dt_compat,
> + .restart = exynos5_restart,
> +MACHINE_END
> +
> +DT_MACHINE_START(EXYNOS5440_DT, "SAMSUNG EXYNOS5440 (Flattened Device
> Tree)") + /* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
> + .init_irq = exynos5_init_irq,
> + .smp = smp_ops(exynos_smp_ops),
> + .map_io = exynos5_dt_map_io,
> + .handle_irq = gic_handle_irq,
> + .init_machine = exynos5_dt_machine_init,
> + .timer = &exynos5_timer,
> + .dt_compat = exynos5_dt_compat,
> .restart = exynos5_restart,
Since restarts for both differ, why not to add separate exynos5440 restart
and use it here?
> MACHINE_END
> diff --git a/arch/arm/mach-exynos/mct.c b/arch/arm/mach-exynos/mct.c
> index cc3805a..31f45ec 100644
> --- a/arch/arm/mach-exynos/mct.c
> +++ b/arch/arm/mach-exynos/mct.c
> @@ -19,7 +19,9 @@
> #include <linux/platform_device.h>
> #include <linux/delay.h>
> #include <linux/percpu.h>
> +#include <linux/of.h>
>
> +#include <asm/arch_timer.h>
> #include <asm/hardware/gic.h>
> #include <asm/localtimer.h>
>
> @@ -487,6 +489,9 @@ static void __init exynos4_timer_init(void)
> exynos4x12_clk_init();
> #endif
>
> + if (of_machine_is_compatible("samsung,exynos5440"))
> + arch_timer_of_register();
> +
Why exynos4_timer_init is being touched here, if exynos5_timer_init is
being added?
I would rather keep exynos4_timer (which is used for all Exynos4 SoCs
and for Exynos5250) as is and define new exynos5250_timer if it needs
completely different initialization...
> if ((soc_is_exynos4210()) || (soc_is_exynos5250()))
> mct_int_type = MCT_INT_SPI;
> else
> @@ -500,3 +505,13 @@ static void __init exynos4_timer_init(void)
> struct sys_timer exynos4_timer = {
> .init = exynos4_timer_init,
> };
> +
> +static void __init exynos5_timer_init(void)
> +{
> + if (of_machine_is_compatible("samsung,exynos5440"))
> + arch_timer_of_register();
> +}
Also again this of_machine_is_compatible().
Best regards,
Tomasz Figa
^ permalink raw reply
* [GIT PULL] vexpress: soc changes for v3.8
From: Arnd Bergmann @ 2012-10-26 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351273532.9454.43.camel@hornet>
On Friday 26 October 2012, Pawel Moll wrote:
>
> On Fri, 2012-10-26 at 18:18 +0100, Arnd Bergmann wrote:
> > Are you sure it's the same commit that Mike has in his tree?
> > Is this not the tree that is part of linux-next?
>
> Damn, I am seriously confused now... I'm looking at next-20121026 in
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git and
> I'm not seeing the vexpress clk drivers! Neither I can find the
> patches in git://git.linaro.org/people/mturquette/linux.git clk-next.
>
> Am I doing something wrong or just looking not where I should? You seem
> to be able to see some -next vexpress clk patches - where about?
I'm the one who was confused, they are not actually in linux-next for
all I can tell, neither the version you used nor any other.
Arnd
^ permalink raw reply
* [PATCH v5] gpio/omap: fix off-mode bug: clear debounce settings on free/reset
From: Jon Hunter @ 2012-10-26 19:26 UTC (permalink / raw)
To: linux-arm-kernel
This change was originally titled "gpio/omap: fix off-mode bug: clear debounce
clock enable mask on free/reset". The title has been updated slightly to
reflect (what should be) the final fix.
When a GPIO is freed or shutdown, we need to ensure that any debounce settings
are cleared and if the GPIO is the only GPIO in the bank that is currently
using debounce, then disable the debounce clock as well to save power.
Currently, the debounce settings are not cleared on a GPIO free or shutdown and
so during a context restore on subsequent off-mode transition, the previous
debounce values are restored from the shadow copies (bank->context.debounce*)
leading to mismatch state between driver state and hardware state.
This was discovered when board code was doing
gpio_request_one()
gpio_set_debounce()
gpio_free()
which was leaving the GPIO debounce settings in a confused state. If that GPIO
bank is subsequently used with off-mode enabled, bogus state would be restored,
leaving GPIO debounce enabled which then prevented the CORE powerdomain from
transitioning.
To fix this, introduce a new function called _clear_gpio_debounce() to clear
any debounce settings when the GPIO is freed or shutdown. If this GPIO is the
last debounce-enabled GPIO in the bank, the debounce will also be cut.
Please note that we cannot use _gpio_dbck_disable() to disable the debounce
clock because this has been specifically created for the gpio suspend path
and is intended to shutdown the debounce clock while debounce is enabled.
Special thanks to Kevin Hilman for root causing the bug. This fix is a
collaborative effort with inputs from Kevin Hilman, Grazvydas Ignotas and
Santosh Shilimkar.
Testing:
- This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
enabling debounce and then freeing the gpio and checking the register
contents, the saved register context and the debounce clock state.
- Kevin Hilman tested on 37xx/EVM board which configures GPIO debounce for the
ads7846 touchscreen in its board file using the above sequence, and so was
failing off-mode tests in dynamic idle. Verified that off-mode tests are
passing with this patch.
V5 changes:
- Corrected author
Reported-by: Paul Walmsley <paul@pwsan.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
drivers/gpio/gpio-omap.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..d335af1 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -251,6 +251,40 @@ static void _set_gpio_debounce(struct gpio_bank *bank, unsigned gpio,
}
}
+/**
+ * _clear_gpio_debounce - clear debounce settings for a gpio
+ * @bank: the gpio bank we're acting upon
+ * @gpio: the gpio number on this @gpio
+ *
+ * If a gpio is using debounce, then clear the debounce enable bit and if
+ * this is the only gpio in this bank using debounce, then clear the debounce
+ * time too. The debounce clock will also be disabled when calling this function
+ * if this is the only gpio in the bank using debounce.
+ */
+static void _clear_gpio_debounce(struct gpio_bank *bank, unsigned gpio)
+{
+ u32 gpio_bit = GPIO_BIT(bank, gpio);
+
+ if (!bank->dbck_flag)
+ return;
+
+ if (!(bank->dbck_enable_mask & gpio_bit))
+ return;
+
+ bank->dbck_enable_mask &= ~gpio_bit;
+ bank->context.debounce_en &= ~gpio_bit;
+ __raw_writel(bank->context.debounce_en,
+ bank->base + bank->regs->debounce_en);
+
+ if (!bank->dbck_enable_mask) {
+ bank->context.debounce = 0;
+ __raw_writel(bank->context.debounce, bank->base +
+ bank->regs->debounce);
+ clk_disable(bank->dbck);
+ bank->dbck_enabled = false;
+ }
+}
+
static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
unsigned trigger)
{
@@ -539,6 +573,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
_set_gpio_irqenable(bank, gpio, 0);
_clear_gpio_irqstatus(bank, gpio);
_set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
+ _clear_gpio_debounce(bank, gpio);
}
/* Use disable_irq_wake() and enable_irq_wake() functions from drivers */
--
1.7.9.5
^ permalink raw reply related
* [RESEND][PATCH v4] gpio/omap: fix off-mode bug: clear debounce settings on free/reset
From: Jon Hunter @ 2012-10-26 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351279246-3923-1-git-send-email-jon-hunter@ti.com>
Sorry, ignore these ...
On 10/26/2012 02:20 PM, Jon Hunter wrote:
> From: Kevin Hilman <khilman@ti.com>
... forgot to change the author from Kevin to me. Will re-post.
Jon
> This change was originally titled "gpio/omap: fix off-mode bug: clear debounce
> clock enable mask on free/reset". The title has been updated slightly to
> reflect (what should be) the final fix.
>
> When a GPIO is freed or shutdown, we need to ensure that any debounce settings
> are cleared and if the GPIO is the only GPIO in the bank that is currently
> using debounce, then disable the debounce clock as well to save power.
>
> Currently, the debounce settings are not cleared on a GPIO free or shutdown and
> so during a context restore on subsequent off-mode transition, the previous
> debounce values are restored from the shadow copies (bank->context.debounce*)
> leading to mismatch state between driver state and hardware state.
>
> This was discovered when board code was doing
>
> gpio_request_one()
> gpio_set_debounce()
> gpio_free()
>
> which was leaving the GPIO debounce settings in a confused state. If that GPIO
> bank is subsequently used with off-mode enabled, bogus state would be restored,
> leaving GPIO debounce enabled which then prevented the CORE powerdomain from
> transitioning.
>
> To fix this, introduce a new function called _clear_gpio_debounce() to clear
> any debounce settings when the GPIO is freed or shutdown. If this GPIO is the
> last debounce-enabled GPIO in the bank, the debounce will also be cut.
>
> Please note that we cannot use _gpio_dbck_disable() to disable the debounce
> clock because this has been specifically created for the gpio suspend path
> and is intended to shutdown the debounce clock while debounce is enabled.
>
> Special thanks to Kevin Hilman for root causing the bug. This fix is a
> collaborative effort with inputs from Kevin Hilman, Grazvydas Ignotas and
> Santosh Shilimkar.
>
> Testing:
> - This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
> enabling debounce and then freeing the gpio and checking the register
> contents, the saved register context and the debounce clock state.
> - Kevin Hilman tested on 37xx/EVM board which configures GPIO debounce for the
> ads7846 touchscreen in its board file using the above sequence, and so was
> failing off-mode tests in dynamic idle. Verified that off-mode tests are
> passing with this patch.
>
> Reported-by: Paul Walmsley <paul@pwsan.com>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
> Cc: Grazvydas Ignotas <notasas@gmail.com>
> Cc: Jon Hunter <jon-hunter@ti.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> Tested-by: Kevin Hilman <khilman@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> drivers/gpio/gpio-omap.c | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 94cbc84..d335af1 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -251,6 +251,40 @@ static void _set_gpio_debounce(struct gpio_bank *bank, unsigned gpio,
> }
> }
>
> +/**
> + * _clear_gpio_debounce - clear debounce settings for a gpio
> + * @bank: the gpio bank we're acting upon
> + * @gpio: the gpio number on this @gpio
> + *
> + * If a gpio is using debounce, then clear the debounce enable bit and if
> + * this is the only gpio in this bank using debounce, then clear the debounce
> + * time too. The debounce clock will also be disabled when calling this function
> + * if this is the only gpio in the bank using debounce.
> + */
> +static void _clear_gpio_debounce(struct gpio_bank *bank, unsigned gpio)
> +{
> + u32 gpio_bit = GPIO_BIT(bank, gpio);
> +
> + if (!bank->dbck_flag)
> + return;
> +
> + if (!(bank->dbck_enable_mask & gpio_bit))
> + return;
> +
> + bank->dbck_enable_mask &= ~gpio_bit;
> + bank->context.debounce_en &= ~gpio_bit;
> + __raw_writel(bank->context.debounce_en,
> + bank->base + bank->regs->debounce_en);
> +
> + if (!bank->dbck_enable_mask) {
> + bank->context.debounce = 0;
> + __raw_writel(bank->context.debounce, bank->base +
> + bank->regs->debounce);
> + clk_disable(bank->dbck);
> + bank->dbck_enabled = false;
> + }
> +}
> +
> static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
> unsigned trigger)
> {
> @@ -539,6 +573,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
> _set_gpio_irqenable(bank, gpio, 0);
> _clear_gpio_irqstatus(bank, gpio);
> _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
> + _clear_gpio_debounce(bank, gpio);
> }
>
> /* Use disable_irq_wake() and enable_irq_wake() functions from drivers */
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox