From: Pavel Machek <pavel@ucw.cz>
To: Dan Murphy <dmurphy@ti.com>
Cc: linux-leds@vger.kernel.org, jacek.anaszewski@gmail.com,
kernel list <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-omap@vger.kernel.org, tony@atomide.com, sre@kernel.org,
nekit1000@gmail.com, mpartap@gmx.net, merlijn@wizzup.org
Subject: Re: [rfc] leds: add TI LMU backlight driver
Date: Thu, 6 Sep 2018 12:16:15 +0200 [thread overview]
Message-ID: <20180906101615.GA1467@amd> (raw)
In-Reply-To: <d96eab23-dbd9-71a6-551e-2bc99ce4a57c@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]
Hi!
> > Well, I don't think object file size is huge problem. First,
> > "distribution" kernel with support for 6 different chips will be ~71k,
> > while your proposal will result in ~136k. Second, yes, we could put
> > ifdefs into ti-lmu data file to make it smaller.
> >
> > Anyway, clean source code and easy maintainance is more important.
>
> I am going to reply here and snip the rest of the chain.
>
> My proposal is to create a ti-lmu-led-common file that contains all the common
> code. We can have LED drivers use that common code to perform the common tasks.
> This can then be extended to other devices past, present or future that have the
> same feature set.
Sounds good. But we'll still need to have the structure with register
info, right?
> Then the register maps and LED registration can be contained in each LED driver and any additional features
> can be supported in the LED driver. The common code will retrieve any device settings from
> the firmware that it is interested in.
From the device tree?
> I can throw some code together and RFC the code. This way we get the common core for the
> chips and not the bloat or messy source with a single driver.
>
> And yes I can put this together and support it if it is needed. I just need to go get the EVMs
> so I can test it.
Well, if possible, I'd like to see how the code would look. Example
for single LED type would be enough... If it is reasonable, I can port
it to Droid 4 or at least provide testing.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: [rfc] leds: add TI LMU backlight driver
Date: Thu, 6 Sep 2018 12:16:15 +0200 [thread overview]
Message-ID: <20180906101615.GA1467@amd> (raw)
In-Reply-To: <d96eab23-dbd9-71a6-551e-2bc99ce4a57c@ti.com>
Hi!
> > Well, I don't think object file size is huge problem. First,
> > "distribution" kernel with support for 6 different chips will be ~71k,
> > while your proposal will result in ~136k. Second, yes, we could put
> > ifdefs into ti-lmu data file to make it smaller.
> >
> > Anyway, clean source code and easy maintainance is more important.
>
> I am going to reply here and snip the rest of the chain.
>
> My proposal is to create a ti-lmu-led-common file that contains all the common
> code. We can have LED drivers use that common code to perform the common tasks.
> This can then be extended to other devices past, present or future that have the
> same feature set.
Sounds good. But we'll still need to have the structure with register
info, right?
> Then the register maps and LED registration can be contained in each LED driver and any additional features
> can be supported in the LED driver. The common code will retrieve any device settings from
> the firmware that it is interested in.
>From the device tree?
> I can throw some code together and RFC the code. This way we get the common core for the
> chips and not the bloat or messy source with a single driver.
>
> And yes I can put this together and support it if it is needed. I just need to go get the EVMs
> so I can test it.
Well, if possible, I'd like to see how the code would look. Example
for single LED type would be enough... If it is reasonable, I can port
it to Droid 4 or at least provide testing.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180906/1f5f7c15/attachment.sig>
next prev parent reply other threads:[~2018-09-06 10:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-29 21:20 [rfc] leds: add TI LMU backlight driver Pavel Machek
2018-08-29 21:20 ` Pavel Machek
2018-08-30 8:22 ` [PATCH] " Pavel Machek
2018-08-30 8:22 ` Pavel Machek
2018-08-30 8:22 ` Pavel Machek
2018-08-30 16:40 ` Tony Lindgren
2018-08-30 16:40 ` Tony Lindgren
2018-08-30 19:20 ` Jacek Anaszewski
2018-08-30 19:20 ` Jacek Anaszewski
2018-08-30 19:41 ` [rfc] " Dan Murphy
2018-08-30 19:41 ` Dan Murphy
2018-08-30 19:41 ` Dan Murphy
2018-08-30 20:18 ` Pavel Machek
2018-08-30 20:18 ` Pavel Machek
2018-08-31 12:19 ` Dan Murphy
2018-08-31 12:19 ` Dan Murphy
2018-08-31 12:19 ` Dan Murphy
2018-08-31 21:30 ` Pavel Machek
2018-08-31 21:30 ` Pavel Machek
2018-09-04 14:34 ` Dan Murphy
2018-09-04 14:34 ` Dan Murphy
2018-09-04 14:34 ` Dan Murphy
2018-09-06 10:16 ` Pavel Machek [this message]
2018-09-06 10:16 ` Pavel Machek
2018-08-30 20:37 ` kbuild test robot
2018-08-30 20:37 ` kbuild test robot
2018-08-30 20:37 ` kbuild test robot
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=20180906101615.GA1467@amd \
--to=pavel@ucw.cz \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=merlijn@wizzup.org \
--cc=mpartap@gmx.net \
--cc=nekit1000@gmail.com \
--cc=sre@kernel.org \
--cc=tony@atomide.com \
/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.