[PATCH 06/10] mtd: intel-dg: wake card on operations
Usyskin, Alexander
alexander.usyskin at intel.com
Wed Dec 11 09:46:52 UTC 2024
Adding Kartihik
> Subject: Re: [PATCH 06/10] mtd: intel-dg: wake card on operations
>
> Hi Alexander,
>
> Please reduce the context when answering, otherwise it's hard to find
> all places where you commented.
>
> >> > > > That's the part that I'm not sure if I agree. if I remember from some
> >> > > > experiments in the past,
> >> > > > when you call to wake up the child, the parent will wakeup first
> anyway.
> >> > > >
> >> > > The child (mtd device) does not exist at this point of time.
> >> > > To create MTD device, the partition table should be provided
> >> > > and it read directly from flash that should be powered to do read.
> >> >
> >> > I don't understand... you have the mtd->dev at this point... this is
> >> > the one you should be touching, not the mtd->dev.parent... even at the
> >> > probe, but moreover on everywhere else as well.
> >> >
> >>
> >> At the probe time I do not have dev->mtd, but now I see you point here.
> >> I'll separate power management:
> >> - probe before dev->mtd creation will use aux_dev->dev (that will be mtd-
> >> >dev.parent later)
> >> - mtd functions will use mtd->dev
> >>
> >> Is this that you have in mind?
> >
> > I've tried it and found out that mtd->dev is not initialized if partitions are
> present [1].
> > Miquel - this may be the reason why other mtd drivers use pci or platform
> > devices to manage runtime pm.
> > Or I have missed something?
>
> Please keep in mind there is _a lot_ of history behind mtd, and
> sometimes choices from the past cannot be simply "fixed" without
> breaking userspace. The problem with mtd is that the "mtd" structure
> defines nothing with precision. It may be a controller, a chip, a
> partition, or whatever mix of those. In this particular case, I believe
> you are mentioning the KEEP_PARTITIONED_MASTER configuration, which by
> default is unset, which means you'll loose the "top level" mtd device?
>
> However in general I believe the "framework" struct device is maybe less
> relevant than the "bus" struct device when it comes to runtime PM, so
> actually I would eventually expect this device to be used?
>
So, we can't reliable use the mtd here and should hook power management
on mtd->parent, as done in the patch.
Not sure if there any value in extending mtd to support runtime power management.
- -
Thanks,
Sasha
> > [1] https://elixir.bootlin.com/linux/v6.12-
> rc6/source/drivers/mtd/mtdcore.c#L1078
>
> Thanks,
> Miquèl
More information about the Intel-gfx
mailing list