Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs
On Thu, Jan 11, 2018 at 02:05:31AM +, Hyun Kwon wrote:
> Hi Daniel,
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Tuesday, January 09, 2018 1:54 AM
> > To: Hyun Kwon
> > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Tejas
> > Upadhyay ; Michal Simek
> > Subject: Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs
> >
> > On Thu, Jan 04, 2018 at 06:05:59PM -0800, Hyun Kwon wrote:
> > > Debugfs can be used to exploit some specific setting. Main purpose
> > > is for testing and debug diagnostic.
> > >
> > > Signed-off-by: Tejas Upadhyay
> > > Signed-off-by: Hyun Kwon
> >
> > Hm, not sure what's the use, it seems to just be for setting/getting
> > your driver-private properties. Usually people use modetest and similar
> > tools, but if there's demand for setting properties in debugfs (we already
> > have all the infrastructure for dumping the entire kms state, see the
> > various atomic_print_state callbacks) I think that should be done with
> > generic drm code.
> >
> > I'd drop this patch for now (if there's no other reason for it).
>
> Thanks for the input. It'd be helpful, for my own understanding, if this
> can be elaborated a little more. We are using standard tools as well as
> custom script/tool, but some specific properties / controls are hard to
> be executed with modetest only unless we change the entire set up /
> design between each run. The debugfs is used to run all (or as much as
> possible) properties in a single run, and from what I understand, that
> doesn't violate intended debugfs usage as long as it's not treated as a
> stable ABI. The intention is to help isolate issues and enhance the
> diagnostics. I agree, in the long term, this kind of stuff should be
> handled in generic way, but would it be still reasonable to keep it
> driver specific in the meantime?
Well since the property stuff needs more work anyway I think we could do
it properly (for upstream) from the start.
What exactly is the issue with modetest? For intel we don't use it, we do
all our testing using the igt gpu tests:
https://cgit.freedesktop.org/drm/igt
A big pile of these tests also run on non-intel (and we're definitely very
much appreciating such work). But if you want just a bit of scripting,
modetest should be able to do it. If not I guess we'll need patches.
-Daniel
>
> Thanks,
> -hyun
>
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/xlnx/Kconfig | 21 +++
> > > drivers/gpu/drm/xlnx/zynqmp_disp.c | 326
> > +
> > > drivers/gpu/drm/xlnx/zynqmp_dp.c | 304
> > ++
> > > 3 files changed, 651 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
> > > index 7c5529c..befce0f 100644
> > > --- a/drivers/gpu/drm/xlnx/Kconfig
> > > +++ b/drivers/gpu/drm/xlnx/Kconfig
> > > @@ -21,3 +21,24 @@ config DRM_ZYNQMP_DPSUB
> > > this option if you have a Xilinx ZynqMP SoC with DisplayPort
> > > subsystem. The driver provides the kernel mode setting
> > > functionlaities for ZynqMP DP subsystem.
> > > +
> > > +config DRM_ZYNQMP_DISP_DEBUG_FS
> > > + bool "ZynqMP Display debugfs"
> > > + depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> > > + select DRM_ZYNQMP_DP_DEBUG_FS
> > > + help
> > > + Enable the debugfs code for DP Sub driver. The debugfs code
> > > + enables debugging or testing related features. It exposes some
> > > + low level controls to the user space to help testing automation,
> > > + as well as can enable additional diagnostic or statistical
> > > + information.
> > > +
> > > +config DRM_ZYNQMP_DP_DEBUG_FS
> > > + bool "ZynqMP DP debugfs"
> > > + depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> > > + help
> > > + Enable the debugfs code for DP driver. The debugfs code
> > > + enables debugging or testing related features. It exposes some
> > > + low level controls to the user space to help testing automation,
> > > + as well as can enable additional diagnostic or statistical
> > > + information.
> > > diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > > index 68f829c..9fe6d49 100644
> > > --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > > +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > > @@ -17,6 +17,7 @@
> > > #include
> > >
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -508,6 +509,325 @@ static void zynqmp_disp_set(void __iomem
> > *base, int offset, u32 set)
> > > zynqmp_disp_write(base, offset, zynqmp_disp_read(base, offset) |
> > set);
> > > }
> > >
> > > +#ifdef CONFIG_DRM_ZYNQMP_DISP_DEBUG_FS
> > > +
> > > +#define ZYNQMP_DISP_DEBUGFS_READ_MAX_SIZE32UL
> > > +#define ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL 0xFFF
> > > +#define IN_RANGE(x, min, max) ({ \
> > > + typeof(x) _x = (x); \
> > > + _x >= (min) && _x <= (max); })
> >
Re: [PATCH 00/10] Xilinx ZynqMP DisplayPort subsystem DRM KMS driver
On Thu, Jan 11, 2018 at 02:07:08AM +, Hyun Kwon wrote: > Hi Daniel, > > > -Original Message- > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > > Vetter > > Sent: Tuesday, January 09, 2018 1:57 AM > > To: Hyun Kwon > > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal > > Simek > > Subject: Re: [PATCH 00/10] Xilinx ZynqMP DisplayPort subsystem DRM > > KMS driver > > > > On Thu, Jan 04, 2018 at 06:05:49PM -0800, Hyun Kwon wrote: > > > Hi, > > > > > > This patchset adds the DRM KMS driver for Xilinx ZynqMP DisplayPort > > > subsystem. The Xilinx ZynqMP SoC has a hardened full display pipeline > > > which supports blending of up to 2 planes, and the encoder is > > > DisplayPort v1.2 compatible. > > > > > > This series mainly includes 2 sets: Xilinx DRM KMS (patch 1/10 - 5/10) > > > and ZynqMP DP subsystem drivers (patch 6/10 - 10/10). > > > > > > The Xilinx DRM KMS is intended as a common layer shared across other > > > (upcoming) Xilinx sub-drivers. It helps sub-drivers for both hardened as > > > well as soft IPs interoperate together. > > > > > > ZynqMP DP subsystem driver is a sub-driver that implements > > corresponding > > > drm objects (crtc, plane, encoder, connector,,,) for ZynqMP SoC display > > > pipeline. The entire pipeline is mainly partitioned into 2 blocks: > > > generic display logic (zynqmp_disp.c) such as blending, csc,,, and the > > > DP transmitter logic (zynqmp_dp.c). > > > > I read through it all (well mostly the drm relevant bits, not your backend > > code) and looks fairly resonable. Few minor clenaups and code removals > > tbh. > > > > Wrt merging/maintianing, do you want to maintain it as part of the > > drm-misc small drivers group? Highly recommended imo. See > > > > https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm- > > misc.html#small-drivers > > > > for details. Ideally we'd need 2 xilinx maintainers to be able to push > > patches & cross-review stuff. > > I don't have any preference on how to maintain, so I'll follow your > suggestion. One thing that may be worth a note is that there is sizable > amount of development within Xilinx, and those will come in near future > (considering what can be done with FPGA :-)). I'll look for the 2nd > reviewer, and specify that in the next patch if found. If the xilinx activity gets too much we can always split things up again. But if it's just the occasional burst (around a new product for example), then drm-misc has ample of bandwidth to absorb that. And yes the idea is very much that all regular contributors would have commit rights too. All to reduce friction and make it easier to contribute. -Daniel > > Thanks, > -hyun > > > -Daniel > > > > > > > > Thanks, > > > -hyun > > > > > > Hyun Kwon (10): > > > dt-bindings: display: xlnx: Add Xilinx kms bindings > > > drm: xlnx: Add xlnx crtc of Xilinx DRM KMS > > > drm: xlnx: Add xlnx fb of Xilinx DRM KMS > > > drm: xlnx: Add xlnx gem of Xilinx DRM KMS > > > drm: xlnx: Xilinx DRM KMS driver > > > dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings > > > drm: xlnx: DRM KMS driver for Xilinx ZynqMP DP subsystem display > > > drm: xlnx: DRM KMS driver for Xilinx ZynqMP DisplayPort > > > drm: xlnx: ZynqMP DP subsystem DRM KMS driver > > > drm: xlnx: zynqmp: Add debugfs > > > > > > .../devicetree/bindings/display/xlnx/xlnx,kms.txt | 20 + > > > .../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt| 94 + > > > MAINTAINERS|8 + > > > drivers/gpu/drm/Kconfig|2 + > > > drivers/gpu/drm/Makefile |1 + > > > drivers/gpu/drm/xlnx/Kconfig | 44 + > > > drivers/gpu/drm/xlnx/Makefile |5 + > > > drivers/gpu/drm/xlnx/xlnx_crtc.c | 195 ++ > > > drivers/gpu/drm/xlnx/xlnx_crtc.h | 70 + > > > drivers/gpu/drm/xlnx/xlnx_drv.c| 436 +++ > > > drivers/gpu/drm/xlnx/xlnx_drv.h| 22 + > > > drivers/gpu/drm/xlnx/xlnx_fb.c | 468 +++ > > > drivers/gpu/drm/xlnx/xlnx_fb.h | 30 + > > > drivers/gpu/drm/xlnx/xlnx_gem.c| 39 + > > > drivers/gpu/drm/xlnx/xlnx_gem.h| 18 + > > > drivers/gpu/drm/xlnx/zynqmp_disp.c | 3261 > > > > > drivers/gpu/drm/xlnx/zynqmp_disp.h | 28 + > > > drivers/gpu/drm/xlnx/zynqmp_dp.c | 2168 + > > > drivers/gpu/drm/xlnx/zynqmp_dp.h | 29 + > > > drivers/gpu/drm/xlnx/zynqmp_dpsub.c| 141 + > > > drivers/gpu/drm/xlnx/zynqmp_dpsub.h| 19 + > > > 21 files changed, 7098 insertions(+) > > > create mode 100644 > > Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt > > > create mode 100644 > > Documentation/devicetree/bindings
Re: [PATCH v5] drm/omap: plane zpos/zorder management improvements
On Wed, Jan 10, 2018 at 06:28:51PM +0200, Peter Ujfalusi wrote: > On 01/09/2018 04:40 PM, Daniel Vetter wrote: > > On Tue, Jan 09, 2018 at 04:18:48PM +0200, Peter Ujfalusi wrote: > >> Hi, > >> > >> On 2018-01-09 14:44, Daniel Vetter wrote: > Changes since v4: > - further simplify the zpos checking by using a mask and a single loop > - Commit message has been extended > > Changes since v3: > - Use drm_plane_index() instead of storing the same index wothin > omap_plane > struct > - Optimize the zpos validation loop so we avoid extra checks. > > Changes since v2: > - The check for duplicate zpos is moved to omap_crtc > > Changes since v1: > - Dropped the zpos normalization related patches > - New patch based on the discussion, see commit message. > >>> > >>> Sorry for jumping in late to the party, but except when you have a really, > >>> really, really good reason for why omapdrm has to not normalize zpos like > >>> the other drivers do in this case, then I think we should be consistent. > >>> > >>> An inconsistent kms uapi is a lot worse than an uapi with some design > >>> issues: The latter just means we eventually need v2, the former guarantees > >>> we need v2. > >> > >> Even if the v2 contains the "drm/blend: Account also the primary plane > >> of the crtc for normalized_zpos"? > >> It is to ensure that the crtc->primary plane is going to have zpos = 0, > >> even if it's plane_id is higher. > > > > It's a bit a hack, but imo makes sense, given where we are with uapi.> > > Except it sounds like we have more bikesheds going on about what exactly > > zpos is supposed to do. > > As https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html have this to say > about zpos: > "priority of the given plane on crtc (optional) Note that multiple active > planes on the same crtc can have an identical zpos value. The rule to solving > the conflict is to compare the plane object IDs; the plane with a higher ID > must be stacked on top of a plane with a lower ID." > > It implies that the driver should not try to be clever about the normalization > of the zpos. Even if it make sense. > > Considering only crtc->primary is a bit flowed anyway as for the sake of > completeness the crtc->cursor plane should have been kept on top at the same > time. > > >> As it was discussed we have use case when we have two (or more) crtcs, > >> each with one plane (they are the primary planes for the given crtc) and > >> user moves one of the plane from one crtc to another, where it is no > >> longer the primary plane, but still holds zpos = 0. > >> > >> In this case we prefer to keep the actual primary plane of the crtc at > >> the bottom and stack the new planes on top. > > > > Yeah that all sounds reasonable. Or we state that userspace in that case > > better readjust zpos to make it non-ambiguous. Or something else. > > > > Just something that's consistent across drivers. I'm totally fine with > > "organically grown uapi with lots of cruds and hacks". > > I'm fine with using the current normalization as it is and refer to the UAPI > doc if user space is not complying with it. > But then, should the normalization be forced in the core for all drivers to > get consistency? We had that, but then removed it again for reasons I no longer entirely understand. I guess we can keep it as-is for now, or if you want you can float a patch to move it back into the main helpers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/12] drm/sun4i: Add support for A83T second DE2 mixer
It supports 1 VI and 1 UI plane and HW scaling on both planes.
Acked-by: Maxime Ripard
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 2cbb2de6d39c..9b0256d31a61 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -485,6 +485,13 @@ static const struct sun8i_mixer_cfg sun8i_a83t_mixer0_cfg
= {
.vi_num = 1,
};
+static const struct sun8i_mixer_cfg sun8i_a83t_mixer1_cfg = {
+ .ccsc = 1,
+ .scaler_mask= 0x3,
+ .ui_num = 1,
+ .vi_num = 1,
+};
+
static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -498,6 +505,10 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun8i-a83t-de2-mixer-0",
.data = &sun8i_a83t_mixer0_cfg,
},
+ {
+ .compatible = "allwinner,sun8i-a83t-de2-mixer-1",
+ .data = &sun8i_a83t_mixer1_cfg,
+ },
{
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/12] drm/sun4i: Add A83T HDMI support
This patch series implements support for A83T DW HDMI and PHY. Contrary to v1 series, this one is based on latest linux-next, since all needed patches were merged. While exactly this combination of HDMI controller and PHY is not common in Allwinner SoCs, this patch series nevertheless makes groundwork for other SoCs, which have same DW HDMI IP block, but different PHYs, like H3 and H5. Please take a look. Best regards, Jernej Changes from v1: - Collected ACKs - Separated bindings for controller and PHY - Split driver into two parts - controller and PHY - HDMI PHY driver now uses regmap for writes - added defines for PHY registers and bits - updated DT entries to accomodate new bindings - removed already merged clock patch - reworked first clock patch according to comments - added new clock patch which changes NKMP formula - split TCON patch in two, one for quirk and one for new compatible - reworked patch which exports DW HDMI PHY functions: - remove "gen2" from some function names - removed parameter from dw_hdmi_phy_reset() - added address parameter to dw_hdmi_phy_i2c_set_addr() - updated most of commit messages Jernej Skrabec (12): clk: sunxi-ng: Mask nkmp factors when setting register clk: sunxi-ng: Change formula for NKMP PLLs drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a drm/bridge/synopsys: dw-hdmi: Export some PHY related functions drm/bridge/synopsys: dw-hdmi: Add deinit callback dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline drm/sun4i: Add has_channel_0 TCON quirk drm/sun4i: Add support for A83T second TCON drm/sun4i: Add support for A83T second DE2 mixer drm/sun4i: Implement A83T HDMI driver ARM: dts: sun8i: a83t: Add HDMI display pipeline ARM: dts: sun8i: a83t: Enable HDMI on BananaPi M3 .../bindings/display/sunxi/sun4i-drm.txt | 197 +- arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 25 ++ arch/arm/boot/dts/sun8i-a83t.dtsi | 119 +++- drivers/clk/sunxi-ng/ccu_nkmp.c| 27 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 55 ++-- drivers/gpu/drm/sun4i/Kconfig | 9 + drivers/gpu/drm/sun4i/Makefile | 4 + drivers/gpu/drm/sun4i/sun4i_tcon.c | 46 +++- drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 183 + drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 51 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 302 + drivers/gpu/drm/sun4i/sun8i_mixer.c| 11 + include/drm/bridge/dw_hdmi.h | 12 + 14 files changed, 993 insertions(+), 49 deletions(-) create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: next/master build: 198 builds: 1 failed, 197 passed, 1 error, 148 warnings (next-20180110)
On 10-01-18, 16:45, Arnd Bergmann wrote: > > 7 arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Property > > 'dmas', cell 4 is not a phandle reference in /ahb/apb/serial@b410 > > 7 arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Missing > > property '#dma-cells' in node /interrupt-controller@ec801000 or bad phandle > > (referred from /ahb/apb/serial@b410:dmas[4]) > > 7 arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Property > > 'cs-gpios', cell 6 is not a phandle reference in /ahb/apb/spi@e010 > > 7 arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Missing > > property '#gpio-cells' in node /interrupt-controller@ec801000 or bad > > phandle (referred from /ahb/apb/spi@e010:cs-gpios[6]) > > 2 arch/arm/boot/dts/spear600-evb.dtb: Warning (interrupts_property): > > Missing interrupt-parent for /ahb/apb/rtc@fc90 > > Viresh, could you have a look here? Sent fixes for all of them to you. -- viresh ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/12] clk: sunxi-ng: Mask nkmp factors when setting register
Currently, if one of the factors isn't present, bit 0 gets always set to
1. For example, A83T has NMP PLLs modelled as NKMP PLL without K. Since
K is not specified, it's offset, width and shift is 0. Driver assumes
that lowest value possible is 1, otherwise we would get division by 0.
That situation causes that bit 0 is always set, which may change wanted
clock rate.
Fix that by masking every factor according to it's specified width.
Factors with width set to 0 won't have any influence to final register
value.
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu_nkmp.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
index e58c95787f94..a99068a08315 100644
--- a/drivers/clk/sunxi-ng/ccu_nkmp.c
+++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
@@ -134,6 +134,7 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw, unsigned
long rate,
unsigned long parent_rate)
{
struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
+ u32 n_mask, k_mask, m_mask, p_mask;
struct _ccu_nkmp _nkmp;
unsigned long flags;
u32 reg;
@@ -149,18 +150,20 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw, unsigned
long rate,
ccu_nkmp_find_best(parent_rate, rate, &_nkmp);
+ n_mask = GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
+ k_mask = GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
+ m_mask = GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
+ p_mask = GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
+
spin_lock_irqsave(nkmp->common.lock, flags);
reg = readl(nkmp->common.base + nkmp->common.reg);
- reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
- reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
- reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
- reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
-
- reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
- reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
- reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
- reg |= ilog2(_nkmp.p) << nkmp->p.shift;
+ reg &= ~(n_mask | k_mask | m_mask | p_mask);
+
+ reg |= ((_nkmp.n - nkmp->n.offset) << nkmp->n.shift) & n_mask;
+ reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) & k_mask;
+ reg |= ((_nkmp.m - nkmp->m.offset) << nkmp->m.shift) & m_mask;
+ reg |= (ilog2(_nkmp.p) << nkmp->p.shift) & p_mask;
writel(reg, nkmp->common.base + nkmp->common.reg);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/12] drm/bridge/synopsys: dw-hdmi: Add deinit callback
Some SoCs, like Allwinner A83T, have to do additional cleanup when
HDMI driver unloads. When using DW HDMI through DRM bridge API, there is
no place to store driver's private data so it can be accessed in unbind
function. Because of that, add deinit function which is called at the
very end, so drivers can do a proper cleanup.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +++
include/drm/bridge/dw_hdmi.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7d80f4b56683..1b7650f2b425 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2589,6 +2589,9 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
i2c_del_adapter(&hdmi->i2c->adap);
else
i2c_put_adapter(hdmi->ddc);
+
+ if (hdmi->plat_data->deinit)
+ hdmi->plat_data->deinit(hdmi->plat_data);
}
/*
-
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 4a35e5065f6f..9ad83054a5dd 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -124,6 +124,7 @@ struct dw_hdmi_phy_ops {
struct dw_hdmi_plat_data {
struct regmap *regm;
+ void (*deinit)(const struct dw_hdmi_plat_data *pdata);
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
const struct drm_display_mode *mode);
unsigned long input_bus_format;
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/12] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a
Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.
Tests show that one iteration is enough.
Acked-by: Laurent Pinchart
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..7ca14d7325b5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
* then write one of the FC registers several times.
*
* The number of iterations matters and depends on the HDMI TX revision
-* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
-* i.MX6DL (v1.31a) have been identified as needing the workaround, with
-* 4 and 1 iterations respectively.
+* (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
+* (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
+* as needing the workaround, with 4 iterations for v1.30a and 1
+* iteration for others.
*/
switch (hdmi->version) {
@@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
count = 4;
break;
case 0x131a:
+ case 0x132a:
count = 1;
break;
default:
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/12] drm/sun4i: Add support for A83T second TCON
This TCON is connected to HDMI encoder.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0815c528d08e..adfa39f372cf 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1154,6 +1154,10 @@ static const struct sun4i_tcon_quirks
sun8i_a83t_lcd_quirks = {
.has_channel_0 = true,
};
+static const struct sun4i_tcon_quirks sun8i_a83t_tv_quirks = {
+ .has_channel_1 = true,
+};
+
static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
.has_channel_0 = true,
};
@@ -1167,6 +1171,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun7i-a20-tcon", .data = &sun7i_a20_quirks },
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data =
&sun8i_a83t_lcd_quirks },
+ { .compatible = "allwinner,sun8i-a83t-tcon-tv", .data =
&sun8i_a83t_tv_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks },
{ }
};
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/12] drm/sun4i: Add has_channel_0 TCON quirk
Some TCONs on newer SoCs doesn't support channel 0, since they are meant
to be used only with TV or HDMI encoder.
Prepare support for them with adding has_channel_0 quirk.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 41 +++---
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index b78fed809992..0815c528d08e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -84,6 +84,7 @@ static void sun4i_tcon_channel_set_status(struct sun4i_tcon
*tcon, int channel,
switch (channel) {
case 0:
+ WARN_ON(!tcon->quirks->has_channel_0);
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
SUN4I_TCON0_CTL_TCON_ENABLE,
enabled ? SUN4I_TCON0_CTL_TCON_ENABLE : 0);
@@ -276,6 +277,8 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
*tcon,
u8 clk_delay;
u32 reg, val = 0;
+ WARN_ON(!tcon->quirks->has_channel_0);
+
tcon->dclk_min_div = 7;
tcon->dclk_max_div = 7;
sun4i_tcon0_mode_set_common(tcon, mode);
@@ -344,6 +347,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
u8 clk_delay;
u32 val = 0;
+ WARN_ON(!tcon->quirks->has_channel_0);
+
tcon->dclk_min_div = 6;
tcon->dclk_max_div = 127;
sun4i_tcon0_mode_set_common(tcon, mode);
@@ -570,10 +575,12 @@ static int sun4i_tcon_init_clocks(struct device *dev,
}
clk_prepare_enable(tcon->clk);
- tcon->sclk0 = devm_clk_get(dev, "tcon-ch0");
- if (IS_ERR(tcon->sclk0)) {
- dev_err(dev, "Couldn't get the TCON channel 0 clock\n");
- return PTR_ERR(tcon->sclk0);
+ if (tcon->quirks->has_channel_0) {
+ tcon->sclk0 = devm_clk_get(dev, "tcon-ch0");
+ if (IS_ERR(tcon->sclk0)) {
+ dev_err(dev, "Couldn't get the TCON channel 0 clock\n");
+ return PTR_ERR(tcon->sclk0);
+ }
}
if (tcon->quirks->has_channel_1) {
@@ -930,10 +937,12 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
goto err_free_clocks;
}
- ret = sun4i_dclk_create(dev, tcon);
- if (ret) {
- dev_err(dev, "Couldn't create our TCON dot clock\n");
- goto err_free_clocks;
+ if (tcon->quirks->has_channel_0) {
+ ret = sun4i_dclk_create(dev, tcon);
+ if (ret) {
+ dev_err(dev, "Couldn't create our TCON dot clock\n");
+ goto err_free_clocks;
+ }
}
ret = sun4i_tcon_init_irq(dev, tcon);
@@ -991,7 +1000,8 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
return 0;
err_free_dotclock:
- sun4i_dclk_free(tcon);
+ if (tcon->quirks->has_channel_0)
+ sun4i_dclk_free(tcon);
err_free_clocks:
sun4i_tcon_free_clocks(tcon);
err_assert_reset:
@@ -1005,7 +1015,8 @@ static void sun4i_tcon_unbind(struct device *dev, struct
device *master,
struct sun4i_tcon *tcon = dev_get_drvdata(dev);
list_del(&tcon->list);
- sun4i_dclk_free(tcon);
+ if (tcon->quirks->has_channel_0)
+ sun4i_dclk_free(tcon);
sun4i_tcon_free_clocks(tcon);
}
@@ -1102,16 +1113,19 @@ static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
}
static const struct sun4i_tcon_quirks sun4i_a10_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.set_mux= sun4i_a10_tcon_set_mux,
};
static const struct sun4i_tcon_quirks sun5i_a13_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.set_mux= sun5i_a13_tcon_set_mux,
};
static const struct sun4i_tcon_quirks sun6i_a31_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.has_lvds_alt = true,
.needs_de_be_mux= true,
@@ -1119,26 +1133,29 @@ static const struct sun4i_tcon_quirks sun6i_a31_quirks
= {
};
static const struct sun4i_tcon_quirks sun6i_a31s_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.needs_de_be_mux= true,
};
static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
/* Same display pipeline structure as A10 */
.set_mux= sun4i_a10_tcon_set_mux,
};
static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
+ .has_channel_0 = true,
.has_lvds_alt = true,
};
static const struct sun4i_tcon_quir
[PATCH v2 12/12] ARM: dts: sun8i: a83t: Enable HDMI on BananaPi M3
BananaPi M3 includes HDMI connector, so add support for it.
Signed-off-by: Jernej Skrabec
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..00e47423cd07 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -60,6 +60,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
reg_usb1_vbus: reg-usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
@@ -82,6 +93,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
/* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
status = "okay";
@@ -100,6 +115,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mdio {
rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/12] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
This commit adds all necessary compatibles and descriptions needed to implement A83T HDMI pipeline. Mixer is already properly described, so only compatible is added. However, A83T TV TCON, which is connected to HDMI, doesn't have channel 0, contrary to all TCONs currently described. Because of that, TCON documentation is extended. A83T features Synopsys DW HDMI controller with a custom PHY which looks like Synopsys Gen2 PHY with few additions. Since there is no documentation, needed properties were found out through experimentation and reading BSP code. At the end, example is added for newer SoCs, which feature DE2 and DW HDMI. Signed-off-by: Jernej Skrabec --- .../bindings/display/sunxi/sun4i-drm.txt | 197 - 1 file changed, 190 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index cd626ee1147a..4fb380f3e53d 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -64,6 +64,52 @@ Required properties: first port should be the input endpoint. The second should be the output, usually to an HDMI connector. +DWC HDMI TX Encoder +--- + +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP +with Allwinner's own PHY IP. It supports audio and video outputs and CEC. + +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the +following device-specific properties. + +Required properties: + + - compatible: value must be one of: +* "allwinner,sun8i-a83t-dw-hdmi" + - reg: base address and size of memory-mapped region + - reg-io-width: See dw_hdmi.txt. Shall be 1. + - interrupts: HDMI interrupt number + - clocks: phandles to the clocks feeding the HDMI encoder +* iahb: the HDMI bus clock +* isfr: the HDMI register clock + - clock-names: the clock names mentioned above + - resets: phandle to the reset controller + - reset-names: must be "ctrl" + - phys: phandle to the DWC HDMI PHY + - phy-names: must be "phy" + + - ports: A ports node with endpoint definitions as defined in +Documentation/devicetree/bindings/media/video-interfaces.txt. The +first port should be the input endpoint. The second should be the +output, usually to an HDMI connector. + +DWC HDMI PHY + + +Required properties: + - compatible: value must be one of: +* allwinner,sun8i-a83t-hdmi-phy + - reg: base address and size of memory-mapped region + - clocks: phandles to the clocks feeding the HDMI PHY +* bus: the HDMI PHY interface clock +* mod: the HDMI PHY module clock +* tmds: TMDS clock + - clock-names: the clock names mentioned above + - resets: phandle to the reset controller driving the PHY + - reset-names: must be "phy" + TV Encoder -- @@ -94,24 +140,23 @@ Required properties: * allwinner,sun7i-a20-tcon * allwinner,sun8i-a33-tcon * allwinner,sun8i-a83t-tcon-lcd + * allwinner,sun8i-a83t-tcon-tv * allwinner,sun8i-v3s-tcon - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - - clocks: phandles to the clocks feeding the TCON. Three are needed: + - clocks: phandles to the clocks feeding the TCON. One is needed: - 'ahb': the interface clocks - - 'tcon-ch0': The clock driving the TCON channel 0 - resets: phandles to the reset controllers driving the encoder - "lcd": the reset line for the TCON channel 0 - clock-names: the clock names mentioned above - reset-names: the reset names mentioned above - - clock-output-names: Name of the pixel clock created - ports: A ports node with endpoint definitions as defined in Documentation/devicetree/bindings/media/video-interfaces.txt. The first port should be the input endpoint, the second one the output - The output may have multiple endpoints. The TCON has two channels, + The output may have multiple endpoints. TCON can have two channels, usually with the first channel being used for the panels interfaces (RGB, LVDS, etc.), and the second being used for the outputs that require another controller (TV Encoder, HDMI, etc.). The endpoints @@ -119,11 +164,16 @@ Required properties: channel the endpoint is associated to. If that property is not present, the endpoint number will be used as the channel number. +When TCON supports channel 0 (all TCONs except TV TCON on A83T), two +more clocks are needed: + - 'tcon-ch0': The clock driving the TCON channel 0 + - clock-output-names: Name of the pixel clock created + On SoCs other than the A33 and V3s, there is one more clock required: - 'tcon-ch1': The clock driving the TCON channel 1 -On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you -need one more reset line: +When TCON support L
Re: [PATCH] drm/amdkfd: Fix potential NULL pointer dereferences
Hi Felix,
Quoting Felix Kuehling :
Hi Gustavo,
Thanks for catching that. When returning a fault, I think you also need
to srcu_read_unlock(&kfd_processes_srcu, idx).
However, instead of returning an error, I think I'd prefer to skip PDDs
that can't be found with continue statements. That way others would
still suspend and resume successfully. Maybe just print a WARN_ON for
PDDs that aren't found, because that's an unexpected situation,
currently. Maybe in the future it could be normal thing if we ever
support GPU hotplug.
I got it. In that case, what do you think about the following patch instead?
index a22fb071..4ff5f0f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -461,7 +461,8 @@ int kfd_bind_processes_to_device(struct kfd_dev *dev)
hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) {
mutex_lock(&p->mutex);
pdd = kfd_get_process_device_data(dev, p);
- if (pdd->bound != PDD_BOUND_SUSPENDED) {
+
+ if (WARN_ON(!pdd) || pdd->bound != PDD_BOUND_SUSPENDED) {
mutex_unlock(&p->mutex);
continue;
}
@@ -501,6 +502,11 @@ void kfd_unbind_processes_from_device(struct
kfd_dev *dev)
mutex_lock(&p->mutex);
pdd = kfd_get_process_device_data(dev, p);
+ if (WARN_ON(!pdd)) {
+ mutex_unlock(&p->mutex);
+ continue;
+ }
+
if (pdd->bound == PDD_BOUND)
pdd->bound = PDD_BOUND_SUSPENDED;
mutex_unlock(&p->mutex);
Thank you for the feedback.
--
Gustavo
Regards,
Felix
On 2018-01-10 11:50 AM, Gustavo A. R. Silva wrote:
In case kfd_get_process_device_data returns null, there are some
null pointer dereferences in functions kfd_bind_processes_to_device
and kfd_unbind_processes_from_device.
Fix this by null checking pdd before dereferencing it.
Addresses-Coverity-ID: 1463794 ("Dereference null return value")
Addresses-Coverity-ID: 1463772 ("Dereference null return value")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index a22fb071..29d51d5 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -461,6 +461,13 @@ int kfd_bind_processes_to_device(struct kfd_dev *dev)
hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) {
mutex_lock(&p->mutex);
pdd = kfd_get_process_device_data(dev, p);
+
+ if (!pdd) {
+ pr_err("Process device data doesn't exist\n");
+ mutex_unlock(&p->mutex);
+ return -EFAULT;
+ }
+
if (pdd->bound != PDD_BOUND_SUSPENDED) {
mutex_unlock(&p->mutex);
continue;
@@ -501,6 +508,11 @@ void kfd_unbind_processes_from_device(struct
kfd_dev *dev)
mutex_lock(&p->mutex);
pdd = kfd_get_process_device_data(dev, p);
+ if (!pdd) {
+ mutex_unlock(&p->mutex);
+ return;
+ }
+
if (pdd->bound == PDD_BOUND)
pdd->bound = PDD_BOUND_SUSPENDED;
mutex_unlock(&p->mutex);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
Parts of PHY code could be useful also for custom PHYs. For example,
Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
with few additional memory mapped registers, so most of the Synopsys PHY
related code could be reused.
Functions exported here are actually not specific to Synopsys PHYs but
to DWC HDMI controller PHY interface. This means that even if the PHY is
completely custom, i.e. not designed by Synopsys, exported functions can
be useful.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 +--
include/drm/bridge/dw_hdmi.h | 11
2 files changed, 41 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7ca14d7325b5..7d80f4b56683 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi
*hdmi, u8 enable)
HDMI_PHY_CONF0_SVSRET_MASK);
}
-static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
+void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
{
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
-static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
+void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
{
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
{
@@ -1065,6 +1067,22 @@ static void dw_hdmi_phy_sel_interface_control(struct
dw_hdmi *hdmi, u8 enable)
HDMI_PHY_CONF0_SELDIPIF_MASK);
}
+void dw_hdmi_phy_reset(struct dw_hdmi *hdmi)
+{
+ /* PHY reset. The reset signal is active high on Gen2 PHYs. */
+ hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
+ hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_reset);
+
+void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address)
+{
+ hdmi_phy_test_clear(hdmi, 1);
+ hdmi_writeb(hdmi, address, HDMI_PHY_I2CM_SLAVE_ADDR);
+ hdmi_phy_test_clear(hdmi, 0);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_set_addr);
+
static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
{
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
@@ -1203,16 +1221,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
if (phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
- /* PHY reset. The reset signal is active high on Gen2 PHYs. */
- hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
- hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+ dw_hdmi_phy_reset(hdmi);
hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
- hdmi_phy_test_clear(hdmi, 1);
- hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
- HDMI_PHY_I2CM_SLAVE_ADDR);
- hdmi_phy_test_clear(hdmi, 0);
+ dw_hdmi_phy_i2c_set_addr(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2);
/* Write to the PHY as configured by the platform */
if (pdata->configure_phy)
@@ -1251,15 +1264,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi,
void *data)
dw_hdmi_phy_power_off(hdmi);
}
-static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
- void *data)
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+ void *data)
{
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
-static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
- bool force, bool disabled, bool rxsense)
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+ bool force, bool disabled, bool rxsense)
{
u8 old_mask = hdmi->phy_mask;
@@ -1271,8 +1285,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi,
void *data,
if (old_mask != hdmi->phy_mask)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_update_hpd);
-static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
{
/*
* Configure the PHY RX SENSE and HPD interrupts polarities and clear
@@ -1291,6 +1306,7 @@ static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi,
void *data)
[PATCH v2 02/12] clk: sunxi-ng: Change formula for NKMP PLLs
This commit changes formula from this:
Freq = (parent_freq * N * K) / (M * P)
to this:
Freq = (parent_freq / M) * N * K / P
This improves situation when N is in the range 1-255. PLL parent clock
is almost always 24 MHz, which means that for N >= 180 original formula
overflows and result becomes useless. Situation can be improved if M is
used as predivider as it can be seen in the second formula. That way at
least M > 1 is considered, but it still leaves small gap for wrong result
when M = 1 and N >= 180.
Using M as predivider shouldn't cause any issue, because it is in range
1-4 at most, so there is no or only minimal rounding error.
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu_nkmp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
index a99068a08315..e6c996ad4483 100644
--- a/drivers/clk/sunxi-ng/ccu_nkmp.c
+++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
@@ -33,7 +33,7 @@ static void ccu_nkmp_find_best(unsigned long parent, unsigned
long rate,
for (_p = nkmp->min_p; _p <= nkmp->max_p; _p
<<= 1) {
unsigned long tmp_rate;
- tmp_rate = parent * _n * _k / (_m * _p);
+ tmp_rate = (parent / _m) * _n * _k / _p;
if (tmp_rate > rate)
continue;
@@ -107,7 +107,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw *hw,
p = reg >> nkmp->p.shift;
p &= (1 << nkmp->p.width) - 1;
- return (parent_rate * n * k >> p) / m;
+ return (parent_rate / m) * n * k >> p;
}
static long ccu_nkmp_round_rate(struct clk_hw *hw, unsigned long rate,
@@ -127,7 +127,7 @@ static long ccu_nkmp_round_rate(struct clk_hw *hw, unsigned
long rate,
ccu_nkmp_find_best(*parent_rate, rate, &_nkmp);
- return *parent_rate * _nkmp.n * _nkmp.k / (_nkmp.m * _nkmp.p);
+ return (*parent_rate / _nkmp.m) * _nkmp.n * _nkmp.k / _nkmp.p;
}
static int ccu_nkmp_set_rate(struct clk_hw *hw, unsigned long rate,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/12] drm/sun4i: Implement A83T HDMI driver
A83T has DW HDMI IP block with a custom PHY similar to Synopsys gen2
HDMI PHY.
Only video output was tested, while HW also supports audio and CEC.
Support for them will be added later.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Kconfig | 9 +
drivers/gpu/drm/sun4i/Makefile | 4 +
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 183
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 51 ++
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 302 +
5 files changed, 549 insertions(+)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 882d85db9053..7327da3bc94f 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -40,6 +40,15 @@ config DRM_SUN4I_BACKEND
do some alpha blending and feed graphics to TCON. If M is
selected the module will be called sun4i-backend.
+config DRM_SUN8I_DW_HDMI
+ tristate "Support for Allwinner version of DesignWare HDMI"
+ depends on DRM_SUN4I
+ select DRM_DW_HDMI
+ help
+ Choose this option if you have an Allwinner SoC with the
+ DesignWare HDMI controller with custom HDMI PHY. If M is
+ selected the module will be called sun8i_dw_hdmi.
+
config DRM_SUN8I_MIXER
tristate "Support for Allwinner Display Engine 2.0 Mixer"
default MACH_SUN8I
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 2b37a6abbb1d..a7c47d9aa64d 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,6 +9,9 @@ sun4i-drm-hdmi-y+= sun4i_hdmi_enc.o
sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
+sun8i-drm-hdmi-y += sun8i_dw_hdmi.o
+sun8i-drm-hdmi-y += sun8i_hdmi_phy.o
+
sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
sun8i_vi_layer.o sun8i_ui_scaler.o \
sun8i_vi_scaler.o sun8i_csc.o
@@ -26,4 +29,5 @@ obj-$(CONFIG_DRM_SUN4I) += sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
obj-$(CONFIG_DRM_SUN4I_HDMI) += sun4i-drm-hdmi.o
+obj-$(CONFIG_DRM_SUN8I_DW_HDMI)+= sun8i-drm-hdmi.o
obj-$(CONFIG_DRM_SUN8I_MIXER) += sun8i-mixer.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
new file mode 100644
index ..afb9f5f988a9
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -0,0 +1,183 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Jernej Skrabec
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "sun8i_dw_hdmi.h"
+
+static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adj_mode)
+{
+ struct sun8i_dw_hdmi *hdmi = encoder_to_sun8i_dw_hdmi(encoder);
+
+ sun8i_hdmi_phy_update_clock(hdmi->phy, mode->crtc_clock * 1000);
+}
+
+static const struct drm_encoder_helper_funcs
+sun8i_dw_hdmi_encoder_helper_funcs = {
+ .mode_set = sun8i_dw_hdmi_encoder_mode_set,
+};
+
+static const struct drm_encoder_funcs sun8i_dw_hdmi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
+static enum drm_mode_status
+sun8i_dw_hdmi_mode_valid(struct drm_connector *connector,
+const struct drm_display_mode *mode)
+{
+ if (mode->clock > 297000)
+ return MODE_BAD;
+
+ return MODE_OK;
+}
+
+static void sun8i_dw_hdmi_deinit(const struct dw_hdmi_plat_data *plat_data)
+{
+ struct sun8i_dw_hdmi *hdmi = plat_data_to_sun8i_dw_hdmi(plat_data);
+
+ sun8i_hdmi_phy_remove(hdmi);
+
+ reset_control_assert(hdmi->rst_ctrl);
+}
+
+static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dw_hdmi_plat_data *plat_data;
+ struct drm_device *drm = data;
+ struct device_node *phy_node;
+ struct drm_encoder *encoder;
+ struct sun8i_dw_hdmi *hdmi;
+ int ret;
+
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
+ hdmi = devm_kzalloc(&pdev->dev, sizeof(*hdmi), GFP_KERNEL);
+ if (!hdmi)
+ return -ENOMEM;
+
+ plat_data = &hdmi->plat_data;
+ hdmi->dev = &pdev->dev;
+ encoder = &hdmi->encoder;
+
+ encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
+ /*
+* If we failed to find the CRTC(s) which this encoder is
+* supposed to be connected to, it's because the CRTC
[PATCH v2] drm/amdkfd: Fix potential NULL pointer dereferences
In case kfd_get_process_device_data returns null, there are some
null pointer dereferences in functions kfd_bind_processes_to_device
and kfd_unbind_processes_from_device.
Fix this by printing a WARN_ON for PDDs that aren't found and skip
them with continue statements.
Addresses-Coverity-ID: 1463794 ("Dereference null return value")
Addresses-Coverity-ID: 1463772 ("Dereference null return value")
Suggested-by: Felix Kuehling
Signed-off-by: Gustavo A. R. Silva
---
Changes in v2:
Print a WARN_ON and skip PDDs that aren't found instead of returning
an error.
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index a22fb071..4ff5f0f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -461,7 +461,8 @@ int kfd_bind_processes_to_device(struct kfd_dev *dev)
hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) {
mutex_lock(&p->mutex);
pdd = kfd_get_process_device_data(dev, p);
- if (pdd->bound != PDD_BOUND_SUSPENDED) {
+
+ if (WARN_ON(!pdd) || pdd->bound != PDD_BOUND_SUSPENDED) {
mutex_unlock(&p->mutex);
continue;
}
@@ -501,6 +502,11 @@ void kfd_unbind_processes_from_device(struct kfd_dev *dev)
mutex_lock(&p->mutex);
pdd = kfd_get_process_device_data(dev, p);
+ if (WARN_ON(!pdd)) {
+ mutex_unlock(&p->mutex);
+ continue;
+ }
+
if (pdd->bound == PDD_BOUND)
pdd->bound = PDD_BOUND_SUSPENDED;
mutex_unlock(&p->mutex);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 11/12] ARM: dts: sun8i: a83t: Add HDMI display pipeline
This commit adds all bits necessary for HDMI on A83T - mixer1, tcon1,
hdmi, hdmi phy and hdmi pinctrl entries.
Signed-off-by: Jernej Skrabec
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 119 +-
1 file changed, 118 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 7f4955a5fab7..c2638966d338 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -155,7 +155,7 @@
de: display-engine {
compatible = "allwinner,sun8i-a83t-display-engine";
- allwinner,pipelines = <&mixer0>;
+ allwinner,pipelines = <&mixer0>, <&mixer1>;
status = "disabled";
};
@@ -208,6 +208,32 @@
};
};
+ mixer1: mixer@120 {
+ compatible = "allwinner,sun8i-a83t-de2-mixer-1";
+ reg = <0x0120 0x10>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+<&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer1_out_tcon1: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon1_in_mixer1>;
+ };
+ };
+ };
+ };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun8i-a83t-system-controller",
"syscon";
@@ -256,6 +282,43 @@
};
};
+ tcon1: lcd-controller@1c0d000 {
+ compatible = "allwinner,sun8i-a83t-tcon-tv";
+ reg = <0x01c0d000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON1>, <&ccu CLK_TCON1>;
+ clock-names = "ahb", "tcon-ch1";
+ resets = <&ccu RST_BUS_TCON1>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon1_in_mixer1: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&mixer1_out_tcon1>;
+ };
+ };
+
+ tcon1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon1_out_hdmi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<&hdmi_in_tcon1>;
+ };
+ };
+ };
+ };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun8i-a83t-mmc",
"allwinner,sun7i-a20-mmc";
@@ -427,6 +490,11 @@
drive-strength = <40>;
};
+ hdmi_pins: hdmi-pins {
+ pins = "PH6", "PH7", "PH8";
+ function = "hdmi";
+ };
+
i2c0_pins: i2c0-pins {
pins = "PH0", "PH1";
function = "i2c0";
@@ -685,6 +753,55 @@
interrupts = ;
};
+ hdmi: hdmi@1ee {
+ compatible = "allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee 0x1>;
+ reg-io-width = <1>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_SLOW>;
+ clock-names = "iahb", "isfr";
+ resets = <&ccu RST_BUS_HDMI1>;
+
Re: [Bug 198123] Console is the wrong color at boot with radeon 6670
On Wed, Jan 10, 2018 at 01:15:22PM +0100, Daniel Vetter wrote:
> On Sun, Jan 07, 2018 at 07:14:41PM +, Deposite Pirate wrote:
> > December 22, 2017 4:35 PM, "Michel Dänzer" wrote:
> >
> > > "Deposite Pirate", do the attached (only compile tested) patches work?
> >
> > Hi,
> >
> > Sorry for the delay. I was not at home for a while. So, I've compiled and
> > booted a kernel with both
> > of these patches and
> > the issue is still present.
>
> Below a revised version of Michel's first patch. This one should work I
Hi Deposite Pirate, can you pls test this version of Michel's first patch?
Thanks, Daniel
> hope.
> -Daniel
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index d22f4b6a8828..dc0abdf8be00 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -213,9 +213,6 @@ void radeon_crtc_load_lut(struct drm_crtc *crtc)
> struct drm_device *dev = crtc->dev;
> struct radeon_device *rdev = dev->dev_private;
>
> - if (!crtc->enabled)
> - return;
> -
> if (ASIC_IS_DCE5(rdev))
> dce5_crtc_load_lut(crtc);
> else if (ASIC_IS_DCE4(rdev))
> @@ -702,6 +699,8 @@ static void radeon_crtc_init(struct drm_device *dev, int
> index)
> radeon_atombios_init_crtc(dev, radeon_crtc);
> else
> radeon_legacy_init_crtc(dev, radeon_crtc);
> +
> + radeon_crtc_load_lut(&radeon_crtc->base);
> }
>
> static const char *encoder_names[38] = {
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 198123] Console is the wrong color at boot with radeon 6670
On 2018-01-10 01:15 PM, Daniel Vetter wrote: > On Sun, Jan 07, 2018 at 07:14:41PM +, Deposite Pirate wrote: >> December 22, 2017 4:35 PM, "Michel Dänzer" wrote: >> >>> "Deposite Pirate", do the attached (only compile tested) patches work? >> >> Hi, >> >> Sorry for the delay. I was not at home for a while. So, I've compiled and >> booted a kernel with both >> of these patches and >> the issue is still present. > > Below a revised version of Michel's first patch. This one should work I > hope. > -Daniel > > diff --git a/drivers/gpu/drm/radeon/radeon_display.c > b/drivers/gpu/drm/radeon/radeon_display.c > index d22f4b6a8828..dc0abdf8be00 100644 > --- a/drivers/gpu/drm/radeon/radeon_display.c > +++ b/drivers/gpu/drm/radeon/radeon_display.c > @@ -213,9 +213,6 @@ void radeon_crtc_load_lut(struct drm_crtc *crtc) > struct drm_device *dev = crtc->dev; > struct radeon_device *rdev = dev->dev_private; > > - if (!crtc->enabled) > - return; > - > if (ASIC_IS_DCE5(rdev)) > dce5_crtc_load_lut(crtc); > else if (ASIC_IS_DCE4(rdev)) Good catch, thanks Daniel. FWIW though, I'd prefer this to be a separate patch, in case it causes any regressions. But let's wait for test results first. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: check the return value of register_shrinker
Am 11.01.2018 um 06:16 schrieb Roger He:
This fixes the build warning:
"ignoring return value of 'register_shrinker', declared with
attribute warn_unused_result [-Wunused-result]"
Signed-off-by: Roger He
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 21 -
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 24 ++--
2 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 79854ab..0eab24e 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -477,12 +477,12 @@ ttm_pool_shrink_count(struct shrinker *shrink, struct
shrink_control *sc)
return count;
}
-static void ttm_pool_mm_shrink_init(struct ttm_pool_manager *manager)
+static int ttm_pool_mm_shrink_init(struct ttm_pool_manager *manager)
{
manager->mm_shrink.count_objects = ttm_pool_shrink_count;
manager->mm_shrink.scan_objects = ttm_pool_shrink_scan;
manager->mm_shrink.seeks = 1;
- register_shrinker(&manager->mm_shrink);
+ return register_shrinker(&manager->mm_shrink);
}
static void ttm_pool_mm_shrink_fini(struct ttm_pool_manager *manager)
@@ -1034,15 +1034,18 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob,
unsigned max_pages)
ret = kobject_init_and_add(&_manager->kobj, &ttm_pool_kobj_type,
&glob->kobj, "pool");
- if (unlikely(ret != 0)) {
- kobject_put(&_manager->kobj);
- _manager = NULL;
- return ret;
- }
-
- ttm_pool_mm_shrink_init(_manager);
+ if (unlikely(ret != 0))
+ goto error;
+ ret = ttm_pool_mm_shrink_init(_manager);
+ if (unlikely(ret != 0))
+ goto error;
return 0;
+
+error:
+ kobject_put(&_manager->kobj);
+ _manager = NULL;
+ return ret;
}
void ttm_page_alloc_fini(void)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 4c65940..c7f01a4 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -1182,12 +1182,12 @@ ttm_dma_pool_shrink_count(struct shrinker *shrink,
struct shrink_control *sc)
return count;
}
-static void ttm_dma_pool_mm_shrink_init(struct ttm_pool_manager *manager)
+static int ttm_dma_pool_mm_shrink_init(struct ttm_pool_manager *manager)
{
manager->mm_shrink.count_objects = ttm_dma_pool_shrink_count;
manager->mm_shrink.scan_objects = &ttm_dma_pool_shrink_scan;
manager->mm_shrink.seeks = 1;
- register_shrinker(&manager->mm_shrink);
+ return register_shrinker(&manager->mm_shrink);
}
static void ttm_dma_pool_mm_shrink_fini(struct ttm_pool_manager *manager)
@@ -1197,7 +1197,7 @@ static void ttm_dma_pool_mm_shrink_fini(struct
ttm_pool_manager *manager)
int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
{
- int ret = -ENOMEM;
+ int ret;
WARN_ON(_manager);
@@ -1205,7 +1205,7 @@ int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, unsigned max_pages)
_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
if (!_manager)
- goto err;
+ return -ENOMEM;
mutex_init(&_manager->lock);
INIT_LIST_HEAD(&_manager->pools);
@@ -1217,13 +1217,17 @@ int ttm_dma_page_alloc_init(struct ttm_mem_global
*glob, unsigned max_pages)
/* This takes care of auto-freeing the _manager */
ret = kobject_init_and_add(&_manager->kobj, &ttm_pool_kobj_type,
&glob->kobj, "dma_pool");
- if (unlikely(ret != 0)) {
- kobject_put(&_manager->kobj);
- goto err;
- }
- ttm_dma_pool_mm_shrink_init(_manager);
+ if (unlikely(ret != 0))
+ goto error;
+
+ ret = ttm_dma_pool_mm_shrink_init(_manager);
+ if (unlikely(ret != 0))
+ goto error;
return 0;
-err:
+
+error:
+ kobject_put(&_manager->kobj);
+ _manager = NULL;
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/vc4: Expose performance counters to userspace
The V3D engine has various hardware counters which might be interesting
to userspace performance analysis tools.
Expose new ioctls to create/destroy a performance monitor object and
query the counter values of this perfmance monitor.
Note that a perfomance monitor is given an ID that is only valid on the
file descriptor it has been allocated from. A performance monitor can be
attached to a CL submission and the driver will enable HW counters for
this request and update the performance monitor values at the end of the
job.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- Get rid of the CL extension stuff
- Fix isolation of jobs when perfmon attached to them are different
- Add more comments in the code
- Use an SPDX header for vc4_perfmon.c
- Consider 0 as an invalid perfmonid to be backward compatible with mesa
versions that lack perfmon support
---
drivers/gpu/drm/vc4/Makefile | 1 +
drivers/gpu/drm/vc4/vc4_drv.c | 26 ++
drivers/gpu/drm/vc4/vc4_drv.h | 68 ++
drivers/gpu/drm/vc4/vc4_gem.c | 48 +-
drivers/gpu/drm/vc4/vc4_irq.c | 40 +++-
drivers/gpu/drm/vc4/vc4_perfmon.c | 188 ++
drivers/gpu/drm/vc4/vc4_regs.h| 35 +--
drivers/gpu/drm/vc4/vc4_v3d.c | 64 ++---
include/uapi/drm/vc4_drm.h| 67 ++
9 files changed, 465 insertions(+), 72 deletions(-)
create mode 100644 drivers/gpu/drm/vc4/vc4_perfmon.c
diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index f5500df51686..4a3a868235f8 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -15,6 +15,7 @@ vc4-y := \
vc4_vec.o \
vc4_hvs.o \
vc4_irq.o \
+ vc4_perfmon.o \
vc4_plane.o \
vc4_render_cl.o \
vc4_trace_points.o \
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index ceb385fd69c5..94b99c90425a 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -101,6 +101,7 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void
*data,
case DRM_VC4_PARAM_SUPPORTS_THREADED_FS:
case DRM_VC4_PARAM_SUPPORTS_FIXED_RCL_ORDER:
case DRM_VC4_PARAM_SUPPORTS_MADVISE:
+ case DRM_VC4_PARAM_SUPPORTS_PERFMON:
args->value = true;
break;
default:
@@ -111,6 +112,26 @@ static int vc4_get_param_ioctl(struct drm_device *dev,
void *data,
return 0;
}
+static int vc4_open(struct drm_device *dev, struct drm_file *file)
+{
+ struct vc4_file *vc4file;
+
+ vc4file = kzalloc(sizeof(*vc4file), GFP_KERNEL);
+ if (!vc4file)
+ return -ENOMEM;
+
+ vc4_perfmon_open_file(vc4file);
+ file->driver_priv = vc4file;
+ return 0;
+}
+
+static void vc4_close(struct drm_device *dev, struct drm_file *file)
+{
+ struct vc4_file *vc4file = file->driver_priv;
+
+ vc4_perfmon_close_file(vc4file);
+}
+
static const struct vm_operations_struct vc4_vm_ops = {
.fault = vc4_fault,
.open = drm_gem_vm_open,
@@ -143,6 +164,9 @@ static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(VC4_GET_TILING, vc4_get_tiling_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VC4_LABEL_BO, vc4_label_bo_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(VC4_GEM_MADVISE, vc4_gem_madvise_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VC4_PERFMON_CREATE, vc4_perfmon_create_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VC4_PERFMON_DESTROY, vc4_perfmon_destroy_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(VC4_PERFMON_GET_VALUES, vc4_perfmon_get_values_ioctl,
DRM_RENDER_ALLOW),
};
static struct drm_driver vc4_drm_driver = {
@@ -153,6 +177,8 @@ static struct drm_driver vc4_drm_driver = {
DRIVER_RENDER |
DRIVER_PRIME),
.lastclose = drm_fb_helper_lastclose,
+ .open = vc4_open,
+ .postclose = vc4_close,
.irq_handler = vc4_irq,
.irq_preinstall = vc4_irq_preinstall,
.irq_postinstall = vc4_irq_postinstall,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 3af22936d9b3..fefa1664a9f5 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -11,6 +11,8 @@
#include
#include
+#include "uapi/drm/vc4_drm.h"
+
/* Don't forget to update vc4_bo.c: bo_type_names[] when adding to
* this.
*/
@@ -29,6 +31,36 @@ enum vc4_kernel_bo_type {
VC4_BO_TYPE_COUNT
};
+/* Performance monitor object. The perform lifetime is controlled by userspace
+ * using perfmon related ioctls. A perfmon can be attached to a submit_cl
+ * request, and when this is the case, HW perf counters will be activated just
+ * before the submit_cl is submitted to the GPU and disabled when the job is
+ * done. This way, only events related to a specific job will be counted.
+ */
+struct vc4_perfmon {
+ /*
[Bug 198123] Console is the wrong color at boot with radeon 6670
https://bugzilla.kernel.org/show_bug.cgi?id=198123 Daniel Vetter (dan...@ffwll.ch) changed: What|Removed |Added CC||dan...@ffwll.ch --- Comment #10 from Daniel Vetter (dan...@ffwll.ch) --- Created attachment 273531 --> https://bugzilla.kernel.org/attachment.cgi?id=273531&action=edit test patch on top of b8e2b0199cc377617dc238f5106352c06dcd3fa2 - is the red message correct, or maybe also inverted/funny? - on top of b8e2b0199cc377617dc238f5106352c06dcd3fa2 please try the attached diff -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: add some lockdep asserts to the reservation object implementation
Did this fall through the cracks over the holidays? It really has made
my work much easier while reworking some of the reservation object
handling in etnaviv and I think it might benefit others.
Regards,
Lucas
Am Freitag, den 01.12.2017, 12:12 +0100 schrieb Lucas Stach:
> This adds lockdep asserts to the reservation functions which state in their
> documentation that obj->lock must be held. Allows builds with PROVE_LOCKING
> enabled to check that the locking requirements are met.
>
> > Signed-off-by: Lucas Stach
> ---
> drivers/dma-buf/reservation.c | 8
> include/linux/reservation.h | 2 ++
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index b44d9d7db347..accd398e2ea6 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -71,6 +71,8 @@ int reservation_object_reserve_shared(struct
> reservation_object *obj)
> > struct reservation_object_list *fobj, *old;
> > u32 max;
>
> > + reservation_object_assert_held(obj);
> +
> > old = reservation_object_get_list(obj);
>
> > if (old && old->shared_max) {
> @@ -211,6 +213,8 @@ void reservation_object_add_shared_fence(struct
> reservation_object *obj,
> {
> > struct reservation_object_list *old, *fobj = obj->staged;
>
> > + reservation_object_assert_held(obj);
> +
> > old = reservation_object_get_list(obj);
> > obj->staged = NULL;
>
> @@ -236,6 +240,8 @@ void reservation_object_add_excl_fence(struct
> reservation_object *obj,
> > struct reservation_object_list *old;
> > u32 i = 0;
>
> > + reservation_object_assert_held(obj);
> +
> > old = reservation_object_get_list(obj);
> > if (old)
> > i = old->shared_count;
> @@ -276,6 +282,8 @@ int reservation_object_copy_fences(struct
> reservation_object *dst,
> > size_t size;
> > unsigned i;
>
> > + reservation_object_assert_held(dst);
> +
> > rcu_read_lock();
> > src_list = rcu_dereference(src->fence);
>
> diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> index 21fc84d82d41..55e7318800fd 100644
> --- a/include/linux/reservation.h
> +++ b/include/linux/reservation.h
> @@ -212,6 +212,8 @@ reservation_object_unlock(struct reservation_object *obj)
> static inline struct dma_fence *
> reservation_object_get_excl(struct reservation_object *obj)
> {
> > + reservation_object_assert_held(obj);
> +
> > return rcu_dereference_protected(obj->fence_excl,
> > reservation_object_held(obj));
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: add some lockdep asserts to the reservation object implementation
Yeah, somehow missed that one.
The patch looks mostly good, except for reservation_object_get_excl().
For that one an RCU protection is usually sufficient, so annotating it
with reservation_object_assert_held() sounds incorrect to me.
Regards,
Christian.
Am 11.01.2018 um 11:43 schrieb Lucas Stach:
Did this fall through the cracks over the holidays? It really has made
my work much easier while reworking some of the reservation object
handling in etnaviv and I think it might benefit others.
Regards,
Lucas
Am Freitag, den 01.12.2017, 12:12 +0100 schrieb Lucas Stach:
This adds lockdep asserts to the reservation functions which state in their
documentation that obj->lock must be held. Allows builds with PROVE_LOCKING
enabled to check that the locking requirements are met.
Signed-off-by: Lucas Stach
---
drivers/dma-buf/reservation.c | 8
include/linux/reservation.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index b44d9d7db347..accd398e2ea6 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -71,6 +71,8 @@ int reservation_object_reserve_shared(struct
reservation_object *obj)
struct reservation_object_list *fobj, *old;
u32 max;
+ reservation_object_assert_held(obj);
+
old = reservation_object_get_list(obj);
if (old && old->shared_max) {
@@ -211,6 +213,8 @@ void reservation_object_add_shared_fence(struct
reservation_object *obj,
{
struct reservation_object_list *old, *fobj = obj->staged;
+ reservation_object_assert_held(obj);
+
old = reservation_object_get_list(obj);
obj->staged = NULL;
@@ -236,6 +240,8 @@ void reservation_object_add_excl_fence(struct reservation_object *obj,
struct reservation_object_list *old;
u32 i = 0;
+ reservation_object_assert_held(obj);
+
old = reservation_object_get_list(obj);
if (old)
i = old->shared_count;
@@ -276,6 +282,8 @@ int reservation_object_copy_fences(struct
reservation_object *dst,
size_t size;
unsigned i;
+ reservation_object_assert_held(dst);
+
rcu_read_lock();
src_list = rcu_dereference(src->fence);
diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 21fc84d82d41..55e7318800fd 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -212,6 +212,8 @@ reservation_object_unlock(struct reservation_object *obj)
static inline struct dma_fence *
reservation_object_get_excl(struct reservation_object *obj)
{
+ reservation_object_assert_held(obj);
+
return rcu_dereference_protected(obj->fence_excl,
reservation_object_held(obj));
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH] dma-buf: add some lockdep asserts to the reservation object implementation
Am Donnerstag, den 11.01.2018, 11:54 +0100 schrieb Christian König:
> Yeah, somehow missed that one.
>
> The patch looks mostly good, except for reservation_object_get_excl().
>
> For that one an RCU protection is usually sufficient, so annotating it
> with reservation_object_assert_held() sounds incorrect to me.
Ah, you are correct. I was confused about this one as
reservation_object_get_excl_rcu() exists and and the doc
above reservation_object_get_excl() states "The obj->lock must be
held.", which is misleading for the read-only case.
I'll send a v2 with that fixed.
Regards,
Lucas
> Regards,
> Christian.
>
> Am 11.01.2018 um 11:43 schrieb Lucas Stach:
> > Did this fall through the cracks over the holidays? It really has made
> > my work much easier while reworking some of the reservation object
> > handling in etnaviv and I think it might benefit others.
> >
> > Regards,
> > Lucas
> >
> > Am Freitag, den 01.12.2017, 12:12 +0100 schrieb Lucas Stach:
> > > This adds lockdep asserts to the reservation functions which state in
> > > their
> > > documentation that obj->lock must be held. Allows builds with
> > > PROVE_LOCKING
> > > enabled to check that the locking requirements are met.
> > >
> > > > Signed-off-by: Lucas Stach
> > >
> > > ---
> > > drivers/dma-buf/reservation.c | 8
> > > include/linux/reservation.h | 2 ++
> > > 2 files changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> > > index b44d9d7db347..accd398e2ea6 100644
> > > --- a/drivers/dma-buf/reservation.c
> > > +++ b/drivers/dma-buf/reservation.c
> > > @@ -71,6 +71,8 @@ int reservation_object_reserve_shared(struct
> > > reservation_object *obj)
> > > > > > > > struct reservation_object_list *fobj, *old;
> > > > u32 max;
> > >
> > >
> > > > + reservation_object_assert_held(obj);
> > >
> > > +
> > > > old = reservation_object_get_list(obj);
> > >
> > >
> > > > if (old && old->shared_max) {
> > >
> > > @@ -211,6 +213,8 @@ void reservation_object_add_shared_fence(struct
> > > reservation_object *obj,
> > > {
> > > > struct reservation_object_list *old, *fobj = obj->staged;
> > >
> > >
> > > > + reservation_object_assert_held(obj);
> > >
> > > +
> > > > > > > > old = reservation_object_get_list(obj);
> > > > obj->staged = NULL;
> > >
> > >
> > > @@ -236,6 +240,8 @@ void reservation_object_add_excl_fence(struct
> > > reservation_object *obj,
> > > > > > > > struct reservation_object_list *old;
> > > > u32 i = 0;
> > >
> > >
> > > > + reservation_object_assert_held(obj);
> > >
> > > +
> > > > > > > > old = reservation_object_get_list(obj);
> > > > > > > > if (old)
> > > > i = old->shared_count;
> > >
> > > @@ -276,6 +282,8 @@ int reservation_object_copy_fences(struct
> > > reservation_object *dst,
> > > > > > > > size_t size;
> > > > unsigned i;
> > >
> > >
> > > > + reservation_object_assert_held(dst);
> > >
> > > +
> > > > > > > > rcu_read_lock();
> > > > src_list = rcu_dereference(src->fence);
> > >
> > >
> > > diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> > > index 21fc84d82d41..55e7318800fd 100644
> > > --- a/include/linux/reservation.h
> > > +++ b/include/linux/reservation.h
> > > @@ -212,6 +212,8 @@ reservation_object_unlock(struct reservation_object
> > > *obj)
> > > static inline struct dma_fence *
> > > reservation_object_get_excl(struct reservation_object *obj)
> > > {
> > > > + reservation_object_assert_held(obj);
> > >
> > > +
> > > > > > > > return rcu_dereference_protected(obj->fence_excl,
> > > > reservation_object_held(obj));
> > >
> > > }
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()
Hi Brian,
On 01/09/2018 07:55 PM, Brian Norris wrote:
> Hi Philippe,
>
> On Tue, Jan 09, 2018 at 10:48:43AM +, Philippe CORNU wrote:
>> Hi Brian,
>>
>> And many thanks for implementing these TODOs.
>
> And thanks for adding them; it gave me a better option than just adding
> yet another switch case (MIPI_DSI_GENERIC_LONG_WRITE) ;)
>
>> On 01/06/2018 01:38 AM, Brian Norris wrote:
>>> This takes care of 2 TODOs in this driver, by using the common DSI
>>> packet-marshalling code instead of our custom short/long write code.
>>> This both saves us some duplicated code and gets us free support for
>>> command types that weren't already part of our switch block (e.g.,
>>> MIPI_DSI_GENERIC_LONG_WRITE).
>>>
>>> The code logic stays mostly intact, except that it becomes unnecessary
>>> to split the short/long write functions, and we have to copy data a bit
>>> more.
>>>
>>> Along the way, I noticed that loop bounds were a little odd:
>>>
>>> while (DIV_ROUND_UP(len, pld_data_bytes))
>>>
>>> This really was just supposed to be 'len != 0', so I made that more
>>> clear.
>>>
>>> Tested on RK3399 with some pending refactoring patches by Nickey Yang,
>>> to make the Rockchip DSI driver wrap this common driver.
>>>
>>> Signed-off-by: Brian Norris
>>> ---
>>> Could use an extra look from folks. This looks like the correct trivial
>>> transformation, but I'm not that familiar with DSI.
>>>
>>>drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 78
>>> ++-
>>>1 file changed, 16 insertions(+), 62 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> index d9cca4fd66ec..2fed20e44dfe 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> @@ -136,10 +136,6 @@
>>> GEN_SW_0P_TX_LP)
>>>
>>>#define DSI_GEN_HDR 0x6c
>>> -/* TODO These 2 defines will be reworked thanks to
>>> mipi_dsi_create_packet() */
>>> -#define GEN_HDATA(data)(((data) & 0x) << 8)
>>> -#define GEN_HTYPE(type)(((type) & 0xff) << 0)
>>> -
>>>#define DSI_GEN_PLD_DATA 0x70
>>>
>>>#define DSI_CMD_PKT_STATUS 0x74
>>> @@ -359,44 +355,15 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct
>>> dw_mipi_dsi *dsi, u32 hdr_val)
>>> return 0;
>>>}
>>>
>>> -static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
>>> - const struct mipi_dsi_msg *msg)
>>> -{
>>> - const u8 *tx_buf = msg->tx_buf;
>>> - u16 data = 0;
>>> - u32 val;
>>> -
>>> - if (msg->tx_len > 0)
>>> - data |= tx_buf[0];
>>> - if (msg->tx_len > 1)
>>> - data |= tx_buf[1] << 8;
>>> -
>>> - if (msg->tx_len > 2) {
>>> - dev_err(dsi->dev, "too long tx buf length %zu for short
>>> write\n",
>>> - msg->tx_len);
>>> - return -EINVAL;
>>> - }
>>> -
>>> - val = GEN_HDATA(data) | GEN_HTYPE(msg->type);
>>> - return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
>>> -}
>>> -
>>> -static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
>>> - const struct mipi_dsi_msg *msg)
>>> +static int dw_mipi_dsi_dcs_write(struct dw_mipi_dsi *dsi,
>>> +const struct mipi_dsi_packet *packet)
>>
>> Both DCS and Generic dsi transfers are managed by drm_mipi_dsi.c
>> helpers. So maybe dw_mipi_dsi_dcs_write() should be renamed
>> dw_mipi_dsi_write()...
>
> Ah, good point. I really meant to remove the _dcs naming too, but I
> guess I missed it. Will follow up.
>
>>>{
>>> - const u8 *tx_buf = msg->tx_buf;
>>> - int len = msg->tx_len, pld_data_bytes = sizeof(u32), ret;
>>> - u32 hdr_val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
>>> + const u8 *tx_buf = packet->payload;
>>> + int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
>>> u32 remainder;
>>> u32 val;
>>>
>>> - if (msg->tx_len < 3) {
>>> - dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
>>> - msg->tx_len);
>>> - return -EINVAL;
>>> - }
>>> -
>>> - while (DIV_ROUND_UP(len, pld_data_bytes)) {
>>> + while (len) {
>>> if (len < pld_data_bytes) {
>>> remainder = 0;
>>> memcpy(&remainder, tx_buf, len);
>>> @@ -419,40 +386,27 @@ static int dw_mipi_dsi_dcs_long_write(struct
>>> dw_mipi_dsi *dsi,
>>> }
>>> }
>>>
>>> - return dw_mipi_dsi_gen_pkt_hdr_write(dsi, hdr_val);
>>> + remainder = 0;
>>> + memcpy(&remainder, packet->header, sizeof(packet->header));
>
> By the way: I don't think it's an issue that should block this patch,
> since if I'm right, this function already is "broken", but isn't this
> actually a bad way to handle byte-to-word marshalling? Particularly,
> we're copying bytes into a
[Bug 103107] [CI] igt@gem_ctx_param@invalid-param-[get|set] - Failed assertion: __gem_context_get_param(fd, &arg) == -22
https://bugs.freedesktop.org/show_bug.cgi?id=103107 --- Comment #10 from Marta Löfstedt --- I believe this issue started when the I915_CONTEXT_PARAM_PRIORITY was added. commit ac14fbd460d0ec16e7750e40dcd8199b0ff83d0a Author: Chris Wilson Date: Tue Oct 3 21:34:53 2017 +0100 drm/i915/scheduler: Support user-defined priorities so instead of hitting default case with -EINVAL return, in i915_gem_context_getparam_ioctl, I915_CONTEXT_PARAM_BANNABLE + 1 gives us I915_CONTEXT_PARAM_PRIORITY. So, we could just change I915_CONTEXT_PARAM_BANNABLE + 1 to I915_CONTEXT_PARAM_PRIORITY + 1, but there is a comment in the testcase: /* NOTE: This testcase intentionally tests for the next free parameter * to catch ABI extensions. Don't "fix" this testcase without adding all * the tests for the new param first. */ As strict interpretation of this gives that subtest for the missing I915_CONTEXT_PARAM_GTT_SIZE, I915_CONTEXT_PARAM_NO_ERROR_CAPTURE, I915_CONTEXT_PARAM_BANNABLE and I915_CONTEXT_PARAM_PRIORITY, needs to be added before changing this test. I.e. this testcase fails because there are niot testcases for all context params. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103107] [CI] igt@gem_ctx_param@invalid-param-[get|set] - Failed assertion: __gem_context_get_param(fd, &arg) == -22
https://bugs.freedesktop.org/show_bug.cgi?id=103107 --- Comment #11 from Marta Löfstedt --- https://patchwork.freedesktop.org/patch/197018/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/12] drm/sun4i: Add support for A83T second TCON
On Wed, Jan 10, 2018 at 08:25:08PM +0100, Jernej Skrabec wrote: > This TCON is connected to HDMI encoder. > > Signed-off-by: Jernej Skrabec Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/12] drm/sun4i: Add has_channel_0 TCON quirk
On Wed, Jan 10, 2018 at 08:25:07PM +0100, Jernej Skrabec wrote: > Some TCONs on newer SoCs doesn't support channel 0, since they are meant > to be used only with TV or HDMI encoder. > > Prepare support for them with adding has_channel_0 quirk. > > Signed-off-by: Jernej Skrabec Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5] drm/omap: plane zpos/zorder management improvements
Hi Daniel, On Thursday, 11 January 2018 10:19:50 EET Daniel Vetter wrote: > On Wed, Jan 10, 2018 at 06:28:51PM +0200, Peter Ujfalusi wrote: > > On 01/09/2018 04:40 PM, Daniel Vetter wrote: > >> On Tue, Jan 09, 2018 at 04:18:48PM +0200, Peter Ujfalusi wrote: > >>> On 2018-01-09 14:44, Daniel Vetter wrote: > > Changes since v4: > > - further simplify the zpos checking by using a mask and a single > > loop > > - Commit message has been extended > > > > Changes since v3: > > - Use drm_plane_index() instead of storing the same index wothin > > omap_plane struct > > - Optimize the zpos validation loop so we avoid extra checks. > > > > Changes since v2: > > - The check for duplicate zpos is moved to omap_crtc > > > > Changes since v1: > > - Dropped the zpos normalization related patches > > - New patch based on the discussion, see commit message. > > Sorry for jumping in late to the party, but except when you have a > really, really, really good reason for why omapdrm has to not normalize > zpos like the other drivers do in this case, then I think we should be > consistent. > > An inconsistent kms uapi is a lot worse than an uapi with some design > issues: The latter just means we eventually need v2, the former > guarantees > we need v2. > >>> > >>> Even if the v2 contains the "drm/blend: Account also the primary plane > >>> of the crtc for normalized_zpos"? > >>> It is to ensure that the crtc->primary plane is going to have zpos = 0, > >>> even if it's plane_id is higher. > >> > >> It's a bit a hack, but imo makes sense, given where we are with uapi.> > >> Except it sounds like we have more bikesheds going on about what > >> exactly zpos is supposed to do. > > > > As https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html have this to say > > about zpos: > > "priority of the given plane on crtc (optional) Note that multiple active > > planes on the same crtc can have an identical zpos value. The rule to > > solving the conflict is to compare the plane object IDs; the plane with a > > higher ID must be stacked on top of a plane with a lower ID." > > > > It implies that the driver should not try to be clever about the > > normalization of the zpos. Even if it make sense. > > > > Considering only crtc->primary is a bit flowed anyway as for the sake of > > completeness the crtc->cursor plane should have been kept on top at the > > same time. > > > >>> As it was discussed we have use case when we have two (or more) crtcs, > >>> each with one plane (they are the primary planes for the given crtc) > >>> and user moves one of the plane from one crtc to another, where it is no > >>> longer the primary plane, but still holds zpos = 0. > >>> > >>> In this case we prefer to keep the actual primary plane of the crtc at > >>> the bottom and stack the new planes on top. > >> > >> Yeah that all sounds reasonable. Or we state that userspace in that case > >> better readjust zpos to make it non-ambiguous. Or something else. > >> > >> Just something that's consistent across drivers. I'm totally fine with > >> "organically grown uapi with lots of cruds and hacks". > > > > I'm fine with using the current normalization as it is and refer to the > > UAPI doc if user space is not complying with it. > > But then, should the normalization be forced in the core for all drivers > > to get consistency? > > We had that, but then removed it again for reasons I no longer entirely > understand. I guess we can keep it as-is for now, or if you want you can > float a patch to move it back into the main helpers. The problem is that zpos normalization requires accessing the state of all enabled planes for a CRTC in order to compute (and store) the normalized zpos values. This thus forces all planes to be added to the commit state, even when the commit doesn't touch the zpos property. I assume this caused issues (possibly performance issues) in drivers that then performed hardware setup of all planes as a result. It could be possible to implement zpos normalization in a more efficient way, or to make it possible for driver to optimize hardware setup when plane states have not changed. For instance (thinking out loud) we could add a bit to the plane state to tell whether anything has changed, drivers could then easily skip those planes. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/3] drm/sun4i: hdmi: Fix sun4i_tmds_determine_rate
On Tue, Jan 09, 2018 at 01:03:20PM +1100, Jonathan Liu wrote: > This patchset fixes several issues in sun4i_tmds_determine_rate that I > discovered while trying to get a projector connected to an Olimex > A20-OLinuXino-LIME using HDMI with a native resolution of 1280x800 and > pixel clock of 83.5 MHz to display at its native resolution. Queued all three patches as fixes, thanks! maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2] x86/gpu: add CFL to early quirks
On 15.12.2017 23:19, Rodrigo Vivi wrote:
> On Fri, Dec 15, 2017 at 04:39:25PM +, Ingo Molnar wrote:
>>
>> * Lucas De Marchi wrote:
>>
>>> CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
>>> allow the memory region to be stolen, otherwise we could have RAM being
>>> arbitrarily overwritten if for example we keep using the UEFI framebuffer,
>>> depending on how BIOS has set up the e820 map.
>>>
>>> Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.")
>>> Signed-off-by: Lucas De Marchi
>>> Cc: Rodrigo Vivi
>>> Cc: Anusha Srivatsa
>>> Cc: Jani Nikula
>>> Cc: Joonas Lahtinen
>>> Cc: David Airlie
>>> Cc: intel-...@lists.freedesktop.org
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: Ingo Molnar
>>> Cc: H. Peter Anvin
>>> Cc: Thomas Gleixner
>>> Cc: x...@kernel.org
>>> Cc: # v4.13+ 0890540e21cf drm/i915: add GT number
>>> to intel_device_info
>>> Cc: # v4.13+ 41693fd52373 drm/i915/kbl: Change a
>>> KBL pci id to GT2 from GT1.5
>>> Cc: # v4.13+
>>> Reviewed-by: Rodrigo Vivi
>>> ---
>>>
>>> v2: improve commit message, add Fixes tag and CC stable
>>>
>>> arch/x86/kernel/early-quirks.c | 1 +
>>> include/drm/i915_pciids.h | 6 ++
>>> 2 files changed, 7 insertions(+)
>>
>> Acked-by: Ingo Molnar
>
> Merged to drm-intel-next-queued.
> Thanks for the patches, suggestions and acks.
Shouldn't this go to v4.15 as well, because CFL is enabled there? I
don't see it in rc8.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly
Hi Maxime,
(CC'ing Mark Brown)
Thank you for the patch.
On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> The devm_regulator_get_optional function, unlike it was assumed in the
> commit a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> property"), is actually returning an error pointer with -ENODEV instead of
> NULL when there's no regulator to find.
>
> Make sure we handle that case properly.
>
> Fixes: a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> property") Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/panel/panel-lvds.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> b/drivers/gpu/drm/panel/panel-lvds.c index 57e38a9e7ab4..9f46e7095c0e
> 100644
> --- a/drivers/gpu/drm/panel/panel-lvds.c
> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> @@ -215,8 +215,13 @@ static int panel_lvds_probe(struct platform_device
> *pdev) lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> if (IS_ERR(lvds->supply)) {
> ret = PTR_ERR(lvds->supply);
> - dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
> - return ret;
> +
> + if (ret != -ENODEV) {
> + dev_err(lvds->dev, "failed to request regulator: %d\n",
> ret);
> + return ret;
I wouldn't print an error message if ret == -EPROBE_DEFER.
> + } else {
> + lvds->supply = NULL;
> + }
> }
How about
lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
if (IS_ERR(lvds->supply)) {
ret = PTR_ERR(lvds->supply);
if (ret != -ENODEV) {
if (ret == -EPROBE_DEFER)
dev_err(lvds->dev, "failed to request
regulator: %d\n", ret);
return ret;
}
lvds->supply = NULL;
}
My preference, however, would be for devm_regulator_get_optional() to return
NULL when no regulator is present. The current implementation returns -ENODEV
in multiple cases, making it impossible to properly discriminate between
having no regulator and not being able to get the regulator due to an error.
Mark, what do you think about this ?
> /* Get GPIOs and backlight controller. */
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly
Hi,
On Thu, Jan 11, 2018 at 03:05:01PM +0200, Laurent Pinchart wrote:
> Hi Maxime,
>
> (CC'ing Mark Brown)
>
> Thank you for the patch.
>
> On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> > The devm_regulator_get_optional function, unlike it was assumed in the
> > commit a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> > property"), is actually returning an error pointer with -ENODEV instead of
> > NULL when there's no regulator to find.
> >
> > Make sure we handle that case properly.
> >
> > Fixes: a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> > property") Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/panel/panel-lvds.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> > b/drivers/gpu/drm/panel/panel-lvds.c index 57e38a9e7ab4..9f46e7095c0e
> > 100644
> > --- a/drivers/gpu/drm/panel/panel-lvds.c
> > +++ b/drivers/gpu/drm/panel/panel-lvds.c
> > @@ -215,8 +215,13 @@ static int panel_lvds_probe(struct platform_device
> > *pdev) lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> > if (IS_ERR(lvds->supply)) {
> > ret = PTR_ERR(lvds->supply);
> > - dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
> > - return ret;
> > +
> > + if (ret != -ENODEV) {
> > + dev_err(lvds->dev, "failed to request regulator: %d\n",
> > ret);
> > + return ret;
>
> I wouldn't print an error message if ret == -EPROBE_DEFER.
>
> > + } else {
> > + lvds->supply = NULL;
> > + }
> > }
>
> How about
>
> lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> if (IS_ERR(lvds->supply)) {
> ret = PTR_ERR(lvds->supply);
> if (ret != -ENODEV) {
> if (ret == -EPROBE_DEFER)
I guess that would be != -EPROBE_DEFER
> dev_err(lvds->dev, "failed to request
> regulator: %d\n", ret);
> return ret;
> }
>
> lvds->supply = NULL;
> }
Otherwise, it works for me.
> My preference, however, would be for devm_regulator_get_optional() to return
> NULL when no regulator is present. The current implementation returns -ENODEV
> in multiple cases, making it impossible to properly discriminate between
> having no regulator and not being able to get the regulator due to an error.
It would feel more intuitive to me too, but it would also require to
fix most of the call sites that would have a similar pattern.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: make dw_mipi_dsi_bridge_mode_set() static
Hi Brian,
Reviewed-by: Philippe Cornu
Many thanks,
Philippe :-)
On 01/09/2018 09:33 PM, Brian Norris wrote:
> sparse complains:
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:703:6: warning: symbol
> 'dw_mipi_dsi_bridge_mode_set' was not declared. Should it be static?
>
> Signed-off-by: Brian Norris
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 90f13df6f106..d60a77e98b57 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -700,9 +700,9 @@ static void dw_mipi_dsi_bridge_post_disable(struct
> drm_bridge *bridge)
> pm_runtime_put(dsi->dev);
> }
>
> -void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> +static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> {
> struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
> const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()
Hi Brian & All *DSI DRM experts*,
1) Re-reading this patch, I realize that the returned value of
dw_mipi_dsi_host_transfer() is not correct: we should return the number
of transfered/received bytes...
so I think there are two solutions: fix this in this serie or add a TODO
for later (both solutions are fine to me :-)
2) Digging more into the drm code, the function
mipi_dsi_device_transfer() in drm_mipi_dsi.c is called in the same file
by the 3 following functions: mipi_dsi_shutdown_peripheral(),
mipi_dsi_turn_on_peripheral() &
mipi_dsi_set_maximum_return_packet_size(). All these 3 functions are
expecting "Return: 0 on success or a negative error code on failure."
that is not in line with the transfer function.
So then, we can change the documentation in this file and have instead
"* Return: The number of bytes transmitted on success or a negative
error code on failure." as for mipi_dsi_generic_write()...
Or we can change the source code of these 3 functions to match with the
documentation "Return: 0 on success...".
note: Hopefully, "users" of these 3 functions test the sign of the
return value (or do not use it).
Does anyone have a preferred solutions?
Many thanks
Philippe :-)
On 01/09/2018 09:32 PM, Brian Norris wrote:
> This takes care of 2 TODOs in this driver, by using the common DSI
> packet-marshalling code instead of our custom short/long write code.
> This both saves us some duplicated code and gets us free support for
> command types that weren't already part of our switch block (e.g.,
> MIPI_DSI_GENERIC_LONG_WRITE).
>
> The code logic stays mostly intact, except that it becomes unnecessary
> to split the short/long write functions, and we have to copy data a bit
> more.
>
> Along the way, I noticed that loop bounds were a little odd:
>
> while (DIV_ROUND_UP(len, pld_data_bytes))
>
> This really was just supposed to be 'len != 0', so I made that more
> clear.
>
> Tested on RK3399 with some pending refactoring patches by Nickey Yang,
> to make the Rockchip DSI driver wrap this common driver.
>
> Signed-off-by: Brian Norris
> Reviewed-by: Philippe Cornu
> Tested-by: Philippe Cornu
> ---
> v2:
> * remove "dcs" naming, since these commands handle generic DSI too, not
> just DCS (thanks Philippe)
> * add Philippe's {Tested,Reviewed}-by
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 78
> ++-
> 1 file changed, 16 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d9cca4fd66ec..ed91e32ee43a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -136,10 +136,6 @@
>GEN_SW_0P_TX_LP)
>
> #define DSI_GEN_HDR 0x6c
> -/* TODO These 2 defines will be reworked thanks to mipi_dsi_create_packet()
> */
> -#define GEN_HDATA(data) (((data) & 0x) << 8)
> -#define GEN_HTYPE(type) (((type) & 0xff) << 0)
> -
> #define DSI_GEN_PLD_DATA0x70
>
> #define DSI_CMD_PKT_STATUS 0x74
> @@ -359,44 +355,15 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct
> dw_mipi_dsi *dsi, u32 hdr_val)
> return 0;
> }
>
> -static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
> -const struct mipi_dsi_msg *msg)
> -{
> - const u8 *tx_buf = msg->tx_buf;
> - u16 data = 0;
> - u32 val;
> -
> - if (msg->tx_len > 0)
> - data |= tx_buf[0];
> - if (msg->tx_len > 1)
> - data |= tx_buf[1] << 8;
> -
> - if (msg->tx_len > 2) {
> - dev_err(dsi->dev, "too long tx buf length %zu for short
> write\n",
> - msg->tx_len);
> - return -EINVAL;
> - }
> -
> - val = GEN_HDATA(data) | GEN_HTYPE(msg->type);
> - return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
> -}
> -
> -static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
> - const struct mipi_dsi_msg *msg)
> +static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
> + const struct mipi_dsi_packet *packet)
> {
> - const u8 *tx_buf = msg->tx_buf;
> - int len = msg->tx_len, pld_data_bytes = sizeof(u32), ret;
> - u32 hdr_val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
> + const u8 *tx_buf = packet->payload;
> + int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
> u32 remainder;
> u32 val;
>
> - if (msg->tx_len < 3) {
> - dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
> - msg->tx_len);
> - return -EINVAL;
> - }
> -
> - while (DIV_ROUND_UP(len, pld_data_bytes)) {
> + while (len) {
> if (len < pld_data_bytes) {
> remainder = 0;
> memcpy
Re: [RFC v2 6/8] drm: Handle fbdev emulation in core
Den 11.01.2018 08.45, skrev Daniel Vetter:
On Wed, Jan 10, 2018 at 06:02:38PM +0100, Noralf Trønnes wrote:
Den 09.01.2018 11.38, skrev Daniel Vetter:
On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote:
Prepare for generic fbdev emulation by letting DRM core work directly
with the fbdev compatibility layer. This is done by adding new fbdev
helper vtable callbacks for restore, hotplug_event, unregister and
release.
Signed-off-by: Noralf Trønnes
No clue whether my idea is any good, but inspired by the bootsplash
discussion, and the prospect that we might get other in-kernel drm/kms
clients I'm wondering whether we should make this a bit more generic and
tie it to drm_file?
The idea would be to have a list of internal drm clients by putting all
the internal drm_files onto a list (same way we do with the userspace
ones). Then we'd just walk that list and call ->hotplug, ->unregister and
->release at the right places.
->restore would be a bit different, I guess for that we'd only call the
->restore callback of the very first kernel-internal client.
With that we could then add/remove kernel-internal drm clients like normal
userspace clients, which should make integration of emergency consoles,
boot splashes and whatever else real easy. And I think it would be a lot
cleaner than leaking fb_helper knowledge into the drm core, which feels a
rather backwards.
Otoh that feels a bit overengineered (but at least it shouldn't be a lot
more code really). If the list is too much work we could start with 1
drm_file * pointer for internal stuff (but would still need locking, so
list_head is probably easier).
Thoughts?
I prefer to have a proper in-kernel client API from the get go, instead
of fixing it up later. The reason I skipped spending time on it in this
RFC, was that I didn't know if I was on the right track at the right time
to get the necessary attention to make this dumb_buffer idea happen.
With a drm_file centric approach, are you thinking something like this:
struct drm_device {
+ struct list_head filelist_internal;
};
+struct drm_file_funcs {
+ int (*restore)(struct drm_file *file);
+ void (*hotplug)(struct drm_file *file);
+ void (*unregister)(struct drm_file *file);
I guess we still need a cleanup callback here? For the usual two-stage
driver unload sequence of 1. unregister 2. cleanup.
There's no need for a cleanup callback in this scenario.
The client holds a ref on drm_device through drm_internal_open() and if
it can't release the drm_file on .unregister, there won't be any cleanup.
When the client is in a position to release drm_file (fb_close), it will
do so and the ref is dropped.
If for some reason we can't take a ref, then we need to use
drm_device.open_count to avoid drm_device going away in drm_dev_unplug().
Noralf.
+};
struct drm_file {
+ struct drm_device *dev;
+ const struct drm_file_funcs *funcs;
};
struct drm_file *drm_file_alloc(struct drm_minor *minor)
{
+ file->dev = dev;
}
struct drm_file* drm_internal_open(struct drm_device *dev,
const struct drm_file_funcs *funcs)
struct drm_file *file;
int ret;
if (!try_module_get(dev->driver->fops->owner))
return ERR_PTR(-ENODEV);
drm_dev_ref(dev);
file = drm_file_alloc(dev);
if (IS_ERR(file)) {
drm_dev_unref(dev);
module_put(dev->driver->fops->owner);
return file;
}
file->funcs = funcs;
mutex_lock(&dev->filelist_mutex);
list_add(&file->lhead, &dev->filelist_internal);
mutex_unlock(&dev->filelist_mutex);
return file;
}
void drm_internal_release(struct drm_file *file)
{
struct drm_device *dev = file->dev;
mutex_lock(&dev->filelist_mutex);
list_del(&file->lhead);
mutex_unlock(&dev->filelist_mutex);
drm_file_free(file);
drm_dev_unref(dev);
module_put(dev->driver->fops->owner);
}
void drm_lastclose(struct drm_device *dev)
{
+ mutex_lock(&dev->filelist_mutex);
+ list_for_each_entry(file, &dev->filelist_internal, lhead) {
+ if (file->funcs && file->funcs->restore &&
+ !file->funcs->restore(file))
+ break;
+ mutex_unlock(&dev->filelist_mutex);
}
void drm_kms_helper_hotplug_event(struct drm_device *dev)
{
+ mutex_lock(&dev->filelist_mutex);
+ list_for_each_entry(file, &dev->filelist_internal, lhead) {
+ if (file->funcs && file->funcs->hotplug)
+ file->funcs->hotplug(file);
+ mutex_unlock(&dev->filelist_mutex);
}
How is locking done when .unregister will call into drm_internal_release()?
void drm_dev_unregister(struct drm_device *dev)
{
+ list_for_each_entry(file, &dev->filelist_internal, lhead) {
+ if (file->funcs && file->funcs->unregister)
+ file->funcs->unregister(file);
}
There is also the case where .unregister can't release the drm_file
because userspace has mmap'ed the buffer (fbdev). The client holds a ref
on
Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly
On Thu, 11 Jan 2018, Laurent Pinchart wrote: > My preference, however, would be for devm_regulator_get_optional() to return > NULL when no regulator is present. The current implementation returns -ENODEV > in multiple cases, making it impossible to properly discriminate between > having no regulator and not being able to get the regulator due to an error. Just a word of warning, IS_ERR(NULL) is false, and your proposed change would apparently require quite a churn all over the kernel. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdkfd: Fix potential NULL pointer dereferences
On Thu, Jan 11, 2018 at 1:15 AM, Gustavo A. R. Silva
wrote:
> In case kfd_get_process_device_data returns null, there are some
> null pointer dereferences in functions kfd_bind_processes_to_device
> and kfd_unbind_processes_from_device.
>
> Fix this by printing a WARN_ON for PDDs that aren't found and skip
> them with continue statements.
>
> Addresses-Coverity-ID: 1463794 ("Dereference null return value")
> Addresses-Coverity-ID: 1463772 ("Dereference null return value")
> Suggested-by: Felix Kuehling
> Signed-off-by: Gustavo A. R. Silva
> ---
> Changes in v2:
> Print a WARN_ON and skip PDDs that aren't found instead of returning
> an error.
>
> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> index a22fb071..4ff5f0f 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
> @@ -461,7 +461,8 @@ int kfd_bind_processes_to_device(struct kfd_dev *dev)
> hash_for_each_rcu(kfd_processes_table, temp, p, kfd_processes) {
> mutex_lock(&p->mutex);
> pdd = kfd_get_process_device_data(dev, p);
> - if (pdd->bound != PDD_BOUND_SUSPENDED) {
> +
> + if (WARN_ON(!pdd) || pdd->bound != PDD_BOUND_SUSPENDED) {
> mutex_unlock(&p->mutex);
> continue;
> }
> @@ -501,6 +502,11 @@ void kfd_unbind_processes_from_device(struct kfd_dev
> *dev)
> mutex_lock(&p->mutex);
> pdd = kfd_get_process_device_data(dev, p);
>
> + if (WARN_ON(!pdd)) {
> + mutex_unlock(&p->mutex);
> + continue;
> + }
> +
> if (pdd->bound == PDD_BOUND)
> pdd->bound = PDD_BOUND_SUSPENDED;
> mutex_unlock(&p->mutex);
> --
> 2.7.4
>
This patch is:
Reviewed-by: Oded Gabbay
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms bindings
On Wed, Jan 10, 2018 at 8:04 PM, Hyun Kwon wrote:
> Hi Rob,
>
> Thanks for the feedback.
>
>> -Original Message-
>> From: Rob Herring [mailto:r...@kernel.org]
>> Sent: Monday, January 08, 2018 8:00 PM
>> To: Hyun Kwon
>> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
>> Simek
>> Subject: Re: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms
>> bindings
>>
>> On Thu, Jan 04, 2018 at 06:05:50PM -0800, Hyun Kwon wrote:
>> > The dt binding for Xilinx DRM KMS driver.
>>
>> Bindings are for h/w, not drivers.
>
> I'll rephrase this.
>
>>
>> >
>> > Signed-off-by: Hyun Kwon
>> > ---
>> > .../devicetree/bindings/display/xlnx/xlnx,kms.txt| 20
>>
>> > 1 file changed, 20 insertions(+)
>> > create mode 100644
>> Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
>> b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
>> > new file mode 100644
>> > index 000..8dcd552
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
>> > @@ -0,0 +1,20 @@
>> > +Xilinx KMS Pipeline
>> > +---
>> > +
>> > +Xilinx display pipelines can be designed with hardened video IPs and soft
>> video
>> > +IPs in programmable logic. This KMS module provides the common
>> functionality
>> > +of individual subdevice drivers, and glue logics between them.
>> > +
>> > +Required properties:
>> > +
>> > +- compatible: Must be "xlnx,kms".
>
> I'll also rephrase the description and rename this to xlnx,display.
>
>> > +
>> > +- ports: phandles for CRTC ports, using the DT bindings defined in
>> > + Documentation/devicetree/bindings/graph.txt.
>>
>> This use of ports is not part of the graph binding.
>
> I'll add more details in the description.
>
>>
>> > +
>> > +Example:
>> > +
>> > + xlnx_drm: xlnx_drm {
>> > + compatible = "xlnx,kms";
>>
>> drm and kms are Linuxisms.
>
> I agree. I'll remove linux subsystem specific terms.
>
>>
>> Why do you need this node?
>
> This node is used to represent a display pipeline as a single entity, which
> can consist of multiple components / IPs. I'll elaborate more per your
> suggestion.
You generally don't need that. Just have the DRM driver match with the
first block in the display pipeline. Then use the OF graph to connect
to the other components in the pipeline. It would help to have a block
diagram showing the data pipelines and h/w blocks.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #180 from x...@amail.club --- >From watching this bug progress over the last two years and not really improving, I guess this problem is never going to get fixed, at least not too soon. >From my testing last year, it would seem that the majority who have this problem own the MSI brand one, both 390 an 390x have the problem, and there isn't a proper workaround for it besides forcing the memory(maybe core) clock high, so it would seem that the clock is not being set correctly, or the "sensor" isn't realizing that clock should be increased. I have tried every kernel from the past year in hopes that this problem would be solved, with no successful test, I have tried using both AMDGPU and radeon modules, while blacklisting the other to make sure that there was not a problem with one, and still no success. On Windows 10, there is never an issue with artifacts, or crashes. If there is anyway to get this on a fast track to being fixed, please let everyone know, so that we can help, that is what community is for...I think. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave - Hopefully final drm/i915 fixes for v4.15: - Fix a KASAN reported use after free - Whitelist a register to avoid hangs - GVT fixes BR, Jani. The following changes since commit b2cd1df66037e7c4697c7e40496bf7e4a5e16a2d: Linux 4.15-rc7 (2018-01-07 14:22:41 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-01-11-1 for you to fetch changes up to 5005c8514285ae4f28e862f8d91faaa2015e03a3: drm/i915: Don't adjust priority on an already signaled fence (2018-01-11 11:42:53 +0200) Hopefully final drm/i915 fixes for v4.15: - Fix a KASAN reported use after free - Whitelist a register to avoid hangs - GVT fixes Changbin Du (1): drm/i915/gvt: Fix stack-out-of-bounds bug in cmd parser Chris Wilson (1): drm/i915: Don't adjust priority on an already signaled fence Jani Nikula (1): Merge tag 'gvt-fixes-2018-01-08' of https://github.com/intel/gvt-linux into drm-intel-fixes Kenneth Graunke (1): drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake. Zhi Wang (1): drm/i915/gvt: Clear the shadow page table entry after post-sync drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 ++-- drivers/gpu/drm/i915/gvt/gtt.c | 5 - drivers/gpu/drm/i915/i915_gem.c| 2 +- drivers/gpu/drm/i915/i915_reg.h| 2 ++ drivers/gpu/drm/i915/intel_engine_cs.c | 5 + drivers/gpu/drm/i915/intel_lrc.c | 3 +++ 6 files changed, 17 insertions(+), 4 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103316] [Hawaii, FirePro, radeon] WARNING: CPU: 1 PID: 18632 at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:548 ttm_dma_free_pool.part.8+0x128/0x130 [ttm]
https://bugs.freedesktop.org/show_bug.cgi?id=103316 --- Comment #6 from Vedran Miletić --- Still the case in Fedora rawhide with kernel 4.15.0-0.rc7.git0.1.fc28.x86_64 [ 2582.430297] [drm] radeon: finishing device. [ 2582.445874] [TTM] Finalizing pool allocator [ 2582.445877] [TTM] Finalizing DMA pool allocator [ 2582.445912] WARNING: CPU: 2 PID: 2446 at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:565 ttm_dma_free_pool.part.9+0x11c/0x120 [ttm] [ 2582.445913] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables sunrpc intel_rapl x86_pkg_temp_thermal snd_hda_codec_realtek intel_powerclamp snd_hda_codec_generic coretemp snd_hda_codec_hdmi snd_hda_intel snd_hda_codec kvm_intel kvm snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd iTCO_wdt wmi_bmof irqbypass eeepc_wmi asus_wmi sparse_keymap rfkill iTCO_vendor_support crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate [ 2582.445930] intel_uncore mxm_wmi intel_rapl_perf soundcore mei_me mei i2c_i801 shpchp lpc_ich wmi xfs libcrc32c amdgpu chash i915 radeon(-) i2c_algo_bit drm_kms_helper ttm r8169 drm crc32c_intel mii video [ 2582.445937] CPU: 2 PID: 2446 Comm: modprobe Not tainted 4.15.0-0.rc7.git0.1.fc28.x86_64 #1 [ 2582.445938] Hardware name: ASUS All Series/Z87-A, BIOS 1602 10/29/2013 [ 2582.445941] RIP: 0010:ttm_dma_free_pool.part.9+0x11c/0x120 [ttm] [ 2582.445941] RSP: 0018:b1d8029afd40 EFLAGS: 00010202 [ 2582.445942] RAX: 0202 RBX: 8cda93b27540 RCX: [ 2582.445942] RDX: 00018041 RSI: f7c0104eca80 RDI: b1d8029afcf0 [ 2582.445943] RBP: 8cda9ce482d8 R08: 8cda93b2a900 R09: 00018040 [ 2582.445943] R10: b1d8029afbc0 R11: R12: 0008 [ 2582.445943] R13: c046f1d0 R14: 8cda9d193100 R15: c046f160 [ 2582.445944] FS: 7f4991aca0c0() GS:8cdaafa8() knlGS: [ 2582.445945] CS: 0010 DS: ES: CR0: 80050033 [ 2582.445945] CR2: 7fff854e7968 CR3: 0003a6dbe002 CR4: 001606e0 [ 2582.445946] Call Trace: [ 2582.445950] ttm_dma_page_alloc_fini+0x7d/0xf0 [ttm] [ 2582.445952] ttm_mem_global_release+0x14/0x80 [ttm] [ 2582.445963] drm_global_item_unref+0x44/0x60 [drm] [ 2582.445976] radeon_ttm_fini+0x12b/0x190 [radeon] [ 2582.445984] radeon_bo_fini+0xe/0x30 [radeon] [ 2582.445996] cik_fini+0xc6/0xf0 [radeon] [ 2582.446002] radeon_device_fini+0x31/0x110 [radeon] [ 2582.446007] radeon_driver_unload_kms+0x3e/0x70 [radeon] [ 2582.446013] drm_dev_unregister+0x3c/0xe0 [drm] [ 2582.446018] drm_put_dev+0x2e/0x60 [drm] [ 2582.446020] pci_device_remove+0x36/0xb0 [ 2582.446023] device_release_driver_internal+0x157/0x220 [ 2582.446024] driver_detach+0x32/0x60 [ 2582.446025] bus_remove_driver+0x51/0xd0 [ 2582.446026] pci_unregister_driver+0x22/0xa0 [ 2582.446036] radeon_exit+0xc/0x64 [radeon] [ 2582.446038] SyS_delete_module+0x1a1/0x2b0 [ 2582.446040] ? exit_to_usermode_loop+0x8a/0xa0 [ 2582.446042] entry_SYSCALL_64_fastpath+0x1a/0x7d [ 2582.446043] RIP: 0033:0x7f4990fc8a17 [ 2582.446043] RSP: 002b:7fff854eaa98 EFLAGS: 0206 [ 2582.446044] Code: 00 00 00 00 ad de 48 89 df 48 89 03 48 05 00 01 00 00 48 89 43 08 e8 24 7d 09 e8 5b 5d 41 5c 48 8b 3d 99 b8 00 00 e9 b4 e7 6d e8 <0f> ff eb b3 0f 1f 44 00 00 48 8b 06 48 85 c0 74 0d 48 85 ff 74 [ 2582.446057] ---[ end trace f3849642451d16df ]--- [ 2582.446223] [TTM] Zone kernel: Used memory at exit: 2080 kiB [ 2582.446225] [TTM] Zone dma32: Used memory at exit: 24 kiB [ 2582.446225] [drm] radeon: ttm finalized -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/19] drm/blend: Add a generic alpha property
On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote: > On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote: > > On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote: > > > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote: > > > > Some drivers duplicate the logic to create a property to store a > > > > per-plane > > > > alpha. > > > > > > > > Let's create a helper in order to move that to the core. > > > > > > > > Cc: Boris Brezillon > > > > Cc: Laurent Pinchart > > > > Signed-off-by: Maxime Ripard > > > > > > Do we have userspace for this? > > > > Wayland seems to be on its way to implement this, with ChromeOS using > > it: > > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html > > > > and more specifically: > > https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118 > > Yay, would be good to include these links in the patch description. Really > happy we're having a real standard now used by multiple people. I will. > > > Is encoding a fixed 0-255 range really the best idea? > > > > I don't really know, is there hardware or formats where there is more > > than 255? Or did you mean less than that? > > 30bit I'd assume wants more alpha. In the past we've done some fixed-point > stuff (e.g. for LUT), using the 0.0-1.0 float range. Using that for the > blend equation docs is also what I recommend (and that we map from 0-255 > to 0.0-1.0 logically). Ofc the hw might not do any of that ... I think > 0.16 fixed point, stored in a u16 is probably best. That's what we're > doing for gamma tables already, and that way drivers can simply throw away > the lower bits. But that would also break the two users of that property that won't be able to move to the generic property (with the same name) without breaking userspace. The point of that patch was to allow some code consolidation, and that would mean failing to do so here :/ > > > I know other drivers have skimped on the rules here a bit ... But at least > > > internally (i.e. within the drm_plane_state) we probably should restrict > > > ourselves to u8. And this needs real docs (i.e. the full blend equation > > > drivers are supposed to implement). > > > > You mean straight vs premultiplied? Maybe we should implement this as > > an additional property in read only depending on how the hardware > > behaves? > > No need for an additional property right now, but definitely document > whether you mean straight or pre-multiplied. Just writing down the blend > equation is probably best. Ack. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/19] drm/blend: Add a generic alpha property
On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote: > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote: >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote: >> > On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote: >> > > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote: >> > > > Some drivers duplicate the logic to create a property to store a >> > > > per-plane >> > > > alpha. >> > > > >> > > > Let's create a helper in order to move that to the core. >> > > > >> > > > Cc: Boris Brezillon >> > > > Cc: Laurent Pinchart >> > > > Signed-off-by: Maxime Ripard >> > > >> > > Do we have userspace for this? >> > >> > Wayland seems to be on its way to implement this, with ChromeOS using >> > it: >> > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html >> > >> > and more specifically: >> > https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118 >> >> Yay, would be good to include these links in the patch description. Really >> happy we're having a real standard now used by multiple people. > > I will. > >> > > Is encoding a fixed 0-255 range really the best idea? >> > >> > I don't really know, is there hardware or formats where there is more >> > than 255? Or did you mean less than that? >> >> 30bit I'd assume wants more alpha. In the past we've done some fixed-point >> stuff (e.g. for LUT), using the 0.0-1.0 float range. Using that for the >> blend equation docs is also what I recommend (and that we map from 0-255 >> to 0.0-1.0 logically). Ofc the hw might not do any of that ... I think >> 0.16 fixed point, stored in a u16 is probably best. That's what we're >> doing for gamma tables already, and that way drivers can simply throw away >> the lower bits. > > But that would also break the two users of that property that won't be > able to move to the generic property (with the same name) without > breaking userspace. The point of that patch was to allow some code > consolidation, and that would mean failing to do so here :/ Let me try to clarify: - We'll keep the exact existing property semantics with the 0-255 range for the userspace visible property. - But internally, in the decode value that we store into drm_plane_state, we'll do the slightly more future proof thing with a few more bits. That gives us the option of exposing those bits in the future without having to change all the drivers again (which we have to do for this series here already anyway, since the decoded value moves into drm_plane_state from driver subclasses). Definitely not asking to break userspace here :-) Cheers, Daniel >> > > I know other drivers have skimped on the rules here a bit ... But at >> > > least >> > > internally (i.e. within the drm_plane_state) we probably should restrict >> > > ourselves to u8. And this needs real docs (i.e. the full blend equation >> > > drivers are supposed to implement). >> > >> > You mean straight vs premultiplied? Maybe we should implement this as >> > an additional property in read only depending on how the hardware >> > behaves? >> >> No need for an additional property right now, but definitely document >> whether you mean straight or pre-multiplied. Just writing down the blend >> equation is probably best. > > Ack. > > Thanks! > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/tegra: Fixes for v4.15-rc1
Hi Dave, Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes (2018-01-09 12:03:10 +1000) are available in the Git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.15-rc8 for you to fetch changes up to d780537f9b49e9d714a454e5ed989d909beab8ec: drm/tegra: sor: Fix hang on Tegra124 eDP (2018-01-10 13:04:58 +0100) Thanks, Thierry drm/tegra: Fixes for v4.15-rc8 A single fix for a Tegra124 eDP regression introduced by the SOR changes in v4.15-rc1. Thierry Reding (1): drm/tegra: sor: Fix hang on Tegra124 eDP drivers/gpu/drm/tegra/sor.c | 3 +++ 1 file changed, 3 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/tegra: Fixes for v4.15-rc8
Hi Dave, The following changes since commit b0bb222440a5c8273f67dd37946707e6ba6ad832: Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes (2018-01-09 12:03:10 +1000) are available in the Git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.15-rc8 for you to fetch changes up to d780537f9b49e9d714a454e5ed989d909beab8ec: drm/tegra: sor: Fix hang on Tegra124 eDP (2018-01-10 13:04:58 +0100) Thanks, Thierry drm/tegra: Fixes for v4.15-rc8 A single fix for a Tegra124 eDP regression introduced by the SOR changes in v4.15-rc1. Thierry Reding (1): drm/tegra: sor: Fix hang on Tegra124 eDP drivers/gpu/drm/tegra/sor.c | 3 +++ 1 file changed, 3 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 3/3] drm/amdgpu: Move to gtt before cpu accesses dma buf.
A good catch. I'll fix that.
Regards,
Samuel Li
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: Thursday, January 11, 2018 1:43 AM
> To: kbu...@01.org; Li, Samuel
> Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; Li, Samuel ; Dan Carpenter
>
> Subject: Re: [PATCH 3/3] drm/amdgpu: Move to gtt before cpu accesses dma
> buf.
>
>
> Hi Samuel,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on drm/drm-next] [also build test WARNING on
> v4.15-rc7 next-20180110] [if your patch is applied to the wrong git tree,
> please drop us a note to help improve the system]
>
> url:https://github.com/0day-ci/linux/commits/Samuel-Li/drm-amdgpu-
> allow-framebuffer-in-GART-memory-as-well/20180106-050432
> base: git://people.freedesktop.org/~airlied/linux.git drm-next
>
> smatch warnings:
> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c:226
> amdgpu_gem_prime_export() error: 'buf' dereferencing possible ERR_PTR()
>
> # https://github.com/0day-
> ci/linux/commit/6aa2afecb5a3efc463d200023839399571404843
> git remote add linux-review https://github.com/0day-ci/linux git remote
> update linux-review git checkout
> 6aa2afecb5a3efc463d200023839399571404843
> vim +/buf +226 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
>
> 6aa2afecb5 Samuel Li 2018-01-04 211
> d38ceaf99e Alex Deucher2015-04-20 212 struct dma_buf
> *amdgpu_gem_prime_export(struct drm_device *dev,
> d38ceaf99e Alex Deucher2015-04-20 213
> struct drm_gem_object *gobj,
> d38ceaf99e Alex Deucher2015-04-20 214
> int flags)
> d38ceaf99e Alex Deucher2015-04-20 215 {
> d38ceaf99e Alex Deucher2015-04-20 216struct amdgpu_bo *bo =
> gem_to_amdgpu_bo(gobj);
> 4b277247b1 Christian König 2017-11-13 217struct dma_buf *buf;
> d38ceaf99e Alex Deucher2015-04-20 218
> e1eb899b45 Christian König 2017-08-25 219if
> (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) ||
> e1eb899b45 Christian König 2017-08-25 220bo->flags &
> AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)
> d38ceaf99e Alex Deucher2015-04-20 221return ERR_PTR(-
> EPERM);
> d38ceaf99e Alex Deucher2015-04-20 222
> 4b277247b1 Christian König 2017-11-13 223buf =
> drm_gem_prime_export(dev, gobj, flags);
> 4b277247b1 Christian König 2017-11-13 224if (!IS_ERR(buf))
> 4b277247b1 Christian König 2017-11-13 225buf->file->f_mapping
> = dev->anon_inode->i_mapping;
> 6aa2afecb5 Samuel Li 2018-01-04 @226buf->ops =
> &amdgpu_dmabuf_ops;
> 6aa2afecb5 Samuel Li 2018-01-04 227
> 4b277247b1 Christian König 2017-11-13 228return buf;
> d38ceaf99e Alex Deucher2015-04-20 229 }
> 6aa2afecb5 Samuel Li 2018-01-04 230
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] drm/tegra: Fixes for v4.15-rc1
On Thu, Jan 11, 2018 at 05:41:17PM +0100, Thierry Reding wrote: > Hi Dave, > > Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes > (2018-01-09 12:03:10 +1000) > > are available in the Git repository at: > > git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.15-rc8 > > for you to fetch changes up to d780537f9b49e9d714a454e5ed989d909beab8ec: > > drm/tegra: sor: Fix hang on Tegra124 eDP (2018-01-10 13:04:58 +0100) > > Thanks, > Thierry I fat-fingered this, please disregard. Sorry, Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patch v2 2/2] dma-buf: clarify locking documentation for reservation_object_get_excl
The documentation was misleading, as for a lot of use-cases holding the RCU read side lock is sufficient. Signed-off-by: Lucas Stach --- include/linux/reservation.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/linux/reservation.h b/include/linux/reservation.h index 21fc84d82d41..ae1175e5997c 100644 --- a/include/linux/reservation.h +++ b/include/linux/reservation.h @@ -204,7 +204,8 @@ reservation_object_unlock(struct reservation_object *obj) * @obj: the reservation object * * Returns the exclusive fence (if any). Does NOT take a - * reference. The obj->lock must be held. + * reference. Writers must hold obj->lock, readers may only + * hold a RCU read side lock. * * RETURNS * The exclusive fence or NULL -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/tegra: Changes for v4.16-rc1 (with fixes)
Hi Dave, The following changes since commit ebae8d07435ae91314f4a28d69b530d09c625815: drm/tegra: dc: Implement legacy blending (2017-12-21 14:55:55 +0100) are available in the Git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.16-rc1-fixes for you to fetch changes up to 8f62142e490d761ceb92b55a7c05bb79294d6c6c: drm/tegra: dc: Properly cleanup overlay planes (2018-01-08 16:24:13 +0100) This has fixes for the issues that Dmitry had pointed out in response to my first pull request. It is based on top of my earlier pull request, so I've only included the shortlog of the changes since then. It should be safe to pull only this one in order to get all of the other changes as well. Thanks, Thierry drm/tegra: Changes for v4.16-rc1 The bulk of these changes are preparation work and addition of support for Tegra186. Currently only HDMI output (the primary output on Jetson TX2) is supported, but the hardware is also capable of doing DSI and DisplayPort. Tegra DRM now also uses the atomic commit helpers instead of the open- coded variant that was only doing half its job. As a bit of a byproduct of the Tegra186 support the driver also gained HDMI 2.0 as well as zpos property support. Along the way there are also a few patches to clean up a few things and fix minor issues. Thierry Reding (3): drm/tegra: dc: Restore YUV overlay support drm/tegra: dc: Fix possible_crtcs mask for planes drm/tegra: dc: Properly cleanup overlay planes drivers/gpu/drm/tegra/dc.c| 35 +++ drivers/gpu/drm/tegra/plane.c | 5 + 2 files changed, 28 insertions(+), 12 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Patch v2 1/2] dma-buf: add some lockdep asserts to the reservation object implementation
This adds lockdep asserts to the reservation functions which state in their
documentation that obj->lock must be held. Allows builds with PROVE_LOCKING
enabled to check that the locking requirements are met.
Signed-off-by: Lucas Stach
---
v2: remove erroneous check from reservation_object_get_excl
---
drivers/dma-buf/reservation.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index b44d9d7db347..accd398e2ea6 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -71,6 +71,8 @@ int reservation_object_reserve_shared(struct
reservation_object *obj)
struct reservation_object_list *fobj, *old;
u32 max;
+ reservation_object_assert_held(obj);
+
old = reservation_object_get_list(obj);
if (old && old->shared_max) {
@@ -211,6 +213,8 @@ void reservation_object_add_shared_fence(struct
reservation_object *obj,
{
struct reservation_object_list *old, *fobj = obj->staged;
+ reservation_object_assert_held(obj);
+
old = reservation_object_get_list(obj);
obj->staged = NULL;
@@ -236,6 +240,8 @@ void reservation_object_add_excl_fence(struct
reservation_object *obj,
struct reservation_object_list *old;
u32 i = 0;
+ reservation_object_assert_held(obj);
+
old = reservation_object_get_list(obj);
if (old)
i = old->shared_count;
@@ -276,6 +282,8 @@ int reservation_object_copy_fences(struct
reservation_object *dst,
size_t size;
unsigned i;
+ reservation_object_assert_held(dst);
+
rcu_read_lock();
src_list = rcu_dereference(src->fence);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs
Hi Daniel, > -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter > Sent: Thursday, January 11, 2018 12:06 AM > To: Hyun Kwon > Cc: Daniel Vetter ; dri-devel@lists.freedesktop.org; > devicet...@vger.kernel.org; Tejas Upadhyay ; Michal > Simek > Subject: Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs > > On Thu, Jan 11, 2018 at 02:05:31AM +, Hyun Kwon wrote: > > Hi Daniel, > > > > > -Original Message- > > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > > > Vetter > > > Sent: Tuesday, January 09, 2018 1:54 AM > > > To: Hyun Kwon > > > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Tejas > > > Upadhyay ; Michal Simek > > > Subject: Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs > > > > > > On Thu, Jan 04, 2018 at 06:05:59PM -0800, Hyun Kwon wrote: > > > > Debugfs can be used to exploit some specific setting. Main purpose > > > > is for testing and debug diagnostic. > > > > > > > > Signed-off-by: Tejas Upadhyay > > > > Signed-off-by: Hyun Kwon > > > > > > Hm, not sure what's the use, it seems to just be for setting/getting > > > your driver-private properties. Usually people use modetest and similar > > > tools, but if there's demand for setting properties in debugfs (we already > > > have all the infrastructure for dumping the entire kms state, see the > > > various atomic_print_state callbacks) I think that should be done with > > > generic drm code. > > > > > > I'd drop this patch for now (if there's no other reason for it). > > > > Thanks for the input. It'd be helpful, for my own understanding, if this > > can be elaborated a little more. We are using standard tools as well as > > custom script/tool, but some specific properties / controls are hard to > > be executed with modetest only unless we change the entire set up / > > design between each run. The debugfs is used to run all (or as much as > > possible) properties in a single run, and from what I understand, that > > doesn't violate intended debugfs usage as long as it's not treated as a > > stable ABI. The intention is to help isolate issues and enhance the > > diagnostics. I agree, in the long term, this kind of stuff should be > > handled in generic way, but would it be still reasonable to keep it > > driver specific in the meantime? > > Well since the property stuff needs more work anyway I think we could do > it properly (for upstream) from the start. > > What exactly is the issue with modetest? For intel we don't use it, we do > all our testing using the igt gpu tests: > > https://cgit.freedesktop.org/drm/igt > > A big pile of these tests also run on non-intel (and we're definitely very > much appreciating such work). But if you want just a bit of scripting, > modetest should be able to do it. If not I guess we'll need patches. For example, for DisplayPort, there are lane count / link rate, and the maximum values depend on the board or connected monitors. We are enforcing those values manually through debugfs before running tests. We will think how to remove the driver specific debugfs, and we can drop it for now. I'll take a look at the repo. Thanks for the pointer. Thanks, -hyun > -Daniel > > > > Thanks, > > -hyun > > > > > -Daniel > > > > > > > --- > > > > drivers/gpu/drm/xlnx/Kconfig | 21 +++ > > > > drivers/gpu/drm/xlnx/zynqmp_disp.c | 326 > > > + > > > > drivers/gpu/drm/xlnx/zynqmp_dp.c | 304 > > > ++ > > > > 3 files changed, 651 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig > > > > index 7c5529c..befce0f 100644 > > > > --- a/drivers/gpu/drm/xlnx/Kconfig > > > > +++ b/drivers/gpu/drm/xlnx/Kconfig > > > > @@ -21,3 +21,24 @@ config DRM_ZYNQMP_DPSUB > > > > this option if you have a Xilinx ZynqMP SoC with DisplayPort > > > > subsystem. The driver provides the kernel mode setting > > > > functionlaities for ZynqMP DP subsystem. > > > > + > > > > +config DRM_ZYNQMP_DISP_DEBUG_FS > > > > + bool "ZynqMP Display debugfs" > > > > + depends on DEBUG_FS && DRM_ZYNQMP_DPSUB > > > > + select DRM_ZYNQMP_DP_DEBUG_FS > > > > + help > > > > + Enable the debugfs code for DP Sub driver. The debugfs code > > > > + enables debugging or testing related features. It exposes some > > > > + low level controls to the user space to help testing > > > > automation, > > > > + as well as can enable additional diagnostic or statistical > > > > + information. > > > > + > > > > +config DRM_ZYNQMP_DP_DEBUG_FS > > > > + bool "ZynqMP DP debugfs" > > > > + depends on DEBUG_FS && DRM_ZYNQMP_DPSUB > > > > + help > > > > + Enable the debugfs code for DP driver. The debugfs code > > > > + enables debugging or testing related features. It exposes some > > > > + low level cont
[PATCH 0/3] Add R-Car V3M (R8A77970) support to the DU driver
Hello! Here's the set of 3 patches against the 'drm-next' branch of David Airlie's 'linux.git' repo plus the patch fixing LVDCR1 for R-Car gen3 posted recently. The main purpose of these patches is to add the R-Car V3M (R8A77970) support to the DU driver, we have to do some refactoring first to achieve this goal... [1/3] drm: rcar-du: lvds: refactor LVDS startup [2/3] drm: rcar-du: add 'model' field to 'struct rcar_du_device_info' [3/3] drm: rcar-du: add R8A77970 support MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: rcar-du: lvds: refactor LVDS startup
After the recent correction of the R-Car gen3 LVDCR1 value, already similar
enough at their ends rcar_du_lvdsenc_start_gen{2|3}() started asking for a
merge and it's becoming actually necessary with the addition the R-Car V3M
(R8A77970) support -- this gen3 SoC has gen2-like LVDPLLCR layout.
BTW, such a merge saves 72 bytes of the object code with AArch64 gcc 4.8.5.
Signed-off-by: Sergei Shtylyov
---
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 132 --
1 file changed, 54 insertions(+), 78 deletions(-)
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -39,98 +39,41 @@ static void rcar_lvds_write(struct rcar_
iowrite32(data, lvds->mmio + reg);
}
-static void rcar_du_lvdsenc_start_gen2(struct rcar_du_lvdsenc *lvds,
- struct rcar_du_crtc *rcrtc)
+static u32 rcar_lvds_gen2_lvdpllcr(unsigned int freq)
{
- const struct drm_display_mode *mode = &rcrtc->crtc.mode;
- unsigned int freq = mode->clock;
- u32 lvdcr0;
- u32 pllcr;
+ u32 lvdpllcr;
- /* PLL clock configuration */
if (freq < 39000)
- pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
+ lvdpllcr = LVDPLLCR_PLLDLYCNT_38M;
else if (freq < 61000)
- pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
+ lvdpllcr = LVDPLLCR_PLLDLYCNT_60M;
else if (freq < 121000)
- pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL |
LVDPLLCR_PLLDLYCNT_121M;
+ lvdpllcr = LVDPLLCR_PLLDLYCNT_121M;
else
- pllcr = LVDPLLCR_PLLDLYCNT_150M;
-
- rcar_lvds_write(lvds, LVDPLLCR, pllcr);
-
- /*
-* Select the input, hardcode mode 0, enable LVDS operation and turn
-* bias circuitry on.
-*/
- lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
- if (rcrtc->index == 2)
- lvdcr0 |= LVDCR0_DUSEL;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+ return LVDPLLCR_PLLDLYCNT_150M;
- /* Turn all the channels on. */
- rcar_lvds_write(lvds, LVDCR1,
- LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
- LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
-
- /*
-* Turn the PLL on, wait for the startup delay, and turn the output
-* on.
-*/
- lvdcr0 |= LVDCR0_PLLON;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
- usleep_range(100, 150);
-
- lvdcr0 |= LVDCR0_LVRES;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+ return lvdpllcr | LVDPLLCR_CEEN | LVDPLLCR_COSEL;
}
-static void rcar_du_lvdsenc_start_gen3(struct rcar_du_lvdsenc *lvds,
- struct rcar_du_crtc *rcrtc)
+static u32 rcar_lvds_gen3_lvdpllcr(unsigned int freq)
{
- const struct drm_display_mode *mode = &rcrtc->crtc.mode;
- unsigned int freq = mode->clock;
- u32 lvdcr0;
- u32 pllcr;
-
- /* PLL clock configuration */
if (freq < 42000)
- pllcr = LVDPLLCR_PLLDIVCNT_42M;
+ return LVDPLLCR_PLLDIVCNT_42M;
else if (freq < 85000)
- pllcr = LVDPLLCR_PLLDIVCNT_85M;
+ return LVDPLLCR_PLLDIVCNT_85M;
else if (freq < 128000)
- pllcr = LVDPLLCR_PLLDIVCNT_128M;
- else
- pllcr = LVDPLLCR_PLLDIVCNT_148M;
-
- rcar_lvds_write(lvds, LVDPLLCR, pllcr);
-
- /* Turn all the channels on. */
- rcar_lvds_write(lvds, LVDCR1,
- LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
- LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
-
- /*
-* Turn the PLL on, set it to LVDS normal mode, wait for the startup
-* delay and turn the output on.
-*/
- lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
- lvdcr0 |= LVDCR0_PWD;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+ return LVDPLLCR_PLLDIVCNT_128M;
- usleep_range(100, 150);
-
- lvdcr0 |= LVDCR0_LVRES;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+ return LVDPLLCR_PLLDIVCNT_148M;
}
static int rcar_du_lvdsenc_start(struct rcar_du_lvdsenc *lvds,
struct rcar_du_crtc *rcrtc)
{
- u32 lvdhcr;
+ u32 lvdhcr, lvdpllcr, lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
+ const struct drm_display_mode *mode = &rcrtc->crtc.mode;
+ unsigned int gen = lvds->dev->info->gen;
+ unsigned int freq = mode->clock;
int ret;
if (lvds->enabled)
@@ -158,14 +101,47 @@ static int rcar_du_lvdsenc_start(struct
else
lvdhcr = LVDCHCR_CHSEL_CH(0, 0) | LVDCHCR_CH
[PATCH 2/3] drm: rcar-du: add model field to struct rcar_du_device_info
In order to add the R-Car V3M (R8A77970) support to the DU driver we'd need
to keep track not only of the SoC generation but also of the exact model
(for the LVDS encoder support). Therefore add the 'model' field to the
'struct rcar_du_device_info' and initialize it accordingly for the already
supported SoCs.
Signed-off-by: Sergei Shtylyov
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c |9 +
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 14 ++
2 files changed, 23 insertions(+)
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -37,6 +37,7 @@
static const struct rcar_du_device_info rzg1_du_r8a7743_info = {
.gen = 2,
+ .model = R8A7743,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
| RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
@@ -58,6 +59,7 @@ static const struct rcar_du_device_info
static const struct rcar_du_device_info rzg1_du_r8a7745_info = {
.gen = 2,
+ .model = R8A7745,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
| RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
@@ -79,6 +81,7 @@ static const struct rcar_du_device_info
static const struct rcar_du_device_info rcar_du_r8a7779_info = {
.gen = 2,
+ .model = R8A7779,
.features = 0,
.num_crtcs = 2,
.routes = {
@@ -100,6 +103,7 @@ static const struct rcar_du_device_info
static const struct rcar_du_device_info rcar_du_r8a7790_info = {
.gen = 2,
+ .model = R8A7790,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
| RCAR_DU_FEATURE_EXT_CTRL_REGS,
.quirks = RCAR_DU_QUIRK_ALIGN_128B | RCAR_DU_QUIRK_LVDS_LANES,
@@ -128,6 +132,7 @@ static const struct rcar_du_device_info
/* M2-W (r8a7791) and M2-N (r8a7793) are identical */
static const struct rcar_du_device_info rcar_du_r8a7791_info = {
.gen = 2,
+ .model = R8A7791,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
| RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
@@ -150,6 +155,7 @@ static const struct rcar_du_device_info
static const struct rcar_du_device_info rcar_du_r8a7792_info = {
.gen = 2,
+ .model = R8A7792,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
| RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
@@ -169,6 +175,7 @@ static const struct rcar_du_device_info
static const struct rcar_du_device_info rcar_du_r8a7794_info = {
.gen = 2,
+ .model = R8A7794,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
| RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
@@ -191,6 +198,7 @@ static const struct rcar_du_device_info
static const struct rcar_du_device_info rcar_du_r8a7795_info = {
.gen = 3,
+ .model = R8A7795,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
| RCAR_DU_FEATURE_EXT_CTRL_REGS
| RCAR_DU_FEATURE_VSP1_SOURCE,
@@ -223,6 +231,7 @@ static const struct rcar_du_device_info
static const struct rcar_du_device_info rcar_du_r8a7796_info = {
.gen = 3,
+ .model = R8A7796,
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
| RCAR_DU_FEATURE_EXT_CTRL_REGS
| RCAR_DU_FEATURE_VSP1_SOURCE,
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -49,9 +49,22 @@ struct rcar_du_output_routing {
unsigned int port;
};
+enum rcar_du_model {
+ R8A7743,
+ R8A7745,
+ R8A7779,
+ R8A7790,
+ R8A7791,
+ R8A7792,
+ R8A7794,
+ R8A7795,
+ R8A7796,
+};
+
/*
* struct rcar_du_device_info - DU model-specific information
* @gen: device generation (2 or 3)
+ * @model: device model
* @features: device features (RCAR_DU_FEATURE_*)
* @quirks: device quirks (RCAR_DU_QUIRK_*)
* @num_crtcs: total number of CRTCs
@@ -60,6 +73,7 @@ struct rcar_du_output_routing {
*/
struct rcar_du_device_info {
unsigned int gen;
+ enum rcar_du_model model;
unsigned int features;
unsigned int quirks;
unsigned int num_crtcs;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm: rcar-du: add R8A77970 support
Add support for the R-Car V3M (R8A77970) SoC to the DU driver (this SoC
has only 1 display port). Note that there are some differences with the
other R-Car gen3 SoCs in the LVDS encoder part, e.g. LVDPLLCR has the same
layout as on the R-Car gen2 SoCs...
Signed-off-by: Sergei Shtylyov
---
Documentation/devicetree/bindings/display/renesas,du.txt |1
drivers/gpu/drm/rcar-du/rcar_du_drv.c| 23 +++
drivers/gpu/drm/rcar-du/rcar_du_drv.h|1
drivers/gpu/drm/rcar-du/rcar_du_group.c | 10 +++---
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c| 20 +
5 files changed, 45 insertions(+), 10 deletions(-)
Index: linux/Documentation/devicetree/bindings/display/renesas,du.txt
===
--- linux.orig/Documentation/devicetree/bindings/display/renesas,du.txt
+++ linux/Documentation/devicetree/bindings/display/renesas,du.txt
@@ -13,6 +13,7 @@ Required Properties:
- "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
- "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
- "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
+- "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
- reg: A list of base address and length of each memory resource, one for
each entry in the reg-names property.
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -258,6 +258,28 @@ static const struct rcar_du_device_info
.dpll_ch = BIT(1),
};
+static const struct rcar_du_device_info rcar_du_r8a77970_info = {
+ .gen = 3,
+ .model = R8A77970,
+ .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS
+ | RCAR_DU_FEATURE_VSP1_SOURCE,
+ .num_crtcs = 1,
+ .routes = {
+ /* R8A77970 has one RGB output and one LVDS output. */
+ [RCAR_DU_OUTPUT_DPAD0] = {
+ .possible_crtcs = BIT(0),
+ .port = 1,
+ },
+ [RCAR_DU_OUTPUT_LVDS0] = {
+ .possible_crtcs = BIT(0),
+ .port = 0,
+ },
+ },
+ .num_lvds = 1,
+ .dpll_ch = BIT(1),
+};
+
static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info },
{ .compatible = "renesas,du-r8a7745", .data = &rzg1_du_r8a7745_info },
@@ -269,6 +291,7 @@ static const struct of_device_id rcar_du
{ .compatible = "renesas,du-r8a7794", .data = &rcar_du_r8a7794_info },
{ .compatible = "renesas,du-r8a7795", .data = &rcar_du_r8a7795_info },
{ .compatible = "renesas,du-r8a7796", .data = &rcar_du_r8a7796_info },
+ { .compatible = "renesas,du-r8a77970", .data = &rcar_du_r8a77970_info },
{ }
};
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -59,6 +59,7 @@ enum rcar_du_model {
R8A7794,
R8A7795,
R8A7796,
+ R8A77970,
};
/*
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_group.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -133,10 +133,12 @@ static void rcar_du_group_setup(struct r
rcar_du_group_write(rgrp, DORCR, DORCR_PG1D_DS1 | DORCR_DPRS);
/* Apply planes to CRTCs association. */
- mutex_lock(&rgrp->lock);
- rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
- rgrp->dptsr_planes);
- mutex_unlock(&rgrp->lock);
+ if (rcdu->info->num_crtcs > 1) {
+ mutex_lock(&rgrp->lock);
+ rcar_du_group_write(rgrp, DPTSR, (rgrp->dptsr_planes << 16) |
+ rgrp->dptsr_planes);
+ mutex_unlock(&rgrp->lock);
+ }
}
/*
Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -71,8 +71,10 @@ static int rcar_du_lvdsenc_start(struct
struct rcar_du_crtc *rcrtc)
{
u32 lvdhcr, lvdpllcr, lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
+ const struct rcar_du_device_info *info = lvds->dev->info;
const struct drm_display_mode *mode = &rcrtc->crtc.mode;
- unsigned int gen = lvds->dev->info->gen;
+ unsigned int gen = info->gen;
+ enum rcar_du_model model = info->model;
Re: [PATCH 06/19] drm/blend: Add a generic alpha property
Hi Daniel, On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote: > On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote: > > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote: > >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote: > >>> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote: > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote: > > Some drivers duplicate the logic to create a property to store a > > per-plane alpha. > > > > Let's create a helper in order to move that to the core. > > > > Cc: Boris Brezillon > > Cc: Laurent Pinchart > > Signed-off-by: Maxime Ripard > > Do we have userspace for this? > >>> > >>> Wayland seems to be on its way to implement this, with ChromeOS using > >>> it: > >>> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741 > >>> .html > >>> > >>> and more specifically: > >>> https://chromium.googlesource.com/chromium/src/+/master/third_party/way > >>> land-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1 > >>> .xml#118 > >> > >> Yay, would be good to include these links in the patch description. > >> Really happy we're having a real standard now used by multiple people. > > > > I will. > > > >> > > Is encoding a fixed 0-255 range really the best idea? > >> > > >> > I don't really know, is there hardware or formats where there is more > >> > than 255? Or did you mean less than that? > >> > >> 30bit I'd assume wants more alpha. In the past we've done some > >> fixed-point stuff (e.g. for LUT), using the 0.0-1.0 float range. Using > >> that for the blend equation docs is also what I recommend (and that we > >> map from 0-255 to 0.0-1.0 logically). Ofc the hw might not do any of that > >> ... I think 0.16 fixed point, stored in a u16 is probably best. That's > >> what we're doing for gamma tables already, and that way drivers can > >> simply throw away the lower bits. > > > > But that would also break the two users of that property that won't be > > able to move to the generic property (with the same name) without > > breaking userspace. The point of that patch was to allow some code > > consolidation, and that would mean failing to do so here :/ > > Let me try to clarify: > - We'll keep the exact existing property semantics with the 0-255 > range for the userspace visible property. > > - But internally, in the decode value that we store into > drm_plane_state, we'll do the slightly more future proof thing with a > few more bits. > > That gives us the option of exposing those bits in the future without > having to change all the drivers again (which we have to do for this > series here already anyway, since the decoded value moves into > drm_plane_state from driver subclasses). > > Definitely not asking to break userspace here :-) As the property range is available to userspace, we could allow drivers to expose a driver-dependent number of bits for the alpha value without breaking anything. We can even require new drivers to expose 16 bits regardless of the number of bits that the hardware can handle, or we could keep that driver- specific. Please note, however, that U0.16 can only represent [0.0, 0.84741...] while we need [0.0, 1.0]. As all the hardware I know map the full range of values ([0, 255] for 8-bit for instance) to [0.0, 1.0] I wouldn't pretend that the 16-bit value exposed to userspace is U0.16. > I know other drivers have skimped on the rules here a bit ... But at > least internally (i.e. within the drm_plane_state) we probably should > restrict ourselves to u8. And this needs real docs (i.e. the full blend > equation drivers are supposed to implement). > >>> > >>> You mean straight vs premultiplied? Maybe we should implement this as > >>> an additional property in read only depending on how the hardware > >>> behaves? > >> > >> No need for an additional property right now, but definitely document > >> whether you mean straight or pre-multiplied. Just writing down the blend > >> equation is probably best. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms bindings
Hi Rob,
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Thursday, January 11, 2018 6:43 AM
> To: Hyun Kwon
> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
> Simek
> Subject: Re: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms
> bindings
>
> On Wed, Jan 10, 2018 at 8:04 PM, Hyun Kwon wrote:
> > Hi Rob,
> >
> > Thanks for the feedback.
> >
> >> -Original Message-
> >> From: Rob Herring [mailto:r...@kernel.org]
> >> Sent: Monday, January 08, 2018 8:00 PM
> >> To: Hyun Kwon
> >> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Michal
> >> Simek
> >> Subject: Re: [PATCH 01/10] dt-bindings: display: xlnx: Add Xilinx kms
> >> bindings
> >>
> >> On Thu, Jan 04, 2018 at 06:05:50PM -0800, Hyun Kwon wrote:
> >> > The dt binding for Xilinx DRM KMS driver.
> >>
> >> Bindings are for h/w, not drivers.
> >
> > I'll rephrase this.
> >
> >>
> >> >
> >> > Signed-off-by: Hyun Kwon
> >> > ---
> >> > .../devicetree/bindings/display/xlnx/xlnx,kms.txt| 20
> >>
> >> > 1 file changed, 20 insertions(+)
> >> > create mode 100644
> >> Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> >> >
> >> > diff --git
> a/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> >> b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> >> > new file mode 100644
> >> > index 000..8dcd552
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,kms.txt
> >> > @@ -0,0 +1,20 @@
> >> > +Xilinx KMS Pipeline
> >> > +---
> >> > +
> >> > +Xilinx display pipelines can be designed with hardened video IPs and
> soft
> >> video
> >> > +IPs in programmable logic. This KMS module provides the common
> >> functionality
> >> > +of individual subdevice drivers, and glue logics between them.
> >> > +
> >> > +Required properties:
> >> > +
> >> > +- compatible: Must be "xlnx,kms".
> >
> > I'll also rephrase the description and rename this to xlnx,display.
> >
> >> > +
> >> > +- ports: phandles for CRTC ports, using the DT bindings defined in
> >> > + Documentation/devicetree/bindings/graph.txt.
> >>
> >> This use of ports is not part of the graph binding.
> >
> > I'll add more details in the description.
> >
> >>
> >> > +
> >> > +Example:
> >> > +
> >> > + xlnx_drm: xlnx_drm {
> >> > + compatible = "xlnx,kms";
> >>
> >> drm and kms are Linuxisms.
> >
> > I agree. I'll remove linux subsystem specific terms.
> >
> >>
> >> Why do you need this node?
> >
> > This node is used to represent a display pipeline as a single entity, which
> can consist of multiple components / IPs. I'll elaborate more per your
> suggestion.
>
> You generally don't need that. Just have the DRM driver match with the
> first block in the display pipeline. Then use the OF graph to connect
> to the other components in the pipeline. It would help to have a block
> diagram showing the data pipelines and h/w blocks.
>
Some examples are as following. In simple case, a pipeline is linear with
multiple blocks:
ZynqMP DisplayPort pipeline:
ZynqMP DMA -> ZynqMP Display controller -> ZynqMP DP encoder
FPGA display pipeline where each block comes as a separate device:
FPGA DMA -> FPGA mixer -> FPGA HDMI encoder
It gets more interesting as those can be mixed:
ZynqMP DMA -> ZynqMP Display controller -> ZynqMP DP encoder
|
FPAG DMA ->
or
ZynqMP DMA -> ZynqMP Display controller -> ZynqMP DP encoder
|
-> FPGA HDMI encoder
Or even,
ZynqMP DMA -> ZynqMP Display controller -> ZynqMP DP
encoder
| |
FPAG DMA -> FPGA mixer -> ->
FPGA HDMI encoder
This node is representation of such variations as a single pipeline device.
Thanks,
-hyun
> Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/prime: Remove duplicate forward declaration
From: Thierry Reding struct device is forward-declared twice. Remove the second instance. Signed-off-by: Thierry Reding --- include/drm/drm_prime.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h index 9cd9e36f77b5..59ccab402e85 100644 --- a/include/drm/drm_prime.h +++ b/include/drm/drm_prime.h @@ -59,8 +59,6 @@ struct drm_device; struct drm_gem_object; struct drm_file; -struct device; - struct dma_buf *drm_gem_prime_export(struct drm_device *dev, struct drm_gem_object *obj, int flags); -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4 v6] drm/pl111: Support handling bridge timings
Linus Walleij writes:
> If the bridge has a too strict setup time for the incoming
> signals, we may not be fast enough and then we need to
> compensate by outputting the signal on the inverse clock
> edge so it is for sure stable when the bridge samples it.
>
> Since bridges in difference to panels does not expose their
> connectors, make the connector optional in the display
> setup code.
>
> Acked-by: Laurent Pinchart
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v5->v6:
> - Collect Laurent's ACK.
> ChangeLog v4->v5:
> - Use the new bridge timings setup method.
> ---
> drivers/gpu/drm/pl111/Kconfig | 1 +
> drivers/gpu/drm/pl111/pl111_display.c | 35
> +++
> drivers/gpu/drm/pl111/pl111_drv.c | 20 +++-
> 3 files changed, 43 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> index e5e2abd66491..82cb3e60ddc8 100644
> --- a/drivers/gpu/drm/pl111/Kconfig
> +++ b/drivers/gpu/drm/pl111/Kconfig
> @@ -8,6 +8,7 @@ config DRM_PL111
> select DRM_GEM_CMA_HELPER
> select DRM_BRIDGE
> select DRM_PANEL_BRIDGE
> + select DRM_DUMB_VGA_DAC
> select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> help
> Choose this option for DRM support for the PL111 CLCD controller.
Should this be in PL111, or in whatever machine is a consumer of this
driver plus a dumb dac? I'm OK either way, it's not a big deal for the
platform I've got.
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
> b/drivers/gpu/drm/pl111/pl111_drv.c
> index 201d57d5cb54..101a9c7db6ff 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -107,11 +107,17 @@ static int pl111_modeset_init(struct drm_device *dev)
> ret = PTR_ERR(bridge);
> goto out_config;
> }
> - /*
> - * TODO: when we are using a different bridge than a panel
> - * (such as a dumb VGA connector) we need to devise a different
> - * method to get the connector out of the bridge.
> - */
> + } else if (bridge) {
> + dev_info(dev->dev, "Using non-panel bridge\n");
This looks like it might be a debug printf you didn't intend to leave
in. Either way, the patch gets my:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4 v6] drm/bridge: Provide a way to embed timing info in bridges
Daniel Vetter writes:
> On Wed, Jan 10, 2018 at 03:12:24PM +0100, Linus Walleij wrote:
>> After some discussion and failed patch sets trying to convey
>> the right timing information between the display engine and
>> a bridge using the connector, I try instead to use an optional
>> timing information container in the bridge itself, so that
>> display engines can retrieve it from any bridge and use it to
>> determine how to drive outputs.
>>
>> Signed-off-by: Linus Walleij
>> ---
>> ChangeLog v5->v6:
>> - Sort forward struct declarations alphabetically
>> - Switch to using DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE to indicate
>> positive or negatice clock samling edge
>> ChangeLog ->v5:
>> - New patch
>> ---
>> include/drm/drm_bridge.h | 21 +
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index 682d01ba920c..28c9ac6d9036 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -29,6 +29,7 @@
>> #include
>>
>> struct drm_bridge;
>> +struct drm_bridge_timings;
>> struct drm_panel;
>>
>> /**
>> @@ -222,6 +223,23 @@ struct drm_bridge_funcs {
>> void (*enable)(struct drm_bridge *bridge);
>> };
>>
>> +/**
>> + * struct drm_bridge_timings - timing information for the bridge
>> + * @sampling_edge: whether the bridge samples the digital input signal from
>> the
>> + * display engine on the positive or negative edge of the clock, this should
>> + * reuse the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE bitwise flags from the DRM
>> + * connector (bit 2 and 3 valid)
>> + * @setup_time_ps: the time in picoseconds the input data lines must be
>> stable
>> + * before the clock edge
>> + * @hold_time_ps: the time in picoseconds taken for the bridge to sample the
>> + * input signal after the clock edge
>> + */
>
> Just a style nit: for longer kerneldoc comments for struct members the
> in-line style, split up for each member, is imo better.
> -Daniel
The new style also discourages the comments getting out of sync with the
code. I'd be happy to r-b with them moved.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/prime: Remove duplicate forward declaration
Quoting Thierry Reding (2018-01-11 20:17:30) > From: Thierry Reding > > struct device is forward-declared twice. Remove the second instance. So good they declared it twice. Also the first one first in with the alphabetical ordering. > Signed-off-by: Thierry Reding Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #20 from Alex Deucher --- Everything looks like it's implemented properly in the code to enable HBR audio. Take a look at: drivers/gpu/drm/amd/display/dc/dce/dce_audio.c for audio configuration drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c for display stream infoframes Can you add some debugging output to dce_aud_az_configure() to see why it may not be getting enabled in your case? Specifically see if is_audio_format_supported() is failing for HBR formats and why and see if set_high_bit_rate_capable() is getting enabled. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly
Hi Jani, On Thursday, 11 January 2018 16:31:59 EET Jani Nikula wrote: > On Thu, 11 Jan 2018, Laurent Pinchart wrote: > > My preference, however, would be for devm_regulator_get_optional() to > > return NULL when no regulator is present. The current implementation > > returns -ENODEV in multiple cases, making it impossible to properly > > discriminate between having no regulator and not being able to get the > > regulator due to an error. > > Just a word of warning, IS_ERR(NULL) is false, and your proposed change > would apparently require quite a churn all over the kernel. That's correct, but I still think that would make the API clearer. I don't want to block this patch until we make such a change, but it's a good opportunity to discuss it. I'd like to know what Mark's opinion is. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland
https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #15 from Bong Cosca --- [39409/39409] skip: 2874, pass: 15671, warn: 12, fail: 20845, crash: 7 Piglit results haven't changed much since, but notably with more crashes. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/nouveau: Remove redundant _get
From: Thierry Reding
The nouveau_fence_get_get_driver_name() function has a redundant _get in
its name. Remove it.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 503fa94dc06d..9c8f3a154d55 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -426,7 +426,7 @@ nouveau_fence_new(struct nouveau_channel *chan, bool sysmem,
return ret;
}
-static const char *nouveau_fence_get_get_driver_name(struct dma_fence *fence)
+static const char *nouveau_fence_get_driver_name(struct dma_fence *fence)
{
return "nouveau";
}
@@ -496,7 +496,7 @@ static void nouveau_fence_release(struct dma_fence *f)
}
static const struct dma_fence_ops nouveau_fence_ops_legacy = {
- .get_driver_name = nouveau_fence_get_get_driver_name,
+ .get_driver_name = nouveau_fence_get_driver_name,
.get_timeline_name = nouveau_fence_get_timeline_name,
.enable_signaling = nouveau_fence_no_signaling,
.signaled = nouveau_fence_is_signaled,
@@ -523,7 +523,7 @@ static bool nouveau_fence_enable_signaling(struct dma_fence
*f)
}
static const struct dma_fence_ops nouveau_fence_ops_uevent = {
- .get_driver_name = nouveau_fence_get_get_driver_name,
+ .get_driver_name = nouveau_fence_get_driver_name,
.get_timeline_name = nouveau_fence_get_timeline_name,
.enable_signaling = nouveau_fence_enable_signaling,
.signaled = nouveau_fence_is_signaled,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/nouveau: tegra: Use IOMMU groups
From: Thierry Reding
Use IOMMU groups to attach the GPU to its IOMMU domain. This is not
strictly necessary because the domain isn't shared with any other
device, but it makes the code consistent with how IOMMU is handled in
other drivers and provides an easy way to detect when no IOMMU has
been attached via device tree.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/include/nvkm/core/tegra.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 18 +++---
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/tegra.h
b/drivers/gpu/drm/nouveau/include/nvkm/core/tegra.h
index 5c102d0206a7..5a9a796380dc 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/core/tegra.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/core/tegra.h
@@ -25,6 +25,7 @@ struct nvkm_device_tegra {
struct nvkm_mm mm;
struct iommu_domain *domain;
+ struct iommu_group *group;
unsigned long pgshift;
} iommu;
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index 78597da6313a..1f07999aea1d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -110,7 +110,8 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra
*tdev)
mutex_init(&tdev->iommu.mutex);
- if (iommu_present(&platform_bus_type)) {
+ tdev->iommu.group = iommu_group_get(dev);
+ if (tdev->iommu.group) {
tdev->iommu.domain = iommu_domain_alloc(&platform_bus_type);
if (!tdev->iommu.domain)
goto error;
@@ -132,7 +133,7 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra
*tdev)
tdev->iommu.pgshift -= 1;
}
- ret = iommu_attach_device(tdev->iommu.domain, dev);
+ ret = iommu_attach_group(tdev->iommu.domain, tdev->iommu.group);
if (ret)
goto free_domain;
@@ -140,19 +141,21 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra
*tdev)
(1ULL << tdev->func->iommu_bit) >>
tdev->iommu.pgshift, 1);
if (ret)
- goto detach_device;
+ goto detach_group;
}
return;
-detach_device:
- iommu_detach_device(tdev->iommu.domain, dev);
+detach_group:
+ iommu_detach_group(tdev->iommu.domain, tdev->iommu.group);
free_domain:
iommu_domain_free(tdev->iommu.domain);
error:
+ iommu_group_put(tdev->iommu.group);
tdev->iommu.domain = NULL;
+ tdev->iommu.group = NULL;
tdev->iommu.pgshift = 0;
dev_err(dev, "cannot initialize IOMMU MM\n");
#endif
@@ -162,10 +165,11 @@ static void
nvkm_device_tegra_remove_iommu(struct nvkm_device_tegra *tdev)
{
#if IS_ENABLED(CONFIG_IOMMU_API)
- if (tdev->iommu.domain) {
+ if (tdev->iommu.group && tdev->iommu.domain) {
nvkm_mm_fini(&tdev->iommu.mm);
- iommu_detach_device(tdev->iommu.domain, tdev->device.dev);
+ iommu_detach_group(tdev->iommu.domain, tdev->iommu.group);
iommu_domain_free(tdev->iommu.domain);
+ iommu_group_put(tdev->iommu.group);
}
#endif
}
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/nouveau: Provide custom struct dma_buf_ops
From: Thierry Reding
Instead of relying on the DRM PRIME helpers to provide all of the
DMA-BUF operations, provide a custom version of struct dma_buf_ops to
allow additional functionality to be implemented.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +-
drivers/gpu/drm/nouveau/nouveau_gem.h | 15 +--
drivers/gpu/drm/nouveau/nouveau_prime.c | 157 +---
3 files changed, 135 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 56fe261b6268..3ce2f02e9e58 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1081,15 +1081,12 @@ driver_stub = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
- .gem_prime_export = drm_gem_prime_export,
- .gem_prime_import = drm_gem_prime_import,
+ .gem_prime_export = nouveau_gem_prime_export,
+ .gem_prime_import = nouveau_gem_prime_import,
.gem_prime_pin = nouveau_gem_prime_pin,
- .gem_prime_res_obj = nouveau_gem_prime_res_obj,
.gem_prime_unpin = nouveau_gem_prime_unpin,
+ .gem_prime_res_obj = nouveau_gem_prime_res_obj,
.gem_prime_get_sg_table = nouveau_gem_prime_get_sg_table,
- .gem_prime_import_sg_table = nouveau_gem_prime_import_sg_table,
- .gem_prime_vmap = nouveau_gem_prime_vmap,
- .gem_prime_vunmap = nouveau_gem_prime_vunmap,
.gem_free_object_unlocked = nouveau_gem_object_del,
.gem_open_object = nouveau_gem_object_open,
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.h
b/drivers/gpu/drm/nouveau/nouveau_gem.h
index fe39998f65cc..eb55c1eb1d9f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.h
@@ -32,13 +32,14 @@ extern int nouveau_gem_ioctl_cpu_fini(struct drm_device *,
void *,
extern int nouveau_gem_ioctl_info(struct drm_device *, void *,
struct drm_file *);
-extern int nouveau_gem_prime_pin(struct drm_gem_object *);
+struct dma_buf *nouveau_gem_prime_export(struct drm_device *dev,
+struct drm_gem_object *obj,
+int flags);
+struct drm_gem_object *nouveau_gem_prime_import(struct drm_device *drm,
+ struct dma_buf *buf);
+int nouveau_gem_prime_pin(struct drm_gem_object *obj);
+void nouveau_gem_prime_unpin(struct drm_gem_object *obj);
struct reservation_object *nouveau_gem_prime_res_obj(struct drm_gem_object *);
-extern void nouveau_gem_prime_unpin(struct drm_gem_object *);
-extern struct sg_table *nouveau_gem_prime_get_sg_table(struct drm_gem_object
*);
-extern struct drm_gem_object *nouveau_gem_prime_import_sg_table(
- struct drm_device *, struct dma_buf_attachment *, struct sg_table *);
-extern void *nouveau_gem_prime_vmap(struct drm_gem_object *);
-extern void nouveau_gem_prime_vunmap(struct drm_gem_object *, void *);
+struct sg_table *nouveau_gem_prime_get_sg_table(struct drm_gem_object *obj);
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 1fefc93af1d7..63cf4aca2d8e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -23,69 +23,152 @@
*/
#include
+#include
#include
#include "nouveau_drv.h"
#include "nouveau_gem.h"
-struct sg_table *nouveau_gem_prime_get_sg_table(struct drm_gem_object *obj)
+static void *nouveau_gem_prime_kmap_atomic(struct dma_buf *buf,
+ unsigned long page)
{
- struct nouveau_bo *nvbo = nouveau_gem_object(obj);
- int npages = nvbo->bo.num_pages;
+ return NULL;
+}
- return drm_prime_pages_to_sg(nvbo->bo.ttm->pages, npages);
+static void nouveau_gem_prime_kunmap_atomic(struct dma_buf *buf,
+ unsigned long page, void *addr)
+{
}
-void *nouveau_gem_prime_vmap(struct drm_gem_object *obj)
+static void *nouveau_gem_prime_kmap(struct dma_buf *buf, unsigned long page)
{
- struct nouveau_bo *nvbo = nouveau_gem_object(obj);
+ return NULL;
+}
+
+static void nouveau_gem_prime_kunmap(struct dma_buf *buf, unsigned long page,
+void *addr)
+{
+}
+
+static void *nouveau_gem_prime_vmap(struct dma_buf *buf)
+{
+ struct nouveau_bo *bo = nouveau_gem_object(buf->priv);
int ret;
- ret = ttm_bo_kmap(&nvbo->bo, 0, nvbo->bo.num_pages,
- &nvbo->dma_buf_vmap);
+ ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, &bo->dma_buf_vmap);
if (ret)
return ERR_PTR(ret);
- return nvbo->dma_buf_vmap.virtual;
+ return bo->dma_buf_vmap.virtual;
}
-void nouveau_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
+static void nouveau_gem_prime_vunmap(
[PATCH 4/5] drm/nouveau: prime: Implement mmap()
From: Thierry Reding
Provide an implementation of mmap() for PRIME exported buffers. This
allows userspace to map these buffers and access them using the CPU.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_prime.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 63cf4aca2d8e..5d885d7cb059 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -50,6 +50,37 @@ static void nouveau_gem_prime_kunmap(struct dma_buf *buf,
unsigned long page,
{
}
+static inline u64 nouveau_bo_mmap_offset(struct nouveau_bo *bo)
+{
+ return drm_vma_node_offset_addr(&bo->bo.vma_node) >> PAGE_SHIFT;
+}
+
+static int nouveau_gem_prime_mmap(struct dma_buf *buf,
+ struct vm_area_struct *vma)
+{
+ struct nouveau_bo *bo = nouveau_gem_object(buf->priv);
+ struct drm_gem_object *obj = buf->priv;
+ int ret;
+
+ /* check for valid size */
+ if (obj->size < vma->vm_end - vma->vm_start)
+ return -EINVAL;
+
+ vma->vm_pgoff += nouveau_bo_mmap_offset(bo);
+
+ if (unlikely(vma->vm_pgoff < DRM_FILE_PAGE_OFFSET))
+ return drm_legacy_mmap(vma->vm_file, vma);
+
+ ret = drm_vma_node_allow(&obj->vma_node, vma->vm_file->private_data);
+ if (ret)
+ return ret;
+
+ ret = ttm_bo_mmap(vma->vm_file, vma, bo->bo.bdev);
+ drm_vma_node_revoke(&obj->vma_node, vma->vm_file->private_data);
+
+ return ret;
+}
+
static void *nouveau_gem_prime_vmap(struct dma_buf *buf)
{
struct nouveau_bo *bo = nouveau_gem_object(buf->priv);
@@ -79,6 +110,7 @@ static const struct dma_buf_ops nouveau_gem_prime_dmabuf_ops
= {
.unmap_atomic = nouveau_gem_prime_kunmap_atomic,
.map = nouveau_gem_prime_kmap,
.unmap = nouveau_gem_prime_kunmap,
+ .mmap = nouveau_gem_prime_mmap,
.vmap = nouveau_gem_prime_vmap,
.vunmap = nouveau_gem_prime_vunmap,
};
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/prime: Export more helpers for drivers
From: Thierry Reding
Export some more of the helpers in order to allow drivers to more fine-
grainedly select which helpers to use. This gives drivers an easy way to
reuse a lot of the code in the helpers while at the same time allowing
them to provide their own implementation for other functions in struct
dma_buf_ops.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_prime.c | 23 +--
include/drm/drm_prime.h | 12
2 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9a17725b0f7a..f9903e6b59f6 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -180,9 +180,8 @@ static int drm_prime_lookup_buf_handle(struct
drm_prime_file_private *prime_fpri
return -ENOENT;
}
-static int drm_gem_map_attach(struct dma_buf *dma_buf,
- struct device *target_dev,
- struct dma_buf_attachment *attach)
+int drm_gem_map_attach(struct dma_buf *dma_buf, struct device *target_dev,
+ struct dma_buf_attachment *attach)
{
struct drm_prime_attachment *prime_attach;
struct drm_gem_object *obj = dma_buf->priv;
@@ -200,9 +199,10 @@ static int drm_gem_map_attach(struct dma_buf *dma_buf,
return dev->driver->gem_prime_pin(obj);
}
+EXPORT_SYMBOL(drm_gem_map_attach);
-static void drm_gem_map_detach(struct dma_buf *dma_buf,
- struct dma_buf_attachment *attach)
+void drm_gem_map_detach(struct dma_buf *dma_buf,
+ struct dma_buf_attachment *attach)
{
struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = dma_buf->priv;
@@ -228,6 +228,7 @@ static void drm_gem_map_detach(struct dma_buf *dma_buf,
kfree(prime_attach);
attach->priv = NULL;
}
+EXPORT_SYMBOL(drm_gem_map_detach);
void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private
*prime_fpriv,
struct dma_buf *dma_buf)
@@ -254,8 +255,8 @@ void drm_prime_remove_buf_handle_locked(struct
drm_prime_file_private *prime_fpr
}
}
-static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
- enum dma_data_direction dir)
+struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
+enum dma_data_direction dir)
{
struct drm_prime_attachment *prime_attach = attach->priv;
struct drm_gem_object *obj = attach->dmabuf->priv;
@@ -291,13 +292,15 @@ static struct sg_table *drm_gem_map_dma_buf(struct
dma_buf_attachment *attach,
return sgt;
}
+EXPORT_SYMBOL(drm_gem_map_dma_buf);
-static void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
- struct sg_table *sgt,
- enum dma_data_direction dir)
+void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
+ struct sg_table *sgt,
+ enum dma_data_direction dir)
{
/* nothing to be done here */
}
+EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
/**
* drm_gem_dmabuf_export - dma_buf export implementation for GEM
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index 59ccab402e85..3a9706815773 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -50,8 +50,10 @@ struct drm_prime_file_private {
struct rb_root handles;
};
+enum dma_data_direction;
struct device;
+struct dma_buf_attachment;
struct dma_buf_export_info;
struct dma_buf;
@@ -59,6 +61,16 @@ struct drm_device;
struct drm_gem_object;
struct drm_file;
+int drm_gem_map_attach(struct dma_buf *dma_buf, struct device *target_dev,
+ struct dma_buf_attachment *attach);
+void drm_gem_map_detach(struct dma_buf *dma_buf,
+ struct dma_buf_attachment *attach);
+struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
+enum dma_data_direction dir);
+void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
+ struct sg_table *sgt,
+ enum dma_data_direction dir);
+
struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *obj,
int flags);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/prime: Remove duplicate forward declaration
From: Thierry Reding struct device is forward-declared twice. Remove the second instance. Reviewed-by: Chris Wilson Signed-off-by: Thierry Reding --- include/drm/drm_prime.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h index 9cd9e36f77b5..59ccab402e85 100644 --- a/include/drm/drm_prime.h +++ b/include/drm/drm_prime.h @@ -59,8 +59,6 @@ struct drm_device; struct drm_gem_object; struct drm_file; -struct device; - struct dma_buf *drm_gem_prime_export(struct drm_device *dev, struct drm_gem_object *obj, int flags); -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/nouveau: prime: Implement cache maintenance
From: Thierry Reding
Implement the ->begin_cpu_access() and ->end_cpu_access() callbacks to
allow userspace to invalidate the cache before accessing a buffer that
is exported using PRIME and flush the cache after modifying the buffer
through its userspace mapping.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_prime.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 5d885d7cb059..a3a586ce864c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -29,6 +29,26 @@
#include "nouveau_drv.h"
#include "nouveau_gem.h"
+static int nouveau_gem_prime_begin_cpu_access(struct dma_buf *buf,
+ enum dma_data_direction direction)
+{
+ struct nouveau_bo *bo = nouveau_gem_object(buf->priv);
+
+ nouveau_bo_sync_for_cpu(bo);
+
+ return 0;
+}
+
+static int nouveau_gem_prime_end_cpu_access(struct dma_buf *buf,
+ enum dma_data_direction direction)
+{
+ struct nouveau_bo *bo = nouveau_gem_object(buf->priv);
+
+ nouveau_bo_sync_for_device(bo);
+
+ return 0;
+}
+
static void *nouveau_gem_prime_kmap_atomic(struct dma_buf *buf,
unsigned long page)
{
@@ -106,6 +126,8 @@ static const struct dma_buf_ops
nouveau_gem_prime_dmabuf_ops = {
.map_dma_buf = drm_gem_map_dma_buf,
.unmap_dma_buf = drm_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
+ .begin_cpu_access = nouveau_gem_prime_begin_cpu_access,
+ .end_cpu_access = nouveau_gem_prime_end_cpu_access,
.map_atomic = nouveau_gem_prime_kmap_atomic,
.unmap_atomic = nouveau_gem_prime_kunmap_atomic,
.map = nouveau_gem_prime_kmap,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly
Hi Maxime,
On Thursday, 11 January 2018 15:12:56 EET Maxime Ripard wrote:
> On Thu, Jan 11, 2018 at 03:05:01PM +0200, Laurent Pinchart wrote:
> > On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> >> The devm_regulator_get_optional function, unlike it was assumed in the
> >> commit a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> >> property"), is actually returning an error pointer with -ENODEV instead
> >> of NULL when there's no regulator to find.
> >>
> >> Make sure we handle that case properly.
> >>
> >> Fixes: a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> >> property") Signed-off-by: Maxime Ripard
> >>
> >> ---
> >>
> >> drivers/gpu/drm/panel/panel-lvds.c | 9 +++--
> >> 1 file changed, 7 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> >> b/drivers/gpu/drm/panel/panel-lvds.c index 57e38a9e7ab4..9f46e7095c0e
> >> 100644
> >> --- a/drivers/gpu/drm/panel/panel-lvds.c
> >> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> >> @@ -215,8 +215,13 @@ static int panel_lvds_probe(struct platform_device
> >> *pdev)
> >>lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> >>if (IS_ERR(lvds->supply)) {
> >>ret = PTR_ERR(lvds->supply);
> >> - dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
> >> - return ret;
> >> +
> >> + if (ret != -ENODEV) {
> >> + dev_err(lvds->dev, "failed to request regulator: %d\n",
> >> ret);
> >> + return ret;
> >
> > I wouldn't print an error message if ret == -EPROBE_DEFER.
> >
> >> + } else {
> >> + lvds->supply = NULL;
> >> + }
> >>}
> >
> > How about
> >
> > lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> > if (IS_ERR(lvds->supply)) {
> > ret = PTR_ERR(lvds->supply);
> > if (ret != -ENODEV) {
> > if (ret == -EPROBE_DEFER)
>
> I guess that would be != -EPROBE_DEFER
Of course, my bad.
> > dev_err(lvds->dev, "failed to request
> > regulator: %d\n", ret);
> > return ret;
> > }
> >
> > lvds->supply = NULL;
> > }
>
> Otherwise, it works for me.
>
> > My preference, however, would be for devm_regulator_get_optional() to
> > return NULL when no regulator is present. The current implementation
> > returns -ENODEV in multiple cases, making it impossible to properly
> > discriminate between having no regulator and not being able to get the
> > regulator due to an error.
>
> It would feel more intuitive to me too, but it would also require to
> fix most of the call sites that would have a similar pattern.
Of course. I don't mean we need to delay this patch, but I still think it
would be a good API improvement that could be developed separately (and of
course I wouldn't complain if you volunteered ;-)).
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: lvds: Handle the optional regulator case properly
Hi Maxime,
On Friday, 12 January 2018 00:06:06 EET Laurent Pinchart wrote:
> On Thursday, 11 January 2018 15:12:56 EET Maxime Ripard wrote:
> > On Thu, Jan 11, 2018 at 03:05:01PM +0200, Laurent Pinchart wrote:
> >> On Wednesday, 10 January 2018 17:59:41 EET Maxime Ripard wrote:
> >>> The devm_regulator_get_optional function, unlike it was assumed in the
> >>> commit a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> >>> property"), is actually returning an error pointer with -ENODEV instead
> >>> of NULL when there's no regulator to find.
> >>>
> >>> Make sure we handle that case properly.
> >>>
> >>> Fixes: a1c55bccf600 ("drm/panel: lvds: Add support for the power-supply
> >>> property") Signed-off-by: Maxime Ripard
> >>>
> >>> ---
> >>>
> >>> drivers/gpu/drm/panel/panel-lvds.c | 9 +++--
> >>> 1 file changed, 7 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> >>> b/drivers/gpu/drm/panel/panel-lvds.c index 57e38a9e7ab4..9f46e7095c0e
> >>> 100644
> >>> --- a/drivers/gpu/drm/panel/panel-lvds.c
> >>> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> >>> @@ -215,8 +215,13 @@ static int panel_lvds_probe(struct platform_device
> >>> *pdev)
> >>> lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> >>> if (IS_ERR(lvds->supply)) {
> >>> ret = PTR_ERR(lvds->supply);
> >>> - dev_err(lvds->dev, "failed to request regulator: %d\n", ret);
> >>> - return ret;
> >>> +
> >>> + if (ret != -ENODEV) {
> >>> + dev_err(lvds->dev, "failed to request regulator: %d\n",
> >>> ret);
> >>> + return ret;
> >>
> >> I wouldn't print an error message if ret == -EPROBE_DEFER.
> >>
> >>> + } else {
> >>> + lvds->supply = NULL;
> >>> + }
> >>> }
> >>
> >> How about
> >>
> >>lvds->supply = devm_regulator_get_optional(lvds->dev, "power");
> >>if (IS_ERR(lvds->supply)) {
> >>ret = PTR_ERR(lvds->supply);
> >>if (ret != -ENODEV) {
> >>if (ret == -EPROBE_DEFER)
> >
> > I guess that would be != -EPROBE_DEFER
>
> Of course, my bad.
>
> >>dev_err(lvds->dev, "failed to request
> >> regulator: %d\n", ret);
> >>return ret;
> >>}
> >>
> >>lvds->supply = NULL;
> >>}
> >
> > Otherwise, it works for me.
With the above change,
Reviewed-by: Laurent Pinchart
Tested-by: Laurent Pinchart
> >> My preference, however, would be for devm_regulator_get_optional() to
> >> return NULL when no regulator is present. The current implementation
> >> returns -ENODEV in multiple cases, making it impossible to properly
> >> discriminate between having no regulator and not being able to get the
> >> regulator due to an error.
> >
> > It would feel more intuitive to me too, but it would also require to
> > fix most of the call sites that would have a similar pattern.
>
> Of course. I don't mean we need to delay this patch, but I still think it
> would be a good API improvement that could be developed separately (and of
> course I wouldn't complain if you volunteered ;-)).
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/nouveau: Support fence FDs at kickoff
From: Thierry Reding
Add a new NOUVEAU_GEM_PUSHBUF2 IOCTL that accepts and emits a sync fence
FD from/to userspace if requested by the corresponding flags.
Based heavily on work by Lauri Peltonen
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
drivers/gpu/drm/nouveau/nouveau_gem.c | 78 +--
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +
include/uapi/drm/nouveau_drm.h| 14 +++
4 files changed, 91 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 3ce2f02e9e58..b38500a64236 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1012,6 +1012,7 @@ nouveau_ioctls[] = {
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info,
DRM_AUTH|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF2, nouveau_gem_ioctl_pushbuf2,
DRM_AUTH|DRM_RENDER_ALLOW),
};
long
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index ea5e1cbd..ad5c939b4f33 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -24,6 +24,8 @@
*
*/
+#include
+
#include "nouveau_drv.h"
#include "nouveau_dma.h"
#include "nouveau_fence.h"
@@ -666,22 +668,28 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
return ret;
}
-int
-nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+static int
+__nouveau_gem_ioctl_pushbuf(struct drm_device *dev,
+ struct drm_nouveau_gem_pushbuf2 *request,
+ struct drm_file *file_priv)
{
struct nouveau_abi16 *abi16 = nouveau_abi16_get(file_priv);
struct nouveau_cli *cli = nouveau_cli(file_priv);
struct nouveau_abi16_chan *temp;
struct nouveau_drm *drm = nouveau_drm(dev);
- struct drm_nouveau_gem_pushbuf *req = data;
+ struct drm_nouveau_gem_pushbuf *req = &request->base;
struct drm_nouveau_gem_pushbuf_push *push;
struct drm_nouveau_gem_pushbuf_bo *bo;
struct nouveau_channel *chan = NULL;
struct validate_op op;
struct nouveau_fence *fence = NULL;
+ struct dma_fence *prefence = NULL;
int i, j, ret = 0, do_reloc = 0;
+ /* check for unrecognized flags */
+ if (request->flags & ~NOUVEAU_GEM_PUSHBUF_FLAGS)
+ return -EINVAL;
+
if (unlikely(!abi16))
return -ENOMEM;
@@ -746,6 +754,15 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
goto out_prevalid;
}
+ if (request->flags & NOUVEAU_GEM_PUSHBUF_FENCE_WAIT) {
+ prefence = sync_file_get_fence(request->fence);
+ if (prefence) {
+ ret = nouveau_fence_sync(prefence, chan, true);
+ if (ret < 0)
+ goto out;
+ }
+ }
+
/* Apply any relocations that are required */
if (do_reloc) {
ret = nouveau_gem_pushbuf_reloc_apply(cli, req, bo);
@@ -830,7 +847,30 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
goto out;
}
+ if (request->flags & NOUVEAU_GEM_PUSHBUF_FENCE_EMIT) {
+ struct sync_file *file;
+ int fd;
+
+ fd = get_unused_fd_flags(O_CLOEXEC);
+ if (fd < 0) {
+ ret = fd;
+ goto out;
+ }
+
+ file = sync_file_create(&fence->base);
+ if (!file) {
+ put_unused_fd(fd);
+ goto out;
+ }
+
+ fd_install(fd, file->file);
+ request->fence = fd;
+ }
+
out:
+ if (prefence)
+ dma_fence_put(prefence);
+
validate_fini(&op, fence, bo);
nouveau_fence_unref(&fence);
@@ -855,6 +895,27 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
return nouveau_abi16_put(abi16, ret);
}
+int
+nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_nouveau_gem_pushbuf *request = data;
+ struct drm_nouveau_gem_pushbuf2 req;
+ int ret;
+
+ memset(&req, 0, sizeof(req));
+ memcpy(&req.base, request, sizeof(*request));
+
+ ret = __nouveau_gem_ioctl_pushbuf(dev, &req, file_priv);
+
+ request->gart_available = req.base.gart_available;
+ request->vram_available = req.base.vram_available;
+ request->suffix1 = req.base.suffix1;
+ request->suffix0 = req.base.
[PATCH 1/3] drm/nouveau: Split nouveau_fence_sync()
From: Thierry Reding
Turn nouveau_fence_sync() into a low-level helper that adds fence waits
to the channel command stream. The new nouveau_bo_sync() helper replaces
the previous nouveau_fence_sync() implementation. It passes each of the
buffer object's fences to nouveau_fence_sync() in turn.
This provides more fine-grained control over fences which is needed by
subsequent patches for sync fd support.
Heavily based on work by Lauri Peltonen .
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 38 -
drivers/gpu/drm/nouveau/nouveau_bo.h | 2 +
drivers/gpu/drm/nouveau/nouveau_display.c | 4 +-
drivers/gpu/drm/nouveau/nouveau_fence.c | 68 +++
drivers/gpu/drm/nouveau/nouveau_fence.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
6 files changed, 57 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 41e7f2927443..0285ca4c6235 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -545,6 +545,42 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
PAGE_SIZE, DMA_FROM_DEVICE);
}
+int
+nouveau_bo_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan,
+ bool exclusive, bool intr)
+{
+ struct reservation_object *resv = nvbo->bo.resv;
+ struct reservation_object_list *fobj;
+ struct dma_fence *fence;
+ int ret = 0, i;
+
+ if (!exclusive) {
+ ret = reservation_object_reserve_shared(resv);
+ if (ret < 0)
+ return ret;
+ }
+
+ fobj = reservation_object_get_list(resv);
+ fence = reservation_object_get_excl(resv);
+
+ if (fence && (!exclusive || !fobj || !fobj->shared_count))
+ return nouveau_fence_sync(fence, chan, intr);
+
+ if (!exclusive || !fobj)
+ return ret;
+
+ for (i = 0; i < fobj->shared_count && !ret; ++i) {
+ fence = rcu_dereference_protected(fobj->shared[i],
+
reservation_object_held(resv));
+
+ ret = nouveau_fence_sync(fence, chan, intr);
+ if (ret < 0)
+ break;
+ }
+
+ return ret;
+}
+
int
nouveau_bo_validate(struct nouveau_bo *nvbo, bool interruptible,
bool no_wait_gpu)
@@ -1114,7 +1150,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
evict, bool intr,
}
mutex_lock_nested(&cli->mutex, SINGLE_DEPTH_NESTING);
- ret = nouveau_fence_sync(nouveau_bo(bo), chan, true, intr);
+ ret = nouveau_bo_sync(nouveau_bo(bo), chan, true, intr);
if (ret == 0) {
ret = drm->ttm.move(chan, bo, &bo->mem, new_reg);
if (ret == 0) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 7b5cc5c73d20..d2ef12c0e39a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -93,6 +93,8 @@ 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);
+int nouveau_bo_sync(struct nouveau_bo *nvbo, struct nouveau_channel *channel,
+ bool exclusive, bool intr);
/* TODO: submit equivalent to TTM generic API upstream? */
static inline void __iomem *
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 009713404cc4..526280e9677a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -755,7 +755,7 @@ nouveau_page_flip_emit(struct nouveau_channel *chan,
spin_unlock_irqrestore(&dev->event_lock, flags);
/* Synchronize with the old framebuffer */
- ret = nouveau_fence_sync(old_bo, chan, false, false);
+ ret = nouveau_bo_sync(old_bo, chan, false, false);
if (ret)
goto fail;
@@ -819,7 +819,7 @@ nouveau_crtc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
goto fail_unpin;
/* synchronise rendering channel with the kernel's channel */
- ret = nouveau_fence_sync(new_bo, chan, false, true);
+ ret = nouveau_bo_sync(new_bo, chan, false, true);
if (ret) {
ttm_bo_unreserve(&new_bo->bo);
goto fail_unpin;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 9c8f3a154d55..d61fcfb97b09 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -332,66 +332,26 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool
lazy, bool intr)
}
int
-nouveau_fence_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool
excl
RE: [PATCH v2 4/5] drm/dp: Macro for DSC eDP Output BPP
Looks good to me.
>-Original Message-
>From: Navare, Manasi D
>Sent: Thursday, January 4, 2018 12:23 AM
>To: gfx-internal-de...@eclists.intel.com
>Cc: Navare, Manasi D ; Jani Nikula
>; Ville Syrjala ;
>Srivatsa, Anusha ; dri-devel@lists.freedesktop.org
>Subject: [PATCH v2 4/5] drm/dp: Macro for DSC eDP Output BPP
>
>This returns the maximum output BPP supported by the eDP panel by reading the
>MAX_SUPPORTED_BPP DSC DPCD register.
>
>Cc: Jani Nikula
>Cc: Ville Syrjala
>Cc: Anusha Srivatsa
>Cc: dri-devel@lists.freedesktop.org
>Signed-off-by: Manasi Navare
Reviewed-by: Anusha Srivatsa
>---
> include/drm/drm_dp_helper.h | 10 ++
> 1 file changed, 10 insertions(+)
>
>diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
>06e41b2..4e8f357 100644
>--- a/include/drm/drm_dp_helper.h
>+++ b/include/drm/drm_dp_helper.h
>@@ -980,6 +980,16 @@ drm_dp_is_branch(const u8
>dpcd[DP_RECEIVER_CAP_SIZE])
> return dpcd[DP_DOWNSTREAMPORT_PRESENT] &
>DP_DWN_STRM_PORT_PRESENT; }
>
>+/* DP/eDP DSC support */
>+static inline u16
>+drm_edp_dsc_get_output_bpp(const u8
>dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
>+{
>+ return dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_LOW -
>DP_DSC_SUPPORT] |
>+ (dsc_dpcd[DP_DSC_MAX_BITS_PER_PIXEL_HI -
>DP_DSC_SUPPORT] &
>+ DP_DSC_MAX_BITS_PER_PIXEL_HI_MASK <<
>+ DP_DSC_MAX_BITS_PER_PIXEL_HI_SHIFT);
>+}
>+
> /*
> * DisplayPort AUX channel
> */
>--
>2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/nouveau: Support DMA fence arrays
From: Thierry Reding
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index d61fcfb97b09..53178b1471e3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -331,9 +332,9 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool lazy,
bool intr)
return 0;
}
-int
-nouveau_fence_sync(struct dma_fence *fence, struct nouveau_channel *chan,
- bool intr)
+static int
+__nouveau_fence_sync(struct dma_fence *fence, struct nouveau_channel *chan,
+bool intr)
{
struct nouveau_fence_chan *fctx = chan->fence;
struct nouveau_channel *prev = NULL;
@@ -356,6 +357,30 @@ nouveau_fence_sync(struct dma_fence *fence, struct
nouveau_channel *chan,
return ret;
}
+int
+nouveau_fence_sync(struct dma_fence *fence, struct nouveau_channel *chan,
+ bool intr)
+{
+ int ret = 0;
+
+ if (dma_fence_is_array(fence)) {
+ struct dma_fence_array *array = to_dma_fence_array(fence);
+ unsigned int i;
+
+ for (i = 0; i < array->num_fences; i++) {
+ struct dma_fence *f = array->fences[i];
+
+ ret = __nouveau_fence_sync(f, chan, intr);
+ if (ret < 0)
+ break;
+ }
+ } else {
+ ret = __nouveau_fence_sync(fence, chan, intr);
+ }
+
+ return ret;
+}
+
void
nouveau_fence_unref(struct nouveau_fence **pfence)
{
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/nouveau: Add support for fence FDs
From: Thierry Reding This small series of patches implements support for waiting on and emitting fence FDs on kickoff. This enables explicit fencing and can be used for example to synchronize buffer accesses between the display engine and the GPU on Tegra. The first patch lays the groundwork by splitting up nouveau_fence_sync() to allow reuse. Patch 2 is where the interesting stuff happens. It adds a new IOCTL (PUSHBUF2) that is a superset of the existing PUSHBUF IOCTL and reuses most of the code while adding support for pre- and post- fences. Finally, the third patch teaches Nouveau how to deal with fence arrays, which are usually a result of chaining together multiple dependent jobs. I have corresponding userspace support for these in libdrm and Mesa: https://cgit.freedesktop.org/~tagr/drm/log/?h=nouveau-sync-fd https://cgit.freedesktop.org/~tagr/mesa/log/?h=nouveau-sync-fd I'll send those patches out shortly. There's some more work depending on these patches that I plan to send out in the coming days or weeks. The final result allows Nouveau and Tegra DRM to negotiate for a framebuffer modifier and then go into a render/scanout loop using fences for synchronization. All of this was tested using a slightly modified version of kmscube. Thierry Thierry Reding (3): drm/nouveau: Split nouveau_fence_sync() drm/nouveau: Support fence FDs at kickoff drm/nouveau: Support DMA fence arrays drivers/gpu/drm/nouveau/nouveau_bo.c | 38 ++- drivers/gpu/drm/nouveau/nouveau_bo.h | 2 + drivers/gpu/drm/nouveau/nouveau_display.c | 4 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 1 + drivers/gpu/drm/nouveau/nouveau_fence.c | 81 +-- drivers/gpu/drm/nouveau/nouveau_fence.h | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 80 -- drivers/gpu/drm/nouveau/nouveau_gem.h | 2 + include/uapi/drm/nouveau_drm.h| 14 ++ 9 files changed, 167 insertions(+), 57 deletions(-) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/tegra: Add support for fence FDs
From: Thierry Reding This set of patches adds support for fences to Tegra DRM and complements the fence FD support for Nouveau. Technically this isn't necessary for a fence-based synchronization loop with Nouveau because the KMS core takes care of all that, but engines behind host1x can use the IOCTL extensions provided here to emit fence FDs that in turn can be used to synchronize their jobs with either the scanout engine or the GPU. See the following link for the Nouveau fence FD support series: https://patchwork.freedesktop.org/series/36361/ Thierry Mikko Perttunen (3): gpu: host1x: Add support for DMA fences drm/tegra: Add sync file support to submit interface drm/tegra: Support for sync file-based fences in submit drivers/gpu/drm/tegra/drm.c| 82 --- drivers/gpu/host1x/Kconfig | 1 + drivers/gpu/host1x/Makefile| 1 + drivers/gpu/host1x/dev.h | 12 ++- drivers/gpu/host1x/fence.c | 202 + drivers/gpu/host1x/fence.h | 28 + drivers/gpu/host1x/hw/channel_hw.c | 36 +-- drivers/gpu/host1x/intr.c | 11 +- drivers/gpu/host1x/intr.h | 8 +- drivers/gpu/host1x/syncpt.c| 2 + include/linux/host1x.h | 12 ++- include/uapi/drm/tegra_drm.h | 10 +- 12 files changed, 376 insertions(+), 29 deletions(-) create mode 100644 drivers/gpu/host1x/fence.c create mode 100644 drivers/gpu/host1x/fence.h -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 5/6] iommu/arm-smmu: Add support for qcom,smmu-v2 variant
On Tue, Jan 09, 2018 at 03:31:48PM +0530, Vivek Gautam wrote:
> qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
> clock and power requirements. This smmu core is used with
> multiple masters on msm8996, viz. mdss, video, etc.
> Add bindings for the same.
>
> Signed-off-by: Vivek Gautam
> ---
>
> * Major change in this patch -
>Changed compatible string from 'qcom,msm8996-smmu-v2' to
>'qcom,smmu-v2' to reflect the IP version rather than the
>platform on which it is used.
The bugs and how things are connected are all the same? I'd suggest you
keep both strings.
>The same IP is used across multiple platforms including msm8996,
>and sdm845 etc.
But for only 2 or so platforms a fallback is not really worth it. You'll
probably be on SMMUv3 before too long...
>
> .../devicetree/bindings/iommu/arm,smmu.txt | 35
> ++
> drivers/iommu/arm-smmu.c | 13
> 2 files changed, 48 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> index 8a6ffce12af5..e4951288c87c 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
> @@ -17,6 +17,7 @@ conditions.
> "arm,mmu-401"
> "arm,mmu-500"
> "cavium,smmu-v2"
> +"qcom,smmu-v2"
>
>depending on the particular implementation and/or the
>version of the architecture implemented.
> @@ -71,6 +72,23 @@ conditions.
>or using stream matching with #iommu-cells = <2>, and
>may be ignored if present in such cases.
>
> +- clock-names:Should be "bus", and "iface" for "qcom,smmu-v2"
> + implementation.
> +
> + "bus" clock for "qcom,smmu-v2" is required for downstream
> + bus access and for the smmu ptw.
> +
> + "iface" clock is required to access smmu's registers
> through
> + the TCU's programming interface.
> +
> +- clocks: Phandles for respective clocks described by clock-names.
> +
> +- power-domains: Phandles to SMMU's power domain specifier. This is
> + required even if SMMU belongs to the master's power
> + domain, as the SMMU will have to be enabled and
> + accessed before master gets enabled and linked to its
> + SMMU.
> +
> ** Deprecated properties:
>
> - mmu-masters (deprecated in favour of the generic "iommus" binding) :
> @@ -137,3 +155,20 @@ conditions.
> iommu-map = <0 &smmu3 0 0x400>;
> ...
> };
> +
> + /* Qcom's arm,smmu-v2 implementation */
> + smmu4: iommu {
> + compatible = "qcom,smmu-v2";
> + reg = <0xd0 0x1>;
> +
> + #global-interrupts = <1>;
> + interrupts = ,
> + ,
> + ;
> + #iommu-cells = <1>;
> + power-domains = <&mmcc MDSS_GDSC>;
> +
> + clocks = <&mmcc SMMU_MDP_AXI_CLK>,
> + <&mmcc SMMU_MDP_AHB_CLK>;
> + clock-names = "bus", "iface";
> + };
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 33bbcfedb896..2ade214c41bc 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -119,6 +119,7 @@ enum arm_smmu_implementation {
> GENERIC_SMMU,
> ARM_MMU500,
> CAVIUM_SMMUV2,
> + QCOM_SMMUV2,
> };
>
> struct arm_smmu_s2cr {
> @@ -1971,6 +1972,17 @@ struct arm_smmu_match_data {
> ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
> ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
>
> +static const char * const qcom_smmuv2_clks[] = {
> + "bus", "iface",
> +};
> +
> +static const struct arm_smmu_match_data qcom_smmuv2 = {
> + .version = ARM_SMMU_V2,
> + .model = QCOM_SMMUV2,
> + .clks = qcom_smmuv2_clks,
> + .num_clks = ARRAY_SIZE(qcom_smmuv2_clks),
> +};
> +
> static const struct of_device_id arm_smmu_of_match[] = {
> { .compatible = "arm,smmu-v1", .data = &smmu_generic_v1 },
> { .compatible = "arm,smmu-v2", .data = &smmu_generic_v2 },
> @@ -1978,6 +1990,7 @@ struct arm_smmu_match_data {
> { .compatible = "arm,mmu-401", .data = &arm_mmu401 },
> { .compatible = "arm,mmu-500", .data = &arm_mmu500 },
> { .compatible = "cavium,smmu-v2", .data = &cavium_smmuv2 },
> + { .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 },
> { },
> };
> MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
___
dri-devel mailing list
dri
[PATCH 3/3] drm/tegra: Support for sync file-based fences in submit
From: Mikko Perttunen
Add support for sync file-based prefences and postfences
to job submission. Fences are passed to the Host1x implementation.
Signed-off-by: Mikko Perttunen
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 82 -
1 file changed, 66 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d50bddb2e447..c40175c32dd7 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -374,6 +375,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
struct drm_tegra_submit *args, struct drm_device *drm,
struct drm_file *file)
{
+ struct host1x *host1x = dev_get_drvdata(drm->dev->parent);
unsigned int num_cmdbufs = args->num_cmdbufs;
unsigned int num_relocs = args->num_relocs;
unsigned int num_waitchks = args->num_waitchks;
@@ -382,7 +384,6 @@ int tegra_drm_submit(struct tegra_drm_context *context,
struct drm_tegra_waitchk __user *user_waitchks;
struct drm_tegra_syncpt __user *user_syncpt;
struct drm_tegra_syncpt syncpt;
- struct host1x *host1x = dev_get_drvdata(drm->dev->parent);
struct drm_gem_object **refs;
struct host1x_syncpt *sp;
struct host1x_job *job;
@@ -402,6 +403,10 @@ int tegra_drm_submit(struct tegra_drm_context *context,
if (args->num_waitchks != 0)
return -EINVAL;
+ /* Check for unrecognized flags */
+ if (args->flags & ~DRM_TEGRA_SUBMIT_FLAGS)
+ return -EINVAL;
+
job = host1x_job_alloc(context->channel, args->num_cmdbufs,
args->num_relocs, args->num_waitchks);
if (!job)
@@ -413,6 +418,14 @@ int tegra_drm_submit(struct tegra_drm_context *context,
job->class = context->client->base.class;
job->serialize = true;
+ if (args->flags & DRM_TEGRA_SUBMIT_WAIT_FENCE_FD) {
+ job->prefence = sync_file_get_fence(args->fence);
+ if (!job->prefence) {
+ err = -ENOENT;
+ goto put;
+ }
+ }
+
/*
* Track referenced BOs so that they can be unreferenced after the
* submission is complete.
@@ -436,7 +449,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
if (copy_from_user(&cmdbuf, user_cmdbufs, sizeof(cmdbuf))) {
err = -EFAULT;
- goto fail;
+ goto put_bos;
}
/*
@@ -445,13 +458,13 @@ int tegra_drm_submit(struct tegra_drm_context *context,
*/
if (cmdbuf.words > CDMA_GATHER_FETCHES_MAX_NB) {
err = -EINVAL;
- goto fail;
+ goto put_bos;
}
bo = host1x_bo_lookup(file, cmdbuf.handle);
if (!bo) {
err = -ENOENT;
- goto fail;
+ goto put_bos;
}
offset = (u64)cmdbuf.offset + (u64)cmdbuf.words * sizeof(u32);
@@ -465,7 +478,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
*/
if (offset & 3 || offset >= obj->gem.size) {
err = -EINVAL;
- goto fail;
+ goto put_bos;
}
host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
@@ -482,7 +495,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
&user_relocs[num_relocs], drm,
file);
if (err < 0)
- goto fail;
+ goto put_bos;
reloc = &job->relocarray[num_relocs];
obj = host1x_to_tegra_bo(reloc->cmdbuf.bo);
@@ -496,7 +509,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
if (reloc->cmdbuf.offset & 3 ||
reloc->cmdbuf.offset >= obj->gem.size) {
err = -EINVAL;
- goto fail;
+ goto put_bos;
}
obj = host1x_to_tegra_bo(reloc->target.bo);
@@ -504,7 +517,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
if (reloc->target.offset >= obj->gem.size) {
err = -EINVAL;
- goto fail;
+ goto put_bos;
}
}
@@ -516,7 +529,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
err = host1x_waitchk_copy_from_user(
wait, &user_waitchks[num_waitchks], file);
if (err < 0)
-
[PATCH 1/3] gpu: host1x: Add support for DMA fences
From: Mikko Perttunen
Add an implementation of DMA fences backed by Host1x syncpoints,
an interface to specify a prefence for job submissions.
Before submission, prefences containing only Host1x syncpoints
are waited by pushing wait commands to CDMA, whereas other
fences are CPU-waited.
Signed-off-by: Mikko Perttunen
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/Kconfig | 1 +
drivers/gpu/host1x/Makefile| 1 +
drivers/gpu/host1x/dev.h | 12 ++-
drivers/gpu/host1x/fence.c | 202 +
drivers/gpu/host1x/fence.h | 28 +
drivers/gpu/host1x/hw/channel_hw.c | 36 +--
drivers/gpu/host1x/intr.c | 11 +-
drivers/gpu/host1x/intr.h | 8 +-
drivers/gpu/host1x/syncpt.c| 2 +
include/linux/host1x.h | 12 ++-
10 files changed, 302 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/host1x/fence.c
create mode 100644 drivers/gpu/host1x/fence.h
diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
index 91916326957f..e41032ebf16d 100644
--- a/drivers/gpu/host1x/Kconfig
+++ b/drivers/gpu/host1x/Kconfig
@@ -1,6 +1,7 @@
config TEGRA_HOST1X
tristate "NVIDIA Tegra host1x driver"
depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
+ select DMA_SHARED_BUFFER
select IOMMU_IOVA if IOMMU_SUPPORT
help
Driver for the NVIDIA Tegra host1x hardware.
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index b92016ce09b7..ae3a6edf74b4 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -9,6 +9,7 @@ host1x-y = \
job.o \
debug.o \
mipi.o \
+ fence.o \
hw/host1x01.o \
hw/host1x02.o \
hw/host1x04.o \
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index 43e9fabb43a1..c9071c9c443e 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2012-2015, NVIDIA Corporation.
+ * Copyright (C) 2012-2016 NVIDIA CORPORATION. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -42,6 +42,7 @@ struct host1x_channel_ops {
int (*init)(struct host1x_channel *channel, struct host1x *host,
unsigned int id);
int (*submit)(struct host1x_job *job);
+ void (*push_wait)(struct host1x_channel *ch, u32 id, u32 thresh);
};
struct host1x_cdma_ops {
@@ -117,6 +118,8 @@ struct host1x {
struct clk *clk;
struct reset_control *rst;
+ u64 fence_ctx_base;
+
struct iommu_group *group;
struct iommu_domain *domain;
struct iova_domain iova;
@@ -250,6 +253,13 @@ static inline int host1x_hw_channel_submit(struct host1x
*host,
return host->channel_op->submit(job);
}
+static inline void host1x_hw_channel_push_wait(struct host1x *host,
+ struct host1x_channel *channel,
+ u32 id, u32 thresh)
+{
+ host->channel_op->push_wait(channel, id, thresh);
+}
+
static inline void host1x_hw_cdma_start(struct host1x *host,
struct host1x_cdma *cdma)
{
diff --git a/drivers/gpu/host1x/fence.c b/drivers/gpu/host1x/fence.c
new file mode 100644
index ..3b056623ea64
--- /dev/null
+++ b/drivers/gpu/host1x/fence.c
@@ -0,0 +1,202 @@
+/*
+ * Copyright (C) 2016 NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
[PATCH 2/3] drm/tegra: Add sync file support to submit interface
From: Mikko Perttunen
Adds ability to pass sync file based prefences and get back
sync file based postfences during job submission. Both
fence fd's are passed in the `fence` field. A new `flags`
field is used to specify if the prefence should be waited
or a postfence created.
Signed-off-by: Mikko Perttunen
Signed-off-by: Thierry Reding
---
include/uapi/drm/tegra_drm.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index d954f8c33321..03492d6670a5 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -117,6 +117,11 @@ struct drm_tegra_waitchk {
__u32 thresh;
};
+#define DRM_TEGRA_SUBMIT_WAIT_FENCE_FD (1 << 0)
+#define DRM_TEGRA_SUBMIT_CREATE_FENCE_FD (1 << 1)
+#define DRM_TEGRA_SUBMIT_FLAGS (DRM_TEGRA_SUBMIT_WAIT_FENCE_FD | \
+ DRM_TEGRA_SUBMIT_CREATE_FENCE_FD)
+
struct drm_tegra_submit {
__u64 context;
__u32 num_syncpts;
@@ -129,9 +134,10 @@ struct drm_tegra_submit {
__u64 cmdbufs;
__u64 relocs;
__u64 waitchks;
- __u32 fence;/* Return value */
+ __u32 fence;
+ __u32 flags;
- __u32 reserved[5]; /* future expansion */
+ __u32 reserved[4]; /* future expansion */
};
#define DRM_TEGRA_GEM_TILING_MODE_PITCH 0
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] nouveau: Support fence FDs
From: Thierry Reding
Add a new nouveau_pushbuf_kick_fence() function that takes and emits a
sync fence FD. The fence FD can be waited on, or merged with other fence
FDs, or passed back to the kernel as a prerequisite for a subsequent HW
operation.
Based heavily on work by Lauri Peltonen
Signed-off-by: Thierry Reding
---
For the kernel patches that add the new IOCTL, see the series at:
https://patchwork.freedesktop.org/series/36361/
include/drm/nouveau_drm.h | 23
nouveau/nouveau.h | 2 +
nouveau/pushbuf.c | 130 ++
3 files changed, 121 insertions(+), 34 deletions(-)
diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index cb077821c43f..e7f1a2aefd22 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -178,6 +178,28 @@ struct drm_nouveau_gem_pushbuf {
__u64 gart_available;
};
+#define NOUVEAU_GEM_PUSHBUF_FENCE_WAIT (1 << 0)
+#define NOUVEAU_GEM_PUSHBUF_FENCE_EMIT (1 << 1)
+#define NOUVEAU_GEM_PUSHBUF_FLAGS (NOUVEAU_GEM_PUSHBUF_FENCE_WAIT | \
+ NOUVEAU_GEM_PUSHBUF_FENCE_EMIT)
+
+struct drm_nouveau_gem_pushbuf2 {
+uint32_t channel;
+uint32_t nr_buffers;
+uint64_t buffers;
+uint32_t nr_relocs;
+uint32_t nr_push;
+uint64_t relocs;
+uint64_t push;
+uint32_t suffix0;
+uint32_t suffix1;
+uint64_t vram_available;
+uint64_t gart_available;
+uint32_t flags;
+int32_t fence;
+uint64_t reserved;
+};
+
#define NOUVEAU_GEM_CPU_PREP_NOWAIT 0x0001
#define NOUVEAU_GEM_CPU_PREP_NOBLOCK 0x0002
#define NOUVEAU_GEM_CPU_PREP_WRITE 0x0004
@@ -212,6 +234,7 @@ struct drm_nouveau_sarea {
#define DRM_NOUVEAU_GEM_CPU_PREP 0x42
#define DRM_NOUVEAU_GEM_CPU_FINI 0x43
#define DRM_NOUVEAU_GEM_INFO 0x44
+#define DRM_NOUVEAU_GEM_PUSHBUF2 0x45
#if defined(__cplusplus)
}
diff --git a/nouveau/nouveau.h b/nouveau/nouveau.h
index 335ce77dca77..70d680700faf 100644
--- a/nouveau/nouveau.h
+++ b/nouveau/nouveau.h
@@ -226,6 +226,8 @@ void nouveau_pushbuf_reloc(struct nouveau_pushbuf *, struct
nouveau_bo *,
int nouveau_pushbuf_validate(struct nouveau_pushbuf *);
uint32_t nouveau_pushbuf_refd(struct nouveau_pushbuf *, struct nouveau_bo *);
int nouveau_pushbuf_kick(struct nouveau_pushbuf *, struct nouveau_object
*chan);
+int nouveau_pushbuf_kick_fence(struct nouveau_pushbuf *,
+ struct nouveau_object *chan, int *fence);
struct nouveau_bufctx *
nouveau_pushbuf_bufctx(struct nouveau_pushbuf *, struct nouveau_bufctx *);
diff --git a/nouveau/pushbuf.c b/nouveau/pushbuf.c
index 035e3019f2cd..f13804db7534 100644
--- a/nouveau/pushbuf.c
+++ b/nouveau/pushbuf.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -77,7 +78,7 @@ nouveau_pushbuf(struct nouveau_pushbuf *push)
}
static int pushbuf_validate(struct nouveau_pushbuf *, bool);
-static int pushbuf_flush(struct nouveau_pushbuf *);
+static int pushbuf_flush(struct nouveau_pushbuf *, int *);
static bool
pushbuf_kref_fits(struct nouveau_pushbuf *push, struct nouveau_bo *bo,
@@ -172,7 +173,7 @@ pushbuf_kref(struct nouveau_pushbuf *push, struct
nouveau_bo *bo,
*/
fpush = cli_push_get(push->client, bo);
if (fpush && fpush != push)
- pushbuf_flush(fpush);
+ pushbuf_flush(fpush, NULL);
kref = cli_kref_get(push->client, bo);
if (kref) {
@@ -307,7 +308,8 @@ pushbuf_dump(struct nouveau_pushbuf_krec *krec, int
krec_id, int chid)
}
static int
-pushbuf_submit(struct nouveau_pushbuf *push, struct nouveau_object *chan)
+pushbuf_submit(struct nouveau_pushbuf *push, struct nouveau_object *chan,
+ int *fence)
{
struct nouveau_pushbuf_priv *nvpb = nouveau_pushbuf(push);
struct nouveau_pushbuf_krec *krec = nvpb->list;
@@ -315,9 +317,9 @@ pushbuf_submit(struct nouveau_pushbuf *push, struct
nouveau_object *chan)
struct nouveau_drm *drm = nouveau_drm(&dev->object);
struct drm_nouveau_gem_pushbuf_bo_presumed *info;
struct drm_nouveau_gem_pushbuf_bo *kref;
- struct drm_nouveau_gem_pushbuf req;
struct nouveau_fifo *fifo = chan->data;
struct nouveau_bo *bo;
+ int fence_out = -1;
int krec_id = 0;
int ret = 0, i;
@@ -330,35 +332,81 @@ pushbuf_submit(struct nouveau_pushbuf *push, struct
nouveau_object *chan)
nouveau_pushbuf_data(push, NULL, 0, 0);
while (krec && krec->nr_push) {
- req.channel = fifo->channel;
- req.nr_buffers = krec->nr_buffer;
- req.buffers = (uint64_t)(unsigned long)krec->buffer;
- req.nr_relocs = krec->nr_reloc;
- req.nr_push = krec->nr_push;
- req.relocs = (uint64_t)(unsigned long)krec->r
Re: [PATCH v3 4/7] drm/tinydrm/mipi-dbi: Add poweron-reset functions
On 01/10/2018 12:59 PM, Noralf Trønnes wrote:
Split out common poweron-reset functionality.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 22 ++--
drivers/gpu/drm/tinydrm/mipi-dbi.c | 73 ++
drivers/gpu/drm/tinydrm/st7586.c | 9 ++---
drivers/gpu/drm/tinydrm/st7735r.c | 8 ++---
include/drm/tinydrm/mipi-dbi.h | 2 ++
5 files changed, 83 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index c69a4d958f24..1617405faed4 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -49,33 +49,17 @@
static int mi0283qt_init(struct mipi_dbi *mipi)
{
- struct tinydrm_device *tdev = &mipi->tinydrm;
- struct device *dev = tdev->drm->dev;
u8 addr_mode;
int ret;
DRM_DEBUG_KMS("\n");
- ret = regulator_enable(mipi->regulator);
- if (ret) {
- DRM_DEV_ERROR(dev, "Failed to enable regulator %d\n", ret);
+ ret = mipi_dbi_poweron_conditional_reset(mipi);
+ if (ret < 0)
return ret;
- }
-
- /* Avoid flicker by skipping setup if the bootloader has done it */
It could be helpful to keep this comment.
- if (mipi_dbi_display_is_on(mipi))
+ if (ret == 1)
return 0;
- mipi_dbi_hw_reset(mipi);
- ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
- if (ret) {
- DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
- regulator_disable(mipi->regulator);
- return ret;
- }
-
- msleep(20);
-
mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
mipi_dbi_command(mipi, ILI9341_PWCTRLB, 0x00, 0x83, 0x30);
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 1c8ef0c4d6d4..3e879d605ed3 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -463,6 +463,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
val &= ~DCS_POWER_MODE_RESERVED_MASK;
+ /* The poweron/reset value is 08h DCS_POWER_MODE_DISPLAY_NORMAL_MODE */
if (val != (DCS_POWER_MODE_DISPLAY |
DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
return false;
@@ -473,6 +474,78 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
}
EXPORT_SYMBOL(mipi_dbi_display_is_on);
+static int mipi_dbi_poweron_reset_conditional(struct mipi_dbi *mipi, bool cond)
+{
+ struct device *dev = mipi->tinydrm.drm->dev;
+ int ret;
+
+ if (mipi->regulator) {
+ ret = regulator_enable(mipi->regulator);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n",
ret);
+ return ret;
+ }
+ }
+
+ if (cond && mipi_dbi_display_is_on(mipi))
+ return 1;
+
+ mipi_dbi_hw_reset(mipi);
+ ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "Failed to send reset command (%d)\n", ret);
+ if (mipi->regulator)
+ regulator_disable(mipi->regulator);
+ return ret;
+ }
+
+ /*
+* If we did a hw reset, we know the controller is in Sleep mode and
+* per MIPI DSC spec should wait 5ms after soft reset. If we didn't,
+* we assume worst case and wait 120ms.
+*/
+ if (mipi->reset)
+ usleep_range(5000, 2);
+ else
+ msleep(120);
+
+ return 0;
+}
+
+/**
+ * mipi_dbi_poweron_reset - MIPI DBI poweron and reset
+ * @mipi: MIPI DBI structure
+ *
+ * This function enables the regulator if used and does a hardware and software
+ * reset.
+ *
+ * Returns:
+ * Zero on success, or a negative error code.
+ */
+int mipi_dbi_poweron_reset(struct mipi_dbi *mipi)
+{
+ return mipi_dbi_poweron_reset_conditional(mipi, false);
+}
+EXPORT_SYMBOL(mipi_dbi_poweron_reset);
+
+/**
+ * mipi_dbi_poweron_conditional_reset - MIPI DBI poweron and conditional reset
+ * @mipi: MIPI DBI structure
+ *
+ * This function enables the regulator if used and if the display is off, it
+ * does a hardware and software reset. If mipi_dbi_display_is_on() determines
+ * that the display is on, no reset is performed.
+ *
+ * Returns:
+ * Zero if the controller was reset, 1 if the display was already on, or a
+ * negative error code.
+ */
+int mipi_dbi_poweron_conditional_reset(struct mipi_dbi *mipi)
+{
+ return mipi_dbi_poweron_reset_conditional(mipi, true);
+}
+EXPORT_SYMBOL(mipi_dbi_poweron_conditional_reset);
+
#if IS_ENABLED(CONFIG_SPI)
/**
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
index 9fd4423c8e70..a6396ef9cc4a 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -179,19 +179,16 @@ static void st7586_
Re: [PATCH v3 7/7] drm/tinydrm/mipi-dbi: Change reset active time
On 01/10/2018 12:59 PM, Noralf Trønnes wrote: The MIPI DBI spec states that reset active/low time should be more than 9us. Change from 20ms to 20us. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/tinydrm/mipi-dbi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c b/drivers/gpu/drm/tinydrm/mipi-dbi.c index 6798b4837441..75dd65c57e74 100644 --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c @@ -414,7 +414,7 @@ void mipi_dbi_hw_reset(struct mipi_dbi *mipi) return; gpiod_set_value_cansleep(mipi->reset, 0); - msleep(20); + usleep_range(20, 1000); gpiod_set_value_cansleep(mipi->reset, 1); msleep(120); } Reviewed-by: David Lechner Tested-by: David Lechner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer
https://bugs.freedesktop.org/show_bug.cgi?id=102800 --- Comment #17 from higu...@gmx.net --- Sorry for the delay! yes, it works! After applying the patch, i can use the radeon card without the runpm=0 normally -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: Pass the proper arguments to nvif_object_map_handle()
From: Thierry Reding
This is obviously wrong in the current code. Make sure to record the
correct size of the arguments and pass the actual arguments to the
nvif_object_map_handle() function.
Suggested-by: Ben Skeggs
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index a8a957207f3a..8334b3f4e60b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1494,11 +1494,13 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *reg)
args.nv50.ro = 0;
args.nv50.kind = mem->kind;
args.nv50.comp = mem->comp;
+ argc = sizeof(args.nv50);
break;
case NVIF_CLASS_MEM_GF100:
args.gf100.version = 0;
args.gf100.ro = 0;
args.gf100.kind = mem->kind;
+ argc = sizeof(args.gf100);
break;
default:
WARN_ON(1);
@@ -1506,7 +1508,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev,
struct ttm_mem_reg *reg)
}
ret = nvif_object_map_handle(&mem->mem.object,
-&argc, argc,
+&args, argc,
&handle, &length);
if (ret != 1) {
pr_info(" nvif_object_map_handle(): %d\n",
ret);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: lvds: fix LVDCR1 for R-Car gen3
Hi Sergei,
On Thursday, 21 December 2017 22:23:30 EET Sergei Shtylyov wrote:
> The LVDCR1 register for the R-Car gen3 SoCs was documented as having the
> layout different from the gen2 SoCs in the early R-Car gen3 manuals but
> since v0.52 the LVDCR1 layout is described as being the same as on the gen2
> SoCs; the old CHn control values are said to be prohibited now (and there
> seems to be no valid output signal when they are used).
>
> Fixes: 6bc2e15cf21c ("drm: rcar-du: lvds: Add R-Car Gen3 support")
> Signed-off-by: Sergei Shtylyov
I've tested this on Salvator-X H3 ES1.1, Salvator-XS H3 ES2.0 and Salvator-X
M3-W, and the LVDS output works correctly. I assume both settings work on
these SoCs, while only the new settings work on V3M. Thus,
Reviewed-by: Laurent Pinchart
Tested-by: Laurent Pinchart
and applied to my tree.
> ---
> drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 10 --
> drivers/gpu/drm/rcar-du/rcar_lvds_regs.h |6 ++
> 2 files changed, 6 insertions(+), 10 deletions(-)
>
> Index: linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> +++ linux/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
> @@ -70,9 +70,8 @@ static void rcar_du_lvdsenc_start_gen2(s
>
> /* Turn all the channels on. */
> rcar_lvds_write(lvds, LVDCR1,
> - LVDCR1_CHSTBY_GEN2(3) | LVDCR1_CHSTBY_GEN2(2) |
> - LVDCR1_CHSTBY_GEN2(1) | LVDCR1_CHSTBY_GEN2(0) |
> - LVDCR1_CLKSTBY_GEN2);
> + LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
> + LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
>
> /*
>* Turn the PLL on, wait for the startup delay, and turn the output
> @@ -109,9 +108,8 @@ static void rcar_du_lvdsenc_start_gen3(s
>
> /* Turn all the channels on. */
> rcar_lvds_write(lvds, LVDCR1,
> - LVDCR1_CHSTBY_GEN3(3) | LVDCR1_CHSTBY_GEN3(2) |
> - LVDCR1_CHSTBY_GEN3(1) | LVDCR1_CHSTBY_GEN3(0) |
> - LVDCR1_CLKSTBY_GEN3);
> + LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
> + LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
>
> /*
>* Turn the PLL on, set it to LVDS normal mode, wait for the startup
> Index: linux/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h
> ===
> --- linux.orig/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h
> +++ linux/drivers/gpu/drm/rcar-du/rcar_lvds_regs.h
> @@ -26,10 +26,8 @@
>
> #define LVDCR1 0x0004
> #define LVDCR1_CKSEL (1 << 15) /* Gen2 only */
> -#define LVDCR1_CHSTBY_GEN2(n)(3 << (2 + (n) * 2))/* Gen2
> only */
> -#define LVDCR1_CHSTBY_GEN3(n)(1 << (2 + (n) * 2))/* Gen3
> only */
> -#define LVDCR1_CLKSTBY_GEN2 (3 << 0)/* Gen2 only */
> -#define LVDCR1_CLKSTBY_GEN3 (1 << 0)/* Gen3 only */
> +#define LVDCR1_CHSTBY(n) (3 << (2 + (n) * 2))
> +#define LVDCR1_CLKSTBY (3 << 0)
>
> #define LVDPLLCR 0x0008
> #define LVDPLLCR_CEEN(1 << 14)
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/vc4: Expose performance counters to userspace
Boris Brezillon writes:
> The V3D engine has various hardware counters which might be interesting
> to userspace performance analysis tools.
>
> Expose new ioctls to create/destroy a performance monitor object and
> query the counter values of this perfmance monitor.
>
> Note that a perfomance monitor is given an ID that is only valid on the
> file descriptor it has been allocated from. A performance monitor can be
> attached to a CL submission and the driver will enable HW counters for
> this request and update the performance monitor values at the end of the
> job.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v2:
> - Get rid of the CL extension stuff
> - Fix isolation of jobs when perfmon attached to them are different
> - Add more comments in the code
> - Use an SPDX header for vc4_perfmon.c
> - Consider 0 as an invalid perfmonid to be backward compatible with mesa
> versions that lack perfmon support
> ---
> drivers/gpu/drm/vc4/Makefile | 1 +
> drivers/gpu/drm/vc4/vc4_drv.c | 26 ++
> drivers/gpu/drm/vc4/vc4_drv.h | 68 ++
> drivers/gpu/drm/vc4/vc4_gem.c | 48 +-
> drivers/gpu/drm/vc4/vc4_irq.c | 40 +++-
> drivers/gpu/drm/vc4/vc4_perfmon.c | 188
> ++
> drivers/gpu/drm/vc4/vc4_regs.h| 35 +--
> drivers/gpu/drm/vc4/vc4_v3d.c | 64 ++---
> include/uapi/drm/vc4_drm.h| 67 ++
> 9 files changed, 465 insertions(+), 72 deletions(-)
> create mode 100644 drivers/gpu/drm/vc4/vc4_perfmon.c
>
> diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
> index f5500df51686..4a3a868235f8 100644
> --- a/drivers/gpu/drm/vc4/Makefile
> +++ b/drivers/gpu/drm/vc4/Makefile
> @@ -15,6 +15,7 @@ vc4-y := \
> vc4_vec.o \
> vc4_hvs.o \
> vc4_irq.o \
> + vc4_perfmon.o \
> vc4_plane.o \
> vc4_render_cl.o \
> vc4_trace_points.o \
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index ceb385fd69c5..94b99c90425a 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -101,6 +101,7 @@ static int vc4_get_param_ioctl(struct drm_device *dev,
> void *data,
> case DRM_VC4_PARAM_SUPPORTS_THREADED_FS:
> case DRM_VC4_PARAM_SUPPORTS_FIXED_RCL_ORDER:
> case DRM_VC4_PARAM_SUPPORTS_MADVISE:
> + case DRM_VC4_PARAM_SUPPORTS_PERFMON:
> args->value = true;
> break;
> default:
> @@ -111,6 +112,26 @@ static int vc4_get_param_ioctl(struct drm_device *dev,
> void *data,
> return 0;
> }
>
> +static int vc4_open(struct drm_device *dev, struct drm_file *file)
> +{
> + struct vc4_file *vc4file;
> +
> + vc4file = kzalloc(sizeof(*vc4file), GFP_KERNEL);
> + if (!vc4file)
> + return -ENOMEM;
> +
> + vc4_perfmon_open_file(vc4file);
> + file->driver_priv = vc4file;
> + return 0;
> +}
> +
> +static void vc4_close(struct drm_device *dev, struct drm_file *file)
> +{
> + struct vc4_file *vc4file = file->driver_priv;
> +
> + vc4_perfmon_close_file(vc4file);
> +}
> +
> static const struct vm_operations_struct vc4_vm_ops = {
> .fault = vc4_fault,
> .open = drm_gem_vm_open,
> @@ -143,6 +164,9 @@ static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(VC4_GET_TILING, vc4_get_tiling_ioctl,
> DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(VC4_LABEL_BO, vc4_label_bo_ioctl, DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(VC4_GEM_MADVISE, vc4_gem_madvise_ioctl,
> DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(VC4_PERFMON_CREATE, vc4_perfmon_create_ioctl,
> DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(VC4_PERFMON_DESTROY, vc4_perfmon_destroy_ioctl,
> DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(VC4_PERFMON_GET_VALUES, vc4_perfmon_get_values_ioctl,
> DRM_RENDER_ALLOW),
> };
>
> static struct drm_driver vc4_drm_driver = {
> @@ -153,6 +177,8 @@ static struct drm_driver vc4_drm_driver = {
> DRIVER_RENDER |
> DRIVER_PRIME),
> .lastclose = drm_fb_helper_lastclose,
> + .open = vc4_open,
> + .postclose = vc4_close,
> .irq_handler = vc4_irq,
> .irq_preinstall = vc4_irq_preinstall,
> .irq_postinstall = vc4_irq_postinstall,
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 3af22936d9b3..fefa1664a9f5 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -11,6 +11,8 @@
> #include
> #include
>
> +#include "uapi/drm/vc4_drm.h"
> +
> /* Don't forget to update vc4_bo.c: bo_type_names[] when adding to
> * this.
> */
> @@ -29,6 +31,36 @@ enum vc4_kernel_bo_type {
> VC4_BO_TYPE_COUNT
> };
>
> +/* Performance monitor object. The perform lifetime is controlled by
> userspace
> + * using perfmon related ioctls. A perfmon can be attached to a submit_cl
> + * request, and when this is the case, HW perf counters will
[PATCH 00/10] R-Car DU: Convert LVDS code to bridge driver
Hello, This patch series addresses a design mistake that dates back from the initial DU support. Support for the LVDS encoders, which are IP cores separate from the DU, was bundled in the DU driver. Worse, both the DU and LVDS were described through a single DT node. To fix the, patches 01/10 and 02/10 define new DT bindings for the LVDS encoders, and deprecate their description inside the DU bindings. To retain backward compatibility with existing DT, patch 03/10 then patches the device tree at runtime to convert the legacy bindings to the new ones. With the DT side addressed, patch 04/10 then converts the LVDS support code to a separate bridge driver. After a small fix to the Porter board device tree in patch 05/10, patches 06/10 to 10/10 then update all the device tree sources to the new LVDS encoders bindings. I decided to go for live DT patching in patch 03/10 because implementing support for both the legacy and new bindings in the driver would have been very intrusive, and prevented further cleanups. I'm in a way both proud and ashamed of that patch that I would call a neat and dirty hack. It was fun to write perhaps in a similar way that one would enjoy researching and developing proof-of-concepts for security holes: they're good and bad at the same time. Anyway, with this philosophical considerations aside, there were a few shortcomings in the OF API that I worked around with local code in the driver. If anyone is interested in performing similar live DT patching I think we could move some of the code to the OF core. For instance I was surprised to not find a device node lookup by path function that would start at a given node instead of the root of the live device tree, and had to write rcar_du_of_find_node_by_path(). Utility functions to add or modify properties or to rename nodes could similarly be added. Laurent Pinchart (10): dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings drm: rcar-du: Fix legacy DT to create LVDS encoder nodes drm: rcar-du: Convert LVDS encoder code to bridge driver ARM: dts: porter: Fix HDMI output routing ARM: dts: r8a7790: Convert to new LVDS DT bindings ARM: dts: r8a7791: Convert to new LVDS DT bindings ARM: dts: r8a7793: Convert to new LVDS DT bindings arm64: dts: renesas: r8a7795: Convert to new LVDS DT bindings arm64: dts: renesas: r8a7796: Convert to new LVDS DT bindings .../bindings/display/bridge/renesas,lvds.txt | 54 ++ .../devicetree/bindings/display/renesas,du.txt | 26 +- MAINTAINERS| 1 + arch/arm/boot/dts/r8a7790-lager.dts| 22 +- arch/arm/boot/dts/r8a7790.dtsi | 61 ++- arch/arm/boot/dts/r8a7791-koelsch.dts | 10 +- arch/arm/boot/dts/r8a7791-porter.dts | 18 +- arch/arm/boot/dts/r8a7791.dtsi | 35 +- arch/arm/boot/dts/r8a7793-gose.dts | 10 +- arch/arm/boot/dts/r8a7793.dtsi | 35 +- .../boot/dts/renesas/r8a7795-es1-salvator-x.dts| 3 +- arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 3 +- .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 35 +- arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 3 +- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 35 +- drivers/gpu/drm/rcar-du/Kconfig| 5 +- drivers/gpu/drm/rcar-du/Makefile | 6 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 21 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 5 - drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 175 +-- drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 12 - drivers/gpu/drm/rcar-du/rcar_du_kms.c | 14 +- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 93 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 24 - drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 270 -- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 64 --- drivers/gpu/drm/rcar-du/rcar_du_of.c | 440 drivers/gpu/drm/rcar-du/rcar_du_of.h | 16 + drivers/gpu/drm/rcar-du/rcar_du_of_lvds.dts| 82 +++ drivers/gpu/drm/rcar-du/rcar_lvds.c| 554 + 33 files changed, 1420 insertions(+), 721 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c delete mode 100644 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c create mode 1006
[PATCH 03/10] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes
The internal LVDS encoders now have their own DT bindings. Before
switching the driver infrastructure to those new bindings, implement
backward-compatibility through live DT patching.
Patching is disabled and will be enabled along with support for the new
DT bindings in the DU driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 1 +
drivers/gpu/drm/rcar-du/Makefile| 2 +
drivers/gpu/drm/rcar-du/rcar_du_of.c| 440
drivers/gpu/drm/rcar-du/rcar_du_of.h| 16 +
drivers/gpu/drm/rcar-du/rcar_du_of_lvds.dts | 82 ++
5 files changed, 541 insertions(+)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of.h
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_of_lvds.dts
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 8a50dab19e5c..e3193ebd3ced 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -22,6 +22,7 @@ config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
select DRM_PANEL
+ select OF_OVERLAY
help
Enable support for the R-Car Display Unit embedded LVDS encoders.
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 0cf5c11030e8..0cf457bef1f2 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -5,6 +5,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
rcar_du_group.o \
rcar_du_kms.o \
rcar_du_lvdscon.o \
+rcar_du_of.o \
+rcar_du_of_lvds.dtb.o \
rcar_du_plane.o
rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_of.c
b/drivers/gpu/drm/rcar-du/rcar_du_of.c
new file mode 100644
index ..c2726e29bd59
--- /dev/null
+++ b/drivers/gpu/drm/rcar-du/rcar_du_of.c
@@ -0,0 +1,440 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * rcar_du_of.c - Legacy DT bindings compatibility
+ *
+ * Copyright (C) 2018 Laurent Pinchart
+ *
+ * Based on work from Jyri Sarha
+ * Copyright (C) 2015 Texas Instruments
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rcar_du_crtc.h"
+#include "rcar_du_drv.h"
+
+extern u8 __dtb_rcar_du_of_lvds_begin[];
+extern u8 __dtb_rcar_du_of_lvds_end[];
+
+struct rcar_du_of_overlay {
+ struct device_node *np;
+ void *data;
+ void *mem;
+};
+
+static void __init rcar_du_of_free_overlay(struct rcar_du_of_overlay *overlay)
+{
+ of_node_put(overlay->np);
+ kfree(overlay->data);
+ kfree(overlay->mem);
+}
+
+static int __init rcar_du_of_get_overlay(struct rcar_du_of_overlay *overlay,
+u8 *begin, u8 *end)
+{
+ const size_t size = end - begin;
+
+ memset(overlay, 0, sizeof(*overlay));
+
+ if (!size)
+ return -EINVAL;
+
+ overlay->data = kmemdup(begin, size, GFP_KERNEL);
+ if (!overlay->data)
+ return -ENOMEM;
+
+ overlay->mem = of_fdt_unflatten_tree(overlay->data, NULL, &overlay->np);
+ if (!overlay->mem) {
+ rcar_du_of_free_overlay(overlay);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static struct device_node __init *
+rcar_du_of_find_node_by_path(struct device_node *parent, const char *path)
+{
+ parent = of_node_get(parent);
+ if (!parent)
+ return NULL;
+
+ while (parent && *path == '/') {
+ struct device_node *child = NULL;
+ struct device_node *node;
+ const char *next;
+ size_t len;
+
+ /* Skip the initial '/' delimiter and find the next one. */
+ path++;
+ next = strchrnul(path, '/');
+ len = next - path;
+ if (!len)
+ goto error;
+
+ for_each_child_of_node(parent, node) {
+ const char *name = kbasename(node->full_name);
+
+ if (strncmp(path, name, len) == 0 &&
+ strlen(name) == len) {
+ child = node;
+ break;
+ }
+ }
+
+ if (!child)
+ goto error;
+
+ of_node_put(parent);
+ parent = child;
+ path = next;
+ }
+
+ return parent;
+
+error:
+ of_node_put(parent);
+ return NULL;
+}
+
+static int __init rcar_du_of_add_property(struct device_node *np,
+ const char *name, const void *value,
+ size_t length)
+{
+ struct property *prop;
+
+ prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+ if (!prop)
+
[PATCH 05/10] ARM: dts: porter: Fix HDMI output routing
The HDMI encoder is connected to the RGB output of the DU, which is
port@0, not port@1. Fix the incorrect DT description.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7791-porter.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts
b/arch/arm/boot/dts/r8a7791-porter.dts
index eb374956294f..9a02d03b23c2 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -425,7 +425,7 @@
"dclkin.0", "dclkin.1";
ports {
- port@1 {
+ port@0 {
endpoint {
remote-endpoint = <&adv7511_in>;
};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/10] ARM: dts: r8a7790: Convert to new LVDS DT bindings
The internal LVDS encoder now has DT bindings separate from the DU. Port
the device tree over to the new model.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7790-lager.dts | 22 ++---
arch/arm/boot/dts/r8a7790.dtsi | 61 -
2 files changed, 71 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 7d5cd01069a3..f84963cb6785 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -317,10 +317,8 @@
status = "okay";
clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>, <&cpg CPG_MOD 722>,
-<&cpg CPG_MOD 726>, <&cpg CPG_MOD 725>,
<&x13_clk>, <&x2_clk>;
- clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1",
- "dclkin.0", "dclkin.1";
+ clock-names = "du.0", "du.1", "du.2", "dclkin.0", "dclkin.1";
ports {
port@0 {
@@ -328,12 +326,26 @@
remote-endpoint = <&adv7123_in>;
};
};
+ };
+};
+
+&lvds0 {
+ status = "okay";
+
+ ports {
port@1 {
endpoint {
remote-endpoint = <&adv7511_in>;
};
};
- port@2 {
+ };
+};
+
+&lvds1 {
+ status = "okay";
+
+ ports {
+ port@1 {
lvds_connector: endpoint {
};
};
@@ -689,7 +701,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
- remote-endpoint = <&du_out_lvds0>;
+ remote-endpoint = <&lvds0_out>;
};
};
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 62baabd757b6..ccb3e4fb36ed 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -1067,17 +1067,14 @@
du: display@feb0 {
compatible = "renesas,du-r8a7790";
- reg = <0 0xfeb0 0 0x7>,
- <0 0xfeb9 0 0x1c>,
- <0 0xfeb94000 0 0x1c>;
- reg-names = "du", "lvds.0", "lvds.1";
+ reg = <0 0xfeb0 0 0x7>;
+ reg-names = "du";
interrupts = ,
,
;
clocks = <&cpg CPG_MOD 724>, <&cpg CPG_MOD 723>,
-<&cpg CPG_MOD 722>, <&cpg CPG_MOD 726>,
-<&cpg CPG_MOD 725>;
- clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1";
+<&cpg CPG_MOD 722>;
+ clock-names = "du.0", "du.1", "du.2";
status = "disabled";
ports {
@@ -1092,11 +1089,61 @@
port@1 {
reg = <1>;
du_out_lvds0: endpoint {
+ remote-endpoint = <&lvds0_in>;
};
};
port@2 {
reg = <2>;
du_out_lvds1: endpoint {
+ remote-endpoint = <&lvds1_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds@feb9 {
+ compatible = "renesas,lvds-r8a7790";
+ reg = <0 0xfeb9 0 0x1c>;
+ clocks = <&cpg CPG_MOD 726>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint = <&du_out_lvds0>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ lvds0_out: endpoint {
+ };
+ };
+ };
+ };
+
+ lvds1: lvds@feb94000 {
+ compatible = "renesas,lvds-r8a7790";
+ reg = <0 0xfeb94000 0 0x1c>;
+ clocks = <&cpg CPG_MOD 725>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds1_in: endpoint {
+ remote-endpoint = <&du_out_lvds1>;
+ }
[PATCH 01/10] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings
The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add
corresponding device tree bindings.
Signed-off-by: Laurent Pinchart
---
.../bindings/display/bridge/renesas,lvds.txt | 54 ++
MAINTAINERS| 1 +
2 files changed, 55 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
new file mode 100644
index ..459c56822eda
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -0,0 +1,54 @@
+Renesas R-Car LVDS Encoder
+==
+
+These DT bindings describe the LVDS encoder embedded in the Renesas R-Car Gen2
+and Gen3 SoCs.
+
+Required properties:
+
+- compatible : Shall contain one of
+ - "renesas,lvds-r8a7743" for R8A7790 (R-Car RZ/G1M) compatible LVDS encoders
+ - "renesas,lvds-r8a7790" for R8A7790 (R-Car H2) compatible LVDS encoders
+ - "renesas,lvds-r8a7791" for R8A7791 (R-Car M2-W) compatible LVDS encoders
+ - "renesas,lvds-r8a7793" for R8A7791 (R-Car M2-N) compatible LVDS encoders
+ - "renesas,lvds-r8a7795" for R8A7795 (R-Car H3) compatible LVDS encoders
+ - "renesas,lvds-r8a7796" for R8A7796 (R-Car M3-W) compatible LVDS encoders
+
+- reg: Base address and length for the memory-mapped registers
+- clocks: A phandle + clock-specifier pair for the functional clock
+
+Requires nodes:
+
+The LVDS encoder has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 corresponds to the parallel input
+- Video port 1 corresponds to the LVDS output
+
+Each port shall have a single endpoint.
+
+
+Example:
+
+ lvds0: lvds@feb9 {
+ compatible = "renesas,lvds-r8a7790";
+ reg = <0 0xfeb9 0 0x1c>;
+ clocks = <&cpg CPG_MOD 726>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint = <&du_out_lvds0>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ lvds0_out: endpoint {
+ };
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 40aea858c7ea..5609a7f5ac4d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4725,6 +4725,7 @@ F:drivers/gpu/drm/rcar-du/
F: drivers/gpu/drm/shmobile/
F: include/linux/platform_data/shmob_drm.h
F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+F: Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
F: Documentation/devicetree/bindings/display/renesas,du.txt
DRM DRIVERS FOR ROCKCHIP
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
