This reverts commit b6fc28a158076ca2764edc9a6d1e1402f56e1c0c. It breaks
wireless AP reconnection on: (14e4:4727)
Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller
Any attempt to reconnect to an AP results in timeouts no matter how near to the
AP I am:
00:10:40 $nb kernel: wlan0:
Hi Piotr
On Mon, Mar 18, 2013 at 2:49 PM, Piotr Haber wrote:
> On 03/18/13 11:45, David Herrmann wrote:
>> This reverts commit b6fc28a158076ca2764edc9a6d1e1402f56e1c0c. It breaks
>> wireless AP reconnection on: (14e4:4727)
>> Broadcom Corporation BCM4313 802.11b/g/n Wi
o the target format while blitting.
Fast-paths for xrgb32/etc. could be implemented if we want to improve
blitting performance.
Signed-off-by: David Herrmann
---
Hi
This driver is a very basic DRM driver with roughly the same functionality as
vesafb but with a userspace API that doesn't s
Hi guys
On Mon, Feb 25, 2013 at 1:29 PM, Jiri Kosina wrote:
> On Mon, 25 Feb 2013, Benjamin Tissoires wrote:
>
>> Hi guys,
>>
>> this is the v2 of the hid transport cleanup.
>>
>> Changes since v1:
>> - gathered reviewed/acked/etc..
>> - changed commit messages of patches 4-6
>> - add newcomer in
ecated these and I haven't seen a Bluetooth device that
relies on it. Any reasons why I should implement them?
Also, for things like UHID I think we can safely drop this request.
Considering that, I think the patches can be applied as they are, so:
Reviewed-by: David Herrmann
The Bluetooth H
Hi
On Mon, Feb 25, 2013 at 4:06 PM, Benjamin Tissoires
wrote:
>> (I did read the Bluetooth HID Profile specification but I have no idea
>> how USB does it, so please bear with me if I mix things up. Maybe some
>> day I will have the time to read the USB specs, too)
>>
>> * There are several drive
Hi Dave
Sorry, I was busy reworking the HIDP layer. I finally got time to
continue my work on this again. See below:
On Mon, Feb 18, 2013 at 12:47 AM, Dave Airlie wrote:
[..snap..]
> As I said maybe I'm concentrating on the problem you aren't trying to fix,
> but then I'm not sure I've enough in
Hi Bruno
On Mon, Jul 30, 2012 at 9:36 PM, Bruno Prémont
wrote:
> Hi,
>
> This series updates picoLCD driver:
> - split the driver functions into separate files which get included
> depending on Kconfig selection
> (implementation for CIR using RC_CORE will follow later)
> - drop private frame
Hi Dmitry
On Fri, Sep 21, 2012 at 10:07 AM, Dmitry Torokhov
wrote:
> Thank you very much for working on this, unfortunately your patch extends the
> existing infrastructure handling of character devices in input core,
> which is quite rigid and sub-optimal.
>
> For a while now I wanted to stop in
Hi Dmitry
On Fri, Sep 21, 2012 at 10:51 PM, Dmitry Torokhov
wrote:
> On Friday, September 21, 2012 09:18:00 PM David Herrmann wrote:
>> Hi Dmitry
>>
>> On Fri, Sep 21, 2012 at 11:22 AM, David Herrmann
>>
>> wrote:
>> > Hi Dmitry
>> >
>
e);
> +}
> +
> +#else
> +
> +static inline void mousedev_psaux_register(void)
> +{
> +}
> +
> +static inline void mousedev_psaux_unregister(void)
> +{
> +}
> +
> #endif
>
> static int __init mousedev_init(void)
> {
> int error;
>
&g
Hi
On Tue, Aug 27, 2013 at 5:01 PM, David Barksdale wrote:
> This patch adds support for the Silicon Labs CP2112
> "Single-Chip HID USB to SMBus Master Bridge."
>
> I wrote this to support a USB temperature and humidity
> sensor I've been working on. It's been tested by using
> SMBus byte-read, b
Hi
On Tue, Oct 1, 2013 at 2:11 AM, Zachary Lund wrote:
> I apologize for poor assumptions and lack of general knowledge
> concerning what I'm talking about. However, I feel I can still help on
> the subject.
>
> As to what device I'm talking about, I'm talking about the more
> properly termed "Xb
mount, we extend it to also provide
anonymous inodes for use in drivers like DRM.
Signed-off-by: David Herrmann
Wanted-by: Daniel Vetter
---
Hi Linus & Al
Any chance I could get an ACK on this? It's fairly trivial and allows us to
simplify the DRM logic quite a bit (see patch 2/2
't
look very nice to ignore it silently.
Tested with nouveau on x86_64.
Signed-off-by: David Herrmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/ast/ast_ttm.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c| 2 +-
drivers/gpu/drm/drm_drv.c | 1 -
driver
ioremap_wc+0x32/0x40
i915_driver_load+0x670/0xf50 [i915]
...
Reported-by: Tom Gundersen
Signed-off-by: David Herrmann
Tested-by: Tom Gundersen
Tested-by: Pavel Roskin
---
Hi
Sorry for the delay, but I was in the US for the last 2 weeks and this is really
no major issue, just suppresses a war
e with the parent-device removal. Instead, we rely on
unregister_framebuffer() as barrier and we're safe.
Reported-by: Tom Gundersen
Signed-off-by: David Herrmann
---
Hi
I know that simplefb was supposed to stay "as simple as possible" but I really
think this series is the
Framebuffers shouldn't be cached and it is usually very uncommon to read
them. Therefore, use ioremap_wc() to get significant speed improvements on
systems which provide it. On all other systems it's aliased to
ioremap_nocache() which is also fine.
Reported-by: Tom Gundersen
Signed-off
Hi Tom
On Sun, Sep 8, 2013 at 11:38 AM, Tom Gundersen wrote:
> On Sun, Sep 8, 2013 at 2:13 AM, David Herrmann wrote:
>> Hi
>>
>> On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen wrote:
>>> Hi David,
>>>
>>> On Sat, Sep 7, 2013 at 11:57 PM, Tom Gunde
Hi
On Wed, Oct 2, 2013 at 6:16 PM, Stephen Warren wrote:
> On 10/02/2013 08:58 AM, David Herrmann wrote:
>> Unfortunately, fbdev does not create its own "struct device" for
>> framebuffers. Instead, it attaches to the device of the parent layer. This
>> has the
.
Signed-off-by: James Bates
Signed-off-by: David Herrmann
---
Hi
As James didn't respond to the last emails, I just rebased the patch and resent
it. The efi M_xyz constants were moved to x86-sysfb so if anyone wants to remove
unused bits, please send a separate patch to LKML and x86-ML.
dmi_list[i].base is null.
Signed-off-by: James Bates
Signed-off-by: David Herrmann
---
v3: fixes the "Author" field and James' email address
drivers/video/efifb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/efifb.c b/drivers/video/efifb.
ABI. To avoid any hacks in uinput, we simply introduce a new
uinput_user_dev2 to replace the old one. The new API allows growing
ABS_CNT2 values without any API changes.
Signed-off-by: David Herrmann
---
Hi
This is only compile-tested but I wanted to get a first revision out to let
people know w
Hi
On Tue, Jul 9, 2013 at 11:02 PM, Stephen Warren wrote:
> On 07/04/2013 06:25 AM, David Herrmann wrote:
>> Hi
>>
>> This series changes the way we handle firmware framebuffers on x86 systems.
>> On
>> other architectures the recently introduced "simple-fr
_inode, I'd be
happy to implement it. However, I didn't succeed and I am actually not sure that
separate "struct address_space" are actually supported. For instance, DRM core
uses code like:
container_of(dev_mapping, struct inode, i_data)
So I didn't spent much time on th
r what reason?), but I remember Daniel
told me that i810 might.
Tested with nouveau on x86_64.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_drv.c | 1 -
drivers/gpu/drm/drm_fops.c | 24 +++-
drivers/gpu/drm/drm_stub.c | 12 +
FS mount, we extend it to also provide
anonymous inodes for use in drivers like DRM.
Signed-off-by: David Herrmann
---
fs/anon_inodes.c| 36 +---
include/linux/anon_inodes.h | 1 +
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/f
BHID, I am fine with this. I never
read the USBHID specs, though, I rely on your comment here.
Anyway, code looks good:
Reviewed-by: David Herrmann
Thanks!
David
> Signed-off-by: Benjamin Tissoires
> ---
> net/bluetooth/hidp/core.c | 14 --
> 1 file changed, 14 de
return -1;
> + }
> +
> + hid_set_field(field, offset, value);
> +
> + return hidp_send_report(session, field->report);
> +}
> +
We had this discussion before (regarding uhid and hidpinput_event), it
would be nice to have a helper in hid-input.
Hi
On Thu, Jul 11, 2013 at 4:10 PM, Benjamin Tissoires
wrote:
> Hi David,
>
> On Thu, Jul 11, 2013 at 4:02 PM, David Herrmann wrote:
>> Hi
>>
>>> +static int hidp_hidinput_event(struct input_dev *dev, unsigned int type,
>>> +
Hi Tomi
On Thu, Sep 5, 2013 at 8:48 AM, Tomi Valkeinen wrote:
> Hi Linus,
>
> Here are the fbdev changes for 3.12.
>
> There's a conflict in drivers/video/simplefb.c, which you can resolve by using
> the version in your tree.
No, both need to be merged. The current version lacks support for
ABGR
VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>
> from the individual drivers' sections that already did this before.
Yepp, looks good. Maybe we should just drop it entirely. It's 200
lines of code and no additional dependencies. Anyway, nice catch:
Reviewed-by: David Herrmann
Thanks
D
Hi
On Tue, Sep 3, 2013 at 11:51 PM, David Barksdale wrote:
> On 08/29/2013 11:43 AM, David Herrmann wrote:
>>
>> Hi
>>
>> On Tue, Aug 27, 2013 at 5:01 PM, David Barksdale
>> wrote:
>>>
>>> This patch adds support for the Silicon Labs CP2
Hi
On Fri, Sep 6, 2013 at 11:32 AM, Tom Gundersen wrote:
> lfb_size can easily be say 4M, which would make the bitshit overflow and
> the test fail.
>
> Signed-off-by: Tom Gundersen
> Cc: David Herrmann
> Cc: H. Peter Anvin
> ---
> arch/x86/kernel/sysfb_simplefb.c | 2
Hi
On Fri, Sep 6, 2013 at 12:59 PM, Geert Uytterhoeven
wrote:
> On Fri, Sep 6, 2013 at 11:55 AM, David Herrmann wrote:
>> On Fri, Sep 6, 2013 at 11:32 AM, Tom Gundersen wrote:
>>> lfb_size can easily be say 4M, which would make the bitshit overflow and
>>> the test
Hi
On Fri, Sep 6, 2013 at 10:20 PM, Markus Trippelsdorf
wrote:
> On 2013.09.06 at 14:00 +0200, Jiri Kosina wrote:
>>
>> David Herrmann (12):
> ...
>> HID: wiimote: add support for Guitar-Hero drums
>
> commit 61e00655e9cb82e034eb72b95a51072e718d14a7
>
Hi
On Fri, Sep 6, 2013 at 11:59 PM, Markus Trippelsdorf
wrote:
> On 2013.09.06 at 23:50 +0200, David Herrmann wrote:
>> Hi
>>
>> On Fri, Sep 6, 2013 at 10:20 PM, Markus Trippelsdorf
>> wrote:
>> > On 2013.09.06 at 14:00 +0200, Jiri Kosina w
And this time also attached...
On Sat, Sep 7, 2013 at 9:31 AM, David Herrmann wrote:
> Hi
>
> On Sat, Sep 7, 2013 at 5:22 AM, Dmitry Torokhov
> wrote:
>> On Fri, Sep 06, 2013 at 06:00:29PM -0700, Linus Torvalds wrote:
>>> On Fri, Sep 6, 2013 at 5:58 PM,
. I believe you need to revert:
>
> 73f8645 HID: wiimote: add support for Guitar-Hero drums
> 61e0065 Input: introduce BTN/ABS bits for drums and guitars
>
> Hmm... there also was "HID: wiimote: add support for Guitar-Hero
> guitars" but I do not see it...
The commits to
Hi
On Sat, Sep 7, 2013 at 10:24 AM, Benjamin Tissoires
wrote:
> On Sat, Sep 7, 2013 at 9:31 AM, David Herrmann wrote:
>> Hi
>>
>> On Sat, Sep 7, 2013 at 5:22 AM, Dmitry Torokhov
>> wrote:
>>> On Fri, Sep 06, 2013 at 06:00:29PM -0700, Linus Torvalds wrote:
Hi
On Sat, Sep 7, 2013 at 11:20 AM, Benjamin Tissoires
wrote:
>
>
> On 07/09/13 10:57, David Herrmann wrote:
>> Hi
>>
>> On Sat, Sep 7, 2013 at 10:24 AM, Benjamin Tissoires
>>> I'm not particularly in favor of adding semantic between ABS_MISC and
>&
Hi Tom
On Fri, Sep 6, 2013 at 1:49 PM, Tom Gundersen wrote:
> This is similar to the output printed by efifb.
>
> Signed-off-by: Tom Gundersen
> Cc: Stephen Warren
> Cc: David Herrmann
> ---
>
> Hi,
>
> Sorry for the resend, got the ml address wrong.
>
>
Hi
On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen wrote:
> Hi guys,
>
> With current git (v3.11-5058-g57d7309) I get the following oops:
>
> [5.434312] [ cut here ]
> [5.434318] WARNING: CPU: 2 PID: 199 at arch/x86/mm/ioremap.c:171
> __ioremap_caller+0x2e3/0x390()
>
Hi
On Sat, Sep 7, 2013 at 3:45 PM, Tom Gundersen wrote:
> On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann wrote:
>> On Fri, Sep 6, 2013 at 2:10 PM, Tom Gundersen wrote:
>>> Hi guys,
>>>
>>> With current git (v3.11-5058-g57d7309) I get the following oops:
>
Hi Tom
On Sat, Sep 7, 2013 at 3:52 PM, David Herrmann wrote:
> Hi
>
> On Sat, Sep 7, 2013 at 3:45 PM, Tom Gundersen wrote:
>> On Sat, Sep 7, 2013 at 2:40 PM, David Herrmann wrote:
>>>
>>> It seems to be unrelated to the x86-sysfb changes. The WARN_ON
>&g
Hi Linus
On Sat, Sep 7, 2013 at 6:52 PM, Linus Torvalds
wrote:
> On Sat, Sep 7, 2013 at 12:31 AM, David Herrmann wrote:
>>
>> The bug only occurs for multi-touch devices (their ABS_* bits are
>>>0x1f), that's why I didn't see it happening during my tests..
&
Hi
On Sun, Sep 8, 2013 at 1:22 AM, Tom Gundersen wrote:
> Hi David,
>
> On Sat, Sep 7, 2013 at 11:57 PM, Tom Gundersen wrote:
>> On Sat, Sep 7, 2013 at 4:30 PM, David Herrmann wrote:
>>> Attached are two patches. The first one should fix this issue, the
>>> sec
Hi
On Fri, Jul 12, 2013 at 10:23 PM, Adam Borowski wrote:
> This is not a bug on our side, but a misdesign in ITU T.416, yet with
> all popular terminals supporting these codes, people consider this to
> be a bug in Linux. By breaking the design principles behind SGR codes
> (gracefully ignoring
ed to load uhid to know which minor it's going to use.
Hence, allocate a static minor (just like uinput does) and we're good
to go.
Reported-by: Tom Gundersen
Signed-off-by: David Herrmann
---
drivers/hid/uhid.c | 3 ++-
include/linux/miscdevice.h | 1 +
2 files changed, 3
Hi Tom
On Mon, Sep 9, 2013 at 5:43 PM, Tom Gundersen wrote:
> Hi Marcel,
>
> The above commit (60cbd53 in mainline) doesn't appear to work for me.
> I.e., depmod does not create an entry in modules.devname and hence no
> device node is created on boot.
>
> If I understand correctly, you'd also ne
Hi Adam
On Mon, Sep 9, 2013 at 6:46 PM, Adam Borowski wrote:
> On Mon, Sep 09, 2013 at 05:53:19PM +0200, David Herrmann wrote:
>> On Fri, Jul 12, 2013 at 10:23 PM, Adam Borowski wrote:
>> > + i++;
>> > + if (
Hi
On Thu, Sep 12, 2013 at 3:24 PM, Adam Borowski wrote:
> On Thu, Sep 12, 2013 at 02:37:26PM +0200, David Herrmann wrote:
>> On Mon, Sep 9, 2013 at 6:46 PM, Adam Borowski wrote:
>> > On Mon, Sep 09, 2013 at 05:53:19PM +0200, David Herrmann wrote:
>> > [...]
>
AM +1000, Peter Hutterer wrote:
>> >> > On Thu, Oct 03, 2013 at 12:10:36AM +0200, David Herrmann wrote:
>> >> > > As we painfully noticed during the 3.12 merge-window our
>> >> > > EVIOCGABS/EVIOCSABS API is limited to ABS_MAX<=0x3f. We tried
>> >
Hi
I'm not very familiar with the xbox-gamepad driver, but please see
below for some comments:
On Mon, Sep 23, 2013 at 2:34 AM, Zachary Lund wrote:
> I'm apologize ahead of time if this thread isn't appropriate, I'm not
> very familiar with mailing lists, especially lkml. I'm also very new
> to
.
>
> However this version doesn't work. Adding the hid_hw_open/hid_hw_close
> calls to cp2112_probe() as suggested by David Herrmann seems to have
> stopped events being delivered to cp2112_raw_event(). Why is that?
I suggest calling hid_hw_open() in _probe() and hid_hw_close() i
Hey Jiri
I forgot to put you on CC on the initial patch. Any comments on this?
Cheers
David
On Mon, Sep 9, 2013 at 6:51 PM, Tom Gundersen wrote:
> On Mon, Sep 9, 2013 at 6:33 PM, David Herrmann wrote:
>> udev has this nice feature of creating "dead" /dev/ device-nodes if
&g
fuse_dev_write+0x69/0x80
[] do_sync_readv_writev+0xdc/0x120
[] ? rw_copy_check_uvector+0x6b/0x130
[] ? handle_mm_fault+0x12e/0x1f0
[] do_readv_writev+0xd3/0x1e0
[] vfs_writev+0x30/0x60
[] sys_writev+0x48/0xb0
[] system_call_fastpath+0x16/0x1b
---[ end trace 368eb04507b14c94 ]---
Hi Tejun
On Mon, Nov 12, 2012 at 7:33 PM, Tejun Heo wrote:
> Hello, David.
>
> On Mon, Nov 12, 2012 at 05:15:48PM +0100, David Herrmann wrote:
>> We do not check whether we already registered a CUSE device with a given
>> name so we might end up with two devices with the
vfs_writev+0x30/0x60
[] sys_writev+0x48/0xb0
[] system_call_fastpath+0x16/0x1b
---[ end trace 368eb04507b14c94 ]---
Signed-off-by: David Herrmann
---
Hi again
I changed the spinlock to a mutex now. This should make it more readable as
Tejun suggested.
Thanks
David
fs/fuse/c
Hi Tejun
On Thu, Nov 15, 2012 at 3:44 PM, Tejun Heo wrote:
> On Thu, Nov 15, 2012 at 01:23:17PM +0100, David Herrmann wrote:
>> We do not check whether we already registered a CUSE device with a given
>> name so we might end up with two devices with the same name. Sysfs will
>
evice, we
need to protect the whole registration with a mutex.
Signed-off-by: David Herrmann
---
Hi
Changes in v2 include:
- move mutex-conversion into a separate patch
- check every list in the cuse_conntbl array, not only the current one
fs/fuse/cuse.c | 21 +++--
1 file ch
paths.
Signed-off-by: David Herrmann
---
Hi again
Sorry for the noise, but I think this time everything should work. I fixed the
name-check to check for all registered devices instead only one list.
And I split it into two patches.
Thanks for the reviews!
David
fs/fuse/cuse.c | 19
Hi
On Wed, Apr 17, 2013 at 11:05 PM, Byron Stanoszek wrote:
> David,
>
> I'm developing a small application that uses libdrm (DRM ioctls) to change
> the
> resolution of a single graphics display and show a framebuffer. I've run
> into
> two problems with this implementation that I'm hoping you c
ithout the wiimote specifics.
No user-space library is needed, but libxwiimote and xwiishow already include
support for it (if someone wants to integrate it into existing wiimote apps).
Cheers
David
David Herrmann (2):
input: document gamepad API and add extra keycodes
HID: wiimote: support Nint
. To avoid confusion, the action buttons now
have BTN_EAST/SOUTH/WEST/NORTH aliases.
Reported-by: Todd Showalter
Signed-off-by: David Herrmann
---
Documentation/input/gamepad.txt | 156
include/uapi/linux/input.h | 9 +++
2 files changed, 165
use hidraw to access these if you're
interested.
We might want to hook up the "charging" and "USB" bits to the battery
device so user-space can query whether it is currently charged via USB.
Signed-off-by: David Herrmann
---
drivers/hid/hid-wiimote-core.c| 23 +++
Use the new DRM infrastructure to kick out firmware drivers before probing
the real driver.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
kick out firmware DRM drivers. Additionally, unlike the
fbdev equivalent, DRM firmware drivers can now query the system whether a
real hardware driver is already loaded and prevent loading themselves.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_pci.c | 1 +
drivers
make the VT layer
happy. This needs to be fixed soon! Otherwise, we need a "depends !VT"
line for SimpleDRM.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/simpledrm/Kconfig | 11 ++
drivers/gpu/drm/simpledrm/Makefile | 4 +
drivers/gpu/drm/simpledrm/s
it is not needed. The headers
provide proper dummies for the case OF is disabled.
Furthermore, we move the FORMAT-definitions to the common platform header
so initialization code can use it to transform "struct screen_info" to
the right format-name.
Signed-off-by: David Herrmann
--
uffer.
Cheers
David
David Herrmann (6):
fbdev: simplefb: add init through platform_data
x86: provide platform-devices for boot-framebuffers
drm: add SimpleDRM driver
drm: simpledrm: add fbdev fallback support
drm: add helpers to kick out firmware drivers
drm: nouveau: kick out fir
. The buffer is
directly mapped into user-space, so we have only resources for a single
buffer. Otherwise, shadow buffers plus damage-request would be needed.
Signed-off-by: David Herrmann
---
MAINTAINERS| 8 +
drivers/gpu/drm/Kconfig| 2
ibility (if
strange formats are used), we still allow vesafb/efifb to be loaded
simultaneously and pick up all remaining devices.
Signed-off-by: David Herrmann
---
arch/x86/Kconfig | 18 ++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/sysfb.c | 157
ysfb_efi.c, too? We
could make the DMI table __init then.
I tested this (including DRM handover) with vesafb, efifb and simpledrm. It all
worked well without problems. More testing is highly welcome! Also feel free
to pickup individual fixes which don't directly depend on the series (eg. #
for VGA/vesa/EFI framebuffers, but is also of great use for all other
systems.
Especially with x86 support for simplefb, this information is needed to
unload simplefb before a real hw-driver (like i915, radeon, nouveau) is
loaded.
Signed-off-by: David Herrmann
---
drivers/video/simplefb.c | 10
. The buffer is
directly mapped into user-space, so we have only resources for a single
buffer. Otherwise, shadow buffers plus damage-request would be needed.
Signed-off-by: David Herrmann
---
MAINTAINERS| 8 +
drivers/gpu/drm/Kconfig| 2
invalidate the firmware framebuffer. Otherwise, simpledrm
could be loaded again, after a real hw-driver was unloaded (which is
very unlikely to work, except if hw-drivers reset fw FBs during unload).
Note that fbdev doesn't provide such protection against late driver
probing.
Signed-off-by: David Her
Create a simple fbdev device during SimpleDRM setup so legacy user-space
and fbcon can use it.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/simpledrm/Kconfig | 11 ++
drivers/gpu/drm/simpledrm/Makefile | 1 +
drivers/gpu/drm/simpledrm/simpledrm.h | 22
and I couldn't figure out why. Hence, lets just require
console-unbinding so fbdev hotplugging works with fbcon.
Signed-off-by: David Herrmann
---
drivers/video/console/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/console/Kconfig b/drivers/
Instead of creating a dummy device, we now bind to the efi-fb device
which is provided by x86 initialization code.
Signed-off-by: David Herrmann
---
drivers/video/efifb.c | 68 +--
1 file changed, 22 insertions(+), 46 deletions(-)
diff --git a
it is not needed. The headers
provide proper dummies for the case OF is disabled.
Furthermore, we move the FORMAT-definitions to the common platform header
so initialization code can use it to transform "struct screen_info" to
the right format-name.
Signed-off-by: David Herrmann
--
Use the new DRM infrastructure to kick out firmware drivers before probing
the real driver.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
The EFI FB quirks from efifb.c are useful for simple-framebuffer devices
as well. Apply them by default so we can convert efifb.c to use
efi-framebuffer platform devices.
Signed-off-by: David Herrmann
---
arch/x86/include/asm/sysfb.h | 57 +++
arch/x86/kernel/Makefile | 1 +
arch
and
provide a generic simple-framebuffer. For backwards-compatibility (if
strange formats are used), we still allow vesafb/efifb to be loaded
simultaneously and pick up all remaining devices.
Signed-off-by: David Herrmann
---
arch/x86/Kconfig | 26 +++
arch/x86/in
Kick out firmware DRM and fbdev drivers via the new
drm_kick_out_firmware() before loading radeon.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/radeon/radeon_drv.c | 28
drivers/gpu/drm/radeon/radeon_kms.c | 30 ++
2 files changed
32bit XRGB and ARGB are used by modern x86 systems for EFI and VESA
framebuffers. Add both variants so simplefb can be used on such systems.
Signed-off-by: David Herrmann
---
include/linux/platform_data/simplefb.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/platform_data
Use the new DRM infrastructure to kick out firmware DRM drivers before
loading i915.
Signed-off-by: David Herrmann
---
drivers/gpu/drm/i915/i915_dma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
x86 creates platform-framebuffer platform devices for every system
framebuffer. Use these instead of creating a dummy device.
This requires us to remove the __init annotations as hotplugging may occur
during runtime.
Signed-off-by: David Herrmann
---
drivers/video/vesafb.c | 55
Hi
On Thu, Jul 4, 2013 at 7:48 PM, H. Peter Anvin wrote:
> On 07/04/2013 05:25 AM, David Herrmann wrote:
>>
>> - What FB formats are common on x86 that we should add to
>> SIMPLEFB_FORMATS?
>> (other than ARGB/XRGB32)
>
>
> The common pixel formats on x8
Hi
On Tue, Jun 25, 2013 at 3:05 AM, Andy Lutomirski wrote:
> On 06/24/2013 03:27 PM, David Herrmann wrote:
>> + sdrm->fb_map = ioremap(sdrm->fb_base, sdrm->fb_size);
>
> This should probably be ioremap_wc. Otherwise it will be *really* slow
> if used in l
Hi
On Wed, Jun 26, 2013 at 10:58 PM, Stephen Warren wrote:
> On 06/24/2013 04:27 PM, David Herrmann wrote:
>> The SimpleDRM driver binds to simple-framebuffer devices and provides a
>> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
>>
Hi
On Wed, Jun 26, 2013 at 10:39 PM, Stephen Warren wrote:
> On 06/24/2013 04:27 PM, David Herrmann wrote:
>> If we create proper platform-devices in x86 boot-code, we can use simplefb
>> for VBE or EFI framebuffers, too. However, there is normally no OF support
>&
Hi
On Wed, Jun 26, 2013 at 10:49 PM, Stephen Warren wrote:
> On 06/24/2013 04:27 PM, David Herrmann wrote:
>> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
>> x86 causes troubles when loading multiple fbdev drivers. The global
>> "struct scr
Hi
On Wed, Jun 26, 2013 at 10:59 PM, Stephen Warren wrote:
> On 06/24/2013 04:27 PM, David Herrmann wrote:
>> Create a simple fbdev device during SimpleDRM setup so legacy user-space
>> and fbcon can use it.
>>
>> fbdev deletion is quite buggy. A unregister_framebuf
Hi
On Wed, Jun 26, 2013 at 11:30 PM, Stephen Warren wrote:
> On 06/24/2013 04:27 PM, David Herrmann wrote:
>> Hi
>>
>> This is my second revision of the dvbe driver. I renamed it to SimpleDRM to
>> show the resemblence with the recently introduced simplefb.c fbdev d
Hi
On Thu, Jun 27, 2013 at 11:47 AM, Jiri Kosina wrote:
> On Wed, 26 Jun 2013, Dmitry Torokhov wrote:
>
>> On Sat, Jun 15, 2013 at 03:32:44PM +0200, David Herrmann wrote:
>> > --- a/include/uapi/linux/input.h
>> > +++ b/include/uapi/linux/input.h
>
Hi
On Wed, Jun 26, 2013 at 5:45 PM,
wrote:
> Hi,
>
> The idea was to make the creation of an empty hid device while inside the
> kernel easier. This problem came up, when I was writing a kernel module
> driver for a usb temperature sensor. The sensors were supposed to be
> recognized in lm-sensor
implicitly
> initialized items
> in the dmi_list array, the null dereference does not occur, my customer
> command-line arg is
> parsed correctly, and my console displays correctly.
>
> Signed-off-by: James Bates
(CC'ing hpa)
Yepp, this patch looks good:
Reviewed-by: David H
b4
>> [] __driver_attach+0x4e/0x6f
>> [] bus_for_each_dev+0x57/0x8a
>> [] driver_attach+0x19/0x1b
>> [] bus_add_driver+0xde/0x201
>> [] driver_register+0x8c/0x110
>> [] platform_driver_register+0x41/0x43
>> [] platform_driver_probe+0x18/0x8a
&g
Hi
On Fri, Aug 16, 2013 at 10:19 PM, James Bates wrote:
> On Fri, 2013-08-16 at 15:37 +0200, David Herrmann wrote:
>
> Hi
> (CC'ing hpa)
>
> Yepp, this patch looks good:
> Reviewed-by: David Herrmann
>
> However, I'd like to see some code to prevent this fr
1 - 100 of 809 matches
Mail list logo
