* [PATCH 0/2] video: da8xx-fb trival cleanup
From: Lad Prabhakar @ 2013-05-16 7:22 UTC (permalink / raw)
To: DLOS, LFBDEV, Florian Tobias Schandinat; +Cc: LKML, Lad, Prabhakar
From: Lad, Prabhakar <prabhakar.csengg@gmail.com>
This patch series cleans the header inclusion and uses devm_* api
in the driver.
This patch series applies on 3.10-rc1 and is only boot
tested enabling FB driver.
Lad, Prabhakar (2):
video: da8xx-fb: remove unwanted header inclusion and sort the
alphabetically
video:da8xx-fb: Convert to devm_* api
drivers/video/da8xx-fb.c | 62 ++++++++++++---------------------------------
1 files changed, 17 insertions(+), 45 deletions(-)
--
1.7.4.1
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos_dp: Add parsing of gpios pins to exynos-dp driver
From: 한진구 @ 2013-05-16 2:04 UTC (permalink / raw)
To: Tomasz Figa, Vikas Sajjan
Cc: 한진구, linux-samsung-soc@vger.kernel.org,
김국진, devicetree-discuss@lists.ozlabs.org,
patches@linaro.org, linaro-kernel@lists.linaro.org,
rpurdie@rpsys.net, FlorianSchandinat@gmx.de,
linux-fbdev@vger.kernel.org
In-Reply-To: <1528008.HgBKZQmFTy@amdc1227>
VHVlc2RheSwgTWF5IDE0LCAyMDEzIDExOjE3IFBNLCBWaWthcyBTYWpqYW4gd3JvdGU6DQo+IA0K
PiBIaSBWaWthcywNCj4gDQo+IE9uIFR1ZXNkYXkgMTQgb2YgTWF5IDIwMTMgMTg6MjU6NTEgVmlr
YXMgU2FqamFuIHdyb3RlOg0KPiA+ICBBZGRzIEdQSU8gcGFyc2luZyBmdW5jdGlvbmFsaXR5IGZv
ciAiTENEIGJhY2tsaWdodCIgYW5kICJMQ0QgZW5hYmxlIg0KPiA+ICBHUElPIHBpbnMgb2YgZXh5
bm9zIGRwIGNvbnRyb2xsZXIuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBWaWthcyBTYWpqYW4g
PHZpa2FzLnNhamphbkBsaW5hcm8ub3JnPg0KPiA+IC0tLQ0KPiA+ICBkcml2ZXJzL3ZpZGVvL2V4
eW5vcy9leHlub3NfZHBfY29yZS5jIHwgICA0NQ0KPiA+ICsrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKyAxIGZpbGUgY2hhbmdlZCwgNDUgaW5zZXJ0aW9ucygrKQ0KPiA+DQo+IA0KPiBJ
IGRvbid0IHRoaW5rIHRoYXQgRXh5bm9zIERQIGRyaXZlciBpcyByaWdodCBwbGFjZSBmb3Igc3Vj
aCBjb2RlLiBCYWNrbGlnaHQNCj4gYW5kIExDRCBkcml2ZXJzIGFyZSByZXNwb25zaWJsZSBmb3Ig
YmFja2xpZ2h0IGFuZCBMQ0QgcG93ZXIgY29udHJvbCB1c2luZw0KPiBiYWNrbGlnaHQgYW5kIExD
RCBzdWJzeXN0ZW1zLg0KPiANCj4gSU1ITyB0aGUgY29ycmVjdCBzb2x1dGlvbiB3b3VsZCBiZSB0
byBlaXRoZXIgZXh0ZW5kIGV4aXN0aW5nIGJhY2tsaWdodC9sY2QNCj4gZHJpdmVycyBmb3VuZCBp
biBkcml2ZXJzL3ZpZGVvL2JhY2tsaWdodCB0byBzdXBwb3J0IGRpcmVjdCBHUElPIGNvbnRyb2wg
YW5kDQo+IHBhcnNlIEdQSU8gcGlucyBmcm9tIGRldmljZSB0cmVlIG9yIGNyZWF0ZSBuZXcgZ3Bp
b19ibCBhbmQgZ3Bpb19sY2QgZHJpdmVycy4NCg0KSGkgVmlrYXMgU2FqaWFuLA0KDQpJIGFncmVl
IHdpdGggVG9tYXN6IEZpZ2EncyBvcGluaW9uLg0KQmFja2xpZ2h0L0xDRCBmcmFtZXdvcmsgc2hv
dWxkIGJlIHVzZWQuDQplRFAgcGFuZWwgYmFja2xpZ2h0IG9uIFNNREs1MjEwIGJvYXJkIGNhbiBi
ZSBjb250cm9sbGVkIGJ5IFBXTTsNCnRodXMsIHB3bS1iYWNrbGlnaHQgZHJpdmVyIHNob3VsZCBi
ZSB1c2VkLg0KQWxzbywgZURQIHBhbmVsIHJlc2V0IHBpbiBzaG91bGQgYmUgY29udHJvbGxlZCBi
eSB1c2luZw0KcGxhdGZvcm0tbGNkIGRyaXZlci4NCg0KPiANCj4gQ0NpbmcgUmljaGFyZCwgRmxv
cmlhbiBhbmQgbGludXgtZmJkZXYuDQoNCkFsc28sIEkgaGF2ZSBiZWVuIGRvaW5nIGJhY2tsaWdo
dCByZXZpZXdzIGluc3RlYWQgb2YgUmljaGFyZCwNCnBsZWFzZSBkbyBDQydpbmcgbWUuDQoNCkJl
c3QgcmVnYXJkcywNCkppbmdvbyBIYW4NCg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBUb21hc3oN
Cg=
^ permalink raw reply
* [PATCH] video: Use less worrisome language in fbdev handoff
From: Adam Jackson @ 2013-05-15 21:04 UTC (permalink / raw)
To: linux-fbdev
For some reason people see "conflicting" and think it's a problem, even
though it's totally normal. Just call it a handoff.
Signed-off-by: Adam Jackson <ajax@redhat.com>
---
drivers/video/fbmem.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 098bfc6..2ec56a2 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1576,10 +1576,9 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
if (fb_do_apertures_overlap(gen_aper, a) ||
(primary && gen_aper && gen_aper->count &&
gen_aper->ranges[0].base = VGA_FB_PHYS)) {
-
- printk(KERN_INFO "fb: conflicting fb hw usage "
- "%s vs %s - removing generic driver\n",
- name, registered_fb[i]->fix.id);
+ printk(KERN_INFO "fb: Handoff from generic %s "
+ "driver to %s\n", registered_fb[i]->fix.id,
+ name);
do_unregister_framebuffer(registered_fb[i]);
}
}
--
1.8.2.1
^ permalink raw reply related
* Re: [PATCH v3 6/9] radeon: Switch to arch_phys_wc_add and add a missing ..._del
From: Andy Lutomirski @ 2013-05-15 18:22 UTC (permalink / raw)
To: Jerome Glisse
Cc: Alex Deucher, linux-kernel, dri-devel, linux-fbdev, Daniel Vetter,
Dave Airlie
In-Reply-To: <CAH3drwb743_q5ZrNDNsnOUUNVDMcefaq9NH3+t863OGc98-D-Q@mail.gmail.com>
On Wed, May 15, 2013 at 7:49 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
> On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
>>> On Tue, May 14, 2013 at 8:58 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>>> On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>>>>
>>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>>
>>> I believe it will break something but we could deal with the fallout
>>> once it happens.
>>
>> FWIW, I'm running with this code on my machine right now using the
>> radeon driver. Everything seems fine. If I build without MTRRs and
>> without PAT, though, graphics are slow (as expected). So I think
>> everything's okay.
>>
>> --Andy
>
> I am worried on p4 where i last see issue with that notably with agp.
Do you remember any details? It looks like PAT is enabled on Pentium
4 (i.e. famliy 0xF).
--Andy
^ permalink raw reply
* Re: fb driver for logiCVC
From: Bruno Prémont @ 2013-05-15 16:41 UTC (permalink / raw)
To: Davor Joja; +Cc: linux-kernel, linux-fbdev
In-Reply-To: <9D79B9A9194389468A922F618415D0A401229E7E@abc.xylon.local>
Hello Davor,
On Tue, 14 May 2013 "Davor Joja" wrote:
> Can I get suggestion how to send driver to this list which consists of
> several files and folders, as one (big) patch or as described in
> "how-to" as link to some ftp or git?
> My previous mail has not been replied, because of link to driver or
> other issue (tested on kernel 3.8)?
You should also send it to linux-fbdev (CCed) so interested people have
a better chance of seeing it (and quoting previous mail below).
If you have a git tree with history it might be nice. Otherwise it's
easier to review if you can split the big-patch into multiple incremental
parts adding some functionality each (that incremental nature would also
be expected from a git tree).
Your tree at https://github.com/logicbricks/linux_kernel looks weird,
you seem to have imported just the subfolders of kernel tree you worked
on instead of cloning e.g. v3.8 release and applying your driver on top
of it. This way it's not possible to merge your tree and it's rather hard
to find out what belongs to your driver or not.
Bruno
On Wed, 08 May 2013 "Davor Joja" wrote:
> I am sending link to frame buffer driver for Xylon "logiCVC" FPGA IP
> core, so I would kindly ask for driver review.
> logiCVC is Configurable Video Controller developed for Xilinx FPGA
> devices.
> logiCVC device together with xylonfb driver is widely used in Xilinx
> Targeted Referent Designs on Zynq SoC platforms (ZC702, ZC706, ZED, TED,
> Xilinx customers and Xilinx university program) and on custom projects
> from Xylon and Xylon customers.
>
> Driver implements platform and open firmware registration types.
> It has built in interface with V4L2 ADV7511 HDMI transmitter driver for
> handling EDID and miscellaneous clock generator SI570 driver.
> I would seek an advice for above mentioned and other issues which will
> get to surface in review.
>
> For now fb driver runs on 3.8 kernel (ARM architecture), and it was
> tested in all its configurations with:
> - Xylon test application
> - fbdev - Frame buffer device test application
> - DirectFB,
> - QT
> - Ubuntu 10.04 (16bpp and 32bpp color depth) Driver build was tested by
> Open Source Technology Center.
>
> Latest driver is available at
> https://github.com/logicbricks/linux_kernel.git under
> "drivers/video/xylon" and "include/linux" "Documentation (xylonfb
> devicetree parameters)"
> It is available on https://github.com/xilinx but not latest version.
>
> I have placed on ftp.logicbricks.com logiCVC datasheet, application
> note, current xylonfb driver user manual and test applications.
> Username: xylonfb
> Password: xylonfb
^ permalink raw reply
* Re: [PATCH v3 6/9] radeon: Switch to arch_phys_wc_add and add a missing ..._del
From: Jerome Glisse @ 2013-05-15 14:49 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Alex Deucher, linux-kernel, dri-devel, linux-fbdev, Daniel Vetter,
Dave Airlie
In-Reply-To: <CALCETrVo-6cnKZsDJnBJcwGjpPbW9QAYriyjAZavaZ8O2OkjnQ@mail.gmail.com>
On Tue, May 14, 2013 at 5:35 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
>> On Tue, May 14, 2013 at 8:58 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>>> On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>>>
>>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>>
>> I believe it will break something but we could deal with the fallout
>> once it happens.
>
> FWIW, I'm running with this code on my machine right now using the
> radeon driver. Everything seems fine. If I build without MTRRs and
> without PAT, though, graphics are slow (as expected). So I think
> everything's okay.
>
> --Andy
I am worried on p4 where i last see issue with that notably with agp.
Cheers,
Jerome
^ permalink raw reply
* Re: Introduce a new helper framework for buffer synchronization
From: Rob Clark @ 2013-05-15 14:06 UTC (permalink / raw)
To: Inki Dae
Cc: linux-fbdev, DRI mailing list, Kyungmin Park, myungjoo.ham,
YoungJun Cho, linux-arm-kernel, linux-media
In-Reply-To: <00cf01ce512b$bacc5540$3064ffc0$%dae@samsung.com>
On Wed, May 15, 2013 at 1:19 AM, Inki Dae <inki.dae@samsung.com> wrote:
>
>
>> -----Original Message-----
>> From: Rob Clark [mailto:robdclark@gmail.com]
>> Sent: Tuesday, May 14, 2013 10:39 PM
>> To: Inki Dae
>> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
>> Cho; linux-arm-kernel@lists.infradead.org; linux-media@vger.kernel.org
>> Subject: Re: Introduce a new helper framework for buffer synchronization
>>
>> On Mon, May 13, 2013 at 10:52 PM, Inki Dae <inki.dae@samsung.com> wrote:
>> >> well, for cache management, I think it is a better idea.. I didn't
>> >> really catch that this was the motivation from the initial patch, but
>> >> maybe I read it too quickly. But cache can be decoupled from
>> >> synchronization, because CPU access is not asynchronous. For
>> >> userspace/CPU access to buffer, you should:
>> >>
>> >> 1) wait for buffer
>> >> 2) prepare-access
>> >> 3) ... do whatever cpu access to buffer ...
>> >> 4) finish-access
>> >> 5) submit buffer for new dma-operation
>> >>
>> >
>> >
>> > For data flow from CPU to DMA device,
>> > 1) wait for buffer
>> > 2) prepare-access (dma_buf_begin_cpu_access)
>> > 3) cpu access to buffer
>> >
>> >
>> > For data flow from DMA device to CPU
>> > 1) wait for buffer
>>
>> Right, but CPU access isn't asynchronous (from the point of view of
>> the CPU), so there isn't really any wait step at this point. And if
>> you do want the CPU to be able to signal a fence from userspace for
>> some reason, you probably what something file/fd based so the
>> refcnting/cleanup when process dies doesn't leave some pending DMA
>> action wedged. But I don't really see the point of that complexity
>> when the CPU access isn't asynchronous in the first place.
>>
>
> There was my missing comments, please see the below sequence.
>
> For data flow from CPU to DMA device and then from DMA device to CPU,
> 1) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
> - including prepare-access (dma_buf_begin_cpu_access)
> 2) cpu access to buffer
> 3) wait for buffer <- at device driver
> - but CPU is already accessing the buffer so blocked.
> 4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...)
> 5) the thread, blocked at 3), is waked up by 4).
> - and then finish-access (dma_buf_end_cpu_access)
right, I understand you can have background threads, etc, in
userspace. But there are already plenty of synchronization primitives
that can be used for cpu->cpu synchronization, either within the same
process or between multiple processes. For cpu access, even if it is
handled by background threads/processes, I think it is better to use
the traditional pthreads or unix synchronization primitives. They
have existed forever, they are well tested, and they work.
So while it seems nice and orthogonal/clean to couple cache and
synchronization and handle dma->cpu and cpu->cpu and cpu->dma in the
same generic way, but I think in practice we have to make things more
complex than they otherwise need to be to do this. Otherwise I think
we'll be having problems with badly behaved or crashing userspace.
BR,
-R
> 6) dma access to buffer
> 7) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
> - but DMA is already accessing the buffer so blocked.
> 8) signal <- at device driver
> 9) the thread, blocked at 7), is waked up by 8)
> - and then prepare-access (dma_buf_begin_cpu_access)
> 10 cpu access to buffer
>
> Basically, 'wait for buffer' includes buffer synchronization, committing
> processing, and cache operation. The buffer synchronization means that a
> current thread should wait for other threads accessing a shared buffer until
> the completion of their access. And the committing processing means that a
> current thread possesses the shared buffer so any trying to access the
> shared buffer by another thread makes the thread to be blocked. However, as
> I already mentioned before, it seems that these user interfaces are so ugly
> yet. So we need better way.
>
> Give me more comments if there is my missing point :)
>
> Thanks,
> Inki Dae
>
>> BR,
>> -R
>>
>>
>> > 2) finish-access (dma_buf_end _cpu_access)
>> > 3) dma access to buffer
>> >
>> > 1) and 2) are coupled with one function: we have implemented
>> > fence_helper_commit_reserve() for it.
>> >
>> > Cache control(cache clean or cache invalidate) is performed properly
>> > checking previous access type and current access type.
>> > And the below is actual codes for it,
>
^ permalink raw reply
* Re: [PATCH] console/font: Refactor font support code selection logic
From: Hans Verkuil @ 2013-05-15 11:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Florian Tobias Schandinat, linux-fbdev, Ismael Luceno,
Thomas Winischhofer, Thomas Bogendoerfer, Helge Deller,
linux-media, devel, linux-usb, linux-kernel
In-Reply-To: <1368618050-26895-1-git-send-email-geert@linux-m68k.org>
On Wed 15 May 2013 13:40:50 Geert Uytterhoeven wrote:
> The current Makefile rules to build font support are messy and buggy.
> Replace them by Kconfig rules:
> - Introduce CONFIG_FONT_SUPPORT, which controls the building of all font
> code,
> - Select CONFIG_FONT_SUPPORT for all drivers that use fonts,
> - Select CONFIG_FONT_8x16 for all drivers that default to the VGA8x16
> font,
> - Drop the bogus console dependency for CONFIG_VIDEO_VIVI.
>
> This fixes (if CONFIG_SOLO6X10=y and there are no built-in console
> drivers):
>
> drivers/built-in.o: In function `solo_osd_print':
> drivers/staging/media/solo6x10/solo6x10-enc.c:144: undefined reference to `.find_font'
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
That looks much more sane. Thanks!
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
> ---
> drivers/media/platform/Kconfig | 2 +-
> drivers/staging/media/solo6x10/Kconfig | 2 ++
> drivers/usb/misc/sisusbvga/Kconfig | 1 +
> drivers/video/console/Kconfig | 12 ++++++++++--
> drivers/video/console/Makefile | 14 +++++---------
> 5 files changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 0cbe1ff..c1f29d5 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -220,7 +220,7 @@ if V4L_TEST_DRIVERS
> config VIDEO_VIVI
> tristate "Virtual Video Driver"
> depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64
> - depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
> + select FONT_SUPPORT
> select FONT_8x16
> select VIDEOBUF2_VMALLOC
> default n
> diff --git a/drivers/staging/media/solo6x10/Kconfig b/drivers/staging/media/solo6x10/Kconfig
> index ec32776..b34bb6c 100644
> --- a/drivers/staging/media/solo6x10/Kconfig
> +++ b/drivers/staging/media/solo6x10/Kconfig
> @@ -1,6 +1,8 @@
> config SOLO6X10
> tristate "Softlogic 6x10 MPEG codec cards"
> depends on PCI && VIDEO_DEV && SND && I2C
> + select FONT_SUPPORT
> + select FONT_8x16
> select VIDEOBUF2_DMA_SG
> select VIDEOBUF2_DMA_CONTIG
> select SND_PCM
> diff --git a/drivers/usb/misc/sisusbvga/Kconfig b/drivers/usb/misc/sisusbvga/Kconfig
> index 0d03a52..36bc28c 100644
> --- a/drivers/usb/misc/sisusbvga/Kconfig
> +++ b/drivers/usb/misc/sisusbvga/Kconfig
> @@ -2,6 +2,7 @@
> config USB_SISUSBVGA
> tristate "USB 2.0 SVGA dongle support (Net2280/SiS315)"
> depends on (USB_MUSB_HDRC || USB_EHCI_HCD)
> + select FONT_SUPPORT if USB_SISUSBVGA_CON
> ---help---
> Say Y here if you intend to attach a USB2VGA dongle based on a
> Net2280 and a SiS315 chip.
> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
> index bc922c4..baf27dc 100644
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@ -62,6 +62,7 @@ config MDA_CONSOLE
> config SGI_NEWPORT_CONSOLE
> tristate "SGI Newport Console support"
> depends on SGI_IP22
> + select FONT_SUPPORT
> help
> Say Y here if you want the console on the Newport aka XL graphics
> card of your Indy. Most people say Y here.
> @@ -91,6 +92,7 @@ config FRAMEBUFFER_CONSOLE
> tristate "Framebuffer Console support"
> depends on FB
> select CRC32
> + select FONT_SUPPORT
> help
> Low-level framebuffer-based console driver.
>
> @@ -123,12 +125,18 @@ config FRAMEBUFFER_CONSOLE_ROTATION
> config STI_CONSOLE
> bool "STI text console"
> depends on PARISC
> + select FONT_SUPPORT
> default y
> help
> The STI console is the builtin display/keyboard on HP-PARISC
> machines. Say Y here to build support for it into your kernel.
> The alternative is to use your primary serial port as a console.
>
> +config FONT_SUPPORT
> + tristate
> +
> +if FONT_SUPPORT
> +
> config FONTS
> bool "Select compiled-in fonts"
> depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
> @@ -158,7 +166,6 @@ config FONT_8x8
>
> config FONT_8x16
> bool "VGA 8x16 font" if FONTS
> - depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON
> default y if !SPARC && !FONTS
> help
> This is the "high resolution" font for the VGA frame buffer (the one
> @@ -226,7 +233,6 @@ config FONT_10x18
>
> config FONT_AUTOSELECT
> def_bool y
> - depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON
> depends on !FONT_8x8
> depends on !FONT_6x11
> depends on !FONT_7x14
> @@ -238,5 +244,7 @@ config FONT_AUTOSELECT
> depends on !FONT_10x18
> select FONT_8x16
>
> +endif # FONT_SUPPORT
> +
> endmenu
>
> diff --git a/drivers/video/console/Makefile b/drivers/video/console/Makefile
> index a862e91..3a11b63 100644
> --- a/drivers/video/console/Makefile
> +++ b/drivers/video/console/Makefile
> @@ -18,14 +18,14 @@ font-objs-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
>
> font-objs += $(font-objs-y)
>
> -# Each configuration option enables a list of files.
> +obj-$(CONFIG_FONT_SUPPORT) += font.o
>
> obj-$(CONFIG_DUMMY_CONSOLE) += dummycon.o
> -obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o font.o
> -obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o font.o
> +obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o
> +obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o
> obj-$(CONFIG_VGA_CONSOLE) += vgacon.o
> obj-$(CONFIG_MDA_CONSOLE) += mdacon.o
> -obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon.o bitblit.o font.o softcursor.o
> +obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon.o bitblit.o softcursor.o
> ifeq ($(CONFIG_FB_TILEBLITTING),y)
> obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += tileblit.o
> endif
> @@ -34,8 +34,4 @@ obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
> fbcon_ccw.o
> endif
>
> -obj-$(CONFIG_FB_STI) += sticore.o font.o
> -
> -ifeq ($(CONFIG_USB_SISUSBVGA_CON),y)
> -obj-$(CONFIG_USB_SISUSBVGA) += font.o
> -endif
> +obj-$(CONFIG_FB_STI) += sticore.o
>
^ permalink raw reply
* [PATCH] console/font: Refactor font support code selection logic
From: Geert Uytterhoeven @ 2013-05-15 11:40 UTC (permalink / raw)
To: Florian Tobias Schandinat, linux-fbdev
Cc: Hans Verkuil, Ismael Luceno, Thomas Winischhofer,
Thomas Bogendoerfer, Helge Deller, linux-media, devel, linux-usb,
linux-kernel, Geert Uytterhoeven
The current Makefile rules to build font support are messy and buggy.
Replace them by Kconfig rules:
- Introduce CONFIG_FONT_SUPPORT, which controls the building of all font
code,
- Select CONFIG_FONT_SUPPORT for all drivers that use fonts,
- Select CONFIG_FONT_8x16 for all drivers that default to the VGA8x16
font,
- Drop the bogus console dependency for CONFIG_VIDEO_VIVI.
This fixes (if CONFIG_SOLO6X10=y and there are no built-in console
drivers):
drivers/built-in.o: In function `solo_osd_print':
drivers/staging/media/solo6x10/solo6x10-enc.c:144: undefined reference to `.find_font'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
drivers/media/platform/Kconfig | 2 +-
drivers/staging/media/solo6x10/Kconfig | 2 ++
drivers/usb/misc/sisusbvga/Kconfig | 1 +
drivers/video/console/Kconfig | 12 ++++++++++--
drivers/video/console/Makefile | 14 +++++---------
5 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0cbe1ff..c1f29d5 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -220,7 +220,7 @@ if V4L_TEST_DRIVERS
config VIDEO_VIVI
tristate "Virtual Video Driver"
depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64
- depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
+ select FONT_SUPPORT
select FONT_8x16
select VIDEOBUF2_VMALLOC
default n
diff --git a/drivers/staging/media/solo6x10/Kconfig b/drivers/staging/media/solo6x10/Kconfig
index ec32776..b34bb6c 100644
--- a/drivers/staging/media/solo6x10/Kconfig
+++ b/drivers/staging/media/solo6x10/Kconfig
@@ -1,6 +1,8 @@
config SOLO6X10
tristate "Softlogic 6x10 MPEG codec cards"
depends on PCI && VIDEO_DEV && SND && I2C
+ select FONT_SUPPORT
+ select FONT_8x16
select VIDEOBUF2_DMA_SG
select VIDEOBUF2_DMA_CONTIG
select SND_PCM
diff --git a/drivers/usb/misc/sisusbvga/Kconfig b/drivers/usb/misc/sisusbvga/Kconfig
index 0d03a52..36bc28c 100644
--- a/drivers/usb/misc/sisusbvga/Kconfig
+++ b/drivers/usb/misc/sisusbvga/Kconfig
@@ -2,6 +2,7 @@
config USB_SISUSBVGA
tristate "USB 2.0 SVGA dongle support (Net2280/SiS315)"
depends on (USB_MUSB_HDRC || USB_EHCI_HCD)
+ select FONT_SUPPORT if USB_SISUSBVGA_CON
---help---
Say Y here if you intend to attach a USB2VGA dongle based on a
Net2280 and a SiS315 chip.
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index bc922c4..baf27dc 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -62,6 +62,7 @@ config MDA_CONSOLE
config SGI_NEWPORT_CONSOLE
tristate "SGI Newport Console support"
depends on SGI_IP22
+ select FONT_SUPPORT
help
Say Y here if you want the console on the Newport aka XL graphics
card of your Indy. Most people say Y here.
@@ -91,6 +92,7 @@ config FRAMEBUFFER_CONSOLE
tristate "Framebuffer Console support"
depends on FB
select CRC32
+ select FONT_SUPPORT
help
Low-level framebuffer-based console driver.
@@ -123,12 +125,18 @@ config FRAMEBUFFER_CONSOLE_ROTATION
config STI_CONSOLE
bool "STI text console"
depends on PARISC
+ select FONT_SUPPORT
default y
help
The STI console is the builtin display/keyboard on HP-PARISC
machines. Say Y here to build support for it into your kernel.
The alternative is to use your primary serial port as a console.
+config FONT_SUPPORT
+ tristate
+
+if FONT_SUPPORT
+
config FONTS
bool "Select compiled-in fonts"
depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
@@ -158,7 +166,6 @@ config FONT_8x8
config FONT_8x16
bool "VGA 8x16 font" if FONTS
- depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON
default y if !SPARC && !FONTS
help
This is the "high resolution" font for the VGA frame buffer (the one
@@ -226,7 +233,6 @@ config FONT_10x18
config FONT_AUTOSELECT
def_bool y
- depends on FRAMEBUFFER_CONSOLE || SGI_NEWPORT_CONSOLE || STI_CONSOLE || USB_SISUSBVGA_CON
depends on !FONT_8x8
depends on !FONT_6x11
depends on !FONT_7x14
@@ -238,5 +244,7 @@ config FONT_AUTOSELECT
depends on !FONT_10x18
select FONT_8x16
+endif # FONT_SUPPORT
+
endmenu
diff --git a/drivers/video/console/Makefile b/drivers/video/console/Makefile
index a862e91..3a11b63 100644
--- a/drivers/video/console/Makefile
+++ b/drivers/video/console/Makefile
@@ -18,14 +18,14 @@ font-objs-$(CONFIG_FONT_MINI_4x6) += font_mini_4x6.o
font-objs += $(font-objs-y)
-# Each configuration option enables a list of files.
+obj-$(CONFIG_FONT_SUPPORT) += font.o
obj-$(CONFIG_DUMMY_CONSOLE) += dummycon.o
-obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o font.o
-obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o font.o
+obj-$(CONFIG_SGI_NEWPORT_CONSOLE) += newport_con.o
+obj-$(CONFIG_STI_CONSOLE) += sticon.o sticore.o
obj-$(CONFIG_VGA_CONSOLE) += vgacon.o
obj-$(CONFIG_MDA_CONSOLE) += mdacon.o
-obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon.o bitblit.o font.o softcursor.o
+obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon.o bitblit.o softcursor.o
ifeq ($(CONFIG_FB_TILEBLITTING),y)
obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += tileblit.o
endif
@@ -34,8 +34,4 @@ obj-$(CONFIG_FRAMEBUFFER_CONSOLE) += fbcon_rotate.o fbcon_cw.o fbcon_ud.o \
fbcon_ccw.o
endif
-obj-$(CONFIG_FB_STI) += sticore.o font.o
-
-ifeq ($(CONFIG_USB_SISUSBVGA_CON),y)
-obj-$(CONFIG_USB_SISUSBVGA) += font.o
-endif
+obj-$(CONFIG_FB_STI) += sticore.o
--
1.7.0.4
^ permalink raw reply related
* RE: Introduce a new helper framework for buffer synchronization
From: Inki Dae @ 2013-05-15 5:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51909DB4.2060208@canonical.com>
> -----Original Message-----
> From: Rob Clark [mailto:robdclark@gmail.com]
> Sent: Tuesday, May 14, 2013 10:39 PM
> To: Inki Dae
> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
> Cho; linux-arm-kernel@lists.infradead.org; linux-media@vger.kernel.org
> Subject: Re: Introduce a new helper framework for buffer synchronization
>
> On Mon, May 13, 2013 at 10:52 PM, Inki Dae <inki.dae@samsung.com> wrote:
> >> well, for cache management, I think it is a better idea.. I didn't
> >> really catch that this was the motivation from the initial patch, but
> >> maybe I read it too quickly. But cache can be decoupled from
> >> synchronization, because CPU access is not asynchronous. For
> >> userspace/CPU access to buffer, you should:
> >>
> >> 1) wait for buffer
> >> 2) prepare-access
> >> 3) ... do whatever cpu access to buffer ...
> >> 4) finish-access
> >> 5) submit buffer for new dma-operation
> >>
> >
> >
> > For data flow from CPU to DMA device,
> > 1) wait for buffer
> > 2) prepare-access (dma_buf_begin_cpu_access)
> > 3) cpu access to buffer
> >
> >
> > For data flow from DMA device to CPU
> > 1) wait for buffer
>
> Right, but CPU access isn't asynchronous (from the point of view of
> the CPU), so there isn't really any wait step at this point. And if
> you do want the CPU to be able to signal a fence from userspace for
> some reason, you probably what something file/fd based so the
> refcnting/cleanup when process dies doesn't leave some pending DMA
> action wedged. But I don't really see the point of that complexity
> when the CPU access isn't asynchronous in the first place.
>
There was my missing comments, please see the below sequence.
For data flow from CPU to DMA device and then from DMA device to CPU,
1) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
- including prepare-access (dma_buf_begin_cpu_access)
2) cpu access to buffer
3) wait for buffer <- at device driver
- but CPU is already accessing the buffer so blocked.
4) signal <- at user side - ioctl(fd, DMA_BUF_PUT_FENCE, ...)
5) the thread, blocked at 3), is waked up by 4).
- and then finish-access (dma_buf_end_cpu_access)
6) dma access to buffer
7) wait for buffer <- at user side - ioctl(fd, DMA_BUF_GET_FENCE, ...)
- but DMA is already accessing the buffer so blocked.
8) signal <- at device driver
9) the thread, blocked at 7), is waked up by 8)
- and then prepare-access (dma_buf_begin_cpu_access)
10 cpu access to buffer
Basically, 'wait for buffer' includes buffer synchronization, committing
processing, and cache operation. The buffer synchronization means that a
current thread should wait for other threads accessing a shared buffer until
the completion of their access. And the committing processing means that a
current thread possesses the shared buffer so any trying to access the
shared buffer by another thread makes the thread to be blocked. However, as
I already mentioned before, it seems that these user interfaces are so ugly
yet. So we need better way.
Give me more comments if there is my missing point :)
Thanks,
Inki Dae
> BR,
> -R
>
>
> > 2) finish-access (dma_buf_end _cpu_access)
> > 3) dma access to buffer
> >
> > 1) and 2) are coupled with one function: we have implemented
> > fence_helper_commit_reserve() for it.
> >
> > Cache control(cache clean or cache invalidate) is performed properly
> > checking previous access type and current access type.
> > And the below is actual codes for it,
^ permalink raw reply
* [PATCH] ps3fb: Fix compile warning
From: Geoff Levand @ 2013-05-15 3:12 UTC (permalink / raw)
To: linux-fbdev
Fix the following compile warning when -Wparentheses is set:
drivers/video/ps3fb.c: warning: suggest parentheses around ‘+’ inside ‘<<’
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
Hi Florian,
Please apply.
-Geoff
drivers/video/ps3fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/ps3fb.c b/drivers/video/ps3fb.c
index d9f08c6..a397271d 100644
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -710,7 +710,7 @@ static int ps3fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
r = vm_iomap_memory(vma, info->fix.smem_start, info->fix.smem_len);
dev_dbg(info->device, "ps3fb: mmap framebuffer P(%lx)->V(%lx)\n",
- info->fix.smem_start + vma->vm_pgoff << PAGE_SHIFT,
+ (info->fix.smem_start + vma->vm_pgoff) << PAGE_SHIFT,
vma->vm_start);
return r;
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH v3 6/9] radeon: Switch to arch_phys_wc_add and add a missing ..._del
From: Andy Lutomirski @ 2013-05-14 21:35 UTC (permalink / raw)
To: Jerome Glisse
Cc: Alex Deucher, linux-kernel, dri-devel, linux-fbdev, Daniel Vetter,
Dave Airlie
In-Reply-To: <CAH3drwbSLdjd4Y8x8YfzhM5WK+A-L7mnYeS0kdqu7MwEB5kbCQ@mail.gmail.com>
On Tue, May 14, 2013 at 6:37 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
> On Tue, May 14, 2013 at 8:58 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>>
>> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
>
> I believe it will break something but we could deal with the fallout
> once it happens.
FWIW, I'm running with this code on my machine right now using the
radeon driver. Everything seems fine. If I build without MTRRs and
without PAT, though, graphics are slow (as expected). So I think
everything's okay.
--Andy
^ permalink raw reply
* Re: [PATCH V5 5/5] fbcon: queue work on power efficient wq
From: Tejun Heo @ 2013-05-14 17:57 UTC (permalink / raw)
To: Viresh Kumar
Cc: davem, airlied, axboe, tglx, peterz, mingo, rostedt,
linux-rt-users, linux-kernel, robin.randhawa, Steve.Bannister,
Liviu.Dudau, charles.garcia-tobin, arvind.chauhan, linaro-kernel,
patches, linux-fbdev
In-Reply-To: <89924f001e3ddd66ab41a16500569a976ea846fd.1366803121.git.viresh.kumar@linaro.org>
On Wed, Apr 24, 2013 at 05:12:57PM +0530, Viresh Kumar wrote:
> fbcon uses workqueues and it has no real dependency of scheduling these on the
> cpu which scheduled them.
>
> On a idle system, it is observed that and idle cpu wakes up many times just to
> service this work. It would be better if we can schedule it on a cpu which the
> scheduler believes to be the most appropriate one.
>
> This patch replaces system_wq with system_power_efficient_wq.
>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Dave, applied this to wq/for-3.11. Please holler if you want this to
be routed differently.
Thanks!
--
tejun
^ permalink raw reply
* Re: Build regressions/improvements in v3.10-rc1 (cris)
From: Jesper Nilsson @ 2013-05-14 16:33 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Kernel Development, Linux Fbdev development list,
linux-cris-kernel
In-Reply-To: <CAMuHMdW6p6tP=wwBNV9uAAbwwgpyzMiPxsBSJNOUazhznYC4iQ@mail.gmail.com>
On Tue, May 14, 2013 at 02:06:51PM +0200, Geert Uytterhoeven wrote:
> On Sun, May 12, 2013 at 10:44 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > drivers/video/console/fonts.c:71:2: error: #error No fonts configured.: 2 errors in 2 logs
> > v3.10-rc1/cris/cris-allmodconfig v3.10-rc1/cris/cris-allyesconfig
> >
> > Fbdev issue?
>
> This is caused by cris not using the generic drivers/Kconfig, and thus not
> traversing drivers/video/console/Kconfig.
> As the build system does traverse drivers/video/console/Makefile, fonts.c
> is compiled with an inconsistent configuration.
>
> Two solutions:
> 1. Add drivers/video/console/Kconfig to arch/cris/Kconfig,
> 2. Switch cris to drivers/Kconfig,
>
> I prefer two, as this is what's done by all (except h8300) other
> architectures. This will seriously broaden the scope of allmodconfig,
> though, and require more fixes (e.g. missing <asm/vga.h>).
I would have no objections a conversion of CRIS to use the
drivers/Kconfig, though it feels a bit strange to compile
video drivers for SoCs that don't have any video out hardware.
> Note: The decision logic for compiling drivers/video/console/fonts.c is
> overly complicated, and seems to be buggy for some stuff living
> outside drivers drivers/video (drivers/media/platform/vivi.c and
> drivers/staging/media/solo6x10/solo6x10-enc.c). I think this should
> be resolved in Kconfig logic, using a new FONT_SUPPORT
> symbol (FONTS is already taken).
>
> 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
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos_dp: Add parsing of gpios pins to exynos-dp driver
From: Tomasz Figa @ 2013-05-14 14:16 UTC (permalink / raw)
To: Vikas Sajjan
Cc: jg1.han, linux-samsung-soc, kgene.kim, devicetree-discuss,
patches, linaro-kernel, rpurdie, FlorianSchandinat, linux-fbdev
In-Reply-To: <1368536152-13370-2-git-send-email-vikas.sajjan@linaro.org>
Hi Vikas,
On Tuesday 14 of May 2013 18:25:51 Vikas Sajjan wrote:
> Adds GPIO parsing functionality for "LCD backlight" and "LCD enable"
> GPIO pins of exynos dp controller.
>
> Signed-off-by: Vikas Sajjan <vikas.sajjan@linaro.org>
> ---
> drivers/video/exynos/exynos_dp_core.c | 45
> +++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+)
>
I don't think that Exynos DP driver is right place for such code. Backlight
and LCD drivers are responsible for backlight and LCD power control using
backlight and LCD subsystems.
IMHO the correct solution would be to either extend existing backlight/lcd
drivers found in drivers/video/backlight to support direct GPIO control and
parse GPIO pins from device tree or create new gpio_bl and gpio_lcd drivers.
CCing Richard, Florian and linux-fbdev.
Best regards,
Tomasz
^ permalink raw reply
* Re: Introduce a new helper framework for buffer synchronization
From: Rob Clark @ 2013-05-14 13:38 UTC (permalink / raw)
To: Inki Dae
Cc: linux-fbdev, DRI mailing list, Kyungmin Park, myungjoo.ham,
YoungJun Cho, linux-arm-kernel, linux-media
In-Reply-To: <006a01ce504e$0de3b0e0$29ab12a0$%dae@samsung.com>
On Mon, May 13, 2013 at 10:52 PM, Inki Dae <inki.dae@samsung.com> wrote:
>> well, for cache management, I think it is a better idea.. I didn't
>> really catch that this was the motivation from the initial patch, but
>> maybe I read it too quickly. But cache can be decoupled from
>> synchronization, because CPU access is not asynchronous. For
>> userspace/CPU access to buffer, you should:
>>
>> 1) wait for buffer
>> 2) prepare-access
>> 3) ... do whatever cpu access to buffer ...
>> 4) finish-access
>> 5) submit buffer for new dma-operation
>>
>
>
> For data flow from CPU to DMA device,
> 1) wait for buffer
> 2) prepare-access (dma_buf_begin_cpu_access)
> 3) cpu access to buffer
>
>
> For data flow from DMA device to CPU
> 1) wait for buffer
Right, but CPU access isn't asynchronous (from the point of view of
the CPU), so there isn't really any wait step at this point. And if
you do want the CPU to be able to signal a fence from userspace for
some reason, you probably what something file/fd based so the
refcnting/cleanup when process dies doesn't leave some pending DMA
action wedged. But I don't really see the point of that complexity
when the CPU access isn't asynchronous in the first place.
BR,
-R
> 2) finish-access (dma_buf_end _cpu_access)
> 3) dma access to buffer
>
> 1) and 2) are coupled with one function: we have implemented
> fence_helper_commit_reserve() for it.
>
> Cache control(cache clean or cache invalidate) is performed properly
> checking previous access type and current access type.
> And the below is actual codes for it,
^ permalink raw reply
* Re: [PATCH v3 6/9] radeon: Switch to arch_phys_wc_add and add a missing ..._del
From: Jerome Glisse @ 2013-05-14 13:37 UTC (permalink / raw)
To: Alex Deucher
Cc: linux-fbdev, Daniel Vetter, linux-kernel, dri-devel,
Andy Lutomirski
In-Reply-To: <CADnq5_O6tZeRVq=gmJfn3JWQGgECSE1JuonpSKgFCYSD8RCqHQ@mail.gmail.com>
On Tue, May 14, 2013 at 8:58 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
I believe it will break something but we could deal with the fallout
once it happens.
>> ---
>> drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
>> index d3aface..15cd34b 100644
>> --- a/drivers/gpu/drm/radeon/radeon_object.c
>> +++ b/drivers/gpu/drm/radeon/radeon_object.c
>> @@ -321,8 +321,8 @@ void radeon_bo_force_delete(struct radeon_device *rdev)
>> int radeon_bo_init(struct radeon_device *rdev)
>> {
>> /* Add an MTRR for the VRAM */
>> - rdev->mc.vram_mtrr = mtrr_add(rdev->mc.aper_base, rdev->mc.aper_size,
>> - MTRR_TYPE_WRCOMB, 1);
>> + rdev->mc.vram_mtrr = arch_phys_wc_add(rdev->mc.aper_base,
>> + rdev->mc.aper_size);
>> DRM_INFO("Detected VRAM RAM=%lluM, BAR=%lluM\n",
>> rdev->mc.mc_vram_size >> 20,
>> (unsigned long long)rdev->mc.aper_size >> 20);
>> @@ -334,6 +334,7 @@ int radeon_bo_init(struct radeon_device *rdev)
>> void radeon_bo_fini(struct radeon_device *rdev)
>> {
>> radeon_ttm_fini(rdev);
>> + arch_phys_wc_del(rdev->mc.vram_mtrr);
>> }
>>
>> void radeon_bo_list_add_object(struct radeon_bo_list *lobj,
>> --
>> 1.8.1.4
>>
^ permalink raw reply
* Re: [PATCH v3 6/9] radeon: Switch to arch_phys_wc_add and add a missing ..._del
From: Alex Deucher @ 2013-05-14 12:58 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-kernel, dri-devel, linux-fbdev, Daniel Vetter,
Jerome Glisse, Dave Airlie
In-Reply-To: <bf7788cfd4695d05f2b414735744105906650e42.1368485053.git.luto@amacapital.net>
On Mon, May 13, 2013 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
> index d3aface..15cd34b 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -321,8 +321,8 @@ void radeon_bo_force_delete(struct radeon_device *rdev)
> int radeon_bo_init(struct radeon_device *rdev)
> {
> /* Add an MTRR for the VRAM */
> - rdev->mc.vram_mtrr = mtrr_add(rdev->mc.aper_base, rdev->mc.aper_size,
> - MTRR_TYPE_WRCOMB, 1);
> + rdev->mc.vram_mtrr = arch_phys_wc_add(rdev->mc.aper_base,
> + rdev->mc.aper_size);
> DRM_INFO("Detected VRAM RAM=%lluM, BAR=%lluM\n",
> rdev->mc.mc_vram_size >> 20,
> (unsigned long long)rdev->mc.aper_size >> 20);
> @@ -334,6 +334,7 @@ int radeon_bo_init(struct radeon_device *rdev)
> void radeon_bo_fini(struct radeon_device *rdev)
> {
> radeon_ttm_fini(rdev);
> + arch_phys_wc_del(rdev->mc.vram_mtrr);
> }
>
> void radeon_bo_list_add_object(struct radeon_bo_list *lobj,
> --
> 1.8.1.4
>
^ permalink raw reply
* Re: Build regressions/improvements in v3.10-rc1 (cris)
From: Geert Uytterhoeven @ 2013-05-14 12:06 UTC (permalink / raw)
To: Linux Kernel Development; +Cc: Cris, Linux Fbdev development list
In-Reply-To: <alpine.DEB.2.00.1305122242430.5463@ayla.of.borg>
On Sun, May 12, 2013 at 10:44 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> drivers/video/console/fonts.c:71:2: error: #error No fonts configured.: 2 errors in 2 logs
> v3.10-rc1/cris/cris-allmodconfig v3.10-rc1/cris/cris-allyesconfig
>
> Fbdev issue?
This is caused by cris not using the generic drivers/Kconfig, and thus not
traversing drivers/video/console/Kconfig.
As the build system does traverse drivers/video/console/Makefile, fonts.c
is compiled with an inconsistent configuration.
Two solutions:
1. Add drivers/video/console/Kconfig to arch/cris/Kconfig,
2. Switch cris to drivers/Kconfig,
I prefer two, as this is what's done by all (except h8300) other
architectures. This will seriously broaden the scope of allmodconfig,
though, and require more fixes (e.g. missing <asm/vga.h>).
Note: The decision logic for compiling drivers/video/console/fonts.c is
overly complicated, and seems to be buggy for some stuff living
outside drivers drivers/video (drivers/media/platform/vivi.c and
drivers/staging/media/solo6x10/solo6x10-enc.c). I think this should
be resolved in Kconfig logic, using a new FONT_SUPPORT
symbol (FONTS is already taken).
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] drivers: video: mxsfb: clean use of devm_ioremap_resource()
From: Laurent Navet @ 2013-05-14 9:25 UTC (permalink / raw)
To: FlorianSchandinat; +Cc: linux-fbdev, linux-kernel, Laurent Navet
Check of 'res' and calls to dev_err are already done in devm_ioremap_resource,
so no need to do them twice.
Signed-off-by: Laurent Navet <laurent.navet@gmail.com>
---
drivers/video/mxsfb.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 21223d4..0f3d0fc 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -884,9 +884,10 @@ static int mxsfb_probe(struct platform_device *pdev)
pdev->id_entry = of_id->data;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "Cannot get memory IO resource\n");
- return -ENODEV;
+ host->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(host->base)) {
+ ret = PTR_ERR(host->base);
+ goto fb_release;
}
fb_info = framebuffer_alloc(sizeof(struct mxsfb_info), &pdev->dev);
@@ -897,13 +898,6 @@ static int mxsfb_probe(struct platform_device *pdev)
host = to_imxfb_host(fb_info);
- host->base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(host->base)) {
- dev_err(&pdev->dev, "ioremap failed\n");
- ret = PTR_ERR(host->base);
- goto fb_release;
- }
-
host->pdev = pdev;
platform_set_drvdata(pdev, host);
--
1.7.10.4
^ permalink raw reply related
* RE: Introduce a new helper framework for buffer synchronization
From: Inki Dae @ 2013-05-14 2:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <51909DB4.2060208@canonical.com>
> -----Original Message-----
> From: Rob Clark [mailto:robdclark@gmail.com]
> Sent: Tuesday, May 14, 2013 2:58 AM
> To: Inki Dae
> Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
> Cho; linux-arm-kernel@lists.infradead.org; linux-media@vger.kernel.org
> Subject: Re: Introduce a new helper framework for buffer synchronization
>
> On Mon, May 13, 2013 at 1:18 PM, Inki Dae <inki.dae@samsung.com> wrote:
> >
> >
> > 2013/5/13 Rob Clark <robdclark@gmail.com>
> >>
> >> On Mon, May 13, 2013 at 8:21 AM, Inki Dae <inki.dae@samsung.com> wrote:
> >> >
> >> >> In that case you still wouldn't give userspace control over the
> fences.
> >> >> I
> >> >> don't see any way that can end well.
> >> >> What if userspace never signals? What if userspace gets killed by
> oom
> >> >> killer. Who keeps track of that?
> >> >>
> >> >
> >> > In all cases, all kernel resources to user fence will be released by
> >> > kernel
> >> > once the fence is timed out: never signaling and process killing by
> oom
> >> > killer makes the fence timed out. And if we use mmap mechanism you
> >> > mentioned
> >> > before, I think user resource could also be freed properly.
> >>
> >>
> >> I tend to agree w/ Maarten here.. there is no good reason for
> >> userspace to be *signaling* fences. The exception might be some blob
> >> gpu drivers which don't have enough knowledge in the kernel to figure
> >> out what to do. (In which case you can add driver private ioctls for
> >> that.. still not the right thing to do but at least you don't make a
> >> public API out of it.)
> >>
> >
> > Please do not care whether those are generic or not. Let's see the
> following
> > three things. First, it's cache operation. As you know, ARM SoC has ACP
> > (Accelerator Coherency Port) and can be connected to DMA engine or
> similar
> > devices. And this port is used for cache coherency between CPU cache and
> DMA
> > device. However, most devices on ARM based embedded systems don't use
> the
> > ACP port. So they need proper cache operation before and after of DMA or
> CPU
> > access in case of using cachable mapping. Actually, I see many Linux
> based
> > platforms call cache control interfaces directly for that. I think the
> > reason, they do so, is that kernel isn't aware of when and how CPU
> accessed
> > memory.
>
> I think we had kicked around the idea of giving dmabuf's a
> prepare/finish ioctl quite some time back. This is probably something
> that should be at least a bit decoupled from fences. (Possibly
> 'prepare' waits for dma access to complete, but not the other way
> around.)
>
> And I did implement in omapdrm support for simulating coherency via
> page fault-in / shoot-down.. It is one option that makes it
> completely transparent to userspace, although there is some
> performance const, so I suppose it depends a bit on your use-case.
>
> > And second, user process has to do so many things in case of using
> shared
> > memory with DMA device. User process should understand how DMA device is
> > operated and when interfaces for controling the DMA device are called.
> Such
> > things would make user application so complicated.
> >
> > And third, it's performance optimization to multimedia and graphics
> devices.
> > As I mentioned already, we should consider sequential processing for
> buffer
> > sharing between CPU and DMA device. This means that CPU should stay with
> > idle until DMA device is completed and vise versa.
> >
> > That is why I proposed such user interfaces. Of course, these interfaces
> > might be so ugly yet: for this, Maarten pointed already out and I agree
> with
> > him. But there must be another better way. Aren't you think we need
> similar
> > thing? With such interfaces, cache control and buffer synchronization
> can be
> > performed in kernel level. Moreover, user applization doesn't need to
> > consider DMA device controlling anymore. Therefore, one thread can
> access a
> > shared buffer and the other can control DMA device with the shared
> buffer in
> > parallel. We can really make the best use of CPU and DMA idle time. In
> other
> > words, we can really make the best use of multi tasking OS, Linux.
> >
> > So could you please tell me about that there is any reason we don't use
> > public API for it? I think we can add and use public API if NECESSARY.
>
> well, for cache management, I think it is a better idea.. I didn't
> really catch that this was the motivation from the initial patch, but
> maybe I read it too quickly. But cache can be decoupled from
> synchronization, because CPU access is not asynchronous. For
> userspace/CPU access to buffer, you should:
>
> 1) wait for buffer
> 2) prepare-access
> 3) ... do whatever cpu access to buffer ...
> 4) finish-access
> 5) submit buffer for new dma-operation
>
For data flow from CPU to DMA device,
1) wait for buffer
2) prepare-access (dma_buf_begin_cpu_access)
3) cpu access to buffer
For data flow from DMA device to CPU
1) wait for buffer
2) finish-access (dma_buf_end _cpu_access)
3) dma access to buffer
1) and 2) are coupled with one function: we have implemented
fence_helper_commit_reserve() for it.
Cache control(cache clean or cache invalidate) is performed properly
checking previous access type and current access type.
And the below is actual codes for it,
static void fence_helper_cache_ops(struct fence_helper *fh)
{
struct seqno_fence_dmabuf *sfd;
list_for_each_entry(sfd, &fh->sf.sync_buf_list, list) {
struct dma_buf *dmabuf = sfd->sync_buf;
if (WARN_ON(!dmabuf))
continue;
/* first time access. */
if (!dmabuf->access_type)
goto out;
if (dmabuf->access_type = DMA_BUF_ACCESS_WRITE &&
((fh->type = (DMA_BUF_ACCESS_READ |
DMA_BUF_ACCESS_DMA)) ||
(fh->type = (DMA_BUF_ACCESS_WRITE |
DMA_BUF_ACCESS_DMA))))
/* cache clean */
dma_buf_end_cpu_access(dmabuf, 0, dmabuf->size,
DMA_TO_DEVICE);
else if (dmabuf->access_type = (DMA_BUF_ACCESS_WRITE |
DMA_BUF_ACCESS_DMA) &&
(fh->type = DMA_BUF_ACCESS_READ))
/* cache invalidate */
dma_buf_begin_cpu_access(dmabuf, 0, dmabuf->size,
DMA_FROM_DEVICE);
out:
/* Update access type to new one. */
dmabuf->access_type = fh->type;
}
}
The above function is called after wait for buffer.
Thus, we can check who (CPU or DMA) and how (READ or WRITE) accessed and
accesses buffer with this approach. In other words, now kernel is aware of
buffer access by CPU also.
Thanks,
Inki Dae
> I suppose you could combine the syscall for #1 and #2.. not sure if
> that is a good idea or not. But you don't need to. And there is
> never really any need for userspace to signal a fence.
>
> BR,
> -R
>
> > Thanks,
> > Inki Dae
> >
> >>
> >> BR,
> >> -R
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
^ permalink raw reply
* RE: [PATCH 02/15] video: ep93xx: remove unnecessary platform_set_drvdata()
From: H Hartley Sweeten @ 2013-05-14 0:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <000201ce4e45$a5da7330$f18f5990$@samsung.com>
On Saturday, May 11, 2013 5:47 AM, Jingoo Han wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
> (device-core: Ensure drvdata = NULL when no driver is bound).
> Thus, it is not needed to manually clear the device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/video/ep93xx-fb.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* [PATCH v3 9/9] drm: Don't leak phys_wc "handles" to userspace
From: Andy Lutomirski @ 2013-05-13 23:58 UTC (permalink / raw)
To: linux-kernel, dri-devel, linux-fbdev
Cc: Daniel Vetter, Jerome Glisse, Alex Deucher, Dave Airlie,
Andy Lutomirski
In-Reply-To: <cover.1368485053.git.luto@amacapital.net>
I didn't fix this in the earlier patch -- it would have broken the
build due to the now-deleted garbage in drm_os_linux.h.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
drivers/gpu/drm/drm_bufs.c | 9 +++++++++
drivers/gpu/drm/drm_ioctl.c | 15 ++++++++++++++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 0190fce..5a4dbb4 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -414,6 +414,15 @@ int drm_addmap_ioctl(struct drm_device *dev, void *data,
/* avoid a warning on 64-bit, this casting isn't very nice, but the API is set so too late */
map->handle = (void *)(unsigned long)maplist->user_token;
+
+ /*
+ * It appears that there are no users of this value whatsoever --
+ * drmAddMap just discards it. Let's not encourage its use.
+ * (Keeping drm_addmap_core's returned mtrr value would be wrong --
+ * it's not a real mtrr index anymore.)
+ */
+ map->mtrr = -1;
+
return 0;
}
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index e77bd8b..ffd7a7b 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -38,6 +38,9 @@
#include <linux/pci.h>
#include <linux/export.h>
+#ifdef CONFIG_X86
+#include <asm/mtrr.h>
+#endif
/**
* Get the bus id.
@@ -181,7 +184,17 @@ int drm_getmap(struct drm_device *dev, void *data,
map->type = r_list->map->type;
map->flags = r_list->map->flags;
map->handle = (void *)(unsigned long) r_list->user_token;
- map->mtrr = r_list->map->mtrr;
+
+#ifdef CONFIG_X86
+ /*
+ * There appears to be exactly one user of the mtrr index: dritest.
+ * It's easy enough to keep it working on non-PAT systems.
+ */
+ map->mtrr = phys_wc_to_mtrr_index(r_list->map->mtrr);
+#else
+ map->mtrr = -1;
+#endif
+
mutex_unlock(&dev->struct_mutex);
return 0;
--
1.8.1.4
^ permalink raw reply related
* [PATCH v3 8/9] drm: Remove mtrr_add and mtrr_del fallback hack for non-MTRR systems
From: Andy Lutomirski @ 2013-05-13 23:58 UTC (permalink / raw)
To: linux-kernel, dri-devel, linux-fbdev
Cc: Daniel Vetter, Jerome Glisse, Alex Deucher, Dave Airlie,
Andy Lutomirski
In-Reply-To: <cover.1368485053.git.luto@amacapital.net>
There are no users left in drivers/gpu.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
include/drm/drmP.h | 5 +----
include/drm/drm_os_linux.h | 16 ----------------
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3e6cfa0..7a9fef5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -55,16 +55,13 @@
#include <linux/mm.h>
#include <linux/cdev.h>
#include <linux/mutex.h>
+#include <linux/io.h>
#include <linux/slab.h>
#if defined(__alpha__) || defined(__powerpc__)
#include <asm/pgtable.h> /* For pte_wrprotect */
#endif
-#include <asm/io.h>
#include <asm/mman.h>
#include <asm/uaccess.h>
-#ifdef CONFIG_MTRR
-#include <asm/mtrr.h>
-#endif
#if defined(CONFIG_AGP) || defined(CONFIG_AGP_MODULE)
#include <linux/types.h>
#include <linux/agp_backend.h>
diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h
index 3933691..35c7c2b 100644
--- a/include/drm/drm_os_linux.h
+++ b/include/drm/drm_os_linux.h
@@ -65,22 +65,6 @@ struct no_agp_kern {
#define DRM_AGP_KERN struct no_agp_kern
#endif
-#if !(__OS_HAS_MTRR)
-static __inline__ int mtrr_add(unsigned long base, unsigned long size,
- unsigned int type, char increment)
-{
- return -ENODEV;
-}
-
-static __inline__ int mtrr_del(int reg, unsigned long base, unsigned long size)
-{
- return -ENODEV;
-}
-
-#define MTRR_TYPE_WRCOMB 1
-
-#endif
-
/** Other copying of data to kernel space */
#define DRM_COPY_FROM_USER(arg1, arg2, arg3) \
copy_from_user(arg1, arg2, arg3)
--
1.8.1.4
^ permalink raw reply related
* [PATCH v3 7/9] uvesafb: Clean up MTRR code
From: Andy Lutomirski @ 2013-05-13 23:58 UTC (permalink / raw)
To: linux-kernel, dri-devel, linux-fbdev
Cc: Daniel Vetter, Jerome Glisse, Alex Deucher, Dave Airlie,
Andy Lutomirski
In-Reply-To: <cover.1368485053.git.luto@amacapital.net>
The old code allowed very strange memory types. Now it works like
all the other video drivers: ioremap_wc is used unconditionally,
and MTRRs are set if PAT is unavailable (unless MTRR is disabled
by a module parameter).
UC, WB, and WT support is gone. If there are MTRR conflicts that prevent
addition of a WC MTRR, adding a non-conflicting MTRR is pointless; it's
better to just turn off MTRR support entirely.
As an added bonus, any MTRR added is freed on unload.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
---
Documentation/fb/uvesafb.txt | 16 ++++------
drivers/video/uvesafb.c | 70 +++++++++++---------------------------------
include/video/uvesafb.h | 1 +
3 files changed, 23 insertions(+), 64 deletions(-)
diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt
index eefdd91..f6362d8 100644
--- a/Documentation/fb/uvesafb.txt
+++ b/Documentation/fb/uvesafb.txt
@@ -81,17 +81,11 @@ pmipal Use the protected mode interface for palette changes.
mtrr:n Setup memory type range registers for the framebuffer
where n:
- 0 - disabled (equivalent to nomtrr) (default)
- 1 - uncachable
- 2 - write-back
- 3 - write-combining
- 4 - write-through
-
- If you see the following in dmesg, choose the type that matches
- the old one. In this example, use "mtrr:2".
-...
-mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining
-...
+ 0 - disabled (equivalent to nomtrr)
+ 3 - write-combining (default)
+
+ Values other than 0 and 3 will result in a warning and will be
+ treated just like 3.
nomtrr Do not use memory type range registers.
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index d428445..8701f96 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -24,9 +24,6 @@
#ifdef CONFIG_X86
#include <video/vga.h>
#endif
-#ifdef CONFIG_MTRR
-#include <asm/mtrr.h>
-#endif
#include "edid.h"
static struct cb_id uvesafb_cn_id = {
@@ -1540,67 +1537,30 @@ static void uvesafb_init_info(struct fb_info *info, struct vbe_mode_ib *mode)
static void uvesafb_init_mtrr(struct fb_info *info)
{
-#ifdef CONFIG_MTRR
+ struct uvesafb_par *par = info->par;
+
if (mtrr && !(info->fix.smem_start & (PAGE_SIZE - 1))) {
int temp_size = info->fix.smem_len;
- unsigned int type = 0;
- switch (mtrr) {
- case 1:
- type = MTRR_TYPE_UNCACHABLE;
- break;
- case 2:
- type = MTRR_TYPE_WRBACK;
- break;
- case 3:
- type = MTRR_TYPE_WRCOMB;
- break;
- case 4:
- type = MTRR_TYPE_WRTHROUGH;
- break;
- default:
- type = 0;
- break;
- }
+ int rc;
- if (type) {
- int rc;
+ /* Find the largest power-of-two */
+ temp_size = roundup_pow_of_two(temp_size);
- /* Find the largest power-of-two */
- temp_size = roundup_pow_of_two(temp_size);
+ /* Try and find a power of two to add */
+ do {
+ rc = arch_phys_wc_add(info->fix.smem_start, temp_size);
+ temp_size >>= 1;
+ } while (temp_size >= PAGE_SIZE && rc = -EINVAL);
- /* Try and find a power of two to add */
- do {
- rc = mtrr_add(info->fix.smem_start,
- temp_size, type, 1);
- temp_size >>= 1;
- } while (temp_size >= PAGE_SIZE && rc = -EINVAL);
- }
+ if (rc >= 0)
+ par->mtrr_handle = rc;
}
-#endif /* CONFIG_MTRR */
}
static void uvesafb_ioremap(struct fb_info *info)
{
-#ifdef CONFIG_X86
- switch (mtrr) {
- case 1: /* uncachable */
- info->screen_base = ioremap_nocache(info->fix.smem_start, info->fix.smem_len);
- break;
- case 2: /* write-back */
- info->screen_base = ioremap_cache(info->fix.smem_start, info->fix.smem_len);
- break;
- case 3: /* write-combining */
- info->screen_base = ioremap_wc(info->fix.smem_start, info->fix.smem_len);
- break;
- case 4: /* write-through */
- default:
- info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
- break;
- }
-#else
- info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
-#endif /* CONFIG_X86 */
+ info->screen_base = ioremap_wc(info->fix.smem_start, info->fix.smem_len);
}
static ssize_t uvesafb_show_vbe_ver(struct device *dev,
@@ -1851,6 +1811,7 @@ static int uvesafb_remove(struct platform_device *dev)
unregister_framebuffer(info);
release_region(0x3c0, 32);
iounmap(info->screen_base);
+ arch_phys_wc_del(par->mtrr_handle);
release_mem_region(info->fix.smem_start, info->fix.smem_len);
fb_destroy_modedb(info->monspecs.modedb);
fb_dealloc_cmap(&info->cmap);
@@ -1930,6 +1891,9 @@ static int uvesafb_setup(char *options)
}
}
+ if (mtrr != 3 && mtrr != 1)
+ pr_warn("uvesafb: mtrr should be set to 0 or 3; %d is unsupported", mtrr);
+
return 0;
}
#endif /* !MODULE */
diff --git a/include/video/uvesafb.h b/include/video/uvesafb.h
index 1a91850..30f5362 100644
--- a/include/video/uvesafb.h
+++ b/include/video/uvesafb.h
@@ -134,6 +134,7 @@ struct uvesafb_par {
int mode_idx;
struct vbe_crtc_ib crtc;
+ int mtrr_handle;
};
#endif /* _UVESAFB_H */
--
1.8.1.4
^ permalink raw reply related
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