AgeCommit message (Collapse)AuthorFilesLines
2013-01-28sunxi-disp: Fix compiling for sun5isunxi-v3.0.57-r2Hans de Goede1-1/+1
It looks like the 3.4 branch has been broken for compiling for sun5i for a while, this fixes it. Signed-off-by : Hans de Goede <>
2013-01-28sunxi-hdmi: Adjust vertical total in interlaced mode with +1 if neededHans de Goede1-0/+8
The VT we get from EDID is the real VT / 2 *rounded down*, so we need to have either VT * 2 or VT * 2 + 1, add some magic to figure out which one we need. Signed-off-by: Hans de Goede <>
2013-01-28sunxi-hdmi: edid: introduce HT and VT helper variablesHans de Goede1-6/+8
Signed-off-by: Hans de Goede <>
2013-01-28sunxi-disp: Fix lcd controller timing programming for interlaced modesHans de Goede1-0/+3
Signed-off-by: Hans de Goede <>
2013-01-28leds: sunxi: show [leds_para] in Kconfig helpAlejandro Mery1-1/+1
Signed-off-by: Alejandro Mery <> Reported-by: Alexandr V. Shutko <>
2013-01-24leds:sunxi: use [leds_para] instead of [leds]Alejandro Mery1-12/+13
for consistency with the other script.bin sections Signed-off-by: Alejandro Mery <>
2013-01-24sunxi-hdmi: Fix data byte 3 of hdmi avi frameHans de Goede1-1/+5
Always set the IT content flag, to tell the display to not do scaling / filtering (which conflicts with for example computer rendered anti-aliased text). And for RGB colorspace also set the Full Range flag (pixel values go from 0-255). Signed-off-by: Hans de Goede <>
2013-01-24sunxi-hdmi: Fix data byte 2 of hdmi avi frameHans de Goede1-7/+10
Before this patch the YUV_COLORSPACE was dynamically adjusting the 2nd data byte based on the pixelclock, to select between the ITU601 (old standard tv colorspace) and ITU709 colorspace (new hd tv colorspace), as well as between 4:3 and 16:9 picture aspect ratio. But in RGB colorspace mode the 2nd data byte is hardcoded to ITO601 4:3. This patch fixes this, and also makes only the colorspace selection depend on the pixelclock (checking for sd-mode clocks). While using the actual picture aspect ratio to set the aspect ratio. This is necessary since with EDID support non SD modes may still have a 4:3 aspect ratio. Signed-off-by: Hans de Goede <>
2013-01-24sunxi-hdmi: Fix data byte 1 of hdmi avi frameHans de Goede1-4/+2
Fix the low nibble of data byte 1 of hdmi avi frame, before this patch it was being set to 0 for YUV_COLORSPACE, which is wrong since that means no bar-data, no overscan-data. But we want to explicitly disable overscan so as to for example not make xfce's panel(s) go offscreen. And it was being set to e for RGB colorspace, which is wrong since that means both horz. and vert. bar-data, underscan. While the avi frame does not contain any (valid) bar data. This patch changes the low nibble to 2 for each case, or iow to: no bar-data, underscan. Signed-off-by: Hans de Goede <>
2013-01-24input:touchscreen:ft5x_ts: Enable needed bits for xorg input device probe.Jari Helaakoski1-65/+40
[ 17.888] (II) config/udev: Adding input device ft5x_ts (/dev/input/event1) [ 17.888] (**) ft5x_ts: Applying InputClass "evdev touchscreen catchall" [ 17.888] (II) Using input driver 'evdev' for 'ft5x_ts' [ 17.888] (II) Loading /usr/lib/xorg/modules/input/ [ 17.888] (**) ft5x_ts: always reports core events [ 17.889] (**) evdev: ft5x_ts: Device: "/dev/input/event1" [ 17.889] (--) evdev: ft5x_ts: Vendor 0 Product 0 [ 17.889] (--) evdev: ft5x_ts: Found absolute axes [ 17.889] (--) evdev: ft5x_ts: Found absolute multitouch axes [ 17.889] (--) evdev: ft5x_ts: Found x and y absolute axes [ 17.889] (--) evdev: ft5x_ts: Found absolute touchscreen [ 17.890] (II) evdev: ft5x_ts: Configuring as touchscreen [ 17.890] (**) evdev: ft5x_ts: YAxisMapping: buttons 4 and 5 [ 17.890] (**) evdev: ft5x_ts: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [ 17.890] (**) Option "config_info" "udev:/sys/devices/platform/sun4i-i2c.2/i2c-2/2-0038/input/input1/event1" [ 17.891] (II) XINPUT: Adding extended input device "ft5x_ts" (type: TOUCHSCREEN, id 7) [ 17.891] (II) evdev: ft5x_ts: initialized for absolute axes. [ 17.893] (**) ft5x_ts: (accel) keeping acceleration scheme 1 [ 17.893] (**) ft5x_ts: (accel) acceleration profile 0 [ 17.893] (**) ft5x_ts: (accel) acceleration factor: 2.000 [ 17.893] (**) ft5x_ts: (accel) acceleration threshold: 4 [ 17.895] (II) config/udev: Adding input device ft5x_ts (/dev/input/mouse0) [ 17.896] (II) No input driver specified, ignoring this device. [ 17.896] (II) This device may have been added with another device file. Signed-off-by: Jari Helaakoski <>
2013-01-24axp20-mfd.h: Fixup axp20_init_chip to not cause spurious interruptsHans de Goede1-8/+5
Before this patch axp20_init_chip did the following: 1) Set the interrupt enable registers to 0x000000000103ffd8 2) Write 0xffffffffffffffff to the interrupt status registers to write-clear all interrupt status bits 3) Write 0x0000000000000000 to the interrupt enable registers to disable all interrupts Between 2 and 3 an unwanted interrupt can trigger and since this is all done over slow i2c there is plenty of time for this. This patch fixes this by changing the init sequence to: 1) Set the interrupt enable registers to 0x0000000000000000 2) Write 0xffffffffffffffff to the interrupt status registers to write-clear all interrupt status bits Signed-off-by: Hans de Goede <>
2013-01-24axp20-mfd.h: Re-format chip init register valuesHans de Goede1-5/+6
So that they can be read without needing horizontal scrolling. Signed-off-by: Hans de Goede <>
2013-01-24sunxi-disp: Use mode names like pal and ntsc for specifying tv-out modesHans de Goede1-6/+27
Some of the tv modes have the exact same dimensions but are different in things like how the color is encoded, so specifying <width>x<height> is not enough to uniquely identify them. Therefore this patch changes the screen0_output_mode value to be a mode-name like pal, ntsc or pal-nc when the screen0_output_type is set to tv. As an added bonus this patch also limits which modes from the tv_mode table can be selected, so that the user can no longer select hdmi only modes when using tv-out. Signed-off-by: Hans de Goede <>
2013-01-24sunxi-disp: Add missing breakHans de Goede1-0/+1
This fixes a kernel NULL ptr deref (trying to call hdmi functions before they are registered) when trying to use tv-out. Signed-off-by: Hans de Goede <>
2013-01-24sunxi-disp: Fix tv-out / standard tv-modes not workingHans de Goede1-4/+4
For the tv / hdmi output lcd_clk_div is not used when programming the pll, instead pre_scale is used. My commit titled: "sunxi-hdmi: Dynamically determine pll frequency for hdmi modes" Wrongly sets lcd_clk_div rather then setting pre_scale. This bug did not get noticed sofar because pre_scale gets initialized to 1, which is the correct value for non 27000000 Hz pixelclock modes. Signed-off-by: Hans de Goede <>
2013-01-24sunxi-hdmi: Fix pixelclock conversion harderHans de Goede1-6/+8
The pixelclock in hz -> picoseconds -> hz conversions loosing precision first fixed by "sunxi-hdmi: Fix some modes no longer working with X", is still a problem with some modes :| For example 130000000 becomes 130010000, and X does not work. We can only do pixelclocks which are a divider of 1 - 15 of a multiple of 3 MHz. Combining this with EDID's granularity of 10 Khz, all clocks must have been a multiple of 100 or 250 KHz before the conversion. Therefore this patch changes the rounding in fb_videomode_pixclock_to_hdmi_pclk from rounding to 10Khz to rounding to 50Khz, which should hopefullly be enough to get rid of any imprecision introduced by the conversion process. Reported-by: Daniel Veillard <> Signed-off-by: Hans de Goede <>
2013-01-24block:sunxi-nand: settings updates for various flash chips based on ↵Neal Peacock1-18/+16 allwinner source dump This patch updates the settings that were found to be different, note I haven't tested all these changes. Signed-off-by: Neal Peacock <>
2013-01-24block:sunxi-nand: New flash chips from allwinner sourceNeal Peacock1-0/+9
I found that the i-onik sources from allwinner had an updated nand_id.c file with settings I needed for a nand chip on a new device. This series of patches merges it in. This patch adds all the new entries that didn't exist before. Signed-off-by: Neal Peacock <>
2013-01-24mach-sunxi: configure IRQ for ARM Cortex-A8 performance monitoring unitSiarhei Siamashka2-0/+34
This allows the use of performance monitoring unit for statistical sampling based profiling (oprofile, perf). The downside is that the performance unit in Cortex-A8 is affected by erratum 628216, which causes it to miss interrupts in some cases and disrupt profiling results. Some information in public access about this erratum can be found here: As a result, it may be preferable to keep using the standard timer for general purpose profiling instead of the PMU cycle counter. But some of the other performance events may be still useful in practice (cache misses, ...). Signed-off-by: Siarhei Siamashka <>
2013-01-24leds:sunxi: Added LEDS driver for sunxi platformsAlexandr V. Shutko11-0/+520
Signed-off-by: Alexandr V. Shutko <>
2013-01-15sunxi-configs: minimalize configs with savedefconfigThomas Monjalon8-14374/+1
defconfig files should be saved with "make savedefconfig". It has been fixed with this command: > for config in $(grep -rl 'Automatically generated' arch/arm/configs); > do > cp $config .config; > make ARCH=arm savedefconfig; > mv defconfig $config; rm .config; > done Signed-off-by: Thomas Monjalon <>
2013-01-14sunxi-hdmi: Fix some modes no longer working with XHans de Goede5-11/+43
The "video:sunxi:disp:Dynamic mode switching" patch adds a check to see if the passed in pixelclock is valid when calling Fb_check_var. However that pixelclock gets there through a KHZ2PICOS followed by a PICOS2KHZ conversion, changing for example a 85500000 clock into a 85506000 clock, causing this check to fail. Note that the inaccuracy in this conversion is such, that it will fail for almost any mode, yet for some reason this seems to only cause problems for some modes. One theory I've is that a 85500000 mode causes problems with X, because X only makes the (now failing) FBIOPUT_VSCREENINFO call when KHZ2PICOS followed by PICOS2KHZ leads to a difference of more then .01 Mhz after rounding. IE xorg.log for the failed case contains: FBDEV(0): Built-in mode "current": 85.5 MHz, 47.7 kHz, 60.0 Hz FBDEV(0): Modeline "current"x0.0 85.51 1360 1424 1536 1792 ... Note the 85.51 versus 85.5. In the end it does not matter, since we simply need to deal with the inaccuracy and not make Fb_check_var fail because of it. This patch fixes this by: 1) Introducing new PICOS2HZ and HZ2PICOS inline functions (named in caps to match the naming of the PICOS2KHZ and KHZ2PICOS macros, but these cannot be macros because they need 64 bit divisions). This greatly improves accuracy since we have all clocks in HZ and converting them to Khz first just throws away a lot of precision 2) Rounding the result of PICOS2HZ to the nearest multiple of 10000 since edid clocks are always a multiple of 10000 Concretely this fixes X no longer starting on my HD ready television. Signed-off-by: Hans de Goede <>
2013-01-14sunxi-hdmi: Call hdmi_edid_received after checking the checksumHans de Goede1-2/+5
As it is not really helpful to pass bogus data to the fbdev ... Signed-off-by: Hans de Goede <>
2013-01-14sunxi-hdmi: Don't overwrite the current timings when receiving new EDIDHans de Goede1-1/+8
Besides that overwriting the current timings is just wrong, this also fixes a lot of "EDID mode used without valid EDID info" messages getting thrown and more nasty side effects when unplugging and replugging a monitor. What was happening is that the hdmi-edid code calls hdmi_edid_received, which updates the fb_dev mode-list, the fbdev core code responds to this by asking us what the current mode is, which ends up with a call to hdmi_get_video_timing(). which would fail in Hdmi_tv_mode_to_hdmi_mode because the Device_Support_VIC[HDMI_EDID] has been set to 0. After the fbdev core failed to get the current mode, it tries to set things to a new mode, which ends up doing a hdmi_get_video_timing() again (to save the current mode as a fallback in case the new mode fails), which fails, and things go downhill from there... This patches fixes all this by keeping the current timing info in place as *the* EDID mode when the current video_mode is HDMI_EDID. Signed-off-by: Hans de Goede <>
2013-01-14sunxi-hdmi: Replace some magic constants with definesHans de Goede3-8/+12
Signed-off-by: Hans de Goede <>
2013-01-14video:sunxi:disp:Make Fb_Init export cleanerJari Helaakoski8-9/+12
Cleanup Signed-off-by: Jari Helaakoski <> Acked-by: Hans de Goede <>
2013-01-14video:sunxi:disp:Remove struct __disp_tcon_timing_tJari Helaakoski5-76/+29
Cleanup. Signed-off-by: Jari Helaakoski <> Acked-by: Hans de Goede <>
2013-01-14video:sunxi:disp:Use BSP_disp_get_videomode elsewhere.Jari Helaakoski1-38/+22
Double buffering must be always on, or it can cause performance problems in gles applications. Signed-off-by: Jari Helaakoski <> Acked-by: Hans de Goede <>
2013-01-14video:sunxi:disp:Dynamic mode switchingJari Helaakoski6-1/+209
This patch improves Hans De Goede's EDID patch by allowing user to set new mode at runtime. Example: echo D:1280x720p-60 > /sys/devices/platform/disp/graphics/fb0/mode But precondition is that EDID support must be activated like before. Ie. by using following modprobe configuration: options disp screen0_output_mode=EDID:1280x720p60 Signed-off-by: Jari Helaakoski <> Acked-by: Hans de Goede <>
2013-01-14sunxi: disp_ump: Introduce a new ioctl for UMP wrapping the whole framebuffersunxi-v3.0.57-r1Siarhei Siamashka4-6/+13
There are two ioctls (GET_UMP_SECURE_ID_BUF1 and GET_UMP_SECURE_ID_BUF2) available for similar purpose already. And they are used by xf86-video-mali X11 DDX driver. In order not to clash with them, we just can add a new ioctl. This ioctl is needed for the new, soon to be announced xf86-video-sunxifb X11 DDX driver. Signed-off-by: Siarhei Siamashka <>
2013-01-14arch:arm:configs add ext4 fs capabilitiesRobin Humble7-14/+14
add ext4 fs capabilities to defconfigs. this allows fedora 17 packages to be updated as rpm uses capabilities in preference to setuid. Signed-off-by: Robin Humble <>
2013-01-14input:touchscreen:ft5x_ts: Make device visible under /sys/class/input/input*Jari Helaakoski1-0/+2
2013-01-14sunxi-serial: Get rid of useless sw_serial_get_configHans de Goede1-25/+0
All info gathered there is never uses, so while we're cleaning up the sunxi-serial code lets nuke this. Signed-off-by: Hans de Goede <>
2013-01-14sunxi-serial: Get rid of sw_serial global arrayHans de Goede1-8/+7
There is no need for global state here, instead store the line-number we got from registering together with our other info in the sw_serial_port struct. While at it, also add proper error checking for the serial8250_register_port call. Signed-off-by: Hans de Goede <>
2013-01-14sunxi-serial: No need to keep the port struct in memoryHans de Goede1-17/+17
Since it is only a template we don't need to keep it around. Signed-off-by: Hans de Goede <>
2013-01-14sunxi-serial: Fix bad pointer access in sw_serial_pmHans de Goede1-1/+2
The sunxi-serial code assumes that the struct uart_port *port parameter passed to the pm callback it the address of the struct it used to register. But this is completely wrong! The argument passed to serial8250_register_port is only a template, it is copied not used directly. Instead store the correct address in port->private_data and use that. Signed-off-by: Hans de Goede <>
2013-01-14tty:serial:8250_sunxi: Fix module unloadJari Helaakoski1-9/+62
2013-01-14arm:mach-sun4i:clock: Fix for "[ccmu] try to set apb1 parent to sata_pll ↵Jari Helaakoski1-1/+1
failed!" warning print. U-boot also uses OSC24M for apb1.
2013-01-08HACK: sunxi: video: change kernel framebuffer mapping to writecombineSiarhei Siamashka3-7/+28
The kernelspace mapping of framebuffer (needed for fbcon) had CPU caching enabled by some mistake. This caused glitches and artifacts in the framebuffer console, which can be easily reproduced as reported on IRC: <buZz> supereasy to reproduce; 1) type a multiword command on (fbdev) console 2) ctrl-left a word 3) delete its first character 4) tada, sticky pixels The solution is to change the kernel framebuffer memory mapping to writecombine, just like it is done for the userspace mapping. This patch is definitely *not* a clean solution. It is cutting some corners by doing exactly what was NAK'ed by the ARM kernel maintainers: The ioremap restriction (intended to prevent creating aliased mappings with different memory attributes) has been introduced with 309caa9cc6ff39d2, later relaxed in 06c10884486a63a1, and finally re-introduced again in 67cfa23ac9df810d. Even though this patch is not perfect, it can be used as a stopgap solution. = changes in v2 revision: Fix for the problems with disp module loading/unloading in dual-monitor configuration. Added debugging messages and fallback code for the case if ioremap_wc() fails. Signed-off-by: Siarhei Siamashka <>
2013-01-07Merge branch 'reference-3.0' into sunxi-3.0sunxi-v3.0.57-r0Alejandro Mery117-383/+836
2013-01-07Merge tag 'v3.0.57' into reference-3.0Alejandro Mery114-373/+821
This is the 3.0.57 stable release Conflicts: scripts/Kbuild.include
2013-01-07Merge branch 'mirror/android-3.0' into reference-3.0Alejandro Mery4-10/+15
2013-01-06sunxi-usb: restore usb-manager's ability to enable/disable host controllerssunxi-v3.0.52-r2Jussi Kivilinna2-0/+28
Signed-off-by: Jussi Kivilinna <> Acked-by: Jari Helaakoski <>
2013-01-06video: sunxi: fix green text in RGB565 framebuffer consoleSiarhei Siamashka1-1/+1
When the framebuffer is configured to use RGB565 format, the default text color was showing up green instead of gray. This was caused by incorrectly taking low bits instead of high bits when reducing color components from 8 bits to anything lower. === before === [ 42.610000] Fb_setcolreg,regno= 7,a=FF,r=AA,g=AA,b=AA, result=0000554A (0x554A = 01010 101010 01010) === after === [ 37.260000] Fb_setcolreg,regno= 7,a=FF,r=AA,g=AA,b=AA, result=0000AD55 (0xAD55 = 10101 101010 10101) Signed-off-by: Siarhei Siamashka <> Acked-by: Jari Helaakoski <>
2013-01-06video: sunxi: don't silently change any 16bpp video mode to ARGB1555Siarhei Siamashka1-1/+17
Even in spite of having fb0_format/fb1_format configured to any of 16bpp choices (ARGB1555, ARGB1555, RGBA5551, ARGB4444, RGB655, RGB565, RGB556) in *.fex file, it was getting silently overrided with ARGB1555. But RGB565 is generally best supported in software and has more performance optimizations. It would be a shame if we could not use it. Signed-off-by: Siarhei Siamashka <> Acked-by: Jari Helaakoski <>
2013-01-03sunxi-usb: Unify sun4i and sun5i host driversAndrey Panov9-2714/+804
- All drivers are handling clock through API rather than speaking to IO ports directly, merging changes from A13 SDK. - Kconfig options are updated - Remnants of support for USB1 and USB2 ports are deleted from sun4i_usb and sun5_usb, as these ports are handled by EHCI and OHCI drivers. [v2, Jussi Kivilinna] - Kconfig options changed and kept dual role OTG controller options mostly unchanged - cleanups - Tested on sunxi-3.4 with sun4i and only compile tested on sunxi-3.0. Signed-off-by: Jussi Kivilinna <>
2013-01-03sunxi-hdmi: Allow EDID info < 1.3Hans de Goede1-1/+6
But only if the preferred timing feature bit is set, so that we know the first DTD contains the preferred mode for the monitor. Reported-by: Robin Humble <> Signed-off-by: Hans de Goede <>
2013-01-03video:sunxi:disp:Pass correct pixel_clk to kernelJari Helaakoski1-3/+9
Signed-off-by: Jari Helaakoski <> Acked-by: Hans de Goede <>
2013-01-03video:sunxi:hdmi: Speedup hdmi initJari Helaakoski1-11/+16
Signed-off-by: Jari Helaakoski <> Acked-by: Hans de Goede <>
2013-01-03sunxi-hdmi: Fix NULL ptr deref when EDID info is received before fb is ↵Hans de Goede2-8/+22
registered With the latest changes hdmi_edid_received() calls lock_fb_info() now, but calling lock_fb_info() on a not yet registered fb causes a NULL ptr exception. This patch fixes this by tracking if the fb has been registered yet, and only locking it if has (otherwise there will be no users of it, so no locking will be necessary). This patch also adds locking around the registered state trackig + checking as hdmi_edid_received() gets called from the hdmi tasklet thread, so it may race with Fb_Init(). Signed-off-by: Hans de Goede <>