The newer Atmel SoCs use normal 16bit 565 BGR/RGB for the palette data,
rather than the special intensity + 555 format.

Fill out palette data correctly on these devices, and at the same time
respect the RGB/BGR wiring mode.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

If used with negative polarity the PWM unit cannot be disabled. This would
result in a full contrast screen.
Instead let the PWM unit enabled using 0x0 as compare value which darkens
the display.
In result no power saving is possible if inverted contrast polarity
is used.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

In the AT91SAM9263 Manual the HFP part in LCDTIM2 is described as follows:
  * HFP: Horizontal Front Porch
  Number of idle LCDDOTCK cycles at the end of the line.
  Idle period is (HFP+2) LCDDOTCK cycles.

It is only a minor issue. I also changed all boards using atmel_lcdfb
I found to respect the new calculation.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

This four year old subsystem does not have a single in-tree user
not even in staging and as far as I know also none out-of-tree.
I think that justifies removing it which cleans the config up.
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
Acked-by: NJames Simmons <jsimmons@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>

According to the comments in include/linux/init.h:

"Pointers to __devexit functions must use __devexit_p(function_name), the
wrapper will insert either the function_name or NULL, depending on the config
options."

We have __devexit annotation for platinumfb_remove(), thus add __devexit_p at
necessary place.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The diu_pool structure contains diu_addr objects for various objects
allocated in DMA space that are used by the DIU, but the only instance
of this structure is a global variable, 'pool'.  Eliminate 'pool' by
merging its fields into the fsl_diu_data structure, which is instantiated
on the heap for each DIU controller found.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The diu_hw structure contains two fields used to access the DIU registers,
but the only instance of this structure is a global variable, 'dr'.
Eliminate 'dr' by merging its fields into the fsl_diu_data structure,
which is instantiated on the heap for each DIU controller found.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The Freescale DIU video controller supports five video "modes", but only
the first two are used by the driver.  The other three are special modes
that don't make sense for a framebuffer driver.  Therefore, there's no
point in keeping a global variable that indicates which mode we're
supposed to use.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The MFB_TYPE_xxx macros indicate different "operating modes" of each AOI,
but this feature is not actually used in the driver.  The mfb_index.type
field is always set to MFB_TYPE_OUTPUT, so just delete it and any code
that references it.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

Each of the five AOIs created by the DIU driver has a special purpose, and
they're not treated equally.  It makes sense to identify them with an enum
instead of a hard-coded number.

Since the 'index' is now an enum, it can only contain allowed values, so
there's no need to check for an invalid value.  This simplifies some other
code, such as fsl_diu_disable_panel(), which no longer needs to return an
error code.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

Add the following new video modes to the Freescale DIU framebuffer driver:

640x480x60
640x480x72
640x480x75
640x480x90
640x480x100
800x480x60
800x600x60
854x480x60
1280x480x60
1280x720x60
1920x1080x60

Also add margin data to the 320x240 video mode.  This mode was originally
intended only for the AOIs (overlays) used on planes two and three, but with
real margin data, it can now be used as an actual video mode.
Video mode data is from earlier work done by Jerry Huang
<Chang-Ming.Huang@freescale.com>.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The function which is supposed to provide screen blanking support doesn't
actually do anything, so the framebuffer layer thinks the screen has
been blanked when it really isn't.  Remove the code completely for now.

A side-effect of this change is that the framebuffer console blanking now
works correctly.  Presumably this is because the console now receives -EINVAL
instead of '0' when it asks the driver to blank the screen, so the console
does it manually now.

A signficant refactoring of the driver is planned, and proper hardware
blanking support will added afterwards.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

Move several macros and structures from the Freescale DIU driver's header
file into the source file, because they're only used by that file.  Also
delete a few unused macros.

The diu and diu_ad structures cannot be moved because they're being used
by the MPC5121 platform file.  A future patch eliminate the need for
the platform file to access these structs, so they'll be moved also.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

Use the _IOx macros to define the ioctl commands, instead of hard-coded
numbers.  Unfortunately, the original definitions of MFB_SET_PIXFMT and
MFB_GET_PIXFMT used the wrong value for the size, so these macros have
new values now.  To avoid breaking binary compatibility with older
applications, we retain support for the original values, but the driver
displays a warning message if they're used.

Also remove the FBIOGET_GWINFO and FBIOPUT_GWINFO ioctls.  FBIOPUT_GWINFO
was never implemented, and FBIOGET_GWINFO was never used by any
application.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

* git://github.com/davem330/net:
  pch_gbe: Fixed the issue on which a network freezes
  pch_gbe: Fixed the issue on which PC was frozen when link was downed.
  make PACKET_STATISTICS getsockopt report consistently between ring and non-ring
  net: xen-netback: correctly restart Tx after a VM restore/migrate
  bonding: properly stop queuing work when requested
  can bcm: fix incomplete tx_setup fix
  RDSRDMA: Fix cleanup of rds_iw_mr_pool
  net: Documentation: Fix type of variables
  ibmveth: Fix oops on request_irq failure
  ipv6: nullify ipv6_ac_list and ipv6_fl_list when creating new socket
  cxgb4: Fix EEH on IBM P7IOC
  can bcm: fix tx_setup off-by-one errors
  MAINTAINERS: tehuti: Alexander Indenbaum's address bounces
  dp83640: reduce driver noise
  ptp: fix L2 event message recognition

* 'fix/asoc' of git://github.com/tiwai/sound:
  ASoC: omap_mcpdm_remove cannot be __devexit
  ASoC: Fix setting update bits for WM8753_LADC and WM8753_RADC
  ASoC: use a valid device for dev_err() in Zylonite

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon/kms: fix channel_remap setup (v2)
  drm/radeon: Set cursor x/y to 0 when x/yorigin > 0.
  drm/radeon: Update AVIVO cursor coordinate origin before x/yorigin calculation.
  drm/radeon: Simplify cursor x/yorigin calculation.
  drm/radeon/kms: fix cursor image off-by-one error
  drm/radeon/kms: Fix logic error in DP HPD handler
  drm/radeon/kms: add retry limits for native DP aux defer
  drm/radeon/kms: fix regression in DP aux defer handling

* 'spi/merge' of git://git.secretlab.ca/git/linux-2.6:
  spi-topcliff-pch: Fix overrun issue
  spi-topcliff-pch: Add recovery processing in case FIFO overrun error occurs
  spi-topcliff-pch: Fix CPU read complete condition issue
  spi-topcliff-pch: Fix SSN Control issue
  spi-topcliff-pch: add tx-memory clear after complete transmitting

Add the ability to disable PCI-E MPS turning and using the BIOS
configured MPS defaults.  Due to the number of issues recently
discovered on some x86 chipsets, make this the default behavior.

Also, add the option for peer to peer DMA MPS configuration.  Peer to
peer DMA is outside the scope of this patch, but MPS configuration could
prevent it from working by having the MPS on one root port different
than the MPS on another.  To work around this, simply make the system
wide MPS the smallest possible value (128B).
Signed-off-by: NJon Mason <mason@myri.com>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Most asics just use the hw default value which requires
no explicit programming.  For those that need a different
value, the vbios will program it properly.  As such,
there's no need to program these registers explicitly
in the driver.  Changing MC_SHARED_CHREMAP requires a reload
of all data in vram otherwise its contents will be scambled.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=40103

v2: drop now unused channel_remap functions.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

We found that adding load, Rx data sometimes drops.(with DMA transfer mode)
The cause is that before starting Rx-DMA processing, Tx-DMA processing starts.
This causes FIFO overrun occurs.

This patch fixes the issue by modifying FIFO tx-threshold and DMA descriptor
size like below.

                      Current                   this patch
Rx-descriptor   4Byte+12Byte*341    -->    12Byte*340-4Byte-12Byte
Rx-threshold                   (Not modified)
Tx-descriptor   4Byte+12Byte*341    -->    16Byte-12Byte*340
Rx-threshold    12Byte              -->    2Byte
Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Add recovery processing in case FIFO overrun error occurs with DMA transfer mode.
Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

We found Rx data sometimes drops.(with non-DMA transfer mode)
The cause is read complete condition is not true.

This patch fixes the issue.
Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

During processing 1 command/data series,
SSN should keep LOW.
However, currently, SSN becomes HIGH.
This patch fixes the issue.
Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Currently, in case of reading date from SPI flash,
command is sent twice.
The cause is that tx-memory clear processing is missing .
This patch adds the tx-momory clear processing.
Signed-off-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Revised LCD controller in upcoming TI SoC which is an updated version of
LCDC IP that was found on TI's DA850 SoC supports 2048*2048 resolution.
Below are the encoding details:
Width:
Pixels Per Line = {pplmsb, ppllsb, 4'b1111} + 1
Where pplmsb:1bit==>Raster Timing0[3], ppllsb:6bits==>Raster Timing0[9:4].
And encoded value can range from 16 to 2048 in multiples of 16.

Height:
Lines Per Panel = {lpp_b10, lpp}
Where lpp:10bits==>Raster Timing1[9:0], lpp_b10:1bit==>Raster Timing2[26].
And encoded value can range from 1 to 2048, programmable range is 0 to
2047.

Patch is verified on emulation platform of upcoming SoC for updated
feature and on DA850 platform to make sure nothing existing breaks.
Signed-off-by: NManjunathappa, Prakash <prakash.pm@ti.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

Compiling panel-picodlp.c failed with:

drivers/video/omap2/displays/panel-picodlp.c:560:12: error:
'THIS_MODULE' undeclared here (not in a function)

Add #include <linux/module.h> to get THIS_MODULE definition.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Commit 2a7fade7 ("hwmon: lis3: Power on corrections") caused a
regression on HP laptops with 8bit chip.  Writing CTRL2_BOOT_8B bit seems
clearing the BIOS setup, and no proper interrupt for DriveGuard will be
triggered any more.

Since the init code there is basically only for embedded devices, put a
pdata check so that the problematic initialization will be skipped for
hp_accel stuff.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Cc: Eric Piel <eric.piel@tremplin-utc.net>
Cc: Samu Onkalo <samu.p.onkalo@nokia.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@google.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'hwmon-for-linus' of git://github.com/groeck/linux:
  hwmon: (coretemp) Avoid leaving around dangling pointer
  hwmon: (coretemp) Fixup platform device ID change

* git://github.com/davem330/ide:
  ide-disk: Fix request requeuing

* 'btrfs-3.0' of git://github.com/chrismason/linux:
  Btrfs: force a page fault if we have a shorty copy on a page boundary

Simon Kirby reported that on his RAID setup with idedisk underneath
the box OOMs after a couple of days of runtime. Running with
CONFIG_DEBUG_KMEMLEAK pointed to idedisk_prep_fn() which unconditionally
allocates an ide_cmd struct. However, ide_requeue_and_plug() can be
called more than once per request, either from the request issue or the
IRQ handler path and do blk_peek_request() ends up in idedisk_prep_fn()
repeatedly, allocating a struct ide_cmd everytime and "forgetting" the
previous pointer.

Make sure the code reuses the old allocated chunk.
Reported-and-tested-by: NSimon Kirby <sim@hostway.ca>
Cc: <stable@kernel.org> [ 39.x, 3.0.x ]
Link: http://marc.info/?l=linux-kernel&m=131667641517919
Link: http://lkml.kernel.org/r/20110922072643.GA27232@hostway.caSigned-off-by: NBorislav Petkov <bp@alien8.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The pch_gbe driver has an issue which a network stops,
when receiving traffic is high.
In the case, The link down and up are necessary to return a network.

This patch fixed this issue.
Signed-off-by: NToshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When a link was downed during network use,
there is an issue on which PC freezes.

This patch fixed this issue.
Signed-off-by: NToshiharu Okada <toshiharu-linux@dsn.okisemi.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is a minor change.

Up until kernel 2.6.32, getsockopt(fd, SOL_PACKET, PACKET_STATISTICS,
...) would return total and dropped packets since its last invocation. The
introduction of socket queue overflow reporting [1] changed drop
rate calculation in the normal packet socket path, but not when using a
packet ring. As a result, the getsockopt now returns different statistics
depending on the reception method used. With a ring, it still returns the
count since the last call, as counts are incremented in tpacket_rcv and
reset in getsockopt. Without a ring, it returns 0 if no drops occurred
since the last getsockopt and the total drops over the lifespan of
the socket otherwise. The culprit is this line in packet_rcv, executed
on a drop:

drop_n_acct:
        po->stats.tp_drops = atomic_inc_return(&sk->sk_drops);

As it shows, the new drop number it taken from the socket drop counter,
which is not reset at getsockopt. I put together a small example
that demonstrates the issue [2]. It runs for 10 seconds and overflows
the queue/ring on every odd second. The reported drop rates are:
ring: 16, 0, 16, 0, 16, ...
non-ring: 0, 15, 0, 30, 0, 46, 0, 60, 0 , 74.

Note how the even ring counts monotonically increase. Because the
getsockopt adds tp_drops to tp_packets, total counts are similarly
reported cumulatively. Long story short, reinstating the original code, as
the below patch does, fixes the issue at the cost of additional per-packet
cycles. Another solution that does not introduce per-packet overhead
is be to keep the current data path, record the value of sk_drops at
getsockopt() at call N in a new field in struct packetsock and subtract
that when reporting at call N+1. I'll be happy to code that, instead,
it's just more messy.

[1] http://patchwork.ozlabs.org/patch/35665/
[2] http://kernel.googlecode.com/files/test-packetsock-getstatistics.cSigned-off-by: NWillem de Bruijn <willemb@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If a VM is saved and restored (or migrated) the netback driver will no
longer process any Tx packets from the frontend.  xenvif_up() does not
schedule the processing of any pending Tx requests from the front end
because the carrier is off.  Without this initial kick the frontend
just adds Tx requests to the ring without raising an event (until the
ring is full).

This was caused by 47103041 (net:
xen-netback: convert to hw_features) which reordered the calls to
xenvif_up() and netif_carrier_on() in xenvif_connect().
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>