* [PATCH v2 1/4] dt-bindings: gpio - add exar to vendor prefixes list
From: Nandor Han @ 2017-04-13 10:27 UTC (permalink / raw)
To: gregkh, davem, geert, mchehab, daniel.vetter, linus.walleij,
gnurou, robh+dt, mark.rutland, linux-gpio, devicetree,
linux-kernel
Cc: Nandor Han
In-Reply-To: <cover.1492077070.git.nandor.han@ge.com>
Add Exar Corporation to vendors list.
Signed-off-by: Nandor Han <nandor.han@ge.com>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index c7d1b72..ba9058c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -104,6 +104,7 @@ ettus NI Ettus Research
eukrea Eukréa Electromatique
everest Everest Semiconductor Co. Ltd.
everspin Everspin Technologies, Inc.
+exar Exar Corporation
excito Excito
ezchip EZchip Semiconductor
faraday Faraday Technology Corporation
--
2.10.1
^ permalink raw reply related
* [PATCH v2 0/4] XRA1403,gpio - add XRA1403 gpio expander driver
From: Nandor Han @ 2017-04-13 10:27 UTC (permalink / raw)
To: gregkh, davem, geert, mchehab, daniel.vetter, linus.walleij,
gnurou, robh+dt, mark.rutland, linux-gpio, devicetree,
linux-kernel
Cc: Nandor Han
The patchset will add a driver to support basic functionality for
XRA1403 device. Features supported:
- get/set GPIO direction (input, output)
- get/set GPIO level (low, high)
Documentation: A gpio-xra1403.txt file was added to document the DTS
bindings related to driver.
Testing:
1.1 XRA1403 connected to iMX53 MCU
1.2 Use the GPIO tools provided by kernel from tools/gpio dir
2.1 `lsgpio`
root@csmon ppd:~# lsgpio
GPIO chip: gpiochip8, "xra1403", 16 GPIO lines
line 0: unnamed unused [output]
line 1: unnamed unused [output]
line 2: unnamed unused [output]
line 3: unnamed unused [output]
line 4: unnamed unused [output]
line 5: unnamed unused
line 6: unnamed unused
line 7: unnamed unused [output]
line 8: unnamed unused [output]
line 9: unnamed unused
line 10: unnamed unused [output]
line 11: unnamed unused
line 12: unnamed unused
line 13: unnamed unused
line 14: unnamed unused
line 15: unnamed unused [output]
GPIO chip: gpiochip7, "xra1403", 16 GPIO lines
line 0: unnamed unused
line 1: unnamed unused
line 2: unnamed unused
line 3: unnamed unused
line 4: unnamed unused
line 5: unnamed unused
line 6: unnamed unused
line 7: unnamed unused
line 8: unnamed unused
line 9: unnamed unused
line 10: unnamed unused
line 11: unnamed unused
line 12: unnamed unused
line 13: unnamed unused
line 14: unnamed unused
line 15: unnamed unused
3.1 `gpio-hammer`
root@csmon ppd:~# gpio-hammer -n gpiochip8 -o0 -o1 -o2 -o3
Hammer lines [0, 1, 2, 3] on gpiochip8, initial states: [0, 0, 0, 0]
[\] [0: 0, 1: 0, 2: 0, 3: 0]
...
[\] [0: 1, 1: 1, 2: 1, 3: 1]
When using `gpio-hammer` I also attached an oscilloscope to one of the pins and I was
able to monitor and validate the GPIO status.
Nandor Han (4):
dt-bindings: gpio - add exar to vendor prefixes list
gpio - Add EXAR XRA1403 SPI GPIO expander driver
doc,dts - add XRA1403 DTS binding documentation
Add XRA1403 support to MAINTAINERS file
.../devicetree/bindings/gpio/gpio-xra1403.txt | 46 ++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
MAINTAINERS | 8 +
drivers/gpio/Kconfig | 5 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-xra1403.c | 236 +++++++++++++++++++++
6 files changed, 297 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-xra1403.txt
create mode 100644 drivers/gpio/gpio-xra1403.c
--
2.10.1
^ permalink raw reply
* Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default
From: Philipp Zabel @ 2017-04-13 10:07 UTC (permalink / raw)
To: Hans Verkuil
Cc: Steve Longerbeam, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
nick-gcszYUEDH4VrovVCs/uTlw, markus.heiser-O6JHGLzbNUwb1SvskN2V4Q,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw,
bparrot-l0cyMroinI0, geert-Td1EMuHUCqxL1ZNQvxDV9g,
arnd-r2nGTMty4D4, sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w,
minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w,
tiffany.lin-NuS5LvNUpcJWk0Htik3J/w,
jean-christophe.trotin-qxv4g6HH51o,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ,
niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw,
robert.jarzmik-GANU6spQydw, songjun.wu-UWL1GkI3JZL3oGB3hsPCZA,
andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
shuah-DgEjT+Ai2ygdnm+yROfE0A, sakari.ailus-VuQAYsv1563Yd54FQh9/CA,
pavel-+ZI9xUNit7I, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-medi
In-Reply-To: <6c22519f-64f8-7213-d458-23470bdd5ecd-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
On Wed, 2017-04-12 at 09:03 +0200, Hans Verkuil wrote:
[...]
> >> Do you have a git tree with this patch? It is really hard to review without
> >> having the full imx-media-csi.c source.
> >
> > The patch applies on top of
> >
> > https://github.com/slongerbeam/mediatree.git imx-media-staging-md-v14
> >
> > I have uploaded a branch
> >
> > git://git.pengutronix.de/git/pza/linux imx-media-staging-md-v14+color
> >
> > with the patch applied on top.
> >
> >> I think one problem is that it is not clearly defined how subdevs and colorspace
> >> information should work.
>
> Ah, having the full source helped.
>
> Ignore my previous review, it was incorrect.
Ok.
> I'll have to think about this some more. I'll get back to this, but it may take some
> time since my vacation starts tomorrow. The spec is simply unclear about how to handle
> this so we have to come up with some guidelines.
Yes, please. Until then, have a nice vacation.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] mfd: arizona: Add GPIO maintain state flag
From: Charles Keepax @ 2017-04-13 9:15 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: Rob Herring, linus.walleij, lee.jones, gnurou, mark.rutland,
linux-gpio, devicetree, linux-kernel, patches
In-Reply-To: <1491903267.4826.8.camel@rf-debian.wolfsonmicro.main>
On Tue, Apr 11, 2017 at 10:34:27AM +0100, Richard Fitzgerald wrote:
> On Mon, 2017-04-10 at 15:17 -0500, Rob Herring wrote:
> > On Fri, Apr 07, 2017 at 01:38:44PM +0100, Charles Keepax wrote:
> > > The Arizona devices only maintain the state of output GPIOs whilst the
> > > CODEC is active, this can cause issues if the CODEC suspends whilst
> > > something is relying on the state of one of its GPIOs. However, in
> > > many systems the CODEC GPIOs are used for audio related features
> > > and thus the state of the GPIOs is unimportant whilst the CODEC is
> > > suspended. Often keeping the CODEC resumed in such a system would
> > > incur a power impact that is unacceptable.
> > >
> > > Add a flag through the second cell of the GPIO specifier in device
> > > tree, to allow the user to select whether a GPIO being configured as
> > > an output should keep the CODEC resumed.
> >
> > If the whole codec can't be suspended, why does this need to be per
> > GPIO? You could just have a single boolean property.
> >
>
> Three reasons I can think of:
>
> 1) The GPIO binding already provides for passing extra information
> through the binding ("Exact meaning of each specifier cell is controller
> specific" as it says in the main gpio binding doc) so why add yet
> another custom property to do it?
>
> 2) Doing it through the gpio means that if ultimately the child DT node
> that is using it gets disabled (status="disabled") or that driver isn't
> in use the codec will be able to go to sleep. That won't happen with a
> brute-force "big lock".
>
> 3) The codec only has to be kept awake while any such GPIO is actually
> in use. See (2)
>
Yeah option 3 is the primary issue here, we only want to keep the
CODEC enabled whilst specific GPIOs are in use. As GPIOs can be
dynamically requested/released by things in the kernel we want to
know which GPIOs require the CODEC to be kept alive. Also in the
future one might be tempted to add maintain whilst high and
maintain whilst low options for lines with pulls on them to
further optimise power.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
From: PrasannaKumar Muralidharan @ 2017-04-13 8:39 UTC (permalink / raw)
To: sean.wang
Cc: Herbert Xu, Matt Mackall, Rob Herring, Mark Rutland,
Corentin LABBE, Romain Perier, shannon.nelson, Wei Yongjun,
devicetree, linux-crypto, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede
In-Reply-To: <1492067108-14748-3-git-send-email-sean.wang@mediatek.com>
Hi Sean,
Mostly looks good, have few minor comments.
On 13 April 2017 at 12:35, <sean.wang@mediatek.com> wrote:
> +static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + int ready;
> +
> + ready = readl(priv->base + RNG_CTRL) & RNG_READY;
> + if (!ready && wait)
> + readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
> + ready & RNG_READY, USEC_POLL,
> + TIMEOUT_POLL);
> + return !!ready;
> +}
Use readl_poll_timeout_atomic's return value or -EIO instead of
!!ready. This will simplify mtk_rng_read.
> +static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> +{
> + struct mtk_rng *priv = to_mtk_rng(rng);
> + int retval = 0;
> +
> + while (max >= sizeof(u32)) {
> + if (!mtk_rng_wait_ready(rng, wait))
> + break;
> +
> + *(u32 *)buf = readl(priv->base + RNG_DATA);
> + retval += sizeof(u32);
> + buf += sizeof(u32);
> + max -= sizeof(u32);
> + }
> +
> + if (unlikely(wait && max))
> + dev_warn(priv->dev, "timeout might be not properly set\n");
Is this really necessary? Better to choose proper timeout than
providing this warning message. In rare cases if the timeout could
occur due to some reason (may be a hardware fault) print appropriate
warning message.
> + return retval || !wait ? retval : -EIO;
> +}
Set retavl to mtk_rng_wait_ready and return retval.
Regards,
Prasanna
^ permalink raw reply
* Re: [PATCHv4 0/2] Nokia H4+ support
From: Marcel Holtmann @ 2017-04-13 8:33 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Gustavo F. Padovan, Johan Hedberg, Rob Herring, Pavel Machek,
Linux Bluetooth, devicetree, linux-kernel
In-Reply-To: <20170413002659.25821-1-sre@kernel.org>
Hi Sebastian,
> Here is the fourth revision of the nokia bluetooth patchset. Compared
> to the previous one the following things have changed:
>
> * Drop patch 1-8 (applied by Marcel) and update Cc/To for patchset
> * Order includes in the driver alphabetically
> * Explicitly include <linux/of.h> in the nokia bluetooth driver
>
> -- Sebastian
>
> Sebastian Reichel (2):
> dt-bindings: net: bluetooth: Add nokia-bluetooth
> Bluetooth: add nokia driver
both patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash
From: Cyrille Pitchen @ 2017-04-13 8:24 UTC (permalink / raw)
To: Guochun Mao
Cc: Cyrille Pitchen, Mark Rutland, devicetree, Richard Weinberger,
Russell King, linux-kernel, Rob Herring, linux-mtd,
Matthias Brugger, linux-mediatek, David Woodhouse,
linux-arm-kernel
In-Reply-To: <1492051237.2866.36.camel@mhfsdcap03>
Hi Guochun,
Le 13/04/2017 à 04:40, Guochun Mao a écrit :
> Hi Cyrille,
>
> On Wed, 2017-04-12 at 22:57 +0200, Cyrille Pitchen wrote:
>> Hi Guochun,
>>
>> Le 05/04/2017 à 10:37, Guochun Mao a écrit :
>>> When nor's size larger than 16MByte, nor's address width maybe
>>> set to 3 or 4, and controller should change address width according
>>> to nor's setting.
>>>
>>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>st
Acked-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
>>> ---
>>> drivers/mtd/spi-nor/mtk-quadspi.c | 27 +++++++++++++++++++++++++++
>>> 1 file changed, 27 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> index e661877..b637770 100644
>>> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
>>> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> @@ -104,6 +104,8 @@
>>> #define MTK_NOR_MAX_RX_TX_SHIFT 6
>>> /* can shift up to 56 bits (7 bytes) transfer by MTK_NOR_PRG_CMD */
>>> #define MTK_NOR_MAX_SHIFT 7
>>> +/* nor controller 4-byte address mode enable bit */
>>> +#define MTK_NOR_4B_ADDR_EN BIT(4)
>>>
>>> /* Helpers for accessing the program data / shift data registers */
>>> #define MTK_NOR_PRG_REG(n) (MTK_NOR_PRGDATA0_REG + 4 * (n))
>>> @@ -230,10 +232,35 @@ static int mt8173_nor_write_buffer_disable(struct mt8173_nor *mt8173_nor)
>>> 10000);
>>> }
>>>
>>> +static void mt8173_nor_set_addr_width(struct mt8173_nor *mt8173_nor)
>>> +{
>>> + u8 val;
>>> + struct spi_nor *nor = &mt8173_nor->nor;
>>> +
>>> + val = readb(mt8173_nor->base + MTK_NOR_DUAL_REG);
>>> +
>>> + switch (nor->addr_width) {
>>> + case 3:
>>> + val &= ~MTK_NOR_4B_ADDR_EN;
>>> + break;
>>> + case 4:
>>> + val |= MTK_NOR_4B_ADDR_EN;
>>> + break;
>>> + default:
>>> + dev_warn(mt8173_nor->dev, "Unexpected address width %u.\n",
>>> + nor->addr_width);
>>> + break;
>>> + }
>>> +
>>> + writeb(val, mt8173_nor->base + MTK_NOR_DUAL_REG);
>>> +}
>>> +
>>> static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
>>> {
>>> int i;
>>>
>>> + mt8173_nor_set_addr_width(mt8173_nor);
>>> +
>>> for (i = 0; i < 3; i++) {
>>
>> Should it be 'i < nor->addr_width' instead of 'i < 3' ?
>> Does it work when accessing data after 128Mbit ?
>
> Yes, it can work.
>
> Let's see the whole function,
>
> static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
> {
> int i;
>
> mt8173_nor_set_addr_width(mt8173_nor);
>
> for (i = 0; i < 3; i++) {
> writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG
> + i * 4);
> addr >>= 8;
> }
> /* Last register is non-contiguous */
> writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR3_REG);
> }
>
> The nor controller has 4 registers for address.
> This '3' indicates the number of contiguous address' registers
> base + MTK_NOR_RADR0_REG(0x10)
> base + MTK_NOR_RADR1_REG(0x14)
> base + MTK_NOR_RADR2_REG(0x18),
> but the last address register is non-contiguous,
> it's base + MTK_NOR_RADR3_REG(0xc8)
>
> mt8173_nor_set_addr will set addr into these 4 registers by Byte.
> The bit MTK_NOR_4B_ADDR_EN will decide whether 3-byte(0x10,0x14,0x18)
> or 4-byte(0x10,0x14,x018,0xc8) been sent to nor device.
> and, it can access data after 128Mbit when sent 4-byte address.
Indeed, you're right. Sorry for the noise!
>
> Best regards,
>
> Guochun
>
>>
>> Best regards,
>>
>> Cyrille
>>
>>> writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG + i * 4);
>>> addr >>= 8;
>>>
>>
>
>
>
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: rk3399: add support for firefly-rk3399 board
From: Heiko Stübner @ 2017-04-13 8:22 UTC (permalink / raw)
To: Kever Yang
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Jianqun Xu, Liang Chen,
Brian Norris, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andy Yan,
Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Will Deacon, Mark Rutland, Catalin Marinas, Matthias Brugger
In-Reply-To: <6d1eb0cc-fe3b-a483-123c-8558096c0846-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Am Donnerstag, 13. April 2017, 12:00:19 CEST schrieb Kever Yang:
> Hi Heiko,
>
> On 04/12/2017 09:29 PM, Heiko Stuebner wrote:
> > Hi Kever,
> >
> > Am Montag, 10. April 2017, 11:50:13 CEST schrieb Kever Yang:
> >> Firefly-rk3399 is a bord from T-Firefly, you can find detail about
> >> it here:
> >> http://en.t-firefly.com/en/firenow/Firefly_RK3399/
> >>
> >> This patch add basic node for the board and make it able to bring
> >> up.
> >>
> >> Peripheral works:
> >> - usb hub which connect to ehci controller;
> >> - UART2 debug
> >> - eMMC
> >> - PCIe
> >>
> >> Not work:
> >> - USB 3.0 HOST, type-C port
> >> - sdio, sd-card
> >>
> >> Not test for other peripheral:
> >> - HDMI
> >> - Ethernet
> >> - OPTICAL
> >> - WiFi/BT
> >> - MIPI CSI/DSI
> >> - IR
> >> - EDP/DP
> >>
> >> Signed-off-by: Kever Yang <kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >
> > applied for 4.13, as we're a bit late for 4.12, with the following
changes:
> Thanks for your help, I'm not familiar with the devices status on upstream
> because not working on kernel upstream for a long time.
>
> > - commit subject
> > - dropped status from backlight (as there is no disabled common node
> >
> > and it's specific to the firefly itself)
> >
> > - quite some reordering of properties
> > - reordered regulator nodes per their addresses: 0x1b < 0x40
> > - dropped obsolete regulator-compatible properties
> > - fixed gpio-irq on the mpu6500
> > - dropped out-of-tree orientation properties of mpu6500
> >
> > --> please provide the optional "mount-matrix" in a follow-up patch
> >
> > see bindings/iio/imu/inv_mpu6050.txt
>
> Maybe we can drop this mpu6050 node first? I can't find binding file for it.
The binding (and driver in the kernel) is the same as for the mpu6050.
So you can find the documentation in
Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
Someone should add the other ids from
drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
to the binding.
mount-matrix is optional, so the basic node itself can stay in the dt.
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: Document STM32 I2S bindings
From: Olivier MOYSAN @ 2017-04-13 8:01 UTC (permalink / raw)
To: Mark Brown
Cc: mark.rutland@arm.com, Rob Herring, alsa-devel@alsa-project.org,
Alexandre TORGUE, devicetree@vger.kernel.org, Arnaud POULIQUEN,
tiwai@suse.com, lgirdwood@gmail.com, mcoquelin.stm32@gmail.com,
perex@perex.cz, linux-arm-kernel@lists.infradead.org,
Benjamin GAIGNARD
In-Reply-To: <20170412153831.r2urwvfseipfsrsi@sirena.org.uk>
Hello Mark,
On 04/12/2017 05:38 PM, Mark Brown wrote:
> On Wed, Apr 12, 2017 at 12:58:16PM +0000, Olivier MOYSAN wrote:
>> On 04/12/2017 01:32 PM, Mark Brown wrote:
>
>>> It is totally normal to just not use one direction in a given system, we
>>> don't normally need to do anything special to handle things. I'm a bit
>>> confused as to what's different here and needs configuring?
>
>> The IP does not provide an audio channel configured either as rx or tx.
>> I agree, that in such case, the cpu driver does not generally need
>> to worry about direction and there is nothing special required to handle it.
>
> No, that's not what I'm saying - such hardware would be extremely
> unusual.
>
>> Here the IP provides 2 channels, 1 tx and 1 rx, which may be active or
>> not. The driver has to know which channel is used, and if both channels
>> have to be managed. The affected registers depend on selected channel.
>
> This sounds like essentially every audio controller out there. The
> overwhelming majority of controllers do exactly as you describe and have
> both directions in the same IP, this really doesn't seem at all unusual.
> Off the top of my head I can only think of one SoC family which combines
> multiple IPs to do bidirectional audio (though I didn't check).
>
> It really feels like there is something different here and I'm just
> missing it.
>
Yes, I think I need to give more details on design choices.
The IP provides 2 channels.
I can see mainly 3 solutions to link dais to these channels:
1) 2 static dais NOT exclusive
- dai tx
- dai rx
The IP exhibits a mode register, where you select mode TX, RX or FD.
There are 2 two options to manage this register.
option 1:
start first channel with mode RX or TX
when second channel is started, mode has to be changed to FD.
Transfers have to be stopped before changing configuration
registers, so this leads to cuts in audio stream.
option 2:
start a first channel with mode FD.
In this case, we may have unpredictable behavior for the stream
which is not already started. probably underrun/overrun.
So, this solution rises problem for full-duplex management.
2) 3 static dais exclusive
- dai tx
- dai rx
- dai rx-tx (fd)
This is the current implementation.
The choice of the dai is done at probe time. It is provided by DT
through sound-dai parameter.
When dai fd is selected, after starting first stream, we assume that
second stream will be started. In this case we wait for second stream
to be available before enabling IP and starting transfers.
3) 1 dynamic dai
- dai rx or tx or fd (according to dma conf in IP node)
Here the driver exposes only a single dai constructed from dma
configuration provided by IP DT node.
This allows to get ride of sound-dai parameter.
This was my suggestion after Rob comments on DT bindings.
Hope this will help clarifying design constraints.
>> Moreover specific processing has to be performed if both channels are used.
>
> Given that this case has to be supported anyway I'd be more inclined to
> ask the question the other way around TBH.
>
Best regards
olivier
^ permalink raw reply
* Re: [PATCH v5 0/4] gpio: mvebu: Add PWM fan support
From: Ralph Sennhauser @ 2017-04-13 7:49 UTC (permalink / raw)
To: Thierry Reding
Cc: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Russell King, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170412171656.GC11964-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org>
On Wed, 12 Apr 2017 19:16:56 +0200
Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sun, Apr 09, 2017 at 08:09:26PM +0200, Ralph Sennhauser wrote:
> > Hi Therry,
> >
> > Resending this as v5 with some minor changes since v4. What is
> > missing is an ACK from you so Linus can merge the driver and
> > Gregory the dts changes. For this driver to make it into 4.12 it
> > would be nice to have it in next soon. I hope you can make some
> > room in your schedule to have another look at this series.
> >
> > Thanks
> > Ralph
> >
> > ---
> >
> > Notes:
> >
> > About npwm = 1:
> > The only way I can think of to achieve that requires reading the
> > GPIO line from the device tree. This would prevent a user to
> > dynamically choose a line. Which is fine for the fan found on
> > Mamba but let's take some development board with freely accessible
> > GPIOs and suddenly we limit the use of this driver. Given the
> > above, npwm = ngpio with only one usable at a time is a more
> > accurate
>
> I think "accurate" is perhaps not the word I'd choose. "npwm" is
> defined as "number of PWMs controlled by this chip", and that's
> effectively just the one. It's implied that all PWMs exposed by a
> chip can be used concurrently.
I'm not native English so some terms might be off a tad in how I use
them, replace accurate with what you think I meant ;).
The "it's implied" sounds like a contract and EBUSY a violation thereof.
>
> Anyway, I can see how npwm = ngpio might be more convenient, and if
> that is what you want to do, I don't feel strongly enough to object.
The goal is a pwm-fan driver for Mamba. So npwm=1 would work just fine
from that stand point. It's indeed the sysfs case I had in mind which
would be hampered. Whether to consider that one valid / desirable I
don't want to judge. For me it's a hypothetical use case for others it
might be real.
For this series I want just this one device to work and getting the
bindings right to not prevent others extending the driver later when
they need.
The driver which is under rework here is in use for 2 years, so I went
with the feature set provided by it which is more than I need. It's a
one of it's kind driver and I only have this single use case, so really
your call.
Thanks
Ralph
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 1/4] gpio: mvebu: Add limited PWM support
From: Ralph Sennhauser @ 2017-04-13 7:45 UTC (permalink / raw)
To: Thierry Reding
Cc: Andrew Lunn, Linus Walleij, Alexandre Courbot, Rob Herring,
Mark Rutland, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth, Russell King, linux-pwm, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170412171121.GB11964@ulmo.ba.sec>
On Wed, 12 Apr 2017 19:11:21 +0200
Thierry Reding <thierry.reding@gmail.com> wrote:
> On Sun, Apr 09, 2017 at 08:09:27PM +0200, Ralph Sennhauser wrote:
> > From: Andrew Lunn <andrew@lunn.ch>
> >
> > Armada 370/XP devices can 'blink' GPIO lines with a configurable on
> > and off period. This can be modelled as a PWM.
> >
> > However, there are only two sets of PWM configuration registers for
> > all the GPIO lines. This driver simply allows a single GPIO line per
> > GPIO chip of 32 lines to be used as a PWM. Attempts to use more
> > return EBUSY.
> >
> > Due to the interleaving of registers it is not simple to separate
> > the PWM driver from the GPIO driver. Thus the GPIO driver has been
> > extended with a PWM driver.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> > URL: https://patchwork.ozlabs.org/patch/427287/
> > URL: https://patchwork.ozlabs.org/patch/427295/
> > [Ralph Sennhauser:
> > * Port forward
> > * Merge PWM portion into gpio-mvebu.c
> > * Switch to atomic PWM API
> > * Add new compatible string marvell,armada-370-xp-gpio
> > * Update and merge documentation patch
> > * Update MAINTAINERS]
> > Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
> > Tested-by: Andrew Lunn <andrew@lunn.ch>
> > ---
> > .../devicetree/bindings/gpio/gpio-mvebu.txt | 32 ++
> > MAINTAINERS | 2 +
> > drivers/gpio/gpio-mvebu.c | 324
> > ++++++++++++++++++++- 3 files changed, 346 insertions(+), 12
> > deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
> > b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt index
> > a6f3bec..fe49e9d 100644 ---
> > a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt +++
> > b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt @@ -38,6
> > +38,24 @@ Required properties:
> > - #gpio-cells: Should be two. The first cell is the pin number. The
> > second cell is reserved for flags, unused at the moment.
> >
> > +Optional properties:
> > +
> > +In order to use the gpio lines in PWM mode, some additional
> > optional +properties are required. Only Armada 370 and XP support
> > these properties. +
> > +- compatible: Must contain "marvell,armada-370-xp-gpio"
> > +
> > +- reg: an additional register set is needed, for the GPIO Blink
> > + Counter on/off registers.
> > +
> > +- reg-names: Must contain an entry "pwm" corresponding to the
> > + additional register range needed for pwm operation.
> > +
> > +- #pwm-cells: Should be two. The first cell is the GPIO line
> > number. The
> > + second cell is the period in nanoseconds.
> > +
> > +- clocks: Must be a phandle to the clock for the gpio controller.
> > +
> > Example:
> >
> > gpio0: gpio@d0018100 {
> > @@ -51,3 +69,17 @@ Example:
> > #interrupt-cells = <2>;
> > interrupts = <16>, <17>, <18>, <19>;
> > };
> > +
> > + gpio1: gpio@18140 {
> > + compatible = "marvell,armada-370-xp-gpio";
> > + reg = <0x18140 0x40>, <0x181c8 0x08>;
> > + reg-names = "gpio", "pwm";
> > + ngpios = <17>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + #pwm-cells = <2>;
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > + interrupts = <87>, <88>, <89>;
> > + clocks = <&coreclk 0>;
> > + };
>
> This is going to need an Acked-by from one of the device tree
> maintainers. Rob and devicetree@vger.kernel.org are on Cc, but I
> suspect nobody might look for the binding change "hidden" in this
> patch.
>
> Maybe best to split this off into a separate patch, or explicitly ping
> Rob to look at this patch.
Hi Thierry,
Rob asked for the new compatible string so he did see it presumably. As
you prefer to have an ACK by him I'll see to getting one for the driver
(bindings part). The patch could be split but then one might want to
split it even further. Like this the first patch in the series is a nice
self contained package.
>
<snip/>
>
> > +
> > + mvpwm->clk_rate = clk_get_rate(mvchip->clk);
> > + if (!mvpwm->clk_rate) {
> > + dev_err(dev, "failed to get clock rate\n");
> > + return -EINVAL;
> > + }
> > +
> > + mvpwm->chip.dev = dev;
> > + mvpwm->chip.ops = &mvebu_pwm_ops;
> > + mvpwm->chip.base = mvchip->chip.base;
> > + mvpwm->chip.npwm = mvchip->chip.ngpio;
>
> I still would've done this differently. If you use this with a PWM
> user you have to hook it up via DT anyway, so it doesn't matter
> whether you specify the PWM index or the GPIO via some other
> property. The _only_ use-case where this might actually be an
> advantage is if you request a PWM via the sysfs interface.
Let me answer this in the other mail where you bring this up.
>
<snip/>
> All of my comments are effectively of a bikeshed nature, so from a PWM
> perspective this is:
>
> Acked-by: Thierry Reding <thierry.reding@gmail.com>
Thanks for the detailed review and the ACK. Will work on all the
mentioned bits for v6.
Ralph
^ permalink raw reply
* [PATCH v5 4/4] net: dsa: LAN9303: add MDIO managed mode support
From: Juergen Borleis @ 2017-04-13 7:33 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
In-Reply-To: <20170413073343.8067-1-jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
When the LAN9303 device is in MDIO manged mode, all register accesses must
be done via MDIO.
Please note: this code is compile time tested only due to the absence of such
configured hardware. It is based on a patch from Stefan Roese from 2014.
Signed-off-by: Juergen Borleis <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
CC: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
CC: mark.rutland-5wv7dgnIgG8@public.gmane.org
---
.../devicetree/bindings/net/dsa/lan9303.txt | 45 ++++++-
drivers/net/dsa/Kconfig | 8 ++
drivers/net/dsa/Makefile | 1 +
drivers/net/dsa/lan9303_mdio.c | 144 +++++++++++++++++++++
4 files changed, 197 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/dsa/lan9303_mdio.c
diff --git a/Documentation/devicetree/bindings/net/dsa/lan9303.txt b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
index 2edc2561467a7..04f2965a44676 100644
--- a/Documentation/devicetree/bindings/net/dsa/lan9303.txt
+++ b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
@@ -3,7 +3,10 @@ SMSC/MicroChip LAN9303 three port ethernet switch
Required properties:
-- compatible: should be "smsc,lan9303-i2c"
+- compatible: should be
+ - "smsc,lan9303-i2c" for I2C managed mode
+ or
+ - "smsc,lan9303-mdio" for mdio managed mode
Optional properties:
@@ -60,3 +63,43 @@ I2C managed mode:
};
};
};
+
+MDIO managed mode:
+
+ master: masterdevice@X {
+ status = "okay";
+ phy-handle = <&switch>;
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch: switch-phy@0 {
+ compatible = "smsc,lan9303-mdio";
+ reg = <0>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <100>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&master>;
+ };
+
+ port@1 { /* external port 1 */
+ reg = <1>;
+ label = "lan1;
+ };
+
+ port@2 { /* external port 2 */
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+ };
+ };
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 83887c68ef7a3..e52b298853474 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -67,4 +67,12 @@ config NET_DSA_SMSC_LAN9303_I2C
Enable access functions if the SMSC/Microchip LAN9303 is configured
for I2C managed mode.
+config NET_DSA_SMSC_LAN9303_MDIO
+ bool "MDIO managed mode"
+ depends on NET_DSA_SMSC_LAN9303
+ depends on OF_MDIO
+ ---help---
+ Enable access functions if the SMSC/Microchip LAN9303 is configured
+ for MDIO managed mode.
+
endmenu
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index e626aeba8525e..e782d9648bc8c 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -1,5 +1,6 @@
lan9303-objs-y := lan9303-core.o
lan9303-objs-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
+lan9303-objs-$(CONFIG_NET_DSA_SMSC_LAN9303_MDIO) += lan9303_mdio.o
obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
obj-$(CONFIG_NET_DSA_BCM_SF2) += bcm-sf2.o
diff --git a/drivers/net/dsa/lan9303_mdio.c b/drivers/net/dsa/lan9303_mdio.c
new file mode 100644
index 0000000000000..87c5cfa946a92
--- /dev/null
+++ b/drivers/net/dsa/lan9303_mdio.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright (C) 2017 Pengutronix, Juergen Borleis <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
+ *
+ * Partially based on a patch from
+ * Copyright (c) 2014 Stefan Roese <sr-ynQEQJNshbs@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mdio.h>
+#include <linux/phy.h>
+#include <linux/of.h>
+
+#include "lan9303.h"
+
+/* Generate phy-addr and -reg from the input address */
+#define PHY_ADDR(x) ((((x) >> 6) + 0x10) & 0x1f)
+#define PHY_REG(x) (((x) >> 1) & 0x1f)
+
+struct lan9303_mdio {
+ struct mdio_device *device;
+ struct lan9303 chip;
+};
+
+static void lan9303_mdio_real_write(struct mdio_device *mdio, int reg, u16 val)
+{
+ mdio->bus->write(mdio->bus, PHY_ADDR(reg), PHY_REG(reg), val);
+}
+
+static int lan9303_mdio_write(void *ctx, uint32_t reg, uint32_t val)
+{
+ struct lan9303_mdio *sw_dev = (struct lan9303_mdio *)ctx;
+
+ mutex_lock(&sw_dev->device->bus->mdio_lock);
+ lan9303_mdio_real_write(sw_dev->device, reg, val & 0xffff);
+ lan9303_mdio_real_write(sw_dev->device, reg + 2, (val >> 16) & 0xffff);
+ mutex_unlock(&sw_dev->device->bus->mdio_lock);
+
+ return 0;
+}
+
+static u16 lan9303_mdio_real_read(struct mdio_device *mdio, int reg)
+{
+ return mdio->bus->read(mdio->bus, PHY_ADDR(reg), PHY_REG(reg));
+}
+
+static int lan9303_mdio_read(void *ctx, uint32_t reg, uint32_t *val)
+{
+ struct lan9303_mdio *sw_dev = (struct lan9303_mdio *)ctx;
+
+ mutex_lock(&sw_dev->device->bus->mdio_lock);
+ *val = lan9303_mdio_real_read(sw_dev->device, reg);
+ *val |= (lan9303_mdio_real_read(sw_dev->device, reg + 2) << 16);
+ mutex_unlock(&sw_dev->device->bus->mdio_lock);
+
+ return 0;
+}
+
+static const struct regmap_config lan9303_mdio_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 32,
+ .reg_stride = 1,
+ .can_multi_write = true,
+ .max_register = 0x0ff, /* address bits 0..1 are not used */
+ .reg_format_endian = REGMAP_ENDIAN_LITTLE,
+
+ .volatile_table = &lan9303_register_set,
+ .wr_table = &lan9303_register_set,
+ .rd_table = &lan9303_register_set,
+
+ .reg_read = lan9303_mdio_read,
+ .reg_write = lan9303_mdio_write,
+
+ .cache_type = REGCACHE_NONE,
+};
+
+static int lan9303_mdio_probe(struct mdio_device *mdiodev)
+{
+ struct lan9303_mdio *sw_dev;
+ int ret;
+
+ sw_dev = devm_kzalloc(&mdiodev->dev, sizeof(struct lan9303_mdio),
+ GFP_KERNEL);
+ if (!sw_dev)
+ return -ENOMEM;
+
+ sw_dev->chip.regmap = devm_regmap_init(&mdiodev->dev, NULL, sw_dev,
+ &lan9303_mdio_regmap_config);
+ if (IS_ERR(sw_dev->chip.regmap)) {
+ ret = PTR_ERR(sw_dev->chip.regmap);
+ dev_err(&mdiodev->dev, "regmap init failed: %d\n", ret);
+ return ret;
+ }
+
+ /* link forward and backward */
+ sw_dev->device = mdiodev;
+ dev_set_drvdata(&mdiodev->dev, sw_dev);
+ sw_dev->chip.dev = &mdiodev->dev;
+
+ ret = lan9303_probe(&sw_dev->chip, mdiodev->dev.of_node);
+ if (ret != 0)
+ return ret;
+
+ dev_info(&mdiodev->dev, "LAN9303 MDIO driver loaded successfully\n");
+
+ return 0;
+}
+
+static void lan9303_mdio_remove(struct mdio_device *mdiodev)
+{
+ struct lan9303_mdio *sw_dev = dev_get_drvdata(&mdiodev->dev);
+
+ if (!sw_dev)
+ return;
+
+ lan9303_remove(&sw_dev->chip);
+}
+
+/*-------------------------------------------------------------------------*/
+
+static const struct of_device_id lan9303_mdio_of_match[] = {
+ { .compatible = "smsc,lan9303-mdio" },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, lan9303_mdio_of_match);
+
+static struct mdio_driver lan9303_mdio_driver = {
+ .mdiodrv.driver = {
+ .name = "LAN9303_MDIO",
+ .of_match_table = of_match_ptr(lan9303_mdio_of_match),
+ },
+ .probe = lan9303_mdio_probe,
+ .remove = lan9303_mdio_remove,
+};
+mdio_module_driver(lan9303_mdio_driver);
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v5 3/4] net: dsa: LAN9303: add I2C managed mode support
From: Juergen Borleis @ 2017-04-13 7:33 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
In-Reply-To: <20170413073343.8067-1-jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
In this mode the switch device and the internal phys will be managed via
I2C interface. The MDIO interface is still supported, but for the
(emulated) CPU port only.
Signed-off-by: Juergen Borleis <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
CC: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
CC: mark.rutland-5wv7dgnIgG8@public.gmane.org
---
.../devicetree/bindings/net/dsa/lan9303.txt | 62 ++++++++++++
drivers/net/dsa/Kconfig | 17 ++++
drivers/net/dsa/Makefile | 6 ++
drivers/net/dsa/lan9303_i2c.c | 109 +++++++++++++++++++++
4 files changed, 194 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/dsa/lan9303.txt
create mode 100644 drivers/net/dsa/lan9303_i2c.c
diff --git a/Documentation/devicetree/bindings/net/dsa/lan9303.txt b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
new file mode 100644
index 0000000000000..2edc2561467a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
@@ -0,0 +1,62 @@
+SMSC/MicroChip LAN9303 three port ethernet switch
+-------------------------------------------------
+
+Required properties:
+
+- compatible: should be "smsc,lan9303-i2c"
+
+Optional properties:
+
+- reset-gpios: GPIO to be used to reset the whole device
+- reset-duration: reset duration in milliseconds, defaults to 200 ms
+
+Subnodes:
+
+The integrated switch subnode should be specified according to the binding
+described in dsa/dsa.txt. The CPU port of this switch is always port 0.
+
+Note: always use 'reg = <0/1/2>;' for the three DSA ports, even if the device is
+configured to use 1/2/3 instead. This hardware configuration will be
+auto-detected and mapped accordingly.
+
+Example:
+
+I2C managed mode:
+
+ master: masterdevice@X {
+ status = "okay";
+
+ fixed-link { /* RMII fixed link to LAN9303 */
+ speed = <100>;
+ full-duplex;
+ };
+ };
+
+ switch: switch@a {
+ compatible = "smsc,lan9303-i2c";
+ reg = <0xa>;
+ status = "okay";
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <200>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 { /* RMII fixed link to master */
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&master>;
+ };
+
+ port@1 { /* external port 1 */
+ reg = <1>;
+ label = "lan1;
+ };
+
+ port@2 { /* external port 2 */
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 31a2b229106dd..83887c68ef7a3 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -50,4 +50,21 @@ config NET_DSA_MT7530
This enables support for the Mediatek MT7530 Ethernet switch
chip.
+menuconfig NET_DSA_SMSC_LAN9303
+ tristate "SMSC/Microchip LAN9303 3-ports 10/100 ethernet switch"
+ depends on NET_DSA
+ select NET_DSA_TAG_LAN9303
+ ---help---
+ This enables support for the SMSC/Microchip LAN9303 3 port ethernet
+ switch chips.
+
+config NET_DSA_SMSC_LAN9303_I2C
+ bool "I2C managed mode"
+ depends on NET_DSA_SMSC_LAN9303
+ depends on I2C && OF
+ select REGMAP_I2C
+ ---help---
+ Enable access functions if the SMSC/Microchip LAN9303 is configured
+ for I2C managed mode.
+
endmenu
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index 2ae07f4fbf635..e626aeba8525e 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -1,8 +1,14 @@
+lan9303-objs-y := lan9303-core.o
+lan9303-objs-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
+
obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
obj-$(CONFIG_NET_DSA_BCM_SF2) += bcm-sf2.o
bcm-sf2-objs := bcm_sf2.o bcm_sf2_cfp.o
obj-$(CONFIG_NET_DSA_QCA8K) += qca8k.o
obj-$(CONFIG_NET_DSA_MT7530) += mt7530.o
+obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303.o
+lan9303-objs := $(lan9303-objs-y)
+
obj-y += b53/
obj-y += mv88e6xxx/
obj-$(CONFIG_NET_DSA_LOOP) += dsa_loop.o dsa_loop_bdinfo.o
diff --git a/drivers/net/dsa/lan9303_i2c.c b/drivers/net/dsa/lan9303_i2c.c
new file mode 100644
index 0000000000000..23d942440e4b2
--- /dev/null
+++ b/drivers/net/dsa/lan9303_i2c.c
@@ -0,0 +1,109 @@
+/*
+ * Copyright (C) 2017 Pengutronix, Juergen Borleis <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/of.h>
+
+#include "lan9303.h"
+
+struct lan9303_i2c {
+ struct i2c_client *device;
+ struct lan9303 chip;
+};
+
+static const struct regmap_config lan9303_i2c_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 32,
+ .reg_stride = 1,
+ .can_multi_write = true,
+ .max_register = 0x0ff, /* address bits 0..1 are not used */
+ .reg_format_endian = REGMAP_ENDIAN_LITTLE,
+
+ .volatile_table = &lan9303_register_set,
+ .wr_table = &lan9303_register_set,
+ .rd_table = &lan9303_register_set,
+
+ .cache_type = REGCACHE_NONE,
+};
+
+static int lan9303_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct lan9303_i2c *sw_dev;
+ int ret;
+
+ sw_dev = devm_kzalloc(&client->dev, sizeof(struct lan9303_i2c),
+ GFP_KERNEL);
+ if (!sw_dev)
+ return -ENOMEM;
+
+ sw_dev->chip.regmap = devm_regmap_init_i2c(client,
+ &lan9303_i2c_regmap_config);
+ if (IS_ERR(sw_dev->chip.regmap)) {
+ ret = PTR_ERR(sw_dev->chip.regmap);
+ dev_err(&client->dev, "Failed to allocate register map: %d\n",
+ ret);
+ return ret;
+ }
+
+ /* link forward and backward */
+ sw_dev->device = client;
+ i2c_set_clientdata(client, sw_dev);
+ sw_dev->chip.dev = &client->dev;
+
+ ret = lan9303_probe(&sw_dev->chip, client->dev.of_node);
+ if (ret != 0)
+ return ret;
+
+ dev_info(&client->dev, "LAN9303 I2C driver loaded successfully\n");
+
+ return 0;
+}
+
+static int lan9303_i2c_remove(struct i2c_client *client)
+{
+ struct lan9303_i2c *sw_dev;
+
+ sw_dev = i2c_get_clientdata(client);
+ if (!sw_dev)
+ return -ENODEV;
+
+ return lan9303_remove(&sw_dev->chip);
+}
+
+/*-------------------------------------------------------------------------*/
+
+static const struct i2c_device_id lan9303_i2c_id[] = {
+ { "lan9303", 0 },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(i2c, lan9303_i2c_id);
+
+static const struct of_device_id lan9303_i2c_of_match[] = {
+ { .compatible = "smsc,lan9303-i2c", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, lan9303_i2c_of_match);
+
+static struct i2c_driver lan9303_i2c_driver = {
+ .driver = {
+ .name = "LAN9303_I2C",
+ .of_match_table = of_match_ptr(lan9303_i2c_of_match),
+ },
+ .probe = lan9303_i2c_probe,
+ .remove = lan9303_i2c_remove,
+ .id_table = lan9303_i2c_id,
+};
+module_i2c_driver(lan9303_i2c_driver);
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/3] media: mtk-mdp: Fix mdp device tree
From: Minghsiu Tsai @ 2017-04-13 7:33 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson-QSEj5FYQhm4dnm+yROfE0A, Rob Herring,
Mauro Carvalho Chehab, Matthias Brugger, Daniel Kurtz,
Pawel Osciak, Houlong Wei
Cc: srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Eddie Huang, Yingjoe Chen,
Wu-Cheng Li, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Minghsiu Tsai
In-Reply-To: <1492068787-17838-1-git-send-email-minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
From: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 9e4eb7d..a5ad586 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -118,7 +118,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mutex_init(&mdp->vpulock);
/* Iterate over sibling MDP function blocks */
- for_each_child_of_node(dev->of_node, node) {
+ for_each_child_of_node(dev->of_node->parent, node) {
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: mt8173: Fix mdp device tree
From: Minghsiu Tsai @ 2017-04-13 7:33 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, Houlong Wei
Cc: srv_heupstream, Eddie Huang, Yingjoe Chen, Wu-Cheng Li,
devicetree, linux-kernel, linux-arm-kernel, linux-media,
linux-mediatek, Minghsiu Tsai
In-Reply-To: <1492068787-17838-1-git-send-email-minghsiu.tsai@mediatek.com>
From: Daniel Kurtz <djkurtz@chromium.org>
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 126 +++++++++++++++----------------
1 file changed, 60 insertions(+), 66 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 6922252..d28a363 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -792,80 +792,74 @@
#clock-cells = <1>;
};
- mdp {
- compatible = "mediatek,mt8173-mdp";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
+ mdp_rdma0: rdma@14001000 {
+ compatible = "mediatek,mt8173-mdp-rdma",
+ "mediatek,mt8173-mdp";
+ reg = <0 0x14001000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+ <&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA0>;
+ mediatek,larb = <&larb0>;
mediatek,vpu = <&vpu>;
+ };
- mdp_rdma0: rdma@14001000 {
- compatible = "mediatek,mt8173-mdp-rdma";
- reg = <0 0x14001000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RDMA0>,
- <&mmsys CLK_MM_MUTEX_32K>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_RDMA0>;
- mediatek,larb = <&larb0>;
- };
-
- mdp_rdma1: rdma@14002000 {
- compatible = "mediatek,mt8173-mdp-rdma";
- reg = <0 0x14002000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RDMA1>,
- <&mmsys CLK_MM_MUTEX_32K>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_RDMA1>;
- mediatek,larb = <&larb4>;
- };
+ mdp_rdma1: rdma@14002000 {
+ compatible = "mediatek,mt8173-mdp-rdma";
+ reg = <0 0x14002000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RDMA1>,
+ <&mmsys CLK_MM_MUTEX_32K>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_RDMA1>;
+ mediatek,larb = <&larb4>;
+ };
- mdp_rsz0: rsz@14003000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14003000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RSZ0>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- };
+ mdp_rsz0: rsz@14003000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14003000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ0>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
- mdp_rsz1: rsz@14004000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14004000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RSZ1>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- };
+ mdp_rsz1: rsz@14004000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14004000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ1>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
- mdp_rsz2: rsz@14005000 {
- compatible = "mediatek,mt8173-mdp-rsz";
- reg = <0 0x14005000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_RSZ2>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- };
+ mdp_rsz2: rsz@14005000 {
+ compatible = "mediatek,mt8173-mdp-rsz";
+ reg = <0 0x14005000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_RSZ2>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ };
- mdp_wdma0: wdma@14006000 {
- compatible = "mediatek,mt8173-mdp-wdma";
- reg = <0 0x14006000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_WDMA>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_WDMA>;
- mediatek,larb = <&larb0>;
- };
+ mdp_wdma0: wdma@14006000 {
+ compatible = "mediatek,mt8173-mdp-wdma";
+ reg = <0 0x14006000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WDMA>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WDMA>;
+ mediatek,larb = <&larb0>;
+ };
- mdp_wrot0: wrot@14007000 {
- compatible = "mediatek,mt8173-mdp-wrot";
- reg = <0 0x14007000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_WROT0>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_WROT0>;
- mediatek,larb = <&larb0>;
- };
+ mdp_wrot0: wrot@14007000 {
+ compatible = "mediatek,mt8173-mdp-wrot";
+ reg = <0 0x14007000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WROT0>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WROT0>;
+ mediatek,larb = <&larb0>;
+ };
- mdp_wrot1: wrot@14008000 {
- compatible = "mediatek,mt8173-mdp-wrot";
- reg = <0 0x14008000 0 0x1000>;
- clocks = <&mmsys CLK_MM_MDP_WROT1>;
- power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
- iommus = <&iommu M4U_PORT_MDP_WROT1>;
- mediatek,larb = <&larb4>;
- };
+ mdp_wrot1: wrot@14008000 {
+ compatible = "mediatek,mt8173-mdp-wrot";
+ reg = <0 0x14008000 0 0x1000>;
+ clocks = <&mmsys CLK_MM_MDP_WROT1>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
+ iommus = <&iommu M4U_PORT_MDP_WROT1>;
+ mediatek,larb = <&larb4>;
};
ovl0: ovl@1400c000 {
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree
From: Minghsiu Tsai @ 2017-04-13 7:33 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, Houlong Wei
Cc: devicetree, Minghsiu Tsai, srv_heupstream, Wu-Cheng Li,
linux-kernel, linux-mediatek, Yingjoe Chen, Eddie Huang,
linux-arm-kernel, linux-media
In-Reply-To: <1492068787-17838-1-git-send-email-minghsiu.tsai@mediatek.com>
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
---
Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
index 4182063..0d03e3a 100644
--- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
@@ -2,7 +2,7 @@
Media Data Path is used for scaling and color space conversion.
-Required properties (controller (parent) node):
+Required properties (controller node):
- compatible: "mediatek,mt8173-mdp"
- mediatek,vpu: the node of video processor unit, see
Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
@@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
for details.
Example:
-mdp {
- compatible = "mediatek,mt8173-mdp";
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
- mediatek,vpu = <&vpu>;
-
mdp_rdma0: rdma@14001000 {
compatible = "mediatek,mt8173-mdp-rdma";
+ "mediatek,mt8173-mdp";
reg = <0 0x14001000 0 0x1000>;
clocks = <&mmsys CLK_MM_MDP_RDMA0>,
<&mmsys CLK_MM_MUTEX_32K>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
iommus = <&iommu M4U_PORT_MDP_RDMA0>;
mediatek,larb = <&larb0>;
+ mediatek,vpu = <&vpu>;
};
mdp_rdma1: rdma@14002000 {
@@ -106,4 +101,3 @@ mdp {
iommus = <&iommu M4U_PORT_MDP_WROT1>;
mediatek,larb = <&larb4>;
};
-};
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] Fix mdp device tree
From: Minghsiu Tsai @ 2017-04-13 7:33 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, Houlong Wei
Cc: srv_heupstream, Eddie Huang, Yingjoe Chen, Wu-Cheng Li,
devicetree, linux-kernel, linux-arm-kernel, linux-media,
linux-mediatek
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
Daniel Kurtz (2):
arm64: dts: mt8173: Fix mdp device tree
media: mtk-mdp: Fix mdp device tree
Minghsiu Tsai (1):
dt-bindings: mt8173: Fix mdp device tree
.../devicetree/bindings/media/mediatek-mdp.txt | 12 +-
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 126 ++++++++++-----------
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +-
3 files changed, 64 insertions(+), 76 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 2/2] hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
From: sean.wang @ 2017-04-13 7:05 UTC (permalink / raw)
To: herbert, mpm, robh+dt, mark.rutland, clabbe.montjoie,
prasannatsmkumar, romain.perier, shannon.nelson
Cc: weiyongjun1, devicetree, linux-crypto, linux-mediatek,
linux-arm-kernel, linux-kernel, keyhaede, Sean Wang
In-Reply-To: <1492067108-14748-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds support for hardware random generator on MT7623 SoC
and should also work on other similar Mediatek SoCs. Currently,
the driver is already tested successfully with rng-tools.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/char/hw_random/Kconfig | 16 +++-
drivers/char/hw_random/Makefile | 2 +-
drivers/char/hw_random/mtk-rng.c | 174 +++++++++++++++++++++++++++++++++++++++
3 files changed, 190 insertions(+), 2 deletions(-)
create mode 100644 drivers/char/hw_random/mtk-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 0cafe08..af782ce 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -419,10 +419,24 @@ config HW_RANDOM_CAVIUM
Generator hardware found on Cavium SoCs.
To compile this driver as a module, choose M here: the
- module will be called cavium_rng.
+ module will be called mtk-rng.
If unsure, say Y.
+config HW_RANDOM_MTK
+ tristate "Mediatek Random Number Generator support"
+ depends on HW_RANDOM
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ default y
+ ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on Mediatek SoCs.
+
+ To compile this driver as a module, choose M here. the
+ module will be called mtk-rng.
+
+ If unsure, say Y.
+
endif # HW_RANDOM
config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 5f52b1e..68be716 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -1,7 +1,6 @@
#
# Makefile for HW Random Number Generator (RNG) device drivers.
#
-
obj-$(CONFIG_HW_RANDOM) += rng-core.o
rng-core-y := core.o
obj-$(CONFIG_HW_RANDOM_TIMERIOMEM) += timeriomem-rng.o
@@ -36,3 +35,4 @@ obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.o
+obj-$(CONFIG_HW_RANDOM_MTK) += mtk-rng.o
diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
new file mode 100644
index 0000000..6561ee0
--- /dev/null
+++ b/drivers/char/hw_random/mtk-rng.c
@@ -0,0 +1,174 @@
+/*
+ * Driver for Mediatek Hardware Random Number Generator
+ *
+ * Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#define MTK_RNG_DEV KBUILD_MODNAME
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define USEC_POLL 2
+#define TIMEOUT_POLL 20
+
+#define RNG_CTRL 0x00
+#define RNG_EN BIT(0)
+#define RNG_READY BIT(31)
+
+#define RNG_DATA 0x08
+
+#define to_mtk_rng(p) container_of(p, struct mtk_rng, rng)
+
+struct mtk_rng {
+ struct device *dev;
+ void __iomem *base;
+ struct clk *clk;
+ struct hwrng rng;
+};
+
+static int mtk_rng_init(struct hwrng *rng)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ u32 val;
+ int err;
+
+ err = clk_prepare_enable(priv->clk);
+ if (err)
+ return err;
+
+ val = readl(priv->base + RNG_CTRL);
+ val |= RNG_EN;
+ writel(val, priv->base + RNG_CTRL);
+
+ return 0;
+}
+
+static void mtk_rng_cleanup(struct hwrng *rng)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ u32 val;
+
+ val = readl(priv->base + RNG_CTRL);
+ val &= ~RNG_EN;
+ writel(val, priv->base + RNG_CTRL);
+
+ clk_disable_unprepare(priv->clk);
+}
+
+static bool mtk_rng_wait_ready(struct hwrng *rng, bool wait)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ int ready;
+
+ ready = readl(priv->base + RNG_CTRL) & RNG_READY;
+ if (!ready && wait)
+ readl_poll_timeout_atomic(priv->base + RNG_CTRL, ready,
+ ready & RNG_READY, USEC_POLL,
+ TIMEOUT_POLL);
+ return !!ready;
+}
+
+static int mtk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+ struct mtk_rng *priv = to_mtk_rng(rng);
+ int retval = 0;
+
+ while (max >= sizeof(u32)) {
+ if (!mtk_rng_wait_ready(rng, wait))
+ break;
+
+ *(u32 *)buf = readl(priv->base + RNG_DATA);
+ retval += sizeof(u32);
+ buf += sizeof(u32);
+ max -= sizeof(u32);
+ }
+
+ if (unlikely(wait && max))
+ dev_warn(priv->dev, "timeout might be not properly set\n");
+
+ return retval || !wait ? retval : -EIO;
+}
+
+static int mtk_rng_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ int ret;
+ struct mtk_rng *priv;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "no iomem resource\n");
+ return -ENXIO;
+ }
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = &pdev->dev;
+ priv->rng.name = pdev->name;
+ priv->rng.init = mtk_rng_init;
+ priv->rng.cleanup = mtk_rng_cleanup;
+ priv->rng.read = mtk_rng_read;
+
+ priv->clk = devm_clk_get(&pdev->dev, "rng");
+ if (IS_ERR(priv->clk)) {
+ ret = PTR_ERR(priv->clk);
+ dev_err(&pdev->dev, "no clock for device: %d\n", ret);
+ return ret;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ ret = devm_hwrng_register(&pdev->dev, &priv->rng);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register rng device: %d\n",
+ ret);
+ return ret;
+ }
+
+ dev_info(&pdev->dev, "registered RNG driver\n");
+
+ return 0;
+}
+
+static const struct of_device_id mtk_rng_match[] = {
+ { .compatible = "mediatek,mt7623-rng" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mtk_rng_match);
+
+static struct platform_driver mtk_rng_driver = {
+ .probe = mtk_rng_probe,
+ .driver = {
+ .name = MTK_RNG_DEV,
+ .of_match_table = mtk_rng_match,
+ },
+};
+
+module_platform_driver(mtk_rng_driver);
+
+MODULE_DESCRIPTION("Mediatek Random Number Generator Driver");
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: hwrng: Add Mediatek hardware random generator bindings
From: sean.wang @ 2017-04-13 7:05 UTC (permalink / raw)
To: herbert, mpm, robh+dt, mark.rutland, clabbe.montjoie,
prasannatsmkumar, romain.perier, shannon.nelson
Cc: weiyongjun1, devicetree, linux-crypto, linux-mediatek,
linux-arm-kernel, linux-kernel, keyhaede, Sean Wang
In-Reply-To: <1492067108-14748-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Document the devicetree bindings for Mediatek random number
generator which could be found on MT7623 SoC or other similar
Mediatek SoCs.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt b/Documentation/devicetree/bindings/rng/mtk-rng.txt
new file mode 100644
index 0000000..a6d62a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/mtk-rng.txt
@@ -0,0 +1,18 @@
+Device-Tree bindings for Mediatek random number generator
+found in Mediatek SoC family
+
+Required properties:
+- compatible : Should be "mediatek,mt7623-rng"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : Should contain "rng" entries;
+- reg : Specifies base physical address and size of the registers
+
+Example:
+
+rng: rng@1020f000 {
+ compatible = "mediatek,mt7623-rng";
+ reg = <0 0x1020f000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_TRNG>;
+ clock-names = "rng";
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] hwrng: mtk: add support for hardware random generator on MT7623 SoC
From: sean.wang-NuS5LvNUpcJWk0Htik3J/w @ 2017-04-13 7:05 UTC (permalink / raw)
To: herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w,
prasannatsmkumar-Re5JQEeQqe8AvxtiuMwx3w,
romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
shannon.nelson-QHcLZuEGTsvQT0dZR+AlfA
Cc: weiyongjun1-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w, Sean Wang
From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
This patchset introduces support for Mediatek hardware random generator (RNG)
Currently, the driver is already tested successfully with rng-tools on MT7623
SoC. And it should also be workable on other similar Mediatek SoCs.
SoC that also works on other similar SoCs.
Sean Wang (2):
dt-bindings: hwrng: Add Mediatek hardware random generator bindings
hwrng: mtk: Add driver for hardware random generator on MT7623 SoC
Documentation/devicetree/bindings/rng/mtk-rng.txt | 18 +++
drivers/char/hw_random/Kconfig | 16 +-
drivers/char/hw_random/Makefile | 2 +-
drivers/char/hw_random/mtk-rng.c | 174 ++++++++++++++++++++++
4 files changed, 208 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rng/mtk-rng.txt
create mode 100644 drivers/char/hw_random/mtk-rng.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 2/2] i2c: mux: ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Michael Hennerich @ 2017-04-13 6:58 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij
Cc: Wolfram Sang, Rob Herring, Mark Rutland,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <ef75918a-3e5d-91d2-bc05-546e1e0f0bb4@axentia.se>
On 12.04.2017 18:53, Peter Rosin wrote:
> On 2017-04-12 10:26, Linus Walleij wrote:
>> On Tue, Apr 11, 2017 at 2:16 PM, <michael.hennerich@analog.com> wrote:
>>
>>> From: Michael Hennerich <michael.hennerich@analog.com>
>>>
>>> This patch adds support for the Analog Devices / Linear Technology
>>> LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
>>> The LTC4306 optionally provides two general purpose input/output pins
>>> (GPIOs) that can be configured as logic inputs, opendrain outputs or
>>> push-pull outputs via the generic GPIOLIB framework.
>
> Great, thanks for your contribution Michael! Both patches pushed to the
> for-next branch of the i2c-mux tree.
>
>>> Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
>> (...)
>>> Changes since v4:
>>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> Please go ahead and merge to the i2c tree if you like.
>
> Yup, thanks for the review! (But not merged directly to the i2c tree,
> although they will get there eventually...)
>
> Cheers,
> peda
>
>
Peter and Linus,
Thanks for your precious time - really appreciated!
--
Greetings,
Michael
--
Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne
^ permalink raw reply
* Re: [PATCH] [media] mtk-mdp: Fix g_/s_selection capture/compose logic
From: Wu-Cheng Li (李務誠) @ 2017-04-13 6:50 UTC (permalink / raw)
To: Minghsiu Tsai
Cc: Hans Verkuil, Daniel Thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, Houlong Wei,
srv_heupstream, Eddie Huang, Yingjoe Chen, devicetree,
linux-kernel, linux-arm-kernel, linux-media, linux-mediatek
In-Reply-To: <1492057130-1194-1-git-send-email-minghsiu.tsai@mediatek.com>
Reviewed-by: Wu-Cheng Li <wuchengli@chromium.org>
On Thu, Apr 13, 2017 at 12:18 PM, Minghsiu Tsai
<minghsiu.tsai@mediatek.com> wrote:
> From: Daniel Kurtz <djkurtz@chromium.org>
>
> Experiments show that the:
> (1) mtk-mdp uses the _MPLANE form of CAPTURE/OUTPUT
> (2) CAPTURE types use CROP targets, and OUTPUT types use COMPOSE targets
>
> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
>
> ---
> drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> index 13afe48..8ab7ca0 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> @@ -837,12 +837,12 @@ static int mtk_mdp_m2m_g_selection(struct file *file, void *fh,
> struct mtk_mdp_ctx *ctx = fh_to_ctx(fh);
> bool valid = false;
>
> - if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> - if (mtk_mdp_is_target_compose(s->target))
> - valid = true;
> - } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> if (mtk_mdp_is_target_crop(s->target))
> valid = true;
> + } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + if (mtk_mdp_is_target_compose(s->target))
> + valid = true;
> }
> if (!valid) {
> mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
> @@ -907,12 +907,12 @@ static int mtk_mdp_m2m_s_selection(struct file *file, void *fh,
> int ret;
> bool valid = false;
>
> - if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
> - if (s->target == V4L2_SEL_TGT_COMPOSE)
> - valid = true;
> - } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> if (s->target == V4L2_SEL_TGT_CROP)
> valid = true;
> + } else if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
> + if (s->target == V4L2_SEL_TGT_COMPOSE)
> + valid = true;
> }
> if (!valid) {
> mtk_mdp_dbg(1, "[%d] invalid type:%d,%u", ctx->id, s->type,
> @@ -925,7 +925,7 @@ static int mtk_mdp_m2m_s_selection(struct file *file, void *fh,
> if (ret)
> return ret;
>
> - if (mtk_mdp_is_target_crop(s->target))
> + if (mtk_mdp_is_target_compose(s->target))
> frame = &ctx->s_frame;
> else
> frame = &ctx->d_frame;
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 1/3] input: touchscreen: ar1021_i2c: add support for AR1020
From: Martin Kepplinger @ 2017-04-13 6:38 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: christian.gmeiner, linux, linux-input, linux-kernel, devicetree
In-Reply-To: <20170412154054.GB6297@dtor-ws>
On 2017-04-12 17:40, Dmitry Torokhov wrote:
> Hi Martin,
>
> On Tue, Apr 11, 2017 at 12:27:57PM +0200, Martin Kepplinger wrote:
>> ar1021_i2c simply also supports the ar1020 device we use. This is tested.
>> They also share the same datasheet:
>>
>> http://ww1.microchip.com/downloads/en/DeviceDoc/40001393C.pdf
>>
>> We differentiate not only to make it obvious that we support both devices,
>> but also to be able to implement the few model specific things in the
>> future.
>>
>> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
>> ---
>> drivers/input/touchscreen/Kconfig | 4 ++--
>> drivers/input/touchscreen/ar1021_i2c.c | 13 ++++++++++---
>> 2 files changed, 12 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
>> index 33c62e5..535b91a 100644
>> --- a/drivers/input/touchscreen/Kconfig
>> +++ b/drivers/input/touchscreen/Kconfig
>> @@ -96,8 +96,8 @@ config TOUCHSCREEN_AR1021_I2C
>> tristate "Microchip AR1021 i2c touchscreen"
>> depends on I2C && OF
>> help
>> - Say Y here if you have the Microchip AR1021 touchscreen controller
>> - chip in your system.
>> + Say Y here if you have the Microchip AR1020 or AR1021 touchscreen
>> + controller chip in your system.
>>
>> If unsure, say N.
>>
>> diff --git a/drivers/input/touchscreen/ar1021_i2c.c b/drivers/input/touchscreen/ar1021_i2c.c
>> index 6562b17..1767257 100644
>> --- a/drivers/input/touchscreen/ar1021_i2c.c
>> +++ b/drivers/input/touchscreen/ar1021_i2c.c
>> @@ -1,5 +1,5 @@
>> /*
>> - * Microchip AR1021 driver for I2C
>> + * Microchip AR1020 and AR1021 driver for I2C
>> *
>> * Author: Christian Gmeiner <christian.gmeiner@gmail.com>
>> *
>> @@ -24,6 +24,11 @@ struct ar1021_i2c {
>> u8 data[AR1021_TOCUH_PKG_SIZE];
>> };
>>
>> +enum {
>> + ar1021,
>> + ar1020,
>> +};
>> +
>> static irqreturn_t ar1021_i2c_irq(int irq, void *dev_id)
>> {
>> struct ar1021_i2c *ar1021 = dev_id;
>> @@ -151,13 +156,15 @@ static int __maybe_unused ar1021_i2c_resume(struct device *dev)
>> static SIMPLE_DEV_PM_OPS(ar1021_i2c_pm, ar1021_i2c_suspend, ar1021_i2c_resume);
>>
>> static const struct i2c_device_id ar1021_i2c_id[] = {
>> - { "MICROCHIP_AR1021_I2C", 0 },
>> + { "MICROCHIP_AR1021_I2C", ar1021 },
>> + { "MICROCHIP_AR1020_I2C", ar1020 },
>> { },
>> };
>> MODULE_DEVICE_TABLE(i2c, ar1021_i2c_id);
>>
>> static const struct of_device_id ar1021_i2c_of_match[] = {
>> { .compatible = "microchip,ar1021-i2c", },
>> + { .compatible = "microchip,ar1020-i2c", },
>> { }
>> };
>> MODULE_DEVICE_TABLE(of, ar1021_i2c_of_match);
>> @@ -175,5 +182,5 @@ static struct i2c_driver ar1021_i2c_driver = {
>> module_i2c_driver(ar1021_i2c_driver);
>>
>> MODULE_AUTHOR("Christian Gmeiner <christian.gmeiner@gmail.com>");
>> -MODULE_DESCRIPTION("Microchip AR1021 I2C Driver");
>> +MODULE_DESCRIPTION("Microchip AR1020 and AR1021 I2C Driver");
>> MODULE_LICENSE("GPL");
>> --
>> 2.1.4
>>
>
> I do not see where you handle ar1020 differently from ar1021. If devices
> are compatible, you do not need to add a new compatible to the driver,
> simply use it in the binding:
>
> compatible = "microchip,ar1020-i2c", "microchip,ar1021-i2c";
>
> Thanks.
>
Why would you use "microchip,ar1020-i2c" in the dts if it's not
available? people don't obviously see, by grepping or reading,
that they have a compatible driver. ... or did I get you wrong?
I don't handle anything differently now. Factory reset has to be done
differntly though, as one example. So it'd be nice to have the option
to add data.
thanks
martin
^ permalink raw reply
* Re: [PATCH V4 2/9] PM / Domains: Use OPP tables for power-domains
From: Viresh Kumar @ 2017-04-13 6:03 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson, Kevin Hilman, linaro-kernel,
linux-pm, linux-kernel, Vincent Guittot, Stephen Boyd,
Nishanth Menon, robh+dt, lina.iyer, rnayak, devicetree
In-Reply-To: <6f72cb6e-2d8c-4e68-59cd-67f40e8c3118@arm.com>
On 12-04-17, 17:58, Sudeep Holla wrote:
>
>
> On 20/03/17 09:32, Viresh Kumar wrote:
> > The OPP table bindings contains all the necessary fields to support
> > power-domains now. Update the power-domain bindings to allow
> > "operating-points-v2" to be present within the power-domain node.
> >
> > Also allow consumer devices, that don't use OPP tables, to specify the
> > parent power-domain's performance level using the
> > "domain-performance-state" property.
> >
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > ---
> > .../devicetree/bindings/power/power_domain.txt | 42 ++++++++++++++++++++++
> > 1 file changed, 42 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> > index 723e1ad937da..5db112fa5d7c 100644
> > --- a/Documentation/devicetree/bindings/power/power_domain.txt
> > +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> > @@ -38,6 +38,9 @@ phandle arguments (so called PM domain specifiers) of length specified by the
> > domain's idle states. In the absence of this property, the domain would be
> > considered as capable of being powered-on or powered-off.
> >
> > +- operating-points-v2 : This describes the performance states of a PM domain.
> > + Refer to ../opp/opp.txt for more information.
> > +
> > Example:
> >
> > power: power-controller@12340000 {
> > @@ -118,4 +121,43 @@ The node above defines a typical PM domain consumer device, which is located
> > inside a PM domain with index 0 of a power controller represented by a node
> > with the label "power".
> >
> > +Optional properties:
> > +- domain-performance-state: A positive integer value representing the minimum
> > + power-domain performance level required by the consumer device. The integer
> > + value '0' represents the lowest performance level and the higher values
> > + represent higher performance levels. The value of "domain-performance-state"
> > + field should match the "domain-performance-state" field of one of the OPP
> > + nodes in the parent power-domain's OPP table.
> > +
> > +
> > +
> > +Example:
> > +
> > + domain_opp_table: opp_table {
> > + compatible = "operating-points-v2";
> > +
> > + opp@1 {
> > + domain-performance-state = <1>;
> > + opp-microvolt = <975000 970000 985000>;
> > + };
> > + opp@2 {
> > + domain-performance-state = <2>;
> > + opp-microvolt = <1075000 1000000 1085000>;
> > + };
> > + };
> > +
> > + parent: power-controller@12340000 {
> > + compatible = "foo,power-controller";
> > + reg = <0x12340000 0x1000>;
> > + #power-domain-cells = <0>;
> > + operating-points-v2 = <&domain_opp_table>;
>
> As mentioned in the other email, it would be good to consider
> scalability with multiple power domains in a PM domain provider.
> i.e case of #power-domain-cells = <1> or more
Yeah, but that isn't supported for devices today. So no point
considering that today.
--
viresh
^ permalink raw reply
* Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for power-domains
From: Viresh Kumar @ 2017-04-13 5:50 UTC (permalink / raw)
To: Sudeep Holla
Cc: Rafael Wysocki, ulf.hansson, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Stephen Boyd, linaro-kernel, linux-pm,
linux-kernel, Vincent Guittot, robh+dt, lina.iyer, rnayak,
devicetree
In-Reply-To: <468e756b-7112-4006-b31d-9fcf1c32673d@arm.com>
On 12-04-17, 18:05, Sudeep Holla wrote:
>
>
> On 20/03/17 09:32, Viresh Kumar wrote:
> [...]
>
> > +
> > +Example 7: domain-Performance-state:
> > +(example: For 1GHz require domain state 1 and for 1.1 & 1.2 GHz require state 2)
> > +
> > +/ {
> > + domain_opp_table: opp_table0 {
> > + compatible = "operating-points-v2";
> > +
> > + opp@1 {
> > + domain-performance-state = <1>;
> > + opp-microvolt = <975000 970000 985000>;
> > + };
> > + opp@2 {
> > + domain-performance-state = <2>;
> > + opp-microvolt = <1075000 1000000 1085000>;
> > + };
> > + };
> > +
> > + foo_domain: power-controller@12340000 {
> > + compatible = "foo,power-controller";
> > + reg = <0x12340000 0x1000>;
> > + #power-domain-cells = <0>;
> > + operating-points-v2 = <&domain_opp_table>;
> > + }
> > +
> > + cpu0_opp_table: opp_table1 {
> > + compatible = "operating-points-v2";
> > + opp-shared;
> > +
> > + opp@1000000000 {
> > + opp-hz = /bits/ 64 <1000000000>;
> > + domain-performance-state = <1>;
> > + };
> > + opp@1100000000 {
> > + opp-hz = /bits/ 64 <1100000000>;
> > + domain-performance-state = <2>;
> > + };
> > + opp@1200000000 {
> > + opp-hz = /bits/ 64 <1200000000>;
> > + domain-performance-state = <2>;
> > + };
> > + };
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu@0 {
> > + compatible = "arm,cortex-a9";
> > + reg = <0>;
> > + clocks = <&clk_controller 0>;
> > + clock-names = "cpu";
> > + operating-points-v2 = <&cpu0_opp_table>;
> > + power-domains = <&foo_domain>;
> > + };
> > + };
> > +};
>
>
> Thinking more about this above example, I think you need more
> explanation. So in the above case you have cpu with clock controller,
> power-domain and the OPP table info, I can think of few things that need
> to be explicit:
>
> 1. How does the precedence look like ?
Just think of the power-domain as a regulator here. If we are
increasing frequency of the device, power-domain needs to be
programmed first followed by the clock.
> 2. Since power-domains with OPP table control the performance state, do
They control performance state of the domains, not the devices.
> we ignore clock and operating-points-v2 in the above case completely?
No. They are separate.
>
> 3. Will the power-domain drive the OPP ?
power-domain will driver its own state using its own OPP table.
Devices may fine tune within those states.
--
viresh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox