From: Matthias Brugger <matthias.bgg@gmail.com>
To: ulrich.hecht+renesas@gmail.com,
laurent.pinchart@ideasonboard.com, ck.hu@mediatek.com,
p.zabel@pengutronix.de, airlied@linux.ie, robh+dt@kernel.org,
mark.rutland@arm.com
Cc: linux@armlinux.org.uk, matthias.bgg@gmail.com,
catalin.marinas@arm.com, will.deacon@arm.com,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem
Date: Thu, 19 Oct 2017 13:26:06 +0200 [thread overview]
Message-ID: <20171019112610.13645-1-mbrugger@suse.com> (raw)
In theory the MMSYS device tree identifier is matches twice, by the clk driver
and the DRM subsystem. But the kernel only matches the first driver for a
device (clk) and discards the second one. This breaks graphics on mt8173 and
most probably on mt2701 as well.
MMSYS in Mediatek SoCs has some registers to control clock gates (which is
used in the clk driver) and some registers to enable the differnet blocks of
the display subsystem. The kernel uses the binding to load the central
comoponent of the distplay subsystem, which in place probes all the other
components and enables the present ones in the MMSYS.
We found us with the problem, that we need to change and therefor break one
of the two bindings, or the DRM one or the clock driver one.
Apart from that the DRM subysystem does access the MMSYS registers via relaxed
reads/writes. But the it should to so via regmap, as the registers are shared.
Possible solutions:
1) We add a new mediatek,mt8173-mmsys-clk node, which lives as a simple-mfd
under the actual mmsys node. We change the clock driver to probe on this
binding. This would make sense as the clock gate register live completly in
the MMSYS configuration registers.
2) As the nodes of the DRM subsystem just need some of the registers of MMSYS
we add a new binding mediatek,mt8173-dispsys which probes the central
component of the DRM system. It has only a handle to mt8173-mmsys to access
the registerspace via regmap functions.
In this patchset I implemented 2). Please take into account, that this is a
RFC. I had no time to actually test the verison on real HW. Some of the
register accesses should be done using regmap_update instead of
regmap_read + regmap_write.
This RFC shall only show how solution 2) would look like. We can use it as
discussion to see how we circumvent the actual situation.
next reply other threads:[~2017-10-19 11:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-19 11:26 Matthias Brugger [this message]
2017-10-19 11:26 ` [RFC resend 1/4] dt-bindings: display: mediatek: add drm binding Matthias Brugger
2017-10-19 12:19 ` Ryder Lee
2017-10-19 14:36 ` Matthias Brugger
[not found] ` <20171019112610.13645-2-mbrugger-IBi9RG/b67k@public.gmane.org>
2017-10-19 12:38 ` Philipp Zabel
2017-10-19 12:53 ` Laurent Pinchart
2017-10-19 13:06 ` Philipp Zabel
[not found] ` <1508418397.7665.18.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2017-10-19 15:11 ` Matthias Brugger
2017-10-19 11:26 ` [RFC resend 2/4] drm/mediatek: Add new compatible to probe multimedia subsystem Matthias Brugger
2017-10-19 11:26 ` [RFC resend 3/4] arm64: dts: mt8173: Fix drm subsystem Matthias Brugger
[not found] ` <20171019112610.13645-4-mbrugger-IBi9RG/b67k@public.gmane.org>
2017-10-19 12:38 ` Philipp Zabel
2017-10-20 9:16 ` CK Hu
2017-10-20 12:49 ` Matthias Brugger
2017-10-19 11:26 ` [RFC resend 4/4] arm: dts: mt2701: " Matthias Brugger
2017-10-19 13:01 ` [RFC resend] arm64: mt8173: Fix Acer Chromebooks mmsys probe problem Philipp Zabel
2017-10-19 13:39 ` Laurent Pinchart
2017-10-19 14:54 ` Philipp Zabel
2017-10-23 1:42 ` CK Hu
[not found] ` <1508424856.7665.22.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2017-10-23 10:23 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171019112610.13645-1-mbrugger@suse.com \
--to=matthias.bgg@gmail.com \
--cc=airlied@linux.ie \
--cc=catalin.marinas@arm.com \
--cc=ck.hu@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=ulrich.hecht+renesas@gmail.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).