All of lore.kernel.org
 help / color / mirror / Atom feed
From: tmshlvck@gmail.com (Tomas Hlavacek)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] ARM: dts: Add support for Turris Omnia
Date: Fri, 25 Nov 2016 13:49:11 +0100	[thread overview]
Message-ID: <1480078151.381.4@smtp.gmail.com> (raw)
In-Reply-To: <20161124150700.GD7155@lunn.ch>

Hi!

On Thu, Nov 24, 2016 at 4:07 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  @Tomas: I think it doesn't make sense when we alternate sending 
>> patches
>>  without prior arrangement. Do you already work on a v5? If not I 
>> can do
>>  that to fix the last few comments. Not sure when a submission is too
>>  late to enter v4.10, but I think the window isn't that big any more.
> 
> It is getting a bit late. But maybe Linus will add in another -rc
> week.
> 
>> 
>>  > No leds? No buttons via gpio-keys?
>> 
>>  The leds are controlled by a Cortex-M0 and without intervention 
>> blink
>>  according to a hardware function (network, power, pci). IMHO that's 
>> ok
>>  for an initial setup.
> 
> 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.

Regarding the button, we actually have one, that is connected to the 
MCU and by default it sets LED brigtness autonomously, but it should be 
able to generate IRQs via the MCU if we change the mode in the MCU. 
I'll look into that.

Tomas

WARNING: multiple messages have this Message-ID (diff)
From: Tomas Hlavacek <tmshlvck@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, "Jason Cooper" <jason@lakedaemon.net>,
	"Uwe Kleine-König" <uwe@kleine-koenig.org>,
	"Russell King" <linux@armlinux.org.uk>,
	linux-kernel@vger.kernel.org, "Rob Herring" <robh+dt@kernel.org>,
	"Gregory Clement" <gregory.clement@free-electrons.com>,
	linux-arm-kernel@lists.infradead.org,
	"Sebastian Hesselbarth" <sebastian.hesselbarth@gmail.com>
Subject: Re: [RFC PATCH] ARM: dts: Add support for Turris Omnia
Date: Fri, 25 Nov 2016 13:49:11 +0100	[thread overview]
Message-ID: <1480078151.381.4@smtp.gmail.com> (raw)
In-Reply-To: <20161124150700.GD7155@lunn.ch>

Hi!

On Thu, Nov 24, 2016 at 4:07 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  @Tomas: I think it doesn't make sense when we alternate sending 
>> patches
>>  without prior arrangement. Do you already work on a v5? If not I 
>> can do
>>  that to fix the last few comments. Not sure when a submission is too
>>  late to enter v4.10, but I think the window isn't that big any more.
> 
> It is getting a bit late. But maybe Linus will add in another -rc
> week.
> 
>> 
>>  > No leds? No buttons via gpio-keys?
>> 
>>  The leds are controlled by a Cortex-M0 and without intervention 
>> blink
>>  according to a hardware function (network, power, pci). IMHO that's 
>> ok
>>  for an initial setup.
> 
> 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.

Regarding the button, we actually have one, that is connected to the 
MCU and by default it sets LED brigtness autonomously, but it should be 
able to generate IRQs via the MCU if we change the mode in the MCU. 
I'll look into that.

Tomas

WARNING: multiple messages have this Message-ID (diff)
From: Tomas Hlavacek <tmshlvck@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "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: Fri, 25 Nov 2016 13:49:11 +0100	[thread overview]
Message-ID: <1480078151.381.4@smtp.gmail.com> (raw)
In-Reply-To: <20161124150700.GD7155@lunn.ch>

Hi!

On Thu, Nov 24, 2016 at 4:07 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>  @Tomas: I think it doesn't make sense when we alternate sending 
>> patches
>>  without prior arrangement. Do you already work on a v5? If not I 
>> can do
>>  that to fix the last few comments. Not sure when a submission is too
>>  late to enter v4.10, but I think the window isn't that big any more.
> 
> It is getting a bit late. But maybe Linus will add in another -rc
> week.
> 
>> 
>>  > No leds? No buttons via gpio-keys?
>> 
>>  The leds are controlled by a Cortex-M0 and without intervention 
>> blink
>>  according to a hardware function (network, power, pci). IMHO that's 
>> ok
>>  for an initial setup.
> 
> 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.

Regarding the button, we actually have one, that is connected to the 
MCU and by default it sets LED brigtness autonomously, but it should be 
able to generate IRQs via the MCU if we change the mode in the MCU. 
I'll look into that.

Tomas

  reply	other threads:[~2016-11-25 12:49 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
2016-11-05 21:04 ` Andrew Lunn
2016-11-05 21:04   ` Andrew Lunn
2016-11-05 22:08   ` Uwe Kleine-König
2016-11-05 22:08     ` Uwe Kleine-König
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
2016-11-05 21:27   ` Uwe Kleine-König
2016-11-05 21:27     ` Uwe Kleine-König
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>
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 at nic.cz
2016-11-14 12:23   ` tomas.hlavacek-x+rMaJPWets
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 at nic.cz
2016-11-14 14:59       ` tomas.hlavacek
2016-11-14 20:16   ` Uwe Kleine-König
2016-11-14 20:16     ` Uwe Kleine-König
2016-11-14 20:28     ` Andrew Lunn
2016-11-14 20:28       ` Andrew Lunn
2016-11-19 20:09       ` tomas.hlavacek at nic.cz
2016-11-19 20:09         ` tomas.hlavacek-x+rMaJPWets
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 at nic.cz
2016-11-22 21:59             ` tomas.hlavacek
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 [this message]
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
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
2016-11-23  0:27             ` [PATCH RFC] ARM: dts: add " tomas.hlavacek at nic.cz
2016-11-23  0:27               ` tomas.hlavacek-x+rMaJPWets
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
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 at nic.cz
2016-11-23 22:45                 ` tomas.hlavacek

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=1480078151.381.4@smtp.gmail.com \
    --to=tmshlvck@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.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.