From: Pavel Machek <pavel@ucw.cz>
To: Tomas Hlavacek <tmshlvck@gmail.com>
Cc: "Andrew Lunn" <andrew@lunn.ch>,
"Uwe Kleine-König" <uwe@kleine-koenig.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Russell King" <linux@armlinux.org.uk>,
"Jason Cooper" <jason@lakedaemon.net>,
"Gregory Clement" <gregory.clement@free-electrons.com>,
"Sebastian Hesselbarth" <sebastian.hesselbarth@gmail.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia
Date: Sat, 10 Dec 2016 09:16:04 +0100 [thread overview]
Message-ID: <20161210081604.GA8273@xo-6d-61-c0.localdomain> (raw)
In-Reply-To: <1480078151.381.4@smtp.gmail.com>
Hi!
> >Yes. That is fine. It is just unusual. Most boards have gpio-led and
> >gpio-keys, which are easy to add. That is why i asked. Adding an LED
> >driver which talks to this M0 can be added later.
>
> Actually the WiP driver for MCU LED interface, that we use in our
> kernel is here: https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb
>
> It definitely needs some cleanup and it adds non-standard features
> (main PWM for all LEDs, autonomous blink mode, colors) via custom
> /sys files, which I suspect that is not going to be acceptable for
> upstream. Let's keep it for the next iteration.
Actually, LEDs that can do PWM intensity on their own are common and
supported.
LEDs that can do PWM pretty advanced patterns are common in the cellphones,
as is the color. Unfortunately, good support in kernel is missing. It
would be good to change that.
In n900, I have a LED that can compute prime numbers then blink them,
autonomously. We probably don't need to support _that_, but common
support for patterns would be good.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
To: Tomas Hlavacek <tmshlvck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Andrew Lunn" <andrew-g2DYL2Zd6BY@public.gmane.org>,
"Uwe Kleine-König"
<uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>,
"Rob Herring" <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"Mark Rutland" <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"Russell King" <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
"Jason Cooper" <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
"Gregory Clement"
<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
"Sebastian Hesselbarth"
<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia
Date: Sat, 10 Dec 2016 09:16:04 +0100 [thread overview]
Message-ID: <20161210081604.GA8273@xo-6d-61-c0.localdomain> (raw)
In-Reply-To: <1480078151.381.4-TAvD023jEQEN+BqQ9rBEUg@public.gmane.org>
Hi!
> >Yes. That is fine. It is just unusual. Most boards have gpio-led and
> >gpio-keys, which are easy to add. That is why i asked. Adding an LED
> >driver which talks to this M0 can be added later.
>
> Actually the WiP driver for MCU LED interface, that we use in our
> kernel is here: https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb
>
> It definitely needs some cleanup and it adds non-standard features
> (main PWM for all LEDs, autonomous blink mode, colors) via custom
> /sys files, which I suspect that is not going to be acceptable for
> upstream. Let's keep it for the next iteration.
Actually, LEDs that can do PWM intensity on their own are common and
supported.
LEDs that can do PWM pretty advanced patterns are common in the cellphones,
as is the color. Unfortunately, good support in kernel is missing. It
would be good to change that.
In n900, I have a LED that can compute prime numbers then blink them,
autonomously. We probably don't need to support _that_, but common
support for patterns would be good.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] ARM: dts: Add support for Turris Omnia
Date: Sat, 10 Dec 2016 09:16:04 +0100 [thread overview]
Message-ID: <20161210081604.GA8273@xo-6d-61-c0.localdomain> (raw)
In-Reply-To: <1480078151.381.4@smtp.gmail.com>
Hi!
> >Yes. That is fine. It is just unusual. Most boards have gpio-led and
> >gpio-keys, which are easy to add. That is why i asked. Adding an LED
> >driver which talks to this M0 can be added later.
>
> Actually the WiP driver for MCU LED interface, that we use in our
> kernel is here: https://github.com/tmshlvck/omnia-linux/commit/2121afd8fbd2e4c720edcdd472b11b5303bc0dfb
>
> It definitely needs some cleanup and it adds non-standard features
> (main PWM for all LEDs, autonomous blink mode, colors) via custom
> /sys files, which I suspect that is not going to be acceptable for
> upstream. Let's keep it for the next iteration.
Actually, LEDs that can do PWM intensity on their own are common and
supported.
LEDs that can do PWM pretty advanced patterns are common in the cellphones,
as is the color. Unfortunately, good support in kernel is missing. It
would be good to change that.
In n900, I have a LED that can compute prime numbers then blink them,
autonomously. We probably don't need to support _that_, but common
support for patterns would be good.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2016-12-10 14:24 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-05 20:38 [PATCH RFC] ARM: dts: add support for Turris Omnia Uwe Kleine-König
2016-11-05 20:38 ` Uwe Kleine-König
[not found] ` <20161105203841.9661-1-uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
2016-11-05 21:04 ` Andrew Lunn
2016-11-05 21:04 ` Andrew Lunn
[not found] ` <20161105210441.GB1216-g2DYL2Zd6BY@public.gmane.org>
2016-11-05 22:08 ` Uwe Kleine-König
2016-11-05 22:08 ` Uwe Kleine-König
[not found] ` <20161105220848.k6rrjmvvhdaeduma-jgopVnDzZD+b0XQX99//ntPVjbGH4+40kFgPdswSElo@public.gmane.org>
2016-11-06 10:19 ` Andrew Lunn
2016-11-06 10:19 ` Andrew Lunn
2016-11-05 21:23 ` Andrew Lunn
2016-11-05 21:23 ` Andrew Lunn
[not found] ` <20161105212326.GC1216-g2DYL2Zd6BY@public.gmane.org>
2016-11-05 21:27 ` Uwe Kleine-König
2016-11-05 21:27 ` Uwe Kleine-König
[not found] ` <20161105212748.vtdprlxxismy5xmk-jgopVnDzZD+b0XQX99//ntPVjbGH4+40kFgPdswSElo@public.gmane.org>
2016-11-05 21:37 ` Andrew Lunn
2016-11-05 21:37 ` Andrew Lunn
[not found] ` <20161106104534.lsdyppz5qcnjcqe4@perseus.defre.kleine-koenig.org>
[not found] ` <20161106111109.GD9617@lunn.ch>
[not found] ` <20161106141716.fwgje74rhhixnixq@perseus.defre.kleine-koenig.org>
[not found] ` <20161106162809.GA14042@lunn.ch>
[not found] ` <20161106162809.GA14042-g2DYL2Zd6BY@public.gmane.org>
2016-11-06 19:32 ` Uwe Kleine-König
2016-11-06 19:32 ` Uwe Kleine-König
2016-11-07 7:41 ` Martin Strbačka
2016-11-07 7:41 ` Martin Strbačka
2016-11-14 12:23 ` tomas.hlavacek-x+rMaJPWets
2016-11-14 12:23 ` tomas.hlavacek at nic.cz
[not found] ` <1479126185.15557.5-TAvD023jEQEN+BqQ9rBEUg@public.gmane.org>
2016-11-14 13:10 ` Andrew Lunn
2016-11-14 13:10 ` Andrew Lunn
2016-11-14 14:51 ` tomas.hlavacek
2016-11-14 14:59 ` tomas.hlavacek
2016-11-14 14:59 ` tomas.hlavacek at nic.cz
2016-11-14 20:16 ` Uwe Kleine-König
2016-11-14 20:16 ` Uwe Kleine-König
[not found] ` <20161114201640.rr32iyjf5a53v33t-jgopVnDzZD+b0XQX99//ntPVjbGH4+40kFgPdswSElo@public.gmane.org>
2016-11-14 20:28 ` Andrew Lunn
2016-11-14 20:28 ` Andrew Lunn
[not found] ` <20161114202832.GG24546-g2DYL2Zd6BY@public.gmane.org>
2016-11-19 20:09 ` tomas.hlavacek-x+rMaJPWets
2016-11-19 20:09 ` tomas.hlavacek at nic.cz
[not found] ` <1479586147.10840.0-TAvD023jEQEN+BqQ9rBEUg@public.gmane.org>
2016-11-20 20:30 ` Uwe Kleine-König
2016-11-20 20:30 ` Uwe Kleine-König
2016-11-22 21:59 ` tomas.hlavacek
2016-11-22 21:59 ` tomas.hlavacek at nic.cz
2016-11-23 0:09 ` [RFC PATCH] ARM: dts: Add " Tomas Hlavacek
2016-11-23 0:09 ` Tomas Hlavacek
2016-11-23 0:09 ` Tomas Hlavacek
2016-11-23 0:35 ` Andrew Lunn
2016-11-23 0:35 ` Andrew Lunn
2016-11-24 8:37 ` Uwe Kleine-König
2016-11-24 8:37 ` Uwe Kleine-König
2016-11-24 15:07 ` Andrew Lunn
2016-11-24 15:07 ` Andrew Lunn
2016-11-25 12:49 ` Tomas Hlavacek
2016-11-25 12:49 ` Tomas Hlavacek
2016-11-25 12:49 ` Tomas Hlavacek
2016-11-25 14:34 ` Uwe Kleine-König
2016-12-10 8:16 ` Pavel Machek [this message]
2016-12-10 8:16 ` Pavel Machek
2016-12-10 8:16 ` Pavel Machek
2016-11-23 8:19 ` Uwe Kleine-König
2016-11-23 8:19 ` Uwe Kleine-König
2016-11-23 8:19 ` Uwe Kleine-König
[not found] ` <1479851991.26813.2-TAvD023jEQEN+BqQ9rBEUg@public.gmane.org>
2016-11-23 0:27 ` [PATCH RFC] ARM: dts: add " tomas.hlavacek-x+rMaJPWets
2016-11-23 0:27 ` tomas.hlavacek at nic.cz
[not found] ` <1479860851.10840.11-TAvD023jEQEN+BqQ9rBEUg@public.gmane.org>
2016-11-23 1:39 ` Andrew Lunn
2016-11-23 1:39 ` Andrew Lunn
2016-11-23 14:59 ` Andrew Lunn
2016-11-23 14:59 ` Andrew Lunn
[not found] ` <20161123145916.GL14947-g2DYL2Zd6BY@public.gmane.org>
2016-11-23 18:36 ` Uwe Kleine-König
2016-11-23 18:36 ` Uwe Kleine-König
2016-11-23 22:45 ` tomas.hlavacek
2016-11-23 22:45 ` tomas.hlavacek at nic.cz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161210081604.GA8273@xo-6d-61-c0.localdomain \
--to=pavel@ucw.cz \
--cc=andrew@lunn.ch \
--cc=devicetree@vger.kernel.org \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=tmshlvck@gmail.com \
--cc=uwe@kleine-koenig.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.