Linux-mediatek Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 13/16] arm: dts: rename mt7623-evb.dts to arch/arm/boot/dts/mt7623n-rfb.dtsi
From: Rob Herring @ 2017-01-27 20:13 UTC (permalink / raw)
  To: John Crispin
  Cc: Matthias Brugger, devicetree, linux-mediatek, Andreas Färber,
	linux-arm-kernel
In-Reply-To: <1485170975-51813-14-git-send-email-john@phrozen.org>

On Mon, Jan 23, 2017 at 12:29:32PM +0100, John Crispin wrote:
> There are 2 versions of the SoC. MT7623N is almost identical to MT7623A
> but has some additional multimedia features. The reference boards are
> available as NAND or MMC and might have a different ethernet setup. In
> order to reduce the duplication of devicetree code we add an intermediate
> dtsi file for these reference boards. Additionally MTK/WCN pointed out,
> that the EVB is yet another board and the board in question is infact the
> RFB. Take this into account while renaming the files.
> 
>  Signed-off-by: John Crispin <john@phrozen.org>
> ---
>  Documentation/devicetree/bindings/arm/mediatek.txt |    4 +--
>  arch/arm/boot/dts/Makefile                         |    2 +-
>  arch/arm/boot/dts/mt7623-evb.dts                   |   33 --------------------
>  arch/arm/boot/dts/mt7623n-rfb-nand.dts             |   21 +++++++++++++
>  arch/arm/boot/dts/mt7623n-rfb.dtsi                 |   29 +++++++++++++++++
>  5 files changed, 53 insertions(+), 36 deletions(-)
>  delete mode 100644 arch/arm/boot/dts/mt7623-evb.dts
>  create mode 100644 arch/arm/boot/dts/mt7623n-rfb-nand.dts
>  create mode 100644 arch/arm/boot/dts/mt7623n-rfb.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt
> index c860b24..71149cb 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek.txt
> @@ -38,9 +38,9 @@ Supported boards:
>  - Evaluation board for MT6795(Helio X10):
>      Required root node properties:
>        - compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
> -- Evaluation board for MT7623:
> +- Reference  board for MT7623N with NAND:
>      Required root node properties:
> -      - compatible = "mediatek,mt7623-evb", "mediatek,mt7623";
> +      - compatible = "mediatek,mt7623n-rfb-nand", "mediatek,mt7623";

Seems like we should have mt7623n as a compatible.

>  - MTK mt8127 tablet moose EVB:
>      Required root node properties:
>        - compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index cccdbcb..9735c2c 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -976,7 +976,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
>  	mt6580-evbp1.dtb \
>  	mt6589-aquaris5.dtb \
>  	mt6592-evb.dtb \
> -	mt7623-evb.dtb \
> +	mt7623n-rfb-nand.dtb \
>  	mt8127-moose.dtb \
>  	mt8135-evbp1.dtb
>  dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
> diff --git a/arch/arm/boot/dts/mt7623-evb.dts b/arch/arm/boot/dts/mt7623-evb.dts
> deleted file mode 100644
> index 58ed038..0000000
> --- a/arch/arm/boot/dts/mt7623-evb.dts
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -/*
> - * Copyright (c) 2016 MediaTek Inc.
> - * Author: John Crispin <blogic@openwrt.org>
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - */
> -
> -/dts-v1/;
> -#include "mt7623-mt6323.dtsi"
> -
> -/ {
> -	model = "MediaTek MT7623 evaluation board";
> -	compatible = "mediatek,mt7623-evb", "mediatek,mt7623";
> -
> -	chosen {
> -		stdout-path = &uart2;
> -	};
> -
> -	memory {
> -		reg = <0 0x80000000 0 0x40000000>;
> -	};
> -};
> -
> -&uart2 {
> -	status = "okay";
> -};
> diff --git a/arch/arm/boot/dts/mt7623n-rfb-nand.dts b/arch/arm/boot/dts/mt7623n-rfb-nand.dts
> new file mode 100644
> index 0000000..436d51c
> --- /dev/null
> +++ b/arch/arm/boot/dts/mt7623n-rfb-nand.dts
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: John Crispin <blogic@openwrt.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +/dts-v1/;
> +#include "mt7623n-rfb.dtsi"
> +
> +/ {
> +	model = "MediaTek MT7623N NAND reference board";
> +	compatible = "mediatek,mt7623n-rfb-nand", "mediatek,mt7623";
> +};
> diff --git a/arch/arm/boot/dts/mt7623n-rfb.dtsi b/arch/arm/boot/dts/mt7623n-rfb.dtsi
> new file mode 100644
> index 0000000..d46390e
> --- /dev/null
> +++ b/arch/arm/boot/dts/mt7623n-rfb.dtsi
> @@ -0,0 +1,29 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: John Crispin <blogic@openwrt.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include "mt7623-mt6323.dtsi"
> +
> +/ {
> +	chosen {
> +		stdout-path = &uart2;
> +	};
> +
> +	memory {

Unless it can change:

memory@80000000

> +		reg = <0 0x80000000 0 0x40000000>;
> +	};
> +};
> +
> +&uart2 {
> +	status = "okay";
> +};
> -- 
> 1.7.10.4
> 

^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: pwm: Add MediaTek PWM bindings
From: Rob Herring @ 2017-01-27 20:59 UTC (permalink / raw)
  To: John Crispin
  Cc: Thierry Reding, Matthias Brugger, linux-pwm, devicetree,
	linux-mediatek, Sean Wang (王志亘)
In-Reply-To: <1485196477-669-1-git-send-email-john@phrozen.org>

On Mon, Jan 23, 2017 at 07:34:36PM +0100, John Crispin wrote:
> Document the device-tree binding of MediaTek PWM. The PWM has 5 channels.
> This has been tested on MT7623 only but should work on all the other MTK
> SoCs that contain this core.
> 
> Signed-off-by: John Crispin <john@phrozen.org>
> ---
>  .../devicetree/bindings/pwm/pwm-mediatek.txt       |   34 ++++++++++++++++++++
>  1 file changed, 34 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mediatek.txt

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* Re: [PATCH v2 1/2] Documentation: mtk-quadspi: update DT bindings
From: Rob Herring @ 2017-01-27 22:29 UTC (permalink / raw)
  To: Guochun Mao
  Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
	Russell King, linux-kernel, Marek Vasut, linux-mtd, John Crispin,
	Matthias Brugger, linux-mediatek, Cyrille Pitchen, Brian Norris,
	David Woodhouse, linux-arm-kernel
In-Reply-To: <1485315515-29942-2-git-send-email-guochun.mao@mediatek.com>

On Wed, Jan 25, 2017 at 11:38:34AM +0800, Guochun Mao wrote:
> Add "mediatek,mt2701-nor" for nor flash node's compatible.
> 
> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> ---
>  .../devicetree/bindings/mtd/mtk-quadspi.txt        |    8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Acked-by: Rob Herring <robh@kernel.org>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [PATCH 1/2] Documentation: devicetree: change the mediatek ethernet compatible string
From: Rob Herring @ 2017-01-27 22:41 UTC (permalink / raw)
  To: John Crispin
  Cc: Matthias Brugger, David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
	Sean Wang, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1485332455-34743-1-git-send-email-john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>

On Wed, Jan 25, 2017 at 09:20:54AM +0100, John Crispin wrote:
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
> 
> The ethernet driver is currently of no real use until we finish and
> upstream the DSA driver. There are no users of this binding yet. It should
> be safe to fix this now before it is too late and we need to provide
> backward compatibility for the mt7623-eth compat string.

Thanks for the explanation.

> Reported-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/net/mediatek-net.txt |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
> index c010faf..c7194e8 100644
> --- a/Documentation/devicetree/bindings/net/mediatek-net.txt
> +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
> @@ -7,7 +7,7 @@ have dual GMAC each represented by a child node..
>  * Ethernet controller node
>  
>  Required properties:
> -- compatible: Should be "mediatek,mt7623-eth"
> +- compatible: Should be "mediatek,mt2701-eth"

You should have both strings with 2701 being last. That way if you ever 
find a difference in the 7623, you don't need a DT update to fix it.

>  - reg: Address and length of the register set for the device
>  - interrupts: Should contain the three frame engines interrupts in numeric
>  	order. These are fe_int0, fe_int1 and fe_int2.
> -- 
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 3/4] leds: Add LED support for MT6323 PMIC
From: Sean Wang @ 2017-01-28 14:05 UTC (permalink / raw)
  To: Jacek Anaszewski
  Cc: mark.rutland, devicetree, keyhaede, linux-kernel, robh+dt,
	rpurdie, linux-arm-kernel, pavel, matthias.bgg, linux-mediatek,
	lee.jones, linux-leds
In-Reply-To: <62acfd5d-6455-d89b-9169-71337319311f@gmail.com>

Hi Jacek,

thanks for your effort on reviewing
I has given these idea about your questions inline below
and will fix up these explicit mistakes in the next version. 

thanks again

On Tue, 2017-01-24 at 23:51 +0100, Jacek Anaszewski wrote:
> Hi Sean,
> 
> Thanks for the patch. Please find my comments in the code below.
> 
> On 01/23/2017 04:54 AM, sean.wang@mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> > 
> > MT6323 PMIC is a multi-function device that includes
> > LED function. It allows attaching upto 4 LEDs which can
> 
> s/upto/up to/
> 
will be fixed

> > either be on, off or dimmed and/or blinked with the the
> > controller.
> > 
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > ---
> >  drivers/leds/Kconfig       |   8 +
> >  drivers/leds/Makefile      |   1 +
> >  drivers/leds/leds-mt6323.c | 391 +++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 400 insertions(+)
> >  create mode 100644 drivers/leds/leds-mt6323.c
> > 
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > index c621cbb..30095fc 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -117,6 +117,14 @@ config LEDS_MIKROTIK_RB532
> >  	  This option enables support for the so called "User LED" of
> >  	  Mikrotik's Routerboard 532.
> >  
> > +config LEDS_MT6323
> > +	tristate "LED Support for Mediatek MT6323 PMIC"
> > +	depends on LEDS_CLASS
> > +	depends on MFD_MT6397
> > +
> > +	help
> > +	  This option enables support for on-chip LED drivers found on
> > +	  Mediatek MT6323 PMIC.
> > +
> >  config LEDS_S3C24XX
> >  	tristate "LED Support for Samsung S3C24XX GPIO LEDs"
> >  	depends on LEDS_CLASS
> > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> > index 6b82737..4feb332 100644
> > --- a/drivers/leds/Makefile
> > +++ b/drivers/leds/Makefile
> > @@ -72,6 +72,7 @@ obj-$(CONFIG_LEDS_IS31FL32XX)		+= leds-is31fl32xx.o
> >  obj-$(CONFIG_LEDS_PM8058)		+= leds-pm8058.o
> >  obj-$(CONFIG_LEDS_MLXCPLD)		+= leds-mlxcpld.o
> >  obj-$(CONFIG_LEDS_NIC78BX)		+= leds-nic78bx.o
> > +obj-$(CONFIG_LEDS_MT6323)		+= leds-mt6323.o
> >  
> >  # LED SPI Drivers
> >  obj-$(CONFIG_LEDS_DAC124S085)		+= leds-dac124s085.o
> > diff --git a/drivers/leds/leds-mt6323.c b/drivers/leds/leds-mt6323.c
> > new file mode 100644
> > index 0000000..de3006d
> > --- /dev/null
> > +++ b/drivers/leds/leds-mt6323.c
> > @@ -0,0 +1,391 @@
> > +/*
> > + * LED driver for Mediatek MT6323 PMIC
> > + *
> > + * Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> > + * the License, or (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/leds.h>
> > +#include <linux/regmap.h>
> > +#include <linux/mfd/mt6397/core.h>
> > +#include <linux/mfd/mt6323/registers.h>
> > +#include <linux/module.h>
> 
> Please sort include directives alphabetically.
> 
will be fixed

> > +
> > +/* Register to enable 32K clock common for LED device */
> > +#define MTK_MT6323_TOP_CKPDN0         0x0102
> 
> How about dropping MTK and leaving MT6323 prefix?
> The same applies to the other macros.

MT6323_TOP_CKPDN0 had been defined in regulator header files
but your idea is good where reusing them is better . 

Will be enhanced.


> > +#define RG_DRV_32K_CK_PDN	      BIT(11)
> > +#define RG_DRV_32K_CK_PDN_MASK	      BIT(11)
> 
> These macros also require MT6323 prefix.

Will be enhanced

> > +
> > +/* Register to enable individual clock for LED device */
> > +#define MTK_MT6323_TOP_CKPDN2         0x010E
> > +#define RG_ISINK_CK_PDN(i)	      BIT(i)
> > +#define RG_ISINK_CK_PDN_MASK(i)       BIT(i)
> > +
> > +/* Register to select clock source */
> > +#define MTK_MT6323_TOP_CKCON1	      0x0126
> > +#define RG_ISINK_CK_SEL_MASK(i)	      (BIT(10) << (i))
> > +
> > +/* Register to setup the duty cycle of the blink */
> > +#define MTK_MT6323_ISINK_CON0(i)      (0x0330 + 0x8 * (i))
> > +#define ISINK_DIM_DUTY(i)	      (((i) << 8) & GENMASK(12, 8))
> > +#define ISINK_DIM_DUTY_MASK	      GENMASK(12, 8)
> > +
> > +/* Register to setup the period of the blink */
> > +#define MTK_MT6323_ISINK_CON1(i)      (0x0332 + 0x8 * (i))
> > +#define ISINK_DIM_FSEL(i)	      ((i) & GENMASK(15, 0))
> > +#define ISINK_DIM_FSEL_MASK	      GENMASK(15, 0)
> > +
> > +/* Register to control the brightness */
> > +#define MTK_MT6323_ISINK_CON2(i)      (0x0334 + 0x8 * (i))
> > +#define ISINK_CH_STEP(i)	      (((i) << 12) & GENMASK(14, 12))
> > +#define ISINK_CH_STEP_MASK	      GENMASK(14, 12)
> > +#define ISINK_SFSTR0_TC(i)	      (((i) << 1) & GENMASK(2, 1))
> > +#define ISINK_SFSTR0_TC_MASK	      GENMASK(2, 1)
> > +#define ISINK_SFSTR0_EN		      BIT(0)
> > +#define ISINK_SFSTR0_EN_MASK	      BIT(0)
> > +
> > +/* Register to LED channel enablement */
> > +#define MTK_MT6323_ISINK_EN_CTRL      0x0356
> > +#define ISINK_CH_EN(i)		      BIT(i)
> > +#define ISINK_CH_EN_MASK(i)	      BIT(i)
> > +
> > +#define MTK_MAX_PERIOD		      10000
> > +#define MTK_MAX_DEVICES			  4
> > +#define MTK_MAX_BRIGHTNESS		  6
> > +
> > +struct mtk_led;
> 
> This is redundant.
> 
Will be fixed

> > +struct mtk_leds;
> > +
> > +/**
> > + * struct mtk_led - state container for the LED device
> > + * @id: the identifier in MT6323 LED device
> > + * @parent: the pointer to MT6323 LED controller
> > + * @cdev: LED class device for this LED device
> > + * @current_brightness: current state of the LED device
> > + */
> > +struct mtk_led {
> > +	int    id;
> > +	struct mtk_leds *parent;
> > +	struct led_classdev cdev;
> > +	u8 current_brightness;
> > +};
> > +
> > +/* struct mtk_leds -	state container for holding LED controller
> 
> Please stick to the kernel doc format consistently:
> 
> /**
>  *

Will be fixed

> > + *			of the driver
> > + * @dev:		The device pointer
> > + * @hw:			The underlying hardware providing shared
> > +			bus for the register operations
> 
> leading " *" is missing here
> 

Will be fixed

> > + * @led_num:		How much the LED device the controller could control
> > + * @lock:		The lock among process context
> > + * @led:		The array that contains the state of individual
> > +			LED device
> 
> Ditto.
> 

Will be fixed

> > + */
> > +struct mtk_leds {
> > +	struct device	*dev;
> > +	struct mt6397_chip *hw;
> > +	u8     led_num;
> > +	/* protect among process context */
> > +	struct mutex	 lock;
> > +	struct mtk_led	 led[4];
> > +};
> > +
> > +static void mtk_led_hw_off(struct led_classdev *cdev)
> > +{
> > +	struct mtk_led *led = container_of(cdev, struct mtk_led, cdev);
> > +	struct mtk_leds *leds = led->parent;
> > +	struct regmap *regmap = leds->hw->regmap;
> > +	unsigned int status;
> > +
> > +	status = ISINK_CH_EN(led->id);
> > +	regmap_update_bits(regmap, MTK_MT6323_ISINK_EN_CTRL,
> > +			   ISINK_CH_EN_MASK(led->id), ~status);
> 
> Let's check return value. The same applies the other occurrences
> of regmap API calls.


Will be fixed and applied to all the occurrences where regmap API being 
used.

> > +
> > +	usleep_range(100, 300);
> 
> Just out of curiosity - does the data sheet mention it or is it inferred
> empirically?
> 

it comes from that inferred empirically. 
leds can't being light on if without the delay

> > +	regmap_update_bits(regmap, MTK_MT6323_TOP_CKPDN2,
> > +			   RG_ISINK_CK_PDN_MASK(led->id),
> > +			   RG_ISINK_CK_PDN(led->id));
> > +
> > +	dev_dbg(leds->dev, "%s called for led%d\n",
> > +		__func__, led->id);
> 
> Let's remove this debug logging.
> 

will be removed 

> > +}
> > +
> > +static u8 get_mtk_led_hw_brightness(struct led_classdev *cdev)
> > +{
> > +	struct mtk_led *led = container_of(cdev, struct mtk_led, cdev);
> > +	struct mtk_leds *leds = led->parent;
> > +	struct regmap *regmap = leds->hw->regmap;
> > +	unsigned int status;
> > +
> > +	regmap_read(regmap, MTK_MT6323_TOP_CKPDN2, &status);
> > +	if (status & RG_ISINK_CK_PDN_MASK(led->id))
> > +		return 0;
> > +
> > +	regmap_read(regmap, MTK_MT6323_ISINK_EN_CTRL, &status);
> > +	if (!(status & ISINK_CH_EN(led->id)))
> > +		return 0;
> > +
> > +	regmap_read(regmap, MTK_MT6323_ISINK_CON2(led->id), &status);
> > +	return  ((status & ISINK_CH_STEP_MASK) >> 12) + 1;
> 
> What is 12? Please add a macro for it.
> 

will be fixed

> > +}
> > +
> > +static void mtk_led_hw_on(struct led_classdev *cdev)
> > +{
> > +	struct mtk_led *led = container_of(cdev, struct mtk_led, cdev);
> > +	struct mtk_leds *leds = led->parent;
> > +	struct regmap *regmap = leds->hw->regmap;
> > +	unsigned int status;
> > +
> > +	/* Setup required clock source, enable the corresponding
> 
> Kernel style comments please:
> 
> /*
>  *
>  */
> The same applies to the other occurrences thereof.
> Refer to Documentation/process/coding-style.rst (chapter 8).
> 

will be fixed and applied to all occurrences

> > +	 * clock and channel and let work with continuous blink as
> > +	 * the default
> > +	 */
> > +	regmap_update_bits(regmap, MTK_MT6323_TOP_CKCON1,
> > +			   RG_ISINK_CK_SEL_MASK(led->id), 0);
> > +
> > +	status = RG_ISINK_CK_PDN(led->id);
> > +	regmap_update_bits(regmap, MTK_MT6323_TOP_CKPDN2,
> > +			   RG_ISINK_CK_PDN_MASK(led->id), ~status);
> > +
> > +	usleep_range(100, 300);
> > +
> > +	regmap_update_bits(regmap, MTK_MT6323_ISINK_EN_CTRL,
> > +			   ISINK_CH_EN_MASK(led->id),
> > +			   ISINK_CH_EN(led->id));
> > +
> > +	regmap_update_bits(regmap, MTK_MT6323_ISINK_CON2(led->id),
> > +			   ISINK_CH_STEP_MASK,
> > +			   ISINK_CH_STEP(1));
> > +
> > +	regmap_update_bits(regmap, MTK_MT6323_ISINK_CON0(led->id),
> > +			   ISINK_DIM_DUTY_MASK, ISINK_DIM_DUTY(31));
> > +
> > +	regmap_update_bits(regmap, MTK_MT6323_ISINK_CON1(led->id),
> > +			   ISINK_DIM_FSEL_MASK, ISINK_DIM_FSEL(1000));
> > +
> > +	led->current_brightness = 1;
> > +
> > +	dev_dbg(leds->dev, "%s called for led%d\n",
> > +		__func__, led->id);
> 
> Let's remove this debug logging.
> 

will be removed

> > +}
> > +
> > +static int mtk_led_set_blink(struct led_classdev *cdev,
> > +			     unsigned long *delay_on,
> > +			     unsigned long *delay_off)
> > +{
> > +	struct mtk_led *led = container_of(cdev, struct mtk_led, cdev);
> > +	struct mtk_leds *leds = led->parent;
> > +	struct regmap *regmap = leds->hw->regmap;
> > +	u16 period;
> > +	u8 duty_cycle, duty_hw;
> > +
> > +	/* Units are in ms , if over the hardware able
> > +	 * to support, fallback into software blink
> > +	 */
> > +	if (*delay_on + *delay_off > MTK_MAX_PERIOD)
> > +		return -EINVAL;
> > +
> > +	/* LED subsystem requires a default user
> > +	 * friendly blink pattern for the LED so using
> > +	 * 1Hz duty cycle 50% here if without specific
> > +	 * value delay_on and delay off being assigned
> > +	 */
> > +	if (*delay_on == 0 && *delay_off == 0) {
> > +		*delay_on = 500;
> > +		*delay_off = 500;
> > +	}
> > +
> > +	period = *delay_on + *delay_off;
> > +
> > +	/* duty_cycle is the percentage of period during
> > +	 * which the led is ON
> > +	 */
> > +	duty_cycle = 100 * (*delay_on) / period;
> > +
> > +	mutex_lock(&leds->lock);
> > +
> > +	if (!led->current_brightness)
> > +		mtk_led_hw_on(cdev);
> > +
> > +	duty_hw = DIV_ROUND_CLOSEST(duty_cycle * 1000, 3125);
> 
> Please add a macro for 3125.
> 

will be fixed

> > +	regmap_update_bits(regmap, MTK_MT6323_ISINK_CON0(led->id),
> > +			   ISINK_DIM_DUTY_MASK, ISINK_DIM_DUTY(duty_hw));
> > +
> > +	regmap_update_bits(regmap, MTK_MT6323_ISINK_CON1(led->id),
> > +			   ISINK_DIM_FSEL_MASK, ISINK_DIM_FSEL(period - 1));
> > +
> > +	mutex_unlock(&leds->lock);
> > +
> > +	dev_dbg(leds->dev, "%s: Hardware blink! period=%dms duty=%d for led%d\n",
> > +		__func__, period, duty_cycle, led->id);
> 
> Let's remove this debug logging.
> 

will be removed

> > +
> > +	return 0;
> > +}
> > +
> > +static int mtk_led_set_brightness(struct led_classdev *cdev,
> > +				  enum led_brightness brightness)
> > +{
> > +	struct mtk_led *led = container_of(cdev, struct mtk_led, cdev);
> > +	struct mtk_leds *leds = led->parent;
> > +	struct regmap *regmap = leds->hw->regmap;
> > +
> > +	mutex_lock(&leds->lock);
> > +
> > +	if (!led->current_brightness && brightness)
> > +		mtk_led_hw_on(cdev);
> > +
> > +	if (brightness) {
> > +		/* Setup current output for the corresponding
> > +		 * brightness level
> > +		 */
> > +		regmap_update_bits(regmap, MTK_MT6323_ISINK_CON2(led->id),
> > +				   ISINK_CH_STEP_MASK,
> > +				   ISINK_CH_STEP(brightness - 1));
> > +
> > +		regmap_update_bits(regmap, MTK_MT6323_ISINK_CON2(led->id),
> > +				   ISINK_SFSTR0_TC_MASK | ISINK_SFSTR0_EN_MASK,
> > +				   ISINK_SFSTR0_TC(2) | ISINK_SFSTR0_EN);
> > +
> > +		dev_dbg(leds->dev, "Update led brightness:%d\n",
> > +			brightness);
> 
> Let's remove this debug logging.
> 

will be removed

> > +	}
> > +
> > +	if (!brightness)
> > +		mtk_led_hw_off(cdev);
> 
> It could be enclosed in "else " case of the above "if (brightness)"
> condition.
> 
good suggestion. will be enhanced

> > +	led->current_brightness = brightness;
> > +
> > +	mutex_unlock(&leds->lock);
> > +
> > +	return 0;
> > +}
> > +
> > +static int mt6323_led_probe(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct device_node *np = pdev->dev.of_node;
> > +	struct device_node *child;
> > +	struct mt6397_chip *hw = dev_get_drvdata(pdev->dev.parent);
> > +	struct mtk_leds *leds;
> > +	int ret, i = 0, count;
> > +	const char *state;
> > +	unsigned int status;
> > +
> > +	count = of_get_child_count(np);
> > +	if (!count)
> > +		return -ENODEV;
> > +
> > +	/* The number the LEDs on MT6323 could be support is
> > +	 * up to MTK_MAX_DEVICES
> > +	 */
> > +	count = (count <= MTK_MAX_DEVICES) ? count : MTK_MAX_DEVICES;
> > +
> > +	leds = devm_kzalloc(dev, sizeof(struct mtk_leds) +
> > +			    sizeof(struct mtk_led) * count,
> > +			    GFP_KERNEL);
> > +	if (!leds)
> > +		return -ENOMEM;
> > +
> > +	platform_set_drvdata(pdev, leds);
> > +	leds->dev = dev;
> > +
> > +	/* leds->hw points to the underlying bus for the register
> > +	 * controlled
> > +	 */
> > +	leds->hw = hw;
> > +	mutex_init(&leds->lock);
> > +	leds->led_num = count;
> > +
> > +	status = RG_DRV_32K_CK_PDN;
> > +	regmap_update_bits(leds->hw->regmap, MTK_MT6323_TOP_CKPDN0,
> > +			   RG_DRV_32K_CK_PDN_MASK, ~status);
> > +
> > +	/* Waiting for 32K stable prior to give the default value
> 
> Could you shed more light on this statement? How data sheet explains
> that?

it is also from inferred empirically but that could be removed
because 32k clock should be stable before the hardware is being 
enabled.

> > +	 * to each LED state decided through these useful common
> > +	 * propertys such as label, linux,default-trigger and
> 
> s/propertys/properties/
> 

will be fixed

> > +	 * default-state
> > +	 */
> > +	usleep_range(300, 500);
> > +
> > +	for_each_available_child_of_node(np, child) {
> > +		leds->led[i].cdev.name =
> > +			of_get_property(child, "label", NULL) ? :
> > +					child->name;
> > +		leds->led[i].cdev.default_trigger = of_get_property(child,
> > +						    "linux,default-trigger",
> > +						    NULL);
> > +		leds->led[i].cdev.max_brightness = MTK_MAX_BRIGHTNESS;
> > +		leds->led[i].cdev.brightness_set_blocking =
> > +					mtk_led_set_brightness;
> > +		leds->led[i].cdev.blink_set = mtk_led_set_blink;
> > +		leds->led[i].id = i;
> > +		leds->led[i].parent = leds;
> > +		state = of_get_property(child, "default-state", NULL);
> > +		if (state) {
> > +			if (!strcmp(state, "keep")) {
> > +				leds->led[i].current_brightness =
> > +				get_mtk_led_hw_brightness(&leds->led[i].cdev);
> > +			} else if (!strcmp(state, "on")) {
> > +				mtk_led_set_brightness(&leds->led[i].cdev, 1);
> > +			} else  {
> > +				mtk_led_set_brightness(&leds->led[i].cdev,
> > +						       0);
> > +			}
> > +		}
> > +		ret = devm_led_classdev_register(dev, &leds->led[i].cdev);
> > +		if (ret) {
> > +			dev_err(&pdev->dev, "Failed to register LED: %d\n",
> > +				ret);
> > +			return ret;
> > +		}
> > +		leds->led[i].cdev.dev->of_node = child;
> > +		i++;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int mt6323_led_remove(struct platform_device *pdev)
> > +{
> > +	struct mtk_leds *leds = platform_get_drvdata(pdev);
> > +	int i;
> > +
> > +	/* Turned the LED to OFF state if driver removal */
> 
> s/if/on/

will be fixed
> > +	for (i = 0 ; i < leds->led_num ; i++)
> > +		mtk_led_hw_off(&leds->led[i].cdev);
> > +
> > +	regmap_update_bits(leds->hw->regmap, MTK_MT6323_TOP_CKPDN0,
> > +			   RG_DRV_32K_CK_PDN_MASK, RG_DRV_32K_CK_PDN);
> 
> Please add mutex_destroy here.
> 

will be fixed
> > +	return 0;
> > +}
> > +
> > +static const struct of_device_id mt6323_led_dt_match[] = {
> > +	{ .compatible = "mediatek,mt6323-led" },
> > +	{},
> > +};
> > +MODULE_DEVICE_TABLE(of, mt6323_led_dt_match);
> > +
> > +static struct platform_driver mt6323_led_driver = {
> > +	.probe		= mt6323_led_probe,
> > +	.remove		= mt6323_led_remove,
> > +	.driver		= {
> > +		.name	= "mt6323-led",
> > +		.of_match_table = mt6323_led_dt_match,
> > +	},
> > +};
> > +
> > +module_platform_driver(mt6323_led_driver);
> > +
> > +MODULE_DESCRIPTION("LED driver for Mediatek MT6323 PMIC");
> > +MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
> > +MODULE_LICENSE("GPL v2");
> 
> MODULE_LICENSE("GPL") since you are allowing also later version.
> 

will be fixed

> Please also adress the following sparse warnings:
> 
> drivers/leds/leds-mt6323.c:166:9: warning: cast truncates bits from
> constant value (7ffffffff000 becomes fffff000)
> drivers/leds/leds-mt6323.c:170:9: warning: cast truncates bits from
> constant value (1fffffffff00 becomes ffffff00)
> drivers/leds/leds-mt6323.c:173:9: warning: cast truncates bits from
> constant value (ffffffffffff becomes ffffffff)
> drivers/leds/leds-mt6323.c:221:9: warning: cast truncates bits from
> constant value (1fffffffff00 becomes ffffff00)
> drivers/leds/leds-mt6323.c:224:9: warning: cast truncates bits from
> constant value (ffffffffffff becomes ffffffff)
> drivers/leds/leds-mt6323.c:251:17: warning: cast truncates bits from
> constant value (7ffffffff000 becomes fffff000)
> drivers/leds/leds-mt6323.c:255:17: warning: cast truncates bits from
> constant value (7ffffffff becomes ffffffff
> 

will be fixed

^ permalink raw reply

* Re: [PATCH 1/2] spi: When no dma_chan map buffers with spi_master's parent
From: Andy Shevchenko @ 2017-01-28 22:17 UTC (permalink / raw)
  To: Daniel Kurtz
  Cc: dtor, groeck, Nicolas Boichat, Robin Murphy, Leilk Liu,
	Mark Brown, Matthias Brugger, open list:SPI SUBSYSTEM, open list,
	moderated list:ARM/Mediatek SoC support,
	moderated list:ARM/Mediatek SoC support
In-Reply-To: <20170126162154.124287-1-djkurtz@chromium.org>

On Thu, Jan 26, 2017 at 6:21 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> Back before commit 1dccb598df54 ("arm64: simplify dma_get_ops"), for
> arm64, devices for which dma_ops were not explicitly set were automatically
> configured to use swiotlb_dma_ops, since this was hard-coded as the
> global "dma_ops" in arm64_dma_init().
>
> Now that global "dma_ops" has been removed, all devices much have their
> dma_ops explicitly set by a call to arch_setup_dma_ops(), otherwise the
> device is assigned dummy_dma_ops, and thus calls to map_sg for such a
> device will fail (return 0).
>
> Mediatek SPI uses DMA but does not use a dma channel.  Support for this
> was added by commit c37f45b5f1cd ("spi: support spi without dma channel
> to use can_dma()"), which uses the master_spi dev to DMA map buffers.
>
> The master_spi device is not a platform device, rather it is created
> in spi_alloc_device(), and therefore its dma_ops are never set.
>
> Therefore, when the mediatek SPI driver when it does DMA (for large SPI
> transactions > 32 bytes), SPI will use spi_map_buf()->dma_map_sg() to
> map the buffer for use in DMA.  But dma_map_sg()->dma_map_sg_attrs() returns
> 0, because ops->map_sg is dummy_dma_ops->__dummy_map_sg, and hence
> spi_map_buf() returns -ENOMEM (-12).
>
> Fix this by using the real spi_master's parent device which should be a
> real physical device with DMA properties.

Wouldn't be better to copy necessary stuff from parent device to its
child? Like DMA mask propagation (I dunno if there are such in SPI,
but at least many other drivers are doing that).

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply

* Re: [GIT PULL] arm: mediatek: dts changes for v4.11
From: Olof Johansson @ 2017-01-30  1:20 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: James Liao, Leilk Liu, zhiyong.tao, John Crispin, Dawei Chien,
	arm, moderated list:ARM/Mediatek SoC support, honghui.zhang,
	xiaolei li, linux-arm-kernel@lists.infradead.org
In-Reply-To: <82e017a8-ade7-b16f-740c-6c106f2f8049@gmail.com>

On Wed, Jan 25, 2017 at 02:46:56PM +0100, Matthias Brugger wrote:
> Hi Arnd, hi Olof,
> 
> Please merge the following changes for 32-bit dts files.
> 
> Thanks,
> Matthias
> 
> ---
> 
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
> 
>   Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
> 
> are available in the git repository at:
> 
>   https://github.com/mbgg/linux-mediatek.git tags/v4.10-next-dts32
> 
> for you to fetch changes up to e348dc74f798c2df31c685bf0c814396f4f3b735:
> 
>   arm: dts: mt2701: Add thermal device node. (2017-01-24 11:24:35 +0100)
> 
> ----------------------------------------------------------------
> Lots of updates for mt2701:
> Rearrange the dt nodes and fix unit address for pincontroler
> Add nodes for:
> - clock controller subsystems
> - scpsys controller
> - iommu and smi
> - spi
> - nand
> - auxadc
> - thermal controller and zones
> 
> Email address updated for mt7623 devicetree files.

Merged, thanks!


-Olof

^ permalink raw reply

* Re: [GIT PULL] arm64: mediatek: dts changes for v4.11
From: Olof Johansson @ 2017-01-30  1:21 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: Dawei Chien, arm-DgEjT+Ai2ygdnm+yROfE0A,
	moderated list:ARM/Mediatek SoC support, Bibby Hsieh,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <943b4e63-d2bc-0b9c-f4a7-4689f2ac48ea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Wed, Jan 25, 2017 at 02:48:24PM +0100, Matthias Brugger wrote:
> Hi Arnd, hi Olof,
> 
> Please merge the following changes for 64-bit dts files.
> 
> Thanks,
> Matthias
> 
> ---
> 
> The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
> 
>   Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
> 
> are available in the git repository at:
> 
>   https://github.com/mbgg/linux-mediatek.git tags/v4.10-next-dts
> 
> for you to fetch changes up to 6de18454e06f4eb9c0c7008d3999cd1d0b289d42:
> 
>   arm64: dts: mt8173: add node for thermal calibration (2017-01-23 10:18:13
> +0100)
> 
> ----------------------------------------------------------------
> For mt8173:
> - set mm_sel clock to 400 MHz to support 4K HDMI
> - adjust power efficiency between the little and big cores
> - add a node for thermal calibration via e-fuse data

Merged, thanks.


-Olof

^ permalink raw reply

* Re: [PATCH 1/2] spi: When no dma_chan map buffers with spi_master's parent
From: Robin Murphy @ 2017-01-30 11:44 UTC (permalink / raw)
  To: Andy Shevchenko, Daniel Kurtz
  Cc: Nicolas Boichat, Leilk Liu, open list, open list:SPI SUBSYSTEM,
	Matthias Brugger, Mark Brown,
	moderated list:ARM/Mediatek SoC support, groeck, dtor,
	moderated list:ARM/Mediatek SoC support
In-Reply-To: <CAHp75Vfzz7U3=R4dFSgr-eXuOfH1_eLDKcPSWmWdUcTS_tggdw@mail.gmail.com>

On 28/01/17 22:17, Andy Shevchenko wrote:
> On Thu, Jan 26, 2017 at 6:21 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
>> Back before commit 1dccb598df54 ("arm64: simplify dma_get_ops"), for
>> arm64, devices for which dma_ops were not explicitly set were automatically
>> configured to use swiotlb_dma_ops, since this was hard-coded as the
>> global "dma_ops" in arm64_dma_init().
>>
>> Now that global "dma_ops" has been removed, all devices much have their
>> dma_ops explicitly set by a call to arch_setup_dma_ops(), otherwise the
>> device is assigned dummy_dma_ops, and thus calls to map_sg for such a
>> device will fail (return 0).
>>
>> Mediatek SPI uses DMA but does not use a dma channel.  Support for this
>> was added by commit c37f45b5f1cd ("spi: support spi without dma channel
>> to use can_dma()"), which uses the master_spi dev to DMA map buffers.
>>
>> The master_spi device is not a platform device, rather it is created
>> in spi_alloc_device(), and therefore its dma_ops are never set.
>>
>> Therefore, when the mediatek SPI driver when it does DMA (for large SPI
>> transactions > 32 bytes), SPI will use spi_map_buf()->dma_map_sg() to
>> map the buffer for use in DMA.  But dma_map_sg()->dma_map_sg_attrs() returns
>> 0, because ops->map_sg is dummy_dma_ops->__dummy_map_sg, and hence
>> spi_map_buf() returns -ENOMEM (-12).
>>
>> Fix this by using the real spi_master's parent device which should be a
>> real physical device with DMA properties.
> 
> Wouldn't be better to copy necessary stuff from parent device to its
> child? Like DMA mask propagation (I dunno if there are such in SPI,
> but at least many other drivers are doing that).

Absolutely not. The "necessary stuff" includes arch-specific things
which would require filling the SPI code with arch-specific #ifdefs, and
may go as far as private data structures held by other drivers (e.g.
IOMMUs) which the SPI code cannot even touch, let alone know what to do
with. The "parent device" here *is* the real DMA master device (as
described by firmware and configured by the arch code accordingly), so
using any other device for DMA is just plain wrong.

Robin.

^ permalink raw reply

* Re: [PATCH -next] mtd: nand: mediatek: remove redundant dev_err call in mtk_nfc_probe()
From: Boris Brezillon @ 2017-01-30 12:36 UTC (permalink / raw)
  To: Wei Yongjun
  Cc: Richard Weinberger, linux-mediatek, linux-kernel, Marek Vasut,
	Wei Yongjun, Matthias Brugger, linux-mtd, Cyrille Pitchen,
	Brian Norris, David Woodhouse, linux-arm-kernel
In-Reply-To: <20170117142246.9607-1-weiyj.lk@gmail.com>

On Tue, 17 Jan 2017 14:22:46 +0000
Wei Yongjun <weiyj.lk@gmail.com> wrote:

> From: Wei Yongjun <weiyongjun1@huawei.com>
> 
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 

Applied.

Thanks,

Boris

> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
>  drivers/mtd/nand/mtk_nand.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/mtk_nand.c b/drivers/mtd/nand/mtk_nand.c
> index 6c3eed3..6c517c6 100644
> --- a/drivers/mtd/nand/mtk_nand.c
> +++ b/drivers/mtd/nand/mtk_nand.c
> @@ -1383,7 +1383,6 @@ static int mtk_nfc_probe(struct platform_device *pdev)
>  	nfc->regs = devm_ioremap_resource(dev, res);
>  	if (IS_ERR(nfc->regs)) {
>  		ret = PTR_ERR(nfc->regs);
> -		dev_err(dev, "no nfi base\n");
>  		goto release_ecc;
>  	}
>  
> 
> 
> 

^ permalink raw reply

* Re: [PATCH v2 1/2] Documentation: mtk-quadspi: update DT bindings
From: Cyrille Pitchen @ 2017-01-30 12:49 UTC (permalink / raw)
  To: Rob Herring, Guochun Mao
  Cc: Brian Norris, John Crispin, David Woodhouse, Boris Brezillon,
	Marek Vasut, Richard Weinberger, Mark Rutland, Matthias Brugger,
	Russell King, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170127222936.d342eloplti27p4s@rob-hp-laptop>

Le 27/01/2017 à 23:29, Rob Herring a écrit :
> On Wed, Jan 25, 2017 at 11:38:34AM +0800, Guochun Mao wrote:
>> Add "mediatek,mt2701-nor" for nor flash node's compatible.
>>
>> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>> ---
>>  .../devicetree/bindings/mtd/mtk-quadspi.txt        |    8 +++++++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> 
Applied to the github spi-nor tree.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Applied "spi: mediatek: Only do dma for 4-byte aligned buffers" to the spi tree
From: Mark Brown @ 2017-01-31 20:02 UTC (permalink / raw)
  To: Daniel Kurtz
  Cc: drinkcat, Leilk Liu, Robin Murphy, open list, linux-spi,
	Matthias Brugger, Mark Brown,
	moderated list:ARM/Mediatek SoC, support, groeck, dtor,
	moderated list:ARM/Mediatek SoC, support
In-Reply-To: <20170126162154.124287-2-djkurtz@chromium.org>

The patch

   spi: mediatek: Only do dma for 4-byte aligned buffers

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 1ce24864bff40e11500a699789412115fdf244bf Mon Sep 17 00:00:00 2001
From: Daniel Kurtz <djkurtz@chromium.org>
Date: Fri, 27 Jan 2017 00:21:54 +0800
Subject: [PATCH] spi: mediatek: Only do dma for 4-byte aligned buffers

Mediatek SPI DMA only works when tx and rx buffer addresses are 4-byte
aligned.

Unaligned DMA transactions appeared to work previously, since we the
spi core was incorrectly using the spi_master device for dma, which
had a 0 dma_mask, and therefore the swiotlb dma map operations were
falling back to using bounce buffers.  Since each DMA transaction would
use its own buffer, the mapped starting address of each transaction was
always aligned.  When doing real DMA, the mapped address will share the
alignment of the raw tx/rx buffer provided by the SPI user, which may or
may not be aligned.

If a buffer is not aligned, we cannot use DMA, and must use FIFO based
transaction instead.

So, this patch implements a scheme that allows using the FIFO for
arbitrary length transactions (larger than the 32-byte FIFO size) by
reloading the FIFO in the interrupt handler.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Cc: Leilk Liu <leilk.liu@mediatek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/spi/spi-mt65xx.c | 37 +++++++++++++++++++++++++++++++++----
 1 file changed, 33 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 899d7a8f0889..278867a31950 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -73,7 +73,7 @@
 #define MTK_SPI_IDLE 0
 #define MTK_SPI_PAUSED 1
 
-#define MTK_SPI_MAX_FIFO_SIZE 32
+#define MTK_SPI_MAX_FIFO_SIZE 32U
 #define MTK_SPI_PACKET_SIZE 1024
 
 struct mtk_spi_compatible {
@@ -333,7 +333,7 @@ static int mtk_spi_fifo_transfer(struct spi_master *master,
 	struct mtk_spi *mdata = spi_master_get_devdata(master);
 
 	mdata->cur_transfer = xfer;
-	mdata->xfer_len = xfer->len;
+	mdata->xfer_len = min(MTK_SPI_MAX_FIFO_SIZE, xfer->len);
 	mtk_spi_prepare_transfer(master, xfer);
 	mtk_spi_setup_packet(master);
 
@@ -410,7 +410,10 @@ static bool mtk_spi_can_dma(struct spi_master *master,
 			    struct spi_device *spi,
 			    struct spi_transfer *xfer)
 {
-	return xfer->len > MTK_SPI_MAX_FIFO_SIZE;
+	/* Buffers for DMA transactions must be 4-byte aligned */
+	return (xfer->len > MTK_SPI_MAX_FIFO_SIZE &&
+		(unsigned long)xfer->tx_buf % 4 == 0 &&
+		(unsigned long)xfer->rx_buf % 4 == 0);
 }
 
 static int mtk_spi_setup(struct spi_device *spi)
@@ -451,7 +454,33 @@ static irqreturn_t mtk_spi_interrupt(int irq, void *dev_id)
 					&reg_val, remainder);
 			}
 		}
-		spi_finalize_current_transfer(master);
+
+		trans->len -= mdata->xfer_len;
+		if (!trans->len) {
+			spi_finalize_current_transfer(master);
+			return IRQ_HANDLED;
+		}
+
+		if (trans->tx_buf)
+			trans->tx_buf += mdata->xfer_len;
+		if (trans->rx_buf)
+			trans->rx_buf += mdata->xfer_len;
+
+		mdata->xfer_len = min(MTK_SPI_MAX_FIFO_SIZE, trans->len);
+		mtk_spi_setup_packet(master);
+
+		cnt = trans->len / 4;
+		iowrite32_rep(mdata->base + SPI_TX_DATA_REG, trans->tx_buf, cnt);
+
+		remainder = trans->len % 4;
+		if (remainder > 0) {
+			reg_val = 0;
+			memcpy(&reg_val, trans->tx_buf + (cnt * 4), remainder);
+			writel(reg_val, mdata->base + SPI_TX_DATA_REG);
+		}
+
+		mtk_spi_enable_transfer(master);
+
 		return IRQ_HANDLED;
 	}
 
-- 
2.11.0

^ permalink raw reply related

* Applied "spi: When no dma_chan map buffers with spi_master's parent" to the spi tree
From: Mark Brown @ 2017-01-31 20:02 UTC (permalink / raw)
  To: Daniel Kurtz
  Cc: drinkcat-F7+t8E8rja9g9hUCZPvPmw, Leilk Liu, Robin Murphy,
	open list, linux-spi-u79uwXL29TY76Z2rM5mHXA, Matthias Brugger,
	Mark Brown, moderated list:ARM/Mediatek SoC, support,
	groeck-F7+t8E8rja9g9hUCZPvPmw, dtor-F7+t8E8rja9g9hUCZPvPmw,
	moderated list:ARM/Mediatek SoC, support
In-Reply-To: <20170126162154.124287-1-djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

The patch

   spi: When no dma_chan map buffers with spi_master's parent

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 88b0aa544af58ce3be125a1845a227264ec9ab89 Mon Sep 17 00:00:00 2001
From: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Date: Fri, 27 Jan 2017 00:21:53 +0800
Subject: [PATCH] spi: When no dma_chan map buffers with spi_master's parent

Back before commit 1dccb598df54 ("arm64: simplify dma_get_ops"), for
arm64, devices for which dma_ops were not explicitly set were automatically
configured to use swiotlb_dma_ops, since this was hard-coded as the
global "dma_ops" in arm64_dma_init().

Now that global "dma_ops" has been removed, all devices much have their
dma_ops explicitly set by a call to arch_setup_dma_ops(), otherwise the
device is assigned dummy_dma_ops, and thus calls to map_sg for such a
device will fail (return 0).

Mediatek SPI uses DMA but does not use a dma channel.  Support for this
was added by commit c37f45b5f1cd ("spi: support spi without dma channel
to use can_dma()"), which uses the master_spi dev to DMA map buffers.

The master_spi device is not a platform device, rather it is created
in spi_alloc_device(), and therefore its dma_ops are never set.

Therefore, when the mediatek SPI driver when it does DMA (for large SPI
transactions > 32 bytes), SPI will use spi_map_buf()->dma_map_sg() to
map the buffer for use in DMA.  But dma_map_sg()->dma_map_sg_attrs() returns
0, because ops->map_sg is dummy_dma_ops->__dummy_map_sg, and hence
spi_map_buf() returns -ENOMEM (-12).

Fix this by using the real spi_master's parent device which should be a
real physical device with DMA properties.

Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Fixes: c37f45b5f1cd ("spi: support spi without dma channel to use can_dma()")
Cc: Leilk Liu <leilk.liu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 drivers/spi/spi.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 656dd3e3220c..f4d412e48e1c 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -805,12 +805,12 @@ static int __spi_map_msg(struct spi_master *master, struct spi_message *msg)
 	if (master->dma_tx)
 		tx_dev = master->dma_tx->device->dev;
 	else
-		tx_dev = &master->dev;
+		tx_dev = master->dev.parent;
 
 	if (master->dma_rx)
 		rx_dev = master->dma_rx->device->dev;
 	else
-		rx_dev = &master->dev;
+		rx_dev = master->dev.parent;
 
 	list_for_each_entry(xfer, &msg->transfers, transfer_list) {
 		if (!master->can_dma(master, msg->spi, xfer))
@@ -852,12 +852,12 @@ static int __spi_unmap_msg(struct spi_master *master, struct spi_message *msg)
 	if (master->dma_tx)
 		tx_dev = master->dma_tx->device->dev;
 	else
-		tx_dev = &master->dev;
+		tx_dev = master->dev.parent;
 
 	if (master->dma_rx)
 		rx_dev = master->dma_rx->device->dev;
 	else
-		rx_dev = &master->dev;
+		rx_dev = master->dev.parent;
 
 	list_for_each_entry(xfer, &msg->transfers, transfer_list) {
 		if (!master->can_dma(master, msg->spi, xfer))
-- 
2.11.0

^ permalink raw reply related

* Applied "ASoC: mt8173-max98090: remove the call to snd_soc_jack_add_pins." to the asoc tree
From: Mark Brown @ 2017-01-31 21:17 UTC (permalink / raw)
  To: Enric Balletbo i Serra
  Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Garlic Tseng,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jaroslav Kysela, Mark Brown,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170127152042.7631-1-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>

The patch

   ASoC: mt8173-max98090: remove the call to snd_soc_jack_add_pins.

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From b1b9e0d3d98ebb1a228d9994b4c9dbac7215e2b9 Mon Sep 17 00:00:00 2001
From: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Date: Fri, 27 Jan 2017 16:20:42 +0100
Subject: [PATCH] ASoC: mt8173-max98090: remove the call to
 snd_soc_jack_add_pins.

The snd_soc_card_jack_new function can call snd_soc_jack_add_pins for
you, so pass directly the pins struct when you create the new jack.

Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 sound/soc/mediatek/mt8173/mt8173-max98090.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/sound/soc/mediatek/mt8173/mt8173-max98090.c b/sound/soc/mediatek/mt8173/mt8173-max98090.c
index 5524a2c727ec..46c8e6ae00b4 100644
--- a/sound/soc/mediatek/mt8173/mt8173-max98090.c
+++ b/sound/soc/mediatek/mt8173/mt8173-max98090.c
@@ -79,17 +79,11 @@ static int mt8173_max98090_init(struct snd_soc_pcm_runtime *runtime)
 
 	/* enable jack detection */
 	ret = snd_soc_card_jack_new(card, "Headphone", SND_JACK_HEADPHONE,
-				    &mt8173_max98090_jack, NULL, 0);
+				    &mt8173_max98090_jack,
+				    mt8173_max98090_jack_pins,
+				    ARRAY_SIZE(mt8173_max98090_jack_pins));
 	if (ret) {
-		dev_err(card->dev, "Can't snd_soc_jack_new %d\n", ret);
-		return ret;
-	}
-
-	ret = snd_soc_jack_add_pins(&mt8173_max98090_jack,
-				    ARRAY_SIZE(mt8173_max98090_jack_pins),
-				    mt8173_max98090_jack_pins);
-	if (ret) {
-		dev_err(card->dev, "Can't snd_soc_jack_add_pins %d\n", ret);
+		dev_err(card->dev, "Can't create a new Jack %d\n", ret);
 		return ret;
 	}
 
-- 
2.11.0

^ permalink raw reply related

* Re: [PATCH v20 2/4] mailbox: mediatek: Add Mediatek CMDQ driver
From: Jassi Brar @ 2017-02-01  5:22 UTC (permalink / raw)
  To: Horng-Shyang Liao
  Cc: Rob Herring, Matthias Brugger, Daniel Kurtz, Sascha Hauer,
	Devicetree List, Linux Kernel Mailing List,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Sascha Hauer,
	Philipp Zabel, Nicolas Boichat, CK HU, cawa cheng, Bibby Hsieh,
	YT Shen, Daoyuan Huang, Damon Chu
In-Reply-To: <1485419833.990.1.camel@mtksdaap41>

On Thu, Jan 26, 2017 at 2:07 PM, Horng-Shyang Liao <hs.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> Hi Jassi,
>
> On Thu, 2017-01-26 at 10:08 +0530, Jassi Brar wrote:
>> On Wed, Jan 4, 2017 at 8:36 AM, HS Liao <hs.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>>
>> > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
>> > new file mode 100644
>> > index 0000000..747bcd3
>> > --- /dev/null
>> > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
>>
>> ...
>>
>> > +static void cmdq_task_exec(struct cmdq_pkt *pkt, struct cmdq_thread *thread)
>> > +{
>> > +       struct cmdq *cmdq;
>> > +       struct cmdq_task *task;
>> > +       unsigned long curr_pa, end_pa;
>> > +
>> > +       cmdq = dev_get_drvdata(thread->chan->mbox->dev);
>> > +
>> > +       /* Client should not flush new tasks if suspended. */
>> > +       WARN_ON(cmdq->suspended);
>> > +
>> > +       task = kzalloc(sizeof(*task), GFP_ATOMIC);
>> > +       task->cmdq = cmdq;
>> > +       INIT_LIST_HEAD(&task->list_entry);
>> > +       task->pa_base = dma_map_single(cmdq->mbox.dev, pkt->va_base,
>> > +                                      pkt->cmd_buf_size, DMA_TO_DEVICE);
>> >
>> You seem to parse the requests and responses, that should ideally be
>> done in client driver.
>> Also, we are here in atomic context, can you move it in client driver
>> (before the spin_lock)?
>> Maybe by adding a new 'pa_base' member as well in 'cmdq_pkt'.
>
> will do
>
>> ....
>> > +
>> > +       cmdq->mbox.num_chans = CMDQ_THR_MAX_COUNT;
>> > +       cmdq->mbox.ops = &cmdq_mbox_chan_ops;
>> > +       cmdq->mbox.of_xlate = cmdq_xlate;
>> > +
>> > +       /* make use of TXDONE_BY_ACK */
>> > +       cmdq->mbox.txdone_irq = false;
>> > +       cmdq->mbox.txdone_poll = false;
>> > +
>> > +       for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
>> >
>> You mean  i < CMDQ_THR_MAX_COUNT
>
> will do
>
>> > +               cmdq->thread[i].base = cmdq->base + CMDQ_THR_BASE +
>> > +                               CMDQ_THR_SIZE * i;
>> > +               INIT_LIST_HEAD(&cmdq->thread[i].task_busy_list);
>> >
>> You seem the queue mailbox requests in this controller driver? why not
>> use the mailbox api for that?
>>
>> > +               init_timer(&cmdq->thread[i].timeout);
>> > +               cmdq->thread[i].timeout.function = cmdq_thread_handle_timeout;
>> > +               cmdq->thread[i].timeout.data = (unsigned long)&cmdq->thread[i];
>> >
>> Here again... you seem to ignore the polling mechanism provided by the
>> mailbox api, and implement your own.
>
> The queue is used to record the tasks which are flushed into CMDQ
> hardware (GCE). We are handling time critical tasks, so we have to
> queue them in GCE rather than a software queue (e.g. mailbox buffer).
> Let me use display as an example. Many display tasks are flushed into
> CMDQ to wait next vsync event. When vsync event is triggered by display
> hardware, GCE needs to process all flushed tasks "within vblank" to
> prevent garbage on screen. This is all done by GCE (without CPU)
> to fulfill time critical requirement. After GCE finish its work,
> it will generate interrupts, and then CMDQ driver will let clients know
> which tasks are done.
>
Does the GCE provide any 'lock' to prevent modifying (by adding tasks
to) the GCE h/w buffer when it is processing it at vsync?  Otherwise
there maybe race/error. If there is such a 'lock' flag/irq, that could
help here. However, you are supposed to know your h/w better, so I
will accept this implementation assuming it can't be done any better.

Please address other comments and resubmit.

Thanks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v2 1/2] Documentation: mtk-quadspi: update DT bindings
From: Guochun Mao @ 2017-02-02  3:21 UTC (permalink / raw)
  To: Cyrille Pitchen, Rob Herring
  Cc: Brian Norris, John Crispin, David Woodhouse, Boris Brezillon,
	Marek Vasut, Richard Weinberger, Mark Rutland, Matthias Brugger,
	Russell King, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <90bfb55c-eb01-af2f-d2f7-49f1f33da3b2-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>

On Mon, 2017-01-30 at 13:49 +0100, Cyrille Pitchen wrote:
> Le 27/01/2017 à 23:29, Rob Herring a écrit :
> > On Wed, Jan 25, 2017 at 11:38:34AM +0800, Guochun Mao wrote:
> >> Add "mediatek,mt2701-nor" for nor flash node's compatible.
> >>
> >> Signed-off-by: Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >> ---
> >>  .../devicetree/bindings/mtd/mtk-quadspi.txt        |    8 +++++++-
> >>  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > 
> Applied to the github spi-nor tree.
> 
> Thanks!

Thank you very much!

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 1/2] Documentation: devicetree: change the mediatek ethernet compatible string
From: James Liao @ 2017-02-02  5:07 UTC (permalink / raw)
  To: John Crispin
  Cc: Rob Herring, Matthias Brugger, David S. Miller, netdev, Sean Wang,
	linux-mediatek, devicetree
In-Reply-To: <1485332455-34743-1-git-send-email-john@phrozen.org>

On Wed, 2017-01-25 at 09:20 +0100, John Crispin wrote:
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
> 
> The ethernet driver is currently of no real use until we finish and
> upstream the DSA driver. There are no users of this binding yet. It should
> be safe to fix this now before it is too late and we need to provide
> backward compatibility for the mt7623-eth compat string.
> 
> Reported-by: Sean Wang <sean.wang@mediatek.com>
> Signed-off-by: John Crispin <john@phrozen.org>

Acked-by: James Liao <jamesjj.liao@mediatek.com>

> ---
>  Documentation/devicetree/bindings/net/mediatek-net.txt |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/mediatek-net.txt b/Documentation/devicetree/bindings/net/mediatek-net.txt
> index c010faf..c7194e8 100644
> --- a/Documentation/devicetree/bindings/net/mediatek-net.txt
> +++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
> @@ -7,7 +7,7 @@ have dual GMAC each represented by a child node..
>  * Ethernet controller node
>  
>  Required properties:
> -- compatible: Should be "mediatek,mt7623-eth"
> +- compatible: Should be "mediatek,mt2701-eth"
>  - reg: Address and length of the register set for the device
>  - interrupts: Should contain the three frame engines interrupts in numeric
>  	order. These are fe_int0, fe_int1 and fe_int2.

^ permalink raw reply

* Re: [PATCH 2/2] net-next: ethernet: mediatek: change the compatible string
From: James Liao @ 2017-02-02  5:07 UTC (permalink / raw)
  To: John Crispin
  Cc: Rob Herring, Matthias Brugger, David S. Miller, netdev, Sean Wang,
	linux-mediatek, devicetree
In-Reply-To: <1485332455-34743-2-git-send-email-john@phrozen.org>

On Wed, 2017-01-25 at 09:20 +0100, John Crispin wrote:
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
> 
> The ethernet driver is currently of no real use until we finish and
> upstream the DSA driver. There are no users of this binding yet. It should
> be safe to fix this now before it is too late and we need to provide
> backward compatibility for the mt7623-eth compat string.
> 
> Reported-by: Sean Wang <sean.wang@mediatek.com>
> Signed-off-by: John Crispin <john@phrozen.org>

Acked-by: James Liao <jamesjj.liao@mediatek.com>

> ---
>  drivers/net/ethernet/mediatek/mtk_eth_soc.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 25ae0c5..9e75768 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2515,7 +2515,7 @@ static int mtk_remove(struct platform_device *pdev)
>  }
>  
>  const struct of_device_id of_mtk_match[] = {
> -	{ .compatible = "mediatek,mt7623-eth" },
> +	{ .compatible = "mediatek,mt2701-eth" },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, of_mtk_match);

^ permalink raw reply

* [PATCH] iommu: mtk: remove bogus 'select' statements
From: Arnd Bergmann @ 2017-02-02 14:29 UTC (permalink / raw)
  To: Joerg Roedel, Matthias Brugger
  Cc: Arnd Bergmann, Will Deacon, linux-kernel, iommu, linux-mediatek,
	Honghui Zhang, Andy Fleming, Robin Murphy, linux-arm-kernel

The mediatek IOMMU driver enables some drivers that it does not directly
rely on, and that causes a warning for build testing:

warning: (MTK_IOMMU_V1) selects COMMON_CLK_MT2701_VDECSYS which has unmet direct dependencies (COMMON_CLK && COMMON_CLK_MT2701)
warning: (MTK_IOMMU_V1) selects COMMON_CLK_MT2701_IMGSYS which has unmet direct dependencies (COMMON_CLK && COMMON_CLK_MT2701)
warning: (MTK_IOMMU_V1) selects COMMON_CLK_MT2701_MMSYS which has unmet direct dependencies (COMMON_CLK && COMMON_CLK_MT2701)

This removes the select statements.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/iommu/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index bb537d06d319..8b6fd8928819 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -352,9 +352,6 @@ config MTK_IOMMU_V1
 	select IOMMU_API
 	select MEMORY
 	select MTK_SMI
-	select COMMON_CLK_MT2701_MMSYS
-	select COMMON_CLK_MT2701_IMGSYS
-	select COMMON_CLK_MT2701_VDECSYS
 	help
 	  Support for the M4U on certain Mediatek SoCs. M4U generation 1 HW is
 	  Multimedia Memory Managememt Unit. This option enables remapping of
-- 
2.9.0

^ permalink raw reply related

* [PATCH 08/10] iommu/mediatek: Make use of iommu_device_register interface
From: Joerg Roedel @ 2017-02-03 15:17 UTC (permalink / raw)
  To: Will Deacon, Robin Murphy, Lorenzo Pieralisi, Alex Williamson,
	David Woodhouse
  Cc: Joerg Roedel, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1486135068-23994-1-git-send-email-joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>

From: Joerg Roedel <jroedel-l3A5Bk7waGM@public.gmane.org>

Register individual Mediatek IOMMUs to the iommu core and
add sysfs entries.

Cc: Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Signed-off-by: Joerg Roedel <jroedel-l3A5Bk7waGM@public.gmane.org>
---
 drivers/iommu/mtk_iommu.c | 26 ++++++++++++++++++++++++++
 drivers/iommu/mtk_iommu.h |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 1479c76..9fb7258 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -360,11 +360,15 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct iommu_domain *domain,
 
 static int mtk_iommu_add_device(struct device *dev)
 {
+	struct mtk_iommu_data *data;
 	struct iommu_group *group;
 
 	if (!dev->iommu_fwspec || dev->iommu_fwspec->ops != &mtk_iommu_ops)
 		return -ENODEV; /* Not a iommu client device */
 
+	data = dev->iommu_fwspec->iommu_priv;
+	iommu_device_link(&data->iommu, dev);
+
 	group = iommu_group_get_for_dev(dev);
 	if (IS_ERR(group))
 		return PTR_ERR(group);
@@ -375,9 +379,14 @@ static int mtk_iommu_add_device(struct device *dev)
 
 static void mtk_iommu_remove_device(struct device *dev)
 {
+	struct mtk_iommu_data *data;
+
 	if (!dev->iommu_fwspec || dev->iommu_fwspec->ops != &mtk_iommu_ops)
 		return;
 
+	data = dev->iommu_fwspec->iommu_priv;
+	iommu_device_unlink(&data->iommu, dev);
+
 	iommu_group_remove_device(dev);
 	iommu_fwspec_free(dev);
 }
@@ -497,6 +506,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 	struct mtk_iommu_data   *data;
 	struct device           *dev = &pdev->dev;
 	struct resource         *res;
+	resource_size_t		ioaddr;
 	struct component_match  *match = NULL;
 	void                    *protect;
 	int                     i, larb_nr, ret;
@@ -519,6 +529,7 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 	data->base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(data->base))
 		return PTR_ERR(data->base);
+	ioaddr = res->start;
 
 	data->irq = platform_get_irq(pdev, 0);
 	if (data->irq < 0)
@@ -567,6 +578,18 @@ static int mtk_iommu_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	ret = iommu_device_sysfs_add(&data->iommu, dev, NULL,
+				     "mtk-iommu.%pa", &ioaddr);
+	if (ret)
+		return ret;
+
+	data->iommu.ops    = &mtk_iommu_ops;
+	data->iommu.fwnode = &pdev->dev.of_node->fwnode;
+
+	ret = iommu_device_register(&data->iommu);
+	if (ret)
+		return ret;
+
 	if (!iommu_present(&platform_bus_type))
 		bus_set_iommu(&platform_bus_type, &mtk_iommu_ops);
 
@@ -577,6 +600,9 @@ static int mtk_iommu_remove(struct platform_device *pdev)
 {
 	struct mtk_iommu_data *data = platform_get_drvdata(pdev);
 
+	iommu_device_sysfs_remove(&data->iommu);
+	iommu_device_unregister(&data->iommu);
+
 	if (iommu_present(&platform_bus_type))
 		bus_set_iommu(&platform_bus_type, NULL);
 
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 50177f7..2a28ead 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -47,6 +47,8 @@ struct mtk_iommu_data {
 	struct iommu_group		*m4u_group;
 	struct mtk_smi_iommu		smi_imu;      /* SMI larb iommu info */
 	bool                            enable_4GB;
+
+	struct iommu_device		iommu;
 };
 
 static inline int compare_of(struct device *dev, void *data)
-- 
1.9.1

^ permalink raw reply related

* Re: [PATCH v2 2/2] arm: dts: mt2701: add nor flash node
From: Guochun Mao @ 2017-02-05  4:00 UTC (permalink / raw)
  To: Boris Brezillon, Marek Vasut
  Cc: Mark Rutland, devicetree, Richard Weinberger, Russell King,
	linux-kernel, Rob Herring, linux-mtd, John Crispin,
	Matthias Brugger, linux-mediatek, Cyrille Pitchen, Brian Norris,
	David Woodhouse, linux-arm-kernel
In-Reply-To: <1485315515-29942-3-git-send-email-guochun.mao@mediatek.com>

On Wed, 2017-01-25 at 11:38 +0800, Guochun Mao wrote:
> Add Mediatek nor flash node.
> 
> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
> ---
>  arch/arm/boot/dts/mt2701-evb.dts |   25 +++++++++++++++++++++++++
>  arch/arm/boot/dts/mt2701.dtsi    |   12 ++++++++++++
>  2 files changed, 37 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
> index 082ca88..85e5ae8 100644
> --- a/arch/arm/boot/dts/mt2701-evb.dts
> +++ b/arch/arm/boot/dts/mt2701-evb.dts
> @@ -24,6 +24,31 @@
>  	};
>  };
>  
> +&nor_flash {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&nor_pins_default>;
> +	status = "okay";
> +	flash@0 {
> +		compatible = "jedec,spi-nor";
> +		reg = <0>;
> +	};
> +};
> +
> +&pio {
> +	nor_pins_default: nor {
> +		pins1 {
> +			pinmux = <MT2701_PIN_240_EXT_XCS__FUNC_EXT_XCS>,
> +				 <MT2701_PIN_241_EXT_SCK__FUNC_EXT_SCK>,
> +				 <MT2701_PIN_239_EXT_SDIO0__FUNC_EXT_SDIO0>,
> +				 <MT2701_PIN_238_EXT_SDIO1__FUNC_EXT_SDIO1>,
> +				 <MT2701_PIN_237_EXT_SDIO2__FUNC_EXT_SDIO2>,
> +				 <MT2701_PIN_236_EXT_SDIO3__FUNC_EXT_SDIO3>;
> +			drive-strength = <MTK_DRIVE_4mA>;
> +			bias-pull-up;
> +		};
> +	};
> +};
> +
>  &uart0 {
>  	status = "okay";
>  };
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index bdf8954..1eefce4 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -227,6 +227,18 @@
>  		status = "disabled";
>  	};
>  
> +	nor_flash: spi@11014000 {
> +		compatible = "mediatek,mt2701-nor",
> +			     "mediatek,mt8173-nor";
> +		reg = <0 0x11014000 0 0xe0>;
> +		clocks = <&pericfg CLK_PERI_FLASH>,
> +			 <&topckgen CLK_TOP_FLASH_SEL>;
> +		clock-names = "spi", "sf";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		status = "disabled";
> +	};
> +
>  	mmsys: syscon@14000000 {
>  		compatible = "mediatek,mt2701-mmsys", "syscon";
>  		reg = <0 0x14000000 0 0x1000>;

Hi,
mtk-quadspi.txt had been updated as suggested.
Is there suggestion about this patch?
Thanks.

BR,
Guochun

^ permalink raw reply

* [PATCH -next] usb: mtu3: remove redundant dev_err call in get_ssusb_rscs()
From: Wei Yongjun @ 2017-02-05 16:25 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Matthias Brugger, Chunfeng Yun
  Cc: Wei Yongjun, linux-usb-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

From: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.

Signed-off-by: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
 drivers/usb/mtu3/mtu3_plat.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 19a345d..4559baa 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -252,10 +252,8 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
 
 	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ippc");
 	ssusb->ippc_base = devm_ioremap_resource(dev, res);
-	if (IS_ERR(ssusb->ippc_base)) {
-		dev_err(dev, "failed to map memory for ippc\n");
+	if (IS_ERR(ssusb->ippc_base))
 		return PTR_ERR(ssusb->ippc_base);
-	}
 
 	ssusb->dr_mode = usb_get_dr_mode(dev);
 	if (ssusb->dr_mode == USB_DR_MODE_UNKNOWN) {



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* Re: [PATCH v20 2/4] mailbox: mediatek: Add Mediatek CMDQ driver
From: Horng-Shyang Liao @ 2017-02-06  5:37 UTC (permalink / raw)
  To: Jassi Brar
  Cc: Rob Herring, Matthias Brugger, Daniel Kurtz, Sascha Hauer,
	Devicetree List, Linux Kernel Mailing List,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Sascha Hauer,
	Philipp Zabel, Nicolas Boichat, CK HU, cawa cheng, Bibby Hsieh,
	YT Shen, Daoyuan Huang, Damon Chu, Jo
In-Reply-To: <CABb+yY13VaFpYz6EExvAXLpAqEWDJ4R50WG0DYbXO6iCESbA5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Jassi,

On Wed, 2017-02-01 at 10:52 +0530, Jassi Brar wrote:
> On Thu, Jan 26, 2017 at 2:07 PM, Horng-Shyang Liao <hs.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> > Hi Jassi,
> >
> > On Thu, 2017-01-26 at 10:08 +0530, Jassi Brar wrote:
> >> On Wed, Jan 4, 2017 at 8:36 AM, HS Liao <hs.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> >>
> >> > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
> >> > new file mode 100644
> >> > index 0000000..747bcd3
> >> > --- /dev/null
> >> > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> >>
> >> ...
> >>
> >> > +static void cmdq_task_exec(struct cmdq_pkt *pkt, struct cmdq_thread *thread)
> >> > +{
> >> > +       struct cmdq *cmdq;
> >> > +       struct cmdq_task *task;
> >> > +       unsigned long curr_pa, end_pa;
> >> > +
> >> > +       cmdq = dev_get_drvdata(thread->chan->mbox->dev);
> >> > +
> >> > +       /* Client should not flush new tasks if suspended. */
> >> > +       WARN_ON(cmdq->suspended);
> >> > +
> >> > +       task = kzalloc(sizeof(*task), GFP_ATOMIC);
> >> > +       task->cmdq = cmdq;
> >> > +       INIT_LIST_HEAD(&task->list_entry);
> >> > +       task->pa_base = dma_map_single(cmdq->mbox.dev, pkt->va_base,
> >> > +                                      pkt->cmd_buf_size, DMA_TO_DEVICE);
> >> >
> >> You seem to parse the requests and responses, that should ideally be
> >> done in client driver.
> >> Also, we are here in atomic context, can you move it in client driver
> >> (before the spin_lock)?
> >> Maybe by adding a new 'pa_base' member as well in 'cmdq_pkt'.
> >
> > will do

I agree with moving dma_map_single out from spin_lock.

However, mailbox clients cannot map virtual memory to mailbox
controller's device for DMA. In our previous discussion, we decided to
remove mailbox_controller.h from clients to restrict their capabilities.

Please take a look at following link from 2016/9/22 to 2016/9/30 about
mailbox_controller.h.
https://patchwork.kernel.org/patch/9312953/

Is there any better place to do dma_map_single?

> >> ....
> >> > +
> >> > +       cmdq->mbox.num_chans = CMDQ_THR_MAX_COUNT;
> >> > +       cmdq->mbox.ops = &cmdq_mbox_chan_ops;
> >> > +       cmdq->mbox.of_xlate = cmdq_xlate;
> >> > +
> >> > +       /* make use of TXDONE_BY_ACK */
> >> > +       cmdq->mbox.txdone_irq = false;
> >> > +       cmdq->mbox.txdone_poll = false;
> >> > +
> >> > +       for (i = 0; i < ARRAY_SIZE(cmdq->thread); i++) {
> >> >
> >> You mean  i < CMDQ_THR_MAX_COUNT
> >
> > will do
> >
> >> > +               cmdq->thread[i].base = cmdq->base + CMDQ_THR_BASE +
> >> > +                               CMDQ_THR_SIZE * i;
> >> > +               INIT_LIST_HEAD(&cmdq->thread[i].task_busy_list);
> >> >
> >> You seem the queue mailbox requests in this controller driver? why not
> >> use the mailbox api for that?
> >>
> >> > +               init_timer(&cmdq->thread[i].timeout);
> >> > +               cmdq->thread[i].timeout.function = cmdq_thread_handle_timeout;
> >> > +               cmdq->thread[i].timeout.data = (unsigned long)&cmdq->thread[i];
> >> >
> >> Here again... you seem to ignore the polling mechanism provided by the
> >> mailbox api, and implement your own.
> >
> > The queue is used to record the tasks which are flushed into CMDQ
> > hardware (GCE). We are handling time critical tasks, so we have to
> > queue them in GCE rather than a software queue (e.g. mailbox buffer).
> > Let me use display as an example. Many display tasks are flushed into
> > CMDQ to wait next vsync event. When vsync event is triggered by display
> > hardware, GCE needs to process all flushed tasks "within vblank" to
> > prevent garbage on screen. This is all done by GCE (without CPU)
> > to fulfill time critical requirement. After GCE finish its work,
> > it will generate interrupts, and then CMDQ driver will let clients know
> > which tasks are done.
> >
> Does the GCE provide any 'lock' to prevent modifying (by adding tasks
> to) the GCE h/w buffer when it is processing it at vsync?  Otherwise

CPU will suspend GCE when adding a task (cmdq_thread_suspend),
and resume GCE after adding task is done (cmdq_thread_resume).
If GCE is processing task(s) at vsync and CPU wants to add a new task
at the same time, CPU will detect this situation
(by cmdq_thread_is_in_wfe), resume GCE immediately, and then add
following task(s) to wait for next vsync event.
All the above logic is implemented at cmdq_task_exec.

> there maybe race/error. If there is such a 'lock' flag/irq, that could
> help here. However, you are supposed to know your h/w better, so I
> will accept this implementation assuming it can't be done any better.
> 
> Please address other comments and resubmit.
> 
> Thanks

After we figure out a better solution for dma_map_single issue, I will
resubmit a new version.

Thanks,
HS


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 2/6] usb: mtu3: add reference clock
From: Chunfeng Yun @ 2017-02-06  7:03 UTC (permalink / raw)
  To: Matthias Brugger
  Cc: Mark Rutland, devicetree, Mathias Nyman, Felipe Balbi,
	Ian Campbell, Greg Kroah-Hartman, linux-usb, linux-kernel,
	Rob Herring, linux-mediatek, linux-arm-kernel
In-Reply-To: <60a7c32a-b7d9-5856-2a61-3670e266bea3@gmail.com>

On Wed, 2017-01-25 at 00:23 +0100, Matthias Brugger wrote:
> 
> On 01/20/2017 03:20 AM, Chunfeng Yun wrote:
> > On Thu, 2017-01-19 at 13:22 +0100, Matthias Brugger wrote:
> >>
> >> On 18/01/17 07:08, Chunfeng Yun wrote:
> >>> usually, the reference clock comes from 26M oscillator directly,
> >>> but some SoCs are not, add it for compatibility.
> >>>
> >>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> >>> ---
> >>>  drivers/usb/mtu3/mtu3.h      |    1 +
> >>>  drivers/usb/mtu3/mtu3_plat.c |   21 +++++++++++++++++++--
> >>>  2 files changed, 20 insertions(+), 2 deletions(-)
> > [...]
> >>> @@ -154,6 +162,7 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
> >>>  static void ssusb_rscs_exit(struct ssusb_mtk *ssusb)
> >>>  {
> >>>  	clk_disable_unprepare(ssusb->sys_clk);
> >>> +	clk_disable_unprepare(ssusb->ref_clk);
> >>>  	regulator_disable(ssusb->vusb33);
> >>>  	ssusb_phy_power_off(ssusb);
> >>>  	ssusb_phy_exit(ssusb);
> >>> @@ -216,6 +225,12 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
> >>>  		return PTR_ERR(ssusb->sys_clk);
> >>>  	}
> >>>
> >>> +	ssusb->ref_clk = devm_clk_get(dev, "ref_ck");
> >>> +	if (IS_ERR(ssusb->ref_clk)) {
> >>> +		dev_err(dev, "failed to get ref clock\n");
> >>> +		return PTR_ERR(ssusb->ref_clk);
> >>> +	}
> >>> +
> >>
> >> That would break older dts bindings, right?
> > Yes, So I send a new patch for the related dts. Maybe it's not a
> > problem, only one dts file need be updated currently.
> >
> >> ref_ck must be optional for the code.
> > I tend to make it be optional for the dts, but not for the code.
> > There are some "fixed-clock" which can be treated as dummy ones, and if
> > a clock is really optional, we can use one fixed-clock in dts, and keep
> > the code simple.
> > In fact, the reference clock is essential for usb controller.
> 
> Well the thing is that there are devices in the field with an older dtb 
> which would break on a newer kernel. That's why we need to make it work 
> with the old dtb in the code as well.
> 
Happy Chinese New Year!

Ok, I will make it optional.

Thanks and sorry for later reply.

> Regards,
> Matthias
> 
> >>
> >> Regards,
> >> Matthias
> >
> >

^ permalink raw reply

* Re: [PATCH 6/6] dt-bindings: mt8173-mtu3: add reference clock
From: Chunfeng Yun @ 2017-02-06  7:06 UTC (permalink / raw)
  To: Rob Herring
  Cc: Mathias Nyman, Felipe Balbi, Greg Kroah-Hartman, Matthias Brugger,
	Mark Rutland, Ian Campbell,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Linux USB List, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_JsqJg7=ykNkAbMeLqFT6HK-pK+FQAK7ZS_UMMy8ftrGM-KA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Mon, 2017-01-23 at 08:02 -0600, Rob Herring wrote:
> On Sat, Jan 21, 2017 at 7:49 PM, Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> > Hi,
> >
> > On Sat, 2017-01-21 at 14:11 -0600, Rob Herring wrote:
> >> On Wed, Jan 18, 2017 at 02:08:27PM +0800, Chunfeng Yun wrote:
> >> > add a reference clock for compatibility
> >>
> >> Why? This block suddenly has 2 clocks instead of 1?
> > In fact, there is a reference clock which comes from 26M oscillator
> > directly. I ignore it because it is a fixed-clock in DTS, and always
> > turned on for mt8173. But later, I find that I made a mistake before
> > when I bring up it on a new platform whose reference clock comes from
> > PLL, and need control it. So here add it, no matter it is a fixed-clock
> > or not.
> 
> Add this explanation to the changelog.
> 
Happy Chinese New Year!

Ok, I'll add it.

Thanks and sorry for later reply.

> Rob


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ 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