Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
On 4/18/21 9:27 PM, Alice Guo (OSS) wrote:
> From: Alice Guo
>
> Update all the code that use soc_device_match because add support for
> soc_device_match returning -EPROBE_DEFER.
>
> Signed-off-by: Alice Guo
> ---
[ ... ]
> drivers/watchdog/renesas_wdt.c| 2 +-
> 48 files changed, 131 insertions(+), 52 deletions(-)
>
[ ... ]
> diff --git a/drivers/watchdog/renesas_wdt.c b/drivers/watchdog/renesas_wdt.c
> index 5791198960e6..fdc534dc4024 100644
> --- a/drivers/watchdog/renesas_wdt.c
> +++ b/drivers/watchdog/renesas_wdt.c
> @@ -197,7 +197,7 @@ static bool rwdt_blacklisted(struct device *dev)
> const struct soc_device_attribute *attr;
>
> attr = soc_device_match(rwdt_quirks_match);
> - if (attr && setup_max_cpus > (uintptr_t)attr->data) {
> + if (!IS_ERR(attr) && attr && setup_max_cpus > (uintptr_t)attr->data) {
This is wrong. We can not make the decision below without having access
to attr. The function may wrongly return false if soc_device_match()
returns an error.
Guenter
> dev_info(dev, "Watchdog blacklisted on %s %s\n", attr->soc_id,
>attr->revision);
> return true;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Fix build warnings
Fix the following build warnings.
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:
In function ‘dm_update_mst_vcpi_slots_for_dsc’:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6242:46:
warning: variable ‘old_con_state’ set but not used
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:
In function ‘amdgpu_dm_commit_cursors’:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7709:44:
warning: variable ‘new_plane_state’ set but not used
The variables were introduced to be used in iterators, but not used.
Use other iterators which don't require the unused variables.
Fixes: 8ad278062de4e ("drm/amd/display: Disable cursors before disabling
planes")
Fixes: 29b9ba74f6384 ("drm/amd/display: Recalculate VCPI slots for new DSC
connectors")
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 573cf17262da..f9b87f1f424b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6239,13 +6239,13 @@ static int dm_update_mst_vcpi_slots_for_dsc(struct
drm_atomic_state *state,
{
struct dc_stream_state *stream = NULL;
struct drm_connector *connector;
- struct drm_connector_state *new_con_state, *old_con_state;
+ struct drm_connector_state *new_con_state;
struct amdgpu_dm_connector *aconnector;
struct dm_connector_state *dm_conn_state;
int i, j, clock, bpp;
int vcpi, pbn_div, pbn = 0;
- for_each_oldnew_connector_in_state(state, connector, old_con_state,
new_con_state, i) {
+ for_each_new_connector_in_state(state, connector, new_con_state, i) {
aconnector = to_amdgpu_dm_connector(connector);
@@ -7706,15 +7706,14 @@ static void amdgpu_dm_handle_vrr_transition(struct
dm_crtc_state *old_state,
static void amdgpu_dm_commit_cursors(struct drm_atomic_state *state)
{
struct drm_plane *plane;
- struct drm_plane_state *old_plane_state, *new_plane_state;
+ struct drm_plane_state *old_plane_state;
int i;
/*
* TODO: Make this per-stream so we don't issue redundant updates for
* commits with multiple streams.
*/
- for_each_oldnew_plane_in_state(state, plane, old_plane_state,
- new_plane_state, i)
+ for_each_old_plane_in_state(state, plane, old_plane_state, i)
if (plane->type == DRM_PLANE_TYPE_CURSOR)
handle_cursor_update(plane, old_plane_state);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 11/11] drm/i915: Extract i915_module.c
On Tue, Jul 27, 2021 at 02:10:37PM +0200, Daniel Vetter wrote:
> The module init code is somewhat misplaced in i915_pci.c, since it
> needs to pull in init/exit functions from every part of the driver and
> pollutes the include list a lot.
>
> Extract an i915_module.c file which pulls all the bits together, and
> allows us to massively trim the include list of i915_pci.c.
>
> The downside is that have to drop the error path check Jason added to
> catch when we set up the pci driver too early. I think that risk is
> acceptable for this pretty nice include.
>
> Cc: Jason Ekstrand
> Cc: Tvrtko Ursulin
> Signed-off-by: Daniel Vetter
> Reviewed-by: Jason Ekstrand
With gcc and CONFIG_GCC_PLUGIN_RANDSTRUCT=y, this patch results
in:
drivers/gpu/drm/i915/i915_module.c:50:11: error:
positional initialization of field in 'struct' declared with
'designated_init' attribute
This is seen for each of the initializers.
Guenter
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/i915_module.c | 113
> drivers/gpu/drm/i915/i915_pci.c| 117 +
> drivers/gpu/drm/i915/i915_pci.h| 8 ++
> 4 files changed, 125 insertions(+), 114 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_module.c
> create mode 100644 drivers/gpu/drm/i915/i915_pci.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 9022dc638ed6..4ebd9f417ddb 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -38,6 +38,7 @@ i915-y += i915_drv.o \
> i915_irq.o \
> i915_getparam.o \
> i915_mitigations.o \
> + i915_module.o \
> i915_params.o \
> i915_pci.o \
> i915_scatterlist.o \
> diff --git a/drivers/gpu/drm/i915/i915_module.c
> b/drivers/gpu/drm/i915/i915_module.c
> new file mode 100644
> index ..c578ea8f56a0
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_module.c
> @@ -0,0 +1,113 @@
> +/*
> + * SPDX-License-Identifier: MIT
> + *
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include
> +
> +#include "gem/i915_gem_context.h"
> +#include "gem/i915_gem_object.h"
> +#include "i915_active.h"
> +#include "i915_buddy.h"
> +#include "i915_params.h"
> +#include "i915_pci.h"
> +#include "i915_perf.h"
> +#include "i915_request.h"
> +#include "i915_scheduler.h"
> +#include "i915_selftest.h"
> +#include "i915_vma.h"
> +
> +static int i915_check_nomodeset(void)
> +{
> + bool use_kms = true;
> +
> + /*
> + * Enable KMS by default, unless explicitly overriden by
> + * either the i915.modeset prarameter or by the
> + * vga_text_mode_force boot option.
> + */
> +
> + if (i915_modparams.modeset == 0)
> + use_kms = false;
> +
> + if (vgacon_text_force() && i915_modparams.modeset == -1)
> + use_kms = false;
> +
> + if (!use_kms) {
> + /* Silently fail loading to not upset userspace. */
> + DRM_DEBUG_DRIVER("KMS disabled.\n");
> + return 1;
> + }
> +
> + return 0;
> +}
> +
> +static const struct {
> + int (*init)(void);
> + void (*exit)(void);
> +} init_funcs[] = {
> + { i915_check_nomodeset, NULL },
> + { i915_active_module_init, i915_active_module_exit },
> + { i915_buddy_module_init, i915_buddy_module_exit },
> + { i915_context_module_init, i915_context_module_exit },
> + { i915_gem_context_module_init, i915_gem_context_module_exit },
> + { i915_objects_module_init, i915_objects_module_exit },
> + { i915_request_module_init, i915_request_module_exit },
> + { i915_scheduler_module_init, i915_scheduler_module_exit },
> + { i915_vma_module_init, i915_vma_module_exit },
> + { i915_mock_selftests, NULL },
> + { i915_pmu_init, i915_pmu_exit },
> + { i915_register_pci_driver, i915_unregister_pci_driver },
> + { i915_perf_sysctl_register, i915_perf_sysctl_unregister },
> +};
> +static int init_progress;
> +
> +static int __init i915_init(void)
> +{
> + int err, i;
> +
> + for (i = 0; i < ARRAY_SIZE(init_funcs); i++) {
> + err = init_funcs[i].init();
> + if (err < 0) {
> + while (i--) {
> + if (init_funcs[i].exit)
> + init_funcs[i].exit();
> + }
> + return err;
> + } else if (err > 0) {
> + /*
> + * Early-exit success is reserved for things which
> + * don't have an exit() function because we have no
> + * idea how far they got or how to partially tear
> + * them down.
> + */
> + WARN_ON(init_funcs[i].exit);
> + break;
> + }
> + }
> +
> + init_progress = i;
> +
> + return 0;
> +}
> +
> +static void __exit i915_exit(vo
Re: [PATCH v15 10/12] swiotlb: Add restricted DMA pool initialization
Hi Claire, On Thu, Jun 24, 2021 at 11:55:24PM +0800, Claire Chang wrote: > Add the initialization function to create restricted DMA pools from > matching reserved-memory nodes. > > Regardless of swiotlb setting, the restricted DMA pool is preferred if > available. > > The restricted DMA pools provide a basic level of protection against the > DMA overwriting buffer contents at unexpected times. However, to protect > against general data leakage and system memory corruption, the system > needs to provide a way to lock down the memory access, e.g., MPU. > > Signed-off-by: Claire Chang > Reviewed-by: Christoph Hellwig > Tested-by: Stefano Stabellini > Tested-by: Will Deacon > --- > include/linux/swiotlb.h | 3 +- > kernel/dma/Kconfig | 14 > kernel/dma/swiotlb.c| 76 + > 3 files changed, 92 insertions(+), 1 deletion(-) > > diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h > index 3b9454d1e498..39284ff2a6cd 100644 > --- a/include/linux/swiotlb.h > +++ b/include/linux/swiotlb.h > @@ -73,7 +73,8 @@ extern enum swiotlb_force swiotlb_force; > * range check to see if the memory was in fact allocated by this > * API. > * @nslabs: The number of IO TLB blocks (in groups of 64) between @start and > - * @end. This is command line adjustable via setup_io_tlb_npages. > + * @end. For default swiotlb, this is command line adjustable via > + * setup_io_tlb_npages. > * @used:The number of used IO TLB block. > * @list:The free list describing the number of free entries available > * from each index. > diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig > index 77b405508743..3e961dc39634 100644 > --- a/kernel/dma/Kconfig > +++ b/kernel/dma/Kconfig > @@ -80,6 +80,20 @@ config SWIOTLB > bool > select NEED_DMA_MAP_STATE > > +config DMA_RESTRICTED_POOL > + bool "DMA Restricted Pool" > + depends on OF && OF_RESERVED_MEM > + select SWIOTLB This makes SWIOTLB user configurable, which in turn results in mips64-linux-ld: arch/mips/kernel/setup.o: in function `arch_mem_init': setup.c:(.init.text+0x19c8): undefined reference to `plat_swiotlb_setup' make[1]: *** [Makefile:1280: vmlinux] Error 1 when building mips:allmodconfig. Should this possibly be "depends on SWIOTLB" ? Thanks, Guenter
Re: [PATCH v3 4/5] amba: Make the remove callback return void
On Tue, Jan 26, 2021 at 05:58:34PM +0100, Uwe Kleine-König wrote:
> All amba drivers return 0 in their remove callback. Together with the
> driver core ignoring the return value anyhow, it doesn't make sense to
> return a value here.
>
> Change the remove prototype to return void, which makes it explicit that
> returning an error value doesn't work as expected. This simplifies changing
> the core remove callback to return void, too.
>
> Reviewed-by: Ulf Hansson
> Reviewed-by: Arnd Bergmann
> Acked-by: Alexandre Belloni
> Acked-by: Dmitry Torokhov
> Acked-by: Krzysztof Kozlowski # for drivers/memory
> Acked-by: Mark Brown
> Acked-by: Dmitry Torokhov
> Acked-by: Linus Walleij
> Signed-off-by: Uwe Kleine-König
For watchdog:
Acked-by: Guenter Roeck
Guenter
> ---
> drivers/amba/bus.c | 5 ++---
> drivers/char/hw_random/nomadik-rng.c | 3 +--
> drivers/dma/pl330.c| 3 +--
> drivers/gpu/drm/pl111/pl111_drv.c | 4 +---
> drivers/hwtracing/coresight/coresight-catu.c | 3 +--
> drivers/hwtracing/coresight/coresight-cpu-debug.c | 4 +---
> drivers/hwtracing/coresight/coresight-cti-core.c | 4 +---
> drivers/hwtracing/coresight/coresight-etb10.c | 4 +---
> drivers/hwtracing/coresight/coresight-etm3x-core.c | 4 +---
> drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 +---
> drivers/hwtracing/coresight/coresight-funnel.c | 4 ++--
> drivers/hwtracing/coresight/coresight-replicator.c | 4 ++--
> drivers/hwtracing/coresight/coresight-stm.c| 4 +---
> drivers/hwtracing/coresight/coresight-tmc-core.c | 4 +---
> drivers/hwtracing/coresight/coresight-tpiu.c | 4 +---
> drivers/i2c/busses/i2c-nomadik.c | 4 +---
> drivers/input/serio/ambakmi.c | 3 +--
> drivers/memory/pl172.c | 4 +---
> drivers/memory/pl353-smc.c | 4 +---
> drivers/mmc/host/mmci.c| 4 +---
> drivers/rtc/rtc-pl030.c| 4 +---
> drivers/rtc/rtc-pl031.c| 4 +---
> drivers/spi/spi-pl022.c| 5 ++---
> drivers/tty/serial/amba-pl010.c| 4 +---
> drivers/tty/serial/amba-pl011.c| 3 +--
> drivers/vfio/platform/vfio_amba.c | 3 +--
> drivers/video/fbdev/amba-clcd.c| 4 +---
> drivers/watchdog/sp805_wdt.c | 4 +---
> include/linux/amba/bus.h | 2 +-
> sound/arm/aaci.c | 4 +---
> 30 files changed, 34 insertions(+), 80 deletions(-)
>
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index 8c4a42df47c6..48b5d4b4e889 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -300,11 +300,10 @@ static int amba_remove(struct device *dev)
> {
> struct amba_device *pcdev = to_amba_device(dev);
> struct amba_driver *drv = to_amba_driver(dev->driver);
> - int ret = 0;
>
> pm_runtime_get_sync(dev);
> if (drv->remove)
> - ret = drv->remove(pcdev);
> + drv->remove(pcdev);
> pm_runtime_put_noidle(dev);
>
> /* Undo the runtime PM settings in amba_probe() */
> @@ -315,7 +314,7 @@ static int amba_remove(struct device *dev)
> amba_put_disable_pclk(pcdev);
> dev_pm_domain_detach(dev, true);
>
> - return ret;
> + return 0;
> }
>
> static void amba_shutdown(struct device *dev)
> diff --git a/drivers/char/hw_random/nomadik-rng.c
> b/drivers/char/hw_random/nomadik-rng.c
> index b0ded41eb865..67947a19aa22 100644
> --- a/drivers/char/hw_random/nomadik-rng.c
> +++ b/drivers/char/hw_random/nomadik-rng.c
> @@ -69,11 +69,10 @@ static int nmk_rng_probe(struct amba_device *dev, const
> struct amba_id *id)
> return ret;
> }
>
> -static int nmk_rng_remove(struct amba_device *dev)
> +static void nmk_rng_remove(struct amba_device *dev)
> {
> amba_release_regions(dev);
> clk_disable(rng_clk);
> - return 0;
> }
>
> static const struct amba_id nmk_rng_ids[] = {
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index bc0f66af0f11..fd8d2bc3be9f 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -3195,7 +3195,7 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> return ret;
> }
>
> -static int pl330_remove(struct amba_device *adev)
> +static void pl330_remove(struct amba_device *adev)
> {
> struct pl330_dmac *pl330 = amba_get_drvdata(adev);
> struct
Re: [PATCH] drm/msm: remove unneeded variable: "rc"
On Tue, Feb 2, 2021 at 4:32 AM Bernard Zhao wrote:
>
> remove unneeded variable: "rc".
>
> Signed-off-by: Bernard Zhao
Reviewed-by: Guenter Roeck
>
> ---
> drivers/gpu/drm/msm/dp/dp_panel.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c
> b/drivers/gpu/drm/msm/dp/dp_panel.c
> index d1780bcac8cc..9cc816663668 100644
> --- a/drivers/gpu/drm/msm/dp/dp_panel.c
> +++ b/drivers/gpu/drm/msm/dp/dp_panel.c
> @@ -409,7 +409,6 @@ int dp_panel_timing_cfg(struct dp_panel *dp_panel)
>
> int dp_panel_init_panel_info(struct dp_panel *dp_panel)
> {
> - int rc = 0;
> struct drm_display_mode *drm_mode;
>
> drm_mode = &dp_panel->dp_mode.drm_mode;
> @@ -436,7 +435,7 @@ int dp_panel_init_panel_info(struct dp_panel *dp_panel)
> min_t(u32, dp_panel->dp_mode.bpp,
> 30));
> DRM_DEBUG_DP("updated bpp = %d\n", dp_panel->dp_mode.bpp);
>
> - return rc;
> + return 0;
> }
>
> struct dp_panel *dp_panel_get(struct dp_panel_in *in)
> --
> 2.29.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/8] drm/mediatek: add component POSTMASK
On Tue, Feb 02, 2021 at 04:12:31PM +0800, Hsin-Yi Wang wrote:
> From: Yongqiang Niu
>
> This patch add component POSTMASK.
>
> Signed-off-by: Yongqiang Niu
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: CK Hu
> ---
[ ... ]
>
> +void mtk_postmask_config(struct device *dev, unsigned int w,
static
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> +{
> + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> +
> + mtk_ddp_write(cmdq_pkt, w << 16 | h, &priv->cmdq_reg, priv->regs,
> + DISP_POSTMASK_SIZE);
> + mtk_ddp_write(cmdq_pkt, POSTMASK_RELAY_MODE, &priv->cmdq_reg,
> + priv->regs, DISP_POSTMASK_CFG);
> +}
> +
> +void mtk_postmask_start(struct device *dev)
static
> +{
> + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> +
> + writel(POSTMASK_EN, priv->regs + DISP_POSTMASK_EN);
> +}
> +
> +void mtk_postmask_stop(struct device *dev)
static
> +{
> + struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
> +
> + writel_relaxed(0x0, priv->regs + DISP_POSTMASK_EN);
> +}
> +
> static void mtk_aal_config(struct device *dev, unsigned int w,
> unsigned int h, unsigned int vrefresh,
> unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> @@ -413,6 +445,14 @@ static const struct mtk_ddp_comp_funcs ddp_ovl = {
> .bgclr_in_off = mtk_ovl_bgclr_in_off,
> };
>
> +static const struct mtk_ddp_comp_funcs ddp_postmask = {
> + .clk_enable = mtk_ddp_clk_enable,
> + .clk_disable = mtk_ddp_clk_disable,
> + .config = mtk_postmask_config,
> + .start = mtk_postmask_start,
> + .stop = mtk_postmask_stop,
> +};
> +
> static const struct mtk_ddp_comp_funcs ddp_rdma = {
> .clk_enable = mtk_rdma_clk_enable,
> .clk_disable = mtk_rdma_clk_disable,
> @@ -448,6 +488,7 @@ static const char * const
> mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
> [MTK_DISP_MUTEX] = "mutex",
> [MTK_DISP_OD] = "od",
> [MTK_DISP_BLS] = "bls",
> + [MTK_DISP_POSTMASK] = "postmask",
> };
>
> struct mtk_ddp_comp_match {
> @@ -457,36 +498,37 @@ struct mtk_ddp_comp_match {
> };
>
> static const struct mtk_ddp_comp_match mtk_ddp_matches[DDP_COMPONENT_ID_MAX]
> = {
> - [DDP_COMPONENT_AAL0]= { MTK_DISP_AAL, 0, &ddp_aal },
> - [DDP_COMPONENT_AAL1]= { MTK_DISP_AAL, 1, &ddp_aal },
> - [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
> - [DDP_COMPONENT_CCORR] = { MTK_DISP_CCORR, 0, &ddp_ccorr },
> - [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, &ddp_color },
> - [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, &ddp_color },
> - [DDP_COMPONENT_DITHER] = { MTK_DISP_DITHER,0, &ddp_dither },
> - [DDP_COMPONENT_DPI0]= { MTK_DPI,0, &ddp_dpi },
> - [DDP_COMPONENT_DPI1]= { MTK_DPI,1, &ddp_dpi },
> - [DDP_COMPONENT_DSI0]= { MTK_DSI,0, &ddp_dsi },
> - [DDP_COMPONENT_DSI1]= { MTK_DSI,1, &ddp_dsi },
> - [DDP_COMPONENT_DSI2]= { MTK_DSI,2, &ddp_dsi },
> - [DDP_COMPONENT_DSI3]= { MTK_DSI,3, &ddp_dsi },
> - [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0, &ddp_gamma },
> - [DDP_COMPONENT_OD0] = { MTK_DISP_OD,0, &ddp_od },
> - [DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, &ddp_od },
> - [DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, &ddp_ovl },
> - [DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, &ddp_ovl },
> - [DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, &ddp_ovl },
> - [DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L,1, &ddp_ovl },
> - [DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,2, &ddp_ovl },
> - [DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
> - [DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
> - [DDP_COMPONENT_PWM2]= { MTK_DISP_PWM, 2, NULL },
> - [DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, &ddp_rdma },
> - [DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, &ddp_rdma },
> - [DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, &ddp_rdma },
> - [DDP_COMPONENT_UFOE]= { MTK_DISP_UFOE, 0, &ddp_ufoe },
> - [DDP_COMPONENT_WDMA0] = { MTK_DISP_WDMA, 0, NULL },
> - [DDP_COMPONENT_WDMA1] = { MTK_DISP_WDMA, 1, NULL },
> + [DDP_COMPONENT_AAL0]= { MTK_DISP_AAL, 0, &ddp_aal },
> + [DDP_COMPONENT_AAL1]= { MTK_DISP_AAL, 1, &ddp_aal },
> + [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
> + [DDP_COMPONENT_CCORR] = { MTK_DISP_CCORR, 0, &ddp_ccorr },
> + [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0, &ddp_color },
> + [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1, &ddp_color },
> + [DDP_COMPONENT_DITHER] = { MTK_DISP_DITHER,0, &ddp_dither
> },
>
[PATCH] fbmem: Mark proc_fb_seq_ops as __maybe_unused
With CONFIG_PROC_FS=n and -Werror, 0-day reports:
drivers/video/fbdev/core/fbmem.c:736:36: error:
'proc_fb_seq_ops' defined but not used
Mark it as __maybe_unused.
Reported-by: kernel test robot
Signed-off-by: Guenter Roeck
---
drivers/video/fbdev/core/fbmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 372b52a2befa..52c606c0f8a2 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -733,7 +733,7 @@ static int fb_seq_show(struct seq_file *m, void *v)
return 0;
}
-static const struct seq_operations proc_fb_seq_ops = {
+static const struct __maybe_unused seq_operations proc_fb_seq_ops = {
.start = fb_seq_start,
.next = fb_seq_next,
.stop = fb_seq_stop,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Declare drm_send_event_helper static
0-day reports:
drivers/gpu/drm/drm_file.c:789:6: error:
no previous prototype for 'drm_send_event_helper'
Since drm_send_event_helper() is only used locally,
declare it static to fix the problem.
Reported-by: kernel test robot
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/drm_file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 7efbccffc2ea..def5df9f19e3 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -786,8 +786,8 @@ EXPORT_SYMBOL(drm_event_cancel_free);
* The timestamp variant of dma_fence_signal is used when the caller
* sends a valid timestamp.
*/
-void drm_send_event_helper(struct drm_device *dev,
- struct drm_pending_event *e, ktime_t timestamp)
+static void drm_send_event_helper(struct drm_device *dev,
+ struct drm_pending_event *e, ktime_t
timestamp)
{
assert_spin_locked(&dev->event_lock);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbmem: Correct position of '__maybe_unused' in proc_fb_seq_ops
On Wed, May 05, 2021 at 11:28:08AM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute
> declaration must precede definition [-Wignored-attributes]
> static const struct __maybe_unused seq_operations proc_fb_seq_ops = {
> ^
> ./include/linux/compiler_attributes.h:273:56: note: expanded from macro
> '__maybe_unused'
> #define __maybe_unused __attribute__((__unused__))
> ^
> ./include/linux/seq_file.h:31:8: note: previous definition is here
> struct seq_operations {
> ^
> 1 warning generated.
>
> The attribute should not split the type 'struct seq_operations'. Move it
> before the struct keyword so that it works properly and there is no more
> warning.
>
Oops, sorry.
Reviewed-by: Guenter Roeck
Guenter
> Fixes: b9d79e4ca4ff ("fbmem: Mark proc_fb_seq_ops as __maybe_unused")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1371
> Reported-by: kernel test robot
> Signed-off-by: Nathan Chancellor
> ---
> drivers/video/fbdev/core/fbmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 52c606c0f8a2..84c484f37b4a 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -733,7 +733,7 @@ static int fb_seq_show(struct seq_file *m, void *v)
> return 0;
> }
>
> -static const struct __maybe_unused seq_operations proc_fb_seq_ops = {
> +static const __maybe_unused struct seq_operations proc_fb_seq_ops = {
> .start = fb_seq_start,
> .next = fb_seq_next,
> .stop = fb_seq_stop,
>
> base-commit: b9d79e4ca4ff23543d6b33c736ba07c1f0a9dcb1
> --
> 2.31.1.362.g311531c9de
>
Re: [git pull] drm fixes round two for 5.13-rc1
On 5/9/21 2:08 PM, Linus Torvalds wrote:
On Sun, May 9, 2021 at 11:16 AM Dave Airlie wrote:
Bit later than usual, I queued them all up on Friday then promptly
forgot to write the pull request email. This is mainly amdgpu fixes,
with some radeon/msm/fbdev and one i915 gvt fix thrown in.
Hmm. Gcc seems ok with this, but clang complains:
Yeah, sorry, that was supposed to fix a problem, not replace it with
another one. And, as you noticed, gcc didn't complain, so I didn't
realize that I created a mess (and don't ask me why I put that
__maybe_unused after 'struct' - no idea).
Guenter
drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute
declaration must precede definition [-Wignored-attributes]
static const struct __maybe_unused seq_operations proc_fb_seq_ops = {
^
but I noticed it only after I had already pushed out the pull.
I'm actually surprised that gcc accepted that horrid mess: putting
"__maybe_unused" between the "struct" and the struct name is very very
wrong.
I fixed it up after the merge due to not noticing earlier..
Maybe the drm test robots should start testing with clang too?
Linus
Re: [PATCH v2] drm: Declare drm_send_event_helper static.
On Mon, May 10, 2021 at 06:46:16PM +0530, Rajat Asthana wrote: > Declare drm_send_event_helper as static to fix sparse warning: > > > warning: symbol 'drm_send_event_helper' was not declared. > > Should it be static? > > Signed-off-by: Rajat Asthana > --- > Changes in v2: > Provide full name in Author and Signed-off. > Turns out a variant of this patch [1] has already been accepted. Guenter --- [1] https://patchwork.kernel.org/project/dri-devel/patch/20210427105503.10765-1-fmdefrance...@gmail.com/
Re: [PATCH v15 12/12] of: Add plumbing for restricted DMA pool
Hi, On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote: > If a device is not behind an IOMMU, we look up the device node and set > up the restricted DMA when the restricted-dma-pool is presented. > > Signed-off-by: Claire Chang > Tested-by: Stefano Stabellini > Tested-by: Will Deacon With this patch in place, all sparc and sparc64 qemu emulations fail to boot. Symptom is that the root file system is not found. Reverting this patch fixes the problem. Bisect log is attached. Guenter --- # bad: [fb0ca446157a86b75502c1636b0d81e642fe6bf1] Add linux-next specific files for 20210701 # good: [62fb9874f5da54fdb243003b386128037319b219] Linux 5.13 git bisect start 'HEAD' 'v5.13' # bad: [f63c4fda987a19b1194cc45cb72fd5bf968d9d90] Merge remote-tracking branch 'rdma/for-next' git bisect bad f63c4fda987a19b1194cc45cb72fd5bf968d9d90 # good: [46bb5dd1d2a63e906e374e97dfd4a5e33934b1c4] Merge remote-tracking branch 'ipsec/master' git bisect good 46bb5dd1d2a63e906e374e97dfd4a5e33934b1c4 # good: [43ba6969cfb8185353a7a6fc79070f13b9e3d6d3] Merge remote-tracking branch 'clk/clk-next' git bisect good 43ba6969cfb8185353a7a6fc79070f13b9e3d6d3 # good: [1ca5eddcf8dca1d6345471c6404e7364af0d7019] Merge remote-tracking branch 'fuse/for-next' git bisect good 1ca5eddcf8dca1d6345471c6404e7364af0d7019 # good: [8f6d7b3248705920187263a4e7147b0752ec7dcf] Merge remote-tracking branch 'pci/next' git bisect good 8f6d7b3248705920187263a4e7147b0752ec7dcf # good: [df1885a755784da3ef285f36d9230c1d090ef186] RDMA/rtrs_clt: Alloc less memory with write path fast memory registration git bisect good df1885a755784da3ef285f36d9230c1d090ef186 # good: [93d31efb58c8ad4a66bbedbc2d082df458c04e45] Merge remote-tracking branch 'cpufreq-arm/cpufreq/arm/linux-next' git bisect good 93d31efb58c8ad4a66bbedbc2d082df458c04e45 # good: [46308965ae6fdc7c25deb2e8c048510ae51bbe66] RDMA/irdma: Check contents of user-space irdma_mem_reg_req object git bisect good 46308965ae6fdc7c25deb2e8c048510ae51bbe66 # good: [6de7a1d006ea9db235492b288312838d6878385f] thermal/drivers/int340x/processor_thermal: Split enumeration and processing part git bisect good 6de7a1d006ea9db235492b288312838d6878385f # good: [081bec2577cda3d04f6559c60b6f4e2242853520] dt-bindings: of: Add restricted DMA pool git bisect good 081bec2577cda3d04f6559c60b6f4e2242853520 # good: [bf95ac0bcd69979af146852f6a617a60285ebbc1] Merge remote-tracking branch 'thermal/thermal/linux-next' git bisect good bf95ac0bcd69979af146852f6a617a60285ebbc1 # good: [3d8287544223a3d2f37981c1f9ffd94d0b5e9ffc] RDMA/core: Always release restrack object git bisect good 3d8287544223a3d2f37981c1f9ffd94d0b5e9ffc # bad: [cff1f23fad6e0bd7d671acce0d15285c709f259c] Merge remote-tracking branch 'swiotlb/linux-next' git bisect bad cff1f23fad6e0bd7d671acce0d15285c709f259c # bad: [b655006619b7bccd0dc1e055bd72de5d613e7b5c] of: Add plumbing for restricted DMA pool git bisect bad b655006619b7bccd0dc1e055bd72de5d613e7b5c # first bad commit: [b655006619b7bccd0dc1e055bd72de5d613e7b5c] of: Add plumbing for restricted DMA pool
Re: [PATCH v15 12/12] of: Add plumbing for restricted DMA pool
On 7/2/21 6:18 AM, Will Deacon wrote:
On Fri, Jul 02, 2021 at 12:39:41PM +0100, Robin Murphy wrote:
On 2021-07-02 04:08, Guenter Roeck wrote:
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
With this patch in place, all sparc and sparc64 qemu emulations
fail to boot. Symptom is that the root file system is not found.
Reverting this patch fixes the problem. Bisect log is attached.
Ah, OF_ADDRESS depends on !SPARC, so of_dma_configure_id() is presumably
returning an unexpected -ENODEV from the of_dma_set_restricted_buffer()
stub. That should probably be returning 0 instead, since either way it's not
an error condition for it to simply do nothing.
Something like below?
Yes, that does the trick.
Will
--->8
From 4d9dcb9210c1f37435b6088284e04b6b36ee8c4d Mon Sep 17 00:00:00 2001
From: Will Deacon
Date: Fri, 2 Jul 2021 14:13:28 +0100
Subject: [PATCH] of: Return success from of_dma_set_restricted_buffer() when
!OF_ADDRESS
When CONFIG_OF_ADDRESS=n, of_dma_set_restricted_buffer() returns -ENODEV
and breaks the boot for sparc[64] machines. Return 0 instead, since the
function is essentially a glorified NOP in this configuration.
Cc: Claire Chang
Cc: Konrad Rzeszutek Wilk
Reported-by: Guenter Roeck
Suggested-by: Robin Murphy
Link: https://lore.kernel.org/r/20210702030807.ga2685...@roeck-us.net
Signed-off-by: Will Deacon
Tested-by: Guenter Roeck
---
drivers/of/of_private.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 8fde97565d11..34dd548c5eac 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -173,7 +173,8 @@ static inline int of_dma_get_range(struct device_node *np,
static inline int of_dma_set_restricted_buffer(struct device *dev,
struct device_node *np)
{
- return -ENODEV;
+ /* Do nothing, successfully. */
+ return 0;
}
#endif
Re: [git pull] drm for 5.18-rc1
Hi, On Thu, Mar 24, 2022 at 12:30:02PM +1000, Dave Airlie wrote: > Hi Linus, > > This is the main drm pull request for 5.18. > > The summary changelog is below, lots of work all over, > Intel improving DG2 support, amdkfd CRIU support, msm > new hw support, and faster fbdev support. > > Conflicts: > I did a merge into your tree this morning, couple of Kconfig > clashes, drm_cache.c needs an ioport.h include to avoid a build > fail due to other header refactoring. I think you should be able > to handle it. > > External interactions: > - dma-buf-map gets renamed to iosys-map > - this adds a yes/no helper to the strings helpers, and it's used > in some other code. > - platform driver for chromeos privacy screen > > Let me know if there are any issues. > [ ... ] > fbdev: Improve performance of cfb_imageblit() As reported as reponse to the patch submission, this patch causes crashes with qemu's mainstone, z2, and collie emulations. Reverting it fixes the problem. Unable to handle kernel paging request at virtual address e090d000 [e090d000] *pgd=c0c0b811c0c0b811, *pte=c0c0b000, *ppte= Internal error: Oops: 807 [#1] ARM CPU: 0 PID: 1 Comm: swapper Not tainted 5.17.0-next-20220324 #1 Hardware name: Sharp-Collie PC is at cfb_imageblit+0x58c/0x6e0 Guenter
Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()
Hi, On Wed, Feb 23, 2022 at 08:38:03PM +0100, Thomas Zimmermann wrote: > Improve the performance of cfb_imageblit() by manually unrolling > the inner blitting loop and moving some invariants out. The compiler > failed to do this automatically. This change keeps cfb_imageblit() > in sync with sys_imagebit(). > > A microbenchmark measures the average number of CPU cycles > for cfb_imageblit() after a stabilizing period of a few minutes > (i7-4790, FullHD, simpledrm, kernel with debugging). > > cfb_imageblit(), new: 15724 cycles > cfb_imageblit(): old: 30566 cycles > > In the optimized case, cfb_imageblit() is now ~2x faster than before. > > v3: > * fix commit description (Pekka) > > Signed-off-by: Thomas Zimmermann This patch causes crashes with arm mainstone, z2, and collie emulations. Reverting it fixes the problem. collie crash log and bisect log attached. Guenter --- 8<--- cut here --- Unable to handle kernel paging request at virtual address e090d000 [e090d000] *pgd=c0c0b811c0c0b811, *pte=c0c0b000, *ppte= Internal error: Oops: 807 [#1] ARM CPU: 0 PID: 1 Comm: swapper Not tainted 5.17.0-next-20220324 #1 Hardware name: Sharp-Collie PC is at cfb_imageblit+0x58c/0x6e0 LR is at 0x5 pc : []lr : [<0005>]psr: a153 sp : e0809958 ip : e090d000 fp : e08099f4 r10: e08099c8 r9 : c0c70600 r8 : 6802 r7 : c0c6e000 r6 : r5 : e08e7000 r4 : 0280 r3 : 0020 r2 : 0003 r1 : 0002 r0 : 0002 Flags: NzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none Control: 717f Table: c0004000 DAC: 0053 Register r0 information: non-paged memory Register r1 information: non-paged memory Register r2 information: non-paged memory Register r3 information: non-paged memory Register r4 information: non-paged memory Register r5 information: 0-page vmalloc region starting at 0xe08e6000 allocated at dma_common_contiguous_remap+0x94/0xb0 Register r6 information: NULL pointer Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: non-slab/vmalloc memory Register r10 information: 2-page vmalloc region starting at 0xe0808000 allocated at kernel_clone+0x78/0x4e4 Register r11 information: 2-page vmalloc region starting at 0xe0808000 allocated at kernel_clone+0x78/0x4e4 Register r12 information: 0-page vmalloc region starting at 0xe08e6000 allocated at dma_common_contiguous_remap+0x94/0xb0 Process swapper (pid: 1, stack limit = 0x(ptrval)) Stack: (0xe0809958 to 0xe080a000) 9940: 8153 005e 9960: dfb1b424 0020 0001 0002 0003 0004 9980: dfb1b420 c067f338 e08099ab 0026 99a0: 8153 0820 007fe178 c07db82c e08099d4 003e 0820 c0e32b00 99c0: 0006 c07db82c 0001 c0da1e40 e0809a54 c0e32b00 0006 0001 99e0: 0001 c0c6e000 e0809a34 e08099f8 c040a3f8 c040e530 0006 0001 9a00: c0e61920 c0da1e78 c0e61920 e0809a54 c06ad89c c0e32b00 9a20: c0da1e00 0020 e0809acc e0809a38 c040a040 c040a26c e0809a7c 0140 9a40: 0002 0002 0001 0007 0039 0001 c0da1e00 9a60: 0004 0006 0007 0001 9a80: c06ad89c c07db82c 9aa0: e0809acc c0c0c3c0 c0e32b00 0007 0002 0720 c0409cf0 0028 9ac0: e0809afc e0809ad0 c040665c c0409cfc c0c0c3c0 c0807584 9ae0: ff60 c0c7 e0809b1c e0809b00 c0439a50 c040656c 9b00: c0c0c3c0 e0809b54 e0809b20 c043a798 c0439a24 9b20: c04095c8 c0c6ff60 c07db82c e0809b54 c0c0c3c0 c0c6ff60 9b40: ff60 e0809ba4 e0809b58 c0407254 c043a5ac e0809b7c e0809b68 9b60: c04145d8 0720 0050 c0c0c3c0 9b80: c0e32b00 c0e61920 0050 0028 c0a00df8 0028 e0809bec e0809ba8 9ba0: c0407748 c0406f04 0050 0028 0050 0001 c0a02f70 9bc0: c0c0c3c0 c0c0c624 c0a02f84 003e c0a03080 9be0: e0809c0c e0809bf0 c0438b10 c040734c c0c0c3c0 c06affbc 0001 c0a02f84 9c00: e0809c54 e0809c10 c043be28 c0438a80 003e 0001 c0779d88 9c20: 0001 c08075a8 c06affbc 0001 003e 9c40: 0001 c0a02f8c e0809c9c e0809c58 c043c6ec c043bc98 c08075a8 c077c29c 9c60: 0001 c0e32b44 c0a03a58 c067f354 c0805a24 c0a00cc8 c0805a24 9c80: c07dbabc c0e32da4 f000 e0809cb4 e0809ca0 c0405d5c c043c5d4 9ca0: c0a00dac e0809cd4 e0809cb8 c0408f48 c0405cfc c0e32b00 9cc0: c0a00ca8 c0e32b10 e0809d44 e0809cd8 c03ff9e4 c0408e70 c0779a14 9ce0: c000ea7c 0041 0140 00f0 00029e01 000b 001e 9d00: 0002 0005 0001 0003 0020 c07db82c 9d20: c0e32b00 c07dfe08 0004 000d 0
Re: [2/2] fbdev: Fix cfb_imageblit() for arbitrary image widths
On Sun, Mar 13, 2022 at 08:29:52PM +0100, Thomas Zimmermann wrote:
> Commit 0d03011894d2 ("fbdev: Improve performance of cfb_imageblit()")
> broke cfb_imageblit() for image widths that are not aligned to 8-bit
> boundaries. Fix this by handling the trailing pixels on each line
> separately. The performance improvements in the original commit do not
> regress by this change.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 0d03011894d2 ("fbdev: Improve performance of cfb_imageblit()")
> Reported-by: Marek Szyprowski
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
> Cc: Sam Ravnborg
> Tested-by: Marek Szyprowski
> Acked-by: Daniel Vetter
> Reviewed-by: Javier Martinez Canillas
Tested-by: Guenter Roeck
> ---
> drivers/video/fbdev/core/cfbimgblt.c | 28
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/cfbimgblt.c
> b/drivers/video/fbdev/core/cfbimgblt.c
> index 7361cfabdd85..9ebda4e0dc7a 100644
> --- a/drivers/video/fbdev/core/cfbimgblt.c
> +++ b/drivers/video/fbdev/core/cfbimgblt.c
> @@ -218,7 +218,7 @@ static inline void fast_imageblit(const struct fb_image
> *image, struct fb_info *
> {
> u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
> u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
> - u32 bit_mask, eorx;
> + u32 bit_mask, eorx, shift;
> const char *s = image->data, *src;
> u32 __iomem *dst;
> const u32 *tab = NULL;
> @@ -259,17 +259,23 @@ static inline void fast_imageblit(const struct fb_image
> *image, struct fb_info *
>
> for (i = image->height; i--; ) {
> dst = (u32 __iomem *)dst1;
> + shift = 8;
> src = s;
>
> + /*
> + * Manually unroll the per-line copying loop for better
> + * performance. This works until we processed the last
> + * completely filled source byte (inclusive).
> + */
> switch (ppw) {
> case 4: /* 8 bpp */
> - for (j = k; j; j -= 2, ++src) {
> + for (j = k; j >= 2; j -= 2, ++src) {
> FB_WRITEL(colortab[(*src >> 4) & bit_mask],
> dst++);
> FB_WRITEL(colortab[(*src >> 0) & bit_mask],
> dst++);
> }
> break;
> case 2: /* 16 bpp */
> - for (j = k; j; j -= 4, ++src) {
> + for (j = k; j >= 4; j -= 4, ++src) {
> FB_WRITEL(colortab[(*src >> 6) & bit_mask],
> dst++);
> FB_WRITEL(colortab[(*src >> 4) & bit_mask],
> dst++);
> FB_WRITEL(colortab[(*src >> 2) & bit_mask],
> dst++);
> @@ -277,7 +283,7 @@ static inline void fast_imageblit(const struct fb_image
> *image, struct fb_info *
> }
> break;
> case 1: /* 32 bpp */
> - for (j = k; j; j -= 8, ++src) {
> + for (j = k; j >= 8; j -= 8, ++src) {
> FB_WRITEL(colortab[(*src >> 7) & bit_mask],
> dst++);
> FB_WRITEL(colortab[(*src >> 6) & bit_mask],
> dst++);
> FB_WRITEL(colortab[(*src >> 5) & bit_mask],
> dst++);
> @@ -290,6 +296,20 @@ static inline void fast_imageblit(const struct fb_image
> *image, struct fb_info *
> break;
> }
>
> + /*
> + * For image widths that are not a multiple of 8, there
> + * are trailing pixels left on the current line. Print
> + * them as well.
> + */
> + for (; j--; ) {
> + shift -= ppw;
> + FB_WRITEL(colortab[(*src >> shift) & bit_mask], dst++);
> + if (!shift) {
> + shift = 8;
> + ++src;
> + }
> + }
> +
> dst1 += p->fix.line_length;
> s += spitch;
> }
Re: [PATCH v3 4/5] fbdev: Improve performance of cfb_imageblit()
On 3/24/22 12:18, Thomas Zimmermann wrote: Hi Am 24.03.22 um 20:11 schrieb Guenter Roeck: Hi, On Wed, Feb 23, 2022 at 08:38:03PM +0100, Thomas Zimmermann wrote: Improve the performance of cfb_imageblit() by manually unrolling the inner blitting loop and moving some invariants out. The compiler failed to do this automatically. This change keeps cfb_imageblit() in sync with sys_imagebit(). A microbenchmark measures the average number of CPU cycles for cfb_imageblit() after a stabilizing period of a few minutes (i7-4790, FullHD, simpledrm, kernel with debugging). cfb_imageblit(), new: 15724 cycles cfb_imageblit(): old: 30566 cycles In the optimized case, cfb_imageblit() is now ~2x faster than before. v3: * fix commit description (Pekka) Signed-off-by: Thomas Zimmermann This patch causes crashes with arm mainstone, z2, and collie emulations. Reverting it fixes the problem. collie crash log and bisect log attached. Does it work if you apply the fixes at https://patchwork.freedesktop.org/series/101321/ ? Yes, it does, specifically the cfb related patch. I sent a Tested-by:. Thanks, Guenter
Re: [PATCH] drm/selftest: plane_helper: Put test structures in static storage
On Wed, Mar 02, 2022 at 04:59:09PM -0700, Nathan Chancellor wrote:
> Clang warns on certain 32-bit architectures:
>
> drivers/gpu/drm/selftests/test-drm_plane_helper.c:76:5: warning: stack
> frame size (1064) exceeds limit (1024) in 'igt_check_plane_state'
> [-Wframe-larger-than]
> int igt_check_plane_state(void *ignored)
> ^
> 1 warning generated.
>
> The structures in igt_check_plane_state() total 1008 bytes, so any small
> amount of inlining will cause the stack frame to exceed the 32-bit limit
> of 1024, triggering the warning.
>
> Move these structures to static storage, which dramatically reduces the
> amount of stack space in igt_check_plane_state(). There is no testing
> impact, as igt_check_plane_state() is only called once in the driver.
>
> Fixes: 943e6a8beeac ("mock a drm_plane in igt_check_plane_state to make the
> test more robust")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1600
> Reported-by: kernel test robot
> Suggested-by: Nick Desaulniers
> Signed-off-by: Nathan Chancellor
> Reviewed-by: Nick Desaulniers
Tested-by: Guenter Roeck
Note that the offending patch is now in mainline and results in test build
failures there.
Building csky:allmodconfig ... failed
--
Error log:
drivers/gpu/drm/selftests/test-drm_plane_helper.c: In function
'igt_check_plane_state':
drivers/gpu/drm/selftests/test-drm_plane_helper.c:223:1: error: the frame size
of 1072 bytes is larger than 1024 bytes
This is with gcc 11.2.
Guenter
Re: [PATCH] device: fix missing check on list iterator
On 3/26/22 22:31, Xiaomeng Tong wrote:
The bug is here:
lo = pstate->base.domain[domain->name];
The list iterator 'pstate' will point to a bogus position containing
HEAD if the list is empty or no element is found. This case should
be checked before any use of the iterator, otherwise it will lead
to a invalid memory access.
To fix this bug, add an check. Use a new value 'iter' as the list
iterator, while use the old value 'pstate' as a dedicated variable
to point to the found element.
Cc: sta...@vger.kernel.org
Fixes: 9838366c1597d ("drm/nouveau/device: initial control object class, with pstate
control methods")
Signed-off-by: Xiaomeng Tong
---
drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
index ce774579c89d..6b768635e8ba 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
@@ -72,7 +72,7 @@ nvkm_control_mthd_pstate_attr(struct nvkm_control *ctrl, void
*data, u32 size)
} *args = data;
struct nvkm_clk *clk = ctrl->device->clk;
const struct nvkm_domain *domain;
- struct nvkm_pstate *pstate;
+ struct nvkm_pstate *pstate = NULL, *iter;
struct nvkm_cstate *cstate;
int i = 0, j = -1;
u32 lo, hi;
@@ -103,11 +103,16 @@ nvkm_control_mthd_pstate_attr(struct nvkm_control *ctrl,
void *data, u32 size)
return -EINVAL;
if (args->v0.state != NVIF_CONTROL_PSTATE_ATTR_V0_STATE_CURRENT) {
- list_for_each_entry(pstate, &clk->states, head) {
- if (i++ == args->v0.state)
+ list_for_each_entry(iter, &clk->states, head) {
+ if (i++ == args->v0.state) {
+ pstate = iter;
Is iter and the assignment really necessary ? Unless I am missing something,
list_for_each_entry() always assigns pos (pstate/iter), even if the list is
empty. If nothing is found, pstate would be NULL at the end, so
break;
+ }
}
+ if (!pstate)
+ return -EINVAL;
+
... just this check should do to cover both the "not found" and "list empty"
cases.
Thanks,
Guenter
lo = pstate->base.domain[domain->name];
hi = lo;
list_for_each_entry(cstate, &pstate->list, head) {
Re: [PATCH] device: fix missing check on list iterator
On 3/26/22 23:59, Xiaomeng Tong wrote:
On Sat, 26 Mar 2022 22:38:05 -0700, Guenter Roeck wrote:
@@ -103,11 +103,16 @@ nvkm_control_mthd_pstate_attr(struct nvkm_control *ctrl,
void *data, u32 size)
return -EINVAL;
if (args->v0.state != NVIF_CONTROL_PSTATE_ATTR_V0_STATE_CURRENT) {
- list_for_each_entry(pstate, &clk->states, head) {
- if (i++ == args->v0.state)
+ list_for_each_entry(iter, &clk->states, head) {
+ if (i++ == args->v0.state) {
+ pstate = iter;
Is iter and the assignment really necessary ? Unless I am missing something,
list_for_each_entry() always assigns pos (pstate/iter), even if the list is
empty. If nothing is found, pstate would be NULL at the end, so
the pstate will not be NULL at the end! so the assignment is necessary!
#define list_for_each_entry(pos, head, member) \
for (pos = __container_of((head)->next, pos, member); \
&pos->member != (head);\
pos = __container_of(pos->member.next, pos, member))
Uuh, yes, you are correct. Sorry for the noise.
Guenter
Re: [PATCH] drm: Fix no previous prototype error in drm_nomodeset.c
On Wed, Mar 02, 2022 at 10:39:02PM +0530, Aashish Sharma wrote: > Fix this kernel test robot error: > > drivers/gpu/drm/drm_nomodeset.c:8:6: error: > no previous prototype for 'drm_firmware_drivers_only' > > Including drm_drv.h in drm_nomodeset.c which contains > drm_firmware_drivers_only's declaration. > > Signed-off-by: Aashish Sharma Reviewed-by: Guenter Roeck > --- > drivers/gpu/drm/drm_nomodeset.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_nomodeset.c b/drivers/gpu/drm/drm_nomodeset.c > index f3978d5bd3a1..9402deb4985f 100644 > --- a/drivers/gpu/drm/drm_nomodeset.c > +++ b/drivers/gpu/drm/drm_nomodeset.c > @@ -2,6 +2,7 @@ > > #include > #include > +#include > > static bool drm_nomodeset; > > -- > 2.35.1.574.g5d30c73bfb-goog >
[PATCH] drm/nouveau/nvkm: Replace -ENOSYS with -ENODEV
nvkm test builds fail with the following error.
drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c:
In function 'nvkm_control_mthd_pstate_info':
drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c:60:35: error:
overflow in conversion from 'int' to '__s8' {aka 'signed char'}
changes value from '-251' to '5'
The code builds on most architectures, but fails on parisc where ENOSYS
is defined as 251. Replace the error code with -ENODEV (-19). The actual
error code does not really matter and is not passed to userspace - it
just has to be negative.
Fixes: 7238eca4cf18 ("drm/nouveau: expose pstate selection per-power source in
sysfs")
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
index b0ece71aefde..ce774579c89d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c
@@ -57,7 +57,7 @@ nvkm_control_mthd_pstate_info(struct nvkm_control *ctrl, void
*data, u32 size)
args->v0.count = 0;
args->v0.ustate_ac = NVIF_CONTROL_PSTATE_INFO_V0_USTATE_DISABLE;
args->v0.ustate_dc = NVIF_CONTROL_PSTATE_INFO_V0_USTATE_DISABLE;
- args->v0.pwrsrc = -ENOSYS;
+ args->v0.pwrsrc = -ENODEV;
args->v0.pstate = NVIF_CONTROL_PSTATE_INFO_V0_PSTATE_UNKNOWN;
}
--
2.33.0
Re: [PATCH] dt-bindings: More use 'enum' instead of 'oneOf' plus 'const' entries
On 9/10/21 9:51 AM, Rob Herring wrote: 'enum' is equivalent to 'oneOf' with a list of 'const' entries, but 'enum' is more concise and yields better error messages. Fix a couple more cases which have appeared. Cc: Rob Clark Cc: Sean Paul Cc: Mark Brown Cc: Wim Van Sebroeck Cc: Guenter Roeck Cc: Jonathan Marek Cc: Aswath Govindraju Cc: Marc Zyngier Cc: Linus Walleij Cc: dri-devel@lists.freedesktop.org Cc: freedr...@lists.freedesktop.org Cc: linux-...@vger.kernel.org Cc: linux-watch...@vger.kernel.org Signed-off-by: Rob Herring --- .../bindings/display/msm/dsi-phy-7nm.yaml | 8 .../devicetree/bindings/spi/omap-spi.yaml | 6 +++--- .../bindings/watchdog/maxim,max63xx.yaml | 14 +++--- For watchdog: Acked-by: Guenter Roeck 3 files changed, 14 insertions(+), 14 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml index 4265399bb154..c851770bbdf2 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml @@ -14,10 +14,10 @@ allOf: properties: compatible: -oneOf: - - const: qcom,dsi-phy-7nm - - const: qcom,dsi-phy-7nm-8150 - - const: qcom,sc7280-dsi-phy-7nm +enum: + - qcom,dsi-phy-7nm + - qcom,dsi-phy-7nm-8150 + - qcom,sc7280-dsi-phy-7nm reg: items: diff --git a/Documentation/devicetree/bindings/spi/omap-spi.yaml b/Documentation/devicetree/bindings/spi/omap-spi.yaml index e55538186cf6..9952199cae11 100644 --- a/Documentation/devicetree/bindings/spi/omap-spi.yaml +++ b/Documentation/devicetree/bindings/spi/omap-spi.yaml @@ -84,9 +84,9 @@ unevaluatedProperties: false if: properties: compatible: - oneOf: -- const: ti,omap2-mcspi -- const: ti,omap4-mcspi + enum: +- ti,omap2-mcspi +- ti,omap4-mcspi then: properties: diff --git a/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml b/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml index f2105eedac2c..ab9641e845db 100644 --- a/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml +++ b/Documentation/devicetree/bindings/watchdog/maxim,max63xx.yaml @@ -15,13 +15,13 @@ maintainers: properties: compatible: -oneOf: - - const: maxim,max6369 - - const: maxim,max6370 - - const: maxim,max6371 - - const: maxim,max6372 - - const: maxim,max6373 - - const: maxim,max6374 +enum: + - maxim,max6369 + - maxim,max6370 + - maxim,max6371 + - maxim,max6372 + - maxim,max6373 + - maxim,max6374 reg: description: This is a 1-byte memory-mapped address
Re: [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire
On Mon, Oct 18, 2021 at 06:45:03PM +0100, Matthew Auld wrote:
> As pointed out by Thomas, we likely need to flush the pages here if the
> GPU can read the page contents directly from main memory. Underneath we
> don't know what the sg_table is pointing to, so just add a
> wbinvd_on_all_cpus() here, for now.
>
> Reported-by: Thomas Hellström
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
With nosmp builds:
Error log:
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c: In function
'i915_gem_object_get_pages_dmabuf':
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:248:17: error: implicit declaration
of function 'wbinvd_on_all_cpus' [-Werror=implicit-function-declaration]
248 | wbinvd_on_all_cpus();
| ^~
Guenter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index 5be505ebbb7b..1adcd8e02d29 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -232,6 +232,7 @@ struct dma_buf *i915_gem_prime_export(struct
> drm_gem_object *gem_obj, int flags)
>
> static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
> {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct sg_table *pages;
> unsigned int sg_page_sizes;
>
> @@ -242,8 +243,11 @@ static int i915_gem_object_get_pages_dmabuf(struct
> drm_i915_gem_object *obj)
> if (IS_ERR(pages))
> return PTR_ERR(pages);
>
> - sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
> + /* XXX: consider doing a vmap flush or something */
> + if (!HAS_LLC(i915) || i915_gem_object_can_bypass_llc(obj))
> + wbinvd_on_all_cpus();
>
> + sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
> __i915_gem_object_set_pages(obj, pages, sg_page_sizes);
>
> return 0;
> --
> 2.26.3
>
Re: [PATCH] drm/amdgpu: fix out of bounds write
On Wed, Oct 13, 2021 at 04:04:13PM -0400, Thelford Williams wrote:
> Size can be any value and is user controlled resulting in overwriting the
> 40 byte array wr_buf with an arbitrary length of data from buf.
>
> Signed-off-by: Thelford Williams
> Signed-off-by: Alex Deucher
The fix works, but unless I am missing something it is incomplete.
parse_write_buffer_into_params() is called several times, and the
size parameter is always wrong. This patch only fixes one of several
instances of the problem.
Guenter
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index 814f67d86a3c..9b3ad56607bb 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -264,7 +264,7 @@ static ssize_t dp_link_settings_write(struct file *f,
> const char __user *buf,
> if (!wr_buf)
> return -ENOSPC;
>
> - if (parse_write_buffer_into_params(wr_buf, size,
> + if (parse_write_buffer_into_params(wr_buf, wr_buf_size,
> (long *)param, buf,
> max_param_num,
> ¶m_nums)) {
> --
> 2.33.0
Re: [PATCH] drm/amdgpu: fix out of bounds write
On 10/27/21 8:22 AM, Harry Wentland wrote:
On 2021-10-27 10:39, Guenter Roeck wrote:
On Wed, Oct 13, 2021 at 04:04:13PM -0400, Thelford Williams wrote:
Size can be any value and is user controlled resulting in overwriting the
40 byte array wr_buf with an arbitrary length of data from buf.
Signed-off-by: Thelford Williams
Signed-off-by: Alex Deucher
The fix works, but unless I am missing something it is incomplete.
parse_write_buffer_into_params() is called several times, and the
size parameter is always wrong. This patch only fixes one of several
instances of the problem.
Patrik sent a patch that covers all cases:
https://patchwork.freedesktop.org/patch/461554/?series=96341&rev=2
Harry
Thanks!
Guenter
Guenter
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 814f67d86a3c..9b3ad56607bb 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -264,7 +264,7 @@ static ssize_t dp_link_settings_write(struct file *f, const
char __user *buf,
if (!wr_buf)
return -ENOSPC;
- if (parse_write_buffer_into_params(wr_buf, size,
+ if (parse_write_buffer_into_params(wr_buf, wr_buf_size,
(long *)param, buf,
max_param_num,
¶m_nums)) {
--
2.33.0
Re: [PATCH] drm/bridge: anx7625: Fix edid_read break case in sp_tx_edid_read()
On Fri, Nov 12, 2021 at 07:24:33PM +0800, Hsin-Yi Wang wrote:
> edid_read() was assumed to return 0 on success. After
> 7f16d0f3b8e2("drm/bridge: anx7625: Propagate errors from sp_tx_rst_aux()"),
> the function can return >= 0 for successful case. Fix the g_edid_break
> condition in sp_tx_edid_read().
>
> Fixes: 7f16d0f3b8e2("drm/bridge: anx7625: Propagate errors from
> sp_tx_rst_aux()")
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Robert Foss
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 1a871f6b6822ee..392203b576042b 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -826,7 +826,7 @@ static int sp_tx_edid_read(struct anx7625_data *ctx,
> g_edid_break = edid_read(ctx, offset,
>pblock_buf);
>
> - if (g_edid_break)
> + if (g_edid_break < 0)
> break;
g_edid_break is declared u8 and thus never < 0. The break; statement
doesn't indicate an error but that a break was encountered, and the
value of g_edid_break == 1 is used elsewhere in the function to indicate
that condition. It also doesn't break out of the outer loop, but only
out of the switch statement.
With this patch in place, g_edid_break will have a more or less random
value after an error, and the behavior of this function will be undefined.
Guenter
Re: [PATCH v7 2/5] dma-buf: heaps: Move heap-helper logic into the cma_heap implementation
On Sat, Nov 21, 2020 at 11:49:59PM +, John Stultz wrote: > Since the heap-helpers logic ended up not being as generic as > hoped, move the heap-helpers dma_buf_ops implementations into > the cma_heap directly. > > This will allow us to remove the heap_helpers code in a following > patch. > mips:allmodconfig: drivers/dma-buf/heaps/cma_heap.c: In function 'cma_heap_do_vmap': drivers/dma-buf/heaps/cma_heap.c:195:10: error: implicit declaration of function 'vmap' Bisect log attached. Guenter --- # bad: [9317f948b0b188b8d2fded75957e6d42c460df1b] Add linux-next specific files for 20201215 # good: [2c85ebc57b3e1817b6ce1a6b703928e113a90442] Linux 5.10 git bisect start 'HEAD' 'v5.10' # good: [8357e709304f1791b390c34f63cd00cb434a9ea9] Merge remote-tracking branch 'pm/linux-next' git bisect good 8357e709304f1791b390c34f63cd00cb434a9ea9 # bad: [e43c4376b37c58a05fe2f512aebfc7362306] Merge remote-tracking branch 'tomoyo/master' git bisect bad e43c4376b37c58a05fe2f512aebfc7362306 # good: [6f2d5cf9756dab190e79edd4ec098c81dca6743c] net: stmmac: simplify the return dwmac5_rxp_disable() git bisect good 6f2d5cf9756dab190e79edd4ec098c81dca6743c # bad: [fef5fe5f601c5826083b81837800b8b99570bfb0] Merge remote-tracking branch 'drm-misc/for-linux-next' git bisect bad fef5fe5f601c5826083b81837800b8b99570bfb0 # good: [5bb0c4b5eb61d939fed0b27d11fb91fb85769c9a] ice, xsk: Move Rx allocation out of while-loop git bisect good 5bb0c4b5eb61d939fed0b27d11fb91fb85769c9a # good: [b54139eb968d982bfd5f451a8d143f3f6cdd82cf] Merge remote-tracking branch 'mtd/mtd/next' git bisect good b54139eb968d982bfd5f451a8d143f3f6cdd82cf # good: [f42a3d780d2ff7a122b089460f4bfbe402b4e27e] Merge remote-tracking branch 'amdgpu/drm-next' git bisect good f42a3d780d2ff7a122b089460f4bfbe402b4e27e # good: [3a9ec563a4ff770ae647f6ee539810f1866866c9] drm/i915/icl: Fix initing the DSI DSC power refcount during HW readout git bisect good 3a9ec563a4ff770ae647f6ee539810f1866866c9 # bad: [2c3a1e49696fd05b52ec5eeb7c006ac32724c915] video: fbdev: lxfb_ops: Fix fall-through warnings for Clang git bisect bad 2c3a1e49696fd05b52ec5eeb7c006ac32724c915 # good: [2ac5ef3b23629e974948c48f4141bacb5abb] drm: document drm_mode_get_connector git bisect good 2ac5ef3b23629e974948c48f4141bacb5abb # good: [2b6cb81b95d1e8abfb6d32cf194a5bd2992c315c] drm/meson: dw-hdmi: Enable the iahb clock early enough git bisect good 2b6cb81b95d1e8abfb6d32cf194a5bd2992c315c # bad: [4c68e499bb9d6d9ec3e18fcb2f68641abb22464a] dma-buf: heaps: Skip sync if not mapped git bisect bad 4c68e499bb9d6d9ec3e18fcb2f68641abb22464a # bad: [a5d2d29e24be8967ef78a1b1fb2292413e3b3df9] dma-buf: heaps: Move heap-helper logic into the cma_heap implementation git bisect bad a5d2d29e24be8967ef78a1b1fb2292413e3b3df9 # good: [3812957587923ca325308ed9c4a5be5ca935e903] dma-buf: system_heap: Rework system heap to use sgtables instead of pagelists git bisect good 3812957587923ca325308ed9c4a5be5ca935e903 # first bad commit: [a5d2d29e24be8967ef78a1b1fb2292413e3b3df9] dma-buf: heaps: Move heap-helper logic into the cma_heap implementation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 02/30] genirq: Move status flag checks to core
On Thu, Dec 10, 2020 at 08:25:38PM +0100, Thomas Gleixner wrote:
> These checks are used by modules and prevent the removal of the export of
> irq_to_desc(). Move the accessor into the core.
>
> Signed-off-by: Thomas Gleixner
Yes, but that means that irq_check_status_bit() may be called from modules,
but it is not exported, resulting in build errors such as the following.
arm64:allmodconfig:
ERROR: modpost: "irq_check_status_bit" [drivers/perf/arm_spe_pmu.ko] undefined!
Guenter
> ---
> include/linux/irqdesc.h | 17 +
> kernel/irq/manage.c | 17 +
> 2 files changed, 22 insertions(+), 12 deletions(-)
>
> --- a/include/linux/irqdesc.h
> +++ b/include/linux/irqdesc.h
> @@ -223,28 +223,21 @@ irq_set_chip_handler_name_locked(struct
> data->chip = chip;
> }
>
> +bool irq_check_status_bit(unsigned int irq, unsigned int bitmask);
> +
> static inline bool irq_balancing_disabled(unsigned int irq)
> {
> - struct irq_desc *desc;
> -
> - desc = irq_to_desc(irq);
> - return desc->status_use_accessors & IRQ_NO_BALANCING_MASK;
> + return irq_check_status_bit(irq, IRQ_NO_BALANCING_MASK);
> }
>
> static inline bool irq_is_percpu(unsigned int irq)
> {
> - struct irq_desc *desc;
> -
> - desc = irq_to_desc(irq);
> - return desc->status_use_accessors & IRQ_PER_CPU;
> + return irq_check_status_bit(irq, IRQ_PER_CPU);
> }
>
> static inline bool irq_is_percpu_devid(unsigned int irq)
> {
> - struct irq_desc *desc;
> -
> - desc = irq_to_desc(irq);
> - return desc->status_use_accessors & IRQ_PER_CPU_DEVID;
> + return irq_check_status_bit(irq, IRQ_PER_CPU_DEVID);
> }
>
> static inline void
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -2769,3 +2769,23 @@ bool irq_has_action(unsigned int irq)
> return res;
> }
> EXPORT_SYMBOL_GPL(irq_has_action);
> +
> +/**
> + * irq_check_status_bit - Check whether bits in the irq descriptor status
> are set
> + * @irq: The linux irq number
> + * @bitmask: The bitmask to evaluate
> + *
> + * Returns: True if one of the bits in @bitmask is set
> + */
> +bool irq_check_status_bit(unsigned int irq, unsigned int bitmask)
> +{
> + struct irq_desc *desc;
> + bool res = false;
> +
> + rcu_read_lock();
> + desc = irq_to_desc(irq);
> + if (desc)
> + res = !!(desc->status_use_accessors & bitmask);
> + rcu_read_unlock();
> + return res;
> +}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 01/32] Kconfig: introduce and depend on LEGACY_PCI
On 12/27/21 8:42 AM, Niklas Schnelle wrote: Introduce a new LEGACY_PCI Kconfig option which gates support for legacy PCI devices including those attached to a PCI-to-PCI Express bridge and PCI Express devices using legacy I/O spaces. Note that this is different from non PCI uses of I/O ports such as by ACPI. Add dependencies on LEGACY_PCI for all PCI drivers which only target legacy PCI devices and ifdef legacy PCI specific functions in ata handling. This effectively disables all default configurations which now depend on CONFIG_LEGACY_PCI. Yet, I don't see CONFIG_LEGACY_PCI added to configuration files which explicitly enable any of the affected configurations. Is that on purpose ? If so, I think it should at least be mentioned in the commit description. However, I think it would be more appropriate to either delete all affected configuration flags from the affected configuration files, or to add CONFIG_LEGACY_PCI=y to those files. Guenter
[PATCH] drm/pl111: Initialize clock spinlock early
The following warning is seen on systems with broken clock divider.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1 Comm: swapper Not tainted 5.1.0-09698-g1fb3b52 #1
Hardware name: ARM Integrator/CP (Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x18)
[] (show_stack) from [] (dump_stack+0x18/0x24)
[] (dump_stack) from [] (register_lock_class+0x674/0x6f8)
[] (register_lock_class) from []
(__lock_acquire+0x68/0x2128)
[] (__lock_acquire) from [] (lock_acquire+0x110/0x21c)
[] (lock_acquire) from [] (_raw_spin_lock+0x34/0x48)
[] (_raw_spin_lock) from []
(pl111_display_enable+0xf8/0x5fc)
[] (pl111_display_enable) from []
(drm_atomic_helper_commit_modeset_enables+0x1ec/0x244)
Since commit eedd6033b4c8 ("drm/pl111: Support variants with broken clock
divider"), the spinlock is not initialized if the clock divider is broken.
Initialize it earlier to fix the problem.
Fixes: eedd6033b4c8 ("drm/pl111: Support variants with broken clock divider")
Cc: Linus Walleij
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/pl111/pl111_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index 0c5d391f0a8f..4501597f30ab 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -531,14 +531,15 @@ pl111_init_clock_divider(struct drm_device *drm)
dev_err(drm->dev, "CLCD: unable to get clcdclk.\n");
return PTR_ERR(parent);
}
+
+ spin_lock_init(&priv->tim2_lock);
+
/* If the clock divider is broken, use the parent directly */
if (priv->variant->broken_clockdivider) {
priv->clk = parent;
return 0;
}
parent_name = __clk_get_name(parent);
-
- spin_lock_init(&priv->tim2_lock);
div->init = &init;
ret = devm_clk_hw_register(drm->dev, div);
--
2.7.4
Re: [PATCH] drm/pl111: Initialize clock spinlock early
On 5/14/19 3:20 PM, Linus Walleij wrote:
On Mon, May 13, 2019 at 4:46 PM Guenter Roeck wrote:
The following warning is seen on systems with broken clock divider.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1 Comm: swapper Not tainted 5.1.0-09698-g1fb3b52 #1
Hardware name: ARM Integrator/CP (Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x18)
[] (show_stack) from [] (dump_stack+0x18/0x24)
[] (dump_stack) from [] (register_lock_class+0x674/0x6f8)
[] (register_lock_class) from []
(__lock_acquire+0x68/0x2128)
[] (__lock_acquire) from [] (lock_acquire+0x110/0x21c)
[] (lock_acquire) from [] (_raw_spin_lock+0x34/0x48)
[] (_raw_spin_lock) from []
(pl111_display_enable+0xf8/0x5fc)
[] (pl111_display_enable) from []
(drm_atomic_helper_commit_modeset_enables+0x1ec/0x244)
Since commit eedd6033b4c8 ("drm/pl111: Support variants with broken clock
divider"), the spinlock is not initialized if the clock divider is broken.
Initialize it earlier to fix the problem.
Fixes: eedd6033b4c8 ("drm/pl111: Support variants with broken clock divider")
Cc: Linus Walleij
Signed-off-by: Guenter Roeck
Applied to drm-misc-next-fixes and pushed.
Out of curiosity: do you have a "real" Integrator/CP or is this
QEMU?
This is with qemu.
Guenter
Re: [PATCH v5 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting
On 1/21/19 7:17 AM, Vincent Guittot wrote: On Fri, 18 Jan 2019 at 13:08, Guenter Roeck wrote: On 1/18/19 3:05 AM, Rafael J. Wysocki wrote: On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot wrote: On Fri, 18 Jan 2019 at 11:42, Vincent Guittot wrote: Hi Guenter, Le Thursday 17 Jan 2019 à 14:16:28 (-0800), Guenter Roeck a écrit : On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote: From: Thara Gopinath This patch replaces jiffies based accounting for runtime_active_time and runtime_suspended_time with ktime base accounting. This makes the runtime debug counters inline with genpd and other pm subsytems which uses ktime based accounting. timekeeping is initialized before pm_runtime_init() so ktime_get() will be ready before first call. In fact, timekeeping_init() is called early in start_kernel() which is way before driver_init() (and that's when devices can start to be initialized) called from rest_init() via kernel_init_freeable() and do_basic_setup(). This is not (always) correct. My qemu "collie" boot test fails with this patch applied. Reverting the patch fixes the problem. Bisect log attached. Can you try the patch below ? ktime_get_mono_fast_ns() has the advantage of being init with dummy clock so it can be used at early_init. Another possibility would be delay the init of the gpiochip Well, right. Initializing devices before timekeeping doesn't feel particularly robust from the design perspective. How exactly does that happen? With an added 'initialized' flag and backtrace into the timekeeping code, with the change suggested earlier applied: [ cut here ] WARNING: CPU: 0 PID: 0 at kernel/time/timekeeping.c:453 ktime_get_mono_fast_ns+0x114/0x12c Timekeeping not initialized CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc2-next-20190117-dirty #2 Hardware name: Sharp-Collie Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r7:0009 r6: r5:c065ba90 r4:c06d3e54 [] (show_stack) from [] (dump_stack+0x20/0x28) [] (dump_stack) from [] (__warn+0xcc/0xf4) [] (__warn) from [] (warn_slowpath_fmt+0x4c/0x6c) r8:df407b08 r7: r6:c0c01550 r5:c065bad8 r4:c06dd028 [] (warn_slowpath_fmt) from [] (ktime_get_mono_fast_ns+0x114/0x12c) r3: r2:c065bad8 r5: r4:df407b08 [] (ktime_get_mono_fast_ns) from [] (pm_runtime_init+0x38/0xb8) r9:c06c9a5c r8:df407b08 r7: r6:c0c01550 r5: r4:df407b08 [] (pm_runtime_init) from [] (device_initialize+0xb0/0xec) r7: r6:c0c01550 r5: r4:df407b08 [] (device_initialize) from [] (gpiochip_add_data_with_key+0x9c/0x884) r7: r6:c06fca34 r5: r4: [] (gpiochip_add_data_with_key) from [] (sa1100_init_gpio+0x40/0x98) r10:dfffcd60 r9:c06c9a5c r8:c06dd020 r7:c06dd028 r6: r5: r4:c06fca34 [] (sa1100_init_gpio) from [] (sa1100_init_irq+0x2c/0x3c) r7:c06dd028 r6: r5:c0713300 r4:c06e1070 [] (sa1100_init_irq) from [] (init_IRQ+0x20/0x28) r5:c0713300 r4: [] (init_IRQ) from [] (start_kernel+0x254/0x4cc) [] (start_kernel) from [<>] ( (null)) r10:717f r9:6901b119 r8:c100 r7:0092 r6:313d r5:0053 r4:c06a7330 ---[ end trace 91e1bd00dd7cce32 ]--- Does it means that only the pm_runtime_init is done before timekeeping_init() but no update_pm_runtime_accounting() ? In this case, we can keep using ktimeçget in update_pm_runtime_accounting() and find a solution to deal with early_call of pm_runtime_init() For this platform that is correct. I can't answer for the generic case. Guenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: add -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines
On Tue, Jan 29, 2019 at 10:30:31AM -0500, Alex Deucher wrote: > On Fri, Jan 25, 2019 at 10:29 AM Wentland, Harry > wrote: > > > > On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote: > > > arch/x86/Makefile disables SSE and SSE2 for the whole kernel. The > > > AMDGPU drivers modified in this patch re-enable SSE but not SSE2. Turn > > > on SSE2 to support emitting double precision floating point instructions > > > rather than calls to non-existent (usually available from gcc_s or > > > compiler_rt) floating point helper routines. > > > > > > Link: > > > https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html > > > Link: https://github.com/ClangBuiltLinux/linux/issues/327 > > > Cc: sta...@vger.kernel.org # 4.19 > > > Reported-by: S, Shirish > > > Reported-by: Matthias Kaehlcke > > > Suggested-by: James Y Knight > > > Suggested-by: Nathan Chancellor > > > Signed-off-by: Nick Desaulniers > > > Tested-by: Guenter Roeck > > > > Reviewed-by: Harry Wentland > > > > and applied. > > > > This patch causes a segfault: > https://bugs.freedesktop.org/show_bug.cgi?id=109487 > > Any ideas? > Set -msse2 only for clang ? I suspect, though, that this might only solve the compile problem. If I understand correctly, the first warning in the log is due to BREAK_TO_DEBUGGER(), suggesting that something is seriously wrong. Maybe enabling sse2 results in different results from floating point operations. Unfortunately I don't have a system with the affected GPU, so I can't run any tests on real hardware. Unless someone can test with real hardware, I think we have no choice but to revert the patch. Guenter > Alex > > > Harry > > > > > --- > > > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 2 +- > > > drivers/gpu/drm/amd/display/dc/dml/Makefile | 2 +- > > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > > > b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > > > index 95f332ee3e7e..dc85a3c088af 100644 > > > --- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile > > > +++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile > > > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > > > cc_stack_align := -mstack-alignment=16 > > > endif > > > > > > -calcs_ccflags := -mhard-float -msse $(cc_stack_align) > > > +calcs_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > > > > > > CFLAGS_dcn_calcs.o := $(calcs_ccflags) > > > CFLAGS_dcn_calc_auto.o := $(calcs_ccflags) > > > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > > > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > > > index d97ca6528f9d..33c7d7588712 100644 > > > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > > > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > > > @@ -30,7 +30,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),) > > > cc_stack_align := -mstack-alignment=16 > > > endif > > > > > > -dml_ccflags := -mhard-float -msse $(cc_stack_align) > > > +dml_ccflags := -mhard-float -msse -msse2 $(cc_stack_align) > > > > > > CFLAGS_display_mode_lib.o := $(dml_ccflags) > > > CFLAGS_display_pipe_clocks.o := $(dml_ccflags) > > > > > ___ > > amd-gfx mailing list > > amd-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
On Wed, Dec 26, 2018 at 10:06:19AM -0200, Fabio Estevam wrote:
> Since commit e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
> the DRM_MSM symbol can be selected by SOC_IMX5 causing the following
> error when building imx_v6_v7_defconfig:
>
> In file included from ../drivers/gpu/drm/msm/adreno/a5xx_gpu.c:17:0:
> ../include/linux/qcom_scm.h: In function 'qcom_scm_set_cold_boot_addr':
> ../include/linux/qcom_scm.h:73:10: error: 'ENODEV' undeclared (first use in
> this function)
> return -ENODEV;
>
> Include the header file to fix this problem.
>
> Reported-by: kernelci.org bot
> Fixes: e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
> Signed-off-by: Fabio Estevam
> Reviewed-by: Bjorn Andersson
Tested-by: Guenter Roeck
Still broken upstream, and the commit window is about to close.
Any chance to send this patch upstream anytime soon ?
Guenter
> ---
> include/linux/qcom_scm.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
> index 06996ad4f2bc..ce5a476fd733 100644
> --- a/include/linux/qcom_scm.h
> +++ b/include/linux/qcom_scm.h
> @@ -13,6 +13,7 @@
> #ifndef __QCOM_SCM_H
> #define __QCOM_SCM_H
>
> +#include
> #include
> #include
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting
On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote:
> From: Thara Gopinath
>
> This patch replaces jiffies based accounting for runtime_active_time
> and runtime_suspended_time with ktime base accounting. This makes the
> runtime debug counters inline with genpd and other pm subsytems which
> uses ktime based accounting.
>
> timekeeping is initialized before pm_runtime_init() so ktime_get() will
> be ready before first call. In fact, timekeeping_init() is called early
> in start_kernel() which is way before driver_init() (and that's when
> devices can start to be initialized) called from rest_init() via
> kernel_init_freeable() and do_basic_setup().
>
This is not (always) correct. My qemu "collie" boot test fails with this
patch applied. Reverting the patch fixes the problem. Bisect log attached.
With some added debugging:
...
IRQS: 16, nr_irqs: 65, preallocated irqs: 65
irq: Cannot allocate irq_descs @ IRQ1, assuming pre-allocated
gpio gpiochip0: ### pm_runtime_init()
irq: Cannot allocate irq_descs @ IRQ33, assuming pre-allocated
## timekeeping_init()
sched_clock: 32 bits at 3686kHz, resolution 271ns, wraps every 58254200ns^M
...
This is with:
void pm_runtime_init(struct device *dev)
{
+ dev_info(dev, "### pm_runtime_init() \n");
+
...
@@ -1526,6 +1526,8 @@ void __init timekeeping_init(void)
struct clocksource *clock;
unsigned long flags;
+ pr_info("## timekeeping_init() \n");
+
Guenter
---
# bad: [a37d50ca3b837c19a297f349365d11a20c1087d0] Add linux-next specific files
for 20190117
# good: [1c7fc5cbc33980acd13d668f1c8f0313d6ae9fd8] Linux 5.0-rc2
git bisect start 'HEAD' 'v5.0-rc2'
# bad: [4edb817d29fdf19fb5d52784bb3c29c40e00f586] Merge remote-tracking branch
'pm/linux-next'
git bisect bad 4edb817d29fdf19fb5d52784bb3c29c40e00f586
# good: [6d95886720d306a1914a7c9a8aeb0bcbc7aef018] Merge remote-tracking branch
'omap/for-next'
git bisect good 6d95886720d306a1914a7c9a8aeb0bcbc7aef018
# good: [975b5cdd74430bc8a04f832d65a47cdb95b73fec] Merge remote-tracking branch
'fuse/for-next'
git bisect good 975b5cdd74430bc8a04f832d65a47cdb95b73fec
# good: [112386d2189fc54b979c3a8bf64b2908df91e123] Merge remote-tracking branch
'i2c/i2c/for-next'
git bisect good 112386d2189fc54b979c3a8bf64b2908df91e123
# good: [3943f059823b6e15884387f31618b84826e924b3] media: coda: Add control for
h.264 chroma qp index offset
git bisect good 3943f059823b6e15884387f31618b84826e924b3
# good: [44970b5079ee100875b06e45db5d6e91a16e] Merge remote-tracking branch
'v4l-dvb/master'
git bisect good 44970b5079ee100875b06e45db5d6e91a16e
# bad: [599170c2b860aca3364574f833bb9cc801c9668d] Merge branch 'pm-core' into
linux-next
git bisect bad 599170c2b860aca3364574f833bb9cc801c9668d
# good: [347d570919ca9a3a3653ce9cbb7399c7c0ba8248] Merge branch 'acpi-pci' into
linux-next
git bisect good 347d570919ca9a3a3653ce9cbb7399c7c0ba8248
# good: [e0a9fde86ba1bc26dd754c733b32e70cd8f1c187] Merge branches 'acpi-tables'
and 'acpi-apei' into linux-next
git bisect good e0a9fde86ba1bc26dd754c733b32e70cd8f1c187
# good: [3b4ed2e2eb5583774a1ed4aa4596a5a3c55f2567] drm/i915: Move on the new pm
runtime interface
git bisect good 3b4ed2e2eb5583774a1ed4aa4596a5a3c55f2567
# bad: [c75c303933a68c547f3352d1d708843f9449d3f4] PM: clock_ops: fix missing
clk_prepare() return value check
git bisect bad c75c303933a68c547f3352d1d708843f9449d3f4
# bad: [3982ab9ce433efc72ca31eb9ddc85d9355966444] PM-runtime: Replace jiffies
based accounting with ktime-based accounting
git bisect bad 3982ab9ce433efc72ca31eb9ddc85d9355966444
# first bad commit: [3982ab9ce433efc72ca31eb9ddc85d9355966444] PM-runtime:
Replace jiffies based accounting with ktime-based accounting
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v3 6/7] drm/mediatek: change the dsi phytiming calculate method
On Sun, May 19, 2019 at 05:25:36PM +0800, Jitao Shi wrote:
> Change the method of frame rate calc which can get more accurate
> frame rate.
>
> data rate = pixel_clock * bit_per_pixel / lanes
> Adjust hfp_wc to adapt the additional phy_data
>
> if MIPI_DSI_MODE_VIDEO_BURST
> hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12 - 6;
> else
> hfp_wc = hfp * bpp - data_phy_cycles * lanes - 12;
>
> Note:
> //(2: 1 for sync, 1 for phy idle)
> data_phy_cycles = T_hs_exit + T_lpx + T_hs_prepare + T_hs_zero + 2;
>
> bpp: bit per pixel
>
> Signed-off-by: Jitao Shi
> Tested-by: Ryan Case
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 119 +
> 1 file changed, 86 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 1165ff944889..3f51b2000c68 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -158,6 +158,25 @@
> (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> (type == MIPI_DSI_DCS_READ))
>
> +struct mtk_phy_timing {
> + u32 lpx;
> + u32 da_hs_prepare;
> + u32 da_hs_zero;
> + u32 da_hs_trail;
> +
> + u32 ta_go;
> + u32 ta_sure;
> + u32 ta_get;
> + u32 da_hs_exit;
> +
> + u32 clk_hs_zero;
> + u32 clk_hs_trail;
> +
> + u32 clk_hs_prepare;
> + u32 clk_hs_post;
> + u32 clk_hs_exit;
> +};
> +
> struct phy;
>
> struct mtk_dsi_driver_data {
> @@ -182,12 +201,13 @@ struct mtk_dsi {
> struct clk *digital_clk;
> struct clk *hs_clk;
>
> - u32 data_rate;
> + u64 data_rate;
This results in 64-bit divide operations and thus build failures
with 32-bit builds. More on that below.
>
> unsigned long mode_flags;
> enum mipi_dsi_pixel_format format;
> unsigned int lanes;
> struct videomode vm;
> + struct mtk_phy_timing phy_timing;
> int refcount;
> bool enabled;
> u32 irq_data;
> @@ -221,17 +241,39 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
> {
> u32 timcon0, timcon1, timcon2, timcon3;
> u32 ui, cycle_time;
> + struct mtk_phy_timing *timing = &dsi->phy_timing;
> +
> + ui = 10 / dsi->data_rate;
> + cycle_time = 80 / dsi->data_rate;
This results in 64-bit divide operations. On top of that, 80
is larger than 0x, resulting in an integer overflow on 32-bit
systems; it should be provided as 80ULL.
> +
> + timing->lpx = NS_TO_CYCLE(60, cycle_time);
> + timing->da_hs_prepare = NS_TO_CYCLE((40 + 5 * ui), cycle_time);
> + timing->da_hs_zero = NS_TO_CYCLE((110 + 6 * ui), cycle_time);
> + timing->da_hs_trail = NS_TO_CYCLE(((0x4 * ui) + 80), cycle_time);
> +
> + if (timing->da_hs_zero > timing->da_hs_prepare)
> + timing->da_hs_zero -= timing->da_hs_prepare;
> +
> + timing->ta_go = 4 * timing->lpx;
> + timing->ta_sure = 3 * timing->lpx / 2;
> + timing->ta_get = 5 * timing->lpx;
> + timing->da_hs_exit = 2 * timing->lpx;
> +
> + timing->clk_hs_zero = NS_TO_CYCLE(0x150, cycle_time);
> + timing->clk_hs_trail = NS_TO_CYCLE(0x64, cycle_time) + 0xa;
>
> - ui = 1000 / dsi->data_rate + 0x01;
> - cycle_time = 8000 / dsi->data_rate + 0x01;
> + timing->clk_hs_prepare = NS_TO_CYCLE(0x40, cycle_time);
> + timing->clk_hs_post = NS_TO_CYCLE(80 + 52 * ui, cycle_time);
> + timing->clk_hs_exit = 2 * timing->lpx;
>
> - timcon0 = T_LPX | T_HS_PREP << 8 | T_HS_ZERO << 16 | T_HS_TRAIL << 24;
> - timcon1 = 4 * T_LPX | (3 * T_LPX / 2) << 8 | 5 * T_LPX << 16 |
> - T_HS_EXIT << 24;
> - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> - timcon3 = NS_TO_CYCLE(0x40, cycle_time) | (2 * T_LPX) << 16 |
> - NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8;
> + timcon0 = timing->lpx | timing->da_hs_prepare << 8 |
> + timing->da_hs_zero << 16 | timing->da_hs_trail << 24;
> + timcon1 = timing->ta_go | timing->ta_sure << 8 |
> + timing->ta_get << 16 | timing->da_hs_exit << 24;
> + timcon2 = 1 << 8 | timing->clk_hs_zero << 16 |
> + timing->clk_hs_trail << 24;
> + timcon3 = timing->clk_hs_prepare | timing->clk_hs_post << 8 |
> + timing->clk_hs_exit << 16;
>
> writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> @@ -418,7 +460,8 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> u32 horizontal_sync_active_byte;
> u32 horizontal_backporch_byte;
> u32 horizontal_frontporch_byte;
> - u32 dsi_tmp_buf_bpp;
> + u32 dsi_tmp_buf_bpp, data_phy_cycles;
> + struct mtk_phy_timing *timing = &dsi->phy_timing;
>
> struct videomode *vm = &dsi->vm;
>
> @@ -433,7 +476,8 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi)
> writel(vm->vact
Re: [PATCH 09/11] hwmon: Drop obsolete JZ4740 driver
On Thu, Jul 25, 2019 at 06:02:13PM -0400, Paul Cercueil wrote:
> The JZ4740 boards now use the iio-hwmon driver.
>
> Signed-off-by: Paul Cercueil
> Tested-by: Artur Rojek
Acked-by: Guenter Roeck
> ---
> drivers/hwmon/Kconfig| 10 ---
> drivers/hwmon/Makefile | 1 -
> drivers/hwmon/jz4740-hwmon.c | 135 ---
> 3 files changed, 146 deletions(-)
> delete mode 100644 drivers/hwmon/jz4740-hwmon.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 650dd71f9724..2199ac1d0ba7 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -660,16 +660,6 @@ config SENSORS_IT87
> This driver can also be built as a module. If so, the module
> will be called it87.
>
> -config SENSORS_JZ4740
> - tristate "Ingenic JZ4740 SoC ADC driver"
> - depends on MACH_JZ4740 && MFD_JZ4740_ADC
> - help
> - If you say yes here you get support for reading adc values from the
> ADCIN
> - pin on Ingenic JZ4740 SoC based boards.
> -
> - This driver can also be built as a module. If so, the module will be
> - called jz4740-hwmon.
> -
> config SENSORS_JC42
> tristate "JEDEC JC42.4 compliant memory module temperature sensors"
> depends on I2C
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 8db472ea04f0..1e82e912a5c4 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -85,7 +85,6 @@ obj-$(CONFIG_SENSORS_INA2XX)+= ina2xx.o
> obj-$(CONFIG_SENSORS_INA3221)+= ina3221.o
> obj-$(CONFIG_SENSORS_IT87) += it87.o
> obj-$(CONFIG_SENSORS_JC42) += jc42.o
> -obj-$(CONFIG_SENSORS_JZ4740) += jz4740-hwmon.o
> obj-$(CONFIG_SENSORS_K8TEMP) += k8temp.o
> obj-$(CONFIG_SENSORS_K10TEMP)+= k10temp.o
> obj-$(CONFIG_SENSORS_LINEAGE)+= lineage-pem.o
> diff --git a/drivers/hwmon/jz4740-hwmon.c b/drivers/hwmon/jz4740-hwmon.c
> deleted file mode 100644
> index bec5befd1d8b..
> --- a/drivers/hwmon/jz4740-hwmon.c
> +++ /dev/null
> @@ -1,135 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-or-later
> -/*
> - * Copyright (C) 2009-2010, Lars-Peter Clausen
> - * JZ4740 SoC HWMON driver
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -#include
> -
> -#include
> -
> -struct jz4740_hwmon {
> - void __iomem *base;
> - int irq;
> - const struct mfd_cell *cell;
> - struct platform_device *pdev;
> - struct completion read_completion;
> - struct mutex lock;
> -};
> -
> -static irqreturn_t jz4740_hwmon_irq(int irq, void *data)
> -{
> - struct jz4740_hwmon *hwmon = data;
> -
> - complete(&hwmon->read_completion);
> - return IRQ_HANDLED;
> -}
> -
> -static ssize_t in0_input_show(struct device *dev,
> - struct device_attribute *dev_attr, char *buf)
> -{
> - struct jz4740_hwmon *hwmon = dev_get_drvdata(dev);
> - struct platform_device *pdev = hwmon->pdev;
> - struct completion *completion = &hwmon->read_completion;
> - long t;
> - unsigned long val;
> - int ret;
> -
> - mutex_lock(&hwmon->lock);
> -
> - reinit_completion(completion);
> -
> - enable_irq(hwmon->irq);
> - hwmon->cell->enable(pdev);
> -
> - t = wait_for_completion_interruptible_timeout(completion, HZ);
> -
> - if (t > 0) {
> - val = readw(hwmon->base) & 0xfff;
> - val = (val * 3300) >> 12;
> - ret = sprintf(buf, "%lu\n", val);
> - } else {
> - ret = t ? t : -ETIMEDOUT;
> - }
> -
> - hwmon->cell->disable(pdev);
> - disable_irq(hwmon->irq);
> -
> - mutex_unlock(&hwmon->lock);
> -
> - return ret;
> -}
> -
> -static DEVICE_ATTR_RO(in0_input);
> -
> -static struct attribute *jz4740_attrs[] = {
> - &dev_attr_in0_input.attr,
> - NULL
> -};
> -
> -ATTRIBUTE_GROUPS(jz4740);
> -
> -static int jz4740_hwmon_probe(struct platform_device *pdev)
> -{
> - int ret;
> - struct device *dev = &pdev->dev;
> - struct jz4740_hwmon *hwmon;
> - struct device *hwmon_dev;
> -
> - hwmon = devm_kzalloc(dev, sizeof(*hwmon), GFP_KERNEL);
> - if (!hwmon)
> - return -ENOMEM;
> -
> - hwmon->cell = mfd_get_cell(pdev);
> -
> - hwmon->irq = platform_get_irq(pdev, 0);
> - if (hwmon->irq < 0) {
> - dev_err(&pdev->dev,
[PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds
ppc:allmodconfig builds fail with the following error.
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
uses hard float,
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
uses soft float
powerpc64-linux-ld:
failed to merge target specific data of file
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
uses hard float,
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
uses soft float
powerpc64-linux-ld:
failed to merge target specific data of
file drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
uses hard float,
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
uses soft float
powerpc64-linux-ld:
failed to merge target specific data of file
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
64-bit outline-only KASAN support") which adds support for KASAN. This
commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
compiled which lack the selection of hard-float.
Fixes: 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN support")
Cc: Michael Ellerman
Cc: Daniel Axtens
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 4
drivers/gpu/drm/amd/display/dc/dcn315/Makefile | 4
drivers/gpu/drm/amd/display/dc/dcn316/Makefile | 4
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
index ec041e3cda30..74be02114ae4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
@@ -15,6 +15,10 @@ DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o
dcn31_init.o dcn31_hubp.o
dcn31_apg.o dcn31_hpo_dp_stream_encoder.o dcn31_hpo_dp_link_encoder.o \
dcn31_afmt.o dcn31_vpg.o
+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -mhard-float -maltivec
+endif
+
AMD_DAL_DCN31 = $(addprefix $(AMDDALPATH)/dc/dcn31/,$(DCN31))
AMD_DISPLAY_FILES += $(AMD_DAL_DCN31)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
index 59381d24800b..1395c1ced8c5 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
@@ -25,6 +25,10 @@
DCN315 = dcn315_resource.o
+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn315/dcn315_resource.o := -mhard-float -maltivec
+endif
+
AMD_DAL_DCN315 = $(addprefix $(AMDDALPATH)/dc/dcn315/,$(DCN315))
AMD_DISPLAY_FILES += $(AMD_DAL_DCN315)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
index 819d44a9439b..c3d2dd78f1e2 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
@@ -25,6 +25,10 @@
DCN316 = dcn316_resource.o
+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn316/dcn316_resource.o := -mhard-float -maltivec
+endif
+
AMD_DAL_DCN316 = $(addprefix $(AMDDALPATH)/dc/dcn316/,$(DCN316))
AMD_DISPLAY_FILES += $(AMD_DAL_DCN316)
--
2.35.1
Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds
On Mon, Jun 20, 2022 at 05:51:04PM -0400, Alex Deucher wrote:
> On Sat, Jun 18, 2022 at 7:27 PM Guenter Roeck wrote:
> >
> > ppc:allmodconfig builds fail with the following error.
> >
> > powerpc64-linux-ld:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> > uses hard float,
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
> > uses soft float
> > powerpc64-linux-ld:
> > failed to merge target specific data of file
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
> > powerpc64-linux-ld:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> > uses hard float,
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
> > uses soft float
> > powerpc64-linux-ld:
> > failed to merge target specific data of
> > file
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
> > powerpc64-linux-ld:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> > uses hard float,
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
> > uses soft float
> > powerpc64-linux-ld:
> > failed to merge target specific data of file
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
> >
> > The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
> > 64-bit outline-only KASAN support") which adds support for KASAN. This
> > commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
> > KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
> > compiled which lack the selection of hard-float.
> >
> > Fixes: 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN support")
> > Cc: Michael Ellerman
> > Cc: Daniel Axtens
> > Signed-off-by: Guenter Roeck
> > ---
> > drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 4
> > drivers/gpu/drm/amd/display/dc/dcn315/Makefile | 4
> > drivers/gpu/drm/amd/display/dc/dcn316/Makefile | 4
> > 3 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> > b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> > index ec041e3cda30..74be02114ae4 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> > @@ -15,6 +15,10 @@ DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o
> > dcn31_init.o dcn31_hubp.o
> > dcn31_apg.o dcn31_hpo_dp_stream_encoder.o
> > dcn31_hpo_dp_link_encoder.o \
> > dcn31_afmt.o dcn31_vpg.o
> >
> > +ifdef CONFIG_PPC64
> > +CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -mhard-float -maltivec
> > +endif
>
> This stuff was all moved as part of the FP rework in:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=26f4712aedbdf4b9f5e3888a50a2a4b130ee4a9b
> @Siqueira, Rodrigo
> , @Melissa Wen, @Dhillon, Jasdeep can you take a look to understand
> why this is necessary? If we add back the PPC flags, I think we need
> to add back the x86 ones as well.
>
For my part I have no idea. All I can see is that powerpc:allmodconfig
builds fail with the above errors. I have not seen any build errors with
other architectures.
Guenter
> Alex
>
> > +
> > AMD_DAL_DCN31 = $(addprefix $(AMDDALPATH)/dc/dcn31/,$(DCN31))
> >
> > AMD_DISPLAY_FILES += $(AMD_DAL_DCN31)
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> > b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> > index 59381d24800b..1395c1ced8c5 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> > @@ -25,6 +25,10 @@
> >
> > DCN315 = dcn315_resource.o
> >
> > +ifdef CONFIG_PPC64
> > +CFLAGS_$(AMDDALPATH)/dc/dcn315/dcn315_resource.o := -mhard-float -maltivec
> > +endif
> > +
> > AMD_DAL_DCN315 = $(addprefix $(AMDDALPATH)/dc/dcn315/,$(DCN315))
> >
> > AMD_DISPLAY_FILES += $(AMD_DAL_DCN315)
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> > b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> > index 819d44a9439b..c3d2dd78f1e2 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> > @@ -25,6 +25,10 @@
> >
> > DCN316 = dcn316_resource.o
> >
> > +ifdef CONFIG_PPC64
> > +CFLAGS_$(AMDDALPATH)/dc/dcn316/dcn316_resource.o := -mhard-float -maltivec
> > +endif
> > +
> > AMD_DAL_DCN316 = $(addprefix $(AMDDALPATH)/dc/dcn316/,$(DCN316))
> >
> > AMD_DISPLAY_FILES += $(AMD_DAL_DCN316)
> > --
> > 2.35.1
> >
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
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 >
Re: [PATCH 09/48] watchdog: sa1100: use platform device registration
On 4/19/22 09:37, Arnd Bergmann wrote:
From: Arnd Bergmann
Rather than relying on machine specific headers to
pass down the reboot status and the register locations,
use resources and platform_data.
Aside from this, keep the changes to a minimum.
Cc: Wim Van Sebroeck
Cc: Guenter Roeck
Cc: linux-watch...@vger.kernel.org
Signed-off-by: Arnd Bergmann
Acked-by: Guenter Roeck
---
arch/arm/mach-pxa/devices.c | 11 +++
arch/arm/mach-pxa/include/mach/regs-ost.h | 2 +
arch/arm/mach-pxa/include/mach/reset.h| 2 +-
arch/arm/mach-pxa/pxa25x.c| 2 +-
arch/arm/mach-pxa/pxa27x.c| 2 +-
arch/arm/mach-pxa/pxa3xx.c| 2 +-
arch/arm/mach-pxa/reset.c | 3 -
arch/arm/mach-sa1100/generic.c| 6 +-
arch/arm/mach-sa1100/include/mach/reset.h | 1 -
drivers/watchdog/sa1100_wdt.c | 87 ---
10 files changed, 83 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index 454523237c97..12f78636045f 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -24,6 +24,8 @@
#include
#include
+#include
+#include
#include "devices.h"
#include "generic.h"
@@ -1118,3 +1120,12 @@ void __init pxa2xx_set_dmac_info(struct mmp_dma_platdata *dma_pdata)
{
pxa_register_device(&pxa2xx_pxa_dma, dma_pdata);
}
+
+void __init pxa_register_wdt(unsigned int reset_status)
+{
+ struct resource res = DEFINE_RES_MEM(OST_PHYS, OST_LEN);
+
+ reset_status &= RESET_STATUS_WATCHDOG;
+ platform_device_register_resndata(NULL, "sa1100_wdt", -1, &res, 1,
+ &reset_status, sizeof(reset_status));
+}
diff --git a/arch/arm/mach-pxa/include/mach/regs-ost.h
b/arch/arm/mach-pxa/include/mach/regs-ost.h
index 109d0ed264df..c8001cfc8d6b 100644
--- a/arch/arm/mach-pxa/include/mach/regs-ost.h
+++ b/arch/arm/mach-pxa/include/mach/regs-ost.h
@@ -7,6 +7,8 @@
/*
* OS Timer & Match Registers
*/
+#define OST_PHYS 0x40A0
+#define OST_LEN0x0020
#define OSMR0 io_p2v(0x40A0) /* */
#define OSMR1 io_p2v(0x40A4) /* */
diff --git a/arch/arm/mach-pxa/include/mach/reset.h
b/arch/arm/mach-pxa/include/mach/reset.h
index e1c4d100fd45..963dd190bc13 100644
--- a/arch/arm/mach-pxa/include/mach/reset.h
+++ b/arch/arm/mach-pxa/include/mach/reset.h
@@ -8,8 +8,8 @@
#define RESET_STATUS_GPIO (1 << 3) /* GPIO Reset */
#define RESET_STATUS_ALL (0xf)
-extern unsigned int reset_status;
extern void clear_reset_status(unsigned int mask);
+extern void pxa_register_wdt(unsigned int reset_status);
/**
* init_gpio_reset() - register GPIO as reset generator
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index 305047ebd2f1..dfc90b41fba3 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -240,7 +240,7 @@ static int __init pxa25x_init(void)
if (cpu_is_pxa25x()) {
- reset_status = RCSR;
+ pxa_register_wdt(RCSR);
pxa25x_init_pm();
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index a81ac88ecbfd..38fdd22c4dc5 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -337,7 +337,7 @@ static int __init pxa27x_init(void)
if (cpu_is_pxa27x()) {
- reset_status = RCSR;
+ pxa_register_wdt(RCSR);
pxa27x_init_pm();
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index fc84aed99481..7c569fa2a6da 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -463,7 +463,7 @@ static int __init pxa3xx_init(void)
if (cpu_is_pxa3xx()) {
- reset_status = ARSR;
+ pxa_register_wdt(ARSR);
/*
* clear RDH bit every time after reset
diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c
index af78405aa4e9..fcb791c5ae3e 100644
--- a/arch/arm/mach-pxa/reset.c
+++ b/arch/arm/mach-pxa/reset.c
@@ -11,9 +11,6 @@
#include
#include
-unsigned int reset_status;
-EXPORT_SYMBOL(reset_status);
-
static void do_hw_reset(void);
static int reset_gpio = -1;
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index 4dfb7554649d..6c21f214cd60 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -39,9 +39,6 @@
#include "generic.h"
#include
-unsigned int reset_status;
-EXPORT_SYMBOL(reset_status);
-
#define NR_FREQS 16
/*
@@ -319,10 +316,13 @@ static struct platform_device *sa11x0_devices[]
__initdata = {
static int __init sa1100_init(void)
{
+ struct resource wdt_res = DEFINE_RES_MEM(0x9000, 0x20);
pm_power_off = sa1100_power_off;
regulator_has_full_constraints();
+ platform_device_register_simple(&quo
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On Tue, Apr 19, 2022 at 06:37:22PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann > > This revisits a series I sent a few years ago: > > https://lore.kernel.org/lkml/20191018154052.1276506-1-a...@arndb.de/ > > All the other ARMv5 conversions are under way now, with > OMAP1 being the only one still not in linux-next yet, > and PXA completing the set. > > Most of the patches are unchanged from before, furtunately > the PXA code is fairly stable. I addressed Robert's comments, > pulled in two patches from Dmitry, and added the last a the > final four patches to finish off the multiplatform conversion. > > I hope someone is left to test these on PXA: if this works, > I'd like to merge it for 5.19. A git tree with these is avaialable > for testing at > > https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18 > Unfortunately that crashes for me when trying to boot from ide. Bisect points to the last patch of the series. Guenter --- [1.403715] 8<--- cut here --- [1.403848] Unable to handle kernel paging request at virtual address feeb000e [1.404097] [feeb000e] *pgd= [1.404400] Internal error: Oops: 805 [#1] PREEMPT ARM [1.404648] Modules linked in: [1.404890] CPU: 0 PID: 22 Comm: pccardd Not tainted 5.18.0-rc3-next-20220422 #1 [1.405159] Hardware name: SHARP Borzoi [1.405319] PC is at pcmcia_init_one+0xf8/0x27c [1.405476] LR is at devres_add+0x40/0x6c [1.405611] pc : []lr : []psr: a113 [1.405846] sp : c48a5d00 ip : c15f4220 fp : 6113 [1.406026] r10: r9 : c48b000e r8 : c48b [1.406195] r7 : feeb r6 : feeb000e r5 : c15ec090 r4 : c15ec020 [1.406395] r3 : 0002 r2 : r1 : c15f4200 r0 : feeb000e [1.406615] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [1.406847] Control: 7977 Table: a0004000 DAC: 0071 [1.407042] Register r0 information: 0-page vmalloc region starting at 0xfee0 allocated at pci_reserve_io+0x0/0x38 [1.407453] Register r1 information: slab [1.407721] Register r2 information: NULL pointer [1.407885] Register r3 information: non-paged memory [1.408047] Register r4 information: slab [1.408179] Register r5 information: slab [1.408310] Register r6 information: 0-page vmalloc region starting at 0xfee0 allocated at pci_reserve_io+0x0/0x38 [1.408622] Register r7 information: 0-page vmalloc region starting at 0xfee0 allocated at pci_reserve_io+0x0/0x38 [1.408941] Register r8 information: 0-page vmalloc region starting at 0xc48b allocated at soc_pcmcia_add_one+0xf0/0x370 [1.409291] Register r9 information: 0-page vmalloc region starting at 0xc48b allocated at soc_pcmcia_add_one+0xf0/0x370 [1.409617] Register r10 information: NULL pointer [1.409768] Register r11 information: non-paged memory [1.409924] Register r12 information: slab [1.410066] Process pccardd (pid: 22, stack limit = 0x(ptrval)) [1.410268] Stack: (0xc48a5d00 to 0xc48a6000) [1.410448] 5d00: c15ebb78 001a 0110 c0ad702c ff00051a c15ec090 [1.410694] 5d20: c0b713ec c0b713ec c12f6048 c0b644fc 6113 c053f6bc [1.410938] 5d40: c16b3bf0 c15efa88 c09d4e48 0001 0007 0200 000f [1.411174] 5d60: c0b71300 c0ad702c c0b644fc c15ec090 c0b713ec [1.411410] 5d80: c0b9f980 c04491a8 c15ec090 6113 c15ec090 c0b713ec c15ec090 [1.411644] 5da0: 0003 c0449530 c078a988 c0399c90 ff08 c0be4d7c c0b713ec c15ec090 [1.411882] 5dc0: 0003 c0b644fc 6113 c04496e0 0001 c0b713ec [1.412117] 5de0: c48a5e2c c15ec090 c0b644fc c0449aa0 c48a5e2c c04499fc c0be4d50 [1.412352] 5e00: c0b644fc c044702c c12f407c c16b3bd4 c0ad702c c15ec090 0001 [1.412587] 5e20: c15ec0d4 c0449030 c15ec090 c15ec090 0001 c0ad702c c15ec090 c15ec090 [1.412827] 5e40: c0b77a9c c0448044 c15ec090 c12f5030 c04458bc 0001 c009c720 [1.413065] 5e60: c15ec090 c04590e4 c15ec090 0002 c12f6048 c12f6150 c15ec088 c0ad702c [1.413307] 5e80: c15ec090 c15ec020 c12f6150 c12f6048 c12f6150 c15ec088 c15ec090 c12f6160 [1.413551] 5ea0: 6113 c0540820 c12f6048 c12f6150 ffe4 c12f6178 c12f6900 [1.413804] 5ec0: c0bb6828 c05409e8 0011 c12f6048 c12f6150 c0ba35c8 [1.414050] 5ee0: c12f6178 c12f6900 c0bb6828 c074c3a8 c48a5f04 c0ad702c c48a5f10 c074c44c [1.414294] 5f00: c098de10 c09acdc0 c12f4fa0 c48a5f1c 31d0 c0ad702c c12f6048 c12f6048 [1.414538] 5f20: c12f6150 c0ba35c8 c0540af8 c12f6048 c12f6150 c053dcd4 [1.414791] 5f40: c12f6048 0080 c12f6144 c12f6900 c053e704 c12f6178 [1.415037] 5f60: 30d0 c0ad702c c12f6900 c12f4fe0 c12f21a0 c053e36c c12f6048 c12f6900 [1.415282] 5f80: c4809cc0
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 4/22/22 12:16, Arnd Bergmann wrote: On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck wrote: On Tue, Apr 19, 2022 at 06:37:22PM +0200, Arnd Bergmann wrote: From: Arnd Bergmann This revisits a series I sent a few years ago: https://lore.kernel.org/lkml/20191018154052.1276506-1-a...@arndb.de/ All the other ARMv5 conversions are under way now, with OMAP1 being the only one still not in linux-next yet, and PXA completing the set. Most of the patches are unchanged from before, furtunately the PXA code is fairly stable. I addressed Robert's comments, pulled in two patches from Dmitry, and added the last a the final four patches to finish off the multiplatform conversion. I hope someone is left to test these on PXA: if this works, I'd like to merge it for 5.19. A git tree with these is avaialable for testing at https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=pxa-multiplatform-5.18 Unfortunately that crashes for me when trying to boot from ide. Bisect points to the last patch of the series. Thanks a lot for testing and the perfect bug report! [1.403715] 8<--- cut here --- [1.403848] Unable to handle kernel paging request at virtual address feeb000e [1.404097] [feeb000e] *pgd= Ok, this is the PCI I/O space area, which starts at 0xfee0, clearly the way I/O space gets mapped changed here. I don't yet see what happened, but it should be straightforward to find from here. [1.416643] pcmcia_init_one from pcmcia_device_probe+0xe4/0x2a0 [1.416882] pcmcia_device_probe from really_probe+0xc8/0x3b4 [1.417070] really_probe from __driver_probe_device+0x9c/0x214 [1.417255] __driver_probe_device from driver_probe_device+0x38/0xe0 [1.417454] driver_probe_device from __device_attach_driver+0xa4/0x11c [1.417657] __device_attach_driver from bus_for_each_drv+0x88/0xd8 [1.417864] bus_for_each_drv from __device_attach+0xf4/0x194 [1.418047] __device_attach from bus_probe_device+0x8c/0x94 [1.418224] bus_probe_device from device_add+0x3d0/0x894 [1.418395] device_add from pcmcia_device_add+0x2ec/0x3e0 [1.418568] pcmcia_device_add from pcmcia_card_add+0xd4/0x1a0 [1.418756] pcmcia_card_add from pcmcia_bus_add+0x44/0x4c [1.418930] pcmcia_bus_add from socket_insert+0x12c/0x150 [1.419103] socket_insert from pccardd+0x398/0x44c [1.419257] pccardd from kthread+0xdc/0x114 [1.419400] kthread from ret_from_fork+0x14/0x2c [1.419569] Exception stack(0xc48a5fb0 to 0xc48a5ff8) [1.419735] 5fa0: [1.419979] 5fc0: [1.420222] 5fe0: 0013 [1.420501] Code: 1357 e1a06000 0a43 e3a03002 (e5c03000) [1.420874] ---[ end trace ]--- --- # bad: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform # good: [3123109284176b1532874591f7c81f3837bbdc17] Linux 5.18-rc1 git bisect start 'HEAD' 'v5.18-rc1' # good: [9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d] ARM: pxa: mainstone-wm97xx: use gpio lookup table git bisect good 9b03d7f95bd4d97101ecb8ea1e822103b81fdb2d # good: [764063eee7620ea9abb940068a7ad0e7f9efa1b6] cpufreq: pxa3: move clk register access to clk driver git bisect good 764063eee7620ea9abb940068a7ad0e7f9efa1b6 # good: [5153474f0a4388b7ddb59add4be73bfb42b2007f] ARM: mmp: remove tavorevb board support git bisect good 5153474f0a4388b7ddb59add4be73bfb42b2007f # good: [2746f7c78b428c8b01b691a29a972c08101ae343] ARM: PXA: fix multi-cpu build of xsc3 git bisect good 2746f7c78b428c8b01b691a29a972c08101ae343 # good: [73d5106e9489464eac84362705e93bcf3b376123] ARM: pxa: remove support for MTD_XIP git bisect good 73d5106e9489464eac84362705e93bcf3b376123 # first bad commit: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform I'll back out this patch for now while investigating further. Which machine did you hit this on? Is this on hardware or in qemu? qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. Also, I just noticed that the failure is not always the same. z2 fails to boot from initrd, and sx1 fails to boot completely. I'll do another round of bisects. Guenter Arnd
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: > On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck wrote: > > On 4/22/22 12:16, Arnd Bergmann wrote: > > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck wrote: > > > > > > Which machine did you hit this on? Is this on hardware or in qemu? > > > > > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. > > Also, I just noticed that the failure is not always the same. > > z2 fails to boot from initrd, and sx1 fails to boot completely. > > That's a lot of machines failing, I hope at least we got the same bugs more > than once here. > > For the I/O space, I found now that PXA was not using the standard > virtual I/O address yet, but instead used a NULL-based offset. > > I'm not entirely happy with this patch, but this is an outline of what > I think we need to fix that: https://pastebin.com/3nVgQsEw > This one is probably incomplete, at least it breaks sa1100 for now, > and it adds a bogus CONFIG_PCI dependency. I'm also not sure > in what way the last patch in the series triggers it, rather than the > one that removed mach/io.h. > > I had sx1 booting in qemu at least, with the omap1 multiplatform series only. > If you have a custom config for this one, make sure you get the right > DEBUG_LL address. > > > I'll do another round of bisects. > So ... z2 bisect points to the same patch, but the error is different. As mentioned, it does not recognize the initrd. Oddly enough, booting from initrd works for the other platforms. The sx1 boot failure seems to be unrelated to your patch series. It boots fine if built from the tip of your branch, but fails to boot in -next. That will require a bisect from -next. Guenter
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: > On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck wrote: > > On 4/22/22 12:16, Arnd Bergmann wrote: > > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck wrote: > > > > > > Which machine did you hit this on? Is this on hardware or in qemu? > > > > > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. > > Also, I just noticed that the failure is not always the same. > > z2 fails to boot from initrd, and sx1 fails to boot completely. > > That's a lot of machines failing, I hope at least we got the same bugs more > than once here. > > For the I/O space, I found now that PXA was not using the standard > virtual I/O address yet, but instead used a NULL-based offset. > > I'm not entirely happy with this patch, but this is an outline of what > I think we need to fix that: https://pastebin.com/3nVgQsEw > This one is probably incomplete, at least it breaks sa1100 for now, > and it adds a bogus CONFIG_PCI dependency. I'm also not sure > in what way the last patch in the series triggers it, rather than the > one that removed mach/io.h. > > I had sx1 booting in qemu at least, with the omap1 multiplatform series only. > If you have a custom config for this one, make sure you get the right > DEBUG_LL address. > > > I'll do another round of bisects. > Here is the bisect for the sx1 boot failure. Guenter --- # bad: [e7d6987e09a328d4a949701db40ef63fbb970670] Add linux-next specific files for 20220422 # good: [b2d229d4ddb17db541098b83524d901257e93845] Linux 5.18-rc3 git bisect start 'HEAD' 'v5.18-rc3' # bad: [479506a21bd2df998017a00f4fe0ea893039d9d0] Merge branch 'drm-next' of git://git.freedesktop.org/git/drm/drm.git git bisect bad 479506a21bd2df998017a00f4fe0ea893039d9d0 # bad: [84fdc506ff63f3f8eb7feaac87821c39bf1dbdfd] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git git bisect bad 84fdc506ff63f3f8eb7feaac87821c39bf1dbdfd # bad: [0318e72d28be01b99056a7e66572423682eae2bb] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git git bisect bad 0318e72d28be01b99056a7e66572423682eae2bb # good: [813d98e2e26d3f418d925263a82d72d1454b326e] Merge branch 'zstd-linus' of https://github.com/terrelln/linux.git git bisect good 813d98e2e26d3f418d925263a82d72d1454b326e # bad: [5e87f91cfe6e938eccb88a992687e2ac52eec2a7] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git git bisect bad 5e87f91cfe6e938eccb88a992687e2ac52eec2a7 # bad: [ac4b03d5ad6b887558eb94943f0f2834661dee45] Merge branch 'pxa-multiplatform-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc into arm/multiplatform-late git bisect bad ac4b03d5ad6b887558eb94943f0f2834661dee45 # good: [6eab9bfd712f63c0977f2d38a45f321816030707] Merge branch 'omap1/multiplatform-prep' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc into arm/multiplatform git bisect good 6eab9bfd712f63c0977f2d38a45f321816030707 # good: [ac571609a9fab9b94bbd8e634ba20e2ab672e32d] input: touchscreen: mainstone: sync with zylonite driver git bisect good ac571609a9fab9b94bbd8e634ba20e2ab672e32d # good: [77b9aeb6e3cd4de6b320d3a9be5d692594159f9e] ARM: pxa: remove unused mach/bitfield.h git bisect good 77b9aeb6e3cd4de6b320d3a9be5d692594159f9e # good: [7643a9ca9f8e08f71e15f89dd74863635e981e03] ARM: pxa: convert to multiplatform git bisect good 7643a9ca9f8e08f71e15f89dd74863635e981e03 # good: [bdfb692acfa98c3e8135ab44bc8366636443590a] [MERGED] ASoC: ti: osk5912: Make it CCF clk API compatible git bisect good bdfb692acfa98c3e8135ab44bc8366636443590a # bad: [b59e8a5fd321fe44bdabd38908b4f899f933cf0f] [TO BE REBASED] ARM: omap1: enable multiplatform git bisect bad b59e8a5fd321fe44bdabd38908b4f899f933cf0f # good: [4c4467ac74299b14b8cf74406722af8090aa7766] [TO BE REBASED] ARM: OMAP1: clock: Convert to CCF git bisect good 4c4467ac74299b14b8cf74406722af8090aa7766 # first bad commit: [b59e8a5fd321fe44bdabd38908b4f899f933cf0f] [TO BE REBASED] ARM: omap1: enable multiplatform
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 4/23/22 12:55, Arnd Bergmann wrote: On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck wrote: On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck wrote: On 4/22/22 12:16, Arnd Bergmann wrote: On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck wrote: Which machine did you hit this on? Is this on hardware or in qemu? qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. Also, I just noticed that the failure is not always the same. z2 fails to boot from initrd, and sx1 fails to boot completely. That's a lot of machines failing, I hope at least we got the same bugs more than once here. For the I/O space, I found now that PXA was not using the standard virtual I/O address yet, but instead used a NULL-based offset. I'm not entirely happy with this patch, but this is an outline of what I think we need to fix that: https://pastebin.com/3nVgQsEw This one is probably incomplete, at least it breaks sa1100 for now, and it adds a bogus CONFIG_PCI dependency. I'm also not sure in what way the last patch in the series triggers it, rather than the one that removed mach/io.h. I had sx1 booting in qemu at least, with the omap1 multiplatform series only. If you have a custom config for this one, make sure you get the right DEBUG_LL address. I'll do another round of bisects. Here is the bisect for the sx1 boot failure. Odd, I can't reproduce this at all. Do you get any console output at all for this? Is this the plain omap1_defconfig, or something else? No, it is my own sx1 specific configuration. https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/qemu_sx1_defconfig I don't recall where I got it from but ... One thing I keep having to apply myself is this snippet: diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S index 0bfad62ea858..87c695703580 100644 --- a/arch/arm/mm/proc-arm925.S +++ b/arch/arm/mm/proc-arm925.S @@ -441,7 +441,6 @@ __arm925_setup: #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH mov r0, #4 @ disable write-back on caches explicitly - mcr p15, 7, r0, c15, c0, 0 #endif it does not have CONFIG_CPU_DCACHE_WRITETHROUGH enabled. Guenter adr r5, arm925_crval I don't remember what the story is behind this, but I can't actually manage to boot omap1_defconfig on qemu with the instruction intact. Arnd
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 4/24/22 01:52, Arnd Bergmann wrote: On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck wrote: On 4/23/22 12:55, Arnd Bergmann wrote: On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck wrote: On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: Odd, I can't reproduce this at all. Do you get any console output at all for this? Is this the plain omap1_defconfig, or something else? No, it is my own sx1 specific configuration. https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/qemu_sx1_defconfig I don't recall where I got it from but ... Ok, that explains it, thanks! I fixed all the defconfig files that come with the kernel, but for your own ones you have to add # CONFIG_ARCH_MULTI_V7 is not set into the defconfig file, otherwise the multiplatform target defaults to an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1, you also need to enable CONFIG_ARCH_MULTI_V4T. This is slightly unfortunate, but I don't see any way to avoid it, and the modified defconfig will still work fine with older kernel trees. Yes, that works. I changed it in my configuration. One thing I keep having to apply myself is this snippet: diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S index 0bfad62ea858..87c695703580 100644 --- a/arch/arm/mm/proc-arm925.S +++ b/arch/arm/mm/proc-arm925.S @@ -441,7 +441,6 @@ __arm925_setup: #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH mov r0, #4 @ disable write-back on caches explicitly - mcr p15, 7, r0, c15, c0, 0 #endif it does not have CONFIG_CPU_DCACHE_WRITETHROUGH enabled. Maybe it was disabled explicitly for the sx1_defconfig because of this bug. I would think that this is required for actual sx1 hardware because the option is default-enabled for ARM925T, and that CPU core is exclusively used in OMAP15xx. That looks like a bug in qemu. ARM925T instruction support is limited to V4T instructions. qemu doesn't have explicit 5T support. It is either V4T or V5. Guenter
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 4/28/22 06:44, Arnd Bergmann wrote: On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann wrote: On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck wrote: On 4/24/22 01:52, Arnd Bergmann wrote: On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck wrote: into the defconfig file, otherwise the multiplatform target defaults to an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1, you also need to enable CONFIG_ARCH_MULTI_V4T. This is slightly unfortunate, but I don't see any way to avoid it, and the modified defconfig will still work fine with older kernel trees. Yes, that works. I changed it in my configuration. Ok, great!. I managed to boot the z2 machine with PCMCIA support and it gets around the issue with my patch, correctly detecting the CF card. Hi Guenter, I have now sent out a fix that I'm happy with, and applied it to the pxa-multiplatform-5.18 branch of the soc tree as well as the combined arm/multiplatform tree. I have not merged this new version into the for-next branch since I would like to see if there are any other regressions first. Can you run your boot tests on the arm/multiplatform branch and let me know if that fixes everything you found? If that takes a lot of manual steps on your side, I'd just wait for the build bots and merge it after all there are no new compile-time issues. -next is pretty badly broken right now due to a series of less than perfect mm patches, so testing there won't do any good. I'll see if I can dig up the multiplatform branch and push it into my 'testing' branch. Guenter
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 4/28/22 06:44, Arnd Bergmann wrote: On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann wrote: On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck wrote: On 4/24/22 01:52, Arnd Bergmann wrote: On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck wrote: into the defconfig file, otherwise the multiplatform target defaults to an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1, you also need to enable CONFIG_ARCH_MULTI_V4T. This is slightly unfortunate, but I don't see any way to avoid it, and the modified defconfig will still work fine with older kernel trees. Yes, that works. I changed it in my configuration. Ok, great!. I managed to boot the z2 machine with PCMCIA support and it gets around the issue with my patch, correctly detecting the CF card. Hi Guenter, I have now sent out a fix that I'm happy with, and applied it to the pxa-multiplatform-5.18 branch of the soc tree as well as the combined arm/multiplatform tree. I have not merged this new version into the for-next branch since I would like to see if there are any other regressions first. Can you run your boot tests on the arm/multiplatform branch and let me know if that fixes everything you found? If that takes a lot of manual steps on your side, I'd just wait for the build bots and merge it after all there are no new compile-time issues. I tried the pxa-multiplatform-5.18 branch. Its failures match those in v5.18-rc1. Should I try soc/arm/multiplatform as well ? Guenter
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 4/29/22 10:48, Guenter Roeck wrote: On 4/28/22 06:44, Arnd Bergmann wrote: On Sun, Apr 24, 2022 at 8:48 PM Arnd Bergmann wrote: On Sun, Apr 24, 2022 at 5:28 PM Guenter Roeck wrote: On 4/24/22 01:52, Arnd Bergmann wrote: On Sun, Apr 24, 2022 at 4:09 AM Guenter Roeck wrote: into the defconfig file, otherwise the multiplatform target defaults to an ARMv7 instead of ARMv5 build. For an OMAP15xx as in the SX1, you also need to enable CONFIG_ARCH_MULTI_V4T. This is slightly unfortunate, but I don't see any way to avoid it, and the modified defconfig will still work fine with older kernel trees. Yes, that works. I changed it in my configuration. Ok, great!. I managed to boot the z2 machine with PCMCIA support and it gets around the issue with my patch, correctly detecting the CF card. Hi Guenter, I have now sent out a fix that I'm happy with, and applied it to the pxa-multiplatform-5.18 branch of the soc tree as well as the combined arm/multiplatform tree. I have not merged this new version into the for-next branch since I would like to see if there are any other regressions first. Can you run your boot tests on the arm/multiplatform branch and let me know if that fixes everything you found? If that takes a lot of manual steps on your side, I'd just wait for the build bots and merge it after all there are no new compile-time issues. I tried the pxa-multiplatform-5.18 branch. Its failures match those in v5.18-rc1. Uuh, wait, the build wasn't complete. There are still some failures. I'll report later. Guenter
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 4/29/22 14:46, Arnd Bergmann wrote: On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck wrote: On 4/29/22 10:48, Guenter Roeck wrote: I tried the pxa-multiplatform-5.18 branch. Its failures match those in v5.18-rc1. Uuh, wait, the build wasn't complete. There are still some failures. I'll report later. Sorry about the breakage, I got a few more reports about minor build errors and warnings, the newly uploaded branches should address all of the ones I got reports for. Unless I am missing something the failures are the same as before. See https://kerneltests.org/builders/qemu-arm-testing/builds/74/steps/qemubuildcommand/logs/stdio This is with v5.18-rc1-49-ge8ab9a9a2745 which is the tip of soc/pxa-multiplatform-5.18. Should I check a different branch ? Thanks, Guenter
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 4/30/22 01:04, Arnd Bergmann wrote: On Sat, Apr 30, 2022 at 1:09 AM Guenter Roeck wrote: On 4/29/22 14:46, Arnd Bergmann wrote: On Fri, Apr 29, 2022 at 10:23 PM Guenter Roeck wrote: On 4/29/22 10:48, Guenter Roeck wrote: I tried the pxa-multiplatform-5.18 branch. Its failures match those in v5.18-rc1. Uuh, wait, the build wasn't complete. There are still some failures. I'll report later. Sorry about the breakage, I got a few more reports about minor build errors and warnings, the newly uploaded branches should address all of the ones I got reports for. Unless I am missing something the failures are the same as before. See https://kerneltests.org/builders/qemu-arm-testing/builds/74/steps/qemubuildcommand/logs/stdio This is with v5.18-rc1-49-ge8ab9a9a2745 which is the tip of soc/pxa-multiplatform-5.18. Should I check a different branch ? I only addressed the pcmcia probe failure that you reported for the final pxa patch, which previously caused a NULL pointer reference here: [1.405319] PC is at pcmcia_init_one+0xf8/0x27c [1.405476] LR is at devres_add+0x40/0x6c [1.405611] pc : []lr : []psr: a113 [1.405846] sp : c48a5d00 ip : c15f4220 fp : 6113 [1.406026] r10: r9 : c48b000e r8 : c48b [1.406195] r7 : feeb r6 : feeb000e r5 : c15ec090 r4 : c15ec020 [1.406395] r3 : 0002 r2 : r1 : c15f4200 r0 : feeb000e This now seems to work: [1.435846] pcmcia_socket pcmcia_socket1: pccard: PCMCIA card inserted into slot 1 [1.456350] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0 [1.457489] pcmcia 0.0: pcmcia: registering new device pcmcia0.0 (IRQ: 217) [1.460275] pata_pcmcia: probe of 0.0 failed with error -12 So it sounds like there are additional bugs that I have to look at. I probably won't be able to do that in time for the merge window. The logs contain a number of warnings, but I have no idea which ones of those are preexisting issue. I had a look at [0.689982] pxa-dma pxa-dma.0: error -ENXIO: IRQ index 1 not found Yes, those messages are indeed old. and concluded that it must have done this for a long time. In my own qemu instance, I see a crash from iWMMXt, but that works fine on your machine. OTOH, your failed instances all look like they either time out or failed to find a rootfs. I tried passing an MMC device as root, and that works here. Booting from mmc works for me as well. Booting from pcmcia worked before, so I assume that there must be some regression. Guenter
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 4/30/22 07:23, Arnd Bergmann wrote:
On Sat, Apr 30, 2022 at 3:32 PM Arnd Bergmann wrote:
On Sat, Apr 30, 2022 at 2:41 PM Guenter Roeck wrote:
On 4/30/22 01:04, Arnd Bergmann wrote:
and concluded that it must have done this for a long time. In my own qemu
instance, I see a crash from iWMMXt, but that works fine on your machine.
OTOH, your failed instances all look like they either time out or
failed to find a
rootfs. I tried passing an MMC device as root, and that works here.
Booting from mmc works for me as well. Booting from pcmcia worked before,
so I assume that there must be some regression.
Ok, got it, and managed to reproduce the hang now. My "ARM: pxa/sa1100: move
I/O space to PCI_IOBASE" patch managed to get it to the point of detecting
the pcmcia device instead of crashing, so I assumed it was enough when it
clearly was not. Before that patch, it still works, afterwards it hangs with
"pata_pcmcia: probe of 0.0 failed with error -12" as mentioned above. I'll
have another look.
Got it: as the PCMCIA bus on this machine is the only thing with an I/O space,
I assigned it port number range 0-0x1000, with an io_offset of 0, but this
was apparently unexpected and triggered this sanity check:
static int static_find_io(struct pcmcia_socket *s, unsigned int attr,
unsigned int *base, unsigned int num,
unsigned int align, struct resource **parent)
{
if (!s->io_offset)
return -EINVAL;
...
return 0;
}
I moved the devices around now, giving zeus/viper I/O space an offset of
zero, and moving PCMCIA to offset 0x1 and 0x11000 for the two slots,
which now works because the io_offset is nonzero. I've regenerated the
branches again, and confirmed the for-next branch still boots from pcmcia.
With v5.18-rc1-49-gcb813018b5c1, I still get:
[0.797668] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[0.805262] /dev/root: Can't open blockdev
[0.805487] VFS: Cannot open root device "(null)" or unknown-block(0,0):
error -6
[0.805674] Please append a correct "root=" boot option; here are the
available partitions:
when trying to boot z2 from initrd.
The other problems are gone.
Guenter
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 5/2/22 12:21, Arnd Bergmann wrote:
On Mon, May 2, 2022 at 6:26 PM Guenter Roeck wrote:
With v5.18-rc1-49-gcb813018b5c1, I still get:
[0.797668] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[0.805262] /dev/root: Can't open blockdev
[0.805487] VFS: Cannot open root device "(null)" or unknown-block(0,0):
error -6
[0.805674] Please append a correct "root=" boot option; here are the
available partitions:
when trying to boot z2 from initrd.
The other problems are gone.
Ok, progress!
What is your qemu command line? I see that z2 has no pcmcia device, so
I tried booting
from MMC, but this already fails with 5.18-rc1 without any of my
patches, giving me
[0.697481] Creating 3 MTD partitions on "physmap-flash":
[0.698161] 0x-0x0004 : "U-Boot Bootloader"
[0.702815] 0x0004-0x0006 : "U-Boot Environment"
[0.706541] 0x0006-0x0080 : "Flash"
[0.718066] pxa2xx-mci pxa2xx-mci.0: incomplete constraints, dummy
supplies not allowed
[0.718501] pxa2xx-mci pxa2xx-mci.0: incomplete constraints, dummy
supplies not allowed
To boot from initrd:
qemu-system-arm -M z2 -kernel \
arch/arm/boot/zImage -no-reboot -initrd \
rootfs-armv5.cpio --append \
"panic=-1 slub_debug=FZPUA rdinit=/sbin/init console=ttyS0" -nographic \
-monitor null -serial stdio
where rootfs-armv5.cpio is from my repository at github.com.
https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/rootfs-armv5.cpio.gz
Do you have MMC or some other rootfs working without my patch series?
I can boot z2 from mmc and flash, but I have a number of configuration
flags enabled on top of pxa_defconfig. That also works with your latest patch
series. See
https://kerneltests.org/builders/qemu-arm-testing/builds/75/steps/qemubuildcommand/logs/stdio
# Always enable ...
enable_config "${defconfig}" CONFIG_DEVTMPFS CONFIG_DEVTMPFS_MOUNT
CONFIG_BLK_DEV_INITRD
# Options needed to be built into the kernel for device support
# on pxa devices
# MTD, squashfs
enable_config_cond "${defconfig}" CONFIG_MTD_BLOCK CONFIG_MTD_PXA2XX
CONFIG_SQUASHFS
# MMC
enable_config_cond "${defconfig}" CONFIG_MMC_BLOCK CONFIG_MMC_PXA
# PCMCIA
enable_config_cond "${defconfig}" CONFIG_ATA CONFIG_BLK_DEV_SD CONFIG_PCCARD
enable_config_cond "${defconfig}" CONFIG_PCMCIA CONFIG_PATA_PCMCIA
CONFIG_PCMCIA_PXA2XX
# USB
enable_config_cond "${defconfig}" CONFIG_USB CONFIG_USB_STORAGE
CONFIG_USB_OHCI_HCD CONFIG_USB_OHCI_HCD_PXA27X
Hope this helps,
Guenter
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 5/2/22 14:03, Arnd Bergmann wrote: On Mon, May 2, 2022 at 10:35 PM Guenter Roeck wrote: On 5/2/22 12:21, Arnd Bergmann wrote: To boot from initrd: qemu-system-arm -M z2 -kernel \ arch/arm/boot/zImage -no-reboot -initrd \ rootfs-armv5.cpio --append \ "panic=-1 slub_debug=FZPUA rdinit=/sbin/init console=ttyS0" -nographic \ -monitor null -serial stdio where rootfs-armv5.cpio is from my repository at github.com. https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/rootfs-armv5.cpio.gz Ok, that works here with any configuration, I don't see a regression. Could this be a problem with the size increase? The machine only has 32MB of RAM, so it's possible that the multiplatform-enabled kernel with DT support etc pushes it over the edge, especially with an initramfs. qemu puts initrd in the middle of available memory. With the image size being ~1MB larger than with v5.18-rc, this is too much, and the kernel overwrites part of initrd. This causes it to be corrupted. It looks like that would have happened eventually, your patch series just made it happen now. The kernel is just getting too large to run on such small systems. I worked around the problem in my version of qemu by loading initrd at the end of the (small) RAM. With that, I no longer see the boot failure. Guenter
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 5/3/22 00:17, Arnd Bergmann wrote: On Tue, May 3, 2022 at 4:55 AM Guenter Roeck wrote: On 5/2/22 14:03, Arnd Bergmann wrote: On Mon, May 2, 2022 at 10:35 PM Guenter Roeck wrote: On 5/2/22 12:21, Arnd Bergmann wrote: qemu puts initrd in the middle of available memory. With the image size being ~1MB larger than with v5.18-rc, this is too much, and the kernel overwrites part of initrd. This causes it to be corrupted. It looks like that would have happened eventually, your patch series just made it happen now. The kernel is just getting too large to run on such small systems. I worked around the problem in my version of qemu by loading initrd at the end of the (small) RAM. With that, I no longer see the boot failure. Ok, thanks for confirming. If it's just the image size that changed, then I think we can live with it. Having the kernel image grow by 1MB seems excessive though, I'd like to understand better where that increase comes from. Starting out from pxa_defconfig, I see a 40KB increase from the final patch that moves to multiplatform support, which I think is fine. If you have a z2 specific config, that would probably not enable CONFIG_OF, which is always turned on for multiplatform, but again that only adds around 250KB in my builds (using gcc-11). This is more than I'd like it to be, but still much less than 1MB. Maybe it is a bit less; I only compared the size of "Image". Either case, it is enough to cause the problem. I am not sure if it is worth the time trying to track this down further. Guenter
Re: [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c
On 5/11/22 10:00, Sam Ravnborg wrote: Hi Javier. On Wed, May 11, 2022 at 01:32:30PM +0200, Javier Martinez Canillas wrote: From: Daniel Vetter Well except when the olpc dcon fbdev driver is enabled, that thing digs around in there in rather unfixable ways. Cc oldc_dcon maintainers as fyi. Another way to fix this is to mark FB_OLPC_DCON and add a TODO entry to fix this. We are really not supposed to carry such special code around to keep staging working. I know this may not be a popular viewpoint, but just look at the ugly workarounds required here. Sam v2: I typoed the config name (0day) Cc: kernel test robot Cc: Jens Frederich Cc: Jon Nettleton Cc: Greg Kroah-Hartman Cc: linux-stag...@lists.linux.dev Signed-off-by: Daniel Vetter Signed-off-by: Daniel Vetter Reviewed-by: Javier Martinez Canillas Cc: Daniel Vetter Cc: Helge Deller Cc: Matthew Wilcox Cc: Sam Ravnborg Cc: Tetsuo Handa Cc: Zhen Lei Cc: Alex Deucher Cc: Xiyu Yang Cc: linux-fb...@vger.kernel.org Cc: Zheyu Ma Cc: Guenter Roeck Signed-off-by: Javier Martinez Canillas --- (no changes since v1) drivers/video/fbdev/core/fbmem.c | 8 ++-- include/linux/fb.h | 7 +++ 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 265efa189bcc..6cab5f4c1fb3 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -50,10 +50,14 @@ static DEFINE_MUTEX(registration_lock); struct fb_info *registered_fb[FB_MAX] __read_mostly; -EXPORT_SYMBOL(registered_fb); - int num_registered_fb __read_mostly; +#if IS_ENABLED(CONFIG_FB_OLPC_DCON) +EXPORT_SYMBOL(registered_fb); EXPORT_SYMBOL(num_registered_fb); +#endif It is stuff like this I refer to as "ugly" in the comment above. My "solution" for that kind of thing is to use a namespace, such as EXPORT_SYMBOL_NS(registered_fb, FB_OLPC_DCON); EXPORT_SYMBOL_NS(num_registered_fb, FB_OLPC_DCON); and import it from the offending code. That avoids ifdefs while at the same time limiting the use of the symbols to the expected scope. Of course that could be abused but that abuse would be obvious. Guenter
Re: [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > During a patch discussion, Linus brought up the option of changing > the C standard version from gnu89 to gnu99, which allows using variable > declaration inside of a for() loop. While the C99, C11 and later standards > introduce many other features, most of these are already available in > gnu89 as GNU extensions as well. The downside is that backporting affected patches to older kernel branches now fails with error messages such as mm/kfence/core.c: In function ‘kfence_init_pool’: mm/kfence/core.c:595:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode Just something to keep in mind when writing patches. Guenter
Re: [greybus-dev] Re: [PATCH] [v2] Kbuild: move to -std=gnu11
On 5/16/22 06:31, Greg KH wrote: On Mon, May 16, 2022 at 06:10:23AM -0700, Guenter Roeck wrote: On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: From: Arnd Bergmann During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99, which allows using variable declaration inside of a for() loop. While the C99, C11 and later standards introduce many other features, most of these are already available in gnu89 as GNU extensions as well. The downside is that backporting affected patches to older kernel branches now fails with error messages such as mm/kfence/core.c: In function ‘kfence_init_pool’: mm/kfence/core.c:595:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode Just something to keep in mind when writing patches. I just ran across this very issue on this commit. It's an easy fixup for 5.17.y to make this work, so I did that in my tree. If this gets to be too much, we might need to reconsider adding c11 to older stable kernels. I think I'll do just that for ChromeOS; I don't want to have to deal with the backports, and we are using recent compilers anyway. Guenter
Re: [greybus-dev] Re: [PATCH] [v2] Kbuild: move to -std=gnu11
On 5/18/22 00:46, Arnd Bergmann wrote: On Mon, May 16, 2022 at 3:19 PM Guenter Roeck wrote: On 5/16/22 06:31, Greg KH wrote: On Mon, May 16, 2022 at 06:10:23AM -0700, Guenter Roeck wrote: On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: From: Arnd Bergmann During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99, which allows using variable declaration inside of a for() loop. While the C99, C11 and later standards introduce many other features, most of these are already available in gnu89 as GNU extensions as well. The downside is that backporting affected patches to older kernel branches now fails with error messages such as mm/kfence/core.c: In function ‘kfence_init_pool’: mm/kfence/core.c:595:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode Just something to keep in mind when writing patches. I just ran across this very issue on this commit. It's an easy fixup for 5.17.y to make this work, so I did that in my tree. If this gets to be too much, we might need to reconsider adding c11 to older stable kernels. I think I'll do just that for ChromeOS; I don't want to have to deal with the backports, and we are using recent compilers anyway. I think it would be better not to have the --std=gnu11 change in the older stable kernels by default, as this has introduced build warnings and other smaller issues, as well as raising the minimum compiler version. The users that are stuck on older kernels for some reason tend to overlap with those on older compilers. One example here is Android, which used to ship with a gcc-4.9 build as the only non-clang toolchain, and was using this for building their kernels. If someone wants to pull in stable updates into an older Android, this would fail with -std=gnu11. Others may be in the same situation. Changing some of the 5.x stable branches to -std=gnu11 is probably less of a problem, but I would not know where to draw the line exactly. Maybe check with the Android team to see what the newest kernel is that they expect to be built with the old gcc-4.9. I don't think they still build anything with gcc. We (ChromeOS) only need it for test builds of chromeos-4.4 (sigh), and that will hopefully be gone in a couple of months. We already enabled -std=gnu11 in chromeos-5.10 and chromeos-5.15. We'll see if that is possible with chromeos-5.4 as well. We won't bother with older kernel branches, but those should not get many patches from upstream outside stable release merges, so it is less of a problem. Guenter
Re: [linux-next:master] BUILD REGRESSION 736ee37e2e8eed7fe48d0a37ee5a709514d478b3
On 5/18/22 17:55, kernel test robot wrote: tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Add linux-next specific files for 20220518 Error/Warning reports: https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com https://lore.kernel.org/linux-mm/202205041248.wgcwpcev-...@intel.com https://lore.kernel.org/linux-mm/202205122113.ulkzd3sz-...@intel.com https://lore.kernel.org/linux-mm/202205172344.3gfeaum1-...@intel.com https://lore.kernel.org/linux-mm/202205190527.o9wvevhi-...@intel.com Error/Warning: (recently discovered and may have been fixed) [ .. ] drivers/hwmon/nct6775-platform.c:199:9: sparse:unsigned char drivers/hwmon/nct6775-platform.c:199:9: sparse:void This is getting tiresome. Every driver using outb() on m68k will experience that "problem". As far as I can see, it is caused by #define out_8(addr,b) (void)((*(__force volatile u8 *) (unsigned long)(addr)) = (b)) in arch/m68k/include/asm/raw_io.h. I have no idea what the "(void)" is for, but removing it "fixes" the problem. Either case, this is not a problem with the nct6775 driver, nor is it a new problem. Guenter
Re: [PATCH] drm/msm/adreno: Do not propagate void return values
On 5/20/22 05:53, Geert Uytterhoeven wrote:
With sparse ("make C=2"), lots of
error: return expression in void function
messages are seen.
Fix this by removing the return statements to propagate void return
values.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Guenter Roeck
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 4 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 3e325e2a2b1b68eb..d137136d93f3b4ca 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -504,7 +504,7 @@ static void a6xx_rpmh_stop(struct a6xx_gmu *gmu)
static inline void pdc_write(void __iomem *ptr, u32 offset, u32 value)
{
- return msm_writel(value, ptr + (offset << 2));
+ msm_writel(value, ptr + (offset << 2));
}
static void __iomem *a6xx_gmu_get_mmio(struct platform_device *pdev,
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 84bd516f01e895b2..e034935b3986f9f2 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -98,7 +98,7 @@ static inline u32 gmu_read(struct a6xx_gmu *gmu, u32 offset)
static inline void gmu_write(struct a6xx_gmu *gmu, u32 offset, u32 value)
{
- return msm_writel(value, gmu->mmio + (offset << 2));
+ msm_writel(value, gmu->mmio + (offset << 2));
}
static inline void
@@ -138,7 +138,7 @@ static inline u32 gmu_read_rscc(struct a6xx_gmu *gmu, u32
offset)
static inline void gmu_write_rscc(struct a6xx_gmu *gmu, u32 offset, u32 value)
{
- return msm_writel(value, gmu->rscc + (offset << 2));
+ msm_writel(value, gmu->rscc + (offset << 2));
}
#define gmu_poll_timeout_rscc(gmu, addr, val, cond, interval, timeout) \
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ccc4fcf7a630f49a..d671b75f3289fdff 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1446,7 +1446,7 @@ static void a6xx_llc_rmw(struct a6xx_gpu *a6xx_gpu, u32
reg, u32 mask, u32 or)
static void a6xx_llc_write(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 value)
{
- return msm_writel(value, a6xx_gpu->llc_mmio + (reg << 2));
+ msm_writel(value, a6xx_gpu->llc_mmio + (reg << 2));
}
static void a6xx_llc_deactivate(struct a6xx_gpu *a6xx_gpu)
Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds
On 6/30/22 14:01, Rodrigo Siqueira Jordao wrote:
On 2022-06-18 19:27, Guenter Roeck wrote:
ppc:allmodconfig builds fail with the following error.
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
uses hard float,
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
uses soft float
powerpc64-linux-ld:
failed to merge target specific data of file
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
uses hard float,
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
uses soft float
powerpc64-linux-ld:
failed to merge target specific data of
file drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
uses hard float,
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
uses soft float
powerpc64-linux-ld:
failed to merge target specific data of file
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
64-bit outline-only KASAN support") which adds support for KASAN. This
commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
compiled which lack the selection of hard-float.
Fixes: 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN support")
Cc: Michael Ellerman
Cc: Daniel Axtens
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 4
drivers/gpu/drm/amd/display/dc/dcn315/Makefile | 4
drivers/gpu/drm/amd/display/dc/dcn316/Makefile | 4
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
index ec041e3cda30..74be02114ae4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
@@ -15,6 +15,10 @@ DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o
dcn31_init.o dcn31_hubp.o
dcn31_apg.o dcn31_hpo_dp_stream_encoder.o dcn31_hpo_dp_link_encoder.o \
dcn31_afmt.o dcn31_vpg.o
+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -mhard-float -maltivec
+endif
+
AMD_DAL_DCN31 = $(addprefix $(AMDDALPATH)/dc/dcn31/,$(DCN31))
AMD_DISPLAY_FILES += $(AMD_DAL_DCN31)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
index 59381d24800b..1395c1ced8c5 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
@@ -25,6 +25,10 @@
DCN315 = dcn315_resource.o
+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn315/dcn315_resource.o := -mhard-float -maltivec
+endif
+
AMD_DAL_DCN315 = $(addprefix $(AMDDALPATH)/dc/dcn315/,$(DCN315))
AMD_DISPLAY_FILES += $(AMD_DAL_DCN315)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
index 819d44a9439b..c3d2dd78f1e2 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
@@ -25,6 +25,10 @@
DCN316 = dcn316_resource.o
+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn316/dcn316_resource.o := -mhard-float -maltivec
+endif
+
AMD_DAL_DCN316 = $(addprefix $(AMDDALPATH)/dc/dcn316/,$(DCN316))
AMD_DISPLAY_FILES += $(AMD_DAL_DCN316)
Hi,
I don't want to re-introduce those FPU flags for DCN31/DCN314/DCN316 since we
fully isolate FPU operations for those ASICs inside the DML folder. Notice that
we have the PPC64 in the DML Makefile:
https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/dc/dml/Makefile
Yes, sure, ppc64 is in dc/dml/Makefile. The problem is that it selects
hard-float
ifdef CONFIG_PPC64
dml_ccflags := -mhard-float -maltivec
endif
and dc/{dcn31,dcn315,dcn316} don't.
Could you share what you see without your patch in the amd-staging-drm-next?
You mean linux-next ? Same error.
Building powerpc:allmodconfig ... failed
--
Error log:
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o uses hard
float, drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o uses
soft float
powerpc64-linux-ld: failed to merge target specific data of file
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o uses hard
float, drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o uses
soft float
powerpc64-linux-ld: failed to merge target specific data of file
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/
Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds
On Thu, Jun 30, 2022 at 05:01:01PM -0400, Rodrigo Siqueira Jordao wrote:
>
>
> On 2022-06-18 19:27, Guenter Roeck wrote:
> > ppc:allmodconfig builds fail with the following error.
> >
> > powerpc64-linux-ld:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> > uses hard float,
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
> > uses soft float
> > powerpc64-linux-ld:
> > failed to merge target specific data of file
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
> > powerpc64-linux-ld:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> > uses hard float,
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
> > uses soft float
> > powerpc64-linux-ld:
> > failed to merge target specific data of
> > file drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
> > powerpc64-linux-ld:
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> > uses hard float,
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
> > uses soft float
> > powerpc64-linux-ld:
> > failed to merge target specific data of file
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
> >
> > The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
> > 64-bit outline-only KASAN support") which adds support for KASAN. This
> > commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
> > KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
> > compiled which lack the selection of hard-float.
> >
> > Fixes: 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN support")
> > Cc: Michael Ellerman
> > Cc: Daniel Axtens
> > Signed-off-by: Guenter Roeck
> > ---
> > drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 4
> > drivers/gpu/drm/amd/display/dc/dcn315/Makefile | 4
> > drivers/gpu/drm/amd/display/dc/dcn316/Makefile | 4
> > 3 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> > b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> > index ec041e3cda30..74be02114ae4 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> > @@ -15,6 +15,10 @@ DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o
> > dcn31_init.o dcn31_hubp.o
> > dcn31_apg.o dcn31_hpo_dp_stream_encoder.o dcn31_hpo_dp_link_encoder.o \
> > dcn31_afmt.o dcn31_vpg.o
> > +ifdef CONFIG_PPC64
> > +CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -mhard-float -maltivec
> > +endif
> > +
> > AMD_DAL_DCN31 = $(addprefix $(AMDDALPATH)/dc/dcn31/,$(DCN31))
> > AMD_DISPLAY_FILES += $(AMD_DAL_DCN31)
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> > b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> > index 59381d24800b..1395c1ced8c5 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> > @@ -25,6 +25,10 @@
> > DCN315 = dcn315_resource.o
> > +ifdef CONFIG_PPC64
> > +CFLAGS_$(AMDDALPATH)/dc/dcn315/dcn315_resource.o := -mhard-float -maltivec
> > +endif
> > +
> > AMD_DAL_DCN315 = $(addprefix $(AMDDALPATH)/dc/dcn315/,$(DCN315))
> > AMD_DISPLAY_FILES += $(AMD_DAL_DCN315)
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> > b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> > index 819d44a9439b..c3d2dd78f1e2 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> > @@ -25,6 +25,10 @@
> > DCN316 = dcn316_resource.o
> > +ifdef CONFIG_PPC64
> > +CFLAGS_$(AMDDALPATH)/dc/dcn316/dcn316_resource.o := -mhard-float -maltivec
> > +endif
> > +
> > AMD_DAL_DCN316 = $(addprefix $(AMDDALPATH)/dc/dcn316/,$(DCN316))
> > AMD_DISPLAY_FILES += $(AMD_DAL_DCN316)
>
> Hi,
>
> I don't want to re-introduce those FPU flags for DCN31/DCN314/DCN316 since
> we fully isolate FPU operations for those ASICs inside the DML folder.
FWIW, I don't think that matters from a linking perspective since the hard-float
and the soft-float objects are linked together, and the linker bails out on
that because the ABIs are not compatible. You only get a warning on that unless
you build with -Werror, which is the case for allmodconfig builds.
Guenter
Re: [linux-next:master] BUILD REGRESSION 088b9c375534d905a4d337c78db3b3bfbb52c4a0
On Thu, Jul 07, 2022 at 10:08:33AM +0200, Greg KH wrote: [ ... ] > > > > Unverified Error/Warning (likely false positive, please contact us if > > interested): > > > > arch/x86/events/core.c:2114 init_hw_perf_events() warn: missing error code > > 'err' > > drivers/android/binder.c:1481:19-23: ERROR: from is NULL but dereferenced. > > drivers/android/binder.c:2920:29-33: ERROR: target_thread is NULL but > > dereferenced. > > drivers/android/binder.c:353:25-35: ERROR: node -> proc is NULL but > > dereferenced. > > drivers/android/binder.c:4888:16-20: ERROR: t is NULL but dereferenced. > > drivers/base/regmap/regmap.c:1996:1: internal compiler error: in arc_ifcvt, > > at config/arc/arc.c:9637 > > drivers/char/random.c:869:1: internal compiler error: in arc_ifcvt, at > > config/arc/arc.c:9637 > > drivers/firmware/arm_scmi/clock.c:394:1: internal compiler error: in > > arc_ifcvt, at config/arc/arc.c:9637 > > drivers/firmware/arm_scmi/powercap.c:376:1: internal compiler error: in > > arc_ifcvt, at config/arc/arc.c:9637 > > drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_powertune.c:1214:1: > > internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 > > drivers/gpu/drm/amd/display/dc/os_types.h: drm/drm_print.h is included more > > than once. > > drivers/gpu/drm/bridge/ite-it66121.c:1398:1: internal compiler error: in > > arc_ifcvt, at config/arc/arc.c:9637 > > drivers/greybus/operation.c:617:1: internal compiler error: in arc_ifcvt, > > at config/arc/arc.c:9637 > > > > When the compiler crashes, why are you blaming all of these different > mailing lists? Perhaps you need to fix your compiler :) > To be fair, it says above "likely false positive, please contact us if interested". Also, the 32-bit build errors _are_ real, and the NULL dereferences in the binder driver are at the very least suspicious. Guenter
Re: [PATCH v1 10/11] watchdog: bd9576_wdt: switch to using devm_fwnode_gpiod_get()
On 9/5/22 04:09, Andy Shevchenko wrote:
On Mon, Sep 5, 2022 at 9:33 AM Dmitry Torokhov
wrote:
I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
fwnode property API.
While at it switch the rest of the calls to read properties in
it, switch
bd9576_wdt_probe() to the generic device property API as well.
...
struct device *dev = &pdev->dev;
struct device *parent = dev->parent;
can make your code slightly neater.
...
+ count = device_property_count_u32(dev->parent, "rohm,hw-timeout-ms");
+ if (count < 0 && count != -EINVAL)
+ return count;
+
+ if (count > 0) {
+ if (count > ARRAY_SIZE(hw_margin))
+ return -EINVAL;
Why double check? You may move it out of the (count > 0).
Two checks will always be needed, so I don't entirely see
how that would be better.
...
- if (ret == 1)
- hw_margin_max = hw_margin[0];
+ ret = device_property_read_u32_array(dev->parent,
+"rohm,hw-timeout-ms",
+hw_margin, count);
+ if (ret < 0)
+ return ret;
So, only this needs the count > 0 check since below already has it implicitly.
Sorry, I don't understand this comment.
Guenter
- if (ret == 2) {
- hw_margin_max = hw_margin[1];
- hw_margin_min = hw_margin[0];
+ if (count == 1)
+ hw_margin_max = hw_margin[0];
+
+ if (count == 2) {
+ hw_margin_max = hw_margin[1];
+ hw_margin_min = hw_margin[0];
+ }
}
Re: [PATCH v1 10/11] watchdog: bd9576_wdt: switch to using devm_fwnode_gpiod_get()
On 9/5/22 08:21, Andy Shevchenko wrote:
On Mon, Sep 5, 2022 at 6:13 PM Guenter Roeck wrote:
On 9/5/22 04:09, Andy Shevchenko wrote:
On Mon, Sep 5, 2022 at 9:33 AM Dmitry Torokhov
wrote:
...
+ count = device_property_count_u32(dev->parent, "rohm,hw-timeout-ms");
+ if (count < 0 && count != -EINVAL)
+ return count;
+
+ if (count > 0) {
+ if (count > ARRAY_SIZE(hw_margin))
+ return -EINVAL;
Why double check? You may move it out of the (count > 0).
Two checks will always be needed, so I don't entirely see
how that would be better.
But not nested. That's my point:
if (count > ARRAY_SIZE())
return ...
if (count > 0)
...
The old code has either 1 or two checks if there is no error.
Your suggested code has always two checks. I don't see how that
is an improvement.
- if (ret == 1)
- hw_margin_max = hw_margin[0];
+ ret = device_property_read_u32_array(dev->parent,
+"rohm,hw-timeout-ms",
+hw_margin, count);
+ if (ret < 0)
+ return ret;
So, only this needs the count > 0 check since below already has it implicitly.
Sorry, I don't understand this comment.
if (count > 0) {
ret = device_property_read_u32_array(...);
...
}
if (count == 1)
...
if (count == 2)
...
But here it might be better to have the nested conditionals.
We know that count is either 1 or 2 here, so strictly speaking
if (count == 1) {
} else {
}
would be sufficient. On the other side, that depends on ARRAY_SIZE() being
exactly 2, so
if (count == 1) {
} else if (count == 2) {
}
would also make sense. Either way is fine with me. I'll leave it up
to Dmitry to decide what he wants to do.
Thanks,
Guenter
- if (ret == 2) {
- hw_margin_max = hw_margin[1];
- hw_margin_min = hw_margin[0];
+ if (count == 1)
+ hw_margin_max = hw_margin[0];
+
+ if (count == 2) {
+ hw_margin_max = hw_margin[1];
+ hw_margin_min = hw_margin[0];
+ }
}
Re: [PATCH v1 04/11] usb: phy: tegra: switch to using devm_gpiod_get()
On 9/5/22 12:55, Andy Shevchenko wrote: On Mon, Sep 5, 2022 at 10:51 PM Dmitry Torokhov wrote: On Mon, Sep 05, 2022 at 10:41:40PM +0300, Andy Shevchenko wrote: On Mon, Sep 5, 2022 at 10:40 PM Dmitry Torokhov wrote: On Mon, Sep 05, 2022 at 01:59:44PM +0300, Andy Shevchenko wrote: On Mon, Sep 5, 2022 at 9:32 AM Dmitry Torokhov wrote: ... - gpiod = devm_gpiod_get_from_of_node(&pdev->dev, np, - "nvidia,phy-reset-gpio", - 0, GPIOD_OUT_HIGH, - "ulpi_phy_reset_b"); + gpiod = devm_gpiod_get(&pdev->dev, "nvidia,phy-reset", + GPIOD_OUT_HIGH); err = PTR_ERR_OR_ZERO(gpiod); What does _OR_ZERO mean now? This converts a pointer to an error code if a pointer represents ERR_PTR() encoded error, or 0 to indicate success. Yes, I know that. My point is, how is it useful now (or even before)? I mean that devm_gpio_get() never returns NULL, right? What does returning NULL have to do with anything. It has to do with a dead code. If defm_gpiod_get() does not return NULL, then why do we even bother to check? PTR_ERR_OR_ZERO() converts into an error code (if the pointer is an ERR_PTR) or 0 if it is a real pointer. Its purpose is not to convert NULL into 0, its purpose is to convert a pointer either into an error code or 0. That is what is done here, and it is done all over the place in the kernel. I don't see your problem with it. Care to explain ? It converts a pointer to a "classic" return code, with negative errors and 0 on success. It allows to not use multiple IS_ERR/PTR_ERR in the code (I'd need 1 IS_ERR and 2 PTR_ERR, one in dev_err() and another to return). I don't see how this is relevant. You lost me. Really, please explain your problem with PTR_ERR_OR_ZERO(). Thanks, Guenter
Re: [PATCH v1 10/11] watchdog: bd9576_wdt: switch to using devm_fwnode_gpiod_get()
On 9/5/22 12:47, Dmitry Torokhov wrote:
[ ... ]
We know that count is either 1 or 2 here, so strictly speaking
if (count == 1) {
} else {
}
would be sufficient. On the other side, that depends on ARRAY_SIZE() being
exactly 2, so
if (count == 1) {
} else if (count == 2) {
}
would also make sense. Either way is fine with me. I'll leave it up
to Dmitry to decide what he wants to do.
My goal is to drop usage of devm_gpiod_get_from_of_node(), beyond that I
do not have strong preferences either way really. It is probing code, so
performance is not critical, but I'm obviously satisfied with how the
code looks now, or I would not have sent it.
Good point.
Reviewed-by: Guenter Roeck
Re: [PATCH 0/7] Add HWMON support
On 9/26/22 10:52, Badal Nilawar wrote: This series adds the HWMON support for DGFX Test-with: 20220919144408.251981-1-riana.ta...@intel.com v2: - Reorganized series. Created first patch as infrastructure patch followed by feature patches. (Ashutosh) - Fixed review comments (Jani) - Fixed review comments (Ashutosh) v3: - Fixed review comments from Guenter - Exposed energy inferface as standard hwmon interface (Ashutosh) - For power interface added entries for critical power and maintained standard interface for all the entries except power1_max_interval - Extended support for XEHPSDV (Ashutosh) v4: - Fixed review comment from Guenter - Cleaned up unused code v5: - Fixed review comments (Jani) v6: - Fixed review comments (Ashutosh) - Updated date and kernel version in documentation v7: - Fixed review comments (Anshuman) - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko) v8: s/hwmon_device_register_with_info/ devm_hwmon_device_register_with_info/ (Ashutosh) Is there some reason for not actually versioning this patch series ? Just wondering. Thanks, Guenter Ashutosh Dixit (2): drm/i915/hwmon: Expose card reactive critical power drm/i915/hwmon: Expose power1_max_interval Dale B Stimson (4): drm/i915/hwmon: Add HWMON infrastructure drm/i915/hwmon: Power PL1 limit and TDP setting drm/i915/hwmon: Show device level energy usage drm/i915/hwmon: Extend power/energy for XEHPSDV Riana Tauro (1): drm/i915/hwmon: Add HWMON current voltage support .../ABI/testing/sysfs-driver-intel-i915-hwmon | 75 ++ drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 + drivers/gpu/drm/i915/i915_driver.c| 5 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_hwmon.c | 736 ++ drivers/gpu/drm/i915/i915_hwmon.h | 20 + drivers/gpu/drm/i915/i915_reg.h | 6 + drivers/gpu/drm/i915/intel_mchbar_regs.h | 21 + 9 files changed, 876 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
[PATCH] drm/amd/display: Enable building new display engine with KCOV enabled
The new display engine uses floating point math, which is not supported
by KCOV. Commit 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov
is enabled") tried to work around the problem by disabling
CONFIG_DRM_AMD_DC_DCN if KCOV_INSTRUMENT_ALL and KCOV_ENABLE_COMPARISONS
are enabled. The result is that KCOV can not be enabled on systems which
require this display engine. A much simpler and less invasive solution is
to disable KCOV selectively when compiling the display enagine while
keeping it enabled for the rest of the kernel.
Fixes: 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov is enabled")
Cc: Arnd Bergmann
Cc: Leo Li
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/amd/display/Kconfig | 2 +-
drivers/gpu/drm/amd/display/dc/Makefile | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/Kconfig
b/drivers/gpu/drm/amd/display/Kconfig
index b4029c0d5d8c..96cbc87f7b6b 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -6,7 +6,7 @@ config DRM_AMD_DC
bool "AMD DC - Enable new display engine"
default y
select SND_HDA_COMPONENT if SND_HDA_CORE
- select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL &&
KCOV_ENABLE_COMPARISONS)
+ select DRM_AMD_DC_DCN if (X86 || PPC64)
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
diff --git a/drivers/gpu/drm/amd/display/dc/Makefile
b/drivers/gpu/drm/amd/display/dc/Makefile
index b4eca0236435..b801973749d2 100644
--- a/drivers/gpu/drm/amd/display/dc/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/Makefile
@@ -26,6 +26,9 @@
DC_LIBS = basics bios dml clk_mgr dce gpio irq link virtual
ifdef CONFIG_DRM_AMD_DC_DCN
+
+KCOV_INSTRUMENT := n
+
DC_LIBS += dcn20
DC_LIBS += dsc
DC_LIBS += dcn10
--
2.35.1
Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds
On 7/13/22 13:57, Alex Deucher wrote:
On Thu, Jun 30, 2022 at 5:01 PM Rodrigo Siqueira Jordao
wrote:
On 2022-06-18 19:27, Guenter Roeck wrote:
ppc:allmodconfig builds fail with the following error.
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
uses hard float,
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
uses soft float
powerpc64-linux-ld:
failed to merge target specific data of file
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
uses hard float,
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
uses soft float
powerpc64-linux-ld:
failed to merge target specific data of
file drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
powerpc64-linux-ld:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
uses hard float,
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
uses soft float
powerpc64-linux-ld:
failed to merge target specific data of file
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
64-bit outline-only KASAN support") which adds support for KASAN. This
commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
compiled which lack the selection of hard-float.
Fixes: 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN support")
Cc: Michael Ellerman
Cc: Daniel Axtens
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/amd/display/dc/dcn31/Makefile | 4
drivers/gpu/drm/amd/display/dc/dcn315/Makefile | 4
drivers/gpu/drm/amd/display/dc/dcn316/Makefile | 4
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
index ec041e3cda30..74be02114ae4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
@@ -15,6 +15,10 @@ DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o
dcn31_init.o dcn31_hubp.o
dcn31_apg.o dcn31_hpo_dp_stream_encoder.o dcn31_hpo_dp_link_encoder.o \
dcn31_afmt.o dcn31_vpg.o
+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -mhard-float -maltivec
+endif
+
AMD_DAL_DCN31 = $(addprefix $(AMDDALPATH)/dc/dcn31/,$(DCN31))
AMD_DISPLAY_FILES += $(AMD_DAL_DCN31)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
index 59381d24800b..1395c1ced8c5 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
@@ -25,6 +25,10 @@
DCN315 = dcn315_resource.o
+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn315/dcn315_resource.o := -mhard-float -maltivec
+endif
+
AMD_DAL_DCN315 = $(addprefix $(AMDDALPATH)/dc/dcn315/,$(DCN315))
AMD_DISPLAY_FILES += $(AMD_DAL_DCN315)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
index 819d44a9439b..c3d2dd78f1e2 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
@@ -25,6 +25,10 @@
DCN316 = dcn316_resource.o
+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn316/dcn316_resource.o := -mhard-float -maltivec
+endif
+
AMD_DAL_DCN316 = $(addprefix $(AMDDALPATH)/dc/dcn316/,$(DCN316))
AMD_DISPLAY_FILES += $(AMD_DAL_DCN316)
Hi,
I don't want to re-introduce those FPU flags for DCN31/DCN314/DCN316
since we fully isolate FPU operations for those ASICs inside the DML
I don't understand why we don't need to add the hard-float flags back
on the other DCN blocks. Did we miss something in the DML cleanup for
DCN 3.1.x? Anyway, at this point, the patch is:
Acked-by: Alex Deucher
We can sort the rest out for 5.20.
The problem is not the FPU operations, but the fact that soft-float
and hard-float compiled code is linked together. The soft-float and
hard-float ABIs on powerpc are not compatible, so one ends up with
an object file which is partially soft-float and partially hard-float
compiled and thus uses different ABIs. That can only create chaos,
so the linker complains about it.
Guenter
Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds
On Wed, Jul 13, 2022 at 05:20:40PM -0400, Alex Deucher wrote: [ ... ] > > The problem is not the FPU operations, but the fact that soft-float > > and hard-float compiled code is linked together. The soft-float and > > hard-float ABIs on powerpc are not compatible, so one ends up with > > an object file which is partially soft-float and partially hard-float > > compiled and thus uses different ABIs. That can only create chaos, > > so the linker complains about it. > > I get that, I just don't see why only DCN 3.1.x files have this > problem. The DCN 2.x files should as well. > No idea. Maybe ppc:allmodconfig only builds DCN 3.1.x, and other builds don't use -Werror and the warning is ignored. Guenter
Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds
On Wed, Jul 13, 2022 at 05:20:40PM -0400, Alex Deucher wrote: > > > > The problem is not the FPU operations, but the fact that soft-float > > and hard-float compiled code is linked together. The soft-float and > > hard-float ABIs on powerpc are not compatible, so one ends up with > > an object file which is partially soft-float and partially hard-float > > compiled and thus uses different ABIs. That can only create chaos, > > so the linker complains about it. > > I get that, I just don't see why only DCN 3.1.x files have this > problem. The DCN 2.x files should as well. > Seen in drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile: # prevent build errors regarding soft-float vs hard-float FP ABI tags # this code is currently unused on ppc64, as it applies to Renoir APUs only ifdef CONFIG_PPC64 CFLAGS_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := $(call cc-option,-mno-gnu-attribute) endif Does that explain it ? Guenter
Re: [PATCH] drm/amd/display: Enable building new display engine with KCOV enabled
On 7/14/22 09:29, Alex Deucher wrote:
Applied. Thanks!
On Wed, Jul 13, 2022 at 4:03 PM Harry Wentland wrote:
On 2022-07-12 18:42, Guenter Roeck wrote:
The new display engine uses floating point math, which is not supported
by KCOV. Commit 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov
is enabled") tried to work around the problem by disabling
CONFIG_DRM_AMD_DC_DCN if KCOV_INSTRUMENT_ALL and KCOV_ENABLE_COMPARISONS
are enabled. The result is that KCOV can not be enabled on systems which
require this display engine. A much simpler and less invasive solution is
to disable KCOV selectively when compiling the display enagine while
"enagine". Outch.
Anyway, thanks for applying.
Guenter
keeping it enabled for the rest of the kernel.
Fixes: 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov is enabled")
Cc: Arnd Bergmann
Cc: Leo Li
Signed-off-by: Guenter Roeck
Reviewed-by: Harry Wentland
Harry
---
drivers/gpu/drm/amd/display/Kconfig | 2 +-
drivers/gpu/drm/amd/display/dc/Makefile | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/Kconfig
b/drivers/gpu/drm/amd/display/Kconfig
index b4029c0d5d8c..96cbc87f7b6b 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -6,7 +6,7 @@ config DRM_AMD_DC
bool "AMD DC - Enable new display engine"
default y
select SND_HDA_COMPONENT if SND_HDA_CORE
- select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL &&
KCOV_ENABLE_COMPARISONS)
+ select DRM_AMD_DC_DCN if (X86 || PPC64)
help
Choose this option if you want to use the new display engine
support for AMDGPU. This adds required support for Vega and
diff --git a/drivers/gpu/drm/amd/display/dc/Makefile
b/drivers/gpu/drm/amd/display/dc/Makefile
index b4eca0236435..b801973749d2 100644
--- a/drivers/gpu/drm/amd/display/dc/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/Makefile
@@ -26,6 +26,9 @@
DC_LIBS = basics bios dml clk_mgr dce gpio irq link virtual
ifdef CONFIG_DRM_AMD_DC_DCN
+
+KCOV_INSTRUMENT := n
+
DC_LIBS += dcn20
DC_LIBS += dsc
DC_LIBS += dcn10
Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds
On 7/14/22 11:49, Melissa Wen wrote: O 07/13, Alex Deucher wrote: On Wed, Jul 13, 2022 at 7:09 PM Guenter Roeck wrote: On Wed, Jul 13, 2022 at 05:20:40PM -0400, Alex Deucher wrote: The problem is not the FPU operations, but the fact that soft-float and hard-float compiled code is linked together. The soft-float and hard-float ABIs on powerpc are not compatible, so one ends up with an object file which is partially soft-float and partially hard-float compiled and thus uses different ABIs. That can only create chaos, so the linker complains about it. I get that, I just don't see why only DCN 3.1.x files have this problem. The DCN 2.x files should as well. Seen in drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile: # prevent build errors regarding soft-float vs hard-float FP ABI tags # this code is currently unused on ppc64, as it applies to Renoir APUs only ifdef CONFIG_PPC64 CFLAGS_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := $(call cc-option,-mno-gnu-attribute) endif Does that explain it ? I would expect to see it in dcn20_resource.c and dcn30_clk_mgr.c for example. They follow the same pattern as the dcn 3.1.x files. They call functions that use FP, but maybe there is some FP code still in those functions that we missed somehow. Hi, I'm a little late here, but I'm not able to reproduce the issue yet. I have this setup: - gcc 11.3.0 - binutils 2.38.50 - mainline kernel (torvalds) version: 5.19.0-rc6 (cross-compiling) -> make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- allmodconfig => DRM_AMD_DC [=y] && HAS_IOMEM [=y] && DRM [=m] && DRM_AMDGPU [=m] && (X86 || PPC64 [=y]) && (!KCOV_INSTRUMENT_ALL [=n] || !KCOV_ENABLE_COMPARISONS [=n]) -> make -j16 ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- Am I missing something? So, as Alex mentioned the possibility of some non-isolated FPU code in 3.1, I reviewed dcn31 code and my best bet so far is that the issue is here: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c#L1721 Although dcn31_update_soc_for_wm_a() is only called inside dml/dcn31/dcn31_fpu: - dc->res_pool->funcs->update_soc_for_wm_a(dc, context); it's declared in dcn31_resource and has FPU code. So, we should move it to dml/dcn31/dcn31_fpu. However, as I can't reproduce the issue, I don't know if it addresses the problem reported here and also if everything will be clean after moving it. I don't think that would solve anything. As I have tried to point out, the problem is that code compiled with hard-float is linked together with code compiled with soft-float. An alternate fix might be something like the one attached below, but I don't know if that would be correct and/or complete. Guenter, Can you provide more info about your setup: cross-compile or not, any flags, branch, etc? Nothing special. Same compile options as the ones you use, and it is a cross-compile environment. I tried gcc 11.2.0 with binutils 2.36.1 and gcc 11.3.0 with binutils 2.38. Guenter --- diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile index ec041e3cda30..44ff6f196860 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile @@ -10,6 +10,8 @@ # # Makefile for dcn31. +CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := $(call cc-option,-mno-gnu-attribute) + DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o dcn31_init.o dcn31_hubp.o \ dcn31_dccg.o dcn31_optc.o dcn31_dio_link_encoder.o dcn31_panel_cntl.o \ dcn31_apg.o dcn31_hpo_dp_stream_encoder.o dcn31_hpo_dp_link_encoder.o \ diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile index 59381d24800b..55fcae2d2aae 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile @@ -25,6 +25,8 @@ DCN315 = dcn315_resource.o +CFLAGS_$(AMDDALPATH)/dc/dcn315/$(DCN315) := $(call cc-option,-mno-gnu-attribute) + AMD_DAL_DCN315 = $(addprefix $(AMDDALPATH)/dc/dcn315/,$(DCN315)) AMD_DISPLAY_FILES += $(AMD_DAL_DCN315) diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile index 819d44a9439b..7251ef9c1afb 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile +++ b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile @@ -25,6 +25,8 @@ DCN316 = dcn316_resource.o +CFLAGS_$(AMDDALPATH)/dc/dcn316/$(DCN316) := $(call cc-option,-mno-gnu-attribute) + AMD_DAL_DCN316 = $(addprefix $(AMDDALPATH)/dc/dcn316/,$(DCN316)) AMD_DISPLAY_FILES += $(AMD_DAL_DCN316)
Re: [PATCH v5 4/9] drm: selftest: convert drm_format selftest to KUnit
On Fri, Jul 08, 2022 at 05:30:47PM -0300, Maíra Canal wrote: > Considering the current adoption of the KUnit framework, convert the > DRM format selftest to the KUnit API. > > Tested-by: David Gow > Acked-by: Daniel Latypov > Reviewed-by: Javier Martinez Canillas > Signed-off-by: Maíra Canal This patch results in: Building powerpc:allmodconfig ... failed -- Error log: drivers/gpu/drm/tests/drm_format_test.c: In function 'igt_check_drm_format_min_pitch': drivers/gpu/drm/tests/drm_format_test.c:271:1: error: the frame size of 3712 bytes is larger than 2048 bytes presumably due to function nesting. Guenter
Re: [PATCH v5 4/9] drm: selftest: convert drm_format selftest to KUnit
On Thu, Jul 14, 2022 at 04:51:40PM -0700, Guenter Roeck wrote: > On Fri, Jul 08, 2022 at 05:30:47PM -0300, Maíra Canal wrote: > > Considering the current adoption of the KUnit framework, convert the > > DRM format selftest to the KUnit API. > > > > Tested-by: David Gow > > Acked-by: Daniel Latypov > > Reviewed-by: Javier Martinez Canillas > > Signed-off-by: Maíra Canal > > This patch results in: > > Building powerpc:allmodconfig ... failed > -- > Error log: > drivers/gpu/drm/tests/drm_format_test.c: In function > 'igt_check_drm_format_min_pitch': > drivers/gpu/drm/tests/drm_format_test.c:271:1: error: the frame size of 3712 > bytes is larger than 2048 bytes > Also seen with i386:allyesconfig: drivers/gpu/drm/tests/drm_format_test.c: In function 'igt_check_drm_format_min_pitch': drivers/gpu/drm/tests/drm_format_test.c:271:1: error: the frame size of 2572 bytes is larger than 2048 bytes Guenter
Re: [v3] drm/i915/ttm: fix sg_table construction
On Mon, Jul 11, 2022 at 09:58:59AM +0100, Matthew Auld wrote:
> If we encounter some monster sized local-memory page that exceeds the
> maximum sg length (UINT32_MAX), ensure that don't end up with some
> misaligned address in the entry that follows, leading to fireworks
> later. Also ensure we have some coverage of this in the selftests.
>
> v2(Chris):
> - Use round_down consistently to avoid udiv errors
> v3(Nirmoy):
> - Also update the max_segment in the selftest
>
> Fixes: f701b16d4cc5 ("drm/i915/ttm: add i915_sg_from_buddy_resource")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6379
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> Cc: Nirmoy Das
> Reviewed-by: Nirmoy Das
Building i386:defconfig ... failed
--
Error log:
x86_64-linux-ld: drivers/gpu/drm/i915/i915_scatterlist.o: in function
`i915_rsgt_from_mm_node':
i915_scatterlist.c:(.text+0x196): undefined reference to `__udivdi3'
Bisect log attached.
Guenter
---
# bad: [9b59ec8d50a1f28747ceff9a4f39af5deba9540e] Merge tag
'riscv-for-linus-5.19-rc7' of
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
# good: [e5d523f1ae8f2cef01f8e071aeee432654166708] ubsan: disable
UBSAN_DIV_ZERO for clang
git bisect start 'HEAD' 'e5d523f1ae8f'
# bad: [2a347a06ebb1b186a5cb919c9f5ab6e040554be7] Merge tag
'platform-drivers-x86-v5.19-4' of
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
git bisect bad 2a347a06ebb1b186a5cb919c9f5ab6e040554be7
# bad: [093f8d8f10aa22935bc8bf7100700f714ebaba9c] Merge tag
'amd-drm-fixes-5.19-2022-07-13' of https://gitlab.freedesktop.org/agd5f/linux
into drm-fixes
git bisect bad 093f8d8f10aa22935bc8bf7100700f714ebaba9c
# bad: [ad765fae792e16ce3c1d0b69ce939e3f7dba40ab] drm/i915/gem: Look for
waitboosting across the whole object prior to individual waits
git bisect bad ad765fae792e16ce3c1d0b69ce939e3f7dba40ab
# good: [f99546298a4537965b75d518c210742f641be389] Merge tag
'gvt-fixes-2022-07-11' of https://github.com/intel/gvt-linux into
drm-intel-fixes
git bisect good f99546298a4537965b75d518c210742f641be389
# bad: [aff1e0b09b54b64944b7fe32997229552737b9e9] drm/i915/ttm: fix sg_table
construction
git bisect bad aff1e0b09b54b64944b7fe32997229552737b9e9
# good: [896dcabd1f8f613c533d948df17408c41f8929f5] drm/i915/selftests: fix a
couple IS_ERR() vs NULL tests
git bisect good 896dcabd1f8f613c533d948df17408c41f8929f5
# first bad commit: [aff1e0b09b54b64944b7fe32997229552737b9e9] drm/i915/ttm:
fix sg_table construction
[PATCH] drm/i915: Fix 32-bit build
Commit aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction") introduces
an additional parameter to i915_rsgt_from_mm_node(). The parameter is used
to calculate segment_pages. This in turn is used in DIV_ROUND_UP() as
divisor. So far segment_pages was a constant and handled without divide
operation. Since it is no longer constant, a divide operation is now
necessary. This results in build errors on 32-bit builds.
x86_64-linux-ld: drivers/gpu/drm/i915/i915_scatterlist.o:
in function `i915_rsgt_from_mm_node':
i915_scatterlist.c:(.text+0x196): undefined reference to `__udivdi3'
Fix the problem by using DIV_ROUND_UP_ULL() instead of DIV_ROUND_UP().
Fixes: aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction")
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Rodrigo Vivi
Signed-off-by: Guenter Roeck
---
I took a stab at the problem. Please ignore the noise if it has already
been fixed with a different patch.
drivers/gpu/drm/i915/i915_scatterlist.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
b/drivers/gpu/drm/i915/i915_scatterlist.c
index f63b50b71e10..b81d5658c222 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -96,7 +96,7 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct
drm_mm_node *node,
i915_refct_sgt_init(rsgt, node->size << PAGE_SHIFT);
st = &rsgt->table;
- if (sg_alloc_table(st, DIV_ROUND_UP(node->size, segment_pages),
+ if (sg_alloc_table(st, DIV_ROUND_UP_ULL(node->size, segment_pages),
GFP_KERNEL)) {
i915_refct_sgt_put(rsgt);
return ERR_PTR(-ENOMEM);
--
2.36.2
Re: [PATCH] drm/tests: Split up test cases in igt_check_drm_format_min_pitch
On 7/17/22 11:43, Maíra Canal wrote:
The igt_check_drm_format_min_pitch() function had a lot of
KUNIT_EXPECT_* calls, all of which ended up allocating and initializing
various test assertion structures on the stack.
This behavior was producing -Wframe-larger-than warnings on PowerPC, i386,
and MIPS architectures, such as:
drivers/gpu/drm/tests/drm_format_test.c: In function
'igt_check_drm_format_min_pitch':
drivers/gpu/drm/tests/drm_format_test.c:271:1: error: the frame size of
3712 bytes is larger than 2048 bytes
So, the igt_check_drm_format_min_pitch() test case was split into three
smaller functions: one testing single plane formats, one testing multiple
planes formats, and the other testing tiled formats.
Reported-by: kernel test robot
Reported-by: Guenter Roeck
Signed-off-by: Maíra Canal
I applied the patch to next-20220714 (the fixed file is gone
in next-20220715) and tested with i386, ppc, and mips compilers.
The problem is no longer seen after this patch is applied.
Tested-by: Guenter Roeck
Guenter
---
drivers/gpu/drm/tests/drm_format_test.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_format_test.c
b/drivers/gpu/drm/tests/drm_format_test.c
index 056cb8599d6d..28f2b8f88818 100644
--- a/drivers/gpu/drm/tests/drm_format_test.c
+++ b/drivers/gpu/drm/tests/drm_format_test.c
@@ -91,7 +91,7 @@ static void igt_check_drm_format_block_height(struct kunit
*test)
KUNIT_EXPECT_FALSE(test, drm_format_info_block_height(info, -1));
}
-static void igt_check_drm_format_min_pitch(struct kunit *test)
+static void igt_check_drm_format_min_pitch_for_single_plane(struct kunit *test)
{
const struct drm_format_info *info = NULL;
@@ -175,6 +175,11 @@ static void igt_check_drm_format_min_pitch(struct kunit *test)
(uint64_t)UINT_MAX * 4);
KUNIT_EXPECT_EQ(test, drm_format_info_min_pitch(info, 0, (UINT_MAX -
1)),
(uint64_t)(UINT_MAX - 1) * 4);
+}
+
+static void igt_check_drm_format_min_pitch_for_multiple_planes(struct kunit
*test)
+{
+ const struct drm_format_info *info = NULL;
/* Test 2 planes format */
info = drm_format_info(DRM_FORMAT_NV12);
@@ -249,6 +254,11 @@ static void igt_check_drm_format_min_pitch(struct kunit
*test)
(uint64_t)(UINT_MAX - 1) / 2);
KUNIT_EXPECT_EQ(test, drm_format_info_min_pitch(info, 2, (UINT_MAX - 1)
/ 2),
(uint64_t)(UINT_MAX - 1) / 2);
+}
+
+static void igt_check_drm_format_min_pitch_for_tiled_format(struct kunit *test)
+{
+ const struct drm_format_info *info = NULL;
/* Test tiled format */
info = drm_format_info(DRM_FORMAT_X0L2);
@@ -273,7 +283,9 @@ static void igt_check_drm_format_min_pitch(struct kunit
*test)
static struct kunit_case drm_format_tests[] = {
KUNIT_CASE(igt_check_drm_format_block_width),
KUNIT_CASE(igt_check_drm_format_block_height),
- KUNIT_CASE(igt_check_drm_format_min_pitch),
+ KUNIT_CASE(igt_check_drm_format_min_pitch_for_single_plane),
+ KUNIT_CASE(igt_check_drm_format_min_pitch_for_multiple_planes),
+ KUNIT_CASE(igt_check_drm_format_min_pitch_for_tiled_format),
{ }
};
Re: [PATCH v6 08/13] usb: typec: tcpci_mt6370: Add MediaTek MT6370 tcpci driver
On 7/22/22 03:24, ChiaEn Wu wrote:
From: ChiYuan Huang
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual
Flash LED current sources, a RGB LED driver, a backlight WLED driver,
a display bias driver and a general LDO for portable devices.
Add support for the Type-C & Power Delivery controller in
MediaTek MT6370 IC.
Signed-off-by: ChiYuan Huang
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Guenter Roeck
---
v6
- Convert tcpci as device resource managed with 'devm_add_action_or_reset' API.
- Refine remvoe callback.
- Refine the commit text from 'This commit add' to 'Add'.
---
drivers/usb/typec/tcpm/Kconfig| 11 ++
drivers/usb/typec/tcpm/Makefile | 1 +
drivers/usb/typec/tcpm/tcpci_mt6370.c | 208 ++
3 files changed, 220 insertions(+)
create mode 100644 drivers/usb/typec/tcpm/tcpci_mt6370.c
diff --git a/drivers/usb/typec/tcpm/Kconfig b/drivers/usb/typec/tcpm/Kconfig
index 073fd2e..e6b88ca 100644
--- a/drivers/usb/typec/tcpm/Kconfig
+++ b/drivers/usb/typec/tcpm/Kconfig
@@ -35,6 +35,17 @@ config TYPEC_MT6360
USB Type-C. It works with Type-C Port Controller Manager
to provide USB PD and USB Type-C functionalities.
+config TYPEC_TCPCI_MT6370
+ tristate "MediaTek MT6370 Type-C driver"
+ depends on MFD_MT6370
+ help
+ MediaTek MT6370 is a multi-functional IC that includes
+ USB Type-C. It works with Type-C Port Controller Manager
+ to provide USB PD and USB Type-C functionalities.
+
+ This driver can also be built as a module. The module
+ will be called "tcpci_mt6370".
+
config TYPEC_TCPCI_MAXIM
tristate "Maxim TCPCI based Type-C chip driver"
help
diff --git a/drivers/usb/typec/tcpm/Makefile b/drivers/usb/typec/tcpm/Makefile
index 7d499f3..906d9dc 100644
--- a/drivers/usb/typec/tcpm/Makefile
+++ b/drivers/usb/typec/tcpm/Makefile
@@ -6,4 +6,5 @@ typec_wcove-y := wcove.o
obj-$(CONFIG_TYPEC_TCPCI) += tcpci.o
obj-$(CONFIG_TYPEC_RT1711H) += tcpci_rt1711h.o
obj-$(CONFIG_TYPEC_MT6360)+= tcpci_mt6360.o
+obj-$(CONFIG_TYPEC_TCPCI_MT6370) += tcpci_mt6370.o
obj-$(CONFIG_TYPEC_TCPCI_MAXIM) += tcpci_maxim.o
diff --git a/drivers/usb/typec/tcpm/tcpci_mt6370.c
b/drivers/usb/typec/tcpm/tcpci_mt6370.c
new file mode 100644
index 000..4f53319
--- /dev/null
+++ b/drivers/usb/typec/tcpm/tcpci_mt6370.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2022 Richtek Technology Corp.
+ *
+ * Author: ChiYuan Huang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "tcpci.h"
+
+#define MT6370_REG_SYSCTRL80x9B
+
+#define MT6370_AUTOIDLE_MASK BIT(3)
+
+#define MT6370_VENDOR_ID 0x29CF
+#define MT6370_TCPC_DID_A 0x2170
+
+struct mt6370_priv {
+ struct device *dev;
+ struct regulator *vbus;
+ struct tcpci *tcpci;
+ struct tcpci_data tcpci_data;
+};
+
+static const struct reg_sequence mt6370_reg_init[] = {
+ REG_SEQ(0xA0, 0x1, 1000),
+ REG_SEQ(0x81, 0x38, 0),
+ REG_SEQ(0x82, 0x82, 0),
+ REG_SEQ(0xBA, 0xFC, 0),
+ REG_SEQ(0xBB, 0x50, 0),
+ REG_SEQ(0x9E, 0x8F, 0),
+ REG_SEQ(0xA1, 0x5, 0),
+ REG_SEQ(0xA2, 0x4, 0),
+ REG_SEQ(0xA3, 0x4A, 0),
+ REG_SEQ(0xA4, 0x01, 0),
+ REG_SEQ(0x95, 0x01, 0),
+ REG_SEQ(0x80, 0x71, 0),
+ REG_SEQ(0x9B, 0x3A, 1000),
+};
+
+static int mt6370_tcpc_init(struct tcpci *tcpci, struct tcpci_data *data)
+{
+ u16 did;
+ int ret;
+
+ ret = regmap_register_patch(data->regmap, mt6370_reg_init,
+ ARRAY_SIZE(mt6370_reg_init));
+ if (ret)
+ return ret;
+
+ ret = regmap_raw_read(data->regmap, TCPC_BCD_DEV, &did, sizeof(u16));
+ if (ret)
+ return ret;
+
+ if (did == MT6370_TCPC_DID_A)
+ return regmap_write(data->regmap, TCPC_FAULT_CTRL, 0x80);
+
+ return 0;
+}
+
+static int mt6370_tcpc_set_vconn(struct tcpci *tcpci, struct tcpci_data *data,
+bool enable)
+{
+ return regmap_update_bits(data->regmap, MT6370_REG_SYSCTRL8,
+ MT6370_AUTOIDLE_MASK,
+ !enable ? MT6370_AUTOIDLE_MASK : 0);
+}
+
+static int mt6370_tcpc_set_vbus(struct tcpci *tcpci, struct tcpci_data *data,
+ bool source, bool sink)
+{
+ struct mt6370_priv *priv = container_of(data, struct mt6370_priv,
+ tcpci_data);
+ int ret;
+
+
Re: Stack-frame warnings in display_mode_vba_32.c
On 7/29/22 22:12, Paul E. McKenney wrote: On Fri, Jul 29, 2022 at 11:41:55PM -0300, André Almeida wrote: Hi Paul, Às 23:25 de 29/07/22, Paul E. McKenney escreveu: Hello! I am seeing the following in allmodconfig builds of recent -next on x86: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c: In function ‘DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerformanceCalculation’: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:1659:1: error: the frame size of 2144 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] 1659 | } | ^ drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c: In function ‘dml32_ModeSupportAndSystemConfigurationFull’: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c:3799:1: error: the frame size of 2480 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] 3799 | } // ModeSupportAndSystemConfigurationFull | ^ I think they are fixed at amd-staging-drm-next: git log --oneline amd/amd-staging-drm-next drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c 953daa61981b drm/amd/display: Reduce stack size in the mode support function 361e705e712d drm/amd/display: reduce stack for dml32_CalculatePrefetchSchedule f2dbf5a4dd1e drm/amd/display: reduce stack for dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport a0a68cda2ef8 drm/amd/display: reduce stack for dml32_CalculateVMRowAndSwath ca6730ca0f01 drm/amd/display: reduce stack for dml32_CalculateSwathAndDETConfiguration 593eef8c1a5e drm/amd/display: reduce stack size in dcn32 dml (v2) https://gitlab.freedesktop.org/agd5f/linux/-/commits/amd-staging-drm-next/drivers/gpu/drm/amd/display/dc/dml/dcn32/display_mode_vba_32.c Very good, thank you! I will test again on the next -next. Did you try next-20220728 ? groeck@server:~/src/linux-next$ git describe next-20220728 groeck@server:~/src/linux-next$ git log --oneline drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_32.c 1b54a0121dba drm/amd/display: Reduce stack size in the mode support function 86e4863e67a9 drm/amd/display: reduce stack for dml32_CalculatePrefetchSchedule 3c3abac60117 drm/amd/display: reduce stack for dml32_CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport c3b3f9ba25e6 drm/amd/display: reduce stack for dml32_CalculateVMRowAndSwath bac4b41d917a drm/amd/display: reduce stack for dml32_CalculateSwathAndDETConfiguration 7acc487ab57e drm/amd/display: reduce stack size in dcn32 dml (v2) Guenter
Re: [v5,3/3] drm/i915: Add support for integrated privacy screens
On Fri, Dec 20, 2019 at 12:03:53PM -0800, Rajat Jain wrote:
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the intel_connector for the panel, that
> the userspace can then use to control and check the status.
>
> Identifying the presence of privacy screen, and controlling it, is done
> via ACPI _DSM methods.
>
> Currently, this is done only for the Intel display ports. But in future,
> this can be done for any other ports if the hardware becomes available
> (e.g. external monitors supporting integrated privacy screens?).
>
> Signed-off-by: Rajat Jain
> ---
> v5: fix a cosmetic checkpatch warning
> v4: Fix a typo in intel_privacy_screen.h
> v3: * Change license to GPL-2.0 OR MIT
> * Move privacy screen enum from UAPI to intel_display_types.h
> * Rename parameter name and some other minor changes.
> v2: Formed by splitting the original patch into multiple patches.
> - All code has been moved into i915 now.
> - Privacy screen is a i915 property
> - Have a local state variable to store the prvacy screen. Don't read
> it from hardware.
>
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/display/intel_atomic.c | 13 +++-
> .../gpu/drm/i915/display/intel_connector.c| 35 +
> .../gpu/drm/i915/display/intel_connector.h| 1 +
> .../drm/i915/display/intel_display_types.h| 18 +
> drivers/gpu/drm/i915/display/intel_dp.c | 6 ++
> .../drm/i915/display/intel_privacy_screen.c | 72 +++
> .../drm/i915/display/intel_privacy_screen.h | 27 +++
> 8 files changed, 171 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 90dcf09f52cc..f7067c8f0407 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -197,7 +197,8 @@ i915-y += \
> display/intel_vga.o
> i915-$(CONFIG_ACPI) += \
> display/intel_acpi.o \
> - display/intel_opregion.o
> + display/intel_opregion.o \
> + display/intel_privacy_screen.o
> i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
> display/intel_fbdev.o
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index c2875b10adf9..c73b81c4c3f6 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -37,6 +37,7 @@
> #include "intel_atomic.h"
> #include "intel_display_types.h"
> #include "intel_hdcp.h"
> +#include "intel_privacy_screen.h"
> #include "intel_sprite.h"
>
> /**
> @@ -57,11 +58,14 @@ int intel_digital_connector_atomic_get_property(struct
> drm_connector *connector,
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_digital_connector_state *intel_conn_state =
> to_intel_digital_connector_state(state);
> + struct intel_connector *intel_connector = to_intel_connector(connector);
>
> if (property == dev_priv->force_audio_property)
> *val = intel_conn_state->force_audio;
> else if (property == dev_priv->broadcast_rgb_property)
> *val = intel_conn_state->broadcast_rgb;
> + else if (property == intel_connector->privacy_screen_property)
> + *val = intel_conn_state->privacy_screen_status;
> else {
> DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
>property->base.id, property->name);
> @@ -89,15 +93,18 @@ int intel_digital_connector_atomic_set_property(struct
> drm_connector *connector,
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_digital_connector_state *intel_conn_state =
> to_intel_digital_connector_state(state);
> + struct intel_connector *intel_connector = to_intel_connector(connector);
>
> if (property == dev_priv->force_audio_property) {
> intel_conn_state->force_audio = val;
> return 0;
> - }
> -
> - if (property == dev_priv->broadcast_rgb_property) {
> + } else if (property == dev_priv->broadcast_rgb_property) {
> intel_conn_state->broadcast_rgb = val;
> return 0;
> + } else if (property == intel_connector->privacy_screen_property) {
> + intel_privacy_screen_set_val(intel_connector, val);
> + intel_conn_state->privacy_screen_status = val;
> + return 0;
> }
>
> DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
> b/drivers/gpu/drm/i915/display/intel_connector.c
> index 1133c4e97bb4..f3e041c737de 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.c
> +++ b/drivers/gpu/drm/i91
Re: [PATCH v2 2/2] drm/bridge: add it6505 driver
Hi, On Tue, Sep 03, 2019 at 06:51:54PM +0800, allen wrote: > From: Allen Chen > > This adds support for the iTE IT6505. > This device can convert DPI signal to DP output. > > Signed-off-by: Jitao Shi > Signed-off-by: Yilun Lin > Signed-off-by: Allen Chen I tried to provide feedback on this patch, but it is far from compiling against the upstream kernel (or -next), and it has a number of obvious problems such as missing include files, variable type mismatches, and set but unused variables. It does compile against v4.19.y, but even there it generates a number of build warnings. I would suggest to fix those problems and to make sure that the driver builds without warnings on top of the mainline kernel before resubmitting. Thanks, Guenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp_mst: Fix build on systems with STACKTRACE_SUPPORT=n
On systems with STACKTRACE_SUPPORT=n, we get:
WARNING: unmet direct dependencies detected for STACKTRACE
Depends on [n]: STACKTRACE_SUPPORT
Selected by [y]:
- STACKDEPOT [=y]
and build errors such as:
m68k-linux-ld: kernel/stacktrace.o: in function `stack_trace_save':
(.text+0x11c): undefined reference to `save_stack_trace'
Add the missing deendency on STACKTRACE_SUPPORT.
Fixes: 12a280c72868 ("drm/dp_mst: Add topology ref history tracking for
debugging")
Cc: Lyude Paul
Cc: Sean Paul
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1168351267fd..bfdadc3667e0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -95,6 +95,7 @@ config DRM_KMS_FB_HELPER
config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
bool "Enable refcount backtrace history in the DP MST helpers"
+ depends on STACKTRACE_SUPPORT
select STACKDEPOT
depends on DRM_KMS_HELPER
depends on DEBUG_KERNEL
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 19/24] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory
On Fri, Jul 26, 2019 at 07:23:13PM +0200, Andrzej Pietrasiewicz wrote: > Use the ddc pointer provided by the generic connector. > > Signed-off-by: Andrzej Pietrasiewicz > Reviewed-by: Neil Armstrong This patch results in a crash when running qemu:versatilepb. Unable to handle kernel NULL pointer dereference at virtual address 00c5 pgd = (ptrval) [00c5] *pgd= Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.3.0-rc1+ #1 Hardware name: ARM-Versatile (Device Tree Support) PC is at sysfs_do_create_link_sd+0x38/0xd8 LR is at sysfs_do_create_link_sd+0x38/0xd8 pc : []lr : []psr: a153 sp : c783bd18 ip : fp : c783bde8 r10: c7ef5ea8 r9 : 0001 r8 : c0955dc0 r7 : c73cb5b0 r6 : c73cd800 r5 : 00ad r4 : r3 : c7838ae0 r2 : r1 : 0008 r0 : c0aa2898 Flags: NzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none Control: 00093177 Table: 4000 DAC: 0053 Process swapper (pid: 1, stack limit = 0x(ptrval)) Stack: (0xc783bd18 to 0xc783c000) bd00: c73ccc48 c73ccc74 bd20: c73cd800 c0ac7c88 c729cc80 c7ef5ea8 c04c7fc0 c73ccc48 c0a73068 bd40: c73cd800 c0ac7c88 c04c87e0 0001 c04cefcc c04dc3f8 bd60: c73a9030 c73cd800 c73ccc48 7fc2ce37 c73cd800 c04cefcc bd80: c73cd800 c04b4ebc c0a73068 c7ef5ea8 c783bde8 c049ffcc bda0: c73a9020 c73cd800 c78e6000 c73a9020 c73a9020 c0a73068 c04df2f8 bdc0: c783bde8 c095a76c c73a9020 c0065744 c73ccc20 c73a9020 0001 bde0: c7838ae0 c73ccc20 7fc2ce37 c78e6000 c0ac7c34 be00: c07dc1f8 c0a6b384 c0a59858 c045e8d8 c78e6000 c1173a78 be20: c0ac7c34 c04e77c4 c78e6000 c0ac7c34 c0ac7c34 c0a73068 be40: e000 c0a6b384 c04e7a34 c0ac7c34 c0ac7c34 c0a73068 c78e6000 be60: c0ac7c34 c0a73068 e000 c0a6b384 c0a59858 c04e7cf0 be80: c0ac7c34 c78e6000 c04e7d7c c0ac7c34 c04e7cf8 c04e5928 bea0: c73b2800 c78d88a0 c78dd110 7fc2ce37 e000 c0ac7c34 c73b2800 c0ac16e0 bec0: c04e6b28 c095a73c c0af0a60 c0a73068 c0ac7c34 c0af0a60 c0a73068 bee0: c0a401c4 c04e8968 e000 c0af0a60 c0a73068 c000b3bc 0115 bf00: c7ffce6c c7ffce00 c09e15b0 0115 0115 c0048844 c09e000c c097cfd4 bf20: 0006 0006 c7ffce6c e000 c006954c bf40: e000 7fc2ce37 c0afb000 c0af0a60 0115 c0afb000 0007 c0a59850 bf60: e000 c0a111e8 0006 0006 c0a10678 7fc2ce37 bf80: c07824cc bfa0: c07824d4 c00090b0 bfc0: bfe0: 0013 [] (sysfs_do_create_link_sd) from [] (drm_connector_register.part.1+0x40/0xa0) [] (drm_connector_register.part.1) from [] (drm_connector_register_all+0x90/0xb8) [] (drm_connector_register_all) from [] (drm_modeset_register_all+0x44/0x6c) [] (drm_modeset_register_all) from [] (drm_dev_register+0x15c/0x1c0) [] (drm_dev_register) from [] (pl111_amba_probe+0x2e0/0x4ac) [] (pl111_amba_probe) from [] (amba_probe+0x9c/0x118) [] (amba_probe) from [] (really_probe+0x1c0/0x2bc) [] (really_probe) from [] (driver_probe_device+0x5c/0x170) [] (driver_probe_device) from [] (device_driver_attach+0x58/0x60) [] (device_driver_attach) from [] (__driver_attach+0x84/0xc0) [] (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4) [] (bus_for_each_dev) from [] (bus_add_driver+0x154/0x1e0) [] (bus_add_driver) from [] (driver_register+0x74/0x108) [] (driver_register) from [] (do_one_initcall+0x84/0x2e4) [] (do_one_initcall) from [] (kernel_init_freeable+0x2bc/0x394) [] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0) [] (kernel_init) from [] (ret_from_fork+0x14/0x24) Exception stack(0xc783bfb0 to 0xc783bff8) bfa0: bfc0: bfe0: 0013 Code: e59f00a0 e1a09003 e1a08002 eb176e54 (e5955018) ---[ end trace f503b374936886c5 ]--- Bisect log attached. Guenter --- # bad: [3880be629e26f6c407593602398c6651860d5fae] Add linux-next specific files for 20190807 # good: [e21a712a9685488f5ce80495b37b9fdbe96c230d] Linux 5.3-rc3 git bisect start 'HEAD' 'v5.3-rc3' # good: [83d74da9e6d2ca78b32e9e794c6bcbd433d5efaa] Merge remote-tracking branch 'crypto/master' git bisect good 83d74da9e6d2ca78b32e9e794c6bcbd433d5efaa # bad: [3add021bff629f1792a5e4268afe13b3047b5523] Merge remote-tracking branch 'sound/for-next' git bisect bad 3add021bff629f1792a5e4268afe13b3047b5523 # good: [4ef58ee18a654b1992d00281501d6eff051a0c5e] Merge remote-tracking branch 'amdgpu/drm-next' gi
Re: next/master build: 230 builds: 5 failed, 225 passed, 6 errors, 1344 warnings (next-20190805)
On Mon, Aug 05, 2019 at 12:12:05PM +0100, Mark Brown wrote: > On Mon, Aug 05, 2019 at 02:40:32AM -0700, kernelci.org bot wrote: > > Today's -next fails to build an arm allmodconfig due to: > > > allmodconfig (arm, gcc-8) — FAIL, 2 errors, 16 warnings, 0 section > > mismatches > > > > Errors: > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:9: error: implicit > > declaration of function 'readq'; did you mean 'readb'? > > [-Werror=implicit-function-declaration] > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:298:3: error: implicit > > declaration of function 'writeq'; did you mean 'writeb'? > > [-Werror=implicit-function-declaration] > > due to 4fa1c6a679bb0 (drm/amdgpu: add RREG64/WREG64(_PCIE) operations) > which introduces use of readq() and writeq(). AFAICS this problem affects all 32-bit builds, including i386. Is it in the process of being fixed, or should we submit a patch limiting DRM_AMDGPU to 64-bit builds ? Guenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: next/master build: 230 builds: 5 failed, 225 passed, 6 errors, 1344 warnings (next-20190805)
On 8/8/19 11:53 AM, Alex Deucher wrote: On Thu, Aug 8, 2019 at 2:53 PM Guenter Roeck wrote: On Mon, Aug 05, 2019 at 12:12:05PM +0100, Mark Brown wrote: On Mon, Aug 05, 2019 at 02:40:32AM -0700, kernelci.org bot wrote: Today's -next fails to build an arm allmodconfig due to: allmodconfig (arm, gcc-8) — FAIL, 2 errors, 16 warnings, 0 section mismatches Errors: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:9: error: implicit declaration of function 'readq'; did you mean 'readb'? [-Werror=implicit-function-declaration] drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:298:3: error: implicit declaration of function 'writeq'; did you mean 'writeb'? [-Werror=implicit-function-declaration] due to 4fa1c6a679bb0 (drm/amdgpu: add RREG64/WREG64(_PCIE) operations) which introduces use of readq() and writeq(). AFAICS this problem affects all 32-bit builds, including i386. Is it in the process of being fixed, or should we submit a patch limiting DRM_AMDGPU to 64-bit builds ? Yes, the fix is being discussed here: https://patchwork.freedesktop.org/patch/322213/ Please note that this does fail for i386 (32-bit x86) builds, contrary to the information in that discussion. Also, from looking into the kernel, I only see readq/writeq defined for arch/x86 in 64-bit mode; see arch/x86/include/asm/io.h. Guenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: dumb-vga-dac: Fix dereferencing -ENODEV DDC channel
On Tue, Aug 13, 2019 at 02:01:26PM +0200, Neil Armstrong wrote:
> Hi,
>
>
> On 13/08/2019 11:30, Geert Uytterhoeven wrote:
> > If the VGA connector has no DDC channel, an error pointer will be
> > dereferenced, e.g. on Salvator-XS:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address
> > 017d
> > ...
> > Call trace:
> > sysfs_do_create_link_sd.isra.0+0x40/0x108
> > sysfs_create_link+0x20/0x40
> > drm_sysfs_connector_add+0xa8/0xc8
> > drm_connector_register.part.3+0x54/0xb0
> > drm_connector_register_all+0xb0/0xd0
> > drm_modeset_register_all+0x54/0x88
> > drm_dev_register+0x18c/0x1d8
> > rcar_du_probe+0xe4/0x150
> > ...
> >
> > This happens because vga->ddc either contains a valid DDC channel
> > pointer, or -ENODEV, and drm_connector_init_with_ddc() expects a valid
> > DDC channel pointer, or NULL.
> >
> > Fix this by resetting vga->ddc to NULL in case of -ENODEV, and replacing
> > the existing error checks by non-NULL checks.
> > This is similar to what the HDMI connector driver does.
> >
> > Fixes: a4f9087e85de141e ("drm/bridge: dumb-vga-dac: Provide ddc symlink in
> > connector sysfs directory")
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > An alternative would be to check if vga->ddc contains an error pointer,
> > and calling drm_connector_init() instead of
> > drm_connector_init_with_ddc(), like before.
> > ---
> > drivers/gpu/drm/bridge/dumb-vga-dac.c | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > index 8ef6539ae78a6eb3..7aa789c358829b05 100644
> > --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> > @@ -42,7 +42,7 @@ static int dumb_vga_get_modes(struct drm_connector
> > *connector)
> > struct edid *edid;
> > int ret;
> >
> > - if (IS_ERR(vga->ddc))
> > + if (!vga->ddc)
> > goto fallback;
> >
> > edid = drm_get_edid(connector, vga->ddc);
> > @@ -84,7 +84,7 @@ dumb_vga_connector_detect(struct drm_connector
> > *connector, bool force)
> > * wire the DDC pins, or the I2C bus might not be working at
> > * all.
> > */
> > - if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
> > + if (vga->ddc && drm_probe_ddc(vga->ddc))
> > return connector_status_connected;
> >
> > return connector_status_unknown;
> > @@ -197,6 +197,7 @@ static int dumb_vga_probe(struct platform_device *pdev)
> > if (PTR_ERR(vga->ddc) == -ENODEV) {
> > dev_dbg(&pdev->dev,
> > "No i2c bus specified. Disabling EDID
> > readout\n");
> > + vga->ddc = NULL;
> > } else {
> > dev_err(&pdev->dev, "Couldn't retrieve i2c bus\n");
> > return PTR_ERR(vga->ddc);
> > @@ -218,7 +219,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
> >
> > drm_bridge_remove(&vga->bridge);
> >
> > - if (!IS_ERR(vga->ddc))
> > + if (vga->ddc)
> > i2c_put_adapter(vga->ddc);
> >
> > return 0;
> >
>
> Looks sane,
>
> Reviewed-by: Neil Armstrong
>
> Guenter, can you confirm it also fixes qemu:versatilepb ?
>
Yes, it does.
Tested-by: Guenter Roeck
Guenter
[PATCH] drm/amd/amdkfd: Drop unnecessary NULL check after container_of
The first parameter passed to container_of() is the pointer to the work structure passed to the worker and never NULL. The NULL check on the result of container_of() is therefore unnecessary and misleading. Remove it. This change was made automatically with the following Coccinelle script. @@ type t; identifier v; statement s; @@ <+... ( t v = container_of(...); | v = container_of(...); ) ... when != v - if (\( !v \| v == NULL \) ) s ...+> Signed-off-by: Guenter Roeck --- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c b/drivers/gpu/drm/amd/amdkfd/kfd_process.c index 5b6c5669c03d..2f8d352e0069 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c @@ -110,8 +110,6 @@ static void kfd_sdma_activity_worker(struct work_struct *work) workarea = container_of(work, struct kfd_sdma_activity_handler_workarea, sdma_activity_work); - if (!workarea) - return; pdd = workarea->pdd; if (!pdd) -- 2.25.1
[PATCH] drm/i915/gem: Use list_entry to access list members
Use list_entry() instead of container_of() to access list members.
Also drop unnecessary and misleading NULL checks on the result of
list_entry().
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index d4f883f35b95..4241af5074a9 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -148,7 +148,7 @@ static void dmabuf_gem_object_free(struct kref *kref)
if (vgpu && vgpu->active && !list_empty(&vgpu->dmabuf_obj_list_head)) {
list_for_each(pos, &vgpu->dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos,
+ dmabuf_obj = list_entry(pos,
struct intel_vgpu_dmabuf_obj, list);
if (dmabuf_obj == obj) {
list_del(pos);
@@ -357,10 +357,8 @@ pick_dmabuf_by_info(struct intel_vgpu *vgpu,
struct intel_vgpu_dmabuf_obj *ret = NULL;
list_for_each(pos, &vgpu->dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
- if ((dmabuf_obj == NULL) ||
- (dmabuf_obj->info == NULL))
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
+ if (dmabuf_obj->info == NULL)
continue;
fb_info = (struct intel_vgpu_fb_info *)dmabuf_obj->info;
@@ -387,11 +385,7 @@ pick_dmabuf_by_num(struct intel_vgpu *vgpu, u32 id)
struct intel_vgpu_dmabuf_obj *ret = NULL;
list_for_each(pos, &vgpu->dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
- if (!dmabuf_obj)
- continue;
-
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
if (dmabuf_obj->dmabuf_id == id) {
ret = dmabuf_obj;
break;
@@ -600,8 +594,7 @@ void intel_vgpu_dmabuf_cleanup(struct intel_vgpu *vgpu)
mutex_lock(&vgpu->dmabuf_lock);
list_for_each_safe(pos, n, &vgpu->dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
dmabuf_obj->vgpu = NULL;
idr_remove(&vgpu->object_idr, dmabuf_obj->dmabuf_id);
--
2.25.1
[PATCH v2] drm/i915/gem: Use list_entry to access list members
Use list_entry() instead of container_of() to access list members.
Also drop unnecessary and misleading NULL checks on the result of
list_entry().
Signed-off-by: Guenter Roeck
---
v2: Checkpatch fixes:
- Fix alignment
- Replace comparison against NULL with !
drivers/gpu/drm/i915/gvt/dmabuf.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index d4f883f35b95..e3f488681484 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -148,8 +148,7 @@ static void dmabuf_gem_object_free(struct kref *kref)
if (vgpu && vgpu->active && !list_empty(&vgpu->dmabuf_obj_list_head)) {
list_for_each(pos, &vgpu->dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos,
- struct intel_vgpu_dmabuf_obj, list);
+ dmabuf_obj = list_entry(pos, struct
intel_vgpu_dmabuf_obj, list);
if (dmabuf_obj == obj) {
list_del(pos);
intel_gvt_hypervisor_put_vfio_device(vgpu);
@@ -357,10 +356,8 @@ pick_dmabuf_by_info(struct intel_vgpu *vgpu,
struct intel_vgpu_dmabuf_obj *ret = NULL;
list_for_each(pos, &vgpu->dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
- if ((dmabuf_obj == NULL) ||
- (dmabuf_obj->info == NULL))
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
+ if (!dmabuf_obj->info)
continue;
fb_info = (struct intel_vgpu_fb_info *)dmabuf_obj->info;
@@ -387,11 +384,7 @@ pick_dmabuf_by_num(struct intel_vgpu *vgpu, u32 id)
struct intel_vgpu_dmabuf_obj *ret = NULL;
list_for_each(pos, &vgpu->dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
- if (!dmabuf_obj)
- continue;
-
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
if (dmabuf_obj->dmabuf_id == id) {
ret = dmabuf_obj;
break;
@@ -600,8 +593,7 @@ void intel_vgpu_dmabuf_cleanup(struct intel_vgpu *vgpu)
mutex_lock(&vgpu->dmabuf_lock);
list_for_each_safe(pos, n, &vgpu->dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
dmabuf_obj->vgpu = NULL;
idr_remove(&vgpu->object_idr, dmabuf_obj->dmabuf_id);
--
2.25.1
[PATCH] drm/msm/dp: Drop unnecessary NULL checks after container_of
The result of container_of() operations is never NULL unless the embedded
element is the first element of the structure. This is not the case here.
The NULL check on the result of container_of() is therefore unnecessary
and misleading. Remove it.
This change was made automatically with the following Coccinelle script.
@@
type t;
identifier v;
statement s;
@@
<+...
(
t v = container_of(...);
|
v = container_of(...);
)
...
when != v
- if (\( !v \| v == NULL \) ) s
...+>
While at it, remove unused but assigned variable hpd in
dp_display_usbpd_attention_cb().
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/msm/dp/dp_display.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 1784e119269b..a74e7ef96fcf 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -208,10 +208,6 @@ static int dp_display_bind(struct device *dev, struct
device *master,
dp = container_of(g_dp_display,
struct dp_display_private, dp_display);
- if (!dp) {
- DRM_ERROR("DP driver bind failed. Invalid driver data\n");
- return -EINVAL;
- }
dp->dp_display.drm_dev = drm;
priv = drm->dev_private;
@@ -252,10 +248,6 @@ static void dp_display_unbind(struct device *dev, struct
device *master,
dp = container_of(g_dp_display,
struct dp_display_private, dp_display);
- if (!dp) {
- DRM_ERROR("Invalid DP driver data\n");
- return;
- }
dp_power_client_deinit(dp->power);
dp_aux_unregister(dp->aux);
@@ -406,11 +398,6 @@ static int dp_display_usbpd_configure_cb(struct device
*dev)
dp = container_of(g_dp_display,
struct dp_display_private, dp_display);
- if (!dp) {
- DRM_ERROR("no driver data found\n");
- rc = -ENODEV;
- goto end;
- }
dp_display_host_init(dp, false);
@@ -437,11 +424,6 @@ static int dp_display_usbpd_disconnect_cb(struct device
*dev)
dp = container_of(g_dp_display,
struct dp_display_private, dp_display);
- if (!dp) {
- DRM_ERROR("no driver data found\n");
- rc = -ENODEV;
- return rc;
- }
dp_add_event(dp, EV_USER_NOTIFICATION, false, 0);
@@ -502,7 +484,6 @@ static int dp_display_usbpd_attention_cb(struct device *dev)
int rc = 0;
u32 sink_request;
struct dp_display_private *dp;
- struct dp_usbpd *hpd;
if (!dev) {
DRM_ERROR("invalid dev\n");
@@ -511,12 +492,6 @@ static int dp_display_usbpd_attention_cb(struct device
*dev)
dp = container_of(g_dp_display,
struct dp_display_private, dp_display);
- if (!dp) {
- DRM_ERROR("no driver data found\n");
- return -ENODEV;
- }
-
- hpd = dp->usbpd;
/* check for any test request issued by sink */
rc = dp_link_process_request(dp->link);
--
2.25.1
[PATCH] drm/msm/disp/dpu1/dpu_encoder: Drop unnecessary NULL checks after container_of
The result of container_of() operations is never NULL unless the embedded
element is the first element of the structure. This is not the case here.
The NULL checks on the result of container_of() are therefore unnecessary
and misleading. Remove them.
This change was made automatically with the following Coccinelle script.
@@
type t;
identifier v;
statement s;
@@
<+...
(
t v = container_of(...);
|
v = container_of(...);
)
...
when != v
- if (\( !v \| v == NULL \) ) s
...+>
Signed-off-by: Guenter Roeck
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 8d942052db8a..a573fe211375 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -1453,11 +1453,6 @@ static void dpu_encoder_off_work(struct work_struct
*work)
struct dpu_encoder_virt *dpu_enc = container_of(work,
struct dpu_encoder_virt, delayed_off_work.work);
- if (!dpu_enc) {
- DPU_ERROR("invalid dpu encoder\n");
- return;
- }
-
dpu_encoder_resource_control(&dpu_enc->base,
DPU_ENC_RC_EVENT_ENTER_IDLE);
@@ -1797,11 +1792,6 @@ static void dpu_encoder_vsync_event_work_handler(struct
kthread_work *work)
struct dpu_encoder_virt, vsync_event_work);
ktime_t wakeup_time;
- if (!dpu_enc) {
- DPU_ERROR("invalid dpu encoder\n");
- return;
- }
-
if (dpu_encoder_vsync_time(&dpu_enc->base, &wakeup_time))
return;
--
2.25.1
Re: [PATCH 3/3] Replace for_each_*_bit_from() with for_each_*_bit() where appropriate
On Fri, Jun 18, 2021 at 12:57:35PM -0700, Yury Norov wrote:
> A couple of kernel functions call for_each_*_bit_from() with start
> bit equal to 0. Replace them with for_each_*_bit().
>
> No functional changes, but might improve on readability.
>
> Signed-off-by: Yury Norov
> ---
> arch/x86/kernel/apic/vector.c | 4 ++--
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 4 ++--
> drivers/hwmon/ltc2992.c | 3 +--
This should be three different patches, one per subsystem.
Guenter
> 3 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
> index fb67ed5e7e6a..d099ef226f55 100644
> --- a/arch/x86/kernel/apic/vector.c
> +++ b/arch/x86/kernel/apic/vector.c
> @@ -760,9 +760,9 @@ void __init lapic_update_legacy_vectors(void)
>
> void __init lapic_assign_system_vectors(void)
> {
> - unsigned int i, vector = 0;
> + unsigned int i, vector;
>
> - for_each_set_bit_from(vector, system_vectors, NR_VECTORS)
> + for_each_set_bit(vector, system_vectors, NR_VECTORS)
> irq_matrix_assign_system(vector_matrix, vector, false);
>
> if (nr_legacy_irqs() > 1)
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 4102bcea3341..42ce3287d3be 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1032,7 +1032,7 @@ int etnaviv_gpu_debugfs(struct etnaviv_gpu *gpu, struct
> seq_file *m)
>
> void etnaviv_gpu_recover_hang(struct etnaviv_gpu *gpu)
> {
> - unsigned int i = 0;
> + unsigned int i;
>
> dev_err(gpu->dev, "recover hung GPU!\n");
>
> @@ -1045,7 +1045,7 @@ void etnaviv_gpu_recover_hang(struct etnaviv_gpu *gpu)
>
> /* complete all events, the GPU won't do it after the reset */
> spin_lock(&gpu->event_spinlock);
> - for_each_set_bit_from(i, gpu->event_bitmap, ETNA_NR_EVENTS)
> + for_each_set_bit(i, gpu->event_bitmap, ETNA_NR_EVENTS)
> complete(&gpu->event_free);
> bitmap_zero(gpu->event_bitmap, ETNA_NR_EVENTS);
> spin_unlock(&gpu->event_spinlock);
> diff --git a/drivers/hwmon/ltc2992.c b/drivers/hwmon/ltc2992.c
> index 2a4bed0ab226..7352d2b3c756 100644
> --- a/drivers/hwmon/ltc2992.c
> +++ b/drivers/hwmon/ltc2992.c
> @@ -248,8 +248,7 @@ static int ltc2992_gpio_get_multiple(struct gpio_chip
> *chip, unsigned long *mask
>
> gpio_status = reg;
>
> - gpio_nr = 0;
> - for_each_set_bit_from(gpio_nr, mask, LTC2992_GPIO_NR) {
> + for_each_set_bit(gpio_nr, mask, LTC2992_GPIO_NR) {
> if (test_bit(LTC2992_GPIO_BIT(gpio_nr), &gpio_status))
> set_bit(gpio_nr, bits);
> }
Re: [PATCH 3/3] drm/i915/hwmon: Expose power1_max_enable
On 2/13/23 21:33, Ashutosh Dixit wrote:
On ATSM the PL1 power limit is disabled at power up. The previous uapi
assumed that the PL1 limit is always enabled and therefore did not have a
notion of a disabled PL1 limit. This results in erroneous PL1 limit values
when PL1 limit is disabled. For example at power up, the disabled ATSM PL1
limit is shown as 0 which means a low PL1 limit whereas the limit being
disabled actually implies a high effective PL1 limit value.
To get round this problem, expose power1_max_enable as a custom hwmon
attribute. power1_max_enable can be used in conjunction with power1_max to
interpret power1_max (PL1 limit) values correctly. It can also be used to
enable/disable the PL1 power limit.
Signed-off-by: Ashutosh Dixit
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +++
drivers/gpu/drm/i915/i915_hwmon.c | 48 +--
2 files changed, 51 insertions(+), 4 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 2d6a472eef885..edd94a44b4570 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -18,6 +18,13 @@ Description: RW. Card reactive sustained (PL1/Tau) power
limit in microwatts.
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_max_enable
This is not a standard hwmon attribute. The standard attribute would be
power1_enable.
So from hwmon perspective this is a NACK.
Guenter
+Date: May 2023
+KernelVersion: 6.3
+Contact: intel-...@lists.freedesktop.org
+Description: RW. Enable/disable the PL1 power limit (power1_max).
+
+ Only supported for particular Intel i915 graphics platforms.
What: /sys/devices/.../hwmon/hwmon/power1_rated_max
Date: February 2023
KernelVersion:6.2
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 7c20a6f47b92e..5665869d8602b 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -230,13 +230,52 @@ hwm_power1_max_interval_store(struct device *dev,
PKG_PWR_LIM_1_TIME, rxy);
return count;
}
+static SENSOR_DEVICE_ATTR_RW(power1_max_interval, hwm_power1_max_interval, 0);
-static SENSOR_DEVICE_ATTR(power1_max_interval, 0664,
- hwm_power1_max_interval_show,
- hwm_power1_max_interval_store, 0);
+static ssize_t
+hwm_power1_max_enable_show(struct device *dev, struct device_attribute *attr,
char *buf)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ intel_wakeref_t wakeref;
+ u32 r;
+
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ r = intel_uncore_read(ddat->uncore,
ddat->hwmon->rg.pkg_rapl_limit);
+
+ return sysfs_emit(buf, "%u\n", !!(r & PKG_PWR_LIM_1_EN));
+}
+
+static ssize_t
+hwm_power1_max_enable_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ intel_wakeref_t wakeref;
+ u32 en, r;
+ bool _en;
+ int ret;
+
+ ret = kstrtobool(buf, &_en);
+ if (ret)
+ return ret;
+
+ en = REG_FIELD_PREP(PKG_PWR_LIM_1_EN, _en);
+ hwm_locked_with_pm_intel_uncore_rmw(ddat,
ddat->hwmon->rg.pkg_rapl_limit,
+ PKG_PWR_LIM_1_EN, en);
+
+ /* Verify, because PL1 limit cannot be disabled on all platforms */
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ r = intel_uncore_read(ddat->uncore,
ddat->hwmon->rg.pkg_rapl_limit);
+ if ((r & PKG_PWR_LIM_1_EN) != en)
+ return -EPERM;
+
+ return count;
+}
+static SENSOR_DEVICE_ATTR_RW(power1_max_enable, hwm_power1_max_enable, 0);
static struct attribute *hwm_attributes[] = {
&sensor_dev_attr_power1_max_interval.dev_attr.attr,
+ &sensor_dev_attr_power1_max_enable.dev_attr.attr,
NULL
};
@@ -247,7 +286,8 @@ static umode_t hwm_attributes_visible(struct kobject *kobj,
struct hwm_drvdata *ddat = dev_get_drvdata(dev);
struct i915_hwmon *hwmon = ddat->hwmon;
- if (attr == &sensor_dev_attr_power1_max_interval.dev_attr.attr)
+ if (attr == &sensor_dev_attr_power1_max_interval.dev_attr.attr ||
+ attr == &sensor_dev_attr_power1_max_enable.dev_attr.attr)
return i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit) ?
attr->mode : 0;
return 0;
