From: Linus Walleij <linus.walleij(a)linaro.org>
Machines that have embedded pin controllers need to select them
explicitly, so why broadcast their config options to menuconfig.
We provide a helpful submenu for those machines that do select
it, making it possible to enable debugging for example.
Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
---
ChangeLog v1->v2:
- Removed some more pointless help text
---
drivers/pinctrl/Kconfig | 22 +++++++---------------
1 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ef56644..e17e2f8 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -2,23 +2,17 @@
# PINCTRL infrastructure and drivers
#
-menuconfig PINCTRL
- bool "PINCTRL Support"
+config PINCTRL
+ bool
depends on EXPERIMENTAL
- help
- This enables the PINCTRL subsystem for controlling pins
- on chip packages, for example multiplexing pins on primarily
- PGA and BGA packages for systems on chip.
-
- If unsure, say N.
if PINCTRL
+menu "Pin controllers"
+ depends on PINCTRL
+
config PINMUX
bool "Support pinmux controllers"
- help
- Say Y here if you want the pincontrol subsystem to handle pin
- multiplexing drivers.
config DEBUG_PINCTRL
bool "Debug PINCTRL calls"
@@ -30,14 +24,12 @@ config PINMUX_SIRF
bool "CSR SiRFprimaII pinmux driver"
depends on ARCH_PRIMA2
select PINMUX
- help
- Say Y here to enable the SiRFprimaII pinmux driver
config PINMUX_U300
bool "U300 pinmux driver"
depends on ARCH_U300
select PINMUX
- help
- Say Y here to enable the U300 pinmux driver
+
+endmenu
endif
--
1.7.3.2
Hi,
I'm trying to make a SIP stack run on a low-end processor (720 MIPS capable). Problem is the stack's EC is not neon-optimized & with a 256 ms EC tail, I'm exhausting the CPU.
On one of the forums, I came across neon optimization trials for speex AEC by Linaro. Has there been a completed project? Or any other that can help me?
Thank you for answering.
Regards,
Sangram
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
From: Linus Walleij <linus.walleij(a)linaro.org>
Machines that have embedded pin controllers need to select them
explicitly, so why broadcast their config options to menuconfig.
We provide a helpful submenu for those machines that do select
it, making it possible to enable debugging for example.
Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
---
drivers/pinctrl/Kconfig | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ef56644..e816f60 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -2,18 +2,15 @@
# PINCTRL infrastructure and drivers
#
-menuconfig PINCTRL
- bool "PINCTRL Support"
+config PINCTRL
+ bool
depends on EXPERIMENTAL
- help
- This enables the PINCTRL subsystem for controlling pins
- on chip packages, for example multiplexing pins on primarily
- PGA and BGA packages for systems on chip.
-
- If unsure, say N.
if PINCTRL
+menu "Pin controllers"
+ depends on PINCTRL
+
config PINMUX
bool "Support pinmux controllers"
help
@@ -40,4 +37,6 @@ config PINMUX_U300
help
Say Y here to enable the U300 pinmux driver
+endmenu
+
endif
--
1.7.3.2
Hi Michael,
I went to take a look at the kernel ci-loop page to see the build
status of upstream builds and have a few new comments on
the UIL
1) When there is a build failure, is it possible to have
the build link go directly to the build results?
It currently takes 3 clicks to get to the results
from the main page and it may not be obvious to
someone that the "consoleText" attachment
is the correct link to use.
2) From the main ci-loop page, how do I get to
a link for the RSS feed? Are the RSS feeds
per-tree or per (tree + defconfig) combination?
The later is preferred from the perspective of
having upstream sub-arch maintainers who
want to watch specific platforms.
Thanks,
~Deepak
Hi,
For a better performance in USB charging operation, the DA9052/53 charging
current can be configured in accordance with the USB host current
delivering capacity (known through USB drivers negotiation).
To implement this useful feature, a new writable property "USB charge current"
needs to be added in the Linux battery core.
Let me know your views on it.
Regards,
Ashish
Hello,
Based on the discussions and decisions made at the Linaro Connect Q4.11,
Infrastructure team is pleased to announce changes in the process of
Linaro Android Infrastructure planning and maintenance. The main
audience of the new process is Linaro Android Team, which is the primary
stakeholder of the Android infrastructure, but it also applies to other
groups and individuals in Linaro, as well as external contributors and
community.
The basic idea is to make Android infrastructure planning and
management more sustainable, as well as improve the Infrastructure Team
internal processes which will allow entire team to handle Android
infrastructure tasks and improve cross-team work and knowledge sharing.
The new process is as follows:
1. There's a new Linaro Android Infrastructure project at Launchpad,
https://launchpad.net/linaro-android-infrastructure/ , which is
intended to be a central facade for Android infrastructure development
and maintenance.
2. The bugtracker in that project,
https://bugs.launchpad.net/linaro-android-infrastructure is intended as
a single contact point to report Android infrastructure issues, so
please bookmark it and keep it handy. This ticket queue replaces all
older communication means, like direct email, IRC pings, etc. (that
doesn't mean they can't be used, it means that any issue should be
reported as a ticket nonetheless). The bugtracker is indeed conceived
to be a single point of contact, and if a ticket requires recursing to
Linaro IS team, that will be handled by Infrastructure team itself.
Using the "bug also affects project" Launchpad feature, tickets can be
easily cross-posted to other projects which are affected.
3. The blueprints area in that project,
https://blueprints.launchpad.net/linaro-android-infrastructure is used
to host all blueprints related to Android infrastructure. That may
change in the future (i.e. they will be filed against individual
projects), but so far it's good step forward from such bluprints being
filed against linaro-android project, which caused scheduling and
accounting issues for both Android and Infrastructure teams.
4. The usual rules of thumb are applied to blueprints and tickets:
Blueprints represent work to develop new (sub)systems or add
non-trivial functionality to existing systems. They can be filed at any
time, but prioritized and scheduled for execution at the beginning of
monthly milestones. Tickets represent issues reports and requests to
make changes which only Infra team can do, other maintenance requests,
and feature requests. Tickets which turn out to require substantial
effort, may be converted to blueprints.
5. For the time being, the Infrastructure team commits to working on
1-2 Android infrastructure blueprints each milestone, with more time
spent on maintenance (including documentation and testsuites) of
existing systems. Following the process above will allow us to optimize
and improve our workflow, and provide more resources to Android
infrastructure work, if that proves to be required.
Thanks,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
I've got a pthread test that is the fall out of a bug fix which is a good test
of kernel and libc and would like to add it into Lava.
I'm told that I currently have to pick a hardware pack and image - but for
this case what I really want to do is to create a test that can be used
as a regression test that gets run on whatever the latest kernel is on
any of a set of platforms (basically anything of Panda speed or similar/faster).
mwhudson suggested I posted that requirement here.
Thoughts?
Dave