Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 13 1月, 2015 1 次提交
  3. 12 1月, 2015 3 次提交
  5. 09 1月, 2015 1 次提交
  7. 08 1月, 2015 4 次提交
  9. 07 1月, 2015 12 次提交
  11. 06 1月, 2015 18 次提交
    • M
      virtio_pci: document why we defer kfree · a1eb03f5
      由 Michael S. Tsirkin 提交于 
      The reason we defer kfree until release function is because it's a
general rule for kobjects: kfree of the reference counter itself is only
legal in the release function.

Previous patch didn't make this clear, document this in code.

Cc: stable@vger.kernel.org
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      a1eb03f5
    • S
      virtio_pci: defer kfree until release callback · 63bd62a0
      由 Sasha Levin 提交于 
      A struct device which has just been unregistered can live on past the
point at which a driver decides to drop it's initial reference to the
kobject gained on allocation.

This implies that when releasing a virtio device, we can't free a struct
virtio_device until the underlying struct device has been released,
which might not happen immediately on device_unregister().

Unfortunately, this is exactly what virtio pci does:
it has an empty release callback, and frees memory immediately
after unregistering the device.

This causes an easy to reproduce crash if CONFIG_DEBUG_KOBJECT_RELEASE
it enabled.

To fix, free the memory only once we know the device is gone in the release
callback.

Cc: stable@vger.kernel.org
Signed-off-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      63bd62a0
    • M
      virtio_pci: device-specific release callback · 945399a8
      由 Michael S. Tsirkin 提交于 
      It turns out we need to add device-specific code
in release callback. Move it to virtio_pci_legacy.c.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      945399a8
    • M
      virtio: make del_vqs idempotent · 80e9541f
      由 Michael S. Tsirkin 提交于 
      Our code calls del_vqs multiple times, assuming
it's idempotent.

commit 3ec7a77b
    virtio_pci: free up vq->priv
broke this assumption, by adding kfree there,
so multiple calls cause double free.

Fix it up.

Fixes: 3ec7a77bReported-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      80e9541f
    • A
      drm/i915: Support creation of unbound wc user mappings for objects · 1816f923
      由 Akash Goel 提交于 
      This patch provides support to create write-combining virtual mappings of
GEM object. It intends to provide the same funtionality of 'mmap_gtt'
interface without the constraints and contention of a limited aperture
space, but requires clients handles the linear to tile conversion on their
own. This is for improving the CPU write operation performance, as with such
mapping, writes and reads are almost 50% faster than with mmap_gtt. Similar
to the GTT mmapping, unlike the regular CPU mmapping, it avoids the cache
flush after update from CPU side, when object is passed onto GPU.  This
type of mapping is specially useful in case of sub-region update,
i.e. when only a portion of the object is to be updated. Using a CPU mmap
in such cases would normally incur a clflush of the whole object, and
using a GTT mmapping would likely require eviction of an active object or
fence and thus stall. The write-combining CPU mmap avoids both.

To ensure the cache coherency, before using this mapping, the GTT domain
has been reused here. This provides the required cache flush if the object
is in CPU domain or synchronization against the concurrent rendering.
Although the access through an uncached mmap should automatically
invalidate the cache lines, this may not be true for non-temporal write
instructions and also not all pages of the object may be updated at any
given point of time through this mapping.  Having a call to get_pages in
set_to_gtt_domain function, as added in the earlier patch 'drm/i915:
Broaden application of set-domain(GTT)', would guarantee the clflush and
so there will be no cachelines holding the data for the object before it
is accessed through this map.

The drm_i915_gem_mmap structure (for the DRM_I915_GEM_MMAP_IOCTL) has been
extended with a new flags field (defaulting to 0 for existent users). In
order for userspace to detect the extended ioctl, a new parameter
I915_PARAM_MMAP_VERSION has been added for versioning the ioctl interface.

v2: Fix error handling, invalid flag detection, renaming (ickle)

v3: Rebase to latest drm-intel-nightly codebase

The new mmapping is exercised by igt/gem_mmap_wc,
igt/gem_concurrent_blit and igt/gem_gtt_speed.

Change-Id: Ie883942f9e689525f72fe9a8d3780c3a9faa769a
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1816f923
    • C
      drm/i915: Broaden application of set-domain(GTT) · 43566ded
      由 Chris Wilson 提交于 
      Previously, this was restricted to only operate on bound objects - to
make pointer access through the GTT to the object coherent with writes
to and from the GPU. A second usecase is drm_intel_bo_wait_rendering()
which at present does not function unless the object also happens to
be bound into the GGTT (on current systems that is becoming increasingly
rare, especially for the typical requests from mesa). A third usecase is
a future patch wishing to extend the coverage of the GTT domain to
include objects not bound into the GGTT but still in its coherent cache
domain. For the latter pair of requests, we need to operate on the
object regardless of its bind state.

v2: After discussion with Akash, we came to the conclusion that the
get-pages was required in order for accurate domain tracking in the
corner cases (like the shrinker) and also useful for ensuring memory
coherency with earlier cached CPU mmaps in case userspace uses exotic
cache bypass (non-temporal) instructions.

v3: Fix the inactive object check.

v4: Rebase to latest drm-intel-nightly codebase
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NAkash Goel <akash.goel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      43566ded
    • B
      drm/i915: Add some extra guards in evict_vm · b9b5dce5
      由 Ben Widawsky 提交于 
      v2: Use WARN_ONs (Daniel)

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b9b5dce5
    • D
      drm/i915: Include i915_gem_evict.c kerneldoc into the drm docbook · 7838a63a
      由 Daniel Vetter 提交于 
      I've written these long before we've had a reasonable docbook
structure, and naturally they've gone stale. Fix this up asap.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      7838a63a
    • K
      drm/i915: Make sample_c messages go faster on Haswell. · 94411593
      由 Kenneth Graunke 提交于 
      Haswell significantly improved the performance of sampler_c messages,
but the optimization appears to be off by default.  Later platforms
remove this bit, and apparently always enable the optimization.

Improves performance in "Counter Strike: Global Offensive" by 18%
at default settings on Iris Pro.

This may break sampling of paletted formats (P8/A8P8/P8A8).  It's
unclear whether it affects sampling of paletted formats in general,
or just the sample_c message (which is never used).

While libva does have support for using paletted formats (primarily
for OSDs), that support appears to have been broken for at least a
year, so I couldn't observe a regression from this:

I tried to get libva-intel to use paletted formats, and observe a
regression...but the only thing I found that used it was mplayer's OSD
(on screen display).  Even without my patch, the colors were totally
wrong with that, and it's according to a few distro wikis, that's been
the case for over a year.

If libva's code for paletted formats /is/ broken, they could always
add code to disable this bit using the command validator when fixing
it.

Further investigation from Haihao shows that libva mplayer OSD seems
to work at least on his setup (still unclear what's wron with Ken's),
and that it's not affected by this patch. Quoting the discussion
between Haihao and Ken:

> > > If you use "-vo gl" or "-vo xv", the OSD is solid white text with a black
> > > border around it.  I presume that it's supposed to be white with vaapi as
> > > well, but I guess I'm not entirely sure.
> > >
> > > It's possible that the optimization doesn't affect the palette as long as
> > > you never use sample_c with the paletted textures.
> >
> > I verified the palette takes effect in the following way:
> >
> > 1. Only support P8A8 format in the driver
> >
> > 2. ran the above command and I saw white OSD text
> >
> > 3. Only support P4A4 format in the driver and don't use
> > 3DSTATE_SAMPLER_PALETTE_LOAD0 to load the value to the texture palette,
> > so the palette keeps unchanged.
> >
> > 4. ran the above command and I saw black OSD text.
> >
> > 5. Load the right value to the texture palette and ran the above command
> > again, I saw white OSD text.
> >
> > Hence I think sample_c with the paletted textures is used in the driver.
>
> That sounds like the palette is actually working, then.  Great :)
>
> I doubt that libva would use sample_c - sampling with a shadow comparison?
> It looks like it just uses sample and sample+killpix.

You are right, libva driver doesn't use sample_c message.

> I'm pretty sure the sample_c optimization just uses the palette memory as
> storage for some stuff, so it's quite possible it just works if you're
> only using sample and sample+killpix.

Thanks for the explanation, it makes sense to me.
Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
[danvet: Add wa name from Ville's review to the comment and copypaste
the explanation why we don't care about libva (already broken) from
Ken. Also add conclusion from libva devs that&why this is all fine.]
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: "Xiang, Haihao" <haihao.xiang@intel.com>
Cc: libva@lists.freedesktop.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      94411593
    • H
      ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu() · d02dc27d
      由 Hanjun Guo 提交于 
      acpi_map_lsapic() will allocate a logical CPU number and map it to
physical CPU id (such as APIC id) for the hot-added CPU, it will also
do some mapping for NUMA node id and etc, acpi_unmap_lsapic() will
do the reverse.

We can see that the name of the function is a little bit confusing and
arch (IA64) dependent so rename them as acpi_(un)map_cpu() to make arch
agnostic and explicit.
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d02dc27d
    • H
      ACPI / processor: Convert apic_id to phys_id to make it arch agnostic · af8f3f51
      由 Hanjun Guo 提交于 
      apic_id in MADT table is the CPU hardware id which identify
it self in the system for x86 and ia64, OSPM will use it for
SMP init to map APIC ID to logical cpu number in the early
boot, when the DSDT/SSDT (ACPI namespace) is scanned later, the
ACPI processor driver is probed and the driver will use acpi_id
in DSDT to get the apic_id, then map to the logical cpu number
which is needed by the processor driver.

Before ACPI 5.0, only x86 and ia64 were supported in ACPI spec,
so apic_id is used both in arch code and ACPI core which is
pretty fine. Since ACPI 5.0, ARM is supported by ACPI and
APIC is not available on ARM, this will confuse people when
apic_id is both used by x86 and ARM in one function.

So convert apic_id to phys_id (which is the original meaning)
in ACPI processor dirver to make it arch agnostic, but leave the
arch dependent code unchanged, no functional change.
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      af8f3f51
    • R
      ACPI / PM: Fix PM initialization for devices that are not present · 1b1f3e16
      由 Rafael J. Wysocki 提交于 
      If an ACPI device object whose _STA returns 0 (not present and not
functional) has _PR0 or _PS0, its power_manageable flag will be set
and acpi_bus_init_power() will return 0 for it.  Consequently, if
such a device object is passed to the ACPI device PM functions, they
will attempt to carry out the requested operation on the device,
although they should not do that for devices that are not present.

To fix that problem make acpi_bus_init_power() return an error code
for devices that are not present which will cause power_manageable to
be cleared for them as appropriate in acpi_bus_get_power_flags().
However, the lists of power resources should not be freed for the
device in that case, so modify acpi_bus_get_power_flags() to keep
those lists even if acpi_bus_init_power() returns an error.
Accordingly, when deciding whether or not the lists of power
resources need to be freed, acpi_free_power_resources_lists()
should check the power.flags.power_resources flag instead of
flags.power_manageable, so make that change too.

Furthermore, if acpi_bus_attach() sees that flags.initialized is
unset for the given device, it should reset the power management
settings of the device and re-initialize them from scratch instead
of relying on the previous settings (the device may have appeared
after being not present previously, for example), so make it use
the 'valid' flag of the D0 power state as the initial value of
flags.power_manageable for it and call acpi_bus_init_power() to
discover its current power state.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
      1b1f3e16
    • B
      qla2xxx: fix busy wait regression · 975f7d46
      由 Bruno Prémont 提交于 
      Commit e05fe292 (qla2xxx: Honor FCP_RSP retry delay timer field.)
causes systems to busy-wait for about 3 minutes after boot prior to
detecting SAN disks.

During this wait period one kworker is running full-time
(though /proc/<pid>/stack has no useful data). Another kworker is
waiting for IO to complete during that whole time period.

Looking at drivers/scsi/qla2xxx/qla_os.c, fcport->retry_delay_timestamp
has a special value of 0 though that 0 value forces system to wait when
jiffies is very large value (e.g. 4294952605 - "negative" value when
signed on 32bit systems).
Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
Acked-by: NChad Dupuis <chad.dupuis@qlogic.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      975f7d46
    • D
      drm/radeon: integer underflow in radeon_cp_dispatch_texture() · dd5a74f2
      由 Dan Carpenter 提交于 
      The test:

	if (size > RADEON_MAX_TEXTURE_SIZE) {

"size" is an integer and it's controled by the user so it can be
negative and the test can underflow.  Later we use "size" in:

	dwords = size / 4;
	...
	RADEON_COPY_MT(buffer, data, (int)(dwords * sizeof(u32)));

It causes memory corruption to copy a negative size buffer.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      dd5a74f2
    • A
      drm/radeon: adjust default bapm settings for KV · 02ae7af5
      由 Alex Deucher 提交于 
      Enabling bapm seems to cause clocking problems on some
KV configurations.  Disable it by default for now.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
      02ae7af5
    • A
      drm/radeon: properly filter DP1.2 4k modes on non-DP1.2 hw · 410cce2a
      由 Alex Deucher 提交于 
      The check was already in place in the dp mode_valid check, but
radeon_dp_get_dp_link_clock() never returned the high clock
mode_valid was checking for because that function clipped the
clock based on the hw capabilities.  Add an explicit check
in the mode_valid function.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=87172Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc:stable@vge.kernel.org
      410cce2a
    • A
      drm/radeon: fix sad_count check for dce3 · 5665c3eb
      由 Alex Deucher 提交于 
      Make it consistent with the sad code for other asics to deal
with monitors that don't report sads.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=89461Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
      5665c3eb
    • A
      drm/radeon: KV has three PPLLs (v2) · fbedf1c3
      由 Alex Deucher 提交于 
      Enable all three in the driver.  Early documentation
indicated the 3rd one was used for something else, but
that is not the case.

v2: handle disable as well
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
      fbedf1c3
  13. 05 1月, 2015 1 次提交