Hello Dave,
Those patches improve audio info frame management, add pixel formats
support and fix minor issues.
The following changes since commit e4bf44b3b558742fb7c58b4d34e206c8942f07e6:
drm/modes: Print the mode status in human readable form (2015-02-03
11:13:27 +1000)
are available in the git repository at:
http://git.linaro.org/people/benjamin.gaignard/kernel.git
drm-sti-next-2015-02-04
for you to fetch changes up to cffe1e89dc9bf541a39d9287ced7c5addff07084:
drm: sti: HDMI add audio infoframe (2015-02-05 16:21:19 +0100)
----------------------------------------------------------------
Arnaud Pouliquen (1):
drm: sti: HDMI add audio infoframe
Benjamin Gaignard (1):
drm: sti: add support of ABGR8888 for gdp plane
Fabien Dessenne (1):
drm: sti: add support of XBGR8888 for gdp plane
Jassi Brar (1):
drm: sti: fix check for clk_pix_main
Vincent Abriou (1):
drm: sti: fix static checker warning in sti_awg_utils
drivers/gpu/drm/sti/sti_awg_utils.c | 2 -
drivers/gpu/drm/sti/sti_gdp.c | 11 +++
drivers/gpu/drm/sti/sti_hdmi.c | 179 +++++++++++++++++++++++++++---------
drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
4 files changed, 149 insertions(+), 45 deletions(-)
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Hello Everyone,
Based on review comments received, I've split my earlier patchset on
'dma-buf constraints-enabled allocation' [1] into 2 sets:
- first one is this one, to use dma_parms and related parameters from
struct device to share constraints, and then to use these constraints in
dma-buf to help find the least common constraint set that could then be
used by exporters to decide on allocation.
This is a partial re-write of what Rob Clark proposed some while ago [2];
I've tried to take care of review comments on his patchset, but any errors
and omissions are, ofcourse, mine.
- Second part, one which I'm working on, and will post soon, aims at adding
allocator-helpers in dma-buf framework which could use this constraint
information to help choose the right allocator from a list.
While I work on the second part, I thought of sending the RFC for this one,
to get feedback on whether this mechanism seems ok to everyone.
[1] https://lkml.org/lkml/2014/10/10/340
[2] https://lkml.org/lkml/2012/7/19/285
Rob Clark (1):
device: add dma_params->max_segment_count
Sumit Semwal (1):
dma-buf: add helpers for sharing attacher constraints with dma-parms
drivers/dma-buf/dma-buf.c | 134 +++++++++++++++++++++++++++++++++++++++++++-
include/linux/device.h | 1 +
include/linux/dma-buf.h | 22 ++++++++
include/linux/dma-mapping.h | 19 +++++++
4 files changed, 175 insertions(+), 1 deletion(-)
--
1.9.1
Hi Michel,
On 22 January 2015 at 12:30, Michel Dänzer <michel(a)daenzer.net> wrote:
> From: Michel Dänzer <michel.daenzer(a)amd.com>
>
> It was causing the return value of fence_is_signaled to be ignored, making
> reservation objects signal too early.
>
Thanks; pushed to my for-next.
> Cc: stable(a)vger.kernel.org
> Reviewed-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com>
> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
> Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com>
> ---
> drivers/dma-buf/reservation.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index 3c97c8f..8a37af9 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -402,8 +402,6 @@ reservation_object_test_signaled_single(struct fence *passed_fence)
> int ret = 1;
>
> if (!test_bit(FENCE_FLAG_SIGNALED_BIT, &lfence->flags)) {
> - int ret;
> -
> fence = fence_get_rcu(lfence);
> if (!fence)
> return -1;
> --
> 2.1.4
>
--
Thanks and best regards,
Sumit.
Hi Robin!
On 22 January 2015 at 00:26, Robin Murphy <robin.murphy(a)arm.com> wrote:
> Hi Sumit,
>
>
> On 21/01/15 04:16, Sumit Semwal wrote:
>>
>> From: Rob Clark <robdclark(a)gmail.com>
>>
>> For devices which have constraints about maximum number of segments in
>> an sglist. For example, a device which could only deal with contiguous
>> buffers would set max_segment_count to 1.
>>
>> The initial motivation is for devices sharing buffers via dma-buf,
>> to allow the buffer exporter to know the constraints of other
>> devices which have attached to the buffer. The dma_mask and fields
>> in 'struct device_dma_parameters' tell the exporter everything else
>> that is needed, except whether the importer has constraints about
>> maximum number of segments.
>>
>> Signed-off-by: Rob Clark <robdclark(a)gmail.com>
>> [sumits: Minor updates wrt comments on the first version]
>> Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org>
>> ---
>> include/linux/device.h | 1 +
>> include/linux/dma-mapping.h | 19 +++++++++++++++++++
>> 2 files changed, 20 insertions(+)
>>
>> diff --git a/include/linux/device.h b/include/linux/device.h
>> index fb50673..a32f9b6 100644
>> --- a/include/linux/device.h
>> +++ b/include/linux/device.h
>> @@ -647,6 +647,7 @@ struct device_dma_parameters {
>> * sg limitations.
>> */
>> unsigned int max_segment_size;
>> + unsigned int max_segment_count; /* INT_MAX for unlimited */
>> unsigned long segment_boundary_mask;
>> };
>>
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index c3007cb..38e2835 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -154,6 +154,25 @@ static inline unsigned int
>> dma_set_max_seg_size(struct device *dev,
>> return -EIO;
>> }
>>
>> +#define DMA_SEGMENTS_MAX_SEG_COUNT ((unsigned int) INT_MAX)
>> +
>> +static inline unsigned int dma_get_max_seg_count(struct device *dev)
>> +{
>> + return dev->dma_parms ?
>> + dev->dma_parms->max_segment_count :
>> + DMA_SEGMENTS_MAX_SEG_COUNT;
>> +}
>
>
> I know this copies the style of the existing code, but unfortunately it also
> copies the subtle brokenness. Plenty of drivers seem to set up a dma_parms
> struct just for max_segment_size, thus chances are you'll come across a
> max_segment_count of 0 sooner or later. How badly is that going to break
> things? I posted a fix recently[1] having hit this problem with
> segment_boundary_mask in IOMMU code.
>
Thanks very much for reviewing this code; and apologies for missing
your patch that you mentioned here; sure, I will update my patch
accordingly as well.
>> +
>> +static inline int dma_set_max_seg_count(struct device *dev,
>> + unsigned int count)
>> +{
>> + if (dev->dma_parms) {
>> + dev->dma_parms->max_segment_count = count;
>> + return 0;
>> + } else
>
>
> This "else" is just as unnecessary as the other two I've taken out ;)
>
>
> Robin.
>
> [1]:http://article.gmane.org/gmane.linux.kernel.iommu/8175/
>
>
>> + return -EIO;
>> +}
>> +
>> static inline unsigned long dma_get_seg_boundary(struct device *dev)
>> {
>> return dev->dma_parms ?
>>
>
>
BR,
Sumit.
Hello Everyone,
This is yet another attempt to get Exynos SYSMMU driver with integrated
with IOMMU & DMA-mapping subsystems. The main change from previous
version is a rebase onto latest v3.19-rc4 kernel base, which includes
"automatic DMA configuration for IOMMU masters" patches developed by
Will Deacon. The other change is long avaited addition of DTS patches
for Exynos 5250 and 5420/5422/5800.
Merge plan for this patchset:
1. All iommu related patches (with 'iommu: exynos') can be merged to
iommu tree. They don't have any direct dependencies on the DTS, DRM and
power domain initialization change - without them the driver will simply
not initialize, when no exynos,sysmmu nodes are provided in device tree.
Joerg, could you merge those patches?
2. DTS and power domain patches should go to Samsung Exynos tree. Those
patches depends on my earlier DTS patches for Exynos SoCs, which make
this patchset really complete:
- 'ARM: DTS: Exynos: convert to generic power domain bindings'
(http://www.spinics.net/lists/linux-samsung-soc/msg40584.html)
- '[PATCH v3 0/7] Enable HDMI support on Exynos platforms'
(http://www.spinics.net/lists/arm-kernel/msg391148.html)
Kukjin, could you merge those patches?
3. Exynos DRM fix. This patch in my opinion should go Exynos DRM tree.
Inki, could you merge it?
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Changelog:
v4:
- rebased onto v3.19-rc4 and other Exynos DTS queued patches
- added DTS patch for Exynos 5250 & 5420/5422/5800
v3: http://www.spinics.net/lists/linux-samsung-soc/msg39168.html
- rebased onto "[RFC PATCH v4 0/8] Introduce automatic DMA
configuration for IOMMU masters"
- added some minor fixes for iommu and dma-mapping frameworks
v2: http://thread.gmane.org/gmane.linux.kernel.iommu/6472/
- rebased onto "[RFC PATCH v3 0/7] Introduce automatic DMA
configuration for IOMMU masters" patches:
http://www.spinics.net/lists/arm-kernel/msg362076.html
- changed initialization from bus notifiers to DT related callbacks
- removed support for separate IO address spaces - this will be
discussed separately after the basic support gets merged
- removed support for power domain notifier-based runtime power
management - this also will be discussed separately later
v1: https://lkml.org/lkml/2014/8/5/183
- initial version, feature complete, completely rewrote integration
approach
Patch summary:
Marek Szyprowski (18):
drm: exynos: detach from default dma-mapping domain on init
arm: exynos: pm_domains: add support for devices registered before
arch_initcall
ARM: dts: exynos4: add sysmmu nodes
ARM: dts: exynos5250: add sysmmu nodes
ARM: dts: exynos5420: add sysmmu 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 | 118 +++++++
arch/arm/boot/dts/exynos4210.dtsi | 23 ++
arch/arm/boot/dts/exynos4x12.dtsi | 82 +++++
arch/arm/boot/dts/exynos5250.dtsi | 250 +++++++++++++++
arch/arm/boot/dts/exynos5420.dtsi | 178 +++++++++++
arch/arm/mach-exynos/pm_domains.c | 9 +-
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 +
drivers/iommu/exynos-iommu.c | 490 ++++++++++++++----------------
8 files changed, 884 insertions(+), 269 deletions(-)
--
1.9.2
Hello David,
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
I have tested this branch on top of commit:
"Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes" 00d6a9b6be5885ad38234cd171f6fb18a87faa7c
on drm-fixes 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 | 31 +++++++-
9 files changed, 166 insertions(+), 109 deletions(-)
--
1.9.1