Re: [PATCH 1/7] docs: fix broken doc references due to renames
On Fri, Jul 26, 2019 at 07:41:35AM -0600, Rob Herring wrote: > On Fri, Jul 26, 2019 at 5:47 AM Mauro Carvalho Chehab > wrote: > > > > Some files got renamed but probably due to some merge conflicts, > > a few references still point to the old locations. > > > > Signed-off-by: Mauro Carvalho Chehab > > Acked-by: Wolfram Sang # I2C part > > Reviewed-by: Jerry Hoemann # hpwdt.rst > > --- > > Documentation/RCU/rculist_nulls.txt | 2 +- > > Documentation/devicetree/bindings/arm/idle-states.txt | 2 +- > > Documentation/locking/spinlocks.rst | 4 ++-- > > Documentation/memory-barriers.txt | 2 +- > > Documentation/translations/ko_KR/memory-barriers.txt | 2 +- > > Documentation/watchdog/hpwdt.rst | 2 +- > > MAINTAINERS | 10 +- > > drivers/gpu/drm/drm_modes.c | 2 +- for the drm part: Acked-by: Daniel Vetter > > drivers/i2c/busses/i2c-nvidia-gpu.c | 2 +- > > drivers/scsi/hpsa.c | 4 ++-- > > 10 files changed, 16 insertions(+), 16 deletions(-) > > Acked-by: Rob Herring -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 0/4] video: of: display_timing: Adjust err printing of of_get_display_timing()
Hi,
On 7/23/19 10:38 AM, Sam Ravnborg wrote:
> Hi Dough.
>
> On Mon, Jul 22, 2019 at 11:24:35AM -0700, Douglas Anderson wrote:
>> As reported by Sam Ravnborg [1], after commit b8a2948fa2b3
>> ("drm/panel: simple: Add ability to override typical timing") we now
>> see a pointless error message printed on every boot for many systems.
>> Let's fix that by adjusting who is responsible for printing error
>> messages when of_get_display_timing() is used.
>>
>> Most certainly we can bikeshed the topic about whether this is the
>> right fix or we should instead add logic to panel_simple_probe() to
>> avoid calling of_get_display_timing() in the case where there is no
>> "panel-timing" sub-node. If there is consensus that I should move the
>> fix to panel_simple_probe() I'm happy to spin this series. In that
>> case we probably should _remove_ the extra prints that were already
>> present in the other two callers of of_get_display_timing().
>>
>> While at it, fix a missing of_node_put() found by code inspection.
>>
>> NOTE: amba-clcd and panel-lvds were only compile-tested.
>>
>> [1] https://lkml.kernel.org/r/20190721093815.ga4...@ravnborg.org
>>
>>
>> Douglas Anderson (4):
>> video: of: display_timing: Add of_node_put() in
>> of_get_display_timing()
>> video: of: display_timing: Don't yell if no timing node is present
>> drm: panel-lvds: Spout an error if of_get_display_timing() gives an
>> error
>> video: amba-clcd: Spout an error if of_get_display_timing() gives an
>> error
>
> Series looks good - thanks.
> Reviewed-by: Sam Ravnborg
>
> You could consider silencing display_timing as the last patch, but thats
> a very small detail.
>
> How do we apply these fixes - to drm-misc-next? Bartlomiej?
>
> No need to go in via drm-misc-fixes as the offending commit is only in
> drm-misc-next.
I've merged the whole series to drm-misc-next, thanks!
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
Re: [PATCH v3 6a/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding
Hi, On Thu, Jul 25, 2019 at 05:18:29PM +0200, Torsten Duwe wrote: > The anx6345 is an ultra-low power DisplayPort/eDP transmitter designed > for portable devices. > > Add a binding document for it. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Vasily Khoruzhick > Reviewed-by: Rob Herring > Signed-off-by: Torsten Duwe > Reviewed-by: Laurent Pinchart > --- > .../devicetree/bindings/display/bridge/anx6345.yaml | 90 ++ > 1 file changed, 90 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/anx6345.yaml > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.yaml > b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml > new file mode 100644 > index ..0af092d101c5 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.yaml > @@ -0,0 +1,90 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/anx6345.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Analogix ANX6345 eDP Transmitter Device Tree Bindings > + > +maintainers: > + - Torsten Duwe > + > +description: | > + The ANX6345 is an ultra-low power Full-HD eDP transmitter designed for > + portable devices. > + > +properties: > + compatible: > +const: analogix,anx6345 > + > + reg: > +maxItems: 1 > +description: I2C address of the device > + > + reset-gpios: > +maxItems: 1 > +description: active low GPIO to use for reset > + > + dvdd12-supply: > +maxItems: 1 > +description: Regulator for 1.2V digital core power. > +$ref: /schemas/types.yaml#/definitions/phandle > + > + dvdd25-supply: > +maxItems: 1 > +description: Regulator for 2.5V digital core power. > +$ref: /schemas/types.yaml#/definitions/phandle There's no need to specify the type here, all the properties ending in -supply are already checked for that type > + ports: > +type: object > +minItems: 1 > +maxItems: 2 > +description: | > + Video port 0 for LVTTL input, > + Video port 1 for eDP output (panel or connector) > + using the DT bindings defined in > + Documentation/devicetree/bindings/media/video-interfaces.txt You should probably describe the port@0 and port@1 nodes here as well. It would allow you to express that the port 0 is mandatory and the port 1 optional, which got dropped in the conversion. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[Bug 111211] Kernel 5.2.2 introduced tearing, corruption and freezes with Raven Ridge 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=111211 Michel Dänzer changed: What|Removed |Added Attachment #144872|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 12/24] drm/vc4: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index ee7d4e7b0ee3..eb57c907a256 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -267,7 +267,8 @@ static const struct drm_connector_helper_funcs
vc4_hdmi_connector_helper_funcs =
};
static struct drm_connector *vc4_hdmi_connector_init(struct drm_device *dev,
-struct drm_encoder
*encoder)
+struct drm_encoder
*encoder,
+struct i2c_adapter *ddc)
{
struct drm_connector *connector;
struct vc4_hdmi_connector *hdmi_connector;
@@ -281,8 +282,10 @@ static struct drm_connector
*vc4_hdmi_connector_init(struct drm_device *dev,
hdmi_connector->encoder = encoder;
- drm_connector_init(dev, connector, _hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+ drm_connector_init_with_ddc(dev, connector,
+ _hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ ddc);
drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
/* Create and attach TV margin props to this connector. */
@@ -1395,7 +1398,8 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
DRM_MODE_ENCODER_TMDS, NULL);
drm_encoder_helper_add(hdmi->encoder, _hdmi_encoder_helper_funcs);
- hdmi->connector = vc4_hdmi_connector_init(drm, hdmi->encoder);
+ hdmi->connector =
+ vc4_hdmi_connector_init(drm, hdmi->encoder, hdmi->ddc);
if (IS_ERR(hdmi->connector)) {
ret = PTR_ERR(hdmi->connector);
goto err_destroy_encoder;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 11/24] drm/imx: imx-tve: Provide ddc symlink in connector's sysfs
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/imx/imx-tve.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c index 649515868f86..5bbfaa2cd0f4 100644 --- a/drivers/gpu/drm/imx/imx-tve.c +++ b/drivers/gpu/drm/imx/imx-tve.c @@ -484,8 +484,10 @@ static int imx_tve_register(struct drm_device *drm, struct imx_tve *tve) drm_connector_helper_add(>connector, _tve_connector_helper_funcs); - drm_connector_init(drm, >connector, _tve_connector_funcs, - DRM_MODE_CONNECTOR_VGA); + drm_connector_init_with_ddc(drm, >connector, + _tve_connector_funcs, + DRM_MODE_CONNECTOR_VGA, + tve->ddc); drm_connector_attach_encoder(>connector, >encoder); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 09/24] drm/tegra: Provide ddc symlink in output connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/tegra/hdmi.c | 7 --- drivers/gpu/drm/tegra/sor.c | 7 --- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c index 334c4d7d238b..416a2862a84b 100644 --- a/drivers/gpu/drm/tegra/hdmi.c +++ b/drivers/gpu/drm/tegra/hdmi.c @@ -1425,9 +1425,10 @@ static int tegra_hdmi_init(struct host1x_client *client) hdmi->output.dev = client->dev; - drm_connector_init(drm, >output.connector, - _hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm, >output.connector, + _hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->output.ddc); drm_connector_helper_add(>output.connector, _hdmi_connector_helper_funcs); hdmi->output.connector.dpms = DRM_MODE_DPMS_OFF; diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c index 4ffe3794e6d3..3a69e387c62d 100644 --- a/drivers/gpu/drm/tegra/sor.c +++ b/drivers/gpu/drm/tegra/sor.c @@ -2832,9 +2832,10 @@ static int tegra_sor_init(struct host1x_client *client) sor->output.dev = sor->dev; - drm_connector_init(drm, >output.connector, - _sor_connector_funcs, - connector); + drm_connector_init_with_ddc(drm, >output.connector, + _sor_connector_funcs, + connector, + sor->output.ddc); drm_connector_helper_add(>output.connector, _sor_connector_helper_funcs); sor->output.connector.dpms = DRM_MODE_DPMS_OFF; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 10/24] drm/imx: imx-ldb: Provide ddc symlink in connector's sysfs
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/imx/imx-ldb.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c index de62a4cd4827..db461b6a257f 100644 --- a/drivers/gpu/drm/imx/imx-ldb.c +++ b/drivers/gpu/drm/imx/imx-ldb.c @@ -462,9 +462,10 @@ static int imx_ldb_register(struct drm_device *drm, */ drm_connector_helper_add(_ldb_ch->connector, _ldb_connector_helper_funcs); - drm_connector_init(drm, _ldb_ch->connector, - _ldb_connector_funcs, - DRM_MODE_CONNECTOR_LVDS); + drm_connector_init_with_ddc(drm, _ldb_ch->connector, + _ldb_connector_funcs, + DRM_MODE_CONNECTOR_LVDS, + imx_ldb_ch->ddc); drm_connector_attach_encoder(_ldb_ch->connector, encoder); } -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 13/24] drm: zte: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/zte/zx_hdmi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c index a50f5a1f09b8..b98a1420dcd3 100644 --- a/drivers/gpu/drm/zte/zx_hdmi.c +++ b/drivers/gpu/drm/zte/zx_hdmi.c @@ -319,8 +319,10 @@ static int zx_hdmi_register(struct drm_device *drm, struct zx_hdmi *hdmi) hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD; - drm_connector_init(drm, >connector, _hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm, >connector, + _hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + >ddc->adap); drm_connector_helper_add(>connector, _hdmi_connector_helper_funcs); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 14/24] drm: zte: Provide ddc symlink in vga connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/zte/zx_vga.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_vga.c b/drivers/gpu/drm/zte/zx_vga.c
index 9b67e419280c..c4fa3bbaba78 100644
--- a/drivers/gpu/drm/zte/zx_vga.c
+++ b/drivers/gpu/drm/zte/zx_vga.c
@@ -165,8 +165,10 @@ static int zx_vga_register(struct drm_device *drm, struct
zx_vga *vga)
vga->connector.polled = DRM_CONNECTOR_POLL_HPD;
- ret = drm_connector_init(drm, connector, _vga_connector_funcs,
-DRM_MODE_CONNECTOR_VGA);
+ ret = drm_connector_init_with_ddc(drm, connector,
+ _vga_connector_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ >ddc->adap);
if (ret) {
DRM_DEV_ERROR(dev, "failed to init connector: %d\n", ret);
goto clean_encoder;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 15/24] drm/tilcdc: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c index c6e4e52f32bc..d51776dd7a03 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c @@ -222,8 +222,10 @@ static struct drm_connector *tfp410_connector_create(struct drm_device *dev, connector = _connector->base; - drm_connector_init(dev, connector, _connector_funcs, - DRM_MODE_CONNECTOR_DVID); + drm_connector_init_with_ddc(dev, connector, + _connector_funcs, + DRM_MODE_CONNECTOR_DVID, + mod->i2c); drm_connector_helper_add(connector, _connector_helper_funcs); connector->polled = DRM_CONNECTOR_POLL_CONNECT | -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm: Set crc->opened to false before setting crc source to NULL.
From: Dingchen Zhang to terminate the while-loop in drm_dp_aux_crc_work when drm_dp_start/stop_crc are called in the hook to set crc source. v3: set crc->opened to false without checking (Nick) v2: Move spin_lock around entire crc->opened use (Daniel) Cc: Daniel Vetter Cc: Harry Wentland Cc: Nick Kazlauskas Signed-off-by: Dingchen Zhang --- drivers/gpu/drm/drm_debugfs_crc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c index dac267e840af..d2d2389d8892 100644 --- a/drivers/gpu/drm/drm_debugfs_crc.c +++ b/drivers/gpu/drm/drm_debugfs_crc.c @@ -249,6 +249,11 @@ static int crtc_crc_release(struct inode *inode, struct file *filep) struct drm_crtc *crtc = filep->f_inode->i_private; struct drm_crtc_crc *crc = >crc; + /* terminate the infinite while loop if 'drm_dp_aux_crc_work' running */ + spin_lock_irq(>lock); + crc->opened = false; + spin_unlock_irq(>lock); + crtc->funcs->set_crc_source(crtc, NULL); spin_lock_irq(>lock); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111229] Unable to unbind GPU from amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=111229
--- Comment #4 from weden...@yandex.ru ---
My first guess is that unbinding causes GPU reset which is known to leave GPU
in a messy state ("the reset bug").
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290]
https://bugs.freedesktop.org/show_bug.cgi?id=101946 weden...@yandex.ru changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=111229 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106993] general protection fault in mutex_lock / drm_mode_object_unregister when unloading amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=106993 weden...@yandex.ru changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=111229 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111229] Unable to unbind GPU from amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=111229 weden...@yandex.ru changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=101946 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111229] Unable to unbind GPU from amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=111229 weden...@yandex.ru changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=106993 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: My penguin has blue feets (aka: RGB versus BGR troubles)
On Fri, Jul 26, 2019 at 11:35 PM Ilia Mirkin wrote: > On Fri, Jul 26, 2019 at 4:36 PM Sam Ravnborg wrote: > > > > Hi all. > > > > The Atmel at91sam9263 has a nice LCDC IP core that supports several > > formats: > > DRM_FORMAT_XBGR, DRM_FORMAT_BGR888, DRM_FORMAT_BGR565 > > > > (It also supports a palletized C8 format, but thats for later). > > > > The formats are all BGR formats - and some boards actually reverse Blue > > and Red when wiring up the display. I have added a DT property to > > identify boards with this difference. > > > > The penguin shown during boot of the kernel had blue feet which is a > > clear sign that RED and GREEN was reversed. > > > > So to fix this I (got help from imirkin on irc) I implmented a quirk. > > See patch below. > > > > With the quirk enabled I see: > > - penguin shown during kernel boot has yellow feets (OK) > > - modetest tell the driver reports: XB24 BG24 BG16 (as expected) > > - modetest -s fails with: > > # modetest -M atmel-lcdc -s 34:800x480-60Hz > > setting mode 800x480-60Hz@XR24 on connectors 34, crtc 32 > > failed to set mode: Function not implemented > > > > Snip from dmesg: > > > > drm:drm_ioctl] pid=208, dev=0xe201, auth=1, DRM_IOCTL_MODE_ADDFB2 > > [drm:drm_mode_addfb2] [FB:37] > > [drm:drm_ioctl] pid=208, dev=0xe201, auth=1, DRM_IOCTL_MODE_SETCRTC > > [drm:drm_mode_setcrtc] [CRTC:32:crtc-0] > > [drm:drm_mode_setcrtc] Invalid pixel format XR24 little-endian > > (0x34325258), modifier 0x0 > > > > [drm:drm_mode_object_put] OBJ ID: 37 (2) > > [drm:drm_ioctl] pid=208, ret = -22 > > [drm:drm_ioctl] pid=208, dev=0xe201, auth=1, DRM_IOCTL_MODE_DIRTYFB > > [drm:drm_mode_object_put] OBJ ID: 37 (2) > > [drm:drm_ioctl] pid=208, ret = -38 > > [drm:drm_ioctl] pid=208, dev=0xe201, auth=1, DRM_IOCTL_MODE_RMFB > > [drm:drm_mode_object_put] OBJ ID: 37 (2) > > [drm:drm_mode_object_put] OBJ ID: 37 (1) > > [drm:drm_ioctl] pid=208, dev=0xe201, auth=1, DRM_IOCTL_MODE_DESTROY_DUMB > > [drm:drm_release] open_count = 1 > > [drm:drm_file_free] pid = 208, device = 0xe201, open_count = 1 > > [drm:drm_lastclose] > > [drm:drm_lastclose] driver lastclose completed > > > > Notice that somehow we have a framebuffer in XR24 format, which is not > > supported by the driver. > > > > > > I have tried to tell that my driver supports DRM_FORMAT_XRGB, > > DRM_FORMAT_RGB888, DRM_FORMAT_RGB565 and then modetest works. > > But in the output of modetest -s the blue and red colors are reversed. > > > > *Any* hints why modetest fails when my driver reports the correct formats? > > Every driver to date supports XR24. So modetest uses that by default. > But this fails with your driver since it's an unsupported format. > Something like: > > modetest -M atmel-lcdc -s 34:800x480-60Hz@XB24 > > should do the trick. The quirk covers drivers that use AddFB(). > However modetest is fancy and uses AddFB2, which takes an explicit > format. Yeah I thinki for fbdev the correct fix is to look whether the driver enabled atomic and if so, consult the fourcc format list of the primary plane of the first crtc to figure out what you might actually have set. Without atomic you can't realy on the format list being correct since for drivers who get the default primary plane that drm_crtc_init sets up the format list is garbage. Reworking the entire fbdev emulation to use fourcc codes would be even more awesome I guess. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111228] PRIME output screen satys black on 1002:15d8 with 128MB VRAM
https://bugs.freedesktop.org/show_bug.cgi?id=111228 --- Comment #1 from djczaps --- Created attachment 144876 --> https://bugs.freedesktop.org/attachment.cgi?id=144876=edit nvidia bug report I'm consistentky trying to run my Nvidia gtx 1660 Ti on laptop with Ryzen 7 processor. So far unsucessfull trying to get into GUI. It might be something related to iommu and power management when trying to open and close the laptop lid. Laptop model Ausus TUF 505 DU. Any help will be appreciated. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111228] PRIME output screen satys black on 1002:15d8 with 128MB VRAM
https://bugs.freedesktop.org/show_bug.cgi?id=111228 --- Comment #2 from djczaps --- https://devtalk.nvidia.com/default/topic/1056652/linux/amd-ryzen-7-geforce-gtx-1660-ti-laptop-gt-cannot-get-nvidia-to-be-used-as-primary-graphics/post/5365696/#5365696 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/bridge: Add NWL MIPI DSI host controller support
Hello, On Fri, Jul 26, 2019 at 05:01:52PM -0300, Fabio Estevam wrote: > Hi Guido, > > Thanks for your work on this driver! > > On Wed, Jul 24, 2019 at 12:52 PM Guido Günther wrote: > > > --- /dev/null > > +++ b/drivers/gpu/drm/bridge/imx-nwl/Kconfig > > @@ -0,0 +1,15 @@ > > +config DRM_IMX_NWL_DSI > > + tristate "Support for Northwest Logic MIPI DSI Host controller" > > + depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM || COMPILE_TEST) > > This IP could potentially be found on other SoCs, so no need to make > it depend on ARCH_MXC. I'd go even further and not use the prefix imx in the driver name or anywhere in the code. [snip] -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] video: of: display_timing: Add of_node_put() in of_get_display_timing()
Hi Douglas,
Thank you for the patch.
On Mon, Jul 22, 2019 at 11:24:36AM -0700, Douglas Anderson wrote:
> From code inspection it can be seen that of_get_display_timing() is
> lacking an of_node_put(). Add it.
>
> Fixes: ffa3fd21de8a ("videomode: implement public of_get_display_timing()")
> Signed-off-by: Douglas Anderson
Reviewed-by: Laurent Pinchart
> ---
>
> drivers/video/of_display_timing.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/of_display_timing.c
> b/drivers/video/of_display_timing.c
> index f5c1c469c0af..5eedae0799f0 100644
> --- a/drivers/video/of_display_timing.c
> +++ b/drivers/video/of_display_timing.c
> @@ -119,6 +119,7 @@ int of_get_display_timing(const struct device_node *np,
> const char *name,
> struct display_timing *dt)
> {
> struct device_node *timing_np;
> + int ret;
>
> if (!np)
> return -EINVAL;
> @@ -129,7 +130,11 @@ int of_get_display_timing(const struct device_node *np,
> const char *name,
> return -ENOENT;
> }
>
> - return of_parse_display_timing(timing_np, dt);
> + ret = of_parse_display_timing(timing_np, dt);
> +
> + of_node_put(timing_np);
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(of_get_display_timing);
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111228] PRIME output screen satys black on 1002:15d8 with 128MB VRAM
https://bugs.freedesktop.org/show_bug.cgi?id=111228 Bug ID: 111228 Summary: PRIME output screen satys black on 1002:15d8 with 128MB VRAM Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: hhfe...@gmx.de So far I met the same PCI ID 1002:15d8 with 2GB VRAM which was working fine in prime output mode with any nvidia gpu as provider. The mentioned version with 128MB VRAM doesn't work. No error messages regarding prime, just the screen staying black. https://devtalk.nvidia.com/default/topic/1056652/linux/amd-ryzen-7-geforce-gtx-1660-ti-laptop-gt-cannot-get-nvidia-to-be-used-as-primary-graphics/1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] dt-bindings: display/bridge: Add binding for IMX NWL mipi dsi host controller
Hi Guido,
Thank you for the patch.
On Wed, Jul 24, 2019 at 05:52:25PM +0200, Guido Günther wrote:
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther
> ---
> .../bindings/display/bridge/imx-nwl-dsi.txt | 89 +++
> 1 file changed, 89 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> new file mode 100644
> index ..288fdb726d5a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> @@ -0,0 +1,89 @@
> +Northwest Logic MIPI-DSI on imx SoCs
> +=
There's one too many =.
> +
> +NWL MIPI-DSI host controller found on i.MX8 platforms. This is a
> +dsi bridge for the for the NWL MIPI-DSI host.
s/dsi/DSI/
s/for the for the /for the /
> +
> +Required properties:
> +- compatible:"fsl,-nwl-dsi"
> + The following strings are expected:
> + "fsl,imx8mq-nwl-dsi"
> +- reg: the register range of the MIPI-DSI controller
> +- interrupts:the interrupt number for this module
It's not just a number but a specifier (with flags).
> +- clock, clock-names:phandles to the MIPI-DSI clocks
That should be phandles and names.
> + The following clocks are expected on all platforms:
Expected or required ?
s/ on all platforms// as you only support a single platform.
> + "core"- DSI core clock
> + "tx_esc" - TX_ESC clock (used in escape mode)
> + "rx_esc" - RX_ESC clock (used in escape mode)
> + "phy_ref" - PHY_REF clock. Clock is managed by the phy. Only
> +used to read the clock rate.
> +- assigned-clocks: phandles to clocks that require initial configuration
> +- assigned-clock-rates: rates of the clocks that require initial
> configuration
> + The following clocks need to have an initial configuration:
> + "tx_esc" (20 MHz) and "rx_esc" (80 Mhz).
I think those two properties are out of scope for these bindings.
> +- phys: phandle to the phy module representing the DPHY
> + inside the MIPI-DSI IP block
> +- phy-names: should be "dphy"
> +
> +Optional properties:
> +- power-domains phandle to the power domain
> +- srcphandle to the system reset controller
> (required on
> + i.MX8MQ)
Should this use the standard resets property ?
> +- mux-selphandle to the MUX register set (required on i.MX8MQ)
> +- assigned-clock-parents phandles to parent clocks that needs to be assigned
> as
> + parents to clocks defined in assigned-clocks
This property is also out of scope.
> +
> +Example:
> + mipi_dsi: mipi_dsi@30a0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,imx8mq-nwl-dsi";
> + reg = <0x30A0 0x300>;
> + clocks = < IMX8MQ_CLK_DSI_CORE>,
> + < IMX8MQ_CLK_DSI_AHB>,
> + < IMX8MQ_CLK_DSI_IPG_DIV>,
> + < IMX8MQ_CLK_DSI_PHY_REF>;
> + clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
> + assigned-clocks = < IMX8MQ_CLK_DSI_AHB>,
> + < IMX8MQ_CLK_DSI_CORE>,
> + < IMX8MQ_CLK_DSI_IPG_DIV>;
> + assigned-clock-parents = < IMX8MQ_SYS1_PLL_80M>,
> + < IMX8MQ_SYS1_PLL_266M>;
> + assigned-clock-rates = <8000>,
> +<26600>,
> +<2000>;
> + interrupts = ;
> + power-domains = <_mipi>;
> + src = <>;
> + mux-sel = <_gpr>;
> + phys = <>;
> + phy-names = "dphy";
> + status = "okay";
> +
> + panel@0 {
> + compatible = "...";
> + port {
> + panel_in: endpoint {
> +remote-endpoint = <_dsi_out>;
> + };
> + };
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + mipi_dsi_in: endpoint {
> + remote-endpoint =
> <_disp0_mipi_dsi>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + mipi_dsi_out: endpoint {
> +
[Bug 111229] Unable to unbind GPU from amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=111229 --- Comment #2 from weden...@yandex.ru --- Created attachment 144879 --> https://bugs.freedesktop.org/attachment.cgi?id=144879=edit lspci -vvv before unbind -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111229] Unable to unbind GPU from amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=111229 Bug ID: 111229 Summary: Unable to unbind GPU from amdgpu Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: weden...@yandex.ru Created attachment 144877 --> https://bugs.freedesktop.org/attachment.cgi?id=144877=edit dmesg kernel 5.2.1 Arch linux Kernel version: 5.2.1 I have two GPUs in my system: integrated Intel and Sapphire Pulse Vega 56. I boot with Intel as my primary gpu and I use Vega for VFIO (gpu passthrough) and gpu offloading. What I'm trying to do is to boot with amdgpu driver for Vega and bind it to vfio-pci when I start VM (qemu). The problem occurs when I try to unbind Vega from amdgpu driver using this command: echo -n ":03:00.0" > /sys/bus/pci/drivers/amdgpu/unbind It results in segfault with following error in dmesg (full dmesg from boot to shutdown is attached): [drm:amdgpu_pci_remove [amdgpu]] *ERROR* Device removal is currently not supported outside of fbcon After that I'm unable to rebind device back to amdgpu or any other driver: echo ":03:00.0" > /sys/bus/pci/drivers/amdgpu/bind bash: echo: write error: No such device Also I'm unable to shutdown properly. Shutdown process becomes stuck at some point and only holding the button helps. I've attached relevant lspci -vvv output before and after attempt to unbind, in case it's useful. Another thing I've tried is to unbind using kernel 4.19.60 and it just hangs after executing the command. I've attached the log of this attempt (error is different from 5.2.1). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111229] Unable to unbind GPU from amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=111229 --- Comment #1 from weden...@yandex.ru --- Created attachment 144878 --> https://bugs.freedesktop.org/attachment.cgi?id=144878=edit dmesg kernel 4.19.60 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111229] Unable to unbind GPU from amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=111229 --- Comment #3 from weden...@yandex.ru --- Created attachment 144880 --> https://bugs.freedesktop.org/attachment.cgi?id=144880=edit lspci -vvv after unbind -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] dt-bindings: display/bridge: Add binding for IMX NWL mipi dsi host controller
Hello,
On Fri, Jul 26, 2019 at 11:23:15AM +0200, Sam Ravnborg wrote:
> On Wed, Jul 24, 2019 at 05:52:25PM +0200, Guido Günther wrote:
> > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
> >
> > Signed-off-by: Guido Günther
> > ---
> > .../bindings/display/bridge/imx-nwl-dsi.txt | 89 +++
>
> New binding. Any chance we can get this in yaml format?
> This is the way forward and we have to convert the file anyway.
>
> None of the other bridges use yaml format, but someone has to be the
> first.
>
> > 1 file changed, 89 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> > b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> > new file mode 100644
> > index ..288fdb726d5a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> > @@ -0,0 +1,89 @@
> > +Northwest Logic MIPI-DSI on imx SoCs
> > +=
> > +
> > +NWL MIPI-DSI host controller found on i.MX8 platforms. This is a
> > +dsi bridge for the for the NWL MIPI-DSI host.
>
> To my best understanding a bridge is something that converts from one
> format to another format.
> Something that in the drm world are connected to an encoder.
>
> I do not know the HW here - but from this very brif description this
> sounds more like a display controller and not a bridge?
I would call it an encoder, that's the term usually employed for such
devices (similar to HDMI encoder).
> > +
> > +Required properties:
> > +- compatible: "fsl,-nwl-dsi"
> > + The following strings are expected:
> > + "fsl,imx8mq-nwl-dsi"
> > +- reg: the register range of the MIPI-DSI controller
> > +- interrupts: the interrupt number for this module
> > +- clock, clock-names: phandles to the MIPI-DSI clocks
> > + The following clocks are expected on all platforms:
> > + "core"- DSI core clock
> > + "tx_esc" - TX_ESC clock (used in escape mode)
> > + "rx_esc" - RX_ESC clock (used in escape mode)
> > + "phy_ref" - PHY_REF clock. Clock is managed by the phy. Only
> > +used to read the clock rate.
> > +- assigned-clocks: phandles to clocks that require initial configuration
> > +- assigned-clock-rates:rates of the clocks that require initial
> > configuration
> > + The following clocks need to have an initial configuration:
> > + "tx_esc" (20 MHz) and "rx_esc" (80 Mhz).
> > +- phys:phandle to the phy module representing the DPHY
> > + inside the MIPI-DSI IP block
> > +- phy-names: should be "dphy"
> > +
> > +Optional properties:
> > +- power-domainsphandle to the power domain
> > +- src phandle to the system reset controller
> > (required on
> > + i.MX8MQ)
> Name is not very descriptive.
> Other bindings seems to use "resets" here?
>
> > +- mux-sel phandle to the MUX register set (required on i.MX8MQ)
> > +- assigned-clock-parents phandles to parent clocks that needs to be
> > assigned as
> > + parents to clocks defined in assigned-clocks
> > +
> > +Example:
> > + mipi_dsi: mipi_dsi@30a0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fsl,imx8mq-nwl-dsi";
> > + reg = <0x30A0 0x300>;
> > + clocks = < IMX8MQ_CLK_DSI_CORE>,
> > +< IMX8MQ_CLK_DSI_AHB>,
> > +< IMX8MQ_CLK_DSI_IPG_DIV>,
> > +< IMX8MQ_CLK_DSI_PHY_REF>;
> > + clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
> > + assigned-clocks = < IMX8MQ_CLK_DSI_AHB>,
> > + < IMX8MQ_CLK_DSI_CORE>,
> > + < IMX8MQ_CLK_DSI_IPG_DIV>;
> > + assigned-clock-parents = < IMX8MQ_SYS1_PLL_80M>,
> > +< IMX8MQ_SYS1_PLL_266M>;
> > + assigned-clock-rates = <8000>,
> > + <26600>,
> > + <2000>;
> > + interrupts = ;
> > + power-domains = <_mipi>;
> > + src = <>;
> > + mux-sel = <_gpr>;
> > + phys = <>;
> > + phy-names = "dphy";
> > + status = "okay";
> I recall status should not be included in examples.
>
> > +
> > + panel@0 {
> > + compatible = "...";
> > + port {
> > +panel_in: endpoint {
> > + remote-endpoint = <_dsi_out>;
> > +};
> > + };
> > + };
> > +
> > + ports {
> > + #address-cells = <1>;
> > +
Re: [PATCH 3/3] drm/bridge: Add NWL MIPI DSI host controller support
Hello Guido,
Thank you for the patch.
On Wed, Jul 24, 2019 at 05:52:26PM +0200, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found on
> i.MX8 SoCs.
>
> It adds support for the i.MX8MQ but the same IP can be found on
> e.g. the i.MX8QXP.
>
> It has been tested on the Librem 5 devkit using mxsfb.
>
> Signed-off-by: Guido Günther
> Co-developed-by: Robert Chiras
> ---
> drivers/gpu/drm/bridge/Kconfig | 2 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/imx-nwl/Kconfig | 15 +
> drivers/gpu/drm/bridge/imx-nwl/Makefile | 2 +
> drivers/gpu/drm/bridge/imx-nwl/nwl-drv.c | 529
> drivers/gpu/drm/bridge/imx-nwl/nwl-drv.h | 72 +++
> drivers/gpu/drm/bridge/imx-nwl/nwl-dsi.c | 745 +++
> drivers/gpu/drm/bridge/imx-nwl/nwl-dsi.h | 111
> 8 files changed, 1477 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx-nwl/Kconfig
> create mode 100644 drivers/gpu/drm/bridge/imx-nwl/Makefile
> create mode 100644 drivers/gpu/drm/bridge/imx-nwl/nwl-drv.c
> create mode 100644 drivers/gpu/drm/bridge/imx-nwl/nwl-drv.h
> create mode 100644 drivers/gpu/drm/bridge/imx-nwl/nwl-dsi.c
> create mode 100644 drivers/gpu/drm/bridge/imx-nwl/nwl-dsi.h
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index a6eec908c43e..38c3145a7e57 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -152,6 +152,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
>
> source "drivers/gpu/drm/bridge/adv7511/Kconfig"
>
> +source "drivers/gpu/drm/bridge/imx-nwl/Kconfig"
> +
As this doesn't seem to be an i.MX-specific IP, I wouldn't use the name
imx in file names or in the code, at least in the parts that are not
NXP-specific.
> source "drivers/gpu/drm/bridge/synopsys/Kconfig"
>
> endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf5a6f8..904a9eb3a20a 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -16,4 +16,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-y += imx-nwl/
> obj-y += synopsys/
> diff --git a/drivers/gpu/drm/bridge/imx-nwl/Kconfig
> b/drivers/gpu/drm/bridge/imx-nwl/Kconfig
> new file mode 100644
> index ..822dba1b380a
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx-nwl/Kconfig
> @@ -0,0 +1,15 @@
> +config DRM_IMX_NWL_DSI
> + tristate "Support for Northwest Logic MIPI DSI Host controller"
> + depends on DRM && (ARCH_MXC || ARCH_MULTIPLATFORM || COMPILE_TEST)
> + depends on COMMON_CLK
> + depends on OF && HAS_IOMEM
> + select DRM_KMS_HELPER
> + select DRM_MIPI_DSI
> + select DRM_PANEL_BRIDGE
> + select GENERIC_PHY_MIPI_DPHY
> + select MFD_SYSCON
> + select REGMAP_MMIO
> + help
> + This enables the Northwest Logic MIPI DSI Host controller as
> + found on NXP's i.MX8 Processors.
> +
> diff --git a/drivers/gpu/drm/bridge/imx-nwl/Makefile
> b/drivers/gpu/drm/bridge/imx-nwl/Makefile
> new file mode 100644
> index ..9fa63483da5b
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx-nwl/Makefile
> @@ -0,0 +1,2 @@
> +imx-nwl-objs := nwl-drv.o nwl-dsi.o
> +obj-$(CONFIG_DRM_IMX_NWL_DSI) += imx-nwl.o
> diff --git a/drivers/gpu/drm/bridge/imx-nwl/nwl-drv.c
> b/drivers/gpu/drm/bridge/imx-nwl/nwl-drv.c
> new file mode 100644
> index ..451f8f067c6f
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx-nwl/nwl-drv.c
> @@ -0,0 +1,529 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * i.MX8 NWL MIPI DSI host driver
> + *
> + * Copyright (C) 2017 NXP
> + * Copyright (C) 2019 Purism SPC
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
This doesn't seem to be needed.
> +#include
> +#include
Same here.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "nwl-drv.h"
> +#include "nwl-dsi.h"
> +
> +#define DRV_NAME "imx-nwl-dsi"
> +
> +/* 8MQ SRC specific registers */
> +#define SRC_MIPIPHY_RCR 0x28
> +#define RESET_BYTE_N BIT(1)
> +#define RESET_N BIT(2)
> +#define DPI_RESET_N BIT(3)
> +#define ESC_RESET_N BIT(4)
> +#define PCLK_RESET_N BIT(5)
> +
> +/* Possible clocks */
> +#define CLK_PIXEL"pixel"
> +#define CLK_CORE "core"
> +#define CLK_BYPASS "bypass"
> +
> +enum imx_ext_regs {
> + IMX_REG_CSR = BIT(1),
> + IMX_REG_SRC = BIT(2),
> + IMX_REG_GPR = BIT(3),
> +};
> +
> +static const struct regmap_config nwl_dsi_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = IRQ_MASK2,
> + .name = DRV_NAME,
> +};
> +
> +struct imx_nwl_platform_data {
> +
Re: [PATCH 00/11] JZ4740 SoC cleanup
Le ven. 26 juil. 2019 à 14:46, Sam Ravnborg a écrit : Hi Paul. On Thu, Jul 25, 2019 at 06:02:04PM -0400, Paul Cercueil wrote: Hi, This patchset converts the Qi LB60 MIPS board to devicetree and makes it use all the shiny new drivers that have been developed or updated recently. All the crappy old drivers and custom code can be dropped since they have been replaced by better alternatives. The overall diffstat is missing. Just for curiosity it would be nice to see what was dropped with this patch. Sam Diffstat: arch/mips/boot/dts/ingenic/jz4740.dtsi | 84 arch/mips/boot/dts/ingenic/qi_lb60.dts | 295 - arch/mips/configs/qi_lb60_defconfig| 44 +++--- arch/mips/include/asm/mach-jz4740/gpio.h | 15 --- arch/mips/include/asm/mach-jz4740/jz4740_fb.h | 58 arch/mips/include/asm/mach-jz4740/jz4740_mmc.h | 12 -- arch/mips/include/asm/mach-jz4740/platform.h | 26 arch/mips/jz4740/Makefile | 7 +- arch/mips/jz4740/board-qi_lb60.c | 491 --- arch/mips/jz4740/platform.c| 250 --- arch/mips/jz4740/prom.c| 5 - arch/mips/jz4740/setup.c | 3 +- drivers/dma/Kconfig| 6 - drivers/dma/Makefile | 1 - drivers/dma/dma-jz4740.c | 623 - drivers/hwmon/Kconfig | 10 -- drivers/hwmon/Makefile | 1 - drivers/hwmon/jz4740-hwmon.c | 135 --- drivers/mfd/Kconfig| 9 -- drivers/mfd/Makefile | 1 - drivers/mfd/jz4740-adc.c | 324 - drivers/mtd/nand/raw/ingenic/Kconfig | 7 - drivers/mtd/nand/raw/ingenic/Makefile | 1 - drivers/mtd/nand/raw/ingenic/jz4740_nand.c | 536 -- drivers/power/supply/Kconfig | 11 -- drivers/power/supply/Makefile | 1 - drivers/power/supply/jz4740-battery.c | 421 -- drivers/video/fbdev/Kconfig| 9 -- drivers/video/fbdev/Makefile | 1 - drivers/video/fbdev/jz4740_fb.c| 690 --- sound/soc/jz4740/Kconfig | 25 +--- sound/soc/jz4740/Makefile | 5 - sound/soc/jz4740/qi_lb60.c | 106 --- 33 files changed, 404 insertions(+), 3809 deletions(-)
Re: [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
Hi Artur, On 7/23/19 15:20, Artur Świgoń wrote: > This patch adds interconnect functionality to the exynos-bus devfreq > driver. > > The SoC topology is a graph (or, more specifically, a tree) and most of its > edges are taken from the devfreq parent-child hierarchy (cf. > Documentation/devicetree/bindings/devfreq/exynos-bus.txt). The previous > patch adds missing edges to the DT (under the name 'parent'). Due to > unspecified relative probing order, -EPROBE_DEFER may be propagated to > guarantee that a child is probed before its parent. > > Each bus is now an interconnect provider and an interconnect node as well > (cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers > itself as a node. Node IDs are not hardcoded but rather assigned at > runtime, in probing order (subject to the above-mentioned exception > regarding relative order). This approach allows for using this driver with > various Exynos SoCs. I am not familiar with the Exynos bus topology, but it seems to me that it's not represented correctly. An interconnect provider with just a single node (port) is odd. I would expect that each provider consists of multiple master and slave nodes. This data would be used by a framework to understand what are the links and how the traffic flows between the IP blocks and through which buses. > The devfreq target() callback provided by exynos-bus now selects either the > frequency calculated by the devfreq governor or the frequency requested via > the interconnect API for the given node, whichever is higher. This completely makes sense. We just need to be sure that the interconnect framework is used correctly. Thanks, Georgi
[PATCH] drm/komeda: Adds more check in mode_valid
This patch adds the checks for vrefresh, crtc_hdisplay and crtc_vdisplay.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 2fed1f6..017f6b6 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -403,11 +403,37 @@ unsigned long komeda_crtc_get_aclk(struct
komeda_crtc_state *kcrtc_st)
struct komeda_dev *mdev = crtc->dev->dev_private;
struct komeda_crtc *kcrtc = to_kcrtc(crtc);
struct komeda_pipeline *master = kcrtc->master;
- unsigned long min_pxlclk, min_aclk;
+ struct komeda_compiz *compiz = master->compiz;
+ unsigned long min_pxlclk, min_aclk, delta, full_frame;
+ int hdisplay = m->hdisplay;
if (m->flags & DRM_MODE_FLAG_INTERLACE)
return MODE_NO_INTERLACE;
+ full_frame = m->htotal * m->vtotal;
+ delta = abs(m->clock * 1000 - m->vrefresh * full_frame);
+ if (m->vrefresh && (delta > full_frame)) {
+ DRM_DEBUG_ATOMIC("mode clock check error!\n");
+ return MODE_CLOCK_RANGE;
+ }
+
+ if (kcrtc->side_by_side)
+ hdisplay /= 2;
+
+ if (!in_range(>hsize, hdisplay)) {
+ DRM_DEBUG_ATOMIC("hdisplay[%u] is out of range[%u, %u]!\n",
+hdisplay, compiz->hsize.start,
+compiz->hsize.end);
+ return MODE_BAD_HVALUE;
+ }
+
+ if (!in_range(>vsize, m->vdisplay)) {
+ DRM_DEBUG_ATOMIC("vdisplay[%u] is out of range[%u, %u]!\n",
+m->vdisplay, compiz->vsize.start,
+compiz->vsize.end);
+ return MODE_BAD_VVALUE;
+ }
+
min_pxlclk = m->clock * 1000;
if (master->dual_link)
min_pxlclk /= 2;
--
1.9.1
Re: [PATCH v5 01/24] drm: Include ddc adapter pointer in struct drm_connector
Hi Andrzej.
After reading through the series a few more comments.
1) The subject of this patch could be improved.
Consider something like:
drm: add ddc link in sysfs created by drm_connector
This spells out much better what the patch achieve.
2) The purpsoe of drm_connector.ddc is to provide drm_connector with
info to create the symlink.
Yet in many follow-up patches the drivers are changed so
drm_connector.ddc is their only reference to struct i2c_adapter.
But the ownership is not clear here.
Who owns the reference to i2c_adapter - and who has the
responsibility to call put() on the adapter.
Looking at the conversions done then some drivers are converted
so they only use drm_connector.ddc, and other drivers have their own
reference to i2c_adapter.
The latter looks like the correct solution as the ownership of the
reference belongs to the driver and not drm_connector.
In other words - a conversion where the drivers only assigned
drm_connector.ddc (using drm_connector_init_with_ddc()),
seems like a more clean design that does not mix up ownership.
This is at least how I see it.
I did not take this type of look at the patches before. Sorry
for providing feedback this late.
Sam
On Fri, Jul 26, 2019 at 08:37:59AM +0200, Sam Ravnborg wrote:
> Hi Andrzej.
>
> Patch looks good, but one kernel-doc detail.
>
> On Wed, Jul 24, 2019 at 03:59:23PM +0200, Andrzej Pietrasiewicz wrote:
> > Add generic code which creates symbolic links in sysfs, pointing to ddc
> > interface used by a particular video output. For example:
> >
> > ls -l /sys/class/drm/card0-HDMI-A-1/ddc
> > lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
> > -> ../../../../soc/1388.i2c/i2c-2
> >
> > This makes it easy for user to associate a display with its ddc adapter
> > and use e.g. ddcutil to control the chosen monitor.
> >
> > This patch adds an i2c_adapter pointer to struct drm_connector. Particular
> > drivers can then use it instead of using their own private instance. If a
> > connector contains a ddc, then create a symbolic link in sysfs.
> >
> > Signed-off-by: Andrzej Pietrasiewicz
> > Acked-by: Daniel Vetter
> > Reviewed-by: Andrzej Hajda
> > ---
> > drivers/gpu/drm/drm_sysfs.c | 8
> > include/drm/drm_connector.h | 11 +++
> > 2 files changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > index ad10810bc972..e962a9d45f7e 100644
> > --- a/drivers/gpu/drm/drm_sysfs.c
> > +++ b/drivers/gpu/drm/drm_sysfs.c
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -294,6 +295,9 @@ int drm_sysfs_connector_add(struct drm_connector
> > *connector)
> > /* Let userspace know we have a new connector */
> > drm_sysfs_hotplug_event(dev);
> >
> > + if (connector->ddc)
> > + return sysfs_create_link(>kdev->kobj,
> > +>ddc->dev.kobj, "ddc");
> > return 0;
> > }
> >
> > @@ -301,6 +305,10 @@ void drm_sysfs_connector_remove(struct drm_connector
> > *connector)
> > {
> > if (!connector->kdev)
> > return;
> > +
> > + if (connector->ddc)
> > + sysfs_remove_link(>kdev->kobj, "ddc");
> > +
> > DRM_DEBUG("removing \"%s\" from sysfs\n",
> > connector->name);
> >
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 4c30d751487a..33a6fff85fdb 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -41,6 +41,7 @@ struct drm_property;
> > struct drm_property_blob;
> > struct drm_printer;
> > struct edid;
> > +struct i2c_adapter;
> >
> > enum drm_connector_force {
> > DRM_FORCE_UNSPECIFIED,
> > @@ -1311,6 +1312,16 @@ struct drm_connector {
> > * [0]: progressive, [1]: interlaced
> > */
> > int audio_latency[2];
> > +
> > + /**
> > +* @ddc: associated ddc adapter.
> > +* A connector usually has its associated ddc adapter. If a driver uses
> > +* this field, then an appropriate symbolic link is created in connector
> > +* sysfs directory to make it easy for the user to tell which i2c
> > +* adapter is for a particular display.
> > +*/
> > + struct i2c_adapter *ddc;
>
> To help the reader could you add in the above a reference to
> drm_connector_init_with_ddc() sp the reader is told how to init this
> field.
>
> Either add it in PATCH 2 - or merge patch 1 and 2.
>
> Sam
>
> > +
> > /**
> > * @null_edid_counter: track sinks that give us all zeros for the EDID.
> > * Needed to workaround some HW bugs where we get all 0s
> > --
> > 2.17.1
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
[PATCH] drm/komeda: Skips the invalid writeback job
Current DRM-CORE accepts the writeback_job with a empty fb, but that
is an invalid job for HW, so need to skip it when commit it to HW.
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +-
drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 9 -
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 2fed1f6..372e99a 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -265,7 +265,7 @@ void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
komeda_pipeline_update(slave, old->state);
conn_st = wb_conn ? wb_conn->base.base.state : NULL;
- if (conn_st && conn_st->writeback_job)
+ if (conn_st && conn_st->writeback_job && conn_st->writeback_job->fb)
drm_writeback_queue_job(_conn->base, conn_st);
/* step 2: notify the HW to kickoff the update */
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index 9787745..8e2ef63 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -52,9 +52,16 @@
struct komeda_data_flow_cfg dflow;
int err;
- if (!writeback_job || !writeback_job->fb)
+ if (!writeback_job)
return 0;
+ if (!writeback_job->fb) {
+ if (writeback_job->out_fence)
+ DRM_DEBUG_ATOMIC("Out fence required on a invalid
writeback job.\n");
+
+ return writeback_job->out_fence ? -EINVAL : 0;
+ }
+
if (!crtc_st->active) {
DRM_DEBUG_ATOMIC("Cannot write the composition result out on a
inactive CRTC.\n");
return -EINVAL;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 04/18] kunit: test: add kunit_stream a std::stream like logger
On Thu 2019-07-25 13:21:12, Brendan Higgins wrote: > On Wed, Jul 24, 2019 at 12:31 AM Petr Mladek wrote: > > > > On Mon 2019-07-22 16:54:10, Stephen Boyd wrote: > > > Quoting Brendan Higgins (2019-07-22 15:30:49) > > > > On Mon, Jul 22, 2019 at 1:03 PM Stephen Boyd wrote: > > > > > > > > > > > > > > > What's the calling context of the assertions and expectations? I still > > > > > don't like the fact that string stream needs to allocate buffers and > > > > > throw them into a list somewhere because the calling context matters > > > > > there. > > > > > > > > The calling context is the same as before, which is anywhere. > > > > > > Ok. That's concerning then. > > > > > > > > > > > > I'd prefer we just wrote directly to the console/log via printk > > > > > instead. That way things are simple because we use the existing > > > > > buffering path of printk, but maybe there's some benefit to the string > > > > > stream that I don't see? Right now it looks like it builds a string > > > > > and > > > > > then dumps it to printk so I'm sort of lost what the benefit is over > > > > > just writing directly with printk. > > > > > > > > It's just buffering it so the whole string gets printed uninterrupted. > > > > If we were to print out piecemeal to printk, couldn't we have another > > > > call to printk come in causing it to garble the KUnit message we are > > > > in the middle of printing? > > > > > > Yes, printing piecemeal by calling printk many times could lead to > > > interleaving of messages if something else comes in such as an interrupt > > > printing something. Printk has some support to hold "records" but I'm > > > not sure how that would work here because KERN_CONT talks about only > > > being used early on in boot code. I haven't looked at printk in detail > > > though so maybe I'm all wrong and KERN_CONT just works? > > > > KERN_CONT does not guarantee that the message will get printed > > together. The pieces get interleaved with messages printed in > > parallel. > > > > Note that KERN_CONT was originally really meant to be used only during > > boot. It was later used more widely and ended in the best effort category. > > > > There were several attempts to make it more reliable. But it was > > always either too complicated or error prone or both. > > > > You need to use your own buffering if you rely want perfect output. > > The question is if it is really worth the complexity. Also note that > > any buffering reduces the chance that the messages will reach > > the console. > > Seems like that settles it then. Thanks! > > > BTW: There is a work in progress on a lockless printk ring buffer. > > It will make printk() more secure regarding deadlocks. But it might > > make transparent handling of continuous lines even more tricky. > > > > I guess that local buffering, before calling printk(), will be > > even more important then. Well, it might really force us to create > > an API for it. > > Cool! Can you CC me on that discussion? Adding John Oggness into CC. John, please CC Brendan Higgins on the patchsets eventually switching printk() into the lockless buffer. The test framework is going to do its own buffering to keep the related messages together. The lockless ringbuffer might make handling of related (partial) lines worse or better. It might justify KUnit's extra buffering or it might allow to get rid of it. > > Note that stroring the messages into the printk log is basically safe in any > > context. It uses temporary per-CPU buffers for recursive messages and > > in NMI. The only problem is panic() when some CPU gets stuck with the > > lock taken. This will get solved by the lockless ringbuffer. Also > > the temporary buffers will not be necessary any longer. > > Sure, I think Stephen's concern is all the supporting code that is > involved. Not printk specifically. It just means a lot more of KUnit > has to be IRQ safe. I see. BTW: I wonder if KUnit could reuse the existing seq_buf implementation for buffering messages. I am sorry if it has already been proposed and rejected for some reason. I might have missed it. Feel free to just point me to same older mail. > > Much bigger problems are with consoles. There are many of them. It > > means a lot of code and more locks involved, including scheduler > > locks. Note that console lock is a semaphore. > > That shouldn't affect us though, right? As long as we continue to use > the printk interface? I guess that it should not affect KUnit. The only problem might be if the testing framework calls printk() inside scheduler or console code. And only when the tested code uses the same locks that will be used by the called printk(). To be honest I do not fully understand KUnit design. I am not completely sure how the tested code is isolated from the running system. Namely, I do not know if the tested code shares the same locks with the system running the test. Best Regards, Petr
Re: [PATCH v5 2/3] dma-buf: add DMA_BUF_SET_NAME ioctls
Quoting Chenbo Feng (2019-06-13 23:34:07) > From: Greg Hackmann > > This patch adds complimentary DMA_BUF_SET_NAME ioctls, which lets > userspace processes attach a free-form name to each buffer. > > This information can be extremely helpful for tracking and accounting > shared buffers. For example, on Android, we know what each buffer will > be used for at allocation time: GL, multimedia, camera, etc. The > userspace allocator can use DMA_BUF_SET_NAME to associate that > information with the buffer, so we can later give developers a > breakdown of how much memory they're allocating for graphics, camera, > etc. The name was never freed... diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d56993238501..0106b96da585 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -104,6 +104,8 @@ static int dma_buf_release(struct inode *inode, struct file *file) list_del(>list_node); mutex_unlock(_list.lock); + kfree(dmabuf->name); + if (dmabuf->resv == (struct reservation_object *)[1]) reservation_object_fini(dmabuf->resv); This trusts that access to the name via the fs is serialised by the refcount. It would have been great if the inode would only be allocated for a named dmabuf, but I expect that requires replacing struct file after it is exposed (but maybe a struct file can be moved between fs?). -Chris
Re: [PATCH v5 02/24] drm: Add drm_connector_init() variant with ddc
Hi Andrzej.
On Wed, Jul 24, 2019 at 03:59:24PM +0200, Andrzej Pietrasiewicz wrote:
> Allow passing ddc adapter pointer to the init function. Even if
> drm_connector_init() sometime in the future decides to e.g. memset() all
> connector fields to zeros, the newly added function ensures that at its
> completion the ddc member of connector is correctly set.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/drm_connector.c | 19 +++
> include/drm/drm_connector.h | 5 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 068d4b05f1be..06fbfc44fb48 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -296,6 +296,25 @@ int drm_connector_init(struct drm_device *dev,
> }
> EXPORT_SYMBOL(drm_connector_init);
>
> +int drm_connector_init_with_ddc(struct drm_device *dev,
> + struct drm_connector *connector,
> + const struct drm_connector_funcs *funcs,
> + int connector_type,
> + struct i2c_adapter *ddc)
> +{
This is good, with this helper there is no longer any confusion about
ordering.
drm_connector_init_with_ddc() is part of the public interface for
drm_connector and needs kernel-doc documentation.
Sam
> + int ret;
> +
> + ret = drm_connector_init(dev, connector, funcs, connector_type);
> + if (ret)
> + return ret;
> +
> + /* provide ddc symlink in sysfs */
> + connector->ddc = ddc;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_connector_init_with_ddc);
> +
> /**
> * drm_connector_attach_edid_property - attach edid property.
> * @connector: the connector
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 33a6fff85fdb..937fda9c1374 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1410,6 +1410,11 @@ int drm_connector_init(struct drm_device *dev,
> struct drm_connector *connector,
> const struct drm_connector_funcs *funcs,
> int connector_type);
> +int drm_connector_init_with_ddc(struct drm_device *dev,
> + struct drm_connector *connector,
> + const struct drm_connector_funcs *funcs,
> + int connector_type,
> + struct i2c_adapter *ddc);
> void drm_connector_attach_edid_property(struct drm_connector *connector);
> int drm_connector_register(struct drm_connector *connector);
> void drm_connector_unregister(struct drm_connector *connector);
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 01/24] drm: Include ddc adapter pointer in struct drm_connector
Hi Andrzej.
Patch looks good, but one kernel-doc detail.
On Wed, Jul 24, 2019 at 03:59:23PM +0200, Andrzej Pietrasiewicz wrote:
> Add generic code which creates symbolic links in sysfs, pointing to ddc
> interface used by a particular video output. For example:
>
> ls -l /sys/class/drm/card0-HDMI-A-1/ddc
> lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
> -> ../../../../soc/1388.i2c/i2c-2
>
> This makes it easy for user to associate a display with its ddc adapter
> and use e.g. ddcutil to control the chosen monitor.
>
> This patch adds an i2c_adapter pointer to struct drm_connector. Particular
> drivers can then use it instead of using their own private instance. If a
> connector contains a ddc, then create a symbolic link in sysfs.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Acked-by: Daniel Vetter
> Reviewed-by: Andrzej Hajda
> ---
> drivers/gpu/drm/drm_sysfs.c | 8
> include/drm/drm_connector.h | 11 +++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index ad10810bc972..e962a9d45f7e 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -294,6 +295,9 @@ int drm_sysfs_connector_add(struct drm_connector
> *connector)
> /* Let userspace know we have a new connector */
> drm_sysfs_hotplug_event(dev);
>
> + if (connector->ddc)
> + return sysfs_create_link(>kdev->kobj,
> + >ddc->dev.kobj, "ddc");
> return 0;
> }
>
> @@ -301,6 +305,10 @@ void drm_sysfs_connector_remove(struct drm_connector
> *connector)
> {
> if (!connector->kdev)
> return;
> +
> + if (connector->ddc)
> + sysfs_remove_link(>kdev->kobj, "ddc");
> +
> DRM_DEBUG("removing \"%s\" from sysfs\n",
> connector->name);
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 4c30d751487a..33a6fff85fdb 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -41,6 +41,7 @@ struct drm_property;
> struct drm_property_blob;
> struct drm_printer;
> struct edid;
> +struct i2c_adapter;
>
> enum drm_connector_force {
> DRM_FORCE_UNSPECIFIED,
> @@ -1311,6 +1312,16 @@ struct drm_connector {
>* [0]: progressive, [1]: interlaced
>*/
> int audio_latency[2];
> +
> + /**
> + * @ddc: associated ddc adapter.
> + * A connector usually has its associated ddc adapter. If a driver uses
> + * this field, then an appropriate symbolic link is created in connector
> + * sysfs directory to make it easy for the user to tell which i2c
> + * adapter is for a particular display.
> + */
> + struct i2c_adapter *ddc;
To help the reader could you add in the above a reference to
drm_connector_init_with_ddc() sp the reader is told how to init this
field.
Either add it in PATCH 2 - or merge patch 1 and 2.
Sam
> +
> /**
>* @null_edid_counter: track sinks that give us all zeros for the EDID.
>* Needed to workaround some HW bugs where we get all 0s
> --
> 2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] drm: Switch to use DEVFREQ_GOV_SIMPLE_ONDEMAND constant
On 7/25/19 5:52 AM, Yue Hu wrote:
From: Yue Hu
Since governor name is defined by DEVFREQ framework internally, use the
macro definition instead of using the name directly.
Signed-off-by: Yue Hu
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/msm/msm_gpu.c | 3 ++-
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 4edb874..f7308d6 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -95,7 +95,8 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
*/
gpu->devfreq.devfreq = devm_devfreq_add_device(>pdev->dev,
- _devfreq_profile, "simple_ondemand", NULL);
+ _devfreq_profile, DEVFREQ_GOV_SIMPLE_ONDEMAND,
+ NULL);
if (IS_ERR(gpu->devfreq.devfreq)) {
DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
devfreq\n");
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index db79853..a7c18bc 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -157,7 +157,8 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
dev_pm_opp_put(opp);
pfdev->devfreq.devfreq = devm_devfreq_add_device(>pdev->dev,
- _devfreq_profile, "simple_ondemand", NULL);
+ _devfreq_profile, DEVFREQ_GOV_SIMPLE_ONDEMAND,
+ NULL);
if (IS_ERR(pfdev->devfreq.devfreq)) {
DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
devfreq\n");
ret = PTR_ERR(pfdev->devfreq.devfreq);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/amdgpu: Fill out gem_object->resv
Am 25.07.19 um 15:26 schrieb Daniel Vetter:
> That way we can ditch our gem_prime_res_obj implementation. Since ttm
> absolutely needs the right reservation object all the boilerplate is
> already there and we just have to wire it up correctly.
>
> Note that gem/prime doesn't care when we do this, as long as we do it
> before the bo is registered and someone can call the handle2fd ioctl
> on it.
>
> Aside: ttm_buffer_object.ttm_resv could probably be ditched in favour
> of always passing a non-NULL resv to ttm_bo_init(). At least for gem
> drivers that would avoid having two of these, on in ttm_buffer_object
> and the other in drm_gem_object, one just there for confusion.
>
> Acked-by: Gerd Hoffmann
> Cc: Gerd Hoffmann
> Reviewed-by: Emil Velikov
> Signed-off-by: Daniel Vetter
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: Daniel Vetter
> Cc: "Michel Dänzer"
> Cc: Chris Wilson
> Cc: Huang Rui
> Cc: Felix Kuehling
> Cc: Andrey Grodzovsky
> Cc: Evan Quan
> Cc: Sonny Jiang
> Cc: Amber Lin
> Cc: "Michał Mirosław"
> Cc: Junwei Zhang
> Cc: Thomas Zimmermann
> Cc: Samuel Li
Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 17 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h | 1 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 -
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
> 4 files changed, 3 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index 4809d4a5d72a..02cd845e77b3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -267,20 +267,6 @@ static void amdgpu_dma_buf_map_detach(struct dma_buf
> *dma_buf,
> drm_gem_map_detach(dma_buf, attach);
> }
>
> -/**
> - * amdgpu_gem_prime_res_obj - _driver.gem_prime_res_obj implementation
> - * @obj: GEM BO
> - *
> - * Returns:
> - * The BO's reservation object.
> - */
> -struct reservation_object *amdgpu_gem_prime_res_obj(struct drm_gem_object
> *obj)
> -{
> - struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> -
> - return bo->tbo.resv;
> -}
> -
> /**
>* amdgpu_dma_buf_begin_cpu_access - _buf_ops.begin_cpu_access
> implementation
>* @dma_buf: Shared DMA buffer
> @@ -339,8 +325,7 @@ const struct dma_buf_ops amdgpu_dmabuf_ops = {
>* @gobj: GEM BO
>* @flags: Flags such as DRM_CLOEXEC and DRM_RDWR.
>*
> - * The main work is done by the _gem_prime_export helper, which in turn
> - * uses _gem_prime_res_obj.
> + * The main work is done by the _gem_prime_export helper.
>*
>* Returns:
>* Shared DMA buffer representing the GEM BO from the given device.
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
> index 7f73a4f94204..5012e6ab58f1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.h
> @@ -34,7 +34,6 @@ struct dma_buf *amdgpu_gem_prime_export(struct
> drm_gem_object *gobj,
> int flags);
> struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
> struct dma_buf *dma_buf);
> -struct reservation_object *amdgpu_gem_prime_res_obj(struct drm_gem_object *);
> void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj);
> void amdgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
> int amdgpu_gem_prime_mmap(struct drm_gem_object *obj,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index f67b5baed441..98df55534a6d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1397,7 +1397,6 @@ static struct drm_driver kms_driver = {
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_export = amdgpu_gem_prime_export,
> .gem_prime_import = amdgpu_gem_prime_import,
> - .gem_prime_res_obj = amdgpu_gem_prime_res_obj,
> .gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
> .gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
> .gem_prime_vmap = amdgpu_gem_prime_vmap,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index bea6f298dfdc..19ec775b7aa8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -509,6 +509,8 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
> if (unlikely(r != 0))
> return r;
>
> + bo->gem_base.resv = bo->tbo.resv;
> +
> if (!amdgpu_gmc_vram_full_visible(>gmc) &&
> bo->tbo.mem.mem_type == TTM_PL_VRAM &&
> bo->tbo.mem.start < adev->gmc.visible_vram_size >> PAGE_SHIFT)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: [PATCH 1/4] drm/radeon: Fill out gem_object->resv
Am 25.07.19 um 15:26 schrieb Daniel Vetter:
> That way we can ditch our gem_prime_res_obj implementation. Since ttm
> absolutely needs the right reservation object all the boilerplate is
> already there and we just have to wire it up correctly.
>
> Note that gem/prime doesn't care when we do this, as long as we do it
> before the bo is registered and someone can call the handle2fd ioctl
> on it.
>
> Aside: ttm_buffer_object.ttm_resv could probably be ditched in favour
> of always passing a non-NULL resv to ttm_bo_init(). At least for gem
> drivers that would avoid having two of these, on in ttm_buffer_object
> and the other in drm_gem_object, one just there for confusion.
>
> Acked-by: Gerd Hoffmann
> Cc: Gerd Hoffmann
> Reviewed-by: Emil Velikov
> Signed-off-by: Daniel Vetter
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: amd-...@lists.freedesktop.org
Reviewed-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_drv.c| 2 --
> drivers/gpu/drm/radeon/radeon_object.c | 1 +
> drivers/gpu/drm/radeon/radeon_prime.c | 7 ---
> 3 files changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 4403e76e1ae0..a4a78dfdef37 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -152,7 +152,6 @@ struct drm_gem_object
> *radeon_gem_prime_import_sg_table(struct drm_device *dev,
> struct sg_table *sg);
> int radeon_gem_prime_pin(struct drm_gem_object *obj);
> void radeon_gem_prime_unpin(struct drm_gem_object *obj);
> -struct reservation_object *radeon_gem_prime_res_obj(struct drm_gem_object *);
> void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
> void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
>
> @@ -566,7 +565,6 @@ static struct drm_driver kms_driver = {
> .gem_prime_export = radeon_gem_prime_export,
> .gem_prime_pin = radeon_gem_prime_pin,
> .gem_prime_unpin = radeon_gem_prime_unpin,
> - .gem_prime_res_obj = radeon_gem_prime_res_obj,
> .gem_prime_get_sg_table = radeon_gem_prime_get_sg_table,
> .gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
> .gem_prime_vmap = radeon_gem_prime_vmap,
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
> b/drivers/gpu/drm/radeon/radeon_object.c
> index 21f73fc86f38..7a2bad843f8a 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -262,6 +262,7 @@ int radeon_bo_create(struct radeon_device *rdev,
> r = ttm_bo_init(>mman.bdev, >tbo, size, type,
> >placement, page_align, !kernel, acc_size,
> sg, resv, _ttm_bo_destroy);
> + bo->gem_base.resv = bo->tbo.resv;
> up_read(>pm.mclk_lock);
> if (unlikely(r != 0)) {
> return r;
> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
> b/drivers/gpu/drm/radeon/radeon_prime.c
> index deaffce50a2e..8ce3e8045d42 100644
> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> +++ b/drivers/gpu/drm/radeon/radeon_prime.c
> @@ -117,13 +117,6 @@ void radeon_gem_prime_unpin(struct drm_gem_object *obj)
> }
>
>
> -struct reservation_object *radeon_gem_prime_res_obj(struct drm_gem_object
> *obj)
> -{
> - struct radeon_bo *bo = gem_to_radeon_bo(obj);
> -
> - return bo->tbo.resv;
> -}
> -
> struct dma_buf *radeon_gem_prime_export(struct drm_gem_object *gobj,
> int flags)
> {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/komeda: Adds internal bpp computing for arm afbc only format YU08 YU10
The drm_format_info doesn't have any cpp or block_size (both are zero)
information for arm only afbc format YU08/YU10. we need to compute it
by ourselves.
Signed-off-by: Lowry Li (Arm Technology China)
---
.../drm/arm/display/komeda/komeda_format_caps.c| 23 ++
.../drm/arm/display/komeda/komeda_format_caps.h| 3 +++
.../drm/arm/display/komeda/komeda_framebuffer.c| 6 --
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
index cd4d9f5..3c9e060 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
@@ -35,6 +35,29 @@
return NULL;
}
+u32 komeda_get_afbc_format_bpp(const struct drm_format_info *info, u64
modifier)
+{
+ u32 bpp;
+
+ WARN_ON(modifier == DRM_FORMAT_MOD_LINEAR);
+
+ switch (info->format) {
+ case DRM_FORMAT_YUV420_8BIT:
+ bpp = 12;
+ break;
+ case DRM_FORMAT_YUV420_10BIT:
+ bpp = 15;
+ break;
+ default:
+ bpp = info->cpp[0] * 8;
+ break;
+ }
+
+ WARN_ON(bpp == 0);
+
+ return bpp;
+}
+
/* Two assumptions
* 1. RGB always has YTR
* 2. Tiled RGB always has SC
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
index 3631910..32273cf 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
@@ -97,6 +97,9 @@ static inline const char *komeda_get_format_name(u32 fourcc,
u64 modifier)
komeda_get_format_caps(struct komeda_format_caps_table *table,
u32 fourcc, u64 modifier);
+u32 komeda_get_afbc_format_bpp(const struct drm_format_info *info,
+ u64 modifier);
+
u32 *komeda_get_layer_fourcc_list(struct komeda_format_caps_table *table,
u32 layer_type, u32 *n_fmts);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index 10bf63e..966d0c7 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -44,7 +44,7 @@ static int komeda_fb_create_handle(struct drm_framebuffer *fb,
const struct drm_format_info *info = fb->format;
struct drm_gem_object *obj;
u32 alignment_w = 0, alignment_h = 0, alignment_header;
- u32 n_blocks = 0, min_size = 0;
+ u32 n_blocks = 0, min_size = 0, bpp;
obj = drm_gem_object_lookup(file, mode_cmd->handles[0]);
if (!obj) {
@@ -86,10 +86,12 @@ static int komeda_fb_create_handle(struct drm_framebuffer
*fb,
kfb->offset_payload = ALIGN(n_blocks * AFBC_HEADER_SIZE,
alignment_header);
+ bpp = komeda_get_afbc_format_bpp(info, fb->modifier);
kfb->afbc_size = kfb->offset_payload + n_blocks *
-ALIGN(info->cpp[0] * AFBC_SUPERBLK_PIXELS,
+ALIGN(bpp * AFBC_SUPERBLK_PIXELS / 8,
AFBC_SUPERBLK_ALIGNMENT);
min_size = kfb->afbc_size + fb->offsets[0];
+
if (min_size > obj->size) {
DRM_DEBUG_KMS("afbc size check failed, obj_size: 0x%lx.
min_size 0x%x.\n",
obj->size, min_size);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/komeda: Initialize and enable output polling on Komeda
Initialize and enable output polling on Komeda. Signed-off-by: Lowry Li (Arm Technology China) --- drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c index 1462bac..26f2919 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c @@ -15,6 +15,7 @@ #include #include #include +#include #include "komeda_dev.h" #include "komeda_framebuffer.h" @@ -331,6 +332,8 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev) if (err) goto uninstall_irq; + drm_kms_helper_poll_init(drm); + return kms; uninstall_irq: @@ -348,6 +351,7 @@ void komeda_kms_detach(struct komeda_kms_dev *kms) struct drm_device *drm = >base; struct komeda_dev *mdev = drm->dev_private; + drm_kms_helper_poll_fini(drm); mdev->funcs->disable_irq(mdev); drm_dev_unregister(drm); drm_irq_uninstall(drm); -- 1.9.1
[PATCH 3/3] drm/panel: jh057n00900: Print error code on all DRM_DEV_ERROR()s
Most of them had these already but two mere missing. This eases
debugging.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
index cc89831e30a6..a182ca7de701 100644
--- a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
+++ b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
@@ -127,7 +127,7 @@ static int jh057n_init_sequence(struct jh057n *ctx)
ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
if (ret < 0) {
- DRM_DEV_ERROR(dev, "Failed to exit sleep mode\n");
+ DRM_DEV_ERROR(dev, "Failed to exit sleep mode: %d\n", ret);
return ret;
}
/* Panel is operational 120 msec after reset */
@@ -355,7 +355,9 @@ static int jh057n_probe(struct mipi_dsi_device *dsi)
ret = mipi_dsi_attach(dsi);
if (ret < 0) {
- DRM_DEV_ERROR(dev, "mipi_dsi_attach failed. Is host ready?\n");
+ DRM_DEV_ERROR(dev,
+ "mipi_dsi_attach failed (%d). Is host ready?\n",
+ ret);
drm_panel_remove(>panel);
return ret;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/panel: jh057n00900: Move dsi init sequence to prepare
If the panel is wrapped in a panel_bridge it gets prepar()ed before the upstream DSI bridge which can cause hangs (e.g. with imx-nwl since clocks are not enabled yet). To avoid this move the panel's first DSI access to enable() so the upstream bridge can prepare the DSI host controller in it's pre_enable(). The second patch makes the disable() call symmetric to the above and the third one just eases debugging. Guido Günther (3): drm/panel: jh057n00900: Move panel DSI init to enable() drm/panel: jh057n00900: Move mipi_dsi_dcs_set_display_off to disable() drm/panel: jh057n00900: Print error code on all DRM_DEV_ERROR()s .../drm/panel/panel-rocktech-jh057n00900.c| 31 --- 1 file changed, 19 insertions(+), 12 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/panel: jh057n00900: Move mipi_dsi_dcs_set_display_off to disable()
This makes it symmetric with the panel init happening in enable().
Signed-off-by: Guido Günther
---
drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
index c6b4bfd79fde..cc89831e30a6 100644
--- a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
+++ b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
@@ -158,19 +158,23 @@ static int jh057n_enable(struct drm_panel *panel)
static int jh057n_disable(struct drm_panel *panel)
{
struct jh057n *ctx = panel_to_jh057n(panel);
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ int ret;
+
+ ret = backlight_disable(ctx->backlight);
+ if (ret < 0)
+ return ret;
- return backlight_disable(ctx->backlight);
+ return mipi_dsi_dcs_set_display_off(dsi);
}
static int jh057n_unprepare(struct drm_panel *panel)
{
struct jh057n *ctx = panel_to_jh057n(panel);
- struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
if (!ctx->prepared)
return 0;
- mipi_dsi_dcs_set_display_off(dsi);
regulator_disable(ctx->iovcc);
regulator_disable(ctx->vcc);
ctx->prepared = false;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/panel: jh057n00900: Move panel DSI init to enable()
If the panel is wrapped in a panel_bridge it gets prepar()ed before the
upstream DSI bridge which can cause hangs (e.g. with imx-nwl since clocks
are not enabled yet). To avoid this move the panel's first DSI access to
enable() so the upstream bridge can prepare the DSI host controller in
it's pre_enable().
This is also in line with other panel drivers.
Signed-off-by: Guido Günther
---
.../gpu/drm/panel/panel-rocktech-jh057n00900.c| 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
index 1274b54f2672..c6b4bfd79fde 100644
--- a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
+++ b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
@@ -143,6 +143,14 @@ static int jh057n_init_sequence(struct jh057n *ctx)
static int jh057n_enable(struct drm_panel *panel)
{
struct jh057n *ctx = panel_to_jh057n(panel);
+ int ret;
+
+ ret = jh057n_init_sequence(ctx);
+ if (ret < 0) {
+ DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d\n",
+ ret);
+ return ret;
+ }
return backlight_enable(ctx->backlight);
}
@@ -197,13 +205,6 @@ static int jh057n_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(ctx->reset_gpio, 0);
msleep(20);
- ret = jh057n_init_sequence(ctx);
- if (ret < 0) {
- DRM_DEV_ERROR(ctx->dev, "Panel init sequence failed: %d\n",
- ret);
- return ret;
- }
-
ctx->prepared = true;
return 0;
--
2.20.1
Re: [PATCH 2/3] dt-bindings: display/bridge: Add binding for IMX NWL mipi dsi host controller
Hi Guido.
A few comments follows.
Sam
On Wed, Jul 24, 2019 at 05:52:25PM +0200, Guido Günther wrote:
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther
> ---
> .../bindings/display/bridge/imx-nwl-dsi.txt | 89 +++
New binding. Any chance we can get this in yaml format?
This is the way forward and we have to convert the file anyway.
None of the other bridges use yaml format, but someone has to be the
first.
> 1 file changed, 89 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> new file mode 100644
> index ..288fdb726d5a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> @@ -0,0 +1,89 @@
> +Northwest Logic MIPI-DSI on imx SoCs
> +=
> +
> +NWL MIPI-DSI host controller found on i.MX8 platforms. This is a
> +dsi bridge for the for the NWL MIPI-DSI host.
To my best understanding a bridge is something that converts from one
format to another format.
Something that in the drm world are connected to an encoder.
I do not know the HW here - but from this very brif description this
sounds more like a display controller and not a bridge?
> +
> +Required properties:
> +- compatible:"fsl,-nwl-dsi"
> + The following strings are expected:
> + "fsl,imx8mq-nwl-dsi"
> +- reg: the register range of the MIPI-DSI controller
> +- interrupts:the interrupt number for this module
> +- clock, clock-names:phandles to the MIPI-DSI clocks
> + The following clocks are expected on all platforms:
> + "core"- DSI core clock
> + "tx_esc" - TX_ESC clock (used in escape mode)
> + "rx_esc" - RX_ESC clock (used in escape mode)
> + "phy_ref" - PHY_REF clock. Clock is managed by the phy. Only
> +used to read the clock rate.
> +- assigned-clocks: phandles to clocks that require initial configuration
> +- assigned-clock-rates: rates of the clocks that require initial
> configuration
> + The following clocks need to have an initial configuration:
> + "tx_esc" (20 MHz) and "rx_esc" (80 Mhz).
> +- phys: phandle to the phy module representing the DPHY
> + inside the MIPI-DSI IP block
> +- phy-names: should be "dphy"
> +
> +Optional properties:
> +- power-domains phandle to the power domain
> +- srcphandle to the system reset controller
> (required on
> + i.MX8MQ)
Name is not very descriptive.
Other bindings seems to use "resets" here?
> +- mux-selphandle to the MUX register set (required on i.MX8MQ)
> +- assigned-clock-parents phandles to parent clocks that needs to be assigned
> as
> + parents to clocks defined in assigned-clocks
> +
> +Example:
> + mipi_dsi: mipi_dsi@30a0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,imx8mq-nwl-dsi";
> + reg = <0x30A0 0x300>;
> + clocks = < IMX8MQ_CLK_DSI_CORE>,
> + < IMX8MQ_CLK_DSI_AHB>,
> + < IMX8MQ_CLK_DSI_IPG_DIV>,
> + < IMX8MQ_CLK_DSI_PHY_REF>;
> + clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
> + assigned-clocks = < IMX8MQ_CLK_DSI_AHB>,
> + < IMX8MQ_CLK_DSI_CORE>,
> + < IMX8MQ_CLK_DSI_IPG_DIV>;
> + assigned-clock-parents = < IMX8MQ_SYS1_PLL_80M>,
> + < IMX8MQ_SYS1_PLL_266M>;
> + assigned-clock-rates = <8000>,
> +<26600>,
> +<2000>;
> + interrupts = ;
> + power-domains = <_mipi>;
> + src = <>;
> + mux-sel = <_gpr>;
> + phys = <>;
> + phy-names = "dphy";
> + status = "okay";
I recall status should not be included in examples.
> +
> + panel@0 {
> + compatible = "...";
> + port {
> + panel_in: endpoint {
> +remote-endpoint = <_dsi_out>;
> + };
> + };
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + mipi_dsi_in: endpoint {
> + remote-endpoint =
> <_disp0_mipi_dsi>;
> +
Re: [PATCH v2 6/7] drm/panfrost: Add support for GPU heap allocations
On 26/07/2019 10:15, Steven Price wrote:
On 25/07/2019 22:11, Rob Herring wrote:
On Thu, Jul 25, 2019 at 7:08 AM Robin Murphy
wrote:
Hi Rob,
On 25/07/2019 02:10, Rob Herring wrote:
[...]
@@ -328,6 +427,18 @@ static irqreturn_t panfrost_mmu_irq_handler(int
irq, void *data)
access_type = (fault_status >> 8) & 0x3;
source_id = (fault_status >> 16);
+ /* Page fault only */
+ if ((status & mask) == BIT(i)) {
+ WARN_ON(exception_type < 0xC1 ||
exception_type > 0xC4);
+
+ ret = panfrost_mmu_map_fault_addr(pfdev, i,
addr);
+ if (!ret) {
+ mmu_write(pfdev, MMU_INT_CLEAR, BIT(i));
+ status &= ~mask;
+ continue;
+ }
+ }
+
/* terminal fault, print info about the fault */
dev_err(pfdev->dev,
"Unhandled Page fault in AS%d at VA 0x%016llX\n"
@@ -368,8 +479,9 @@ int panfrost_mmu_init(struct panfrost_device
*pfdev)
if (irq <= 0)
return -ENODEV;
- err = devm_request_irq(pfdev->dev, irq, panfrost_mmu_irq_handler,
- IRQF_SHARED, "mmu", pfdev);
+ err = devm_request_threaded_irq(pfdev->dev, irq, NULL,
+ panfrost_mmu_irq_handler,
+ IRQF_ONESHOT, "mmu", pfdev);
The change of flags here breaks platforms using a single shared
interrupt line.
Do they exist? I think this was largely copy-n-paste leftover from the
Good question - of the platforms I know about they all have separate
IRQs, but kbase does explicitly allow shared interrupts so it's quite
possible there is a platform out there which does.
lima driver where utgard has a bunch of irqs and so they get combined.
While it's possible certainly, I'd like to avoid having to do further
rework either to use a workqueue or we need a single driver handler
which then dispatches the sub handlers. The problem is threaded irq
handlers don't work with shared irqs.
It seems reasonable to me to at least wait until someone identifies a
platform which needs shared interrupts before embarking on the refactoring.
I don't know about real silicon, but it's certainly true of our internal
FPGA images that I've been playing with (the Juno board only has a
single IRQ line for the entire FPGA site). That's obviously not a major
priority for upstream, though, so I can hack around it if it's not
otherwise justified.
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMD Drivers
Awesome, thanks for the update! I will wait for the next upstrem... Besides this minor problem everything is wonderful! Even retroarch works now! With 4.18.x 5.1.x and 5.2.x freeze the entire system when access amdgpu... Thanks a lot! --- Gilberto Nunes Ferreira (47) 3025-5907 (47) 99676-7530 - Whatsapp / Telegram Skype: gilberto.nunes36 Em qui, 25 de jul de 2019 às 16:50, Alex Deucher escreveu: > > On Thu, Jul 25, 2019 at 3:29 PM Gilberto Nunes > wrote: > > > > Hi there! > > > > I try the kernel 5.3.0-050300rc1-generic and almost everything works > > perfectly, except there's no sound in HDMI!!! > > Sounds is fixed with this patch: > https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.3=92e6475ae0a0383b012eb21c1aaf0e5456b1a3d9 > which is on it's way upstream for rc2. > > Alex > > > Pavucontrol show me device unplugged! > > But I have now work properly NIC and GPU! > > > > > > lspci > > 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Processor Root Complex > > 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Family 15h (Models > > 60h-6fh) I/O Memory Management Unit > > 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. > > [AMD/ATI] Wani [Radeon R5/R6/R7 Graphics] (rev c8) > > 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Kabini > > HDMI/DP Audio > > 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Host Bridge > > 00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Processor Root Port > > 00:02.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Processor Root Port > > 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Host Bridge > > 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Processor Root Port > > 00:08.0 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device > > 1578 > > 00:09.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 157d > > 00:09.2 Audio device: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Audio Controller > > 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB > > XHCI Controller (rev 20) > > 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA > > Controller [AHCI mode] (rev 49) > > 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB > > EHCI Controller (rev 49) > > 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev > > 4a) > > 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev > > 11) > > 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Processor Function 0 > > 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Processor Function 1 > > 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Processor Function 2 > > 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Processor Function 3 > > 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Processor Function 4 > > 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h > > (Models 60h-6fh) Processor Function 5 > > 01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. > > RTL8411B PCI Express Card Reader (rev 01) > > 01:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. > > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) > > 02:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless > > Network Adapter (rev 31) > > 03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] > > Lexa PRO [Radeon RX 550/550X] (rev c3) > > --- > > Gilberto Nunes Ferreira > > > > (47) 3025-5907 > > (47) 99676-7530 - Whatsapp / Telegram > > > > Skype: gilberto.nunes36 > > > > > > Em qui, 25 de jul de 2019 às 14:26, Alex Deucher > > escreveu: > > > > > > On Thu, Jul 25, 2019 at 3:30 AM Enrico Weigelt, metux IT consult > > > wrote: > > > > > > > > On 24.07.19 16:17, Gilberto Nunes wrote: > > > > > > > > Hi, > > > > > > > > crossposting to dri-devel, as it smells like a problem w/ amdgpu driver. > > > > > > > > > CPU - AMD A12-9720P RADEON R7, 12 COMPUTE CORES 4C+8G > > > > > GPU - Wani [Radeon R5/R6/R7 Graphics] (amdgpu) > > > > > Network Interface card: > > > > > 01:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. > > > > > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) > > > > > > > > > > When I install kernel 4.18.x or 5.x, the network doesn't work > > > > > anymore... > > > > > > > > What about other versions (eg. v4.19) ? > > > > Which is the last working version ? > > > > > > > > > I can loaded the modulo r8169 andr8168. > > > > > I saw enp1s0f1 as well but there's no link at all! > > > > > Even when I fixed the IP none link! > > > > > I cannot ping the network gateway or any
Re: Re: [PATCH v2 6/7] drm/panfrost: Add support for GPU heap allocations
On 25/07/2019 17:13, Alyssa Rosenzweig wrote: >> Either we should prevent mapping of HEAP objects > > I'm good with that. AFAIK, HEAP objects shouldn't be (CPU) mmapped > anyway in normal use; if you need them mapped (for debugging etc), it's > no big deal to just.. not set the HEAP flag in debug builds. > > Or do you mean GPU mapping? Sorry, I was being sloppy again![1] I meant CPU mmapped. I agree there isn't a strong use case for it. I've been investigating/testing Panfrost kernel with the Arm Mali blob. Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer - since SAME_VA means permanently mapped on the CPU this translated to mmapping a HEAP object. Why it does this I've no idea. So I've got an interest in trying to maintain compatibility. kbase places no restriction on mmapping buffers. The main use in the blob for this is being able to dump buffers when debugging (i.e. dump buffers before/after every GPU job). Ideally you also need a way of querying which pages have been backed by faults (much easier with kbase where that's always just the number of pages). Steve [1] kbase+the blob have different terminology here to Panfrost, I do sometimes struggle with the idea of "not mapped on the GPU" - it's not really a concept in kbase. All buffers are "mapped" - they just might be "growable" and not yet full size... :) Hence "mapped" refers to the CPU. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/7] drm/shmem: Put pages independent of a SG table being set
On 25/07/2019 02:09, Rob Herring wrote:
> If a driver does its own management of pages, the shmem helper object's
> pages array could be allocated when a SG table is not. There's not
> really any good reason to tie putting pages with having a SG table when
> freeing the object, so just put pages if the pages array is populated.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Eric Anholt
> Signed-off-by: Rob Herring
LGTM: Reviewed-by: Steven Price
> ---
> v2:
> - new patch
>
> drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 2f64667ac805..477e4cc50f7a 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -118,11 +118,11 @@ void drm_gem_shmem_free_object(struct drm_gem_object
> *obj)
> if (shmem->sgt) {
> dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
>shmem->sgt->nents, DMA_BIDIRECTIONAL);
> -
> - drm_gem_shmem_put_pages(shmem);
> sg_free_table(shmem->sgt);
> kfree(shmem->sgt);
> }
> + if (shmem->pages)
> + drm_gem_shmem_put_pages(shmem);
> }
>
> WARN_ON(shmem->pages_use_count);
> --
> 2.20.1
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [v8, 2/2] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel
Hi Emil Velikov:
First of all, thank you for your comments.
> + struct gpio_desc *enable_gpio;
> + struct gpio_desc *pp33_gpio;
> + struct gpio_desc *pp18_gpio;
DT claims that these gpios are required, yet one is using the optional gpio
API.
Is the code off, or does the DT need fixing?
Thank you for your advice , I will fix code.
static int send_mipi_cmds(struct drm_panel *panel, const struct panel_cmd
*cmds)
This format seems semi-magical. Any particular reason why you're not
using the helpers?
In particular, enter/exit sleep mode and set display on/off.
Normally, we only need to download 0x28 0x10 commands to power-key down.
I noticed that helper func (mipi_dsi_dcs_set_display_off,
mipi_dsi_dcs_enter_sleep_mode) help me send this commands(0x28 0x10).
But based on previous debugging experience, Some vendors are special and
may send other commands after sending cmd 0x28 0x10 or before send cmd 0x28
0x10.
this problem may also occur in our vendor,
so i think this above approach helps me manage code better.
Thanks.
Emil Velikov 于2019年7月1日周一 下午9:41写道：
> Hi Jerry,
>
> On Thu, 25 Apr 2019 at 08:40, Jerry Han wrote:
> >
> > Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
> > panel.
> >
> > V8:
> > - Modify communication address
> >
> > V7:
> > - Add the information of the reviewer
> > - Remove unnecessary delays, The udelay_range code gracefully returns
> > without hitting the scheduler on a delay of 0. (Derek)
> > - Merge the same data structures, like display_mode and off_cmds (Derek)
> > - Optimize the processing of results returned by
> > devm_gpiod_get_optional (Derek)
> >
> > V6:
> > - Add the information of the reviewer (Sam)
> > - Delete unnecessary header files #include (Sam)
> > - The config DRM_PANEL_BOE_HIMAX8279D appears twice. Drop one of them
> (Sam)
> > - ADD static, set_gpios function is not used outside this module (Sam)
> >
> > V5:
> > - Added changelog
> >
> > V4:
> > - Frefix all function maes with boe_ (Sam)
> > - Fsed "enable_gpio" replace "reset_gpio", Make it look clearer (Sam)
> > - Sort include lines alphabetically (Sam)
> > - Fixed entries in the makefile must be sorted alphabetically (Sam)
> > - Add send_mipi_cmds function to avoid duplicating the code (Sam)
> > - Add the necessary delay(reset_delay_t5) between reset and sending
> > the initialization command (Rock wang)
> >
> > V3:
> > - Remove unnecessary delays in sending initialization commands (Jitao
> Shi)
> >
> > V2:
> > - Use SPDX identifier (Sam)
> > - Use necessary header files replace drmP.h (Sam)
> > - Delete unnecessary header files #include (Sam)
> > - Specifies a GPIOs array to control the reset timing,
> > instead of reading "dsi-reset-sequence" data from DTS (Sam)
> > - Delete backlight_disable() function when already disabled (Sam)
> > - Use devm_of_find_backlight() replace of_find_backlight_by_node() (Sam)
> > - Move the necessary data in the DTS to the current file,
> > like porch, display_mode and Init code etc. (Sam)
> > - Add compatible device "boe,himax8279d10p" (Sam)
> >
> > Signed-off-by: Jerry Han
> > Reviewed-by: Sam Ravnborg
> > Reviewed-by: Derek Basehore
> > Cc: Jitao Shi
> > Cc: Rock wang
> > ---
> While the DT has landed, this patch is not merged it seems.
> I think that Sam is waiting for a version which does not trigger so
> many check-patch warnings.
>
> That said, a couple of comments if I may.
>
> > + struct gpio_desc *enable_gpio;
> > + struct gpio_desc *pp33_gpio;
> > + struct gpio_desc *pp18_gpio;
> DT claims that these gpios are required, yet one is using the optional
> gpio API.
> Is the code off, or does the DT need fixing?
>
>
> > +static int send_mipi_cmds(struct drm_panel *panel, const struct
> panel_cmd *cmds)
> > +{
> > + struct panel_info *pinfo = to_panel_info(panel);
> > + unsigned int i = 0;
> > + int err;
> > +
> > + if (!cmds)
> > + return -EFAULT;
> > +
> > + for (i = 0; cmds[i].len != 0; i++) {
> > + const struct panel_cmd *cmd = [i];
> > +
> > + if (cmd->len == 2)
> > + err = mipi_dsi_dcs_write(pinfo->link,
> > + cmd->data[1], NULL,
> 0);
> > + else
> > + err = mipi_dsi_dcs_write(pinfo->link,
> > + cmd->data[1],
> cmd->data + 2,
> > + cmd->len - 2);
> > +
> > + if (err < 0)
> > + return err;
> > +
> > + usleep_range((cmd->data[0]) * 1000,
> > + (1 + cmd->data[0]) * 1000);
> > + }
> > +
> This format seems semi-magical. Any particular reason why you're not
> using the helpers?
> In particular, enter/exit sleep mode and set display on/off.
>
> Speaking of which - the 8inch display uses then, yet they are missing
> for the
Re: AMD Drivers
Hi there! I try the kernel 5.3.0-050300rc1-generic and almost everything works perfectly, except there's no sound in HDMI!!! Pavucontrol show me device unplugged! But I have now work properly NIC and GPU! lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Complex 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) I/O Memory Management Unit 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wani [Radeon R5/R6/R7 Graphics] (rev c8) 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Kabini HDMI/DP Audio 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Host Bridge 00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Port 00:02.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Port 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Host Bridge 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Root Port 00:08.0 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 1578 00:09.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 157d 00:09.2 Audio device: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Audio Controller 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 20) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 49) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 49) 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 4a) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 60h-6fh) Processor Function 5 01:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader (rev 01) 01:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) 02:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 31) 03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon RX 550/550X] (rev c3) --- Gilberto Nunes Ferreira (47) 3025-5907 (47) 99676-7530 - Whatsapp / Telegram Skype: gilberto.nunes36 Em qui, 25 de jul de 2019 às 14:26, Alex Deucher escreveu: > > On Thu, Jul 25, 2019 at 3:30 AM Enrico Weigelt, metux IT consult > wrote: > > > > On 24.07.19 16:17, Gilberto Nunes wrote: > > > > Hi, > > > > crossposting to dri-devel, as it smells like a problem w/ amdgpu driver. > > > > > CPU - AMD A12-9720P RADEON R7, 12 COMPUTE CORES 4C+8G > > > GPU - Wani [Radeon R5/R6/R7 Graphics] (amdgpu) > > > Network Interface card: > > > 01:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. > > > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) > > > > > > When I install kernel 4.18.x or 5.x, the network doesn't work anymore... > > > > What about other versions (eg. v4.19) ? > > Which is the last working version ? > > > > > I can loaded the modulo r8169 andr8168. > > > I saw enp1s0f1 as well but there's no link at all! > > > Even when I fixed the IP none link! > > > I cannot ping the network gateway or any other IP inside LAN! > > > Right now, I booted my laptop with kernel > > > Linux version 5.2.2-050202-generic (kernel@kathleen) (gcc version > > > 9.1.0 (Ubuntu 9.1.0-9ubuntu2)) #201907231250 SMP Tue Jul 23 12:53:21 > > > UTC 2019 > > > > Could you also try 5.3 ? > > > > > The system boot slowly, and I have a SSD Samsung, which in kernel > > > 4.15, boot quickly. > > > And there's many errors in dmesg command, like you can see in this pastbin > > > > > > https://paste.ubuntu.com/p/YhbjnzYYYh/ > > > > looks like something's wrong w/ reading gpu registers (more precisely > > waiting for some changing), that's causing the soft lockup. (maybe too > > big timeout ?) > > It looks like the dGPU fails to power up properly when you attempt to > use it. You can append amdgpu.runpm=0 to the kernel command line in > grub to disable dynamically powering down the dGPU. > > Alex > > > > > > Oh! By the way, the network card r8169 are work wonderful! > > > > Didn't you say (above) that it does not work ? > > Or is it just an immediate fail and later comes back ? > > >
Re: [PATCH v2 6/7] drm/panfrost: Add support for GPU heap allocations
On 25/07/2019 22:28, Rob Herring wrote: On Thu, Jul 25, 2019 at 9:35 AM Steven Price wrote: On 25/07/2019 15:59, Steven Price wrote: [...] It would appear that in the following call sgt==NULL: ret = sg_alloc_table_from_pages(sgt, pages + page_offset, NUM_FAULT_PAGES, 0, SZ_2M, GFP_KERNEL); Which means we've ended up with a BO with bo->sgt==NULL, bo->pages set and bo->is_heap=true. My understanding is this should be impossible. I haven't yet figured out how this happens - it seems to be just before termination, so it might be a race with cleanup? That was a red herring - it's partly my test case doing something a bit weird. This crash is caused by doing an mmap of a HEAP object before any fault has occurred. My brother Red is always causing problems. ;) But you were right that I need to kfree bo->sgts. Additionally, I also need to call sg_free_table on each table. drm_gem_shmem_mmap() calls drm_gem_shmem_get_pages() which will populate bo->base.pages (even if bo->is_heap). Either we should prevent mapping of HEAP objects, or alternatively bo->base.pages could be allocated upfront instead of during the first fault. My preference would be allocating it upfront because optimising for the case of a HEAP BO which isn't used seems a bit weird. Although there's still the question of exactly what the behaviour should be of accessing through the CPU pages which haven't been allocated yet. Also shmem->pages_use_count needs incrementing to stop drm_gem_shmem_get_pages() replacing bo->base.pages. I haven't tested what happens if you mmap *after* the first fault. I did say mmap had undefined/unknown behavior. True - and I was surprised to find out my test was actually doing that! But crashing the kernel is perhaps a bit excessive! Avoiding the mmap of HEAP objects everything runs fine - and the memory leaks are much smaller than they used to be :) Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] arm64: dts: fast models: Increase clcd's max-memory-bandwidth
On 25/07/2019 16:15, Robin Murphy wrote:
Hi Kevin,
Hi Robin,
On 25/07/2019 15:50, Kevin Brodsky wrote:
It may be desirable on certain platforms, such as Android, to
use 32bpp buffers. Since there is no clear bandwidth limit for the
CLCD component on the fast model, let's increase
max-memory-bandwidth to allow using 32bpp buffers.
Given that the property is optional anyway, would it hurt to just remove
it? After trying to dig up any relevant internal email history, it's
still far from clear how and why it got here in the first place.
Very good point, I hadn't realised it was an optional property. Removing it
completely seems to work fine. I'll send a v2 removing it from both fvp-base-revc.dts
and rtsm_ve-motherboard.dtsi. Thanks!
Kevin
Robin.
Reported-by: Ruben Ayrapetyan
Signed-off-by: Kevin Brodsky
---
arch/arm64/boot/dts/arm/fvp-base-revc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
index 687707020ec1..3aee49ed6d88 100644
--- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
+++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
@@ -269,7 +269,7 @@
motherboard {
iofpga@3, {
clcd@1f {
- max-memory-bandwidth = <13000>; /*
16bpp @ 63.5MHz */
+ max-memory-bandwidth = <26000>; /*
32bpp @ 63.5MHz */
};
};
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/7] drm/panfrost: Add support for GPU heap allocations
On 25/07/2019 15:59, Steven Price wrote: [...] > It would appear that in the following call sgt==NULL: >> ret = sg_alloc_table_from_pages(sgt, pages + page_offset, >> NUM_FAULT_PAGES, 0, SZ_2M, GFP_KERNEL); > > Which means we've ended up with a BO with bo->sgt==NULL, bo->pages set > and bo->is_heap=true. My understanding is this should be impossible. > > I haven't yet figured out how this happens - it seems to be just before > termination, so it might be a race with cleanup? That was a red herring - it's partly my test case doing something a bit weird. This crash is caused by doing an mmap of a HEAP object before any fault has occurred. drm_gem_shmem_mmap() calls drm_gem_shmem_get_pages() which will populate bo->base.pages (even if bo->is_heap). Either we should prevent mapping of HEAP objects, or alternatively bo->base.pages could be allocated upfront instead of during the first fault. My preference would be allocating it upfront because optimising for the case of a HEAP BO which isn't used seems a bit weird. Although there's still the question of exactly what the behaviour should be of accessing through the CPU pages which haven't been allocated yet. Also shmem->pages_use_count needs incrementing to stop drm_gem_shmem_get_pages() replacing bo->base.pages. I haven't tested what happens if you mmap *after* the first fault. Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: hmm_range_fault related fixes and legacy API removal v3
On Wed, Jul 24, 2019 at 08:52:51AM +0200, Christoph Hellwig wrote: > Hi Jérôme, Ben and Jason, > > below is a series against the hmm tree which fixes up the mmap_sem > locking in nouveau and while at it also removes leftover legacy HMM APIs > only used by nouveau. > > The first 4 patches are a bug fix for nouveau, which I suspect should > go into this merge window even if the code is marked as staging, just > to avoid people copying the breakage. > > Changes since v2: > - new patch from Jason to document FAULT_FLAG_ALLOW_RETRY semantics >better > - remove -EAGAIN handling in nouveau earlier I don't see Ralph's tested by, do you think it changed enough to require testing again? If so, Ralph would you be so kind? In any event, I'm sending this into linux-next and intend to forward the first four next week. Thanks, Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/7] drm/panfrost: Add heap and no execute buffer allocation
This series is: Acked-by: Alyssa Rosenzweig On Wed, Jul 24, 2019 at 07:09:56PM -0600, Rob Herring wrote: > This series adds new BO allocation flags PANFROST_BO_HEAP and > PANFROST_BO_NOEXEC. The heap allocations are paged in on GPU page faults. > > This is based on drm-misc-next. A branch is here[1]. > > Rob > > [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git > panfrost/heap-noexec > > Rob Herring (7): > drm/gem: Allow sparsely populated page arrays in drm_gem_put_pages > drm/shmem: Put pages independent of a SG table being set > drm/panfrost: Restructure the GEM object creation > drm/panfrost: Split panfrost_mmu_map SG list mapping to its own > function > drm/panfrost: Add a no execute flag for BO allocations > drm/panfrost: Add support for GPU heap allocations > drm/panfrost: Bump driver version to 1.1 > > drivers/gpu/drm/drm_gem.c | 3 + > drivers/gpu/drm/drm_gem_shmem_helper.c | 4 +- > drivers/gpu/drm/panfrost/TODO | 2 - > drivers/gpu/drm/panfrost/panfrost_drv.c | 61 ++-- > drivers/gpu/drm/panfrost/panfrost_gem.c | 93 ++-- > drivers/gpu/drm/panfrost/panfrost_gem.h | 16 +- > drivers/gpu/drm/panfrost/panfrost_mmu.c | 189 > include/uapi/drm/panfrost_drm.h | 3 + > 8 files changed, 307 insertions(+), 64 deletions(-) > > -- > 2.20.1 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/7] drm/panfrost: Add support for GPU heap allocations
On 25/07/2019 22:11, Rob Herring wrote:
On Thu, Jul 25, 2019 at 7:08 AM Robin Murphy wrote:
Hi Rob,
On 25/07/2019 02:10, Rob Herring wrote:
[...]
@@ -328,6 +427,18 @@ static irqreturn_t panfrost_mmu_irq_handler(int irq, void
*data)
access_type = (fault_status >> 8) & 0x3;
source_id = (fault_status >> 16);
+ /* Page fault only */
+ if ((status & mask) == BIT(i)) {
+ WARN_ON(exception_type < 0xC1 || exception_type > 0xC4);
+
+ ret = panfrost_mmu_map_fault_addr(pfdev, i, addr);
+ if (!ret) {
+ mmu_write(pfdev, MMU_INT_CLEAR, BIT(i));
+ status &= ~mask;
+ continue;
+ }
+ }
+
/* terminal fault, print info about the fault */
dev_err(pfdev->dev,
"Unhandled Page fault in AS%d at VA 0x%016llX\n"
@@ -368,8 +479,9 @@ int panfrost_mmu_init(struct panfrost_device *pfdev)
if (irq <= 0)
return -ENODEV;
- err = devm_request_irq(pfdev->dev, irq, panfrost_mmu_irq_handler,
-IRQF_SHARED, "mmu", pfdev);
+ err = devm_request_threaded_irq(pfdev->dev, irq, NULL,
+ panfrost_mmu_irq_handler,
+ IRQF_ONESHOT, "mmu", pfdev);
The change of flags here breaks platforms using a single shared
interrupt line.
Do they exist? I think this was largely copy-n-paste leftover from the
Good question - of the platforms I know about they all have separate
IRQs, but kbase does explicitly allow shared interrupts so it's quite
possible there is a platform out there which does.
lima driver where utgard has a bunch of irqs and so they get combined.
While it's possible certainly, I'd like to avoid having to do further
rework either to use a workqueue or we need a single driver handler
which then dispatches the sub handlers. The problem is threaded irq
handlers don't work with shared irqs.
It seems reasonable to me to at least wait until someone identifies a
platform which needs shared interrupts before embarking on the refactoring.
Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/7] drm/panfrost: Restructure the GEM object creation
On 25/07/2019 02:09, Rob Herring wrote:
> Setting the GPU VA when creating the GEM object doesn't allow for any
> conditional adjustments. In preparation to support adjusting the
> mapping, restructure the GEM object creation to map the GEM object after
> we've created the base shmem object.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 21 +++--
> drivers/gpu/drm/panfrost/panfrost_gem.c | 58 -
> drivers/gpu/drm/panfrost/panfrost_gem.h | 5 +++
> 3 files changed, 59 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index cb43ff4ebf4a..d354b92964d5 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -46,29 +46,20 @@ static int panfrost_ioctl_get_param(struct drm_device
> *ddev, void *data, struct
> static int panfrost_ioctl_create_bo(struct drm_device *dev, void *data,
> struct drm_file *file)
> {
> - int ret;
> - struct drm_gem_shmem_object *shmem;
> + struct panfrost_gem_object *bo;
> struct drm_panfrost_create_bo *args = data;
>
> if (!args->size || args->flags || args->pad)
> return -EINVAL;
>
> - shmem = drm_gem_shmem_create_with_handle(file, dev, args->size,
> - >handle);
> - if (IS_ERR(shmem))
> - return PTR_ERR(shmem);
> -
> - ret = panfrost_mmu_map(to_panfrost_bo(>base));
> - if (ret)
> - goto err_free;
> + bo = panfrost_gem_create_with_handle(file, dev, args->size, args->flags,
> + >handle);
> + if (IS_ERR(bo))
> + return PTR_ERR(bo);
>
> - args->offset = to_panfrost_bo(>base)->node.start << PAGE_SHIFT;
> + args->offset = bo->node.start << PAGE_SHIFT;
>
> return 0;
> -
> -err_free:
> - drm_gem_handle_delete(file, args->handle);
> - return ret;
> }
>
> /**
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index 543ab1b81bd5..df70dcf3cb2f 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -23,7 +23,8 @@ static void panfrost_gem_free_object(struct drm_gem_object
> *obj)
> panfrost_mmu_unmap(bo);
>
> spin_lock(>mm_lock);
> - drm_mm_remove_node(>node);
> + if (drm_mm_node_allocated(>node))
> + drm_mm_remove_node(>node);
> spin_unlock(>mm_lock);
>
> drm_gem_shmem_free_object(obj);
> @@ -50,10 +51,7 @@ static const struct drm_gem_object_funcs
> panfrost_gem_funcs = {
> */
> struct drm_gem_object *panfrost_gem_create_object(struct drm_device *dev,
> size_t size)
> {
> - int ret;
> - struct panfrost_device *pfdev = dev->dev_private;
> struct panfrost_gem_object *obj;
> - u64 align;
>
> obj = kzalloc(sizeof(*obj), GFP_KERNEL);
> if (!obj)
> @@ -61,20 +59,52 @@ struct drm_gem_object *panfrost_gem_create_object(struct
> drm_device *dev, size_t
>
> obj->base.base.funcs = _gem_funcs;
>
> - size = roundup(size, PAGE_SIZE);
> - align = size >= SZ_2M ? SZ_2M >> PAGE_SHIFT : 0;
> + return >base.base;
> +}
> +
> +static int panfrost_gem_map(struct panfrost_device *pfdev, struct
> panfrost_gem_object *bo)
> +{
> + int ret;
> + size_t size = bo->base.base.size;
> + u64 align = size >= SZ_2M ? SZ_2M >> PAGE_SHIFT : 0;
>
> spin_lock(>mm_lock);
> - ret = drm_mm_insert_node_generic(>mm, >node,
> + ret = drm_mm_insert_node_generic(>mm, >node,
>size >> PAGE_SHIFT, align, 0, 0);
> spin_unlock(>mm_lock);
> + if (ret)
> + return ret;
> +
> + return panfrost_mmu_map(bo);
> +}
> +
> +struct panfrost_gem_object *
> +panfrost_gem_create_with_handle(struct drm_file *file_priv,
> + struct drm_device *dev, size_t size,
> + u32 flags,
> + uint32_t *handle)
> +{
> + int ret;
> + struct panfrost_device *pfdev = dev->dev_private;
> + struct drm_gem_shmem_object *shmem;
> + struct panfrost_gem_object *bo;
> +
> + size = roundup(size, PAGE_SIZE);
> +
> + shmem = drm_gem_shmem_create_with_handle(file_priv, dev, size, handle);
> + if (IS_ERR(shmem))
> + return ERR_CAST(shmem);
> +
> + bo = to_panfrost_bo(>base);
> +
> + ret = panfrost_gem_map(pfdev, bo);
> if (ret)
> goto free_obj;
>
> - return >base.base;
> + return bo;
>
> free_obj:
> - kfree(obj);
> + drm_gem_handle_delete(file_priv, *handle);
> return ERR_PTR(ret);
> }
>
> @@ -83,8 +113,10 @@
[PATCH v2] arm64: dts: fast models: Remove clcd's max-memory-bandwidth
It is unclear why max-memory-bandwidth should be set for CLCD on the
fast model. Removing that property allows allocating and using 32bpp
buffers, which may be desirable on certain platforms such as
Android.
Reported-by: Ruben Ayrapetyan
Signed-off-by: Kevin Brodsky
---
Changes in v2:
- Remove the attribute completely instead of increasing its value. It is
optional and there is no clear reason why it should be set at all.
arch/arm64/boot/dts/arm/fvp-base-revc.dts| 8
arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 2 --
2 files changed, 10 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
index 687707020ec1..62ab0d54ff71 100644
--- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
+++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
@@ -265,13 +265,5 @@
<0 0 42 0 0 GIC_SPI 42
IRQ_TYPE_LEVEL_HIGH>,
<0 0 43 0 0 GIC_SPI 43
IRQ_TYPE_LEVEL_HIGH>,
<0 0 44 0 0 GIC_SPI 44
IRQ_TYPE_LEVEL_HIGH>;
-
- motherboard {
- iofpga@3, {
- clcd@1f {
- max-memory-bandwidth = <13000>; /*
16bpp @ 63.5MHz */
- };
- };
- };
};
};
diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
index 454cf6c44c49..03a7bf079c8f 100644
--- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
+++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
@@ -188,8 +188,6 @@
interrupts = <14>;
clocks = <_oscclk1>,
<_clk24mhz>;
clock-names = "clcdclk", "apb_pclk";
- /* 800x600 16bpp @36MHz works fine */
- max-memory-bandwidth = <5400>;
memory-region = <>;
port {
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/7] drm/panfrost: Add support for GPU heap allocations
On 25/07/2019 02:10, Rob Herring wrote: > The midgard/bifrost GPUs need to allocate GPU heap memory which is > allocated on GPU page faults and not pinned in memory. The vendor driver > calls this functionality GROW_ON_GPF. > > This implementation assumes that BOs allocated with the > PANFROST_BO_NOEXEC flag are never mmapped or exported. Both of those may > actually work, but I'm unsure if there's some interaction there. It > would cause the whole object to be pinned in memory which would defeat > the point of this. > > On faults, we map in 2MB at a time in order to utilize huge pages (if > enabled). Currently, once we've mapped pages in, they are only unmapped > if the BO is freed. Once we add shrinker support, we can unmap pages > with the shrinker. I've taken this for a spin, unfortunately it falls over: [ 599.733909] Unable to handle kernel NULL pointer dereference at virtual address [ 599.742732] Mem abort info: [ 599.745526] ESR = 0x9646 [ 599.748612] Exception class = DABT (current EL), IL = 32 bits [ 599.754559] SET = 0, FnV = 0 [ 599.757612] EA = 0, S1PTW = 0 [ 599.760780] Data abort info: [ 599.763687] ISV = 0, ISS = 0x0046 [ 599.767549] CM = 0, WnR = 1 [ 599.770546] user pgtable: 4k pages, 48-bit VAs, pgdp=af36d000 [ 599.777017] [] pgd=af260003, pud=af269003, pmd= [ 599.785782] Internal error: Oops: 9646 [#1] SMP [ 599.790667] Modules linked in: panfrost gpu_sched [ 599.795390] CPU: 0 PID: 1007 Comm: irq/67-mmu Tainted: G S 5.3.0-rc1-00355-g8c4e5073a168-dirty #35 [ 599.805653] Hardware name: HiKey960 (DT) [ 599.809577] pstate: 6005 (nZCv daif -PAN -UAO) [ 599.814384] pc : __sg_alloc_table+0x14/0x168 [ 599.818654] lr : sg_alloc_table+0x2c/0x60 [ 599.822660] sp : 11bcbba0 [ 599.825973] x29: 11bcbba0 x28: [ 599.831289] x27: 8000a87081e0 x26: [ 599.836603] x25: 0080 x24: 0020 [ 599.841917] x23: x22: [ 599.847231] x21: 0200 x20: [ 599.852546] x19: f000 x18: 0010 [ 599.857860] x17: x16: [ 599.863175] x15: x14: 3030303030303030 [ 599.868489] x13: 3030303030302873 x12: 656761705f6d6f72 [ 599.873805] x11: 665f656c6261745f x10: 0004 [ 599.879118] x9 : x8 : 7e00 [ 599.884434] x7 : 8000a870cff8 x6 : 104277e8 [ 599.889748] x5 : 0cc0 x4 : [ 599.895061] x3 : x2 : 0080 [ 599.900375] x1 : 0008 x0 : [ 599.905692] Call trace: [ 599.908143] __sg_alloc_table+0x14/0x168 [ 599.912067] sg_alloc_table+0x2c/0x60 [ 599.915732] __sg_alloc_table_from_pages+0xd8/0x208 [ 599.920612] sg_alloc_table_from_pages+0x14/0x20 [ 599.925252] panfrost_mmu_map_fault_addr+0x288/0x368 [panfrost] [ 599.931185] panfrost_mmu_irq_handler+0x134/0x298 [panfrost] [ 599.936855] irq_thread_fn+0x28/0x78 [ 599.940435] irq_thread+0x124/0x1f8 [ 599.943931] kthread+0x120/0x128 [ 599.947166] ret_from_fork+0x10/0x18 [ 599.950753] Code: 719f 910003fd a9046bf9 1a821099 (a9007c1f) [ 599.956854] ---[ end trace d99c6028af6bbbd8 ]--- It would appear that in the following call sgt==NULL: > ret = sg_alloc_table_from_pages(sgt, pages + page_offset, > NUM_FAULT_PAGES, 0, SZ_2M, GFP_KERNEL); Which means we've ended up with a BO with bo->sgt==NULL, bo->pages set and bo->is_heap=true. My understanding is this should be impossible. I haven't yet figured out how this happens - it seems to be just before termination, so it might be a race with cleanup? > Cc: Tomeu Vizoso > Cc: Boris Brezillon > Cc: Robin Murphy > Cc: Steven Price > Cc: Alyssa Rosenzweig > Signed-off-by: Rob Herring > --- > v2: > - Stop leaking pages! > - Properly call dma_unmap_sg on cleanup > - Enforce PANFROST_BO_NOEXEC when PANFROST_BO_HEAP is set > > drivers/gpu/drm/panfrost/TODO | 2 - > drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +- > drivers/gpu/drm/panfrost/panfrost_gem.c | 23 +++- > drivers/gpu/drm/panfrost/panfrost_gem.h | 8 ++ > drivers/gpu/drm/panfrost/panfrost_mmu.c | 134 ++-- > include/uapi/drm/panfrost_drm.h | 1 + > 6 files changed, 159 insertions(+), 16 deletions(-) > > diff --git a/drivers/gpu/drm/panfrost/TODO b/drivers/gpu/drm/panfrost/TODO > index c2e44add37d8..64129bf73933 100644 > --- a/drivers/gpu/drm/panfrost/TODO > +++ b/drivers/gpu/drm/panfrost/TODO > @@ -14,8 +14,6 @@ >The hard part is handling when more address spaces are needed than what >the h/w provides. > > -- Support pinning pages on demand (GPU page faults). > - > - Support userspace controlled GPU virtual addresses. Needed for Vulkan. > (Tomeu) > > - Support for madvise and a
Re: Re: [PATCH v2 6/7] drm/panfrost: Add support for GPU heap allocations
> Sorry, I was being sloppy again![1] I meant CPU mmapped. No worries, just wanted to check :) > Apparently the blob in some cases creates a SAME_VA GROW_ON_GPF buffer - > since SAME_VA means permanently mapped on the CPU this translated to > mmapping a HEAP object. Why it does this I've no idea. I'm not sure I follow. Conceptually, if you're permanently mapped, there's nothing to grow, right? Is there a reason not to just disable HEAP in this cases, i.e.: if (flags & SAME_VA) flags &= ~GROW_ON_GPF; It may not be fully optimal, but that way the legacy code keeps working and upstream userspace isn't held back :) > The main use in the blob for > this is being able to dump buffers when debugging (i.e. dump buffers > before/after every GPU job). Could we disable HEAP support in userspace (not setting the flags) for debug builds that need to dump buffers? In production the extra memory usage matters, hence this patch, but in dev, there's plenty of memory to spare. > Ideally you also need a way of querying which pages have been backed > by faults (much easier with kbase where that's always just the number > of pages). Is there a use case for this with one of the userland APIs? (Maybe Vulkan?) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm/hmm: replace hmm_update with mmu_notifier_range
On 7/24/19 6:14 PM, Jason Gunthorpe wrote:
On Tue, Jul 23, 2019 at 02:05:06PM -0700, Ralph Campbell wrote:
The hmm_mirror_ops callback function sync_cpu_device_pagetables() passes
a struct hmm_update which is a simplified version of struct
mmu_notifier_range. This is unnecessary so replace hmm_update with
mmu_notifier_range directly.
Signed-off-by: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: Jason Gunthorpe
Cc: Christoph Hellwig
Cc: Ben Skeggs
This is based on 5.3.0-rc1 plus Christoph Hellwig's 6 patches
("hmm_range_fault related fixes and legacy API removal v2").
Jason, I believe this is the patch you were requesting.
Doesn't this need revision to include amgpu?
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c: .sync_cpu_device_pagetables =
amdgpu_mn_sync_pagetables_gfx,
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c: .sync_cpu_device_pagetables =
amdgpu_mn_sync_pagetables_hsa,
Thanks,
Jason
Yes. I have added this to v2 which I'll send out with Christoph's 2
patches and the hmm_range.vma removal patch you suggested.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/7] drm/panfrost: Add support for GPU heap allocations
> Either we should prevent mapping of HEAP objects I'm good with that. AFAIK, HEAP objects shouldn't be (CPU) mmapped anyway in normal use; if you need them mapped (for debugging etc), it's no big deal to just.. not set the HEAP flag in debug builds. Or do you mean GPU mapping? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] RFT: drm/pl111: Support grayscale
Hi, Am Mittwoch, 24. Juli 2019, 14:33:06 CEST schrieb Linus Walleij: > On Tue, Jul 23, 2019 at 5:19 PM Fabian Vogt wrote: > > > I gave the series a try (virtual CX and TP so far, will do on a real CX > > later): > > OOPS with a nullptr deref during probe. > > This diff which just moves some lines around fixes that and the LCD appears > > to > > work properly. > > OK I folded this into my patch, thanks! > > > Once I verified the 24bit depth and clock speed config on HW as well, I can > > give you my Tested-by, or would you prefer that I resubmit your series with > > the > > fix below? > > It's fine if you test it just with your patch as-is, I didn't change anything > else. > > I would be amazed if it "just works" now. Indeed, you won't be. On a real CX the LCD displays shows content without any other changes to the set, but has a ~3Hz pulsating effect scrolling from the top to the bottom and the gray text changes color slightly. Without the patchset applied everything looks perfectly. I tried setting vrefresh to 20, fb_bpp to 16 and forcing an inverted panel clock, but the pulsing didn't change. Using the emulated CX I compared the contents of the registers and found that only the IPC bit (which I tried to set, so that's likely not it) and the interrupt registers have a different content. Any idea? Thanks, Fabian > Yours, > Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/7] drm/gem: Allow sparsely populated page arrays in drm_gem_put_pages
On 25/07/2019 02:09, Rob Herring wrote:
> Panfrost has a need for pages allocated on demand via GPU page faults.
> When releasing the pages, the only thing preventing using
> drm_gem_put_pages() is needing to skip over unpopulated pages, so allow
> for skipping over NULL struct page pointers.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Rob Herring
LGTM: Reviewed-by: Steven Price
> ---
> v2:
> - new patch
>
> drivers/gpu/drm/drm_gem.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 243f43d70f42..db373c945f16 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -633,6 +633,9 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct
> page **pages,
>
> pagevec_init();
> for (i = 0; i < npages; i++) {
> + if (!pages[i])
> + continue;
> +
> if (dirty)
> set_page_dirty(pages[i]);
>
> --
> 2.20.1
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: OLED panel brightness support
at 00:03, wrote: -Original Message- From: Daniel Vetter On Behalf Of Daniel Vetter Sent: Wednesday, July 24, 2019 6:49 AM To: Kai-Heng Feng Cc: dri-devel@lists.freedesktop.org; Anthony Wong; Limonciello, Mario Subject: Re: OLED panel brightness support [EXTERNAL EMAIL] On Tue, Jul 23, 2019 at 06:46:55PM +0800, Kai-Heng Feng wrote: Hi, Currently, OLED panel brightness [1] is not supported. We have a similar Dell system that also affect by lack of OLED brightness support. I’ve investigated both kernel and user space but I haven’t found a good general solution yet. Dell systems use EDID descriptor 4 as Dell specific descriptor, which reports its panel type and we can know it’s an OLED panel or not. My initial thought is to add a new attribute “oled" in drm_sysfs.c [2] to let userspace like clutter [3] to control the brightness. However other DEs may need to implement their own OLED brightness support which isn’t ideal. So I’d like to know if there’s any good way to support OLED brightness in good old backlight sysfs, to let userspace keep to the current interface. [1] https://bugs.freedesktop.org/show_bug.cgi?id=97883 [2] https://pastebin.ubuntu.com/p/QYrRBppVT9/ [3] https://gitlab.gnome.org/GNOME/clutter/blob/master/clutter/clutter- brightness-contrast-effect.c#L559 I think the Most Proper Solution would be to integrate the backlight support into drm, by adding the backlight knobs as kms properties to the correct connector. This would fix a whole bag of issue: - no more ill-defined magic for userspace to find the right backlight - we could have well-defined semantics what happens with the backlight across a kms modeset - issues like this could be solved with a small helper and a bit of code in the kernel (there's also other DDC knobs to control backlight, which we also don't really expose in a consistent way). Downside is how to roll this out in a backward compatible way, without breaking the world: - fbcon/fbdev needs to be taught to not do it's own backlight wrangling for kms drivers which handle backlight natively - we might need an opt-in magic for this, if it turns out that the kms driver handling the backlight breaks stuff - userspace ofc needs to fall back to its current pile of hacks if the backlight stuff isn't supported natively. Adding more ill-defined sysfs files, or more magice ordering rules, or anything else like that doesn't sound too appealing. Where are you thinking that the opt in magic would occur then? Userspace? As KH said, at least on Dell it's a known location in EDID to indicate panel is OLED, so it seems like this could be a kernel time documented magic at least to turn this on in the important scenarios. I think what Daniel says is to keep a uniform backlight interface. The next question is, how do we change the brightness level for OLED displays? Is changing gamma value a good way to do it? Kai-Heng -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: remove duplicated include from dc_link.c
Remove duplicated include. Reported-by: Hulk Robot Signed-off-by: YueHaibing --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index 193d6f1..a14785d 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -45,10 +45,6 @@ #include "dpcd_defs.h" #include "dmcu.h" #include "hw/clk_mgr.h" -#if defined(CONFIG_DRM_AMD_DC_DCN2_0) -#include "resource.h" -#endif -#include "hw/clk_mgr.h" #define DC_LOGGER_INIT(logger) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: AMD Drivers
Hi there > What about other versions (eg. v4.19) ? > Which is the last working version ? The only series that works properly is 4.15.x > Could you also try 5.3 ? I will, ASAP! >> Oh! By the way, the network card r8169 are work wonderful! >Didn't you say (above) that it does not work ? >Or is it just an immediate fail and later comes back ? Well... I installed 5.2 and after reboot NIC works fine, but get stuck with amdgpu again... It's seems 5.x is in the right path... But still amdgpu has some bugs, I think... Thanks a lot for your coments Best regards Em qui, 25 de jul de 2019 às 04:22, Enrico Weigelt, metux IT consult escreveu: > > On 24.07.19 16:17, Gilberto Nunes wrote: > > Hi, > > crossposting to dri-devel, as it smells like a problem w/ amdgpu driver. > > > CPU - AMD A12-9720P RADEON R7, 12 COMPUTE CORES 4C+8G > > GPU - Wani [Radeon R5/R6/R7 Graphics] (amdgpu) > > Network Interface card: > > 01:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. > > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) > > > > When I install kernel 4.18.x or 5.x, the network doesn't work anymore... > > What about other versions (eg. v4.19) ? > Which is the last working version ? > > > I can loaded the modulo r8169 andr8168. > > I saw enp1s0f1 as well but there's no link at all! > > Even when I fixed the IP none link! > > I cannot ping the network gateway or any other IP inside LAN! > > Right now, I booted my laptop with kernel > > Linux version 5.2.2-050202-generic (kernel@kathleen) (gcc version > > 9.1.0 (Ubuntu 9.1.0-9ubuntu2)) #201907231250 SMP Tue Jul 23 12:53:21 > > UTC 2019 > > Could you also try 5.3 ? > > > The system boot slowly, and I have a SSD Samsung, which in kernel > > 4.15, boot quickly. > > And there's many errors in dmesg command, like you can see in this pastbin > > > > https://paste.ubuntu.com/p/YhbjnzYYYh/ > > looks like something's wrong w/ reading gpu registers (more precisely > waiting for some changing), that's causing the soft lockup. (maybe too > big timeout ?) > > > Oh! By the way, the network card r8169 are work wonderful! > > Didn't you say (above) that it does not work ? > Or is it just an immediate fail and later comes back ? > > > --mtx > > > -- > Enrico Weigelt, metux IT consult > Free software and Linux embedded engineering > i...@metux.net -- +49-151-27565287 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/7] drm/panfrost: Add a no execute flag for BO allocations
On 25/07/2019 02:10, Rob Herring wrote:
> Executable buffers have an alignment restriction that they can't cross
> 16MB boundary as the GPU program counter is 24-bits. This restriction is
> currently not handled and we just get lucky. As current userspace
> assumes all BOs are executable, that has to remain the default. So add a
> new PANFROST_BO_NOEXEC flag to allow userspace to indicate which BOs are
> not executable.
>
> There is also a restriction that executable buffers cannot start or end
> on a 4GB boundary. This is mostly avoided as there is only 4GB of space
> currently and the beginning is already blocked out for NULL ptr
> detection. Add support to handle this restriction fully regardless of
> the current constraints.
>
> For existing userspace, all created BOs remain executable, but the GPU
> VA alignment will be increased to the size of the BO. This shouldn't
> matter as there is plenty of GPU VA space.
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Acked-by: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Reviewed-by: Steven Price
> ---
> v2:
> - Rework panfrost_drm_mm_color_adjust() from Steven and Robin
>
> drivers/gpu/drm/panfrost/panfrost_drv.c | 30 -
> drivers/gpu/drm/panfrost/panfrost_gem.c | 18 +--
> drivers/gpu/drm/panfrost/panfrost_gem.h | 3 ++-
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 3 +++
> include/uapi/drm/panfrost_drm.h | 2 ++
> 5 files changed, 52 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index d354b92964d5..7ebd82d8d570 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -49,7 +49,8 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev,
> void *data,
> struct panfrost_gem_object *bo;
> struct drm_panfrost_create_bo *args = data;
>
> - if (!args->size || args->flags || args->pad)
> + if (!args->size || args->pad ||
> + (args->flags & ~PANFROST_BO_NOEXEC))
> return -EINVAL;
>
> bo = panfrost_gem_create_with_handle(file, dev, args->size, args->flags,
> @@ -367,6 +368,32 @@ static struct drm_driver panfrost_drm_driver = {
> .gem_prime_mmap = drm_gem_prime_mmap,
> };
>
> +#define PFN_4G (SZ_4G >> PAGE_SHIFT)
> +#define PFN_4G_MASK (PFN_4G - 1)
> +#define PFN_16M (SZ_16M >> PAGE_SHIFT)
> +
> +static void panfrost_drm_mm_color_adjust(const struct drm_mm_node *node,
> + unsigned long color,
> + u64 *start, u64 *end)
> +{
> + /* Executable buffers can't start or end on a 4GB boundary */
> + if (!(color & PANFROST_BO_NOEXEC)) {
> + u64 next_seg;
> +
> + if ((*start & PFN_4G_MASK) == 0)
> + (*start)++;
> +
> + if ((*end & PFN_4G_MASK) == 0)
> + (*end)--;
> +
> + next_seg = ALIGN(*start, PFN_4G);
> + if (next_seg - *start <= PFN_16M)
> + *start = next_seg + 1;
> +
> + *end = min(*end, ALIGN(*start, PFN_4G) - 1);
> + }
> +}
> +
> static int panfrost_probe(struct platform_device *pdev)
> {
> struct panfrost_device *pfdev;
> @@ -394,6 +421,7 @@ static int panfrost_probe(struct platform_device *pdev)
>
> /* 4G enough for now. can be 48-bit */
> drm_mm_init(>mm, SZ_32M >> PAGE_SHIFT, (SZ_4G - SZ_32M) >>
> PAGE_SHIFT);
> + pfdev->mm.color_adjust = panfrost_drm_mm_color_adjust;
>
> pm_runtime_use_autosuspend(pfdev->dev);
> pm_runtime_set_autosuspend_delay(pfdev->dev, 50); /* ~3 frames */
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c
> b/drivers/gpu/drm/panfrost/panfrost_gem.c
> index df70dcf3cb2f..63731f6c5223 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
> @@ -66,11 +66,23 @@ static int panfrost_gem_map(struct panfrost_device
> *pfdev, struct panfrost_gem_o
> {
> int ret;
> size_t size = bo->base.base.size;
> - u64 align = size >= SZ_2M ? SZ_2M >> PAGE_SHIFT : 0;
> + u64 align;
> + unsigned long color = bo->noexec ? PANFROST_BO_NOEXEC : 0;
> +
> + /*
> + * Executable buffers cannot cross a 16MB boundary as the program
> + * counter is 24-bits. We assume executable buffers will be less than
> + * 16MB and aligning executable buffers to their size will avoid
> + * crossing a 16MB boundary.
> + */
> + if (!bo->noexec)
> + align = size >> PAGE_SHIFT;
> + else
> + align = size >= SZ_2M ? SZ_2M >> PAGE_SHIFT : 0;
>
> spin_lock(>mm_lock);
> ret = drm_mm_insert_node_generic(>mm, >node,
> - size >> PAGE_SHIFT, align, 0, 0);
> + size >> PAGE_SHIFT, align, color, 0);
[PATCH] arm64: dts: fast models: Increase clcd's max-memory-bandwidth
It may be desirable on certain platforms, such as Android, to
use 32bpp buffers. Since there is no clear bandwidth limit for the
CLCD component on the fast model, let's increase
max-memory-bandwidth to allow using 32bpp buffers.
Reported-by: Ruben Ayrapetyan
Signed-off-by: Kevin Brodsky
---
arch/arm64/boot/dts/arm/fvp-base-revc.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
index 687707020ec1..3aee49ed6d88 100644
--- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
+++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
@@ -269,7 +269,7 @@
motherboard {
iofpga@3, {
clcd@1f {
- max-memory-bandwidth = <13000>; /*
16bpp @ 63.5MHz */
+ max-memory-bandwidth = <26000>; /*
32bpp @ 63.5MHz */
};
};
};
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/mxsfb: Read bus flags from bridge if present
The bridge might have special requirmentes on the input bus. This
is e.g. used by the imx-nwl bridge.
Signed-off-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index e84bac3a541d..3b8eb3ac13b6 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -215,7 +215,7 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
{
struct drm_device *drm = mxsfb->pipe.crtc.dev;
struct drm_display_mode *m = >pipe.crtc.state->adjusted_mode;
- const u32 bus_flags = mxsfb->connector->display_info.bus_flags;
+ u32 bus_flags = mxsfb->connector->display_info.bus_flags;
u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
int err;
@@ -239,6 +239,9 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
clk_set_rate(mxsfb->clk, m->crtc_clock * 1000);
+ if (mxsfb->bridge && mxsfb->bridge->timings)
+ bus_flags = mxsfb->bridge->timings->input_bus_flags;
+
DRM_DEV_DEBUG_DRIVER(drm->dev, "Pixel clock: %dkHz (actual: %dkHz)\n",
m->crtc_clock,
(int)(clk_get_rate(mxsfb->clk) / 1000));
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/1] drm/mxsfb: Read bus flags from bridge if present
The bridge might have special requirmentes on the input bus. This is e.g. used by the imx-nwl bridge. Robert, maybe you can add this patch to your 'Improvements and fixes for mxsfb DRM driver' since it depends on the first patch in this series anyway? Tested with 'Improvements and fixes for mxsfb DRM driver'[0] and 'drm: bridge: Add NWL MIPI DSI host controller support'[1] on next-20190725. [0]: https://patchwork.freedesktop.org/series/62822/ [1]: https://patchwork.freedesktop.org/series/64185/ Guido Günther (1): drm/mxsfb: Read bus flags from bridge if present drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] backlight: drop EARLY_EVENT_BLANK support
On Thu, Jul 25, 2019 at 04:32:24PM +0200, Sam Ravnborg wrote:
> There was no users left - so drop the code to support EARLY_FB_BLANK.
Why are we using a different noun for the subject and description?
> This patch removes the support in backlight,
> and drop the notifier in fbmem.
>
> That EARLY_FB_BLANK is not used can be verified that no driver set any of:
>
> lcd_ops.early_set_power()
> lcd_ops.r_early_set_power()
>
> Noticed while browsing backlight code for other reasons.
>
> Signed-off-by: Sam Ravnborg
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Maarten Lankhorst
> Cc: "Michał Mirosław"
> Cc: Peter Rosin
> Cc: Gerd Hoffmann
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
Other than the quibble about the description...
Acked-by: Daniel Thompson
> ---
>
> Build tested with various architectures, configs.
>
> Lee, Daniel - OK to commit to drm-misc-next where fbdev stuff is
> maintained today?
>
> Patch needs ack from Bartlomiej first of course.
>
> Sam
>
> drivers/video/backlight/lcd.c| 8
> drivers/video/fbdev/core/fbmem.c | 12 +---
> include/linux/fb.h | 4
> include/linux/lcd.h | 10 --
> 4 files changed, 1 insertion(+), 33 deletions(-)
>
> diff --git a/drivers/video/backlight/lcd.c b/drivers/video/backlight/lcd.c
> index d6b653aa4ee9..78b033358625 100644
> --- a/drivers/video/backlight/lcd.c
> +++ b/drivers/video/backlight/lcd.c
> @@ -39,14 +39,6 @@ static int fb_notifier_callback(struct notifier_block
> *self,
> if (event == FB_EVENT_BLANK) {
> if (ld->ops->set_power)
> ld->ops->set_power(ld, *(int *)evdata->data);
> - } else if (event == FB_EARLY_EVENT_BLANK) {
> - if (ld->ops->early_set_power)
> - ld->ops->early_set_power(ld,
> - *(int *)evdata->data);
> - } else if (event == FB_R_EARLY_EVENT_BLANK) {
> - if (ld->ops->r_early_set_power)
> - ld->ops->r_early_set_power(ld,
> - *(int *)evdata->data);
> } else {
> if (ld->ops->set_mode)
> ld->ops->set_mode(ld, evdata->data);
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 00fe0efeaee9..e6a1c805064f 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1058,7 +1058,7 @@ int
> fb_blank(struct fb_info *info, int blank)
> {
> struct fb_event event;
> - int ret = -EINVAL, early_ret;
> + int ret = -EINVAL;
>
> if (blank > FB_BLANK_POWERDOWN)
> blank = FB_BLANK_POWERDOWN;
> @@ -1066,21 +1066,11 @@ fb_blank(struct fb_info *info, int blank)
> event.info = info;
> event.data =
>
> - early_ret = fb_notifier_call_chain(FB_EARLY_EVENT_BLANK, );
> -
> if (info->fbops->fb_blank)
> ret = info->fbops->fb_blank(blank, info);
>
> if (!ret)
> fb_notifier_call_chain(FB_EVENT_BLANK, );
> - else {
> - /*
> - * if fb_blank is failed then revert effects of
> - * the early blank event.
> - */
> - if (!early_ret)
> - fb_notifier_call_chain(FB_R_EARLY_EVENT_BLANK, );
> - }
>
> return ret;
> }
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 50948e519897..756706b666a1 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -135,10 +135,6 @@ struct fb_cursor_user {
>
> /* A display blank is requested */
> #define FB_EVENT_BLANK 0x09
> -/* A hardware display blank early change occurred */
> -#define FB_EARLY_EVENT_BLANK 0x10
> -/* A hardware display blank revert early change occurred */
> -#define FB_R_EARLY_EVENT_BLANK 0x11
>
> struct fb_event {
> struct fb_info *info;
> diff --git a/include/linux/lcd.h b/include/linux/lcd.h
> index 851eee8fff25..238fb1dfed98 100644
> --- a/include/linux/lcd.h
> +++ b/include/linux/lcd.h
> @@ -41,16 +41,6 @@ struct lcd_ops {
> /* Get the LCD panel power status (0: full on, 1..3: controller
> power on, flat panel power off, 4: full off), see FB_BLANK_XXX */
> int (*get_power)(struct lcd_device *);
> - /*
> - * Enable or disable power to the LCD(0: on; 4: off, see FB_BLANK_XXX)
> - * and this callback would be called proir to fb driver's callback.
> - *
> - * P.S. note that if early_set_power is not NULL then early fb notifier
> - * would be registered.
> - */
> - int (*early_set_power)(struct lcd_device *, int power);
> - /* revert the effects of the
Re: [PATCH 3/3] drm/bridge: Add NWL MIPI DSI host controller support
Hi Guido.
Following some trivial comments.
As for the overall design I already commented on that in the binding.
(bridge versus display controller)
That it can work on top of mxsfb is a good indication that it is a
bridge but I just do not see the full picture.
In general the code looked clean and neat.
On Wed, Jul 24, 2019 at 05:52:26PM +0200, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found on
> i.MX8 SoCs.
>
> It adds support for the i.MX8MQ but the same IP can be found on
> e.g. the i.MX8QXP.
>
> It has been tested on the Librem 5 devkit using mxsfb.
Looking at mxsfb I wonder hw this was done, as there seems to be no
bridge support in mxsfb. Using a patched version of mxsfb?
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 4934fcf5a6f8..904a9eb3a20a 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -16,4 +16,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
> obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
> +obj-y += imx-nwl/
obj-$(ONFIG_DRM_IMX_NWL_DSI) += imx-nwl/?
So we do not visit the directory unless required.
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx-nwl/Makefile
> @@ -0,0 +1,2 @@
> +imx-nwl-objs := nwl-drv.o nwl-dsi.o
The preferred syntax is
imx-nwl-y := nwl-drv.o nwl-dsi.o
See for example Makefile for mxsfb.
Consider to introduce
header-test-y += nwl-drv.h nwl-dsi.h
So we at build time check that the headers are self-contained.
(they include what they need).
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "nwl-drv.h"
> +#include "nwl-dsi.h"
The most typical order of include files are:
#include
#include
#include
#include ""
With the empty lines in-between each block.
And sorted like is already done here.
This in general for all the files for this driver.
> +
> +static bool
> +imx_nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct imx_nwl_dsi *dsi = bridge_to_dsi(bridge);
> + struct device *dev = dsi->dev;
> + union phy_configure_opts new_cfg;
> + unsigned long phy_ref_rate;
> + int ret;
> +
> + ret = nwl_dsi_get_dphy_params(dsi, adjusted_mode, _cfg);
> + if (ret < 0)
> + return ret;
> +
> + /*
> + * If hs clock is unchanged, we're all good - all parameters are
> + * derived from it atm.
> + */
> + if (new_cfg.mipi_dphy.hs_clk_rate == dsi->phy_cfg.mipi_dphy.hs_clk_rate)
> + return true;
> +
> + phy_ref_rate = clk_get_rate(dsi->phy_ref_clk);
> + DRM_DEV_DEBUG_DRIVER(dev, "PHY at ref rate: %lu\n", phy_ref_rate);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dsi->dev,
> + "Cannot setup PHY for mode: %ux%u @%d Hz\n",
> + adjusted_mode->hdisplay, adjusted_mode->vdisplay,
> + adjusted_mode->clock);
> + DRM_DEV_ERROR(dsi->dev, "PHY ref clk: %lu, bit clk: %lu\n",
> + phy_ref_rate, new_cfg.mipi_dphy.hs_clk_rate);
> + } else {
> + /* Save the new desired phy config */
> + memcpy(>phy_cfg, _cfg, sizeof(new_cfg));
> + }
> +
> + /* LCDIF + NWL needs active high sync */
> + adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> + adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC);
> +
> + drm_display_mode_to_videomode(adjusted_mode, >vm);
Hmm, the videomode is just another representation of data already
included in display_mode.
And, as a personal itch, I consider videomode as something that belongs
in the old fb drivers, and not drm drivers. But that may be me only.
Sam
Re: [PATCH 2/3] drm/panel: jh057n00900: Move mipi_dsi_dcs_set_display_off to disable()
Hi Guido.
On Fri, Jul 26, 2019 at 11:21:42AM +0200, Guido Günther wrote:
> This makes it symmetric with the panel init happening in enable().
>
> Signed-off-by: Guido Günther
> ---
> drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> index c6b4bfd79fde..cc89831e30a6 100644
> --- a/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> +++ b/drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> @@ -158,19 +158,23 @@ static int jh057n_enable(struct drm_panel *panel)
> static int jh057n_disable(struct drm_panel *panel)
> {
> struct jh057n *ctx = panel_to_jh057n(panel);
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> + int ret;
> +
> + ret = backlight_disable(ctx->backlight);
> + if (ret < 0)
> + return ret;
We most likely do not want to skip mipi_dsi_dcs_set_display_off()
just because we fail to disable backlight.
Most other panels disable backlight without a check for the return
value.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: Demote panel timing not found error message
From: Thierry Reding
Failing to find a panel-timing node is not an error in all cases, so do
not output an error message in that case. Instead turn it into a debug
message and make the drivers that care about it output an error message
of their own.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/panel/panel-lvds.c | 4 +++-
drivers/video/fbdev/amba-clcd.c| 4 +++-
drivers/video/of_display_timing.c | 2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-lvds.c
b/drivers/gpu/drm/panel/panel-lvds.c
index 1ec57d0806a8..7fcb3527c788 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -147,8 +147,10 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
int ret;
ret = of_get_display_timing(np, "panel-timing", );
- if (ret < 0)
+ if (ret < 0) {
+ dev_err(lvds->dev, "%pOF: could not find panel timing\n", np);
return ret;
+ }
videomode_from_timing(, >video_mode);
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 89324e42a033..13df898a3481 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -561,8 +561,10 @@ static int clcdfb_of_get_dpi_panel_mode(struct device_node
*node,
struct videomode video;
err = of_get_display_timing(node, "panel-timing", );
- if (err)
+ if (err) {
+ pr_err("%pOF: could not find panel timing\n", node);
return err;
+ }
videomode_from_timing(, );
diff --git a/drivers/video/of_display_timing.c
b/drivers/video/of_display_timing.c
index f5c1c469c0af..9385b518349f 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -125,7 +125,7 @@ int of_get_display_timing(const struct device_node *np,
const char *name,
timing_np = of_get_child_by_name(np, name);
if (!timing_np) {
- pr_err("%pOF: could not find node '%s'\n", np, name);
+ pr_debug("%pOF: could not find node '%s'\n", np, name);
return -ENOENT;
}
--
2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111224] Wireless Network Deployment
https://bugs.freedesktop.org/show_bug.cgi?id=111224 Bug ID: 111224 Summary: Wireless Network Deployment Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: sushanthp2...@hotmail.com Forget expensive, full-time technicians. Whether it’s a new building or time for an upgrade, our teams of local Field Engineers can provide on-site survey and installation of your wireless network solution. Immediately after your company submits a Work Order in our platform, our dispatch team contacts a qualified, experienced Field Engineer in your community with the availability to complete your project. Our technicians have the field experience necessary to hit the ground running; securely installing, configuring and testing your wireless network connection to make sure everything you need is operating at peak performance. Once we verify with you that the project has been completed to your satisfaction, simply close out the Work Order and get back to business. Know more: https://www.fieldengineer.com/blogs/wireless-network-deployment -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111224] Wireless Network Deployment
https://bugs.freedesktop.org/show_bug.cgi?id=111224 sushanthpandiri changed: What|Removed |Added URL||https://www.fieldengineer.c ||om/blogs/wireless-network-d ||eployment -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/panel: jh057n00900: Move dsi init sequence to prepare
Hi Guido. On Fri, Jul 26, 2019 at 11:21:40AM +0200, Guido Günther wrote: > If the panel is wrapped in a panel_bridge it gets prepar()ed before the > upstream DSI bridge which can cause hangs (e.g. with imx-nwl since clocks > are not enabled yet). To avoid this move the panel's first DSI access to > enable() so the upstream bridge can prepare the DSI host controller in > it's pre_enable(). > > The second patch makes the disable() call symmetric to the above and the third > one just eases debugging. > > Guido Günther (3): > drm/panel: jh057n00900: Move panel DSI init to enable() > drm/panel: jh057n00900: Move mipi_dsi_dcs_set_display_off to disable() > drm/panel: jh057n00900: Print error code on all DRM_DEV_ERROR()s Patch 1 + 3 are both: Reviewed-by: Sam Ravnborg See comment on patch 2. While you are touching this driver can you make an extra patch? Today the driver calls the internal prepare,enable,disable,unprepare functions. The right way to do it is to use the drm_panel_(prepare,enable,disable,unprepare) variants. The benefit is that we can move a little logic to these functions and the drivers will then benefit from this. Two things I have in my local queue: - Move bool for prepared/enabled (to protect that we do not prepare/enable twice) - backlight support This driver will benefit form both and this little modification will make it simpler to introduce. I can also prepare the patch if you prefer. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init()
On Thu, 25 Jul 2019 at 14:44, Chanwoo Choi wrote:
>
> 2019년 7월 24일 (수) 오전 8:09, Artur Świgoń 님이 작성:
> >
> > This patch adds a new static function, exynos_bus_profile_init(), extracted
> > from exynos_bus_probe().
> >
> > Signed-off-by: Artur Świgoń
> > ---
> > drivers/devfreq/exynos-bus.c | 106 ---
> > 1 file changed, 60 insertions(+), 46 deletions(-)
> >
> > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > index d9f377912c10..d8f1efaf2d49 100644
> > --- a/drivers/devfreq/exynos-bus.c
> > +++ b/drivers/devfreq/exynos-bus.c
> > @@ -372,12 +372,69 @@ static int exynos_bus_parse_of(struct device_node *np,
> > return ret;
> > }
> >
> > +static int exynos_bus_profile_init(struct exynos_bus *bus,
> > + struct devfreq_dev_profile *profile)
> > +{
> > + struct device *dev = bus->dev;
> > + struct devfreq_simple_ondemand_data *ondemand_data;
> > + int ret;
> > +
> > + /* Initialize the struct profile and governor data for parent
> > device */
> > + profile->polling_ms = 50;
> > + profile->target = exynos_bus_target;
> > + profile->get_dev_status = exynos_bus_get_dev_status;
> > + profile->exit = exynos_bus_exit;
> > +
> > + ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data),
> > GFP_KERNEL);
> > + if (!ondemand_data) {
> > + ret = -ENOMEM;
> > + goto err;
> > + }
> > + ondemand_data->upthreshold = 40;
> > + ondemand_data->downdifferential = 5;
> > +
> > + /* Add devfreq device to monitor and handle the exynos bus */
> > + bus->devfreq = devm_devfreq_add_device(dev, profile,
> > + DEVFREQ_GOV_SIMPLE_ONDEMAND,
> > + ondemand_data);
> > + if (IS_ERR(bus->devfreq)) {
> > + dev_err(dev, "failed to add devfreq device\n");
> > + ret = PTR_ERR(bus->devfreq);
> > + goto err;
> > + }
> > +
> > + /* Register opp_notifier to catch the change of OPP */
> > + ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to register opp notifier\n");
> > + goto err;
> > + }
> > +
> > + /*
> > +* Enable devfreq-event to get raw data which is used to determine
> > +* current bus load.
> > +*/
> > + ret = exynos_bus_enable_edev(bus);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to enable devfreq-event devices\n");
> > + goto err;
> > + }
> > +
> > + ret = exynos_bus_set_event(bus);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to set event to devfreq-event
> > devices\n");
> > + goto err;
> > + }
> > +
> > +err:
> > + return ret;
> > +}
> > +
> > static int exynos_bus_probe(struct platform_device *pdev)
> > {
> > struct device *dev = >dev;
> > struct device_node *np = dev->of_node, *node;
> > struct devfreq_dev_profile *profile;
> > - struct devfreq_simple_ondemand_data *ondemand_data;
> > struct devfreq_passive_data *passive_data;
> > struct devfreq *parent_devfreq;
> > struct exynos_bus *bus;
> > @@ -418,52 +475,9 @@ static int exynos_bus_probe(struct platform_device
> > *pdev)
> > if (ret < 0)
> > goto err;
> >
> > - /* Initialize the struct profile and governor data for parent
> > device */
> > - profile->polling_ms = 50;
> > - profile->target = exynos_bus_target;
> > - profile->get_dev_status = exynos_bus_get_dev_status;
> > - profile->exit = exynos_bus_exit;
> > -
> > - ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data),
> > GFP_KERNEL);
> > - if (!ondemand_data) {
> > - ret = -ENOMEM;
> > + ret = exynos_bus_profile_init(bus, profile);
> > + if (ret < 0)
> > goto err;
> > - }
> > - ondemand_data->upthreshold = 40;
> > - ondemand_data->downdifferential = 5;
> > -
> > - /* Add devfreq device to monitor and handle the exynos bus */
> > - bus->devfreq = devm_devfreq_add_device(dev, profile,
> > - DEVFREQ_GOV_SIMPLE_ONDEMAND,
> > - ondemand_data);
> > - if (IS_ERR(bus->devfreq)) {
> > - dev_err(dev, "failed to add devfreq device\n");
> > - ret = PTR_ERR(bus->devfreq);
> > - goto err;
> > - }
> > -
> > - /* Register opp_notifier to catch the change of OPP */
> > - ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
> > - if (ret < 0) {
> > - dev_err(dev, "failed to register opp notifier\n");
> > - goto err;
> > - }
> > -
> > -
Re: [RFC PATCH 04/11] devfreq: exynos-bus: Clean up code
On 19. 7. 26. 오후 7:45, Krzysztof Kozlowski wrote:
> On Thu, 25 Jul 2019 at 14:51, Chanwoo Choi wrote:
>>
>> 2019년 7월 24일 (수) 오전 8:07, Artur Świgoń 님이 작성:
>>>
>>> This patch adds minor improvements to the exynos-bus driver.
>>>
>>> Signed-off-by: Artur Świgoń
>>> ---
>>> drivers/devfreq/exynos-bus.c | 49
>>> 1 file changed, 22 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 4bb83b945bf7..412511ca7703 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -15,11 +15,10 @@
>>> #include
>>> #include
>>> #include
>>> -#include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> -#include
>>>
>>> #define DEFAULT_SATURATION_RATIO 40
>>> #define DEFAULT_VOLTAGE_TOLERANCE 2
>>> @@ -256,7 +255,7 @@ static int exynos_bus_parent_parse_of(struct
>>> device_node *np,
>>> struct exynos_bus *bus)
>>> {
>>> struct device *dev = bus->dev;
>>> - int i, ret, count, size;
>>> + int i, ret, count;
>>>
>>> /* Get the regulator to provide each bus with the power */
>>> bus->regulator = devm_regulator_get(dev, "vdd");
>>> @@ -283,8 +282,7 @@ static int exynos_bus_parent_parse_of(struct
>>> device_node *np,
>>> }
>>> bus->edev_count = count;
>>>
>>> - size = sizeof(*bus->edev) * count;
>>> - bus->edev = devm_kzalloc(dev, size, GFP_KERNEL);
>>> + bus->edev = devm_kcalloc(dev, count, sizeof(*bus->edev),
>>> GFP_KERNEL);
>>> if (!bus->edev) {
>>> ret = -ENOMEM;
>>> goto err_regulator;
>>> @@ -388,7 +386,7 @@ static int exynos_bus_profile_init(struct exynos_bus
>>> *bus,
>>> ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data),
>>> GFP_KERNEL);
>>> if (!ondemand_data) {
>>> ret = -ENOMEM;
>>> - goto err;
>>> + goto out;
>>> }
>>> ondemand_data->upthreshold = 40;
>>> ondemand_data->downdifferential = 5;
>>> @@ -400,14 +398,14 @@ static int exynos_bus_profile_init(struct exynos_bus
>>> *bus,
>>> if (IS_ERR(bus->devfreq)) {
>>> dev_err(dev, "failed to add devfreq device\n");
>>> ret = PTR_ERR(bus->devfreq);
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> /* Register opp_notifier to catch the change of OPP */
>>> ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
>>> if (ret < 0) {
>>> dev_err(dev, "failed to register opp notifier\n");
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> /*
>>> @@ -417,16 +415,16 @@ static int exynos_bus_profile_init(struct exynos_bus
>>> *bus,
>>> ret = exynos_bus_enable_edev(bus);
>>> if (ret < 0) {
>>> dev_err(dev, "failed to enable devfreq-event devices\n");
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> ret = exynos_bus_set_event(bus);
>>> if (ret < 0) {
>>> dev_err(dev, "failed to set event to devfreq-event
>>> devices\n");
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> -err:
>>> +out:
>>> return ret;
>>> }
>>>
>>> @@ -446,27 +444,28 @@ static int exynos_bus_profile_init_passive(struct
>>> exynos_bus *bus,
>>> parent_devfreq = devfreq_get_devfreq_by_phandle(dev, 0);
>>> if (IS_ERR(parent_devfreq)) {
>>> ret = -EPROBE_DEFER;
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> passive_data = devm_kzalloc(dev, sizeof(*passive_data), GFP_KERNEL);
>>> if (!passive_data) {
>>> ret = -ENOMEM;
>>> - goto err;
>>> + goto out;
>>> }
>>> passive_data->parent = parent_devfreq;
>>>
>>> /* Add devfreq device for exynos bus with passive governor */
>>> - bus->devfreq = devm_devfreq_add_device(dev, profile,
>>> DEVFREQ_GOV_PASSIVE,
>>> + bus->devfreq = devm_devfreq_add_device(dev, profile,
>>> + DEVFREQ_GOV_PASSIVE,
>>> passive_data);
>>> if (IS_ERR(bus->devfreq)) {
>>> dev_err(dev,
>>> "failed to add devfreq dev with passive
>>> governor\n");
>>> ret = PTR_ERR(bus->devfreq);
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> -err:
>>> +out:
>>> return ret;
>>> }
>>>
>>> @@ -484,11 +483,11 @@ static int exynos_bus_probe(struct platform_device
>>> *pdev)
>>> return -EINVAL;
>>> }
>>>
>>> - bus = devm_kzalloc(>dev, sizeof(*bus), GFP_KERNEL);
>>> + bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
>>>
Re: [PATCH 1/1] drm/mxsfb: Read bus flags from bridge if present
On 2019-07-26 11:49, Guido Günther wrote:
> The bridge might have special requirmentes on the input bus. This
> is e.g. used by the imx-nwl bridge.
>
> Signed-off-by: Guido Günther
Looks good to me.
Reviewed-by: Stefan Agner
That is similar to what I sent for the imx DRM driver:
https://lkml.org/lkml/2018/9/12/913
I probably should follow up on that patchset.
--
Stefan
> ---
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index e84bac3a541d..3b8eb3ac13b6 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -215,7 +215,7 @@ static void mxsfb_crtc_mode_set_nofb(struct
> mxsfb_drm_private *mxsfb)
> {
> struct drm_device *drm = mxsfb->pipe.crtc.dev;
> struct drm_display_mode *m = >pipe.crtc.state->adjusted_mode;
> - const u32 bus_flags = mxsfb->connector->display_info.bus_flags;
> + u32 bus_flags = mxsfb->connector->display_info.bus_flags;
> u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
> int err;
>
> @@ -239,6 +239,9 @@ static void mxsfb_crtc_mode_set_nofb(struct
> mxsfb_drm_private *mxsfb)
>
> clk_set_rate(mxsfb->clk, m->crtc_clock * 1000);
>
> + if (mxsfb->bridge && mxsfb->bridge->timings)
> + bus_flags = mxsfb->bridge->timings->input_bus_flags;
> +
> DRM_DEV_DEBUG_DRIVER(drm->dev, "Pixel clock: %dkHz (actual: %dkHz)\n",
>m->crtc_clock,
>(int)(clk_get_rate(mxsfb->clk) / 1000));
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] dt-bindings: display/bridge: Add binding for IMX NWL mipi dsi host controller
Hi Sam,
thanks for your comments!
On Fri, Jul 26, 2019 at 11:23:15AM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> A few comments follows.
>
> Sam
>
> On Wed, Jul 24, 2019 at 05:52:25PM +0200, Guido Günther wrote:
> > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
> >
> > Signed-off-by: Guido Günther
> > ---
> > .../bindings/display/bridge/imx-nwl-dsi.txt | 89 +++
>
> New binding. Any chance we can get this in yaml format?
> This is the way forward and we have to convert the file anyway.
>
> None of the other bridges use yaml format, but someone has to be the
> first.
I'm fine with converting this (i also forgot to squash a missing unit
name and a typo fix in the bindings, will add this for v2).
>
> > 1 file changed, 89 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> > b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> > new file mode 100644
> > index ..288fdb726d5a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> > @@ -0,0 +1,89 @@
> > +Northwest Logic MIPI-DSI on imx SoCs
> > +=
> > +
> > +NWL MIPI-DSI host controller found on i.MX8 platforms. This is a
> > +dsi bridge for the for the NWL MIPI-DSI host.
>
> To my best understanding a bridge is something that converts from one
> format to another format.
> Something that in the drm world are connected to an encoder.
>
> I do not know the HW here - but from this very brif description this
> sounds more like a display controller and not a bridge?
mxsfb can drive LCD displays directly and - on newer SoCs like the i.MX8
- also feed the nwl dsi host controller. So having that as a bridge is
hopefully the right thing to do.
In order for that to work on the hardware i tested on, we'd need:
- at least the first patch from
https://patchwork.freedesktop.org/series/62822/ for bridge support
- https://patchwork.freedesktop.org/series/64300/ to get the bus flags
- https://patchwork.freedesktop.org/series/64292/ to be able to use
panel_bridge in this driver
I only had a reference to the first point above in the cover letter.
I'll add the other ones for v2 now that these are sent out. I'll also
address your comments in other parts of this series.
Cheers and thanks for having look!
-- Guido
>
>
> > +
> > +Required properties:
> > +- compatible: "fsl,-nwl-dsi"
> > + The following strings are expected:
> > + "fsl,imx8mq-nwl-dsi"
> > +- reg: the register range of the MIPI-DSI controller
> > +- interrupts: the interrupt number for this module
> > +- clock, clock-names: phandles to the MIPI-DSI clocks
> > + The following clocks are expected on all platforms:
> > + "core"- DSI core clock
> > + "tx_esc" - TX_ESC clock (used in escape mode)
> > + "rx_esc" - RX_ESC clock (used in escape mode)
> > + "phy_ref" - PHY_REF clock. Clock is managed by the phy. Only
> > +used to read the clock rate.
> > +- assigned-clocks: phandles to clocks that require initial configuration
> > +- assigned-clock-rates:rates of the clocks that require initial
> > configuration
> > + The following clocks need to have an initial configuration:
> > + "tx_esc" (20 MHz) and "rx_esc" (80 Mhz).
> > +- phys:phandle to the phy module representing the DPHY
> > + inside the MIPI-DSI IP block
> > +- phy-names: should be "dphy"
> > +
> > +Optional properties:
> > +- power-domainsphandle to the power domain
> > +- src phandle to the system reset controller
> > (required on
> > + i.MX8MQ)
> Name is not very descriptive.
> Other bindings seems to use "resets" here?
>
> > +- mux-sel phandle to the MUX register set (required on i.MX8MQ)
> > +- assigned-clock-parents phandles to parent clocks that needs to be
> > assigned as
> > + parents to clocks defined in assigned-clocks
> > +
> > +Example:
> > + mipi_dsi: mipi_dsi@30a0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fsl,imx8mq-nwl-dsi";
> > + reg = <0x30A0 0x300>;
> > + clocks = < IMX8MQ_CLK_DSI_CORE>,
> > +< IMX8MQ_CLK_DSI_AHB>,
> > +< IMX8MQ_CLK_DSI_IPG_DIV>,
> > +< IMX8MQ_CLK_DSI_PHY_REF>;
> > + clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
> > + assigned-clocks = < IMX8MQ_CLK_DSI_AHB>,
> > + < IMX8MQ_CLK_DSI_CORE>,
> > + < IMX8MQ_CLK_DSI_IPG_DIV>;
> > + assigned-clock-parents = < IMX8MQ_SYS1_PLL_80M>,
> > +
Re: [RFC PATCH 04/11] devfreq: exynos-bus: Clean up code
On Thu, 25 Jul 2019 at 14:51, Chanwoo Choi wrote:
>
> 2019년 7월 24일 (수) 오전 8:07, Artur Świgoń 님이 작성:
> >
> > This patch adds minor improvements to the exynos-bus driver.
> >
> > Signed-off-by: Artur Świgoń
> > ---
> > drivers/devfreq/exynos-bus.c | 49
> > 1 file changed, 22 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > index 4bb83b945bf7..412511ca7703 100644
> > --- a/drivers/devfreq/exynos-bus.c
> > +++ b/drivers/devfreq/exynos-bus.c
> > @@ -15,11 +15,10 @@
> > #include
> > #include
> > #include
> > -#include
> > +#include
> > #include
> > #include
> > #include
> > -#include
> >
> > #define DEFAULT_SATURATION_RATIO 40
> > #define DEFAULT_VOLTAGE_TOLERANCE 2
> > @@ -256,7 +255,7 @@ static int exynos_bus_parent_parse_of(struct
> > device_node *np,
> > struct exynos_bus *bus)
> > {
> > struct device *dev = bus->dev;
> > - int i, ret, count, size;
> > + int i, ret, count;
> >
> > /* Get the regulator to provide each bus with the power */
> > bus->regulator = devm_regulator_get(dev, "vdd");
> > @@ -283,8 +282,7 @@ static int exynos_bus_parent_parse_of(struct
> > device_node *np,
> > }
> > bus->edev_count = count;
> >
> > - size = sizeof(*bus->edev) * count;
> > - bus->edev = devm_kzalloc(dev, size, GFP_KERNEL);
> > + bus->edev = devm_kcalloc(dev, count, sizeof(*bus->edev),
> > GFP_KERNEL);
> > if (!bus->edev) {
> > ret = -ENOMEM;
> > goto err_regulator;
> > @@ -388,7 +386,7 @@ static int exynos_bus_profile_init(struct exynos_bus
> > *bus,
> > ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data),
> > GFP_KERNEL);
> > if (!ondemand_data) {
> > ret = -ENOMEM;
> > - goto err;
> > + goto out;
> > }
> > ondemand_data->upthreshold = 40;
> > ondemand_data->downdifferential = 5;
> > @@ -400,14 +398,14 @@ static int exynos_bus_profile_init(struct exynos_bus
> > *bus,
> > if (IS_ERR(bus->devfreq)) {
> > dev_err(dev, "failed to add devfreq device\n");
> > ret = PTR_ERR(bus->devfreq);
> > - goto err;
> > + goto out;
> > }
> >
> > /* Register opp_notifier to catch the change of OPP */
> > ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
> > if (ret < 0) {
> > dev_err(dev, "failed to register opp notifier\n");
> > - goto err;
> > + goto out;
> > }
> >
> > /*
> > @@ -417,16 +415,16 @@ static int exynos_bus_profile_init(struct exynos_bus
> > *bus,
> > ret = exynos_bus_enable_edev(bus);
> > if (ret < 0) {
> > dev_err(dev, "failed to enable devfreq-event devices\n");
> > - goto err;
> > + goto out;
> > }
> >
> > ret = exynos_bus_set_event(bus);
> > if (ret < 0) {
> > dev_err(dev, "failed to set event to devfreq-event
> > devices\n");
> > - goto err;
> > + goto out;
> > }
> >
> > -err:
> > +out:
> > return ret;
> > }
> >
> > @@ -446,27 +444,28 @@ static int exynos_bus_profile_init_passive(struct
> > exynos_bus *bus,
> > parent_devfreq = devfreq_get_devfreq_by_phandle(dev, 0);
> > if (IS_ERR(parent_devfreq)) {
> > ret = -EPROBE_DEFER;
> > - goto err;
> > + goto out;
> > }
> >
> > passive_data = devm_kzalloc(dev, sizeof(*passive_data), GFP_KERNEL);
> > if (!passive_data) {
> > ret = -ENOMEM;
> > - goto err;
> > + goto out;
> > }
> > passive_data->parent = parent_devfreq;
> >
> > /* Add devfreq device for exynos bus with passive governor */
> > - bus->devfreq = devm_devfreq_add_device(dev, profile,
> > DEVFREQ_GOV_PASSIVE,
> > + bus->devfreq = devm_devfreq_add_device(dev, profile,
> > + DEVFREQ_GOV_PASSIVE,
> > passive_data);
> > if (IS_ERR(bus->devfreq)) {
> > dev_err(dev,
> > "failed to add devfreq dev with passive
> > governor\n");
> > ret = PTR_ERR(bus->devfreq);
> > - goto err;
> > + goto out;
> > }
> >
> > -err:
> > +out:
> > return ret;
> > }
> >
> > @@ -484,11 +483,11 @@ static int exynos_bus_probe(struct platform_device
> > *pdev)
> > return -EINVAL;
> > }
> >
> > - bus = devm_kzalloc(>dev, sizeof(*bus), GFP_KERNEL);
> > + bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
> > if (!bus)
> > return -ENOMEM;
> >
Re: [RFC PATCH 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init()
On 19. 7. 26. 오후 7:42, Krzysztof Kozlowski wrote:
> On Thu, 25 Jul 2019 at 14:44, Chanwoo Choi wrote:
>>
>> 2019년 7월 24일 (수) 오전 8:09, Artur Świgoń 님이 작성:
>>>
>>> This patch adds a new static function, exynos_bus_profile_init(), extracted
>>> from exynos_bus_probe().
>>>
>>> Signed-off-by: Artur Świgoń
>>> ---
>>> drivers/devfreq/exynos-bus.c | 106 ---
>>> 1 file changed, 60 insertions(+), 46 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index d9f377912c10..d8f1efaf2d49 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -372,12 +372,69 @@ static int exynos_bus_parse_of(struct device_node *np,
>>> return ret;
>>> }
>>>
>>> +static int exynos_bus_profile_init(struct exynos_bus *bus,
>>> + struct devfreq_dev_profile *profile)
>>> +{
>>> + struct device *dev = bus->dev;
>>> + struct devfreq_simple_ondemand_data *ondemand_data;
>>> + int ret;
>>> +
>>> + /* Initialize the struct profile and governor data for parent
>>> device */
>>> + profile->polling_ms = 50;
>>> + profile->target = exynos_bus_target;
>>> + profile->get_dev_status = exynos_bus_get_dev_status;
>>> + profile->exit = exynos_bus_exit;
>>> +
>>> + ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data),
>>> GFP_KERNEL);
>>> + if (!ondemand_data) {
>>> + ret = -ENOMEM;
>>> + goto err;
>>> + }
>>> + ondemand_data->upthreshold = 40;
>>> + ondemand_data->downdifferential = 5;
>>> +
>>> + /* Add devfreq device to monitor and handle the exynos bus */
>>> + bus->devfreq = devm_devfreq_add_device(dev, profile,
>>> + DEVFREQ_GOV_SIMPLE_ONDEMAND,
>>> + ondemand_data);
>>> + if (IS_ERR(bus->devfreq)) {
>>> + dev_err(dev, "failed to add devfreq device\n");
>>> + ret = PTR_ERR(bus->devfreq);
>>> + goto err;
>>> + }
>>> +
>>> + /* Register opp_notifier to catch the change of OPP */
>>> + ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to register opp notifier\n");
>>> + goto err;
>>> + }
>>> +
>>> + /*
>>> +* Enable devfreq-event to get raw data which is used to determine
>>> +* current bus load.
>>> +*/
>>> + ret = exynos_bus_enable_edev(bus);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to enable devfreq-event devices\n");
>>> + goto err;
>>> + }
>>> +
>>> + ret = exynos_bus_set_event(bus);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to set event to devfreq-event
>>> devices\n");
>>> + goto err;
>>> + }
>>> +
>>> +err:
>>> + return ret;
>>> +}
>>> +
>>> static int exynos_bus_probe(struct platform_device *pdev)
>>> {
>>> struct device *dev = >dev;
>>> struct device_node *np = dev->of_node, *node;
>>> struct devfreq_dev_profile *profile;
>>> - struct devfreq_simple_ondemand_data *ondemand_data;
>>> struct devfreq_passive_data *passive_data;
>>> struct devfreq *parent_devfreq;
>>> struct exynos_bus *bus;
>>> @@ -418,52 +475,9 @@ static int exynos_bus_probe(struct platform_device
>>> *pdev)
>>> if (ret < 0)
>>> goto err;
>>>
>>> - /* Initialize the struct profile and governor data for parent
>>> device */
>>> - profile->polling_ms = 50;
>>> - profile->target = exynos_bus_target;
>>> - profile->get_dev_status = exynos_bus_get_dev_status;
>>> - profile->exit = exynos_bus_exit;
>>> -
>>> - ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data),
>>> GFP_KERNEL);
>>> - if (!ondemand_data) {
>>> - ret = -ENOMEM;
>>> + ret = exynos_bus_profile_init(bus, profile);
>>> + if (ret < 0)
>>> goto err;
>>> - }
>>> - ondemand_data->upthreshold = 40;
>>> - ondemand_data->downdifferential = 5;
>>> -
>>> - /* Add devfreq device to monitor and handle the exynos bus */
>>> - bus->devfreq = devm_devfreq_add_device(dev, profile,
>>> - DEVFREQ_GOV_SIMPLE_ONDEMAND,
>>> - ondemand_data);
>>> - if (IS_ERR(bus->devfreq)) {
>>> - dev_err(dev, "failed to add devfreq device\n");
>>> - ret = PTR_ERR(bus->devfreq);
>>> - goto err;
>>> - }
>>> -
>>> - /* Register opp_notifier to catch the change of OPP */
>>> - ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
>>> - if (ret < 0) {
>>> - dev_err(dev, "failed to register opp notifier\n");
>>>
Re: [PATCH v1 1/1] backlight: drop EARLY_EVENT_BLANK support
Hi Daniel. On Fri, Jul 26, 2019 at 10:50:16AM +0100, Daniel Thompson wrote: > On Thu, Jul 25, 2019 at 04:32:24PM +0200, Sam Ravnborg wrote: > > There was no users left - so drop the code to support EARLY_FB_BLANK. > > Why are we using a different noun for the subject and description? I fat-fingered the description. Will fix when I apply - or send out a v2 if requested. ... > > > > Signed-off-by: Sam Ravnborg > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > Cc: Bartlomiej Zolnierkiewicz > > Cc: Daniel Vetter > > Cc: Sam Ravnborg > > Cc: Maarten Lankhorst > > Cc: "Michał Mirosław" > > Cc: Peter Rosin > > Cc: Gerd Hoffmann > > Cc: dri-devel@lists.freedesktop.org > > Cc: linux-fb...@vger.kernel.org > > Other than the quibble about the description... > > Acked-by: Daniel Thompson Thanks, Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: sun4i: tcon: Mark expected switch fall-through
When fall-through warnings was enabled by default the following warning
was starting to show up:
../drivers/gpu/drm/sun4i/sun4i_tcon.c: In function
‘sun4i_tcon0_mode_set_dithering’:
../drivers/gpu/drm/sun4i/sun4i_tcon.c:316:7: warning: this statement may fall
through [-Wimplicit-fallthrough=]
val |= SUN4I_TCON0_FRM_CTL_MODE_B;
../drivers/gpu/drm/sun4i/sun4i_tcon.c:317:2: note: here
case MEDIA_BUS_FMT_RGB666_1X18:
^~~~
Rework so that the compiler doesn't warn about fall-through.
Fixes: d93512ef0f0e ("Makefile: Globally enable fall-through warning")
Signed-off-by: Anders Roxell
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 690aeb822704..04c721d0d3b9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -316,6 +316,7 @@ static void sun4i_tcon0_mode_set_dithering(struct
sun4i_tcon *tcon,
/* R and B components are only 5 bits deep */
val |= SUN4I_TCON0_FRM_CTL_MODE_R;
val |= SUN4I_TCON0_FRM_CTL_MODE_B;
+ /* Fall through */
case MEDIA_BUS_FMT_RGB666_1X18:
case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
/* Fall through: enable dithering */
--
2.20.1
[PATCH] video: fbdev: Mark expected switch fall-through
When fall-through warnings was enabled by default the following warnings
was starting to show up:
../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function
‘sh_mobile_lcdc_channel_fb_init’:
../drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may
fall
through [-Wimplicit-fallthrough=]
info->fix.ypanstep = 2;
~~~^~~
../drivers/video/fbdev/sh_mobile_lcdcfb.c:2087:2: note: here
case V4L2_PIX_FMT_NV16:
^~~~
../drivers/video/fbdev/sh_mobile_lcdcfb.c: In function
‘sh_mobile_lcdc_overlay_fb_init’:
../drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may
fall
through [-Wimplicit-fallthrough=]
info->fix.ypanstep = 2;
~~~^~~
../drivers/video/fbdev/sh_mobile_lcdcfb.c:1597:2: note: here
case V4L2_PIX_FMT_NV16:
^~~~
Rework so that the compiler doesn't warn about fall-through.
Fixes: d93512ef0f0e ("Makefile: Globally enable fall-through warning")
Signed-off-by: Anders Roxell
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index ac0bcac9a865..c249763dbf0b 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -1594,6 +1594,7 @@ sh_mobile_lcdc_overlay_fb_init(struct
sh_mobile_lcdc_overlay *ovl)
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_NV21:
info->fix.ypanstep = 2;
+ /* Fall through */
case V4L2_PIX_FMT_NV16:
case V4L2_PIX_FMT_NV61:
info->fix.xpanstep = 2;
@@ -2084,6 +2085,7 @@ sh_mobile_lcdc_channel_fb_init(struct sh_mobile_lcdc_chan
*ch,
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_NV21:
info->fix.ypanstep = 2;
+ /* Fall through */
case V4L2_PIX_FMT_NV16:
case V4L2_PIX_FMT_NV61:
info->fix.xpanstep = 2;
--
2.20.1
[PATCH 1/2] drm: sun4i: sun6i_mipi_dsi: Mark expected switch fall-through
When fall-through warnings was enabled by default the following warning
was starting to show up:
../drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function
‘sun6i_dsi_transfer’:../drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:992:6: warning:
this statement may fall through [-Wimplicit-fallthrough=]
if (msg->rx_len == 1) {
^
../drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:997:2: note: here
default:
^~~
Rework so that the compiler doesn't warn about fall-through. Change
the if-statement so that we can move out 'break;' one level.
Fixes: d93512ef0f0e ("Makefile: Globally enable fall-through warning")
Signed-off-by: Anders Roxell
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 472f73985deb..40ed21e527f9 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -992,8 +992,10 @@ static ssize_t sun6i_dsi_transfer(struct mipi_dsi_host
*host,
case MIPI_DSI_DCS_READ:
if (msg->rx_len == 1) {
ret = sun6i_dsi_dcs_read(dsi, msg);
- break;
+ } else {
+ ret = -EINVAL;
}
+ break;
default:
ret = -EINVAL;
--
2.20.1
[PATCH v2 10/10] docs: remove extra conf.py files
Now that the latex_documents are handled automatically, we can
remove those extra conf.py files.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/admin-guide/conf.py | 10 --
Documentation/core-api/conf.py | 10 --
Documentation/crypto/conf.py | 10 --
Documentation/dev-tools/conf.py| 10 --
Documentation/doc-guide/conf.py| 10 --
Documentation/driver-api/80211/conf.py | 10 --
Documentation/driver-api/conf.py | 10 --
Documentation/driver-api/pm/conf.py| 10 --
Documentation/filesystems/conf.py | 10 --
Documentation/gpu/conf.py | 10 --
Documentation/input/conf.py| 10 --
Documentation/kernel-hacking/conf.py | 10 --
Documentation/maintainer/conf.py | 10 --
Documentation/media/conf.py| 12
Documentation/networking/conf.py | 10 --
Documentation/process/conf.py | 10 --
Documentation/sh/conf.py | 10 --
Documentation/sound/conf.py| 10 --
Documentation/userspace-api/conf.py| 10 --
Documentation/vm/conf.py | 10 --
Documentation/x86/conf.py | 10 --
21 files changed, 212 deletions(-)
delete mode 100644 Documentation/admin-guide/conf.py
delete mode 100644 Documentation/core-api/conf.py
delete mode 100644 Documentation/crypto/conf.py
delete mode 100644 Documentation/dev-tools/conf.py
delete mode 100644 Documentation/doc-guide/conf.py
delete mode 100644 Documentation/driver-api/80211/conf.py
delete mode 100644 Documentation/driver-api/conf.py
delete mode 100644 Documentation/driver-api/pm/conf.py
delete mode 100644 Documentation/filesystems/conf.py
delete mode 100644 Documentation/gpu/conf.py
delete mode 100644 Documentation/input/conf.py
delete mode 100644 Documentation/kernel-hacking/conf.py
delete mode 100644 Documentation/maintainer/conf.py
delete mode 100644 Documentation/media/conf.py
delete mode 100644 Documentation/networking/conf.py
delete mode 100644 Documentation/process/conf.py
delete mode 100644 Documentation/sh/conf.py
delete mode 100644 Documentation/sound/conf.py
delete mode 100644 Documentation/userspace-api/conf.py
delete mode 100644 Documentation/vm/conf.py
delete mode 100644 Documentation/x86/conf.py
diff --git a/Documentation/admin-guide/conf.py
b/Documentation/admin-guide/conf.py
deleted file mode 100644
index 86f738953799..
--- a/Documentation/admin-guide/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel User Documentation'
-
-tags.add("subproject")
-
-latex_documents = [
-('index', 'linux-user.tex', 'Linux Kernel User Documentation',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/core-api/conf.py b/Documentation/core-api/conf.py
deleted file mode 100644
index db1f7659f3da..
--- a/Documentation/core-api/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Core-API Documentation"
-
-tags.add("subproject")
-
-latex_documents = [
-('index', 'core-api.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/crypto/conf.py b/Documentation/crypto/conf.py
deleted file mode 100644
index 4335d251ddf3..
--- a/Documentation/crypto/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Crypto API'
-
-tags.add("subproject")
-
-latex_documents = [
-('index', 'crypto-api.tex', 'Linux Kernel Crypto API manual',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/dev-tools/conf.py b/Documentation/dev-tools/conf.py
deleted file mode 100644
index 7faafa3f7888..
--- a/Documentation/dev-tools/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Development tools for the kernel"
-
-tags.add("subproject")
-
-latex_documents = [
-('index', 'dev-tools.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/doc-guide/conf.py b/Documentation/doc-guide/conf.py
deleted file mode 100644
index fd3731182d5a..
--- a/Documentation/doc-guide/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = 'Linux Kernel Documentation Guide'
-
-tags.add("subproject")
-
-latex_documents = [
-('index', 'kernel-doc-guide.tex', 'Linux Kernel Documentation Guide',
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/driver-api/80211/conf.py
b/Documentation/driver-api/80211/conf.py
deleted file mode 100644
index 4424b4b0b9c3..
--- a/Documentation/driver-api/80211/conf.py
+++ /dev/null
@@ -1,10 +0,0 @@
-# -*- coding: utf-8; mode: python -*-
-
-project = "Linux 802.11 Driver Developer's
Re: [PATCH 04/11] ASoC: jz4740: Drop lb60 board code
On Thu, Jul 25, 2019 at 06:02:08PM -0400, Paul Cercueil wrote: > The board now uses the simple-audio-card driver. > > Signed-off-by: Paul Cercueil > Tested-by: Artur Rojek Acked-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: Demote panel timing not found error message
Hi Thierry.
On Fri, Jul 26, 2019 at 12:18:49PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Failing to find a panel-timing node is not an error in all cases, so do
> not output an error message in that case. Instead turn it into a debug
> message and make the drivers that care about it output an error message
> of their own.
This is more or less the same as already implmented by Douglas here:
https://patchwork.kernel.org/cover/11053243/
Doug's has an extra bug-fix that we shall not miss.
I am waiting for feedback from Bartlomiej before proceeding.
I guess he is on holiday somewhere and will return soon.
Sam
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/panel/panel-lvds.c | 4 +++-
> drivers/video/fbdev/amba-clcd.c| 4 +++-
> drivers/video/of_display_timing.c | 2 +-
> 3 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-lvds.c
> b/drivers/gpu/drm/panel/panel-lvds.c
> index 1ec57d0806a8..7fcb3527c788 100644
> --- a/drivers/gpu/drm/panel/panel-lvds.c
> +++ b/drivers/gpu/drm/panel/panel-lvds.c
> @@ -147,8 +147,10 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
> int ret;
>
> ret = of_get_display_timing(np, "panel-timing", );
> - if (ret < 0)
> + if (ret < 0) {
> + dev_err(lvds->dev, "%pOF: could not find panel timing\n", np);
> return ret;
> + }
>
> videomode_from_timing(, >video_mode);
>
> diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
> index 89324e42a033..13df898a3481 100644
> --- a/drivers/video/fbdev/amba-clcd.c
> +++ b/drivers/video/fbdev/amba-clcd.c
> @@ -561,8 +561,10 @@ static int clcdfb_of_get_dpi_panel_mode(struct
> device_node *node,
> struct videomode video;
>
> err = of_get_display_timing(node, "panel-timing", );
> - if (err)
> + if (err) {
> + pr_err("%pOF: could not find panel timing\n", node);
> return err;
> + }
>
> videomode_from_timing(, );
>
> diff --git a/drivers/video/of_display_timing.c
> b/drivers/video/of_display_timing.c
> index f5c1c469c0af..9385b518349f 100644
> --- a/drivers/video/of_display_timing.c
> +++ b/drivers/video/of_display_timing.c
> @@ -125,7 +125,7 @@ int of_get_display_timing(const struct device_node *np,
> const char *name,
>
> timing_np = of_get_child_by_name(np, name);
> if (!timing_np) {
> - pr_err("%pOF: could not find node '%s'\n", np, name);
> + pr_debug("%pOF: could not find node '%s'\n", np, name);
> return -ENOENT;
> }
>
> --
> 2.22.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 1/7] docs: fix broken doc references due to renames
Some files got renamed but probably due to some merge conflicts,
a few references still point to the old locations.
Signed-off-by: Mauro Carvalho Chehab
Acked-by: Wolfram Sang # I2C part
Reviewed-by: Jerry Hoemann # hpwdt.rst
---
Documentation/RCU/rculist_nulls.txt | 2 +-
Documentation/devicetree/bindings/arm/idle-states.txt | 2 +-
Documentation/locking/spinlocks.rst | 4 ++--
Documentation/memory-barriers.txt | 2 +-
Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
Documentation/watchdog/hpwdt.rst | 2 +-
MAINTAINERS | 10 +-
drivers/gpu/drm/drm_modes.c | 2 +-
drivers/i2c/busses/i2c-nvidia-gpu.c | 2 +-
drivers/scsi/hpsa.c | 4 ++--
10 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/Documentation/RCU/rculist_nulls.txt
b/Documentation/RCU/rculist_nulls.txt
index 8151f0195f76..23f115dc87cf 100644
--- a/Documentation/RCU/rculist_nulls.txt
+++ b/Documentation/RCU/rculist_nulls.txt
@@ -1,7 +1,7 @@
Using hlist_nulls to protect read-mostly linked lists and
objects using SLAB_TYPESAFE_BY_RCU allocations.
-Please read the basics in Documentation/RCU/listRCU.txt
+Please read the basics in Documentation/RCU/listRCU.rst
Using special makers (called 'nulls') is a convenient way
to solve following problem :
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt
b/Documentation/devicetree/bindings/arm/idle-states.txt
index 326f29b270ad..2d325bed37e5 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -703,4 +703,4 @@ cpus {
https://www.devicetree.org/specifications/
[6] ARM Linux Kernel documentation - Booting AArch64 Linux
-Documentation/arm64/booting.txt
+Documentation/arm64/booting.rst
diff --git a/Documentation/locking/spinlocks.rst
b/Documentation/locking/spinlocks.rst
index 098107fb7d86..e93ec6645238 100644
--- a/Documentation/locking/spinlocks.rst
+++ b/Documentation/locking/spinlocks.rst
@@ -82,7 +82,7 @@ itself. The read lock allows many concurrent readers.
Anything that
**changes** the list will have to get the write lock.
NOTE! RCU is better for list traversal, but requires careful
- attention to design detail (see Documentation/RCU/listRCU.txt).
+ attention to design detail (see Documentation/RCU/listRCU.rst).
Also, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_
time need to do any changes (even if you don't do it every time), you have
@@ -90,7 +90,7 @@ to get the write-lock at the very beginning.
NOTE! We are working hard to remove reader-writer spinlocks in most
cases, so please don't add a new one without consensus. (Instead, see
- Documentation/RCU/rcu.txt for complete information.)
+ Documentation/RCU/rcu.rst for complete information.)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index 045bb8148fe9..1adbb8a371c7 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -548,7 +548,7 @@ There are certain things that the Linux kernel memory
barriers do not guarantee:
[*] For information on bus mastering DMA and coherency please read:
- Documentation/PCI/pci.rst
+ Documentation/driver-api/pci/pci.rst
Documentation/DMA-API-HOWTO.txt
Documentation/DMA-API.txt
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt
b/Documentation/translations/ko_KR/memory-barriers.txt
index a33c2a536542..2774624ee843 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -569,7 +569,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
[*] 버스 마스터링 DMA 와 일관성에 대해서는 다음을 참고하시기 바랍니다:
- Documentation/PCI/pci.rst
+ Documentation/driver-api/pci/pci.rst
Documentation/DMA-API-HOWTO.txt
Documentation/DMA-API.txt
diff --git a/Documentation/watchdog/hpwdt.rst b/Documentation/watchdog/hpwdt.rst
index c165d92cfd12..c824cd7f6e32 100644
--- a/Documentation/watchdog/hpwdt.rst
+++ b/Documentation/watchdog/hpwdt.rst
@@ -63,7 +63,7 @@ Last reviewed: 08/20/2018
and loop forever. This is generally not what a watchdog user wants.
For those wishing to learn more please see:
- Documentation/kdump/kdump.rst
+ Documentation/admin-guide/kdump/kdump.rst
Documentation/admin-guide/kernel-parameters.txt (panic=)
Your Linux Distribution specific documentation.
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e2a525e22c0..51bdbd230174 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -899,7 +899,7 @@ L: linux-...@vger.kernel.org
W: http://ez.analog.com/community/linux-device-drivers
S: Supported
F: drivers/iio/adc/ad7124.c
-F:
Re: [RFC PATCH 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
Hi
On 2019-07-25 15:13, Chanwoo Choi wrote:
> 2019년 7월 24일 (수) 오전 8:07, Artur Świgoń 님이 작성:
>> This patch adds two fields tp the Exynos4412 DTS:
>>- parent: to declare connections between nodes that are not in a
>> parent-child relation in devfreq;
>>- #interconnect-cells: required by the interconnect framework.
>>
>> Please note that #interconnect-cells is always zero and node IDs are not
>> hardcoded anywhere.
>>
>> Signed-off-by: Artur Świgoń
>> ---
>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
>> arch/arm/boot/dts/exynos4412.dtsi | 9 +
>> 2 files changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index ea55f377d17c..bdd61ae86103 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -106,6 +106,7 @@
>> _leftbus {
>> devfreq-events = <_leftbus_3>, <_rightbus_3>;
>> vdd-supply = <_reg>;
>> + parent = <_dmc>;
> It is wrong. 'bus_leftbus' has not any h/w dependency of 'bus_dmc'
> and 'bus_leftbus' is not child of 'bus_dmc'.
>
> Even it there are some PMQoS requirement between them,
> it it not proper to tie both 'bus_leftbus' and 'bus_dmc'.
There is strict dependency between them. DMC bus running at frequency
lower than left (or right) bus really doesn't make much sense, because
it will limit the left bus performance. This dependency should be
modeled somehow.
>> status = "okay";
>> };
>>
>> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
>> b/arch/arm/boot/dts/exynos4412.dtsi
>> index d20db2dfe8e2..a70a671acacd 100644
>> --- a/arch/arm/boot/dts/exynos4412.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412.dtsi
>> @@ -390,6 +390,7 @@
>> clocks = < CLK_DIV_DMC>;
>> clock-names = "bus";
>> operating-points-v2 = <_dmc_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -398,6 +399,7 @@
>> clocks = < CLK_DIV_ACP>;
>> clock-names = "bus";
>> operating-points-v2 = <_acp_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -406,6 +408,7 @@
>> clocks = < CLK_DIV_C2C>;
>> clock-names = "bus";
>> operating-points-v2 = <_dmc_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -459,6 +462,7 @@
>> clocks = < CLK_DIV_GDL>;
>> clock-names = "bus";
>> operating-points-v2 = <_leftbus_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -467,6 +471,7 @@
>> clocks = < CLK_DIV_GDR>;
>> clock-names = "bus";
>> operating-points-v2 = <_leftbus_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -475,6 +480,7 @@
>> clocks = < CLK_ACLK160>;
>> clock-names = "bus";
>> operating-points-v2 = <_display_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -483,6 +489,7 @@
>> clocks = < CLK_ACLK133>;
>> clock-names = "bus";
>> operating-points-v2 = <_fsys_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -491,6 +498,7 @@
>> clocks = < CLK_ACLK100>;
>> clock-names = "bus";
>> operating-points-v2 = <_peri_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -499,6 +507,7 @@
>> clocks = < CLK_SCLK_MFC>;
>> clock-names = "bus";
>> operating-points-v2 = <_leftbus_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> --
>> 2.17.1
>>
>
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
Re: [PATCH v5 01/24] drm: Include ddc adapter pointer in struct drm_connector
Hi Sam, W dniu 26.07.2019 o 08:37, Sam Ravnborg pisze: Hi Andrzej. Patch looks good, but one kernel-doc detail. Thanks, I will address both issues you found, in v6. Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204181] NULL pointer dereference regression in amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181 Frank Steinborn (stei...@nognu.de) changed: What|Removed |Added CC||stei...@nognu.de --- Comment #21 from Frank Steinborn (stei...@nognu.de) --- Facing the same issue (Vega64). I captured a dmesg (drm.debug=0x54) with lockup and uploaded it here: https://nognu.de/p/dmesg_amdgpu.txt Thanks! -- 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
