* [PATCH 0/7] Clean up write-combining MTRR addition
From: Andy Lutomirski @ 2013-05-03 23:00 UTC (permalink / raw)
To: linux-kernel, dri-devel, linux-fbdev; +Cc: Andy Lutomirski
A fair number of drivers (mostly graphics) add write-combining MTRRs.
Most ignore errors and most add the MTRR even on PAT systems which don't
need to use MTRRs.
This series adds new functions mtrr_{add,del}_wc_if_needed and
drm_mtrr_{add,del}_wc that report errors and do nothing if PAT is
enabled.
I've only tested the radeon driver, since I don't have test hardware
easily available for the other drivers.
Benefits include:
- Simpler code
- No more complaints about MTRR conflict warnings on PAT systems
- Eventual unexporting of the MTRR API?
This series eliminates about half of the mtrr_add calls in drivers/.
The series is also at:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cleanup
Andy Lutomirski (7):
x86: Add mtrr_{add,del}_wc_if_needed
drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Rework
drm_mtrr_{add,del}
drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
drm: Use drm_mtrr_add_wc for the AGP aperture
i915: Use drm_mtrr_{add,del}_wc
radeon: Switch to drm_mtrr_add_wc and add a missing drm_mtrr_del_wc
uvesafb: Clean up MTRR code
Documentation/fb/uvesafb.txt | 16 +++-----
arch/x86/include/asm/mtrr.h | 21 ++++++++++
arch/x86/kernel/cpu/mtrr/main.c | 53 +++++++++++++++++++++++++
drivers/gpu/drm/ast/ast_ttm.c | 14 ++-----
drivers/gpu/drm/cirrus/cirrus_ttm.c | 15 ++------
drivers/gpu/drm/drm_bufs.c | 11 ++----
drivers/gpu/drm/drm_pci.c | 8 ++--
drivers/gpu/drm/drm_stub.c | 10 +----
drivers/gpu/drm/drm_vm.c | 13 ++++---
drivers/gpu/drm/i915/i915_dma.c | 43 +++------------------
drivers/gpu/drm/mgag200/mgag200_ttm.c | 14 ++-----
drivers/gpu/drm/nouveau/nouveau_ttm.c | 13 ++-----
drivers/gpu/drm/radeon/radeon_object.c | 5 ++-
drivers/gpu/drm/savage/savage_bci.c | 42 ++++++++------------
drivers/gpu/drm/savage/savage_drv.h | 5 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 ++---
drivers/video/uvesafb.c | 70 +++++++++-------------------------
include/drm/drmP.h | 23 +++++------
include/video/uvesafb.h | 1 +
19 files changed, 169 insertions(+), 218 deletions(-)
--
1.8.1.4
^ permalink raw reply
* Re: [PATCH 0/6] Davinci fbdev driver and enable it for DMx platform
From: Prabhakar Lad @ 2013-05-03 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51838994.7070805@ti.com>
On Fri, May 3, 2013 at 3:25 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> On 4/26/2013 11:16 AM, Prabhakar Lad wrote:
>> Hi Laurent,
>>
>> On Thu, Apr 25, 2013 at 2:32 AM, Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com> wrote:
>>> Hi Prabhakar,
>>>
>>> Thank you for the patch.
>>>
>>> On Wednesday 24 April 2013 17:30:02 Prabhakar Lad wrote:
>>>> From: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>>>>
>>>> This patch series adds an fbdev driver for Texas
>>>> Instruments Davinci SoC.The display subsystem consists
>>>> of OSD and VENC, with OSD supporting 2 RGb planes and
>>>> 2 video planes.
>>>> http://focus.ti.com/general/docs/lit/
>>>> getliterature.tsp?literatureNumber=sprue37d&fileType=pdf
>>>>
>>>> A good amount of the OSD and VENC enabling code is
>>>> present in the kernel, and this patch series adds the
>>>> fbdev interface.
>>>>
>>>> The fbdev driver exports 4 nodes representing each
>>>> plane to the user - from fb0 to fb3.
>>>
>>> The obvious question is: why not a KMS driver instead ? :-)
>>>
>> I did go through the KMS model (thanks for pointing to your work and the video)
>> and it looks like this would require a fair amount of development, at this point
>> of time I would go with the current implementation and revisit on KMS model
>> at later point of time.
>
> But I doubt you will be able to sneak a new fbdev driver through. Last
> time I heard, Andrew is only taking in fixes not new features.
>
Then we have no choice left and go with KMS driver itself though it would take
some time since KMS is a new inclusion into DRM.
Regards,
--Prabhakar
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Laurent Pinchart @ 2013-05-03 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5182AF83.4080705@wwwdotorg.org>
Hi Stephen,
On Thursday 02 May 2013 12:25:07 Stephen Warren wrote:
> On 04/29/2013 04:04 PM, Arnd Bergmann wrote:
> > On Monday 29 April 2013, Laurent Pinchart wrote:
> >> On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
> >>> Good point. Stephen, would it be a problem to make this a KMS driver
> >>> instead? Old fbdev API could be emulated on top of it, until it goes out
> >>> of use, couldn't it?
> >>
> >> There's already an fbdev emulation layer in KMS, for such a simple use
> >> case it will work fine.
> >
> > I suggested the same to Stephen when he first brought up this driver.
> > Unfortunately his attempt to create a simple KMS driver resulted in a
> > significantly larger driver than the one he did for the framebuffer
> > interface. This means that either Stephen did something really wrong
> > in his attempt, or the KMS interface isn't as good as it should be
> > if we want to move people away from frame buffer drivers.
>
> Well, I didn't actually attempt to write the KMS driver; I simply took a
> look at existing KMS drivers (and perhaps some stub KMS driver; I forget
> right now) to see what it'd take, and it looked quite scary.
>
> The other issue is that the KMS semantics appear to desire that the
> driver allocate FB memory from some pool, and then point the display
> scanout at the allocated memory. However, this driver's semantics are
> that some other entity has allocated and reserved some memory region for
> scanout, and the simple FB driver exists solely to scribble to that
> memory region. Rob Clark said the thought this could be handled by
> writing a custom memory allocator to support this, but it seemed a
> little pointless to write a whole memory allocator when the existing FB
> interface allows the driver to just set a struct member to the address
> and be done with it.
KMS handles frame buffers through two objects, a GEM object that represents a
piece of memory and a frame buffer object that represents, well, a frame
buffer :-)
GEM objects management requires an allocator, and frame buffers reference one
or more GEM objects to model the frame buffer memory. As allocating new GEM
objects isn't possible in this case, the driver could create a GEM object and
a frame buffer at initialization time, and implement GEM allocation stubs that
would simply return an error unconditionally.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 0/6] Davinci fbdev driver and enable it for DMx platform
From: Sekhar Nori @ 2013-05-03 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+V-a8sLD2dP1RLb8ibZDOsLCP8hhMNUTr-zzU1zx_2ALDaDrg@mail.gmail.com>
On 4/26/2013 11:16 AM, Prabhakar Lad wrote:
> Hi Laurent,
>
> On Thu, Apr 25, 2013 at 2:32 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>> Hi Prabhakar,
>>
>> Thank you for the patch.
>>
>> On Wednesday 24 April 2013 17:30:02 Prabhakar Lad wrote:
>>> From: Lad, Prabhakar <prabhakar.csengg@gmail.com>
>>>
>>> This patch series adds an fbdev driver for Texas
>>> Instruments Davinci SoC.The display subsystem consists
>>> of OSD and VENC, with OSD supporting 2 RGb planes and
>>> 2 video planes.
>>> http://focus.ti.com/general/docs/lit/
>>> getliterature.tsp?literatureNumber=sprue37d&fileType=pdf
>>>
>>> A good amount of the OSD and VENC enabling code is
>>> present in the kernel, and this patch series adds the
>>> fbdev interface.
>>>
>>> The fbdev driver exports 4 nodes representing each
>>> plane to the user - from fb0 to fb3.
>>
>> The obvious question is: why not a KMS driver instead ? :-)
>>
> I did go through the KMS model (thanks for pointing to your work and the video)
> and it looks like this would require a fair amount of development, at this point
> of time I would go with the current implementation and revisit on KMS model
> at later point of time.
But I doubt you will be able to sneak a new fbdev driver through. Last
time I heard, Andrew is only taking in fixes not new features.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Dave Airlie @ 2013-05-03 5:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <517FAF0C.1060901@ti.com>
>
> I think it would be reasonable to have a restriction of only a single
> bootfb instance, so one could just use static global variables/funcs to
> manage the hand-over.
>
> All this, of course, presumes that nobody else than fbcon is using the
> fb. But I think it's also a reasonable restriction that the fb device is
> not used (mmapped) by anyone.
>
We already have this on x86, though the handover isn't great,
FBINFO_MISC_FIRMWARE flag, and the aperture tracking stuff.
Dave.
^ permalink raw reply
* Re: [PATCH 8/9] s3c2410fb: Remove redundant platform_set_drvdata()
From: Sylwester Nawrocki @ 2013-05-02 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000001ce46f6$54f27cc0$fed77640$@samsung.com>
Hi Jingoo,
On 05/02/2013 07:31 AM, Jingoo Han wrote:
> On Saturday, April 27, 2013 5:02 AM, Sylwester Nawrocki wrote:
>> > driver_data field is being cleared by the driver core since
>> > commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
>> > device-core: Ensure drvdata = NULL when no driver is bound
>> > hence there is no need to do it in the driver's remove() callback.
> How about eliminating platform_set_drvdata(pdev, NULL)
> in s3c24xxfb_probe() as well as s3c2410fb_remove()?
Ah, thanks for pointing out. Indeed, that could be dropped too, I've
overlooked it somehow. Will update and resend this patch shortly.
Regards,
Sylwester
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Geert Uytterhoeven @ 2013-05-02 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5182AF83.4080705@wwwdotorg.org>
On Thu, May 2, 2013 at 8:25 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 04/29/2013 04:04 PM, Arnd Bergmann wrote:
>> On Monday 29 April 2013, Laurent Pinchart wrote:
>>> On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
>>>
>>>> Good point. Stephen, would it be a problem to make this a KMS driver
>>>> instead? Old fbdev API could be emulated on top of it, until it goes out
>>>> of use, couldn't it?
>>>
>>> There's already an fbdev emulation layer in KMS, for such a simple use case it
>>> will work fine.
>>
>> I suggested the same to Stephen when he first brought up this driver.
>> Unfortunately his attempt to create a simple KMS driver resulted in a
>> significantly larger driver than the one he did for the framebuffer
>> interface. This means that either Stephen did something really wrong
>> in his attempt, or the KMS interface isn't as good as it should be
>> if we want to move people away from frame buffer drivers.
>
> Well, I didn't actually attempt to write the KMS driver; I simply took a
> look at existing KMS drivers (and perhaps some stub KMS driver; I forget
> right now) to see what it'd take, and it looked quite scary.
>
> The other issue is that the KMS semantics appear to desire that the
> driver allocate FB memory from some pool, and then point the display
> scanout at the allocated memory. However, this driver's semantics are
> that some other entity has allocated and reserved some memory region for
> scanout, and the simple FB driver exists solely to scribble to that
> memory region. Rob Clark said the thought this could be handled by
> writing a custom memory allocator to support this, but it seemed a
> little pointless to write a whole memory allocator when the existing FB
> interface allows the driver to just set a struct member to the address
> and be done with it.
I'm also curious to see the code for the first real simplekms/vesakms/ofkms/...
driver...
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: [PATCH V2] video: implement a simple framebuffer driver
From: Stephen Warren @ 2013-05-02 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201304300004.20320.arnd@arndb.de>
On 04/29/2013 04:04 PM, Arnd Bergmann wrote:
> On Monday 29 April 2013, Laurent Pinchart wrote:
>> On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
>>
>>> Good point. Stephen, would it be a problem to make this a KMS driver
>>> instead? Old fbdev API could be emulated on top of it, until it goes out
>>> of use, couldn't it?
>>
>> There's already an fbdev emulation layer in KMS, for such a simple use case it
>> will work fine.
>
> I suggested the same to Stephen when he first brought up this driver.
> Unfortunately his attempt to create a simple KMS driver resulted in a
> significantly larger driver than the one he did for the framebuffer
> interface. This means that either Stephen did something really wrong
> in his attempt, or the KMS interface isn't as good as it should be
> if we want to move people away from frame buffer drivers.
Well, I didn't actually attempt to write the KMS driver; I simply took a
look at existing KMS drivers (and perhaps some stub KMS driver; I forget
right now) to see what it'd take, and it looked quite scary.
The other issue is that the KMS semantics appear to desire that the
driver allocate FB memory from some pool, and then point the display
scanout at the allocated memory. However, this driver's semantics are
that some other entity has allocated and reserved some memory region for
scanout, and the simple FB driver exists solely to scribble to that
memory region. Rob Clark said the thought this could be handled by
writing a custom memory allocator to support this, but it seemed a
little pointless to write a whole memory allocator when the existing FB
interface allows the driver to just set a struct member to the address
and be done with it.
^ permalink raw reply
* Re: [PATCH 8/9] s3c2410fb: Remove redundant platform_set_drvdata()
From: Jingoo Han @ 2013-05-02 5:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1367006543-5458-9-git-send-email-sylvester.nawrocki@gmail.com>
On Saturday, April 27, 2013 5:02 AM, Sylwester Nawrocki wrote:
> driver_data field is being cleared by the driver core since
> commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
> device-core: Ensure drvdata = NULL when no driver is bound
> hence there is no need to do it in the driver's remove() callback.
>
> Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
> ---
> drivers/video/s3c2410fb.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/s3c2410fb.c b/drivers/video/s3c2410fb.c
> index 11f98ca..0439ed0 100644
> --- a/drivers/video/s3c2410fb.c
> +++ b/drivers/video/s3c2410fb.c
> @@ -1013,7 +1013,6 @@ static int s3c2410fb_remove(struct platform_device *pdev)
> irq = platform_get_irq(pdev, 0);
> free_irq(irq, info);
>
> - platform_set_drvdata(pdev, NULL);
> framebuffer_release(fbinfo);
Hi Sylwester,
How about eliminating platform_set_drvdata(pdev, NULL)
in s3c24xxfb_probe() as well as s3c2410fb_remove()?
@@ -1005,7 +1005,6 @@ release_regs:
release_mem:
release_mem_region(res->start, size);
dealloc_fb:
- platform_set_drvdata(pdev, NULL);
framebuffer_release(fbinfo);
return ret;
}
Best regards,
Jingoo Han
>
> return 0;
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/10] OMAPDSS: Basic deferred probe support
From: Tony Lindgren @ 2013-05-01 16:55 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-fbdev, linux-omap, grygorii.strashko, chf.fritz,
Archit Taneja
In-Reply-To: <1367230957-32337-1-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [130429 03:28]:
> Hi,
>
> omapdss, omapfb and the panel drivers do not currently support deferred probe,
> which is causing the display drivers fail when booting with DT.
>
> This series adds very basic support for deferred probing, which hopefully fixes
> the issues for omap4 panda and sdp boards with the current kernel.
>
> Limitations:
>
> * Deferred probe support for omap_vout and omapdrm is still totally missing.
> * If it so happens that at omapfb probe time one panel has been probed, but
> another has been deferred, only the probed one will be used.
> * Only DPI, DSI and HDMI outputs have been fixed.
> * Some panel drivers may need modifications to support EPROBE_DEFER
>
> Patches based on linux-next, i.e. the latest omapdss stuff.
Great, these fix the issues at least for panda booted with DT.
Regards,
Tony
^ permalink raw reply
* Re: [alsa-devel] [PATCH] MAINTAINERS: Add linux-samsung-soc list to all related entries
From: Sylwester Nawrocki @ 2013-05-01 10:28 UTC (permalink / raw)
To: Mark Brown
Cc: Kyungmin Park, t.stanislaws, linux-fbdev, linux-samsung-soc,
linux, jy0922.shim, alsa-devel, sbkim73, sw0312.kim, jg1.han,
linux-mmc, Tomasz Figa, dri-devel, inki.dae, jtp.park, dh09.lee,
linux-arm-kernel, s.nawrocki, k.debski, linux-media
In-Reply-To: <20130430132755.GB1023@sirena.org.uk>
On 04/30/2013 03:27 PM, Mark Brown wrote:
> On Mon, Apr 22, 2013 at 03:23:29PM +0900, Kyungmin Park wrote:
>
>> I don't think it's not required, each tree has each own mailing list. don't
>> need to post all patches to samsung-soc list.
>
> It can be useful to get system level input on some stuff, I guess it
> mostly depends if the people on the generic list mind the extra traffic
> or if they find it useful.
I think this could also improve testing coverage, if more people are aware
of stuff going in through various mailing lists.
Also on a specific subsystem mailing lists yet another SoC specific patches
may not get enough attention, as people care most about the core subsystem
changes.
So I would in general encourage others to Cc linux-samsung-soc, even if the
$subject patch gets ignored.
I seriously doubt anyone would have ever been disturbed with additional
traffic on the list, with its current average of about 20..50 emails per
day.
^ permalink raw reply
* Re: Re[2]: [PATCH V2] video: implement a simple framebuffer driver
From: Arnd Bergmann @ 2013-04-30 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1367332685.945287573@f287.mail.ru>
On Tuesday 30 April 2013, Alexander Shiyan wrote:
> > On 04/04/2013 05:39 AM, Stephen Warren wrote:
> > > A simple frame-buffer describes a raw memory region that may be rendered
> > > to, with the assumption that the display hardware has already been set
> > > up to scan out from that buffer.
> > >
> > > This is useful in cases where a bootloader exists and has set up the
> > > display hardware, but a Linux driver doesn't yet exist for the display
> > > hardware.
> > >
> > > Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> ...
> > > + framebuffer {
> > > + compatible = "simple-framebuffer";
> > > + reg = <0x1d385000 (1600 * 1200 * 2)>;
> > > + width = <1600>;
> > > + height = <1200>;
> > > + stride = <(1600 * 2)>;
> > > + format = "r5g6b5";
> > > + };
> >
> > I'm not an expert on DT, but I think the point of DT is to describe the
> > hardware. This doesn't describe the hardware at all.
>
> On my incompetent opinion, "bpp" parameter can replace size of
> framebuffer and "stride". Is not it?
Not necessarily: you could have a stride that is larger than a line.
Arnd
^ permalink raw reply
* Re[2]: [PATCH V2] video: implement a simple f =?UTF-8?B?cmFtZWJ1ZmZlciBkc
From: Alexander Shiyan @ 2013-04-30 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <517F753F.5090909@ti.com>
PiBPbiAwNC8wNC8yMDEzIDA1OjM5IEFNLCBTdGVwaGVuIFdhcnJlbiB3cm90ZToKPiA+IEEgc2lt
cGxlIGZyYW1lLWJ1ZmZlciBkZXNjcmliZXMgYSByYXcgbWVtb3J5IHJlZ2lvbiB0aGF0IG1heSBi
ZSByZW5kZXJlZAo+ID4gdG8sIHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUgZGlzcGxheSBo
YXJkd2FyZSBoYXMgYWxyZWFkeSBiZWVuIHNldAo+ID4gdXAgdG8gc2NhbiBvdXQgZnJvbSB0aGF0
IGJ1ZmZlci4KPiA+IAo+ID4gVGhpcyBpcyB1c2VmdWwgaW4gY2FzZXMgd2hlcmUgYSBib290bG9h
ZGVyIGV4aXN0cyBhbmQgaGFzIHNldCB1cCB0aGUKPiA+IGRpc3BsYXkgaGFyZHdhcmUsIGJ1dCBh
IExpbnV4IGRyaXZlciBkb2Vzbid0IHlldCBleGlzdCBmb3IgdGhlIGRpc3BsYXkKPiA+IGhhcmR3
YXJlLgo+ID4gCj4gPiBTaWduZWQtb2ZmLWJ5OiBTdGVwaGVuIFdhcnJlbiA8c3dhcnJlbkB3d3dk
b3Rvcmcub3JnPgouLi4KPiA+ICsJZnJhbWVidWZmZXIgewo+ID4gKwkJY29tcGF0aWJsZSA9ICJz
aW1wbGUtZnJhbWVidWZmZXIiOwo+ID4gKwkJcmVnID0gPDB4MWQzODUwMDAgKDE2MDAgKiAxMjAw
ICogMik+Owo+ID4gKwkJd2lkdGggPSA8MTYwMD47Cj4gPiArCQloZWlnaHQgPSA8MTIwMD47Cj4g
PiArCQlzdHJpZGUgPSA8KDE2MDAgKiAyKT47Cj4gPiArCQlmb3JtYXQgPSAicjVnNmI1IjsKPiA+
ICsJfTsKPiAKPiBJJ20gbm90IGFuIGV4cGVydCBvbiBEVCwgYnV0IEkgdGhpbmsgdGhlIHBvaW50
IG9mIERUIGlzIHRvIGRlc2NyaWJlIHRoZQo+IGhhcmR3YXJlLiBUaGlzIGRvZXNuJ3QgZGVzY3Jp
YmUgdGhlIGhhcmR3YXJlIGF0IGFsbC4KCk9uIG15IGluY29tcGV0ZW50IG9waW5pb24sICJicHAi
IHBhcmFtZXRlciBjYW4gcmVwbGFjZSBzaXplIG9mCmZyYW1lYnVmZmVyIGFuZCAic3RyaWRlIi4g
SXMgbm90IGl0PwoKLS0tCg=
^ permalink raw reply
* Re: [alsa-devel] [PATCH] MAINTAINERS: Add linux-samsung-soc list to all related entries
From: Mark Brown @ 2013-04-30 13:27 UTC (permalink / raw)
To: Kyungmin Park
Cc: t.stanislaws, linux-fbdev, linux-samsung-soc, linux, jy0922.shim,
alsa-devel, sbkim73, sw0312.kim, jg1.han, linux-mmc, Tomasz Figa,
dri-devel, inki.dae, jtp.park, dh09.lee, linux-arm-kernel,
s.nawrocki, k.debski, linux-media
In-Reply-To: <CAH9JG2U7Qdq_xQbuqHu6PXzURS2fWwBC=HJmyrXT5n3n_pAa0w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
On Mon, Apr 22, 2013 at 03:23:29PM +0900, Kyungmin Park wrote:
> I don't think it's not required, each tree has each own mailing list. don't
> need to post all patches to samsung-soc list.
It can be useful to get system level input on some stuff, I guess it
mostly depends if the people on the generic list mind the extra traffic
or if they find it useful.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Laurent Pinchart @ 2013-04-30 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <517FAF78.1010306@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]
On Tuesday 30 April 2013 14:48:08 Tomi Valkeinen wrote:
> On 04/30/2013 02:42 PM, Laurent Pinchart wrote:
> > On Tuesday 30 April 2013 12:28:42 Arnd Bergmann wrote:
> >> On Tuesday 30 April 2013, Tomi Valkeinen wrote:
> >>> The bootloader would init the display hardware, the bootfb would give an
> >>> early /dev/fb0 for the kernel and userspace, and when the real display
> >>> driver is loaded, the bootfb would be unbound and the real driver would
> >>> take over.
> >
> > This could be done with a KMS driver as well ;-)
>
> Right, I forgot to mention that. I had it in mind also =).
>
> DRM has the same problem as fbdev with multi-arch and lots of display
> and panel drivers.
>
> Probably the same bootfb could be used for DRM also. Or do you see any
> benefit of having a "bootkms" driver, or such?
As part of the (long term) effort to deprecate fbdev I would of course prefer
a bootkms driver. The KMS fbdev emulation layer would provide fbdev
compatibility for free during the transition.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Tomi Valkeinen @ 2013-04-30 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1547536.Us4pVspuI2@avalon>
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]
On 04/30/2013 02:42 PM, Laurent Pinchart wrote:
> On Tuesday 30 April 2013 12:28:42 Arnd Bergmann wrote:
>> On Tuesday 30 April 2013, Tomi Valkeinen wrote:
>>> The bootloader would init the display hardware, the bootfb would give an
>>> early /dev/fb0 for the kernel and userspace, and when the real display
>>> driver is loaded, the bootfb would be unbound and the real driver would
>>> take over.
>
> This could be done with a KMS driver as well ;-)
Right, I forgot to mention that. I had it in mind also =).
DRM has the same problem as fbdev with multi-arch and lots of display
and panel drivers.
Probably the same bootfb could be used for DRM also. Or do you see any
benefit of having a "bootkms" driver, or such?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Tomi Valkeinen @ 2013-04-30 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201304301228.42245.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]
On 04/30/2013 01:28 PM, Arnd Bergmann wrote:
> On Tuesday 30 April 2013, Tomi Valkeinen wrote:
>
>> The bootloader would init the display hardware, the bootfb would give an
>> early /dev/fb0 for the kernel and userspace, and when the real display
>> driver is loaded, the bootfb would be unbound and the real driver would
>> take over.
>
> I think that's a great idea. What I'm not sure about is how that
> infrastructure for switching frame buffers would work and how hard
> it's to write.
I don't have any clear ideas either, just some vague ones:
I think the simplest option would be for the userspace to just unbind
the fbcon, then the bootfb device/driver, and then load the real driver.
I don't see why that would not work, but it's far from optimal. The fb
memory would become unallocated for a while, and the user could see
garbage on the display.
A proper hand-over would be more complex. So, I don't know... Maybe the
bootfb driver could have custom API for this. When the real driver is
loaded, it'd call the bootfb to get the fb memory, and to unbind the bootfb.
Would there be issues with passing the fb memory? If one uses dma_alloc,
the device is linked to the allocated memory, so I presume you can't
just pass that around and remove the original device.
Then again, dma_alloc would not be used here, as bootfb needs the fb
memory from a particular location, so I guess bootmem is needed here.
I think it would be reasonable to have a restriction of only a single
bootfb instance, so one could just use static global variables/funcs to
manage the hand-over.
All this, of course, presumes that nobody else than fbcon is using the
fb. But I think it's also a reasonable restriction that the fb device is
not used (mmapped) by anyone.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Laurent Pinchart @ 2013-04-30 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201304301228.42245.arnd@arndb.de>
On Tuesday 30 April 2013 12:28:42 Arnd Bergmann wrote:
> On Tuesday 30 April 2013, Tomi Valkeinen wrote:
> > The bootloader would init the display hardware, the bootfb would give an
> > early /dev/fb0 for the kernel and userspace, and when the real display
> > driver is loaded, the bootfb would be unbound and the real driver would
> > take over.
This could be done with a KMS driver as well ;-)
> I think that's a great idea. What I'm not sure about is how that
> infrastructure for switching frame buffers would work and how hard it's to
> write.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Arnd Bergmann @ 2013-04-30 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <517F753F.5090909@ti.com>
On Tuesday 30 April 2013, Tomi Valkeinen wrote:
> > + framebuffer {
> > + compatible = "simple-framebuffer";
> > + reg = <0x1d385000 (1600 * 1200 * 2)>;
> > + width = <1600>;
> > + height = <1200>;
> > + stride = <(1600 * 2)>;
> > + format = "r5g6b5";
> > + };
>
> I'm not an expert on DT, but I think the point of DT is to describe the
> hardware. This doesn't describe the hardware at all.
That's ok.
It's not uncommon to have settings in the device tree that describe how
hardware is set up. Other similar properties would be the line rate
of a serial port, or a keymap describing what each button is labeled.
They are not physical properties, but they are necessary platform specific
pieces of information that are not available otherwise.
Arnd
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Arnd Bergmann @ 2013-04-30 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <517F7245.2050606@iki.fi>
On Tuesday 30 April 2013, Tomi Valkeinen wrote:
> The bootloader would init the display hardware, the bootfb would give an
> early /dev/fb0 for the kernel and userspace, and when the real display
> driver is loaded, the bootfb would be unbound and the real driver would
> take over.
I think that's a great idea. What I'm not sure about is how that
infrastructure for switching frame buffers would work and how hard
it's to write.
Arnd
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Laurent Pinchart @ 2013-04-30 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMiCvBwck0Z6Nyo9zW=1=J=wjhJW68qNGMrN_8iim=8Srg@mail.gmail.com>
Hi Olof,
On Monday 29 April 2013 15:40:44 Olof Johansson wrote:
> On Mon, Apr 29, 2013 at 3:23 PM, Laurent Pinchart wrote:
> > On Tuesday 30 April 2013 00:04:20 Arnd Bergmann wrote:
> >> On Monday 29 April 2013, Laurent Pinchart wrote:
> >> > On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
> >> > > Good point. Stephen, would it be a problem to make this a KMS driver
> >> > > instead? Old fbdev API could be emulated on top of it, until it goes
> >> > > out of use, couldn't it?
> >> >
> >> > There's already an fbdev emulation layer in KMS, for such a simple use
> >> > case it will work fine.
> >>
> >> I suggested the same to Stephen when he first brought up this driver.
> >> Unfortunately his attempt to create a simple KMS driver resulted in a
> >> significantly larger driver than the one he did for the framebuffer
> >> interface. This means that either Stephen did something really wrong in
> >> his attempt, or the KMS interface isn't as good as it should be if we
> >> want to move people away from frame buffer drivers.
> >
> > Implementing a KMS driver requires a fair amount of code. The DRM/KMS
> > subsystem provides helpers that significantly reduce the driver size.
> > Those helpers have been designed around common use cases found in existing
> > KMS drivers.
> >
> > I'm pretty sure we will be able to add useful helpers for existing fbdev
> > drivers that will make porting them to KMS pretty easy, but that first
> > requires starting to port drivers to find out what common code could be
> > factored out.
>
> Meanwhile this tiny driver will allow us to use hardware that can't
> otherwise be used (because the proper graphics drivers for said hardware is
> _also_ stuck behind large reworks, i.e. common display framework, which has
> uncertain progress at this time).
Point taken :-)
> As Stephen mentioned in the original patch, this particular driver is very
> useful for Raspberry Pi. But it is also the best way forward (right now) for
> getting basic upstream usability out of the Samsung ARM-based Chromebook. As
> a matter of fact, as of this weekend linux-next boots on that platform with
> keyboard, trackpad, framebuffer and USB2.0 without a single out-of-tree
> patch. Getting the same functionality out of 3.10 would be very desirable.
>
> So, I clearly understand the desire to move over to a more modern framework.
> At the same time, there's definite value in merging this small driver while
> that's happening. Holding useful code hostage isn't always very productive.
I want to be clear about this, even though I believe we should put as much
effort as possible behind KMS drivers, I won't nack this patch. It has real
use cases and is useful, I'm just concerned it will get abused (but it's far
from being the only piece of code that could be subject to abuse).
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Tomi Valkeinen @ 2013-04-30 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]
On 04/04/2013 05:39 AM, Stephen Warren wrote:
> A simple frame-buffer describes a raw memory region that may be rendered
> to, with the assumption that the display hardware has already been set
> up to scan out from that buffer.
>
> This is useful in cases where a bootloader exists and has set up the
> display hardware, but a Linux driver doesn't yet exist for the display
> hardware.
>
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
> ---
> v2: s/dumb/simple/ throughout. Provide more details on pixel format.
>
> I ended up going with a separate FB driver:
> * DRM/KMS look much more complex, and don't provide any benefit that I can
> tell for this simple driver.
> * Creating a separate driver rather than adjusting offb.c to work allows a
> new clean binding to be defined, and doesn't require removing or ifdefing
> PPC-isms in offb.c.
> ---
> .../bindings/video/simple-framebuffer.txt | 25 +++
> drivers/video/Kconfig | 17 ++
> drivers/video/Makefile | 1 +
> drivers/video/simplefb.c | 234 ++++++++++++++++++++
> 4 files changed, 277 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer.txt
> create mode 100644 drivers/video/simplefb.c
>
> diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> new file mode 100644
> index 0000000..3ea4605
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
> @@ -0,0 +1,25 @@
> +Simple Framebuffer
> +
> +A simple frame-buffer describes a raw memory region that may be rendered to,
> +with the assumption that the display hardware has already been set up to scan
> +out from that buffer.
> +
> +Required properties:
> +- compatible: "simple-framebuffer"
> +- reg: Should contain the location and size of the framebuffer memory.
> +- width: The width of the framebuffer in pixels.
> +- height: The height of the framebuffer in pixels.
> +- stride: The number of bytes in each line of the framebuffer.
> +- format: The format of the framebuffer surface. Valid values are:
> + - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
> +
> +Example:
> +
> + framebuffer {
> + compatible = "simple-framebuffer";
> + reg = <0x1d385000 (1600 * 1200 * 2)>;
> + width = <1600>;
> + height = <1200>;
> + stride = <(1600 * 2)>;
> + format = "r5g6b5";
> + };
I'm not an expert on DT, but I think the point of DT is to describe the
hardware. This doesn't describe the hardware at all.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Tomi Valkeinen @ 2013-04-30 7:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2863648.BDvrAG5uPk@flatron>
[-- Attachment #1: Type: text/plain, Size: 646 bytes --]
On 04/30/2013 12:15 AM, Tomasz Figa wrote:
> Well, there is also at least one legitimate use case for this driver.
>
> I believe there exist embedded devices on which there is no need to
> dynamically control the framebuffer. It needs one time initialization,
> usually in bootloader, and then it is used as is, using constant
> parameters as long as the system is running.
>
> I doubt there is a need for any KMS (or any other control) driver for such
> devices - dumb framebuffer driver would be everything needed in such case.
Isn't there usually the need to power off the hardware when
blanking/suspending?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Tomi Valkeinen @ 2013-04-30 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1365043183-28905-1-git-send-email-swarren@wwwdotorg.org>
Hi,
On 04/04/2013 05:39 AM, Stephen Warren wrote:
> A simple frame-buffer describes a raw memory region that may be rendered
> to, with the assumption that the display hardware has already been set
> up to scan out from that buffer.
>
> This is useful in cases where a bootloader exists and has set up the
> display hardware, but a Linux driver doesn't yet exist for the display
> hardware.
I had an idea related to this driver. There are two requirements that I
believe are (or will be) quite common:
On embedded devices quite often the bootloader initializes the display,
with the purpose of having a valid image on the screen for the whole
boot up process (company logo, or whatever).
With multi-arch kernels, we'll have display drivers for all platforms
and panels compiled with the kernel. If all these are built-in, they
will possibly increase the kernel size quite a bit, so it would be good
to have the display drivers as modules.
Now, if we have the display drivers as modules, the point when the
kernel/userspace can update the screen will be pretty late. Also,
there's no chance to get any early kernel boot messages on the screen.
So how about if we had this kind of simple fb, built-in to the kernel,
used only for the boot time until the proper driver is loaded. A "bootfb".
The bootloader would init the display hardware, the bootfb would give an
early /dev/fb0 for the kernel and userspace, and when the real display
driver is loaded, the bootfb would be unbound and the real driver would
take over.
Tomi
^ permalink raw reply
* Re: [PATCH V2] video: implement a simple framebuffer driver
From: Olof Johansson @ 2013-04-29 22:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2040099.REU8D4ds1g@avalon>
On Mon, Apr 29, 2013 at 3:23 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Arnd,
>
> On Tuesday 30 April 2013 00:04:20 Arnd Bergmann wrote:
>> On Monday 29 April 2013, Laurent Pinchart wrote:
>> > On Monday 29 April 2013 23:31:30 Tomasz Figa wrote:
>> > > Good point. Stephen, would it be a problem to make this a KMS driver
>> > > instead? Old fbdev API could be emulated on top of it, until it goes out
>> > > of use, couldn't it?
>> >
>> > There's already an fbdev emulation layer in KMS, for such a simple use
>> > case it will work fine.
>>
>> I suggested the same to Stephen when he first brought up this driver.
>> Unfortunately his attempt to create a simple KMS driver resulted in a
>> significantly larger driver than the one he did for the framebuffer
>> interface. This means that either Stephen did something really wrong in his
>> attempt, or the KMS interface isn't as good as it should be if we want to
>> move people away from frame buffer drivers.
>
> Implementing a KMS driver requires a fair amount of code. The DRM/KMS
> subsystem provides helpers that significantly reduce the driver size. Those
> helpers have been designed around common use cases found in existing KMS
> drivers.
>
> I'm pretty sure we will be able to add useful helpers for existing fbdev
> drivers that will make porting them to KMS pretty easy, but that first
> requires starting to port drivers to find out what common code could be
> factored out.
Meanwhile this tiny driver will allow us to use hardware that can't
otherwise be used (because the proper graphics drivers for said
hardware is _also_ stuck behind large reworks, i.e. common display
framework, which has uncertain progress at this time).
As Stephen mentioned in the original patch, this particular driver is
very useful for Raspberry Pi. But it is also the best way forward
(right now) for getting basic upstream usability out of the Samsung
ARM-based Chromebook. As a matter of fact, as of this weekend
linux-next boots on that platform with keyboard, trackpad, framebuffer
and USB2.0 without a single out-of-tree patch. Getting the same
functionality out of 3.10 would be very desirable.
So, I clearly understand the desire to move over to a more modern
framework. At the same time, there's definite value in merging this
small driver while that's happening. Holding useful code hostage isn't
always very productive.
-Olof
^ 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