[PATCH v2 1/1] drm/rockchip: fix integer type used for storing dp data rate
commmit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changes
the type of variables used to store the display port data rate and
number of lanes to u8. However u8 is not sufficient to store the link
data rate of the display port.
This commit reverts the type of data rate to unsigned int.
Signed-off-by: Tobias Schramm
---
drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index 83c4586665b4..81ac9b658a70 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -95,7 +95,7 @@ struct cdn_dp_device {
struct cdn_dp_port *port[MAX_PHY];
u8 ports;
u8 max_lanes;
- u8 max_rate;
+ unsigned int max_rate;
u8 lanes;
int active_port;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/1] Regression in rockchipdrm
commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changed
the datatype used for storing the display port data rate to u8.
A u8 is not sufficient to store the data rate, resulting in a crash due
to incorrect calculations.
This series resolves the issue by restoring the data type changed in
commit 2589c4025f13 to their original type.
Thanks to CrystalGamma for identifying the commit causing the regression.
v2: Keep lane count as u8
Tobias Schramm (1):
drm/rockchip: fix integer type used for storing dp data rate
drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8] drm/panel: Add driver for Sony ACX424AKP panel
The Sony ACX424AKP is a command/videomode DSI panel for mobile devices. It is used on the ST-Ericsson HREF520 reference design. We support video mode by default, but it is possible to switch the panel into command mode by using the bool property "dsi-command-mode". Cc: Stephan Gerhold Signed-off-by: Linus Walleij --- ChangeLog v7->v8: - Fix some compilation problems due to the connector refactoring that went in recently so all builds fine now. - Add a MAINTAINERS entry for the driver. - Convert some msleep() to usleep_range(): it's fine to sleep some more so make this explicit. ChangeLog v6->v7: - Add some Kconfig help text. - Sort includes alphabetically. - Move the struct drm_panel first in the state container struct since we are subclassing the panel class. - Put an explicit /* sentinel */ text in the NULL entry for compatible. - Move MTP ID readout to the .prepare() callback. - Add a verbose comment about the MDDI setting so others understand what may be going on. - Explain why the backlight follows the display and cannot be turned on/off ChangeLog v5->v6: - Move the "set MDDI" command back to this file. It is a local pecularity, we suspect there is a Novatek controller inside this display. ChangeLog v4->v5: - Bindings were iterated separately so a jump in versioning. - Add Stephan as reviewer. ChangeLog v3->v4: - No changes just resending with the new binding updates. ChangeLog v2->v3: - No changes just resending with the new binding updates. ChangeLog v1->v2: - Fix up the ID read function to split into reading header, version and ID, store the version in the struct. - Get rid of a surplus semicolon found by the build robot while rewriting the above code. - Use unsigned int in probe() loop. - Set vrefresh to 60Hz, as good as any, the measured vrefresh in continous command mode is ~117 Hz. - Use a different for() idiom while retrying to read ID 5 times. - Drop the sync pulse setting, we are not using this, this panel uses an event. - Use the generic "enforce-video-mode" for video mode enforcement. --- MAINTAINERS | 6 + drivers/gpu/drm/panel/Kconfig| 11 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-sony-acx424akp.c | 550 +++ 4 files changed, 568 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-sony-acx424akp.c diff --git a/MAINTAINERS b/MAINTAINERS index 4118dfe61867..3d5cbbaee117 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5368,6 +5368,12 @@ S: Maintained F: drivers/gpu/drm/tiny/st7735r.c F: Documentation/devicetree/bindings/display/sitronix,st7735r.txt +DRM DRIVER FOR SONY ACX424AKP PANELS +M: Linus Walleij +T: git git://anongit.freedesktop.org/drm/drm-misc +S: Maintained +F: drivers/gpu/drm/panel/panel-sony-acx424akp.c + DRM DRIVER FOR ST-ERICSSON MCDE M: Linus Walleij T: git git://anongit.freedesktop.org/drm/drm-misc diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 41f796b28dd5..ae44ac2ec106 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -338,6 +338,17 @@ config DRM_PANEL_SITRONIX_ST7789V Say Y here if you want to enable support for the Sitronix ST7789V controller for 240x320 LCD panels +config DRM_PANEL_SONY_ACX424AKP + tristate "Sony ACX424AKP DSI command mode panel" + depends on OF + depends on DRM_MIPI_DSI + depends on BACKLIGHT_CLASS_DEVICE + select VIDEOMODE_HELPERS + help + Say Y here if you want to enable the Sony ACX424 display + panel. This panel supports DSI in both command and video + mode. + config DRM_PANEL_SONY_ACX565AKM tristate "Sony ACX565AKM panel" depends on GPIOLIB && OF && SPI diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index 4dc7acff21b9..7c4d3c581fd4 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -35,6 +35,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o +obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o diff --git a/drivers/gpu/drm/panel/panel-sony-acx424akp.c b/drivers/gpu/drm/panel/panel-sony-acx424akp.c new file mode 100644 index ..de0abf76ae6f --- /dev/null +++ b/drivers/gpu/drm/panel/panel-sony-acx424akp.c @@ -0,0 +1,550 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * MIPI-DSI Sony ACX424AKP panel driver. This is a 480x864 + * AMOLED panel with a command-only DSI interface. + * +
Re: [PATCH 1/1] drm/rockchip: fix integer type used for storing dp data rate and lane count
Am 09.01.20 um 01:15 schrieb Heiko Stübner:
> Am Mittwoch, 8. Januar 2020, 23:39:49 CET schrieb Tobias Schramm:
>> commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changes
>> the type of variables used to store the display port data rate and
>> number of lanes to u8. However u8 is not sufficient to store the link
>> data rate of the display port.
>> This commit reverts the type of both the number of lanes and the data
>> rate to unsigned int.
>>
>> Signed-off-by: Tobias Schramm
>> ---
>> drivers/gpu/drm/rockchip/cdn-dp-core.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
>> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
>> index 83c4586665b4..806cb0b08982 100644
>> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
>> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
>> @@ -94,8 +94,8 @@ struct cdn_dp_device {
>> struct video_info video_info;
>> struct cdn_dp_port *port[MAX_PHY];
>> u8 ports;
>> -u8 max_lanes;
>> -u8 max_rate;
>> +unsigned int max_lanes;
>
> although I would think u8 should be enough for max_lanes?
> There shouldn't be be more than 255 dp lanes?
True. I'll test and send a v2.
Thanks, Tobias
>
> Heiko
>
>> +unsigned int max_rate;
>> u8 lanes;
>> int active_port;
>>
>>
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] dt-bindings: panel-simple: Add compatible for Sharp LS020B1DD01D
On Wed, Jan 08, 2020 at 09:30:00PM -0300, Paul Cercueil wrote: > Add a compatible string for the Sharp LS020B1DD01D 2" HQVGA TFT LCD > panel, and remove the old sharp,ls020b1dd01d.txt documentation which is > now obsolete. > > Signed-off-by: Paul Cercueil Applied to drm-misc-next, thanks Sam > --- > .../bindings/display/panel/panel-simple.yaml | 2 ++ > .../bindings/display/panel/sharp,ls020b1dd01d.txt| 12 > 2 files changed, 2 insertions(+), 12 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index c1a77d9105a2..f1fba1db382a 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -35,6 +35,8 @@ properties: >- ampire,am800480r3tmqwa1h > # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel >- giantplus,gpm940b0 > +# Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel > + - sharp,ls020b1dd01d > >backlight: true >enable-gpios: true > diff --git > a/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt > b/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt > deleted file mode 100644 > index e45edbc565a3.. > --- a/Documentation/devicetree/bindings/display/panel/sharp,ls020b1dd01d.txt > +++ /dev/null > @@ -1,12 +0,0 @@ > -Sharp 2.0" (240x160 pixels) 16-bit TFT LCD panel > - > -Required properties: > -- compatible: should be "sharp,ls020b1dd01d" > -- power-supply: as specified in the base binding > - > -Optional properties: > -- backlight: as specified in the base binding > -- enable-gpios: as specified in the base binding > - > -This binding is compatible with the simple-panel binding, which is specified > -in simple-panel.txt in this directory. > -- > 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: panel-simple: Add compatible for GiantPlus GPM940B0
On Wed, Jan 08, 2020 at 09:29:59PM -0300, Paul Cercueil wrote: > Add a compatible string for the GiantPlus GPM740B0 3" QVGA TFT LCD > panel, and remove the old giantplus,gpm740b0.txt documentation which is > now obsolete. > > Signed-off-by: Paul Cercueil Thanks, applied to drm-misc-next. Sam > --- > .../bindings/display/panel/giantplus,gpm940b0.txt| 12 > .../bindings/display/panel/panel-simple.yaml | 2 ++ > 2 files changed, 2 insertions(+), 12 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt > > diff --git > a/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt > b/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt > deleted file mode 100644 > index 3dab52f92c26.. > --- a/Documentation/devicetree/bindings/display/panel/giantplus,gpm940b0.txt > +++ /dev/null > @@ -1,12 +0,0 @@ > -GiantPlus 3.0" (320x240 pixels) 24-bit TFT LCD panel > - > -Required properties: > -- compatible: should be "giantplus,gpm940b0" > -- power-supply: as specified in the base binding > - > -Optional properties: > -- backlight: as specified in the base binding > -- enable-gpios: as specified in the base binding > - > -This binding is compatible with the simple-panel binding, which is specified > -in simple-panel.txt in this directory. > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 090866260f4f..c1a77d9105a2 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -33,6 +33,8 @@ properties: >- ampire,am-480272h3tmqw-t01h > # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel >- ampire,am800480r3tmqwa1h > +# GiantPlus GPM940B0 3.0" QVGA TFT LCD panel > + - giantplus,gpm940b0 > >backlight: true >enable-gpios: true > -- > 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/9] drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation)
Hi Am 08.01.20 um 21:05 schrieb Krzysztof Kozlowski: > The ioreadX() helpers have inconsistent interface. On some architectures > void *__iomem address argument is a pointer to const, on some not. > > Implementations of ioreadX() do not modify the memory under the address > so they can be converted to a "const" version for const-safety and > consistency among architectures. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Thomas Zimmermann > --- > drivers/gpu/drm/mgag200/mgag200_drv.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h > b/drivers/gpu/drm/mgag200/mgag200_drv.h > index aa32aad222c2..6512b3af4fb7 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_drv.h > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h > @@ -34,9 +34,9 @@ > > #define MGAG200FB_CONN_LIMIT 1 > > -#define RREG8(reg) ioread8(((void __iomem *)mdev->rmmio) + (reg)) > +#define RREG8(reg) ioread8(((const void __iomem *)mdev->rmmio) + (reg)) > #define WREG8(reg, v) iowrite8(v, ((void __iomem *)mdev->rmmio) + (reg)) > -#define RREG32(reg) ioread32(((void __iomem *)mdev->rmmio) + (reg)) > +#define RREG32(reg) ioread32(((const void __iomem *)mdev->rmmio) + (reg)) > #define WREG32(reg, v) iowrite32(v, ((void __iomem *)mdev->rmmio) + (reg)) > > #define ATTR_INDEX 0x1fc0 > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 2081/2680] include/kcl/kcl_mm.h:53:28: error: redefinition of 'memalloc_nofs_save'
Hi Slava,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: efcd1418868bc7be0eb22a57497ac20eeb831ff1 [2081/2680] drm/amdkcl: Test
whether memalloc_nofs_save() and memalloc_nofs_restore() functions are available
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout efcd1418868bc7be0eb22a57497ac20eeb831ff1
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:260:10: error: too many arguments to function
'drm_gem_object_lookup'
return drm_gem_object_lookup(dev, filp, handle);
^
In file included from include/kcl/kcl_drm.h:9:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_gem.h:386:24: note: declared here
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: At top level:
include/kcl/kcl_drm.h:269:8: error: redefinition of 'struct
drm_format_name_buf'
struct drm_format_name_buf {
^~~
In file included from include/drm/drmP.h:69:0,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_fourcc.h:142:8: note: originally defined here
struct drm_format_name_buf {
^~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_gem_object_put_unlocked':
include/kcl/kcl_drm.h:301:9: error: implicit declaration of function
'drm_gem_object_unreference_unlocked'; did you mean
'drm_gem_object_put_unlocked'? [-Werror=implicit-function-declaration]
return drm_gem_object_unreference_unlocked(obj);
^~~
drm_gem_object_put_unlocked
include/kcl/kcl_drm.h:301:9: warning: 'return' with a value, in function
returning void
return drm_gem_object_unreference_unlocked(obj);
^~~~
include/kcl/kcl_drm.h:298:20: note: declared here
static inline void kcl_drm_gem_object_put_unlocked(struct drm_gem_object
*obj)
^~~
include/kcl/kcl_drm.h: In function
'kcl_drm_atomic_get_old_crtc_state_before_commit':
include/kcl/kcl_drm.h:325:43: error: invalid type argument of '->' (have
'struct __drm_crtcs_state')
return state->crtcs[drm_crtc_index(crtc)]->state;
^~
include/kcl/kcl_drm.h: In function
'kcl_drm_atomic_get_new_crtc_state_after_commit':
include/kcl/kcl_drm.h:360:43: error: invalid type argument of '->' (have
'struct __drm_crtcs_state')
return state->crtcs[drm_crtc_index(crtc)]->state;
^~
include/kcl/kcl_drm.h: At top level:
include/kcl/kcl_drm.h:465:8: error: redefinition of 'struct drm_printer'
struct drm_printer {
^~~
In file included from include/drm/drm_mm.h:49:0,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/drm/drm_print.h:70:8: note: originally defined here
struct drm_printer {
^~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:471:6: error: conflicting types for 'drm_printf'
void drm_printf(struct drm_printer *p, const char *f, ...);
^~
In file included from include/drm/drm_mm.h:49:0,
from include/drm/drm_vma_manager.h:26,
from include/kcl/kcl_drm_vma_manager.h:8,
from drivers/gpu/drm/ttm/backport/backport.h:5,
from :0:
include/drm/drm_print.h:86:6: note: previous declaration of 'drm_printf' was
here
void drm_printf(struct drm_printer *p, const char *f, ...);
^~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:537:20: error: static declaration of 'drm_dev_put'
follows non-static
[PATCH] drm/dp_mst: fix documentation of drm_dp_mst_add_affected_dsc_crtcs
the parameter is the mst manager, not the port. Signed-off-by: Alex Deucher --- drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 7e9b9b7e50cf..a4be2f825899 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -4781,7 +4781,7 @@ drm_dp_mst_atomic_check_vcpi_alloc_limit(struct drm_dp_mst_topology_mgr *mgr, /** * drm_dp_mst_add_affected_dsc_crtcs * @state: Pointer to the new struct drm_dp_mst_topology_state - * @port: Port pointer of connector with new state + * @mgr: MST topology manager * * Whenever there is a change in mst topology * DSC configuration would have to be recalculated -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:drm-next 234/239] htmldocs: drivers/gpu/drm/drm_dp_mst_topology.c:4866: warning: Function parameter or member 'mgr' not described in 'drm_dp_mst_add_affected_dsc_crtcs'
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next head: 97b7d54cb4471d27e35913a98c914956be65cc2c commit: 730758bf5a57ae27c65ba2bcdadc1c9a811502b9 [234/239] drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs reproduce: make htmldocs If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): fs/posix_acl.c:647: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' sound/soc/soc-core.c:2509: warning: Function parameter or member 'legacy_dai_naming' not described in 'snd_soc_register_dai' include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:223: warning: Function parameter or member 'resume' not described in 'regulator_ops' include/linux/skbuff.h:888: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'list' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'skb_mstamp_ns' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member '__cloned_offset' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'head_frag' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member '__pkt_type_offset' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'encapsulation' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'encap_hdr_csum' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'csum_valid' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member '__pkt_vlan_present_offset' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'vlan_present' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'csum_complete_sw' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'csum_level' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'inner_protocol_type' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'remcsum_offload' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'sender_cpu' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'reserved_tailroom' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'inner_ipproto' not described in 'sk_buff' include/net/sock.h:232: warning: Function parameter or member 'skc_addrpair' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_portpair' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_ipv6only' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_net_refcnt' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_v6_daddr' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_v6_rcv_saddr' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_cookie' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_listener' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_tw_dr' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_rcv_wnd' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_tw_rcv_nxt' not described in 'sock_common' include/net/sock.h:514: warning: Function parameter or member 'sk_rx_skb_cache' not described in 'sock' include/net/sock.h:514: warning: Function parameter or member 'sk_wq_raw' not described in 'sock' include/net/sock.h:514: warning: Function parameter or member 'tcp_rtx_queue' not described in 'sock' include/net/sock.h:514: warning: Function parameter or member 'sk_tx_skb_cache' not described in 'sock' include/net/sock.h:514: warning: Function parameter or member
[radeon-alex:amd-19.50 2080/2680] include/kcl/kcl_kref.h:7:28: error: redefinition of 'kref_read'
Hi Evan, FYI, the error/warning still remains. tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50 head: f981f76437edab0861f3721c27f1c3cec5903dcc commit: b35c23a557bb753b64082a4aa4057374bcbcca74 [2080/2680] drm/amdkcl: Test whether kref_read() function is available config: i386-allyesconfig (attached as .config) compiler: gcc-7 (Debian 7.5.0-3) 7.5.0 reproduce: git checkout b35c23a557bb753b64082a4aa4057374bcbcca74 # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): static inline void drm_dev_put(struct drm_device *dev) ^~~ In file included from drivers/gpu/drm/ttm/backport/backport.h:8:0, from :0: include/kcl/kcl_mm.h: At top level: include/kcl/kcl_mm.h:65:21: error: redefinition of 'kvmalloc' static inline void *kvmalloc(size_t size, gfp_t flags) ^~~~ In file included from include/drm/drm_vma_manager.h:27:0, from include/kcl/kcl_drm_vma_manager.h:8, from drivers/gpu/drm/ttm/backport/backport.h:5, from :0: include/linux/mm.h:635:21: note: previous definition of 'kvmalloc' was here static inline void *kvmalloc(size_t size, gfp_t flags) ^~~~ In file included from drivers/gpu/drm/ttm/backport/backport.h:8:0, from :0: include/kcl/kcl_mm.h:75:21: error: redefinition of 'kvzalloc' static inline void *kvzalloc(size_t size, gfp_t flags) ^~~~ In file included from include/drm/drm_vma_manager.h:27:0, from include/kcl/kcl_drm_vma_manager.h:8, from drivers/gpu/drm/ttm/backport/backport.h:5, from :0: include/linux/mm.h:643:21: note: previous definition of 'kvzalloc' was here static inline void *kvzalloc(size_t size, gfp_t flags) ^~~~ In file included from drivers/gpu/drm/ttm/backport/backport.h:8:0, from :0: include/kcl/kcl_mm.h:85:20: error: static declaration of 'kvfree' follows non-static declaration static inline void kvfree(const void *addr) ^~ In file included from include/drm/drm_vma_manager.h:27:0, from include/kcl/kcl_drm_vma_manager.h:8, from drivers/gpu/drm/ttm/backport/backport.h:5, from :0: include/linux/mm.h:663:13: note: previous declaration of 'kvfree' was here extern void kvfree(const void *addr); ^~ In file included from drivers/gpu/drm/ttm/backport/backport.h:8:0, from :0: include/kcl/kcl_mm.h:105:21: error: redefinition of 'kvmalloc_array' static inline void *kvmalloc_array(size_t n, size_t size, gfp_t flags) ^~ In file included from include/drm/drm_vma_manager.h:27:0, from include/kcl/kcl_drm_vma_manager.h:8, from drivers/gpu/drm/ttm/backport/backport.h:5, from :0: include/linux/mm.h:648:21: note: previous definition of 'kvmalloc_array' was here static inline void *kvmalloc_array(size_t n, size_t size, gfp_t flags) ^~ In file included from drivers/gpu/drm/ttm/backport/backport.h:8:0, from :0: include/kcl/kcl_mm.h:118:21: error: redefinition of 'kvcalloc' static inline void *kvcalloc(size_t n, size_t size, gfp_t flags) ^~~~ In file included from include/drm/drm_vma_manager.h:27:0, from include/kcl/kcl_drm_vma_manager.h:8, from drivers/gpu/drm/ttm/backport/backport.h:5, from :0: include/linux/mm.h:658:21: note: previous definition of 'kvcalloc' was here static inline void *kvcalloc(size_t n, size_t size, gfp_t flags) ^~~~ In file included from drivers/gpu/drm/ttm/backport/backport.h:9:0, from :0: include/kcl/kcl_fence.h:161:20: error: redefinition of 'dma_fence_set_error' static inline void dma_fence_set_error(struct dma_fence *fence, ^~~ In file included from include/drm/drmP.h:58:0, from include/kcl/kcl_drm.h:6, from drivers/gpu/drm/ttm/backport/backport.h:6, from :0: include/linux/dma-fence.h:517:20: note: previous definition of 'dma_fence_set_error' was here static inline void dma_fence_set_error(struct dma_fence *fence, ^~~ In file included from drivers/gpu/drm/ttm/backport/backport.h:9:0, from :0: include/kcl/kcl_fence.h: In function 'dma_fence_set_error': include/kcl/kcl_fence.h:167:7: error: 'struct
Re: Process identical patches in different tree
Hi, Matthias: On Wed, 2020-01-08 at 13:05 +0100, Matthias Brugger wrote: > On 08/01/2020 12:14, Matthias Brugger wrote: > > Hi CK, > > > > On 07/01/2020 03:56, CK Hu wrote: > >> Hi, Dave, Daniel, Matthias: > >> > >> In mediatek-drm-next-5.6 [1], I've cherry-pick 3 patches from > >> v5.5-next/soc [2] because some drm patches depend on these cmdq patches. > >> So these cmdq patches exist in both tree now. I want to know how to > >> process this case. I think we could choose one of below way: > >> > >> 1. Because these cmdq patches are identical in both tree, so each tree > >> could do its own upstream and the there would be nothing happen when > >> merge. > >> 2. Let soc upstream first, and mediatek drm rebase on the latest > >> mainline then upstream. > >> > >> Which one do you prefer? > >> > > > > What we would need is a stable branch with this commits that get merged by > > both > > trees. If I understand correctly that otherwise the SHA of the commits > > would be > > different and that would provoke merge conflicts. > > > > We should not rely on one tree being merged before the other. AFAIK there > > is no > > hard merge order between trees. > > > > I prepared a branch with the patches I think are relevant for you. Please > confirm that this is correct, merge the tree in yours and I'll do the same for > v5.5-next/soc > > > > The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a: > > Linux 5.5-rc1 (2019-12-08 14:57:55 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/ > tags/v5.5-next-cmdq-stable > > for you to fetch changes up to d412f18c9bc791d8951e903de9a68817e3098a6a: > > soc: mediatek: cmdq: add cmdq_dev_get_client_reg function (2020-01-08 > 12:59:57 > +0100) > > > cmdq patches needed by drm driver to use cmdq interface > > > Bibby Hsieh (4): > soc: mediatek: cmdq: remove OR opertaion from err return > soc: mediatek: cmdq: define the instruction struct > soc: mediatek: cmdq: add polling function > soc: mediatek: cmdq: add cmdq_dev_get_client_reg function > > drivers/soc/mediatek/mtk-cmdq-helper.c | 147 > - > include/linux/mailbox/mtk-cmdq-mailbox.h | 11 ++ > include/linux/soc/mediatek/mtk-cmdq.h| 53 + > 3 files changed, 185 insertions(+), 26 deletions(-) > > > I've done in [1], is it what you expect? [1] https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.6 Regards, CK > Regards, > Matthias > > ___ > Linux-mediatek mailing list > linux-media...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/lima: use drm_sched_fault for error task handling
Thanks, applied to drm-misc-next.
Regards,
Qiang
On Tue, Jan 7, 2020 at 4:16 PM Andreas Baierl wrote:
>
> Am 03.01.2020 um 06:46 schrieb Vasily Khoruzhick:
> > On Wed, Jan 1, 2020 at 2:39 AM Qiang Yu wrote:
> >> drm_sched_job_timedout works with drm_sched_stop as a pair,
> >> so we'd better use the drm_sched_fault helper to make the
> >> error and timeout handling go the same path.
> >>
> >> This also fixes application hang when task error.
> >>
> >> Signed-off-by: Qiang Yu
> > LGTM in general.
> >
> > Reviewed-by: Vasily Khoruzhick
> >
> > Erico, Andreas, could you test this patch on actual hardware? I'll
> > have pretty limited access to the hardware for next few weeks, so I
> > won't be able to test it myself.
> I've tested that one on top of a recent kernel (3a562aee727a) on a
> Mali450/ Allwinner H5 device with deqp and got no regressions and kernel
> issues.
> So...
>
> Tested-by: Andreas Baierl
> >> ---
> >> drivers/gpu/drm/lima/lima_sched.c | 35 ---
> >> drivers/gpu/drm/lima/lima_sched.h | 2 --
> >> 2 files changed, 9 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/lima/lima_sched.c
> >> b/drivers/gpu/drm/lima/lima_sched.c
> >> index f522c5f99729..a31a90c380b6 100644
> >> --- a/drivers/gpu/drm/lima/lima_sched.c
> >> +++ b/drivers/gpu/drm/lima/lima_sched.c
> >> @@ -255,13 +255,17 @@ static struct dma_fence *lima_sched_run_job(struct
> >> drm_sched_job *job)
> >> return task->fence;
> >> }
> >>
> >> -static void lima_sched_handle_error_task(struct lima_sched_pipe *pipe,
> >> -struct lima_sched_task *task)
> >> +static void lima_sched_timedout_job(struct drm_sched_job *job)
> >> {
> >> + struct lima_sched_pipe *pipe = to_lima_pipe(job->sched);
> >> + struct lima_sched_task *task = to_lima_task(job);
> >> +
> >> + if (!pipe->error)
> >> + DRM_ERROR("lima job timeout\n");
> >> +
> >> drm_sched_stop(>base, >base);
> >>
> >> - if (task)
> >> - drm_sched_increase_karma(>base);
> >> + drm_sched_increase_karma(>base);
> >>
> >> pipe->task_error(pipe);
> >>
> >> @@ -284,16 +288,6 @@ static void lima_sched_handle_error_task(struct
> >> lima_sched_pipe *pipe,
> >> drm_sched_start(>base, true);
> >> }
> >>
> >> -static void lima_sched_timedout_job(struct drm_sched_job *job)
> >> -{
> >> - struct lima_sched_pipe *pipe = to_lima_pipe(job->sched);
> >> - struct lima_sched_task *task = to_lima_task(job);
> >> -
> >> - DRM_ERROR("lima job timeout\n");
> >> -
> >> - lima_sched_handle_error_task(pipe, task);
> >> -}
> >> -
> >> static void lima_sched_free_job(struct drm_sched_job *job)
> >> {
> >> struct lima_sched_task *task = to_lima_task(job);
> >> @@ -318,15 +312,6 @@ static const struct drm_sched_backend_ops
> >> lima_sched_ops = {
> >> .free_job = lima_sched_free_job,
> >> };
> >>
> >> -static void lima_sched_error_work(struct work_struct *work)
> >> -{
> >> - struct lima_sched_pipe *pipe =
> >> - container_of(work, struct lima_sched_pipe, error_work);
> >> - struct lima_sched_task *task = pipe->current_task;
> >> -
> >> - lima_sched_handle_error_task(pipe, task);
> >> -}
> >> -
> >> int lima_sched_pipe_init(struct lima_sched_pipe *pipe, const char *name)
> >> {
> >> unsigned int timeout = lima_sched_timeout_ms > 0 ?
> >> @@ -335,8 +320,6 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe,
> >> const char *name)
> >> pipe->fence_context = dma_fence_context_alloc(1);
> >> spin_lock_init(>fence_lock);
> >>
> >> - INIT_WORK(>error_work, lima_sched_error_work);
> >> -
> >> return drm_sched_init(>base, _sched_ops, 1, 0,
> >>msecs_to_jiffies(timeout), name);
> >> }
> >> @@ -349,7 +332,7 @@ void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
> >> void lima_sched_pipe_task_done(struct lima_sched_pipe *pipe)
> >> {
> >> if (pipe->error)
> >> - schedule_work(>error_work);
> >> + drm_sched_fault(>base);
> >> else {
> >> struct lima_sched_task *task = pipe->current_task;
> >>
> >> diff --git a/drivers/gpu/drm/lima/lima_sched.h
> >> b/drivers/gpu/drm/lima/lima_sched.h
> >> index 928af91c1118..1d814fecbcc0 100644
> >> --- a/drivers/gpu/drm/lima/lima_sched.h
> >> +++ b/drivers/gpu/drm/lima/lima_sched.h
> >> @@ -68,8 +68,6 @@ struct lima_sched_pipe {
> >> void (*task_fini)(struct lima_sched_pipe *pipe);
> >> void (*task_error)(struct lima_sched_pipe *pipe);
> >> void (*task_mmu_error)(struct lima_sched_pipe *pipe);
> >> -
> >> - struct work_struct error_work;
> >> };
> >>
> >> int lima_sched_task_init(struct lima_sched_task *task,
> >> --
> >> 2.17.1
> >>
> > ___
> > dri-devel mailing list
> >
[radeon-alex:drm-next 218/239] htmldocs: include/drm/drm_dp_mst_helper.h:162: warning: Function parameter or member 'fec_capable' not described in 'drm_dp_mst_port'
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next head: 97b7d54cb4471d27e35913a98c914956be65cc2c commit: ccc3c70e60b54ed29137323b6e48d2895faec88b [218/239] drm/dp_mst: Parse FEC capability on MST ports reproduce: make htmldocs If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not found fs/posix_acl.c:647: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:223: warning: Function parameter or member 'resume' not described in 'regulator_ops' sound/soc/soc-core.c:2509: warning: Function parameter or member 'legacy_dai_naming' not described in 'snd_soc_register_dai' include/linux/skbuff.h:888: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'list' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'skb_mstamp_ns' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member '__cloned_offset' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'head_frag' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member '__pkt_type_offset' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'encapsulation' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'encap_hdr_csum' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'csum_valid' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member '__pkt_vlan_present_offset' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'vlan_present' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'csum_complete_sw' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'csum_level' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'inner_protocol_type' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'remcsum_offload' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'sender_cpu' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'reserved_tailroom' not described in 'sk_buff' include/linux/skbuff.h:888: warning: Function parameter or member 'inner_ipproto' not described in 'sk_buff' include/net/sock.h:232: warning: Function parameter or member 'skc_addrpair' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_portpair' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_ipv6only' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_net_refcnt' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_v6_daddr' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_v6_rcv_saddr' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_cookie' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_listener' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_tw_dr' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_rcv_wnd' not described in 'sock_common' include/net/sock.h:232: warning: Function parameter or member 'skc_tw_rcv_nxt' not described in 'sock_common' include/net/sock.h:514: warning: Function parameter or member 'sk_rx_skb_cache' not described in 'sock' include/net/sock.h:514: warning: Function parameter or member 'sk_wq_raw' not described in 'sock' include/net/sock.h:514: warning: Function
[radeon-alex:amd-19.50 2071/2680] include/kcl/kcl_list.h:6:20: error: redefinition of 'list_bulk_move_tail'
Hi Prike, FYI, the error/warning still remains. tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50 head: f981f76437edab0861f3721c27f1c3cec5903dcc commit: 034972ea50d821bd2596276c956b39f0ed9ca2dd [2071/2680] drm/amdkcl: Test whether list_bulk_move_tail() is available config: i386-allyesconfig (attached as .config) compiler: gcc-7 (Debian 7.5.0-3) 7.5.0 reproduce: git checkout 034972ea50d821bd2596276c956b39f0ed9ca2dd # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): from drivers/gpu/drm/ttm/backport/backport.h:6, from :0: include/drm/drm_drv.h:739:6: note: previous declaration of 'drm_dev_put' was here void drm_dev_put(struct drm_device *dev); ^~~ In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0, from :0: include/kcl/kcl_drm.h: In function 'drm_dev_put': include/kcl/kcl_drm.h:539:9: error: implicit declaration of function 'drm_dev_unref'; did you mean 'drm_dev_enter'? [-Werror=implicit-function-declaration] return drm_dev_unref(dev); ^ drm_dev_enter include/kcl/kcl_drm.h:539:9: warning: 'return' with a value, in function returning void return drm_dev_unref(dev); ^~ include/kcl/kcl_drm.h:537:20: note: declared here static inline void drm_dev_put(struct drm_device *dev) ^~~ In file included from drivers/gpu/drm/ttm/backport/backport.h:8:0, from :0: include/kcl/kcl_mm.h: At top level: include/kcl/kcl_mm.h:65:21: error: redefinition of 'kvmalloc' static inline void *kvmalloc(size_t size, gfp_t flags) ^~~~ In file included from include/drm/drm_vma_manager.h:27:0, from include/kcl/kcl_drm_vma_manager.h:8, from drivers/gpu/drm/ttm/backport/backport.h:5, from :0: include/linux/mm.h:635:21: note: previous definition of 'kvmalloc' was here static inline void *kvmalloc(size_t size, gfp_t flags) ^~~~ In file included from drivers/gpu/drm/ttm/backport/backport.h:8:0, from :0: include/kcl/kcl_mm.h:75:21: error: redefinition of 'kvzalloc' static inline void *kvzalloc(size_t size, gfp_t flags) ^~~~ In file included from include/drm/drm_vma_manager.h:27:0, from include/kcl/kcl_drm_vma_manager.h:8, from drivers/gpu/drm/ttm/backport/backport.h:5, from :0: include/linux/mm.h:643:21: note: previous definition of 'kvzalloc' was here static inline void *kvzalloc(size_t size, gfp_t flags) ^~~~ In file included from drivers/gpu/drm/ttm/backport/backport.h:8:0, from :0: include/kcl/kcl_mm.h:85:20: error: static declaration of 'kvfree' follows non-static declaration static inline void kvfree(const void *addr) ^~ In file included from include/drm/drm_vma_manager.h:27:0, from include/kcl/kcl_drm_vma_manager.h:8, from drivers/gpu/drm/ttm/backport/backport.h:5, from :0: include/linux/mm.h:663:13: note: previous declaration of 'kvfree' was here extern void kvfree(const void *addr); ^~ In file included from drivers/gpu/drm/ttm/backport/backport.h:8:0, from :0: include/kcl/kcl_mm.h:105:21: error: redefinition of 'kvmalloc_array' static inline void *kvmalloc_array(size_t n, size_t size, gfp_t flags) ^~ In file included from include/drm/drm_vma_manager.h:27:0, from include/kcl/kcl_drm_vma_manager.h:8, from drivers/gpu/drm/ttm/backport/backport.h:5, from :0: include/linux/mm.h:648:21: note: previous definition of 'kvmalloc_array' was here static inline void *kvmalloc_array(size_t n, size_t size, gfp_t flags) ^~ In file included from drivers/gpu/drm/ttm/backport/backport.h:8:0, from :0: include/kcl/kcl_mm.h:118:21: error: redefinition of 'kvcalloc' static inline void *kvcalloc(size_t n, size_t size, gfp_t flags) ^~~~ In file included from include/drm/drm_vma_manager.h:27:0, from include/kcl/kcl_drm_vma_manager.h:8, from drivers/gpu/drm/ttm/backport/backport.h:5, from :0: include/linux/mm.h:658:21: note: previous definition of 'kvcalloc' was here static inline void *kvcalloc(size_t n, size_t size, gfp_t flags) ^~~~ In file included from
Re: [PATCH v2 1/2] dt-bindings: display: panel: Add AUO B116XAK01 panel bindings
Hi Rob. On Wed, Jan 08, 2020 at 03:53:55PM -0800, Rob Clark wrote: > From: Rob Clark > > Signed-off-by: Rob Clark > --- > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 090866260f4f..5f1d765447bc 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -33,6 +33,8 @@ properties: >- ampire,am-480272h3tmqw-t01h > # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel >- ampire,am800480r3tmqwa1h > +# AUO B116XAK01 eDP TFT LCD panel > + - auo,b116xa01 > >backlight: true >enable-gpios: true Both patches applied to drm-misc-next. Thanks, Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm/rockchip: fix integer type used for storing dp data rate and lane count
Am Mittwoch, 8. Januar 2020, 23:39:49 CET schrieb Tobias Schramm:
> commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changes
> the type of variables used to store the display port data rate and
> number of lanes to u8. However u8 is not sufficient to store the link
> data rate of the display port.
> This commit reverts the type of both the number of lanes and the data
> rate to unsigned int.
>
> Signed-off-by: Tobias Schramm
> ---
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index 83c4586665b4..806cb0b08982 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -94,8 +94,8 @@ struct cdn_dp_device {
> struct video_info video_info;
> struct cdn_dp_port *port[MAX_PHY];
> u8 ports;
> - u8 max_lanes;
> - u8 max_rate;
> + unsigned int max_lanes;
although I would think u8 should be enough for max_lanes?
There shouldn't be be more than 255 dp lanes?
Heiko
> + unsigned int max_rate;
> u8 lanes;
> int active_port;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] nouveau/secboot/gm20b: initialize pointer in gm20b_secboot_new()
On Wed, 8 Jan 2020 at 15:46, Dan Carpenter wrote:
>
> We accidentally set "psb" which is a no-op instead of "*psb" so it
> generates a static checker warning. We should probably set it before
> the first error return so that it's always initialized.
You actually don't need to do either, *psb will be NULL already on
entry to the function. But removing the assignment in the error path
should be done still.
Ben.
>
> Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add secure boot support")
> Signed-off-by: Dan Carpenter
> ---
> Static analysis. I'm not sure how this is called.
>
> drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
> index df8b919dcf09..ace6fefba428 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
> @@ -108,6 +108,7 @@ gm20b_secboot_new(struct nvkm_device *device, int index,
> struct gm200_secboot *gsb;
> struct nvkm_acr *acr;
>
> + *psb = NULL;
> acr = acr_r352_new(BIT(NVKM_SECBOOT_FALCON_FECS) |
>BIT(NVKM_SECBOOT_FALCON_PMU));
> if (IS_ERR(acr))
> @@ -116,10 +117,8 @@ gm20b_secboot_new(struct nvkm_device *device, int index,
> acr->optional_falcons = BIT(NVKM_SECBOOT_FALCON_PMU);
>
> gsb = kzalloc(sizeof(*gsb), GFP_KERNEL);
> - if (!gsb) {
> - psb = NULL;
> + if (!gsb)
> return -ENOMEM;
> - }
> *psb = >base;
>
> ret = nvkm_secboot_ctor(_secboot, acr, device, index,
> >base);
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/panel: Add support for AUO B116XAK01 panel
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index ba3f85f36c2f..0c3444c62014 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -629,6 +629,35 @@ static const struct panel_desc auo_b101xtn01 = {
},
};
+static const struct drm_display_mode auo_b116xak01_mode = {
+ .clock = 69300,
+ .hdisplay = 1366,
+ .hsync_start = 1366 + 48,
+ .hsync_end = 1366 + 48 + 32,
+ .htotal = 1366 + 48 + 32 + 10,
+ .vdisplay = 768,
+ .vsync_start = 768 + 4,
+ .vsync_end = 768 + 4 + 6,
+ .vtotal = 768 + 4 + 6 + 15,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc auo_b116xak01 = {
+ .modes = _b116xak01_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 256,
+ .height = 144,
+ },
+ .delay = {
+ .hpd_absent_delay = 200,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_eDP,
+};
+
static const struct drm_display_mode auo_b116xw03_mode = {
.clock = 70589,
.hdisplay = 1366,
@@ -3125,6 +3154,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "auo,b101xtn01",
.data = _b101xtn01,
+ }, {
+ .compatible = "auo,b116xa01",
+ .data = _b116xak01,
}, {
.compatible = "auo,b116xw03",
.data = _b116xw03,
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] dt-bindings: display: panel: Add AUO B116XAK01 panel bindings
From: Rob Clark Signed-off-by: Rob Clark --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 090866260f4f..5f1d765447bc 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -33,6 +33,8 @@ properties: - ampire,am-480272h3tmqw-t01h # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel - ampire,am800480r3tmqwa1h +# AUO B116XAK01 eDP TFT LCD panel + - auo,b116xa01 backlight: true enable-gpios: true -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/1] Regression in rockchipdrm
commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changed
the datatype used for storing the display port data rate to u8.
A u8 is not sufficient to store the data rate, resulting in a crash due
to incorrect calculations.
This series resolves the issue by restoring the data types changed in
commit 2589c4025f13 to their original type.
Tobias Schramm (1):
drm/rockchip: fix integer type used for storing dp data rate and lane
count
drivers/gpu/drm/rockchip/cdn-dp-core.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/rockchip: fix integer type used for storing dp data rate and lane count
commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changes
the type of variables used to store the display port data rate and
number of lanes to u8. However u8 is not sufficient to store the link
data rate of the display port.
This commit reverts the type of both the number of lanes and the data
rate to unsigned int.
Signed-off-by: Tobias Schramm
---
drivers/gpu/drm/rockchip/cdn-dp-core.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index 83c4586665b4..806cb0b08982 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -94,8 +94,8 @@ struct cdn_dp_device {
struct video_info video_info;
struct cdn_dp_port *port[MAX_PHY];
u8 ports;
- u8 max_lanes;
- u8 max_rate;
+ unsigned int max_lanes;
+ unsigned int max_rate;
u8 lanes;
int active_port;
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU
On Wed, Jan 8, 2020 at 9:23 PM Mark Brown wrote:
>
> On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
>
> > Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> > regulator for their SRAM, let's add support for that.
>
> > + pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev,
> > "sram");
> > + if (IS_ERR(pfdev->regulator_sram)) {
>
> This supply is required for the devices that need it so I'd therefore
> expect the driver to request the supply non-optionally based on the
> compatible string rather than just hoping that a missing regulator isn't
> important.
That'd be a bit awkward to match, though... Currently all bifrost
share the same compatible "arm,mali-bifrost", and it'd seem
weird/wrong to match "mediatek,mt8183-mali" in this driver? I have no
idea if any other Mali implementation will require a second regulator,
but with the MT8183 we do need it, see below.
> Though I do have to wonder given the lack of any active
> management of the supply if this is *really* part of the GPU or if it's
> more of a SoC thing, it's not clear what exactly adding this code is
> achieving.
Well if devfreq was working (see patch 7
https://patchwork.kernel.org/patch/11322851/ for a partial
implementation), it would adjust both mali and sram regulators, see
the OPP table in patch 2
(https://patchwork.kernel.org/patch/11322825/): SRAM voltage needs to
be increased for frequencies >=698Mhz.
Now if you have some better idea how to implement this, I'm all ears!
Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 2055/2680] include/kcl/kcl_drm.h:571:20: error: static declaration of 'drm_dev_put' follows non-static declaration
Hi Prike,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: 8d660d16d64cb75fab00f3e78409a93394cb7d29 [2055/2680] drm/amdkcl: Test
whether drm_dev_put is available
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout 8d660d16d64cb75fab00f3e78409a93394cb7d29
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_plane.h:713:5: note: declared here
int drm_universal_plane_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_gem_object_lookup':
include/kcl/kcl_drm.h:260:32: error: passing argument 1 of
'drm_gem_object_lookup' from incompatible pointer type
[-Werror=incompatible-pointer-types]
return drm_gem_object_lookup(dev, filp, handle);
^~~
In file included from include/kcl/kcl_drm.h:9:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_gem.h:386:24: note: expected 'struct drm_file *' but
argument is of type 'struct drm_device *'
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:260:37: warning: passing argument 2 of
'drm_gem_object_lookup' makes integer from pointer without a cast
[-Wint-conversion]
return drm_gem_object_lookup(dev, filp, handle);
^~~~
In file included from include/kcl/kcl_drm.h:9:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_gem.h:386:24: note: expected 'u32 {aka unsigned int}' but
argument is of type 'struct drm_file *'
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:260:10: error: too many arguments to function
'drm_gem_object_lookup'
return drm_gem_object_lookup(dev, filp, handle);
^
In file included from include/kcl/kcl_drm.h:9:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_gem.h:386:24: note: declared here
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: At top level:
include/kcl/kcl_drm.h:303:8: error: redefinition of 'struct
drm_format_name_buf'
struct drm_format_name_buf {
^~~
In file included from include/drm/drmP.h:69:0,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_fourcc.h:142:8: note: originally defined here
struct drm_format_name_buf {
^~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_gem_object_put_unlocked':
include/kcl/kcl_drm.h:335:9: error: implicit declaration of function
'drm_gem_object_unreference_unlocked'; did you mean
'drm_gem_object_put_unlocked'? [-Werror=implicit-function-declaration]
return drm_gem_object_unreference_unlocked(obj);
^~~
drm_gem_object_put_unlocked
include/kcl/kcl_drm.h:335:9: warning: 'return' with a value, in function
returning void
return drm_gem_object_unreference_unlocked(obj);
^~~~
include/kcl/kcl_drm.h:332:20: note: declared here
static inline void kcl_drm_gem_object_put_unlocked(struct drm_gem_object
*obj)
^~~
include/kcl/kcl_drm.h: In function
'kcl_drm_atomic_get_old_crtc_state_before_commit':
include/kcl/kcl_drm.h:359:43: error: invalid type argument of '->' (have
'struct __drm_crtcs_state')
return state->crtcs[drm_crtc_index(crtc)]->state;
^~
include/kcl/kcl_drm.h: In function
'kcl_drm_atomic_get_new_crtc_state_after_commit':
Re: [PATCH v2 7/7, RFC]: drm/panfrost: devfreq: Add support for 2 regulators
On Thu, Jan 9, 2020 at 4:09 AM Rob Herring wrote:
> [snip]
> > void panfrost_devfreq_resume(struct panfrost_device *pfdev)
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> > b/drivers/gpu/drm/panfrost/panfrost_device.h
> > index 92d471676fc7823..581da3fe5df8b17 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> > +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> > @@ -91,10 +91,12 @@ struct panfrost_device {
> > struct {
> > struct devfreq *devfreq;
> > struct thermal_cooling_device *cooling;
> > + struct opp_table *dev_opp_table;
> > ktime_t busy_time;
> > ktime_t idle_time;
> > ktime_t time_last_update;
> > atomic_t busy_count;
> > + struct panfrost_devfreq_slot slot[NUM_JOB_SLOTS];
>
> ?? Left over from some rebase?
Oh, yes, sorry.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-5.5
Hi Dave, Daniel, A few minor fixes for 5.5. This also enables DRIVER_SYNCOBJ_TIMELINE which has been implemented for ages, but was awaiting Khronos which has since happened. The relevant amdvlk code is in: https://github.com/GPUOpen-Drivers/pal/blob/dev/src/core/os/amdgpu/amdgpuDevice.cpp The following changes since commit a6204fc7b83cbe3398f61cf1742b09f66f0ae220: agp: remove unused variable arqsz in agp_3_5_enable() (2020-01-03 16:08:05 +1000) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.5-2020-01-08 for you to fetch changes up to db4ff423cd1659580e541a2d4363342f15c14230: drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpu (2020-01-07 11:33:32 -0500) amd-drm-fixes-5.5-2020-01-08: amdgpu: - Stability fix for raven - Reduce pixel encoding to if max clock is exceeded on HDMI to allow additional high res modes UAPI: - enable DRIVER_SYNCOBJ_TIMELINE for amdgpu Alex Deucher (1): Revert "drm/amdgpu: Set no-retry as default." Chunming Zhou (1): drm/amdgpu: add DRIVER_SYNCOBJ_TIMELINE to amdgpu Thomas Anderson (1): drm/amd/display: Reduce HDMI pixel encoding if max clock is exceeded drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 7 ++-- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 45 --- 2 files changed, 27 insertions(+), 25 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: Update e-mail addresses for Laura Abbott
From: Laura Abbott Consolodate everything under an @kernel.org address. Signed-off-by: Laura Abbott --- Sumit, would you be willing to take this through your tree/drm-misc? --- .mailmap| 3 +++ MAINTAINERS | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index a7bc8cabd157..1b67591657fc 100644 --- a/.mailmap +++ b/.mailmap @@ -144,6 +144,9 @@ Koushik Krzysztof Kozlowski Krzysztof Kozlowski Kuninori Morimoto +Laura Abbott +Laura Abbott +Laura Abbott Leon Romanovsky Leon Romanovsky Leonid I Ananiev diff --git a/MAINTAINERS b/MAINTAINERS index 8982c6e013b3..35b30e355f2f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1098,7 +1098,7 @@ F: Documentation/devicetree/bindings/rtc/google,goldfish-rtc.txt F: drivers/rtc/rtc-goldfish.c ANDROID ION DRIVER -M: Laura Abbott +M: Laura Abbott M: Sumit Semwal L: de...@driverdev.osuosl.org L: dri-devel@lists.freedesktop.org -- 2.24.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 2031/2680] include/kcl/kcl_mm.h:60:21: error: redefinition of 'kvmalloc'
Hi changzhu,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: f12f9b802b6dd80fdee0b7c601b8b9d59a967556 [2031/2680] drm/amdkcl: Test
if linux/overflow.h and struct_size exists
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout f12f9b802b6dd80fdee0b7c601b8b9d59a967556
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_plane.h:713:5: note: declared here
int drm_universal_plane_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_gem_object_lookup':
include/kcl/kcl_drm.h:252:32: error: passing argument 1 of
'drm_gem_object_lookup' from incompatible pointer type
[-Werror=incompatible-pointer-types]
return drm_gem_object_lookup(dev, filp, handle);
^~~
In file included from include/kcl/kcl_drm.h:9:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_gem.h:386:24: note: expected 'struct drm_file *' but
argument is of type 'struct drm_device *'
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:252:37: warning: passing argument 2 of
'drm_gem_object_lookup' makes integer from pointer without a cast
[-Wint-conversion]
return drm_gem_object_lookup(dev, filp, handle);
^~~~
In file included from include/kcl/kcl_drm.h:9:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_gem.h:386:24: note: expected 'u32 {aka unsigned int}' but
argument is of type 'struct drm_file *'
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:252:10: error: too many arguments to function
'drm_gem_object_lookup'
return drm_gem_object_lookup(dev, filp, handle);
^
In file included from include/kcl/kcl_drm.h:9:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_gem.h:386:24: note: declared here
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: At top level:
include/kcl/kcl_drm.h:295:8: error: redefinition of 'struct
drm_format_name_buf'
struct drm_format_name_buf {
^~~
In file included from include/drm/drmP.h:69:0,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_fourcc.h:142:8: note: originally defined here
struct drm_format_name_buf {
^~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_gem_object_put_unlocked':
include/kcl/kcl_drm.h:327:9: error: implicit declaration of function
'drm_gem_object_unreference_unlocked'; did you mean
'drm_gem_object_put_unlocked'? [-Werror=implicit-function-declaration]
return drm_gem_object_unreference_unlocked(obj);
^~~
drm_gem_object_put_unlocked
include/kcl/kcl_drm.h:327:9: warning: 'return' with a value, in function
returning void
return drm_gem_object_unreference_unlocked(obj);
^~~~
include/kcl/kcl_drm.h:324:20: note: declared here
static inline void kcl_drm_gem_object_put_unlocked(struct drm_gem_object
*obj)
^~~
include/kcl/kcl_drm.h: In function
'kcl_drm_atomic_get_old_crtc_state_before_commit':
include/kcl/kcl_drm.h:351:43: error: invalid type argument of '->' (have
'struct __drm_crtcs_state')
return state->crtcs[drm_crtc_index(crtc)]->state;
^~
include/kcl/kcl_drm.h: In function
'kcl_drm_atomic_get_new_crtc_state_after_commit':
[PATCH v2 14/14] phy/rockchip: inno-hdmi: Support more pre-pll configuration
From: Algea Cao
Adding the following freq cfg in 8-bit and 10-bit color depth:
{
4000, 6500, 7100, 8350, 8575,
8875, 10800, 11900, 16200
}
New freq has been validated by quantumdata 980.
For some freq which can't be got by only using integer freq div,
frac freq div is needed, Such as 88.75Mhz 10-bit. But The actual
freq is different from the target freq, We must try to narrow
the gap between them. RK322X only support integer freq div.
The VCO of pre-PLL must be more than 2Ghz, otherwise PLL may be
unlocked.
Signed-off-by: Algea Cao
Signed-off-by: Jonas Karlman
Acked-by: Heiko Stuebner
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 74 ---
1 file changed, 49 insertions(+), 25 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 3719309ad0d0..bb8bdf5e3301 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -291,32 +291,56 @@ struct inno_hdmi_phy_drv_data {
const struct phy_config *phy_cfg_table;
};
+/*
+ * If only using integer freq div can't get frequency we want, frac
+ * freq div is needed. For example, pclk 88.75 Mhz and tmdsclk
+ * 110.9375 Mhz must use frac div 0xF0. The actual frequency is different
+ * from the target frequency. Such as the tmds clock 110.9375 Mhz,
+ * the actual tmds clock we get is 110.93719 Mhz. It is important
+ * to note that RK322X platforms do not support frac div.
+ */
static const struct pre_pll_config pre_pll_cfg_table[] = {
- { 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
- { 2700, 3375, 1, 90, 1, 3, 3, 10, 3, 3, 4, 0, 0},
- { 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
- { 59341000, 59341000, 1, 98, 3, 1, 2, 1, 3, 3, 4, 0, 0xE6AE6B},
- { 5940, 5940, 1, 99, 3, 1, 1, 1, 3, 3, 4, 0, 0},
- { 59341000, 74176250, 1, 98, 0, 3, 3, 1, 3, 3, 4, 0, 0xE6AE6B},
- { 5940, 7425, 1, 99, 1, 2, 2, 1, 3, 3, 4, 0, 0},
- { 74176000, 74176000, 1, 98, 1, 2, 2, 1, 2, 3, 4, 0, 0xE6AE6B},
- { 7425, 7425, 1, 99, 1, 2, 2, 1, 2, 3, 4, 0, 0},
- { 74176000, 9272, 4, 494, 1, 2, 2, 1, 3, 3, 4, 0, 0x816817},
- { 7425, 92812500, 4, 495, 1, 2, 2, 1, 3, 3, 4, 0, 0},
- {148352000, 148352000, 1, 98, 1, 1, 1, 1, 2, 2, 2, 0, 0xE6AE6B},
- {14850, 14850, 1, 99, 1, 1, 1, 1, 2, 2, 2, 0, 0},
- {148352000, 18544, 4, 494, 0, 2, 2, 1, 3, 2, 2, 0, 0x816817},
- {14850, 185625000, 4, 495, 0, 2, 2, 1, 3, 2, 2, 0, 0},
- {296703000, 296703000, 1, 98, 0, 1, 1, 1, 0, 2, 2, 0, 0xE6AE6B},
- {29700, 29700, 1, 99, 0, 1, 1, 1, 0, 2, 2, 0, 0},
- {296703000, 370878750, 4, 494, 1, 2, 0, 1, 3, 1, 1, 0, 0x816817},
- {29700, 37125, 4, 495, 1, 2, 0, 1, 3, 1, 1, 0, 0},
- {593407000, 296703500, 1, 98, 0, 1, 1, 1, 0, 2, 1, 0, 0xE6AE6B},
- {59400, 29700, 1, 99, 0, 1, 1, 1, 0, 2, 1, 0, 0},
- {593407000, 370879375, 4, 494, 1, 2, 0, 1, 3, 1, 1, 1, 0x816817},
- {59400, 37125, 4, 495, 1, 2, 0, 1, 3, 1, 1, 1, 0},
- {593407000, 593407000, 1, 98, 0, 2, 0, 1, 0, 1, 1, 0, 0xE6AE6B},
- {59400, 59400, 1, 99, 0, 2, 0, 1, 0, 1, 1, 0, 0},
+ { 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
+ { 2700, 3375, 1, 90, 1, 3, 3, 10, 3, 3, 4, 0, 0},
+ { 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
+ { 4000, 5000, 1, 100, 2, 2, 2, 1, 0, 0, 15, 0, 0},
+ { 59341000, 59341000, 1, 98, 3, 1, 2, 1, 3, 3, 4, 0, 0xE6AE6B},
+ { 5940, 5940, 1, 99, 3, 1, 1, 1, 3, 3, 4, 0, 0},
+ { 59341000, 74176250, 1, 98, 0, 3, 3, 1, 3, 3, 4, 0, 0xE6AE6B},
+ { 5940, 7425, 1, 99, 1, 2, 2, 1, 3, 3, 4, 0, 0},
+ { 6500, 6500, 1, 130, 2, 2, 2, 1, 0, 0, 12, 0, 0},
+ { 6500, 8125, 3, 325, 0, 3, 3, 1, 0, 0, 10, 0, 0},
+ { 7100, 7100, 3, 284, 0, 3, 3, 1, 0, 0, 8, 0, 0},
+ { 7100, 8875, 3, 355, 0, 3, 3, 1, 0, 0, 10, 0, 0},
+ { 74176000, 74176000, 1, 98, 1, 2, 2, 1, 2, 3, 4, 0, 0xE6AE6B},
+ { 7425, 7425, 1, 99, 1, 2, 2, 1, 2, 3, 4, 0, 0},
+ { 74176000, 9272, 4, 494, 1, 2, 2, 1, 3, 3, 4, 0, 0x816817},
+ { 7425, 92812500, 4, 495, 1, 2, 2, 1, 3, 3, 4, 0, 0},
+ { 8350, 8350, 2, 167, 2, 1, 1, 1, 0, 0, 6, 0, 0},
+ { 8350, 104375000, 1, 104, 2, 1, 1, 1, 1, 0, 5, 0, 0x60},
+ { 8575, 8575, 3, 343, 0, 3, 3, 1, 0, 0, 8, 0, 0},
+ { 8875, 8875, 3, 355, 0, 3, 3, 1, 0, 0, 8, 0, 0},
+ { 8875, 110937500, 1, 110, 2, 1, 1, 1, 1, 0, 5, 0, 0xF0},
+ {10800, 10800, 1, 90, 3, 0, 0, 1, 0, 0, 5, 0, 0},
+ {10800, 13500, 1, 90, 0, 2,
[PATCH v2 11/14] ARM: dts: rockchip: add vpll clock to hdmi node on rk3228
Add the hdmiphy clock as the vpll in hdmi node. Signed-off-by: Jonas Karlman --- arch/arm/boot/dts/rk322x.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi index 340ed6ccb08f..16ad240d5f7f 100644 --- a/arch/arm/boot/dts/rk322x.dtsi +++ b/arch/arm/boot/dts/rk322x.dtsi @@ -639,8 +639,8 @@ interrupts = ; assigned-clocks = < SCLK_HDMI_PHY>; assigned-clock-parents = <_phy>; - clocks = < SCLK_HDMI_HDCP>, < PCLK_HDMI_CTRL>, < SCLK_HDMI_CEC>; - clock-names = "isfr", "iahb", "cec"; + clocks = < SCLK_HDMI_HDCP>, < PCLK_HDMI_CTRL>, <_phy>, < SCLK_HDMI_CEC>; + clock-names = "isfr", "iahb", "vpll", "cec"; pinctrl-names = "default"; pinctrl-0 = <_xfer _hpd _cec>; resets = < SRST_HDMI_P>; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/14] arm64: dts: rockchip: add vpll clock to hdmi node on rk3328
Add the hdmiphy clock as the vpll in hdmi node. Signed-off-by: Jonas Karlman --- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi index fee896338cc1..5d8807aca62e 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi @@ -720,9 +720,11 @@ ; clocks = < PCLK_HDMI>, < SCLK_HDMI_SFC>, +<>, < SCLK_RTC32K>; clock-names = "iahb", "isfr", + "vpll", "cec"; phys = <>; phy-names = "hdmi"; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/14] drm/rockchip: dw-hdmi: limit tmds to 340mhz on rk3228/rk3328
RK3228/RK3328 does not provide a stable hdmi signal at TMDS rates
above 371.25MHz (340MHz pixel clock).
Limit the pixel clock rate to 340MHz to provide a stable signal.
Also limit the pixel clock to the display reported max tmds clock.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 22 +++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 45fcdce3f27f..66c14df4a680 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -237,6 +237,24 @@ dw_hdmi_rockchip_mode_valid(struct drm_connector
*connector,
return (valid) ? MODE_OK : MODE_BAD;
}
+static enum drm_mode_status
+dw_hdmi_rk3228_mode_valid(struct drm_connector *connector,
+ const struct drm_display_mode *mode)
+{
+ struct drm_display_info *info = >display_info;
+ int max_tmds_clock = max(info->max_tmds_clock, 165000);
+ int clock = mode->clock;
+
+ if (connector->ycbcr_420_allowed && drm_mode_is_420(info, mode) &&
+ (info->color_formats & DRM_COLOR_FORMAT_YCRCB420))
+ clock /= 2;
+
+ if (clock > max_tmds_clock || clock > 34)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
static const struct drm_encoder_funcs dw_hdmi_rockchip_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
@@ -424,7 +442,7 @@ static struct rockchip_hdmi_chip_data rk3228_chip_data = {
};
static const struct dw_hdmi_plat_data rk3228_hdmi_drv_data = {
- .mode_valid = dw_hdmi_rockchip_mode_valid,
+ .mode_valid = dw_hdmi_rk3228_mode_valid,
.mpll_cfg = rockchip_mpll_cfg,
.cur_ctr = rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
@@ -461,7 +479,7 @@ static struct rockchip_hdmi_chip_data rk3328_chip_data = {
};
static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
- .mode_valid = dw_hdmi_rockchip_mode_valid,
+ .mode_valid = dw_hdmi_rk3228_mode_valid,
.mpll_cfg = rockchip_mpll_cfg,
.cur_ctr = rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/14] phy/rockchip: inno-hdmi: remove unused no_c from rk3328 recalc_rate
no_c is not used in any calculation, lets remove it.
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 093d2334e8cd..06db69c8373e 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -714,7 +714,7 @@ unsigned long inno_hdmi_phy_rk3328_clk_recalc_rate(struct
clk_hw *hw,
{
struct inno_hdmi_phy *inno = to_inno_hdmi_phy(hw);
unsigned long frac;
- u8 nd, no_a, no_b, no_c, no_d;
+ u8 nd, no_a, no_b, no_d;
u64 vco;
u16 nf;
@@ -737,9 +737,6 @@ unsigned long inno_hdmi_phy_rk3328_clk_recalc_rate(struct
clk_hw *hw,
no_b = inno_read(inno, 0xa5) & RK3328_PRE_PLL_PCLK_DIV_B_MASK;
no_b >>= RK3328_PRE_PLL_PCLK_DIV_B_SHIFT;
no_b += 2;
- no_c = inno_read(inno, 0xa6) & RK3328_PRE_PLL_PCLK_DIV_C_MASK;
- no_c >>= RK3328_PRE_PLL_PCLK_DIV_C_SHIFT;
- no_c = 1 << no_c;
no_d = inno_read(inno, 0xa6) & RK3328_PRE_PLL_PCLK_DIV_D_MASK;
do_div(vco, (nd * (no_a == 1 ? no_b : no_a) * no_d * 2));
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/14] arm64: dts: rockchip: increase vop clock rate on rk3328
The VOP on RK3328 needs to run at higher rate in order to produce a proper 3840x2160 signal. Signed-off-by: Jonas Karlman --- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi index c9ff1188bd7b..fee896338cc1 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi @@ -803,8 +803,8 @@ <0>, <2400>, <2400>, <2400>, <1500>, <1500>, - <1>, <1>, - <1>, <1>, + <3>, <1>, + <4>, <1>, <5000>, <1>, <1>, <1>, <5000>, <5000>, -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/14] clk: rockchip: set parent rate for DCLK_VOP clock on rk3228
Signed-off-by: Jonas Karlman
---
drivers/clk/rockchip/clk-rk3228.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3228.c
b/drivers/clk/rockchip/clk-rk3228.c
index d17cfb7a3ff4..25f79af22cb8 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drivers/clk/rockchip/clk-rk3228.c
@@ -410,7 +410,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[]
__initdata = {
RK2928_CLKSEL_CON(29), 0, 3, DFLAGS),
DIV(0, "sclk_vop_pre", "sclk_vop_src", 0,
RK2928_CLKSEL_CON(27), 8, 8, DFLAGS),
- MUX(DCLK_VOP, "dclk_vop", mux_dclk_vop_p, 0,
+ MUX(DCLK_VOP, "dclk_vop", mux_dclk_vop_p, CLK_SET_RATE_PARENT |
CLK_SET_RATE_NO_REPARENT,
RK2928_CLKSEL_CON(27), 1, 1, MFLAGS),
FACTOR(0, "xin12m", "xin24m", 0, 1, 2),
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/14] phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write
inno_write is used to configure 0xaa reg, that also hold the
POST_PLL_POWER_DOWN bit.
When POST_PLL_REFCLK_SEL_TMDS is configured the power down bit is not
taken into consideration.
Fix this by keeping the power down bit until configuration is complete.
Also reorder the reg write order for consistency.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 06db69c8373e..3a59a6da0440 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -1020,9 +1020,10 @@ inno_hdmi_phy_rk3328_power_on(struct inno_hdmi_phy *inno,
inno_write(inno, 0xac, RK3328_POST_PLL_FB_DIV_7_0(cfg->fbdiv));
if (cfg->postdiv == 1) {
- inno_write(inno, 0xaa, RK3328_POST_PLL_REFCLK_SEL_TMDS);
inno_write(inno, 0xab, RK3328_POST_PLL_FB_DIV_8(cfg->fbdiv) |
RK3328_POST_PLL_PRE_DIV(cfg->prediv));
+ inno_write(inno, 0xaa, RK3328_POST_PLL_REFCLK_SEL_TMDS |
+ RK3328_POST_PLL_POWER_DOWN);
} else {
v = (cfg->postdiv / 2) - 1;
v &= RK3328_POST_PLL_POST_DIV_MASK;
@@ -1030,7 +1031,8 @@ inno_hdmi_phy_rk3328_power_on(struct inno_hdmi_phy *inno,
inno_write(inno, 0xab, RK3328_POST_PLL_FB_DIV_8(cfg->fbdiv) |
RK3328_POST_PLL_PRE_DIV(cfg->prediv));
inno_write(inno, 0xaa, RK3328_POST_PLL_POST_DIV_ENABLE |
- RK3328_POST_PLL_REFCLK_SEL_TMDS);
+ RK3328_POST_PLL_REFCLK_SEL_TMDS |
+ RK3328_POST_PLL_POWER_DOWN);
}
for (v = 0; v < 14; v++)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 13/14] drm/rockchip: dw-hdmi: remove unused plat_data on rk3228/rk3328
mpll_cfg/cur_ctr/phy_config is not used when phy_force_vendor is true,
lets remove them.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 66c14df4a680..a813299e97a2 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -443,9 +443,6 @@ static struct rockchip_hdmi_chip_data rk3228_chip_data = {
static const struct dw_hdmi_plat_data rk3228_hdmi_drv_data = {
.mode_valid = dw_hdmi_rk3228_mode_valid,
- .mpll_cfg = rockchip_mpll_cfg,
- .cur_ctr = rockchip_cur_ctr,
- .phy_config = rockchip_phy_config,
.phy_data = _chip_data,
.phy_ops = _hdmi_phy_ops,
.phy_name = "inno_dw_hdmi_phy2",
@@ -480,9 +477,6 @@ static struct rockchip_hdmi_chip_data rk3328_chip_data = {
static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
.mode_valid = dw_hdmi_rk3228_mode_valid,
- .mpll_cfg = rockchip_mpll_cfg,
- .cur_ctr = rockchip_cur_ctr,
- .phy_config = rockchip_phy_config,
.phy_data = _chip_data,
.phy_ops = _hdmi_phy_ops,
.phy_name = "inno_dw_hdmi_phy2",
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/14] drm/rockchip: dw-hdmi: require valid vpll clock rate on rk3228/rk3328
RK3228/RK3328 can only support clock rates defined in the pre pll table.
Lets validate the mode clock rate against the pre pll config and filter
out any mode with a clock rate returning error from clk_round_rate().
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index fae38b323a0c..45fcdce3f27f 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -245,6 +245,22 @@ static void dw_hdmi_rockchip_encoder_disable(struct
drm_encoder *encoder)
{
}
+static enum drm_mode_status
+dw_hdmi_rockchip_encoder_mode_valid(struct drm_encoder *encoder,
+ const struct drm_display_mode *mode)
+{
+ struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
+ long rate;
+
+ if (hdmi->vpll_clk) {
+ rate = clk_round_rate(hdmi->vpll_clk, mode->clock * 1000);
+ if (rate < 0)
+ return MODE_CLOCK_RANGE;
+ }
+
+ return MODE_OK;
+}
+
static bool
dw_hdmi_rockchip_encoder_mode_fixup(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
@@ -306,6 +322,7 @@ dw_hdmi_rockchip_encoder_atomic_check(struct drm_encoder
*encoder,
}
static const struct drm_encoder_helper_funcs
dw_hdmi_rockchip_encoder_helper_funcs = {
+ .mode_valid = dw_hdmi_rockchip_encoder_mode_valid,
.mode_fixup = dw_hdmi_rockchip_encoder_mode_fixup,
.mode_set = dw_hdmi_rockchip_encoder_mode_set,
.enable = dw_hdmi_rockchip_encoder_enable,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/14] drm/rockchip: dw-hdmi: allow high tmds bit rates
Prepare support for High TMDS Bit Rates used by HDMI2.0 display modes.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 7f56d8c3491d..fae38b323a0c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -318,6 +318,8 @@ static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi
*dw_hdmi, void *data,
{
struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+ dw_hdmi_set_high_tmds_clock_ratio(dw_hdmi);
+
return phy_power_on(hdmi->phy);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/14] phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328
inno_hdmi_phy_rk3328_clk_set_rate() is using the RK3228 macro
when configuring vco_div_5 on RK3328.
Fix this by using correct vco_div_5 macro for RK3328.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 9ca20c947283..b0ac1d3ee390 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -790,8 +790,8 @@ static int inno_hdmi_phy_rk3328_clk_set_rate(struct clk_hw
*hw,
RK3328_PRE_PLL_POWER_DOWN);
/* Configure pre-pll */
- inno_update_bits(inno, 0xa0, RK3228_PCLK_VCO_DIV_5_MASK,
-RK3228_PCLK_VCO_DIV_5(cfg->vco_div_5_en));
+ inno_update_bits(inno, 0xa0, RK3328_PCLK_VCO_DIV_5_MASK,
+RK3328_PCLK_VCO_DIV_5(cfg->vco_div_5_en));
inno_write(inno, 0xa1, RK3328_PRE_PLL_PRE_DIV(cfg->prediv));
val = RK3328_SPREAD_SPECTRUM_MOD_DISABLE;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/14] phy/rockchip: inno-hdmi: force set_rate on power_on
From: Huicong Xu
Regular 8-bit and Deep Color video formats mainly differ in TMDS rate and
not in pixel clock rate.
When the hdmiphy clock is configured with the same pixel clock rate using
clk_set_rate() the clock framework do not signal the hdmi phy driver
to set_rate when switching between 8-bit and Deep Color.
This result in pre/post pll not being re-configured when switching between
regular 8-bit and Deep Color video formats.
Fix this by calling set_rate in power_on to force pre pll re-configuration.
Signed-off-by: Huicong Xu
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 3a59a6da0440..3719309ad0d0 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -245,6 +245,7 @@ struct inno_hdmi_phy {
struct clk_hw hw;
struct clk *phyclk;
unsigned long pixclock;
+ unsigned long tmdsclock;
};
struct pre_pll_config {
@@ -485,6 +486,8 @@ static int inno_hdmi_phy_power_on(struct phy *phy)
dev_dbg(inno->dev, "Inno HDMI PHY Power On\n");
+ inno->plat_data->clk_ops->set_rate(>hw, inno->pixclock, 2400);
+
ret = clk_prepare_enable(inno->phyclk);
if (ret)
return ret;
@@ -509,6 +512,8 @@ static int inno_hdmi_phy_power_off(struct phy *phy)
clk_disable_unprepare(inno->phyclk);
+ inno->tmdsclock = 0;
+
dev_dbg(inno->dev, "Inno HDMI PHY Power Off\n");
return 0;
@@ -628,6 +633,9 @@ static int inno_hdmi_phy_rk3228_clk_set_rate(struct clk_hw
*hw,
dev_dbg(inno->dev, "%s rate %lu tmdsclk %lu\n",
__func__, rate, tmdsclock);
+ if (inno->pixclock == rate && inno->tmdsclock == tmdsclock)
+ return 0;
+
cfg = inno_hdmi_phy_get_pre_pll_cfg(inno, rate);
if (IS_ERR(cfg))
return PTR_ERR(cfg);
@@ -670,6 +678,7 @@ static int inno_hdmi_phy_rk3228_clk_set_rate(struct clk_hw
*hw,
}
inno->pixclock = rate;
+ inno->tmdsclock = tmdsclock;
return 0;
}
@@ -781,6 +790,9 @@ static int inno_hdmi_phy_rk3328_clk_set_rate(struct clk_hw
*hw,
dev_dbg(inno->dev, "%s rate %lu tmdsclk %lu\n",
__func__, rate, tmdsclock);
+ if (inno->pixclock == rate && inno->tmdsclock == tmdsclock)
+ return 0;
+
cfg = inno_hdmi_phy_get_pre_pll_cfg(inno, rate);
if (IS_ERR(cfg))
return PTR_ERR(cfg);
@@ -820,6 +832,7 @@ static int inno_hdmi_phy_rk3328_clk_set_rate(struct clk_hw
*hw,
}
inno->pixclock = rate;
+ inno->tmdsclock = tmdsclock;
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/14] phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate
From: Zheng Yang
inno_hdmi_phy_rk3328_clk_recalc_rate() is returning a rate not found
in the pre pll config table when the fractal divider is used.
This can prevent proper power_on because a tmdsclock for the new rate
is not found in the pre pll config table.
Fix this by saving and returning a rounded pixel rate that exist
in the pre pll config table.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Zheng Yang
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index b0ac1d3ee390..093d2334e8cd 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -745,10 +745,12 @@ unsigned long inno_hdmi_phy_rk3328_clk_recalc_rate(struct
clk_hw *hw,
do_div(vco, (nd * (no_a == 1 ? no_b : no_a) * no_d * 2));
}
- inno->pixclock = vco;
- dev_dbg(inno->dev, "%s rate %lu\n", __func__, inno->pixclock);
+ inno->pixclock = DIV_ROUND_CLOSEST((unsigned long)vco, 1000) * 1000;
- return vco;
+ dev_dbg(inno->dev, "%s rate %lu vco %llu\n",
+ __func__, inno->pixclock, vco);
+
+ return inno->pixclock;
}
static long inno_hdmi_phy_rk3328_clk_round_rate(struct clk_hw *hw,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: one binding file for all simple panels
Hi Jyri, Rob, Paul, Miquel.
Following patch is now applied to drm-misc-next.
Please add your simple panels to this file so
we avoid independent bindings files for ecah panel.
I will handle the inevitable conflicts when I apply.
Sam
On Thu, Jan 02, 2020 at 11:17:11AM +0100, Sam Ravnborg wrote:
> There is an increasing number of new simple panels.
> Common for many of these simple panels are that they have one
> mandatory power-supply and some of them have backlight and / or
> an enable gpio.
>
> The binding file to describe these panels adds overhead
> that really do not add value.
> The binding are known and there is nothing gained from a
> dedicated binding file nor for any dedicated example.
>
> The following patch introduces a single panel-simple.yaml
> and converts two ampire bindings over to the new file.
>
> The conversion - if applied will have following effects:
>
> - The maintainer for the individual file will change
> There is no need for many different maintainers for a simple binding.
> We have the same situation with the panel-simple driver in the kernel.
>
> - The license will change to (GPL-2.0-only OR BSD-2-Clause)
> There is usually only a single line copied from the original
> file, a line that is often copied from a datasheet.
> This license change should be acceptable considered what little
> is copied.
> If the license change is not OK we can use a dedicated binding
> file in these cases.
>
> This is a follow-up on Rob's big patch converting a lot of panel bindings
> to individual files:
>
> "dt-bindings: display: Convert a bunch of panels to DT schema"
> https://patchwork.ozlabs.org/patch/1197683/
>
> The objectives with one file for the relevant simple panels are:
> - Make it simpler to add bindings for simple panels
> - Keep the number of bindings file lower and thus easier to find a
> relevant file to copy from when adding new panels.
> - Keep the binding documentation for simple panels more consistent
> - Make it simpler to add support for new panels
>
> v2:
> - spelling fixes (imirkin via irc, Rob)
> - updated description (Rob)
> - list properires in alphabetical order
> - added power-supply to example (Rob)
> - updated title
> - reworded changelog a little
>
> Signed-off-by: Sam Ravnborg
> Cc: Thierry Reding
> Cc: Rob Herring
> Cc: Maxime Ripard
> Cc: Yannick Fertre
> Cc: Mark Rutland
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: devicet...@vger.kernel.org
> ---
> .../panel/ampire,am-480272h3tmqw-t01h.yaml| 42 -
> .../panel/ampire,am800480r3tmqwa1h.txt| 7 ---
> .../bindings/display/panel/panel-simple.yaml | 59 +++
> 3 files changed, 59 insertions(+), 49 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
> create mode 100644
> Documentation/devicetree/bindings/display/panel/panel-simple.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
>
> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
> deleted file mode 100644
> index c6e33e7f36d0..
> ---
> a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
> +++ /dev/null
> @@ -1,42 +0,0 @@
> -# SPDX-License-Identifier: GPL-2.0
> -%YAML 1.2
>
> -$id:
> http://devicetree.org/schemas/display/panel/ampire,am-480272h3tmqw-t01h.yaml#
> -$schema: http://devicetree.org/meta-schemas/core.yaml#
> -
> -title: Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
> -
> -maintainers:
> - - Yannick Fertre
> - - Thierry Reding
> -
> -allOf:
> - - $ref: panel-common.yaml#
> -
> -properties:
> - compatible:
> -const: ampire,am-480272h3tmqw-t01h
> -
> - power-supply: true
> - enable-gpios: true
> - backlight: true
> - port: true
> -
> -required:
> - - compatible
> -
> -additionalProperties: false
> -
> -examples:
> - - |
> -panel_rgb: panel {
> - compatible = "ampire,am-480272h3tmqw-t01h";
> - enable-gpios = < 8 1>;
> - port {
> -panel_in_rgb: endpoint {
> - remote-endpoint = <_out_rgb>;
> -};
> - };
> -};
> -
> -...
> diff --git
> a/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
>
> b/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
> deleted file mode 100644
> index 83e2cae1cc1b..
> ---
> a/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt
> +++ /dev/null
> @@ -1,7 +0,0 @@
> -Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
> -
> -Required properties:
> -- compatible: should be "ampire,am800480r3tmqwa1h"
> -
> -This binding is compatible with the simple-panel binding, which is specified
> -in simple-panel.txt in this directory.
> diff
[PATCH v2 00/14] Support more HDMI modes on RK3228/RK3328
This series make it possible to use more HDMI modes on RK3328, and presumably also on RK3228. It also prepares for a future YUV420 and 10-bit output series. Part of this has been reworked from vendor BSP 4.4 kernel commits. Patch 1-5 fixes issues and shortcomings in the inno hdmi phy driver. Patch 6 prepares for use of high TMDS bit rates used with HDMI 2.0 and 10-bit output modes. Patch 7-13 changes rk3228/rk3328 to use mode_valid functions suited for the inno hdmi phy instead of the dw-hdmi phy. These changes allows for more CEA modes to be usable, e.g. some 4K and fractal modes. Patch 14 adds support for more pixel clock rates in order to support common DMT modes in addition to CEA modes. Note: I have only been able to build test RK322x related changes as I do not have any RK322x device to test on. All modes, including fractal modes, has been tested with modetest on a RK3328 Rock64 device using e.g. modetest -M rockchip -s 39:3840x2160-29.97 Changes in v2: - collect acked-by tag - drop the limit resolution width to 3840 patch This series is also available at [1] and the early work on YUV420 and 10-bit output is available at [2]. [1] https://github.com/Kwiboo/linux-rockchip/commits/next-20200108-inno-hdmi-phy [2] https://github.com/Kwiboo/linux-rockchip/commits/next-20200108-bus-format Regards, Jonas Algea Cao (1): phy/rockchip: inno-hdmi: Support more pre-pll configuration Huicong Xu (1): phy/rockchip: inno-hdmi: force set_rate on power_on Jonas Karlman (11): phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328 phy/rockchip: inno-hdmi: remove unused no_c from rk3328 recalc_rate phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write drm/rockchip: dw-hdmi: allow high tmds bit rates drm/rockchip: dw-hdmi: require valid vpll clock rate on rk3228/rk3328 clk: rockchip: set parent rate for DCLK_VOP clock on rk3228 arm64: dts: rockchip: increase vop clock rate on rk3328 arm64: dts: rockchip: add vpll clock to hdmi node on rk3328 ARM: dts: rockchip: add vpll clock to hdmi node on rk3228 drm/rockchip: dw-hdmi: limit tmds to 340mhz on rk3228/rk3328 drm/rockchip: dw-hdmi: remove unused plat_data on rk3228/rk3328 Zheng Yang (1): phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate arch/arm/boot/dts/rk322x.dtsi | 4 +- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 +- drivers/clk/rockchip/clk-rk3228.c | 2 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 47 ++-- drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 110 -- 5 files changed, 120 insertions(+), 49 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/3] dt-bindings: Add vendor prefix for Satoz
Hi Miquel. On Mon, Jan 06, 2020 at 04:18:25PM +0100, Miquel Raynal wrote: > Satoz is a Chinese TFT manufacturer. > Website: http://www.sat-sz.com/English/index.html > > Signed-off-by: Miquel Raynal > Acked-by: Rob Herring I have applied this. Can you please re-do patch 2/3 so the compatible is added to panel-simple.yaml - which I just pushed to drm-misc-next. Then we have a two-line entry rather than a whole file as you also asked for. Sam > --- > > Changes since v3: > * None. > > Changes since v2: > * None. > > Changes since v1: > * Added Rob's Ack. > > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index 967e78c5ec0a..4894c5314b49 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -819,6 +819,8 @@ patternProperties: > description: Sancloud Ltd >"^sandisk,.*": > description: Sandisk Corporation > + "^satoz,.*": > +description: Satoz International Co., Ltd >"^sbs,.*": > description: Smart Battery System >"^schindler,.*": > -- > 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: display: add sc7180 panel variant
On Tue, Jan 07, 2020 at 04:59:56PM +0530, Harigovindan P wrote: > Add a compatible string to support sc7180 panel version. > > Changes in v1: > -Added a compatible string to support sc7180 panel version. > Changes in v2: > -Removed unwanted properties from description. > -Creating source files without execute permissions(Rob Herring). > > Signed-off-by: Harigovindan P > --- > .../bindings/display/visionox,rm69299.txt | 48 > ++ > 1 file changed, 48 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/visionox,rm69299.txt As I send in v1, please make this a DT schema. See Documentation/devicetree/writing-schema.rst. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave and Daniel, Either our code is nearly perfect, or things are still slow due to holidays. I'll choose to believe the former. Please pull! drm-misc-fixes-2020-01-08: -mst: Fix NO_STOP_BIT bit offset (Wayne) -sun4i: Fix RGB_DIV clock min divider on old hardware (Chen-Yu) -fb_helper: Fix bits_per_pixel param set behavior to round up (Geert) Cc: Wayne Lin Cc: Chen-Yu Tsai Cc: Geert Uytterhoeven Cheers, Sean The following changes since commit ac2917b01992c098b8d4e6837115e3ca347fdd90: drm/arm/mali: make malidp_mw_connector_helper_funcs static (2019-12-20 15:23:51 +) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-01-08 for you to fetch changes up to f30e27779d3031a092c2a177b7fb76adccc45241: drm/fb-helper: Round up bits_per_pixel if possible (2020-01-07 16:54:03 +0100) -mst: Fix NO_STOP_BIT bit offset (Wayne) -sun4i: Fix RGB_DIV clock min divider on old hardware (Chen-Yu) -fb_helper: Fix bits_per_pixel param set behavior to round up (Geert) Cc: Wayne Lin Cc: Chen-Yu Tsai Cc: Geert Uytterhoeven Chen-Yu Tsai (1): drm/sun4i: tcon: Set RGB DCLK min. divider based on hardware model Geert Uytterhoeven (1): drm/fb-helper: Round up bits_per_pixel if possible Wayne Lin (1): drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- drivers/gpu/drm/drm_fb_helper.c | 7 ++- drivers/gpu/drm/sun4i/sun4i_tcon.c| 15 --- drivers/gpu/drm/sun4i/sun4i_tcon.h| 1 + 4 files changed, 20 insertions(+), 5 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dt-bindings: one binding file for all simple panels
Hi Benjamin. > > + > > +required: > > + - compatible > > + - power-supply > > Hi Sam, > > power-supply property should be optional like it was in > ampire,am-480272h3tmqw-t01h.yaml > else it looks good for me. power-supply was discussed in PATRCH 2/2 and the conclusion was that power-supply is required. Thus I take this as an Acked-by: And I have committed to drm-misc-next Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/9] iomap: Constify ioreadX() iomem argument (as in generic implementation)
On Wed, Jan 8, 2020 at 9:05 PM Krzysztof Kozlowski wrote: > > The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On > some architectures void *__iomem address argument is a pointer to const, > on some not. > > Implementations of ioreadX() do not modify the memory under the address > so they can be converted to a "const" version for const-safety and > consistency among architectures. > > Suggested-by: Geert Uytterhoeven > Signed-off-by: Krzysztof Kozlowski > Reviewed-by: Geert Uytterhoeven Thanks for getting this done! Reviewed-by: Arnd Bergmann > Changes since v1: > 1. Constify also ioreadX_rep() and mmio_insX(), > 2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability, The alpha and parisc versions should be independent, I was thinking you leave them as separate patches, but this work for me too. I have no real opinion on the other 8 patches, I would have left them out completely, but they don't hurt either. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/print: document DRM_ logging functions
On Wed, 2020-01-08 at 21:04 +0100, Sam Ravnborg wrote: > Hi Daniel. > > > > I'd replace the entire block with a "This stuff is deprecated" warning. > > > > We > > > > have at least a corresponding todo.rst entry. > > > > > > We have many situations where no drm_device is available. > > > At least when you a buried in drm_panel patches. > > > > > > So it is either DRM_DEV_ERROR() or drv_err(). > > > Which is why I have pushed for nicer drm_ variants of these... > > > > Huh, drm_panel indeed has no drm_device. And I guess we don't have a > > convenient excuse to add it ... > > > > > The todo entry only covers the nice new macros that Jani added > > > where we have a drm_device. > > > > I wonder whether for those cases we shouldn't just directly use the > > various dev_* macros? > > We would miss the nice [drm] marker in the logging. > So [drm] will be added by the drivers and the core - but not the panels. > That is the only drawback I see right now. > > Which was enough justification for me to add the drm_dev_ variants. > Feel free to convince me that this is not justification to add these > variants. > > In drm/panel/* there is no use of DRM_DEBUG* - and there is no > reason to introduce the variants we can filer with drm.debug. > > There is a single DRM_DEBUG() user, which does not count here. > > > We could introduce only: > > drm_dev_(err|warn|info|debug) - and not the more specialized variants. > > Then we avoid that people make shortcuts and use drm_dev_dbg_kms() when > they are supposed to use drm_dbg_kms(). > This was one of the very valid argumest against the patch that > introduced all the drm_dev_* variants. A few of these defines aren't used at all. $ git grep -P -oh "DRM_DEV_DEBUG[A-Z_]*" | sort | uniq -c | sort -rn 98 DRM_DEV_DEBUG_KMS 38 DRM_DEV_DEBUG_DRIVER 26 DRM_DEV_DEBUG 2 DRM_DEV_DEBUG_RATELIMITED 2 DRM_DEV_DEBUG_PRIME_RATELIMITED 2 DRM_DEV_DEBUG_KMS_RATELIMITED 2 DRM_DEV_DEBUG_DRIVER_RATELIMITED 1 DRM_DEV_DEBUG_VBL 1 DRM_DEV_DEBUG_PRIME 1 DRM_DEV_DEBUG_DP 1 DRM_DEV_DEBUG_ATOMIC It might be sensible to consolidate these into just 2 calls and add an appropriate argument. DRM_DEV_DEBUG(dev, type, fmt, ...) DRM_DEV_DEBUG_RATELIMITED(dev, type, fmt, ...) or drm_dev_dbg(dev, type, fmt, ...) drm_dev_dbg_ratelimited(dev, type, fmt, ...) A treewide sed is trivial. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/9] ntb: intel: Constify ioreadX() iomem argument (as in generic implementation)
On 1/8/20 1:05 PM, Krzysztof Kozlowski wrote:
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
Acked-by: Dave Jiang
---
Changes since v1:
1. Add Geert's review.
---
drivers/ntb/hw/intel/ntb_hw_gen1.c | 2 +-
drivers/ntb/hw/intel/ntb_hw_gen3.h | 2 +-
drivers/ntb/hw/intel/ntb_hw_intel.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen1.c
b/drivers/ntb/hw/intel/ntb_hw_gen1.c
index bb57ec239029..9202502a9787 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen1.c
+++ b/drivers/ntb/hw/intel/ntb_hw_gen1.c
@@ -1202,7 +1202,7 @@ int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int
pidx, int sidx,
ndev->peer_reg->spad);
}
-static u64 xeon_db_ioread(void __iomem *mmio)
+static u64 xeon_db_ioread(const void __iomem *mmio)
{
return (u64)ioread16(mmio);
}
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen3.h
b/drivers/ntb/hw/intel/ntb_hw_gen3.h
index 75fb86ca27bb..d1455f24ec99 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen3.h
+++ b/drivers/ntb/hw/intel/ntb_hw_gen3.h
@@ -91,7 +91,7 @@
#define GEN3_DB_TOTAL_SHIFT 33
#define GEN3_SPAD_COUNT 16
-static inline u64 gen3_db_ioread(void __iomem *mmio)
+static inline u64 gen3_db_ioread(const void __iomem *mmio)
{
return ioread64(mmio);
}
diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.h
b/drivers/ntb/hw/intel/ntb_hw_intel.h
index e071e28bca3f..3c0a5a2da241 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.h
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.h
@@ -102,7 +102,7 @@ struct intel_ntb_dev;
struct intel_ntb_reg {
int (*poll_link)(struct intel_ntb_dev *ndev);
int (*link_is_up)(struct intel_ntb_dev *ndev);
- u64 (*db_ioread)(void __iomem *mmio);
+ u64 (*db_ioread)(const void __iomem *mmio);
void (*db_iowrite)(u64 db_bits, void __iomem *mmio);
unsigned long ntb_ctl;
resource_size_t db_size;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/drm_panel: fix export of drm_panel_of_backlight, try #3
On Wed, Jan 8, 2020 at 5:46 PM Sam Ravnborg wrote: > > Hi Arnd. > > > > > All of this is just another hack until the backlight config usage is > > > > fixed for good. Do we really want to make this the example to copy paste > > > > wherever we hit the issue next? > > > > > > > > I'm not naking, but I'm not acking either. > > > > > > I will try to take a look at your old BACKLIGHT_CLASS_DEVICE patch this > > > weekend. I think we need that one fixed - and then we can have this mess > > > with "drm_panel_of_backlight" fixed in the right way. > > > > I had also attempted to fix the larger mess around 'select' statements in > > DRM/FB > > around BACKLIGHT_CLASS_DEVICE several times in the past, and even at > > some point sent a patch that was acked but never merged and later broke > > because > > of other changes. > > Any chance you have the patch around or can dig up a pointer? > My google foo did not turn up anything. I found it now: https://lore.kernel.org/lkml/20170726135312.2214309-1-a...@arndb.de/ Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7, RFC]: drm/panfrost: devfreq: Add support for 2 regulators
On Tue, Jan 7, 2020 at 11:24 PM Nicolas Boichat wrote:
>
> The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for
> devfreq, and provides OPP table with 2 sets of voltages.
>
> TODO: This is incomplete as we'll need add support for setting
> a pair of voltages as well.
>
> Signed-off-by: Nicolas Boichat
> ---
> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 18 ++
> drivers/gpu/drm/panfrost/panfrost_device.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> index 413987038fbfccb..5eb0effded7eb09 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
> @@ -79,6 +79,22 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
> struct devfreq *devfreq;
> struct thermal_cooling_device *cooling;
>
> + /* If we have 2 regulator, we need an OPP table with 2 voltages. */
> + if (pfdev->regulator_sram) {
> + const char * const reg_names[] = { "mali", "sram" };
> +
> + pfdev->devfreq.dev_opp_table =
> + dev_pm_opp_set_regulators(dev,
> + reg_names, ARRAY_SIZE(reg_names));
> + if (IS_ERR(pfdev->devfreq.dev_opp_table)) {
> + ret = PTR_ERR(pfdev->devfreq.dev_opp_table);
> + pfdev->devfreq.dev_opp_table = NULL;
> + dev_err(dev,
> + "Failed to init devfreq opp table: %d\n",
> ret);
> + return ret;
> + }
> + }
> +
> ret = dev_pm_opp_of_add_table(dev);
> if (ret == -ENODEV) /* Optional, continue without devfreq */
> return 0;
> @@ -119,6 +135,8 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
> if (pfdev->devfreq.cooling)
> devfreq_cooling_unregister(pfdev->devfreq.cooling);
> dev_pm_opp_of_remove_table(>pdev->dev);
> + if (pfdev->devfreq.dev_opp_table)
> + dev_pm_opp_put_regulators(pfdev->devfreq.dev_opp_table);
> }
>
> void panfrost_devfreq_resume(struct panfrost_device *pfdev)
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> b/drivers/gpu/drm/panfrost/panfrost_device.h
> index 92d471676fc7823..581da3fe5df8b17 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> @@ -91,10 +91,12 @@ struct panfrost_device {
> struct {
> struct devfreq *devfreq;
> struct thermal_cooling_device *cooling;
> + struct opp_table *dev_opp_table;
> ktime_t busy_time;
> ktime_t idle_time;
> ktime_t time_last_update;
> atomic_t busy_count;
> + struct panfrost_devfreq_slot slot[NUM_JOB_SLOTS];
?? Left over from some rebase?
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/9] drm/nouveau: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski --- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index f8015e0318d7..5120d062c2df 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -613,7 +613,7 @@ nouveau_bo_rd32(struct nouveau_bo *nvbo, unsigned index) mem += index; if (is_iomem) - return ioread32_native((void __force __iomem *)mem); + return ioread32_native((const void __force __iomem *)mem); else return *mem; } -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 8/9] media: fsl-viu: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski --- drivers/media/platform/fsl-viu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c index 81a8faedbba6..991d9dc82749 100644 --- a/drivers/media/platform/fsl-viu.c +++ b/drivers/media/platform/fsl-viu.c @@ -34,7 +34,7 @@ /* Allow building this driver with COMPILE_TEST */ #if !defined(CONFIG_PPC) && !defined(CONFIG_MICROBLAZE) #define out_be32(v, a) iowrite32be(a, (void __iomem *)v) -#define in_be32(a) ioread32be((void __iomem *)a) +#define in_be32(a) ioread32be((const void __iomem *)a) #endif #define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */ -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 9/9] net: wireless: ath5k: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
---
drivers/net/wireless/ath/ath5k/ahb.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ahb.c
b/drivers/net/wireless/ath/ath5k/ahb.c
index 2c9cec8b53d9..8bd01df369fb 100644
--- a/drivers/net/wireless/ath/ath5k/ahb.c
+++ b/drivers/net/wireless/ath/ath5k/ahb.c
@@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device *pdev)
if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
/* Enable WMAC AHB arbitration */
- reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
+ reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
reg |= AR5K_AR2315_AHB_ARB_CTL_WLAN;
iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
/* Enable global WMAC swapping */
- reg = ioread32((void __iomem *) AR5K_AR2315_BYTESWAP);
+ reg = ioread32((const void __iomem *) AR5K_AR2315_BYTESWAP);
reg |= AR5K_AR2315_BYTESWAP_WMAC;
iowrite32(reg, (void __iomem *) AR5K_AR2315_BYTESWAP);
} else {
/* Enable WMAC DMA access (assuming 5312 or 231x*/
/* TODO: check other platforms */
- reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
+ reg = ioread32((const void __iomem *) AR5K_AR5312_ENABLE);
if (to_platform_device(ah->dev)->id == 0)
reg |= AR5K_AR5312_ENABLE_WLAN0;
else
@@ -202,12 +202,12 @@ static int ath_ahb_remove(struct platform_device *pdev)
if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
/* Disable WMAC AHB arbitration */
- reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
+ reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
reg &= ~AR5K_AR2315_AHB_ARB_CTL_WLAN;
iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
} else {
/*Stop DMA access */
- reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
+ reg = ioread32((const void __iomem *) AR5K_AR5312_ENABLE);
if (to_platform_device(ah->dev)->id == 0)
reg &= ~AR5K_AR5312_ENABLE_WLAN0;
else
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/9] arc: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the
address so they can be converted to a "const" version for const-safety
and consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
---
arch/arc/plat-axs10x/axs10x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c
index 63ea5a606ecd..180c260a8221 100644
--- a/arch/arc/plat-axs10x/axs10x.c
+++ b/arch/arc/plat-axs10x/axs10x.c
@@ -84,7 +84,7 @@ static void __init axs10x_print_board_ver(unsigned int creg,
const char *str)
unsigned int val;
} board;
- board.val = ioread32((void __iomem *)creg);
+ board.val = ioread32((const void __iomem *)creg);
pr_info("AXS: %s FPGA Date: %u-%u-%u\n", str, board.d, board.m,
board.y);
}
@@ -95,7 +95,7 @@ static void __init axs10x_early_init(void)
char mb[32];
/* Determine motherboard version */
- if (ioread32((void __iomem *) CREG_MB_CONFIG) & (1 << 28))
+ if (ioread32((const void __iomem *) CREG_MB_CONFIG) & (1 << 28))
mb_rev = 3; /* HT-3 (rev3.0) */
else
mb_rev = 2; /* HT-2 (rev2.0) */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/9] virtio: pci: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
1. Add Geert's review.
---
drivers/virtio/virtio_pci_modern.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_pci_modern.c
b/drivers/virtio/virtio_pci_modern.c
index 7abcc50838b8..fc58db4ab6c3 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -26,16 +26,16 @@
* method, i.e. 32-bit accesses for 32-bit fields, 16-bit accesses
* for 16-bit fields and 8-bit accesses for 8-bit fields.
*/
-static inline u8 vp_ioread8(u8 __iomem *addr)
+static inline u8 vp_ioread8(const u8 __iomem *addr)
{
return ioread8(addr);
}
-static inline u16 vp_ioread16 (__le16 __iomem *addr)
+static inline u16 vp_ioread16 (const __le16 __iomem *addr)
{
return ioread16(addr);
}
-static inline u32 vp_ioread32(__le32 __iomem *addr)
+static inline u32 vp_ioread32(const __le32 __iomem *addr)
{
return ioread32(addr);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/9] ntb: intel: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
1. Add Geert's review.
---
drivers/ntb/hw/intel/ntb_hw_gen1.c | 2 +-
drivers/ntb/hw/intel/ntb_hw_gen3.h | 2 +-
drivers/ntb/hw/intel/ntb_hw_intel.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen1.c
b/drivers/ntb/hw/intel/ntb_hw_gen1.c
index bb57ec239029..9202502a9787 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen1.c
+++ b/drivers/ntb/hw/intel/ntb_hw_gen1.c
@@ -1202,7 +1202,7 @@ int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int
pidx, int sidx,
ndev->peer_reg->spad);
}
-static u64 xeon_db_ioread(void __iomem *mmio)
+static u64 xeon_db_ioread(const void __iomem *mmio)
{
return (u64)ioread16(mmio);
}
diff --git a/drivers/ntb/hw/intel/ntb_hw_gen3.h
b/drivers/ntb/hw/intel/ntb_hw_gen3.h
index 75fb86ca27bb..d1455f24ec99 100644
--- a/drivers/ntb/hw/intel/ntb_hw_gen3.h
+++ b/drivers/ntb/hw/intel/ntb_hw_gen3.h
@@ -91,7 +91,7 @@
#define GEN3_DB_TOTAL_SHIFT33
#define GEN3_SPAD_COUNT16
-static inline u64 gen3_db_ioread(void __iomem *mmio)
+static inline u64 gen3_db_ioread(const void __iomem *mmio)
{
return ioread64(mmio);
}
diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.h
b/drivers/ntb/hw/intel/ntb_hw_intel.h
index e071e28bca3f..3c0a5a2da241 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.h
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.h
@@ -102,7 +102,7 @@ struct intel_ntb_dev;
struct intel_ntb_reg {
int (*poll_link)(struct intel_ntb_dev *ndev);
int (*link_is_up)(struct intel_ntb_dev *ndev);
- u64 (*db_ioread)(void __iomem *mmio);
+ u64 (*db_ioread)(const void __iomem *mmio);
void (*db_iowrite)(u64 db_bits, void __iomem *mmio);
unsigned long ntb_ctl;
resource_size_t db_size;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/9] drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures void *__iomem address argument is a pointer to const, on some not. Implementations of ioreadX() do not modify the memory under the address so they can be converted to a "const" version for const-safety and consistency among architectures. Signed-off-by: Krzysztof Kozlowski --- drivers/gpu/drm/mgag200/mgag200_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h index aa32aad222c2..6512b3af4fb7 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.h +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h @@ -34,9 +34,9 @@ #define MGAG200FB_CONN_LIMIT 1 -#define RREG8(reg) ioread8(((void __iomem *)mdev->rmmio) + (reg)) +#define RREG8(reg) ioread8(((const void __iomem *)mdev->rmmio) + (reg)) #define WREG8(reg, v) iowrite8(v, ((void __iomem *)mdev->rmmio) + (reg)) -#define RREG32(reg) ioread32(((void __iomem *)mdev->rmmio) + (reg)) +#define RREG32(reg) ioread32(((const void __iomem *)mdev->rmmio) + (reg)) #define WREG32(reg, v) iowrite32(v, ((void __iomem *)mdev->rmmio) + (reg)) #define ATTR_INDEX 0x1fc0 -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/9] iomap: Constify ioreadX() iomem argument
Hi, Changes since v1 https://lore.kernel.org/lkml/1578415992-24054-1-git-send-email-k...@kernel.org/ 1. Constify also ioreadX_rep() and mmio_insX(), 2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability, 3. Add Geert's review, 4. Re-order patches so all optional driver changes are at the end. Description === The ioread8/16/32() and others have inconsistent interface among the architectures: some taking address as const, some not. It seems there is nothing really stopping all of them to take pointer to const. Patchset was not really tested on all affected architectures. Build testing is in progress - I hope auto-builders will point any issues. volatile There is still interface inconsistency between architectures around "volatile" qualifier: - include/asm-generic/io.h:static inline u32 ioread32(const volatile void __iomem *addr) - include/asm-generic/iomap.h:extern unsigned int ioread32(const void __iomem *); This is still discussed and out of scope of this patchset. Merging === Multiple architectures are affected in first patch so acks are welcomed. Patches 2-4 depend on first patch. The rest is optional cleanup, without actual impact. Best regards, Krzysztof Krzysztof Kozlowski (9): iomap: Constify ioreadX() iomem argument (as in generic implementation) net: wireless: rtl818x: Constify ioreadX() iomem argument (as in generic implementation) ntb: intel: Constify ioreadX() iomem argument (as in generic implementation) virtio: pci: Constify ioreadX() iomem argument (as in generic implementation) arc: Constify ioreadX() iomem argument (as in generic implementation) drm/mgag200: Constify ioreadX() iomem argument (as in generic implementation) drm/nouveau: Constify ioreadX() iomem argument (as in generic implementation) media: fsl-viu: Constify ioreadX() iomem argument (as in generic implementation) net: wireless: ath5k: Constify ioreadX() iomem argument (as in generic implementation) arch/alpha/include/asm/core_apecs.h | 6 +- arch/alpha/include/asm/core_cia.h | 6 +- arch/alpha/include/asm/core_lca.h | 6 +- arch/alpha/include/asm/core_marvel.h | 4 +- arch/alpha/include/asm/core_mcpcia.h | 6 +- arch/alpha/include/asm/core_t2.h | 2 +- arch/alpha/include/asm/io.h | 12 ++-- arch/alpha/include/asm/io_trivial.h | 16 ++--- arch/alpha/include/asm/jensen.h | 2 +- arch/alpha/include/asm/machvec.h | 6 +- arch/alpha/kernel/core_marvel.c | 2 +- arch/alpha/kernel/io.c| 12 ++-- arch/arc/plat-axs10x/axs10x.c | 4 +- arch/parisc/include/asm/io.h | 4 +- arch/parisc/lib/iomap.c | 72 +-- arch/powerpc/kernel/iomap.c | 28 arch/sh/kernel/iomap.c| 22 +++--- drivers/gpu/drm/mgag200/mgag200_drv.h | 4 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +- drivers/media/platform/fsl-viu.c | 2 +- drivers/net/wireless/ath/ath5k/ahb.c | 10 +-- .../realtek/rtl818x/rtl8180/rtl8180.h | 6 +- drivers/ntb/hw/intel/ntb_hw_gen1.c| 2 +- drivers/ntb/hw/intel/ntb_hw_gen3.h| 2 +- drivers/ntb/hw/intel/ntb_hw_intel.h | 2 +- drivers/virtio/virtio_pci_modern.c| 6 +- include/asm-generic/iomap.h | 28 include/linux/io-64-nonatomic-hi-lo.h | 4 +- include/linux/io-64-nonatomic-lo-hi.h | 4 +- lib/iomap.c | 30 30 files changed, 156 insertions(+), 156 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/9] iomap: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
some architectures void *__iomem address argument is a pointer to const,
on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Suggested-by: Geert Uytterhoeven
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
1. Constify also ioreadX_rep() and mmio_insX(),
2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability,
3. Add Geert's review.
---
arch/alpha/include/asm/core_apecs.h | 6 +--
arch/alpha/include/asm/core_cia.h | 6 +--
arch/alpha/include/asm/core_lca.h | 6 +--
arch/alpha/include/asm/core_marvel.h | 4 +-
arch/alpha/include/asm/core_mcpcia.h | 6 +--
arch/alpha/include/asm/core_t2.h | 2 +-
arch/alpha/include/asm/io.h | 12 ++---
arch/alpha/include/asm/io_trivial.h | 16 +++---
arch/alpha/include/asm/jensen.h | 2 +-
arch/alpha/include/asm/machvec.h | 6 +--
arch/alpha/kernel/core_marvel.c | 2 +-
arch/alpha/kernel/io.c| 12 ++---
arch/parisc/include/asm/io.h | 4 +-
arch/parisc/lib/iomap.c | 72 +--
arch/powerpc/kernel/iomap.c | 28 +--
arch/sh/kernel/iomap.c| 22
include/asm-generic/iomap.h | 28 +--
include/linux/io-64-nonatomic-hi-lo.h | 4 +-
include/linux/io-64-nonatomic-lo-hi.h | 4 +-
lib/iomap.c | 30 +--
20 files changed, 136 insertions(+), 136 deletions(-)
diff --git a/arch/alpha/include/asm/core_apecs.h
b/arch/alpha/include/asm/core_apecs.h
index 0a07055bc0fe..2d9726fc02ef 100644
--- a/arch/alpha/include/asm/core_apecs.h
+++ b/arch/alpha/include/asm/core_apecs.h
@@ -384,7 +384,7 @@ struct el_apecs_procdata
} \
} while (0)
-__EXTERN_INLINE unsigned int apecs_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread8(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -420,7 +420,7 @@ __EXTERN_INLINE void apecs_iowrite8(u8 b, void __iomem
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int apecs_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread16(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -456,7 +456,7 @@ __EXTERN_INLINE void apecs_iowrite16(u16 b, void __iomem
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int apecs_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int apecs_ioread32(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
if (addr < APECS_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_cia.h
b/arch/alpha/include/asm/core_cia.h
index c706a7f2b061..cb22991f6761 100644
--- a/arch/alpha/include/asm/core_cia.h
+++ b/arch/alpha/include/asm/core_cia.h
@@ -342,7 +342,7 @@ struct el_CIA_sysdata_mcheck {
#define vuip volatile unsigned int __force *
#define vulp volatile unsigned long __force *
-__EXTERN_INLINE unsigned int cia_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread8(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -374,7 +374,7 @@ __EXTERN_INLINE void cia_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int cia_ioread16(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread16(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -404,7 +404,7 @@ __EXTERN_INLINE void cia_iowrite16(u16 b, void __iomem
*xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int cia_ioread32(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int cia_ioread32(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
if (addr < CIA_DENSE_MEM)
diff --git a/arch/alpha/include/asm/core_lca.h
b/arch/alpha/include/asm/core_lca.h
index 84d5e5b84f4f..ec86314418cb 100644
--- a/arch/alpha/include/asm/core_lca.h
+++ b/arch/alpha/include/asm/core_lca.h
@@ -230,7 +230,7 @@ union el_lca {
} while (0)
-__EXTERN_INLINE unsigned int lca_ioread8(void __iomem *xaddr)
+__EXTERN_INLINE unsigned int lca_ioread8(const void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr;
unsigned long result, base_and_type;
@@ -266,7 +266,7 @@ __EXTERN_INLINE void lca_iowrite8(u8 b, void __iomem *xaddr)
*(vuip) ((addr << 5) + base_and_type) = w;
}
-__EXTERN_INLINE unsigned int
[PATCH v2 2/9] net: wireless: rtl818x: Constify ioreadX() iomem argument (as in generic implementation)
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among architectures.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
1. Add Geert's review.
---
drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
index 7948a2da195a..2ff00800d45b 100644
--- a/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
+++ b/drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8180.h
@@ -150,17 +150,17 @@ void rtl8180_write_phy(struct ieee80211_hw *dev, u8 addr,
u32 data);
void rtl8180_set_anaparam(struct rtl8180_priv *priv, u32 anaparam);
void rtl8180_set_anaparam2(struct rtl8180_priv *priv, u32 anaparam2);
-static inline u8 rtl818x_ioread8(struct rtl8180_priv *priv, u8 __iomem *addr)
+static inline u8 rtl818x_ioread8(struct rtl8180_priv *priv, const u8 __iomem
*addr)
{
return ioread8(addr);
}
-static inline u16 rtl818x_ioread16(struct rtl8180_priv *priv, __le16 __iomem
*addr)
+static inline u16 rtl818x_ioread16(struct rtl8180_priv *priv, const __le16
__iomem *addr)
{
return ioread16(addr);
}
-static inline u32 rtl818x_ioread32(struct rtl8180_priv *priv, __le32 __iomem
*addr)
+static inline u32 rtl818x_ioread32(struct rtl8180_priv *priv, const __le32
__iomem *addr)
{
return ioread32(addr);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/print: document DRM_ logging functions
Hi Daniel. > > > > > > I'd replace the entire block with a "This stuff is deprecated" warning. We > > > have at least a corresponding todo.rst entry. > > > > We have many situations where no drm_device is available. > > At least when you a buried in drm_panel patches. > > > > So it is either DRM_DEV_ERROR() or drv_err(). > > Which is why I have pushed for nicer drm_ variants of these... > > Huh, drm_panel indeed has no drm_device. And I guess we don't have a > convenient excuse to add it ... > > > The todo entry only covers the nice new macros that Jani added > > where we have a drm_device. > > I wonder whether for those cases we shouldn't just directly use the > various dev_* macros? We would miss the nice [drm] marker in the logging. So [drm] will be added by the drivers and the core - but not the panels. That is the only drawback I see right now. Which was enough justification for me to add the drm_dev_ variants. Feel free to convince me that this is not justification to add these variants. In drm/panel/* there is no use of DRM_DEBUG* - and there is no reason to introduce the variants we can filer with drm.debug. There is a single DRM_DEBUG() user, which does not count here. We could introduce only: drm_dev_(err|warn|info|debug) - and not the more specialized variants. Then we avoid that people make shortcuts and use drm_dev_dbg_kms() when they are supposed to use drm_dbg_kms(). This was one of the very valid argumest against the patch that introduced all the drm_dev_* variants. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 2027/2680] include/kcl/kcl_fence.h:129:20: error: redefinition of 'dma_fence_set_error'
Hi Flora,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: c53ae0e01db63d1b142681add947781668e3319c [2027/2680] drm/amdkcl: drop
kcl_dma_fence_set_error
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout c53ae0e01db63d1b142681add947781668e3319c
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/scheduler/backport/backport.h:5:0,
from :0:
include/kcl/kcl_fence.h: In function 'kcl_fence_get_rcu_safe':
include/kcl/kcl_fence.h:124:32: error: passing argument 1 of
'dma_fence_get_rcu_safe' from incompatible pointer type
[-Werror=incompatible-pointer-types]
return dma_fence_get_rcu_safe(fencep);
^~
In file included from include/kcl/kcl_fence.h:9:0,
from drivers/gpu/drm/scheduler/backport/backport.h:5,
from :0:
include/linux/dma-fence.h:315:1: note: expected 'struct dma_fence **' but
argument is of type 'struct fence **'
dma_fence_get_rcu_safe(struct dma_fence __rcu **fencep)
^~
In file included from drivers/gpu/drm/scheduler/backport/backport.h:5:0,
from :0:
include/kcl/kcl_fence.h:124:9: error: return from incompatible pointer type
[-Werror=incompatible-pointer-types]
return dma_fence_get_rcu_safe(fencep);
^~
include/kcl/kcl_fence.h: At top level:
>> include/kcl/kcl_fence.h:129:20: error: redefinition of 'dma_fence_set_error'
static inline void dma_fence_set_error(struct dma_fence *fence,
^~~
In file included from include/kcl/kcl_fence.h:9:0,
from drivers/gpu/drm/scheduler/backport/backport.h:5,
from :0:
include/linux/dma-fence.h:517:20: note: previous definition of
'dma_fence_set_error' was here
static inline void dma_fence_set_error(struct dma_fence *fence,
^~~
In file included from drivers/gpu/drm/scheduler/backport/backport.h:5:0,
from :0:
include/kcl/kcl_fence.h: In function 'dma_fence_set_error':
>> include/kcl/kcl_fence.h:135:7: error: 'struct dma_fence' has no member named
>> 'status'
fence->status = error;
^~
cc1: some warnings being treated as errors
vim +/dma_fence_set_error +129 include/kcl/kcl_fence.h
127
128 #if !defined(HAVE_DMA_FENCE_SET_ERROR)
> 129 static inline void dma_fence_set_error(struct dma_fence *fence,
130 int error)
131 {
132 BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags));
133 BUG_ON(error >= 0 || error < -MAX_ERRNO);
134
> 135 fence->status = error;
136 }
137 #endif
138
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/print: document DRM_ logging functions
On Tue, Jan 07, 2020 at 07:17:52PM +0100, Sam Ravnborg wrote: > Hi Daniel. > > > > + * Logging when a * is available, but no _device * > > > + * > > > ~ > > > + * > > > + * DRM/Drivers can use the following functions for logging when there is > > > a > > > + * struct device * available. > > > + * The logging functions share the same prototype: > > > > I'd replace the entire block with a "This stuff is deprecated" warning. We > > have at least a corresponding todo.rst entry. > > We have many situations where no drm_device is available. > At least when you a buried in drm_panel patches. > > So it is either DRM_DEV_ERROR() or drv_err(). > Which is why I have pushed for nicer drm_ variants of these... Huh, drm_panel indeed has no drm_device. And I guess we don't have a convenient excuse to add it ... > The todo entry only covers the nice new macros that Jani added > where we have a drm_device. I wonder whether for those cases we shouldn't just directly use the various dev_* macros? -Daniel > > Sam > > > > > -Daniel > > > > > + * > > > + * .. code-block:: c > > > + * > > > + * void DRM_xxx(struct device *, char * fmt, ...) > > > + * > > > + * .. code-block:: none > > > + * > > > + * # Plain logging > > > + * DRM_DEV_INFO(dev, fmt, ...) > > > + * DRM_DEV_ERROR(dev, fmt, ...) > > > + * > > > + * # Log only once > > > + * DRM_DEV_INFO_ONCE(dev, fmt, ...) > > > + * > > > + * # Ratelimited - do not flood the logs > > > + * DRM_DEV_DEBUG_RATELIMITED(dev, fmt, ...) > > > + * DRM_DEV_DEBUG_DRIVER_RATELIMITED(dev, fmt, ...) > > > + * DRM_DEV_DEBUG_KMS_RATELIMITED(dev, fmt, ...) > > > + * DRM_DEV_DEBUG_PRIME_RATELIMITED(dev, fmt, ...) > > > + * DRM_DEV_ERROR_RATELIMITED(dev, fmt, ...) > > > + * > > > + * # Logging with a specific category > > > + * DRM_DEV_DEBUG(dev, fmt, ...)# Logged as CORE > > > + * DRM_DEV_DEBUG_DRIVER(dev, fmt, ...) > > > + * DRM_DEV_DEBUG_KMS(dev, fmt, ...) > > > + * DRM_DEV_DEBUG_PRIME(dev, fmt, ...) > > > + * DRM_DEV_DEBUG_ATOMIC(dev, fmt, ...) > > > + * DRM_DEV_DEBUG_VBL(dev, fmt, ...) > > > + * DRM_DEV_DEBUG_DP(dev, fmt, ...) > > > + * > > > + * Logging when no * nor _device * is available > > > + * > > > > > > + * > > > + * DRM/Drivers can use the following functions for logging when there is > > > no > > > + * extra info associated to the logging. > > > + * The logging functions share the same prototype: > > > + * > > > + * .. code-block:: c > > > + * > > > + * void DRM_xxx(char * fmt, ...) > > > + * > > > + * .. code-block:: none > > > + * > > > + * # Plain logging > > > + * DRM_INFO(fmt, ...) > > > + * DRM_NOTE(fmt, ...) > > > + * DRM_WARN(fmt, ...) > > > + * DRM_ERROR(fmt, ...) > > > + * > > > + * # Log only once > > > + * DRM_INFO_ONCE(fmt, ...) > > > + * DRM_NOTE_ONCE(fmt, ...) > > > + * DRM_WARN_ONCE(fmt, ...) > > > + * > > > + * # Ratelimited - do not flood the logs > > > + * DRM_DEBUG_RATELIMITED(fmt, ...) > > > + * DRM_DEBUG_DRIVER_RATELIMITED(fmt, ...) > > > + * DRM_DEBUG_KMS_RATELIMITED(fmt, ...) > > > + * DRM_DEBUG_PRIME_RATELIMITED(fmt, ...) > > > + * DRM_ERROR_RATELIMITED(fmt, ...) > > > + * > > > + * # Logging with a specific category > > > + * DRM_DEBUG(fmt, ...) # Logged as CORE > > > + * DRM_DEBUG_DRIVER(fmt, ...) > > > + * DRM_DEBUG_KMS(fmt, ...) > > > + * DRM_DEBUG_PRIME(fmt, ...) > > > + * DRM_DEBUG_ATOMIC(fmt, ...) > > > + * DRM_DEBUG_VBL(fmt, ...) > > > + * DRM_DEBUG_LEASE(fmt, ...) > > > + * DRM_DEBUG_DP(fmt, ...) > > > */ > > > > > > /** > > > @@ -399,7 +475,7 @@ __printf(3, 4) > > > void drm_dev_dbg(const struct device *dev, enum drm_debug_category > > > category, > > >const char *format, ...); > > > > > > -/** > > > +/* > > > * Error output. > > > * > > > * @dev: device pointer > > > @@ -408,7 +484,7 @@ void drm_dev_dbg(const struct device *dev, enum > > > drm_debug_category category, > > > #define DRM_DEV_ERROR(dev, fmt, ...) > > > \ > > > drm_dev_printk(dev, KERN_ERR, "*ERROR* " fmt, ##__VA_ARGS__) > > > > > > -/** > > > +/* > > > * Rate limited error output. Like DRM_ERROR() but won't flood the log. > > > * > > > * @dev: device pointer > > > @@ -436,7 +512,7 @@ void drm_dev_dbg(const struct device *dev, enum > > > drm_debug_category category, > > > } \ > > > }) > > > > > > -/** > > > +/* > > > * Debug output. > > > * > > > * @dev: device pointer > > > @@ -466,7 +542,7 @@ void drm_dev_dbg(const struct device *dev, enum > > > drm_debug_category category, > > > drm_dev_dbg(dev, category, fmt, ##__VA_ARGS__); \ > > > }) > > > > > > -/** > > > +/* > > > * Rate limited debug output. Like DRM_DEBUG() but won't
Re: [PATCH] i915: fix backlight configuration issue
On Wed, Jan 08, 2020 at 05:32:26PM +0200, Jani Nikula wrote: > On Wed, 08 Jan 2020, Arnd Bergmann wrote: > > The i915 driver can use the backlight subsystem as an option, and usually > > selects it when CONFIG_ACPI is set. However it is possible to configure > > a kernel with modular backlight classdev support and a built-in i915 > > driver, which leads to a linker error: > > > > drivers/gpu/drm/i915/display/intel_panel.o: In function > > `intel_backlight_device_register': > > intel_panel.c:(.text+0x2f58): undefined reference to > > `backlight_device_register' > > drivers/gpu/drm/i915/display/intel_panel.o: In function > > `intel_backlight_device_unregister': > > intel_panel.c:(.text+0x2fe4): undefined reference to > > `backlight_device_unregister' > > > > Add another Kconfig option to ensure the driver only tries to use > > the backlight support when it can in fact be linked that way. The > > new option is on by default to keep the existing behavior. > > > > This is roughly what other drivers like nouveau do as well. > > > > Signed-off-by: Arnd Bergmann > > --- > > I've had this one lying around for a long time, it is still needed > > but I am not sure which solution is best here. This version is > > probably the least invasive, but it does not solve the bigger > > problem around too many 'select' statements in drm > > This is just another hack that's only required because backlight is > selected instead of depended on throughout the kernel. (*) > > i915 (and most drm drivers, with some variations) could easily handle > this with: > > depends on (ACPI && ACPI_VIDEO) || ACPI=n > depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n > > Those two lines express the allowed configurations. It's just that we > can't do that in i915 *alone*. The combinations of depends and selects > lead to impossible configurations. It's all or nothing. > > I am not amused by adding more hacks, and I am really *not* interested > in adding another useless i915 config option to "solve" this issue. > > So thanks, but no thanks. I'm not taking this patch. Yeah I'm also leaning towards that the real fix here is to convert backlight over to be a depends on symbol, not a select symbol. It's clearly not a simple stand-alone helper. Or someone makes select recursive and adds a SAT solver to Kconfig :-) -Daniel > > > BR, > Jani. > > > (*) The deeper issue is that people as well as the kconfig tools ignore > the warnings in Documentation/kbuild/kconfig-language.rst: > > select should be used with care. select will force > a symbol to a value without visiting the dependencies. > By abusing select you are able to select a symbol FOO even > if FOO depends on BAR that is not set. > In general use select only for non-visible symbols > (no prompts anywhere) and for symbols with no dependencies. > That will limit the usefulness but on the other hand avoid > the illegal configurations all over. > > I don't think we can, uh, fix the people, but it might be possible to > warn about selecting visible symbols or symbols with dependencies. > > > --- > > drivers/gpu/drm/i915/Kconfig | 11 ++- > > drivers/gpu/drm/i915/display/intel_panel.c | 4 ++-- > > drivers/gpu/drm/i915/display/intel_panel.h | 6 +++--- > > 3 files changed, 15 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > > index ba9595960bbe..81d956040d18 100644 > > --- a/drivers/gpu/drm/i915/Kconfig > > +++ b/drivers/gpu/drm/i915/Kconfig > > @@ -16,7 +16,7 @@ config DRM_I915 > > select IRQ_WORK > > # i915 depends on ACPI_VIDEO when ACPI is enabled > > # but for select to work, need to select ACPI_VIDEO's dependencies, ick > > - select BACKLIGHT_CLASS_DEVICE if ACPI > > + select DRM_I915_BACKLIGHT if ACPI > > select INPUT if ACPI > > select ACPI_VIDEO if ACPI > > select ACPI_BUTTON if ACPI > > @@ -68,6 +68,15 @@ config DRM_I915_FORCE_PROBE > > > > Use "*" to force probe the driver for all known devices. > > > > +config DRM_I915_BACKLIGHT > > + tristate "Control backlight support" > > + depends on DRM_I915 > > + default DRM_I915 > > + select BACKLIGHT_CLASS_DEVICE > > + help > > + Say Y here if you want to control the backlight of your display > > + (e.g. a laptop panel). > > + > > config DRM_I915_CAPTURE_ERROR > > bool "Enable capturing GPU state following a hang" > > depends on DRM_I915 > > diff --git a/drivers/gpu/drm/i915/display/intel_panel.c > > b/drivers/gpu/drm/i915/display/intel_panel.c > > index 7b3ec6eb3382..e2fe7a50dcbf 100644 > > --- a/drivers/gpu/drm/i915/display/intel_panel.c > > +++ b/drivers/gpu/drm/i915/display/intel_panel.c > > @@ -1203,7 +1203,7 @@ void intel_panel_enable_backlight(const struct > > intel_crtc_state *crtc_state, > > mutex_unlock(_priv->backlight_lock); > > } > > > > -#if
Re: [PATCH] gpu/drm: clean up white space in drm_legacy_lock_master_cleanup()
On Wed, Jan 08, 2020 at 08:43:12AM +0300, Dan Carpenter wrote:
> We moved this code to a different file and accidentally deleted a
> newline.
>
> Signed-off-by: Dan Carpenter
Oops, thanks for catching, patch applied!
-Daniel
> ---
> drivers/gpu/drm/drm_lock.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_lock.c b/drivers/gpu/drm/drm_lock.c
> index 2e8ce99d0baa..2c79e8199e3c 100644
> --- a/drivers/gpu/drm/drm_lock.c
> +++ b/drivers/gpu/drm/drm_lock.c
> @@ -360,7 +360,8 @@ void drm_legacy_lock_master_cleanup(struct drm_device
> *dev, struct drm_master *m
> /*
>* Since the master is disappearing, so is the
>* possibility to lock.
> - */ mutex_lock(>struct_mutex);
> + */
> + mutex_lock(>struct_mutex);
> if (master->lock.hw_lock) {
> if (dev->sigdata.lock == master->lock.hw_lock)
> dev->sigdata.lock = NULL;
> --
> 2.11.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/msm: support firmware-name for zap fw
On Tue, Jan 07, 2020 at 05:38:42PM -0800, Rob Clark wrote:
> From: Rob Clark
>
> Since zap firmware can be device specific, allow for a firmware-name
> property in the zap node to specify which firmware to load, similarly to
> the scheme used for dsp/wifi/etc.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 32 ++---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 112e8b8a261e..aa8737bd58db 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -26,6 +26,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
> char *fwname,
> {
> struct device *dev = >pdev->dev;
> const struct firmware *fw;
> + const char *signed_fwname = NULL;
> struct device_node *np, *mem_np;
> struct resource r;
> phys_addr_t mem_phys;
> @@ -58,8 +59,33 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
> char *fwname,
>
> mem_phys = r.start;
>
> - /* Request the MDT file for the firmware */
> - fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
> + /*
> + * Check for a firmware-name property. This is the new scheme
> + * to handle firmware that may be signed with device specific
> + * keys, allowing us to have a different zap fw path for different
> + * devices.
> + *
> + * If the firmware-name property is found, we bypass the
> + * adreno_request_fw() mechanism, because we don't need to handle
> + * the /lib/firmware/qcom/* vs /lib/firmware/* case.
> + *
> + * If the firmware-name property is not found, for backwards
> + * compatibility we fall back to the fwname from the gpulist
> + * table.
> + */
> + of_property_read_string_index(np, "firmware-name", 0, _fwname);
> + if (signed_fwname) {
> + fwname = signed_fwname;
> + ret = request_firmware_direct(, signed_fwname,
> gpu->dev->dev);
> + if (ret) {
> + DRM_DEV_ERROR(dev, "could not load signed zap firmware:
> %d\n", ret);
> + fw = ERR_PTR(ret);
> + }
> + } else {
> + /* Request the MDT file for the firmware */
> + fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
> + }
> +
Since DT seems to be the trend for target specific firmware names I think we
should plan to quickly deprecate the legacy name and not require new targets to
set it. If a zap node is going to be opt in then it isn't onerous to ask
the developer to set the additional property for each target platform.
Jordan
> if (IS_ERR(fw)) {
> DRM_DEV_ERROR(dev, "Unable to load %s\n", fwname);
> return PTR_ERR(fw);
> @@ -95,7 +121,7 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
> char *fwname,
>* not. But since we've already gotten through adreno_request_fw()
>* we know which of the two cases it is:
>*/
> - if (to_adreno_gpu(gpu)->fwloc == FW_LOCATION_LEGACY) {
> + if (signed_fwname || (to_adreno_gpu(gpu)->fwloc == FW_LOCATION_LEGACY))
> {
> ret = qcom_mdt_load(dev, fw, fwname, pasid,
> mem_region, mem_phys, mem_size, NULL);
> } else {
> --
> 2.24.1
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/dp: Add function to parse EDID descriptors for adaptive sync limits
Ville, could you take a look at this patch?
I have tested this on the VRR monitor here and it does parse
the detailed monitor range correctly to expose the min and max vfreq.
Also I got rid of storing the pixel clock in the info->adaptive_sync_limits
struct
since thats just themax dotclock and not related to adaptive sync limits really.
Harry, could you take a look at this patch as well? This can be used inside
amdgpu
in several ways, it will automatically populate the drm_display_info during
get_edid_modes
or this function can be called explicitly in amdgpu_dm_update_freesync_caps()
so I would
leave the usage of this to you and Nicholas depending on what works better in
your driver.
Regards
Manasi
On Tue, Jan 07, 2020 at 04:32:08PM -0800, Manasi Navare wrote:
> Adaptive Sync is a VESA feature so add a DRM core helper to parse
> the EDID's detailed descritors to obtain the adaptive sync monitor range.
> Store this info as part fo drm_display_info so it can be used
> across all drivers.
> This part of the code is stripped out of amdgpu's function
> amdgpu_dm_update_freesync_caps() to make it generic and be used
> across all DRM drivers
>
> v2:
> * Change vmin and vmax to use u8 (Ville)
> * Dont store pixel clock since that is just a max dotclock
> and not related to VRR mode (Manasi)
>
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Clinton A Taylor
> Cc: Nicholas Kazlauskas
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_edid.c | 51 +
> include/drm/drm_connector.h | 22
> include/drm/drm_edid.h | 2 ++
> 3 files changed, 75 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 99769d6c9f84..52781a0e708b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4880,6 +4880,54 @@ static void drm_parse_cea_ext(struct drm_connector
> *connector,
> }
> }
>
> +void drm_get_adaptive_sync_limits(struct drm_connector *connector,
> + const struct edid *edid)
> +{
> + struct drm_display_info *info = >display_info;
> + const struct detailed_timing *timing;
> + const struct detailed_non_pixel *data;
> + const struct detailed_data_monitor_range *range;
> + int i;
> +
> + /*
> + * Restrict Adaptive Sync only for dp and edp
> + */
> + if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort &&
> + connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> + return;
> +
> + if (edid->version <= 1 && !(edid->version == 1 && edid->revision > 1))
> + return;
> +
> + for (i = 0; i < 4; i++) {
> + timing = >detailed_timings[i];
> + data= >data.other_data;
> + range = >data.range;
> + /*
> + * Check if monitor has continuous frequency mode
> + */
> + if (data->type != EDID_DETAIL_MONITOR_RANGE)
> + continue;
> + /*
> + * Check for flag range limits only. If flag == 1 then
> + * no additional timing information provided.
> + * Default GTF, GTF Secondary curve and CVT are not
> + * supported
> + */
> + if (range->flags != 1)
> + continue;
> +
> + info->adaptive_sync.min_vfreq = range->min_vfreq;
> + info->adaptive_sync.max_vfreq = range->max_vfreq;
> +
> + DRM_DEBUG_KMS("Adaptive Sync refresh rate range is %d Hz - %d
> Hz\n",
> + info->adaptive_sync.min_vfreq,
> + info->adaptive_sync.max_vfreq);
> + break;
> + }
> +}
> +EXPORT_SYMBOL(drm_get_adaptive_sync_limits);
> +
> /* A connector has no EDID information, so we've got no EDID to compute
> quirks from. Reset
> * all of the values which would have been set from EDID
> */
> @@ -4901,6 +4949,7 @@ drm_reset_display_info(struct drm_connector *connector)
> memset(>hdmi, 0, sizeof(info->hdmi));
>
> info->non_desktop = 0;
> + memset(>adaptive_sync, 0, sizeof(info->adaptive_sync));
> }
>
> u32 drm_add_display_info(struct drm_connector *connector, const struct edid
> *edid)
> @@ -4916,6 +4965,8 @@ u32 drm_add_display_info(struct drm_connector
> *connector, const struct edid *edi
>
> info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
>
> + drm_get_adaptive_sync_limits(connector, edid);
> +
> DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
>
> if (edid->revision < 3)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 221910948b37..77df404a2e01 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -254,6 +254,23 @@ enum drm_panel_orientation {
> DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> };
>
> +/**
> + * struct drm_adaptive_sync_info - Panel's Adaptive Sync
Re: [PATCH 0/2] drm/radeon: have the callers of set_memory_*() check the return value
On Wed, Jan 8, 2020 at 12:39 PM Kees Cook wrote: > > On Wed, Jan 08, 2020 at 01:56:47PM +0100, Christian König wrote: > > Am 07.01.20 um 20:25 schrieb Tianlin Li: > > > Right now several architectures allow their set_memory_*() family of > > > functions to fail, but callers may not be checking the return values. > > > If set_memory_*() returns with an error, call-site assumptions may be > > > infact wrong to assume that it would either succeed or not succeed at > > > all. Ideally, the failure of set_memory_*() should be passed up the > > > call stack, and callers should examine the failure and deal with it. > > > > > > Need to fix the callers and add the __must_check attribute. They also > > > may not provide any level of atomicity, in the sense that the memory > > > protections may be left incomplete on failure. This issue likely has a > > > few steps on effects architectures: > > > 1)Have all callers of set_memory_*() helpers check the return value. > > > 2)Add __must_check to all set_memory_*() helpers so that new uses do > > > not ignore the return value. > > > 3)Add atomicity to the calls so that the memory protections aren't left > > > in a partial state. > > > > > > This series is part of step 1. Make drm/radeon check the return value of > > > set_memory_*(). > > > > I'm a little hesitate merge that. This hardware is >15 years old and nobody > > of the developers have any system left to test this change on. > > If that's true it should be removed from the tree. We need to be able to > correctly make these kinds of changes in the kernel. This driver supports about 15 years of hardware generations. Newer cards are still prevalent, but the older stuff is less so. It still works and people use it based on feedback I've seen, but the older stuff has no active development at this point. This change just happens to target those older chips. Alex > > > Would it be to much of a problem to just add something like: r = > > set_memory_*(); (void)r; /* Intentionally ignored */. > > This seems like a bad idea -- we shouldn't be papering over failures > like this when there is logic available to deal with it. > > > Apart from that certainly a good idea to add __must_check to the functions. > > Agreed! > > -Kees > > -- > Kees Cook > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/Kconfig: add missing 'depends on DRM' for DRM_DP_CEC
On Wed, Jan 08, 2020 at 01:08:47PM +0100, Hans Verkuil wrote: > On 12/6/19 12:26 PM, Hans Verkuil wrote: > > Add a missing 'depends on DRM' for the DRM_DP_CEC config > > option. Without that enabling DRM_DP_CEC will force CEC_CORE > > to =y instead of =m if DRM=m as well. > > > > Signed-off-by: Hans Verkuil > > Daniel, can you review this? It's annoying that the cec core is > compiled as part of the kernel when it can just be a module. Why did we even make this optional? Really worth it to compile out 4 functions and some change? Anyway the one you really want here is CONFIG_DRM_KMS_HELPER, but that is a selected variable, and you can't mix select and depends on because that breaks Kconfig in hilarious ways. Or so I thought, but other public symbols like this (e.g. DRM_FBDEV_EMULATION) do the same trick. So I guess Reviewed-by: Daniel Vetter But really, is all this complexity? -Daniel > > Regards, > > Hans > > > --- > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > > index 1168351267fd..e8e478d6da9c 100644 > > --- a/drivers/gpu/drm/Kconfig > > +++ b/drivers/gpu/drm/Kconfig > > @@ -163,6 +163,7 @@ config DRM_LOAD_EDID_FIRMWARE > > > > config DRM_DP_CEC > > bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support" > > + depends on DRM > > select CEC_CORE > > help > > Choose this option if you want to enable HDMI CEC support for > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] drm/radeon: have the callers of set_memory_*() check the return value
On Wed, Jan 08, 2020 at 01:56:47PM +0100, Christian König wrote: > Am 07.01.20 um 20:25 schrieb Tianlin Li: > > Right now several architectures allow their set_memory_*() family of > > functions to fail, but callers may not be checking the return values. > > If set_memory_*() returns with an error, call-site assumptions may be > > infact wrong to assume that it would either succeed or not succeed at > > all. Ideally, the failure of set_memory_*() should be passed up the > > call stack, and callers should examine the failure and deal with it. > > > > Need to fix the callers and add the __must_check attribute. They also > > may not provide any level of atomicity, in the sense that the memory > > protections may be left incomplete on failure. This issue likely has a > > few steps on effects architectures: > > 1)Have all callers of set_memory_*() helpers check the return value. > > 2)Add __must_check to all set_memory_*() helpers so that new uses do > > not ignore the return value. > > 3)Add atomicity to the calls so that the memory protections aren't left > > in a partial state. > > > > This series is part of step 1. Make drm/radeon check the return value of > > set_memory_*(). > > I'm a little hesitate merge that. This hardware is >15 years old and nobody > of the developers have any system left to test this change on. If that's true it should be removed from the tree. We need to be able to correctly make these kinds of changes in the kernel. > Would it be to much of a problem to just add something like: r = > set_memory_*(); (void)r; /* Intentionally ignored */. This seems like a bad idea -- we shouldn't be papering over failures like this when there is logic available to deal with it. > Apart from that certainly a good idea to add __must_check to the functions. Agreed! -Kees -- Kees Cook ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omapdrm: use BUG_ON macro for error debugging.
On Thu, Jan 02, 2020 at 12:55:15PM +0300, Wambui Karuga wrote:
> Since the if statement only checks for the value of the `id` variable,
> it can be replaced by the more concise BUG_ON() macro for error
> reporting.
> Issue found using coccinelle.
>
> Signed-off-by: Wambui Karuga
Tomi said he's ok with this landing in drm-misc-next on irc, so merged.
Thanks for your patch!
-Daniel
> ---
> drivers/gpu/drm/omapdrm/dss/dispc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 413dbdd1771e..dbb90f2d2ccd 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -393,8 +393,7 @@ static void dispc_get_reg_field(struct dispc_device
> *dispc,
> enum dispc_feat_reg_field id,
> u8 *start, u8 *end)
> {
> - if (id >= dispc->feat->num_reg_fields)
> - BUG();
> + BUG_ON(id >= dispc->feat->num_reg_fields);
>
> *start = dispc->feat->reg_fields[id].start;
> *end = dispc->feat->reg_fields[id].end;
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/drm_panel: fix export of drm_panel_of_backlight, try #3
Hi Arnd. > > > All of this is just another hack until the backlight config usage is > > > fixed for good. Do we really want to make this the example to copy paste > > > wherever we hit the issue next? > > > > > > I'm not naking, but I'm not acking either. > > > > I will try to take a look at your old BACKLIGHT_CLASS_DEVICE patch this > > weekend. I think we need that one fixed - and then we can have this mess > > with "drm_panel_of_backlight" fixed in the right way. > > I had also attempted to fix the larger mess around 'select' statements in > DRM/FB > around BACKLIGHT_CLASS_DEVICE several times in the past, and even at > some point sent a patch that was acked but never merged and later broke > because > of other changes. Any chance you have the patch around or can dig up a pointer? My google foo did not turn up anything. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/51] drm/bridge: Extend bridge API to disable connector creation
On 19/12/2019 12:44, Laurent Pinchart wrote:
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple components. For instance a
pipeline with a bridge connected to the DDC signals to read EDID data,
and another one connected to the HPD signal to detect connection and
disconnection, will not be possible to support through this model.
- It requires every bridge driver to implement similar connector
handling code, resulting in code duplication.
- It assumes that a bridge will either be wired to a connector or to
another bridge, but doesn't support bridges that can be used in both
positions very well (although there is some ad-hoc support for this in
the analogix_dp bridge driver).
In order to solve these issues, ownership of the connector should be
moved to the display controller driver (where it can be implemented
using helpers provided by the core).
Extend the bridge API to allow disabling connector creation in bridge
drivers as a first step towards the new model. The new flags argument to
the bridge .attach() operation allows instructing the bridge driver to
skip creating a connector. Unconditionally set the new flags argument to
0 for now to keep the existing behaviour, and modify all existing bridge
drivers to return an error when connector creation is not requested as
they don't support this feature yet.
The change is based on the following semantic patch, with manual review
and edits.
@ rule1 @
identifier funcs;
identifier fn;
@@
struct drm_bridge_funcs funcs = {
...,
.attach = fn
};
@ depends on rule1 @
identifier rule1.fn;
identifier bridge;
statement S, S1;
@@
int fn(
struct drm_bridge *bridge
+ , enum drm_bridge_attach_flags flags
)
{
... when != S
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+ DRM_ERROR("Fix bridge driver to make connector optional!");
+ return -EINVAL;
+ }
+
S1
...
}
@ depends on rule1 @
identifier rule1.fn;
identifier bridge, flags;
expression E1, E2, E3;
@@
int fn(
struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags
) {
<...
drm_bridge_attach(E1, E2, E3
+ , flags
)
...>
}
@@
expression E1, E2, E3;
@@
drm_bridge_attach(E1, E2, E3
+ , 0
)
Signed-off-by: Laurent Pinchart
Reviewed-by: Boris Brezillon
Acked-by: Sam Ravnborg
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/i915/gvt: make gvt oblivious of kvmgt data structures
On Wed, 2020-01-08 at 12:24 +0200, Jani Nikula wrote: > On Mon, 06 Jan 2020, Julian Stecklina > wrote: [...] > > + /* Hypervisor-specific device state. */ > > + void *vdev; > > I have no clue about the relative merits of the patch, but you can use > the actual type for the pointer with a forward declaration. You don't > need the definition for that. > > i.e. > > struct kvmgt_vdev; > ... > struct kvmgt_vdev *vdev; The goal here is to make the GVT code independent of the hypervisor backend. Different hypervisor backends need to keep different per-device state, so using the KVM type here defeats the purpose. I assume this is not only useful for us, but also for other hypervisor backends, such as Xen or 3rd-party hypervisors. Julian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 1967/2680] include/kcl/kcl_drm.h:313:9: error: implicit declaration of function 'drm_gem_object_unreference_unlocked'; did you mean 'drm_gem_object_put_unlocked'?
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: c3612b68d1358e8325c377ba5e1f690b39a6cea8 [1967/2680] drm/amdkcl: Test
whether drm_gem_object_put_unlocked() is available
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout c3612b68d1358e8325c377ba5e1f690b39a6cea8
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
return drm_encoder_init(dev, encoder, funcs,
^~~~
In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_atomic_helper.h:32,
from include/kcl/kcl_drm.h:10,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_encoder.h:183:5: note: declared here
int drm_encoder_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_crtc_init_with_planes':
include/kcl/kcl_drm.h:206:10: error: too few arguments to function
'drm_crtc_init_with_planes'
return drm_crtc_init_with_planes(dev, crtc, primary,
^
In file included from include/drm/drmP.h:68:0,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_crtc.h:1120:5: note: declared here
int drm_crtc_init_with_planes(struct drm_device *dev,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_universal_plane_init':
include/kcl/kcl_drm.h:227:29: error: incompatible type for argument 7 of
'drm_universal_plane_init'
formats, format_count, type);
^~~~
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drmP.h:68,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_plane.h:713:5: note: expected 'const uint64_t * {aka const
long long unsigned int *}' but argument is of type 'enum drm_plane_type'
int drm_universal_plane_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:226:10: error: too few arguments to function
'drm_universal_plane_init'
return drm_universal_plane_init(dev, plane, possible_crtcs, funcs,
^~~~
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drmP.h:68,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_plane.h:713:5: note: declared here
int drm_universal_plane_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_gem_object_lookup':
include/kcl/kcl_drm.h:238:32: error: passing argument 1 of
'drm_gem_object_lookup' from incompatible pointer type
[-Werror=incompatible-pointer-types]
return drm_gem_object_lookup(dev, filp, handle);
^~~
In file included from include/kcl/kcl_drm.h:9:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_gem.h:386:24: note: expected 'struct drm_file *' but
argument is of type 'struct drm_device *'
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:238:37: warning: passing argument 2 of
'drm_gem_object_lookup' makes integer from pointer without a cast
[-Wint-conversion]
return drm_gem_object_lookup(dev, filp, handle);
^~~~
In file included from include/kcl/kcl_drm.h:9:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_gem.h:386:24: note: expected 'u32 {aka unsigned int}' but
argument is of type 'struct drm_file *'
struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
handle);
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
Re: [PATCH] i915: fix backlight configuration issue
On Wed, 08 Jan 2020, Arnd Bergmann wrote:
> The i915 driver can use the backlight subsystem as an option, and usually
> selects it when CONFIG_ACPI is set. However it is possible to configure
> a kernel with modular backlight classdev support and a built-in i915
> driver, which leads to a linker error:
>
> drivers/gpu/drm/i915/display/intel_panel.o: In function
> `intel_backlight_device_register':
> intel_panel.c:(.text+0x2f58): undefined reference to
> `backlight_device_register'
> drivers/gpu/drm/i915/display/intel_panel.o: In function
> `intel_backlight_device_unregister':
> intel_panel.c:(.text+0x2fe4): undefined reference to
> `backlight_device_unregister'
>
> Add another Kconfig option to ensure the driver only tries to use
> the backlight support when it can in fact be linked that way. The
> new option is on by default to keep the existing behavior.
>
> This is roughly what other drivers like nouveau do as well.
>
> Signed-off-by: Arnd Bergmann
> ---
> I've had this one lying around for a long time, it is still needed
> but I am not sure which solution is best here. This version is
> probably the least invasive, but it does not solve the bigger
> problem around too many 'select' statements in drm
This is just another hack that's only required because backlight is
selected instead of depended on throughout the kernel. (*)
i915 (and most drm drivers, with some variations) could easily handle
this with:
depends on (ACPI && ACPI_VIDEO) || ACPI=n
depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
Those two lines express the allowed configurations. It's just that we
can't do that in i915 *alone*. The combinations of depends and selects
lead to impossible configurations. It's all or nothing.
I am not amused by adding more hacks, and I am really *not* interested
in adding another useless i915 config option to "solve" this issue.
So thanks, but no thanks. I'm not taking this patch.
BR,
Jani.
(*) The deeper issue is that people as well as the kconfig tools ignore
the warnings in Documentation/kbuild/kconfig-language.rst:
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
I don't think we can, uh, fix the people, but it might be possible to
warn about selecting visible symbols or symbols with dependencies.
> ---
> drivers/gpu/drm/i915/Kconfig | 11 ++-
> drivers/gpu/drm/i915/display/intel_panel.c | 4 ++--
> drivers/gpu/drm/i915/display/intel_panel.h | 6 +++---
> 3 files changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index ba9595960bbe..81d956040d18 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -16,7 +16,7 @@ config DRM_I915
> select IRQ_WORK
> # i915 depends on ACPI_VIDEO when ACPI is enabled
> # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> - select BACKLIGHT_CLASS_DEVICE if ACPI
> + select DRM_I915_BACKLIGHT if ACPI
> select INPUT if ACPI
> select ACPI_VIDEO if ACPI
> select ACPI_BUTTON if ACPI
> @@ -68,6 +68,15 @@ config DRM_I915_FORCE_PROBE
>
> Use "*" to force probe the driver for all known devices.
>
> +config DRM_I915_BACKLIGHT
> + tristate "Control backlight support"
> + depends on DRM_I915
> + default DRM_I915
> + select BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to control the backlight of your display
> + (e.g. a laptop panel).
> +
> config DRM_I915_CAPTURE_ERROR
> bool "Enable capturing GPU state following a hang"
> depends on DRM_I915
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index 7b3ec6eb3382..e2fe7a50dcbf 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -1203,7 +1203,7 @@ void intel_panel_enable_backlight(const struct
> intel_crtc_state *crtc_state,
> mutex_unlock(_priv->backlight_lock);
> }
>
> -#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
> +#if IS_ENABLED(CONFIG_DRM_I915_BACKLIGHT)
> static u32 intel_panel_get_backlight(struct intel_connector *connector)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> @@ -1370,7 +1370,7 @@ void intel_backlight_device_unregister(struct
> intel_connector *connector)
> panel->backlight.device = NULL;
> }
> }
> -#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
> +#endif /* CONFIG_DRM_I915_BACKLIGHT */
>
> /*
> * CNP: PWM
[Bug 206017] Kernel 5.4.x unusable with GUI due to crashes (some hard)
https://bugzilla.kernel.org/show_bug.cgi?id=206017 udo (udo...@xs4all.nl) changed: What|Removed |Added Severity|high|blocking --- Comment #11 from udo (udo...@xs4all.nl) --- I.e.: it is stable and working OK with e.g. mkv playing. Then we start Firefox and boom. System freezes, -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/bridge: chrontel-ch7033: Add a new driver
Hi Lubomir,
Thank you for the patch.
On Fri, Dec 20, 2019 at 08:49:14AM +0100, Lubomir Rintel wrote:
> This is a driver for video encoder with VGA and DVI/HDMI outputs.
>
> There is no documentation for the chip -- the operation was guessed from
> what was sniffed on a Dell Wyse 3020 ThinOS terminal, the register names
> come from the ch7035 driver in Mediatek's GPL code dump.
>
> Only bare minimum is implemented -- no fancy stuff, such as scaling. That
> would only worsen our misery. We don't load the firmware and we don't need
> to even bother enabling the MCU. There are probably no distributable
> firmware images anyway.
>
> Just like the tda998x driver, this one uses the component framework and
> adds an encoder on component bind, so that it works with the Armada DRM
> driver.
Any chance the Armada DRM driver could use of_drm_find_bridge() to avoid
having to use the component framework everywhere ?
> Tested with a handful of monitors ranging from 1024x768@75 to 1400x1050@60,
> with VGA as well as DVI.
>
> Signed-off-by: Lubomir Rintel
> ---
> drivers/gpu/drm/bridge/Kconfig | 10 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/chrontel-ch7033.c | 722 +++
> 3 files changed, 733 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/chrontel-ch7033.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 34362976cd6fd..9456ea968c5b7 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -37,6 +37,16 @@ config DRM_CDNS_DSI
> Support Cadence DPI to DSI bridge. This is an internal
> bridge and is meant to be directly embedded in a SoC.
>
> +config DRM_CHRONTEL_CH7033
> + tristate "Chrontel CH7033 Video Encoder"
> + depends on OF
> + select DRM_KMS_HELPER
> + help
> + Enable support for the Chrontel CH7033 VGA/DVI/HDMI Encoder, as
> + found in the Dell Wyse 3020 thin client.
> +
> + If in doubt, say "N".
> +
> config DRM_DUMB_VGA_DAC
> tristate "Dumb VGA DAC Bridge support"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf5a6f82..74a9ab2f17468 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> +obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
> obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> megachips-stdp-ge-b850v3-fw.o
> diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c
> b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> new file mode 100644
> index 0..a3b63984226a4
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
> @@ -0,0 +1,722 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Chrontel CH7033 Video Encoder Driver
> + *
> + * Copyright (C) 2019 Lubomir Rintel
> + */
> +
> +#include
> +#include
> +#include
Could you please sort these alphabetically ?
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Page 0, Register 0x07 */
> +enum {
> + DRI_PD = BIT(3),
> + IO_PD = BIT(5),
> +};
> +
> +/* Page 0, Register 0x08 */
> +enum {
> + DRI_PDDRI = GENMASK(7, 4),
> + PDDAC = GENMASK(3, 1),
> + PANEN = BIT(0),
> +};
> +
> +/* Page 0, Register 0x09 */
> +enum {
> + DPD = BIT(7),
> + GCKOFF = BIT(6),
> + TV_BP = BIT(5),
> + SCLPD = BIT(4),
> + SDPD= BIT(3),
> + VGA_PD = BIT(2),
> + HDBKPD = BIT(1),
> + HDMI_PD = BIT(0),
> +};
> +
> +/* Page 0, Register 0x0a */
> +enum {
> + MEMINIT = BIT(7),
> + MEMIDLE = BIT(6),
> + MEMPD = BIT(5),
> + STOP= BIT(4),
> + LVDS_PD = BIT(3),
> + HD_DVIB = BIT(2),
> + HDCP_PD = BIT(1),
> + MCU_PD = BIT(0),
> +};
> +
> +/* Page 0, Register 0x18 */
> +enum {
> + IDF = GENMASK(7, 4),
> + INTEN = BIT(3),
> + SWAP= GENMASK(2, 0),
> +};
> +
> +enum {
> + BYTE_SWAP_RGB = 0,
> + BYTE_SWAP_RBG = 1,
> + BYTE_SWAP_GRB = 2,
> + BYTE_SWAP_GBR = 3,
> + BYTE_SWAP_BRG = 4,
> + BYTE_SWAP_BGR = 5,
> +};
> +
> +/* Page 0, Register 0x19 */
> +enum {
> + HPO_I = BIT(5),
> + VPO_I = BIT(4),
> + DEPO_I = BIT(3),
> + CRYS_EN = BIT(2),
> + GCLKFREQ= GENMASK(2, 0),
> +};
> +
> +/* Page 0, Register 0x2e */
> +enum {
> + HFLIP = BIT(7),
> + VFLIP = BIT(6),
> + DEPO_O = BIT(5),
> +
Re: [Intel-gfx] [PATCH 1/5] drm/i915: convert to using the drm_dbg_kms() macro.
Quoting Jani Nikula (2020-01-08 14:44:38)
> On Wed, 08 Jan 2020, Chris Wilson wrote:
> > Quoting Jani Nikula (2020-01-08 09:40:40)
> >> On Wed, 08 Jan 2020, Joonas Lahtinen
> >> wrote:
> >> > Quoting Wambui Karuga (2020-01-07 17:13:29)
> >> >> Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
> >> >> drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c.
> >> >>
> >> >> Signed-off-by: Wambui Karuga
> >> >> ---
> >> >> drivers/gpu/drm/i915/intel_pch.c | 46 +---
> >> >> 1 file changed, 24 insertions(+), 22 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/intel_pch.c
> >> >> b/drivers/gpu/drm/i915/intel_pch.c
> >> >> index 43b68b5fc562..4ed60e1f01db 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_pch.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_pch.c
> >> >> @@ -12,90 +12,91 @@ intel_pch_type(const struct drm_i915_private
> >> >> *dev_priv, unsigned short id)
> >> >> {
> >> >> switch (id) {
> >> >> case INTEL_PCH_IBX_DEVICE_ID_TYPE:
> >> >> - DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> >> >> + drm_dbg_kms(_priv->drm, "Found Ibex Peak PCH\n");
> >> >
> >> > Did we at some point consider i915_dbg_kms alias? That would just take
> >> > dev_priv (or i915, as it's called in newer code). It would shorten many
> >> > of the statements.
> >> >
> >> > i915_dbg_kms(dev_priv, ...) or i915_dbg_kms(i915, ...)
> >>
> >> I'd rather use the common drm logging macros. I thought about adding
> >> i915 specific ones only if the drm device specific logging macros
> >> weren't going to be merged.
> >
> > Why do they even exist? Why isn't it enough to do
> > #define drm_info(drm, fmt, ...) dev_info(&(drm)->dev, fmt, ##__VA_ARGS) ?
>
> It *is* enough to do that, and that's essentially what the new macros
> do, just with an extra helper macro in between.
/o\
Mistook __drm_printk() for the older drm_dev_printk()
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 1966/2680] include/kcl/kcl_drm.h:281:8: error: redefinition of 'struct drm_format_name_buf'
Hi Yifan,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: 757a363a37449c5b612b3c7c3f62be125b1282e3 [1966/2680] drm/amdkcl: Test
whether drm_get_format_name() is available
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout 757a363a37449c5b612b3c7c3f62be125b1282e3
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
include/kcl/kcl_drm.h:98:1: error: conflicting types for
'drm_fb_helper_remove_conflicting_framebuffers'
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from include/kcl/kcl_drm.h:7:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_fb_helper.h:589:1: note: previous definition of
'drm_fb_helper_remove_conflicting_framebuffers' was here
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_encoder_init':
include/kcl/kcl_drm.h:191:9: error: too few arguments to function
'drm_encoder_init'
return drm_encoder_init(dev, encoder, funcs,
^~~~
In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_atomic_helper.h:32,
from include/kcl/kcl_drm.h:10,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_encoder.h:183:5: note: declared here
int drm_encoder_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_crtc_init_with_planes':
include/kcl/kcl_drm.h:206:10: error: too few arguments to function
'drm_crtc_init_with_planes'
return drm_crtc_init_with_planes(dev, crtc, primary,
^
In file included from include/drm/drmP.h:68:0,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_crtc.h:1120:5: note: declared here
int drm_crtc_init_with_planes(struct drm_device *dev,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_universal_plane_init':
include/kcl/kcl_drm.h:227:29: error: incompatible type for argument 7 of
'drm_universal_plane_init'
formats, format_count, type);
^~~~
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drmP.h:68,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_plane.h:713:5: note: expected 'const uint64_t * {aka const
long long unsigned int *}' but argument is of type 'enum drm_plane_type'
int drm_universal_plane_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:226:10: error: too few arguments to function
'drm_universal_plane_init'
return drm_universal_plane_init(dev, plane, possible_crtcs, funcs,
^~~~
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drmP.h:68,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_plane.h:713:5: note: declared here
int drm_universal_plane_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_gem_object_lookup':
include/kcl/kcl_drm.h:238:32: error: passing argument 1 of
'drm_gem_object_lookup' from incompatible pointer type
[-Werror=incompatible-pointer-types]
return drm_gem_object_lookup(dev, filp, handle);
^~~
In file included from include/kcl/kcl_drm.h:9:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_gem.h:386:24: note: expected 'struct drm_file *' but
argument is of type 'struct drm_device *'
struct drm_gem_object
Re: [Intel-gfx] [PATCH 1/5] drm/i915: convert to using the drm_dbg_kms() macro.
On Wed, 08 Jan 2020, Chris Wilson wrote:
> Quoting Jani Nikula (2020-01-08 09:40:40)
>> On Wed, 08 Jan 2020, Joonas Lahtinen wrote:
>> > Quoting Wambui Karuga (2020-01-07 17:13:29)
>> >> Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
>> >> drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c.
>> >>
>> >> Signed-off-by: Wambui Karuga
>> >> ---
>> >> drivers/gpu/drm/i915/intel_pch.c | 46 +---
>> >> 1 file changed, 24 insertions(+), 22 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_pch.c
>> >> b/drivers/gpu/drm/i915/intel_pch.c
>> >> index 43b68b5fc562..4ed60e1f01db 100644
>> >> --- a/drivers/gpu/drm/i915/intel_pch.c
>> >> +++ b/drivers/gpu/drm/i915/intel_pch.c
>> >> @@ -12,90 +12,91 @@ intel_pch_type(const struct drm_i915_private
>> >> *dev_priv, unsigned short id)
>> >> {
>> >> switch (id) {
>> >> case INTEL_PCH_IBX_DEVICE_ID_TYPE:
>> >> - DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
>> >> + drm_dbg_kms(_priv->drm, "Found Ibex Peak PCH\n");
>> >
>> > Did we at some point consider i915_dbg_kms alias? That would just take
>> > dev_priv (or i915, as it's called in newer code). It would shorten many
>> > of the statements.
>> >
>> > i915_dbg_kms(dev_priv, ...) or i915_dbg_kms(i915, ...)
>>
>> I'd rather use the common drm logging macros. I thought about adding
>> i915 specific ones only if the drm device specific logging macros
>> weren't going to be merged.
>
> Why do they even exist? Why isn't it enough to do
> #define drm_info(drm, fmt, ...) dev_info(&(drm)->dev, fmt, ##__VA_ARGS) ?
It *is* enough to do that, and that's essentially what the new macros
do, just with an extra helper macro in between.
> #define i915_info(i915, fmt, ...) drm_info(&(i915)->drm, fmt, ##__VA_ARGS)
>
> The lea for >drm.dev is the same as the mov, so we shave off an
> unnecessary wrapper.
I was hoping to avoid having our own aliases and abstractions of
everything, and instead making the drm macros do what we want. I mean I
could've just ignored drm completely, add our own hacks and convert the
driver...
Sure, there's the boilerplate of dereferencing >drm, but in many
places we already have struct drm_device * available too.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] dt-bindings: display: Add Chrontel CH7033 Video Encoder binding
On Fri, Dec 20, 2019 at 08:49:13AM +0100, Lubomir Rintel wrote:
> Add binding document for the Chrontel CH7033 VGA/DVI/HDMI Encoder.
>
> Signed-off-by: Lubomir Rintel
> ---
> .../display/bridge/chrontel,ch7033.yaml | 86 +++
> 1 file changed, 86 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
> b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
> new file mode 100644
> index 0..f19b336a99c78
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/chrontel,ch7033.yaml
> @@ -0,0 +1,86 @@
> +# SPDX-License-Identifier: GPL-2.0-only
Dual license new bindings:
(GPL-2.0-only OR BSD-2-Clause)
With that,
Reviewed-by: Rob Herring
> +# Copyright (C) 2019 Lubomir Rintel
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/chrontel,ch7033.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Chrontel CH7033 Video Encoder Device Tree Bindings
> +
> +maintainers:
> + - Lubomir Rintel
> +
> +properties:
> + compatible:
> +const: chrontel,ch7033
> +
> + reg:
> +maxItems: 1
> +description: I2C address of the device
> +
> + ports:
> +type: object
> +
> +properties:
> + port@0:
> +type: object
> +description: |
> + Video port for RGB input.
> +
> + port@1:
> +type: object
> +description: |
> + DVI port, should be connected to a node compatible with the
> + dvi-connector binding.
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +dvi-connector {
> +compatible = "dvi-connector";
> +ddc-i2c-bus = <>;
> +hpd-gpios = < 62 GPIO_ACTIVE_LOW>;
> +digital;
> +analog;
> +
> +port {
> +dvi_in: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +};
> +
> +vga-dvi-encoder@76 {
> +compatible = "chrontel,ch7033";
> +reg = <0x76>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +endpoint {
> +remote-endpoint = <_rgb_out>;
> +};
> +};
> +
> +encoder_out: port@1 {
> +reg = <1>;
> +endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +
> +};
> +};
> --
> 2.24.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFT v1 1/3] drm/panfrost: enable devfreq based the "operating-points-v2" property
[ +Sudeep ] On 08/01/2020 12:38 pm, Martin Blumenstingl wrote: Hi Robin, On Wed, Jan 8, 2020 at 12:18 PM Robin Murphy wrote: On 07/01/2020 11:06 pm, Martin Blumenstingl wrote: Decouple the check to see whether we want to enable devfreq for the GPU from dev_pm_opp_set_regulators(). This is preparation work for adding back support for regulator control (which means we need to call dev_pm_opp_set_regulators() before dev_pm_opp_of_add_table(), which means having a check for "is devfreq enabled" that is not tied to dev_pm_opp_of_add_table() makes things easier). Hmm, what about cases like the SCMI DVFS protocol where the OPPs are dynamically discovered rather than statically defined in DT? where can I find such an example (Amlogic SoCs use SCPI instead of SCMI, so I don't think that I have any board with SCMI support) or some documentation? (I could only find SCPI clock and CPU DVFS implementations, but no generic "OPPs for any device" implementation) On closer inspection I think this applies to the SCPI DVFS protocol too[1]. AIUI the fact that neither is wired up to a devfreq driver yet is merely due to lack of demand and suitable systems to develop/test on so far - the panfrost devfreq code is only now looking like the first viable upstream use-case ;) Robin. [1] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922g/BABFEBCD.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dt-bindings: Add vendor prefix for Chrontel, Inc.
On Fri, 20 Dec 2019 08:49:12 +0100, Lubomir Rintel wrote: > > Chrontel makes encoders for video displays and perhaps other stuff. > Their web site is http://www.chrontel.com/. > > Signed-off-by: Lubomir Rintel > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] i915: fix backlight configuration issue
The i915 driver can use the backlight subsystem as an option, and usually
selects it when CONFIG_ACPI is set. However it is possible to configure
a kernel with modular backlight classdev support and a built-in i915
driver, which leads to a linker error:
drivers/gpu/drm/i915/display/intel_panel.o: In function
`intel_backlight_device_register':
intel_panel.c:(.text+0x2f58): undefined reference to `backlight_device_register'
drivers/gpu/drm/i915/display/intel_panel.o: In function
`intel_backlight_device_unregister':
intel_panel.c:(.text+0x2fe4): undefined reference to
`backlight_device_unregister'
Add another Kconfig option to ensure the driver only tries to use
the backlight support when it can in fact be linked that way. The
new option is on by default to keep the existing behavior.
This is roughly what other drivers like nouveau do as well.
Signed-off-by: Arnd Bergmann
---
I've had this one lying around for a long time, it is still needed
but I am not sure which solution is best here. This version is
probably the least invasive, but it does not solve the bigger
problem around too many 'select' statements in drm
---
drivers/gpu/drm/i915/Kconfig | 11 ++-
drivers/gpu/drm/i915/display/intel_panel.c | 4 ++--
drivers/gpu/drm/i915/display/intel_panel.h | 6 +++---
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index ba9595960bbe..81d956040d18 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -16,7 +16,7 @@ config DRM_I915
select IRQ_WORK
# i915 depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
- select BACKLIGHT_CLASS_DEVICE if ACPI
+ select DRM_I915_BACKLIGHT if ACPI
select INPUT if ACPI
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
@@ -68,6 +68,15 @@ config DRM_I915_FORCE_PROBE
Use "*" to force probe the driver for all known devices.
+config DRM_I915_BACKLIGHT
+ tristate "Control backlight support"
+ depends on DRM_I915
+ default DRM_I915
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to control the backlight of your display
+ (e.g. a laptop panel).
+
config DRM_I915_CAPTURE_ERROR
bool "Enable capturing GPU state following a hang"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 7b3ec6eb3382..e2fe7a50dcbf 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1203,7 +1203,7 @@ void intel_panel_enable_backlight(const struct
intel_crtc_state *crtc_state,
mutex_unlock(_priv->backlight_lock);
}
-#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
+#if IS_ENABLED(CONFIG_DRM_I915_BACKLIGHT)
static u32 intel_panel_get_backlight(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -1370,7 +1370,7 @@ void intel_backlight_device_unregister(struct
intel_connector *connector)
panel->backlight.device = NULL;
}
}
-#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
+#endif /* CONFIG_DRM_I915_BACKLIGHT */
/*
* CNP: PWM clock frequency is 19.2 MHz or 24 MHz.
diff --git a/drivers/gpu/drm/i915/display/intel_panel.h
b/drivers/gpu/drm/i915/display/intel_panel.h
index cedeea443336..e6e81268b7ed 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.h
+++ b/drivers/gpu/drm/i915/display/intel_panel.h
@@ -49,10 +49,10 @@ intel_panel_edid_fixed_mode(struct intel_connector
*connector);
struct drm_display_mode *
intel_panel_vbt_fixed_mode(struct intel_connector *connector);
-#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
+#if IS_ENABLED(CONFIG_DRM_I915_BACKLIGHT)
int intel_backlight_device_register(struct intel_connector *connector);
void intel_backlight_device_unregister(struct intel_connector *connector);
-#else /* CONFIG_BACKLIGHT_CLASS_DEVICE */
+#else /* CONFIG_DRM_I915_BACKLIGHT */
static inline int intel_backlight_device_register(struct intel_connector
*connector)
{
return 0;
@@ -60,6 +60,6 @@ static inline int intel_backlight_device_register(struct
intel_connector *connec
static inline void intel_backlight_device_unregister(struct intel_connector
*connector)
{
}
-#endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
+#endif /* CONFIG_DRM_I915_BACKLIGHT */
#endif /* __INTEL_PANEL_H__ */
--
2.20.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [v2] drm: panel: fix excessive stack usage in td028ttec1_prepare
With gcc -O3 in combination with the structleak plug, the compiler can
inline very aggressively, leading to rather large stack usage:
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c: In function 'td028ttec1_prepare':
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c:233:1: error: the frame size of
2768 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
}
Marking jbt_reg_write_*() as noinline avoids the case where
multiple instances of this function get inlined into the same
stack frame and each one adds a copy of 'tx_buf'.
The compiler is clearly making some bad decisions here, but I
did not open a new bug report as this only happens in combination
with the structleak plugin.
Link:
https://lore.kernel.org/lkml/cak8p3a3janfza3gfrtdydg1-i-oih3poqzkkrk-x3bgsfrm...@mail.gmail.com/
Fixes: mmtom ("init/Kconfig: enable -O3 for all arches")
Signed-off-by: Arnd Bergmann
---
v2:
- mark all three functions as noinlien
- add code comment
- add link to more detailed analysis
---
drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
index cf29405a2dbe..5034db8b55de 100644
--- a/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/panel/panel-tpo-td028ttec1.c
@@ -86,7 +86,12 @@ struct td028ttec1_panel {
#define to_td028ttec1_device(p) container_of(p, struct td028ttec1_panel, panel)
-static int jbt_ret_write_0(struct td028ttec1_panel *lcd, u8 reg, int *err)
+/*
+ * noinline_for_stack so we don't get multiple copies of tx_buf
+ * on the stack in case of gcc-plugin-structleak
+ */
+static int noinline_for_stack
+jbt_ret_write_0(struct td028ttec1_panel *lcd, u8 reg, int *err)
{
struct spi_device *spi = lcd->spi;
u16 tx_buf = JBT_COMMAND | reg;
@@ -105,7 +110,8 @@ static int jbt_ret_write_0(struct td028ttec1_panel *lcd, u8
reg, int *err)
return ret;
}
-static int jbt_reg_write_1(struct td028ttec1_panel *lcd,
+static int noinline_for_stack
+jbt_reg_write_1(struct td028ttec1_panel *lcd,
u8 reg, u8 data, int *err)
{
struct spi_device *spi = lcd->spi;
@@ -128,7 +134,8 @@ static int jbt_reg_write_1(struct td028ttec1_panel *lcd,
return ret;
}
-static int jbt_reg_write_2(struct td028ttec1_panel *lcd,
+static int noinline_for_stack
+jbt_reg_write_2(struct td028ttec1_panel *lcd,
u8 reg, u16 data, int *err)
{
struct spi_device *spi = lcd->spi;
--
2.20.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH next] drm/i915/gtt: add missing include file asm/smp.h
On Wed, 08 Jan 2020, Chen Zhou wrote: > Fix build error: > lib/crypto/chacha.c: In function chacha_permute: > lib/crypto/chacha.c:65:1: warning: the frame size of 3384 bytes is larger > than 2048 bytes [-Wframe-larger-than=] > } > ^ IMO this needs a better explanation of why not having the include leads to the above failure. BR, Jani. > > Reported-by: Hulk Robot > Signed-off-by: Chen Zhou > --- > drivers/gpu/drm/i915/gt/intel_ggtt.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c > b/drivers/gpu/drm/i915/gt/intel_ggtt.c > index 1a2b5dc..9ef8ed8 100644 > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c > @@ -6,6 +6,7 @@ > #include > > #include > +#include > > #include "intel_gt.h" > #include "i915_drv.h" -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/7] drm/panfrost: Add support for a second regulator for the GPU
On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> regulator for their SRAM, let's add support for that.
> + pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev, "sram");
> + if (IS_ERR(pfdev->regulator_sram)) {
This supply is required for the devices that need it so I'd therefore
expect the driver to request the supply non-optionally based on the
compatible string rather than just hoping that a missing regulator isn't
important. Though I do have to wonder given the lack of any active
management of the supply if this is *really* part of the GPU or if it's
more of a SoC thing, it's not clear what exactly adding this code is
achieving.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 1965/2680] include/kcl/kcl_drm.h:238:32: error: passing argument 1 of 'drm_gem_object_lookup' from incompatible pointer type
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: c450088041e3378cd3b78d99169e9bca8fd20a5b [1965/2680] drm/amdkcl: Test
whether drm_gem_object_lookup() wants 2 args
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout c450088041e3378cd3b78d99169e9bca8fd20a5b
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:98:1: error: conflicting types for
'drm_fb_helper_remove_conflicting_framebuffers'
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from include/kcl/kcl_drm.h:7:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_fb_helper.h:589:1: note: previous definition of
'drm_fb_helper_remove_conflicting_framebuffers' was here
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_encoder_init':
include/kcl/kcl_drm.h:191:9: error: too few arguments to function
'drm_encoder_init'
return drm_encoder_init(dev, encoder, funcs,
^~~~
In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_atomic_helper.h:32,
from include/kcl/kcl_drm.h:10,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_encoder.h:183:5: note: declared here
int drm_encoder_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_crtc_init_with_planes':
include/kcl/kcl_drm.h:206:10: error: too few arguments to function
'drm_crtc_init_with_planes'
return drm_crtc_init_with_planes(dev, crtc, primary,
^
In file included from include/drm/drmP.h:68:0,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_crtc.h:1120:5: note: declared here
int drm_crtc_init_with_planes(struct drm_device *dev,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_universal_plane_init':
include/kcl/kcl_drm.h:227:29: error: incompatible type for argument 7 of
'drm_universal_plane_init'
formats, format_count, type);
^~~~
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drmP.h:68,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_plane.h:713:5: note: expected 'const uint64_t * {aka const
long long unsigned int *}' but argument is of type 'enum drm_plane_type'
int drm_universal_plane_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:226:10: error: too few arguments to function
'drm_universal_plane_init'
return drm_universal_plane_init(dev, plane, possible_crtcs, funcs,
^~~~
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drmP.h:68,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_plane.h:713:5: note: declared here
int drm_universal_plane_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_gem_object_lookup':
>> include/kcl/kcl_drm.h:238:32: error: passing argument 1 of
>> 'drm_gem_object_lookup' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
return drm_gem_object_lookup(dev, filp, handle);
^~~
In file included from include/kcl/kcl_drm.h:9:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_gem.h:386:24: note: expected 'struct drm_file *' but
argument is of type
Re: [PATCH 0/2] drm/radeon: have the callers of set_memory_*() check the return value
Am 07.01.20 um 20:25 schrieb Tianlin Li: Right now several architectures allow their set_memory_*() family of functions to fail, but callers may not be checking the return values. If set_memory_*() returns with an error, call-site assumptions may be infact wrong to assume that it would either succeed or not succeed at all. Ideally, the failure of set_memory_*() should be passed up the call stack, and callers should examine the failure and deal with it. Need to fix the callers and add the __must_check attribute. They also may not provide any level of atomicity, in the sense that the memory protections may be left incomplete on failure. This issue likely has a few steps on effects architectures: 1)Have all callers of set_memory_*() helpers check the return value. 2)Add __must_check to all set_memory_*() helpers so that new uses do not ignore the return value. 3)Add atomicity to the calls so that the memory protections aren't left in a partial state. This series is part of step 1. Make drm/radeon check the return value of set_memory_*(). I'm a little hesitate merge that. This hardware is >15 years old and nobody of the developers have any system left to test this change on. Would it be to much of a problem to just add something like: r = set_memory_*(); (void)r; /* Intentionally ignored */. Apart from that certainly a good idea to add __must_check to the functions. Regards, Christian. Tianlin Li (2): drm/radeon: have the callers of set_memory_*() check the return value drm/radeon: change call sites to handle return value properly. drivers/gpu/drm/radeon/r100.c| 3 ++- drivers/gpu/drm/radeon/radeon.h | 2 +- drivers/gpu/drm/radeon/radeon_gart.c | 22 ++ drivers/gpu/drm/radeon/rs400.c | 3 ++- 4 files changed, 23 insertions(+), 7 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fwd: [PATCH] drm/i915: Fix enable OA report logic
On Wed, 08 Jan 2020, Andy Shevchenko wrote:
> I forwarding this to a (sub)set of correct MLs/maintainers. Please,
> follow the instructions they give.
Thanks, already fixed by commit 9278bbb6e43c ("drm/i915/perf: Reverse a
ternary to make sparse happy") in our -next.
BR,
Jani.
>
> -- Forwarded message -
> From: Ebrahim Byagowi
> Date: Mon, Dec 23, 2019 at 12:17 PM
> Subject: [PATCH] drm/i915: Fix enable OA report logic
> To:
>
>
>
> Clang raises
>
> drivers/gpu/drm/i915/i915_perf.c:2474:50: warning: operator '?:' has
> lower precedence than '|'; '|' will be evaluated first
> [-Wbitwise-conditional-parentheses]
> !(stream->sample_flags & SAMPLE_OA_REPORT) ?
> ~~ ^
> drivers/gpu/drm/i915/i915_perf.c:2474:50: note: place parentheses
> around the '|' expression to silence this warning
> !(stream->sample_flags & SAMPLE_OA_REPORT) ?
> ~~ ^
> drivers/gpu/drm/i915/i915_perf.c:2474:50: note: place parentheses
> around the '?:' expression to evaluate it first
> !(stream->sample_flags & SAMPLE_OA_REPORT) ?
> ~~~^
>
> with -Wbitwise-conditional-parentheses and apparently is right
> as '|' is evaluated before '?:' which doesn't seem to be the intention
> here so let's put parentheses in the right place to fix it.
>
> Signed-off-by: Ebrahim Byagowi
> ---
> drivers/gpu/drm/i915/i915_perf.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 2ae14bc14931..db963f7c2e2e 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -2471,9 +2471,9 @@ static int gen12_enable_metric_set(struct
> i915_perf_stream *stream)
> * If the user didn't require OA reports,
> instruct the
> * hardware not to emit ctx switch reports.
> */
> - !(stream->sample_flags & SAMPLE_OA_REPORT) ?
> -
> _MASKED_BIT_ENABLE(GEN12_OAG_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS) :
> -
> _MASKED_BIT_DISABLE(GEN12_OAG_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS));
> + (!(stream->sample_flags & SAMPLE_OA_REPORT) ?
> +
> _MASKED_BIT_ENABLE(GEN12_OAG_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS) :
> +
> _MASKED_BIT_DISABLE(GEN12_OAG_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS)));
>
> intel_uncore_write(uncore, GEN12_OAG_OAGLBCTXCTRL, periodic ?
>(GEN12_OAG_OAGLBCTXCTRL_COUNTER_RESUME |
> --
> 2.24.0
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Fwd: [PATCH] drm/i915: Fix enable OA report logic
I forwarding this to a (sub)set of correct MLs/maintainers. Please, follow the instructions they give. -- Forwarded message - From: Ebrahim Byagowi Date: Mon, Dec 23, 2019 at 12:17 PM Subject: [PATCH] drm/i915: Fix enable OA report logic To: Clang raises drivers/gpu/drm/i915/i915_perf.c:2474:50: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] !(stream->sample_flags & SAMPLE_OA_REPORT) ? ~~ ^ drivers/gpu/drm/i915/i915_perf.c:2474:50: note: place parentheses around the '|' expression to silence this warning !(stream->sample_flags & SAMPLE_OA_REPORT) ? ~~ ^ drivers/gpu/drm/i915/i915_perf.c:2474:50: note: place parentheses around the '?:' expression to evaluate it first !(stream->sample_flags & SAMPLE_OA_REPORT) ? ~~~^ with -Wbitwise-conditional-parentheses and apparently is right as '|' is evaluated before '?:' which doesn't seem to be the intention here so let's put parentheses in the right place to fix it. Signed-off-by: Ebrahim Byagowi --- drivers/gpu/drm/i915/i915_perf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index 2ae14bc14931..db963f7c2e2e 100644 --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -2471,9 +2471,9 @@ static int gen12_enable_metric_set(struct i915_perf_stream *stream) * If the user didn't require OA reports, instruct the * hardware not to emit ctx switch reports. */ - !(stream->sample_flags & SAMPLE_OA_REPORT) ? - _MASKED_BIT_ENABLE(GEN12_OAG_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS) : - _MASKED_BIT_DISABLE(GEN12_OAG_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS)); + (!(stream->sample_flags & SAMPLE_OA_REPORT) ? + _MASKED_BIT_ENABLE(GEN12_OAG_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS) : + _MASKED_BIT_DISABLE(GEN12_OAG_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS))); intel_uncore_write(uncore, GEN12_OAG_OAGLBCTXCTRL, periodic ? (GEN12_OAG_OAGLBCTXCTRL_COUNTER_RESUME | -- 2.24.0 -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 1964/2680] include/kcl/kcl_drm.h:227:29: error: incompatible type for argument 7 of 'drm_universal_plane_init'
Hi Slava,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: aa5f7e64d5afdf1b60cb7594bc78632997b6eb38 [1964/2680] drm/amdkcl: Test
whether drm_universal_plane_init() wants 9 args or 8 args
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout aa5f7e64d5afdf1b60cb7594bc78632997b6eb38
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:98:1: error: conflicting types for
'drm_fb_helper_remove_conflicting_framebuffers'
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from include/kcl/kcl_drm.h:7:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_fb_helper.h:589:1: note: previous definition of
'drm_fb_helper_remove_conflicting_framebuffers' was here
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_encoder_init':
include/kcl/kcl_drm.h:191:9: error: too few arguments to function
'drm_encoder_init'
return drm_encoder_init(dev, encoder, funcs,
^~~~
In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_atomic_helper.h:32,
from include/kcl/kcl_drm.h:10,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_encoder.h:183:5: note: declared here
int drm_encoder_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_crtc_init_with_planes':
include/kcl/kcl_drm.h:206:10: error: too few arguments to function
'drm_crtc_init_with_planes'
return drm_crtc_init_with_planes(dev, crtc, primary,
^
In file included from include/drm/drmP.h:68:0,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_crtc.h:1120:5: note: declared here
int drm_crtc_init_with_planes(struct drm_device *dev,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_universal_plane_init':
>> include/kcl/kcl_drm.h:227:29: error: incompatible type for argument 7 of
>> 'drm_universal_plane_init'
formats, format_count, type);
^~~~
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drmP.h:68,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_plane.h:713:5: note: expected 'const uint64_t * {aka const
long long unsigned int *}' but argument is of type 'enum drm_plane_type'
int drm_universal_plane_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
>> include/kcl/kcl_drm.h:226:10: error: too few arguments to function
>> 'drm_universal_plane_init'
return drm_universal_plane_init(dev, plane, possible_crtcs, funcs,
^~~~
In file included from include/drm/drm_crtc.h:45:0,
from include/drm/drmP.h:68,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_plane.h:713:5: note: declared here
int drm_universal_plane_init(struct drm_device *dev,
^~~~
vim +/drm_universal_plane_init +227 include/kcl/kcl_drm.h
950c9c93299ece Junwei Zhang 2016-12-23 210
950c9c93299ece Junwei Zhang 2016-12-23 211 static inline int
kcl_drm_universal_plane_init(struct drm_device *dev, struct drm_plane *plane,
950c9c93299ece Junwei Zhang 2016-12-23 212unsigned
long possible_crtcs,
950c9c93299ece Junwei Zhang 2016-12-23 213const
struct drm_plane_funcs *funcs,
950c9c93299ece Junwei Zhang 2016-12-23 214const
uint32_t *formats, unsigned int format_count,
7e18f7a415538c Evan
Re: Process identical patches in different tree
On 08/01/2020 12:14, Matthias Brugger wrote: > Hi CK, > > On 07/01/2020 03:56, CK Hu wrote: >> Hi, Dave, Daniel, Matthias: >> >> In mediatek-drm-next-5.6 [1], I've cherry-pick 3 patches from >> v5.5-next/soc [2] because some drm patches depend on these cmdq patches. >> So these cmdq patches exist in both tree now. I want to know how to >> process this case. I think we could choose one of below way: >> >> 1. Because these cmdq patches are identical in both tree, so each tree >> could do its own upstream and the there would be nothing happen when >> merge. >> 2. Let soc upstream first, and mediatek drm rebase on the latest >> mainline then upstream. >> >> Which one do you prefer? >> > > What we would need is a stable branch with this commits that get merged by > both > trees. If I understand correctly that otherwise the SHA of the commits would > be > different and that would provoke merge conflicts. > > We should not rely on one tree being merged before the other. AFAIK there is > no > hard merge order between trees. > I prepared a branch with the patches I think are relevant for you. Please confirm that this is correct, merge the tree in yours and I'll do the same for v5.5-next/soc The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a: Linux 5.5-rc1 (2019-12-08 14:57:55 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/ tags/v5.5-next-cmdq-stable for you to fetch changes up to d412f18c9bc791d8951e903de9a68817e3098a6a: soc: mediatek: cmdq: add cmdq_dev_get_client_reg function (2020-01-08 12:59:57 +0100) cmdq patches needed by drm driver to use cmdq interface Bibby Hsieh (4): soc: mediatek: cmdq: remove OR opertaion from err return soc: mediatek: cmdq: define the instruction struct soc: mediatek: cmdq: add polling function soc: mediatek: cmdq: add cmdq_dev_get_client_reg function drivers/soc/mediatek/mtk-cmdq-helper.c | 147 - include/linux/mailbox/mtk-cmdq-mailbox.h | 11 ++ include/linux/soc/mediatek/mtk-cmdq.h| 53 + 3 files changed, 185 insertions(+), 26 deletions(-) Regards, Matthias ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument
On Wed, Jan 8, 2020 at 10:15 AM Krzysztof Kozlowski wrote: > > The __force-cast that removes the __iomem here also means that > > the 'volatile' keyword could be dropped from the argument list, > > as it has no real effect any more, but then there are a few drivers > > that mark their iomem pointers as either 'volatile void __iomem*' or > > (worse) 'volatile void *', so we keep it in the argument list to not > > add warnings for those drivers. > > > > It may be time to change these drivers to not use volatile for __iomem > > pointers, but that seems out of scope for what Krzysztof is trying > > to do. Ideally we would be consistent here though, either using volatile > > all the time or never. > > Indeed. I guess there are no objections around const so let me send v2 > for const only. Ok, sounds good. Maybe mention in the changelog then that the 'volatile' in the interface is intentionally left out, and that only users of readl/writel still have it to deal with existing drivers. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 1963/2680] include/kcl/kcl_drm.h:206:10: error: too few arguments to function 'drm_crtc_init_with_planes'
Hi Slava,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f981f76437edab0861f3721c27f1c3cec5903dcc
commit: f2e0d469732d27bc612df52b42094309ba5877d9 [1963/2680] drm/amdkcl: Test
whether drm_crtc_init_with_planes() wants name
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout f2e0d469732d27bc612df52b42094309ba5877d9
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:98:1: error: conflicting types for
'drm_fb_helper_remove_conflicting_framebuffers'
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from include/kcl/kcl_drm.h:7:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_fb_helper.h:589:1: note: previous definition of
'drm_fb_helper_remove_conflicting_framebuffers' was here
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_encoder_init':
include/kcl/kcl_drm.h:191:9: error: too few arguments to function
'drm_encoder_init'
return drm_encoder_init(dev, encoder, funcs,
^~~~
In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_atomic_helper.h:32,
from include/kcl/kcl_drm.h:10,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_encoder.h:183:5: note: declared here
int drm_encoder_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_crtc_init_with_planes':
>> include/kcl/kcl_drm.h:206:10: error: too few arguments to function
>> 'drm_crtc_init_with_planes'
return drm_crtc_init_with_planes(dev, crtc, primary,
^
In file included from include/drm/drmP.h:68:0,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_crtc.h:1120:5: note: declared here
int drm_crtc_init_with_planes(struct drm_device *dev,
^
vim +/drm_crtc_init_with_planes +206 include/kcl/kcl_drm.h
950c9c93299ece Junwei Zhang 2016-12-23 195
950c9c93299ece Junwei Zhang 2016-12-23 196 static inline int
kcl_drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
950c9c93299ece Junwei Zhang 2016-12-23 197 struct
drm_plane *primary,
950c9c93299ece Junwei Zhang 2016-12-23 198 struct
drm_plane *cursor,
950c9c93299ece Junwei Zhang 2016-12-23 199 const
struct drm_crtc_funcs *funcs,
950c9c93299ece Junwei Zhang 2016-12-23 200 const
char *name, ...)
950c9c93299ece Junwei Zhang 2016-12-23 201 {
f2e0d469732d27 Slava Grigorev 2018-07-17 202 #if
defined(HAVE_DRM_CRTC_INIT_WITH_PLANES_VALID_WITH_NAME)
950c9c93299ece Junwei Zhang 2016-12-23 203 return
drm_crtc_init_with_planes(dev, crtc, primary,
950c9c93299ece Junwei Zhang 2016-12-23 204
cursor, funcs, name);
950c9c93299ece Junwei Zhang 2016-12-23 205 #else
950c9c93299ece Junwei Zhang 2016-12-23 @206 return
drm_crtc_init_with_planes(dev, crtc, primary,
950c9c93299ece Junwei Zhang 2016-12-23 207
cursor, funcs);
950c9c93299ece Junwei Zhang 2016-12-23 208 #endif
950c9c93299ece Junwei Zhang 2016-12-23 209 }
950c9c93299ece Junwei Zhang 2016-12-23 210
:: The code at line 206 was first introduced by commit
:: 950c9c93299eceb8cca4b12eb09a04a48d383ec6 drm/amdkcl: [4.5] fix drm
encoder and plane functions
:: TO: Junwei Zhang
:: CC: Chengming Gui
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFT v1 1/3] drm/panfrost: enable devfreq based the "operating-points-v2" property
On 07/01/2020 11:06 pm, Martin Blumenstingl wrote: Decouple the check to see whether we want to enable devfreq for the GPU from dev_pm_opp_set_regulators(). This is preparation work for adding back support for regulator control (which means we need to call dev_pm_opp_set_regulators() before dev_pm_opp_of_add_table(), which means having a check for "is devfreq enabled" that is not tied to dev_pm_opp_of_add_table() makes things easier). Hmm, what about cases like the SCMI DVFS protocol where the OPPs are dynamically discovered rather than statically defined in DT? Robin. Signed-off-by: Martin Blumenstingl --- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c b/drivers/gpu/drm/panfrost/panfrost_devfreq.c index 413987038fbf..1471588763ce 100644 --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c @@ -5,6 +5,7 @@ #include #include #include +#include #include #include "panfrost_device.h" @@ -79,10 +80,12 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev) struct devfreq *devfreq; struct thermal_cooling_device *cooling; - ret = dev_pm_opp_of_add_table(dev); - if (ret == -ENODEV) /* Optional, continue without devfreq */ + if (!device_property_present(dev, "operating-points-v2")) + /* Optional, continue without devfreq */ return 0; - else if (ret) + + ret = dev_pm_opp_of_add_table(dev); + if (ret) return ret; panfrost_devfreq_reset(pfdev); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
