This series of patches fix various issues in STI drm driver.
Now HDMI i2c adapter could be selected in device tree
and plug detection doesn't use gpio anymore.
I also had fix some signal timing problems after testing the driver
on more hardware.
The remaining patches attemps to simplify the code and prepare
the next evolutions like DVO and auxiliary CRTC support
The changes could be fetch here:
http://git.linaro.org/people/benjamin.gaignard/kernel.git
on drm-sti-fixes-2014-12-04 branch
Benjamin Gaignard (9):
drm: sti: allow to change hdmi ddc i2c adapter
drm: sti: remove gpio for HDMI hot plug detection
drm: sti: clear all mixer control
drm: sti: simplify gdp code
drm: sti: remove event lock while disabling vblank
drm: sti: fix hdmi avi infoframe
drm: sti: use drm_crtc_vblank_{on/off} instead of drm_vblank_{on/off}
drm: sti: prepare sti_tvout to support auxiliary crtc
drm: sti: fix delay in VTG programming
.../devicetree/bindings/gpu/st,stih4xx.txt | 3 +-
drivers/gpu/drm/sti/sti_drm_crtc.c | 10 +--
drivers/gpu/drm/sti/sti_gdp.c | 39 ++++-----
drivers/gpu/drm/sti/sti_hdmi.c | 84 +++++++++++---------
drivers/gpu/drm/sti/sti_hdmi.h | 6 +-
drivers/gpu/drm/sti/sti_mixer.c | 9 +++
drivers/gpu/drm/sti/sti_mixer.h | 1 +
drivers/gpu/drm/sti/sti_tvout.c | 92 ++++++++++++----------
drivers/gpu/drm/sti/sti_vtg.c | 25 +++++-
9 files changed, 160 insertions(+), 109 deletions(-)
--
1.9.1
Hello Everyone,
This is yet another attempt to finally make Exynos SYSMMU driver fully
integrated with DMA-mapping subsystem.
Previous approach is available here: https://lkml.org/lkml/2014/8/5/183
I meantime, there have been a discussion about the way the iommu driver
should be integrated with dma-mapping subsystem, which resulted in "[RFC
PATCH v3 0/7] Introduce automatic DMA configuration for IOMMU masters"
patches prepared by Will Deacon:
http://www.spinics.net/lists/arm-kernel/msg362076.html
Those patches removed the need to use bus-specific notifiers for
initialization.
Main changes since previous version of my patches:
1. rebased onto "[RFC PATCH v3 0/7] Introduce automatic DMA
configuration for IOMMU masters" patches, changed initialization from
bus notifiers to DT related callbacks
2. removed support for separate IO address spaces - this will be
discussed separately after the basic support gets merged
3. removed support for power domain notifier-based runtime power
management - this also will be discussed separately later
I hope that the driver with above changes will be easier to be merged to
v3.18.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Patch summary:
Marek Szyprowski (18):
arm: dma-mapping: arm_iommu_attach_device: automatically set
max_seg_size
arm: exynos: bind power domains earlier, on device creation
drm: exynos: detach from default dma-mapping domain on init
clk: exynos: add missing smmu_g2d clock and update comments
ARM: DTS: Exynos4: add System MMU nodes
iommu: exynos: don't read version register on every tlb operation
iommu: exynos: remove unused functions
iommu: exynos: remove useless spinlock
iommu: exynos: refactor function parameters to simplify code
iommu: exynos: remove unused functions, part 2
iommu: exynos: remove useless device_add/remove callbacks
iommu: exynos: add support for binding more than one sysmmu to master
device
iommu: exynos: add support for runtime_pm
iommu: exynos: rename variables to reflect their purpose
iommu: exynos: document internal structures
iommu: exynos: remove excessive includes and sort others
alphabetically
iommu: exynos: init from dt-specific callback instead of initcall
iommu: exynos: add callback for initializing devices from device tree
arch/arm/boot/dts/exynos4.dtsi | 117 +++++++
arch/arm/boot/dts/exynos4210.dtsi | 23 ++
arch/arm/boot/dts/exynos4x12.dtsi | 82 +++++
arch/arm/mach-exynos/pm_domains.c | 12 +-
arch/arm/mm/dma-mapping.c | 16 +
drivers/clk/samsung/clk-exynos4.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 +
drivers/iommu/exynos-iommu.c | 494 ++++++++++++++----------------
include/dt-bindings/clock/exynos4.h | 10 +-
9 files changed, 483 insertions(+), 275 deletions(-)
--
1.9.2
Hello,
This is another approach to finish support for reserved memory regions
defined in device tree. Previous attempts
(http://lists.linaro.org/pipermail/linaro-mm-sig/2014-February/003738.html
and https://lkml.org/lkml/2014/7/14/108) ended in merging parts of the
code and documentation. Merged patches allow to reserve memory, but
there is still no reserved memory drivers nor any code that actually
uses reserved memory regions.
The final conclusion from the above mentioned threads is that there is
no automated reserved memory initialization. All drivers that want to
use reserved memory, should initialize it on their own.
This patch series provides two driver for reserved memory regions (one
based on CMA and one based on dma_coherent allocator). The main
improvement comparing to the previous version is removal of automated
reserved memory for every device and support for named memory regions.
Those patches are for merging, rebased on top of recent linux-next tree.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Changes since v1 (https://lkml.org/lkml/2014/8/26/339):
- removed patches for named reserved regions - they will be discussed
separately
- added a check for 'no-map' property to dma coherent allocator
(suggested by Laura Abbott)
- removed example code for s5p-mfc driver
Changes since '[PATCH v2 RESEND 0/4] CMA & device tree, once again' version:
(https://lkml.org/lkml/2014/7/14/108)
- added return error value to of_reserved_mem_device_init()
- added support for named memory regions (so more than one region can be
defined per device)
- added usage example - converted custom reserved memory code used by
s5p-mfc driver to the generic reserved memory handling code
Patch summary:
Marek Szyprowski (3):
drivers: of: add return value to of_reserved_mem_device_init
drivers: dma-coherent: add initialization from device tree
drivers: dma-contiguous: add initialization from device tree
drivers/base/dma-coherent.c | 145 ++++++++++++++++++++++++++++++++++------
drivers/base/dma-contiguous.c | 71 ++++++++++++++++++++
drivers/of/of_reserved_mem.c | 3 +-
include/linux/cma.h | 3 +
include/linux/of_reserved_mem.h | 9 ++-
mm/cma.c | 62 ++++++++++++++---
6 files changed, 259 insertions(+), 34 deletions(-)
--
1.9.2
Hi All,
I lost the only Android Tablet that I had to hack around and in the market
for new Android Tablet. Needs to be stuff I can buy personally, so Juno /
Vexpress is out the window.
What would you recommend I buy? Below are specific use cases
i. Work on NEON optimizations for Audio libraries (Vorbis, FLAC etc) in
**Android** context.
ii. So, would obviously like to have a reference Android baseline build
that is actively used in Linaro.
Is anyone in LMG using builds available for Nexus10
<http://releases.linaro.org/14.09/android/nexus10> and Nexus7
<http://releases.linaro.org/14.09/android/nexus7-2013> actively right now?
How official are these builds?
Regards,
Vish (Viswanath Puttagunta)
Cell: 972-342-0205
Technical Program Manager
Member Services, Linaro
Hi All,
Does any one have instructions to install Ubuntu natively on Samsung
Chromebook2 that worked for you?
Regards,
Vish (Viswanath Puttagunta)
Cell: 972-342-0205
Technical Program Manager
Member Services, Linaro
Hi,
I wanted to know about the impact of changing PAGE_ALLOC_COSTLY_ORDER value from 3 to 2.
This macro is defined in include/linux/mmzone.h
#define PAGE_ALLOC_COSTLY_ORDER 3
As I know this value should never be changed irrespective of the type of the system.
Is it good to change this value for RAM size: 512MB, 256MB or 128MB?
If anybody have changed this value and experience any kind of problem or benefits please let us know.
We noticed that for one of the Android product with 512MB RAM, the PAGE_ALLOC_COSTLY_ORDER was set to 2.
We could not figure out why this value was decreased from 3 to 2.
As per my analysis, I observed that kmalloc fails little early, if we change this value to 2.
This is also visible from the _slowpath_ in page_alloc.c
Apart from this we could not find any other impact.
If anybody is aware of any other impact, please let us know.
Thank you!
Regards,
Pintu Kumar
On Sun, Sep 14, 2014 at 12:36:43PM +0200, Christian König wrote:
> Yeah, right. Providing the fd to reassign to a fence would indeed reduce the
> create/close overhead.
>
> But it would still be more overhead than for example a simple on demand
> growing ring buffer which then uses 64bit sequence numbers in userspace to
> refer to a fence in the kernel.
>
> Apart from that I'm pretty sure that when we do the syncing completely in
> userspace we need more fences open at the same time than fds are available
> by default.
If you do the syncing completely in userspace you don't need kernel fences
at all. Kernel fences are only required if you sync with a different
process (where the pure userspace syncing might not work out) or with
different devices.
tbh I don't see any use-case at all where you'd need 10k such fences. That
means your driver gets to deal with 2 kinds of fences, but so be it. Since
not using fds for cross-device or cross-process syncing imo just doesn't
make sense, so that one pretty much will have to stick.
> As long as our internal handle or sequence based fence are easily
> convertible to a fence fd I actually don't really see a problem with that.
> Going to hack that approach into my prototype and then we can see how bad
> the code looks after all.
My plan for i915 is to start out with fd fences only, and once we have
some clarity on the exact requirements probably add some pure
userspace-controlled fences for tightly coupled stuff. Those might be
fully internal to the opencl userspace driver though and never get out of
there, ever.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch