The framebuffer routines also work with the cea861 data. Move the edid reading
into the function itself, which avoids us having to read the EDID data multiple
times and allows us to pass the full EDID data to the framebuffer routines.
We always have to read the first block to determine the actual length of the
EDID data. In order to keep the reading logic the same all the time, we simply
re-read the EDID data always (even if there are no extension blocks). This
hopefully will help keep timing issues similar across all devices.
For timer based power autogating, we have to move clk_enable/disable out of
timer handler, because they become may sleep.
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
If GPU error interrupt detected, related device will be destroyed.
In the destory function, device_idle and mutex_lock may cause sleep,
which may cause kernel crash, so delay the device destroy to the
workqueue to avoid this.
Signed-off-by: Jie Zhou <b30303@freescale.com>
Cleanup the siihdmi header (which really is pointless to split out...), redefine
the fields for the sii info frame packets, and restructure sizes to be in terms
of registers.
The allocations are no longer done in the info frame setting, DVI can transmit
the info frames, and the cost is simply the i2c writes. This is an infrequent
operation, so just absorb the cost regardless of the connection type.
Use a proper edid structure definition rather than indexing into a data blob.
This also adds additional helper functions to work with the returned edid data.
There is much room for further improvements still. We should simply read the
first block, then use that to actually determine the number of blocks we need to
read from the device. We cant simply read all the potential blocks as that can
be up to 32K of data.
Once we are reading all the EDID extensions, we should iterate over the blocks
to find the CEA block rather than assuming that the device is sending the CEA
block as the first block (especially given that the VESA spec calls for block 1
to be an extension map if there are more than 1 block present).
bus_timeout depends somewhat on the output device for certain operations. As
such, it can be useful to actually change the value at runtime. To that end,
make the value a module parameter.
Bonus whitespace cleanups and centralises the value to a single location.
info frame checksumming is defined by the CEA861-E standard, and is not specific
to SII9xxx, so move that into the CEA861 header.
Don't bother allocating the info frame structures off the heap. That causes
unnecessary fragmentation and complexity. Allocate them off the stack as they
are small enough. This also helps keep everything simple.
As a bonus, fixed up the SII HDMI structures and the CEA861 InfoFrame structures
in the process as well. Also clean up the magic number in the AVI InfoFrame
assertion.
Compared with other drivers, the "ret" should be nagative and
returned. But in vhci_hdc, it always return 0;
I dont't use the driver, and I'm not familiar with the code.
Hope the patch is helpful.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This includes fixes for all of the legit checkpatch.pl errors and
warnings. I have also included several of the suggestions from the
linux-kernel mailing list when the USB-IP code was first added.
Signed-off-by: Brian G. Merrell <bgmerrell@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drag mxc_ipuv3_fb with it (remove final efikamx specific stuff)
update some IPU stuff and ioctls for it all to interoperate
notes:
that line_length bug is still there, I really can't find why it's 0...
doesn't register because the platform_device isn't in a/a/p-mxc/devices.?
ENGR00133954 ipuv3: remove FB_SYNC_EXT flag
ENGR00133034 ipuv3: fix black flash issue during high resolution video playback
ENGR00134076 ipuv3: should not set burst size again
ENGR00133345 IPUv3 VDI:Support bottom field first setting
ENGR00131660 ipuv3: left stripe output column should be set to zero
This actually fixes the clock sync problem with the AOC HDMI monitor we have (perfectly
working display but "input not support" floating around). Happily, the boot splash
actually works, too (previously it would not work until the second set of the display
when GDM booted). Hopefully IPU support is nice and stable now.
Workaround for imx5x M4IF burst len errata when armv7 neon enabled, use
pgprot_writecombine instead of pgprot_noncached, to avoid burst len > 8.
Signed-off-by: Sammy He <r62914@freescale.com>
HW flow control should be enable/disable by userspace.
It can be set by tty option: options.c_cflag of CRTSCTS
bit.
This bug is found by testing UART BT AR3001 chip,
this chip will wake up the chip by set RTS to high,
it needs frist disable HW flow control, set RTS,
then disable HW flow control.
Signed-off-by: Zhang Jiejing <jiejing.zhang@freescale.com>
If VPU doesn't use IRAM, there will be a kernel dump when
we enter VPU driver probe function.
This issue is caused by allocating IRAM with zero buffer
size.
Signed-off-by: Liu Ying <b17645@freescale.com>
disable dp-dc in the display flow end irq handler, otherwise,
ipu may get NFB4EOF error for next fb enabling under big resolution(like 1080p).
Signed-off-by: Jason Chen <b02280@freescale.com>
