All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Boichat <drinkcat@chromium.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Rob Herring <robh+dt@kernel.org>, David Airlie <airlied@linux.ie>,
	Daniel Vetter <daniel@ffwll.ch>,
	Mark Rutland <mark.rutland@arm.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Steven Price <steven.price@arm.com>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v4 5/7] drm/panfrost: Add support for multiple power domains
Date: Wed, 12 Feb 2020 10:08:26 +0800	[thread overview]
Message-ID: <CANMq1KC2LEQ2iQzGDVAi+-x4Uy1LLB8JU-grTBVTL-iRej-t4A@mail.gmail.com> (raw)
In-Reply-To: <CAGETcx_3-ZoVAf+Uf0Yo86pUU1nL4S4-jrS0eZi50yvhCO985g@mail.gmail.com>

On Wed, Feb 12, 2020 at 4:09 AM Saravana Kannan <saravanak@google.com> wrote:
>
> On Tue, Feb 11, 2020 at 11:44 AM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > +Saravana
> >
> > On Thu, Feb 6, 2020 at 11:27 PM Nicolas Boichat <drinkcat@chromium.org> wrote:
> > >
> > > When there is a single power domain per device, the core will
> > > ensure the power domain is switched on (so it is technically
> > > equivalent to having not power domain specified at all).
> > >
> > > However, when there are multiple domains, as in MT8183 Bifrost
> > > GPU, we need to handle them in driver code.
> > >
> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > >
> > > ---
> > > [snip]
> > > +               pfdev->pm_domain_links[i] = device_link_add(pfdev->dev,
> > > +                               pfdev->pm_domain_devs[i], DL_FLAG_PM_RUNTIME |
> > > +                               DL_FLAG_STATELESS | DL_FLAG_RPM_ACTIVE);
> >
> > We're in the process of adding device links based on DT properties.
> > Shouldn't we add power domains to that? See drivers/of/property.c for
> > what's handled.
>
> Rob,
>
> drivers/of/property.c doesn't enable the RPM_ACTIVE AND PM_RUNTIME
> flags. Wanted to start off conservative. But adding command line ops
> to change the default flags shouldn't be difficult. But before I do
> that, I want to change of_devlink to
> fw_devlink=<disabled|permissive|enabled>. May be I can extend that to
> "disabled, permissive, suspend, runtime".
>
> Nicholas,
>
> And the adding and removing of device links for power domains will be
> a 2 line change. I've been meaning to add a few more bindings like
> hwspinlocks and pinctrl. I can roll power domains support into that if
> you want.

Adding power domains makes sense to me, as there are a bunch of other
users (git grep dev_pm_domain_attach_by_name).

This seems to be a bit orthogonal to this patch though. If your
solution lands before this (and not something that is behind a command
line option), then I'm happy to make use of it. Either way, happy to
test things.

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Boichat <drinkcat@chromium.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	David Airlie <airlied@linux.ie>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Steven Price <steven.price@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 5/7] drm/panfrost: Add support for multiple power domains
Date: Wed, 12 Feb 2020 10:08:26 +0800	[thread overview]
Message-ID: <CANMq1KC2LEQ2iQzGDVAi+-x4Uy1LLB8JU-grTBVTL-iRej-t4A@mail.gmail.com> (raw)
In-Reply-To: <CAGETcx_3-ZoVAf+Uf0Yo86pUU1nL4S4-jrS0eZi50yvhCO985g@mail.gmail.com>

On Wed, Feb 12, 2020 at 4:09 AM Saravana Kannan <saravanak@google.com> wrote:
>
> On Tue, Feb 11, 2020 at 11:44 AM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > +Saravana
> >
> > On Thu, Feb 6, 2020 at 11:27 PM Nicolas Boichat <drinkcat@chromium.org> wrote:
> > >
> > > When there is a single power domain per device, the core will
> > > ensure the power domain is switched on (so it is technically
> > > equivalent to having not power domain specified at all).
> > >
> > > However, when there are multiple domains, as in MT8183 Bifrost
> > > GPU, we need to handle them in driver code.
> > >
> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > >
> > > ---
> > > [snip]
> > > +               pfdev->pm_domain_links[i] = device_link_add(pfdev->dev,
> > > +                               pfdev->pm_domain_devs[i], DL_FLAG_PM_RUNTIME |
> > > +                               DL_FLAG_STATELESS | DL_FLAG_RPM_ACTIVE);
> >
> > We're in the process of adding device links based on DT properties.
> > Shouldn't we add power domains to that? See drivers/of/property.c for
> > what's handled.
>
> Rob,
>
> drivers/of/property.c doesn't enable the RPM_ACTIVE AND PM_RUNTIME
> flags. Wanted to start off conservative. But adding command line ops
> to change the default flags shouldn't be difficult. But before I do
> that, I want to change of_devlink to
> fw_devlink=<disabled|permissive|enabled>. May be I can extend that to
> "disabled, permissive, suspend, runtime".
>
> Nicholas,
>
> And the adding and removing of device links for power domains will be
> a 2 line change. I've been meaning to add a few more bindings like
> hwspinlocks and pinctrl. I can roll power domains support into that if
> you want.

Adding power domains makes sense to me, as there are a bunch of other
users (git grep dev_pm_domain_attach_by_name).

This seems to be a bit orthogonal to this patch though. If your
solution lands before this (and not something that is behind a command
line option), then I'm happy to make use of it. Either way, happy to
test things.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Boichat <drinkcat@chromium.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	David Airlie <airlied@linux.ie>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Steven Price <steven.price@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 5/7] drm/panfrost: Add support for multiple power domains
Date: Wed, 12 Feb 2020 10:08:26 +0800	[thread overview]
Message-ID: <CANMq1KC2LEQ2iQzGDVAi+-x4Uy1LLB8JU-grTBVTL-iRej-t4A@mail.gmail.com> (raw)
In-Reply-To: <CAGETcx_3-ZoVAf+Uf0Yo86pUU1nL4S4-jrS0eZi50yvhCO985g@mail.gmail.com>

On Wed, Feb 12, 2020 at 4:09 AM Saravana Kannan <saravanak@google.com> wrote:
>
> On Tue, Feb 11, 2020 at 11:44 AM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > +Saravana
> >
> > On Thu, Feb 6, 2020 at 11:27 PM Nicolas Boichat <drinkcat@chromium.org> wrote:
> > >
> > > When there is a single power domain per device, the core will
> > > ensure the power domain is switched on (so it is technically
> > > equivalent to having not power domain specified at all).
> > >
> > > However, when there are multiple domains, as in MT8183 Bifrost
> > > GPU, we need to handle them in driver code.
> > >
> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > >
> > > ---
> > > [snip]
> > > +               pfdev->pm_domain_links[i] = device_link_add(pfdev->dev,
> > > +                               pfdev->pm_domain_devs[i], DL_FLAG_PM_RUNTIME |
> > > +                               DL_FLAG_STATELESS | DL_FLAG_RPM_ACTIVE);
> >
> > We're in the process of adding device links based on DT properties.
> > Shouldn't we add power domains to that? See drivers/of/property.c for
> > what's handled.
>
> Rob,
>
> drivers/of/property.c doesn't enable the RPM_ACTIVE AND PM_RUNTIME
> flags. Wanted to start off conservative. But adding command line ops
> to change the default flags shouldn't be difficult. But before I do
> that, I want to change of_devlink to
> fw_devlink=<disabled|permissive|enabled>. May be I can extend that to
> "disabled, permissive, suspend, runtime".
>
> Nicholas,
>
> And the adding and removing of device links for power domains will be
> a 2 line change. I've been meaning to add a few more bindings like
> hwspinlocks and pinctrl. I can roll power domains support into that if
> you want.

Adding power domains makes sense to me, as there are a bunch of other
users (git grep dev_pm_domain_attach_by_name).

This seems to be a bit orthogonal to this patch though. If your
solution lands before this (and not something that is behind a command
line option), then I'm happy to make use of it. Either way, happy to
test things.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Boichat <drinkcat@chromium.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	David Airlie <airlied@linux.ie>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Steven Price <steven.price@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Hsin-Yi Wang <hsinyi@chromium.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 5/7] drm/panfrost: Add support for multiple power domains
Date: Wed, 12 Feb 2020 10:08:26 +0800	[thread overview]
Message-ID: <CANMq1KC2LEQ2iQzGDVAi+-x4Uy1LLB8JU-grTBVTL-iRej-t4A@mail.gmail.com> (raw)
In-Reply-To: <CAGETcx_3-ZoVAf+Uf0Yo86pUU1nL4S4-jrS0eZi50yvhCO985g@mail.gmail.com>

On Wed, Feb 12, 2020 at 4:09 AM Saravana Kannan <saravanak@google.com> wrote:
>
> On Tue, Feb 11, 2020 at 11:44 AM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > +Saravana
> >
> > On Thu, Feb 6, 2020 at 11:27 PM Nicolas Boichat <drinkcat@chromium.org> wrote:
> > >
> > > When there is a single power domain per device, the core will
> > > ensure the power domain is switched on (so it is technically
> > > equivalent to having not power domain specified at all).
> > >
> > > However, when there are multiple domains, as in MT8183 Bifrost
> > > GPU, we need to handle them in driver code.
> > >
> > > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
> > >
> > > ---
> > > [snip]
> > > +               pfdev->pm_domain_links[i] = device_link_add(pfdev->dev,
> > > +                               pfdev->pm_domain_devs[i], DL_FLAG_PM_RUNTIME |
> > > +                               DL_FLAG_STATELESS | DL_FLAG_RPM_ACTIVE);
> >
> > We're in the process of adding device links based on DT properties.
> > Shouldn't we add power domains to that? See drivers/of/property.c for
> > what's handled.
>
> Rob,
>
> drivers/of/property.c doesn't enable the RPM_ACTIVE AND PM_RUNTIME
> flags. Wanted to start off conservative. But adding command line ops
> to change the default flags shouldn't be difficult. But before I do
> that, I want to change of_devlink to
> fw_devlink=<disabled|permissive|enabled>. May be I can extend that to
> "disabled, permissive, suspend, runtime".
>
> Nicholas,
>
> And the adding and removing of device links for power domains will be
> a 2 line change. I've been meaning to add a few more bindings like
> hwspinlocks and pinctrl. I can roll power domains support into that if
> you want.

Adding power domains makes sense to me, as there are a bunch of other
users (git grep dev_pm_domain_attach_by_name).

This seems to be a bit orthogonal to this patch though. If your
solution lands before this (and not something that is behind a command
line option), then I'm happy to make use of it. Either way, happy to
test things.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-02-12  2:08 UTC|newest]

Thread overview: 166+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07  5:26 [PATCH v4 0/7] Add dts for mt8183 GPU (and misc panfrost patches) Nicolas Boichat
2020-02-07  5:26 ` Nicolas Boichat
2020-02-07  5:26 ` Nicolas Boichat
2020-02-07  5:26 ` Nicolas Boichat
2020-02-07  5:26 ` [PATCH v4 1/7] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-25 17:16   ` Rob Herring
2020-02-25 17:16     ` Rob Herring
2020-02-25 17:16     ` Rob Herring
2020-02-25 17:16     ` Rob Herring
2020-02-26  0:55     ` Nicolas Boichat
2020-02-26  0:55       ` Nicolas Boichat
2020-02-26  0:55       ` Nicolas Boichat
2020-02-26  0:55       ` Nicolas Boichat
2020-03-06  2:34       ` Nick Fan
2020-03-06  2:34         ` Nick Fan
2020-03-06  2:34         ` Nick Fan
2020-03-06  2:34         ` Nick Fan
2020-03-06  2:43         ` Nicolas Boichat
2020-03-06  2:43           ` Nicolas Boichat
2020-03-06  2:43           ` Nicolas Boichat
2020-03-06  2:43           ` Nicolas Boichat
2020-03-06 14:13         ` Rob Herring
2020-03-06 14:13           ` Rob Herring
2020-03-06 14:13           ` Rob Herring
2020-03-06 14:13           ` Rob Herring
2020-03-06 14:43           ` Steven Price
2020-03-06 14:43             ` Steven Price
2020-03-06 14:43             ` Steven Price
2020-03-06 14:43             ` Steven Price
2020-03-09  7:55             ` Nick Fan
2020-03-09  7:55               ` Nick Fan
2020-03-09  7:55               ` Nick Fan
2020-03-09  7:55               ` Nick Fan
2020-02-07  5:26 ` [PATCH v4 2/7] arm64: dts: mt8183: Add node for the Mali GPU Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26 ` [PATCH v4 3/7] drm/panfrost: Improve error reporting in panfrost_gpu_power_on Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-12 10:38   ` Matthias Brugger
2020-02-12 10:38     ` Matthias Brugger
2020-02-12 10:38     ` Matthias Brugger
2020-02-12 10:38     ` Matthias Brugger
2020-02-07  5:26 ` [PATCH v4 4/7] drm/panfrost: Add support for multiple regulators Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-10 11:31   ` Steven Price
2020-02-10 11:31     ` Steven Price
2020-02-10 11:31     ` Steven Price
2020-02-10 11:31     ` Steven Price
2020-02-10 14:00   ` Mark Brown
2020-02-10 14:00     ` Mark Brown
2020-02-10 14:00     ` Mark Brown
2020-02-10 14:00     ` Mark Brown
2020-02-07  5:26 ` [PATCH v4 5/7] drm/panfrost: Add support for multiple power domains Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07 13:52   ` Alyssa Rosenzweig
2020-02-07 13:52     ` Alyssa Rosenzweig
2020-02-07 13:52     ` Alyssa Rosenzweig
2020-02-07 13:52     ` Alyssa Rosenzweig
2020-02-09 12:43     ` Nicolas Boichat
2020-02-09 12:43       ` Nicolas Boichat
2020-02-09 12:43       ` Nicolas Boichat
2020-02-09 12:43       ` Nicolas Boichat
2020-02-07 14:25   ` Ulf Hansson
2020-02-07 14:25     ` Ulf Hansson
2020-02-07 14:25     ` Ulf Hansson
2020-02-07 14:25     ` Ulf Hansson
2020-02-09 12:50     ` Nicolas Boichat
2020-02-09 12:50       ` Nicolas Boichat
2020-02-09 12:50       ` Nicolas Boichat
2020-02-09 12:50       ` Nicolas Boichat
2020-02-10  7:50       ` Ulf Hansson
2020-02-10  7:50         ` Ulf Hansson
2020-02-10  7:50         ` Ulf Hansson
2020-02-10  7:50         ` Ulf Hansson
2020-02-10 11:39   ` Steven Price
2020-02-10 11:39     ` Steven Price
2020-02-10 11:39     ` Steven Price
2020-02-10 11:39     ` Steven Price
2020-02-11 19:43   ` Rob Herring
2020-02-11 19:43     ` Rob Herring
2020-02-11 19:43     ` Rob Herring
2020-02-11 19:43     ` Rob Herring
2020-02-11 20:08     ` Saravana Kannan
2020-02-11 20:08       ` Saravana Kannan
2020-02-11 20:08       ` Saravana Kannan
2020-02-11 20:08       ` Saravana Kannan
2020-02-12  1:58       ` Rob Herring
2020-02-12  1:58         ` Rob Herring
2020-02-12  1:58         ` Rob Herring
2020-02-12  1:58         ` Rob Herring
2020-02-12  2:10         ` Saravana Kannan
2020-02-12  2:10           ` Saravana Kannan
2020-02-12  2:10           ` Saravana Kannan
2020-02-12  2:10           ` Saravana Kannan
2020-02-12  2:08       ` Nicolas Boichat [this message]
2020-02-12  2:08         ` Nicolas Boichat
2020-02-12  2:08         ` Nicolas Boichat
2020-02-12  2:08         ` Nicolas Boichat
2020-02-07  5:26 ` [PATCH v4 6/7] RFC: drm/panfrost: Add mt8183-mali compatible string Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26 ` [PATCH v4 7/7] RFC: drm/panfrost: devfreq: Add support for 2 regulators Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-07  5:26   ` Nicolas Boichat
2020-02-12  8:49   ` Nicolas Boichat
2020-02-12  8:49     ` Nicolas Boichat
2020-02-12  8:49     ` Nicolas Boichat
2020-02-12  8:49     ` Nicolas Boichat
2020-02-12  9:06     ` Viresh Kumar
2020-02-12  9:06       ` Viresh Kumar
2020-02-12  9:06       ` Viresh Kumar
2020-02-12  9:06       ` Viresh Kumar
2020-02-12 18:14     ` Rob Herring
2020-02-12 18:14       ` Rob Herring
2020-02-12 18:14       ` Rob Herring
2020-02-12 18:14       ` Rob Herring
2020-02-13  7:57       ` Nicolas Boichat
2020-02-13  7:57         ` Nicolas Boichat
2020-02-13  7:57         ` Nicolas Boichat
2020-02-13  7:57         ` Nicolas Boichat
2020-02-13  8:24         ` Nicolas Boichat
2020-02-13  8:24           ` Nicolas Boichat
2020-02-13  8:24           ` Nicolas Boichat
2020-02-13  8:24           ` Nicolas Boichat
2020-02-14  1:37         ` Nick Fan (范哲維)
2020-02-14  1:37           ` Nick Fan (范哲維)
2020-03-09  1:53           ` Nicolas Boichat
2020-03-09  1:53             ` Nicolas Boichat
2020-03-09  1:53             ` Nicolas Boichat
2020-03-09  1:53             ` Nicolas Boichat
2020-02-07  6:17 ` [PATCH v4 0/7] Add dts for mt8183 GPU (and misc panfrost patches) Tomeu Vizoso
2020-02-07  6:17   ` Tomeu Vizoso
2020-02-07  6:17   ` Tomeu Vizoso
2020-02-07  6:17   ` Tomeu Vizoso
2020-02-07  7:42   ` Nicolas Boichat
2020-02-07  7:42     ` Nicolas Boichat
2020-02-07  7:42     ` Nicolas Boichat
2020-02-07  7:42     ` Nicolas Boichat
2020-02-07  8:13     ` Tomeu Vizoso
2020-02-07  8:13       ` Tomeu Vizoso
2020-02-07  8:13       ` Tomeu Vizoso
2020-02-07  8:13       ` Tomeu Vizoso
2020-02-10  3:39       ` Nicolas Boichat
2020-02-10  3:39         ` Nicolas Boichat
2020-02-10  3:39         ` Nicolas Boichat
2020-02-10  3:39         ` Nicolas Boichat
2020-02-10  8:17         ` Tomeu Vizoso
2020-02-10  8:17           ` Tomeu Vizoso
2020-02-10  8:17           ` Tomeu Vizoso
2020-02-10  8:17           ` Tomeu Vizoso
2020-02-25 20:35 ` Rob Herring
2020-02-25 20:35   ` Rob Herring
2020-02-25 20:35   ` Rob Herring
2020-02-25 20:35   ` Rob Herring

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=CANMq1KC2LEQ2iQzGDVAi+-x4Uy1LLB8JU-grTBVTL-iRej-t4A@mail.gmail.com \
    --to=drinkcat@chromium.org \
    --cc=airlied@linux.ie \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=broonie@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hsinyi@chromium.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=saravanak@google.com \
    --cc=steven.price@arm.com \
    --cc=tomeu.vizoso@collabora.com \
    --cc=ulf.hansson@linaro.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.