HI Rob,
Resurrecting old thread, but I think it's better as it has context.
Added driver core maintainers, see discussion points below.
On Wed, 11 Oct 2023 at 21:44, Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Wed, Oct 11, 2023 at 1:20 PM Dmitry Baryshkov
> <dmitry.baryshkov@xxxxxxxxxx> wrote:
> >
> > On Wed, 11 Oct 2023 at 18:49, Rob Herring <robh@xxxxxxxxxx> wrote:
> > >
> > > On Sun, Aug 27, 2023 at 02:50:18PM +0300, Dmitry Baryshkov wrote:
> > > > Add a simple driver that handles scaling of L2 frequency and voltages.
> > > >
> > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
> > > > ---
> > >
> > > [...]
> > >
> > > > +static const struct of_device_id krait_l2_match_table[] = {
> > > > + { .compatible = "qcom,krait-l2-cache" },
> > > > + {}
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, krait_l2_match_table);
> > > > +
> > > > +static struct platform_driver krait_l2_driver = {
> > > > + .probe = krait_l2_probe,
> > > > + .remove = krait_l2_remove,
> > > > + .driver = {
> > > > + .name = "qcom-krait-l2",
> > > > + .of_match_table = krait_l2_match_table,
> > > > + .sync_state = icc_sync_state,
> > > > + },
> > > > +};
> > >
> > > As I mentioned in the other thread, cache devices already have a struct
> > > device. Specifically, they have a struct device (no subclass) on the
> > > cpu_subsys bus type. So there should be no need for a platform device
> > > and second struct device.
> > >
> > > See drivers/acpi/processor_driver.c for an example. Or grep any use of
> > > "cpu_subsys".
> >
> > Most likely you mean drivers/base/cacheinfo.c. I saw this code, I
> > don't think it makes a good fit here. The cacheinfo devices provide
> > information only, they are not tied to DT nodes in any way.
>
> They are completely tied to DT nodes beyond L1.
>
> > cpu_subsys
> > doesn't provide a way to match drivers with subsys devices in the
> > non-ACPI case, etc.
>
> That's a 2 line addition to add DT support.
>
> > Moreover, the whole cacheinfo subsys is
> > non-existing on arm32, there is no cacheinfo implementation there,
> > thanks to the overall variety of architectures.
>
> Humm, well I don't think it would be too hard to add, but I won't ask
> you to do that. All the info comes from DT or can come from DT, so it
> should be just a matter of arm32 calling the cacheinfo init.
>
> > Thus said, I don't think cacheinfo makes a good fit for the case of
> > scaling L2 cache.
>
> I still disagree. It's not really cacheinfo. That is what creates the
> devices, but it's the cpu_subsys bus type. Why do you care that it is
> platform bus vs. cpu_subsys?
I finally found a timeslot to look at cacheinfo. I added support for
arm32 cacheinfo (which is fine) and tried using cacheinfo devices for
L2 driver mapping (the RFC has been posted at [1]).
But after I actually tried using it for the L2 cache driver. I
stumbled upon several issues, which I'd like to discuss before rushing
to code.
First, you supposed that cacheinfo devices land onto the cpu_subsys
bus. However only actual CPU devices end up on cpu_subsys. CPU cache
devices are created using cpu_device_create(), but despite its name
they don't go to cpu_subsys.
Second and more important, these devices are created without any
attempt to share them. So on a 4-core system I have 4 distinct devices
for L2 cache even though it is shared between all cores.
root@qcom-armv7a:~# stat -c "%N %i" /sys/bus/cpu/devices/cpu*/cache/index2/level
/sys/bus/cpu/devices/cpu0/cache/index2/level 15537
/sys/bus/cpu/devices/cpu1/cache/index2/level 15560
/sys/bus/cpu/devices/cpu2/cache/index2/level 15583
/sys/bus/cpu/devices/cpu3/cache/index2/level 15606
I think it makes sense to rework cacheinfo to create actual CPU cache
devices (maybe having a separate cache bus).
In my case it should become something like:
cpu0-2-unified (shared between all 4 cores)
cpu0-1-icache
cpu0-1-dcache
cpu1-1-icache
cpu1-1-dcache
...
I'm not sure if it's worth supporting more than one instance of the
same kind per level (e.g. I think current cacheinfo has nothing
against having two I-cache or two D-cache devices)
The cpuN/cache/indexM should become symlinks to those cache devices.
What do you think?
[1] https://lore.kernel.org/linux-arm-msm/CAA8EJppCRzknaujKFyLa_i7x4UnX31YFSyjtux+zJ0harixrbA@xxxxxxxxxxxxxx
> On a separate issue, I'd propose you move this to drivers/cache/
> instead of the dumping ground that is drivers/soc/. It's nothing more
> than a location to collect cache related drivers ATM because we seem
> to be accumulating more of them.
I thought about reusing drivers/devfreq, it already has the Mediatek CCI driver.
--
With best wishes
Dmitry
