lkml.org 
[lkml]   [2020]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 01/13] mfd: Add i.MX generic mix support
    On 20-04-30 10:22:04, Aisheng Dong wrote:
    > > From: Abel Vesa <abel.vesa@nxp.com>
    > > Sent: Thursday, April 30, 2020 6:04 PM
    > > To: Lee Jones <lee.jones@linaro.org>
    > > On 20-04-24 07:27:27, Lee Jones wrote:
    > > > On Thu, 23 Apr 2020, Aisheng Dong wrote:
    > > >
    > > > > > From: Abel Vesa <abel.vesa@nxp.com>
    > > > > > Sent: Wednesday, April 22, 2020 5:19 PM On 20-04-17 09:07:47, Lee
    > > > > > Jones wrote:
    > > > > > > On Wed, 15 Apr 2020, Abel Vesa wrote:
    > > > > > >
    > > > > > > > Some of the i.MX SoCs have a IP for interfacing the dedicated
    > > > > > > > IPs with clocks, resets and interrupts, plus some other specific control
    > > registers.
    > > > > > > > To allow the functionality to be split between drivers, this
    > > > > > > > MFD driver is added that has only two purposes: register the
    > > > > > > > devices and map the entire register addresses. Everything else
    > > > > > > > is left to the dedicated drivers that will bind to the registered devices.
    > > > > > > >
    > > > > > > > Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
    > > > > > > > ---
    > > > > > > > drivers/mfd/Kconfig | 11 +++++++++++
    > > > > > > > drivers/mfd/Makefile | 1 +
    > > > > > > > drivers/mfd/imx-mix.c | 48
    > > > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++
    > > > > > > > 3 files changed, 60 insertions(+) create mode 100644
    > > > > > > > drivers/mfd/imx-mix.c
    > > > > > >
    > > > > > > For completeness - Arnd's reply to this patch:
    > > > > > >
    > > > > >
    > > > > > I'm replying here to Arnd's reply.
    > > > > >
    > > > > > I'm trying to give here a whole picture of the entire problem
    > > > > > while the documentation for i.MX8MP is _not yet_ public.
    > > > > >
    > > > > > Historically, each IP would have its own enclosure for all the related GPRs.
    > > > > > Starting with i.MX8MP some GPRs (and some subparts) from the IP
    > > > > > were placed inside these mixes.
    > > > > >
    > > > > > Audiomix for example, has multiple SAIs, a PLL, and some reset
    > > > > > bits for EARC and some GPRs for AudioDSP. This means that i.MX8MP
    > > > > > has 7 SAIs, 1 EARC and
    > > > > > 1 AudioDSP.
    > > > > > Future platforms might have different numbers of SAIs, EARCs or
    > > AudioDSPs.
    > > > > > The PLL can't be placed in one of those SAIs and it was placed in audiomix.
    > > > > > The i.MX8MP has at least 4 of these mixes.
    > > > > >
    > > > > > Now, the commonalities between all mixes are:
    > > > > > - have their own power domains
    > > > > > - driven by dedicated clock slice
    > > > > > - contain clocks and resets
    > > > > > - some very subsystem specific GPRs
    > > > > >
    > > > > > Knowing that each mix has its own power domain, AFAICT, it needs
    > > > > > to be registered as a single device. Considering that it can have
    > > > > > clocks (audiomix has gates, muxes and plls), I believe that needs
    > > > > > a clock driver, even more so since the muxes need their parents
    > > > > > from the platform clock driver. Same principle applies to reset
    > > > > > bits. The subsystem specific GPRs can be registered as syscon
    > > > > > devices and taken care of by its counterpart IP (e.g. the AudioDSP specific
    > > regs would be taken care of by the DSP driver, if there is one).
    > > > > >
    > > > > > Now based on all of the above, by using MFD we take care of the
    > > > > > power domain control for the entire mix, plus, the MFD doesn't
    > > > > > have any kind of functionality by its own, relying on its children
    > > > > > devices that are populated based on what is in the mix MFD devicetree
    > > node.
    > > > > >
    > > > >
    > > > > How about doing like this which maybe can address Arnd's concerns?
    > > > > audiomix: audiomix@30e20000 {
    > > > > compatible = "fsl,imx8mp-audiomix", "syscon";
    > > > > reg = <0x30e20000 xxx>,
    > > > > <0x30e20xxx xxx>;
    > > > > reg-names = "audio", "reset", "...";
    > > > > #clock-cells = <1>;
    > > > > #reset-cells = <1>;
    > > > > power-domains = <&audiomix_pd>; }
    > > > >
    > > > > That means we have one combo driver registering two controllers
    > > > > (clk/reset), both use the same power domain as audiomix.
    > > > > And it can be easily extended to support more services provided by
    > > > > audiomix over syscon if needed.
    > > > > Then the 'dummy' MDF driver is not needed anymore.
    > > > >
    > > > > Jones & Arnd,
    > > > > How do you think?
    > > >
    > > > Sounds okay in principle. Anything that prevents the existence of a
    > > > dummy (a.k.a. pointless) MFD must be seen as a positive move.
    > > >
    > >
    > > OK, I'll do it in a single driver and single dts node.
    > >
    > > But there might be an issue with the placement of this new driver.
    > >
    > > drivers/clk/imx/ could be an option, but the driver will use a lot of different APIs
    > > from different subsystems. Not the audiomix, but the future mixes.
    >
    > Maybe Stephen could comment whether it's ok to push a combo driver
    > (e.g. clk&reset&syscon) In drivers/clk/imx.
    >
    > From what we see, it seems already some similar combo drivers (clk&reset) there.
    >
    > BTW, not sure if any technical block reasons to put in drivers/clk.
    > Maybe we can quickly try internally first.
    >

    Working on it already.

    > Regards
    > Aisheng
    >
    > >
    > > > --
    > > > Lee Jones [李琼斯]
    > > > Linaro Services Technical Lead
    > > > Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook
    > > > | Twitter | Blog

    \
     
     \ /
      Last update: 2020-04-30 13:14    [W:3.133 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site