== Linus Walleij linusw ==
=== Highlights ===
* Intense activity on pinctrl and gpio trees, also sending
yet another round of pull requests for fixes to Torvalds
for GPIO.
* Switched the U300 over to use the GPIO ranges.
Discovered more issues with the solution and solved
them with another 10 patches to the related code and
drivers.
https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-gpiorange-makeo…
* Finalized my GPIO patch stack and sent of a pull
request to Grant so he can funnel this to Torvalds for
kernel v3.8.
* Discussed the status of the CW1200 driver in a lot of
private mails.
* Acked a plethora of patches for the removal of __devinit
* Send clock patches for the Integrator/IM-PD1 to Mike
Turquette, he merged them.
=== Plans ===
* Attack the remaining headers in arch/arm/mach-ux500
so we can move forward with multiplatform for v3.9
or so. (Make no promises, make no commitments...)
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Look into other Ux500 stuff in need of mainlining...
using an internal tracking sheet for this.
* Look into regmap. Try something out, get to know it.
=== Issues ===
* The GPIO range blueprint got escalated above the
single zImage work due to influx from the community.
Since contribuitors drive the process this happens...
It was work that was on our blueprint list, but we could
not control the priority of execution. I think this is
normal but it needs to be reported and noted.
Thanks,
Linus Walleij
Hi Andrew, Jason,
And yet another set that folks seem to be too busy to look into. :)
The rationale for the series is this:
This patchset implements "kiosk" mode for KDB debugger. The mode reduces
kdb features, so that it is no longer possible to leak sensitive data via
the debugger, and not possible to change program flow in a predefined
manner by an ordinary user. The root can control the capability.
It is useful on phones with an easy access to a debugger console (e.g.
thru a headphone mini-jack), or on a public PCs (but we still want to let
the user somewhat diagnose the problem via KDB-via-KMS).
Later we might want to implement password-protected "unlock" command (with
the hash of the password passed via some sysfs attribute).
There are a few patches, some are just cleanups, some are churn-ish
cleanups, but inevitable. And the rest implements the mode -- after all
the preparations, everything is pretty straightforward.
Thanks!
Anton.
--
include/linux/kdb.h | 20 ++--
kernel/debug/kdb/kdb_bp.c | 24 ++---
kernel/debug/kdb/kdb_main.c | 189 +++++++++++++++++----------------
kernel/debug/kdb/kdb_private.h | 3 +-
kernel/trace/trace_kdb.c | 4 +-
5 files changed, 125 insertions(+), 115 deletions(-)
Items of public interest from 1:1 protocol...
On Mon, Nov 19, 2012 at 9:22 PM, Deepak Saxena <dsaxena(a)linaro.org> wrote:
> On 19 November 2012 02:03, Linus Walleij <linus.walleij(a)linaro.org> wrote:
>> * Intense activity on pinctrl and gpio trees, also sending
>> a second round of pull requests for fixes to Torvalds
>> for GPIO.
>
> Is this work beyond what's in the two BPs below? If not, can you
> create BPs for sort of random maintenance work that comes up and just
> throw things on there as they come up? We're still trying to sort out
> the best way to use the BPs but there's a lot of pressure to make sure
> that we have good tracking of all the work we're doing.
So this has basically been just collecting patches that people
send on the mailing list, ask a question, git commit --amend
to add an ACK, push -next branches etc to the git servers
etc. It adds up.
I don't know how to properly encode that into a blueprint
without the detailing taking more time than the actual
work, shall I create a blueprint named "pinctrl maintenance"
and "gpio maintenance" and just push in weekly TODO items
there with titles like "monitor mailing list", "extract patches",
"apply patches", "push branches", "read Rothwells merge log",
etc?
>> * Sent a patch set to move the Integrators over to the SoC
>> bus (Lee's invention) when booting from device tree,
>> and at the same time find a natural place to define
>> system controller registers. This is meant as a good
>> example of how to use the SoC bus.
>
> -EANOTHERBUS? How does the SoC bus compare to the newly proposed
> Capebus. What does it offer that is not already in the platform bus?
I'm not familiar with the Capebus... This one was discussed
between Lee, Greg and Arnd and they agreed that this was the
way to create a container for all the peripherals on an SoC.
> PPC went down the path of having an "Off-Chip Peripheral Bus" to
> describe devices and then threw it all away a few years ago, so
> wondering how this compares.
So this is an on-chip peripheral bus. It will group typically
AMBA (PrimeCell) and platform devices that sit in the same
die.
Check commit:
74d1d82cdaaec727f5072eb1c9f49b7e920e076f
Yours,
Linus Walleij
hi all,
Now when i debug the Linux kernel on Fast Model (A15x1+A7x1), i found
the generic timer's frequency cannot work properly.
In the boot-wrapper, it has set the frequency as 24MHz; and i also use
the modeldebugger to confirm it has been set successfully. But after the
linux kernel bootup, i saw the counter register increased quicker than
24MHz, so that the kernel cannot get the correct timestamp.
I'm not sure it's a issue originally come from the model? Or i miss
something. There have method to fix this issue? Any suggestion will be
appreciate.
--
Thx,
Leo Yan
== Linus Walleij linusw ==
=== Highlights ===
* Intense activity on pinctrl and gpio trees, also sending
a second round of pull requests for fixes to Torvalds
for GPIO.
* Debated default-hogging of pinctrl handles. We
NACKed the idea to use notifications to obtain hogs
as it can't handle deferred probes properly, instead
we will attempt to push this to the device driver core.
https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-notifyhog
* Probably finished the GPIO-range blueprint work, but
need to switch the U300 over to this mechanism as
a trial platform:
https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-gpiorange-makeo…
* Sent a patch set to move the Integrators over to the SoC
bus (Lee's invention) when booting from device tree,
and at the same time find a natural place to define
system controller registers. This is meant as a good
example of how to use the SoC bus.
* Had a final look at Synaptic's RMI4 patch set, I've reviewed
all that I can, now it remains for Dmitry and Greg to
review the final pieces of the architecture.
* Initial Integrator/IM-PD1 patches being cooked.
=== Plans ===
* Attack the remaining headers in arch/arm/mach-ux500
so we can move forward with multiplatform for v3.9
or so. (Make no promises, make no commitments...)
* Test the PL08x patches on the Ericsson Research
PB11MPCore and submit platform data for using
pl08x DMA on that platform.
* Look into other Ux500 stuff in need of mainlining...
using an internal tracking sheet for this.
* Look into regmap. Try something out, get to know it.
=== Issues ===
* N/A
Thanks,
Linus Walleij
=== Highlights ===
* KVM/ARM VGIC state saving and restoring implementation.
1) read the full software emulated gic code hw/arm_gic.c to understand
the original gic_state using
2) started to define the standard ABI of gic state for user space to use.
The work consists of two part: kernel vgic part and user level qemu
part.
I would firstly complete kernel vgic part.
During the process, mainly two problems met:
Firstly, unlike kvm_pic_state of x86, the gic_state, mainly used by
fully
sw emulated gic in hw/arm_gic.c, is not used by kernel vgic code and
most
of its members are also not used by hw assisted hw/kvm/arm_gic.c code,
i probably need define a new standard gic state structure interface in
kvm_irqchip for qemu to use, may be named kvm_gic_state.
Secondly, currently i only know to the test method via savevm on a
single
virtual machine, this is the first target. In the future, we may
support multi
targets.
Will keep going as this and send patch first.
* Reviewed a few imx pinctrl patches
* Invovled with a few FSL internal meetings on the i.MX changes.
==== Activity Summary ====
- Implemented review comments from Francesco, waiting for ack.
- Pinged Rob for review comments and ack
- Rebasing ab8500-dt patch set to 3.7-rc5
- Discussion with Arnd on my new blueprint: "impact on kernel size for
multi-platform configs"
Thanks arnd for his useful inputs
- Updated in my Blue Print with the detailed work items
==== Plan ====
- Rebase (manually) ab8500 DT patch and test
- Review and rework on the work items details and proceed accordingly
==== Issues ====
2 days holiday
=== Highlights ===
* Mostly caught up from paternity leave
* Queued a few timekeeping patches for 3.8
* Discussed need for CLOCK_PERF and possible clock_gettime2() interfaces
on lkml
* Reviewed patches that allow for vdso pvclock.
* Took a quick look at the ashmem/binder fixes for 64bit
* Started testing and reviewing Minchan's madvise volatile patch
* Sent out Android upstreaming weekly email
=== Plans ===
* Continue playing with Minchans madvise volatile patch, trying to see
how to best integrate my needs with it.
* Try to get a closer review of the ashmem/binder 64bit fixes
=== Issues ===
* NA
