linux-toradex.git/include/linux/fb.h, branch T20_LinuxImageV2.0Beta1_20121218 Linux kernel for Apalis and Colibri modules HDMI stereo support - kernel code changes 2011-12-01T05:44:51+00:00 chzhang chzhang@nvidia.com 2011-02-11T09:40:11+00:00 7ffab3a960e618d89c696fb08b40187a8dc7fc7b Signed-off-by: Chong Zhang <chzhang@nvidia.com> Original-Change-Id: I53eea3b14852aecd589dfbd0461258e064835cc9 Reviewed-on: http://git-master/r/11405 Reviewed-by: Daniel Willemsen <dwillemsen@nvidia.com> Rebase-Id: R4c2c1bba6eeeee16cf3d99061717c236c695eaf7 
Signed-off-by: Chong Zhang <chzhang@nvidia.com>
Original-Change-Id: I53eea3b14852aecd589dfbd0461258e064835cc9
Reviewed-on: http://git-master/r/11405
Reviewed-by: Daniel Willemsen <dwillemsen@nvidia.com>

Rebase-Id: R4c2c1bba6eeeee16cf3d99061717c236c695eaf7
video: fbmon: add HDMI dectetion to fbmod edid parsing 2011-12-01T05:37:13+00:00 Erik Gilling konkers@android.com 2011-02-07T03:32:17+00:00 949e796a5a1ea149540adf576e2a11aa17712902 Looks for ieee registration number 0x000c03 as per HDMI spec. CEA-861-E section D.6.8. Change-Id: I6875b24c66e8754510edabcb4f9ba682a50d6ac1 Signed-off-by: Erik Gilling <konkers@android.com> Signed-off-by: Lajos Molnar <molnar@ti.com> 
Looks for ieee registration number 0x000c03 as per HDMI spec.
CEA-861-E section D.6.8.

Change-Id: I6875b24c66e8754510edabcb4f9ba682a50d6ac1
Signed-off-by: Erik Gilling <konkers@android.com>
Signed-off-by: Lajos Molnar <molnar@ti.com>
video: fbmon: Add support for CEA pixel ratios. 2011-12-01T05:37:13+00:00 Lajos Molnar molnar@ti.com 2011-09-09T21:44:13+00:00 1943fcae396cd22f86942171298d6fd7485bb123 CEA defines multiple timings with dual timing ratios that cannot be distinguished from timings parameters. Added 2 new fb flags to specify 4:3 or 16:9 display ratios. Also added a flag that denotes CEA formats that require repeating pixels. Change-Id: I75d413babdcb4048a0ccce6548ed386ad0e52318 Signed-off-by: Lajos Molnar <molnar@ti.com> 
CEA defines multiple timings with dual timing ratios that cannot
be distinguished from timings parameters.  Added 2 new fb flags
to specify 4:3 or 16:9 display ratios.

Also added a flag that denotes CEA formats that require repeating
pixels.

Change-Id: I75d413babdcb4048a0ccce6548ed386ad0e52318
Signed-off-by: Lajos Molnar <molnar@ti.com>
video: fbmon: add remaining modes to CEA mode database 2011-12-01T05:37:12+00:00 Erik Gilling konkers@android.com 2011-09-13T20:44:44+00:00 e3d3b3cadb615e3465d5d41d62bbc49346058d65 These mode are directly from the CEA-861-E spec. Change-Id: Ic29390fb8dfc4605da1f95aaee0e2e775dfc0a4a Signed-off-by: Erik Gilling <konkers@android.com> 
These mode are directly from the CEA-861-E spec.

Change-Id: Ic29390fb8dfc4605da1f95aaee0e2e775dfc0a4a
Signed-off-by: Erik Gilling <konkers@android.com>
Revert "video: fbmon: add HDMI dectetion to fbmod edid parsing" 2011-12-01T05:37:12+00:00 Erik Gilling konkers@android.com 2011-11-09T22:18:46+00:00 ec3038e4888abb61e42754c5a6e4b466792ab032 This reverts commit c326f06779fb6bdd7f92c3ede8d1bebbe2fafbfa. 
This reverts commit c326f06779fb6bdd7f92c3ede8d1bebbe2fafbfa.
video: fbmon: add HDMI dectetion to fbmod edid parsing 2011-12-01T05:36:57+00:00 Erik Gilling konkers@android.com 2011-02-07T03:32:17+00:00 cb5acd891d88529ccd75191577df4728d9081217 Looks for ieee registration numver 0x000c03 as per HDMI spec. Change-Id: I6875b24c66e8754510edabcb4f9ba682a50d6ac1 Signed-off-by: Erik Gilling <konkers@android.com> 
Looks for ieee registration numver 0x000c03 as per HDMI spec.

Change-Id: I6875b24c66e8754510edabcb4f9ba682a50d6ac1
Signed-off-by: Erik Gilling <konkers@android.com>
fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers 2011-07-21T00:47:59+00:00 Josef Bacik josef@redhat.com 2011-07-17T00:44:56+00:00 02c24a82187d5a628c68edfe71ae60dc135cd178 Btrfs needs to be able to control how filemap_write_and_wait_range() is called in fsync to make it less of a painful operation, so push down taking i_mutex and the calling of filemap_write_and_wait() down into the ->fsync() handlers. Some file systems can drop taking the i_mutex altogether it seems, like ext3 and ocfs2. For correctness sake I just pushed everything down in all cases to make sure that we keep the current behavior the same for everybody, and then each individual fs maintainer can make up their mind about what to do from there. Thanks, Acked-by: Jan Kara <jack@suse.cz> Signed-off-by: Josef Bacik <josef@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
Btrfs needs to be able to control how filemap_write_and_wait_range() is called
in fsync to make it less of a painful operation, so push down taking i_mutex and
the calling of filemap_write_and_wait() down into the ->fsync() handlers.  Some
file systems can drop taking the i_mutex altogether it seems, like ext3 and
ocfs2.  For correctness sake I just pushed everything down in all cases to make
sure that we keep the current behavior the same for everybody, and then each
individual fs maintainer can make up their mind about what to do from there.
Thanks,

Acked-by: Jan Kara <jack@suse.cz>
Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
fbcon: add lifetime refcount to opened frame buffers 2011-05-12T14:37:51+00:00 Linus Torvalds torvalds@linux-foundation.org 2011-05-11T21:49:36+00:00 698b368275c3fa98261159253cfc79653f9dffc6 This just adds the refcount and the new registration lock logic. It does not (for example) actually change the read/write/ioctl routines to actually use the frame buffer that was opened: those function still end up alway susing whatever the current frame buffer is at the time of the call. Without this, if something holds the frame buffer open over a framebuffer switch, the close() operation after the switch will access a fb_info that has been free'd by the unregistering of the old frame buffer. (The read/write/ioctl operations will normally not cause problems, because they will - illogically - pick up the new fbcon instead. But a switch that happens just as one of those is going on might see problems too, the window is just much smaller: one individual op rather than the whole open-close sequence.) This use-after-free is apparently fairly easily triggered by the Ubuntu 11.04 boot sequence. Acked-by: Tim Gardner <tim.gardner@canonical.com> Tested-by: Daniel J Blueman <daniel.blueman@gmail.com> Tested-by: Anca Emanuel <anca.emanuel@gmail.com> Cc: Bruno Prémont <bonbons@linux-vserver.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
This just adds the refcount and the new registration lock logic.  It
does not (for example) actually change the read/write/ioctl routines to
actually use the frame buffer that was opened: those function still end
up alway susing whatever the current frame buffer is at the time of the
call.

Without this, if something holds the frame buffer open over a
framebuffer switch, the close() operation after the switch will access a
fb_info that has been free'd by the unregistering of the old frame
buffer.

(The read/write/ioctl operations will normally not cause problems,
because they will - illogically - pick up the new fbcon instead.  But a
switch that happens just as one of those is going on might see problems
too, the window is just much smaller: one individual op rather than the
whole open-close sequence.)

This use-after-free is apparently fairly easily triggered by the Ubuntu
11.04 boot sequence.

Acked-by: Tim Gardner <tim.gardner@canonical.com>
Tested-by: Daniel J Blueman <daniel.blueman@gmail.com>
Tested-by: Anca Emanuel <anca.emanuel@gmail.com>
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix common misspellings 2011-03-31T14:26:23+00:00 Lucas De Marchi lucas.demarchi@profusion.mobi 2011-03-31T01:57:33+00:00 25985edcedea6396277003854657b5f3cb31a628 Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi> 
Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
unicore32 machine related: add frame buffer driver for pkunity-v3 soc 2011-03-17T01:19:20+00:00 GuanXuetao gxt@mprc.pku.edu.cn 2011-02-26T13:39:10+00:00 ce443ab5fd536941da1d529ba3963324f941fc29 change from original version -- by advice of Paul Mundt 1. remove videomemorysize definitions 2. remove unifb_enable and unifb_setup 3. use dev_warn instead of printk in fb driver 4. remove judgement for FB_ACCEL_PUV3_UNIGFX 5. adjust clk_get and clk_set_rate calls 6. add resources definitions 7. remove unifb_option 8. adjust register for platform_device 9. adjust unifb_ops position and unifb_regs assignment position Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn> Acked-by: Arnd Bergmann <arnd@arndb.de> 
change from original version -- by advice of Paul Mundt
1. remove videomemorysize definitions
2. remove unifb_enable and unifb_setup
3. use dev_warn instead of printk in fb driver
4. remove judgement for FB_ACCEL_PUV3_UNIGFX
5. adjust clk_get and clk_set_rate calls
6. add resources definitions
7. remove unifb_option
8. adjust register for platform_device
9. adjust unifb_ops position and unifb_regs assignment position

Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
Acked-by: Arnd Bergmann <arnd@arndb.de>