Re: [PATCH 13/20] drm/i915/ttm: mappable migration on fault
On 1/26/22 16:21, Matthew Auld wrote:
The end goal is to have userspace tell the kernel what buffers will
require CPU access, however if we ever reach the CPU fault handler, and
the current resource is not mappable, then we should attempt to migrate
the buffer to the mappable portion of LMEM, or even system memory, if the
allowable placements permit it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 58 ++---
1 file changed, 52 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 8376e4c3d290..7299053fb1ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -636,11 +636,25 @@ static void i915_ttm_swap_notify(struct ttm_buffer_object
*bo)
i915_ttm_purge(obj);
}
+static bool i915_ttm_resource_mappable(struct ttm_resource *res)
+{
+ struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
+
+ if (!i915_ttm_cpu_maps_iomem(res))
+ return true;
+
+ return bman_res->used_visible_size == bman_res->base.num_pages;
+}
+
static int i915_ttm_io_mem_reserve(struct ttm_device *bdev, struct
ttm_resource *mem)
{
+
Stray line.
Otherwise LGTM.
Reviewed-by: Thomas Hellström
Re: [PATCH] HPE BMC GXP SUPPORT
On 02/02/2022 17:52, nick.hawk...@hpe.com wrote: > From: Nick Hawkins > > GXP is the name of the HPE SoC. > This SoC is used to implement BMC features of HPE servers > (all ProLiant, Synergy, and many Apollo, and Superdome machines) > It does support many features including: > ARMv7 architecture, and it is based on a Cortex A9 core > Use an AXI bus to which > a memory controller is attached, as well as > multiple SPI interfaces to connect boot flash, > and ROM flash, a 10/100/1000 Mac engine which > supports SGMII (2 ports) and RMII > Multiple I2C engines to drive connectivity with a host > infrastructure > A video engine which support VGA and DP, as well as > an hardware video encoder > Multiple PCIe ports > A PECI interface, and LPC eSPI > Multiple UART for debug purpose, and Virtual UART for host > connectivity > A GPIO engine > This Patch Includes: > Documentation for device tree bindings > Device Tree Bindings > GXP Timer Support > GXP Architecture Support > 1. Please version your patchses and document the changes under ---. 2. With your v1 I responded what has to be separate patch. This was totally ignored here, so no. You have to follow this. 3. Please run checkpatch and be sure there are no warnings. 4. Bindings in dtschema, not in text. Best regards, Krzysztof Best regards, Krzysztof
Re: Kconfig CONFIG_FB dependency regression
On Thu, Feb 3, 2022 at 12:55 AM Thinh Nguyen wrote:
> Arnd Bergmann wrote:
> > On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen
> > wrote:
> >> Fabio Estevam wrote:
> >
> > CONFIG_FB should not normally be needed for booting, so unless
> > you have a graphical application in your initramfs that requires the
> > /dev/fb0
> > device to work, it is not supposed to make a difference.
> >
>
> I'm not sure, but it seems like the setup we have isn't the only one
> that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs
> to have CONFIG_FB set.
No, that one is different: the change for imx_v6_v7_defconfig was
done because they actually use a framebuffer console on some devices,
so the patch just adds the symbol to enable the drivers they are using.
This is expected with my original patch that doesn't implicitly enable
the framebuffer layer any more. What is not expected is for the kernel
to hang during boot as you reported for your unidentified platform.
> > Are there any other differences in your .config before and after the patch?
> > It's possible that you use some other driver that in turn depends on
> > CONFIG_FB. Does your machine have any graphical output device?
> > If yes, which driver do you use?
>
> I don't have the answer to those questions yet. Need more investigation.
> I'm new to this particular test setup.
Do you mean you don't know if there is a screen attached to the system?
> >
> > You may also want to make sure that you have 9d6366e743f3 ("drm:
> > fb_helper: improve CONFIG_FB dependency") in your kernel, which
> > fixes a minor problem with my original patch.
> >
>
> The issue also occurs in mainline, which has your minor fix commit
> above. The revert isn't clean for the latest kernel version. I also have
> to revert some of the changes along with CONFIG_FB. The revert looks
> more like this for the latest kernel:
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b1f22e457fd0..7cbc733a8569 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
>
> config DRM_FBDEV_EMULATION
> bool "Enable legacy fbdev support for your modesetting driver"
> - depends on DRM_KMS_HELPER
> - depends on FB=y || FB=DRM_KMS_HELPER
> + depends on DRM
> + select DRM_KMS_HELPER
> + select FB
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
>
>
>
> I attached the configs for kernel v5.17-rc1. The "bad" config is without
> any revert, the "good" config is with the change above.
Looking at the config, I see that this is for an x86 machine,
and you have the FB_EFI driver and EFI_EARLYCON enabled.
What I suspec is going on is that you are looking at a screen rather
than a serial console, and the kernel doesn't actually hang but you
just don't see any more messages after the DRM driver takes
over from EFI_EARLYCON because there is no console driver.
In this case, what you see is the intended behavior, not a bug.
If you want a graphical console in your system, you need to
enable the support for this in your config.
Arnd
[PATCH] drm/modes: Fix drm_mode_validate_size() docs
From: Ville Syrjälä drm_mode_validate_size() does *not* modify the passed in mode's status (in fact it is passed in as const). Also this operates on a single mode, so the reference to some list is just confusing. Remove the nonsense docs. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 1c72208d8133..425a56a976a1 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1136,16 +1136,14 @@ EXPORT_SYMBOL(drm_mode_validate_driver); /** * drm_mode_validate_size - make sure modes adhere to size constraints * @mode: mode to check * @maxX: maximum width * @maxY: maximum height * - * This function is a helper which can be used to validate modes against size - * limitations of the DRM device/connector. If a mode is too big its status - * member is updated with the appropriate validation failure code. The list - * itself is not changed. + * This function is a helper which can be used to validate + * modes against size limitations of the DRM device/connector. * * Returns: * The mode status */ enum drm_mode_status drm_mode_validate_size(const struct drm_display_mode *mode, -- 2.34.1
Re: [PATCH v6] fbdev: fbmem: Fix the implicit type casting
Hi Daniel, I assume you will take this. Patch is: Reviewed-by: Sam Ravnborg Sam On Wed, Feb 02, 2022 at 03:58:08PM -0800, Yizhuo Zhai wrote: > In function do_fb_ioctl(), the "arg" is the type of unsigned long, > and in "case FBIOBLANK:" this argument is casted into an int before > passig to fb_blank(). In fb_blank(), the comparision > if (blank > FB_BLANK_POWERDOWN) would be bypass if the original > "arg" is a large number, which is possible because it comes from > the user input. Fix this by adding the check before the function > call. > > Signed-off-by: Yizhuo Zhai > --- > drivers/video/fbdev/core/fbmem.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/video/fbdev/core/fbmem.c > b/drivers/video/fbdev/core/fbmem.c > index 0fa7ede94fa6..13083ad8d751 100644 > --- a/drivers/video/fbdev/core/fbmem.c > +++ b/drivers/video/fbdev/core/fbmem.c > @@ -1160,6 +1160,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned > int cmd, > ret = fbcon_set_con2fb_map_ioctl(argp); > break; > case FBIOBLANK: > + if (arg > FB_BLANK_POWERDOWN) > + return -EINVAL; > console_lock(); > lock_fb_info(info); > ret = fb_blank(info, arg); > -- > 2.25.1
[PATCH -next] drm/amdkfd: Fix resource_size.cocci warning
Use resource_size function on resource object instead of explicit computation. Eliminate the following coccicheck warning: ./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:978:11-14: ERROR: Missing resource_size with res Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c index 8430f6475723..d4287a39be56 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c @@ -975,7 +975,7 @@ int svm_migrate_init(struct amdgpu_device *adev) pgmap->type = 0; if (pgmap->type == MEMORY_DEVICE_PRIVATE) devm_release_mem_region(adev->dev, res->start, - res->end - res->start + 1); + resource_size(res)); return PTR_ERR(r); } -- 2.20.1.7.g153144c
Re: [PATCH RESEND v5 3/4] drm/bridge: anx7625: Support reading edid through aux channel
Hi Hsin-Yi, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on next-20220202] [cannot apply to robh/for-next drm-intel/for-linux-next v5.17-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/Hsin-Yi-Wang/drm-bridge-anx7625-send-DPCD-command-to-downstream/20220203-001041 base: git://anongit.freedesktop.org/drm/drm drm-next config: s390-randconfig-r044-20220130 (https://download.01.org/0day-ci/archive/20220203/202202031234.x27z4ztl-...@intel.com/config) compiler: s390-linux-gcc (GCC) 11.2.0 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 # https://github.com/0day-ci/linux/commit/f706d1336c4d5a5984565b964370868113710354 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Hsin-Yi-Wang/drm-bridge-anx7625-send-DPCD-command-to-downstream/20220203-001041 git checkout f706d1336c4d5a5984565b964370868113710354 # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=s390 SHELL=/bin/bash If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): s390-linux-ld: drivers/gpu/drm/bridge/analogix/anx7625.o: in function `anx7625_i2c_probe': >> anx7625.c:(.text+0x5d02): undefined reference to >> `devm_of_dp_aux_populate_ep_devices' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[pull] amdgpu drm-fixes-5.17
Hi Dave, Daniel, Fixes for 5.17. The following changes since commit 26291c54e111ff6ba87a164d85d4a4e134b7315c: Linux 5.17-rc2 (2022-01-30 15:37:07 +0200) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.17-2022-02-02 for you to fetch changes up to e8ae38720e1a685fd98cfa5ae118c9d07b45ca79: drm/amdgpu: fix logic inversion in check (2022-02-02 18:35:00 -0500) amd-drm-fixes-5.17-2022-02-02: amdgpu: - mGPU fan boost fix for beige goby - S0ix fixes - Cyan skillfish hang fix - DCN fixes for DCN 3.1 - DCN fixes for DCN 3.01 - Apple retina panel fix - ttm logic inversion fix Agustin Gutierrez (1): drm/amd/display: Update watermark values for DCN301 Aun-Ali Zaidi (1): drm/amd/display: Force link_rate as LINK_RATE_RBR2 for 2018 15" Apple Retina panels Christian König (1): drm/amdgpu: fix logic inversion in check Evan Quan (1): drm/amd/pm: correct the MGpuFanBoost support for Beige Goby Lang Yu (1): drm/amdgpu: fix a potential GPU hang on cyan skillfish Mario Limonciello (4): drm/amd: Warn users about potential s0ix problems drm/amd: add support to check whether the system is set to s3 drm/amd: Only run s3 or s0ix if system is configured properly drm/amd: avoid suspend on dGPUs w/ s2idle support when runtime PM enabled Paul Hsieh (1): drm/amd/display: watermark latencies is not enough on DCN31 Zhan Liu (1): drm/amd/display: revert "Reset fifo after enable otg" drivers/gpu/drm/amd/amdgpu/amdgpu.h| 10 -- drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 37 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 11 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 2 +- drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 ++ .../drm/amd/display/dc/clk_mgr/dcn301/vg_clk_mgr.c | 16 +- .../amd/display/dc/clk_mgr/dcn31/dcn31_clk_mgr.c | 20 ++-- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 20 .../amd/display/dc/dce110/dce110_hw_sequencer.c| 5 --- .../amd/display/dc/dcn10/dcn10_stream_encoder.c| 15 - .../amd/display/dc/dcn10/dcn10_stream_encoder.h| 3 -- .../amd/display/dc/dcn20/dcn20_stream_encoder.c| 2 -- .../display/dc/dcn30/dcn30_dio_stream_encoder.c| 2 -- .../gpu/drm/amd/display/dc/inc/hw/stream_encoder.h | 4 --- .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 6 ++-- 15 files changed, 94 insertions(+), 62 deletions(-)
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #64 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Jon from comment #61) > Chiming in as another victim of: > [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125! > This is just a symptom of an application trying to use the GPU after a GPU reset without re-initializing it's context. The cause of a GPU reset can be a lot of things. If you have different hardware from other people on this ticket, it's not likely the same issue. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: Kconfig CONFIG_FB dependency regression
Hi--
On 2/2/22 15:55, Thinh Nguyen wrote:
> Arnd Bergmann wrote:
>> On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen
>> wrote:
>>> Fabio Estevam wrote:
On Tue, Feb 1, 2022 at 8:06 PM Randy Dunlap wrote:
>
> On 2/1/22 15:01, Thinh Nguyen wrote:
>> Hi,
>>
>> One of our test setups is unable to boot (stuck at initramfs). Git
>> bisection points to the commit below:
>>
>> f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB")
>>
>> Reverting this patch resolves the issue. This issue persists in mainline
>> also. Unfortunately there isn't any meaningful log. Hopefully someone
>> can give some insight as to what could be the issue and revert/fix this
>> issue.
>
> Hi,
> Did you enable DRM_FBDEV_EMULATION?
>>>
>>> I did not enable it.
>>>
> Please provide the failing .config file.
Does selecting CONFIG_FB=y help?
>>>
>>> On the config that has the issue, this isn't set. After reverting the
>>> commit above, this was set. Maybe this is what's needed? I need to test it.
>>
>> CONFIG_FB should not normally be needed for booting, so unless
>> you have a graphical application in your initramfs that requires the /dev/fb0
>> device to work, it is not supposed to make a difference.
>>
>
> I'm not sure, but it seems like the setup we have isn't the only one
> that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs
> to have CONFIG_FB set.
>
>> Are there any other differences in your .config before and after the patch?
>> It's possible that you use some other driver that in turn depends on
>> CONFIG_FB. Does your machine have any graphical output device?
>> If yes, which driver do you use?
>
> I don't have the answer to those questions yet. Need more investigation.
> I'm new to this particular test setup.
>
>>
>> You may also want to make sure that you have 9d6366e743f3 ("drm:
>> fb_helper: improve CONFIG_FB dependency") in your kernel, which
>> fixes a minor problem with my original patch.
>>
>> Arnd
>
> The issue also occurs in mainline, which has your minor fix commit
> above. The revert isn't clean for the latest kernel version. I also have
> to revert some of the changes along with CONFIG_FB. The revert looks
> more like this for the latest kernel:
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b1f22e457fd0..7cbc733a8569 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
>
> config DRM_FBDEV_EMULATION
> bool "Enable legacy fbdev support for your modesetting driver"
> - depends on DRM_KMS_HELPER
> - depends on FB=y || FB=DRM_KMS_HELPER
> + depends on DRM
> + select DRM_KMS_HELPER
> + select FB
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
>
>
>
> I attached the configs for kernel v5.17-rc1. The "bad" config is without
> any revert, the "good" config is with the change above.
I took bad.config with kernel 5.17-rc1 and then manually set/enabled:
CONFIG_FB
CONFIG_FB_EFI
CONFIG_FB_MODE_HELPERS
CONFIG_FB_TILEBLITTING
CONFIG_LOGO
and I got very close to your good.config file.
Can you do the same and see if it works for you?
If so, then we can decide what to do about it.
thanks.
--
~Randy
Re: [PATCH] drm/exynos: fimd: add BGR support for exynos4/5
Hi Martin.
Thanks for your contribution,
Inki Dae
22. 1. 30. 07:01에 Martin Jücker 이(가) 쓴 글:
> In the downstream kernels for exynos4 and exynos5 devices, there is an
> undocumented register that controls the order of the RGB output. It can
> be set to either normal order or reversed, which enables BGR support for
> those SoCs.
>
> This patch enables the BGR support for all the SoCs that were found to
> have at least one device with this logic in the corresponding downstream
> kernels.
>
> Signed-off-by: Martin Jücker
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 42 ++--
> include/video/samsung_fimd.h | 4 +++
> 2 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index c735e53939d8..cb632360c968 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -109,6 +109,7 @@ struct fimd_driver_data {
> unsigned int has_dp_clk:1;
> unsigned int has_hw_trigger:1;
> unsigned int has_trigger_per_te:1;
> + unsigned int has_bgr_support:1;
> };
>
> static struct fimd_driver_data s3c64xx_fimd_driver_data = {
> @@ -138,6 +139,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data =
> {
> .lcdblk_bypass_shift = 1,
> .has_shadowcon = 1,
> .has_vtsel = 1,
> + .has_bgr_support = 1,
> };
>
> static struct fimd_driver_data exynos5_fimd_driver_data = {
> @@ -149,6 +151,7 @@ static struct fimd_driver_data exynos5_fimd_driver_data =
> {
> .has_vidoutcon = 1,
> .has_vtsel = 1,
> .has_dp_clk = 1,
> + .has_bgr_support = 1,
> };
>
> static struct fimd_driver_data exynos5420_fimd_driver_data = {
> @@ -162,6 +165,7 @@ static struct fimd_driver_data
> exynos5420_fimd_driver_data = {
> .has_vtsel = 1,
> .has_mic_bypass = 1,
> .has_dp_clk = 1,
> + .has_bgr_support = 1,
> };
>
> struct fimd_context {
> @@ -226,6 +230,18 @@ static const uint32_t fimd_formats[] = {
> DRM_FORMAT_ARGB,
> };
>
> +static const uint32_t fimd_extended_formats[] = {
> + DRM_FORMAT_C8,
> + DRM_FORMAT_XRGB1555,
> + DRM_FORMAT_XBGR1555,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_ABGR,
> +};
> +
> static const unsigned int capabilities[WINDOWS_NR] = {
> 0,
> EXYNOS_DRM_PLANE_CAP_WIN_BLEND | EXYNOS_DRM_PLANE_CAP_PIX_BLEND,
> @@ -673,21 +689,25 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
> val |= WINCONx_BYTSWP;
> break;
> case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_XBGR1555:
> val |= WINCON0_BPPMODE_16BPP_1555;
> val |= WINCONx_HAWSWP;
> val |= WINCONx_BURSTLEN_16WORD;
> break;
> case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_BGR565:
> val |= WINCON0_BPPMODE_16BPP_565;
> val |= WINCONx_HAWSWP;
> val |= WINCONx_BURSTLEN_16WORD;
> break;
> case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> val |= WINCON0_BPPMODE_24BPP_888;
> val |= WINCONx_WSWP;
> val |= WINCONx_BURSTLEN_16WORD;
> break;
> case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> default:
> val |= WINCON1_BPPMODE_25BPP_A1888;
> val |= WINCONx_WSWP;
> @@ -695,6 +715,18 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
> break;
> }
>
> + switch (pixel_format) {
> + case DRM_FORMAT_XBGR1555:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_BGR565:
> + writel(WIN_RGB_ORDER_REVERSE, ctx->regs + WIN_RGB_ORDER(win));
> + break;
> + default:
> + writel(WIN_RGB_ORDER_FORWARD, ctx->regs + WIN_RGB_ORDER(win));
> + break;
> + }
> +
> /*
>* Setting dma-burst to 16Word causes permanent tearing for very small
>* buffers, e.g. cursor buffer. Burst Mode switching which based on
> @@ -1074,8 +1106,14 @@ static int fimd_bind(struct device *dev, struct device
> *master, void *data)
> ctx->drm_dev = drm_dev;
>
> for (i = 0; i < WINDOWS_NR; i++) {
> - ctx->configs[i].pixel_formats = fimd_formats;
> - ctx->configs[i].num_pixel_formats = ARRAY_SIZE(fimd_formats);
> + if (ctx->driver_data->has_bgr_support) {
> + ctx->configs[i].pixel_formats = fimd_extended_formats;
> + ctx->configs[i].num_pixel_formats =
> ARRAY_SIZE(fimd_extended_formats);
> + } else {
> + ctx->configs[i].pixel_formats = fimd_formats;
> + ctx->configs[i].num_pixel_forma
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #63 from Randune (randyk...@gmail.com) --- (In reply to Jon from comment #61) > Chiming in as another victim of: > [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125! > > Radeon RX 6700 XT (NAVY_FLOUNDER, DRM 3.42.0, 5.15.15-76051515-generic, LLVM > 12.0.1) > AMD Ryzen 9 5900X > Ubuntu Mate > Mesa 21.2.2 > > Haven't attempted the amdgpu.dpm=0 workaround because the side effects of it > appear to be bad. I've tried amdgpu.dpm=0 and it seriously kills the frame rate in super tux kart at least. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #62 from Randune (randyk...@gmail.com) --- I've been getting "ring gfx timeouts" for some time (See comment 35), most of the time it's when the computer has not had any input for a while (while I'm away from it). When it freezes I can SSH into it but when I try to do a: "shutdown -h now" it boots me out of SSH as it should but the computer never seems to actually shutdown. I've tried many different kernel parameters but no luck so far. I'm now trying the amdgpu.runpm=0 as suggested here: https://wiki.archlinux.org/title/AMDGPU (at the very bottom of the page: Issues with power management / dynamic re-activation of a discrete amdgpu graphics card) I haven't seen any performance repercussions yet. I'll just have to wait it out and see. For my system specs see my previous comment 35. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] HPE BMC GXP SUPPORT
> .../bindings/display/hpe,gxp-thumbnail.txt| 21 + > .../devicetree/bindings/gpio/hpe,gxp-gpio.txt | 16 + > .../devicetree/bindings/i2c/hpe,gxp-i2c.txt | 19 + > .../bindings/ipmi/hpegxp-kcs-bmc-cfg.txt | 13 + > .../bindings/ipmi/hpegxp-kcs-bmc.txt | 21 + Hi Nick In addiiton to the other feedback also given, for new bindings you should be using yaml, not txt. You then gain validation of the bindings. Andrew
Re: [PATCH v6] fbdev: fbmem: Fix the implicit type casting
On Wed, Feb 02, 2022 at 03:58:09PM -0800, Yizhuo Zhai wrote: > In function do_fb_ioctl(), the "arg" is the type of unsigned long, > and in "case FBIOBLANK:" this argument is casted into an int before > passig to fb_blank(). In fb_blank(), the comparision > if (blank > FB_BLANK_POWERDOWN) would be bypass if the original > "arg" is a large number, which is possible because it comes from > the user input. Fix this by adding the check before the function > call. > > Signed-off-by: Yizhuo Zhai Reviewed-by: Guenter Roeck On a side note, change logs would be useful. Guenter > --- > drivers/video/fbdev/core/fbmem.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/video/fbdev/core/fbmem.c > b/drivers/video/fbdev/core/fbmem.c > index 0fa7ede94fa6..13083ad8d751 100644 > --- a/drivers/video/fbdev/core/fbmem.c > +++ b/drivers/video/fbdev/core/fbmem.c > @@ -1160,6 +1160,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned > int cmd, > ret = fbcon_set_con2fb_map_ioctl(argp); > break; > case FBIOBLANK: > + if (arg > FB_BLANK_POWERDOWN) > + return -EINVAL; > console_lock(); > lock_fb_info(info); > ret = fb_blank(info, arg); > -- > 2.25.1 >
[PATCH] drm/amd/pm: add missing prototypes to amdgpu_dpm_internal
Include the header with the prototype to silence the following clang
warnings:
drivers/gpu/drm/amd/amdgpu/../pm/amdgpu_dpm_internal.c:29:6: warning: no
previous prototype for function 'amdgpu_dpm_get_active_displays'
[-Wmissing-prototypes]
void amdgpu_dpm_get_active_displays(struct amdgpu_device *adev)
^
drivers/gpu/drm/amd/amdgpu/../pm/amdgpu_dpm_internal.c:29:1: note: declare
'static' if the function is not intended to be used outside of this
translation unit
void amdgpu_dpm_get_active_displays(struct amdgpu_device *adev)
^
static
drivers/gpu/drm/amd/amdgpu/../pm/amdgpu_dpm_internal.c:76:5: warning: no
previous prototype for function 'amdgpu_dpm_get_vrefresh'
[-Wmissing-prototypes]
u32 amdgpu_dpm_get_vrefresh(struct amdgpu_device *adev)
^
drivers/gpu/drm/amd/amdgpu/../pm/amdgpu_dpm_internal.c:76:1: note: declare
'static' if the function is not intended to be used outside of this
translation unit
u32 amdgpu_dpm_get_vrefresh(struct amdgpu_device *adev)
^
static
2 warnings generated.
Besides that, remove the duplicated prototype of the function
amdgpu_dpm_get_vblank_time in order to keep the consistency of the
headers.
fixes: 6ddbd37f ("drm/amd/pm: optimize the amdgpu_pm_compute_clocks()
implementations")
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/amd/pm/amdgpu_dpm_internal.c | 1 +
drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h | 1 -
drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 1 +
3 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_dpm_internal.c
b/drivers/gpu/drm/amd/pm/amdgpu_dpm_internal.c
index ba5f6413412d..42efe838fa85 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_dpm_internal.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_dpm_internal.c
@@ -25,6 +25,7 @@
#include "amdgpu_display.h"
#include "hwmgr.h"
#include "amdgpu_smu.h"
+#include "amdgpu_dpm_internal.h"
void amdgpu_dpm_get_active_displays(struct amdgpu_device *adev)
{
diff --git a/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
b/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
index 5cc05110cdae..09790413cbc4 100644
--- a/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
+++ b/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
@@ -343,7 +343,6 @@ struct amdgpu_pm {
struct amdgpu_ctx *stable_pstate_ctx;
};
-u32 amdgpu_dpm_get_vblank_time(struct amdgpu_device *adev);
int amdgpu_dpm_read_sensor(struct amdgpu_device *adev, enum amd_pp_sensors
sensor,
void *data, uint32_t *size);
diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
index 7427c50409d4..caae54487f9c 100644
--- a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
+++ b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
@@ -28,6 +28,7 @@
#include "amdgpu_pm.h"
#include "amdgpu_dpm.h"
#include "amdgpu_atombios.h"
+#include "amdgpu_dpm_internal.h"
#include "amd_pcie.h"
#include "sid.h"
#include "r600_dpm.h"
--
2.34.1
linux-next: manual merge of the drm-intel-gt tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-intel-gt tree got a conflict in:
drivers/gpu/drm/i915/i915_reg.h
between commit:
0d6419e9c855 ("drm/i915: Move GT registers to their own header file")
from the drm-intel tree and commit:
270677026261 ("drm/i915/dg2: Add Wa_14015227452")
from the drm-intel-gt tree.
I fixed it up (I used the former version and then added the following
merge fix patch) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
It would be nice if you synced up these 2 trees (by merging one into
the other) as I am carrying several merge fix patches due to the
splitting up of i915_reg.h.
From: Stephen Rothwell
Date: Thu, 3 Feb 2022 11:09:02 +1100
Subject: [PATCH] fix up for "drm/i915: Move GT registers to their own header
file"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 16d98ebee687..a6f0220c2e9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1482,6 +1482,7 @@ enum {
#define GEN9_ROW_CHICKEN4 _MMIO(0xe48c)
#define GEN12_DISABLE_GRF_CLEAR REG_BIT(13)
+#define XEHP_DIS_BBL_SYSPIPE REG_BIT(11)
#define GEN12_DISABLE_TDL_PUSH REG_BIT(9)
#define GEN11_DIS_PICK_2ND_EUREG_BIT(7)
#define GEN12_DISABLE_HDR_PAST_PAYLOAD_HOLD_FIX REG_BIT(4)
--
2.34.1
--
Cheers,
Stephen Rothwell
pgpUarUr69RTM.pgp
Description: OpenPGP digital signature
[Bug 215511] Dual monitor with amd 5700 causes system to hang at startup.
https://bugzilla.kernel.org/show_bug.cgi?id=215511 --- Comment #4 from Jose Mestre (pmes...@gmail.com) --- 0f591d17e36e08313b0c440b99b0e57b47e01a9a is the first bad commit commit 0f591d17e36e08313b0c440b99b0e57b47e01a9a Author: Angus Wang Date: Thu Dec 9 17:27:01 2021 -0500 drm/amd/display: Changed pipe split policy to allow for multi-display pipe split commit ee2698cf79cc759a397c61086c758d4cc85938bf upstream. [WHY] Current implementation of pipe split policy prevents pipe split with multiple displays connected, which caused the MCLK speed to be stuck at max [HOW] Changed the pipe split policies so that pipe split is allowed for multi-display configurations Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1522 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1709 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1655 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1403 Note this is a backport of this commit from amdgpu drm-next for 5.16. Tested-by: Daniel Wheeler Reviewed-by: Aric Cyr Acked-by: Rodrigo Siqueira Signed-off-by: Angus Wang Signed-off-by: Alex Deucher Cc: sta...@vger.kernel.org Signed-off-by: Greg Kroah-Hartman drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_reg.h
between commit:
b3f74938d656 ("drm/i915/pmu: Use PM timestamp instead of RING TIMESTAMP for
reference")
from the drm-intel-fixes tree and commit:
22ba60f617bd ("drm/i915: Move [more] GT registers to their own header file")
from the drm-intel tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp6BW4Ym65c2.pgp
Description: OpenPGP digital signature
[PATCH v6] fbdev: fbmem: Fix the implicit type casting
In function do_fb_ioctl(), the "arg" is the type of unsigned long, and in "case FBIOBLANK:" this argument is casted into an int before passig to fb_blank(). In fb_blank(), the comparision if (blank > FB_BLANK_POWERDOWN) would be bypass if the original "arg" is a large number, which is possible because it comes from the user input. Fix this by adding the check before the function call. Signed-off-by: Yizhuo Zhai --- drivers/video/fbdev/core/fbmem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 0fa7ede94fa6..13083ad8d751 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1160,6 +1160,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, ret = fbcon_set_con2fb_map_ioctl(argp); break; case FBIOBLANK: + if (arg > FB_BLANK_POWERDOWN) + return -EINVAL; console_lock(); lock_fb_info(info); ret = fb_blank(info, arg); -- 2.25.1
[PATCH v6] fbdev: fbmem: Fix the implicit type casting
In function do_fb_ioctl(), the "arg" is the type of unsigned long, and in "case FBIOBLANK:" this argument is casted into an int before passig to fb_blank(). In fb_blank(), the comparision if (blank > FB_BLANK_POWERDOWN) would be bypass if the original "arg" is a large number, which is possible because it comes from the user input. Fix this by adding the check before the function call. Signed-off-by: Yizhuo Zhai --- drivers/video/fbdev/core/fbmem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 0fa7ede94fa6..13083ad8d751 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1160,6 +1160,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, ret = fbcon_set_con2fb_map_ioctl(argp); break; case FBIOBLANK: + if (arg > FB_BLANK_POWERDOWN) + return -EINVAL; console_lock(); lock_fb_info(info); ret = fb_blank(info, arg); -- 2.25.1
Re: [RFC][PATCH] Revert "drm/panel-simple: drop use of data-mapping property"
Hi Christoph, Thank you for the patch. On Tue, Feb 01, 2022 at 12:07:17PM +0100, Christoph Niedermaier wrote: > Without the data-mapping devicetree property my display won't > work properly. It is flickering, because the bus flags won't > be assigned without a defined bus format by the imx parallel > display driver. There was a discussion about the removal [1] > and an agreement that a better solution is needed, but it is > missing so far. So what would be the better approach? > > [1] https://patchwork.freedesktop.org/patch/357659/?series=74705&rev=1 > > This reverts commit d021d751c14752a0266865700f6f212fab40a18c. > > Signed-off-by: Christoph Niedermaier > Cc: Marek Vasut > Cc: Sam Ravnborg > Cc: Laurent Pinchart > Cc: Maxime Ripard > Cc: Philipp Zabel > Cc: David Airlie > Cc: Daniel Vetter > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: linux-arm-ker...@lists.infradead.org > To: dri-devel@lists.freedesktop.org > --- > drivers/gpu/drm/panel/panel-simple.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/panel/panel-simple.c > b/drivers/gpu/drm/panel/panel-simple.c > index 3c08f9827acf..2c683d94a3f3 100644 > --- a/drivers/gpu/drm/panel/panel-simple.c > +++ b/drivers/gpu/drm/panel/panel-simple.c > @@ -453,6 +453,7 @@ static int panel_dpi_probe(struct device *dev, > struct panel_desc *desc; > unsigned int bus_flags; > struct videomode vm; > + const char *mapping; > int ret; > > np = dev->of_node; > @@ -477,6 +478,16 @@ static int panel_dpi_probe(struct device *dev, > of_property_read_u32(np, "width-mm", &desc->size.width); > of_property_read_u32(np, "height-mm", &desc->size.height); > > + of_property_read_string(np, "data-mapping", &mapping); > + if (!strcmp(mapping, "rgb24")) > + desc->bus_format = MEDIA_BUS_FMT_RGB888_1X24; > + else if (!strcmp(mapping, "rgb565")) > + desc->bus_format = MEDIA_BUS_FMT_RGB565_1X16; > + else if (!strcmp(mapping, "bgr666")) > + desc->bus_format = MEDIA_BUS_FMT_RGB666_1X18; > + else if (!strcmp(mapping, "lvds666")) > + desc->bus_format = MEDIA_BUS_FMT_RGB666_1X24_CPADHI; You're right that there's an issue, but a revert isn't the right option. The commit you're reverting never made it in a stable release, because it was deemed to not be a good enough option. First of all, any attempt to fix this should include an update to the DT binding. Second, as this is about DPI panels, the LVDS option should be dropped. Finally, I've shared some initial thoughts in [1], maybe you can reply to that e-mail to continue the discussion there ? https://lore.kernel.org/all/20200303185531.gj11...@pendragon.ideasonboard.com/ > + > /* Extract bus_flags from display_timing */ > bus_flags = 0; > vm.flags = timing->flags; -- Regards, Laurent Pinchart
Re: [PATCH v5] fbdev: fbmem: Fix the implicit type casting
On 2/2/22 15:33, Yizhuo Zhai wrote:
In function do_fb_ioctl(), the "arg" is the type of unsigned long,
and in "case FBIOBLANK:" this argument is casted into an int before
passig to fb_blank(). In fb_blank(), the comparision
if (blank > FB_BLANK_POWERDOWN) would be bypass if the original
"arg" is a large number, which is possible because it comes from
the user input. Fix this by adding the check before the function
call.
Signed-off-by: Yizhuo Zhai
---
drivers/video/fbdev/core/fbmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0fa7ede94fa6..d5dec24c4d16 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1162,6 +1162,11 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
case FBIOBLANK:
console_lock();
lock_fb_info(info);
+ if (arg > FB_BLANK_POWERDOWN) {
+ unlock_fb_info(info);
+ console_unlock();
+ return -EINVAL;
+ }
Is it really necessary to perform this check within the lock ?
arg is a passed in value, and FB_BLANK_POWERDOWN.
It seems to me that
case FBIOBLANK:
if (arg > FB_BLANK_POWERDOWN)
return -EINVAL;
console_lock();
...
should be sufficient.
Sorry if I missed some previous discussion; this is the first time
I looked at this patch.
Guenter
[PATCH v5] fbdev: fbmem: Fix the implicit type casting
In function do_fb_ioctl(), the "arg" is the type of unsigned long,
and in "case FBIOBLANK:" this argument is casted into an int before
passig to fb_blank(). In fb_blank(), the comparision
if (blank > FB_BLANK_POWERDOWN) would be bypass if the original
"arg" is a large number, which is possible because it comes from
the user input. Fix this by adding the check before the function
call.
Signed-off-by: Yizhuo Zhai
---
drivers/video/fbdev/core/fbmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0fa7ede94fa6..d5dec24c4d16 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1162,6 +1162,11 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
case FBIOBLANK:
console_lock();
lock_fb_info(info);
+ if (arg > FB_BLANK_POWERDOWN) {
+ unlock_fb_info(info);
+ console_unlock();
+ return -EINVAL;
+ }
ret = fb_blank(info, arg);
/* might again call into fb_blank */
fbcon_fb_blanked(info, arg);
--
2.25.1
[PATCH v5] fbdev: fbmem: Fix the implicit type casting
In function do_fb_ioctl(), the "arg" is the type of unsigned long,
and in "case FBIOBLANK:" this argument is casted into an int before
passig to fb_blank(). In fb_blank(), the comparision
if (blank > FB_BLANK_POWERDOWN) would be bypass if the original
"arg" is a large number, which is possible because it comes from
the user input. Fix this by adding the check before the function
call.
Signed-off-by: Yizhuo Zhai
---
drivers/video/fbdev/core/fbmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0fa7ede94fa6..d5dec24c4d16 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1162,6 +1162,11 @@ static long do_fb_ioctl(struct fb_info *info, unsigned
int cmd,
case FBIOBLANK:
console_lock();
lock_fb_info(info);
+ if (arg > FB_BLANK_POWERDOWN) {
+ unlock_fb_info(info);
+ console_unlock();
+ return -EINVAL;
+ }
ret = fb_blank(info, arg);
/* might again call into fb_blank */
fbcon_fb_blanked(info, arg);
--
2.25.1
Re: [PATCH] HPE BMC GXP SUPPORT
On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote: > From: Nick Hawkins > > GXP is the name of the HPE SoC. > This SoC is used to implement BMC features of HPE servers > (all ProLiant, Synergy, and many Apollo, and Superdome machines) > It does support many features including: > ARMv7 architecture, and it is based on a Cortex A9 core > Use an AXI bus to which > a memory controller is attached, as well as > multiple SPI interfaces to connect boot flash, > and ROM flash, a 10/100/1000 Mac engine which > supports SGMII (2 ports) and RMII > Multiple I2C engines to drive connectivity with a host > infrastructure > A video engine which support VGA and DP, as well as > an hardware video encoder > Multiple PCIe ports > A PECI interface, and LPC eSPI > Multiple UART for debug purpose, and Virtual UART for host > connectivity > A GPIO engine > This Patch Includes: > Documentation for device tree bindings > Device Tree Bindings > GXP Timer Support > GXP Architecture Support This is far too big for a single patch. It needs to be broken into functional chunks that can be reviewed individually. Each driver and each device tree change along with it's accompanying code need to be done in individual patches. The way it is it can't be reviewed in any sane manner. -corey > > Signed-off-by: Nick Hawkins > --- > .../bindings/display/hpe,gxp-thumbnail.txt| 21 + > .../devicetree/bindings/gpio/hpe,gxp-gpio.txt | 16 + > .../devicetree/bindings/i2c/hpe,gxp-i2c.txt | 19 + > .../bindings/ipmi/hpegxp-kcs-bmc-cfg.txt | 13 + > .../bindings/ipmi/hpegxp-kcs-bmc.txt | 21 + > .../memory-controllers/hpe,gxp-srom.txt | 13 + > .../devicetree/bindings/mtd/hpe,gxp.txt | 16 + > .../bindings/net/hpe,gxp-umac-mdio.txt| 21 + > .../devicetree/bindings/net/hpe,gxp-umac.txt | 20 + > .../devicetree/bindings/pwm/hpe,gxp-fan.txt | 15 + > .../bindings/serial/hpe,gxp-vuart-cfg.txt | 17 + > .../bindings/serial/hpe,gxp-vuart.txt | 23 + > .../bindings/soc/hpe/hpe,gxp-chif.txt | 16 + > .../bindings/soc/hpe/hpe,gxp-csm.txt | 14 + > .../bindings/soc/hpe/hpe,gxp-dbg.txt | 18 + > .../bindings/soc/hpe/hpe,gxp-fn2.txt | 20 + > .../bindings/soc/hpe/hpe,gxp-xreg.txt | 19 + > .../devicetree/bindings/spi/hpe,gxp-spifi.txt | 76 +++ > .../bindings/thermal/hpe,gxp-coretemp.txt | 14 + > .../bindings/timer/hpe,gxp-timer.txt | 18 + > .../devicetree/bindings/usb/hpe,gxp-udc.txt | 21 + > .../devicetree/bindings/vendor-prefixes.yaml | 4 +- > .../bindings/watchdog/hpe,gxp-wdt.txt | 11 + > MAINTAINERS | 14 + > arch/arm/Kconfig | 2 + > arch/arm/boot/dts/Makefile| 2 + > arch/arm/boot/dts/hpe-bmc-dl360gen10.dts | 207 +++ > arch/arm/boot/dts/hpe-gxp.dtsi| 555 ++ > arch/arm/configs/gxp_defconfig| 243 > arch/arm/mach-hpe/Kconfig | 21 + > arch/arm/mach-hpe/Makefile| 1 + > arch/arm/mach-hpe/gxp.c | 62 ++ > drivers/clocksource/Kconfig | 8 + > drivers/clocksource/Makefile | 1 + > drivers/clocksource/gxp_timer.c | 158 + > 35 files changed, 1719 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/display/hpe,gxp-thumbnail.txt > create mode 100644 Documentation/devicetree/bindings/gpio/hpe,gxp-gpio.txt > create mode 100644 Documentation/devicetree/bindings/i2c/hpe,gxp-i2c.txt > create mode 100644 > Documentation/devicetree/bindings/ipmi/hpegxp-kcs-bmc-cfg.txt > create mode 100644 Documentation/devicetree/bindings/ipmi/hpegxp-kcs-bmc.txt > create mode 100644 > Documentation/devicetree/bindings/memory-controllers/hpe,gxp-srom.txt > create mode 100644 Documentation/devicetree/bindings/mtd/hpe,gxp.txt > create mode 100644 > Documentation/devicetree/bindings/net/hpe,gxp-umac-mdio.txt > create mode 100644 Documentation/devicetree/bindings/net/hpe,gxp-umac.txt > create mode 100644 Documentation/devicetree/bindings/pwm/hpe,gxp-fan.txt > create mode 100644 > Documentation/devicetree/bindings/serial/hpe,gxp-vuart-cfg.txt > create mode 100644 Documentation/devicetree/bindings/serial/hpe,gxp-vuart.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-chif.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-csm.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-dbg.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-fn2.txt > create mode 100644 Documentation/devicetree/bindings/soc/hp
Re: [PATCH] HPE BMC GXP SUPPORT
> This is far too big for a single patch. It needs to be broken into > functional chunks that can be reviewed individually. Each driver and > each device tree change along with it's accompanying code need to be > done in individual patches. The way it is it can't be reviewed in any > sane manner. > -corey Thanks for your feedback. We are getting a little bit lost here, as our plan was to submit initial - bindings - dts for SoC and 1 board - initial platform init code Then drivers code avoiding to send many dts updates which might complexify the review. We wanted to send all drivers code to relevant reviewers by tomorrow. So, what you are asking ( do not worry I am not trying to negotiate, I just want to avoid English misunderstandings as I am French) is to send per driver - binding - dts update - driver code For each driver through different submission (with each of them containing the 3 associated parts) ? What shall be the initial one in our case as we are introducing a platform ? An empty dts infrastructure and then we make it grow one step at a time ? vejmarie
Re: [Openipmi-developer] [PATCH] HPE BMC GXP SUPPORT
On Wed, Feb 02, 2022 at 06:14:57PM +, Verdun, Jean-Marie wrote: > > This is far too big for a single patch. It needs to be broken into > > functional chunks that can be reviewed individually. Each driver and > > each device tree change along with it's accompanying code need to be > > done in individual patches. The way it is it can't be reviewed in any > > sane manner. > > > -corey > > Thanks for your feedback. We are getting a little bit lost here, as our plan > was to submit initial > > - bindings > - dts for SoC and 1 board > - initial platform init code > > Then drivers code avoiding to send many dts updates which might complexify > the review. We wanted to send all drivers code to relevant reviewers by > tomorrow. > > So, what you are asking ( do not worry I am not trying to negotiate, I just > want to avoid English misunderstandings as I am French) is to send per driver > > - binding > - dts update > - driver code > > For each driver through different submission (with each of them containing > the 3 associated parts) ? Arnd gave an excellent explaination for this. To be clear, you need to split out changes to individual subsystems and submit those to the maintainers for that subsystem and not send them to everyone. That way you reduce sending emails to people who don't need to see them. Once you have a set of patches for a subsystem, you can submit them as one set. That is generally preferred. The "git send-email" or "git format-patch" tools are generally what we use, they let you compose a header message where you can give an overall explaination, then it sends the individual changes as followup messages to the header message. -corey > > What shall be the initial one in our case as we are introducing a platform ? > An empty dts infrastructure and then we make it grow one step at a time ? > > vejmarie > > > > > > ___ > Openipmi-developer mailing list > openipmi-develo...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openipmi-developer
[PATCH] drm/amd/display: Use NULL pointer instead of plain integer
Assigning 0L to a pointer variable caused the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/rc_calc_fpu.c:71:40:
warning: Using plain integer as NULL pointer
In order to remove this warning, this commit assigns a NULL pointer to
the pointer variable that caused this issue.
Reported-by: kernel test robot
Signed-off-by: Magali Lemes
---
drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c
b/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c
index ec636d06e18c..ef75eb7d5adc 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c
@@ -68,7 +68,7 @@ static void get_qp_set(qp_set qps, enum colour_mode cm, enum
bits_per_comp bpc,
int sel = table_hash(mode, bpc, max_min);
int table_size = 0;
int index;
- const struct qp_entry *table = 0L;
+ const struct qp_entry *table = NULL;
// alias enum
enum { min = DAL_MM_MIN, max = DAL_MM_MAX };
--
2.25.1
[PATCH v4] fbdev: fbmem: Fix the implicit type casting
In function do_fb_ioctl(), the "arg" is the type of unsigned long, and in "case FBIOBLANK:" this argument is casted into an int before passig to fb_blank(). In fb_blank(), the comparision if (blank > FB_BLANK_POWERDOWN) would be bypass if the original "arg" is a large number, which is possible because it comes from the user input. Fix this by adding the check before the function call. Signed-off-by: Yizhuo Zhai --- drivers/video/fbdev/core/fbmem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 0fa7ede94fa6..b3352e23caaa 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1162,6 +1162,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, case FBIOBLANK: console_lock(); lock_fb_info(info); + if (arg > FB_BLANK_POWERDOWN) + return -EINVAL; ret = fb_blank(info, arg); /* might again call into fb_blank */ fbcon_fb_blanked(info, arg); -- 2.25.1
[PATCH v4] fbdev: fbmem: Fix the implicit type casting
In function do_fb_ioctl(), the "arg" is the type of unsigned long, and in "case FBIOBLANK:" this argument is casted into an int before passig to fb_blank(). In fb_blank(), the comparision if (blank > FB_BLANK_POWERDOWN) would be bypass if the original "arg" is a large number, which is possible because it comes from the user input. Fix this by adding the check before the function call. Signed-off-by: Yizhuo Zhai --- drivers/video/fbdev/core/fbmem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 0fa7ede94fa6..b3352e23caaa 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1162,6 +1162,8 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd, case FBIOBLANK: console_lock(); lock_fb_info(info); + if (arg > FB_BLANK_POWERDOWN) + return -EINVAL; ret = fb_blank(info, arg); /* might again call into fb_blank */ fbcon_fb_blanked(info, arg); -- 2.25.1
Re: [PATCH] drm/amd/display: Use NULL pointer instead of plain integer
Applied. Thanks!
Alex
On Wed, Feb 2, 2022 at 5:20 PM Magali Lemes wrote:
>
> Assigning 0L to a pointer variable caused the following warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dsc/rc_calc_fpu.c:71:40:
> warning: Using plain integer as NULL pointer
>
> In order to remove this warning, this commit assigns a NULL pointer to
> the pointer variable that caused this issue.
>
> Reported-by: kernel test robot
> Signed-off-by: Magali Lemes
> ---
> drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c
> b/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c
> index ec636d06e18c..ef75eb7d5adc 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c
> @@ -68,7 +68,7 @@ static void get_qp_set(qp_set qps, enum colour_mode cm,
> enum bits_per_comp bpc,
> int sel = table_hash(mode, bpc, max_min);
> int table_size = 0;
> int index;
> - const struct qp_entry *table = 0L;
> + const struct qp_entry *table = NULL;
>
> // alias enum
> enum { min = DAL_MM_MIN, max = DAL_MM_MAX };
> --
> 2.25.1
>
Re: [PATCH] fbdev: fbmem: Fix the implicit type casting
Not at all, I can draft the new patch and resend. Thanks for all the useful discussion : ) On Wed, Feb 2, 2022 at 9:36 AM Helge Deller wrote: > On 2/2/22 18:27, Sam Ravnborg wrote: > > Hi Helge, > > > > On Tue, Feb 01, 2022 at 04:02:40PM +0100, Helge Deller wrote: > >> On 1/31/22 07:57, Yizhuo Zhai wrote: > >>> In function do_fb_ioctl(), the "arg" is the type of unsigned long, > >> > >> yes, because it comes from the ioctl framework... > >> > >>> and in "case FBIOBLANK:" this argument is casted into an int before > >>> passig to fb_blank(). > >> > >> which makes sense IMHO. > >> > >>> In fb_blank(), the comparision if (blank > FB_BLANK_POWERDOWN) would > >>> be bypass if the original "arg" is a large number, which is possible > >>> because it comes from the user input. > >> > >> The main problem I see with your patch is that you change the behaviour. > >> Let's assume someone passes in -1UL. > >> With your patch applied, this means the -1 (which is e.g. 0x on > 32bit) > >> is converted to a positive integer and will be capped to > FB_BLANK_POWERDOWN. > >> Since most blank functions just check and react on specific values, you > changed > >> the behaviour that the screen now gets blanked at -1, while it wasn't > before. > >> > >> One could now argue, that it's undefined behaviour if people > >> pass in wrong values, but anyway, it's different now. > > > > We should just plug this hole and in case an illegal value is passed > > then return -EINVAL. > > > > Acceptable values are FB_BLANK_UNBLANK..FB_BLANK_POWERDOWN, > > anything less than or greater than should result in -EINVAL. > > Yes, that's the best solution. > Yizhuo Zhai, would you mind to resend with that solution? > > Helge > > > We miss this kind or early checks in many places, and we see the effect > > of this in some drivers where they do it locally for no good. > > > > Sam > -- Kind Regards, *Yizhuo Zhai* *Computer Science, Graduate Student* *University of California, Riverside *
Re: [PATCH v2] drm/msm/dp: add wide bus support
On 02/02/2022 20:49, Kuogee Hsieh wrote:
On 2/2/2022 1:56 AM, Dmitry Baryshkov wrote:
On 02/02/2022 03:30, Kuogee Hsieh wrote:
Normally, mdp will push one pixel of data per pixel clock to
interface to display. Wide bus feature will increase bus
width from 32 bits to 64 bits so that it can push two
pixel of data per pixel clock to interface to display.
This feature is pre requirement to support 4k resolution
since it will reduce pixel clock rate to half of original
rate. Hence pixel clock rate used to drive 4k panel will
not exceed limitation.
Bjorn question is still valid. Why is this required for the 4k panels?
For which clock frequencies/chipsets?
less clock rate will use less power.
Please let me know exactly which info you are looking for.
I'm trying to make sense from the commit message ('pre requirement to
support 4k resolutions') and Bjorn using 4k monitor w/o this patch.
Also I'm trying to understand, when should it be used and which imact
will it have.
changes in v2:
-- remove compression related code from timing
-- remove op_info from struct msm_drm_private
-- remove unnecessary wide_bus_en variables
-- pass wide_bus_en into timing configuration by struct msm_dp
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 +
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 14 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 99
++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 +
drivers/gpu/drm/msm/dp/dp_catalog.c | 15 +++-
drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c | 13 ++-
drivers/gpu/drm/msm/dp/dp_ctrl.h | 1 +
drivers/gpu/drm/msm/dp/dp_display.c | 11 +++
drivers/gpu/drm/msm/dp/dp_display.h | 21 -
drivers/gpu/drm/msm/dp/dp_panel.c | 4 +-
drivers/gpu/drm/msm/dp/dp_panel.h | 2 +-
drivers/gpu/drm/msm/msm_drv.h | 25 ++
14 files changed, 154 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1e648db..7bbdfb9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -217,6 +217,14 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+
+bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc)
+{
+ struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
+
+ return dpu_enc->dp->wide_bus_en;
+}
+
static void _dpu_encoder_setup_dither(struct dpu_hw_pingpong
*hw_pp, unsigned bpc)
{
struct dpu_hw_dither_cfg dither_cfg = { 0 };
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index e241914..0d73550 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -168,4 +168,6 @@ int dpu_encoder_get_linecount(struct drm_encoder
*drm_enc);
*/
int dpu_encoder_get_vsync_count(struct drm_encoder *drm_enc);
+bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc);
+
#endif /* __DPU_ENCODER_H__ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index ddd9d89..b72c33b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -110,6 +110,20 @@ static void drm_mode_to_intf_timing_params(
timing->v_back_porch += timing->v_front_porch;
timing->v_front_porch = 0;
}
+
+ timing->wide_bus_en =
dpu_encoder_is_widebus_enabled(phys_enc->parent);
+
+ /*
+ * for DP, divide the horizonal parameters by 2 when
+ * widebus is enabled
+ */
+ if (timing->wide_bus_en) {
+ timing->width = timing->width >> 1;
+ timing->xres = timing->xres >> 1;
+ timing->h_back_porch = timing->h_back_porch >> 1;
+ timing->h_front_porch = timing->h_front_porch >> 1;
+ timing->hsync_pulse_width = timing->hsync_pulse_width >> 1;
+ }
}
static u32 get_horizontal_total(const struct intf_timing_params
*timing)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 116e2b5..35d4aaa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -33,6 +33,7 @@
#define INTF_TP_COLOR1 0x05C
#define INTF_CONFIG2 0x060
#define INTF_DISPLAY_DATA_HCTL 0x064
+#define INTF_ACTIVE_DATA_HCTL 0x068
#define INTF_FRAME_LINE_COUNT_EN 0x0A8
#define INTF_FRAME_COUNT 0x0AC
#define INTF_LINE_COUNT 0x0B0
@@ -90,68
Re: [PATCH] HPE BMC GXP SUPPORT
On Wed, Feb 2, 2022 at 7:14 PM Verdun, Jean-Marie wrote: > > > This is far too big for a single patch. It needs to be broken into > > functional chunks that can be reviewed individually. Each driver and > > each device tree change along with it's accompanying code need to be > > done in individual patches. The way it is it can't be reviewed in any > > sane manner. > > > -corey > > Thanks for your feedback. We are getting a little bit lost here, as our plan > was to submit initial > > - bindings > - dts for SoC and 1 board > - initial platform init code > > Then drivers code avoiding to send many dts updates which might complexify the > review. We wanted to send all drivers code to relevant reviewers by tomorrow. > > So, what you are asking ( do not worry I am not trying to negotiate, I just > want > to avoid English misunderstandings as I am French) is to send per driver > > - binding > - dts update > - driver code > > For each driver through different submission (with each of them containing the > 3 associated parts) ? > > What shall be the initial one in our case as we are introducing a platform ? > An empty dts infrastructure and then we make it grow one step at a time ? Ideally, what I prefer to see is a series of patches for all "essential" drivers and the platform code that includes: - one patch for each new binding - one patch for each new driver - one patch that hooks up arch/arm/mach-hpe/, MAINTAINERS and any other changes to arch/arm/ other than dts - one patch that adds the initial .dts and .dtsi files, with all the devices added that have a valid binding, no need to split this up any further This should include everything you need to boot into an initramfs shell, typically cpu, serial, timer, clk, pinctrl, gpio, irqchip. We will merge these as a git branch in the soc tree. In parallel, you can work with subsystem maintainers for the "non-essential" drivers to review any other driver and binding, e.g. drm/kms, network, i2c, pci, usb, etc. The patches for the corresponding .dts additions also go through the soc tree, but to make things simpler, you can send those in for a later release. Arnd
Re: [PATCH] drm/i915: Flip guc_id allocation partition
On 13.01.2022 17:27, Matthew Brost wrote:
> Move the multi-lrc guc_id from the lower allocation partition (0 to
> number of multi-lrc guc_ids) to upper allocation partition (number of
> single-lrc to max guc_ids).
>
> This will help when a native driver transitions to a PF after driver
> load time. If the perma-pin guc_ids (kernel contexts) are in a low range
> it is easy reduce total number of guc_ids as the allocated slrc are in a
> valid range the mlrc range moves to an unused range. Assuming no mlrc
> are allocated and few slrc are used the native to PF transition is
> seamless for the guc_id resource.
>
> v2:
> (Michal / Tvrtko)
> - Add an explaination to commit message of why this patch is needed
> (Michal / Piotr)
> - Replace marcos with functions
> (Michal)
> - Rework logic flow in new_mlrc_guc_id
> - Unconditionally call bitmap_free
> v3:
> (Michal)
> - Move allocation of mlrc bitmap back submission init
> (CI)
> - Resend for CI
>
> Signed-off-by: Matthew Brost
> ---
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 77 ++-
> 1 file changed, 56 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 23a40f10d376d..fce58365b3ff8 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -138,17 +138,6 @@ guc_create_parallel(struct intel_engine_cs **engines,
>
> #define GUC_REQUEST_SIZE 64 /* bytes */
>
> -/*
> - * We reserve 1/16 of the guc_ids for multi-lrc as these need to be
> contiguous
> - * per the GuC submission interface. A different allocation algorithm is used
> - * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to
> - * partition the guc_id space. We believe the number of multi-lrc contexts in
> - * use should be low and 1/16 should be sufficient. Minimum of 32 guc_ids for
> - * multi-lrc.
> - */
> -#define NUMBER_MULTI_LRC_GUC_ID(guc) \
> - ((guc)->submission_state.num_guc_ids / 16)
> -
> /*
> * Below is a set of functions which control the GuC scheduling state which
> * require a lock.
> @@ -1746,6 +1735,7 @@ void intel_guc_submission_reset_finish(struct intel_guc
> *guc)
> }
>
> static void destroyed_worker_func(struct work_struct *w);
> +static int number_mlrc_guc_id(struct intel_guc *guc);
>
> /*
> * Set up the memory resources to be shared with the GuC (via the GGTT)
> @@ -1778,7 +1768,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
> destroyed_worker_func);
>
> guc->submission_state.guc_ids_bitmap =
> - bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
> + bitmap_zalloc(number_mlrc_guc_id(guc), GFP_KERNEL);
to fully benefit from the id partition flip we likely will have to
allocate bitmap 'just-in-time' when first mlrc id is needed
so something like you had in early rev but abandon to avoid alloc inside
spinlock - but I'm wondering why we can't alloc bitmap for mlrc case,
while we allow allocation for slrc (as ida_simple_get may alloc, no?
> if (!guc->submission_state.guc_ids_bitmap)
> return -ENOMEM;
>
> @@ -1864,6 +1854,57 @@ static void guc_submit_request(struct i915_request *rq)
> spin_unlock_irqrestore(&sched_engine->lock, flags);
> }
>
> +/*
> + * We reserve 1/16 of the guc_ids for multi-lrc as these need to be
> contiguous
> + * per the GuC submission interface. A different allocation algorithm is used
> + * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to
> + * partition the guc_id space. We believe the number of multi-lrc contexts in
> + * use should be low and 1/16 should be sufficient.
do we have any other numbers as guideline ?
while it is easy assumption that 1/16 from 64K contexts may be
sufficient, what about 1/16 of 1K contexts ? will that work too ?
also, do we have to make hard split ? what if there will be no users for
mlrc but more slrc contexts would be beneficial ? or the opposite ?
> + */
> +#define MLRC_GUC_ID_RATIO16
> +
> +static int number_mlrc_guc_id(struct intel_guc *guc)
> +{
> + return guc->submission_state.num_guc_ids / MLRC_GUC_ID_RATIO;
> +}
> +
> +static int number_slrc_guc_id(struct intel_guc *guc)
> +{
> + return guc->submission_state.num_guc_ids - number_mlrc_guc_id(guc);
> +}
> +
> +static int mlrc_guc_id_base(struct intel_guc *guc)
> +{
> + return number_slrc_guc_id(guc);
> +}
> +
> +static int new_mlrc_guc_id(struct intel_guc *guc, struct intel_context *ce)
> +{
> + int ret;
> +
> + GEM_BUG_ON(!intel_context_is_parent(ce));
> + GEM_BUG_ON(!guc->submission_state.guc_ids_bitmap);
> +
> + ret = bitmap_find_free_region(guc->submission_state.guc_ids_bitmap,
> +number_mlrc_guc_id(guc),
> +order_base_2(ce->parallel.number_children
> +
Re: [PATCH v1 0/3] Add support for eDP PHY on SC7280 platform
Quoting Sankeerth Billakanti (2021-11-15 23:07:35) > This series adds support for the eDP PHY on Qualcomm SC7280 platform. > The changes are dependent on v4 of the new eDP PHY driver introduced by Bjorn: > https://patchwork.kernel.org/project/linux-arm-msm/list/?series=575135 > > Sankeerth Billakanti (3): > dt-bindings: phy: Add eDP PHY compatible for sc7280 > phy: qcom: Add support for eDP PHY on sc7280 > phy: qcom: Program SSC only if supported by sink This series was sent to the wrong maintainers. It's in the phy framework, not the drm framework. Please use scripts/get_maintainers.pl to find the right email addresses and send this series again.
Re: [PATCH v1 1/2] ARM64: dts: qcom: enable eDP panel support for sc7280
Hi,
On Mon, Jan 24, 2022 at 11:04 AM Doug Anderson wrote:
>
> > +&mdss_edp {
> > + status = "okay";
> > +
> > + vdda-1p2-supply = <&vreg_l6b_1p2>;
> > + vdda-0p9-supply = <&vreg_l10c_0p8>;
> > +
> > + ports {
> > + port@1 {
> > + reg = <1>;
> > + edp_out: endpoint {
> > + remote-endpoint = <&edp_panel_in>;
> > + };
> > + };
> > + };
>
> I think part of the above should be in sc7280.dtsi. Basically in
> sc7820.dtsi I think you should have:
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> port@0 {
> reg = <0>;
> edp_in: endpoint {
> remote-endpoint = <&dpu_intf5_out>;
> };
> };
> port@1 {
> reg = <1>;
> edp_out: endpoint {
> };
> };
> };
>
> ...and then the crd dts file just needs:
>
> &edp_out {
> remote-endpoint = <&edp_panel_in>;
> };
>
> Right?
I've attempted to do the sc7280 part of this in:
https://lore.kernel.org/r/20220202132301.v3.7.Ic84bb69c45be2fccf50e3bd17b845fe20eec624c@changeid
Assuming folks think that's good then you should probably base your
next version atop that.
-Doug
Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref histories from debugfs
JFYI I should be able to respond to this soon, I think I'm following your issue a bit more (haven't gotten to go through the patches too so I'm probably going to see if I can reproduce it locally as well. Sorry for the delay - dealing with some X.org stuff and work issues at the moment On Tue, 2022-01-25 at 08:32 +, Lin, Wayne wrote: > [Public] > > Hey Lyude, > > Sorry, just got chance to get back to this and BIG THANKS to elaborating in > such details! > Following are some of my comments : ) > > > -Original Message- > > From: Lyude Paul > > Sent: Wednesday, January 19, 2022 9:59 AM > > To: Lin, Wayne > > Cc: dri-devel@lists.freedesktop.org > > Subject: Re: [PATCH] WIP: drm/dp_mst: Add support for dumping topology ref > > histories from debugfs > > > > Hey - so, the original issue here was that payloads were not always > > deleted when we expected them to be - correct? > > Actually, what I was trying to do is not relevant to payload maintenance. > What I wanted to do is having a way to notify > amdgpu to release its enumerated resource "dc_sink" when unplug event > occurs. Currently, under specific scenarios, > we can't release remote "dc_sink" and ends up can't allocate resource for > new connected monitors. I'll explain the scenario > underneath. > > So, get back to the main issue that I was trying to solve when I pushed the > patchset: > https://patchwork.kernel.org/project/dri-devel/cover/20210720160342.11415-1-wayne@amd.com/ > > I was trying to fix some problems that I observed after these 2 patches > * 09b974e8983 drm/amd/amdgpu_dm/mst: Remove ->destroy_connector() callback > * 72dc0f51591 drm/dp_mst: Remove drm_dp_mst_topology_cbs.destroy_connector > > With above patches, it changes our flow to remove dc_sink (by calling > dc_link_remote_sink()) when connector is about to be > destroyed. And let's see below use cases: > a). Disconnection happens between mst branch devices > e.g. > src - 1st_mstb - 2nd_mstb - sst_monitor => src - 1st_mstb (disconnect) > 2nd_mstb - sst_monitor > > In above case, after receiving CSN, we will put topology reference count of > 2nd mstb and its port which connected to the sst monitor. > As you suggested before, we will destroy 2nd mst branch device and its all > ports due to there is no more mst path can route to them. > As the result of that, we at end call drm_dp_delayed_destroy_port() and > unregister/put the drm connector and eventually call > dc_link_remote_sink() to release the dc_sinck we enumerate for the specific > stream sink of sst_monitor. > > However, in below case: > b). Disconnection happens between mst branch devices and SST monitor > e.g. > src - 1st_mstb - sst_monitor => src - 1st_mstb (disconnect) sst_monitor > > In this case, which is the case having problem, it definitely won't decrease > the topology references count of the port of 1st_mstb which > was connected to the sst monitor to zero since the port is still existing in > the topology. Same as the malloc reference since the port can't get > destroyed. Hence, the port still exists and we won't call > drm_dp_delayed_destroy_port() to unregister and put the drm connector. As > the > result of that, we can't release corresponding remote dc_sink under this > case. And after few times hotplugs, we can't create any new > dc_sink since the number of stream sink is exceeding our limitation. > > Hence, what I'm thinking here is to register a callback function for > notifying us that the remote sink is detached. This just aligns what we do > for handling long HPD event (unplug monitor from system) of legacy DP (none > mst). For which case, once we detect long HPD event > indicating the monitor is detached, we will immediately try to release the > dc_link->local_sink and fire hotplug event to upper layer. > Same as here, once receives a CSN message notifying a drm connector is > changed from connected to disconnected, trigger the callback > function and we can try to release the dc_sink resource. > > > > > If I'm remembering that correctly, then (and I'm not 100% sure on this > > yet) I might already have noticed something very possibly wonky in > > how we handle payload allocations currently, that I found while working on > > the non-atomic removal branch that I linked to you in my > > previous response. Basically, in the > > step1() function it looks like that we follow this general flow with > > updating > > payloads: > > > > * Loop through proposed payloads and compare to previously programmed > > payloads > > - If a payload has a different allocation then it previously did, > > update the > > payload > > - If the payload is new, create it > > - If a payload no longer has an allocation, remove the payload > > > > At first glance this seems totally correct - but I'm not actually entirely > > convinced it is? Particularly because it seems like the order in which > > we do creation/deletion of payloads is totally arbitrary. To explain what > > I mea
Re: [Intel-gfx] [PATCH 1/6] drm: add writeback pointers to drm_connector
Hi Kandpal,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip v5.17-rc2
next-20220202]
[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/Kandpal-Suraj/drm-writeback-connector-changes/20220202-164832
base: git://anongit.freedesktop.org/drm/drm drm-next
config: i386-randconfig-a013-20220131
(https://download.01.org/0day-ci/archive/20220203/202202030437.kmrdd39e-...@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
6b1e844b69f15bb7dffaf9365cd2b355d2eb7579)
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
#
https://github.com/0day-ci/linux/commit/57ad56d769873f62f87fe432243030ceb1678f87
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Kandpal-Suraj/drm-writeback-connector-changes/20220202-164832
git checkout 57ad56d769873f62f87fe432243030ceb1678f87
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Note: the
linux-review/Kandpal-Suraj/drm-writeback-connector-changes/20220202-164832 HEAD
75bbd0a8b1fb58f702279bfbc2fe2d74db8f7028 builds fine.
It only hurts bisectability.
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/vkms/vkms_writeback.c:117:56: error: member reference type
>> 'struct drm_connector *' is a pointer; did you mean to use '->'?
struct drm_connector_state *conn_state = wb_conn->base.state;
~^
->
>> drivers/gpu/drm/vkms/vkms_writeback.c:143:38: error: member reference type
>> 'struct drm_encoder *' is a pointer; did you mean to use '->'?
vkmsdev->output.wb_connector.encoder.possible_crtcs = 1;
^
->
>> drivers/gpu/drm/vkms/vkms_writeback.c:144:27: error: incompatible pointer
>> types passing 'struct drm_connector **' to parameter of type 'struct
>> drm_connector *'; remove & [-Werror,-Wincompatible-pointer-types]
drm_connector_helper_add(&wb->base, &vkms_wb_conn_helper_funcs);
^
include/drm/drm_modeset_helper_vtables.h:1153:67: note: passing argument to
parameter 'connector' here
static inline void drm_connector_helper_add(struct drm_connector *connector,
^
3 errors generated.
vim +117 drivers/gpu/drm/vkms/vkms_writeback.c
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 108
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 109 static void
vkms_wb_atomic_commit(struct drm_connector *conn,
eca22edb37d29f Maxime Ripard2020-11-18 110
struct drm_atomic_state *state)
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 111 {
eca22edb37d29f Maxime Ripard2020-11-18 112 struct
drm_connector_state *connector_state = drm_atomic_get_new_connector_state(state,
eca22edb37d29f Maxime Ripard2020-11-18 113
conn);
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 114 struct vkms_device
*vkmsdev = drm_device_to_vkms_device(conn->dev);
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 115 struct vkms_output
*output = &vkmsdev->output;
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 116 struct
drm_writeback_connector *wb_conn = &output->wb_connector;
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 @117 struct
drm_connector_state *conn_state = wb_conn->base.state;
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 118 struct vkms_crtc_state
*crtc_state = output->composer_state;
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 119
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 120 if (!conn_state)
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 121 return;
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 122
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 123
vkms_set_composer(&vkmsdev->output, true);
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 124
dbd9d80c1b2e03 Rodrigo Siqueira 2020-08-30 125
spin_loc
Re: [PATCH v2 1/2] drm/msm/gpu: Add ctx to get_param()
On Tue, Feb 1, 2022 at 8:16 AM Rob Clark wrote: > > From: Rob Clark > > Prep work for next patch. > > Signed-off-by: Rob Clark > --- > diff --git a/drivers/gpu/drm/msm/msm_rd.c b/drivers/gpu/drm/msm/msm_rd.c > index 7e4d6460719e..dd3605b46264 100644 > --- a/drivers/gpu/drm/msm/msm_rd.c > +++ b/drivers/gpu/drm/msm/msm_rd.c > @@ -197,13 +197,15 @@ static int rd_open(struct inode *inode, struct file > *file) > > /* the parsing tools need to know gpu-id to know which > * register database to load. > +* > +* Note: These particular param does not require a context > */ Minor typo fix, "param does not" -> "params do not" Other than that, series `Reviewed-by: Emma Anholt ` and I love that we're catching non-address-space associated faults now, too!
Re: [RFC v3 00/12] Define and use reset domain for GPU recovery in amdgpu
Just another ping, with Shyun's help I was able to do some smoke testing on XGMI SRIOV system (booting and triggering hive reset) and for now looks good. Andrey On 2022-01-28 14:36, Andrey Grodzovsky wrote: Just a gentle ping if people have more comments on this patch set ? Especially last 5 patches as first 7 are exact same as V2 and we already went over them mostly. Andrey On 2022-01-25 17:37, Andrey Grodzovsky wrote: This patchset is based on earlier work by Boris[1] that allowed to have an ordered workqueue at the driver level that will be used by the different schedulers to queue their timeout work. On top of that I also serialized any GPU reset we trigger from within amdgpu code to also go through the same ordered wq and in this way simplify somewhat our GPU reset code so we don't need to protect from concurrency by multiple GPU reset triggeres such as TDR on one hand and sysfs trigger or RAS trigger on the other hand. As advised by Christian and Daniel I defined a reset_domain struct such that all the entities that go through reset together will be serialized one against another. TDR triggered by multiple entities within the same domain due to the same reason will not be triggered as the first such reset will cancel all the pending resets. This is relevant only to TDR timers and not to triggered resets coming from RAS or SYSFS, those will still happen after the in flight resets finishes. v2: Add handling on SRIOV configuration, the reset notify coming from host and driver already trigger a work queue to handle the reset so drop this intermediate wq and send directly to timeout wq. (Shaoyun) v3: Lijo suggested puting 'adev->in_gpu_reset' in amdgpu_reset_domain struct. I followed his advise and also moved adev->reset_sem into same place. This in turn caused to do some follow-up refactor of the original patches where i decoupled amdgpu_reset_domain life cycle frolm XGMI hive because hive is destroyed and reconstructed for the case of reset the devices in the XGMI hive during probe for SRIOV See [2] while we need the reset sem and gpu_reset flag to always be present. This was attained by adding refcount to amdgpu_reset_domain so each device can safely point to it as long as it needs. [1] https://patchwork.kernel.org/project/dri-devel/patch/20210629073510.2764391-3-boris.brezil...@collabora.com/ [2] https://www.spinics.net/lists/amd-gfx/msg58836.html P.S Going through drm-misc-next and not amd-staging-drm-next as Boris work hasn't landed yet there. P.P.S Patches 8-12 are the refactor on top of the original V2 patchset. P.P.P.S I wasn't able yet to test the reworked code on XGMI SRIOV system because drm-misc-next fails to load there. Would appriciate if maybe jingwech can try it on his system like he tested V2. Andrey Grodzovsky (12): drm/amdgpu: Introduce reset domain drm/amdgpu: Move scheduler init to after XGMI is ready drm/amdgpu: Fix crash on modprobe drm/amdgpu: Serialize non TDR gpu recovery with TDRs drm/amd/virt: For SRIOV send GPU reset directly to TDR queue. drm/amdgpu: Drop hive->in_reset drm/amdgpu: Drop concurrent GPU reset protection for device drm/amdgpu: Rework reset domain to be refcounted. drm/amdgpu: Move reset sem into reset_domain drm/amdgpu: Move in_gpu_reset into reset_domain drm/amdgpu: Rework amdgpu_device_lock_adev Revert 'drm/amdgpu: annotate a false positive recursive locking' drivers/gpu/drm/amd/amdgpu/amdgpu.h | 15 +- drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 275 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 43 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 +- .../gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 18 +- drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 39 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h | 12 + drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 24 +- drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 3 +- drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 6 +- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 14 +- drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 19 +- drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 19 +- drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 11 +- 16 files changed, 313 insertions(+), 199 deletions(-)
[PATCH v3 3/3] drm/msm/dp: replace DRM_DEBUG_DP marco with drm_dbg_dp
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_audio.c | 49 +++--
drivers/gpu/drm/msm/dp/dp_catalog.c | 34 +++-
drivers/gpu/drm/msm/dp/dp_ctrl.c| 106 +++-
drivers/gpu/drm/msm/dp/dp_display.c | 68 +--
drivers/gpu/drm/msm/dp/dp_drm.c | 4 +-
drivers/gpu/drm/msm/dp/dp_link.c| 99 +++--
drivers/gpu/drm/msm/dp/dp_panel.c | 43 +--
drivers/gpu/drm/msm/dp/dp_parser.c | 2 +-
drivers/gpu/drm/msm/dp/dp_power.c | 20 ---
9 files changed, 246 insertions(+), 179 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
b/drivers/gpu/drm/msm/dp/dp_audio.c
index d7e4a39..4fbbe0a 100644
--- a/drivers/gpu/drm/msm/dp/dp_audio.c
+++ b/drivers/gpu/drm/msm/dp/dp_audio.c
@@ -136,7 +136,8 @@ static void dp_audio_stream_sdp(struct dp_audio_private
*audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_1_BIT)
| (parity_byte << PARITY_BYTE_1_BIT));
- DRM_DEBUG_DP("Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_1);
@@ -148,7 +149,8 @@ static void dp_audio_stream_sdp(struct dp_audio_private
*audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_2_BIT)
| (parity_byte << PARITY_BYTE_2_BIT));
- DRM_DEBUG_DP("Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
@@ -162,7 +164,8 @@ static void dp_audio_stream_sdp(struct dp_audio_private
*audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_3_BIT)
| (parity_byte << PARITY_BYTE_3_BIT));
- DRM_DEBUG_DP("Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
@@ -183,8 +186,9 @@ static void dp_audio_timestamp_sdp(struct dp_audio_private
*audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_1_BIT)
| (parity_byte << PARITY_BYTE_1_BIT));
- DRM_DEBUG_DP("Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
- value, parity_byte);
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
+ value, parity_byte);
dp_audio_set_header(catalog, value,
DP_AUDIO_SDP_TIMESTAMP, DP_AUDIO_SDP_HEADER_1);
@@ -196,7 +200,8 @@ static void dp_audio_timestamp_sdp(struct dp_audio_private
*audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_2_BIT)
| (parity_byte << PARITY_BYTE_2_BIT));
- DRM_DEBUG_DP("Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
DP_AUDIO_SDP_TIMESTAMP, DP_AUDIO_SDP_HEADER_2);
@@ -209,7 +214,8 @@ static void dp_audio_timestamp_sdp(struct dp_audio_private
*audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_3_BIT)
| (parity_byte << PARITY_BYTE_3_BIT));
- DRM_DEBUG_DP("Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
DP_AUDIO_SDP_TIMESTAMP, DP_AUDIO_SDP_HEADER_3);
@@ -229,7 +235,8 @@ static void dp_audio_infoframe_sdp(struct dp_audio_private
*audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_1_BIT)
| (parity_byte << PARITY_BYTE_1_BIT));
- DRM_DEBUG_DP("Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
DP_AUDIO_SDP_INFOFRAME, DP_AUDIO_SDP_HEADER
[PATCH v3 2/3] drm/msm/dp: enhance debug info related to dp phy
DP phy should be initialized and exited symmetrically to avoid
clock being stucked at either on or off error. Add debug info
to cover all DP phy to identify clock issues easily.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 245e1b9..dcd0126 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1396,6 +1396,8 @@ void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
dp_catalog_ctrl_phy_reset(ctrl->catalog);
phy_init(phy);
+ DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
+ phy, phy->init_count, phy->power_count);
}
void dp_ctrl_phy_exit(struct dp_ctrl *dp_ctrl)
@@ -1410,6 +1412,8 @@ void dp_ctrl_phy_exit(struct dp_ctrl *dp_ctrl)
dp_catalog_ctrl_phy_reset(ctrl->catalog);
phy_exit(phy);
+ DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
+ phy, phy->init_count, phy->power_count);
}
static bool dp_ctrl_use_fixed_nvid(struct dp_ctrl_private *ctrl)
@@ -1484,6 +1488,8 @@ static int dp_ctrl_deinitialize_mainlink(struct
dp_ctrl_private *ctrl)
phy_exit(phy);
phy_init(phy);
+ DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
+ phy, phy->init_count, phy->power_count);
return 0;
}
@@ -1895,14 +1901,12 @@ int dp_ctrl_off_link_stream(struct dp_ctrl *dp_ctrl)
phy_power_off(phy);
- DRM_DEBUG_DP("After, phy=%x init_count=%d power_on=%d\n",
- (u32)(uintptr_t)phy, phy->init_count, phy->power_count);
-
/* aux channel down, reinit phy */
phy_exit(phy);
phy_init(phy);
- DRM_DEBUG_DP("DP off link/stream done\n");
+ DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
+ phy, phy->init_count, phy->power_count);
return ret;
}
@@ -1933,13 +1937,9 @@ int dp_ctrl_off(struct dp_ctrl *dp_ctrl)
DRM_ERROR("Failed to disable link clocks. ret=%d\n", ret);
}
- DRM_DEBUG_DP("Before, phy=%x init_count=%d power_on=%d\n",
- (u32)(uintptr_t)phy, phy->init_count, phy->power_count);
-
phy_power_off(phy);
-
- DRM_DEBUG_DP("After, phy=%x init_count=%d power_on=%d\n",
- (u32)(uintptr_t)phy, phy->init_count, phy->power_count);
+ DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
+ phy, phy->init_count, phy->power_count);
return ret;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3 0/3] Add connector_type to debug info to differentiate between eDP and DP
1) Add connector_type to debug info to differentiate between eDP and DP 2) add more debug info to cover dp Phy 3) repalce DRM_DEBUG_DP with drm_debug_dp Kuogee Hsieh (3): drm/msm/dp: add connector type to enhance debug messages drm/msm/dp: enhance debug info related to dp phy drm/msm/dp: replace DRM_DEBUG_DP marco with drm_dbg_dp drivers/gpu/drm/msm/dp/dp_audio.c | 49 +-- drivers/gpu/drm/msm/dp/dp_catalog.c | 34 ++- drivers/gpu/drm/msm/dp/dp_ctrl.c| 116 +++- drivers/gpu/drm/msm/dp/dp_display.c | 103 ++-- drivers/gpu/drm/msm/dp/dp_drm.c | 4 +- drivers/gpu/drm/msm/dp/dp_link.c| 99 +- drivers/gpu/drm/msm/dp/dp_panel.c | 43 +++-- drivers/gpu/drm/msm/dp/dp_parser.c | 2 +- drivers/gpu/drm/msm/dp/dp_power.c | 20 --- 9 files changed, 283 insertions(+), 187 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v3 1/3] drm/msm/dp: add connector type to enhance debug messages
DP driver is a generic driver which supports both eDP and DP.
For debugging purpose it is required to have capabilities to
differentiate message are generated from eDP or DP. This patch
add connector type into debug messages for this purpose.
Changes in v3:
-- replace original patch into 3 patches
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 71 ++---
1 file changed, 50 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 1d7f82e..01371dd 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -375,8 +375,9 @@ static int dp_display_process_hpd_high(struct
dp_display_private *dp)
static void dp_display_host_phy_init(struct dp_display_private *dp)
{
- DRM_DEBUG_DP("core_init=%d phy_init=%d\n",
- dp->core_initialized, dp->phy_initialized);
+ DRM_DEBUG_DP("type=%d core_init=%d phy_init=%d\n",
+ dp->dp_display.connector_type, dp->core_initialized,
+ dp->phy_initialized);
if (!dp->phy_initialized) {
dp_ctrl_phy_init(dp->ctrl);
@@ -386,8 +387,9 @@ static void dp_display_host_phy_init(struct
dp_display_private *dp)
static void dp_display_host_phy_exit(struct dp_display_private *dp)
{
- DRM_DEBUG_DP("core_init=%d phy_init=%d\n",
- dp->core_initialized, dp->phy_initialized);
+ DRM_DEBUG_DP("type=%d core_init=%d phy_init=%d\n",
+ dp->dp_display.connector_type, dp->core_initialized,
+ dp->phy_initialized);
if (dp->phy_initialized) {
dp_ctrl_phy_exit(dp->ctrl);
@@ -397,7 +399,9 @@ static void dp_display_host_phy_exit(struct
dp_display_private *dp)
static void dp_display_host_init(struct dp_display_private *dp)
{
- DRM_DEBUG_DP("core_initialized=%d\n", dp->core_initialized);
+ DRM_DEBUG_DP("type=%d core_init=%d phy_init=%d\n",
+ dp->dp_display.connector_type, dp->core_initialized,
+ dp->phy_initialized);
dp_power_init(dp->power, false);
dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
@@ -407,7 +411,9 @@ static void dp_display_host_init(struct dp_display_private
*dp)
static void dp_display_host_deinit(struct dp_display_private *dp)
{
- DRM_DEBUG_DP("core_initialized=%d\n", dp->core_initialized);
+ DRM_DEBUG_DP("type=%d core_init=%d phy_init=%d\n",
+ dp->dp_display.connector_type, dp->core_initialized,
+ dp->phy_initialized);
dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
dp_aux_deinit(dp->aux);
@@ -517,7 +523,9 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
mutex_lock(&dp->event_mutex);
state = dp->hpd_state;
- DRM_DEBUG_DP("hpd_state=%d\n", state);
+ DRM_DEBUG_DP("Before, type=%d hpd_state=%d\n",
+ dp->dp_display.connector_type, state);
+
if (state == ST_DISPLAY_OFF || state == ST_SUSPENDED) {
mutex_unlock(&dp->event_mutex);
return 0;
@@ -549,6 +557,8 @@ static int dp_hpd_plug_handle(struct dp_display_private
*dp, u32 data)
dp_catalog_hpd_config_intr(dp->catalog,
DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, true);
+ DRM_DEBUG_DP("After, type=%d hpd_state=%d\n",
+ dp->dp_display.connector_type, state);
mutex_unlock(&dp->event_mutex);
/* uevent will complete connection part */
@@ -565,8 +575,10 @@ static int dp_connect_pending_timeout(struct
dp_display_private *dp, u32 data)
mutex_lock(&dp->event_mutex);
state = dp->hpd_state;
- if (state == ST_CONNECT_PENDING)
+ if (state == ST_CONNECT_PENDING) {
dp->hpd_state = ST_CONNECTED;
+ DRM_DEBUG_DP("type=%d\n", dp->dp_display.connector_type);
+ }
mutex_unlock(&dp->event_mutex);
@@ -599,6 +611,9 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
state = dp->hpd_state;
+ DRM_DEBUG_DP("Before, type=%d hpd_state=%d\n",
+ dp->dp_display.connector_type, state);
+
/* disable irq_hpd/replug interrupts */
dp_catalog_hpd_config_intr(dp->catalog,
DP_DP_IRQ_HPD_INT_MASK | DP_DP_HPD_REPLUG_INT_MASK, false);
@@ -641,13 +656,15 @@ static int dp_hpd_unplug_handle(struct dp_display_private
*dp, u32 data)
/* start sentinel checking in case of missing uevent */
dp_add_event(dp, EV_DISCONNECT_PENDING_TIMEOUT, 0, DP_TIMEOUT_5_SECOND);
- DRM_DEBUG_DP("hpd_state=%d\n", state);
/* signal the disconnect event early to ensure proper teardown */
dp_display_handle_plugged_change(&dp->dp_display, false);
/* enable HDP plug interrupt to prepare for next plugin */
dp_catalog_hpd_config_intr(dp->catalog, DP_DP_HPD_PLUG_I
Re: fbdev git tree update
Hello Sam, On 2/2/22 19:39, Sam Ravnborg wrote: > Hi Helge, >> >>> How come there are backlight, dt-bindings >> >> I didn't know, and I picked up those at the beginning. >> I did agreed with the backlight maintainers that I should >> keep those which are already in my tree, and that I will ignore >> any upcoming new ones. > Fine, just include this in the cover letter to explain it. Ok, I'll do. >>> and agp in between the fbdev patches? >> >> It wasn't picked up yet, agp somehow belongs to fbdev and as >> maintainer for parisc I was somehow involved as well. >> I'm happy to drop it if you think it belongs somewhere else... > > I see no point in dropping as you are involved and patch seems relevant. > But please explain this in the cover letter so readers are not left > wondering. Ok. Thanks a lot for your feedback ! Helge
Re: [PATCH v2] drm/msm/dp: add connector type to enhance debug messages
On 1/31/2022 6:34 PM, Dmitry Baryshkov wrote:
On 27/01/2022 02:46, Kuogee Hsieh wrote:
DP driver is a generic driver which supports both eDP and DP.
For debugging purpose it is required to have capabilities to
differentiate message are generated from eDP or DP.
This patch do:
1) add connector type into debug messages within dp_display.c
2) revise debug messages related to DP phy within dp_ctrl.c
3) replace DRM_DEBUG_DP marco with drm_dbg_dp
You list three items here. This patch should be split into respective
three parts.
Changes in V2:
-- replace DRM_DEBUG_DP marco with drm_dbg_dp
I suppose that Stephen's idea was to pass proper drm_device to this
function rather than always passing NULL.
yes,
1) pass drm_device at dp_display.c level
2) drm_device point to mdss node. therefore it does not yield any
useful info to differentiate between eDP and DP.
3) since others files level have no drm_device access, pass NULL instead
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_audio.c | 49 +--
drivers/gpu/drm/msm/dp/dp_catalog.c | 34 ++-
drivers/gpu/drm/msm/dp/dp_ctrl.c | 116
+++-
drivers/gpu/drm/msm/dp/dp_display.c | 103
++--
drivers/gpu/drm/msm/dp/dp_drm.c | 4 +-
drivers/gpu/drm/msm/dp/dp_link.c | 99
+-
drivers/gpu/drm/msm/dp/dp_panel.c | 43 +++--
drivers/gpu/drm/msm/dp/dp_parser.c | 2 +-
drivers/gpu/drm/msm/dp/dp_power.c | 20 ---
9 files changed, 283 insertions(+), 187 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
b/drivers/gpu/drm/msm/dp/dp_audio.c
index d7e4a39..4fbbe0a 100644
--- a/drivers/gpu/drm/msm/dp/dp_audio.c
+++ b/drivers/gpu/drm/msm/dp/dp_audio.c
@@ -136,7 +136,8 @@ static void dp_audio_stream_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_1_BIT)
| (parity_byte << PARITY_BYTE_1_BIT));
- DRM_DEBUG_DP("Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_1);
@@ -148,7 +149,8 @@ static void dp_audio_stream_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_2_BIT)
| (parity_byte << PARITY_BYTE_2_BIT));
- DRM_DEBUG_DP("Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
@@ -162,7 +164,8 @@ static void dp_audio_stream_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_3_BIT)
| (parity_byte << PARITY_BYTE_3_BIT));
- DRM_DEBUG_DP("Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
@@ -183,8 +186,9 @@ static void dp_audio_timestamp_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_1_BIT)
| (parity_byte << PARITY_BYTE_1_BIT));
- DRM_DEBUG_DP("Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
- value, parity_byte);
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
+ value, parity_byte);
dp_audio_set_header(catalog, value,
DP_AUDIO_SDP_TIMESTAMP, DP_AUDIO_SDP_HEADER_1);
@@ -196,7 +200,8 @@ static void dp_audio_timestamp_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_2_BIT)
| (parity_byte << PARITY_BYTE_2_BIT));
- DRM_DEBUG_DP("Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
DP_AUDIO_SDP_TIMESTAMP, DP_AUDIO_SDP_HEADER_2);
@@ -209,7 +214,8 @@ static void dp_audio_timestamp_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_3_BIT)
| (parity_byte << PARITY_BYTE_3_BIT));
- DRM_DEBUG_DP("Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
d
Re: fbdev git tree update
Hi Helge, > > > How come there are backlight, dt-bindings > > I didn't know, and I picked up those at the beginning. > I did agreed with the backlight maintainers that I should > keep those which are already in my tree, and that I will ignore > any upcoming new ones. Fine, just include this in the cover letter to explain it. > > and agp in between the fbdev patches? > > It wasn't picked up yet, agp somehow belongs to fbdev and as > maintainer for parisc I was somehow involved as well. > I'm happy to drop it if you think it belongs somewhere else... I see no point in dropping as you are involved and patch seems relevant. But please explain this in the cover letter so readers are not left wondering. Sam
Re: [PATCH v2] drm/msm/dp: add connector type to enhance debug messages
On 1/31/2022 6:34 PM, Dmitry Baryshkov wrote:
On 27/01/2022 02:46, Kuogee Hsieh wrote:
DP driver is a generic driver which supports both eDP and DP.
For debugging purpose it is required to have capabilities to
differentiate message are generated from eDP or DP.
This patch do:
1) add connector type into debug messages within dp_display.c
2) revise debug messages related to DP phy within dp_ctrl.c
3) replace DRM_DEBUG_DP marco with drm_dbg_dp
You list three items here. This patch should be split into respective
three parts.
Changes in V2:
-- replace DRM_DEBUG_DP marco with drm_dbg_dp
I suppose that Stephen's idea was to pass proper drm_device to this
function rather than always passing NULL.
yes,
1) pass drm_device at dp_display.c level
2) drm_device point to mdss node. therefore it does not yield any
useful info to differentiate between eDP and DP.
3) since others files level have no drm_device access, pass NULL instead
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_audio.c | 49 +--
drivers/gpu/drm/msm/dp/dp_catalog.c | 34 ++-
drivers/gpu/drm/msm/dp/dp_ctrl.c | 116
+++-
drivers/gpu/drm/msm/dp/dp_display.c | 103
++--
drivers/gpu/drm/msm/dp/dp_drm.c | 4 +-
drivers/gpu/drm/msm/dp/dp_link.c | 99
+-
drivers/gpu/drm/msm/dp/dp_panel.c | 43 +++--
drivers/gpu/drm/msm/dp/dp_parser.c | 2 +-
drivers/gpu/drm/msm/dp/dp_power.c | 20 ---
9 files changed, 283 insertions(+), 187 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_audio.c
b/drivers/gpu/drm/msm/dp/dp_audio.c
index d7e4a39..4fbbe0a 100644
--- a/drivers/gpu/drm/msm/dp/dp_audio.c
+++ b/drivers/gpu/drm/msm/dp/dp_audio.c
@@ -136,7 +136,8 @@ static void dp_audio_stream_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_1_BIT)
| (parity_byte << PARITY_BYTE_1_BIT));
- DRM_DEBUG_DP("Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
DP_AUDIO_SDP_STREAM, DP_AUDIO_SDP_HEADER_1);
@@ -148,7 +149,8 @@ static void dp_audio_stream_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_2_BIT)
| (parity_byte << PARITY_BYTE_2_BIT));
- DRM_DEBUG_DP("Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
@@ -162,7 +164,8 @@ static void dp_audio_stream_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_3_BIT)
| (parity_byte << PARITY_BYTE_3_BIT));
- DRM_DEBUG_DP("Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
@@ -183,8 +186,9 @@ static void dp_audio_timestamp_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_1_BIT)
| (parity_byte << PARITY_BYTE_1_BIT));
- DRM_DEBUG_DP("Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
- value, parity_byte);
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 1: value = 0x%x, parity_byte = 0x%x\n",
+ value, parity_byte);
dp_audio_set_header(catalog, value,
DP_AUDIO_SDP_TIMESTAMP, DP_AUDIO_SDP_HEADER_1);
@@ -196,7 +200,8 @@ static void dp_audio_timestamp_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_2_BIT)
| (parity_byte << PARITY_BYTE_2_BIT));
- DRM_DEBUG_DP("Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 2: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
dp_audio_set_header(catalog, value,
DP_AUDIO_SDP_TIMESTAMP, DP_AUDIO_SDP_HEADER_2);
@@ -209,7 +214,8 @@ static void dp_audio_timestamp_sdp(struct
dp_audio_private *audio)
parity_byte = dp_audio_calculate_parity(new_value);
value |= ((new_value << HEADER_BYTE_3_BIT)
| (parity_byte << PARITY_BYTE_3_BIT));
- DRM_DEBUG_DP("Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
+ drm_dbg_dp((struct drm_device *)NULL,
+ "Header Byte 3: value = 0x%x, parity_byte = 0x%x\n",
value, parity_byte);
d
Re: fbdev git tree update
Hello Sam, On 2/2/22 18:56, Sam Ravnborg wrote: > Hi Helge, > > On Sun, Jan 30, 2022 at 10:05:39PM +0100, Helge Deller wrote: >> Hello DRI and fbdev developers, >> >> I've now mostly checked all queued-up patches on the fbdev mailing list: >> https://patchwork.kernel.org/project/linux-fbdev/list/ > > Nice to see all the pending fbdev patches processed. Thanks! > I do not see why most of them are applied - why bother with > dev_err_probe or spelling fixes in old drivers that does not see any > active development. But that's your call. Doesn't for every driver at some point the development ceases? Reasons might be that it's not used anymore, or simply because it does what it should do. > How come there are backlight, dt-bindings I didn't know, and I picked up those at the beginning. I did agreed with the backlight maintainers that I should keep those which are already in my tree, and that I will ignore any upcoming new ones. > and agp in between the fbdev patches? It wasn't picked up yet, agp somehow belongs to fbdev and as maintainer for parisc I was somehow involved as well. I'm happy to drop it if you think it belongs somewhere else... > It would be nice to be able to trust that if the fbdev tree has patches > then it is mentioned when the tree touches files outside the fbdev > dir. Sure. Usually I also send out the diffstat. Helge > > > These are the patches that caught my eye: > >> Arnd Bergmann (1): >> agp: define proper stubs for empty helpers >> >> Luca Weiss (2): >> backlight: qcom-wled: Add PM6150L compatible >> dt-bindings: simple-framebuffer: allow standalone compatible >> >> Xu Wang (2): >> backlight: lm3630a_bl: Remove redundant 'flush_workqueue()' calls > > If this was mentioned then fine - but now it looks like patches that do > not belong here. > > Sam >
Re: [PATCH] HPE BMC GXP SUPPORT
Hi Nick, good to see all this stuff coming mainline, On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote: > From: Nick Hawkins > > GXP is the name of the HPE SoC. > This SoC is used to implement BMC features of HPE servers > (all ProLiant, Synergy, and many Apollo, and Superdome machines) > It does support many features including: > ARMv7 architecture, and it is based on a Cortex A9 core > Use an AXI bus to which > a memory controller is attached, as well as > multiple SPI interfaces to connect boot flash, > and ROM flash, a 10/100/1000 Mac engine which > supports SGMII (2 ports) and RMII > Multiple I2C engines to drive connectivity with a host > infrastructure > A video engine which support VGA and DP, as well as > an hardware video encoder > Multiple PCIe ports > A PECI interface, and LPC eSPI > Multiple UART for debug purpose, and Virtual UART for host > connectivity > A GPIO engine > This Patch Includes: > Documentation for device tree bindings > Device Tree Bindings > GXP Timer Support > GXP Architecture Support > > Signed-off-by: Nick Hawkins > --- > .../bindings/display/hpe,gxp-thumbnail.txt| 21 + > .../devicetree/bindings/gpio/hpe,gxp-gpio.txt | 16 + ... All new bindings must be in the DT-schema format (yaml files). This enables a lot of syntax checks and validation. We are slowly migrating away from the .txt based bindings. Also, for new bindings please follow the guide lines listed in Documentation/devicetree/bindings/submitting-patches.rst Consider including the bindings with the drivers using the bindings so things have a more natural split. Sam
Re: fbdev git tree update
Hi Helge, On Sun, Jan 30, 2022 at 10:05:39PM +0100, Helge Deller wrote: > Hello DRI and fbdev developers, > > I've now mostly checked all queued-up patches on the fbdev mailing list: > https://patchwork.kernel.org/project/linux-fbdev/list/ Nice to see all the pending fbdev patches processed. I do not see why most of them are applied - why bother with dev_err_probe or spelling fixes in old drivers that does not see any active development. But that's your call. How come there are backlight, dt-bindings and agp in between the fbdev patches? It would be nice to be able to trust that if the fbdev tree has patches then it is mentioned when the tree touches files outside the fbdev dir. These are the patches that caught my eye: > Arnd Bergmann (1): > agp: define proper stubs for empty helpers > > Luca Weiss (2): > backlight: qcom-wled: Add PM6150L compatible > dt-bindings: simple-framebuffer: allow standalone compatible > > Xu Wang (2): > backlight: lm3630a_bl: Remove redundant 'flush_workqueue()' calls If this was mentioned then fine - but now it looks like patches that do not belong here. Sam
Re: [PATCH v2] drm/msm/dp: add wide bus support
On 2/2/2022 1:56 AM, Dmitry Baryshkov wrote:
On 02/02/2022 03:30, Kuogee Hsieh wrote:
Normally, mdp will push one pixel of data per pixel clock to
interface to display. Wide bus feature will increase bus
width from 32 bits to 64 bits so that it can push two
pixel of data per pixel clock to interface to display.
This feature is pre requirement to support 4k resolution
since it will reduce pixel clock rate to half of original
rate. Hence pixel clock rate used to drive 4k panel will
not exceed limitation.
Bjorn question is still valid. Why is this required for the 4k panels?
For which clock frequencies/chipsets?
less clock rate will use less power.
Please let me know exactly which info you are looking for.
changes in v2:
-- remove compression related code from timing
-- remove op_info from struct msm_drm_private
-- remove unnecessary wide_bus_en variables
-- pass wide_bus_en into timing configuration by struct msm_dp
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 2 +
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 14 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 99
++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 +
drivers/gpu/drm/msm/dp/dp_catalog.c | 15 +++-
drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
drivers/gpu/drm/msm/dp/dp_ctrl.c | 13 ++-
drivers/gpu/drm/msm/dp/dp_ctrl.h | 1 +
drivers/gpu/drm/msm/dp/dp_display.c | 11 +++
drivers/gpu/drm/msm/dp/dp_display.h | 21 -
drivers/gpu/drm/msm/dp/dp_panel.c | 4 +-
drivers/gpu/drm/msm/dp/dp_panel.h | 2 +-
drivers/gpu/drm/msm/msm_drv.h | 25 ++
14 files changed, 154 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1e648db..7bbdfb9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -217,6 +217,14 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
};
+
+bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc)
+{
+ struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
+
+ return dpu_enc->dp->wide_bus_en;
+}
+
static void _dpu_encoder_setup_dither(struct dpu_hw_pingpong
*hw_pp, unsigned bpc)
{
struct dpu_hw_dither_cfg dither_cfg = { 0 };
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index e241914..0d73550 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -168,4 +168,6 @@ int dpu_encoder_get_linecount(struct drm_encoder
*drm_enc);
*/
int dpu_encoder_get_vsync_count(struct drm_encoder *drm_enc);
+bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc);
+
#endif /* __DPU_ENCODER_H__ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index ddd9d89..b72c33b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -110,6 +110,20 @@ static void drm_mode_to_intf_timing_params(
timing->v_back_porch += timing->v_front_porch;
timing->v_front_porch = 0;
}
+
+ timing->wide_bus_en =
dpu_encoder_is_widebus_enabled(phys_enc->parent);
+
+ /*
+ * for DP, divide the horizonal parameters by 2 when
+ * widebus is enabled
+ */
+ if (timing->wide_bus_en) {
+ timing->width = timing->width >> 1;
+ timing->xres = timing->xres >> 1;
+ timing->h_back_porch = timing->h_back_porch >> 1;
+ timing->h_front_porch = timing->h_front_porch >> 1;
+ timing->hsync_pulse_width = timing->hsync_pulse_width >> 1;
+ }
}
static u32 get_horizontal_total(const struct intf_timing_params
*timing)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 116e2b5..35d4aaa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -33,6 +33,7 @@
#define INTF_TP_COLOR1 0x05C
#define INTF_CONFIG2 0x060
#define INTF_DISPLAY_DATA_HCTL 0x064
+#define INTF_ACTIVE_DATA_HCTL 0x068
#define INTF_FRAME_LINE_COUNT_EN 0x0A8
#define INTF_FRAME_COUNT 0x0AC
#define INTF_LINE_COUNT 0x0B0
@@ -90,68 +91,95 @@ static void
dpu_hw_intf_setup_timing_engine(struct dpu_hw_intf *ctx,
u32 hsync_period, vsync_period;
u32 display_v_start, display_v_end;
u32 hsync_start_x, hsync_end_x;
+ u32 hsync_data_start_x, hsync_data_end_x;
u32 active_h_start,
Re: [RFC][PATCH] Revert "drm/panel-simple: drop use of data-mapping property"
On 2/1/22 1:07 PM, Christoph Niedermaier wrote: Without the data-mapping devicetree property my display won't work properly. It is flickering, because the bus flags won't be assigned without a defined bus format by the imx parallel display driver. There was a discussion about the removal [1] and an agreement that a better solution is needed, but it is missing so far. Obviously bus format in panel-dpi is broken, so this revert looks necessary. The current state of panel-dpi isn't consistent with changes introduced in commit 4a1d0dbc8332231d1d500d7a1d13c45457262a97 So what would be the better approach? Another approach is using panel instead of panel-dpi. [1] https://patchwork.freedesktop.org/patch/357659/?series=74705&rev=1 This reverts commit d021d751c14752a0266865700f6f212fab40a18c. But, also you need to revert 99f155d0776fb8838e326efce056aa08e25433d0 Signed-off-by: Christoph Niedermaier Tested-by: Denys Drozdov
[PATCH] HPE BMC GXP SUPPORT
From: Nick Hawkins GXP is the name of the HPE SoC. This SoC is used to implement BMC features of HPE servers (all ProLiant, Synergy, and many Apollo, and Superdome machines) It does support many features including: ARMv7 architecture, and it is based on a Cortex A9 core Use an AXI bus to which a memory controller is attached, as well as multiple SPI interfaces to connect boot flash, and ROM flash, a 10/100/1000 Mac engine which supports SGMII (2 ports) and RMII Multiple I2C engines to drive connectivity with a host infrastructure A video engine which support VGA and DP, as well as an hardware video encoder Multiple PCIe ports A PECI interface, and LPC eSPI Multiple UART for debug purpose, and Virtual UART for host connectivity A GPIO engine This Patch Includes: Documentation for device tree bindings Device Tree Bindings GXP Timer Support GXP Architecture Support Signed-off-by: Nick Hawkins --- .../bindings/display/hpe,gxp-thumbnail.txt| 21 + .../devicetree/bindings/gpio/hpe,gxp-gpio.txt | 16 + .../devicetree/bindings/i2c/hpe,gxp-i2c.txt | 19 + .../bindings/ipmi/hpegxp-kcs-bmc-cfg.txt | 13 + .../bindings/ipmi/hpegxp-kcs-bmc.txt | 21 + .../memory-controllers/hpe,gxp-srom.txt | 13 + .../devicetree/bindings/mtd/hpe,gxp.txt | 16 + .../bindings/net/hpe,gxp-umac-mdio.txt| 21 + .../devicetree/bindings/net/hpe,gxp-umac.txt | 20 + .../devicetree/bindings/pwm/hpe,gxp-fan.txt | 15 + .../bindings/serial/hpe,gxp-vuart-cfg.txt | 17 + .../bindings/serial/hpe,gxp-vuart.txt | 23 + .../bindings/soc/hpe/hpe,gxp-chif.txt | 16 + .../bindings/soc/hpe/hpe,gxp-csm.txt | 14 + .../bindings/soc/hpe/hpe,gxp-dbg.txt | 18 + .../bindings/soc/hpe/hpe,gxp-fn2.txt | 20 + .../bindings/soc/hpe/hpe,gxp-xreg.txt | 19 + .../devicetree/bindings/spi/hpe,gxp-spifi.txt | 76 +++ .../bindings/thermal/hpe,gxp-coretemp.txt | 14 + .../bindings/timer/hpe,gxp-timer.txt | 18 + .../devicetree/bindings/usb/hpe,gxp-udc.txt | 21 + .../devicetree/bindings/vendor-prefixes.yaml | 4 +- .../bindings/watchdog/hpe,gxp-wdt.txt | 11 + MAINTAINERS | 14 + arch/arm/Kconfig | 2 + arch/arm/boot/dts/Makefile| 2 + arch/arm/boot/dts/hpe-bmc-dl360gen10.dts | 207 +++ arch/arm/boot/dts/hpe-gxp.dtsi| 555 ++ arch/arm/configs/gxp_defconfig| 243 arch/arm/mach-hpe/Kconfig | 21 + arch/arm/mach-hpe/Makefile| 1 + arch/arm/mach-hpe/gxp.c | 62 ++ drivers/clocksource/Kconfig | 8 + drivers/clocksource/Makefile | 1 + drivers/clocksource/gxp_timer.c | 158 + 35 files changed, 1719 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/hpe,gxp-thumbnail.txt create mode 100644 Documentation/devicetree/bindings/gpio/hpe,gxp-gpio.txt create mode 100644 Documentation/devicetree/bindings/i2c/hpe,gxp-i2c.txt create mode 100644 Documentation/devicetree/bindings/ipmi/hpegxp-kcs-bmc-cfg.txt create mode 100644 Documentation/devicetree/bindings/ipmi/hpegxp-kcs-bmc.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/hpe,gxp-srom.txt create mode 100644 Documentation/devicetree/bindings/mtd/hpe,gxp.txt create mode 100644 Documentation/devicetree/bindings/net/hpe,gxp-umac-mdio.txt create mode 100644 Documentation/devicetree/bindings/net/hpe,gxp-umac.txt create mode 100644 Documentation/devicetree/bindings/pwm/hpe,gxp-fan.txt create mode 100644 Documentation/devicetree/bindings/serial/hpe,gxp-vuart-cfg.txt create mode 100644 Documentation/devicetree/bindings/serial/hpe,gxp-vuart.txt create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-chif.txt create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-csm.txt create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-dbg.txt create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-fn2.txt create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-xreg.txt create mode 100644 Documentation/devicetree/bindings/spi/hpe,gxp-spifi.txt create mode 100644 Documentation/devicetree/bindings/thermal/hpe,gxp-coretemp.txt create mode 100644 Documentation/devicetree/bindings/timer/hpe,gxp-timer.txt create mode 100644 Documentation/devicetree/bindings/usb/hpe,gxp-udc.txt create mode 100644 Documentation/devicetree/bindings/watchdog/hpe,gxp-wdt.txt create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts create mode 100644 arch/arm/boot/dts/hpe-gxp.dts
Re: [RFC][PATCH] Revert "drm/panel-simple: drop use of data-mapping property"
On 2/1/22 1:07 PM, Christoph Niedermaier wrote: Without the data-mapping devicetree property my display won't work properly. It is flickering, because the bus flags won't be assigned without a defined bus format by the imx parallel display driver. There was a discussion about the removal [1] and an agreement that a better solution is needed, but it is missing so far. Obviously bus format in panel-dpi is broken, so this revert looks necessary. The current state of panel-dpi isn't consistent with changes introduced in commit 4a1d0dbc8332231d1d500d7a1d13c45457262a97 So what would be the better approach? Another approach is using panel instead of panel-dpi. [1]https://patchwork.freedesktop.org/patch/357659/?series=74705&rev=1 This reverts commit d021d751c14752a0266865700f6f212fab40a18c. But, also you need to revert 99f155d0776fb8838e326efce056aa08e25433d0 Signed-off-by: Christoph Niedermaier Tested-by: Denys Drozdov
Re: [PATCH] fbdev: fbmem: Fix the implicit type casting
On 2/2/22 18:27, Sam Ravnborg wrote: > Hi Helge, > > On Tue, Feb 01, 2022 at 04:02:40PM +0100, Helge Deller wrote: >> On 1/31/22 07:57, Yizhuo Zhai wrote: >>> In function do_fb_ioctl(), the "arg" is the type of unsigned long, >> >> yes, because it comes from the ioctl framework... >> >>> and in "case FBIOBLANK:" this argument is casted into an int before >>> passig to fb_blank(). >> >> which makes sense IMHO. >> >>> In fb_blank(), the comparision if (blank > FB_BLANK_POWERDOWN) would >>> be bypass if the original "arg" is a large number, which is possible >>> because it comes from the user input. >> >> The main problem I see with your patch is that you change the behaviour. >> Let's assume someone passes in -1UL. >> With your patch applied, this means the -1 (which is e.g. 0x on >> 32bit) >> is converted to a positive integer and will be capped to FB_BLANK_POWERDOWN. >> Since most blank functions just check and react on specific values, you >> changed >> the behaviour that the screen now gets blanked at -1, while it wasn't before. >> >> One could now argue, that it's undefined behaviour if people >> pass in wrong values, but anyway, it's different now. > > We should just plug this hole and in case an illegal value is passed > then return -EINVAL. > > Acceptable values are FB_BLANK_UNBLANK..FB_BLANK_POWERDOWN, > anything less than or greater than should result in -EINVAL. Yes, that's the best solution. Yizhuo Zhai, would you mind to resend with that solution? Helge > We miss this kind or early checks in many places, and we see the effect > of this in some drivers where they do it locally for no good. > > Sam
[PATCH] drm/i915: opportunistically apply ALLOC_CONTIGIOUS
It looks like this code was accidentally dropped at some point(in a slightly different form), so add it back. The gist is that if we know the allocation will be one single chunk, then we can just annotate the BO with I915_BO_ALLOC_CONTIGUOUS, even if the user doesn't bother. In the future this might prove to be potentially useful. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_region.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c b/drivers/gpu/drm/i915/gem/i915_gem_region.c index a4350227e9ae..dd414a2bcb06 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_region.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c @@ -57,6 +57,9 @@ i915_gem_object_create_region(struct intel_memory_region *mem, size = round_up(size, default_page_size); + if (default_page_size == size) + flags |= I915_BO_ALLOC_CONTIGUOUS; + GEM_BUG_ON(!size); GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_MIN_ALIGNMENT)); -- 2.34.1
Re: [PATCH] fbdev: fbmem: Fix the implicit type casting
Hi Helge, On Tue, Feb 01, 2022 at 04:02:40PM +0100, Helge Deller wrote: > On 1/31/22 07:57, Yizhuo Zhai wrote: > > In function do_fb_ioctl(), the "arg" is the type of unsigned long, > > yes, because it comes from the ioctl framework... > > > and in "case FBIOBLANK:" this argument is casted into an int before > > passig to fb_blank(). > > which makes sense IMHO. > > > In fb_blank(), the comparision if (blank > FB_BLANK_POWERDOWN) would > > be bypass if the original "arg" is a large number, which is possible > > because it comes from the user input. > > The main problem I see with your patch is that you change the behaviour. > Let's assume someone passes in -1UL. > With your patch applied, this means the -1 (which is e.g. 0x on 32bit) > is converted to a positive integer and will be capped to FB_BLANK_POWERDOWN. > Since most blank functions just check and react on specific values, you > changed > the behaviour that the screen now gets blanked at -1, while it wasn't before. > > One could now argue, that it's undefined behaviour if people > pass in wrong values, but anyway, it's different now. We should just plug this hole and in case an illegal value is passed then return -EINVAL. Acceptable values are FB_BLANK_UNBLANK..FB_BLANK_POWERDOWN, anything less than or greater than should result in -EINVAL. We miss this kind or early checks in many places, and we see the effect of this in some drivers where they do it locally for no good. Sam
[RFC v4] drm/amdgpu: Rework reset domain to be refcounted.
The reset domain contains register access semaphor
now and so needs to be present as long as each device
in a hive needs it and so it cannot be binded to XGMI
hive life cycle.
Adress this by making reset domain refcounted and pointed
by each member of the hive and the hive itself.
v4:
Fix crash on boot with XGMI hive by adding type to reset_domain.
XGMI will only create a new reset_domain if prevoius was of single
device type meaning it's first boot. Otherwsie it will take a
refocunt to exsiting reset_domain from the amdgou device.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 6 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 44 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 38 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h | 18 +
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 29 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.h | 2 +-
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 4 +-
drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c | 4 +-
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 4 +-
9 files changed, 118 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 8e96b9a14452..f2ba460bfd59 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -813,9 +813,7 @@ struct amd_powerplay {
#define AMDGPU_RESET_MAGIC_NUM 64
#define AMDGPU_MAX_DF_PERFMONS 4
-struct amdgpu_reset_domain {
- struct workqueue_struct *wq;
-};
+struct amdgpu_reset_domain;
struct amdgpu_device {
struct device *dev;
@@ -1102,7 +1100,7 @@ struct amdgpu_device {
struct amdgpu_reset_control *reset_cntl;
uint32_t
ip_versions[HW_ID_MAX][HWIP_MAX_INSTANCE];
- struct amdgpu_reset_domain reset_domain;
+ struct amdgpu_reset_domain *reset_domain;
};
static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index fef952ca8db5..cd1b7af69c35 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2313,7 +2313,7 @@ static int amdgpu_device_init_schedulers(struct
amdgpu_device *adev)
r = drm_sched_init(&ring->sched, &amdgpu_sched_ops,
ring->num_hw_submission,
amdgpu_job_hang_limit,
- timeout, adev->reset_domain.wq,
ring->sched_score, ring->name);
+ timeout, adev->reset_domain->wq,
ring->sched_score, ring->name);
if (r) {
DRM_ERROR("Failed to create scheduler on ring %s.\n",
ring->name);
@@ -2432,24 +2432,22 @@ static int amdgpu_device_ip_init(struct amdgpu_device
*adev)
if (r)
goto init_failed;
+ /**
+* In case of XGMI grab extra reference for reset domain for this device
+*/
if (adev->gmc.xgmi.num_physical_nodes > 1) {
- struct amdgpu_hive_info *hive;
-
- amdgpu_xgmi_add_device(adev);
+ if (amdgpu_xgmi_add_device(adev) == 0) {
+ struct amdgpu_hive_info *hive =
amdgpu_get_xgmi_hive(adev);
- hive = amdgpu_get_xgmi_hive(adev);
- if (!hive || !hive->reset_domain.wq) {
- DRM_ERROR("Failed to obtain reset domain info for XGMI
hive:%llx", hive->hive_id);
- r = -EINVAL;
- goto init_failed;
- }
+ if (!hive->reset_domain ||
+
!kref_get_unless_zero(&hive->reset_domain->refcount)) {
+ r = -ENOENT;
+ goto init_failed;
+ }
- adev->reset_domain.wq = hive->reset_domain.wq;
- } else {
- adev->reset_domain.wq =
alloc_ordered_workqueue("amdgpu-reset-dev", 0);
- if (!adev->reset_domain.wq) {
- r = -ENOMEM;
- goto init_failed;
+ /* Drop the early temporary reset domain we created for
device */
+ kref_put(&adev->reset_domain->refcount,
amdgpu_reset_destroy_reset_domain);
+ adev->reset_domain = hive->reset_domain;
}
}
@@ -3599,6 +3597,15 @@ int amdgpu_device_init(struct amdgpu_device *adev,
return r;
}
+ /*
+* Reset domain needs to be present early, before XGMI hive discovered
+* (if any) and intitialized to use reset sem and in_gpu reset flag
+* early on during init.
+*/
+ adev->reset_domain = amdgpu_reset_create_reset_domain(SINGLE_DEVICE
,"amdgpu-reset-dev");
+ if (!adev->reset_do
Re: [Intel-gfx] [PATCH v3 1/3] drm: Stop spamming log with drm_cache message
On Tue, Feb 01, 2022 at 09:41:33AM -0800, Lucas De Marchi wrote: > On Tue, Feb 01, 2022 at 09:12:05AM -0800, Jose Souza wrote: > > On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote: > > > Only x86 and in some cases PPC have support added in drm_cache.c for the > > > clflush class of functions. However warning once is sufficient to taint > > > the log instead of spamming it with "Architecture has no drm_cache.c > > > support" every few millisecond. Switch to WARN_ONCE() so we still get > > > the log message, but only once, together with the warning. E.g: > > > > > > [ cut here ] > > > Architecture has no drm_cache.c support > > > WARNING: CPU: 80 PID: 888 at drivers/gpu/drm/drm_cache.c:139 > > > drm_clflush_sg+0x40/0x50 [drm] > > > ... > > > > > > v2 (Jani): use WARN_ONCE() and keep the message previously on pr_err() > > > > Reviewed-by: José Roberto de Souza > > > > But while at it, why not add a drm_device parameter to this function so we > > can use drm_WARN_ONCE()? > > Anyways, it is better than before. > > I thought about that, but it didn't seem justifiable because: > > 1) drm_WARN_ONCE will basically add dev_driver_string() to the log. > However the warning message here is basically helping the bootstrap of > additional archs. They shouldn't be seen on anything properly supported. > > 2) This seems all to be a layer below drm anyway and could even be used > in places outside easy access to a drm pointer. > > So, it seems the benefit of using the subsystem-specific drm_WARN_ONCE > doesn't justify the hassle of changing the callers, possibly adding > additional back pointers to have access to the drm device pointer. Initially I had same feeling as Jose, but good points raised here. Acked-by: Rodrigo Vivi > > thanks > Lucas De Marchi
Re: [PATCH v2 3/3] drm/panel: Add MIPI DBI compatible SPI driver
Hi Noralf, > > > > Parts of it is ergonomics I guess. We're used to having all those > > properties either in the DT or the driver, but here we introduce a new > > way that isn't done anywhere else. > > > > And I don't see any real downside to putting it in the DT? It's going to > > be in an overlay, under the user's control anyway, right? > > > > Ok, I'll spin a new version using DT properties. I like this better than anything else as we then have everything in a single place when we add a new panel and more. I just recall some resistance to add such HW specific setup - but the usecase here is kinda special. Looks forward to see the updated patch! Sam
Re: [PATCH v12 2/9] drm/ingenic: Add support for JZ4780 and HDMI output
On Wednesday, 2 February 2022 13:41:21 CET Paul Cercueil wrote: > Le mer., févr. 2 2022 at 13:33:15 +0100, H. Nikolaus Schaller> a écrit : > >> Am 02.02.2022 um 13:28 schrieb Paul Cercueil : > >> > >> Note that there are other things not working with your current > >> > >> implementation, for instance you cannot set the X/Y start position > >> of the f1 plane, which means it's only really usable for fullscreen > >> desktop/windows. > > > > Is setting x/y possible for the other SoC? > > Yes. They support different x/y positions, sizes, and pixel format for > both f0, f1 and IPU planes. One thing worth noting about the JZ4780 is that a lot of the registers that might otherwise be used for the above purposes appear to be read-only, at least for the different fields concerned. For example, those affecting ingenic_drm_plane_config: Control Register (LCDCTRL) - specifically the BPP0 field OSD Control Register (LCDOSDCTRL) Foreground 0 XY Position Register (LCDXYP0) Foreground 1 XY Position Register (LCDXYP1) Foreground 0 Size Register (LCDSIZE0) Foreground 1 Size Register (LCDSIZE1) These require changes to the extended descriptor members instead, and I am fairly sure I mentioned the implications for pixel depth configuration previously. So, as far as I can tell, we would need to update the descriptors, not the registers, to support the operations mentioned above. As for the f0 plane "not working", I am not aware of any limitation around using only f0 (assuming it corresponds to what the manual calls fg0) or only f1 (again, assuming fg1 in the manual) or both. My assumption was that for this particular driver, f0 was reserved for some kind of overlay and that f1 was to be used for the normal non-overlay display for products where the OSD peripheral is provided. From the definition of struct ingenic_drm: /* * f1 (aka. foreground1) is our primary plane, on top of which * f0 (aka. foreground0) can be overlayed. Z-order is fixed in * hardware and cannot be changed. */ So, as I understood it, the driver would configure f1 in the case of the JZ4780 for basic display support. Configuring f0 as an overlay should be entirely possible, but I imagine that it needs to change the descriptors, not the registers, to have a chance of actually working. I hope this is somewhat useful information. I honestly don't know if, say, the JZ4770 has a similar arrangement with regard to configuration via descriptors, as opposed to registers, but I think it is an important distinction between devices in this particular family that needs to be accommodated in the driver, and we obviously want to determine how this might best be achieved. Paul
Re: [PATCH 5/5] drm/stm: ltdc: add support of ycbcr pixel formats
Hi Yannick,
On Wed, Dec 15, 2021 at 10:48:43PM +0100, Yannick Fertre wrote:
> This patch adds the following YCbCr input pixel formats on the latest
> LTDC hardware version:
>
> 1 plane (co-planar) : YUYV, YVYU, UYVY, VYUY
> 2 planes (semi-planar): NV12, NV21
> 3 planes (full-planar): YU12=I420=DRM YUV420, YV12=DRM YVU420
>
> Signed-off-by: Yannick Fertre
> +static inline void ltdc_set_ycbcr_config(struct drm_plane *plane, u32
> drm_pix_fmt)
> +{
> + struct ltdc_device *ldev = plane_to_ltdc(plane);
> + struct drm_plane_state *state = plane->state;
> + u32 lofs = plane->index * LAY_OFS;
> + u32 val;
> +
> + switch (drm_pix_fmt) {
> + case DRM_FORMAT_YUYV:
> + val = (YCM_I << 4) | LxPCR_YF | LxPCR_CBF;
> + break;
> + case DRM_FORMAT_YVYU:
> + val = (YCM_I << 4) | LxPCR_YF;
> + break;
> + case DRM_FORMAT_UYVY:
> + val = (YCM_I << 4) | LxPCR_CBF;
> + break;
> + case DRM_FORMAT_VYUY:
> + val = (YCM_I << 4);
> + break;
> + case DRM_FORMAT_NV12:
> + val = (YCM_SP << 4) | LxPCR_CBF;
> + break;
> + case DRM_FORMAT_NV21:
> + val = (YCM_SP << 4);
> + break;
> + case DRM_FORMAT_YUV420:
> + case DRM_FORMAT_YVU420:
> + val = (YCM_FP << 4);
> + break;
> + default:
> + /* RGB or not a YCbCr supported format */
> + break;
> + }
> +
> + /* Enable limited range */
> + if (state->color_range == DRM_COLOR_YCBCR_LIMITED_RANGE)
> + val |= LxPCR_YREN;
> +
> + /* enable ycbcr conversion */
> + val |= LxPCR_YCEN;
> +
> + regmap_write(ldev->regmap, LTDC_L1PCR + lofs, val);
> +}
This patch as commit 484e72d3146b ("drm/stm: ltdc: add support of ycbcr
pixel formats") in -next introduced the following clang warning:
drivers/gpu/drm/stm/ltdc.c:625:2: warning: variable 'val' is used uninitialized
whenever switch default is taken [-Wsometimes-uninitialized]
default:
^~~
drivers/gpu/drm/stm/ltdc.c:635:2: note: uninitialized use occurs here
val |= LxPCR_YCEN;
^~~
drivers/gpu/drm/stm/ltdc.c:600:9: note: initialize the variable 'val' to
silence this warning
u32 val;
^
= 0
1 warning generated.
Would it be okay to just return in the default case (maybe with a
message about an unsupported format?) or should there be another fix?
Cheers,
[PATCH v13 8/9] MIPS: DTS: CI20: fix how ddc power is enabled
Originally we proposed a new hdmi-5v-supply regulator reference
for CI20 device tree but that was superseded by a better idea to use
the already defined "ddc-en-gpios" property of the "hdmi-connector".
Since "MIPS: DTS: CI20: Add DT nodes for HDMI setup" has already
been applied to v5.17-rc1, we add this on top.
Fixes: ae1b8d2c2de9 ("MIPS: DTS: CI20: Add DT nodes for HDMI setup")
Signed-off-by: H. Nikolaus Schaller
Reviewed-by: Paul Cercueil
---
arch/mips/boot/dts/ingenic/ci20.dts | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
b/arch/mips/boot/dts/ingenic/ci20.dts
index 3e336b3dbb109..ab6e3dc0bc1d0 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -83,6 +83,8 @@ hdmi_out: connector {
label = "HDMI OUT";
type = "a";
+ ddc-en-gpios = <&gpa 25 GPIO_ACTIVE_HIGH>;
+
port {
hdmi_con: endpoint {
remote-endpoint = <&dw_hdmi_out>;
@@ -114,17 +116,6 @@ otg_power: fixedregulator@2 {
gpio = <&gpf 14 GPIO_ACTIVE_LOW>;
enable-active-high;
};
-
- hdmi_power: fixedregulator@3 {
- compatible = "regulator-fixed";
-
- regulator-name = "hdmi_power";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
-
- gpio = <&gpa 25 0>;
- enable-active-high;
- };
};
&ext {
@@ -576,8 +567,6 @@ &hdmi {
pinctrl-names = "default";
pinctrl-0 = <&pins_hdmi_ddc>;
- hdmi-5v-supply = <&hdmi_power>;
-
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.33.0
[PATCH v13 5/9] drm/synopsys+ingenic: repair hot plug detection
so that it calls drm_kms_helper_hotplug_event().
We need to set .poll_enabled but that struct component
can only be accessed in the core code. Hence we add a public
setter function.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 2 ++
include/drm/bridge/dw_hdmi.h | 1 +
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 54d8fdad395f5..52e7cd2e020d3 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3216,6 +3216,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
return 0;
}
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
+{
+ if (hdmi->bridge.dev)
+ hdmi->bridge.dev->mode_config.poll_enabled = enable;
+ else
+ dev_warn(hdmi->dev, "no hdmi->bridge.dev");
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
+
struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
{
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
index 34e986dd606cf..90547a28dc5c7 100644
--- a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -55,6 +55,8 @@ ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
if (mode->clock > 216000)
return MODE_CLOCK_HIGH;
+ dw_hdmi_enable_poll(hdmi, true);
+
return MODE_OK;
}
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 2a1f85f9a8a3f..963960794b40e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -196,5 +196,6 @@ enum drm_connector_status dw_hdmi_phy_read_hpd(struct
dw_hdmi *hdmi,
void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
bool force, bool disabled, bool rxsense);
void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);
#endif /* __IMX_HDMI_H__ */
--
2.33.0
[PATCH v13 6/9] dw-hdmi/ingenic-dw-hdmi: repair interworking with hdmi-connector
Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
introduced a new mechanism to negotiate bus formats between hdmi connector
and the synopsys hdmi driver inside the jz4780.
By this, the dw-hdmi is no longer the only bridge and sets up a list
of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().
This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780 but only
produces a black screen.
This fix is based on the observation that max_bpc = 0 when running this
function while info->bpc = 8. Since the formats checks before this always test
for max_bpc >= info->pbc indirectly my assumption is that we must check it
here as well.
Adding the proposed patch makes the CI20/jz4780 panel work again in
MEDIA_BUS_FMT_RGB888_1X24 mode.
Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 52e7cd2e020d3..34703a15ee4ff 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2620,10 +2620,10 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
}
- if (info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCRCB422)
output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
- if (info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCRCB444)
output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
/* Default 8bit RGB fallback */
--
2.33.0
[PATCH v13 4/9] drm/ingenic: Add dw-hdmi driver specialization for jz4780
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780 HDMI support. This requires a new driver, plus device tree and
configuration modifications.
Here we add Kconfig DRM_INGENIC_DW_HDMI, Makefile and driver code.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/Kconfig | 9 ++
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 104 ++
3 files changed, 114 insertions(+)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index 001f59fb06d56..090830bcbde7f 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -24,4 +24,13 @@ config DRM_INGENIC_IPU
The Image Processing Unit (IPU) will appear as a second primary plane.
+config DRM_INGENIC_DW_HDMI
+ tristate "Ingenic specific support for Synopsys DW HDMI"
+ depends on MACH_JZ4780
+ select DRM_DW_HDMI
+ help
+ Choose this option to enable Synopsys DesignWare HDMI based driver.
+ If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
+ select this option.
+
endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index d313326bdddbb..f10cc1c5a5f22 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
ingenic-drm-y = ingenic-drm-drv.o
ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
+obj-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
new file mode 100644
index 0..34e986dd606cf
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019, 2020 Paul Boddie
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ * Probe and remove operations derived from rcar_dw_hdmi.c.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
+ { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
} } },
+ { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
} } },
+ { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
} } },
+ { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
} } },
+ { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
} } }
+};
+
+static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
+ /*pixelclk bpp8bpp10 bpp12 */
+ { 5400, { 0x091c, 0x091c, 0x06dc } },
+ { 5840, { 0x091c, 0x06dc, 0x06dc } },
+ { 7200, { 0x06dc, 0x06dc, 0x091c } },
+ { 7425, { 0x06dc, 0x0b5c, 0x091c } },
+ { 11880, { 0x091c, 0x091c, 0x06dc } },
+ { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+ { ~0UL, { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 21600, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+ /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
+ if (mode->clock > 216000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
+ .mpll_cfg = ingenic_mpll_cfg,
+ .cur_ctr= ingenic_cur_ctr,
+ .phy_config = ingenic_phy_config,
+ .mode_valid = ingenic_dw_hdmi_mode_valid,
+ .output_port= 1,
+};
+
+static const struct of_device_id ingenic_dw_hdmi_dt_ids[] = {
+ { .compatible = "ingenic,jz4780-dw-hdmi" },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ingenic_dw_hdmi_dt_ids);
+
+static void ingenic_dw_hdmi_cleanup(void *data)
+{
+ struct dw_hdmi *hdmi = (struct dw_hdmi *)data;
+
+ dw_hdmi_remove(hdmi);
+}
+
+static int ingenic_dw_hdmi_probe(struct platform_device *pdev)
+{
+ struct dw_hdmi *hdmi;
+
+ hdmi = dw_hdmi_probe(pdev, &ingenic_dw_hdmi_plat_data);
+ if (IS_ERR(hdmi))
+ return PTR_ERR(hdmi);
+
+ return devm_add_action_or_reset(&pdev->dev, ingenic_dw_hdmi_cleanup,
hdmi);
+}
+
+static struct platform_
[PATCH v13 7/9] drm/bridge: display-connector: add ddc-en gpio support
"hdmi-connector.yaml" bindings defines an optional property
"ddc-en-gpios" for a single gpio to enable DDC operation.
Usually this controls +5V power on the HDMI connector.
This +5V may also be needed for HPD.
This was not reflected in code.
Now, the driver activates the ddc gpio after probe and
deactivates after remove so it is "almost on".
But only if this driver is loaded (and not e.g. blacklisted
as module).
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/display-connector.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index d24f5b90feabf..e4d52a7e31b71 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -24,6 +24,7 @@ struct display_connector {
int hpd_irq;
struct regulator*dp_pwr;
+ struct gpio_desc*ddc_en;
};
static inline struct display_connector *
@@ -345,6 +346,17 @@ static int display_connector_probe(struct platform_device
*pdev)
}
}
+ /* enable DDC */
+ if (type == DRM_MODE_CONNECTOR_HDMIA) {
+ conn->ddc_en = devm_gpiod_get_optional(&pdev->dev, "ddc-en",
+ GPIOD_OUT_HIGH);
+
+ if (IS_ERR(conn->ddc_en)) {
+ dev_err(&pdev->dev, "Couldn't get ddc-en gpio\n");
+ return PTR_ERR(conn->ddc_en);
+ }
+ }
+
conn->bridge.funcs = &display_connector_bridge_funcs;
conn->bridge.of_node = pdev->dev.of_node;
@@ -373,6 +385,9 @@ static int display_connector_remove(struct platform_device
*pdev)
{
struct display_connector *conn = platform_get_drvdata(pdev);
+ if (conn->ddc_en)
+ gpiod_set_value(conn->ddc_en, 0);
+
if (conn->dp_pwr)
regulator_disable(conn->dp_pwr);
--
2.33.0
[PATCH v13 3/9] dt-bindings: display: Add ingenic, jz4780-dw-hdmi DT Schema
From: Sam Ravnborg
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Based on .txt binding from Zubair Lutfullah Kakakhel
Signed-off-by: Sam Ravnborg
Signed-off-by: H. Nikolaus Schaller
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
---
.../display/bridge/ingenic,jz4780-hdmi.yaml | 82 +++
1 file changed, 82 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
new file mode 100644
index 0..b8219eab4475a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ingenic,jz4780-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic JZ4780 HDMI Transmitter
+
+maintainers:
+ - H. Nikolaus Schaller
+
+description: |
+ The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI 1.4
+ TX controller IP with accompanying PHY IP.
+
+allOf:
+ - $ref: synopsys,dw-hdmi.yaml#
+
+properties:
+ compatible:
+const: ingenic,jz4780-dw-hdmi
+
+ reg-io-width:
+const: 4
+
+ clocks:
+maxItems: 2
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input from LCD controller output.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Link to the HDMI connector.
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - ports
+ - reg-io-width
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+hdmi: hdmi@1018 {
+compatible = "ingenic,jz4780-dw-hdmi";
+reg = <0x1018 0x8000>;
+reg-io-width = <4>;
+ddc-i2c-bus = <&i2c4>;
+interrupt-parent = <&intc>;
+interrupts = <3>;
+clocks = <&cgu JZ4780_CLK_AHB0>, <&cgu JZ4780_CLK_HDMI>;
+clock-names = "iahb", "isfr";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+hdmi_in: port@0 {
+reg = <0>;
+dw_hdmi_in: endpoint {
+remote-endpoint = <&jz4780_lcd_out>;
+};
+};
+hdmi_out: port@1 {
+reg = <1>;
+dw_hdmi_out: endpoint {
+remote-endpoint = <&hdmi_con>;
+};
+};
+};
+};
+
+...
--
2.33.0
[PATCH v13 2/9] drm/ingenic: Add support for JZ4780 and HDMI output
From: Paul Boddie
Add support for the LCD controller present on JZ4780 SoCs.
This SoC uses 8-byte descriptors which extend the current
4-byte descriptors used for other Ingenic SoCs.
Tested on MIPS Creator CI20 board.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 63 ++-
drivers/gpu/drm/ingenic/ingenic-drm.h | 38 ++
2 files changed, 100 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 9c60fc4605e4b..caa70fdd45466 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -6,6 +6,7 @@
#include "ingenic-drm.h"
+#include
#include
#include
#include
@@ -49,6 +50,11 @@ struct ingenic_dma_hwdesc {
u32 addr;
u32 id;
u32 cmd;
+ /* extended hw descriptor for jz4780 */
+ u32 offsize;
+ u32 pagewidth;
+ u32 cpos;
+ u32 dessize;
} __aligned(16);
struct ingenic_dma_hwdescs {
@@ -59,7 +65,10 @@ struct ingenic_dma_hwdescs {
struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
+ bool has_alpha;
bool map_noncoherent;
+ bool use_extended_hwdesc;
+ bool plane_f0_not_working;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
unsigned int num_formats_f0, num_formats_f1;
@@ -446,6 +455,9 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
if (!crtc)
return 0;
+ if (priv->soc_info->plane_f0_not_working && plane == &priv->f0)
+ return -EINVAL;
+
crtc_state = drm_atomic_get_existing_crtc_state(state,
crtc);
if (WARN_ON(!crtc_state))
@@ -662,6 +674,33 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
hwdesc->cmd = JZ_LCD_CMD_EOF_IRQ | (width * height * cpp / 4);
hwdesc->next = dma_hwdesc_addr(priv, next_id);
+ if (priv->soc_info->use_extended_hwdesc) {
+ hwdesc->cmd |= JZ_LCD_CMD_FRM_ENABLE;
+
+ /* Extended 8-byte descriptor */
+ hwdesc->cpos = 0;
+ hwdesc->offsize = 0;
+ hwdesc->pagewidth = 0;
+
+ switch (newstate->fb->format->format) {
+ case DRM_FORMAT_XRGB1555:
+ hwdesc->cpos |= JZ_LCD_CPOS_RGB555;
+ fallthrough;
+ case DRM_FORMAT_RGB565:
+ hwdesc->cpos |= JZ_LCD_CPOS_BPP_15_16;
+ break;
+ case DRM_FORMAT_XRGB:
+ hwdesc->cpos |= JZ_LCD_CPOS_BPP_18_24;
+ break;
+ }
+ hwdesc->cpos |= (JZ_LCD_CPOS_COEFFICIENT_1 <<
+JZ_LCD_CPOS_COEFFICIENT_OFFSET);
+ hwdesc->dessize =
+ (0xff << JZ_LCD_DESSIZE_ALPHA_OFFSET) |
+ FIELD_PREP(JZ_LCD_DESSIZE_HEIGHT_MASK, height -
1) |
+ FIELD_PREP(JZ_LCD_DESSIZE_WIDTH_MASK, width -
1);
+ }
+
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
fourcc = newstate->fb->format->format;
@@ -693,6 +732,9 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
| JZ_LCD_CFG_SPL_DISABLE | JZ_LCD_CFG_REV_DISABLE;
}
+ if (priv->soc_info->use_extended_hwdesc)
+ cfg |= JZ_LCD_CFG_DESCRIPTOR_8;
+
if (mode->flags & DRM_MODE_FLAG_NHSYNC)
cfg |= JZ_LCD_CFG_HSYNC_ACTIVE_LOW;
if (mode->flags & DRM_MODE_FLAG_NVSYNC)
@@ -1015,6 +1057,7 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
long parent_rate;
unsigned int i, clone_mask = 0;
int ret, irq;
+ u32 osdc = 0;
soc_info = of_device_get_match_data(dev);
if (!soc_info) {
@@ -1272,7 +1315,10 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
/* Enable OSD if available */
if (soc_info->has_osd)
- regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN);
+ osdc |= JZ_LCD_OSDC_OSDEN;
+ if (soc_info->has_alpha)
+ osdc |= JZ_LCD_OSDC_ALPHAEN;
+ regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
mutex_init(&priv->clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1468,10 +1514,25 @@ static const struct jz_soc_info jz4770_soc_info = {
.num_formats_f0 = ARRAY_SIZE(jz4770_formats_f0),
};
+static const struct jz_soc_
[PATCH v13 1/9] drm/ingenic: prepare ingenic drm for later addition of JZ4780
This changes the way the regmap is allocated to prepare for the
later addition of the JZ4780 which has more registers and bits
than the others.
Therefore we make the regmap as big as the reg property in
the device tree tells.
Suggested-by: Paul Cercueil
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index b4943a56be09b..9c60fc4605e4b 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -173,7 +173,6 @@ static const struct regmap_config ingenic_drm_regmap_config
= {
.val_bits = 32,
.reg_stride = 4,
- .max_register = JZ_REG_LCD_SIZE1,
.writeable_reg = ingenic_drm_writeable_reg,
};
@@ -1011,6 +1010,8 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
struct ingenic_drm_bridge *ib;
struct drm_device *drm;
void __iomem *base;
+ struct resource *res;
+ struct regmap_config regmap_config;
long parent_rate;
unsigned int i, clone_mask = 0;
int ret, irq;
@@ -1056,14 +1057,16 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
drm->mode_config.funcs = &ingenic_drm_mode_config_funcs;
drm->mode_config.helper_private = &ingenic_drm_mode_config_helpers;
- base = devm_platform_ioremap_resource(pdev, 0);
+ base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
if (IS_ERR(base)) {
dev_err(dev, "Failed to get memory resource\n");
return PTR_ERR(base);
}
+ regmap_config = ingenic_drm_regmap_config;
+ regmap_config.max_register = res->end - res->start;
priv->map = devm_regmap_init_mmio(dev, base,
- &ingenic_drm_regmap_config);
+ ®map_config);
if (IS_ERR(priv->map)) {
dev_err(dev, "Failed to create regmap\n");
return PTR_ERR(priv->map);
--
2.33.0
[PATCH v13 0/9] MIPS: JZ4780 and CI20 HDMI
PATCH V13 2022-02-02 17:31:22: * 7/9: remove call to gpiod_set_value() because of GPIOD_OUT_HIGH (by p...@crapouillou.net) * 4/9: replace ".." by "." (by p...@crapouillou.net) * 3/9: remove old hdmi-5v-power in the example (by p...@crapouillou.net) * 2/9: disable handling of plane f0 only for jz4780 (by p...@crapouillou.net) PATCH V12 2022-01-31 13:26:54: This version reworks how hdmi ddc power is controlled by connector and not by ddc/hdmi bridge driver. Also some patches of the previous version of this series have been removed since they are already applied to mips-next/linux/next/v5.17-rc1. Fixes and changes: - repair interworking of dw-hdmi with connector-hdmi (by h...@goldelico.com) - fix JZ_REG_LCD_OSDC setup for jz4780 (by h...@goldelico.com and p...@crapouillou.net) - adjustments for ci20.dts to use connector gpio for +5v (suggested by several) - to add control of "ddc-en-gpios" to hdmi-connector driver (by h...@goldelico.com) - regulator code removed because we now use the "ddc-en-gpios" of the connector driver (suggested by p...@crapouillou.net) - bindings: addition of "ddc-i2c-bus" and "hdmi-5v-supply" removed (suggested by robh...@kernel.org) - rebase on v5.17-rc2 PATCH V11 2021-12-02 19:39:52: - patch 4/8: change devm_regulator_get_optional to devm_regulator_get and remove NULL check (requested by broo...@kernel.org) - patch 3/8: make hdmi-5v-supply required (requested by broo...@kernel.org) PATCH V10 2021-11-30 22:26:41: - patch 3/8: fix $id and $ref paths (found by r...@kernel.org) PATCH V9 2021-11-24 22:29:14: - patch 6/8: remove optional <0> for assigned-clocks and unintentionally included "unwedge" setup (found by p...@crapouillou.net) - patch 4/8: some cosmetics make regulator enable/disable only if not NULL (found by p...@crapouillou.net) simplify/fix error handling and driver cleanup on remove (proposed by p...@crapouillou.net) - patch 3/8: fix #include path in example (found by p...@crapouillou.net) fix missing "i" in unevaluatedProperties (found by r...@kernel.org) fix 4 spaces indentation for required: property (found by r...@kernel.org) PATCH V8 2021-11-23 19:14:00: - fix a bad editing result from patch 2/8 (found by p...@crapouillou.net) PATCH V7 2021-11-23 18:46:23: - changed gpio polarity of hdmi_power to 0 (suggested by p...@crapouillou.net) - fixed LCD1 irq number (bug found by p...@crapouillou.net) - removed "- 4" for calculating max_register (suggested by p...@crapouillou.net) - use unevaluatedPropertes instead of additionalProperties (suggested by r...@kernel.org) - moved and renamed ingenic,jz4780-hdmi.yaml (suggested by r...@kernel.org) - adjusted assigned-clocks changes to upstream which added some for SSI (by h...@goldelico.com) - rebased and tested with v5.16-rc2 + patch set drm/ingenic by p...@crapouillou.net (by h...@goldelico.com) PATCH V6 2021-11-10 20:43:33: - changed CONFIG_DRM_INGENIC_DW_HDMI to "m" (by h...@goldelico.com) - made ingenic-dw-hdmi an independent platform driver which can be compiled as module and removed error patch fixes for IPU (suggested by p...@crapouillou.net) - moved assigned-clocks from jz4780.dtsi to ci20.dts (suggested by p...@crapouillou.net) - fixed reg property in jz4780.dtsi to cover all registers incl. gamma and vee (by h...@goldelico.com) - added a base patch to calculate regmap size from DTS reg property (requested by p...@crapouillou.net) - restored resetting all bits except one in LCDOSDC (requested by p...@crapouillou.net) - clarified setting of cpos (suggested by p...@crapouillou.net) - moved bindings definition for ddc-i2c-bus (suggested by p...@crapouillou.net) - simplified mask definitions for JZ_LCD_DESSIZE (requested by p...@crapouillou.net) - removed setting alpha premultiplication (suggested by p...@crapouillou.net) - removed some comments (suggested by p...@crapouillou.net) PATCH V5 2021-10-05 14:28:44: - dropped mode_fixup and timings support in dw-hdmi as it is no longer needed in this V5 (by h...@goldelico.com) - dropped "drm/ingenic: add some jz4780 specific features" (stimulated by p...@crapouillou.net) - fixed typo in commit subject: "synopsis" -> "synopsys" (by h...@goldelico.com) - swapped clocks in jz4780.dtsi to match synopsys,dw-hdmi.yaml (by h...@goldelico.com) - improved, simplified, fixed, dtbschecked ingenic-jz4780-hdmi.yaml and made dependent of bridge/synopsys,dw-hdmi.yaml (based on suggestions by max...@cerno.tech) - fixed binding vs. driver&DTS use of hdmi-5v regulator (suggested by max...@cerno.tech) - dropped "drm/bridge: synopsis: Fix to properly handle HPD" - was a no longer needed workaround for a previous version (suggested by max...@cerno.tech) PATCH V4 2021-09-27 18:44:38: - fix setting output_port = 1 (issue found by p...@crapouillou.net) - ci20.dts: convert to use hdmi-connector (by h...@goldelico.com) - add a hdmi-regulator to control +5V power (by h...@goldelico.com) - added a fix to
Re: [PATCH v5 0/5] drm: exynos: dsi: Convert drm bridge
Hi Marek, On Fri, Jan 21, 2022 at 6:14 PM Marek Szyprowski wrote: > > Hi Jagan, > > On 21.01.2022 12:40, Jagan Teki wrote: > > On Fri, Jan 21, 2022 at 5:06 PM Marek Szyprowski > > wrote: > >> On 17.01.2022 09:42, Jagan Teki wrote: > >>> Updated series about drm bridge conversion of exynos dsi. > >>> > >>> Previous version can be accessible, here [1]. > >>> > >>> Patch 1: connector reset > >>> > >>> Patch 2: panel_bridge API > >>> > >>> Patch 3: bridge conversion > >>> > >>> Patch 4: atomic functions > >>> > >>> Patch 5: DSI init in pre_enable > >>> > >>> Apply below patches to test on Exynos DSI: > >>> - > >>> https://protect2.fireeye.com/v1/url?k=53bdf119-0c26c815-53bc7a56-000babff3563-792dc1a6b54db43e&q=1&e=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352&u=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fpatch%2F1825%2F > >>> - > >>> https://protect2.fireeye.com/v1/url?k=cb269ea3-94bda7af-cb2715ec-000babff3563-e6f545b4a32558ba&q=1&e=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352&u=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fpatch%2F1838%2F > >>> > >>> [1] > >>> https://protect2.fireeye.com/v1/url?k=ee1dae12-b186971e-ee1c255d-000babff3563-83eaf8e86e67e0d9&q=1&e=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352&u=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fcover%2F1826%2F > >>> > >>> Any inputs? > >> I've tried a few times, but I am unable to find what is the base for > >> this patchset. I always get a conflict around exynos_dsi_mode_set() > >> function. I've tried current linux-next, drm-next, v5.16-rc1 and v5.16. > >> It looks that I must have missed applying some patch before playing with > >> this. > >> > >> I've also tried to apply only the last patch, as if I got it right, it > >> is the only difference between v4 and v5 and updated 'drm: of: Lookup if > >> child node has panel or bridge'. In such case the board freezes during > >> the drm initialization. > > Please use drm-misc/drm-misc-next with below patches and then apply this > > series. > > I don't have a good news. It doesn't work. The last patch even breaks > DSI operation: > > [4.520276] [drm] Exynos DRM: using 1380.decon device for DMA > mapping operations > [4.520578] exynos-drm exynos-drm: bound 1380.decon (ops > decon_component_ops) > [4.580473] exynos-drm exynos-drm: bound 1388.decon (ops > decon_component_ops) > [4.580726] exynos-drm exynos-drm: bound 1393.mic (ops > exynos_mic_component_ops) > [4.584304] exynos-dsi 1390.dsi: [drm:exynos_dsi_host_attach] > Attached s6e3hf2 device > [4.585141] exynos-drm exynos-drm: bound 1390.dsi (ops > exynos_dsi_component_ops) > [4.593189] rc_core: Couldn't load IR keymap rc-cec > [4.594133] Registered IR keymap rc-empty > [4.598760] rc rc0: sii8620 as /devices/virtual/rc/rc0 > [4.605219] input: sii8620 as /devices/virtual/rc/rc0/input1 > [4.610238] exynos-drm exynos-drm: bound 1397.hdmi (ops > hdmi_component_ops) > [4.920038] exynos-dsi 1390.dsi: xfer timed out: 39 03 00 00 f0 5a 5a > [5.024033] [ cut here ] > [5.024055] [CRTC:49:crtc-0] vblank wait timed out > [5.024129] WARNING: CPU: 4 PID: 151 at > drivers/gpu/drm/drm_atomic_helper.c:1530 > drm_atomic_helper_wait_for_vblanks.part.24+0x298/0x2a8 > [5.024171] Modules linked in: > [5.024195] CPU: 4 PID: 151 Comm: kworker/4:7 Not tainted 5.16.0-rc5+ > #11232 > [5.024219] Hardware name: Samsung TM2E board (DT) > [5.024232] Workqueue: events output_poll_execute > [5.024262] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS > BTYPE=--) > [5.024285] pc : drm_atomic_helper_wait_for_vblanks.part.24+0x298/0x2a8 > [5.024308] lr : drm_atomic_helper_wait_for_vblanks.part.24+0x298/0x2a8 > [5.024327] sp : 800013b5b970 > [5.024340] x29: 800013b5b970 x28: x27: > 2437e400 > [5.024391] x26: x25: x24: > 800011aa0c60 > [5.024437] x23: 0001 x22: 25113000 x21: > 0001 > [5.024482] x20: 316fc800 x19: x18: > > [5.024526] x17: 00480a11 x16: 0028 x15: > 800011b66df8 > [5.024571] x14: x13: 0a74756f2064656d x12: > 6974207469617720 > [5.024615] x11: 656820747563205b x10: 003a x9 : > 7e82f035 > [5.024661] x8 : 800011b66df8 x7 : 800013b5b740 x6 : > 0001 > [5.024704] x5 : 0001 x4 : x3 : > 0007 > [5.024747] x2 : 800012524ea0 x1 : 68a66f6a76622200 x0 : > > [5.024791] Call trace: > [5.024802] drm_atomic_helper_wait_for_vblanks.part.24+0x298/0x2a8 > [5.024825] drm_atomic_helper_commit_tail_rpm+0x60/0x78 > [5.024845] commit_tail+0x9c/0x170 > [5.024864] drm_atomic_helper_commit+0x188/0x3a0 > [5.024884] drm_atomic_commit+0x54/0x68 > [5.024906] drm_client_modeset_commit_atomic+0x260/0x288 > [5.024927] d
Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
On 2021-09-06 17:38, Uma Shankar wrote: > This is how a typical display color hardware pipeline looks like: > +---+ > |RAM| > | +--++-++-+ | > | | FB 1 || FB 2 || FB N| | > | +--++-++-+ | > +---+ >| Plane Color Hardware Block | > ++ > | +---v-+ +---v---+ +---v--+ | > | | Plane A | | Plane B | | Plane N | | > | | DeGamma | | Degamma | | Degamma | | > | +---+-+ +---+---+ +---+--+ | > | | | || > | +---v-+ +---v---+ +---v--+ | > | |Plane A | | Plane B | | Plane N | | > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > | +---+-+ ++--+ ++-+ | > | | | | | > | +---v-+ +v--+ +v-+ | > | | Plane A | | Plane B | | Plane N | | > | | Gamma | | Gamma | | Gamma| | > | +---+-+ ++--+ ++-+ | We've had a number of discussions on naming for these properties but I don't think we've arrived at a consensus. It has come up repeatedly, though, that gamma/degamma might be misleading terms. I've opened a ticket on gitlab to help track this item and would like it if we could discuss the merits of different naming schemes over there: https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/7 Uma, I tried to tag you but don't see you on gitlab.freedesktop.org. Harry > | | | | | > ++ > +--v--v---v---| > || || > || Pipe Blender|| > +++ > ||| > |+---v--+ | > || Pipe DeGamma| | > || | | > |+---+--+ | > ||Pipe Color | > |+---v--+ Hardware| > || Pipe CSC/CTM| | > || | | > |+---+--+ | > ||| > |+---v--+ | > || Pipe Gamma | | > || | | > |+---+--+ | > ||| > +-+ > | > v >Pipe Output > > This patch series adds properties for plane color features. It adds > properties for degamma used to linearize data and CSC used for gamut > conversion. It also includes Gamma support used to again non-linearize > data as per panel supported color space. These can be utilize by user > space to convert planes from one format to another, one color space to > another etc. > > Userspace can take smart blending decisions and utilize these hardware > supported plane color features to get accurate color profile. The same > can help in consistent color quality from source to panel taking > advantage of advanced color features in hardware. > > These patches add the property interfaces and enable helper functions. > This series adds Intel's XE_LPD hw specific plane gamma feature. We > can build up and add other platform/hardware specific implementation > on top of this series. > > Credits: Special mention and credits to Ville Syrjala for coming up > with a design for this feature and inputs. This series is based on > his original design and idea. > > Note: Userspace support for this new UAPI will be done on Chrome in > alignment with weston and general opensource community. > Discussion ongoing with Harry Wentland, Pekka and community on color > pipeline and UAPI design. Harry's RFC below: > https://patchwork.freedesktop.org/series/89506/ > We need to converge on a common UAPI interface which caters to > all the modern color hardware pipelines. > > ToDo: State readout for this feature will be added next. > > v2: Added UAPI description and added change in the rfc section of > kernel Documentation folder > > Uma Shankar (22): > drm: RFC for Plane Color Hardware Pipeline > drm: Add Enhanced Gamma and color lut range attributes > drm: Add Plane Degamma Mode property > drm: Add Plane Degamma Lut property > drm/i915/xelpd: Define Degamma Lut range struct for HDR planes > drm/i915/xelpd: Add register definitions for Plane Degamma > drm/i915/xelpd: Enable plane color features > drm/i915/xelpd: Add color capabilities of SDR planes > drm/i915/xelpd:
[PATCH RESEND v5 4/4] dt-bindings: drm/bridge: anx7625: Add aux-bus node
List panel under aux-bus node if it's connected to anx7625's aux bus.
Signed-off-by: Hsin-Yi Wang
---
.../display/bridge/analogix,anx7625.yaml| 17 +
1 file changed, 17 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 1d3e88daca041a..0d38d6fe39830f 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -83,6 +83,9 @@ properties:
type: boolean
description: let the driver enable audio HDMI codec function or not.
+ aux-bus:
+$ref: /schemas/display/dp-aux-bus.yaml#
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -167,5 +170,19 @@ examples:
};
};
};
+
+aux-bus {
+panel {
+compatible = "innolux,n125hce-gn1";
+power-supply = <&pp3300_disp_x>;
+backlight = <&backlight_lcd0>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <&anx7625_out>;
+};
+};
+};
+};
};
};
--
2.35.0.rc2.247.g8bbb082509-goog
[PATCH RESEND v5 3/4] drm/bridge: anx7625: Support reading edid through aux channel
Support reading edid through aux channel if panel is connected to aux
bus. Extend anx7625_aux_dpcd_trans() to implement aux transfer function:
1. panel is populated in devm_of_dp_aux_populate_ep_devices(), so move
anx7625_parse_dt() after.
2. Use pm runtime autosuspend since aux transfer function is called
multiple times when reading edid.
3. No-op if aux transfer length is 0.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Xin Ji
---
v4->v5:
fix header and indent.
v3->v4:
rebase to latest drm-misc-next
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 120 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 1 +
2 files changed, 103 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index b7e3373994b480..a59a4f4d2c5b10 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -231,19 +232,23 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
return 0;
}
-static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx, u8 op,
- u32 address, u8 len, u8 *buf)
+static int anx7625_aux_trans(struct anx7625_data *ctx, u8 op, u32 address,
+u8 len, u8 *buf)
{
struct device *dev = &ctx->client->dev;
int ret;
u8 addrh, addrm, addrl;
u8 cmd;
+ bool is_write = !(op & DP_AUX_I2C_READ);
- if (len > MAX_DPCD_BUFFER_SIZE) {
+ if (len > DP_AUX_MAX_PAYLOAD_BYTES) {
dev_err(dev, "exceed aux buffer len.\n");
return -EINVAL;
}
+ if (!len)
+ return len;
+
addrl = address & 0xFF;
addrm = (address >> 8) & 0xFF;
addrh = (address >> 16) & 0xFF;
@@ -262,7 +267,7 @@ static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx,
u8 op,
ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
AP_AUX_ADDR_19_16, addrh);
- if (op == DP_AUX_NATIVE_WRITE)
+ if (is_write)
ret |= anx7625_reg_block_write(ctx, ctx->i2c.rx_p0_client,
AP_AUX_BUFF_START, len, buf);
/* Enable aux access */
@@ -275,14 +280,14 @@ static int anx7625_aux_dpcd_trans(struct anx7625_data
*ctx, u8 op,
}
ret = wait_aux_op_finish(ctx);
- if (ret) {
+ if (ret < 0) {
dev_err(dev, "aux IO error: wait aux op finish.\n");
return ret;
}
/* Write done */
- if (op == DP_AUX_NATIVE_WRITE)
- return 0;
+ if (is_write)
+ return len;
/* Read done, read out dpcd data */
ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
@@ -292,7 +297,7 @@ static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx,
u8 op,
return -EIO;
}
- return 0;
+ return len;
}
static int anx7625_video_mute_control(struct anx7625_data *ctx,
@@ -867,7 +872,7 @@ static int anx7625_hdcp_enable(struct anx7625_data *ctx)
}
/* Read downstream capability */
- anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_READ, 0x68028, 1, &bcap);
+ anx7625_aux_trans(ctx, DP_AUX_NATIVE_READ, 0x68028, 1, &bcap);
if (!(bcap & 0x01)) {
pr_warn("downstream not support HDCP 1.4, cap(%x).\n", bcap);
return 0;
@@ -956,7 +961,7 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
dev_dbg(dev, "notify downstream enter into standby\n");
/* Downstream monitor enter into standby mode */
data = 2;
- ret |= anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1,
&data);
+ ret |= anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1, &data);
if (ret < 0)
DRM_DEV_ERROR(dev, "IO error : mute video fail\n");
@@ -1655,11 +1660,56 @@ static int anx7625_parse_dt(struct device *dev,
return 0;
}
+static bool anx7625_of_panel_on_aux_bus(struct device *dev)
+{
+ struct device_node *bus, *panel;
+
+ bus = of_get_child_by_name(dev->of_node, "aux-bus");
+ if (!bus)
+ return false;
+
+ panel = of_get_child_by_name(bus, "panel");
+ of_node_put(bus);
+ if (!panel)
+ return false;
+ of_node_put(panel);
+
+ return true;
+}
+
static inline struct anx7625_data *bridge_to_anx7625(struct drm_bridge *bridge)
{
return container_of(bridge, struct anx7625_data, bridge);
}
+static ssize_t anx7625_aux_transfer(struct drm_dp_aux *aux,
+ struct drm_dp_aux_msg *msg)
+{
+ struct anx7625_data *ctx = container_of(aux, struct anx7625_data, aux);
+ struct device *dev = &ctx->client->dev;
+ u8 request = msg->request & ~DP_AUX_I2C_MOT;
+ int ret = 0;
[PATCH RESEND v5 2/4] drm/bridge: anx7625: Convert to use devm_kzalloc
Use devm_kzalloc instead of kzalloc and drop kfree(). Let the memory
handled by driver detach.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Xin Ji
---
v2->v3: remove kfree() in anx7625_i2c_remove().
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 17b23940549a42..b7e3373994b480 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -2515,7 +2515,7 @@ static int anx7625_i2c_probe(struct i2c_client *client,
return -ENODEV;
}
- platform = kzalloc(sizeof(*platform), GFP_KERNEL);
+ platform = devm_kzalloc(dev, sizeof(*platform), GFP_KERNEL);
if (!platform) {
DRM_DEV_ERROR(dev, "fail to allocate driver data\n");
return -ENOMEM;
@@ -2527,7 +2527,7 @@ static int anx7625_i2c_probe(struct i2c_client *client,
if (ret) {
if (ret != -EPROBE_DEFER)
DRM_DEV_ERROR(dev, "fail to parse DT : %d\n", ret);
- goto free_platform;
+ return ret;
}
platform->client = client;
@@ -2552,7 +2552,7 @@ static int anx7625_i2c_probe(struct i2c_client *client,
if (!platform->hdcp_workqueue) {
dev_err(dev, "fail to create work queue\n");
ret = -ENOMEM;
- goto free_platform;
+ return ret;
}
platform->pdata.intp_irq = client->irq;
@@ -2637,9 +2637,6 @@ static int anx7625_i2c_probe(struct i2c_client *client,
if (platform->hdcp_workqueue)
destroy_workqueue(platform->hdcp_workqueue);
-free_platform:
- kfree(platform);
-
return ret;
}
@@ -2666,7 +2663,6 @@ static int anx7625_i2c_remove(struct i2c_client *client)
if (platform->pdata.audio_en)
anx7625_unregister_audio(platform);
- kfree(platform);
return 0;
}
--
2.35.0.rc2.247.g8bbb082509-goog
[PATCH RESEND v5 1/4] drm/bridge: anx7625: send DPCD command to downstream
From: Xin Ji
Send DPCD command to downstream before anx7625 power down,
let downstream monitor enter into standby mode.
Signed-off-by: Xin Ji
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Hsin-Yi Wang
---
v3->v4:
Use common DP_AUX_NATIVE_READ/WRITE
Previously in:
https://patchwork.kernel.org/project/dri-devel/patch/1f36f8bf0a48fb2bba17bacec23700e58c1d407d.1641891874.git@analogixsemi.com/
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 42 +++
drivers/gpu/drm/bridge/analogix/anx7625.h | 2 --
2 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 76662fce4ce61d..17b23940549a42 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -129,6 +129,23 @@ static int anx7625_reg_write(struct anx7625_data *ctx,
return ret;
}
+static int anx7625_reg_block_write(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u8 len, u8 *buf)
+{
+ int ret;
+ struct device *dev = &client->dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_write_i2c_block_data(client, reg_addr, len, buf);
+ if (ret < 0)
+ dev_err(dev, "write i2c block failed id=%x\n:%x",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
static int anx7625_write_or(struct anx7625_data *ctx,
struct i2c_client *client,
u8 offset, u8 mask)
@@ -214,8 +231,8 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
return 0;
}
-static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
-u32 address, u8 len, u8 *buf)
+static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx, u8 op,
+ u32 address, u8 len, u8 *buf)
{
struct device *dev = &ctx->client->dev;
int ret;
@@ -231,8 +248,7 @@ static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
addrm = (address >> 8) & 0xFF;
addrh = (address >> 16) & 0xFF;
- cmd = DPCD_CMD(len, DPCD_READ);
- cmd = ((len - 1) << 4) | 0x09;
+ cmd = DPCD_CMD(len, op);
/* Set command and length */
ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
@@ -246,6 +262,9 @@ static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
AP_AUX_ADDR_19_16, addrh);
+ if (op == DP_AUX_NATIVE_WRITE)
+ ret |= anx7625_reg_block_write(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_BUFF_START, len, buf);
/* Enable aux access */
ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
AP_AUX_CTRL_STATUS, AP_AUX_CTRL_OP_EN);
@@ -255,14 +274,17 @@ static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
return -EIO;
}
- usleep_range(2000, 2100);
-
ret = wait_aux_op_finish(ctx);
if (ret) {
dev_err(dev, "aux IO error: wait aux op finish.\n");
return ret;
}
+ /* Write done */
+ if (op == DP_AUX_NATIVE_WRITE)
+ return 0;
+
+ /* Read done, read out dpcd data */
ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
AP_AUX_BUFF_START, len, buf);
if (ret < 0) {
@@ -845,7 +867,7 @@ static int anx7625_hdcp_enable(struct anx7625_data *ctx)
}
/* Read downstream capability */
- anx7625_aux_dpcd_read(ctx, 0x68028, 1, &bcap);
+ anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_READ, 0x68028, 1, &bcap);
if (!(bcap & 0x01)) {
pr_warn("downstream not support HDCP 1.4, cap(%x).\n", bcap);
return 0;
@@ -918,6 +940,7 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
{
struct device *dev = &ctx->client->dev;
int ret;
+ u8 data;
DRM_DEV_DEBUG_DRIVER(dev, "stop dp output\n");
@@ -929,6 +952,11 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client, 0x08, 0x7f);
ret |= anx7625_video_mute_control(ctx, 1);
+
+ dev_dbg(dev, "notify downstream enter into standby\n");
+ /* Downstream monitor enter into standby mode */
+ data = 2;
+ ret |= anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1,
&data);
if (ret < 0)
DRM_DEV_ERROR(dev, "IO error : mute video fail\n");
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
b/drivers/gpu/drm/bridge/analogix/anx7625.h
index 56165f5b254c14..64a8ab56529404 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.h
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
@@ -242,8 +242,6 @@
#define AP_AUX_COMMAND 0x
Re: [PATCH 1/4] drm: Add I2C connector type
Den 02.02.2022 16.04, skrev Pekka Paalanen: > On Wed, 2 Feb 2022 10:45:42 +0100 > Noralf Trønnes wrote: > >> Den 02.02.2022 10.14, skrev Thomas Zimmermann: >>> Hi Noralf, >>> >>> since you're here, I'll just hijack the discussion to ask something only >>> semi-related. >>> >>> IIRC the gud driver doesn't update the display immediately during atomic >>> commits. Instead, it instructs a helper thread to do the update. What's >>> the rational behind this design? Is that something we should adopt for >>> other drivers that operate over slow buses (USB, I2C, etc)? Would this >>> be relevant for the ssd1307 driver? >>> >> >> Async flushing is only necessary on multi display setups where there's >> only one rendering loop for all the displays. I saw what tiny/gm12u320.c >> did and Hans gave me the rationale. The SPI drivers run flushing inline. >> Info on the gud wiki: >> https://github.com/notro/gud/wiki/Linux-Host-Driver#asynchronous-flushing > > Hi, > > please also consider that userspace may throttle to the KMS pageflip > events. If the pageflip event is immediate from submitting a flip, that > could mean userspace will be repainting in a busy-loop, like 1 kHz. > However, I remember something about virtual KMS drivers doing exactly > this, and there being something that tells userspace to throttle itself > instead of depending on pageflip completions. I just forget how that is > supposed to work, and I'm fairly sure that e.g. Weston does not behave > well there. > > Unfortunately, the pageflip event is also what synchronises FB usage. > Once flipping in a new FB completed, the old FB is free for re-use. > But, if the kernel is still copying out from the old FB, userspace may > partially overwrite the contents, temporarily leading to an incomplete > or too new image on screen. Do you have anything to prevent that? > Unfortunately not. One solution would be to make a buffer copy during the flip and do the USB transfer async but I haven't looked into that. My plan is to wait and see what problems users report back before trying to fix anything. Noralf.
Re: [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
On Wed, 02 Feb 2022, Dmitry Baryshkov wrote:
> On Wed, 2 Feb 2022 at 16:15, Jani Nikula wrote:
>>
>> On Wed, 02 Feb 2022, Laurent Pinchart
>> wrote:
>> > Hi Kandpal,
>> >
>> > Thank you for the patch.
>> >
>> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
>> >> Changing rcar_du driver to accomadate the change of
>> >> drm_writeback_connector.base and drm_writeback_connector.encoder
>> >> to a pointer the reason for which is explained in the
>> >> Patch(drm: add writeback pointers to drm_connector).
>> >>
>> >> Signed-off-by: Kandpal Suraj
>> >> ---
>> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
>> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
>> >> 2 files changed, 7 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> index 66e8839db708..68f387a04502 100644
>> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
>> >> const char *const *sources;
>> >> unsigned int sources_count;
>> >>
>> >> +struct drm_connector connector;
>> >> +struct drm_encoder encoder;
>> >
>> > Those fields are, at best, poorly named. Furthermore, there's no need in
>> > this driver or in other drivers using drm_writeback_connector to create
>> > an encoder or connector manually. Let's not polute all drivers because
>> > i915 doesn't have its abstractions right.
>>
>> i915 uses the quite common model for struct inheritance:
>>
>> struct intel_connector {
>> struct drm_connector base;
>> /* ... */
>> }
>>
>> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
>> radeon, tilcdc, and vboxvideo.
>
> For the reference. msm does not wrap drm_connector into any _common_
> structure, which is used internally.
>
>> We could argue about the relative merits of that abstraction, but I
>> think the bottom line is that it's popular and the drivers using it are
>> not going to be persuaded to move away from it.
>
> As I wrote earlier, I am not sure if these drivers would try using
> their drm_connector subclass for writeback.
> ast: ast_connector = drm_connector + respective i2c adapter for EDID,
> not needed for WB
> fsl-dcu: fsl_dcu_drm_connector = drm_connector + drm_encoder pointer +
> drm_panel. Not needed for WB
> hisilicon, mgag200: same as ast
> tilcdc: same as fsl-dcu
> vboxdrv: the only driver that may possibly benefit from using
> vbox_connector in the writeback support, as the connector is bare
> drm_connector + crtc pointer + hints (width, height, disconnected).
>
> I have left amd, nouveau and radeon out of this list, too complex to
> analyze in several minutes.
>
> I'd second the proposal of supporting optional drm_encoder for
> drm_writeback_connector (as the crtc/encoder split can be vague), but
> I do not see the benefit for the drivers to use their own
> drm_connector subclass for drm_writeback.
If a driver uses inheritance throughout the driver, and a *different*
subclass gets introduced into the mix, you need to add a ton of checks
all over the place when you cast the superclass pointer to the subclass.
The connector/encoder funcs you do have to pass to
drm_writeback_connector_init() can't use any of the shared driver
infrastructure that assume a certain inheritance.
See also my reply to Laurent [1].
> It well might be that we all misunderstand your design. Do you have a
> complete intel drm_writeback implementation based on this patchset? It
> would be easier to judge if the approach is correct seeing your
> target.
That would be up to Suraj Kandpal.
BR,
Jani.
[1] https://lore.kernel.org/r/87v8xxs2hz@intel.com
>
>>
>> It's no coincidence that the drivers who've implemented writeback so far
>> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
>> because the drm_writeback_connector midlayer does, forcing the issue.
>>
>> So I think drm_writeback_connector should *not* use the inheritance
>> abstraction because it's a midlayer that should leave that option to the
>> drivers. I think drm_writeback_connector needs to be changed to
>> accommodate that, and, unfortunately, it means current writeback users
>> need to be changed as well.
>>
>> I am not sure, however, if the series at hand is the right
>> approach. Perhaps writeback can be modified to allocate the stuff for
>> you if you prefer it that way, as long as the drm_connector is not
>> embedded in struct drm_writeback_connector.
--
Jani Nikula, Intel Open Source Graphics Center
Re: [next] arm: panel-edp.c:(.text+0xb74): undefined reference to `drm_panel_dp_aux_backlight'
Hi Am 02.02.22 um 16:37 schrieb Doug Anderson: Hi, On Wed, Feb 2, 2022 at 2:25 AM Thomas Zimmermann wrote: Hi Am 02.02.22 um 10:28 schrieb Ard Biesheuvel: On Wed, 2 Feb 2022 at 10:08, Thomas Zimmermann wrote: Hi Am 02.02.22 um 10:02 schrieb Naresh Kamboju: Following builds failed on Linux next 20220202 arm architecture. - arm-gcc-10-omap2plus_defconfig - arm-clang-nightly-shmobile_defconfig - arm-gcc-8-lpc32xx_defconfig - arm-clang-13-shmobile_defconfig - arm-gcc-10-shmobile_defconfig - arm-clang-11-shmobile_defconfig - arm-clang-11-omap2plus_defconfig - arm-clang-13-omap2plus_defconfig - arm-clang-11-lpc32xx_defconfig - arm-gcc-8-omap2plus_defconfig - arm-gcc-9-vexpress_defconfig - arm-clang-nightly-lpc32xx_defconfig - arm-gcc-9-shmobile_defconfig - arm-clang-13-lpc32xx_defconfig - arm-gcc-10-sama5_defconfig - arm-clang-11-vexpress_defconfig - arm-clang-11-sama5_defconfig - arm-gcc-9-omap2plus_defconfig - arm-clang-nightly-sama5_defconfig - arm-clang-13-vexpress_defconfig - arm-clang-nightly-vexpress_defconfig - arm-gcc-9-lpc32xx_defconfig - arm-clang-12-vexpress_defconfig - arm-gcc-10-vexpress_defconfig - arm-clang-12-shmobile_defconfig - arm-gcc-11-omap2plus_defconfig - arm-gcc-9-sama5_defconfig - arm-gcc-8-shmobile_defconfig - arm-gcc-10-lpc32xx_defconfig - arm-clang-12-omap2plus_defconfig - arm-gcc-8-vexpress_defconfig - arm-clang-12-sama5_defconfig - arm-clang-nightly-omap2plus_defconfig - arm-gcc-11-lpc32xx_defconfig - arm-gcc-11-sama5_defconfig - arm-gcc-11-shmobile_defconfig - arm-gcc-11-vexpress_defconfig - arm-gcc-8-sama5_defconfig - arm-clang-13-sama5_defconfig - arm-clang-12-lpc32xx_defconfig make --silent --keep-going --jobs=8 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 'CC=sccache arm-linux-gnueabihf-gcc' 'HOSTCC=sccache gcc' vexpress_defconfig make --silent --keep-going --jobs=8 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 'CC=sccache arm-linux-gnueabihf-gcc' 'HOSTCC=sccache gcc' arm-linux-gnueabihf-ld: drivers/gpu/drm/panel/panel-edp.o: in function `panel_edp_probe': panel-edp.c:(.text+0xb74): undefined reference to `drm_panel_dp_aux_backlight' make[1]: *** [/builds/linux/Makefile:1222: vmlinux] Error 1 Reported-by: Linux Kernel Functional Testing meta data: --- git describe: next-20220202 git_repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git target_arch: arm kconfig: vexpress_defconfig toolchain: gcc-11 Build log: - https://builds.tuxbuild.com/24XRim72vFXix6l6MdAJNENy6je/ Steps to reproduce: # To install tuxmake on your system globally: # sudo pip3 install -U tuxmake # # See https://docs.tuxmake.org/ for complete documentation. # Original tuxmake command with fragments listed below. tuxmake --runtime podman --target-arch arm --toolchain gcc-11 --kconfig vexpress_defconfig tuxmake --runtime podman --target-arch arm --toolchain gcc-11 --kconfig https://builds.tuxbuild.com/24XRim72vFXix6l6MdAJNENy6je/config You'll now need CONFIG_DRM_DP_HELPER=y in your config. That should never be the solution for linker errors such as this one. If CONFIG_DRM_PANEL_EDP relies on something provided by CONFIG_DRM_DP_HELPER, it should select it or depend on it in Kconfig. Of course, we'll provide a patch for the Kconfig files. There was discussion about this last November but I guess nothing came of it? https://lore.kernel.org/r/2027062704.14671-1-rdun...@infradead.org/ In there Arnd provided a proposed patch. If everyone likes that and it fixes things then we can apply it... Yep, apparently this was broken before. We recently moved these symbols from CONFIG_DRM_KMS_HELPER behind CONFIG_DRM_DP_HELPER. We'd have to use that instead. Best regards Thomas -Doug -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v4 00/10] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping
On Wed, Feb 02, 2022 at 03:57:50PM +0100, Christoph Hellwig wrote: > On Thu, Jan 27, 2022 at 02:32:58PM -0800, Andrew Morton wrote: > > On Wed, 26 Jan 2022 21:09:39 -0600 Alex Sierra wrote: > > > > > This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory > > > owned by a device that can be mapped into CPU page tables like > > > MEMORY_DEVICE_GENERIC and can also be migrated like > > > MEMORY_DEVICE_PRIVATE. > > > > Some more reviewer input appears to be desirable here. > > > > I was going to tentatively add it to -mm and -next, but problems. > > 5.17-rc1's mm/migrate.c:migrate_vma_check_page() is rather different > > from the tree you patched. Please redo, refresh and resend? > > I really hate adding more types with the weird one off page refcount. > We need to clean that mess up first. Is there anyone who could give an outline of what is needed to make fsdax use compound pages/folios for its PMD stuff? I already suggested removing that as a way forward, and was shot down, but nobody is standing up to maintain this code and fix it :( We got devdax and the DRM stuff fixed now, so FSDAX is the next blocker on this work. The people who want this to advance have no idea about FSs or what to do, unfortunately. Jason
Re: [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> Hi Jani,
>
> On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
>> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
>> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
>> >> Changing rcar_du driver to accomadate the change of
>> >> drm_writeback_connector.base and drm_writeback_connector.encoder
>> >> to a pointer the reason for which is explained in the
>> >> Patch(drm: add writeback pointers to drm_connector).
>> >>
>> >> Signed-off-by: Kandpal Suraj
>> >> ---
>> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
>> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
>> >> 2 files changed, 7 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> index 66e8839db708..68f387a04502 100644
>> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>> >> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
>> >> const char *const *sources;
>> >> unsigned int sources_count;
>> >>
>> >> + struct drm_connector connector;
>> >> + struct drm_encoder encoder;
>> >
>> > Those fields are, at best, poorly named. Furthermore, there's no need in
>> > this driver or in other drivers using drm_writeback_connector to create
>> > an encoder or connector manually. Let's not polute all drivers because
>> > i915 doesn't have its abstractions right.
>>
>> i915 uses the quite common model for struct inheritance:
>>
>> struct intel_connector {
>> struct drm_connector base;
>> /* ... */
>> }
>>
>> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
>> radeon, tilcdc, and vboxvideo.
>>
>> We could argue about the relative merits of that abstraction, but I
>> think the bottom line is that it's popular and the drivers using it are
>> not going to be persuaded to move away from it.
>
> Nobody said inheritance is bad.
>
>> It's no coincidence that the drivers who've implemented writeback so far
>> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
>> because the drm_writeback_connector midlayer does, forcing the issue.
>
> Are you sure it's not a coincidence ? :-)
>
> The encoder and especially connector created by drm_writeback_connector
> are there only because KMS requires a drm_encoder and a drm_connector to
> be exposed to userspace (and I could argue that using a connector for
> writeback is a hack, but that won't change). The connector is "virtual",
> I still fail to see why i915 or any other driver would need to wrap it
> into something else. The whole point of the drm_writeback_connector
> abstraction is that drivers do not have to manage the writeback
> drm_connector manually, they shouldn't touch it at all.
The thing is, drm_writeback_connector_init() calling
drm_connector_init() on the drm_connector embedded in
drm_writeback_connector leads to that connector being added to the
drm_device's list of connectors. Ditto for the encoder.
All the driver code that handles drm_connectors would need to take into
account they might not be embedded in intel_connector. Throughout the
driver. Ditto for the encoders.
The point is, you can't initialize a connector or an encoder for a
drm_device in isolation of the rest of the driver, even if it were
supposed to be hidden away.
BR,
Jani.
>
>> So I think drm_writeback_connector should *not* use the inheritance
>> abstraction because it's a midlayer that should leave that option to the
>> drivers. I think drm_writeback_connector needs to be changed to
>> accommodate that, and, unfortunately, it means current writeback users
>> need to be changed as well.
>>
>> I am not sure, however, if the series at hand is the right
>> approach. Perhaps writeback can be modified to allocate the stuff for
>> you if you prefer it that way, as long as the drm_connector is not
>> embedded in struct drm_writeback_connector.
>>
>> > Nack.
>> >
>> >> struct drm_writeback_connector writeback;
>> >> };
>> >>
>> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> >> b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> >> index c79d1259e49b..5b1e83380c47 100644
>> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
>> >> @@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device
>> >> *rcdu,
>> >> {
>> >> struct drm_writeback_connector *wb_conn = &rcrtc->writeback;
>> >>
>> >> - wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
>> >> - drm_connector_helper_add(&wb_conn->base,
>> >> + wb_conn->base = &rcrtc->connector;
>> >> + wb_conn->encoder = &rcrtc->encoder;
>> >> + wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(&rcrtc->crtc);
>> >> + drm_connector_helper_add(wb_conn->base,
>> >>&rcar_du_wb_conn_helper_funcs);
>> >>
>> >> return drm_writeback_connector_init(&rcdu->ddev, wb_conn,
>
Re: [next] arm: panel-edp.c:(.text+0xb74): undefined reference to `drm_panel_dp_aux_backlight'
Hi, On Wed, Feb 2, 2022 at 2:25 AM Thomas Zimmermann wrote: > > Hi > > Am 02.02.22 um 10:28 schrieb Ard Biesheuvel: > > On Wed, 2 Feb 2022 at 10:08, Thomas Zimmermann wrote: > >> > >> Hi > >> > >> Am 02.02.22 um 10:02 schrieb Naresh Kamboju: > >>> Following builds failed on Linux next 20220202 arm architecture. > >>> - arm-gcc-10-omap2plus_defconfig > >>> - arm-clang-nightly-shmobile_defconfig > >>> - arm-gcc-8-lpc32xx_defconfig > >>> - arm-clang-13-shmobile_defconfig > >>> - arm-gcc-10-shmobile_defconfig > >>> - arm-clang-11-shmobile_defconfig > >>> - arm-clang-11-omap2plus_defconfig > >>> - arm-clang-13-omap2plus_defconfig > >>> - arm-clang-11-lpc32xx_defconfig > >>> - arm-gcc-8-omap2plus_defconfig > >>> - arm-gcc-9-vexpress_defconfig > >>> - arm-clang-nightly-lpc32xx_defconfig > >>> - arm-gcc-9-shmobile_defconfig > >>> - arm-clang-13-lpc32xx_defconfig > >>> - arm-gcc-10-sama5_defconfig > >>> - arm-clang-11-vexpress_defconfig > >>> - arm-clang-11-sama5_defconfig > >>> - arm-gcc-9-omap2plus_defconfig > >>> - arm-clang-nightly-sama5_defconfig > >>> - arm-clang-13-vexpress_defconfig > >>> - arm-clang-nightly-vexpress_defconfig > >>> - arm-gcc-9-lpc32xx_defconfig > >>> - arm-clang-12-vexpress_defconfig > >>> - arm-gcc-10-vexpress_defconfig > >>> - arm-clang-12-shmobile_defconfig > >>> - arm-gcc-11-omap2plus_defconfig > >>> - arm-gcc-9-sama5_defconfig > >>> - arm-gcc-8-shmobile_defconfig > >>> - arm-gcc-10-lpc32xx_defconfig > >>> - arm-clang-12-omap2plus_defconfig > >>> - arm-gcc-8-vexpress_defconfig > >>> - arm-clang-12-sama5_defconfig > >>> - arm-clang-nightly-omap2plus_defconfig > >>> - arm-gcc-11-lpc32xx_defconfig > >>> - arm-gcc-11-sama5_defconfig > >>> - arm-gcc-11-shmobile_defconfig > >>> - arm-gcc-11-vexpress_defconfig > >>> - arm-gcc-8-sama5_defconfig > >>> - arm-clang-13-sama5_defconfig > >>> - arm-clang-12-lpc32xx_defconfig > >>> > >>> > >>> make --silent --keep-going --jobs=8 ARCH=arm > >>> CROSS_COMPILE=arm-linux-gnueabihf- 'CC=sccache > >>> arm-linux-gnueabihf-gcc' 'HOSTCC=sccache gcc' vexpress_defconfig > >>> make --silent --keep-going --jobs=8 ARCH=arm > >>> CROSS_COMPILE=arm-linux-gnueabihf- 'CC=sccache > >>> arm-linux-gnueabihf-gcc' 'HOSTCC=sccache gcc' > >>> arm-linux-gnueabihf-ld: drivers/gpu/drm/panel/panel-edp.o: in function > >>> `panel_edp_probe': > >>> panel-edp.c:(.text+0xb74): undefined reference to > >>> `drm_panel_dp_aux_backlight' > >>> make[1]: *** [/builds/linux/Makefile:1222: vmlinux] Error 1 > >>> > >>> > >>> Reported-by: Linux Kernel Functional Testing > >>> > >>> meta data: > >>> --- > >>> git describe: next-20220202 > >>> git_repo: > >>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > >>> target_arch: arm > >>> kconfig: vexpress_defconfig > >>> toolchain: gcc-11 > >>> > >>> Build log: > >>> - > >>> https://builds.tuxbuild.com/24XRim72vFXix6l6MdAJNENy6je/ > >>> > >>> Steps to reproduce: > >>> > >>> # To install tuxmake on your system globally: > >>> # sudo pip3 install -U tuxmake > >>> # > >>> # See https://docs.tuxmake.org/ for complete documentation. > >>> # Original tuxmake command with fragments listed below. > >>> > >>> tuxmake --runtime podman --target-arch arm --toolchain gcc-11 > >>> --kconfig vexpress_defconfig > >>> > >>> tuxmake --runtime podman --target-arch arm --toolchain gcc-11 > >>> --kconfig https://builds.tuxbuild.com/24XRim72vFXix6l6MdAJNENy6je/config > >> > >> You'll now need > >> > >> CONFIG_DRM_DP_HELPER=y > >> > >> in your config. > >> > > > > That should never be the solution for linker errors such as this one. > > > > If CONFIG_DRM_PANEL_EDP relies on something provided by > > CONFIG_DRM_DP_HELPER, it should select it or depend on it in Kconfig. > > Of course, we'll provide a patch for the Kconfig files. There was discussion about this last November but I guess nothing came of it? https://lore.kernel.org/r/2027062704.14671-1-rdun...@infradead.org/ In there Arnd provided a proposed patch. If everyone likes that and it fixes things then we can apply it... -Doug
[PATCH v2 2/2] drm/st7735r: Add SPI ID table
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by ensuring that there are SPI IDs
for all OF IDs.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown
Cc: David Lechner
---
drivers/gpu/drm/tiny/st7735r.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tiny/st7735r.c b/drivers/gpu/drm/tiny/st7735r.c
index fc40dd10efa8..713e4b286210 100644
--- a/drivers/gpu/drm/tiny/st7735r.c
+++ b/drivers/gpu/drm/tiny/st7735r.c
@@ -174,6 +174,7 @@ MODULE_DEVICE_TABLE(of, st7735r_of_match);
static const struct spi_device_id st7735r_id[] = {
{ "jd-t18003-t01", (uintptr_t)&jd_t18003_t01_cfg },
+ { "rh128128t", (uintptr_t)&rh128128t_cfg },
{ },
};
MODULE_DEVICE_TABLE(spi, st7735r_id);
--
2.30.2
[PATCH v2 0/2] drm/tiny: Ensure DT compatibles have SPI device IDs
Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so this series adds SPI IDs where they aren't provided for a given modalias. v2: - Rebase onto v5.17-rc1. Mark Brown (2): drm/ili9486: Add SPI ID table drm/st7735r: Add SPI ID table drivers/gpu/drm/tiny/ili9486.c | 2 ++ drivers/gpu/drm/tiny/st7735r.c | 1 + 2 files changed, 3 insertions(+) base-commit: e783362eb54cd99b2cac8b3a9aeac942e6f6ac07 -- 2.30.2
[PATCH v2 1/2] drm/ili9486: Add SPI ID table
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by ensuring that there are SPI IDs
for all OF IDs.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown
Cc: Kamlesh Gurudasani
---
drivers/gpu/drm/tiny/ili9486.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index e9a63f4b2993..da4dc48db030 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -182,6 +182,8 @@ MODULE_DEVICE_TABLE(of, ili9486_of_match);
static const struct spi_device_id ili9486_id[] = {
{ "ili9486", 0 },
+ { "rpi-lcd-35", 0 },
+ { "piscreen", 0 },
{ }
};
MODULE_DEVICE_TABLE(spi, ili9486_id);
--
2.30.2
[PATCH v2 3/3] drm/ili9486: Add SPI ID table
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by ensuring that there are SPI IDs
for all OF IDs.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown
Cc: Kamlesh Gurudasani
---
drivers/gpu/drm/tiny/ili9486.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index e9a63f4b2993..da4dc48db030 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -182,6 +182,8 @@ MODULE_DEVICE_TABLE(of, ili9486_of_match);
static const struct spi_device_id ili9486_id[] = {
{ "ili9486", 0 },
+ { "rpi-lcd-35", 0 },
+ { "piscreen", 0 },
{ }
};
MODULE_DEVICE_TABLE(spi, ili9486_id);
--
2.30.2
[PATCH v2 2/3] drm/panel-novotek-nt39016: Add SPI ID table
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding an id_table listing the
SPI IDs for everything.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown
---
drivers/gpu/drm/panel/panel-novatek-nt39016.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
index d036853db865..fa6ffa7fd96e 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt39016.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt39016.c
@@ -346,6 +346,13 @@ static const struct of_device_id nt39016_of_match[] = {
};
MODULE_DEVICE_TABLE(of, nt39016_of_match);
+static const struct spi_device_id nt39016_spi_ids[] = {
+ { .name = "kd035g6-54nt", .driver_data = (uintptr_t)&kd035g6_info },
+ { .name = "nt39016", .driver_data = 0 },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(spi, nt39016_spi_ids);
+
static struct spi_driver nt39016_driver = {
.driver = {
.name = "nt39016",
@@ -353,6 +360,7 @@ static struct spi_driver nt39016_driver = {
},
.probe = nt39016_probe,
.remove = nt39016_remove,
+ .id_table = nt39016_spi_ids,
};
module_spi_driver(nt39016_driver);
--
2.30.2
[PATCH v2 1/3] drm/panel-ilitek-il9322: Add SPI ID table
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding an id_table listing the
SPI IDs for everything.
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown
---
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index 8e84df9a0033..c7a980fd6406 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -935,6 +935,19 @@ static const struct of_device_id ili9322_of_match[] = {
};
MODULE_DEVICE_TABLE(of, ili9322_of_match);
+static const struct spi_device_id ili9322_spi_ids[] = {
+ {
+ .name = "dir-685-panel",
+ .driver_data = (kernel_ulong_t)&ili9322_dir_685,
+ },
+ {
+ .name = "ili9322",
+ .driver_data = 0,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(spi, ili9322_spi_ids);
+
static struct spi_driver ili9322_driver = {
.probe = ili9322_probe,
.remove = ili9322_remove,
@@ -942,6 +955,7 @@ static struct spi_driver ili9322_driver = {
.name = "panel-ilitek-ili9322",
.of_match_table = ili9322_of_match,
},
+ .id_table = ili9322_spi_ids,
};
module_spi_driver(ili9322_driver);
--
2.30.2
[PATCH v2 0/3] drm/panel: Ensure DT compatibles have SPI device IDs
Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so this series adds SPI IDs where they aren't provided for a given modalias. v2: - Rebase onto v5.17-rc1. Mark Brown (3): drm/panel-ilitek-il9322: Add SPI ID table drm/panel-novotek-nt39016: Add SPI ID table drm/ili9486: Add SPI ID table drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 14 ++ drivers/gpu/drm/panel/panel-novatek-nt39016.c | 8 drivers/gpu/drm/tiny/ili9486.c| 2 ++ 3 files changed, 24 insertions(+) base-commit: e783362eb54cd99b2cac8b3a9aeac942e6f6ac07 -- 2.30.2
Re: [PATCH v4] phy: dphy: Correct clk_pre parameter
On 24-01-22, 10:40, Liu Ying wrote: > The D-PHY specification (v1.2) explicitly mentions that the T-CLK-PRE > parameter's unit is Unit Interval(UI) and the minimum value is 8. Also, > kernel doc of the 'clk_pre' member of struct phy_configure_opts_mipi_dphy > mentions that it should be in UI. However, the dphy core driver wrongly > sets 'clk_pre' to 8000, which seems to hint that it's in picoseconds. > > So, let's fix the dphy core driver to correctly reflect the T-CLK-PRE > parameter's minimum value according to the D-PHY specification. > > I'm assuming that all impacted custom drivers shall program values in > TxByteClkHS cycles into hardware for the T-CLK-PRE parameter. The D-PHY > specification mentions that the frequency of TxByteClkHS is exactly 1/8 > the High-Speed(HS) bit rate(each HS bit consumes one UI). So, relevant > custom driver code is changed to program those values as > DIV_ROUND_UP(cfg->clk_pre, BITS_PER_BYTE), then. > > Note that I've only tested the patch with RM67191 DSI panel on i.MX8mq EVK. > Help is needed to test with other i.MX8mq, Meson and Rockchip platforms, > as I don't have the hardwares. Applied, thanks -- ~Vinod
Re: [PATCH 1/4] drm: Add I2C connector type
On Wed, 2 Feb 2022 10:45:42 +0100 Noralf Trønnes wrote: > Den 02.02.2022 10.14, skrev Thomas Zimmermann: > > Hi Noralf, > > > > since you're here, I'll just hijack the discussion to ask something only > > semi-related. > > > > IIRC the gud driver doesn't update the display immediately during atomic > > commits. Instead, it instructs a helper thread to do the update. What's > > the rational behind this design? Is that something we should adopt for > > other drivers that operate over slow buses (USB, I2C, etc)? Would this > > be relevant for the ssd1307 driver? > > > > Async flushing is only necessary on multi display setups where there's > only one rendering loop for all the displays. I saw what tiny/gm12u320.c > did and Hans gave me the rationale. The SPI drivers run flushing inline. > Info on the gud wiki: > https://github.com/notro/gud/wiki/Linux-Host-Driver#asynchronous-flushing Hi, please also consider that userspace may throttle to the KMS pageflip events. If the pageflip event is immediate from submitting a flip, that could mean userspace will be repainting in a busy-loop, like 1 kHz. However, I remember something about virtual KMS drivers doing exactly this, and there being something that tells userspace to throttle itself instead of depending on pageflip completions. I just forget how that is supposed to work, and I'm fairly sure that e.g. Weston does not behave well there. Unfortunately, the pageflip event is also what synchronises FB usage. Once flipping in a new FB completed, the old FB is free for re-use. But, if the kernel is still copying out from the old FB, userspace may partially overwrite the contents, temporarily leading to an incomplete or too new image on screen. Do you have anything to prevent that? Thanks, pq pgpHZXCeS8cF2.pgp Description: OpenPGP digital signature
Re: [PATCH v4 0/3] Fix regression introduced by disabling accelerated scrolling in fbcon
On Wed, Feb 02, 2022 at 02:55:28PM +0100, Helge Deller wrote: > This series reverts two patches which disabled scrolling acceleration in > fbcon/fbdev. Those patches introduced a regression for fbdev-supported graphic > cards because of the performance penalty by doing screen scrolling by software > instead of using existing 2D hardware acceleration. > > The third patch introduces a new config option > CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION, which -if enabled- switches > fbcon to utilize the bitblt and fillrect hardware acceleration in the > framebuffer console. If disabled, such acceleration will not be used, even if > it is supported by the graphics hardware driver. > > This series is being discussed on linux-fbdev and dri-devel mailing lists. > > Updates in v3: > - respin with fixes to build rotation code > > Updates in v4: > - changed the Kconfig option and Kconfig help text > > Helge Deller (3): > Revert "fbdev: Garbage collect fbdev scrolling acceleration, part 1 > (from TODO list)" > Revert "fbcon: Disable accelerated scrolling" > fbcon: Add option to enable legacy hardware acceleration Applied to drm-misc-fixes, thanks for the patches. Cheers, Daniel > > Documentation/gpu/todo.rst | 24 - > drivers/video/console/Kconfig | 20 + > drivers/video/fbdev/core/bitblit.c | 16 + > drivers/video/fbdev/core/fbcon.c| 557 +++- > drivers/video/fbdev/core/fbcon.h| 72 +++ > drivers/video/fbdev/core/fbcon_ccw.c| 28 +- > drivers/video/fbdev/core/fbcon_cw.c | 28 +- > drivers/video/fbdev/core/fbcon_rotate.h | 9 + > drivers/video/fbdev/core/fbcon_ud.c | 37 +- > drivers/video/fbdev/core/tileblit.c | 16 + > drivers/video/fbdev/skeletonfb.c| 12 +- > include/linux/fb.h | 2 +- > 12 files changed, 753 insertions(+), 68 deletions(-) > > -- > 2.34.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v10 2/6] dt-bindings: gpio: logicvc: Add a compatible with major version only
On 2022-01-30 00:46, Linus Walleij wrote: On Thu, Jan 20, 2022 at 4:00 PM Paul Kocialkowski wrote: There are lots of different versions of the logicvc block and it makes little sense to list them all in compatibles since all versions with the same major are found to be register-compatible. The reason we try to be precise is because sometime, long after the driver has been merged and maintained for a few years, a bug is discovered in a specific version of the silicon. What happens is that a fix is applied on all silicon whether it is needed or not. If you have the precise silicon compatible, you can avoid this and target only a specific version. Indeed, the better approach would be something like: compatible: oneOf: - items: - enum: - foo,bar-v1.0 - foo,bar,v1.1 - const: foo,bar-v1 - items: - enum: - foo,bar-v2.0 - const: foo,bar-v2 That way the DTs are future-proof, while drivers can still match on only the less-specific strings until a need arises. Plus it avoids the problem that if an existing OS that only understands "foo,bar-v1.0" is given a new DT with only "foo,bar-v1" for v1.0 hardware it won't be able to use the device, even though it's *functionally* capable of doing so. However, from skimming patch #5, it looks possible that none of these changes are needed at all. If LOGICVC_IP_VERSION_REG tells you the exact revision, and is always present (as the unconditional reading of it implies), then the only reason for adding new compatibles would be if, say, v5 has more clocks from v4 and you want the binding to enforce that; otherwise, newer versions are literally compatible with the currently-defined binding and therefore should continue to bind against the existing string(s) to maximise forward- and backward-compatibility. Sure, it's not the prettiest thing for a "generic" compatible to be based on an oddly-specific version number that doesn't necessarily match the actual software-discoverable version, but what's done is done and that's the cost of ABI. Cheers, Robin. (also, nitpick for that part of patch #5 since I'm here: please include linux/bitfield.h rather than reinventing FIELD_GET() locally)
Re: [PATCH v2] dma-buf-map: Rename to iosys-map
Hello Lucas, On Wed, 2 Feb 2022 at 15:08, Lucas De Marchi wrote: > > On Wed, Feb 02, 2022 at 10:25:28AM +0100, Christian König wrote: > >Am 02.02.22 um 10:11 schrieb Lucas De Marchi: > >>[SNIP] > >>diff --git a/MAINTAINERS b/MAINTAINERS > >>index d03ad8da1f36..112676f11792 100644 > >>--- a/MAINTAINERS > >>+++ b/MAINTAINERS > >>@@ -5675,7 +5675,6 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > >> F: Documentation/driver-api/dma-buf.rst > >> F: drivers/dma-buf/ > >> F: include/linux/*fence.h > > > >Oh, that is not correct to begin with. > > right, include/linux/dma-fence* > > > > >>-F: include/linux/dma-buf* > > > >That here should probably be changed to point directly to > >include/linux/dma-buf.h, but that can come later on. > > thanks for catching that. I will change it on next version and add your > (and any additional) ack. > > Lucas De Marchi > > > > >Feel free to add an Acked-by: Christian König > > to the patch. > > > >If nobody objects I'm going to push it drm-misc-next and provide a > >follow up to cleanup the MAINTAINERS file a bit more. Thank you for the patch; apologies for not being able to respond earlier (was out due to covid, just getting back slowly). With Christian's suggestions, looks good to me as well - feel free to add an Acked-by: Sumit Semwal to the same. > > > >Regards, > >Christian. Best, Sumit. > > > >> F: include/linux/dma-resv.h > >> K: \bdma_(?:buf|fence|resv)\b > >>@@ -9976,6 +9975,13 @@ F: include/linux/iova.h > >> F: include/linux/of_iommu.h > >> F: include/uapi/linux/iommu.h > >>+IOSYS-MAP HELPERS > >>+M: Thomas Zimmermann > >>+L: dri-devel@lists.freedesktop.org > >>+S: Maintained > >>+T: git git://anongit.freedesktop.org/drm/drm-misc > >>+F: include/linux/iosys-map.h > >>+ > >
[PATCH v4 3/3] fbcon: Add option to enable legacy hardware acceleration
Add a config option CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION to
enable bitblt and fillrect hardware acceleration in the framebuffer
console. If disabled, such acceleration will not be used, even if it is
supported by the graphics hardware driver.
If you plan to use DRM as your main graphics output system, you should
disable this option since it will prevent compiling in code which isn't
used later on when DRM takes over.
For all other configurations, e.g. if none of your graphic cards support
DRM (yet), DRM isn't available for your architecture, or you can't be
sure that the graphic card in the target system will support DRM, you
most likely want to enable this option.
In the non-accelerated case (e.g. when DRM is used), the inlined
fb_scrollmode() function is hardcoded to return SCROLL_REDRAW and as such the
compiler is able to optimize much unneccesary code away.
In this v3 patch version I additionally changed the GETVYRES() and GETVXRES()
macros to take a pointer to the fbcon_display struct. This fixes the build when
console rotation is enabled and helps the compiler again to optimize out code.
Signed-off-by: Helge Deller
Cc: sta...@vger.kernel.org # v5.10+
Signed-off-by: Helge Deller
---
drivers/video/console/Kconfig | 20 +
drivers/video/fbdev/core/fbcon.c| 39 ++---
drivers/video/fbdev/core/fbcon.h| 15 +-
drivers/video/fbdev/core/fbcon_ccw.c| 10 +++
drivers/video/fbdev/core/fbcon_cw.c | 10 +++
drivers/video/fbdev/core/fbcon_rotate.h | 4 +--
drivers/video/fbdev/core/fbcon_ud.c | 20 ++---
7 files changed, 84 insertions(+), 34 deletions(-)
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 840d9813b0bc..fcc46380e7c9 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -78,6 +78,26 @@ config FRAMEBUFFER_CONSOLE
help
Low-level framebuffer-based console driver.
+config FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+ bool "Enable legacy fbcon hardware acceleration code"
+ depends on FRAMEBUFFER_CONSOLE
+ default y if PARISC
+ default n
+ help
+ This option enables the fbcon (framebuffer text-based) hardware
+ acceleration for graphics drivers which were written for the fbdev
+ graphics interface.
+
+ On modern machines, on mainstream machines (like x86-64) or when
+ using a modern Linux distribution those fbdev drivers usually aren't
used.
+ So enabling this option wouldn't have any effect, which is why you
want
+ to disable this option on such newer machines.
+
+ If you compile this kernel for older machines which still require the
+ fbdev drivers, you may want to say Y.
+
+ If unsure, select n.
+
config FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
bool "Map the console to the primary display device"
depends on FRAMEBUFFER_CONSOLE
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index b813985f1403..f7b7d35953e8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1136,11 +1136,13 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
if ((cap & FBINFO_HWACCEL_COPYAREA) &&
!(cap & FBINFO_HWACCEL_DISABLED))
p->scrollmode = SCROLL_MOVE;
else /* default to something safe */
p->scrollmode = SCROLL_REDRAW;
+#endif
/*
* ++guenther: console.c:vc_allocate() relies on initializing
@@ -1705,7 +1707,7 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int
t, unsigned int b,
count = vc->vc_rows;
if (logo_shown >= 0)
goto redraw_up;
- switch (p->scrollmode) {
+ switch (fb_scrollmode(p)) {
case SCROLL_MOVE:
fbcon_redraw_blit(vc, info, p, t, b - t - count,
count);
@@ -1795,7 +1797,7 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int
t, unsigned int b,
count = vc->vc_rows;
if (logo_shown >= 0)
goto redraw_down;
- switch (p->scrollmode) {
+ switch (fb_scrollmode(p)) {
case SCROLL_MOVE:
fbcon_redraw_blit(vc, info, p, b - 1, b - t - count,
-count);
@@ -1946,12 +1948,12 @@ static void fbcon_bmove_rec(struct vc_data *vc, struct
fbcon_display *p, int sy,
height, width);
}
-static void updatescrollmode(struct fbcon_display *p,
+static void updatescrollmode_accel(struct fbcon_display *p,
struct fb_info *info,
struct vc_data *vc)
{
+#ifdef CONFIG_FRAMEBU
[PATCH v4 2/3] Revert "fbcon: Disable accelerated scrolling"
This reverts commit 39aead8373b3c20bb5965c024dfb51a94e526151. Revert the first (of 2) commits which disabled scrolling acceleration in fbcon/fbdev. It introduced a regression for fbdev-supported graphic cards because of the performance penalty by doing screen scrolling by software instead of using the existing graphic card 2D hardware acceleration. Console scrolling acceleration was disabled by dropping code which checked at runtime the driver hardware capabilities for the BINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags and if set, it enabled scrollmode SCROLL_MOVE which uses hardware acceleration to move screen contents. After dropping those checks scrollmode was hard-wired to SCROLL_REDRAW instead, which forces all graphic cards to redraw every character at the new screen position when scrolling. This change effectively disabled all hardware-based scrolling acceleration for ALL drivers, because now all kind of 2D hardware acceleration (bitblt, fillrect) in the drivers isn't used any longer. The original commit message mentions that only 3 DRM drivers (nouveau, omapdrm and gma500) used hardware acceleration in the past and thus code for checking and using scrolling acceleration is obsolete. This statement is NOT TRUE, because beside the DRM drivers there are around 35 other fbdev drivers which depend on fbdev/fbcon and still provide hardware acceleration for fbdev/fbcon. The original commit message also states that syzbot found lots of bugs in fbcon and thus it's "often the solution to just delete code and remove features". This is true, and the bugs - which actually affected all users of fbcon, including DRM - were fixed, or code was dropped like e.g. the support for software scrollback in vgacon (commit 973c096f6a85). So to further analyze which bugs were found by syzbot, I've looked through all patches in drivers/video which were tagged with syzbot or syzkaller back to year 2005. The vast majority fixed the reported issues on a higher level, e.g. when screen is to be resized, or when font size is to be changed. The few ones which touched driver code fixed a real driver bug, e.g. by adding a check. But NONE of those patches touched code of either the SCROLL_MOVE or the SCROLL_REDRAW case. That means, there was no real reason why SCROLL_MOVE had to be ripped-out and just SCROLL_REDRAW had to be used instead. The only reason I can imagine so far was that SCROLL_MOVE wasn't used by DRM and as such it was assumed that it could go away. That argument completely missed the fact that SCROLL_MOVE is still heavily used by fbdev (non-DRM) drivers. Some people mention that using memcpy() instead of the hardware acceleration is pretty much the same speed. But that's not true, at least not for older graphic cards and machines where we see speed decreases by factor 10 and more and thus this change leads to console responsiveness way worse than before. That's why the original commit is to be reverted. By reverting we reintroduce hardware-based scrolling acceleration and fix the performance regression for fbdev drivers. There isn't any impact on DRM when reverting those patches. Signed-off-by: Helge Deller Acked-by: Geert Uytterhoeven Acked-by: Sven Schnelle Cc: sta...@vger.kernel.org # v5.10+ Signed-off-by: Helge Deller --- Documentation/gpu/todo.rst | 21 --- drivers/video/fbdev/core/fbcon.c | 45 ++-- 2 files changed, 37 insertions(+), 29 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 29506815d24a..a1212b5b3026 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -300,27 +300,6 @@ Contact: Daniel Vetter, Noralf Tronnes Level: Advanced -Garbage collect fbdev scrolling acceleration - - -Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode = -SCROLL_REDRAW. There's a ton of code this will allow us to remove: - -- lots of code in fbcon.c - -- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called - directly instead of the function table (with a switch on p->rotate) - -- fb_copyarea is unused after this, and can be deleted from all drivers - -Note that not all acceleration code can be deleted, since clearing and cursor -support is still accelerated, which might be good candidates for further -deletion projects. - -Contact: Daniel Vetter - -Level: Intermediate - idr_init_base() --- diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 22bb3892f6bd..b813985f1403 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -1025,7 +1025,7 @@ static void fbcon_init(struct vc_data *vc, int init) struct vc_data *svc = *default_mode; struct fbcon_display *t, *p = &fb_display[vc->vc_num]; int logo = 1, new_rows, new_cols, rows, cols; - int ret; + int cap, ret; if (WARN_ON(info_idx == -1))
