Re: linux-4.11-rc1/drivers/gpu/drm/exynos/exynos5433_drm_decon.c:681: suspicious mask ?
On 09.03.2017 08:34, Inki Dae wrote:
> Hello David,
>
> Thanks for report.
>
> 2017년 03월 06일 19:05에 David Binderman 이(가) 쓴 글:
>> Hello there,
>>
>> linux-4.11-rc1/drivers/gpu/drm/exynos/exynos5433_drm_decon.c:681]: (warning)
>> Result of operator '|' is always true if one operand is non-zero. Did you
>> intend to use '&'?
>>
> Right. this is known issue and below patch fixes this,
> http://www.spinics.net/lists/dri-devel/msg132589.html
>
> This patch will go to -fixes.
>
>> Source code is
>>
>> if (ctx->out_type | I80_HW_TRG) {
>>
>> Also in the same file:
>>
>> [drivers/gpu/drm/exynos/exynos5433_drm_decon.c:131]: (style) Same expression
>> on both sides of '|'.
>>
>> Source code is
>>
>>writel(TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
>>| TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN,
> In this case, only problem is two flags are set in duplicate. This should be
> cleaned up. Thanks. :)
Wrong copy/paste removed two other flags and duplicated these above. It
did not hurt to much as it affects only software trigger which is not
used atm.
Fix sent yesterday [1].
[1]: http://www.spinics.net/lists/dri-devel/msg134877.html
Regards
Andrzej
>
>> Regards
>>
>> David Binderman
>>
>>
> ___
> 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 3/4] phy: rockchip-typec: support DP phy switch
Hi Brian, Am Mittwoch, 8. März 2017, 19:10:50 CET schrieb Brian Norris: > On Thu, Mar 09, 2017 at 02:02:54AM +0100, Heiko Stuebner wrote: > > Am Mittwoch, 8. März 2017, 16:39:23 CET schrieb Brian Norris: > > > On Fri, Feb 10, 2017 at 03:44:13PM +0800, Chris Zhong wrote: > > > > There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence > > > > only one PHY can connect to DP controller at one time, the other > > > > should > > > > be disconnected. The GRF_SOC_CON26 register has a switch bit to do it, > > > > set this bit means enable PHY 1, clear this bit means enable PHY 0. > > > > > > > > Signed-off-by: Chris Zhong > > > > --- > > > > > > > > drivers/phy/phy-rockchip-typec.c | 9 + > > > > 1 file changed, 9 insertions(+) > > > > > > > > diff --git a/drivers/phy/phy-rockchip-typec.c > > > > b/drivers/phy/phy-rockchip-typec.c index 7cfb0f8..1604aaa 100644 > > > > --- a/drivers/phy/phy-rockchip-typec.c > > > > +++ b/drivers/phy/phy-rockchip-typec.c > > ... > > > > > @@ -869,6 +873,11 @@ static int tcphy_parse_dt(struct > > > > rockchip_typec_phy > > > > *tcphy,> > > > > > > > > if (ret) > > > > > > > > return ret; > > > > > > > > + ret = tcphy_get_param(dev, &cfg->uphy_dp_sel, > > > > + "rockchip,uphy-dp-sel"); > > > > + if (ret) > > > > + return ret; > > > > > > What about existing device trees? You're essentially adding this > > > new property and requiring it at the same time. > > > > > > Or are we considering no RK3399 DP stable at the moment? I guess we > > > haven't actually merged any device trees that support this yet, no? > > > > An interesting situation we're in here. On the one hand, you're right this > > breaks "backwards compatiblity". > > > > But on the other hand, the type-c phy is currently very much unused. The > > only current board rk3399-evb.dts does not enable them (so they're > > disabled everywhere) and we have neither dwc3 nor dp nodes in any rk3399 > > devicetrees so far. Also Rob was ok with the binding change :-) . > > > > So from my pov, I'd say it _should_ be ok, as nothing is using the phys at > > all yet and thus there is nothing that could get broken. > > Yeah, I guess it's OK... but BTW out-of-tree DTs are perfectly > legit, once the bindings are accepted. > > Another random point of contention (not worth too much, as the pattern > is already set), but why do these deserve DT properties at all? The > device already has a "rk3399" compatible property, so can't we derive > GRF offsets from that? I'm definitly with you in this regard. But it seems like there is some sort of current trend of moving more stuff into the dt again. I vaguely remember phy and (or) dt-maintainers preferring to have these definitions in the dt for the typec-phy. See also the recent mail from Olof concerning the grf initialization and maybe not having per-soc definitions in the driver, where I'm trying to keep things out of the dt a bit more strongly :-) . So yes, personally I would definitly prefer not having to much GRF-stuff leak into the dt. Simply because the GRF has always been very unstable over time [=you always find one more bit that needs tuning] and to not cause things like the above. But as you said I guess we're to late for the typec-phy. Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Refactor the component match logic.
On 2017年03月08日 13:58, Jeffy Chen wrote:
Currently we are adding all components from the dts, if one of their
drivers been disabled, we would not be able to bring up others.
Right, all the dts related components should enable on kernel
config, otherwise drm can't bring up, high coupling, it's a problem.
Refactor component match logic, follow exynos drm.
RFC. is it a good idea to use platform driver match?
I hesitated, match components with device-tree make code
independent, but indeed has match problem.
Signed-off-by: Jeffy Chen
---
drivers/gpu/drm/rockchip/Kconfig| 10 +-
drivers/gpu/drm/rockchip/Makefile | 16 +--
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 9 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c | 8 +-
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 8 +-
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 10 +-
drivers/gpu/drm/rockchip/inno_hdmi.c| 10 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 156
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 6 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 +-
10 files changed, 133 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 0e4eb84..50c41c0 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -13,7 +13,7 @@ config DRM_ROCKCHIP
IP found on the SoC.
config ROCKCHIP_ANALOGIX_DP
- tristate "Rockchip specific extensions for Analogix DP driver"
+ bool "Rockchip specific extensions for Analogix DP driver"
depends on DRM_ROCKCHIP
select DRM_ANALOGIX_DP
help
@@ -22,7 +22,7 @@ config ROCKCHIP_ANALOGIX_DP
on RK3288 based SoC, you should selet this option.
config ROCKCHIP_CDN_DP
-tristate "Rockchip cdn DP"
+bool "Rockchip cdn DP"
depends on DRM_ROCKCHIP
depends on EXTCON
select SND_SOC_HDMI_CODEC if SND_SOC
@@ -33,7 +33,7 @@ config ROCKCHIP_CDN_DP
option.
config ROCKCHIP_DW_HDMI
-tristate "Rockchip specific extensions for Synopsys DW HDMI"
+bool "Rockchip specific extensions for Synopsys DW HDMI"
depends on DRM_ROCKCHIP
select DRM_DW_HDMI
help
@@ -43,7 +43,7 @@ config ROCKCHIP_DW_HDMI
option.
config ROCKCHIP_DW_MIPI_DSI
- tristate "Rockchip specific extensions for Synopsys DW MIPI DSI"
+ bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
depends on DRM_ROCKCHIP
select DRM_MIPI_DSI
help
@@ -53,7 +53,7 @@ config ROCKCHIP_DW_MIPI_DSI
option.
config ROCKCHIP_INNO_HDMI
- tristate "Rockchip specific extensions for Innosilicon HDMI"
+ bool "Rockchip specific extensions for Innosilicon HDMI"
depends on DRM_ROCKCHIP
help
This selects support for Rockchip SoC specific extensions
diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile
index c931e2a..fa8dc9d 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -3,14 +3,14 @@
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
- rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
+ rockchip_drm_gem.o rockchip_drm_psr.o \
+ rockchip_drm_vop.o rockchip_vop_reg.o
rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
-obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
-obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp.o
-cdn-dp-objs := cdn-dp-core.o cdn-dp-reg.o
-obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
-obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
-obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
-obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
+obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e82..91ebe5c 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -507,7 +507,7 @@ static const struct of_device_id rockchip_dp_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, rockchip_dp_dt_ids);
-static struct platform_driver rockchip_dp_driver = {
+struct platform_driver rockchip_dp_driver = {
.probe = rockchip_dp_probe,
.remove = rockchip_dp_remove,
.driver = {
@@ -516,10 +516,3 @@ static struct platform_driver rockchip_dp_driver = {
.of_match_table = of_match_ptr(rockchip_dp_dt_ids),
},
};
-
-module_platform_driver(rockchip_dp_driver);
-
-MODULE_AUTHOR
[PULL] drm-intel-fixes
Hi Dave, here's two batches of gvt-g fixes. I've got more coming, but no reason to delay these. drm-intel-fixes-2017-03-09: flushing out gvt-g fixes BR, Jani. The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-03-09 for you to fetch changes up to 70647f9163aa4fc7090b0d6795d026ebe3897928: Merge tag 'gvt-fixes-2017-03-08' of https://github.com/01org/gvt-linux into drm-intel-fixes (2017-03-08 12:21:54 +0200) flushing out gvt-g fixes Bing Niu (1): drm/i915/gvt: set SFUSE_STRAP properly for vitual monitor detection Changbin Du (1): drm/i915/gvt: protect RO and Rsvd bits of virtual vgpu configuration space Chuanxiao Dong (3): drm/i915/gvt: add a NULL pointer check to avoid kernel panic drm/i915/gvt: use pfn_valid for better checking drm/i915/gvt: handle workload lifecycle properly Jani Nikula (2): Merge tag 'gvt-next-2017-02-24' of https://github.com/01org/gvt-linux into drm-intel-fixes Merge tag 'gvt-fixes-2017-03-08' of https://github.com/01org/gvt-linux into drm-intel-fixes Min He (2): drm/i915/gvt: introduced failsafe mode into vgpu drm/i915/gvt: enter failsafe mode when guest requires more resources Pei Zhang (2): drm/i915/gvt: add cmd_access to GEN7_HALF_SLICE_CHICKEN1 drm/i915/gvt: add some new MMIOs to cmd_access white list Ping Gao (1): drm/i915/gvt: clear the vGPU reset logic Takashi Iwai (1): drm/i915/gvt: Fix superfluous newline in GVT_DISPLAY_READY env var Tina Zhang (1): drm/i915/gvt: change some gvt_err to gvt_dbg_cmd Weinan Li (2): drm/i915/gvt: refine pcode write emulation drm/i915/gvt: fix pcode mailbox write emulation of BDW Zhao Yan (8): drm/i915/gvt: fix unhandled mmio warnings drm/i915/gvt: add more registers to context save/restore list drm/i915/gvt: force-nopriv register handling drm/i915/gvt: set default value to 0 for unhandled mmio regs drm/i915/gvt: have more registers with F_CMD_ACCESS flags set drm/i915/gvt: add more registers into handlers list drm/i915/gvt: fix an error for one register drm/i915/gvt: fix an error for F_RO flag Zhao, Xinda (3): drm/i915/gvt: handle fence reg access during GPU reset drm/i915/gvt: decrease priority of output msg for untracked mmio drm/i915/gvt: remove unnecessary error msg from gtt write Zhenyu Wang (4): drm/i915/gvt: Fix check error on opregion.c drm/i915/gvt: adjust to fixed vGPU types drm/i915/gvt: Add more edid definition support drm/i915/gvt: add resolution definition for vGPU type drivers/gpu/drm/i915/gvt/cfg_space.c | 57 - drivers/gpu/drm/i915/gvt/cmd_parser.c | 10 +- drivers/gpu/drm/i915/gvt/display.c| 139 +++ drivers/gpu/drm/i915/gvt/display.h| 20 +- drivers/gpu/drm/i915/gvt/firmware.c | 2 +- drivers/gpu/drm/i915/gvt/gtt.c| 40 ++-- drivers/gpu/drm/i915/gvt/gvt.h| 12 +- drivers/gpu/drm/i915/gvt/handlers.c | 439 -- drivers/gpu/drm/i915/gvt/kvmgt.c | 12 +- drivers/gpu/drm/i915/gvt/mmio.c | 66 - drivers/gpu/drm/i915/gvt/opregion.c | 5 +- drivers/gpu/drm/i915/gvt/render.c | 16 ++ drivers/gpu/drm/i915/gvt/scheduler.c | 52 ++-- drivers/gpu/drm/i915/gvt/vgpu.c | 72 +++--- 14 files changed, 686 insertions(+), 256 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
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
2017-03-06 17:04 GMT+01:00 Daniel Vetter : > On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote: >> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote: >> >> > No one gave a thing about android in upstream, so Greg KH just dumped it >> > all into staging/android/. We've discussed ION a bunch of times, recorded >> > anything we'd like to fix in staging/android/TODO, and Laura's patch >> > series here addresses a big chunk of that. >> >> > This is pretty much the same approach we (gpu folks) used to de-stage the >> > syncpt stuff. >> >> Well, there's also the fact that quite a few people have issues with the >> design (like Laurent). It seems like a lot of them have either got more >> comfortable with it over time, or at least not managed to come up with >> any better ideas in the meantime. > > See the TODO, it has everything a really big group (look at the patch for > the full Cc: list) figured needs to be improved at LPC 2015. We don't just > merge stuff because merging stuff is fun :-) > > Laurent was even in that group ... > -Daniel For me those patches are going in the right direction. I still have few questions: - since alignment management has been remove from ion-core, should it be also removed from ioctl structure ? - can you we ride off ion_handle (at least in userland) and only export a dma-buf descriptor ? In the future how can we add new heaps ? Some platforms have very specific memory allocation requirements (just have a look in the number of gem custom allocator in drm) Do you plan to add heap type/mask for each ? Benjamin > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 18/24] drm/etnaviv: switch to postclose
Am Mittwoch, den 08.03.2017, 19:15 +0100 schrieb Daniel Vetter:
> On Wed, Mar 08, 2017 at 05:09:45PM +0100, Lucas Stach wrote:
> > Am Mittwoch, den 08.03.2017, 15:12 +0100 schrieb Daniel Vetter:
> > > I didn't spot anything that would require ordering here (well not
> > > anywhere else either), and I'm trying to unify at least modern
> > > drivers
> > > on one close hook.
> > >
> > > Cc: Lucas Stach
> > > Cc: Russell King
> > > Cc: Christian Gmeiner
> > > Cc: etna...@lists.freedesktop.org
> > > Signed-off-by: Daniel Vetter
> >
> > Acked-by: Lucas Stach
> >
> > for merging through drm-misc
>
> t-b would be great, this entire area is rather wonky and full of decades
> of cargo-culting. I'm not sure I missed something important, so really
> want each patch to see some testing before we merge it, if possible.
> -Daniel
In that case I'll just merge it through my tree, so it gets our usual
internal testing.
Now applied.
Regards,
Lucas
>
> >
> > > ---
> > > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > > b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > > index 587e45043542..289a9f8c6671 100644
> > > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> > > @@ -111,7 +111,7 @@ static int etnaviv_open(struct drm_device *dev,
> > > struct drm_file *file)
> > > return 0;
> > > }
> > >
> > > -static void etnaviv_preclose(struct drm_device *dev, struct drm_file
> > > *file)
> > > +static void etnaviv_postclose(struct drm_device *dev, struct
> > > drm_file *file)
> > > {
> > > struct etnaviv_drm_private *priv = dev->dev_private;
> > > struct etnaviv_file_private *ctx = file->driver_priv;
> > > @@ -488,7 +488,7 @@ static struct drm_driver etnaviv_drm_driver = {
> > > DRIVER_PRIME |
> > > DRIVER_RENDER,
> > > .open = etnaviv_open,
> > > - .preclose = etnaviv_preclose,
> > > + .postclose = etnaviv_postclose,
> > > .gem_free_object_unlocked = etnaviv_gem_free_object,
> > > .gem_vm_ops = &vm_ops,
> > > .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/exynos: mixer: document YCbCr magic numbers
On 06.03.2017 10:43, Tobias Jakobi wrote:
> Hello Andrzej,
>
>
> Andrzej Hajda wrote:
>> On 03.03.2017 14:40, Tobias Jakobi wrote:
>>> The output stage of the mixer uses YCbCr for the internal
>>> computations, which is the reason that some registers take
>>> YCbCr related data as input. In particular this applies
>>> to MXR_BG_COLOR{0,1,2} and MXR_CM_COEFF_{Y,CB,CR}.
>>>
>>> Document the formatting of the data which we write to
>>> these registers.
>>>
>>> While at it, unify wording of comments in the register header.
>>>
>>> Signed-off-by: Tobias Jakobi
>>> ---
>>> drivers/gpu/drm/exynos/exynos_mixer.c | 35
>>> +++
>>> drivers/gpu/drm/exynos/regs-mixer.h | 7 +--
>>> 2 files changed, 32 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> index 41d0c36..3b0b07d 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>>> @@ -45,6 +45,20 @@
>>> #define MIXER_WIN_NR 3
>>> #define VP_DEFAULT_WIN 2
>>>
>>> +/*
>>> + * Mixer color space conversion coefficient triplet.
>>> + * Used for CSC from RGB to YCbCr.
>>> + * Each coefficient is a 10-bit fixed point number with
>>> + * sign and no integer part, i.e.
>> Maybe it would be more clear to say in exclusive range (-1,1)
>>> + * [0:8] = fractional part (representing a value y = x / 2^9)
>>> + * [9] = sign
>>> + * Negative values are encoded with two's complement.
>>> + */
>>> +#define MXR_CSC_CT(a0, a1, a2) (((a0) << 20) | ((a1) << 10) | ((a2) << 0))
>> We can take advantage of the fact that floating point numbers are
>> allowed in compile time, aren't they?
>>
>> #define MXR_CSC_C(x) ((int)((x) * 512) & 0x3ff)
>> #define MXR_CSC_CT(a0, a1, a2) ((MXR_CSC_C(a0) << 20) | (MXR_CSC_C(a1)
>> << 10) | (MXR_CSC_C(a2) << 0))
>>
>> and stop using magic hexadecimals, now we will use real coefficients.
>> MXR_CSC_CT(0.1835, 0.6132, 0.0625)
> I'm not sure if this change of base can be done in a lossless fashion
> without typing out too many digits [see below]. I haven't done the math
> here.
Difference by one in representation corresponds to 0.0019, so four
digits after dot is enough.
> Like I said, no functional changes.
Decision is yours, I can only advice to do not give up.
Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/11] drm/sun4i: Support two display pipelines
On Thu, Mar 09, 2017 at 06:05:23PM +0800, Chen-Yu Tsai wrote: > Hi Maxime, > > This is part 3 of my sun4i drm clean up series. In this part support > for 2 display pipelines is added, after some more code cleanups and > restructuring. > > While this series enables the second display pipeline, there's no > usable output at the moment. For the A31, the second TCON's panel > interface uses the same pins as the Ethernet controller. However > Ethernet is used on most boards. We will have to wait for HDMI > support to actually use it. > > Patch 1 fixes the TCON's clock and regmap initialization sequence, > splitting out the dot clock init part till after the regmap. > > Patch 2 fixes a comment spotted while reviewing Maxime's HDMI patches. > > Patch 3 makes the crtc init code use the tcon pointer embedded in the > crtc structure, instead of the sun4i_drv structure, to get the tcon's > output port node. This should have been a part of the last batch of > patches. > > Patch 4 makes the tv encoder code get the tcon and backend pointers > from its attached crtc. > > Patch 5 makes the crtc init function take tcon and backend pointers. > > Patch 6 makes the layer init functions take a backend pointer. Applied the patches up to this one, see my comments for the rest of the patches. 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 09/11] drm/sun4i: Support two display pipelines
Hi,
On Thu, Mar 09, 2017 at 06:05:32PM +0800, Chen-Yu Tsai wrote:
> Some Allwinner SoCs have two display pipelines (frontend -> backend ->
> tcon).
>
> Previously we only supported one pipeline. This patch extends the
> current driver to support two. It extends the tcon and backend pointers
> in sun4i_drv into arrays, and makes the related bind functions store
> the pointer into said arrays based on the id fetched from the device
> tree. In the case of the tcons, it falls back to a first come order
> if no encoders that can be used for differentiating the tcons are
> defined. The driver's depth-first traversal of the of graph, coupled
> with the increasing address ordering of the of graph endpoints, and
> the fact that tcon0 should always be enabled for the tcon/encoder
> mux to be accessible, means that tcon1 would always come after tcon0.
>
> Assignment of the device structure into sun4i_drv is moved to the end
> of the bind function, when all possible error checks have passed.
>
> This patch also drops a trailing 0 in one of the backend probe messages.
>
> Signed-off-by: Chen-Yu Tsai
> ---
> drivers/gpu/drm/sun4i/sun4i_backend.c | 9 +++--
> drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_drv.h | 6 --
> drivers/gpu/drm/sun4i/sun4i_tcon.c| 25 +
> 4 files changed, 29 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index f3c92d54c8e4..8d22efd5a9cc 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -350,12 +350,15 @@ static int sun4i_backend_bind(struct device *dev,
> struct device *master,
> if (!backend)
> return -ENOMEM;
> dev_set_drvdata(dev, backend);
> - drv->backend = backend;
>
> backend->id = sun4i_backend_of_get_id(dev->of_node);
> if (backend->id < 0)
> return backend->id;
>
> + /* We only support SUN4I_DRM_MAX_PIPELINES number of backends */
> + if (backend->id >= SUN4I_DRM_MAX_PIPELINES)
> + return -EINVAL;
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> regs = devm_ioremap_resource(dev, res);
> if (IS_ERR(regs))
> @@ -364,7 +367,7 @@ static int sun4i_backend_bind(struct device *dev, struct
> device *master,
> backend->regs = devm_regmap_init_mmio(dev, regs,
> &sun4i_backend_regmap_config);
> if (IS_ERR(backend->regs)) {
> - dev_err(dev, "Couldn't create the backend0 regmap\n");
> + dev_err(dev, "Couldn't create the backend regmap\n");
> return PTR_ERR(backend->regs);
> }
>
> @@ -413,6 +416,8 @@ static int sun4i_backend_bind(struct device *dev, struct
> device *master,
> }
> }
>
> + drv->backend[backend->id] = backend;
> +
> /* Reset the registers */
> for (i = 0x800; i < 0x1000; i += 4)
> regmap_write(backend->regs, i, 0);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 767bbadcc85d..c15ecb8343d7 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -271,7 +271,7 @@ static int sun4i_drv_probe(struct platform_device *pdev)
> struct device_node *np = pdev->dev.of_node;
> int i, count = 0;
>
> - for (i = 0;; i++) {
> + for (i = 0; i < SUN4I_DRM_MAX_PIPELINES; i++) {
> struct device_node *pipeline = of_parse_phandle(np,
>
> "allwinner,pipelines",
> i);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h
> b/drivers/gpu/drm/sun4i/sun4i_drv.h
> index 5df50126ff52..ec1c08af47e1 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
> @@ -16,9 +16,11 @@
> #include
> #include
>
> +#define SUN4I_DRM_MAX_PIPELINES 2
> +
> struct sun4i_drv {
> - struct sun4i_backend*backend;
> - struct sun4i_tcon *tcon;
> + struct sun4i_backend*backend[SUN4I_DRM_MAX_PIPELINES];
> + struct sun4i_tcon *tcon[SUN4I_DRM_MAX_PIPELINES];
>
> struct drm_fbdev_cma*fbdev;
> };
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index b774c9a50c55..7749c3133f38 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -532,7 +532,6 @@ static int sun4i_tcon_bind(struct device *dev, struct
> device *master,
> if (!tcon)
> return -ENOMEM;
> dev_set_drvdata(dev, tcon);
> - drv->tcon = tcon;
> tcon->drm = drm;
> tcon->dev = dev;
> tcon->quirks = of_device_get_match_data(dev);
> @@ -540,14 +539,22 @@ static int sun4i_tcon_bind(struct device *dev, struct
> device *master,
> /* This
Re: [PATCH] drm/i915: Nuke skl_update_plane debug message from the pipe update critical section
Op 08-03-17 om 14:12 schreef Ville Syrjälä:
> On Wed, Mar 08, 2017 at 01:00:07PM +0100, Maarten Lankhorst wrote:
>> printks are slow so we should not be doing them from the vblank evade
>> critical section. These could explain why we sometimes seem to
>> blow past our 100 usec deadline.
>>
>> The problem has been there ever since commit bfd16b2a23dc ("drm/i915:
>> Make updating pipe without modeset atomic.")
> I guess that part isn't actually true as far as this printk is
> concerned?
>
> Maybe commit 331879ce8ea ("drm/i915: skylake sprite plane scaling
> using shared scalers")?
>
> Anyways
> Reviewed-by: Ville Syrjälä
>
>> but it may not have
>> been readily visible until commit e1edbd44e23b ("drm/i915: Complain
>> if we take too long under vblank evasion.") increased our chances
>> of noticing it.
>>
>> Signed-off-by: Maarten Lankhorst
>> Cc: Ville Syrjälä
>> ---
>> drivers/gpu/drm/i915/intel_sprite.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
>> b/drivers/gpu/drm/i915/intel_sprite.c
>> index 375ca91b308c..00da5a1ede82 100644
>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>> @@ -271,9 +271,6 @@ skl_update_plane(struct drm_plane *drm_plane,
>> int scaler_id = plane_state->scaler_id;
>> const struct intel_scaler *scaler;
>>
>> -DRM_DEBUG_KMS("plane = %d PS_PLANE_SEL(plane) = 0x%x\n",
>> - plane_id, PS_PLANE_SEL(plane_id));
>> -
>> scaler = &crtc_state->scaler_state.scalers[scaler_id];
>>
>> I915_WRITE(SKL_PS_CTRL(pipe, scaler_id),
>> --
>> 2.7.4
Pushed with the changes.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 22/24] drm: Nerf the preclose callback for modern drivers
On Wed, Mar 08, 2017 at 03:12:55PM +0100, Daniel Vetter wrote:
> With all drivers converted there's only legacy dri1 drivers using it.
> Not going to touch those, instead just hide it like we've done with
> other dri1 driver hooks like firstopen.
>
> In all this I didn't find any real reason why we'd needed 2 hooks, and
> having symmetry between open and close just appeases my OCD better.
> Yeah, someone else could do an s/postclose/close/, but that's for
> someone who understands cocci. And maybe after this series is reviewed
> and landed, to avoid patch-regen churn.
>
> Signed-off-by: Daniel Vetter
From irc:
Acked-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_file.c | 8
> include/drm/drm_drv.h | 23 ++-
> 2 files changed, 6 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index a8813a1115dc..f8483fc6d3d7 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -350,9 +350,8 @@ void drm_lastclose(struct drm_device * dev)
> *
> * This function must be used by drivers as their &file_operations.release
> * method. It frees any resources associated with the open file, and calls
> the
> - * &drm_driver.preclose and &drm_driver.lastclose driver callbacks. If this
> is
> - * the last open file for the DRM device also proceeds to call the
> - * &drm_driver.lastclose driver callback.
> + * &drm_driver.lastclose driver callback. If this is the last open file for
> the
> + * DRM device also proceeds to call the &drm_driver.lastclose driver
> callback.
> *
> * RETURNS:
> *
> @@ -372,7 +371,8 @@ int drm_release(struct inode *inode, struct file *filp)
> list_del(&file_priv->lhead);
> mutex_unlock(&dev->filelist_mutex);
>
> - if (dev->driver->preclose)
> + if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
> + dev->driver->preclose)
> dev->driver->preclose(dev, file_priv);
>
> /*
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 8f900fb30275..fde343e0d581 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -104,23 +104,6 @@ struct drm_driver {
> int (*open) (struct drm_device *, struct drm_file *);
>
> /**
> - * @preclose:
> - *
> - * One of the driver callbacks when a new &struct drm_file is closed.
> - * Useful for tearing down driver-private data structures allocated in
> - * @open like buffer allocators, execution contexts or similar things.
> - *
> - * Since the display/modeset side of DRM can only be owned by exactly
> - * one &struct drm_file (see &drm_file.is_master and &drm_device.master)
> - * there should never be a need to tear down any modeset related
> - * resources in this callback. Doing so would be a driver design bug.
> - *
> - * FIXME: It is not really clear why there's both @preclose and
> - * @postclose. Without a really good reason, use @postclose only.
> - */
> - void (*preclose) (struct drm_device *, struct drm_file *file_priv);
> -
> - /**
>* @postclose:
>*
>* One of the driver callbacks when a new &struct drm_file is closed.
> @@ -131,9 +114,6 @@ struct drm_driver {
>* one &struct drm_file (see &drm_file.is_master and &drm_device.master)
>* there should never be a need to tear down any modeset related
>* resources in this callback. Doing so would be a driver design bug.
> - *
> - * FIXME: It is not really clear why there's both @preclose and
> - * @postclose. Without a really good reason, use @postclose only.
>*/
> void (*postclose) (struct drm_device *, struct drm_file *);
>
> @@ -150,7 +130,7 @@ struct drm_driver {
>* state changes, e.g. in conjunction with the :ref:`vga_switcheroo`
>* infrastructure.
>*
> - * This is called after @preclose and @postclose have been called.
> + * This is called after @postclose hook has been called.
>*
>* NOTE:
>*
> @@ -516,6 +496,7 @@ struct drm_driver {
> /* List of devices hanging off this driver with stealth attach. */
> struct list_head legacy_dev_list;
> int (*firstopen) (struct drm_device *);
> + void (*preclose) (struct drm_device *, struct drm_file *file_priv);
> int (*dma_ioctl) (struct drm_device *dev, void *data, struct drm_file
> *file_priv);
> int (*dma_quiescent) (struct drm_device *);
> int (*context_dtor) (struct drm_device *dev, int context);
> --
> 2.11.0
>
--
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: [PATCH 09/24] drm: Extract drm_file.h
On Wed, Mar 08, 2017 at 12:05:50PM -0300, Gustavo Padovan wrote: > 2017-03-08 Daniel Vetter : > > > I'm torn on whether drm_minor really should be here or somewhere else. > > Maybe with more clarity after untangling drmP.h more this is easier to > > decide, for now I've put a FIXME comment right next to it. Right now > > we need struct drm_minor for the inline drm_file type helpers, and so > > it does kinda make sense to have them here. > > > > Next patch will kerneldoc-ify the entire pile. > > > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_file.c | 5 +- > > include/drm/drmP.h | 127 + > > include/drm/drm_file.h | 172 > > + > > include/drm/drm_prime.h| 1 + > > 4 files changed, 178 insertions(+), 127 deletions(-) > > create mode 100644 include/drm/drm_file.h > > Reviewed-by: Gustavo Padovan Merged up to this patch, thanks a lot to everyone for the reviews. -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
Re: [PATCH 12/15] drm/sun4i: tcon: multiply the vtotal when not in interlace
On Tue, Mar 07, 2017 at 06:05:17PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
> wrote:
> > It appears that the total vertical resolution needs to be doubled when
> > we're not in interlaced. Make sure that is the case.
>
> This is true for both channels, though we handle them differently.
>
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index e44217fb4f6f..515fa56c1e6a 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -248,10 +248,13 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
> > struct drm_encoder *encoder,
> > SUN4I_TCON1_BASIC3_H_BACKPORCH(bp));
> >
> > bp = mode->crtc_vtotal - mode->crtc_vsync_start;
> > + val = mode->crtc_vtotal;
> > + if (!(mode->flags & DRM_MODE_FLAG_INTERLACE))
> > + val = val * 2;
> > DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
> > mode->vtotal, bp);
> > regmap_write(tcon->regs, SUN4I_TCON1_BASIC4_REG,
> > -SUN4I_TCON1_BASIC4_V_TOTAL(mode->vtotal) |
> > +SUN4I_TCON1_BASIC4_V_TOTAL(val) |
>
> For channel 0, the SUN4I_TCON0_BASIC2_V_TOTAL macro multiplies the passed in
> value by 2. I think we should do the same for channel 1, and instead halve the
> value passed in if we are outputting interlaced data. I think this makes more
> sense because:
>
> 1) The register description for both channels are the same. Handling them
>consistently will result in less confusion, such as this one.
>
> 2) The definition of interlaced modes is a frame is separated into odd and
>even fields, with each field contains half the number of lines of the
>full frame. One field is displayed during each VSYNC cycle. The TCON does
>not know whether it's interlaced video or not. It only knows the display
>timings. In this case, the number of horizontal lines per cycle is key.
Hmm, yes, you're right. I'll fix it in the next release.
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 1/15] clk: divider: Make divider_round_rate take the parent clock
Hi Stephen,
On Tue, Mar 07, 2017 at 06:11:57AM -0800, Stephen Boyd wrote:
> On 03/07, Maxime Ripard wrote:
> > So far, divider_round_rate only considers the parent clock returned by
> > clk_hw_get_parent.
> >
> > This works fine on clocks that have a single parents, this doesn't work on
> > muxes, since we will only consider the first parent, while other parents
> > may totally be able to provide a better combination.
> >
> > Clocks in that case cannot use divider_round_rate, so would have to come up
> > with a very similar logic to work around it. Instead of having to do
> > something like this, and duplicate that logic everywhere, give an
> > additional parameter for the parent clock to consider.
> >
> > Current users have been converted using the following coccinelle script
> >
> > @@
> > identifier hw, rate, prate, table, width, flags;
> > @@
> >
> > -long divider_round_rate(struct clk_hw *hw,
> > +long divider_round_rate(struct clk_hw *hw, struct clk_hw *parent,
> > unsigned long rate,
> > unsigned long *prate,
> > const struct clk_div_table *table,
> > u8 width,
> > unsigned long flags) { ... }
> >
> > @@
> > identifier fn, hw;
> > expression E2, E3, E4, E5, E6;
> > @@
> > fn (struct clk_hw *hw, ...) {
> > <...
> > -divider_round_rate(hw, E2, E3, E4, E5, E6)
> > +divider_round_rate(hw, clk_hw_get_parent(hw), E2, E3, E4, E5, E6)
> > ...>
> > }
>
> Why not introduce another function like
>
> divider_round_rate_parent()
> divider_round_rate_mux()
>
> that takes the extra parent argument? Technically, a divider is
> considered to only have one parent, and if it has more than one
> parent, then it is a mux and a divider.
Yes, that would work too, without needing the cross tree change. I'll
do that in the next version.
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 10/15] drm/sun4i: tcon: Switch mux on only for composite
On Wed, Mar 08, 2017 at 11:51:39AM +0800, Chen-Yu Tsai wrote: > On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard > wrote: > > Even though that mux is undocumented, it seems like it needs to be set to 1 > > when using composite, and 0 when using HDMI. > > > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c > > index d2335f109601..93249c5ab1e4 100644 > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c > > @@ -268,11 +268,16 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon, > > struct drm_encoder *encoder, > >SUN4I_TCON_GCTL_IOMAP_MASK, > >SUN4I_TCON_GCTL_IOMAP_TCON1); > > > > + if (encoder->encoder_type == DRM_MODE_ENCODER_TVDAC) > > + val = 1; > > + else > > + val = 0; > > + > > /* > > * FIXME: Undocumented bits > > */ > > if (tcon->quirks->has_unknown_mux) > > - regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1); > > + regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, val); > > We might want to do this the other way around, i.e. exporting > > int sun4i_tcon_mux_set(struct drm_device *drm, int encoder_type, >int pipeline) > > and have downstream encoders call it. For the A31, the mux is not exclusively > used for channel 1; there is a mux setting for MIPI DSI as well, but AFAIK > DSI is connected to channel 0. We could make it part of sun4i_tcon_channel_enable too, though. What do you think? > Additionally, the mux registers are only valid in the first TCON, meaning > it must available be active in 2 pipeline chips. It's also why we'd pass > "struct drm_device *" instead of "struct sun4i_tcon *". H. That's going to be tricky to support. Has this been confirmed somehow? Is the register used for something else on TCON1? 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: [linux-sunxi] [PATCH 14/15] ARM: sun5i: a10s: Add the HDMI controller node
1;4601;0c
On Wed, Mar 08, 2017 at 11:35:39AM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
> wrote:
> > The A10s has an HDMI controller connected to the second TCON channel. Add
> > it to our DT.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > arch/arm/boot/dts/sun5i-a10s.dtsi | 34 -
> > arch/arm/boot/dts/sun5i.dtsi | 1 +-
> > 2 files changed, 35 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi
> > b/arch/arm/boot/dts/sun5i-a10s.dtsi
> > index 074485782a4a..3482c9d2b120 100644
> > --- a/arch/arm/boot/dts/sun5i-a10s.dtsi
> > +++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
> > @@ -72,7 +72,33 @@
> > };
> > };
> >
> > + display-engine {
> > + compatible = "allwinner,sun5i-a10s-display-engine",
> > +"allwinner,sun5i-a13-display-engine";
> > + allwinner,pipelines = <&fe0>;
> > + };
> > +
> > soc@01c0 {
> > + hdmi0: hdmi@01c16000 {
>
> Nit: is the 0 suffix needed? I don't see any indication that there is
> a second controller.
>
> > + compatible = "allwinner,sun5i-a10s-hdmi";
> > + reg = <0x01c16000 0x1000>;
> > + clocks = <&ccu CLK_AHB_HDMI>, <&ccu CLK_HDMI>,
> > +<&ccu CLK_PLL_VIDEO0_2X>,
> > +<&ccu CLK_PLL_VIDEO1_2X>;
> > + clock-names = "ahb", "mod", "pll-0", "pll-1";
> > + status = "disabled";
> > +
> > + port {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + hdmi0_in_tcon0: endpoint@0 {
> > + reg = <0>;
> > + remote-endpoint =
> > <&tcon0_out_hdmi0>;
> > + };
> > + };
> > + };
> > +
> > pwm: pwm@01c20e00 {
> > compatible = "allwinner,sun5i-a10s-pwm";
> > reg = <0x01c20e00 0xc>;
> > @@ -129,3 +155,11 @@
> >
> > &sram_a {
> > };
> > +
> > +&tcon0_out {
> > + tcon0_out_hdmi0: endpoint@2 {
> > + reg = <2>;
> > + remote-endpoint = <&hdmi0_in_tcon0>;
> > + allwinner,tcon-channel = <1>;
> > + };
> > +};
> > diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
> > index f3b6e19244f9..3d009b2aa42a 100644
> > --- a/arch/arm/boot/dts/sun5i.dtsi
> > +++ b/arch/arm/boot/dts/sun5i.dtsi
> > @@ -273,6 +273,7 @@
> > tcon0_out_tve0: endpoint@1 {
> > reg = <1>;
> > remote-endpoint =
> > <&tve0_in_tcon0>;
> > + allwinner,tcon-channel =
> > <1>;
>
> This looks like a separate patch, probably following the binding
> change?
I don't know, the binding says that without anything specified, reg
would be used. I was assuming that we only needed it once we had the
new endpoint to make it consistent, therefore it didn't need an extra
patch.
But I can definitely create one if you want.
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 4/5] drm/radeon: Don't register Thunderbolt eGPU with vga_switcheroo
On Wed, Mar 08, 2017 at 03:34:47PM -0500, Alex Deucher wrote: > On Wed, Mar 8, 2017 at 12:01 AM, Lukas Wunner wrote: > > On Tue, Mar 07, 2017 at 03:30:30PM -0500, Alex Deucher wrote: > >> On Fri, Feb 24, 2017 at 2:19 PM, Lukas Wunner wrote: > >> > An external Thunderbolt GPU can neither drive the laptop's panel nor be > >> > powered off by the platform, so there's no point in registering it with > >> > vga_switcheroo. In fact, when the external GPU is runtime suspended, > >> > vga_switcheroo will cut power to the internal discrete GPU, resulting in > >> > a lockup. > >> > >> I'm not necessarily opposed to this, but I'd prefer something more > >> generic. E.g., what happens if someone uses another dGPU in a docking > >> station or some other sort of PCIe bridge? > > > > Such a dGPU is only relevant to vga_switcheroo if it can either drive > > the panel or be powered off by the platform. Does such a product exist? > > > > I've never heard of one, and think that's because such a product doesn't > > make sense: A docking staton is not power-constrained, it's stationary > > and connected to a wall outlet, so there's no need to power the dGPU off > > when it's not in use. > > > > And at a docking station you're usually connected to a larger monitor, > > so having the dGPU drive the laptop's smaller panel isn't necessary either. > > In the rare cases where there's no larger monitor, you just use the dGPU > > for render offloading, just as you would for contemporary ATPX laptops. > > > > OTOH, dGPUs in Thunderbolt enclosures *do* exist and connecting them > > to an ATPX machine causes failure, as explained in the commit message. > > Whether you introduce additional dGPUs via thunderbolt or some > proprietary interface or a pci bridge in a docking station the result > is still the same. You end up with the potential scenario you > described in this commit message that there may be confusion as to > which GPU is controlled via ACPI power controls. > > I talked to the windows team. They special case thunderbolt as well, Very interesting, thanks for reaching out to them. I've already heard that Windows 10 supports Thunderbolt eGPUs, but only with Thunderbolt 3. I think it's desirable that we achieve feature parity with them (without the unnecessary restriction to Thunderbolt 3). Older Windows versions as well as macOS apparently require all sorts of awful hacks for eGPUs. > so the patch is probably fine. Is that an ack or are there any remaining concerns? > For pcie ports in a docking station, I > suspect there may not actually be any docking stations supported by PX > laptops where this could be an issue. If/when such products do become available, they can probably be identified via specific ACPI methods or if all else fails, DMI quirks. > For non-thunderbolt detachable > graphics there is a new ATIF function to query the bus number of the > supported device. I'll send a patch out for that in a bit. Great, thanks. > Thinking about this more, long term we should probably only register > with vga_switcheroo if we support display muxing which is a legacy > feature these days. Most systems are mux-less so we just need to > handle dgpu power control via runtime pm. Right now registering with vga_switcheroo is still necessary even for muxless systems primarily because DRM drivers call vga_switcheroo_set_dynamic_switch() to pause the HDA driver and update the power state stored internally by vga_switcheroo. I plan to address the former by reworking vga_switcheroo audio handling using functional device dependencies (a new PM mechanism that appeared in v4.10, see documentation in aad800403a87), and I think the latter will then become obsolete as well. I've got a concept in my head and am pumped to code it up, just a little time-constrained at the moment. :-) Thanks, Lukas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 95269] monitors connected to Display Ports not recognised by xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=95269 cokochiaki changed: What|Removed |Added i915 features|display/DP |display/atomic CC||mayoc...@icloud.com QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org Component|DRM/Intel |libdrm Version|XOrg git|DRI git Severity|normal |trivial -- 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 95269] monitors connected to Display Ports not recognised by xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=95269 cokochiaki changed: What|Removed |Added Severity|trivial |normal Component|libdrm |fc-cat Version|DRI git |unspecified Assignee|dri-devel@lists.freedesktop |fontconfig-bugs@lists.freed |.org|esktop.org Product|DRI |fontconfig QA Contact||freedesk...@behdad.org -- 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 23965] radeonBackground objects appear in front of foreground ones in neverball
https://bugs.freedesktop.org/show_bug.cgi?id=23965 cokochiaki changed: What|Removed |Added OS|Linux (All) |Mac OS X (All) -- 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 95269] monitors connected to Display Ports not recognised by xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=95269 Bastien Nocera changed: What|Removed |Added Assignee|nagap...@gmail.com |dri-devel@lists.freedesktop ||.org Product|LDTP|DRI CC|mayoc...@icloud.com | Component|ldtprecord |libdrm -- 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 4/5] drm/radeon: Don't register Thunderbolt eGPU with vga_switcheroo
On Thu, Mar 9, 2017 at 5:55 AM, Lukas Wunner wrote: > On Wed, Mar 08, 2017 at 03:34:47PM -0500, Alex Deucher wrote: >> On Wed, Mar 8, 2017 at 12:01 AM, Lukas Wunner wrote: >> > On Tue, Mar 07, 2017 at 03:30:30PM -0500, Alex Deucher wrote: >> >> On Fri, Feb 24, 2017 at 2:19 PM, Lukas Wunner wrote: >> >> > An external Thunderbolt GPU can neither drive the laptop's panel nor be >> >> > powered off by the platform, so there's no point in registering it with >> >> > vga_switcheroo. In fact, when the external GPU is runtime suspended, >> >> > vga_switcheroo will cut power to the internal discrete GPU, resulting in >> >> > a lockup. >> >> >> >> I'm not necessarily opposed to this, but I'd prefer something more >> >> generic. E.g., what happens if someone uses another dGPU in a docking >> >> station or some other sort of PCIe bridge? >> > >> > Such a dGPU is only relevant to vga_switcheroo if it can either drive >> > the panel or be powered off by the platform. Does such a product exist? >> > >> > I've never heard of one, and think that's because such a product doesn't >> > make sense: A docking staton is not power-constrained, it's stationary >> > and connected to a wall outlet, so there's no need to power the dGPU off >> > when it's not in use. >> > >> > And at a docking station you're usually connected to a larger monitor, >> > so having the dGPU drive the laptop's smaller panel isn't necessary either. >> > In the rare cases where there's no larger monitor, you just use the dGPU >> > for render offloading, just as you would for contemporary ATPX laptops. >> > >> > OTOH, dGPUs in Thunderbolt enclosures *do* exist and connecting them >> > to an ATPX machine causes failure, as explained in the commit message. >> >> Whether you introduce additional dGPUs via thunderbolt or some >> proprietary interface or a pci bridge in a docking station the result >> is still the same. You end up with the potential scenario you >> described in this commit message that there may be confusion as to >> which GPU is controlled via ACPI power controls. >> >> I talked to the windows team. They special case thunderbolt as well, > > Very interesting, thanks for reaching out to them. I've already heard > that Windows 10 supports Thunderbolt eGPUs, but only with Thunderbolt 3. > I think it's desirable that we achieve feature parity with them (without > the unnecessary restriction to Thunderbolt 3). Older Windows versions as > well as macOS apparently require all sorts of awful hacks for eGPUs. > > >> so the patch is probably fine. > > Is that an ack or are there any remaining concerns? Series is: Acked-by: Alex Deucher > > >> For pcie ports in a docking station, I >> suspect there may not actually be any docking stations supported by PX >> laptops where this could be an issue. > > If/when such products do become available, they can probably be identified > via specific ACPI methods or if all else fails, DMI quirks. > > >> For non-thunderbolt detachable >> graphics there is a new ATIF function to query the bus number of the >> supported device. I'll send a patch out for that in a bit. > > Great, thanks. > > >> Thinking about this more, long term we should probably only register >> with vga_switcheroo if we support display muxing which is a legacy >> feature these days. Most systems are mux-less so we just need to >> handle dgpu power control via runtime pm. > > Right now registering with vga_switcheroo is still necessary even for > muxless systems primarily because DRM drivers call > vga_switcheroo_set_dynamic_switch() to pause the HDA driver and update > the power state stored internally by vga_switcheroo. > > I plan to address the former by reworking vga_switcheroo audio handling > using functional device dependencies (a new PM mechanism that appeared > in v4.10, see documentation in aad800403a87), and I think the latter will > then become obsolete as well. I've got a concept in my head and am > pumped to code it up, just a little time-constrained at the moment. :-) Thanks for looking into it. Alex > > Thanks, > > Lukas > ___ > 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 09/11] drm/sun4i: Support two display pipelines
On Thu, Mar 09, 2017 at 07:20:30PM +0800, Chen-Yu Tsai wrote:
> On Thu, Mar 9, 2017 at 6:36 PM, Maxime Ripard
> wrote:
> > Hi,
> >
> > On Thu, Mar 09, 2017 at 06:05:32PM +0800, Chen-Yu Tsai wrote:
> >> Some Allwinner SoCs have two display pipelines (frontend -> backend ->
> >> tcon).
> >>
> >> Previously we only supported one pipeline. This patch extends the
> >> current driver to support two. It extends the tcon and backend pointers
> >> in sun4i_drv into arrays, and makes the related bind functions store
> >> the pointer into said arrays based on the id fetched from the device
> >> tree. In the case of the tcons, it falls back to a first come order
> >> if no encoders that can be used for differentiating the tcons are
> >> defined. The driver's depth-first traversal of the of graph, coupled
> >> with the increasing address ordering of the of graph endpoints, and
> >> the fact that tcon0 should always be enabled for the tcon/encoder
> >> mux to be accessible, means that tcon1 would always come after tcon0.
> >>
> >> Assignment of the device structure into sun4i_drv is moved to the end
> >> of the bind function, when all possible error checks have passed.
> >>
> >> This patch also drops a trailing 0 in one of the backend probe messages.
> >>
> >> Signed-off-by: Chen-Yu Tsai
> >> ---
> >> drivers/gpu/drm/sun4i/sun4i_backend.c | 9 +++--
> >> drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
> >> drivers/gpu/drm/sun4i/sun4i_drv.h | 6 --
> >> drivers/gpu/drm/sun4i/sun4i_tcon.c| 25 +
> >> 4 files changed, 29 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> index f3c92d54c8e4..8d22efd5a9cc 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> >> @@ -350,12 +350,15 @@ static int sun4i_backend_bind(struct device *dev,
> >> struct device *master,
> >> if (!backend)
> >> return -ENOMEM;
> >> dev_set_drvdata(dev, backend);
> >> - drv->backend = backend;
> >>
> >> backend->id = sun4i_backend_of_get_id(dev->of_node);
> >> if (backend->id < 0)
> >> return backend->id;
> >>
> >> + /* We only support SUN4I_DRM_MAX_PIPELINES number of backends */
> >> + if (backend->id >= SUN4I_DRM_MAX_PIPELINES)
> >> + return -EINVAL;
> >> +
> >> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> regs = devm_ioremap_resource(dev, res);
> >> if (IS_ERR(regs))
> >> @@ -364,7 +367,7 @@ static int sun4i_backend_bind(struct device *dev,
> >> struct device *master,
> >> backend->regs = devm_regmap_init_mmio(dev, regs,
> >> &sun4i_backend_regmap_config);
> >> if (IS_ERR(backend->regs)) {
> >> - dev_err(dev, "Couldn't create the backend0 regmap\n");
> >> + dev_err(dev, "Couldn't create the backend regmap\n");
> >> return PTR_ERR(backend->regs);
> >> }
> >>
> >> @@ -413,6 +416,8 @@ static int sun4i_backend_bind(struct device *dev,
> >> struct device *master,
> >> }
> >> }
> >>
> >> + drv->backend[backend->id] = backend;
> >> +
> >> /* Reset the registers */
> >> for (i = 0x800; i < 0x1000; i += 4)
> >> regmap_write(backend->regs, i, 0);
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
> >> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> >> index 767bbadcc85d..c15ecb8343d7 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> >> @@ -271,7 +271,7 @@ static int sun4i_drv_probe(struct platform_device
> >> *pdev)
> >> struct device_node *np = pdev->dev.of_node;
> >> int i, count = 0;
> >>
> >> - for (i = 0;; i++) {
> >> + for (i = 0; i < SUN4I_DRM_MAX_PIPELINES; i++) {
> >> struct device_node *pipeline = of_parse_phandle(np,
> >>
> >> "allwinner,pipelines",
> >> i);
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h
> >> b/drivers/gpu/drm/sun4i/sun4i_drv.h
> >> index 5df50126ff52..ec1c08af47e1 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_drv.h
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
> >> @@ -16,9 +16,11 @@
> >> #include
> >> #include
> >>
> >> +#define SUN4I_DRM_MAX_PIPELINES 2
> >> +
> >> struct sun4i_drv {
> >> - struct sun4i_backend*backend;
> >> - struct sun4i_tcon *tcon;
> >> + struct sun4i_backend*backend[SUN4I_DRM_MAX_PIPELINES];
> >> + struct sun4i_tcon *tcon[SUN4I_DRM_MAX_PIPELINES];
> >>
> >> struct drm_fbdev_cma*fbdev;
> >> };
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> index b774c9a50c55..7749c3133f38 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> +++ b/drivers/gpu/drm
Re: [linux-sunxi] Re: [PATCH 10/15] drm/sun4i: tcon: Switch mux on only for composite
On Thu, Mar 09, 2017 at 07:31:27PM +0800, Chen-Yu Tsai wrote: > >> Additionally, the mux registers are only valid in the first TCON, meaning > >> it must available be active in 2 pipeline chips. It's also why we'd pass > >> "struct drm_device *" instead of "struct sun4i_tcon *". > > > > H. That's going to be tricky to support. Has this been confirmed > > somehow? Is the register used for something else on TCON1? > > At this point, the only reference is Allwinner's kernel, and the old 3.4 > kernel for A10/A20. I could try getting HDMI working on the A31 to get > some real results. > > FWIW, the registers do not seem to be aliased across the two TCONs. Then maybe we don't need to care, and we can just always write to the mux? 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 0/5] Thunderbolt GPU fixes
On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote:
> Fix Thunderbolt-related issues in apple-gmux and vga_switcheroo:
>
> Patch [1/5] ("Recognize Thunderbolt devices") has already been subjected
> to a fair amount of scrutiny over at linux-pci@, I've submitted it 5 times
> total since May 2016. With luck it may be in ack-able shape now.
>
> Patch [2/5] amends apple-gmux to handle combined DP/Thunderbolt ports
> properly on newer MacBook Pros.
>
> Patches [3/5] to [5/5] avoid registering external Thunderbolt GPUs with
> vga_switcheroo: Dave Airlie designed vga_switcheroo to register GPUs
> unconditionally. So if a desktop box has multiple GPUs, vga_switcheroo
> will see more than one discrete GPU but that's not a problem because on
> desktop boxes no handler is registered and thus vga_switcheroo_enable()
> is never called. Hybrid graphics laptops on the other hand do register
> a handler, but are assumed to never register more than one discrete GPU.
> However once a Thunderbolt eGPU is attached to a hybrid graphics laptop,
> that assumption is no longer true and things go south when vga_switcheroo
> runtime suspends the external discrete GPU and then calls the handler to
> cut power to the internal discrete GPU. The driver for the internal GPU
> will sit there puzzled and typically cause a lockup.
>
> This series is just a first step towards proper handling of eGPUs, another
> will be support for surprise removal: DRM drivers need to cease MMIO and
> PCI config space access once a device is gone to avoid delaying device
> teardown or accessing a newly attached replacement device. Also, MMIO
> reads to removed devices return "all ones", which results in an infinite
> loop e.g. in nouveau's nvkm_nsec().
>
> The question is how to recognize device removal. One common method is to
> read the vendor register with pci_device_is_present(), but this reports
> a false positive if the device is present but in D3cold. A better method
> is to let the PCIe hotplug driver recognize and cache device removal.
> Keith Busch has developed patches which do exactly that, they're now at
> v6 and fully reviewed by Christoph Hellwig but alas were not included in
> the 4.11 PCI pull for some reason:
> http://www.spinics.net/lists/linux-pci/msg58123.html
>
> I've pushed the present series to GitHub in case anyone prefers reviewing
> it in a GUI:
> https://github.com/l1k/linux/commits/thunderbolt_gpu_v1
For merging, should I smash this all into drm-misc? The only thing outside
is the apple-gmux driver ...
-Daniel
>
> Thanks,
>
> Lukas
>
>
> Lukas Wunner (5):
> PCI: Recognize Thunderbolt devices
> apple-gmux: Don't switch external DP port on 2011+ MacBook Pros
> drm/nouveau: Don't register Thunderbolt eGPU with vga_switcheroo
> drm/radeon: Don't register Thunderbolt eGPU with vga_switcheroo
> drm/amdgpu: Don't register Thunderbolt eGPU with vga_switcheroo
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 3 ++-
> drivers/gpu/drm/nouveau/nouveau_vga.c | 10 +-
> drivers/gpu/drm/radeon/radeon_device.c | 7 +--
> drivers/gpu/drm/radeon/radeon_kms.c| 3 ++-
> drivers/pci/pci.h | 2 ++
> drivers/pci/probe.c| 21
> drivers/platform/x86/apple-gmux.c | 31
> +-
> include/linux/pci.h| 23 ++
> 9 files changed, 99 insertions(+), 8 deletions(-)
>
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v9] drm/i915: enable scrambling
+ intel-gfx
+ dri-devl
(missed in in-reply-to)
Regards
Shashank
-Original Message-
From: Sharma, Shashank
Sent: Thursday, March 9, 2017 6:02 PM
To: ville.syrj...@linux.intel.com; conselv...@gmail.com
Cc: Sharma, Shashank
Subject: [PATCH v9] drm/i915: enable scrambling
Geminilake platform sports a native HDMI 2.0 controller, and is capable of
driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these
higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required, enables
it during the modeset.
V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
in intel_enable_ddi() before enabling the port.
V3: Addressed review comments from Jani
- In comments, function names, use "sink" instead of "monitor",
so that the implementation could be close to the language of
HDMI spec.
V4: Addressed review comment from Maarten
- scrambling -> hdmi_scrambling
- high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
V5: Addressed review comments from Ville and Ander
- Do not modifiy the crtc_state after compute_config. Move all
scrambling and tmds_clock_ratio calcutations to compute_config.
- While setting scrambling for source/sink, do not check the
conditions again, just go by the crtc_state flags. This will
simplyfy the condition checks.
V6: Addressed review comments from Ville
- Do not add IS_GLK check in disable/enable function, instead add it
in compute_config, while setting state flags.
- Remove unnecessary paranthesis.
- Simplyfy handle_sink_scrambling function as suggested.
- Add readout code for scrambling status in get_ddi_config and add a
check for the same in pipe_config_compare.
V7: Addressed review comments from Ander/Ville
- No separate function for source scrambling, make it inline
- Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
- Do not add platform check while setting source scrambling
- Use pipe_config instead of crtc->config to set sink scrambling
- To readout scrambling status, Compare with SCRAMBLING_MASK
not any of its bits
- Remove platform check in intel_pipe_config_compare while checking
scrambling status
V8: Fixed mege conflict, Addressed review comments from Ander
- Remove the desciption/comment about scrambling fom the caller, move
it to the function
- Move the IS_GLK check into scrambling function
- Fix alignment
V9: Fixed review comments from Ville, Ander
- Pass the scrambling state variables as bool input to the sink_scrambling
function and let the disable call be unconditional.
- Fix alignments in function calls and debug messages.
- Add kernel doc for function intel_hdmi_handle_sink_scrambling
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 7
drivers/gpu/drm/i915/intel_ddi.c | 23 +
drivers/gpu/drm/i915/intel_display.c | 3 ++
drivers/gpu/drm/i915/intel_drv.h | 10 ++
drivers/gpu/drm/i915/intel_hdmi.c| 63
5 files changed, 106 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cc843f9..2d50fdc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7830,7 +7830,14 @@ enum {
#define TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12)
#define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
#define TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
+#define TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7) #define
+TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
#define TRANS_DDI_BFI_ENABLE (1<<4)
+#define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define TRANS_DDI_HDMI_SCRAMBLING (1<<0)
+#define TRANS_DDI_HDMI_SCRAMBLING_MASK (TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE \
+ | TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ \
+ | TRANS_DDI_HDMI_SCRAMBLING)
/* DisplayPort Transport Control */
#define _DP_TP_CTL_A 0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ee341ef..169d2b4 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1309,6 +1309,11 @@ void intel_ddi_enable_transcoder_func(const struct
intel_crtc_state *crtc_state)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+ if (crtc_state->hdmi_scrambling)
+ temp |= TRANS_DDI_HDMI_SCRAMBLING_MASK;
+ if (crtc_state->hdmi_high_tmds_clock_ratio)
+ temp |= TRANS_DDI_HIGH_TMDS_CHAR_RATE;
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (crtc_state->fdi_lanes - 1) << 1; @@ -1881,6 +188
[drm-tip:drm-tip 777/788] include/drm/drm_pci.h:76:64: warning: 'struct platform_device' declared inside parameter list will not be visible outside of this definition or declaration
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 510c200742ced5a91d07e48220b669a3c9b30c0c
commit: 23ef59ef6dcc9b62bf077490a74df93b3bb0d530 [777/788] drm: Extract
drm_pci.h
config: i386-randconfig-x070-201710 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 23ef59ef6dcc9b62bf077490a74df93b3bb0d530
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/drm_pci.c:29:0:
>> include/drm/drm_pci.h:76:64: warning: 'struct platform_device' declared
>> inside parameter list will not be visible outside of this definition or
>> declaration
extern int drm_platform_init(struct drm_driver *driver, struct
platform_device *platform_device);
^~~
vim +76 include/drm/drm_pci.h
60
61 static inline int drm_pci_set_busid(struct drm_device *dev,
62 struct drm_master *master)
63 {
64 return -ENOSYS;
65 }
66 #endif
67
68 #define DRM_PCIE_SPEED_25 1
69 #define DRM_PCIE_SPEED_50 2
70 #define DRM_PCIE_SPEED_80 4
71
72 extern int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32
*speed_mask);
73 extern int drm_pcie_get_max_link_width(struct drm_device *dev, u32
*mlw);
74
75 /* platform section */
> 76 extern int drm_platform_init(struct drm_driver *driver, struct
platform_device *platform_device);
77
78 #endif /* _DRM_PCI_H_ */
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] intel: fix a conversion format mismatch
Hi Chih-Wei, On 9 March 2017 at 02:12, Chih-Wei Huang wrote: > To avoid the warning: > > external/libdrm/intel/intel_bufmgr.c:362:20: warning: more '%' conversions > than data arguments [-Wformat] > fprintf(stderr, "%s: Mappable aperture size hardcoded to 64MiB\n"); > ~^ > This seems to depend on the patch from Tomasz, which removes the libpciaccess dependency and stubs the API. Personally I don't mind having that one land and if so, this fix should be squashed. > Change-Id: I6c1b0a9e3004aacde0d64662de1144cadff30132 Please drop these and use your s-o-b for upstream submissions. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On 03/09/2017 02:00 AM, Benjamin Gaignard wrote: > 2017-03-06 17:04 GMT+01:00 Daniel Vetter : >> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote: >>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote: >>> No one gave a thing about android in upstream, so Greg KH just dumped it all into staging/android/. We've discussed ION a bunch of times, recorded anything we'd like to fix in staging/android/TODO, and Laura's patch series here addresses a big chunk of that. >>> This is pretty much the same approach we (gpu folks) used to de-stage the syncpt stuff. >>> >>> Well, there's also the fact that quite a few people have issues with the >>> design (like Laurent). It seems like a lot of them have either got more >>> comfortable with it over time, or at least not managed to come up with >>> any better ideas in the meantime. >> >> See the TODO, it has everything a really big group (look at the patch for >> the full Cc: list) figured needs to be improved at LPC 2015. We don't just >> merge stuff because merging stuff is fun :-) >> >> Laurent was even in that group ... >> -Daniel > > For me those patches are going in the right direction. > > I still have few questions: > - since alignment management has been remove from ion-core, should it > be also removed from ioctl structure ? Yes, I think I'm going to go with the suggestion to fixup the ABI so we don't need the compat layer and as part of that I'm also dropping the align argument. > - can you we ride off ion_handle (at least in userland) and only > export a dma-buf descriptor ? Yes, I think this is the right direction given we're breaking everything anyway. I was debating trying to keep the two but moving to only dma bufs is probably cleaner. The only reason I could see for keeping the handles is running out of file descriptors for dma-bufs but that seems unlikely. > > In the future how can we add new heaps ? > Some platforms have very specific memory allocation > requirements (just have a look in the number of gem custom allocator in drm) > Do you plan to add heap type/mask for each ? Yes, that was my thinking. > > Benjamin > Thanks, Laura ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/tegra: Support for sync file-based fences in submit
Add support for sync file-based prefences and postfences
to job submission. Fences are passed to the Host1x implementation.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.c | 69 ++---
1 file changed, 59 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 64dff8530403..bf4a2a13c17d 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -344,6 +345,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;
@@ -361,6 +363,11 @@ int tegra_drm_submit(struct tegra_drm_context *context,
if (args->num_syncpts != 1)
return -EINVAL;
+ /* Check for unrecognized flags */
+ if (args->flags & ~(DRM_TEGRA_SUBMIT_WAIT_FENCE_FD |
+ DRM_TEGRA_SUBMIT_CREATE_FENCE_FD))
+ return -EINVAL;
+
job = host1x_job_alloc(context->channel, args->num_cmdbufs,
args->num_relocs, args->num_waitchks);
if (!job)
@@ -372,19 +379,27 @@ 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_job;
+ }
+ }
+
while (num_cmdbufs) {
struct drm_tegra_cmdbuf cmdbuf;
struct host1x_bo *bo;
if (copy_from_user(&cmdbuf, cmdbufs, sizeof(cmdbuf))) {
err = -EFAULT;
- goto fail;
+ goto put_fence;
}
bo = host1x_bo_lookup(file, cmdbuf.handle);
if (!bo) {
err = -ENOENT;
- goto fail;
+ goto put_fence;
}
host1x_job_add_gather(job, bo, cmdbuf.words, cmdbuf.offset);
@@ -398,19 +413,19 @@ int tegra_drm_submit(struct tegra_drm_context *context,
&relocs[num_relocs], drm,
file);
if (err < 0)
- goto fail;
+ goto put_fence;
}
if (copy_from_user(job->waitchk, waitchks,
sizeof(*waitchks) * num_waitchks)) {
err = -EFAULT;
- goto fail;
+ goto put_fence;
}
if (copy_from_user(&syncpt, (void __user *)(uintptr_t)args->syncpts,
sizeof(syncpt))) {
err = -EFAULT;
- goto fail;
+ goto put_fence;
}
job->is_addr_reg = context->client->ops->is_addr_reg;
@@ -423,20 +438,54 @@ int tegra_drm_submit(struct tegra_drm_context *context,
err = host1x_job_pin(job, context->client->base.dev);
if (err)
- goto fail;
+ goto put_fence;
err = host1x_job_submit(job);
if (err)
- goto fail_submit;
+ goto unpin_job;
- args->fence = job->syncpt_end;
+ if (args->flags & DRM_TEGRA_SUBMIT_CREATE_FENCE_FD) {
+ struct dma_fence *fence;
+ struct sync_file *file;
+
+ fence = host1x_fence_create(
+ host1x, host1x_syncpt_get(host1x, job->syncpt_id),
+ job->syncpt_end);
+ if (!fence) {
+ err = -ENOMEM;
+ goto put_fence;
+ }
+
+ file = sync_file_create(fence);
+ if (!file) {
+ dma_fence_put(fence);
+ err = -ENOMEM;
+ goto put_fence;
+ }
+
+ err = get_unused_fd_flags(O_CLOEXEC);
+ if (err < 0) {
+ dma_fence_put(fence);
+ goto put_fence;
+ }
+
+ fd_install(err, file->file);
+ args->fence = err;
+ } else {
+ args->fence = job->syncpt_end;
+ }
+ if (job->prefence)
+ dma_fence_put(job->prefence);
host1x_job_put(job);
return 0;
-fail_submit:
+unpin_job:
host1x_job_unpin(job);
-fail:
+put_fence:
+ if (job->prefence)
+
[PATCH 2/3] drm/tegra: Add sync file support to submit interface
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
---
include/uapi/drm/tegra_drm.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index d954f8c33321..b85689c15d8f 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -117,6 +117,9 @@ struct drm_tegra_waitchk {
__u32 thresh;
};
+#define DRM_TEGRA_SUBMIT_WAIT_FENCE_FD (1 << 0)
+#define DRM_TEGRA_SUBMIT_CREATE_FENCE_FD (1 << 1)
+
struct drm_tegra_submit {
__u64 context;
__u32 num_syncpts;
@@ -129,9 +132,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.11.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] Tegra Host1x dma_fence/sync_file support
Hi everyone, this series adds support for using sync fences as prefences and postfences for host1x job submissions. The patches are available as a git repository at https://github.com/cyndis/linux/tree/host1x-fence-1 and testing code is available at https://github.com/cyndis/host1x_test though you may want to edit the main function to disable the timeout tests for now as they cause a deadlock (not caused by this series; fix upcoming). Verified on a Jetson TX1; should go on top of the earlier VIC series. Some additional points: * I noticed that the waitchk_mask field in the submit UAPI is completely useless, and has never had any effect in the upstream kernel. It has also not existed in the downstream kernel for many years. We could replace it with the flags field if that is deemed acceptable, though of course it is possible there exists some application that fills it with some non-zero value. * Signaling is enabled for all host1x fences, not just those for which enable_signaling has been called. This is because enable_signaling is called from atomic context and we cannot set up an action waiter in atomic context. Thanks, Mikko 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| 69 +++-- 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 | 8 +- 12 files changed, 367 insertions(+), 23 deletions(-) create mode 100644 drivers/gpu/host1x/fence.c create mode 100644 drivers/gpu/host1x/fence.h -- 2.11.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] gpu: host1x: Add support for DMA fences
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
---
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 b2fd029d67b3..3ede4aede6c3 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
help
Driver for the NVIDIA Tegra host1x hardware.
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index a1d9974cfcb5..e5d61542b9b5 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -8,6 +8,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 e5113acecd7a..1ee79dbd1882 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,
@@ -41,6 +41,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 {
@@ -110,6 +111,8 @@ struct host1x {
struct device *dev;
struct clk *clk;
+ u64 fence_ctx_base;
+
struct iommu_domain *domain;
struct iova_domain iova;
dma_addr_t iova_end;
@@ -230,6 +233,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
[drm-intel:drm-intel-nightly 777/788] include/drm/drm_pci.h:76:64: warning: 'struct platform_device' declared inside parameter list
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 510c200742ced5a91d07e48220b669a3c9b30c0c
commit: 23ef59ef6dcc9b62bf077490a74df93b3bb0d530 [777/788] drm: Extract
drm_pci.h
config: tile-tilegx_defconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 23ef59ef6dcc9b62bf077490a74df93b3bb0d530
# save the attached .config to linux build tree
make.cross ARCH=tile
All warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/drm_pci.c:29:0:
>> include/drm/drm_pci.h:76:64: warning: 'struct platform_device' declared
>> inside parameter list [enabled by default]
>> include/drm/drm_pci.h:76:64: warning: its scope is only this definition or
>> declaration, which is probably not what you want [enabled by default]
vim +76 include/drm/drm_pci.h
60
61 static inline int drm_pci_set_busid(struct drm_device *dev,
62 struct drm_master *master)
63 {
64 return -ENOSYS;
65 }
66 #endif
67
68 #define DRM_PCIE_SPEED_25 1
69 #define DRM_PCIE_SPEED_50 2
70 #define DRM_PCIE_SPEED_80 4
71
72 extern int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32
*speed_mask);
73 extern int drm_pcie_get_max_link_width(struct drm_device *dev, u32
*mlw);
74
75 /* platform section */
> 76 extern int drm_platform_init(struct drm_driver *driver, struct
platform_device *platform_device);
77
78 #endif /* _DRM_PCI_H_ */
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Tegra Host1x dma_fence/sync_file support
On Thu, Mar 9, 2017 at 6:57 PM, Mikko Perttunen wrote: > Hi everyone, > > this series adds support for using sync fences as prefences and > postfences for host1x job submissions. The patches are available > as a git repository at > > https://github.com/cyndis/linux/tree/host1x-fence-1 > > and testing code is available at > > https://github.com/cyndis/host1x_test > > though you may want to edit the main function to disable the > timeout tests for now as they cause a deadlock (not caused > by this series; fix upcoming). > > Verified on a Jetson TX1; should go on top of the earlier > VIC series. > > Some additional points: > * I noticed that the waitchk_mask field in the submit UAPI is completely > useless, and has never had any effect in the upstream kernel. > It has also not existed in the downstream kernel for many years. > We could replace it with the flags field if that is deemed > acceptable, though of course it is possible there exists some > application that fills it with some non-zero value. If open source userspace (nouveau_dri.so) never used it, then you can freely change it. Backwards compat guarantee in drm is only for open source userspace (and by implication ofc anything that uses the ioctl the same way). See: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements On that topic, do we have the nouveau patches to enable the egl_android extension for this already published? > * Signaling is enabled for all host1x fences, not just those for > which enable_signaling has been called. This is because > enable_signaling is called from atomic context and we cannot set > up an action waiter in atomic context. Yeah, this was some good fun getting it all sorted in i915 too :-) -Daniel > > Thanks, > Mikko > > 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| 69 +++-- > 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 | 8 +- > 12 files changed, 367 insertions(+), 23 deletions(-) > create mode 100644 drivers/gpu/host1x/fence.c > create mode 100644 drivers/gpu/host1x/fence.h > > -- > 2.11.1 > > ___ > 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
[PATCH 2/3] drm/tegra: Protect IOMMU operations by mutex
From: Thierry Reding
IOMMU support is currently not thread-safe, which can cause crashes,
amongst other things, under certain workloads.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 5 +
drivers/gpu/drm/tegra/drm.h | 1 +
drivers/gpu/drm/tegra/gem.c | 12 ++--
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 1d7be5ea97ee..d2ec16332fe0 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -144,6 +144,7 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
DRM_DEBUG_DRIVER("IOMMU aperture initialized (%#llx-%#llx)\n",
start, end);
drm_mm_init(&tegra->mm, start, end - start + 1);
+ mutex_init(&tegra->mm_lock);
}
mutex_init(&tegra->clients_lock);
@@ -210,6 +211,7 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
if (tegra->domain) {
iommu_domain_free(tegra->domain);
drm_mm_takedown(&tegra->mm);
+ mutex_destroy(&tegra->mm_lock);
}
free:
kfree(tegra);
@@ -234,6 +236,7 @@ static void tegra_drm_unload(struct drm_device *drm)
if (tegra->domain) {
iommu_domain_free(tegra->domain);
drm_mm_takedown(&tegra->mm);
+ mutex_destroy(&tegra->mm_lock);
}
kfree(tegra);
@@ -910,7 +913,9 @@ static int tegra_debugfs_iova(struct seq_file *s, void
*data)
struct tegra_drm *tegra = drm->dev_private;
struct drm_printer p = drm_seq_file_printer(s);
+ mutex_lock(&tegra->mm_lock);
drm_mm_print(&tegra->mm, &p);
+ mutex_unlock(&tegra->mm_lock);
return 0;
}
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index eda0d690faad..fe2db2afdca6 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -42,6 +42,7 @@ struct tegra_drm {
struct drm_device *drm;
struct iommu_domain *domain;
+ struct mutex mm_lock;
struct drm_mm mm;
struct mutex clients_lock;
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index e9f664990859..94470112ed1f 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -128,12 +128,14 @@ static int tegra_bo_iommu_map(struct tegra_drm *tegra,
struct tegra_bo *bo)
if (!bo->mm)
return -ENOMEM;
+ mutex_lock(&tegra->mm_lock);
+
err = drm_mm_insert_node_generic(&tegra->mm,
bo->mm, bo->gem.size, PAGE_SIZE, 0, 0);
if (err < 0) {
dev_err(tegra->drm->dev, "out of I/O virtual memory: %zd\n",
err);
- goto free;
+ goto unlock;
}
bo->paddr = bo->mm->start;
@@ -147,11 +149,14 @@ static int tegra_bo_iommu_map(struct tegra_drm *tegra,
struct tegra_bo *bo)
bo->size = err;
+ mutex_unlock(&tegra->mm_lock);
+
return 0;
remove:
drm_mm_remove_node(bo->mm);
-free:
+unlock:
+ mutex_unlock(&tegra->mm_lock);
kfree(bo->mm);
return err;
}
@@ -161,8 +166,11 @@ static int tegra_bo_iommu_unmap(struct tegra_drm *tegra,
struct tegra_bo *bo)
if (!bo->mm)
return 0;
+ mutex_lock(&tegra->mm_lock);
iommu_unmap(tegra->domain, bo->paddr, bo->size);
drm_mm_remove_node(bo->mm);
+ mutex_unlock(&tegra->mm_lock);
+
kfree(bo->mm);
return 0;
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/tegra: Don't leak kernel pointer to userspace
From: Thierry Reding
Each open file descriptor can have any number of contexts associated
with it. To differentiate between these contexts a unique ID is required
and back when these userspace interfaces were introduced, in commit
d43f81cbaf43 ("drm/tegra: Add gr2d device"), the pointer to the context
structure was deemed adequate. However, this leaks information about
kernel internal memory to userspace, which can potentially be exploited.
Switch the context parameter to be allocated from an IDR, which has the
added benefit of providing an easy way to look up a context from its ID.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 160 +++-
drivers/gpu/drm/tegra/drm.h | 2 +-
2 files changed, 114 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 72a5b1e7d2d2..1d7be5ea97ee 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
@@ -24,7 +25,8 @@
#define DRIVER_PATCHLEVEL 0
struct tegra_drm_file {
- struct list_head contexts;
+ struct idr contexts;
+ struct mutex lock;
};
static void tegra_atomic_schedule(struct tegra_drm *tegra,
@@ -245,7 +247,8 @@ static int tegra_drm_open(struct drm_device *drm, struct
drm_file *filp)
if (!fpriv)
return -ENOMEM;
- INIT_LIST_HEAD(&fpriv->contexts);
+ idr_init(&fpriv->contexts);
+ mutex_init(&fpriv->lock);
filp->driver_priv = fpriv;
return 0;
@@ -424,21 +427,16 @@ int tegra_drm_submit(struct tegra_drm_context *context,
#ifdef CONFIG_DRM_TEGRA_STAGING
-static struct tegra_drm_context *tegra_drm_get_context(__u64 context)
+static struct tegra_drm_context *
+tegra_drm_file_get_context(struct tegra_drm_file *file, u32 id)
{
- return (struct tegra_drm_context *)(uintptr_t)context;
-}
-
-static bool tegra_drm_file_owns_context(struct tegra_drm_file *file,
- struct tegra_drm_context *context)
-{
- struct tegra_drm_context *ctx;
+ struct tegra_drm_context *context;
- list_for_each_entry(ctx, &file->contexts, list)
- if (ctx == context)
- return true;
+ mutex_lock(&file->lock);
+ context = idr_find(&file->contexts, id);
+ mutex_unlock(&file->lock);
- return false;
+ return context;
}
static int tegra_gem_create(struct drm_device *drm, void *data,
@@ -519,6 +517,28 @@ static int tegra_syncpt_wait(struct drm_device *drm, void
*data,
&args->value);
}
+static int tegra_client_open(struct tegra_drm_file *fpriv,
+struct tegra_drm_client *client,
+struct tegra_drm_context *context)
+{
+ int err;
+
+ err = client->ops->open_channel(client, context);
+ if (err < 0)
+ return err;
+
+ err = idr_alloc(&fpriv->contexts, context, 0, 0, GFP_KERNEL);
+ if (err < 0) {
+ client->ops->close_channel(context);
+ return err;
+ }
+
+ context->client = client;
+ context->id = err;
+
+ return 0;
+}
+
static int tegra_open_channel(struct drm_device *drm, void *data,
struct drm_file *file)
{
@@ -533,19 +553,22 @@ static int tegra_open_channel(struct drm_device *drm,
void *data,
if (!context)
return -ENOMEM;
+ mutex_lock(&fpriv->lock);
+
list_for_each_entry(client, &tegra->clients, list)
if (client->base.class == args->client) {
- err = client->ops->open_channel(client, context);
- if (err)
+ err = tegra_client_open(fpriv, client, context);
+ if (err < 0)
break;
- list_add(&context->list, &fpriv->contexts);
- args->context = (uintptr_t)context;
- context->client = client;
- return 0;
+ args->context = context->id;
+ break;
}
- kfree(context);
+ if (err < 0)
+ kfree(context);
+
+ mutex_unlock(&fpriv->lock);
return err;
}
@@ -555,16 +578,22 @@ static int tegra_close_channel(struct drm_device *drm,
void *data,
struct tegra_drm_file *fpriv = file->driver_priv;
struct drm_tegra_close_channel *args = data;
struct tegra_drm_context *context;
+ int err = 0;
- context = tegra_drm_get_context(args->context);
+ mutex_lock(&fpriv->lock);
- if (!tegra_drm_file_owns_context(fpriv, context))
- return -EINVAL;
+ context = tegra_drm_file_get_context(fpriv, args->context);
+ if (!context) {
+ err = -EINVAL;
+
[PATCH 3/3] gpu: host1x: Fix potential out-of-bounds access
From: Thierry Reding
The check for valid syncpoint IDs is off by one. While at it, rewrite
the check to make it more easily understandable.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/syncpt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index 25c11a85050b..0ac026cdc30c 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -484,7 +484,7 @@ unsigned int host1x_syncpt_nb_mlocks(struct host1x *host)
struct host1x_syncpt *host1x_syncpt_get(struct host1x *host, unsigned int id)
{
- if (host->info->nb_pts < id)
+ if (id >= host->info->nb_pts)
return NULL;
return host->syncpt + id;
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100141] [AMDGPU][CIK][4.10/4.11-rc1] Regression - Hibernation does not respect 'reboot' option in /sys/power/disk
https://bugs.freedesktop.org/show_bug.cgi?id=100141 Bug ID: 100141 Summary: [AMDGPU][CIK][4.10/4.11-rc1] Regression - Hibernation does not respect 'reboot' option in /sys/power/disk Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: shawn.st...@rogers.com AMDGPU used to respect rebooting after hibernation, now when you specify this, it performs writing pages to disk then freezes. If I perform a hard power off then back on, hibernation will resume correctly. Please test for 'reboot' when using /sys/power/disk -- 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] amdgpu drm-fixes-4.11
Hi Dave, A few fixes for 4.11. The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.11 for you to fetch changes up to a5b11dac1f57c4b327c2d6eccb8fdd01499f9e17: drm/amdgpu: bump driver version for some new features (2017-03-09 16:35:16 -0500) Alex Deucher (2): drm/amdgpu: validate paramaters in the gem ioctl drm/amdgpu: bump driver version for some new features Jim Qu (1): drm/amd/amdgpu: fix console deadlock if late init failed drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 - drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 21 + 3 files changed, 27 insertions(+), 2 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Forward declare struct platform_device
./include/drm/drm_pci.h:76:64: warning: ‘struct platform_device’ declared
inside parameter list will not be visible outside of this definition or
declaration
extern int drm_platform_init(struct drm_driver *driver, struct platform_device
*platform_device);
Fixes: 23ef59ef6dcc ("drm: Extract drm_pci.h")
Signed-off-by: Chris Wilson
Cc: Gustavo Padovan
Cc: Daniel Vetter
---
include/drm/drm_pci.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_pci.h b/include/drm/drm_pci.h
index 5081b3eba309..9cd2173fc892 100644
--- a/include/drm/drm_pci.h
+++ b/include/drm/drm_pci.h
@@ -73,6 +73,8 @@ extern int drm_pcie_get_speed_cap_mask(struct drm_device
*dev, u32 *speed_mask);
extern int drm_pcie_get_max_link_width(struct drm_device *dev, u32 *mlw);
/* platform section */
-extern int drm_platform_init(struct drm_driver *driver, struct platform_device
*platform_device);
+struct platform_device;
+extern int drm_platform_init(struct drm_driver *driver,
+struct platform_device *platform_device);
#endif /* _DRM_PCI_H_ */
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Shared semaphores for amdgpu
> Completely agree, problem here is that this isn't documented like this in > the Vulkan specification as far as I know. (I'm adding dri-devel, since I think Intel folks have looked into some of this already, and we might need to make some common functionality). "The semaphore must be signaled, or have an associated semaphore signal operation that is pending execution." So I'll try and summarise the semantics of semaphores vs current fence fds. For shared semaphores there are two defined semantics: temporary and permanent, I think we would need to support both. temporary align with fence fd, but permanent not so much. The main difference I see if that fence's are a one shot thing, you create a fence when you submit it and then you give it to someone else to wait on it. Semaphores are a create once, share once, use multiple times. The semantics for permanaent semaphore sharing is: process AB allocate export import signal wait signal wait and so on. The way we currently to semaphores is to insert a fence into the semaphore on signal, and block waiting for that fence on wait, then insert a new one on the next signal. This means we don't want to constantly reshared the fence_fd. (The temporary semaphores sharing semantics match this behaviour). This leaves me to believe that fence fd's can't be used for this task as-is. Now the question is if we can extend them, and how we do that in a useful and backwards compatible manner. How would we do this, allow dma_fence to be "updated" from another dma_fence, so we have some sort of dma_fence variant that has a permanent lifetime, that we can on signal update from another fence to match it's behaviour, then on wait works on the updated info. Do we just want a wrapper around a fence then, which is pretty much what the proposed sem code is. or do we want some way to link a bunch of fences together? What we don't want is to expose to userspace anything that requires us to reshare the fence via the fd again after the initial setup. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99195] Random GPU lockup on Fedora 25 Wayland & X sessions with Mobility Radeon HD 5650/5750 Opensource drivers
https://bugs.freedesktop.org/show_bug.cgi?id=99195 --- Comment #8 from Tim --- Ok, i tried this on Debian Stretch development branch, and have no hangs. Tested even in heavy video games. Debian have 13.0.5 version of mesa. But Chromium with enabled hardware acceleration still hangs whole system after 5 min. -- 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
linux-next: build warning after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from drivers/gpu/drm/drm_pci.c:29:0:
include/drm/drm_pci.h:76:64: warning: 'struct platform_device' declared inside
parameter list
extern int drm_platform_init(struct drm_driver *driver, struct platform_device
*platform_device);
^
include/drm/drm_pci.h:76:64: warning: its scope is only this definition or
declaration, which is probably not what you want
Introduced by commit
23ef59ef6dcc ("drm: Extract drm_pci.h")
A forgotten include file (or maybe just a forward declaration of the struct).
--
Cheers,
Stephen Rothwell
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/11] drm/sun4i: Pass pointer for underlying backend into layer init
sun4i_layer only controls the backend hardware block of the display
pipeline.
Pass pointers to the underlying backend in the layer init function,
instead of trying to fetch it from the drm_device structure. This
avoids the headache of trying to figure out which device the layers
actually belong to.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_layer.c | 13 ++---
drivers/gpu/drm/sun4i/sun4i_layer.h | 3 ++-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 221e6d5ee970..3c876c3a356a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -149,7 +149,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
scrtc->tcon = tcon;
/* Create our layers */
- scrtc->layers = sun4i_layers_init(drm);
+ scrtc->layers = sun4i_layers_init(drm, scrtc->backend);
if (IS_ERR(scrtc->layers)) {
dev_err(drm->dev, "Couldn't create the planes\n");
return NULL;
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 6feaf85a5942..f26bde5b9117 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -16,7 +16,6 @@
#include
#include "sun4i_backend.h"
-#include "sun4i_drv.h"
#include "sun4i_layer.h"
struct sun4i_plane_desc {
@@ -102,9 +101,9 @@ static const struct sun4i_plane_desc sun4i_backend_planes[]
= {
};
static struct sun4i_layer *sun4i_layer_init_one(struct drm_device *drm,
+ struct sun4i_backend *backend,
const struct sun4i_plane_desc
*plane)
{
- struct sun4i_drv *drv = drm->dev_private;
struct sun4i_layer *layer;
int ret;
@@ -124,14 +123,14 @@ static struct sun4i_layer *sun4i_layer_init_one(struct
drm_device *drm,
drm_plane_helper_add(&layer->plane,
&sun4i_backend_layer_helper_funcs);
- layer->backend = drv->backend;
+ layer->backend = backend;
return layer;
}
-struct sun4i_layer **sun4i_layers_init(struct drm_device *drm)
+struct sun4i_layer **sun4i_layers_init(struct drm_device *drm,
+ struct sun4i_backend *backend)
{
- struct sun4i_drv *drv = drm->dev_private;
struct sun4i_layer **layers;
int i;
@@ -165,7 +164,7 @@ struct sun4i_layer **sun4i_layers_init(struct drm_device
*drm)
const struct sun4i_plane_desc *plane = &sun4i_backend_planes[i];
struct sun4i_layer *layer;
- layer = sun4i_layer_init_one(drm, plane);
+ layer = sun4i_layer_init_one(drm, backend, plane);
if (IS_ERR(layer)) {
dev_err(drm->dev, "Couldn't initialize %s plane\n",
i ? "overlay" : "primary");
@@ -174,7 +173,7 @@ struct sun4i_layer **sun4i_layers_init(struct drm_device
*drm)
DRM_DEBUG_DRIVER("Assigning %s plane to pipe %d\n",
i ? "overlay" : "primary", plane->pipe);
- regmap_update_bits(drv->backend->regs,
SUN4I_BACKEND_ATTCTL_REG0(i),
+ regmap_update_bits(backend->regs, SUN4I_BACKEND_ATTCTL_REG0(i),
SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK,
SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(plane->pipe));
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.h
b/drivers/gpu/drm/sun4i/sun4i_layer.h
index a97e376bae17..4be1f0919df2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.h
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.h
@@ -26,6 +26,7 @@ plane_to_sun4i_layer(struct drm_plane *plane)
return container_of(plane, struct sun4i_layer, plane);
}
-struct sun4i_layer **sun4i_layers_init(struct drm_device *drm);
+struct sun4i_layer **sun4i_layers_init(struct drm_device *drm,
+ struct sun4i_backend *backend);
#endif /* _SUN4I_LAYER_H_ */
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/11] drm/sun4i: Fetch TCON ID from device tree
Some Allwinner SoCs have 2 display pipelines, as in 2 of each
components, including the frontend, backend, TCON, and any other
extras.
As the backend and TCON are always paired together and form the CRTC,
we need to know which backend or TCON we are currently probing, so we
can pair them when initializing the CRTC.
This patch figures out the TCON's ID from the device tree and stores
it in the TCON's data structure. It does this by looking at the "reg"
property of any remote endpoints connected to the TCON's output port,
except LCD panels or external bridges on the RGB interface.
If none are found, it assumes the system only has 1 TCON.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 60 ++
drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 ++
2 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 3ced0b1cef6e..b774c9a50c55 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -471,6 +471,55 @@ struct drm_bridge *sun4i_tcon_find_bridge(struct
device_node *node)
return of_drm_find_bridge(remote) ?: ERR_PTR(-EPROBE_DEFER);
}
+/*
+ * The tcon can output video to an tv or hdmi encoder. When there are 2
+ * tcons, on older SoCs with DE 1.0, either tcon can be muxed to the
+ * encoder.
+ *
+ * This relationship within the display pipeline is encoded in the device
+ * tree with of_graph. Here we use it to figure out which tcon, if there
+ * are 2 or more, we are currently probing. The number would be in the
+ * "reg" property of the downstream input port endpoint.
+ */
+static int sun4i_tcon_of_get_id(struct device_node *node)
+{
+ struct device_node *port, *ep;
+ int ret = -EINVAL;
+
+ /* output is port 1 */
+ port = of_graph_get_port_by_id(node, 1);
+ if (!port)
+ return -EINVAL;
+
+ /* try finding a downstream endpoint */
+ for_each_available_child_of_node(port, ep) {
+ struct device_node *remote;
+ u32 reg;
+
+ ret = of_property_read_u32(ep, "reg", ®);
+ if (ret)
+ continue;
+
+ /* Skip endpoint 0, the LCD panel interface */
+ if (!reg)
+ continue;
+
+ remote = of_parse_phandle(ep, "remote-endpoint", 0);
+ if (!remote)
+ continue;
+
+ ret = of_property_read_u32(remote, "reg", ®);
+ if (ret)
+ continue;
+
+ ret = reg;
+ }
+
+ of_node_put(port);
+
+ return ret;
+}
+
static int sun4i_tcon_bind(struct device *dev, struct device *master,
void *data)
{
@@ -488,6 +537,17 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
tcon->dev = dev;
tcon->quirks = of_device_get_match_data(dev);
+ /* This can fail if the DT does not have any downstream encoders. */
+ tcon->id = sun4i_tcon_of_get_id(dev->of_node);
+ if (tcon->id < 0) {
+ /*
+* TODO We currently support only 1 TCON, so we can
+* safely set this to 0. This should be revisited
+* when we add support for multiple pipelines.
+*/
+ tcon->id = 0;
+ }
+
tcon->lcd_rst = devm_reset_control_get(dev, "lcd");
if (IS_ERR(tcon->lcd_rst)) {
dev_err(dev, "Couldn't get our reset line\n");
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index f636343a935d..28b8da1e6c18 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -172,6 +172,8 @@ struct sun4i_tcon {
/* Associated crtc */
struct sun4i_crtc *crtc;
+
+ int id;
};
struct drm_bridge *sun4i_tcon_find_bridge(struct device_node *node);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] Fix DP busy wait and defer disabling overlay plane
Thanks for your tips and links Philipp and Russell! My distro of choice is Arch and so really I should try to install the patched git kernel "the Arch way" so my first question is, does anyone on this list have an Arch PKGBUILD script to create a linux (4.x) git kernel package for imx6 alikes? If the answer to that is no then I think I'm most of the way to having created one based upon https://aur.archlinux.org/packages/linux-git/ but I'm missing a suitable kernel .config file. I tried putting make imx_v6_v7_defconfig Into the PKGBUILD but that didn't work out and the ALARM imx6 kernel config is for kernel 3.14 so I can't use that either. Thanks On Mon, Mar 6, 2017 at 4:29 PM, Russell King - ARM Linux wrote: > On Mon, Mar 06, 2017 at 02:50:58PM +0100, Philipp Zabel wrote: >> Sorry, I should have mentioned that this must be called from inside an >> existing kernel git repository. The idea is that you don't have to clone >> the whole kernel through our pipe, but can use the upstream repository, >> which has a much better internet connection, for most of the data: >> >> git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> cd linux >> git fetch https://git.pengutronix.de/git/pza/linux.git >> tags/v4.10-ipu-dp-plane-fix >> git checkout -b "branchname" FETCH_HEAD > > If you have an existing tree which is based on Linus' tree, you can save > the server and download bandwidth by doing: > > git clone --dissociate --reference /path/to/local/copy/of/linus/tree > https://git.pengutronix.de/git/pza/linux.git > cd linux > git checkout tags/v4.10-ipu-dp-plane-fix > > This will clone your tree, but make use of the objects already present > in /path/to/local/copy/of/linus/tree, making copies of them (so it > doesn't matter if you subsequently get rid of that reference tree.) > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/11] drm/sun4i: Fix TCON clock and regmap initialization sequence
The TCON driver calls sun4i_tcon_init_regmap and sun4i_tcon_init_clocks
in its bind function. The former creates a regmap and writes to several
register to clear its configuration to a known default. The latter
initializes various clocks. This includes enabling the bus clock for
register access and creating the dotclock.
In order for the first step's writes to work, the bus clock must be
enabled which is done in the second step. but the dotclock's ops use
the regmap created in the first step.
Rearrange the function calls such that the clocks are initialized before
the regmap, and split out the dot clock creation to after the regmap is
initialized.
Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 505520baa585..ee51d7e77a6a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -335,12 +335,11 @@ static int sun4i_tcon_init_clocks(struct device *dev,
}
}
- return sun4i_dclk_create(dev, tcon);
+ return 0;
}
static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
{
- sun4i_dclk_free(tcon);
clk_disable_unprepare(tcon->clk);
}
@@ -505,22 +504,28 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
return ret;
}
+ ret = sun4i_tcon_init_clocks(dev, tcon);
+ if (ret) {
+ dev_err(dev, "Couldn't init our TCON clocks\n");
+ goto err_assert_reset;
+ }
+
ret = sun4i_tcon_init_regmap(dev, tcon);
if (ret) {
dev_err(dev, "Couldn't init our TCON regmap\n");
- goto err_assert_reset;
+ goto err_free_clocks;
}
- ret = sun4i_tcon_init_clocks(dev, tcon);
+ ret = sun4i_dclk_create(dev, tcon);
if (ret) {
- dev_err(dev, "Couldn't init our TCON clocks\n");
- goto err_assert_reset;
+ dev_err(dev, "Couldn't create our TCON dot clock\n");
+ goto err_free_clocks;
}
ret = sun4i_tcon_init_irq(dev, tcon);
if (ret) {
dev_err(dev, "Couldn't init our TCON interrupts\n");
- goto err_free_clocks;
+ goto err_free_dotclock;
}
tcon->crtc = sun4i_crtc_init(drm);
@@ -536,6 +541,8 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
return 0;
+err_free_dotclock:
+ sun4i_dclk_free(tcon);
err_free_clocks:
sun4i_tcon_free_clocks(tcon);
err_assert_reset:
@@ -548,6 +555,7 @@ static void sun4i_tcon_unbind(struct device *dev, struct
device *master,
{
struct sun4i_tcon *tcon = dev_get_drvdata(dev);
+ sun4i_dclk_free(tcon);
sun4i_tcon_free_clocks(tcon);
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/11] drm/sun4i: Support two display pipelines
Some Allwinner SoCs have two display pipelines (frontend -> backend ->
tcon).
Previously we only supported one pipeline. This patch extends the
current driver to support two. It extends the tcon and backend pointers
in sun4i_drv into arrays, and makes the related bind functions store
the pointer into said arrays based on the id fetched from the device
tree. In the case of the tcons, it falls back to a first come order
if no encoders that can be used for differentiating the tcons are
defined. The driver's depth-first traversal of the of graph, coupled
with the increasing address ordering of the of graph endpoints, and
the fact that tcon0 should always be enabled for the tcon/encoder
mux to be accessible, means that tcon1 would always come after tcon0.
Assignment of the device structure into sun4i_drv is moved to the end
of the bind function, when all possible error checks have passed.
This patch also drops a trailing 0 in one of the backend probe messages.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 9 +++--
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_drv.h | 6 --
drivers/gpu/drm/sun4i/sun4i_tcon.c| 25 +
4 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index f3c92d54c8e4..8d22efd5a9cc 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -350,12 +350,15 @@ static int sun4i_backend_bind(struct device *dev, struct
device *master,
if (!backend)
return -ENOMEM;
dev_set_drvdata(dev, backend);
- drv->backend = backend;
backend->id = sun4i_backend_of_get_id(dev->of_node);
if (backend->id < 0)
return backend->id;
+ /* We only support SUN4I_DRM_MAX_PIPELINES number of backends */
+ if (backend->id >= SUN4I_DRM_MAX_PIPELINES)
+ return -EINVAL;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev, res);
if (IS_ERR(regs))
@@ -364,7 +367,7 @@ static int sun4i_backend_bind(struct device *dev, struct
device *master,
backend->regs = devm_regmap_init_mmio(dev, regs,
&sun4i_backend_regmap_config);
if (IS_ERR(backend->regs)) {
- dev_err(dev, "Couldn't create the backend0 regmap\n");
+ dev_err(dev, "Couldn't create the backend regmap\n");
return PTR_ERR(backend->regs);
}
@@ -413,6 +416,8 @@ static int sun4i_backend_bind(struct device *dev, struct
device *master,
}
}
+ drv->backend[backend->id] = backend;
+
/* Reset the registers */
for (i = 0x800; i < 0x1000; i += 4)
regmap_write(backend->regs, i, 0);
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 767bbadcc85d..c15ecb8343d7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -271,7 +271,7 @@ static int sun4i_drv_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
int i, count = 0;
- for (i = 0;; i++) {
+ for (i = 0; i < SUN4I_DRM_MAX_PIPELINES; i++) {
struct device_node *pipeline = of_parse_phandle(np,
"allwinner,pipelines",
i);
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h
b/drivers/gpu/drm/sun4i/sun4i_drv.h
index 5df50126ff52..ec1c08af47e1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.h
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
@@ -16,9 +16,11 @@
#include
#include
+#define SUN4I_DRM_MAX_PIPELINES2
+
struct sun4i_drv {
- struct sun4i_backend*backend;
- struct sun4i_tcon *tcon;
+ struct sun4i_backend*backend[SUN4I_DRM_MAX_PIPELINES];
+ struct sun4i_tcon *tcon[SUN4I_DRM_MAX_PIPELINES];
struct drm_fbdev_cma*fbdev;
};
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index b774c9a50c55..7749c3133f38 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -532,7 +532,6 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
if (!tcon)
return -ENOMEM;
dev_set_drvdata(dev, tcon);
- drv->tcon = tcon;
tcon->drm = drm;
tcon->dev = dev;
tcon->quirks = of_device_get_match_data(dev);
@@ -540,14 +539,22 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
/* This can fail if the DT does not have any downstream encoders. */
tcon->id = sun4i_tcon_of_get_id(dev->of_node);
if (tcon->id < 0) {
- /*
-* TODO We currently support only 1
[PATCH 05/11] drm/sun4i: Pass pointers for associated backend and tcon into crtc init
sun4i_crtc controls the backend and tcon hardware blocks of the display
pipeline.
Pass pointers to the underlying devices into the crtc init function,
instead of trying to fetch them from the drm_device structure. This
avoids the headache of trying to figure out which devices the crtc
is actually associated with.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 9 +
drivers/gpu/drm/sun4i/sun4i_crtc.h | 4 +++-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 2 +-
3 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
b/drivers/gpu/drm/sun4i/sun4i_crtc.c
index 5323e3485988..221e6d5ee970 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
@@ -134,9 +134,10 @@ static const struct drm_crtc_funcs sun4i_crtc_funcs = {
.disable_vblank = sun4i_crtc_disable_vblank,
};
-struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm)
+struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
+ struct sun4i_backend *backend,
+ struct sun4i_tcon *tcon)
{
- struct sun4i_drv *drv = drm->dev_private;
struct sun4i_crtc *scrtc;
struct drm_plane *primary = NULL, *cursor = NULL;
int ret, i;
@@ -144,8 +145,8 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm)
scrtc = devm_kzalloc(drm->dev, sizeof(*scrtc), GFP_KERNEL);
if (!scrtc)
return ERR_PTR(-ENOMEM);
- scrtc->backend = drv->backend;
- scrtc->tcon = drv->tcon;
+ scrtc->backend = backend;
+ scrtc->tcon = tcon;
/* Create our layers */
scrtc->layers = sun4i_layers_init(drm);
diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.h
b/drivers/gpu/drm/sun4i/sun4i_crtc.h
index cd0e633cce3a..230cb8f0d601 100644
--- a/drivers/gpu/drm/sun4i/sun4i_crtc.h
+++ b/drivers/gpu/drm/sun4i/sun4i_crtc.h
@@ -27,6 +27,8 @@ static inline struct sun4i_crtc
*drm_crtc_to_sun4i_crtc(struct drm_crtc *crtc)
return container_of(crtc, struct sun4i_crtc, crtc);
}
-struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm);
+struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
+ struct sun4i_backend *backend,
+ struct sun4i_tcon *tcon);
#endif /* _SUN4I_CRTC_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c52c482c8fd0..3ced0b1cef6e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -528,7 +528,7 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
goto err_free_dotclock;
}
- tcon->crtc = sun4i_crtc_init(drm);
+ tcon->crtc = sun4i_crtc_init(drm, drv->backend, tcon);
if (IS_ERR(tcon->crtc)) {
dev_err(dev, "Couldn't create our CRTC\n");
ret = PTR_ERR(tcon->crtc);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/11] ARM: dts: sun6i: Enable tcon0 by default
tcon0 contains a muxing register used to mux tcon output to downstream
hdmi or mipi dsi encoders. tcon0 must be available for the mux to be
configured.
Whether the display subsystem is enabled or not is now solely controlled
by the display-engine node.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 1 -
arch/arm/boot/dts/sun6i-a31.dtsi| 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index f094eeb6c499..fb237ce60198 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -320,7 +320,6 @@
&tcon0 {
pinctrl-names = "default";
pinctrl-0 = <&lcd0_rgb888_pins>;
- status = "okay";
};
&tcon0_out {
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 40f020824ccc..0ddcffab594e 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -265,7 +265,6 @@
"tcon-ch0",
"tcon-ch1";
clock-output-names = "tcon0-pixel-clock";
- status = "disabled";
ports {
#address-cells = <1>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/11] drm/sun4i: tv: Get tcon and backend pointers from associated crtc
The drm_encoder structure provides us with a pointer to the crtc
currently tied to the encoder. Subsequently we can extract the
tcon and backend pointers from our crtc structure, instead of
getting it directly from the sun4i_drv structure.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index 32ed5fdf0c4d..49c49431a053 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
@@ -23,6 +23,7 @@
#include
#include "sun4i_backend.h"
+#include "sun4i_crtc.h"
#include "sun4i_drv.h"
#include "sun4i_tcon.h"
@@ -350,8 +351,9 @@ static int sun4i_tv_atomic_check(struct drm_encoder
*encoder,
static void sun4i_tv_disable(struct drm_encoder *encoder)
{
struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
- struct sun4i_drv *drv = tv->drv;
- struct sun4i_tcon *tcon = drv->tcon;
+ struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
+ struct sun4i_tcon *tcon = crtc->tcon;
+ struct sun4i_backend *backend = crtc->backend;
DRM_DEBUG_DRIVER("Disabling the TV Output\n");
@@ -360,18 +362,19 @@ static void sun4i_tv_disable(struct drm_encoder *encoder)
regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
SUN4I_TVE_EN_ENABLE,
0);
- sun4i_backend_disable_color_correction(drv->backend);
+ sun4i_backend_disable_color_correction(backend);
}
static void sun4i_tv_enable(struct drm_encoder *encoder)
{
struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
- struct sun4i_drv *drv = tv->drv;
- struct sun4i_tcon *tcon = drv->tcon;
+ struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
+ struct sun4i_tcon *tcon = crtc->tcon;
+ struct sun4i_backend *backend = crtc->backend;
DRM_DEBUG_DRIVER("Enabling the TV Output\n");
- sun4i_backend_apply_color_correction(drv->backend);
+ sun4i_backend_apply_color_correction(backend);
regmap_update_bits(tv->regs, SUN4I_TVE_EN_REG,
SUN4I_TVE_EN_ENABLE,
@@ -385,8 +388,8 @@ static void sun4i_tv_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
{
struct sun4i_tv *tv = drm_encoder_to_sun4i_tv(encoder);
- struct sun4i_drv *drv = tv->drv;
- struct sun4i_tcon *tcon = drv->tcon;
+ struct sun4i_crtc *crtc = drm_crtc_to_sun4i_crtc(encoder->crtc);
+ struct sun4i_tcon *tcon = crtc->tcon;
const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
sun4i_tcon1_mode_set(tcon, mode);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD
On Wed, Mar 08, 2017 at 09:15:24AM +0100, Romain Perier wrote: > - dw_hdmi_update_power() will be called. As hdmi->force will be equal to > DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. This > field has not been updated by the irq handler, so it will be false and > DRM_FORCE_ON won't be put to hdmi->force. Right, and wrong. Your initial part is correct, but the latter sentence is incorrect - we only ever update hdmi->force according to the user's force requests, never as a result of the current state of the driver. hdmi->force exists to allow the user to say "I want to force this connector to always report disconnected or connected" to work around stupid monitors that pulse everything from HPD to RXSENSE when in standby mode. > This commit fixes the issue by removing the check for "!hdmi->disabled". > As already explained, even if the PHY is partially disabled, information > coming from HDMI Transmitter about HPD should be saved for a later use. Your fix looks fine to me, as both dw_hdmi_update_power() and dw_hdmi_update_phy_mask() effectively ignore attempts to update the state while hdmi->disabled is true. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD
Hi Romain,
On 08-03-2017 08:15, Romain Perier wrote:
> Currently, the irq handler that monitores changes for HPD anx RX_SENSE
> relies on the status of the bridge for updating the status of the HPD.
> The update is done only when the bridge is enabled.
>
> However, on Rockchip platforms we have found use cases where it could be
> a problem. When HDMI is being used, turning off/on the screen or
> unplugging/re-plugging the cable, the following simplified code path
> will happen:
>
> - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is on
> hdmi->disabled is false, then the handler will update the rxsense flag
> accordingly.
> - dw_hdmi_update_power() will be invoked with the mode
> DRM_FORCE_UNSPECIFIED and rxsense == 1, so dw_hdmi_poweroff() will be
> called and the PHY will be desactivated (its pixel clocks and TMDS)
>
> [...]
>
> - dw_hdmi_bridge_disable() will be invoked, the bridge will be marked as
> disabled.
>
> - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is
> currently disabled the HPD status won't be updated, so hdmi->rxsense
> won't be changed. Even if the data part of the PHY is disabled, this
> information coming from the HDMI Transmitter is correct and should be
> saved.
>
> [...]
>
> - dw_hdmi_bridge_enable() will be invoked, the bridge will be marked as
> enabled.
> - dw_hdmi_update_power() will be called. As hdmi->force will be equal to
> DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. This
> field has not been updated by the irq handler, so it will be false and
> DRM_FORCE_ON won't be put to hdmi->force.
>
> Consequently, most of the time dw_hdmi_poweron() won't be called in this
> use case, TMDS won't be re-enabled the PHY won't be re-initialized,
> resulting in a "Signal not found".
>
> This commit fixes the issue by removing the check for "!hdmi->disabled".
> As already explained, even if the PHY is partially disabled, information
> coming from HDMI Transmitter about HPD should be saved for a later use.
>
> Signed-off-by: Romain Perier
> ---
>
> Note: Due to an email configuration issue, some of my patches were not
> received on infradead.org or vger.kernel.org. It is now fixed, so I
> resend this patch for this reason.
>
> drivers/gpu/drm/bridge/dw-hdmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> b/drivers/gpu/drm/bridge/dw-hdmi.c
> index 235ce7d..b621fc7 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> @@ -1790,7 +1790,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> if (intr_stat &
> (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
> mutex_lock(&hdmi->mutex);
> - if (!hdmi->disabled && !hdmi->force) {
> + if (!hdmi->force) {
> /*
>* If the RX sense status indicates we're disconnected,
>* clear the software rxsense status.
Makes sense but I think you need to make sure that phy will not
be enabled when bridge is disabled i.e. you should update rxsense
only.
Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/11] ARM: dts: sun6i: Add second display pipeline device nodes
The Allwinner A31/A31s SoCs have 2 display pipelines, as in 2 display
frontends, backends, and tcons each. The relationship between the
backends and tcons are 1:1, but the frontends can feed either backend.
Add device nodes and of graph nodes describing this relationship.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31.dtsi | 168 ++-
1 file changed, 167 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index a4b96184cac1..40f020824ccc 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -233,7 +233,7 @@
de: display-engine {
compatible = "allwinner,sun6i-a31-display-engine";
- allwinner,pipelines = <&fe0>;
+ allwinner,pipelines = <&fe0>, <&fe1>;
status = "disabled";
};
@@ -290,6 +290,43 @@
};
};
+ tcon1: lcd-controller@01c0d000 {
+ compatible = "allwinner,sun6i-a31-tcon";
+ reg = <0x01c0d000 0x1000>;
+ interrupts = ;
+ resets = <&ccu RST_AHB1_LCD1>;
+ reset-names = "lcd";
+ clocks = <&ccu CLK_AHB1_LCD1>,
+<&ccu CLK_LCD1_CH0>,
+<&ccu CLK_LCD1_CH1>;
+ clock-names = "ahb",
+ "tcon-ch0",
+ "tcon-ch1";
+ clock-output-names = "tcon1-pixel-clock";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon1_in_drc1: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&drc1_out_tcon1>;
+ };
+ };
+
+ tcon1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
@@ -897,6 +934,130 @@
reg = <0>;
remote-endpoint = <&be0_in_fe0>;
};
+
+ fe0_out_be1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&be1_in_fe0>;
+ };
+ };
+ };
+ };
+
+ fe1: display-frontend@01e2 {
+ compatible = "allwinner,sun6i-a31-display-frontend";
+ reg = <0x01e2 0x2>;
+ interrupts = ;
+ clocks = <&ccu CLK_AHB1_FE1>, <&ccu CLK_FE1>,
+<&ccu CLK_DRAM_FE1>;
+ clock-names = "ahb", "mod",
+ "ram";
+ resets = <&ccu RST_AHB1_FE1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ fe1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ fe1_out_be0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&be0_in_fe1>;
+ };
+
+ fe1_out_be1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&be1_in_fe1>;
+ };
+ };
+ };
+ };
+
+ be1: display-backend@01e4 {
+ compatible = "allwinner,sun6i-a31-display-backend";
+ reg = <0x01e4 0x1>;
+ interrupts = ;
+ clocks = <
Re: [PATCH RESEND] drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD
Hello,
Le 09/03/2017 à 15:28, Jose Abreu a écrit :
> Hi Romain,
>
>
> On 08-03-2017 08:15, Romain Perier wrote:
>> Currently, the irq handler that monitores changes for HPD anx RX_SENSE
>> relies on the status of the bridge for updating the status of the HPD.
>> The update is done only when the bridge is enabled.
>>
>> However, on Rockchip platforms we have found use cases where it could be
>> a problem. When HDMI is being used, turning off/on the screen or
>> unplugging/re-plugging the cable, the following simplified code path
>> will happen:
>>
>> - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is on
>> hdmi->disabled is false, then the handler will update the rxsense flag
>> accordingly.
>> - dw_hdmi_update_power() will be invoked with the mode
>> DRM_FORCE_UNSPECIFIED and rxsense == 1, so dw_hdmi_poweroff() will be
>> called and the PHY will be desactivated (its pixel clocks and TMDS)
>>
>> [...]
>>
>> - dw_hdmi_bridge_disable() will be invoked, the bridge will be marked as
>> disabled.
>>
>> - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is
>> currently disabled the HPD status won't be updated, so hdmi->rxsense
>> won't be changed. Even if the data part of the PHY is disabled, this
>> information coming from the HDMI Transmitter is correct and should be
>> saved.
>>
>> [...]
>>
>> - dw_hdmi_bridge_enable() will be invoked, the bridge will be marked as
>> enabled.
>> - dw_hdmi_update_power() will be called. As hdmi->force will be equal to
>> DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. This
>> field has not been updated by the irq handler, so it will be false and
>> DRM_FORCE_ON won't be put to hdmi->force.
>>
>> Consequently, most of the time dw_hdmi_poweron() won't be called in this
>> use case, TMDS won't be re-enabled the PHY won't be re-initialized,
>> resulting in a "Signal not found".
>>
>> This commit fixes the issue by removing the check for "!hdmi->disabled".
>> As already explained, even if the PHY is partially disabled, information
>> coming from HDMI Transmitter about HPD should be saved for a later use.
>>
>> Signed-off-by: Romain Perier
>> ---
>>
>> Note: Due to an email configuration issue, some of my patches were not
>> received on infradead.org or vger.kernel.org. It is now fixed, so I
>> resend this patch for this reason.
>>
>> drivers/gpu/drm/bridge/dw-hdmi.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/dw-hdmi.c
>> index 235ce7d..b621fc7 100644
>> --- a/drivers/gpu/drm/bridge/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
>> @@ -1790,7 +1790,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>> if (intr_stat &
>> (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
>> mutex_lock(&hdmi->mutex);
>> -if (!hdmi->disabled && !hdmi->force) {
>> +if (!hdmi->force) {
>> /*
>> * If the RX sense status indicates we're disconnected,
>> * clear the software rxsense status.
> Makes sense but I think you need to make sure that phy will not
> be enabled when bridge is disabled i.e. you should update rxsense
> only.
>
> Best regards,
> Jose Miguel Abreu
I agree with Russel, dw_hdmi_update_phy_mask already checks that. So it
should not be enabled, imho.
Regards,
Romain
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] phy: rockchip-typec: support DP phy switch
On Fri, Feb 10, 2017 at 03:44:13PM +0800, Chris Zhong wrote:
> There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence
> only one PHY can connect to DP controller at one time, the other should
> be disconnected. The GRF_SOC_CON26 register has a switch bit to do it,
> set this bit means enable PHY 1, clear this bit means enable PHY 0.
>
> Signed-off-by: Chris Zhong
> ---
>
> drivers/phy/phy-rockchip-typec.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/phy/phy-rockchip-typec.c
> b/drivers/phy/phy-rockchip-typec.c
> index 7cfb0f8..1604aaa 100644
> --- a/drivers/phy/phy-rockchip-typec.c
> +++ b/drivers/phy/phy-rockchip-typec.c
> @@ -267,6 +267,7 @@ struct rockchip_usb3phy_port_cfg {
> struct usb3phy_reg usb3tousb2_en;
> struct usb3phy_reg external_psm;
> struct usb3phy_reg pipe_status;
> + struct usb3phy_reg uphy_dp_sel;
> };
>
> struct rockchip_typec_phy {
> @@ -736,6 +737,7 @@ static const struct phy_ops rockchip_usb3_phy_ops = {
> static int rockchip_dp_phy_power_on(struct phy *phy)
> {
> struct rockchip_typec_phy *tcphy = phy_get_drvdata(phy);
> + struct rockchip_usb3phy_port_cfg *cfg = &tcphy->port_cfgs;
> int new_mode, ret = 0;
> u32 val;
>
> @@ -766,6 +768,8 @@ static int rockchip_dp_phy_power_on(struct phy *phy)
> tcphy_phy_init(tcphy, new_mode);
> }
>
> + property_enable(tcphy, &cfg->uphy_dp_sel, 1);
> +
> ret = readx_poll_timeout(readl, tcphy->base + DP_MODE_CTL,
Idea for future work: this should just be readl_poll_timeout() here, and
throughout the driver.
>val, val & DP_MODE_A2, 1000,
>PHY_MODE_SET_TIMEOUT);
> @@ -869,6 +873,11 @@ static int tcphy_parse_dt(struct rockchip_typec_phy
> *tcphy,
> if (ret)
> return ret;
>
> + ret = tcphy_get_param(dev, &cfg->uphy_dp_sel,
> + "rockchip,uphy-dp-sel");
> + if (ret)
> + return ret;
What about existing device trees? You're essentially adding this
new property and requiring it at the same time.
Or are we considering no RK3399 DP stable at the moment? I guess we
haven't actually merged any device trees that support this yet, no?
Brian
> +
> tcphy->grf_regs = syscon_regmap_lookup_by_phandle(dev->of_node,
> "rockchip,grf");
> if (IS_ERR(tcphy->grf_regs)) {
> --
> 2.6.3
>
>
> ___
> Linux-rockchip mailing list
> linux-rockc...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings
Hi Neil,
On 08-03-2017 12:12, Neil Armstrong wrote:
>
> Hi Jose,
>
> It seems here that we only have the RGB444<->YUV444 8bit tables, from the
> Amlogic
> source I have the following for 10bit, 12bit and 16bit for itu601 :
>
> static const u16 csc_coeff_rgb_out_eitu601_10b[3][4] = {
> { 0x2000, 0x6926, 0x74fd, 0x043b },
> { 0x2000, 0x2cdd, 0x, 0x7a65 },
> { 0x2000, 0x, 0x38b4, 0x78ea }
> };
>
> static const u16 csc_coeff_rgb_out_eitu601_12b_16b[3][4] = {
> { 0x2000, 0x6926, 0x74fd, 0x10ee },
> { 0x2000, 0x2cdd, 0x, 0x6992 },
> { 0x2000, 0x, 0x38b4, 0x63a6 }
> };
These two do not match anything I have here.
>
> static const u16 csc_coeff_rgb_in_eitu601_10b[3][4] = {
> { 0x2591, 0x1322, 0x074b, 0x },
> { 0x6535, 0x2000, 0x7acc, 0x0800 },
> { 0x6acd, 0x7534, 0x2000, 0x0800 }
> };
This is more or less correct, I have small offsets. Note that I
even have offsets with the values that are in dw-hdmi driver,
which can be caused because I'm seeing the latest document that
contain these values. I guess they were updated.
>
> static const u16 csc_coeff_rgb_in_eitu601_12b_16b[3][4] = {
> { 0x2591, 0x1322, 0x074b, 0x },
> { 0x6535, 0x2000, 0x7acc, 0x2000 },
> { 0x6acd, 0x7534, 0x2000, 0x2000 }
> };
The same for this.
>
> But I miss the itu709 values.
>
> Could you confirm these values and maybe provide the itu709 values ?
I will have to check if I can provide you the values. I will get
back to you.
Best regards,
Jose Miguel Abreu
>
> Thanks !
> Neil
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/sun4i: Use embedded tcon pointer to get the tcon's output port node
A pointer to the underlying tcon of the crtc was added to the sun4i_crtc structure in "drm/sun4i: Add backend and tcon pointers to sun4i_crtc". However the crtc init function was still using the copy from sun4i_drv to set drm_crtc.port. This was an oversight when the patches were reordered. Switch to using the embedded tcon pointer to get the tcon's ouptut port and assign it to drm_crtc.port. This makes it possible to remove the usage of sun4i_drv completely in subsequent patches. Signed-off-by: Chen-Yu Tsai --- drivers/gpu/drm/sun4i/sun4i_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c b/drivers/gpu/drm/sun4i/sun4i_crtc.c index 7bbcedff9f07..5323e3485988 100644 --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c @@ -183,7 +183,7 @@ struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm) drm_crtc_helper_add(&scrtc->crtc, &sun4i_crtc_helper_funcs); /* Set crtc.port to output port node of the tcon */ - scrtc->crtc.port = of_graph_get_port_by_id(drv->tcon->dev->of_node, + scrtc->crtc.port = of_graph_get_port_by_id(scrtc->tcon->dev->of_node, 1); /* Set possible_crtcs to this crtc for overlay planes */ -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/11] drm/sun4i: Fix tcon channel 0 comment about backporch = backporch + hsync
The backporch programmed into the tcon registers is actually the
backporch + hsync length from the display timings, as indicated in
the interface timing diagrams found in the user manual of the A31
and A33 SoCs.
The comments for channel 0 mistakenly describe the discrepancy as
TCON backporch = frontporch + hsync.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index ee51d7e77a6a..c52c482c8fd0 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -143,7 +143,7 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
/*
* This is called a backporch in the register documentation,
-* but it really is the front porch + hsync
+* but it really is the back porch + hsync
*/
bp = mode->crtc_htotal - mode->crtc_hsync_start;
DRM_DEBUG_DRIVER("Setting horizontal total %d, backporch %d\n",
@@ -156,7 +156,7 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
/*
* This is called a backporch in the register documentation,
-* but it really is the front porch + hsync
+* but it really is the back porch + hsync
*/
bp = mode->crtc_vtotal - mode->crtc_vsync_start;
DRM_DEBUG_DRIVER("Setting vertical total %d, backporch %d\n",
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Tegra Host1x dma_fence/sync_file support
On 03/09/2017 08:58 PM, Daniel Vetter wrote: On Thu, Mar 9, 2017 at 6:57 PM, Mikko Perttunen wrote: Hi everyone, this series adds support for using sync fences as prefences and postfences for host1x job submissions. The patches are available as a git repository at https://github.com/cyndis/linux/tree/host1x-fence-1 and testing code is available at https://github.com/cyndis/host1x_test though you may want to edit the main function to disable the timeout tests for now as they cause a deadlock (not caused by this series; fix upcoming). Verified on a Jetson TX1; should go on top of the earlier VIC series. Some additional points: * I noticed that the waitchk_mask field in the submit UAPI is completely useless, and has never had any effect in the upstream kernel. It has also not existed in the downstream kernel for many years. We could replace it with the flags field if that is deemed acceptable, though of course it is possible there exists some application that fills it with some non-zero value. If open source userspace (nouveau_dri.so) never used it, then you can freely change it. Backwards compat guarantee in drm is only for open source userspace (and by implication ofc anything that uses the ioctl the same way). See: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements nouveau doesn't have any host1x related code - so no, there is no pre-existing open-source userspace that uses this :) On that topic, do we have the nouveau patches to enable the egl_android extension for this already published? I assume you are referring to EGL_ANDROID_native_fence_sync; I don't know what nouveau's status is regarding that. With this series, the host1x driver does not yet allow other drivers access to the raw syncpoint values behind host1x fences but that can be fixed pretty easily if/when nouveau wants to support native syncpoint waits on Tegra. Host1x jobs do use native waits already with this series, though. * Signaling is enabled for all host1x fences, not just those for which enable_signaling has been called. This is because enable_signaling is called from atomic context and we cannot set up an action waiter in atomic context. Yeah, this was some good fun getting it all sorted in i915 too :-) -Daniel :) Cheers, Mikko Thanks, Mikko 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| 69 +++-- 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 | 8 +- 12 files changed, 367 insertions(+), 23 deletions(-) create mode 100644 drivers/gpu/host1x/fence.c create mode 100644 drivers/gpu/host1x/fence.h -- 2.11.1 ___ 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: [linux-sunxi] Re: [PATCH 10/15] drm/sun4i: tcon: Switch mux on only for composite
On Thu, Mar 9, 2017 at 6:58 PM, Maxime Ripard wrote: > On Wed, Mar 08, 2017 at 11:51:39AM +0800, Chen-Yu Tsai wrote: >> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard >> wrote: >> > Even though that mux is undocumented, it seems like it needs to be set to 1 >> > when using composite, and 0 when using HDMI. >> > >> > Signed-off-by: Maxime Ripard >> > --- >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 7 ++- >> > 1 file changed, 6 insertions(+), 1 deletion(-) >> > >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c >> > index d2335f109601..93249c5ab1e4 100644 >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c >> > @@ -268,11 +268,16 @@ void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon, >> > struct drm_encoder *encoder, >> >SUN4I_TCON_GCTL_IOMAP_MASK, >> >SUN4I_TCON_GCTL_IOMAP_TCON1); >> > >> > + if (encoder->encoder_type == DRM_MODE_ENCODER_TVDAC) >> > + val = 1; >> > + else >> > + val = 0; >> > + >> > /* >> > * FIXME: Undocumented bits >> > */ >> > if (tcon->quirks->has_unknown_mux) >> > - regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, 1); >> > + regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, val); >> >> We might want to do this the other way around, i.e. exporting >> >> int sun4i_tcon_mux_set(struct drm_device *drm, int encoder_type, >>int pipeline) >> >> and have downstream encoders call it. For the A31, the mux is not exclusively >> used for channel 1; there is a mux setting for MIPI DSI as well, but AFAIK >> DSI is connected to channel 0. > > We could make it part of sun4i_tcon_channel_enable too, though. What > do you think? We still need some way of figuring out what mux value to set for those cases. Let's keep your solution for now. We can work on it later when we have an actual use case to deal with. > >> Additionally, the mux registers are only valid in the first TCON, meaning >> it must available be active in 2 pipeline chips. It's also why we'd pass >> "struct drm_device *" instead of "struct sun4i_tcon *". > > H. That's going to be tricky to support. Has this been confirmed > somehow? Is the register used for something else on TCON1? At this point, the only reference is Allwinner's kernel, and the old 3.4 kernel for A10/A20. I could try getting HDMI working on the A31 to get some real results. FWIW, the registers do not seem to be aliased across the two TCONs. Regards ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 14/15] ARM: sun5i: a10s: Add the HDMI controller node
On Thu, Mar 9, 2017 at 6:59 PM, Maxime Ripard
wrote:
> 1;4601;0c
> On Wed, Mar 08, 2017 at 11:35:39AM +0800, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
>> wrote:
>> > The A10s has an HDMI controller connected to the second TCON channel. Add
>> > it to our DT.
>> >
>> > Signed-off-by: Maxime Ripard
>> > ---
>> > arch/arm/boot/dts/sun5i-a10s.dtsi | 34 -
>> > arch/arm/boot/dts/sun5i.dtsi | 1 +-
>> > 2 files changed, 35 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi
>> > b/arch/arm/boot/dts/sun5i-a10s.dtsi
>> > index 074485782a4a..3482c9d2b120 100644
>> > --- a/arch/arm/boot/dts/sun5i-a10s.dtsi
>> > +++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
>> > @@ -72,7 +72,33 @@
>> > };
>> > };
>> >
>> > + display-engine {
>> > + compatible = "allwinner,sun5i-a10s-display-engine",
>> > +"allwinner,sun5i-a13-display-engine";
>> > + allwinner,pipelines = <&fe0>;
>> > + };
>> > +
>> > soc@01c0 {
>> > + hdmi0: hdmi@01c16000 {
>>
>> Nit: is the 0 suffix needed? I don't see any indication that there is
>> a second controller.
>>
>> > + compatible = "allwinner,sun5i-a10s-hdmi";
>> > + reg = <0x01c16000 0x1000>;
>> > + clocks = <&ccu CLK_AHB_HDMI>, <&ccu CLK_HDMI>,
>> > +<&ccu CLK_PLL_VIDEO0_2X>,
>> > +<&ccu CLK_PLL_VIDEO1_2X>;
>> > + clock-names = "ahb", "mod", "pll-0", "pll-1";
>> > + status = "disabled";
>> > +
>> > + port {
>> > + #address-cells = <1>;
>> > + #size-cells = <0>;
>> > +
>> > + hdmi0_in_tcon0: endpoint@0 {
>> > + reg = <0>;
>> > + remote-endpoint =
>> > <&tcon0_out_hdmi0>;
>> > + };
>> > + };
>> > + };
>> > +
>> > pwm: pwm@01c20e00 {
>> > compatible = "allwinner,sun5i-a10s-pwm";
>> > reg = <0x01c20e00 0xc>;
>> > @@ -129,3 +155,11 @@
>> >
>> > &sram_a {
>> > };
>> > +
>> > +&tcon0_out {
>> > + tcon0_out_hdmi0: endpoint@2 {
>> > + reg = <2>;
>> > + remote-endpoint = <&hdmi0_in_tcon0>;
>> > + allwinner,tcon-channel = <1>;
>> > + };
>> > +};
>> > diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
>> > index f3b6e19244f9..3d009b2aa42a 100644
>> > --- a/arch/arm/boot/dts/sun5i.dtsi
>> > +++ b/arch/arm/boot/dts/sun5i.dtsi
>> > @@ -273,6 +273,7 @@
>> > tcon0_out_tve0: endpoint@1 {
>> > reg = <1>;
>> > remote-endpoint =
>> > <&tve0_in_tcon0>;
>> > + allwinner,tcon-channel =
>> > <1>;
>>
>> This looks like a separate patch, probably following the binding
>> change?
>
> I don't know, the binding says that without anything specified, reg
> would be used. I was assuming that we only needed it once we had the
> new endpoint to make it consistent, therefore it didn't need an extra
> patch.
>
> But I can definitely create one if you want.
It just seems a bit out of place, that's all. Mentioning it in the
commit message would be good enough for me.
ChenYu
> 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
[PATCH 07/11] drm/sun4i: Fetch backend ID from device tree
Some Allwinner SoCs have 2 display pipelines, as in 2 of each
components, including the frontend, backend, TCON, and any other
extras.
As the backend and TCON are always paired together and form the CRTC,
we need to know which backend or TCON we are currently probing, so we
can pair them when initializing the CRTC.
This patch figures out the backend's ID from the device tree and stores
it in the backend's data structure. It does this by looking at the "reg"
property of any remote endpoints connected to the backend's input port.
Signed-off-by: Chen-Yu Tsai
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 44 +++
drivers/gpu/drm/sun4i/sun4i_backend.h | 2 ++
2 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index d660741ba475..f3c92d54c8e4 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
#include "sun4i_backend.h"
@@ -288,6 +289,45 @@ static int sun4i_backend_free_sat(struct device *dev) {
return 0;
}
+/*
+ * The display backend can take video output from the display frontend, or
+ * the display enhancement unit on the A80, as input for one it its layers.
+ * This relationship within the display pipeline is encoded in the device
+ * tree with of_graph, and we use it here to figure out which backend, if
+ * there are 2 or more, we are currently probing. The number would be in
+ * the "reg" property of the upstream output port endpoint.
+ */
+static int sun4i_backend_of_get_id(struct device_node *node)
+{
+ struct device_node *port, *ep;
+ int ret = -EINVAL;
+
+ /* input is port 0 */
+ port = of_graph_get_port_by_id(node, 0);
+ if (!port)
+ return -EINVAL;
+
+ /* try finding an upstream endpoint */
+ for_each_available_child_of_node(port, ep) {
+ struct device_node *remote;
+ u32 reg;
+
+ remote = of_parse_phandle(ep, "remote-endpoint", 0);
+ if (!remote)
+ continue;
+
+ ret = of_property_read_u32(remote, "reg", ®);
+ if (ret)
+ continue;
+
+ ret = reg;
+ }
+
+ of_node_put(port);
+
+ return ret;
+}
+
static struct regmap_config sun4i_backend_regmap_config = {
.reg_bits = 32,
.val_bits = 32,
@@ -312,6 +352,10 @@ static int sun4i_backend_bind(struct device *dev, struct
device *master,
dev_set_drvdata(dev, backend);
drv->backend = backend;
+ backend->id = sun4i_backend_of_get_id(dev->of_node);
+ if (backend->id < 0)
+ return backend->id;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev, res);
if (IS_ERR(regs))
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 83e63cc702b4..d9a7df55c63f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -149,6 +149,8 @@ struct sun4i_backend {
struct clk *sat_clk;
struct reset_control*sat_reset;
+
+ int id;
};
void sun4i_backend_apply_color_correction(struct sun4i_backend *backend);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] phy: rockchip-typec: support DP phy switch
Hi, On Thu, Mar 09, 2017 at 02:02:54AM +0100, Heiko Stuebner wrote: > Am Mittwoch, 8. März 2017, 16:39:23 CET schrieb Brian Norris: > > On Fri, Feb 10, 2017 at 03:44:13PM +0800, Chris Zhong wrote: > > > There are 2 Type-c PHYs in RK3399, but only one DP controller. Hence > > > only one PHY can connect to DP controller at one time, the other should > > > be disconnected. The GRF_SOC_CON26 register has a switch bit to do it, > > > set this bit means enable PHY 1, clear this bit means enable PHY 0. > > > > > > Signed-off-by: Chris Zhong > > > --- > > > > > > drivers/phy/phy-rockchip-typec.c | 9 + > > > 1 file changed, 9 insertions(+) > > > > > > diff --git a/drivers/phy/phy-rockchip-typec.c > > > b/drivers/phy/phy-rockchip-typec.c index 7cfb0f8..1604aaa 100644 > > > --- a/drivers/phy/phy-rockchip-typec.c > > > +++ b/drivers/phy/phy-rockchip-typec.c ... > > > @@ -869,6 +873,11 @@ static int tcphy_parse_dt(struct rockchip_typec_phy > > > *tcphy,> > > > if (ret) > > > > > > return ret; > > > > > > + ret = tcphy_get_param(dev, &cfg->uphy_dp_sel, > > > + "rockchip,uphy-dp-sel"); > > > + if (ret) > > > + return ret; > > > > What about existing device trees? You're essentially adding this > > new property and requiring it at the same time. > > > > Or are we considering no RK3399 DP stable at the moment? I guess we > > haven't actually merged any device trees that support this yet, no? > > An interesting situation we're in here. On the one hand, you're right this > breaks "backwards compatiblity". > > But on the other hand, the type-c phy is currently very much unused. The only > current board rk3399-evb.dts does not enable them (so they're disabled > everywhere) and we have neither dwc3 nor dp nodes in any rk3399 devicetrees > so > far. Also Rob was ok with the binding change :-) . > > So from my pov, I'd say it _should_ be ok, as nothing is using the phys at > all > yet and thus there is nothing that could get broken. Yeah, I guess it's OK... but BTW out-of-tree DTs are perfectly legit, once the bindings are accepted. Another random point of contention (not worth too much, as the pattern is already set), but why do these deserve DT properties at all? The device already has a "rk3399" compatible property, so can't we derive GRF offsets from that? Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] phy: rockchip-typec: support DP phy switch
On Thu, Mar 09, 2017 at 09:31:33AM +0100, Heiko Stuebner wrote: > Am Mittwoch, 8. März 2017, 19:10:50 CET schrieb Brian Norris: > > Another random point of contention (not worth too much, as the pattern > > is already set), but why do these deserve DT properties at all? The > > device already has a "rk3399" compatible property, so can't we derive > > GRF offsets from that? > > I'm definitly with you in this regard. > > But it seems like there is some sort of current trend of moving more stuff > into the dt again. I vaguely remember phy and (or) dt-maintainers preferring > to have these definitions in the dt for the typec-phy. Hmm, not sure I understand that one. You're just going to multiply the variations of DT props you have to support, instead of simply multiplying a (non-ABI) table within the driver. The latter seems much more stable. Oh well, not my subsystem. > See also the recent mail from Olof concerning the grf initialization and > maybe > not having per-soc definitions in the driver, where I'm trying to keep things > out of the dt a bit more strongly :-) . Thanks for the pointer. I looked up (and replied to) that one. Either I don't understand exactly what he's saying or... I'd like to know what he's smoking. You can't just wish away the fact that the GRF is truly a "general register file" and will change forever (and so will our understanding of how to use it). Kernels always need to update for new chipsets. Device Tree Bindings Are Forever (TM). Now let's see if Olof reads my reply which points back to this thread...and now to the above comment :) > So yes, personally I would definitly prefer not having to much GRF-stuff leak > into the dt. Simply because the GRF has always been very unstable over time > [=you always find one more bit that needs tuning] and to not cause things > like > the above. But as you said I guess we're to late for the typec-phy. I'm with you. Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/11] drm/sun4i: Support two display pipelines
Hi Maxime, This is part 3 of my sun4i drm clean up series. In this part support for 2 display pipelines is added, after some more code cleanups and restructuring. While this series enables the second display pipeline, there's no usable output at the moment. For the A31, the second TCON's panel interface uses the same pins as the Ethernet controller. However Ethernet is used on most boards. We will have to wait for HDMI support to actually use it. Patch 1 fixes the TCON's clock and regmap initialization sequence, splitting out the dot clock init part till after the regmap. Patch 2 fixes a comment spotted while reviewing Maxime's HDMI patches. Patch 3 makes the crtc init code use the tcon pointer embedded in the crtc structure, instead of the sun4i_drv structure, to get the tcon's output port node. This should have been a part of the last batch of patches. Patch 4 makes the tv encoder code get the tcon and backend pointers from its attached crtc. Patch 5 makes the crtc init function take tcon and backend pointers. Patch 6 makes the layer init functions take a backend pointer. Patch 7 adds a function to fetch a backend's ID from the device tree. Patch 8 adds a function to fetch a TCON's ID from the device tree. Patch 9 extends the sun4i drm driver to support 2 display pipelines. Patch 10 adds device nodes for sun6i's second display pipeline. Patch 11 enables sun6i's tcon0 by default. Regards ChenYu Chen-Yu Tsai (11): drm/sun4i: Fix TCON clock and regmap initialization sequence drm/sun4i: Fix tcon channel 0 comment about backporch = backporch + hsync drm/sun4i: Use embedded tcon pointer to get the tcon's output port node drm/sun4i: tv: Get tcon and backend pointers from associated crtc drm/sun4i: Pass pointers for associated backend and tcon into crtc init drm/sun4i: Pass pointer for underlying backend into layer init drm/sun4i: Fetch backend ID from device tree drm/sun4i: Fetch TCON ID from device tree drm/sun4i: Support two display pipelines ARM: dts: sun6i: Add second display pipeline device nodes ARM: dts: sun6i: Enable tcon0 by default arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 1 - arch/arm/boot/dts/sun6i-a31.dtsi| 169 +++- drivers/gpu/drm/sun4i/sun4i_backend.c | 53 - drivers/gpu/drm/sun4i/sun4i_backend.h | 2 + drivers/gpu/drm/sun4i/sun4i_crtc.c | 13 ++- drivers/gpu/drm/sun4i/sun4i_crtc.h | 4 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +- drivers/gpu/drm/sun4i/sun4i_drv.h | 6 +- drivers/gpu/drm/sun4i/sun4i_layer.c | 13 +-- drivers/gpu/drm/sun4i/sun4i_layer.h | 3 +- drivers/gpu/drm/sun4i/sun4i_tcon.c | 99 ++-- drivers/gpu/drm/sun4i/sun4i_tcon.h | 2 + drivers/gpu/drm/sun4i/sun4i_tv.c| 19 ++-- 13 files changed, 344 insertions(+), 42 deletions(-) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/11] drm/sun4i: Support two display pipelines
On Thu, Mar 9, 2017 at 6:36 PM, Maxime Ripard
wrote:
> Hi,
>
> On Thu, Mar 09, 2017 at 06:05:32PM +0800, Chen-Yu Tsai wrote:
>> Some Allwinner SoCs have two display pipelines (frontend -> backend ->
>> tcon).
>>
>> Previously we only supported one pipeline. This patch extends the
>> current driver to support two. It extends the tcon and backend pointers
>> in sun4i_drv into arrays, and makes the related bind functions store
>> the pointer into said arrays based on the id fetched from the device
>> tree. In the case of the tcons, it falls back to a first come order
>> if no encoders that can be used for differentiating the tcons are
>> defined. The driver's depth-first traversal of the of graph, coupled
>> with the increasing address ordering of the of graph endpoints, and
>> the fact that tcon0 should always be enabled for the tcon/encoder
>> mux to be accessible, means that tcon1 would always come after tcon0.
>>
>> Assignment of the device structure into sun4i_drv is moved to the end
>> of the bind function, when all possible error checks have passed.
>>
>> This patch also drops a trailing 0 in one of the backend probe messages.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> drivers/gpu/drm/sun4i/sun4i_backend.c | 9 +++--
>> drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
>> drivers/gpu/drm/sun4i/sun4i_drv.h | 6 --
>> drivers/gpu/drm/sun4i/sun4i_tcon.c| 25 +
>> 4 files changed, 29 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
>> b/drivers/gpu/drm/sun4i/sun4i_backend.c
>> index f3c92d54c8e4..8d22efd5a9cc 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
>> @@ -350,12 +350,15 @@ static int sun4i_backend_bind(struct device *dev,
>> struct device *master,
>> if (!backend)
>> return -ENOMEM;
>> dev_set_drvdata(dev, backend);
>> - drv->backend = backend;
>>
>> backend->id = sun4i_backend_of_get_id(dev->of_node);
>> if (backend->id < 0)
>> return backend->id;
>>
>> + /* We only support SUN4I_DRM_MAX_PIPELINES number of backends */
>> + if (backend->id >= SUN4I_DRM_MAX_PIPELINES)
>> + return -EINVAL;
>> +
>> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> regs = devm_ioremap_resource(dev, res);
>> if (IS_ERR(regs))
>> @@ -364,7 +367,7 @@ static int sun4i_backend_bind(struct device *dev, struct
>> device *master,
>> backend->regs = devm_regmap_init_mmio(dev, regs,
>> &sun4i_backend_regmap_config);
>> if (IS_ERR(backend->regs)) {
>> - dev_err(dev, "Couldn't create the backend0 regmap\n");
>> + dev_err(dev, "Couldn't create the backend regmap\n");
>> return PTR_ERR(backend->regs);
>> }
>>
>> @@ -413,6 +416,8 @@ static int sun4i_backend_bind(struct device *dev, struct
>> device *master,
>> }
>> }
>>
>> + drv->backend[backend->id] = backend;
>> +
>> /* Reset the registers */
>> for (i = 0x800; i < 0x1000; i += 4)
>> regmap_write(backend->regs, i, 0);
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
>> b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> index 767bbadcc85d..c15ecb8343d7 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> @@ -271,7 +271,7 @@ static int sun4i_drv_probe(struct platform_device *pdev)
>> struct device_node *np = pdev->dev.of_node;
>> int i, count = 0;
>>
>> - for (i = 0;; i++) {
>> + for (i = 0; i < SUN4I_DRM_MAX_PIPELINES; i++) {
>> struct device_node *pipeline = of_parse_phandle(np,
>>
>> "allwinner,pipelines",
>> i);
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.h
>> b/drivers/gpu/drm/sun4i/sun4i_drv.h
>> index 5df50126ff52..ec1c08af47e1 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_drv.h
>> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.h
>> @@ -16,9 +16,11 @@
>> #include
>> #include
>>
>> +#define SUN4I_DRM_MAX_PIPELINES 2
>> +
>> struct sun4i_drv {
>> - struct sun4i_backend*backend;
>> - struct sun4i_tcon *tcon;
>> + struct sun4i_backend*backend[SUN4I_DRM_MAX_PIPELINES];
>> + struct sun4i_tcon *tcon[SUN4I_DRM_MAX_PIPELINES];
>>
>> struct drm_fbdev_cma*fbdev;
>> };
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index b774c9a50c55..7749c3133f38 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -532,7 +532,6 @@ static int sun4i_tcon_bind(struct device *dev, struct
>> device *master,
>> if (!tcon)
>> return -ENOMEM;
>> dev_set_drvdata(dev, tcon);
>> - drv->tcon = tcon;
>> tcon->drm = drm;
>> tcon->dev = dev;
>> t
Re: [PATCH] drm: Forward declare struct platform_device
On 9 March 2017 at 22:46, Chris Wilson wrote:
> ./include/drm/drm_pci.h:76:64: warning: ‘struct platform_device’ declared
> inside parameter list will not be visible outside of this definition or
> declaration
> extern int drm_platform_init(struct drm_driver *driver, struct
> platform_device *platform_device);
>
> Fixes: 23ef59ef6dcc ("drm: Extract drm_pci.h")
> Signed-off-by: Chris Wilson
> Cc: Gustavo Padovan
> Cc: Daniel Vetter
> ---
> include/drm/drm_pci.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_pci.h b/include/drm/drm_pci.h
> index 5081b3eba309..9cd2173fc892 100644
> --- a/include/drm/drm_pci.h
> +++ b/include/drm/drm_pci.h
> @@ -73,6 +73,8 @@ extern int drm_pcie_get_speed_cap_mask(struct drm_device
> *dev, u32 *speed_mask);
> extern int drm_pcie_get_max_link_width(struct drm_device *dev, u32 *mlw);
>
> /* platform section */
> -extern int drm_platform_init(struct drm_driver *driver, struct
> platform_device *platform_device);
> +struct platform_device;
> +extern int drm_platform_init(struct drm_driver *driver,
> +struct platform_device *platform_device);
>
I wouldn't bother with the re-wrap, but regardless
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Shared semaphores for amdgpu
Am 10.03.2017 um 00:19 schrieb Dave Airlie:
Completely agree, problem here is that this isn't documented like this in
the Vulkan specification as far as I know.
(I'm adding dri-devel, since I think Intel folks have looked into some
of this already,
and we might need to make some common functionality).
"The semaphore must be signaled, or have an associated semaphore
signal operation that is
pending execution."
So I'll try and summarise the semantics of semaphores vs current fence fds.
For shared semaphores there are two defined semantics: temporary and permanent,
I think we would need to support both. temporary align with fence fd,
but permanent not so much.
The main difference I see if that fence's are a one shot thing, you
create a fence when you submit
it and then you give it to someone else to wait on it.
Semaphores are a create once, share once, use multiple times.
The semantics for permanaent semaphore sharing is:
process AB
allocate
export
import
signal
wait
signal
wait
and so on.
The way we currently to semaphores is to insert a fence into the
semaphore on signal, and
block waiting for that fence on wait, then insert a new one on the
next signal. This means
we don't want to constantly reshared the fence_fd. (The temporary
semaphores sharing semantics
match this behaviour).
This leaves me to believe that fence fd's can't be used for this task
as-is. Now the question is if we can
extend them, and how we do that in a useful and backwards compatible manner.
As far as I can see the only functionality we are missing here is:
void sync_file_signal(struct sync_file *sync_file, struct dma_fence *fence)
{
dma_fence_put(sync_file->fence);
sync_file->fence = fence;
}
We probably should do this atomically, but that is only a matter of
taking locks/atomic pointer operation.
The waiting is done using the normal sync_file_get_fence() function.
The rest is David's patch to import/export the fd handle into a local
idr based handle.
How would we do this, allow dma_fence to be "updated" from another
dma_fence, so we have some sort
of dma_fence variant that has a permanent lifetime, that we can on
signal update from another fence
to match it's behaviour, then on wait works on the updated info. Do we
just want a wrapper around a fence
then, which is pretty much what the proposed sem code is. or do we
want some way to link a bunch
of fences together? What we don't want is to expose to userspace
anything that requires us to reshare the
fence via the fd again after the initial setup.
We don't need to reshare the fd or change anything on the dma_fence
implementation, just using the sync_file as the base container should be
enough.
Christian.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Forward declare struct platform_device
On Fri, Mar 10, 2017 at 12:41:30AM +, Emil Velikov wrote:
> On 9 March 2017 at 22:46, Chris Wilson wrote:
> > ./include/drm/drm_pci.h:76:64: warning: ‘struct platform_device’ declared
> > inside parameter list will not be visible outside of this definition or
> > declaration
> > extern int drm_platform_init(struct drm_driver *driver, struct
> > platform_device *platform_device);
> >
> > Fixes: 23ef59ef6dcc ("drm: Extract drm_pci.h")
> > Signed-off-by: Chris Wilson
> > Cc: Gustavo Padovan
> > Cc: Daniel Vetter
> > ---
> > include/drm/drm_pci.h | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/drm/drm_pci.h b/include/drm/drm_pci.h
> > index 5081b3eba309..9cd2173fc892 100644
> > --- a/include/drm/drm_pci.h
> > +++ b/include/drm/drm_pci.h
> > @@ -73,6 +73,8 @@ extern int drm_pcie_get_speed_cap_mask(struct drm_device
> > *dev, u32 *speed_mask);
> > extern int drm_pcie_get_max_link_width(struct drm_device *dev, u32 *mlw);
> >
> > /* platform section */
> > -extern int drm_platform_init(struct drm_driver *driver, struct
> > platform_device *platform_device);
> > +struct platform_device;
> > +extern int drm_platform_init(struct drm_driver *driver,
> > +struct platform_device *platform_device);
> >
> I wouldn't bother with the re-wrap, but regardless
> Reviewed-by: Emil Velikov
Step by step we become checkpatch clean.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100141] [AMDGPU][CIK][4.10/4.11-rc1] Regression - Hibernation does not respect 'reboot' option in /sys/power/disk
https://bugs.freedesktop.org/show_bug.cgi?id=100141 --- Comment #1 from Michel Dänzer --- It's not the amdgpu driver's responsibility to perform the reboot. It's possible that an amdgpu bug somehow prevents the reboot from occurring though. Does this problem not happen when the amdgpu driver is blacklisted? -- 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] drm: Add DPCD definitions for DP 1.4 DSC feature
On Wed, Feb 22, 2017 at 10:23:18AM +0200, Jani Nikula wrote: > > [Your MUA messed up the quoting, FTFY below.] > > On Wed, 22 Feb 2017, "Navare, Manasi D" wrote: > > > On Fri, 17 Feb 2017, Manasi Navare wrote: > > >> Display stream compression is supported on DP 1.4 DP devices. This > > >> patch adds the corersponding DPCD register definitions for DSC. > > >> > > >> v2: > > >> * Rebased on drm-tip > > >> > > >> Signed-off-by: Manasi Navare > > >> Cc: Jani Nikula > > >> Cc: Paulo Zanoni > > >> Cc: dri-devel@lists.freedesktop.org > > > > > > Tedious work to cross check this stuff against the spec... found one > > > real issue; while at it please fix a few nitpicks that I would > > > otherwise have ignored. > > > > > > BR, > > > Jani. > > > > > > > > >> --- > > >> include/drm/drm_dp_helper.h | 102 > > >> > > >> 1 file changed, 102 insertions(+) > > >> > > >> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > > >> index ba89295..4c1fc26 100644 > > >> --- a/include/drm/drm_dp_helper.h > > >> +++ b/include/drm/drm_dp_helper.h > > >> @@ -179,6 +179,108 @@ > > >> > > >> #define DP_GUID 0x030 /* 1.2 */ > > >> > > >> +#define DP_DSC_SUPPORT 0x060 /* DP 1.4 */ > > >> +# define DP_DSC_DECOMPRESSION_IS_SUPPORTED (1 << 0) > > >> + > > >> +#define DP_DSC_REV 0x061 > > >> +# define DP_DSC_MAJOR_MASK (15 << 0) > > >> +# define DP_DSC_MINOR_MASK (15 << 4) > > >> +# define DP_DSC_MINOR_SHIFT 4 > > > > > > Nitpick: Hex is preferred for masks. Same for all masks > > > below. MAJOR_SHIFT for completeness. > > > > > So should I add the MAJOR_SHIFT as well even though it will just 0? > > Yes, 0 is not special here. Having it is also self-documenting, so you > don't have to look up the DP spec to check. > > > > > > > > > >> + > > >> +#define DP_DSC_RC_BUF_BLK_SIZE 0x062 > > >> +# define DP_DSC_RC_BUF_BLK_SIZE_1 0x0 > > >> +# define DP_DSC_RC_BUF_BLK_SIZE_4 0x1 > > >> +# define DP_DSC_RC_BUF_BLK_SIZE_16 0x2 > > >> +# define DP_DSC_RC_BUF_BLK_SIZE_64 0x3 > > >> + > > >> +#define DP_DSC_RC_BUF_SIZE 0x063 > > >> + > > >> +#define DP_DSC_SLICE_CAP_1 0x064 > > >> +# define DP_DSC_1_PER_DP_DSC_SINK (1 << 0) > > >> +# define DP_DSC_2_PER_DP_DSC_SINK (1 << 1) > > >> +# define DP_DSC_4_PER_DP_DSC_SINK (1 << 3) > > >> +# define DP_DSC_6_PER_DP_DSC_SINK (1 << 4) > > >> +# define DP_DSC_8_PER_DP_DSC_SINK (1 << 5) > > >> +# define DP_DSC_10_PER_DP_DSC_SINK (1 << 6) > > >> +# define DP_DSC_12_PER_DP_DSC_SINK (1 << 7) > > >> + > > >> +#define DP_DSC_LINE_BUF_BIT_DEPTH 0x065 > > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_MASK (15 << 0) > > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_90x0 > > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_10 0x1 > > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_11 0x2 > > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_12 0x3 > > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_13 0x4 > > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_14 0x5 > > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_15 0x6 > > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_16 0x7 > > >> +# define DP_DSC_LINE_BUF_BIT_DEPTH_80x8 > > >> + > > >> +#define DP_DSC_BLK_PREDICTION_SUPPORT 0x066 > > >> +# define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0) > > >> + > > >> +#define DP_DSC_MAX_BITS_PER_PIXEL_LOW 0x067 /* eDP 1.4 */ > > >> + > > >> +#define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068 /* eDP 1.4 */ > > >> + > > >> +#define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069 > > >> +# define DP_DSC_RGB (1 << 0) > > >> +# define DP_DSC_YCbCr444(1 << 1) > > >> +# define DP_DSC_YCbCr422_Simple (1 << 2) > > >> +# define DP_DSC_YCbCr422_Native (1 << 3) > > >> +# define DP_DSC_YCbCr420_Native (1 << 4) > > >> + > > >> +#define DP_DSC_DEC_COLOR_DEPTH_CAP 0x06A > > >> +# define DP_DSC_8_BPC (1 << 1) > > >> +# define DP_DSC_10_BPC (1 << 2) > > >> +# define DP_DSC_12_BPC (1 >> 3) > > > > > > Oops, shifting to wrong direction! > > > > Oops, yes that is my mistake, I will fix the shift direction. > > > > >> + > > >> +#define DP_DSC_PEAK_THROUGHPUT 0x06B > > >> +# define DP_DSC_THROUGHPUT_MODE_0_340 0x1 > > >> +# define DP_DSC_THROUGHPUT_MODE_0_400 0x2 > > >> +# define DP_DSC_THROUGHPUT_MODE_0_450 0x3 > > >> +# define DP_DSC_THROUGHPUT_MODE_0_500 0x4 > > >> +# define DP_DSC_THROUGHPUT_MODE_0_550 0x5 > > >> +# define DP_DSC_THROUGHPUT_MODE_0_600 0x6 > > >> +# define DP_DSC_THROUGHPUT_MODE_0_650 0x7 > > >> +# define DP_DSC_THROUGHPUT_MODE_0_700 0x8 > > >> +# define DP_DSC_T
Re: Shared semaphores for amdgpu
>
> As far as I can see the only functionality we are missing here is:
>
> void sync_file_signal(struct sync_file *sync_file, struct dma_fence *fence)
> {
> dma_fence_put(sync_file->fence);
> sync_file->fence = fence;
> }
>
> We probably should do this atomically, but that is only a matter of taking
> locks/atomic pointer operation.
>
> The waiting is done using the normal sync_file_get_fence() function.
>
> The rest is David's patch to import/export the fd handle into a local idr
> based handle.
Are you suggesting we start keeping track of sync_file objects in a local idr?
As currently they are only tracked as files, which is probably not what we want
for every unshared semaphore, or are you thinking more that the amdgpu local
sem should be just storing a sync_file pointer, rather than what it does now.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
connector/edid probing races
Talk to Jonas (jadahl) on irc, he had 3 mutters running and on hotplug all 3 of them were diving into the connector getting code. Now I think we can avoid this in userspace by not probing when not owning the VT, but it's still messy behaviour. It looks like one thread does a getconnector, this fills out the EDID blob with a specific blob id, then second thread does getconnector, which replaces the EDID blob with another one the first thread calls get property blob, but the blob id it is looking for is destroyed. Ideas? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 4.11-rc2
Hi Linus, These are the drm fixes I've collected for rc2. Mostly i915 GVT only fixes, along with a single EDID fix, some mxsfb fixes and a few minor amd fixes. Thanks, Dave. The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201: Linux 4.11-rc1 (2017-03-05 12:59:56 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-4.11-rc2 for you to fetch changes up to 3f81e1340706e9a7f854808e2f580c3106805d0c: drm: mxsfb: Implement drm_panel handling (2017-03-10 11:11:14 +1000) intel, amd and mxsfb fixes. Alex Deucher (2): drm/amdgpu: validate paramaters in the gem ioctl drm/amdgpu: bump driver version for some new features Bing Niu (1): drm/i915/gvt: set SFUSE_STRAP properly for vitual monitor detection Changbin Du (1): drm/i915/gvt: protect RO and Rsvd bits of virtual vgpu configuration space Chuanxiao Dong (3): drm/i915/gvt: add a NULL pointer check to avoid kernel panic drm/i915/gvt: use pfn_valid for better checking drm/i915/gvt: handle workload lifecycle properly Dave Airlie (3): Merge tag 'drm-misc-fixes-2017-03-06' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2017-03-09' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes Merge branch 'drm-fixes-4.11' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Fabio Estevam (2): drm: mxsfb_crtc: Fix the framebuffer misplacement drm: mxsfb: Implement drm_panel handling Jani Nikula (2): Merge tag 'gvt-next-2017-02-24' of https://github.com/01org/gvt-linux into drm-intel-fixes Merge tag 'gvt-fixes-2017-03-08' of https://github.com/01org/gvt-linux into drm-intel-fixes Jim Qu (1): drm/amd/amdgpu: fix console deadlock if late init failed Marek Vasut (1): drm: mxsfb: Fix crash when provided invalid DT bindings Min He (2): drm/i915/gvt: introduced failsafe mode into vgpu drm/i915/gvt: enter failsafe mode when guest requires more resources Pei Zhang (2): drm/i915/gvt: add cmd_access to GEN7_HALF_SLICE_CHICKEN1 drm/i915/gvt: add some new MMIOs to cmd_access white list Ping Gao (1): drm/i915/gvt: clear the vGPU reset logic Stefan Agner (2): drm: mxsfb: use bus_format to determine LCD bus width drm: mxsfb: fix pixel clock polarity Takashi Iwai (1): drm/i915/gvt: Fix superfluous newline in GVT_DISPLAY_READY env var Tina Zhang (1): drm/i915/gvt: change some gvt_err to gvt_dbg_cmd Tomeu Vizoso (1): drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058 Weinan Li (2): drm/i915/gvt: refine pcode write emulation drm/i915/gvt: fix pcode mailbox write emulation of BDW Zhao Yan (8): drm/i915/gvt: fix unhandled mmio warnings drm/i915/gvt: add more registers to context save/restore list drm/i915/gvt: force-nopriv register handling drm/i915/gvt: set default value to 0 for unhandled mmio regs drm/i915/gvt: have more registers with F_CMD_ACCESS flags set drm/i915/gvt: add more registers into handlers list drm/i915/gvt: fix an error for one register drm/i915/gvt: fix an error for F_RO flag Zhao, Xinda (3): drm/i915/gvt: handle fence reg access during GPU reset drm/i915/gvt: decrease priority of output msg for untracked mmio drm/i915/gvt: remove unnecessary error msg from gtt write Zhenyu Wang (4): drm/i915/gvt: Fix check error on opregion.c drm/i915/gvt: adjust to fixed vGPU types drm/i915/gvt: Add more edid definition support drm/i915/gvt: add resolution definition for vGPU type drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 21 ++ drivers/gpu/drm/drm_edid.c | 3 + drivers/gpu/drm/i915/gvt/cfg_space.c | 57 +++- drivers/gpu/drm/i915/gvt/cmd_parser.c | 10 +- drivers/gpu/drm/i915/gvt/display.c | 139 ++--- drivers/gpu/drm/i915/gvt/display.h | 20 +- drivers/gpu/drm/i915/gvt/firmware.c| 2 +- drivers/gpu/drm/i915/gvt/gtt.c | 40 ++- drivers/gpu/drm/i915/gvt/gvt.h | 12 +- drivers/gpu/drm/i915/gvt/handlers.c| 439 - drivers/gpu/drm/i915/gvt/kvmgt.c | 12 +- drivers/gpu/drm/i915/gvt/mmio.c| 66 - drivers/gpu/drm/i915/gvt/opregion.c| 5 +- drivers/gpu/drm/i915/gvt/render.c | 16 ++ drivers/gpu/drm/i915/gvt/scheduler.c | 52 ++-- drivers/gpu/drm/i915/gvt/vgpu.c| 72 +++-- drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 49 +++- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 + drivers/gpu/drm/mxsfb/mxsfb_out.c | 4 + drivers/gpu/drm/mxsfb/
[PATCH 00/41] Chromebook Plus (aka kevin) kernel patches
Despite our best intentions (and we did a decent job this time around) of submitting upstream first for the Chromebook Plus, we had a number of patches slip through the cracks. This series includes all but one of those patches. The outlier breaks my veyron board, so I dropped it. The patches have been tested on the Chromebook Plus in our downstream kernel, and my veyron-jaq board with an upstream kernel. They have also been compile tested using the drm-misc configs. Sean Douglas Anderson (4): drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner drm/bridge: analogix_dp: Split the platform-specific poweron in two parts drm/bridge: analogix_dp: Properly log AUX CH errors drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip Haixia Shi (1): drm/rockchip: support prime import sg table Lin Huang (6): drm/bridge: analogix_dp: Move enable video into config_video() drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the panel drm/bridge: analogix_dp: Extend hpd check time to 100ms drm/bridge: analogix_dp: Check dpcd write/read status drm/bridge: analogix_dp: Reset aux channel if an error occurred Mark Yao (1): drm/rockchip: pre dither down when output bpc is 8bit Sean Paul (3): drm/panel: simple: Change mode for Sharp lq123p1jx31 drm/rockchip: Don't use atomic constructs for psr drm/rockchip: Remove analogix psr worker Tomasz Figa (6): drm/rockchip: Get rid of some unnecessary code drm/rockchip: Flush PSR before committing modeset disables/enables drm/bridge: analogix_dp: Allow master driver to cleanup in unbind drm/rockchip: analogix_dp: Fix invalid implementation of unbind drm/bridge: analogix_dp: Add analogix_dp_shutdown drm/rockchip: analogix_dp: Wire the shutdown callback to disable PSR Yakir Yang (1): drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR zain wang (18): drm/bridge: analogix_dp: set psr activate/deactivate when enable/disable bridge drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind drm/bridge: analogix_dp: Don't change psr while bridge is disabled drm/rockchip: add mutex vop lock drm/bridge: analogix_dp: add fast link train for eDP drm/rockchip: Only wait for panel ACK on PSR entry drm/bridge: analogix_dp: Don't use fast link training when panel just powered up drm/bridge: analogix_dp: Retry bridge enable when it failed drm/bridge: analogix_dp: Wait for HPD signal before configuring link drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip drm/rockchip: Restore psr->state when enable/disable psr failed drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll drm/bridge: analogix_dp: Fix timeout of video streamclk config drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1 drm/bridge: analogix_dp: Move fast link training detect to set_bridge drm/rockchip: Disable VOP windows when PSR is active Ørjan Eide (1): drm/rockchip: Respect page offset for PRIME mmap calls drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 471 +++-- drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 14 +- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 273 +++- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 7 + drivers/gpu/drm/exynos/exynos_dp.c | 2 +- drivers/gpu/drm/panel/panel-simple.c | 7 +- drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 129 +++--- drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 3 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 4 +- drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 13 + drivers/gpu/drm/rockchip/rockchip_drm_gem.c| 125 +- drivers/gpu/drm/rockchip/rockchip_drm_gem.h| 5 +- drivers/gpu/drm/rockchip/rockchip_drm_psr.c| 112 ++--- drivers/gpu/drm/rockchip/rockchip_drm_psr.h| 6 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 81 +++- drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 6 +- include/drm/bridge/analogix_dp.h | 7 +- 18 files changed, 882 insertions(+), 384 deletions(-) -- 2.12.0.246.ga2ecc84866-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/41] drm/panel: simple: Change mode for Sharp lq123p1jx31
Change the mode for Sharp lq123p1jx31 panel to something more
rockchip-friendly such that we can use the fixed PLLs to
generate the pixel clock
Cc: Chris Zhong
Cc: Stéphane Marchesin
Signed-off-by: Sean Paul
---
drivers/gpu/drm/panel/panel-simple.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 89eb0422821c..787b4d143220 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1598,17 +1598,18 @@ static const struct panel_desc sharp_lq101k1ly04 = {
};
static const struct drm_display_mode sharp_lq123p1jx31_mode = {
- .clock = 252750,
+ .clock = 27,
.hdisplay = 2400,
.hsync_start = 2400 + 48,
.hsync_end = 2400 + 48 + 32,
- .htotal = 2400 + 48 + 32 + 80,
+ .htotal = 2400 + 48 + 32 + 139,
.vdisplay = 1600,
.vsync_start = 1600 + 3,
.vsync_end = 1600 + 3 + 10,
- .vtotal = 1600 + 3 + 10 + 33,
+ .vtotal = 1600 + 3 + 10 + 84,
.vrefresh = 60,
.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+ .type = DRM_MODE_TYPE_PREFERRED | DRM_MODE_TYPE_DRIVER,
};
static const struct panel_desc sharp_lq123p1jx31 = {
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/41] drm/bridge: analogix_dp: set psr activate/deactivate when enable/disable bridge
From: zain wang
There's a race between when bridge_disable and when vop_crtc_disable
are called. If the flush timer triggers a new psr work between these,
we will operate eDP without power shutdowned by bridge_disable. In this
case, moving activate/deactivate to enable/disable bridge to avoid it.
Cc: Stéphane Marchesin
Signed-off-by: zain wang
Signed-off-by: Caesar Wang
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 7 +-
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 30 -
drivers/gpu/drm/rockchip/rockchip_drm_psr.h | 4 ++--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4
4 files changed, 32 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 8548e8271639..28c0d4406454 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -159,12 +159,17 @@ static int rockchip_dp_poweron(struct
analogix_dp_plat_data *plat_data)
return ret;
}
- return 0;
+ return rockchip_drm_psr_activate(&dp->encoder);
}
static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
{
struct rockchip_dp_device *dp = to_dp(plat_data);
+ int ret;
+
+ ret = rockchip_drm_psr_deactivate(&dp->encoder);
+ if (ret != 0)
+ return ret;
clk_disable_unprepare(dp->pclk);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index a553e182ff53..4c379e90b178 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -57,6 +57,24 @@ static struct psr_drv *find_psr_by_crtc(struct drm_crtc
*crtc)
return psr;
}
+static struct psr_drv *find_psr_by_encoder(struct drm_encoder *encoder)
+{
+ struct rockchip_drm_private *drm_drv = encoder->dev->dev_private;
+ struct psr_drv *psr;
+ unsigned long flags;
+
+ spin_lock_irqsave(&drm_drv->psr_list_lock, flags);
+ list_for_each_entry(psr, &drm_drv->psr_list, list) {
+ if (psr->encoder == encoder)
+ goto out;
+ }
+ psr = ERR_PTR(-ENODEV);
+
+out:
+ spin_unlock_irqrestore(&drm_drv->psr_list_lock, flags);
+ return psr;
+}
+
static void psr_set_state_locked(struct psr_drv *psr, enum psr_state state)
{
/*
@@ -115,14 +133,14 @@ static void psr_flush_handler(unsigned long data)
/**
* rockchip_drm_psr_activate - activate PSR on the given pipe
- * @crtc: CRTC to obtain the PSR encoder
+ * @encoder: encoder to obtain the PSR encoder
*
* Returns:
* Zero on success, negative errno on failure.
*/
-int rockchip_drm_psr_activate(struct drm_crtc *crtc)
+int rockchip_drm_psr_activate(struct drm_encoder *encoder)
{
- struct psr_drv *psr = find_psr_by_crtc(crtc);
+ struct psr_drv *psr = find_psr_by_encoder(encoder);
unsigned long flags;
if (IS_ERR(psr))
@@ -138,14 +156,14 @@ EXPORT_SYMBOL(rockchip_drm_psr_activate);
/**
* rockchip_drm_psr_deactivate - deactivate PSR on the given pipe
- * @crtc: CRTC to obtain the PSR encoder
+ * @encoder: encoder to obtain the PSR encoder
*
* Returns:
* Zero on success, negative errno on failure.
*/
-int rockchip_drm_psr_deactivate(struct drm_crtc *crtc)
+int rockchip_drm_psr_deactivate(struct drm_encoder *encoder)
{
- struct psr_drv *psr = find_psr_by_crtc(crtc);
+ struct psr_drv *psr = find_psr_by_encoder(encoder);
unsigned long flags;
if (IS_ERR(psr))
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
index b420cf1bf902..b1ea0155e57c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.h
@@ -18,8 +18,8 @@
void rockchip_drm_psr_flush_all(struct drm_device *dev);
int rockchip_drm_psr_flush(struct drm_crtc *crtc);
-int rockchip_drm_psr_activate(struct drm_crtc *crtc);
-int rockchip_drm_psr_deactivate(struct drm_crtc *crtc);
+int rockchip_drm_psr_activate(struct drm_encoder *encoder);
+int rockchip_drm_psr_deactivate(struct drm_encoder *encoder);
int rockchip_drm_psr_register(struct drm_encoder *encoder,
void (*psr_set)(struct drm_encoder *, bool enable));
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 0539afb6b7c8..1c1e8535ad28 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -568,8 +568,6 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
WARN_ON(vop->event);
- rockchip_drm_psr_deactivate(&vop->crtc);
-
/*
* We need to make sure that all windows are disabled before we
* disable that crtc. Otherwise we might try to scan from a destroyed
@@ -981,8 +979,6 @
[PATCH 03/41] drm/rockchip: support prime import sg table
From: Haixia Shi
The prime fd to handle ioctl was not used with rockchip before. Support
was added in order to pass graphics_Gbm and to support potential uses
within Chrome OS (e.g. zero-copy video decode, camera).
Signed-off-by: Haixia Shi
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 118 ++--
drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 5 +-
3 files changed, 115 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index ccf456938792..1e371b7a1506 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -238,6 +238,7 @@ static struct drm_driver rockchip_drm_driver = {
.gem_prime_import = drm_gem_prime_import,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_get_sg_table = rockchip_gem_prime_get_sg_table,
+ .gem_prime_import_sg_table = rockchip_gem_prime_import_sg_table,
.gem_prime_vmap = rockchip_gem_prime_vmap,
.gem_prime_vunmap = rockchip_gem_prime_vunmap,
.gem_prime_mmap = rockchip_gem_mmap_buf,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index df9e57064f19..5dffe276d2a7 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -16,6 +16,8 @@
#include
#include
#include
+
+#include
#include
#include "rockchip_drm_drv.h"
@@ -308,12 +310,10 @@ static void rockchip_gem_release_object(struct
rockchip_gem_object *rk_obj)
}
struct rockchip_gem_object *
- rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
- bool alloc_kmap)
+ rockchip_gem_alloc_object(struct drm_device *drm, unsigned int size)
{
struct rockchip_gem_object *rk_obj;
struct drm_gem_object *obj;
- int ret;
size = round_up(size, PAGE_SIZE);
@@ -325,6 +325,20 @@ struct rockchip_gem_object *
drm_gem_object_init(drm, obj, size);
+ return rk_obj;
+}
+
+struct rockchip_gem_object *
+rockchip_gem_create_object(struct drm_device *drm, unsigned int size,
+ bool alloc_kmap)
+{
+ struct rockchip_gem_object *rk_obj;
+ int ret;
+
+ rk_obj = rockchip_gem_alloc_object(drm, size);
+ if (IS_ERR(rk_obj))
+ return rk_obj;
+
ret = rockchip_gem_alloc_buf(rk_obj, alloc_kmap);
if (ret)
goto err_free_rk_obj;
@@ -342,11 +356,21 @@ struct rockchip_gem_object *
*/
void rockchip_gem_free_object(struct drm_gem_object *obj)
{
- struct rockchip_gem_object *rk_obj;
-
- rk_obj = to_rockchip_obj(obj);
+ struct drm_device *drm = obj->dev;
+ struct rockchip_drm_private *private = drm->dev_private;
+ struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
- rockchip_gem_free_buf(rk_obj);
+ if (obj->import_attach) {
+ if (private->domain) {
+ rockchip_gem_iommu_unmap(rk_obj);
+ } else {
+ dma_unmap_sg(drm->dev, rk_obj->sgt->sgl,
+rk_obj->sgt->nents, DMA_BIDIRECTIONAL);
+ }
+ drm_prime_gem_destroy(obj, rk_obj->sgt);
+ } else {
+ rockchip_gem_free_buf(rk_obj);
+ }
rockchip_gem_release_object(rk_obj);
}
@@ -476,6 +500,86 @@ struct sg_table *rockchip_gem_prime_get_sg_table(struct
drm_gem_object *obj)
return sgt;
}
+static unsigned long rockchip_sg_get_contiguous_size(struct sg_table *sgt,
+int count)
+{
+ struct scatterlist *s;
+ dma_addr_t expected = sg_dma_address(sgt->sgl);
+ unsigned int i;
+ unsigned long size = 0;
+
+ for_each_sg(sgt->sgl, s, count, i) {
+ if (sg_dma_address(s) != expected)
+ break;
+ expected = sg_dma_address(s) + sg_dma_len(s);
+ size += sg_dma_len(s);
+ }
+ return size;
+}
+
+static int
+rockchip_gem_iommu_map_sg(struct drm_device *drm,
+ struct dma_buf_attachment *attach,
+ struct sg_table *sg,
+ struct rockchip_gem_object *rk_obj)
+{
+ rk_obj->sgt = sg;
+ return rockchip_gem_iommu_map(rk_obj);
+}
+
+static int
+rockchip_gem_dma_map_sg(struct drm_device *drm,
+ struct dma_buf_attachment *attach,
+ struct sg_table *sg,
+ struct rockchip_gem_object *rk_obj)
+{
+ int count = dma_map_sg(drm->dev, sg->sgl, sg->nents,
+ DMA_BIDIRECTIONAL);
+ if (!count)
+ return -EINVAL;
+
+ if (rockchip_sg_get_contiguous_size(sg, count) <
[PATCH 04/41] drm/rockchip: Respect page offset for PRIME mmap calls
From: Ørjan Eide When mapping external DMA-bufs through the PRIME mmap call, we might be given an offset which has to be respected. However for the internal DRM GEM mmap path, we have to ignore the fake mmap offset used to identify the buffer only. Currently the code always zeroes out vma->vm_pgoff, which breaks the former. This patch fixes the problem by moving the vm_pgoff assignment to a function that is used only for GEM mmap path, so that the PRIME path retains the original offset. BUG=chrome-os-partner:56615 TEST=graphics_GLBench Cc: Daniel Kurtz Signed-off-by: Ørjan Eide Signed-off-by: Tomasz Figa Signed-off-by: Sean Paul --- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c index 5dffe276d2a7..7fa2cb77bdc0 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c @@ -263,7 +263,6 @@ static int rockchip_drm_gem_object_mmap(struct drm_gem_object *obj, * VM_PFNMAP flag that was set by drm_gem_mmap_obj()/drm_gem_mmap(). */ vma->vm_flags &= ~VM_PFNMAP; - vma->vm_pgoff = 0; if (rk_obj->pages) ret = rockchip_drm_gem_object_mmap_iommu(obj, vma); @@ -298,6 +297,12 @@ int rockchip_gem_mmap(struct file *filp, struct vm_area_struct *vma) if (ret) return ret; + /* +* Set vm_pgoff (used as a fake buffer offset by DRM) to 0 and map the +* whole buffer from the start. +*/ + vma->vm_pgoff = 0; + obj = vma->vm_private_data; return rockchip_drm_gem_object_mmap(obj, vma); -- 2.12.0.246.ga2ecc84866-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/41] drm/rockchip: Get rid of some unnecessary code
From: Tomasz Figa
Current code implements prepare_fb and cleanup_fb callbacks only to
grab/release fb references, which is already done by atomic framework
when creating/destryoing plane state. Also there are some unused fields
vop and vop_win structs. Let's remove these unused bits.
Signed-off-by: Tomasz Figa
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 2151e1cee4b4..0539afb6b7c8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -108,9 +108,6 @@ struct vop {
struct drm_device *drm_dev;
bool is_enabled;
- /* mutex vsync_ work */
- struct mutex vsync_mutex;
- bool vsync_work_pending;
struct completion dsp_hold_completion;
/* protected by dev->event_lock */
@@ -1592,8 +1589,6 @@ static int vop_bind(struct device *dev, struct device
*master, void *data)
spin_lock_init(&vop->reg_lock);
spin_lock_init(&vop->irq_lock);
- mutex_init(&vop->vsync_mutex);
-
ret = devm_request_irq(dev, vop->irq, vop_isr,
IRQF_SHARED, dev_name(dev), vop);
if (ret)
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/41] drm/bridge: analogix_dp: Don't power bridge in analogix_dp_bind
From: zain wang The bridge does not need to be powered in analogix_dp_bind(), so remove the calls to pm_runtime_get()/phy_power_on()/analogix_dp_init_dp() as well as their power-off counterparts. Cc: Stéphane Marchesin Signed-off-by: zain wang Signed-off-by: Caesar Wang [the patch originally just removed the power_on portion, seanpaul removed the power off code as well as improved the commit message] Signed-off-by: Sean Paul --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index c26997afd3cf..f64592f52262 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -1385,11 +1385,6 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev, pm_runtime_enable(dev); - pm_runtime_get_sync(dev); - phy_power_on(dp->phy); - - analogix_dp_init_dp(dp); - ret = devm_request_threaded_irq(&pdev->dev, dp->irq, analogix_dp_hardirq, analogix_dp_irq_thread, @@ -1418,15 +1413,10 @@ int analogix_dp_bind(struct device *dev, struct drm_device *drm_dev, goto err_disable_pm_runtime; } - phy_power_off(dp->phy); - pm_runtime_put(dev); - return 0; err_disable_pm_runtime: - phy_power_off(dp->phy); - pm_runtime_put(dev); pm_runtime_disable(dev); return ret; -- 2.12.0.246.ga2ecc84866-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 41/41] drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip
From: Douglas Anderson The comments in analogix_dp_init_aux() claim that we're disabling aux channel retries, but then right below it for Rockchip it sets them to 3. If we actually need 3 retries for Rockchip then we could adjust the comment, but it seems more likely that we want the same retry behavior across all platforms. Cc: Stéphane Marchesin Cc: 征增 王 Signed-off-by: Douglas Anderson Signed-off-by: Sean Paul --- drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c index 29d130222636..57dd1991d7de 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c @@ -480,15 +480,16 @@ void analogix_dp_init_aux(struct analogix_dp_device *dp) analogix_dp_reset_aux(dp); - /* Disable AUX transaction H/W retry */ + /* AUX_BIT_PERIOD_EXPECTED_DELAY doesn't apply to Rockchip IP */ if (dp->plat_data && is_rockchip(dp->plat_data->dev_type)) - reg = AUX_BIT_PERIOD_EXPECTED_DELAY(0) | - AUX_HW_RETRY_COUNT_SEL(3) | - AUX_HW_RETRY_INTERVAL_600_MICROSECONDS; + reg = 0; else - reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3) | - AUX_HW_RETRY_COUNT_SEL(0) | - AUX_HW_RETRY_INTERVAL_600_MICROSECONDS; + reg = AUX_BIT_PERIOD_EXPECTED_DELAY(3); + + /* Disable AUX transaction H/W retry */ + reg |= AUX_HW_RETRY_COUNT_SEL(0) | + AUX_HW_RETRY_INTERVAL_600_MICROSECONDS; + writel(reg, dp->reg_base + ANALOGIX_DP_AUX_HW_RETRY_CTL); /* Receive AUX Channel DEFER commands equal to DEFFER_COUNT*64 */ -- 2.12.0.246.ga2ecc84866-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 20/41] drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy
From: zain wang
Following the correct power up sequence:
dp_pd=ff => dp_pd=7f => wait 10us => dp_pd=00
Cc: Stéphane Marchesin
Signed-off-by: zain wang
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 3 +++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index b47c5af43560..bb72f8b0e603 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -321,10 +321,16 @@ void analogix_dp_set_analog_power_down(struct
analogix_dp_device *dp,
break;
case POWER_ALL:
if (enable) {
- reg = DP_PHY_PD | AUX_PD | CH3_PD | CH2_PD |
- CH1_PD | CH0_PD;
+ reg = DP_ALL_PD;
writel(reg, dp->reg_base + phy_pd_addr);
} else {
+ reg = DP_ALL_PD;
+ writel(reg, dp->reg_base + phy_pd_addr);
+ usleep_range(10, 15);
+ reg &= ~DP_INC_BG;
+ writel(reg, dp->reg_base + phy_pd_addr);
+ usleep_range(10, 15);
+
writel(0x00, dp->reg_base + phy_pd_addr);
}
break;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 40200c652533..9602668669f4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -342,12 +342,15 @@
#define DP_PLL_REF_BIT_1_2500V (0x7 << 0)
/* ANALOGIX_DP_PHY_PD */
+#define DP_INC_BG (0x1 << 7)
+#define DP_EXP_BG (0x1 << 6)
#define DP_PHY_PD (0x1 << 5)
#define AUX_PD (0x1 << 4)
#define CH3_PD (0x1 << 3)
#define CH2_PD (0x1 << 2)
#define CH1_PD (0x1 << 1)
#define CH0_PD (0x1 << 0)
+#define DP_ALL_PD (0xff)
/* ANALOGIX_DP_PHY_TEST */
#define MACRO_RST (0x1 << 5)
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/41] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR
From: Yakir Yang
Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
function, or print the sink PSR error state if we failed to apply the
requested PSR setting.
Cc: 征增 王
Cc: Stéphane Marchesin
Signed-off-by: Yakir Yang
[seanpaul changed timeout loop to a readx poll]
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 6 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 35 +++---
3 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f64592f52262..8a8f05fe9da3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -124,8 +124,7 @@ int analogix_dp_enable_psr(struct device *dev)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
- analogix_dp_send_psr_spd(dp, &psr_vsc);
- return 0;
+ return analogix_dp_send_psr_spd(dp, &psr_vsc);
}
EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
@@ -152,8 +151,7 @@ int analogix_dp_disable_psr(struct device *dev)
if (ret != 1)
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
- analogix_dp_send_psr_spd(dp, &psr_vsc);
- return 0;
+ return analogix_dp_send_psr_spd(dp, &psr_vsc);
}
EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 5c6a28806129..b039b28d8fcc 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,8 @@
#define MAX_CR_LOOP 5
#define MAX_EQ_LOOP 5
+#define DP_TIMEOUT_PSR_LOOP_MS 300
+
/* DP_MAX_LANE_COUNT */
#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
@@ -247,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct
analogix_dp_device *dp);
void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc);
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc);
ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
struct drm_dp_aux_msg *msg);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 303083ad28e3..005a3f7005d2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -10,10 +10,11 @@
* option) any later version.
*/
-#include
-#include
#include
+#include
#include
+#include
+#include
#include
@@ -992,10 +993,25 @@ void analogix_dp_enable_psr_crc(struct analogix_dp_device
*dp)
writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
}
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc)
+static ssize_t analogix_dp_get_psr_status(struct analogix_dp_device *dp)
+{
+ ssize_t val;
+ u8 status;
+
+ val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &status);
+ if (val < 0) {
+ dev_err(dp->dev, "PSR_STATUS read failed ret=%zd", val);
+ return val;
+ }
+ return status;
+}
+
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc)
{
unsigned int val;
+ int ret;
+ ssize_t psr_status;
/* don't send info frame */
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
@@ -1036,6 +1052,17 @@ void analogix_dp_send_psr_spd(struct analogix_dp_device
*dp,
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+
+ ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
+ psr_status >= 0 &&
+ ((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
+ (!vsc->DB1 && psr_status == DP_PSR_SINK_INACTIVE)), 1500,
+ DP_TIMEOUT_PSR_LOOP_MS * 1000);
+ if (ret) {
+ dev_warn(dp->dev, "Failed to apply PSR %d\n", ret);
+ return ret;
+ }
+ return 0;
}
ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-d
[PATCH 07/41] drm/rockchip: Don't use atomic constructs for psr
Instead of using timer and spinlocks, use delayed_work and
mutexes for rockchip psr. This allows us to make blocking
calls when enabling/disabling psr (which is sort of important
given we're talking over dpcd to the display).
Cc: Caesar Wang
Cc: 征增 王
Cc: Stéphane Marchesin
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 14 +++--
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 68 +++--
4 files changed, 37 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 28c0d4406454..90eb7908e2e5 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -72,7 +72,7 @@ struct rockchip_dp_device {
struct reset_control *rst;
struct work_struct psr_work;
- spinlock_t psr_lock;
+ struct mutex psr_lock;
unsigned int psr_state;
const struct rockchip_dp_chip_data *data;
@@ -83,21 +83,20 @@ struct rockchip_dp_device {
static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
{
struct rockchip_dp_device *dp = to_dp(encoder);
- unsigned long flags;
if (!analogix_dp_psr_supported(dp->dev))
return;
dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
- spin_lock_irqsave(&dp->psr_lock, flags);
+ mutex_lock(&dp->psr_lock);
if (enabled)
dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
else
dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
schedule_work(&dp->psr_work);
- spin_unlock_irqrestore(&dp->psr_lock, flags);
+ mutex_unlock(&dp->psr_lock);
}
static void analogix_dp_psr_work(struct work_struct *work)
@@ -108,7 +107,6 @@ static void analogix_dp_psr_work(struct work_struct *work)
int psr_state = dp->psr_state;
int vact_end;
int ret;
- unsigned long flags;
if (!crtc)
return;
@@ -122,12 +120,12 @@ static void analogix_dp_psr_work(struct work_struct *work)
return;
}
- spin_lock_irqsave(&dp->psr_lock, flags);
+ mutex_lock(&dp->psr_lock);
if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
analogix_dp_enable_psr(dp->dev);
else
analogix_dp_disable_psr(dp->dev);
- spin_unlock_irqrestore(&dp->psr_lock, flags);
+ mutex_unlock(&dp->psr_lock);
}
static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
@@ -406,7 +404,7 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;
- spin_lock_init(&dp->psr_lock);
+ mutex_init(&dp->psr_lock);
dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
INIT_WORK(&dp->psr_work, analogix_dp_psr_work);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 1e371b7a1506..6b767b8dabd5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -134,7 +134,7 @@ static int rockchip_drm_bind(struct device *dev)
drm_dev->dev_private = private;
INIT_LIST_HEAD(&private->psr_list);
- spin_lock_init(&private->psr_list_lock);
+ mutex_init(&private->psr_list_lock);
drm_mode_config_init(drm_dev);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 8aca219ec4c8..1844951118da 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -55,7 +55,7 @@ struct rockchip_drm_private {
struct mutex mm_lock;
struct drm_mm mm;
struct list_head psr_list;
- spinlock_t psr_list_lock;
+ struct mutex psr_list_lock;
};
int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
index 4c379e90b178..b339ca943139 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
@@ -18,7 +18,7 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_psr.h"
-#define PSR_FLUSH_TIMEOUT msecs_to_jiffies(100)
+#define PSR_FLUSH_TIMEOUT_MS 100
enum psr_state {
PSR_FLUSH,
@@ -30,11 +30,11 @@ struct psr_drv {
struct list_headlist;
struct drm_encoder *encoder;
- spinlock_t lock;
+ struct mutexlock;
boolactive;
enum psr_state state;
- struct timer_list flush_timer;
+ struct delayed_work flush_wo
[PATCH 11/41] drm/rockchip: add mutex vop lock
From: zain wang
Add a lock to vop to avoid disabling the crtc while waiting for a line
flag while enabling psr. If we disable in the middle of waiting for the
line flag, we'll end up timing out or worse.
Signed-off-by: zain wang
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 30 +++--
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 1c1e8535ad28..aa5c528c59fc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -130,6 +130,7 @@ struct vop {
spinlock_t reg_lock;
/* lock vop irq reg */
spinlock_t irq_lock;
+ struct mutex vop_lock;
unsigned int irq;
@@ -568,6 +569,7 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
WARN_ON(vop->event);
+ mutex_lock(&vop->vop_lock);
/*
* We need to make sure that all windows are disabled before we
* disable that crtc. Otherwise we might try to scan from a destroyed
@@ -619,6 +621,7 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
clk_disable(vop->aclk);
clk_disable(vop->hclk);
pm_runtime_put(vop->dev);
+ mutex_unlock(&vop->vop_lock);
if (crtc->state->event && !crtc->state->active) {
spin_lock_irq(&crtc->dev->event_lock);
@@ -885,10 +888,13 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
uint32_t pin_pol, val;
int ret;
+ mutex_lock(&vop->vop_lock);
+
WARN_ON(vop->event);
ret = vop_enable(crtc);
if (ret) {
+ mutex_unlock(&vop->vop_lock);
DRM_DEV_ERROR(vop->dev, "Failed to enable vop (%d)\n", ret);
return;
}
@@ -979,6 +985,7 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
VOP_CTRL_SET(vop, standby, 0);
+ mutex_unlock(&vop->vop_lock);
}
static bool vop_fs_irq_is_pending(struct vop *vop)
@@ -1506,15 +1513,22 @@ int rockchip_drm_wait_line_flag(struct drm_crtc *crtc,
unsigned int line_num,
{
struct vop *vop = to_vop(crtc);
unsigned long jiffies_left;
+ int ret = 0;
if (!crtc || !vop->is_enabled)
return -ENODEV;
- if (line_num > crtc->mode.vtotal || mstimeout <= 0)
- return -EINVAL;
+ mutex_lock(&vop->vop_lock);
+
+ if (line_num > crtc->mode.vtotal || mstimeout <= 0) {
+ ret = -EINVAL;
+ goto out;
+ }
- if (vop_line_flag_irq_is_enabled(vop))
- return -EBUSY;
+ if (vop_line_flag_irq_is_enabled(vop)) {
+ ret = -EBUSY;
+ goto out;
+ }
reinit_completion(&vop->line_flag_completion);
vop_line_flag_irq_enable(vop, line_num);
@@ -1525,10 +1539,13 @@ int rockchip_drm_wait_line_flag(struct drm_crtc *crtc,
unsigned int line_num,
if (jiffies_left == 0) {
dev_err(vop->dev, "Timeout waiting for IRQ\n");
- return -ETIMEDOUT;
+ ret = -ETIMEDOUT;
+ goto out;
}
- return 0;
+out:
+ mutex_unlock(&vop->vop_lock);
+ return ret;
}
EXPORT_SYMBOL(rockchip_drm_wait_line_flag);
@@ -1584,6 +1601,7 @@ static int vop_bind(struct device *dev, struct device
*master, void *data)
spin_lock_init(&vop->reg_lock);
spin_lock_init(&vop->irq_lock);
+ mutex_init(&vop->vop_lock);
ret = devm_request_irq(dev, vop->irq, vop_isr,
IRQF_SHARED, dev_name(dev), vop);
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/41] drm/bridge: analogix_dp: Move enable video into config_video()
From: Lin Huang
We need to enable video before analogix_dp_is_video_stream_on(), so
we can get the right video stream status.
Cc: 征增 王
Cc: Stéphane Marchesin
Signed-off-by: Lin Huang
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 9dfa1b507389..52218d743059 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -823,11 +823,10 @@ static int analogix_dp_config_video(struct
analogix_dp_device *dp)
if (analogix_dp_is_slave_video_stream_clock_on(dp) == 0)
break;
if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
- dev_err(dp->dev, "Timeout of video streamclk ok\n");
+ dev_err(dp->dev, "Timeout of slave video streamclk
ok\n");
return -ETIMEDOUT;
}
-
- usleep_range(1, 2);
+ usleep_range(1000, 1001);
}
/* Set to use the register calculated M/N video */
@@ -842,6 +841,9 @@ static int analogix_dp_config_video(struct
analogix_dp_device *dp)
/* Configure video slave mode */
analogix_dp_enable_video_master(dp, 0);
+ /* Enable video */
+ analogix_dp_start_video(dp);
+
timeout_loop = 0;
for (;;) {
@@ -955,9 +957,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to enable the panel\n");
}
- /* Enable video */
- analogix_dp_start_video(dp);
-
dp->psr_enable = analogix_dp_detect_sink_psr(dp);
if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/41] drm/bridge: analogix_dp: Don't change psr while bridge is disabled
From: zain wang
There is a race between AUX CH bring-up and enabling bridge which will
cause link training to fail. To avoid hitting it, don't change psr state
while enabling the bridge.
Cc: Tomeu Vizoso
Cc: Sean Paul
Signed-off-by: zain wang
Signed-off-by: Caesar Wang
[seanpaul fixed up the commit message a bit and renamed *_supported to
*_enabled]
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 15 ---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c| 2 +-
include/drm/bridge/analogix_dp.h | 2 +-
4 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 8a8f05fe9da3..64d94a34874d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -98,20 +98,20 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
*dp)
return 0;
}
-int analogix_dp_psr_supported(struct device *dev)
+int analogix_dp_psr_enabled(struct device *dev)
{
struct analogix_dp_device *dp = dev_get_drvdata(dev);
- return dp->psr_support;
+ return dp->psr_enable;
}
-EXPORT_SYMBOL_GPL(analogix_dp_psr_supported);
+EXPORT_SYMBOL_GPL(analogix_dp_psr_enabled);
int analogix_dp_enable_psr(struct device *dev)
{
struct analogix_dp_device *dp = dev_get_drvdata(dev);
struct edp_vsc_psr psr_vsc;
- if (!dp->psr_support)
+ if (!dp->psr_enable)
return 0;
/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
@@ -134,7 +134,7 @@ int analogix_dp_disable_psr(struct device *dev)
struct edp_vsc_psr psr_vsc;
int ret;
- if (!dp->psr_support)
+ if (!dp->psr_enable)
return 0;
/* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
@@ -878,8 +878,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
/* Enable video */
analogix_dp_start_video(dp);
- dp->psr_support = analogix_dp_detect_sink_psr(dp);
- if (dp->psr_support)
+ dp->psr_enable = analogix_dp_detect_sink_psr(dp);
+ if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
}
@@ -1120,6 +1120,7 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
if (ret)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
+ dp->psr_enable = false;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index b039b28d8fcc..e135a42cb19e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -170,7 +170,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolforce_hpd;
- boolpsr_support;
+ boolpsr_enable;
struct mutexpanel_lock;
boolpanel_is_modeset;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 64e7e2c0bc58..f44756029478 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -83,7 +83,7 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder,
bool enabled)
int vact_end;
int ret;
- if (!analogix_dp_psr_supported(dp->dev))
+ if (!analogix_dp_psr_enabled(dp->dev))
return;
dev_dbg(dp->dev, "%s PSR...\n", enabled ? "enable" : "disable");
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index c99d6eaef1ac..4fc0165ed3f5 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -38,7 +38,7 @@ struct analogix_dp_plat_data {
struct drm_connector *);
};
-int analogix_dp_psr_supported(struct device *dev);
+int analogix_dp_psr_enabled(struct device *dev);
int analogix_dp_enable_psr(struct device *dev);
int analogix_dp_disable_psr(struct device *dev);
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 25/41] drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip
From: zain wang
There some different bit between Rockchip and Exynos in register "AUX_PD",
So let's fix the incorrect operations about it.
Cc: Douglas Anderson
Signed-off-by: zain wang
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 116 --
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 2 +
2 files changed, 64 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index bb72f8b0e603..377bee4e20fd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -248,76 +248,84 @@ void analogix_dp_set_analog_power_down(struct
analogix_dp_device *dp,
{
u32 reg;
u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+ u32 mask;
if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
phy_pd_addr = ANALOGIX_DP_PD;
switch (block) {
case AUX_BLOCK:
- if (enable) {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg |= AUX_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- } else {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg &= ~AUX_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- }
+ if (dp->plat_data && is_rockchip(dp->plat_data->dev_type))
+ mask = RK_AUX_PD;
+ else
+ mask = AUX_PD;
+
+ reg = readl(dp->reg_base + phy_pd_addr);
+ if (enable)
+ reg |= mask;
+ else
+ reg &= ~mask;
+ writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH0_BLOCK:
- if (enable) {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg |= CH0_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- } else {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg &= ~CH0_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- }
+ mask = CH0_PD;
+ reg = readl(dp->reg_base + phy_pd_addr);
+
+ if (enable)
+ reg |= mask;
+ else
+ reg &= ~mask;
+ writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH1_BLOCK:
- if (enable) {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg |= CH1_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- } else {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg &= ~CH1_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- }
+ mask = CH1_PD;
+ reg = readl(dp->reg_base + phy_pd_addr);
+
+ if (enable)
+ reg |= mask;
+ else
+ reg &= ~mask;
+ writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH2_BLOCK:
- if (enable) {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg |= CH2_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- } else {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg &= ~CH2_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- }
+ mask = CH2_PD;
+ reg = readl(dp->reg_base + phy_pd_addr);
+
+ if (enable)
+ reg |= mask;
+ else
+ reg &= ~mask;
+ writel(reg, dp->reg_base + phy_pd_addr);
break;
case CH3_BLOCK:
- if (enable) {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg |= CH3_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- } else {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg &= ~CH3_PD;
- writel(reg, dp->reg_base + phy_pd_addr);
- }
+ mask = CH3_PD;
+ reg = readl(dp->reg_base + phy_pd_addr);
+
+ if (enable)
+ reg |= mask;
+ else
+ reg &= ~mask;
+ writel(reg, dp->reg_base + phy_pd_addr);
break;
case ANALOG_TOTAL:
- if (enable) {
- reg = readl(dp->reg_base + phy_pd_addr);
- reg |= DP_PHY_PD;
-
[PATCH 21/41] drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the panel
From: Lin Huang
When panel is shut down, we should make sure edp can be disabled to avoid
undefined behavior.
Cc: Stéphane Marchesin
Signed-off-by: Lin Huang
Signed-off-by: zain wang
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 048b6f7c9b6e..3b2d53935ae9 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1163,6 +1163,12 @@ static int analogix_dp_set_bridge(struct
analogix_dp_device *dp)
pm_runtime_get_sync(dp->dev);
+ ret = clk_prepare_enable(dp->clock);
+ if (ret < 0) {
+ DRM_ERROR("Failed to prepare_enable the clock clk [%d]\n", ret);
+ goto out_dp_clk_pre;
+ }
+
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
@@ -1192,6 +1198,8 @@ static int analogix_dp_set_bridge(struct
analogix_dp_device *dp)
phy_power_off(dp->phy);
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
+ clk_disable_unprepare(dp->clock);
+out_dp_clk_pre:
pm_runtime_put_sync(dp->dev);
return ret;
@@ -1235,10 +1243,13 @@ static void analogix_dp_bridge_disable(struct
drm_bridge *bridge)
disable_irq(dp->irq);
phy_power_off(dp->phy);
+ analogix_dp_set_analog_power_down(dp, POWER_ALL, 1);
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
+ clk_disable_unprepare(dp->clock);
+
pm_runtime_put_sync(dp->dev);
ret = analogix_dp_prepare_panel(dp, false, true);
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/41] drm/bridge: analogix_dp: add fast link train for eDP
From: zain wang
We would meet a short black screen when exit PSR with the full link
training, In this case, we should use fast link train instead of full
link training.
Signed-off-by: zain wang
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 142 -
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 3 +
2 files changed, 114 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 64d94a34874d..5bc151b0995b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -10,17 +10,18 @@
* option) any later version.
*/
-#include
-#include
-#include
#include
-#include
+#include
+#include
+#include
#include
+#include
+#include
+#include
#include
#include
-#include
-#include
#include
+#include
#include
#include
@@ -35,6 +36,8 @@
#define to_dp(nm) container_of(nm, struct analogix_dp_device, nm)
+static const bool verify_fast_training;
+
struct bridge_init {
struct i2c_client *client;
struct device_node *node;
@@ -531,7 +534,7 @@ static int analogix_dp_process_equalizer_training(struct
analogix_dp_device *dp)
{
int lane, lane_count, retval;
u32 reg;
- u8 link_align, link_status[2], adjust_request[2];
+ u8 link_align, link_status[2], adjust_request[2], spread;
usleep_range(400, 401);
@@ -574,6 +577,20 @@ static int analogix_dp_process_equalizer_training(struct
analogix_dp_device *dp)
dev_dbg(dp->dev, "final lane count = %.2x\n",
dp->link_train.lane_count);
+ retval = drm_dp_dpcd_readb(&dp->aux, DP_MAX_DOWNSPREAD,
+ &spread);
+ if (retval != 1) {
+ dev_err(dp->dev, "failed to read downspread %d\n",
+ retval);
+ dp->fast_train_support = false;
+ } else {
+ dp->fast_train_support =
+ (spread & DP_NO_AUX_HANDSHAKE_LINK_TRAINING) ?
+ true : false;
+ }
+ dev_dbg(dp->dev, "fast link training %s\n",
+ dp->fast_train_support ? "supported" : "unsupported");
+
/* set enhanced mode if available */
analogix_dp_set_enhanced_mode(dp);
dp->link_train.lt_state = FINISHED;
@@ -630,10 +647,12 @@ static void analogix_dp_get_max_rx_lane_count(struct
analogix_dp_device *dp,
*lane_count = DPCD_MAX_LANE_COUNT(data);
}
-static void analogix_dp_init_training(struct analogix_dp_device *dp,
- enum link_lane_count_type max_lane,
- int max_rate)
+static int analogix_dp_full_link_train(struct analogix_dp_device *dp,
+ u32 max_lanes, u32 max_rate)
{
+ int retval = 0;
+ bool training_finished = false;
+
/*
* MACRO_RST must be applied after the PLL_LOCK to avoid
* the DP inter pair skew issue for at least 10 us
@@ -659,18 +678,13 @@ static void analogix_dp_init_training(struct
analogix_dp_device *dp,
}
/* Setup TX lane count & rate */
- if (dp->link_train.lane_count > max_lane)
- dp->link_train.lane_count = max_lane;
+ if (dp->link_train.lane_count > max_lanes)
+ dp->link_train.lane_count = max_lanes;
if (dp->link_train.link_rate > max_rate)
dp->link_train.link_rate = max_rate;
/* All DP analog module power up */
analogix_dp_set_analog_power_down(dp, POWER_ALL, 0);
-}
-
-static int analogix_dp_sw_link_training(struct analogix_dp_device *dp)
-{
- int retval = 0, training_finished = 0;
dp->link_train.lt_state = START;
@@ -705,22 +719,88 @@ static int analogix_dp_sw_link_training(struct
analogix_dp_device *dp)
return retval;
}
-static int analogix_dp_set_link_train(struct analogix_dp_device *dp,
- u32 count, u32 bwtype)
+static int analogix_dp_fast_link_train(struct analogix_dp_device *dp)
{
- int i;
- int retval;
+ int i, ret;
+ u8 link_align, link_status[2];
+ enum pll_status status;
- for (i = 0; i < DP_TIMEOUT_LOOP_COUNT; i++) {
- analogix_dp_init_training(dp, count, bwtype);
- retval = analogix_dp_sw_link_training(dp);
- if (retval == 0)
- break;
+ analogix_dp_reset_macro(dp);
- usleep_range(100, 110);
+ analogix_dp_set_link_bandwidth(dp, dp->link_train.link_rate);
+ analogix_dp_set_lane_count(dp, dp->link_train.lane_count);
+
+ for (i = 0; i < dp->link_train.lane_count; i++) {
+
[PATCH 22/41] drm/bridge: analogix_dp: Extend hpd check time to 100ms
From: Lin Huang We only allocated 1ms to detect the hpd signal before, it too short to detect a short pulse (hpd signal), extend it to 100ms. Cc: Stéphane Marchesin Cc: 征增 王 Signed-off-by: Lin Huang Signed-off-by: Sean Paul --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 3b2d53935ae9..043641aa0a6f 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -76,7 +76,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device *dp) return 0; timeout_loop++; - usleep_range(10, 11); + usleep_range(1000, 1100); } /* -- 2.12.0.246.ga2ecc84866-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/41] drm/bridge: analogix_dp: Wait for HPD signal before configuring link
From: zain wang
According to DP spec v1.3 chap 3.5.1.2 Link Training, Link Policy Maker
must first detect that the HPD signal is asserted high by the Downstream
Device before establishing a link with it.
Cc: Stéphane Marchesin
Signed-off-by: zain wang
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f3eea7636a2e..048b6f7c9b6e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1172,6 +1172,15 @@ static int analogix_dp_set_bridge(struct
analogix_dp_device *dp)
if (ret)
goto out_dp_init;
+ /* According to DP spec v1.3 chap 3.5.1.2 Link Training,
+* We should first make sure the HPD signal is asserted high by device
+* when we want to establish a link with it. */
+ ret = analogix_dp_detect_hpd(dp);
+ if (ret) {
+ DRM_ERROR("failed to get hpd single ret = %d\n", ret);
+ goto out_dp_init;
+ }
+
ret = analogix_dp_commit(dp);
if (ret)
goto out_dp_init;
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/41] drm/rockchip: Remove analogix psr worker
Now that the spinlocks and timers are gone, we can remove the psr
worker located in rockchip's analogix driver and do the enable/disable
directly. This should simplify the code and remove races on disable.
Cc: 征增 王
Cc: Stéphane Marchesin
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 38 -
1 file changed, 5 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 90eb7908e2e5..64e7e2c0bc58 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -71,10 +71,6 @@ struct rockchip_dp_device {
struct regmap*grf;
struct reset_control *rst;
- struct work_struct psr_work;
- struct mutex psr_lock;
- unsigned int psr_state;
-
const struct rockchip_dp_chip_data *data;
struct analogix_dp_plat_data plat_data;
@@ -83,30 +79,14 @@ struct rockchip_dp_device {
static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
{
struct rockchip_dp_device *dp = to_dp(encoder);
+ struct drm_crtc *crtc = dp->encoder.crtc;
+ int vact_end;
+ int ret;
if (!analogix_dp_psr_supported(dp->dev))
return;
- dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
-
- mutex_lock(&dp->psr_lock);
- if (enabled)
- dp->psr_state = EDP_VSC_PSR_STATE_ACTIVE;
- else
- dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
-
- schedule_work(&dp->psr_work);
- mutex_unlock(&dp->psr_lock);
-}
-
-static void analogix_dp_psr_work(struct work_struct *work)
-{
- struct rockchip_dp_device *dp =
- container_of(work, typeof(*dp), psr_work);
- struct drm_crtc *crtc = dp->encoder.crtc;
- int psr_state = dp->psr_state;
- int vact_end;
- int ret;
+ dev_dbg(dp->dev, "%s PSR...\n", enabled ? "enable" : "disable");
if (!crtc)
return;
@@ -120,12 +100,10 @@ static void analogix_dp_psr_work(struct work_struct *work)
return;
}
- mutex_lock(&dp->psr_lock);
- if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
+ if (enabled)
analogix_dp_enable_psr(dp->dev);
else
analogix_dp_disable_psr(dp->dev);
- mutex_unlock(&dp->psr_lock);
}
static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
@@ -142,8 +120,6 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data
*plat_data)
struct rockchip_dp_device *dp = to_dp(plat_data);
int ret;
- cancel_work_sync(&dp->psr_work);
-
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
dev_err(dp->dev, "failed to enable pclk %d\n", ret);
@@ -404,10 +380,6 @@ static int rockchip_dp_bind(struct device *dev, struct
device *master,
dp->plat_data.power_off = rockchip_dp_powerdown;
dp->plat_data.get_modes = rockchip_dp_get_modes;
- mutex_init(&dp->psr_lock);
- dp->psr_state = ~EDP_VSC_PSR_STATE_ACTIVE;
- INIT_WORK(&dp->psr_work, analogix_dp_psr_work);
-
rockchip_drm_psr_register(&dp->encoder, analogix_dp_psr_set);
return analogix_dp_bind(dev, dp->drm_dev, &dp->plat_data);
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/41] drm/bridge: analogix_dp: Retry bridge enable when it failed
From: zain wang
When we enable bridge failed, we have to retry it, otherwise we would get
the abnormal display.
Cc: Stéphane Marchesin
Signed-off-by: zain wang
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 65 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 3 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 5 +-
3 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 919ae68e7670..f3eea7636a2e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -43,8 +43,10 @@ struct bridge_init {
struct device_node *node;
};
-static void analogix_dp_init_dp(struct analogix_dp_device *dp)
+static int analogix_dp_init_dp(struct analogix_dp_device *dp)
{
+ int ret;
+
analogix_dp_reset(dp);
analogix_dp_swreset(dp);
@@ -56,10 +58,13 @@ static void analogix_dp_init_dp(struct analogix_dp_device
*dp)
analogix_dp_enable_sw_function(dp);
analogix_dp_config_interrupt(dp);
- analogix_dp_init_analog_func(dp);
+ ret = analogix_dp_init_analog_func(dp);
+ if (ret)
+ return ret;
analogix_dp_init_hpd(dp);
analogix_dp_init_aux(dp);
+ return 0;
}
static int analogix_dp_detect_hpd(struct analogix_dp_device *dp)
@@ -925,7 +930,7 @@ static irqreturn_t analogix_dp_irq_thread(int irq, void
*arg)
return IRQ_HANDLED;
}
-static void analogix_dp_commit(struct analogix_dp_device *dp)
+static int analogix_dp_commit(struct analogix_dp_device *dp)
{
int ret;
@@ -935,11 +940,10 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = readx_poll_timeout(analogix_dp_train_link, dp, ret, !ret, 100,
-DP_TIMEOUT_TRAINING_US * 5);
+ ret = analogix_dp_train_link(dp);
if (ret) {
dev_err(dp->dev, "unable to do link train, ret=%d\n", ret);
- return;
+ return ret;
}
analogix_dp_enable_scramble(dp, 1);
@@ -960,6 +964,7 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
dp->psr_enable = analogix_dp_detect_sink_psr(dp);
if (dp->psr_enable)
analogix_dp_enable_sink_psr(dp);
+ return 0;
}
/*
@@ -1152,12 +1157,9 @@ static void analogix_dp_bridge_pre_enable(struct
drm_bridge *bridge)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
}
-static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
+static int analogix_dp_set_bridge(struct analogix_dp_device *dp)
{
- struct analogix_dp_device *dp = bridge->driver_private;
-
- if (dp->dpms_mode == DRM_MODE_DPMS_ON)
- return;
+ int ret;
pm_runtime_get_sync(dp->dev);
@@ -1165,11 +1167,46 @@ static void analogix_dp_bridge_enable(struct drm_bridge
*bridge)
dp->plat_data->power_on(dp->plat_data);
phy_power_on(dp->phy);
- analogix_dp_init_dp(dp);
+
+ ret = analogix_dp_init_dp(dp);
+ if (ret)
+ goto out_dp_init;
+
+ ret = analogix_dp_commit(dp);
+ if (ret)
+ goto out_dp_init;
+
enable_irq(dp->irq);
- analogix_dp_commit(dp);
+ return 0;
- dp->dpms_mode = DRM_MODE_DPMS_ON;
+out_dp_init:
+ phy_power_off(dp->phy);
+ if (dp->plat_data->power_off)
+ dp->plat_data->power_off(dp->plat_data);
+ pm_runtime_put_sync(dp->dev);
+
+ return ret;
+}
+
+static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
+{
+ struct analogix_dp_device *dp = bridge->driver_private;
+ int timeout_loop = 0;
+
+ if (dp->dpms_mode == DRM_MODE_DPMS_ON)
+ return;
+
+ while (timeout_loop < MAX_PLL_LOCK_LOOP) {
+ if (analogix_dp_set_bridge(dp) == 0) {
+ dp->dpms_mode = DRM_MODE_DPMS_ON;
+ return;
+ }
+ dev_err(dp->dev, "failed to set bridge, retry: %d\n",
+ timeout_loop);
+ timeout_loop++;
+ usleep_range(10, 11);
+ }
+ dev_err(dp->dev, "too many times retry set bridge, give it up\n");
}
static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 403ff853464b..769255dc6e99 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -19,6 +19,7 @@
#define DP_TIMEOUT_LOOP_COUNT 100
#define MAX_CR_LOOP 5
#define MAX_EQ_LOOP 5
+#define MAX_PLL_LOCK_LOOP 5
/* Training takes 22ms if AUX channel comm
[PATCH 13/41] drm/rockchip: pre dither down when output bpc is 8bit
From: Mark Yao
Some encoder have a crc verification check, crc check fail if
input and output data is not equal.
That means encoder input and output need use same color depth,
vop can output 10bit data to encoder, but some panel only support
8bit depth, that would make crc check die.
So pre dither down vop data to 8bit if panel's bpc is 8.
Signed-off-by: Mark Yao
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 4
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 6 --
5 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index f44756029478..b6c6d6d09d7e 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -225,6 +225,7 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder
*encoder,
{
struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
struct rockchip_dp_device *dp = to_dp(encoder);
+ struct drm_display_info *di = &conn_state->connector->display_info;
int ret;
/*
@@ -248,6 +249,9 @@ rockchip_dp_drm_encoder_atomic_check(struct drm_encoder
*encoder,
s->output_mode = ROCKCHIP_OUT_MODE_P888;
}
+ s->output_bpc = di->bpc;
+ s->output_type = DRM_MODE_CONNECTOR_eDP;
+
return 0;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 1844951118da..a966d1d37378 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -36,6 +36,7 @@ struct rockchip_crtc_state {
struct drm_crtc_state base;
int output_type;
int output_mode;
+ int output_bpc;
};
#define to_rockchip_crtc_state(s) \
container_of(s, struct rockchip_crtc_state, base)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index aa5c528c59fc..ea3fff4170d9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -968,6 +968,10 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
DRM_DEV_ERROR(vop->dev, "unsupported connector_type [%d]\n",
s->output_type);
}
+ if (s->output_mode == ROCKCHIP_OUT_MODE_ && s->output_bpc == 8)
+ VOP_CTRL_SET(vop, pre_dither_down, 1);
+ else
+ VOP_CTRL_SET(vop, pre_dither_down, 0);
VOP_CTRL_SET(vop, out_mode, s->output_mode);
VOP_CTRL_SET(vop, htotal_pw, (htotal << 16) | hsync_len);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 5a4faa85dbd2..9a1eb83271eb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -47,6 +47,7 @@ struct vop_ctrl {
struct vop_reg mipi_en;
struct vop_reg dp_en;
struct vop_reg out_mode;
+ struct vop_reg pre_dither_down;
struct vop_reg dither_down;
struct vop_reg dither_up;
struct vop_reg pin_pol;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 91fbc7b52147..e645a9621721 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -212,7 +212,8 @@ static const struct vop_ctrl rk3288_ctrl_data = {
.hdmi_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 13),
.edp_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 14),
.mipi_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 15),
- .dither_down = VOP_REG(RK3288_DSP_CTRL1, 0xf, 1),
+ .pre_dither_down = VOP_REG(RK3288_DSP_CTRL1, 0x1, 1),
+ .dither_down = VOP_REG(RK3288_DSP_CTRL1, 0x7, 2),
.dither_up = VOP_REG(RK3288_DSP_CTRL1, 0x1, 6),
.data_blank = VOP_REG(RK3288_DSP_CTRL0, 0x1, 19),
.out_mode = VOP_REG(RK3288_DSP_CTRL0, 0xf, 0),
@@ -289,7 +290,8 @@ static const struct vop_ctrl rk3399_ctrl_data = {
.hdmi_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 13),
.edp_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 14),
.mipi_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 15),
- .dither_down = VOP_REG(RK3399_DSP_CTRL1, 0xf, 1),
+ .pre_dither_down = VOP_REG(RK3399_DSP_CTRL1, 0x1, 1),
+ .dither_down = VOP_REG(RK3399_DSP_CTRL1, 0x7, 2),
.dither_up = VOP_REG(RK3399_DSP_CTRL1, 0x1, 6),
.data_blank = VOP_REG(RK3399_DSP_CTRL0, 0x1, 19),
.out_mode = VOP_REG(RK3399_DSP_CTRL0, 0xf, 0),
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 23/41] drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode
From: zain wang Enhanced mode is required by the eDP 1.2 specification, and not doing it early could result in a period of time where we have a link transmitting idle packets without it. Since there is no reason to disable it, we just enable it at the beginning of link training and then keep it on all the time Cc: Tomasz Figa Signed-off-by: zain wang Signed-off-by: Sean Paul --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index 043641aa0a6f..8d69d4327871 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c @@ -284,6 +284,8 @@ static int analogix_dp_link_start(struct analogix_dp_device *dp) retval = drm_dp_dpcd_write(&dp->aux, DP_LINK_BW_SET, buf, 2); if (retval < 0) return retval; + /* set enhanced mode if available */ + analogix_dp_set_enhanced_mode(dp); /* Set TX pre-emphasis to minimum */ for (lane = 0; lane < lane_count; lane++) @@ -596,8 +598,6 @@ static int analogix_dp_process_equalizer_training(struct analogix_dp_device *dp) dev_dbg(dp->dev, "fast link training %s\n", dp->fast_train_enable ? "supported" : "unsupported"); - /* set enhanced mode if available */ - analogix_dp_set_enhanced_mode(dp); dp->link_train.lt_state = FINISHED; return 0; @@ -947,8 +947,6 @@ static int analogix_dp_commit(struct analogix_dp_device *dp) } analogix_dp_enable_scramble(dp, 1); - analogix_dp_enable_rx_to_enhanced_mode(dp, 1); - analogix_dp_enable_enhanced_mode(dp, 1); analogix_dp_init_video(dp); ret = analogix_dp_config_video(dp); -- 2.12.0.246.ga2ecc84866-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/41] drm/rockchip: Only wait for panel ACK on PSR entry
From: zain wang
We currently wait for the panel to mirror our intended PSR state
before continuing on both PSR enter and PSR exit. This is really
only important to do when we're entering PSR, since we want to
be sure the last frame we pushed is being served from the panel's
internal fb before shutting down the soc blocks (vop/analogix).
This patch changes the behavior such that we only wait for the
panel to complete the PSR transition when we're entering PSR, and
to skip verification when we're exiting.
Cc: Stéphane Marchesin
Cc: Sonny Rao
Signed-off-by: zain wang
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 4 ++--
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 5 -
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5bc151b0995b..9dfa1b507389 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -127,7 +127,7 @@ int analogix_dp_enable_psr(struct device *dev)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
- return analogix_dp_send_psr_spd(dp, &psr_vsc);
+ return analogix_dp_send_psr_spd(dp, &psr_vsc, true);
}
EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
@@ -154,7 +154,7 @@ int analogix_dp_disable_psr(struct device *dev)
if (ret != 1)
dev_err(dp->dev, "Failed to set DP Power0 %d\n", ret);
- return analogix_dp_send_psr_spd(dp, &psr_vsc);
+ return analogix_dp_send_psr_spd(dp, &psr_vsc, false);
}
EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 920607d7eb3e..6a96ef7e6934 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -253,7 +253,7 @@ void analogix_dp_enable_scrambling(struct
analogix_dp_device *dp);
void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc);
+struct edp_vsc_psr *vsc, bool blocking);
ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
struct drm_dp_aux_msg *msg);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 005a3f7005d2..9df2f3ef000c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1007,7 +1007,7 @@ static ssize_t analogix_dp_get_psr_status(struct
analogix_dp_device *dp)
}
int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
-struct edp_vsc_psr *vsc)
+struct edp_vsc_psr *vsc, bool blocking)
{
unsigned int val;
int ret;
@@ -1053,6 +1053,9 @@ int analogix_dp_send_psr_spd(struct analogix_dp_device
*dp,
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+ if (!blocking)
+ return 0;
+
ret = readx_poll_timeout(analogix_dp_get_psr_status, dp, psr_status,
psr_status >= 0 &&
((vsc->DB1 && psr_status == DP_PSR_SINK_ACTIVE_RFB) ||
--
2.12.0.246.ga2ecc84866-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
