Re: [PATCH] drm/edid: Quirk Vive Pro VR headset non-desktop.
On Wed, 30 May 2018, Daniel Stone wrote: > On 29 May 2018 at 12:52, Lubosz Sarnecki > wrote: >> This adds the Vive Pro's EDID information and >> sets EDID_QUIRK_NON_DESKTOP. > > Trivially: > Reviewed-by: Daniel Stone Cc: sta...@vger.kernel.org # v4.when-was-this-feature-added? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()
On Wed, May 30, 2018 at 02:42:50PM +0100, Robin Murphy wrote:
> On 30/05/18 14:12, Thierry Reding wrote:
> > On Wed, May 30, 2018 at 02:54:46PM +0200, Thierry Reding wrote:
> > > On Wed, May 30, 2018 at 10:59:30AM +0100, Robin Murphy wrote:
> > > > On 30/05/18 09:03, Thierry Reding wrote:
> > > > > From: Thierry Reding
> > > > >
> > > > > Implement this function to enable drivers from detaching from any
> > > > > IOMMU
> > > > > domains that architecture code might have attached them to so that
> > > > > they
> > > > > can take exclusive control of the IOMMU via the IOMMU API.
> > > > >
> > > > > Signed-off-by: Thierry Reding
> > > > > ---
> > > > > Changes in v3:
> > > > > - make API 32-bit ARM specific
> > > > > - avoid extra local variable
> > > > >
> > > > > Changes in v2:
> > > > > - fix compilation
> > > > >
> > > > >arch/arm/include/asm/dma-mapping.h | 3 +++
> > > > >arch/arm/mm/dma-mapping-nommu.c| 4
> > > > >arch/arm/mm/dma-mapping.c | 16
> > > > >3 files changed, 23 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/include/asm/dma-mapping.h
> > > > > b/arch/arm/include/asm/dma-mapping.h
> > > > > index 8436f6ade57d..5960e9f3a9d0 100644
> > > > > --- a/arch/arm/include/asm/dma-mapping.h
> > > > > +++ b/arch/arm/include/asm/dma-mapping.h
> > > > > @@ -103,6 +103,9 @@ extern void arch_setup_dma_ops(struct device
> > > > > *dev, u64 dma_base, u64 size,
> > > > >#define arch_teardown_dma_ops arch_teardown_dma_ops
> > > > >extern void arch_teardown_dma_ops(struct device *dev);
> > > > > +#define arm_dma_iommu_detach_device arm_dma_iommu_detach_device
> > > > > +extern void arm_dma_iommu_detach_device(struct device *dev);
> > > > > +
> > > > >/* do not use this function in a driver */
> > > > >static inline bool is_device_dma_coherent(struct device *dev)
> > > > >{
> > > > > diff --git a/arch/arm/mm/dma-mapping-nommu.c
> > > > > b/arch/arm/mm/dma-mapping-nommu.c
> > > > > index f448a0663b10..eb781369377b 100644
> > > > > --- a/arch/arm/mm/dma-mapping-nommu.c
> > > > > +++ b/arch/arm/mm/dma-mapping-nommu.c
> > > > > @@ -241,3 +241,7 @@ void arch_setup_dma_ops(struct device *dev, u64
> > > > > dma_base, u64 size,
> > > > >void arch_teardown_dma_ops(struct device *dev)
> > > > >{
> > > > >}
> > > > > +
> > > > > +void arm_dma_iommu_detach_device(struct device *dev)
> > > > > +{
> > > > > +}
> > > > > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> > > > > index af27f1c22d93..6d8af08b3e7d 100644
> > > > > --- a/arch/arm/mm/dma-mapping.c
> > > > > +++ b/arch/arm/mm/dma-mapping.c
> > > > > @@ -2400,3 +2400,19 @@ void arch_teardown_dma_ops(struct device *dev)
> > > > > arm_teardown_iommu_dma_ops(dev);
> > > > >}
> > > > > +
> > > > > +void arm_dma_iommu_detach_device(struct device *dev)
> > > > > +{
> > > > > +#ifdef CONFIG_ARM_DMA_USE_IOMMU
> > > > > + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> > > > > +
> > > > > + if (!mapping)
> > > > > + return;
> > > > > +
> > > > > + arm_iommu_release_mapping(mapping);
> > > >
> > > > Potentially freeing the mapping before you try to operate on it is
> > > > never the
> > > > best idea. Plus arm_iommu_detach_device() already releases a reference
> > > > appropriately anyway, so it's a double-free.
> > >
> > > But the reference released by arm_iommu_detach_device() is to balance
> > > out the reference acquired by arm_iommu_attach_device(), isn't it? In
> > > the above, the arm_iommu_release_mapping() is supposed to drop the
> > > final reference which was obtained by arm_iommu_create_mapping(). The
> > > mapping shouldn't go away irrespective of the order in which these
> > > will be called.
> >
> > Going over the DMA/IOMMU code I just remembered that I drew inspiration
> > from arm_teardown_iommu_dma_ops() for the initial proposal which also
> > calls both arm_iommu_detach_device() and arm_iommu_release_mapping().
> > That said, one other possibility to implement this would be to export
> > the 32-bit and 64-bit ARM implementations of arch_teardown_dma_ops()
> > and use that instead. linux/dma-mapping.h implements a stub for
> > architectures that don't provide one, so it should work without any
> > #ifdef guards.
> >
> > That combined with the set_dma_ops() fix in arm_iommu_detach_device()
> > should fix this pretty nicely.
>
> OK, having a second look at the ARM code I see I had indeed overlooked that
> extra reference held until arm_teardown_iommu_dma_ops() - mea culpa - but
> frankly that looks wrong anyway, as it basically defeats the point of
> refcounting the mapping at all. AFAICS arm_setup_iommu_dma_ops() should just
> be made to behave 'normally' by unconditionally dropping the initial
> reference after calling __arm_iommu_attach_device(), then we don't need all
> these odd and confusing release calls dotted around at all.
Good point. I can follow up with a series to fix
Re: [PATCH v2 09/10] ARM: dts: exynos5250: add DSI node
On Wed, May 30, 2018 at 2:16 PM, Maciej Purski wrote: > From: Andrzej Hajda > > The patch adds common part of DSI node for Exynos5250 platforms > and a required mipi-phy node. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Maciej Purski > --- > arch/arm/boot/dts/exynos5250.dtsi | 21 + > 1 file changed, 21 insertions(+) Thanks for changes. I'll take both DTS patches after bindings get accepted and after upcomming merge window. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106735] [amdgpu] all displays reconnect after failed EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=106735 --- Comment #2 from Matthias --- Should I try to force a binary EDID for the connected PSVR? maybe like the solution proposed here: http://hotcashew.com/2013/08/fixing-invalid-edid-in-linux-wit-fglrx/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
>
> Signed-off-by: Neil Armstrong
> Reviewed-by: Hans Verkuil
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/intel_display.h | 20
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c| 13 +
> 4 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index dfd9588..2d65d56 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -23,6 +23,7 @@ config DRM_I915
> select SYNC_FILE
> select IOSF_MBI
> select CRC32
> + select CEC_CORE if CEC_NOTIFIER
> help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 4e7418b..c68d1c8 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -126,6 +126,26 @@ enum port {
>
> #define port_name(p) ((p) + 'A')
>
> +static inline const char *port_identifier(enum port port)
> +{
> + switch (port) {
> + case PORT_A:
> + return "Port A";
> + case PORT_B:
> + return "Port B";
> + case PORT_C:
> + return "Port C";
> + case PORT_D:
> + return "Port D";
> + case PORT_E:
> + return "Port E";
> + case PORT_F:
> + return "Port F";
> + default:
> + return "";
> + }
> +}
Could use a comment to make it clear that this identifier is
expected to remain stable since it's referenced from other drivers.
> +
> enum dpio_channel {
> DPIO_CH0,
> DPIO_CH1
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d436858..b50e51b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * __wait_for - magic wait macro
> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
> bool has_audio;
> bool rgb_quant_range_selectable;
> struct intel_connector *attached_connector;
> + struct cec_notifier *notifier;
"notifier" seems a bit too generic a name. "cec_notifier" would be
better.
Apart from that this seems OK to me
Reviewed-by: Ville Syrjälä
> };
>
> struct intel_dp_mst_encoder;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1baef4a..d522b5b 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> connected = true;
> }
>
> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> +
> return connected;
> }
>
> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> {
> enum drm_connector_status status;
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>
> + if (status != connector_status_connected)
> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> +
> return status;
> }
>
> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> *encoder,
>
> static void intel_hdmi_destroy(struct drm_connector *connector)
> {
> + if (intel_attached_hdmi(connector)->notifier)
> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
> kfree(to_intel_connector(connector)->detect_edid);
> drm_connector_cleanup(connector);
> kfree(connector);
> @@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> u32 temp = I915_READ(PEG_BAND_GAP_DATA);
> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev,
> + port_identifier(port));
> + if (!intel_hdmi->notifier)
> + DRM_DEBUG_KMS("CEC notifier get failed\n");
> }
>
> void intel_hdmi_init(struct drm_i915_private *dev_priv,
> --
> 2.7.4
>
>
[PATCH v4 0/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Thierry Reding An unfortunate interaction between the 32-bit ARM DMA/IOMMU mapping code and Tegra SMMU driver changes to support IOMMU groups introduced a boot- time regression on Tegra124. This was caught very late because none of the standard configurations that are tested on Tegra enable the ARM DMA/ IOMMU mapping code since it is not needed. The reason for the failure is that the GPU found on Tegra uses a special bit in physical addresses to determine whether or not a buffer is mapped through the SMMU. In order to achieve this, the Nouveau driver needs to explicitly understand which buffers are mapped through the SMMU and which aren't. Hiding usage of the SMMU behind the DMA API is bound to fail because the knowledge doesn't exist. Furthermore, the GPU has its own IOMMU and in most cases doesn't need buffers to be physically or virtually contiguous. One notable exception is for compressible buffers which need to be mapped with large pages, which in turn require all the small pages in a large page to be contiguous. This can be achieved with an SMMU mapping, though it isn't currently supported in Nouveau. Since Translating through the SMMU is unnecessary and can have a negative impact on performance for the common case, so we want to avoid it when possible. This series of patches adds a 32-bit ARM specific API that allows a driver to detach the device from the DMA/IOMMU mapping so that it can provide its own implementation for dealing with the SMMU. The second patch makes use of that new API in the Nouveau driver to fix the regression. Thierry Thierry Reding (2): ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device() drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping arch/arm/mm/dma-mapping.c | 12 ++-- drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 + 2 files changed, 19 insertions(+), 6 deletions(-) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 04/11] dt-bindings: msm/disp: remove unused writeback bindings
DPU writeback support is not enabled yet so
removing the bindings. The corresponding driver
code is also removed. The bindings will be added
back when writeback support is reworked and enabled
based on new DRM writeback connector at a later stage.
Signed-off-by: Rajesh Yadav
---
.../devicetree/bindings/drm/msm/dpu-wb.txt | 23 --
1 file changed, 23 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/drm/msm/dpu-wb.txt
diff --git a/Documentation/devicetree/bindings/drm/msm/dpu-wb.txt
b/Documentation/devicetree/bindings/drm/msm/dpu-wb.txt
deleted file mode 100644
index 02845536..000
--- a/Documentation/devicetree/bindings/drm/msm/dpu-wb.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-QTI Snapdragon Display Engine (DPU) writeback display
-
-Required properties:
-- compatible: "qcom,wb-display"
-
-Optional properties:
-- cell-index: Index of writeback device instance.
- Default to 0 if not specified.
-- label: String to describe this writeback display.
- Default to "unknown" if not specified.
-
-Example:
-
-/ {
- ...
-
- dpu_wb: qcom,wb-display {
- compatible = "qcom,wb-display";
- cell-index = <2>;
- label = "wb_display";
- };
-
-};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106735] [amdgpu] all displays reconnect after failed EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=106735 Bug ID: 106735 Summary: [amdgpu] all displays reconnect after failed EDID read Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: m...@matthias-kastner.de Created attachment 139861 --> https://bugs.freedesktop.org/attachment.cgi?id=139861=edit dmesg I am on ubuntu 18.04 LTS on gnome3 with X.org. I am using amdgpu with a Raden RX 580. > $ lspci -k | grep -EA3 'VGA|3D|Display' > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Ellesmere [Radeon RX 470/480] (rev e7) > Subsystem: ASUSTeK Computer Inc. Ellesmere [Radeon RX 470/480/570/580] > Kernel driver in use: amdgpu > Kernel modules: amdgpu > $ uname -r > 4.15.0-22-generic > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 18.04 LTS > Release: 18.04 > Codename: bionic Two screens for working are connected via DVI and HDMI. One HDMI output is connected to a PlayStation VR Headset. The Headset redirects all input to the TV but it is mostly turned off. When turned off but connected to the HDMI output, frequent EDID read fails are reported to syslog: > [drm:log_to_debug_console [amdgpu]] *ERROR* No EDID read. When un-plugging the PSVR Headset from HDMI the errors vanish. After the EDID read there is the HMD related messages like > [3.066968] [drm:log_to_debug_console [amdgpu]] *ERROR* No EDID read. > [3.091884] [drm] SIE HMD *08: [Block 0] > [3.091886] [drm] SIE HMD *08: [Block 1] > [3.091890] [drm] dc_link_detect: manufacturer_id = D94D, product_id = > B403, > serial_number = 1010101, manufacture_week = 38, manufacture_year = > 27, display_name = SIE HMD *08, speaker_flag = 15, audio_mode_count = 4 > [3.091896] [drm] dc_link_detect: mode number = 0, format_code = 1, > channel_count = 6, sample_rate = 87, sample_size = 7 > [3.091899] [drm] dc_link_detect: mode number = 1, format_code = 2, > channel_count = 6, sample_rate = 7, sample_size = 80 > [3.091902] [drm] dc_link_detect: mode number = 2, format_code = 7, > channel_count = 6, sample_rate = 7, sample_size = 188 > [3.091905] [drm] dc_link_detect: mode number = 3, format_code = 10, > channel_count = 8, sample_rate = 4, sample_size = 0 All connected Screens then reconnect: They turn black and the position of the screens (which is left and which is right screen) is sometimes also reset. This is annoying during productive work. My point is that I don't mind if there is no EDID from the PSVR HeadSet or any of the connected devices. The headset is turned off and As I see it, it should only check for the EDID when I turn it on. The only quick solution here is to unplug the Headset while on Linux. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104391] DC R9 285 HDMI audio regression since drm/amd/display: try to find matching audio inst for enc inst first
https://bugs.freedesktop.org/show_bug.cgi?id=104391 --- Comment #8 from Andy Furniss --- I tried agd5f drm-next-4.19-wip, which reports [drm] Display Core initialized with v3.1.47 but still no sound. The warning/bt in dmesg is not there any more. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32
https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #2 from udo --- Created attachment 139863 --> https://bugs.freedesktop.org/attachment.cgi?id=139863=edit dmesg Another hang. Was reading slashdot, -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32
https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #4 from udo --- Created attachment 139864 --> https://bugs.freedesktop.org/attachment.cgi?id=139864=edit xorg log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Thierry Reding
Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to a DMA/IOMMU mapping that transparently uses
the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
backed buffers (a special bit in the GPU's MMU page tables indicates the
memory path to take: via the SMMU or directly to the memory controller).
Transparently backing DMA memory with an IOMMU prevents Nouveau from
properly handling such memory accesses and causes memory access faults.
As a side-note: buffers other than those allocated in instance memory
don't need to be physically contiguous from the GPU's perspective since
the GPU can map them into contiguous buffers using its own MMU. Mapping
these buffers through the IOMMU is unnecessary and will even lead to
performance degradation because of the additional translation. One
exception to this are compressible buffers which need large pages. In
order to enable these large pages, multiple small pages will have to be
combined into one large (I/O virtually contiguous) mapping via the
IOMMU. However, that is a topic outside the scope of this fix and isn't
currently supported. An implementation will want to explicitly create
these large pages in the Nouveau driver, so detaching from a DMA/IOMMU
mapping would still be required.
Signed-off-by: Thierry Reding
---
Changes in v4:
- use existing APIs to detach from a DMA/IOMMU mapping
Changes in v3:
- clarify the use of IOMMU mapping for compressible buffers
- squash multiple patches into this
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index 78597da6313a..0e372a190d3f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -23,6 +23,10 @@
#ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
#include "priv.h"
+#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
+#include
+#endif
+
static int
nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
{
@@ -105,6 +109,15 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra
*tdev)
unsigned long pgsize_bitmap;
int ret;
+#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
+ if (dev->archdata.mapping) {
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+
+ arm_iommu_detach_device(dev);
+ arm_iommu_release_mapping(mapping);
+ }
+#endif
+
if (!tdev->func->iommu_bit)
return;
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 00/11] Remove unused code and cleanup devicetree bindings for DPU driver
This patch series aims at removing unused code from DPU driver and also cleaning up its devicetree bindings. Following functionality is removed in this series: - Removed display port driver, it will be posted back later after verification on SDM845 - Removed HDCP 1.x support, it will be posted back with display port driver - Removed writeback support, it will be added at later stage based on DRM writeback connector series Additionally, following cleanups are done: - Remove bus_scale config from devicetree and use static config in driver - Cleanup devicetree binding to model actual (tree like) HW hierarchy - Cleanup unused utility functions This series is rebased on following: 1. https://lists.freedesktop.org/archives/freedreno/2018-May/002502.html 2. https://lists.freedesktop.org/archives/freedreno/2018-May/002565.html Jordan Crouse (1): drm/msm/dpu: Remove unused code and move the header Rajesh Yadav (10): dt-bindings: msm/disp: remove unused dsi & panel bindings dt-bindings: msm/disp: remove unused display port bindings Revert "drm/msm: Add DisplayPort support" dt-bindings: msm/disp: remove unused writeback bindings drm/msm/dpu: remove writeback support drm/msm/dpu: remove hdcp support drm/msm/dpu: remove dt parsing logic for bus_scale config dt-bindings: msm/disp: cleanup bindings for Snapdragon 845 DPU drm/msm/dpu: correct dpu_io_util.h include path drm/msm/dpu: move dpu_io_util to dpu folder .../devicetree/bindings/display/msm/dpu.txt| 318 ++-- .../devicetree/bindings/drm/msm/dpu-dp.txt | 217 --- .../devicetree/bindings/drm/msm/dpu-dsi.txt| 102 -- .../devicetree/bindings/drm/msm/dpu-wb.txt | 23 - .../devicetree/bindings/drm/msm/mdss-dsi-panel.txt | 772 -- .../devicetree/bindings/fb/mdss-dsi-panel.txt | 742 - Documentation/devicetree/bindings/fb/mdss-pll.txt | 103 -- drivers/gpu/drm/msm/Makefile | 21 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |3 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 94 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|2 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 63 - .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 1349 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 41 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 77 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c |3 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 19 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |6 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 12 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |4 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 321 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 186 --- drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c| 186 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.h| 61 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|5 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|1 - drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 253 ++-- drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h |2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 42 +- drivers/gpu/drm/msm/disp/dpu1/dpu_wb.c | 767 -- drivers/gpu/drm/msm/disp/dpu1/dpu_wb.h | 232 --- drivers/gpu/drm/msm/dp/dp_audio.c | 806 -- drivers/gpu/drm/msm/dp/dp_audio.h | 81 - drivers/gpu/drm/msm/dp/dp_aux.c| 570 --- drivers/gpu/drm/msm/dp/dp_aux.h| 44 - drivers/gpu/drm/msm/dp/dp_catalog.c| 1320 drivers/gpu/drm/msm/dp/dp_catalog.h| 163 -- drivers/gpu/drm/msm/dp/dp_ctrl.c | 1474 -- drivers/gpu/drm/msm/dp/dp_ctrl.h | 50 - drivers/gpu/drm/msm/dp/dp_debug.c | 503 --- drivers/gpu/drm/msm/dp/dp_debug.h | 60 - drivers/gpu/drm/msm/dp/dp_display.c| 1255 drivers/gpu/drm/msm/dp/dp_display.h| 52 - drivers/gpu/drm/msm/dp/dp_drm.c| 538 --- drivers/gpu/drm/msm/dp/dp_drm.h| 96 -- drivers/gpu/drm/msm/dp/dp_hdcp2p2.c| 927 drivers/gpu/drm/msm/dp/dp_link.c | 1548 --- drivers/gpu/drm/msm/dp/dp_link.h | 184 --- drivers/gpu/drm/msm/dp/dp_panel.c | 526 --- drivers/gpu/drm/msm/dp/dp_panel.h | 115 -- drivers/gpu/drm/msm/dp/dp_parser.c | 645 drivers/gpu/drm/msm/dp/dp_parser.h | 200 --- drivers/gpu/drm/msm/dp/dp_power.c | 593 drivers/gpu/drm/msm/dp/dp_power.h
Re: [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()
On 30/05/18 14:12, Thierry Reding wrote:
On Wed, May 30, 2018 at 02:54:46PM +0200, Thierry Reding wrote:
On Wed, May 30, 2018 at 10:59:30AM +0100, Robin Murphy wrote:
On 30/05/18 09:03, Thierry Reding wrote:
From: Thierry Reding
Implement this function to enable drivers from detaching from any IOMMU
domains that architecture code might have attached them to so that they
can take exclusive control of the IOMMU via the IOMMU API.
Signed-off-by: Thierry Reding
---
Changes in v3:
- make API 32-bit ARM specific
- avoid extra local variable
Changes in v2:
- fix compilation
arch/arm/include/asm/dma-mapping.h | 3 +++
arch/arm/mm/dma-mapping-nommu.c| 4
arch/arm/mm/dma-mapping.c | 16
3 files changed, 23 insertions(+)
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index 8436f6ade57d..5960e9f3a9d0 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -103,6 +103,9 @@ extern void arch_setup_dma_ops(struct device *dev, u64
dma_base, u64 size,
#define arch_teardown_dma_ops arch_teardown_dma_ops
extern void arch_teardown_dma_ops(struct device *dev);
+#define arm_dma_iommu_detach_device arm_dma_iommu_detach_device
+extern void arm_dma_iommu_detach_device(struct device *dev);
+
/* do not use this function in a driver */
static inline bool is_device_dma_coherent(struct device *dev)
{
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
index f448a0663b10..eb781369377b 100644
--- a/arch/arm/mm/dma-mapping-nommu.c
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -241,3 +241,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base,
u64 size,
void arch_teardown_dma_ops(struct device *dev)
{
}
+
+void arm_dma_iommu_detach_device(struct device *dev)
+{
+}
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index af27f1c22d93..6d8af08b3e7d 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2400,3 +2400,19 @@ void arch_teardown_dma_ops(struct device *dev)
arm_teardown_iommu_dma_ops(dev);
}
+
+void arm_dma_iommu_detach_device(struct device *dev)
+{
+#ifdef CONFIG_ARM_DMA_USE_IOMMU
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+
+ if (!mapping)
+ return;
+
+ arm_iommu_release_mapping(mapping);
Potentially freeing the mapping before you try to operate on it is never the
best idea. Plus arm_iommu_detach_device() already releases a reference
appropriately anyway, so it's a double-free.
But the reference released by arm_iommu_detach_device() is to balance
out the reference acquired by arm_iommu_attach_device(), isn't it? In
the above, the arm_iommu_release_mapping() is supposed to drop the
final reference which was obtained by arm_iommu_create_mapping(). The
mapping shouldn't go away irrespective of the order in which these
will be called.
Going over the DMA/IOMMU code I just remembered that I drew inspiration
from arm_teardown_iommu_dma_ops() for the initial proposal which also
calls both arm_iommu_detach_device() and arm_iommu_release_mapping().
That said, one other possibility to implement this would be to export
the 32-bit and 64-bit ARM implementations of arch_teardown_dma_ops()
and use that instead. linux/dma-mapping.h implements a stub for
architectures that don't provide one, so it should work without any
#ifdef guards.
That combined with the set_dma_ops() fix in arm_iommu_detach_device()
should fix this pretty nicely.
OK, having a second look at the ARM code I see I had indeed overlooked
that extra reference held until arm_teardown_iommu_dma_ops() - mea culpa
- but frankly that looks wrong anyway, as it basically defeats the point
of refcounting the mapping at all. AFAICS arm_setup_iommu_dma_ops()
should just be made to behave 'normally' by unconditionally dropping the
initial reference after calling __arm_iommu_attach_device(), then we
don't need all these odd and confusing release calls dotted around at all.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] drm/blend: Add per-plane pixel blend mode property
On Wed, May 30, 2018 at 07:23:52PM +0800, Lowry Li wrote: > Hi, > > This serie aims at adding the support for pixel blend modes represent the > alpha blending equation selection in the driver. It also introduces to use > it in the malidp driver. > > Let me know what you think, Hi Lowry, Thank you for doing this work. I know this is something that is missing for proper Android support, so it's most welcome. Do you have userspace patches using this property? Sean > Lowry > > Changes for v2: > - Moves the blending equation into the DOC comment > - Refines the comments of drm_plane_create_blend_mode_property to not >enumerate the #defines, but instead the string values > - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha > - Introduces to use it in the malidp driver, which depends on the plane >alpha patch > > Changes from v1: > - v1 is just the core changes to request for commments > - Adds a pixel_blend_mode to drm_plane_state and a blend_mode_property to >drm_plane, and related support functions > - Defines three blend modes in drm_blend.h > - Rebased on current drm-next > > Lowry Li (2): > drm/blend: Add per-plane pixel blend mode property > drm/mali-dp: Implement plane alpha and pixel blend on malidp > > drivers/gpu/drm/arm/malidp_planes.c | 76 ++--- > drivers/gpu/drm/drm_atomic.c| 4 ++ > drivers/gpu/drm/drm_atomic_helper.c | 1 + > drivers/gpu/drm/drm_blend.c | 110 > > include/drm/drm_blend.h | 6 ++ > include/drm/drm_plane.h | 6 ++ > 6 files changed, 171 insertions(+), 32 deletions(-) > > -- > 1.9.1 > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #3 from Alex Deucher --- Can you narrow down the regression or better yet bisect? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93370] [clover/caicos] OpenCL atomic_cmpxchg() segmentation fault
https://bugs.freedesktop.org/show_bug.cgi?id=93370 Jan Vesely changed: What|Removed |Added Summary|[r600g] OpenCL |[clover/caicos] OpenCL |atomic_cmpxchg()|atomic_cmpxchg() |segmentation fault on |segmentation fault |Caicos | --- Comment #1 from Jan Vesely --- The backtrace does not look compilation related. However, atomic ops that return the old value are not supported atm. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()
From: Thierry Reding
Instead of setting the DMA ops pointer to NULL, set the correct,
non-IOMMU ops depending on the device's coherency setting.
Signed-off-by: Thierry Reding
---
Changes in v4:
- new patch to fix existing arm_iommu_detach_device() to do what we need
arch/arm/mm/dma-mapping.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index af27f1c22d93..87a0037574e4 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1151,6 +1151,11 @@ int arm_dma_supported(struct device *dev, u64 mask)
return __dma_supported(dev, mask, false);
}
+static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
+{
+ return coherent ? _coherent_dma_ops : _dma_ops;
+}
+
#ifdef CONFIG_ARM_DMA_USE_IOMMU
static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs)
@@ -2296,7 +2301,7 @@ void arm_iommu_detach_device(struct device *dev)
iommu_detach_device(mapping->domain, dev);
kref_put(>kref, release_iommu_mapping);
to_dma_iommu_mapping(dev) = NULL;
- set_dma_ops(dev, NULL);
+ set_dma_ops(dev, arm_get_dma_map_ops(dev->archdata.dma_coherent));
pr_debug("Detached IOMMU controller from %s device.\n", dev_name(dev));
}
@@ -2357,11 +2362,6 @@ static void arm_teardown_iommu_dma_ops(struct device
*dev) { }
#endif /* CONFIG_ARM_DMA_USE_IOMMU */
-static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent)
-{
- return coherent ? _coherent_dma_ops : _dma_ops;
-}
-
void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
const struct iommu_ops *iommu, bool coherent)
{
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 02/11] dt-bindings: msm/disp: remove unused display port bindings
DPU display port driver is not enabled yet so removing the bindings. The driver code is also reverted. The bindings will be added back when display port driver is reworked and enabled for sdm845. Signed-off-by: Rajesh Yadav --- .../devicetree/bindings/drm/msm/dpu-dp.txt | 217 - 1 file changed, 217 deletions(-) delete mode 100644 Documentation/devicetree/bindings/drm/msm/dpu-dp.txt diff --git a/Documentation/devicetree/bindings/drm/msm/dpu-dp.txt b/Documentation/devicetree/bindings/drm/msm/dpu-dp.txt deleted file mode 100644 index 1ed2715..000 --- a/Documentation/devicetree/bindings/drm/msm/dpu-dp.txt +++ /dev/null @@ -1,217 +0,0 @@ -Qualcomm Technologies, Inc. -dpu-dp is the master Display Port device which supports DP host controllers that are compatible with VESA Display Port interface specification. -DP Controller: Required properties: -- compatible: Should be "qcom,dp-display". -- reg: Base address and length of DP hardware's memory mapped regions. -- reg-names:A list of strings that name the list of regs. "dp_ctrl" - DP controller memory region. - "dp_phy" - DP PHY memory region. - "dp_ln_tx0" - USB3 DP PHY combo TX-0 lane memory region. - "dp_ln_tx1" - USB3 DP PHY combo TX-1 lane memory region. - "dp_mmss_cc" - Display Clock Control memory region. - "qfprom_physical" - QFPROM Phys memory region. - "dp_pll" - USB3 DP combo PLL memory region. - "usb3_dp_com" - USB3 DP PHY combo memory region. - "hdcp_physical" - DP HDCP memory region. -- cell-index: Specifies the controller instance. -- clocks: Clocks required for Display Port operation. -- clock-names: Names of the clocks corresponding to handles. Following clocks are required: - "core_aux_clk", "core_usb_ref_clk_src","core_usb_ref_clk", "core_usb_cfg_ahb_clk", - "core_usb_pipe_clk", "ctrl_link_clk", "ctrl_link_iface_clk", "ctrl_crypto_clk", - "ctrl_pixel_clk", "pixel_clk_rcg", "pixel_parent". -- gdsc-supply: phandle to gdsc regulator node. -- vdda-1p2-supply: phandle to vdda 1.2V regulator node. -- vdda-0p9-supply: phandle to vdda 0.9V regulator node. -- interrupt-parent phandle to the interrupt parent device node. -- interrupts: The interrupt signal from the DSI block. -- qcom,aux-en-gpio:Specifies the aux-channel enable gpio. -- qcom,aux-sel-gpio: Specifies the aux-channel select gpio. -- qcom,usbplug-cc-gpio:Specifies the usbplug orientation gpio. -- qcom,aux-cfg0-settings: Specifies the DP AUX configuration 0 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg1-settings: Specifies the DP AUX configuration 1 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg2-settings: Specifies the DP AUX configuration 2 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg3-settings: Specifies the DP AUX configuration 3 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg4-settings: Specifies the DP AUX configuration 4 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg5-settings: Specifies the DP AUX configuration 5 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg6-settings: Specifies the DP AUX configuration 6 settings.
[Bug 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32
https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #3 from udo --- messages file has similar messages. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm/panel: Add support for Truly NT35597 panel
On Fri, May 25, 2018 at 05:27:51PM -0700, Abhinav Kumar wrote:
> Add support for Truly NT35597 panel used
> in MSM reference platforms.
>
> This panel supports both single DSI and dual DSI
> modes.
>
> However, this patch series adds support only for
> dual DSI mode.
>
> Changes in v4:
> - Fix the license identifier
> - Fix formatting issues for the regulator loads
> - Fix error messages and return code
>
> Signed-off-by: Archit Taneja
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/panel/Kconfig | 8 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 576
>
> 3 files changed, 585 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 25682ff..2fcd9b1 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -177,4 +177,12 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_TRULY_NT35597_WQXGA
> + tristate "Truly WQXGA"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
> + help
> + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
> DSI
> + Video Mode panel
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index f26efc1..056ea93 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> new file mode 100644
> index 000..a57cbf0
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> @@ -0,0 +1,576 @@
> +// SPDX-License-Identifier: GPL-2.0
I guess it is up to Sean and Rob if they want to accept // comments for SPDX.
I'm not sure there is a hard and fast rule about it.
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const char * const regulator_names[] = {
> + "vdda",
> + "vdispp",
> + "vdispn"
The reason why the coding style insists on commas for the last member of an
listy is that if you added another item the resulting patch would
only need one line instead of three. For example:
+ "foo",
instead of:
- "vdispn"
+ "vdispn",
+ "foo",
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
On Wed, May 30, 2018 at 02:30:51PM +0100, Robin Murphy wrote: > On 30/05/18 14:00, Thierry Reding wrote: > > On Wed, May 30, 2018 at 11:30:25AM +0100, Robin Murphy wrote: > > > On 30/05/18 09:03, Thierry Reding wrote: > > > > From: Thierry Reding > > > > > > > > Depending on the kernel configuration, early ARM architecture setup code > > > > may have attached the GPU to a DMA/IOMMU mapping that transparently uses > > > > the IOMMU to back the DMA API. Tegra requires special handling for IOMMU > > > > backed buffers (a special bit in the GPU's MMU page tables indicates the > > > > memory path to take: via the SMMU or directly to the memory controller). > > > > Transparently backing DMA memory with an IOMMU prevents Nouveau from > > > > properly handling such memory accesses and causes memory access faults. > > > > > > > > As a side-note: buffers other than those allocated in instance memory > > > > don't need to be physically contiguous from the GPU's perspective since > > > > the GPU can map them into contiguous buffers using its own MMU. Mapping > > > > these buffers through the IOMMU is unnecessary and will even lead to > > > > performance degradation because of the additional translation. One > > > > exception to this are compressible buffers which need large pages. In > > > > order to enable these large pages, multiple small pages will have to be > > > > combined into one large (I/O virtually contiguous) mapping via the > > > > IOMMU. However, that is a topic outside the scope of this fix and isn't > > > > currently supported. An implementation will want to explicitly create > > > > these large pages in the Nouveau driver, so detaching from a DMA/IOMMU > > > > mapping would still be required. > > > > > > I wonder if it might make sense to have a hook in iommu_attach_device() to > > > notify the arch DMA API code when moving devices between unmanaged and DMA > > > ops domains? That seems like it might be the most low-impact way to > > > address > > > the overall problem long-term. > > > > > > > Signed-off-by: Thierry Reding > > > > --- > > > > Changes in v3: > > > > - clarify the use of IOMMU mapping for compressible buffers > > > > - squash multiple patches into this > > > > > > > >drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 5 + > > > >1 file changed, 5 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > > > b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > > > index 78597da6313a..d0538af1b967 100644 > > > > --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > > > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > > > @@ -105,6 +105,11 @@ nvkm_device_tegra_probe_iommu(struct > > > > nvkm_device_tegra *tdev) > > > > unsigned long pgsize_bitmap; > > > > int ret; > > > > +#if IS_ENABLED(CONFIG_ARM) > > > > > > Wouldn't CONFIG_ARM_DMA_USE_IOMMU be even more appropriate? > > > > Not necessarily. arm_dma_iommu_detach_device() is always defined on ARM, > > only with CONFIG_ARM_DMA_USE_IOMMU=n it will be empty. So this check is > > a guard to make sure we don't call the function when it isn't available, > > but it may still not do anything. > > Calling a function under condition A, which only does anything under > condition B, when B depends on A, is identical in behaviour to only calling > the function under condition B, except needlessly harder to follow. > > > > > + /* make sure we can use the IOMMU exclusively */ > > > > + arm_dma_iommu_detach_device(dev); > > > > > > As before, I would just use the existing infrastructure the same way the > > > Exynos DRM driver currently does in __exynos_iommu_attach() (albeit > > > without > > > then reattaching to another DMA ops mapping). > > > > That's pretty much what I initially did and which was shot down by > > Christoph. As I said earlier, at this point I don't really care what > > color the shed will be. Can you and Christoph come to an agreement > > on what it should be? > > What I was getting at is that arm_iommu_detach_device() already *is* the > exact function Christoph was asking for, it just needs a minor fix instead > of adding explicit set_dma_ops() fiddling at its callsites which only > obfuscates the fact that it's supposed to be responsible for resetting the > device's DMA ops already. It still has the downside of callers having to explicitly check for the existence of a mapping, otherwise they'll cause a warning to be printed to the kernel log. That's not all that bad, though. I'll prepare version 4 with those changes. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 Jan Vesely changed: What|Removed |Added Blocks||82717 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=82717 [Bug 82717] OpenCL support for mandelbulber-opencl -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 01/11] dt-bindings: msm/disp: remove unused dsi & panel bindings
DPU driver switched to existing upstream dsi driver so removing the dsi-staging specific dsi and panel bindings. Signed-off-by: Rajesh Yadav --- .../devicetree/bindings/drm/msm/dpu-dsi.txt| 102 --- .../devicetree/bindings/drm/msm/mdss-dsi-panel.txt | 772 - .../devicetree/bindings/fb/mdss-dsi-panel.txt | 742 Documentation/devicetree/bindings/fb/mdss-pll.txt | 103 --- 4 files changed, 1719 deletions(-) delete mode 100644 Documentation/devicetree/bindings/drm/msm/dpu-dsi.txt delete mode 100644 Documentation/devicetree/bindings/drm/msm/mdss-dsi-panel.txt delete mode 100644 Documentation/devicetree/bindings/fb/mdss-dsi-panel.txt delete mode 100644 Documentation/devicetree/bindings/fb/mdss-pll.txt diff --git a/Documentation/devicetree/bindings/drm/msm/dpu-dsi.txt b/Documentation/devicetree/bindings/drm/msm/dpu-dsi.txt deleted file mode 100644 index 641cc26..000 --- a/Documentation/devicetree/bindings/drm/msm/dpu-dsi.txt +++ /dev/null @@ -1,102 +0,0 @@ -Qualcomm Technologies, Inc. - -mdss-dsi is the master DSI device which supports multiple DSI host controllers -that are compatible with MIPI display serial interface specification. - -DSI Controller: -Required properties: -- compatible: Should be "qcom,dsi-ctrl-hw-v". Supported - versions include 1.4, 2.0 and 2.2. - eg: qcom,dsi-ctrl-hw-v1.4, qcom,dsi-ctrl-hw-v2.0, - qcom,dsi-ctrl-hw-v2.2 - And for dsi phy driver: - qcom,dsi-phy-v0.0-hpm, qcom,dsi-phy-v0.0-lpm, - qcom,dsi-phy-v1.0, qcom,dsi-phy-v2.0, - qcom,dsi-phy-v3.0 -- reg: Base address and length of DSI controller's memory - mapped regions. -- reg-names:A list of strings that name the list of regs. - "dsi_ctrl" - DSI controller memory region. - "mmss_misc" - MMSS misc memory region. -- cell-index: Specifies the controller instance. -- clocks: Clocks required for DSI controller operation. -- clock-names: Names of the clocks corresponding to handles. Following - clocks are required: - "mdp_core_clk" - "iface_clk" - "core_mmss_clk" - "bus_clk" - "byte_clk" - "pixel_clk" - "core_clk" - "byte_clk_rcg" - "pixel_clk_rcg" -- gdsc-supply: phandle to gdsc regulator node. -- vdda-supply: phandle to vdda regulator node. -- vcca-supply: phandle to vcca regulator node. -- interrupt-parent phandle to the interrupt parent device node. -- interrupts: The interrupt signal from the DSI block. - -Bus Scaling Data: -- qcom,msm-bus,name: String property describing MDSS client. -- qcom,msm-bus,num-cases: This is the number of bus scaling use cases - defined in the vectors property. This must be - set to <2> for MDSS DSI driver where use-case 0 - is used to remove BW votes from the system. Use - case 1 is used to generate bandwidth requestes - when sending command packets. -- qcom,msm-bus,num-paths: This represents number of paths in each bus - scaling usecase. This value depends on number of - AXI master ports dedicated to MDSS for - particular chipset. -- qcom,msm-bus,vectors-KBps: A series of 4 cell properties, with a format - of (src, dst, ab, ib) which is defined at - Documentation/devicetree/bindings/arm/msm/msm_bus.txt. - DSI driver should always set average bandwidth - (ab) to 0 and always use instantaneous - bandwidth(ib) values. - -Optional properties: -- label: String to describe controller. -- qcom,platform-te-gpio: Specifies the gpio used for TE. -- qcom,dsi-display-active: Current active display -- qcom,dsi-ctrl: handle to dsi controller device -- qcom,dsi-phy: handle to dsi phy device -- qcom,dsi-manager: Specifies dsi manager is present -- qcom,dsi-display: Specifies dsi display is present -- qcom,hdmi-display: Specifies hdmi is present -- qcom,dp-display:Specified dp is present -- qcom,-supply-entries: A node that lists the elements of the supply used by the - a particular "type" of DSI module. The module "types" - can be "core", "ctrl", and "phy". Within the same type, -
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 05/30/2018 06:54 PM, Boris Ostrovsky wrote:
On 05/30/2018 04:29 AM, Oleksandr Andrushchenko wrote:
On 05/29/2018 11:03 PM, Boris Ostrovsky wrote:
On 05/29/2018 02:22 PM, Oleksandr Andrushchenko wrote:
On 05/29/2018 09:04 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
@@ -463,11 +457,6 @@ static enum bp_state
increase_reservation(unsigned long nr_pages)
int rc;
unsigned long i;
struct page *page;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid = DOMID_SELF
- };
if (nr_pages > ARRAY_SIZE(frame_list))
nr_pages = ARRAY_SIZE(frame_list);
@@ -486,9 +475,7 @@ static enum bp_state
increase_reservation(unsigned long nr_pages)
page = balloon_next_page(page);
}
- set_xen_guest_handle(reservation.extent_start, frame_list);
- reservation.nr_extents = nr_pages;
- rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, );
+ rc = xenmem_reservation_increase(nr_pages, frame_list);
if (rc <= 0)
return BP_EAGAIN;
@@ -496,29 +483,7 @@ static enum bp_state
increase_reservation(unsigned long nr_pages)
page = balloon_retrieve(false);
BUG_ON(page == NULL);
-#ifdef CONFIG_XEN_HAVE_PVMMU
- /*
- * We don't support PV MMU when Linux and Xen is using
- * different page granularity.
- */
- BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
-
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- unsigned long pfn = page_to_pfn(page);
-
- set_phys_to_machine(pfn, frame_list[i]);
-
- /* Link back into the page tables if not highmem. */
- if (!PageHighMem(page)) {
- int ret;
- ret = HYPERVISOR_update_va_mapping(
- (unsigned long)__va(pfn << PAGE_SHIFT),
- mfn_pte(frame_list[i], PAGE_KERNEL),
- 0);
- BUG_ON(ret);
- }
- }
-#endif
+ xenmem_reservation_va_mapping_update(1, ,
_list[i]);
Can you make a single call to xenmem_reservation_va_mapping_update(rc,
...)? You need to keep track of pages but presumable they can be put
into an array (or a list). In fact, perhaps we can have
balloon_retrieve() return a set of pages.
This is actually how it is used later on for dma-buf, but I just
didn't want
to alter original balloon code too much, but this can be done, in
order of simplicity:
1. Similar to frame_list, e.g. static array of struct page* of size
ARRAY_SIZE(frame_list):
more static memory is used, but no allocations
2. Allocated at run-time with kcalloc: allocation can fail
If this is called in freeing DMA buffer code path or in error path then
we shouldn't do it.
3. Make balloon_retrieve() return a set of pages: will require
list/array allocation
and handling, allocation may fail, balloon_retrieve prototype change
balloon pages are strung on the lru list. Can we keep have
balloon_retrieve return a list of pages on that list?
First of all, before we go deep in details, I will highlight
the goal of the requested change: for balloon driver we call
xenmem_reservation_va_mapping_update(*1*, , _list[i]);
from increase_reservation
and
xenmem_reservation_va_mapping_reset(*1*, );
from decrease_reservation and it seems to be not elegant because of
that one page/frame passed while we might have multiple pages/frames
passed at once.
In the balloon driver the producer of pages for increase_reservation
is balloon_retrieve(false) and for decrease_reservation it is
alloc_page(gfp).
In case of decrease_reservation the page is added on the list:
LIST_HEAD(pages);
[...]
list_add(>lru, );
and in case of increase_reservation it is retrieved page by page
and can be put on a list as well with the same code from
decrease_reservation, e.g.
LIST_HEAD(pages);
[...]
list_add(>lru, );
Thus, both decrease_reservation and increase_reservation may hold
their pages on a list before calling
xenmem_reservation_va_mapping_{update|reset}.
For that we need a prototype change:
xenmem_reservation_va_mapping_reset(, );
But for xenmem_reservation_va_mapping_update it will look like:
xenmem_reservation_va_mapping_update(, ,
)
which seems to be inconsistent. Converting entries of the static
frame_list array
into corresponding list doesn't seem to be cute as well.
For dma-buf use-case arrays are more preferable as dma-buf constructs
scatter-gather
tables from array of pages etc. and if page list is passed then it
needs to be
converted into page array anyways.
So, we can:
1. Keep the prototypes as is, e.g. accept array of pages and use
nr_pages == 1 in
case of balloon driver (existing code)
2. Statically allocate struct page* array in the balloon driver and
fill it with pages
when those pages are retrieved:
static struct page *page_list[ARRAY_SIZE(frame_list)];
which will take additional
Re: [PATCH v7 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
On Tue, May 29, 2018 at 08:41:42AM +0200, Andrzej Hajda wrote: > On 24.05.2018 18:41, Sandeep Panda wrote: > > Document the bindings used for the sn65dsi86 DSI to eDP bridge. > > > > Changes in v1: > > - Rephrase the dt-binding descriptions to be more inline with existing > >bindings (Andrzej Hajda). > > - Add missing dt-binding that are parsed by corresponding driver > >(Andrzej Hajda). > > > > Changes in v2: > > - Remove edp panel specific dt-binding entries. Only keep bridge > >specific entries (Sean Paul). > > - Remove custom-modes dt entry since its usage is removed from driver also > > (Sean Paul). > > - Remove is-pluggable dt entry since this will not be needed anymore (Sean > > Paul). > > > > Changes in v3: > > - Remove irq-gpio dt entry and instead populate is an interrupt > >property (Rob Herring). > > > > Changes in v4: > > - Add link to bridge chip datasheet (Stephen Boyd) > > - Add vpll and vcc regulator supply bindings (Stephen Boyd) > > - Add ref clk optional dt binding (Stephen Boyd) > > - Add gpio-controller optional dt binding (Stephen Boyd) > > > > Changes in v5: > > - Use clock property to specify the input refclk (Stephen Boyd). > > - Update gpio cell and pwm cell numbers (Stephen Boyd). > > > > Changes in v6: > > - Add property to mention the lane mapping scheme and polarity inversion > >(Stephen Boyd). > > > > Signed-off-by: Sandeep Panda > > --- > > .../bindings/display/bridge/ti,sn65dsi86.txt | 89 > > ++ > > 1 file changed, 89 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > > new file mode 100644 > > index 000..4a771a3 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > > @@ -0,0 +1,89 @@ > > +SN65DSI86 DSI to eDP bridge chip > > + > > + > > +This is the binding for Texas Instruments SN65DSI86 bridge. > > +http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf > > + > > +Required properties: > > +- compatible: Must be "ti,sn65dsi86" > > +- reg: i2c address of the chip, 0x2d as per datasheet > > +- enable-gpios: OF device-tree gpio specification for bridge_en pin > > info about active high should be added > > > + > > +- vccio-supply: A 1.8V supply that powers up the digital IOs. > > +- vpll-supply: A 1.8V supply that powers up the displayport PLL. > > +- vcca-supply: A 1.2V supply that powers up the analog circuits. > > +- vcc-supply: A 1.2V supply that powers up the digital core. > > + > > +Optional properties: > > +- interrupts: Specifier for the SN65DSI86 interrupt line. > > +- hpd-gpios: Specifications for HPD gpio pin. > > Again, please specify active level. Having this property in the bridge node is strange. Also, does eDP normally have a HPD signal? If you are using this for DP, then this property goes in the connector node (or is absent if the bridge chip has a dedicated signal). > > + > > +- gpio-controller: Marks the device has a GPIO controller. > > +- #gpio-cells: Should be two. The first cell is the pin number and > > + the second cell is used to specify flags. > > + See ../../gpio/gpio.txt for more information. > > +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of > > + the cell formats. > > + > > +- clock-names: should be "refclk" > > +- clocks: Specification for input reference clock. The reference > > + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. > > + > > +- lane-config: Specification to describe the logical to physical lane > > + mapping scheme and polarity inversion of lanes. > > Please describe this property, I guess it is about DSI lanes, and it > should be exact(?) four pair of numbers, what are meaning and ranges of > both numbers. What should be assumed if property is not present. Btw you > can look into other bindings for reference, I guess there are already > bindings having such property. In fact, IIRC, some QCom bindings already have a property. Maybe it's the same. If so, don't describe it twice. Document in common location and just reference the common definition and add any constraints (like active level for a GPIO). Is this DSI or eDP lanes? Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fb_omap: add gpiolib dependency
Building the omap sub-drivers when CONFIG_GPIOLIB is disabled causes lots of build failures, either from using gpiolib interfaces, or from including the wrong headers: drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c: In function 'opa362_enable': drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:101:3: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c: In function 'panel_dpi_enable': drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c:86:2: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c: In function 'panel_dpi_probe_pdata': drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c:189:23: error: implicit declaration of function 'gpio_to_desc'; did you mean 'irq_to_desc'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c: In function 'panel_dpi_probe_of': drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c:210:9: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_gpio_request_one'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c: In function 'sharp_ls_enable': drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c:120:3: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c: In function 'lb035q02_enable': drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:170:3: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c: In function 'hdmi_probe_of': drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c:584:2: error: implicit declaration of function 'of_node_put'; did you mean 'node_set'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c: In function 'hdmi_probe_of': drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:554:2: error: implicit declaration of function 'of_node_put'; did you mean 'node_set'? [-Werror=implicit-function-declaration] Rather than fixing up each one individually, this just marks all of it as depending on GPIOLIB. Signed-off-by: Arnd Bergmann --- drivers/video/fbdev/omap2/omapfb/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig b/drivers/video/fbdev/omap2/omapfb/Kconfig index e6226aeed17e..3bf154e676d1 100644 --- a/drivers/video/fbdev/omap2/omapfb/Kconfig +++ b/drivers/video/fbdev/omap2/omapfb/Kconfig @@ -5,6 +5,7 @@ menuconfig FB_OMAP2 tristate "OMAP2+ frame buffer support" depends on FB depends on DRM_OMAP = n + depends on GPIOLIB select FB_OMAP2_DSS select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3 -- 2.9.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 81620] radeon: fence wait failed (-35) after hybrid suspend on 3.15
https://bugs.freedesktop.org/show_bug.cgi?id=81620 i...@yahoo.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEEDINFO|RESOLVED --- Comment #2 from i...@yahoo.com --- Yes, the bug has been fixed long ago. I'm using vdpau all the time, so I'm sure it is working. At least on 64 bit kernels. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense
On Wed, May 30, 2018 at 11:43:58AM +0200, Neil Armstrong wrote:
> The dw_hdmi_setup_rx_sense exported function should not use struct device
> to recover the dw-hdmi context using drvdata, but take struct dw_hdmi
> directly like other exported functions.
>
> This caused a regression using Meson DRM on S905X since v4.17-rc1 :
>
> Internal error: Oops: 9607 [#1] PREEMPT SMP
> [...]
> CPU: 0 PID: 124 Comm: irq/32-dw_hdmi_ Not tainted 4.17.0-rc7 #2
> Hardware name: Libre Technology CC (DT)
> [...]
> pc : osq_lock+0x54/0x188
> lr : __mutex_lock.isra.0+0x74/0x530
> [...]
> Process irq/32-dw_hdmi_ (pid: 124, stack limit = 0xadf418cb)
> Call trace:
> osq_lock+0x54/0x188
> __mutex_lock_slowpath+0x10/0x18
> mutex_lock+0x30/0x38
> __dw_hdmi_setup_rx_sense+0x28/0x98
> dw_hdmi_setup_rx_sense+0x10/0x18
> dw_hdmi_top_thread_irq+0x2c/0x50
> irq_thread_fn+0x28/0x68
> irq_thread+0x10c/0x1a0
> kthread+0x128/0x130
> ret_from_fork+0x10/0x18
> Code: 34000964 d00050a2 51000484 9135c042 (f864d844)
> ---[ end trace 945641e1fbbc07da ]---
> note: irq/32-dw_hdmi_[124] exited with preempt_count 1
> genirq: exiting task "irq/32-dw_hdmi_" (124) is an active IRQ thread (irq 32)
>
> Fixes: eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
> Signed-off-by: Neil Armstrong
> Tested-by: Koen Kooi
Thanks for your patch, Neil. I've applied it to -misc-fixes and will send it to
Dave in hope it can sneak into 4.17.
Sean
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 15 ---
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
> include/drm/bridge/dw_hdmi.h | 2 +-
> 3 files changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index ec8d000..3c136f2b 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2077,7 +2077,7 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void
> *dev_id)
> return ret;
> }
>
> -void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
> +void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
> {
> mutex_lock(>mutex);
>
> @@ -2103,13 +2103,6 @@ void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi,
> bool hpd, bool rx_sense)
> }
> mutex_unlock(>mutex);
> }
> -
> -void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
> -{
> - struct dw_hdmi *hdmi = dev_get_drvdata(dev);
> -
> - __dw_hdmi_setup_rx_sense(hdmi, hpd, rx_sense);
> -}
> EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
>
> static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> @@ -2145,9 +2138,9 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>*/
> if (intr_stat &
> (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
> - __dw_hdmi_setup_rx_sense(hdmi,
> - phy_stat & HDMI_PHY_HPD,
> - phy_stat & HDMI_PHY_RX_SENSE);
> + dw_hdmi_setup_rx_sense(hdmi,
> +phy_stat & HDMI_PHY_HPD,
> +phy_stat & HDMI_PHY_RX_SENSE);
>
> if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
> cec_notifier_set_phys_addr(hdmi->cec_notifier,
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index a393095..c9ad456 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -529,7 +529,7 @@ static irqreturn_t dw_hdmi_top_thread_irq(int irq, void
> *dev_id)
> if (stat & HDMITX_TOP_INTR_HPD_RISE)
> hpd_connected = true;
>
> - dw_hdmi_setup_rx_sense(dw_hdmi->dev, hpd_connected,
> + dw_hdmi_setup_rx_sense(dw_hdmi->hdmi, hpd_connected,
> hpd_connected);
>
> drm_helper_hpd_irq_event(dw_hdmi->encoder.dev);
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index dd2a8cf..ccb5aa8 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -151,7 +151,7 @@ struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
>struct drm_encoder *encoder,
>const struct dw_hdmi_plat_data *plat_data);
>
> -void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense);
> +void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense);
>
> void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
> void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Sean Paul, Software Engineer,
Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
Qiang Yu writes: > On Thu, May 24, 2018 at 3:51 PM, Daniel Vetter wrote: >> On Thu, May 24, 2018 at 09:18:04AM +0800, Qiang Yu wrote: >>> On Thu, May 24, 2018 at 4:31 AM, Daniel Vetter wrote: >>> > On Wed, May 23, 2018 at 2:59 PM, Qiang Yu wrote: >>> >> On Wed, May 23, 2018 at 5:04 PM, Daniel Vetter wrote: >>> >>> On Tue, May 22, 2018 at 09:04:17AM +0800, Qiang Yu wrote: >>> On Tue, May 22, 2018 at 3:37 AM, Eric Anholt wrote: >>> > Qiang Yu writes: >>> > >>> >> This reverts commit 45c3d213a400c952ab7119f394c5293bb6877e6b. >>> >> >>> >> lima driver need preclose to wait all task in the context >>> >> created within closing file to finish before free all the >>> >> buffer object. Otherwise pending tesk may fail and get >>> >> noisy MMU fault message. >>> >> >>> >> Move this wait to each buffer object free function can >>> >> achieve the same result but some buffer object is shared >>> >> with other file context, but we only want to wait the >>> >> closing file context's tasks. So the implementation is >>> >> not that straight forword compared to the preclose one. >>> > >>> > You should just separate your MMU structures from drm_file, and have >>> > drm_file and the jobs using it keep a reference on them. This is >>> > what >>> > I've done in V3D as well. >>> >>> It's not the VM/MMU struct that causes this problem, it's each buffer >>> object that gets freed before task is done (postclose is after buffer >>> free). >>> If you mean I should keep reference of all buffers for tasks, that's >>> not >>> as simple as just waiting task done before free buffers. >>> >>> >>> >>> Why can't you do that waiting in the postclose hook? If it's the lack of >>> >>> reference-counting in your driver for gem bo, then I'd say you need to >>> >>> roll out some reference counting. Relying on the implicit reference >>> >>> provided by the core is kinda not so great (which was the reason I've >>> >>> thrown out the preclose hook). There's also per-bo open/close hooks. >>> >> >>> >> It's possible to not use preclose, but the implementation is not as >>> >> simple >>> >> and straight forward as the preclose I think. There're two method I can >>> >> think of: >>> >> 1. do wait when free buffers callback unmap buffer from this process's >>> >> lima VM (wait buffer reservation object), this is fine and simple, >>> >> but >>> >> there's case that this buffer is shared between two processes, so the >>> >> best way should be only waiting fences from this process, so we'd >>> >> better do some record for fences for a "perfect waiting" >>> >> 2. keep a reference of involved buffers for a task, unreference it when >>> >> task done, also keep a reference of the buffer mapping in this >>> >> process's >>> >> lima VM (this is more complicated to implement) >>> >> >>> >> But if there's a preclose, just wait all this process's task done, then >>> >> unmap/free buffers, it's simple and straight forward. I'd like to hear if >>> >> there's other better way for only use postclose. >>> > >>> > Refcount your buffers. Borrowing references from other places tends to >>> > result in a maintenance headache with no end. So solution 2. >>> >>> In current lima implementation, refcount involved buffer for task is done >>> in user space. So kernel's task object don't keep that. User space >>> driver is responsible not unmap/free buffer before task is complete. This >>> works simple and fine except the case that user press Ctrl+C to terminate >>> the application which will force to close drm fd. I really don't think >>> adding >>> buffer refcount for tasks in kernel just for this case is valuable because >>> it has no benefits for normal case but some extra load. >> >> If kernel correctness relies on refcounting you have a giantic security >> problem. You need to fix that. Kernel _must_ assume that userspace is >> evil, trying to pull it over the table. > > It is OK if evil user free/unmap the buffer when task is not done > in my implementation. It will generate a MMU fault in that case and kernel > driver will do recovery. > > So does the Ctrl+C case, if don't deal with it, just get some noisy MMU > fault warning and a HW reset recovery. How about an app rendering to shared buffers, which glFlush()es and exits cleanly but doesn't close the DRI screen? What would cause that app's rendering to get completed succesfully instead of faulting to death? You really do need to refcount the buffers used in a rendering job so they don't get freed early. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/13] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()
On Fri, May 25, 2018 at 09:50:34PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of plane->fb (which we're going to deprecate for atomic drivers)
> we need to look at plane->state->fb. The maze of code leading to
> vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
> concluded that the calls originating from vmw_*_primary_plane_atomic_update()
> all pass in the crtc which means we'll never end up in this branch
> of the function. All other callers use drm_modeset_lock_all() somewhere
> higher up, which means accessing plane->state is safe. We'll toss in
> a lockdep assert to catch wrongdoers.
>
> v2: Drop the comment and make the code do what it did before (Thomas)
>
> Cc: Deepak Rawat
> Cc: Thomas Hellstrom
> Cc: Sinclair Yeh
> Cc: VMware Graphics
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 2e4c38bb846d..5417eb1b486e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -2326,9 +2326,12 @@ int vmw_kms_helper_dirty(struct vmw_private *dev_priv,
> } else {
> list_for_each_entry(crtc, _priv->dev->mode_config.crtc_list,
> head) {
> - if (crtc->primary->fb != >base)
> - continue;
> - units[num_units++] = vmw_crtc_to_du(crtc);
> + struct drm_plane *plane = crtc->primary;
> +
> + lockdep_assert_held(>mutex);
kbuild test robot told me
>> include/linux/lockdep.h:347:52: error: 'struct drm_modeset_lock' has
>> no member named 'dep_map'
#define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map)
Maybe I'll just drop the asserts? Or do people really want them
(in which case I gues I need to dig out the underlying mutex)?
> +
> + if (plane->state->fb == >base)
> + units[num_units++] = vmw_crtc_to_du(crtc);
> }
> }
>
> --
> 2.16.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/atomic: Set current atomic state in drm_private_state
drm_private_state has a back pointer to the drm_atomic_state, however that was not initialized in drm_atomic_get_private_obj_state after duplication, as it is the case for other drm atomic getters Signed-off-by: Alexandru Gheorghe --- drivers/gpu/drm/drm_atomic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 7d25c42..249aaf8 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1108,6 +1108,7 @@ drm_atomic_get_private_obj_state(struct drm_atomic_state *state, state->private_objs[index].old_state = obj->state; state->private_objs[index].new_state = obj_state; state->private_objs[index].ptr = obj; + obj_state->state = state; state->num_private_objs = num_objs; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] drm/v3d: add CONFIG_MMU dependency
Arnd Bergmann writes:
> Without CONFIG_MMU, we get a link error:
>
> drivers/gpu/drm/v3d/v3d_bo.o: In function `v3d_gem_fault':
> v3d_bo.c:(.text+0x3ca): undefined reference to `vm_insert_mixed'
>
> The other drivers with this problem already depend on CONFIG_MMU,
> so let's do the same thing here.
>
> Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D
> V3.x+")
> Signed-off-by: Arnd Bergmann
Applied to drm-misc-next-fixes. Thanks!
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] xen/grant-table: Make set/clear page private code shared
On Fri, May 25, 2018 at 06:33:24PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Make set/clear page private code shared and accessible to
> other kernel modules which can re-use these instead of open-coding.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/grant-table.c | 54 +--
> include/xen/grant_table.h | 3 +++
> 2 files changed, 38 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 27be107d6480..d7488226e1f2 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void)
> }
> EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
>
> -/**
> - * gnttab_alloc_pages - alloc pages suitable for grant mapping into
> - * @nr_pages: number of pages to alloc
> - * @pages: returns the pages
> - */
> -int gnttab_alloc_pages(int nr_pages, struct page **pages)
> +int gnttab_pages_set_private(int nr_pages, struct page **pages)
> {
> int i;
> - int ret;
> -
> - ret = alloc_xenballooned_pages(nr_pages, pages);
> - if (ret < 0)
> - return ret;
>
> for (i = 0; i < nr_pages; i++) {
> #if BITS_PER_LONG < 64
> struct xen_page_foreign *foreign;
>
> foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
> - if (!foreign) {
> - gnttab_free_pages(nr_pages, pages);
> + if (!foreign)
Don't we have to free previously allocated "foreign"(s) if it fails in the
middle
(e.g. 0 < i && i < nr_pages - 1) before returning?
> return -ENOMEM;
> - }
> +
> set_page_private(pages[i], (unsigned long)foreign);
> #endif
> SetPagePrivate(pages[i]);
> @@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page
> **pages)
>
> return 0;
> }
> -EXPORT_SYMBOL(gnttab_alloc_pages);
> +EXPORT_SYMBOL(gnttab_pages_set_private);
>
> /**
> - * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
> - * @nr_pages; number of pages to free
> - * @pages: the pages
> + * gnttab_alloc_pages - alloc pages suitable for grant mapping into
> + * @nr_pages: number of pages to alloc
> + * @pages: returns the pages
> */
> -void gnttab_free_pages(int nr_pages, struct page **pages)
> +int gnttab_alloc_pages(int nr_pages, struct page **pages)
> +{
> + int ret;
> +
> + ret = alloc_xenballooned_pages(nr_pages, pages);
> + if (ret < 0)
> + return ret;
> +
> + ret = gnttab_pages_set_private(nr_pages, pages);
> + if (ret < 0)
> + gnttab_free_pages(nr_pages, pages);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(gnttab_alloc_pages);
> +
> +void gnttab_pages_clear_private(int nr_pages, struct page **pages)
> {
> int i;
>
> @@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
> ClearPagePrivate(pages[i]);
> }
> }
> +}
> +EXPORT_SYMBOL(gnttab_pages_clear_private);
> +
> +/**
> + * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
> + * @nr_pages; number of pages to free
> + * @pages: the pages
> + */
> +void gnttab_free_pages(int nr_pages, struct page **pages)
> +{
> + gnttab_pages_clear_private(nr_pages, pages);
> free_xenballooned_pages(nr_pages, pages);
> }
> EXPORT_SYMBOL(gnttab_free_pages);
> diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
> index 2e37741f6b8d..de03f2542bb7 100644
> --- a/include/xen/grant_table.h
> +++ b/include/xen/grant_table.h
> @@ -198,6 +198,9 @@ void gnttab_free_auto_xlat_frames(void);
> int gnttab_alloc_pages(int nr_pages, struct page **pages);
> void gnttab_free_pages(int nr_pages, struct page **pages);
>
> +int gnttab_pages_set_private(int nr_pages, struct page **pages);
> +void gnttab_pages_clear_private(int nr_pages, struct page **pages);
> +
> int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
> struct gnttab_map_grant_ref *kmap_ops,
> struct page **pages, unsigned int count);
> --
> 2.17.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH] drm/msm: make pclk_rate u64 to avoid truncation
Hi Abhinav, Thank you for the patch! Yet something to improve: [auto build test ERROR on robclark/msm-next] [also build test ERROR on v4.17-rc7] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Abhinav-Kumar/drm-msm-make-pclk_rate-u64-to-avoid-truncation/20180530-182643 base: git://people.freedesktop.org/~robclark/linux msm-next config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): >> ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/msm/msm.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 10/11] drm/msm/dpu: correct dpu_io_util.h include path
On Wed, May 30, 2018 at 08:19:47PM +0530, Rajesh Yadav wrote: > dpu_io_util.h is moved from standard include path > to driver folder, correct the include path in code. > > Signed-off-by: Rajesh Yadav If the previous patch doesn't compile without this fix you should squash them. > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 1 - > drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c > b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c > index 24c3274..f997bd9 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c > @@ -20,7 +20,6 @@ > #include > #include > #include > -#include > > #include "dpu_power_handle.h" > #include "dpu_trace.h" > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h > b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h > index 9a6d4b9..193f468 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h > @@ -21,7 +21,7 @@ > #define DPU_POWER_HANDLE_ENABLE_BUS_IB_QUOTA 16 > #define DPU_POWER_HANDLE_DISABLE_BUS_IB_QUOTA0 > > -#include > +#include "dpu_io_util.h" > > /* event will be triggered before power handler disable */ > #define DPU_POWER_EVENT_PRE_DISABLE 0x1 -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106258] AMD Xorg start failes with non-4K page sizes
https://bugs.freedesktop.org/show_bug.cgi?id=106258 --- Comment #20 from Ben Crocker --- Please note that the path to the firmware, /lib/firmware/amdgpu, is correct for Red Hat products (RHEL, Fedora, CentOS) as well. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/13] drm: Eliminate plane->fb/crtc usage for atomic drivers
Thanks Ville. This series: Reviewed-by: Sinclair Yeh On Fri, May 25, 2018 at 09:50:32PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Here are again the last (?) bits of eliminating the plane->fb/crtc > usage for atomic drivers. I've pushed everything else (thanks to > everyone who reviewed them). > > Deepak said he'd tested the vmwgfx stuff, so I think it should be > safe to land. Just missing a bit of review... > > Cc: Alex Deucher > Cc: amd-...@lists.freedesktop.org > Cc: "Christian König" > Cc: Daniel Vetter > Cc: David Airlie > Cc: "David (ChunMing) Zhou" > Cc: Deepak Rawat > Cc: Eric Anholt > Cc: freedr...@lists.freedesktop.org > Cc: Gerd Hoffmann > Cc: Harry Wentland > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Kyungmin Park > Cc: linux-arm-...@vger.kernel.org > Cc: Rob Clark > Cc: Seung-Woo Kim > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Cc: virtualizat...@lists.linux-foundation.org > Cc: VMware Graphics > > Ville Syrjälä (13): > drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset() > drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty() > drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb() > drm/vmwgfx: Stop updating plane->fb > drm/vmwgfx: Stop using plane->fb in atomic_enable() > drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc > drm/amdgpu/dc: Stop updating plane->fb > drm/i915: Stop updating plane->fb/crtc > drm/exynos: Stop updating plane->crtc > drm/msm: Stop updating plane->fb/crtc > drm/virtio: Stop updating plane->crtc > drm/vc4: Stop updating plane->fb/crtc > drm: Stop updating plane->crtc/fb/old_fb on atomic drivers > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 - > drivers/gpu/drm/drm_atomic.c | 55 > +++ > drivers/gpu/drm/drm_atomic_helper.c | 15 +-- > drivers/gpu/drm/drm_crtc.c| 8 +++- > drivers/gpu/drm/drm_fb_helper.c | 7 --- > drivers/gpu/drm/drm_framebuffer.c | 5 --- > drivers/gpu/drm/drm_plane.c | 14 +++--- > drivers/gpu/drm/drm_plane_helper.c| 4 +- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 - > drivers/gpu/drm/i915/intel_atomic_plane.c | 12 - > drivers/gpu/drm/i915/intel_display.c | 7 ++- > drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 1 - > drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c| 2 - > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 1 - > drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 2 - > drivers/gpu/drm/vc4/vc4_crtc.c| 3 -- > drivers/gpu/drm/virtio/virtgpu_display.c | 2 - > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 24 -- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 24 +++--- > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 - > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 5 +-- > include/drm/drm_atomic.h | 3 -- > 22 files changed, 46 insertions(+), 154 deletions(-) > > -- > 2.16.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm/panel: Add support for Truly NT35597 panel
On Fri, May 25, 2018 at 05:27:51PM -0700, Abhinav Kumar wrote:
> Add support for Truly NT35597 panel used
> in MSM reference platforms.
>
> This panel supports both single DSI and dual DSI
> modes.
>
> However, this patch series adds support only for
> dual DSI mode.
>
> Changes in v4:
> - Fix the license identifier
> - Fix formatting issues for the regulator loads
> - Fix error messages and return code
>
> Signed-off-by: Archit Taneja
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/panel/Kconfig | 8 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 576
>
> 3 files changed, 585 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 25682ff..2fcd9b1 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -177,4 +177,12 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_TRULY_NT35597_WQXGA
> + tristate "Truly WQXGA"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
> + help
> + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
> DSI
> + Video Mode panel
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index f26efc1..056ea93 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -18,3 +18,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> new file mode 100644
> index 000..a57cbf0
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> @@ -0,0 +1,576 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const char * const regulator_names[] = {
> + "vdda",
> + "vdispp",
> + "vdispn"
> +};
> +
> +static unsigned long const regulator_enable_loads[] = {
> + 62000,
> + 10,
> + 10,
> +};
> +
> +static unsigned long const regulator_disable_loads[] = {
> + 80,
> + 100,
> + 100,
> +};
> +
> +struct truly_wqxga {
> + struct device *dev;
> + struct drm_panel panel;
> +
> + struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
> +
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *mode_gpio;
> +
> + struct backlight_device *backlight;
> + struct videomode vm;
> +
> + struct mipi_dsi_device *dsi[2];
> +
> + bool prepared;
> + bool enabled;
> +};
> +
> +static inline struct truly_wqxga *panel_to_truly_wqxga(struct drm_panel
> *panel)
> +{
> + return container_of(panel, struct truly_wqxga, panel);
> +}
> +
> +static int truly_wqxga_power_on(struct truly_wqxga *ctx)
> +{
> + int ret, i;
> +
> + for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
> + ret = regulator_set_load(ctx->supplies[i].consumer,
> + regulator_enable_loads[i]);
> + if (ret)
> + return ret;
> + }
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> + if (ret < 0)
> + return ret;
> +
> + msleep(20);
> + gpiod_set_value(ctx->reset_gpio, 1);
> + msleep(20);
> + gpiod_set_value(ctx->reset_gpio, 0);
> + msleep(20);
> + gpiod_set_value(ctx->reset_gpio, 1);
> + msleep(50);
Why is this needed? Could you please comment?
Also, it seems like this is active low? You should specify that in the dt, and
let gpiod translate the value.
> +
> + return 0;
> +}
> +
> +static int truly_wqxga_power_off(struct truly_wqxga *ctx)
> +{
> + int ret, i;
> +
> + gpiod_set_value(ctx->reset_gpio, 0);
> +
> + for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
> + ret = regulator_set_load(ctx->supplies[i].consumer,
> + regulator_disable_loads[i]);
> + if (ret)
> + return ret;
> + }
> +
> + return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> +}
> +
> +static int truly_wqxga_disable(struct drm_panel *panel)
> +{
> + struct truly_wqxga *ctx = panel_to_truly_wqxga(panel);
> +
> + if (!ctx->enabled)
> +
[PATCH 1/2] drm/scheduler: Avoid using wait_event_killable for dying process.
Dying process might be blocked from receiving any more signals
so avoid using it.
Also retire enity->fini_status and just check the SW queue,
if it's not empty do the fallback cleanup.
Also handle entity->last_scheduled == NULL use case which
happens when HW ring is already hangged whem a new entity
tried to enqeue jobs.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 47 ++-
include/drm/gpu_scheduler.h | 1 -
2 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 44d4807..4d038f9 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -135,7 +135,6 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
entity->rq = rq;
entity->sched = sched;
entity->guilty = guilty;
- entity->fini_status = 0;
entity->last_scheduled = NULL;
spin_lock_init(>rq_lock);
@@ -173,7 +172,8 @@ static bool drm_sched_entity_is_initialized(struct
drm_gpu_scheduler *sched,
static bool drm_sched_entity_is_idle(struct drm_sched_entity *entity)
{
rmb();
- if (spsc_queue_peek(>job_queue) == NULL)
+
+ if (entity->rq == NULL || spsc_queue_peek(>job_queue) == NULL)
return true;
return false;
@@ -227,12 +227,16 @@ void drm_sched_entity_do_release(struct drm_gpu_scheduler
*sched,
* The client will not queue more IBs during this fini, consume existing
* queued IBs or discard them on SIGKILL
*/
- if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL)
- entity->fini_status = -ERESTARTSYS;
+ if ((current->flags & PF_EXITING))
+ wait_event_timeout(sched->job_scheduled,
+ drm_sched_entity_is_idle(entity),
msecs_to_jiffies(1000));
else
- entity->fini_status = wait_event_killable(sched->job_scheduled,
- drm_sched_entity_is_idle(entity));
- drm_sched_entity_set_rq(entity, NULL);
+ wait_event_killable(sched->job_scheduled,
drm_sched_entity_is_idle(entity));
+
+
+ /* For killed process disable any more IBs enqueue right now */
+ if ((current->flags & PF_EXITING) && (current->exit_code == SIGKILL))
+ drm_sched_entity_set_rq(entity, NULL);
}
EXPORT_SYMBOL(drm_sched_entity_do_release);
@@ -247,7 +251,13 @@ EXPORT_SYMBOL(drm_sched_entity_do_release);
void drm_sched_entity_cleanup(struct drm_gpu_scheduler *sched,
struct drm_sched_entity *entity)
{
- if (entity->fini_status) {
+
+ drm_sched_entity_set_rq(entity, NULL);
+
+ /* Consumption of existing IBs wasn't completed. Forcefully
+* remove them here.
+*/
+ if (spsc_queue_peek(>job_queue)) {
struct drm_sched_job *job;
int r;
@@ -267,12 +277,22 @@ void drm_sched_entity_cleanup(struct drm_gpu_scheduler
*sched,
struct drm_sched_fence *s_fence = job->s_fence;
drm_sched_fence_scheduled(s_fence);
dma_fence_set_error(_fence->finished, -ESRCH);
- r = dma_fence_add_callback(entity->last_scheduled,
>finish_cb,
-
drm_sched_entity_kill_jobs_cb);
- if (r == -ENOENT)
+
+ /*
+* When pipe is hanged by older entity, new entity might
+* not even have chance to submit it's first job to HW
+* and so entity->last_scheduled will remain NULL
+*/
+ if (!entity->last_scheduled)
drm_sched_entity_kill_jobs_cb(NULL,
>finish_cb);
- else if (r)
- DRM_ERROR("fence add callback failed (%d)\n",
r);
+ else {
+ r =
dma_fence_add_callback(entity->last_scheduled, >finish_cb,
+
drm_sched_entity_kill_jobs_cb);
+ if (r == -ENOENT)
+ drm_sched_entity_kill_jobs_cb(NULL,
>finish_cb);
+ else if (r)
+ DRM_ERROR("fence add callback failed
(%d)\n", r);
+ }
}
}
@@ -713,6 +733,7 @@ static int drm_sched_main(void *param)
continue;
sched_job = drm_sched_entity_pop_job(entity);
+
if (!sched_job)
continue;
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index dec6558..d220ac9 100644
--- a/include/drm/gpu_scheduler.h
Re: [PATCH 6/9] drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
Noralf Trønnes writes: > These are needed for pl111 to use the generic fbdev emulation. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm/panel: Add support for Truly NT35597 panel
On Wed, May 30, 2018 at 09:47:25AM -0600, Jordan Crouse wrote:
> On Fri, May 25, 2018 at 05:27:51PM -0700, Abhinav Kumar wrote:
> > Add support for Truly NT35597 panel used
> > in MSM reference platforms.
> >
> > This panel supports both single DSI and dual DSI
> > modes.
> >
> > However, this patch series adds support only for
> > dual DSI mode.
> >
> > Changes in v4:
> > - Fix the license identifier
> > - Fix formatting issues for the regulator loads
> > - Fix error messages and return code
> >
> > Signed-off-by: Archit Taneja
> > Signed-off-by: Abhinav Kumar
> > ---
> > drivers/gpu/drm/panel/Kconfig | 8 +
> > drivers/gpu/drm/panel/Makefile | 1 +
> > drivers/gpu/drm/panel/panel-truly-nt35597.c | 576
> >
> > 3 files changed, 585 insertions(+)
> > create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
> >
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index 25682ff..2fcd9b1 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -177,4 +177,12 @@ config DRM_PANEL_SITRONIX_ST7789V
> > Say Y here if you want to enable support for the Sitronix
> > ST7789V controller for 240x320 LCD panels
> >
> > +config DRM_PANEL_TRULY_NT35597_WQXGA
> > + tristate "Truly WQXGA"
> > + depends on OF
> > + depends on DRM_MIPI_DSI
> > + select VIDEOMODE_HELPERS
> > + help
> > + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
> > DSI
> > + Video Mode panel
> > endmenu
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index f26efc1..056ea93 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -18,3 +18,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> > panel-seiko-43wvf1g.o
> > obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> > obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> > +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> > diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> > b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> > new file mode 100644
> > index 000..a57cbf0
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> > @@ -0,0 +1,576 @@
> > +// SPDX-License-Identifier: GPL-2.0
>
> I guess it is up to Sean and Rob if they want to accept // comments for SPDX.
> I'm not sure there is a hard and fast rule about it.
>
Hard meh from me. Looks like there are plenty of examples of both in drm.
Sean
> > +/*
> > + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +static const char * const regulator_names[] = {
> > + "vdda",
> > + "vdispp",
> > + "vdispn"
>
> The reason why the coding style insists on commas for the last member of an
> listy is that if you added another item the resulting patch would
> only need one line instead of three. For example:
>
> + "foo",
>
> instead of:
>
> - "vdispn"
> + "vdispn",
> + "foo",
>
>
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amdgpu: move amdgpu_ctx_mgr_entity_fini to f_ops flush hook.
With this we can now terminate jobs enqueue into SW queue the moment
the task is being killed instead of waiting for last user of
drm file to release it.
Also stop checking for kref_read(>refcount) == 1 when
calling drm_sched_entity_do_release since other task
might still hold a reference to this entity but we don't
care since KILL means terminate job submission regardless
of what other tasks are doing.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 13 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 1 -
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index c5bb362..db69045 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -452,23 +452,24 @@ void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr
*mgr)
idp = >ctx_handles;
+ mutex_lock(>lock);
idr_for_each_entry(idp, ctx, id) {
- if (!ctx->adev)
+ if (!ctx->adev) {
+ mutex_unlock(>lock);
return;
+ }
for (i = 0; i < ctx->adev->num_rings; i++) {
if (ctx->adev->rings[i] == >adev->gfx.kiq.ring)
continue;
- if (kref_read(>refcount) == 1)
-
drm_sched_entity_do_release(>adev->rings[i]->sched,
- >rings[i].entity);
- else
- DRM_ERROR("ctx %p is still alive\n", ctx);
+ drm_sched_entity_do_release(>adev->rings[i]->sched,
+ >rings[i].entity);
}
}
+ mutex_unlock(>lock);
}
void amdgpu_ctx_mgr_entity_cleanup(struct amdgpu_ctx_mgr *mgr)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index b0bf2f2..36a9acf 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -855,9 +855,21 @@ static const struct dev_pm_ops amdgpu_pm_ops = {
.runtime_idle = amdgpu_pmops_runtime_idle,
};
+static int amdgpu_flush(struct file *f, fl_owner_t id)
+{
+ struct drm_file *file_priv = f->private_data;
+ struct amdgpu_fpriv *fpriv = file_priv->driver_priv;
+
+ amdgpu_ctx_mgr_entity_fini(>ctx_mgr);
+
+ return 0;
+}
+
+
static const struct file_operations amdgpu_driver_kms_fops = {
.owner = THIS_MODULE,
.open = drm_open,
+ .flush = amdgpu_flush,
.release = drm_release,
.unlocked_ioctl = amdgpu_drm_ioctl,
.mmap = amdgpu_mmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index ca21549..1239384 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -930,7 +930,6 @@ void amdgpu_driver_postclose_kms(struct drm_device *dev,
return;
pm_runtime_get_sync(dev->dev);
- amdgpu_ctx_mgr_entity_fini(>ctx_mgr);
if (adev->asic_type != CHIP_RAVEN) {
amdgpu_uvd_free_handles(adev, file_priv);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: Set current atomic state in drm_private_state
On Wed, May 30, 2018 at 06:30:52PM +0100, Alexandru Gheorghe wrote: > drm_private_state has a back pointer to the drm_atomic_state, > however that was not initialized in drm_atomic_get_private_obj_state > after duplication, as it is the case for other drm atomic getters > > Signed-off-by: Alexandru Gheorghe > --- > drivers/gpu/drm/drm_atomic.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 7d25c42..249aaf8 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -1108,6 +1108,7 @@ drm_atomic_get_private_obj_state(struct > drm_atomic_state *state, > state->private_objs[index].old_state = obj->state; > state->private_objs[index].new_state = obj_state; > state->private_objs[index].ptr = obj; > + obj_state->state = state; Reviewed-by: Ville Syrjälä I guess no one ever used that pointer. Should we add some WARNs to drm_atomic_helper_swap_state() to make sure these are correct? I think in general life might be nicer if we didn't even have these pointers at all. As it stands it's pretty easy to accidentally use them when you're not supposed to (eg. after swap_state() try to use the new_state->state). But there's tons of code that would need to be touched to eliminate them so not a very pleasant project. > > state->num_private_objs = num_objs; > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/13] drm/vc4: Stop updating plane->fb/crtc
Ville Syrjala writes: > From: Ville Syrjälä > > We want to get rid of plane->fb/crtc on atomic drivers. Stop setting > them. > > Cc: Eric Anholt > Signed-off-by: Ville Syrjälä > Reviewed-by: Maarten Lankhorst > Reviewed-by: Daniel Vetter Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106735] [amdgpu] all displays reconnect after failed EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=106735 --- Comment #3 from dwagner --- (In reply to Matthias from comment #2) > Should I try to force a binary EDID for the connected PSVR? At this time, I would recommend against this: I experience consistent crashes on evey S3 resume if use the kernel command line parameter to force a certain binary EDID. Which is a pity, because (a) this worked fine with prior kernel versions until early October 2017 and (b) it was useful when waking up the computer remotely while the connected display is still switched off. See also: https://bugs.freedesktop.org/show_bug.cgi?id=103277 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/amdgpu/df: fix potential array out-of-bounds read
From: Colin Ian King
The comparison with the number of elements in array df_v3_7_channel_number
is off-by-one and can produce an array out-of-bounds read if
fb_channel_number is equal to the number of elements of the array. Fix
this by changing the comparison to >= instead of >.
Detected by CoverityScan, CID#1469489 ("Out-of-bounds read")
Fixes: 13b581502d51 ("drm/amdgpu/df: implement df v3_6 callback functions (v2)")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
index 60608b3df881..d5ebe566809b 100644
--- a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
+++ b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c
@@ -64,7 +64,7 @@ static u32 df_v3_6_get_hbm_channel_number(struct
amdgpu_device *adev)
int fb_channel_number;
fb_channel_number = adev->df_funcs->get_fb_channel_number(adev);
- if (fb_channel_number > ARRAY_SIZE(df_v3_6_channel_number))
+ if (fb_channel_number >= ARRAY_SIZE(df_v3_6_channel_number))
fb_channel_number = 0;
return df_v3_6_channel_number[fb_channel_number];
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA
On 05/30/2018 06:20 PM, Boris Ostrovsky wrote:
On 05/30/2018 02:34 AM, Oleksandr Andrushchenko wrote:
On 05/29/2018 10:10 PM, Boris Ostrovsky wrote:
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
+/**
+ * gnttab_dma_free_pages - free DMAable pages
+ * @args: arguments to the function
+ */
+int gnttab_dma_free_pages(struct gnttab_dma_alloc_args *args)
+{
+ xen_pfn_t *frames;
+ size_t size;
+ int i, ret;
+
+ gnttab_pages_clear_private(args->nr_pages, args->pages);
+
+ frames = kcalloc(args->nr_pages, sizeof(*frames), GFP_KERNEL);
Any way you can do it without allocating memory? One possibility is to
keep allocated frames from gnttab_dma_alloc_pages(). (Not sure I like
that either but it's the only thing I can think of).
Yes, I was also thinking about storing the allocated frames array from
gnttab_dma_alloc_pages(), but that seemed not to be clear enough as
the caller of the gnttab_dma_alloc_pages will need to store those frames
in some context, so we can pass them on free. But the caller doesn't
really
need the frames which might confuse, so I decided to make those
allocations
on the fly.
But I can still rework that to store the frames if you insist: please
let me know.
I would prefer not to allocate anything in the release path. Yes, I
realize that dragging frames array around is not necessary but IMO it's
better than potentially failing an allocation during a teardown. A
comment in the struct definition could explain the reason for having
this field.
Then I would suggest we have it this way: current API requires that
struct page **pages are allocated from outside. So, let's allocate
the frames from outside as well. This way the caller is responsible for
both pages and frames arrays and API looks consistent.
+ if (!frames)
+ return -ENOMEM;
+
+ for (i = 0; i < args->nr_pages; i++)
+ frames[i] = page_to_xen_pfn(args->pages[i]);
Not xen_page_to_gfn()?
Well, according to [1] it should be :
/* XENMEM_populate_physmap requires a PFN based on Xen
* granularity.
*/
frame_list[i] = page_to_xen_pfn(page);
Ah, yes. I was looking at decrease_reservation and automatically assumed
the same parameter type.
Good, then this one is resolved
-boris
Thank you,
Oleksandr
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes for 4.17
Hi Dave, One more fix that came in today. It's fixing a regression introduced during the merge window, so it'd be nice to get it in. drm-misc-fixes-2018-05-30: dw-hdmi: Fix Oops regression from rc1 (Neil) Cc: Neil Armstrong Cheers, Sean The following changes since commit 2bc5ff0bdc00d81d719dad74589317a260d583ed: drm/omap: fix NULL deref crash with SDI displays (2018-05-24 19:14:46 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-05-30 for you to fetch changes up to c32048d9e93a5ab925d745396c63e7b912147f0a: drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense (2018-05-30 13:42:39 -0400) dw-hdmi: Fix Oops regression from rc1 (Neil) Cc: Neil Armstrong Neil Armstrong (1): drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 15 --- drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +- include/drm/bridge/dw_hdmi.h | 2 +- 3 files changed, 6 insertions(+), 13 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106594] [radeonsi,regression,apitrace] Prison Architect rendered unplayable by multicoloured flickering triangles and overlayed triangles when performing certain actions
https://bugs.freedesktop.org/show_bug.cgi?id=106594 Kai changed: What|Removed |Added CC||bri...@vmware.com, ||mathias.froehl...@web.de QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Keywords||bisected Component|Drivers/Gallium/radeonsi|Mesa core --- Comment #6 from Kai --- The bisection result is: > 9c7be67968aaba224d518dee86dff736a4b599c6 is the first bad commit > commit 9c7be67968aaba224d518dee86dff736a4b599c6 > Author: Mathias Fröhlich > Date: Sun May 13 09:18:57 2018 +0200 > > mesa: Remove FLUSH_VERTICES from VAO state changes. > > Pending draw calls on immediate mode or display list calls do > not depend on changes of the VAO state. So, remove calls to > FLUSH_VERTICES and flag _NEW_ARRAY as appropriate. > > Reviewed-by: Brian Paul > Signed-off-by: Mathias Fröhlich > > :04 04 ad95067168b41b30d17d7ff05ecd47be4ca150e4 > 97ab8bde466f83da431193b045a664e540595d80 M src Reverting that commit generates several conflicts. I'd probably have to revert the whole series? Since this touches core Mesa, the bug shouldn't be constrained to radeonsi, I'll adjust the component accordingly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH v2] drm/msm: make pclk_rate u64 to avoid truncation
Higher values of pclk can exceed 32 bits when multiplied
by a factor.
Make the pclk_rate u64 to accommodate higher pixel clock
rates.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index b916f46..5a04f2d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -668,7 +668,8 @@ static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
u8 lanes = msm_host->lanes;
u32 bpp = dsi_get_bpp(msm_host->format);
- u32 pclk_rate;
+ u64 pclk_rate;
+ u64 pclk_bpp;
if (!mode) {
pr_err("%s: mode not set\n", __func__);
@@ -676,14 +677,18 @@ static int dsi_calc_clk_rate(struct msm_dsi_host
*msm_host)
}
pclk_rate = mode->clock * 1000;
+ pclk_bpp = pclk_rate * bpp;
+
if (lanes > 0) {
- msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes);
+ do_div(pclk_bpp, (8 * lanes));
} else {
pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
- msm_host->byte_clk_rate = (pclk_rate * bpp) / 8;
+ do_div(pclk_bpp, 8);
}
- DBG("pclk=%d, bclk=%d", pclk_rate, msm_host->byte_clk_rate);
+ msm_host->byte_clk_rate = pclk_bpp;
+
+ DBG("pclk=%llu, bclk=%d", pclk_rate, msm_host->byte_clk_rate);
msm_host->esc_clk_rate = clk_get_rate(msm_host->esc_clk);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm/panel: Add support for Truly NT35597 panel
Hi Sean
Thanks for your review.
Some responses below. Please help to check.
Thanks
Abhinav
On 2018-05-30 12:12, Sean Paul wrote:
On Fri, May 25, 2018 at 05:27:51PM -0700, Abhinav Kumar wrote:
Add support for Truly NT35597 panel used
in MSM reference platforms.
This panel supports both single DSI and dual DSI
modes.
However, this patch series adds support only for
dual DSI mode.
Changes in v4:
- Fix the license identifier
- Fix formatting issues for the regulator loads
- Fix error messages and return code
Signed-off-by: Archit Taneja
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/panel/Kconfig | 8 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-truly-nt35597.c | 576
3 files changed, 585 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
diff --git a/drivers/gpu/drm/panel/Kconfig
b/drivers/gpu/drm/panel/Kconfig
index 25682ff..2fcd9b1 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -177,4 +177,12 @@ config DRM_PANEL_SITRONIX_ST7789V
Say Y here if you want to enable support for the Sitronix
ST7789V controller for 240x320 LCD panels
+config DRM_PANEL_TRULY_NT35597_WQXGA
+ tristate "Truly WQXGA"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+ help
+ Say Y here if you want to enable support for Truly NT35597 WQXGA
Dual DSI
+ Video Mode panel
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile
b/drivers/gpu/drm/panel/Makefile
index f26efc1..056ea93 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
panel-seiko-43wvf1g.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) +=
panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) +=
panel-sharp-ls043t1le01.o
obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
b/drivers/gpu/drm/panel/panel-truly-nt35597.c
new file mode 100644
index 000..a57cbf0
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
@@ -0,0 +1,576 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const char * const regulator_names[] = {
+ "vdda",
+ "vdispp",
+ "vdispn"
+};
[Abhinav] Will add a ',' here as per jordan's comment
+
+static unsigned long const regulator_enable_loads[] = {
+ 62000,
+ 10,
+ 10,
+};
+
+static unsigned long const regulator_disable_loads[] = {
+ 80,
+ 100,
+ 100,
+};
+
+struct truly_wqxga {
+ struct device *dev;
+ struct drm_panel panel;
+
+ struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *mode_gpio;
+
+ struct backlight_device *backlight;
+ struct videomode vm;
+
+ struct mipi_dsi_device *dsi[2];
+
+ bool prepared;
+ bool enabled;
+};
+
+static inline struct truly_wqxga *panel_to_truly_wqxga(struct
drm_panel *panel)
+{
+ return container_of(panel, struct truly_wqxga, panel);
+}
+
+static int truly_wqxga_power_on(struct truly_wqxga *ctx)
+{
+ int ret, i;
+
+ for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
+ ret = regulator_set_load(ctx->supplies[i].consumer,
+ regulator_enable_loads[i]);
+ if (ret)
+ return ret;
+ }
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies),
ctx->supplies);
+ if (ret < 0)
+ return ret;
+
+ msleep(20);
+ gpiod_set_value(ctx->reset_gpio, 1);
+ msleep(20);
+ gpiod_set_value(ctx->reset_gpio, 0);
+ msleep(20);
+ gpiod_set_value(ctx->reset_gpio, 1);
+ msleep(50);
Why is this needed? Could you please comment?
Also, it seems like this is active low? You should specify that in the
dt, and
let gpiod translate the value.
[Abhinav] This is the panel's reset sequence which demands this delay. I
can comment the same.
Its active HIGH. I can leave a comment in the bindings mentioning the
same.
Let me know if this is sufficient.
+
+ return 0;
+}
+
+static int truly_wqxga_power_off(struct truly_wqxga *ctx)
+{
+ int ret, i;
+
+ gpiod_set_value(ctx->reset_gpio, 0);
+
+ for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
+ ret = regulator_set_load(ctx->supplies[i].consumer,
+ regulator_disable_loads[i]);
+ if (ret)
+ return ret;
+ }
+
+ return
[Bug 106747] [CI] igt@* - crash - An internal exception that should have been handled was not: UnicodeDecodeError
https://bugs.freedesktop.org/show_bug.cgi?id=106747 Martin Peres changed: What|Removed |Added QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org Summary|[CI] igt@* - crash - An |[CI] igt@* - crash - An |internal exception that |internal exception that |should have been handled|should have been handled |was not:|was not: UnicodeDecodeError |UnicodeDecodeError.An | Whiteboard||ReadyForDev Component|DRM/Intel |IGT --- Comment #1 from Martin Peres --- Moving to IGT. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] xen/gntdev: Implement dma-buf export functionality
On Fri, May 25, 2018 at 06:33:29PM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> 1. Create a dma-buf from grant references provided by the foreign
>domain. By default dma-buf is backed by system memory pages, but
>by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
>as a DMA write-combine/coherent buffer, e.g. allocated with
>corresponding dma_alloc_xxx API.
>Export the resulting buffer as a new dma-buf.
>
> 2. Implement waiting for the dma-buf to be released: block until the
>dma-buf with the file descriptor provided is released.
>If within the time-out provided the buffer is not released then
>-ETIMEDOUT error is returned. If the buffer with the file descriptor
>does not exist or has already been released, then -ENOENT is returned.
>For valid file descriptors this must not be treated as error.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/gntdev.c | 478 ++-
> 1 file changed, 476 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 9e450622af1a..52abc6cd5846 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -4,6 +4,8 @@
> * Device for accessing (in user-space) pages that have been granted by other
> * domains.
> *
> + * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c.
> + *
> * Copyright (c) 2006-2007, D G Murray.
> * (c) 2009 Gerd Hoffmann
> * (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
> @@ -41,6 +43,9 @@
> #ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> #include
> #endif
> +#ifdef CONFIG_XEN_GNTDEV_DMABUF
> +#include
> +#endif
>
> #include
> #include
> @@ -81,6 +86,17 @@ struct gntdev_priv {
> /* Device for which DMA memory is allocated. */
> struct device *dma_dev;
> #endif
> +
> +#ifdef CONFIG_XEN_GNTDEV_DMABUF
> + /* Private data of the hyper DMA buffers. */
> +
> + /* List of exported DMA buffers. */
> + struct list_head dmabuf_exp_list;
> + /* List of wait objects. */
> + struct list_head dmabuf_exp_wait_list;
> + /* This is the lock which protects dma_buf_xxx lists. */
> + struct mutex dmabuf_lock;
> +#endif
> };
>
> struct unmap_notify {
> @@ -125,12 +141,38 @@ struct grant_map {
>
> #ifdef CONFIG_XEN_GNTDEV_DMABUF
> struct xen_dmabuf {
> + struct gntdev_priv *priv;
> + struct dma_buf *dmabuf;
> + struct list_head next;
> + int fd;
> +
> union {
> + struct {
> + /* Exported buffers are reference counted. */
> + struct kref refcount;
> + struct grant_map *map;
> + } exp;
> struct {
> /* Granted references of the imported buffer. */
> grant_ref_t *refs;
> } imp;
> } u;
> +
> + /* Number of pages this buffer has. */
> + int nr_pages;
> + /* Pages of this buffer. */
> + struct page **pages;
> +};
> +
> +struct xen_dmabuf_wait_obj {
> + struct list_head next;
> + struct xen_dmabuf *xen_dmabuf;
> + struct completion completion;
> +};
> +
> +struct xen_dmabuf_attachment {
> + struct sg_table *sgt;
> + enum dma_data_direction dir;
> };
> #endif
>
> @@ -320,6 +362,16 @@ static void gntdev_put_map(struct gntdev_priv *priv,
> struct grant_map *map)
> gntdev_free_map(map);
> }
>
> +#ifdef CONFIG_XEN_GNTDEV_DMABUF
> +static void gntdev_remove_map(struct gntdev_priv *priv, struct grant_map
> *map)
> +{
> + mutex_lock(>lock);
> + list_del(>next);
> + gntdev_put_map(NULL /* already removed */, map);
> + mutex_unlock(>lock);
> +}
> +#endif
> +
> /* -- */
>
> static int find_grant_ptes(pte_t *pte, pgtable_t token,
> @@ -628,6 +680,12 @@ static int gntdev_open(struct inode *inode, struct file
> *flip)
> INIT_LIST_HEAD(>freeable_maps);
> mutex_init(>lock);
>
> +#ifdef CONFIG_XEN_GNTDEV_DMABUF
> + mutex_init(>dmabuf_lock);
> + INIT_LIST_HEAD(>dmabuf_exp_list);
> + INIT_LIST_HEAD(>dmabuf_exp_wait_list);
> +#endif
> +
> if (use_ptemod) {
> priv->mm = get_task_mm(current);
> if (!priv->mm) {
> @@ -1053,17 +,433 @@ static long gntdev_ioctl_grant_copy(struct
> gntdev_priv *priv, void __user *u)
> /* DMA buffer export support. */
> /* -- */
>
> +/* -- */
> +/* Implementation of wait for exported DMA buffer to be released. */
> +/* -- */
> +
> +static void dmabuf_exp_release(struct kref *kref);
> +
> +static struct xen_dmabuf_wait_obj *
> +dmabuf_exp_wait_obj_new(struct gntdev_priv *priv,
> +
Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On Wed, May 30, 2018 at 06:29:36PM +0300, Ville Syrjälä wrote:
> On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote:
> > This patchs adds the cec_notifier feature to the intel_hdmi part
> > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> > between each HDMI ports.
> > The changes will allow the i915 HDMI code to notify EDID and HPD changes
> > to an eventual CEC adapter.
> >
> > Signed-off-by: Neil Armstrong
> > Reviewed-by: Hans Verkuil
> > ---
> > drivers/gpu/drm/i915/Kconfig | 1 +
> > drivers/gpu/drm/i915/intel_display.h | 20
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > drivers/gpu/drm/i915/intel_hdmi.c| 13 +
> > 4 files changed, 36 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> > index dfd9588..2d65d56 100644
> > --- a/drivers/gpu/drm/i915/Kconfig
> > +++ b/drivers/gpu/drm/i915/Kconfig
> > @@ -23,6 +23,7 @@ config DRM_I915
> > select SYNC_FILE
> > select IOSF_MBI
> > select CRC32
> > + select CEC_CORE if CEC_NOTIFIER
> > help
> > Choose this option if you have a system that has "Intel Graphics
> > Media Accelerator" or "HD Graphics" integrated graphics,
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index 4e7418b..c68d1c8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -126,6 +126,26 @@ enum port {
> >
> > #define port_name(p) ((p) + 'A')
> >
> > +static inline const char *port_identifier(enum port port)
> > +{
> > + switch (port) {
> > + case PORT_A:
> > + return "Port A";
> > + case PORT_B:
> > + return "Port B";
> > + case PORT_C:
> > + return "Port C";
> > + case PORT_D:
> > + return "Port D";
> > + case PORT_E:
> > + return "Port E";
> > + case PORT_F:
> > + return "Port F";
> > + default:
> > + return "";
> > + }
> > +}
>
> Could use a comment to make it clear that this identifier is
> expected to remain stable since it's referenced from other drivers.
>
> > +
> > enum dpio_channel {
> > DPIO_CH0,
> > DPIO_CH1
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index d436858..b50e51b 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -39,6 +39,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /**
> > * __wait_for - magic wait macro
> > @@ -1001,6 +1002,7 @@ struct intel_hdmi {
> > bool has_audio;
> > bool rgb_quant_range_selectable;
> > struct intel_connector *attached_connector;
> > + struct cec_notifier *notifier;
>
> "notifier" seems a bit too generic a name. "cec_notifier" would be
> better.
>
> Apart from that this seems OK to me
> Reviewed-by: Ville Syrjälä
It seems that you will need to push this to other trees right?
Feel free to use:
Acked-by: Rodrigo Vivi
>
> > };
> >
> > struct intel_dp_mst_encoder;
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 1baef4a..d522b5b 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> > connected = true;
> > }
> >
> > + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> > +
> > return connected;
> > }
> >
> > @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector,
> > bool force)
> > {
> > enum drm_connector_status status;
> > struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> >
> > DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> > connector->base.id, connector->name);
> > @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector,
> > bool force)
> >
> > intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
> >
> > + if (status != connector_status_connected)
> > + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> > +
> > return status;
> > }
> >
> > @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> > *encoder,
> >
> > static void intel_hdmi_destroy(struct drm_connector *connector)
> > {
> > + if (intel_attached_hdmi(connector)->notifier)
> > + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
> > kfree(to_intel_connector(connector)->detect_edid);
> > drm_connector_cleanup(connector);
> > kfree(connector);
> > @@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct
> > intel_digital_port *intel_dig_port,
> > u32 temp = I915_READ(PEG_BAND_GAP_DATA);
> > I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> > }
> > +
> > +
Re: [PATCH v4 1/9] drm/mediatek: update dt-bindings for mt2712
On Mon, May 28, 2018 at 02:38:19PM +0800, Stu Hsieh wrote: > Update device tree binding documentation for the display subsystem for > Mediatek MT2712 SoCs. > > Signed-off-by: Stu Hsieh > Acked-by: CK Hu > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/10] dt-bindings: tc358754: add DT bindings
On Wed, May 30, 2018 at 02:15:58PM +0200, Maciej Purski wrote:
> From: Andrzej Hajda
>
> The patch adds bindings to Toshiba DSI/LVDS bridge TC358764.
> Bindings describe power supplies, reset gpio and video interfaces.
>
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Maciej Purski
> ---
> .../bindings/display/bridge/toshiba,tc358764.txt | 37
> ++
> 1 file changed, 37 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> new file mode 100644
> index 000..6eda14f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt
> @@ -0,0 +1,37 @@
> +TC358764 MIPI-DSI to LVDS panel bridge
> +
> +Required properties:
> + - compatible: "toshiba,tc358764"
> + - reg: the virtual channel number of a DSI peripheral
> + - vddc-supply: core voltage supply, 1.2V
> + - vddio-supply: I/O voltage supply, 1.8V or 3.3V
> + - vddlvds-supply: LVDS1/2 voltage supply, 3.3V
> + - reset-gpios: a GPIO spec for the reset pin
> +
> +The device node can contain zero to two 'port' child nodes, each with one
How would 0 ports be valid?
> +child 'endpoint' node, according to the bindings defined in [1].
> +The following are properties specific to those nodes.
> +
> +port:
> + - reg: (required) can be 0 for DSI port or 1 for LVDS port;
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + bridge@0 {
> + reg = <0>;
> + compatible = "toshiba,tc358764";
> + vddc-supply = <_1v2_reg>;
> + vddio-supply = <_1v8_reg>;
> + vddlvds-supply = <_3v3_reg>;
> + reset-gpios = < 6 GPIO_ACTIVE_LOW>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@1 {
> + reg = <1>;
> + lvds_ep: endpoint {
> + remote-endpoint = <_ep>;
> + };
> + };
> + };
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #5 from Pixie --- Created attachment 139875 --> https://bugs.freedesktop.org/attachment.cgi?id=139875=edit dmesg log on a working setup (kernel 4.14.35, latest stable mesa) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #7 from Pixie --- Logs from working software submitted. Booting promptly into a newer kernel and salvaging logs from there. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #6 from Pixie --- Created attachment 139876 --> https://bugs.freedesktop.org/attachment.cgi?id=139876=edit Xorg log on the same functional 4.14.35 setup. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #15 from Pixie --- That Git install doesn't seem to have changed anything visible. Doesn't show in logs either, which is weird. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv<8> 0/3] Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver patch here is allocating memory for information to be streamed from the ARM/Linux to the display port. Basically the driver just wraps the information such as the pixels to be drawn by the FPGA FrameBuffer 2. The piece of hardware in discussion is the SoC FPGA where Linux runs on the ARM chip and the FGPA is driven by its NIOS soft core with its own proprietary firmware. For example the application from the ARM Linux would have to write information on the /dev/fb0 with the information stored in the SDRAM to be fetched by the FPGA framebuffer IP and displayed on the Display Port Monitor. Ong Hean Loong (3): ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite ARM:drm ivip Intel FPGA Video and Image Processing Suite .../devicetree/bindings/display/altr,vip-fb2.txt | 112 +++ arch/arm/configs/socfpga_defconfig |5 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivip/Kconfig | 14 ++ drivers/gpu/drm/ivip/Makefile |9 + drivers/gpu/drm/ivip/intel_vip_conn.c | 96 ++ drivers/gpu/drm/ivip/intel_vip_core.c | 162 drivers/gpu/drm/ivip/intel_vip_drv.h | 52 ++ drivers/gpu/drm/ivip/intel_vip_of.c| 193 10 files changed, 646 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt create mode 100644 drivers/gpu/drm/ivip/Kconfig create mode 100644 drivers/gpu/drm/ivip/Makefile create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong
Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
The driver only supports the Intel Arria10 devkit and its variants.
This driver can be either loaded staticlly or in modules.
The OF device tree binding is located at:
Documentation/devicetree/bindings/display/altr,vip-fb2.txt
Signed-off-by: Ong Hean Loong
---
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/ivip/Kconfig | 14 +++
drivers/gpu/drm/ivip/Makefile |9 ++
drivers/gpu/drm/ivip/intel_vip_conn.c | 95
drivers/gpu/drm/ivip/intel_vip_core.c | 163
drivers/gpu/drm/ivip/intel_vip_drv.h | 52 +
drivers/gpu/drm/ivip/intel_vip_of.c | 193 +
8 files changed, 529 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/ivip/Kconfig
create mode 100644 drivers/gpu/drm/ivip/Makefile
create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index deeefa7..cdc8e1a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -204,6 +204,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
source "drivers/gpu/drm/i915/Kconfig"
+source "drivers/gpu/drm/ivip/Kconfig"
+
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 50093ff..c0fba1d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
obj-$(CONFIG_DRM_MGA) += mga/
obj-$(CONFIG_DRM_I810) += i810/
obj-$(CONFIG_DRM_I915) += i915/
+obj-$(CONFIG_DRM_IVIP) += ivip/
obj-$(CONFIG_DRM_MGAG200) += mgag200/
obj-$(CONFIG_DRM_VC4) += vc4/
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 000..1d08b90
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,14 @@
+config DRM_IVIP
+tristate "Intel FGPA Video and Image Processing"
+depends on DRM && OF
+select DRM_GEM_CMA_HELPER
+select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+select DRM_KMS_CMA_HELPER
+help
+ Choose this option if you have an Intel FPGA Arria 10 system
+ and above with an Intel Display Port IP. This does not support
+ legacy Intel FPGA Cyclone V display port. Currently only
single
+ frame buffer is supported. Note that ACPI and X_86
architecture
+ is not supported for Arria10. If M is selected the module
will be
+ called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..cc55b04
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the drm device driver. This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+ intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c
b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 000..46bb04c
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,95 @@
+/*
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
+ .reset = drm_atomic_helper_connector_reset,
+ .detect
Re: [PATCH 0/8] xen: dma-buf support for grant device
On 05/31/2018 04:46 AM, Boris Ostrovsky wrote: On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: Oleksandr Andrushchenko (8): xen/grant-table: Make set/clear page private code shared xen/balloon: Move common memory reservation routines to a module xen/grant-table: Allow allocating buffers suitable for DMA xen/gntdev: Allow mappings for DMA buffers xen/gntdev: Add initial support for dma-buf UAPI xen/gntdev: Implement dma-buf export functionality xen/gntdev: Implement dma-buf import functionality xen/gntdev: Expose gntdev's dma-buf API for in-kernel use drivers/xen/Kconfig | 23 + drivers/xen/Makefile | 1 + drivers/xen/balloon.c | 71 +-- drivers/xen/gntdev.c | 1025 - I think this calls for gntdev_dma.c. I assume you mean as a separate file (part of gntdev driver)? I only had a quick look over gntdev changes but they very much are concentrated in dma-specific routines. I tried to do that, but there are some dependencies between the gntdev.c and gntdev_dma.c, so finally I decided to put it all together. You essentially only share file_operations entry points with original gntdev code, right? fops + mappings done by gntdev (struct grant_map) and I need to release map on dma_buf .release callback which makes some cross-dependencies between modules which seemed to be not cute (gntdev keeps its all structs and functions inside, so I cannot easily access those w/o helpers). But I'll try one more time and move all DMA specific stuff into gntdev_dma.c -boris Thank you, Oleksandr drivers/xen/grant-table.c | 176 +- drivers/xen/mem-reservation.c | 134 + include/uapi/xen/gntdev.h | 106 include/xen/grant_dev.h | 37 ++ include/xen/grant_table.h | 28 + include/xen/mem_reservation.h | 29 + 10 files changed, 1527 insertions(+), 103 deletions(-) create mode 100644 drivers/xen/mem-reservation.c create mode 100644 include/xen/grant_dev.h create mode 100644 include/xen/mem_reservation.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong Intel FPGA Video and Image Processing Suite Frame Buffer II driver config for Arria 10 devkit and its variants Signed-off-by: Ong, Hean Loong --- arch/arm/configs/socfpga_defconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 2620ce7..d7deee8 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -111,6 +111,11 @@ CONFIG_MFD_ALTERA_A10SR=y CONFIG_MFD_STMPE=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_DRM=m +CONFIG_DRM_IVIP=m +CONFIG_DRM_IVIP_OF=m +CONFIG_FB=y +CONFIG_FB_SIMPLE=y CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong
Device tree binding for Intel FPGA Video and Image Processing Suite. The
binding involved would be generated from the Altera (Intel) Qsys system. The
bindings would set the max width, max height, buts per pixel and memory port
width. The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as altr.
V8:
*Add port to Display port decoder
V7:
*Fix OF graph for better description
*Add description for encoder
V6:
*Description have not describe DT device in general
V5:
*remove bindings for bits per symbol as it has only one value which is 8
V4:
*fix properties that does not describe the values
V3:
*OF graph not in accordance to graph.txt
V2:
*Remove Linux driver description
V1:
*Missing vendor prefix
Signed-off-by: Ong, Hean Loong
---
.../devicetree/bindings/display/altr,vip-fb2.txt | 99
1 files changed, 99 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
new file mode 100644
index 000..4092804
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
@@ -0,0 +1,99 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Intel FPGA SoC Arria10 and above with display port IP
+
+The Video Frame Buffer II in Video Image Processing (VIP) suite is an IP core
+that interfaces between system memory and Avalon-ST video ports. The IP core
+can be configured to support the memory reader (from memory to Avalon-ST)
+and/or memory writer (from Avalon-ST to memory) interfaces.
+
+More information the FPGA video IP component can be acquired from
+https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
+/literature/ug/ug_vip.pdf
+
+DT-Bindings:
+=
+Required properties:
+
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+ registers.
+- altr,max-width: The maximum width of the framebuffer in pixels.
+- altr,max-height: The maximum height of the framebuffer in pixels.
+- altr,mem-port-width = the bus width of the avalon master port
+ on the frame reader
+
+Optional sub-nodes:
+- ports: The connection to the encoder
+
+Optional properties
+
+- compatible: "altr, display-port"
+- reg: Physical base address and length of the display port controller's
+ registers
+- clocks: required clock handles for specified pairs in clock name
+- clock-names: required clock names. Contains:
+ - aux_clk: auxiliary clock,
+ - clk: 100 MHz output clock
+ - xcvr_mgmt_clk: transceiver management clock
+
+Optional sub-nodes:
+- ports: The connection to the controller
+
+Connections between the Frame Buffer II and other video IP cores in the system
+are modelled using the OF graph DT bindings. The Frame Buffer II node has up
+to two OF graph ports. When the memory writer interface is enabled, port 0
+maps to the Avalon-ST Input (din) port. When the memory reader interface is
+enabled, port 1 maps to the Avalon-ST Output (dout) port.
+
+The encoder is built into the FPGA HW design and therefore would not
+be accessible from the DDR.
+
+ Port 0 Port1
+-
+ARRIA10 AVALON_ST (DIN)AVALON_ST (DOUT)
+
+Required Properties Example:
+
+
+framebuffer@10280 {
+ compatible = "altr,vip-frame-buffer-2.0";
+ reg = <0x0001 0x0280 0x0040>;
+ altr,max-width = <1280>;
+ altr,max-height = <720>;
+ altr,mem-port-width = <128>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ fb_output: endpoint {
+ remote-endpoint =
<_encoder_input>;
+ };
+ };
+ };
+};
+
+Optional Properties Example:
+This is not required unless there are needs to customize
+Display Port controller settings.
+
+displayport@12000 {
+ compatible = "altr, display-port";
+ reg = <0x0001 0x2000 0x0800>;
+ clocks = <_0_clk_16 _0_clk_100 _0_clk_100>;
+ clock-names = "aux_clk", "clk", "xcvr_mgmt_clk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <1>;
+ dp_input: endpoint {
+
[Bug 82717] OpenCL support for mandelbulber-opencl
https://bugs.freedesktop.org/show_bug.cgi?id=82717 Jan Vesely changed: What|Removed |Added Depends on||87738 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=87738 [Bug 87738] [OpenCL] Please add Image support -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 07/11] drm/msm/dpu: remove dt parsing logic for bus_scale config
Bus scale config related dt-bindings are removed.
Add bus_scale config in driver instead.
Signed-off-by: Rajesh Yadav
---
drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 254 +++
1 file changed, 167 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
index bdf18de..24c3274 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
@@ -20,15 +20,137 @@
#include
#include
#include
-#ifdef CONFIG_QCOM_BUS_SCALING
-#include
-#include
-#endif
#include
#include "dpu_power_handle.h"
#include "dpu_trace.h"
+#ifdef CONFIG_QCOM_BUS_SCALING
+#include
+#include
+
+#define DPU_BUS_VECTOR_ENTRY(src_val, dst_val, ab_val, ib_val) \
+ { \
+ .src = src_val,\
+ .dst = dst_val,\
+ .ab = (ab_val),\
+ .ib = (ib_val),\
+ }
+
+static struct msm_bus_vectors dpu_reg_bus_vectors[] = {
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_FIRST,
+MSM_BUS_SLAVE_DISPLAY_CFG, 0, 0),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_FIRST,
+MSM_BUS_SLAVE_DISPLAY_CFG, 0, 7680),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_FIRST,
+MSM_BUS_SLAVE_DISPLAY_CFG, 0, 15000),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_FIRST,
+MSM_BUS_SLAVE_DISPLAY_CFG, 0, 3),
+};
+
+static struct msm_bus_paths dpu_reg_bus_usecases[] = { {
+ .num_paths = 1,
+ .vectors = _reg_bus_vectors[0],
+}, {
+ .num_paths = 1,
+ .vectors = _reg_bus_vectors[1],
+}, {
+ .num_paths = 1,
+ .vectors = _reg_bus_vectors[2],
+}, {
+ .num_paths = 1,
+ .vectors = _reg_bus_vectors[3],
+} };
+
+static struct msm_bus_scale_pdata dpu_reg_bus_scale_table = {
+ .usecase = dpu_reg_bus_usecases,
+ .num_usecases = ARRAY_SIZE(dpu_reg_bus_usecases),
+ .name = "mdss_reg",
+};
+
+static struct msm_bus_vectors dpu_data_bus_vectors[] = {
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT0,
+MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 0),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT1,
+MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 0),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT0,
+MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 64),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT1,
+MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 64),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT0,
+MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 64),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT1,
+MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 64),
+};
+
+static struct msm_bus_paths dpu_data_bus_usecases[] = { {
+ .num_paths = 2,
+ .vectors = _data_bus_vectors[0],
+}, {
+ .num_paths = 2,
+ .vectors = _data_bus_vectors[2],
+}, {
+ .num_paths = 2,
+ .vectors = _data_bus_vectors[4],
+} };
+
+static struct msm_bus_scale_pdata dpu_data_bus_scale_table = {
+ .usecase = dpu_data_bus_usecases,
+ .num_usecases = ARRAY_SIZE(dpu_data_bus_usecases),
+ .name = "mdss_mnoc",
+};
+
+static struct msm_bus_vectors dpu_llcc_bus_vectors[] = {
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MNOC_HF_MEM_NOC,
+MSM_BUS_SLAVE_LLCC, 0, 0),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MNOC_HF_MEM_NOC,
+MSM_BUS_SLAVE_LLCC, 0, 64),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MNOC_HF_MEM_NOC,
+MSM_BUS_SLAVE_LLCC, 0, 64),
+};
+
+static struct msm_bus_paths dpu_llcc_bus_usecases[] = { {
+ .num_paths = 1,
+ .vectors = _llcc_bus_vectors[0],
+}, {
+ .num_paths = 1,
+ .vectors = _llcc_bus_vectors[1],
+}, {
+ .num_paths = 1,
+ .vectors = _llcc_bus_vectors[2],
+} };
+static struct msm_bus_scale_pdata dpu_llcc_bus_scale_table = {
+ .usecase = dpu_llcc_bus_usecases,
+ .num_usecases = ARRAY_SIZE(dpu_llcc_bus_usecases),
+ .name = "mdss_llcc",
+};
+
+static struct msm_bus_vectors dpu_ebi_bus_vectors[] = {
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_LLCC,
+MSM_BUS_SLAVE_EBI_CH0, 0, 0),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_LLCC,
+MSM_BUS_SLAVE_EBI_CH0, 0, 64),
+ DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_LLCC,
+
[Bug 106735] [amdgpu] all displays reconnect after failed EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=106735 --- Comment #1 from Matthias --- Created attachment 139862 --> https://bugs.freedesktop.org/attachment.cgi?id=139862=edit Xorg.log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #11 from Pixie --- Seems somewhere between what looks like versions 3.19 and 3.25. Gonna guess 4.15 has an earlier version; gonna fetch logs from that shortly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #16 from Pixie --- Running glxgears gives me a GL version of 3.1 Mesa 18.2.0-devel, that the one I'm looking for? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] dt-bindings: new binding for Ilitek ILI9341 display panels
On Fri, May 25, 2018 at 03:14:33PM -0500, David Lechner wrote: > On 05/25/2018 02:36 PM, David Lechner wrote: > > This adds a new binding for Ilitek ILI9341 display panels. It includes > > a compatible string for one display (more can be added in the future). > > > > The vendor prefix "noname" is used because the vendor is not known. > > Looks like I forgot to update "noname" to "adafruit" in the commit message. > Patch is as intended though. Other than that, Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #4 from Pixie --- If instructed how, I would definitely be willing to bisect. Power went out, fell asleep, no xorg logs during the day. Sorry for the delay, a working log/dmesg combo on 4.14.35 coming up shortly, for reference. This breaks on any kernel 4.15 and above, by the way. Decided to report it against whatever is present in 4.17, since the issue still persists there. And if I can get rc4 to install, I'll test that and provide the logs from that. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #10 from Pixie --- Created attachment 139878 --> https://bugs.freedesktop.org/attachment.cgi?id=139878=edit Xorg log on the broken 4.17-rc1 setup The broken Xorg log doesn't even seem to acknowledge the monitor exists through a quick grep. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #9 from Pixie --- Created attachment 139877 --> https://bugs.freedesktop.org/attachment.cgi?id=139877=edit dmesg from a broken 4.17-rc1 setup; look here for the errors -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #12 from Pixie --- Seems like I had the right idea. 4.15 runs amdgpu 3.23. May install a Mesa git version from a PPA after this to check. Really want the new kernels, so I'm probably gonna do that right away after posting the two logs. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] xen/grant-table: Make set/clear page private code shared
On 05/31/2018 12:34 AM, Dongwon Kim wrote:
On Fri, May 25, 2018 at 06:33:24PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/grant-table.c | 54 +--
include/xen/grant_table.h | 3 +++
2 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 27be107d6480..d7488226e1f2 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void)
}
EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
-/**
- * gnttab_alloc_pages - alloc pages suitable for grant mapping into
- * @nr_pages: number of pages to alloc
- * @pages: returns the pages
- */
-int gnttab_alloc_pages(int nr_pages, struct page **pages)
+int gnttab_pages_set_private(int nr_pages, struct page **pages)
{
int i;
- int ret;
-
- ret = alloc_xenballooned_pages(nr_pages, pages);
- if (ret < 0)
- return ret;
for (i = 0; i < nr_pages; i++) {
#if BITS_PER_LONG < 64
struct xen_page_foreign *foreign;
foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
- if (!foreign) {
- gnttab_free_pages(nr_pages, pages);
+ if (!foreign)
Don't we have to free previously allocated "foreign"(s) if it fails in the
middle
(e.g. 0 < i && i < nr_pages - 1) before returning?
gnttab_free_pages(nr_pages, pages); will take care of it when called from
outside, see below. It can also handle partial allocations, so no problem
here
return -ENOMEM;
- }
+
set_page_private(pages[i], (unsigned long)foreign);
#endif
SetPagePrivate(pages[i]);
@@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
return 0;
}
-EXPORT_SYMBOL(gnttab_alloc_pages);
+EXPORT_SYMBOL(gnttab_pages_set_private);
/**
- * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
- * @nr_pages; number of pages to free
- * @pages: the pages
+ * gnttab_alloc_pages - alloc pages suitable for grant mapping into
+ * @nr_pages: number of pages to alloc
+ * @pages: returns the pages
*/
-void gnttab_free_pages(int nr_pages, struct page **pages)
+int gnttab_alloc_pages(int nr_pages, struct page **pages)
+{
+ int ret;
+
+ ret = alloc_xenballooned_pages(nr_pages, pages);
+ if (ret < 0)
+ return ret;
+
+ ret = gnttab_pages_set_private(nr_pages, pages);
+ if (ret < 0)
+ gnttab_free_pages(nr_pages, pages);
+
+ return ret;
+}
+EXPORT_SYMBOL(gnttab_alloc_pages);
+
+void gnttab_pages_clear_private(int nr_pages, struct page **pages)
{
int i;
@@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
ClearPagePrivate(pages[i]);
}
}
+}
+EXPORT_SYMBOL(gnttab_pages_clear_private);
+
+/**
+ * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
+ * @nr_pages; number of pages to free
+ * @pages: the pages
+ */
+void gnttab_free_pages(int nr_pages, struct page **pages)
+{
+ gnttab_pages_clear_private(nr_pages, pages);
free_xenballooned_pages(nr_pages, pages);
}
EXPORT_SYMBOL(gnttab_free_pages);
diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h
index 2e37741f6b8d..de03f2542bb7 100644
--- a/include/xen/grant_table.h
+++ b/include/xen/grant_table.h
@@ -198,6 +198,9 @@ void gnttab_free_auto_xlat_frames(void);
int gnttab_alloc_pages(int nr_pages, struct page **pages);
void gnttab_free_pages(int nr_pages, struct page **pages);
+int gnttab_pages_set_private(int nr_pages, struct page **pages);
+void gnttab_pages_clear_private(int nr_pages, struct page **pages);
+
int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops,
struct gnttab_map_grant_ref *kmap_ops,
struct page **pages, unsigned int count);
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] xen/gntdev: Implement dma-buf export functionality
On 05/31/2018 02:10 AM, Dongwon Kim wrote:
On Fri, May 25, 2018 at 06:33:29PM +0300, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
corresponding dma_alloc_xxx API.
Export the resulting buffer as a new dma-buf.
2. Implement waiting for the dma-buf to be released: block until the
dma-buf with the file descriptor provided is released.
If within the time-out provided the buffer is not released then
-ETIMEDOUT error is returned. If the buffer with the file descriptor
does not exist or has already been released, then -ENOENT is returned.
For valid file descriptors this must not be treated as error.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c | 478 ++-
1 file changed, 476 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 9e450622af1a..52abc6cd5846 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -4,6 +4,8 @@
* Device for accessing (in user-space) pages that have been granted by other
* domains.
*
+ * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c.
+ *
* Copyright (c) 2006-2007, D G Murray.
* (c) 2009 Gerd Hoffmann
* (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
@@ -41,6 +43,9 @@
#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
#include
#endif
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+#include
+#endif
#include
#include
@@ -81,6 +86,17 @@ struct gntdev_priv {
/* Device for which DMA memory is allocated. */
struct device *dma_dev;
#endif
+
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ /* Private data of the hyper DMA buffers. */
+
+ /* List of exported DMA buffers. */
+ struct list_head dmabuf_exp_list;
+ /* List of wait objects. */
+ struct list_head dmabuf_exp_wait_list;
+ /* This is the lock which protects dma_buf_xxx lists. */
+ struct mutex dmabuf_lock;
+#endif
};
struct unmap_notify {
@@ -125,12 +141,38 @@ struct grant_map {
#ifdef CONFIG_XEN_GNTDEV_DMABUF
struct xen_dmabuf {
+ struct gntdev_priv *priv;
+ struct dma_buf *dmabuf;
+ struct list_head next;
+ int fd;
+
union {
+ struct {
+ /* Exported buffers are reference counted. */
+ struct kref refcount;
+ struct grant_map *map;
+ } exp;
struct {
/* Granted references of the imported buffer. */
grant_ref_t *refs;
} imp;
} u;
+
+ /* Number of pages this buffer has. */
+ int nr_pages;
+ /* Pages of this buffer. */
+ struct page **pages;
+};
+
+struct xen_dmabuf_wait_obj {
+ struct list_head next;
+ struct xen_dmabuf *xen_dmabuf;
+ struct completion completion;
+};
+
+struct xen_dmabuf_attachment {
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
};
#endif
@@ -320,6 +362,16 @@ static void gntdev_put_map(struct gntdev_priv *priv, struct grant_map *map)
gntdev_free_map(map);
}
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+static void gntdev_remove_map(struct gntdev_priv *priv, struct grant_map *map)
+{
+ mutex_lock(>lock);
+ list_del(>next);
+ gntdev_put_map(NULL /* already removed */, map);
+ mutex_unlock(>lock);
+}
+#endif
+
/* -- */
static int find_grant_ptes(pte_t *pte, pgtable_t token,
@@ -628,6 +680,12 @@ static int gntdev_open(struct inode *inode, struct file
*flip)
INIT_LIST_HEAD(>freeable_maps);
mutex_init(>lock);
+#ifdef CONFIG_XEN_GNTDEV_DMABUF
+ mutex_init(>dmabuf_lock);
+ INIT_LIST_HEAD(>dmabuf_exp_list);
+ INIT_LIST_HEAD(>dmabuf_exp_wait_list);
+#endif
+
if (use_ptemod) {
priv->mm = get_task_mm(current);
if (!priv->mm) {
@@ -1053,17 +,433 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv
*priv, void __user *u)
/* DMA buffer export support. */
/* -- */
+/* -- */
+/* Implementation of wait for exported DMA buffer to be released. */
+/* -- */
+
+static void dmabuf_exp_release(struct kref *kref);
+
+static struct xen_dmabuf_wait_obj *
+dmabuf_exp_wait_obj_new(struct gntdev_priv *priv,
+ struct xen_dmabuf *xen_dmabuf)
+{
+ struct xen_dmabuf_wait_obj *obj;
+
+ obj =
Re: [PATCH v2 2/4] dt-bindings: Add vendor prefix for Adafruit
On Fri, May 25, 2018 at 02:36:21PM -0500, David Lechner wrote: > This adds a device tree vendor prefix for Adafruit Industries, LLC. > > Signed-off-by: David Lechner > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/10] panel/hv070wsa-100: add DT bindings
On Wed, May 30, 2018 at 02:15:56PM +0200, Maciej Purski wrote: > From: Andrzej Hajda "dt-bindings: display: ..." is preferred subject prefix. > > The patch adds bindings to BOE HV070-WSA WSVGA panel. > Bindings are compatible with simple panel bindings. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Maciej Purski > --- > .../devicetree/bindings/display/panel/boe,hv070wsa-100.txt | 7 > +++ > 1 file changed, 7 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > > diff --git > a/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > new file mode 100644 > index 000..bfc20ac > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > @@ -0,0 +1,7 @@ > +BOE HV070WSA-100 7.01" WSVGA TFT LCD panel > + > +Required properties: > +- compatible: should be "boe,hv070wsa-100" > + > +This binding is compatible with the simple-panel binding, which is specified > +in simple-panel.txt in this directory. You have to state exactly which properties apply. Does this panel have a backlight? 1 supply, 2 supplies, no supplies? Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #8 from Pixie --- Nope, fell flat on its face. rc1 logs coming shortly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #13 from Pixie --- Created attachment 139879 --> https://bugs.freedesktop.org/attachment.cgi?id=139879=edit Broken dmesg on 4.15 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #14 from Pixie --- Created attachment 139880 --> https://bugs.freedesktop.org/attachment.cgi?id=139880=edit Broken Xorg log on 4.15 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Extend grant table module API to allow allocating buffers that can
> be used for DMA operations and mapping foreign grant references
> on top of those.
> The resulting buffer is similar to the one allocated by the balloon
> driver in terms that proper memory reservation is made
> ({increase|decrease}_reservation and VA mappings updated if needed).
> This is useful for sharing foreign buffers with HW drivers which
> cannot work with scattered buffers provided by the balloon driver,
> but require DMAable memory instead.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/Kconfig | 13
> drivers/xen/grant-table.c | 124 ++
> include/xen/grant_table.h | 25
> 3 files changed, 162 insertions(+)
>
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index e5d0c28372ea..3431fe210624 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -161,6 +161,19 @@ config XEN_GRANT_DEV_ALLOC
> to other domains. This can be used to implement frontend drivers
> or as part of an inter-domain shared memory channel.
>
> +config XEN_GRANT_DMA_ALLOC
> + bool "Allow allocating DMA capable buffers with grant reference module"
> + depends on XEN
Should it depend on anything from DMA? CONFIG_HAS_DMA for example?
> + help
> + Extends grant table module API to allow allocating DMA capable
> + buffers and mapping foreign grant references on top of it.
> + The resulting buffer is similar to one allocated by the balloon
> + driver in terms that proper memory reservation is made
> + ({increase|decrease}_reservation and VA mappings updated if needed).
> + This is useful for sharing foreign buffers with HW drivers which
> + cannot work with scattered buffers provided by the balloon driver,
> + but require DMAable memory instead.
> +
> config SWIOTLB_XEN
> def_bool y
> select SWIOTLB
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index d7488226e1f2..06fe6e7f639c 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -45,6 +45,9 @@
> #include
> #include
> #include
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> +#include
> +#endif
>
> #include
> #include
> @@ -57,6 +60,7 @@
> #ifdef CONFIG_X86
> #include
> #endif
> +#include
> #include
> #include
>
> @@ -811,6 +815,82 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
> }
> EXPORT_SYMBOL(gnttab_alloc_pages);
>
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> +/**
> + * gnttab_dma_alloc_pages - alloc DMAable pages suitable for grant mapping
> into
> + * @args: arguments to the function
> + */
> +int gnttab_dma_alloc_pages(struct gnttab_dma_alloc_args *args)
> +{
> + unsigned long pfn, start_pfn;
> + xen_pfn_t *frames;
> + size_t size;
> + int i, ret;
> +
> + frames = kcalloc(args->nr_pages, sizeof(*frames), GFP_KERNEL);
> + if (!frames)
> + return -ENOMEM;
> +
> + size = args->nr_pages << PAGE_SHIFT;
> + if (args->coherent)
> + args->vaddr = dma_alloc_coherent(args->dev, size,
> + >dev_bus_addr,
> + GFP_KERNEL | __GFP_NOWARN);
> + else
> + args->vaddr = dma_alloc_wc(args->dev, size,
> +>dev_bus_addr,
> +GFP_KERNEL | __GFP_NOWARN);
> + if (!args->vaddr) {
> + pr_err("Failed to allocate DMA buffer of size %zu\n", size);
> + ret = -ENOMEM;
> + goto fail_free_frames;
> + }
> +
> + start_pfn = __phys_to_pfn(args->dev_bus_addr);
> + for (pfn = start_pfn, i = 0; pfn < start_pfn + args->nr_pages;
> + pfn++, i++) {
> + struct page *page = pfn_to_page(pfn);
> +
> + args->pages[i] = page;
> + frames[i] = xen_page_to_gfn(page);
> + xenmem_reservation_scrub_page(page);
> + }
> +
> + xenmem_reservation_va_mapping_reset(args->nr_pages, args->pages);
> +
> + ret = xenmem_reservation_decrease(args->nr_pages, frames);
> + if (ret != args->nr_pages) {
> + pr_err("Failed to decrease reservation for DMA buffer\n");
> + xenmem_reservation_increase(ret, frames);
> + ret = -EFAULT;
> + goto fail_free_dma;
> + }
> +
> + ret = gnttab_pages_set_private(args->nr_pages, args->pages);
> + if (ret < 0)
> + goto fail_clear_private;
> +
> + kfree(frames);
> + return 0;
> +
> +fail_clear_private:
> + gnttab_pages_clear_private(args->nr_pages, args->pages);
> +fail_free_dma:
Do you need to xenmem_reservation_increase()?
> + xenmem_reservation_va_mapping_update(args->nr_pages, args->pages,
> +
Re: [PATCH 5/8] xen/gntdev: Add initial support for dma-buf UAPI
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > > +/* > + * Create a dma-buf [1] from grant references @refs of count @count provided > + * by the foreign domain @domid with flags @flags. > + * > + * By default dma-buf is backed by system memory pages, but by providing > + * one of the GNTDEV_DMA_FLAG_XXX flags it can also be created as > + * a DMA write-combine or coherent buffer, e.g. allocated with dma_alloc_wc/ > + * dma_alloc_coherent. > + * > + * Returns 0 if dma-buf was successfully created and the corresponding > + * dma-buf's file descriptor is returned in @fd. > + * > + * [1] > https://elixir.bootlin.com/linux/latest/source/Documentation/driver-api/dma-buf.rst Documentation/driver-api/dma-buf.rst. -boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] xen/grant-table: Make set/clear page private code shared
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Make set/clear page private code shared and accessible to > other kernel modules which can re-use these instead of open-coding. > > Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Boris Ostrovsky ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Memory {increase|decrease}_reservation and VA mappings update/reset
> code used in balloon driver can be made common, so other drivers can
> also re-use the same functionality without open-coding.
> Create a dedicated module
IIUIC this is not really a module, it's a common file.
> for the shared code and export corresponding
> symbols for other kernel modules.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/Makefile | 1 +
> drivers/xen/balloon.c | 71 ++
> drivers/xen/mem-reservation.c | 134 ++
> include/xen/mem_reservation.h | 29
> 4 files changed, 170 insertions(+), 65 deletions(-)
> create mode 100644 drivers/xen/mem-reservation.c
> create mode 100644 include/xen/mem_reservation.h
>
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 451e833f5931..3c87b0c3aca6 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -2,6 +2,7 @@
> obj-$(CONFIG_HOTPLUG_CPU)+= cpu_hotplug.o
> obj-$(CONFIG_X86)+= fallback.o
> obj-y+= grant-table.o features.o balloon.o manage.o preempt.o time.o
> +obj-y+= mem-reservation.o
> obj-y+= events/
> obj-y+= xenbus/
>
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 065f0b607373..57b482d67a3a 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -71,6 +71,7 @@
> #include
> #include
> #include
> +#include
>
> static int xen_hotplug_unpopulated;
>
> @@ -157,13 +158,6 @@ static DECLARE_DELAYED_WORK(balloon_worker,
> balloon_process);
> #define GFP_BALLOON \
> (GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC)
>
> -static void scrub_page(struct page *page)
> -{
> -#ifdef CONFIG_XEN_SCRUB_PAGES
> - clear_highpage(page);
> -#endif
> -}
> -
> /* balloon_append: add the given page to the balloon. */
> static void __balloon_append(struct page *page)
> {
> @@ -463,11 +457,6 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> int rc;
> unsigned long i;
> struct page *page;
> - struct xen_memory_reservation reservation = {
> - .address_bits = 0,
> - .extent_order = EXTENT_ORDER,
> - .domid= DOMID_SELF
> - };
>
> if (nr_pages > ARRAY_SIZE(frame_list))
> nr_pages = ARRAY_SIZE(frame_list);
> @@ -486,9 +475,7 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> page = balloon_next_page(page);
> }
>
> - set_xen_guest_handle(reservation.extent_start, frame_list);
> - reservation.nr_extents = nr_pages;
> - rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, );
> + rc = xenmem_reservation_increase(nr_pages, frame_list);
> if (rc <= 0)
> return BP_EAGAIN;
>
> @@ -496,29 +483,7 @@ static enum bp_state increase_reservation(unsigned long
> nr_pages)
> page = balloon_retrieve(false);
> BUG_ON(page == NULL);
>
> -#ifdef CONFIG_XEN_HAVE_PVMMU
> - /*
> - * We don't support PV MMU when Linux and Xen is using
> - * different page granularity.
> - */
> - BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
> -
> - if (!xen_feature(XENFEAT_auto_translated_physmap)) {
> - unsigned long pfn = page_to_pfn(page);
> -
> - set_phys_to_machine(pfn, frame_list[i]);
> -
> - /* Link back into the page tables if not highmem. */
> - if (!PageHighMem(page)) {
> - int ret;
> - ret = HYPERVISOR_update_va_mapping(
> - (unsigned long)__va(pfn <<
> PAGE_SHIFT),
> - mfn_pte(frame_list[i],
> PAGE_KERNEL),
> - 0);
> - BUG_ON(ret);
> - }
> - }
> -#endif
> + xenmem_reservation_va_mapping_update(1, , _list[i]);
Can you make a single call to xenmem_reservation_va_mapping_update(rc,
...)? You need to keep track of pages but presumable they can be put
into an array (or a list). In fact, perhaps we can have
balloon_retrieve() return a set of pages.
>
> /* Relinquish the page back to the allocator. */
> free_reserved_page(page);
> @@ -535,11 +500,6 @@ static enum bp_state decrease_reservation(unsigned long
> nr_pages, gfp_t gfp)
> unsigned long i;
> struct page *page, *tmp;
> int ret;
> - struct xen_memory_reservation reservation = {
> - .address_bits = 0,
> - .extent_order = EXTENT_ORDER,
> - .domid= DOMID_SELF
> - };
> LIST_HEAD(pages);
>
[Bug 74974] [radeonsi] x264 OpenCL does not work
https://bugs.freedesktop.org/show_bug.cgi?id=74974 Jan Vesely changed: What|Removed |Added Depends on||87738 --- Comment #1 from Jan Vesely --- based on the email exchange libx264 needs image support Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=87738 [Bug 87738] [OpenCL] Please add Image support -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 Jan Vesely changed: What|Removed |Added Blocks||74974 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=74974 [Bug 74974] [radeonsi] x264 OpenCL does not work -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 81896] [clover/sumo] GPU reset when running some "John the Ripper" (+ jumbo patch, from Git) OpenCL tests
https://bugs.freedesktop.org/show_bug.cgi?id=81896 Jan Vesely changed: What|Removed |Added Summary|GPU reset when running some |[clover/sumo] GPU reset | "John the Ripper" (+ jumbo |when running some "John |patch, from Git) OpenCL |the Ripper" (+ jumbo patch, |tests |from Git) OpenCL tests -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add checks for NULL drm_*_helper_funcs
On Tue, May 29, 2018 at 10:03:53AM +0200, Daniel Vetter wrote:
> On Fri, May 25, 2018 at 05:20:08AM +0300, Haneen Mohammed wrote:
> > This patch add checks for NULL drm_[connector/crtc/plane]_helper_funcs
> > pointers before derefrencing the variable to avoid NULL pointer
> > dereference and make the helper functions as optional as possible.
> >
> > Signed-off-by: Haneen Mohammed
>
> I started reviewing this, and then realized it's a bit a can of worms.
> E.g. connector->funcs->detect shouldn't be there, it's a helper callback
> really (but placed in the wrong function table). So connector->funcs isn't
> optional, but connector->funcs->detect maybe should be optional.
>
> So I'm not sure anymore whether doing this holesale is a good idea. Do we
> still need this for vkms? If yes, then a more focused patch to just make
> the things optional that vkms does not (yet) provide might be better.
> Including an explanation of what exactly blows up in vkms.
>
hm only for running the igt tests & modetest in libdrm.
It was easier to add check for all the funcs, but I will check again the
least amount of checks needed for vkms.
Thank you!
Haneen
> Thanks, Daniel
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 42 +++--
> > drivers/gpu/drm/drm_probe_helper.c | 11
> > 2 files changed, 28 insertions(+), 25 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index c35654591c12..52092deb741d 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -112,9 +112,9 @@ static int handle_conflicting_encoders(struct
> > drm_atomic_state *state,
> > if (!new_conn_state->crtc)
> > continue;
> >
> > - if (funcs->atomic_best_encoder)
> > + if (funcs && funcs->atomic_best_encoder)
> > new_encoder = funcs->atomic_best_encoder(connector,
> > new_conn_state);
> > - else if (funcs->best_encoder)
> > + else if (funcs && funcs->best_encoder)
> > new_encoder = funcs->best_encoder(connector);
> > else
> > new_encoder = drm_atomic_helper_best_encoder(connector);
> > @@ -308,10 +308,10 @@ update_connector_routing(struct drm_atomic_state
> > *state,
> >
> > funcs = connector->helper_private;
> >
> > - if (funcs->atomic_best_encoder)
> > + if (funcs && funcs->atomic_best_encoder)
> > new_encoder = funcs->atomic_best_encoder(connector,
> > new_connector_state);
> > - else if (funcs->best_encoder)
> > + else if (funcs && funcs->best_encoder)
> > new_encoder = funcs->best_encoder(connector);
> > else
> > new_encoder = drm_atomic_helper_best_encoder(connector);
> > @@ -438,7 +438,7 @@ mode_fixup(struct drm_atomic_state *state)
> > continue;
> >
> > funcs = crtc->helper_private;
> > - if (!funcs->mode_fixup)
> > + if (!funcs || !funcs->mode_fixup)
> > continue;
> >
> > ret = funcs->mode_fixup(crtc, _crtc_state->mode,
> > @@ -639,7 +639,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > new_crtc_state->connectors_changed = true;
> > }
> >
> > - if (funcs->atomic_check)
> > + if (funcs && funcs->atomic_check)
> > ret = funcs->atomic_check(connector,
> > new_connector_state);
> > if (ret)
> > return ret;
> > @@ -681,7 +681,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > if (connectors_mask & BIT(i))
> > continue;
> >
> > - if (funcs->atomic_check)
> > + if (funcs && funcs->atomic_check)
> > ret = funcs->atomic_check(connector,
> > new_connector_state);
> > if (ret)
> > return ret;
> > @@ -972,14 +972,16 @@ disable_outputs(struct drm_device *dev, struct
> > drm_atomic_state *old_state)
> >
> >
> > /* Right function depends upon target state. */
> > - if (new_crtc_state->enable && funcs->prepare)
> > - funcs->prepare(crtc);
> > - else if (funcs->atomic_disable)
> > - funcs->atomic_disable(crtc, old_crtc_state);
> > - else if (funcs->disable)
> > - funcs->disable(crtc);
> > - else
> > - funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> > + if (funcs) {
> > + if (new_crtc_state->enable && funcs->prepare)
> > + funcs->prepare(crtc);
> > + else if (funcs->atomic_disable)
> > + funcs->atomic_disable(crtc, old_crtc_state);
> > + else if (funcs->disable)
> > +
Re: [PATCH 1/8] xen/grant-table: Make set/clear page private code shared
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Make set/clear page private code shared and accessible to
> other kernel modules which can re-use these instead of open-coding.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/xen/grant-table.c | 54 +--
> include/xen/grant_table.h | 3 +++
> 2 files changed, 38 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 27be107d6480..d7488226e1f2 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void)
> }
> EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames);
>
> -/**
> - * gnttab_alloc_pages - alloc pages suitable for grant mapping into
> - * @nr_pages: number of pages to alloc
> - * @pages: returns the pages
> - */
> -int gnttab_alloc_pages(int nr_pages, struct page **pages)
> +int gnttab_pages_set_private(int nr_pages, struct page **pages)
> {
> int i;
> - int ret;
> -
> - ret = alloc_xenballooned_pages(nr_pages, pages);
> - if (ret < 0)
> - return ret;
>
> for (i = 0; i < nr_pages; i++) {
> #if BITS_PER_LONG < 64
> struct xen_page_foreign *foreign;
>
> foreign = kzalloc(sizeof(*foreign), GFP_KERNEL);
> - if (!foreign) {
> - gnttab_free_pages(nr_pages, pages);
> + if (!foreign)
> return -ENOMEM;
> - }
> +
> set_page_private(pages[i], (unsigned long)foreign);
> #endif
> SetPagePrivate(pages[i]);
> @@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page
> **pages)
>
> return 0;
> }
> -EXPORT_SYMBOL(gnttab_alloc_pages);
> +EXPORT_SYMBOL(gnttab_pages_set_private);
EXPORT_SYMBOL_GPL()
>
> /**
> - * gnttab_free_pages - free pages allocated by gnttab_alloc_pages()
> - * @nr_pages; number of pages to free
> - * @pages: the pages
> + * gnttab_alloc_pages - alloc pages suitable for grant mapping into
> + * @nr_pages: number of pages to alloc
> + * @pages: returns the pages
> */
> -void gnttab_free_pages(int nr_pages, struct page **pages)
> +int gnttab_alloc_pages(int nr_pages, struct page **pages)
> +{
> + int ret;
> +
> + ret = alloc_xenballooned_pages(nr_pages, pages);
> + if (ret < 0)
> + return ret;
> +
> + ret = gnttab_pages_set_private(nr_pages, pages);
> + if (ret < 0)
> + gnttab_free_pages(nr_pages, pages);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(gnttab_alloc_pages);
> +
> +void gnttab_pages_clear_private(int nr_pages, struct page **pages)
> {
> int i;
>
> @@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages)
> ClearPagePrivate(pages[i]);
> }
> }
> +}
> +EXPORT_SYMBOL(gnttab_pages_clear_private);
EXPORT_SYMBOL_GPL()
Juergen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/amdgpu: fix 'ISO C90 forbids mixed declarations'
Please add something like "Fixing a compiler warning." as commit message.
With that done the series is Reviewed-by: Christian König
.
Thanks,
Christian.
Am 30.05.2018 um 05:14 schrieb Chunming Zhou:
Change-Id: I412f5783e2839c53841e6ab665f939236bdc5bf1
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 9ea8fb077aba..12f0d18c6ee8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -657,12 +657,12 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser
*p,
p->bytes_moved_vis);
if (p->bo_list) {
- gds = p->bo_list->gds_obj;
- gws = p->bo_list->gws_obj;
- oa = p->bo_list->oa_obj;
struct amdgpu_vm *vm = >vm;
unsigned i;
+ gds = p->bo_list->gds_obj;
+ gws = p->bo_list->gws_obj;
+ oa = p->bo_list->oa_obj;
for (i = 0; i < p->bo_list->num_entries; i++) {
struct amdgpu_bo *bo = p->bo_list->array[i].robj;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 05/30/2018 07:32 AM, Juergen Gross wrote:
On 25/05/18 17:33, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated module for the shared code and export corresponding
symbols for other kernel modules.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/Makefile | 1 +
drivers/xen/balloon.c | 71 ++
drivers/xen/mem-reservation.c | 134 ++
include/xen/mem_reservation.h | 29
4 files changed, 170 insertions(+), 65 deletions(-)
create mode 100644 drivers/xen/mem-reservation.c
create mode 100644 include/xen/mem_reservation.h
Can you please name this include/xen/mem-reservation.h ?
Will rename
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 451e833f5931..3c87b0c3aca6 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_HOTPLUG_CPU) += cpu_hotplug.o
obj-$(CONFIG_X86) += fallback.o
obj-y += grant-table.o features.o balloon.o manage.o preempt.o time.o
+obj-y += mem-reservation.o
obj-y += events/
obj-y += xenbus/
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 065f0b607373..57b482d67a3a 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -71,6 +71,7 @@
#include
#include
#include
+#include
static int xen_hotplug_unpopulated;
@@ -157,13 +158,6 @@ static DECLARE_DELAYED_WORK(balloon_worker, balloon_process);
#define GFP_BALLOON \
(GFP_HIGHUSER | __GFP_NOWARN | __GFP_NORETRY | __GFP_NOMEMALLOC)
-static void scrub_page(struct page *page)
-{
-#ifdef CONFIG_XEN_SCRUB_PAGES
- clear_highpage(page);
-#endif
-}
-
/* balloon_append: add the given page to the balloon. */
static void __balloon_append(struct page *page)
{
@@ -463,11 +457,6 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
int rc;
unsigned long i;
struct page *page;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid= DOMID_SELF
- };
if (nr_pages > ARRAY_SIZE(frame_list))
nr_pages = ARRAY_SIZE(frame_list);
@@ -486,9 +475,7 @@ static enum bp_state increase_reservation(unsigned long
nr_pages)
page = balloon_next_page(page);
}
- set_xen_guest_handle(reservation.extent_start, frame_list);
- reservation.nr_extents = nr_pages;
- rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, );
+ rc = xenmem_reservation_increase(nr_pages, frame_list);
if (rc <= 0)
return BP_EAGAIN;
@@ -496,29 +483,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages)
page = balloon_retrieve(false);
BUG_ON(page == NULL);
-#ifdef CONFIG_XEN_HAVE_PVMMU
- /*
-* We don't support PV MMU when Linux and Xen is using
-* different page granularity.
-*/
- BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
-
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- unsigned long pfn = page_to_pfn(page);
-
- set_phys_to_machine(pfn, frame_list[i]);
-
- /* Link back into the page tables if not highmem. */
- if (!PageHighMem(page)) {
- int ret;
- ret = HYPERVISOR_update_va_mapping(
- (unsigned long)__va(pfn <<
PAGE_SHIFT),
- mfn_pte(frame_list[i],
PAGE_KERNEL),
- 0);
- BUG_ON(ret);
- }
- }
-#endif
+ xenmem_reservation_va_mapping_update(1, , _list[i]);
/* Relinquish the page back to the allocator. */
free_reserved_page(page);
@@ -535,11 +500,6 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
unsigned long i;
struct page *page, *tmp;
int ret;
- struct xen_memory_reservation reservation = {
- .address_bits = 0,
- .extent_order = EXTENT_ORDER,
- .domid= DOMID_SELF
- };
LIST_HEAD(pages);
if (nr_pages > ARRAY_SIZE(frame_list))
@@ -553,7 +513,7 @@ static enum bp_state decrease_reservation(unsigned long
nr_pages, gfp_t gfp)
break;
}
adjust_managed_page_count(page, -1);
- scrub_page(page);
+ xenmem_reservation_scrub_page(page);
Re: [PATCH 4/8] xen/gntdev: Allow mappings for DMA buffers
On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>
> struct unmap_notify {
> @@ -96,10 +104,28 @@ struct grant_map {
> struct gnttab_unmap_grant_ref *kunmap_ops;
> struct page **pages;
> unsigned long pages_vm_start;
> +
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> + /*
> + * If dmabuf_vaddr is not NULL then this mapping is backed by DMA
> + * capable memory.
> + */
> +
> + /* Device for which DMA memory is allocated. */
> + struct device *dma_dev;
> + /* Flags used to create this DMA buffer: GNTDEV_DMABUF_FLAG_XXX. */
> + bool dma_flags;
Again, I think most of the comments here can be dropped. Except possibly
for the flags.
> + /* Virtual/CPU address of the DMA buffer. */
> + void *dma_vaddr;
> + /* Bus address of the DMA buffer. */
> + dma_addr_t dma_bus_addr;
> +#endif
> };
>
> static int unmap_grant_pages(struct grant_map *map, int offset, int pages);
>
> +static struct miscdevice gntdev_miscdev;
> +
> /* -- */
>
> static void gntdev_print_maps(struct gntdev_priv *priv,
> @@ -121,8 +147,26 @@ static void gntdev_free_map(struct grant_map *map)
> if (map == NULL)
> return;
>
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> + if (map->dma_vaddr) {
> + struct gnttab_dma_alloc_args args;
> +
> + args.dev = map->dma_dev;
> + args.coherent = map->dma_flags & GNTDEV_DMA_FLAG_COHERENT;
> + args.nr_pages = map->count;
> + args.pages = map->pages;
> + args.vaddr = map->dma_vaddr;
> + args.dev_bus_addr = map->dma_bus_addr;
> +
> + gnttab_dma_free_pages();
> + } else if (map->pages) {
> + gnttab_free_pages(map->count, map->pages);
> + }
> +#else
> if (map->pages)
> gnttab_free_pages(map->count, map->pages);
> +#endif
> +
} else
#endif
if (map->pages)
gnttab_free_pages(map->count, map->pages);
(and elsewhere)
> kfree(map->pages);
> kfree(map->grants);
> kfree(map->map_ops);
>
> diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h
> index 6d1163456c03..2d5a4672f07c 100644
> --- a/include/uapi/xen/gntdev.h
> +++ b/include/uapi/xen/gntdev.h
> @@ -200,4 +200,19 @@ struct ioctl_gntdev_grant_copy {
> /* Send an interrupt on the indicated event channel */
> #define UNMAP_NOTIFY_SEND_EVENT 0x2
>
> +/*
> + * Flags to be used while requesting memory mapping's backing storage
> + * to be allocated with DMA API.
> + */
> +
> +/*
> + * The buffer is backed with memory allocated with dma_alloc_wc.
> + */
> +#define GNTDEV_DMA_FLAG_WC (1 << 1)
Is there a reason you are not using bit 0?
-boris
> +
> +/*
> + * The buffer is backed with memory allocated with dma_alloc_coherent.
> + */
> +#define GNTDEV_DMA_FLAG_COHERENT (1 << 2)
> +
> #endif /* __LINUX_PUBLIC_GNTDEV_H__ */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: vgem: Change return type to vm_fault_t
On Tue, May 29, 2018 at 12:14 PM, Daniel Vetter wrote:
> On Thu, May 24, 2018 at 07:51:40PM +0530, Souptick Joarder wrote:
>> On Thu, May 24, 2018 at 6:27 PM, Daniel Vetter wrote:
>> > On Wed, May 23, 2018 at 03:05:35PM +0530, Souptick Joarder wrote:
>> >> On Mon, May 14, 2018 at 9:56 PM, Daniel Vetter wrote:
>> >> > On Thu, May 10, 2018 at 02:51:38PM -0400, Sean Paul wrote:
>> >> >> On Thu, May 10, 2018 at 07:58:11PM +0530, Souptick Joarder wrote:
>> >> >> > Hi Sean,
>> >> >> >
>> >> >> > On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder
>> >> >> > wrote:
>> >> >> > > Use new return type vm_fault_t for fault handler.
>> >> >> > >
>> >> >> > > Signed-off-by: Souptick Joarder
>> >> >> > > Reviewed-by: Matthew Wilcox
>> >> >> > > ---
>> >> >> > > drivers/gpu/drm/vgem/vgem_drv.c | 5 ++---
>> >> >> > > 1 file changed, 2 insertions(+), 3 deletions(-)
>> >> >> > >
>> >> >> > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
>> >> >> > > b/drivers/gpu/drm/vgem/vgem_drv.c
>> >> >> > > index 2524ff1..c64a859 100644
>> >> >> > > --- a/drivers/gpu/drm/vgem/vgem_drv.c
>> >> >> > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
>> >> >> > > @@ -61,13 +61,13 @@ static void vgem_gem_free_object(struct
>> >> >> > > drm_gem_object *obj)
>> >> >> > > kfree(vgem_obj);
>> >> >> > > }
>> >> >> > >
>> >> >> > > -static int vgem_gem_fault(struct vm_fault *vmf)
>> >> >> > > +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
>> >> >> > > {
>> >> >> > > struct vm_area_struct *vma = vmf->vma;
>> >> >> > > struct drm_vgem_gem_object *obj = vma->vm_private_data;
>> >> >> > > /* We don't use vmf->pgoff since that has the fake offset
>> >> >> > > */
>> >> >> > > unsigned long vaddr = vmf->address;
>> >> >> > > - int ret;
>> >> >> > > + vm_fault_t ret = VM_FAULT_SIGBUS;
>> >> >> > > loff_t num_pages;
>> >> >> > > pgoff_t page_offset;
>> >> >> > > page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
>> >> >> > > @@ -77,7 +77,6 @@ static int vgem_gem_fault(struct vm_fault *vmf)
>> >> >> > > if (page_offset > num_pages)
>> >> >> > > return VM_FAULT_SIGBUS;
>> >> >> > >
>> >> >> > > - ret = -ENOENT;
>> >> >> > > mutex_lock(>pages_lock);
>> >> >> > > if (obj->pages) {
>> >> >> > > get_page(obj->pages[page_offset]);
>> >> >> > > --
>> >> >> > > 1.9.1
>> >> >> > >
>> >> >> >
>> >> >> > Any further comment on this patch ?
>> >> >>
>> >> >> Patch looks good to me. My build test fails, though, since vm_fault_t
>> >> >> doesn't
>> >> >> exist in drm-misc-next yet.
>> >> >
>> >> > vm_fault_t is already in upstream, just needs Maarten to do a backmerge.
>> >> > Which I think he's done by now ... Otherwise nag him more :-)
>> >> > -Daniel
>> >> >
>> >> >>
>> >> >> So, for now,
>> >> >>
>> >> >> Reviewed-by: Sean Paul
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Sean Paul, Software Engineer, Google / Chromium OS
>> >> >> ___
>> >> >> dri-devel mailing list
>> >> >> dri-devel@lists.freedesktop.org
>> >> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>> >> >
>> >> > --
>> >> > Daniel Vetter
>> >> > Software Engineer, Intel Corporation
>> >> > http://blog.ffwll.ch
>> >>
>> >> Daniel/ Sean, is this patch already merged for 4.18 ?
>> >
>> > Nope, fell through the cracks. Thanks for the reminder, queued for 4.18
>> > now.
>> > -Daniel
>>
>> Thanks Daniel :).
>> Few other similar drm driver patches are also candidates
>> for 4.18. Are you the right Maintainer to make a request
>> for the same ?
>
> No, please try to find others. I'm occasionally picking stuff up that fell
> through all the cracks, as a last resort, but if I make that a habit then
> this doesn't scale. Please check with MAINTAINERS who's more appropriate
> to get nag mails from you :-)
>
Sorry about it, I will ping the right MAINTAINERS :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] display: panel: Add KOE tx14d24vm1bpa display support (320x240)
This commit adds support for KOE's 5.7" display.
Signed-off-by: Lukasz Majewski
Reviewed-by: Rob Herring
---
Changes for v2:
- Add Reviewed-by tag
---
.../bindings/display/panel/koe,tx14d24vm1bpa.txt | 42 ++
drivers/gpu/drm/panel/panel-simple.c | 26 ++
2 files changed, 68 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
new file mode 100644
index ..be7ac666807b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
@@ -0,0 +1,42 @@
+Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
+
+Required properties:
+- compatible: should be "koe,tx14d24vm1bpa"
+- backlight: phandle of the backlight device attached to the panel
+- power-supply: single regulator to provide the supply voltage
+
+Required nodes:
+- port: Parallel port mapping to connect this display
+
+This panel needs single power supply voltage. Its backlight is conntrolled
+via PWM signal.
+
+Example:
+
+
+Example device-tree definition when connected to iMX53 based board
+
+ lcd_panel: lcd-panel {
+ compatible = "koe,tx14d24vm1bpa";
+ backlight = <_lcd>;
+ power-supply = <_3v3>;
+
+ port {
+ lcd_panel_in: endpoint {
+ remote-endpoint = <_display_out>;
+ };
+ };
+ };
+
+Then one needs to extend the dispX node:
+
+ lcd_display: disp1 {
+
+ port@1 {
+ reg = <1>;
+
+ lcd_display_out: endpoint {
+ remote-endpoint = <_panel_in>;
+ };
+ };
+ };
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index d9984bdb5bb5..103b43ce7dee 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1268,6 +1268,29 @@ static const struct panel_desc innolux_zj070na_01p = {
},
};
+static const struct display_timing koe_tx14d24vm1bpa_timing = {
+ .pixelclock = { 558, 585, 620 },
+ .hactive = { 320, 320, 320 },
+ .hfront_porch = { 30, 30, 30 },
+ .hback_porch = { 30, 30, 30 },
+ .hsync_len = { 1, 5, 17 },
+ .vactive = { 240, 240, 240 },
+ .vfront_porch = { 6, 6, 6 },
+ .vback_porch = { 5, 5, 5 },
+ .vsync_len = { 1, 2, 11 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc koe_tx14d24vm1bpa = {
+ .timings = _tx14d24vm1bpa_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 115,
+ .height = 86,
+ },
+};
+
static const struct display_timing koe_tx31d200vm0baa_timing = {
.pixelclock = { 3960, 4320, 4800 },
.hactive = { 1280, 1280, 1280 },
@@ -2204,6 +2227,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,zj070na-01p",
.data = _zj070na_01p,
}, {
+ .compatible = "koe,tx14d24vm1bpa",
+ .data = _tx14d24vm1bpa,
+ }, {
.compatible = "koe,tx31d200vm0baa",
.data = _tx31d200vm0baa,
}, {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] gpu: drm: etnaviv: Change return type to vm_fault_t
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
Previously vm_insert_page() returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_page() will replace this inefficiency by
returning VM_FAULT_* type.
vmf_error() is the newly introduce inline function
in 4.17-rc6.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
v2: mutex_lock_killable() is replaced with previous
mutex_lock_interruptible() cause that discussion
is not yet reached to any conclusion.
v3: updated the change log.
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 3 ++-
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 37 +--
2 files changed, 11 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
index a54f0b7..f6777f0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -62,7 +63,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
struct drm_file *file);
int etnaviv_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-int etnaviv_gem_fault(struct vm_fault *vmf);
+vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf);
int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64 *offset);
struct sg_table *etnaviv_gem_prime_get_sg_table(struct drm_gem_object *obj);
void *etnaviv_gem_prime_vmap(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index fcc969f..b36e1ef 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -180,31 +180,30 @@ int etnaviv_gem_mmap(struct file *filp, struct
vm_area_struct *vma)
return obj->ops->mmap(obj, vma);
}
-int etnaviv_gem_fault(struct vm_fault *vmf)
+vm_fault_t etnaviv_gem_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct drm_gem_object *obj = vma->vm_private_data;
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
struct page **pages, *page;
pgoff_t pgoff;
- int ret;
+ int err;
/*
* Make sure we don't parallel update on a fault, nor move or remove
-* something from beneath our feet. Note that vm_insert_page() is
+* something from beneath our feet. Note that vmf_insert_page() is
* specifically coded to take care of this, so we don't have to.
*/
- ret = mutex_lock_interruptible(_obj->lock);
- if (ret)
- goto out;
-
+ err = mutex_lock_interruptible(_obj->lock);
+ if (err)
+ return VM_FAULT_NOPAGE;
/* make sure we have pages attached now */
pages = etnaviv_gem_get_pages(etnaviv_obj);
mutex_unlock(_obj->lock);
if (IS_ERR(pages)) {
- ret = PTR_ERR(pages);
- goto out;
+ err = PTR_ERR(pages);
+ return vmf_error(err);
}
/* We don't use vmf->pgoff since that has the fake offset: */
@@ -215,25 +214,7 @@ int etnaviv_gem_fault(struct vm_fault *vmf)
VERB("Inserting %p pfn %lx, pa %lx", (void *)vmf->address,
page_to_pfn(page), page_to_pfn(page) << PAGE_SHIFT);
- ret = vm_insert_page(vma, vmf->address, page);
-
-out:
- switch (ret) {
- case -EAGAIN:
- case 0:
- case -ERESTARTSYS:
- case -EINTR:
- case -EBUSY:
- /*
-* EBUSY is ok: this just means that another thread
-* already did the job.
-*/
- return VM_FAULT_NOPAGE;
- case -ENOMEM:
- return VM_FAULT_OOM;
- default:
- return VM_FAULT_SIGBUS;
- }
+ return vmf_insert_page(vma, vmf->address, page);
}
int etnaviv_gem_mmap_offset(struct drm_gem_object *obj, u64 *offset)
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI
Hi Geert > > HDMI sound doesn't use hdmi0_con. > > You can do it now, thanks > > Thanks, so hdmi0_con can be moved now. > > But HDMI sound does use hdmi0/ports/port@2. right? Yes Best regards --- Kuninori Morimoto ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] xen/gntdev: Add initial support for dma-buf UAPI
On 05/30/2018 01:34 AM, Boris Ostrovsky wrote: On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: +/* + * Create a dma-buf [1] from grant references @refs of count @count provided + * by the foreign domain @domid with flags @flags. + * + * By default dma-buf is backed by system memory pages, but by providing + * one of the GNTDEV_DMA_FLAG_XXX flags it can also be created as + * a DMA write-combine or coherent buffer, e.g. allocated with dma_alloc_wc/ + * dma_alloc_coherent. + * + * Returns 0 if dma-buf was successfully created and the corresponding + * dma-buf's file descriptor is returned in @fd. + * + * [1] https://elixir.bootlin.com/linux/latest/source/Documentation/driver-api/dma-buf.rst Documentation/driver-api/dma-buf.rst. Indeed ;) -boris Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
