* Re: [Patch v5 1/2] dmaengine: add Qualcomm BAM dma driver
From: Stephen Boyd @ 2014-02-08 2:42 UTC (permalink / raw)
To: Andy Gross
Cc: devicetree, Vinod Koul, linux-arm-msm, linux-kernel, dmaengine,
Dan Williams, linux-arm-kernel
In-Reply-To: <1391546556-27702-2-git-send-email-agross@codeaurora.org>
On 02/04, Andy Gross wrote:
> diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c
> new file mode 100644
> index 0000000..214250c
> --- /dev/null
> +++ b/drivers/dma/qcom_bam_dma.c
> @@ -0,0 +1,1066 @@
> +/*
> + * QCOM BAM DMA engine driver
Can you please move this down into the comment below?
> + *
> + * Copyright (c) 2013-2014, 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.
> + *
And split this out into its own comment block? I think this will
make the lawyers happier.
> + *
> + * QCOM BAM DMA blocks are distributed amongst a number of the on-chip
> + * peripherals on the MSM 8x74. The configuration of the channels are dependent
> + * on the way they are hard wired to that specific peripheral. The peripheral
> + * device tree entries specify the configuration of each channel.
> + *
> + * The DMA controller requires the use of external memory for storage of the
> + * hardware descriptors for each channel. The descriptor FIFO is accessed as a
> + * circular buffer and operations are managed according to the offset within the
> + * FIFO. After pipe/channel reset, all of the pipe registers and internal state
> + * are back to defaults.
> + *
> + * During DMA operations, we write descriptors to the FIFO, being careful to
> + * handle wrapping and then write the last FIFO offset to that channel's
> + * P_EVNT_REG register to kick off the transaction. The P_SW_OFSTS register
> + * indicates the current FIFO offset that is being processed, so there is some
> + * indication of where the hardware is currently working.
> + */
[...]
> +
> +/* PIPE CTRL */
> +#define P_EN BIT(1)
^^^^
Nitpick: Weird tab here?
> +
> +/**
> + * bam_start_dma - start next transaction
> + * @bchan - bam dma channel
> + *
> + * Note: must hold bam dma channel vc.lock
You can use lockdep_assert_held() here to document this
requirement and test for it at runtime.
> + */
> +static void bam_start_dma(struct bam_chan *bchan)
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v8 3/3] mmc: sdhci-msm: Add platform_execute_tunning implementation
From: Stephen Boyd @ 2014-02-08 3:23 UTC (permalink / raw)
To: Georgi Djakov
Cc: linux-mmc, cjb, devicetree, grant.likely, rob.herring, pawel.moll,
mark.rutland, swarren, ijc+devicetree, galak, rob, linux-doc,
linux-kernel, linux-arm-msm
In-Reply-To: <1391107507-17321-4-git-send-email-gdjakov@mm-sol.com>
On 01/30, Georgi Djakov wrote:
> @@ -75,17 +110,389 @@ struct sdhci_msm_host {
> };
>
> /* MSM platform specific tuning */
> -int sdhci_msm_execute_tuning(struct sdhci_host *host, u32 opcode)
> +static inline int msm_dll_poll_ck_out_en(struct sdhci_host *host, u8 poll)
> +{
> + u32 wait_cnt = 50;
> + u8 ck_out_en = 0;
Looks like a useless assignment.
> + struct mmc_host *mmc = host->mmc;
> +
> + /* poll for CK_OUT_EN bit. max. poll time = 50us */
> + ck_out_en = !!(readl_relaxed(host->ioaddr + CORE_DLL_CONFIG) &
> + CORE_CK_OUT_EN);
> +
> + while (ck_out_en != poll) {
> + if (--wait_cnt == 0) {
> + dev_err(mmc_dev(mmc), "%s: CK_OUT_EN bit is not %d\n",
> + mmc_hostname(mmc), poll);
> + return -ETIMEDOUT;
> + }
> + udelay(1);
> +
> + ck_out_en = !!(readl_relaxed(host->ioaddr + CORE_DLL_CONFIG) &
> + CORE_CK_OUT_EN);
> + }
> +
> + return 0;
> +}
> +
> +static int msm_config_cm_dll_phase(struct sdhci_host *host, u8 phase)
> +{
> + int rc = 0;
Looks like a useless assignment.
> + u8 grey_coded_phase_table[] = {
> + 0x0, 0x1, 0x3, 0x2, 0x6, 0x7, 0x5, 0x4,
> + 0xc, 0xd, 0xf, 0xe, 0xa, 0xb, 0x9, 0x8
> + };
This could be static const?
> + unsigned long flags;
> + u32 config;
> + struct mmc_host *mmc = host->mmc;
> +
> + spin_lock_irqsave(&host->lock, flags);
> +
> + config = readl_relaxed(host->ioaddr + CORE_DLL_CONFIG);
> + config &= ~(CORE_CDR_EN | CORE_CK_OUT_EN);
> + config |= (CORE_CDR_EXT_EN | CORE_DLL_EN);
> + writel_relaxed(config, host->ioaddr + CORE_DLL_CONFIG);
> +
> + /* Wait until CK_OUT_EN bit of DLL_CONFIG register becomes '0' */
> + rc = msm_dll_poll_ck_out_en(host, 0);
> + if (rc)
> + goto err_out;
> +
> + /*
> + * Write the selected DLL clock output phase (0 ... 15)
> + * to CDR_SELEXT bit field of DLL_CONFIG register.
> + */
> + writel_relaxed(((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
> + & ~(0xF << 20))
> + | (grey_coded_phase_table[phase] << 20)),
> + host->ioaddr + CORE_DLL_CONFIG);
Wow this is complicated. Can we please break this up into
multiple lines? What does 0xf << 20 mean?
> +
> + /* Set CK_OUT_EN bit of DLL_CONFIG register to 1. */
> + writel_relaxed((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
> + | CORE_CK_OUT_EN), host->ioaddr + CORE_DLL_CONFIG);
> +
[...]
> +}
> +
> +static int msm_find_most_appropriate_phase(struct sdhci_host *host,
> + u8 *phase_table, u8 total_phases)
> +{
[...]
> +
> + for (cnt = 0; cnt <= row_index; cnt++) {
> + if (phases_per_row[cnt] > curr_max) {
> + curr_max = phases_per_row[cnt];
> + selected_row_index = cnt;
> + }
> + }
> +
> + i = ((curr_max * 3) / 4);
Unnecessary extra parentheses here.
> + if (i)
> + i--;
> +
> + ret = (int)ranges[selected_row_index][i];
Is this cast necessary?
> +
> + if (ret >= MAX_PHASES) {
> + ret = -EINVAL;
> + dev_err(mmc_dev(mmc), "%s: invalid phase selected=%d\n",
> + mmc_hostname(mmc), ret);
> + }
> +
> + return ret;
> +}
> +
> +static inline void msm_cm_dll_set_freq(struct sdhci_host *host)
> +{
> + u32 mclk_freq = 0;
> +
> + /* Program the MCLK value to MCLK_FREQ bit field */
> + if (host->clock <= 112000000)
> + mclk_freq = 0;
> + else if (host->clock <= 125000000)
> + mclk_freq = 1;
> + else if (host->clock <= 137000000)
> + mclk_freq = 2;
> + else if (host->clock <= 150000000)
> + mclk_freq = 3;
> + else if (host->clock <= 162000000)
> + mclk_freq = 4;
> + else if (host->clock <= 175000000)
> + mclk_freq = 5;
> + else if (host->clock <= 187000000)
> + mclk_freq = 6;
> + else if (host->clock <= 200000000)
> + mclk_freq = 7;
This could be a case statement but I'm not sure it's any clearer.
At least the range is specified.
switch (host->clock) {
case 0 ... 112000000:
mclk_freq = 0;
break;
case 112000001 ... 125000000:
mclk_freq = 1;
break;
...
> +
> + writel_relaxed(((readl_relaxed(host->ioaddr + CORE_DLL_CONFIG)
> + & ~(7 << 24)) | (mclk_freq << 24)),
> + host->ioaddr + CORE_DLL_CONFIG);
This is also complicated. Can you split this up into multiple lines?
> +int sdhci_msm_execute_tuning(struct sdhci_host *host, u32 opcode)
> +{
[...]
> + do {
> + struct mmc_command cmd = { 0 };
> + struct mmc_data data = { 0 };
> + struct mmc_request mrq = {
> + .cmd = &cmd,
> + .data = &data
> + };
> + struct scatterlist sg;
> +
> + /* set the phase in delay line hw block */
> + rc = msm_config_cm_dll_phase(host, phase);
> + if (rc)
> + goto out;
> +
> + cmd.opcode = opcode;
> + cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
> +
> + data.blksz = size;
> + data.blocks = 1;
> + data.flags = MMC_DATA_READ;
> + data.timeout_ns = 1000 * 1000 * 1000; /* 1 sec */
NSEC_PER_SEC?
> +
> + data.sg = &sg;
> + data.sg_len = 1;
> + sg_init_one(&sg, data_buf, sizeof(data_buf));
> + memset(data_buf, 0, sizeof(data_buf));
> + mmc_wait_for_req(mmc, &mrq);
> +
> + if (!cmd.error && !data.error &&
> + !memcmp(data_buf, tuning_block_pattern, sizeof(data_buf))) {
> + /* tuning is successful at this tuning point */
> + tuned_phases[tuned_phase_cnt++] = phase;
> + dev_dbg(mmc_dev(mmc), "%s: found good phase = %d\n",
> + mmc_hostname(mmc), phase);
> + }
> + } while (++phase < 16);
++phase < ARRAY_SIZE(tuned_phases) ?
> +
> + if (tuned_phase_cnt) {
> + rc = msm_find_most_appropriate_phase(host, tuned_phases,
> + tuned_phase_cnt);
> + if (rc < 0)
> + goto out;
> + else
> + phase = (u8) rc;
Unnecessary cast?
> +
> + /*
> + * Finally set the selected phase in delay
> + * line hw block.
> + */
> + rc = msm_config_cm_dll_phase(host, phase);
> + if (rc)
> + goto out;
> + dev_dbg(mmc_dev(mmc), "%s: setting the tuning phase to %d\n",
> + mmc_hostname(mmc), phase);
> + } else {
> + if (--tuning_seq_cnt)
> + goto retry;
> + /* tuning failed */
> + dev_dbg(mmc_dev(mmc), "%s: no tuning point found\n",
> + mmc_hostname(mmc));
> + rc = -EIO;
> + }
> +
> +out:
> + kfree(data_buf);
> + return rc;
> +}
> +
> #define MAX_PROP_SIZE 32
> static int sdhci_msm_dt_parse_vreg_info(struct device *dev,
> struct sdhci_msm_reg_data *vreg, const char *vreg_name)
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH] ARM: dts: qcom: Add RNG device tree node
From: Stephen Boyd @ 2014-02-08 3:37 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: devicetree, linux-arm-kernel, linux-arm-msm, Kumar Gala,
Mark Rutland, Rob Herring, Pawel Moll, Ian Campbell, David Brown
In-Reply-To: <1391764987-17138-1-git-send-email-svarbanov@mm-sol.com>
On 02/07, Stanimir Varbanov wrote:
> Add the necessary DT node to probe the rng driver on
> msm8974 platforms.
>
Looks good. We should add it to msm8960-cdp and enable the driver
in the defconfig as well.
> Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH v2] ARM: sunxi: Add driver for sunxi usb phy
From: Chen-Yu Tsai @ 2014-02-08 4:32 UTC (permalink / raw)
To: linux-sunxi
Cc: Kishon Vijay Abraham I, Maxime Ripard, linux-arm-kernel,
devicetree, Hans de Goede
In-Reply-To: <1391790801-27864-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sat, Feb 8, 2014 at 12:33 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
> through a single set of registers. Besides this there are also some other
> phy related bits which need poking, which are per phy, but shared between the
> ohci and ehci controllers, so these are also controlled from this new phy
> driver.
>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/phy/sun4i-usb-phy.txt | 28 ++
> drivers/phy/Kconfig | 11 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-sun4i-usb.c | 326 +++++++++++++++++++++
> 4 files changed, 366 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> create mode 100644 drivers/phy/phy-sun4i-usb.c
>
[...]
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> new file mode 100644
> index 0000000..bd9cb7fa
> --- /dev/null
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -0,0 +1,326 @@
> +/*
> + * Allwinner sun4i USB phy driver
> + *
> + * Copyright (C) 2014 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> + *
> + * Based on code from
> + * Allwinner Technology Co., Ltd. <www.allwinnertech.com>
> + *
> + * Modelled after: Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Author: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@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 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/clk.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
> +
> +#define REG_ISCR 0x00
> +#define REG_PHYCTL 0x04
> +#define REG_PHYBIST 0x08
> +#define REG_PHYTUNE 0x0c
> +
> +#define SUNXI_AHB_ICHR8_EN BIT(10)
> +#define SUNXI_AHB_INCR4_BURST_EN BIT(9)
> +#define SUNXI_AHB_INCRX_ALIGN_EN BIT(8)
> +#define SUNXI_ULPI_BYPASS_EN BIT(0)
> +
> +/* Common Control Bits for Both PHYs */
> +#define PHY_PLL_BW 0x03
> +#define PHY_RES45_CAL_EN 0x0c
> +
> +/* Private Control Bits for Each PHY */
> +#define PHY_TX_AMPLITUDE_TUNE 0x20
> +#define PHY_TX_SLEWRATE_TUNE 0x22
> +#define PHY_VBUSVALID_TH_SEL 0x25
> +#define PHY_PULLUP_RES_SEL 0x27
> +#define PHY_OTG_FUNC_EN 0x28
> +#define PHY_VBUS_DET_EN 0x29
> +#define PHY_DISCON_TH_SEL 0x2a
> +
> +#define MAX_PHYS 3
> +
> +struct sun4i_usb_phy_data {
> + struct clk *clk;
> + void __iomem *base;
> + struct mutex mutex;
> + int num_phys;
> + u32 disc_thresh;
> + struct sun4i_usb_phy {
> + struct phy *phy;
> + void __iomem *pmu;
> + struct regulator *vbus;
> + struct reset_control *reset;
> + int index;
> + } phys[MAX_PHYS];
> +};
> +
> +#define to_sun4i_usb_phy_data(phy) \
> + container_of((phy), struct sun4i_usb_phy_data, phys[(phy)->index])
> +
> +static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, u32 addr, u32 data,
> + int len)
> +{
> + struct sun4i_usb_phy_data *phy_data = to_sun4i_usb_phy_data(phy);
> + u32 temp, usbc_bit = BIT(phy->index * 2);
> + int i;
> +
> + mutex_lock(&phy_data->mutex);
> +
> + for (i = 0; i < len; i++) {
> + temp = readl(phy_data->base + REG_PHYCTL);
> +
> + /* clear the address portion */
> + temp &= ~(0xff << 8);
> +
> + /* set the address */
> + temp |= ((addr + i) << 8);
> + writel(temp, phy_data->base + REG_PHYCTL);
> +
> + /* set the data bit and clear usbc bit*/
> + temp = readb(phy_data->base + REG_PHYCTL);
> + if (data & 0x1)
> + temp |= BIT(7);
> + else
> + temp &= ~BIT(7);
> + temp &= ~usbc_bit;
> + writeb(temp, phy_data->base + REG_PHYCTL);
> +
> + /* pulse usbc_bit */
> + temp = readb(phy_data->base + REG_PHYCTL);
> + temp |= usbc_bit;
> + writeb(temp, phy_data->base + REG_PHYCTL);
> +
> + temp = readb(phy_data->base + REG_PHYCTL);
> + temp &= ~usbc_bit;
> + writeb(temp, phy_data->base + REG_PHYCTL);
> +
> + data >>= 1;
> + }
> + mutex_unlock(&phy_data->mutex);
> +}
> +
> +static void sun4i_usb_phy_passby(struct sun4i_usb_phy *phy, int enable)
> +{
> + u32 bits, reg_value;
> +
> + if (!phy->pmu)
> + return;
> +
> + bits = SUNXI_AHB_ICHR8_EN | SUNXI_AHB_INCR4_BURST_EN |
> + SUNXI_AHB_INCRX_ALIGN_EN | SUNXI_ULPI_BYPASS_EN;
> +
> + reg_value = readl(phy->pmu);
> +
> + if (enable)
> + reg_value |= bits;
> + else
> + reg_value &= ~bits;
> +
> + writel(reg_value, phy->pmu);
> +}
> +
> +static int sun4i_usb_phy_init(struct phy *_phy)
> +{
> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> + struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
> + int ret;
> +
> + ret = clk_prepare_enable(data->clk);
> + if (ret)
> + return ret;
> +
> + ret = reset_control_deassert(phy->reset);
> + if (ret) {
> + clk_disable_unprepare(data->clk);
> + return ret;
> + }
> +
> + /* Adjust PHY's magnitude and rate */
> + sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> +
> + /* Disconnect threshold adjustment */
> + sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL, data->disc_thresh, 2);
> +
> + sun4i_usb_phy_passby(phy, 1);
> +
> + return 0;
> +}
> +
> +static int sun4i_usb_phy_exit(struct phy *_phy)
> +{
> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> + struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
> +
> + sun4i_usb_phy_passby(phy, 0);
> + reset_control_assert(phy->reset);
> + clk_disable_unprepare(data->clk);
> +
> + return 0;
> +}
> +
> +static int sun4i_usb_phy_power_on(struct phy *_phy)
> +{
> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> + int ret = 0;
> +
> + if (phy->vbus)
> + ret = regulator_enable(phy->vbus);
> +
> + return ret;
> +}
> +
> +static int sun4i_usb_phy_power_off(struct phy *_phy)
> +{
> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> +
> + if (phy->vbus)
> + regulator_disable(phy->vbus);
> +
> + return 0;
> +}
> +
> +static struct phy_ops sun4i_usb_phy_ops = {
> + .init = sun4i_usb_phy_init,
> + .exit = sun4i_usb_phy_exit,
> + .power_on = sun4i_usb_phy_power_on,
> + .power_off = sun4i_usb_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static struct phy *sun4i_usb_phy_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct sun4i_usb_phy_data *data = dev_get_drvdata(dev);
> +
> + if (WARN_ON(args->args[0] == 0 || args->args[0] >= data->num_phys))
> + return ERR_PTR(-ENODEV);
> +
> + return data->phys[args->args[0]].phy;
> +}
> +
> +static int sun4i_usb_phy_probe(struct platform_device *pdev)
> +{
> + struct sun4i_usb_phy_data *data;
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + void __iomem *pmu = NULL;
> + struct phy_provider *phy_provider;
> + struct reset_control *reset;
> + struct regulator *vbus;
> + struct phy *phy;
> + char name[16];
> + int i;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + mutex_init(&data->mutex);
> +
> + if (of_device_is_compatible(np, "allwinner,sun5i-a13-usb-phy"))
> + data->num_phys = 2;
> + else
> + data->num_phys = 3;
> +
> + if (of_device_is_compatible(np, "allwinner,sun4i-a10-usb-phy"))
> + data->disc_thresh = 3;
> + else
> + data->disc_thresh = 2;
> +
> + data->clk = devm_clk_get(dev, "usb_phy");
> + if (IS_ERR(data->clk)) {
> + dev_err(dev, "could not get usb_phy clock\n");
> + return PTR_ERR(data->clk);
> + }
> +
> + /* Skip 0, 0 is the phy for otg which is not yet supported. */
> + for (i = 1; i < data->num_phys; i++) {
> + snprintf(name, sizeof(name), "usb%d_vbus", i);
> + vbus = devm_regulator_get_optional(dev, name);
> + if (IS_ERR(vbus)) {
> + if (PTR_ERR(vbus) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + vbus = NULL;
> + }
> +
> + snprintf(name, sizeof(name), "usb%d_reset", i);
> + reset = devm_reset_control_get(dev, name);
> + if (IS_ERR(phy)) {
> + dev_err(dev, "failed to get reset %s\n", name);
> + return PTR_ERR(phy);
> + }
Wrong variable checked for error here that I pointed out before is still wrong.
Cheers
ChenYu
> +
> + if (i) { /* No pmu for usbc0 */
> + pmu = devm_ioremap_resource(dev,
> + platform_get_resource(pdev, IORESOURCE_MEM, i));
> + if (IS_ERR(pmu))
> + return PTR_ERR(pmu);
> + }
> +
> + phy = devm_phy_create(dev, &sun4i_usb_phy_ops, NULL);
> + if (IS_ERR(phy)) {
> + dev_err(dev, "failed to create PHY %d\n", i);
> + return PTR_ERR(phy);
> + }
> +
> + data->phys[i].phy = phy;
> + data->phys[i].pmu = pmu;
> + data->phys[i].vbus = vbus;
> + data->phys[i].reset = reset;
> + data->phys[i].index = i;
> + phy_set_drvdata(phy, &data->phys[i]);
> + }
> +
> + data->base = devm_ioremap_resource(dev,
> + platform_get_resource(pdev, IORESOURCE_MEM, 0));
> + if (IS_ERR(data->base))
> + return PTR_ERR(data->base);
> +
> + dev_set_drvdata(dev, data);
> + phy_provider = devm_of_phy_provider_register(dev, sun4i_usb_phy_xlate);
> + if (IS_ERR(phy_provider))
> + return PTR_ERR(phy_provider);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id sun4i_usb_phy_of_match[] = {
> + { .compatible = "allwinner,sun4i-a10-usb-phy" },
> + { .compatible = "allwinner,sun5i-a13-usb-phy" },
> + { .compatible = "allwinner,sun7i-a20-usb-phy" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
> +
> +static struct platform_driver sun4i_usb_phy_driver = {
> + .probe = sun4i_usb_phy_probe,
> + .driver = {
> + .of_match_table = sun4i_usb_phy_of_match,
> + .name = "sun4i-usb-phy",
> + .owner = THIS_MODULE,
> + }
> +};
> +module_platform_driver(sun4i_usb_phy_driver);
> +
> +MODULE_DESCRIPTION("Allwinner sun4i USB phy driver");
> +MODULE_AUTHOR("Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>");
> +MODULE_LICENSE("GPL v2");
> --
> 1.8.4.2
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH v2 1/2] PM / OPP: Allow boost frequency to be looked up from device tree
From: Thomas Abraham @ 2014-02-08 5:10 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
linux-samsung-soc@vger.kernel.org, kgene.kim@samsung.com,
t.figa@samsung.com, l.majewski@samsung.com,
viresh.kumar@linaro.org, thomas.ab@samsung.com, Nishanth Menon
In-Reply-To: <52F50346.7040707@arm.com>
On Fri, Feb 7, 2014 at 9:31 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 15:19, Thomas Abraham wrote:
>> From: Thomas Abraham <thomas.ab@samsung.com>
>>
>> Commit 6f19efc0 ("cpufreq: Add boost frequency support in core") adds
>> support for CPU boost mode. This patch adds support for finding available
>> boost frequencies from device tree and marking them as usable in boost mode.
>>
>> Cc: Nishanth Menon <nm@ti.com>
>> Cc: Lukasz Majewski <l.majewski@samsung.com>
>> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
>> ---
>> drivers/base/power/opp.c | 34 +++++++++++++++++++++++++++++++++-
>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
>> index fa41874..b636826 100644
>> --- a/drivers/base/power/opp.c
>> +++ b/drivers/base/power/opp.c
>> @@ -628,7 +628,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>> struct device_opp *dev_opp;
>> struct dev_pm_opp *opp;
>> struct cpufreq_frequency_table *freq_table;
>> - int i = 0;
>> + int i = 0, j, len, ret;
>> + u32 *boost_freqs = NULL;
>>
>> /* Pretend as if I am an updater */
>> mutex_lock(&dev_opp_list_lock);
>> @@ -650,10 +651,35 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
>> return -ENOMEM;
>> }
>>
>> + if (of_find_property(dev->of_node, "boost-frequency", &len)) {
>> + if (len == 0 || (len & (sizeof(u32) - 1)) != 0) {
>> + dev_err(dev, "%s: invalid boost frequency\n", __func__);
>> + ret = -EINVAL;
>> + goto err_boost;
>> + }
>> +
>> + boost_freqs = kzalloc(len, GFP_KERNEL);
>> + if (!boost_freqs) {
>> + dev_warn(dev, "%s: no memory for boost freq table\n",
>> + __func__);
>> + ret = -ENOMEM;
>> + goto err_boost;
>> + }
>> + of_property_read_u32_array(dev->of_node, "boost-frequency",
>> + boost_freqs, len / sizeof(u32));
>> + }
>> +
>> list_for_each_entry(opp, &dev_opp->opp_list, node) {
>> if (opp->available) {
>> freq_table[i].driver_data = i;
>> freq_table[i].frequency = opp->rate / 1000;
>> + for (j = 0; j < len / sizeof(u32) && boost_freqs; j++) {
>> + if (boost_freqs[j] == freq_table[i].frequency) {
>> + freq_table[i].driver_data =
>> + CPUFREQ_BOOST_FREQ;
>> + break;
>> + }
>> + }
>> i++;
>> }
>> }
> IIRC you had mentioned that the boost-opp was not limited to be a cpufreq, but
> this change seems to be cpufreq only.
Yes, but as you have initiated the discussion on extending the OPP
binding, this has been limited to cpufreq only. If the new OPP library
has support for listing boost frequency, this can be migrated to the
new OPP libaray.
Thanks,
Thomas.
>
> Regards,
> Sudeep
>
^ permalink raw reply
* Re: [PATCH] net: rfkill-regulator: Add devicetree support.
From: Bill Fink @ 2014-02-08 6:22 UTC (permalink / raw)
To: Marek Belisko
Cc: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, rob,
linville, johannes, davem, grant.likely, neilb, hns, devicetree,
linux-doc, linux-kernel, linux-wireless, netdev
In-Reply-To: <1391802529-29861-1-git-send-email-marek@goldelico.com>
On Fri, 7 Feb 2014, Marek Belisko wrote:
> Signed-off-by: NeilBrown <neilb@suse.de>
> Signed-off-by: Marek Belisko <marek@goldelico.com>
> ---
> Based on Neil's patch and extend for documentation and bindings include.
>
> .../bindings/net/rfkill/rfkill-relugator.txt | 28 ++++++++++++++++
^^^^^^^^^
Typo in file name.
-Bill
> include/dt-bindings/net/rfkill-regulator.h | 23 +++++++++++++
> net/rfkill/rfkill-regulator.c | 38 ++++++++++++++++++++++
> 3 files changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> create mode 100644 include/dt-bindings/net/rfkill-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> new file mode 100644
> index 0000000..cdb7dd7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
> @@ -0,0 +1,28 @@
> +Regulator consumer for rfkill devices
> +
> +Required properties:
> +- compatible : Must be "rfkill-regulator".
> +- label : Name of rfkill device.
> +- type : Type of rfkill device.
> +
> +Possible values (defined in include/dt-bindings/net/rfkill-regulator.h):
> + RFKILL_TYPE_ALL
> + RFKILL_TYPE_WLAN
> + RFKILL_TYPE_BLUETOOTH
> + RFKILL_TYPE_UWB
> + RFKILL_TYPE_WIMAX
> + RFKILL_TYPE_WWAN
> + RFKILL_TYPE_GPS
> + RFKILL_TYPE_FM
> + RFKILL_TYPE_NFC
> +
> +- vrfkill-supply - regulator device.
> +
> +Example:
> + gps-rfkill {
> + compatible = "rfkill-regulator";
> + label = "GPS";
> + type = <RFKILL_TYPE_GPS>;
> + vrfkill-supply = <®>;
> + };
> +
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Thomas Abraham @ 2014-02-08 6:47 UTC (permalink / raw)
To: Sudeep Holla
Cc: Nishanth Menon, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@rjwysocki.net, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, t.figa@samsung.com, l.majewski@samsung.com,
viresh.kumar@linaro.org, thomas.ab@samsung.com, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
In-Reply-To: <52F51FCD.5000009@arm.com>
On Fri, Feb 7, 2014 at 11:32 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
> On 07/02/14 17:37, Nishanth Menon wrote:
>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>
> [...]
>
>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>> frequencies and the boost parameters are exposed through sysfs)
>>
>> That will be a different problem -> as currently every single
>> frequency in the cpufreq list has ability to be marked as boost
>> frequency - if userspace does not maintain that, then, IMHO, fix the
>> userspace :D
>>
>
> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
> the list of frequencies based on the state of the boost feature at anytime.
The list of frequencies in
/sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies
does not change based in the state of the boost feature (enabled or
disabled). But the scaling_max_frequency and scaling_min_frequency are
updated based on the set of available + boost frequencies available.
>
> Intuitively the list without boost shouldn't have any frequency above the range
> when it's enabled :), that's what I was referring to. So I am not talking about
> any issue with user-space maintenance.
>
> Regards,
> Sudeep
>
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: devicetree: Add boost-frequency binding to list boost mode frequency
From: Thomas Abraham @ 2014-02-08 6:47 UTC (permalink / raw)
To: Nishanth Menon
Cc: Sudeep Holla, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@rjwysocki.net, linux-samsung-soc@vger.kernel.org,
kgene.kim@samsung.com, t.figa@samsung.com, l.majewski@samsung.com,
viresh.kumar@linaro.org, thomas.ab@samsung.com, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala
In-Reply-To: <CAGo_u6quxExJOyY8mvCw5sDSuz=_j0YqJ6FJW+FAdaxUeqzN9Q@mail.gmail.com>
On Sat, Feb 8, 2014 at 1:11 AM, Nishanth Menon <nm@ti.com> wrote:
> On Fri, Feb 7, 2014 at 12:02 PM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>> On 07/02/14 17:37, Nishanth Menon wrote:
>>> On Fri, Feb 7, 2014 at 11:31 AM, Sudeep Holla <Sudeep.Holla@arm.com> wrote:
>>
>> [...]
>>
>>>> Yes I think its counter-intuitive as it's visible to the userspace(list of
>>>> frequencies and the boost parameters are exposed through sysfs)
>>>
>>> That will be a different problem -> as currently every single
>>> frequency in the cpufreq list has ability to be marked as boost
>>> frequency - if userspace does not maintain that, then, IMHO, fix the
>>> userspace :D
>>>
>>
>> /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies gives
>> the list of frequencies based on the state of the boost feature at anytime.
>>
>> Intuitively the list without boost shouldn't have any frequency above the range
>> when it's enabled :), that's what I was referring to. So I am not talking about
>> any issue with user-space maintenance.
> Fair enough - but i still think it has nothing to do with dt binding
> itself -> and i think the discussion we've had should be good for the
> binding provided in this patch.. I hope.. if documentation needs a bit
> of better explanation to prevent a repeat of the same discussion at a
> later point of time, now might be a good time to add it in.
The term boost and over-clocking have been described in the bindings
document as being the same. Since the term over-clocking refers to
running a CPU beyond normal operating frequencies, I tend to agree
with Sudeep that it is not intuitive if a normal operating frequency
is greater than a boost mode frequency.
Otherwise, when userspace does "echo 1 >
/sys/devices/system/cpu/cpufreq/boost", what is it supposed to mean. I
think the original intent of boost mode patches was to allow CPU to
operate at frequencies greater than the normal operating frequencies.
Lukasz, how would you want this to be handled?
Thanks,
Thomas.
>
> Regards,
> Nishanth Menon
^ permalink raw reply
* Re: [PATCH 1/3] sound: soc: codecs: Add es8328 codec
From: Sean Cross @ 2014-02-08 8:10 UTC (permalink / raw)
To: Mark Brown; +Cc: devicetree, alsa-devel, Shawn Guo, Liam Girdwood, Sascha Hauer
In-Reply-To: <20140207181238.GL1757@sirena.org.uk>
On 8/2/14 2:12 AM, Mark Brown wrote:
> On Fri, Feb 07, 2014 at 01:05:15PM +0800, Sean Cross wrote:
>
> Please use subject likes matching the style for the subsystem. If your
> changelog looks different to others in the same area it probably needs
> an update.
>
> In general this looks like it should be making much more use of the
> framework rather than open coding, it looks like it's very much hard
> coded for one use cae.
Alright, I'll try to use more of the framework provided. I tried to use
one of the Wolfson codecs as an example. Is there a "canonical" driver
that's up-to-date and uses an appreciable amount of framework?
>
>> +config SND_SOC_ES8328
>> + tristate
>> +
>
> It looks like you're going to use this on an ARM system, you should add
> DT support and make it visible in Kconfig.
>
>> +static const struct snd_soc_dapm_widget es8328_dapm_widgets[] = {
>> + SND_SOC_DAPM_DAC("Speaker Volume", "HiFi Playback",
SND_SOC_NOPM, 0, 0),
>
> Don't declare a stream by name, use DAPM routes to connect the stream to
> the widget.
Where can I read up on DAPM routes? I don't see the word "route"
mentioned in the dapm.txt SoC documentation.
>
>> + SND_SOC_DAPM_OUTPUT("VOUTL"),
>> + SND_SOC_DAPM_OUTPUT("VOUTR"),
>> + SND_SOC_DAPM_INPUT("LINE_IN"),
>> + SND_SOC_DAPM_INPUT("MIC_IN"),
>> + SND_SOC_DAPM_OUTPUT("HP_OUT"),
>> + SND_SOC_DAPM_OUTPUT("SPK_OUT"),
>
> Something is messed up with your indentation, spaces vs tabs I expect.
Sloppy. I'll fix this in the next revision.
>
>> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
>> +
>> + if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) {
>
> An else clause is more idiomatic here.
>
>> + snd_soc_write(codec, ES8328_ADCCONTROL5, adc);
>
> It's more idiomatic to use update_bits() here and save doing a manual
> read/modify/write cycle - it also avoids the write if not needed.
>
>> +static int es8328_adc_enable(struct snd_soc_codec *codec)
>> +{
>> + u16 reg = snd_soc_read(codec, ES8328_CHIPPOWER);
>> + reg &= ~(ES8328_CHIPPOWER_ADCVREF_OFF |
>> + ES8328_CHIPPOWER_ADCPLL_OFF |
>> + ES8328_CHIPPOWER_ADCSTM_RESET |
>> + ES8328_CHIPPOWER_ADCDIG_OFF);
>> + snd_soc_write(codec, ES8328_CHIPPOWER, reg);
>
> This looks like it should be done in DAPM.
The codec has very strict power sequencing. If I'm understanding the
document correctly, I'd add a DAPM widget for the DAC, and then register
a widget event for when the DAC gets opened, and do power sequencing
there? Or is there a way to have multiple register writes defined as a
single DAPM widget?
>> +
>> + /* Set up microphone to be differential input */
>> + snd_soc_write(codec, ES8328_ADCCONTROL2, 0xf0);
>
> This looks like something that should be platform data and/or DAPM -
> other platforms may be wired differently.
>
>> + /* Set ADC to act as I2S master */
>> + snd_soc_write(codec, ES8328_ADCCONTROL3, 0x02);
>
> set_dai_fmt().
>
>> + /* Set I2S to 16-bit mode */
>> + snd_soc_write(codec, ES8328_ADCCONTROL4, 0x18);
>
> This should be being done in hw_params.
>> + /* Frequency clock of 272 */
>> + snd_soc_write(codec, ES8328_ADCCONTROL5, 0x02);
>
> What is the frequency clock in this context?
The frequency is a specific divider defined in the datasheet. There is
a table of frequencies and dividers for various frequencies. One option
is to code this table into the driver and pick the frequency clocks out
of the table.
I decided to assume the codec has a fixed input frequency of 22.5792
MHz. This means the codec can support 11.025, 22.05, and 44.1 kHz, but
cannot support 48 kHz. It should be possible to instead feed the codec
a 24 MHz clock and run it at 48 kHz. Pulseaudio runs at 44.1 by
default, so I went with that.
>
>> + /* Power up LOUT2 ROUT2, and power down xOUT1 */
>> + snd_soc_write(codec, ES8328_DACPOWER,
>> + ES8328_DACPOWER_ROUT2_ON |
>> + ES8328_DACPOWER_LOUT2_ON);
>
> This looks like it should be being done in DAPM.
>
>> + /* Enable click-free power up */
>> + snd_soc_write(codec, ES8328_DACCONTROL6,
ES8328_DACCONTROL6_CLICKFREE);
>> + snd_soc_write(codec, ES8328_DACCONTROL3, 0x36);
>
> Just do this once on startup?
Correct.
>
>> + /* Set I2S to 16-bit mode */
>> + snd_soc_write(codec, ES8328_DACCONTROL1,
ES8328_DACCONTROL1_DACWL_16);
>
> hw_params().
>
>> + /* No attenuation */
>> + snd_soc_write(codec, ES8328_DACCONTROL4, 0x00);
>> + snd_soc_write(codec, ES8328_DACCONTROL5, 0x00);
>
> This and the rest of the function looks like it should be done in a
> combination of DAPM and normal ALSA controls.
>
>> + for (i = 0; i < 4; i++)
>> + snd_soc_write(codec, i + ES8328_DACCONTROL24, old_volumes[i]);
>
> You are probably looking for something like SOC_DAPM_SINGLE_AUTODISABLE.
>
>> +static const struct snd_soc_dai_ops es8328_dai_ops = {
>> + .hw_params = es8328_hw_params,
>> + .prepare = es8328_pcm_prepare,
>> + .shutdown = es8328_pcm_shutdown,
>> +// .digital_mute = es8328_mute,
>
> Hrm?
Oops. Leftover from some anti-pop work I did earlier. I'll remove it.
>
>> +static const struct of_device_id es8328_of_match[] = {
>> + { .compatible = "everest,es8328", },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, es8328_of_match);
>
> Any device tree device needs a binding document.
My fault for omitting one.
Much of the code in adc_enable() and dac_enable() come from the
reference manual. They indicate that the codec has very strict ordering
requirements on registers that must be set during playback and
recording. Again, is there any way to ensure that hw_params(),
set_dai_fmt(), and the DAPM widgets are called in a specific order?
Thank you for the feedback.
Sean
^ permalink raw reply
* Re: [PATCH 1/3] sound: soc: codecs: Add es8328 codec
From: Sean Cross @ 2014-02-08 8:17 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Shawn Guo, Sascha Hauer,
Liam Girdwood
In-Reply-To: <20140207181238.GL1757-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On 8/2/14 2:12 AM, Mark Brown wrote:
> On Fri, Feb 07, 2014 at 01:05:15PM +0800, Sean Cross wrote:
>
> Please use subject likes matching the style for the subsystem. If
> your changelog looks different to others in the same area it
> probably needs an update.
>
> In general this looks like it should be making much more use of
> the framework rather than open coding, it looks like it's very much
> hard coded for one use cae.
Alright, I'll try to use more of the framework provided. I tried to
use one of the Wolfson codecs as an example. Is there a "canonical"
driver that's up-to-date and uses an appreciable amount of framework?
>> +config SND_SOC_ES8328 + tristate +
>
> It looks like you're going to use this on an ARM system, you should
> add DT support and make it visible in Kconfig.
>
>> +static const struct snd_soc_dapm_widget es8328_dapm_widgets[] =
>> { + SND_SOC_DAPM_DAC("Speaker Volume", "HiFi Playback",
>> SND_SOC_NOPM, 0, 0),
>
> Don't declare a stream by name, use DAPM routes to connect the
> stream to the widget.
Where can I read up on DAPM routes? I don't see the word "route"
mentioned in the dapm.txt SoC documentation.
>> + SND_SOC_DAPM_OUTPUT("VOUTL"), + SND_SOC_DAPM_OUTPUT("VOUTR"), +
>> SND_SOC_DAPM_INPUT("LINE_IN"), +
>> SND_SOC_DAPM_INPUT("MIC_IN"), +
>> SND_SOC_DAPM_OUTPUT("HP_OUT"), +
>> SND_SOC_DAPM_OUTPUT("SPK_OUT"),
>
> Something is messed up with your indentation, spaces vs tabs I
> expect.
Sloppy. I'll fix this in the next revision.
Also, this is hard-coding widgets for this platform. In reality,
there's an output LOUT1, ROUT1, LOUT2, ROUT2, in addition to LDAC and
RDAC. The DAC outputs to both OUT1 and OUT2. I feel this is the sort
of thing DAPM was designed to accommodate.
How can I specify LOUT1 etc., and how can I define the mapping of
outputs on my particular platform? E.g. OUT2 goes to the Headset on
this board.
>> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + + if
>> (substream->stream == SNDRV_PCM_STREAM_CAPTURE) {
>
> An else clause is more idiomatic here.
>
>> + snd_soc_write(codec, ES8328_ADCCONTROL5, adc);
>
> It's more idiomatic to use update_bits() here and save doing a
> manual read/modify/write cycle - it also avoids the write if not
> needed.
That makes sense.
>> +static int es8328_adc_enable(struct snd_soc_codec *codec) +{ +
>> u16 reg = snd_soc_read(codec, ES8328_CHIPPOWER); + reg &=
>> ~(ES8328_CHIPPOWER_ADCVREF_OFF | + ES8328_CHIPPOWER_ADCPLL_OFF
>> | + ES8328_CHIPPOWER_ADCSTM_RESET | +
>> ES8328_CHIPPOWER_ADCDIG_OFF); + snd_soc_write(codec,
>> ES8328_CHIPPOWER, reg);
>
> This looks like it should be done in DAPM.
The codec has very strict power sequencing. If I'm understanding the
document correctly, I'd add a DAPM widget for the DAC, and then
register a widget event for when the DAC gets opened, and do power
sequencing there? Or is there a way to have multiple register writes
defined as a single DAPM widget?
>> + + /* Set up microphone to be differential input */ +
>> snd_soc_write(codec, ES8328_ADCCONTROL2, 0xf0);
>
> This looks like something that should be platform data and/or DAPM
> - other platforms may be wired differently.
>
>> + /* Set ADC to act as I2S master */ + snd_soc_write(codec,
>> ES8328_ADCCONTROL3, 0x02);
>
> set_dai_fmt().
>
>> + /* Set I2S to 16-bit mode */ + snd_soc_write(codec,
>> ES8328_ADCCONTROL4, 0x18);
>
> This should be being done in hw_params.
>
>> + /* Frequency clock of 272 */ + snd_soc_write(codec,
>> ES8328_ADCCONTROL5, 0x02);
>
> What is the frequency clock in this context?
The frequency is a specific divider defined in the datasheet. There
is a table of frequencies and dividers for various frequencies. One
option is to code this table into the driver and pick the frequency
clocks out of the table.
I decided to assume the codec has a fixed input frequency of 22.5792
MHz. This means the codec can support 11.025, 22.05, and 44.1 kHz,
but cannot support 48 kHz. It should be possible to instead feed the
codec a 24 MHz clock and run it at 48 kHz. Pulseaudio runs at 44.1 by
default, so I went with that.
>> + /* Power up LOUT2 ROUT2, and power down xOUT1 */ +
>> snd_soc_write(codec, ES8328_DACPOWER, +
>> ES8328_DACPOWER_ROUT2_ON | + ES8328_DACPOWER_LOUT2_ON);
>
> This looks like it should be being done in DAPM.
>
>> + /* Enable click-free power up */ + snd_soc_write(codec,
>> ES8328_DACCONTROL6, ES8328_DACCONTROL6_CLICKFREE); +
>> snd_soc_write(codec, ES8328_DACCONTROL3, 0x36);
>
> Just do this once on startup?
Correct.
>> + /* Set I2S to 16-bit mode */ + snd_soc_write(codec,
>> ES8328_DACCONTROL1, ES8328_DACCONTROL1_DACWL_16);
>
> hw_params().
>
>> + /* No attenuation */ + snd_soc_write(codec, ES8328_DACCONTROL4,
>> 0x00); + snd_soc_write(codec, ES8328_DACCONTROL5, 0x00);
>
> This and the rest of the function looks like it should be done in
> a combination of DAPM and normal ALSA controls.
>
>> + for (i = 0; i < 4; i++) + snd_soc_write(codec, i +
>> ES8328_DACCONTROL24, old_volumes[i]);
>
> You are probably looking for something like
> SOC_DAPM_SINGLE_AUTODISABLE.
>
>> +static const struct snd_soc_dai_ops es8328_dai_ops = { +
>> .hw_params = es8328_hw_params, + .prepare = es8328_pcm_prepare, +
>> .shutdown = es8328_pcm_shutdown, +// .digital_mute =
>> es8328_mute,
>
> Hrm?
Oops. Leftover from some anti-pop work I did earlier. I'll remove it.
>> +static const struct of_device_id es8328_of_match[] = { + {
>> .compatible = "everest,es8328", }, + { } +};
>> +MODULE_DEVICE_TABLE(of, es8328_of_match);
>
> Any device tree device needs a binding document.
>
My fault for omitting one.
Much of the code in adc_enable() and dac_enable() come from the
reference manual. They indicate that the codec has very strict
ordering requirements on registers that must be set during playback
and recording. Again, is there any way to ensure that hw_params(),
set_dai_fmt(), and the DAPM widgets are called in a specific order?
Thank you for the feedback.
Sean
--
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] sound: soc: fsl: Add support for Novena onboard audio
From: Sean Cross @ 2014-02-08 8:27 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Shawn Guo, Sascha Hauer,
Liam Girdwood
In-Reply-To: <20140207181433.GM1757-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On 8/2/14 2:14 AM, Mark Brown wrote:
> On Fri, Feb 07, 2014 at 01:05:16PM +0800, Sean Cross wrote:
>> Novena uses an ES8328 audio codec connected via I2S.
>
> The CODEC looked pretty simple, can this use simple-card?
I had never heard of simple-card. It doesn't look like it supports
device tree. Novena doesn't have a platform definition, and we run
entirely using DT. If simple-card can work without a platform
definition, then we can use it. Otherwise, it's nearly identical to
imx-sgtl5000.c, with the exception of the code you called out.
>> + /* Headphone jack detection */ + if
>> (gpio_is_valid(data->jack_gpio)) { + ret =
>> snd_soc_jack_new(rtd->codec, "Headset", +
>> SND_JACK_HEADSET | SND_JACK_BTN_0, + &headset_jack); +
>> if (ret) + return ret; + + headset_jack_gpios[0].gpio =
>> data->jack_gpio; + ret = snd_soc_jack_add_gpios(&headset_jack, +
>> ARRAY_SIZE(headset_jack_gpios), + headset_jack_gpios); +
>> }
>
> We'd need to add support for this but that shouldn't be too hard.
It does seem simple. I could imagine specifying the jack in a device
tree file, and mapping it to a GPIO.
Can you think of why this would oops on removal? If I disable
headphone jack detection (by simply making data->jack_gpio an invalid
gpio), the module removes cleanly.
>> +static int imx_set_frequency(struct imx_novena_data *data, int
>> freq) { + int ret; + + ret = clk_set_parent(data->system_cko,
>> data->codec_clk); + if (ret) { + dev_err(data->dev, "unable to
>> set clk output"); + return ret; + } + + ret =
>> clk_set_parent(data->codec_clk_sel, data->codec_clk_post_div); +
>> if (ret) { + dev_err(data->dev, "unable to set clk parent"); +
>> return ret; + }
>
> There's supposed to be support for this sort of thing going into
> the clock API with some sort of generic binding.
Can you direct me to this patch? Is it supposed to be defined in the
device tree file? As of right now, the clock is hardcoded to 24 MHz
in clk-imx6q.c, which is why we need to change it here.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] usage-model.txt: fix a typo
From: Laszlo Papp @ 2014-02-08 8:50 UTC (permalink / raw)
To: grant.likely, rob; +Cc: devicetree, linux-doc, linux-kernel, Laszlo Papp
Signed-off-by: Laszlo Papp <lpapp@kde.org>
---
Documentation/devicetree/usage-model.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/usage-model.txt b/Documentation/devicetree/usage-model.txt
index 2b6b3d3..cd2eae5 100644
--- a/Documentation/devicetree/usage-model.txt
+++ b/Documentation/devicetree/usage-model.txt
@@ -123,7 +123,7 @@ successor, the BeagleBoard xM board might look like, respectively:
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
Where "ti,omap3-beagleboard-xm" specifies the exact model, it also
-claims that it compatible with the OMAP 3450 SoC, and the omap3 family
+claims that it is compatible with the OMAP 3450 SoC, and the omap3 family
of SoCs in general. You'll notice that the list is sorted from most
specific (exact board) to least specific (SoC family).
--
1.8.5.4
^ permalink raw reply related
* [PATCH 1/2] OF: update stdout-path parsing
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-02-08 11:53 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
Jean-Christophe PLAGNIOL-VILLARD,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer
Today we only check if the linux,stdout-path property is present and retreive
the node. But the DT specification allow to pass the serial options too as
this
linux,stdout-path = &UART0;
or with options
inux,stdout-path = "/plb@0/serial@84000000:115200";
So update the parsing to support and also the backward compatible stdout-path
property.
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
---
drivers/of/base.c | 57 +++++++++++++++++++++++++++++++++++++++++++++---------
include/linux/of.h | 4 ++--
2 files changed, 50 insertions(+), 11 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ff85450..ab9ff2f 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -34,6 +34,7 @@ EXPORT_SYMBOL(of_allnodes);
struct device_node *of_chosen;
struct device_node *of_aliases;
static struct device_node *of_stdout;
+static char *of_stdout_option;
DEFINE_MUTEX(of_aliases_mutex);
@@ -1783,6 +1784,45 @@ static void of_alias_add(struct alias_prop *ap, struct device_node *np,
}
/**
+ * of_stdout_path_scan - check if a device node matches the
+ * linux,stdout-path property and parse it
+ */
+static void of_stdout_path_scan(void)
+{
+ const char *name;
+ const char *tmp;
+ const char *tmp_option;
+
+ name = of_get_property(of_chosen, "linux,stdout-path", NULL);
+ if (!name)
+ name = of_get_property(of_chosen, "stdout-path", NULL);
+
+ if (!name)
+ return;
+
+ tmp_option = strchr(name, ':');
+
+ if (!tmp_option) {
+ of_stdout = of_find_node_by_path(name);
+ return;
+ }
+
+ tmp = kstrndup(name, strlen(name) - strlen(tmp_option), GFP_KERNEL);
+ if (!tmp)
+ return;
+
+ of_stdout = of_find_node_by_path(tmp);
+ if (!of_stdout)
+ goto out;
+
+ tmp_option++;
+ of_stdout_option = kstrdup(tmp_option, GFP_KERNEL);
+
+out:
+ kfree(tmp);
+}
+
+/**
* of_alias_scan - Scan all properties of 'aliases' node
*
* The function scans all the properties of 'aliases' node and populate
@@ -1800,13 +1840,8 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align))
if (of_chosen == NULL)
of_chosen = of_find_node_by_path("/chosen@0");
- if (of_chosen) {
- const char *name;
-
- name = of_get_property(of_chosen, "linux,stdout-path", NULL);
- if (name)
- of_stdout = of_find_node_by_path(name);
- }
+ if (of_chosen)
+ of_stdout_path_scan();
of_aliases = of_find_node_by_path("/aliases");
if (!of_aliases)
@@ -1923,13 +1958,17 @@ EXPORT_SYMBOL_GPL(of_prop_next_string);
* linux,stdout-path property
*
* Check if this device node matches the linux,stdout-path property
- * in the chosen node. return true if yes, false otherwise.
+ * in the chosen node. return true if yes, false otherwise with the option if
+ * requested.
*/
-int of_device_is_stdout_path(struct device_node *dn)
+int of_device_is_stdout_path(struct device_node *dn, char** option)
{
if (!of_stdout)
return false;
+ if (option)
+ *option = of_stdout_option;
+
return of_stdout == dn;
}
EXPORT_SYMBOL_GPL(of_device_is_stdout_path);
diff --git a/include/linux/of.h b/include/linux/of.h
index 70c64ba..a8afe44 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -352,7 +352,7 @@ const __be32 *of_prop_next_u32(struct property *prop, const __be32 *cur,
*/
const char *of_prop_next_string(struct property *prop, const char *cur);
-int of_device_is_stdout_path(struct device_node *dn);
+int of_device_is_stdout_path(struct device_node *dn, char** option);
#else /* CONFIG_OF */
@@ -542,7 +542,7 @@ static inline int of_machine_is_compatible(const char *compat)
return 0;
}
-static inline int of_device_is_stdout_path(struct device_node *dn)
+static inline int of_device_is_stdout_path(struct device_node *dn, char** option)
{
return 0;
}
--
1.9.rc1
--
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/2] serial: atmel: evaluate linux,stdout-path property
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-02-08 11:53 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
Jean-Christophe PLAGNIOL-VILLARD,
linux-serial-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer
In-Reply-To: <1391860433-5343-1-git-send-email-plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
if the driver is built as module skip it as add_preferred_console is not
exported
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
---
drivers/tty/serial/atmel_serial.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index a49f10d..2ade64e 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2044,6 +2044,19 @@ static struct uart_ops atmel_pops = {
#endif
};
+static void atmel_of_preferred_console(struct atmel_uart_port *atmel_port,
+ struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct uart_port *port = &atmel_port->uart;
+ char* option;
+
+ if (!np || !of_device_is_stdout_path(np, &option))
+ return;
+
+ add_preferred_console(ATMEL_DEVICENAME, port->line, option);
+}
+
/*
* Configure the port from the platform device resource info.
*/
@@ -2059,6 +2072,9 @@ static int atmel_init_port(struct atmel_uart_port *atmel_port,
atmel_init_rs485(atmel_port, pdev);
+ if (IS_BUILTIN(CONFIG_SERIAL_ATMEL))
+ atmel_of_preferred_console(atmel_port, pdev);
+
port->iotype = UPIO_MEM;
port->flags = UPF_BOOT_AUTOCONF;
port->ops = &atmel_pops;
--
1.9.rc1
--
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 1/2] devicetree: Add Xilinx XADC binding documentation
From: Jonathan Cameron @ 2014-02-08 12:26 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Michal Simek, linux-iio-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391534692-9049-1-git-send-email-lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
On 04/02/14 17:24, Lars-Peter Clausen wrote:
> The Xilinx XADC is a ADC that can be found in the series 7 FPGAs from Xilinx.
> The XADC has a DRP interface for communication. Currently two different
> frontends for the DRP interface exist. One that is only available on the ZYNQ
> family as a hardmacro in the SoC portion of the ZYNQ. The other one is available
> on all series 7 platforms and is a softmacro with a AXI interface. This binding
> document describes the bindings for both of them since the bindings are very
> similar.
>
> Each of them needs:
> * A address range where the registers are mapped
> * An interrupt number for the device interrupt
> * A clock. For the the ZYNQ hardmacro interface this is the modules PCAP
> clock, for the AXI softmacro it is the AXI bus interface clock.
>
> Additionally the bindings specify whether an external multiplexer is used and in
> which mode it is used. The devicetree bindings also describe which external
> channels are connected and in which configuration.
>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
A couple of little bits below.
> ---
> .../devicetree/bindings/iio/adc/xilinx-xadc.txt | 119 +++++++++++++++++++++
> 1 file changed, 119 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
> new file mode 100644
> index 0000000..40d97c1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
> @@ -0,0 +1,119 @@
> +Xilinx XADC device driver
> +
Err, you repeat yourself rather a lot in this description! You might want to state
this paragraph only once ;)
> +The Xilinx XADC is a ADC that can be found in the series 7 FPGAs from Xilinx.
> +The XADC has a DRP interface for communication. Currently two different
> +frontends for the DRP interface exist. One that is only available on the ZYNQ
> +family as a hardmacro in the SoC portion of the ZYNQ. The other one is
> +available on all series 7 platforms and is a softmacro with a AXI interface.
> +
> +This binding document describes the bindings for both of them since the
> +bindings are very similar. The Xilinx XADC is a ADC that can be found in the
> +series 7 FPGAs from Xilinx. The XADC has a DRP interface for communication.
> +Currently two different frontends for the DRP interface exist. One that is only
> +available on the ZYNQ family as a hardmacro in the SoC portion of the ZYNQ. The
> +other one is available on all series 7 platforms and is a softmacro with a AXI
> +interface. This binding document describes the bindings for both of them since
> +the bindings are very similar.
> +
> +Required properties:
> + - compatible: Should be one of
> + * "xlnx,zynq-xadc-1.00.a": When using the ZYNQ device
> + configuration interface to interface to the XADC hardmacro.
> + * "xlnx,axi-xadc-1.00.a": When using the axi-xadc pcore to
> + interface to the XADC hardmacro.
> + - reg: Address and length of the register set for the device
> + - interrupts: Interrupt for the XADC control interface.
> + - clocks: When using the ZYNQ this must be the ZYNQ PCAP clock,
> + when using the AXI-XADC pcore this must be the clock that provides the
> + clock to the AXI bus interface of the core.
> +
> +Optional properties:
> + - interrupt-parent: phandle to the parent interrupt controller
> + - xlnx,external-mux:
> + * "none": No external multiplexer is used, this is the default
> + if the property is omitted.
> + * "single": External multiplexer mode is used with one
> + multiplexer.
> + * "dual": External multiplexer mode is used with two
> + multiplexers for simultaneous sampling.
> + - xlnx,external-mux-channel: Configures which pair of pins is used to
> + sample data in external mux mode.
> + Valid values for single external multiplexer mode are:
> + 0: VP/VN
> + 1: VAUXP[0]/VAUXN[0]
> + 2: VAUXP[1]/VAUXN[1]
> + ...
> + 16: VAUXP[15]/VAUXN[15]
> + Valid values for dual external multiplexer mode are:
> + 1: VAUXP[0]/VAUXN[0] - VAUXP[8]/VAUXN[8]
> + 2: VAUXP[1]/VAUXN[1] - VAUXP[9]/VAUXN[9]
> + ...
> + 8: VAUXP[7]/VAUXN[7] - VAUXP[15]/VAUXN[15]
> +
> + This property needs to be present if the device is configured for
> + external multiplexer mode (either single or dual). If the device is
> + not using external multiplexer mode the property is ignored.
> + - xnlx,channels: List of external channels that are connected to the ADC
> + Required properties:
> + * #address-cells: Should be 1.
> + * #size-cells: Should be 0.
> +
> + The child nodes of this node represent the external channels which are
not present
> + connected to the ADC. If the property is no present no external
> + channels will be assumed to be connected.
> +
> + Each child node represents one channel and has the following
> + properties:
> + Required properties:
> + * reg: Pair of pins the the channel is connected to.
> + 0: VP/VN
> + 1: VAUXP[0]/VAUXN[0]
> + 2: VAUXP[1]/VAUXN[1]
> + ...
> + 16: VAUXP[15]/VAUXN[15]
> + Note each channel number should only be used at most
> + once.
> + Optional properties:
> + * xlnx,bipolar: If set the channel is used in bipolar
> + mode.
> +
> +
> +Examples:
> + xadc@f8007100 {
> + compatible = "xlnx,zynq-xadc-1.00.a";
> + reg = <0xf8007100 0x20>;
> + interrupts = <0 7 4>;
> + interrupt-parent = <&gic>;
> + clocks = <&pcap_clk>;
> +
> + xlnx,channels {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + channel@0 {
> + reg = <0>;
> + };
> + channel@1 {
> + reg = <1>;
> + };
> + channel@8 {
> + reg = <8>;
> + };
> + };
> + };
> +
> + xadc@43200000 {
> + compatible = "xlnx,axi-xadc-1.00.a";
> + reg = <0x43200000 0x1000>;
> + interrupts = <0 53 4>;
> + interrupt-parent = <&gic>;
> + clocks = <&fpga1_clk>;
> +
> + xlnx,channels {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + channel@0 {
> + reg = <0>;
> + xlnx,bipolar;
> + };
> + };
> + };
>
^ permalink raw reply
* Proposal
From: Mark Reyes Guus @ 2014-02-08 14:10 UTC (permalink / raw)
To: Recipients
Good day. I am Mark Reyes Guus, I work with Abn Amro Bank as an auditor. I have a proposition to discuss with you. Should you be interested, please e-mail back to me.
Private Email: markreyesguus-cUNmAtK3PYUqdlJmJB21zg@public.gmane.org OR markguus.reyes01-/k+kKI0dE6M@public.gmane.org
Yours Sincerely,
Mark Reyes Guus.
--
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] pci: Add support for creating a generic host_bridge from device tree
From: Liviu Dudau @ 2014-02-08 14:22 UTC (permalink / raw)
To: Tanmay Inamdar
Cc: Arnd Bergmann, devicetree@vger.kernel.org, linaro-kernel,
linux-pci, Will Deacon, LKML, Catalin Marinas, Bjorn Helgaas,
LAKML
In-Reply-To: <CACoXjcnTHgtBDesqFUOca1nf34HvNGAV0vP9AEB5xV1mvcRGfw@mail.gmail.com>
On Sat, Feb 08, 2014 at 12:21:56AM +0000, Tanmay Inamdar wrote:
> On Thu, Feb 6, 2014 at 2:18 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > On Wed, Feb 05, 2014 at 10:26:27PM +0000, Tanmay Inamdar wrote:
> >> Hello Liviu,
> >>
> >> I did not get the first email of this particular patch on any of
> >> subscribed mailing lists (don't know why), hence replying here.
> >
> > Strange, it shows in the MARC and GMANE archive for linux-pci, probably
> > a hickup on your receiving side?
> >
> >>
> >> +struct pci_host_bridge *
> >> +pci_host_bridge_of_init(struct device *parent, int busno, struct pci_ops *ops,
> >> + void *host_data, struct list_head *resources)
> >> +{
> >> + struct pci_bus *root_bus;
> >> + struct pci_host_bridge *bridge;
> >> +
> >> + /* first parse the host bridge bus ranges */
> >> + if (pci_host_bridge_of_get_ranges(parent->of_node, resources))
> >> + return NULL;
> >> +
> >> + /* then create the root bus */
> >> + root_bus = pci_create_root_bus(parent, busno, ops, host_data, resources);
> >> + if (!root_bus)
> >> + return NULL;
> >> +
> >> + bridge = to_pci_host_bridge(root_bus->bridge);
> >> +
> >> + return bridge;
> >> +}
> >>
> >> You are keeping the domain_nr inside pci_host_bridge structure. In
> >> above API, domain_nr is required in 'pci_find_bus' function called
> >> from 'pci_create_root_bus'. Since the bridge is allocated after
> >> creating root bus, 'pci_find_bus' always gets domain_nr as 0. This
> >> will cause problem for scanning multiple domains.
> >
> > Good catch. I was switching between creating a pci_controller in arch/arm64 and
> > adding the needed bits in pci_host_bridge. After internal review I've decided to
> > add the domain_nr to pci_host_bridge, but forgot to update the code everywhere.
> >
> > Thanks for reviewing this, will fix in v2.
> >
> > Do you find porting to the new API straight forward?
>
> It is quite straight forward for MEM regions but for IO regions it is
> not. You always assume IO resource starting at 0x0. IMO, this will
> cause problem for systems with multiple ports / IO windows. You can
> take a look at 'drivers/pci/host/pcie-designware.c'.
>
> Also the manipulations of addresses for IO_RESOURCES can be dangerous.
> It can make some value negative. For example if my PCI IO range starts
> in 32 bit address range say 0x8000_0000 with CPU address
> 0xb0_8000_0000, window->offset after manipulation will become
> negative.
>
> Personally I would like to do get all the PCI and CPU addresses from
> my device tree as is and do the 'pci_add_resource_offset'. This will
> help me setup my regions correctly without any further arithmetic.
> Please let me know what you think.
Yes, that parsing code of ranges is incorrect in light of the current discussion. I
will try to propose a fix in the v2 series.
Regarding your PCI IO range: if your bus address starts at 0x8000_0000, would
that not cause problems with devices that use less than 32bits for address
decoding? It is a rather unusual setup, I believe the x86 world (even PCI spec?)
mandates IO bus ranges in the first 16MB of address range?
Best regards,
Liviu
>
> >
> > Best regards,
> > Liviu
> >
> >>
> >>
> >> On Mon, Feb 3, 2014 at 10:46 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Monday 03 February 2014 18:33:48 Liviu Dudau wrote:
> >> >> +/**
> >> >> + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
> >> >> + * @dev: device node of the host bridge having the range property
> >> >> + * @resources: list where the range of resources will be added after DT parsing
> >> >> + *
> >> >> + * This function will parse the "ranges" property of a PCI host bridge device
> >> >> + * node and setup the resource mapping based on its content. It is expected
> >> >> + * that the property conforms with the Power ePAPR document.
> >> >> + *
> >> >> + * Each architecture will then apply their filtering based on the limitations
> >> >> + * of each platform. One general restriction seems to be the number of IO space
> >> >> + * ranges, the PCI framework makes intensive use of struct resource management,
> >> >> + * and for IORESOURCE_IO types they can only be requested if they are contained
> >> >> + * within the global ioport_resource, so that should be limited to one IO space
> >> >> + * range.
> >> >
> >> > Actually we have quite a different set of restrictions around I/O space on ARM32
> >> > at the moment: Each host bridge can have its own 64KB range in an arbitrary
> >> > location on MMIO space, and the total must not exceed 2MB of I/O space.
> >> >
> >> >> + */
> >> >> +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
> >> >> + struct list_head *resources)
> >> >> +{
> >> >> + struct resource *res;
> >> >> + struct of_pci_range range;
> >> >> + struct of_pci_range_parser parser;
> >> >> + int err;
> >> >> +
> >> >> + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
> >> >> +
> >> >> + /* Check for ranges property */
> >> >> + err = of_pci_range_parser_init(&parser, dev);
> >> >> + if (err)
> >> >> + return err;
> >> >> +
> >> >> + pr_debug("Parsing ranges property...\n");
> >> >> + for_each_of_pci_range(&parser, &range) {
> >> >> + /* Read next ranges element */
> >> >> + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> >> >> + range.pci_space, range.pci_addr);
> >> >> + pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> >> >> + range.cpu_addr, range.size);
> >> >> +
> >> >> + /* If we failed translation or got a zero-sized region
> >> >> + * (some FW try to feed us with non sensical zero sized regions
> >> >> + * such as power3 which look like some kind of attempt
> >> >> + * at exposing the VGA memory hole) then skip this range
> >> >> + */
> >> >> + if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> >> >> + continue;
> >> >> +
> >> >> + res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> >> >> + if (!res) {
> >> >> + err = -ENOMEM;
> >> >> + goto bridge_ranges_nomem;
> >> >> + }
> >> >> +
> >> >> + of_pci_range_to_resource(&range, dev, res);
> >> >> +
> >> >> + pci_add_resource_offset(resources, res,
> >> >> + range.cpu_addr - range.pci_addr);
> >> >> + }
> >> >
> >> > I believe of_pci_range_to_resource() will return the MMIO aperture for the
> >> > I/O space window here, which is not what you are supposed to pass into
> >> > pci_add_resource_offset.
> >> >
> >> >> +EXPORT_SYMBOL(pci_host_bridge_of_init);
> >> >
> >> > EXPORT_SYMBOL_GPL
> >> >
> >> >> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> >> >> index 6e34498..16febae 100644
> >> >> --- a/drivers/pci/probe.c
> >> >> +++ b/drivers/pci/probe.c
> >> >> @@ -1787,6 +1787,17 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> >> >> list_for_each_entry_safe(window, n, resources, list) {
> >> >> list_move_tail(&window->list, &bridge->windows);
> >> >> res = window->res;
> >> >> + /*
> >> >> + * IO resources are stored in the kernel with a CPU start
> >> >> + * address of zero. Adjust the data accordingly and remember
> >> >> + * the offset
> >> >> + */
> >> >> + if (resource_type(res) == IORESOURCE_IO) {
> >> >> + bridge->io_offset = res->start;
> >> >> + res->end -= res->start;
> >> >> + window->offset -= res->start;
> >> >> + res->start = 0;
> >> >> + }
> >> >> offset = window->offset;
> >> >> if (res->flags & IORESOURCE_BUS)
> >> >
> >> > Won't this break all existing host bridges?
> >> >
> >> > Arnd
> >> >
> >> > _______________________________________________
> >> > linux-arm-kernel mailing list
> >> > linux-arm-kernel@lists.infradead.org
> >> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>
> >
> > --
> > ====================
> > | I would like to |
> > | fix the world, |
> > | but they're not |
> > | giving me the |
> > \ source code! /
> > ---------------
> > ¯\_(ツ)_/¯
> >
> > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> >
> > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
> > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [alsa-devel] [PATCH 1/3] sound: soc: codecs: Add es8328 codec
From: Lars-Peter Clausen @ 2014-02-08 16:06 UTC (permalink / raw)
To: Sean Cross
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw, Mark Brown, Shawn Guo,
Liam Girdwood, Sascha Hauer
In-Reply-To: <1391749517-11787-2-git-send-email-xobs-nXMMniAx+RbQT0dZR+AlfA@public.gmane.org>
On 02/07/2014 06:05 AM, Sean Cross wrote:
> Add support for the ES8328 audio codec.
Hi,
a couple of minor coments. Also when submitting a patch it is a good idea to
run scripts/checkpatch.pl on the patch itself and `make C=2` and `make C=2
CHECK=scripts/coccicheck` on your driver module (E.g. in your case `make C=2
sound/soc/codecs/es8328.o`). These tools check your driver for a couple of
known issues. Fixing those before the submission will make the reviews job
easier.
> [...]
> +uint8_t sample_ratios[] = {
static const
> + [ES8328_RATE_8019 ] = 0x9,
> + [ES8328_RATE_11025] = 0x7,
> + [ES8328_RATE_22050] = 0x4,
> + [ES8328_RATE_44100] = 0x2,
> +};
> [...]
> +
> +static int es8328_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *dai)
> +{
> + struct snd_soc_codec *codec = dai->codec;
> +
> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> + u8 dac = snd_soc_read(codec, ES8328_DACCONTROL2);
> + dac &= ~ES8328_DACCONTROL2_RATEMASK;
> +
> + switch (params_rate(params)) {
> + case 8000:
> + dac |= sample_ratios[ES8328_RATE_8019];
> + break;
> + case 11025:
> + dac |= sample_ratios[ES8328_RATE_11025];
> + break;
> + case 22050:
> + dac |= sample_ratios[ES8328_RATE_22050];
> + break;
> + case 44100:
> + dac |= sample_ratios[ES8328_RATE_44100];
> + break;
> + default:
> + dev_err(codec->dev, "%s: unknown rate %d\n",
> + __func__, params_rate(params));
> + return -EINVAL;
> + }
> + snd_soc_write(codec, ES8328_DACCONTROL2, dac);
> + }
> +
> + if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) {
> + u8 adc = snd_soc_read(codec, ES8328_ADCCONTROL5);
> + adc &= ~ES8328_ADCCONTROL5_RATEMASK;
> +
> + switch (params_rate(params)) {
> + case 8000:
> + adc |= sample_ratios[ES8328_RATE_8019];
> + break;
> + case 11025:
> + adc |= sample_ratios[ES8328_RATE_11025];
> + break;
> + case 22050:
> + adc |= sample_ratios[ES8328_RATE_22050];
> + break;
> + case 44100:
> + adc |= sample_ratios[ES8328_RATE_44100];
> + break;
> + default:
> + dev_err(codec->dev, "%s: unknown rate %d\n",
> + __func__, params_rate(params));
> + return -EINVAL;
> + }
> + snd_soc_write(codec, ES8328_ADCCONTROL5, adc);
> + }
The only difference between the capture and the playback path seems to be
the register that's written two. By adding a variable that holds the
register number and gets initialized based on the direction you can elimate
about half of the code in this function.
> +
> + return 0;
[...]
> +static int es8328_set_dai_sysclk(struct snd_soc_dai *codec_dai,
> + int clk_id, unsigned int freq, int dir)
> +{
> + struct snd_soc_codec *codec = codec_dai->codec;
> + struct es8328_priv *es8328 = snd_soc_codec_get_drvdata(codec);
> +
> + switch (clk_id) {
> + case 0:
> + es8328->sysclk = freq;
es8328->sysclk seems to be unused. I guess it might be used if you add
support for different base clock rates. For now you should probably return
an error if freq != 22579200.
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
[...]
> +static int es8328_dac_enable(struct snd_soc_codec *codec)
> +{
> + u16 old_volumes[4];
> + u16 reg;
> + int i;
> +
> + for (i = 0; i < 4; i++) {
> + old_volumes[i] = snd_soc_read(codec, i + ES8328_DACCONTROL24);
> + snd_soc_write(codec, i + ES8328_DACCONTROL24, 0);
> + }
This looks like a job for AUTOMUTE controls. They'll set the volume to zero
before the DAC is powered down and restore the original value after the DAC
was powered up.
> +
> + /* Power up LOUT2 ROUT2, and power down xOUT1 */
> + snd_soc_write(codec, ES8328_DACPOWER,
> + ES8328_DACPOWER_ROUT2_ON |
> + ES8328_DACPOWER_LOUT2_ON);
> +
> + /* Enable click-free power up */
> + snd_soc_write(codec, ES8328_DACCONTROL6, ES8328_DACCONTROL6_CLICKFREE);
> + snd_soc_write(codec, ES8328_DACCONTROL3, 0x36);
> +
> + /* Set I2S to 16-bit mode */
> + snd_soc_write(codec, ES8328_DACCONTROL1, ES8328_DACCONTROL1_DACWL_16);
> +
> + /* No attenuation */
> + snd_soc_write(codec, ES8328_DACCONTROL4, 0x00);
> + snd_soc_write(codec, ES8328_DACCONTROL5, 0x00);
> +
> + /* Set LIN2 for the output mixer */
> + snd_soc_write(codec, ES8328_DACCONTROL16,
> + ES8328_DACCONTROL16_RMIXSEL_RIN2 |
> + ES8328_DACCONTROL16_LMIXSEL_LIN2);
> +
> + /* Point the left DAC at the left mixer */
> + snd_soc_write(codec, ES8328_DACCONTROL17, ES8328_DACCONTROL17_LD2LO);
> + /* Point the right DAC at the right mixer */
> + snd_soc_write(codec, ES8328_DACCONTROL20, ES8328_DACCONTROL20_RD2RO);
> +
> + /* Disable all other outputs */
> + snd_soc_write(codec, ES8328_DACCONTROL18, 0x00);
> + snd_soc_write(codec, ES8328_DACCONTROL19, 0x00);
> +
> +
> + /* Disable mono mode for DACL, and mute DACR */
> + snd_soc_write(codec, ES8328_DACCONTROL7, 0x00);
> +
> + for (i = 0; i < 4; i++)
> + snd_soc_write(codec, i + ES8328_DACCONTROL24, old_volumes[i]);
> +
> + reg = snd_soc_read(codec, ES8328_CHIPPOWER);
> + reg &= ~(ES8328_CHIPPOWER_DACVREF_OFF |
> + ES8328_CHIPPOWER_DACPLL_OFF |
> + ES8328_CHIPPOWER_DACSTM_RESET |
> + ES8328_CHIPPOWER_DACDIG_OFF);
> + snd_soc_write(codec, ES8328_CHIPPOWER, reg);
> + snd_soc_write(codec, ES8328_DACCONTROL3, 0x32);
> +
> + return 0;
> +}
[...]
> +static int es8328_suspend(struct snd_soc_codec *codec)
> +{
> + return 0;
> +}
> +
If you don't do anything in suspend there is no need to provide a callback
function.
> +static int es8328_resume(struct snd_soc_codec *codec)
> +{
> + es8328_init(codec);
> + return 0;
> +}
> +
> +static int es8328_probe(struct snd_soc_codec *codec)
> +{
> + int ret;
> + struct device *dev = codec->dev;
> +
> + ret = snd_soc_codec_set_cache_io(codec, 7, 9, SND_SOC_REGMAP);
> + if (ret < 0) {
> + dev_err(dev, "failed to configure cache I/O: %d\n", ret);
> + return ret;
> + }
> +
> + /* power on device */
> + es8328_init(codec);
> +
> + return 0;
> +}
> +
> +static int es8328_remove(struct snd_soc_codec *codec)
> +{
> + /* Power everything down and reset the cip */
> + snd_soc_write(codec, ES8328_CHIPPOWER,
> + ES8328_CHIPPOWER_DACSTM_RESET |
> + ES8328_CHIPPOWER_ADCSTM_RESET |
> + ES8328_CHIPPOWER_DACDIG_OFF |
> + ES8328_CHIPPOWER_ADCDIG_OFF |
> + ES8328_CHIPPOWER_DACVREF_OFF |
> + ES8328_CHIPPOWER_ADCVREF_OFF);
> +
> + return 0;
> +}
> +
> +static struct snd_soc_codec_driver soc_codec_dev_es8328 = {
es8328_codec_driver is a better name.
THe soc_codec_dev_... naming scheme you see in some drivers comes from a pre
multi-component era where it was more firt
> + .probe = es8328_probe,
> + .remove = es8328_remove,
> + .suspend = es8328_suspend,
> + .resume = es8328_resume,
> + .controls = es8328_snd_controls,
> + .num_controls = ARRAY_SIZE(es8328_snd_controls),
> + .dapm_widgets = es8328_dapm_widgets,
> + .num_dapm_widgets = ARRAY_SIZE(es8328_dapm_widgets),
> + .dapm_routes = es8328_intercon,
> + .num_dapm_routes = ARRAY_SIZE(es8328_intercon),
> +};
[...]
> +#if defined(CONFIG_SPI_MASTER)
> +static int es8328_spi_probe(struct spi_device *spi)
> +{
> + struct es8328_priv *es8328;
> + int ret;
> +
> + es8328 = devm_kzalloc(&spi->dev, sizeof(struct es8328_priv),
> + GFP_KERNEL);
sizeof(*es8328) is the preferred style for kernel code.
> + if (es8328 == NULL)
> + return -ENOMEM;
> +
> + es8328->regmap = devm_regmap_init_spi(spi, &es8328_regmap);
> + if (IS_ERR(es8328->regmap))
> + return PTR_ERR(es8328->regmap);
> +
> + spi_set_drvdata(spi, es8328);
> +
> + ret = snd_soc_register_codec(&spi->dev,
> + &soc_codec_dev_es8328, &es8328_dai, 1);
> + if (ret < 0)
> + dev_err(&spi->dev, "unable to register codec: %d\n", ret);
> +
> + return ret;
> +}
[...]
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
> +static int es8328_i2c_probe(struct i2c_client *i2c,
> + const struct i2c_device_id *id)
> +{
> + struct es8328_priv *es8328;
> + int ret;
> +
> + es8328 = devm_kzalloc(&i2c->dev, sizeof(struct es8328_priv),
> + GFP_KERNEL);
same here.
> + if (es8328 == NULL)
> + return -ENOMEM;
> +
> + es8328->regmap = devm_regmap_init_i2c(i2c, &es8328_regmap);
> + if (IS_ERR(es8328->regmap))
> + return PTR_ERR(es8328->regmap);
> +
> + i2c_set_clientdata(i2c, es8328);
> +
> + ret = snd_soc_register_codec(&i2c->dev,
> + &soc_codec_dev_es8328, &es8328_dai, 1);
> +
> + return ret;
> +}
> +
[...]
--
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] net: rfkill-regulator: Add devicetree support.
From: Belisko Marek @ 2014-02-08 20:42 UTC (permalink / raw)
To: Bill Fink
Cc: Rob Herring, Pawel Moll, Mark Rutland,
ijc+devicetree@hellion.org.uk, Kumar Gala, Rob Landley, linville,
johannes, davem, Grant Likely, NeilBrown,
Dr. H. Nikolaus Schaller, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, LKML, linux-wireless, netdev
In-Reply-To: <20140208012225.d7a311c7.billfink@mindspring.com>
On Sat, Feb 8, 2014 at 7:22 AM, Bill Fink <billfink@mindspring.com> wrote:
> On Fri, 7 Feb 2014, Marek Belisko wrote:
>
>> Signed-off-by: NeilBrown <neilb@suse.de>
>> Signed-off-by: Marek Belisko <marek@goldelico.com>
>> ---
>> Based on Neil's patch and extend for documentation and bindings include.
>>
>> .../bindings/net/rfkill/rfkill-relugator.txt | 28 ++++++++++++++++
>
> ^^^^^^^^^
> Typo in file name.
Ah. Right. Thanks.
>
> -Bill
>
>
>
>> include/dt-bindings/net/rfkill-regulator.h | 23 +++++++++++++
I also think this should be renamed to rfkill.h because same defines
could be used for rfkill-gpio driver.
>> net/rfkill/rfkill-regulator.c | 38 ++++++++++++++++++++++
>> 3 files changed, 89 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
>> create mode 100644 include/dt-bindings/net/rfkill-regulator.h
>>
>> diff --git a/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
>> new file mode 100644
>> index 0000000..cdb7dd7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/rfkill/rfkill-relugator.txt
>> @@ -0,0 +1,28 @@
>> +Regulator consumer for rfkill devices
>> +
>> +Required properties:
>> +- compatible : Must be "rfkill-regulator".
>> +- label : Name of rfkill device.
>> +- type : Type of rfkill device.
>> +
>> +Possible values (defined in include/dt-bindings/net/rfkill-regulator.h):
>> + RFKILL_TYPE_ALL
>> + RFKILL_TYPE_WLAN
>> + RFKILL_TYPE_BLUETOOTH
>> + RFKILL_TYPE_UWB
>> + RFKILL_TYPE_WIMAX
>> + RFKILL_TYPE_WWAN
>> + RFKILL_TYPE_GPS
>> + RFKILL_TYPE_FM
>> + RFKILL_TYPE_NFC
>> +
>> +- vrfkill-supply - regulator device.
>> +
>> +Example:
>> + gps-rfkill {
>> + compatible = "rfkill-regulator";
>> + label = "GPS";
>> + type = <RFKILL_TYPE_GPS>;
>> + vrfkill-supply = <®>;
>> + };
>> +
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* Re: [PATCH 02/12] dt-bindings: document s3c24xx controller for external clock output
From: Tomasz Figa @ 2014-02-09 1:54 UTC (permalink / raw)
To: Heiko Stübner, Kukjin Kim
Cc: t.figa, mturquette, linux-arm-kernel, linux-samsung-soc,
Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, devicetree
In-Reply-To: <201312131359.00450.heiko@sntech.de>
Hi Heiko,
On 13.12.2013 13:59, Heiko Stübner wrote:
> The clock settings are distributed over a regular register and parts
> of the misccr register.
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> .../bindings/clock/samsung,s3c2410-dclk.txt | 53 ++++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/samsung,s3c2410-dclk.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2410-dclk.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2410-dclk.txt
> new file mode 100644
> index 0000000..0a1f7b1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/samsung,s3c2410-dclk.txt
> @@ -0,0 +1,53 @@
> +* Samsung S3C24XX External Clock Output Controller
> +
> +The S3C24XX series can generate clock signals on two clock output pads.
> +The clock binding described here is applicable to all SoCs in
> +the s3c24x family.
> +
> +Required Properties:
> +
> +- compatible: should be one of the following.
> + - "samsung,s3c2410-dclk" - controller in S3C2410 SoCs.
> + - "samsung,s3c2412-dclk" - controller in S3C2412 SoCs.
> + - "samsung,s3c2440-dclk" - controller in S3C2440 and S3C2442 SoCs.
> + - "samsung,s3c2443-dclk" - controller in S3C2443 and later SoCs.
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- #clock-cells: should be 1.
> +- samsung,misccr: phandle to the syscon managing the misccr register, which
> + holds configuration settings for different soc-components (clocks, usb, ...).
Hmm, looking at the datasheet, DCLK and CLKOUT registers seem to be part
of the pin controller. I wonder if there is really a need for different
driver and device node to handle them.
Could this be simply made a part of the s3c24xx pinctrl driver,
extending it to register also a clock provider under the same DT node?
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 1/2] ARM: dts: N9/N950: fix boot hang with 3.14-rc1
From: Aaro Koskinen @ 2014-02-09 12:12 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Aaro Koskinen
N9/N950 does not boot anymore with 3.14-rc1, because SoC compatible
property is missing. Fix that.
Signed-off-by: Aaro Koskinen <aaro.koskinen-X3B1VOXEql0@public.gmane.org>
---
arch/arm/boot/dts/omap3-n9.dts | 2 +-
arch/arm/boot/dts/omap3-n950.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
index 39828ce464ee..9938b5dc1909 100644
--- a/arch/arm/boot/dts/omap3-n9.dts
+++ b/arch/arm/boot/dts/omap3-n9.dts
@@ -14,5 +14,5 @@
/ {
model = "Nokia N9";
- compatible = "nokia,omap3-n9", "ti,omap3";
+ compatible = "nokia,omap3-n9", "ti,omap36xx", "ti,omap3";
};
diff --git a/arch/arm/boot/dts/omap3-n950.dts b/arch/arm/boot/dts/omap3-n950.dts
index b076a526b999..261c5589bfa3 100644
--- a/arch/arm/boot/dts/omap3-n950.dts
+++ b/arch/arm/boot/dts/omap3-n950.dts
@@ -14,5 +14,5 @@
/ {
model = "Nokia N950";
- compatible = "nokia,omap3-n950", "ti,omap3";
+ compatible = "nokia,omap3-n950", "ti,omap36xx", "ti,omap3";
};
--
1.8.5.3
--
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/2] ARM: dts: N900: add missing compatible property
From: Aaro Koskinen @ 2014-02-09 12:12 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, linux-omap, devicetree,
linux-arm-kernel
Cc: Aaro Koskinen
In-Reply-To: <1391947956-24462-1-git-send-email-aaro.koskinen@iki.fi>
Add missing compatible property to avoid problems in the future.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
---
arch/arm/boot/dts/omap3-n900.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 6fc85f963530..0bf40c90faba 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -1,6 +1,6 @@
/*
* Copyright (C) 2013 Pavel Machek <pavel@ucw.cz>
- * Copyright 2013 Aaro Koskinen <aaro.koskinen@iki.fi>
+ * Copyright (C) 2013-2014 Aaro Koskinen <aaro.koskinen@iki.fi>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 (or later) as
@@ -13,7 +13,7 @@
/ {
model = "Nokia N900";
- compatible = "nokia,omap3-n900", "ti,omap3";
+ compatible = "nokia,omap3-n900", "ti,omap3430", "ti,omap3";
cpus {
cpu@0 {
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH v2] ARM: sunxi: Add driver for sunxi usb phy
From: Hans de Goede @ 2014-02-09 13:29 UTC (permalink / raw)
To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Kishon Vijay Abraham I, Maxime Ripard, linux-arm-kernel,
devicetree
In-Reply-To: <CAGb2v67L1X63Pp10H6MFApkLzCvwOokxSW+fH6KquDnqaRGRmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi,
On 02/08/2014 05:32 AM, Chen-Yu Tsai wrote:
> On Sat, Feb 8, 2014 at 12:33 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
>> through a single set of registers. Besides this there are also some other
>> phy related bits which need poking, which are per phy, but shared between the
>> ohci and ehci controllers, so these are also controlled from this new phy
>> driver.
>>
<snip>
>> + snprintf(name, sizeof(name), "usb%d_reset", i);
>> + reset = devm_reset_control_get(dev, name);
>> + if (IS_ERR(phy)) {
>> + dev_err(dev, "failed to get reset %s\n", name);
>> + return PTR_ERR(phy);
>> + }
>
> Wrong variable checked for error here that I pointed out before is still wrong.
Ah, yes my bad, I'll do a v3 fixing this, and switching to using register names as
Maxime requested. Don't know whether I'll be able to send v3 today as I'm currently
on the road. If not I'll try to get it out the door tomorrow.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v4 4/7] ARM: sunxi: Add driver for SD/MMC hosts found on Allwinner sunxi SoCs
From: Priit Laes @ 2014-02-09 14:37 UTC (permalink / raw)
To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson, Laurent Pinchart,
Mike Turquette, Simon Baatz, Hans de Goede, Emilio López,
linux-mmc-u79uwXL29TY76Z2rM5mHXA, Chris Ball,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, H Hartley Sweeten, Tejun Heo,
Maxime Ripard, Guennadi Liakhovetski,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
david.lanzendoerfer-Z7Kmv9EsliU
In-Reply-To: <20140207213316.24624.28705.stgit-GPtPHOohwllnsqa/0SyWJQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 10115 bytes --]
Ühel kenal päeval, R, 07.02.2014 kell 22:33, kirjutas David Lanzendörfer:
> This is based on the driver Allwinner ships in their Android kernel
sources.
>
> Initial porting to upstream kernels done by David Lanzendörfer, additional
> fixes and cleanups by Hans de Goede.
>
> It uses dma in bus-master mode using a built-in designware idmac
controller,
> which is identical to the one found in the mmc-dw hosts.
> The rest of the host is not identical to mmc-dw.
>
> Signed-off-by: David Lanzendörfer
<david.lanzendoerfer-Z7Kmv9EsliU-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>
> Signed-off-by: Hans de Goede
<hdegoede-H+wXaHxf7aLQT0dZR+AlfA-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>
> ---
> drivers/mmc/host/Kconfig | 7
> drivers/mmc/host/Makefile | 2
> drivers/mmc/host/sunxi-mci.c | 871
++++++++++++++++++++++++++++++++++++++++++
> drivers/mmc/host/sunxi-mci.h | 239 ++++++++++++
> 4 files changed, 1119 insertions(+)
> create mode 100644 drivers/mmc/host/sunxi-mci.c
> create mode 100644 drivers/mmc/host/sunxi-mci.h
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 1384f67..7caf266 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -689,3 +689,10 @@ config MMC_REALTEK_PCI
> help
> Say Y here to include driver code to support SD/MMC card interface
> of Realtek PCI-E card reader
> +
> +config MMC_SUNXI
> + tristate "Allwinner sunxi SD/MMC Host Controller support"
> + depends on ARCH_SUNXI
> + help
> + This selects support for the SD/MMC Host Controller on
> + Allwinner sunxi SoCs.
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 3483b6b..6c9cbd3 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -54,6 +54,8 @@ obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o
>
> obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o
>
> +obj-$(CONFIG_MMC_SUNXI) += sunxi-mci.o
> +
> obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-pltfm.o
> obj-$(CONFIG_MMC_SDHCI_CNS3XXX) += sdhci-cns3xxx.o
> obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o
> diff --git a/drivers/mmc/host/sunxi-mci.c b/drivers/mmc/host/sunxi-mci.c
> new file mode 100644
> index 0000000..8b47c99
> --- /dev/null
> +++ b/drivers/mmc/host/sunxi-mci.c
> @@ -0,0 +1,871 @@
> +/*
[...]
> +
> +static void sunxi_mmc_dump_errinfo(struct sunxi_mmc_host *smc_host)
> +{
> + struct mmc_command *cmd = smc_host->mrq->cmd;
> + struct mmc_data *data = smc_host->mrq->data;
> +
> + /* For some cmds timeout is normal with sd/mmc cards */
> + if ((smc_host->int_sum & SDXC_IntErrBit) == SDXC_RespTimeout &&
> + (cmd->opcode == 5 || cmd->opcode == 52))
Aren't these the ones defined in linux/mmc/sdio.h:
5 - SD_IO_SEND_OP_COND
52 - SD_IO_RW_DIRECT
> + return;
> +
> + dev_err(mmc_dev(smc_host->mmc),
> + "smc %d err, cmd %d,%s%s%s%s%s%s%s%s%s%s !!\n",
> + smc_host->mmc->index, cmd->opcode,
> + data ? (data->flags & MMC_DATA_WRITE ? " WR" : " RD") : "",
> + smc_host->int_sum & SDXC_RespErr ? " RE" : "",
> + smc_host->int_sum & SDXC_RespCRCErr ? " RCE" : "",
> + smc_host->int_sum & SDXC_DataCRCErr ? " DCE" : "",
> + smc_host->int_sum & SDXC_RespTimeout ? " RTO" : "",
> + smc_host->int_sum & SDXC_DataTimeout ? " DTO" : "",
> + smc_host->int_sum & SDXC_FIFORunErr ? " FE" : "",
> + smc_host->int_sum & SDXC_HardWLocked ? " HL" : "",
> + smc_host->int_sum & SDXC_StartBitErr ? " SBE" : "",
> + smc_host->int_sum & SDXC_EndBitErr ? " EBE" : ""
> + );
> +}
[...]
> +static void sunxi_mmc_set_clk_dly(struct sunxi_mmc_host *smc_host,
> + u32 oclk_dly, u32 sclk_dly)
> +{
> + unsigned long iflags;
> + struct clk_hw *hw = __clk_get_hw(smc_host->clk_mod);
> +
> + spin_lock_irqsave(&smc_host->lock, iflags);
> + clk_sunxi_mmc_phase_control(hw, sclk_dly, oclk_dly);
> + spin_unlock_irqrestore(&smc_host->lock, iflags);
> +}
> +
> +struct sunxi_mmc_clk_dly mmc_clk_dly[MMC_CLK_MOD_NUM] = {
> + { MMC_CLK_400K, 0, 7 },
> + { MMC_CLK_25M, 0, 5 },
> + { MMC_CLK_50M, 3, 5 },
> + { MMC_CLK_50MDDR, 2, 4 },
> + { MMC_CLK_50MDDR_8BIT, 2, 4 },
> + { MMC_CLK_100M, 1, 4 },
> + { MMC_CLK_200M, 1, 4 },
>From the looks of it, it should be static const, but apparently this was
raising a warning when David did it.. Hints anyone?
> +};
> +
> +static void sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *smc_host,
> + unsigned int rate)
> +{
> + u32 newrate;
> + u32 src_clk;
> + u32 oclk_dly;
> + u32 sclk_dly;
> + u32 temp;
> + struct sunxi_mmc_clk_dly *dly = NULL;
> +
> + newrate = clk_round_rate(smc_host->clk_mod, rate);
> + if (smc_host->clk_mod_rate == newrate) {
> + dev_dbg(mmc_dev(smc_host->mmc), "clk already %d, rounded %d\n",
> + rate, newrate);
> + return;
> + }
> +
> + dev_dbg(mmc_dev(smc_host->mmc), "setting clk to %d, rounded %d\n",
> + rate, newrate);
> +
> + /* setting clock rate */
> + clk_disable(smc_host->clk_mod);
> + clk_set_rate(smc_host->clk_mod, newrate);
> + clk_enable(smc_host->clk_mod);
> + smc_host->clk_mod_rate = newrate = clk_get_rate(smc_host->clk_mod);
> + dev_dbg(mmc_dev(smc_host->mmc), "clk is now %d\n", newrate);
> +
> + sunxi_mmc_oclk_onoff(smc_host, 0);
> + /* clear internal divider */
> + temp = mci_readl(smc_host, REG_CLKCR);
> + temp &= ~0xff;
> + mci_writel(smc_host, REG_CLKCR, temp);
> +
> + /* determine delays */
> + if (rate <= 400000) {
> + dly = &mmc_clk_dly[MMC_CLK_400K];
> + } else if (rate <= 25000000) {
> + dly = &mmc_clk_dly[MMC_CLK_25M];
> + } else if (rate <= 50000000) {
> + if (smc_host->ddr) {
> + if (smc_host->bus_width == 8)
> + dly = &mmc_clk_dly[MMC_CLK_50MDDR_8BIT];
> + else
> + dly = &mmc_clk_dly[MMC_CLK_50MDDR];
> + } else {
> + dly = &mmc_clk_dly[MMC_CLK_50M];
> + }
> + } else if (rate <= 104000000) {
> + dly = &mmc_clk_dly[MMC_CLK_100M];
> + } else if (rate <= 208000000) {
> + dly = &mmc_clk_dly[MMC_CLK_200M];
> + } else {
> + dly = &mmc_clk_dly[MMC_CLK_50M];
> + }
> +
> + oclk_dly = dly->oclk_dly;
> + sclk_dly = dly->sclk_dly;
> +
> + src_clk = clk_get_rate(clk_get_parent(smc_host->clk_mod));
> +
> + if (src_clk >= 300000000 && src_clk <= 400000000) {
> + if (oclk_dly)
> + oclk_dly--;
> + if (sclk_dly)
> + sclk_dly--;
> + }
> +
> + sunxi_mmc_set_clk_dly(smc_host, oclk_dly, sclk_dly);
> + sunxi_mmc_oclk_onoff(smc_host, 1);
> +
> + /* oclk_onoff sets various irq status bits, clear these */
> + mci_writel(smc_host, REG_RINTR,
> + mci_readl(smc_host, REG_RINTR) & ~SDXC_SDIOInt);
> +}
> +
[...]
> diff --git a/drivers/mmc/host/sunxi-mci.h b/drivers/mmc/host/sunxi-mci.h
> new file mode 100644
> index 0000000..4f3c2d9
> --- /dev/null
> +++ b/drivers/mmc/host/sunxi-mci.h
> @@ -0,0 +1,239 @@
> +/*
> + * Driver for sunxi SD/MMC host controllers
> + * (C) Copyright 2014-2015 Reuuimlla Technology Co., Ltd.
> + * (C) Copyright 2014-2015 Aaron Maoye
<leafy.myeh-jFKXxz0WcGyYHARAtoI1EgC/G2K4zDHf-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>
> + * (C) Copyright 2014-2015 O2S GmbH <www.o2s.ch>
> + * (C) Copyright 2014-2015 David Lanzendörfer
<david.lanzendoerfer-Z7Kmv9EsliU@public.gmane.org>
> + * (C) Copyright 2014-2015 Hans de Goede
<hdegoede-H+wXaHxf7aLQT0dZR+AlfA-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>
Had to take a look at the calendar...
> + *
> + * 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.
> + */
> +
> +#ifndef __SUNXI_MCI_H__
> +#define __SUNXI_MCI_H__
> +
[...]
> +
> +struct sunxi_idma_des {
> + u32 config;
> +#define SDXC_IDMAC_DES0_DIC BIT(1) /* disable interrupt on
completion */
> +#define SDXC_IDMAC_DES0_LD BIT(2) /* last descriptor */
> +#define SDXC_IDMAC_DES0_FD BIT(3) /* first descriptor */
> +#define SDXC_IDMAC_DES0_CH BIT(4) /* chain mode */
> +#define SDXC_IDMAC_DES0_ER BIT(5) /* end of ring */
> +#define SDXC_IDMAC_DES0_CES BIT(30) /* card error summary */
> +#define SDXC_IDMAC_DES0_OWN BIT(31) /* 1-idma owns it, 0-host owns it
*/
This #define placement inside the struct looks really weird.
> +
> + /*
> + * If the idma-des-size-bits of property is ie 13, bufsize bits are:
> + * Bits 0-12: buf1 size
> + * Bits 13-25: buf2 size
> + * Bits 26-31: not used
> + * Since we only ever set buf1 size, we can simply store it directly.
> + */
> + u32 buf_size;
> + u32 buf_addr_ptr1;
> + u32 buf_addr_ptr2;
> +};
> +
[...]
> +
> +#define MMC_CLK_400K 0
> +#define MMC_CLK_25M 1
> +#define MMC_CLK_50M 2
> +#define MMC_CLK_50MDDR 3
> +#define MMC_CLK_50MDDR_8BIT 4
> +#define MMC_CLK_100M 5
> +#define MMC_CLK_200M 6
> +#define MMC_CLK_MOD_NUM 7
> +
> +struct sunxi_mmc_clk_dly {
> + u32 mode;
> + u32 oclk_dly;
> + u32 sclk_dly;
Do these members have to be u32? They all seem to be smaller than 10.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
[-- Attachment #2: Type: text/html, Size: 15454 bytes --]
^ permalink raw reply
* Re: Devicetree Maintenance in barebox
From: Jon Loeliger @ 2014-02-09 17:58 UTC (permalink / raw)
To: Jason Cooper
Cc: Sascha Hauer, Grant Likely, Ian Campbell,
barebox-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140207141028.GT8533-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
> Hi Sascha,
>
> + Grant Likely, Ian Campbell, devicetree ML
>
> Also, In the DT meeting earlier this week, Grant Likely said he has the
> request in to create a separate mailinglist for collaboration between
> the different devicetree users (BSD, Linux, etc).
...
> I think the proper solution will percolate out of the first
> cross-project discussions on the new ML.
...
> Definitely fodder for the new ML.
>
> Grant, can you please add Sascha to the list of folks to notify when
> the new ML is ready?
I don't think there needs to be a different mailing list
in order to combine or discuss other OS's use of the device
tree compiler. The DTC is OS and Use-agnostic. Discussions
of DTC needs for FreeBSD can happen right here as the orginal
purpose of this list was DTC discussion.
Are you, and Grant(?), suggesting that a separate list
should be created for FreeBSD use of DTS-file contents?
Or that DTS-file-content related discussions should be
separated from DTC discussions?
> imho, the goal is to not have any project tied to a specific version
> of the devicetree.
>
> iow, we don't break backwards compatibility in the
> devicetrees, and projects should revert to default behavior if new dt
> parameters are missing. This means Linux and BSD shouldn't need to keep
> a current copy of the devicetree in their trees. However, building the
> bootloader is a different animal. It needs to provide the dt blob...
The devicetree source file format hasn't changed in years.
Yes, it is enhanced, but compatibly. Or do you mean the
contents of the DTB for some specific platform?
Thanks,
jdl
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox