* Re: No more new fbdev drivers, please
From: Ondrej Zary @ 2015-09-25 11:00 UTC (permalink / raw)
To: dri-devel
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Aaro Koskinen,
Greg Kroah-Hartman, linux-kernel@vger.kernel.org, Tomi Valkeinen,
Laurent Pinchart, Daniel Vetter, Dave Airlie, Sudip Mukherjee
In-Reply-To: <20150925084923.GD5273@blackmetal.musicnaut.iki.fi>
On Friday 25 September 2015, Aaro Koskinen wrote:
> Hi,
>
> On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
> > fbdev is (more or less) maintained, but it's a deprecated framework. All
> > new Linux display drivers should be done on DRM.
> >
> > So let's not add any more new fbdev drivers.
> >
> > I will continue to maintain the current fbdev drivers, and I don't mind
> > adding some new features to those current drivers, as long as the amount
> > of code required to add the features stays sensible.
> >
> > I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> > and the question is what to do with those.
>
> I was still planning to work on xgifb as I need it on some systems for
> the console.
xgifb supports these devices:
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_20
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_27
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_42
Two of them are already supported by sisfb:
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_20
PCI_VENDOR_ID_XGI, PCI_DEVICE_ID_XGI_40
So I think that support for the remaining two (and missing features, if any)
should be added to sisfb.
--
Ondrej Zary
^ permalink raw reply
* Re: omapdss: Division by zero in kernel
From: Pali Rohár @ 2015-09-25 11:34 UTC (permalink / raw)
To: Pavel Machek
Cc: Peter Teoh, Tomi Valkeinen, Jean-Christophe Plagniol-Villard,
Jyri Sarha, omap, linux-fbdev, LKML, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, Nishanth Menon
In-Reply-To: <20150917051644.GA6665@amd>
On Thursday 17 September 2015 07:16:44 Pavel Machek wrote:
>
> > > if (image->depth = 1) {
> > > if (p->fix.visual = FB_VISUAL_TRUECOLOR ||
> > > p->fix.visual = FB_VISUAL_DIRECTCOLOR) {
> > > fgcolor = ((u32*)(p->pseudo_palette))[image->fg_color];
> > > bgcolor = ((u32*)(p->pseudo_palette))[image->bg_color];
> > > } else {
> > > fgcolor = image->fg_color;
> > > bgcolor = image->bg_color;
> > > }
> > >
> > > if (32 % bpp = 0 && !start_index && !pitch_index &&
> > > ((width & (32/bpp-1)) = 0) &&
> > > bpp >= 8 && bpp <= 32)
> > > fast_imageblit(image, p, dst1, fgcolor, bgcolor);
> > > else
> > > slow_imageblit(image, p, dst1, fgcolor, bgcolor,
> > > start_index, pitch_index);
> > > } else
> > > color_imageblit(image, p, dst1, start_index, pitch_i
> > >
> > >
> > > Notice that bpp is not checked for zero, and thus bpp=0 is totally
> > > feasible? resulting in 32/bpp crashing the kernel?
> > >
> >
> > Hm... this could really be a problem! But how to patch it? Which branch
> > should be called (fast_ or slow_ function) if bpp is zero?
> >
> > And is there some way to force kernel to dump backtrace into dmesg when
> > division by zero occur?
>
> You can do WARN_ON(bpp=1) ... and should probably return in that
> case.
>
> Pavel
Does not make sense to call slow_ function? In that if condition check
also that bpp is nonzero...
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Tomi Valkeinen @ 2015-09-25 13:09 UTC (permalink / raw)
To: Kamil Lulko, Daniel Vetter; +Cc: linux-fbdev, linux-kernel, dri-devel
In-Reply-To: <560524E7.4020707@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
On 25/09/15 13:41, Kamil Lulko wrote:
> Hi,
>
>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>> new Linux display drivers should be done on DRM.
>
> What about no-mmu platforms? DRM has a big fat MMU dependency in the
> kconfig, is there a way to write DRM driver for such devices?
I guess not.
Then again, I don't see why DRM would have a hard dependency to MMU, if
the work is done to make DRM work optionally without MMU. How much work
that is, I have no idea.
Tom
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] staging: sm7xxfb: move sm712fb out of staging
From: Sudip Mukherjee @ 2015-09-25 13:54 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe Plagniol-Villard, Jonathan Corbet,
Greg Kroah-Hartman, linux-kernel, linux-fbdev, linux-doc, devel
In-Reply-To: <5603E567.5000001@ti.com>
On Thu, Sep 24, 2015 at 02:58:31PM +0300, Tomi Valkeinen wrote:
>
> On 02/09/15 15:48, Sudip Mukherjee wrote:
>
<snip>
>
> Is there a public datasheet for the HW?
I could not find one in Silicon Motion website. I will try to find else
I can talk to them and keep it in my github. And can send you also if
you want.
>
> The driver as it is now is quite horrible. Huge tables of raw data,
> written directly to the registers. Lots of magic numbers all around.
> Even with a datasheet, presuming it's public and it contains all those
> values, the driver is rather unmaintainable.
>
> All those need to be sorted out for the DRM driver anyway, so maybe it's
> better to clean up the fb driver first.
Ok. I never looked at them to see how they can be made better. I will
see.
regards
sudip
^ permalink raw reply
* Re: [PATCH] fbdev: broadsheetfb: fix memory leak
From: Sudip Mukherjee @ 2015-09-25 13:56 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jean-Christophe Plagniol-Villard, linux-kernel, linux-fbdev
In-Reply-To: <5603CCA0.6000702@ti.com>
On Thu, Sep 24, 2015 at 01:12:48PM +0300, Tomi Valkeinen wrote:
>
> On 18/09/15 14:16, Sudip Mukherjee wrote:
> > On the error path we have missed releasing the firmware.
> >
> > Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> > ---
<snip>
>
> This looks like correct fix, but where is the firmware released when
> there is no error?
I will send v2. Usually all the memleaks will be in the error path so I
concentrate on that part. Sorry, should have looked fully.
regards
sudip
^ permalink raw reply
* Re: [PATCH] fbdev: put module after running driver callback
From: David Herrmann @ 2015-09-25 17:58 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev@vger.kernel.org, Jean-Christophe Plagniol-Villard,
dri-devel@lists.freedesktop.org
In-Reply-To: <5603DD55.8080801@ti.com>
Hi
On Thu, Sep 24, 2015 at 1:24 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
> On 11/09/15 19:10, David Herrmann wrote:
>> Currently, for each open() on an fbdev device, we pin the underlying
>> fbdev device and driver module. On close(), we release both. This
>> guarantees that the fbdev object stays around until the last FD is
>> released (even though it might be unregistered already).
>>
>> However, currently we call module_put() *before* calling put_fb_info().
>> This has the side-effect that the driver module might be unloaded before
>> put_fb_info() calls into fbinfo->fbops->fb_destroy().
>>
>> Fix this by keeping the module pinned until after we release our fbdev
>> reference. Note that register_framebuffer() and unregister_framebuffer()
>> are special as we require the driver to unregister device before
>> unloading. Hence, they don't need to pin the module. However, all open
>> handlers *have to*.
>>
>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>> ---
>> drivers/video/fbdev/core/fbmem.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
>> index 0705d88..4e78731 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -1482,13 +1482,16 @@ __acquires(&info->lock)
>> __releases(&info->lock)
>> {
>> struct fb_info * const info = file->private_data;
>> + struct module *owner;
>>
>> mutex_lock(&info->lock);
>> if (info->fbops->fb_release)
>> info->fbops->fb_release(info,1);
>> - module_put(info->fbops->owner);
>> + owner = info->fbops->owner;
>> mutex_unlock(&info->lock);
>> +
>> put_fb_info(info);
>> + module_put(owner);
>> return 0;
>> }
>
> Looking at fb_open(), in error case it calls module_put() followed by
> put_fb_info(). Is that broken also?
Indeed, same issue here. I will send v2 which fixes both.
> Have you hit this bug, or did you just find it by looking at the code?
> In other words, is this for 4.3 fixes, or 4.4. I guess the user needs to
> unload the module just at the right time to trigger this bug.
Theoretical issue. It's almost impossible to trigger, as module
unloading takes ages compared to the time required to release the
fbinfo.
Thanks
David
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Daniel Vetter @ 2015-09-25 18:44 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: dri-devel, linux-fbdev, linux-kernel, Kamil Lulko
In-Reply-To: <5605479A.2020903@ti.com>
On Fri, Sep 25, 2015 at 04:09:46PM +0300, Tomi Valkeinen wrote:
>
>
> On 25/09/15 13:41, Kamil Lulko wrote:
> > Hi,
> >
> >> fbdev is (more or less) maintained, but it's a deprecated framework. All
> >> new Linux display drivers should be done on DRM.
> >
> > What about no-mmu platforms? DRM has a big fat MMU dependency in the
> > kconfig, is there a way to write DRM driver for such devices?
>
> I guess not.
>
> Then again, I don't see why DRM would have a hard dependency to MMU, if
> the work is done to make DRM work optionally without MMU. How much work
> that is, I have no idea.
We have plenty drivers in drm without hw mmu, and yeah there's probably no
reason at all why the drm subsystem has a hard depency on cpu MMUs. Might
be some #ifdef fallout that needs to be done, but there shouldn't be
anything fundamental. Maybe the old dri1 days code has something, but
that's all historical cruft anyway.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Sudip Mukherjee @ 2015-09-26 7:27 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, DRI Development, Laurent Pinchart,
Daniel Vetter, Arnaud Patard, Dave Airlie
In-Reply-To: <5603EC15.9090605@ti.com>
On Thu, Sep 24, 2015 at 03:27:01PM +0300, Tomi Valkeinen wrote:
> Hi all,
>
> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.
<snip>
>
> SM750 hardware seems to support multiple outputs, hardware overlays, 2D
> accelerator... I think it's pointless to write an fbdev driver for such
> a HW, as it's not possible to use those features with fbdev (without
> custom API).
Yes, it supports these and even SM712 which was recently moved out of
staging to fbdev area (which is the main reason that this thread
started) also supports dual display and 2D acceleration but those
features are not yet done in that driver.
SM750 will also have its code cleaned in few months so that it will be
ready to be moved out of staging. Right now we only have the framebuffer
driver and this hardware is being used in many laptops and notebooks. As
of now drm driver is not there for both SM712 and SM750. So then what
happens after SM750 is ready to be moved out? Will it be accepted in
fbdev or it will have to stay in staging untill a drm driver is ready?
BTW, I had a doubt about drm drivers. Is there any library or test suite
to test the driver? I am almost halfway in making a KMS driver for SM712
but still don't know how to test it properly. I was thinkig of asking
Daniel offlist but since this thread came up so asking here.
regards
sudip
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Ilia Mirkin @ 2015-09-26 7:29 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen,
Laurent Pinchart, Daniel Vetter, Arnaud Patard, Dave Airlie
In-Reply-To: <20150926071539.GA30836@sudip-pc>
On Sat, Sep 26, 2015 at 3:15 AM, Sudip Mukherjee
<sudipm.mukherjee@gmail.com> wrote:
> BTW, I had a doubt about drm drivers. Is there any library or test suite
> to test the driver? I am almost halfway in making a KMS driver for SM712
> but still don't know how to test it properly. I was thinkig of asking
> Daniel offlist but since this thread came up so asking here.
Take a look at the modetest tool, part of libdrm:
http://cgit.freedesktop.org/mesa/drm/tree/tests/modetest
It's quite handy and contains command-line access to a lot of the
various KMS functionality, changing modes, configuring planes,
different formats, etc.
-ilia
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Geert Uytterhoeven @ 2015-09-26 8:28 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen,
Laurent Pinchart, Arnaud Patard, Dave Airlie, Sudip Mukherjee
In-Reply-To: <20150924152312.GV3383@phenom.ffwll.local>
Hi Daniel,
On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
>> Or are there some plans to make the writing of DRM drivers for very
>> simple/trivial devices a bit simpler?
>
> Since years I'm trying to sell someone on implementing support for
> drm_simple_outputs which would collapse the crtc->encoder->connector
> chain into 1 entity. Would be trivial to implement and then trivial to
> write simple drivers on top of that. And besides that drm already has
> piles of reallly simple drivers with just one output and one framebuffer.
>
> There's no reason not to use drm for gfx drivers at all.
Good to hear that!
For the (mailing list) record, can you please provide some explicit pointers
to these existing really simple drivers?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2] fbdev: broadsheetfb: fix memory leak
From: Sudip Mukherjee @ 2015-09-26 8:52 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-kernel, linux-fbdev, Sudip Mukherjee
We have requested the firmware and it was loaded but we missed releasing
it both on success and error.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
---
v1: relased the firmware only on the error path.
drivers/video/fbdev/broadsheetfb.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/broadsheetfb.c b/drivers/video/fbdev/broadsheetfb.c
index 0e5fde1..9f9a7be 100644
--- a/drivers/video/fbdev/broadsheetfb.c
+++ b/drivers/video/fbdev/broadsheetfb.c
@@ -752,7 +752,7 @@ static ssize_t broadsheet_loadstore_waveform(struct device *dev,
if ((fw_entry->size < 8*1024) || (fw_entry->size > 64*1024)) {
dev_err(dev, "Invalid waveform\n");
err = -EINVAL;
- goto err_failed;
+ goto err_fw;
}
mutex_lock(&(par->io_lock));
@@ -762,13 +762,15 @@ static ssize_t broadsheet_loadstore_waveform(struct device *dev,
mutex_unlock(&(par->io_lock));
if (err < 0) {
dev_err(dev, "Failed to store broadsheet waveform\n");
- goto err_failed;
+ goto err_fw;
}
dev_info(dev, "Stored broadsheet waveform, size %zd\n", fw_entry->size);
- return len;
+ err = len;
+err_fw:
+ release_firmware(fw_entry);
err_failed:
return err;
}
--
1.9.1
^ permalink raw reply related
* Re: No more new fbdev drivers, please
From: Geert Uytterhoeven @ 2015-09-26 9:03 UTC (permalink / raw)
To: Kamil Lulko
Cc: Linux Fbdev development list, Tomi Valkeinen,
linux-kernel@vger.kernel.org, DRI Development
In-Reply-To: <560524E7.4020707@gmail.com>
On Fri, Sep 25, 2015 at 12:41 PM, Kamil Lulko <kamil.lulko@gmail.com> wrote:
>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>> new Linux display drivers should be done on DRM.
>
>
> What about no-mmu platforms? DRM has a big fat MMU dependency in the
> kconfig, is there a way to write DRM driver for such devices?
That would indeed be a showstopper...
I dropped the dependency, and gave it a quick try for m68knommu.
Seems like DRM currently needs pgprot_writecombine() and pte_wrprotect().
Probably that can be fixed easily.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Alex Deucher @ 2015-09-26 17:07 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Daniel Vetter,
linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen,
Laurent Pinchart, Greg Kroah-Hartman, Arnaud Patard, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <CAMuHMdVAO8Ua4G1DRMxTKxqJaAb4xBTQie-nvOkYJ7sox-YCYw@mail.gmail.com>
On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Daniel,
>
> On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
>>> Or are there some plans to make the writing of DRM drivers for very
>>> simple/trivial devices a bit simpler?
>>
>> Since years I'm trying to sell someone on implementing support for
>> drm_simple_outputs which would collapse the crtc->encoder->connector
>> chain into 1 entity. Would be trivial to implement and then trivial to
>> write simple drivers on top of that. And besides that drm already has
>> piles of reallly simple drivers with just one output and one framebuffer.
>>
>> There's no reason not to use drm for gfx drivers at all.
>
> Good to hear that!
>
> For the (mailing list) record, can you please provide some explicit pointers
> to these existing really simple drivers?
See the tilcdc, ast, mgag200, and udl drivers for example.
Alex
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Geert Uytterhoeven @ 2015-09-26 18:01 UTC (permalink / raw)
To: Alex Deucher
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Daniel Vetter,
linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen,
Laurent Pinchart, Greg Kroah-Hartman, Arnaud Patard, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <CADnq5_NL5p+sRzOvVpr=JnZ-e-vGtDD-69qapQMKawWtfVRnCw@mail.gmail.com>
Hi Alex,
On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
>>>> Or are there some plans to make the writing of DRM drivers for very
>>>> simple/trivial devices a bit simpler?
>>>
>>> Since years I'm trying to sell someone on implementing support for
>>> drm_simple_outputs which would collapse the crtc->encoder->connector
>>> chain into 1 entity. Would be trivial to implement and then trivial to
>>> write simple drivers on top of that. And besides that drm already has
>>> piles of reallly simple drivers with just one output and one framebuffer.
>>>
>>> There's no reason not to use drm for gfx drivers at all.
>>
>> Good to hear that!
>>
>> For the (mailing list) record, can you please provide some explicit pointers
>> to these existing really simple drivers?
>
> See the tilcdc, ast, mgag200, and udl drivers for example.
Thanks for the list!
The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
several fbdev drivers that have less than 200 LoC.
Granted, these really small ones support a single fixed video mode only, but
you can write a simple fbdev driver with mode setting in less than 1000 LoC.
I'm sure DRM can do better?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: David Herrmann @ 2015-09-26 18:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Daniel Vetter,
linux-kernel@vger.kernel.org, DRI Development, Arnaud Patard,
Tomi Valkeinen, Laurent Pinchart, Greg Kroah-Hartman, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <CAMuHMdX0Jg9RSu9rm2-trtMCDpS16Zy8VLEnmjvW_vWVWvHdVQ@mail.gmail.com>
Hi
On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Alex,
>
> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Thu, Sep 24, 2015 at 5:23 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>> On Thu, Sep 24, 2015 at 02:46:21PM +0200, Thomas Petazzoni wrote:
>>>>> Or are there some plans to make the writing of DRM drivers for very
>>>>> simple/trivial devices a bit simpler?
>>>>
>>>> Since years I'm trying to sell someone on implementing support for
>>>> drm_simple_outputs which would collapse the crtc->encoder->connector
>>>> chain into 1 entity. Would be trivial to implement and then trivial to
>>>> write simple drivers on top of that. And besides that drm already has
>>>> piles of reallly simple drivers with just one output and one framebuffer.
>>>>
>>>> There's no reason not to use drm for gfx drivers at all.
>>>
>>> Good to hear that!
>>>
>>> For the (mailing list) record, can you please provide some explicit pointers
>>> to these existing really simple drivers?
>>
>> See the tilcdc, ast, mgag200, and udl drivers for example.
>
> Thanks for the list!
>
> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
> several fbdev drivers that have less than 200 LoC.
> Granted, these really small ones support a single fixed video mode only, but
> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>
> I'm sure DRM can do better?
Is counting lines really the level of the discussion to go here?
DRM is a big set of helpers, nothing else. If many trivial, small
drivers share common code, developers are more than welcome to
contribute them to drm-core and help making drivers less complex.
As Daniel mentioned, the connector+encoder+crtc combination is one of
those simplifications that would make sense if more such drivers are
added. Furthermore, the not-yet-merged SimpleDRM driver is one example
how to implement multiple of those dumb-fb drivers with a shared
code-base.
Thanks
David
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Geert Uytterhoeven @ 2015-09-26 18:46 UTC (permalink / raw)
To: David Herrmann
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Daniel Vetter,
linux-kernel@vger.kernel.org, DRI Development, Arnaud Patard,
Tomi Valkeinen, Laurent Pinchart, Greg Kroah-Hartman, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <CANq1E4TN4_NNs32LBcNWeDC2jUtT2TCYHfYeummEC5-TQn7BpA@mail.gmail.com>
Hi David,
On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> For the (mailing list) record, can you please provide some explicit pointers
>>>> to these existing really simple drivers?
>>>
>>> See the tilcdc, ast, mgag200, and udl drivers for example.
>>
>> Thanks for the list!
>>
>> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
>> several fbdev drivers that have less than 200 LoC.
>> Granted, these really small ones support a single fixed video mode only, but
>> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>>
>> I'm sure DRM can do better?
>
> Is counting lines really the level of the discussion to go here?
LoC is not the most important. But if the smallest DRM driver needs an order
of magnitude more LoC than the smallest fbdev driver, I start to wonder.
E.g. if I want to write a new simple driver for my new shiny hardware, it
can make a big difference if I have to write (and test/debug) 800 LoC, or
3000 LoC.
> DRM is a big set of helpers, nothing else. If many trivial, small
> drivers share common code, developers are more than welcome to
> contribute them to drm-core and help making drivers less complex.
Good. But from the figures above, I don't think we're at that point yet that
writing a new DRM driver is less/equal amount of work than writing a new
fbdev driver, at least for some classes of hardware. So it may be a bit
premature to put a moratorium on new fbdev drivers.
I may be mistaken, I'm still not sufficiently familiar with the DRM subsystem
as I'd like to be.
> As Daniel mentioned, the connector+encoder+crtc combination is one of
> those simplifications that would make sense if more such drivers are
> added. Furthermore, the not-yet-merged SimpleDRM driver is one example
> how to implement multiple of those dumb-fb drivers with a shared
> code-base.
Thanks, looking forward to SimpleDRM!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] Revert "backlight: pwm: Handle EPROBE_DEFER while requesting the PWM"
From: Robert Jarzmik @ 2015-09-26 19:24 UTC (permalink / raw)
To: Thierry Reding, Jingoo Han, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-pwm, linux-fbdev, linux-kernel, Robert Jarzmik
This reverts commit 68feaca0b13e453aa14ee064c1736202b48b342f.
This commit breaks legacy platforms, for which :
(a) no pwm table is added (legacy platforms)
(b) in this case, in pwm_get(), pmw_lookup_list is empty, and therefore
chosen = NULL, and therefore pwm_get() returns NULL, and pwm_get()
returns -EPROBE_DEFER
(c) as a consequence, this code is unreachable in pwm_bl.c :
if (IS_ERR(pb->pwm)) {
ret = PTR_ERR(pb->pwm);
dev_info(&pdev->dev, "%s:%d(): %d\n", __func__, __LINE__, ret);
if (ret = -EPROBE_DEFER)
goto err_alloc;
dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
pb->legacy = true;
pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
As this code is unreachable, all legacy platforms relying on pwm_id are
broken, amongst which pxa have been tested as broken.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/video/backlight/pwm_bl.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index eff379b234cc..57cb9ec8be43 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -272,10 +272,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->pwm = devm_pwm_get(&pdev->dev, NULL);
if (IS_ERR(pb->pwm)) {
- ret = PTR_ERR(pb->pwm);
- if (ret = -EPROBE_DEFER)
- goto err_alloc;
-
dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
pb->legacy = true;
pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
--
2.1.4
^ permalink raw reply related
* Re: No more new fbdev drivers, please
From: Rob Clark @ 2015-09-26 20:49 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Greg Kroah-Hartman,
Daniel Vetter, linux-kernel@vger.kernel.org, DRI Development,
Tomi Valkeinen, Laurent Pinchart, Arnaud Patard, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <CAMuHMdWdyTay2nX5CFPOUQQjVxFTTcZF=sVaNDziTs6GV2DGqQ@mail.gmail.com>
On Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi David,
>
> On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>>> <geert@linux-m68k.org> wrote:
>>>>> For the (mailing list) record, can you please provide some explicit pointers
>>>>> to these existing really simple drivers?
>>>>
>>>> See the tilcdc, ast, mgag200, and udl drivers for example.
>>>
>>> Thanks for the list!
>>>
>>> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
>>> several fbdev drivers that have less than 200 LoC.
>>> Granted, these really small ones support a single fixed video mode only, but
>>> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>>>
>>> I'm sure DRM can do better?
>>
>> Is counting lines really the level of the discussion to go here?
>
> LoC is not the most important. But if the smallest DRM driver needs an order
> of magnitude more LoC than the smallest fbdev driver, I start to wonder.
I think most of the drm/kms drivers are bigger due to more features..
iirc original tilcdc was ~2k loc (compared to ~1.6kloc for da8xx-fb),
but it already supported multiple modes, page flipping, vblank
notification, etc. It has grown since then. Although still probably
smaller than downstream da8xx-fb + tda998x hdmi bridge (and re-using
the same tda998x bridge code with several other drivers too, compared
to downstream solution for the same)..
Probably there is room for more helpers for even more restrictive hw.
BR,
-R
> E.g. if I want to write a new simple driver for my new shiny hardware, it
> can make a big difference if I have to write (and test/debug) 800 LoC, or
> 3000 LoC.
>
>> DRM is a big set of helpers, nothing else. If many trivial, small
>> drivers share common code, developers are more than welcome to
>> contribute them to drm-core and help making drivers less complex.
>
> Good. But from the figures above, I don't think we're at that point yet that
> writing a new DRM driver is less/equal amount of work than writing a new
> fbdev driver, at least for some classes of hardware. So it may be a bit
> premature to put a moratorium on new fbdev drivers.
> I may be mistaken, I'm still not sufficiently familiar with the DRM subsystem
> as I'd like to be.
>
>> As Daniel mentioned, the connector+encoder+crtc combination is one of
>> those simplifications that would make sense if more such drivers are
>> added. Furthermore, the not-yet-merged SimpleDRM driver is one example
>> how to implement multiple of those dumb-fb drivers with a shared
>> code-base.
>
> Thanks, looking forward to SimpleDRM!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Dave Airlie @ 2015-09-26 21:55 UTC (permalink / raw)
To: Rob Clark
Cc: Geert Uytterhoeven, Thomas Petazzoni, linux-fbdev, Teddy Wang,
Greg Kroah-Hartman, Daniel Vetter, linux-kernel@vger.kernel.org,
DRI Development, Tomi Valkeinen, Laurent Pinchart, Arnaud Patard,
Dave Airlie, Sudip Mukherjee
In-Reply-To: <CAF6AEGvqFXf8BgDz6dT4EX95La6PgQjj0ZzK2j3aW8_MvqRL1w@mail.gmail.com>
On 27 September 2015 at 06:49, Rob Clark <robdclark@gmail.com> wrote:
> On Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> Hi David,
>>
>> On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>>> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>>>>> <geert@linux-m68k.org> wrote:
>>>>>> For the (mailing list) record, can you please provide some explicit pointers
>>>>>> to these existing really simple drivers?
>>>>>
>>>>> See the tilcdc, ast, mgag200, and udl drivers for example.
>>>>
>>>> Thanks for the list!
>>>>
>>>> The smallest of these (udl) still counts in at ca. 2800 LoC, while there are
>>>> several fbdev drivers that have less than 200 LoC.
>>>> Granted, these really small ones support a single fixed video mode only, but
>>>> you can write a simple fbdev driver with mode setting in less than 1000 LoC.
>>>>
>>>> I'm sure DRM can do better?
>>>
>>> Is counting lines really the level of the discussion to go here?
>>
>> LoC is not the most important. But if the smallest DRM driver needs an order
>> of magnitude more LoC than the smallest fbdev driver, I start to wonder.
>
> I think most of the drm/kms drivers are bigger due to more features..
> iirc original tilcdc was ~2k loc (compared to ~1.6kloc for da8xx-fb),
> but it already supported multiple modes, page flipping, vblank
> notification, etc. It has grown since then. Although still probably
> smaller than downstream da8xx-fb + tda998x hdmi bridge (and re-using
> the same tda998x bridge code with several other drivers too, compared
> to downstream solution for the same)..
>
> Probably there is room for more helpers for even more restrictive hw.
My main worry for having helpers for "simple" hw, is that people start
using them
to have a minimal 400loc driver, but once they add any feature outside
the helper
they have to rewrite their driver to avoid the helpers.
Most of the drm driver is boilerplate, we could possibly reduce the boilerplate,
but I'm not sure it's worth the effort to save somebody a small bit of
trouble at
bringup.
loc is a pointless tool for measuring this, a small drm driver will be as simple
as a small fbdev driver, and will likely provide more features that people need.
Dave.
^ permalink raw reply
* Re: [PATCH v2 1/3] staging: sm7xxfb: move sm712fb out of staging
From: Mike Rapoport @ 2015-09-27 4:42 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Tomi Valkeinen, devel, linux-fbdev, linux-doc, Greg Kroah-Hartman,
Jonathan Corbet, linux-kernel, Jean-Christophe Plagniol-Villard
In-Reply-To: <20150925134206.GA4799@sudip-pc>
Hi Sudip,
On Fri, Sep 25, 2015 at 07:12:06PM +0530, Sudip Mukherjee wrote:
> On Thu, Sep 24, 2015 at 02:58:31PM +0300, Tomi Valkeinen wrote:
> >
> > On 02/09/15 15:48, Sudip Mukherjee wrote:
> >
> <snip>
> >
> > Is there a public datasheet for the HW?
> I could not find one in Silicon Motion website. I will try to find else
> I can talk to them and keep it in my github. And can send you also if
> you want.
I'd appreciate sm750 datasheet, if you have one.
> >
> > The driver as it is now is quite horrible. Huge tables of raw data,
> > written directly to the registers. Lots of magic numbers all around.
> > Even with a datasheet, presuming it's public and it contains all those
> > values, the driver is rather unmaintainable.
> >
> > All those need to be sorted out for the DRM driver anyway, so maybe it's
> > better to clean up the fb driver first.
> Ok. I never looked at them to see how they can be made better. I will
> see.
>
> regards
> sudip
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Noralf Trønnes @ 2015-09-27 13:09 UTC (permalink / raw)
To: Tomi Valkeinen, Greg Kroah-Hartman, linux-fbdev, DRI Development
Cc: Sudip Mukherjee, Teddy Wang, Thomas Petazzoni, Laurent Pinchart,
Dave Airlie, Daniel Vetter, linux-kernel@vger.kernel.org
In-Reply-To: <5603EC15.9090605@ti.com>
Den 24.09.2015 14:27, skrev Tomi Valkeinen:
> Hi all,
>
> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.
>
> So let's not add any more new fbdev drivers.
>
> I will continue to maintain the current fbdev drivers, and I don't mind
> adding some new features to those current drivers, as long as the amount
> of code required to add the features stays sensible.
>
> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> and the question is what to do with those.
>
> xgifb was added in 2010, and is still in staging.
>
> fbtft looks like maybe some kind of framework on top of fbdev, with
> fbtft specific subdrivers... I didn't look at it in detail, but my gut
> says "never".
I have done some work [1] to try and make fbtft look more like the rest
of the kernel (doc [2]), but that work will result in an almost complete
rewrite of fbtft. When Tomi showed reluctance to move sm712fb out of
staging [3], I started to look at DRM to see if I could find my way
through the myriad of helpers and objects/structs.
I now have this simplified view of DRM [4]:
struct tinydrm_device {
struct drm_device *base;
struct drm_plane plane;
struct drm_crtc crtc;
struct drm_encoder encoder;
struct drm_connector connector;
struct drm_fbdev_cma *fbdev_cma;
bool enabled;
u32 width, height;
void *dev_private;
int (*enable)(struct tinydrm_device *tdev);
int (*disable)(struct tinydrm_device *tdev);
int (*dirty)(struct drm_framebuffer *fb,
struct drm_gem_cma_object *cma_obj,
unsigned flags, unsigned color,
struct drm_clip_rect *clips, unsigned num_clips);
/* blank() is missing */
/* maybe some modeset() function to set hw rotation */
};
Currently I'm able to get fbdev framebuffer changes through as dirty()
calls. Next step is to hook up some of the rewritten fbtft code to
actually get something on the display.
This is the display controller abstraction I use in the rewritten fbtft:
struct lcdctrl {
struct lcdreg *lcdreg;
u32 width;
u32 height;
u32 rotation;
bool enabled;
struct regulator *power_supply;
void *driver_private;
u64 flags;
int (*poweron)(struct lcdctrl *ctrl);
void (*poweroff)(struct lcdctrl *ctrl);
int (*update)(struct lcdctrl *ctrl, struct lcdctrl_update *update);
int (*rotate)(struct lcdctrl *ctrl, u32 rotation);
int (*blank)(struct lcdctrl *ctrl, bool blank);
bool (*check)(struct lcdctrl *ctrl, u32 value);
};
So what I would like, is to have a simple struct like this to hide the
complexity of the graphics subsystem. Leaving the driver with just a
few lines of code to setup the controller:
static int ada_mipifb_1480_poweron(struct lcdctrl *ctrl)
{
lcdreg_reset(reg);
lcdreg_writereg(reg, ILI9340_PWCTRL1, 0x23);
[...]
}
static int ada_mipifb_probe(struct spi_device *spi)
{
cfg.width = 240;
cfg.height = 320;
cfg.addr_mode0 = ILI9340_MADCTL_MX;
cfg.addr_mode90 = ILI9340_MADCTL_MV | ILI9340_MADCTL_MY |
ILI9340_MADCTL_MX;
cfg.addr_mode180 = ILI9340_MADCTL_MY;
cfg.addr_mode270 = ILI9340_MADCTL_MV;
cfg.bgr = true;
reg = devm_lcdreg_spi_init(spi, LCDREG_SPI_4WIRE);
ctrl = devm_mipi_dbi_init(reg, &cfg);
ctrl->poweron = ada_mipifb_1480_poweron;
return devm_lcdctrl_register(ctrl);
}
For me personally it doesn't matter whether these drivers are drm or fbdev.
fbdev has everything these drivers need, but maybe it's not such a good
choice
for the future.
Noralf.
[1] https://github.com/notro/linux-staging/commits/next
[2]
https://github.com/notro/linux-staging/blob/next/drivers/staging/fbtft/Documentation/fb/fbtft.txt
[3] https://lkml.org/lkml/2015/9/1/274
[4] https://gist.github.com/notro/59e0c064bc512e85e9b2
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Emil Velikov @ 2015-09-27 16:08 UTC (permalink / raw)
To: Noralf Trønnes
Cc: Tomi Valkeinen, Greg Kroah-Hartman, linux-fbdev, DRI Development,
Thomas Petazzoni, Teddy Wang, Daniel Vetter,
linux-kernel@vger.kernel.org, Laurent Pinchart, Dave Airlie,
Sudip Mukherjee
In-Reply-To: <5607EA9C.7040909@tronnes.org>
Hi all,
On 27 September 2015 at 14:09, Noralf Trønnes <noralf@tronnes.org> wrote:
>
> Den 24.09.2015 14:27, skrev Tomi Valkeinen:
>>
>> Hi all,
>>
>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>> new Linux display drivers should be done on DRM.
>>
>> So let's not add any more new fbdev drivers.
>>
>> I will continue to maintain the current fbdev drivers, and I don't mind
>> adding some new features to those current drivers, as long as the amount
>> of code required to add the features stays sensible.
>>
>> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
>> and the question is what to do with those.
>>
>> xgifb was added in 2010, and is still in staging.
>>
>> fbtft looks like maybe some kind of framework on top of fbdev, with
>> fbtft specific subdrivers... I didn't look at it in detail, but my gut
>> says "never".
>
>
> I have done some work [1] to try and make fbtft look more like the rest
> of the kernel (doc [2]), but that work will result in an almost complete
> rewrite of fbtft.
From a very quick skim fbtft looks pretty much like drm/panel. We
presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have
you had a look at these ?
Cheers,
Emil
^ permalink raw reply
* Re: No more new fbdev drivers, please
From: Gerd Hoffmann @ 2015-09-28 7:39 UTC (permalink / raw)
To: David Herrmann
Cc: Thomas Petazzoni, linux-fbdev, Teddy Wang, Daniel Vetter,
linux-kernel@vger.kernel.org, DRI Development, Tomi Valkeinen,
Geert Uytterhoeven, Laurent Pinchart, Greg Kroah-Hartman,
Arnaud Patard, Dave Airlie, Sudip Mukherjee
In-Reply-To: <CANq1E4TN4_NNs32LBcNWeDC2jUtT2TCYHfYeummEC5-TQn7BpA@mail.gmail.com>
Hi,
> As Daniel mentioned, the connector+encoder+crtc combination is one of
> those simplifications that would make sense if more such drivers are
> added.
Another one is memory management. It's pretty complex because it can
handle _way_ more than what simple drivers need, and the result is
_alot_ of ttm boilerplate in the drivers.
cheers,
Gerd
^ permalink raw reply
* Re: [PATCHv3 1/3] leds: Add of_led_get() and led_put()
From: Tomi Valkeinen @ 2015-09-28 8:08 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Jingoo Han, Lee Jones, linux-leds, linux-fbdev, Andrew Lunn
In-Reply-To: <55F2DC3C.6090100@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
On 11/09/15 16:50, Jacek Anaszewski wrote:
>> +/**
>> + * led_put() - release a LED device, reserved with led_get()
>
> s/led_get/of_led_get/
>
> or we should add led_get, but since class_find_device, which increments
> device ref count, takes led_node and led_match_led_node, it is tightly
> coupled tightly with OF. OTOH we could have of_led_put for symmetry,
> but it would have nothing to do with OF. Amending the comment is the
> best option here, I think.
I agree. I've changed the comment.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCHv3 2/3] backlight: add led-backlight driver
From: Tomi Valkeinen @ 2015-09-28 8:12 UTC (permalink / raw)
To: Jingoo Han, Lee Jones
Cc: Jacek Anaszewski, linux-leds, linux-fbdev, Andrew Lunn
In-Reply-To: <1441976857-26548-3-git-send-email-tomi.valkeinen@ti.com>
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]
Hi Jingoo, Lee,
On 11/09/15 16:07, Tomi Valkeinen wrote:
> This patch adds a led-backlight driver (led_bl), which is similar to
> pwm_bl except the driver uses a LED class driver to adjust the
> brightness in the HW.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/backlight/Kconfig | 7 ++
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/led_bl.c | 246 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 254 insertions(+)
> create mode 100644 drivers/video/backlight/led_bl.c
Any comments on the backlight side of this series? It is very similar to
the pwm_bl.c, so I presume the approach is acceptable?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox