Enable dss to process color formats with pre-mulitplied alpha.
With this we can have alpha values defined for each pixel
and hence can have different blending values for each pixel.
sysfs entry has been created for this and pre-multiplied alpha
support is turned off by default.
Signed-off-by: NSudeep Basavaraj <sudeep.basavaraj@ti.com>
Signed-off-by: NRajkumar N <rajkumar.nagarajan@ti.com>
Signed-off-by: NSamreen <samreen@ti.com>
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Splitting the OMAP3 dss has feature separately for
omap3430 & omap3630
Signed-off-by: NSamreen <samreen@ti.com>
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Read correct DISPC_CONFIG bit when the channel is DIGIT, remove extra line
at the end of the function.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Fallback on the local-mac-address prom property if the Cassini device
does not have an address programmed in the VPD ROM. This uses the same
technique as implemented by the sungem driver.

The problem was reported by Frans van Berckel using Debian kernel 2.6.34-7
on Sun Fire V440. udev was assigning a new eth<n> device name on each reboot
because the cassini driver was using a random MAC address.

Fix tested on 2.6.34-7 and 2.6.37 Sun Fire V440. Compile tested against
2.6.36 davem/sparc-2.6.git
Reported-by: NFrans van Berckel <fberckel@xs4all.nl>
Tested-by: NFrans van Berckel <fberckel@xs4all.nl>
Reviewed-by: NJulian Calaby <julian.calaby@gmail.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NRichard Mortimer <richm@oldelvet.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After commit 25edd694 ("sparc64: Get
rid of indirect p1275 PROM call buffer.")  we can't pass virtual
addresses >4GB to PROM calls.

Largely this is never necessary in drivers because we have a copy of
the entire PROM device tree in the kernel and a set of of_*()
interfaces to access it.

Unfortunately there were some lingering prom calls in the atyfb
driver, in particular prom_finddevice() was being called with an
on-stack address which could be anywhere.

This code is actually probing for information we already have, the
PROM choosen console output device is stored in of_console_device so
all of this nasty code consolidates into a one-line comparison.

Next we have some prom_getintdefault() calls which are trivially
transformed into the equivalent of_getintprop_default().

Special thanks to Fabio, who figured out exactly where the bootup
was hanging.  That made this bug trivial to fix.
Reported-by: NFabio M. Di NItto <fabbione@fabbione.net>
Reported-by: NSam Ravnborg <sam@ravnborg.org>
Reported-by: NFrans van Berckel <fberckel@xs4all.nl>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NFabio M. Di NItto <fabbione@fabbione.net>

Signed-off-by: NFerenc Wagner <wferi@niif.hu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NFerenc Wagner <wferi@niif.hu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The new firmware interface requires each Slow Path Queue (SPQ) message's
type field to include the function number.  The existing code does not
do this consistently.  We fix this by OR'ing in the function number
into the type field centrally in cnic_submit_kwqe_16().
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Return -ENOMEM instead of 0 for the case of mdiobus_alloc and kmalloc failure.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Return PTR_ERR(port->phydev) instead of 1 if phy_connect failed.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

gcc 4.5+ doesn't properly evaluate some inlined expressions.
A previous patch were proposed by Andrew Morton using noinline.
However, the entire inlined function is bogus, so let's just
remove it and be happy.
Reported-by: NAndrew Morton <akpm@linux-foundation.org>
Cc: stable@kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This kills off all of the dl_xxx() printk wrappers and simply stubs in a
pr_fmt() definition to accomplish the same thing.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

The edid length is fixed, so use the standard definition consistently.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

udlfb selects all of the options it presently ifdef conditionalizes, so
none of the statements have any effect outside of aggravating eye strain.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This adds a new entry to the modedb for 864x480 TAAL panels, the default
configuration for many OMAP boards. This enables omapfb to make use of
the standard mode parsing.
Signed-off-by: NMayuresh Janorkar <mayur@ti.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

These patch fix a longstanding bug in the i810 frame buffer driver.

The handling of the i2c bus is wrong: A 1 bit should not written to the
i2c, these will be done by switch the i2c to input. Driving an 1 bit
active is against the i2c spec.

An active driven of a 1 bit will result in very strange error, depending
which side is the more powerful one. In my case it depends on the
temperature of the Display-Controller-EEprom: With an cold eprom a got
the correct EDID datas, with a warm one some of the 1 bits was 0 :-(

The same bug is also in the intelfb driver in the file
drivers/video/intelfb/intelfb_i2c.c. The functions intelfb_gpio_setscl()
and intelfb_gpio_setsda() do drive the 1 bit active to the i2c bus. But
since i have no card which is used by the intelfb driver i cannot fix
it.
Signed-off-by: NStefani Seibold <stefani@seibold.net>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Resurrected some old hardware and fixed up the hgafb driver to work
again. Only tested with fbcon, since most fbdev-based software appears
to only support 12bpp and up. It does not appear that this driver has
worked for at least the entire 2.6.x series, perhaps since 2002.

Hercules graphics hardware uses packed pixels horizontally, but rows are
not linear. In other words, the pixels are not packed vertically. This
means that custom imageblit, fillrect and copyarea need to be written
specific to the hardware.

 * Removed the experimental acceleration option, since it is required
   for the hardware to work.
 * Fixed imageblit to work with fb_image's wider than 8 pixels.
 * Updated configuration text (HGA hardware is from 1984)
Signed-off-by: NBrent Cook <busterb@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This code had an error handling goto to the wrong place, a misplaced
release_mem_region, and a duplicated release_mem_region.

The semantic match that finds the double release_mem_region is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
expression e1,e2,e3;
position p1,p2,p3;
@@
release_mem_region@p1(e1, e2)@p3;
... when != request_mem_region(e1,e2,e3)
release_mem_region(e1, e2)@p2;

@@
expression e <= r.e1,e3;
expression r.e1,e2;
position r.p1,r.p2,r.p3,p!=r.p1;
@@
*release_mem_region(e1, e2)@p3;
... when != e = e3
*release_mem_region@p(e1, e2)@p2;// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

MX27 and MX25 have 10 bits in the YMAX field of LCDC Size Register.

Fix the maximum value for yres.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This patch extends the LCDC driver with 24 bpp
and 32 bpp support.

These modes have been kept disabled earlier due
to dependencies between the potential two LCDC
channels that are exported as two separate
framebuffer devices. The dependency boils down
to a byte swap register that is shared between
multiple channels.

With this patch applied all single channel LCDC
hardware can chose freely from 16, 24 and 32 bpp.
Dual channel LCDC must stick to the same setup
for both channels.

Without this patch only 16 bpp is fully supported.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ST Micro variants has some specific dma burst threshold compensation,
which allows them to make better use of a DMA controller.  Add support
to set this up.

Based on a patch from Linus Walleij.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add DMA engine support for transmit to the PL011 driver.  Based on a
patch from Linus Walliej, with the following changes:

- remove RX DMA support.  As PL011 doesn't give us receive timeout
  interrupts, we only get notified of received data when the RX DMA
  has completed.  This rather sucks for interactive use of the TTY.

- remove abuse of completions.  Completions are supposed to be for
  events, not to tell what condition buffers are in.  Replace it with
  a simple 'queued' bool.

- fix locking - it is only safe to access the circular buffer with the
  port lock held.

- only map the DMA buffer when required - if we're ever behind an IOMMU
  this helps keep IOMMU usage down, and also ensures that we're legal
  when we change the scatterlist entry length.

- fix XON/XOFF sending - we must send XON/XOFF characters out as soon
  as possible - waiting for up to 4095 characters in the DMA buffer
  to be sent first is not acceptable.

- fix XON/XOFF receive handling - we need to stop DMA when instructed
  to by the TTY layer, and restart it again when instructed to.  There
  is a subtle problem here: we must not completely empty the circular
  buffer with DMA, otherwise we will not be notified of XON.

- change the 'enable_dma' flag into a 'using DMA' flag, and track
  whether we can use TX DMA by whether the channel pointer is non-NULL.
  This gives us more control over whether we use DMA in the driver.

- we don't need to have the TX DMA buffer continually allocated for
  each port - instead, allocate it when the port starts up, and free
  it when it's shut down.  Update the 'using DMA' flag if we get
  the buffer, and adjust the TTY FIFO size appropriately.

- if we're going to use PIO to send characters, use the existing IRQ
  based functionality rather than reimplementing it.  This also ensures
  we call uart_write_wakeup() at the appropriate time, otherwise we'll
  stall.

- use DMA engine helper functions for type safety.

- fix init when built as a module - we can't have to initcall functions,
  so we must settle on one.  This means we can eliminate the deferred
  DMA initialization.

- there is no need to terminate transfers on a failed prep_slave_sg()
  call - nothing has been setup, so nothing needs to be terminated.
  This avoids a potential deadlock in the DMA engine code
  (tasklet->callback->failed prepare->terminate->tasklet_disable
   which then ends up waiting for the tasklet to finish running.)

- Dan says that the submission callback should not return an error:
  | dma_submit_error() is something I should have removed after commit
  | a0587bcf "ioat1: move descriptor allocation from submit to prep" all
  | errors should be notified by prep failing to return a descriptor
  | handle.  Negative dma_cookie_t values are only returned by the
  | dma_async_memcpy* calls which translate a prep failure into -ENOMEM.
  So remove the error handling at that point.  This also solves the
  potential deadlock mentioned in the previous comment.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As the DMA support introduces a separate interrupt-time callback, our
interrupt handler will not be the only handler which takes the port
lock, so we need to ensure that IRQs are disabled.  We must use the
_irqsave variant so we don't inadvertently enable interrupts.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

With DMA support, we need to tell the TTY subsystem that the DMA buffer
is the size of the FIFO, otherwise things like tty_wait_until_sent()
will time out too early.  Keep (and use) the hardware value separately
from the port->fifosize.

This was part of a larger patch from Linus Walleij, with a little
modification.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Rather than copying all vendor data into the port structure, copy
just that which is frequently used, and keep a pointer to the
remaining vendor data structure.  This makes it easier to add
vendor quirks in the future.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The error flags weren't being cleared upon UART startup, which
can cause problems when we add DMA support.  It's good practice
to ensure that these flags are cleared anyway, so let's do so.

This was part of a larger patch from Linus Walleij.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Include the revision number of the PL011 primecell in the boot-time
port printk to allow proper identification of the peripheral.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

drivers/staging/cx25821/cx25821-video.c: In function ‘video_open’:
drivers/staging/cx25821/cx25821-video.c:817:8: error: implicit declaration of function ‘lock_kernel’
drivers/staging/cx25821/cx25821-video.c:834:9: error: implicit declaration of function ‘unlock_kernel’

This patch just adds a header with BKL function. It should be enough
to avoid compilation breakage, but, as BKL will be removed, we need
to properly fix it on a latter patch.
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Reported-by: NAnca Emanuel <anca.emanuel@gmail.com>
Cc: Palash Bandyopadhyay <Palash.Bandyopadhyay@conexant.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Different sh-mobile SoCs have variations in their MIPI DSI register layouts,
besides, different LCD panels require different configuration parameters. This
patch switches the driver to use platform-provided MIPI DSI parameters.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

On SH-Mobile platforms using runtime PM with the MIPI DSI driver switches the
DSI Tx link clock on PM events.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Fix test in lbs_spi_thread().  down_interruptible() can return -EINTR, but
not EINTR.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Cc: Dan Williams <dcbw@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

To inject a packet in monitor mode, a dummy station has
to be associated with the monitor interface in the target.
Failing to do this would result in a firmware crash on the device.
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

ath5k_eeprom_mode_from_channel() returns -1 on error but we're storing
the result in "ee_mode" which is an unsigned char.  This breaks the
error handling.  This patch makes "ee_mode" an int.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove some obvious looking dead code and rename few functions
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Restart the beacon timers only if the beacon
was already configured. Otherwise beacons timers
are restarted unnecessarily in unassociated state too.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit 0ce3bcfc.

Event though with the above commit we obtain the configured DTIM period
from the AP rather than always hardcoding it to '1', this seems to cause
problems under the following scenarios:
* Preventing association with broken AP's
* Adds latency in roaming
So its better to always use the safe value of '1' for dtim period

Cc: Jouni Malinen <Jouni.Malinen@Atheros.com>
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

An Rx DMA descriptor can have multiple error bits set, and some error
bits (e.g. MIC failure) are filtered by the driver based on other criteria.
Remove the 'else' in various error bit checks so that all error information
is properly passed to the driver.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>