lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200821153749.08afec86@coco.lan>
Date:   Fri, 21 Aug 2020 15:37:49 +0200
From:   Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To:     Sam Ravnborg <sam@...nborg.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Neil Armstrong <narmstrong@...libre.com>,
        Xinliang Liu <xinliang.liu@...aro.org>,
        Wanchun Zheng <zhengwanchun@...ilicon.com>,
        linuxarm@...wei.com, dri-devel <dri-devel@...ts.freedesktop.org>,
        Andrzej Hajda <a.hajda@...sung.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        devel@...verdev.osuosl.org, Daniel Borkmann <daniel@...earbox.net>,
        John Fastabend <john.fastabend@...il.com>,
        Xiubin Zhang <zhangxiubin1@...wei.com>,
        Wei Xu <xuwei5@...ilicon.com>, David Airlie <airlied@...ux.ie>,
        Xinwei Kong <kong.kongxinwei@...ilicon.com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Bogdan Togorean <bogdan.togorean@...log.com>,
        Laurentiu Palcu <laurentiu.palcu@....com>,
        linux-media@...r.kernel.org, devicetree@...r.kernel.org,
        Liwei Cai <cailiwei@...ilicon.com>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        Manivannan Sadhasivam <mani@...nel.org>,
        Chen Feng <puck.chen@...ilicon.com>,
        Alexei Starovoitov <ast@...nel.org>,
        linaro-mm-sig@...ts.linaro.org, Rob Herring <robh+dt@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>, mauro.chehab@...wei.com,
        Rob Clark <robdclark@...omium.org>,
        linux-arm-kernel@...ts.infradead.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, Liuyao An <anliuyao@...wei.com>,
        Rongrong Zou <zourongrong@...il.com>, bpf@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH 00/49] DRM driver for Hikey 970

Hi Sam,

Em Wed, 19 Aug 2020 19:35:58 +0200
Sam Ravnborg <sam@...nborg.org> escreveu:

> > +	ret = drm_bridge_attach(encoder, bridge, NULL, 0);  
> The bridge should be attached with the falg that tell the bridge NOT to
> create a connector.
> 
> The display driver shall created the connector.
> 
> Please see how other drivers do this (but most driver uses the old
> pattern so so look for drm_bridge_attach() with the flag argument.

Not sure if I got what should be done here.

From what I've seen at the DRM code, one of the differences between the 
display engine for the first Hikey board (Kirin 620 based) and 960/970
is with regards to bridges. The first Hikey device doesn't use any
external bridges: both panel and HDMI support are provided by the SoC.

The Hikey 960 and 970 boards may either use an external bridge
or not. They also have two output connectors:

- The first one doesn't use an external bridge. It is used
  only together with an external daughter display panel board. 
  It sounds that one such panels is this one:

	https://www.96boards.org/blog/linksprite-hikey-aosp/

  I don't have any such board. The OOT driver came with one
  panel display, I didn't port such driver. 

- The second one uses an external bridge (adv7535) which is connected
  to the HDMI board's connector.

As there's just one bridge, the driver uses this to find its
OF data:

	struct device_node *bridge_node;

	bridge_node = of_graph_get_remote_port_parent(endpoint);
	dsi->bridge = of_drm_find_bridge(bridge_node);

Basically, it doesn't call drm_bridge_add(), and doesn't
declare any struct drm_bridge_funcs fops, as there's just one
bridge that it is always there.

-

That's said, when I ported the code from Kernel 4.9, I fixed
some broken things at the hotplug logic, trying to use other
drivers with external bridges as examples. Yet, as you noticed,
I ended using some older bridge model.  

The only other driver I found that doesn't use drm_bridge_add()
and doesn't pass 0 as flags is this one:

	drivers/gpu/drm/omapdrm/omap_drv.c

Is it a good example?

What I see different there there is that it calls drm_bridge_attach()
with:

	ret = drm_bridge_attach(pipe->encoder,
				pipe->output->bridge, NULL,
				DRM_BRIDGE_ATTACH_NO_CONNECTOR);

Is adding this enough? Or should I do something else?


Thanks,
Mauro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ