[v4,00/12] Mediatek MT8183 clock and scpsys support
mbox series

Message ID 20190201083016.25856-1-weiyi.lu@mediatek.com
Headers show
Series
  • Mediatek MT8183 clock and scpsys support
Related show

Message

Weiyi Lu Feb. 1, 2019, 8:30 a.m. UTC
This series is based on v5.0-rc1 and most of changes are extracted from series below
(clock/scpsys common changes for both MT8183 & MT6765)
https://patchwork.kernel.org/patch/10528495/
(clock support of MT8183)
https://patchwork.kernel.org/patch/10549891/

The whole series is composed of
clock common changes for both MT8183 & MT6765 (PATCH 1-3),
scpsys common changes for both MT8183 & MT6765 (PATCH 4),
clock support of MT8183 (PATCH 5-8),
scpsys support of MT8183 (PATCH 9-11) and
resend a clock patch long time ago(PTACH 12).

change sinve v3:
- add fix tag.
- small change of mtk_clk_mux data structure.
- use of_property_for_each_string to iterate dependent subsys clock of power domain.
- document critical clocks.
- reduce some clock register error log.
- few coding style fix.

change sinve v2:
- refine for implementation consistency of mtk clk mux.
- separate the onoff API into enable/disable API for mtk scpsys.
- resend a patch about PLL rate changing.

changes since v1:
- refine for better code quality.
- some minor bug fix of clock part, like incorrect control address
  and missing clocks.

Comments

Weiyi Lu Feb. 1, 2019, 8:30 a.m. UTC | #1
This series is based on v5.0-rc1 and most of changes are extracted from series below
(clock/scpsys common changes for both MT8183 & MT6765)
https://patchwork.kernel.org/patch/10528495/
(clock support of MT8183)
https://patchwork.kernel.org/patch/10549891/

The whole series is composed of
clock common changes for both MT8183 & MT6765 (PATCH 1-3),
scpsys common changes for both MT8183 & MT6765 (PATCH 4),
clock support of MT8183 (PATCH 5-8),
scpsys support of MT8183 (PATCH 9-11) and
resend a clock patch long time ago(PTACH 12).

change sinve v3:
- add fix tag.
- small change of mtk_clk_mux data structure.
- use of_property_for_each_string to iterate dependent subsys clock of power domain.
- document critical clocks.
- reduce some clock register error log.
- few coding style fix.

change sinve v2:
- refine for implementation consistency of mtk clk mux.
- separate the onoff API into enable/disable API for mtk scpsys.
- resend a patch about PLL rate changing.

changes since v1:
- refine for better code quality.
- some minor bug fix of clock part, like incorrect control address
  and missing clocks.

James Liao (1):
  clk: mediatek: Allow changing PLL rate when it is off

Owen Chen (4):
  clk: mediatek: Disable tuner_en before change PLL rate
  clk: mediatek: add new clkmux register API
  clk: mediatek: add configurable pcwibits and fmin to mtk_pll_data
  soc: mediatek: add new flow for mtcmos power.

Weiyi Lu (7):
  dt-bindings: ARM: Mediatek: Document bindings for MT8183
  clk: mediatek: Add dt-bindings for MT8183 clocks
  clk: mediatek: Add flags support for mtk_gate data
  clk: mediatek: Add MT8183 clock support
  dt-bindings: soc: fix typo of MT8173 power dt-bindings
  dt-bindings: soc: Add MT8183 power dt-bindings
  soc: mediatek: Add MT8183 scpsys support

 .../arm/mediatek/mediatek,apmixedsys.txt      |    1 +
 .../bindings/arm/mediatek/mediatek,audsys.txt |    1 +
 .../bindings/arm/mediatek/mediatek,camsys.txt |   22 +
 .../bindings/arm/mediatek/mediatek,imgsys.txt |    1 +
 .../arm/mediatek/mediatek,infracfg.txt        |    1 +
 .../bindings/arm/mediatek/mediatek,ipu.txt    |   43 +
 .../bindings/arm/mediatek/mediatek,mcucfg.txt |    1 +
 .../bindings/arm/mediatek/mediatek,mfgcfg.txt |    1 +
 .../bindings/arm/mediatek/mediatek,mmsys.txt  |    1 +
 .../arm/mediatek/mediatek,topckgen.txt        |    1 +
 .../arm/mediatek/mediatek,vdecsys.txt         |    1 +
 .../arm/mediatek/mediatek,vencsys.txt         |    1 +
 .../bindings/soc/mediatek/scpsys.txt          |   14 +
 drivers/clk/mediatek/Kconfig                  |   75 +
 drivers/clk/mediatek/Makefile                 |   15 +-
 drivers/clk/mediatek/clk-gate.c               |    5 +-
 drivers/clk/mediatek/clk-gate.h               |   17 +-
 drivers/clk/mediatek/clk-mt8183-audio.c       |  105 ++
 drivers/clk/mediatek/clk-mt8183-cam.c         |   63 +
 drivers/clk/mediatek/clk-mt8183-img.c         |   63 +
 drivers/clk/mediatek/clk-mt8183-ipu0.c        |   56 +
 drivers/clk/mediatek/clk-mt8183-ipu1.c        |   56 +
 drivers/clk/mediatek/clk-mt8183-ipu_adl.c     |   54 +
 drivers/clk/mediatek/clk-mt8183-ipu_conn.c    |  123 ++
 drivers/clk/mediatek/clk-mt8183-mfgcfg.c      |   54 +
 drivers/clk/mediatek/clk-mt8183-mm.c          |  111 ++
 drivers/clk/mediatek/clk-mt8183-vdec.c        |   67 +
 drivers/clk/mediatek/clk-mt8183-venc.c        |   59 +
 drivers/clk/mediatek/clk-mt8183.c             | 1285 +++++++++++++++++
 drivers/clk/mediatek/clk-mtk.c                |    3 +-
 drivers/clk/mediatek/clk-mtk.h                |    3 +
 drivers/clk/mediatek/clk-mux.c                |  223 +++
 drivers/clk/mediatek/clk-mux.h                |   89 ++
 drivers/clk/mediatek/clk-pll.c                |   53 +-
 drivers/soc/mediatek/Makefile                 |    2 +-
 drivers/soc/mediatek/mtk-scpsys-ext.c         |   99 ++
 drivers/soc/mediatek/mtk-scpsys.c             |  602 ++++++--
 include/dt-bindings/clock/mt8183-clk.h        |  422 ++++++
 include/dt-bindings/power/mt8173-power.h      |    6 +-
 include/dt-bindings/power/mt8183-power.h      |   26 +
 include/linux/soc/mediatek/scpsys-ext.h       |   39 +
 41 files changed, 3757 insertions(+), 107 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt
 create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt
 create mode 100644 drivers/clk/mediatek/clk-mt8183-audio.c
 create mode 100644 drivers/clk/mediatek/clk-mt8183-cam.c
 create mode 100644 drivers/clk/mediatek/clk-mt8183-img.c
 create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu0.c
 create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu1.c
 create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_adl.c
 create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_conn.c
 create mode 100644 drivers/clk/mediatek/clk-mt8183-mfgcfg.c
 create mode 100644 drivers/clk/mediatek/clk-mt8183-mm.c
 create mode 100644 drivers/clk/mediatek/clk-mt8183-vdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt8183-venc.c
 create mode 100644 drivers/clk/mediatek/clk-mt8183.c
 create mode 100644 drivers/clk/mediatek/clk-mux.c
 create mode 100644 drivers/clk/mediatek/clk-mux.h
 create mode 100644 drivers/soc/mediatek/mtk-scpsys-ext.c
 create mode 100644 include/dt-bindings/clock/mt8183-clk.h
 create mode 100644 include/dt-bindings/power/mt8183-power.h
 create mode 100644 include/linux/soc/mediatek/scpsys-ext.h
Stephen Boyd Feb. 20, 2019, 7:18 p.m. UTC | #2
Quoting Weiyi Lu (2019-02-01 00:30:04)
> This series is based on v5.0-rc1 and most of changes are extracted from series below
> (clock/scpsys common changes for both MT8183 & MT6765)
> https://patchwork.kernel.org/patch/10528495/
> (clock support of MT8183)
> https://patchwork.kernel.org/patch/10549891/
> 
> The whole series is composed of
> clock common changes for both MT8183 & MT6765 (PATCH 1-3),
> scpsys common changes for both MT8183 & MT6765 (PATCH 4),
> clock support of MT8183 (PATCH 5-8),
> scpsys support of MT8183 (PATCH 9-11) and
> resend a clock patch long time ago(PTACH 12).

What's the merge plan here? Do you want me to apply these patches to clk
tree? Will someone be sending me a pull request for mediatek clk changes
this cycle? It's getting pretty late for much of anything making this
upcoming merge window.
Matthias Brugger Feb. 21, 2019, 8:36 a.m. UTC | #3
On 20/02/2019 20:18, Stephen Boyd wrote:
> Quoting Weiyi Lu (2019-02-01 00:30:04)
>> This series is based on v5.0-rc1 and most of changes are extracted from series below
>> (clock/scpsys common changes for both MT8183 & MT6765)
>> https://patchwork.kernel.org/patch/10528495/
>> (clock support of MT8183)
>> https://patchwork.kernel.org/patch/10549891/
>>
>> The whole series is composed of
>> clock common changes for both MT8183 & MT6765 (PATCH 1-3),
>> scpsys common changes for both MT8183 & MT6765 (PATCH 4),
>> clock support of MT8183 (PATCH 5-8),
>> scpsys support of MT8183 (PATCH 9-11) and
>> resend a clock patch long time ago(PTACH 12).
> 
> What's the merge plan here? Do you want me to apply these patches to clk
> tree? Will someone be sending me a pull request for mediatek clk changes
> this cycle? It's getting pretty late for much of anything making this
> upcoming merge window.
> 

As far as I can see, the clock patches are independent, so I think it is OK to
take them. SCPSYS patches will go through my tree once they are in shape.

Do you prefer to get pull requests for clock patches? I wasn't aware of that.
But if you prefer that, we can find someone who prepares every merge window a
pull request.

Regards,
Matthias
Stephen Boyd Feb. 22, 2019, 7:48 a.m. UTC | #4
Quoting Matthias Brugger (2019-02-21 00:36:24)
> 
> 
> On 20/02/2019 20:18, Stephen Boyd wrote:
> > 
> > What's the merge plan here? Do you want me to apply these patches to clk
> > tree? Will someone be sending me a pull request for mediatek clk changes
> > this cycle? It's getting pretty late for much of anything making this
> > upcoming merge window.
> > 
> 
> As far as I can see, the clock patches are independent, so I think it is OK to
> take them. SCPSYS patches will go through my tree once they are in shape.

Ok great. When patches for clks are interspersed throughout the patch
series it makes me think that something later in the series depends on
something that isn't a clk patch so then I can't apply it.

> 
> Do you prefer to get pull requests for clock patches? I wasn't aware of that.
> But if you prefer that, we can find someone who prepares every merge window a
> pull request.
> 

I don't really care one way or the other about pull requests vs.
manually applying patches. It helps if someone wants to pick the patches
up and send them along when there are complex dependencies between the
clk patches and dts bits or something like that. It also helps if
there's someone else with knowledge of the particular SoC saying "these
are good, please pull these patches". Subsystem maintainers obviously
aren't experts in all SoCs and their various quirks, plus datasheets
aren't always so widely available, so sharing the load with SoC
maintainers who are familiar with the hardware usually makes a lot of
sense.

Otherwise, if you just want to put your "Reviewed-by" tag on any patches
that look good and are sane then I'll quickly understand that these
patches are good and that I should pick them up into the clk tree from
the list. Just please communicate one way or the other about patches
that you care about because it helps to know if they've gotten attention
or not.
Weiyi Lu Feb. 26, 2019, 4 a.m. UTC | #5
On Thu, 2019-02-21 at 23:48 -0800, Stephen Boyd wrote:
> Quoting Matthias Brugger (2019-02-21 00:36:24)
> > 
> > 
> > On 20/02/2019 20:18, Stephen Boyd wrote:
> > > 
> > > What's the merge plan here? Do you want me to apply these patches to clk
> > > tree? Will someone be sending me a pull request for mediatek clk changes
> > > this cycle? It's getting pretty late for much of anything making this
> > > upcoming merge window.
> > > 
> > 
> > As far as I can see, the clock patches are independent, so I think it is OK to
> > take them. SCPSYS patches will go through my tree once they are in shape.
> 
> Ok great. When patches for clks are interspersed throughout the patch
> series it makes me think that something later in the series depends on
> something that isn't a clk patch so then I can't apply it.
> 

Hi Stephen,

Sorry for making such complex dependencies between the clk patches and
others in this series. And just like Matthias mentioned, the clock
patches are independent from others. I could resend a clock-only series
right away if each clock patch in v4 is qualified to merge into
clk-next.
If there still some provide need to be fixed, please let me know. I'll
fix them and send v5 only for clock.

> > 
> > Do you prefer to get pull requests for clock patches? I wasn't aware of that.
> > But if you prefer that, we can find someone who prepares every merge window a
> > pull request.
> > 
> 
> I don't really care one way or the other about pull requests vs.
> manually applying patches. It helps if someone wants to pick the patches
> up and send them along when there are complex dependencies between the
> clk patches and dts bits or something like that. It also helps if
> there's someone else with knowledge of the particular SoC saying "these
> are good, please pull these patches". Subsystem maintainers obviously
> aren't experts in all SoCs and their various quirks, plus datasheets
> aren't always so widely available, so sharing the load with SoC
> maintainers who are familiar with the hardware usually makes a lot of
> sense.
> 
> Otherwise, if you just want to put your "Reviewed-by" tag on any patches
> that look good and are sane then I'll quickly understand that these
> patches are good and that I should pick them up into the clk tree from
> the list. Just please communicate one way or the other about patches
> that you care about because it helps to know if they've gotten attention
> or not.
>
Stephen Boyd Feb. 26, 2019, 5:45 p.m. UTC | #6
Quoting Weiyi Lu (2019-02-25 20:00:50)
> On Thu, 2019-02-21 at 23:48 -0800, Stephen Boyd wrote:
> > Quoting Matthias Brugger (2019-02-21 00:36:24)
> > > 
> > > 
> > > On 20/02/2019 20:18, Stephen Boyd wrote:
> > > > 
> > > > What's the merge plan here? Do you want me to apply these patches to clk
> > > > tree? Will someone be sending me a pull request for mediatek clk changes
> > > > this cycle? It's getting pretty late for much of anything making this
> > > > upcoming merge window.
> > > > 
> > > 
> > > As far as I can see, the clock patches are independent, so I think it is OK to
> > > take them. SCPSYS patches will go through my tree once they are in shape.
> > 
> > Ok great. When patches for clks are interspersed throughout the patch
> > series it makes me think that something later in the series depends on
> > something that isn't a clk patch so then I can't apply it.
> > 
> 
> Hi Stephen,
> 
> Sorry for making such complex dependencies between the clk patches and
> others in this series. And just like Matthias mentioned, the clock
> patches are independent from others. I could resend a clock-only series
> right away if each clock patch in v4 is qualified to merge into
> clk-next.
> If there still some provide need to be fixed, please let me know. I'll
> fix them and send v5 only for clock.

It looks like Matthias has some comments on the first patch that need to
be addressed. I looked over the rest of the clk patches and they look ok
at a quick glance. If you resend just the clk patches without the rest
then I can probably apply them for the upcoming merge window.