On Wednesday, October 02, 2013 2:13 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:

Summary
=======

Fix IRQ Domain DT support issues and gpio IRQ

...

Jean-Christophe,

Given objections raised on the list, and my preference for easy submission
to the elinux wiki, can you re-submit this proposal with the following changes:

1) please use the format specified in the template at:
http://elinux.org/CEWG_Open_Project_Proposal_template

2) please fill in the Scope and Contractor Candidates sections
with your own wording.

This should not take too long.

Thanks,
-- Tim

Ezequiel,

Thanks for this proposal also. Here is a link to the proposal on the wiki:
http://elinux.org/Implement_scatter-gather_lists_support_in_UBI_and_UBIFS

-- Tim

On Tuesday, October 01, 2013 4:19 PM, Ezequiel Garcia wrote:

Improve UBI user space tools

...

Thanks for this proposal. I've saved it on the wiki at:
http://elinux.org/Improve_UBI_user_space_tools

-- Tim

Eeks, these are my text-blocks. This is weak. Tim, I think we should
remove the "share-alike" from proposals? I mean, if the topic is of real
importance, one can easily invest a bit of time for those two
paragraphs.

yeah I like the english so I re-use it if you do not mind

I do mind. I would have not if you had a) asked beforehand or b) gave
correct attribution according to the license.

On 11:55 Wed 02 Oct , Wolfram Sang wrote:

Scope
=====

I think the main ideas can be discussed and implemented in 240 hours effort.
If the duration is 3 or 5 months depends on how discussions with upstream go.


Contractor candidates
=====================

Given that I already started digging into the topic, have some designs sketched
and already submitted initial patches, I recommend myself. I also think I have
enough upstream experience to deal with such a major task.

Eeks, these are my text-blocks. This is weak. Tim, I think we should
remove the "share-alike" from proposals? I mean, if the topic is of real
importance, one can easily invest a bit of time for those two
paragraphs.

yeah I like the english so I re-use it if you do not mind

And as a sidenote, it doesn't fit well. Since Jean dropped the "Related
work" section, there is no proof about digging into the topic and
sketching some designs.

sorry patch on the device-tree ML

http://permalink.gmane.org/gmane.linux.drivers.devicetree/36679

Those topic was discussed with Grant and LinusW in Cc

Best Regards,
J.

Wolfram

Tim, I think we should remove the "share-alike" from proposals?

I mean "remove the remix". I'd suggest CC BY-ND for proposals.

Scope
=====

I think the main ideas can be discussed and implemented in 240 hours effort.
If the duration is 3 or 5 months depends on how discussions with upstream go.


Contractor candidates
=====================

Given that I already started digging into the topic, have some designs sketched
and already submitted initial patches, I recommend myself. I also think I have
enough upstream experience to deal with such a major task.

Eeks, these are my text-blocks. This is weak. Tim, I think we should
remove the "share-alike" from proposals? I mean, if the topic is of real
importance, one can easily invest a bit of time for those two
paragraphs.

And as a sidenote, it doesn't fit well. Since Jean dropped the "Related
work" section, there is no proof about digging into the topic and
sketching some designs.

Wolfram

Hi,

Summary
=======

Fix IRQ Domain DT support issues and gpio IRQ

Proposer
========

Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...>

Description
===========

Today the kernel have multiple issues arround the IRQ

* IRQ Domain platfrom driver support

Today if you register an irq domain via a platform driver and then use the irq
in DT such as this

eth0: ethernet@30000000 {
compatible = "micrel,ks8851-mll";
reg = <0x30000000 0x1
0x30000002 0xff>;
interrupt-parent = <&pioD>;
interrupts = <21 IRQ_TYPE_EDGE_BOTH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_board_eth0>;
status = "okay";
};

the irq in the platform resource will not be fill as the resolve is done at of_platform_populate
To fix this we need to resolve the irq at driver probe time.

* Multiple interrupt-parent support

Today if you need the irq from 2 interrupt controler it's impossible.
Such as a hw irq and a GPIO irq both provided via dt

To fix this implement a new property "interrupt-lines"

that will work in a same way as gpios by providing firt the phandle of the controller
and then the cell data

interrupt-lines = <&aic 0 4 0 & pioD 21 IRQ_TYPE_EDGE_BOTH>;

* gpio irq DT

Today you need to use a gpio as IRQ you need to configure it and then use it
As a in the kernel we make the disctinction between standard IRQ and gpio IRQ.
This should have never been the case and need to be fix up widely.
By droping all the gpio_to_irq in the drivers and ONLY provide interrupts

Scope
=====

I think the main ideas can be discussed and implemented in 240 hours effort.
If the duration is 3 or 5 months depends on how discussions with upstream go.


Contractor candidates
=====================

Given that I already started digging into the topic, have some designs sketched
and already submitted initial patches, I recommend myself. I also think I have
enough upstream experience to deal with such a major task.

Best Regards,
J.
_______________________________________________
Celinux-dev mailing list
Celinux-dev@...
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev

_______________________________________________
Celinux-dev mailing list
Celinux-dev@...
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev

Hi all,

This was originally suggested by Artem Bityutskiy; so I'm just putting
up a proposal
by digging his own words from old mails and public discussions.

Once again, apologies for the late submission.
---
Implement scatter-gather lists support in UBI and UBIFS

; Summary: Implement scatter-gather lists support in UBI and UBIFS

; Proposer: Ezequiel García <ezequiel@...>

== Description ==
Currently UBI and UBIFS seem to allocate a lot vmalloced LEB-sized buffers
on mount time. The reason for this is to "reserve" such memory and prevent
the big allocations from failing at a later point.

This heavily affects the memory footprint in systems using UBIFS.

A possible solution is to implement scatter-gather lists support in UBI
and UBIFS and replace the big (LEB-sized) vmallocations by smaller
allocations.

While this is a big effort and will only benefit UBIFS, it is expected that
it will help reduce the memory usage in such systems.

In addition, it has the added benefit of addressing another problem.
Some ARM platforms don't support DMA on vmalloc'ed buffers;
using scatter-gather lists the allocated will be quite smaller -O(page)-,
and it will be possible to allocate them on physically contiguous memory
(DMA capable).

These are recurrent issues [1, 2, 3] in the UBI mailing list, and it's
UBI maintainer's
suggested proposal [4].

== Related work ==
As Linus Walleij pointed out [5] the MMC subsystem already implements something
along this lines, and so this work might start by looking at that.

== Scope ==
Unknown.

== Contractor Candidates ==
None yet.

[1] http://lists.infradead.org/pipermail/linux-mtd/2009-August/026817.html
[2] http://lists.infradead.org/pipermail/linux-mtd/2012-November/044982.html
[3] http://lists.infradead.org/pipermail/linux-mtd/2012-October/044586.html
[4] http://lists.infradead.org/pipermail/linux-mtd/2012-November/045140.html
[5] http://lists.infradead.org/pipermail/linux-mtd/2012-October/044608.html

[[Category:Project proposals 2013]]

--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Hi all,

Here's a proposal I've been thinking while working with UBI and finding myself
cursing too often.

Apologies for the late submission.

---
Improve UBI user space tools

; Summary: Improve UBI userspace tools

; Proposer: Ezequiel García <ezequiel@...>

== Description ==
Currently the UBI tools are a bit messy and not straight-forward to use.
In addition, there are quite a few different -yet related- commands to
accomplish different stages of an UBI/UBIFS preparation or flashing.

A possible way of dealing with such complexity would be revisiting
these tools and introduce a new centralized tool (git-like), with sub-commands
for the different tasks.

The benefit of this effort is obviously to simplify the (exceedingly)
complicated
task of dealing with UBI and UBI volumes setup, both off-box and
in-box (presumably
for developers testings).

For instance, the ubinize tool requires the setup of an 'ini' file specifying
the volumes configuration, which is usually a bit annoying.

== Related work ==
I'm not aware of any

== Scope ==
A first working proposal of the centralized tool could be complete
in 4 weeks. This work should be done as close to upstream as possible
to come up with something useful to regular UBI users.

== Contractor Candidates ==
None yet.

[[Category:Project proposals 2013]]

--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Tim,

Great proposal! I'm glad to see this, as I think it addresses an important
area of work and enablement in the kernel.

Glad you like it!

I wish you had used the template, though. :-)

Sorry about that and thanks for fixing it up :)

Wolfram

Wolfram,

Great proposal! I'm glad to see this, as I think it addresses an important
area of work and enablement in the kernel.

I wish you had used the template, though. :-)

I've put the proposal on the wiki at:
http://elinux.org/Improve_devm_*_and_get_rid_of_boilerplate_code
-- Tim

Summary
=======

Clean up, consolidate and improve the managed devices of the Linux kernel
(devm_* functions) and make their usage more consistent. That also enables to
remove boilerplate code and strings in drivers.


Proposer
========

Wolfram Sang <wsa@...>


Description
===========

Managed devices have a great potential to make writing device drivers easier
and less error prone. The basic mechanisms are there, yet using these
mechanisms has gone a bit wild and there is no maintainer to keep an eye on it.
This project aims to improve the situation by:

* Fix the callers

Fix the kernel tree to clearly represent the best-practices in using devm functions.
This will usually remove code from the kernel.

* Cleaning up

Remove superfluous or too shim devm-functions to have a well-known basic set of
functions. This will remove code from the kernel.

* Consolidate

On top of these functions, add convenience functions which combine typical
procedures into seperate functions. An already existing example is
devm_ioremap_resource() which does devm_request_mem_region() and
devm_ioremap{_nocache} with proper error checking and giving proper error
messages. This will remove code and *lots* of inconsistent error strings from
the kernel. Also, most devm functions themselves use a similar pattern.
Refactoring might be worth in that area, too.

* Remove subtle issues

There are some devm functions missing. So for some subsystems, resource
allocation is additionally done by hand. This can cause subtle bugs, especially
in exit paths, since manually allocated resources might be not available
anymore when devm allocated resource would still need them. Adding those
functions will get things right. Also, the already existing action mechanism
might be used to do things on removal which are otherwise often forgotten.


The huge bonus of such a cleaned up devm interface is that devices drivers will
be smaller in size, easier to write, and less error-prone since typical
patterns are outsourced to a trusted mechanism. And maintainers will spend less
time reviewing because resource allocation is a neverending source of mistakes.


Related work
============

First steps have already been done:

Remove unneded checks with devm_ioremap_resource:
http://article.gmane.org/gmane.linux.drivers.driver-project.devel/38106

And bugs are found on the way, too:

Fixing wrong devres allocation in the PWM subsystem:
http://lkml.org/lkml/2013/6/3/589

Fixing up wrong devm-conversions:
http://thread.gmane.org/gmane.linux.kernel/1495010

Cleaning up copy&paste mistake in the GPIO subsystem:
http://lkml.org/lkml/2013/6/4/436

Scope
=====

I think the main ideas can be discussed and implemented in 120 hours effort.
If the duration is 1 or 2 months depends on how discussions with upstream go.


Contractor candidates
=====================

Given that I already started digging into the topic, have some designs sketched
and already submitted initial patches, I recommend myself. I also think I have
enough upstream experience to deal with such a major task.

Hi,

Yesterday, I've uploaded last Japan Jamboree videos to YouTube and
placed the links from the wiki page. Tim's presentation was performed in
English so that it will especially useful for out of Japan developers, too.

http://elinux.org/Japan_Technical_Jamboree_46


Sorry for my late action.



Best,
S. Ueda

(2013/09/06 12:34), Satoru Ueda wrote:

--
| TEL: +81-(0)50-3750-3882 FAX: +81-(0)50-3750-6620
| Strategic Alliance Sec.
| S&T Technology Promotion Dept, Software Design Group, Sony Corp.

Dear Atilla Filiz,

On Tue, 17 Sep 2013 17:08:11 +0200, Atilla Filiz wrote:

Generic upgrade infrastructure for embedded systems.

; Summary: Generic upgrade infrastructure for embedded systems.

; Proposer: Atilla Filiz, Arnout Vandecappelle

== Description ==

Experience as an embedded software contractor shows that most clients
need a means to upgrade their devices in the field. Often these
solutions are ad-hoc, and need to be redone for each project,
although requirements are similar.

A collection of scripts and permissively licensed source code will help
device manufacturers to rapidly and safely implement a secure,
fail-safe,
atomic upgrade system for their devices.

The infrastructure will allow an embedded system to have one backup
firmware, and one or two main firmware partitions. When a new firmware
is downloaded and written as a main firmware, the upgrade system makes
sure
the device can boot. If the upgrade fails due to power, file corruption
or
other factors, the system recovers by booting the previous firmware or
a
failsafe firmware to retry upgrading.

Having this feature will prevent reinventing the wheel for each new
product when it comes to upgrading.

Interesting, thanks. I was also pondering proposing a project around
system upgrade for embedded systems, but I was thinking of a different
approach. Rather than implementing yet another tool/infrastructure, I
wanted to propose a project that consists in writing a
document/white-paper that details the different system upgrades
solutions that one can use (for example: dual kernel+rootfs partitions,
or minimal kernel+initramfs, updating from the bootloader or from
Linux, full system update vs. package based updates), with details on
their respective advantages/drawbacks, and how to implement them.

I believe the problem in this space is not the much the solutions
themselves, but rather the lack of a central document to help people
make their mind between the different available solutions, and to help
them find the relevant existing tools / bits of code. I don't think
it's a problem that can be solved in a one-solution-fits-all way,
depending on the context (size of flash, type of embedded system,
origin of the firmware upgrades, etc.) there will necessarily be
different solutions.

Best regards,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Device-tree documentation project

; Summary: Device-tree documentation project

; Proposer: Tim Bird, Sony Mobile

== Description ==
The [[Device Tree]] is a relatively new (for ARM Linux) framework
for specifying the hardware configuration of a board to the Linux Kernel.
New device drivers for many embedded products are always being
produced, and it is strongly encouraged that new drivers
and the board support for new ARM boards use device tree as part
of their driver configuration. However, some areas of the device
tree bindings are non-uniform and not well-documented.

This project would consist of documenting aspects of the device
tree system that would be useful for:
* board support developers (board/platform developers)
* device driver developers
* kernel sub-system maintainers

Kernel sub-system maintainers would be well-served by a document
describing "rules", guidelines and best practices for device
tree bindings.

Many documents exist which describe the syntax of the device tree,
(such as the epar document, the device-tree wiki and the usage
document in the kernel Documentation directory). However, some
details are missing from these documents, and in some cases the
explicit practices for working with device tree in the Linux
kernel are different or have evolved from when these original
documents were written.

The output from this effort would be a readily-accessible document.
It would probably make sense to put the document in the kernel source
tree, under Documentation/devicetree. Failing that, the document
could be placed on the elinux wiki or the device tree wiki.

== Issues ==
Some areas of device tree bindings (and driver infrastructure) are
in flux (e.g. pinctrl, dma). Would it be better to wait until
these areas have settled down?

Does throwing money at this project dis-incent volunteer effort?

== Related work ==
* http://devicetree.org/Device_Tree_Usage - this is part of the device tree wiki
* http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf - open-firmware device tree specification
** This requires registration? :-(
* Some 2013 kernel summit discussion entries:
** http://lists.linuxfoundation.org/pipermail/ksummit-2013-discuss/2013-July/000127.html
*** Jonathan Corbet asks about the need for discussion and/or a document on device tree
** http://lists.linuxfoundation.org/pipermail/ksummit-2013-discuss/2013-July/000129.html
*** Greg KH would like a document
** http://lists.linuxfoundation.org/pipermail/ksummit-2013-discuss/2013-July/000599.html
*** Stephen Warren recommends a reviewer's checklist for new bindings

== Some questions to answer ==
Here are some possible questions that this documentation could
address: (If these are already answered by the epar document, please
cite the section:)

1. What is a phandle? How is it used? What rules are there for
defining them? For referencing them?

2. How are #foo-cells used?

3. What are the rules for naming attributes? when should vendor
qualifiers be used and when not?

4. How does device-tree interact with device instantiation - when
is the device node created?, who creates it, when is the initcall
called? when is the probe function called?

5. How does device-tree interact with platform/bus instantiation?
Do buses instantiate their children device nodes, or does the probe
routine do this?

6. what is the kernel API for interacting with device-tree? What
things are parsed automatically, vs. require manual (coded) parsing?

== Scope ==
A rough guess of the amount of work required for this document is
approximately 3 months (12 person-weeks).

== Contractor Candidates ==
* Jonathan Corbet (output could also be part of LDD4??)
* Thomas Petazzoni - is presenting a tutorial on device tree at ELCE
* one of the device-tree maintainers? (Grant, Stephen, Mark, etc.)

== Comments ==

[[Category:Project proposals 2013]]

On Tuesday, September 17, 2013 8:08 AM Atilla Filiz [Atilla.Filiz@...] wrote:

Generic upgrade infrastructure for embedded systems.

Thanks. This is an interesting project, which I've added to the wiki at:
http://elinux.org/Generic_upgrade_infrastructure_for_embedded_systems

I'll also try to add commentary from the e-mail discussion to that page as well.
So anyone who has feedback or insights into this project, please feel free
to discuss them on this list.
-- Tim

On 17:08 Tue 17 Sep , Atilla Filiz wrote:

Generic upgrade infrastructure for embedded systems.

; Summary: Generic upgrade infrastructure for embedded systems.

; Proposer: Atilla Filiz, Arnout Vandecappelle

== Description ==

Experience as an embedded software contractor shows that most clients
need a means to upgrade their devices in the field. Often these
solutions are ad-hoc, and need to be redone for each project,
although requirements are similar.

A collection of scripts and permissively licensed source code will help
device manufacturers to rapidly and safely implement a secure,
fail-safe,
atomic upgrade system for their devices.

The infrastructure will allow an embedded system to have one backup
firmware, and one or two main firmware partitions. When a new firmware
is downloaded and written as a main firmware, the upgrade system makes
sure
the device can boot. If the upgrade fails due to power, file corruption
or
other factors, the system recovers by booting the previous firmware or
a
failsafe firmware to retry upgrading.

Having this feature will prevent reinventing the wheel for each new
product when it comes to upgrading.

== Related work ==
* FOSDEM/ELC-E Presentation:
http://mind.be/content/Presentation_Upgrade-without-Bricking.pdf
* Generic project repository with detailed documentation:
https://gitorious.org/gupies
* CGI based project repository:
https://gitorious.org/embedded-linux-firmware-upgrade-tool

== Scope ==
A basic system can be implemented and unit tested in six person-weeks.
This includes support
for a single bootloader (U-Boot), for overwriting an MTD partition and a
UBI volume. This also
includes a wire format for the upgrade image and documentation for the
platform-specific part,
needed per project. Additional partition types (e.g. mbr) or bootloaders
(e.g. barebox) require
additional effort.

we are currently working on such project with a full c application under GPLv2
call linupdate + barebox

that will support secure boot platform too such as STB

Best Regards,
J.

== Contractor Candidates ==
Arnout Vandecappelle (Essensium/Mind)

== Comments ==


[[Category:Project proposals 2013]]



_______________________________________________
Celinux-dev mailing list
Celinux-dev@...
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev

Hi,

On Tue, Sep 17, 2013 at 05:08:11PM +0200, Atilla Filiz wrote:

Generic upgrade infrastructure for embedded systems.

Will you be at ELC-E? Sascha has a barebox talk there:
http://embeddedlinuxconferenceeu2013.sched.org/event/d7296221f5c9c177a2f84f5da58ece9b#.Ujh1HR_Yo7Y
System updating is an important feature for us as well. The bootloader
spec work outlined in this talk is basically about redundancy boot and
system updating in a more systematic and "embedded-is-not-(that)-
special" way.

rsc
--
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-5555 |