OMAPDSS: DISPC: fix the use of wrong DSI PLL

Patch 61265da7213cc76427ff4c56b31f296ecbaffea8 (OMAPDSS: DISPC: Choose
the PLL type based on a dispc feature) added support for VIDEO PLLs, but
it accidentally used wrong PLL ID in one place.

This causes the kernel to crash when using DSI PLL2 for video (e.g.
omap4 panda).

Fix the wrong ID.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: PLL: Fix PLL_SELFREQDCO field width

PLL_SELFREQDCO bitfield is from bit 3 to 1, but the driver writes bits
from 4 to 1. The bit 4 is unused, so this should not cause any issues,
but it's better to fix it.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: PLL: fix PLL config when pixel clock is low

The VIDEO PLL patches which generalized the DSS PLL code added a new
check to verify that the PLL DCO rate is not too low.

However, this breaks OMAP4 HDMI. It seems that on OMAP4, the PLL works
fine with low DCO rates, but not on OMAP5.

As the check is just a safety measure against driver bugs (if driver
calculates PLL settings badly), we can just disable the check for now.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
drm: omapdrm: fix compiler errors

[ Upstream commit 2d31ca3ad7d5d44c8adc7f253c96ce33f3a2e931 ]

Regular randconfig nightly testing has detected problems with omapdrm.

omapdrm fails to build when the kernel is built to support 64-bit DMA
addresses and/or 64-bit physical addresses due to an assumption about
the width of these types.

Use %pad to print DMA addresses, rather than %x or %Zx (which is even
more wrong than %x).  Avoid passing a uint32_t pointer into a function
which expects dma_addr_t pointer.

drivers/gpu/drm/omapdrm/omap_plane.c: In function 'omap_plane_pre_apply':
drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Werror=format]
drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Werror=format]
make[5]: *** [drivers/gpu/drm/omapdrm/omap_plane.o] Error 1
drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_get_paddr':
drivers/gpu/drm/omapdrm/omap_gem.c:794:4: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' [-Werror=format]
drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_describe':
drivers/gpu/drm/omapdrm/omap_gem.c:991:4: error: format '%Zx' expects argument of type 'size_t', but argument 7 has type 'dma_addr_t' [-Werror=format]
drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_init':
drivers/gpu/drm/omapdrm/omap_gem.c:1470:4: error: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Werror=format]
make[5]: *** [drivers/gpu/drm/omapdrm/omap_gem.o] Error 1
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c: In function 'dmm_txn_append':
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:226:2: error: passing argument 3 of 'alloc_dma' from incompatible pointer type [-Werror]
make[5]: *** [drivers/gpu/drm/omapdrm/omap_dmm_tiler.o] Error 1
make[5]: Target `__build' not remade because of errors.
make[4]: *** [drivers/gpu/drm/omapdrm] Error 2

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Revert "drm/omap: fix the handling of fb ref counts"

This reverts commit 2ec07ba724943da09ba8b11bfcc10d81d06a4600.

Commit 2ec07ba724943da09ba8b11bfcc10d81d06a4600, which was backported
from mainline (f2d022aa421ca903a30f63b04528064b7eceaf5e), does not work
correctly.

The original commit was made to fix fb refcount issue on top of
mainline, which contains the new primary-plane support for drm. However,
our kernel does not have the primary-plane support, and the commit
actually breaks fb refcounting.

The issue shows when unloading omapdrm, which causes a WARN to be
printed as the root fb still has references. After reverting the patch,
the problem disappears.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
drm/omap: fix encoder-crtc mapping

OMAP DSS hardware supports changing the output port to which an overlay
manager's video stream goes. For example, DPI video stream can come from
any of the four overlay managers on OMAP5.

However, as it's difficult to manage the change in the driver, the
omapdss driver does not support that at the moment, and has a hardcoded
overlay manager per output.

omapdrm, on the other hand, uses the hardware features to find out which
overlay manager to use for an output, which causes problems. For
example, on OMAP5, omapdrm tries to use DIGIT overlay manager for DPI
output, instead of the LCD3 required by the omapdss driver.

This patch changes the omapdrm to use the omapdss driver's hardcoded
overlay managers, which fixes the issue.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
drm/omap: page_flip: return -EBUSY if flip pending

The DRM documentation says:

"If a page flip is already pending, the page_flip operation must return
-EBUSY."

Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning
-EBUSY.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
drm/omap: fix race issue with vsync irq and apply

omap_crtc's apply_worker does:

	omap_irq_register(dev, &omap_crtc->apply_irq);
	dispc_mgr_go(channel);

This is supposed to enable the vsync irq, and set the GO bit. The vsync
handler will later check if the HW has cleared the GO bit and queue
apply work.

However, what may happen is that the vsync irq is enabled, and it gets
ran before the GO bit is set by the apply_worker. In this case the vsync
handler will see the GO bit as cleared, and queues the apply work too
early.

This causes WARN'ings from dispc driver, and possibly other problems.

This patch fixes the issue by adding a new variable, 'go_bit_set' which
is used to track the supposed state of GO bit and helps the apply worker
and irq handler handle the job without a race.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
drm/omap: make modesetting synchronous

Currently modesetting is not done synchronously, but it queues work that
is done later. In theory this is fine, but the driver doesn't handle it
at properly. This means that if an application first does a full
modeset, then immediately afterwards starts page flipping, the page
flipping will not work properly as there's modeset work still in the
queue.

The result with my test application was that a backbuffer was shown on
the screen.

Fixing this properly would be rather big undertaking. Thus this patch
fixes the issue by making the modesetting synchronous, by waiting for
the queued work to be done at the end of omap_crtc->commit().

The ugly part here is that the background work takes crtc->mutex, and
the modesetting also holds that lock, which means that the background
work never gets done. To get around this, we unclock, wait, and lock
again.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
drm/omap: clear omap_obj->paddr in omap_gem_put_paddr()

Clear omap_obj's paddr when unmapping the memory, so that it's easier to
catch bad use of the paddr.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
drm/omap: add pin refcounting to omap_framebuffer

omap_framebuffer_pin() and omap_framebuffer_unpin() are currently
broken, as they cannot be called multiple times (i.e. pin, pin, unpin,
unpin), which is what happens in certain cases. This issue causes the
driver to possibly use 0 as an address for a displayed buffer, leading
to OCP error from DSS.

This patch fixes the issue by adding a simple pin_count, used to track
the number of pins.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
drm/omap: fix omap_crtc_flush() to handle the workqueue

omap_crtc_flush() is used to wait for scheduled work to be done for the
give crtc. However, it's not quite right at the moment.

omap_crtc_flush() does wait for work that is ran via vsync irq to be
done. However, work is also queued to the driver's priv->wq workqueue,
which is not handled by omap_crtc_flush().

Improve omap_crtc_flush() to flush the workqueue so that work there will
be ran.

This fixes a race issue on module unload, where an unpin work may be on
the work queue, but does not get ran before drm core starts tearing the
driver down, leading to a WARN.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
drm/omap: fix preclose to wait for scheduled work

We already wait for all scheduled work to be done on the driver's unload
function. However, I think we need to wait on preclose() also, so that
when an application closes the drm file descriptor, we are sure that
there's no left around.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
drm/omap: add a comment why locking is missing

unpin_worker() calls omap_framebuffer_unpin() without any locks, which
looks very suspicious. However, both pin and unpin are always called via
the driver's private workqueue, so the access is synchronized that way.

Add a comment to make this clear.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
ASoC: tlv320aic31xx: Fix 24bit samples with I2S format and 12MHz mclk

I2S format requires bitclock to have an exact amount of cycles in a
frame for audio to work cleanly. With dsp formats that is not so
important.

Updates aic31xx_setup_pll() to look for a line in aic31xx_divs table
that produces the best match for the bitclock and adds lines to
aic31xx_divs for 12MHz mclk and 24bit samples.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
ASoC: tlv320aic31xx: Choose PLL p divider automatically

The PLL input after p-divider should always be <= 20MHz [1]. This patch
chooses p-divider value automatically. After this aic31xx_divs table
no longer needs p_val field or separate lines for 12 and 24 MHz mclks.

[1] http://www.ti.com/lit/ds/symlink/tlv320aic3100.pdf
    Section: 5.6 CLOCK Generation and PLL

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
HACK: drm/fb_helper: enable panning support

Increase the size of the buffer that is created in the fbdev emulation
helpers.  And fill in the var structure with the amount that was allocated.

This should be parameterized so each DRM driver could pick its required
number of buffers allocated for /dev/fb0, however I don't see an easy way
to do this.  For now it is hardcoded and will effect all platforms that use
fb_cma_helper (only tilcdc for ti-linux-3.14.y).

Signed-off-by: Darren Etheridge <detheridge@ti.com>
HACK: drm/tilcdc: add vsync callback for use in omaplfb for gpu

Add a vsync callback registration API that is identical to what was done
for da8xx-fb.c.

Need to find if there is a better way using the DRM infrastructure from
kernel space.  Either that or change the userspace window manager stuff in
the gpu libraries to make use of the DRM provided syncronization
mechanisms.  There is a generic vblank_wait function proposal circulating the
dri-devel list at the moment that could replace this.

Signed-off-by: Darren Etheridge <detheridge@ti.com>
drm/tilcdc: fix the ping-pong dma tearing issue seen on buffer flipping

Update the DMA pointers during the pan display ioctl.  Borrowed from
da8xx_fb.c update the scanout buffers immediately so the DMA ping/pong
doesn't end up out of sync with what we really want it to DMA, otherwise part
of the screen ends up tearing during rapid flip operations.

Ported to tilcdc from upstream commit deb95c6c958f5ba97b6b89ab18917bf79cb8ce7b

Signed-off-by: Darren Etheridge <detheridge@ti.com>
v4l: of: New property to specify number of channels

For time multiplexed video signal, number of channels multiplexed
is specified by adding a new property 'num-channels' to the endpoint

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>