* Re: [PATCH] ARM: dts: sun6i: sina31s: Enable USB OTG controller in peripheral mode
From: Maxime Ripard @ 2017-01-18 7:11 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170118010105.20069-1-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]
On Wed, Jan 18, 2017 at 09:01:05AM +0800, Chen-Yu Tsai wrote:
> While the SinA31s does have a proper 5-pin mini USB OTG port, the ID
> pin does not seem to work. The pin used in the schematics is always low,
> regardless of the attached OTG cable or SoC internal pin bias settings.
>
> The v1.5 board is missing bias resistors shown in the schematics for
> earlier revisions, and the connections of the remaining one does not
> match the schematics either.
>
> In addition, VBUS for this port is disconnected from the board's 5V
> power rail. The board features a pad to solder jumper pins to connect
> VBUS to 5V manually.
>
> Given the above and the fact that the board has 5 more USB host ports,
> it makes more sense to have the OTG port work in peripheral mode.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 00/13] Ingenic JZ4740 / JZ4780 pinctrl driver
From: Thierry Reding @ 2017-01-18 7:15 UTC (permalink / raw)
To: Paul Cercueil
Cc: Linus Walleij, Rob Herring, Mark Rutland, Ralf Baechle,
Ulf Hansson, Boris Brezillon, Bartlomiej Zolnierkiewicz,
Maarten ter Huurne, Lars-Peter Clausen, Paul Burton, linux-gpio,
devicetree, linux-kernel, linux-mips, linux-mmc, linux-mtd,
linux-pwm, linux-fbdev, james.hogan
In-Reply-To: <20170117231421.16310-1-paul@crapouillou.net>
[-- Attachment #1: Type: text/plain, Size: 2322 bytes --]
On Wed, Jan 18, 2017 at 12:14:08AM +0100, Paul Cercueil wrote:
[...]
> One problem still unresolved: the pinctrl framework does not allow us to
> configure each pin on demand (someone please prove me wrong), when the
> various PWM channels are requested or released. For instance, the PWM
> channels can be configured from sysfs, which would require all PWM pins
> to be configured properly beforehand for the PWM function, eventually
> causing conflicts with other platform or board drivers.
Still catching up on a lot of email, so I haven't gone through the
entire series. But I don't think the above is true.
My understanding is that you can have separate pin groups for each
pin (provided the hardware supports that) and then control each of
these groups dynamically at runtime.
That is you could have the PWM driver's ->request() and ->free()
call into the pinctrl framework to select the correct pinmux
configuration as necessary.
> The proper solution here would be to modify the pwm-jz4740 driver to
> handle only one PWM channel, and create an instance of this driver
> for each one of the 8 PWM channels. Then, it could use the pinctrl
> framework to dynamically configure the PWM pin it controls.
That could probably work. From only looking at the JZ4740 PWM driver
there's no separate IP block to deal with the PWM outputs, but they are
merely GPIOs controller via a timer, so one instance per GPIO seems like
a fine solution to me.
> Until this can be done, the only jz4740 board supported upstream
> (Qi lb60) could configure all of its connected PWM pins in PWM function
> mode, if those are not used by other drivers nor by GPIOs on the
> board. The only jz4780 board upstream (CI20) does not yet support the
> PWM driver.
Typically all of the pinmux is pre-determined by the board design. That
is if you've got 8 pins that can be driven by a PWM signal, not all of
those might be exposed by the design. If, say, only 0-4 and 6 expose the
PWM signal while 5 and 7 expose a different function then you can simply
use a static pinmux configuration and ignore PWMs 5 and 7. Even if
someone were to configure them, the signal would simply go nowhere.
Of course you'd have to check that your hardware actually matches those
assumptions. They certainly apply to many SoCs that I've come across.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 12/13] pwm: jz4740: Let the pinctrl driver configure the pins
From: Thierry Reding @ 2017-01-18 7:20 UTC (permalink / raw)
To: Paul Cercueil
Cc: Linus Walleij, Rob Herring, Mark Rutland, Ralf Baechle,
Ulf Hansson, Boris Brezillon, Bartlomiej Zolnierkiewicz,
Maarten ter Huurne, Lars-Peter Clausen, Paul Burton, linux-gpio,
devicetree, linux-kernel, linux-mips, linux-mmc, linux-mtd,
linux-pwm, linux-fbdev, james.hogan
In-Reply-To: <20170117231421.16310-13-paul@crapouillou.net>
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
On Wed, Jan 18, 2017 at 12:14:20AM +0100, Paul Cercueil wrote:
> Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on
> the pins being properly configured before the driver probes.
>
> One inherent problem of this new approach is that the pinctrl framework
> does not allow us to configure each pin on demand, when the various PWM
> channels are requested or released. For instance, the PWM channels can
> be configured from sysfs, which would require all PWM pins to be configured
> properly beforehand for the PWM function, eventually causing conflicts
> with other platform or board drivers.
>
> The proper solution here would be to modify the pwm-jz4740 driver to
> handle only one PWM channel, and create an instance of this driver
> for each one of the 8 PWM channels. Then, it could use the pinctrl
> framework to dynamically configure the PWM pin it controls.
>
> Until this can be done, the only jz4740 board supported upstream
> (Qi lb60) could configure all of its connected PWM pins in PWM function
> mode, if those are not used by other drivers nor by GPIOs on the
> board.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> drivers/pwm/pwm-jz4740.c | 29 -----------------------------
> 1 file changed, 29 deletions(-)
>
> diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
> index 76d13150283f..a75ff3622450 100644
> --- a/drivers/pwm/pwm-jz4740.c
> +++ b/drivers/pwm/pwm-jz4740.c
> @@ -21,22 +21,10 @@
> #include <linux/platform_device.h>
> #include <linux/pwm.h>
>
> -#include <asm/mach-jz4740/gpio.h>
What about the linux/gpio.h header? It seems to me like that would be no
longer needed after this patch either.
Other than that this looks like the patch I'd expect if the pinmux was
configured statically, based on board design.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 13/13] MIPS: jz4740: Remove custom GPIO code
From: Thierry Reding @ 2017-01-18 7:27 UTC (permalink / raw)
To: Paul Cercueil, Ralf Baechle
Cc: Mark Rutland, Boris Brezillon, Ulf Hansson, Lars-Peter Clausen,
james.hogan, Paul Burton, Bartlomiej Zolnierkiewicz,
Linus Walleij, linux-mmc, linux-kernel, linux-pwm, linux-gpio,
devicetree, Rob Herring, linux-mips, linux-fbdev,
Maarten ter Huurne, linux-mtd
In-Reply-To: <20170117231421.16310-14-paul@crapouillou.net>
[-- Attachment #1.1: Type: text/plain, Size: 1641 bytes --]
On Wed, Jan 18, 2017 at 12:14:21AM +0100, Paul Cercueil wrote:
> All the drivers for the various hardware elements of the jz4740 SoC have
> been modified to use the pinctrl framework for their pin configuration
> needs.
> As such, this platform code is now unused and can be deleted.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> arch/mips/include/asm/mach-jz4740/gpio.h | 371 ----------------------
> arch/mips/jz4740/Makefile | 2 -
> arch/mips/jz4740/gpio.c | 519 -------------------------------
> 3 files changed, 892 deletions(-)
> delete mode 100644 arch/mips/jz4740/gpio.c
Have you considered how this could best be merged? It's probably easiest
to take all of this through the MIPS tree because we have an addition of
the pinctrl that would be a replacement for the GPIO code, while at the
same time a bunch of drivers rely on the JZ4740 GPIO code for successful
compilation.
That's slightly complicated by the number of drivers, so needs a lot of
coordination, but it's not the worst I've seen.
Maybe one other solution that would make the transition easier would be
to stub out the GPIO functions if the pinctrl driver is enabled, and do
the removal of the mach-jz4740/gpio.h after all drivers have been merged
through their corresponding subsystem trees. That way all drivers should
remain compilable and functional at runtime, while still having the
possibility to merge through the subsystem trees.
That said, the whole series is fairly simple, so merging everything
through the MIPS tree sounds like the easiest way to go.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v11 09/12] drm/mediatek: add dsi transfer function
From: CK Hu @ 2017-01-18 7:49 UTC (permalink / raw)
To: YT Shen
Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Matthias Brugger, yingjoe.chen, shaoming chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-10-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> From: shaoming chen <shaoming.chen@mediatek.com>
>
> add dsi read/write commands for transfer function
>
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 168 ++++++++++++++++++++++++++++++++++++-
> 1 file changed, 166 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 474861a..b3c7fd8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -24,6 +24,7 @@
> #include <linux/of_graph.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> +#include <video/mipi_display.h>
> #include <video/videomode.h>
>
> #include "mtk_drm_ddp_comp.h"
> @@ -80,8 +81,16 @@
> #define DSI_HBP_WC 0x54
> #define DSI_HFP_WC 0x58
>
> +#define DSI_CMDQ_SIZE 0x60
> +#define CMDQ_SIZE 0x3f
> +
> #define DSI_HSTX_CKL_WC 0x64
>
> +#define DSI_RX_DATA0 0x74
> +#define DSI_RX_DATA1 0x78
> +#define DSI_RX_DATA2 0x7c
> +#define DSI_RX_DATA3 0x80
> +
> #define DSI_RACK 0x84
> #define RACK BIT(0)
>
> @@ -117,6 +126,15 @@
> #define CLK_HS_POST (0xff << 8)
> #define CLK_HS_EXIT (0xff << 16)
>
> +#define DSI_CMDQ0 0x180
> +#define CONFIG (0xff << 0)
> +#define SHORT_PACKET 0
> +#define LONG_PACKET 2
> +#define BTA BIT(2)
> +#define DATA_ID (0xff << 8)
> +#define DATA_0 (0xff << 16)
> +#define DATA_1 (0xff << 24)
> +
> #define T_LPX 5
> #define T_HS_PREP 6
> #define T_HS_TRAIL 8
> @@ -125,6 +143,12 @@
>
> #define NS_TO_CYCLE(n, c) ((n) / (c) + (((n) % (c)) ? 1 : 0))
>
> +#define MTK_DSI_HOST_IS_READ(type) \
> + ((type == MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM) || \
> + (type == MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM) || \
> + (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> + (type == MIPI_DSI_DCS_READ))
> +
> struct phy;
>
> struct mtk_dsi {
> @@ -497,12 +521,12 @@ static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32 irq_bit)
> dsi->irq_data |= irq_bit;
> }
>
> -static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
> +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
> {
> dsi->irq_data &= ~irq_bit;
> }
>
> -static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
> +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
> unsigned int timeout)
> {
> s32 ret = 0;
> @@ -832,9 +856,149 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host *host,
> return 0;
> }
>
> +static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
> +{
> + u32 timeout_ms = 500000; /* total 1s ~ 2s timeout */
> +
> + while (timeout_ms--) {
> + if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
> + break;
> +
> + usleep_range(2, 4);
> + }
> +
> + if (timeout_ms == 0) {
> + DRM_WARN("polling dsi wait not busy timeout!\n");
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + }
> +}
> +
> +static u32 mtk_dsi_recv_cnt(u8 type, u8 *read_data)
> +{
> + switch (type) {
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
> + return 1;
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
> + return 2;
> + case MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE:
> + case MIPI_DSI_RX_DCS_LONG_READ_RESPONSE:
> + return read_data[1] + read_data[2] * 16;
> + case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
> + DRM_INFO("type is 0x02, try again\n");
> + break;
> + default:
> + DRM_INFO("type(0x%x) cannot be non-recognite\n", type);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
> +{
> + const char *tx_buf = msg->tx_buf;
> + u8 config, cmdq_size, cmdq_off, type = msg->type;
> + u32 reg_val, cmdq_mask, i;
> +
> + if (MTK_DSI_HOST_IS_READ(type))
> + config = BTA;
> + else
> + config = (msg->tx_len > 2) ? LONG_PACKET : SHORT_PACKET;
> +
> + if (msg->tx_len > 2) {
> + cmdq_size = 1 + (msg->tx_len + 3) / 4;
> + cmdq_off = 4;
> + cmdq_mask = CONFIG | DATA_ID | DATA_0 | DATA_1;
> + reg_val = (msg->tx_len << 16) | (type << 8) | config;
> + } else {
> + cmdq_size = 1;
> + cmdq_off = 2;
> + cmdq_mask = CONFIG | DATA_ID;
> + reg_val = (type << 8) | config;
> + }
> +
> + for (i = 0; i < msg->tx_len; i++)
> + writeb(tx_buf[i], dsi->regs + DSI_CMDQ0 + cmdq_off + i);
> +
> + mtk_dsi_mask(dsi, DSI_CMDQ0, cmdq_mask, reg_val);
> + mtk_dsi_mask(dsi, DSI_CMDQ_SIZE, CMDQ_SIZE, cmdq_size);
> +}
> +
> +static ssize_t mtk_dsi_host_send_cmd(struct mtk_dsi *dsi,
> + const struct mipi_dsi_msg *msg, u8 flag)
> +{
> + mtk_dsi_wait_for_idle(dsi);
> + mtk_dsi_irq_data_clear(dsi, flag);
> + mtk_dsi_cmdq(dsi, msg);
> + mtk_dsi_start(dsi);
> +
> + if (!mtk_dsi_wait_for_irq_done(dsi, flag, 2000))
> + return -ETIME;
> + else
> + return 0;
> +}
> +
> +static ssize_t mtk_dsi_host_transfer(struct mipi_dsi_host *host,
> + const struct mipi_dsi_msg *msg)
> +{
> + struct mtk_dsi *dsi = host_to_dsi(host);
> + u32 recv_cnt, i;
> + u8 read_data[16];
> + void *src_addr;
> + u8 irq_flag = CMD_DONE_INT_FLAG;
> +
> + if (readl(dsi->regs + DSI_MODE_CTRL) & MODE) {
> + DRM_ERROR("dsi engine is not command mode\n");
> + return -EINVAL;
> + }
> +
> + if (MTK_DSI_HOST_IS_READ(msg->type))
> + irq_flag |= LPRX_RD_RDY_INT_FLAG;
> +
> + if (mtk_dsi_host_send_cmd(dsi, msg, irq_flag) < 0)
> + return -ETIME;
> +
> + if (!MTK_DSI_HOST_IS_READ(msg->type))
> + return 0;
> +
> + if (!msg->rx_buf) {
> + DRM_ERROR("dsi receive buffer size may be NULL\n");
> + return -EINVAL;
> + }
> +
> + for (i = 0; i < 16; i++)
> + *(read_data + i) = readb(dsi->regs + DSI_RX_DATA0 + i);
> +
> + recv_cnt = mtk_dsi_recv_cnt(read_data[0], read_data);
> +
> + if (recv_cnt > 2)
> + src_addr = &read_data[4];
> + else
> + src_addr = &read_data[1];
> +
> + if (recv_cnt > 10)
> + recv_cnt = 10;
> +
> + if (recv_cnt > msg->rx_len)
> + recv_cnt = msg->rx_len;
> +
> + if (recv_cnt)
> + memcpy(msg->rx_buf, src_addr, recv_cnt);
> +
> + DRM_INFO("dsi get %d byte data from the panel address(0x%x)\n",
> + recv_cnt, *((u8 *)(msg->tx_buf)));
> +
> + return recv_cnt;
> +}
> +
> static const struct mipi_dsi_host_ops mtk_dsi_ops = {
> .attach = mtk_dsi_host_attach,
> .detach = mtk_dsi_host_detach,
> + .transfer = mtk_dsi_host_transfer,
> };
>
> static int mtk_dsi_bind(struct device *dev, struct device *master, void *data)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-18 7:50 UTC (permalink / raw)
To: Shawn Lin
Cc: linux-wireless, Linux Kernel, linux-mmc, devicetree,
Tony Lindgren, Ulf Hansson
In-Reply-To: <0a49ba8d-e749-8462-fa48-7d8a17cecc75@rock-chips.com>
On Sun, Jan 15, 2017 at 6:35 PM, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> On 2017/1/16 5:41, Matt Ranostay wrote:
>>
>> On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin <shawn.lin@rock-chips.com>
>> wrote:
>>>
>>> On 2017/1/13 13:29, Matt Ranostay wrote:
>>>>
>>>>
>>>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>>>> This can be abstracted to other chipsets if needed in the future.
>>>>
>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>>>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>>>> ---
>>>> drivers/mmc/core/Kconfig | 10 ++++
>>>> drivers/mmc/core/Makefile | 1 +
>>>> drivers/mmc/core/pwrseq_sd8787.c | 117
>>>> +++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 128 insertions(+)
>>>> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>>>
>>>> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
>>>> index cdfa8520a4b1..fc1ecdaaa9ca 100644
>>>> --- a/drivers/mmc/core/Kconfig
>>>> +++ b/drivers/mmc/core/Kconfig
>>>> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
>>>> This driver can also be built as a module. If so, the module
>>>> will be called pwrseq_emmc.
>>>>
>>>> +config PWRSEQ_SD8787
>>>> + tristate "HW reset support for SD8787 BT + Wifi module"
>>>> + depends on OF && (MWIFIEX || BT_MRVL_SDIO)
>>>> + help
>>>> + This selects hardware reset support for the SD8787 BT + Wifi
>>>> + module. By default this option is set to n.
>>>> +
>>>> + This driver can also be built as a module. If so, the module
>>>> + will be called pwrseq_sd8787.
>>>> +
>>>
>>>
>>>
>>> I don't like this way, as we have a chance to list lots
>>> configure options here. wifi A,B,C,D...Z, all of them need a
>>> new section here if needed?
>>>
>>> Instead, could you just extent pwrseq_simple.c and add you
>>> .compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?
>>
>>
>> You mean all the chipset pwrseqs linked into the pwrseq-simple module?
>
>
> What I mean was if you just extent the pwrseq-simple a bit, you could
> just add your chipset pwrseqs linked into the pwrseq-simple. But if you
> need a different *pattern* of pwrseqs, you should need a new name, for
> instance, pwrseq-sdio.c etc... But please don't use the name of
> sd8787? So if I use a wifi named ABC but using the same pwrseq pattenr,
> should I include your "mmc-pwrseq- sd8787" for that or I need a new
> mmc-pwrseq-ABC.c?
Ah so pwrseq-sdio.c seems reasonable and having chipsets functions
defined in a structure. That could be abstracted out for other
chipsets that could needed in the future.
- Matt
>
>
>>
>> Ulf your thoughts on this?
>>
>>>
>>>
>>>
>>>> config PWRSEQ_SIMPLE
>>>> tristate "Simple HW reset support for MMC"
>>>> default y
>>>> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
>>>> index b2a257dc644f..0f81464fa824 100644
>>>> --- a/drivers/mmc/core/Makefile
>>>> +++ b/drivers/mmc/core/Makefile
>>>> @@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
>>>> quirks.o slot-gpio.o
>>>> mmc_core-$(CONFIG_OF) += pwrseq.o
>>>> obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
>>>> +obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
>>>> obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
>>>> mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
>>>> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
>>>> diff --git a/drivers/mmc/core/pwrseq_sd8787.c
>>>> b/drivers/mmc/core/pwrseq_sd8787.c
>>>> new file mode 100644
>>>> index 000000000000..f4080fe6439e
>>>> --- /dev/null
>>>> +++ b/drivers/mmc/core/pwrseq_sd8787.c
>>>> @@ -0,0 +1,117 @@
>>>> +/*
>>>> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT +
>>>> Wifi
>>>> chip
>>>> + *
>>>> + * Copyright (C) 2016 Matt Ranostay <matt@ranostay.consulting>
>>>> + *
>>>> + * Based on the original work pwrseq_simple.c
>>>> + * Copyright (C) 2014 Linaro Ltd
>>>> + * Author: Ulf Hansson <ulf.hansson@linaro.org>
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License as published by
>>>> + * the Free Software Foundation; either version 2 of the License, or
>>>> + * (at your option) any later version.
>>>> + *
>>>> + * This program is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> + * GNU General Public License for more details.
>>>> + *
>>>> + */
>>>> +
>>>> +#include <linux/delay.h>
>>>> +#include <linux/init.h>
>>>> +#include <linux/kernel.h>
>>>> +#include <linux/platform_device.h>
>>>> +#include <linux/module.h>
>>>> +#include <linux/slab.h>
>>>> +#include <linux/device.h>
>>>> +#include <linux/err.h>
>>>> +#include <linux/gpio/consumer.h>
>>>> +
>>>> +#include <linux/mmc/host.h>
>>>> +
>>>> +#include "pwrseq.h"
>>>> +
>>>> +struct mmc_pwrseq_sd8787 {
>>>> + struct mmc_pwrseq pwrseq;
>>>> + struct gpio_desc *reset_gpio;
>>>> + struct gpio_desc *pwrdn_gpio;
>>>> +};
>>>> +
>>>> +#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787,
>>>> pwrseq)
>>>> +
>>>> +static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
>>>> +{
>>>> + struct mmc_pwrseq_sd8787 *pwrseq =
>>>> to_pwrseq_sd8787(host->pwrseq);
>>>> +
>>>> + gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
>>>> +
>>>> + msleep(300);
>>>> + gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
>>>> +}
>>>> +
>>>> +static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
>>>> +{
>>>> + struct mmc_pwrseq_sd8787 *pwrseq =
>>>> to_pwrseq_sd8787(host->pwrseq);
>>>> +
>>>> + gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
>>>> + gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
>>>> +}
>>>> +
>>>> +static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
>>>> + .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
>>>> + .power_off = mmc_pwrseq_sd8787_power_off,
>>>> +};
>>>> +
>>>> +static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
>>>> + { .compatible = "mmc-pwrseq-sd8787",},
>>>> + {/* sentinel */},
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
>>>> +
>>>> +static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct mmc_pwrseq_sd8787 *pwrseq;
>>>> + struct device *dev = &pdev->dev;
>>>> +
>>>> + pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
>>>> + if (!pwrseq)
>>>> + return -ENOMEM;
>>>> +
>>>> + pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn",
>>>> GPIOD_OUT_LOW);
>>>> + if (IS_ERR(pwrseq->pwrdn_gpio))
>>>> + return PTR_ERR(pwrseq->pwrdn_gpio);
>>>> +
>>>> + pwrseq->reset_gpio = devm_gpiod_get(dev, "reset",
>>>> GPIOD_OUT_LOW);
>>>> + if (IS_ERR(pwrseq->reset_gpio))
>>>> + return PTR_ERR(pwrseq->reset_gpio);
>>>> +
>>>> + pwrseq->pwrseq.dev = dev;
>>>> + pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
>>>> + pwrseq->pwrseq.owner = THIS_MODULE;
>>>> + platform_set_drvdata(pdev, pwrseq);
>>>> +
>>>> + return mmc_pwrseq_register(&pwrseq->pwrseq);
>>>> +}
>>>> +
>>>> +static int mmc_pwrseq_sd8787_remove(struct platform_device *pdev)
>>>> +{
>>>> + struct mmc_pwrseq_sd8787 *pwrseq = platform_get_drvdata(pdev);
>>>> +
>>>> + mmc_pwrseq_unregister(&pwrseq->pwrseq);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static struct platform_driver mmc_pwrseq_sd8787_driver = {
>>>> + .probe = mmc_pwrseq_sd8787_probe,
>>>> + .remove = mmc_pwrseq_sd8787_remove,
>>>> + .driver = {
>>>> + .name = "pwrseq_sd8787",
>>>> + .of_match_table = mmc_pwrseq_sd8787_of_match,
>>>> + },
>>>> +};
>>>> +
>>>> +module_platform_driver(mmc_pwrseq_sd8787_driver);
>>>> +MODULE_LICENSE("GPL v2");
>>>>
>>>
>>>
>>> --
>>> Best Regards
>>> Shawn Lin
>>>
>>
>>
>>
>
>
> --
> Best Regards
> Shawn Lin
>
^ permalink raw reply
* Re: [PATCH v2 02/10] clk: ccu-sun8i-a33: Add CLK_SET_RATE_PARENT to ac-dig
From: Mylene Josserand @ 2017-01-18 7:58 UTC (permalink / raw)
To: Maxime Ripard
Cc: lgirdwood, broonie, perex, tiwai, wens, mturquette, sboyd,
mark.rutland, robh+dt, linux-kernel, linux-arm-kernel, linux-clk,
alsa-devel, devicetree, linux-sunxi, thomas.petazzoni,
alexandre.belloni
In-Reply-To: <20170117164415.4qseqbqkdx3e6bvt@lukather>
Hi,
On 17/01/2017 17:44, Maxime Ripard wrote:
> Hi,
>
> On Tue, Jan 17, 2017 at 03:02:22PM +0100, Mylène Josserand wrote:
>> The audio DAI needs to set the clock rates of the ac-dig clock.
>> To make it possible, the parent PLL audio clock rates should
>> also be changed. This is possible via "CLK_SET_RATE_PARENT" flag.
>>
>> Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
>
> Please make sure to look at the prefixes usually used in the commit
> titles of the area you're working on. In this case that would have
> been "clk: sunxi-ng:". I fixed it, and applied.
Okay, I will pay more attention to prefixes for commit titles for next
times.
Thank you !
--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 1/3] USB3/DWC3: Add definition for global soc bus configuration register
From: Changming Huang @ 2017-01-18 8:12 UTC (permalink / raw)
To: balbi, robh+dt, mark.rutland, catalin.marinas
Cc: linux-usb, linux-kernel, devicetree, linux-arm-kernel,
Changming Huang
Add the macro definition for global soc bus configuration register 0/1
Signed-off-by: Changming Huang <jerry.huang@nxp.com>
---
Changes in v4:
- no change
Changes in v3:
- no change
Changes in v2:
- split the patch
- add more macro definition for soc bus configuration register
drivers/usb/dwc3/core.h | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index de5a857..065aa6f 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -161,6 +161,32 @@
/* Bit fields */
+/* Global SoC Bus Configuration Register 0 */
+#define AXI3_CACHE_TYPE_AW 0x8 /* write allocate */
+#define AXI3_CACHE_TYPE_AR 0x4 /* read allocate */
+#define AXI3_CACHE_TYPE_SNP 0x2 /* cacheable */
+#define AXI3_CACHE_TYPE_BUF 0x1 /* bufferable */
+#define DWC3_GSBUSCFG0_DATARD_SHIFT 28
+#define DWC3_GSBUSCFG0_DESCRD_SHIFT 24
+#define DWC3_GSBUSCFG0_DATAWR_SHIFT 20
+#define DWC3_GSBUSCFG0_DESCWR_SHIFT 16
+#define DWC3_GSBUSCFG0_SNP_MASK 0xffff0000
+#define DWC3_GSBUSCFG0_DATABIGEND (1 << 11)
+#define DWC3_GSBUSCFG0_DESCBIGEND (1 << 10)
+#define DWC3_GSBUSCFG0_INCR256BRSTENA (1 << 7) /* INCR256 burst */
+#define DWC3_GSBUSCFG0_INCR128BRSTENA (1 << 6) /* INCR128 burst */
+#define DWC3_GSBUSCFG0_INCR64BRSTENA (1 << 5) /* INCR64 burst */
+#define DWC3_GSBUSCFG0_INCR32BRSTENA (1 << 4) /* INCR32 burst */
+#define DWC3_GSBUSCFG0_INCR16BRSTENA (1 << 3) /* INCR16 burst */
+#define DWC3_GSBUSCFG0_INCR8BRSTENA (1 << 2) /* INCR8 burst */
+#define DWC3_GSBUSCFG0_INCR4BRSTENA (1 << 1) /* INCR4 burst */
+#define DWC3_GSBUSCFG0_INCRBRSTENA (1 << 0) /* undefined length enable */
+#define DWC3_GSBUSCFG0_INCRBRST_MASK 0xff
+
+/* Global SoC Bus Configuration Register 1 */
+#define DWC3_GSBUSCFG1_1KPAGEENA (1 << 12) /* 1K page boundary enable */
+#define DWC3_GSBUSCFG1_PTRANSLIMIT_MASK 0xf00
+
/* Global Debug Queue/FIFO Space Available Register */
#define DWC3_GDBGFIFOSPACE_NUM(n) ((n) & 0x1f)
#define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 2/3] USB3/DWC3: Add property "snps,incr-burst-type-adjustment" for INCR burst type
From: Changming Huang @ 2017-01-18 8:12 UTC (permalink / raw)
To: balbi-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Changming Huang
In-Reply-To: <1484727138-3264-1-git-send-email-jerry.huang-3arQi8VN3Tc@public.gmane.org>
Property "snps,incr-burst-type-adjustment = <x>, <y>..." for USB3.0 DWC3.
When Just one value means INCRx mode with fix burst type.
When more than one value, means undefined length burst mode, USB controller
can use the length less than or equal to the largest enabled burst length.
While enabling undefined length INCR burst type and INCR16 burst type,
get better write performance on NXP Layerscape platform:
around 3% improvement (from 364MB/s to 375MB/s).
Signed-off-by: Changming Huang <jerry.huang-3arQi8VN3Tc@public.gmane.org>
---
Changes in v4:
- change definition for this property.
Changes in v3:
- add new property for INCR burst in usb node.
Documentation/devicetree/bindings/usb/dwc3.txt | 6 ++++++
arch/arm/boot/dts/ls1021a.dtsi | 1 +
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 2 ++
4 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
index e3e6983..a68dbfc 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -55,6 +55,11 @@ Optional properties:
fladj_30mhz_sdbnd signal is invalid or incorrect.
- <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
+ register, undefined length INCR burst type enable and INCRx type.
+ When just one value, which means INCRX burst mode. When more than one
+ value, which means undefined length INCR burst type enabled.
+ The values can be 1, 4, 8, 16, 32, 64, 128 and 256.
This is usually a subnode to DWC3 glue to which it is connected.
@@ -63,4 +68,5 @@ dwc3@4a030000 {
reg = <0x4a030000 0xcfff>;
interrupts = <0 92 4>
usb-phy = <&usb2_phy>, <&usb3,phy>;
+ snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 368e219..6eee0d5 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -627,6 +627,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
pcie@3400000 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 97d331e..04ffd66 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -482,6 +482,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
usb1: usb3@3000000 {
@@ -491,6 +492,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
usb2: usb3@3100000 {
@@ -500,6 +502,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
sata: sata@3200000 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index d058e56..902cc93 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -710,6 +710,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
usb1: usb3@3110000 {
@@ -720,6 +721,7 @@
dr_mode = "host";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
+ snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
};
ccn@4000000 {
--
1.7.9.5
--
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 v4 3/3] USB3/DWC3: Enable undefined length INCR burst type
From: Changming Huang @ 2017-01-18 8:12 UTC (permalink / raw)
To: balbi, robh+dt, mark.rutland, catalin.marinas
Cc: linux-usb, linux-kernel, devicetree, linux-arm-kernel,
Changming Huang, Rajesh Bhagat
In-Reply-To: <1484727138-3264-1-git-send-email-jerry.huang@nxp.com>
Enable the undefined length INCR burst type and set INCRx.
Different platform may has the different burst size type.
In order to get best performance, we need to tune the burst size to
one special value, instead of the default value.
Signed-off-by: Changming Huang <jerry.huang@nxp.com>
Signed-off-by: Rajesh Bhagat <rajesh.bhagat@nxp.com>
---
Changes in v4:
- Modify the codes according to the definition of this property.
Changes in v3:
- add new property for INCR burst in usb node to reset GSBUSCFG0.
Changes in v2:
- split patch
- create one new function to handle soc bus configuration register.
drivers/usb/dwc3/core.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++
drivers/usb/dwc3/core.h | 7 ++++
2 files changed, 90 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 369bab1..446aec3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -650,6 +650,87 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
}
+/* set global soc bus configuration registers */
+static void dwc3_set_soc_bus_cfg(struct dwc3 *dwc)
+{
+ struct device *dev = dwc->dev;
+ u32 *vals;
+ u32 cfg;
+ int ntype;
+ int ret;
+ int i;
+
+ cfg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
+
+ /*
+ * Handle property "snps,incr-burst-type-adjustment".
+ * Get the number of value from this property:
+ * result <= 0, means this property is not supported.
+ * result = 1, means INCRx burst mode supported.
+ * result > 1, means undefined length burst mode supported.
+ */
+ ntype = device_property_read_u32_array(dev,
+ "snps,incr-burst-type-adjustment", NULL, 0);
+ if (ntype > 0) {
+ vals = kcalloc(ntype, sizeof(u32), GFP_KERNEL);
+ if (!vals) {
+ dev_err(dev, "Error to get memory\n");
+ return;
+ }
+ /* Get INCR burst type, and parse it */
+ ret = device_property_read_u32_array(dev,
+ "snps,incr-burst-type-adjustment", vals, ntype);
+ if (ret) {
+ dev_err(dev, "Error to get property\n");
+ return;
+ }
+ *(dwc->incrx_type + 1) = vals[0];
+ if (ntype > 1) {
+ *dwc->incrx_type = 1;
+ for (i = 1; i < ntype; i++) {
+ if (vals[i] > *(dwc->incrx_type + 1))
+ *(dwc->incrx_type + 1) = vals[i];
+ }
+ } else
+ *dwc->incrx_type = 0;
+
+ /* Enable Undefined Length INCR Burst and Enable INCRx Burst */
+ cfg &= ~DWC3_GSBUSCFG0_INCRBRST_MASK;
+ if (*dwc->incrx_type)
+ cfg |= DWC3_GSBUSCFG0_INCRBRSTENA;
+ switch (*(dwc->incrx_type + 1)) {
+ case 256:
+ cfg |= DWC3_GSBUSCFG0_INCR256BRSTENA;
+ break;
+ case 128:
+ cfg |= DWC3_GSBUSCFG0_INCR128BRSTENA;
+ break;
+ case 64:
+ cfg |= DWC3_GSBUSCFG0_INCR64BRSTENA;
+ break;
+ case 32:
+ cfg |= DWC3_GSBUSCFG0_INCR32BRSTENA;
+ break;
+ case 16:
+ cfg |= DWC3_GSBUSCFG0_INCR16BRSTENA;
+ break;
+ case 8:
+ cfg |= DWC3_GSBUSCFG0_INCR8BRSTENA;
+ break;
+ case 4:
+ cfg |= DWC3_GSBUSCFG0_INCR4BRSTENA;
+ break;
+ case 1:
+ break;
+ default:
+ dev_err(dev, "Invalid property\n");
+ break;
+ }
+ }
+
+ dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, cfg);
+}
+
/**
* dwc3_core_init - Low-level initialization of DWC3 Core
* @dwc: Pointer to our controller context structure
@@ -698,6 +779,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
/* Adjust Frame Length */
dwc3_frame_length_adjustment(dwc);
+ dwc3_set_soc_bus_cfg(dwc);
+
usb_phy_set_suspend(dwc->usb2_phy, 0);
usb_phy_set_suspend(dwc->usb3_phy, 0);
ret = phy_power_on(dwc->usb2_generic_phy);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 065aa6f..9df6304 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -805,6 +805,7 @@ struct dwc3_scratchpad_array {
* @regs: base address for our registers
* @regs_size: address space size
* @fladj: frame length adjustment
+ * @incrx_type: INCR burst type adjustment
* @irq_gadget: peripheral controller's IRQ number
* @nr_scratch: number of scratch buffers
* @u1u2: only used on revisions <1.83a for workaround
@@ -928,6 +929,12 @@ struct dwc3 {
enum usb_phy_interface hsphy_mode;
u32 fladj;
+ /*
+ * For INCR burst type.
+ * First field: for undefined length INCR burst type enable.
+ * Second field: for INCRx burst type enable
+ */
+ u32 incrx_type[2];
u32 irq_gadget;
u32 nr_scratch;
u32 u1u2;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2 03/10] dt-bindings: sound: Add new reset compatible for sun4i-i2s
From: Mylene Josserand @ 2017-01-18 8:23 UTC (permalink / raw)
To: Maxime Ripard
Cc: lgirdwood, broonie, perex, tiwai, wens, mturquette, sboyd,
mark.rutland, robh+dt, linux-kernel, linux-arm-kernel, linux-clk,
alsa-devel, devicetree, linux-sunxi, thomas.petazzoni,
alexandre.belloni
In-Reply-To: <20170117164636.qhkxvqcs7l732wxk@lukather>
Hi,
On 17/01/2017 17:46, Maxime Ripard wrote:
> On Tue, Jan 17, 2017 at 03:02:23PM +0100, Mylène Josserand wrote:
>> Add a new compatible for sun4i-i2s driver to handle some
>> SoCs that have a reset line that must be asserted/deasserted.
>>
>> This new compatible, "allwinner,sun6i-a31-i2s", requires two
>> properties:
>> - resets: phandle to the reset line
>> - reset-names: the name of the reset line ("rst").
>> Except these differences, the compatible is identical to previous one
>> which will not handle a reset line.
>>
>> Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
>> ---
>> .../devicetree/bindings/sound/sun4i-i2s.txt | 23 ++++++++++++++++++++++
>> 1 file changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
>> index 7a2c0945fd22..f673206e309b 100644
>> --- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
>> +++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
>> @@ -7,6 +7,7 @@ Required properties:
>>
>> - compatible: should be one of the following:
>> - "allwinner,sun4i-a10-i2s"
>> + - "allwinner,sun6i-a31-i2s" for controller with reset lines
>
> That's not only for controllers with reset lines, but for the
> controllers found in the A31 (and later). I'd simply drop the last
> part of that line.
ACK
>
>> - reg: physical base address of the controller and length of memory mapped
>> region.
>> - interrupts: should contain the I2S interrupt.
>> @@ -19,7 +20,13 @@ Required properties:
>> - "mod" : module clock for the I2S controller
>> - #sound-dai-cells : Must be equal to 0
>>
>> +Required properties for the following compatibles:
>> + - "allwinner,sun6i-a31-i2s"
>> +- resets: phandle to the reset line for this codec
>> +- reset-names: Contains the reset signal name "rst"
>
> You don't need reset-names if there's a single reset line.
>
ACK
>> +
>> Example:
>> +For "allwinner,sun4i-a10-i2s":
>>
>> i2s0: i2s@01c22400 {
>> #sound-dai-cells = <0>;
>> @@ -32,3 +39,19 @@ i2s0: i2s@01c22400 {
>> <&dma SUN4I_DMA_NORMAL 3>;
>> dma-names = "rx", "tx";
>> };
>> +
>> +For "allwinner,sun6i-a31-i2s":
>> +
>> +dai: dai@01c22c00 {
>> + #sound-dai-cells = <0>;
>> + compatible = "allwinner,sun6i-a31-i2s";
>> + reg = <0x01c22c00 0x200>;
>> + interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
>> + clock-names = "apb", "mod";
>> + resets = <&ccu RST_BUS_CODEC>;
>> + reset-names = "rst";
>> + dmas = <&dma 15>, /* AUDIO_CODEC port */
>> + <&dma 15>; /* AUDIO_CODEC port */
>> + dma-names = "rx", "tx";
>> +};
>
> And we already have an example, so there's no need to add a new one
> either.
I will remove it on a V3.
Thank you the review!
--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 07/10] dt-bindings: sound: Add sun8i audio documentation
From: Mylene Josserand @ 2017-01-18 8:25 UTC (permalink / raw)
To: Mark Brown
Cc: lgirdwood, perex, tiwai, maxime.ripard, wens, mturquette, sboyd,
mark.rutland, robh+dt, linux-kernel, linux-arm-kernel, linux-clk,
alsa-devel, devicetree, linux-sunxi, thomas.petazzoni,
alexandre.belloni
In-Reply-To: <20170117165029.wu4m6flhdwxk5e3q@sirena.org.uk>
Hi,
On 17/01/2017 17:50, Mark Brown wrote:
> On Tue, Jan 17, 2017 at 03:02:27PM +0100, Mylène Josserand wrote:
>> Add the documentation for dt-binding of the digital audio codec driver
>> and the audio card driver for Sun8i SoCs.
>
>
> Please submit patches using subject lines reflecting the style for the
> subsystem. This makes it easier for people to identify relevant
> patches. Look at what existing commits in the area you're changing are
> doing and make sure your subject lines visually resemble what they're
> doing.
>
Yeah, sorry about that. Maxime indicated it in another patch. I will
keep it in mind for next times.
Anyway, thank you for the review!
Best regards,
--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 1/3] dt/bindings: da8xx-usb: Add binding for the CPPI 4.1 DMA controller
From: Sekhar Nori @ 2017-01-18 8:33 UTC (permalink / raw)
To: Sergei Shtylyov, Alexandre Bailon,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, khilman-rdvid1DuHRBWk0Htik3J/w,
ptitiano-rdvid1DuHRBWk0Htik3J/w, tony-4v6yS6AI5VpBDgjK7y7TUQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA, b-liu-l0cyMroinI0,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <aa9b6761-c8de-13ea-1a62-9810ad92a6d4-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On Tuesday 17 January 2017 10:46 PM, Sergei Shtylyov wrote:
> On 01/17/2017 05:20 PM, Alexandre Bailon wrote:
>
>> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx cppi41 dma controller.
>>
>> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> .../devicetree/bindings/usb/da8xx-usb.txt | 42
>> ++++++++++++++++++++++
>> 1 file changed, 42 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>> b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>> index ccb844a..aed3169 100644
>> --- a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>> +++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>> @@ -18,10 +18,26 @@ Required properties:
>>
>> - phy-names: Should be "usb-phy"
>>
>> + - dmas: specifies the dma channels
>> +
>> + - dma-names: specifies the names of the channels. Use "rxN" for receive
>> + and "txN" for transmit endpoints. N specifies the endpoint number.
>> +
>> Optional properties:
>> ~~~~~~~~~~~~~~~~~~~~
>> - vbus-supply: Phandle to a regulator providing the USB bus power.
>>
>> +DMA
>> +~~~
>> +- compatible: ti,da8xx-cppi41
>
> Almost missed this -- wildcards in this property are forbidden.
> We should use "ti,da830-cppi41" as a least common denominator.
Documentation/devicetree/bindings/submitting-patches.txt states:
"
5) The wildcard "<chip>" may be used in compatible strings, as in
the following example:
- compatible: Must contain '"nvidia,<chip>-pcie",
"nvidia,tegra20-pcie"' where <chip> is tegra30, tegra132, ...
"
I take this to mean that using wildcards to denote an SoC family on
which the same IP is present is okay to do. With that understanding, I
think using ti,da8xx-cppi41 is fine too. Although I have no objections
against using the more specific ti,da830-cppi41
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: dts: r7s72100: update sdhi clock bindings
From: Geert Uytterhoeven @ 2017-01-18 8:41 UTC (permalink / raw)
To: Chris Brandt
Cc: Ulf Hansson, Rob Herring, Mark Rutland, Simon Horman,
Wolfram Sang, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux MMC List, Linux-Renesas
In-Reply-To: <20170117195940.25092-4-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Tue, Jan 17, 2017 at 8:59 PM, Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> The SDHI controller in the RZ/A1 has 2 clock sources per channel and both
> need to be enabled/disabled for proper operation. This fixes the fact that
> the define for R7S72100_CLK_SDHI1 was not correct to begin with (typo), and
> that all 4 clock sources need to be defined an used.
>
> Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Note that this depends on the acceptance of the DT binding doc update.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/3] mmc: sh_mobile_sdhi: explain clock bindings
From: Geert Uytterhoeven @ 2017-01-18 8:44 UTC (permalink / raw)
To: Chris Brandt
Cc: Ulf Hansson, Rob Herring, Mark Rutland, Simon Horman,
Wolfram Sang, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux MMC List, Linux-Renesas
In-Reply-To: <20170117195940.25092-3-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Hi Chris,
On Tue, Jan 17, 2017 at 8:59 PM, Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> In the case of a single clock source, you don't need names. However,
> if the controller has 2 clock sources, you need to name them correctly
> so the driver can find the 2nd one.
>
> Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> index a1650ed..258b98c 100644
> --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> @@ -25,8 +25,29 @@ Required properties:
> "renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC
> "renesas,sdhi-r8a7796" - SDHI IP on R8A7796 SoC
>
> +- clocks: Most controllers only have 1 clock source per cahnnel. However, some
> + have 2. If 2 clocks are specified, you must name them as "core" and
> + "carddetect". If the controller only has 1 clock, naming is not
Perhaps this clock should just be called "cd", as that's already an
established abbreviation for card detect in MMC DT bindings?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 4/5] dt: bindings: i2c-mux-pca954x: Add documentation for nxp,irq-mask-enable
From: Phil Reid @ 2017-01-18 9:00 UTC (permalink / raw)
To: Peter Rosin, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1abf8327-9c3c-f390-fbc4-9eb142068a66-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 17/01/2017 18:14, Peter Rosin wrote:
> On 2017-01-17 10:43, Peter Rosin wrote:
>> On 2017-01-17 10:28, Phil Reid wrote:
>>> On 17/01/2017 16:57, Peter Rosin wrote:
>>>> On 2017-01-17 09:00, Phil Reid wrote:
>>>>> Unfortunately some hardware device will assert their irq line immediately
>>>>> on power on and provide no mechanism to mask the irq. As the i2c muxes
>>>>> provide no method to mask irq line this provides a work around by keeping
>>>>> the parent irq masked until enough device drivers have loaded to service
>>>>> all pending interrupts.
>>>>>
>>>>> For example the the ltc1760 assert its SMBALERT irq immediately on power
>>>>> on. With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
>>>>> device is registered irq are enabled and fire continuously as the second
>>>>> device driver has not yet loaded. Setting this parameter to <1 1> will
>>>>> delay the irq being enabled until both devices are ready.
>>>>
>>> G'day Peter,
>>>
>>>
>>>> Hang on, does this suggestion I made make any sense at all? Maybe it does,
>>>> but does the pca954x driver even get notified of any but the first irq client
>>>> that unmasks interrupts on a mux segment? How can it count the number of
>>>> active irq clients if not?
>>>
>>> Good question.
>>>
>>> So what I did to test is setup my 2 ltc1760s to use the same irq on the pca954x.
>>> Using the latest patch series.
>>>
>>> Adding a log message into the irq_unmask function got the following.
>>> dev_err(&data->client->dev, "irq_unmask %d %x %d", pos, data->irq_mask, data->irq_enabled);
>>>
>>> dmesg | grep irq_unmask
>>> [ 4.392098] pca954x 4-0070: irq_unmask 0 1 1
>>>
>>>
>>> But Looks like both got registered ok to the same irq.
>>> cat /proc/interrupts
>>> 161: 0 0 i2c-mux-pca954x 0 Level 15-000a, 16-000a
>>>
>>> So from this testing, it doesn't look like it gets called multiple times.
>>
>> As I suspected, thanks for verifying!
>>
>>> So back to the bitmask for the dt do you think.
>>
>> Looking at kernel/irq/chip.c:irq_enable (and struct irq_chip docs), I get the
>> feeling that if you provide the irq_enable operation (and maybe irq_disable too?),
>> that might get us more info?
>
> No, I no longer think that. I think we need to get at the irq descriptor "depth".
> But that feels like poking at the wrong level. Crap.
>
> And to answer the question if I think we should go back to a dt bitmask, then
> no I do not think that. The array describes what we want to do, it's the linux
> implementation that gives us difficulties. Agreed?
G'day Peter,
Yes agreed, that makes sense.
I had a play with using the irq_enable call back.
But that doesn't seem to offer any more feedback then unmask.
Called just once on the first irq that registers.
The only way I can see to count the number of registered handlers on a
shared irq is to count the action handlers on the irq_desc.
The only irq_chip handler that seems guaranteed to be called on irq request is
irq_bus_lock, irq_bus_sync_unlock callbacks, but these are called elsewhere
at various times.
We have a dt spec that supports this future proofing of the irq count.
But as you say the kernel code prevents us at the moment.
The count of 1 bitmask implementation works for my particular situation at the moment.
Perhaps the > 1 case can be tackled in the future when someone has a use case?
Thoughts?
>
>>> I think the interrupt enablelogic is correct now.
>>>
>>>>
>>>> I'm truly sorry for the trouble I'm causing by not just saying how it should
>>>> be done from the start, but I feel like I've been thrown in at the deep end
>>>> when it comes to interrupt controllers...
>>>
>>> No problem. I'm learning a couple things as we go.
>>> Should help me out on other drivers :)
>>
>> Yes, I'm also picking up a few bits here and there...
--
Regards
Phil Reid
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 06/14] ARM: davinci: da850: model the SATA refclk
From: Sekhar Nori @ 2017-01-18 9:02 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Patrick Titiano,
Michael Turquette, Tejun Heo, Rob Herring, Mark Rutland,
Russell King, David Lechner
Cc: linux-ide, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <1484655976-25382-7-git-send-email-bgolaszewski@baylibre.com>
On Tuesday 17 January 2017 05:56 PM, Bartosz Golaszewski wrote:
> Register a dummy clock modelling the external SATA oscillator for
I would not call it a dummy clock. Its representing something physically
present. Just call it "fixed rate clock" ?
> da850 DT mode. For non-DT boot we don't register the clock - instead
> we rely on the default MPY value defined in the da850 ahci driver (as
> is done currently).
Here too, like David suggested, it will be nice to register it both for
DT and non-DT case. With that I think your driver will be simple too
since you dont have to worry about the case when refclkpn is not supplied.
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> arch/arm/mach-davinci/da8xx-dt.c | 8 ++++++++
> arch/arm/mach-davinci/devices-da8xx.c | 23 +++++++++++++++++++++++
> arch/arm/mach-davinci/include/mach/da8xx.h | 1 +
> 3 files changed, 32 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index b83e5d1..13137cb 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -61,6 +61,14 @@ static void __init da850_init_machine(void)
> pr_warn("%s: registering USB 1.1 PHY clock failed: %d",
> __func__, ret);
>
> + if (of_machine_is_compatible("ti,da850-evm") ||
> + of_machine_is_compatible("ti,da850-lcdk")) {
> + ret = da850_register_sata_refclk(100000000);
> + if (ret)
> + pr_warn("%s: registering SATA_REFCLK clock failed: %d",
> + __func__, ret);
> + }
Since all supported boards use 100 Mhz refclk anyway, I would drop the
machine check and just do:
/* All existing boards use 100MHz SATA refclkpn */
unsigned long sata_refclkpn = 100 * 1000 * 1000;
ret = da850_register_sata_refclk(sata_refclkpn);
It should then be easy for the odd board (when it comes) to set
sata_refclkpn to a different value.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v2 01/14] devicetree: bindings: add bindings for ahci-da850
From: Sekhar Nori @ 2017-01-18 9:05 UTC (permalink / raw)
To: David Lechner, Bartosz Golaszewski, Kevin Hilman, Patrick Titiano,
Michael Turquette, Tejun Heo, Rob Herring, Mark Rutland,
Russell King
Cc: linux-ide, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <7e3c8946-2a19-3e11-c071-b3737554005c@lechnology.com>
On Wednesday 18 January 2017 12:05 AM, David Lechner wrote:
> On 01/17/2017 06:26 AM, Bartosz Golaszewski wrote:
>> Add DT bindings for the TI DA850 AHCI SATA controller.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> Documentation/devicetree/bindings/ata/ahci-da850.txt | 18
>> ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
>>
>> diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> b/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> new file mode 100644
>> index 0000000..e7111b4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt
>> @@ -0,0 +1,18 @@
>> +Device tree binding for the TI DA850 AHCI SATA Controller
>> +---------------------------------------------------------
>> +
>> +Required properties:
>> + - compatible: must be "ti,da850-ahci"
>> + - reg: physical base addresses and sizes of the controller's
>> register areas
>> + - interrupts: interrupt specifier (refer to the interrupt binding)
>> +
>> +Optional properties:
>> + - clocks: clock specifier (refer to the common clock binding)
>
> Won't you also need a clock-names property since there are two clocks?
>
>> +
>> +Example:
>> +
>> + sata: ahci@218000 {
>> + compatible = "ti,da850-ahci";
>> + reg = <0x218000 0x2000>, <0x22c018 0x4>;
>> + interrupts = <67>;
>> + };
>>
>
> It would be nice to have clocks and clock-names in the example as well.
Well, we don't use the common clock binding today. Is it really
necessary to add them now. Thats basically going to remain completely
untested.
I would drop the mention of clocks specification as an optional property
too.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v4 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
From: Vivek Gautam @ 2017-01-18 9:13 UTC (permalink / raw)
To: Kishon Vijay Abraham I, robh+dt, linux-kernel, devicetree
Cc: mark.rutland, sboyd, bjorn.andersson, srinivas.kandagatla,
linux-arm-msm
In-Reply-To: <587C880E.90803@ti.com>
Hi Kishon,
On 01/16/2017 02:15 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:
>> PHY transceiver driver for QUSB2 phy controller that provides
>> HighSpeed functionality for DWC3 controller present on
>> Qualcomm chipsets.
>>
>> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
>> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>
>> Changes since v3:
>> - Added 'Reviewed-by' from Stephen.
>> - Fixed debug message for qusb2_phy_set_tune2_param().
>> - Replaced devm_reset_control_get() with devm_reset_control_get_by_index()
>> since we are requesting only one reset.
>> - Updated devm_nvmem_cell_get() with a NULL cell id.
>> - Made error labels more idiomatic.
>> - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept
>> base address and register offset as two separate arguments.
>>
>> Changes since v2:
>> - Removed selecting 'RESET_CONTROLLER' config.
>> - Added error handling for clk_prepare_enable paths.
>> - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
>> do that since 'xo' is modeled as parent to this clock.
>> - Removed 'ref_clk_src' handling. Driver doesn't need to request and
>> handle this clock.
>> - Moved nvmem_cell_get() to probe function.
>> - Simplified phy pll status handling.
>> - Using of_device_get_match_data() to get match data.
>> - Uniformly using lowercase for hex numbers.
>> - Fixed sparse warnings.
>> - Using shorter variable names in structure and in functions.
>> - Handling various comment style shortcomings.
>>
>> Changes since v1:
>> - removed reference to clk_enabled/pwr_enabled.
>> - moved clock and regulator enable code to phy_power_on/off() callbacks.
>> - fixed return on EPROBE_DEFER in qusb2_phy_probe().
>> - fixed phy create and phy register ordering.
>> - removed references to non-lkml links from commit message.
>> - took care of other minor nits.
>> - Fixed coccinelle warnings -
>> 'PTR_ERR applied after initialization to constant'
>> - Addressed review comment, regarding qfprom access for tune2 param value.
>> This driver is now based on qfprom patch[1] that allows byte access now.
>>
>> drivers/phy/Kconfig | 10 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-qcom-qusb2.c | 539 +++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 550 insertions(+)
>> create mode 100644 drivers/phy/phy-qcom-qusb2.c
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index e8eb7f225a88..0ed53d018b23 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -430,6 +430,16 @@ config PHY_STIH407_USB
>> Enable this support to enable the picoPHY device used by USB2
>> and USB3 controllers on STMicroelectronics STiH407 SoC families.
>>
>> +config PHY_QCOM_QUSB2
>> + tristate "Qualcomm QUSB2 PHY Driver"
>> + depends on OF && (ARCH_QCOM || COMPILE_TEST)
>> + select GENERIC_PHY
>> + help
>> + Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
>> + controllers on Qualcomm chips. This driver supports the high-speed
>> + PHY which is usually paired with either the ChipIdea or Synopsys DWC3
>> + USB IPs on MSM SOCs.
>> +
>> config PHY_QCOM_UFS
>> tristate "Qualcomm UFS PHY driver"
>> depends on OF && ARCH_QCOM
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 65eb2f436a41..dad1682b80e3 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -49,6 +49,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
>> obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
>> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
>> obj-$(CONFIG_PHY_STIH407_USB) += phy-stih407-usb.o
>> +obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
>> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
>> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
>> obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
>> diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
>> new file mode 100644
>> index 000000000000..c69118610164
>> --- /dev/null
>> +++ b/drivers/phy/phy-qcom-qusb2.c
>> @@ -0,0 +1,539 @@
>> +/*
>> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only 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/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/mfd/syscon.h>
>> +#include <linux/module.h>
>> +#include <linux/nvmem-consumer.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/phy/phy.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regmap.h>
>> +#include <linux/regulator/consumer.h>
>> +#include <linux/reset.h>
>> +#include <linux/slab.h>
>> +
>> +#define QUSB2PHY_PLL_TEST 0x04
>> +#define CLK_REF_SEL BIT(7)
>> +
>> +#define QUSB2PHY_PLL_TUNE 0x08
>> +#define QUSB2PHY_PLL_USER_CTL1 0x0c
>> +#define QUSB2PHY_PLL_USER_CTL2 0x10
>> +#define QUSB2PHY_PLL_AUTOPGM_CTL1 0x1c
>> +#define QUSB2PHY_PLL_PWR_CTRL 0x18
>> +
>> +#define QUSB2PHY_PLL_STATUS 0x38
>> +#define PLL_LOCKED BIT(5)
>> +
>> +#define QUSB2PHY_PORT_TUNE1 0x80
>> +#define QUSB2PHY_PORT_TUNE2 0x84
>> +#define QUSB2PHY_PORT_TUNE3 0x88
>> +#define QUSB2PHY_PORT_TUNE4 0x8c
>> +#define QUSB2PHY_PORT_TUNE5 0x90
>> +#define QUSB2PHY_PORT_TEST2 0x9c
>> +
>> +#define QUSB2PHY_PORT_POWERDOWN 0xb4
>> +#define CLAMP_N_EN BIT(5)
>> +#define FREEZIO_N BIT(1)
>> +#define POWER_DOWN BIT(0)
>> +
>> +#define QUSB2PHY_REFCLK_ENABLE BIT(0)
>> +
>> +#define PHY_CLK_SCHEME_SEL BIT(0)
>> +
>> +struct qusb2_phy_init_tbl {
>> + unsigned int offset;
>> + unsigned int val;
>> +};
>> +#define QUSB2_PHY_INIT_CFG(o, v) \
>> + { \
>> + .offset = o, \
>> + .val = v, \
>> + }
>> +
>> +static const struct qusb2_phy_init_tbl msm8996_init_tbl[] = {
>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE1, 0xf8),
>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE2, 0xb3),
>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE3, 0x83),
>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TUNE4, 0xc0),
>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_TUNE, 0x30),
>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL1, 0x79),
>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_USER_CTL2, 0x21),
>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PORT_TEST2, 0x14),
>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_AUTOPGM_CTL1, 0x9f),
>> + QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
>> +};
> I wish all this data comes from device tree and one API in phy-core can do all
> these settings. Your other driver qcom-qmp also seems to have a bunch of
> similar settings.
>
> The problem is every vendor driver adds a bunch of code to perform the same
> thing again and again when all of these settings can be done by a single phy API.
Yes, i understand this. You have commented similar thing in the patch
from Jaehoon -
[PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy
I would like to understand the requirements here.
Would you like me to get all this information from the device tree -
an array of register offset and value pair, which we can then program
by calling a phy_ops (may be calibrate) ? Something of this sort:
phy-calibrate-data = <val1, register_offset1>,
<val2, register_offset2>,
<val3, register_offset3>,
....
I am sure having such information in the driver (like i have in my patch)
makes the driver look more clumsy.
But, all this data can be pretty huge - a set of some 100+
register-value pairs
for QMP phy, for example. So, will it be okay to get this from device tree ?
We also note here that such information changes from one IP version to
another.
I remember Rob having some concerns about it.
Regards
Vivek
> Thanks
> Kishon
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v7 3/8] PWM: add pwm-stm32 DT bindings
From: Thierry Reding @ 2017-01-18 9:20 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
fabrice.gasnier-qxv4g6HH51o, gerald.baeza-qxv4g6HH51o,
arnaud.pouliquen-qxv4g6HH51o,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Benjamin Gaignard
In-Reply-To: <1483608344-9012-4-git-send-email-benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2578 bytes --]
On Thu, Jan 05, 2017 at 10:25:39AM +0100, Benjamin Gaignard wrote:
> Define bindings for pwm-stm32
>
> version 6:
> - change st,breakinput parameter format to make it usuable on stm32f7 too.
>
> version 2:
> - use parameters instead of compatible of handle the hardware configuration
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
> ---
> .../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> new file mode 100644
> index 0000000..866f222
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> @@ -0,0 +1,33 @@
> +STMicroelectronics STM32 Timers PWM bindings
> +
> +Must be a sub-node of an STM32 Timers device tree node.
> +See ../mfd/stm32-timers.txt for details about the parent node.
> +
> +Required parameters:
> +- compatible: Must be "st,stm32-pwm".
> +- pinctrl-names: Set to "default".
> +- pinctrl-0: List of phandles pointing to pin configuration nodes for PWM module.
> + For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
> +
> +Optional parameters:
> +- st,breakinput: Arrays of three u32 <index level filter> to describe break input configurations.
> + "index" indicates on which break input the configuration should be applied.
It might be useful to specify what the valid values are for the break
input index.
Also, u32 is kind of a Linuxism, perhaps "Arrays of three cells"? Also,
does this mean there can be multiple entries? Such as 6 cells for two
configurations? What's the maximum number of such configurations?
If it's possible to specify multiple configurations, maybe a slightly
clearer wording would be: "One or more <index level filter> triplets to
describe..."
> + "level" gives the active level (0=low or 1=high) for this configuration.
So how does this work exactly? "level" specifies the output level if the
filter value is matched?
> + "filter" gives the filtering value to be applied.
Is this a single value at which "level" will be applied? Or is it an
upper/lower bound that can be used to restrict the output to "level" if
the signal goes beyond/below a certain threshold?
Maybe an example would clarify this. Or perhaps a reference to a manual
where a more in-depth description of this functionality can be found.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] dt/bindings: da8xx-usb: Add binding for the CPPI 4.1 DMA controller
From: Sergei Shtylyov @ 2017-01-18 9:30 UTC (permalink / raw)
To: Sekhar Nori, Alexandre Bailon, vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, khilman-rdvid1DuHRBWk0Htik3J/w,
ptitiano-rdvid1DuHRBWk0Htik3J/w, tony-4v6yS6AI5VpBDgjK7y7TUQ,
linux-omap-u79uwXL29TY76Z2rM5mHXA, b-liu-l0cyMroinI0,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <710c724c-3831-e9d1-406b-76bdfed7b948-l0cyMroinI0@public.gmane.org>
Hello!
On 1/18/2017 11:33 AM, Sekhar Nori wrote:
>>> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx cppi41 dma controller.
>>>
>>> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/usb/da8xx-usb.txt | 42
>>> ++++++++++++++++++++++
>>> 1 file changed, 42 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>> b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>> index ccb844a..aed3169 100644
>>> --- a/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>> +++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt
>>> @@ -18,10 +18,26 @@ Required properties:
>>>
>>> - phy-names: Should be "usb-phy"
>>>
>>> + - dmas: specifies the dma channels
>>> +
>>> + - dma-names: specifies the names of the channels. Use "rxN" for receive
>>> + and "txN" for transmit endpoints. N specifies the endpoint number.
>>> +
>>> Optional properties:
>>> ~~~~~~~~~~~~~~~~~~~~
>>> - vbus-supply: Phandle to a regulator providing the USB bus power.
>>>
>>> +DMA
>>> +~~~
>>> +- compatible: ti,da8xx-cppi41
>>
>> Almost missed this -- wildcards in this property are forbidden.
>> We should use "ti,da830-cppi41" as a least common denominator.
>
> Documentation/devicetree/bindings/submitting-patches.txt states:
>
> "
> 5) The wildcard "<chip>" may be used in compatible strings, as in
> the following example:
>
> - compatible: Must contain '"nvidia,<chip>-pcie",
> "nvidia,tegra20-pcie"' where <chip> is tegra30, tegra132, ...
> "
>
> I take this to mean that using wildcards to denote an SoC family on
> which the same IP is present is okay to do.> With that understanding, I
> think using ti,da8xx-cppi41 is fine too.
It doesn't really follow. I repeat, x's are not allowed.
[...]
> Thanks,
> Sekhar
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: devicetree: amlogic: Add R-Box Pro
From: Neil Armstrong @ 2017-01-18 9:35 UTC (permalink / raw)
To: Andreas Färber, linux-amlogic
Cc: Mark Rutland, devicetree, Kevin Hilman, linux-kernel, Rob Herring,
Carlo Caione, ada, linux-arm-kernel
In-Reply-To: <20170117225459.4438-2-afaerber@suse.de>
On 01/17/2017 11:54 PM, Andreas Färber wrote:
> Cc: ada@kingnoval.com
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
> Originally I thought we would group by SoC (6, 8, 8b, gxbb, gxl, gmx, etc.)
> but this got out of order with nexbox,a95x - so inserting kingnovel between
> amlogic and nexbox here. If that's what we want going forward, we should move
> the old entries to make the scheme clearer. The alternative would be to
> reorder alphabetically within each SoC group, but nexbox,a95x with two SoCs
> makes it difficult to categorize, we could choose gxbb as the earlier one.
Andreas,
Feel free to provide a fixup.
Neil
>
> Documentation/devicetree/bindings/arm/amlogic.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
> index 9b2b41ab6817..fb0ee7d9a921 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -45,5 +45,6 @@ Board compatible values:
> - "amlogic,p231" (Meson gxl s905d)
> - "amlogic,q200" (Meson gxm s912)
> - "amlogic,q201" (Meson gxm s912)
> + - "kingnovel,r-box-pro" (Meson gxm S912)
> - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
> - "nexbox,a1" (Meson gxm s912)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] of: Export of_node_ktype
From: Alexander Sverdlin @ 2017-01-18 9:37 UTC (permalink / raw)
Cc: Alexander Sverdlin, Rob Herring, Frank Rowand,
devicetree-u79uwXL29TY76Z2rM5mHXA
This is necessary for of_node_init() to work in the modules.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
drivers/of/base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..2eb4dea62b84 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -106,6 +106,7 @@ static void of_node_release(struct kobject *kobj)
struct kobj_type of_node_ktype = {
.release = of_node_release,
};
+EXPORT_SYMBOL_GPL(of_node_ktype);
static ssize_t of_node_property_read(struct file *filp, struct kobject *kobj,
struct bin_attribute *bin_attr, char *buf,
--
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] of: Export __of_find_all_nodes()
From: Alexander Sverdlin @ 2017-01-18 9:38 UTC (permalink / raw)
Cc: Alexander Sverdlin, Rob Herring, Frank Rowand,
devicetree-u79uwXL29TY76Z2rM5mHXA
This is necessary for for_each_of_allnodes() to work in the modules.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
drivers/of/base.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 2eb4dea62b84..f576c33e0b84 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -270,6 +270,7 @@ struct device_node *__of_find_all_nodes(struct device_node *prev)
}
return np;
}
+EXPORT_SYMBOL_GPL(__of_find_all_nodes);
/**
* of_find_all_nodes - Get next node in global list
--
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
* Re: [PATCH v2 12/14] ARM: dts: da850: add pinmux settings for the SATA controller
From: Sekhar Nori @ 2017-01-18 9:39 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Patrick Titiano,
Michael Turquette, Tejun Heo, Rob Herring, Mark Rutland,
Russell King, David Lechner
Cc: linux-ide, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1484655976-25382-13-git-send-email-bgolaszewski@baylibre.com>
Hi Bartosz,
On Tuesday 17 January 2017 05:56 PM, Bartosz Golaszewski wrote:
> Add pinmux sub-nodes for all muxed SATA pins.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Since these are all unused at this time, we should drop adding them
until a time someone really needs these.
Thanks,
Sekhar
^ 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