[PATCH] Reenabling SS on Cayman
It reverts commit c745fe611ca42295c9d91d8e305d27983e9132ef now that
Cayman is stable since VDDCI fix. Spread spectrum was not the culprit.
Signed-off-by: Alexandre Demers
---
drivers/gpu/drm/radeon/rv770_dpm.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rv770_dpm.c
b/drivers/gpu/drm/radeon/rv770_dpm.c
index da041a4..3c76e1d 100644
--- a/drivers/gpu/drm/radeon/rv770_dpm.c
+++ b/drivers/gpu/drm/radeon/rv770_dpm.c
@@ -2329,12 +2329,6 @@ void rv770_get_engine_memory_ss(struct radeon_device
*rdev)
pi->mclk_ss = radeon_atombios_get_asic_ss_info(rdev, &ss,
ASIC_INTERNAL_MEMORY_SS,
0);
- /* disable ss, causes hangs on some cayman boards */
- if (rdev->family == CHIP_CAYMAN) {
- pi->sclk_ss = false;
- pi->mclk_ss = false;
- }
-
if (pi->sclk_ss || pi->mclk_ss)
pi->dynamic_ss = true;
else
--
2.0.1
Reenable Spread Spectrum on Cayman
Since vddci was the real culprit behind Cayman's dpm problem and now that it is fixed, I've been playing around with kernel 3.16-RC4 and spread spectrum reenabled. So far, no problem and I think it's safe to reenable it for good. Alex, if you share my impression, could you push the following patch? Thanks.
[PATCH v3 4/4] ARM: tegra: roth: add display DT node
Tegra DSI support has been fixed to support continuous clock behavior that
the panel used on SHIELD requires, so finally add its device tree node
since it is functional.
Signed-off-by: Alexandre Courbot
---
arch/arm/boot/dts/tegra114-roth.dts | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114-roth.dts
b/arch/arm/boot/dts/tegra114-roth.dts
index d20898e..78df4ee 100644
--- a/arch/arm/boot/dts/tegra114-roth.dts
+++ b/arch/arm/boot/dts/tegra114-roth.dts
@@ -28,6 +28,22 @@
reg = <0x8000 0x7960>;
};
+ host1x at 5000 {
+ dsi at 5430 {
+ status = "okay";
+
+ vdd-supply = <&vdd_1v2_ap>;
+
+ panel at 0 {
+ compatible = "lg,lh500wx1-sd03";
+ reg = <0>;
+
+ power-supply = <&vdd_lcd>;
+ backlight = <&backlight>;
+ };
+ };
+ };
+
pinmux at 7868 {
pinctrl-names = "default";
pinctrl-0 = <&state_default>;
@@ -823,7 +839,6 @@
regulator-name = "vdd-1v8";
regulator-min-microvolt =
<180>;
regulator-max-microvolt =
<180>;
- regulator-always-on;
regulator-boot-on;
};
@@ -870,10 +885,11 @@
regulator-name =
"vdd-2v8-display";
regulator-min-microvolt =
<280>;
regulator-max-microvolt =
<280>;
+ regulator-always-on;
regulator-boot-on;
};
- ldo3 {
+ vdd_1v2_ap: ldo3 {
regulator-name = "avdd-1v2";
regulator-min-microvolt =
<120>;
regulator-max-microvolt =
<120>;
@@ -1069,7 +1085,7 @@
regulator-boot-on;
};
- regulator at 1 {
+ vdd_lcd: regulator at 1 {
compatible = "regulator-fixed";
reg = <1>;
regulator-name = "vdd_lcd_1v8";
--
2.0.0
[PATCH v3 3/4] drm/tegra: dsi - Handle non-continuous clock flag
Handle the MIPI_DSI_CLOCK_NONCONTINUOUS flag and only set TX-only clock behavior when this flag is present to allow panels requiring continuous clock mode to operate with this driver. Signed-off-by: Alexandre Courbot --- drivers/gpu/drm/tegra/dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c index bd56f2a..eadfeaf 100644 --- a/drivers/gpu/drm/tegra/dsi.c +++ b/drivers/gpu/drm/tegra/dsi.c @@ -474,7 +474,8 @@ static int tegra_output_dsi_enable(struct tegra_output *output) tegra_dsi_writel(dsi, value, DSI_HOST_CONTROL); value = tegra_dsi_readl(dsi, DSI_CONTROL); - value |= DSI_CONTROL_HS_CLK_CTRL; + if (dsi->flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) + value |= DSI_CONTROL_HS_CLK_CTRL; value &= ~DSI_CONTROL_TX_TRIG(3); value &= ~DSI_CONTROL_DCS_ENABLE; value |= DSI_CONTROL_VIDEO_ENABLE; -- 2.0.0
[PATCH v3 2/4] drm/panel: Set non-continuous clock flag on supporting panels
The LG LD070WX3-SL01 and Panasonic VVX10F004B00 are DSI support
non-continuous clock mode. Set the MIPI_DSI_CLOCK_NON_CONTINUOUS
to their definition so host drivers become aware of this capability.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/panel/panel-simple.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index a251361..869a84e3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -545,7 +545,7 @@ static const struct panel_desc_dsi lg_ld070wx3_sl01 = {
.height = 151,
},
},
- .flags = MIPI_DSI_MODE_VIDEO,
+ .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_CLOCK_NON_CONTINUOUS,
.format = MIPI_DSI_FMT_RGB888,
.lanes = 4,
};
@@ -599,7 +599,8 @@ static const struct panel_desc_dsi panasonic_vvx10f004b00 =
{
.height = 136,
},
},
- .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE,
+ .flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+MIPI_DSI_CLOCK_NON_CONTINUOUS,
.format = MIPI_DSI_FMT_RGB888,
.lanes = 4,
};
--
2.0.0
[PATCH v3 1/4] drm/dsi: Flag for non-continuous clock behavior
As per section 5.6.1 of the DSI specification, all DSI transmitters must
support continuous clock behavior on the clock lane, while non-continuous
mode support is only optional. Add a flag that allows devices to indicate
that they support non-continuous clock mode so host drivers can adapt
their behavior accordingly.
Signed-off-by: Alexandre Courbot
---
include/drm/drm_mipi_dsi.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 944f33f..efa1b55 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -94,6 +94,8 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
#define MIPI_DSI_MODE_VSYNC_FLUSH BIT(8)
/* disable EoT packets in HS mode */
#define MIPI_DSI_MODE_EOT_PACKET BIT(9)
+/* device supports non-continuous clock behavior (DSI spec 5.6.1) */
+#define MIPI_DSI_CLOCK_NON_CONTINUOUS BIT(10)
enum mipi_dsi_pixel_format {
MIPI_DSI_FMT_RGB888,
--
2.0.0
[PATCH v3 0/4] drm/dsi/tegra: continuous clock support
This small series adds a flag that allows to specify that a DSI device supports non-continuous clock mode, and uses it in the Tegra DSI driver to only enable this mode on panels that support it. Until now, the Tegra DSI driver unconditionally enabled non-continuous mode, which prevented continous-mode-only panels from working with it. This allows us to enable the panel embedded in NVIDIA SHIELD and which only supports continuous mode. Changes since v2: - Changed the flag to enable non-continuous behavior instead of the contrary, to match the DSI spec more closely and highlight the fact continuous behavior is the default Changes since v1: - Removed unneeded regulator-always-on property for vdd_lcd regulator Alexandre Courbot (4): drm/dsi: Flag for non-continuous clock behavior drm/panel: Set non-continuous clock flag on supporting panels drm/tegra: dsi - Handle non-continuous clock flag ARM: tegra: roth: add display DT node arch/arm/boot/dts/tegra114-roth.dts | 22 +++--- drivers/gpu/drm/panel/panel-simple.c | 5 +++-- drivers/gpu/drm/tegra/dsi.c | 3 ++- include/drm/drm_mipi_dsi.h | 2 ++ 4 files changed, 26 insertions(+), 6 deletions(-) -- 2.0.0
[Bug 81066] New: [r600g] Second Life causes GPU to lock up sometimes with DRI_PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=81066 Priority: medium Bug ID: 81066 Assignee: dri-devel at lists.freedesktop.org Summary: [r600g] Second Life causes GPU to lock up sometimes with DRI_PRIME Severity: normal Classification: Unclassified OS: Linux (All) Reporter: shawn.starr at rogers.com Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 102452 --> https://bugs.freedesktop.org/attachment.cgi?id=102452&action=edit Kernel stack dump kernel: 3.16.0-0.rc4.git0.1.fc21.1.x86_64 mesa: 0.3.0-2.20140707.fc21.x86_64 (git master) Xorg: 1.15.99.904-1.fc21.x86_64 (git master, no 904 build yet) kernel command boot options: BOOT_IMAGE=/vmlinuz-3.16.0-0.rc4.git0.1.fc21.1.x86_64 root=/dev/mapper/fedora_segfault-root ro vconsole.keymap=us rhgb slub_debug=- cgroup_disable=memory console=tty0 console=ttyS0,115200n8 radeon.runpm=0 radeon.dpm=1 radeon.hard_reset=1 intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1 LANG=en_CA.UTF-8 Kernel dump from lockup see attachment 1) I am trying to use the PCI hard_reset radeon.ko option 2) pciehp decides to yank the GPU driver while it's doing a PCI reset (!) 3) When the GPU is reset, it's in a non-finished startup state. This all happened when I tried to play Second Life with the Radeon GPU as offload renderer on the Intel GM45 GPU which is doing the display. To run Second Life I'm using: $ LIBGL_DRI3_DISABLE=1 $ xrandr --setprovideroffloadsink 0x55 0xa2 $DRI_PRIME=1 ./singularity >& /dev/null & Here is the Xrandr providers list: Providers: number : 3 Provider 0: id: 0xa2 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 3 outputs: 4 associated providers: 2 name:Intel Provider 1: id: 0x55 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 4 associated providers: 2 name:radeon Provider 2: id: 0x55 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 4 associated providers: 2 name:radeon -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140708/faa78f36/attachment.html>
[PATCH v2 0/9] Updated fence patch series
On 8 July 2014 20:09, Greg KH wrote: > On Tue, Jul 08, 2014 at 03:44:27PM +0200, Daniel Vetter wrote: >> On Mon, Jul 07, 2014 at 10:30:52AM -0700, Greg KH wrote: >> > On Mon, Jul 07, 2014 at 03:23:17PM +0200, Daniel Vetter wrote: >> > > On Wed, Jul 2, 2014 at 7:37 AM, Greg KH >> > > wrote: >> > > >> Android can expose fences to userspace. It's possible to make the new >> > > >> fence >> > > >> mechanism expose the same fences to userspace by changing >> > > >> sync_fence_create >> > > >> to take a struct fence instead of a struct sync_pt. No other change >> > > >> is needed, >> > > >> because only the fence parts of struct sync_pt are used. But because >> > > >> the >> > > >> userspace fences are a separate problem and I haven't really looked >> > > >> at it yet >> > > >> I feel it should stay in staging, for now. >> > > > >> > > > Ok, that's reasonable. >> > > > >> > > > At first glance, this all looks "sane" to me, any objection from anyone >> > > > if I merge this through my driver-core tree for 3.17? >> > > >> > > Ack from my side fwiw. >> > >> > Thanks, I'll queue it up later today. >> >> btw should we add you as a (co)maintainer for driver/core/dma-buf since >> you seem to want to keep a closer tab on what the insane gfx folks are up >> to in there? > > Sure, why not, what's one more maintainership... > > Oh, does that mean you want me to be the one collecting the patches and > forwarding them on to Linus? If so, that's fine, I can easily do that > as well due to my infrastructure being set up for it. > If you're ok, I could continue to do the collecting / forwarding business - I guess Daniel meant more from the 'not miss patches that need review'! Upto you! > thanks, > > greg k-h Thanks and best regards, ~Sumit -- Thanks and regards, Sumit Semwal Graphics Engineer - Graphics working group Linaro.org ? Open source software for ARM SoCs
[Bug 80673] XCOM: Enemy Unknown - Wrong read access when starting the game
https://bugs.freedesktop.org/show_bug.cgi?id=80673 Hadrien changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #10 from Hadrien --- (In reply to comment #9) > Hadrien, your findings are correct. Can we close this bug now? Sure. I gave all the information to the game developers. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140708/48d479a1/attachment.html>
[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support
On Tue, 8 Jul 2014 11:41:32 -0400
Rob Clark wrote:
> On Tue, Jul 8, 2014 at 10:37 AM, Boris BREZILLON
> wrote:
> > On Tue, 8 Jul 2014 08:49:41 -0400
> > Rob Clark wrote:
> >
> >> On Tue, Jul 8, 2014 at 3:23 AM, Boris BREZILLON
> >> wrote:
> >> > Hello Rob,
> >> >
> >> > On Mon, 7 Jul 2014 23:45:54 -0400
> >> > Rob Clark wrote:
> >> >
> >> >> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON
> >> >> wrote:
> >> >> > The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs
> >> >> > (i.e.
> >> >> > at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
> >> >> > controller device.
> >> >> >
> >> >> > This display controller supports at least one primary plane and might
> >> >> > provide several overlays and an hardware cursor depending on the IP
> >> >> > version.
> >> >> >
> >> >> > At the moment, this driver only implements an RGB connector to
> >> >> > interface
> >> >> > with LCD panels, but support for other kind of external devices (like
> >> >> > DRM
> >> >> > bridges) might be added later.
> >> >> >
> >> >> > Signed-off-by: Boris BREZILLON
> >> >> > ---
> >> >> > drivers/gpu/drm/Kconfig | 2 +
> >> >> > drivers/gpu/drm/Makefile| 1 +
> >> >> > drivers/gpu/drm/atmel-hlcdc/Kconfig | 11 +
> >> >> > drivers/gpu/drm/atmel-hlcdc/Makefile| 7 +
> >> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 469 +++
> >> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 474 +++
> >> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 210 +++
> >> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 706
> >> >> > +++
> >> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h | 422 ++
> >> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c | 351
> >> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 729
> >> >> >
> >> >> > 11 files changed, 3382 insertions(+)
> >> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
> >> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
> >> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> >> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
> >> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
> >> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c
> >> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >> >> > index d1cc2f6..df6f0c1 100644
> >> >> > --- a/drivers/gpu/drm/Kconfig
> >> >> > +++ b/drivers/gpu/drm/Kconfig
> >> >> > @@ -182,6 +182,8 @@ source "drivers/gpu/drm/cirrus/Kconfig"
> >> >
> >> > [...]
> >> >
> >> >> > +
> >> >> > +/**
> >> >> > + * Atmel HLCDC Plane properties.
> >> >> > + *
> >> >> > + * This structure stores plane property definitions.
> >> >> > + *
> >> >> > + * @alpha: alpha blending (or transparency) property
> >> >> > + * @csc: YUV to RGB conversion factors property
> >> >> > + */
> >> >> > +struct atmel_hlcdc_plane_properties {
> >> >> > + struct drm_property *alpha;
> >> >> > + struct drm_property *csc;
> >> >>
> >> >> appears like csc is not used yet, so I suppose you can drop it for
> >> >> now.. when you do add it, don't forget to update drm.tmp. But for
> >> >> now it at least makes review easier when the driver doesn't add new
> >> >> userspace interfaces :-)
> >> >
> >> >
> >> > Sure, I guess this is a leftover from another patch I made to add Color
> >> > Space Conversion configuration.
> >> >
> >> > I'll remove it for the next version.
> >> >
> >> >>
> >> >> > +};
> >> >> > +
> >> >> > +/**
> >> >> > + * Atmel HLCDC Plane.
> >> >> > + *
> >> >> > + * @base: base DRM plane structure
> >> >> > + * @layer: HLCDC layer structure
> >> >> > + * @properties: pointer to the property definitions structure
> >> >> > + * @alpha: current alpha blending (or transparency) status
> >> >> > + */
> >> >> > +struct atmel_hlcdc_plane {
> >> >> > + struct drm_plane base;
> >> >> > + struct atmel_hlcdc_layer layer;
> >> >> > + struct atmel_hlcdc_plane_properties *properties;
> >> >> > +};
> >> >> > +
> >> >> > +static inline struct atmel_hlcdc_plane *
> >> >> > +drm_plane_to_atmel_hlcdc_plane(struct drm_plane *p)
> >> >> > +{
> >> >> > + return container_of(p, struct atmel_hlcdc_plane, base);
> >> >> > +}
> >> >> > +
> >> >> > +static inline struct atmel_hlcdc_plane *
> >> >> > +atmel_hlcdc_layer_to_plane(struct atmel_hlcdc_layer *l)
> >> >> > +{
> >> >> > + return container_of(l, struct atmel_hlcdc_plane, layer);
> >> >> > +}
> >> >> > +
> >> >> > +/**
> >> >> > + * Atmel HLCDC Plane update request structure.
> >> >> > +
[Bug 81020] [radeonsi][regresssion] Wireframe of background rendered through objects in Half-Life 2: Episode 2 with MSAA enabled
https://bugs.freedesktop.org/show_bug.cgi?id=81020 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Ol??k --- Fixed by be536efe20d7d0969e6d5286fc488fcc1c403b6. Closing. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140708/649a80c5/attachment.html>
[Bug 78661] GPU sometimes locks up after boot and/or resume
https://bugzilla.kernel.org/show_bug.cgi?id=78661 --- Comment #10 from Nikolaus Waxweiler --- Alright, both patches active. Will test and report back. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 80673] XCOM: Enemy Unknown - Wrong read access when starting the game
https://bugs.freedesktop.org/show_bug.cgi?id=80673 --- Comment #9 from Marek Ol??k --- Hadrien, your findings are correct. Can we close this bug now? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140708/ac237216/attachment.html>
[PATCH] drm/radeon: fix typo in ci_stop_dpm()
Need to use the RREG32_SMC() accessor since the register is an smc indirect index. Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/ci_dpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c index 10dae41..584090a 100644 --- a/drivers/gpu/drm/radeon/ci_dpm.c +++ b/drivers/gpu/drm/radeon/ci_dpm.c @@ -1179,7 +1179,7 @@ static int ci_stop_dpm(struct radeon_device *rdev) tmp &= ~GLOBAL_PWRMGT_EN; WREG32_SMC(GENERAL_PWRMGT, tmp); - tmp = RREG32(SCLK_PWRMGT_CNTL); + tmp = RREG32_SMC(SCLK_PWRMGT_CNTL); tmp &= ~DYNAMIC_PM_EN; WREG32_SMC(SCLK_PWRMGT_CNTL, tmp); -- 1.8.3.1
[PATCH v4 6/6] drm/nouveau: allocate GPFIFOs and fences coherently
Specify TTM_PL_FLAG_UNCACHED when allocating GPFIFOs and fences to
allow them to be safely accessed by the kernel without being synced
on non-coherent architectures.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nv84_fence.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index ccb6b452d6d0..155b1b192676 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -110,7 +110,7 @@ nouveau_channel_prep(struct nouveau_drm *drm, struct
nouveau_cli *cli,
chan->handle = handle;
/* allocate memory for dma push buffer */
- target = TTM_PL_FLAG_TT;
+ target = TTM_PL_FLAG_TT | TTM_PL_FLAG_UNCACHED;
if (nouveau_vram_pushbuf)
target = TTM_PL_FLAG_VRAM;
diff --git a/drivers/gpu/drm/nouveau/nv84_fence.c
b/drivers/gpu/drm/nouveau/nv84_fence.c
index 9fd475c89820..b5d6737b6b8d 100644
--- a/drivers/gpu/drm/nouveau/nv84_fence.c
+++ b/drivers/gpu/drm/nouveau/nv84_fence.c
@@ -257,8 +257,8 @@ nv84_fence_create(struct nouveau_drm *drm)
if (ret == 0)
ret = nouveau_bo_new(drm->dev, 16 * (pfifo->max + 1), 0,
-TTM_PL_FLAG_TT, 0, 0, NULL,
-&priv->bo_gart);
+TTM_PL_FLAG_TT | TTM_PL_FLAG_UNCACHED, 0,
+0, NULL, &priv->bo_gart);
if (ret == 0) {
ret = nouveau_bo_pin(priv->bo_gart, TTM_PL_FLAG_TT);
if (ret == 0) {
--
2.0.0
[PATCH v4 5/6] drm/nouveau: implement explicitly coherent BOs
Allow nouveau_bo_new() to recognize the TTM_PL_FLAG_UNCACHED flag, which
means that we want the allocated BO to be perfectly coherent between the
CPU and GPU. This is useful on non-coherent architectures for which we
do not want to manually sync some rarely-accessed buffers: typically,
fences and pushbuffers.
A TTM BO allocated with the TTM_PL_FLAG_UNCACHED on a non-coherent
architecture will be populated using the DMA API, and accesses to it
performed using the coherent mapping performed by dma_alloc_coherent().
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 76
drivers/gpu/drm/nouveau/nouveau_bo.h | 1 +
2 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 47e4e8886769..23a29adfabf0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -219,6 +219,9 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
nvbo->tile_flags = tile_flags;
nvbo->bo.bdev = &drm->ttm.bdev;
+ if (!nv_device_is_cpu_coherent(nouveau_dev(dev)))
+ nvbo->force_coherent = flags & TTM_PL_FLAG_UNCACHED;
+
nvbo->page_shift = 12;
if (drm->client.base.vm) {
if (!(flags & TTM_PL_FLAG_TT) && size > 256 * 1024)
@@ -289,8 +292,9 @@ void
nouveau_bo_placement_set(struct nouveau_bo *nvbo, uint32_t type, uint32_t busy)
{
struct ttm_placement *pl = &nvbo->placement;
- uint32_t flags = TTM_PL_MASK_CACHING |
- (nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);
+ uint32_t flags = (nvbo->force_coherent ? TTM_PL_FLAG_UNCACHED :
+TTM_PL_MASK_CACHING) |
+(nvbo->pin_refcnt ? TTM_PL_FLAG_NO_EVICT : 0);
pl->placement = nvbo->placements;
set_placement_list(nvbo->placements, &pl->num_placement,
@@ -390,7 +394,14 @@ nouveau_bo_map(struct nouveau_bo *nvbo)
if (ret)
return ret;
- ret = ttm_bo_kmap(&nvbo->bo, 0, nvbo->bo.mem.num_pages, &nvbo->kmap);
+ /*
+* TTM buffers allocated using the DMA API already have a mapping, let's
+* use it instead.
+*/
+ if (!nvbo->force_coherent)
+ ret = ttm_bo_kmap(&nvbo->bo, 0, nvbo->bo.mem.num_pages,
+ &nvbo->kmap);
+
ttm_bo_unreserve(&nvbo->bo);
return ret;
}
@@ -398,7 +409,14 @@ nouveau_bo_map(struct nouveau_bo *nvbo)
void
nouveau_bo_unmap(struct nouveau_bo *nvbo)
{
- if (nvbo)
+ if (!nvbo)
+ return;
+
+ /*
+* TTM buffers allocated using the DMA API already had a coherent
+* mapping which we used, no need to unmap.
+*/
+ if (!nvbo->force_coherent)
ttm_bo_kunmap(&nvbo->kmap);
}
@@ -482,12 +500,36 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool
interruptible,
return 0;
}
+static inline void *
+_nouveau_bo_mem_index(struct nouveau_bo *nvbo, unsigned index, void *mem, u8
sz)
+{
+ struct ttm_dma_tt *dma_tt;
+ u8 *m = mem;
+
+ index *= sz;
+
+ if (m) {
+ /* kmap'd address, return the corresponding offset */
+ m += index;
+ } else {
+ /* DMA-API mapping, lookup the right address */
+ dma_tt = (struct ttm_dma_tt *)nvbo->bo.ttm;
+ m = dma_tt->cpu_address[index / PAGE_SIZE];
+ m += index % PAGE_SIZE;
+ }
+
+ return m;
+}
+#define nouveau_bo_mem_index(o, i, m) _nouveau_bo_mem_index(o, i, m,
sizeof(*m))
+
u16
nouveau_bo_rd16(struct nouveau_bo *nvbo, unsigned index)
{
bool is_iomem;
u16 *mem = ttm_kmap_obj_virtual(&nvbo->kmap, &is_iomem);
- mem = &mem[index];
+
+ mem = nouveau_bo_mem_index(nvbo, index, mem);
+
if (is_iomem)
return ioread16_native((void __force __iomem *)mem);
else
@@ -499,7 +541,9 @@ nouveau_bo_wr16(struct nouveau_bo *nvbo, unsigned index,
u16 val)
{
bool is_iomem;
u16 *mem = ttm_kmap_obj_virtual(&nvbo->kmap, &is_iomem);
- mem = &mem[index];
+
+ mem = nouveau_bo_mem_index(nvbo, index, mem);
+
if (is_iomem)
iowrite16_native(val, (void __force __iomem *)mem);
else
@@ -511,7 +555,9 @@ nouveau_bo_rd32(struct nouveau_bo *nvbo, unsigned index)
{
bool is_iomem;
u32 *mem = ttm_kmap_obj_virtual(&nvbo->kmap, &is_iomem);
- mem = &mem[index];
+
+ mem = nouveau_bo_mem_index(nvbo, index, mem);
+
if (is_iomem)
return ioread32_native((void __force __iomem *)mem);
else
@@ -523,7 +569,9 @@ nouveau_bo_wr32(struct nouveau_bo *nvbo, unsigned index,
u32 val)
{
bool is_iomem;
u32 *mem = ttm_kmap_obj_virtual(&nvbo->kmap, &is_iomem);
- mem = &mem[index];
+
+ mem = nouveau_bo_mem_index(nvbo,
[PATCH v4 4/6] drm/nouveau: synchronize BOs when required
On architectures for which access to GPU memory is non-coherent,
caches need to be flushed and invalidated explicitly when BO control
changes between CPU and GPU.
This patch adds buffer synchronization functions which invokes the
correct API (PCI or DMA) to ensure synchronization is effective.
Based on the TTM DMA cache helper patches by Lucas Stach.
Signed-off-by: Lucas Stach
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 56 +++
drivers/gpu/drm/nouveau/nouveau_bo.h | 2 ++
drivers/gpu/drm/nouveau/nouveau_gem.c | 12
3 files changed, 70 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 67e9e8e2e2ec..47e4e8886769 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -402,6 +402,60 @@ nouveau_bo_unmap(struct nouveau_bo *nvbo)
ttm_bo_kunmap(&nvbo->kmap);
}
+void
+nouveau_bo_sync_for_device(struct nouveau_bo *nvbo)
+{
+ struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
+ struct nouveau_device *device = nouveau_dev(drm->dev);
+ struct ttm_dma_tt *ttm_dma = (struct ttm_dma_tt *)nvbo->bo.ttm;
+ int i;
+
+ if (!ttm_dma)
+ return;
+
+ if (nv_device_is_cpu_coherent(device) || nvbo->force_coherent)
+ return;
+
+ if (nv_device_is_pci(device)) {
+ for (i = 0; i < ttm_dma->ttm.num_pages; i++)
+ pci_dma_sync_single_for_device(device->pdev,
+ ttm_dma->dma_address[i], PAGE_SIZE,
+ PCI_DMA_TODEVICE);
+ } else {
+ for (i = 0; i < ttm_dma->ttm.num_pages; i++)
+ dma_sync_single_for_device(nv_device_base(device),
+ ttm_dma->dma_address[i], PAGE_SIZE,
+ DMA_TO_DEVICE);
+ }
+}
+
+void
+nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
+{
+ struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
+ struct nouveau_device *device = nouveau_dev(drm->dev);
+ struct ttm_dma_tt *ttm_dma = (struct ttm_dma_tt *)nvbo->bo.ttm;
+ int i;
+
+ if (!ttm_dma)
+ return;
+
+ if (nv_device_is_cpu_coherent(device) || nvbo->force_coherent)
+ return;
+
+ if (nv_device_is_pci(device)) {
+ for (i = 0; i < ttm_dma->ttm.num_pages; i++)
+ pci_dma_sync_single_for_cpu(device->pdev,
+ ttm_dma->dma_address[i], PAGE_SIZE,
+ PCI_DMA_FROMDEVICE);
+ } else {
+ for (i = 0; i < ttm_dma->ttm.num_pages; i++)
+ dma_sync_single_for_cpu(nv_device_base(device),
+ ttm_dma->dma_address[i], PAGE_SIZE,
+ DMA_FROM_DEVICE);
+ }
+}
+
int
nouveau_bo_validate(struct nouveau_bo *nvbo, bool interruptible,
bool no_wait_gpu)
@@ -418,6 +472,8 @@ nouveau_bo_validate(struct nouveau_bo *nvbo, bool
interruptible,
if (!ttm)
return ret;
+ nouveau_bo_sync_for_device(nvbo);
+
device = nouveau_dev(nouveau_bdev(ttm->bdev)->dev);
nv_wr32(device, 0x70004, 0x0001);
if (!nv_wait(device, 0x070004, 0x0001, 0x))
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index ff17c1f432fc..fa42298d2dca 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -81,6 +81,8 @@ void nouveau_bo_wr32(struct nouveau_bo *, unsigned index, u32
val);
void nouveau_bo_fence(struct nouveau_bo *, struct nouveau_fence *);
int nouveau_bo_validate(struct nouveau_bo *, bool interruptible,
bool no_wait_gpu);
+void nouveau_bo_sync_for_device(struct nouveau_bo *nvbo);
+void nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo);
struct nouveau_vma *
nouveau_bo_vma_find(struct nouveau_bo *, struct nouveau_vm *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index c90c0dc0afe8..08829a720891 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -896,6 +896,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void
*data,
spin_lock(&nvbo->bo.bdev->fence_lock);
ret = ttm_bo_wait(&nvbo->bo, true, true, no_wait);
spin_unlock(&nvbo->bo.bdev->fence_lock);
+ nouveau_bo_sync_for_cpu(nvbo);
drm_gem_object_unreference_unlocked(gem);
return ret;
}
@@ -904,6 +905,17 @@ int
nouveau_gem_ioctl_cpu_fini(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
+ struct drm_nouveau_gem_cpu_fini *req = data;
+ struct drm_gem_object *gem;
+ struct nouveau_bo *nvbo;
+
+ gem = drm_gem_object_lookup(dev, file_priv, req->handle);
[PATCH v4 3/6] drm/nouveau: introduce nv_device_is_cpu_coherent()
Add a function allowing us to know whether a device is CPU-coherent,
i.e. accesses performed by the CPU on GPU-mapped buffers will
be immediately visible on the GPU side and vice-versa.
For now, a device is considered to be coherent if it uses the PCI bus on
a non-ARM architecture.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/core/engine/device/base.c | 6 ++
drivers/gpu/drm/nouveau/core/include/core/device.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c
b/drivers/gpu/drm/nouveau/core/engine/device/base.c
index e4e9e64988fe..23c7061aac3c 100644
--- a/drivers/gpu/drm/nouveau/core/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/core/engine/device/base.c
@@ -520,6 +520,12 @@ nv_device_get_irq(struct nouveau_device *device, bool
stall)
}
}
+bool
+nv_device_is_cpu_coherent(struct nouveau_device *device)
+{
+ return (!IS_ENABLED(CONFIG_ARM) && nv_device_is_pci(device));
+}
+
static struct nouveau_oclass
nouveau_device_oclass = {
.handle = NV_ENGINE(DEVICE, 0x00),
diff --git a/drivers/gpu/drm/nouveau/core/include/core/device.h
b/drivers/gpu/drm/nouveau/core/include/core/device.h
index a8a9a9cf16cb..1f9d5d87cf06 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/device.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/device.h
@@ -171,4 +171,7 @@ nv_device_unmap_page(struct nouveau_device *device,
dma_addr_t addr);
int
nv_device_get_irq(struct nouveau_device *device, bool stall);
+bool
+nv_device_is_cpu_coherent(struct nouveau_device *device);
+
#endif
--
2.0.0
[PATCH v4 2/6] drm/nouveau: map pages using DMA API on platform devices
page_to_phys() is not the correct way to obtain the DMA address of a
buffer on a non-PCI system. Use the DMA API functions for this, which
are portable and will allow us to use other DMA API functions for
buffer synchronization.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/core/engine/device/base.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c
b/drivers/gpu/drm/nouveau/core/engine/device/base.c
index 18c8c7245b73..e4e9e64988fe 100644
--- a/drivers/gpu/drm/nouveau/core/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/core/engine/device/base.c
@@ -489,7 +489,10 @@ nv_device_map_page(struct nouveau_device *device, struct
page *page)
if (pci_dma_mapping_error(device->pdev, ret))
ret = 0;
} else {
- ret = page_to_phys(page);
+ ret = dma_map_page(&device->platformdev->dev, page, 0,
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
+ if (dma_mapping_error(&device->platformdev->dev, ret))
+ ret = 0;
}
return ret;
@@ -501,6 +504,9 @@ nv_device_unmap_page(struct nouveau_device *device,
dma_addr_t addr)
if (nv_device_is_pci(device))
pci_unmap_page(device->pdev, addr, PAGE_SIZE,
PCI_DMA_BIDIRECTIONAL);
+ else
+ dma_unmap_page(&device->platformdev->dev, addr,
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
}
int
--
2.0.0
[PATCH v4 1/6] drm/ttm: expose CPU address of DMA-allocated pages
Pages allocated using the DMA API have a coherent memory mapping. Make
this mapping visible to drivers so they can decide to use it instead of
creating their own redundant one.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 2 ++
drivers/gpu/drm/ttm/ttm_tt.c | 6 +-
include/drm/ttm/ttm_bo_driver.h | 2 ++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index fb8259f69839..0301fac5badd 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -847,6 +847,7 @@ static int ttm_dma_pool_get_pages(struct dma_pool *pool,
if (count) {
d_page = list_first_entry(&pool->free_list, struct dma_page,
page_list);
ttm->pages[index] = d_page->p;
+ ttm_dma->cpu_address[index] = d_page->vaddr;
ttm_dma->dma_address[index] = d_page->dma;
list_move_tail(&d_page->page_list, &ttm_dma->pages_list);
r = 0;
@@ -978,6 +979,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
INIT_LIST_HEAD(&ttm_dma->pages_list);
for (i = 0; i < ttm->num_pages; i++) {
ttm->pages[i] = NULL;
+ ttm_dma->cpu_address[i] = 0;
ttm_dma->dma_address[i] = 0;
}
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 75f319090043..341594ede596 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -58,6 +58,8 @@ static void ttm_dma_tt_alloc_page_directory(struct ttm_dma_tt
*ttm)
ttm->ttm.pages = drm_calloc_large(ttm->ttm.num_pages, sizeof(void*));
ttm->dma_address = drm_calloc_large(ttm->ttm.num_pages,
sizeof(*ttm->dma_address));
+ ttm->cpu_address = drm_calloc_large(ttm->ttm.num_pages,
+ sizeof(*ttm->cpu_address));
}
#ifdef CONFIG_X86
@@ -228,7 +230,7 @@ int ttm_dma_tt_init(struct ttm_dma_tt *ttm_dma, struct
ttm_bo_device *bdev,
INIT_LIST_HEAD(&ttm_dma->pages_list);
ttm_dma_tt_alloc_page_directory(ttm_dma);
- if (!ttm->pages || !ttm_dma->dma_address) {
+ if (!ttm->pages || !ttm_dma->dma_address || !ttm_dma->cpu_address) {
ttm_tt_destroy(ttm);
pr_err("Failed allocating page table\n");
return -ENOMEM;
@@ -243,6 +245,8 @@ void ttm_dma_tt_fini(struct ttm_dma_tt *ttm_dma)
drm_free_large(ttm->pages);
ttm->pages = NULL;
+ drm_free_large(ttm_dma->cpu_address);
+ ttm_dma->cpu_address = NULL;
drm_free_large(ttm_dma->dma_address);
ttm_dma->dma_address = NULL;
}
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index a5183da3ef92..7d30f0666d24 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -133,6 +133,7 @@ struct ttm_tt {
* struct ttm_dma_tt
*
* @ttm: Base ttm_tt struct.
+ * @cpu_address: The CPU address of the pages
* @dma_address: The DMA (bus) addresses of the pages
* @pages_list: used by some page allocation backend
*
@@ -142,6 +143,7 @@ struct ttm_tt {
*/
struct ttm_dma_tt {
struct ttm_tt ttm;
+ void **cpu_address;
dma_addr_t *dma_address;
struct list_head pages_list;
};
--
2.0.0
[PATCH v4 0/6] drm: nouveau: memory coherency on ARM
Another revision of this patchset critical for GK20A to operate. Previous attempts were exclusively using either TTM's regular page allocator or the DMA API one. Both have their advantages and drawbacks: the page allocator is fast but requires explicit synchronization on non-coherent architectures, whereas the DMA allocator always returns coherent memory, but is also slower, creates a permanent kernel mapping, and is more constrained as to which memory it can use. This version attempts to use the most-fit allocator according to the buffer use-case: - buffers that are passed to user-space can explicitly be synced during their validation and preparation for CPU access, as previously shown by Lucas (http://lists.freedesktop.org/archives/nouveau/2013-August/014029.html ). For these, we don't mind if the memory is not coherent and prefer to use the page allocator. - buffers that are used by the kernel, typically fences and GPFIFO buffers, are accessed rarely and thus should not trigger a costly flush or cache invalidation. For these, we want to guarantee coherent access and use the DMA API if necessary. This series attempts to implement this behavior by allowing the TTM_PL_FLAG_UNCACHED flag to be passed to nouveau_bo_new(). On coherent architectures this flag is a no-op ; on non-coherent architectures, it will force the creation of a coherent buffer using the DMA-API. Several fixes and changes were necessary to enable this behavior: - CPU addresses of DMA-allocated BOs must be made visible (patch 1) so the coherent mapping can be used by drivers - The DMA-sync functions are required for BOs populated using the page allocator (patch 4). Pages need to be mapped to the device using the correct API if we are to call the sync functions (patch 2). Additionally, we need to understand whether we are on a CPU-coherent architecture (patch 3). - Coherent BOs need to be detected by Nouveau so their coherent kernel mapping can be used instead of creating a new one (patch 5). - Finally, buffers that are used by the kernel should be requested to be coherent (page 6). Changes since v3: - Only use the DMA allocator for BOs that strictly require to be coherent - Fixed the way pages are mapped to the GPU on platform devices - Thoroughly checked with CONFIG_DMA_API_DEBUG that there were no API violations Alexandre Courbot (6): drm/ttm: expose CPU address of DMA-allocated pages drm/nouveau: map pages using DMA API on platform devices drm/nouveau: introduce nv_device_is_cpu_coherent() drm/nouveau: synchronize BOs when required drm/nouveau: implement explicitly coherent BOs drm/nouveau: allocate GPFIFOs and fences coherently drivers/gpu/drm/nouveau/core/engine/device/base.c | 14 ++- drivers/gpu/drm/nouveau/core/include/core/device.h | 3 + drivers/gpu/drm/nouveau/nouveau_bo.c | 132 +++-- drivers/gpu/drm/nouveau/nouveau_bo.h | 3 + drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 12 ++ drivers/gpu/drm/nouveau/nv84_fence.c | 4 +- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 2 + drivers/gpu/drm/ttm/ttm_tt.c | 6 +- include/drm/ttm/ttm_bo_driver.h| 2 + 10 files changed, 167 insertions(+), 13 deletions(-) -- 2.0.0
[PATCH 2/2] drm/udl: Implement page_flip ioctl
On 8 July 2014 17:15, David Herrmann wrote:
> Hi
>
> On Thu, Jul 3, 2014 at 12:13 AM, St?phane Marchesin
> wrote:
>> This is a very crude page_flip implementation for UDL. There are ways
>> to make it better (make it asynchronous, make it do actual vsynced
>> flips...) but that's for another patch.
>>
>> Signed-off-by: St?phane Marchesin
>> ---
>> drivers/gpu/drm/udl/udl_modeset.c | 21 +
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
>> b/drivers/gpu/drm/udl/udl_modeset.c
>> index cddc4fc..7dc3bd8 100644
>> --- a/drivers/gpu/drm/udl/udl_modeset.c
>> +++ b/drivers/gpu/drm/udl/udl_modeset.c
>> @@ -363,6 +363,26 @@ static void udl_crtc_destroy(struct drm_crtc *crtc)
>> kfree(crtc);
>> }
>>
>> +static int udl_crtc_page_flip(struct drm_crtc *crtc,
>> + struct drm_framebuffer *fb,
>> + struct drm_pending_vblank_event *event,
>> + uint32_t page_flip_flags)
>> +{
>> + struct udl_framebuffer *ufb = to_udl_fb(fb);
>> + struct drm_device *dev = crtc->dev;
>> + unsigned long flags;
>> +
>> + udl_handle_damage(ufb, 0, 0, fb->width, fb->height);
>> +
>> + spin_lock_irqsave(&dev->event_lock, flags);
>> + if (event)
>> + drm_send_vblank_event(dev, 0, event);
>> + spin_unlock_irqrestore(&dev->event_lock, flags);
>> + crtc->fb = fb;
>
> Doesn't this break user-space that expects page-flip events to not
> occur more often than the refresh-rate? For instance, weston
> re-renders on each page-flip event. With this patch, it will never
> sleep on udl as it immediately gets the page-flip event back?
I don't think you can update the USB device quicker than the refresh rate :-P
though that might change if we ever get USB3!
Dave.
[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support
On Tue, Jul 08, 2014 at 07:08:20PM +0200, Boris BREZILLON wrote:
> On Tue, 8 Jul 2014 11:41:32 -0400
> Rob Clark wrote:
>
> > On Tue, Jul 8, 2014 at 10:37 AM, Boris BREZILLON
> > wrote:
> > > On Tue, 8 Jul 2014 08:49:41 -0400
> > > Rob Clark wrote:
> > >
> > >> On Tue, Jul 8, 2014 at 3:23 AM, Boris BREZILLON
> > >> wrote:
> > >> > Hello Rob,
> > >> >
> > >> > On Mon, 7 Jul 2014 23:45:54 -0400
> > >> > Rob Clark wrote:
> > >> >
> > >> >> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON
> > >> >> wrote:
...
> > >> >> > +/**
> > >> >> > + * Atmel HLCDC Plane update request structure.
> > >> >> > + *
> > >> >> > + * @crtc_x: x position of the plane relative to the CRTC
> > >> >> > + * @crtc_y: y position of the plane relative to the CRTC
> > >> >> > + * @crtc_w: visible width of the plane
> > >> >> > + * @crtc_h: visible height of the plane
> > >> >> > + * @src_x: x buffer position
> > >> >> > + * @src_y: y buffer position
> > >> >> > + * @src_w: buffer width
> > >> >> > + * @src_h: buffer height
> > >> >> > + * @pixel_format: pixel format
> > >> >> > + * @gems: GEM object object containing image buffers
> > >> >> > + * @offsets: offsets to apply to the GEM buffers
> > >> >> > + * @pitches: line size in bytes
> > >> >> > + * @crtc: crtc to display on
> > >> >> > + * @finished: finished callback
> > >> >> > + * @finished_data: data passed to the finished callback
> > >> >> > + * @bpp: bytes per pixel deduced from pixel_format
> > >> >> > + * @xstride: value to add to the pixel pointer between each line
> > >> >> > + * @pstride: value to add to the pixel pointer between each pixel
> > >> >> > + * @nplanes: number of planes (deduced from pixel_format)
> > >> >> > + */
> > >> >> > +struct atmel_hlcdc_plane_update_req {
> > >> >> > + int crtc_x;
> > >> >> > + int crtc_y;
> > >> >> > + unsigned int crtc_w;
> > >> >> > + unsigned int crtc_h;
> > >> >> > + uint32_t src_x;
> > >> >> > + uint32_t src_y;
> > >> >> > + uint32_t src_w;
> > >> >> > + uint32_t src_h;
> > >> >> > + uint32_t pixel_format;
> > >> >> > + struct drm_gem_cma_object *gems[ATMEL_HLCDC_MAX_PLANES];
> > >> >> > + unsigned int offsets[ATMEL_HLCDC_MAX_PLANES];
> > >> >> > + unsigned int pitches[ATMEL_HLCDC_MAX_PLANES];
> > >> >>
> > >> >> tbh, I've only looked closely, but I don't completely follow all the
> > >> >> layering here.. I wonder if we'd be better off just moving 'struct
> > >> >> drm_fb_cma' to header file so you could get the gem objects / pixel
> > >> >> fmt / width / height directly from the fb object (and then you can
> > >> >> reference count things at the fb level, rather than at the individual
> > >> >> gem obj level, too)
> > >> >>
> > >> >
> > >> > Actually, the HW cursor is a drm_plane too, and in this case I cannot
> > >> > retrieve a drm_fb_cma object, but just a single GEM object (see
> > >> > atmel_hlcdc_crtc_cursor_set function in atmel_hlcdc_crtc.c).
> > >>
> > >> oh, right.. well maybe for the cursor case it would be possible to
> > >> wrap up the gem bo with an internally created fb? Not sure if that
> > >> ends up simplifying things or not, so it is definitely your call. But
> > >> at least my experience with other drivers (that did not use a plane as
> > >> a cursor internally) was that I could simplify things after fb gained
> > >> refcnt'ing.
> > >
> > > Unless I'm missing something, I'd say moving to fb objects instead of
> > > GEM objects won't simplify the code much (I'm already refcnt'ing GEM
> > > objects when launching a DMA transfer for a plane update).
> >
> > yeah, mostly just saves you a bit of bookkeeping. Ie. ref/unref one
> > thing instead of loop over N objects, etc. Nothing earth-shattering.
> >
>
> Okay, my bad, this is definitely simpler with fb objects (I made use of
> drm_fb_cma_create to create an fb object when cursor_set is called)
> than it was when using GEM objects.
>
> I might even be able to simplify the layer update mechanism with this
> approach.
>
> Thanks for the advice.
>
> Best Regards,
>
> Boris
Hi Boris.
I haven't really looked at any of your driver in depth, but from a quick
glance it looks like you're registering a cursor drm_plane (i.e., making
use of the new universal plane infrastructure), but you're also
providing an implementation of the legacy cursor ioctls (cursor_set and
cursor_move). There's some patches working their way through the
pipeline that should make this unnecessary and hopefully simplify your
life a bit:
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=c394c2b08e247c32ef292b75fd8b34312465f8ae
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=b36552b32aa9c69e83a3a20bda56379fb9e52435
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=161d0dc1dccb17ff7a38f462c7c0d4ef8bcc5662
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=fc1d3e44ef7c1db93384150fdbf8948dcf949f1
[PATCH 1/2] drm/nouveau/bar: add noncached ioremap property
Ping Ben, how do these two patches look like?
On Fri, Jun 27, 2014 at 7:28 PM, Alexandre Courbot
wrote:
> Some BARs (like GK20A's) do not support being ioremapped write-combined.
> Add a boolean property to the BAR structure and handle that case in the
> Nouveau BO implementation.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/nouveau/core/include/subdev/bar.h | 3 +++
> drivers/gpu/drm/nouveau/nouveau_bo.c | 17 -
> 2 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
> b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
> index 9faa98e67ad8..9002cbb6432b 100644
> --- a/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
> +++ b/drivers/gpu/drm/nouveau/core/include/subdev/bar.h
> @@ -20,6 +20,9 @@ struct nouveau_bar {
> u32 flags, struct nouveau_vma *);
> void (*unmap)(struct nouveau_bar *, struct nouveau_vma *);
> void (*flush)(struct nouveau_bar *);
> +
> + /* whether the BAR supports to be ioremapped WC or should be uncached
> */
> + bool iomap_uncached;
> };
>
> static inline struct nouveau_bar *
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index b6dc85c614be..4db886f9f793 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -500,18 +500,25 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev,
> uint32_t type,
> man->default_caching = TTM_PL_FLAG_CACHED;
> break;
> case TTM_PL_VRAM:
> + man->flags = TTM_MEMTYPE_FLAG_FIXED |
> +TTM_MEMTYPE_FLAG_MAPPABLE;
> + man->available_caching = TTM_PL_FLAG_UNCACHED |
> +TTM_PL_FLAG_WC;
> + man->default_caching = TTM_PL_FLAG_WC;
> +
> if (nv_device(drm->device)->card_type >= NV_50) {
> + /* Some BARs do not support being ioremapped WC */
> + if (nouveau_bar(drm->device)->iomap_uncached) {
> + man->available_caching = TTM_PL_FLAG_UNCACHED;
> + man->default_caching = TTM_PL_FLAG_UNCACHED;
> + }
> +
> man->func = &nouveau_vram_manager;
> man->io_reserve_fastpath = false;
> man->use_io_reserve_lru = true;
> } else {
> man->func = &ttm_bo_manager_func;
> }
> - man->flags = TTM_MEMTYPE_FLAG_FIXED |
> -TTM_MEMTYPE_FLAG_MAPPABLE;
> - man->available_caching = TTM_PL_FLAG_UNCACHED |
> -TTM_PL_FLAG_WC;
> - man->default_caching = TTM_PL_FLAG_WC;
> break;
> case TTM_PL_TT:
> if (nv_device(drm->device)->card_type >= NV_50)
> --
> 2.0.0
>
[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support
On Tue, 8 Jul 2014 08:49:41 -0400
Rob Clark wrote:
> On Tue, Jul 8, 2014 at 3:23 AM, Boris BREZILLON
> wrote:
> > Hello Rob,
> >
> > On Mon, 7 Jul 2014 23:45:54 -0400
> > Rob Clark wrote:
> >
> >> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON
> >> wrote:
> >> > The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
> >> > at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
> >> > controller device.
> >> >
> >> > This display controller supports at least one primary plane and might
> >> > provide several overlays and an hardware cursor depending on the IP
> >> > version.
> >> >
> >> > At the moment, this driver only implements an RGB connector to interface
> >> > with LCD panels, but support for other kind of external devices (like DRM
> >> > bridges) might be added later.
> >> >
> >> > Signed-off-by: Boris BREZILLON
> >> > ---
> >> > drivers/gpu/drm/Kconfig | 2 +
> >> > drivers/gpu/drm/Makefile| 1 +
> >> > drivers/gpu/drm/atmel-hlcdc/Kconfig | 11 +
> >> > drivers/gpu/drm/atmel-hlcdc/Makefile| 7 +
> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 469 +++
> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 474 +++
> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 210 +++
> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 706
> >> > +++
> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h | 422 ++
> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c | 351
> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 729
> >> >
> >> > 11 files changed, 3382 insertions(+)
> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c
> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> >> >
> >> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> >> > index d1cc2f6..df6f0c1 100644
> >> > --- a/drivers/gpu/drm/Kconfig
> >> > +++ b/drivers/gpu/drm/Kconfig
> >> > @@ -182,6 +182,8 @@ source "drivers/gpu/drm/cirrus/Kconfig"
> >
> > [...]
> >
> >> > +
> >> > +/**
> >> > + * Atmel HLCDC Plane properties.
> >> > + *
> >> > + * This structure stores plane property definitions.
> >> > + *
> >> > + * @alpha: alpha blending (or transparency) property
> >> > + * @csc: YUV to RGB conversion factors property
> >> > + */
> >> > +struct atmel_hlcdc_plane_properties {
> >> > + struct drm_property *alpha;
> >> > + struct drm_property *csc;
> >>
> >> appears like csc is not used yet, so I suppose you can drop it for
> >> now.. when you do add it, don't forget to update drm.tmp. But for
> >> now it at least makes review easier when the driver doesn't add new
> >> userspace interfaces :-)
> >
> >
> > Sure, I guess this is a leftover from another patch I made to add Color
> > Space Conversion configuration.
> >
> > I'll remove it for the next version.
> >
> >>
> >> > +};
> >> > +
> >> > +/**
> >> > + * Atmel HLCDC Plane.
> >> > + *
> >> > + * @base: base DRM plane structure
> >> > + * @layer: HLCDC layer structure
> >> > + * @properties: pointer to the property definitions structure
> >> > + * @alpha: current alpha blending (or transparency) status
> >> > + */
> >> > +struct atmel_hlcdc_plane {
> >> > + struct drm_plane base;
> >> > + struct atmel_hlcdc_layer layer;
> >> > + struct atmel_hlcdc_plane_properties *properties;
> >> > +};
> >> > +
> >> > +static inline struct atmel_hlcdc_plane *
> >> > +drm_plane_to_atmel_hlcdc_plane(struct drm_plane *p)
> >> > +{
> >> > + return container_of(p, struct atmel_hlcdc_plane, base);
> >> > +}
> >> > +
> >> > +static inline struct atmel_hlcdc_plane *
> >> > +atmel_hlcdc_layer_to_plane(struct atmel_hlcdc_layer *l)
> >> > +{
> >> > + return container_of(l, struct atmel_hlcdc_plane, layer);
> >> > +}
> >> > +
> >> > +/**
> >> > + * Atmel HLCDC Plane update request structure.
> >> > + *
> >> > + * @crtc_x: x position of the plane relative to the CRTC
> >> > + * @crtc_y: y position of the plane relative to the CRTC
> >> > + * @crtc_w: visible width of the plane
> >> > + * @crtc_h: visible height of the plane
> >> > + * @src_x: x buffer position
> >> > + * @src_y: y buffer position
> >> > + * @src_w: buffer width
> >> > + * @src_h: buffer height
> >> > + * @pixel_format: pixel format
> >> > + * @gems: GEM object object containing image buffers
> >> > + * @offsets: offs
[PATCH] drm: reduce default drm vblank off delay to 50ms
On Wed, Jul 02, 2014 at 01:42:38PM -0700, Jesse Barnes wrote: > On Wed, 2 Jul 2014 13:35:19 -0700 > St?phane Marchesin wrote: > > > On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter wrote: > > > On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes > > virtuousgeek.org> wrote: > > >> People keep whining about this, but no one seems to send a patch. This > > >> *ought* to be safe now that we've dealt with the hw races in Mario's > > >> updated code, and fixed the bugs we know about in VT switch, DPMS, and > > >> multi-head configuraions. > > >> > > >> Signed-off-by: Jesse Barnes > > > > > > Afaik the fundamental race of enabling the vblank is still there, so > > > this is just duct-tape. And our hw has the required registers (on > > > gen5+ at least) to close this race for real and abolish all "disable > > > vblank irq later to paper over races and smooth things out). Hence I > > > think we should dtrt and so > > > > [digging an old thread] > > > > So I'm looking at this machine where we can't get good PSR residency > > because the vblank_offdelay is so long. Therefore, I'm suddenly very > > interested in solving this issue :) Of course I can't seem to find > > logs of the fun IRC discussion you guys had, can you describe what the > > race is, and also what are the registers you're talking about? > > Beyond that I don't see why this obvious and simple improvement should > be blocked on some other work. Maybe it's a bit late now since Ville > may already have patches for what Daniel mentions above, but I still > find the nack to be totally misguided. > > Dave, please just pick this up so everyone can benefit while we thrash > through an i915 fix (doubtless introducing some bugs) that lets us > disable immediately. This needs an ack from Mario. And I really don't see why we _now_ need to suddenly rush then when we have patches from Ville to address this properly. The blocker is only that it's not yet reviewed but meh. And people with product ship dates looming over their head can always just apply this themselves. Us sucking at reviewing is imo no reason at all to rush patches in. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 0/9] Updated fence patch series
On Mon, Jul 07, 2014 at 10:30:52AM -0700, Greg KH wrote: > On Mon, Jul 07, 2014 at 03:23:17PM +0200, Daniel Vetter wrote: > > On Wed, Jul 2, 2014 at 7:37 AM, Greg KH > > wrote: > > >> Android can expose fences to userspace. It's possible to make the new > > >> fence > > >> mechanism expose the same fences to userspace by changing > > >> sync_fence_create > > >> to take a struct fence instead of a struct sync_pt. No other change is > > >> needed, > > >> because only the fence parts of struct sync_pt are used. But because the > > >> userspace fences are a separate problem and I haven't really looked at > > >> it yet > > >> I feel it should stay in staging, for now. > > > > > > Ok, that's reasonable. > > > > > > At first glance, this all looks "sane" to me, any objection from anyone > > > if I merge this through my driver-core tree for 3.17? > > > > Ack from my side fwiw. > > Thanks, I'll queue it up later today. btw should we add you as a (co)maintainer for driver/core/dma-buf since you seem to want to keep a closer tab on what the insane gfx folks are up to in there? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/3] gpu: drm: Remove unnecessary parameter from drm_ht_remove_item()
On Tue, Jul 08, 2014 at 01:40:44PM +0200, Thomas Hellstrom wrote: > On 07/08/2014 01:24 PM, Daniel Vetter wrote: > > On Tue, Jun 24, 2014 at 10:52:13PM +0100, Masaru Nomura wrote: > >> removed drm_open_hash from drm_ht_remove_item() as the parameter is > >> not used within the function. > >> > >> Signed-off-by: Masaru Nomura > >> --- > >> Please review this patch carefully. The reason the parameter is passed > >> might be some historical one or clarity of which drm_open_hash > >> we remove an item from. > > Reasons for this are probably lost. On the patch: > > > > Reviewed-by: Daniel Vetter > > Acked-by: Thomas Hellstrom > > > > > Aside: Imo we could/should just move all the users to directly employ the > > linux hashtab instead of partially reinventing the wheel here in drm. > > -Daniel > > > > Actually, in this case, the wheel was invented in drm before it was made > generic :). > It's possible to utilize part of "hashtable.h" but I don't think the > code size gain > will be major... Yeah, lots of work and little gain ;-) There needs to be a terribly boring and rainy day to get around to that ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/plane-helper: Use proper plane init function
On Mon, Jun 30, 2014 at 03:37:51PM -0700, Matt Roper wrote:
> drm_plane_init() (the legacy plane initialization function) takes a bool
> as its final parameter; originally this indicated whether a plane was
> 'private' to the driver (before the DRM core understood non-overlay
> planes), now it indicates whether the plane is a primary plane (private
> planes were used by some drivers to represent primary planes
> internally). The newer drm_universal_plane_init() take an 'enum
> drm_plane_type' as its final parameter to allow the caller to specify
> the specific plane type desired (primary, cursor, or overlay).
>
> Due to a rebasing mistake, the primary plane helper is currently passing
> DRM_PLANE_TYPE_PRIMARY (enum value = 1) for drm_plane_init()'s boolean
> 'is_primary' parameter. This winds up giving the correct behavior since
> DRM_PLANE_TYPE_PRIMARY evaluates as true, but is confusing to anyone
> reading the code since we're passing an enum value (one of three
> possible values) for a boolean parameter.
>
> Replace the primary plane helper's call to drm_plane_init() with
> drm_universal_plane_init() so that the parameter and value types match
> up as expected.
>
> Signed-off-by: Matt Roper
Applied to topic/core-stuff.
-Daniel
> ---
> drivers/gpu/drm/drm_plane_helper.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c
> index 6d13314..827ec1a 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -335,9 +335,10 @@ struct drm_plane *drm_primary_helper_create_plane(struct
> drm_device *dev,
> }
>
> /* possible_crtc's will be filled in later by crtc_init */
> - ret = drm_plane_init(dev, primary, 0, &drm_primary_helper_funcs,
> - formats, num_formats,
> - DRM_PLANE_TYPE_PRIMARY);
> + ret = drm_universal_plane_init(dev, primary, 0,
> +&drm_primary_helper_funcs,
> +formats, num_formats,
> +DRM_PLANE_TYPE_PRIMARY);
> if (ret) {
> kfree(primary);
> primary = NULL;
> --
> 1.8.5.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] exynos: Put a stop to the userptr heresy.
On Wed, Jul 02, 2014 at 11:25:19AM -0400, Jerome Glisse wrote: > Anyway as this is upstream i guess you can keep it. This is just an horrible > API that allow to circumvant any limit set by memcg for page locking and all. > But anyway GPU driver never played in the same ballpark as other driver. I agree that exynos userptr as-is should be removed since as opposed to the i915 implementation it doesn't play nice with the core mm and allos unpriviledged userspace to exceed all mlock limits. I've taken considerable amounts of internal heat for rejecting i915 userptr until the mmu notifier stuff was implemented and so really want exynos to fix this up asap. Dave? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] i915: purify user ptr ioctl through the fire of truth.
On Mon, Jun 30, 2014 at 02:23:32PM -0400, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> Heresy should not be tolerated, any ioctl that rely on pure luck
> should die. Violating memory pining kernel policy and all the
> reasonable expection kernel have about user of mmu_notifier api
> is not tolerable.
>
> Because we can neither broke old userspace the ioctl is left but
> i will never succeed which is the only reliable option for it.
>
> Signed-off-by: J?r?me Glisse
As per the irc discussions I've had with Glisse I'll stick with i915
userptr. A few key points:
- userptr is really only valid for X shem and malloced memory. It's very
far away from real shared address space (iirc called hmm by amd/nvidia)
and doesn't make any guarantees when userspace remaps memory
(mmap/unmap) or forks (i.e. cow maps). In that sense userptr is an
evolutionary dead-end, but still rather useful.
- The only reason we have the mmu notifier is to be able to
opportunistically pin memory with without hitting mlock limits. For that
we need to play nice with page migration and swap-out, which our mmu
notifier callback allows. If there's a race there's no harm done since
both swap-out and page migration either retry or move to victimize
another suitable page. Of coures real shared virtual memory would need a
rather different mmu notifier implementation (and hw support) to close
all the races, but userptr is explicitly not that powerful. If you cow
or remap you get to keep all the pieces.
Hence the mmu notifier is really just to be able to keep the page pinned
after the batch completes instead of dropping the pinning again like AIO
does after a transaction completes.
- Hence we only need correctness wrt swap-out/page-migration. The page
references obtained by gup guarantees that without the mmu notifier
stuff. That's the same guarantees as aio and friends rely on, so we
should be safe (at least for now).
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h | 15 -
> drivers/gpu/drm/i915/i915_gem.c | 1 -
> drivers/gpu/drm/i915/i915_gem_userptr.c | 687
> +---
> drivers/gpu/drm/i915/i915_gpu_error.c | 2 -
> 4 files changed, 5 insertions(+), 700 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8cea596..3970bd0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -393,7 +393,6 @@ struct drm_i915_error_state {
> u32 tiling:2;
> u32 dirty:1;
> u32 purgeable:1;
> - u32 userptr:1;
> s32 ring:4;
> u32 cache_level:3;
> } **active_bo, **pinned_bo;
> @@ -1750,19 +1749,6 @@ struct drm_i915_gem_object {
>
> /** for phy allocated objects */
> drm_dma_handle_t *phys_handle;
> -
> - union {
> - struct i915_gem_userptr {
> - uintptr_t ptr;
> - unsigned read_only :1;
> - unsigned workers :4;
> -#define I915_GEM_USERPTR_MAX_WORKERS 15
> -
> - struct mm_struct *mm;
> - struct i915_mmu_object *mn;
> - struct work_struct *work;
> - } userptr;
> - };
> };
> #define to_intel_bo(x) container_of(x, struct drm_i915_gem_object, base)
>
> @@ -2195,7 +2181,6 @@ int i915_gem_set_tiling(struct drm_device *dev, void
> *data,
> struct drm_file *file_priv);
> int i915_gem_get_tiling(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
> -int i915_gem_init_userptr(struct drm_device *dev);
> int i915_gem_userptr_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file);
> int i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f6d1238..30fc784 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4754,7 +4754,6 @@ int i915_gem_init(struct drm_device *dev)
> DRM_DEBUG_DRIVER("allow wake ack timed out\n");
> }
>
> - i915_gem_init_userptr(dev);
> i915_gem_init_global_gtt(dev);
>
> ret = i915_gem_context_init(dev);
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 191ac71..f261cb9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -22,692 +22,15 @@
> *
> */
>
> -#include "drmP.h"
> #include "i915_drm.h"
> #include "i915_drv.h"
> -#include "i915_trace.h"
> #include "intel_drv.h"
> -#include
> -#include
> -#include
> -#include
>
> -#if defined(CONFIG_MMU_NOTIFIER)
> -#include
> -
> -struct i915_mmu_notifier {
> - spinlock_t lock;
> - struct hlist_node node;
> - struct mmu_notifier mn;
> - struct rb_r
[RFC] drm/exynos: abort commit when framebuffer is removed from plane
Hi Inki,
What do you think about the following fix? I need your inputs for this.
Regards,
Rahul Sharma
On 19 June 2014 20:43, Rahul Sharma wrote:
> This situation arises when userspace remove the frambuffer object
> and call setmode ioctl.
>
> drm_mode_rmfb --> drm_plane_force_disable --> plane->crtc = NULL;
> and
> drm_mode_setcrtc --> exynos_plane_commit --> passes plane->crtc to
> exynos_drm_crtc_plane_commit which is NULL.
>
> This crashes the system.
>
> Signed-off-by: Rahul Sharma
> ---
> This works fine but I am not confident on the correctness of the
> solution.
>
> drivers/gpu/drm/exynos/exynos_drm_crtc.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 95c9435..da4efe4 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -165,6 +165,12 @@ static int exynos_drm_crtc_mode_set_commit(struct
> drm_crtc *crtc, int x, int y,
> return -EPERM;
> }
>
> + /* when framebuffer is removed, commit should not proceed. */
> + if(!plane->fb){
> + DRM_ERROR("framebuffer has been removed from plane.\n");
> + return -EFAULT;
> + }
> +
> crtc_w = crtc->primary->fb->width - x;
> crtc_h = crtc->primary->fb->height - y;
>
> --
> 1.7.9.5
>
[Bug 78661] GPU sometimes locks up after boot and/or resume
https://bugzilla.kernel.org/show_bug.cgi?id=78661 --- Comment #9 from Alex Deucher --- This might be related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=76998 Can you try this patch: https://bugs.freedesktop.org/attachment.cgi?id=102392 -- You are receiving this mail because: You are watching the assignee of the bug.
mixer_check_mode drops Exynos5 display modes
Hi Sean, While looking at the following commit I noticed something: commit f041b257a8997c8472a1013e9f252c3e2a1d879e Author: Sean Paul Date: Thu Jan 30 16:19:15 2014 -0500 drm/exynos: Remove exynos_drm_hdmi shim This commit changes how mixer_check_mode() is used. It used to just exclude certain modes on old mixer versions, but now it seems to be called unconditionally, for all mixer versions. I guess the effect here is that some modes on exynos5 setups are dropped whereas they weren't before. Is that intentional? Thanks Daniel
[Bug 78661] GPU sometimes locks up after boot and/or resume
https://bugzilla.kernel.org/show_bug.cgi?id=78661 --- Comment #8 from Nikolaus Waxweiler --- Speaking of hangs, every once in a while I get lockups on boot where the screen stays corrupted or black and even the reset button doesn't help and I have to long-press the power button. Theres no log for those hangs so I don't know if they're related to this bug. Anything I can do to further analyze these hangs? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 0/9] Updated fence patch series
On Wed, Jul 02, 2014 at 11:12:32AM +0200, Maarten Lankhorst wrote: > op 02-07-14 07:37, Greg KH schreef: > > On Tue, Jul 01, 2014 at 12:57:02PM +0200, Maarten Lankhorst wrote: > >> So after some more hacking I've moved dma-buf to its own subdirectory, > >> drivers/dma-buf and applied the fence patches to its new place. I believe > >> that the > >> first patch should be applied regardless, and the rest should be ready now. > >> :-) > >> > >> Changes to the fence api: > >> - release_fence -> fence_release etc. > >> - __fence_init -> fence_init > >> - __fence_signal -> fence_signal_locked > >> - __fence_is_signaled -> fence_is_signaled_locked > >> - Changing BUG_ON to WARN_ON in fence_later, and return NULL if it > >> triggers. > >> > >> Android can expose fences to userspace. It's possible to make the new fence > >> mechanism expose the same fences to userspace by changing sync_fence_create > >> to take a struct fence instead of a struct sync_pt. No other change is > >> needed, > >> because only the fence parts of struct sync_pt are used. But because the > >> userspace fences are a separate problem and I haven't really looked at it > >> yet > >> I feel it should stay in staging, for now. > > Ok, that's reasonable. > > > > At first glance, this all looks "sane" to me, any objection from anyone > > if I merge this through my driver-core tree for 3.17? > > > Sounds good to me, let me know when you pull it in, so I can rebase my > drm conversion on top of it. :-) All are now queued up and in my driver-core tree in the driver-core-next branch, you should have gotten the emails about it. thanks, greg k-h
[PATCH 2/3] gpu: drm: Remove unnecessary parameter from drm_ht_remove_item()
On 07/08/2014 01:24 PM, Daniel Vetter wrote: > On Tue, Jun 24, 2014 at 10:52:13PM +0100, Masaru Nomura wrote: >> removed drm_open_hash from drm_ht_remove_item() as the parameter is >> not used within the function. >> >> Signed-off-by: Masaru Nomura >> --- >> Please review this patch carefully. The reason the parameter is passed >> might be some historical one or clarity of which drm_open_hash >> we remove an item from. > Reasons for this are probably lost. On the patch: > > Reviewed-by: Daniel Vetter Acked-by: Thomas Hellstrom > > Aside: Imo we could/should just move all the users to directly employ the > linux hashtab instead of partially reinventing the wheel here in drm. > -Daniel > Actually, in this case, the wheel was invented in drm before it was made generic :). It's possible to utilize part of "hashtable.h" but I don't think the code size gain will be major... /Thomas
[PATCH] drm: Fix function names in kerneldoc
On Thu, Jun 26, 2014 at 09:37:20PM +0200, Thierry Reding wrote: > From: Thierry Reding > > The drm_property_create_enum(), drm_property_create_bitmask() and > drm_property_create_range() contain the wrong name in the kerneldoc > comment. This is probably simply a copy/paste mistake. > > Signed-off-by: Thierry Reding Applied to topic/core-stuff. -Daniel > --- > drivers/gpu/drm/drm_crtc.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 684ad81baa3c..cbeb23499552 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -3329,7 +3329,7 @@ fail: > EXPORT_SYMBOL(drm_property_create); > > /** > - * drm_property_create - create a new enumeration property type > + * drm_property_create_enum - create a new enumeration property type > * @dev: drm device > * @flags: flags specifying the property type > * @name: name of the property > @@ -3375,7 +3375,7 @@ struct drm_property *drm_property_create_enum(struct > drm_device *dev, int flags, > EXPORT_SYMBOL(drm_property_create_enum); > > /** > - * drm_property_create - create a new bitmask property type > + * drm_property_create_bitmask - create a new bitmask property type > * @dev: drm device > * @flags: flags specifying the property type > * @name: name of the property > @@ -3437,7 +3437,7 @@ static struct drm_property > *property_create_range(struct drm_device *dev, > } > > /** > - * drm_property_create - create a new ranged property type > + * drm_property_create_range - create a new ranged property type > * @dev: drm device > * @flags: flags specifying the property type > * @name: name of the property > -- > 2.0.0 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 2/3] gpu: drm: Remove unnecessary parameter from drm_ht_remove_item()
On Tue, Jun 24, 2014 at 10:52:13PM +0100, Masaru Nomura wrote:
> removed drm_open_hash from drm_ht_remove_item() as the parameter is
> not used within the function.
>
> Signed-off-by: Masaru Nomura
> ---
> Please review this patch carefully. The reason the parameter is passed
> might be some historical one or clarity of which drm_open_hash
> we remove an item from.
Reasons for this are probably lost. On the patch:
Reviewed-by: Daniel Vetter
Aside: Imo we could/should just move all the users to directly employ the
linux hashtab instead of partially reinventing the wheel here in drm.
-Daniel
>
> drivers/gpu/drm/drm_auth.c | 2 +-
> drivers/gpu/drm/drm_hashtab.c | 2 +-
> drivers/gpu/drm/drm_stub.c | 2 +-
> drivers/gpu/drm/ttm/ttm_object.c| 8 +++-
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 4 ++--
> include/drm/drm_hashtab.h | 2 +-
> 7 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index 3cedae1..f7ceea0 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -115,7 +115,7 @@ int drm_remove_magic(struct drm_master *master,
> drm_magic_t magic)
> return -EINVAL;
> }
> pt = drm_hash_entry(hash, struct drm_magic_entry, hash_item);
> - drm_ht_remove_item(&master->magiclist, hash);
> + drm_ht_remove_item(hash);
> list_del(&pt->head);
> mutex_unlock(&dev->struct_mutex);
>
> diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
> index c3b80fd..a66447f 100644
> --- a/drivers/gpu/drm/drm_hashtab.c
> +++ b/drivers/gpu/drm/drm_hashtab.c
> @@ -188,7 +188,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned
> long key)
> return -EINVAL;
> }
>
> -int drm_ht_remove_item(struct drm_open_hash *ht, struct drm_hash_item *item)
> +int drm_ht_remove_item(struct drm_hash_item *item)
> {
> hlist_del_init_rcu(&item->head);
> return 0;
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index 14d1646..6ffed45 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -166,7 +166,7 @@ static void drm_master_destroy(struct kref *kref)
>
> list_for_each_entry_safe(pt, next, &master->magicfree, head) {
> list_del(&pt->head);
> - drm_ht_remove_item(&master->magiclist, &pt->hash_item);
> + drm_ht_remove_item(&pt->hash_item);
> kfree(pt);
> }
>
> diff --git a/drivers/gpu/drm/ttm/ttm_object.c
> b/drivers/gpu/drm/ttm/ttm_object.c
> index d2a0533..42f73a8 100644
> --- a/drivers/gpu/drm/ttm/ttm_object.c
> +++ b/drivers/gpu/drm/ttm/ttm_object.c
> @@ -188,7 +188,7 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
> return 0;
> out_err1:
> spin_lock(&tdev->object_lock);
> - (void)drm_ht_remove_item_rcu(&tdev->object_hash, &base->hash);
> + drm_ht_remove_item_rcu(&base->hash);
> spin_unlock(&tdev->object_lock);
> out_err0:
> return ret;
> @@ -202,7 +202,7 @@ static void ttm_release_base(struct kref *kref)
> struct ttm_object_device *tdev = base->tfile->tdev;
>
> spin_lock(&tdev->object_lock);
> - (void)drm_ht_remove_item_rcu(&tdev->object_hash, &base->hash);
> + drm_ht_remove_item_rcu(&base->hash);
> spin_unlock(&tdev->object_lock);
>
> /*
> @@ -390,11 +390,9 @@ static void ttm_ref_object_release(struct kref *kref)
> container_of(kref, struct ttm_ref_object, kref);
> struct ttm_base_object *base = ref->obj;
> struct ttm_object_file *tfile = ref->tfile;
> - struct drm_open_hash *ht;
> struct ttm_mem_global *mem_glob = tfile->tdev->mem_glob;
>
> - ht = &tfile->ref_hash[ref->ref_type];
> - (void)drm_ht_remove_item_rcu(ht, &ref->hash);
> + drm_ht_remove_item_rcu(&ref->hash);
> list_del(&ref->head);
> spin_unlock(&tfile->lock);
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 87df0b3..1780f5e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -2185,13 +2185,13 @@ static void vmw_clear_validations(struct
> vmw_sw_context *sw_context)
>base.head) {
> list_del(&entry->base.head);
> ttm_bo_unref(&entry->base.bo);
> - (void) drm_ht_remove_item(&sw_context->res_ht, &entry->hash);
> + drm_ht_remove_item(&entry->hash);
> sw_context->cur_val_buf--;
> }
> BUG_ON(sw_context->cur_val_buf != 0);
>
> list_for_each_entry(val, &sw_context->resource_list, head)
> - (void) drm_ht_remove_item(&sw_context->res_ht, &val->hash);
> + drm_ht_remove_item(&val->hash);
> }
>
> static int vmw_validate_single_buffer(struct vmw_private *dev_priv,
>
[PATCH 06/22] i810: Use pci_zalloc_consistent
On Mon, Jun 23, 2014 at 06:41:34AM -0700, Joe Perches wrote:
> Remove the now unnecessary memset too.
>
> Signed-off-by: Joe Perches
Since I seem to be the last idiot to have touched i810.ko:
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/i810/i810_dma.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
> index e88bac1..bae897d 100644
> --- a/drivers/gpu/drm/i810/i810_dma.c
> +++ b/drivers/gpu/drm/i810/i810_dma.c
> @@ -393,15 +393,14 @@ static int i810_dma_initialize(struct drm_device *dev,
>
> /* Program Hardware Status Page */
> dev_priv->hw_status_page =
> - pci_alloc_consistent(dev->pdev, PAGE_SIZE,
> - &dev_priv->dma_status_page);
> + pci_zalloc_consistent(dev->pdev, PAGE_SIZE,
> + &dev_priv->dma_status_page);
> if (!dev_priv->hw_status_page) {
> dev->dev_private = (void *)dev_priv;
> i810_dma_cleanup(dev);
> DRM_ERROR("Can not allocate hardware status page\n");
> return -ENOMEM;
> }
> - memset(dev_priv->hw_status_page, 0, PAGE_SIZE);
> DRM_DEBUG("hw status page @ %p\n", dev_priv->hw_status_page);
>
> I810_WRITE(0x02080, dev_priv->dma_status_page);
> --
> 1.8.1.2.459.gbcd45b4.dirty
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 81045] New: [r600] Unreal Engine 4 demo crashed kernel
https://bugs.freedesktop.org/show_bug.cgi?id=81045 Priority: medium Bug ID: 81045 Assignee: dri-devel at lists.freedesktop.org Summary: [r600] Unreal Engine 4 demo crashed kernel Severity: major Classification: Unclassified OS: Linux (All) Reporter: nikoli at gmx.us Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 102434 --> https://bugs.freedesktop.org/attachment.cgi?id=102434&action=edit kernel messages Tried running Unreal Engine 4 demos from https://wiki.unrealengine.com/Linux_Demos 'Mobile Temple Demo' started, worked bad (image was too dark, possible to see almost nothing), but did not crash anything. Next tried 'Effects Cave Demo': in a few seconds after first start of demo X server became not responding (not even possible to switch with ctrl+alt+f1), it was flickering between grey fill and normal desktop (seems kernel tried to restart GPU), then system became fully unresponsive: ssh did not work, power button did not send system to suspend. Attached kernel messages saved by syslog. I never had GPU related stability problems with 3.12.x-3.14.x kernels before: several opengl 3d games worked fine, opengl based mpv video output worked fine, glxgears and stellarium worked fine too. Did unreal engine try to use some non implemented or unstable features? Why kernel allowed to crash itself instead of killing userspace app? Hardware: Radeon HD 6770 Software: Gentoo hardened amd64 stable, kernel-3.14.10, libdrm-2.4.54, mesa-10.2.2, llvm-3.3, xf86-video-ati-7.3.0, xorg-server-1.15.0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140708/609cc8c1/attachment.html>
[PATCH/RESEND 0/9] drm: tilcdc driver fixes
On Sat, Jun 28, 2014 at 06:51:15AM -0400, Rob Clark wrote: > On Fri, Jun 27, 2014 at 6:08 PM, Darren Etheridge > wrote: > > Guido, > > > > > > On 06/17/2014 09:17 AM, Guido Mart?nez wrote: > >> > >> The tilcdc driver could be compiled as a module, but was severely broken > >> and could not be used as such. This patchset attempts to fix the issues > >> preventing a proper load/unload of the module. > >> > >> Issues included dangling sysfs nodes, dangling devices, memory leaks and > >> a double kfree. > >> > >> It now seems to be working ok. We have tested this by loading and > >> unloading the driver repeteadly, with both panel and slave connectors > >> and found no flaws. > >> > >> There is still one warning left on tilcdc_crtc_destroy, caused by > >> destroying the connector while still in an ON status. We don't know why > >> this happens or why it's an issue, so we did not fix it. > >> > > > > Yes I see what you mean, it triggers the WARN_ON in tilcdc_crtc_destroy > > because DRM_MODE_DPMS_ON is still set. This WARN_ON does make some sense > > because DPMS_OFF would have the effect of turning off clocks and putting the > > monitor to sleep which seems logical considering we have torn down the > > display. Adding a tilcdc_crtc_dpms(DPMS_OFF) right before the WARN_ON > > confirms this, but it seems strange that this hasn't happened automatically > > (+ Russell doesn't need to do it in his Armada driver) - so I suspect there > > is a better way. > > tbh, I'm not entirely sure offhand why drm_mode_config_cleanup() > doesn't remove the fb's first (which should have the effect of > shutting down any lit crtc/encoder/connector).. that would seem like > the sensible way to shut down.. All userspace fbs should be cleared already before going into the driver unload. Which only leaves you with driver internal fbs (usually just one for fbdev emulation). It's the driver's job to clean that up explicitly. Then you can call mode_config_cleanup and the WARN_ON in there is a really nice space leak check. If we'd unconditionally clean up all fbs we'd have trouble with driver-private embedded fbs and their refcounting and would loose the space leak check. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[RFCv2] drm/msm: DT support for 8960/8064
Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
add necessary DT support so that we can use drm/msm on upstream kernel.
Signed-off-by: Rob Clark
---
I thought I sent this already, but looks like I've forgot.
I've updated the names for the GPIO properties (and, via helper, made
driver check both with and without -gpio suffix). Added clock-names,
etc.
For now I've removed the compatible string for 8074 hdmi phy. Due to
integration differences between mdp4 and mdp5 devices, it may end up
being easier to document the bindings separately (even though most of
the code is in common). When paired with mdp5 display controller, for
example, the HDMI block does not have it's own irq.
Documentation/devicetree/bindings/drm/msm/gpu.txt | 52 +
Documentation/devicetree/bindings/drm/msm/hdmi.txt | 46 +++
Documentation/devicetree/bindings/drm/msm/mdp.txt | 48 +++
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 68 ++
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 10 +++-
drivers/gpu/drm/msm/msm_drv.c | 29 +++--
7 files changed, 225 insertions(+), 30 deletions(-)
create mode 100644 Documentation/devicetree/bindings/drm/msm/gpu.txt
create mode 100644 Documentation/devicetree/bindings/drm/msm/hdmi.txt
create mode 100644 Documentation/devicetree/bindings/drm/msm/mdp.txt
diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt
b/Documentation/devicetree/bindings/drm/msm/gpu.txt
new file mode 100644
index 000..67d0a58
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/msm/gpu.txt
@@ -0,0 +1,52 @@
+Qualcomm adreno/snapdragon GPU
+
+Required properties:
+- compatible: "qcom,adreno-3xx"
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The interrupt signal from the gpu.
+- clocks: device clocks
+ See ../clocks/clock-bindings.txt for details.
+- clock-names: the following clocks are required:
+ * "core_clk"
+ * "iface_clk"
+ * "mem_iface_clk"
+- qcom,chipid: gpu chip-id. Note this may become optional for future
+ devices if we can reliably read the chipid from hw
+- qcom,gpu-pwrlevels: list of operating points
+ - compatible: "qcom,gpu-pwrlevels"
+ - for each qcom,gpu-pwrlevel:
+- qcom,gpu-freq: requested gpu clock speed
+- NOTE: downstream android driver defines additional parameters to
+ configure memory bandwidth scaling per OPP.
+
+Example:
+
+/ {
+ ...
+
+ gpu: qcom,kgsl-3d0 at 430 {
+ compatible = "qcom,adreno-3xx";
+ reg = <0x0430 0x2>;
+ reg-names = "kgsl_3d0_reg_memory";
+ interrupts = ;
+ interrupt-names = "kgsl_3d0_irq";
+ clock-names =
+ "core_clk",
+ "iface_clk",
+ "mem_iface_clk";
+ clocks =
+ <&mmcc GFX3D_CLK>,
+ <&mmcc GFX3D_AHB_CLK>,
+ <&mmcc MMSS_IMEM_AHB_CLK>;
+ qcom,chipid = <0x03020100>;
+ qcom,gpu-pwrlevels {
+ compatible = "qcom,gpu-pwrlevels";
+ qcom,gpu-pwrlevel at 0 {
+ qcom,gpu-freq = <45000>;
+ };
+ qcom,gpu-pwrlevel at 1 {
+ qcom,gpu-freq = <2700>;
+ };
+ };
+ };
+};
diff --git a/Documentation/devicetree/bindings/drm/msm/hdmi.txt
b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
new file mode 100644
index 000..aca917f
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
@@ -0,0 +1,46 @@
+Qualcomm adreno/snapdragon hdmi output
+
+Required properties:
+- compatible: one of the following
+ * "qcom,hdmi-tx-8660"
+ * "qcom,hdmi-tx-8960"
+- reg: Physical base address and length of the controller's registers
+- reg-names: "core_physical"
+- interrupts: The interrupt signal from the hdmi block.
+- clocks: device clocks
+ See ../clocks/clock-bindings.txt for details.
+- qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin
+- qcom,hdmi-tx-ddc-data-gpio: ddc data pin
+- qcom,hdmi-tx-hpd-gpio: hpd pin
+- core-vdda-supply: phandle to supply regulator
+- hdmi-mux-supply: phandle to mux regulator
+
+Optional properties:
+- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
+- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin
+
+Example:
+
+/ {
+ ...
+
+ hdmi: qcom,hdmi-tx-8960 at 4a0 {
+ compatible = "qcom,hdmi-tx-8960";
+ reg-names = "core_physical";
+ reg = <0x04a0 0x1000>;
+ interrupts = ;
+ clock-names =
+ "core_clk",
+ "master_iface_clk",
+ "slave_iface_clk";
+ clocks =
+ <&mmcc HDMI_APP_CLK>,
+ <&
[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support
On Tue, Jul 8, 2014 at 10:37 AM, Boris BREZILLON
wrote:
> On Tue, 8 Jul 2014 08:49:41 -0400
> Rob Clark wrote:
>
>> On Tue, Jul 8, 2014 at 3:23 AM, Boris BREZILLON
>> wrote:
>> > Hello Rob,
>> >
>> > On Mon, 7 Jul 2014 23:45:54 -0400
>> > Rob Clark wrote:
>> >
>> >> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON
>> >> wrote:
>> >> > The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
>> >> > at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
>> >> > controller device.
>> >> >
>> >> > This display controller supports at least one primary plane and might
>> >> > provide several overlays and an hardware cursor depending on the IP
>> >> > version.
>> >> >
>> >> > At the moment, this driver only implements an RGB connector to interface
>> >> > with LCD panels, but support for other kind of external devices (like
>> >> > DRM
>> >> > bridges) might be added later.
>> >> >
>> >> > Signed-off-by: Boris BREZILLON
>> >> > ---
>> >> > drivers/gpu/drm/Kconfig | 2 +
>> >> > drivers/gpu/drm/Makefile| 1 +
>> >> > drivers/gpu/drm/atmel-hlcdc/Kconfig | 11 +
>> >> > drivers/gpu/drm/atmel-hlcdc/Makefile| 7 +
>> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 469 +++
>> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 474 +++
>> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 210 +++
>> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 706
>> >> > +++
>> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h | 422 ++
>> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c | 351
>> >> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 729
>> >> >
>> >> > 11 files changed, 3382 insertions(+)
>> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
>> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
>> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
>> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
>> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c
>> >> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> >> >
>> >> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> >> > index d1cc2f6..df6f0c1 100644
>> >> > --- a/drivers/gpu/drm/Kconfig
>> >> > +++ b/drivers/gpu/drm/Kconfig
>> >> > @@ -182,6 +182,8 @@ source "drivers/gpu/drm/cirrus/Kconfig"
>> >
>> > [...]
>> >
>> >> > +
>> >> > +/**
>> >> > + * Atmel HLCDC Plane properties.
>> >> > + *
>> >> > + * This structure stores plane property definitions.
>> >> > + *
>> >> > + * @alpha: alpha blending (or transparency) property
>> >> > + * @csc: YUV to RGB conversion factors property
>> >> > + */
>> >> > +struct atmel_hlcdc_plane_properties {
>> >> > + struct drm_property *alpha;
>> >> > + struct drm_property *csc;
>> >>
>> >> appears like csc is not used yet, so I suppose you can drop it for
>> >> now.. when you do add it, don't forget to update drm.tmp. But for
>> >> now it at least makes review easier when the driver doesn't add new
>> >> userspace interfaces :-)
>> >
>> >
>> > Sure, I guess this is a leftover from another patch I made to add Color
>> > Space Conversion configuration.
>> >
>> > I'll remove it for the next version.
>> >
>> >>
>> >> > +};
>> >> > +
>> >> > +/**
>> >> > + * Atmel HLCDC Plane.
>> >> > + *
>> >> > + * @base: base DRM plane structure
>> >> > + * @layer: HLCDC layer structure
>> >> > + * @properties: pointer to the property definitions structure
>> >> > + * @alpha: current alpha blending (or transparency) status
>> >> > + */
>> >> > +struct atmel_hlcdc_plane {
>> >> > + struct drm_plane base;
>> >> > + struct atmel_hlcdc_layer layer;
>> >> > + struct atmel_hlcdc_plane_properties *properties;
>> >> > +};
>> >> > +
>> >> > +static inline struct atmel_hlcdc_plane *
>> >> > +drm_plane_to_atmel_hlcdc_plane(struct drm_plane *p)
>> >> > +{
>> >> > + return container_of(p, struct atmel_hlcdc_plane, base);
>> >> > +}
>> >> > +
>> >> > +static inline struct atmel_hlcdc_plane *
>> >> > +atmel_hlcdc_layer_to_plane(struct atmel_hlcdc_layer *l)
>> >> > +{
>> >> > + return container_of(l, struct atmel_hlcdc_plane, layer);
>> >> > +}
>> >> > +
>> >> > +/**
>> >> > + * Atmel HLCDC Plane update request structure.
>> >> > + *
>> >> > + * @crtc_x: x position of the plane relative to the CRTC
>> >> > + * @crtc_y: y position of the plane relative to the CRTC
>> >> > + * @crtc_w: visible width of the plane
>> >> > + * @crtc_h: visible height of the plane
>> >> > + * @src_x: x buffer position
>> >> > + * @src_y: y buffer position
>>
[PATCH v3] ASoC: tda998x: add a codec to the HDMI transmitter
This patch adds a CODEC function to the NXP TDA998x HDMI transmitter.
The CODEC handles both I2S and S/PDIF input and does dynamic input
switch in the TDA998x I2C driver on start/stop audio streaming.
Signed-off-by: Jean-Francois Moine
---
v3: fix bad rate (Andrew Jackson)
v2: check double stream start (Mark Brown)
---
.../devicetree/bindings/drm/i2c/tda998x.txt| 13 ++
drivers/gpu/drm/i2c/Makefile | 2 +-
drivers/gpu/drm/i2c/tda998x_codec.c| 247 +
drivers/gpu/drm/i2c/tda998x_drv.c | 74 --
drivers/gpu/drm/i2c/tda998x_drv.h | 32 +++
include/drm/i2c/tda998x.h | 1 +
6 files changed, 348 insertions(+), 21 deletions(-)
create mode 100644 drivers/gpu/drm/i2c/tda998x_codec.c
create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.h
diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index d7df01c..7ce4eac 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -15,6 +15,15 @@ Optional properties:
- video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: <0x230145>
+ - audio-ports: one or two values corresponding to entries in
+ the audio-port-names property.
+
+ - audio-port-names: must contain "i2s", "spdif" entries
+ matching entries in the audio-ports property.
+
+ - #sound-dai-cells: must be set to <1> for use with the simple-card.
+ The DAI 0 is the I2S input and the DAI 1 is the S/PDIF input.
+
Example:
tda998x: hdmi-encoder {
@@ -24,4 +33,8 @@ Example:
interrupts = <27 2>;/* falling edge */
pinctrl-0 = <&pmx_camera>;
pinctrl-names = "default";
+
+ audio-ports = <0x03>, <0x04>;
+ audio-port-names = "i2s", "spdif";
+ #sound-dai-cells = <1>;
};
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 43aa33b..f2d625c 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -6,5 +6,5 @@ obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o
sil164-y := sil164_drv.o
obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
-tda998x-y := tda998x_drv.o
+tda998x-y := tda998x_drv.o tda998x_codec.o
obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
diff --git a/drivers/gpu/drm/i2c/tda998x_codec.c
b/drivers/gpu/drm/i2c/tda998x_codec.c
new file mode 100644
index 000..e22f974
--- /dev/null
+++ b/drivers/gpu/drm/i2c/tda998x_codec.c
@@ -0,0 +1,247 @@
+/*
+ * ALSA SoC TDA998X CODEC
+ *
+ * Copyright (C) 2014 Jean-Francois Moine
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tda998x_drv.h"
+
+#define TDA998X_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | \
+ SNDRV_PCM_FMTBIT_S20_3LE | \
+ SNDRV_PCM_FMTBIT_S24_LE | \
+ SNDRV_PCM_FMTBIT_S32_LE)
+
+static int tda_startup(struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct tda998x_priv *priv = snd_soc_codec_get_drvdata(dai->codec);
+ u8 *eld = priv->eld;
+ struct snd_pcm_runtime *runtime = substream->runtime;
+ u8 *sad;
+ int sad_count;
+ unsigned eld_ver, mnl, rate_mask;
+ unsigned max_channels, fmt;
+ u64 formats;
+ struct snd_pcm_hw_constraint_list *rate_constraints =
+ &priv->rate_constraints;
+ static const u32 hdmi_rates[] = {
+ 32000, 44100, 48000, 88200, 96000, 176400, 192000
+ };
+
+ /* check if streaming is already active */
+ if (priv->dai_id != AFMT_NO_AUDIO)
+ return -EBUSY;
+ priv->dai_id = dai->id;
+
+ if (!eld)
+ return 0;
+
+ /* adjust the hw params from the ELD (EDID) */
+ eld_ver = eld[0] >> 3;
+ if (eld_ver != 2 && eld_ver != 31)
+ return 0;
+
+ mnl = eld[4] & 0x1f;
+ if (mnl > 16)
+ return 0;
+
+ sad_count = eld[5] >> 4;
+ sad = eld + 20 + mnl;
+
+ /* Start from the basic audio settings */
+ max_channels = 2;
+ rate_mask = 0;
+ fmt = 0;
+ while (sad_count--) {
+ switch (sad[0] & 0x78) {
+ case 0x08: /* PCM */
+ max_channels = max(max_channels, (sad[0] & 7) + 1u);
+ rate_mask |= sad[1];
+ fmt |= sad[2] & 0x07;
+ break;
+ }
+ sad += 3;
+ }
+
+ /* set the constraints */
+ rate_constraints
[alsa-devel] [PATCH v2] ASoC: tda998x: add a codec to the HDMI transmitter
On Tue, 08 Jul 2014 10:17:58 +0100
Andrew Jackson wrote:
> > + static const u32 hdmi_rates[] = {
> > + 32000, 44100, 48000, 88200, 9600, 176400, 192000
> > + };
> > +
>
> Shouldn't this be 96000, not 9600? Assuming that the table is ordered in
> terms of increasing frequencies.
You are right. Thank you.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
[PATCH/RESEND 0/9] drm: tilcdc driver fixes
On 3 July 2014 06:38, Ezequiel Garc?a wrote: > On 02 Jul 02:08 PM, Dave Airlie wrote: >> On 2 July 2014 12:31, Darren Etheridge wrote: >> > On 07/01/2014 06:39 PM, Guido Mart?nez wrote: >> >> >> >> On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote: >> >>> >> >>> [snip] >> >>> >> >>> Otherwise I think this is a good and useful patch series. >> >> >> >> It that a Tested-by tag? :) >> > >> > >> > Sure - I would prefer that the WARN_ON was silenced when the tilcdc module >> > is removed, but the series adds improvements over what is there now. I >> > have >> > tested it across a few variants of AM335x boards and attached display >> > hardware in both module form and built-in to the kernel, therefore: >> > >> > Tested-by: Darren Etheridge >> >> Has someone gathered that tags and put these in a git tree by any chance? >> > > I don't think anyone has. Is that a problem? > > If you need a pull request with these, I can prepare something in bitbucket. > Would that work you? I've picked them up manually now, so should be all fine. Thanks, Dave.
[PATCH v2 0/9] Updated fence patch series
On Tue, Jul 08, 2014 at 08:22:11PM +0530, Sumit Semwal wrote: > On 8 July 2014 20:09, Greg KH wrote: > > On Tue, Jul 08, 2014 at 03:44:27PM +0200, Daniel Vetter wrote: > >> On Mon, Jul 07, 2014 at 10:30:52AM -0700, Greg KH wrote: > >> > On Mon, Jul 07, 2014 at 03:23:17PM +0200, Daniel Vetter wrote: > >> > > On Wed, Jul 2, 2014 at 7:37 AM, Greg KH >> > > linuxfoundation.org> wrote: > >> > > >> Android can expose fences to userspace. It's possible to make the > >> > > >> new fence > >> > > >> mechanism expose the same fences to userspace by changing > >> > > >> sync_fence_create > >> > > >> to take a struct fence instead of a struct sync_pt. No other change > >> > > >> is needed, > >> > > >> because only the fence parts of struct sync_pt are used. But > >> > > >> because the > >> > > >> userspace fences are a separate problem and I haven't really looked > >> > > >> at it yet > >> > > >> I feel it should stay in staging, for now. > >> > > > > >> > > > Ok, that's reasonable. > >> > > > > >> > > > At first glance, this all looks "sane" to me, any objection from > >> > > > anyone > >> > > > if I merge this through my driver-core tree for 3.17? > >> > > > >> > > Ack from my side fwiw. > >> > > >> > Thanks, I'll queue it up later today. > >> > >> btw should we add you as a (co)maintainer for driver/core/dma-buf since > >> you seem to want to keep a closer tab on what the insane gfx folks are up > >> to in there? > > > > Sure, why not, what's one more maintainership... > > > > Oh, does that mean you want me to be the one collecting the patches and > > forwarding them on to Linus? If so, that's fine, I can easily do that > > as well due to my infrastructure being set up for it. > > > If you're ok, I could continue to do the collecting / forwarding > business - I guess Daniel meant more from the 'not miss patches that > need review'! Hey, I'm more than willing to have other people do the real work of collecting / forwarding :) I'll just review stuff as it floats by, that's not enough of a role to put me in "MAINTAINERS" at all. thanks, greg k-h
[v3 10/13] drm/i915: Add 180 degree primary plane rotation support
From: Sonika Jindal
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.
v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.
v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.
v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.
v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.
v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
crtc->primary->fb and return value of update_primary_plane is ignored.
v9: added rotation property to primary plane instead of crtc. Removing reset
of rotation property from lastclose. rotation_property is moved to drm_plane,so
drm layer will take care of resetting.
v10: adding updation of fbc when rotation is set to 0.
v11: adding mutex locks for update_fbc. Allowing rotation only if value is
different than old one. Other minor cleanups.
Testcase: igt/kms_rotation_crc
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Uma Shankar
Signed-off-by: Sagar Kamble
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 109 --
drivers/gpu/drm/i915/intel_pm.c |7 +++
3 files changed, 112 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c70c804..c600d3b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4087,6 +4087,7 @@ enum punit_power_well {
#define DISPPLANE_NO_LINE_DOUBLE 0
#define DISPPLANE_STEREO_POLARITY_FIRST 0
#define DISPPLANE_STEREO_POLARITY_SECOND (1<<18)
+#define DISPPLANE_ROTATE_180 (1<<15)
#define DISPPLANE_TRICKLE_FEED_DISABLE (1<<14) /* Ironlake */
#define DISPPLANE_TILED (1<<10)
#define _DSPAADDR 0x70184
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5e8e711..47ef1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2414,7 +2414,9 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
unsigned long linear_offset;
u32 dspcntr;
u32 reg;
+ int pixel_size;
+ pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb->obj;
@@ -2422,6 +2424,8 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
dspcntr = I915_READ(reg);
/* Mask out pixel format bits in case we change it */
dspcntr &= ~DISPPLANE_PIXFORMAT_MASK;
+ dspcntr &= ~DISPPLANE_ROTATE_180;
+
switch (fb->pixel_format) {
case DRM_FORMAT_C8:
dspcntr |= DISPPLANE_8BPP;
@@ -2463,8 +2467,6 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
- I915_WRITE(reg, dspcntr);
-
linear_offset = y * fb->pitches[0] + x * (fb->bits_per_pixel / 8);
if (INTEL_INFO(dev)->gen >= 4) {
@@ -2477,6 +2479,18 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
intel_crtc->dspaddr_offset = linear_offset;
}
+ if (to_intel_plane(crtc->primary)->rotation == BIT(DRM_ROTATE_180)) {
+ dspcntr |= DISPPLANE_ROTATE_180;
+
+ x += (intel_crtc->config.pipe_src_w - 1);
+ y += (intel_crtc->config.pipe_src_h - 1);
+ linear_offset += (intel_crtc->config.pipe_src_h - 1) *
+ fb->pitches[0] +
+ (intel_crtc->config.pipe_src_w - 1) * pixel_size;
+ }
+
+ I915_WRITE(reg, dspcntr);
+
DRM_DEBUG_KMS("Writing base %08lX %08lX %d %d %d\n",
i915_gem_obj_ggtt_offset(obj), linear_offset, x, y,
fb->pitches[0]);
@@ -2487,7 +2501,8 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
I915_WRITE(DSPTILEOFF(plane), (y << 16) | x);
I915_WRITE(DSPLINOFF(plane),
[v3 09/13] drm/i915: Add rotation property for sprites
From: Ville Syrj?l?
Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.
v2: Moving rotation_property to drm_plane
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ville Syrj?l?
Signed-off-by: Sonika Jindal
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/intel_sprite.c | 40 ++-
include/drm/drm_crtc.h |1 +
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index cbad738..aa63027 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1202,6 +1202,29 @@ out_unlock:
return ret;
}
+static int intel_plane_set_property(struct drm_plane *plane,
+ struct drm_property *prop,
+ uint64_t val)
+{
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ uint64_t old_val;
+ int ret = -ENOENT;
+
+ if (prop == plane->rotation_property) {
+ /* exactly one rotation angle please */
+ if (hweight32(val & 0xf) != 1)
+ return -EINVAL;
+
+ old_val = intel_plane->rotation;
+ intel_plane->rotation = val;
+ ret = intel_plane_restore(plane);
+ if (ret)
+ intel_plane->rotation = old_val;
+ }
+
+ return ret;
+}
+
int intel_plane_restore(struct drm_plane *plane)
{
struct intel_plane *intel_plane = to_intel_plane(plane);
@@ -1228,6 +1251,7 @@ static const struct drm_plane_funcs intel_plane_funcs = {
.update_plane = intel_update_plane,
.disable_plane = intel_disable_plane,
.destroy = intel_destroy_plane,
+ .set_property = intel_plane_set_property,
};
static uint32_t ilk_plane_formats[] = {
@@ -1338,8 +1362,22 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe,
int plane)
&intel_plane_funcs,
plane_formats, num_plane_formats,
false);
- if (ret)
+ if (ret) {
kfree(intel_plane);
+ goto out;
+ }
+
+ if (!intel_plane->base.rotation_property)
+ intel_plane->base.rotation_property =
+ drm_mode_create_rotation_property(dev,
+ BIT(DRM_ROTATE_0) |
+ BIT(DRM_ROTATE_180));
+
+ if (intel_plane->base.rotation_property)
+ drm_object_attach_property(&intel_plane->base.base,
+ intel_plane->base.rotation_property,
+ intel_plane->rotation);
+ out:
return ret;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 08ed55e..6006c70 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -615,6 +615,7 @@ struct drm_plane {
const struct drm_plane_funcs *funcs;
+ struct drm_property *rotation_property;
struct drm_object_properties properties;
enum drm_plane_type type;
--
1.7.10.4
[v3 08/13] drm/i915: Make intel_plane_restore() return an error
From: Ville Syrj?l?
Propagate the error from intel_update_plane() up through
intel_plane_restore() to the caller. This will be used for
rollback purposes when setting properties fails.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ville Syrj?l?
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/intel_drv.h|2 +-
drivers/gpu/drm/i915/intel_sprite.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 67b1c59..da5a3ca 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -993,7 +993,7 @@ bool intel_sdvo_init(struct drm_device *dev, uint32_t
sdvo_reg, bool is_sdvob);
int intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane);
void intel_flush_primary_plane(struct drm_i915_private *dev_priv,
enum plane plane);
-void intel_plane_restore(struct drm_plane *plane);
+int intel_plane_restore(struct drm_plane *plane);
void intel_plane_disable(struct drm_plane *plane);
int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 54d4224..cbad738 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1202,18 +1202,18 @@ out_unlock:
return ret;
}
-void intel_plane_restore(struct drm_plane *plane)
+int intel_plane_restore(struct drm_plane *plane)
{
struct intel_plane *intel_plane = to_intel_plane(plane);
if (!plane->crtc || !plane->fb)
- return;
+ return 0;
- intel_update_plane(plane, plane->crtc, plane->fb,
- intel_plane->crtc_x, intel_plane->crtc_y,
- intel_plane->crtc_w, intel_plane->crtc_h,
- intel_plane->src_x, intel_plane->src_y,
- intel_plane->src_w, intel_plane->src_h);
+ return intel_update_plane(plane, plane->crtc, plane->fb,
+ intel_plane->crtc_x, intel_plane->crtc_y,
+ intel_plane->crtc_w, intel_plane->crtc_h,
+ intel_plane->src_x, intel_plane->src_y,
+ intel_plane->src_w, intel_plane->src_h);
}
void intel_plane_disable(struct drm_plane *plane)
--
1.7.10.4
[v3 07/13] drm/i915: Add 180 degree sprite rotation support
From: Ville Syrj?l?
The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.
The upper layers are not yet plugged in.
v2: HSW handles the rotated buffer offset automagically
v3: BDW also handles the rotated buffer offset automagically
Testcase: igt/kms_rotation_crc
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ville Syrj?l?
Signed-off-by: Sagar Kamble
Reviewed-by: Imre Deak
---
drivers/gpu/drm/i915/i915_reg.h |3 +++
drivers/gpu/drm/i915/intel_drv.h|1 +
drivers/gpu/drm/i915/intel_sprite.c | 37 +++
3 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3488567..c70c804 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4171,6 +4171,7 @@ enum punit_power_well {
#define DVS_YUV_ORDER_UYVY (1<<16)
#define DVS_YUV_ORDER_YVYU (2<<16)
#define DVS_YUV_ORDER_VYUY (3<<16)
+#define DVS_ROTATE_180 (1<<15)
#define DVS_DEST_KEY (1<<2)
#define DVS_TRICKLE_FEED_DISABLE (1<<14)
#define DVS_TILED(1<<10)
@@ -4241,6 +4242,7 @@ enum punit_power_well {
#define SPRITE_YUV_ORDER_UYVY(1<<16)
#define SPRITE_YUV_ORDER_YVYU(2<<16)
#define SPRITE_YUV_ORDER_VYUY(3<<16)
+#define SPRITE_ROTATE_180(1<<15)
#define SPRITE_TRICKLE_FEED_DISABLE (1<<14)
#define SPRITE_INT_GAMMA_ENABLE (1<<13)
#define SPRITE_TILED (1<<10)
@@ -4314,6 +4316,7 @@ enum punit_power_well {
#define SP_YUV_ORDER_UYVY(1<<16)
#define SP_YUV_ORDER_YVYU(2<<16)
#define SP_YUV_ORDER_VYUY(3<<16)
+#define SP_ROTATE_180(1<<15)
#define SP_TILED (1<<10)
#define _SPALINOFF (VLV_DISPLAY_BASE + 0x72184)
#define _SPASTRIDE (VLV_DISPLAY_BASE + 0x72188)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ab5962b..67b1c59 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -437,6 +437,7 @@ struct intel_plane {
unsigned int crtc_w, crtc_h;
uint32_t src_x, src_y;
uint32_t src_w, src_h;
+ unsigned int rotation;
/* Since we need to change the watermarks before/after
* enabling/disabling the planes, we need to store the parameters here
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 404335d..54d4224 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -163,6 +163,7 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc
*crtc,
sprctl &= ~SP_PIXFORMAT_MASK;
sprctl &= ~SP_YUV_BYTE_ORDER_MASK;
sprctl &= ~SP_TILED;
+ sprctl &= ~SP_ROTATE_180;
switch (fb->pixel_format) {
case DRM_FORMAT_YUYV:
@@ -234,6 +235,14 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc
*crtc,
fb->pitches[0]);
linear_offset -= sprsurf_offset;
+ if (intel_plane->rotation == BIT(DRM_ROTATE_180)) {
+ sprctl |= SP_ROTATE_180;
+
+ x += src_w;
+ y += src_h;
+ linear_offset += src_h * fb->pitches[0] + src_w * pixel_size;
+ }
+
atomic_update = intel_pipe_update_start(intel_crtc, &start_vbl_count);
intel_update_primary_plane(intel_crtc);
@@ -363,6 +372,7 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
sprctl &= ~SPRITE_RGB_ORDER_RGBX;
sprctl &= ~SPRITE_YUV_BYTE_ORDER_MASK;
sprctl &= ~SPRITE_TILED;
+ sprctl &= ~SPRITE_ROTATE_180;
switch (fb->pixel_format) {
case DRM_FORMAT_XBGR:
@@ -424,6 +434,17 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
pixel_size, fb->pitches[0]);
linear_offset -= sprsurf_offset;
+ if (intel_plane->rotation == BIT(DRM_ROTATE_180)) {
+ sprctl |= SPRITE_ROTATE_180;
+
+ /* HSW and BDW does this automagically in hardware */
+ if (!IS_HASWELL(dev) && !IS_BROADWELL(dev)) {
+ x += src_w;
+ y += src_h;
+ linear_offset += src_h * fb->pitches[0] + src_w *
pixel_size;
+ }
+ }
+
atomic_update = intel_pipe_update_start(intel_crtc, &start_vbl_count);
intel_update_primary_plane(intel_crtc);
@@ -569,6 +590,7 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
dvscntr &= ~DVS_RGB_ORDER_XBGR;
dvscntr &= ~DVS_YUV_BYTE_ORDER_MASK;
dvscntr &= ~DVS_TILED;
+ dvscntr &= ~DVS_ROTATE_180;
switch (fb->pixel_format) {
[v3 06/13] drm: Add drm_rotation_simplify()
From: Ville Syrj?l?
drm_rotation_simplify() can be used to eliminate unsupported rotation
flags. It will check if any unsupported flags are present, and if so
it will modify the rotation to an alternate form by adding 180 degrees
to rotation angle, and flipping the reflect x and y bits. The hope is
that this identity transform will eliminate the unsupported flags.
Of course that might not result in any more supported rotation, so
the caller is still responsible for checking the result afterwards.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ville Syrj?l?
Reviewed-by: Imre Deak
---
drivers/gpu/drm/drm_crtc.c | 30 ++
include/drm/drm_crtc.h |2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f224d4d..89bab66 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4842,6 +4842,36 @@ int drm_format_vert_chroma_subsampling(uint32_t format)
EXPORT_SYMBOL(drm_format_vert_chroma_subsampling);
/**
+ * drm_rotation_simplify() - Try to simplify the rotation
+ * @rotation: Rotation to be simplified
+ * @supported_rotations: Supported rotations
+ *
+ * Attempt to simplify the rotation to a form that is supported.
+ * Eg. if the hardware supports everything except DRM_REFLECT_X
+ * one could call this function like this:
+ *
+ * drm_rotation_simplify(rotation, BIT(DRM_ROTATE_0) |
+ * BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_180) |
+ * BIT(DRM_ROTATE_270) | BIT(DRM_REFLECT_Y));
+ *
+ * to eliminate the DRM_ROTATE_X flag. Depending on what kind of
+ * transforms the hardware supports, this function may not
+ * be able to produce a supported transform, so the caller should
+ * check the result afterwards.
+ */
+unsigned int drm_rotation_simplify(unsigned int rotation,
+ unsigned int supported_rotations)
+{
+ if (rotation & ~supported_rotations) {
+ rotation ^= BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y);
+ rotation = (rotation & ~0xf) | BIT((ffs(rotation & 0xf) + 1) %
4);
+ }
+
+ return rotation;
+}
+EXPORT_SYMBOL(drm_rotation_simplify);
+
+/**
* drm_mode_config_init - initialize DRM mode_configuration structure
* @dev: DRM device
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f7b383b..08ed55e 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1115,6 +1115,8 @@ extern int drm_format_vert_chroma_subsampling(uint32_t
format);
extern const char *drm_get_format_name(uint32_t format);
extern struct drm_property *drm_mode_create_rotation_property(struct
drm_device *dev,
unsigned int
supported_rotations);
+extern unsigned int drm_rotation_simplify(unsigned int rotation,
+ unsigned int supported_rotations);
/* Helpers */
--
1.7.10.4
[v3 05/13] drm: Add drm_rect rotation functions
From: Ville Syrj?l?
Add some helper functions to move drm_rects between different rotated
coordinate spaces. One function does the forward transform and
another does the inverse.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ville Syrj?l?
Reviewed-by: Imre Deak
---
drivers/gpu/drm/drm_rect.c | 140
include/drm/drm_rect.h |6 ++
2 files changed, 146 insertions(+)
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index 7047ca0..631f5af 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -293,3 +293,143 @@ void drm_rect_debug_print(const struct drm_rect *r, bool
fixed_point)
DRM_DEBUG_KMS("%dx%d%+d%+d\n", w, h, r->x1, r->y1);
}
EXPORT_SYMBOL(drm_rect_debug_print);
+
+/**
+ * drm_rect_rotate - Rotate the rectangle
+ * @r: rectangle to be rotated
+ * @width: Width of the coordinate space
+ * @height: Height of the coordinate space
+ * @rotation: Transformation to be applied
+ *
+ * Apply @rotation to the coordinates of rectangle @r.
+ *
+ * @width and @height combined with @rotation define
+ * the location of the new origin.
+ *
+ * @width correcsponds to the horizontal and @height
+ * to the vertical axis of the untransformed coordinate
+ * space.
+ */
+void drm_rect_rotate(struct drm_rect *r,
+int width, int height,
+unsigned int rotation)
+{
+ struct drm_rect tmp;
+
+ if (rotation & (BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y))) {
+ tmp = *r;
+
+ if (rotation & BIT(DRM_REFLECT_X)) {
+ r->x1 = width - tmp.x2;
+ r->x2 = width - tmp.x1;
+ }
+
+ if (rotation & BIT(DRM_REFLECT_Y)) {
+ r->y1 = height - tmp.y2;
+ r->y2 = height - tmp.y1;
+ }
+ }
+
+ switch (rotation & 0xf) {
+ case BIT(DRM_ROTATE_0):
+ break;
+ case BIT(DRM_ROTATE_90):
+ tmp = *r;
+ r->x1 = tmp.y1;
+ r->x2 = tmp.y2;
+ r->y1 = width - tmp.x2;
+ r->y2 = width - tmp.x1;
+ break;
+ case BIT(DRM_ROTATE_180):
+ tmp = *r;
+ r->x1 = width - tmp.x2;
+ r->x2 = width - tmp.x1;
+ r->y1 = height - tmp.y2;
+ r->y2 = height - tmp.y1;
+ break;
+ case BIT(DRM_ROTATE_270):
+ tmp = *r;
+ r->x1 = height - tmp.y2;
+ r->x2 = height - tmp.y1;
+ r->y1 = tmp.x1;
+ r->y2 = tmp.x2;
+ break;
+ default:
+ break;
+ }
+}
+EXPORT_SYMBOL(drm_rect_rotate);
+
+/**
+ * drm_rect_rotate_inv - Inverse rotate the rectangle
+ * @r: rectangle to be rotated
+ * @width: Width of the coordinate space
+ * @height: Height of the coordinate space
+ * @rotation: Transformation whose inverse is to be applied
+ *
+ * Apply the inverse of @rotation to the coordinates
+ * of rectangle @r.
+ *
+ * @width and @height combined with @rotation define
+ * the location of the new origin.
+ *
+ * @width correcsponds to the horizontal and @height
+ * to the vertical axis of the original untransformed
+ * coordinate space, so that you never have to flip
+ * them when doing a rotatation and its inverse.
+ * That is, if you do:
+ *
+ * drm_rotate(&r, width, height, rotation);
+ * drm_rotate_inv(&r, width, height, rotation);
+ *
+ * you will always get back the original rectangle.
+ */
+void drm_rect_rotate_inv(struct drm_rect *r,
+int width, int height,
+unsigned int rotation)
+{
+ struct drm_rect tmp;
+
+ switch (rotation & 0xf) {
+ case BIT(DRM_ROTATE_0):
+ break;
+ case BIT(DRM_ROTATE_90):
+ tmp = *r;
+ r->x1 = width - tmp.y2;
+ r->x2 = width - tmp.y1;
+ r->y1 = tmp.x1;
+ r->y2 = tmp.x2;
+ break;
+ case BIT(DRM_ROTATE_180):
+ tmp = *r;
+ r->x1 = width - tmp.x2;
+ r->x2 = width - tmp.x1;
+ r->y1 = height - tmp.y2;
+ r->y2 = height - tmp.y1;
+ break;
+ case BIT(DRM_ROTATE_270):
+ tmp = *r;
+ r->x1 = tmp.y1;
+ r->x2 = tmp.y2;
+ r->y1 = height - tmp.x2;
+ r->y2 = height - tmp.x1;
+ break;
+ default:
+ break;
+ }
+
+ if (rotation & (BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y))) {
+ tmp = *r;
+
+ if (rotation & BIT(DRM_REFLECT_X)) {
+ r->x1 = width - tmp.x2;
+ r->x2 = width - tmp.x1;
+ }
+
+ if (rotation & BIT(DRM_REFLECT_Y)) {
+ r->y1 = height - tmp.y2;
+
[v3 04/13] drm/omap: Switch omapdrm over to drm_mode_create_rotation_property()
From: Ville Syrj?l?
Use the new drm_mode_create_rotation_property() in omapdrm.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ville Syrj?l?
Reviewed-by: Rob Clark
Reviewed-by: Imre Deak
Reviewed-by: Sagar Kamble
---
drivers/gpu/drm/omapdrm/omap_plane.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index aff06e7..da9d15d 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -308,19 +308,13 @@ void omap_plane_install_properties(struct drm_plane
*plane,
if (priv->has_dmm) {
prop = priv->rotation_prop;
if (!prop) {
- const struct drm_prop_enum_list props[] = {
- { DRM_ROTATE_0, "rotate-0" },
- { DRM_ROTATE_90, "rotate-90" },
- { DRM_ROTATE_180, "rotate-180" },
- { DRM_ROTATE_270, "rotate-270" },
- { DRM_REFLECT_X, "reflect-x" },
- { DRM_REFLECT_Y, "reflect-y" },
- };
- prop = drm_property_create_bitmask(dev, 0, "rotation",
- props, ARRAY_SIZE(props),
- BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_90) |
- BIT(DRM_ROTATE_180) |
BIT(DRM_ROTATE_270) |
- BIT(DRM_REFLECT_X) |
BIT(DRM_REFLECT_Y));
+ prop = drm_mode_create_rotation_property(dev,
+
BIT(DRM_ROTATE_0) |
+
BIT(DRM_ROTATE_90) |
+
BIT(DRM_ROTATE_180) |
+
BIT(DRM_ROTATE_270) |
+
BIT(DRM_REFLECT_X) |
+
BIT(DRM_REFLECT_Y));
if (prop == NULL)
return;
priv->rotation_prop = prop;
--
1.7.10.4
[v3 02/13] drm: Add support_bits parameter to drm_property_create_bitmask()
From: Ville Syrj?l?
Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.
v2: Populate values[] array as non-sparse
Make supported_bits 64bit
Fix up omapdrm call site (Rob)
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Ville Syrj?l?
Reviewed-by: Imre Deak
Reviewed-by: Sagar Kamble
---
drivers/gpu/drm/drm_crtc.c | 17 +
drivers/gpu/drm/omapdrm/omap_plane.c |5 -
include/drm/drm_crtc.h |3 ++-
3 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 41c7212..2fbee61 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3395,19 +3395,28 @@ EXPORT_SYMBOL(drm_property_create_enum);
struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
int flags, const char *name,
const struct drm_prop_enum_list *props,
-int num_values)
+int num_props,
+uint64_t supported_bits)
{
struct drm_property *property;
- int i, ret;
+ int i, ret, index = 0;
+ int num_values = hweight64(supported_bits);
flags |= DRM_MODE_PROP_BITMASK;
property = drm_property_create(dev, flags, name, num_values);
if (!property)
return NULL;
+ for (i = 0; i < num_props; i++) {
+ if (!(supported_bits & (1ULL << props[i].type)))
+ continue;
- for (i = 0; i < num_values; i++) {
- ret = drm_property_add_enum(property, i,
+ if (WARN_ON(index >= num_values)) {
+ drm_property_destroy(dev, property);
+ return NULL;
+ }
+
+ ret = drm_property_add_enum(property, index++,
props[i].type,
props[i].name);
if (ret) {
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 3cf31ee..aff06e7 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -317,7 +317,10 @@ void omap_plane_install_properties(struct drm_plane *plane,
{ DRM_REFLECT_Y, "reflect-y" },
};
prop = drm_property_create_bitmask(dev, 0, "rotation",
- props, ARRAY_SIZE(props));
+ props, ARRAY_SIZE(props),
+ BIT(DRM_ROTATE_0) | BIT(DRM_ROTATE_90) |
+ BIT(DRM_ROTATE_180) |
BIT(DRM_ROTATE_270) |
+ BIT(DRM_REFLECT_X) |
BIT(DRM_REFLECT_Y));
if (prop == NULL)
return;
priv->rotation_prop = prop;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfc7235..cb4850a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1006,7 +1006,8 @@ extern struct drm_property
*drm_property_create_enum(struct drm_device *dev, int
struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
int flags, const char *name,
const struct drm_prop_enum_list *props,
-int num_values);
+int num_props,
+uint64_t supported_bits);
struct drm_property *drm_property_create_range(struct drm_device *dev, int
flags,
const char *name,
uint64_t min, uint64_t max);
--
1.7.10.4
[alsa-devel] [PATCH v2] ASoC: tda998x: add a codec to the HDMI transmitter
On 07/04/14 08:17, Jean-Francois Moine wrote:
> This patch adds a CODEC function to the NXP TDA998x HDMI transmitter.
>
> The CODEC handles both I2S and S/PDIF input and does dynamic input
> switch in the TDA998x I2C driver on start/stop audio streaming.
>
> Signed-off-by: Jean-Francois Moine
> ---
[snip]
> +++ b/drivers/gpu/drm/i2c/tda998x_codec.c
[snip]
> +static int tda_startup(struct snd_pcm_substream *substream,
> + struct snd_soc_dai *dai)
> +{
> + struct tda998x_priv *priv = snd_soc_codec_get_drvdata(dai->codec);
> + u8 *eld = priv->eld;
> + struct snd_pcm_runtime *runtime = substream->runtime;
> + u8 *sad;
> + int sad_count;
> + unsigned eld_ver, mnl, rate_mask;
> + unsigned max_channels, fmt;
> + u64 formats;
> + struct snd_pcm_hw_constraint_list *rate_constraints =
> + &priv->rate_constraints;
> + static const u32 hdmi_rates[] = {
> + 32000, 44100, 48000, 88200, 9600, 176400, 192000
> + };
> +
Shouldn't this be 96000, not 9600? Assuming that the table is ordered in terms
of increasing frequencies.
Andrew
[Intel-gfx] [PATCH 5/5] drm/i915: Kick out vga console
On Mon, Jul 07, 2014 at 10:53:16PM -0400, Ed Tomlinson wrote:
> Hi Daniel,
>
> The patch below also works. You can use my Tested By for it.
Thanks a lot for testing, patch submitted and should get forwarded asap.
>
> Thanks
> Ed Tomlinson
>
> PS. I _really_ need to get a serial console working on my i7 box.
Usually this doesn't help a lot with gfx initialization issues since we do
an awful lot of setup while holding the console_lock. Which prevents any
dmesg output on any console :(
Cheers, Daniel
>
> On Monday 07 July 2014 14:26:54 Daniel Vetter wrote:
> > On Mon, Jul 07, 2014 at 06:45:49AM -0400, Ed Tomlinson wrote:
> > > Daniel,
> > >
> > > I am not quite sure I understand what you want me to test?
> > > Do you want me to try it without:
> > >
> > > > > + if (ret == 0) {
> > > > > + ret = do_unregister_con_driver(&vga_con);
> >
> > Below the diff of what I mean.
> > -Daniel
> >
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 5e583a1838f8..bd8517151479 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -1466,12 +1466,13 @@ static int i915_kick_out_vgacon(struct
> > drm_i915_private *dev_priv)
> > #else
> > static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
> > {
> > - int ret;
> > + int ret = 0;
> >
> > DRM_INFO("Replacing VGA console driver\n");
> >
> > console_lock();
> > - ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1, 1);
> > + if (con_is_bound(&vga_con))
> > + ret = do_take_over_console(&dummy_con, 0, MAX_NR_CONSOLES - 1,
> > 1);
> > if (ret == 0) {
> > ret = do_unregister_con_driver(&vga_con);
> >
> >
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v5 14/14] ARM: dts: exynos5420: add dsi node
This patch adds common part of dsi node.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 0b9d15d..3a7862b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -523,6 +523,20 @@
#phy-cells = <1>;
};
+ dsi at 1450 {
+ compatible = "samsung,exynos5410-mipi-dsi";
+ reg = <0x1450 0x1>;
+ interrupts = <0 82 0>;
+ samsung,power-domain = <&disp_pd>;
+ phys = <&mipi_phy 1>;
+ phy-names = "dsim";
+ clocks = <&clock CLK_DSIM1>, <&clock CLK_SCLK_MIPI1>;
+ clock-names = "bus_clk", "pll_clk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
fimd: fimd at 1440 {
samsung,power-domain = <&disp_pd>;
clocks = <&clock CLK_SCLK_FIMD1>, <&clock CLK_FIMD1>;
--
1.9.0
[PATCH v5 13/14] ARM: dts: exynos5420: add mipi-phy node
This patch adds mipi-phy node for MIPI DSI device.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos5420.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index e385322..0b9d15d 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -517,6 +517,12 @@
phy-names = "dp";
};
+ mipi_phy: video-phy at 10040714 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10040714 12>;
+ #phy-cells = <1>;
+ };
+
fimd: fimd at 1440 {
samsung,power-domain = <&disp_pd>;
clocks = <&clock CLK_SCLK_FIMD1>, <&clock CLK_FIMD1>;
--
1.9.0
[PATCH v5 12/14] ARM: dts: exynos5: add system register property
This patch adds sysreg property to fimd device node which is required to use I80 interface. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- arch/arm/boot/dts/exynos5.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi index 79d0608..fdead12 100644 --- a/arch/arm/boot/dts/exynos5.dtsi +++ b/arch/arm/boot/dts/exynos5.dtsi @@ -87,6 +87,7 @@ reg = <0x1440 0x4>; interrupt-names = "fifo", "vsync", "lcd_sys"; interrupts = <18 4>, <18 5>, <18 6>; + samsung,sysreg = <&sysreg_system_controller>; status = "disabled"; }; -- 1.9.0
[PATCH v5 11/14] ARM: dts: exynos4: add system register property
This patch adds sysreg property to fimd device node which is required to use I80 interface. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- arch/arm/boot/dts/exynos4.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index b8ece4b..92ee786 100644 --- a/arch/arm/boot/dts/exynos4.dtsi +++ b/arch/arm/boot/dts/exynos4.dtsi @@ -608,6 +608,7 @@ clocks = <&clock CLK_SCLK_FIMD0>, <&clock CLK_FIMD0>; clock-names = "sclk_fimd", "fimd"; samsung,power-domain = <&pd_lcd0>; + samsung,sysreg = <&sys_reg>; status = "disabled"; }; }; -- 1.9.0
[PATCH v5 10/14] drm/panel: add S6E3FA0 driver
This patch adds MIPI DSI command mode based
S6E3FA0 AMOLED LCD Panel driver.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/panel/Kconfig | 7 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-s6e3fa0.c | 569 ++
3 files changed, 577 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..be1392e 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,11 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_S6E3FA0
+ tristate "S6E3FA0 DSI command mode panel"
+ depends on DRM && DRM_PANEL
+ depends on OF
+ select DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..85c6738 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E3FA0) += panel-s6e3fa0.o
diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
b/drivers/gpu/drm/panel/panel-s6e3fa0.c
new file mode 100644
index 000..66058a7
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
@@ -0,0 +1,569 @@
+/*
+ * MIPI DSI command mode based s6e3fa0 AMOLED LCD 5.7 inch drm panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * YoungJun Cho
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+#include
+
+/* Manufacturer Command Set */
+#define MCS_GLOBAL_PARAMETER 0xb0
+#define MCS_AID0xb2
+#define MCS_ELVSSOPT 0xb6
+#define MCS_TEMPERATURE_SET0xb8
+#define MCS_PENTILE_CTRL 0xc0
+#define MCS_GAMMA_MODE 0xca
+#define MCS_VDDM 0xd7
+#define MCS_ALS0xe3
+#define MCS_ERR_FG 0xed
+#define MCS_KEY_LEV1 0xf0
+#define MCS_GAMMA_UPDATE 0xf7
+#define MCS_KEY_LEV2 0xfc
+#define MCS_RE 0xfe
+#define MCS_TOUT2_HSYNC0xff
+
+/* Content Adaptive Brightness Control */
+#define DCS_WRITE_CABC 0x55
+
+#define MTP_ID_LEN 3
+#define GAMMA_LEVEL_NUM30
+
+#define DEFAULT_VDDM_VAL 0x15
+
+struct s6e3fa0 {
+ struct device *dev;
+ struct drm_panelpanel;
+
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc*reset_gpio;
+ struct gpio_desc*det_gpio;
+ struct gpio_desc*te_gpio;
+ struct videomodevm;
+
+ unsigned intpower_on_delay;
+ unsigned intreset_delay;
+ unsigned intinit_delay;
+ unsigned intwidth_mm;
+ unsigned intheight_mm;
+
+ unsigned char id;
+ unsigned char vddm;
+ unsigned intbrightness;
+};
+
+#define panel_to_s6e3fa0(p) container_of(p, struct s6e3fa0, panel)
+
+/* VDD Memory Lookup Table contains pairs of {ReadValue, WriteValue} */
+static const unsigned char s6e3fa0_vddm_lut[][2] = {
+ {0x00, 0x0d}, {0x01, 0x0d}, {0x02, 0x0e}, {0x03, 0x0f}, {0x04, 0x10},
+ {0x05, 0x11}, {0x06, 0x12}, {0x07, 0x13}, {0x08, 0x14}, {0x09, 0x15},
+ {0x0a, 0x16}, {0x0b, 0x17}, {0x0c, 0x18}, {0x0d, 0x19}, {0x0e, 0x1a},
+ {0x0f, 0x1b}, {0x10, 0x1c}, {0x11, 0x1d}, {0x12, 0x1e}, {0x13, 0x1f},
+ {0x14, 0x20}, {0x15, 0x21}, {0x16, 0x22}, {0x17, 0x23}, {0x18, 0x24},
+ {0x19, 0x25}, {0x1a, 0x26}, {0x1b, 0x27}, {0x1c, 0x28}, {0x1d, 0x29},
+ {0x1e, 0x2a}, {0x1f, 0x2b}, {0x20, 0x2c}, {0x21, 0x2d}, {0x22, 0x2e},
+ {0x23, 0x2f}, {0x24, 0x30}, {0x25, 0x31}, {0x26, 0x32}, {0x27, 0x33},
+ {0x28, 0x34}, {0x29, 0x35}, {0x2a, 0x36}, {0x2b, 0x37}, {0x2c, 0x38},
+ {0x2d, 0x39}, {0x2e, 0x3a}, {0x2f, 0x3b}, {0x30, 0x3c}, {0x31, 0x3d},
+ {0x32, 0x3e}, {0x33, 0x3f}, {0x34, 0x3f}, {0x35, 0x3f}, {0x36, 0x3f},
+ {0x37, 0x3f}, {0x38, 0x3f}, {0x39, 0x3f}, {0x3a, 0x3f}, {0x3b, 0x3f},
+ {0x3c, 0x3f}, {0x3d, 0x3f}, {0x3e, 0x3f}, {0x3f, 0x3f}, {0x40, 0x0c},
+ {0x41, 0x0b}, {0x42, 0x0a}, {0x43, 0x09}, {0x44, 0x08}, {0x45, 0x07},
+ {0x46, 0x06}, {0x47, 0x05}, {0x48, 0x04}, {0x4
[PATCH v5 09/14] ARM: dts: s6e3fa0: add DT bindings
This patch adds DT bindings for s6e3fa0 panel.
The bindings describes panel resources and display timings.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
.../devicetree/bindings/panel/samsung,s6e3fa0.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
new file mode 100644
index 000..2cd32f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
@@ -0,0 +1,46 @@
+Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
+
+Required properties:
+ - compatible: "samsung,s6e3fa0"
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: core voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpios: a GPIO spec for the reset pin
+ - det-gpios: a GPIO spec for the OLED detection pin
+ - te-gpios: a GPIO spec for the TE pin
+ - display-timings: timings for the connected panel as described by [1]
+
+Optional properties:
+
+The device node can contain one 'port' child node with one child 'endpoint'
+node, according to the bindings defined in [2]. This node should describe
+panel's video bus.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ panel at 0 {
+ compatible = "samsung,s6e3fa0";
+ reg = <0>;
+ vdd3-supply = <&vcclcd_reg>;
+ vci-supply = <&vlcd_reg>;
+ reset-gpios = <&gpy7 4 0>;
+ det-gpios = <&gpg0 6 0>;
+ te-gpios = <&gpd1 7 0>;
+
+ display-timings {
+ timings0 {
+ clock-frequency = <0>;
+ hactive = <1080>;
+ vactive = <1920>;
+ hfront-porch = <2>;
+ hback-porch = <2>;
+ hsync-len = <1>;
+ vfront-porch = <1>;
+ vback-porch = <4>;
+ vsync-len = <1>;
+ };
+ };
+ };
--
1.9.0
[PATCH v5 08/14] drm/exynos: dsi: add driver data to support Exynos5410/5420/5440 SoCs
The offset of register DSIM_PLLTMR_REG in Exynos5410 / 5420 / 5440
SoCs is different from the one in Exynos4 SoCs.
In case of Exynos5410 / 5420 / 5440 SoCs, there is no frequency
band bit in DSIM_PLLCTRL_REG, and it uses DSIM_PHYCTRL_REG and
DSIM_PHYTIMING*_REG instead.
So this patch adds driver data to distinguish it.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 157 +++-
1 file changed, 135 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 76e34ca..162f74d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -55,9 +56,12 @@
/* FIFO memory AC characteristic register */
#define DSIM_PLLCTRL_REG 0x4c/* PLL control register */
-#define DSIM_PLLTMR_REG0x50/* PLL timer register */
#define DSIM_PHYACCHR_REG 0x54/* D-PHY AC characteristic register */
#define DSIM_PHYACCHR1_REG 0x58/* D-PHY AC characteristic register1 */
+#define DSIM_PHYCTRL_REG 0x5c
+#define DSIM_PHYTIMING_REG 0x64
+#define DSIM_PHYTIMING1_REG0x68
+#define DSIM_PHYTIMING2_REG0x6c
/* DSIM_STATUS */
#define DSIM_STOP_STATE_DAT(x) (((x) & 0xf) << 0)
@@ -201,6 +205,24 @@
#define DSIM_PLL_M(x) ((x) << 4)
#define DSIM_PLL_S(x) ((x) << 1)
+/* DSIM_PHYCTRL */
+#define DSIM_PHYCTRL_ULPS_EXIT(x) (((x) & 0x1ff) << 0)
+
+/* DSIM_PHYTIMING */
+#define DSIM_PHYTIMING_LPX(x) ((x) << 8)
+#define DSIM_PHYTIMING_HS_EXIT(x) ((x) << 0)
+
+/* DSIM_PHYTIMING1 */
+#define DSIM_PHYTIMING1_CLK_PREPARE(x) ((x) << 24)
+#define DSIM_PHYTIMING1_CLK_ZERO(x)((x) << 16)
+#define DSIM_PHYTIMING1_CLK_POST(x)((x) << 8)
+#define DSIM_PHYTIMING1_CLK_TRAIL(x) ((x) << 0)
+
+/* DSIM_PHYTIMING2 */
+#define DSIM_PHYTIMING2_HS_PREPARE(x) ((x) << 16)
+#define DSIM_PHYTIMING2_HS_ZERO(x) ((x) << 8)
+#define DSIM_PHYTIMING2_HS_TRAIL(x)((x) << 0)
+
#define DSI_MAX_BUS_WIDTH 4
#define DSI_NUM_VIRTUAL_CHANNELS 4
#define DSI_TX_FIFO_SIZE 2048
@@ -234,6 +256,12 @@ struct exynos_dsi_transfer {
#define DSIM_STATE_INITIALIZED BIT(1)
#define DSIM_STATE_CMD_LPM BIT(2)
+struct exynos_dsi_driver_data {
+ unsigned int plltmr_reg;
+
+ unsigned int has_freqband:1;
+};
+
struct exynos_dsi {
struct mipi_dsi_host dsi_host;
struct drm_connector connector;
@@ -263,11 +291,39 @@ struct exynos_dsi {
spinlock_t transfer_lock; /* protects transfer_list */
struct list_head transfer_list;
+
+ struct exynos_dsi_driver_data *driver_data;
};
#define host_to_dsi(host) container_of(host, struct exynos_dsi, dsi_host)
#define connector_to_dsi(c) container_of(c, struct exynos_dsi, connector)
+static struct exynos_dsi_driver_data exynos4_dsi_driver_data = {
+ .plltmr_reg = 0x50,
+ .has_freqband = 1,
+};
+
+static struct exynos_dsi_driver_data exynos5_dsi_driver_data = {
+ .plltmr_reg = 0x58,
+};
+
+static struct of_device_id exynos_dsi_of_match[] = {
+ { .compatible = "samsung,exynos4210-mipi-dsi",
+ .data = &exynos4_dsi_driver_data },
+ { .compatible = "samsung,exynos5410-mipi-dsi",
+ .data = &exynos5_dsi_driver_data },
+ { }
+};
+
+static inline struct exynos_dsi_driver_data *exynos_dsi_get_driver_data(
+ struct platform_device *pdev)
+{
+ const struct of_device_id *of_id =
+ of_match_device(exynos_dsi_of_match, &pdev->dev);
+
+ return (struct exynos_dsi_driver_data *)of_id->data;
+}
+
static void exynos_dsi_wait_for_reset(struct exynos_dsi *dsi)
{
if (wait_for_completion_timeout(&dsi->completed, msecs_to_jiffies(300)))
@@ -341,14 +397,9 @@ static unsigned long exynos_dsi_pll_find_pms(struct
exynos_dsi *dsi,
static unsigned long exynos_dsi_set_pll(struct exynos_dsi *dsi,
unsigned long freq)
{
- static const unsigned long freq_bands[] = {
- 100 * MHZ, 120 * MHZ, 160 * MHZ, 200 * MHZ,
- 270 * MHZ, 320 * MHZ, 390 * MHZ, 450 * MHZ,
- 510 * MHZ, 560 * MHZ, 640 * MHZ, 690 * MHZ,
- 770 * MHZ, 870 * MHZ, 950 * MHZ,
- };
+ struct exynos_dsi_driver_data *driver_data = dsi->driver_data;
unsigned long fin, fout;
- int timeout, band;
+ int timeout;
u8 p, s;
u16 m;
u32 reg;
@@ -369,18 +420,30 @@ static unsigned long exynos_dsi_set_pll(struct exynos_dsi
*dsi,
"failed to find PLL PMS for requested frequency\n");
return -EFAULT;
}
+ dev_dbg(dsi->dev, "PLL freq %lu, (p %d, m %d, s %d)\n", fout, p, m, s);
[PATCH v5 07/14] ARM: dts: exynos_dsim: add exynos5410 compatible to DT bindings
This patch adds relevant to exynos5410 compatible for exynos5410 / 5420 / 5440 SoCs support. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- Documentation/devicetree/bindings/video/exynos_dsim.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt b/Documentation/devicetree/bindings/video/exynos_dsim.txt index 33b5730..31036c6 100644 --- a/Documentation/devicetree/bindings/video/exynos_dsim.txt +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt @@ -1,7 +1,9 @@ Exynos MIPI DSI Master Required properties: - - compatible: "samsung,exynos4210-mipi-dsi" + - compatible: value should be one of the following + "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */ + "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */ - reg: physical base address and length of the registers set for the device - interrupts: should contain DSI interrupt - clocks: list of clock specifiers, must contain an entry for each required -- 1.9.0
[PATCH v5 06/14] drm/exynos: fimd: support LCD I80 interface
To support MIPI command mode based I80 interface panel,
FIMD should do followings:
- Sets LCD I80 interface timings configuration.
- Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
- Sets LCD block configuration for I80 interface.
- Sets ideal(pixel) clock is 2 times faster than the original one
to generate frame done IRQ prior to the next TE signal.
- Implements trigger feature that transfers image data if there is page
flip request, and implements TE handler to call trigger function.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 276 ++-
include/video/samsung_fimd.h | 3 +-
3 files changed, 235 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 178d2a9..9ba1aae 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -28,6 +28,7 @@ config DRM_EXYNOS_FIMD
bool "Exynos DRM FIMD"
depends on DRM_EXYNOS && !FB_S3C
select FB_MODE_HELPERS
+ select MFD_SYSCON
help
Choose this option if you want to use Exynos FIMD for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..207872d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -20,6 +20,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -61,6 +63,24 @@
/* color key value register for hardware window 1 ~ 4. */
#define WKEYCON1_BASE(x) ((WKEYCON1 + 0x140) + ((x - 1) * 8))
+/* I80 / RGB trigger control register */
+#define TRIGCON0x1A4
+#define TRGMODE_I80_RGB_ENABLE_I80 (1 << 0)
+#define SWTRGCMD_I80_RGB_ENABLE(1 << 1)
+
+/* display mode change control register except exynos4 */
+#define VIDOUT_CON 0x000
+#define VIDOUT_CON_F_I80_LDI0 (0x2 << 8)
+
+/* I80 interface control for main LDI register */
+#define I80IFCONFAx(x) (0x1B0 + (x) * 4)
+#define I80IFCONFBx(x) (0x1B8 + (x) * 4)
+#define LCD_CS_SETUP(x)((x) << 16)
+#define LCD_WR_SETUP(x)((x) << 12)
+#define LCD_WR_ACTIVE(x) ((x) << 8)
+#define LCD_WR_HOLD(x) ((x) << 4)
+#define I80IFEN_ENABLE (1 << 0)
+
/* FIMD has totally five hardware windows. */
#define WINDOWS_NR 5
@@ -68,10 +88,14 @@
struct fimd_driver_data {
unsigned int timing_base;
+ unsigned int lcdblk_offset;
+ unsigned int lcdblk_vt_shift;
+ unsigned int lcdblk_bypass_shift;
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+ unsigned int has_vidoutcon:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -82,12 +106,19 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data = {
static struct fimd_driver_data exynos4_fimd_driver_data = {
.timing_base = 0x0,
+ .lcdblk_offset = 0x210,
+ .lcdblk_vt_shift = 10,
+ .lcdblk_bypass_shift = 1,
.has_shadowcon = 1,
};
static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
+ .lcdblk_offset = 0x214,
+ .lcdblk_vt_shift = 24,
+ .lcdblk_bypass_shift = 15,
.has_shadowcon = 1,
+ .has_vidoutcon = 1,
};
struct fimd_win_data {
@@ -112,15 +143,22 @@ struct fimd_context {
struct clk *bus_clk;
struct clk *lcd_clk;
void __iomem*regs;
+ struct regmap *sysreg;
struct drm_display_mode mode;
struct fimd_win_datawin_data[WINDOWS_NR];
unsigned intdefault_win;
unsigned long irq_flags;
+ u32 vidcon0;
u32 vidcon1;
+ u32 vidout_con;
+ u32 i80ifcon;
+ booli80_if;
boolsuspended;
int pipe;
wait_queue_head_t wait_vsync_queue;
atomic_twait_vsync_event;
+ atomic_twin_updated;
+ atomic_ttriggering;
struct exynos_drm_panel_info panel;
struct fimd_driver_data *driver_data;
@@ -243,6 +281,14 @@ static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
unsigned long ideal_clk = mode->htotal * mode->vtotal * mode->vrefresh;
u32 clkdiv;
+ if (ctx->i80_if) {
+ /*
+* The frame done interrupt should be occur
[PATCH v5 05/14] drm/exynos: dsi: add pass TE host ops to support LCD I80 interface
To support LCD I80 interface, the DSI host calls this function
to notify the panel tearing effect synchronization signal to
the CRTC device manager to trigger to transfer video image.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 11 +++
include/drm/drm_mipi_dsi.h | 7 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index dad543a..76e34ca 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -24,6 +24,7 @@
#include
#include
+#include "exynos_drm_crtc.h"
#include "exynos_drm_drv.h"
/* returns true iff both arguments logically differs */
@@ -1041,10 +1042,20 @@ static ssize_t exynos_dsi_host_transfer(struct
mipi_dsi_host *host,
return (ret < 0) ? ret : xfer.rx_done;
}
+static void exynos_dsi_host_pass_te(struct mipi_dsi_host *host)
+{
+ struct exynos_dsi *dsi = host_to_dsi(host);
+ struct drm_encoder *encoder = dsi->encoder;
+
+ if (dsi->state & DSIM_STATE_ENABLED)
+ exynos_drm_crtc_te_handler(encoder->crtc);
+}
+
static const struct mipi_dsi_host_ops exynos_dsi_ops = {
.attach = exynos_dsi_host_attach,
.detach = exynos_dsi_host_detach,
.transfer = exynos_dsi_host_transfer,
+ .pass_te = exynos_dsi_host_pass_te,
};
static int exynos_dsi_poweron(struct exynos_dsi *dsi)
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 944f33f..3f21bea 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -49,6 +49,12 @@ struct mipi_dsi_msg {
* @detach: detach DSI device from DSI host
* @transfer: send and/or receive DSI packet, return number of received bytes,
* or error
+ * @pass_te: call the crtc te_handler() callback from DSI host.
+ * The panel generates tearing effect synchronization signal between
+ * MCU and FB to display video images. And the display controller
+ * should trigger to transfer video image at this signal. So the panel
+ * receives the TE IRQ, then calls this function to notify it to the
+ * display controller.
*/
struct mipi_dsi_host_ops {
int (*attach)(struct mipi_dsi_host *host,
@@ -57,6 +63,7 @@ struct mipi_dsi_host_ops {
struct mipi_dsi_device *dsi);
ssize_t (*transfer)(struct mipi_dsi_host *host,
struct mipi_dsi_msg *msg);
+ void (*pass_te)(struct mipi_dsi_host *host);
};
/**
--
1.9.0
[PATCH v5 04/14] drm/exynos: add TE handler to support LCD I80 interface
To support LCD I80 interface, the panel should generate
Tearing Effect synchronization signal between MCU and FB
to display video images.
And the display controller should trigger to transfer
video image at this signal.
So the panel receives the TE IRQ, then calls these handler
chains to notify it to the display controller.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 +++
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 +++
3 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 3bf091d..b68e58f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -511,3 +511,11 @@ int exynos_drm_crtc_get_pipe_from_type(struct drm_device
*drm_dev,
return -EPERM;
}
+
+void exynos_drm_crtc_te_handler(struct drm_crtc *crtc)
+{
+ struct exynos_drm_manager *manager = to_exynos_crtc(crtc)->manager;
+
+ if (manager->ops->te_handler)
+ manager->ops->te_handler(manager);
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 9f74b10..690dcdd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -36,4 +36,11 @@ void exynos_drm_crtc_plane_disable(struct drm_crtc *crtc,
int zpos);
int exynos_drm_crtc_get_pipe_from_type(struct drm_device *drm_dev,
unsigned int out_type);
+/*
+ * This function calls the crtc device(manager)'s te_handler() callback
+ * to trigger to transfer video image at the tearing effect synchronization
+ * signal.
+ */
+void exynos_drm_crtc_te_handler(struct drm_crtc *crtc);
+
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 06cde45..d4e0726 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -188,6 +188,8 @@ struct exynos_drm_display {
* @win_commit: apply hardware specific overlay data to registers.
* @win_enable: enable hardware specific overlay.
* @win_disable: disable hardware specific overlay.
+ * @te_handler: trigger to transfer video image at the tearing effect
+ * synchronization signal if there is a page flip request.
*/
struct exynos_drm_manager;
struct exynos_drm_manager_ops {
@@ -206,6 +208,7 @@ struct exynos_drm_manager_ops {
void (*win_commit)(struct exynos_drm_manager *mgr, int zpos);
void (*win_enable)(struct exynos_drm_manager *mgr, int zpos);
void (*win_disable)(struct exynos_drm_manager *mgr, int zpos);
+ void (*te_handler)(struct exynos_drm_manager *mgr);
};
/*
--
1.9.0
[PATCH v5 03/14] ARM: dts: samsung-fimd: add LCD I80 interface specific properties
In case of using MIPI DSI based I80 interface panel, the relevant registers should be set. So this patch adds relevant DT bindings. Signed-off-by: YoungJun Cho Acked-by: Inki Dae Acked-by: Kyungmin Park --- .../devicetree/bindings/video/samsung-fimd.txt | 28 ++ 1 file changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt index 2dad41b..59ff61e 100644 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt @@ -44,6 +44,34 @@ Optional Properties: - display-timings: timing settings for FIMD, as described in document [1]. Can be used in case timings cannot be provided otherwise or to override timings provided by the panel. +- samsung,sysreg: handle to syscon used to control the system registers +- i80-if-timings: timing configuration for lcd i80 interface support. + - cs-setup: clock cycles for the active period of address signal is enabled + until chip select is enabled. + If not specified, the default value(0) will be used. + - wr-setup: clock cycles for the active period of CS signal is enabled until + write signal is enabled. + If not specified, the default value(0) will be used. + - wr-active: clock cycles for the active period of CS is enabled. + If not specified, the default value(1) will be used. + - wr-hold: clock cycles for the active period of CS is disabled until write + signal is disabled. + If not specified, the default value(0) will be used. + + The parameters are defined as: + +VCLK(internal) __|??|_|??|_|??|_|??|_|?? + ::::: +Address Output --:|::: +Chip Select ???|::|?? + | wr-setup+1 || wr-hold+1 | + |<-->||<-->| +Write Enable||??? +| wr-active+1| +|<-->| +Video Data -- The device node can contain 'port' child nodes according to the bindings defined in [2]. The following are properties specific to those nodes: -- 1.9.0
[PATCH v5 02/14] drm/exynos: use wait_event_timeout() for safety usage
There could be the case that the page flip operation isn't finished correctly
with some abnormal condition such as panel reset. So this patch replaces
wait_event() with wait_event_timeout() to avoid waiting for page flip completion
infinitely.
And clears exynos_crtc->pending_flip in exynos_drm_crtc_page_flip()
when exynos_drm_crtc_mode_set_commit() is failed.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 95c9435..3bf091d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -69,8 +69,10 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int
mode)
if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
- wait_event(exynos_crtc->pending_flip_queue,
- atomic_read(&exynos_crtc->pending_flip) == 0);
+ if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
+ !atomic_read(&exynos_crtc->pending_flip),
+ HZ/20))
+ atomic_set(&exynos_crtc->pending_flip, 0);
drm_vblank_off(crtc->dev, exynos_crtc->pipe);
}
@@ -259,6 +261,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
spin_lock_irq(&dev->event_lock);
drm_vblank_put(dev, exynos_crtc->pipe);
list_del(&event->base.link);
+ atomic_set(&exynos_crtc->pending_flip, 0);
spin_unlock_irq(&dev->event_lock);
goto out;
--
1.9.0
[PATCH v5 01/14] drm/exynos: dsi: move the EoT packets configuration point
This configuration could be used in MIPI DSI command mode also.
And adds user manual description for display configuration.
Signed-off-by: YoungJun Cho
Acked-by: Inki Dae
Acked-by: Kyungmin Park
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 6302aa6..dad543a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -468,13 +468,19 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
/* DSI configuration */
reg = 0;
+ /* The first bit of mode_flags specifies display configuration.
+* If this bit is set[= MIPI_DSI_MODE_VIDEO], dsi will support video
+* mode, otherwise it will support command mode.
+*/
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
reg |= DSIM_VIDEO_MODE;
+ /*
+* The user manual describes that following bits are ignored in
+* command mode.
+*/
if (!(dsi->mode_flags & MIPI_DSI_MODE_VSYNC_FLUSH))
reg |= DSIM_MFLUSH_VS;
- if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
- reg |= DSIM_EOT_DISABLE;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
reg |= DSIM_SYNC_INFORM;
if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
@@ -491,6 +497,9 @@ static int exynos_dsi_init_link(struct exynos_dsi *dsi)
reg |= DSIM_HSA_MODE;
}
+ if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
+ reg |= DSIM_EOT_DISABLE;
+
switch (dsi->format) {
case MIPI_DSI_FMT_RGB888:
reg |= DSIM_MAIN_PIX_FORMAT_RGB888;
--
1.9.0
[PATCH v5 00/14] drm/exynos: support LCD I80 interface display
Hi, This series adds LCD I80 interface display support for Exynos DRM driver. The FIMD(display controller) specification describes it as "LCD I80 interface" and the DSI specification describes it as "Command mode interface". This is based on exynos-drm-next branch. The previous patches, RFC: http://www.spinics.net/lists/dri-devel/msg58898.html V1: http://www.spinics.net/lists/dri-devel/msg59291.html V2: http://www.spinics.net/lists/dri-devel/msg59867.html V3: http://www.spinics.net/lists/dri-devel/msg60708.html V4: http://www.spinics.net/lists/dri-devel/msg60943.html Changelog v2: - Fixes typo and removes unnecessary error log (commented by Andrzej Hazda) - Adds missed pendlig_flip flag clear points (commented by Daniel Kurtz) Changelog v3: - Removes generic command mode and command mode display timing interface. - Moves I80 interface timings from panel DT to the FIMD(display controller) DT. Changelog v4: - Removes exynos5 sysreg(syscon) DT bindings and node from dtsi because it was already updated by linux-samsung-soc (commented by Vivek Gautam) Changelog v5: - Fixes FIMD vidcon0 register relevant code - Fixes panel gamma table, disable sequence - Slitely updates for code cleanup Patches 1 and 2 fix trivial bugs. Patches 3, 4, 5 and 6 implement FIMD(display controller) I80 interface. The MIPI DSI command mode based panel generates Tearing Effect synchronization signal between MCU and FB to display video image, and FIMD should trigger to transfer video image at this signal. So the panel should receive the TE IRQ and call TE handler chains to notify it to the FIMD. Patches 7 and 8 implement to use Exynos5410 / 5420 / 5440 SoC DSI driver which is different from previous Exynos4 SoCs for some registers control. Patches 9 and 10 introduce MIPI DSI command mode based Samsung S6E3FA0 AMOLED 5.7" LCD drm panel driver. The ohters add DT property nodes to support MIPI DSI command mode. I welcome any comments. Thank you. Best regards YJ YoungJun Cho (14): drm/exynos: dsi: move the EoT packets configuration point drm/exynos: use wait_event_timeout() for safety usage ARM: dts: samsung-fimd: add LCD I80 interface specific properties drm/exynos: add TE handler to support LCD I80 interface drm/exynos: dsi: add pass TE host ops to support LCD I80 interface drm/exynos: fimd: support LCD I80 interface ARM: dts: exynos_dsim: add exynos5410 compatible to DT bindings drm/exynos: dsi: add driver data to support Exynos5410/5420/5440 SoCs ARM: dts: s6e3fa0: add DT bindings drm/panel: add S6E3FA0 driver ARM: dts: exynos4: add system register property ARM: dts: exynos5: add system register property ARM: dts: exynos5420: add mipi-phy node ARM: dts: exynos5420: add dsi node .../devicetree/bindings/panel/samsung,s6e3fa0.txt | 46 ++ .../devicetree/bindings/video/exynos_dsim.txt | 4 +- .../devicetree/bindings/video/samsung-fimd.txt | 28 + arch/arm/boot/dts/exynos4.dtsi | 1 + arch/arm/boot/dts/exynos5.dtsi | 1 + arch/arm/boot/dts/exynos5420.dtsi | 20 + drivers/gpu/drm/exynos/Kconfig | 1 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 15 +- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 + drivers/gpu/drm/exynos/exynos_drm_drv.h| 3 + drivers/gpu/drm/exynos/exynos_drm_dsi.c| 181 ++- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 276 -- drivers/gpu/drm/panel/Kconfig | 7 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-s6e3fa0.c | 569 + include/drm/drm_mipi_dsi.h | 7 + include/video/samsung_fimd.h | 3 +- 17 files changed, 1098 insertions(+), 72 deletions(-) create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c -- 1.9.0
[PATCH] drm: reduce default drm vblank off delay to 50ms
On Tue, 8 Jul 2014 15:56:04 +0200 Daniel Vetter wrote: > On Wed, Jul 02, 2014 at 01:42:38PM -0700, Jesse Barnes wrote: > > On Wed, 2 Jul 2014 13:35:19 -0700 > > St?phane Marchesin wrote: > > > > > On Tue, Oct 30, 2012 at 12:20 PM, Daniel Vetter > > > wrote: > > > > On Tue, Oct 30, 2012 at 8:09 PM, Jesse Barnes > > > virtuousgeek.org> wrote: > > > >> People keep whining about this, but no one seems to send a patch. This > > > >> *ought* to be safe now that we've dealt with the hw races in Mario's > > > >> updated code, and fixed the bugs we know about in VT switch, DPMS, and > > > >> multi-head configuraions. > > > >> > > > >> Signed-off-by: Jesse Barnes > > > > > > > > Afaik the fundamental race of enabling the vblank is still there, so > > > > this is just duct-tape. And our hw has the required registers (on > > > > gen5+ at least) to close this race for real and abolish all "disable > > > > vblank irq later to paper over races and smooth things out). Hence I > > > > think we should dtrt and so > > > > > > [digging an old thread] > > > > > > So I'm looking at this machine where we can't get good PSR residency > > > because the vblank_offdelay is so long. Therefore, I'm suddenly very > > > interested in solving this issue :) Of course I can't seem to find > > > logs of the fun IRC discussion you guys had, can you describe what the > > > race is, and also what are the registers you're talking about? > > > > Beyond that I don't see why this obvious and simple improvement should > > be blocked on some other work. Maybe it's a bit late now since Ville > > may already have patches for what Daniel mentions above, but I still > > find the nack to be totally misguided. > > > > Dave, please just pick this up so everyone can benefit while we thrash > > through an i915 fix (doubtless introducing some bugs) that lets us > > disable immediately. > > This needs an ack from Mario. > > And I really don't see why we _now_ need to suddenly rush then when we > have patches from Ville to address this properly. The blocker is only that > it's not yet reviewed but meh. > > And people with product ship dates looming over their head can always just > apply this themselves. > > Us sucking at reviewing is imo no reason at all to rush patches in. This is just the most recent version: http://lists.freedesktop.org/archives/dri-devel/2012-October/029648.html IIRC there was one posted back in 2010 too. So hardly rushing. -- Jesse Barnes, Intel Open Source Technology Center
[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support
Hello Rob,
On Mon, 7 Jul 2014 23:45:54 -0400
Rob Clark wrote:
> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON
> wrote:
> > The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
> > at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
> > controller device.
> >
> > This display controller supports at least one primary plane and might
> > provide several overlays and an hardware cursor depending on the IP
> > version.
> >
> > At the moment, this driver only implements an RGB connector to interface
> > with LCD panels, but support for other kind of external devices (like DRM
> > bridges) might be added later.
> >
> > Signed-off-by: Boris BREZILLON
> > ---
> > drivers/gpu/drm/Kconfig | 2 +
> > drivers/gpu/drm/Makefile| 1 +
> > drivers/gpu/drm/atmel-hlcdc/Kconfig | 11 +
> > drivers/gpu/drm/atmel-hlcdc/Makefile| 7 +
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 469 +++
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 474 +++
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 210 +++
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 706
> > +++
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h | 422 ++
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c | 351
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 729
> >
> > 11 files changed, 3382 insertions(+)
> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c
> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index d1cc2f6..df6f0c1 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -182,6 +182,8 @@ source "drivers/gpu/drm/cirrus/Kconfig"
[...]
> > +
> > +/**
> > + * Atmel HLCDC Plane properties.
> > + *
> > + * This structure stores plane property definitions.
> > + *
> > + * @alpha: alpha blending (or transparency) property
> > + * @csc: YUV to RGB conversion factors property
> > + */
> > +struct atmel_hlcdc_plane_properties {
> > + struct drm_property *alpha;
> > + struct drm_property *csc;
>
> appears like csc is not used yet, so I suppose you can drop it for
> now.. when you do add it, don't forget to update drm.tmp. But for
> now it at least makes review easier when the driver doesn't add new
> userspace interfaces :-)
Sure, I guess this is a leftover from another patch I made to add Color
Space Conversion configuration.
I'll remove it for the next version.
>
> > +};
> > +
> > +/**
> > + * Atmel HLCDC Plane.
> > + *
> > + * @base: base DRM plane structure
> > + * @layer: HLCDC layer structure
> > + * @properties: pointer to the property definitions structure
> > + * @alpha: current alpha blending (or transparency) status
> > + */
> > +struct atmel_hlcdc_plane {
> > + struct drm_plane base;
> > + struct atmel_hlcdc_layer layer;
> > + struct atmel_hlcdc_plane_properties *properties;
> > +};
> > +
> > +static inline struct atmel_hlcdc_plane *
> > +drm_plane_to_atmel_hlcdc_plane(struct drm_plane *p)
> > +{
> > + return container_of(p, struct atmel_hlcdc_plane, base);
> > +}
> > +
> > +static inline struct atmel_hlcdc_plane *
> > +atmel_hlcdc_layer_to_plane(struct atmel_hlcdc_layer *l)
> > +{
> > + return container_of(l, struct atmel_hlcdc_plane, layer);
> > +}
> > +
> > +/**
> > + * Atmel HLCDC Plane update request structure.
> > + *
> > + * @crtc_x: x position of the plane relative to the CRTC
> > + * @crtc_y: y position of the plane relative to the CRTC
> > + * @crtc_w: visible width of the plane
> > + * @crtc_h: visible height of the plane
> > + * @src_x: x buffer position
> > + * @src_y: y buffer position
> > + * @src_w: buffer width
> > + * @src_h: buffer height
> > + * @pixel_format: pixel format
> > + * @gems: GEM object object containing image buffers
> > + * @offsets: offsets to apply to the GEM buffers
> > + * @pitches: line size in bytes
> > + * @crtc: crtc to display on
> > + * @finished: finished callback
> > + * @finished_data: data passed to the finished callback
> > + * @bpp: bytes per pixel deduced from pixel_format
> > + * @xstride: value to add to the pixel pointer between each line
> > + * @pstride: value to add to the pixel pointer between each pixel
> > + * @nplanes: number of planes (deduced from pixel_format)
> > + */
> > +str
[PATCH 2/2] drm/udl: Implement page_flip ioctl
Hi
On Tue, Jul 8, 2014 at 9:17 AM, Dave Airlie wrote:
> On 8 July 2014 17:15, David Herrmann wrote:
>> Hi
>>
>> On Thu, Jul 3, 2014 at 12:13 AM, St?phane Marchesin
>> wrote:
>>> This is a very crude page_flip implementation for UDL. There are ways
>>> to make it better (make it asynchronous, make it do actual vsynced
>>> flips...) but that's for another patch.
>>>
>>> Signed-off-by: St?phane Marchesin
>>> ---
>>> drivers/gpu/drm/udl/udl_modeset.c | 21 +
>>> 1 file changed, 21 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
>>> b/drivers/gpu/drm/udl/udl_modeset.c
>>> index cddc4fc..7dc3bd8 100644
>>> --- a/drivers/gpu/drm/udl/udl_modeset.c
>>> +++ b/drivers/gpu/drm/udl/udl_modeset.c
>>> @@ -363,6 +363,26 @@ static void udl_crtc_destroy(struct drm_crtc *crtc)
>>> kfree(crtc);
>>> }
>>>
>>> +static int udl_crtc_page_flip(struct drm_crtc *crtc,
>>> + struct drm_framebuffer *fb,
>>> + struct drm_pending_vblank_event *event,
>>> + uint32_t page_flip_flags)
>>> +{
>>> + struct udl_framebuffer *ufb = to_udl_fb(fb);
>>> + struct drm_device *dev = crtc->dev;
>>> + unsigned long flags;
>>> +
>>> + udl_handle_damage(ufb, 0, 0, fb->width, fb->height);
>>> +
>>> + spin_lock_irqsave(&dev->event_lock, flags);
>>> + if (event)
>>> + drm_send_vblank_event(dev, 0, event);
>>> + spin_unlock_irqrestore(&dev->event_lock, flags);
>>> + crtc->fb = fb;
>>
>> Doesn't this break user-space that expects page-flip events to not
>> occur more often than the refresh-rate? For instance, weston
>> re-renders on each page-flip event. With this patch, it will never
>> sleep on udl as it immediately gets the page-flip event back?
>
> I don't think you can update the USB device quicker than the refresh rate :-P
>
> though that might change if we ever get USB3!
Fair enough. I will keep it in mind and if something turns up, we can
always add a 60Hz software-timer.
Thanks
David
[PATCH 2/2] drm/udl: Implement page_flip ioctl
Hi
On Thu, Jul 3, 2014 at 12:13 AM, St?phane Marchesin
wrote:
> This is a very crude page_flip implementation for UDL. There are ways
> to make it better (make it asynchronous, make it do actual vsynced
> flips...) but that's for another patch.
>
> Signed-off-by: St?phane Marchesin
> ---
> drivers/gpu/drm/udl/udl_modeset.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> b/drivers/gpu/drm/udl/udl_modeset.c
> index cddc4fc..7dc3bd8 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -363,6 +363,26 @@ static void udl_crtc_destroy(struct drm_crtc *crtc)
> kfree(crtc);
> }
>
> +static int udl_crtc_page_flip(struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event,
> + uint32_t page_flip_flags)
> +{
> + struct udl_framebuffer *ufb = to_udl_fb(fb);
> + struct drm_device *dev = crtc->dev;
> + unsigned long flags;
> +
> + udl_handle_damage(ufb, 0, 0, fb->width, fb->height);
> +
> + spin_lock_irqsave(&dev->event_lock, flags);
> + if (event)
> + drm_send_vblank_event(dev, 0, event);
> + spin_unlock_irqrestore(&dev->event_lock, flags);
> + crtc->fb = fb;
Doesn't this break user-space that expects page-flip events to not
occur more often than the refresh-rate? For instance, weston
re-renders on each page-flip event. With this patch, it will never
sleep on udl as it immediately gets the page-flip event back?
Thanks
David
> +
> + return 0;
> +}
> +
> static void udl_crtc_prepare(struct drm_crtc *crtc)
> {
> }
> @@ -384,6 +404,7 @@ static struct drm_crtc_helper_funcs udl_helper_funcs = {
> static const struct drm_crtc_funcs udl_crtc_funcs = {
> .set_config = drm_crtc_helper_set_config,
> .destroy = udl_crtc_destroy,
> + .page_flip = udl_crtc_page_flip,
> };
>
> static int udl_crtc_init(struct drm_device *dev)
> --
> 2.0.0.526.g5318336
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v3 05/11] drm: add Atmel HLCDC Display Controller support
On Tue, Jul 8, 2014 at 3:23 AM, Boris BREZILLON
wrote:
> Hello Rob,
>
> On Mon, 7 Jul 2014 23:45:54 -0400
> Rob Clark wrote:
>
>> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON
>> wrote:
>> > The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
>> > at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
>> > controller device.
>> >
>> > This display controller supports at least one primary plane and might
>> > provide several overlays and an hardware cursor depending on the IP
>> > version.
>> >
>> > At the moment, this driver only implements an RGB connector to interface
>> > with LCD panels, but support for other kind of external devices (like DRM
>> > bridges) might be added later.
>> >
>> > Signed-off-by: Boris BREZILLON
>> > ---
>> > drivers/gpu/drm/Kconfig | 2 +
>> > drivers/gpu/drm/Makefile| 1 +
>> > drivers/gpu/drm/atmel-hlcdc/Kconfig | 11 +
>> > drivers/gpu/drm/atmel-hlcdc/Makefile| 7 +
>> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 469 +++
>> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 474 +++
>> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 210 +++
>> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c | 706
>> > +++
>> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h | 422 ++
>> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c | 351
>> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 729
>> >
>> > 11 files changed, 3382 insertions(+)
>> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
>> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
>> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
>> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
>> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
>> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
>> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
>> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_panel.c
>> > create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
>> >
>> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> > index d1cc2f6..df6f0c1 100644
>> > --- a/drivers/gpu/drm/Kconfig
>> > +++ b/drivers/gpu/drm/Kconfig
>> > @@ -182,6 +182,8 @@ source "drivers/gpu/drm/cirrus/Kconfig"
>
> [...]
>
>> > +
>> > +/**
>> > + * Atmel HLCDC Plane properties.
>> > + *
>> > + * This structure stores plane property definitions.
>> > + *
>> > + * @alpha: alpha blending (or transparency) property
>> > + * @csc: YUV to RGB conversion factors property
>> > + */
>> > +struct atmel_hlcdc_plane_properties {
>> > + struct drm_property *alpha;
>> > + struct drm_property *csc;
>>
>> appears like csc is not used yet, so I suppose you can drop it for
>> now.. when you do add it, don't forget to update drm.tmp. But for
>> now it at least makes review easier when the driver doesn't add new
>> userspace interfaces :-)
>
>
> Sure, I guess this is a leftover from another patch I made to add Color
> Space Conversion configuration.
>
> I'll remove it for the next version.
>
>>
>> > +};
>> > +
>> > +/**
>> > + * Atmel HLCDC Plane.
>> > + *
>> > + * @base: base DRM plane structure
>> > + * @layer: HLCDC layer structure
>> > + * @properties: pointer to the property definitions structure
>> > + * @alpha: current alpha blending (or transparency) status
>> > + */
>> > +struct atmel_hlcdc_plane {
>> > + struct drm_plane base;
>> > + struct atmel_hlcdc_layer layer;
>> > + struct atmel_hlcdc_plane_properties *properties;
>> > +};
>> > +
>> > +static inline struct atmel_hlcdc_plane *
>> > +drm_plane_to_atmel_hlcdc_plane(struct drm_plane *p)
>> > +{
>> > + return container_of(p, struct atmel_hlcdc_plane, base);
>> > +}
>> > +
>> > +static inline struct atmel_hlcdc_plane *
>> > +atmel_hlcdc_layer_to_plane(struct atmel_hlcdc_layer *l)
>> > +{
>> > + return container_of(l, struct atmel_hlcdc_plane, layer);
>> > +}
>> > +
>> > +/**
>> > + * Atmel HLCDC Plane update request structure.
>> > + *
>> > + * @crtc_x: x position of the plane relative to the CRTC
>> > + * @crtc_y: y position of the plane relative to the CRTC
>> > + * @crtc_w: visible width of the plane
>> > + * @crtc_h: visible height of the plane
>> > + * @src_x: x buffer position
>> > + * @src_y: y buffer position
>> > + * @src_w: buffer width
>> > + * @src_h: buffer height
>> > + * @pixel_format: pixel format
>> > + * @gems: GEM object object containing image buffers
>> > + * @offsets: offsets to apply to the GEM buffers
>> > + * @pitches: line size in bytes
>> > + * @crtc: crtc to display on
>> > + * @finished: finished callback
>> > + * @finished_data: data passed to the finished callback
>> > + * @bpp: bytes per pixel deduced from pixel_format
>> > + * @xstride: value to add to
[PATCH 2/2] drm/udl: Implement page_flip ioctl
On Wed, Jul 02, 2014 at 03:13:43PM -0700, St?phane Marchesin wrote:
> This is a very crude page_flip implementation for UDL. There are ways
> to make it better (make it asynchronous, make it do actual vsynced
> flips...) but that's for another patch.
>
> Signed-off-by: St?phane Marchesin
> ---
> drivers/gpu/drm/udl/udl_modeset.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/udl/udl_modeset.c
> b/drivers/gpu/drm/udl/udl_modeset.c
> index cddc4fc..7dc3bd8 100644
> --- a/drivers/gpu/drm/udl/udl_modeset.c
> +++ b/drivers/gpu/drm/udl/udl_modeset.c
> @@ -363,6 +363,26 @@ static void udl_crtc_destroy(struct drm_crtc *crtc)
> kfree(crtc);
> }
>
> +static int udl_crtc_page_flip(struct drm_crtc *crtc,
> + struct drm_framebuffer *fb,
> + struct drm_pending_vblank_event *event,
> + uint32_t page_flip_flags)
> +{
> + struct udl_framebuffer *ufb = to_udl_fb(fb);
> + struct drm_device *dev = crtc->dev;
> + unsigned long flags;
> +
> + udl_handle_damage(ufb, 0, 0, fb->width, fb->height);
Could we not save the damage from an earlier dirtyfb and limit the data
we have to send here?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH v2 0/9] Updated fence patch series
On Tue, Jul 08, 2014 at 03:44:27PM +0200, Daniel Vetter wrote: > On Mon, Jul 07, 2014 at 10:30:52AM -0700, Greg KH wrote: > > On Mon, Jul 07, 2014 at 03:23:17PM +0200, Daniel Vetter wrote: > > > On Wed, Jul 2, 2014 at 7:37 AM, Greg KH > > > wrote: > > > >> Android can expose fences to userspace. It's possible to make the new > > > >> fence > > > >> mechanism expose the same fences to userspace by changing > > > >> sync_fence_create > > > >> to take a struct fence instead of a struct sync_pt. No other change is > > > >> needed, > > > >> because only the fence parts of struct sync_pt are used. But because > > > >> the > > > >> userspace fences are a separate problem and I haven't really looked at > > > >> it yet > > > >> I feel it should stay in staging, for now. > > > > > > > > Ok, that's reasonable. > > > > > > > > At first glance, this all looks "sane" to me, any objection from anyone > > > > if I merge this through my driver-core tree for 3.17? > > > > > > Ack from my side fwiw. > > > > Thanks, I'll queue it up later today. > > btw should we add you as a (co)maintainer for driver/core/dma-buf since > you seem to want to keep a closer tab on what the insane gfx folks are up > to in there? Sure, why not, what's one more maintainership... Oh, does that mean you want me to be the one collecting the patches and forwarding them on to Linus? If so, that's fine, I can easily do that as well due to my infrastructure being set up for it. thanks, greg k-h
linux-next: Tree for Jun 19 (drm/i915)
On Monday, July 07, 2014 11:49:22 PM Rafael J. Wysocki wrote: > On Monday, July 07, 2014 10:06:59 PM Daniel Vetter wrote: > > On Mon, Jul 07, 2014 at 10:01:27PM +0200, Rafael J. Wysocki wrote: > > > On Monday, July 07, 2014 04:54:23 PM Daniel Vetter wrote: > > > > On Wed, Jun 25, 2014 at 01:01:36AM +0200, Rafael J. Wysocki wrote: > > > > > On Tuesday, June 24, 2014 02:43:02 PM Jani Nikula wrote: > > > > > > On Thu, 19 Jun 2014, Randy Dunlap wrote: > > > > > > > On 06/18/14 23:16, Stephen Rothwell wrote: > > > > > > >> Hi all, > > > > > > >> > > > > > > >> The powerpc allyesconfig is again broken more than usual. > > > > > > >> > > > > > > >> Changes since 20140618: > > > > > > >> > > > > > > > > > > > > > > on i386: > > > > > > > > > > > > > > CONFIG_ACPI is not enabled. > > > > > > > > > > > > > > CC drivers/gpu/drm/i915/i915_drv.o > > > > > > > ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_freeze': > > > > > > > ../drivers/gpu/drm/i915/i915_drv.c:547:2: error: implicit > > > > > > > declaration of function 'acpi_target_system_state' > > > > > > > [-Werror=implicit-function-declaration] > > > > > > > ../drivers/gpu/drm/i915/i915_drv.c:547:36: error: 'ACPI_STATE_S3' > > > > > > > undeclared (first use in this function) > > > > > > > ../drivers/gpu/drm/i915/i915_drv.c:547:36: note: each undeclared > > > > > > > identifier is reported only once for each function it appears in > > > > > > > CC net/dccp/qpolicy.o > > > > > > > cc1: some warnings being treated as errors > > > > > > > make[5]: *** [drivers/gpu/drm/i915/i915_drv.o] Error 1 > > > > > > > > > > > > Thanks for the report, we'll fix it. > > > > > > > > > > > > Can anyone explain why include/linux/acpi_bus.h has #ifdef > > > > > > CONFIG_ACPI_SLEEP and conditional build for a dummy inline version > > > > > > of > > > > > > acpi_target_system_state(), *but* that does not get included or > > > > > > used if > > > > > > CONFIG_ACPI=n? Additionally, the combination of CONFIG_ACPI=y and > > > > > > CONFIG_ACPI_SLEEP=n does not seem to work at all. > > > > > > > > > > These two things look like bugs to me. Most likely not tested > > > > > thoruoughly > > > > > enough. > > > > > > > > > > > So we'll really have to sprinkle #ifdef CONFIG_ACPI all over, > > > > > > instead of > > > > > > neatly using the dummy versions that someone has gone through the > > > > > > trouble of adding? > > > > > > > > > > No, we don't have to. > > > > > > > > Back from my vacation and I didn't see a conclusion to this issue here. > > > > Rafael, have you fixed this in your acpi tree or do I need to do > > > > something > > > > in drm-intel? > > > > > > I was on vacation too. :-) > > > > > > Please have a look if i915 includes acpi/acpi_bus.h directly anywhere. > > > If so, > > > it should include linux/acpi.h instead. I'll fix up the rest in the ACPI > > > tree. > > > > We seem to only use linux/acpi.h and acpi/(video|button).h, at least > > according to a grep include.*acpi. So I think we're good in i915 land. > > Thanks for taking care of this. > > The patch below should fix this if I'm not mistaken. So I was mistaken, as it turns out. The problem is that ACPI sleep states are not defined for CONFIG_ACPI unset, quite obviously, so using acpi_target_system_state() in that case doesn't make sense at all. Rafael
[Bug 80868] Support screen scaling modes for external monitors
20 1760 1980 720 725 730 750 +hsync +vsync (37.5 kHz e) Jul 08 03:02:40 rawhide kernel: [drm:drm_calc_timestamping_constants] *ERROR* crtc 14: Can't calculate constants, dotclock = 0! The last line seems important. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140708/7f143ca6/attachment.html>
[Bug 81020] [radeonsi][regresssion] Wireframe of background rendered through objects in Half-Life 2: Episode 2 with MSAA enabled
https://bugs.freedesktop.org/show_bug.cgi?id=81020 --- Comment #5 from Daniel Scharrer --- Yes, the attached patch fixes the issue for me. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140708/cbca34e4/attachment.html>
[PATCH] drm: Remove command line guard for render nodes (v2)
Hi On Tue, Jul 8, 2014 at 12:28 AM, Alex Deucher wrote: > On Mon, Jul 7, 2014 at 6:20 PM, David Herrmann > wrote: >> Hi >> >> On Tue, Jul 8, 2014 at 12:10 AM, Alex Deucher >> wrote: >>> Render nodes are ready to leave the experimental state so >>> drop the kernel command line parameter which was hiding them >>> by default. I swore we had already enabled these by default, >>> that appears to not be the case. >>> >>> v2: remove rnodes parameter description >>> >>> Signed-off-by: Alex Deucher >> >> For completeness: >> You still missed the line in drmP.h. I have it queued in my -next branch [1]. >> > > Thanks! Feel free to add my Acked-by. Added! Thanks! David
[PATCH] drm: Remove command line guard for render nodes (v2)
Hi
On Tue, Jul 8, 2014 at 12:10 AM, Alex Deucher wrote:
> Render nodes are ready to leave the experimental state so
> drop the kernel command line parameter which was hiding them
> by default. I swore we had already enabled these by default,
> that appears to not be the case.
>
> v2: remove rnodes parameter description
>
> Signed-off-by: Alex Deucher
For completeness:
You still missed the line in drmP.h. I have it queued in my -next branch [1].
Thanks
David
[1]
http://cgit.freedesktop.org/~dvdhrm/linux/commit/?h=drm-next&id=c006394362a28e4949046cd0ce1fbc568e914861
> ---
> drivers/gpu/drm/drm_stub.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index 14d1646..07bf701 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -37,9 +37,6 @@
> unsigned int drm_debug = 0;/* 1 to enable debug output */
> EXPORT_SYMBOL(drm_debug);
>
> -unsigned int drm_rnodes = 0; /* 1 to enable experimental render nodes API
> */
> -EXPORT_SYMBOL(drm_rnodes);
> -
> /* 1 to allow user space to request universal planes (experimental) */
> unsigned int drm_universal_planes = 0;
> EXPORT_SYMBOL(drm_universal_planes);
> @@ -60,13 +57,11 @@ MODULE_AUTHOR(CORE_AUTHOR);
> MODULE_DESCRIPTION(CORE_DESC);
> MODULE_LICENSE("GPL and additional rights");
> MODULE_PARM_DESC(debug, "Enable debug output");
> -MODULE_PARM_DESC(rnodes, "Enable experimental render nodes API");
> MODULE_PARM_DESC(vblankoffdelay, "Delay until vblank irq auto-disable
> [msecs]");
> MODULE_PARM_DESC(timestamp_precision_usec, "Max. error on timestamps
> [usecs]");
> MODULE_PARM_DESC(timestamp_monotonic, "Use monotonic timestamps");
>
> module_param_named(debug, drm_debug, int, 0600);
> -module_param_named(rnodes, drm_rnodes, int, 0600);
> module_param_named(universal_planes, drm_universal_planes, int, 0600);
> module_param_named(vblankoffdelay, drm_vblank_offdelay, int, 0600);
> module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
> 0600);
> @@ -588,7 +583,7 @@ struct drm_device *drm_dev_alloc(struct drm_driver
> *driver,
> goto err_minors;
> }
>
> - if (drm_core_check_feature(dev, DRIVER_RENDER) && drm_rnodes) {
> + if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
> if (ret)
> goto err_minors;
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Remove command line guard for render nodes
Hi
On Mon, Jul 7, 2014 at 11:25 PM, Alex Deucher wrote:
> Render nodes are ready to leave the experimental state so
> drop the kernel command line parameter which was hiding them
> by default. I swore we had already enabled these by default,
> that appears to not be the case.
>
> Signed-off-by: Alex Deucher
I did send this for 3.15 but it was never applied. I have it still
queued on my -next branch and Dave said he'll probably take it for the
next release. I will include it in my next pull request [1].
Thanks
David
[1] http://cgit.freedesktop.org/~dvdhrm/linux/log/?h=drm-next
> ---
> drivers/gpu/drm/drm_stub.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index 14d1646..0df920b 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -37,9 +37,6 @@
> unsigned int drm_debug = 0;/* 1 to enable debug output */
> EXPORT_SYMBOL(drm_debug);
>
> -unsigned int drm_rnodes = 0; /* 1 to enable experimental render nodes API
> */
> -EXPORT_SYMBOL(drm_rnodes);
> -
> /* 1 to allow user space to request universal planes (experimental) */
> unsigned int drm_universal_planes = 0;
> EXPORT_SYMBOL(drm_universal_planes);
> @@ -66,7 +63,6 @@ MODULE_PARM_DESC(timestamp_precision_usec, "Max. error on
> timestamps [usecs]");
> MODULE_PARM_DESC(timestamp_monotonic, "Use monotonic timestamps");
>
> module_param_named(debug, drm_debug, int, 0600);
> -module_param_named(rnodes, drm_rnodes, int, 0600);
> module_param_named(universal_planes, drm_universal_planes, int, 0600);
> module_param_named(vblankoffdelay, drm_vblank_offdelay, int, 0600);
> module_param_named(timestamp_precision_usec, drm_timestamp_precision, int,
> 0600);
> @@ -588,7 +584,7 @@ struct drm_device *drm_dev_alloc(struct drm_driver
> *driver,
> goto err_minors;
> }
>
> - if (drm_core_check_feature(dev, DRIVER_RENDER) && drm_rnodes) {
> + if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
> if (ret)
> goto err_minors;
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 81020] [radeonsi][regresssion] Wireframe of background rendered through objects in Half-Life 2: Episode 2 with MSAA enabled
https://bugs.freedesktop.org/show_bug.cgi?id=81020 --- Comment #4 from Marek Ol??k --- Created attachment 102399 --> https://bugs.freedesktop.org/attachment.cgi?id=102399&action=edit possible fix Does the attached patch fix the issue? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140708/6fea71e7/attachment.html>
