The struct exynos_drm_manager has to exist for exynos drm sub driver
using encoder and connector. If it isn't NULL to member of struct
exynos_drm_subdrv, will create encoder and connector else will not. And
the is_local member also doesn't need.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The mixer driver and hdmi driver have each operation callback functions
and they is registered to hdmi common driver. Their struct names in hdmi
common driver include display, manager and overlay. It confuses to
appear whose operation and two driver cannot register same operation
callback functions at the same time. Use their struct names to driver
name.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The default_win member in struct mixer_context isn't change its value
after initialized to 0, so it's better using to define.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

HDMI_OVERLAY_NUMBER is specific of mixer driver and be used "windows
layer" term in exynos user manaual, so rename it.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Some members in struct mixer_context aren't used and the define
HDMI_OVERLAY_NUMBER is unused in hdmi driver, remove them.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

When the void pointer type variable is assigned to the specific pointer
type variable, don't need to do type conversion.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

NV12, NV12M and NV12MT are added to format list of plane to use these
formats for hdmi vp layer.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

this patch fixes that buf->pages is allocated two times when it allocates
physically continuous memory region and removes unnecessary codes.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

1M section, 64k page count also should be rounded up so this patch
rounds up them and caculates page count of them properly and also
checks memory flags from user.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for "doublebuffering". By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these users, we should therefore reject any userspace request to
create a screen that requires a buffer larger than the framebuffer
originally allocated.

References: https://bugs.freedesktop.org/show_bug.cgi?id=38138Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There should be VM_MIXEDMAP, not VM_PFNMAP, because udl_gem_fault() inserts
pages via vm_insert_page(). Other drm/gem drivers already do this.
Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

On pre-R600 asics, the SpeedFanControl table is not
executed as part of ASIC_Init as it is on newer asics.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=29412Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

The code tries various methods for retreiving the BIOS data. However
it doesn't clear the bios->data pointer between the iterations.

In some cases, the shadow() method will fail and not update bios->data
at all, which will cause us to "score" the old data and incorrectly
attribute that score to the new method. This can cause double frees
later when disposing of the unused data.

Additionally, we were not freeing the data for methods that fail the
score test (we only freed when a "best" is superseeded, not when the
new method has a lower score than the exising "best"). Fix that as well.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

From b15b244d6e6e20964bd4b85306722cb60c3c0809 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon, 2 Apr 2012 13:28:18 +1000
Subject:

Under some circumstances, pci_map_rom() can return a valid mapping
but a size of 0 (if it cannot find an image in the header).

This causes nouveau to try to kmalloc() a 0 sized pointer and
dereference it, which crashes.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Ben H. reported that building nouveau into the kernel and power supply
as a module was broken.

Just have nouveau select it, like radeon does.
Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

... and mtdchar_notifier along with it; just have ->drop_inode() that
will unconditionally get evict them instead of dances on mtd device
removal and use simple_pin_fs() instead of kern_mount()
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Since 3.2.12 and 3.3, some systems are failing to boot with a BUG_ON.
Some other systems using the pata_jmicron driver fail to boot because no
disks are detected.  Passing pcie_aspm=force on the kernel command line
works around it.

The cause: commit 4949be16 ("PCI: ignore pre-1.1 ASPM quirking when
ASPM is disabled") changed the behaviour of pcie_aspm_sanity_check() to
always return 0 if aspm is disabled, in order to avoid cases where we
changed ASPM state on pre-PCIe 1.1 devices.

This skipped the secondary function of pcie_aspm_sanity_check which was
to avoid us enabling ASPM on devices that had non-PCIe children, causing
trouble later on.  Move the aspm_disabled check so we continue to honour
that scenario.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=42979 and
          http://bugs.debian.org/665420

Reported-by: Romain Francoise <romain@orebokech.com> # kernel panic
Reported-by: Chris Holland <bandidoirlandes@gmail.com> # disk detection trouble
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: stable@vger.kernel.org
Tested-by: Hatem Masmoudi <hatem.masmoudi@gmail.com> # Dell Latitude E5520
Tested-by: janek <jan0x6c@gmail.com> # pata_jmicron with JMB362/JMB363
[jn: with more symptoms in log message]
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use the SET_SYSTEM_SLEEP_PM_OPS macro to initialise the suspend/resume
functions in the new PM API.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

There's no difference in supporting S3 and S4 for virtio devices: the
vqs have to be re-created as the device has to be assumed to be reset at
restore-time.  Since S4 already handles this situation, we can directly
use the same code and callbacks for S3 support.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

restore_common() was shared between restore and thaw callbacks.  With
thaw gone, we don't need restore_common() anymore.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

The thaw operation was used by the balloon driver, but after the last
commit there's no reason to have separate thaw and restore callbacks.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

There's no reason stats update after restore can't work.  If a host
requested for stats, and before servicing the request, the guest entered
S4, upon restore, the stats request can still be processed and sent off
to the host.
Signed-off-by: NAmit Shah <amit.shah@redhat.com>

Usage of /etc/modprobe.conf file was deprecated by module-init-tools and
is no longer parsed by new kmod tool. References to this file are
replaced in Documentation, comments and Kconfig according to the
context.

There are also some references to the old /etc/modules.conf from 2.4
kernels that are being removed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Using a u64 here creates an endian bug.  We store a u32 number in the
top byte which is a larger number than intended on big endian systems.
There is no reason to use a 64 bit data type here, I guess it was just
an oversight.

I removed the initialization to zero as well.  It's needed with a u64
but with a u32, the variable gets initialized properly inside the call
to acpi_os_read_port().
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

On a system on the thermal limit these are quite noisy and flood the logs.
Better would be a counter anyways. But given that we don't even have
anything for normal throttling this doesn't seem to be urgent either.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Quoth Dmitry Torokhov:
In addition to bus notifier we do install device notifier explicitly
so it might fire up early. The easiest fox would be to move
acpi_video_bus_start_devices() after input_allocate_device() but
before input_register_device() - unregistered input devices can handle
input_event() calls just fine.

May fix crashes reported in:
https://bugzilla.kernel.org/show_bug.cgi?id=40672Signed-off-by: NIgor Murzov <e-mail@date.by>
Signed-off-by: NLen Brown <len.brown@intel.com>

It is always better to check return values, so add some new checks and
correct existing ones.

v2: Be consistent and don't mix errors from -E* and AE_* namespaces.
Signed-off-by: NIgor Murzov <e-mail@date.by>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPI 5.0 adds the BGRT, a table that contains a pointer to the firmware
boot splash and associated metadata. This simple driver exposes it via
/sys/firmware/acpi in order to allow bootsplash applications to draw their
splash around the firmware image and reduce the number of jarring graphical
transitions during boot.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Drivers may wish to add entries to /sys/firmware/acpi, so export acpi_kobj
in order to let them do that.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Make sure the removal of mappings uses the same logic that put the
mappings in place.
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The function apei_estatus_print() and apei_estatus_check() forget to move ahead
the gdata pointer when dealing with multiple generic error data sections.
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Clean the redundant codes of apci_bus_get_power_flags().
Signed-off-by: NAlex He <alex.he@amd.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The acpi_processor_cst_has_changed() function is invoked from a
CPU_ONLINE or CPU_DEAD function, which might well execute on CPU 0
even though the CPU being hotplugged is some other CPU.  In addition,
acpi_processor_cst_has_changed() invokes smp_processor_id() without
protection, resulting in splats when onlining CPUs.

This commit therefore changes the smp_processor_id() to pr->id, as is
used elsewhere in the code, for example, in acpi_processor_add().
Signed-off-by: NPaul E. McKenney <paul.mckenney@linaro.org>
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Tested-by: NYong Zhang <yong.zhang0@gmail.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

... so that acpi_unmap()'s behavior gets in sync with acpi_map()'s.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

During testing pci root bus removal, found some root bus bridge is not freed.
If booting with pnpacpi=off, those hostbridge could be freed without problem.
It turns out that some devices reference are not released during acpi_pnp_match.
that match should not hold one device ref during every calling.
Add pu_device calling before returning.
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: NLen Brown <len.brown@intel.com>

The function acpi_processor_add is stored in the ops.add field of a
acpi_driver structure.  This function is then called in
acpi_bus_driver_init.  On failure, this function clears the field
device->driver_data, but does not free its contents.  Thus the free has to
be done by the add function.  In acpi_processor_add, the corresponding
value is pr.  This value is currently freed on failure before storing it in
device->driver_data, but not after.  This free is added in the error
handling code at the end of the function.  The per_cpu variable
processors is also cleared so that it does not refer to a dangling pointer.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Reviewed-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The current code incorrectly assumes that
(1) the APEI register bit width is always 8, 16, 32, or 64 and
(2) the APEI register bit width is always equal to the APEI
    register access width.

ERST serialization instructions entries such as:

[030h 0048   1]                       Action : 00 [Begin Write Operation]
[031h 0049   1]                  Instruction : 03 [Write Register Value]
[032h 0050   1]        Flags (decoded below) : 01
                      Preserve Register Bits : 1
[033h 0051   1]                     Reserved : 00

[034h 0052  12]              Register Region : [Generic Address Structure]
[034h 0052   1]                     Space ID : 00 [SystemMemory]
[035h 0053   1]                    Bit Width : 03
[036h 0054   1]                   Bit Offset : 00
[037h 0055   1]         Encoded Access Width : 03 [DWord Access:32]
[038h 0056   8]                      Address : 000000007F2D7038

[040h 0064   8]                        Value : 0000000000000001
[048h 0072   8]                         Mask : 0000000000000007

break this assumption by yielding:
  [Firmware Bug]: APEI: Invalid bit width in GAR [0x7f2d7038/3/0]

I have found no ACPI specification requirements corresponding
with the above assumptions.  There is even a good example in
the Serialization Instruction Entries section (ACPI 4.0 section
17.4,1.2, ACPI 4.0a section 2.5.1.2, ACPI 5.0 section 18.5.1.2)
that mentions a serialization instruction with a bit range of
[6:2] which is 5 bits wide, _not_ 8, 16, 32, or 64 bits wide.

Compile and boot tested with 3.3.0-rc7 on a IBM HX5.
Signed-off-by: NGary Hade <garyhade@us.ibm.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Some APEI firmware implementation will access injected address
specified in param1 to trigger the error when injecting memory
error, which means if one SRAR error is injected, the crash
always happens because it is executed in kernel context. This
new parameter can disable trigger action and control is taken
over by the user. In this way, an SRAR error can happen in user
context instead of crashing the system. This function is highly
depended on BIOS implementation so please ensure you know the
BIOS trigger procedure before you enable this switch.

v2:
  notrigger should be created together with param1/param2
Tested-by: NTony Luck <tony.luck@lintel.com>
Signed-off-by: NChen Gong <gong.chen@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

On the platforms with ACPI4.x support, parameter extension
is not always doable, which means only parameter extension
is enabled, einj_param can take effect.

v2->v1: stopping early in einj_get_parameter_address for einj_param
Signed-off-by: NChen Gong <gong.chen@linux.intel.com>
Acked-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>