Re: [PATCH 2/2] drm/sun4i: backend: Disable alpha on the lowest plane on the A20
On Tue, Jul 28, 2020 at 9:48 PM Maxime Ripard wrote:
>
> Unlike we previously thought, the per-pixel alpha is just as broken on the
> A20 as it is on the A10. Remove the quirk that says we can use it.
>
> Cc: Paul Kocialkowski
> Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane
> alpha support")
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/sun4i: backend: Support alpha property on lowest plane
On Tue, Jul 28, 2020 at 9:48 PM Maxime Ripard wrote:
>
> Unlike what we previously thought, only the per-pixel alpha is broken on
> the lowest plane and the per-plane alpha isn't. Remove the check on the
> alpha property being set on the lowest plane to reject a mode.
>
> Cc: Paul Kocialkowski
> Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane
> alpha support")
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
once the build break is fixed.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/sun4i: tcon: Support the LVDS Dual-Link on the A20
On Thu, Jul 30, 2020 at 5:35 PM Maxime Ripard wrote:
>
> The A20 can use its second TCON as the secondary LVDS link in a dual-link
> setup, with the TCON0 being the main link. Extend a bit the parsing code to
> leverage the DRM dual-link code, register only the LVDS output on the
> primary TCON, and add the needed bits to setup the TCON properly.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 36 +++-
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 +++-
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index d03ad75f9900..ed2abf6eb18b 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -487,6 +487,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
> *tcon,
> else
> reg |= SUN4I_TCON0_LVDS_IF_DATA_POL_NORMAL;
>
> + if (tcon->lvds_dual_link)
> + reg |= SUN4I_TCON0_LVDS_IF_DUAL_LINK;
> +
> if (sun4i_tcon_get_pixel_depth(encoder) == 24)
> reg |= SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS;
> else
> @@ -896,6 +899,16 @@ static int sun4i_tcon_register_panel(struct drm_device
> *drm,
> return sun4i_rgb_init(drm, tcon);
>
> /*
> +* Only the TCON0 will be relevant for the LVDS output, so if
> +* our ID is something else, let's prevent our TCON from
> +* registering its own LVDS output
> +*/
> + if (tcon->id) {
> + dev_info(dev, "Secondary TCON, disabling panel output");
Nit: "disabling" is a bit misleading.
Just stating that it is used as a secondary link
> + return 0;
> + }
> +
> + /*
> * This can only be made optional since we've had DT
> * nodes without the LVDS reset properties.
> *
> @@ -941,6 +954,28 @@ static int sun4i_tcon_register_panel(struct drm_device
> *drm,
> return -ENODEV;
> }
>
> + /*
> +* If we don't have a second TCON, we will never be able to do
> +* dual-link LVDS, so we don't have much more to do.
> +*/
> + companion = of_parse_phandle(dev->of_node,
> "allwinner,lvds-companion", 0);
> + if (!companion)
> + return 0;
I assume you want
return sun4i_lvds_init(drm, tcon);
otherwise single-link LVDS would not work anymore?
ChenYu
> +
> + /*
> +* Let's do a sanity check on the dual-link setup to make sure
> +* everything is properly described.
> +*/
> + ret = drm_of_lvds_get_dual_link_pixel_order(dev->of_node, 1, 0,
> + companion, 1, 0);
> + if (ret < 0) {
> + dev_err(dev, "Invalid Dual-Link Configuration.\n");
> + return ret;
> + }
> +
> + dev_info(dev, "Primary TCON, enabling LVDS Dual-Link");
> + tcon->lvds_dual_link = true;
> +
> return sun4i_lvds_init(drm, tcon);
> }
>
> @@ -1500,6 +1535,7 @@ static const struct sun4i_tcon_quirks
> sun7i_a20_tcon0_quirks = {
> };
>
> static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
> + .supports_lvds = true,
> .has_channel_0 = true,
> .has_channel_1 = true,
> .dclk_min_div = 4,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index cfbf4e6c1679..51c4e09cdd13 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -98,6 +98,7 @@
>
> #define SUN4I_TCON0_LVDS_IF_REG0x84
> #define SUN4I_TCON0_LVDS_IF_EN BIT(31)
> +#define SUN4I_TCON0_LVDS_IF_DUAL_LINK BIT(30)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_MASK BIT(26)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_18BITS(1 << 26)
> #define SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS(0 << 26)
> @@ -274,6 +275,9 @@ struct sun4i_tcon {
> /* Associated crtc */
> struct sun4i_crtc *crtc;
>
> + /* Is the LVDS link a dual-channel link? */
> + boollvds_dual_link;
> +
> int id;
>
> /* TCON list management */
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/sun4i: tcon: Refactor the LVDS and panel probing
On Thu, Jul 30, 2020 at 5:35 PM Maxime Ripard wrote:
>
> The current code to parse the DT, deal with the older device trees, and
> register either the RGB or LVDS output has so far grown organically into
> the bind function and has become quite hard to extend properly.
>
> Let's move it into a single function that grabs all the resources it needs
> and registers the proper panel output.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 139 +++---
> 1 file changed, 70 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 2a5a9903c4c6..d03ad75f9900 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -875,6 +875,75 @@ static int sun4i_tcon_init_regmap(struct device *dev,
> return 0;
> }
>
> +static int sun4i_tcon_register_panel(struct drm_device *drm,
> +struct sun4i_tcon *tcon)
> +{
> + struct device_node *companion;
> + struct device_node *remote;
> + struct device *dev = tcon->dev;
> + bool has_lvds_alt;
> + bool has_lvds_rst;
> + int ret;
> +
> + /*
> +* If we have an LVDS panel connected to the TCON, we should
> +* just probe the LVDS connector. Otherwise, let's just register
> +* an RGB panel.
> +*/
> + remote = of_graph_get_remote_node(dev->of_node, 1, 0);
> + if (!tcon->quirks->supports_lvds ||
> + !of_device_is_compatible(remote, "panel-lvds"))
> + return sun4i_rgb_init(drm, tcon);
Slightly related: IIRC there are a few LVDS panels supported in panel-simple
so they don't use the panel-lvds compatible. Any idea how to deal with those?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/display: fix uninitialized variable
Just merged the first patch that fixed this issue, thanks anyways.
2034c2129bc4a91d471815d4dc7a2a69eaa5338d - drm/i915/display: Ensure that ret is
always initialized in icl_combo_phy_verify_state
On Tue, 2020-08-25 at 16:20 -0700, t...@redhat.com wrote:
> From: Tom Rix <
> t...@redhat.com
> >
>
> clang static analysis flags this error
>
> intel_combo_phy.c:268:7: warning: The left expression of the
> compound assignment is an uninitialized value.
> The computed value will also be garbage
> ret &= check_phy_reg(...
> ~~~ ^
>
> ret has no initial values, in icl_combo_phy_verify_state() ret is
> set by the next statment and then updated by similar &= logic.
>
> Because the check_phy_req() are only register reads, reorder the
> statements.
>
> Fixes: 239bef676d8e ("drm/i915/display: Implement new combo phy
> initialization step")
> Signed-off-by: Tom Rix <
> t...@redhat.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index 6968de4f3477..7622ef66c987 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -264,6 +264,8 @@ static bool icl_combo_phy_verify_state(struct
> drm_i915_private *dev_priv,
> if (!icl_combo_phy_enabled(dev_priv, phy))
> return false;
>
> + ret = cnl_verify_procmon_ref_values(dev_priv, phy);
> +
> if (INTEL_GEN(dev_priv) >= 12) {
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
>ICL_PORT_TX_DW8_ODCC_CLK_SEL |
> @@ -276,8 +278,6 @@ static bool icl_combo_phy_verify_state(struct
> drm_i915_private *dev_priv,
>DCC_MODE_SELECT_CONTINUOSLY);
> }
>
> - ret = cnl_verify_procmon_ref_values(dev_priv, phy);
> -
> if (phy_is_master(dev_priv, phy)) {
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
>IREFGEN, IREFGEN);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 1403/1518] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:408:44: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 8252270c0b5fba4dd651473c5fee66ecaa3d9026
commit: 82e6bcf7c9a0c82f3d41a5837bb1dadd68037e55 [1403/1518] drm/amd/pm:
optimize the power related source code layout
config: powerpc64-randconfig-s032-20200828 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-191-g10164920-dirty
git checkout 82e6bcf7c9a0c82f3d41a5837bb1dadd68037e55
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:65:25:
sparse: sparse: cast to restricted __be32
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:74:26:
sparse: sparse: cast to restricted __be32
>> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:408:44:
>> sparse: sparse: incorrect type in argument 1 (different address spaces) @@
>> expected void volatile [noderef] *d @@ got void *kaddr @@
>> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:408:44:
>> sparse: expected void volatile [noderef] *d
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c:408:44:
sparse: got void *kaddr
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next
git checkout 82e6bcf7c9a0c82f3d41a5837bb1dadd68037e55
vim +408 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/smumgr/smu7_smumgr.c
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 321
d3f8c0abf45866d drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2017-09-20 322 int smu7_request_smu_load_fw(struct pp_hwmgr *hwmgr)
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 323 {
b3b030520df05fc drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2017-09-26 324struct smu7_smumgr *smu_data = (struct smu7_smumgr
*)(hwmgr->smu_backend);
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 325uint32_t fw_to_load;
d92867122cd9524 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Alex Deucher
2018-07-12 326int r = 0;
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 327
744a522794bdc64 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2018-09-29 328amdgpu_ucode_init_bo(hwmgr->adev);
744a522794bdc64 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2018-09-29 329
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 330if (smu_data->soft_regs_start)
d3f8c0abf45866d drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2017-09-20 331cgs_write_ind_register(hwmgr->device,
CGS_IND_REG__SMC,
d3f8c0abf45866d drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2017-09-20 332
smu_data->soft_regs_start + smum_get_offsetof(hwmgr,
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 333SMU_SoftRegisters,
UcodeLoadStatus),
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 3340x0);
1ff55f465103782 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2016-08-19 335
d3f8c0abf45866d drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2017-09-20 336if (hwmgr->chip_id > CHIP_TOPAZ) { /* add support for
Topaz */
8bb575a2d83af09 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Rex Zhu
2018-03-22 337if (hwmgr->not_vf) {
d9c8316eb372268 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Evan Quan
2020-03-26 338
smum_send_msg_to_smc_with_parameter(hwmgr,
e224e4f17dc89b2 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Xiangliang
Yu 2016-12-02 339
PPSMC_MSG_SMU_DRAM_ADDR_HI,
a0ec225633d9f68 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Evan Quan
2020-03-27 340
upper_32_bits(smu_data->smu_buffer.mc_addr),
a0ec225633d9f68 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c Evan Quan
2020-03-27 341
Re: [PATCH 2/5] dt-bindings: display/bridge: nwl-dsi: Document video_pll clock
On Fri, 28 Aug 2020 14:13:29 +0300, Robert Chiras (OSS) wrote: > From: Robert Chiras > > Add documentation for a new clock 'video_pll'. > > Signed-off-by: Robert Chiras > --- > Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml | 3 +++ > 1 file changed, 3 insertions(+) > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml: mipi_dsi@30a0: clocks: [[4294967295, 163], [4294967295, 244], [4294967295, 245], [4294967295, 164], [4294967295, 128]] is too short From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml: mipi_dsi@30a0: clock-names: ['core', 'rx_esc', 'tx_esc', 'phy_ref', 'lcdif'] is too short From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml See https://patchwork.ozlabs.org/patch/1353197 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: panel: simple: Add AM-1280800N3TZQW-T00H
Hi Jagan,
I love your patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip linus/master
v5.9-rc2 next-20200828]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jagan-Teki/dt-bindings-display-simple-Add-AM-1280800N3TZQW-T00H/20200829-37
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: x86_64-randconfig-a003-20200828 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c10e63677f5d20f18010f8f68c631ddc97546f7d)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/panel/panel-simple.c:623:3: error: field designator
>> 'vrefresh' does not refer to any field in type 'const struct
>> drm_display_mode'
.vrefresh = 60,
^
1 error generated.
#
https://github.com/0day-ci/linux/commit/dfa982c527d827dca7aa86fc2b58228ff404bc05
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jagan-Teki/dt-bindings-display-simple-Add-AM-1280800N3TZQW-T00H/20200829-37
git checkout dfa982c527d827dca7aa86fc2b58228ff404bc05
vim +623 drivers/gpu/drm/panel/panel-simple.c
612
613 static const struct drm_display_mode ampire_am_1280800n3tzqw_t00h_mode
= {
614 .clock = 71100,
615 .hdisplay = 1280,
616 .hsync_start = 1280 + 40,
617 .hsync_end = 1280 + 40 + 80,
618 .htotal = 1280 + 40 + 80 + 40,
619 .vdisplay = 800,
620 .vsync_start = 800 + 3,
621 .vsync_end = 800 + 3 + 10,
622 .vtotal = 800 + 3 + 10 + 10,
> 623 .vrefresh = 60,
624 .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
625 };
626
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Fri, Aug 28, 2020 at 1:05 AM Greg Kroah-Hartman wrote: > > On Thu, Aug 27, 2020 at 11:54:12AM -0700, John Stultz wrote: > > On Thu, Aug 27, 2020 at 10:17 AM Greg Kroah-Hartman > > wrote: > > > On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > > > > I don't know what is the right thing to do here. I just want to > > > > highlight that AOSP's audio (codec2) HAL depends on the ION system > > > > heap and it will break AOSP for people who boot mainline on their > > > > devices, even for just testing purpose like we do in Linaro. Right now > > > > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > > > > mainline and Sumit is already trying to upstream that vma naming > > > > patch. Removal of in-kernel ION, will just add more to that delta. > > > > > > As AOSP will continue to rely on ION after December of this year, all > > > you are doing is postponing the inevitable a few more months. > > > > > > Push back on the Android team to fix up the code to not use ION, they > > > know this needs to happen. > > > > The point though, is your main premise that no one is using this isn't true. > > They are using the version of ion in the Android kernel tree, yes, as it > has new features that many people are relying on. > > The version that is currently in the kernel tree is crippled, and maybe > works for some use cases, but not the majority, right? So my understanding is the Android Common Kernel tree version was mostly reworked to allow heaps as modules, and allowed heaps to have their own exporter logic (not unlike how dmabuf heaps do it). The main allocation interface is maybe slightly tweaked for out-of-tree vendor heaps, but doesn't affect the in-staging heaps. There's also a few optimizations we have skipped taking upstream. So yes, there are differences, but I don't feel your characterization is quite accurate. > > I'm actively working with Hridya and folks on the codec2 HAL side to > > transition this on the userland side: > > > > https://android-review.googlesource.com/c/platform/frameworks/av/+/1368918/3 > > > > I'd like AOSP to not use ION after September (though being external I > > can't promise anything), much less continuing after December. > > The android team has said they will be dropping ION use for the "next" > Android release, which is sometime next year from what I recall. > December is probably not going to happen :) AOSP is what the next Android release forks off of, so it needs to be fixed first. > > I want this migration to happen as much as anyone. But I'd prefer to > > keep ION in staging until after the LTS is announced. Having both > > around helps development for the transition, which helps us have a > > reliable solution, which helps vendors to migrate and be able to do > > comparative performance testing. > > I don't understand what having this in the "next" kernel helps us with > here. And I would really really prefer to NOT have an outdated version > of this code in a kernel tree that I am going to have to support for the > next X number of years, when no one is using that version of the driver. > > What is this LTS fixation to keep this code around for? Who does it > help? Vendors usually target LTS releases for their hardware bringups. Having a LTS release with both ION and DMA BUF Heaps helps them validate their old ION solution as performant, and then migrate to DMA BUF Heaps and be able to do performance comparisons holding all other things equal. > > I do appreciate that keeping it isn't free, but I also don't feel the > > chaos-monkey approach here is really motivational in the way you > > intend. > > I don't see it helping anyone to leave this around, except to cause > merge issues for me, and development issues for other developers. > > Anyone who really wants this code, can easily revert the deletion and > move on and grab the AOSP copy of the code. That's what they did when > we deleted other Android features that are still relied on. > > Given that the "isn't free" is causing _me_ real pain, and not the > actual users of this code, I am leaning toward wanting to move that > pain/cost to those users, for obvious reasons. Sure. Again, I do understand the desire to remove it, and it's your right to do so. Keeping the code for an extra year in LTS (over 5.4) is a cost, so I understand if you drop it. But I'll ask that you make that judgement clear as the main motivator/rationale of the commit message, rather than flippantly pretending it's not being used, and that everyone agrees it has no usefulness to keep around (especially after we've had this conversation a few times already this year). thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.9-rc3
The pull request you sent on Fri, 28 Aug 2020 12:35:20 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-08-28 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/5ec06b5c0d259a8c7c4376b121b2f62dfbfe57ef Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/3] drm: bridge: add support for lontium LT9611UXC bridge
Hi Dmitry
On Fri, Aug 28, 2020 at 06:49:05PM +0300, Dmitry Baryshkov wrote:
> Add support for Lontium LT9611UXC HDMI bridge. Lontium LT9611UXC is a
> DSI to HDMI bridge which supports two DSI ports and I2S port as an input
> and HDMI port as output. Despite name being similar to LT9611, these
> devices are different enough to warrant separate driver.
>
> Signed-off-by: Dmitry Baryshkov
I have browsed the driver - most looks good but the way modes are
handled looks fishy.
The code either relies on edid or modes returned by a panel-timings
node. The panel-timings node seems to be used to override the edid info.
We do not need this in any other bridge driver today - and thus it is
questionaable if this driver needs it. If it is needed then please
document the rationale behind it - in the source code.
The binding does not exaplin anything about a panel-timings node.
If the panel-timins stuff is not needed, then remember to drop include
files that are no logner used.
And then there is mode_valid which uses a set of modes obtained from
a static list which also looks strange.
The last part can also be found in lontium-lt9611.c but that does
not make it correct.
Please see other bridge drivers.
The extra patch that makes connector creation optinal should be
merged with the first patch - there is no gain to split it in two.
There was also a few style issues, see comments in the following.
Looks forward to see a new revision.
Sam
> ---
> drivers/gpu/drm/bridge/Kconfig | 13 +
> drivers/gpu/drm/bridge/Makefile| 1 +
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 774 +
> 3 files changed, 788 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/lontium-lt9611uxc.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3e11af4e9f63..8343fb054652 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -61,6 +61,19 @@ config DRM_LONTIUM_LT9611
> HDMI signals
> Please say Y if you have such hardware.
>
> +config DRM_LONTIUM_LT9611UXC
> + tristate "Lontium LT9611UXC DSI/HDMI bridge"
> + select SND_SOC_HDMI_CODEC if SND_SOC
> + depends on OF
> + select DRM_PANEL_BRIDGE
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + help
> + Driver for Lontium LT9611UXC DSI to HDMI bridge
> + chip driver that converts dual DSI and I2S to
> + HDMI signals
> + Please say Y if you have such hardware.
> +
> config DRM_LVDS_CODEC
> tristate "Transparent LVDS encoders and decoders support"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index c589a6a7cbe1..306850a5899b 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
> obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
> obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
> +obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
> obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> megachips-stdp-ge-b850v3-fw.o
> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> new file mode 100644
> index ..77c5aa5c6ad7
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
> @@ -0,0 +1,774 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2019-2020. Linaro Limited.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
Sort this block
> +
> +#define EDID_BLOCK_SIZE 128
> +#define EDID_NUM_BLOCKS 2
> +
> +struct lt9611uxc {
> + struct device *dev;
> + struct drm_bridge bridge;
> +
> + struct regmap *regmap;
> + /* Protects all accesses to registers by stopping the on-chip MCU */
> + struct mutex ocm_lock;
> +
> + struct device_node *dsi0_node;
> + struct device_node *dsi1_node;
> + struct mipi_dsi_device *dsi0;
> + struct mipi_dsi_device *dsi1;
> + struct platform_device *audio_pdev;
> +
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *enable_gpio;
> +
> + bool sleep;
> +
> + struct regulator_bulk_data supplies[2];
> +
> + struct i2c_client *client;
> +
> + bool hpd_supported;
> + struct display_timings *timings;
> + u8 edid_buf[EDID_BLOCK_SIZE * EDID_NUM_BLOCKS];
> +};
> +
> +#define LT9611_PAGE_CONTROL 0xff
> +
> +static const struct regmap_range_cfg lt9611uxc_ranges[] = {
> + {
> + .name = "register_ran
Re: [PATCH RFC v6 1/6] dt-bindings: display: add Unisoc's drm master bindings
On Tue, Jul 28, 2020 at 4:08 AM Kevin Tang wrote:
>
> From: Kevin Tang
>
> The Unisoc DRM master device is a virtual device needed to list all
> DPU devices or other display interface nodes that comprise the
> graphics subsystem
>
> Cc: Orson Zhai
> Cc: Chunyan Zhang
> Signed-off-by: Kevin Tang
> ---
> .../devicetree/bindings/display/sprd/drm.yaml | 36
> ++
> 1 file changed, 36 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/sprd/drm.yaml
If you want bindings reviewed, then you need to Cc
devicet...@vger.kernel.org. Otherwise you may be waiting until the 6th
version or later or never.
>
> diff --git a/Documentation/devicetree/bindings/display/sprd/drm.yaml
> b/Documentation/devicetree/bindings/display/sprd/drm.yaml
> new file mode 100644
> index 000..b5792c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/sprd/drm.yaml
> @@ -0,0 +1,36 @@
> +# SPDX-License-Identifier: GPL-2.0
New bindings should be dual licensed:
(GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/sprd/drm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc DRM master device
DRM is a Linux thing and shouldn't be part of a binding.
> +
> +maintainers:
> + - Mark Rutland
No, this should be you or someone that knows the h/w.
> +
> +description: |
> + The Unisoc DRM master device is a virtual device needed to list all
> + DPU devices or other display interface nodes that comprise the
> + graphics subsystem.
> +
> +properties:
> + compatible:
> +const: sprd,display-subsystem
> +
> + ports:
> +description:
> + Should contain a list of phandles pointing to display interface port
> + of DPU devices.
> +
> +required:
> + - compatible
> + - ports
> +
> +examples:
> + - |
> +display-subsystem {
> +compatible = "sprd,display-subsystem";
> +ports = <&dpu_out>;
We generally try to avoid this virtual node as it doesn't represent
any h/w. Can't you bind the driver to the DPU directly?
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dt-bindings: display: bridge: Add documentation for LT9611UXC
On Fri, Aug 28, 2020 at 06:49:04PM +0300, Dmitry Baryshkov wrote: > Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports > and I2S port as input and one HDMI port as output. The LT9611UXC chip is > handled by a separate driver, but the bindings used are fully compatible > with the LT9611 chip, so let's reuse the lt9611.yaml schema. > > Signed-off-by: Dmitry Baryshkov > Acked-by: Vinod Koul Acked-by: Sam Ravnborg We can apply this when the driver is ready. Sam > --- > .../devicetree/bindings/display/bridge/lontium,lt9611.yaml | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml > b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml > index d60208359234..7a1c89b995e2 100644 > --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml > @@ -4,18 +4,19 @@ > $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml# > $schema: http://devicetree.org/meta-schemas/core.yaml# > > -title: Lontium LT9611 2 Port MIPI to HDMI Bridge > +title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge > > maintainers: >- Vinod Koul > > description: | > - The LT9611 is a bridge device which converts DSI to HDMI > + The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI > > properties: >compatible: > enum: >- lontium,lt9611 > + - lontium,lt9611uxc > >reg: > maxItems: 1 > -- > 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi Maxime,
Am 28.08.20 um 17:25 schrieb Maxime Ripard:
> Hi,
>
> On Fri, Aug 28, 2020 at 02:45:49PM +0200, Stefan Wahren wrote:
>> Am 28.08.20 um 08:30 schrieb Hoegeun Kwon:
>>> On 8/27/20 6:49 PM, Stefan Wahren wrote:
Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
> Hi Stefan,
>
> Thank you for your review.
>
>
> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>> Hi Hoeguen,
>>
>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>>> There is a problem that the output does not work at a resolution
>>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>>> resolution exceeding FHD.
>> this patch introduces a mandatory clock, please update
>> brcm,bcm2835-hdmi.yaml first.
>>
>> Is this clock physically available on BCM283x or only on BCM2711?
> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>
> don't supported on pi 3 and pi 3+.
>
> Since 4k is not supported in versions prior to Raspberry Pi 4,
>
> I don't think we need to modify the bvb clock.
>
>
> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>
> instead of 'brcm,bcm2835-hdmi.yaml'.
You are correct please update only brcm,bcm2711-hdmi.yaml.
My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
DTB. So making the BVB clock optional might be better?
>>> You are right, if use old dtb, we have a problem with the hdmi driver.
>>>
>>> So how about modifying it like this?
>>>
>>> @@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
>>> *vc4_hdmi)
>>>
>>> vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
>>> if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
>>> - DRM_ERROR("Failed to get pixel bvb clock\n");
>>> - return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
>>> + DRM_WARN("Failed to get pixel bvb clock\n");
>>> + vc4_hdmi->pixel_bvb_clock = NULL;
>>> }
>> i think the better solution would be devm_clk_get_optional(), which
>> return NULL in case the clock doesn't exist.
> It's not really optional though. BCM2711 will require it in order to run
> properly (as Hoegeun experienced), and the previous SoCs won't.
>
> If we use clk_get_optional and that the DT is missing the clock on the
> BCM2711, we will silently ignore it which doesn't sound great.
you are right. Sorry for the noise.
Best regards
>
> Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: panel: simple: Add AM-1280800N3TZQW-T00H
Hi Jagan.
On Fri, Aug 28, 2020 at 09:29:38PM +0530, Jagan Teki wrote:
> Add Ampire, AM-1280800N3TZQW-T00H 10.1" TFT LCD panel timings.
>
> Signed-off-by: Jagan Teki
> ---
> drivers/gpu/drm/panel/panel-simple.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index b6ecd1552132..c988fe8094f8 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -592,6 +592,31 @@ static void panel_simple_shutdown(struct device *dev)
> drm_panel_unprepare(&panel->base);
> }
>
> +static const struct drm_display_mode ampire_am_1280800n3tzqw_t00h_mode = {
> + .clock = 71100,
> + .hdisplay = 1280,
> + .hsync_start = 1280 + 40,
> + .hsync_end = 1280 + 40 + 80,
> + .htotal = 1280 + 40 + 80 + 40,
> + .vdisplay = 800,
> + .vsync_start = 800 + 3,
> + .vsync_end = 800 + 3 + 10,
> + .vtotal = 800 + 3 + 10 + 10,
> + .vrefresh = 60,
No longer preset - delete.
> + .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> +};
> +
> +static const struct panel_desc ampire_am_1280800n3tzqw_t00h = {
> + .modes = &ire_am_1280800n3tzqw_t00h_mode,
> + .num_modes = 1,
> + .bpc = 6,
> + .size = {
> + .width = 217,
> + .height = 136,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> +};
.connector_type is mandatory today.
And based on connector type you may need to specify .bus_flags.
Sam
> +
> static const struct drm_display_mode ampire_am_480272h3tmqw_t01h_mode = {
> .clock = 9000,
> .hdisplay = 480,
> @@ -3637,6 +3662,9 @@ static const struct panel_desc arm_rtsm = {
>
> static const struct of_device_id platform_of_match[] = {
> {
> + .compatible = "ampire,am-1280800n3tzqw-t00h",
> + .data = &ire_am_1280800n3tzqw_t00h,
> + }, {
> .compatible = "ampire,am-480272h3tmqw-t01h",
> .data = &ire_am_480272h3tmqw_t01h,
> }, {
> --
> 2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 1/6] dt-bindings: display: add Unisoc's drm master bindings
Hi Kevin. > > > > Any specific reason why this is not a ports node like used by many other > > display bindings? > > In other words - I think this is too simple. > We only support one display pipeline now, other interface, like > DP(DisplayPort), HDMI...will be add later... > > ports: > $ref: /schemas/types.yaml#/definitions/phandle-array > description: | > Should contain a list of phandles pointing to display interface port > of dpu devices.. dpu definitions as defined in > Documentation/devicetree/bindings/display/sprd/sprd,dpu.yaml There is nothing wrong having a ports node that is limited to a single port node. But please remember the binding describes the HW - so if the HW supports more than one port the binding should describe this. What the driver supports is not relevant for the binding. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 2/6] drm/sprd: add Unisoc's drm kms master
Hi Kevin > > > > > + > > > + drm->dev_private = sprd; > > dev_private is deprecated. Alwyas use upclassing. > dev_private is deprecated ? I see everyone is still using it, so it > will be deprecated in the future? It is deprecated - and a lot of drivers is in need up an update to get away from using it. >From the kernel-doc: /** * @dev_private: * * DRM driver private data. This is deprecated and should be left set to * NULL. * * Instead of using this pointer it is recommended that drivers use * drm_dev_init() and embed struct &drm_device in their larger * per-device structure. */ void *dev_private; > > > + } > > > + /* with irq_enabled = true, we can use the vblank feature. */ > > > + drm->irq_enabled = true; > > Can drm_irq_install() be used? > > Then this flag shall not be set by the driver, And the interrupt numbers on > > different Soc are not necessarily the same > > > We need to set "IRQ_NOAUTOEN" flag for CRTC IRQ, you can see that we > manually turn the interrupt on and off by crtc > atomic_enable/atomic_disable > and the interrupt number on different Soc are not necessarily the > same. So intall interrupt in kms maybe is not suitable for us... Maybe drm_irq_install() does not fit the need here. But please take an extra look as what is does is quite basic. And no need to roll your own if there is available infrstructure that can be used. But there is nothing wrong rolloing your own if needed. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: panel: simple: Add AM-1280800N3TZQW-T00H
Hi Jagan,
I love your patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip linus/master
v5.9-rc2 next-20200828]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jagan-Teki/dt-bindings-display-simple-Add-AM-1280800N3TZQW-T00H/20200829-37
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-randconfig-m021-20200828 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/panel/panel-simple.c:623:3: error: 'const struct
>> drm_display_mode' has no member named 'vrefresh'
623 | .vrefresh = 60,
| ^~~~
#
https://github.com/0day-ci/linux/commit/dfa982c527d827dca7aa86fc2b58228ff404bc05
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jagan-Teki/dt-bindings-display-simple-Add-AM-1280800N3TZQW-T00H/20200829-37
git checkout dfa982c527d827dca7aa86fc2b58228ff404bc05
vim +623 drivers/gpu/drm/panel/panel-simple.c
612
613 static const struct drm_display_mode ampire_am_1280800n3tzqw_t00h_mode
= {
614 .clock = 71100,
615 .hdisplay = 1280,
616 .hsync_start = 1280 + 40,
617 .hsync_end = 1280 + 40 + 80,
618 .htotal = 1280 + 40 + 80 + 40,
619 .vdisplay = 800,
620 .vsync_start = 800 + 3,
621 .vsync_end = 800 + 3 + 10,
622 .vtotal = 800 + 3 + 10 + 10,
> 623 .vrefresh = 60,
624 .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
625 };
626
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Aw: Re: [PATCH v5 3/7] drm/mediatek: disable tmds on mt2701
On 28/08/2020 01:46, Chun-Kuang Hu wrote: Hi, Frank: Matthias Brugger 於 2020年8月27日 週四 下午10:28寫道： On 27/08/2020 15:41, Frank Wunderlich wrote: Hi Matthias, any opinions about the dts-changes? they look good to me. maybe series except the tmds-Patch get merged...so i add it only to my own repo till we find a better way? currently mainline does not support hdmi at all for the board. the tmds-patch is only a fix for specific resolutions which have a "flickering" without this Patch. Well let's see what CK's opinion. Because no one has comment on this patch, I could apply this patch but I need you to add more experiment information so if someone meets another bug, he could fix his bug and consider your problem. I'm adding Chunhui Dai as he got dropped in the discussion. Chunhui can you as the first patch author provide some more technical background why the distortion happens and why this patch fixes it? Thanks a lot, Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: panel: simple: Add AM-1280800N3TZQW-T00H
Add Ampire, AM-1280800N3TZQW-T00H 10.1" TFT LCD panel timings.
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index b6ecd1552132..c988fe8094f8 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -592,6 +592,31 @@ static void panel_simple_shutdown(struct device *dev)
drm_panel_unprepare(&panel->base);
}
+static const struct drm_display_mode ampire_am_1280800n3tzqw_t00h_mode = {
+ .clock = 71100,
+ .hdisplay = 1280,
+ .hsync_start = 1280 + 40,
+ .hsync_end = 1280 + 40 + 80,
+ .htotal = 1280 + 40 + 80 + 40,
+ .vdisplay = 800,
+ .vsync_start = 800 + 3,
+ .vsync_end = 800 + 3 + 10,
+ .vtotal = 800 + 3 + 10 + 10,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc ampire_am_1280800n3tzqw_t00h = {
+ .modes = &ire_am_1280800n3tzqw_t00h_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+};
+
static const struct drm_display_mode ampire_am_480272h3tmqw_t01h_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -3637,6 +3662,9 @@ static const struct panel_desc arm_rtsm = {
static const struct of_device_id platform_of_match[] = {
{
+ .compatible = "ampire,am-1280800n3tzqw-t00h",
+ .data = &ire_am_1280800n3tzqw_t00h,
+ }, {
.compatible = "ampire,am-480272h3tmqw-t01h",
.data = &ire_am_480272h3tmqw_t01h,
}, {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: display: simple: Add AM-1280800N3TZQW-T00H
Add dt-bindings for 10.1" TFT LCD module from Ampire Co. Ltd. as part of panel-simple. Signed-off-by: Jagan Teki --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index d6cca1479633..f629d04f7737 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -29,6 +29,8 @@ properties: # compatible must be listed in alphabetical order, ordered by compatible. # The description in the comment is mandatory for each compatible. +# Ampire AM-1280800N3TZQW-T00H 10.1" WQVGA TFT LCD panel + - ampire,am-1280800n3tzqw-t00h # Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel - ampire,am-480272h3tmqw-t01h # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi Maxime, Stefan, and Hoegeun
On Fri, 28 Aug 2020 at 16:25, Maxime Ripard wrote:
>
> Hi,
>
> On Fri, Aug 28, 2020 at 02:45:49PM +0200, Stefan Wahren wrote:
> > Am 28.08.20 um 08:30 schrieb Hoegeun Kwon:
> > > On 8/27/20 6:49 PM, Stefan Wahren wrote:
> > >> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
> > >>> Hi Stefan,
> > >>>
> > >>> Thank you for your review.
> > >>>
> > >>>
> > >>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
> > Hi Hoeguen,
> >
> > Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
> > > There is a problem that the output does not work at a resolution
> > > exceeding FHD. To solve this, we need to adjust the bvb clock at a
> > > resolution exceeding FHD.
> > this patch introduces a mandatory clock, please update
> > brcm,bcm2835-hdmi.yaml first.
> >
> > Is this clock physically available on BCM283x or only on BCM2711?
> > >>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
> > >>>
> > >>> don't supported on pi 3 and pi 3+.
> > >>>
> > >>> Since 4k is not supported in versions prior to Raspberry Pi 4,
> > >>>
> > >>> I don't think we need to modify the bvb clock.
> > >>>
> > >>>
> > >>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
> > >>>
> > >>> instead of 'brcm,bcm2835-hdmi.yaml'.
> > >> You are correct please update only brcm,bcm2711-hdmi.yaml.
> > >>
> > >> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
> > >> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
> > >> DTB. So making the BVB clock optional might be better?
> > > You are right, if use old dtb, we have a problem with the hdmi driver.
> > >
> > > So how about modifying it like this?
> > >
> > > @@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> > > *vc4_hdmi)
> > >
> > > vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
> > > if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
> > > - DRM_ERROR("Failed to get pixel bvb clock\n");
> > > - return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
> > > + DRM_WARN("Failed to get pixel bvb clock\n");
> > > + vc4_hdmi->pixel_bvb_clock = NULL;
> > > }
> >
> > i think the better solution would be devm_clk_get_optional(), which
> > return NULL in case the clock doesn't exist.
>
> It's not really optional though. BCM2711 will require it in order to run
> properly (as Hoegeun experienced), and the previous SoCs won't.
>
> If we use clk_get_optional and that the DT is missing the clock on the
> BCM2711, we will silently ignore it which doesn't sound great.
Am I missing something here? (I know I missed this earlier)
We're in vc5_hdmi_init_resources, which is inherently bcm2711 only.
bcm283x will go through vc4_hdmi_init_resources.
As long as vc4_hdmi_init_resources has left vc4_hdmi->pixel_bvb_clock
at NULL, then the clock framework will be happy to do a nop.
For BCM2711 an old DT would have issues, but, as Maxime has stated, no
binding or upstream DTB has been merged yet, so it can be made
mandatory.
Making it optional drops you back on whatever the firmware might have
set it to, which may be sufficient for some resolutions but not
others.
Dave
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203033] nouveau hung task
https://bugzilla.kernel.org/show_bug.cgi?id=203033 James O'Beirne (james.obei...@pm.me) changed: What|Removed |Added CC||james.obei...@pm.me --- Comment #5 from James O'Beirne (james.obei...@pm.me) --- Having the same issue. # lspci | grep VGA 1f:00.0 VGA compatible controller: NVIDIA Corporation GK208 [GeForce GT 710B] (rev a1) # uname -a Linux slug 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux Aug 28 02:34:11 slug kernel: [38304.923718] INFO: task kworker/u32:0:5123 blocked for more than 120 seconds. Aug 28 02:34:11 slug kernel: [38304.923725] Tainted: GE 4.19.0-10-amd64 #1 Debian 4.19.132-1 Aug 28 02:34:11 slug kernel: [38304.923727] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Aug 28 02:34:11 slug kernel: [38304.923729] kworker/u32:0 D0 5123 2 0x8000 Aug 28 02:34:11 slug kernel: [38304.923798] Workqueue: events_unbound nv50_disp_atomic_commit_work [nouveau] Aug 28 02:34:11 slug kernel: [38304.923799] Call Trace: Aug 28 02:34:11 slug kernel: [38304.923808] __schedule+0x2a2/0x870 Aug 28 02:34:11 slug kernel: [38304.923812] schedule+0x28/0x80 Aug 28 02:34:11 slug kernel: [38304.923814] schedule_timeout+0x26d/0x390 Aug 28 02:34:11 slug kernel: [38304.923875] ? nvkm_client_map+0x10/0x10 [nouveau] Aug 28 02:34:11 slug kernel: [38304.923880] dma_fence_default_wait+0x238/0x2a0 Aug 28 02:34:11 slug kernel: [38304.923882] ? dma_fence_release+0x90/0x90 Aug 28 02:34:11 slug kernel: [38304.923884] dma_fence_wait_timeout+0x42/0xf0 Aug 28 02:34:11 slug kernel: [38304.923897] drm_atomic_helper_wait_for_fences+0x63/0xc0 [drm_kms_helper] Aug 28 02:34:11 slug kernel: [38304.923957] nv50_disp_atomic_commit_tail+0x7c/0x880 [nouveau] Aug 28 02:34:11 slug kernel: [38304.923963] ? __switch_to+0x15b/0x440 Aug 28 02:34:11 slug kernel: [38304.923966] ? __switch_to_asm+0x35/0x70 Aug 28 02:34:11 slug kernel: [38304.923971] process_one_work+0x1a7/0x3a0 Aug 28 02:34:11 slug kernel: [38304.923975] worker_thread+0x30/0x390 Aug 28 02:34:11 slug kernel: [38304.923978] ? create_worker+0x1a0/0x1a0 Aug 28 02:34:11 slug kernel: [38304.923981] kthread+0x112/0x130 Aug 28 02:34:11 slug kernel: [38304.923983] ? kthread_bind+0x30/0x30 Aug 28 02:34:11 slug kernel: [38304.923985] ret_from_fork+0x22/0x40 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] drm: bridge: add support for lontium LT9611UXC bridge
On 28-08-20, 18:01, Dmitry Baryshkov wrote:
> On 28/08/2020 17:18, Vinod Koul wrote:
> > On 28-08-20, 15:04, Dmitry Baryshkov wrote:
> > > +static int lt9611uxc_bridge_attach(struct drm_bridge *bridge,
> > > + enum drm_bridge_attach_flags flags)
> > > +{
> > > + struct lt9611uxc *lt9611uxc = bridge_to_lt9611uxc(bridge);
> > > + int ret;
> > > +
> > > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> > > + dev_err(lt9611uxc->dev, "Fix bridge driver to make connector
> > > optional!");
> >
> > Can we support both modes as I have done in lt9611, that way once the
> > conversion is done we can drop the init part and support conversion.
> >
> > I have patch for msm driver to set DRM_BRIDGE_ATTACH_NO_CONNECTOR, you
> > can use that to test
>
> Probably the message text is misleading. The driver as is does not work w/o
> DRM_BRIDGE_ATTACH_NO_CONNECTOR. Do you plan to push that patch into upstream
> tree?
It causes regression in laptop so have removed it ;( I need to fix that
first
The patch is here though and works on rb3 and db410c.
git.linaro.org/people/vinod.koul/kernel.git drm/no_connector
--
~Vinod
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] drm: bridge: add support for lontium LT9611UXC bridge
On Fri, Aug 28, 2020 at 05:33:00PM +0300, Laurent Pinchart wrote:
> On Fri, Aug 28, 2020 at 07:48:48PM +0530, Vinod Koul wrote:
> > On 28-08-20, 15:04, Dmitry Baryshkov wrote:
> >
> > > +#define EDID_BLOCK_SIZE 128
> > > +#define EDID_NUM_BLOCKS 2
> >
> > tab or space either one, not both ;)
> >
> > > +static struct mipi_dsi_device *lt9611uxc_attach_dsi(struct lt9611uxc
> > > *lt9611uxc,
> > > + struct device_node *dsi_node)
> >
> > Please align this with open parenthesis of preceding line (checkpatch
> > with --strict option will check this)
> >
> > > +static int lt9611uxc_bridge_attach(struct drm_bridge *bridge,
> > > + enum drm_bridge_attach_flags flags)
> > > +{
> > > + struct lt9611uxc *lt9611uxc = bridge_to_lt9611uxc(bridge);
> > > + int ret;
> > > +
> > > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> > > + dev_err(lt9611uxc->dev, "Fix bridge driver to make connector
> > > optional!");
> >
> > Can we support both modes as I have done in lt9611, that way once the
> > conversion is done we can drop the init part and support conversion.
>
> I was going to mention that :-) New drivers should support the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
Please ignore this comment, I just realized that the driver supports
DRM_BRIDGE_ATTACH_NO_CONNECTOR, it's the !DRM_BRIDGE_ATTACH_NO_CONNECTOR
case that is not supported, and that's totally fine.
> > I have patch for msm driver to set DRM_BRIDGE_ATTACH_NO_CONNECTOR, you
> > can use that to test
> >
> > > +static int lt9611uxc_hdmi_hw_params(struct device *dev, void *data,
> > > + struct hdmi_codec_daifmt *fmt,
> > > + struct hdmi_codec_params *hparms)
> > > +{
> > > + /*
> > > + * LT9611UXC will automatically detect rate and sample size, so no need
> > > + * to setup anything here.
> > > + */
> > > + return 0;
> > > +}
> >
> > Do we need dummy function?
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties
On 30.07.2020 14:28, Sylwester Nawrocki wrote:
> On 09.07.2020 23:04, Rob Herring wrote:
>> On Thu, Jul 02, 2020 at 06:37:19PM +0200, Sylwester Nawrocki wrote:
>>> Add documentation for new optional properties in the exynos bus nodes:
>>> samsung,interconnect-parent, #interconnect-cells, bus-width.
>>> These properties allow to specify the SoC interconnect structure which
>>> then allows the interconnect consumer devices to request specific
>>> bandwidth requirements.
>>>
>>> Signed-off-by: Artur Świgoń
>>> Signed-off-by: Sylwester Nawrocki
>>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>> @@ -51,6 +51,13 @@ Optional properties only for parent bus device:
>>> - exynos,saturation-ratio: the percentage value which is used to calibrate
>>> the performance count against total cycle count.
>>>
>>> +Optional properties for interconnect functionality (QoS frequency
>>> constraints):
>>> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
>>> + passive devices should point to same node as the exynos,parent-bus
>>> property.
>> Adding vendor specific properties for a common binding defeats the
>> point.
Actually we could do without any new property if we used existing interconnect
consumers binding to specify linking between the provider nodes. I think those
exynos-bus nodes could well be considered both the interconnect providers
and consumers. The example would then be something along the lines
(yes, I know the bus node naming needs to be fixed):
soc {
bus_dmc: bus_dmc {
compatible = "samsung,exynos-bus";
/* ... */
samsung,data-clock-ratio = <4>;
#interconnect-cells = <0>;
};
bus_leftbus: bus_leftbus {
compatible = "samsung,exynos-bus";
/* ... */
interconnects = <&bus_leftbus &bus_dmc>;
#interconnect-cells = <0>;
};
bus_display: bus_display {
compatible = "samsung,exynos-bus";
/* ... */
interconnects = <&bus_display &bus_leftbus>;
#interconnect-cells = <0>;
};
&mixer {
compatible = "samsung,exynos4212-mixer";
interconnects = <&bus_display &bus_dmc>;
/* ... */
};
};
What do you think, Georgi, Rob?
--
Regards
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] drm: bridge: add support for lontium LT9611UXC bridge
On Fri, Aug 28, 2020 at 07:48:48PM +0530, Vinod Koul wrote:
> On 28-08-20, 15:04, Dmitry Baryshkov wrote:
>
> > +#define EDID_BLOCK_SIZE128
> > +#define EDID_NUM_BLOCKS 2
>
> tab or space either one, not both ;)
>
> > +static struct mipi_dsi_device *lt9611uxc_attach_dsi(struct lt9611uxc
> > *lt9611uxc,
> > +struct device_node *dsi_node)
>
> Please align this with open parenthesis of preceding line (checkpatch
> with --strict option will check this)
>
> > +static int lt9611uxc_bridge_attach(struct drm_bridge *bridge,
> > + enum drm_bridge_attach_flags flags)
> > +{
> > + struct lt9611uxc *lt9611uxc = bridge_to_lt9611uxc(bridge);
> > + int ret;
> > +
> > + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> > + dev_err(lt9611uxc->dev, "Fix bridge driver to make connector
> > optional!");
>
> Can we support both modes as I have done in lt9611, that way once the
> conversion is done we can drop the init part and support conversion.
I was going to mention that :-) New drivers should support the
DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.
> I have patch for msm driver to set DRM_BRIDGE_ATTACH_NO_CONNECTOR, you
> can use that to test
>
> > +static int lt9611uxc_hdmi_hw_params(struct device *dev, void *data,
> > +struct hdmi_codec_daifmt *fmt,
> > +struct hdmi_codec_params *hparms)
> > +{
> > + /*
> > +* LT9611UXC will automatically detect rate and sample size, so no need
> > +* to setup anything here.
> > +*/
> > + return 0;
> > +}
>
> Do we need dummy function?
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] drm: bridge: add support for lontium LT9611UXC bridge
On 28-08-20, 15:04, Dmitry Baryshkov wrote:
> +#define EDID_BLOCK_SIZE 128
> +#define EDID_NUM_BLOCKS 2
tab or space either one, not both ;)
> +static struct mipi_dsi_device *lt9611uxc_attach_dsi(struct lt9611uxc
> *lt9611uxc,
> + struct device_node *dsi_node)
Please align this with open parenthesis of preceding line (checkpatch
with --strict option will check this)
> +static int lt9611uxc_bridge_attach(struct drm_bridge *bridge,
> + enum drm_bridge_attach_flags flags)
> +{
> + struct lt9611uxc *lt9611uxc = bridge_to_lt9611uxc(bridge);
> + int ret;
> +
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> + dev_err(lt9611uxc->dev, "Fix bridge driver to make connector
> optional!");
Can we support both modes as I have done in lt9611, that way once the
conversion is done we can drop the init part and support conversion.
I have patch for msm driver to set DRM_BRIDGE_ATTACH_NO_CONNECTOR, you
can use that to test
> +static int lt9611uxc_hdmi_hw_params(struct device *dev, void *data,
> + struct hdmi_codec_daifmt *fmt,
> + struct hdmi_codec_params *hparms)
> +{
> + /*
> + * LT9611UXC will automatically detect rate and sample size, so no need
> + * to setup anything here.
> + */
> + return 0;
> +}
Do we need dummy function?
--
~Vinod
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/tve200: Fix handling of platform_get_irq() error
On Thu, Aug 27, 2020 at 9:11 AM Krzysztof Kozlowski wrote:
> platform_get_irq() returns -ERRNO on error. In such case comparison
> to 0 would pass the check.
>
> Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200")
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/mcde: Fix handling of platform_get_irq() error
On Thu, Aug 27, 2020 at 9:11 AM Krzysztof Kozlowski wrote:
> platform_get_irq() returns -ERRNO on error. In such case comparison
> to 0 would pass the check.
>
> Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] dt-bindings: display: bridge: Add documentation for LT9611UXC
On 28-08-20, 15:04, Dmitry Baryshkov wrote: > Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports > and I2S port as input and one HDMI port as output. The LT9611UXC chip is > handled by a separate driver, but the bindings used are fully compatible > with the LT9611 chip, so let's reuse the lt9611.yaml schema. Acked-By: Vinod Koul -- ~Vinod ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] drm: bridge: add support for lontium LT9611UXC bridge
Hi Dmitry,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20200828]
[cannot apply to robh/for-next drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next linus/master drm-exynos/exynos-drm-next
drm/drm-next v5.9-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Dmitry-Baryshkov/Add-LT9611UXC-DSI-to-HDMI-bridge-support/20200828-200735
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/bridge/lontium-lt9611uxc.c: In function
'lt9611uxc_video_setup':
>> drivers/gpu/drm/bridge/lontium-lt9611uxc.c:322:49: warning: variable
>> 'vsync_porch' set but not used [-Wunused-but-set-variable]
322 | u32 v_total, vactive, vsync_len, vfront_porch, vsync_porch;
| ^~~
>> drivers/gpu/drm/bridge/lontium-lt9611uxc.c:321:49: warning: variable
>> 'hsync_porch' set but not used [-Wunused-but-set-variable]
321 | u32 h_total, hactive, hsync_len, hfront_porch, hsync_porch;
| ^~~
drivers/gpu/drm/bridge/lontium-lt9611uxc.c: At top level:
>> drivers/gpu/drm/bridge/lontium-lt9611uxc.c:473:14: warning: no previous
>> prototype for 'lt9611uxc_bridge_get_edid' [-Wmissing-prototypes]
473 | struct edid *lt9611uxc_bridge_get_edid(struct drm_bridge *bridge,
| ^
#
https://github.com/0day-ci/linux/commit/f1b935d064fd8924137d420e75eb050c3d66c22b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Dmitry-Baryshkov/Add-LT9611UXC-DSI-to-HDMI-bridge-support/20200828-200735
git checkout f1b935d064fd8924137d420e75eb050c3d66c22b
vim +/vsync_porch +322 drivers/gpu/drm/bridge/lontium-lt9611uxc.c
317
318 static void lt9611uxc_video_setup(struct lt9611uxc *lt9611uxc,
319 const struct drm_display_mode *mode)
320 {
> 321 u32 h_total, hactive, hsync_len, hfront_porch, hsync_porch;
> 322 u32 v_total, vactive, vsync_len, vfront_porch, vsync_porch;
323
324 h_total = mode->htotal;
325 v_total = mode->vtotal;
326
327 hactive = mode->hdisplay;
328 hsync_len = mode->hsync_end - mode->hsync_start;
329 hfront_porch = mode->hsync_start - mode->hdisplay;
330 hsync_porch = hsync_len + mode->htotal - mode->hsync_end;
331
332 vactive = mode->vdisplay;
333 vsync_len = mode->vsync_end - mode->vsync_start;
334 vfront_porch = mode->vsync_start - mode->vdisplay;
335 vsync_porch = vsync_len + mode->vtotal - mode->vsync_end;
336
337 regmap_write(lt9611uxc->regmap, 0xd00d, (u8)(v_total / 256));
338 regmap_write(lt9611uxc->regmap, 0xd00e, (u8)(v_total % 256));
339
340 regmap_write(lt9611uxc->regmap, 0xd00f, (u8)(vactive / 256));
341 regmap_write(lt9611uxc->regmap, 0xd010, (u8)(vactive % 256));
342
343 regmap_write(lt9611uxc->regmap, 0xd011, (u8)(h_total / 256));
344 regmap_write(lt9611uxc->regmap, 0xd012, (u8)(h_total % 256));
345
346 regmap_write(lt9611uxc->regmap, 0xd013, (u8)(hactive / 256));
347 regmap_write(lt9611uxc->regmap, 0xd014, (u8)(hactive % 256));
348
349 regmap_write(lt9611uxc->regmap, 0xd015, (u8)(vsync_len % 256));
350
351 regmap_update_bits(lt9611uxc->regmap, 0xd016, 0xf,
(u8)(hsync_len / 256));
352 regmap_write(lt9611uxc->regmap, 0xd017, (u8)(hsync_len % 256));
353
354 regmap_update_bits(lt9611uxc->regmap, 0xd018, 0xf,
(u8)(vfront_porch / 256));
355 regmap_write(lt9611uxc->regmap, 0xd019, (u8)(vfront_porch %
256));
356
357 regmap_update_bits(lt9611uxc->regmap, 0xd01a, 0xf,
(u8)(hfront_porch / 256));
358 regmap_write(lt9611uxc->regmap, 0xd01b, (u8)(hfront_porch %
256));
359 }
360
361 static void lt9611uxc_bridge_mode_set(struct drm_bridge *bridge,
362 const struct drm_display_mode *mode,
363
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi,
Am 28.08.20 um 08:30 schrieb Hoegeun Kwon:
> On 8/27/20 6:49 PM, Stefan Wahren wrote:
>> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
>>> Hi Stefan,
>>>
>>> Thank you for your review.
>>>
>>>
>>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
Hi Hoeguen,
Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
> There is a problem that the output does not work at a resolution
> exceeding FHD. To solve this, we need to adjust the bvb clock at a
> resolution exceeding FHD.
this patch introduces a mandatory clock, please update
brcm,bcm2835-hdmi.yaml first.
Is this clock physically available on BCM283x or only on BCM2711?
>>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>>>
>>> don't supported on pi 3 and pi 3+.
>>>
>>> Since 4k is not supported in versions prior to Raspberry Pi 4,
>>>
>>> I don't think we need to modify the bvb clock.
>>>
>>>
>>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>>>
>>> instead of 'brcm,bcm2835-hdmi.yaml'.
>> You are correct please update only brcm,bcm2711-hdmi.yaml.
>>
>> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
>> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
>> DTB. So making the BVB clock optional might be better?
> You are right, if use old dtb, we have a problem with the hdmi driver.
>
> So how about modifying it like this?
>
> @@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> *vc4_hdmi)
>
> vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
> if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
> - DRM_ERROR("Failed to get pixel bvb clock\n");
> - return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
> + DRM_WARN("Failed to get pixel bvb clock\n");
> + vc4_hdmi->pixel_bvb_clock = NULL;
> }
i think the better solution would be devm_clk_get_optional(), which
return NULL in case the clock doesn't exist.
Best regards
>
> vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
>
> If we modify like this, if there is no bvb clock in dtb, then
> pixel_bvb_clock will be null
>
> and it will not affect the clk control function below.
>
> - clk_set_rate()
> - clk_prepare_enable()
> - clk_disable_unprepare()
>
>
> Best regards
>
> Hoegeun
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/vkms: avoid warning in vkms_get_vblank_timestamp
This patch avoid the warning in vkms_get_vblank_timestamp when vblanks aren't
enabled. When running igt test kms_cursor_crc just after vkms module, the
warning raised like below. Initial value of vblank time is zero and
hrtimer.node.expires is also zero if vblank aren't enabled before. vkms module
isn't real hardware but just virtual hardware module. so vkms can't generate a
resonable timestamp when hrtimer is off. it's best to grab the current time.
[106444.464503] [IGT] kms_cursor_crc: starting subtest pipe-A-cursor-size-change
[106444.471475] WARNING: CPU: 0 PID: 10109 at
/home/realwakka/git/linux/drivers/gpu/drm/vkms//vkms_crtc.c:91
vkms_get_vblank_timestamp+0x42/0x50 [vkms]
[106444.471511] CPU: 0 PID: 10109 Comm: kms_cursor_crc Tainted: GW OE
5.9.0-rc1+ #6
[106444.471514] RIP: 0010:vkms_get_vblank_timestamp+0x42/0x50 [vkms]
[106444.471528] Call Trace:
[106444.471551] drm_get_last_vbltimestamp+0xb9/0xd0 [drm]
[106444.471566] drm_reset_vblank_timestamp+0x63/0xe0 [drm]
[106444.471579] drm_crtc_vblank_on+0x85/0x150 [drm]
[106444.471582] vkms_crtc_atomic_enable+0xe/0x10 [vkms]
[106444.471592] drm_atomic_helper_commit_modeset_enables+0x1db/0x230
[drm_kms_helper]
[106444.471594] vkms_atomic_commit_tail+0x38/0xc0 [vkms]
[106444.471601] commit_tail+0x97/0x130 [drm_kms_helper]
[106444.471608] drm_atomic_helper_commit+0x117/0x140 [drm_kms_helper]
[106444.471622] drm_atomic_commit+0x4a/0x50 [drm]
[106444.471629] drm_atomic_helper_set_config+0x63/0xb0 [drm_kms_helper]
[106444.471642] drm_mode_setcrtc+0x1d9/0x7b0 [drm]
[106444.471654] ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
[106444.471666] drm_ioctl_kernel+0xb6/0x100 [drm]
[106444.471677] drm_ioctl+0x3ad/0x470 [drm]
[106444.471688] ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
[106444.471692] ? tomoyo_file_ioctl+0x19/0x20
[106444.471694] __x64_sys_ioctl+0x96/0xd0
[106444.471697] do_syscall_64+0x37/0x80
[106444.471699] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Cc: Daniel Vetter
Cc: Rodrigo Siqueira
Cc: Haneen Mohammed
Cc: Melissa Wen
Signed-off-by: Sidong Yang
---
v3:
- add cc.
v2:
- modify commit message to make it a bit easier to understand.
---
drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..09c012d54d58 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -86,6 +86,11 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc *crtc,
struct vkms_output *output = &vkmsdev->output;
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
+ if (!READ_ONCE(vblank->enabled)) {
+ *vblank_time = ktime_get();
+ return true;
+ }
+
*vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
if (WARN_ON(*vblank_time == vblank->time))
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
On Thu, Aug 27, 2020 at 2:35 AM Christoph Hellwig wrote: > > On Tue, Aug 25, 2020 at 10:40:27AM -0700, Florian Fainelli wrote: > > Hi, > > > > On 8/24/2020 12:30 PM, Jim Quinlan wrote: > >> > >> Patchset Summary: > >>Enhance a PCIe host controller driver. Because of its unusual design > >>we are foced to change dev->dma_pfn_offset into a more general role > >>allowing multiple offsets. See the 'v1' notes below for more info. > > > > We are version 11 and counting, and it is not clear to me whether there is > > any chance of getting these patches reviewed and hopefully merged for the > > 5.10 merge window. > > > > There are a lot of different files being touched, so what would be the > > ideal way of routing those changes towards inclusion? > > FYI, I offered to take the dma-mapping bits through the dma-mapping tree. > I have a bit of a backlog, but plan to review and if Jim is ok with that > apply the current version. Sounds good to me. Thanks, Jim ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 10:17 AM Greg Kroah-Hartman wrote: > > On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > > On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman > > wrote: > > > > > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > > > The ION android code has long been marked to be removed, now that we > > > > > dma-buf support merged into the real part of the kernel. > > > > > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > > > quite a bit, and any Android device using the ion interface uses that > > > > > forked version and not this in-tree version, the in-tree copy of the > > > > > code is abandonded and not used by anyone. > > > > > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > > > order to keep the kernel building properly, which then causes merge > > > > > issues when merging those changes into the out-of-tree Android code, > > > > > and > > > > > you end up with two different groups of people (the in-kernel-tree > > > > > developers, and the Android kernel developers) who are both annoyed at > > > > > the current situation. Because of this problem, just drop the > > > > > in-kernel > > > > > copy of the ion code now, as it's not used, and is only causing > > > > > problems > > > > > for everyone involved. > > > > > > > > > > Cc: "Arve Hjønnevåg" > > > > > Cc: "Christian König" > > > > > Cc: Christian Brauner > > > > > Cc: Christoph Hellwig > > > > > Cc: Hridya Valsaraju > > > > > Cc: Joel Fernandes > > > > > Cc: John Stultz > > > > > Cc: Laura Abbott > > > > > Cc: Martijn Coenen > > > > > Cc: Shuah Khan > > > > > Cc: Sumit Semwal > > > > > Cc: Suren Baghdasaryan > > > > > Cc: Todd Kjos > > > > > Cc: de...@driverdev.osuosl.org > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > Cc: linaro-mm-...@lists.linaro.org > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > > > We discussed this at the Android MC on Monday and the plan was to > > > > remove it after the next LTS release. > > > > > > I know it was discussed, my point is that it is actually causing > > > problems now (with developers who want to change the internal kernel api > > > hitting issues, and newbies trying to clean up code in ways that isn't > > > exactly optimal wasting maintainer cycles), and that anyone who uses > > > this code, is not actually using this version of the code. Everyone who > > > relies on ion right now, is using the version that is in the Android > > > common kernel tree, which has diverged from this in-kernel way quite a > > > bit now for the reason that we didn't want to take any of those new > > > features in the in-kernel version. > > > > > > So this is a problem that we have caused by just wanting to wait, no one > > > is using this code, combined with it causing problems for the upstream > > > developers. > > > > > > There is nothing "magic" about the last kernel of the year that requires > > > this code to sit here until then. At that point in time, all users > > > will, again, be using the forked Android kernel version, and if we > > > delete this now here, that fork can remain just fine, with the added > > > benifit of it reducing developer workloads here in-kernel. > > > > > > So why wait? > > > > Hi, > > > > I don't know what is the right thing to do here. I just want to > > highlight that AOSP's audio (codec2) HAL depends on the ION system > > heap and it will break AOSP for people who boot mainline on their > > devices, even for just testing purpose like we do in Linaro. Right now > > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > > mainline and Sumit is already trying to upstream that vma naming > > patch. Removal of in-kernel ION, will just add more to that delta. > > As AOSP will continue to rely on ION after December of this year, all > you are doing is postponing the inevitable a few more months. > > Push back on the Android team to fix up the code to not use ION, they > know this needs to happen. > Hi all, We are currently working with the codec2 team to transition codec2 to use libdmabufheap instead of libion. It will definitely happen during the Android S timeframe. Thanks, Hridya > thanks, > > greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/virtio: fix unblank
On Mon, Aug 24, 2020 at 09:24:40AM +0200, Jiri Slaby wrote:
> On 18. 08. 20, 9:25, Gerd Hoffmann wrote:
> > When going through a disable/enable cycle without changing the
> > framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio:
> > skip set_scanout if framebuffer didn't change") causes the screen stay
> > blank. Add a bool to force an update to fix that.
> >
> > v2: use drm_atomic_crtc_needs_modeset() (Daniel).
> >
> > Cc: 1882...@bugs.launchpad.net
> > Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't
> > change")
> > Signed-off-by: Gerd Hoffmann
>
> Tested-by: Jiri Slaby
Ping. Need an ack or an review to merge this.
thanks,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: virtio: fix kconfig dependency warning
Hi, > config DRM_VIRTIO_GPU > tristate "Virtio GPU driver" > - depends on DRM && VIRTIO && MMU > + depends on DRM && VIRTIO_MENU && MMU Shouldn't this depend on both VIRTIO and VIRTIO_MENU, simliar to the other virtio drivers? take care, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3 v3] backlight: Add Kinetic KTD253 backlight driver
On Wed, 19 Aug 2020, Linus Walleij wrote: > The Kinetic KTD253 backlight driver is controlled with a > single GPIO line, but still supports a range of brightness > settings by sending fast pulses on the line. > > This is based off the source code release for the Samsung > GT-S7710 mobile phone. > > Cc: Sam Ravnborg > Reviewed-by: Daniel Thompson > Signed-off-by: Linus Walleij > --- > ChangeLog v2->v3: > - Collect Daniel's review tag. > ChangeLog v1->v2: > - Expose the 32 actual hardware levels of brightness directly > instead of using an interpolated "brightness" table. > - Use the new backlight_get_brightness() helper. > - Call backlight_update_status() in probe instead of calling > local functions to sync brightness. > - Sort includes alphabetically. > - Name the GPIO line "enable" and grab that in accordance > with the change to the DT bindings. > --- > MAINTAINERS| 6 + > drivers/video/backlight/Kconfig| 8 + > drivers/video/backlight/Makefile | 1 + > drivers/video/backlight/ktd253-backlight.c | 198 + > 4 files changed, 213 insertions(+) > create mode 100644 drivers/video/backlight/ktd253-backlight.c Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3 v3] dt-bindings: backlight: Add Kinetic KTD253 bindings
On Wed, 19 Aug 2020, Linus Walleij wrote: > This adds device tree bindings for the Kinetic KTD253 > white LED backlight driver. > > Cc: devicet...@vger.kernel.org > Cc: Sam Ravnborg > Signed-off-by: Linus Walleij > --- > ChangeLog v2->v3: > - Drop the pointless cargo-culted "default-on" property that > we were not using > - Correct the brightness in the example to something legal (13) > ChangeLog v1->v2: > - Create common.yaml for backlight as suggested by Sam and > use that. > - Rename the GPIO line "enable-gpios" > --- > .../leds/backlight/kinetic,ktd253.yaml| 46 +++ > 1 file changed, 46 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3 v3] dt-bindings: backlight: Add some common backlight properties
On Wed, 19 Aug 2020, Linus Walleij wrote: > Let's use a common.yaml include for the backlight like we do with > the LEDs. The LEDs are inherently incompatible so their bindings > cannot be reused for backlight. > > Cc: devicet...@vger.kernel.org > Suggested-by: Sam Ravnborg > Signed-off-by: Linus Walleij > --- > ChangeLog v2->v3: > - Drop the | for the description > - Drop the "default-on" property, we're not using it. > - Drop the minimum 0 for unsigned u32:s > ChangeLog v1->v2: > - New patch as suggested by Sam. > --- > .../bindings/leds/backlight/common.yaml | 34 +++ > 1 file changed, 34 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/leds/backlight/common.yaml Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/nouveau: Support DMA fence arrays
From: Thierry Reding
A DMA fence can be composed of multiple fences in an array. Support this
in the Nouveau driver by iteratively synchronizing to each DMA fence in
the array.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 31 ++---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 8530c2684832..c0849e09279c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -24,6 +24,7 @@
*
*/
+#include
#include
#include
#include
@@ -338,9 +339,9 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool lazy,
bool intr)
return 0;
}
-int
-nouveau_fence_sync(struct dma_fence *fence, struct nouveau_channel *chan,
- bool intr)
+static int
+__nouveau_fence_sync(struct dma_fence *fence, struct nouveau_channel *chan,
+bool intr)
{
struct nouveau_fence_chan *fctx = chan->fence;
struct nouveau_channel *prev = NULL;
@@ -363,6 +364,30 @@ nouveau_fence_sync(struct dma_fence *fence, struct
nouveau_channel *chan,
return ret;
}
+int
+nouveau_fence_sync(struct dma_fence *fence, struct nouveau_channel *chan,
+ bool intr)
+{
+ int ret = 0;
+
+ if (dma_fence_is_array(fence)) {
+ struct dma_fence_array *array = to_dma_fence_array(fence);
+ unsigned int i;
+
+ for (i = 0; i < array->num_fences; i++) {
+ struct dma_fence *f = array->fences[i];
+
+ ret = __nouveau_fence_sync(f, chan, intr);
+ if (ret < 0)
+ break;
+ }
+ } else {
+ ret = __nouveau_fence_sync(fence, chan, intr);
+ }
+
+ return ret;
+}
+
struct nouveau_fence *
nouveau_fence_ref(struct nouveau_fence *fence)
{
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/nouveau: Split nouveau_fence_sync()
From: Thierry Reding
Turn nouveau_fence_sync() into a low-level helper that adds fence waits
to the channel command stream. The new nouveau_bo_sync() helper replaces
the previous nouveau_fence_sync() implementation. It passes each of the
buffer object's fences to nouveau_fence_sync() in turn.
This provides more fine-grained control over fences which is needed by
subsequent patches for sync fd support.
Heavily based on work by Lauri Peltonen .
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 38 +-
drivers/gpu/drm/nouveau/nouveau_bo.h| 2 +
drivers/gpu/drm/nouveau/nouveau_fence.c | 68 +
drivers/gpu/drm/nouveau/nouveau_fence.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
6 files changed, 57 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 6416b6907aeb..4af702d0d6bf 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1117,7 +1117,7 @@ nv04_page_flip_emit(struct nouveau_channel *chan,
spin_unlock_irqrestore(&dev->event_lock, flags);
/* Synchronize with the old framebuffer */
- ret = nouveau_fence_sync(old_bo, chan, false, false);
+ ret = nouveau_bo_sync(old_bo, chan, false, false);
if (ret)
goto fail;
@@ -1183,7 +1183,7 @@ nv04_crtc_page_flip(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
goto fail_unpin;
/* synchronise rendering channel with the kernel's channel */
- ret = nouveau_fence_sync(new_bo, chan, false, true);
+ ret = nouveau_bo_sync(new_bo, chan, false, true);
if (ret) {
ttm_bo_unreserve(&new_bo->bo);
goto fail_unpin;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 9140387f30dc..25ceabfa741c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -574,6 +574,42 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
PAGE_SIZE, DMA_FROM_DEVICE);
}
+int
+nouveau_bo_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan,
+ bool exclusive, bool intr)
+{
+ struct dma_resv *resv = nvbo->bo.base.resv;
+ struct dma_resv_list *fobj;
+ struct dma_fence *fence;
+ int ret = 0, i;
+
+ if (!exclusive) {
+ ret = dma_resv_reserve_shared(resv, 1);
+ if (ret < 0)
+ return ret;
+ }
+
+ fobj = dma_resv_get_list(resv);
+ fence = dma_resv_get_excl(resv);
+
+ if (fence && (!exclusive || !fobj || !fobj->shared_count))
+ return nouveau_fence_sync(fence, chan, intr);
+
+ if (!exclusive || !fobj)
+ return ret;
+
+ for (i = 0; i < fobj->shared_count && !ret; ++i) {
+ fence = rcu_dereference_protected(fobj->shared[i],
+ dma_resv_held(resv));
+
+ ret = nouveau_fence_sync(fence, chan, intr);
+ if (ret < 0)
+ break;
+ }
+
+ return ret;
+}
+
int
nouveau_bo_validate(struct nouveau_bo *nvbo, bool interruptible,
bool no_wait_gpu)
@@ -717,7 +753,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
evict, bool intr,
}
mutex_lock_nested(&cli->mutex, SINGLE_DEPTH_NESTING);
- ret = nouveau_fence_sync(nouveau_bo(bo), chan, true, intr);
+ ret = nouveau_bo_sync(nouveau_bo(bo), chan, true, intr);
if (ret == 0) {
ret = drm->ttm.move(chan, bo, &bo->mem, new_reg);
if (ret == 0) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index aecb7481df0d..93d1706619a1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -96,6 +96,8 @@ int nouveau_bo_validate(struct nouveau_bo *, bool
interruptible,
bool no_wait_gpu);
void nouveau_bo_sync_for_device(struct nouveau_bo *nvbo);
void nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo);
+int nouveau_bo_sync(struct nouveau_bo *nvbo, struct nouveau_channel *channel,
+ bool exclusive, bool intr);
/* TODO: submit equivalent to TTM generic API upstream? */
static inline void __iomem *
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index e5dcbf67de7e..8e7550553584 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -339,66 +339,26 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool
lazy, bool intr)
}
int
-nouveau_fence_sync(struct nouveau_bo *nvbo, struct nouveau_channel *chan, bool
exclusive, bool intr)
+nouveau_fence_sync(struct dma_fence *fence, struct nouveau_channel
[PATCH 6/6] drm/nouveau: Allow zero pushbuffer submits
From: Thierry Reding
These are useful in cases where only a fence is to be created to wait
for existing jobs in the command stream.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 197 +-
1 file changed, 99 insertions(+), 98 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index b3ece731e4e1..c70a045d7141 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -816,9 +816,9 @@ __nouveau_gem_ioctl_pushbuf(struct drm_device *dev,
struct nouveau_abi16_chan *temp;
struct nouveau_drm *drm = nouveau_drm(dev);
struct drm_nouveau_gem_pushbuf *req = &request->base;
- struct drm_nouveau_gem_pushbuf_push *push;
struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
- struct drm_nouveau_gem_pushbuf_bo *bo;
+ struct drm_nouveau_gem_pushbuf_push *push = NULL;
+ struct drm_nouveau_gem_pushbuf_bo *bo = NULL;
struct drm_nouveau_gem_fence *fences = NULL;
struct nouveau_channel *chan = NULL;
struct validate_op op;
@@ -850,8 +850,6 @@ __nouveau_gem_ioctl_pushbuf(struct drm_device *dev,
req->vram_available = drm->gem.vram_available;
req->gart_available = drm->gem.gart_available;
- if (unlikely(req->nr_push == 0))
- goto out_next;
if (unlikely(req->nr_push > NOUVEAU_GEM_MAX_PUSH)) {
NV_PRINTK(err, cli, "pushbuf push count exceeds limit: %d max
%d\n",
@@ -871,33 +869,35 @@ __nouveau_gem_ioctl_pushbuf(struct drm_device *dev,
return nouveau_abi16_put(abi16, -EINVAL);
}
- push = u_memcpya(req->push, req->nr_push, sizeof(*push));
- if (IS_ERR(push))
- return nouveau_abi16_put(abi16, PTR_ERR(push));
+ if (req->nr_push > 0) {
+ push = u_memcpya(req->push, req->nr_push, sizeof(*push));
+ if (IS_ERR(push))
+ return nouveau_abi16_put(abi16, PTR_ERR(push));
- bo = u_memcpya(req->buffers, req->nr_buffers, sizeof(*bo));
- if (IS_ERR(bo)) {
- u_free(push);
- return nouveau_abi16_put(abi16, PTR_ERR(bo));
- }
+ bo = u_memcpya(req->buffers, req->nr_buffers, sizeof(*bo));
+ if (IS_ERR(bo)) {
+ u_free(push);
+ return nouveau_abi16_put(abi16, PTR_ERR(bo));
+ }
- /* Ensure all push buffers are on validate list */
- for (i = 0; i < req->nr_push; i++) {
- if (push[i].bo_index >= req->nr_buffers) {
- NV_PRINTK(err, cli, "push %d buffer not in list\n", i);
- ret = -EINVAL;
- goto out_prevalid;
+ /* Ensure all push buffers are on validate list */
+ for (i = 0; i < req->nr_push; i++) {
+ if (push[i].bo_index >= req->nr_buffers) {
+ NV_PRINTK(err, cli, "push %d buffer not in
list\n", i);
+ ret = -EINVAL;
+ goto out_prevalid;
+ }
}
- }
- /* Validate buffer list */
+ /* Validate buffer list */
revalidate:
- ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo,
- req->nr_buffers, &op, &do_reloc);
- if (ret) {
- if (ret != -ERESTARTSYS)
- NV_PRINTK(err, cli, "validate: %d\n", ret);
- goto out_prevalid;
+ ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo,
+ req->nr_buffers, &op,
&do_reloc);
+ if (ret) {
+ if (ret != -ERESTARTSYS)
+ NV_PRINTK(err, cli, "validate: %d\n", ret);
+ goto out_prevalid;
+ }
}
if (request->num_fences > 0) {
@@ -915,89 +915,89 @@ __nouveau_gem_ioctl_pushbuf(struct drm_device *dev,
}
/* Apply any relocations that are required */
- if (do_reloc) {
- if (!reloc) {
- validate_fini(&op, chan, NULL, bo);
- reloc = u_memcpya(req->relocs, req->nr_relocs,
sizeof(*reloc));
- if (IS_ERR(reloc)) {
- ret = PTR_ERR(reloc);
- goto out_prevalid;
- }
+ if (req->nr_push > 0) {
+ if (do_reloc) {
+ if (!reloc) {
+ validate_fini(&op, chan, NULL, bo);
+ reloc = u_memcpya(req->relocs, req->nr_relocs,
sizeof(*reloc));
+ if (IS_ERR(reloc)) {
+ ret = PTR_ERR(reloc);
+
[PATCH 2/6] drm/nouveau: Add nouveau_fence_ref()
From: Thierry Reding
This is a simple wrapper that increments the reference count of the
backing DMA fence.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 9 +
drivers/gpu/drm/nouveau/nouveau_fence.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index 8e7550553584..8530c2684832 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -363,6 +363,15 @@ nouveau_fence_sync(struct dma_fence *fence, struct
nouveau_channel *chan,
return ret;
}
+struct nouveau_fence *
+nouveau_fence_ref(struct nouveau_fence *fence)
+{
+ if (fence)
+ dma_fence_get(&fence->base);
+
+ return fence;
+}
+
void
nouveau_fence_unref(struct nouveau_fence **pfence)
{
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h
b/drivers/gpu/drm/nouveau/nouveau_fence.h
index 76cbf0c27a30..b8afd4b06445 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
@@ -19,6 +19,7 @@ struct nouveau_fence {
int nouveau_fence_new(struct nouveau_channel *, bool sysmem,
struct nouveau_fence **);
+struct nouveau_fence *nouveau_fence_ref(struct nouveau_fence *);
void nouveau_fence_unref(struct nouveau_fence **);
int nouveau_fence_emit(struct nouveau_fence *, struct nouveau_channel *);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/nouveau: Support sync FDs and syncobjs
From: Thierry Reding
Extends the new NOUVEAU_GEM_PUSHBUF2 IOCTL to accept and emit one or
more sync FDs and/or DRM native sync objects.
Signed-off-by: Thierry Reding
---
Note: If acceptable, this should be merged into the previous patch that
adds the new IOCTL.
drivers/gpu/drm/nouveau/nouveau_gem.c | 180 ++
include/uapi/drm/nouveau_drm.h| 21 ++-
2 files changed, 167 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 039f244c0a00..b3ece731e4e1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -26,6 +26,7 @@
#include
#include
+#include
#include "nouveau_drv.h"
#include "nouveau_dma.h"
@@ -680,12 +681,137 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
return ret;
}
+static int nouveau_channel_wait_fence(struct nouveau_channel *channel,
+ struct drm_file *file_priv,
+ struct drm_nouveau_gem_fence *f)
+{
+ struct dma_fence *fence;
+
+ if (f->flags & NOUVEAU_GEM_FENCE_FD) {
+ fence = sync_file_get_fence(f->handle);
+ if (!fence)
+ return -ENOENT;
+ } else {
+ struct drm_syncobj *syncobj;
+
+ syncobj = drm_syncobj_find(file_priv, f->handle);
+ if (!syncobj)
+ return -ENOENT;
+
+ fence = drm_syncobj_fence_get(syncobj);
+ drm_syncobj_put(syncobj);
+ }
+
+ return nouveau_fence_sync(fence, channel, true);
+}
+
+static int nouveau_channel_wait_fences(struct nouveau_channel *channel,
+ struct drm_file *file_priv,
+ struct drm_nouveau_gem_fence *fences,
+ unsigned int num_fences)
+{
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < num_fences; i++) {
+ if (fences[i].flags & NOUVEAU_GEM_FENCE_WAIT) {
+ ret = nouveau_channel_wait_fence(channel, file_priv,
+&fences[i]);
+ if (ret < 0)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static struct nouveau_fence *
+nouveau_channel_emit_fence(struct nouveau_channel *channel,
+ struct drm_file *file_priv,
+ struct drm_nouveau_gem_fence *f)
+{
+ struct nouveau_fence *fence;
+ int ret;
+
+ ret = nouveau_fence_new(channel, false, &fence);
+ if (ret < 0)
+ return ERR_PTR(ret);
+
+ if (f->flags & NOUVEAU_GEM_FENCE_FD) {
+ struct sync_file *file;
+ int fd;
+
+ fd = get_unused_fd_flags(O_CLOEXEC);
+ if (fd < 0) {
+ ret = fd;
+ goto put;
+ }
+
+ file = sync_file_create(&fence->base);
+ if (!file) {
+ put_unused_fd(fd);
+ ret = -ENOMEM;
+ goto put;
+ }
+
+ fd_install(fd, file->file);
+ f->handle = fd;
+ } else {
+ struct drm_syncobj *syncobj;
+
+ ret = drm_syncobj_create(&syncobj, 0, &fence->base);
+ if (ret < 0)
+ goto put;
+
+ ret = drm_syncobj_get_handle(file_priv, syncobj, &f->handle);
+ drm_syncobj_put(syncobj);
+ }
+
+put:
+ nouveau_fence_unref(&fence);
+ return ERR_PTR(ret);
+}
+
+static struct nouveau_fence *
+nouveau_channel_emit_fences(struct nouveau_channel *channel,
+ struct drm_file *file_priv,
+ struct drm_nouveau_gem_fence *fences,
+ unsigned int num_fences)
+{
+ struct nouveau_fence *fence = NULL, *f;
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < num_fences; i++) {
+ if (fences[i].flags & NOUVEAU_GEM_FENCE_EMIT) {
+ f = nouveau_channel_emit_fence(channel, file_priv,
+ &fences[i]);
+ if (IS_ERR(f))
+ return f;
+
+ if (!fence)
+ fence = f;
+ }
+ }
+
+ if (!fence) {
+ ret = nouveau_fence_new(channel, false, &fence);
+ if (ret)
+ fence = ERR_PTR(ret);
+ } else {
+ nouveau_fence_ref(fence);
+ }
+
+ return fence;
+}
+
static int
__nouveau_gem_ioctl_pushbuf(struct drm_device *dev,
struct drm_nouveau_gem_pushbuf2 *request,
struct drm_file *file_pr
[PATCH 3/6] drm/nouveau: Support fence FDs at kickoff
From: Thierry Reding
Add a new NOUVEAU_GEM_PUSHBUF2 IOCTL that accepts and emits a sync fence
FD from/to userspace if requested by the corresponding flags.
Based heavily on work by Lauri Peltonen
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
drivers/gpu/drm/nouveau/nouveau_gem.c | 79 +--
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +
include/uapi/drm/nouveau_drm.h| 14 +
4 files changed, 92 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 22d246acc5e5..c9cb2648a28b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -1140,6 +1140,7 @@ nouveau_ioctls[] = {
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_PREP, nouveau_gem_ioctl_cpu_prep,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_CPU_FINI, nouveau_gem_ioctl_cpu_fini,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(NOUVEAU_GEM_PUSHBUF2, nouveau_gem_ioctl_pushbuf2,
DRM_RENDER_ALLOW),
};
long
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 590e4c1d2e8a..039f244c0a00 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -24,6 +24,9 @@
*
*/
+#include
+#include
+
#include "nouveau_drv.h"
#include "nouveau_dma.h"
#include "nouveau_fence.h"
@@ -677,24 +680,30 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
return ret;
}
-int
-nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+static int
+__nouveau_gem_ioctl_pushbuf(struct drm_device *dev,
+ struct drm_nouveau_gem_pushbuf2 *request,
+ struct drm_file *file_priv)
{
struct nouveau_abi16 *abi16 = nouveau_abi16_get(file_priv);
struct nouveau_cli *cli = nouveau_cli(file_priv);
struct nouveau_abi16_chan *temp;
struct nouveau_drm *drm = nouveau_drm(dev);
- struct drm_nouveau_gem_pushbuf *req = data;
+ struct drm_nouveau_gem_pushbuf *req = &request->base;
struct drm_nouveau_gem_pushbuf_push *push;
struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
struct drm_nouveau_gem_pushbuf_bo *bo;
struct nouveau_channel *chan = NULL;
struct validate_op op;
struct nouveau_fence *fence = NULL;
+ struct dma_fence *prefence = NULL;
int i, j, ret = 0;
bool do_reloc = false, sync = false;
+ /* check for unrecognized flags */
+ if (request->flags & ~NOUVEAU_GEM_PUSHBUF_FLAGS)
+ return -EINVAL;
+
if (unlikely(!abi16))
return -ENOMEM;
@@ -764,6 +773,15 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
goto out_prevalid;
}
+ if (request->flags & NOUVEAU_GEM_PUSHBUF_FENCE_WAIT) {
+ prefence = sync_file_get_fence(request->fence);
+ if (prefence) {
+ ret = nouveau_fence_sync(prefence, chan, true);
+ if (ret < 0)
+ goto out;
+ }
+ }
+
/* Apply any relocations that are required */
if (do_reloc) {
if (!reloc) {
@@ -865,7 +883,30 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
}
}
+ if (request->flags & NOUVEAU_GEM_PUSHBUF_FENCE_EMIT) {
+ struct sync_file *file;
+ int fd;
+
+ fd = get_unused_fd_flags(O_CLOEXEC);
+ if (fd < 0) {
+ ret = fd;
+ goto out;
+ }
+
+ file = sync_file_create(&fence->base);
+ if (!file) {
+ put_unused_fd(fd);
+ goto out;
+ }
+
+ fd_install(fd, file->file);
+ request->fence = fd;
+ }
+
out:
+ if (prefence)
+ dma_fence_put(prefence);
+
validate_fini(&op, chan, fence, bo);
nouveau_fence_unref(&fence);
@@ -906,6 +947,27 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
return nouveau_abi16_put(abi16, ret);
}
+int
+nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_nouveau_gem_pushbuf *request = data;
+ struct drm_nouveau_gem_pushbuf2 req;
+ int ret;
+
+ memset(&req, 0, sizeof(req));
+ memcpy(&req.base, request, sizeof(*request));
+
+ ret = __nouveau_gem_ioctl_pushbuf(dev, &req, file_priv);
+
+ request->gart_available = req.base.gart_available;
+ request->vram_available = req.base.vram_available;
+ request->suffix1 = req.base.suffix1;
+ request->suff
[PATCH 0/6] drm/nouveau: Support sync FDs and sync objects
From: Thierry Reding Hi, This series implements a new IOCTL to submit push buffers that can optionally return a sync FD or sync object to userspace. This is useful in cases where userspace wants to synchronize operations between the GPU and another driver (such as KMS for display). Among other things this allows extensions such as eglDupNativeFenceFDANDROID to be implemented. Note that patch 4 modifies the ABI introduced in patch 3 by allowing DRM sync objects to be passed rather than only sync FDs. It also allows any number of sync FDs/objects to be passed in or emitted. I think those are useful features, but I left them in a separate patch in case everybody else thinks that this won't be needed. If we decide to merge the new ABI then patch 4 should be squashed into patch 3. The corresponding userspace changes can be found here: libdrm: https://gitlab.freedesktop.org/tagr/drm/-/commits/nouveau-sync-fd-v2/ mesa: https://gitlab.freedesktop.org/tagr/mesa/-/commits/nouveau-sync-fd/ I've verified that this works with kmscube's --atomic mode and Weston. Thierry Thierry Reding (6): drm/nouveau: Split nouveau_fence_sync() drm/nouveau: Add nouveau_fence_ref() drm/nouveau: Support fence FDs at kickoff drm/nouveau: Support sync FDs and syncobjs drm/nouveau: Support DMA fence arrays drm/nouveau: Allow zero pushbuffer submits drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 +- drivers/gpu/drm/nouveau/nouveau_bo.c| 38 ++- drivers/gpu/drm/nouveau/nouveau_bo.h| 2 + drivers/gpu/drm/nouveau/nouveau_drm.c | 1 + drivers/gpu/drm/nouveau/nouveau_fence.c | 90 +++--- drivers/gpu/drm/nouveau/nouveau_fence.h | 3 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 402 ++-- drivers/gpu/drm/nouveau/nouveau_gem.h | 2 + include/uapi/drm/nouveau_drm.h | 23 ++ 9 files changed, 410 insertions(+), 155 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bug report] drm/dp: annotate implicit fall throughs
On Tue, 25 Aug 2020, Dan Carpenter wrote:
> Hello Mathieu Malaterre,
>
> The patch e9c0c874711b: "drm/dp: annotate implicit fall throughs"
> from Jan 14, 2019, leads to the following static checker warning:
>
> drivers/gpu/drm/drm_dp_helper.c:495 drm_dp_downstream_max_bpc()
> warn: ignoring unreachable code.
>
> drivers/gpu/drm/drm_dp_helper.c
>467 int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>468const u8 port_cap[4])
>469 {
>470 int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
>471 bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
>472 DP_DETAILED_CAP_INFO_AVAILABLE;
>473 int bpc;
>474
>475 if (!detailed_cap_info)
>476 return 0;
>477
>478 switch (type) {
>479 case DP_DS_PORT_TYPE_VGA:
>480 case DP_DS_PORT_TYPE_DVI:
>481 case DP_DS_PORT_TYPE_HDMI:
>482 case DP_DS_PORT_TYPE_DP_DUALMODE:
>483 bpc = port_cap[2] & DP_DS_MAX_BPC_MASK;
> ^^
> This is 0x3.
>
>484
>485 switch (bpc) {
>486 case DP_DS_8BPC:
>487 return 8;
>488 case DP_DS_10BPC:
>489 return 10;
>490 case DP_DS_12BPC:
>491 return 12;
>492 case DP_DS_16BPC:
>493 return 16;
>494 }
>495 fallthrough;
>
> This fallthrough is impossible. Probably the way to work around the
> bogus warning is the change the fallthough to "return 0; /* impossible */"
> otherwise the fallthrough is sort of misleading...
Won't that be unreachable as well?
Maybe just add the default label to switch (bpc)?
BR,
Jani.
>
>496 default:
>497 return 0;
>498 }
>499 }
>
> regards,
> dan carpenter
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/24] backlight: add init macros and accessors
On Sun, Aug 23, 2020 at 12:45 PM Sam Ravnborg wrote:
> The first patch trims backlight_update_status() so it can be called with a
> NULL
> backlight_device. Then the caller do not need to add this check just to avoid
> a NULL reference.
>
> The backlight drivers uses several different patterns when registering
> a backlight:
>
> - Register backlight and assign properties later
> - Define a local backlight_properties variable and use memset
> - Define a const backlight_properties and assign relevant properties
>
> On top of this there was differences in what members was assigned.
>
> To align how backlight drivers are initialized introduce following helper
> macros:
> - DECLARE_BACKLIGHT_INIT_FIRMWARE()
> - DECLARE_BACKLIGHT_INIT_PLATFORM()
> - DECLARE_BACKLIGHT_INIT_RAW()
>
> The macros are introduced in patch 2.
>
> The backlight drivers used direct access to backlight_properties.
> Encapsulate these in get/set access operations resulting in following
> benefits:
> - The access methods can be called with a NULL pointer so logic around the
> access can be made simpler.
> - The update_brightness and enable_brightness simplifies the users
> - The code is in most cases more readable with the access operations.
> - When everyone uses the access methods refactoring in the backlight core is
> simpler.
>
> The get/set operations are introduced in patch 3.
>
> The gpio backlight driver received a small overhaul in a set of three patches.
> The result is a smaller and more readable driver.
>
> The remaining patches updates all backlight users in drivers/gpu/drm/*
> With this patch set all of drivers/gpu/drm/:
> - All backlight references to FB_BLANK* are gone from drm/*
> - All direct references to backlight properties are gone
> - All panel drivers uses the devm_ variant for registering backlight
> Daniel Vetter had some concerns with this for future updates,
> but we are aligned now and can update if refoctoring demands it
> - All panel drivers uses the backlight support in drm_panel
>
> Individual patches are only sent to the people listed in the patch + a few
> more.
> Please check https://lore.kernel.org/dri-devel/ for the full series.
>
> v2:
> - Documented BACKLIGHT_PROPS as it may be used by drivers
> - Dropped backlight_set_power_{on,off}, they were a mistake (Daniel)
> - Added backlight_update_brightness() and use it (Daniel)
> - Added backlight_enable_brightness() and use it
> - Moved remaining drm_panel driver to use backlight support in drm_panel
> - gpio backlight driver overhaul
>
> The patches are made on top of the for-backlight-next branch at
> https://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git
> The branch needs v5.8-rc1 backported to build as dev_err_probe()
> is used.
>
> The first 6 patches are candidates for the backlight tree.
> If they are applied then this should preferably be to an immutable
> branch we can merge to drm-misc-next where the drm patches shall go.
>
> The drm patches has known conflics and shall *not* be applied to the
> backlight tree, they are included in this patchset to show how the
> new functions are used.
>
> Diffstat for the drm bits alone looks nice:
> 25 files changed, 243 insertions(+), 460 deletions(-)
>
> Feedback welcome!
Thank you for trying to make backlight easier for developers.
I am a big supporter of this type of simplifications and
generalizations, it is what makes DRM great.
The series:
Acked-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: backlight: sky81452-backlight: Fix reference count imbalance on error
On Thu, 20 Aug 2020, Daniel Thompson wrote:
> On Thu, Aug 20, 2020 at 08:49:16AM +0100, Lee Jones wrote:
> > On Thu, 20 Aug 2020, dinghao@zju.edu.cn wrote:
> >
> > > > On Thu, 20 Aug 2020, dinghao@zju.edu.cn wrote:
> > > >
> > > > > > On Wed, 19 Aug 2020, Markus Elfring wrote:
> > > > > >
> > > > > > > > When of_property_read_u32_array() returns an error code,
> > > > > > > > a pairing refcount decrement is needed to keep np's refcount
> > > > > > > > balanced.
> > > > > > >
> > > > > > > Can another imperative wording be helpful for the change
> > > > > > > description?
> > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=18445bf405cb331117bc98427b1ba6f12418ad17#n151
> > > > > > >
> > > > > > > Would an other commit message be a bit nicer?
> > > > > > >
> > > > > > >
> > > > > > > …
> > > > > > > > +++ b/drivers/video/backlight/sky81452-backlight.c
> > > > > > > > @@ -217,6 +217,7 @@ static struct sky81452_bl_platform_data
> > > > > > > > *sky81452_bl_parse_dt(
> > > > > > > > num_entry);
> > > > > > > > if (ret < 0) {
> > > > > > > > dev_err(dev, "led-sources node is
> > > > > > > > invalid.\n");
> > > > > > > > + of_node_put(np);
> > > > > > > > return ERR_PTR(-EINVAL);
> > > > > > > > }
> > > > > > >
> > > > > > > I propose to add the jump target “put_node” so that a bit of
> > > > > > > common exception
> > > > > > > handling code can be better reused at the end of this function
> > > > > > > implementation.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Markus
> > > > > >
> > > > > > You can safely ignore any review comments from Markus!
> > > > > >
> > > > > > However, this patch doesn't appear to be in my inbox.
> > > > > >
> > > > > > Any ideas as to why?
> > > > > >
> > > > >
> > > > > Thank you for your advice. My outbox shows that this patch
> > > > > has reached your email server successfully. Maybe this
> > > > > ended up in your junk mail file?
> > > >
> > > > This has happened recently, so I was sure to check.
> > > >
> > > > Not there either unfortunately.
> > > >
> > > > Would you be kind enough to bounce/resend please?
> > >
> > > Sure.
> >
> > Looks like you sent it *only* to me. Please keep everyone else in Cc
> > when doing that, or I can't respond to everyone.
> >
> > Anyway, besides the subject line (which I can fix easily), the patch
> > looks good to me, but Daniel T must review.
>
> I've already offered a Reviewed-by for this patch. Perhaps it landed in
> the same place as the original patch...
Patch applied, thanks.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi Stefan & Hoegeun
On Wed, 26 Aug 2020 at 11:04, Stefan Wahren wrote:
>
> Hi Hoeguen,
>
> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
> > There is a problem that the output does not work at a resolution
> > exceeding FHD. To solve this, we need to adjust the bvb clock at a
> > resolution exceeding FHD.
>
> this patch introduces a mandatory clock, please update
> brcm,bcm2835-hdmi.yaml first.
>
> Is this clock physically available on BCM283x or only on BCM2711?
>
> I'm a little bit afraid, this change could break with older firmware
> versions on BCM283x.
Thanks for your keen eye on these things.
BVB only exists on 2711, not 283x.
It runs at 2 pixels/clock, must be an integer divider of I believe
600MHz, and between 75 and 300MHz.
This aim of this patch is fine as we currently only go up to 4k30, but
for 4k60 the BVB will need to be set to 300MHz.
Thanks
Dave
> Best regards
> Stefan
>
> >
> > Signed-off-by: Hoegeun Kwon
> > ---
> > drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
> > drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index 95ec5eedea39..eb3192d1fd86 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -80,6 +80,7 @@
> > # define VC4_HD_M_ENABLE BIT(0)
> >
> > #define CEC_CLOCK_FREQ 4
> > +#define VC4_HSM_MID_CLOCK 149985000
> >
> > static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> > {
> > @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
> > drm_encoder *encoder)
> > HDMI_WRITE(HDMI_VID_CTL,
> > HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
> >
> > + clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
> > clk_disable_unprepare(vc4_hdmi->hsm_clock);
> > clk_disable_unprepare(vc4_hdmi->pixel_clock);
> >
> > @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> > drm_encoder *encoder)
> > return;
> > }
> >
> > + ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
> > + (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 :
> > 7500));
> > + if (ret) {
> > + DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
> > + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> > + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> > + return;
> > + }
> > +
> > + ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
> > + if (ret) {
> > + DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
> > + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> > + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> > + return;
> > + }
> > +
> > if (vc4_hdmi->variant->reset)
> > vc4_hdmi->variant->reset(vc4_hdmi);
> >
> > @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> > *vc4_hdmi)
> > return PTR_ERR(vc4_hdmi->audio_clock);
> > }
> >
> > + vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
> > + if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
> > + DRM_ERROR("Failed to get pixel bvb clock\n");
> > + return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
> > + }
> > +
> > vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
> > if (IS_ERR(vc4_hdmi->reset)) {
> > DRM_ERROR("Failed to get HDMI reset line\n");
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> > index 0806c6d9f24e..63c6f8bddf1d 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> > @@ -147,6 +147,7 @@ struct vc4_hdmi {
> > struct clk *pixel_clock;
> > struct clk *hsm_clock;
> > struct clk *audio_clock;
> > + struct clk *pixel_bvb_clock;
> >
> > struct reset_control *reset;
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/5] Add support for iMX8MQ Display Controller Subsystem
Hi Lucas, I was wondering about the plans to merge this series. Since not many people can test it properly due to lack of DCSS support in the upstream NWL driver (which I heard it's coming soon) and a completely nonexistent HDP driver, are we going to take a leap of faith and merge it as is? Or should we wait? As to who is going to do the actual merge, I know we had a brief discussion about it some time ago and I was supposed to apply for drm-misc rights, however it feels a little awkward to merge my own code... :) Though, I might not even qualify for drm-misc rights anyway, considering I haven't been very active in this area... :/ On that note, I will probably need help with the merging, provided it's still happenning. Will you be able to help me out with this? Thanks, laurentiu On Fri, Jul 31, 2020 at 11:18:28AM +0300, Laurentiu Palcu wrote: > From: Laurentiu Palcu > > Hi, > > This patchset adds initial DCSS support for iMX8MQ chip. Initial support > includes only graphics plane support (no video planes), no HDR10 capabilities, > no graphics decompression (only linear, tiled and super-tiled buffers > allowed). > > Support for the rest of the features will be added incrementally, in > subsequent > patches. > > The patchset was tested with both HDP driver (in the downstream tree) and the > upstream > MIPI-DSI driver (with a couple of patches on top, to make it work correctly > with DCSS). > > Thanks, > Laurentiu > > Changes in v9: > * Fixed a compilation issue found by Guido in his setup: 'select >VIDEOMODE_HELPERS' was missing from Kconfig; > * Use imx8mq-clock.h in the bindings file so one can understand what >those clock values mean; > * no other changes done. Couldn't address the hang Guido reported as >it's not happening in my setup. However, in my tree, there are some >extra NWL and ADV patches applied on top of upstream ones... Also, >removing them and testing only with upstream, even if there's no >image out, does not produce a hang... :/ > > Changes in v8: > * Removed 'select RESET_CONTROLLER" from Kconfig as Philipp pointed >out. SRC is not used in DCSS driver; > * Nothing else changed; > > Changes in v7: > * Added a patch to initialize the connector using the drm_bridge_connector >API as Sam suggested. Tested it using NWL_DSI and ADV7535 with >Guido's patch [1] applied and one fix for ADV [2]. Also, some extra >patches for ADV and NWL were needed, from our downstream tree, which >will be upstreamed soon by their author; > * Rest of the patches are untouched; > > [1] https://lists.freedesktop.org/archives/dri-devel/2020-July/273025.html > [2] https://lists.freedesktop.org/archives/dri-devel/2020-July/273132.html > > Changes in v6: > * Addressed Rob's comment and added "additionalProperties: false" at >the end of the bindings' properties. However, this change surfaced >an issue with the assigned-clock* properties not being documented in >the properties section. Added the descriptions and the bindings patch >will need another review; > * Added an entry for DCSS driver in the MAINTAINERS file; > * Removed the component framework patch altogether; > > Changes in v5: > * Rebased to latest; > * Took out component framework support and made it a separate patch so >that people can still test with HDP driver, which makes use of it. >But the idea is to get rid of it once HDP driver's next versions >will remove component framework as well; > * Slight improvement to modesetting: avoid cutting off the pixel clock >if the new mode and the old one are equal. Also, in this case, is >not necessary to wait for DTG to shut off. This would allow to switch >from 8b RGB to 12b YUV422, for example, with no interruptions (at least >from DCSS point of view); > * Do not fire off CTXLD when going to suspend, unless it still has >entries that need to be committed to DCSS; > * Addressed Rob's comments on bindings; > > Changes in v4: > * Addressed Lucas and Philipp's comments: >* Added DRM_KMS_CMA_HELPER dependency in Kconfig; >* Removed usage of devm_ functions since I'm already doing all the > clean-up in the submodules_deinit(); >* Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush(); >* Removed en_completion variable from dcss_crtc since this was > introduced mainly to avoid vblank timeout warnings which were fixed > by arming the vblank event in flush() instead of begin(); >* Removed clks_on and irq_enabled flags since all the calls to > enabling/disabling clocks and interrupts were balanced; >* Removed the custom atomic_commit callback and used the DRM core > helper and, in the process, got rid of a workqueue that wasn't > necessary anymore; >* Fixed some minor DT binding issues flagged by Philipp; >* Some other minor changes suggested by Lucas; > * Removed YUV formats from the supported formats as these cannot work >
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 11:54:12AM -0700, John Stultz wrote: > On Thu, Aug 27, 2020 at 10:17 AM Greg Kroah-Hartman > wrote: > > On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > > > I don't know what is the right thing to do here. I just want to > > > highlight that AOSP's audio (codec2) HAL depends on the ION system > > > heap and it will break AOSP for people who boot mainline on their > > > devices, even for just testing purpose like we do in Linaro. Right now > > > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > > > mainline and Sumit is already trying to upstream that vma naming > > > patch. Removal of in-kernel ION, will just add more to that delta. > > > > As AOSP will continue to rely on ION after December of this year, all > > you are doing is postponing the inevitable a few more months. > > > > Push back on the Android team to fix up the code to not use ION, they > > know this needs to happen. > > The point though, is your main premise that no one is using this isn't true. They are using the version of ion in the Android kernel tree, yes, as it has new features that many people are relying on. The version that is currently in the kernel tree is crippled, and maybe works for some use cases, but not the majority, right? > I'm actively working with Hridya and folks on the codec2 HAL side to > transition this on the userland side: > https://android-review.googlesource.com/c/platform/frameworks/av/+/1368918/3 > > I'd like AOSP to not use ION after September (though being external I > can't promise anything), much less continuing after December. The android team has said they will be dropping ION use for the "next" Android release, which is sometime next year from what I recall. December is probably not going to happen :) > I want this migration to happen as much as anyone. But I'd prefer to > keep ION in staging until after the LTS is announced. Having both > around helps development for the transition, which helps us have a > reliable solution, which helps vendors to migrate and be able to do > comparative performance testing. I don't understand what having this in the "next" kernel helps us with here. And I would really really prefer to NOT have an outdated version of this code in a kernel tree that I am going to have to support for the next X number of years, when no one is using that version of the driver. What is this LTS fixation to keep this code around for? Who does it help? > I do appreciate that keeping it isn't free, but I also don't feel the > chaos-monkey approach here is really motivational in the way you > intend. I don't see it helping anyone to leave this around, except to cause merge issues for me, and development issues for other developers. Anyone who really wants this code, can easily revert the deletion and move on and grab the AOSP copy of the code. That's what they did when we deleted other Android features that are still relied on. Given that the "isn't free" is causing _me_ real pain, and not the actual users of this code, I am leaning toward wanting to move that pain/cost to those users, for obvious reasons. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge: Fix the dsi remote end-points
DSI end-points are supposed to be at node 0 and node 1 as per binding.
So fix this and use node 0 and node 1 for dsi.
Reported-by: Dmitry Baryshkov
Fixes: 23278bf54afe ("drm/bridge: Introduce LT9611 DSI to HDMI bridge")
Signed-off-by: Vinod Koul
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index 1009fc4ed4ed..d734d9402c35 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -960,13 +960,13 @@ static const struct drm_bridge_funcs lt9611_bridge_funcs
= {
static int lt9611_parse_dt(struct device *dev,
struct lt9611 *lt9611)
{
- lt9611->dsi0_node = of_graph_get_remote_node(dev->of_node, 1, -1);
+ lt9611->dsi0_node = of_graph_get_remote_node(dev->of_node, 0, -1);
if (!lt9611->dsi0_node) {
dev_err(lt9611->dev, "failed to get remote node for primary
dsi\n");
return -ENODEV;
}
- lt9611->dsi1_node = of_graph_get_remote_node(dev->of_node, 2, -1);
+ lt9611->dsi1_node = of_graph_get_remote_node(dev->of_node, 1, -1);
lt9611->ac_mode = of_property_read_bool(dev->of_node, "lt,ac-mode");
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: lvds: Invert the LVDS polarity
On Wed, Aug 26, 2020 at 01:13:33AM +0800, Chen-Yu Tsai wrote: > On Sat, Jul 4, 2020 at 9:38 PM Maxime Ripard wrote: > > > > The LVDS controller can invert the polarity / lanes of the LVDS output. > > The default polarity causes some issues on some panels. > > > > However, U-Boot has always used the opposite polarity without any reported > > issue, and the only currently supported LVDS panel in-tree (the TBS A711) > > seems to be able to work with both settings. > > > > Let's just use the same polarity than U-Boot to be more consistent and > > hopefully support all the panels. > > > > Cc: Ondrej Jirman > > Signed-off-by: Maxime Ripard > > Reviewed-by: Chen-Yu Tsai Applied, thanks! Maxime 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/8] Convert the intel iommu driver to the dma-iommu api
On 2020-08-23 6:04 p.m., Tom Murphy wrote:
> I have added a check for the sg_dma_len == 0 :
> """
> } __sgt_iter(struct scatterlist *sgl, bool dma) {
> struct sgt_iter s = { .sgp = sgl };
>
> + if (sgl && sg_dma_len(sgl) == 0)
> + s.sgp = NULL;
>
> if (s.sgp) {
> .
> """
> at location [1].
> but it doens't fix the problem.
Based on my read of the code, it looks like we also need to change usage
of sgl->length... Something like the rough patch below, maybe?
Also, Tom, do you have an updated version of the patchset to convert the
Intel IOMMU to dma-iommu available? The last one I've found doesn't
apply cleanly (I'm assuming parts of it have been merged in slightly
modified forms).
Thanks,
Logan
--
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
b/drivers/gpu/drm/i915/i915
index b7b59328cb76..9367ac801f0c 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.h
+++ b/drivers/gpu/drm/i915/i915_scatterlist.h
@@ -27,13 +27,19 @@ static __always_inline struct sgt_iter {
} __sgt_iter(struct scatterlist *sgl, bool dma) {
struct sgt_iter s = { .sgp = sgl };
+ if (sgl && !sg_dma_len(s.sgp))
+ s.sgp = NULL;
+
if (s.sgp) {
s.max = s.curr = s.sgp->offset;
- s.max += s.sgp->length;
- if (dma)
+
+ if (dma) {
+ s.max += sg_dma_len(s.sgp);
s.dma = sg_dma_address(s.sgp);
- else
+ } else {
+ s.max += s.sgp->length;
s.pfn = page_to_pfn(sg_page(s.sgp));
+ }
}
return s;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Aw: [PATCH 00/18] Convert arch/arm to use iommu-dma
Tested full series on bananapi r2 (mt7623/mt2701, 5.9-rc1 + hdmi-patches), works so far fbcon+x without issues Tested-by: Frank Wunderlich regards Frank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 2/8] drm/lima: Unconditionally call dev_pm_opp_of_remove_table()
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
Reviewed-by: Qiang Yu
Signed-off-by: Viresh Kumar
---
V2: Applied Reviewed by tag.
---
drivers/gpu/drm/lima/lima_devfreq.c | 6 +-
drivers/gpu/drm/lima/lima_devfreq.h | 1 -
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
b/drivers/gpu/drm/lima/lima_devfreq.c
index bbe02817721b..cd290d866a04 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.c
+++ b/drivers/gpu/drm/lima/lima_devfreq.c
@@ -105,10 +105,7 @@ void lima_devfreq_fini(struct lima_device *ldev)
devfreq->devfreq = NULL;
}
- if (devfreq->opp_of_table_added) {
- dev_pm_opp_of_remove_table(ldev->dev);
- devfreq->opp_of_table_added = false;
- }
+ dev_pm_opp_of_remove_table(ldev->dev);
if (devfreq->regulators_opp_table) {
dev_pm_opp_put_regulators(devfreq->regulators_opp_table);
@@ -162,7 +159,6 @@ int lima_devfreq_init(struct lima_device *ldev)
ret = dev_pm_opp_of_add_table(dev);
if (ret)
goto err_fini;
- ldevfreq->opp_of_table_added = true;
lima_devfreq_reset(ldevfreq);
diff --git a/drivers/gpu/drm/lima/lima_devfreq.h
b/drivers/gpu/drm/lima/lima_devfreq.h
index 5eed2975a375..2d9b3008ce77 100644
--- a/drivers/gpu/drm/lima/lima_devfreq.h
+++ b/drivers/gpu/drm/lima/lima_devfreq.h
@@ -18,7 +18,6 @@ struct lima_devfreq {
struct opp_table *clkname_opp_table;
struct opp_table *regulators_opp_table;
struct thermal_cooling_device *cooling;
- bool opp_of_table_added;
ktime_t busy_time;
ktime_t idle_time;
--
2.25.0.rc1.19.g042ed3e048af
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 13/36] PM / devfreq: tegra30: Use MC timings for building OPP table
Hi,
On 8/15/20 1:47 AM, Dmitry Osipenko wrote:
> 14.08.2020 05:02, Chanwoo Choi пишет:
>> Hi Dmitry,
>>
>> I add the minor comment. Except of some comments, it looks good to me.
>
> Hello, Chanwoo! Thank you for the review!
>
> ...
>>> +struct tegra_devfreq_soc_data {
>>> + const char *mc_compatible;
>>> +};
>>> +
>>> +static const struct tegra_devfreq_soc_data tegra30_soc = {
>>> + .mc_compatible = "nvidia,tegra30-mc",
>>> +};
>>> +
>>> +static const struct tegra_devfreq_soc_data tegra124_soc = {
>>> + .mc_compatible = "nvidia,tegra124-mc",
>>> +};
> .
>>> + soc_data = of_device_get_match_data(&pdev->dev);
>>
>> I think that better to check whether 'soc_data' is not NULL.
>
> It's a quite common misconception among kernel developers that
> of_device_get_match_data() may "accidentally" return NULL, but it
> couldn't if every driver's of_match[] entry has a non-NULL .data field
> and because the OF-matching already happened at the driver's probe-time
> [1], which is the case of this driver.
>
> [1] https://elixir.bootlin.com/linux/v5.8/source/drivers/of/device.c#L189
>
> Hence the NULL-checking is unnecessary.
>
> When I first encountered the of_device_get_match_data(), I was also
> thinking that adding the NULL-checks is a good idea, but later on
> somebody pointed out to me (maybe Thierry) that it's unnecessary to do.
OK. Thanks.
>
>>> +
>>> + mc = tegra_get_memory_controller(soc_data->mc_compatible);
>>> + if (IS_ERR(mc))
>>> + return PTR_ERR(mc);
>>
>> You better to add error log.
>
> In practice we should get only -EPROBE_DEFER here ever. I'll consider
> adding the message in the next revision, at least just for consistency.
In order to handle -EPROBE_DEFER, recommend the using of dev_err_probe().
(snip)
--
Best Regards,
Chanwoo Choi
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/18] staging/media/tegra-vde: Clean up IOMMU workaround
24.08.2020 17:01, Robin Murphy пишет: ... >> Robin, thank you very much for the clarifications! >> >> In accordance to yours comments, this patch can't be applied until Tegra >> SMMU will support IOMMU_DOMAIN_IDENTITY and implement def_domain_type() >> callback that returns IOMMU_DOMAIN_IDENTITY for the VDE device. >> >> Otherwise you're breaking the VDE driver because >> dma_buf_map_attachment() [1] returns the IOMMU SGT of the implicit >> domain which is then mapped into the VDE's explicit domain [2], and this >> is a nonsense. > > It's true that iommu_dma_ops will do some work in the unattached default > domain, but non-coherent cache maintenance will still be performed > correctly on the underlying memory, which is really all that you care > about for this case. As for tegra_vde_iommu_map(), that seems to do the > right thing in only referencing the physical side of the scatterlist > (via iommu_map_sg()) and ignoring the DMA side, so things ought to work > out OK even if it is a little non-obvious. I'll need to double-check this, it's indeed not clear to me right now. I see that if Tegra DRM driver uses implicit IOMMU domain, then when VDE driver imports DMA-buf from Terga DRM and the imported buffer will be auto-mapped to the implicit VDE IOVA [1]. [1] https://elixir.bootlin.com/linux/v5.9-rc2/source/drivers/gpu/drm/tegra/gem.c#L574 >> Hence, either VDE driver should bypass iommu_dma_ops from the start or >> it needs a way to kick out the ops, like it does this using ARM's >> arm_iommu_detach_device(). >> >> >> The same applies to the Tegra GPU devices, otherwise you're breaking >> them as well because Tegra DRM is sensible to implicit vs explicit >> domain. > > Note that Tegra DRM will only be as broken as its current state on > arm64, and I was under the impression that that was OK now - at least I > don't recall seeing any complaints since 43c5bf11a610. Although that > commit and the one before it are resolving the scalability issue that > they describe, it was very much in my mind at the time that they also > have the happy side-effect described above - the default domain isn't > *completely* out of the way, but it's far enough that sensible cases > should be able to work as expected. The Tegra DRM has a very special quirk for ARM32 that was added in this commit [2] and driver relies on checking of whether explicit or implicit IOMMU is used in order to activate the quirk. [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=273da5a046965ccf0ec79eb63f2d5173467e20fa Once the implicit IOMMU is used for the DRM driver, the quirk no longer works (if I'm not missing something). This problem needs to be resolved before implicit IOMMU could be used by the Tegra DRM on ARM32. >> BTW, I tried to apply this series and T30 doesn't boot anymore. I don't >> have more info for now. > > Yeah, I'm still trying to get to the bottom of whether it's actually > working as intended at all, even on my RK3288. So far my debugging > instrumentation has been confusingly inconclusive :/ Surely it will take some time to resolve all the problems and it's great that you're pushing this work! I'll try to help with fixing the ARM32 Tegra side of the problems. I added this to my "TODO" list and should be able to take a closer look during of this/next weeks! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: remove set but not used 'ulBestVCO'
This addresses the following gcc warning with "make W=1":
drivers/video/fbdev/kyro/STG4000InitDevice.c: In function
‘ProgramClock’:
drivers/video/fbdev/kyro/STG4000InitDevice.c:123:6: warning: variable
‘ulBestVCO’ set but not used [-Wunused-but-set-variable]
123 | u32 ulBestVCO = 0, ulBestClk = 0, ulBestScore = 0;
| ^
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/video/fbdev/kyro/STG4000InitDevice.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/kyro/STG4000InitDevice.c
b/drivers/video/fbdev/kyro/STG4000InitDevice.c
index edaeec2d9590..21875d3c2dc2 100644
--- a/drivers/video/fbdev/kyro/STG4000InitDevice.c
+++ b/drivers/video/fbdev/kyro/STG4000InitDevice.c
@@ -120,7 +120,7 @@ u32 ProgramClock(u32 refClock,
{
u32 R = 0, F = 0, OD = 0, ODIndex = 0;
u32 ulBestR = 0, ulBestF = 0, ulBestOD = 0;
- u32 ulBestVCO = 0, ulBestClk = 0, ulBestScore = 0;
+ u32 ulBestClk = 0, ulBestScore = 0;
u32 ulScore, ulPhaseScore, ulVcoScore;
u32 ulTmp = 0, ulVCO;
u32 ulScaleClockReq, ulMinClock, ulMaxClock;
@@ -189,7 +189,6 @@ u32 ProgramClock(u32 refClock,
ulScore = ulPhaseScore +
ulVcoScore;
if (!ulBestScore) {
- ulBestVCO = ulVCO;
ulBestOD = OD;
ulBestF = F;
ulBestR = R;
@@ -206,7 +205,6 @@ u32 ProgramClock(u32 refClock,
but we shall keep this code in case new restrictions
come into play
--*/
if ((ulScore >= ulBestScore) &&
(OD > 0)) {
- ulBestVCO = ulVCO;
ulBestOD = OD;
ulBestF = F;
ulBestR = R;
--
2.25.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)
Hi Ezequiel, > Am 24.08.2020 um 19:38 schrieb Ezequiel Garcia > : > > On Mon, 24 Aug 2020 at 13:05, H. Nikolaus Schaller wrote: >> >> Hi Ezequiel, > > The fix is just re-organizing the code a bit. Just pushed a possible > fix for that (following the IPU handling by Paul Cercueil), > please feel free to test this: > > https://gitlab.collabora.com/linux/0day/-/commits/jz4780-drm-hdmi-module-fix-v5.9-rc2 Works well (after doing a minor fix to the CI20 defconfig)! > > FWIW, my test setup uses mainline vanilla U-Boot v2020.07. > The kernel is loaded via TFTP. Debian mipsel is mounted via NFS > (which means dm9000 works). I'm testing with weston and modetest. > > Note that enabling DRM_INGENIC_IPU will make the driver > fail to load, as the IPU is not optional (and not present on ci20.dts). > A minor thing to fix. > > Cheers, > Ezequiel > >> And it seems to differ significantly from what Paul has developed recently >> to make it work. It seems to be quite lucky that we have a working setup now >> :) >> >>> Nikolaus, Paul: Do you have plans to submit these? >> >> Yes, as soon as we are sure that it works (and when it doesn't). >> >> But thanks to your work it is now much easier to improve things, since we >> are no longer looking for a break-through but just have to avoid regressions. >> >>> If not, I'll be happy to get them out the door for review. >> >> Let it mature a little first and have it tested on more setups and rebased >> to mainline v5.9-rc2 :) > Am 24.08.2020 um 23:11 schrieb Paul Cercueil : > > DRM drivers follow their own schedule, you should rebase to drm-misc-next > instead. > With the comment from Paul, I think it is best if you push them for review. My patch set based on v5.9-rc2 is here (including one EFUSE patch which I have included only for making my Ethernet interface work for testing): https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/jz4780-hdmi-v5 Please take it, do the required squashes and rebasing and post them for discussion to the appropriate lists. BR and thanks for this great break through, Nikolaus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/ingenic: Fix leak of device_node pointer
of_graph_get_remote_node() requires of_node_put() to be called on the
device_node pointer when it's no more in use.
Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index ada990a7f911..c1bcb93aed2d 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -978,6 +978,7 @@ static int ingenic_drm_probe(struct platform_device *pdev)
}
drm_of_component_match_add(dev, &match, compare_of, np);
+ of_node_put(np);
return component_master_add_with_match(dev, &ingenic_master_ops, match);
}
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4] drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets
add event thread to execute events serially from event queue. Also
timeout mode is supported which allow an event be deferred to be
executed at later time. Both link and phy compliant tests had been
done successfully.
Changes in v2:
- Fix potential deadlock by removing redundant connect_mutex
- Check and enable link clock during modeset
- Drop unused code and fix function prototypes.
- set sink power to normal operation state (D0) before DPCD read
Changes in v3:
- push idle pattern at main link before timing generator off
- add timeout handles for both connect and disconnect
Changes in v4:
- fix crash while device in suspend mode
- also fix modeset test
This patch depends-on:
https://lkml.kernel.org/lkml/20200827211658.27479-1-tan...@codeaurora.org/
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 6 +
drivers/gpu/drm/msm/dp/dp_aux.c | 5 +-
drivers/gpu/drm/msm/dp/dp_catalog.c | 77 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 370 ++---
drivers/gpu/drm/msm/dp/dp_ctrl.h| 3 +-
drivers/gpu/drm/msm/dp/dp_display.c | 789 +---
drivers/gpu/drm/msm/dp/dp_display.h | 1 -
drivers/gpu/drm/msm/dp/dp_drm.c | 4 -
drivers/gpu/drm/msm/dp/dp_hpd.c | 2 +-
drivers/gpu/drm/msm/dp/dp_hpd.h | 1 +
drivers/gpu/drm/msm/dp/dp_link.c| 22 +-
drivers/gpu/drm/msm/dp/dp_panel.c | 78 +-
drivers/gpu/drm/msm/dp/dp_panel.h | 9 +-
drivers/gpu/drm/msm/dp/dp_parser.c | 42 +-
drivers/gpu/drm/msm/dp/dp_parser.h | 2 +
drivers/gpu/drm/msm/dp/dp_power.c | 46 +-
drivers/gpu/drm/msm/dp/dp_power.h | 13 +
drivers/gpu/drm/msm/dp/dp_reg.h | 1 +
drivers/gpu/drm/msm/msm_drv.h | 1 +
19 files changed, 1012 insertions(+), 460 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 6a9e257d2fe6..81373bd38f0b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1221,6 +1221,11 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
/* wait for idle */
dpu_encoder_wait_for_event(drm_enc, MSM_ENC_TX_COMPLETE);
+ if (drm_enc->encoder_type == DRM_MODE_ENCODER_TMDS && priv->dp) {
+ if (msm_dp_display_pre_disable(priv->dp, drm_enc))
+ DPU_ERROR_ENC(dpu_enc, "dp display push idle failed\n");
+ }
+
dpu_encoder_resource_control(drm_enc, DPU_ENC_RC_EVENT_PRE_STOP);
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
@@ -1230,6 +1235,7 @@ static void dpu_encoder_virt_disable(struct drm_encoder
*drm_enc)
phys->ops.disable(phys);
}
+
/* after phys waits for frame-done, should be no more frames pending */
if (atomic_xchg(&dpu_enc->frame_done_timeout_ms, 0)) {
DPU_ERROR("enc%d timeout pending\n", drm_enc->base.id);
diff --git a/drivers/gpu/drm/msm/dp/dp_aux.c b/drivers/gpu/drm/msm/dp/dp_aux.c
index 6bf3a5712968..ff38bd140b32 100644
--- a/drivers/gpu/drm/msm/dp/dp_aux.c
+++ b/drivers/gpu/drm/msm/dp/dp_aux.c
@@ -188,9 +188,9 @@ static void dp_aux_native_handler(struct dp_aux_private
*aux)
aux->aux_error_num = DP_AUX_ERR_ADDR;
else if (isr & DP_INTR_TIMEOUT)
aux->aux_error_num = DP_AUX_ERR_TOUT;
- if (isr & DP_INTR_NACK_DEFER)
+ else if (isr & DP_INTR_NACK_DEFER)
aux->aux_error_num = DP_AUX_ERR_NACK;
- if (isr & DP_INTR_AUX_ERROR) {
+ else if (isr & DP_INTR_AUX_ERROR) {
aux->aux_error_num = DP_AUX_ERR_PHY;
dp_catalog_aux_clear_hw_interrupts(aux->catalog);
}
@@ -384,6 +384,7 @@ static ssize_t dp_aux_transfer(struct drm_dp_aux *dp_aux,
PHY_AUX_CFG1);
dp_catalog_aux_reset(aux->catalog);
}
+ usleep_range(400, 500); /* at least 400us to next try */
goto unlock_exit;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index c16072630d40..67abb90953e4 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -536,16 +536,21 @@ void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog
*dp_catalog,
* To make sure link reg writes happens before other operation,
* dp_write_link() function uses writel()
*/
- dp_write_link(catalog, REG_DP_MAINLINK_CTRL,
- DP_MAINLINK_FB_BOUNDARY_SEL);
- dp_write_link(catalog, REG_DP_MAINLINK_CTRL,
- DP_MAINLINK_FB_BOUNDARY_SEL |
- DP_MAINLINK_CTRL_RESET);
- dp_write_link(catalog, REG_DP_MAINLINK_CT
Aw: Re: [PATCH v5 3/7] drm/mediatek: disable tmds on mt2701
Hi Matthias, any opinions about the dts-changes? maybe series except the tmds-Patch get merged...so i add it only to my own repo till we find a better way? currently mainline does not support hdmi at all for the board. the tmds-patch is only a fix for specific resolutions which have a "flickering" without this Patch. regards Frank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: remove set but not used 'ulCoreClock'
This addresses the following gcc warning with "make W=1":
drivers/video/fbdev/kyro/STG4000InitDevice.c: In function
‘SetCoreClockPLL’:
drivers/video/fbdev/kyro/STG4000InitDevice.c:247:6: warning: variable
‘ulCoreClock’ set but not used [-Wunused-but-set-variable] // yanaijie
fixed
247 | u32 ulCoreClock;
| ^~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/video/fbdev/kyro/STG4000InitDevice.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/kyro/STG4000InitDevice.c
b/drivers/video/fbdev/kyro/STG4000InitDevice.c
index 1d3f2080aa6f..edaeec2d9590 100644
--- a/drivers/video/fbdev/kyro/STG4000InitDevice.c
+++ b/drivers/video/fbdev/kyro/STG4000InitDevice.c
@@ -244,7 +244,6 @@ int SetCoreClockPLL(volatile STG4000REG __iomem *pSTGReg,
struct pci_dev *pDev)
{
u32 F, R, P;
u16 core_pll = 0, sub;
- u32 ulCoreClock;
u32 tmp;
u32 ulChipSpeed;
@@ -282,7 +281,7 @@ int SetCoreClockPLL(volatile STG4000REG __iomem *pSTGReg,
struct pci_dev *pDev)
if (ulChipSpeed == 0)
return -EINVAL;
- ulCoreClock = ProgramClock(REF_FREQ, CORE_PLL_FREQ, &F, &R, &P);
+ ProgramClock(REF_FREQ, CORE_PLL_FREQ, &F, &R, &P);
core_pll |= ((P) | ((F - 2) << 2) | ((R - 2) << 11));
--
2.25.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/1] drm/bridge: ps8640: Make sure all needed is powered to get the EDID
The first 4 patches of the series version 2: - drm/bridge_connector: Set default status connected for eDP connectors - drm/bridge: ps8640: Get the EDID from eDP control - drm/bridge: ps8640: Return an error for incorrect attach flags - drm/bridge: ps8640: Print an error if VDO control fails Are already applied to drm-misc-next, so I removed from this series. The pending patch is part of the original series and is a rework of the power handling to get the EDID. Basically, we need to make sure all the needed is powered to be able to get the EDID. Before, we saw that getting the EDID failed as explained in the third patch. [1] https://lkml.org/lkml/2020/6/15/1208 Changes in v3: - Make poweron/poweroff and pre_enable/post_disable reverse one to each other (Sam Ravnborg) Changes in v2: - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg) Enric Balletbo i Serra (1): drm/bridge: ps8640: Rework power state handling drivers/gpu/drm/bridge/parade-ps8640.c | 68 ++ 1 file changed, 58 insertions(+), 10 deletions(-) -- 2.28.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On Thu, Aug 27, 2020 at 10:31:41PM +0530, Amit Pundir wrote: > On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman > wrote: > > > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > > The ION android code has long been marked to be removed, now that we > > > > dma-buf support merged into the real part of the kernel. > > > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > > quite a bit, and any Android device using the ion interface uses that > > > > forked version and not this in-tree version, the in-tree copy of the > > > > code is abandonded and not used by anyone. > > > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > > order to keep the kernel building properly, which then causes merge > > > > issues when merging those changes into the out-of-tree Android code, and > > > > you end up with two different groups of people (the in-kernel-tree > > > > developers, and the Android kernel developers) who are both annoyed at > > > > the current situation. Because of this problem, just drop the in-kernel > > > > copy of the ion code now, as it's not used, and is only causing problems > > > > for everyone involved. > > > > > > > > Cc: "Arve Hjønnevåg" > > > > Cc: "Christian König" > > > > Cc: Christian Brauner > > > > Cc: Christoph Hellwig > > > > Cc: Hridya Valsaraju > > > > Cc: Joel Fernandes > > > > Cc: John Stultz > > > > Cc: Laura Abbott > > > > Cc: Martijn Coenen > > > > Cc: Shuah Khan > > > > Cc: Sumit Semwal > > > > Cc: Suren Baghdasaryan > > > > Cc: Todd Kjos > > > > Cc: de...@driverdev.osuosl.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: linaro-mm-...@lists.linaro.org > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > We discussed this at the Android MC on Monday and the plan was to > > > remove it after the next LTS release. > > > > I know it was discussed, my point is that it is actually causing > > problems now (with developers who want to change the internal kernel api > > hitting issues, and newbies trying to clean up code in ways that isn't > > exactly optimal wasting maintainer cycles), and that anyone who uses > > this code, is not actually using this version of the code. Everyone who > > relies on ion right now, is using the version that is in the Android > > common kernel tree, which has diverged from this in-kernel way quite a > > bit now for the reason that we didn't want to take any of those new > > features in the in-kernel version. > > > > So this is a problem that we have caused by just wanting to wait, no one > > is using this code, combined with it causing problems for the upstream > > developers. > > > > There is nothing "magic" about the last kernel of the year that requires > > this code to sit here until then. At that point in time, all users > > will, again, be using the forked Android kernel version, and if we > > delete this now here, that fork can remain just fine, with the added > > benifit of it reducing developer workloads here in-kernel. > > > > So why wait? > > Hi, > > I don't know what is the right thing to do here. I just want to > highlight that AOSP's audio (codec2) HAL depends on the ION system > heap and it will break AOSP for people who boot mainline on their > devices, even for just testing purpose like we do in Linaro. Right now > we need only 1 (Android specific out-of-tree) patch to boot AOSP with > mainline and Sumit is already trying to upstream that vma naming > patch. Removal of in-kernel ION, will just add more to that delta. So that means you now have to carry 2 patches instead of 1, right? That's not that bad :-D. BTW, why doesn't your mainline testing use dmabuf already? AFAIK, upstream has inertia catching up to products etc, so sooner its removed the better if it is mostly dead (Before it turns into ashmem which nobody can remove). My 2c. thanks, - Joel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 0/8] opp: Unconditionally call dev_pm_opp_of_remove_table()
Hello, This cleans up some of the user code around calls to dev_pm_opp_of_remove_table(). All the patches can be picked by respective maintainers directly except for the last patch, which needs the previous two to get merged first. These are based for 5.9-rc1. Rajendra, Since most of these changes are related to qcom stuff, it would be great if you can give them a try. I wasn't able to test them due to lack of hardware. Ulf, I had to revise the sdhci patch, sorry about that. Please pick this one. Diff between V1 and V2 is mentioned in each of the patches separately. Viresh Kumar (8): cpufreq: imx6q: Unconditionally call dev_pm_opp_of_remove_table() drm/lima: Unconditionally call dev_pm_opp_of_remove_table() drm/msm: Unconditionally call dev_pm_opp_of_remove_table() mmc: sdhci-msm: Unconditionally call dev_pm_opp_of_remove_table() spi: spi-geni-qcom: Unconditionally call dev_pm_opp_of_remove_table() spi: spi-qcom-qspi: Unconditionally call dev_pm_opp_of_remove_table() tty: serial: qcom_geni_serial: Unconditionally call dev_pm_opp_of_remove_table() qcom-geni-se: remove has_opp_table drivers/cpufreq/imx6q-cpufreq.c | 10 ++ drivers/gpu/drm/lima/lima_devfreq.c | 6 +- drivers/gpu/drm/lima/lima_devfreq.h | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 14 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 - drivers/gpu/drm/msm/dsi/dsi_host.c | 8 ++-- drivers/mmc/host/sdhci-msm.c| 14 +- drivers/spi/spi-geni-qcom.c | 13 + drivers/spi/spi-qcom-qspi.c | 15 ++- drivers/tty/serial/qcom_geni_serial.c | 13 + include/linux/qcom-geni-se.h| 2 -- 11 files changed, 31 insertions(+), 66 deletions(-) base-commit: 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5 -- 2.25.0.rc1.19.g042ed3e048af ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Fix memory leak in amdgpu_dm_mode_config_init()
> When amdgpu_display_modeset_create_props() fails, state and
> state->context should be freed to prevent memleak. It's the
> same when amdgpu_dm_audio_init() fails.
* Can another imperative wording become helpful for the change description?
* Would you like to consider the tag “Fixes” for the commit message?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c?id=08572451b4b1783fdff787b0188c4d50fdf96b81
…
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2834,12 +2834,18 @@ static int amdgpu_dm_mode_config_init(struct
> amdgpu_device *adev)
> &dm_atomic_state_funcs);
>
> r = amdgpu_display_modeset_create_props(adev);
> - if (r)
> + if (r) {
> + dc_release_state(state->context);
> + kfree(state);
> return r;
> + }
>
> r = amdgpu_dm_audio_init(adev);
> - if (r)
> + if (r) {
> + dc_release_state(state->context);
> + kfree(state);
> return r;
> + }
>
> return 0;
> }
I imagine that the exception handling code can be improved another bit
for this function implementation.
How do you think about to avoid such duplicate source code?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=15bc20c6af4ceee97a1f90b43c0e386643c071b4#n475
Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2 3/8] drm/msm: Unconditionally call dev_pm_opp_of_remove_table()
dev_pm_opp_of_remove_table() doesn't report any errors when it fails to
find the OPP table with error -ENODEV (i.e. OPP table not present for
the device). And we can call dev_pm_opp_of_remove_table()
unconditionally here.
While at it, also create a label to put clkname.
Signed-off-by: Viresh Kumar
---
V2:
- Compare with -ENODEV only for failures.
- Create new label to put clkname.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 14 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
drivers/gpu/drm/msm/dsi/dsi_host.c | 8 ++--
3 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index c0a4d4e16d82..c8287191951f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1010,12 +1010,9 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
return PTR_ERR(dpu_kms->opp_table);
/* OPP table is optional */
ret = dev_pm_opp_of_add_table(dev);
- if (!ret) {
- dpu_kms->has_opp_table = true;
- } else if (ret != -ENODEV) {
+ if (ret && ret != -ENODEV) {
dev_err(dev, "invalid OPP table in device tree\n");
- dev_pm_opp_put_clkname(dpu_kms->opp_table);
- return ret;
+ goto put_clkname;
}
mp = &dpu_kms->mp;
@@ -1037,8 +1034,8 @@ static int dpu_bind(struct device *dev, struct device
*master, void *data)
priv->kms = &dpu_kms->base;
return ret;
err:
- if (dpu_kms->has_opp_table)
- dev_pm_opp_of_remove_table(dev);
+ dev_pm_opp_of_remove_table(dev);
+put_clkname:
dev_pm_opp_put_clkname(dpu_kms->opp_table);
return ret;
}
@@ -1056,8 +1053,7 @@ static void dpu_unbind(struct device *dev, struct device
*master, void *data)
if (dpu_kms->rpm_enabled)
pm_runtime_disable(&pdev->dev);
- if (dpu_kms->has_opp_table)
- dev_pm_opp_of_remove_table(dev);
+ dev_pm_opp_of_remove_table(dev);
dev_pm_opp_put_clkname(dpu_kms->opp_table);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index e140cd633071..8295979a7165 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -129,7 +129,6 @@ struct dpu_kms {
bool rpm_enabled;
struct opp_table *opp_table;
- bool has_opp_table;
struct dss_module_power mp;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index b17ac6c27554..4335fe33250c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -113,7 +113,6 @@ struct msm_dsi_host {
struct clk *byte_intf_clk;
struct opp_table *opp_table;
- bool has_opp_table;
u32 byte_clk_rate;
u32 pixel_clk_rate;
@@ -1891,9 +1890,7 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
return PTR_ERR(msm_host->opp_table);
/* OPP table is optional */
ret = dev_pm_opp_of_add_table(&pdev->dev);
- if (!ret) {
- msm_host->has_opp_table = true;
- } else if (ret != -ENODEV) {
+ if (ret && ret != -ENODEV) {
dev_err(&pdev->dev, "invalid OPP table in device tree\n");
dev_pm_opp_put_clkname(msm_host->opp_table);
return ret;
@@ -1934,8 +1931,7 @@ void msm_dsi_host_destroy(struct mipi_dsi_host *host)
mutex_destroy(&msm_host->cmd_mutex);
mutex_destroy(&msm_host->dev_mutex);
- if (msm_host->has_opp_table)
- dev_pm_opp_of_remove_table(&msm_host->pdev->dev);
+ dev_pm_opp_of_remove_table(&msm_host->pdev->dev);
dev_pm_opp_put_clkname(msm_host->opp_table);
pm_runtime_disable(&msm_host->pdev->dev);
}
--
2.25.0.rc1.19.g042ed3e048af
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/svm: remove set but not used 'ret'
This addresses the following gcc warning with "make W=1":
drivers/gpu/drm/nouveau/nouveau_svm.c: In function ‘nouveau_pfns_map’:
drivers/gpu/drm/nouveau/nouveau_svm.c:818:6: warning: variable ‘ret’ set
but not used [-Wunused-but-set-variable]
818 | int ret;
| ^~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 2df1c0460559..7c95ffcbd18f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
@@ -815,7 +815,6 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct
mm_struct *mm,
unsigned long addr, u64 *pfns, unsigned long npages)
{
struct nouveau_pfnmap_args *args = nouveau_pfns_to_args(pfns);
- int ret;
args->p.addr = addr;
args->p.size = npages << PAGE_SHIFT;
@@ -823,8 +822,8 @@ nouveau_pfns_map(struct nouveau_svmm *svmm, struct
mm_struct *mm,
mutex_lock(&svmm->mutex);
svmm->vmm->vmm.object.client->super = true;
- ret = nvif_object_ioctl(&svmm->vmm->vmm.object, args, sizeof(*args) +
- npages * sizeof(args->p.phys[0]), NULL);
+ nvif_object_ioctl(&svmm->vmm->vmm.object, args, sizeof(*args) +
+ npages * sizeof(args->p.phys[0]), NULL);
svmm->vmm->vmm.object.client->super = false;
mutex_unlock(&svmm->mutex);
--
2.25.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] drm/sun4i: add missing put_device() call in sun8i_r40_tcon_tv_set_mux()
On Wed, Aug 26, 2020 at 09:08:26AM +0800, Yu Kuai wrote:
> If sun8i_r40_tcon_tv_set_mux() succeed, sun8i_r40_tcon_tv_set_mux()
> doesn't have a corresponding put_device(). Thus add put_device()
> to fix the exception handling for this function implementation.
>
> Fixes: 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")
> Signed-off-by: Yu Kuai
Applied, thanks!
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Aw: Re: [PATCH v5 3/7] drm/mediatek: disable tmds on mt2701
Without this patch i have flickering/horizontal distortion (looks line every second line has different x position as one above approx. 5 px) on my 1280x1024 tft. Fbcon is unreadable with this problem. Hard to describe by words only :( Am 28. August 2020 01:46:07 MESZ schrieb Chun-Kuang Hu : >Hi, Frank: > >Matthias Brugger 於 2020年8月27日 週四 下午10:28寫道： >> >> >> >> On 27/08/2020 15:41, Frank Wunderlich wrote: >> > Hi Matthias, >> > >> > any opinions about the dts-changes? >> > >> >> they look good to me. >> >> > maybe series except the tmds-Patch get merged...so i add it only to >my own repo till we find a better way? >> > currently mainline does not support hdmi at all for the board. the >tmds-patch is only a fix for specific resolutions which have a >"flickering" without this Patch. >> > >> >> Well let's see what CK's opinion. >> > >Because no one has comment on this patch, I could apply this patch but >I need you to add more experiment information so if someone meets >another bug, he could fix his bug and consider your problem. > >Regards, >Chun-Kuang. > >> Regards, >> Matthias > >___ >Linux-mediatek mailing list >linux-media...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-mediatek regards Frank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On Thu, 27 Aug 2020 at 22:36, Logan Gunthorpe wrote:
>
>
>
> On 2020-08-23 6:04 p.m., Tom Murphy wrote:
> > I have added a check for the sg_dma_len == 0 :
> > """
> > } __sgt_iter(struct scatterlist *sgl, bool dma) {
> > struct sgt_iter s = { .sgp = sgl };
> >
> > + if (sgl && sg_dma_len(sgl) == 0)
> > + s.sgp = NULL;
> >
> > if (s.sgp) {
> > .
> > """
> > at location [1].
> > but it doens't fix the problem.
>
> Based on my read of the code, it looks like we also need to change usage
> of sgl->length... Something like the rough patch below, maybe?
>
> Also, Tom, do you have an updated version of the patchset to convert the
> Intel IOMMU to dma-iommu available? The last one I've found doesn't
> apply cleanly (I'm assuming parts of it have been merged in slightly
> modified forms).
>
I'll try and post one in the next 24hours
> Thanks,
>
> Logan
>
> --
>
> diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
> b/drivers/gpu/drm/i915/i915
> index b7b59328cb76..9367ac801f0c 100644
> --- a/drivers/gpu/drm/i915/i915_scatterlist.h
> +++ b/drivers/gpu/drm/i915/i915_scatterlist.h
> @@ -27,13 +27,19 @@ static __always_inline struct sgt_iter {
> } __sgt_iter(struct scatterlist *sgl, bool dma) {
> struct sgt_iter s = { .sgp = sgl };
>
> + if (sgl && !sg_dma_len(s.sgp))
> + s.sgp = NULL;
> +
> if (s.sgp) {
> s.max = s.curr = s.sgp->offset;
> - s.max += s.sgp->length;
> - if (dma)
> +
> + if (dma) {
> + s.max += sg_dma_len(s.sgp);
> s.dma = sg_dma_address(s.sgp);
> - else
> + } else {
> + s.max += s.sgp->length;
> s.pfn = page_to_pfn(sg_page(s.sgp));
> + }
> }
>
> return s;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] coccinelle: api: fix kobj_to_dev.cocci warnings
On Thu, 27 Aug 2020, Markus Elfring wrote:
> > Generated by: scripts/coccinelle/api/kobj_to_dev.cocci
> >
> > Fixes: a2fc3718bc22 ("coccinelle: api: add kobj_to_dev.cocci script")
>
> I wonder about such a combination of information.
>
> I find it reasonable that two function implementations should be adjusted
> according to a generated patch.
> Thus I imagine that not the mentioned SmPL script is “fixed”
> but the affected source file “drivers/video/fbdev/udlfb.c” may be improved.
> Will the subject “[PATCH] video: udlfb: Fix kobj_to_dev.cocci warnings”
> (or “[PATCH] video: udlfb: Use kobj_to_dev() instead of container_of()”)
> be more appropriate for the proposed commit message?
It seems that 0-day picks up new semantic patches that are added to trees
in kernel.org, but that it's strategy for generating the patch is not
ideal. I'll just drop these Fixes lines.
julia___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/tc358775: Fix semicolon
Remove unneded semicolon
Reported-by: kernel test robot
Signed-off-by: Vinay Simha BN
---
drivers/gpu/drm/bridge/tc358775.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358775.c
b/drivers/gpu/drm/bridge/tc358775.c
index d951cdc..2272adc 100644
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -485,7 +485,7 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
val |= TC358775_LVCFG_PCLKDIV(DIVIDE_BY_6);
} else {
val |= TC358775_LVCFG_PCLKDIV(DIVIDE_BY_3);
- };
+ }
d2l_write(tc->i2c, LVCFG, val);
}
--
2.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Parse Colorimetry data block from EDID
Hi Ville Syrjälä,
在 2020/8/27 18:57, Ville Syrjälä 写道:
On Wed, Aug 26, 2020 at 10:23:28PM +0800, Algea Cao wrote:
CEA 861.3 spec adds colorimetry data block for HDMI.
Parsing the block to get the colorimetry data from
panel.
And what exactly do you want to do with that data?
We can get colorimetry data block from edid then support
HDMI colorimetry such as BT2020.
Signed-off-by: Algea Cao
---
drivers/gpu/drm/drm_edid.c | 45 +
include/drm/drm_connector.h | 3 +++
include/drm/drm_edid.h | 14
3 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 31496b6cfc56..67e607c04492 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3223,6 +3223,7 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
+#define COLORIMETRY_DATA_BLOCK 0x5
#define HDR_STATIC_METADATA_BLOCK 0x6
#define USE_EXTENDED_TAG 0x07
#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
@@ -4309,6 +4310,48 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
+static bool cea_db_is_hdmi_colorimetry_data_block(const u8 *db)
+{
+ if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ return false;
+
+ if (db[1] != COLORIMETRY_DATA_BLOCK)
+ return false;
+
+ if (cea_db_payload_len(db) < 2)
+ return false;
+
+ return true;
+}
+
+static void
+drm_parse_colorimetry_data_block(struct drm_connector *connector, const u8 *db)
+{
+ struct drm_hdmi_info *info = &connector->display_info.hdmi;
+
+ if (db[2] & DRM_EDID_CLRMETRY_xvYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_xvYCC_709)
+ info->colorimetry |= DRM_EDID_CLRMETRY_xvYCC_709;
+ if (db[2] & DRM_EDID_CLRMETRY_sYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_sYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_ADBYCC_601)
+ info->colorimetry |= DRM_EDID_CLRMETRY_ADBYCC_601;
+ if (db[2] & DRM_EDID_CLRMETRY_ADB_RGB)
+ info->colorimetry |= DRM_EDID_CLRMETRY_ADB_RGB;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_CYCC)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_CYCC;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_YCC)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_YCC;
+ if (db[2] & DRM_EDID_CLRMETRY_BT2020_RGB)
+ info->colorimetry |= DRM_EDID_CLRMETRY_BT2020_RGB;
+ /* Byte 4 Bit 7: DCI-P3 */
+ if (db[3] & BIT(7))
+ info->colorimetry |= DRM_EDID_CLRMETRY_DCI_P3;
+
+ DRM_DEBUG_KMS("Supported Colorimetry 0x%x\n", info->colorimetry);
+}
+
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
{
if (cea_db_tag(db) != USE_EXTENDED_TAG)
@@ -4994,6 +5037,8 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
drm_parse_vcdb(connector, db);
if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, db);
+ if (cea_db_is_hdmi_colorimetry_data_block(db))
+ drm_parse_colorimetry_data_block(connector, db);
}
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index af145608b5ed..d599c3b9e881 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,9 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /* @colorimetry: bitmap of supported colorimetry modes */
+ u16 colorimetry;
};
/**
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index cfa4f5af49af..98fa78c2f82d 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,20 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/*
+ * Supported Colorimetry from colorimetry data block
+ * as per CEA 861-G spec
+ */
+#define DRM_EDID_CLRMETRY_xvYCC_601 (1 << 0)
+#define DRM_EDID_CLRMETRY_xvYCC_709 (1 << 1)
+#define DRM_EDID_CLRMETRY_sYCC_601(1 << 2)
+#define DRM_EDID_CLRMETRY_ADBYCC_601 (1 << 3)
+#define DRM_EDID_CLRMETRY_ADB_RGB (1 << 4)
+#define DRM_EDID_CLRMETRY_BT2020_CYCC (1 << 5)
+#define DRM_EDID_CLRMETRY_BT2020_YCC (1 << 6)
+#define DRM_EDID_CLRMETRY_BT2020_RGB (1 << 7)
+#define DRM_EDID_CLRMETRY_DCI_P3 (1 << 15)
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-de
Re: [PATCH] staging: ion: remove from the tree
On 8/27/20 6:36 AM, Greg Kroah-Hartman wrote: The ION android code has long been marked to be removed, now that we dma-buf support merged into the real part of the kernel. It was thought that we could wait to remove the ion kernel at a later time, but as the out-of-tree Android fork of the ion code has diverged quite a bit, and any Android device using the ion interface uses that forked version and not this in-tree version, the in-tree copy of the code is abandonded and not used by anyone. Combine this abandoned codebase with the need to make changes to it in order to keep the kernel building properly, which then causes merge issues when merging those changes into the out-of-tree Android code, and you end up with two different groups of people (the in-kernel-tree developers, and the Android kernel developers) who are both annoyed at the current situation. Because of this problem, just drop the in-kernel copy of the ion code now, as it's not used, and is only causing problems for everyone involved. Cc: "Arve Hjønnevåg" Cc: "Christian König" Cc: Christian Brauner Cc: Christoph Hellwig Cc: Hridya Valsaraju Cc: Joel Fernandes Cc: John Stultz Cc: Laura Abbott Cc: Martijn Coenen Cc: Shuah Khan Cc: Sumit Semwal Cc: Suren Baghdasaryan Cc: Todd Kjos Cc: de...@driverdev.osuosl.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Greg Kroah-Hartman --- MAINTAINERS | 10 - drivers/staging/android/Kconfig | 2 - drivers/staging/android/Makefile | 2 - drivers/staging/android/TODO | 5 - drivers/staging/android/ion/Kconfig | 27 - drivers/staging/android/ion/Makefile | 4 - drivers/staging/android/ion/ion.c | 649 -- drivers/staging/android/ion/ion.h | 302 drivers/staging/android/ion/ion_cma_heap.c| 138 drivers/staging/android/ion/ion_heap.c| 286 drivers/staging/android/ion/ion_page_pool.c | 155 - drivers/staging/android/ion/ion_system_heap.c | 377 -- drivers/staging/android/uapi/ion.h| 127 tools/testing/selftests/Makefile | 3 +- tools/testing/selftests/android/Makefile | 39 -- tools/testing/selftests/android/config| 5 - .../testing/selftests/android/ion/.gitignore | 4 - tools/testing/selftests/android/ion/Makefile | 20 - tools/testing/selftests/android/ion/README| 101 --- tools/testing/selftests/android/ion/ion.h | 134 .../testing/selftests/android/ion/ion_test.sh | 58 -- .../selftests/android/ion/ionapp_export.c | 127 .../selftests/android/ion/ionapp_import.c | 79 --- .../selftests/android/ion/ionmap_test.c | 136 .../testing/selftests/android/ion/ionutils.c | 253 --- .../testing/selftests/android/ion/ionutils.h | 55 -- .../testing/selftests/android/ion/ipcsocket.c | 227 -- .../testing/selftests/android/ion/ipcsocket.h | 35 - tools/testing/selftests/android/run.sh| 3 - 29 files changed, 1 insertion(+), 3362 deletions(-) delete mode 100644 drivers/staging/android/ion/Kconfig delete mode 100644 drivers/staging/android/ion/Makefile delete mode 100644 drivers/staging/android/ion/ion.c delete mode 100644 drivers/staging/android/ion/ion.h delete mode 100644 drivers/staging/android/ion/ion_cma_heap.c delete mode 100644 drivers/staging/android/ion/ion_heap.c delete mode 100644 drivers/staging/android/ion/ion_page_pool.c delete mode 100644 drivers/staging/android/ion/ion_system_heap.c delete mode 100644 drivers/staging/android/uapi/ion.h delete mode 100644 tools/testing/selftests/android/Makefile delete mode 100644 tools/testing/selftests/android/config delete mode 100644 tools/testing/selftests/android/ion/.gitignore delete mode 100644 tools/testing/selftests/android/ion/Makefile delete mode 100644 tools/testing/selftests/android/ion/README delete mode 100644 tools/testing/selftests/android/ion/ion.h delete mode 100755 tools/testing/selftests/android/ion/ion_test.sh delete mode 100644 tools/testing/selftests/android/ion/ionapp_export.c delete mode 100644 tools/testing/selftests/android/ion/ionapp_import.c delete mode 100644 tools/testing/selftests/android/ion/ionmap_test.c delete mode 100644 tools/testing/selftests/android/ion/ionutils.c delete mode 100644 tools/testing/selftests/android/ion/ionutils.h delete mode 100644 tools/testing/selftests/android/ion/ipcsocket.c delete mode 100644 tools/testing/selftests/android/ion/ipcsocket.h delete mode 100755 tools/testing/selftests/android/run.sh For selftest changes in this patch: Acked-by: Shuah Khan thanks, -- Shuah ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-next
Hi Daniel, Dave, Here's a re-run of last week's PR (without all the -rc1 churn) plus the patches that got in this week. Thanks! Maxime drm-misc-next-2020-08-27: drm-misc-next for 5.10: UAPI Changes: Cross-subsystem Changes: Core Changes: - ttm: various cleanups and reworks of the API Driver Changes: - ast: various cleanups - gma500: A few fixes, conversion to GPIOd API - hisilicon: Change of maintainer, various reworks - ingenic: Clock handling and formats support improvements - mcde: improvements to the DSI support - mgag200: Support G200 desktop cards - mxsfb: Support the i.MX7 and i.MX8M and the alpha plane - panfrost: support devfreq - ps8640: Retrieve the EDID from eDP control, misc improvements - tidss: Add a workaround for AM65xx YUV formats handling - virtio: a few cleanups, support for virtio-gpu exported resources - bridges: Support the chained bridges on more drivers, new bridges: Toshiba TC358762, Toshiba TC358775, Lontium LT9611 - panels: Convert to dev_ based logging, read orientation from the DT, various fixes, new panels: Mantix MLAF057WE51-X, Chefree CH101OLHLWH-002, Powertip PH800480T013, KingDisplay KD116N21-30NV-A010 The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-08-27 for you to fetch changes up to cd6da0b113512b15a4d35f355f9ecd8858297369: drm/mgag200: fix spelling mistake "expeced" -> "expected" (2020-08-27 11:17:52 +0200) drm-misc-next for 5.10: UAPI Changes: Cross-subsystem Changes: Core Changes: - ttm: various cleanups and reworks of the API Driver Changes: - ast: various cleanups - gma500: A few fixes, conversion to GPIOd API - hisilicon: Change of maintainer, various reworks - ingenic: Clock handling and formats support improvements - mcde: improvements to the DSI support - mgag200: Support G200 desktop cards - mxsfb: Support the i.MX7 and i.MX8M and the alpha plane - panfrost: support devfreq - ps8640: Retrieve the EDID from eDP control, misc improvements - tidss: Add a workaround for AM65xx YUV formats handling - virtio: a few cleanups, support for virtio-gpu exported resources - bridges: Support the chained bridges on more drivers, new bridges: Toshiba TC358762, Toshiba TC358775, Lontium LT9611 - panels: Convert to dev_ based logging, read orientation from the DT, various fixes, new panels: Mantix MLAF057WE51-X, Chefree CH101OLHLWH-002, Powertip PH800480T013, KingDisplay KD116N21-30NV-A010 Bernard Zhao (1): drm/panel: remove return value of function drm_panel_add Christian König (18): drm/radeon: stop using TTM_MEMTYPE_FLAG_MAPPABLE drm/amdgpu: stop using TTM_MEMTYPE_FLAG_MAPPABLE drm/ttm: remove TTM_MEMTYPE_FLAG_MAPPABLE drm/ttm: fix pipelined gutting for evictions v2 drm/ttm: initialize the system domain with defaults v2 drm/ttm: remove TTM_MEMTYPE_FLAG_FIXED v2 drm/radeon: stop implementing init_mem_type drm/amdgpu: stop implementing init_mem_type drm/vmwgfx: stop implementing init_mem_type v2 drm/nouveau: stop implementing init_mem_type drm/qxl: stop implementing init_mem_type drm/vram-helper: stop implementing init_mem_type drm/ttm: remove the init_mem_type callback drm/amdgpu: make sure userptr ttm is allocated drm/ttm: rename ttm_resource_manager_func callbacks drm/ttm: give resource functions their own [ch] files drm/radeon: drop superflous AGP handling drm/ttm: fix broken merge between drm-next and drm-misc-next Clément Péron (10): drm/panfrost: avoid static declaration drm/panfrost: clean headers in devfreq drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle drm/panfrost: introduce panfrost_devfreq struct drm/panfrost: use spinlock instead of atomic drm/panfrost: properly handle error in probe drm/panfrost: rename error labels in device_init drm/panfrost: move devfreq_init()/fini() in device drm/panfrost: dynamically alloc regulators drm/panfrost: add regulators to devfreq Colin Ian King (4): drm/gma500: fix spelling mistake "pannel" -> "panel" drm/virtgpu: remove redundant assignments to width and height drm/omap: fix spelling mistake "propert" -> "property" drm/mgag200: fix spelling mistake "expeced" -> "expected" Daniel Vetter (1): drm/syncobj: Tune down unordered timeline DRM_ERROR Dave Airlie (64): drm/vmwgfx: consolidate ttm object creation and populate drm/vmwgfx: drop bo map/unmap dma functions. nouveau: use ttm populate mapping functions. (v2) qxl/ttm: drop the unusued no wait flag to reserve function d
Re: [PATCH] video: fbdev: controlfb: Fix build for COMPILE_TEST=y && PPC_PMAC=n
On Fri, 21 Aug 2020 20:49:10 +1000, Michael Ellerman wrote: > The build is currently broken, if COMPILE_TEST=y and PPC_PMAC=n: > > linux/drivers/video/fbdev/controlfb.c: In function > âcontrol_set_hardwareâ: > linux/drivers/video/fbdev/controlfb.c:276:2: error: implicit declaration of > function âbtext_update_displayâ > 276 | btext_update_display(p->frame_buffer_phys + CTRLFB_OFF, > | ^~~~ > > [...] Applied to powerpc/fixes. [1/1] video: fbdev: controlfb: Fix build for COMPILE_TEST=y && PPC_PMAC=n https://git.kernel.org/powerpc/c/4d618b9f3fcab84e9ec28c180de46fb2c929d096 cheers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] coccinelle: api: fix kobj_to_dev.cocci warnings
> Generated by: scripts/coccinelle/api/kobj_to_dev.cocci
>
> Fixes: a2fc3718bc22 ("coccinelle: api: add kobj_to_dev.cocci script")
I wonder about such a combination of information.
I find it reasonable that two function implementations should be adjusted
according to a generated patch.
Thus I imagine that not the mentioned SmPL script is “fixed”
but the affected source file “drivers/video/fbdev/udlfb.c” may be improved.
Will the subject “[PATCH] video: udlfb: Fix kobj_to_dev.cocci warnings”
(or “[PATCH] video: udlfb: Use kobj_to_dev() instead of container_of()”)
be more appropriate for the proposed commit message?
Regards,
Markus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/ingenic: Fix driver not probing when IPU port is missing
Even if support for the IPU was compiled in, we may run on a device
(e.g. the Qi LB60) where the IPU is not available, or simply with an old
devicetree without the IPU node. In that case the ingenic-drm refused to
probe.
Fix the driver so that it will probe even if the IPU node is not present
in devicetree (but then IPU support is disabled of course).
v2: Take a different approach
Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index c1bcb93aed2d..b7074161ccf0 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -673,7 +673,7 @@ static void ingenic_drm_unbind_all(void *d)
component_unbind_all(priv->dev, &priv->drm);
}
-static int ingenic_drm_bind(struct device *dev)
+static int ingenic_drm_bind(struct device *dev, bool has_components)
{
struct platform_device *pdev = to_platform_device(dev);
const struct jz_soc_info *soc_info;
@@ -808,7 +808,7 @@ static int ingenic_drm_bind(struct device *dev)
return ret;
}
- if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU)) {
+ if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU) && has_components) {
ret = component_bind_all(dev, drm);
if (ret) {
if (ret != -EPROBE_DEFER)
@@ -939,6 +939,11 @@ static int ingenic_drm_bind(struct device *dev)
return ret;
}
+static int ingenic_drm_bind_with_components(struct device *dev)
+{
+ return ingenic_drm_bind(dev, true);
+}
+
static int compare_of(struct device *dev, void *data)
{
return dev->of_node == data;
@@ -957,7 +962,7 @@ static void ingenic_drm_unbind(struct device *dev)
}
static const struct component_master_ops ingenic_master_ops = {
- .bind = ingenic_drm_bind,
+ .bind = ingenic_drm_bind_with_components,
.unbind = ingenic_drm_unbind,
};
@@ -968,14 +973,12 @@ static int ingenic_drm_probe(struct platform_device *pdev)
struct device_node *np;
if (!IS_ENABLED(CONFIG_DRM_INGENIC_IPU))
- return ingenic_drm_bind(dev);
+ return ingenic_drm_bind(dev, false);
/* IPU is at port address 8 */
np = of_graph_get_remote_node(dev->of_node, 8, 0);
- if (!np) {
- dev_err(dev, "Unable to get IPU node\n");
- return -EINVAL;
- }
+ if (!np)
+ return ingenic_drm_bind(dev, false);
drm_of_component_match_add(dev, &match, compare_of, np);
of_node_put(np);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: ion: remove from the tree
On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: The ION android code has long been marked to be removed, now that we dma-buf support merged into the real part of the kernel. It was thought that we could wait to remove the ion kernel at a later time, but as the out-of-tree Android fork of the ion code has diverged quite a bit, and any Android device using the ion interface uses that forked version and not this in-tree version, the in-tree copy of the code is abandonded and not used by anyone. Combine this abandoned codebase with the need to make changes to it in order to keep the kernel building properly, which then causes merge issues when merging those changes into the out-of-tree Android code, and you end up with two different groups of people (the in-kernel-tree developers, and the Android kernel developers) who are both annoyed at the current situation. Because of this problem, just drop the in-kernel copy of the ion code now, as it's not used, and is only causing problems for everyone involved. Cc: "Arve Hjønnevåg" Cc: "Christian König" Cc: Christian Brauner Cc: Christoph Hellwig Cc: Hridya Valsaraju Cc: Joel Fernandes Cc: John Stultz Cc: Laura Abbott Cc: Martijn Coenen Cc: Shuah Khan Cc: Sumit Semwal Cc: Suren Baghdasaryan Cc: Todd Kjos Cc: de...@driverdev.osuosl.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Greg Kroah-Hartman We discussed this at the Android MC on Monday and the plan was to remove it after the next LTS release. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/1] drm/bridge: ps8640: Rework power state handling
The get_edid() callback can be triggered anytime by an ioctl, i.e
drm_mode_getconnector (ioctl)
-> drm_helper_probe_single_connector_modes
-> drm_bridge_connector_get_modes
-> ps8640_bridge_get_edid
Actually if the bridge pre_enable() function was not called before
get_edid(), the driver will not be able to get the EDID properly and
display will not work until a second get_edid() call is issued and if
pre_enable() is called before. The side effect of this, for example, is
that you see anything when `Frecon` starts, neither the splash screen,
until the graphical session manager starts.
To fix this we need to make sure that all we need is enabled before
reading the EDID. This means the following:
1. If get_edid() is called before having the device powered we need to
power on the device. In such case, the driver will power off again the
device.
2. If get_edid() is called after having the device powered, all should
just work. We added a powered flag in order to avoid recurrent calls
to ps8640_bridge_poweron() and unneeded delays.
3. This seems to be specific for this device, but we need to make sure
the panel is powered on before do a power on cycle on this device.
Otherwise the device fails to retrieve the EDID.
Signed-off-by: Enric Balletbo i Serra
---
Changes in v3:
- Make poweron/poweroff and pre_enable/post_disable reverse one to each other
(Sam Ravnborg)
Changes in v2:
- Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)
drivers/gpu/drm/bridge/parade-ps8640.c | 68 ++
1 file changed, 58 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 9f7b7a9c53c5..7bd0affa057a 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -65,6 +65,7 @@ struct ps8640 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_powerdown;
+ bool powered;
};
static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
@@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct ps8640
*ps_bridge,
return 0;
}
-static void ps8640_pre_enable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
{
- struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
unsigned long timeout;
int ret, status;
+ if (ps_bridge->powered)
+ return;
+
ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
ps_bridge->supplies);
if (ret < 0) {
@@ -152,10 +155,6 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
goto err_regulators_disable;
}
- ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
- if (ret)
- goto err_regulators_disable;
-
/* Switch access edp panel's edid through i2c */
ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
I2C_BYPASS_EN);
@@ -164,6 +163,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
goto err_regulators_disable;
}
+ ps_bridge->powered = true;
+
return;
err_regulators_disable:
@@ -171,12 +172,12 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
ps_bridge->supplies);
}
-static void ps8640_post_disable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
{
- struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
- ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+ if (!ps_bridge->powered)
+ return;
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
@@ -184,6 +185,28 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
ps_bridge->supplies);
if (ret < 0)
DRM_ERROR("cannot disable regulators %d\n", ret);
+
+ ps_bridge->powered = false;
+}
+
+static void ps8640_pre_enable(struct drm_bridge *bridge)
+{
+ struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+ int ret;
+
+ ps8640_bridge_poweron(ps_bridge);
+
+ ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
+ if (ret < 0)
+ ps8640_bridge_poweroff(ps_bridge);
+}
+
+static void ps8640_post_disable(struct drm_bridge *bridge)
+{
+ struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+ ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+ ps8640_bridge_poweroff(ps_bridge);
}
static int ps8640_bridge_attach(struct drm_bridge *bridge,
@@ -249,9 +272,34 @@ static struct edid *ps8640_bridge_get_edid(struct
drm_bridge *bridge,
struct drm_connecto
Re: [PATCH v2 5/5] drm/bridge: ps8640: Rework power state handling
Hi Sam,
Thanks for your comments.
On 26/8/20 20:46, Sam Ravnborg wrote:
> Hi Enric.
>
> On Wed, Aug 26, 2020 at 10:15:26AM +0200, Enric Balletbo i Serra wrote:
>> The get_edid() callback can be triggered anytime by an ioctl, i.e
>>
>> drm_mode_getconnector (ioctl)
>> -> drm_helper_probe_single_connector_modes
>>-> drm_bridge_connector_get_modes
>> -> ps8640_bridge_get_edid
>>
>> Actually if the bridge pre_enable() function was not called before
>> get_edid(), the driver will not be able to get the EDID properly and
>> display will not work until a second get_edid() call is issued and if
>> pre_enable() is called before. The side effect of this, for example, is
>> that you see anything when `Frecon` starts, neither the splash screen,
>> until the graphical session manager starts.
>>
>> To fix this we need to make sure that all we need is enabled before
>> reading the EDID. This means the following:
>>
>> 1. If get_edid() is called before having the device powered we need to
>>power on the device. In such case, the driver will power off again the
>>device.
>>
>> 2. If get_edid() is called after having the device powered, all should
>>just work. We added a powered flag in order to avoid recurrent calls
>>to ps8640_bridge_poweron() and unneeded delays.
>>
>> 3. This seems to be specific for this device, but we need to make sure
>>the panel is powered on before do a power on cycle on this device.
>>Otherwise the device fails to retrieve the EDID.
>>
>> Signed-off-by: Enric Balletbo i Serra
>> ---
>>
>> Changes in v2:
>> - Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)
>>
>> drivers/gpu/drm/bridge/parade-ps8640.c | 64 +++---
>> 1 file changed, 58 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
>> b/drivers/gpu/drm/bridge/parade-ps8640.c
>> index 9f7b7a9c53c5..c5d76e209bda 100644
>> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>> @@ -65,6 +65,7 @@ struct ps8640 {
>> struct regulator_bulk_data supplies[2];
>> struct gpio_desc *gpio_reset;
>> struct gpio_desc *gpio_powerdown;
>> +bool powered;
>> };
>>
>> static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
>> @@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct ps8640
>> *ps_bridge,
>> return 0;
>> }
>>
>> -static void ps8640_pre_enable(struct drm_bridge *bridge)
>> +static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
>> {
>> -struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
>> unsigned long timeout;
>> int ret, status;
>>
>> +if (ps_bridge->powered)
>> +return;
>> +
>> ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
>> ps_bridge->supplies);
>> if (ret < 0) {
>> @@ -164,6 +167,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
>> goto err_regulators_disable;
>> }
>>
>> +ps_bridge->powered = true;
>> +
>> return;
>>
>> err_regulators_disable:
>> @@ -171,12 +176,12 @@ static void ps8640_pre_enable(struct drm_bridge
>> *bridge)
>> ps_bridge->supplies);
>> }
>>
>> -static void ps8640_post_disable(struct drm_bridge *bridge)
>> +static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
>> {
>> -struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> int ret;
>>
>> -ps8640_bridge_vdo_control(ps_bridge, DISABLE);
>> +if (!ps_bridge->powered)
>> +return;
>>
>> gpiod_set_value(ps_bridge->gpio_reset, 1);
>> gpiod_set_value(ps_bridge->gpio_powerdown, 1);
>> @@ -184,6 +189,28 @@ static void ps8640_post_disable(struct drm_bridge
>> *bridge)
>> ps_bridge->supplies);
>> if (ret < 0)
>> DRM_ERROR("cannot disable regulators %d\n", ret);
>> +
>> +ps_bridge->powered = false;
>> +}
>> +
>> +static void ps8640_pre_enable(struct drm_bridge *bridge)
>> +{
>> +struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
>> +int ret;
>> +
>> +ps8640_bridge_poweron(ps_bridge);
>> +
>> +ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
>> +if (ret < 0)
>> +ps8640_bridge_poweroff(ps_bridge);
>> +}
>
> The impleimentation of ps8640_bridge_poweron() versus
> ps8640_bridge_poweroff() is confusing.
>
> ps8640_bridge_poweron() includes ps8640_bridge_vdo_control(.., ENABLE),
> but ps8640_bridge_poweroff() does not include
> ps8640_bridge_vdo_control(..., DISABLE).
>
> This is inconsistent and confusing. At least it was for me when
> reviewing. Can this be improved - or maybe just use naming that does not
> indicate they are the reverse of each other?
>
Right, I think I can implement reverse of each other. So I'll send an updated
series.
Thanks,
Enric
>> +
>> +static void ps8640_post
Re: [PATCH] staging: ion: remove from the tree
On Thu, 27 Aug 2020 at 21:34, Greg Kroah-Hartman wrote: > > On Thu, Aug 27, 2020 at 09:31:27AM -0400, Laura Abbott wrote: > > On 8/27/20 8:36 AM, Greg Kroah-Hartman wrote: > > > The ION android code has long been marked to be removed, now that we > > > dma-buf support merged into the real part of the kernel. > > > > > > It was thought that we could wait to remove the ion kernel at a later > > > time, but as the out-of-tree Android fork of the ion code has diverged > > > quite a bit, and any Android device using the ion interface uses that > > > forked version and not this in-tree version, the in-tree copy of the > > > code is abandonded and not used by anyone. > > > > > > Combine this abandoned codebase with the need to make changes to it in > > > order to keep the kernel building properly, which then causes merge > > > issues when merging those changes into the out-of-tree Android code, and > > > you end up with two different groups of people (the in-kernel-tree > > > developers, and the Android kernel developers) who are both annoyed at > > > the current situation. Because of this problem, just drop the in-kernel > > > copy of the ion code now, as it's not used, and is only causing problems > > > for everyone involved. > > > > > > Cc: "Arve Hjønnevåg" > > > Cc: "Christian König" > > > Cc: Christian Brauner > > > Cc: Christoph Hellwig > > > Cc: Hridya Valsaraju > > > Cc: Joel Fernandes > > > Cc: John Stultz > > > Cc: Laura Abbott > > > Cc: Martijn Coenen > > > Cc: Shuah Khan > > > Cc: Sumit Semwal > > > Cc: Suren Baghdasaryan > > > Cc: Todd Kjos > > > Cc: de...@driverdev.osuosl.org > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: linaro-mm-...@lists.linaro.org > > > Signed-off-by: Greg Kroah-Hartman > > > > We discussed this at the Android MC on Monday and the plan was to > > remove it after the next LTS release. > > I know it was discussed, my point is that it is actually causing > problems now (with developers who want to change the internal kernel api > hitting issues, and newbies trying to clean up code in ways that isn't > exactly optimal wasting maintainer cycles), and that anyone who uses > this code, is not actually using this version of the code. Everyone who > relies on ion right now, is using the version that is in the Android > common kernel tree, which has diverged from this in-kernel way quite a > bit now for the reason that we didn't want to take any of those new > features in the in-kernel version. > > So this is a problem that we have caused by just wanting to wait, no one > is using this code, combined with it causing problems for the upstream > developers. > > There is nothing "magic" about the last kernel of the year that requires > this code to sit here until then. At that point in time, all users > will, again, be using the forked Android kernel version, and if we > delete this now here, that fork can remain just fine, with the added > benifit of it reducing developer workloads here in-kernel. > > So why wait? Hi, I don't know what is the right thing to do here. I just want to highlight that AOSP's audio (codec2) HAL depends on the ION system heap and it will break AOSP for people who boot mainline on their devices, even for just testing purpose like we do in Linaro. Right now we need only 1 (Android specific out-of-tree) patch to boot AOSP with mainline and Sumit is already trying to upstream that vma naming patch. Removal of in-kernel ION, will just add more to that delta. Regards, Amit Pundir > > thanks, > > greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
