Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 02/12] arm64: dts: mt7622: add clock controller device nodes
From: sean.wang at mediatek.com @ 2018-01-04  9:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1515057696.git.sean.wang@mediatek.com>

From: Sean Wang <sean.wang@mediatek.com>

Add clock controller nodes for MT7622 and include header for topckgen,
infracfg, pericfg, apmixedsys, ethsys, sgmiisys, pciesys and ssusbsys
for those devices nodes to be added afterwards.

In addition, provides an oscillator node for the source of PLLs and dummy
clock for PWARP to complement missing support of clock gate for the
wrapper circuit in the driver.

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
---
 arch/arm64/boot/dts/mediatek/mt7622.dtsi | 76 ++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index b111fec..9730f0e 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -8,6 +8,8 @@
 
 #include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/mt7622-clk.h>
+#include <dt-bindings/reset/mt7622-reset.h>
 
 / {
 	compatible = "mediatek,mt7622";
@@ -48,6 +50,19 @@
 		clock-frequency = <280000000>;
 	};
 
+	pwrap_clk: dummy40m {
+		compatible = "fixed-clock";
+		clock-frequency = <40000000>;
+		#clock-cells = <0>;
+	};
+
+	clk25m: oscillator at 0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <25000000>;
+		clock-output-names = "clkxtal";
+	};
+
 	psci {
 		compatible  = "arm,psci-0.2";
 		method      = "smc";
@@ -78,6 +93,22 @@
 			      IRQ_TYPE_LEVEL_HIGH)>;
 	};
 
+	infracfg: infracfg at 10000000 {
+		compatible = "mediatek,mt7622-infracfg",
+			     "syscon";
+		reg = <0 0x10000000 0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	pericfg: pericfg at 10002000 {
+		compatible = "mediatek,mt7622-pericfg",
+			     "syscon";
+		reg = <0 0x10002000 0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
 	sysirq: interrupt-controller at 10200620 {
 		compatible = "mediatek,mt7622-sysirq",
 			     "mediatek,mt6577-sysirq";
@@ -87,6 +118,20 @@
 		reg = <0 0x10200620 0 0x20>;
 	};
 
+	apmixedsys: apmixedsys at 10209000 {
+		compatible = "mediatek,mt7622-apmixedsys",
+			     "syscon";
+		reg = <0 0x10209000 0 0x1000>;
+		#clock-cells = <1>;
+	};
+
+	topckgen: topckgen at 10210000 {
+		compatible = "mediatek,mt7622-topckgen",
+			     "syscon";
+		reg = <0 0x10210000 0 0x1000>;
+		#clock-cells = <1>;
+	};
+
 	gic: interrupt-controller at 10300000 {
 		compatible = "arm,gic-400";
 		interrupt-controller;
@@ -107,4 +152,35 @@
 		clock-names = "baud", "bus";
 		status = "disabled";
 	};
+
+	ssusbsys: ssusbsys at 1a000000 {
+		compatible = "mediatek,mt7622-ssusbsys",
+			     "syscon";
+		reg = <0 0x1a000000 0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	pciesys: pciesys at 1a100800 {
+		compatible = "mediatek,mt7622-pciesys",
+			     "syscon";
+		reg = <0 0x1a100800 0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	ethsys: syscon at 1b000000 {
+		compatible = "mediatek,mt7622-ethsys",
+			     "syscon";
+		reg = <0 0x1b000000 0 0x1000>;
+		#clock-cells = <1>;
+		#reset-cells = <1>;
+	};
+
+	sgmiisys: sgmiisys at 1b128000 {
+		compatible = "mediatek,mt7622-sgmiisys",
+			     "syscon";
+		reg = <0 0x1b128000 0 0x1000>;
+		#clock-cells = <1>;
+	};
 };
-- 
2.7.4

^ permalink raw reply related

* [PATCH 01/12] dt-bindings: clock: mediatek: add missing required #reset-cells
From: sean.wang at mediatek.com @ 2018-01-04  9:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1515057696.git.sean.wang@mediatek.com>

From: Sean Wang <sean.wang@mediatek.com>

All ethsys, pciesys and ssusbsys internally include reset controller, so
explicitly add back these missing cell definitions to related bindings
and examples.

Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
---
 Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt   | 2 ++
 Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt  | 2 ++
 Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
index 7aa3fa1..8f5335b 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
@@ -9,6 +9,7 @@ Required Properties:
 	- "mediatek,mt2701-ethsys", "syscon"
 	- "mediatek,mt7622-ethsys", "syscon"
 - #clock-cells: Must be 1
+- #reset-cells: Must be 1
 
 The ethsys controller uses the common clk binding from
 Documentation/devicetree/bindings/clock/clock-bindings.txt
@@ -20,4 +21,5 @@ ethsys: clock-controller at 1b000000 {
 	compatible = "mediatek,mt2701-ethsys", "syscon";
 	reg = <0 0x1b000000 0 0x1000>;
 	#clock-cells = <1>;
+	#reset-cells = <1>;
 };
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt
index d5d5f12..7fe5dc6 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,pciesys.txt
@@ -8,6 +8,7 @@ Required Properties:
 - compatible: Should be:
 	- "mediatek,mt7622-pciesys", "syscon"
 - #clock-cells: Must be 1
+- #reset-cells: Must be 1
 
 The PCIESYS controller uses the common clk binding from
 Documentation/devicetree/bindings/clock/clock-bindings.txt
@@ -19,4 +20,5 @@ pciesys: pciesys at 1a100800 {
 	compatible = "mediatek,mt7622-pciesys", "syscon";
 	reg = <0 0x1a100800 0 0x1000>;
 	#clock-cells = <1>;
+	#reset-cells = <1>;
 };
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt
index 00760019..b8184da 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ssusbsys.txt
@@ -8,6 +8,7 @@ Required Properties:
 - compatible: Should be:
 	- "mediatek,mt7622-ssusbsys", "syscon"
 - #clock-cells: Must be 1
+- #reset-cells: Must be 1
 
 The SSUSBSYS controller uses the common clk binding from
 Documentation/devicetree/bindings/clock/clock-bindings.txt
@@ -19,4 +20,5 @@ ssusbsys: ssusbsys at 1a000000 {
 	compatible = "mediatek,mt7622-ssusbsys", "syscon";
 	reg = <0 0x1a000000 0 0x1000>;
 	#clock-cells = <1>;
+	#reset-cells = <1>;
 };
-- 
2.7.4

^ permalink raw reply related

* [PATCH 00/12] add dts nodes to MT7622 SoC
From: sean.wang at mediatek.com @ 2018-01-04  9:40 UTC (permalink / raw)
  To: linux-arm-kernel

From: Sean Wang <sean.wang@mediatek.com>

add dts nodes to MT7622 SoC and related rfb1 board

Ryder Lee (2):
  arm64: dts: mt7622: add PCIe device nodes
  arm64: dts: mt7622: add SATA device nodes

Sean Wang (10):
  dt-bindings: clock: mediatek: add missing required #reset-cells
  arm64: dts: mt7622: add clock controller device nodes
  arm64: dts: mt7622: add power domain controller device nodes
  arm64: dts: mt7622: add pinctrl related device nodes
  arm64: dts: mt7622: add PMIC MT6380 related nodes
  arm64: dts: mt7622: add cpufreq related device nodes
  arm64: dts: mt7622: turn uart0 clock to real ones
  arm64: dts: mt7622: add SoC and peripheral related device nodes
  arm64: dts: mt7622: add flash related device nodes
  arm64: dts: mt7622: add ethernet device nodes

 .../bindings/arm/mediatek/mediatek,ethsys.txt      |   2 +
 .../bindings/arm/mediatek/mediatek,pciesys.txt     |   2 +
 .../bindings/arm/mediatek/mediatek,ssusbsys.txt    |   2 +
 arch/arm64/boot/dts/mediatek/mt6380.dtsi           |  91 ++++
 arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts       | 337 +++++++++++++
 arch/arm64/boot/dts/mediatek/mt7622.dtsi           | 533 ++++++++++++++++++++-
 6 files changed, 962 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6380.dtsi

-- 
2.7.4

^ permalink raw reply

* [PATCH] ARM: imx_v6_v7_defconfig: select the CONFIG_CPUFREQ_DT
From: Fabio Estevam @ 2018-01-04  9:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1515080206-1941-1-git-send-email-Anson.Huang@nxp.com>

Hi Anson,

On Thu, Jan 4, 2018 at 1:36 PM, Anson Huang <Anson.Huang@nxp.com> wrote:
> Select CONFIG_CPUFREQ_DT by default to enable
> cpu-freq driver for i.MX7D.
>
> The rest changes are generated by "make savedefconfig".

Please generate this patch on top of Shawn's for-next branch.

There is already a commit there that does the 'make savedefconfig' cleanup.

Thanks

^ permalink raw reply

* [PATCH] arm64: Allocate elfcorehdr & crashkernel mem before any reservation
From: Poonam Aggrwal @ 2018-01-04  9:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1515062300-8246-1-git-send-email-poonam.aggrwal@codeaurora.org>


> -----Original Message-----
> From: Poonam Aggrwal [mailto:poonam.aggrwal at codeaurora.org]
> Sent: Thursday, January 04, 2018 4:08 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: takahiro.akashi at linaro.org; james.morse at arm.com;
> will.deacon at arm.com; Poonam Aggrwal <poonam.aggrwal@nxp.com>; G.h.
> Gao <guanhua.gao@nxp.com>; Abhimanyu Saini <abhimanyu.saini@nxp.com>
> Subject: [PATCH] arm64: Allocate elfcorehdr & crashkernel mem before any
> reservation
> 
> From: Poonam Aggrwal <poonam.aggrwal@nxp.com>
> 
Please ignore this patch; will send another one with correct email address.

Regards
Poonam
> 2.7.4

^ permalink raw reply

* [RFC] pwm-backlight: Allow backlight to remain disabled on boot
From: hl @ 2018-01-04  9:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <6a77b1bc-29fa-2bc5-baeb-0cba8747137a@ti.com>

Hi


On Thursday, January 04, 2018 04:22 PM, Peter Ujfalusi wrote:
> Hi,
>
> On 2018-01-04 04:18, hl wrote:
>> Hi All,
>>
>>  ??? Since many panel power sequence request backlight stay disable
>>
>> before panel power ready, but with now pwm-backlight drvier, it default to
>>
>> enable backlight when pwm-backlight probe, it mess up the panel power
>> sequence.
>>
>> So we need this patch. This patch have been fly for a long time, does
>> anyone have plan
>>
>> to merge it?
> you should not need this anymore since we have:
> 892c7788c724backlight: pwm_bl: Fix GPIO out for unimplemented
> .get_direction()
>
> d1b812945750 backlight: pwm_bl: Check the PWM state for initial
> backlight power state
>
> 7613c922315e backlight: pwm_bl: Move the checks for initial power state
> to a separate function
>
> With these in place the backlight will be kept disabled if it was
> disabled during boot _if_ you have booted via DT _and_ you have a
> phandle pointing to the backlight node (implying that the backlight is
> managed by the display driver).
Oh, thanks for reminding me.
>
>>
>> On Thursday, July 31, 2014 07:42 PM, Thierry Reding wrote:
>>> From: Thierry Reding <treding@nvidia.com>
>>>
>>> The default for backlight devices is to be enabled immediately when
>>> registering with the backlight core. This can be useful for setups that
>>> use a simple framebuffer device and where the backlight cannot otherwise
>>> be hooked up to the panel.
>>>
>>> However, when dealing with more complex setups, such as those of recent
>>> ARM SoCs, this can be problematic. Since the backlight is usually setup
>>> separately from the display controller, the probe order is not usually
>>> deterministic. That can lead to situations where the backlight will be
>>> powered up and the panel will show an uninitialized framebuffer.
>>>
>>> Furthermore, subsystems such as DRM have advanced functionality to set
>>> the power mode of a panel. In order to allow such setups to power up the
>>> panel at exactly the right moment, a way is needed to prevent the
>>> backlight core from powering the backlight up automatically when it is
>>> registered.
>>>
>>> This commit introduces a new boot_off field in the platform data (and
>>> also implements getting the same information from device tree). When set
>>> the initial backlight power mode will be set to "off".
>>>
>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>> ---
>>> I've been meaning to send this for a while but was always holding back
>>> because of the indoctrination that this type of configuration shouldn't
>>> be part of device tree. However this issue was recently raised again in
>>> the context of power up sequences for display panels. As described above
>>> the issue is that panel datasheets recommend that the backlight attached
>>> to a panel be turned on at the very last step to avoid visual glitches
>>> during the panel's power up sequence. With the current implementation it
>>> is typical for the backlight to be probed before the display panel. That
>>> has, in many cases, the side-effect of enabling the backlight, therefore
>>> making the screen content visible before it's actually initialized.
>>>
>>> Some panels come up with random garbage when uninitialized, others show
>>> all white. With some luck the panel will be all black and users won't
>>> really notice.
>>>
>>> This patch is an attempt to enable boards to override the default of
>>> turning on the backlight for the pwm-backlight driver. I'm not sure if
>>> there was a specific reason to turn on the backlight by default when
>>> this driver was initially written, but the fact is that since it has
>>> pretty much always been like this we can't really go and change the
>>> default, otherwise a lot of people may end up with no backlight and no
>>> clue as to how to enable it. So the only reasonable thing we can do is
>>> to keep the old behaviour and give new boards a way to override it if
>>> they know that some other part of the stack will enable it at the right
>>> moment.
>>>
>>>  ? .../devicetree/bindings/video/backlight/pwm-backlight.txt???????? | 1 +
>>>  ? drivers/video/backlight/pwm_bl.c????????????????????????????????? |
>>> 8 ++++++++
>>>  ? include/linux/pwm_backlight.h???????????????????????????????????? |
>>> 2 ++
>>>  ? 3 files changed, 11 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>>> b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>>> index 764db86d441a..65e001a1733d 100644
>>> --- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>>> +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>>> @@ -17,6 +17,7 @@ Optional properties:
>>>  ???????????????? "pwms" property (see PWM binding[0])
>>>  ??? - enable-gpios: contains a single GPIO specifier for the GPIO
>>> which enables
>>>  ??????????????????? and disables the backlight (see GPIO binding[1])
>>> +? - backlight-boot-off: keep the backlight disabled on boot
>>>  ? ? [0]: Documentation/devicetree/bindings/pwm/pwm.txt
>>>  ? [1]: Documentation/devicetree/bindings/gpio/gpio.txt
>>> diff --git a/drivers/video/backlight/pwm_bl.c
>>> b/drivers/video/backlight/pwm_bl.c
>>> index d7a3d13e72ec..62adfc9d37a7 100644
>>> --- a/drivers/video/backlight/pwm_bl.c
>>> +++ b/drivers/video/backlight/pwm_bl.c
>>> @@ -173,6 +173,8 @@ static int pwm_backlight_parse_dt(struct device *dev,
>>>  ????????? data->max_brightness--;
>>>  ????? }
>>>  ? +??? data->boot_off = of_property_read_bool(node,
>>> "backlight-boot-off");
>>> +
>>>  ????? return 0;
>>>  ? }
>>>  ? @@ -317,6 +319,12 @@ static int pwm_backlight_probe(struct
>>> platform_device *pdev)
>>>  ????? }
>>>  ? ????? bl->props.brightness = data->dft_brightness;
>>> +
>>> +??? if (data->boot_off)
>>> +??????? bl->props.power = FB_BLANK_POWERDOWN;
>>> +??? else
>>> +??????? bl->props.power = FB_BLANK_UNBLANK;
>>> +
>>>  ????? backlight_update_status(bl);
>>>  ? ????? platform_set_drvdata(pdev, bl);
>>> diff --git a/include/linux/pwm_backlight.h
>>> b/include/linux/pwm_backlight.h
>>> index efdd9227a49c..1fc14989da4a 100644
>>> --- a/include/linux/pwm_backlight.h
>>> +++ b/include/linux/pwm_backlight.h
>>> @@ -15,6 +15,8 @@ struct platform_pwm_backlight_data {
>>>  ????? unsigned int *levels;
>>>  ????? /* TODO remove once all users are switched to gpiod_* API */
>>>  ????? int enable_gpio;
>>> +??? bool boot_off;
>>> +
>>>  ????? int (*init)(struct device *dev);
>>>  ????? int (*notify)(struct device *dev, int brightness);
>>>  ????? void (*notify_after)(struct device *dev, int brightness);
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> - P?ter
>
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
>

^ permalink raw reply

* [RESEND PATCH v2 14/15] ASoC: qcom: apq8096: Add db820c machine driver
From: Srinivas Kandagatla @ 2018-01-04  9:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20180103194151.GA21040@codeaurora.org>



On 03/01/18 19:41, Stephen Boyd wrote:
>>>> +	ret = dma_coerce_mask_and_coherent(card->dev, DMA_BIT_MASK(32));
>>> Why do we need to do this? Can you add some sort of comment in the code
>>> about why?
>> Even though dsp supports 64 bit addresses, but the sid sits at
>> offset of 32, which brings this restriction of supporting only 32
>> bit iova.
>>
> Doesn't the dsp have an iommu in place to make the address
> translation from 64 to 32 bits transparent? I thought this was
> what dma-ranges and iommu binding was for, but I'm not well
> versed on all the details here.
Thanks for reminding, dma-ranges would work too, I will give that a go 
in next version.

--srini

^ permalink raw reply

* [PATCH 30/67] dma-direct: retry allocations using GFP_DMA for small masks
From: Christoph Hellwig @ 2018-01-04  9:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <f6139b03-0a4a-a9fe-4818-9b0bccf419e4@arm.com>

On Tue, Jan 02, 2018 at 04:43:15PM +0000, Vladimir Murzin wrote:
> On 29/12/17 08:18, Christoph Hellwig wrote:
> > If we got back an allocation that wasn't inside the support coherent mask,
> > retry the allocation using GFP_DMA.
> > 
> > Based on the x86 code.
> > 
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> >  lib/dma-direct.c | 25 ++++++++++++++++++++++++-
> >  1 file changed, 24 insertions(+), 1 deletion(-)
> > 
> > diff --git a/lib/dma-direct.c b/lib/dma-direct.c
> > index ab81de3ac1d3..f8467cb3d89a 100644
> > --- a/lib/dma-direct.c
> > +++ b/lib/dma-direct.c
> > @@ -28,6 +28,11 @@ check_addr(struct device *dev, dma_addr_t dma_addr, size_t size,
> >  	return true;
> >  }
> >  
> > +static bool dma_coherent_ok(struct device *dev, phys_addr_t phys, size_t size)
> > +{
> > +	return phys_to_dma(dev, phys) + size <= dev->coherent_dma_mask;
> 
> Shouldn't it be: phys_to_dma(dev, phys) + size - 1 <= dev->coherent_dma_mask ?

Yes, I think it should.  The existing code was blindly copy and pasted
from x86.

> > +	if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
> > +		__free_pages(page, page_order);
> > +		page = NULL;
> > +
> > +		if (dev->coherent_dma_mask < DMA_BIT_MASK(32) &&
> > +		    !(gfp & GFP_DMA)) {
> > +			gfp = (gfp & ~GFP_DMA32) | GFP_DMA;
> > +			goto again;
> 
> Shouldn't we limit number of attempts?

We only retty once anyway, due to the !GFP_DMA check first and then
ORing in GFP_DMA.

^ permalink raw reply

* [PATCH 02/67] alpha: mark jensen as broken
From: Christoph Hellwig @ 2018-01-04  8:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAMuHMdUXSMuQ=RoZp86CODVk5Ubd3R+jtqOur_Uqnu+7h_m9AA@mail.gmail.com>

On Tue, Jan 02, 2018 at 11:36:00AM +0100, Geert Uytterhoeven wrote:
> Hi Christoph,
> 
> On Fri, Dec 29, 2017 at 9:18 AM, Christoph Hellwig <hch@lst.de> wrote:
> > CONFIG_ALPHA_JENSEN has failed to compile since commit aca05038
> > ("alpha/dma: use common noop dma ops"), so mark it as broken.
> 
> unknown revision or path not in the working tree.
> Ah, you dropped the leading "6":
> 6aca0503847f6329460b15b3ab2b0e30bb752793
> is less than 2 years old, though.

I'll fix the reference.

But 23 month of a whole sub-architecture not compiling should still be
enough to mark it broken.

^ permalink raw reply

* [PATCH 27/67] dma-direct: add dma address sanity checks
From: Christoph Hellwig @ 2018-01-04  8:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAMuHMdWg3PnTXezMCcr3oGf-83-cjvcj4wGiPk7j2pY1Tgzo9Q@mail.gmail.com>

On Fri, Dec 29, 2017 at 03:12:25PM +0100, Geert Uytterhoeven wrote:
> > +check_addr(struct device *dev, dma_addr_t dma_addr, size_t size,
> > +               const char *caller)
> > +{
> > +       if (unlikely(dev && !dma_capable(dev, dma_addr, size))) {
> > +               if (*dev->dma_mask >= DMA_BIT_MASK(32)) {
> > +                       dev_err(dev,
> > +                               "%s: overflow %llx+%zu of device mask %llx\n",
> 
> Please use "%pad" to format dma_addr_t ...
> 
> > +                               caller, (long long)dma_addr, size,
> 
> ... and use &dma_addr.
> 
> > +                               (long long)*dev->dma_mask);
> 
> This cast is not needed, as u64 is unsigned long long in kernelspace on
> all architectures.

Thanks, fixed.

^ permalink raw reply

* [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
From: Christoph Hellwig @ 2018-01-04  8:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <878tdgtwzp.fsf@concordia.ellerman.id.au>

On Tue, Jan 02, 2018 at 08:45:30PM +1100, Michael Ellerman wrote:
> Christoph Hellwig <hch@lst.de> writes:
> 
> > We want to use the dma_direct_ namespace for a generic implementation,
> > so rename powerpc to the second best choice: dma_nommu_.
> 
> I'm not a fan of "nommu". Some of the users of direct ops *are* using an
> IOMMU, they're just setting up a 1:1 mapping once at init time, rather
> than mapping dynamically.
> 
> Though I don't have a good idea for a better name, maybe "1to1",
> "linear", "premapped" ?

It seems like a nice counter part to the dma_iommu_ops used just about
anywhere else in ppc.

But I'll happily take any maintainer bike shed decision for the next
series.  Remember that in a merge window or two it will hopefully
go away in favor of the new generic dma_direct ops.

^ permalink raw reply

* [PATCH 16/67] powerpc: rename dma_direct_ to dma_nommu_
From: Christoph Hellwig @ 2018-01-04  8:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAGRGNgV+DnZAAtiE5oe8rxp4=_JHJrtSQc8F5jrgN0rgYKfwjA@mail.gmail.com>

On Wed, Jan 03, 2018 at 07:19:46PM +1100, Julian Calaby wrote:
> If this is indeed a linear mapping, can we just remove this and
> replace it with the new "generic" mapping being introduced by this
> patchset?

That is the long-term plan.  But as the powerpc one includes support
for non-coherent DMA it will have to wait for the next batch.

^ permalink raw reply

* [PATCH 17/67] microblaze: rename dma_direct to dma_microblaze
From: Christoph Hellwig @ 2018-01-04  8:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAGRGNgW1qwLcCAvU2Jc=3_7b-0Bu016to3cQUgVsc+ca0No_6g@mail.gmail.com>

On Fri, Dec 29, 2017 at 09:11:56PM +1100, Julian Calaby wrote:
> Hi Christoph,
> 
> On Fri, Dec 29, 2017 at 7:18 PM, Christoph Hellwig <hch@lst.de> wrote:
> > This frees the dma_direct_* namespace for a generic implementation.
> 
> Don't you mean "dma_nommu" not "dma_microblaze" in the subject line?

Yes, thanks.

^ permalink raw reply

* [RFC] pwm-backlight: Allow backlight to remain disabled on boot
From: Peter Ujfalusi @ 2018-01-04  8:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <6b14a283-0ded-e22c-8f81-5c241ad57463@rock-chips.com>

Hi,

On 2018-01-04 04:18, hl wrote:
> Hi All,
> 
> ??? Since many panel power sequence request backlight stay disable
> 
> before panel power ready, but with now pwm-backlight drvier, it default to
> 
> enable backlight when pwm-backlight probe, it mess up the panel power
> sequence.
> 
> So we need this patch. This patch have been fly for a long time, does
> anyone have plan
> 
> to merge it?

you should not need this anymore since we have:
892c7788c724backlight: pwm_bl: Fix GPIO out for unimplemented
.get_direction()

d1b812945750 backlight: pwm_bl: Check the PWM state for initial
backlight power state

7613c922315e backlight: pwm_bl: Move the checks for initial power state
to a separate function

With these in place the backlight will be kept disabled if it was
disabled during boot _if_ you have booted via DT _and_ you have a
phandle pointing to the backlight node (implying that the backlight is
managed by the display driver).

> 
> 
> On Thursday, July 31, 2014 07:42 PM, Thierry Reding wrote:
>> From: Thierry Reding <treding@nvidia.com>
>>
>> The default for backlight devices is to be enabled immediately when
>> registering with the backlight core. This can be useful for setups that
>> use a simple framebuffer device and where the backlight cannot otherwise
>> be hooked up to the panel.
>>
>> However, when dealing with more complex setups, such as those of recent
>> ARM SoCs, this can be problematic. Since the backlight is usually setup
>> separately from the display controller, the probe order is not usually
>> deterministic. That can lead to situations where the backlight will be
>> powered up and the panel will show an uninitialized framebuffer.
>>
>> Furthermore, subsystems such as DRM have advanced functionality to set
>> the power mode of a panel. In order to allow such setups to power up the
>> panel at exactly the right moment, a way is needed to prevent the
>> backlight core from powering the backlight up automatically when it is
>> registered.
>>
>> This commit introduces a new boot_off field in the platform data (and
>> also implements getting the same information from device tree). When set
>> the initial backlight power mode will be set to "off".
>>
>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>> ---
>> I've been meaning to send this for a while but was always holding back
>> because of the indoctrination that this type of configuration shouldn't
>> be part of device tree. However this issue was recently raised again in
>> the context of power up sequences for display panels. As described above
>> the issue is that panel datasheets recommend that the backlight attached
>> to a panel be turned on at the very last step to avoid visual glitches
>> during the panel's power up sequence. With the current implementation it
>> is typical for the backlight to be probed before the display panel. That
>> has, in many cases, the side-effect of enabling the backlight, therefore
>> making the screen content visible before it's actually initialized.
>>
>> Some panels come up with random garbage when uninitialized, others show
>> all white. With some luck the panel will be all black and users won't
>> really notice.
>>
>> This patch is an attempt to enable boards to override the default of
>> turning on the backlight for the pwm-backlight driver. I'm not sure if
>> there was a specific reason to turn on the backlight by default when
>> this driver was initially written, but the fact is that since it has
>> pretty much always been like this we can't really go and change the
>> default, otherwise a lot of people may end up with no backlight and no
>> clue as to how to enable it. So the only reasonable thing we can do is
>> to keep the old behaviour and give new boards a way to override it if
>> they know that some other part of the stack will enable it at the right
>> moment.
>>
>> ? .../devicetree/bindings/video/backlight/pwm-backlight.txt???????? | 1 +
>> ? drivers/video/backlight/pwm_bl.c????????????????????????????????? |
>> 8 ++++++++
>> ? include/linux/pwm_backlight.h???????????????????????????????????? |
>> 2 ++
>> ? 3 files changed, 11 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>> b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>> index 764db86d441a..65e001a1733d 100644
>> --- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>> +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>> @@ -17,6 +17,7 @@ Optional properties:
>> ???????????????? "pwms" property (see PWM binding[0])
>> ??? - enable-gpios: contains a single GPIO specifier for the GPIO
>> which enables
>> ??????????????????? and disables the backlight (see GPIO binding[1])
>> +? - backlight-boot-off: keep the backlight disabled on boot
>> ? ? [0]: Documentation/devicetree/bindings/pwm/pwm.txt
>> ? [1]: Documentation/devicetree/bindings/gpio/gpio.txt
>> diff --git a/drivers/video/backlight/pwm_bl.c
>> b/drivers/video/backlight/pwm_bl.c
>> index d7a3d13e72ec..62adfc9d37a7 100644
>> --- a/drivers/video/backlight/pwm_bl.c
>> +++ b/drivers/video/backlight/pwm_bl.c
>> @@ -173,6 +173,8 @@ static int pwm_backlight_parse_dt(struct device *dev,
>> ????????? data->max_brightness--;
>> ????? }
>> ? +??? data->boot_off = of_property_read_bool(node,
>> "backlight-boot-off");
>> +
>> ????? return 0;
>> ? }
>> ? @@ -317,6 +319,12 @@ static int pwm_backlight_probe(struct
>> platform_device *pdev)
>> ????? }
>> ? ????? bl->props.brightness = data->dft_brightness;
>> +
>> +??? if (data->boot_off)
>> +??????? bl->props.power = FB_BLANK_POWERDOWN;
>> +??? else
>> +??????? bl->props.power = FB_BLANK_UNBLANK;
>> +
>> ????? backlight_update_status(bl);
>> ? ????? platform_set_drvdata(pdev, bl);
>> diff --git a/include/linux/pwm_backlight.h
>> b/include/linux/pwm_backlight.h
>> index efdd9227a49c..1fc14989da4a 100644
>> --- a/include/linux/pwm_backlight.h
>> +++ b/include/linux/pwm_backlight.h
>> @@ -15,6 +15,8 @@ struct platform_pwm_backlight_data {
>> ????? unsigned int *levels;
>> ????? /* TODO remove once all users are switched to gpiod_* API */
>> ????? int enable_gpio;
>> +??? bool boot_off;
>> +
>> ????? int (*init)(struct device *dev);
>> ????? int (*notify)(struct device *dev, int brightness);
>> ????? void (*notify_after)(struct device *dev, int brightness);
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

- P?ter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply

* [PATCH v1 6/6] clk: mediatek: add audsys support for MT2701
From: Ryder Lee @ 2018-01-04  7:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1515038387.git.ryder.lee@mediatek.com>

Add clock driver support for MT2701 audsys.

Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
 drivers/clk/mediatek/Kconfig          |   6 ++
 drivers/clk/mediatek/Makefile         |   1 +
 drivers/clk/mediatek/clk-mt2701-aud.c | 174 ++++++++++++++++++++++++++++++++++
 3 files changed, 181 insertions(+)
 create mode 100644 drivers/clk/mediatek/clk-mt2701-aud.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 59dc0aa..efb6f58 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -50,6 +50,12 @@ config COMMON_CLK_MT2701_BDPSYS
 	---help---
 	  This driver supports Mediatek MT2701 bdpsys clocks.
 
+config COMMON_CLK_MT2701_AUDSYS
+	bool "Clock driver for Mediatek MT2701 audsys"
+	depends on COMMON_CLK_MT2701
+	---help---
+	  This driver supports Mediatek MT2701 audsys clocks.
+
 config COMMON_CLK_MT2712
 	bool "Clock driver for Mediatek MT2712"
 	depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index c421ffc..c4ab7d3 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
 obj-$(CONFIG_COMMON_CLK_MT6797_VDECSYS) += clk-mt6797-vdec.o
 obj-$(CONFIG_COMMON_CLK_MT6797_VENCSYS) += clk-mt6797-venc.o
 obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
+obj-$(CONFIG_COMMON_CLK_MT2701_AUDSYS) += clk-mt2701-aud.o
 obj-$(CONFIG_COMMON_CLK_MT2701_BDPSYS) += clk-mt2701-bdp.o
 obj-$(CONFIG_COMMON_CLK_MT2701_ETHSYS) += clk-mt2701-eth.o
 obj-$(CONFIG_COMMON_CLK_MT2701_HIFSYS) += clk-mt2701-hif.o
diff --git a/drivers/clk/mediatek/clk-mt2701-aud.c b/drivers/clk/mediatek/clk-mt2701-aud.c
new file mode 100644
index 0000000..eafc18e
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt2701-aud.c
@@ -0,0 +1,174 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Ryder Lee <ryder.lee@mediatek.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+#include <linux/clk-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+
+#include "clk-mtk.h"
+#include "clk-gate.h"
+
+#include <dt-bindings/clock/mt2701-clk.h>
+
+#define GATE_AUDIO0(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &audio0_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_no_setclr,	\
+	}
+
+#define GATE_AUDIO1(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &audio1_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_no_setclr,	\
+	}
+
+#define GATE_AUDIO2(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &audio2_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_no_setclr,	\
+	}
+
+#define GATE_AUDIO3(_id, _name, _parent, _shift) {	\
+		.id = _id,				\
+		.name = _name,				\
+		.parent_name = _parent,			\
+		.regs = &audio3_cg_regs,			\
+		.shift = _shift,			\
+		.ops = &mtk_clk_gate_ops_no_setclr,	\
+	}
+
+static const struct mtk_gate_regs audio0_cg_regs = {
+	.set_ofs = 0x0,
+	.clr_ofs = 0x0,
+	.sta_ofs = 0x0,
+};
+
+static const struct mtk_gate_regs audio1_cg_regs = {
+	.set_ofs = 0x10,
+	.clr_ofs = 0x10,
+	.sta_ofs = 0x10,
+};
+
+static const struct mtk_gate_regs audio2_cg_regs = {
+	.set_ofs = 0x14,
+	.clr_ofs = 0x14,
+	.sta_ofs = 0x14,
+};
+
+static const struct mtk_gate_regs audio3_cg_regs = {
+	.set_ofs = 0x634,
+	.clr_ofs = 0x634,
+	.sta_ofs = 0x634,
+};
+
+static const struct mtk_gate audio_clks[] = {
+	/* AUDIO0 */
+	GATE_AUDIO0(CLK_AUD_AFE, "audio_afe", "aud_intbus_sel", 2),
+	GATE_AUDIO0(CLK_AUD_HDMI, "audio_hdmi", "audpll_sel", 20),
+	GATE_AUDIO0(CLK_AUD_SPDF, "audio_spdf", "audpll_sel", 21),
+	GATE_AUDIO0(CLK_AUD_SPDF2, "audio_spdf2", "audpll_sel", 22),
+	GATE_AUDIO0(CLK_AUD_APLL, "audio_apll", "audpll_sel", 23),
+	/* AUDIO1 */
+	GATE_AUDIO1(CLK_AUD_I2SIN1, "audio_i2sin1", "aud_mux1_sel", 0),
+	GATE_AUDIO1(CLK_AUD_I2SIN2, "audio_i2sin2", "aud_mux1_sel", 1),
+	GATE_AUDIO1(CLK_AUD_I2SIN3, "audio_i2sin3", "aud_mux1_sel", 2),
+	GATE_AUDIO1(CLK_AUD_I2SIN4, "audio_i2sin4", "aud_mux1_sel", 3),
+	GATE_AUDIO1(CLK_AUD_I2SIN5, "audio_i2sin5", "aud_mux1_sel", 4),
+	GATE_AUDIO1(CLK_AUD_I2SIN6, "audio_i2sin6", "aud_mux1_sel", 5),
+	GATE_AUDIO1(CLK_AUD_I2SO1, "audio_i2so1", "aud_mux1_sel", 6),
+	GATE_AUDIO1(CLK_AUD_I2SO2, "audio_i2so2", "aud_mux1_sel", 7),
+	GATE_AUDIO1(CLK_AUD_I2SO3, "audio_i2so3", "aud_mux1_sel", 8),
+	GATE_AUDIO1(CLK_AUD_I2SO4, "audio_i2so4", "aud_mux1_sel", 9),
+	GATE_AUDIO1(CLK_AUD_I2SO5, "audio_i2so5", "aud_mux1_sel", 10),
+	GATE_AUDIO1(CLK_AUD_I2SO6, "audio_i2so6", "aud_mux1_sel", 11),
+	GATE_AUDIO1(CLK_AUD_ASRCI1, "audio_asrci1", "asm_h_sel", 12),
+	GATE_AUDIO1(CLK_AUD_ASRCI2, "audio_asrci2", "asm_h_sel", 13),
+	GATE_AUDIO1(CLK_AUD_ASRCO1, "audio_asrco1", "asm_h_sel", 14),
+	GATE_AUDIO1(CLK_AUD_ASRCO2, "audio_asrco2", "asm_h_sel", 15),
+	GATE_AUDIO1(CLK_AUD_INTDIR, "audio_intdir", "intdir_sel", 20),
+	GATE_AUDIO1(CLK_AUD_A1SYS, "audio_a1sys", "aud_mux1_sel", 21),
+	GATE_AUDIO1(CLK_AUD_A2SYS, "audio_a2sys", "aud_mux2_sel", 22),
+	GATE_AUDIO1(CLK_AUD_AFE_CONN, "audio_afe_conn", "aud_mux1_sel", 23),
+	GATE_AUDIO1(CLK_AUD_AFE_MRGIF, "audio_afe_mrgif", "aud_mux1_sel", 25),
+	/* AUDIO2 */
+	GATE_AUDIO2(CLK_AUD_MMIF_UL1, "audio_ul1", "aud_mux1_sel", 0),
+	GATE_AUDIO2(CLK_AUD_MMIF_UL2, "audio_ul2", "aud_mux1_sel", 1),
+	GATE_AUDIO2(CLK_AUD_MMIF_UL3, "audio_ul3", "aud_mux1_sel", 2),
+	GATE_AUDIO2(CLK_AUD_MMIF_UL4, "audio_ul4", "aud_mux1_sel", 3),
+	GATE_AUDIO2(CLK_AUD_MMIF_UL5, "audio_ul5", "aud_mux1_sel", 4),
+	GATE_AUDIO2(CLK_AUD_MMIF_UL6, "audio_ul6", "aud_mux1_sel", 5),
+	GATE_AUDIO2(CLK_AUD_MMIF_DL1, "audio_dl1", "aud_mux1_sel", 6),
+	GATE_AUDIO2(CLK_AUD_MMIF_DL2, "audio_dl2", "aud_mux1_sel", 7),
+	GATE_AUDIO2(CLK_AUD_MMIF_DL3, "audio_dl3", "aud_mux1_sel", 8),
+	GATE_AUDIO2(CLK_AUD_MMIF_DL4, "audio_dl4", "aud_mux1_sel", 9),
+	GATE_AUDIO2(CLK_AUD_MMIF_DL5, "audio_dl5", "aud_mux1_sel", 10),
+	GATE_AUDIO2(CLK_AUD_MMIF_DL6, "audio_dl6", "aud_mux1_sel", 11),
+	GATE_AUDIO2(CLK_AUD_MMIF_DLMCH, "audio_dlmch", "aud_mux1_sel", 12),
+	GATE_AUDIO2(CLK_AUD_MMIF_ARB1, "audio_arb1", "aud_mux1_sel", 13),
+	GATE_AUDIO2(CLK_AUD_MMIF_AWB1, "audio_awb", "aud_mux1_sel", 14),
+	GATE_AUDIO2(CLK_AUD_MMIF_AWB2, "audio_awb2", "aud_mux1_sel", 15),
+	GATE_AUDIO2(CLK_AUD_MMIF_DAI, "audio_dai", "aud_mux1_sel", 16),
+	/* AUDIO3 */
+	GATE_AUDIO3(CLK_AUD_ASRCI3, "audio_asrci3", "asm_h_sel", 2),
+	GATE_AUDIO3(CLK_AUD_ASRCI4, "audio_asrci4", "asm_h_sel", 3),
+	GATE_AUDIO3(CLK_AUD_ASRCI5, "audio_asrci5", "asm_h_sel", 4),
+	GATE_AUDIO3(CLK_AUD_ASRCI6, "audio_asrci6", "asm_h_sel", 5),
+	GATE_AUDIO3(CLK_AUD_ASRCO3, "audio_asrco3", "asm_h_sel", 6),
+	GATE_AUDIO3(CLK_AUD_ASRCO4, "audio_asrco4", "asm_h_sel", 7),
+	GATE_AUDIO3(CLK_AUD_ASRCO5, "audio_asrco5", "asm_h_sel", 8),
+	GATE_AUDIO3(CLK_AUD_ASRCO6, "audio_asrco6", "asm_h_sel", 9),
+	GATE_AUDIO3(CLK_AUD_MEM_ASRC1, "audio_mem_asrc1", "asm_h_sel", 10),
+	GATE_AUDIO3(CLK_AUD_MEM_ASRC2, "audio_mem_asrc2", "asm_h_sel", 11),
+	GATE_AUDIO3(CLK_AUD_MEM_ASRC3, "audio_mem_asrc3", "asm_h_sel", 12),
+	GATE_AUDIO3(CLK_AUD_MEM_ASRC4, "audio_mem_asrc4", "asm_h_sel", 13),
+	GATE_AUDIO3(CLK_AUD_MEM_ASRC5, "audio_mem_asrc5", "asm_h_sel", 14),
+};
+
+static const struct of_device_id of_match_clk_mt2701_aud[] = {
+	{ .compatible = "mediatek,mt2701-audsys", },
+	{}
+};
+
+static int clk_mt2701_aud_probe(struct platform_device *pdev)
+{
+	struct clk_onecell_data *clk_data;
+	struct device_node *node = pdev->dev.of_node;
+	int r;
+
+	clk_data = mtk_alloc_clk_data(CLK_AUD_NR);
+
+	mtk_clk_register_gates(node, audio_clks, ARRAY_SIZE(audio_clks),
+				   clk_data);
+
+	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+	if (r)
+		dev_err(&pdev->dev,
+			"could not register clock provider: %s: %d\n",
+			pdev->name, r);
+
+	return r;
+}
+
+static struct platform_driver clk_mt2701_aud_drv = {
+	.probe = clk_mt2701_aud_probe,
+	.driver = {
+		.name = "clk-mt2701-aud",
+		.of_match_table = of_match_clk_mt2701_aud,
+	},
+};
+
+builtin_platform_driver(clk_mt2701_aud_drv);
-- 
1.9.1

^ permalink raw reply related

* [PATCH v1 5/6] clk: mediatek: update missing clock data for MT7622 audsys
From: Ryder Lee @ 2018-01-04  7:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1515038387.git.ryder.lee@mediatek.com>

Add missing clock data 'CLK_AUDIO_AFE_CONN' for MT7622 audsys.

Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
 drivers/clk/mediatek/clk-mt7622-aud.c  | 3 ++-
 include/dt-bindings/clock/mt7622-clk.h | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c b/drivers/clk/mediatek/clk-mt7622-aud.c
index fad7d9f..96959ad 100644
--- a/drivers/clk/mediatek/clk-mt7622-aud.c
+++ b/drivers/clk/mediatek/clk-mt7622-aud.c
@@ -106,6 +106,7 @@
 	GATE_AUDIO1(CLK_AUDIO_INTDIR, "audio_intdir", "intdir_sel", 20),
 	GATE_AUDIO1(CLK_AUDIO_A1SYS, "audio_a1sys", "a1sys_hp_sel", 21),
 	GATE_AUDIO1(CLK_AUDIO_A2SYS, "audio_a2sys", "a2sys_hp_sel", 22),
+	GATE_AUDIO1(CLK_AUDIO_AFE_CONN, "audio_afe_conn", "a1sys_hp_sel", 23),
 	/* AUDIO2 */
 	GATE_AUDIO2(CLK_AUDIO_UL1, "audio_ul1", "a1sys_hp_sel", 0),
 	GATE_AUDIO2(CLK_AUDIO_UL2, "audio_ul2", "a1sys_hp_sel", 1),
@@ -146,7 +147,7 @@ static int clk_mt7622_audiosys_init(struct platform_device *pdev)
 	clk_data = mtk_alloc_clk_data(CLK_AUDIO_NR_CLK);
 
 	mtk_clk_register_gates(node, audio_clks, ARRAY_SIZE(audio_clks),
-			       clk_data);
+				   clk_data);
 
 	r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
 	if (r)
diff --git a/include/dt-bindings/clock/mt7622-clk.h b/include/dt-bindings/clock/mt7622-clk.h
index 3e514ed..e9d77f0 100644
--- a/include/dt-bindings/clock/mt7622-clk.h
+++ b/include/dt-bindings/clock/mt7622-clk.h
@@ -235,7 +235,8 @@
 #define CLK_AUDIO_MEM_ASRC3		43
 #define CLK_AUDIO_MEM_ASRC4		44
 #define CLK_AUDIO_MEM_ASRC5		45
-#define CLK_AUDIO_NR_CLK		46
+#define CLK_AUDIO_AFE_CONN		46
+#define CLK_AUDIO_NR_CLK		47
 
 /* SSUSBSYS */
 
-- 
1.9.1

^ permalink raw reply related

* [PATCH v1 4/6] dt-bindings: clock: mediatek: add "simple-mfd" in audsys documentation
From: Ryder Lee @ 2018-01-04  7:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1515038387.git.ryder.lee@mediatek.com>

Add "simple-mfd" to support MFD device and add a compatible string for MT2701.

Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
 .../bindings/arm/mediatek/mediatek,audsys.txt       | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
index 9b8f578..6e97552 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
@@ -6,17 +6,25 @@ The MediaTek AUDSYS controller provides various clocks to the system.
 Required Properties:
 
 - compatible: Should be one of:
-	- "mediatek,mt7622-audsys", "syscon"
+	- "mediatek,mt2701-audsys", "syscon", "simple-mfd"
+	- "mediatek,mt7622-audsys", "syscon", "simple-mfd"
 - #clock-cells: Must be 1
 
 The AUDSYS controller uses the common clk binding from
 Documentation/devicetree/bindings/clock/clock-bindings.txt
 The available clocks are defined in dt-bindings/clock/mt*-clk.h.
 
+See ../sound/mt2701-afe-pcm.txt for details about required subnode.
+
 Example:
 
-audsys: audsys at 11220000 {
-	compatible = "mediatek,mt7622-audsys", "syscon";
-	reg = <0 0x11220000 0 0x1000>;
-	#clock-cells = <1>;
-};
+	audsys: audio-subsystem at 11220000 {
+		compatible = "mediatek,mt2701-audsys", "syscon", "simple-mfd";
+		reg = <0 0x11220000 0 0x1000>;
+		#clock-cells = <1>;
+
+		afe: audio-controller {
+			compatible = "mediatek,mt2701-audio";
+			...
+		};
+	};
-- 
1.9.1

^ permalink raw reply related

* [PATCH v1 3/6] ASoC: mediatek: update MT2701 AFE documentation to adapt mfd device
From: Ryder Lee @ 2018-01-04  7:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1515038387.git.ryder.lee@mediatek.com>

As the new MFD parent is in place, modify MT2701 AFE documentation to
adapt it. Also add three core clocks in example.

Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
 .../devicetree/bindings/sound/mt2701-afe-pcm.txt   | 171 +++++++++++----------
 1 file changed, 93 insertions(+), 78 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
index 0450baa..12f147b 100644
--- a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
+++ b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt
@@ -2,15 +2,17 @@ Mediatek AFE PCM controller for mt2701
 
 Required properties:
 - compatible = "mediatek,mt2701-audio";
-- reg: register location and size
 - interrupts: should contain AFE and ASYS interrupts
 - interrupt-names: should be "afe" and "asys"
 - power-domains: should define the power domain
 - clocks: Must contain an entry for each entry in clock-names
   See ../clocks/clock-bindings.txt for details
 - clock-names: should have these clock names:
+		"infra_sys_audio_clk",
 		"top_audio_mux1_sel",
 		"top_audio_mux2_sel",
+		"top_audio_a1sys_hp",
+		"top_audio_a2sys_hp",
 		"i2s0_src_sel",
 		"i2s1_src_sel",
 		"i2s2_src_sel",
@@ -45,85 +47,98 @@ Required properties:
 - assigned-clocks-parents: parent of input clocks of assigned clocks.
 - assigned-clock-rates: list of clock frequencies of assigned clocks.
 
+Must be a subnode of MediaTek audsys device tree node.
+See ../arm/mediatek/mediatek,audsys.txt for details about the parent node.
+
 Example:
 
-	afe: mt2701-afe-pcm at 11220000 {
-		compatible = "mediatek,mt2701-audio";
-		reg = <0 0x11220000 0 0x2000>,
-		      <0 0x112A0000 0 0x20000>;
-		interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
-			     <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
-		interrupt-names	= "afe", "asys";
-		power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
-		clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
-			 <&topckgen CLK_TOP_AUD_MUX2_SEL>,
-			 <&topckgen CLK_TOP_AUD_K1_SRC_SEL>,
-			 <&topckgen CLK_TOP_AUD_K2_SRC_SEL>,
-			 <&topckgen CLK_TOP_AUD_K3_SRC_SEL>,
-			 <&topckgen CLK_TOP_AUD_K4_SRC_SEL>,
-			 <&topckgen CLK_TOP_AUD_K1_SRC_DIV>,
-			 <&topckgen CLK_TOP_AUD_K2_SRC_DIV>,
-			 <&topckgen CLK_TOP_AUD_K3_SRC_DIV>,
-			 <&topckgen CLK_TOP_AUD_K4_SRC_DIV>,
-			 <&topckgen CLK_TOP_AUD_I2S1_MCLK>,
-			 <&topckgen CLK_TOP_AUD_I2S2_MCLK>,
-			 <&topckgen CLK_TOP_AUD_I2S3_MCLK>,
-			 <&topckgen CLK_TOP_AUD_I2S4_MCLK>,
-			 <&audiosys CLK_AUD_I2SO1>,
-			 <&audiosys CLK_AUD_I2SO2>,
-			 <&audiosys CLK_AUD_I2SO3>,
-			 <&audiosys CLK_AUD_I2SO4>,
-			 <&audiosys CLK_AUD_I2SIN1>,
-			 <&audiosys CLK_AUD_I2SIN2>,
-			 <&audiosys CLK_AUD_I2SIN3>,
-			 <&audiosys CLK_AUD_I2SIN4>,
-			 <&audiosys CLK_AUD_ASRCO1>,
-			 <&audiosys CLK_AUD_ASRCO2>,
-			 <&audiosys CLK_AUD_ASRCO3>,
-			 <&audiosys CLK_AUD_ASRCO4>,
-			 <&audiosys CLK_AUD_AFE>,
-			 <&audiosys CLK_AUD_AFE_CONN>,
-			 <&audiosys CLK_AUD_A1SYS>,
-			 <&audiosys CLK_AUD_A2SYS>,
-			 <&audiosys CLK_AUD_AFE_MRGIF>;
+	audsys: audio-subsystem at 11220000 {
+		compatible = "mediatek,mt2701-audsys", "syscon", "simple-mfd";
+		...
+
+		afe: audio-controller {
+			compatible = "mediatek,mt2701-audio";
+			interrupts =  <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
+				      <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
+			interrupt-names	= "afe", "asys";
+			power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
+
+			clocks = <&infracfg CLK_INFRA_AUDIO>,
+				 <&topckgen CLK_TOP_AUD_MUX1_SEL>,
+				 <&topckgen CLK_TOP_AUD_MUX2_SEL>,
+				 <&topckgen CLK_TOP_AUD_48K_TIMING>,
+				 <&topckgen CLK_TOP_AUD_44K_TIMING>,
+				 <&topckgen CLK_TOP_AUD_K1_SRC_SEL>,
+				 <&topckgen CLK_TOP_AUD_K2_SRC_SEL>,
+				 <&topckgen CLK_TOP_AUD_K3_SRC_SEL>,
+				 <&topckgen CLK_TOP_AUD_K4_SRC_SEL>,
+				 <&topckgen CLK_TOP_AUD_K1_SRC_DIV>,
+				 <&topckgen CLK_TOP_AUD_K2_SRC_DIV>,
+				 <&topckgen CLK_TOP_AUD_K3_SRC_DIV>,
+				 <&topckgen CLK_TOP_AUD_K4_SRC_DIV>,
+				 <&topckgen CLK_TOP_AUD_I2S1_MCLK>,
+				 <&topckgen CLK_TOP_AUD_I2S2_MCLK>,
+				 <&topckgen CLK_TOP_AUD_I2S3_MCLK>,
+				 <&topckgen CLK_TOP_AUD_I2S4_MCLK>,
+				 <&audsys CLK_AUD_I2SO1>,
+				 <&audsys CLK_AUD_I2SO2>,
+				 <&audsys CLK_AUD_I2SO3>,
+				 <&audsys CLK_AUD_I2SO4>,
+				 <&audsys CLK_AUD_I2SIN1>,
+				 <&audsys CLK_AUD_I2SIN2>,
+				 <&audsys CLK_AUD_I2SIN3>,
+				 <&audsys CLK_AUD_I2SIN4>,
+				 <&audsys CLK_AUD_ASRCO1>,
+				 <&audsys CLK_AUD_ASRCO2>,
+				 <&audsys CLK_AUD_ASRCO3>,
+				 <&audsys CLK_AUD_ASRCO4>,
+				 <&audsys CLK_AUD_AFE>,
+				 <&audsys CLK_AUD_AFE_CONN>,
+				 <&audsys CLK_AUD_A1SYS>,
+				 <&audsys CLK_AUD_A2SYS>,
+				 <&audsys CLK_AUD_AFE_MRGIF>;
 
-		clock-names = "top_audio_mux1_sel",
-			      "top_audio_mux2_sel",
-			      "i2s0_src_sel",
-			      "i2s1_src_sel",
-			      "i2s2_src_sel",
-			      "i2s3_src_sel",
-			      "i2s0_src_div",
-			      "i2s1_src_div",
-			      "i2s2_src_div",
-			      "i2s3_src_div",
-			      "i2s0_mclk_en",
-			      "i2s1_mclk_en",
-			      "i2s2_mclk_en",
-			      "i2s3_mclk_en",
-			      "i2so0_hop_ck",
-			      "i2so1_hop_ck",
-			      "i2so2_hop_ck",
-			      "i2so3_hop_ck",
-			      "i2si0_hop_ck",
-			      "i2si1_hop_ck",
-			      "i2si2_hop_ck",
-			      "i2si3_hop_ck",
-			      "asrc0_out_ck",
-			      "asrc1_out_ck",
-			      "asrc2_out_ck",
-			      "asrc3_out_ck",
-			      "audio_afe_pd",
-			      "audio_afe_conn_pd",
-			      "audio_a1sys_pd",
-			      "audio_a2sys_pd",
-			      "audio_mrgif_pd";
+			clock-names = "infra_sys_audio_clk",
+				      "top_audio_mux1_sel",
+				      "top_audio_mux2_sel",
+				      "top_audio_a1sys_hp",
+				      "top_audio_a2sys_hp",
+				      "i2s0_src_sel",
+				      "i2s1_src_sel",
+				      "i2s2_src_sel",
+				      "i2s3_src_sel",
+				      "i2s0_src_div",
+				      "i2s1_src_div",
+				      "i2s2_src_div",
+				      "i2s3_src_div",
+				      "i2s0_mclk_en",
+				      "i2s1_mclk_en",
+				      "i2s2_mclk_en",
+				      "i2s3_mclk_en",
+				      "i2so0_hop_ck",
+				      "i2so1_hop_ck",
+				      "i2so2_hop_ck",
+				      "i2so3_hop_ck",
+				      "i2si0_hop_ck",
+				      "i2si1_hop_ck",
+				      "i2si2_hop_ck",
+				      "i2si3_hop_ck",
+				      "asrc0_out_ck",
+				      "asrc1_out_ck",
+				      "asrc2_out_ck",
+				      "asrc3_out_ck",
+				      "audio_afe_pd",
+				      "audio_afe_conn_pd",
+				      "audio_a1sys_pd",
+				      "audio_a2sys_pd",
+				      "audio_mrgif_pd";
 
-		assigned-clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
-				  <&topckgen CLK_TOP_AUD_MUX2_SEL>,
-				  <&topckgen CLK_TOP_AUD_MUX1_DIV>,
-				  <&topckgen CLK_TOP_AUD_MUX2_DIV>;
-		assigned-clock-parents = <&topckgen CLK_TOP_AUD1PLL_98M>,
-					 <&topckgen CLK_TOP_AUD2PLL_90M>;
-		assigned-clock-rates = <0>, <0>, <49152000>, <45158400>;
+			assigned-clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
+					  <&topckgen CLK_TOP_AUD_MUX2_SEL>,
+					  <&topckgen CLK_TOP_AUD_MUX1_DIV>,
+					  <&topckgen CLK_TOP_AUD_MUX2_DIV>;
+			assigned-clock-parents = <&topckgen CLK_TOP_AUD1PLL_98M>,
+						 <&topckgen CLK_TOP_AUD2PLL_90M>;
+			assigned-clock-rates = <0>, <0>, <49152000>, <45158400>;
+		};
 	};
-- 
1.9.1

^ permalink raw reply related

* [PATCH v1 2/6] ASoC: mediatek: modify MT2701 AFE driver to adapt mfd device
From: Ryder Lee @ 2018-01-04  7:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1515038387.git.ryder.lee@mediatek.com>

As the new MFD parent is in place, modify MT2701 AFE driver to adapt it.

Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
 sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 45 +++++++++++++-----------------
 sound/soc/mediatek/mt2701/mt2701-reg.h     |  1 -
 2 files changed, 20 insertions(+), 26 deletions(-)

diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
index 0edadca..f0cd08f 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
@@ -17,6 +17,7 @@
 
 #include <linux/delay.h>
 #include <linux/module.h>
+#include <linux/mfd/syscon.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/pm_runtime.h>
@@ -1368,14 +1369,6 @@ static int mt2701_irq_fs(struct snd_pcm_substream *substream, unsigned int rate)
 	},
 };
 
-static const struct regmap_config mt2701_afe_regmap_config = {
-	.reg_bits = 32,
-	.reg_stride = 4,
-	.val_bits = 32,
-	.max_register = AFE_END_ADDR,
-	.cache_type = REGCACHE_NONE,
-};
-
 static irqreturn_t mt2701_asys_isr(int irq_id, void *dev)
 {
 	int id;
@@ -1414,9 +1407,9 @@ static int mt2701_afe_runtime_resume(struct device *dev)
 
 static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
 {
+	struct snd_soc_component *component;
 	struct mtk_base_afe *afe;
 	struct mt2701_afe_private *afe_priv;
-	struct resource *res;
 	struct device *dev;
 	int i, irq_id, ret;
 
@@ -1446,17 +1439,11 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
-	afe->base_addr = devm_ioremap_resource(&pdev->dev, res);
-
-	if (IS_ERR(afe->base_addr))
-		return PTR_ERR(afe->base_addr);
-
-	afe->regmap = devm_regmap_init_mmio(&pdev->dev, afe->base_addr,
-		&mt2701_afe_regmap_config);
-	if (IS_ERR(afe->regmap))
-		return PTR_ERR(afe->regmap);
+	afe->regmap = syscon_node_to_regmap(dev->parent->of_node);
+	if (!afe->regmap) {
+		dev_err(dev, "could not get regmap from parent\n");
+		return -ENODEV;
+	}
 
 	mutex_init(&afe->irq_alloc_lock);
 
@@ -1490,6 +1477,12 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
 			= &mt2701_i2s_data[i][I2S_IN];
 	}
 
+	component = kzalloc(sizeof(*component), GFP_KERNEL);
+	if (!component)
+		return -ENOMEM;
+
+	component->regmap = afe->regmap;
+
 	afe->mtk_afe_hardware = &mt2701_afe_hardware;
 	afe->memif_fs = mt2701_memif_fs;
 	afe->irq_fs = mt2701_irq_fs;
@@ -1502,7 +1495,7 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
 	ret = mt2701_init_clock(afe);
 	if (ret) {
 		dev_err(dev, "init clock error\n");
-		return ret;
+		goto err_init_clock;
 	}
 
 	platform_set_drvdata(pdev, afe);
@@ -1521,10 +1514,10 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
 		goto err_platform;
 	}
 
-	ret = snd_soc_register_component(&pdev->dev,
-					 &mt2701_afe_pcm_dai_component,
-					 mt2701_afe_pcm_dais,
-					 ARRAY_SIZE(mt2701_afe_pcm_dais));
+	ret = snd_soc_add_component(dev, component,
+				    &mt2701_afe_pcm_dai_component,
+				    mt2701_afe_pcm_dais,
+				    ARRAY_SIZE(mt2701_afe_pcm_dais));
 	if (ret) {
 		dev_warn(dev, "err_dai_component\n");
 		goto err_dai_component;
@@ -1538,6 +1531,8 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
 	pm_runtime_put_sync(dev);
 err_pm_disable:
 	pm_runtime_disable(dev);
+err_init_clock:
+	kfree(component);
 
 	return ret;
 }
diff --git a/sound/soc/mediatek/mt2701/mt2701-reg.h b/sound/soc/mediatek/mt2701/mt2701-reg.h
index f17c76f..18e6769 100644
--- a/sound/soc/mediatek/mt2701/mt2701-reg.h
+++ b/sound/soc/mediatek/mt2701/mt2701-reg.h
@@ -145,5 +145,4 @@
 #define ASYS_I2S_CON_WIDE_MODE_SET(x)	((x) << 1)
 #define ASYS_I2S_IN_PHASE_FIX		(0x1 << 31)
 
-#define AFE_END_ADDR 0x15e0
 #endif
-- 
1.9.1

^ permalink raw reply related

* [PATCH v1 1/6] ASoC: mediatek: add some core clocks for MT2701 AFE
From: Ryder Lee @ 2018-01-04  7:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.1515038387.git.ryder.lee@mediatek.com>

Add three core clocks for MT2701 AFE.

Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
 sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c | 30 ++++++++++++++++++++++-
 sound/soc/mediatek/mt2701/mt2701-afe-common.h     |  3 +++
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
index 56a057c..949fc3a 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
@@ -18,8 +18,11 @@
 #include "mt2701-afe-clock-ctrl.h"
 
 static const char *const base_clks[] = {
+	[MT2701_INFRA_SYS_AUDIO] = "infra_sys_audio_clk",
 	[MT2701_TOP_AUD_MCLK_SRC0] = "top_audio_mux1_sel",
 	[MT2701_TOP_AUD_MCLK_SRC1] = "top_audio_mux2_sel",
+	[MT2701_TOP_AUD_A1SYS] = "top_audio_a1sys_hp",
+	[MT2701_TOP_AUD_A2SYS] = "top_audio_a2sys_hp",
 	[MT2701_AUDSYS_AFE] = "audio_afe_pd",
 	[MT2701_AUDSYS_AFE_CONN] = "audio_afe_conn_pd",
 	[MT2701_AUDSYS_A1SYS] = "audio_a1sys_pd",
@@ -169,10 +172,26 @@ static int mt2701_afe_enable_audsys(struct mtk_base_afe *afe)
 	struct mt2701_afe_private *afe_priv = afe->platform_priv;
 	int ret;
 
-	ret = clk_prepare_enable(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+	/* Enable infra clock gate */
+	ret = clk_prepare_enable(afe_priv->base_ck[MT2701_INFRA_SYS_AUDIO]);
 	if (ret)
 		return ret;
 
+	/* Enable top a1sys clock gate */
+	ret = clk_prepare_enable(afe_priv->base_ck[MT2701_TOP_AUD_A1SYS]);
+	if (ret)
+		goto err_a1sys;
+
+	/* Enable top a2sys clock gate */
+	ret = clk_prepare_enable(afe_priv->base_ck[MT2701_TOP_AUD_A2SYS]);
+	if (ret)
+		goto err_a2sys;
+
+	/* Internal clock gates */
+	ret = clk_prepare_enable(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+	if (ret)
+		goto err_afe;
+
 	ret = clk_prepare_enable(afe_priv->base_ck[MT2701_AUDSYS_A1SYS]);
 	if (ret)
 		goto err_audio_a1sys;
@@ -193,6 +212,12 @@ static int mt2701_afe_enable_audsys(struct mtk_base_afe *afe)
 	clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_A1SYS]);
 err_audio_a1sys:
 	clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+err_afe:
+	clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A2SYS]);
+err_a2sys:
+	clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A1SYS]);
+err_a1sys:
+	clk_disable_unprepare(afe_priv->base_ck[MT2701_INFRA_SYS_AUDIO]);
 
 	return ret;
 }
@@ -205,6 +230,9 @@ static void mt2701_afe_disable_audsys(struct mtk_base_afe *afe)
 	clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_A2SYS]);
 	clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_A1SYS]);
 	clk_disable_unprepare(afe_priv->base_ck[MT2701_AUDSYS_AFE]);
+	clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A1SYS]);
+	clk_disable_unprepare(afe_priv->base_ck[MT2701_TOP_AUD_A2SYS]);
+	clk_disable_unprepare(afe_priv->base_ck[MT2701_INFRA_SYS_AUDIO]);
 }
 
 int mt2701_afe_enable_clock(struct mtk_base_afe *afe)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-common.h b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
index 9a2b301..ae8ddea 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-common.h
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
@@ -61,8 +61,11 @@ enum {
 };
 
 enum audio_base_clock {
+	MT2701_INFRA_SYS_AUDIO,
 	MT2701_TOP_AUD_MCLK_SRC0,
 	MT2701_TOP_AUD_MCLK_SRC1,
+	MT2701_TOP_AUD_A1SYS,
+	MT2701_TOP_AUD_A2SYS,
 	MT2701_AUDSYS_AFE,
 	MT2701_AUDSYS_AFE_CONN,
 	MT2701_AUDSYS_A1SYS,
-- 
1.9.1

^ permalink raw reply related

* [PATCH v1 0/6] add "simple-mfd" support for MediaTek audio subsystem
From: Ryder Lee @ 2018-01-04  7:44 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

The reason for this series is that MediaTek audio hardware block expose more than
a single functionality, but register those in different kernel subsystems.
Same issue could also be found in MMSYS: https://lkml.org/lkml/2017/11/14/669

Hence use "simple-mfd" to handle this kind of situation, that will make sure all
children are registered - and we don't need to write an MFD driver specially.
It was tested on the bananapi-r2 and the MT2701/MT7622 EVB.

[1]~[3]: modify the current audio driver accordingly.
[5][6]: add clock driver for MT2701 and add missing data for MT7622.

changes since v1:
 - To avoid writing an MFD driver, we add "simple-mfd" in the audsys binding.
 - Move three top clocks to audio driver [1] as we remove mfd/mtk-audsys.c in v1.

Ryder Lee (6):
  ASoC: mediatek: add some core clocks for MT2701 AFE
  ASoC: mediatek: modify MT2701 AFE driver to adapt mfd device
  ASoC: mediatek: update MT2701 AFE documentation to adapt mfd device
  dt-bindings: clock: mediatek: add "simple-mfd" in audsys documentation
  clk: mediatek: update missing clock data for MT7622 audsys
  clk: mediatek: add audsys support for MT2701

 .../bindings/arm/mediatek/mediatek,audsys.txt      |  21 ++-
 .../devicetree/bindings/sound/mt2701-afe-pcm.txt   | 171 +++++++++++---------
 drivers/clk/mediatek/Kconfig                       |   6 +
 drivers/clk/mediatek/Makefile                      |   1 +
 drivers/clk/mediatek/clk-mt2701-aud.c              | 174 +++++++++++++++++++++
 drivers/clk/mediatek/clk-mt7622-aud.c              |   3 +-
 include/dt-bindings/clock/mt7622-clk.h             |   3 +-
 sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c  |  30 +++-
 sound/soc/mediatek/mt2701/mt2701-afe-common.h      |   3 +
 sound/soc/mediatek/mt2701/mt2701-afe-pcm.c         |  45 +++---
 sound/soc/mediatek/mt2701/mt2701-reg.h             |   1 -
 11 files changed, 345 insertions(+), 113 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-mt2701-aud.c

-- 
1.9.1

^ permalink raw reply

* [PATCH -next] serial: 8250_uniphier: fix error return code in uniphier_uart_probe()
From: Wei Yongjun @ 2018-01-04  7:42 UTC (permalink / raw)
  To: linux-arm-kernel

Fix to return a negative error code from the port register error
handling case instead of 0, as done elsewhere in this function.

Fixes: 39be40ce066d ("serial: 8250_uniphier: fix serial port index in private data")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
 drivers/tty/serial/8250/8250_uniphier.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_uniphier.c b/drivers/tty/serial/8250/8250_uniphier.c
index 45ef506..28d88ccf 100644
--- a/drivers/tty/serial/8250/8250_uniphier.c
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -250,12 +250,13 @@ static int uniphier_uart_probe(struct platform_device *pdev)
 	up.dl_read = uniphier_serial_dl_read;
 	up.dl_write = uniphier_serial_dl_write;
 
-	priv->line = serial8250_register_8250_port(&up);
-	if (priv->line < 0) {
+	ret = serial8250_register_8250_port(&up);
+	if (ret < 0) {
 		dev_err(dev, "failed to register 8250 port\n");
 		clk_disable_unprepare(priv->clk);
 		return ret;
 	}
+	priv->line = ret;
 
 	platform_set_drvdata(pdev, priv);

^ permalink raw reply related

* [PATCH -next] serial: 8250_uniphier: fix error return code in uniphier_uart_probe()
From: Masahiro Yamada @ 2018-01-04  7:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1515051735-59992-1-git-send-email-weiyongjun1@huawei.com>

2018-01-04 16:42 GMT+09:00 Wei Yongjun <weiyongjun1@huawei.com>:
> Fix to return a negative error code from the port register error
> handling case instead of 0, as done elsewhere in this function.
>
> Fixes: 39be40ce066d ("serial: 8250_uniphier: fix serial port index in private data")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---

Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Thanks!

-- 
Best Regards
Masahiro Yamada

^ permalink raw reply

* [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)
From: Greg Kroah-Hartman @ 2018-01-04  6:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <6fa84768-7431-22d2-4930-35b0b65ae86f@gmail.com>

On Wed, Jan 03, 2018 at 09:17:26PM -0800, Florian Fainelli wrote:
> On 12/11/2017 09:59 AM, Catalin Marinas wrote:
> > On Wed, Dec 06, 2017 at 12:35:19PM +0000, Will Deacon wrote:
> >> Patches are also pushed here:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti
> >>
> >> Feedback and testing welcome. At this point, I'd like to start thinking
> >> about getting this merged for 4.16.
> > 
> > For the record, the fixed up version was pushed by Will here:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git kpti
> > 
> > and I queued it for 4.16 in the arm64 for-next/core branch (same tree as
> > above).
> 
> Greg proposed the x86/KPTI patches for the stable-4.9.75 queue, is there
> a plan to get the ARM64/KPTI patches backported towards stable trees as
> well?

Stable tree patches have to get into Linus's tree first before I can do
anything :)

Anyway, once that happens, yes, there is a plan, but it's a bit
"different", and I'll talk about it once these are merged.

thanks,

greg k-h

^ permalink raw reply

* [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
From: vkilari at codeaurora.org @ 2018-01-04  6:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <f89c8f07-bef6-c20b-cb2e-eaa2121689b3@arm.com>

Hi Jeremy

> -----Original Message-----
> From: linux-arm-kernel
[mailto:linux-arm-kernel-bounces at lists.infradead.org]
> On Behalf Of Jeremy Linton
> Sent: Wednesday, January 3, 2018 10:28 PM
> To: vkilari at codeaurora.org
> Cc: 'Mark Rutland' <mark.rutland@arm.com>; Jonathan.Zhang at cavium.com;
> Jayachandran.Nair at cavium.com; 'Lorenzo Pieralisi'
> <lorenzo.pieralisi@arm.com>; austinwc at codeaurora.org; 'Linux PM' <linux-
> pm at vger.kernel.org>; jhugo at codeaurora.org; 'Catalin Marinas'
> <catalin.marinas@arm.com>; 'Sudeep Holla' <sudeep.holla@arm.com>; 'Will
> Deacon' <will.deacon@arm.com>; 'Linux Kernel Mailing List' <linux-
> kernel at vger.kernel.org>; wangxiongfeng2 at huawei.com; 'ACPI Devel Maling
> List' <linux-acpi@vger.kernel.org>; 'Viresh Kumar'
<viresh.kumar@linaro.org>;
> 'Rafael J. Wysocki' <rjw@rjwysocki.net>; 'Hanjun Guo'
> <hanjun.guo@linaro.org>; 'Greg Kroah-Hartman'
> <gregkh@linuxfoundation.org>; 'Rafael J. Wysocki' <rafael@kernel.org>; 'Al
> Stone' <ahs3@redhat.com>; linux-arm-kernel at lists.infradead.org; 'Len
Brown'
> <lenb@kernel.org>
> Subject: Re: [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
> 
> Hi,
> 
> On 01/03/2018 02:49 AM, vkilari at codeaurora.org wrote:
> > Hi Jeremy,
> >
> >   Sorry, I don't have your previous patch emails to reply on right
> > patch context.
> > So commenting on top of this patch.
> >
> > AFAIU, the PPTT v5 patches still rely on CLIDR_EL1 register to know
> > the type of Caches enabled/available on the platform. With PPTT, it
> > should not rely on architecture registers. There can be platforms
> > which can report cache availability in PPTT but not in architecture
> > registers.
> >
> > The following code snippet shows usage of CLIDR_EL1
> >
> > In arch/arm64/kernel/cacheinfo.c
> >
> > static inline enum cache_type get_cache_type(int level) {
> >           u64 clidr;
> >
> >           if (level > MAX_CACHE_LEVEL)
> >                   return CACHE_TYPE_NOCACHE;
> >           clidr = read_sysreg(clidr_el1);
> >           return CLIDR_CTYPE(clidr, level); }
> >
> > static int __populate_cache_leaves(unsigned int cpu) {
> >            unsigned int level, idx;
> >            enum cache_type type;
> >            struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> >            struct cacheinfo *this_leaf = this_cpu_ci->info_list;
> >
> >            for (idx = 0, level = 1; level <= this_cpu_ci->num_levels &&
> >                 idx < this_cpu_ci->num_leaves; idx++, level++) {
> >                    type = get_cache_type(level);
> >                    if (type == CACHE_TYPE_SEPARATE) {
> >                            ci_leaf_init(this_leaf++, CACHE_TYPE_DATA,
level);
> >                            ci_leaf_init(this_leaf++, CACHE_TYPE_INST,
level);
> >                    } else {
> >                            ci_leaf_init(this_leaf++, type, level);
> >                    }
> >           }
> >            return 0;
> >   }
> >
> > In populate_cache_leaves() the cache type is read from CLIDR_EL1
register.
> > If CLIDR_EL1 reports CACHE_TYPE_NOCACHE for a particular level then
> > sysfs entry /sys/devices/system/cpu/cpu0/index<n>/type is not created
> > and hence userspace tools like lstopo will not report this cache
> > level.
> 
> 
> This sounds suspiciously like one of things tweaked between v4->v5. If you
look
> at update_cache_properties() in patch 2/9, you will see that we only
> update/find NOCACHE nodes and convert them to UNIFIED when all the
> attributes in the node are supplied.
> 
> This means that if the node has an incomplete set of attributes we won't
update
> it. Can you verify that you have all those attributes set for nodes which
aren't
> being described by the hardware?

Thanks for pointing out.
Why do we need to check for set of attributes and decide it as UNIFIED
cache.?
We can get cache type from attributes bits[3:2] if cache type valid flag is
set
irrespective of other attributes. If cache type valid flag is not set then
we can assume
it as NOCACHE type as neither architecture register nor in PPTT has valid
cache type.

> 
> Thanks,
> 
> 
> >
> > Regards
> > Vijay
> >
> >> -----Original Message-----
> >> From: linux-arm-kernel
> > [mailto:linux-arm-kernel-bounces at lists.infradead.org]
> >> On Behalf Of Rafael J. Wysocki
> >> Sent: Thursday, December 14, 2017 4:40 AM
> >> To: Jeremy Linton <jeremy.linton@arm.com>
> >> Cc: Mark Rutland <mark.rutland@arm.com>; Jonathan.Zhang at cavium.com;
> >> Jayachandran.Nair at cavium.com; Lorenzo Pieralisi
> >> <lorenzo.pieralisi@arm.com>; Catalin Marinas
> >> <catalin.marinas@arm.com>; Rafael J. Wysocki <rafael@kernel.org>;
> >> jhugo at codeaurora.org; Will Deacon <will.deacon@arm.com>; Linux PM
> <linux-pm@vger.kernel.org>; Rafael J.
> >> Wysocki <rjw@rjwysocki.net>; Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org>; Linux Kernel Mailing List <linux-
> >> kernel at vger.kernel.org>; ACPI Devel Maling List
> > <linux-acpi@vger.kernel.org>;
> >> Viresh Kumar <viresh.kumar@linaro.org>; Hanjun Guo
> >> <hanjun.guo@linaro.org>; Al Stone <ahs3@redhat.com>; Sudeep Holla
> >> <sudeep.holla@arm.com>; austinwc at codeaurora.org;
> >> wangxiongfeng2 at huawei.com; linux-arm-kernel at lists.infradead.org; Len
> >> Brown <lenb@kernel.org>
> >> Subject: Re: [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
> >>
> >> On Thu, Dec 14, 2017 at 12:06 AM, Jeremy Linton
> >> <jeremy.linton@arm.com>
> >> wrote:
> >>> Hi,
> >>>
> >>>
> >>> On 12/13/2017 04:28 PM, Rafael J. Wysocki wrote:
> >>>>
> >>>> On Wed, Dec 13, 2017 at 6:38 PM, Lorenzo Pieralisi
> >>>> <lorenzo.pieralisi@arm.com> wrote:
> >>>>>
> >>>>> On Tue, Dec 12, 2017 at 10:13:08AM -0600, Jeremy Linton wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> First, thanks for taking a look at this.
> >>>>>>
> >>>>>> On 12/11/2017 07:12 PM, Rafael J. Wysocki wrote:
> >>>>>>>
> >>>>>>> On Friday, December 1, 2017 11:23:27 PM CET Jeremy Linton wrote:
> >>>>>>>>
> >>>>>>>> The PPTT can be used to determine the groupings of CPU's at
> >>>>>>>> given levels in the system. Lets add a few routines to the PPTT
> >>>>>>>> parsing code to return a unique id for each unique level in the
> >>>>>>>> processor hierarchy. This can then be matched to build
> >>>>>>>> thread/core/cluster/die/package/etc mappings for each
> >>>>>>>> processing element in the system.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> >>>>>>>
> >>>>>>>
> >>>>>>> Why can't this be folded into patch [2/9]?
> >>>>>>
> >>>>>>
> >>>>>> It can, and I will be happy squash it.
> >>>>>>
> >>>>>> It was requested that the topology portion of the parser be split
> >>>>>> out back in v3.
> >>>>>>
> >>>>>> https://www.spinics.net/lists/linux-acpi/msg78487.html
> >>>>>
> >>>>>
> >>>>> I asked to split cache/topology since I am not familiar with cache
> >>>>> code and Sudeep - who looks after the cache code - won't be able
> >>>>> to review this series in time for v4.16.
> >>>>
> >>>>
> >>>> OK, so why do we need it in 4.16?
> >>>
> >>>
> >>> I think its more case of as soon as possible. That is because there
> >>> are machines where the topology is completely incorrect due to
> >>> assumptions the kernel makes based on registers that aren't defined
> >>> for that purpose (say describing which cores are in a physical
> >>> socket, or LLC's attached to interconnects or memory controllers).
> >>>
> >>> This incorrect topology information is reported to things like the
> >>> kernel scheduler, which then makes poor scheduling decisions
> >>> resulting in sub-optimal system performance.
> >>>
> >>> This patchset (and ACPI 6.2) clears up a lot of those problems.
> >>
> >> As long as the ACPI tables are as expected that is, I suppose?
> >>
> >> Anyway, fair enough, but I don't want to rush it in.
> >>
> >> Thanks,
> >> Rafael
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox