s3c24xx_i2c_parse_dt_gpio is called when cfg_gpio is not defined
in the platform data of the i2c device. When DT is not enabled,
the above function always returns -EINVAL. Since there can be
some i2c devices which don't need to configure any gpio lines,
the probe of such devices would fail here. Changing the default
return value to success would fix this issue.
Signed-off-by: Tushar Behera <tushar.behera(a)linaro.org>
---
This patch is rebased on Kukjin's for-next branch.
d3d936c "Merge branch 'samsung-fixes-2' into for-next"
drivers/i2c/busses/i2c-s3c2410.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 2754cef..b5caa42 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -786,7 +786,7 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
#else
static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c)
{
- return -EINVAL;
+ return 0;
}
static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
--
1.7.4.1
Konstantinos Margaritis wrote:
>> Does anyone know what the impact of renaming these to use a REG_ prefix like
>> i386, amd64 and sparc do* would be?
>>at worst the packages that had to be workaround on arm* for this, can
>have the workaround removed.
I have prepared a patch (attatched) that eliminates the dependency on
sys/procfs.h and renames R? to REG_R?. I have tested it by modifying the
header locally. I am now attempting to rebuild glibc with the patch.
After rebuilding glibc I will install it and attempt to rebuild GDB.
Please comment on the patch and advise on the best route for submission
(that is should I go through debian, through eglibc or direct to glibc?)
>Since you're in the process of fixing things for glibc/arm
Note that I am not a glibc developer nor am I a dd (and even if I was a
dd I don't think I would NMU glibc). I'm just a user with an interest
in the future of debian on arm.
>would you
>mind also looking at WCHAR_MIN/MAX undefined for arm?
>
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598937
They most certainly are defined. The trouble is that WCHAR_MAX is defined
in a strange way.
#define __WCHAR_MAX ( (wchar_t) - 1 )
This definition is fine for normal c or c++ code but
it cannot be properly evaluated in the context of a
preprocessor conditional.
The bug report has a patch (actually a replacement for
an existing patch) which looks fine to me.
Ulrich Weigand>Now, glibc also provides a file <sys/ucontext.h> that defines
Ulrich Weigand>layouts of register sets for use with signal handlers as well
Ulrich Weigand>as the makecontext/setcontext/getcontext family of routines.
Ulrich Weigand>
Ulrich Weigand>Usually, those layouts tend to be in fact identical to the
Ulrich Weigand>layouts described in <sys/user.h> / <sys/procfs.h>. Apparently,
Ulrich Weigand>whoever implemented the ARM version of <sys/ucontext.h> was
Ulrich Weigand>trying to avoid some seemingly unnecessary code duplication
Ulrich Weigand>by making <sys/ucontext.h> *include* <sys/procfs.h> and using
Ulrich Weigand>the information from there directly. This is not done on other
Ulrich Weigand>platforms, for precisely the reason that the <sys/procfs.h>
Ulrich Weigand>and <sys/user.h> headers do pollute the name space ...
Ulrich Weigand>
Ulrich Weigand>So I think the right thing to do in the short term would be to
Ulrich Weigand>stop <sys/ucontext.h> including <sys/procfs.h>, and instead add the
Ulrich Weigand>register set information there directly, even if that means some
Ulrich Weigand>duplication of code. (Again, since this is never-changing ABI,
Ulrich Weigand>duplication isn't actually all that bad. Also, all the other
Ulrich Weigand>platforms do it that way too, so why should ARM be different ...)
Makes sense to me
While we are talking about modifying sys/ucontext.h David Given
raised another issue with that header (for those reading on the linaro list his
post can be found at http://lists.debian.org/debian-arm/2011/12/msg00048.html)
David Given>This might be a good time to mention that on ARM, sys/ucontext.h defines
David Given>both symbols and preprocessor macros called R0, R1, R2, etc in the
David Given>global namespace; this is causing one of my packages to fail to build
David Given>due to symbol collision.
David Given>
David Given>I'm fixing the package, but naming symbols stuff like that is still
David Given>pretty antisocial...
Does anyone know what the impact of renaming these to use a REG_ prefix like
i386, amd64 and sparc do* would be?
* ia64,mips, mipsel, powerpc, 390 and s390x don't seem to define such
symbols at all.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
while trying the linux-next at the point it boots (commit
be9b7335e70696bee731c152429b1737e42fe163, after v3.2-rc4), I noticed the
timers were not working properly with CONFIG_NO_HZ.
It is easy to reproduce with 'time sleep 1' where the timer expires 1, 2
or 3 seconds later.
It seems that does not happen with linux-linaro-3.1 but I was able to
reproduce the problem on a vanilla kernel 3.1.5.
Is it a known problem ?
Thanks
-- Daniel
- --
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJO6MBZAAoJEAKBbMCpUGYAUI4IAMOMK+90biBp+1tj/tY/A1is
FJEQXi1wzhLGo23gIh6D65dcLRsxr3TSdvcHGz2dzB1ZquaaUUJCv8vM909bCSF8
y3dH4WIzEF/rNPcyI2WgtjDq/KVcZK28in8XresC7yC0fEmEB6fHRvQoqBk5fhsb
jWPM8nGbyXJpBFK4yCZRgrz2TYsDInyazplHtGzABMj9j374Wk6yGAsDnCd6/XJM
dArM2IP4Mcd7Zv6m4kJ2vncTCnKR+D4wVTXdRrXTqAd8byfKBgyUHxY/cviXirHp
03nSKJYaw683YhdJ0JVQQJfdOEl+kaCDOkCEV5MUUiSCRors1Z8FcK+DAPAjG84=
=spxQ
-----END PGP SIGNATURE-----
Greetings with a friendly reminder.
* Linaro 11.12 Release Candidate is December 19, 2011.
* Linaro 11.12 Release images is December 22, 2011
(early due to Christmas holiday).
* Linaro 11.12 release is UTC 16:00, December 22, 2011.
The release team needs:
====================
* an up-to-date list of components to be delivered for this cycle.
* https://wiki.linaro.org/Cycles/1112/Release/Status
* all blueprints targeted for this cycle have a headline and
acceptance criteria.
* https://wiki.linaro.org/Cycles/1112/Release/Blueprints
* an up-to-date point of contact list for your team for the
release dates. If PoC for your team is the same as last
month please confirm.
* https://wiki.linaro.org/Cycles/1112/Release/PointOfContacts
--
David Zinman
Linaro Release Manager | Project Manager
Linaro.org | Open source software for ARM SoCs
Hi all!
The 2011.12 release marks glmark2's 10th major release!
Our OpenGL (ES) 2.0 graphics benchmark, glmark2, has been a central
component of the Linaro Graphics WG since the group's creation, and even
before that, when we still had a "User Platforms" team.
glmark2 has been improving steadily with each and every release. We have
seen it run on all kinds of devices: desktops, netbooks, development
boards, tablets and smartphones (sadly, no TVs or refrigerators yet). It
currently provides over 10 highly configurable benchmarking scenes, it
supports both (programmable) OpenGL and OpenGL ES 2.0 and runs on both
GNU/Linux and Android. In short, it is the most versatile Free Software
3D benchmarking application out there!
To celebrate this release, I have written a post/article about the
principles and goals that drive glmark2 development (and the Graphics
WG group in general). It should be visible soon in planet.linaro.org.
Enjoy!
Thanks,
Alexandros
From: Rajendra Nayak <rnayak(a)ti.com>
An hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hwmod framework throws a WARN() about
the device being already in enabled state.
Fix this by introducing a new internal flag '_HWMOD_SKIP_ENABLE' to
identify such devices/hwmods. When the device/hwmod is requested to be
enabled (the first time) by its driver/user, nothing except the
mux-enable is needed. The mux data is board specific and is
unavailable during initial enable() of the device, done by the
framework as part of setup().
A good example of a such a device is an UART used as debug console.
The UART module needs to be kept enabled through the boot, until the
UART driver takes control of it, for debug prints to appear on
the console.
Acked-by: Kevin Hilman <khilman(a)ti.com>
Acked-by: Benoit Cousson <b-cousson(a)ti.com>
Signed-off-by: Rajendra Nayak <rnayak(a)ti.com>
[paul(a)pwsan.com: use a flag rather than a state; updated commit message;
edited some documentation]
Signed-off-by: Paul Walmsley <paul(a)pwsan.com>
---
This patch needs to be applied along with Govindraj & Kevin's UART
patch set. Otherwise lots of nasty warnings are generated to the console
during boot. Applies on top of v3.2-rc5.
arch/arm/mach-omap2/omap_hwmod.c | 23 ++++++++++++++++++++++-
arch/arm/plat-omap/include/plat/omap_hwmod.h | 3 +++
2 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 529142a..f673f80 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1441,6 +1441,25 @@ static int _enable(struct omap_hwmod *oh)
pr_debug("omap_hwmod: %s: enabling\n", oh->name);
+ /*
+ * hwmods with HWMOD_INIT_NO_IDLE flag set are left
+ * in enabled state at init.
+ * Now that someone is really trying to enable them,
+ * just ensure that the hwmod mux is set.
+ */
+ if (oh->_int_flags & _HWMOD_SKIP_ENABLE) {
+ /*
+ * If the caller has mux data populated, do the mux'ing
+ * which wouldn't have been done as part of the _enable()
+ * done during setup.
+ */
+ if (oh->mux)
+ omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED);
+
+ oh->_int_flags &= ~_HWMOD_SKIP_ENABLE;
+ return 0;
+ }
+
if (oh->_state != _HWMOD_STATE_INITIALIZED &&
oh->_state != _HWMOD_STATE_IDLE &&
oh->_state != _HWMOD_STATE_DISABLED) {
@@ -1744,8 +1763,10 @@ static int _setup(struct omap_hwmod *oh, void *data)
* it should be set by the core code as a runtime flag during startup
*/
if ((oh->flags & HWMOD_INIT_NO_IDLE) &&
- (postsetup_state == _HWMOD_STATE_IDLE))
+ (postsetup_state == _HWMOD_STATE_IDLE)) {
+ oh->_int_flags |= _HWMOD_SKIP_ENABLE;
postsetup_state = _HWMOD_STATE_ENABLED;
+ }
if (postsetup_state == _HWMOD_STATE_IDLE)
_idle(oh);
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8b372ed..1a13c02 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -416,10 +416,13 @@ struct omap_hwmod_omap4_prcm {
* _HWMOD_NO_MPU_PORT: no path exists for the MPU to write to this module
* _HWMOD_WAKEUP_ENABLED: set when the omap_hwmod code has enabled ENAWAKEUP
* _HWMOD_SYSCONFIG_LOADED: set when the OCP_SYSCONFIG value has been cached
+ * _HWMOD_SKIP_ENABLE: set if hwmod enabled during init (HWMOD_INIT_NO_IDLE) -
+ * causes the first call to _enable() to only update the pinmux
*/
#define _HWMOD_NO_MPU_PORT (1 << 0)
#define _HWMOD_WAKEUP_ENABLED (1 << 1)
#define _HWMOD_SYSCONFIG_LOADED (1 << 2)
+#define _HWMOD_SKIP_ENABLE (1 << 3)
/*
* omap_hwmod._state definitions
--
1.7.7.3