* Re: [PATCH v1 6/7] MAINTAINERS: update entry for PIN CONTROLLER - MEDIATEK
From: Linus Walleij @ 2018-05-24 7:41 UTC (permalink / raw)
To: Sean Wang
Cc: Rob Herring, Mark Rutland, Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support, Linux ARM,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org
In-Reply-To: <e5bcfc9671a79fef4f38933bb04894f0f53b3d63.1526835466.git.sean.wang@mediatek.com>
On Sun, May 20, 2018 at 7:01 PM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add new files for the entry
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [RESEND PATCH 2/5] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver
From: Benjamin Lindqvist @ 2018-05-24 7:40 UTC (permalink / raw)
To: Stefan Agner
Cc: boris.brezillon, dwmw2, computersforpeace, marek.vasut, robh+dt,
mark.rutland, thierry.reding, mturquette, sboyd, Lucas Stach,
miquel.raynal, richard, marcel, krzk, digetx, jonathanh,
pdeschrijver, pgaikwad, Mirza Krak, linux-mtd, linux-tegra,
devicetree, linux-kernel, linux-clk
In-Reply-To: <86fdf19ec92b732709732fb60199f16488b4b727.1526990589.git.stefan@agner.ch>
[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]
Hi Stefan (and all),
First off, I apoloigize in advance if I'm deviating from common kernel
mailing list courtesy -- this is my first time responding. I just have a
comment on the NAND driver that I'd like to bring to the public.
> + switch (mtd->oobsize) {
> ...
> + case 224:
> + mtd_set_ooblayout(mtd, &tegra_nand_oob_224_ops);
> + chip->ecc.strength = 8;
> + chip->ecc.bytes = 18;
> + value |= CFG_ECC_SEL | CFG_TVAL_8;
> + break; + case 224:
I am not sure how you arrived at this oobsize-based inference. I have not
seen any explicit relation between oob size and ECC algorithm used in the
reference manual. Indeed, the U-Boot I was working on (a fork of the
Toradex 2015.04 U-Boot) always has oobsize == 224 but used either BCH[t=16]
or RS[t=4]. In fact, we tried choosing RS[t=8] in U-Boot but we failed to
make the BootROM decode this at all. So we had to use RS[t=4]. But changing
the algorithm did not automatically change the oobsize, at least it didn't
for us. So maybe you should consider if this is really the way to go about
deciding which algorithm is used.
Note that we're in fact using this patch set in Linux today, but we had to
remove the oobsize inference part. Currently we're simply hard coding it to
CFG_TVAL_4, but maybe it would be cleaner to add ECC algo as a board config
instead, e.g. in the .dts file or whatever. This seems to be done by other
vendors already, see for example excerpt of
Documentation/devicetree/bindings/mtd/gpmc-nand.txt
below:
- ti,nand-ecc-opt: A string setting the ECC layout to use. One of:
"sw" 1-bit Hamming ecc code via software
"hw" <deprecated> use "ham1" instead
"hw-romcode" <deprecated> use "ham1" instead
"ham1" 1-bit Hamming ecc code
"bch4" 4-bit BCH ecc code
"bch8" 8-bit BCH ecc code
"bch16" 16-bit BCH ECC code
Refer below "How to select correct ECC scheme for your device ?"
It seems as if this method would be equally applicable to Tegra NAND.
Best regards,
Benjamin
[-- Attachment #2: Type: text/html, Size: 10245 bytes --]
^ permalink raw reply
* Re: [PATCH v1 5/7] pinctrl: mediatek: remove unused fields in struct mtk_eint_hw
From: Linus Walleij @ 2018-05-24 7:40 UTC (permalink / raw)
To: Sean Wang
Cc: Rob Herring, Mark Rutland, Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support, Linux ARM,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org
In-Reply-To: <72462fb7aab16463a42066998ac3b4bf35ada416.1526835466.git.sean.wang@mediatek.com>
On Sun, May 20, 2018 at 7:01 PM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> The .name field has been not being used in existent code logic, so
> it's better that we remove them all.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 4/7] pinctrl: mediatek: use generic EINT register maps for each SoC
From: Linus Walleij @ 2018-05-24 7:39 UTC (permalink / raw)
To: Sean Wang
Cc: Rob Herring, Mark Rutland, Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support, Linux ARM,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org
In-Reply-To: <39738efefe94e3a4fb7668a27dd73ae49695dc3b.1526835466.git.sean.wang@mediatek.com>
On Sun, May 20, 2018 at 7:01 PM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> So far, EINT on each SoC all used exactly identical register map and thus
> it's better that we apply generic register map already supported in EINT
> library and stop copy-n-pasting the same data block and filling into its
> platform data.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 3/7] pinctrl: mediatek: add EINT support to MT7622 SoC
From: Linus Walleij @ 2018-05-24 7:38 UTC (permalink / raw)
To: Sean Wang
Cc: Rob Herring, Mark Rutland, Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support, Linux ARM,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org
In-Reply-To: <2d02c8e5c4c6b2f783ad55b887ce38d130be2a3f.1526835466.git.sean.wang@mediatek.com>
On Sun, May 20, 2018 at 7:01 PM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Add EINT support to MT7622 SoC and the support is made as just an option
> to MT7622 pinctrl.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 2/7] pinctrl: mediatek: refactor EINT related code for all MediaTek pinctrl can fit
From: Linus Walleij @ 2018-05-24 7:37 UTC (permalink / raw)
To: Sean Wang
Cc: Rob Herring, Mark Rutland, Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support, Linux ARM,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org
In-Reply-To: <7265772c758d4c56cabb95fda708550bc4d2fcb5.1526835466.git.sean.wang@mediatek.com>
On Sun, May 20, 2018 at 7:01 PM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> This patch is in preparation for adding EINT support to MT7622 pinctrl,
> and the refactoring doesn't alter any existent logic.
>
> A reason we have to refactor EINT code pieces into a generic way is that
> currently, they're tightly coupled with a certain type of MediaTek pinctrl
> would cause a grown in a very bad way as there is different types of
> pinctrl devices getting to join.
>
> Therefore, it is an essential or urgent thing that EINT code pieces are
> refactored to eliminate any dependencies across GPIO and EINT as possible.
>
> Additional structure mtk_eint_[xt, hw, regs] are being introduced for
> indicating how maps being designed between GPIO and EINT hw number, how to
> set and get GPIO state for a certain EINT pin, what characteristic on a
> EINT device is present on various SoCs.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 1/7] dt-bindings: pinctrl: add external interrupt support to MT7622 pinctrl
From: Linus Walleij @ 2018-05-24 7:36 UTC (permalink / raw)
To: Sean Wang
Cc: Rob Herring, Mark Rutland, Matthias Brugger,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Mediatek SoC support, Linux ARM,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org
In-Reply-To: <3898620ef606004aaddc332591ca467f56773029.1526835466.git.sean.wang@mediatek.com>
On Sun, May 20, 2018 at 7:01 PM, <sean.wang@mediatek.com> wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> Extend the capability of MT7622 pinctrl with adding EINT so that each
> GPIO can be used to notify CPU when a signal state is changing on the
> line as an external interrupt.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Patch applied with Rob's review tag.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2] ARM: pxa: dts: add pin definitions for extended GPIOs
From: Robert Jarzmik @ 2018-05-24 7:28 UTC (permalink / raw)
To: Daniel Mack; +Cc: devicetree, robh+dt, linux-arm-kernel, haojian.zhuang
In-Reply-To: <20180522202232.7981-1-daniel@zonque.org>
Daniel Mack <daniel@zonque.org> writes:
> The PXA3xx series features some extended GPIO banks which are named GPIO0_2,
> GPIO1_2 etc. The PXA300, PXA310 and PXA320 have different numbers of such
> pins, and they also have variant-specific register offsets.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
Applied to pxa/dt, thanks.
Cheers.
--
Robert
^ permalink raw reply
* Re: [PATCH RFC 00/24] Lima DRM driver
From: Daniel Vetter @ 2018-05-24 7:25 UTC (permalink / raw)
To: Christian König
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Qiang Yu, Erico Nunes
In-Reply-To: <cfc190af-1d46-7dca-fded-19b3b7896166@amd.com>
On Thu, May 24, 2018 at 8:27 AM, Christian König
<christian.koenig@amd.com> wrote:
> Am 24.05.2018 um 02:31 schrieb Qiang Yu:
>>
>> On Wed, May 23, 2018 at 11:44 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>>
>>> On Wed, May 23, 2018 at 3:52 PM, Qiang Yu <yuq825@gmail.com> wrote:
>>>>
>>>> On Wed, May 23, 2018 at 5:29 PM, Christian König
>>>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>>>>
>>>>> Am 18.05.2018 um 11:27 schrieb Qiang Yu:
>>>>>>
>>>>>> Kernel DRM driver for ARM Mali 400/450 GPUs.
>>>>>>
>>>>>> This implementation mainly take amdgpu DRM driver as reference.
>>>>>>
>>>>>> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
>>>>>> OpenGL vertex shader processing and PP is for fragment shader
>>>>>> processing. Each processor has its own MMU so prcessors work in
>>>>>> virtual address space.
>>>>>> - There's only one GP but multiple PP (max 4 for mali 400 and 8
>>>>>> for mali 450) in the same mali 4xx GPU. All PPs are grouped
>>>>>> togather to handle a single fragment shader task divided by
>>>>>> FB output tiled pixels. Mali 400 user space driver is
>>>>>> responsible for assign target tiled pixels to each PP, but mali
>>>>>> 450 has a HW module called DLBU to dynamically balance each
>>>>>> PP's load.
>>>>>> - User space driver allocate buffer object and map into GPU
>>>>>> virtual address space, upload command stream and draw data with
>>>>>> CPU mmap of the buffer object, then submit task to GP/PP with
>>>>>> a register frame indicating where is the command stream and misc
>>>>>> settings.
>>>>>> - There's no command stream validation/relocation due to each user
>>>>>> process has its own GPU virtual address space. GP/PP's MMU switch
>>>>>> virtual address space before running two tasks from different
>>>>>> user process. Error or evil user space code just get MMU fault
>>>>>> or GP/PP error IRQ, then the HW/SW will be recovered.
>>>>>> - Use TTM as MM. TTM_PL_TT type memory is used as the content of
>>>>>> lima buffer object which is allocated from TTM page pool. all
>>>>>> lima buffer object gets pinned with TTM_PL_FLAG_NO_EVICT when
>>>>>> allocation, so there's no buffer eviction and swap for now. We
>>>>>> need reverse engineering to see if and how GP/PP support MMU
>>>>>> fault recovery (continue execution). Otherwise we have to
>>>>>> pin/unpin each envolved buffer when task creation/deletion.
>>>>>
>>>>>
>>>>> Well pinning all memory is usually a no-go for upstreaming. But since
>>>>> you
>>>>> are already using the drm_sched for GPU task scheduling why are you
>>>>> actually
>>>>> needing this?
>>>>>
>>>>> The scheduler should take care of signaling all fences when the
>>>>> hardware is
>>>>> done with it's magic and that is enough for TTM to note that a buffer
>>>>> object
>>>>> is movable again (e.g. unpin them).
>>>>
>>>> Please correct me if I'm wrong.
>>>>
>>>> One way to implement eviction/swap is like this:
>>>> call validation on each buffers involved in a task, but this won't
>>>> prevent it from
>>>> eviction/swap when executing, so a GPU MMU fault may happen and in the
>>>> handler we need to recover the buffer evicted/swapped.
>>>>
>>>> Another way is pin/unpin buffers evolved when task create/free.
>>>>
>>>> First way is better when memory load is low and second way is better
>>>> when
>>>> memory load is high. First way also need less memory.
>>>>
>>>> So I'd prefer first way but due to the GPU MMU fault
>>>> HW op need reverse engineering, I have to pin all buffers now. After
>>>> the HW op is clear, I can choose one way to implement.
>>>
>>> All the drivers using ttm have something that looks like vram, or a
>>> requirement to move buffers around. Afaiui that includes virtio drm
>>> driver.
>>
>> Does virtio drm driver need to move buffers around? amdgpu also
>> has no vram when APU.
Afaiui APUs have a range of stolen memory which looks and acts and is
managed like discrete vram. Including moving buffers around.
>>> From your description you don't have such a requirement, and
>>> then doing what etnaviv has done would be a lot simpler. Everything
>>> that's not related to buffer movement handling is also available
>>> outside of ttm already.
>>
>> Yeah, I could do like etnaviv, but it's not simpler than using ttm
>> directly especially want some optimization (like ttm page pool,
>> ttm_eu_reserve_buffers, ttm_bo_mmap). If I have/want to implement
>> them, why not just use TTM directly with all those helper functions.
>
>
> Well TTM has some design flaws (e.g. heavily layered design etc...), but it
> also offers some rather nice functionality.
Yeah, but I still think that for non-discrete drivers just moving a
bunch of more of the neat ttm functionality into helpers where
everyone can use them (instead of the binary ttm y/n decision) would
be much better. E.g. the allocator pool definitely sounds like
something gem helpers should be able to do, same for reserving a pile
of buffers or default mmap implementations. A lot of that also exists
already, thanks to lots of efforts from Noralf Tronnes and others.
I think ideally the long-term goal would be to modularize ttm concepts
as much as possible, so that drivers can flexibly pick&choose the bits
they need. We're slowly getting there (but definitely not yet there if
you need to manage discrete vram I think).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH V4 1/8] net: ethernet: stmmac: add adaptation for stm32mp157c.
From: Alexandre Torgue @ 2018-05-24 7:24 UTC (permalink / raw)
To: Christophe Roullier, mark.rutland, mcoquelin.stm32,
peppe.cavallaro
Cc: devicetree, linux-arm-kernel, netdev, andrew
In-Reply-To: <1527090479-5263-2-git-send-email-christophe.roullier@st.com>
Hi,
On 05/23/2018 05:47 PM, Christophe Roullier wrote:
> Glue codes to support stm32mp157c device and stay
> compatible with stm32 mcu family
>
> Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
> ---
Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
> drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 270 ++++++++++++++++++++--
> 1 file changed, 255 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
> index 9e6db16..f51e327 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
> @@ -16,49 +16,183 @@
> #include <linux/of_net.h>
> #include <linux/phy.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_wakeirq.h>
> #include <linux/regmap.h>
> #include <linux/slab.h>
> #include <linux/stmmac.h>
>
> #include "stmmac_platform.h"
>
> -#define MII_PHY_SEL_MASK BIT(23)
> +#define SYSCFG_MCU_ETH_MASK BIT(23)
> +#define SYSCFG_MP1_ETH_MASK GENMASK(23, 16)
> +
> +#define SYSCFG_PMCR_ETH_CLK_SEL BIT(16)
> +#define SYSCFG_PMCR_ETH_REF_CLK_SEL BIT(17)
> +#define SYSCFG_PMCR_ETH_SEL_MII BIT(20)
> +#define SYSCFG_PMCR_ETH_SEL_RGMII BIT(21)
> +#define SYSCFG_PMCR_ETH_SEL_RMII BIT(23)
> +#define SYSCFG_PMCR_ETH_SEL_GMII 0
> +#define SYSCFG_MCU_ETH_SEL_MII 0
> +#define SYSCFG_MCU_ETH_SEL_RMII 1
>
> struct stm32_dwmac {
> struct clk *clk_tx;
> struct clk *clk_rx;
> + struct clk *clk_eth_ck;
> + struct clk *clk_ethstp;
> + struct clk *syscfg_clk;
> + bool int_phyclk; /* Clock from RCC to drive PHY */
> u32 mode_reg; /* MAC glue-logic mode register */
> struct regmap *regmap;
> u32 speed;
> + const struct stm32_ops *ops;
> + struct device *dev;
> +};
> +
> +struct stm32_ops {
> + int (*set_mode)(struct plat_stmmacenet_data *plat_dat);
> + int (*clk_prepare)(struct stm32_dwmac *dwmac, bool prepare);
> + int (*suspend)(struct stm32_dwmac *dwmac);
> + void (*resume)(struct stm32_dwmac *dwmac);
> + int (*parse_data)(struct stm32_dwmac *dwmac,
> + struct device *dev);
> + u32 syscfg_eth_mask;
> };
>
> static int stm32_dwmac_init(struct plat_stmmacenet_data *plat_dat)
> {
> struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
> - u32 reg = dwmac->mode_reg;
> - u32 val;
> int ret;
>
> - val = (plat_dat->interface == PHY_INTERFACE_MODE_MII) ? 0 : 1;
> - ret = regmap_update_bits(dwmac->regmap, reg, MII_PHY_SEL_MASK, val);
> - if (ret)
> - return ret;
> + if (dwmac->ops->set_mode) {
> + ret = dwmac->ops->set_mode(plat_dat);
> + if (ret)
> + return ret;
> + }
>
> ret = clk_prepare_enable(dwmac->clk_tx);
> if (ret)
> return ret;
>
> - ret = clk_prepare_enable(dwmac->clk_rx);
> - if (ret)
> - clk_disable_unprepare(dwmac->clk_tx);
> + if (!dwmac->dev->power.is_suspended) {
> + ret = clk_prepare_enable(dwmac->clk_rx);
> + if (ret) {
> + clk_disable_unprepare(dwmac->clk_tx);
> + return ret;
> + }
> + }
> +
> + if (dwmac->ops->clk_prepare) {
> + ret = dwmac->ops->clk_prepare(dwmac, true);
> + if (ret) {
> + clk_disable_unprepare(dwmac->clk_rx);
> + clk_disable_unprepare(dwmac->clk_tx);
> + }
> + }
>
> return ret;
> }
>
> +static int stm32mp1_clk_prepare(struct stm32_dwmac *dwmac, bool prepare)
> +{
> + int ret = 0;
> +
> + if (prepare) {
> + ret = clk_prepare_enable(dwmac->syscfg_clk);
> + if (ret)
> + return ret;
> +
> + if (dwmac->int_phyclk) {
> + ret = clk_prepare_enable(dwmac->clk_eth_ck);
> + if (ret) {
> + clk_disable_unprepare(dwmac->syscfg_clk);
> + return ret;
> + }
> + }
> + } else {
> + clk_disable_unprepare(dwmac->syscfg_clk);
> + if (dwmac->int_phyclk)
> + clk_disable_unprepare(dwmac->clk_eth_ck);
> + }
> + return ret;
> +}
> +
> +static int stm32mp1_set_mode(struct plat_stmmacenet_data *plat_dat)
> +{
> + struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
> + u32 reg = dwmac->mode_reg;
> + int val;
> +
> + switch (plat_dat->interface) {
> + case PHY_INTERFACE_MODE_MII:
> + val = SYSCFG_PMCR_ETH_SEL_MII;
> + pr_debug("SYSCFG init : PHY_INTERFACE_MODE_MII\n");
> + break;
> + case PHY_INTERFACE_MODE_GMII:
> + val = SYSCFG_PMCR_ETH_SEL_GMII;
> + if (dwmac->int_phyclk)
> + val |= SYSCFG_PMCR_ETH_CLK_SEL;
> + pr_debug("SYSCFG init : PHY_INTERFACE_MODE_GMII\n");
> + break;
> + case PHY_INTERFACE_MODE_RMII:
> + val = SYSCFG_PMCR_ETH_SEL_RMII;
> + if (dwmac->int_phyclk)
> + val |= SYSCFG_PMCR_ETH_REF_CLK_SEL;
> + pr_debug("SYSCFG init : PHY_INTERFACE_MODE_RMII\n");
> + break;
> + case PHY_INTERFACE_MODE_RGMII:
> + case PHY_INTERFACE_MODE_RGMII_ID:
> + case PHY_INTERFACE_MODE_RGMII_RXID:
> + case PHY_INTERFACE_MODE_RGMII_TXID:
> + val = SYSCFG_PMCR_ETH_SEL_RGMII;
> + if (dwmac->int_phyclk)
> + val |= SYSCFG_PMCR_ETH_CLK_SEL;
> + pr_debug("SYSCFG init : PHY_INTERFACE_MODE_RGMII\n");
> + break;
> + default:
> + pr_debug("SYSCFG init : Do not manage %d interface\n",
> + plat_dat->interface);
> + /* Do not manage others interfaces */
> + return -EINVAL;
> + }
> +
> + return regmap_update_bits(dwmac->regmap, reg,
> + dwmac->ops->syscfg_eth_mask, val);
> +}
> +
> +static int stm32mcu_set_mode(struct plat_stmmacenet_data *plat_dat)
> +{
> + struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
> + u32 reg = dwmac->mode_reg;
> + int val;
> +
> + switch (plat_dat->interface) {
> + case PHY_INTERFACE_MODE_MII:
> + val = SYSCFG_MCU_ETH_SEL_MII;
> + pr_debug("SYSCFG init : PHY_INTERFACE_MODE_MII\n");
> + break;
> + case PHY_INTERFACE_MODE_RMII:
> + val = SYSCFG_MCU_ETH_SEL_RMII;
> + pr_debug("SYSCFG init : PHY_INTERFACE_MODE_RMII\n");
> + break;
> + default:
> + pr_debug("SYSCFG init : Do not manage %d interface\n",
> + plat_dat->interface);
> + /* Do not manage others interfaces */
> + return -EINVAL;
> + }
> +
> + return regmap_update_bits(dwmac->regmap, reg,
> + dwmac->ops->syscfg_eth_mask, val);
> +}
> +
> static void stm32_dwmac_clk_disable(struct stm32_dwmac *dwmac)
> {
> clk_disable_unprepare(dwmac->clk_tx);
> clk_disable_unprepare(dwmac->clk_rx);
> +
> + if (dwmac->ops->clk_prepare)
> + dwmac->ops->clk_prepare(dwmac, false);
> }
>
> static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
> @@ -70,15 +204,22 @@ static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
> /* Get TX/RX clocks */
> dwmac->clk_tx = devm_clk_get(dev, "mac-clk-tx");
> if (IS_ERR(dwmac->clk_tx)) {
> - dev_err(dev, "No tx clock provided...\n");
> + dev_err(dev, "No ETH Tx clock provided...\n");
> return PTR_ERR(dwmac->clk_tx);
> }
> +
> dwmac->clk_rx = devm_clk_get(dev, "mac-clk-rx");
> if (IS_ERR(dwmac->clk_rx)) {
> - dev_err(dev, "No rx clock provided...\n");
> + dev_err(dev, "No ETH Rx clock provided...\n");
> return PTR_ERR(dwmac->clk_rx);
> }
>
> + if (dwmac->ops->parse_data) {
> + err = dwmac->ops->parse_data(dwmac, dev);
> + if (err)
> + return err;
> + }
> +
> /* Get mode register */
> dwmac->regmap = syscon_regmap_lookup_by_phandle(np, "st,syscon");
> if (IS_ERR(dwmac->regmap))
> @@ -91,11 +232,46 @@ static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
> return err;
> }
>
> +static int stm32mp1_parse_data(struct stm32_dwmac *dwmac,
> + struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> +
> + dwmac->int_phyclk = of_property_read_bool(np, "st,int-phyclk");
> +
> + /* Check if internal clk from RCC selected */
> + if (dwmac->int_phyclk) {
> + /* Get ETH_CLK clocks */
> + dwmac->clk_eth_ck = devm_clk_get(dev, "eth-ck");
> + if (IS_ERR(dwmac->clk_eth_ck)) {
> + dev_err(dev, "No ETH CK clock provided...\n");
> + return PTR_ERR(dwmac->clk_eth_ck);
> + }
> + }
> +
> + /* Clock used for low power mode */
> + dwmac->clk_ethstp = devm_clk_get(dev, "ethstp");
> + if (IS_ERR(dwmac->clk_ethstp)) {
> + dev_err(dev, "No ETH peripheral clock provided for CStop mode ...\n");
> + return PTR_ERR(dwmac->clk_ethstp);
> + }
> +
> + /* Clock for sysconfig */
> + dwmac->syscfg_clk = devm_clk_get(dev, "syscfg-clk");
> + if (IS_ERR(dwmac->syscfg_clk)) {
> + dev_err(dev, "No syscfg clock provided...\n");
> + return PTR_ERR(dwmac->syscfg_clk);
> + }
> +
> + return 0;
> +}
> +
> static int stm32_dwmac_probe(struct platform_device *pdev)
> {
> struct plat_stmmacenet_data *plat_dat;
> struct stmmac_resources stmmac_res;
> struct stm32_dwmac *dwmac;
> + const struct stm32_ops *data;
> int ret;
>
> ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> @@ -112,6 +288,16 @@ static int stm32_dwmac_probe(struct platform_device *pdev)
> goto err_remove_config_dt;
> }
>
> + data = of_device_get_match_data(&pdev->dev);
> + if (!data) {
> + dev_err(&pdev->dev, "no of match data provided\n");
> + ret = -EINVAL;
> + goto err_remove_config_dt;
> + }
> +
> + dwmac->ops = data;
> + dwmac->dev = &pdev->dev;
> +
> ret = stm32_dwmac_parse_data(dwmac, &pdev->dev);
> if (ret) {
> dev_err(&pdev->dev, "Unable to parse OF data\n");
> @@ -149,15 +335,48 @@ static int stm32_dwmac_remove(struct platform_device *pdev)
> return ret;
> }
>
> +static int stm32mp1_suspend(struct stm32_dwmac *dwmac)
> +{
> + int ret = 0;
> +
> + ret = clk_prepare_enable(dwmac->clk_ethstp);
> + if (ret)
> + return ret;
> +
> + clk_disable_unprepare(dwmac->clk_tx);
> + clk_disable_unprepare(dwmac->syscfg_clk);
> + if (dwmac->int_phyclk)
> + clk_disable_unprepare(dwmac->clk_eth_ck);
> +
> + return ret;
> +}
> +
> +static void stm32mp1_resume(struct stm32_dwmac *dwmac)
> +{
> + clk_disable_unprepare(dwmac->clk_ethstp);
> +}
> +
> +static int stm32mcu_suspend(struct stm32_dwmac *dwmac)
> +{
> + clk_disable_unprepare(dwmac->clk_tx);
> + clk_disable_unprepare(dwmac->clk_rx);
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_PM_SLEEP
> static int stm32_dwmac_suspend(struct device *dev)
> {
> struct net_device *ndev = dev_get_drvdata(dev);
> struct stmmac_priv *priv = netdev_priv(ndev);
> + struct stm32_dwmac *dwmac = priv->plat->bsp_priv;
> +
> int ret;
>
> ret = stmmac_suspend(dev);
> - stm32_dwmac_clk_disable(priv->plat->bsp_priv);
> +
> + if (dwmac->ops->suspend)
> + ret = dwmac->ops->suspend(dwmac);
>
> return ret;
> }
> @@ -166,8 +385,12 @@ static int stm32_dwmac_resume(struct device *dev)
> {
> struct net_device *ndev = dev_get_drvdata(dev);
> struct stmmac_priv *priv = netdev_priv(ndev);
> + struct stm32_dwmac *dwmac = priv->plat->bsp_priv;
> int ret;
>
> + if (dwmac->ops->resume)
> + dwmac->ops->resume(dwmac);
> +
> ret = stm32_dwmac_init(priv->plat);
> if (ret)
> return ret;
> @@ -181,8 +404,24 @@ static int stm32_dwmac_resume(struct device *dev)
> static SIMPLE_DEV_PM_OPS(stm32_dwmac_pm_ops,
> stm32_dwmac_suspend, stm32_dwmac_resume);
>
> +static struct stm32_ops stm32mcu_dwmac_data = {
> + .set_mode = stm32mcu_set_mode,
> + .suspend = stm32mcu_suspend,
> + .syscfg_eth_mask = SYSCFG_MCU_ETH_MASK
> +};
> +
> +static struct stm32_ops stm32mp1_dwmac_data = {
> + .set_mode = stm32mp1_set_mode,
> + .clk_prepare = stm32mp1_clk_prepare,
> + .suspend = stm32mp1_suspend,
> + .resume = stm32mp1_resume,
> + .parse_data = stm32mp1_parse_data,
> + .syscfg_eth_mask = SYSCFG_MP1_ETH_MASK
> +};
> +
> static const struct of_device_id stm32_dwmac_match[] = {
> - { .compatible = "st,stm32-dwmac"},
> + { .compatible = "st,stm32-dwmac", .data = &stm32mcu_dwmac_data},
> + { .compatible = "st,stm32mp1-dwmac", .data = &stm32mp1_dwmac_data},
> { }
> };
> MODULE_DEVICE_TABLE(of, stm32_dwmac_match);
> @@ -199,5 +438,6 @@ static SIMPLE_DEV_PM_OPS(stm32_dwmac_pm_ops,
> module_platform_driver(stm32_dwmac_driver);
>
> MODULE_AUTHOR("Alexandre Torgue <alexandre.torgue@gmail.com>");
> -MODULE_DESCRIPTION("STMicroelectronics MCU DWMAC Specific Glue layer");
> +MODULE_AUTHOR("Christophe Roullier <christophe.roullier@st.com>");
> +MODULE_DESCRIPTION("STMicroelectronics STM32 DWMAC Specific Glue layer");
> MODULE_LICENSE("GPL v2");
>
^ permalink raw reply
* Re: [PATCH V4 0/8] net: ethernet: stmmac: add support for stm32mp1
From: Alexandre Torgue @ 2018-05-24 7:22 UTC (permalink / raw)
To: David Miller, christophe.roullier
Cc: mark.rutland, mcoquelin.stm32, peppe.cavallaro, devicetree,
linux-arm-kernel, netdev, andrew
In-Reply-To: <20180523.160811.1425159248399846750.davem@davemloft.net>
On 05/23/2018 10:08 PM, David Miller wrote:
> From: Christophe Roullier <christophe.roullier@st.com>
> Date: Wed, 23 May 2018 17:47:51 +0200
>
>> Patches to have Ethernet support on stm32mp1
>> Changelog:
>> Remark from Rob Herring
>> Move Documentation/devicetree/bindings/arm/stm32.txt in
>> Documentation/devicetree/bindings/arm/stm32/stm32.txt and create
>> Documentation/devicetree/bindings/arm/stm32/stm32-syscon.txt
>>
>> Replace also in arch/arm/boot/dts/stm32mp157c.dtsi, syscfg: system-config@50020000
>> with syscfg: syscon@50020000syscfg: system-config@50020000
>
> Probably the DTS file updates need to go in via the ARM tree, not
> mine.
Yes I will take them in my tree
>
> Can you respin a net-next targetted series that has just the driver
> code and device tree binding updates?
>
> Thank you!
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* RE: [v4 3/6] dt-bindings: fsl-qdma: Add NXP Layerscpae qDMA controller bindings
From: Wen He @ 2018-05-24 7:20 UTC (permalink / raw)
To: Rob Herring
Cc: dmaengine@vger.kernel.org, devicetree@vger.kernel.org, Leo Li,
Jiafei Pan, Jiaheng Fan, Vinod
In-Reply-To: <CAL_JsqLyDaTqccYq16RHNmyEsRmg2D3rYVZv4K7ooSe9SQF1cw@mail.gmail.com>
> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: 2018年5月24日 3:59
> To: Wen He <wen.he_1@nxp.com>
> Cc: dmaengine@vger.kernel.org; devicetree@vger.kernel.org; Leo Li
> <leoyang.li@nxp.com>; Jiafei Pan <jiafei.pan@nxp.com>; Jiaheng Fan
> <jiaheng.fan@nxp.com>; Vinod <vkoul@kernel.org>
> Subject: Re: [v4 3/6] dt-bindings: fsl-qdma: Add NXP Layerscpae qDMA
> controller bindings
>
> Updated Vinod's email...
>
> On Mon, May 21, 2018 at 12:52 AM, Wen He <wen.he_1@nxp.com> wrote:
> > Hi Rob,
> >
> > Please see my comments inline.
> >
> > Best Regards,
> > Wen
> >
> >> -----Original Message-----
> >> From: Rob Herring [mailto:robh@kernel.org]
> >> Sent: 2018年5月19日 5:26
> >> To: Wen He <wen.he_1@nxp.com>
> >> Cc: vinod.koul@intel.com; dmaengine@vger.kernel.org;
> >> devicetree@vger.kernel.org; Leo Li <leoyang.li@nxp.com>; Jiafei Pan
> >> <jiafei.pan@nxp.com>; Jiaheng Fan <jiaheng.fan@nxp.com>
> >> Subject: Re: [v4 3/6] dt-bindings: fsl-qdma: Add NXP Layerscpae qDMA
> >> controller bindings
> >>
> >> On Mon, May 14, 2018 at 08:03:04PM +0800, Wen He wrote:
> >> > Document the devicetree bindings for NXP Layerscape qDMA controller
> >> > which could be found on NXP QorIQ Layerscape SoCs.
> >> >
> >> > Signed-off-by: Wen He <wen.he_1@nxp.com>
> >> > ---
> >> > change in v4:
> >> > - Rewrite the bindings document that follows generic DMA
> >> > bindings file
> >> >
> >> > change in v3:
> >> > - no change
> >> >
> >> > change in v2:
> >> > - Remove indentation
> >> > - Add "Should be" before 'fsl,ls1021a-qdma'
> >> > - Replace 'channels' by 'dma-channels'
> >> > - Replace 'qdma@8390000' by 'dma-controller@8390000'
> >> >
> >> > Documentation/devicetree/bindings/dma/fsl-qdma.txt | 41
> >> ++++++++++++++++++++
> >> > 1 files changed, 41 insertions(+), 0 deletions(-) create mode
> >> > 100644 Documentation/devicetree/bindings/dma/fsl-qdma.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/dma/fsl-qdma.txt
> >> > b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
> >> > new file mode 100644
> >> > index 0000000..368c4e7
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
> >> > @@ -0,0 +1,41 @@
> >> > +NXP Layerscape SoC qDMA Controller
> >> > +==================================
> >> > +
> >> > +This device follows the generic DMA bindings defined in dma/dma.txt.
> >> > +
> >> > +Required properties:
> >> > +
> >> > +- compatible: Must be one of
> >> > + "fsl,ls1021a-qdma": for LS1021A Board
> >> > + "fsl,ls1043a-qdma": for ls1043A Board
> >> > + "fsl,ls1046a-qdma": for ls1046A Board
> >> > +- reg: Should contain the register's base
> address and length.
> >> > +- interrupts: Should contain a reference to the
> interrupt used by
> >> this
> >> > + device.
> >> > +- interrupt-names: Should contain interrupt names:
> >> > + "qdma-error": the error interrupt
> >> > + "qdma-queue": the queue interrupt
> >> > +- queues: Should contain number of queues supported.
> >>
> >> Needs a vendor prefix.
> >>
> >
> > Does means: The queues filed need a vendor prefix ?
> > like 'fsl-queues' ? right?
>
> No, vendor prefixes end with a comma: fsl,queues
>
> Rob
Done.
Thanks for your review, the issue will next version fix.
Best Regards,
Wen
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: pinctrl: document the STMFX pinctrl bindings
From: Linus Walleij @ 2018-05-24 7:13 UTC (permalink / raw)
To: Amelie DELAUNAY
Cc: Lee Jones, Rob Herring, Mark Rutland, Russell King,
Alexandre TORGUE, Maxime Coquelin, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM
In-Reply-To: <28c374e6-b440-f785-b371-03fe15c8bc4b@st.com>
On Fri, May 18, 2018 at 9:29 AM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
> On 05/17/2018 08:36 AM, Lee Jones wrote:
>> On Wed, 16 May 2018, Amelie DELAUNAY wrote:
>>> On 05/16/2018 04:20 PM, Linus Walleij wrote:
>>>> On Wed, May 9, 2018 at 9:56 AM, Amelie DELAUNAY <amelie.delaunay@st.com> wrote:
>>>>
>>>>> Indeed, stmfx has other functions than GPIO. But, after comments done
>>>>> here: [1] and there: [2], it has been decided to move MFD parent/GPIO
>>>>> child drivers into a single PINCTRL/GPIO driver because of the following
>>>>> reasons:
>>>>> - Other stmfx functions (IDD measurement and TouchScreen controller) are
>>>>> not used on any of the boards using an stmfx and supported by Linux, so
>>>>> no way to test these functions, and no need to maintain them while they
>>>>> are not being used.
>>>>> - But, in the case a new board will use more than GPIO function on
>>>>> stmfx, the actual implementation allow to easily extract common init
>>>>> part of stmfx and put it in an MFD driver.
>>>>>
>>>>> So I could remove gpio sub-node and put its contents in stmfx node and
>>>>> keep single PINCTRL/GPIO driver for the time being.
>>>>> Please advise,
>>>>
>>>> I would normally advice to use the right modeling from the start, create
>>>> the MFD driver and spawn the devices from there. It is confusing
>>>> if the layout of the driver(s) doesn't really match the layout of the
>>>> hardware.
>>>>
>>>> I understand that it is a pain to write new MFD drivers to get your
>>>> things going and it would be "nice to get this working really quick
>>>> now" but in my experience it is better to do it right from the start.
>>>>
>>>
>>> Hi Linus,
>>>
>>> Thanks for your advice. I understand the point.
>>> So, the right modeling would be to:
>>> - create an MFD driver with the common init part of stmfx
>>> - remove all common init part of stmfx-pinctrl driver and keep only all
>>> gpio/pinctrl functions.
>>>
>>> I will not develop the other stmfx functions (IDD measurement driver and
>>> TouchScreen controller driver) because, as explained ealier, they are
>>> not used on any of the boards using an stmfx and supported by Linux, so
>>> no way to test these functions, and no need to maintain them while they
>>> are not being used.
>>>
>>> Lee, are you OK with that ?
>>
>> I missed a lot of this conversation I think, but from what I've read,
>> it sounds fine.
>>
>
> I summarize the situation:
> - I still don't have an official datasheet for STMFX device which could
> justify the use of an MFD driver;
> - the MFD driver will contain the STMFX chip initialization stuff such
> as regmap initialization (regmap structure will be shared with the
> child), chip initialization, global interrupt management;
> - there will be only one child (GPIO/PINCTRL node) for the time being.
But there will be more devices in it. And they will invariably be put
to use later, and there will be new versions of the chip as well, and
then you will be happy about doing the MFD core, which makes it
easy to add new variants with different subdevices.
> So, is "MFD driver + GPIO/PINCTRL driver" the right modeling, and does
> it still sound fine after this summary ? :)
No I think it should use an MFD core.
Mainly because of device tree concerns.
The main reason is that the device tree bindings will be different if
you add an MFD core later, the GPIO and pinctrl driver will
move to a child node, making old device trees incompatible.
We could have a single driver in GPIO+pin control if it is a child
of an MFD node in the device tree, but it doesn't make much
sense as the I2C device need to be probing to the MFD core.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v7 4/4] ARM: dts: tegra: Work safely with 256 MB Colibri-T20 modules
From: Krzysztof Kozlowski @ 2018-05-24 6:53 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel
Cc: Marcel Ziswiler, Stefan Agner, Lucas Stach, Krzysztof Kozlowski
In-Reply-To: <1527144833-24285-1-git-send-email-krzk@kernel.org>
Colibri-T20 can come in 256 MB RAM (with 512 MB NAND) or 512 MB RAM
(with 1024 MB NAND) flavors. Both of them will use the same DTSI
expecting the bootloader to do the fixup of /memory node. However in
case it does not happen, let's stay on safe side by limiting the memory
to 256 MB for both versions of Colibri-T20.
Rename to remove the unnecessary memory size from the device tree file
name. While at it, also follow the typical Toradex SoC, module, carrier
board hierarchy.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
RFT:
Not tested on 512 MB module as I have only the 256 MB one.
Changes since v6:
1. Only adjust commit msg.
Changes since v5:
1. Add "colibri" suffix to iris DTS (suggested by Stefan).
Changes since v4:
1. Drop the 512 suffix from file names (suggested by Stefan).
Changes since v3:
1. Reduce the memory in existing DTSI instead of creating a new one
(suggested by Marcel).
Changes since v2:
1. Do not add new compatible but use everywhere existing
"toradex,colibri_t20-512" (suggested by Rob).
Changes since v1:
1. Fix memory size in tegra20-colibri-256.dtsi (was working fine because
my bootloader uses mem= argument).
---
arch/arm/boot/dts/Makefile | 2 +-
.../boot/dts/{tegra20-iris-512.dts => tegra20-colibri-iris.dts} | 4 ++--
.../boot/dts/{tegra20-colibri-512.dtsi => tegra20-colibri.dtsi} | 9 +++++++--
3 files changed, 10 insertions(+), 5 deletions(-)
rename arch/arm/boot/dts/{tegra20-iris-512.dts => tegra20-colibri-iris.dts} (95%)
rename arch/arm/boot/dts/{tegra20-colibri-512.dtsi => tegra20-colibri.dtsi} (98%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ec2024ea8b1e..1c8bb55c0948 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1030,7 +1030,7 @@ dtb-$(CONFIG_ARCH_TANGO) += \
tango4-vantage-1172.dtb
dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
tegra20-harmony.dtb \
- tegra20-iris-512.dtb \
+ tegra20-colibri-iris.dtb \
tegra20-medcom-wide.dtb \
tegra20-paz00.dtb \
tegra20-plutux.dtb \
diff --git a/arch/arm/boot/dts/tegra20-iris-512.dts b/arch/arm/boot/dts/tegra20-colibri-iris.dts
similarity index 95%
rename from arch/arm/boot/dts/tegra20-iris-512.dts
rename to arch/arm/boot/dts/tegra20-colibri-iris.dts
index 40126388946d..57f16c0e9917 100644
--- a/arch/arm/boot/dts/tegra20-iris-512.dts
+++ b/arch/arm/boot/dts/tegra20-colibri-iris.dts
@@ -1,10 +1,10 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
-#include "tegra20-colibri-512.dtsi"
+#include "tegra20-colibri.dtsi"
/ {
- model = "Toradex Colibri T20 512MB on Iris";
+ model = "Toradex Colibri T20 256/512 MB on Iris";
compatible = "toradex,iris", "toradex,colibri_t20-512", "nvidia,tegra20";
aliases {
diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri.dtsi
similarity index 98%
rename from arch/arm/boot/dts/tegra20-colibri-512.dtsi
rename to arch/arm/boot/dts/tegra20-colibri.dtsi
index 5623ff8d128c..dc06b23183e1 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri.dtsi
@@ -2,7 +2,7 @@
#include "tegra20.dtsi"
/ {
- model = "Toradex Colibri T20 512MB";
+ model = "Toradex Colibri T20 256/512 MB";
compatible = "toradex,colibri_t20-512", "nvidia,tegra20";
aliases {
@@ -11,7 +11,12 @@
};
memory@0 {
- reg = <0x00000000 0x20000000>;
+ /*
+ * Set memory to 256 MB to be safe as this could be used on
+ * 256 or 512 MB module. It is expected from bootloader
+ * to fix this up for 512 MB version.
+ */
+ reg = <0x00000000 0x10000000>;
};
host1x@50000000 {
--
2.7.4
^ permalink raw reply related
* [PATCH v7 3/4] ARM: dts: tegra: Fix unit_address_vs_reg and avoid_unnecessary_addr_size DTC warnings
From: Krzysztof Kozlowski @ 2018-05-24 6:53 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel
Cc: Marcel Ziswiler, Stefan Agner, Lucas Stach, Krzysztof Kozlowski
In-Reply-To: <1527144833-24285-1-git-send-email-krzk@kernel.org>
Remove unneeded address/size cells properties and unit addresses to fix
DTC warnings like:
arch/arm/boot/dts/tegra30-apalis-eval.dtb: Warning (unit_address_vs_reg):
/i2c@7000d000/stmpe811@41/stmpe_touchscreen@0: node has a unit name, but no reg property
arch/arm/boot/dts/tegra30-apalis-eval.dtb: Warning (avoid_unnecessary_addr_size):
/i2c@7000d000/stmpe811@41: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Stefan Agner <stefan@agner.ch>
---
Changes since v6:
1. None
Changes since v5:
1. Add Stefan's reviewed-by tag.
Changes since v4:
1. None
---
arch/arm/boot/dts/tegra30-apalis.dtsi | 4 +---
arch/arm/boot/dts/tegra30-beaver.dts | 3 ---
arch/arm/boot/dts/tegra30-colibri.dtsi | 2 --
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi b/arch/arm/boot/dts/tegra30-apalis.dtsi
index 9465fc592b7b..d1a2c0a253c8 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -589,8 +589,6 @@
/* STMPE811 touch screen controller */
stmpe811@41 {
compatible = "st,stmpe811";
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0x41>;
interrupts = <TEGRA_GPIO(V, 0) IRQ_TYPE_LEVEL_LOW>;
interrupt-parent = <&gpio>;
@@ -599,7 +597,7 @@
blocks = <0x5>;
irq-trigger = <0x1>;
- stmpe_touchscreen@0 {
+ stmpe_touchscreen {
compatible = "st,stmpe-ts";
/* 3.25 MHz ADC clock speed */
st,adc-freq = <1>;
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index 1434d50438f9..b0d40ac8ac6e 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -1790,9 +1790,6 @@
vccio-supply = <&vdd_5v_in_reg>;
regulators {
- #address-cells = <1>;
- #size-cells = <0>;
-
vdd1_reg: vdd1 {
regulator-name = "vddio_ddr_1v2";
regulator-min-microvolt = <1200000>;
diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi b/arch/arm/boot/dts/tegra30-colibri.dtsi
index 9bf3327665d3..526ed71cf7a3 100644
--- a/arch/arm/boot/dts/tegra30-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
@@ -351,8 +351,6 @@
/* STMPE811 touch screen controller */
stmpe811@41 {
compatible = "st,stmpe811";
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0x41>;
interrupts = <TEGRA_GPIO(V, 0) IRQ_TYPE_LEVEL_LOW>;
interrupt-parent = <&gpio>;
--
2.7.4
^ permalink raw reply related
* [PATCH v7 2/4] ARM: dts: tegra: Fix unit_address_vs_reg DTC warnings for /memory
From: Krzysztof Kozlowski @ 2018-05-24 6:53 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel
Cc: Marcel Ziswiler, Stefan Agner, Lucas Stach, Krzysztof Kozlowski
In-Reply-To: <1527144833-24285-1-git-send-email-krzk@kernel.org>
Add a generic /memory node in each Tegra DTSI (with empty reg property,
to be overidden by each DTS) and set proper unit address for /memory
nodes to fix the DTC warnings:
arch/arm/boot/dts/tegra20-harmony.dtb: Warning (unit_address_vs_reg):
/memory: node has a reg or ranges property, but no unit name
The DTB after the change is the same as before except adding
unit-address to /memory node.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v6:
1. Fix unit addresses for tegra124 and minor nits (suggested by Stefan).
Changes since v5:
1. Split with skeleton.dtsi removal (suggested by Stefan).
Changes since v4:
1. None
---
arch/arm/boot/dts/tegra114-dalmore.dts | 2 +-
arch/arm/boot/dts/tegra114-roth.dts | 2 +-
arch/arm/boot/dts/tegra114-tn7.dts | 2 +-
arch/arm/boot/dts/tegra114.dtsi | 3 ++-
arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi | 2 +-
arch/arm/boot/dts/tegra124-apalis.dtsi | 2 +-
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 2 +-
arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
arch/arm/boot/dts/tegra124-venice2.dts | 2 +-
arch/arm/boot/dts/tegra124.dtsi | 3 ++-
arch/arm/boot/dts/tegra20-colibri-512.dtsi | 2 +-
arch/arm/boot/dts/tegra20-harmony.dts | 2 +-
arch/arm/boot/dts/tegra20-paz00.dts | 2 +-
arch/arm/boot/dts/tegra20-seaboard.dts | 2 +-
arch/arm/boot/dts/tegra20-tamonten.dtsi | 2 +-
arch/arm/boot/dts/tegra20-trimslice.dts | 2 +-
arch/arm/boot/dts/tegra20-ventana.dts | 2 +-
arch/arm/boot/dts/tegra20.dtsi | 3 ++-
arch/arm/boot/dts/tegra30-apalis.dtsi | 4 ++--
arch/arm/boot/dts/tegra30-beaver.dts | 2 +-
arch/arm/boot/dts/tegra30-cardhu.dtsi | 2 +-
arch/arm/boot/dts/tegra30-colibri.dtsi | 2 +-
arch/arm/boot/dts/tegra30.dtsi | 3 ++-
23 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index eafff16765b4..1788556b4977 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -23,7 +23,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
reg = <0x80000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra114-roth.dts b/arch/arm/boot/dts/tegra114-roth.dts
index 7ed7370ee67a..3d3835591cd2 100644
--- a/arch/arm/boot/dts/tegra114-roth.dts
+++ b/arch/arm/boot/dts/tegra114-roth.dts
@@ -28,7 +28,7 @@
};
};
- memory {
+ memory@80000000 {
/* memory >= 0x79600000 is reserved for firmware usage */
reg = <0x80000000 0x79600000>;
};
diff --git a/arch/arm/boot/dts/tegra114-tn7.dts b/arch/arm/boot/dts/tegra114-tn7.dts
index 7fc4a8b31e45..bfdd1bf61816 100644
--- a/arch/arm/boot/dts/tegra114-tn7.dts
+++ b/arch/arm/boot/dts/tegra114-tn7.dts
@@ -28,7 +28,7 @@
};
};
- memory {
+ memory@80000000 {
/* memory >= 0x37e00000 is reserved for firmware usage */
reg = <0x80000000 0x37e00000>;
};
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 27ef515e5640..85488a150701 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -11,8 +11,9 @@
#address-cells = <1>;
#size-cells = <1>;
- memory {
+ memory@80000000 {
device_type = "memory";
+ reg = <0x80000000 0x0>;
};
host1x@50000000 {
diff --git a/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi b/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
index bb67edb016c5..acb5b379e896 100644
--- a/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis-v1.2.dtsi
@@ -15,7 +15,7 @@
compatible = "toradex,apalis-tk1-v1.2", "toradex,apalis-tk1",
"nvidia,tegra124";
- memory {
+ memory@80000000 {
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi b/arch/arm/boot/dts/tegra124-apalis.dtsi
index 65a2161b9b8e..08518e424448 100644
--- a/arch/arm/boot/dts/tegra124-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis.dtsi
@@ -50,7 +50,7 @@
model = "Toradex Apalis TK1";
compatible = "toradex,apalis-tk1", "nvidia,tegra124";
- memory {
+ memory@80000000 {
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 6dbcf84dafbc..9151b3ebb839 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -24,7 +24,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-nyan.dtsi b/arch/arm/boot/dts/tegra124-nyan.dtsi
index 3609367037a6..d5f11d6d987e 100644
--- a/arch/arm/boot/dts/tegra124-nyan.dtsi
+++ b/arch/arm/boot/dts/tegra124-nyan.dtsi
@@ -13,7 +13,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts
index 89bcc178994d..82d139648ef1 100644
--- a/arch/arm/boot/dts/tegra124-venice2.dts
+++ b/arch/arm/boot/dts/tegra124-venice2.dts
@@ -18,7 +18,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
reg = <0x0 0x80000000 0x0 0x80000000>;
};
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 951feea784af..183c5acafb22 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -13,8 +13,9 @@
#address-cells = <2>;
#size-cells = <2>;
- memory {
+ memory@80000000 {
device_type = "memory";
+ reg = <0x0 0x80000000 0x0 0x0>;
};
pcie@1003000 {
diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index 5c202b3e3bb1..5623ff8d128c 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -10,7 +10,7 @@
rtc1 = "/rtc@7000e000";
};
- memory {
+ memory@0 {
reg = <0x00000000 0x20000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-harmony.dts b/arch/arm/boot/dts/tegra20-harmony.dts
index 628a55a9318b..1d96d92b72a7 100644
--- a/arch/arm/boot/dts/tegra20-harmony.dts
+++ b/arch/arm/boot/dts/tegra20-harmony.dts
@@ -18,7 +18,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts b/arch/arm/boot/dts/tegra20-paz00.dts
index 30436969adc0..ef245291924f 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -19,7 +19,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
reg = <0x00000000 0x20000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts b/arch/arm/boot/dts/tegra20-seaboard.dts
index 284aae351ff2..f91441683aad 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -18,7 +18,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-tamonten.dtsi b/arch/arm/boot/dts/tegra20-tamonten.dtsi
index 872046d48709..20137fc578b1 100644
--- a/arch/arm/boot/dts/tegra20-tamonten.dtsi
+++ b/arch/arm/boot/dts/tegra20-tamonten.dtsi
@@ -15,7 +15,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
reg = <0x00000000 0x20000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-trimslice.dts b/arch/arm/boot/dts/tegra20-trimslice.dts
index d55c6b240a30..9eb26dc15f6b 100644
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@ -18,7 +18,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts
index ee3fbf941e79..f44551e2d9d0 100644
--- a/arch/arm/boot/dts/tegra20-ventana.dts
+++ b/arch/arm/boot/dts/tegra20-ventana.dts
@@ -18,7 +18,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
reg = <0x00000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 88dd1afb5877..55581c0e5105 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -13,8 +13,9 @@
chosen { };
aliases { };
- memory {
+ memory@0 {
device_type = "memory";
+ reg = <0 0>;
};
iram@40000000 {
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi b/arch/arm/boot/dts/tegra30-apalis.dtsi
index 6f29cbad6e8a..9465fc592b7b 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -10,8 +10,8 @@
model = "Toradex Apalis T30";
compatible = "toradex,apalis_t30", "nvidia,tegra30";
- memory {
- reg = <0 0>;
+ memory@80000000 {
+ reg = <0x80000000 0x40000000>;
};
pcie@3000 {
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts b/arch/arm/boot/dts/tegra30-beaver.dts
index ae52a5039506..1434d50438f9 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -17,7 +17,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
reg = <0x80000000 0x7ff00000>;
};
diff --git a/arch/arm/boot/dts/tegra30-cardhu.dtsi b/arch/arm/boot/dts/tegra30-cardhu.dtsi
index 92a9740c533f..33b73dca16a3 100644
--- a/arch/arm/boot/dts/tegra30-cardhu.dtsi
+++ b/arch/arm/boot/dts/tegra30-cardhu.dtsi
@@ -40,7 +40,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@80000000 {
reg = <0x80000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra30-colibri.dtsi b/arch/arm/boot/dts/tegra30-colibri.dtsi
index c44d8c40c410..9bf3327665d3 100644
--- a/arch/arm/boot/dts/tegra30-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra30-colibri.dtsi
@@ -10,7 +10,7 @@
model = "Toradex Colibri T30";
compatible = "toradex,colibri_t30", "nvidia,tegra30";
- memory {
+ memory@80000000 {
reg = <0x80000000 0x40000000>;
};
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 19237c08c166..bc42f791d791 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -14,8 +14,9 @@
chosen { };
aliases { };
- memory {
+ memory@80000000 {
device_type = "memory";
+ reg = <0x80000000 0x0>;
};
pcie@3000 {
--
2.7.4
^ permalink raw reply related
* [PATCH v7 1/4] ARM: dts: tegra: Remove usage of deprecated skeleton.dtsi
From: Krzysztof Kozlowski @ 2018-05-24 6:53 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Thierry Reding, Jonathan Hunter,
devicetree, linux-tegra, linux-kernel
Cc: Marcel Ziswiler, Stefan Agner, Lucas Stach, Krzysztof Kozlowski
Remove the usage of skeleton.dtsi because it was deprecated since commit
9c0da3cc61f1 ("ARM: dts: explicitly mark skeleton.dtsi as deprecated").
It also allows later to fix DTC warnings for missing unit name in
/memory nodes.
The /chosen and /aliases nodes are added only when dependent DTSes do
not define them. Compiled DTB is the same as before this commit.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Stefan Agner <stefan@agner.ch>
---
Changes since v6:
1. Add Stefan's reviewed-by tag.
Changes since v5:
1. New patch, split with skeleton.dtsi removal (suggested by Stefan).
---
arch/arm/boot/dts/tegra114.dtsi | 8 ++++++--
arch/arm/boot/dts/tegra124.dtsi | 6 ++++--
arch/arm/boot/dts/tegra20.dtsi | 11 +++++++++--
arch/arm/boot/dts/tegra30-apalis.dtsi | 4 ++++
arch/arm/boot/dts/tegra30.dtsi | 11 +++++++++--
5 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114.dtsi b/arch/arm/boot/dts/tegra114.dtsi
index 0e4a13295d8a..27ef515e5640 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -5,11 +5,15 @@
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra114";
interrupt-parent = <&lic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ memory {
+ device_type = "memory";
+ };
host1x@50000000 {
compatible = "nvidia,tegra114-host1x", "simple-bus";
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 174092bfac90..951feea784af 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -7,14 +7,16 @@
#include <dt-bindings/reset/tegra124-car.h>
#include <dt-bindings/thermal/tegra124-soctherm.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra124";
interrupt-parent = <&lic>;
#address-cells = <2>;
#size-cells = <2>;
+ memory {
+ device_type = "memory";
+ };
+
pcie@1003000 {
compatible = "nvidia,tegra124-pcie";
device_type = "pci";
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 0a7136462a1a..88dd1afb5877 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -4,11 +4,18 @@
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra20";
interrupt-parent = <&lic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ chosen { };
+ aliases { };
+
+ memory {
+ device_type = "memory";
+ };
iram@40000000 {
compatible = "mmio-sram";
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi b/arch/arm/boot/dts/tegra30-apalis.dtsi
index d1d21ec2a844..6f29cbad6e8a 100644
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -10,6 +10,10 @@
model = "Toradex Apalis T30";
compatible = "toradex,apalis_t30", "nvidia,tegra30";
+ memory {
+ reg = <0 0>;
+ };
+
pcie@3000 {
avdd-pexa-supply = <&vdd2_reg>;
vdd-pexa-supply = <&vdd2_reg>;
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index a110cf84d85f..19237c08c166 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -5,11 +5,18 @@
#include <dt-bindings/pinctrl/pinctrl-tegra.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
-#include "skeleton.dtsi"
-
/ {
compatible = "nvidia,tegra30";
interrupt-parent = <&lic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ chosen { };
+ aliases { };
+
+ memory {
+ device_type = "memory";
+ };
pcie@3000 {
compatible = "nvidia,tegra30-pcie";
--
2.7.4
^ permalink raw reply related
* Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
From: Christian König @ 2018-05-24 6:46 UTC (permalink / raw)
To: Qiang Yu
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <CAKGbVbv10zGLe34J1BXdKHg1Kg0=7A3jUy_8pnjVjNs1T=r8mw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2696 bytes --]
Am 24.05.2018 um 03:38 schrieb Qiang Yu:
> [SNIP]
>>> Adding fence is done already, and I did wait it before unmap. But then
>>> I see when
>>> the buffer is shared between processes, the "perfect wait" is just
>>> wait the fence
>>> from this process's task, so it's better to also distinguish fences.
>>> If so, I just think
>>> why we don't just wait tasks from this process in the preclose before
>>> unmap/free
>>> buffer in the drm_release()?
>>
>> Well it depends on your VM management. When userspace expects that the VM
>> space the BO used is reusable immediately than the TTM callback won't work.
>>
>> On the other hand you can just grab the list of fences on a BO and filter
>> out the ones from your current process and wait for those. See
>> amdgpu_sync_resv() as an example how to do that.
> In current lima implementation, user space driver is responsible not unmap/free
> buffer before task is complete. And VM map/unmap is not differed.
Well it's up to you how to design userspace, but in the past doing it
like that turned out to be a rather bad design decision.
Keep in mind that the kernel driver must guarantee that a shaders can
never access freed up memory.
Otherwise taking over the system from an unprivileged processes becomes
just a typing exercise when you manage to access freed memory which is
now used for a page table.
Because of this we have a separate tracking in amdgpu so that we not
only know who is using which BO, who is using which VM.
> This works simple and fine except the case that user press Ctrl+C to terminate
> the application which will force to close drm fd.
I'm not sure if that actually works as fine as you think.
For an example of what we had to add to prevent security breaches, take
a look at amdgpu_gem_object_close().
> I'd more prefer to wait buffer fence before vm unmap and filter like
> amdgpu_sync_resv() compared to implement refcount in kernel task.
> But these two ways are all not as simple as preclose.
Well, I would rather say you should either delay VM unmap operations
until all users of the VM are done with their work using the
ttm_bo_destroy callback.
Or you block in the gem_close_object callback until all tasks using the
BO are done with it.
> So I still don't understand why you don't want to get preclose back even
> have to introduce other complicated mechanism to cover the case free/unmap
> buffer before this process's task is done?
We intentionally removed the preclose callback to prevent certain use
cases, bringing it back to allow your use case looks rather fishy to me.
BTW: What exactly is the issue with using the postclose callback?
Regards,
Christian.
>
> Regards,
> Qiang
>
[-- Attachment #1.2: Type: text/html, Size: 4056 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH RFC 00/24] Lima DRM driver
From: Christian König @ 2018-05-24 6:27 UTC (permalink / raw)
To: Qiang Yu, Daniel Vetter
Cc: Simon Shields, devicetree, Connor Abbott, Marek Vasut,
Neil Armstrong, Andrei Paulau, dri-devel, Vasily Khoruzhick,
Erico Nunes
In-Reply-To: <CAKGbVbsb5JPXrca6MsRCYgrB76t8wYM8MPKpQU76kJTX8WV-Yg@mail.gmail.com>
Am 24.05.2018 um 02:31 schrieb Qiang Yu:
> On Wed, May 23, 2018 at 11:44 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Wed, May 23, 2018 at 3:52 PM, Qiang Yu <yuq825@gmail.com> wrote:
>>> On Wed, May 23, 2018 at 5:29 PM, Christian König
>>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>>> Am 18.05.2018 um 11:27 schrieb Qiang Yu:
>>>>> Kernel DRM driver for ARM Mali 400/450 GPUs.
>>>>>
>>>>> This implementation mainly take amdgpu DRM driver as reference.
>>>>>
>>>>> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for
>>>>> OpenGL vertex shader processing and PP is for fragment shader
>>>>> processing. Each processor has its own MMU so prcessors work in
>>>>> virtual address space.
>>>>> - There's only one GP but multiple PP (max 4 for mali 400 and 8
>>>>> for mali 450) in the same mali 4xx GPU. All PPs are grouped
>>>>> togather to handle a single fragment shader task divided by
>>>>> FB output tiled pixels. Mali 400 user space driver is
>>>>> responsible for assign target tiled pixels to each PP, but mali
>>>>> 450 has a HW module called DLBU to dynamically balance each
>>>>> PP's load.
>>>>> - User space driver allocate buffer object and map into GPU
>>>>> virtual address space, upload command stream and draw data with
>>>>> CPU mmap of the buffer object, then submit task to GP/PP with
>>>>> a register frame indicating where is the command stream and misc
>>>>> settings.
>>>>> - There's no command stream validation/relocation due to each user
>>>>> process has its own GPU virtual address space. GP/PP's MMU switch
>>>>> virtual address space before running two tasks from different
>>>>> user process. Error or evil user space code just get MMU fault
>>>>> or GP/PP error IRQ, then the HW/SW will be recovered.
>>>>> - Use TTM as MM. TTM_PL_TT type memory is used as the content of
>>>>> lima buffer object which is allocated from TTM page pool. all
>>>>> lima buffer object gets pinned with TTM_PL_FLAG_NO_EVICT when
>>>>> allocation, so there's no buffer eviction and swap for now. We
>>>>> need reverse engineering to see if and how GP/PP support MMU
>>>>> fault recovery (continue execution). Otherwise we have to
>>>>> pin/unpin each envolved buffer when task creation/deletion.
>>>>
>>>> Well pinning all memory is usually a no-go for upstreaming. But since you
>>>> are already using the drm_sched for GPU task scheduling why are you actually
>>>> needing this?
>>>>
>>>> The scheduler should take care of signaling all fences when the hardware is
>>>> done with it's magic and that is enough for TTM to note that a buffer object
>>>> is movable again (e.g. unpin them).
>>> Please correct me if I'm wrong.
>>>
>>> One way to implement eviction/swap is like this:
>>> call validation on each buffers involved in a task, but this won't
>>> prevent it from
>>> eviction/swap when executing, so a GPU MMU fault may happen and in the
>>> handler we need to recover the buffer evicted/swapped.
>>>
>>> Another way is pin/unpin buffers evolved when task create/free.
>>>
>>> First way is better when memory load is low and second way is better when
>>> memory load is high. First way also need less memory.
>>>
>>> So I'd prefer first way but due to the GPU MMU fault
>>> HW op need reverse engineering, I have to pin all buffers now. After
>>> the HW op is clear, I can choose one way to implement.
>> All the drivers using ttm have something that looks like vram, or a
>> requirement to move buffers around. Afaiui that includes virtio drm
>> driver.
> Does virtio drm driver need to move buffers around? amdgpu also
> has no vram when APU.
>
>> From your description you don't have such a requirement, and
>> then doing what etnaviv has done would be a lot simpler. Everything
>> that's not related to buffer movement handling is also available
>> outside of ttm already.
> Yeah, I could do like etnaviv, but it's not simpler than using ttm
> directly especially want some optimization (like ttm page pool,
> ttm_eu_reserve_buffers, ttm_bo_mmap). If I have/want to implement
> them, why not just use TTM directly with all those helper functions.
Well TTM has some design flaws (e.g. heavily layered design etc...), but
it also offers some rather nice functionality.
Regards,
Christian.
>
> Regards,
> Qiang
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/2] mtd: partitions: use DT info for parsing partitions with specified type
From: Boris Brezillon @ 2018-05-24 6:15 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Mark Rutland, Boris Brezillon, devicetree, Richard Weinberger,
Marek Vasut, Rob Herring, linux-mtd, Jonas Gorski,
Rafał Miłecki, Brian Norris, David Woodhouse
In-Reply-To: <0204012f-71b6-70ef-860d-fcce3abdd302@gmail.com>
On Thu, 24 May 2018 07:50:10 +0200
Rafał Miłecki <zajec5@gmail.com> wrote:
> On 23.05.2018 20:24, Boris Brezillon wrote:
> > On Wed, 23 May 2018 19:14:48 +0200
> > Rafał Miłecki <zajec5@gmail.com> wrote:
> >
> >> From: Rafał Miłecki <rafal@milecki.pl>
> >>
> >> This supports nested partitions in a DT. If selected partition has a
> >> "compatible" property specified it will be parsed looking for
> >> subpartitions.
> >>
> >> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> >> ---
> >> drivers/mtd/mtdpart.c | 33 +++++++++++++--------------------
> >> 1 file changed, 13 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
> >> index f8d3a015cdad..52e2cb35fc79 100644
> >> --- a/drivers/mtd/mtdpart.c
> >> +++ b/drivers/mtd/mtdpart.c
> >> @@ -322,22 +322,6 @@ static inline void free_partition(struct mtd_part *p)
> >> kfree(p);
> >> }
> >>
> >> -/**
> >> - * mtd_parse_part - parse MTD partition looking for subpartitions
> >> - *
> >> - * @slave: part that is supposed to be a container and should be parsed
> >> - * @types: NULL-terminated array with names of partition parsers to try
> >> - *
> >> - * Some partitions are kind of containers with extra subpartitions (volumes).
> >> - * There can be various formats of such containers. This function tries to use
> >> - * specified parsers to analyze given partition and registers found
> >> - * subpartitions on success.
> >> - */
> >> -static int mtd_parse_part(struct mtd_part *slave, const char *const *types)
> >> -{
> >> - return parse_mtd_partitions(&slave->mtd, types, NULL);
> >> -}
> >> -
> >> static struct mtd_part *allocate_partition(struct mtd_info *parent,
> >> const struct mtd_partition *part, int partno,
> >> uint64_t cur_offset)
> >> @@ -735,8 +719,8 @@ int add_mtd_partitions(struct mtd_info *master,
> >>
> >> add_mtd_device(&slave->mtd);
> >> mtd_add_partition_attrs(slave);
> >> - if (parts[i].types)
> >> - mtd_parse_part(slave, parts[i].types);
> >> + /* Look for subpartitions */
> >> + parse_mtd_partitions(&slave->mtd, parts[i].types, NULL);
> >>
> >> cur_offset = slave->offset + slave->mtd.size;
> >> }
> >> @@ -812,6 +796,12 @@ static const char * const default_mtd_part_types[] = {
> >> NULL
> >> };
> >>
> >> +/* Check DT only when looking for subpartitions. */
> >> +static const char * const default_subpartition_types[] = {
> >> + "ofpart",
> >> + NULL
> >> +};
> >> +
> >> static int mtd_part_do_parse(struct mtd_part_parser *parser,
> >> struct mtd_info *master,
> >> struct mtd_partitions *pparts,
> >> @@ -882,7 +872,9 @@ static int mtd_part_of_parse(struct mtd_info *master,
> >> const char *fixed = "fixed-partitions";
> >> int ret, err = 0;
> >>
> >> - np = of_get_child_by_name(mtd_get_of_node(master), "partitions");
> >> + np = mtd_get_of_node(master);
> >> + if (!mtd_is_partition(master))
> >> + np = of_get_child_by_name(np, "partitions");
> >> of_property_for_each_string(np, "compatible", prop, compat) {
> >> parser = mtd_part_get_compatible_parser(compat);
> >> if (!parser)
> >> @@ -945,7 +937,8 @@ int parse_mtd_partitions(struct mtd_info *master, const char *const *types,
> >> int ret, err = 0;
> >>
> >> if (!types)
> >> - types = default_mtd_part_types;
> >> + types = mtd_is_partition(master) ? default_subpartition_types :
> >> + default_mtd_part_types;
> >
> > Hm, that means the subparts inherit the parser types from their parent
> > if types != NULL? Is that really what we want? And if that's what we
> > want, why don't we do the same for types == NULL?
>
> No, unless I'm missing something. In add_mtd_partitions() there is now
> a following call:
> parse_mtd_partitions(&slave->mtd, parts[i].types, NULL);
>
> In most cases parts[i].types is NULL, unless you're using some
> exceptional driver (like bcm47xxpart) which sets "types".
>
> So for each partition parse_mtd_partitions() will be called with "types"
> argument almost always set to NULL (no inheriting). That will result in
> picking default_subpartition_types.
And that's the "almost always" I'm not happy with. Either you don't
want to inherit the types from the parent and you do that for both !=
NULL and == NULL, or you inherit it for both.
Also, I'd really like to improve the 'part parser types' selection logic
by letting the boards select the part parsers instead of having the MTD
drivers do it.
Maybe we could have an approach similar to the gpio-lookup-table where
board files could assign a part-parser list to an MTD name, and then let
the core find whether there's a part parser list attached to the MTD
dev at registration time. And for DT-based setup, this information
would just be extracted from the compatible of the 'partitions' node (or
the node directly if the MTD device is a partition).
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH 9/9] regulator: bd71837: Build BD71837 regulator driver
From: Matti Vaittinen @ 2018-05-24 6:01 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount
Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
heikki.haikola
Configurations and Makefile for BD71837 regulator driver
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
drivers/regulator/Kconfig | 11 +++++++++++
drivers/regulator/Makefile | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 097f61784a7d..139f4b53fea0 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -180,6 +180,17 @@ config REGULATOR_BCM590XX
BCM590xx PMUs. This will enable support for the software
controllable LDO/Switching regulators.
+config REGULATOR_BD71837
+ tristate "ROHM BD71837 Power Regulator"
+ depends on MFD_BD71837
+ help
+ This driver supports voltage regulators on ROHM BD71837 PMIC.
+ This will enable support for the software controllable buck
+ and LDO regulators.
+
+ This driver can also be built as a module. If so, the module
+ will be called bd71837-regulator.
+
config REGULATOR_BD9571MWV
tristate "ROHM BD9571MWV Regulators"
depends on MFD_BD9571MWV
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 590674fbecd7..1b4d8ec416c2 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_REGULATOR_AS3711) += as3711-regulator.o
obj-$(CONFIG_REGULATOR_AS3722) += as3722-regulator.o
obj-$(CONFIG_REGULATOR_AXP20X) += axp20x-regulator.o
obj-$(CONFIG_REGULATOR_BCM590XX) += bcm590xx-regulator.o
+obj-$(CONFIG_REGULATOR_BD71837) += bd71837-regulator.o
obj-$(CONFIG_REGULATOR_BD9571MWV) += bd9571mwv-regulator.o
obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
obj-$(CONFIG_REGULATOR_DA9052) += da9052-regulator.o
--
2.14.3
^ permalink raw reply related
* [PATCH 8/9] regulator: bd71837: BD71837 PMIC regulator driver
From: Matti Vaittinen @ 2018-05-24 6:00 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount
Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
heikki.haikola
Support for controlling the 8 bucks and 7 LDOs the PMIC contains.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
drivers/regulator/bd71837-regulator.c | 683 ++++++++++++++++++++++++++++++++++
1 file changed, 683 insertions(+)
create mode 100644 drivers/regulator/bd71837-regulator.c
diff --git a/drivers/regulator/bd71837-regulator.c b/drivers/regulator/bd71837-regulator.c
new file mode 100644
index 000000000000..e6c3fa770755
--- /dev/null
+++ b/drivers/regulator/bd71837-regulator.c
@@ -0,0 +1,683 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2018 ROHM Semiconductors */
+/*
+ * bd71837-regulator.c ROHM BD71837MWV regulator driver
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/machine.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/gpio.h>
+#include <linux/mfd/bd71837.h>
+#include <linux/regulator/of_regulator.h>
+
+struct bd71837_pmic {
+ struct regulator_desc descs[BD71837_REGULATOR_CNT];
+ struct bd71837 *mfd;
+ struct platform_device *pdev;
+ struct regulator_dev *rdev[BD71837_REGULATOR_CNT];
+ struct mutex mtx;
+};
+
+/*
+ * BUCK1/2/3/4
+ * BUCK1RAMPRATE[1:0] BUCK1 DVS ramp rate setting
+ * 00: 10.00mV/usec 10mV 1uS
+ * 01: 5.00mV/usec 10mV 2uS
+ * 10: 2.50mV/usec 10mV 4uS
+ * 11: 1.25mV/usec 10mV 8uS
+ */
+static int bd71837_buck1234_set_ramp_delay(struct regulator_dev *rdev,
+ int ramp_delay)
+{
+ struct bd71837_pmic *pmic = rdev_get_drvdata(rdev);
+ struct bd71837 *mfd = pmic->mfd;
+ int id = rdev->desc->id;
+ unsigned int ramp_value = BUCK1_RAMPRATE_10P00MV;
+
+ dev_dbg(&(pmic->pdev->dev), "Buck[%d] Set Ramp = %d\n", id + 1,
+ ramp_delay);
+ switch (ramp_delay) {
+ case 1 ... 1250:
+ ramp_value = BUCK1_RAMPRATE_1P25MV;
+ break;
+ case 1251 ... 2500:
+ ramp_value = BUCK1_RAMPRATE_2P50MV;
+ break;
+ case 2501 ... 5000:
+ ramp_value = BUCK1_RAMPRATE_5P00MV;
+ break;
+ case 5001 ... 10000:
+ ramp_value = BUCK1_RAMPRATE_10P00MV;
+ break;
+ default:
+ ramp_value = BUCK1_RAMPRATE_10P00MV;
+ dev_err(&pmic->pdev->dev,
+ "%s: ramp_delay: %d not supported, setting 10000mV//us\n",
+ rdev->desc->name, ramp_delay);
+ }
+
+ return regmap_update_bits(mfd->regmap, BD71837_REG_BUCK1_CTRL + id,
+ BUCK1_RAMPRATE_MASK, ramp_value << 6);
+}
+
+static int bd71837_regulator_set_regmap(struct regulator_dev *rdev, int set)
+{
+ int ret = -EINVAL;
+ struct bd71837_pmic *pmic = rdev->reg_data;
+
+ if (pmic) {
+ mutex_lock(&pmic->mtx);
+ if (!set)
+ ret = regulator_disable_regmap(rdev);
+ else
+ ret = regulator_enable_regmap(rdev);
+ mutex_unlock(&pmic->mtx);
+ }
+ return ret;
+}
+
+static int bd71837_regulator_enable_regmap(struct regulator_dev *rdev)
+{
+ return bd71837_regulator_set_regmap(rdev, 1);
+}
+
+static int bd71837_regulator_disable_regmap(struct regulator_dev *rdev)
+{
+ return bd71837_regulator_set_regmap(rdev, 0);
+}
+
+static int bd71837_regulator_set_voltage_sel_regmap(struct regulator_dev *rdev,
+ unsigned int sel)
+{
+ int ret = -EINVAL;
+ struct bd71837_pmic *pmic = rdev->reg_data;
+ int do_disable;
+
+ if (pmic) {
+ mutex_lock(&pmic->mtx);
+ ret = regulator_is_enabled_regmap(rdev);
+ if (!ret || 1 == ret) {
+ do_disable = ret;
+ ret = 0;
+ if (do_disable)
+ ret = regulator_disable_regmap(rdev);
+ if (!ret) {
+ ret =
+ regulator_set_voltage_sel_regmap(rdev, sel);
+ if (do_disable)
+ ret = regulator_enable_regmap(rdev);
+ }
+ }
+ mutex_unlock(&pmic->mtx);
+ }
+ return ret;
+}
+
+static struct regulator_ops bd71837_ldo_regulator_ops = {
+ .enable = bd71837_regulator_enable_regmap,
+ .disable = bd71837_regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .set_voltage_sel = bd71837_regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+};
+
+static struct regulator_ops bd71837_ldo_regulator_nolinear_ops = {
+ .enable = bd71837_regulator_enable_regmap,
+ .disable = bd71837_regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .list_voltage = regulator_list_voltage_table,
+ .set_voltage_sel = bd71837_regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+};
+
+static struct regulator_ops bd71837_buck_regulator_ops = {
+ .enable = bd71837_regulator_enable_regmap,
+ .disable = bd71837_regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .set_voltage_sel = bd71837_regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+};
+
+static struct regulator_ops bd71837_buck_regulator_nolinear_ops = {
+ .enable = bd71837_regulator_enable_regmap,
+ .disable = bd71837_regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .list_voltage = regulator_list_voltage_table,
+ .set_voltage_sel = bd71837_regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+};
+
+static struct regulator_ops bd71837_buck1234_regulator_ops = {
+ .enable = bd71837_regulator_enable_regmap,
+ .disable = bd71837_regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .set_voltage_sel = bd71837_regulator_set_voltage_sel_regmap,
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_time_sel = regulator_set_voltage_time_sel,
+ .set_ramp_delay = bd71837_buck1234_set_ramp_delay,
+};
+
+/*
+ * BUCK1/2/3/4
+ * 0.70 to 1.30V (10mV step)
+ */
+static const struct regulator_linear_range bd71837_buck1234_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(700000, 0x00, 0x3C, 10000),
+ REGULATOR_LINEAR_RANGE(1300000, 0x3D, 0x3F, 0),
+};
+
+/*
+ * BUCK5
+ * 0.9V to 1.35V ()
+ */
+static const struct regulator_linear_range bd71837_buck5_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(700000, 0x00, 0x03, 100000),
+ REGULATOR_LINEAR_RANGE(1050000, 0x04, 0x05, 50000),
+ REGULATOR_LINEAR_RANGE(1200000, 0x06, 0x07, 150000),
+};
+
+/*
+ * BUCK6
+ * 3.0V to 3.3V (step 100mV)
+ */
+static const struct regulator_linear_range bd71837_buck6_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(3000000, 0x00, 0x03, 100000),
+};
+
+/*
+ * BUCK7
+ * 000 = 1.605V
+ * 001 = 1.695V
+ * 010 = 1.755V
+ * 011 = 1.8V (Initial)
+ * 100 = 1.845V
+ * 101 = 1.905V
+ * 110 = 1.95V
+ * 111 = 1.995V
+ */
+const unsigned int buck_7_volts[] = {
+ 1605000, 1695000, 1755000, 1800000, 1845000, 1905000, 1950000, 1995000
+};
+
+/*
+ * BUCK8
+ * 0.8V to 1.40V (step 10mV)
+ */
+static const struct regulator_linear_range bd71837_buck8_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(800000, 0x00, 0x3C, 10000),
+ REGULATOR_LINEAR_RANGE(1400000, 0x3D, 0x3F, 0),
+};
+
+/*
+ * LDO1
+ * 3.0 to 3.3V (100mV step)
+ */
+static const struct regulator_linear_range bd71837_ldo1_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(3000000, 0x00, 0x03, 100000),
+};
+
+/*
+ * LDO2
+ * 0.8 or 0.9V
+ */
+const unsigned int ldo_2_volts[] = {
+ 900000, 800000
+};
+
+/*
+ * LDO3
+ * 1.8 to 3.3V (100mV step)
+ */
+static const struct regulator_linear_range bd71837_ldo3_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(1800000, 0x00, 0x0F, 100000),
+};
+
+/*
+ * LDO4
+ * 0.9 to 1.8V (100mV step)
+ */
+static const struct regulator_linear_range bd71837_ldo4_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(900000, 0x00, 0x09, 100000),
+ REGULATOR_LINEAR_RANGE(1800000, 0x0A, 0x0F, 0),
+};
+
+/*
+ * LDO5
+ * 1.8 to 3.3V (100mV step)
+ */
+static const struct regulator_linear_range bd71837_ldo5_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(1800000, 0x00, 0x0F, 100000),
+};
+
+/*
+ * LDO6
+ * 0.9 to 1.8V (100mV step)
+ */
+static const struct regulator_linear_range bd71837_ldo6_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(900000, 0x00, 0x09, 100000),
+ REGULATOR_LINEAR_RANGE(1800000, 0x0A, 0x0F, 0),
+};
+
+/*
+ * LDO7
+ * 1.8 to 3.3V (100mV step)
+ */
+static const struct regulator_linear_range bd71837_ldo7_voltage_ranges[] = {
+ REGULATOR_LINEAR_RANGE(1800000, 0x00, 0x0F, 100000),
+};
+
+static const struct regulator_desc bd71837_regulators[] = {
+ {
+ .name = "BUCK1",
+ .of_match = of_match_ptr("BUCK1"),
+ .id = BD71837_BUCK1,
+ .ops = &bd71837_buck1234_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_BUCK1_VOLTAGE_NUM,
+ .linear_ranges = bd71837_buck1234_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_buck1234_voltage_ranges),
+ .vsel_reg = BD71837_REG_BUCK1_VOLT_RUN,
+ .vsel_mask = BUCK1_RUN_MASK,
+ .enable_reg = BD71837_REG_BUCK1_CTRL,
+ .enable_mask = BD71837_BUCK_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "BUCK2",
+ .of_match = of_match_ptr("BUCK2"),
+ .id = BD71837_BUCK2,
+ .ops = &bd71837_buck1234_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_BUCK2_VOLTAGE_NUM,
+ .linear_ranges = bd71837_buck1234_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_buck1234_voltage_ranges),
+ .vsel_reg = BD71837_REG_BUCK2_VOLT_RUN,
+ .vsel_mask = BUCK2_RUN_MASK,
+ .enable_reg = BD71837_REG_BUCK2_CTRL,
+ .enable_mask = BD71837_BUCK_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "BUCK3",
+ .of_match = of_match_ptr("BUCK3"),
+ .id = BD71837_BUCK3,
+ .ops = &bd71837_buck1234_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_BUCK3_VOLTAGE_NUM,
+ .linear_ranges = bd71837_buck1234_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_buck1234_voltage_ranges),
+ .vsel_reg = BD71837_REG_BUCK3_VOLT_RUN,
+ .vsel_mask = BUCK3_RUN_MASK,
+ .enable_reg = BD71837_REG_BUCK3_CTRL,
+ .enable_mask = BD71837_BUCK_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "BUCK4",
+ .of_match = of_match_ptr("BUCK4"),
+ .id = BD71837_BUCK4,
+ .ops = &bd71837_buck1234_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_BUCK4_VOLTAGE_NUM,
+ .linear_ranges = bd71837_buck1234_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_buck1234_voltage_ranges),
+ .vsel_reg = BD71837_REG_BUCK4_VOLT_RUN,
+ .vsel_mask = BUCK4_RUN_MASK,
+ .enable_reg = BD71837_REG_BUCK4_CTRL,
+ .enable_mask = BD71837_BUCK_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "BUCK5",
+ .of_match = of_match_ptr("BUCK5"),
+ .id = BD71837_BUCK5,
+ .ops = &bd71837_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_BUCK5_VOLTAGE_NUM,
+ .linear_ranges = bd71837_buck5_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_buck5_voltage_ranges),
+ .vsel_reg = BD71837_REG_BUCK5_VOLT,
+ .vsel_mask = BUCK5_MASK,
+ .enable_reg = BD71837_REG_BUCK5_CTRL,
+ .enable_mask = BD71837_BUCK_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "BUCK6",
+ .of_match = of_match_ptr("BUCK6"),
+ .id = BD71837_BUCK6,
+ .ops = &bd71837_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_BUCK6_VOLTAGE_NUM,
+ .linear_ranges = bd71837_buck6_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_buck6_voltage_ranges),
+ .vsel_reg = BD71837_REG_BUCK6_VOLT,
+ .vsel_mask = BUCK6_MASK,
+ .enable_reg = BD71837_REG_BUCK6_CTRL,
+ .enable_mask = BD71837_BUCK_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "BUCK7",
+ .of_match = of_match_ptr("BUCK7"),
+ .id = BD71837_BUCK7,
+ .ops = &bd71837_buck_regulator_nolinear_ops,
+ .type = REGULATOR_VOLTAGE,
+ .volt_table = &buck_7_volts[0],
+ .n_voltages = ARRAY_SIZE(buck_7_volts),
+ .vsel_reg = BD71837_REG_BUCK7_VOLT,
+ .vsel_mask = BUCK7_MASK,
+ .enable_reg = BD71837_REG_BUCK7_CTRL,
+ .enable_mask = BD71837_BUCK_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "BUCK8",
+ .of_match = of_match_ptr("BUCK8"),
+ .id = BD71837_BUCK8,
+ .ops = &bd71837_buck_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_BUCK8_VOLTAGE_NUM,
+ .linear_ranges = bd71837_buck8_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_buck8_voltage_ranges),
+ .vsel_reg = BD71837_REG_BUCK8_VOLT,
+ .vsel_mask = BUCK8_MASK,
+ .enable_reg = BD71837_REG_BUCK8_CTRL,
+ .enable_mask = BD71837_BUCK_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "LDO1",
+ .of_match = of_match_ptr("LDO1"),
+ .id = BD71837_LDO1,
+ .ops = &bd71837_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_LDO1_VOLTAGE_NUM,
+ .linear_ranges = bd71837_ldo1_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_ldo1_voltage_ranges),
+ .vsel_reg = BD71837_REG_LDO1_VOLT,
+ .vsel_mask = LDO1_MASK,
+ .enable_reg = BD71837_REG_LDO1_VOLT,
+ .enable_mask = BD71837_LDO_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "LDO2",
+ .of_match = of_match_ptr("LDO2"),
+ .id = BD71837_LDO2,
+ .ops = &bd71837_ldo_regulator_nolinear_ops,
+ .type = REGULATOR_VOLTAGE,
+ .volt_table = &ldo_2_volts[0],
+ .vsel_reg = BD71837_REG_LDO2_VOLT,
+ .vsel_mask = LDO2_MASK,
+ .n_voltages = ARRAY_SIZE(ldo_2_volts),
+ .n_voltages = BD71837_LDO2_VOLTAGE_NUM,
+ .enable_reg = BD71837_REG_LDO2_VOLT,
+ .enable_mask = BD71837_LDO_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "LDO3",
+ .of_match = of_match_ptr("LDO3"),
+ .id = BD71837_LDO3,
+ .ops = &bd71837_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_LDO3_VOLTAGE_NUM,
+ .linear_ranges = bd71837_ldo3_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_ldo3_voltage_ranges),
+ .vsel_reg = BD71837_REG_LDO3_VOLT,
+ .vsel_mask = LDO3_MASK,
+ .enable_reg = BD71837_REG_LDO3_VOLT,
+ .enable_mask = BD71837_LDO_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "LDO4",
+ .of_match = of_match_ptr("LDO4"),
+ .id = BD71837_LDO4,
+ .ops = &bd71837_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_LDO4_VOLTAGE_NUM,
+ .linear_ranges = bd71837_ldo4_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_ldo4_voltage_ranges),
+ .vsel_reg = BD71837_REG_LDO4_VOLT,
+ .vsel_mask = LDO4_MASK,
+ .enable_reg = BD71837_REG_LDO4_VOLT,
+ .enable_mask = BD71837_LDO_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "LDO5",
+ .of_match = of_match_ptr("LDO5"),
+ .id = BD71837_LDO5,
+ .ops = &bd71837_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_LDO5_VOLTAGE_NUM,
+ .linear_ranges = bd71837_ldo5_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_ldo5_voltage_ranges),
+ /* LDO5 is supplied by buck6 */
+ .supply_name = "buck6",
+ .vsel_reg = BD71837_REG_LDO5_VOLT,
+ .vsel_mask = LDO5_MASK,
+ .enable_reg = BD71837_REG_LDO5_VOLT,
+ .enable_mask = BD71837_LDO_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "LDO6",
+ .of_match = of_match_ptr("LDO6"),
+ .id = BD71837_LDO6,
+ .ops = &bd71837_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_LDO6_VOLTAGE_NUM,
+ .linear_ranges = bd71837_ldo6_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_ldo6_voltage_ranges),
+ /* LDO6 is supplied by buck7 */
+ .supply_name = "buck7",
+ .vsel_reg = BD71837_REG_LDO6_VOLT,
+ .vsel_mask = LDO6_MASK,
+ .enable_reg = BD71837_REG_LDO6_VOLT,
+ .enable_mask = BD71837_LDO_EN,
+ .owner = THIS_MODULE,
+ },
+ {
+ .name = "LDO7",
+ .of_match = of_match_ptr("LDO7"),
+ .id = BD71837_LDO7,
+ .ops = &bd71837_ldo_regulator_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = BD71837_LDO7_VOLTAGE_NUM,
+ .linear_ranges = bd71837_ldo7_voltage_ranges,
+ .n_linear_ranges = ARRAY_SIZE(bd71837_ldo7_voltage_ranges),
+ .vsel_reg = BD71837_REG_LDO7_VOLT,
+ .vsel_mask = LDO7_MASK,
+ .enable_reg = BD71837_REG_LDO7_VOLT,
+ .enable_mask = BD71837_LDO_EN,
+ .owner = THIS_MODULE,
+ },
+};
+
+struct reg_init {
+ unsigned int reg;
+ unsigned int mask;
+};
+
+static int bd71837_probe(struct platform_device *pdev)
+{
+ struct bd71837_pmic *pmic;
+ struct bd71837_board *pdata;
+ struct regulator_config config = { 0 };
+ struct reg_init pmic_regulator_inits[] = {
+ {
+ .reg = BD71837_REG_BUCK1_CTRL,
+ .mask = BD71837_BUCK_SEL,
+ }, {
+ .reg = BD71837_REG_BUCK2_CTRL,
+ .mask = BD71837_BUCK_SEL,
+ }, {
+ .reg = BD71837_REG_BUCK3_CTRL,
+ .mask = BD71837_BUCK_SEL,
+ }, {
+ .reg = BD71837_REG_BUCK4_CTRL,
+ .mask = BD71837_BUCK_SEL,
+ }, {
+ .reg = BD71837_REG_BUCK5_CTRL,
+ .mask = BD71837_BUCK_SEL,
+ }, {
+ .reg = BD71837_REG_BUCK6_CTRL,
+ .mask = BD71837_BUCK_SEL,
+ }, {
+ .reg = BD71837_REG_BUCK7_CTRL,
+ .mask = BD71837_BUCK_SEL,
+ }, {
+ .reg = BD71837_REG_BUCK8_CTRL,
+ .mask = BD71837_BUCK_SEL,
+ }, {
+ .reg = BD71837_REG_LDO1_VOLT,
+ .mask = BD71837_LDO_SEL,
+ }, {
+ .reg = BD71837_REG_LDO2_VOLT,
+ .mask = BD71837_LDO_SEL,
+ }, {
+ .reg = BD71837_REG_LDO3_VOLT,
+ .mask = BD71837_LDO_SEL,
+ }, {
+ .reg = BD71837_REG_LDO4_VOLT,
+ .mask = BD71837_LDO_SEL,
+ }, {
+ .reg = BD71837_REG_LDO5_VOLT,
+ .mask = BD71837_LDO_SEL,
+ }, {
+ .reg = BD71837_REG_LDO6_VOLT,
+ .mask = BD71837_LDO_SEL,
+ }, {
+ .reg = BD71837_REG_LDO7_VOLT,
+ .mask = BD71837_LDO_SEL,
+ }
+ };
+
+ int i = 0, err;
+
+ pmic = kzalloc(sizeof(struct bd71837_pmic), GFP_KERNEL);
+ if (!pmic)
+ return -ENOMEM;
+
+ mutex_init(&pmic->mtx);
+
+ memcpy(pmic->descs, bd71837_regulators, sizeof(pmic->descs));
+
+ pmic->pdev = pdev;
+ pmic->mfd = dev_get_drvdata(pdev->dev.parent);
+
+ if (!pmic->mfd) {
+ dev_err(&pdev->dev, "No MFD driver data\n");
+ err = -EINVAL;
+ goto err;
+ }
+ platform_set_drvdata(pdev, pmic);
+ pdata = dev_get_platdata(pmic->mfd->dev);
+
+ /* Register LOCK release */
+ err =
+ regmap_update_bits(pmic->mfd->regmap, BD71837_REG_REGLOCK,
+ (REGLOCK_PWRSEQ | REGLOCK_VREG), 0);
+ if (err) {
+ dev_err(&pmic->pdev->dev, "Failed to unlock PMIC (%d)\n", err);
+ goto err;
+ } else
+ dev_dbg(&pmic->pdev->dev, "%s: Unlocked lock register 0x%x\n",
+ __func__, BD71837_REG_REGLOCK);
+
+ for (i = 0; i < ARRAY_SIZE(pmic_regulator_inits); i++) {
+
+ struct regulator_desc *desc;
+ struct regulator_dev *rdev;
+
+ desc = &pmic->descs[i];
+
+ if (pdata)
+ config.init_data = pdata->init_data[i];
+
+ config.dev = &(pmic->pdev->dev);
+ config.driver_data = pmic;
+ config.regmap = pmic->mfd->regmap;
+
+ rdev = regulator_register(desc, &config);
+ if (IS_ERR(rdev)) {
+ dev_err(pmic->mfd->dev,
+ "failed to register %s regulator\n",
+ desc->name);
+ err = PTR_ERR(rdev);
+ goto err;
+ }
+ /* Regulator register gets the regulator constraints and
+ * applies them (set_machine_constraints). This should have
+ * turned the control register(s) to correct values and we
+ * can now switch the control from PMIC state machine to the
+ * register interface
+ */
+ err =
+ regmap_update_bits(pmic->mfd->regmap,
+ pmic_regulator_inits[i].reg,
+ pmic_regulator_inits[i].mask,
+ 0xFFFFFFFF);
+ if (err) {
+ dev_err(&pmic->pdev->dev,
+ "Failed to write BUCK/LDO SEL bit for (%s)\n",
+ desc->name);
+ goto err;
+ }
+
+ pmic->rdev[i] = rdev;
+ }
+
+ return 0;
+
+err:
+ while (--i >= 0)
+ regulator_unregister(pmic->rdev[i]);
+
+ kfree(pmic);
+ return err;
+}
+
+static int bd71837_remove(struct platform_device *pdev)
+{
+ struct bd71837_pmic *pmic = platform_get_drvdata(pdev);
+ int i;
+
+ if (pmic) {
+ for (i = 0; i < BD71837_REGULATOR_CNT; i++)
+ regulator_unregister(pmic->rdev[i]);
+
+ kfree(pmic);
+ }
+ return 0;
+}
+
+static struct platform_driver bd71837_regulator = {
+ .driver = {
+ .name = "bd71837-pmic",
+ .owner = THIS_MODULE,
+ },
+ .probe = bd71837_probe,
+ .remove = bd71837_remove,
+};
+
+module_platform_driver(bd71837_regulator);
+
+MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
+MODULE_DESCRIPTION("BD71837 voltage regulator driver");
+MODULE_LICENSE("GPL");
--
2.14.3
^ permalink raw reply related
* [PATCH 7/9] clk: bd71837: Build ROHM BD71837 PMIC clock driver
From: Matti Vaittinen @ 2018-05-24 5:59 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount
Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
heikki.haikola
Configuration options and Makefile for BD71837 clock driver
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
drivers/clk/Kconfig | 9 +++++++++
drivers/clk/Makefile | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 41492e980ef4..4b045699bb5e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -279,6 +279,15 @@ config COMMON_CLK_STM32H7
---help---
Support for stm32h7 SoC family clocks
+config COMMON_CLK_BD71837
+ tristate "Clock driver for ROHM BD71837 PMIC MFD"
+ depends on MFD_BD71837
+ depends on I2C=y
+ depends on OF
+ help
+ This driver supports ROHM BD71837 PMIC clock.
+
+
source "drivers/clk/bcm/Kconfig"
source "drivers/clk/hisilicon/Kconfig"
source "drivers/clk/imgtec/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index de6d06ac790b..8393c4af7d5a 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -21,6 +21,7 @@ endif
obj-$(CONFIG_MACH_ASM9260) += clk-asm9260.o
obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN) += clk-axi-clkgen.o
obj-$(CONFIG_ARCH_AXXIA) += clk-axm5516.o
+obj-$(CONFIG_COMMON_CLK_BD71837) += clk-bd71837.o
obj-$(CONFIG_COMMON_CLK_CDCE706) += clk-cdce706.o
obj-$(CONFIG_COMMON_CLK_CDCE925) += clk-cdce925.o
obj-$(CONFIG_ARCH_CLPS711X) += clk-clps711x.o
--
2.14.3
^ permalink raw reply related
* [PATCH 6/9] clk: bd71837: Add driver for BD71837 PMIC clock
From: Matti Vaittinen @ 2018-05-24 5:59 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount
Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
heikki.haikola
Support BD71837 gateable 32768 Hz clock.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
drivers/clk/clk-bd71837.c | 155 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 155 insertions(+)
create mode 100644 drivers/clk/clk-bd71837.c
diff --git a/drivers/clk/clk-bd71837.c b/drivers/clk/clk-bd71837.c
new file mode 100644
index 000000000000..8519badb8fc0
--- /dev/null
+++ b/drivers/clk/clk-bd71837.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2018 ROHM Semiconductors */
+/*
+ * bd71837.c -- ROHM BD71837MWV clock driver
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/mfd/bd71837.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+
+static int bd71837_clk_enable(struct clk_hw *hw);
+static void bd71837_clk_disable(struct clk_hw *hw);
+static int bd71837_clk_is_enabled(struct clk_hw *hw);
+
+struct bd71837_clk {
+ struct clk_hw hw;
+ uint8_t reg;
+ uint8_t mask;
+ unsigned long rate;
+ struct platform_device *pdev;
+ struct bd71837 *mfd;
+};
+
+static unsigned long bd71837_clk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate);
+
+static const struct clk_ops bd71837_clk_ops = {
+ .recalc_rate = &bd71837_clk_recalc_rate,
+ .prepare = &bd71837_clk_enable,
+ .unprepare = &bd71837_clk_disable,
+ .is_prepared = &bd71837_clk_is_enabled,
+};
+
+static int bd71837_clk_set(struct clk_hw *hw, int status)
+{
+ struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
+
+ return bd71837_update_bits(c->mfd, c->reg, c->mask, status);
+}
+
+static void bd71837_clk_disable(struct clk_hw *hw)
+{
+ int rv;
+ struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
+
+ rv = bd71837_clk_set(hw, 0);
+ if (rv)
+ dev_err(&c->pdev->dev, "Failed to disable 32K clk (%d)\n", rv);
+}
+
+static int bd71837_clk_enable(struct clk_hw *hw)
+{
+ return bd71837_clk_set(hw, 1);
+}
+
+static int bd71837_clk_is_enabled(struct clk_hw *hw)
+{
+ struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
+
+ return c->mask & bd71837_reg_read(c->mfd, c->reg);
+
+}
+
+static unsigned long bd71837_clk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct bd71837_clk *c = container_of(hw, struct bd71837_clk, hw);
+
+ return c->rate;
+}
+
+static int bd71837_clk_probe(struct platform_device *pdev)
+{
+ struct bd71837_clk *c;
+ int rval = -ENOMEM;
+ struct bd71837 *mfd = dev_get_drvdata(pdev->dev.parent);
+ const char *errstr = "memory allocation for bd71837 data failed";
+ struct clk_init_data init = {
+ .name = "bd71837-32k-out",
+ .ops = &bd71837_clk_ops,
+ };
+
+ c = kzalloc(sizeof(struct bd71837_clk), GFP_KERNEL);
+ if (!c)
+ goto err_out;
+
+ c->reg = BD71837_REG_OUT32K;
+ c->mask = BD71837_OUT32K_EN;
+ c->rate = BD71837_CLK_RATE;
+ c->mfd = mfd;
+ c->pdev = pdev;
+
+ if (pdev->dev.of_node)
+ of_property_read_string_index(pdev->dev.of_node,
+ "clock-output-names", 0,
+ &init.name);
+
+ c->hw.init = &init;
+
+ errstr = "failed to register 32K clk";
+ rval = clk_hw_register(&pdev->dev, &c->hw);
+ if (rval)
+ goto err_free;
+
+ errstr = "failed to register clkdev for bd71837";
+ rval = clk_hw_register_clkdev(&c->hw, init.name, NULL);
+ if (rval)
+ goto err_unregister;
+
+ platform_set_drvdata(pdev, c);
+ dev_dbg(&pdev->dev, "bd71837_clk successfully probed\n");
+
+ return 0;
+
+err_unregister:
+ clk_hw_unregister(&c->hw);
+err_free:
+ kfree(c);
+err_out:
+ dev_err(&pdev->dev, "%s\n", errstr);
+ return rval;
+}
+
+static int bd71837_clk_remove(struct platform_device *pdev)
+{
+ struct bd71837_clk *c = platform_get_drvdata(pdev);
+
+ if (c) {
+ clk_hw_unregister(&c->hw);
+ kfree(c);
+ platform_set_drvdata(pdev, NULL);
+ }
+ return 0;
+}
+
+static struct platform_driver bd71837_clk = {
+ .driver = {
+ .name = "bd71837-clk",
+ .owner = THIS_MODULE,
+ },
+ .probe = bd71837_clk_probe,
+ .remove = bd71837_clk_remove,
+};
+
+module_platform_driver(bd71837_clk);
+
+MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
+MODULE_DESCRIPTION("BD71837 chip clk driver");
+MODULE_LICENSE("GPL");
--
2.14.3
^ permalink raw reply related
* [PATCH 5/9] clk: bd71837: Devicetree bindings for ROHM BD71837 PMIC
From: Matti Vaittinen @ 2018-05-24 5:58 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, mazziesaccount
Cc: linux-clk, devicetree, linux-kernel, mikko.mutanen,
heikki.haikola
Document devicetree bindings for ROHM BD71837 PMIC clock output.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
.../bindings/clock/rohm,bd71837-clock.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
new file mode 100644
index 000000000000..9759fd145781
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rohm,bd71837-clock.txt
@@ -0,0 +1,37 @@
+ROHM BD71837 Power Management Integrated Circuit clock bindings
+
+BD71837 clock node should be sub node of the BD71837 MFD node.
+See BD71837 MFD bindings at
+Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.txt
+
+Required properties:
+- compatible : Should be "rohm,bd71837-clk"
+- clock-frequency : Should be 32768
+- #clock-cells : Should be 0
+
+Optional properties:
+- clock-output-names : Should contain name for output clock.
+ Name "bd71837-32k-out" is used if this is not given.
+
+
+Example:
+
+pmic: bd71837@4b {
+ compatible = "rohm,bd71837";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <29 GPIO_ACTIVE_LOW>;
+ interrupt-names = "irq";
+ #interrupt-cells = <1>;
+ interrupt-controller;
+
+ /* Clock node */
+ clk: bd71837-32k-out {
+ compatible = "rohm,bd71837-clk";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "bd71837-32k-out";
+ };
+};
--
2.14.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox