Re: [PATCH 4/4] soc: mediatek: Add MT2701/MT7623 scpsys driver
On Wed, Dec 30, 2015 at 2:41 PM, James Liao wrote: > > From: Shunli Wang > > Add scpsys driver for MT2701 and MT7623. > > Signed-off-by: Shunli Wang > Signed-off-by: James Liao > --- > drivers/soc/mediatek/Kconfig | 11 +++ > drivers/soc/mediatek/Makefile| 1 + > drivers/soc/mediatek/mtk-scpsys-mt2701.c | 161 > +++ > 3 files changed, 173 insertions(+) > create mode 100644 drivers/soc/mediatek/mtk-scpsys-mt2701.c > > diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig > index eca6fb7..92cf838 100644 > --- a/drivers/soc/mediatek/Kconfig > +++ b/drivers/soc/mediatek/Kconfig > @@ -39,3 +39,14 @@ config MTK_SCPSYS_MT8173 > driver. > The System Control Processor System (SCPSYS) has several power > management related tasks in the system. > + > +config MTK_SCPSYS_MT2701 > + bool "SCPSYS Support MediaTek MT2701 and MT7623" > + depends on ARCH_MEDIATEK || COMPILE_TEST > + select MTK_SCPSYS > + default ARCH_MEDIATEK > + help > + Say yes here to add support for the MT2701/MT7623 SCPSYS power > + domain driver. > + The System Control Processor System (SCPSYS) has several power > + management related tasks in the system. I don't think we really want different drivers and Kconfig options. Can we just use different compatibles to select the appropriate scp_domain_data? -Dan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/5] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for mt2701
Hi Biao and Joe,
On Fri, Dec 18, 2015 at 11:13 PM, Yingjoe Chen
wrote:
> On Fri, 2015-12-11 at 17:07 +0800, Biao Huang wrote:
>> Add mt2701 support using mediatek common pinctrl driver.
>> MT2701 have some special pins need an extra setting register
>> than other ICs, so adding this support to common code.
>>
>> Signed-off-by: Biao Huang
>> ---
>> drivers/pinctrl/mediatek/Kconfig |6 +
>> drivers/pinctrl/mediatek/Makefile |1 +
>> drivers/pinctrl/mediatek/pinctrl-mt2701.c | 590 +++
>> drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 14 +
>> drivers/pinctrl/mediatek/pinctrl-mtk-common.h | 12 +-
>> drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h | 2323
>> +
>> 6 files changed, 2945 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2701.c
>> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h
>
> This patch looks good to me.
> Thanks
>
> Acked-by: Yingjoe Chen
>
> Joe.C
>
>>
>> diff --git a/drivers/pinctrl/mediatek/Kconfig
>> b/drivers/pinctrl/mediatek/Kconfig
>> index 02f6f92..13e9939 100644
>> --- a/drivers/pinctrl/mediatek/Kconfig
>> +++ b/drivers/pinctrl/mediatek/Kconfig
>> @@ -9,6 +9,12 @@ config PINCTRL_MTK_COMMON
>> select OF_GPIO
>>
>> # For ARMv7 SoCs
>> +config PINCTRL_MT2701
>> + bool "Mediatek MT2701 pin control" if COMPILE_TEST && !MACH_MT2701
This is 'bool', so can never be built as a module...
[snip...]
>> +module_init(mtk_pinctrl_init);
Yingjoe - you just ack'ed this change for the other MTK pinctrl.
So, let's apply it here too:
-module_init(mtk_pinctrl_init);
+arch_initcall(mtk_pinctrl_init);
>> +
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_DESCRIPTION("MediaTek MT2701 Pinctrl Driver");
>> +MODULE_AUTHOR("Biao Huang ");
And remove these lines since this isn't a module.
-Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 02/14] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
Hi Philipp,
On Wed, Dec 16, 2015 at 5:52 PM, Philipp Zabel wrote:
> Hi Daniel,
>
> Am Dienstag, den 15.12.2015, 02:57 +0800 schrieb Daniel Kurtz:
>> HI Philipp,
>>
>> This driver is looking really good.
>>
>> But, still some things to think about (mostly small) inline below...
>
> Most of my answers below seem to be "ok" or some form thereof, but I
> have one or two questions regarding the layer_config and crtc_reset
> suggestions.
Answers to your questions below...
>
> [...]
>> > +static void mtk_ovl_layer_config(void __iomem *ovl_base, unsigned int idx,
>> > + struct mtk_plane_state *state)
>> > +{
>> > + struct mtk_plane_pending_state *pending = &state->pending;
>> > + unsigned int addr = pending->addr;
>> > + unsigned int pitch = pending->pitch & 0x;
>> > + unsigned int fmt = pending->format;
>> > + unsigned int offset = (pending->y << 16) | pending->x;
>> > + unsigned int src_size = (pending->height << 16) | pending->width;
>> > + unsigned int con;
>> > +
>> > + con = has_rb_swapped(fmt) << 24 | ovl_fmt_convert(fmt) << 12;
>>
>> Call these conversion routines earlier (during atomic_check) and just add the
>> resulting "con" value to pending.
>
> You mean to add a .layer_atomic_check callback to the mtk_ddp_comp ops?
I didn't have any particular implementation in mind.
But, yeah... maybe a new "check" callback to pre-compute and formally
check the provided state.
This might be overkill though if it ends up adding a lot of overhead
for these values which can never really fail anyway.
> [...]
> How about this:
>
> static void mtk_drm_crtc_reset(struct drm_crtc *crtc)
> {
> struct mtk_crtc_state *state;
>
> if (crtc->state) {
> if (crtc->state->mode_blob)
> drm_property_unreference_blob(crtc->state->mode_blob);
>
> state = to_mtk_crtc_state(crtc->state);
> memset(state, 0, sizeof(*state));
> } else {
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> if (!state)
> return;
> crtc->state = &state->base;
> }
>
> state->base.crtc = crtc;
> }
lgtm
> [...]
> Thanks for the review!
Thanks for the patches!!
>
> regards
> Philipp
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/3] arm64: dts: mt8173: Add thermal zone node.
On Wed, Dec 16, 2015 at 6:09 PM, dawei chien wrote:
> On Wed, 2015-12-16 at 16:34 +0800, Daniel Kurtz wrote:
>> On Wed, Dec 16, 2015 at 11:59 AM, Dawei Chien
>> wrote:
>> >
>> > This adds thermal zone node to Mediatek MT8173 dtsi file.
>> >
>> > Signed-off-by: Dawei Chien
>> > ---
>> > This patch is base on patchset:
>> > https://lkml.org/lkml/2015/11/30/239
>> > ---
>> > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 43
>> > ++
>> > 1 file changed, 43 insertions(+)
>> >
>> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> > b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> > index fda805d..4114cee 100644
>> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> > @@ -188,6 +188,49 @@
>> > clock-output-names = "cpum_ck";
>> > };
>> >
>> > + thermal-zones {
>> > + cpu_thermal: cpu_thermal {
>> > + polling-delay-passive = <1000>; /* milliseconds */
>> > + polling-delay = <1000>; /* milliseconds */
>> > +
>> > + thermal-sensors = <&thermal 0>;
>>
>> This should be <&thermal> with the MTK temp sensor node in
>> https://lkml.org/lkml/2015/11/30/239 patch series.
>>
>> -Dan
>
> Hi Dan,
> Sascha's thermal driver V12 only register sensor id as 0, so we need to
> register sensor id as 0 to device tree as well.
>
> Either <&thermal 0> or <&thermal>, sensor id should be 0 for two cases.
> I try this two case, function all work fine for two cases. May I have
> any misunderstand? Please kindly give your comment.
> I will re-send this patch again once you tell me the reason, thank you.
In the new patchset, Sascha changed it to:
#thermal-sensor-cells = <0>;
Which means the <&thermal> phandle no longer has any arguments.
Thanks!
-Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/3] arm64: dts: mt8173: Add thermal zone node.
On Wed, Dec 16, 2015 at 11:59 AM, Dawei Chien wrote:
>
> This adds thermal zone node to Mediatek MT8173 dtsi file.
>
> Signed-off-by: Dawei Chien
> ---
> This patch is base on patchset:
> https://lkml.org/lkml/2015/11/30/239
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 43
> ++
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index fda805d..4114cee 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -188,6 +188,49 @@
> clock-output-names = "cpum_ck";
> };
>
> + thermal-zones {
> + cpu_thermal: cpu_thermal {
> + polling-delay-passive = <1000>; /* milliseconds */
> + polling-delay = <1000>; /* milliseconds */
> +
> + thermal-sensors = <&thermal 0>;
This should be <&thermal> with the MTK temp sensor node in
https://lkml.org/lkml/2015/11/30/239 patch series.
-Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
On Tue, Dec 15, 2015 at 11:30 AM, Jitao Shi wrote:
> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
>
> Signed-off-by: Jitao Shi
> ---
> Changes since v5
> -fix compile errors when CONFIG_GPIOLIB=n
> ---
> drivers/gpu/drm/bridge/Kconfig | 10 +
> drivers/gpu/drm/bridge/Makefile|1 +
> drivers/gpu/drm/bridge/parade-ps8640.c | 472
>
> 3 files changed, 483 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 639..dcfdbc9 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -41,4 +41,14 @@ config DRM_PARADE_PS8622
> ---help---
> Parade eDP-LVDS bridge chip driver.
>
> +config DRM_PARADE_PS8640
> + tristate "Parade PS8640 MIPI DSI to eDP Converter"
> + depends on OF
> + select DRM_KMS_HELPER
> + select DRM_PANEL
> + ---help---
> + Choose this option if you have PS8640 for display
> + The PS8640 is a high-performance and low-power
> + MIPI DSI to eDP converter
> +
> endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index d4e28be..272e3c01 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
> obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw_hdmi-ahb-audio.o
> obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> new file mode 100644
> index 000..bf0c3c37
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -0,0 +1,472 @@
> +/*
> + * Copyright (c) 2014 MediaTek Inc.
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define PAGE2_GPIO_L 0xa6
> +#define PAGE2_GPIO_H 0xa7
> +#define PS_GPIO9 BIT(1)
> +#define PAGE2_I2C_BYPASS 0xea
> +#define I2C_BYPASS_EN 0xd0
> +
> +#define PAGE3_SET_ADD 0xfe
> +#define PAGE3_SET_VAL 0xff
> +#define VDO_CTL_ADD0x13
> +#define VDO_DIS0x18
> +#define VDO_EN 0x1c
> +
> +#define PAGE4_REV_L0xf0
> +#define PAGE4_REV_H0xf1
> +#define PAGE4_CHIP_L 0xf2
> +#define PAGE4_CHIP_H 0xf3
> +
> +#define bridge_to_ps8640(e)container_of(e, struct ps8640, bridge)
> +#define connector_to_ps8640(e) container_of(e, struct ps8640, connector)
> +
> +struct ps8640 {
> + struct drm_connector connector;
> + struct drm_bridge bridge;
> + struct i2c_client *page[6];
> + struct ps8640_driver_data *driver_data;
> + struct regulator *pwr_1v2_supply;
> + struct regulator *pwr_3v3_supply;
> + struct drm_panel *panel;
> + struct gpio_desc *gpio_rst_n;
> + struct gpio_desc *gpio_slp_n;
> + struct gpio_desc *gpio_mode_sel_n;
> + bool enabled;
> +};
> +
> +static int ps8640_regr(struct i2c_client *client, u8 reg, u8 *value)
> +{
> + int ret;
> +
> + ret = i2c_master_send(client, ®, 1);
> + if (ret <= 0) {
> + dev_err(&client->dev, "Failed to send i2c command, ret=%d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = i2c_master_recv(client, value, 1);
> + if (ret <= 0) {
> + dev_err(&client->dev, "Failed to recv i2c data, ret=%d\n",
> ret);
> + return ret;
> + }
i2c_transfer should be a bit more efficient for reading one byte.
> +
> + return 0;
> +}
> +
> +static int ps8640_regw(struct i2c_client *client, u8 reg, u8 value)
> +{
> + int ret;
> + char buf[2];
> +
> + buf[0] = reg;
> + buf[1] = value;
> + ret = i2c_master_send(client, buf, ARRAY_SIZE(buf));
> + if (ret <= 0) {
> + dev_err(&client->dev, "Failed to send i2c command, ret=%d\n",
> + ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static bool ps8640_check_valid_id(struct ps8640 *ps_bridge)
> +{
> + struct i2c_clien
Re: [PATCH v6 3/5] memory: mediatek: Add SMI driver
Hi Yong,
On Tue, Dec 15, 2015 at 10:38 AM, Yong Wu wrote:
> On Mon, 2015-12-14 at 19:18 +0100, Matthias Brugger wrote:
>> On Tuesday 08 Dec 2015 17:49:11 Yong Wu wrote:
>> > This patch add SMI(Smart Multimedia Interface) driver. This driver
>> > is responsible to enable/disable iommu and control the power domain
>> > and clocks of each local arbiter.
>> >
>> > Signed-off-by: Yong Wu
>> > ---
>> > Currently SMI offer mtk_smi_larb_get/put to enable the power-domain
>> > ,clocks and initialize the iommu configuration register for each a local
>> > arbiter, The reason is:
>> > a) If a device would like to disable iommu, it also need call
>> > mtk_smi_larb_get/put to enable its power and clocks.
>> > b) The iommu core don't support attach/detach a device within a
>> > iommu-group. So we cann't use iommu_attach_device(iommu_detach_device)
>> > instead
>> > of mtk_smi_larb_get/put.
>> >
> [..]
>> > +static int
>> > +mtk_smi_enable(struct device *dev, struct clk *apb, struct clk *smi)
>> > +{
>> > + int ret;
>> > +
>> > + ret = pm_runtime_get_sync(dev);
>> > + if (ret < 0)
>> > + return ret;
>> > +
>> > + ret = clk_prepare_enable(apb);
>> > + if (ret)
>> > + goto err_put_pm;
>> > +
>> > + ret = clk_prepare_enable(smi);
>> > + if (ret)
>> > + goto err_disable_apb;
>> > +
>> > + return 0;
>> > +
>> > +err_disable_apb:
>> > + clk_disable_unprepare(apb);
>> > +err_put_pm:
>> > + pm_runtime_put_sync(dev);
>> > + return ret;
>> > +}
>> > +
>> > +static void
>> > +mtk_smi_disable(struct device *dev, struct clk *apb, struct clk *smi)
>> > +{
>> > + clk_disable_unprepare(smi);
>> > + clk_disable_unprepare(apb);
>> > + pm_runtime_put_sync(dev);
>> > +}
>> > +
>> > +static int mtk_smi_common_enable(struct mtk_smi_common *common)
>> > +{
>> > + return mtk_smi_enable(common->dev, common->clk_apb, common->clk_smi);
>> > +}
>> > +
>> > +static void mtk_smi_common_disable(struct mtk_smi_common *common)
>> > +{
>> > + mtk_smi_disable(common->dev, common->clk_apb, common->clk_smi);
>> > +}
>> > +
>> > +static int mtk_smi_larb_enable(struct mtk_smi_larb *larb)
>> > +{
>> > + return mtk_smi_enable(larb->dev, larb->clk_apb, larb->clk_smi);
>> > +}
>> > +
>> > +static void mtk_smi_larb_disable(struct mtk_smi_larb *larb)
>> > +{
>> > + mtk_smi_disable(larb->dev, larb->clk_apb, larb->clk_smi);
>> > +}
>> > +
>>
>> This is somehow over-engineered. Just use mtk_smi_enable and mtk_smi_disable
>> instead of adding an extra indirection.
>
> I added this only for readable...then the code in mtk_smi_larb_get below
> may looks simple and readable.
>
> If I use mtk_smi_enable/disable directly, the code will be like our
> v5[1], is it OK?
> Maybe I don't need these help function here, and only add more comment
> based on v5.
>
> [1]
> http://lists.linuxfoundation.org/pipermail/iommu/2015-October/014590.html
bike-shedding...
I like the fact that Yong is trying to make his helpers more type-safe.
But, perhaps we can rename "struct mtk_smi_common" as "struct
mtk_smi", and then make "struct mtk_smi_larb" contain a "struct
mtk_smi":
struct mtk_smi {
struct device *dev;
struct clk *clk_apb, *clk_smi;
}
struct mtk_smi_larb {
struct mtk_smi;
...
}
Then, have:
int mtk_smi_enable(struct mtk_smi *smi)
{
clk_enable(smi->clk_apb);
...
}
int mtk_smi_disable(struct mtk_smi *smi)
{
}
int mtk_smi_larb_get(struct device *larbdev)
{
struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
mtk_smi_enable(common);
mtk_smi_enable(&larb->smi);
...
}
>>
>> > +int mtk_smi_larb_get(struct device *larbdev)
>> > +{
>> > + struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
>> > + struct mtk_smi_common *common = dev_get_drvdata(larb->smi_common_dev);
>> > + int ret;
>> > +
>> > + ret = mtk_smi_common_enable(common);
>> > + if (ret)
>> > + return ret;
>> > +
>> > + ret = mtk_smi_larb_enable(larb);
>> > + if (ret)
>> > + goto err_put_smi;
>> > +
>> > + /* Configure the iommu info */
>> > + writel_relaxed(larb->mmu, larb->base + SMI_LARB_MMU_EN);
I think this should probably be writel() not writel_relaxed, since you
really do want the barrier to ensure all other register accesses have
completed before enabling the MMU.
>> > +
>> > + return 0;
>> > +
>> > +err_put_smi:
>> > + mtk_smi_common_disable(common);
>> > + return ret;
>> > +}
>> > +
>> > +void mtk_smi_larb_put(struct device *larbdev)
>> > +{
>> > + struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
>> > + struct mtk_smi_common *common = dev_get_drvdata(larb->smi_common_dev);
>> > +
>> > + writel_relaxed(0, larb->base + SMI_LARB_MMU_EN);
>> > + mtk_smi_larb_disable(larb);
>> > + mtk_smi_common_disable(common);
>> > +}
>> > +
>>
>> Looks strange that you just disable all MMUs while you only enable some of
>> them at runtime. Unfortunately the datasheet I have lacks the SMI part, so I
>> can just gu
Re: [PATCH v7 02/14] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
HI Philipp, This driver is looking really good. But, still some things to think about (mostly small) inline below... On Tue, Dec 1, 2015 at 5:07 AM, Philipp Zabel wrote: > From: CK Hu > > This patch adds an initial DRM driver for the Mediatek MT8173 DISP > subsystem. It currently supports two fixed output streams from the > OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively. > > Signed-off-by: CK Hu > Signed-off-by: YT Shen > Signed-off-by: Philipp Zabel > --- > Changes since v6: > - Split disp_ovl driver from mtk_drm_crtc code > - Added crtc and plane state atomic reset functions > - Toned down debug messages > - Improved error handling for hardware initialization > - Get/put smi_larb in crtc_enable/disable > - Added memory barrier before marking crtc state as ready > - Changed crtc_disable to wait for vblank > - Renamed component power_on/off to start/stop > - Made component ops optional > - Moved crtc creation from disp_ovl driver bind callback into > mtk_drm_kms_init > - Various fixes > - Added support for DRIVER_PRIME feature > - Moved DISP_OVL, DSI, DPI and component initialization into the respective > drivers > --- > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/mediatek/Kconfig| 16 + > drivers/gpu/drm/mediatek/Makefile | 11 + > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 301 +++ > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 565 > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 31 ++ > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 355 + > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 41 ++ > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 275 ++ > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 148 > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 562 +++ > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 53 +++ > drivers/gpu/drm/mediatek/mtk_drm_fb.c | 135 +++ > drivers/gpu/drm/mediatek/mtk_drm_fb.h | 28 ++ > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 227 +++ > drivers/gpu/drm/mediatek/mtk_drm_gem.h | 55 +++ > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 238 > drivers/gpu/drm/mediatek/mtk_drm_plane.h| 58 +++ > 19 files changed, 3102 insertions(+) > create mode 100644 drivers/gpu/drm/mediatek/Kconfig > create mode 100644 drivers/gpu/drm/mediatek/Makefile > create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.h > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index c4bf9a1..8fdb0c2 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -266,3 +266,5 @@ source "drivers/gpu/drm/amd/amdkfd/Kconfig" > source "drivers/gpu/drm/imx/Kconfig" > > source "drivers/gpu/drm/vc4/Kconfig" > + > +source "drivers/gpu/drm/mediatek/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 1e9ff4c..607a49f 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -71,6 +71,7 @@ obj-$(CONFIG_DRM_MSM) += msm/ > obj-$(CONFIG_DRM_TEGRA) += tegra/ > obj-$(CONFIG_DRM_STI) += sti/ > obj-$(CONFIG_DRM_IMX) += imx/ > +obj-$(CONFIG_DRM_MEDIATEK) += mediatek/ > obj-y += i2c/ > obj-y += panel/ > obj-y += bridge/ > diff --git a/drivers/gpu/drm/mediatek/Kconfig > b/drivers/gpu/drm/mediatek/Kconfig > new file mode 100644 > index 000..5343cf1 > --- /dev/null > +++ b/drivers/gpu/drm/mediatek/Kconfig > @@ -0,0 +1,16 @@ > +config DRM_MEDIATEK > + tristate "DRM Support for Mediatek SoCs" > + depends on DRM > + depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST) > + select MTK_SMI > + select DRM_PANEL > + select DRM_MIPI_DSI > + select DRM_PANEL_SIMPLE > + select DRM_KMS_HELPER > + select IOMMU_DMA nit: alphabetize these selects ? > + help > + Choose this option if you have a Mediatek SoCs. > + The module will be called mediatek-drm > + This driver provid
Re: [PATCH v2 0/3] Mediatek EFUSE Support
Hi Srinivas, On Thu, Nov 19, 2015 at 6:46 PM, Andrew-CT Chen wrote: > This patch adds EFUSE support driver which is used by other drivers > like thermal sensor and HDMI impedance. > > There are some efuses these fuses store things like calibration data, > speed bins.. etc. Drivers like thermal sensor, HDMI impedance would > read out this data for configuring the driver. > > Change in v2: > 1. Rebase to 4.4-rc1 > 2. Modify the driver Makefile for more consistent with other drivers > 3. Modify the compatible string to "mediatek,mt8173-efuse" and > "mediatek,efuse" Do you still plan to queue this for v4.5? > > Andrew-CT Chen (3): > dt-bindings: add document of mediatek efuse driver > nvmem: mediatek: Add Mediatek EFUSE driver > dts: arm64: Add EFUSE device node > > .../devicetree/bindings/nvmem/mtk-efuse.txt| 36 + > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 5 ++ > drivers/nvmem/Kconfig | 11 +++ > drivers/nvmem/Makefile | 2 + > drivers/nvmem/mtk-efuse.c | 89 > ++ > 5 files changed, 143 insertions(+) > create mode 100644 Documentation/devicetree/bindings/nvmem/mtk-efuse.txt > create mode 100644 drivers/nvmem/mtk-efuse.c > > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: dts: mt8173: Add nor flash node
Bayi, On Mon, Dec 7, 2015 at 12:46 PM, bayi cheng wrote: > On Mon, 2015-12-07 at 12:34 +0800, bayi cheng wrote: >> On Mon, 2015-12-07 at 12:09 +0800, Daniel Kurtz wrote: >> > Bayi, >> > >> > On Mon, Dec 7, 2015 at 11:53 AM, Bayi Cheng >> > wrote: >> > > Add Mediatek nor flash node >> > > >> > > Signed-off-by: Bayi Cheng >> > > Acked-by: Brian Norris >> > > --- >> > > Previous version of this patch is >> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/386005.html >> > > Drop flash node from mt8173.dtsi accroding review comment >> > >> > Is there a flash on mt8173-evb that can be accessed by the nor_flash ? >> > If so, can you include flash@0 node in the mt8173-evb.dts. >> > >> > -Dan >> > >> Hi Daniel, Thanks for your comments! you are right, there is a flash on >> mt8173-evb which can be accessed by the nor_flash, and I will include >> flash@0 node in mt8173-evb.dts (kernel v3.18) too. >> >> Bayi > > Hi Dan, I have reworked a EVB board for spi nor verify, we replaced the > spi nand flash with spi nor flash on EVB board, > and our shipping EVB board haven't support spi nor flash, So I will not > include flash@0 node in the mt8173-evb.dts. I am sorry to made you > confused! Thanks for confirming. Reviewed-by: Daniel Kurtz -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: dts: mt8173: Add nor flash node
Bayi,
On Mon, Dec 7, 2015 at 11:53 AM, Bayi Cheng wrote:
> Add Mediatek nor flash node
>
> Signed-off-by: Bayi Cheng
> Acked-by: Brian Norris
> ---
> Previous version of this patch is
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/386005.html
> Drop flash node from mt8173.dtsi accroding review comment
Is there a flash on mt8173-evb that can be accessed by the nor_flash ?
If so, can you include flash@0 node in the mt8173-evb.dts.
-Dan
>
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 4dd5f93..af08e97 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -387,6 +387,17 @@
> status = "disabled";
> };
>
> + nor_flash: spi@1100d000 {
> + compatible = "mediatek,mt8173-nor";
> + reg = <0 0x1100d000 0 0xe0>;
> + clocks = <&pericfg CLK_PERI_SPI>,
> +<&topckgen CLK_TOP_SPINFI_IFR_SEL>;
> + clock-names = "spi", "sf";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> i2c3: i2c@1101 {
> compatible = "mediatek,mt8173-i2c";
> reg = <0 0x1101 0 0x70>,
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/2] arm64: dts: mt8173: Add nor flash node
Hi Bayi, Matthias,
Sorry for the late review, one comment below...
On Wed, Nov 18, 2015 at 11:30 AM, Bayi Cheng wrote:
> Add Mediatek nor flash node
>
> Signed-off-by: Bayi Cheng
> Acked-by: Brian Norris
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 4dd5f93..7988656 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -387,7 +387,23 @@
> status = "disabled";
> };
>
> - i2c3: i2c@1101 {
> + nor_flash: spi@1100d000 {
> + compatible = "mediatek,mt8173-nor";
> + reg = <0 0x1100d000 0 0xe0>;
> + clocks = <&pericfg CLK_PERI_SPI>,
> +<&topckgen CLK_TOP_SPINFI_IFR_SEL>;
> + clock-names = "spi", "sf";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + };
I think this flash@0 node represents the flash device present on the
board and should therefore be moved to the board-specific .dts.
-Dan
> + };
> +
> + i2c3: i2c3@1101 {
> compatible = "mediatek,mt8173-i2c";
> reg = <0 0x1101 0 0x70>,
> <0 0x11000280 0 0x80>;
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v5 02/12] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
Hi Philipp, A bunch of review comments inline. On Wed, Nov 4, 2015 at 7:44 PM, Philipp Zabel wrote: > From: CK Hu > > This patch adds an initial DRM driver for the Mediatek MT8173 DISP > subsystem. It currently supports two fixed output streams from the > OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively. > > Signed-off-by: CK Hu > Signed-off-by: YT Shen > Signed-off-by: Philipp Zabel > --- > Changes since v4: > - Add mtk_crtc_state to keep pending state > - Move drm pending vblank event into mtk_crtc_state > - Make mtk_drm_crtc private > - Use drm_dev_alloc and drm_dev_register directly instead of >drm_platform_init > - Drop unnecessary locking in mtk_drm_gem_dump_map_offset > - Remove currently unused mtk_drm_gem_mmap_buf > - Stop referencing plane framebuffers manually > - Set RDMA FIFO output threshold depending on frame width/height/rate > --- > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/mediatek/Kconfig| 16 + > drivers/gpu/drm/mediatek/Makefile | 10 + > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 590 > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 56 +++ > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 218 ++ > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 39 ++ > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 424 > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 86 > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 572 +++ > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 61 +++ > drivers/gpu/drm/mediatek/mtk_drm_fb.c | 151 +++ > drivers/gpu/drm/mediatek/mtk_drm_fb.h | 29 ++ > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 189 + > drivers/gpu/drm/mediatek/mtk_drm_gem.h | 56 +++ > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 167 > drivers/gpu/drm/mediatek/mtk_drm_plane.h| 41 ++ > 18 files changed, 2708 insertions(+) > create mode 100644 drivers/gpu/drm/mediatek/Kconfig > create mode 100644 drivers/gpu/drm/mediatek/Makefile > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.h > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 1a0a8df..9e9987b 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -264,3 +264,5 @@ source "drivers/gpu/drm/sti/Kconfig" > source "drivers/gpu/drm/amd/amdkfd/Kconfig" > > source "drivers/gpu/drm/imx/Kconfig" > + > +source "drivers/gpu/drm/mediatek/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 45e7719..af6b592 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -67,6 +67,7 @@ obj-$(CONFIG_DRM_MSM) += msm/ > obj-$(CONFIG_DRM_TEGRA) += tegra/ > obj-$(CONFIG_DRM_STI) += sti/ > obj-$(CONFIG_DRM_IMX) += imx/ > +obj-$(CONFIG_DRM_MEDIATEK) += mediatek/ > obj-y += i2c/ > obj-y += panel/ > obj-y += bridge/ > diff --git a/drivers/gpu/drm/mediatek/Kconfig > b/drivers/gpu/drm/mediatek/Kconfig > new file mode 100644 > index 000..5343cf1 > --- /dev/null > +++ b/drivers/gpu/drm/mediatek/Kconfig > @@ -0,0 +1,16 @@ > +config DRM_MEDIATEK > + tristate "DRM Support for Mediatek SoCs" > + depends on DRM > + depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST) > + select MTK_SMI > + select DRM_PANEL > + select DRM_MIPI_DSI > + select DRM_PANEL_SIMPLE > + select DRM_KMS_HELPER > + select IOMMU_DMA > + help > + Choose this option if you have a Mediatek SoCs. > + The module will be called mediatek-drm > + This driver provides kernel mode setting and > + buffer management to userspace. > + > diff --git a/drivers/gpu/drm/mediatek/Makefile > b/drivers/gpu/drm/mediatek/Makefile > new file mode 100644 > index 000..ba6d3fc > --- /dev/null > +++ b/drivers/gpu/drm/mediatek/Makefile > @@ -0,0 +1,10 @@ > +mediatek-drm-y := mtk_drm_drv.o \ > + mtk_drm_crtc.o \ > + mtk_drm_ddp.o \ > + mtk_drm_ddp_comp.o \ > + m
Re: [PATCH v4 3/3] arm64: dts: mt8173: Add nor flash node
Sergei,
On Wed, Oct 14, 2015 at 7:05 PM, Sergei Shtylyov
wrote:
> Hello.
>
> On 10/14/2015 4:07 AM, Daniel Kurtz wrote:
>
>>>> Add Mediatek nor flash node
>>>>
>>>> Signed-off-by: Bayi Cheng
>>>> ---
>>>>arch/arm64/boot/dts/mediatek/mt8173.dtsi | 15 +++
>>>>1 file changed, 15 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>>>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>>>> index d18ee42..385c2e4 100644
>>>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>>>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>>>> @@ -365,6 +365,21 @@
>>>> status = "disabled";
>>>> };
>>>>
>>>> + nor_flash: spi@1100d000 {
>>>
>>>
>>> I don't think this is a good label name for a SPI controller.
>>
>>
>> You think "spi" is not a good name for SPI controller?
>> Or you mean the label "nor_flash"?
>
>
>I think I said clearly: "label". :-)
>
>> Would you prefer:
>>
>>spi_nor_flash: spi@1100d000
>
>
>I'd prefer the "_nor_flash" part to be dropped, to be used for the real
> flash device (if needed) which is a sub-node of this node.
The dedicated nor_flash spi bus cannot just be labeled 'spi', as that
would conflict with the general purpose 'spi' bus. Instead, it is
given a unique label that can be used as a phandle elsewhere (e.g., in
a board file, to enable the bus). The name "spi_nor_flash" makes it
clear that this spi bus is only for use for accessing the nor_flash.
Bayi: Actually, this reminds me. I'd prefer if the bus node was
disabled by default, and only enabled by boards as required. So, the
node should include:
status = "disabled";
-Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] arm64: dts: mt8173: Add nor flash node
Sergei,
On Tue, Oct 13, 2015 at 10:33 PM, Sergei Shtylyov
wrote:
> Hello.
>
> On 10/13/2015 12:39 PM, Bayi Cheng wrote:
>
>> Add Mediatek nor flash node
>>
>> Signed-off-by: Bayi Cheng
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 15 +++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index d18ee42..385c2e4 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -365,6 +365,21 @@
>> status = "disabled";
>> };
>>
>> + nor_flash: spi@1100d000 {
>
>
>I don't think this is a good label name for a SPI controller.
You think "spi" is not a good name for SPI controller?
Or you mean the label "nor_flash"?
Would you prefer:
spi_nor_flash: spi@1100d000
>
>> + compatible = "mediatek,mt8173-nor";
>> + reg = <0 0x1100d000 0 0xe0>;
>> + clocks = <&pericfg CLK_PERI_SPI>,
>> +<&topckgen CLK_TOP_SPINFI_IFR_SEL>;
>> + clock-names = "spi", "sf";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + flash@0 {
>> + compatible = "jedec,spi-nor";
>> + reg = <0>;
>> + };
>> + };
>> +
>> i2c3: i2c3@1101 {
>
>
>Grr, the name should be "i2c@1101".
Don't worry. This is already fixed in Matthias' tree:
https://github.com/mbgg/linux-mediatek/commit/1ee35c05d9c67771d649f687e6f76e61e76eb779
-Dan
>
> [...]
>
> MBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
On Fri, Sep 25, 2015 at 2:31 PM, James Liao wrote: > In kernel late init, it turns off all unused clocks, which > needs to access subsystem registers such as VENC and VENC_LT. > > Accessing MT8173 VENC registers needs two top clocks, mm_sel and > venc_sel. Accessing VENC_LT registers needs mm_sel and venclt_sel. > So we need to keep these clocks on before accessing their registers. > > This patch keeps venc_sel / venclt_sel clock on when > VENC / VENC_LT's power is on, to prevent system hang up while > accessing its registeres. > > Signed-off-by: James Liao After the discussions with James here on the list, I'm happy with this fix. Compared to any proposed alternative, this patch seems just as effective and is also simpler and more maintainable and extensible (if other clocks/power domains need the same treatment). Reviewed-by: Daniel Kurtz -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 1/4] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
On Fri, Oct 2, 2015 at 3:40 PM, Philipp Zabel wrote:
> Am Donnerstag, den 01.10.2015, 22:29 +0800 schrieb Daniel Kurtz:
>> On Thu, Oct 1, 2015 at 8:58 PM, Rob Herring wrote:
>> > I was thinking one of the display related blocks like
>> > whatever block provides the main crtc functions.
>>
>> The two "OVL" nodes correspond to the "crtc" functions of the two
>> display pipes in this SoC, we would setup the display-subsystem node
>> like this:
>>
>> display-subsystem {
>> compatible = "mediatek,display-subsystem";
>
> Yes, the problem with the ovl nodes is that there are two equivalent
> ones. Having two equivalent ipu nodes on i.MX6 was the reason to
> introduce the display-subsystem node in the first place, but I'd very
> much prefer to avoid it, if possible.
Oh, interesting. How is it a problem that there are two equivalent ovl nodes?
Why do you prefer to avoid the display-subsystem node?
BTW, what I really meant was for my example was that the
'display-subsystem' 'ports' node lists phandles representing the
'root' nodes for the for the display-subsystem graph.
This matches what we did for rk3288.dtsi:
display-subsystem {
compatible = "mediatek,display-subsystem";
ports = <&ovl0_out>, <&ovl1_out>;
};
> [...]
>> And, any node that needs to poke around in the mmsys_config area, like
>> an ovl, could access it using a phandle <&mmsys> to the common
>> "mediatek,mt8173-mmsys" device, like this:
>>
>> ovl0: ovl@1400c000 {
>>compatible = "mediatek,mt8173-ovl";
>>reg = <0 0x1400c000 0 0x1000>;
>>interrupts = ;
>>clocks = <&mmsys CLK_MM_DISP_OVL0>;
>>iommus = <&iommu M4U_LARB0_ID M4U_PORT_DISP_OVL0>;
>>mediatek,mmsys = <&mmsys>;
>>status = "disabled";
>> };
>
> I think the ovl node has no business linking to mmsys_config.
> It's the drm driver code that sets up the pipeline, including the crtc
> -> encoder connections
My original thinking is that the "ovl" node should link to the
mmsys_config since the mmsys_config has the ovl output select
registers.
An 'ovl' driver would then use the phandle to the syscon to find a
regmap to safely access the registers it needs.
>> One idea to reduce the size of the of_graph would be to just model the
>> entrance/exit points from the MM subsystem in dt. So, instead of:
>> ovl0 -> color0 -> aal -> od -> ufoe -> dsi0 -> dsi-edp-bridge
>> ovl1 -> color1 -> gamma0 -> dpi0 -> hdmi
>>
>> We can do something like this:
>> ovl0 -> dsi0 -> dsi-edp-bridge
>> ovl1 -> dpi0 -> hdmi
>>
>> But ... this might be too limiting for some applications.
>
> I'm already worried about having left out the DISP_PATH0 and DISP_PATH1
> multiplexers from my DT graph example. There are so many ways to do this
> slightly wrong and then having to live with the stable bindings, that
> I'd rather not put an approximation of the real hardware into the device
> tree.
> Now that I've heard it is acceptable for one driver to look for its
> components by their compatible value, I'm leaning towards not describing
> the graph in the DT.
Sure, it would be interesting to see how that would look, too.
-Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
On Fri, Oct 2, 2015 at 11:00 AM, James Liao wrote: > Hi Daniel, > > On Thu, 2015-10-01 at 18:08 +0800, Daniel Kurtz wrote: >> I see two cases where "a power domain is a consumer of a clock": >> (a) the clock is needed to access the power domain control >> registers. The clock must actually be in another power domain, since >> otherwise you could never turn *on* the power domain in question. >> (b) the clock is needed to talk to the power domain that is about to >> turn off, or that was just turned on - these clocks are usually used >> to control some kind of bus arbitration, etc. In this case, the >> clocks are only accessed when the power domain is on. >> >> I would argue that in both cases, the clock should in theory should >> only be enabled/disabled by the power on/off routine for the duration >> of time that is needed, and that it should not be "left enabled" by >> the power domain on/off function... I can see how this might be a >> useful optimization - but it also seems like a way to burn extra power >> by leaving on a clock that is not necessarily being used. >> >> But - perhaps I am over thinking this, and it is standard practice to >> bundle power domains with the clocks that service components in the >> power domain. > > Yes, you are right. Power domain on/off operations need clocks to get > status of the subsystem. Keeping clocks on during power domain on is an > optimization. > > But to model a clock controller as a power domain consumer, or say we > need to control power domain before clock on/off, is not a good practice > because we always consider clock operations should be light weight. > Power domains should be controlled explicitly by subsystem drivers, > instead of hiding behind clock controls. > >> Or, alternatively, just prepare venc_sel once during init, for each >> clock controller that needs it, when configuring the clock controller >> node (for example, in mtk_vencsys_init()). This is similar to how we >> set up 'critical clocks'. >> By just preparing the clock, you tell the common clock core: >> "my clock controller will need this clock later; please make sure >> that it can be enabled/disabled later during atomic context." > > In current implementation, PLLs will be turned on in clk_prepare(). So > if a clock is always prepared, its parent PLL will be kept on even if > the clock is not enabled. It consumes extra power, so we don't prefer > this kind of solution. Actually, I should have proposed adding prepare / unprepare callbacks to mtk_clk_gate_ops in which we prepare_enable/disable_unprepare venc_sel (& mm_sel). This should correctly track all of the clk reference counting needed to access the venc clock control registers. However, this would not actually solve the issue that this patch is trying to fix, since nobody would have called the prepare_clk(venc_cke0) before clk_disable_unused_subtree(venc_cke0). Bummer. I think the crux of the original issue is that the mediatek/clk-gate.c is_enabled() callbacks may be called at a point in time when venc_sel is disabled but VENC PD is enabled. So, perhaps an easier, but still a little hacky way out is to keep the clk & PD problems separate, and just check __clk_is_enabled(venc_sel) before reading the venc clk status register. WDYT? By the way, I'm not really opposed to your current implementation either, I was just helping Matthias & Lucas understand in enough detail that they can help review. -Dan > > > Best regards, > > James > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 1/4] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
On Thu, Oct 1, 2015 at 8:58 PM, Rob Herring wrote:
> On Thu, Oct 1, 2015 at 3:59 AM, Philipp Zabel wrote:
>> Am Mittwoch, den 30.09.2015, 12:13 -0500 schrieb Rob Herring:
>>> On Mon, Sep 21, 2015 at 3:11 AM, Philipp Zabel
>>> wrote:
>>> > Note how the display-subsystem node overlaps the larb node. Is that
>>> > acceptable?
>>>
>>> Given what the graph looks like, perhaps. However, do you really need
>>> a container node? It only serves to provide a list of nodes (e.g. all
>>> the children) to include as components. There are other ways to
>>> determine this list. You could find all nodes just searching
>>> compatible strings for each component. You just need to bind the drm
>>> driver to some other DT node. Is there no node you can pick as the
>>> master component?
>>
>> There is the mmsys clock-controller node at the top of the MMSYS address
>> space (0x1400-0x14ff):
>>
>> mmsys: clock-controller@1400 {
>> compatible = "mediatek,mt8173-mmsys", "syscon";
>> reg = <0 0x1400 0 0x1000>;
>> #clock-cells = <1>;
>> };
>>
>> Its register space also contains the MMSYS_CONFIG region that controls
>> the multiplexers between the display function blocks, so that would be a
>> good candidate.
>> No driver binds to this node yet, the clocks are registered with
>> CLK_OF_DECLARE.
>>
>> I'll try to bind to this node and have the driver find sibling nodes
>> using their compatible strings.
>
> That doesn't seem like a good choice since there are other functions
> in the block. I was thinking one of the display related blocks like
> whatever block provides the main crtc functions.
The two "OVL" nodes correspond to the "crtc" functions of the two
display pipes in this SoC, we would setup the display-subsystem node
like this:
display-subsystem {
compatible = "mediatek,display-subsystem";
ports = <&ovl0>, <&ovl1>;
};
And, any node that needs to poke around in the mmsys_config area, like
an ovl, could access it using a phandle <&mmsys> to the common
"mediatek,mt8173-mmsys" device, like this:
ovl0: ovl@1400c000 {
compatible = "mediatek,mt8173-ovl";
reg = <0 0x1400c000 0 0x1000>;
interrupts = ;
clocks = <&mmsys CLK_MM_DISP_OVL0>;
iommus = <&iommu M4U_LARB0_ID M4U_PORT_DISP_OVL0>;
mediatek,mmsys = <&mmsys>;
status = "disabled";
};
One idea to reduce the size of the of_graph would be to just model the
entrance/exit points from the MM subsystem in dt. So, instead of:
ovl0 -> color0 -> aal -> od -> ufoe -> dsi0 -> dsi-edp-bridge
ovl1 -> color1 -> gamma0 -> dpi0 -> hdmi
We can do something like this:
ovl0 -> dsi0 -> dsi-edp-bridge
ovl1 -> dpi0 -> hdmi
But ... this might be too limiting for some applications.
So, I think we should just live with the big graph.
I would, however, recommend that you move the graph to its own
mt8173-display-graph.dtsi file which would be #included into a board
specific .dts file.
If you let the board .dts include the graph, then we can possibly
shrink the resulting board specific device tree -
At first we would make the full graph in one .dtsi as above
"mt8173-display-graph.dtsi".
This is the full reference graph that will always work.
Then, if a particular board used a fixed configuration, the system
integrator could create a smaller graph with just the graph nodes that
they care about.
For example, if mt8173-evb only supports a single HDMI output, then
perhaps you would just
set up the endpoints for this single fixed function display pipe in
mt8173-evb-display-graph.dtsi:
&ovl1 {
status = "okay";
port {
ovl1_to_color1: endpoint@0 {
remote-endpoint = <&color1_from_ovl1>;
};
};
};
&color1 {
status = "okay";
port@0 {
color1_from_ovl1: endpoint@1 {
remote-endpoint = <&ovl1_to_color1>;
};
};
port@1 {
color1_to_gamma: endpoint@0 {
remote-endpoint = <&gamma_from_color1>;
};
};
};
&gamma {
status = "okay";
port@0 {
gamma_from_color1: endpoint {
remote-endpoint = <&color1_to_gamma>;
};
};
port@1 {
gamma_to_dpi0: endpoint@3 {
remote-endpoint = <&dpi0_from_gamma>;
};
};
};
&dpi0 {
status = "okay";
port@0 {
dpi0_from_gamma: endpoint@2 {
remote-endpoint = <&gamma_to_dpi0>;
};
};
port@1 {
dpi0_to_hdmi: endpoint {
remote-endpoint = <&hdmi_from_dpi0>;
};
};
};
Notice that this also only enables the nodes that we care about (all
of the other nodes would be disabled by default).
I this would allow full flexibility but also drastically cut down on
the resulting .dts size.
The individual component drivers would then march down their graphs
ensuring that all of the corresponding components have been bound, and
then themselves appropriately based on their set of endpoints that are
available.
What d
Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
+linux-clk +linux-pm and the genpd and clock gurus
Hi James,
On Thu, Oct 1, 2015 at 5:26 PM, James Liao wrote:
> Hi Daniel,
>
> On Thu, 2015-10-01 at 16:07 +0800, Daniel Kurtz wrote:
>> Hmm... below is my current understanding.
>>
>> In the current software architecture, we have split the "venc"
>> subsystem register space into two parts (two dt nodes), with each node
>> handled instantiated as its own platform device, and handled by a
>> different platform driver:
>>
>> vencsys: clock-controller@1800 {
>> compatible = "mediatek,mt8173-vencsys", "syscon";
>> reg = <0 0x1800 0 0x1000>;
>> #clock-cells = <1>;
>> };
>>
>> /* TBD - a venc driver has not been posted to the list so I don't
>> really know yet what it will look like */
>> venc: encoder@~1800 {
>>compatible = "mediatek,mt8173-venc?";
>>reg = <0 ~0x1800 0 ?>;
>>clocks = <& <&vencsys CLK_VENC_CKE1>, <&vencsys CLK_VENC_CKE0>, ...;
>>clock-names = "apb", "smi", ...;
>>...
>> };
>>
>> Each independent driver must take appropriate independent action to
>> ensure that any clock required to access its associated registers is
>> enabled when accessing said registers.
>> In other words,
>> * the venc *clock-controller* driver that must enable any clocks
>> required to access the *clock control* registers
>> * the venc *encoder* driver must enable clocks any clocks required to
>> access the *encoder* registers
>
>> Actually, the situation is a little worse that this, since we also
>> have a 'larb' node in the same register space, whose driver must also
>> ensure that VENC_SEL is enabled before accessing its registers:
>>
>> larb3: larb@18001000 {
>> compatible = "mediatek,mt8173-smi-larb";
>> reg = <0 0x18001000 0 0x1000>;
>> mediatek,smi = <&smi_common>;
>> power-domains = <&scpsys MT8173_POWER_DOMAIN_VENC>;
>> clocks = <&vencsys CLK_VENC_CKE1>, <&vencsys CLK_VENC_CKE0>;
>> clock-names = "apb", "smi";
>> };
>>
>> Personally, I am not opposed to using the power-domain enable/disable
>> as a proxy for also enabling/disabling the "subsystem register bank"
>> clock as is done in this patch and by the scpsys driver in general.
>> However, it feels a bit like an abuse of the power domain api.
>>
>> > I preferred to keep venc_sel on during VENC power on because I'm not
>> > sure there is any other framework may control VENC's registers during
>> > kernel init.
>>
>> The misunderstanding here is the interpretation of "VENC's registers".
>> In this case, the registers in question are those owned by the
>> "vencsys: clock-controller@1800" node, and the driver accessing
>> them is drivers/clk/mediatek/clk-gate.c.
>
> The situation is more complex than you mentioned above. VENC (0x1800
> ~ 0x1800) for example, if we want to avoid hanging up while
> accessing registers, we need to:
>
> - Prevent venc_sel off while VENC is powered on.
> - Prevent mm_sel off while MM is powered on.
>
> First, it's not worth to control power domains in clock control path
> because it's too expensive. So we want to keep clock on before accessing
> registers or during the domain is powered on.
>
> Besides, modeling a clock controller as a consumer of power domain may
> not a good idea, because there are power domains be consumers of clocks,
> such as:
>
> [MT8173_POWER_DOMAIN_MM] = {
> .name = "mm",
> [...]
> .clk_id = MT8173_CLK_MM,
> [...]
> },
I see two cases where "a power domain is a consumer of a clock":
(a) the clock is needed to access the power domain control
registers. The clock must actually be in another power domain, since
otherwise you could never turn *on* the power domain in question.
(b) the clock is needed to talk to the power domain that is about to
turn off, or that was just turned on - these clocks are usually used
to control some kind of bus arbitration, etc. In this case, the
clocks are only accessed when the power domain is on.
I would argue that in both cases, the clock should in theory should
only be enabled/disabled by the power on/off routine for the duration
of time that is needed, and that it should not be "left enabled" by
the power domain on/off function... I can see how this might be a
useful optimiz
Re: [RFC v3 0/7] MT8173 DRM support
Hi Philipp,
On Wed, Sep 30, 2015 at 11:29 PM, Philipp Zabel wrote:
> Hi,
>
> this is an update to the MT8173 DRM support RFC. These patches have
> a build dependency on two other patches on top of v4.3-rc1:
> https://patchwork.kernel.org/patch/6914941 ("iommu: Implement common IOMMU
> ops for DMA mapping"), and
> https://patchwork.kernel.org/patch/6928621 ("memory: mediatek: Add SMI
> driver").
>
> I have changed the device tree bindings to group the display function blocks
> under a display-subsystem node. I'm not happy with this organisation as the
> display-subsystem node is not really a physical bus. I'd much prefer
> connecting
> the function blocks with an of-graph, if it is acceptable for just the graph
> to cost >8 KiB dtb size.
>
> The added HDMI driver still directly accesses an undocumented register in the
> apmixedsys (clock-controller) register space to set a divider of the TVDPLL.
> That will be fixed as soon as I understand what this clock is connected to.
>
> Changes since v2:
> - Grouped DISP function block nodes under the display-subsystem node
> - Added of-graph ports to binding documentation
> - Dropped legacy framebuffer support
> - Dropped plane zpos property
> - Update plane->disp_size in atomic_update instead of atomic_check
> - Added asynchronous commit support
> - Split DSI and MIPI TX (MIPI D-PHY) drivers
> - Added DPI driver
> - Added HDMI driver
> - Added HDMI DDC I2C master driver
> - Added HDMI PHY driver
>
> CK Hu (3):
> dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
> drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
> drm/mediatek: Add DSI sub driver
>
> Daniel Kurtz (1):
> drm/mediatek: Add HDMI support
Thanks for the shout-out, but I really can't take any credit for this patch :-)
Somewhere along the life of this patch its ownership changed.
It should probably be Jie Qiu as per its SOB.
>
> Jie Qiu (2):
> drm/mediatek: Add DPI sub driver
> drm/mediatek: enable hdmi output control bit
>
> Philipp Zabel (1):
> dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
Can you also include the actual mt8173.dtsi (& mt8173-evb.dts) changes
that use this binding next time?
This will make it possible to actually build and test the driver.
Thanks,
-Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
Hi James,
On Thu, Oct 1, 2015 at 3:15 PM, James Liao wrote:
> Hi Lucas,
>
> On Wed, 2015-09-30 at 11:07 +0200, Lucas Stach wrote:
>> > If the VENC power domain is disabled, then accesses to the vencsys
>> > registers just silently fail (i.e., reads probably
>> > return all 0s).
>>
>> If this ever happens it is really unfortunate and needs fixing, too. If
>> you need the power domain to be powered ON to properly read or even
>> change the clock registers, the clock driver needs to be a consumer of
>> the power domain, so any clock operations powers the domain up.
>
> A subsystem should be powered on before its clock operations. But I
> think this flow should be guaranteed by VENC driver. This patch is
> focused on the race between disabling unused clocks and power domains by
> frameworks.
>
>> > In theory, we could add "clocks=<&topckgen CLK_TOP_VENC_SEL>;" to the
>> > vencsys clock-controller node. On initialization, mtk_vencsys_init()
>> > could then pass venc_sel to the generic MT8173 gate clock driver, and
>> > it would then clk_enable(venc_sel)/_disable(venc_sel) around any
>> > access to the clock-controller registers. James, however, thinks
>> > this is a lot of extra overhead, and instead has proposed the fix in this
>> > patch,
>> > where venc_sel is forced on whenever the VENC power domain is enabled.
>> >
>> I would still say this is the correct solution. If the vencsys clock
>> registers are itself clocked by VENC_SEL this driver needs to make sure
>> this clock is running at the appropriate times. I understand that this
>> may be a bit of an overhead, but clock enable/disable paths are not
>> really performance critical.
>>
>> > So, this patch is a bit of a hack, but the mtk scpsys driver already
>> > does something similar for the MM & MFG clocks - these clocks are
>> > always enabled whenever certain power domains are enabled, and they
>> > are only disabled when all such power domains are disabled. I'm not
>> > 100% why these clocks must always be kept on whenever these power
>> > domains are enabled, but probably to solve a similar problem where
>> > these clocks are needed to access some registers at a time when these
>> > clocks would not otherwise be explicitly enabled.
>> >
>> I can't really argue with this being the wrong solution if we already
>> have precedent of the same solution being used for other domains. But I
>> would still ask you to re-evaluate with the above in mind.
>
> One cause of the hang up issue is frameworks' behavior. Power domain
> framework and clock framework work independently during kernel init. So
> their control flow can't be guaranteed by a suitable driver, such as
> VENC driver.
Hmm... below is my current understanding.
In the current software architecture, we have split the "venc"
subsystem register space into two parts (two dt nodes), with each node
handled instantiated as its own platform device, and handled by a
different platform driver:
vencsys: clock-controller@1800 {
compatible = "mediatek,mt8173-vencsys", "syscon";
reg = <0 0x1800 0 0x1000>;
#clock-cells = <1>;
};
/* TBD - a venc driver has not been posted to the list so I don't
really know yet what it will look like */
venc: encoder@~1800 {
compatible = "mediatek,mt8173-venc?";
reg = <0 ~0x1800 0 ?>;
clocks = <& <&vencsys CLK_VENC_CKE1>, <&vencsys CLK_VENC_CKE0>, ...;
clock-names = "apb", "smi", ...;
...
};
Each independent driver must take appropriate independent action to
ensure that any clock required to access its associated registers is
enabled when accessing said registers.
In other words,
* the venc *clock-controller* driver that must enable any clocks
required to access the *clock control* registers
* the venc *encoder* driver must enable clocks any clocks required to
access the *encoder* registers
Actually, the situation is a little worse that this, since we also
have a 'larb' node in the same register space, whose driver must also
ensure that VENC_SEL is enabled before accessing its registers:
larb3: larb@18001000 {
compatible = "mediatek,mt8173-smi-larb";
reg = <0 0x18001000 0 0x1000>;
mediatek,smi = <&smi_common>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_VENC>;
clocks = <&vencsys CLK_VENC_CKE1>, <&vencsys CLK_VENC_CKE0>;
clock-names = "apb", "smi";
};
Personally, I am not opposed to using the power-domain enable/disable
as a proxy for also enabling/disabling the "subsystem register bank"
clock as is done in this patch and by the scpsys driver in general.
However, it feels a bit like an abuse of the power domain api.
> I preferred to keep venc_sel on during VENC power on because I'm not
> sure there is any other framework may control VENC's registers during
> kernel init.
The misunderstanding here is the interpretation of "VENC's registers".
In this case, the registers in question are those owned by the
"vencsys: clock-controller@1800" node, and the driver accessing
them is drivers/clk/mediatek/clk-gate.c.
Be
Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
Hi Matthias & Lucas,
On Sun, Sep 27, 2015 at 7:25 PM, Matthias Brugger
wrote:
>
>
>
> On 25/09/15 10:26, Lucas Stach wrote:
>>
>> Am Freitag, den 25.09.2015, 14:31 +0800 schrieb James Liao:
>>>
>>> In kernel late init, it turns off all unused clocks, which
>>> needs to access subsystem registers such as VENC and VENC_LT.
>>>
>>> Accessing MT8173 VENC registers needs two top clocks, mm_sel and
>>> venc_sel. Accessing VENC_LT registers needs mm_sel and venclt_sel.
>>> So we need to keep these clocks on before accessing their registers.
>>>
>>> This patch keeps venc_sel / venclt_sel clock on when
>>> VENC / VENC_LT's power is on, to prevent system hang up while
>>> accessing its registeres.
>>>
>> This changes the binding of an existing driver, so it needs some more
>> consideration. Are VENC_SEL and VENC_LT_SEL really direct clock inputs
>> to the VENC module, or are they some kind of parent clock for one of the
>> existing clocks used by the old VENC binding?
>>
>> If they are direct clock inputs to the VENC module, changing the binding
>> might be still ok at that point, as there shouldn't be many users of
>> that yet.
The MT8173 VENC subsystem clock registers are modeled by the vencsys
clock-controller node:
vencsys: clock-controller@1800 {
compatible = "mediatek,mt8173-vencsys", "syscon";
reg = <0 0x1800 0 0x1000>;
#clock-cells = <1>;
};
These registers, however, are only accessible if:
(a) the VENC power domain is enabled, and
(b) the "venc_sel" clock is enabled.
According to James, venc_sel is a direct clock input the VENC module,
and it is an ancestor to some, but not all, of the subsystem clocks, in
particular it is not an ancestor to "venc_cke0":
static const struct mtk_gate venc_clks[] __initconst = {
GATE_VENC(CLK_VENC_CKE0, "venc_cke0", "mm_sel", 0),
GATE_VENC(CLK_VENC_CKE1, "venc_cke1", "venc_sel", 4),
GATE_VENC(CLK_VENC_CKE2, "venc_cke2", "venc_sel", 8),
GATE_VENC(CLK_VENC_CKE3, "venc_cke3", "venc_sel", 12),
};
If the VENC power domain is disabled, then accesses to the vencsys
registers just silently fail (i.e., reads probably
return all 0s). However, if the power domain is ON but venc_sel is
disabled, then accessing the clock-controller registers results in a
system hang (until the power domain is disabled).
At boot the VENC power domain is forced on by scpsys (like all other
power domains). Later both unused clocks and power domains get
disabled. If clocks are disabled first, and venc_sel is disabled
before venc_cke0, then when unused_clock tries to disable venc_cke0,
the system will hang when it reads the vencsys "is clock enabled" bit
since:
(a) VENC power domain is still enabled, and
(b) venc_sel is already disabled
In theory, we could add "clocks=<&topckgen CLK_TOP_VENC_SEL>;" to the
vencsys clock-controller node. On initialization, mtk_vencsys_init()
could then pass venc_sel to the generic MT8173 gate clock driver, and
it would then clk_enable(venc_sel)/_disable(venc_sel) around any
access to the clock-controller registers. James, however, thinks
this is a lot of extra overhead, and instead has proposed the fix in this patch,
where venc_sel is forced on whenever the VENC power domain is enabled.
So, this patch is a bit of a hack, but the mtk scpsys driver already
does something similar for the MM & MFG clocks - these clocks are
always enabled whenever certain power domains are enabled, and they
are only disabled when all such power domains are disabled. I'm not
100% why these clocks must always be kept on whenever these power
domains are enabled, but probably to solve a similar problem where
these clocks are needed to access some registers at a time when these
clocks would not otherwise be explicitly enabled.
Is the above clear?
>> But then we at least need a corresponding change to the binding
>> documentation.
Agreed.
> Yes, we will need a really good reason to change the bindings.
There is a race where the system can sometimes hang at boot with the
existing implementation & bindings.
This seems like a really good reason to change the bindings, if the
proposed solution is acceptable (it may be possible to fix the hang
without changing the bindings).
> Apart from that we would need to find a solution which works with the old
> (and wrong bindings) as well.
Why do we need to support the old bindings?
This patch fixes a problem in MT8173, for which the mainline kernel is
still under active bringup.
If the existing bindings are not used anywhere yet (*), it seems like
unnecessary overhead to enforce backwards compatibility at this stage.
(*) I don't actually know if this is true, perhaps only Mediatek can
answer this.
> Apart from that, please send the dtsi part as a seperate patch.
Agreed.
Thanks,
-Dan
>
> Thanks,
> Matthias
>
>
>> Regards,
>> Lucas
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support
On Mon, Sep 14, 2015 at 3:32 PM, Daniel Kurtz wrote:
>
> Hi Sascha,
>
> On Mon, Aug 31, 2015 at 3:34 PM, Sascha Hauer wrote:
> > This adds support for the Mediatek thermal controller found on MT8173
> > and likely other SoCs.
> > The controller is a bit special. It does not have its own ADC, instead
> > it controls the on-SoC AUXADC via AHB bus accesses. For this reason
> > we need the physical address of the AUXADC. Also it controls a mux
> > using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
> >
> > Signed-off-by: Sascha Hauer
> > Reviewed-by: Daniel Kurtz
>
> [snip...]
>
> > +static int mtk_read_temp(void *data, long *temp)
> > +{
> > + struct mtk_thermal_bank *bank = data;
> > +
> > + mtk_thermal_get_bank(bank);
> > +
> > + *temp = mtk_thermal_bank_temperature(bank);
> > +
> > + mtk_thermal_put_bank(bank);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
> > + .get_temp = mtk_read_temp,
>
> On v4.3-rc1, this now causes a compile warning, since the prototype
> for get_temp was changed to:
>
>int (*get_temp)(void *, int *);
>
> by:
> commit 17e8351a77397e8a83727eb17e3a3e9b8ab5257a
> thermal: consistently use int for temperatures
It is actually a little worse than a warning. This actually causes a
crash on boot.
Sascha, can you send out a rebased patch set on v4.3-rc1?
Thanks,
-Dan
>
>
> -Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: mt8173.dtsi: correct i2c node names
On Wed, Sep 16, 2015 at 9:35 AM, Yingjoe Chen wrote:
> Node name in device tree should describe general class of the
> device. Correct incorrect i2c node names.
>
> Signed-off-by: Yingjoe Chen
Reviewed-by: Daniel Kurtz
> ---
> This is based on v4.3-rc1.
> All the other i2c node names are correct.
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index d18ee42..7f360b7 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -365,7 +365,7 @@
> status = "disabled";
> };
>
> - i2c3: i2c3@1101 {
> + i2c3: i2c@1101 {
> compatible = "mediatek,mt8173-i2c";
> reg = <0 0x1101 0 0x70>,
> <0 0x11000280 0 0x80>;
> @@ -381,7 +381,7 @@
> status = "disabled";
> };
>
> - i2c4: i2c4@11011000 {
> + i2c4: i2c@11011000 {
> compatible = "mediatek,mt8173-i2c";
> reg = <0 0x11011000 0 0x70>,
> <0 0x11000300 0 0x80>;
> @@ -397,7 +397,7 @@
> status = "disabled";
> };
>
> - i2c6: i2c6@11013000 {
> + i2c6: i2c@11013000 {
> compatible = "mediatek,mt8173-i2c";
> reg = <0 0x11013000 0 0x70>,
> <0 0x1180 0 0x80>;
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] thermal: Add Mediatek thermal controller support
Hi Sascha,
On Mon, Aug 31, 2015 at 3:34 PM, Sascha Hauer wrote:
> This adds support for the Mediatek thermal controller found on MT8173
> and likely other SoCs.
> The controller is a bit special. It does not have its own ADC, instead
> it controls the on-SoC AUXADC via AHB bus accesses. For this reason
> we need the physical address of the AUXADC. Also it controls a mux
> using AHB bus accesses, so we need the APMIXEDSYS physical address aswell.
>
> Signed-off-by: Sascha Hauer
> Reviewed-by: Daniel Kurtz
[snip...]
> +static int mtk_read_temp(void *data, long *temp)
> +{
> + struct mtk_thermal_bank *bank = data;
> +
> + mtk_thermal_get_bank(bank);
> +
> + *temp = mtk_thermal_bank_temperature(bank);
> +
> + mtk_thermal_put_bank(bank);
> +
> + return 0;
> +}
> +
> +static const struct thermal_zone_of_device_ops mtk_thermal_ops = {
> + .get_temp = mtk_read_temp,
On v4.3-rc1, this now causes a compile warning, since the prototype
for get_temp was changed to:
int (*get_temp)(void *, int *);
by:
commit 17e8351a77397e8a83727eb17e3a3e9b8ab5257a
thermal: consistently use int for temperatures
-Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v5] clk: mediatek: Export CPU mux clocks for CPU frequency control
On Mon, Aug 17, 2015 at 4:56 PM, Pi-Cheng Chen wrote:
> From: "pi-cheng.chen"
>
> This patch adds CPU mux clocks which are used by Mediatek cpufreq driver
> for intermediate clock source switching.
>
> Signed-off-by: Pi-Cheng Chen
> Reviewed-by: Daniel Kurtz
> ---
> Changes in v5:
> - Replace __initdata with __initconst to fix compiling error
>
> Changes in v4:
> - Fix some minor issues for v3
> - Rebase to the patch that adds 13mhz clock for MT8173[1]
>
> Changes in v3:
> - Rebase to 4.2-rc1
> - Fix some issues of v2
>
> Changes in v2:
> - Remove use of .determine_rate callback
>
> [1] http://patchwork.kernerl.xyz/patch/6777041/
> ---
> drivers/clk/mediatek/Makefile | 2 +-
> drivers/clk/mediatek/clk-cpumux.c | 127
> +
> drivers/clk/mediatek/clk-cpumux.h | 22 ++
> drivers/clk/mediatek/clk-mt8173.c | 23 ++
> include/dt-bindings/clock/mt8173-clk.h | 4 +-
> 5 files changed, 176 insertions(+), 2 deletions(-)
> create mode 100644 drivers/clk/mediatek/clk-cpumux.c
> create mode 100644 drivers/clk/mediatek/clk-cpumux.h
>
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index 8e4b2a4..299917a 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -1,4 +1,4 @@
> -obj-y += clk-mtk.o clk-pll.o clk-gate.o
> +obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-cpumux.o
> obj-$(CONFIG_RESET_CONTROLLER) += reset.o
> obj-y += clk-mt8135.o
> obj-y += clk-mt8173.o
> diff --git a/drivers/clk/mediatek/clk-cpumux.c
> b/drivers/clk/mediatek/clk-cpumux.c
> new file mode 100644
> index 000..fb04fe1
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-cpumux.c
> @@ -0,0 +1,127 @@
> +/*
> + * Copyright (c) 2015 Linaro Ltd.
> + * Author: Pi-Cheng Chen
> + *
> + * 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
> +#include
> +#include
> +
> +#include "clk-mtk.h"
> +#include "clk-cpumux.h"
> +
> +struct mtk_clk_cpumux {
> + struct clk_hw hw;
> + struct regmap *regmap;
> + u32 reg;
> + u32 mask;
> + u8 shift;
> +};
> +
> +static inline struct mtk_clk_cpumux *to_clk_mux(struct clk_hw *_hw)
> +{
> + return container_of(_hw, struct mtk_clk_cpumux, hw);
> +}
> +
> +static u8 clk_cpumux_get_parent(struct clk_hw *hw)
> +{
> + struct mtk_clk_cpumux *mux = to_clk_mux(hw);
> + int num_parents = __clk_get_num_parents(hw->clk);
This will no longer compile against v4.3-rc1 due to:
commit fc4a05d4b0eb1a0110ef11201bf563cd4b53fbce
clk: Remove unused provider APIs
Use the following instead:
unsigned int num_parents = clk_hw_get_num_parents(hw);
> + unsigned int val;
> +
> + regmap_read(mux->regmap, mux->reg, &val);
> +
> + val >>= mux->shift;
> + val &= mux->mask;
> +
> + if (val >= num_parents)
> + return -EINVAL;
> +
> + return val;
> +}
> +
> +static int clk_cpumux_set_parent(struct clk_hw *hw, u8 index)
> +{
> + struct mtk_clk_cpumux *mux = to_clk_mux(hw);
> + u32 mask, val;
> +
> + val = index << mux->shift;
> + mask = mux->mask << mux->shift;
> +
> + return regmap_update_bits(mux->regmap, mux->reg, mask, val);
> +}
> +
> +static const struct clk_ops clk_cpumux_ops = {
> + .get_parent = clk_cpumux_get_parent,
> + .set_parent = clk_cpumux_set_parent,
> +};
> +
> +static struct clk __init *mtk_clk_register_cpumux(const struct mtk_composite
> *mux,
> + struct regmap *regmap)
> +{
> + struct mtk_clk_cpumux *cpumux;
> + struct clk *clk;
> + struct clk_init_data init;
> +
> + cpumux = kzalloc(sizeof(*cpumux), GFP_KERNEL);
> + if (!cpumux)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = mux->name;
> + init.ops = &clk_cpumux_ops;
> + init.parent_names = mux->parent_names;
> + init.num_parents = mux->num_parents;
> + init.flags = mux->flags;
> +
> + cpumux->reg = mux->mux
Re: [PATCH 2/2] arm64: dts: mt8173: Add thermal zone node for mt8173.
On Mon, Sep 7, 2015 at 12:00 PM, Daniel Kurtz wrote: > Hi Dawei, > > On Fri, Sep 4, 2015 at 5:01 PM, Dawei Chien wrote: >> Add thermal zone node to mt8173.dtsi. >> >> Signed-off-by: Dawei Chien >> --- >> This patch is base on following patches >> https://patchwork.kernel.org/patch/6969581/ >> https://patchwork.kernel.org/patch/6969571/ >> https://patchwork.kernel.org/patch/6969381/ >> --- >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 44 >> ++ >> 1 file changed, 44 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> index 208051a..6493bfd 100644 >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> @@ -17,6 +17,7 @@ >> #include >> #include >> #include "mt8173-pinfunc.h" >> +#include Also, as a nit, (#include ) should be above '#include "mt8173-pinfunc.h"' -djk -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm64: dts: mt8173: Add thermal zone node for mt8173.
Hi Dawei,
On Fri, Sep 4, 2015 at 5:01 PM, Dawei Chien wrote:
> Add thermal zone node to mt8173.dtsi.
>
> Signed-off-by: Dawei Chien
> ---
> This patch is base on following patches
> https://patchwork.kernel.org/patch/6969581/
> https://patchwork.kernel.org/patch/6969571/
> https://patchwork.kernel.org/patch/6969381/
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 44
> ++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 208051a..6493bfd 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -17,6 +17,7 @@
> #include
> #include
> #include "mt8173-pinfunc.h"
> +#include
This include is not necessary, however...
>
> / {
> compatible = "mediatek,mt8173";
> @@ -116,6 +117,49 @@
> clock-output-names = "clk32k";
> };
>
> + thermal-zones {
> + cpu_thermal: cpu_thermal {
> + polling-delay-passive = <1000>; /* milliseconds */
> + polling-delay = <1000>; /* milliseconds */
> +
> + thermal-sensors = <&thermal MT8173_THERMAL_ZONE_CA57>;
this fails to compile, because MT8173_THERMAL_ZONE_CA57 is defined in:
include/dt-bindings/thermal/mt8173.h
-Dan
> + sustainable-power = <1500>;
> +
> + 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";
> + };
> + };
> +
> + cooling-maps {
> + map@0 {
> + trip = <&target>;
> + cooling-device = <&cpu0 0 0>;
> + contribution = <1024>;
> + };
> + map@1 {
> + trip = <&target>;
> + cooling-device = <&cpu2 0 0>;
> + contribution = <2048>;
> + };
> + };
> + };
> + };
> +
> timer {
> compatible = "arm,armv8-timer";
> interrupt-parent = <&gic>;
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 0/3 v6] Add Mediatek MT8173 cpufreq driver
Matthias, On Fri, Aug 28, 2015 at 10:06 PM, Rafael J. Wysocki wrote: > On Wednesday, August 26, 2015 02:53:39 PM Pi-Cheng Chen wrote: >> On Wed, Aug 26, 2015 at 10:16 AM, Viresh Kumar >> wrote: >> > On 26-08-15, 09:25, Pi-Cheng Chen wrote: >> >> The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which >> >> introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it >> >> will >> >> cause some conflicts if it goes through your tree. I am not sure how this >> >> should be handled, but should it be merged through Mediatek SoC maintainer >> >> tree? >> > >> > Just get that applied to MTK tree, it doesn't have any dependency on >> > rest of the patches for build/boot. The only thing is that cpufreq >> > wouldn't work and it will work as soon as Rafael's and MTK's trees are >> > merged by Linus. >> >> Thanks for your explanation. >> >> @Rafael, Would you please apply [1,2] to your tree? > > Applied, thanks! Can you please apply [3] from this set to your dts tree? > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] arm64: dts: Add spi bus dts
Matthias,
On Mon, Aug 17, 2015 at 12:32 PM, Daniel Kurtz wrote:
> On Mon, Aug 17, 2015 at 11:29 AM, Leilk Liu wrote:
>>
>> This patch adds MT8173 spi bus controllers into device tree.
>>
>> Signed-off-by: Leilk Liu
>
> Reviewed-by: Daniel Kurtz
The other SPI patches have already been picked up in broonie's spi tree.
Can you pick this one into your mediatek tree?
Thanks.
-Dan
>
>> ---
>> Change in this patch:
>> pinctl and pad-select fields are board specific, so move to
>> mt8173-evb.dtsi, and status = "okay".
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi| 12
>> 2 files changed, 30 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> index 4be66ca..811cb76 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
>> @@ -387,6 +387,24 @@
>> };
>> };
>>
>> +&pio {
>> + spi_pins_a: spi0 {
>> + pins_spi {
>> + pinmux = ,
>> + ,
>> + ,
>> + ;
>> + };
>> + };
>> +};
>> +
>> +&spi {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&spi_pins_a>;
>> + mediatek,pad-select = <0>;
>> + status = "okay";
>> +};
>> +
>> &uart0 {
>> status = "okay";
>> };
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index d18ee42..3dfb6ed 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -365,6 +365,18 @@
>> status = "disabled";
>> };
>>
>> + spi: spi@1100a000 {
>> + compatible = "mediatek,mt8173-spi";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0 0x1100a000 0 0x1000>;
>> + interrupts = ;
>> + clocks = <&topckgen CLK_TOP_SPI_SEL>,
>> +<&topckgen CLK_TOP_SYSPLL3_D2>;
>> + clock-names = "spi-clk", "parent-clk";
>> + status = "disabled";
>> + };
>> +
>> i2c3: i2c3@1101 {
>> compatible = "mediatek,mt8173-i2c";
>> reg = <0 0x1101 0 0x70>,
>> --
>> 1.8.1.1.dirty
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for Mediatek thermal controller
On Thu, Aug 27, 2015 at 7:49 PM, Punit Agrawal wrote:
> [ + device tree folks ]
>
> Hi Sascha,
>
> When introducing a new binding, it is a good idea to get reviews from
> the device tree maintainers. I've added a few folks here. Please keep
> them in the loop for future postings.
>
> Sascha Hauer writes:
>
>> Signed-off-by: Sascha Hauer
>> Reviewed-by: Daniel Kurtz
>
> Please add a commit log.
>
>> ---
>> .../bindings/thermal/mediatek-thermal.txt | 38
>> ++
>> include/dt-bindings/thermal/mt8173.h | 13
>> 2 files changed, 51 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>> create mode 100644 include/dt-bindings/thermal/mt8173.h
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>> b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>> new file mode 100644
>> index 000..1697375
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
>> @@ -0,0 +1,38 @@
>> +* Mediatek Thermal
>> +
>> +This describes the device tree binding for the Mediatek thermal controller
>> +which measures the on-SoC temperatures. This device does not have its own
>> ADC,
>> +instead it directly controls the AUXADC via AHB bus accesses. For this
>> reason
>> +this device needs phandles to the AUXADC. Also it controls a mux in the
>> +apmixedsys register space via AHB bus accesses, so a phandle to the
>> APMIXEDSYS
>> +is also needed.
>> +
>> +Required properties:
>> +- compatible: "mediatek,mt8173-thermal"
>> +- reg: Address range of the thermal controller
>> +- interrupts: IRQ for the thermal controller
>> +- clocks, clock-names: Clocks needed for the thermal controller. required
>> + clocks are:
>> +"therm": Main clock needed for register access
>> +"auxadc": The AUXADC clock
>> +- resets: Reference to the reset controller controlling the thermal
>> controller.
>> +- mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses
>> +- mediatek,apmixedsys: A phandle to the APMIXEDSYS controller.
>> +- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
>> See
>> + include/dt-bindings/thermal/mt8173.h for valid sensor
>> + numbers.
>> +
>> +Example:
>> +
>> + thermal: thermal@1100b000 {
>> + #thermal-sensor-cells = <1>;
>> + compatible = "mediatek,mt8173-thermal";
>> + reg = <0 0x1100b000 0 0x1000>;
>> + interrupts = <0 70 IRQ_TYPE_LEVEL_LOW>;
>> + clocks = <&pericfg CLK_PERI_THERM>, <&pericfg CLK_PERI_AUXADC>;
>> + clock-names = "therm", "auxadc";
>> + resets = <&pericfg MT8173_PERI_THERM_SW_RST>;
>> + reset-names = "therm";
>> + mediatek,auxadc = <&auxadc>;
>> + mediatek,apmixedsys = <&apmixedsys>;
>> + };
>> diff --git a/include/dt-bindings/thermal/mt8173.h
>> b/include/dt-bindings/thermal/mt8173.h
>> new file mode 100644
>> index 000..692e74c
>> --- /dev/null
>> +++ b/include/dt-bindings/thermal/mt8173.h
>> @@ -0,0 +1,13 @@
>> +/*
>> + * This header provides constants for mediatek,mt8173-thermal
>> + */
>> +
>> +#ifndef _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H
>> +#define _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H
>> +
>> +#define MT8173_THERMAL_ZONE_CA53 0
>> +#define MT8173_THERMAL_ZONE_CA57 1
>> +#define MT8173_THERMAL_ZONE_GPU 2
>> +#define MT8173_THERMAL_ZONE_CORE 3
>> +
>> +#endif /* _DT_BINDINGS_THERMAL_MEDIATEK_MT8173_H */
>
> The constants in this include are not used in the patchset. Please drop
> this hunk and introduce it when you use it.
These constants are part of the devicetree ABI, and I believe they
should be included with the binding.
To make this more concrete, I think these constants could be used as
array indices when initializing the corresponding banks of "bank_data"
in patch 2 (like you do when initializing scp_domain_data in the
scpsys driver).
-Dan
>
> Thanks,
> Punit
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] arm64: dts: Add spi bus dts
On Mon, Aug 17, 2015 at 11:29 AM, Leilk Liu wrote:
>
> This patch adds MT8173 spi bus controllers into device tree.
>
> Signed-off-by: Leilk Liu
Reviewed-by: Daniel Kurtz
> ---
> Change in this patch:
> pinctl and pad-select fields are board specific, so move to
> mt8173-evb.dtsi, and status = "okay".
> ---
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18 ++
> arch/arm64/boot/dts/mediatek/mt8173.dtsi| 12
> 2 files changed, 30 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index 4be66ca..811cb76 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -387,6 +387,24 @@
> };
> };
>
> +&pio {
> + spi_pins_a: spi0 {
> + pins_spi {
> + pinmux = ,
> + ,
> + ,
> + ;
> + };
> + };
> +};
> +
> +&spi {
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi_pins_a>;
> + mediatek,pad-select = <0>;
> + status = "okay";
> +};
> +
> &uart0 {
> status = "okay";
> };
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index d18ee42..3dfb6ed 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -365,6 +365,18 @@
> status = "disabled";
> };
>
> + spi: spi@1100a000 {
> + compatible = "mediatek,mt8173-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0 0x1100a000 0 0x1000>;
> + interrupts = ;
> + clocks = <&topckgen CLK_TOP_SPI_SEL>,
> +<&topckgen CLK_TOP_SYSPLL3_D2>;
> + clock-names = "spi-clk", "parent-clk";
> + status = "disabled";
> + };
> +
> i2c3: i2c3@1101 {
> compatible = "mediatek,mt8173-i2c";
> reg = <0 0x1101 0 0x70>,
> --
> 1.8.1.1.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/9] Fixes and new clocks support for Mediatek MT8173
On Tue, Aug 11, 2015 at 12:43 PM, Daniel Kurtz wrote: > Hi James, > > On Mon, Aug 10, 2015 at 5:50 PM, James Liao wrote: >> This patchset is based on 4.2-rc2 and [1], and contains minor fixes and >> subsystem clocks support for Mediatek MT8173. >> >> The previous reviews can be found in [2]. >> >> changes since v6: >> - Use DUMMY_RATE (0) instead of typical rate for clocks that we don't care >> and not controlled in CCF. > > For the whole series: > Reviewed-by: Daniel Kurtz Hi Sascha, Are you happy with these patches now? Thanks, -Dan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] add GPT timer support for mt8173
On Wed, Aug 12, 2015 at 8:32 PM, Daniel Lezcano wrote: > On 08/11/2015 05:54 PM, Daniel Kurtz wrote: >> >> On Mon, Jul 13, 2015 at 5:32 PM, Yingjoe Chen >> wrote: >>> >>> This series add GPT timer support for mt8173. This is based on v4.2-rc1 >>> and Matthias' next branch (for dts parts). >>> >>> The first 2 patches comes from 'Add SMP bringup support for mt65xx socs' >>> series [1]. I decide to move these 2 patches to this series, since it >>> is more relevent here. They are changed based on Matthias' and Daniel's >>> comments. >>> >>> [1] >>> http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000714.html >>> >>> Daniel Kurtz (1): >>>arm64: dts: mt8173: add timer node >>> >>> Yingjoe Chen (4): >>>clocksource: mediatek: do not enable GPT_CLK_EVT when setup >>>clocksource: mediatek: Use GPT as sched clock source >>>arm64: mediatek: enable MTK_TIMER >>>clk: mediatek: add 13mhz clock for MT8173 >> >> >> Was this mediatek clocksource patch set get forgotten again? > > > Yep. Sounds like it felt at the wrong moment. > >> All 5 patches have have been reviewed, and I think the ones that need >> it have been Ack'ed by Matthias and/or Stephen. >> What is the plan for merging them? > > > So if I am not wrong we have two patches I can take in my tree as a couple > of fixes (1 and 2), right ? Yes. Patches 3 & 5 are for Matthias, and patch 4 is Ack'ed by Stephen Boyd, so I assume Matthias can pick that one up too. Matthias, is that correct? Or does Patch 4 need to go in via a clock maintainer's tree? -Dan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] add GPT timer support for mt8173
On Mon, Jul 13, 2015 at 5:32 PM, Yingjoe Chen wrote: > This series add GPT timer support for mt8173. This is based on v4.2-rc1 > and Matthias' next branch (for dts parts). > > The first 2 patches comes from 'Add SMP bringup support for mt65xx socs' > series [1]. I decide to move these 2 patches to this series, since it > is more relevent here. They are changed based on Matthias' and Daniel's > comments. > > [1] http://lists.infradead.org/pipermail/linux-mediatek/2015-May/000714.html > > Daniel Kurtz (1): > arm64: dts: mt8173: add timer node > > Yingjoe Chen (4): > clocksource: mediatek: do not enable GPT_CLK_EVT when setup > clocksource: mediatek: Use GPT as sched clock source > arm64: mediatek: enable MTK_TIMER > clk: mediatek: add 13mhz clock for MT8173 Was this mediatek clocksource patch set get forgotten again? All 5 patches have have been reviewed, and I think the ones that need it have been Ack'ed by Matthias and/or Stephen. What is the plan for merging them? Thanks, -Dan > > arch/arm64/Kconfig | 1 + > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 9 + > drivers/clk/mediatek/clk-mt8173.c| 5 + > drivers/clocksource/mtk_timer.c | 26 -- > include/dt-bindings/clock/mt8173-clk.h | 3 ++- > 5 files changed, 37 insertions(+), 7 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] arm64: dts: Add spi bus dts
On Fri, Aug 7, 2015 at 3:19 PM, Leilk Liu wrote:
> This patch adds MT8173 spi bus controllers into device tree.
>
> Signed-off-by: Leilk Liu
> ---
> Change in this patch:
> 1. "pad-select" is a vendor property, so change it to "mediatek,pad-select".
> 2. modify the property of clocks and clock-names.
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index d18ee42..066bd6a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -220,6 +220,15 @@
> bias-disable;
> };
> };
> +
> + spi_pins_a: spi0 {
> + pins_spi {
> + pinmux =
> ,
> +
> ,
> +
> ,
> +
> ;
> + };
> + };
> };
>
> scpsys: scpsys@10006000 {
> @@ -365,6 +374,20 @@
> status = "disabled";
> };
>
> + spi: spi@1100a000 {
> + compatible = "mediatek,mt8173-spi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0 0x1100a000 0 0x1000>;
> + interrupts = ;
> + clocks = <&topckgen CLK_TOP_SPI_SEL>, <&topckgen
> CLK_TOP_SYSPLL3_D2>;
> + clock-names = "spi-clk", "parent-clk";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi_pins_a>;
> + mediatek,pad-select = <0>;
The pinctl and pad-select fields are board specific.
Please move to mt8173-evb.dtsi, along with status = "okay";
> + status = "disabled";
> + };
> +
> i2c3: i2c3@1101 {
> compatible = "mediatek,mt8173-i2c";
> reg = <0 0x1101 0 0x70>,
> --
> 1.8.1.1.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/9] Fixes and new clocks support for Mediatek MT8173
Hi James, On Mon, Aug 10, 2015 at 5:50 PM, James Liao wrote: > This patchset is based on 4.2-rc2 and [1], and contains minor fixes and > subsystem clocks support for Mediatek MT8173. > > The previous reviews can be found in [2]. > > changes since v6: > - Use DUMMY_RATE (0) instead of typical rate for clocks that we don't care > and not controlled in CCF. For the whole series: Reviewed-by: Daniel Kurtz > > changes since v5: > - Rebase to 4.2-rc2. > - Patch "Fix enabling of critical clocks" had been included in 4.2-rc2, > so it need not be included in this patchset. > > changes since v4: > - Add a separated patch to remove unused dpi_ck. > - Add separated patches to fix clk/mediatek in release 4.2-rc1. > - Add __init* for initialization data and functions. > - Rename dummy_clk with oscillator in DT. > - Remove mtk_clk_register_apmixed_ex(), call mtk_clk_register_ref2usb_tx() > directly to register USB clock. > > changes since v3: > - Remove clk_null dependency from root clocks. > - Use fixed-rate clocks with typical rate to replace clk_null. > - Separate ref2usb_tx implementation to clk-apmixed.c > - Use clock-controller as the name of clock providers. > > changes since v2: > - Rebase to 4.2-rc1. > - Add device tree nodes for subsystem clocks. > - Fine tune comments of patches. > - Add __init, __initconst and const to init data and functions. > - Removed unused code from init functions of subsystem clocks. > > changes since v1: > - Add CA7PLL and CA15PLL as critical clocks. > - Use the same register descriptor for imgsys, vensys and vencltsys. > - Generalize apmixedsys special clocks registration. > > [1] https://patchwork.kernel.org/patch/6446341/ > [2] https://lkml.org/lkml/2015/8/4/111 > > James Liao (9): > clk: mediatek: Removed unused dpi_ck clock from MT8173 > clk: mediatek: Remove unused code from MT8173. > clk: mediatek: Add __initdata and __init for data and functions > clk: mediatek: Add fixed clocks support for Mediatek SoC. > clk: mediatek: Fix rate and dependency of MT8173 clocks > dt-bindings: ARM: Mediatek: Document devicetree bindings for clock > controllers > clk: mediatek: Add subsystem clocks of MT8173 > clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS > arm64: dts: mt8173: Add subsystem clock controller device nodes > > .../bindings/arm/mediatek/mediatek,imgsys.txt | 22 ++ > .../bindings/arm/mediatek/mediatek,mmsys.txt | 22 ++ > .../bindings/arm/mediatek/mediatek,vdecsys.txt | 22 ++ > .../bindings/arm/mediatek/mediatek,vencltsys.txt | 22 ++ > .../bindings/arm/mediatek/mediatek,vencsys.txt | 22 ++ > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 37 +++ > drivers/clk/mediatek/Makefile | 2 +- > drivers/clk/mediatek/clk-apmixed.c | 107 +++ > drivers/clk/mediatek/clk-gate.c| 2 +- > drivers/clk/mediatek/clk-mt8173.c | 342 > - > drivers/clk/mediatek/clk-mtk.c | 36 ++- > drivers/clk/mediatek/clk-mtk.h | 24 +- > drivers/clk/mediatek/clk-pll.c | 7 +- > include/dt-bindings/clock/mt8173-clk.h | 101 +- > 14 files changed, 735 insertions(+), 33 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt > create mode 100644 drivers/clk/mediatek/clk-apmixed.c > > -- > 1.8.1.1.dirty > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/3] Add MediaTek display PWM driver
Thierry, I think these patches are ready. Will you please consider picking up in your pwm tree? -Dan On Mon, Aug 3, 2015 at 2:21 PM, YH Huang wrote: > On Fri, 2015-07-24 at 17:10 +0800, YH Huang wrote: >> On Fri, 2015-07-24 at 10:42 +0200, Matthias Brugger wrote: >> > On Monday, July 20, 2015 04:17:14 PM YH Huang wrote: >> > > This patch series add the use of display PWM driver, documentation >> > > and device tree for Mediatek SoCs. The driver is used to support >> > > the backlight of the panel. This is based on v4.2-rc1. >> > > >> > > The clock definitions (CLK_MM_DISP_PWM*) are added by James Liao's patch: >> > > clk: mediatek: Add subsystem clocks of MT8173 >> > > >> > > Change in v6: >> > > 1. Enable clocks in the pwm_enable function >> > > 2. Remove suspend/resume code since pwm-backlight driver has done the >> > > same >> > > things 3. Revise some code to make it easier to read >> > > >> > >> > Can you please provide the whole change log for all versions the next time. >> > It's easier this way to understand the evolution of the series. >> >> Change in v6: >> 1. Enable clocks in the pwm_enable function. >> 2. Remove suspend/resume code since pwm-backlight driver has done the >> same things. >> 3. Revise some code to make it easier to read. >> >> Change in v5: >> 1. Configure PWM output via pinctrl. >> 2. Fix the parameter name in dtsi. >> >> Change in v4: >> 1. Codebase is on v4.2-rc1. >> 2. Add the PWM node in dtsi. >> 3. Change the dependency in Kconfig. >> 4. Rewrite some code for readability. >> >> Change in v3: >> 1. Add suspend/resume function. >> 2. Fix the formula for high_width calculation. >> 3. Rewrite some code to make it easier to read. >> 4. Add more information in the commit message. >> >> Change in v2: >> 1. Rewrite descriptions for driver in kconfig to make it much clear. >> 2. Rename the driver from "pwm-mediatek-disp" to "pwm-mtk-disp". >> 3. Disable clocks in the error path. >> 4. Change the shift values in decimal instead of hex. >> 5. Rename and add some variables or function name for consistency and >> readability. >> 6. Drop unnecessary parentheses, spaces, variables and add newlines to >> make the code easiler to read. >> >> Thanks for your suggestion. > > Hi Thierry, > > Do you have any suggestions? > Maybe we could apply the patch? > > Regards, > YH Huang > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 7/9] clk: mediatek: Add subsystem clocks of MT8173
On Fri, Aug 7, 2015 at 4:05 PM, Daniel Kurtz wrote:
> On Fri, Aug 7, 2015 at 10:20 AM, James Liao wrote:
>> Hi Sascha,
>>
>> On Thu, 2015-08-06 at 12:20 +0200, Sascha Hauer wrote:
>>> On Thu, Aug 06, 2015 at 05:13:21PM +0800, Daniel Kurtz wrote:
>>> > On Thu, Aug 6, 2015 at 5:00 PM, James Liao
>>> > wrote:
>>> > > Hi Sascha,
>>> > >
>>> > > On Thu, 2015-08-06 at 10:53 +0200, Sascha Hauer wrote:
>>> > >> On Thu, Aug 06, 2015 at 04:23:51PM +0800, James Liao wrote:
>>> > >> > On Wed, 2015-08-05 at 08:46 +0200, Sascha Hauer wrote:
>>> > >> > > On Tue, Aug 04, 2015 at 04:16:56PM +0800, James Liao wrote:
>>> > >> > > > static const struct mtk_fixed_clk fixed_clks[] __initconst = {
>>> > >> > > > FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m",
>>> > >> > > > 400 * MHZ),
>>> > >> > > > FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m",
>>> > >> > > > "clk26m", 125 * MHZ),
>>> > >> > > > + FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 *
>>> > >> > > > MHZ),
>>> > >> > > > + FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 *
>>> > >> > > > MHZ),
>>> > >> > > > + FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5
>>> > >> > > > * MHZ),
>>> > >> > > > + FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll",
>>> > >> > > > 51.975 * MHZ),
>>> > >> > >
>>> > >> > > I would expect 51975 * KHZ here to avoid fractional numbers.
>>> > >> > > Probably
>>> > >> > > gcc calculates that during compile time so this will work as
>>> > >> > > expected,
>>> > >> > > still I'm not sure this is good style to use fractional numbers
>>> > >> > > here.
>>> > >> >
>>> > >> > As I know all constants will be calculated in compile time, so there
>>> > >> > should be no difference between 51.975 * MHZ and 51975 * KHz.
>>> > >> >
>>> > >> > > Anyway, on my system lvdspll is running at 150MHz. Are you sure
>>> > >> > > there is
>>> > >> > > a clock derived from this running at 148.5MHz? Is it really
>>> > >> > > correct to
>>> > >> > > use a fixed clock here or should it rather be lvdspll directly?
>>> > >> >
>>> > >> > Here is the clock hierarchy between lvdspll and lvds_pxl:
>>> > >> >
>>> > >> > AD_VPLL_DPIX_CK lvds_pxl
>>> > >> > -
>>> > >> >||->||-->|
>>> > >> >|| | cksys | |
>>> > >> > LVDSPLL -->| LVDSTX | | buffer | |
>>> > >> > MMSYS
>>> > >> >|| AD_LVDSTX_CLKDIG_CTS | test | lvds_cts |
>>> > >> >||->||-->|
>>> > >> >
>>> > >> > -
>>> > >> >
>>> > >> > Some clocks and blocks are not modeled into CCF. But we prefer to
>>> > >> > enable
>>> > >> > lvdspll before enabling lvds_pxl. So I modeled lvds_pxl (and
>>> > >> > lvds_cts)
>>> > >> > as a fixed-rate clock with a source from lvdspll.
>>> > >> >
>>> > >> > The frequency of these fixed-rate clocks (such as 148.5 MHz) are
>>> > >> > typical
>>> > >> > rate. In fact, we don't care about the actual rate of these clocks.
>>> > >> > We
>>> > >> > just care about the enable / disable sequence of them.
>>> > >>
>>> > >> Please either use the real rate or 0 (along with a explaining why).
>>> > >> Us
Re: [PATCH v6 7/9] clk: mediatek: Add subsystem clocks of MT8173
On Fri, Aug 7, 2015 at 10:20 AM, James Liao wrote:
> Hi Sascha,
>
> On Thu, 2015-08-06 at 12:20 +0200, Sascha Hauer wrote:
>> On Thu, Aug 06, 2015 at 05:13:21PM +0800, Daniel Kurtz wrote:
>> > On Thu, Aug 6, 2015 at 5:00 PM, James Liao
>> > wrote:
>> > > Hi Sascha,
>> > >
>> > > On Thu, 2015-08-06 at 10:53 +0200, Sascha Hauer wrote:
>> > >> On Thu, Aug 06, 2015 at 04:23:51PM +0800, James Liao wrote:
>> > >> > On Wed, 2015-08-05 at 08:46 +0200, Sascha Hauer wrote:
>> > >> > > On Tue, Aug 04, 2015 at 04:16:56PM +0800, James Liao wrote:
>> > >> > > > static const struct mtk_fixed_clk fixed_clks[] __initconst = {
>> > >> > > > FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m",
>> > >> > > > 400 * MHZ),
>> > >> > > > FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m",
>> > >> > > > "clk26m", 125 * MHZ),
>> > >> > > > + FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 *
>> > >> > > > MHZ),
>> > >> > > > + FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 *
>> > >> > > > MHZ),
>> > >> > > > + FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5
>> > >> > > > * MHZ),
>> > >> > > > + FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll", 51.975
>> > >> > > > * MHZ),
>> > >> > >
>> > >> > > I would expect 51975 * KHZ here to avoid fractional numbers.
>> > >> > > Probably
>> > >> > > gcc calculates that during compile time so this will work as
>> > >> > > expected,
>> > >> > > still I'm not sure this is good style to use fractional numbers
>> > >> > > here.
>> > >> >
>> > >> > As I know all constants will be calculated in compile time, so there
>> > >> > should be no difference between 51.975 * MHZ and 51975 * KHz.
>> > >> >
>> > >> > > Anyway, on my system lvdspll is running at 150MHz. Are you sure
>> > >> > > there is
>> > >> > > a clock derived from this running at 148.5MHz? Is it really correct
>> > >> > > to
>> > >> > > use a fixed clock here or should it rather be lvdspll directly?
>> > >> >
>> > >> > Here is the clock hierarchy between lvdspll and lvds_pxl:
>> > >> >
>> > >> > AD_VPLL_DPIX_CK lvds_pxl -
>> > >> >||->||-->|
>> > >> >|| | cksys | |
>> > >> > LVDSPLL -->| LVDSTX | | buffer | |
>> > >> > MMSYS
>> > >> >|| AD_LVDSTX_CLKDIG_CTS | test | lvds_cts |
>> > >> >||->||-->|
>> > >> > -
>> > >> >
>> > >> > Some clocks and blocks are not modeled into CCF. But we prefer to
>> > >> > enable
>> > >> > lvdspll before enabling lvds_pxl. So I modeled lvds_pxl (and lvds_cts)
>> > >> > as a fixed-rate clock with a source from lvdspll.
>> > >> >
>> > >> > The frequency of these fixed-rate clocks (such as 148.5 MHz) are
>> > >> > typical
>> > >> > rate. In fact, we don't care about the actual rate of these clocks. We
>> > >> > just care about the enable / disable sequence of them.
>> > >>
>> > >> Please either use the real rate or 0 (along with a explaining why).
>> > >> Using
>> > >> a frequency with four to five significant digits makes me think that the
>> > >> actual rate is very important.
>> > >
>> > > Oops, your suggestion is much different from Daniel's.
>> > >
>> > > Daniel, could you help to comment about how we model these clocks?
>> >
>> > First of all, for clocks where the rate doesn't matter, it does
Re: [PATCH v6 7/9] clk: mediatek: Add subsystem clocks of MT8173
On Thu, Aug 6, 2015 at 5:00 PM, James Liao wrote:
> Hi Sascha,
>
> On Thu, 2015-08-06 at 10:53 +0200, Sascha Hauer wrote:
>> On Thu, Aug 06, 2015 at 04:23:51PM +0800, James Liao wrote:
>> > On Wed, 2015-08-05 at 08:46 +0200, Sascha Hauer wrote:
>> > > On Tue, Aug 04, 2015 at 04:16:56PM +0800, James Liao wrote:
>> > > > static const struct mtk_fixed_clk fixed_clks[] __initconst = {
>> > > > FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 *
>> > > > MHZ),
>> > > > FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m",
>> > > > "clk26m", 125 * MHZ),
>> > > > + FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 * MHZ),
>> > > > + FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 * MHZ),
>> > > > + FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5 *
>> > > > MHZ),
>> > > > + FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll", 51.975 *
>> > > > MHZ),
>> > >
>> > > I would expect 51975 * KHZ here to avoid fractional numbers. Probably
>> > > gcc calculates that during compile time so this will work as expected,
>> > > still I'm not sure this is good style to use fractional numbers here.
>> >
>> > As I know all constants will be calculated in compile time, so there
>> > should be no difference between 51.975 * MHZ and 51975 * KHz.
>> >
>> > > Anyway, on my system lvdspll is running at 150MHz. Are you sure there is
>> > > a clock derived from this running at 148.5MHz? Is it really correct to
>> > > use a fixed clock here or should it rather be lvdspll directly?
>> >
>> > Here is the clock hierarchy between lvdspll and lvds_pxl:
>> >
>> > AD_VPLL_DPIX_CK lvds_pxl -
>> >||->||-->|
>> >|| | cksys | |
>> > LVDSPLL -->| LVDSTX | | buffer | | MMSYS
>> >|| AD_LVDSTX_CLKDIG_CTS | test | lvds_cts |
>> >||->||-->|
>> > -
>> >
>> > Some clocks and blocks are not modeled into CCF. But we prefer to enable
>> > lvdspll before enabling lvds_pxl. So I modeled lvds_pxl (and lvds_cts)
>> > as a fixed-rate clock with a source from lvdspll.
>> >
>> > The frequency of these fixed-rate clocks (such as 148.5 MHz) are typical
>> > rate. In fact, we don't care about the actual rate of these clocks. We
>> > just care about the enable / disable sequence of them.
>>
>> Please either use the real rate or 0 (along with a explaining why). Using
>> a frequency with four to five significant digits makes me think that the
>> actual rate is very important.
>
> Oops, your suggestion is much different from Daniel's.
>
> Daniel, could you help to comment about how we model these clocks?
First of all, for clocks where the rate doesn't matter, it doesn't
matters to what rate we set the clock.
As for the color of our shed, "the designer says these are the typical
rates" sounds good enough to me for a "real rate", so I prefer using
the rates in James' patch.
If not sure what Sascha's concern is, but if he insists on 0, I'm fine
with that too.
-Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 7/9] clk: mediatek: Add subsystem clocks of MT8173
On Wed, Aug 5, 2015 at 3:50 PM, Sascha Hauer wrote:
> On Wed, Aug 05, 2015 at 03:41:49PM +0800, Daniel Kurtz wrote:
>> On Wed, Aug 5, 2015 at 3:36 PM, Sascha Hauer wrote:
>> > On Wed, Aug 05, 2015 at 03:26:29PM +0800, Daniel Kurtz wrote:
>> >> On Wed, Aug 5, 2015 at 2:46 PM, Sascha Hauer
>> >> wrote:
>> >> > On Tue, Aug 04, 2015 at 04:16:56PM +0800, James Liao wrote:
>> >> >> Most multimedia subsystem clocks will be accessed by multiple
>> >> >> drivers, so it's a better way to manage these clocks in CCF.
>> >> >> This patch adds clock support for MM, IMG, VDEC, VENC and VENC_LT
>> >> >> subsystems.
>> >> >>
>> >> >> Signed-off-by: James Liao
>> >> >> ---
>> >> >> drivers/clk/mediatek/clk-mt8173.c | 267
>> >> >> +
>> >> >> include/dt-bindings/clock/mt8173-clk.h | 97 +++-
>> >> >> 2 files changed, 361 insertions(+), 3 deletions(-)
>> >> >>
>> >> >> diff --git a/drivers/clk/mediatek/clk-mt8173.c
>> >> >> b/drivers/clk/mediatek/clk-mt8173.c
>> >> >> index f37ace6..05335e5 100644
>> >> >> --- a/drivers/clk/mediatek/clk-mt8173.c
>> >> >> +++ b/drivers/clk/mediatek/clk-mt8173.c
>> >> >> @@ -25,6 +25,10 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
>> >> >> static const struct mtk_fixed_clk fixed_clks[] __initconst = {
>> >> >> FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 *
>> >> >> MHZ),
>> >> >> FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m",
>> >> >> 125 * MHZ),
>> >> >> + FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 * MHZ),
>> >> >> + FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 * MHZ),
>> >> >> + FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5 * MHZ),
>> >> >> + FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll", 51.975 * MHZ),
>> >> >
>> >> > I would expect 51975 * KHZ here to avoid fractional numbers. Probably
>> >> > gcc calculates that during compile time so this will work as expected,
>> >> > still I'm not sure this is good style to use fractional numbers here.
>> >>
>> >> I thought this looked a bit strange too, but for what its worth, these
>> >> two evaluate correctly:
>> >>
>> >> localhost ~ # cat /sys/kernel/debug/clk/clk_summary | grep lvds
>> >> lvdspll 00 14878
>> >>0 0
>> >>lvds_pxl 00 14850
>> >>0 0
>> >>lvds_cts 0051975000
>> >>0 0
>> >>
>> >> >
>> >> > Anyway, on my system lvdspll is running at 150MHz. Are you sure there is
>> >> > a clock derived from this running at 148.5MHz? Is it really correct to
>> >> > use a fixed clock here or should it rather be lvdspll directly?
>> >>
>> >> I agree it does look strange to have a 51.975 MHz and 148.5 MHz clocks
>> >> with a 150 MHz PLL as their parent... However, I'm not sure how much
>> >> this matters? I think the idea here was that these frequencies are
>> >> best effort "nominal" clock values provided by Mediatek "designers".
>> >> The important point is that for the hardware to generate these either
>> >> of these clocks, lvdspll must be enabled.
>> >
>> > This assumes that the lvdspll always runs at frequency the designers
>> > thought that might be a good value. Should we really provide wrong clock
>> > values when on some board for whatever reason the lvdspll is configured
>> > for a different frequency?
>>
>> Do you have an alternative suggestion for estimating the frequency of
>> a non-software controllable or measurable hardware clock?
>
> What's the problem with using lvdspll directly? The consumers of these
> clocks should be able to cope with the deviation between nomial
> frequency and actual frequency.
Oh, I'm totally fine with that too. Although I think the way James
has it better models the hardware.
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 7/9] clk: mediatek: Add subsystem clocks of MT8173
On Wed, Aug 5, 2015 at 3:36 PM, Sascha Hauer wrote:
> On Wed, Aug 05, 2015 at 03:26:29PM +0800, Daniel Kurtz wrote:
>> On Wed, Aug 5, 2015 at 2:46 PM, Sascha Hauer wrote:
>> > On Tue, Aug 04, 2015 at 04:16:56PM +0800, James Liao wrote:
>> >> Most multimedia subsystem clocks will be accessed by multiple
>> >> drivers, so it's a better way to manage these clocks in CCF.
>> >> This patch adds clock support for MM, IMG, VDEC, VENC and VENC_LT
>> >> subsystems.
>> >>
>> >> Signed-off-by: James Liao
>> >> ---
>> >> drivers/clk/mediatek/clk-mt8173.c | 267
>> >> +
>> >> include/dt-bindings/clock/mt8173-clk.h | 97 +++-
>> >> 2 files changed, 361 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/drivers/clk/mediatek/clk-mt8173.c
>> >> b/drivers/clk/mediatek/clk-mt8173.c
>> >> index f37ace6..05335e5 100644
>> >> --- a/drivers/clk/mediatek/clk-mt8173.c
>> >> +++ b/drivers/clk/mediatek/clk-mt8173.c
>> >> @@ -25,6 +25,10 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
>> >> static const struct mtk_fixed_clk fixed_clks[] __initconst = {
>> >> FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
>> >> FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125
>> >> * MHZ),
>> >> + FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 * MHZ),
>> >> + FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 * MHZ),
>> >> + FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5 * MHZ),
>> >> + FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll", 51.975 * MHZ),
>> >
>> > I would expect 51975 * KHZ here to avoid fractional numbers. Probably
>> > gcc calculates that during compile time so this will work as expected,
>> > still I'm not sure this is good style to use fractional numbers here.
>>
>> I thought this looked a bit strange too, but for what its worth, these
>> two evaluate correctly:
>>
>> localhost ~ # cat /sys/kernel/debug/clk/clk_summary | grep lvds
>> lvdspll 00 14878
>>0 0
>>lvds_pxl 00 14850
>>0 0
>>lvds_cts 0051975000
>>0 0
>>
>> >
>> > Anyway, on my system lvdspll is running at 150MHz. Are you sure there is
>> > a clock derived from this running at 148.5MHz? Is it really correct to
>> > use a fixed clock here or should it rather be lvdspll directly?
>>
>> I agree it does look strange to have a 51.975 MHz and 148.5 MHz clocks
>> with a 150 MHz PLL as their parent... However, I'm not sure how much
>> this matters? I think the idea here was that these frequencies are
>> best effort "nominal" clock values provided by Mediatek "designers".
>> The important point is that for the hardware to generate these either
>> of these clocks, lvdspll must be enabled.
>
> This assumes that the lvdspll always runs at frequency the designers
> thought that might be a good value. Should we really provide wrong clock
> values when on some board for whatever reason the lvdspll is configured
> for a different frequency?
Do you have an alternative suggestion for estimating the frequency of
a non-software controllable or measurable hardware clock?
Or can we land this series and update the frequency via some future
patch if and when that other board arrives which may have a different
frequency - and there is some reason to care what that frequency
actually is?
-Dan
>
> sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 7/9] clk: mediatek: Add subsystem clocks of MT8173
On Wed, Aug 5, 2015 at 2:46 PM, Sascha Hauer wrote:
> On Tue, Aug 04, 2015 at 04:16:56PM +0800, James Liao wrote:
>> Most multimedia subsystem clocks will be accessed by multiple
>> drivers, so it's a better way to manage these clocks in CCF.
>> This patch adds clock support for MM, IMG, VDEC, VENC and VENC_LT
>> subsystems.
>>
>> Signed-off-by: James Liao
>> ---
>> drivers/clk/mediatek/clk-mt8173.c | 267
>> +
>> include/dt-bindings/clock/mt8173-clk.h | 97 +++-
>> 2 files changed, 361 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clk/mediatek/clk-mt8173.c
>> b/drivers/clk/mediatek/clk-mt8173.c
>> index f37ace6..05335e5 100644
>> --- a/drivers/clk/mediatek/clk-mt8173.c
>> +++ b/drivers/clk/mediatek/clk-mt8173.c
>> @@ -25,6 +25,10 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
>> static const struct mtk_fixed_clk fixed_clks[] __initconst = {
>> FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
>> FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125 *
>> MHZ),
>> + FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 * MHZ),
>> + FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 * MHZ),
>> + FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5 * MHZ),
>> + FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll", 51.975 * MHZ),
>
> I would expect 51975 * KHZ here to avoid fractional numbers. Probably
> gcc calculates that during compile time so this will work as expected,
> still I'm not sure this is good style to use fractional numbers here.
I thought this looked a bit strange too, but for what its worth, these
two evaluate correctly:
localhost ~ # cat /sys/kernel/debug/clk/clk_summary | grep lvds
lvdspll 00 14878
0 0
lvds_pxl 00 14850
0 0
lvds_cts 0051975000
0 0
>
> Anyway, on my system lvdspll is running at 150MHz. Are you sure there is
> a clock derived from this running at 148.5MHz? Is it really correct to
> use a fixed clock here or should it rather be lvdspll directly?
I agree it does look strange to have a 51.975 MHz and 148.5 MHz clocks
with a 150 MHz PLL as their parent... However, I'm not sure how much
this matters? I think the idea here was that these frequencies are
best effort "nominal" clock values provided by Mediatek "designers".
The important point is that for the hardware to generate these either
of these clocks, lvdspll must be enabled.
-Dan
> Sascha
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/9] Fixes and new clocks support for Mediatek MT8173
On Tue, Aug 4, 2015 at 4:16 PM, James Liao wrote: > This patchset is based on 4.2-rc2 and [1], and contains minor fixes and > subsystem clocks support for Mediatek MT8173. > > The previous reviews can be found in [2]. The most different from previous > patchset is rebasing to 4.2-rc2. For the whole series: Reviewed-by: Daniel Kurtz > > changes since v5: > - Rebase to 4.2-rc2. > - Patch "Fix enabling of critical clocks" had been included in 4.2-rc2, > so it need not be included in this patchset. > > changes since v4: > - Add a separated patch to remove unused dpi_ck. > - Add separated patches to fix clk/mediatek in release 4.2-rc1. > - Add __init* for initialization data and functions. > - Rename dummy_clk with oscillator in DT. > - Remove mtk_clk_register_apmixed_ex(), call mtk_clk_register_ref2usb_tx() > directly to register USB clock. > > changes since v3: > - Remove clk_null dependency from root clocks. > - Use fixed-rate clocks with typical rate to replace clk_null. > - Separate ref2usb_tx implementation to clk-apmixed.c > - Use clock-controller as the name of clock providers. > > changes since v2: > - Rebase to 4.2-rc1. > - Add device tree nodes for subsystem clocks. > - Fine tune comments of patches. > - Add __init, __initconst and const to init data and functions. > - Removed unused code from init functions of subsystem clocks. > > changes since v1: > - Add CA7PLL and CA15PLL as critical clocks. > - Use the same register descriptor for imgsys, vensys and vencltsys. > - Generalize apmixedsys special clocks registration. > > [1] https://patchwork.kernel.org/patch/6446341/ > [2] http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001800.html > > James Liao (9): > clk: mediatek: Removed unused dpi_ck clock from MT8173 > clk: mediatek: Remove unused code from MT8173. > clk: mediatek: Add __initdata and __init for data and functions > clk: mediatek: Add fixed clocks support for Mediatek SoC. > clk: mediatek: Fix rate and dependency of MT8173 clocks > dt-bindings: ARM: Mediatek: Document devicetree bindings for clock > controllers > clk: mediatek: Add subsystem clocks of MT8173 > clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS > arm64: dts: mt8173: Add subsystem clock controller device nodes > > .../bindings/arm/mediatek/mediatek,imgsys.txt | 22 ++ > .../bindings/arm/mediatek/mediatek,mmsys.txt | 22 ++ > .../bindings/arm/mediatek/mediatek,vdecsys.txt | 22 ++ > .../bindings/arm/mediatek/mediatek,vencltsys.txt | 22 ++ > .../bindings/arm/mediatek/mediatek,vencsys.txt | 22 ++ > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 37 +++ > drivers/clk/mediatek/Makefile | 2 +- > drivers/clk/mediatek/clk-apmixed.c | 107 +++ > drivers/clk/mediatek/clk-gate.c| 2 +- > drivers/clk/mediatek/clk-mt8173.c | 335 > - > drivers/clk/mediatek/clk-mtk.c | 36 ++- > drivers/clk/mediatek/clk-mtk.h | 24 +- > drivers/clk/mediatek/clk-pll.c | 7 +- > include/dt-bindings/clock/mt8173-clk.h | 101 ++- > 14 files changed, 728 insertions(+), 33 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt > create mode 100644 > Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt > create mode 100644 drivers/clk/mediatek/clk-apmixed.c > > -- > 1.8.1.1.dirty > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/7] clk: mediatek: Add fixed clocks support for Mediatek SoC.
Hi James,
On Fri, Jul 24, 2015 at 11:01 AM, James Liao wrote:
> This patch adds fixed clocks support by using CCF fixed-rate
> clock implementation.
>
> Signed-off-by: James Liao
> ---
> drivers/clk/mediatek/clk-mtk.c | 23 +++
> drivers/clk/mediatek/clk-mtk.h | 19 ++-
> 2 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index 18444ae..f8307c3 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
> @@ -49,6 +49,29 @@ err_out:
> return NULL;
> }
>
> +void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks, int num,
> + struct clk_onecell_data *clk_data)
void __init mtk_clk_register_fixed_clks(...
> +{
> + int i;
> + struct clk *clk;
> +
> + for (i = 0; i < num; i++) {
> + const struct mtk_fixed_clk *rc = &clks[i];
> +
> + clk = clk_register_fixed_rate(NULL, rc->name, rc->parent,
> + rc->parent ? 0 : CLK_IS_ROOT, rc->rate);
> +
> + if (IS_ERR(clk)) {
> + pr_err("Failed to register clk %s: %ld\n",
> + rc->name, PTR_ERR(clk));
> + continue;
> + }
> +
> + if (clk_data)
> + clk_data->clks[rc->id] = clk;
> + }
> +}
> +
> void mtk_clk_register_factors(const struct mtk_fixed_factor *clks, int num,
> struct clk_onecell_data *clk_data)
> {
> diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> index 9dda9d8..f083dfc 100644
> --- a/drivers/clk/mediatek/clk-mtk.h
> +++ b/drivers/clk/mediatek/clk-mtk.h
> @@ -25,6 +25,23 @@
>
> #define MHZ (1000 * 1000)
>
> +struct mtk_fixed_clk {
> + int id;
> + const char *name;
> + const char *parent;
> + unsigned long rate;
> +};
> +
> +#define FIXED_CLK(_id, _name, _parent, _rate) {\
> + .id = _id, \
> + .name = _name, \
> + .parent = _parent, \
> + .rate = _rate, \
> + }
> +
> +void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks,
> + int num, struct clk_onecell_data *clk_data);
> +
> struct mtk_fixed_factor {
> int id;
> const char *name;
> @@ -41,7 +58,7 @@ struct mtk_fixed_factor {
> .div = _div,\
> }
>
> -extern void mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
> +void mtk_clk_register_factors(const struct mtk_fixed_factor *clks,
Technically, this hunk is unrelated and should probably be in its own patch.
Other than these two nits, this one is:
Reviewed-by: Daniel Kurtz
> int num, struct clk_onecell_data *clk_data);
>
> struct mtk_composite {
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/7] arm64: dts: mt8173: Add subsystem clock controller device nodes
On Fri, Jul 24, 2015 at 11:02 AM, James Liao wrote:
> This patch adds device nodes providing subsystem clocks on MT8173,
> includes mmsys, imgsys, vdecsys, vencsys and vencltsys.
>
> Signed-off-by: James Liao
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 37
>
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index a2f63e4..8731d24 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -88,6 +88,13 @@
> #clock-cells = <0>;
> };
>
> + cpum_ck: dummy_clk {
I'm not a big fan of this "dummy_clk".
The 'name' part of the devicetree node is supposed to be generic.
So, perhaps just oscillator@2, and move it down below clk32k: oscillator@1.
Otherwise:
Reviewed-by: Daniel Kurtz
-Dan
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <0>;
> + clock-output-names = "cpum_ck";
> + };
> +
> clk26m: oscillator@0 {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> @@ -227,6 +234,36 @@
> clocks = <&uart_clk>;
> status = "disabled";
> };
> +
> + mmsys: clock-controller@1400 {
> + compatible = "mediatek,mt8173-mmsys", "syscon";
> + reg = <0 0x1400 0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + imgsys: clock-controller@1500 {
> + compatible = "mediatek,mt8173-imgsys", "syscon";
> + reg = <0 0x1500 0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + vdecsys: clock-controller@1600 {
> + compatible = "mediatek,mt8173-vdecsys", "syscon";
> + reg = <0 0x1600 0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + vencsys: clock-controller@1800 {
> + compatible = "mediatek,mt8173-vencsys", "syscon";
> + reg = <0 0x1800 0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> + vencltsys: clock-controller@1900 {
> + compatible = "mediatek,mt8173-vencltsys", "syscon";
> + reg = <0 0x1900 0 0x1000>;
> + #clock-cells = <1>;
> + };
> };
> };
>
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 6/7] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
On Fri, Jul 24, 2015 at 11:02 AM, James Liao wrote:
> Add REF2USB_TX clock support into MT8173 APMIXEDSYS. This clock
> is needed by USB 3.0.
>
> Signed-off-by: James Liao
> ---
> drivers/clk/mediatek/Makefile | 2 +-
> drivers/clk/mediatek/clk-apmixed.c | 137
> +
> drivers/clk/mediatek/clk-mt8173.c | 15 +++-
> drivers/clk/mediatek/clk-mtk.h | 26 +++
> drivers/clk/mediatek/clk-pll.c | 7 +-
> include/dt-bindings/clock/mt8173-clk.h | 3 +-
> 6 files changed, 180 insertions(+), 10 deletions(-)
> create mode 100644 drivers/clk/mediatek/clk-apmixed.c
>
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index 8e4b2a4..95fdfac 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -1,4 +1,4 @@
> -obj-y += clk-mtk.o clk-pll.o clk-gate.o
> +obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-apmixed.o
> obj-$(CONFIG_RESET_CONTROLLER) += reset.o
> obj-y += clk-mt8135.o
> obj-y += clk-mt8173.o
> diff --git a/drivers/clk/mediatek/clk-apmixed.c
> b/drivers/clk/mediatek/clk-apmixed.c
> new file mode 100644
> index 000..09f2a7c
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-apmixed.c
> @@ -0,0 +1,137 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: James Liao
> + *
> + * 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
> +#include
> +#include
> +
> +#include "clk-mtk.h"
> +
> +#define REF2USB_TX_EN BIT(0)
> +#define REF2USB_TX_LPF_EN BIT(1)
> +#define REF2USB_TX_OUT_EN BIT(2)
> +#define REF2USB_EN_MASK(REF2USB_TX_EN | REF2USB_TX_LPF_EN | \
> +REF2USB_TX_OUT_EN)
> +
> +struct mtk_ref2usb_tx {
> + struct clk_hw hw;
> + void __iomem*base_addr;
> +};
> +
> +static inline struct mtk_ref2usb_tx *to_mtk_ref2usb_tx(struct clk_hw *hw)
> +{
> + return container_of(hw, struct mtk_ref2usb_tx, hw);
> +}
> +
> +static int mtk_ref2usb_tx_is_prepared(struct clk_hw *hw)
> +{
> + struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
> +
> + return (readl(tx->base_addr) & REF2USB_EN_MASK) == REF2USB_EN_MASK;
> +}
> +
> +static int mtk_ref2usb_tx_prepare(struct clk_hw *hw)
> +{
> + struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
> + u32 val;
> +
> + val = readl(tx->base_addr);
> +
> + val |= REF2USB_TX_EN;
> + writel(val, tx->base_addr);
> + udelay(100);
> +
> + val |= REF2USB_TX_LPF_EN;
> + writel(val, tx->base_addr);
> +
> + val |= REF2USB_TX_OUT_EN;
> + writel(val, tx->base_addr);
> +
> + return 0;
> +}
> +
> +static void mtk_ref2usb_tx_unprepare(struct clk_hw *hw)
> +{
> + struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
> + u32 val;
> +
> + val = readl(tx->base_addr);
> + val &= ~REF2USB_EN_MASK;
> + writel(val, tx->base_addr);
> +}
> +
> +static const struct clk_ops mtk_ref2usb_tx_ops = {
> + .is_prepared= mtk_ref2usb_tx_is_prepared,
> + .prepare= mtk_ref2usb_tx_prepare,
> + .unprepare = mtk_ref2usb_tx_unprepare,
> +};
> +
> +struct clk *mtk_clk_register_ref2usb_tx(const char *name,
> + const char *parent_name, void __iomem *reg)
struct clk * __init mtk_clk_register_ref2usb_tx(
> +{
> + struct mtk_ref2usb_tx *tx;
> + struct clk_init_data init = {};
> + struct clk *clk;
> +
> + tx = kzalloc(sizeof(*tx), GFP_KERNEL);
> + if (!tx)
> + return ERR_PTR(-ENOMEM);
> +
> + tx->base_addr = reg;
> + tx->hw.init = &init;
> +
> + init.name = name;
> + init.ops = &mtk_ref2usb_tx_ops;
> + init.parent_names = &parent_name;
> + init.num_parents = 1;
> +
> + clk = clk_register(NULL, &tx->hw);
> +
> + if (IS_ERR(clk)) {
> + pr_err("Failed to register clk %s: %ld\n", name,
> PTR_ERR(clk));
> + kfree(tx);
> + }
> +
> + return clk;
> +}
> +
> +void __init mtk_clk_register_apmixed_ex(struct device_node *node,
> + const struct mtk_clk_ex *clks, int num_clks,
> + struct clk_onecell_data *clk_data)
> +{
> + void __iomem *base;
> + struct clk *clk;
> + int i;
> +
> + base = of_iomap(node, 0);
> + if (!base) {
> + pr_err("%s(): ioremap failed\n", __func__);
> + return;
> + }
> +
> + for (i = 0; i < num_clks; i++) {
> + const struct mtk_clk_ex *cke = &clks[i];
> +
>
Re: [PATCH v4 5/7] clk: mediatek: Add subsystem clocks of MT8173
On Fri, Jul 24, 2015 at 11:02 AM, James Liao wrote:
> Most multimedia subsystem clocks will be accessed by multiple
> drivers, so it's a better way to manage these clocks in CCF.
> This patch adds clock support for MM, IMG, VDEC, VENC and VENC_LT
> subsystems.
>
> Signed-off-by: James Liao
> ---
> drivers/clk/mediatek/clk-mt8173.c | 267
> +
> include/dt-bindings/clock/mt8173-clk.h | 97 +++-
> 2 files changed, 361 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c
> index a72ce82..2cf6620 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -27,6 +27,10 @@ static DEFINE_SPINLOCK(mt8173_clk_lock);
> static const struct mtk_fixed_clk fixed_clks[] __initconst = {
> FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
> FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125 *
> MHZ),
> + FIXED_CLK(CLK_TOP_DSI0_DIG, "dsi0_dig", "clk26m", 130 * MHZ),
> + FIXED_CLK(CLK_TOP_DSI1_DIG, "dsi1_dig", "clk26m", 130 * MHZ),
> + FIXED_CLK(CLK_TOP_LVDS_PXL, "lvds_pxl", "lvdspll", 148.5 * MHZ),
> + FIXED_CLK(CLK_TOP_LVDS_CTS, "lvds_cts", "lvdspll", 51.975 * MHZ),
> };
>
> static const struct mtk_fixed_factor top_divs[] __initconst = {
> @@ -699,6 +703,183 @@ static const struct mtk_composite peri_clks[]
> __initconst = {
> MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c,
> 3, 1),
> };
>
> +static const struct mtk_gate_regs cg_regs_4_8_0 = {
All of these regs tables can be __initconst.
Otherwise:
Reviewed-by: Daniel Kurtz
-Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] clk: mediatek: Fix rate and dependency of MT8173 clocks
On Fri, Jul 24, 2015 at 11:02 AM, James Liao wrote:
> Remove the dependency from clk_null, and give all root clocks a
> typical rate, include clkph_mck_o, usb_syspll_125m and hdmitx_dig_cts.
>
> dpi_ck was removed due to no clock reference to it.
>
> Replace parent clock of infra_cpum with cpum_ck, which is an external
> clock and can be defined in the deivce tree.
>
> Signed-off-by: James Liao
> ---
> drivers/clk/mediatek/clk-mt8173.c | 13 ++---
> include/dt-bindings/clock/mt8173-clk.h | 1 -
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c
> index 4b9e04c..50b3266 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -24,11 +24,9 @@
>
> static DEFINE_SPINLOCK(mt8173_clk_lock);
>
> -static const struct mtk_fixed_factor root_clk_alias[] __initconst = {
> - FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
> - FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
> - FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
> - FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
> +static const struct mtk_fixed_clk fixed_clks[] __initconst = {
> + FIXED_CLK(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk26m", 400 * MHZ),
> + FIXED_CLK(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk26m", 125 *
> MHZ),
> };
>
> static const struct mtk_fixed_factor top_divs[] __initconst = {
> @@ -53,6 +51,7 @@ static const struct mtk_fixed_factor top_divs[] __initconst
> = {
> FACTOR(CLK_TOP_CLKRTC_INT, "clkrtc_int", "clk26m", 1, 793),
> FACTOR(CLK_TOP_FPC, "fpc_ck", "clk26m", 1, 1),
>
> + FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "tvdpll_445p5m", 1,
> 3),
> FACTOR(CLK_TOP_HDMITXPLL_D2, "hdmitxpll_d2", "hdmitx_dig_cts", 1, 2),
> FACTOR(CLK_TOP_HDMITXPLL_D3, "hdmitxpll_d3", "hdmitx_dig_cts", 1, 3),
>
> @@ -611,7 +610,7 @@ static const struct mtk_gate infra_clks[] __initconst = {
> GATE_ICG(CLK_INFRA_GCE, "infra_gce", "axi_sel", 6),
> GATE_ICG(CLK_INFRA_L2C_SRAM, "infra_l2c_sram", "axi_sel", 7),
> GATE_ICG(CLK_INFRA_M4U, "infra_m4u", "mem_sel", 8),
> - GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
> + GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "cpum_ck", 15),
> GATE_ICG(CLK_INFRA_KP, "infra_kp", "axi_sel", 16),
> GATE_ICG(CLK_INFRA_CEC, "infra_cec", "clk26m", 18),
> GATE_ICG(CLK_INFRA_PMICSPI, "infra_pmicspi", "pmicspi_sel", 22),
> @@ -714,7 +713,7 @@ static void __init mtk_topckgen_init(struct device_node
> *node)
>
> clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
>
> - mtk_clk_register_factors(root_clk_alias, ARRAY_SIZE(root_clk_alias),
> clk_data);
> + mtk_clk_register_fixed_clks(fixed_clks, ARRAY_SIZE(fixed_clks),
> clk_data);
> mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
> mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
> &mt8173_clk_lock, clk_data);
> diff --git a/include/dt-bindings/clock/mt8173-clk.h
> b/include/dt-bindings/clock/mt8173-clk.h
> index 4ad76ed..7230c38 100644
> --- a/include/dt-bindings/clock/mt8173-clk.h
> +++ b/include/dt-bindings/clock/mt8173-clk.h
> @@ -18,7 +18,6 @@
> /* TOPCKGEN */
>
> #define CLK_TOP_CLKPH_MCK_O1
> -#define CLK_TOP_DPI2
> #define CLK_TOP_USB_SYSPLL_125M3
I think we should renumber the rest of the CLK_TOP_*
> #define CLK_TOP_HDMITX_DIG_CTS 4
> #define CLK_TOP_ARMCA7PLL_754M 5
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/3] dt-bindings: pwm: add MediaTek display PWM bindings
On Fri, Jul 24, 2015 at 4:40 PM, Matthias Brugger wrote: > On Monday, July 20, 2015 04:17:15 PM YH Huang wrote: >> Document the device-tree binding of MediatTek display PWM. >> The PWM has one channel to control the backlight brightness for display. >> It supports MT8173 and MT6595. >> >> Signed-off-by: YH Huang >> --- >> .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 42 >> ++ 1 file changed, 42 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt >> >> diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt >> b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt new file mode >> 100644 >> index 000..f8f59ba >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt >> @@ -0,0 +1,42 @@ >> +MediaTek display PWM controller >> + >> +Required properties: >> + - compatible: should be "mediatek,-disp-pwm": >> + - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. >> + - "mediatek,mt6595-disp-pwm": found on mt6595 SoC. > > I had another look on the mt6589 datasheet and for me it doesn't look like as > if this drivers is compatible to mt6589. Matthias - the compatible is "mt6595", not mt6589 :-). Which datasheet did you check? -Dan > > DISP_PWM_CON_0 offset 0x10 maps to interrupt enable register and > DISP_PWM_CON_1 offset 0x14 maps to interrupt status register. > > This looks wrong to me, as you use both registers to write clock divider and > clock period. > > Regarding that this is v6 of the patch set, I would propose that you just drop > the compatible string for mt6589 or you implement the register offset on basis > of the compatible string so that mt6589 can you the driver as well. > > Best regards, > Matthias > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] dts: mt8173: Add iommu/smi nodes for mt8173
Hi Yong,
On Thu, Jul 16, 2015 at 5:04 PM, Yong Wu wrote:
>
> This patch add the iommu/larbs nodes for mt8173
To what tree does this apply?
Please rebase these patches (especially this one) on an Matthias'
current v4.2-next/for-next.
>
> Signed-off-by: Yong Wu
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 81
> ++
> 1 file changed, 81 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index e81ac1f..7b8e73c 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include "mt8173-pinfunc.h"
> @@ -240,6 +241,17 @@
> reg = <0 0x10200620 0 0x20>;
> };
>
> + iommu: mmsys_iommu@10205000 {
This name should be generic, like this (this comment really applies to
the binding patch):
iommu: iommu@10205000
> + compatible = "mediatek,mt8173-m4u";
> + reg = <0 0x10205000 0 0x1000>;
> + interrupts = ;
> + clocks = <&infracfg CLK_INFRA_M4U>;
> + clock-names = "bclk";
> + mediatek,larb = <&larb0 &larb1 &larb2
> + &larb3 &larb4 &larb5>;
Tiny nit... please align the "&".
Otherwise, this one is:
Reviewed-by: Daniel Kurtz
Thanks!
-Dan
> + #iommu-cells = <2>;
> + };
> +
> apmixedsys: clock-controller@10209000 {
> compatible = "mediatek,mt8173-apmixedsys";
> reg = <0 0x10209000 0 0x1000>;
> @@ -401,29 +413,98 @@
> #clock-cells = <1>;
> };
>
> + larb0: larb@14021000 {
> + compatible = "mediatek,mt8173-smi-larb";
> + reg = <0 0x14021000 0 0x1000>;
> + mediatek,smi = <&smi_common>;
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> + clocks = <&mmsys CLK_MM_SMI_LARB0>,
> +<&mmsys CLK_MM_SMI_LARB0>;
> + clock-names = "apb", "smi";
> + };
> +
> + smi_common: smi@14022000 {
> + compatible = "mediatek,mt8173-smi";
> + reg = <0 0x14022000 0 0x1000>;
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> + clocks = <&mmsys CLK_MM_SMI_COMMON>,
> +<&mmsys CLK_MM_SMI_COMMON>;
> + clock-names = "apb", "smi";
> + };
> +
> + larb4: larb@14027000 {
> + compatible = "mediatek,mt8173-smi-larb";
> + reg = <0 0x14027000 0 0x1000>;
> + mediatek,smi = <&smi_common>;
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> + clocks = <&mmsys CLK_MM_SMI_LARB4>,
> +<&mmsys CLK_MM_SMI_LARB4>;
> + clock-names = "apb", "smi";
> + };
> +
> imgsys: imgsys@1500 {
> compatible = "mediatek,mt8173-imgsys", "syscon";
> reg = <0 0x1500 0 0x1000>;
> #clock-cells = <1>;
> };
>
> + larb2: larb@15001000 {
> + compatible = "mediatek,mt8173-smi-larb";
> + reg = <0 0x15001000 0 0x1000>;
> + mediatek,smi = <&smi_common>;
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_ISP>;
> + clocks = <&imgsys CLK_IMG_LARB2_SMI>,
> +<&imgsys CLK_IMG_LARB2_SMI>;
> + clock-names = "apb", "smi";
> + };
> +
> vdecsys: vdecsys@1600 {
> compatible = "mediatek,mt8173-vdecsys", "syscon";
> reg = <0 0x1600 0 0x100
Re: [PATCH v2 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173
On Mon, Jul 20, 2015 at 10:51 PM, Yingjoe Chen
wrote:
>
> Hi Daniel, Chunfeng,
>
>
> On Mon, 2015-07-20 at 22:39 +0800, chunfeng yun wrote:
>> Hi,
>>
>> On Tue, 2015-07-14 at 18:12 +0800, Daniel Kurtz wrote:
> <...>
>> > > +
>> > > + usb_p1_vbus: fixedregulator@0 {
>> >
>> > Why @0 ?
>> It is the first fixed regulator, so set it to 0 as a index.
>> I will remove it later
>
> Since this name should be unique, I think we should use gpio number as
> address for fixedregulator in case we need other fixedregulators. So
> this could be:
>
> usb_p1_vbus: fixedregulator@130 {
>
> Also, we should sort according to the address(gpio number) for these
> nodes. Does this make sense?
Yes - that makes some sense.
But, a quick check of other "fixedregulator@" nodes in
arch/arm/boot/dts/ shows that mostly they use @0 , @1.
So, I think the original patch is probably fine.
Sorry for the noise,
-Dan
>
> Joe.C
>
>> >
>> > > + compatible = "regulator-fixed";
>> > > + regulator-name = "usb_vbus";
>> > > + regulator-min-microvolt = <500>;
>> > > + regulator-max-microvolt = <500>;
>> > > + gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
>> > > + enable-active-high;
>> > > + };
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/3] arm64: dts: mt8173: add MT8173 display PWM driver support node
On Mon, Jul 20, 2015 at 4:17 PM, YH Huang wrote:
> Add display PWM node in mt8173-evb.dts and mt8173.dtsi.
>
> Signed-off-by: YH Huang
For the series:
Reviewed-by: Daniel Kurtz
> ---
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 15 +++
> arch/arm64/boot/dts/mediatek/mt8173.dtsi| 22 ++
> 2 files changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index f433c21..b7c1d9f 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -34,6 +34,21 @@
> chosen { };
> };
>
> +&pio {
> + disp_pwm0_pins: disp_pwm0_pins {
> + pins1 {
> + pinmux = ;
> + bias-pull-up;
> + };
> + };
> +};
> +
> +&pwm0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&disp_pwm0_pins>;
> + status = "okay";
> +};
> +
> &pwrap {
> pmic: mt6397 {
> compatible = "mediatek,mt6397";
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 0696f8f..44cab19 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -393,6 +393,28 @@
> #size-cells = <0>;
> status = "disabled";
> };
> +
> + pwm0: pwm@1401e000 {
> + compatible = "mediatek,mt8173-disp-pwm",
> +"mediatek,mt6595-disp-pwm";
> + reg = <0 0x1401e000 0 0x1000>;
> + #pwm-cells = <2>;
> + clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> +<&mmsys CLK_MM_DISP_PWM0MM>;
> + clock-names = "main", "mm";
> + status = "disabled";
> + };
> +
> + pwm1: pwm@1401f000 {
> + compatible = "mediatek,mt8173-disp-pwm",
> +"mediatek,mt6595-disp-pwm";
> + reg = <0 0x1401f000 0 0x1000>;
> + #pwm-cells = <2>;
> + clocks = <&mmsys CLK_MM_DISP_PWM126M>,
> +<&mmsys CLK_MM_DISP_PWM1MM>;
> + clock-names = "main", "mm";
> + status = "disabled";
> + };
> };
> };
>
> --
> 1.8.1.1.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/3] pwm: add MediaTek display PWM driver support
On Fri, Jul 17, 2015 at 2:35 PM, YH Huang wrote:
>
> On Fri, 2015-07-17 at 01:18 +0800, Daniel Kurtz wrote:
> > On Fri, Jul 17, 2015 at 12:44 AM, YH Huang wrote:
> > > On Thu, 2015-07-16 at 23:21 +0800, Daniel Kurtz wrote:
> > >> On Thu, Jul 16, 2015 at 3:17 PM, YH Huang wrote:
> > >> > On Thu, 2015-07-16 at 14:54 +0800, Daniel Kurtz wrote:
> > >> >> On Thu, Jul 16, 2015 at 1:38 PM, YH Huang
> > >> >> wrote:
> > >> >> > On Wed, 2015-07-15 at 23:59 +0800, YH Huang wrote:
> > >> >> >> On Mon, 2015-07-13 at 18:19 +0800, Daniel Kurtz wrote:
> > >> >> >> > On Mon, Jul 13, 2015 at 5:04 PM, YH Huang
> > >> >> >> > wrote:
> > >> >> >> > > +#ifdef CONFIG_PM_SLEEP
> > >> >> >> > > +static int mtk_disp_pwm_suspend(struct device *dev)
> > >> >> >> > > +{
> > >> >> >> > > + struct mtk_disp_pwm *mdp = dev_get_drvdata(dev);
> > >> >> >> > > +
> > >> >> >> > > + clk_disable_unprepare(mdp->clk_main);
> > >> >> >> > > + clk_disable_unprepare(mdp->clk_mm);
> > >> >> >> > > +
> > >> >> >> > > + return 0;
> > >> >> >> > > +}
> > >> >> >> > > +
> > >> >> >> > > +static int mtk_disp_pwm_resume(struct device *dev)
> > >> >> >> > > +{
> > >> >> >> > > + struct mtk_disp_pwm *mdp = dev_get_drvdata(dev);
> > >> >> >> > > + int ret;
> > >> >> >> > > +
> > >> >> >> > > + ret = clk_prepare_enable(mdp->clk_main);
> > >> >> >> > > + if (ret < 0)
> > >> >> >> > > + return ret;
> > >> >> >> > > +
> > >> >> >> > > + ret = clk_prepare_enable(mdp->clk_mm);
> > >> >> >> > > + if (ret < 0) {
> > >> >> >> > > + clk_disable_unprepare(mdp->clk_main);
> > >> >> >> > > + return ret;
> > >> >> >> > > + }
> > >> >> >> > > +
> > >> >> >> >
> > >> >> >> > Don't you also have to restore the PWM rate and frequency?
> > >> >> >> >
> > >> >> >> > Is it possible to save power at runtime by leaving mdp->clk_mm
> > >> >> >> > enabled
> > >> >> >> > (to generate the PWM signal), but disable mdp->clk_main (clock
> > >> >> >> > required to access PWM registers)?
> > >> >> >>
> > >> >> >> The pwm-backlight driver will restore the data.
> > >> >> >>
> > >> >> >> After I try to disable anyone of the two clocks at runtime, the
> > >> >> >> backlight doesn't work well(no immediate update or losing
> > >> >> >> backlight).
> > >> >> >> So we need to keep both clock enabled.
> > >>
> > >> Do you mean you see backlight glitch because the clocks / backlight
> > >> were *already on* during the first config (Perhaps left on by the
> > >> bootloader)?
> > >> I don't know how to solve that problem.
> > >> Maybe Thierry does.
> > >>
> > >> In any case, this is a minor issue; we really shouldn't hold up
> > >> landing the driver to optimize when the clocks are enabled/disabled
> > >> :-). I'm happy enough with what you have in this patch.
> > >
> > > Sorry for my terrible expression. Let me try again.
> > > 1. We want to disable unnecessary clock at runtime.
> > > But, I get backlight glitch when I disable clk_main or clk_mm in
> > > mtk_disp_pwm_config(). So both clocks are necessary and we don't disable
> > > them at runtime.
> > >
> > > 2. Because pwm-backlight driver calls mtk_disp_pwm_config() before
> > > mtk_disp_pwm_enable(), we will lose the first config if clocks are
> > > enabled in mtk_disp_pwm_enable(). I prefer to enable clocks in probe
> > > function. Samsung did the same way in t
Re: [PATCH v5 2/3] pwm: add MediaTek display PWM driver support
On Fri, Jul 17, 2015 at 12:44 AM, YH Huang wrote:
> On Thu, 2015-07-16 at 23:21 +0800, Daniel Kurtz wrote:
>> On Thu, Jul 16, 2015 at 3:17 PM, YH Huang wrote:
>> > On Thu, 2015-07-16 at 14:54 +0800, Daniel Kurtz wrote:
>> >> On Thu, Jul 16, 2015 at 1:38 PM, YH Huang wrote:
>> >> > On Wed, 2015-07-15 at 23:59 +0800, YH Huang wrote:
>> >> >> On Mon, 2015-07-13 at 18:19 +0800, Daniel Kurtz wrote:
>> >> >> > On Mon, Jul 13, 2015 at 5:04 PM, YH Huang
>> >> >> > wrote:
>> >> >> > > +#ifdef CONFIG_PM_SLEEP
>> >> >> > > +static int mtk_disp_pwm_suspend(struct device *dev)
>> >> >> > > +{
>> >> >> > > + struct mtk_disp_pwm *mdp = dev_get_drvdata(dev);
>> >> >> > > +
>> >> >> > > + clk_disable_unprepare(mdp->clk_main);
>> >> >> > > + clk_disable_unprepare(mdp->clk_mm);
>> >> >> > > +
>> >> >> > > + return 0;
>> >> >> > > +}
>> >> >> > > +
>> >> >> > > +static int mtk_disp_pwm_resume(struct device *dev)
>> >> >> > > +{
>> >> >> > > + struct mtk_disp_pwm *mdp = dev_get_drvdata(dev);
>> >> >> > > + int ret;
>> >> >> > > +
>> >> >> > > + ret = clk_prepare_enable(mdp->clk_main);
>> >> >> > > + if (ret < 0)
>> >> >> > > + return ret;
>> >> >> > > +
>> >> >> > > + ret = clk_prepare_enable(mdp->clk_mm);
>> >> >> > > + if (ret < 0) {
>> >> >> > > + clk_disable_unprepare(mdp->clk_main);
>> >> >> > > + return ret;
>> >> >> > > + }
>> >> >> > > +
>> >> >> >
>> >> >> > Don't you also have to restore the PWM rate and frequency?
>> >> >> >
>> >> >> > Is it possible to save power at runtime by leaving mdp->clk_mm
>> >> >> > enabled
>> >> >> > (to generate the PWM signal), but disable mdp->clk_main (clock
>> >> >> > required to access PWM registers)?
>> >> >>
>> >> >> The pwm-backlight driver will restore the data.
>> >> >>
>> >> >> After I try to disable anyone of the two clocks at runtime, the
>> >> >> backlight doesn't work well(no immediate update or losing backlight).
>> >> >> So we need to keep both clock enabled.
>>
>> Do you mean you see backlight glitch because the clocks / backlight
>> were *already on* during the first config (Perhaps left on by the
>> bootloader)?
>> I don't know how to solve that problem.
>> Maybe Thierry does.
>>
>> In any case, this is a minor issue; we really shouldn't hold up
>> landing the driver to optimize when the clocks are enabled/disabled
>> :-). I'm happy enough with what you have in this patch.
>
> Sorry for my terrible expression. Let me try again.
> 1. We want to disable unnecessary clock at runtime.
> But, I get backlight glitch when I disable clk_main or clk_mm in
> mtk_disp_pwm_config(). So both clocks are necessary and we don't disable
> them at runtime.
>
> 2. Because pwm-backlight driver calls mtk_disp_pwm_config() before
> mtk_disp_pwm_enable(), we will lose the first config if clocks are
> enabled in mtk_disp_pwm_enable(). I prefer to enable clocks in probe
> function. Samsung did the same way in their pwm driver.
I don't understand why you will "lose the first config if clocks are
enabled in mtk_disp_pwm_enable(). I don't believe registers will lose
their values just because you turn enable/disable clocks.
Perhaps I wasn't clear with what I was proposing which is something like this:
mtk_disp_pwm_config()
{
clk_enable();
/* write registers */
clk_disable();
}
mtk_disp_enable()
{
clk_enable();
/* write enable bit */
}
mtk_disp_disable()
{
/* clear enable bit */
clk_disable();
}
In this way, if mtk_disp_pwm_config() is called when the pwm is
disabled, we will temporarily enable the clocks long enough to update
the register values. These values should take effect the next time
the PWM is enabled. We then disable the clocks and wait for the PWM
to be enabled.
If mtk_disp_pwm_config() is called when the pwm is already enabled, we
will increment the enable count on the clocks, but then we decrement
it again immediately.
Thanks,
-Dan
>
> Thanks for your kindly suggestions. I will update the patch soon.
>
> Regards,
> YH Huang
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/3] pwm: add MediaTek display PWM driver support
On Thu, Jul 16, 2015 at 3:17 PM, YH Huang wrote: > On Thu, 2015-07-16 at 14:54 +0800, Daniel Kurtz wrote: >> On Thu, Jul 16, 2015 at 1:38 PM, YH Huang wrote: >> > On Wed, 2015-07-15 at 23:59 +0800, YH Huang wrote: >> >> On Mon, 2015-07-13 at 18:19 +0800, Daniel Kurtz wrote: >> >> > On Mon, Jul 13, 2015 at 5:04 PM, YH Huang wrote: >> >> > > Add display PWM driver support to modify backlight for MT8173 and >> >> > > MT6595. >> >> > > The PWM has one channel to control the brightness of the display. >> >> > > When the (high_width / period) is closer to 1, the screen is brighter; >> >> > > otherwise, it is darker. >> >> > > >> >> > > Signed-off-by: YH Huang >> >> > > --- >> >> > > drivers/pwm/Kconfig| 10 ++ >> >> > > drivers/pwm/Makefile | 1 + >> >> > > drivers/pwm/pwm-mtk-disp.c | 256 >> >> > > + >> >> > > 3 files changed, 267 insertions(+) >> >> > > create mode 100644 drivers/pwm/pwm-mtk-disp.c >> >> > > >> >> > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig >> >> > > index b1541f4..f5b03a4 100644 >> >> > > --- a/drivers/pwm/Kconfig >> >> > > +++ b/drivers/pwm/Kconfig >> >> > > @@ -211,6 +211,16 @@ config PWM_LPSS_PLATFORM >> >> > > To compile this driver as a module, choose M here: the >> >> > > module >> >> > > will be called pwm-lpss-platform. >> >> > > >> >> > > +config PWM_MTK_DISP >> >> > > + tristate "MediaTek display PWM driver" >> >> > > + depends on ARCH_MEDIATEK || COMPILE_TEST >> >> > > + help >> >> > > + Generic PWM framework driver for MediaTek disp-pwm device. >> >> > > + The PWM is used to control the backlight brightness for >> >> > > display. >> >> > > + >> >> > > + To compile this driver as a module, choose M here: the >> >> > > module >> >> > > + will be called pwm-mtk-disp. >> >> > > + >> >> > > config PWM_MXS >> >> > > tristate "Freescale MXS PWM support" >> >> > > depends on ARCH_MXS && OF >> >> > > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile >> >> > > index ec50eb5..99c9e75 100644 >> >> > > --- a/drivers/pwm/Makefile >> >> > > +++ b/drivers/pwm/Makefile >> >> > > @@ -18,6 +18,7 @@ obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o >> >> > > obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o >> >> > > obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o >> >> > > obj-$(CONFIG_PWM_LPSS_PLATFORM)+= pwm-lpss-platform.o >> >> > > +obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o >> >> > > obj-$(CONFIG_PWM_MXS) += pwm-mxs.o >> >> > > obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o >> >> > > obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o >> >> > > diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c >> >> > > new file mode 100644 >> >> > > index 000..1f17cee >> >> > > --- /dev/null >> >> > > +++ b/drivers/pwm/pwm-mtk-disp.c >> >> > > @@ -0,0 +1,256 @@ >> >> > > +/* >> >> > > + * MediaTek display pulse-width-modulation controller driver. >> >> > > + * Copyright (c) 2015 MediaTek Inc. >> >> > > + * Author: YH Huang >> >> > > + * >> >> > > + * 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 detail
Re: [PATCH] arm64: dts: mediatek: Add MT8173 MMC dts
Hi Chaotian,
On Thu, Jul 16, 2015 at 7:36 PM, Chaotian Jing
wrote:
> From: Eddie Huang
>
> Add node mmc0 ~ mmc3 for mt8173.dtsi
> Add node mmc0, mmc1 for mt8173-evb.dts
>
> Signed-off-by: Chaotian Jing
> Signed-off-by: Eddie Huang
> ---
> Remove clk_null
> Base on 4.2-rc1, and
> https://github.com/mbgg/linux-mediatek/tree/v4.2-next/arm64 commit 16ea61fc
> arm64: dts: mt8173-evb: Add PMIC support
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 126
>
> arch/arm64/boot/dts/mediatek/mt8173.dtsi| 44 ++
> 2 files changed, 170 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index 986f25f..f76c99b 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -64,6 +64,132 @@
> };
> };
>
> +&mmc0 {
> + status = "okay";
> + pinctrl-names = "default", "state_uhs";
> + pinctrl-0 = <&mmc0_pins_default>;
> + pinctrl-1 = <&mmc0_pins_uhs>;
> + bus-width = <8>;
> + max-frequency = <5000>;
> + cap-mmc-highspeed;
> + vmmc-supply = <&mt6397_vemc_3v3_reg>;
> + vqmmc-supply = <&mt6397_vio18_reg>;
> + non-removable;
> +};
> +
> +&mmc1 {
> + status = "okay";
> + pinctrl-names = "default", "state_uhs";
> + pinctrl-0 = <&mmc1_pins_default>;
> + pinctrl-1 = <&mmc1_pins_uhs>;
> + bus-width = <4>;
> + max-frequency = <5000>;
> + cap-sd-highspeed;
> + sd-uhs-sdr25;
> + cd-gpios = <&pio 132 0>;
> + vmmc-supply = <&mt6397_vmch_reg>;
> + vqmmc-supply = <&mt6397_vmc_reg>;
> +};
> +
> +&pio {
> + mmc0_pins_default: mmc0default {
> + pins_cmd_dat {
> + pinmux = ,
> +,
> +,
> +,
> +,
> +,
> +,
> +,
> +;
> + input-enable;
> + bias-pull-up;
> + };
> +
> + pins_clk {
> + pinmux = ;
> + bias-pull-down;
> + };
> +
> + pins_rst {
> + pinmux = ;
> + bias-pull-up;
> + };
> + };
> +
> + mmc1_pins_default: mmc1default {
> + pins_cmd_dat {
> + pinmux = ,
> +,
> +,
> +,
> +;
> + input-enable;
> + drive-strength = ;
> + bias-pull-up = ;
> + };
> +
> + pins_clk {
> + pinmux = ;
> + bias-pull-down;
> + drive-strength = ;
> + };
> +
> + pins_insert {
> + pinmux = ;
> + bias-pull-up;
> + };
> + };
> +
> + mmc0_pins_uhs: mmc0@0{
(1) I don't think these "@0" are needed (here and for mmc1_pins_uhs)
(2) A space before the '{' would be nice.
Other than these tiny nits, this one is:
Reviewed-by: Daniel Kurtz
> + pins_cmd_dat {
> + pinmux = ,
> +,
> +,
> +,
> +,
> +,
> +,
> +,
> +;
> + input-enable;
> + drive-strength = ;
> + bias-pull-up = ;
> + };
> +
> + pins_clk {
> + pinmux = ;
> + drive-strength = ;
> + bias-pull-down = ;
> + };
> +
> + pins_rst {
> + pinmux = ;
> + bias-pull-up;
> + };
> + };
> +
> + mmc1_pins_uhs: mmc1@0 {
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/3] pwm: add MediaTek display PWM driver support
On Thu, Jul 16, 2015 at 1:38 PM, YH Huang wrote: > On Wed, 2015-07-15 at 23:59 +0800, YH Huang wrote: >> On Mon, 2015-07-13 at 18:19 +0800, Daniel Kurtz wrote: >> > On Mon, Jul 13, 2015 at 5:04 PM, YH Huang wrote: >> > > Add display PWM driver support to modify backlight for MT8173 and MT6595. >> > > The PWM has one channel to control the brightness of the display. >> > > When the (high_width / period) is closer to 1, the screen is brighter; >> > > otherwise, it is darker. >> > > >> > > Signed-off-by: YH Huang >> > > --- >> > > drivers/pwm/Kconfig| 10 ++ >> > > drivers/pwm/Makefile | 1 + >> > > drivers/pwm/pwm-mtk-disp.c | 256 >> > > + >> > > 3 files changed, 267 insertions(+) >> > > create mode 100644 drivers/pwm/pwm-mtk-disp.c >> > > >> > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig >> > > index b1541f4..f5b03a4 100644 >> > > --- a/drivers/pwm/Kconfig >> > > +++ b/drivers/pwm/Kconfig >> > > @@ -211,6 +211,16 @@ config PWM_LPSS_PLATFORM >> > > To compile this driver as a module, choose M here: the module >> > > will be called pwm-lpss-platform. >> > > >> > > +config PWM_MTK_DISP >> > > + tristate "MediaTek display PWM driver" >> > > + depends on ARCH_MEDIATEK || COMPILE_TEST >> > > + help >> > > + Generic PWM framework driver for MediaTek disp-pwm device. >> > > + The PWM is used to control the backlight brightness for >> > > display. >> > > + >> > > + To compile this driver as a module, choose M here: the module >> > > + will be called pwm-mtk-disp. >> > > + >> > > config PWM_MXS >> > > tristate "Freescale MXS PWM support" >> > > depends on ARCH_MXS && OF >> > > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile >> > > index ec50eb5..99c9e75 100644 >> > > --- a/drivers/pwm/Makefile >> > > +++ b/drivers/pwm/Makefile >> > > @@ -18,6 +18,7 @@ obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o >> > > obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o >> > > obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o >> > > obj-$(CONFIG_PWM_LPSS_PLATFORM)+= pwm-lpss-platform.o >> > > +obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o >> > > obj-$(CONFIG_PWM_MXS) += pwm-mxs.o >> > > obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o >> > > obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o >> > > diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c >> > > new file mode 100644 >> > > index 000..1f17cee >> > > --- /dev/null >> > > +++ b/drivers/pwm/pwm-mtk-disp.c >> > > @@ -0,0 +1,256 @@ >> > > +/* >> > > + * MediaTek display pulse-width-modulation controller driver. >> > > + * Copyright (c) 2015 MediaTek Inc. >> > > + * Author: YH Huang >> > > + * >> > > + * 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 >> > > +#include >> > > +#include >> > > +#include >> > > +#include >> > > +#include >> > > +#include >> > > +#include >> > > + >> > > +#define DISP_PWM_EN0 >> > >> > The "DISP_PWM_*" are register offsets, so use a hex value, like this: >> > >> > #define DISP_PWM_EN 0x00 >> > >> > Use BIT() for register *fields*, that is, the individual bits of a >> > register. >> > >> >> Got it! >> >> > > +#define PWM_ENABLE_MASKBIT(0) >> > > + >> > > +#define DISP_PWM_COMMITBI
Re: [PATCH v4] clk: mediatek: Export CPU mux clocks for CPU frequency control
On Tue, Jul 14, 2015 at 5:34 PM, Pi-Cheng Chen wrote:
> From: "pi-cheng.chen"
>
> This patch adds CPU mux clocks which are used by Mediatek cpufreq driver
> for intermediate clock source switching.
>
> Signed-off-by: Pi-Cheng Chen
> Reviewed-by: Daniel Kurtz
> ---
> Changes in v4:
> - Address comments for v3
> - Rebase to the patch that adds 13mhz clock for MT8173[1]
>
> Changes in v3:
> - Rebase to 4.2-rc1
> - Fix some issues of v2
>
> Changes in v2:
> - Remove use of .determine_rate callback
>
> [1] http://patchwork.kernerl.xyz/patch/6777041/
> ---
> drivers/clk/mediatek/Makefile | 2 +-
> drivers/clk/mediatek/clk-cpumux.c | 127
> +
> drivers/clk/mediatek/clk-cpumux.h | 22 ++
> drivers/clk/mediatek/clk-mt8173.c | 23 ++
> include/dt-bindings/clock/mt8173-clk.h | 4 +-
> 5 files changed, 176 insertions(+), 2 deletions(-)
> create mode 100644 drivers/clk/mediatek/clk-cpumux.c
> create mode 100644 drivers/clk/mediatek/clk-cpumux.h
>
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index 8e4b2a4..299917a 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -1,4 +1,4 @@
> -obj-y += clk-mtk.o clk-pll.o clk-gate.o
> +obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-cpumux.o
> obj-$(CONFIG_RESET_CONTROLLER) += reset.o
> obj-y += clk-mt8135.o
> obj-y += clk-mt8173.o
> diff --git a/drivers/clk/mediatek/clk-cpumux.c
> b/drivers/clk/mediatek/clk-cpumux.c
> new file mode 100644
> index 000..fb04fe1
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-cpumux.c
> @@ -0,0 +1,127 @@
> +/*
> + * Copyright (c) 2015 Linaro Ltd.
> + * Author: Pi-Cheng Chen
> + *
> + * 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
> +#include
> +#include
> +
> +#include "clk-mtk.h"
> +#include "clk-cpumux.h"
> +
> +struct mtk_clk_cpumux {
> + struct clk_hw hw;
> + struct regmap *regmap;
> + u32 reg;
> + u32 mask;
> + u8 shift;
> +};
> +
> +static inline struct mtk_clk_cpumux *to_clk_mux(struct clk_hw *_hw)
> +{
> + return container_of(_hw, struct mtk_clk_cpumux, hw);
> +}
> +
> +static u8 clk_cpumux_get_parent(struct clk_hw *hw)
> +{
> + struct mtk_clk_cpumux *mux = to_clk_mux(hw);
> + int num_parents = __clk_get_num_parents(hw->clk);
> + unsigned int val;
> +
> + regmap_read(mux->regmap, mux->reg, &val);
> +
> + val >>= mux->shift;
> + val &= mux->mask;
> +
> + if (val >= num_parents)
> + return -EINVAL;
> +
> + return val;
> +}
> +
> +static int clk_cpumux_set_parent(struct clk_hw *hw, u8 index)
> +{
> + struct mtk_clk_cpumux *mux = to_clk_mux(hw);
> + u32 mask, val;
> +
> + val = index << mux->shift;
> + mask = mux->mask << mux->shift;
> +
> + return regmap_update_bits(mux->regmap, mux->reg, mask, val);
> +}
> +
> +static const struct clk_ops clk_cpumux_ops = {
> + .get_parent = clk_cpumux_get_parent,
> + .set_parent = clk_cpumux_set_parent,
> +};
> +
> +static struct clk __init *mtk_clk_register_cpumux(const struct mtk_composite
> *mux,
> + struct regmap *regmap)
> +{
> + struct mtk_clk_cpumux *cpumux;
> + struct clk *clk;
> + struct clk_init_data init;
> +
> + cpumux = kzalloc(sizeof(*cpumux), GFP_KERNEL);
> + if (!cpumux)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = mux->name;
> + init.ops = &clk_cpumux_ops;
> + init.parent_names = mux->parent_names;
> + init.num_parents = mux->num_parents;
> + init.flags = mux->flags;
> +
> + cpumux->reg = mux->mux_reg;
> + cpumux->shift = mux->mux_shift;
> + cpumux->mask = BIT(mux->mux_width) - 1;
> + cpumux->regmap = regmap;
> + cpumux->hw.init = &init;
> +
> + clk = clk_register(NULL, &cpumux->hw);
> + if (IS_ERR(cl
Re: [PATCH v3 4/5] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
On Tue, Jul 14, 2015 at 5:46 PM, James Liao wrote:
> Hi Daniel,
>
> On Tue, 2015-07-14 at 11:23 +0800, Daniel Kurtz wrote:
>> On Tue, Jul 14, 2015 at 10:45 AM, James Liao
>> wrote:
>> > On Mon, 2015-07-13 at 22:46 +0800, Daniel Kurtz wrote:
>> >> > +static const struct clk_ops mtk_ref2usb_tx_ops = {
>> >> > + .is_prepared= mtk_ref2usb_tx_is_prepared,
>> >> > + .prepare= mtk_ref2usb_tx_prepare,
>> >> > + .unprepare = mtk_ref2usb_tx_unprepare,
>> >> > +};
>> >>
>> >> Burying the implementation of this special "mtk_ref2usb" clock in
>> >> clk-mt8173,c seems a bit awkward.
>> >> Can you please move it to its own file, like mediatek/clk-usb.c?
>> >
>> > Do you mean clk/mediatek/clk-usb.c?
>> >
>> > This clock is a MT8173 specific clock, which may not be reused by other
>> > SoCs. So I think it's not necessary to move it to a separated file.
>>
>> Yes, this is a wrapper for a type of clock. I think it would be
>> better in its own file, rather than embedded in clk-mt8173.c, which is
>> more about enumerating and initializing the clock tree.
>>
>> Perhaps today it is only used for mt8173, but that may not be the case
>> in the future.
>
> OK, I'll separate it from clk-mt8173.c.
>
> Ref2usb_tx's control register is located in APMIXEDSYS, which contains
> most of PLL controlling. Is this clock suitable to implemented
> mtk-pll.c? Or it's proper to be a separated file such as clk-usb.c?
I think a separate clk-usb.c might be better since the driver is very
different than what is used for the PLLs.
Thanks!
-Dan
> Best regards,
>
> James
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173
Hi Chunfeng,
On Wed, Jul 8, 2015 at 5:41 PM, Chunfeng Yun wrote:
> Signed-off-by: Chunfeng Yun
> ---
> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 15 +++
> arch/arm64/boot/dts/mediatek/mt8173.dtsi| 27 +++
> 2 files changed, 42 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index f433c21..cb63dc3 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -13,6 +13,7 @@
> */
>
> /dts-v1/;
> +#include
> #include "mt8173.dtsi"
>
> / {
> @@ -32,6 +33,15 @@
> };
>
> chosen { };
> +
> + usb_p1_vbus: fixedregulator@0 {
Why @0 ?
> + compatible = "regulator-fixed";
> + regulator-name = "usb_vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> };
>
> &pwrap {
> @@ -211,3 +221,8 @@
> &uart0 {
> status = "okay";
> };
> +
> +&usb {
> + reg-vusb33-supply = <&mt6397_vusb_reg>;
> + reg-vbus-supply = <&usb_p1_vbus>;
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 0696f8f..452bd0a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
Sort alphabetically, so:
power before reset
> #include "mt8173-pinfunc.h"
>
> / {
> @@ -393,6 +394,32 @@
> #size-cells = <0>;
> status = "disabled";
> };
> +
> + usb: usb30@1127 {
> + compatible = "mediatek,mt8173-xhci";
> + reg = <0 0x1127 0 0x1000>;
> + interrupts = ;
> + usb-phy = <&u3phy>;
> + usb3-lpm-capable;
> + clocks = <&topckgen CLK_TOP_USB30_SEL>;
> + clock-names = "sys_mac";
> + };
> +
> + u3phy: usb-phy@11271000 {
> + compatible = "mediatek,mt8173-u3phy";
> + reg = <0 0x11271000 0 0x3000>,
> + <0 0x1128 0 0x2>;
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
> + usb-wakeup-ctrl = <&pericfg>;
> + wakeup-src = <1>;
> + u2port-num = <2>;
Mediatek specific properties should be prefixed with "mediatek,".
I also find it nicer if you put the standard properties first:
(compatible, reg, clocks, clock-names, power-domains)
then device specific properties:
(usb-wakeup-ctrl, wakeup-src, u2port-num)
and then the final:
status="disabled";
This last is currently missing, so please add it, too.
Also, is there some pinctrl settings that must be set for USB?
Lastly, I could not quite figure out which patch this set was based on.
Patch [0] mentions v4.2-rc1, however, the .dts changes in this patch
did not apply cleanly.
Perhaps it was based on a particular patch of Matthias tree?
Thanks!
-Dan
> + clocks = <&pericfg CLK_PERI_USB0>,
> +<&pericfg CLK_PERI_USB1>,
> +<&apmixedsys CLK_APMIXED_REF2USB_TX>;
> + clock-names = "wakeup_deb_p0",
> + "wakeup_deb_p1",
> + "u3phya_ref";
> + };
> };
> };
>
> --
> 1.8.1.1.dirty
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] clk: mediatek: Export CPU mux clocks for CPU frequency control
> +{
> + int i;
> + struct clk *clk;
> + struct regmap *regmap;
> +
> + regmap = syscon_node_to_regmap(node);
> + if (IS_ERR(regmap)) {
> + pr_err("Cannot find regmap for %s: %d\n", node->full_name,
> + PTR_ERR(regmap));
> + return PTR_ERR(regmap);
> + }
> +
> + for (i = 0; i < num; i++) {
> + const struct mtk_composite *mux = &clks[i];
> +
> + clk = mtk_clk_register_cpumux(mux, regmap);
> + if (IS_ERR(clk)) {
> + pr_err("Failed to register clk %s: %ld\n",
> + mux->name, PTR_ERR(clk));
> + continue;
> + }
> +
> + clk_data->clks[mux->id] = clk;
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/clk/mediatek/clk-cpumux.h
> b/drivers/clk/mediatek/clk-cpumux.h
> new file mode 100644
> index 000..dddaad5
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-cpumux.h
> @@ -0,0 +1,30 @@
> +/*
> + * Copyright (c) 2015 Linaro Ltd.
> + * Author: Pi-Cheng Chen
> + *
> + * 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.
> + */
> +
> +#ifndef __DRV_CLK_CPUMUX_H
> +#define __DRV_CLK_CPUMUX_H
> +
> +struct mtk_clk_cpumux {
> + struct clk_hw hw;
> + struct regmap *regmap;
> + u32 reg;
> + u32 mask;
> + u8 shift;
> +};
The struct definition can move inside clk-cpumux.c
> +
> +int mtk_clk_register_cpumuxes(struct device_node *node,
> + const struct mtk_composite *clks, int num,
> + struct clk_onecell_data *clk_data);
> +
> +#endif /* __DRV_CLK_CPUMUX_H */
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c
> index 4b9e04c..d14183b 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -19,6 +19,7 @@
>
> #include "clk-mtk.h"
> #include "clk-gate.h"
> +#include "clk-cpumux.h"
>
> #include
>
> @@ -517,6 +518,25 @@ static const char * const i2s3_b_ck_parents[]
> __initconst = {
> "apll2_div5"
> };
>
> +static const char * const ca53_parents[] __initconst = {
> + "clk26m",
> + "armca7pll",
> + "mainpll",
> + "univpll"
> +};
> +
> +static const char * const ca57_parents[] __initconst = {
> + "clk26m",
> + "armca15pll",
> + "mainpll",
> + "univpll"
> +};
> +
> +static struct mtk_composite cpu_muxes[] __initdata = {
static const struct mtk_composite cpu_muxes[] __initconst = {
With the above small fixes, this one is:
Reviewed-by: Daniel Kurtz
> + MUX(CLK_INFRA_CA53SEL, "infra_ca53_sel", ca53_parents, 0x, 0, 2),
> + MUX(CLK_INFRA_CA57SEL, "infra_ca57_sel", ca57_parents, 0x, 2, 2),
> +};
> +
> static const struct mtk_composite top_muxes[] __initconst = {
> /* CLK_CFG_0 */
> MUX(CLK_TOP_AXI_SEL, "axi_sel", axi_parents, 0x0040, 0, 3),
> @@ -738,6 +758,9 @@ static void __init mtk_infrasys_init(struct device_node
> *node)
> mtk_clk_register_gates(node, infra_clks, ARRAY_SIZE(infra_clks),
> clk_data);
>
> + mtk_clk_register_cpumuxes(node, cpu_muxes, ARRAY_SIZE(cpu_muxes),
> + clk_data);
> +
> r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> if (r)
> pr_err("%s(): could not register clock provider: %d\n",
> diff --git a/include/dt-bindings/clock/mt8173-clk.h
> b/include/dt-bindings/clock/mt8173-clk.h
> index 4ad76ed..5501cec 100644
> --- a/include/dt-bindings/clock/mt8173-clk.h
> +++ b/include/dt-bindings/clock/mt8173-clk.h
> @@ -187,7 +187,9 @@
> #define CLK_INFRA_CEC 9
> #define CLK_INFRA_PMICSPI 10
> #define CLK_INFRA_PMICWRAP 11
> -#define CLK_INFRA_NR_CLK 12
> +#define CLK_INFRA_CA53SEL 12
> +#define CLK_INFRA_CA57SEL 13
> +#define CLK_INFRA_NR_CLK 14
>
> /* PERI_SYS */
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] clocksource: mediatek: do not enable GPT_CLK_EVT when setup
Hi Yingjoe,
On Mon, Jul 13, 2015 at 5:32 PM, Yingjoe Chen wrote:
> Spurious mtk timer interrupt is noticed at boot and cause kernel
> crash. It seems if GPT is enabled, it will latch irq status even
> when its IRQ is disabled. When irq is enabled afterward, we see
> spurious interrupt.
> Change init flow to only enable GPT_CLK_SRC at mtk_timer_init.
>
> Signed-off-by: Yingjoe Chen
> ---
> drivers/clocksource/mtk_timer.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
> index 68ab423..237c20b 100644
> --- a/drivers/clocksource/mtk_timer.c
> +++ b/drivers/clocksource/mtk_timer.c
> @@ -156,9 +156,11 @@ static void mtk_timer_global_reset(struct
> mtk_clock_event_device *evt)
> writel(0x3f, evt->gpt_base + GPT_IRQ_ACK_REG);
> }
>
> -static void
> -mtk_timer_setup(struct mtk_clock_event_device *evt, u8 timer, u8 option)
> +static void mtk_timer_setup(struct mtk_clock_event_device *evt, u8 timer,
> + u8 option, bool enable)
This function can be: __init
Other than this tiny nit, and the small potential conflict in patch 4,
this whole series is:
Reviewed-by: Daniel Kurtz
(I do think it is a bit strange that the mediatek,mt6577-timer binding
does not use "clock-names", but that is independent of this patch
set).
Thanks!
> {
> + u32 val;
> +
> writel(TIMER_CTRL_CLEAR | TIMER_CTRL_DISABLE,
> evt->gpt_base + TIMER_CTRL_REG(timer));
>
> @@ -167,8 +169,10 @@ mtk_timer_setup(struct mtk_clock_event_device *evt, u8
> timer, u8 option)
>
> writel(0x0, evt->gpt_base + TIMER_CMP_REG(timer));
>
> - writel(TIMER_CTRL_OP(option) | TIMER_CTRL_ENABLE,
> - evt->gpt_base + TIMER_CTRL_REG(timer));
> + val = TIMER_CTRL_OP(option);
> + if (enable)
> + val |= TIMER_CTRL_ENABLE;
> + writel(val, evt->gpt_base + TIMER_CTRL_REG(timer));
> }
>
> static void mtk_timer_enable_irq(struct mtk_clock_event_device *evt, u8
> timer)
> @@ -235,12 +239,12 @@ static void __init mtk_timer_init(struct device_node
> *node)
> evt->ticks_per_jiffy = DIV_ROUND_UP(rate, HZ);
>
> /* Configure clock source */
> - mtk_timer_setup(evt, GPT_CLK_SRC, TIMER_CTRL_OP_FREERUN);
> + mtk_timer_setup(evt, GPT_CLK_SRC, TIMER_CTRL_OP_FREERUN, true);
> clocksource_mmio_init(evt->gpt_base + TIMER_CNT_REG(GPT_CLK_SRC),
> node->name, rate, 300, 32, clocksource_mmio_readl_up);
>
> /* Configure clock event */
> - mtk_timer_setup(evt, GPT_CLK_EVT, TIMER_CTRL_OP_REPEAT);
> + mtk_timer_setup(evt, GPT_CLK_EVT, TIMER_CTRL_OP_REPEAT, false);
> clockevents_config_and_register(&evt->dev, rate, 0x3,
> 0x);
>
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] clk: mediatek: add 13mhz clock for MT8173
On Mon, Jul 13, 2015 at 5:32 PM, Yingjoe Chen wrote:
> Add 13mhz clock used by GPT timer in infracfg.
>
> Signed-off-by: Yingjoe Chen
> ---
> drivers/clk/mediatek/clk-mt8173.c | 5 +
> include/dt-bindings/clock/mt8173-clk.h | 3 ++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c
> index 4b9e04c..540c5c3 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -618,6 +618,10 @@ static const struct mtk_gate infra_clks[] __initconst = {
> GATE_ICG(CLK_INFRA_PMICWRAP, "infra_pmicwrap", "axi_sel", 23),
> };
>
> +static const struct mtk_fixed_factor infra_divs[] __initconst = {
> + FACTOR(CLK_INFRA_CLK_13M, "clk13m", "clk26m", 1, 2),
> +};
> +
> static const struct mtk_gate_regs peri0_cg_regs = {
> .set_ofs = 0x0008,
> .clr_ofs = 0x0010,
> @@ -737,6 +741,7 @@ static void __init mtk_infrasys_init(struct device_node
> *node)
>
> mtk_clk_register_gates(node, infra_clks, ARRAY_SIZE(infra_clks),
> clk_data);
> + mtk_clk_register_factors(infra_divs, ARRAY_SIZE(infra_divs),
> clk_data);
>
> r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> if (r)
> diff --git a/include/dt-bindings/clock/mt8173-clk.h
> b/include/dt-bindings/clock/mt8173-clk.h
> index 4ad76ed..fa2a2bb 100644
> --- a/include/dt-bindings/clock/mt8173-clk.h
> +++ b/include/dt-bindings/clock/mt8173-clk.h
> @@ -187,7 +187,8 @@
> #define CLK_INFRA_CEC 9
> #define CLK_INFRA_PMICSPI 10
> #define CLK_INFRA_PMICWRAP 11
> -#define CLK_INFRA_NR_CLK 12
> +#define CLK_INFRA_CLK_13M 12
> +#define CLK_INFRA_NR_CLK 13
Note: this one conflicts slightly with pi-cheng's patch that adds CPU
mux clocks for cpufreq driver, since they both add more INFRA clocks:
https://patchwork.kernel.org/patch/6721511/
>
> /* PERI_SYS */
>
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/1] drivers: cpuidle: cpuidle-arm: heterogeneous systems extension
Hi Lorenzo,
On Tue, May 12, 2015 at 9:03 PM, Lorenzo Pieralisi
wrote:
> On Tue, May 05, 2015 at 04:56:15PM +0100, Lorenzo Pieralisi wrote:
>> On Mon, May 04, 2015 at 02:19:15PM +0100, Daniel Lezcano wrote:
>> > On 04/16/2015 06:10 PM, Lorenzo Pieralisi wrote:
>>
>>
>>
>> > > /*
>> > > - * arm_idle_init
>> > > + * Compare idle states phandle properties
>> > >*
>> > > - * Registers the arm specific cpuidle driver with the cpuidle
>> > > - * framework. It relies on core code to parse the idle states
>> > > - * and initialize them using driver data structures accordingly.
>> > > + * Return true if properties are valid and equal, false otherwise
>> >
>> > Just a detail. Would be more consistent to return zero when valid and
>> > equal ?
>>
>> Consistent with memcmp you mean ? Yes, I can change it.
>>
>> > >*/
>> > > -static int __init arm_idle_init(void)
>> > > +static bool __init idle_states_cmp(struct property *states1,
>> > > +struct property *states2)
>> > > +{
>> > > + /*
>> > > + * NB: Implemented through code from drivers/of/unittest.c
>> > > + * Function is generic and can be moved to generic OF code
>> > > + * if needed
>> > > + */
>> > > + return states1 && states2 &&
>> > > +(states1->length == states2->length) &&
>> > > +states1->value && states2->value &&
>> > > +!memcmp(states1->value, states2->value, states1->length);
>> > > +}
>> > > +
>> > > +static int __init arm_idle_init_driver(struct cpuidle_driver *drv)
>> > > {
>> > > - int cpu, ret;
>> > > - struct cpuidle_driver *drv = &arm_idle_driver;
>> > > + int ret, cpu;
>> > > struct cpuidle_device *dev;
>> > > + struct property *curr_idle_states, *idle_states = NULL;
>> > > + struct device_node *cpu_node;
>> > > +
>> > > + for_each_cpu(cpu, drv->cpumask) {
>> > > + cpu_node = of_cpu_device_node_get(cpu);
>> > > + curr_idle_states = of_find_property(cpu_node,
>> > > + "cpu-idle-states",
>> > > NULL);
>> > > + of_node_put(cpu_node);
>> > > +
>> > > + /*
>> > > + * Stash the first valid idle states phandle in the
>> > > cpumask.
>> > > + * If curr_idle_states is NULL assigning it to idle_states
>> > > + * is harmless and it is managed by idle states comparison
>> > > + * code. Keep track of first valid phandle so that
>> > > + * subsequent cpus can compare against it.
>> > > + */
>> > > + if (!idle_states)
>> > > + idle_states = curr_idle_states;
>> > > +
>> > > + /*
>> > > + * If idle states phandles are not equal, remove the
>> > > + * cpu from the driver mask since a CPUidle driver
>> > > + * is only capable of managing uniform idle states.
>> > > + *
>> > > + * Comparison works also when idle_states and
>> > > + * curr_idle_states are the same property, since
>> > > + * they can be == NULL so the cpu must be removed from
>> > > + * the driver mask in that case too (ie cpu has no idle
>> > > + * states).
>> > > + */
>> > > + if (!idle_states_cmp(idle_states, curr_idle_states))
>> > > + cpumask_clear_cpu(cpu, drv->cpumask);
>> > > + }
>> > > +
>> > > + /*
>> > > + * If there are no valid states for this driver we rely on arch
>> > > + * default idle behaviour, bail out
>> > > + */
>> > > + if (!idle_states)
>> > > + return -ENODEV;
>> > >
>> > > /*
>> > >* Initialize idle states data, starting at index 1.
>> > > @@ -117,7 +173,7 @@ static int __init arm_idle_init(void)
>> > >* Call arch CPU operations in order to initialize
>> > >* idle states suspend back-end specific data
>> > >*/
>> > > - for_each_possible_cpu(cpu) {
>> > > + for_each_cpu(cpu, drv->cpumask) {
>> > > ret = arm_cpuidle_init(cpu);
>> > >
>> > > /*
>> > > @@ -157,7 +213,77 @@ out_fail:
>> > > }
>> > >
>> > > cpuidle_unregister_driver(drv);
>> > > + return ret;
>> > > +}
>> > > +
>> > > +/*
>> > > + * arm_idle_init
>> > > + *
>> > > + * Registers the arm specific cpuidle driver(s) with the cpuidle
>> > > + * framework. It relies on core code to parse the idle states
>> > > + * and initialize them using driver data structures accordingly.
>> > > + */
>> > > +static int __init arm_idle_init(void)
>> > > +{
>> > > + int i, ret = -ENODEV;
>> > > + struct cpuidle_driver *drv;
>> > > + cpumask_var_t tmpmask;
>> > > +
>> > > + /*
>> > > + * These drivers require DT idle states to be present.
>> > > + * If no idle states are detected there is no reason to
>> > > + * proceed any further hence we return early.
>>
Re: [PATCH 5/5] arm64: dts: mt8173: add timer node
On Tue, Jul 14, 2015 at 12:26 PM, Daniel Kurtz wrote:
> On Mon, Jul 13, 2015 at 5:32 PM, Yingjoe Chen
> wrote:
>> From: Daniel Kurtz
>>
>> Add device node to enable GPT timer. This timer will be
>> used as sched clock source.
>>
>> Signed-off-by: Daniel Kurtz
>> Signed-off-by: Eddie Huang
>> Signed-off-by: Yingjoe Chen
>
> This binding needs documentation.
Whoops. I just found it at:
Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
>
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index 0696f8f..04bdd8f 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -219,6 +219,15 @@
>> reg = <0 0x10007000 0 0x100>;
>> };
>>
>> + timer: timer@10008000 {
>> + compatible = "mediatek,mt8173-timer",
>> +"mediatek,mt6577-timer";
>> + reg = <0 0x10008000 0 0x1000>;
>> + interrupts = ;
>> + clocks = <&infracfg CLK_INFRA_CLK_13M>,
>> +<&topckgen CLK_TOP_RTC_SEL>;
>
> Why two clocks? The driver only uses one.
> Please use a clock-names property.
>
> Thanks,
> -Dan
>
>> + };
>> +
>> pwrap: pwrap@1000d000 {
>> compatible = "mediatek,mt8173-pwrap";
>> reg = <0 0x1000d000 0 0x1000>;
>> --
>> 1.8.1.1.dirty
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] arm64: dts: mt8173: add timer node
On Mon, Jul 13, 2015 at 5:32 PM, Yingjoe Chen wrote:
> From: Daniel Kurtz
>
> Add device node to enable GPT timer. This timer will be
> used as sched clock source.
>
> Signed-off-by: Daniel Kurtz
> Signed-off-by: Eddie Huang
> Signed-off-by: Yingjoe Chen
This binding needs documentation.
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 0696f8f..04bdd8f 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -219,6 +219,15 @@
> reg = <0 0x10007000 0 0x100>;
> };
>
> + timer: timer@10008000 {
> + compatible = "mediatek,mt8173-timer",
> +"mediatek,mt6577-timer";
> + reg = <0 0x10008000 0 0x1000>;
> + interrupts = ;
> + clocks = <&infracfg CLK_INFRA_CLK_13M>,
> +<&topckgen CLK_TOP_RTC_SEL>;
Why two clocks? The driver only uses one.
Please use a clock-names property.
Thanks,
-Dan
> + };
> +
> pwrap: pwrap@1000d000 {
> compatible = "mediatek,mt8173-pwrap";
> reg = <0 0x1000d000 0 0x1000>;
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
On Tue, Jul 14, 2015 at 10:45 AM, James Liao wrote:
> Hi Daniel,
>
> On Mon, 2015-07-13 at 22:46 +0800, Daniel Kurtz wrote:
>
>> > +static const struct clk_ops mtk_ref2usb_tx_ops = {
>> > + .is_prepared= mtk_ref2usb_tx_is_prepared,
>> > + .prepare= mtk_ref2usb_tx_prepare,
>> > + .unprepare = mtk_ref2usb_tx_unprepare,
>> > +};
>>
>> Burying the implementation of this special "mtk_ref2usb" clock in
>> clk-mt8173,c seems a bit awkward.
>> Can you please move it to its own file, like mediatek/clk-usb.c?
>
> Do you mean clk/mediatek/clk-usb.c?
>
> This clock is a MT8173 specific clock, which may not be reused by other
> SoCs. So I think it's not necessary to move it to a separated file.
Yes, this is a wrapper for a type of clock. I think it would be
better in its own file, rather than embedded in clk-mt8173.c, which is
more about enumerating and initializing the clock tree.
Perhaps today it is only used for mt8173, but that may not be the case
in the future.
-Dan
>
>> > +
>> > +static struct clk *mtk_clk_register_ref2usb_tx(const char *name,
>> > + const char *parent_name, void __iomem *reg)
>> > +{
>> > + struct mtk_ref2usb_tx *tx;
>> > + struct clk_init_data init = {};
>> > + struct clk *clk;
>> > +
>> > + tx = kzalloc(sizeof(*tx), GFP_KERNEL);
>> > + if (!tx)
>> > + return ERR_PTR(-ENOMEM);
>> > +
>> > + tx->base_addr = reg;
>> > + tx->hw.init = &init;
>> > +
>> > + init.name = name;
>> > + init.ops = &mtk_ref2usb_tx_ops;
>> > + init.parent_names = &parent_name;
>> > + init.num_parents = 1;
>> > +
>> > + clk = clk_register(NULL, &tx->hw);
>> > +
>> > + if (IS_ERR(clk)) {
>> > + pr_err("Failed to register clk %s: %ld\n", name,
>> > PTR_ERR(clk));
>> > + kfree(tx);
>> > + }
>> > +
>> > + return clk;
>> > +}
>> > +
>> > +struct mtk_apmixed_ex {
>> > + int id;
>> > + const char *name;
>> > + const char *parent;
>> > + u32 reg_ofs;
>> > +};
>> > +
>> > +#define APMIXED_EX(_id, _name, _parent, _reg_ofs) {\
>> > + .id = _id, \
>> > + .name = _name, \
>> > + .parent = _parent, \
>> > + .reg_ofs = _reg_ofs,\
>> > + }
>> > +
>> > +static const struct mtk_apmixed_ex apmixed_ex[] = {
>>
>> __initconst
>
> OK. I'll fix it in next patch.
>
>> > + APMIXED_EX(CLK_APMIXED_REF2USB_TX, "ref2usb_tx", "clk26m", 0x8),
>> > +};
>> > +
>> > +static void __init mtk_clk_register_apmixedsys_special(struct device_node
>> > *node,
>> > + struct clk_onecell_data *clk_data)
>> > +{
>> > + void __iomem *base;
>> > + struct clk *clk;
>> > + int i;
>> > +
>> > + base = of_iomap(node, 0);
>> > + if (!base) {
>> > + pr_err("%s(): ioremap failed\n", __func__);
>> > + return;
>> > + }
>> > +
>> > + for (i = 0; i < ARRAY_SIZE(apmixed_ex); i++) {
>> > + const struct mtk_apmixed_ex *ape = &apmixed_ex[i];
>> > +
>> > + clk = mtk_clk_register_ref2usb_tx(ape->name, ape->parent,
>> > + base +
>> > ape->reg_ofs);
>> > +
>> > + if (IS_ERR(clk)) {
>> > + pr_err("Failed to register clk %s: %ld\n",
>> > ape->name,
>> > + PTR_ERR(clk));
>> > + continue;
>> > + }
>> > +
>> > + clk_data->clks[CLK_APMIXED_REF2USB_TX] = clk;
>>
>> This works assuming ARRAY_SIZE(apmixed_ex) == 1.
>> Either remove the loop since it is unnecessary, or do:
>> clk_data->clks[ape->id] = clk;
>
> It should be "clk_data->clks[ape->id] = clk". I'll fix it in next patch.
>
>
> Best regards,
>
> James
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
Hi James,
On Fri, Jul 10, 2015 at 6:00 PM, James Liao wrote:
> Add REF2USB_TX clock support into MT8173 APMIXEDSYS. This clock
> is needed by USB 3.0.
>
> Signed-off-by: James Liao
> ---
> drivers/clk/mediatek/clk-mt8173.c | 143
> +
> drivers/clk/mediatek/clk-pll.c | 7 +-
> include/dt-bindings/clock/mt8173-clk.h | 3 +-
> 3 files changed, 146 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c
> index 1d21e26..11f82cb 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -12,6 +12,7 @@
> * GNU General Public License for more details.
> */
>
> +#include
> #include
> #include
> #include
> @@ -968,6 +969,141 @@ static void __init mtk_pericfg_init(struct device_node
> *node)
> }
> CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt8173-pericfg", mtk_pericfg_init);
>
> +#define REF2USB_TX_EN BIT(0)
> +#define REF2USB_TX_LPF_EN BIT(1)
> +#define REF2USB_TX_OUT_EN BIT(2)
> +#define REF2USB_EN_MASK(REF2USB_TX_EN | REF2USB_TX_LPF_EN | \
> +REF2USB_TX_OUT_EN)
> +
> +struct mtk_ref2usb_tx {
> + struct clk_hw hw;
> + void __iomem*base_addr;
> +};
> +
> +static inline struct mtk_ref2usb_tx *to_mtk_ref2usb_tx(struct clk_hw *hw)
> +{
> + return container_of(hw, struct mtk_ref2usb_tx, hw);
> +}
> +
> +static int mtk_ref2usb_tx_is_prepared(struct clk_hw *hw)
> +{
> + struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
> +
> + return (readl(tx->base_addr) & REF2USB_EN_MASK) == REF2USB_EN_MASK;
> +}
> +
> +static int mtk_ref2usb_tx_prepare(struct clk_hw *hw)
> +{
> + struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
> + u32 val;
> +
> + val = readl(tx->base_addr);
> +
> + val |= REF2USB_TX_EN;
> + writel(val, tx->base_addr);
> + udelay(100);
> +
> + val |= REF2USB_TX_LPF_EN;
> + writel(val, tx->base_addr);
> +
> + val |= REF2USB_TX_OUT_EN;
> + writel(val, tx->base_addr);
> +
> + return 0;
> +}
> +
> +static void mtk_ref2usb_tx_unprepare(struct clk_hw *hw)
> +{
> + struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
> + u32 val;
> +
> + val = readl(tx->base_addr);
> + val &= ~REF2USB_EN_MASK;
> + writel(val, tx->base_addr);
> +}
> +
> +static const struct clk_ops mtk_ref2usb_tx_ops = {
> + .is_prepared= mtk_ref2usb_tx_is_prepared,
> + .prepare= mtk_ref2usb_tx_prepare,
> + .unprepare = mtk_ref2usb_tx_unprepare,
> +};
Burying the implementation of this special "mtk_ref2usb" clock in
clk-mt8173,c seems a bit awkward.
Can you please move it to its own file, like mediatek/clk-usb.c?
> +
> +static struct clk *mtk_clk_register_ref2usb_tx(const char *name,
> + const char *parent_name, void __iomem *reg)
> +{
> + struct mtk_ref2usb_tx *tx;
> + struct clk_init_data init = {};
> + struct clk *clk;
> +
> + tx = kzalloc(sizeof(*tx), GFP_KERNEL);
> + if (!tx)
> + return ERR_PTR(-ENOMEM);
> +
> + tx->base_addr = reg;
> + tx->hw.init = &init;
> +
> + init.name = name;
> + init.ops = &mtk_ref2usb_tx_ops;
> + init.parent_names = &parent_name;
> + init.num_parents = 1;
> +
> + clk = clk_register(NULL, &tx->hw);
> +
> + if (IS_ERR(clk)) {
> + pr_err("Failed to register clk %s: %ld\n", name,
> PTR_ERR(clk));
> + kfree(tx);
> + }
> +
> + return clk;
> +}
> +
> +struct mtk_apmixed_ex {
> + int id;
> + const char *name;
> + const char *parent;
> + u32 reg_ofs;
> +};
> +
> +#define APMIXED_EX(_id, _name, _parent, _reg_ofs) {\
> + .id = _id, \
> + .name = _name, \
> + .parent = _parent, \
> + .reg_ofs = _reg_ofs,\
> + }
> +
> +static const struct mtk_apmixed_ex apmixed_ex[] = {
__initconst
> + APMIXED_EX(CLK_APMIXED_REF2USB_TX, "ref2usb_tx", "clk26m", 0x8),
> +};
> +
> +static void __init mtk_clk_register_apmixedsys_special(struct device_node
> *node,
> + struct clk_onecell_data *clk_data)
> +{
> + void __iomem *base;
> + struct clk *clk;
> + int i;
> +
> + base = of_iomap(node, 0);
> + if (!base) {
> + pr_err("%s(): ioremap failed\n", __func__);
> + return;
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(apmixed_ex); i++) {
> + const struct mtk_apmixed_ex *ape = &apmixed_ex[i];
> +
> + clk = mtk_clk_register_ref2usb_tx(ape->name, ape->parent,
> + base + ape->reg_ofs);
Re: [PATCH v5 1/3] dt-bindings: pwm: add MediaTek display PWM bindings
On Mon, Jul 13, 2015 at 5:04 PM, YH Huang wrote:
> Document the device-tree binding of MediatTek display PWM.
> The PWM has one channel to control the backlight brightness for display.
> It supports MT8173 and MT6595.
>
> Signed-off-by: YH Huang
> ---
> .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 29
> ++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> new file mode 100644
> index 000..aac29dc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> @@ -0,0 +1,29 @@
> +MediaTek display PWM controller
> +
> +Required properties:
> + - compatible: should be "mediatek,-disp-pwm":
> + - "mediatek,mt8173-disp-pwm": found on mt8173 SoC.
> + - "mediatek,mt6595-disp-pwm": found on mt6595 SoC.
> + - reg: physical base address and length of the controller's registers.
> + - #pwm-cells: must be 2. See pwm.txt in this directory for a description of
> + the cell format.
> + - clocks: phandle and clock specifier of the PWM reference clock.
> + - clock-names: must contain the following:
> + - "main": clock used to generate PWM signals.
> + - "mm": sync signals from the modules of mmsys.
> + - pinctrl-names: Must contain a "default" entry.
> + - pinctrl-0: One property must exist for each entry in pinctrl-names.
> + See pinctrl/pinctrl-bindings.txt for details of the property values.
> +
> +Example:
> + pwm0: pwm@1401e000 {
> + compatible = "mediatek,mt8173-disp-pwm",
> +"mediatek,mt6595-disp-pwm";
> + reg = <0 0x1401e000 0 0x1000>;
> + #pwm-cells = <2>;
> + clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> +<&mmsys CLK_MM_DISP_PWM0MM>;
> + clock-names = "main", "mm";
> + pinctrl-names = "default";
> + pinctrl-0 = <&disp_pwm0_pins>;
> + };
Please show an example consumer of the pwm phandle to show how to set
the two properties required by the #pwm-cells.
Although the pwm-specifier typically encodes the chip-relative PWM
number and the PWM period in nanoseconds, it is technically controller
specific.
In fact, since the mtk-disp-pwm does not have a chip-relative PWM
number, could we in fact set #pwm-cells = <1>, and only specify the
requested PWM period?
-Dan
> --
> 1.8.1.1.dirty
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/3] pwm: add MediaTek display PWM driver support
On Mon, Jul 13, 2015 at 5:04 PM, YH Huang wrote:
> Add display PWM driver support to modify backlight for MT8173 and MT6595.
> The PWM has one channel to control the brightness of the display.
> When the (high_width / period) is closer to 1, the screen is brighter;
> otherwise, it is darker.
>
> Signed-off-by: YH Huang
> ---
> drivers/pwm/Kconfig| 10 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-mtk-disp.c | 256
> +
> 3 files changed, 267 insertions(+)
> create mode 100644 drivers/pwm/pwm-mtk-disp.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index b1541f4..f5b03a4 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -211,6 +211,16 @@ config PWM_LPSS_PLATFORM
> To compile this driver as a module, choose M here: the module
> will be called pwm-lpss-platform.
>
> +config PWM_MTK_DISP
> + tristate "MediaTek display PWM driver"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + help
> + Generic PWM framework driver for MediaTek disp-pwm device.
> + The PWM is used to control the backlight brightness for display.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-mtk-disp.
> +
> config PWM_MXS
> tristate "Freescale MXS PWM support"
> depends on ARCH_MXS && OF
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index ec50eb5..99c9e75 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
> obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o
> obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o
> obj-$(CONFIG_PWM_LPSS_PLATFORM)+= pwm-lpss-platform.o
> +obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o
> obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
> obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
> obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
> diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
> new file mode 100644
> index 000..1f17cee
> --- /dev/null
> +++ b/drivers/pwm/pwm-mtk-disp.c
> @@ -0,0 +1,256 @@
> +/*
> + * MediaTek display pulse-width-modulation controller driver.
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: YH Huang
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DISP_PWM_EN0
The "DISP_PWM_*" are register offsets, so use a hex value, like this:
#define DISP_PWM_EN 0x00
Use BIT() for register *fields*, that is, the individual bits of a register.
> +#define PWM_ENABLE_MASKBIT(0)
> +
> +#define DISP_PWM_COMMITBIT(3)
#define DISP_PWM_COMMIT0x08
> +#define PWM_COMMIT_MASKBIT(0)
> +
> +#define DISP_PWM_CON_0 BIT(4)
#define DISP_PWM_COMMIT0x10
> +#define PWM_CLKDIV_SHIFT 16
> +#define PWM_CLKDIV_MAX 0x3ff
> +#define PWM_CLKDIV_MASK(PWM_CLKDIV_MAX << PWM_CLKDIV_SHIFT)
> +
> +#define DISP_PWM_CON_1 0x14
> +#define PWM_PERIOD_MASK0xfff
> +/* Shift log2(PWM_PERIOD_MASK + 1) as divisor */
> +#define PWM_PERIOD_BIT_SHIFT 12
> +
> +#define PWM_HIGH_WIDTH_SHIFT 16
> +#define PWM_HIGH_WIDTH_MASK(0x1fff << PWM_HIGH_WIDTH_SHIFT)
> +
> +struct mtk_disp_pwm {
> + struct pwm_chip chip;
> + struct device *dev;
I don't think "dev" is actually used. And, if needed, it can be
extracted from "chip".
> + struct clk *clk_main;
> + struct clk *clk_mm;
> + void __iomem *base;
> +};
> +
> +static inline struct mtk_disp_pwm *to_mtk_disp_pwm(struct pwm_chip *chip)
> +{
> + return container_of(chip, struct mtk_disp_pwm, chip);
> +}
> +
> +static void mtk_disp_pwm_update_bits(void __iomem *address, u32 mask, u32
> value)
Take "struct mtk_disp_pwm *mdp" as a param and extract mdp->base,
rather than pass the raw iomem address.
> +{
> + u32 val;
> +
> + val = readl(address);
> + val &= ~mask;
> + val |= value;
> + writel(val, address);
> +}
> +
> +static int mtk_disp_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> + int duty_ns, int period_ns)
> +{
> + struct mtk_disp_pwm *mdp = to_mtk_disp_pwm(chip);
> + u64 div, rate;
> + u32 clk_div, period, high_width, value;
> +
> + /*
> +* Find period, high_width and clk_div to suit duty_ns and
Re: [PATCH 2/4] dt-bindings: soc: Add documentation for the MediaTek SCPSYS unit
On Wed, Jun 24, 2015 at 2:17 PM, Sascha Hauer wrote:
> This adds documentation for the MediaTek SCPSYS unit found in MT8173 SoCs.
>
> Signed-off-by: Sascha Hauer
> ---
> .../devicetree/bindings/soc/mediatek/scpsys.txt| 41
> ++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> new file mode 100644
> index 000..c051114
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
> @@ -0,0 +1,41 @@
> +MediaTek SCPSYS
> +===
> +
> +The System Control Processor System (SCPSYS) has several power management
> +related tasks in the system. The tasks include thermal measurement, dynamic
> +voltage frequency scaling (DVFS), interrupt filter and lowlevel sleep
> control.
> +The System Power Manager (SPM) inside the SCPSYS is for the MTCMOS power
> +domain control.
> +
> +The driver implements the Generic PM domain bindings described in
> +power/power_domain.txt. It provides the power domains defined in
> +include/dt-bindings/power/mt8173-power.h.
> +
> +Required properties:
> +- compatible: Must be "mediatek,mt8173-scpsys"
> +- #power-domain-cells: Must be 1
> +- reg: Address range of the SCPSYS unit
> +- infracfg: must contain a phandle to the infracfg controller
> +- clock, clock-names: clocks according to the common clock binding.
> + The clocks needed "mm" and "mfg". These are the
> + clocks which hardware needs to be enabled before
> + enabling certain power domains.
> +
> +Example:
> +
> + scpsys: scpsys@10006000 {
Perhaps it is too late, and/or too pedantic, but, since this node
defines a PM domain provider as defined in [0], shouldn't its node
have been the more generic:
scpsys: power-controller@10006000
[0] /Documentation/devicetree/bindings/power/power_domain.txt
> + #power-domain-cells = <1>;
> + compatible = "mediatek,mt8173-scpsys";
> + reg = <0 0x10006000 0 0x1000>;
> + infracfg = <&infracfg>;
> + clocks = <&clk26m>,
> +<&topckgen CLK_TOP_MM_SEL>;
> + clock-names = "mfg", "mm";
> + };
> +
> +Example consumer:
> +
> + afe: mt8173-afe-pcm@1122 {
> + compatible = "mediatek,mt8173-afe-pcm";
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_AUDIO>;
> + };
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Add clk_null to be the dummy root of MT8173 clocks
On Fri, Jul 10, 2015 at 5:16 PM, James Liao wrote: > This patchset is based on 4.2-rc1 and adds a dummy clock "clk_null" > to be the root clock of clocks whose parents are not contained in > CCF clock tree. > > In previous patch [1], it seems not suitable to declare clk_null in > device tree because it's not a clock comes form outside of SoC. So we > move clk_null into clock driver. NAK. I still do not see why we need to introduce clk_null. Just model the real clock tree. Every clock listed with "clk_null" as its parent actually has a real parent clock. As mentioned elsewhere, it is not enough to just enable/disable a clock gate. Clock enables/disables propagate up to parent clocks, and ensure that parents themselves are enabled when any child is enabled, and disabled when all of its children are disabled. So, we must properly configure each clock's parent to ensure that its parent will be enabled when needed, and that it can be disabled to save power when no longer required. Creating a bogus clk_null breaks the clock tree model, potentially causing real issues when enabling/disabling clocks. Please ask your hardware team to specify the real parent clock for each of the clocks below so we can model the clock tree accurately. In addition, these four need not be defined at all. We can just use their parent clocks directly. As Sascha eloquently put it: "There's no need to model pieces of wire in CCF." FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1), FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1), FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1), FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1), For these "clk_null as parent" gate clocks, please specify their real parent clock: GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15), GATE_MM1(CLK_MM_DSI0_DIGITAL, "mm_dsi0_digital", "clk_null", 5), GATE_MM1(CLK_MM_DSI1_DIGITAL, "mm_dsi1_digital", "clk_null", 7), GATE_MM1(CLK_MM_DPI1_PIXEL, "mm_dpi1_pixel", "clk_null", 10), GATE_MM1(CLK_MM_LVDS_PIXEL, "mm_lvds_pixel", "clk_null", 16), GATE_MM1(CLK_MM_LVDS_CTS, "mm_lvds_cts", "clk_null", 17), Thanks, -Dan > [1] https://lkml.org/lkml/2015/6/18/24 > > James Liao (2): > clk: mediatek: Add root clocks support for Mediatek SoC. > clk: mediatek: Add clk_null to be the dummy root clock for MT8173 > > drivers/clk/mediatek/clk-mt8173.c | 5 + > drivers/clk/mediatek/clk-mtk.c | 23 +++ > drivers/clk/mediatek/clk-mtk.h | 17 - > include/dt-bindings/clock/mt8173-clk.h | 1 + > 4 files changed, 45 insertions(+), 1 deletion(-) > > -- > 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Fri, Jul 10, 2015 at 3:27 PM, Eddie Huang wrote:
> Hi all,
>
> On Wed, 2015-07-08 at 13:44 +0800, Sascha Hauer wrote:
>> On Wed, Jul 08, 2015 at 10:37:21AM +0800, Eddie Huang wrote:
>> > On Tue, 2015-07-07 at 23:10 +0800, Daniel Kurtz wrote:
>> > > On Tue, Jul 7, 2015 at 10:36 PM, Sascha Hauer
>> > > wrote:
>> > > > On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote:
>> > > >> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer
>> > > >> wrote:
>> > > >> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
>> > > >> >> Add clk_null, which represents clocks that can not / need not
>> > > >> >> controlled by software.
>> > > >> >> There are many clocks' parent set to clk_null.
>> > > >> >>
>> > > >> >> Signed-off-by: James Liao
>> > > >> >> Signed-off-by: Eddie Huang
>> > > >> >> ---
>> > > >> >> Base on 4.1-rc1
>> > > >> >>
>> > > >> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
>> > > >> >> ---
>> > > >> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
>> > > >> >> 1 file changed, 6 insertions(+)
>> > > >> >>
>> > > >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> > > >> >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> > > >> >> index 924fdb6..4798f44 100644
>> > > >> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> > > >> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> > > >> >> @@ -81,6 +81,12 @@
>> > > >> >> cpu_on= <0x8403>;
>> > > >> >> };
>> > > >> >>
>> > > >> >> + clk_null: clk_null {
>> > > >> >> + compatible = "fixed-clock";
>> > > >> >> + clock-frequency = <0>;
>> > > >> >> + #clock-cells = <0>;
>> > > >> >> + };
>> > > >> >
>> > > >> > The discussion around this patch shows that we don't want to have
>> > > >> > this
>> > > >> > clock in the device tree as it is not a hardware description.
>> > > >> >
>> > > >> > Ok, fine. Eddie, you told us that the rate of the current clk_null
>> > > >> > children
>> > > >> > is not interesting. What's the motivation to send this patch anyway
>> > > >> > then? Why can't you keep its children on the orphan list where they
>> > > >> > are
>> > > >> > already now?
>> > > >> >
>> > > >> > Another possibility would be to instantiate the clk_null clock from
>> > > >> > C
>> > > >> > code rather than from the device tree. This way we wouldn't put any
>> > > >> > wrong descriptions into the device tree and still can implement the
>> > > >> > support for the real parent clocks when we actually need them.
>> > > >>
>> > > >> Some device nodes, like mmc, use a clk_null phandle as one of their
>> > > >> clocks:
>> > > >>
>> > > >> mmc1: mmc@1124 {
>> > > >> compatible = "mediatek,mt8173-mmc",
>> > > >> "mediatek,mt8135-mmc";
>> > > >> reg = <0 0x1124 0 0x1000>;
>> > > >> interrupts = ;
>> > > >> clocks = <&pericfg CLK_PERI_MSDC30_1>,
>> > > >> <&clk_null>;
>> > > >> clock-names = "source", "hclk";
>> > > >> status = "disabled";
>> > > >> };
>> > > >
>> > > > This is another case than the one we discussed about. In the case above
>> > > > I motivated using a dummy clock since the clock exists in the system,
>> > > > but is not software controllable. To abstract this from the driver
>> > > > (which needs this clock since it exists) we here have the dummy clock.
&
Re: [PATCH v2] arm64: dts: mt8173: Add afe device node
On Thu, Jul 9, 2015 at 11:32 AM, Koro Chen wrote:
> This adds afe (audio front end) device node to the MT8173 dtsi file.
>
> Signed-off-by: Koro Chen
Reviewed-by: Daniel Kurtz
I believe this patch depends on the fix in:
https://patchwork.kernel.org/patch/6752521/
If so, I think it would have been better to upload them together and
mention the dependency in the cover letter.
However, now that they are both on the list, we just need to ensure
they are merged together.
-Dan
> ---
> This patch is based on Matthias's tree:
> https://github.com/mbgg/linux-mediatek
> branch: v4.2-next/arm64
>
> Changes since v1:
> - change node name to afe: audio-controller@1122
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 32
>
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 0696f8f..ce9255a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "mt8173-pinfunc.h"
>
> @@ -393,6 +394,37 @@
> #size-cells = <0>;
> status = "disabled";
> };
> +
> + afe: audio-controller@1122 {
> + compatible = "mediatek,mt8173-afe-pcm";
> + reg = <0 0x1122 0 0x1000>;
> + interrupts = ;
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_AUDIO>;
> + clocks = <&infracfg CLK_INFRA_AUDIO>,
> +<&topckgen CLK_TOP_AUDIO_SEL>,
> +<&topckgen CLK_TOP_AUD_INTBUS_SEL>,
> +<&topckgen CLK_TOP_APLL1_DIV0>,
> +<&topckgen CLK_TOP_APLL2_DIV0>,
> +<&topckgen CLK_TOP_I2S0_M_SEL>,
> +<&topckgen CLK_TOP_I2S1_M_SEL>,
> +<&topckgen CLK_TOP_I2S2_M_SEL>,
> +<&topckgen CLK_TOP_I2S3_M_SEL>,
> +<&topckgen CLK_TOP_I2S3_B_SEL>;
> + clock-names = "infra_sys_audio_clk",
> + "top_pdn_audio",
> + "top_pdn_aud_intbus",
> + "bck0",
> + "bck1",
> + "i2s0_m",
> + "i2s1_m",
> + "i2s2_m",
> + "i2s3_m",
> + "i2s3_b";
> + assigned-clocks = <&topckgen CLK_TOP_AUD_1_SEL>,
> + <&topckgen CLK_TOP_AUD_2_SEL>;
> + assigned-clock-parents = <&topckgen CLK_TOP_APLL1>,
> +<&topckgen CLK_TOP_APLL2>;
> + };
> };
> };
>
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] dt-bindings: pwm: add MediaTek display PWM bindings
On Thu, Jul 9, 2015 at 10:45 AM, YH Huang wrote:
>
> On Wed, 2015-07-08 at 20:11 +0800, Daniel Kurtz wrote:
> > On Mon, Jul 6, 2015 at 9:29 PM, YH Huang wrote:
> > > Document the device-tree binding of MediatTek display PWM.
> > > The PWM has one channel to control the backlight brightness for display.
> > > It supports MT8173 and MT6595.
> > >
> > > Signed-off-by: YH Huang
> > > ---
> > > .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 24
> > > ++
> > > 1 file changed, 24 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > new file mode 100644
> > > index 000..757b974
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > @@ -0,0 +1,24 @@
> > > +MediaTek display PWM controller
> > > +
> > > +Required properties:
> > > + - compatible: should be "mediatek,-disp-pwm"
> > > + - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
> > > + - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
> > > + - reg: physical base address and length of the controller's registers
> > > + - #pwm-cells: must be 2. See pwm.txt in this directory for a
> > > description of
> > > + the cell format
> > > + - clocks: phandle and clock specifier of the PWM reference clock
> > > + - clock-names: must contain the following
> > > + - "main": clock used to generate PWM signals
> > > + - "mm": sync signals from the modules of mmsys
> > > +
> > > +Example:
> > > + pwm0: pwm@1401e000 {
> > > + compatible = "mediatek,mt8173-disp-pwm",
> > > +"mediatek,mt6595-disp-pwm";
> > > + reg = <0 0x1401e000 0 0x1000>;
> > > + #pwm-cells = <2>;
> > > + clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> > > +<&mmsys CLK_MM_DISP_PWM0MM>;
> > > + clock-names = "main", "mm";
> >
> > Should we include the pinctrl settings here to enable the PWM output?
> >
>
> Since we use pwm-backlight driver to control backlight, we should enable
> PWM output in the backlight node.
>
> Ref:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>
The pwm-backlight binding specifies which pwm the backlight driver
should use, and how to use it.
I believe actually configuring the output pin for the pwm via pinctl
belongs to the pwm binding.
Regards,
0Dan
>
> Regards,
> YH Huang
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] dt-bindings: pwm: add MediaTek display PWM bindings
On Mon, Jul 6, 2015 at 9:29 PM, YH Huang wrote:
> Document the device-tree binding of MediatTek display PWM.
> The PWM has one channel to control the backlight brightness for display.
> It supports MT8173 and MT6595.
>
> Signed-off-by: YH Huang
> ---
> .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 24
> ++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> new file mode 100644
> index 000..757b974
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> @@ -0,0 +1,24 @@
> +MediaTek display PWM controller
> +
> +Required properties:
> + - compatible: should be "mediatek,-disp-pwm"
> + - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
> + - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
> + - reg: physical base address and length of the controller's registers
> + - #pwm-cells: must be 2. See pwm.txt in this directory for a description of
> + the cell format
> + - clocks: phandle and clock specifier of the PWM reference clock
> + - clock-names: must contain the following
> + - "main": clock used to generate PWM signals
> + - "mm": sync signals from the modules of mmsys
> +
> +Example:
> + pwm0: pwm@1401e000 {
> + compatible = "mediatek,mt8173-disp-pwm",
> +"mediatek,mt6595-disp-pwm";
> + reg = <0 0x1401e000 0 0x1000>;
> + #pwm-cells = <2>;
> + clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> +<&mmsys CLK_MM_DISP_PWM0MM>;
> + clock-names = "main", "mm";
Should we include the pinctrl settings here to enable the PWM output?
> + };
> --
> 1.8.1.1.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Tue, Jul 7, 2015 at 10:36 PM, Sascha Hauer wrote:
> On Tue, Jul 07, 2015 at 10:15:29PM +0800, Daniel Kurtz wrote:
>> On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer wrote:
>> > On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
>> >> Add clk_null, which represents clocks that can not / need not
>> >> controlled by software.
>> >> There are many clocks' parent set to clk_null.
>> >>
>> >> Signed-off-by: James Liao
>> >> Signed-off-by: Eddie Huang
>> >> ---
>> >> Base on 4.1-rc1
>> >>
>> >> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
>> >> ---
>> >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
>> >> 1 file changed, 6 insertions(+)
>> >>
>> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> >> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> >> index 924fdb6..4798f44 100644
>> >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> >> @@ -81,6 +81,12 @@
>> >> cpu_on= <0x8403>;
>> >> };
>> >>
>> >> + clk_null: clk_null {
>> >> + compatible = "fixed-clock";
>> >> + clock-frequency = <0>;
>> >> + #clock-cells = <0>;
>> >> + };
>> >
>> > The discussion around this patch shows that we don't want to have this
>> > clock in the device tree as it is not a hardware description.
>> >
>> > Ok, fine. Eddie, you told us that the rate of the current clk_null children
>> > is not interesting. What's the motivation to send this patch anyway
>> > then? Why can't you keep its children on the orphan list where they are
>> > already now?
>> >
>> > Another possibility would be to instantiate the clk_null clock from C
>> > code rather than from the device tree. This way we wouldn't put any
>> > wrong descriptions into the device tree and still can implement the
>> > support for the real parent clocks when we actually need them.
>>
>> Some device nodes, like mmc, use a clk_null phandle as one of their clocks:
>>
>> mmc1: mmc@1124 {
>> compatible = "mediatek,mt8173-mmc",
>> "mediatek,mt8135-mmc";
>> reg = <0 0x1124 0 0x1000>;
>> interrupts = ;
>> clocks = <&pericfg CLK_PERI_MSDC30_1>,
>> <&clk_null>;
>> clock-names = "source", "hclk";
>> status = "disabled";
>> };
>
> This is another case than the one we discussed about. In the case above
> I motivated using a dummy clock since the clock exists in the system,
> but is not software controllable. To abstract this from the driver
> (which needs this clock since it exists) we here have the dummy clock.
> However, of course I can't prove the clock is indeed not software
> controllable; that's only the information I have.
I was trying to answer your question "What's the motivation to send
this patch anyway?".
The motivation is to send follow on patches that use the clk_null
phandle. We need to provide some clock as the mmc1's hclk. I do not
understand why this has to be "clk_null", though. It seems like this
should be a real clock coming from one of the real clock_controller
nodes. After all, the mmc driver is going to be enabling/disabling
this clock for power savings at runtime. What does that even mean for
clk_null ?
Sorry, I'm not exactly sure what you are saying in your last reply.
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Tue, Jul 7, 2015 at 9:07 PM, Sascha Hauer wrote:
> On Thu, Jun 18, 2015 at 01:29:11PM +0800, Eddie Huang wrote:
>> Add clk_null, which represents clocks that can not / need not
>> controlled by software.
>> There are many clocks' parent set to clk_null.
>>
>> Signed-off-by: James Liao
>> Signed-off-by: Eddie Huang
>> ---
>> Base on 4.1-rc1
>>
>> Change-Id: I4db9b40d07e28f54f7bae9b676316cbd6a962124
>> ---
>> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index 924fdb6..4798f44 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -81,6 +81,12 @@
>> cpu_on= <0x8403>;
>> };
>>
>> + clk_null: clk_null {
>> + compatible = "fixed-clock";
>> + clock-frequency = <0>;
>> + #clock-cells = <0>;
>> + };
>
> The discussion around this patch shows that we don't want to have this
> clock in the device tree as it is not a hardware description.
>
> Ok, fine. Eddie, you told us that the rate of the current clk_null children
> is not interesting. What's the motivation to send this patch anyway
> then? Why can't you keep its children on the orphan list where they are
> already now?
>
> Another possibility would be to instantiate the clk_null clock from C
> code rather than from the device tree. This way we wouldn't put any
> wrong descriptions into the device tree and still can implement the
> support for the real parent clocks when we actually need them.
Some device nodes, like mmc, use a clk_null phandle as one of their clocks:
mmc1: mmc@1124 {
compatible = "mediatek,mt8173-mmc",
"mediatek,mt8135-mmc";
reg = <0 0x1124 0 0x1000>;
interrupts = ;
clocks = <&pericfg CLK_PERI_MSDC30_1>,
<&clk_null>;
clock-names = "source", "hclk";
status = "disabled";
};
-Dan
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] arm64: dts: mt8173: add MT8173 display PWM driver support dtsi
On Mon, Jul 6, 2015 at 9:29 PM, YH Huang wrote:
> Add display PWM node in mt8173.dtsi.
>
> Signed-off-by: YH Huang
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 0696f8f..e4ffd9d 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -393,6 +393,28 @@
> #size-cells = <0>;
> status = "disabled";
> };
> +
> + pwm0: pwm@1401e000 {
> + compatible = "mediatek,mt8173-disp-pwm",
> +"mediatek,mt6595-disp-pwm";
> + reg = <0 0x1401e000 0 0x1000>;
> + #pwm-cells = <2>;
> + clocks = <&mmsys MM_DISP_PWM026M>,
> +<&mmsys MM_DISP_PWM0MM>;
CLK_MM_DISP_PWM026M
> + clock-names = "main", "mm";
> + status = "disabled";
> + };
> +
> + pwm1: pwm@1401f000 {
> + compatible = "mediatek,mt8173-disp-pwm",
> +"mediatek,mt6595-disp-pwm";
> + reg = <0 0x1401f000 0 0x1000>;
> + #pwm-cells = <2>;
> + clocks = <&mmsys MM_DISP_PWM126M>,
> +<&mmsys MM_DISP_PWM1MM>;
> + clock-names = "main", "mm";
> + status = "disabled";
> + };
> };
> };
>
> --
> 1.8.1.1.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: dts: mt8173: Add afe device node
On Mon, Jul 6, 2015 at 2:52 PM, Koro Chen wrote:
> This adds afe (audio front end) device node to the MT8173 dtsi file.
>
> This patch is based on Matthias's tree:
> https://github.com/mbgg/linux-mediatek
> branch: v4.2-next/arm64
>
> Signed-off-by: Koro Chen
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 32
>
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 0696f8f..f8afab4 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "mt8173-pinfunc.h"
>
> @@ -393,6 +394,37 @@
> #size-cells = <0>;
> status = "disabled";
> };
> +
> + afe: mt8173-afe-pcm@1122 {
I believe this should be something generic, like:
afe: audio-controller@1122
Thanks!
-Dan
> + compatible = "mediatek,mt8173-afe-pcm";
> + reg = <0 0x1122 0 0x1000>;
> + interrupts = ;
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_AUDIO>;
> + clocks = <&infracfg CLK_INFRA_AUDIO>,
> +<&topckgen CLK_TOP_AUDIO_SEL>,
> +<&topckgen CLK_TOP_AUD_INTBUS_SEL>,
> +<&topckgen CLK_TOP_APLL1_DIV0>,
> +<&topckgen CLK_TOP_APLL2_DIV0>,
> +<&topckgen CLK_TOP_I2S0_M_SEL>,
> +<&topckgen CLK_TOP_I2S1_M_SEL>,
> +<&topckgen CLK_TOP_I2S2_M_SEL>,
> +<&topckgen CLK_TOP_I2S3_M_SEL>,
> +<&topckgen CLK_TOP_I2S3_B_SEL>;
> + clock-names = "infra_sys_audio_clk",
> + "top_pdn_audio",
> + "top_pdn_aud_intbus",
> + "bck0",
> + "bck1",
> + "i2s0_m",
> + "i2s1_m",
> + "i2s2_m",
> + "i2s3_m",
> + "i2s3_b";
> + assigned-clocks = <&topckgen CLK_TOP_AUD_1_SEL>,
> + <&topckgen CLK_TOP_AUD_2_SEL>;
> + assigned-clock-parents = <&topckgen CLK_TOP_APLL1>,
> +<&topckgen CLK_TOP_APLL2>;
> + };
> };
> };
>
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/9] clocksource: mediatek: Use GPT as sched clock source
On Wed, May 20, 2015 at 7:02 PM, Matthias Brugger
wrote:
> 2015-05-16 9:58 GMT+02:00 Yingjoe Chen :
>> When cpu is in deep idle, arch timer will stop counting. Setup GPT as
>> sched clock source so it can keep counting in idle.
>>
>> Signed-off-by: Yingjoe Chen
>> ---
>> drivers/clocksource/mtk_timer.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/clocksource/mtk_timer.c
>> b/drivers/clocksource/mtk_timer.c
>> index 91206f9..fe7cf72 100644
>> --- a/drivers/clocksource/mtk_timer.c
>> +++ b/drivers/clocksource/mtk_timer.c
>> @@ -24,6 +24,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #define GPT_IRQ_EN_REG 0x00
>> @@ -59,6 +60,13 @@ struct mtk_clock_event_device {
>> struct clock_event_device dev;
>> };
>>
>> +static void __iomem *gpt_base __read_mostly;
>> +
>> +static u64 notrace mtk_read_sched_clock(void)
>> +{
>> + return readl_relaxed(gpt_base + TIMER_CNT_REG(GPT_CLK_SRC));
>> +}
>> +
>> static inline struct mtk_clock_event_device *to_mtk_clk(
>> struct clock_event_device *c)
>> {
>> @@ -243,6 +251,8 @@ static void __init mtk_timer_init(struct device_node
>> *node)
>> mtk_timer_setup(evt, GPT_CLK_SRC, TIMER_CTRL_OP_FREERUN, 1);
>> clocksource_mmio_init(evt->gpt_base + TIMER_CNT_REG(GPT_CLK_SRC),
>> node->name, rate, 300, 32,
>> clocksource_mmio_readl_up);
>> + gpt_base = evt->gpt_base;
>
> This is really hacky. We should clean up the code and provide
> mtk_clock_event_device globally.
> Please add the patch below, which does exactly this.
I don't think this is so hacky.
In light of Stephen's comment about the benefit of using
container_of() to extract gpt_base from the passed in struct
clock_event_device in the other routines, what is the benefit of
making more of mtk_clock_event_device global?
I think what Yingjoe has implemented is short and sweet.
Reviewed-by: Daniel Kurtz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers
On Fri, Jul 3, 2015 at 7:40 AM, Stephen Boyd wrote:
> On 07/01/2015 09:26 PM, Daniel Kurtz wrote:
>> On Thu, Jul 2, 2015 at 10:52 AM, James Liao
>> wrote:
>>> Hi Daniel,
>>>
>>>>> +Required Properties:
>>>>> +
>>>>> +- compatible: Should be:
>>>>> + - "mediatek,mt8173-imgsys", "syscon"
>>>>> +- #clock-cells: Must be 1
>>>>> +
>>>>> +The imgsys controller uses the common clk binding from
>>>>> +Documentation/devicetree/bindings/clock/clock-bindings.txt
>>>>> +The available clocks are defined in dt-bindings/clock/mt*-clk.h.
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> +imgsys: imgsys@1500 {
>>>> Since these nodes will be supplying clocks to the rest of the system,
>>>> I think the "name" part of each of these should all be
>>>> "clock-controller", like topckgen and apmixedsys:
>>>>
>>>> imgsys: clock-controller@1500 {
>>> These subsystems (and topckgen also) also contains other functions such
>>> as reset controller, which may be implemented in clk/mediatek/ in the
>>> future. It is suitable to use "clock-controller" as their name?
>> Hmm,
>>
>> I don't know the "right way" to do this either.
>> Pardon me if you've already had these discussions.
>> I only recently started looking at these clock nodes in detail :-).
>>
>> I think what we really have in register space is a "syscon", as
>> described in [0]:
>> [0] Documentation/devicetree/bindings/mfd/syscon.txt
>>
>> So, we can define this block of registers as a syscon:
>>
>> mmsys_syscon: syscon@1400 {
>>compatible = "mediatek,mt8173-mmsys", "syscon";
>>reg = <0 0x1400 0 0x1000>;
>> };
>>
>>
>> Then for the clock controller functionality, we create a node with a
>> "clock-controller" name and a "-clock" compatible, like this:
>>
>> mmsys_clock: clock-controller {
>>compatible = "mediatek,mt8173-mmsys-clock";
>>#clock-cells = <1>;
>>mediatek,syscon = <&mmsys_syscon>;
>> };
>>
>> You could then do:
>> CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt8173-mmsys-clock", mtk_mmsys_init);
>>
>>
>> If you want to reuse the same register range for some other
>> functionality, we could then use a different node, with a different
>> compatible:
>>
>> mmsys: reset-controller {
>>compatible = "mediatek,mt8173-mmsys-reset";
>>mediatek,syscon = <&mmsys_syscon>;
>> };
>>
>> What do you think of this approach?
>
> DT nodes typically have a reg property. Not having a reg property is a
> good indicator of a problem with the binding. A syscon is used when you
> have a DT node with a reg property and some driver attached to it, but
> you need to poke some bits in another register region that isn't part of
> the reg property. Instead of having multiple nodes with two reg
> properties where the second one is the same, we use a phandle and a syscon.
>
> If clock-controller isn't acceptable maybe clock-reset-contoller would
> work? Or "power-controller"? We certainly shouldn't be making up
> multiple nodes for one hardware block. Of course, the subject of the
> patch is "bindings for clock controllers", so it may be that the
> registers are predominantly clock related and so the name is appropriate
> already.
Using "clock-controller" seems to fit best with the bindings
introduced by this patch.
However, if these bindings are for hardware blocks that contain a grab
bag of various functionality that will be added in later patches, then
I think "syscon" might be best.
-Dan
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] clk: mediatek: mt8173: Fix enabling of critical clocks
Hi Stephen, On Fri, Jul 3, 2015 at 7:03 AM, Stephen Boyd wrote: > On 06/30, James Liao wrote: >> From: Sascha Hauer >> >> On the MT8173 the clocks are provided by different units. To enable >> the critical clocks we must be sure that all parent clocks are already >> registered, otherwise the parents of the critical clocks end up being >> unused and get disabled later. To find a place where all parents are >> registered we try each time after we've registered some clocks if >> all known providers are present now and only then we enable the critical >> clocks >> >> Signed-off-by: Sascha Hauer >> Signed-off-by: James Liao >> --- > > Applied to clk-fixes I think James plans to send an updated version of this patch. > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
On Fri, Jul 3, 2015 at 1:38 PM, James Liao wrote: > Hi Daniel, > > On Wed, 2015-07-01 at 23:22 +0800, Daniel Kurtz wrote: >> This looks like 3 separate gate clocks in a chain, with a timing >> constraint: USB_LPF must be enabled 100 us after USB_TX. >> >> 26MHz--> [GATE] --USB_TX--> [LPF] --USB_LPF--> [GATE] --USB_OUT--> >> ^ ^ ^ >> +--+ | | >> AP_PLL_CON2.REF2USB_TX_EN -+ | | >> AP_PLL_CON2.REF2USB_TX_LPF_EN -+ | >> AP_PLL_CON2.REF2USB_TX_OUT_EN + >> >> >> I think we can model the gate parts using a proper clock tree model >> and the existing clock gate semantics. >> I'm not sure the best way to model the delay; but in theory that could >> be handled by the clock user (USB driver). > > Do you mean to create 3 hierarchical clocks (may be clock gates) to > model these clocks as the following ? > > EN -- LPF -- OUT_EN > > (EN is the parent of LPF, and LPF is the parent of EN) > > If we model these 3 clocks like above, we can't prevent clock users to > enable OUT_EN directly, and there will be no delay between EN and LPF. > > Or you have other suggestions to model these 3 clcoks? I don't really know. I was hoping someone would know of a way to add a "delay" when enabling a clock gate. :-) Why do we need the delay anyway? Is the delay really between LPF and OUT_EN? Or, is the delay between enabling OUT_EN and when the USB block can use the clock? Some ideas: (1) Handled the LPF delay in the USB driver itself: (a) if the delay is really between OUT_EN and when it is used: /* Enabling USB_OUT will enable its parents, USB_LPF and USB_TX */ clk_enable(clk_usb_out); udelay(); (b) Or if the delay is really needed between LPF and OUT, this can be implemented in the USB driver: /* Enable LPF and its parent USB_TX */ clk_enable(clk_lpf); udelay(); clk_enable(clk_usb_out); (2) Add a "delay" property to "struct mtk_clk_gate", with a non-zero value for just this one special LPF clock. The downside is then every gate clock would have to carry this extra field. (3) Add a new clk type, struct mtk_clk_delayed_gate, that includes a struct mtk_clk_gate, plus a delay. I would add this to its own file, or maybe clk-gate.c, though, rather than mediatek/clk-mt8173.c. And then use this for instantiating the LPF clock. -Dan > Best regards, > > James > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] clk: mediatek: Add subsystem clocks of MT8173
On Fri, Jul 3, 2015 at 1:15 PM, James Liao wrote:
> On Wed, 2015-07-01 at 22:54 +0800, Daniel Kurtz wrote:
>> On Tue, Jun 30, 2015 at 10:58 AM, James Liao
>> wrote:
>> >
>> > +static struct mtk_gate_regs cg_regs_4_8_0 = {
>>
>> These should all be:
>>
>> static const struct mtk_gate_regs ...
>
> OK, I'll fix it.
>
>> > + .set_ofs = 0x0004,
>> > + .clr_ofs = 0x0008,
>> > + .sta_ofs = 0x,
>> > +};
>> > +
>> > +#define GATE_IMG(_id, _name, _parent, _shift) {\
>> > + .id = _id, \
>> > + .name = _name, \
>> > + .parent_name = _parent, \
>> > + .regs = &cg_regs_4_8_0, \
>> > + .shift = _shift,\
>> > + .ops = &mtk_clk_gate_ops_setclr,\
>> > + }
>> > +
>> > +static struct mtk_gate img_clks[] __initdata = {
>>
>> These should all be:
>>
>> static const ... __initconst = {
>
> OK, I'll fix it.
>
>> > +
>> > +static void __init mtk_imgsys_init(struct device_node *node)
>> > +{
>> > + struct clk_onecell_data *clk_data;
>> > + void __iomem *base;
>>
>> I don't think you need base for any of these.
>> mtk_clk_register_gates() will use syscon_node_to_regmap() to lookup
>> the regmap by itself.
>
> OK, I'll remove it.
>
>> > + int r;
>> > +
>> > + base = of_iomap(node, 0);
>> > + if (!base) {
>> > + pr_err("%s(): ioremap failed\n", __func__);
>> > + return;
>> > + }
>> > +
>> > + clk_data = mtk_alloc_clk_data(CLK_IMG_NR_CLK);
>>
>> Unrelated to this patch, but:
>> I think each clock node should statically declare its
>> clk_onecell_data, and pass it to mtk_alloc_clk_data().
>> mtk_alloc_clk_data() should then just allocate and initialize the clks array.
>
> Is there any different from allocating clk_onecell_data and clks arary
> dynamically?
I generally believe it is always a bit better to statically allocate
memory where possible. There would then be slightly less to do at
runtime (in this case on the critical boot path), and less churn on
the heap. Each individual allocation probably doesn't matter very
much, but it adds up.
>> > /* APMIXED_SYS */
>> >
>> > -#define CLK_APMIXED_ARMCA15PLL 1
>> > -#define CLK_APMIXED_ARMCA7PLL 2
>> > +#define CLK_APMIXED_ARMCA15PLL 1
>> > +#define CLK_APMIXED_ARMCA7PLL 2
>> > #define CLK_APMIXED_MAINPLL3
>> > #define CLK_APMIXED_UNIVPLL4
>> > #define CLK_APMIXED_MMPLL 5
>> > @@ -232,4 +232,91 @@
>> > #define CLK_PERI_UART3_SEL 39
>> > #define CLK_PERI_NR_CLK40
>>
>> Why do we count up from 1 instead of 0?
>> This means that for each clock-controller:
>> clk_onecell_data->clk[0] == ERR_PTR(-ENOENT)
>
> It's a legacy implementation. I think it doesn't matter for function or
> size in this implementation. We may change clock index to start from 0
> in next SoC clock implementation.
Ok. I don't think it matters a lot. Just curious.
Thanks!
-Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] dt-bindings: pwm: add MediaTek display PWM bindings
On Mon, Jun 29, 2015 at 11:24 PM, YH Huang wrote:
> I am sorry for forgetting to remove Change-Id in [PATCH v3 1/2] and
> [PATCH v3 1/2].
>
> Regards,
> YH Huang
>
> On Mon, 2015-06-29 at 23:03 +0800, YH Huang wrote:
>> Document the device-tree binding of MediatTek display PWM.
>> The clock "main" and "mm" are used to generate PWM signals.
>> The PWM has one channel to control the backlight brightness for display.
>> It supports MT8173 and MT6595.
>>
>> Change-Id: I194ca88b4e4cd01a28b8701e07e86ea6941e5292
>> Signed-off-by: YH Huang
>> ---
>> .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 24
>> ++
>> 1 file changed, 24 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
>> b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
>> new file mode 100644
>> index 000..355b755
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
>> @@ -0,0 +1,24 @@
>> +MediaTek display PWM controller
>> +
>> +Required properties:
>> + - compatible: should be "mediatek,-disp-pwm"
>> + - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
>> + - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
>> + - reg: physical base address and length of the controller's registers
>> + - #pwm-cells: must be 2. See pwm.txt in this directory for a description of
>> + the cell format
>> + - clocks: phandle and clock specifier of the PWM reference clock
>> + - clock-names: must contain the following
>> + - "main": clock used to generate PWM signals
>> + - "mm": sync signals from the modules of mmsys
>> +
>> +Example:
>> + pwm0: pwm@1401e000 {
>> + compatible = "mediatek,mt8173-disp-pwm",
>> + "mediatek,mt6595-disp-pwm";
>> + reg = <0 0x1401e000 0 0x1000>;
>> + #pwm-cells = <2>;
>> + clocks = <&mmsys MM_DISP_PWM026M>,
>> + <&mmsys MM_DISP_PWM0MM>;
These should be CLK_MM_DISP...
Thanks!
-Dan
>> + clock-names = "main", "mm";
>> + };
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] pwm: add MediaTek display PWM driver support
On Mon, Jun 29, 2015 at 11:03 PM, YH Huang wrote: > Add display PWM driver support to modify backlight for MT8173 and MT6595. > The PWM has one channel to control the brightness of the display. > When the (high_width / period) is closer to 1, the screen is brighter; > otherwise, it is darker. > > Change-Id: Ie85b295e290b4163af1c906df977f79b59d6 > Signed-off-by: YH Huang > --- > drivers/pwm/Kconfig| 10 ++ > drivers/pwm/Makefile | 1 + > drivers/pwm/pwm-mtk-disp.c | 256 > + > 3 files changed, 267 insertions(+) > create mode 100644 drivers/pwm/pwm-mtk-disp.c > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > index b1541f4..90e3c079 100644 > --- a/drivers/pwm/Kconfig > +++ b/drivers/pwm/Kconfig > @@ -211,6 +211,16 @@ config PWM_LPSS_PLATFORM > To compile this driver as a module, choose M here: the module > will be called pwm-lpss-platform. > > +config PWM_MTK_DISP > + tristate "MediaTek display PWM driver" > + depends on HAS_IOMEM depends on ARCH_MEDIATEK || COMPILE_TEST > + help > + Generic PWM framework driver for MediaTek disp-pwm device. > + The PWM is used to control the backlight brightness for display. > + > + To compile this driver as a module, choose M here: the module > + will be called pwm-mtk-disp. > + > config PWM_MXS > tristate "Freescale MXS PWM support" > depends on ARCH_MXS && OF > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile > index ec50eb5..99c9e75 100644 > --- a/drivers/pwm/Makefile > +++ b/drivers/pwm/Makefile > @@ -18,6 +18,7 @@ obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o > obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o > obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o > obj-$(CONFIG_PWM_LPSS_PLATFORM)+= pwm-lpss-platform.o > +obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o > obj-$(CONFIG_PWM_MXS) += pwm-mxs.o > obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o > obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o > diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c > new file mode 100644 > index 000..fb3a42e > --- /dev/null > +++ b/drivers/pwm/pwm-mtk-disp.c > @@ -0,0 +1,256 @@ > +/* > + * MediaTek display pulse-width-modulation controller driver. > + * Copyright (c) 2015 MediaTek Inc. > + * Author: YH Huang > + * > + * 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 > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DISP_PWM_EN0x0 > +#define PWM_ENABLE_MASK0x1 For one bit fields like this, it is nicer to use: BIT() Thanks! -Dan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers
On Thu, Jul 2, 2015 at 10:52 AM, James Liao wrote:
> Hi Daniel,
>
>> > +Required Properties:
>> > +
>> > +- compatible: Should be:
>> > + - "mediatek,mt8173-imgsys", "syscon"
>> > +- #clock-cells: Must be 1
>> > +
>> > +The imgsys controller uses the common clk binding from
>> > +Documentation/devicetree/bindings/clock/clock-bindings.txt
>> > +The available clocks are defined in dt-bindings/clock/mt*-clk.h.
>> > +
>> > +Example:
>> > +
>> > +imgsys: imgsys@1500 {
>>
>> Since these nodes will be supplying clocks to the rest of the system,
>> I think the "name" part of each of these should all be
>> "clock-controller", like topckgen and apmixedsys:
>>
>> imgsys: clock-controller@1500 {
>
> These subsystems (and topckgen also) also contains other functions such
> as reset controller, which may be implemented in clk/mediatek/ in the
> future. It is suitable to use "clock-controller" as their name?
Hmm,
I don't know the "right way" to do this either.
Pardon me if you've already had these discussions.
I only recently started looking at these clock nodes in detail :-).
I think what we really have in register space is a "syscon", as
described in [0]:
[0] Documentation/devicetree/bindings/mfd/syscon.txt
So, we can define this block of registers as a syscon:
mmsys_syscon: syscon@1400 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
};
Then for the clock controller functionality, we create a node with a
"clock-controller" name and a "-clock" compatible, like this:
mmsys_clock: clock-controller {
compatible = "mediatek,mt8173-mmsys-clock";
#clock-cells = <1>;
mediatek,syscon = <&mmsys_syscon>;
};
You could then do:
CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt8173-mmsys-clock", mtk_mmsys_init);
If you want to reuse the same register range for some other
functionality, we could then use a different node, with a different
compatible:
mmsys: reset-controller {
compatible = "mediatek,mt8173-mmsys-reset";
mediatek,syscon = <&mmsys_syscon>;
};
What do you think of this approach?
Thanks!
-Dan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Thu, Jul 2, 2015 at 11:06 AM, James Liao wrote:
> Hi Daniel,
>
> On Wed, 2015-07-01 at 19:54 +0800, Daniel Kurtz wrote:
>> On Wed, Jul 1, 2015 at 2:49 PM, Sascha Hauer wrote:
>> > The problem is not that you use fixed clocks for non software
>> > controllable clocks of unknwown rates, but that you try to use a single
>> > clock for all of them and name it 'dummy' or 'null'. Name it
>> >
>> > dpi_ck {
>> > compatible = "fixed-clock";
>> > rate = <0>; /* unknown, generated by some Analog block */
>> > };
>>
>> It would be nice, though, to use the real clock rates.
>> Otherwise, we end up with a bunch of unknown clock rates, like this:
>>
>>clock enable_cnt prepare_cntrate
>> accuracy phase
>>
>> clk_null 22 0
>>0 0
>> mm_lvds_cts 00 0
>>0 0
>> mm_lvds_pixel 00 0
>>0 0
>> mm_dpi1_pixel 00 0
>>0 0
>
>> Furthermore, at least some of these children clocks are possible
>> source clocks for other clocks for which we do want to know the
>> resulting frequency. For example, the "dmpll_*" clocks are mux inputs
>> for many of the subsystem clocks.
>
> These clocks such as clkph_mck_o are configured by other modules before
> kernel init, and their rates may different among platforms.
What other modules?
Do you mean the rates are configured by firmware?
How are the rates set?
Are there registers that configure its rate?
If so, why can't the kernel read these registers and compute the current rate?
For mt8173, we are essentially discussing the following clocks (whose
sole parent is clk_null):
FACTOR(CLK_TOP_CLKPH_MCK_O, "clkph_mck_o", "clk_null", 1, 1),
FACTOR(CLK_TOP_DPI, "dpi_ck", "clk_null", 1, 1),
FACTOR(CLK_TOP_USB_SYSPLL_125M, "usb_syspll_125m", "clk_null", 1, 1),
FACTOR(CLK_TOP_HDMITX_DIG_CTS, "hdmitx_dig_cts", "clk_null", 1, 1),
GATE_ICG(CLK_INFRA_CPUM, "infra_cpum", "clk_null", 15),
GATE_MM1(CLK_MM_DSI0_DIGITAL, "mm_dsi0_digital", "clk_null", 5),
GATE_MM1(CLK_MM_DSI1_DIGITAL, "mm_dsi1_digital", "clk_null", 7),
GATE_MM1(CLK_MM_DPI1_PIXEL, "mm_dpi1_pixel", "clk_null", 10),
GATE_MM1(CLK_MM_LVDS_PIXEL, "mm_lvds_pixel", "clk_null", 16),
GATE_MM1(CLK_MM_LVDS_CTS, "mm_lvds_cts", "clk_null", 17),
clkph_mck_o - This is the parent for dmpll_*, which are themselves
(potential) parent clocks for nearly every subsystem.
In fact, as shown above, the dmpll_* is the selected parent for
several other clocks, which all end up with an unknown rate.
So, I think it is worth investigating a little more how to properly
read or otherwise specify the rate for clkph_mck_o.
dpi_ck, infra_cpum, mm_dsi0_digital, mm_dsi1_digital, mm_lvds_cts -
These are a dead-end (internal?) clock.
It is probably fine if their rates are unknown (0 Hz).
usb_syspll_125m - This sounds like a fixed 125 MHz clock. It is also
a possible parent usb30 clock, so its value will propagate.
hdmitx_dig_cts - This is the root clock for the tree leading to
mm_hdmi_pllck, which includes hdmitxpll_d* and hdmi_sel.
However, I don't know how "mm_hdmi_pllck" is used.
mm_dpi1_pixel, mm_lvds_pixel - These two look very suspicious. The
similar "mm_dpi0_pixel" and "mm_hdmi_pixel" have parent dpi0_sel.
It looks like maybe they should have "dpi1_sel" or "dpilvds_sel" as
parents, but the _sel are not hooked up.
-Dan
> So we can't
> use a hard-coded rate for them. And we also don't care the actual rate
> of these clocks, so assign a dummy rate such as 0 to them should be a
> better way.
>
>
> Best regards,
>
> james
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] dt-bindings: ARM: Mediatek: Document devicetree bindings for spi bus
On Mon, Jun 29, 2015 at 9:04 PM, Leilk Liu wrote:
> Signed-off-by: Leilk Liu
> ---
> .../devicetree/bindings/spi/spi-mt65xx.txt | 32
> ++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-mt65xx.txt
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> new file mode 100644
> index 000..04c28fd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
> @@ -0,0 +1,32 @@
> +MTK SPI device
> +
> +Required properties:
> +- compatible: should be one of the following.
> +- mediatek,mt8173-spi: for mt8173 platforms
> +- mediatek,mt8135-spi: for mt8135 platforms
> +- mediatek,mt6589-spi: for mt6589 platforms
> +
> +- reg: Address and length of the register set for the device
> +
> +- interrupts: Should contain spi interrupt
> +
> +- clock-names: tuple listing input clock names.
> + Required elements: "main"
> +
> +- clocks: phandles to input clocks.
> +
> +- pad-select: should specify spi pad used, only required for MT8173.
> + This value should be 0~3.
> +
> +Example:
> +
> +- SoC Specific Portion:
> +spi: spi@1100a000 {
> + compatible = "mediatek,mt8173-spi";
> + reg = <0 0x1100a000 0 0x1000>;
> + interrupts = ;
> + clocks = <&pericfg PERI_SPI0>;
CLK_PERI_SPI0
> + clock-names = "main";
> + pad-select = <1>;
According to [0], a SPI bus should also specify
address-cells/size-cells to allow SPI bus devices to specify a chip
select.
[0] Documentation/devicetree/bindings/spi/spi-bus.txt
- #address-cells - number of cells required to define a chip select
address on the SPI bus.
- #size-cells - should be zero.
The spi-bus document even describes how to mix "native" and gpio CS lines.
I am still not sure what to do with the "pad-select" feature.
Does "pad-select" just select one of 4 dedicated chip select lines?
Or, does it also change which CK/MOSI/MISO lines are used?
Ideally, the same CK/MOSI/MISO signals are sent on all CK/MOSI/MISO
lines enabled by pinctrl, and "pad-select" just chooses which CS_N
line to use.
In this case, we can use the SPI slave device reg value to select
which CS_N to use for any given device.
Furthermore, we can also support using additional cs-gpios.
However, if the pad-select also specifies which CK/MOSI/MISO pins are
used for a given transaction, then supporting cs-gpios becomes a bit
trickier, since the spi slave device would need to specify both which
gpio-cs to use, as well as which SPI pad it is connected to.
-Dan
> + status = "disabled";
> +};
> --
> 1.8.1.1.dirty
>
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] clk: mediatek: mt8173: Fix enabling of critical clocks
On Wed, Jul 1, 2015 at 10:21 PM, Daniel Kurtz wrote:
> Hi James,
>
> To be precise, it is the CLK_TOP clocks that have CLK_APMIXED PLLs as
> their parents, so we cannot enable the CLK_TOP critical clocks until
> the CLK_APMIXED clocks have all been registered.
>
> Please add something like the above to the commit message.
>
> More comments inline...
>
> On Tue, Jun 30, 2015 at 10:58 AM, James Liao
> wrote:
>> From: Sascha Hauer
>>
>> On the MT8173 the clocks are provided by different units. To enable
>> the critical clocks we must be sure that all parent clocks are already
>> registered, otherwise the parents of the critical clocks end up being
>> unused and get disabled later. To find a place where all parents are
>> registered we try each time after we've registered some clocks if
>> all known providers are present now and only then we enable the critical
>> clocks
>>
>> Signed-off-by: Sascha Hauer
>> Signed-off-by: James Liao
>> ---
>> drivers/clk/mediatek/clk-mt8173.c | 26 +-
>> 1 file changed, 21 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/clk/mediatek/clk-mt8173.c
>> b/drivers/clk/mediatek/clk-mt8173.c
>> index 4b9e04c..c483336 100644
>> --- a/drivers/clk/mediatek/clk-mt8173.c
>> +++ b/drivers/clk/mediatek/clk-mt8173.c
>> @@ -700,6 +700,22 @@ static const struct mtk_composite peri_clks[]
>> __initconst = {
>> MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c,
>> 3, 1),
>> };
>>
>> +static struct clk_onecell_data *mt8173_top_clk_data;
>> +static struct clk_onecell_data *mt8173_pll_clk_data;
>
> These globals can be:
> __initdata
Oops, never mind about this comment...
Using "__initdata" for uninitialized variables doesn't make sense -
"__initdata" is for initialization data, not variables themselves.
Sorry for the noise,
-Dan
>
>> +
>> +static void mtk_clk_enable_critical(void)
>
> And this function is:
>
> static void __init
>
> Other than the above, this one is:
>
> Reviewed-by: Daniel Kurtz
>
> -Dan
>
>> +{
>> + if (!mt8173_top_clk_data || !mt8173_pll_clk_data)
>> + return;
>> +
>> +
>> clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
>> + clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA7PLL]);
>> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_MEM_SEL]);
>> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
>> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_CCI400_SEL]);
>> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_RTC_SEL]);
>> +}
>> +
>> static void __init mtk_topckgen_init(struct device_node *node)
>> {
>> struct clk_onecell_data *clk_data;
>> @@ -712,19 +728,19 @@ static void __init mtk_topckgen_init(struct
>> device_node *node)
>> return;
>> }
>>
>> - clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
>> + mt8173_top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
>>
>> mtk_clk_register_factors(root_clk_alias, ARRAY_SIZE(root_clk_alias),
>> clk_data);
>> mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
>> mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
>> &mt8173_clk_lock, clk_data);
>>
>> - clk_prepare_enable(clk_data->clks[CLK_TOP_CCI400_SEL]);
>> -
>> r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
>> if (r)
>> pr_err("%s(): could not register clock provider: %d\n",
>> __func__, r);
>> +
>> + mtk_clk_enable_critical();
>> }
>> CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt8173-topckgen", mtk_topckgen_init);
>>
>> @@ -818,13 +834,13 @@ static void __init mtk_apmixedsys_init(struct
>> device_node *node)
>> {
>> struct clk_onecell_data *clk_data;
>>
>> - clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
>> + mt8173_pll_clk_data = clk_data =
>> mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
>> if (!clk_data)
>> return;
>>
>> mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
>>
>> - clk_prepare_enable(clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
>> + mtk_clk_enable_critical();
>> }
>> CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt8173-apmixedsys",
>> mtk_apmixedsys_init);
>> --
>> 1.8.1.1.dirty
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS
Hi James,
This looks like 3 separate gate clocks in a chain, with a timing
constraint: USB_LPF must be enabled 100 us after USB_TX.
26MHz--> [GATE] --USB_TX--> [LPF] --USB_LPF--> [GATE] --USB_OUT-->
^ ^ ^
+--+ | |
AP_PLL_CON2.REF2USB_TX_EN -+ | |
AP_PLL_CON2.REF2USB_TX_LPF_EN -+ |
AP_PLL_CON2.REF2USB_TX_OUT_EN +
I think we can model the gate parts using a proper clock tree model
and the existing clock gate semantics.
I'm not sure the best way to model the delay; but in theory that could
be handled by the clock user (USB driver).
-Dan
On Wed, Jul 1, 2015 at 11:22 PM, Daniel Kurtz wrote:
> Hi James,
>
> This looks like 3 separate gate clocks in a chain, with a timing constraint:
> USB_LPF must be enabled 100 us after USB_TX.
>
> 26MHz--> [GATE] --USB_TX--> [LPF] --USB_LPF--> [GATE] --USB_OUT-->
> ^ ^ ^
> +--+ | |
> AP_PLL_CON2.REF2USB_TX_EN -+ | |
> AP_PLL_CON2.REF2USB_TX_LPF_EN -+ |
> AP_PLL_CON2.REF2USB_TX_OUT_EN +
>
>
> I think we can model the gate parts using a proper clock tree model and the
> existing clock gate semantics.
> I'm not sure the best way to model the delay; but in theory that could be
> handled by the clock user (USB driver).
>
> -Dan
>
> On Tue, Jun 30, 2015 at 10:58 AM, James Liao
> wrote:
>> Add REF2USB_TX clock support into MT8173 APMIXEDSYS. This clock
>> is needed by USB 3.0.
>>
>> Signed-off-by: James Liao
>> ---
>> drivers/clk/mediatek/clk-mt8173.c | 143
>> +
>> drivers/clk/mediatek/clk-pll.c | 7 +-
>> include/dt-bindings/clock/mt8173-clk.h | 3 +-
>> 3 files changed, 146 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/clk/mediatek/clk-mt8173.c
>> b/drivers/clk/mediatek/clk-mt8173.c
>> index 75be757..333b6af 100644
>> --- a/drivers/clk/mediatek/clk-mt8173.c
>> +++ b/drivers/clk/mediatek/clk-mt8173.c
>> @@ -12,6 +12,7 @@
>> * GNU General Public License for more details.
>> */
>>
>> +#include
>> #include
>> #include
>> #include
>> @@ -968,6 +969,141 @@ static void __init mtk_pericfg_init(struct
>> device_node *node)
>> }
>> CLK_OF_DECLARE(mtk_pericfg, "mediatek,mt8173-pericfg", mtk_pericfg_init);
>>
>> +#define REF2USB_TX_EN BIT(0)
>> +#define REF2USB_TX_LPF_EN BIT(1)
>> +#define REF2USB_TX_OUT_EN BIT(2)
>> +#define REF2USB_EN_MASK(REF2USB_TX_EN | REF2USB_TX_LPF_EN
>> | \
>> +REF2USB_TX_OUT_EN)
>> +
>> +struct mtk_ref2usb_tx {
>> + struct clk_hw hw;
>> + void __iomem*base_addr;
>> +};
>> +
>> +static inline struct mtk_ref2usb_tx *to_mtk_ref2usb_tx(struct clk_hw *hw)
>> +{
>> + return container_of(hw, struct mtk_ref2usb_tx, hw);
>> +}
>> +
>> +static int mtk_ref2usb_tx_is_prepared(struct clk_hw *hw)
>> +{
>> + struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
>> +
>> + return (readl(tx->base_addr) & REF2USB_EN_MASK) ==
>> REF2USB_EN_MASK;
>> +}
>> +
>> +static int mtk_ref2usb_tx_prepare(struct clk_hw *hw)
>> +{
>> + struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
>> + u32 val;
>> +
>> + val = readl(tx->base_addr);
>> +
>> + val |= REF2USB_TX_EN;
>> + writel(val, tx->base_addr);
>> + udelay(100);
>> +
>> + val |= REF2USB_TX_LPF_EN;
>> + writel(val, tx->base_addr);
>> +
>> + val |= REF2USB_TX_OUT_EN;
>> + writel(val, tx->base_addr);
>> +
>> + return 0;
>> +}
>> +
>> +static void mtk_ref2usb_tx_unprepare(struct clk_hw *hw)
>> +{
>> + struct mtk_ref2usb_tx *tx = to_mtk_ref2usb_tx(hw);
>> + u32 val;
>> +
>> + val = readl(tx->base_addr);
>> + val &= ~REF2USB_EN_MASK;
>> + writel(val, tx->base_addr);
>> +}
>> +
>> +static const struct clk_ops mtk_ref2usb_tx_ops = {
>> + .is_prepared= mtk_ref2usb_tx_is_prepared,
>> + .prepare= mtk_ref2usb_tx_prepare,
>> + .unprepare = mtk_ref2usb_tx_unprepare,
>> +};
>> +
>> +static struct clk *mtk_clk_register_ref2usb_tx(const char *name,
>> + const char
Re: [PATCH v2 3/4] clk: mediatek: Add subsystem clocks of MT8173
On Tue, Jun 30, 2015 at 10:58 AM, James Liao wrote:
> Most multimedia subsystem clocks will be accessed by multiple
> drivers, so it's a better way to manage these clocks in CCF.
> This patch adds clock support for MM, IMG, VDEC, VENC and VENC_LT
> subsystems.
>
> Signed-off-by: James Liao
> ---
> drivers/clk/mediatek/clk-mt8173.c | 298
> +
> include/dt-bindings/clock/mt8173-clk.h | 91 +-
> 2 files changed, 387 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c
> index c483336..75be757 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -700,6 +700,183 @@ static const struct mtk_composite peri_clks[]
> __initconst = {
> MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c,
> 3, 1),
> };
>
> +static struct mtk_gate_regs cg_regs_4_8_0 = {
These should all be:
static const struct mtk_gate_regs ...
> + .set_ofs = 0x0004,
> + .clr_ofs = 0x0008,
> + .sta_ofs = 0x,
> +};
> +
> +#define GATE_IMG(_id, _name, _parent, _shift) {\
> + .id = _id, \
> + .name = _name, \
> + .parent_name = _parent, \
> + .regs = &cg_regs_4_8_0, \
> + .shift = _shift,\
> + .ops = &mtk_clk_gate_ops_setclr,\
> + }
> +
> +static struct mtk_gate img_clks[] __initdata = {
These should all be:
static const ... __initconst = {
> + GATE_IMG(CLK_IMG_LARB2_SMI, "img_larb2_smi", "mm_sel", 0),
> + GATE_IMG(CLK_IMG_CAM_SMI, "img_cam_smi", "mm_sel", 5),
> + GATE_IMG(CLK_IMG_CAM_CAM, "img_cam_cam", "mm_sel", 6),
> + GATE_IMG(CLK_IMG_SEN_TG, "img_sen_tg", "camtg_sel", 7),
> + GATE_IMG(CLK_IMG_SEN_CAM, "img_sen_cam", "mm_sel", 8),
> + GATE_IMG(CLK_IMG_CAM_SV, "img_cam_sv", "mm_sel", 9),
> + GATE_IMG(CLK_IMG_FD, "img_fd", "mm_sel", 11),
> +};
> +
> +static struct mtk_gate_regs mm0_cg_regs = {
> + .set_ofs = 0x0104,
> + .clr_ofs = 0x0108,
> + .sta_ofs = 0x0100,
> +};
> +
> +static struct mtk_gate_regs mm1_cg_regs = {
> + .set_ofs = 0x0114,
> + .clr_ofs = 0x0118,
> + .sta_ofs = 0x0110,
> +};
> +
> +#define GATE_MM0(_id, _name, _parent, _shift) {\
> + .id = _id, \
> + .name = _name, \
> + .parent_name = _parent, \
> + .regs = &mm0_cg_regs, \
> + .shift = _shift,\
> + .ops = &mtk_clk_gate_ops_setclr,\
> + }
> +
> +#define GATE_MM1(_id, _name, _parent, _shift) {\
> + .id = _id, \
> + .name = _name, \
> + .parent_name = _parent, \
> + .regs = &mm1_cg_regs, \
> + .shift = _shift,\
> + .ops = &mtk_clk_gate_ops_setclr,\
> + }
> +
> +static struct mtk_gate mm_clks[] __initdata = {
> + /* MM0 */
> + GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 0),
> + GATE_MM0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
> + GATE_MM0(CLK_MM_CAM_MDP, "mm_cam_mdp", "mm_sel", 2),
> + GATE_MM0(CLK_MM_MDP_RDMA0, "mm_mdp_rdma0", "mm_sel", 3),
> + GATE_MM0(CLK_MM_MDP_RDMA1, "mm_mdp_rdma1", "mm_sel", 4),
> + GATE_MM0(CLK_MM_MDP_RSZ0, "mm_mdp_rsz0", "mm_sel", 5),
> + GATE_MM0(CLK_MM_MDP_RSZ1, "mm_mdp_rsz1", "mm_sel", 6),
> + GATE_MM0(CLK_MM_MDP_RSZ2, "mm_mdp_rsz2", "mm_sel", 7),
> + GATE_MM0(CLK_MM_MDP_TDSHP0, "mm_mdp_tdshp0", "mm_sel", 8),
> + GATE_MM0(CLK_MM_MDP_TDSHP1, "mm_mdp_tdshp1", "mm_sel", 9),
> + GATE_MM0(CLK_MM_MDP_WDMA, "mm_mdp_wdma", "mm_sel", 11),
> + GATE_MM0(CLK_MM_MDP_WROT0, "mm_mdp_wrot0", "mm_sel", 12),
> + GATE_MM0(CLK_MM_MDP_WROT1, "mm_mdp_wrot1", "mm_sel", 13),
> + GATE_MM0(CLK_MM_FAKE_ENG, "mm_fake_eng", "mm_sel", 14),
> + GATE_MM0(CLK_MM_MUTEX_32K, "mm_mutex_32k", "rtc_sel", 15),
> + GATE_MM0(CLK_MM_DISP_OVL0, "mm_disp_ovl0", "mm_sel", 16),
> + GATE_MM0(CLK_MM_DISP_OVL1, "mm_disp_ovl1", "mm_sel", 17),
> + GATE_MM0(CLK_MM_DISP_RDMA0, "mm_disp_rdma0", "mm_sel", 18),
> + GATE_MM0(CLK_MM_DISP_RDMA1, "mm_disp_rdma1", "mm_sel", 19),
> + GATE_MM0(CLK_MM_DISP_RDMA2, "mm_disp_rdma2", "mm_sel", 20),
> + GATE_MM0(CLK_MM_DISP_WDMA0, "mm_disp_wdma0", "mm_sel", 21),
> + GATE_MM0(CLK_MM_DISP_WDMA1, "mm_disp_wdma1", "m
Re: [PATCH v2 1/4] clk: mediatek: mt8173: Fix enabling of critical clocks
Hi James,
To be precise, it is the CLK_TOP clocks that have CLK_APMIXED PLLs as
their parents, so we cannot enable the CLK_TOP critical clocks until
the CLK_APMIXED clocks have all been registered.
Please add something like the above to the commit message.
More comments inline...
On Tue, Jun 30, 2015 at 10:58 AM, James Liao wrote:
> From: Sascha Hauer
>
> On the MT8173 the clocks are provided by different units. To enable
> the critical clocks we must be sure that all parent clocks are already
> registered, otherwise the parents of the critical clocks end up being
> unused and get disabled later. To find a place where all parents are
> registered we try each time after we've registered some clocks if
> all known providers are present now and only then we enable the critical
> clocks
>
> Signed-off-by: Sascha Hauer
> Signed-off-by: James Liao
> ---
> drivers/clk/mediatek/clk-mt8173.c | 26 +-
> 1 file changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt8173.c
> b/drivers/clk/mediatek/clk-mt8173.c
> index 4b9e04c..c483336 100644
> --- a/drivers/clk/mediatek/clk-mt8173.c
> +++ b/drivers/clk/mediatek/clk-mt8173.c
> @@ -700,6 +700,22 @@ static const struct mtk_composite peri_clks[]
> __initconst = {
> MUX(CLK_PERI_UART3_SEL, "uart3_ck_sel", uart_ck_sel_parents, 0x40c,
> 3, 1),
> };
>
> +static struct clk_onecell_data *mt8173_top_clk_data;
> +static struct clk_onecell_data *mt8173_pll_clk_data;
These globals can be:
__initdata
> +
> +static void mtk_clk_enable_critical(void)
And this function is:
static void __init
Other than the above, this one is:
Reviewed-by: Daniel Kurtz
-Dan
> +{
> + if (!mt8173_top_clk_data || !mt8173_pll_clk_data)
> + return;
> +
> + clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
> + clk_prepare_enable(mt8173_pll_clk_data->clks[CLK_APMIXED_ARMCA7PLL]);
> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_MEM_SEL]);
> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_DDRPHYCFG_SEL]);
> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_CCI400_SEL]);
> + clk_prepare_enable(mt8173_top_clk_data->clks[CLK_TOP_RTC_SEL]);
> +}
> +
> static void __init mtk_topckgen_init(struct device_node *node)
> {
> struct clk_onecell_data *clk_data;
> @@ -712,19 +728,19 @@ static void __init mtk_topckgen_init(struct device_node
> *node)
> return;
> }
>
> - clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
> + mt8173_top_clk_data = clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
>
> mtk_clk_register_factors(root_clk_alias, ARRAY_SIZE(root_clk_alias),
> clk_data);
> mtk_clk_register_factors(top_divs, ARRAY_SIZE(top_divs), clk_data);
> mtk_clk_register_composites(top_muxes, ARRAY_SIZE(top_muxes), base,
> &mt8173_clk_lock, clk_data);
>
> - clk_prepare_enable(clk_data->clks[CLK_TOP_CCI400_SEL]);
> -
> r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> if (r)
> pr_err("%s(): could not register clock provider: %d\n",
> __func__, r);
> +
> + mtk_clk_enable_critical();
> }
> CLK_OF_DECLARE(mtk_topckgen, "mediatek,mt8173-topckgen", mtk_topckgen_init);
>
> @@ -818,13 +834,13 @@ static void __init mtk_apmixedsys_init(struct
> device_node *node)
> {
> struct clk_onecell_data *clk_data;
>
> - clk_data = mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
> + mt8173_pll_clk_data = clk_data =
> mtk_alloc_clk_data(CLK_APMIXED_NR_CLK);
> if (!clk_data)
> return;
>
> mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
>
> - clk_prepare_enable(clk_data->clks[CLK_APMIXED_ARMCA15PLL]);
> + mtk_clk_enable_critical();
> }
> CLK_OF_DECLARE(mtk_apmixedsys, "mediatek,mt8173-apmixedsys",
> mtk_apmixedsys_init);
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers
On Tue, Jun 30, 2015 at 10:58 AM, James Liao wrote:
>
> This adds the binding documentation for the mmsys, imgsys, vdecsys,
> vencsys and vencltsys controllers found on Mediatek SoCs.
>
> Signed-off-by: James Liao
> ---
> .../bindings/arm/mediatek/mediatek,imgsys.txt | 22
> ++
> .../bindings/arm/mediatek/mediatek,mmsys.txt | 22
> ++
> .../bindings/arm/mediatek/mediatek,vdecsys.txt | 22
> ++
> .../bindings/arm/mediatek/mediatek,vencltsys.txt | 22
> ++
> .../bindings/arm/mediatek/mediatek,vencsys.txt | 22
> ++
> 5 files changed, 110 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
> create mode 100644
> Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
>
> diff --git
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
> new file mode 100644
> index 000..7612bac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
> @@ -0,0 +1,22 @@
> +Mediatek imgsys controller
> +
> +
> +The Mediatek imgsys controller provides various clocks to the system.
> +
> +Required Properties:
> +
> +- compatible: Should be:
> + - "mediatek,mt8173-imgsys", "syscon"
> +- #clock-cells: Must be 1
> +
> +The imgsys controller uses the common clk binding from
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +The available clocks are defined in dt-bindings/clock/mt*-clk.h.
> +
> +Example:
> +
> +imgsys: imgsys@1500 {
Since these nodes will be supplying clocks to the rest of the system,
I think the "name" part of each of these should all be
"clock-controller", like topckgen and apmixedsys:
imgsys: clock-controller@1500 {
-Dan
>
> + compatible = "mediatek,mt8173-imgsys", "syscon";
> + reg = <0 0x1500 0 0x1000>;
> + #clock-cells = <1>;
> +};
> diff --git
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> new file mode 100644
> index 000..b51e417
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
> @@ -0,0 +1,22 @@
> +Mediatek mmsys controller
> +
> +
> +The Mediatek mmsys controller provides various clocks to the system.
> +
> +Required Properties:
> +
> +- compatible: Should be:
> + - "mediatek,mt8173-mmsys", "syscon"
> +- #clock-cells: Must be 1
> +
> +The mmsys controller uses the common clk binding from
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +The available clocks are defined in dt-bindings/clock/mt*-clk.h.
> +
> +Example:
> +
> +mmsys: mmsys@1400 {
> + compatible = "mediatek,mt8173-mmsys", "syscon";
> + reg = <0 0x1400 0 0x1000>;
> + #clock-cells = <1>;
> +};
> diff --git
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
> new file mode 100644
> index 000..a5b94a7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
> @@ -0,0 +1,22 @@
> +Mediatek vdecsys controller
> +
> +
> +The Mediatek vdecsys controller provides various clocks to the system.
> +
> +Required Properties:
> +
> +- compatible: Should be:
> + - "mediatek,mt8173-vdecsys", "syscon"
> +- #clock-cells: Must be 1
> +
> +The vdecsys controller uses the common clk binding from
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +The available clocks are defined in dt-bindings/clock/mt*-clk.h.
> +
> +Example:
> +
> +vdecsys: vdecsys@1600 {
> + compatible = "mediatek,mt8173-vdecsys", "syscon";
> + reg = <0 0x1600 0 0x1000>;
> + #clock-cells = <1>;
> +};
> diff --git
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
> new file mode 100644
> index 000..3d4e8d8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
> @@ -0,0 +1,22 @@
> +Mediatek vencltsys controller
> +
> +
> +The Mediatek vencltsys controller provides various clocks to the system.
> +
> +Required Properties:
> +
> +- compatible: Should be:
> + - "mediatek,mt8173-vencltsys", "syscon"
> +- #clock-cells: Must be 1
> +
> +The vencltsys controller uses the common clk binding from
> +Documentation/devicetree/bindings/clock/clock-b
Re: [PATCH] arm64: dts: mt8173: add clock_null
On Wed, Jul 1, 2015 at 2:49 PM, Sascha Hauer wrote:
>
> On Tue, Jun 30, 2015 at 05:07:09PM +0800, James Liao wrote:
> > Hi Heiko,
> >
> > There are 4 clocks which are derived from clk_null directly in current
> > topckgen implementation:
> >
> > clkph_mck_o, dpi_ck, usb_syspll_125m, hdmitx_dig_cts
> >
> > Our designer mentioned 2 things about external clocks:
> >
> > 1. These 4 clocks come from analog macro, not from PLL, nor from
> > external clocks directly.
>
> Ok, this means there actually are clocks. We can't control these clock and
> they have some known or unknown rate. This makes them fixed clocks. Just
> specify them in the device tree and you are done. Give them reasonable
> names and the rate if you know it, 0 otherwise.
>
> The problem is not that you use fixed clocks for non software
> controllable clocks of unknwown rates, but that you try to use a single
> clock for all of them and name it 'dummy' or 'null'. Name it
>
> dpi_ck {
> compatible = "fixed-clock";
> rate = <0>; /* unknown, generated by some Analog block */
> };
It would be nice, though, to use the real clock rates.
Otherwise, we end up with a bunch of unknown clock rates, like this:
clock enable_cnt prepare_cntrate
accuracy phase
clk_null 22 0
0 0
mm_lvds_cts 00 0
0 0
mm_lvds_pixel 00 0
0 0
mm_dpi1_pixel 00 0
0 0
mm_dsi1_digital 00 0
0 0
mm_dsi0_digital 11 0
0 0
infra_cpum00 0
0 0
hdmitx_dig_cts00 0
0 0
hdmi_sel 00 0
0 0
mm_hdmi_pllck 00 0
0 0
hdmitxpll_d3 00 0
0 0
hdmitxpll_d2 00 0
0 0
usb_syspll_125m 00 0
0 0
dpi_ck00 0
0 0
clkph_mck_o 11 0
0 0
dmpll_d16 00 0
0 0
dmpll_d8 00 0
0 0
dmpll_d4 00 0
0 0
dmpll_d2 00 0
0 0
dmpll_ck 11 0
0 0
mem_sel 22 0
0 0
infra_m4u11 0
0 0
Furthermore, at least some of these children clocks are possible
source clocks for other clocks for which we do want to know the
resulting frequency. For example, the "dmpll_*" clocks are mux inputs
for many of the subsystem clocks.
-Dan
>
> Technically it's the same, but it sounds much more professional and like
> you know what you are doing ;)
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] spi: mediatek: Add spi bus for Mediatek MT8173
Hi Leilk, Please see comments inline... On Mon, Jun 29, 2015 at 9:04 PM, Leilk Liu wrote: > This patch adds basic spi bus for MT8173. > > Signed-off-by: Leilk Liu > Signed-off-by: Eddie Huang > --- > drivers/spi/Kconfig | 9 + > drivers/spi/Makefile | 1 + > drivers/spi/spi-mt65xx.c | 656 > +++ > 3 files changed, 666 insertions(+) > create mode 100644 drivers/spi/spi-mt65xx.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 198f96b..06f9514 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -324,6 +324,15 @@ config SPI_MESON_SPIFC > This enables master mode support for the SPIFC (SPI flash > controller) available in Amlogic Meson SoCs. > > +config SPI_MT65XX > + tristate "MediaTek SPI controller" > + depends on ARCH_MEDIATEK || COMPILE_TEST > + help > + This selects the MediaTek(R) SPI bus driver. > + If you want to use MediaTek(R) SPI interface, > + say Y or M here.If you are not sure, say N. > + SPI drivers for Mediatek mt65XX series ARM SoCs. > + > config SPI_OC_TINY > tristate "OpenCores tiny SPI" > depends on GPIOLIB > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index d8cbf65..ab332ef 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -48,6 +48,7 @@ obj-$(CONFIG_SPI_MESON_SPIFC) += spi-meson-spifc.o > obj-$(CONFIG_SPI_MPC512x_PSC) += spi-mpc512x-psc.o > obj-$(CONFIG_SPI_MPC52xx_PSC) += spi-mpc52xx-psc.o > obj-$(CONFIG_SPI_MPC52xx) += spi-mpc52xx.o > +obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o > obj-$(CONFIG_SPI_MXS) += spi-mxs.o > obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o > obj-$(CONFIG_SPI_OC_TINY) += spi-oc-tiny.o > diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c > new file mode 100644 > index 000..6cb54587 > --- /dev/null > +++ b/drivers/spi/spi-mt65xx.c > @@ -0,0 +1,656 @@ > +/* > + * Copyright (c) 2015 MediaTek Inc. > + * Author: Leilk Liu > + * > + * 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 > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include It would be nicer if you can alphabetize these headers. > + > +#define SPI_CFG0_REG 0x > +#define SPI_CFG1_REG 0x0004 > +#define SPI_TX_SRC_REG0x0008 > +#define SPI_RX_DST_REG0x000c > +#define SPI_CMD_REG 0x0018 > +#define SPI_STATUS0_REG 0x001c > +#define SPI_PAD_SEL_REG 0x0024 > + > +#define SPI_CFG0_SCK_HIGH_OFFSET 0 > +#define SPI_CFG0_SCK_LOW_OFFSET 8 > +#define SPI_CFG0_CS_HOLD_OFFSET 16 > +#define SPI_CFG0_CS_SETUP_OFFSET 24 > + > +#define SPI_CFG0_SCK_HIGH_MASK0xff > +#define SPI_CFG0_SCK_LOW_MASK 0xff00 > +#define SPI_CFG0_CS_HOLD_MASK 0xff > +#define SPI_CFG0_CS_SETUP_MASK0xff00 > + > +#define SPI_CFG1_CS_IDLE_OFFSET 0 > +#define SPI_CFG1_PACKET_LOOP_OFFSET 8 > +#define SPI_CFG1_PACKET_LENGTH_OFFSET 16 > +#define SPI_CFG1_GET_TICK_DLY_OFFSET 30 > + > +#define SPI_CFG1_CS_IDLE_MASK 0xff > +#define SPI_CFG1_PACKET_LOOP_MASK 0xff00 > +#define SPI_CFG1_PACKET_LENGTH_MASK 0x3ff > +#define SPI_CFG1_GET_TICK_DLY_MASK0xc000 > + > +#define SPI_CMD_ACT_OFFSET0 > +#define SPI_CMD_RESUME_OFFSET 1 > +#define SPI_CMD_RST_OFFSET2 > +#define SPI_CMD_PAUSE_EN_OFFSET 4 > +#define SPI_CMD_DEASSERT_OFFSET 5 > +#define SPI_CMD_CPHA_OFFSET 8 > +#define SPI_CMD_CPOL_OFFSET 9 > +#define SPI_CMD_RX_DMA_OFFSET 10 > +#define SPI_CMD_TX_DMA_OFFSET 11 > +#define SPI_CMD_TXMSBF_OFFSET 12 > +#define SPI_CMD_RXMSBF_OFFSET 13 > +#define SPI_CMD_RX_ENDIAN_OFFSET 14 > +#define SPI_CMD_TX_ENDIAN_OFFSET 15 > +#define SPI_CMD_FINISH_IE_OFFSET 16 > +#define SPI_CMD_PAUSE_IE_OFFSET 17 > + > +#define SPI_CMD_RST_MASK 0x4 > +#define SPI_CMD_PAUSE_EN_MASK 0x10 > +#d
