From: CK Hu <ck.hu@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: <matthias.bgg@kernel.org>, <robh+dt@kernel.org>,
<mark.rutland@arm.com>, <p.zabel@pengutronix.de>,
<airlied@linux.ie>, <mturquette@baylibre.com>,
<sboyd@codeaurora.org>, <ulrich.hecht+renesas@gmail.com>,
<laurent.pinchart@ideasonboard.com>, <sean.wang@mediatek.com>,
<sean.wang@kernel.org>, <rdunlap@infradead.org>, <wens@csie.org>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>, <linux-clk@vger.kernel.org>,
<devicetree@vger.kernel.org>,
Matthias Brugger <mbrugger@suse.com>
Subject: Re: [PATCH v5 05/12] drm: mediatek: Omit warning on probe defers
Date: Tue, 20 Nov 2018 18:23:23 +0800 [thread overview]
Message-ID: <1542709403.13494.0.camel@mtksdaap41> (raw)
In-Reply-To: <9a445746-b07d-73e1-68c9-10eb9d5bf771@gmail.com>
Hi, Matthias:
On Tue, 2018-11-20 at 11:19 +0100, Matthias Brugger wrote:
>
> On 20/11/2018 05:05, CK Hu wrote:
> > Hi, Matthias:
> >
> > On Mon, 2018-11-19 at 10:26 +0100, Matthias Brugger wrote:
> >>
> >> On 19/11/2018 06:38, CK Hu wrote:
> >>> Hi, Matthias:
> >>>
> >>> On Fri, 2018-11-16 at 13:54 +0100, matthias.bgg@kernel.org wrote:
> >>>> From: Matthias Brugger <mbrugger@suse.com>
> >>>>
> >>>> It can happen that the mmsys clock drivers aren't probed before the
> >>>> platform driver gets invoked. The platform driver used to print a warning
> >>>> that the driver failed to get the clocks. Omit this error on
> >>>> the defered probe path.
> >>>
> >>> This patch looks good to me, but you have not modified the sub driver in
> >>> HDMI path. We could let HDMI path print the warning and someone send
> >>> another patch later, or you modify for HDMI path in this patch.
> >>
> >> Sure, I'll add this in v6. After inspecting the code, I think we will need to
> >> also check for not initialized clocks in mtk_mdp_comp_init, as the driver for
> >> now does not even check if the clocks are present. What do you think?
> >
> > Yes, we do really need to consider mdp driver because mmsys clock
> > include mdp clock. You remind me that mmsys control 4 major function:
> > drm routing, drm clock, mdp routing, and mdp clock. Your design let the
> > mmsys device as drm device (control drm routing) and create a sub device
> > as clock device (control drm clock, mdp clock). If one day mdp device
> > (may need control drm routing) need to control the register of mdp
> > routing, would mdp device be a sub device? Or we need not to consider
> > this because it need not to access mmsys register now?
> >
>
> I think we should for now concentrate to fix the clock probing issue. If in the
> future we will need to access drm routing from the mdp device, we can have a
> look into this.
>
> Sounds good?
Sounds good to me.
Regards,
CK
> Regards,
> Matthias
WARNING: multiple messages have this Message-ID (diff)
From: CK Hu <ck.hu@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: matthias.bgg@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, p.zabel@pengutronix.de, airlied@linux.ie,
mturquette@baylibre.com, sboyd@codeaurora.org,
ulrich.hecht+renesas@gmail.com,
laurent.pinchart@ideasonboard.com, sean.wang@mediatek.com,
sean.wang@kernel.org, rdunlap@infradead.org, wens@csie.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, Matthias Brugger <mbrugger@suse.com>
Subject: Re: [PATCH v5 05/12] drm: mediatek: Omit warning on probe defers
Date: Tue, 20 Nov 2018 18:23:23 +0800 [thread overview]
Message-ID: <1542709403.13494.0.camel@mtksdaap41> (raw)
In-Reply-To: <9a445746-b07d-73e1-68c9-10eb9d5bf771@gmail.com>
Hi, Matthias:
On Tue, 2018-11-20 at 11:19 +0100, Matthias Brugger wrote:
>
> On 20/11/2018 05:05, CK Hu wrote:
> > Hi, Matthias:
> >
> > On Mon, 2018-11-19 at 10:26 +0100, Matthias Brugger wrote:
> >>
> >> On 19/11/2018 06:38, CK Hu wrote:
> >>> Hi, Matthias:
> >>>
> >>> On Fri, 2018-11-16 at 13:54 +0100, matthias.bgg@kernel.org wrote:
> >>>> From: Matthias Brugger <mbrugger@suse.com>
> >>>>
> >>>> It can happen that the mmsys clock drivers aren't probed before the
> >>>> platform driver gets invoked. The platform driver used to print a warning
> >>>> that the driver failed to get the clocks. Omit this error on
> >>>> the defered probe path.
> >>>
> >>> This patch looks good to me, but you have not modified the sub driver in
> >>> HDMI path. We could let HDMI path print the warning and someone send
> >>> another patch later, or you modify for HDMI path in this patch.
> >>
> >> Sure, I'll add this in v6. After inspecting the code, I think we will need to
> >> also check for not initialized clocks in mtk_mdp_comp_init, as the driver for
> >> now does not even check if the clocks are present. What do you think?
> >
> > Yes, we do really need to consider mdp driver because mmsys clock
> > include mdp clock. You remind me that mmsys control 4 major function:
> > drm routing, drm clock, mdp routing, and mdp clock. Your design let the
> > mmsys device as drm device (control drm routing) and create a sub device
> > as clock device (control drm clock, mdp clock). If one day mdp device
> > (may need control drm routing) need to control the register of mdp
> > routing, would mdp device be a sub device? Or we need not to consider
> > this because it need not to access mmsys register now?
> >
>
> I think we should for now concentrate to fix the clock probing issue. If in the
> future we will need to access drm routing from the mdp device, we can have a
> look into this.
>
> Sounds good?
Sounds good to me.
Regards,
CK
> Regards,
> Matthias
WARNING: multiple messages have this Message-ID (diff)
From: ck.hu@mediatek.com (CK Hu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 05/12] drm: mediatek: Omit warning on probe defers
Date: Tue, 20 Nov 2018 18:23:23 +0800 [thread overview]
Message-ID: <1542709403.13494.0.camel@mtksdaap41> (raw)
In-Reply-To: <9a445746-b07d-73e1-68c9-10eb9d5bf771@gmail.com>
Hi, Matthias:
On Tue, 2018-11-20 at 11:19 +0100, Matthias Brugger wrote:
>
> On 20/11/2018 05:05, CK Hu wrote:
> > Hi, Matthias:
> >
> > On Mon, 2018-11-19 at 10:26 +0100, Matthias Brugger wrote:
> >>
> >> On 19/11/2018 06:38, CK Hu wrote:
> >>> Hi, Matthias:
> >>>
> >>> On Fri, 2018-11-16 at 13:54 +0100, matthias.bgg at kernel.org wrote:
> >>>> From: Matthias Brugger <mbrugger@suse.com>
> >>>>
> >>>> It can happen that the mmsys clock drivers aren't probed before the
> >>>> platform driver gets invoked. The platform driver used to print a warning
> >>>> that the driver failed to get the clocks. Omit this error on
> >>>> the defered probe path.
> >>>
> >>> This patch looks good to me, but you have not modified the sub driver in
> >>> HDMI path. We could let HDMI path print the warning and someone send
> >>> another patch later, or you modify for HDMI path in this patch.
> >>
> >> Sure, I'll add this in v6. After inspecting the code, I think we will need to
> >> also check for not initialized clocks in mtk_mdp_comp_init, as the driver for
> >> now does not even check if the clocks are present. What do you think?
> >
> > Yes, we do really need to consider mdp driver because mmsys clock
> > include mdp clock. You remind me that mmsys control 4 major function:
> > drm routing, drm clock, mdp routing, and mdp clock. Your design let the
> > mmsys device as drm device (control drm routing) and create a sub device
> > as clock device (control drm clock, mdp clock). If one day mdp device
> > (may need control drm routing) need to control the register of mdp
> > routing, would mdp device be a sub device? Or we need not to consider
> > this because it need not to access mmsys register now?
> >
>
> I think we should for now concentrate to fix the clock probing issue. If in the
> future we will need to access drm routing from the mdp device, we can have a
> look into this.
>
> Sounds good?
Sounds good to me.
Regards,
CK
> Regards,
> Matthias
next prev parent reply other threads:[~2018-11-20 10:23 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-16 12:54 [PATCH v5 00/12] arm/arm64: mediatek: Fix mmsys device probing matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` [PATCH v5 01/12] drm/mediatek: Use regmap for register access matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` [PATCH v5 02/12] clk: mediatek: mt2701-mmsys: switch to platform device probing matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` matthias.bgg
2018-11-16 12:54 ` [PATCH v5 03/12] clk: mediatek: mt8173: switch mmsys " matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` matthias.bgg
2019-10-31 4:17 ` Hsin-Yi Wang
2019-10-31 4:17 ` Hsin-Yi Wang
2019-10-31 4:17 ` Hsin-Yi Wang
2019-10-31 4:17 ` Hsin-Yi Wang
2019-11-04 11:14 ` Matthias Brugger
2019-11-04 11:14 ` Matthias Brugger
2019-11-04 11:14 ` Matthias Brugger
2019-11-04 11:14 ` Matthias Brugger
2018-11-16 12:54 ` [PATCH v5 04/12] drm/mediatek: Add support for mmsys through a pdev matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` matthias.bgg
2018-11-19 5:54 ` CK Hu
2018-11-19 5:54 ` CK Hu
2018-11-19 5:54 ` CK Hu
2018-11-16 12:54 ` [PATCH v5 05/12] drm: mediatek: Omit warning on probe defers matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` matthias.bgg
2018-11-19 5:38 ` CK Hu
2018-11-19 5:38 ` CK Hu
2018-11-19 5:38 ` CK Hu
2018-11-19 9:26 ` Matthias Brugger
2018-11-19 9:26 ` Matthias Brugger
2018-11-20 4:05 ` CK Hu
2018-11-20 4:05 ` CK Hu
2018-11-20 4:05 ` CK Hu
2018-11-20 4:09 ` CK Hu
2018-11-20 4:09 ` CK Hu
2018-11-20 4:09 ` CK Hu
2018-11-20 8:26 ` Aw: Re: [PATCH v5 05/12] drm: mediatek Frank Wunderlich
2018-11-20 8:26 ` Frank Wunderlich
2018-11-20 10:14 ` Matthias Brugger
2018-11-20 10:14 ` Matthias Brugger
2018-11-20 10:34 ` Aw: " Frank Wunderlich
2018-11-20 10:34 ` Frank Wunderlich
2018-11-20 11:39 ` Matthias Brugger
2018-11-20 11:39 ` Matthias Brugger
2018-11-20 10:19 ` [PATCH v5 05/12] drm: mediatek: Omit warning on probe defers Matthias Brugger
2018-11-20 10:19 ` Matthias Brugger
2018-11-20 10:23 ` CK Hu [this message]
2018-11-20 10:23 ` CK Hu
2018-11-20 10:23 ` CK Hu
2018-11-16 12:54 ` [PATCH v5 06/12] drm/mediatek: update dt-bindings matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` matthias.bgg
2018-11-16 23:06 ` Rob Herring
2018-11-16 23:06 ` Rob Herring
2018-11-16 12:54 ` [PATCH v5 07/12] dt-bindings: clock: mediatek: delete mmsys clocks matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` matthias.bgg
2018-11-16 23:07 ` Rob Herring
2018-11-16 23:07 ` Rob Herring
2018-11-16 12:54 ` [PATCH v5 08/12] dt-bindings: mediatek: Change the binding for " matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` matthias.bgg
2018-11-16 23:15 ` Rob Herring
2018-11-16 23:15 ` Rob Herring
2018-11-16 23:15 ` Rob Herring
2018-11-18 17:12 ` Matthias Brugger
2018-11-18 17:12 ` Matthias Brugger
2018-11-19 19:15 ` Rob Herring
2018-11-19 19:15 ` Rob Herring
2018-11-19 19:15 ` Rob Herring
2018-11-21 16:46 ` Stephen Boyd
2018-11-21 16:46 ` Stephen Boyd
2018-11-21 16:46 ` Stephen Boyd
2018-11-21 17:09 ` Matthias Brugger
2018-11-21 17:09 ` Matthias Brugger
2018-11-21 17:09 ` Matthias Brugger
2018-11-30 6:43 ` Stephen Boyd
2018-11-30 6:43 ` Stephen Boyd
2018-11-30 6:43 ` Stephen Boyd
2018-11-30 8:59 ` Matthias Brugger
2018-11-30 8:59 ` Matthias Brugger
2018-11-30 8:59 ` Matthias Brugger
2019-07-01 3:55 ` CK Hu
2019-07-01 3:55 ` CK Hu
2019-07-01 3:55 ` CK Hu
2019-07-04 9:08 ` Matthias Brugger
2019-07-04 9:08 ` Matthias Brugger
2019-07-04 9:08 ` Matthias Brugger
2019-07-04 15:33 ` Ulrich Hecht
2019-07-04 15:33 ` Ulrich Hecht
2019-07-04 15:33 ` Ulrich Hecht
2019-07-05 1:35 ` CK Hu
2019-07-05 1:35 ` CK Hu
2019-07-05 1:35 ` CK Hu
2019-07-05 10:13 ` Matthias Brugger
2019-07-05 10:13 ` Matthias Brugger
2018-11-16 12:54 ` [PATCH v5 09/12] arm64: dts: mt2712e: Use the new mmsys clock compatible matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` [PATCH v5 10/12] arm64: dts: mt6797: " matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` [PATCH v5 11/12] clk: mediatek: mt2712e: Probe with new compatible matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
2018-11-16 12:54 ` matthias.bgg
2018-11-16 12:54 ` [PATCH v5 12/12] clk: mediatek: mt6797: " matthias.bgg
2018-11-16 12:54 ` matthias.bgg at kernel.org
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=1542709403.13494.0.camel@mtksdaap41 \
--to=ck.hu@mediatek.com \
--cc=airlied@linux.ie \
--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-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=matthias.bgg@kernel.org \
--cc=mbrugger@suse.com \
--cc=mturquette@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=sean.wang@kernel.org \
--cc=sean.wang@mediatek.com \
--cc=ulrich.hecht+renesas@gmail.com \
--cc=wens@csie.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.