All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: [Ksummit-discuss] Self nomination
Date: Sat, 06 Aug 2016 02:20:24 +0200	[thread overview]
Message-ID: <2095093.rkXOZ187BN@vostro.rjw.lan> (raw)
In-Reply-To: <b339d512-afc6-8f2d-4c26-e6ff997f75c4@samsung.com>

On Wednesday, August 03, 2016 10:12:00 AM Marek Szyprowski wrote:
> Dear All,
> 
> 
> On 2016-08-03 01:00, Rafael J. Wysocki wrote:
> > On Tuesday, August 02, 2016 10:09:17 AM Linus Walleij wrote:
> >> On Thu, Jul 28, 2016 at 12:14 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> >>> On 26/07/16 23:30, Dmitry Torokhov wrote:
> >>>> - I would like to sync up with people and discuss [lack of] progress
> >>>>    on topic of device probe ordering (including handling of deferred
> >>>>    probes, asynchronous probes, etc).
> >>> I'm extremely interested in discussing this.
> >> I've also tried to pitch in on it in the past but I just feel stupid
> >> whenever we try to come up with something better than what
> >> we have :(
> >>
> >>> It has wide reaching consequences as (with my irqchip maintainer hat on)
> >>> we've had to pretend that some bits of HW (timers, interrupt
> >>> controllers) are not "devices". Not a massive issue for most, except
> >>> when your interrupt controller has requirements that are very similar to
> >>> the DMA mapping API (which you cannot use because "not a device"). Other
> >>> problems are introduced by things like wire-MSI bridges, and most people
> >>> end-up resorting to hacks like ad-hoc initcalls and sprinkling deferred
> >>> probes in specific drivers.
> >> Same feeling here. I'm accepting patches for random initcall
> >> reordering because there is nothing else I can do, people need to
> >> have their systems running. But it feels really fragile.
> >>
> >> Deferred probe alleviated the problem, but I remember saying at
> >> the time that what we really need to do is build a dependency
> >> graph and resolve it the same way e.g. systemd does. (Someone
> >> may have called me BS on that, either for being wrong about everything
> >> as usual or because of mentioning systemd, I don't know which one.)
> >>
> >> The latest proposal I saw came from Rafael and he had a scratch
> >> idea for a dependency graph that I really liked, but I guess he's been
> >> sidetracked since. Rafael, what happened with that?
> > I got distracted, but Marek Szyprowski has revived it recently.
> >
> > It needs to be cleaned up somewhat, but other than that I think it's in
> > a good enough shape to make some progress in that direction, at least in
> > principle.
> 
> I really like the idea of pm dependencies between device and the patches
> prepared by Rafael. They are exactly what we need for our case (PM for
> Exynos IOMMU), but they will also help solving PM issues with complex
> devices (like DRM for SoCs and ASoC audio).
> 
> Rafael: do you plan to do any update on them?

Yes, I do, but to make some cosmetic changes rather.

> Some time ago you wrote, that you had such plan, but real life proved
> something else.

Well, I was working on other things in the meantime, but I still had that
plan. :-)

> If needed I can continue works on them, but I need some directions what has
> to be improved and fixed.

Thanks so much!

First off, the networking people claimed the "devlink" term in the meantime
and it's better to avoid confusion here, so I'd change it to "devdep" or
similar in the patches.

In addition to that Tomeu Vizoso complained that the supplier_links and
consumer_links list heads in struct device were confusing and I see why that
could be the case, so I'd change them to something more direct, like maybe
links_to_suppliers and links_to_consumers.

Please let me know what you think.

Thanks,
Rafael

WARNING: multiple messages have this Message-ID (diff)
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	"ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: [Ksummit-discuss] Self nomination
Date: Sat, 06 Aug 2016 02:20:24 +0200	[thread overview]
Message-ID: <2095093.rkXOZ187BN@vostro.rjw.lan> (raw)
In-Reply-To: <b339d512-afc6-8f2d-4c26-e6ff997f75c4@samsung.com>

On Wednesday, August 03, 2016 10:12:00 AM Marek Szyprowski wrote:
> Dear All,
> 
> 
> On 2016-08-03 01:00, Rafael J. Wysocki wrote:
> > On Tuesday, August 02, 2016 10:09:17 AM Linus Walleij wrote:
> >> On Thu, Jul 28, 2016 at 12:14 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> >>> On 26/07/16 23:30, Dmitry Torokhov wrote:
> >>>> - I would like to sync up with people and discuss [lack of] progress
> >>>>    on topic of device probe ordering (including handling of deferred
> >>>>    probes, asynchronous probes, etc).
> >>> I'm extremely interested in discussing this.
> >> I've also tried to pitch in on it in the past but I just feel stupid
> >> whenever we try to come up with something better than what
> >> we have :(
> >>
> >>> It has wide reaching consequences as (with my irqchip maintainer hat on)
> >>> we've had to pretend that some bits of HW (timers, interrupt
> >>> controllers) are not "devices". Not a massive issue for most, except
> >>> when your interrupt controller has requirements that are very similar to
> >>> the DMA mapping API (which you cannot use because "not a device"). Other
> >>> problems are introduced by things like wire-MSI bridges, and most people
> >>> end-up resorting to hacks like ad-hoc initcalls and sprinkling deferred
> >>> probes in specific drivers.
> >> Same feeling here. I'm accepting patches for random initcall
> >> reordering because there is nothing else I can do, people need to
> >> have their systems running. But it feels really fragile.
> >>
> >> Deferred probe alleviated the problem, but I remember saying at
> >> the time that what we really need to do is build a dependency
> >> graph and resolve it the same way e.g. systemd does. (Someone
> >> may have called me BS on that, either for being wrong about everything
> >> as usual or because of mentioning systemd, I don't know which one.)
> >>
> >> The latest proposal I saw came from Rafael and he had a scratch
> >> idea for a dependency graph that I really liked, but I guess he's been
> >> sidetracked since. Rafael, what happened with that?
> > I got distracted, but Marek Szyprowski has revived it recently.
> >
> > It needs to be cleaned up somewhat, but other than that I think it's in
> > a good enough shape to make some progress in that direction, at least in
> > principle.
> 
> I really like the idea of pm dependencies between device and the patches
> prepared by Rafael. They are exactly what we need for our case (PM for
> Exynos IOMMU), but they will also help solving PM issues with complex
> devices (like DRM for SoCs and ASoC audio).
> 
> Rafael: do you plan to do any update on them?

Yes, I do, but to make some cosmetic changes rather.

> Some time ago you wrote, that you had such plan, but real life proved
> something else.

Well, I was working on other things in the meantime, but I still had that
plan. :-)

> If needed I can continue works on them, but I need some directions what has
> to be improved and fixed.

Thanks so much!

First off, the networking people claimed the "devlink" term in the meantime
and it's better to avoid confusion here, so I'd change it to "devdep" or
similar in the patches.

In addition to that Tomeu Vizoso complained that the supplier_links and
consumer_links list heads in struct device were confusing and I see why that
could be the case, so I'd change them to something more direct, like maybe
links_to_suppliers and links_to_consumers.

Please let me know what you think.

Thanks,
Rafael


  reply	other threads:[~2016-08-06  0:15 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-26 22:30 [Ksummit-discuss] Self nomination Dmitry Torokhov
2016-07-28 10:14 ` Marc Zyngier
2016-08-02  8:09   ` Linus Walleij
2016-08-02 23:00     ` Rafael J. Wysocki
2016-08-03  8:12       ` Marek Szyprowski
2016-08-06  0:20         ` Rafael J. Wysocki [this message]
2016-08-06  0:20           ` Rafael J. Wysocki
2016-08-24 12:12           ` Marek Szyprowski
2016-08-24 12:12             ` Marek Szyprowski
2016-08-24 17:32             ` Rafael J. Wysocki
2016-08-24 17:32               ` Rafael J. Wysocki
2016-08-08 11:07   ` Lorenzo Pieralisi
2016-09-23 10:42     ` Grant Likely
  -- strict thread matches above, loose matches on Subject: below --
2016-07-31  6:57 Olof Johansson
2016-08-02 19:56 ` Mark Brown
2016-07-30  0:32 Ben Hutchings
2016-07-29 22:45 [Ksummit-discuss] self nomination Mimi Zohar
2016-07-29 15:13 [Ksummit-discuss] Self nomination Bartlomiej Zolnierkiewicz
2016-07-28 17:29 [Ksummit-discuss] self nomination James Bottomley
2016-07-28 17:31 ` James Bottomley
2016-07-27 23:20 Davidlohr Bueso
2016-07-28  7:18 ` Jan Kara
2016-07-28 14:37 ` Rik van Riel
2016-07-29  6:17 ` Wangnan (F)
2016-07-29 23:53   ` Davidlohr Bueso
2016-07-27 14:54 [Ksummit-discuss] Self nomination Mark Rutland
2016-07-27 13:57 Lorenzo Pieralisi
2016-07-27  4:46 Darren Hart
2016-07-27  9:25 ` Linus Walleij
2016-07-27 17:02   ` Darren Hart
2016-08-04 12:30   ` Geert Uytterhoeven
2016-07-27  0:50 Sergey Senozhatsky
2016-07-26 23:59 Stephen Rothwell
2016-07-28 12:23 ` Luis de Bethencourt
2016-07-26 15:44 David Woodhouse
2016-07-25 21:46 [Ksummit-discuss] self nomination Kevin Hilman
2016-07-25 17:11 [Ksummit-discuss] Self nomination Johannes Weiner
2016-07-25 18:15 ` Rik van Riel
2016-07-26 10:56   ` Jan Kara
2016-07-26 13:10     ` Vlastimil Babka
2015-08-24  4:20 [Ksummit-discuss] [TECH TOPIC] Kernel Hardening James Morris
2015-08-24 11:46 ` Jiri Kosina
2015-08-24 11:56   ` James Morris
2015-08-24 17:17     ` Kees Cook
2015-08-26 20:51       ` Kees Cook
2015-08-26 21:10         ` Matthew Garrett
2015-08-30  0:41           ` [Ksummit-discuss] Self nomination Matthew Garrett
2015-08-11  5:05 Haggai Eran
2015-07-31  9:15 David Howells
2015-07-31  2:55 Sasha Levin
2015-07-31 16:27 ` Bjorn Helgaas
2015-07-31 16:59   ` Guenter Roeck
2015-07-31 17:03     ` Bjorn Helgaas
2015-07-31 17:08     ` Greg KH
2015-07-31 17:15       ` Guenter Roeck
2015-07-31 17:51         ` Bjorn Helgaas
2015-07-31 18:12           ` Greg KH
2015-07-31 18:17             ` Dave Jones
2015-07-31 18:22               ` Greg KH
2015-07-31 18:59                 ` Dan Williams
2015-08-01 13:03                   ` Jiri Kosina
2015-07-31 17:26       ` James Bottomley
2015-07-31 17:43         ` Greg KH
2015-07-31 17:49         ` Sasha Levin
     [not found] ` <alpine.DEB.2.02.1507310650220.2218@localhost6.localdomain6>
2015-07-31 17:49   ` Sasha Levin
2015-08-01 13:45     ` Dan Carpenter
2015-08-01 15:26       ` Sasha Levin
2015-08-01 16:22         ` Greg KH
2015-08-03  5:14           ` Sasha Levin
2015-08-01 20:30         ` Dave Jones
2015-08-03  5:17           ` Sasha Levin

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=2095093.rkXOZ187BN@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=tomeu.vizoso@collabora.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 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.