* Re: [PATCH 2/6] usb: mtu3: add reference clock
From: Matthias Brugger @ 2017-01-24 23:23 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Mathias Nyman, Felipe Balbi, Greg Kroah-Hartman, Rob Herring,
Mark Rutland, Ian Campbell, linux-kernel, linux-arm-kernel,
linux-usb, linux-mediatek, devicetree
In-Reply-To: <1484878825.10292.58.camel@mhfsdcap03>
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.
Regards,
Matthias
>>
>> Regards,
>> Matthias
>
>
^ permalink raw reply
* Re: [PATCH 3/4] leds: Add LED support for MT6323 PMIC
From: Jacek Anaszewski @ 2017-01-24 22:51 UTC (permalink / raw)
To: sean.wang, rpurdie, lee.jones, matthias.bgg, pavel, robh+dt,
mark.rutland
Cc: devicetree, linux-leds, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede
In-Reply-To: <1485143685-11808-4-git-send-email-sean.wang@mediatek.com>
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/
> 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.
> +
> +/* 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.
> +#define RG_DRV_32K_CK_PDN BIT(11)
> +#define RG_DRV_32K_CK_PDN_MASK BIT(11)
These macros also require MT6323 prefix.
> +
> +/* 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.
> +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:
/**
*
> + * of the driver
> + * @dev: The device pointer
> + * @hw: The underlying hardware providing shared
> + bus for the register operations
leading " *" is missing here
> + * @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.
> + */
> +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.
> +
> + usleep_range(100, 300);
Just out of curiosity - does the data sheet mention it or is it inferred
empirically?
> + 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.
> +}
> +
> +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.
> +}
> +
> +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).
> + * 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.
> +}
> +
> +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.
> + 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.
> +
> + 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.
> + }
> +
> + if (!brightness)
> + mtk_led_hw_off(cdev);
It could be enclosed in "else " case of the above "if (brightness)"
condition.
> + 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?
> + * to each LED state decided through these useful common
> + * propertys such as label, linux,default-trigger and
s/propertys/properties/
> + * 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/
> + 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.
> + 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.
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
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH 08/16] arm: dts: add spi nodes to the mt7623.dtsi file
From: Matthias Brugger @ 2017-01-24 22:39 UTC (permalink / raw)
To: John Crispin, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Andreas Färber
In-Reply-To: <1485170975-51813-9-git-send-email-john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
On 01/23/2017 12:29 PM, John Crispin wrote:
> Add SPI nodes to the mt7623.dtsi file.
>
> Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
> ---
> arch/arm/boot/dts/mt7623.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
> index 8ac4569..c8f38e1 100644
> --- a/arch/arm/boot/dts/mt7623.dtsi
> +++ b/arch/arm/boot/dts/mt7623.dtsi
> @@ -15,6 +15,7 @@
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/clock/mt2701-clk.h>
> +#include <dt-bindings/phy/phy.h>
Why do you need this include here?
Regards,
Matthias
> #include <dt-bindings/pinctrl/mt7623-pinfunc.h>
> #include <dt-bindings/power/mt2701-power.h>
> #include <dt-bindings/reset/mt2701-resets.h>
> @@ -281,6 +282,17 @@
> status = "disabled";
> };
>
> + spi: spi@1100a000 {
> + compatible = "mediatek,mt7623-spi",
> + "mediatek,mt6589-spi";
> + reg = <0 0x1100a000 0 0x1000>;
> + interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&pericfg CLK_PERI_SPI0>;
> + clock-names = "main";
> +
> + status = "disabled";
> + };
> +
> hifsys: syscon@1a000000 {
> compatible = "mediatek,mt7623-hifsys",
> "mediatek,mt2701-hifsys",
>
--
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] spi: mediatek: Manually set dma_ops for spi_master device
From: Mark Brown @ 2017-01-24 15:48 UTC (permalink / raw)
To: Daniel Kurtz
Cc: Leilk Liu, dtor, groeck, Matthias Brugger,
open list:SPI SUBSYSTEM, open list,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <20170124132519.13271-1-djkurtz@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
On Tue, Jan 24, 2017 at 09:25:19PM +0800, Daniel Kurtz wrote:
> The master_spi device is not a platform, rather it is created
> in spi_alloc_device(), and its dma_ops are never set.
Which is good because it's not a physical device and doesn't do DMA.
> Alternatively, perhaps we should be using master->dev.parent to dma map bufs
> in the "no dma channel case".
Yes, exactly.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2, 6/6] dt-bindings: phy-mt65xx-usb: add support for new version phy
From: Matthias Brugger @ 2017-01-24 15:19 UTC (permalink / raw)
To: Chunfeng Yun, Kishon Vijay Abraham I
Cc: Felipe Balbi, Rob Herring, Mark Rutland, Ian Campbell,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484900321-26933-6-git-send-email-chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Hi Chunfeng,
On 01/20/2017 09:18 AM, Chunfeng Yun wrote:
> add a new compatible string for "mt2712", and move reference clock
> into each port node;
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 91 +++++++++++++++++---
> 1 file changed, 77 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> index 33a2b1e..1d06604 100644
> --- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> @@ -6,21 +6,27 @@ This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
> Required properties (controller (parent) node):
> - compatible : should be one of
> "mediatek,mt2701-u3phy"
> + "mediatek,mt2712-u3phy"
> "mediatek,mt8173-u3phy"
> - - reg : offset and length of register for phy, exclude port's
> - register.
> - - clocks : a list of phandle + clock-specifier pairs, one for each
> - entry in clock-names
> - - clock-names : must contain
> - "u3phya_ref": for reference clock of usb3.0 analog phy.
>
> Required nodes : a sub-node is required for each port the controller
> provides. Address range information including the usual
> 'reg' property is used inside these nodes to describe
> the controller's topology.
>
> +Optional properties (controller (parent) node):
> + - reg : offset and length of register shared by multiple ports,
> + exclude port's private register. It is needed on mt2701
> + and mt8173, but not on mt2712.
> +
> Required properties (port (child) node):
> - reg : address and length of the register set for the port.
> +- clocks : a list of phandle + clock-specifier pairs, one for each
> + entry in clock-names
> +- clock-names : must contain
> + "ref_clk": 48M reference clock for HighSpeed analog phy; and
> + 26M reference clock for SuperSpeed analog phy, sometimes is
> + 24M, 25M or 27M, depended on platform.
> - #phy-cells : should be 1 (See second example)
> cell after port phandle is phy type from:
> - PHY_TYPE_USB2
The old bindings will need to be supported by the driver, they have to
stay here with a comment that they are deprecated.
Regards,
Matthias
> @@ -31,21 +37,31 @@ Example:
> u3phy: usb-phy@11290000 {
> compatible = "mediatek,mt8173-u3phy";
> reg = <0 0x11290000 0 0x800>;
> - clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
> - clock-names = "u3phya_ref";
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
> status = "okay";
>
> - phy_port0: port@11290800 {
> - reg = <0 0x11290800 0 0x800>;
> + u2port0: port@11290800 {
> + reg = <0 0x11290800 0 0x100>;
> + clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
> + clock-names = "ref_clk";
> #phy-cells = <1>;
> status = "okay";
> };
>
> - phy_port1: port@11291000 {
> - reg = <0 0x11291000 0 0x800>;
> + u3port0: port@11290900 {
> + reg = <0 0x11290800 0 0x700>;
> + clocks = <&clk26m>;
> + clock-names = "ref_clk";
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +
> + u2port1: port@11291000 {
> + reg = <0 0x11291000 0 0x100>;
> + clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
> + clock-names = "ref_clk";
> #phy-cells = <1>;
> status = "okay";
> };
> @@ -64,7 +80,54 @@ Example:
>
> usb30: usb@11270000 {
> ...
> - phys = <&phy_port0 PHY_TYPE_USB3>;
> - phy-names = "usb3-0";
> + phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
> + phy-names = "usb2-0", "usb3-0";
> ...
> };
> +
> +
> +Layout differences of banks between mt8173/mt2701 and mt2712
> +-------------------------------------------------------------
> +mt8173 and mt2701:
> +port offset bank
> +shared 0x0000 SPLLC
> + 0x0100 FMREG
> +u2 port0 0x0800 U2PHY_COM
> +u3 port0 0x0900 U3PHYD
> + 0x0a00 U3PHYD_BANK2
> + 0x0b00 U3PHYA
> + 0x0c00 U3PHYA_DA
> +u2 port1 0x1000 U2PHY_COM
> +u3 port1 0x1100 U3PHYD
> + 0x1200 U3PHYD_BANK2
> + 0x1300 U3PHYA
> + 0x1400 U3PHYA_DA
> +u2 port2 0x1800 U2PHY_COM
> + ...
> +
> +mt2712:
> +port offset bank
> +u2 port0 0x0000 MISC
> + 0x0100 FMREG
> + 0x0300 U2PHY_COM
> +u3 port0 0x0700 SPLLC
> + 0x0800 CHIP
> + 0x0900 U3PHYD
> + 0x0a00 U3PHYD_BANK2
> + 0x0b00 U3PHYA
> + 0x0c00 U3PHYA_DA
> +u2 port1 0x1000 MISC
> + 0x1100 FMREG
> + 0x1300 U2PHY_COM
> +u3 port1 0x1700 SPLLC
> + 0x1800 CHIP
> + 0x1900 U3PHYD
> + 0x1a00 U3PHYD_BANK2
> + 0x1b00 U3PHYA
> + 0x1c00 U3PHYA_DA
> +u2 port2 0x2000 MISC
> + ...
> +
> + SPLLC shared by u3 ports and FMREG shared by u2 ports on
> +mt8173/mt2701 are put back into each port; a new bank MISC for
> +u2 ports and CHIP for u3 ports are added on mt2712.
>
--
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] spi: mediatek: Manually set dma_ops for spi_master device
From: Robin Murphy @ 2017-01-24 15:14 UTC (permalink / raw)
To: Daniel Kurtz, Leilk Liu
Cc: open list, open list:SPI SUBSYSTEM, 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: <20170124132519.13271-1-djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Hi Dan,
On 24/01/17 13:25, Daniel Kurtz wrote:
> Back before commit 1dccb598df54 ("arm64: simplify dma_get_ops"), for arm64,
> devices that do not manually set a dma_ops are automatically configured to
> use swiotlb_dma_ops, since this was hard-coded as the global "dma_ops" in
> arm64_dma_init().
>
> Now, the global "dma_ops" has been removed, and all devices much have
> their dma_ops explicitly set by a call to arch_setup_dma_ops(). If
> arch_setup_dma_ops() is not called, 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, rather it is created
> in spi_alloc_device(), and its dma_ops are never set.
Ugh, this isn't dwc3-usb all over again, is it?
> 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).
>
> The solution in this patch is a bit of a hack. To install dma_ops for
> its spi_master, we call of_dma_configure() during probe and pass in the
> of_node of the spi-mt65xx platform device.
>
> However, by default, of_dma_configure() will set the coherent_dma_mask
> to 0xffffffff. In fact, using a non-zero dma_mask doesn't actually work
> and causes frequent SPI transaction errors. To work around this, we
> also explicitly set coherent_dma_mask to 0.
That sound like it could do with more investigation before piling hacks
on top of hacks. In theory, that would force dma_alloc_*() to always
fail, whilst allowing dma_map_*() to still work - I imagine the actual
SPI block is just a plain AXI master, meaning there oughtn't to be any
fundamental difference between coherent and streaming DMA, but there can
be differences in whatever functionality those API uses represent in the
driver/SPI code (e.g. data buffers vs. control descriptors).
> Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
>
> I don't know the right place to configure the dma_ops for spi_master.
> It feels like this should actually be done in the spi core, as this might be
> needed by other drivers.
>
> Alternatively, perhaps we should be using master->dev.parent to dma map bufs
> in the "no dma channel case".
AFAICS from a quick scan of the driver, that would be the correct thing
to do - in general for a platform device, the guy described in the DT
should be the guy being passed to DMA API calls.
> And I really don't know why we needed to set the coherent_dma_mask to 0 to
> avoid SPI transaction errors.
Following what I mentioned above, "git grep dma_alloc drivers/spi" makes
it seem like coherent DMA isn't used anywhere relevant, which is rather
puzzling. Unless of course somewhere along the line somebody's done the
dev->dma_mask = &dev->dma_coherent_mask hack, with the result that
writing one mask hits both, making *all* DMA fail and big transfers fall
back to PIO.
And as a backup review comment in case any of the above musings go
nowhere; at the very least please use dma_set_coherent_mask() rather
than open-coding it ;)
Robin.
> Any advice is welcome.
>
> drivers/spi/spi-mt65xx.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
> index 8763eff13d3d..e768835bb67f 100644
> --- a/drivers/spi/spi-mt65xx.c
> +++ b/drivers/spi/spi-mt65xx.c
> @@ -20,6 +20,7 @@
> #include <linux/ioport.h>
> #include <linux/module.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/of_gpio.h>
> #include <linux/platform_device.h>
> #include <linux/platform_data/spi-mt65xx.h>
> @@ -575,6 +576,10 @@ static int mtk_spi_probe(struct platform_device *pdev)
> goto err_put_master;
> }
>
> + /* Call of_dma_configure to set up spi_master's dma_ops */
> + of_dma_configure(&master->dev, master->dev.of_node);
> + /* But explicitly set the coherent_dma_mask to 0 */
> + master->dev.coherent_dma_mask = 0;
> if (!pdev->dev.dma_mask)
> pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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: Add i2c binding for mediatek MT2701 Soc Platform
From: Matthias Brugger @ 2017-01-24 15:03 UTC (permalink / raw)
To: Jun Gao, Wolfram Sang
Cc: srv_heupstream, devicetree, linux-i2c, linux-arm-kernel,
linux-kernel, linux-mediatek, erin.lo
In-Reply-To: <1484719658-11901-2-git-send-email-jun.gao@mediatek.com>
On 01/18/2017 07:07 AM, Jun Gao wrote:
> From: Jun Gao <jun.gao@mediatek.com>
>
> This add i2c DT binding to i2c-mt6577.txt for MT2701.
>
> Signed-off-by: Jun Gao <jun.gao@mediatek.com>
> ---
> .../devicetree/bindings/i2c/i2c-mt6577.txt | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
> b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
> index 0ce6fa3..ef22ecf 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
> @@ -4,11 +4,12 @@ The Mediatek's I2C controller is used to interface with
> I2C devices.
>
> Required properties:
> - compatible: value should be either of the following.
> - (a) "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
> - (b) "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
> - (c) "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
> - (d) "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
> - (e) "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
> + "mediatek,mt2701-i2c", for i2c compatible with mt2701 i2c.
> + "mediatek,mt6577-i2c", for i2c compatible with mt6577 i2c.
> + "mediatek,mt6589-i2c", for i2c compatible with mt6589 i2c.
> + "mediatek,mt8127-i2c", for i2c compatible with mt8127 i2c.
> + "mediatek,mt8135-i2c", for i2c compatible with mt8135 i2c.
> + "mediatek,mt8173-i2c", for i2c compatible with mt8173 i2c.
> - reg: physical base address of the controller and dma base, length of
> memory
> mapped region.
> - interrupts: interrupt number to the cpu.
>
Actually what you need for mt2701 is what you put into the dts file:
compatible = "mediatek,mt2701-i2c", "mediatek,mt6577-i2c";
"mediatek,mt2701-i2c" alone is not supported in the driver.
While at it would you mind to fix the bindings description for the other
SoCs as well?
Thanks,
Matthias
^ permalink raw reply
* [PATCH] spi: mediatek: Manually set dma_ops for spi_master device
From: Daniel Kurtz @ 2017-01-24 13:25 UTC (permalink / raw)
To: Leilk Liu
Cc: dtor-F7+t8E8rja9g9hUCZPvPmw, groeck-F7+t8E8rja9g9hUCZPvPmw,
Daniel Kurtz, Mark Brown, Matthias Brugger,
open list:SPI SUBSYSTEM, open list,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
Back before commit 1dccb598df54 ("arm64: simplify dma_get_ops"), for arm64,
devices that do not manually set a dma_ops are automatically configured to
use swiotlb_dma_ops, since this was hard-coded as the global "dma_ops" in
arm64_dma_init().
Now, the global "dma_ops" has been removed, and all devices much have
their dma_ops explicitly set by a call to arch_setup_dma_ops(). If
arch_setup_dma_ops() is not called, 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, rather it is created
in spi_alloc_device(), and 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).
The solution in this patch is a bit of a hack. To install dma_ops for
its spi_master, we call of_dma_configure() during probe and pass in the
of_node of the spi-mt65xx platform device.
However, by default, of_dma_configure() will set the coherent_dma_mask
to 0xffffffff. In fact, using a non-zero dma_mask doesn't actually work
and causes frequent SPI transaction errors. To work around this, we
also explicitly set coherent_dma_mask to 0.
Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
I don't know the right place to configure the dma_ops for spi_master.
It feels like this should actually be done in the spi core, as this might be
needed by other drivers.
Alternatively, perhaps we should be using master->dev.parent to dma map bufs
in the "no dma channel case".
And I really don't know why we needed to set the coherent_dma_mask to 0 to
avoid SPI transaction errors.
Any advice is welcome.
drivers/spi/spi-mt65xx.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 8763eff13d3d..e768835bb67f 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -20,6 +20,7 @@
#include <linux/ioport.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/platform_data/spi-mt65xx.h>
@@ -575,6 +576,10 @@ static int mtk_spi_probe(struct platform_device *pdev)
goto err_put_master;
}
+ /* Call of_dma_configure to set up spi_master's dma_ops */
+ of_dma_configure(&master->dev, master->dev.of_node);
+ /* But explicitly set the coherent_dma_mask to 0 */
+ master->dev.coherent_dma_mask = 0;
if (!pdev->dev.dma_mask)
pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
--
2.11.0.483.g087da7b7c-goog
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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] clk: mediatek: Fix MT2701 dependencies
From: Jean Delvare @ 2017-01-24 12:58 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-clk, linux-mediatek, Matthias Brugger, James Liao, Erin Lo,
Stephen Boyd, Shunli Wang, Michael Turquette
In-Reply-To: <c3da261a-eb85-9b30-d5e2-05863d2efad2@suse.de>
Hallo Andreas,
On Mon, 9 Jan 2017 21:08:50 +0100, Andreas Färber wrote:
> Another aspect here is that this is a 32-bit SoC but it propagates into
> the arm64 configs, so maybe (ARCH_MEDIATEK && !ARM64) || COMPILE_TEST?
>
> Same for mt2701 pinctrl.
I took a look and the pinctrl situation is different:
config PINCTRL_MT2701
bool "Mediatek MT2701 pin control" if COMPILE_TEST && !MACH_MT2701
(...)
default MACH_MT2701
So the user will not be prompt about it on ARM64 (unless build-testing)
because MACH_MT2701 isn't set on ARM64. The only issue with this
construct is that you end up with useless symbols defined in the
configuration file (they can only be "n".) So I would argue that the
following is preferred:
config PINCTRL_MT2701
bool "Mediatek MT2701 pin control"
(...)
depends on MACH_MT2701 || COMPILE_TEST
default MACH_MT2701
And same for the other 3 PINCTRL_MT* options. Yes, that means the user
will be asked about the options on Mediatek kernels, but actually I
believe this is desirable, as advanced users should be allowed to
disable specific drivers if they know what they are doing. Other users
can just stick to the default.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* [PATCH] clk: mediatek: Fix MT8135 dependencies
From: Jean Delvare @ 2017-01-24 12:09 UTC (permalink / raw)
To: linux-clk, linux-mediatek
Cc: Andreas Färber, James Liao, Stephen Boyd, Matthias Brugger
The MT8135 is a 32-bit SoC, so only propose it on ARM architecture,
not ARM64.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes: 234d511d8c15 ("clk: mediatek: Add hardware dependency")
Cc: Andreas Färber <afaerber@suse.de>
Cc: James Liao <jamesjj.liao@mediatek.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
---
drivers/clk/mediatek/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-4.10-rc4.orig/drivers/clk/mediatek/Kconfig 2017-01-24 12:55:50.192100713 +0100
+++ linux-4.10-rc4/drivers/clk/mediatek/Kconfig 2017-01-24 12:59:08.703066604 +0100
@@ -52,9 +52,9 @@ config COMMON_CLK_MT2701_BDPSYS
config COMMON_CLK_MT8135
bool "Clock driver for Mediatek MT8135"
- depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
select COMMON_CLK_MEDIATEK
- default ARCH_MEDIATEK
+ default ARCH_MEDIATEK && ARM
---help---
This driver supports Mediatek MT8135 clocks.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* [PATCH v2] clk: mediatek: Fix MT2701 dependencies
From: Jean Delvare @ 2017-01-24 12:07 UTC (permalink / raw)
To: linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: James Liao, Erin Lo, Stephen Boyd, Andreas Färber,
Shunli Wang, Matthias Brugger, Michael Turquette
If I say "no" to "Clock driver for Mediatek MT2701", I don't want to
be asked individually about each sub-driver. No means no.
Additionally, this driver shouldn't be proposed at all on non-mediatek
builds, unless build-testing.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
Reviewed-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: James Liao <jamesjj.liao@mediatek.com>
Cc: Shunli Wang <shunli.wang@mediatek.com>
Cc: Erin Lo <erin.lo@mediatek.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
---
Changes since v1:
* Restrict to 32-bit ARM.
drivers/clk/mediatek/Kconfig | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
--- linux-4.10-rc4.orig/drivers/clk/mediatek/Kconfig 2017-01-16 11:13:07.146675028 +0100
+++ linux-4.10-rc4/drivers/clk/mediatek/Kconfig 2017-01-24 12:55:50.192100713 +0100
@@ -8,44 +8,45 @@ config COMMON_CLK_MEDIATEK
config COMMON_CLK_MT2701
bool "Clock driver for Mediatek MT2701"
+ depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
select COMMON_CLK_MEDIATEK
- default ARCH_MEDIATEK
+ default ARCH_MEDIATEK && ARM
---help---
This driver supports Mediatek MT2701 basic clocks.
config COMMON_CLK_MT2701_MMSYS
bool "Clock driver for Mediatek MT2701 mmsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 mmsys clocks.
config COMMON_CLK_MT2701_IMGSYS
bool "Clock driver for Mediatek MT2701 imgsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 imgsys clocks.
config COMMON_CLK_MT2701_VDECSYS
bool "Clock driver for Mediatek MT2701 vdecsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 vdecsys clocks.
config COMMON_CLK_MT2701_HIFSYS
bool "Clock driver for Mediatek MT2701 hifsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 hifsys clocks.
config COMMON_CLK_MT2701_ETHSYS
bool "Clock driver for Mediatek MT2701 ethsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 ethsys clocks.
config COMMON_CLK_MT2701_BDPSYS
bool "Clock driver for Mediatek MT2701 bdpsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 bdpsys clocks.
--
Jean Delvare
SUSE L3 Support
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: John Crispin @ 2017-01-24 10:38 UTC (permalink / raw)
To: Guochun Mao
Cc: Boris Brezillon, Thomas Petazzoni, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Richard Weinberger,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Russell King, Marek Vasut,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Matthias Brugger, linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Mark Rutland, Brian Norris, David Woodhouse, Cyrille Pitchen,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20170124113118.304a860c@bbrezillon>
On 24/01/2017 11:31, Boris Brezillon wrote:
> On Sun, 22 Jan 2017 10:36:40 +0800
> Guochun Mao <guochun.mao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
>
>> Hi,
>> On Thu, 2017-01-19 at 08:18 -0600, Rob Herring wrote:
>>> On Thu, Jan 19, 2017 at 2:14 AM, Boris Brezillon
>>>> One last question and I'm done: is something like that acceptable?
>>>>
>>>> compatible = "<vendor>,<old-soc>","<vendor>,<new-soc>";
>>>>
>>>> This can happen when someone adds support for an unsupported feature
>>>> on a brand new SoC, and then someone else use the same driver for an
>>>> older SoC embedding the same IP but still wants to add a new compatible
>>>> just in case these 2 IPs appear to be slightly different.
>>>
>>> Yes, it's old and new compatible strings in this case and it's newest
>>> compatible string first.
>>>
>>>> Here the order of compat strings is no longer following a clear rule
>>>> like 'most-specific compatible first' or 'newest IP/SoC version first',
>>>> it's completely dependent on the order these IPs were supported in the
>>>> OS (Linux). I'm perfectly fine with that BTW, just want to make sure
>>>> this is authorized.
>>>
>>> I guess we should say "newest compatible for IP first" instead. There
>>> are some exceptions where we add fallbacks later on, but that falls
>>> under the most-specific part.
>>>
>>> It's order that the bindings are defined, not Linux support really,
>>> but in practice those are the same.
>>>
>>> Rob
>>
>> Thanks for all your effort for code reviewing.
>> Our mt2701-nor's hardware is designed base on mt8713-nor,
>> even so, there would be some slight difference.
>> If I don't misunderstand your viewpoint in this discussion,
>> there's no need to drop mt2701-nor compatible.
>
> No, just update the documentation as suggested by Rob.
>
>> And if not, is there any other suggestion?
>
> Nope, and my apologies for being so insistent on something I obviously
> misunderstood.
>
> Regards,
>
> Boris
Hi,
could you please add the mt7623 compat string to the documentation
aswell while at it ? mt7623/mt2701 are essentially the same and it'll
safe us time and effort and not cause merge order conflicts. otherwise i
would need to wait till the mt2701 patch is merged before i can send the
mt7623 one
Thanks !
John
--
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 v3 2/3] dts: mediatek: configure some fixed mmc parameters
From: Matthias Brugger @ 2017-01-24 10:36 UTC (permalink / raw)
To: Ulf Hansson, Yong Mao
Cc: srv_heupstream, Linus Walleij, linux-mmc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mediatek, Chunfeng Yun,
Eddie Huang, Chaotian Jing
In-Reply-To: <CAPDyKFrHCy7bLb-wDRWpELAB5VxPc4tjyWKd31YufEZC_AQtVA@mail.gmail.com>
Hi Ulf,
On 01/20/2017 08:59 AM, Ulf Hansson wrote:
> On 19 January 2017 at 11:19, Yong Mao <yong.mao@mediatek.com> wrote:
>> From: yong mao <yong.mao@mediatek.com>
>>
>> configure some fixed mmc parameters
>>
>> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
>> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
>
> Please change the prefix of the commit message header to "ARM64: dts: mt8173:".
>
> Also make sure you send this to the ARM mailing list as well.
>
> In general, I think it's better DTS changes go via the ARM SoC tree,
> but I can pick it up if it's trivial and I get an ack from the SoC
> maintainer.
>
I can take them through my tree, let's wait at Rob's opinion of v4.
Regards,
Matthias
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> index 0ecaad4..403705e 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> @@ -134,6 +134,9 @@
>> bus-width = <8>;
>> max-frequency = <50000000>;
>> cap-mmc-highspeed;
>> + mtk-hs200-cmd-int-delay=<26>;
>> + mtk-hs400-cmd-int-delay=<14>;
>> + mtk-hs400-cmd-resp-sel=<0>; /* 0:rising, 1:falling */
>> vmmc-supply = <&mt6397_vemc_3v3_reg>;
>> vqmmc-supply = <&mt6397_vio18_reg>;
>> non-removable;
>> --
>> 1.7.9.5
>>
>
> Kind regards
> Uffe
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
^ permalink raw reply
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Boris Brezillon @ 2017-01-24 10:31 UTC (permalink / raw)
To: Guochun Mao
Cc: Rob Herring, Thomas Petazzoni, Marek Vasut, Matthias Brugger,
Mark Rutland, devicetree@vger.kernel.org, Richard Weinberger,
linux-kernel@vger.kernel.org, Russell King,
linux-mtd@lists.infradead.org, linux-mediatek, Cyrille Pitchen,
Brian Norris, David Woodhouse,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1485052600.19995.10.camel@mhfsdcap03>
On Sun, 22 Jan 2017 10:36:40 +0800
Guochun Mao <guochun.mao@mediatek.com> wrote:
> Hi,
> On Thu, 2017-01-19 at 08:18 -0600, Rob Herring wrote:
> > On Thu, Jan 19, 2017 at 2:14 AM, Boris Brezillon
> > > One last question and I'm done: is something like that acceptable?
> > >
> > > compatible = "<vendor>,<old-soc>","<vendor>,<new-soc>";
> > >
> > > This can happen when someone adds support for an unsupported feature
> > > on a brand new SoC, and then someone else use the same driver for an
> > > older SoC embedding the same IP but still wants to add a new compatible
> > > just in case these 2 IPs appear to be slightly different.
> >
> > Yes, it's old and new compatible strings in this case and it's newest
> > compatible string first.
> >
> > > Here the order of compat strings is no longer following a clear rule
> > > like 'most-specific compatible first' or 'newest IP/SoC version first',
> > > it's completely dependent on the order these IPs were supported in the
> > > OS (Linux). I'm perfectly fine with that BTW, just want to make sure
> > > this is authorized.
> >
> > I guess we should say "newest compatible for IP first" instead. There
> > are some exceptions where we add fallbacks later on, but that falls
> > under the most-specific part.
> >
> > It's order that the bindings are defined, not Linux support really,
> > but in practice those are the same.
> >
> > Rob
>
> Thanks for all your effort for code reviewing.
> Our mt2701-nor's hardware is designed base on mt8713-nor,
> even so, there would be some slight difference.
> If I don't misunderstand your viewpoint in this discussion,
> there's no need to drop mt2701-nor compatible.
No, just update the documentation as suggested by Rob.
> And if not, is there any other suggestion?
Nope, and my apologies for being so insistent on something I obviously
misunderstood.
Regards,
Boris
^ permalink raw reply
* Re: [PATCH v3] arm: dts: mt2701: Add thermal device node.
From: Matthias Brugger @ 2017-01-24 10:26 UTC (permalink / raw)
To: Erin Lo
Cc: srv_heupstream, devicetree, linux-arm-kernel, linux-kernel,
linux-mediatek, Dawei Chien
In-Reply-To: <1484645049-4477-2-git-send-email-erin.lo@mediatek.com>
On 01/17/2017 10:24 AM, Erin Lo wrote:
> From: Dawei Chien <dawei.chien@mediatek.com>
>
> Add thermal controller device nodes for MT2701.
>
> Signed-off-by: Dawei Chien <dawei.chien@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> ---
> arch/arm/boot/dts/mt2701.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
Applied, thanks
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 4cfec57..26a88cb 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -89,6 +89,36 @@
> clock-output-names = "rtc32k";
> };
>
> + thermal-zones {
> + cpu_thermal: cpu_thermal {
> + polling-delay-passive = <1000>; /* milliseconds */
> + polling-delay = <1000>; /* milliseconds */
> +
> + thermal-sensors = <&thermal 0>;
> + sustainable-power = <1000>;
> +
> + trips {
> + threshold: trip-point@0 {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + target: trip-point@1 {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu_crit: cpu_crit@0 {
> + temperature = <115000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +
> timer {
> compatible = "arm,armv7-timer";
> interrupt-parent = <&gic>;
> @@ -270,6 +300,19 @@
> status = "disabled";
> };
>
> + thermal: thermal@1100b000 {
> + #thermal-sensor-cells = <0>;
> + compatible = "mediatek,mt2701-thermal";
> + reg = <0 0x1100b000 0 0x1000>;
> + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
> + clock-names = "therm", "auxadc";
> + resets = <&pericfg MT2701_PERI_THERM_SW_RST>;
> + reset-names = "therm";
> + mediatek,auxadc = <&auxadc>;
> + mediatek,apmixedsys = <&apmixedsys>;
> + };
> +
> nandc: nfi@1100d000 {
> compatible = "mediatek,mt2701-nfc";
> reg = <0 0x1100d000 0 0x1000>;
>
^ permalink raw reply
* Re: [PATCH] clk: mediatek: Fix MT2701 dependencies
From: Jean Delvare @ 2017-01-24 9:46 UTC (permalink / raw)
To: Stephen Boyd
Cc: James Liao, Andreas Färber, linux-clk, linux-mediatek,
Matthias Brugger, Erin Lo, Shunli Wang, Michael Turquette
In-Reply-To: <20170120232214.GC20800@codeaurora.org>
On Fri, 20 Jan 2017 15:22:14 -0800, Stephen Boyd wrote:
> On 01/12, Jean Delvare wrote:
> > Hi James,
> >
> > On Thu, 12 Jan 2017 11:39:52 +0800, James Liao wrote:
> > > On Wed, 2017-01-11 at 13:41 +0100, Jean Delvare wrote:
> > > > config COMMON_CLK_MT8173
> > > > bool "Clock driver for Mediatek MT8173"
> > > > - depends on ARCH_MEDIATEK || COMPILE_TEST
> > > > + depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
> > > > select COMMON_CLK_MEDIATEK
> > > > - default ARCH_MEDIATEK
> > > > + default y
> > > > ---help---
> > > > This driver supports Mediatek MT8173 clocks.
> > >
> > > Although MT8173 is a 64-bit SoC, but 32-bit kernel can run on it. So I
> > > think it no need to limit COMMON_CLK_MT8173 only be enabled on ARM64
> > > platform.
> >
> > OK, I'll leave that one alone then, thanks for the information.
>
> Is this patch going another round? I haven't seen anything on the
> list so far.
Sorry for the delay, I'll send an update later today.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [PATCH v4 1/3] mmc: dt-bindings: update Mediatek MMC bindings
From: Ulf Hansson @ 2017-01-24 8:02 UTC (permalink / raw)
To: Yong Mao
Cc: Rob Herring, srv_heupstream, devicetree@vger.kernel.org,
Linus Walleij, linux-mmc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mediatek,
linux-arm-kernel@lists.infradead.org, Chunfeng Yun, Eddie Huang,
Chaotian Jing
In-Reply-To: <1484988923-1543-2-git-send-email-yong.mao@mediatek.com>
+Rob, devicetree
On 21 January 2017 at 09:55, Yong Mao <yong.mao@mediatek.com> wrote:
> From: yong mao <yong.mao@mediatek.com>
>
> Add description for mediatek,hs200-cmd-int-delay
> Add description for mediatek,hs400-cmd-int-delay
> Add description for mediatek,hs400-cmd-resp-sel-rising
>
> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
You need an ack from a DT maintainer for this. I have added Rob and
the devicetree list on cc.
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/mtk-sd.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 0120c7f..4182ea3 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -21,6 +21,15 @@ Optional properties:
> - assigned-clocks: PLL of the source clock
> - assigned-clock-parents: parent of source clock, used for HS400 mode to get 400Mhz source clock
> - hs400-ds-delay: HS400 DS delay setting
> +- mediatek,hs200-cmd-int-delay: HS200 command internal delay setting.
> + This field has total 32 stages.
> + The value is an integer from 0 to 31.
> +- mediatek,hs400-cmd-int-delay: HS400 command internal delay setting
> + This field has total 32 stages.
> + The value is an integer from 0 to 31.
> +- mediatek,hs400-cmd-resp-sel-rising: HS400 command response sample selection
> + If present,HS400 command responses are sampled on rising edges.
> + If not present,HS400 command responses are sampled on falling edges.
>
> Examples:
> mmc0: mmc@11230000 {
> @@ -38,4 +47,7 @@ mmc0: mmc@11230000 {
> assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
> assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
> hs400-ds-delay = <0x14015>;
> + mediatek,hs200-cmd-int-delay = <26>;
> + mediatek,hs400-cmd-int-delay = <14>;
> + mediatek,hs400-cmd-resp-sel-rising;
> };
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH] drm/mediatek: hdmi: Filter interlaced resolutions
From: CK Hu @ 2017-01-24 6:12 UTC (permalink / raw)
To: Bibby Hsieh
Cc: linux-kernel, Sascha Hauer, Daniel Vetter, Cawa Cheng, dri-devel,
Mao Huang, linux-mediatek, Matthias Brugger, Yingjoe Chen,
linux-arm-kernel
In-Reply-To: <1485234604-19889-1-git-send-email-bibby.hsieh@mediatek.com>
Hi, Bibby:
On Tue, 2017-01-24 at 13:10 +0800, Bibby Hsieh wrote:
> Current Mediatek DRM driver does not support interlaced mode, and
> will hang if such resolution is used: Filter those to prevent
> kernel hangs, until the DRM driver is fixed properly.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 0e8c4d9..e33678d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1244,6 +1244,8 @@ static int mtk_hdmi_conn_mode_valid(struct drm_connector *conn,
> return MODE_BAD;
> }
>
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> + return MODE_NO_INTERLACE;
> if (mode->clock < 27000)
> return MODE_CLOCK_LOW;
> if (mode->clock > 297000)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3] drm/mediatek: Support UYVY and YUYV format for overlay
From: CK Hu @ 2017-01-24 5:40 UTC (permalink / raw)
To: Bibby Hsieh
Cc: David Airlie, Matthias Brugger, Daniel Vetter, dri-devel,
linux-mediatek, Yingjoe Chen, Cawa Cheng, Daniel Kurtz,
Philipp Zabel, YT Shen, Thierry Reding, Mao Huang,
linux-arm-kernel, linux-kernel, Sascha Hauer
In-Reply-To: <1485232858-40418-1-git-send-email-bibby.hsieh@mediatek.com>
Hi, Bibby:
On Tue, 2017-01-24 at 12:40 +0800, Bibby Hsieh wrote:
> MT8173 overlay can support UYVY and YUYV format,
> we add the format in DRM driver.
>
> Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 +++++++
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index c703102..53f2001 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -40,10 +40,13 @@
> #define OVL_RDMA_MEM_GMC 0x40402020
>
> #define OVL_CON_BYTE_SWAP BIT(24)
> +#define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
> #define OVL_CON_CLRFMT_RGB565 (0 << 12)
> #define OVL_CON_CLRFMT_RGB888 (1 << 12)
> #define OVL_CON_CLRFMT_RGBA8888 (2 << 12)
> #define OVL_CON_CLRFMT_ARGB8888 (3 << 12)
> +#define OVL_CON_CLRFMT_UYVY (4 << 12)
> +#define OVL_CON_CLRFMT_YUYV (5 << 12)
> #define OVL_CON_AEN BIT(8)
> #define OVL_CON_ALPHA 0xff
>
> @@ -162,6 +165,10 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
> case DRM_FORMAT_XBGR8888:
> case DRM_FORMAT_ABGR8888:
> return OVL_CON_CLRFMT_RGBA8888 | OVL_CON_BYTE_SWAP;
> + case DRM_FORMAT_UYVY:
> + return OVL_CON_CLRFMT_UYVY | OVL_CON_MTX_YUV_TO_RGB;
> + case DRM_FORMAT_YUYV:
> + return OVL_CON_CLRFMT_YUYV | OVL_CON_MTX_YUV_TO_RGB;
> }
> }
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index c461a23..8c02d1d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -28,6 +28,8 @@
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_ARGB8888,
> DRM_FORMAT_RGB565,
> + DRM_FORMAT_UYVY,
> + DRM_FORMAT_YUYV,
> };
>
> static void mtk_plane_reset(struct drm_plane *plane)
^ permalink raw reply
* Re: [PATCH v12 11/12] drm/mediatek: update DSI sub driver flow for sending commands to panel
From: CK Hu @ 2017-01-24 5:33 UTC (permalink / raw)
To: YT Shen
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Philipp Zabel,
David Airlie, Rob Herring, Mark Rutland, Matthias Brugger,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, Daniel Kurtz,
shaoming chen
In-Reply-To: <1485169525-22163-12-git-send-email-yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Hi, YT:
On Mon, 2017-01-23 at 19:05 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
>
> Signed-off-by: shaoming chen <shaoming.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: YT Shen <yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Acked-by: CK Hu <ck.hu-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 266 ++++++++++++++++++++++---------------
> 1 file changed, 161 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 85f22d2..aa3541e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -126,6 +126,10 @@
> #define CLK_HS_POST (0xff << 8)
> #define CLK_HS_EXIT (0xff << 16)
>
> +#define DSI_VM_CMD_CON 0x130
> +#define VM_CMD_EN BIT(0)
> +#define TS_VFP_EN BIT(5)
> +
> #define DSI_CMDQ0 0x180
> #define CONFIG (0xff << 0)
> #define SHORT_PACKET 0
> @@ -239,85 +243,6 @@ static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
> mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, 0);
> }
>
> -static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> -{
> - struct device *dev = dsi->dev;
> - int ret;
> - u64 pixel_clock, total_bits;
> - u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
> -
> - if (++dsi->refcount != 1)
> - return 0;
> -
> - switch (dsi->format) {
> - case MIPI_DSI_FMT_RGB565:
> - bit_per_pixel = 16;
> - break;
> - case MIPI_DSI_FMT_RGB666_PACKED:
> - bit_per_pixel = 18;
> - break;
> - case MIPI_DSI_FMT_RGB666:
> - case MIPI_DSI_FMT_RGB888:
> - default:
> - bit_per_pixel = 24;
> - break;
> - }
> -
> - /**
> - * vm.pixelclock is in kHz, pixel_clock unit is Hz, so multiply by 1000
> - * htotal_time = htotal * byte_per_pixel / num_lanes
> - * overhead_time = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> - * mipi_ratio = (htotal_time + overhead_time) / htotal_time
> - * data_rate = pixel_clock * bit_per_pixel * mipi_ratio / num_lanes;
> - */
> - pixel_clock = dsi->vm.pixelclock * 1000;
> - htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> - dsi->vm.hsync_len;
> - htotal_bits = htotal * bit_per_pixel;
> -
> - overhead_cycles = T_LPX + T_HS_PREP + T_HS_ZERO + T_HS_TRAIL +
> - T_HS_EXIT;
> - overhead_bits = overhead_cycles * dsi->lanes * 8;
> - total_bits = htotal_bits + overhead_bits;
> -
> - dsi->data_rate = DIV_ROUND_UP_ULL(pixel_clock * total_bits,
> - htotal * dsi->lanes);
> -
> - ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> - if (ret < 0) {
> - dev_err(dev, "Failed to set data rate: %d\n", ret);
> - goto err_refcount;
> - }
> -
> - phy_power_on(dsi->phy);
> -
> - ret = clk_prepare_enable(dsi->engine_clk);
> - if (ret < 0) {
> - dev_err(dev, "Failed to enable engine clock: %d\n", ret);
> - goto err_phy_power_off;
> - }
> -
> - ret = clk_prepare_enable(dsi->digital_clk);
> - if (ret < 0) {
> - dev_err(dev, "Failed to enable digital clock: %d\n", ret);
> - goto err_disable_engine_clk;
> - }
> -
> - mtk_dsi_enable(dsi);
> - mtk_dsi_reset_engine(dsi);
> - mtk_dsi_phy_timconfig(dsi);
> -
> - return 0;
> -
> -err_disable_engine_clk:
> - clk_disable_unprepare(dsi->engine_clk);
> -err_phy_power_off:
> - phy_power_off(dsi->phy);
> -err_refcount:
> - dsi->refcount--;
> - return ret;
> -}
> -
> static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
> {
> mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
> @@ -365,16 +290,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
> u32 vid_mode = CMD_MODE;
>
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> - vid_mode = SYNC_PULSE_MODE;
> -
> - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> vid_mode = BURST_MODE;
> + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + vid_mode = SYNC_PULSE_MODE;
> + else
> + vid_mode = SYNC_EVENT_MODE;
> }
>
> writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
> }
>
> +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> +{
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> +}
> +
> static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
> {
> struct videomode *vm = &dsi->vm;
> @@ -512,6 +444,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
> writel(1, dsi->regs + DSI_START);
> }
>
> +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> +{
> + writel(0, dsi->regs + DSI_START);
> +}
> +
> +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> +{
> + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> +}
> +
> static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> {
> u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> @@ -570,6 +512,121 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> +{
> + mtk_dsi_irq_data_clear(dsi, irq_flag);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> + DRM_ERROR("failed to switch cmd mode\n");
> + return -ETIME;
> + } else {
> + return 0;
> + }
> +}
> +
> +static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> +{
> + struct device *dev = dsi->dev;
> + int ret;
> + u64 pixel_clock, total_bits;
> + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
> +
> + if (++dsi->refcount != 1)
> + return 0;
> +
> + switch (dsi->format) {
> + case MIPI_DSI_FMT_RGB565:
> + bit_per_pixel = 16;
> + break;
> + case MIPI_DSI_FMT_RGB666_PACKED:
> + bit_per_pixel = 18;
> + break;
> + case MIPI_DSI_FMT_RGB666:
> + case MIPI_DSI_FMT_RGB888:
> + default:
> + bit_per_pixel = 24;
> + break;
> + }
> +
> + /**
> + * vm.pixelclock is in kHz, pixel_clock unit is Hz, so multiply by 1000
> + * htotal_time = htotal * byte_per_pixel / num_lanes
> + * overhead_time = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> + * mipi_ratio = (htotal_time + overhead_time) / htotal_time
> + * data_rate = pixel_clock * bit_per_pixel * mipi_ratio / num_lanes;
> + */
> + pixel_clock = dsi->vm.pixelclock * 1000;
> + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> + dsi->vm.hsync_len;
> + htotal_bits = htotal * bit_per_pixel;
> +
> + overhead_cycles = T_LPX + T_HS_PREP + T_HS_ZERO + T_HS_TRAIL +
> + T_HS_EXIT;
> + overhead_bits = overhead_cycles * dsi->lanes * 8;
> + total_bits = htotal_bits + overhead_bits;
> +
> + dsi->data_rate = DIV_ROUND_UP_ULL(pixel_clock * total_bits,
> + htotal * dsi->lanes);
> +
> + ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> + if (ret < 0) {
> + dev_err(dev, "Failed to set data rate: %d\n", ret);
> + goto err_refcount;
> + }
> +
> + phy_power_on(dsi->phy);
> +
> + ret = clk_prepare_enable(dsi->engine_clk);
> + if (ret < 0) {
> + dev_err(dev, "Failed to enable engine clock: %d\n", ret);
> + goto err_phy_power_off;
> + }
> +
> + ret = clk_prepare_enable(dsi->digital_clk);
> + if (ret < 0) {
> + dev_err(dev, "Failed to enable digital clock: %d\n", ret);
> + goto err_disable_engine_clk;
> + }
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + mtk_dsi_phy_timconfig(dsi);
> +
> + mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + mtk_dsi_set_vm_cmd(dsi);
> + mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
> +
> + mtk_dsi_clk_ulp_mode_leave(dsi);
> + mtk_dsi_lane0_ulp_mode_leave(dsi);
> + mtk_dsi_clk_hs_mode(dsi, 0);
> +
> + if (dsi->panel) {
> + if (drm_panel_prepare(dsi->panel)) {
> + DRM_ERROR("failed to prepare the panel\n");
> + goto err_disable_digital_clk;
> + }
> + }
> +
> + mtk_dsi_set_mode(dsi);
> + mtk_dsi_clk_hs_mode(dsi, 1);
> +
> + mtk_dsi_start(dsi);
> +
> + return 0;
> +err_disable_digital_clk:
> + clk_disable_unprepare(dsi->digital_clk);
> +err_disable_engine_clk:
> + clk_disable_unprepare(dsi->engine_clk);
> +err_phy_power_off:
> + phy_power_off(dsi->phy);
> +err_refcount:
> + dsi->refcount--;
> + return ret;
> +}
> +
> static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> {
> if (WARN_ON(dsi->refcount == 0))
> @@ -578,6 +635,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> if (--dsi->refcount != 0)
> return;
>
> + mtk_dsi_stop(dsi);
> + if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
> + if (dsi->panel) {
> + if (drm_panel_unprepare(dsi->panel)) {
> + DRM_ERROR("failed to unprepare the panel\n");
> + return;
> + }
> + }
> + }
> +
> + mtk_dsi_reset_engine(dsi);
> mtk_dsi_lane0_ulp_mode_enter(dsi);
> mtk_dsi_clk_ulp_mode_enter(dsi);
>
> @@ -596,36 +664,24 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> if (dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
> ret = mtk_dsi_poweron(dsi);
> if (ret < 0) {
> DRM_ERROR("failed to power on dsi\n");
> return;
> }
>
> - mtk_dsi_rxtx_control(dsi);
> -
> - mtk_dsi_clk_ulp_mode_leave(dsi);
> - mtk_dsi_lane0_ulp_mode_leave(dsi);
> - mtk_dsi_clk_hs_mode(dsi, 0);
> - mtk_dsi_set_mode(dsi);
> -
> - mtk_dsi_ps_control_vact(dsi);
> - mtk_dsi_config_vdo_timing(dsi);
> - mtk_dsi_set_interrupt_enable(dsi);
> -
> - mtk_dsi_set_mode(dsi);
> - mtk_dsi_clk_hs_mode(dsi, 1);
> -
> - mtk_dsi_start(dsi);
> + if (dsi->panel) {
> + if (drm_panel_enable(dsi->panel)) {
> + DRM_ERROR("failed to enable the panel\n");
> + goto err_dsi_power_off;
> + }
> + }
>
> dsi->enabled = true;
> +
> + return;
> +err_dsi_power_off:
> + mtk_dsi_poweroff(dsi);
> }
>
> static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
--
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
* [PATCH] drm/mediatek: hdmi: Filter interlaced resolutions
From: Bibby Hsieh @ 2017-01-24 5:10 UTC (permalink / raw)
To: David Airlie, Matthias Brugger, Daniel Vetter, dri-devel,
linux-mediatek
Cc: Yingjoe Chen, Cawa Cheng, Daniel Kurtz, Bibby Hsieh,
Philipp Zabel, YT Shen, Thierry Reding, CK Hu, Mao Huang,
linux-arm-kernel, linux-kernel, Sascha Hauer
Current Mediatek DRM driver does not support interlaced mode, and
will hang if such resolution is used: Filter those to prevent
kernel hangs, until the DRM driver is fixed properly.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 0e8c4d9..e33678d 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1244,6 +1244,8 @@ static int mtk_hdmi_conn_mode_valid(struct drm_connector *conn,
return MODE_BAD;
}
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ return MODE_NO_INTERLACE;
if (mode->clock < 27000)
return MODE_CLOCK_LOW;
if (mode->clock > 297000)
--
1.9.1
^ permalink raw reply related
* [PATCH v3] drm/mediatek: Support UYVY and YUYV format for overlay
From: Bibby Hsieh @ 2017-01-24 4:40 UTC (permalink / raw)
To: David Airlie, Matthias Brugger, Daniel Vetter, dri-devel,
linux-mediatek
Cc: linux-kernel, Cawa Cheng, Mao Huang, Yingjoe Chen, Sascha Hauer,
linux-arm-kernel
MT8173 overlay can support UYVY and YUYV format,
we add the format in DRM driver.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 +++++++
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index c703102..53f2001 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -40,10 +40,13 @@
#define OVL_RDMA_MEM_GMC 0x40402020
#define OVL_CON_BYTE_SWAP BIT(24)
+#define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
#define OVL_CON_CLRFMT_RGB565 (0 << 12)
#define OVL_CON_CLRFMT_RGB888 (1 << 12)
#define OVL_CON_CLRFMT_RGBA8888 (2 << 12)
#define OVL_CON_CLRFMT_ARGB8888 (3 << 12)
+#define OVL_CON_CLRFMT_UYVY (4 << 12)
+#define OVL_CON_CLRFMT_YUYV (5 << 12)
#define OVL_CON_AEN BIT(8)
#define OVL_CON_ALPHA 0xff
@@ -162,6 +165,10 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
case DRM_FORMAT_XBGR8888:
case DRM_FORMAT_ABGR8888:
return OVL_CON_CLRFMT_RGBA8888 | OVL_CON_BYTE_SWAP;
+ case DRM_FORMAT_UYVY:
+ return OVL_CON_CLRFMT_UYVY | OVL_CON_MTX_YUV_TO_RGB;
+ case DRM_FORMAT_YUYV:
+ return OVL_CON_CLRFMT_YUYV | OVL_CON_MTX_YUV_TO_RGB;
}
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index c461a23..8c02d1d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -28,6 +28,8 @@
DRM_FORMAT_XRGB8888,
DRM_FORMAT_ARGB8888,
DRM_FORMAT_RGB565,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_YUYV,
};
static void mtk_plane_reset(struct drm_plane *plane)
--
1.9.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH v2] drm/mediatek: Support UYVY and YUYV format for overlay
From: Daniel Kurtz @ 2017-01-24 2:54 UTC (permalink / raw)
To: Bibby Hsieh
Cc: linux-kernel@vger.kernel.org, Sascha Hauer, Daniel Vetter,
Cawa Cheng, dri-devel, Mao Huang,
moderated list:ARM/Mediatek SoC support, Matthias Brugger,
Yingjoe Chen, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1485221752.9687.2.camel@mtksdaap41>
On Tue, Jan 24, 2017 at 9:35 AM, Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
>
> Hi, Daniel,
>
> Thanks for your comment.
>
> On Tue, 2017-01-03 at 14:27 +0800, Daniel Kurtz wrote:
> > On Fri, Dec 30, 2016 at 2:26 PM, Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
> > >
> > > MT8173 overlay can support UYVY and YUYV format,
> > > we add the format in DRM driver.
> > >
> > > Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> > > Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 21 +++++++++++++++++++++
> > > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
> > > 2 files changed, 23 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > index c703102..de05845 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > @@ -40,10 +40,13 @@
> > > #define OVL_RDMA_MEM_GMC 0x40402020
> > >
> > > #define OVL_CON_BYTE_SWAP BIT(24)
> > > +#define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
> > > #define OVL_CON_CLRFMT_RGB565 (0 << 12)
> > > #define OVL_CON_CLRFMT_RGB888 (1 << 12)
> > > #define OVL_CON_CLRFMT_RGBA8888 (2 << 12)
> > > #define OVL_CON_CLRFMT_ARGB8888 (3 << 12)
> > > +#define OVL_CON_CLRFMT_UYVY (4 << 12)
> > > +#define OVL_CON_CLRFMT_YUYV (5 << 12)
> >
> > Why not just add " | OVL_CON_MTX_YUV_TO_RGB" here in the definition of
> > these two constants, instead of adding a helper function?
> >
> > > #define OVL_CON_AEN BIT(8)
> > > #define OVL_CON_ALPHA 0xff
> > >
> > > @@ -162,6 +165,21 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
> > > case DRM_FORMAT_XBGR8888:
> > > case DRM_FORMAT_ABGR8888:
> > > return OVL_CON_CLRFMT_RGBA8888 | OVL_CON_BYTE_SWAP;
> > > + case DRM_FORMAT_UYVY:
> > > + return OVL_CON_CLRFMT_UYVY;
> > > + case DRM_FORMAT_YUYV:
> > > + return OVL_CON_CLRFMT_YUYV;
> > > + }
> > > +}
> How about adding " | OVL_CON_MTX_YUV_TO_RGB" after here in "return
> OVL_CON_CLRFMT_UYVY" and "return OVL_CON_CLRFMT_YUYV" ??
Sounds good to me.
> > > +
> > > +static bool ovl_yuv_space(unsigned int fmt)
> > > +{
> > > + switch (fmt) {
> > > + case DRM_FORMAT_UYVY:
> > > + case DRM_FORMAT_YUYV:
> > > + return true;
> > > + default:
> > > + return false;
> > > }
> > > }
> > >
> > > @@ -183,6 +201,9 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
> > > if (idx != 0)
> > > con |= OVL_CON_AEN | OVL_CON_ALPHA;
> > >
> > > + if (ovl_yuv_space(fmt))
> > > + con |= OVL_CON_MTX_YUV_TO_RGB;
> > > +
> > > writel_relaxed(con, comp->regs + DISP_REG_OVL_CON(idx));
> > > writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
> > > writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > > index c461a23..8c02d1d 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > > @@ -28,6 +28,8 @@
> > > DRM_FORMAT_XRGB8888,
> > > DRM_FORMAT_ARGB8888,
> > > DRM_FORMAT_RGB565,
> > > + DRM_FORMAT_UYVY,
> > > + DRM_FORMAT_YUYV,
> > > };
> > >
> > > static void mtk_plane_reset(struct drm_plane *plane)
> > > --
> > > 1.9.1
> > >
>
> --
> Bibby
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2] drm/mediatek: Support UYVY and YUYV format for overlay
From: Bibby Hsieh @ 2017-01-24 1:35 UTC (permalink / raw)
To: Daniel Kurtz
Cc: linux-kernel@vger.kernel.org, Sascha Hauer, Daniel Vetter,
Cawa Cheng, dri-devel, Mao Huang,
moderated list:ARM/Mediatek SoC support, Matthias Brugger,
Yingjoe Chen, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAGS+omDHrYnUeRybHt+FtmjLS8d6jO-3==DYYCzbuhFZJME_Gg@mail.gmail.com>
Hi, Daniel,
Thanks for your comment.
On Tue, 2017-01-03 at 14:27 +0800, Daniel Kurtz wrote:
> On Fri, Dec 30, 2016 at 2:26 PM, Bibby Hsieh <bibby.hsieh@mediatek.com> wrote:
> >
> > MT8173 overlay can support UYVY and YUYV format,
> > we add the format in DRM driver.
> >
> > Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
> > Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
> > ---
> > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 21 +++++++++++++++++++++
> > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 ++
> > 2 files changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index c703102..de05845 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -40,10 +40,13 @@
> > #define OVL_RDMA_MEM_GMC 0x40402020
> >
> > #define OVL_CON_BYTE_SWAP BIT(24)
> > +#define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
> > #define OVL_CON_CLRFMT_RGB565 (0 << 12)
> > #define OVL_CON_CLRFMT_RGB888 (1 << 12)
> > #define OVL_CON_CLRFMT_RGBA8888 (2 << 12)
> > #define OVL_CON_CLRFMT_ARGB8888 (3 << 12)
> > +#define OVL_CON_CLRFMT_UYVY (4 << 12)
> > +#define OVL_CON_CLRFMT_YUYV (5 << 12)
>
> Why not just add " | OVL_CON_MTX_YUV_TO_RGB" here in the definition of
> these two constants, instead of adding a helper function?
>
> > #define OVL_CON_AEN BIT(8)
> > #define OVL_CON_ALPHA 0xff
> >
> > @@ -162,6 +165,21 @@ static unsigned int ovl_fmt_convert(unsigned int fmt)
> > case DRM_FORMAT_XBGR8888:
> > case DRM_FORMAT_ABGR8888:
> > return OVL_CON_CLRFMT_RGBA8888 | OVL_CON_BYTE_SWAP;
> > + case DRM_FORMAT_UYVY:
> > + return OVL_CON_CLRFMT_UYVY;
> > + case DRM_FORMAT_YUYV:
> > + return OVL_CON_CLRFMT_YUYV;
> > + }
> > +}
How about adding " | OVL_CON_MTX_YUV_TO_RGB" after here in "return
OVL_CON_CLRFMT_UYVY" and "return OVL_CON_CLRFMT_YUYV" ??
> > +
> > +static bool ovl_yuv_space(unsigned int fmt)
> > +{
> > + switch (fmt) {
> > + case DRM_FORMAT_UYVY:
> > + case DRM_FORMAT_YUYV:
> > + return true;
> > + default:
> > + return false;
> > }
> > }
> >
> > @@ -183,6 +201,9 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
> > if (idx != 0)
> > con |= OVL_CON_AEN | OVL_CON_ALPHA;
> >
> > + if (ovl_yuv_space(fmt))
> > + con |= OVL_CON_MTX_YUV_TO_RGB;
> > +
> > writel_relaxed(con, comp->regs + DISP_REG_OVL_CON(idx));
> > writel_relaxed(pitch, comp->regs + DISP_REG_OVL_PITCH(idx));
> > writel_relaxed(src_size, comp->regs + DISP_REG_OVL_SRC_SIZE(idx));
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > index c461a23..8c02d1d 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> > @@ -28,6 +28,8 @@
> > DRM_FORMAT_XRGB8888,
> > DRM_FORMAT_ARGB8888,
> > DRM_FORMAT_RGB565,
> > + DRM_FORMAT_UYVY,
> > + DRM_FORMAT_YUYV,
> > };
> >
> > static void mtk_plane_reset(struct drm_plane *plane)
> > --
> > 1.9.1
> >
--
Bibby
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v12 01/12] dt-bindings: display: mediatek: update supported chips
From: Rob Herring @ 2017-01-23 21:02 UTC (permalink / raw)
To: YT Shen
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Philipp Zabel, CK Hu,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
yingjoe.chen-NuS5LvNUpcJWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1485169525-22163-2-git-send-email-yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Mon, Jan 23, 2017 at 07:05:14PM +0800, YT Shen wrote:
> Add decriptions about supported chips, including MT2701 & MT8173
>
> Signed-off-by: YT Shen <yt.shen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 ++
> Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt | 2 ++
> 2 files changed, 4 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox