* [PATCH v2] drm: zte: support hdmi audio through spdif
From: Shawn Guo @ 2016-12-29 11:14 UTC (permalink / raw)
To: linux-arm-kernel
From: Shawn Guo <shawn.guo@linaro.org>
It enables HDMI audio support through SPDIF interface based on generic
hdmi-audio-codec driver. The HDMI hardware supports more audio
interfaces than SPDIF, like I2S, which may be added later.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
Changes for v2:
- Distll the function zx_hdmi_audio_get_n() per Sean's suggestion and
make it inline.
- Fix the operator typo on N_SVAL2 register write.
drivers/gpu/drm/zte/Kconfig | 1 +
drivers/gpu/drm/zte/zx_hdmi.c | 148 +++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/zte/zx_hdmi_regs.h | 14 ++++
drivers/gpu/drm/zte/zx_vou.c | 9 +++
drivers/gpu/drm/zte/zx_vou.h | 10 +++
drivers/gpu/drm/zte/zx_vou_regs.h | 2 +
6 files changed, 184 insertions(+)
diff --git a/drivers/gpu/drm/zte/Kconfig b/drivers/gpu/drm/zte/Kconfig
index 4065b2840f1c..ed6de4b10c74 100644
--- a/drivers/gpu/drm/zte/Kconfig
+++ b/drivers/gpu/drm/zte/Kconfig
@@ -4,5 +4,6 @@ config DRM_ZTE
select DRM_KMS_CMA_HELPER
select DRM_KMS_FB_HELPER
select DRM_KMS_HELPER
+ select SND_SOC_HDMI_CODEC if SND_SOC
help
Choose this option to enable DRM on ZTE ZX SoCs.
diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c
index 6bf6c364811e..c20121846073 100644
--- a/drivers/gpu/drm/zte/zx_hdmi.c
+++ b/drivers/gpu/drm/zte/zx_hdmi.c
@@ -25,6 +25,8 @@
#include <drm/drm_of.h>
#include <drm/drmP.h>
+#include <sound/hdmi-codec.h>
+
#include "zx_hdmi_regs.h"
#include "zx_vou.h"
@@ -49,6 +51,7 @@ struct zx_hdmi {
bool sink_is_hdmi;
bool sink_has_audio;
const struct vou_inf *inf;
+ struct platform_device *audio_pdev;
};
#define to_zx_hdmi(x) container_of(x, struct zx_hdmi, x)
@@ -366,6 +369,142 @@ static irqreturn_t zx_hdmi_irq_handler(int irq, void *dev_id)
return IRQ_NONE;
}
+static int zx_hdmi_audio_startup(struct device *dev, void *data)
+{
+ struct zx_hdmi *hdmi = dev_get_drvdata(dev);
+ struct drm_encoder *encoder = &hdmi->encoder;
+
+ vou_inf_hdmi_audio_sel(encoder->crtc, VOU_HDMI_AUD_SPDIF);
+
+ return 0;
+}
+
+static void zx_hdmi_audio_shutdown(struct device *dev, void *data)
+{
+ struct zx_hdmi *hdmi = dev_get_drvdata(dev);
+
+ /* Disable audio input */
+ hdmi_writeb_mask(hdmi, AUD_EN, AUD_IN_EN, 0);
+}
+
+static inline int zx_hdmi_audio_get_n(unsigned int fs)
+{
+ unsigned int n;
+
+ if (fs && (fs % 44100) == 0)
+ n = 6272 * (fs / 44100);
+ else
+ n = fs * 128 / 1000;
+
+ return n;
+}
+
+static int zx_hdmi_audio_hw_params(struct device *dev,
+ void *data,
+ struct hdmi_codec_daifmt *daifmt,
+ struct hdmi_codec_params *params)
+{
+ struct zx_hdmi *hdmi = dev_get_drvdata(dev);
+ struct hdmi_audio_infoframe *cea = ¶ms->cea;
+ union hdmi_infoframe frame;
+ int n;
+
+ /* We only support spdif for now */
+ if (daifmt->fmt != HDMI_SPDIF) {
+ DRM_DEV_ERROR(hdmi->dev, "invalid daifmt %d\n", daifmt->fmt);
+ return -EINVAL;
+ }
+
+ switch (params->sample_width) {
+ case 16:
+ hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG, SPDIF_SAMPLE_SIZE_MASK,
+ SPDIF_SAMPLE_SIZE_16BIT);
+ break;
+ case 20:
+ hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG, SPDIF_SAMPLE_SIZE_MASK,
+ SPDIF_SAMPLE_SIZE_20BIT);
+ break;
+ case 24:
+ hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG, SPDIF_SAMPLE_SIZE_MASK,
+ SPDIF_SAMPLE_SIZE_24BIT);
+ break;
+ default:
+ DRM_DEV_ERROR(hdmi->dev, "invalid sample width %d\n",
+ params->sample_width);
+ return -EINVAL;
+ }
+
+ /* CTS is calculated by hardware, and we only need to take care of N */
+ n = zx_hdmi_audio_get_n(params->sample_rate);
+ hdmi_writeb(hdmi, N_SVAL1, n & 0xff);
+ hdmi_writeb(hdmi, N_SVAL2, (n >> 8) & 0xff);
+ hdmi_writeb(hdmi, N_SVAL3, (n >> 16) & 0xf);
+
+ /* Enable spdif mode */
+ hdmi_writeb_mask(hdmi, AUD_MODE, SPDIF_EN, SPDIF_EN);
+
+ /* Enable audio input */
+ hdmi_writeb_mask(hdmi, AUD_EN, AUD_IN_EN, AUD_IN_EN);
+
+ memcpy(&frame.audio, cea, sizeof(*cea));
+
+ return zx_hdmi_infoframe_trans(hdmi, &frame, FSEL_AUDIO);
+}
+
+static int zx_hdmi_audio_digital_mute(struct device *dev, void *data,
+ bool enable)
+{
+ struct zx_hdmi *hdmi = dev_get_drvdata(dev);
+
+ if (enable)
+ hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG, TPI_AUD_MUTE,
+ TPI_AUD_MUTE);
+ else
+ hdmi_writeb_mask(hdmi, TPI_AUD_CONFIG, TPI_AUD_MUTE, 0);
+
+ return 0;
+}
+
+static int zx_hdmi_audio_get_eld(struct device *dev, void *data,
+ uint8_t *buf, size_t len)
+{
+ struct zx_hdmi *hdmi = dev_get_drvdata(dev);
+ struct drm_connector *connector = &hdmi->connector;
+
+ memcpy(buf, connector->eld, min(sizeof(connector->eld), len));
+
+ return 0;
+}
+
+static const struct hdmi_codec_ops zx_hdmi_codec_ops = {
+ .audio_startup = zx_hdmi_audio_startup,
+ .hw_params = zx_hdmi_audio_hw_params,
+ .audio_shutdown = zx_hdmi_audio_shutdown,
+ .digital_mute = zx_hdmi_audio_digital_mute,
+ .get_eld = zx_hdmi_audio_get_eld,
+};
+
+static struct hdmi_codec_pdata zx_hdmi_codec_pdata = {
+ .ops = &zx_hdmi_codec_ops,
+ .spdif = 1,
+};
+
+static int zx_hdmi_audio_register(struct zx_hdmi *hdmi)
+{
+ struct platform_device *pdev;
+
+ pdev = platform_device_register_data(hdmi->dev, HDMI_CODEC_DRV_NAME,
+ PLATFORM_DEVID_AUTO,
+ &zx_hdmi_codec_pdata,
+ sizeof(zx_hdmi_codec_pdata));
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ hdmi->audio_pdev = pdev;
+
+ return 0;
+}
+
static int zx_hdmi_i2c_read(struct zx_hdmi *hdmi, struct i2c_msg *msg)
{
int len = msg->len;
@@ -566,6 +705,12 @@ static int zx_hdmi_bind(struct device *dev, struct device *master, void *data)
return ret;
}
+ ret = zx_hdmi_audio_register(hdmi);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "failed to register audio: %d\n", ret);
+ return ret;
+ }
+
ret = zx_hdmi_register(drm, hdmi);
if (ret) {
DRM_DEV_ERROR(dev, "failed to register hdmi: %d\n", ret);
@@ -590,6 +735,9 @@ static void zx_hdmi_unbind(struct device *dev, struct device *master,
hdmi->connector.funcs->destroy(&hdmi->connector);
hdmi->encoder.funcs->destroy(&hdmi->encoder);
+
+ if (hdmi->audio_pdev)
+ platform_device_unregister(hdmi->audio_pdev);
}
static const struct component_ops zx_hdmi_component_ops = {
diff --git a/drivers/gpu/drm/zte/zx_hdmi_regs.h b/drivers/gpu/drm/zte/zx_hdmi_regs.h
index de911f66b658..c6d5d8211725 100644
--- a/drivers/gpu/drm/zte/zx_hdmi_regs.h
+++ b/drivers/gpu/drm/zte/zx_hdmi_regs.h
@@ -52,5 +52,19 @@
#define TPI_INFO_TRANS_RPT BIT(6)
#define TPI_DDC_MASTER_EN 0x06f8
#define HW_DDC_MASTER BIT(7)
+#define N_SVAL1 0xa03
+#define N_SVAL2 0xa04
+#define N_SVAL3 0xa05
+#define AUD_EN 0xa13
+#define AUD_IN_EN BIT(0)
+#define AUD_MODE 0xa14
+#define SPDIF_EN BIT(1)
+#define TPI_AUD_CONFIG 0xa62
+#define SPDIF_SAMPLE_SIZE_SHIFT 6
+#define SPDIF_SAMPLE_SIZE_MASK (0x3 << SPDIF_SAMPLE_SIZE_SHIFT)
+#define SPDIF_SAMPLE_SIZE_16BIT (0x1 << SPDIF_SAMPLE_SIZE_SHIFT)
+#define SPDIF_SAMPLE_SIZE_20BIT (0x2 << SPDIF_SAMPLE_SIZE_SHIFT)
+#define SPDIF_SAMPLE_SIZE_24BIT (0x3 << SPDIF_SAMPLE_SIZE_SHIFT)
+#define TPI_AUD_MUTE BIT(4)
#endif /* __ZX_HDMI_REGS_H__ */
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
index 73fe15c17c32..f89ad7f72fdb 100644
--- a/drivers/gpu/drm/zte/zx_vou.c
+++ b/drivers/gpu/drm/zte/zx_vou.c
@@ -119,6 +119,15 @@ static inline struct zx_vou_hw *crtc_to_vou(struct drm_crtc *crtc)
return zcrtc->vou;
}
+void vou_inf_hdmi_audio_sel(struct drm_crtc *crtc,
+ enum vou_inf_hdmi_audio aud)
+{
+ struct zx_crtc *zcrtc = to_zx_crtc(crtc);
+ struct zx_vou_hw *vou = zcrtc->vou;
+
+ zx_writel_mask(vou->vouctl + VOU_INF_HDMI_CTRL, VOU_HDMI_AUD_MASK, aud);
+}
+
void vou_inf_enable(const struct vou_inf *inf, struct drm_crtc *crtc)
{
struct zx_crtc *zcrtc = to_zx_crtc(crtc);
diff --git a/drivers/gpu/drm/zte/zx_vou.h b/drivers/gpu/drm/zte/zx_vou.h
index 349e06cd86f4..e571b888a3ca 100644
--- a/drivers/gpu/drm/zte/zx_vou.h
+++ b/drivers/gpu/drm/zte/zx_vou.h
@@ -30,6 +30,14 @@ enum vou_inf_data_sel {
VOU_RGB_666 = 3,
};
+enum vou_inf_hdmi_audio {
+ VOU_HDMI_AUD_SPDIF = BIT(0),
+ VOU_HDMI_AUD_I2S = BIT(1),
+ VOU_HDMI_AUD_DSD = BIT(2),
+ VOU_HDMI_AUD_HBR = BIT(3),
+ VOU_HDMI_AUD_PARALLEL = BIT(4),
+};
+
struct vou_inf {
enum vou_inf_id id;
enum vou_inf_data_sel data_sel;
@@ -37,6 +45,8 @@ struct vou_inf {
u32 clocks_sel_bits;
};
+void vou_inf_hdmi_audio_sel(struct drm_crtc *crtc,
+ enum vou_inf_hdmi_audio aud);
void vou_inf_enable(const struct vou_inf *inf, struct drm_crtc *crtc);
void vou_inf_disable(const struct vou_inf *inf, struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/zte/zx_vou_regs.h b/drivers/gpu/drm/zte/zx_vou_regs.h
index f44e7a4ae441..15b73cd3a612 100644
--- a/drivers/gpu/drm/zte/zx_vou_regs.h
+++ b/drivers/gpu/drm/zte/zx_vou_regs.h
@@ -150,6 +150,8 @@
#define VOU_CLK_GL0_SEL BIT(4)
#define VOU_CLK_REQEN 0x20
#define VOU_CLK_EN 0x24
+#define VOU_INF_HDMI_CTRL 0x30
+#define VOU_HDMI_AUD_MASK 0x1f
/* OTFPPU_CTRL registers */
#define OTFPPU_RSZ_DATA_SOURCE 0x04
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] mmc: host: s3cmci: allow probing from device tree
From: Ulf Hansson @ 2016-12-29 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481289284-19919-3-git-send-email-sergio.prado@e-labworks.com>
On 9 December 2016 at 14:14, Sergio Prado <sergio.prado@e-labworks.com> wrote:
> Allows configuring Samsung S3C24XX MMC/SD/SDIO controller using a device
> tree.
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> drivers/mmc/host/s3cmci.c | 155 +++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 131 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
> index 932a4b1fed33..bfeb90e8ffee 100644
> --- a/drivers/mmc/host/s3cmci.c
> +++ b/drivers/mmc/host/s3cmci.c
> @@ -23,6 +23,9 @@
> #include <linux/gpio.h>
> #include <linux/irq.h>
> #include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_gpio.h>
>
> #include <plat/gpio-cfg.h>
> #include <mach/dma.h>
> @@ -127,6 +130,22 @@ enum dbg_channels {
> dbg_conf = (1 << 8),
> };
>
> +struct s3cmci_drv_data {
> + int is2440;
This doesn't say much.
Please use a more descriptive variable name and rename the struct to
perhaps "variant_data", because I guess that is what this is?
> +};
> +
> +static const struct s3cmci_drv_data s3c2410_s3cmci_drv_data = {
> + .is2440 = 0,
> +};
> +
> +static const struct s3cmci_drv_data s3c2412_s3cmci_drv_data = {
> + .is2440 = 1,
> +};
> +
> +static const struct s3cmci_drv_data s3c2440_s3cmci_drv_data = {
> + .is2440 = 1,
> +};
> +
> static const int dbgmap_err = dbg_fail;
> static const int dbgmap_info = dbg_info | dbg_conf;
> static const int dbgmap_debug = dbg_err | dbg_debug;
> @@ -1241,8 +1260,9 @@ static void s3cmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> case MMC_POWER_ON:
> case MMC_POWER_UP:
> /* Configure GPE5...GPE10 pins in SD mode */
> - s3c_gpio_cfgall_range(S3C2410_GPE(5), 6, S3C_GPIO_SFN(2),
> - S3C_GPIO_PULL_NONE);
> + if (!host->pdev->dev.of_node)
> + s3c_gpio_cfgall_range(S3C2410_GPE(5), 6, S3C_GPIO_SFN(2),
> + S3C_GPIO_PULL_NONE);
>
> if (host->pdata->set_power)
> host->pdata->set_power(ios->power_mode, ios->vdd);
> @@ -1254,7 +1274,8 @@ static void s3cmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>
> case MMC_POWER_OFF:
> default:
> - gpio_direction_output(S3C2410_GPE(5), 0);
> + if (!host->pdev->dev.of_node)
> + gpio_direction_output(S3C2410_GPE(5), 0);
>
> if (host->is2440)
> mci_con |= S3C2440_SDICON_SDRESET;
> @@ -1544,21 +1565,12 @@ static inline void s3cmci_debugfs_remove(struct s3cmci_host *host) { }
>
> #endif /* CONFIG_DEBUG_FS */
>
> -static int s3cmci_probe(struct platform_device *pdev)
> +static int s3cmci_probe_pdata(struct s3cmci_host *host)
> {
> - struct s3cmci_host *host;
> - struct mmc_host *mmc;
> - int ret;
> - int is2440;
> - int i;
> + struct platform_device *pdev = host->pdev;
> + int i, ret;
>
> - is2440 = platform_get_device_id(pdev)->driver_data;
> -
> - mmc = mmc_alloc_host(sizeof(struct s3cmci_host), &pdev->dev);
> - if (!mmc) {
> - ret = -ENOMEM;
> - goto probe_out;
> - }
> + host->is2440 = platform_get_device_id(pdev)->driver_data;
>
> for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++) {
> ret = gpio_request(i, dev_name(&pdev->dev));
> @@ -1568,14 +1580,90 @@ static int s3cmci_probe(struct platform_device *pdev)
> for (i--; i >= S3C2410_GPE(5); i--)
> gpio_free(i);
>
> - goto probe_free_host;
> + return ret;
> }
> }
>
> + return 0;
> +}
> +
> +static int s3cmci_probe_dt(struct s3cmci_host *host)
> +{
> + struct platform_device *pdev = host->pdev;
> + struct s3c24xx_mci_pdata *pdata;
> + const struct s3cmci_drv_data *drvdata;
> + struct mmc_host *mmc = host->mmc;
> + int gpio, ret;
> +
> + drvdata = of_device_get_match_data(&pdev->dev);
> + if (!drvdata)
> + return -ENODEV;
> +
> + host->is2440 = drvdata->is2440;
Instead of copying only the member, perhaps assign a host->variant
pointer to the drvdata instead, as that allows to extend the
information for the variant to cover more things than only "is2440",
while going forward.
In other words:
host->variant = of_device_get_match_data(&pdev->dev);
> +
> + ret = mmc_of_parse(mmc);
> + if (ret)
> + return ret;
> +
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + pdata->ocr_avail = mmc->ocr_avail;
> +
> + if (mmc->caps2 & MMC_CAP2_NO_WRITE_PROTECT)
> + pdata->no_wprotect = 1;
> +
> + if (mmc->caps & MMC_CAP_NEEDS_POLL)
> + pdata->no_detect = 1;
> +
> + if (mmc->caps2 & MMC_CAP2_RO_ACTIVE_HIGH)
> + pdata->wprotect_invert = 1;
> +
> + if (mmc->caps2 & MMC_CAP2_CD_ACTIVE_HIGH)
> + pdata->detect_invert = 1;
> +
> + gpio = of_get_named_gpio(pdev->dev.of_node, "cd-gpios", 0);
This should already be covered via mmc_of_parse().
> + if (gpio_is_valid(gpio)) {
> + pdata->gpio_detect = gpio;
> + gpio_free(gpio);
> + }
> +
> + gpio = of_get_named_gpio(pdev->dev.of_node, "wp-gpios", 0);
This should already be covered via mmc_of_parse().
> + if (gpio_is_valid(gpio)) {
> + pdata->gpio_wprotect = gpio;
> + gpio_free(gpio);
> + }
> +
> + pdev->dev.platform_data = pdata;
> +
> + return 0;
> +}
> +
> +static int s3cmci_probe(struct platform_device *pdev)
> +{
> + struct s3cmci_host *host;
> + struct mmc_host *mmc;
> + int ret;
> + int i;
> +
> + mmc = mmc_alloc_host(sizeof(struct s3cmci_host), &pdev->dev);
> + if (!mmc) {
> + ret = -ENOMEM;
> + goto probe_out;
> + }
> +
> host = mmc_priv(mmc);
> host->mmc = mmc;
> host->pdev = pdev;
> - host->is2440 = is2440;
> +
> + if (pdev->dev.of_node)
> + ret = s3cmci_probe_dt(host);
> + else
> + ret = s3cmci_probe_pdata(host);
> +
> + if (ret)
> + goto probe_free_host;
>
> host->pdata = pdev->dev.platform_data;
> if (!host->pdata) {
> @@ -1586,7 +1674,7 @@ static int s3cmci_probe(struct platform_device *pdev)
> spin_lock_init(&host->complete_lock);
> tasklet_init(&host->pio_tasklet, pio_tasklet, (unsigned long) host);
>
> - if (is2440) {
> + if (host->is2440) {
> host->sdiimsk = S3C2440_SDIIMSK;
> host->sdidata = S3C2440_SDIDATA;
> host->clk_div = 1;
> @@ -1789,8 +1877,9 @@ static int s3cmci_probe(struct platform_device *pdev)
> release_mem_region(host->mem->start, resource_size(host->mem));
>
> probe_free_gpio:
> - for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
> - gpio_free(i);
> + if (!pdev->dev.of_node)
> + for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
> + gpio_free(i);
>
> probe_free_host:
> mmc_free_host(mmc);
> @@ -1837,9 +1926,9 @@ static int s3cmci_remove(struct platform_device *pdev)
> if (!pd->no_detect)
> gpio_free(pd->gpio_detect);
>
> - for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
> - gpio_free(i);
> -
> + if (!pdev->dev.of_node)
> + for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
> + gpio_free(i);
>
> iounmap(host->base);
> release_mem_region(host->mem->start, resource_size(host->mem));
> @@ -1848,6 +1937,23 @@ static int s3cmci_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct of_device_id s3cmci_dt_match[] = {
> + {
> + .compatible = "samsung,s3c2410-sdi",
> + .data = &s3c2410_s3cmci_drv_data,
> + },
> + {
> + .compatible = "samsung,s3c2412-sdi",
> + .data = &s3c2412_s3cmci_drv_data,
> + },
> + {
> + .compatible = "samsung,s3c2440-sdi",
> + .data = &s3c2440_s3cmci_drv_data,
> + },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, sdhci_s3c_dt_match);
> +
> static const struct platform_device_id s3cmci_driver_ids[] = {
> {
> .name = "s3c2410-sdi",
> @@ -1867,6 +1973,7 @@ static int s3cmci_remove(struct platform_device *pdev)
> static struct platform_driver s3cmci_driver = {
> .driver = {
> .name = "s3c-sdi",
> + .of_match_table = s3cmci_dt_match,
> },
> .id_table = s3cmci_driver_ids,
> .probe = s3cmci_probe,
> --
> 1.9.1
>
Kind regards
Uffe
^ permalink raw reply
* [PATCH 7/8] ARM: s3c64xx: Drop initialization of unused struct s3c_audio_pdata fields
From: Krzysztof Kozlowski @ 2016-12-29 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0bb15f0e-7033-4cb3-5aba-0bb61fdfc467@samsung.com>
On Thu, Dec 29, 2016 at 11:30:49AM +0100, Sylwester Nawrocki wrote:
> On 12/28/2016 06:53 PM, Krzysztof Kozlowski wrote:
> > On Thu, Nov 10, 2016 at 04:17:55PM +0100, Sylwester Nawrocki wrote:
> >> Remove initialization of dma_{filter, playback, capture, capture_mic}
> >> fields where it is not used any more.
> >>
> >> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> >> ---
> >> arch/arm/mach-s3c64xx/dev-audio.c | 19 -------------------
> >> 1 file changed, 19 deletions(-)
> >>
> > Sylwester,
> >
> > This and 8/8 should be safe to apply, right?
>
> Yes, I think both patches can be applied safely now.
> Thanks for getting back to this.
Thanks, applied both.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433
From: Krzysztof Kozlowski @ 2016-12-29 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229084211.20442-2-andi.shyti@samsung.com>
On Thu, Dec 29, 2016 at 05:42:08PM +0900, Andi Shyti wrote:
> Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
> values used for configuration") has added a header file for defining the
> pinctrl values in order to avoid hardcoded settings in the Exynos
> DTS related files.
>
> Extend samsung.h to the Exynos5433 for drive strength values
> which are strictly related to the particular SoC and may defer
> from others.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> include/dt-bindings/pinctrl/samsung.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/dt-bindings/pinctrl/samsung.h b/include/dt-bindings/pinctrl/samsung.h
> index 6276eb785e2b..58868313d64b 100644
> --- a/include/dt-bindings/pinctrl/samsung.h
> +++ b/include/dt-bindings/pinctrl/samsung.h
> @@ -45,6 +45,12 @@
> #define EXYNOS5420_PIN_DRV_LV3 2
> #define EXYNOS5420_PIN_DRV_LV4 3
>
> +/* Drive strengths for Exynos5433 */
> +#define EXYNOS5433_PIN_DRV_LV1 0
> +#define EXYNOS5433_PIN_DRV_LV2 1
> +#define EXYNOS5433_PIN_DRV_LV3 2
> +#define EXYNOS5433_PIN_DRV_LV4 3
Same values as existing. No need to re-define these.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 4/4] ARM64: dts: exynos5433: remove unused code
From: Krzysztof Kozlowski @ 2016-12-29 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229084211.20442-5-andi.shyti@samsung.com>
On Thu, Dec 29, 2016 at 05:42:11PM +0900, Andi Shyti wrote:
> Because the pinctrl DTS is using the samsung.h macros, the
> previously pin defines are anused. Remove them.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 13 -------------
> 1 file changed, 13 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> index 9afed9fcf7e1..3c821e5c241e 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> @@ -14,19 +14,6 @@
>
> #include <dt-bindings/pinctrl/samsung.h>
>
> -#define PIN_PULL_NONE 0
> -#define PIN_PULL_DOWN 1
> -#define PIN_PULL_UP 3
> -
> -#define PIN_DRV_LV1 0
> -#define PIN_DRV_LV2 2
> -#define PIN_DRV_LV3 1
> -#define PIN_DRV_LV4 3
> -
> -#define PIN_IN 0
> -#define PIN_OUT 1
> -#define PIN_FUNC1 2
> -
This should be squashed with 3/4 because logically it is strictly
related to it and splitting it does not bring any benefits. Actually
while looking at 3/4 I was surprised to see them not removed.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] ARM: dts: qcom: apq8064: Add missing scm clock
From: Bjorn Andersson @ 2016-12-29 12:06 UTC (permalink / raw)
To: linux-arm-kernel
As per the device tree binding the apq8064 scm node requires the core
clock to be specified, so add this.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v1:
- Changed clock to Daytona Fabric
arch/arm/boot/dts/qcom-apq8064.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 1dbe697b2e90..a27cc96ac069 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -4,6 +4,7 @@
#include <dt-bindings/clock/qcom,gcc-msm8960.h>
#include <dt-bindings/reset/qcom,gcc-msm8960.h>
#include <dt-bindings/clock/qcom,mmcc-msm8960.h>
+#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/soc/qcom,gsbi.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -303,6 +304,9 @@
firmware {
scm {
compatible = "qcom,scm-apq8064";
+
+ clocks = <&rpmcc RPM_DAYTONA_FABRIC_CLK>;
+ clock-names = "core";
};
};
--
2.11.0
^ permalink raw reply related
* Linux fails to start secondary cores when system resumes from Suspend-to-RAM
From: Mason @ 2016-12-29 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8c3c6592-1e9a-10d3-2a89-c22a2a23cf4b@free.fr>
On 16/12/2016 08:25, Mason wrote:
> On 16/12/2016 06:14, Yu Chen wrote:
>
>> On Thu, Dec 15, 2016 at 11:18 PM, Mason wrote:
>>
>>> I'm playing with suspend-to-RAM on the tango platform:
>>>
>>> http://lxr.free-electrons.com/source/arch/arm/mach-tango/platsmp.c
>>>
>>> When the system is suspended, the CPU is completely powered down
>>> (receives no power whatsoever). When the system receives a wake-up
>>> event, the CPU is powered up, and starts up exactly the same way
>>> as for a cold boot (I think).
>>>
>>> However, while Linux successfully starts the secondary cores when
>>> the system first boots, it fails when the system resumes from "S3".
>>>
>>> I added printascii() calls inside secondary_start_kernel() and I can
>>> see that the following instruction are "properly" run:
>>>
>>> cpu_switch_mm(mm->pgd, mm);
>>> local_flush_bp_all();
>>> enter_lazy_tlb(mm, current);
>>>
>>> but it seems local_flush_tlb_all(); never returns... :-(
>>>
>>> http://lxr.free-electrons.com/source/arch/arm/include/asm/tlbflush.h#L332
>>>
>>>
>>> Looking more closely at that function, it seems to be failing in:
>>>
>>> tlb_op(TLB_V7_UIS_FULL, "c8, c7, 0", zero);
>>>
>>> (meaning: I get a log before, but not after)
>>>
>>> On my system, tlb_op(TLB_V7_UIS_FULL, "c8, c7, 0", zero);
>>> resolves to:
>>>
>>> c010ce18: e3170602 tst r7, #2097152 ; 0x200000
>>> c010ce1c: 1e086f17 mcrne 15, 0, r6, cr8, cr7, {0}
>>>
>>> What could be happening?
>>> Can a core "hang" on this instruction?
>>> Can a core "crash" on this instruction (meaning, an exception
>>> is raised, and the core loops inside the exception code without
>>> Linux noticing... that seems unlikely)
>>
>> try online/offline the nonboot CPUs via
>> /sys/devices/system/cpu/cpuX/online
>
> offline + online secondary core works.
>
> Note: all cores are in the same power domain, so even if all
> secondary cores are offline, the CPU block remains powered up
> (secondary cores are just held in reset, or spinning in WFI,
> depending on the firmware version).
>
> When the system is suspended, the CPU block (as well as 99%
> of the system) is powered down. Thus, upon resume, all cores
> will run the boot sequence (again).
>
> I'm guessing that something goes wrong during this second
> boot sequence. Could there be a race condition between the
> primary core and one of the secondary cores?
>
> What is different in the Linux boot sequence between cold
> boot and resume? I'm thinking that the state stored in RAM
> is in fact incompatible with what Linux expects when it resumes...
I've taken a closer look at the MCR instruction.
tlb_op(TLB_V7_UIS_FULL, "c8, c7, 0", zero);
#define tlb_op(f, regs, arg) __tlb_op(f, "p15, 0, %0, " regs, arg)
#define __tlb_op(f, insnarg, arg) \
do { \
if (always_tlb_flags & (f)) \
asm("mcr " insnarg \
: : "r" (arg) : "cc"); \
else if (possible_tlb_flags & (f)) \
asm("tst %1, %2\n\t" \
"mcrne " insnarg \
: : "r" (arg), "r" (__tlb_flag), "Ir" (f) \
: "cc"); \
} while (0)
c010dd64: e3130c12 tst r3, #4608 ; 0x1200
c010dd68: 1e081f17 mcrne 15, 0, r1, cr8, cr7, {0}
c010dd6c: e3120602 tst r2, #2097152 ; 0x200000
c010dd70: 1e081f17 mcrne 15, 0, r1, cr8, cr7, {0}
c010dd74: f57ff047 dsb un
c010dd78: f57ff06f isb sy
A8.6.92 MCR, MCR2
Move to Coprocessor from ARM core register passes the value of an ARM core register to a coprocessor.
If no coprocessor can execute the instruction, an Undefined Instruction exception is generated.
This is a generic coprocessor instruction. Some of the fields have no functionality defined by the architecture
and are free for use by the coprocessor instruction set designer. These fields are the opc1, opc2, CRn, and
CRm fields.
Operation
if ConditionPassed() then
EncodingSpecificOperations();
if !Coproc_Accepted(cp, ThisInstr()) then
GenerateCoprocessorException();
else
Coproc_SendOneWord(R[t], cp, ThisInstr());
I.7.5 Coproc_Accepted()
This function determines, for a coprocessor and one of its coprocessor instructions:
- Whether access to the coprocessor is permitted by the CPACR and, if the Security Extensions are
implemented, the NSACR.
- If access is permitted, whether the instruction is accepted by the coprocessor. The coprocessor
architecture definition specifies which instructions it accepts and in what circumstances.
It returns TRUE if access is permitted and the coprocessor accepts the instruction, and FALSE otherwise.
boolean Coproc_Accepted(integer cp_num, bits(32) instr)
I.7.17 GenerateCoprocessorException()
This procedure generates the appropriate exception for a rejected coprocessor instruction.
In all architecture variants and profiles described in this manual, GenerateCoprocessorException() generates
an Undefined Instruction exception.
Assuming I'm hitting this, I would expect the kernel to print something
if the secondary cores trigger an exception. Am I mistaken?
mov r1, #0
mcrne 15, 0, r1, cr8, cr7, {0}
B3.12.34 CP15 c8, TLB maintenance operations
On ARMv7-A implementations, CP15 c8 operations are used for TLB maintenance functions. Figure B3-20
shows the CP15 c8 encodings.
TLBIALL*, invalidate unified TLB
* See text for more information about these mnemonics
Invalidate entire unified TLB
(When separate instruction and data TLBs are implemented,
these operations are performed on both TLBs.)
Rt data = Ignore
Invalidate entire TLB
The Invalidate entire TLB operations invalidate all unlocked entries in the TLB. The value in the register Rt
specified by the MCR instruction used to perform the operation is ignored. You do not have to write a value
to the register before issuing the MCR instruction.
Maybe this is a red herring... I don't see why the TLBIALL would
raise an exception when the system resumes... I first suspected
TrustZone shenanigans, but it looks like TLBIALL just flushes
what it can, so TrustZone seems to be a non-issue.
I'm stumped... Still looking for a clue :-(
Maybe I should instrument the exception handler...
if I only knew where it was.
Regards.
^ permalink raw reply
* [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Ard Biesheuvel @ 2016-12-29 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229022348.GA13402@gondor.apana.org.au>
On 29 December 2016 at 02:23, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Dec 28, 2016 at 07:50:44PM +0000, Ard Biesheuvel wrote:
>>
>> So about this chunksize, is it ever expected to assume other values
>> than 1 (for stream ciphers) or the block size (for block ciphers)?
>> Having block size, IV size *and* chunk size fields may be confusing to
>> some already, so if the purpose of chunk size can be fulfilled by a
>> single 'stream cipher' flag, perhaps we should change that first.
>
> For users (such as algif) it's much more convenient to have a size
> rather than a flag because that's what they need to determine the
> minimum size for partial updates.
>
> For implementors you don't need to specify the chunksize at all
> unless you're a stream cipher (or some other case in future where
> the minimum partial update size is not equal to your block size).
>
OK, fair enough. So I will add a field 'walksize' to the skcipher_alg
struct in my proposal. I think the walk logic itself needs to change
very little, though: we can simply set the walk's chunksize to the
skcipher's walksize if it exceeds its chunksize (and walksize %
chunksize should be 0 in any case, and walksize should default to the
chunksize if not supplied)
If this sounds reasonable to you, I will hack something up next week.
^ permalink raw reply
* [PATCH] ARM: s3c2410_defconfig: Fix invalid values for NF_CT_PROTO_*
From: Krzysztof Kozlowski @ 2016-12-29 12:41 UTC (permalink / raw)
To: linux-arm-kernel
NF_CT_PROTO_DCCP/SCTP/UDPLITE were switched from tristate to boolean so
defconfig needs to be adjusted to silence warnings:
warning: symbol value 'm' invalid for NF_CT_PROTO_DCCP
warning: symbol value 'm' invalid for NF_CT_PROTO_SCTP
warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/configs/s3c2410_defconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/configs/s3c2410_defconfig b/arch/arm/configs/s3c2410_defconfig
index 4364040ed696..1e6c48dd7b11 100644
--- a/arch/arm/configs/s3c2410_defconfig
+++ b/arch/arm/configs/s3c2410_defconfig
@@ -86,9 +86,9 @@ CONFIG_IPV6_TUNNEL=m
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_EVENTS=y
-CONFIG_NF_CT_PROTO_DCCP=m
-CONFIG_NF_CT_PROTO_SCTP=m
-CONFIG_NF_CT_PROTO_UDPLITE=m
+CONFIG_NF_CT_PROTO_DCCP=y
+CONFIG_NF_CT_PROTO_SCTP=y
+CONFIG_NF_CT_PROTO_UDPLITE=y
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
--
2.9.3
^ permalink raw reply related
* [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
From: ayaka @ 2016-12-29 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04b667d9-2591-51ff-e024-047bbb6e17c3@rock-chips.com>
[ 5.849733] rk_gmac-dwmac ff290000.ethernet (unnamed net_device)
(uninitialized): Enable RX Mitigation via HW Watchdog Timer
[ 5.944512] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req
50000000Hz, actual 50000000HZ div = 0)
[ 5.958249] mmc1: new ultra high speed DDR50 SDIO card at address 0001
[ 6.294548] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase
to 177
[ 6.301591] mmc2: new HS200 MMC card at address 0001
[ 6.306758] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req
300000Hz, actual 300000HZ div = 0)
[ 6.316830] mmcblk2: mmc2:0001 AGND3R 14.6 GiB
[ 6.321881] mmcblk2boot0: mmc2:0001 AGND3R partition 1 4.00 MiB
[ 6.328331] mmcblk2boot1: mmc2:0001 AGND3R partition 2 4.00 MiB
[ 6.334792] mmcblk2rpmb: mmc2:0001 AGND3R partition 3 4.00 MiB
[ 6.344295] mmcblk2: p1 p2 p3 p4 p5 p6 p7
[ 6.469892] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req
200000Hz, actual 200000HZ div = 0)
[ 6.621888] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req
100000Hz, actual 93750HZ div = 1)
[ 6.917883] libphy: stmmac: probed
[ 6.921319] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at
0 IRQ POLL (stmmac-0:00) active
[ 6.930476] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at
2 IRQ POLL (stmmac-0:02)
[ 6.939757] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[ 6.946937] rtc-hym8563 0-0051: no valid clock/calendar values available
[ 6.953694] rtc-hym8563 0-0051: hctosys: unable to read the hardware
clock
[ 6.961262] vcc_sd: disabling
[ 6.964275] dovdd_1v8: disabling
[ 6.967527] dvdd_1v2: disabling
[ 6.971006] vdd10_lcd: disabling
[ 6.974701] vcc18_lcd: disabling
[ 6.978467] ttyS2 - failed to request DMA
[ 7.101883] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[ 7.253874] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req
300000Hz, actual 300000HZ div = 0)
[ 7.405883] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req
200000Hz, actual 200000HZ div = 0)
[ 7.557885] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req
100000Hz, actual 93750HZ div = 1)
[ 8.037872] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[ 8.189877] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req
300000Hz, actual 300000HZ div = 0)
[ 8.341881] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req
200000Hz, actual 200000HZ div = 0)
[ 8.493884] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req
100000Hz, actual 93750HZ div = 1)
[ 8.973871] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[ 9.125876] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req
300000Hz, actual 300000HZ div = 0)
[ 9.277884] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req
200000Hz, actual 200000HZ div = 0)
[ 9.429882] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req
100000Hz, actual 93750HZ div = 1)
looping here
If I revert that patch, there are still lots of Bus speed messages, but
finally would enter into system.
On 12/29/2016 06:25 PM, Randy Li wrote:
>
>
> On 12/29/2016 03:25 PM, Shawn Lin wrote:
>> On 2016/12/29 15:13, Jaehoon Chung wrote:
>>> On 12/29/2016 12:02 PM, Jaehoon Chung wrote:
>>>> Hi Randy,
>>>>
>>>> On 12/29/2016 12:34 AM, Randy Li wrote:
>>>>> This reverts commit f90142683f04bcb0729bf0df67a5e29562b725b9.
>>>>> It is reported that making RK3288 can't boot from eMMC/MMC.
>>>>
>>>> Could you explain in more detail?
>>>> As you mentioned, this patch is making that RK3288 can't boot..then
>>>> why?
>>>> Good way should be that finds the main reason and fixes it.
>>>> Not just revert.
>>>
>>> To Shawn,
>>>
>>> Could you check this? If you have rk3288..
>>> If it's not working fine, it needs to revert this patch until finding
>>> the problem.
>>>
>>
>> Hrmm.....as that patchset was tested based on rk3288 and rk3368, so I
>> need to know which board Randy are using now and could you share some
> Sorry, XZY has asked me about this in the morning and I answer him
> that I would give a feedback at home, so I didn't notice this mail.
> The board is Firefly reload. but the reporter told me that Firefly
> release also have the same problem.
>> log?
>>
>> I will have a look at it.
>>
>>
>>> Best Regards,
>>> Jaehoon Chung
>>>
>>>>
>>>> Best Regards,
>>>> Jaehoon Chung
>>>>
>>>>>
>>>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>>>> ---
>>>>> drivers/mmc/host/dw_mmc-rockchip.c | 41
>>>>> +++-----------------------------------
>>>>> 1 file changed, 3 insertions(+), 38 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>> b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>> index 9a46e46..3189234 100644
>>>>> --- a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>> +++ b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>> @@ -14,7 +14,6 @@
>>>>> #include <linux/mmc/dw_mmc.h>
>>>>> #include <linux/of_address.h>
>>>>> #include <linux/mmc/slot-gpio.h>
>>>>> -#include <linux/pm_runtime.h>
>>>>> #include <linux/slab.h>
>>>>>
>>>>> #include "dw_mmc.h"
>>>>> @@ -327,7 +326,6 @@ static int dw_mci_rockchip_probe(struct
>>>>> platform_device *pdev)
>>>>> {
>>>>> const struct dw_mci_drv_data *drv_data;
>>>>> const struct of_device_id *match;
>>>>> - int ret;
>>>>>
>>>>> if (!pdev->dev.of_node)
>>>>> return -ENODEV;
>>>>> @@ -335,49 +333,16 @@ static int dw_mci_rockchip_probe(struct
>>>>> platform_device *pdev)
>>>>> match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
>>>>> drv_data = match->data;
>>>>>
>>>>> - pm_runtime_get_noresume(&pdev->dev);
>>>>> - pm_runtime_set_active(&pdev->dev);
>>>>> - pm_runtime_enable(&pdev->dev);
>>>>> - pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
>>>>> - pm_runtime_use_autosuspend(&pdev->dev);
>>>>> -
>>>>> - ret = dw_mci_pltfm_register(pdev, drv_data);
>>>>> - if (ret) {
>>>>> - pm_runtime_disable(&pdev->dev);
>>>>> - pm_runtime_set_suspended(&pdev->dev);
>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>> - return ret;
>>>>> - }
>>>>> -
>>>>> - pm_runtime_put_autosuspend(&pdev->dev);
>>>>> -
>>>>> - return 0;
>>>>> + return dw_mci_pltfm_register(pdev, drv_data);
>>>>> }
>>>>>
>>>>> -static int dw_mci_rockchip_remove(struct platform_device *pdev)
>>>>> -{
>>>>> - pm_runtime_get_sync(&pdev->dev);
>>>>> - pm_runtime_disable(&pdev->dev);
>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>> -
>>>>> - return dw_mci_pltfm_remove(pdev);
>>>>> -}
>>>>> -
>>>>> -static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
>>>>> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>>>>> - pm_runtime_force_resume)
>>>>> - SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
>>>>> - dw_mci_runtime_resume,
>>>>> - NULL)
>>>>> -};
>>>>> -
>>>>> static struct platform_driver dw_mci_rockchip_pltfm_driver = {
>>>>> .probe = dw_mci_rockchip_probe,
>>>>> - .remove = dw_mci_rockchip_remove,
>>>>> + .remove = dw_mci_pltfm_remove,
>>>>> .driver = {
>>>>> .name = "dwmmc_rockchip",
>>>>> .of_match_table = dw_mci_rockchip_match,
>>>>> - .pm = &dw_mci_rockchip_dev_pm_ops,
>>>>> + .pm = &dw_mci_pltfm_pmops,
>>>>> },
>>>>> };
>>>>>
>>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-mmc" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>> .
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
^ permalink raw reply
* [PATCH 0/2] ARM: add Exynos4412 Prime SoC support
From: Bartlomiej Zolnierkiewicz @ 2016-12-29 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161229133722epcas5p1e138af585fea93a42962f3a7414a081f@epcas5p1.samsung.com>
Hi,
This patchset adds support for Exynos4412 Prime SoC (it supports
additional 1704MHz & 1600MHz CPU OPPs and 1500MHz CPU OPP is just
a regular non-turbo OPP on this SoC).
ODROID-X2/U2/U3 boards use Exynos4412 Prime SoC version so their
board files are updated accordingly.
This patchset brings 21% CPU performance increase on affected
boards (as tested on ODROID-U3 board).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Bartlomiej Zolnierkiewicz (2):
clk: samsung: exynos4412: add cpu clock configuration data for
Exynos4412 Prime
ARM: dts: Add CPU OPPs for Exynos4412 Prime
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +--
arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +--
arch/arm/boot/dts/exynos4412-odroidx2.dts | 1 +
arch/arm/boot/dts/exynos4412-prime.dtsi | 41 +++++++++++++++++++++++++
arch/arm/boot/dts/exynos4412.dtsi | 2 +-
drivers/clk/samsung/clk-exynos4.c | 4 +++
6 files changed, 52 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] clk: samsung: exynos4412: add cpu clock configuration data for Exynos4412 Prime
From: Bartlomiej Zolnierkiewicz @ 2016-12-29 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483018611-27998-1-git-send-email-b.zolnierkie@samsung.com>
Add cpu clock configuration data for Exynos4412 Prime SoC
(it supports additional PLL rates & CPU frequencies).
Based on Hardkernel's kernel for ODROID-X2/U2/U3 boards.
Cc: Doug Anderson <dianders@chromium.org>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Cc: Ben Gamari <ben@smart-cactus.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
drivers/clk/samsung/clk-exynos4.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index faab9b3..e40b775 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -1298,6 +1298,8 @@ static void __init exynos4_clk_register_finpll(struct samsung_clk_provider *ctx)
};
static const struct samsung_pll_rate_table exynos4x12_apll_rates[] __initconst = {
+ PLL_35XX_RATE(1704000000, 213, 3, 0),
+ PLL_35XX_RATE(1600000000, 200, 3, 0),
PLL_35XX_RATE(1500000000, 250, 4, 0),
PLL_35XX_RATE(1400000000, 175, 3, 0),
PLL_35XX_RATE(1300000000, 325, 6, 0),
@@ -1421,6 +1423,8 @@ static void __init exynos4x12_core_down_clock(void)
(((cores) << 8) | ((hpm) << 4) | ((copy) << 0))
static const struct exynos_cpuclk_cfg_data e4412_armclk_d[] __initconst = {
+ { 1704000, E4210_CPU_DIV0(2, 1, 6, 0, 7, 3), E4412_CPU_DIV1(7, 0, 7), },
+ { 1600000, E4210_CPU_DIV0(2, 1, 6, 0, 7, 3), E4412_CPU_DIV1(7, 0, 6), },
{ 1500000, E4210_CPU_DIV0(2, 1, 6, 0, 7, 3), E4412_CPU_DIV1(7, 0, 6), },
{ 1400000, E4210_CPU_DIV0(2, 1, 6, 0, 7, 3), E4412_CPU_DIV1(6, 0, 6), },
{ 1300000, E4210_CPU_DIV0(2, 1, 5, 0, 7, 3), E4412_CPU_DIV1(6, 0, 5), },
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: Add CPU OPPs for Exynos4412 Prime
From: Bartlomiej Zolnierkiewicz @ 2016-12-29 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483018611-27998-1-git-send-email-b.zolnierkie@samsung.com>
Add CPU operating points for Exynos4412 Prime (it supports
additional 1704MHz & 1600MHz OPPs and 1500MHz OPP is just
a regular non-turbo OPP on this SoC). Also update relevant
cooling maps to account for new OPPs.
ODROID-X2/U2/U3 boards use Exynos4412 Prime SoC version so
update their board files accordingly.
Based on Hardkernel's kernel for ODROID-X2/U2/U3 boards.
Cc: Doug Anderson <dianders@chromium.org>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Cc: Ben Gamari <ben@smart-cactus.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +--
arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +--
arch/arm/boot/dts/exynos4412-odroidx2.dts | 1 +
arch/arm/boot/dts/exynos4412-prime.dtsi | 41 +++++++++++++++++++++++++
arch/arm/boot/dts/exynos4412.dtsi | 2 +-
5 files changed, 48 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 8aa19ba..5282d69e 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -97,11 +97,11 @@
thermal-zones {
cpu_thermal: cpu-thermal {
cooling-maps {
- map0 {
+ cooling_map0: map0 {
/* Corresponds to 800MHz at freq_table */
cooling-device = <&cpu0 7 7>;
};
- map1 {
+ cooling_map1: map1 {
/* Corresponds to 200MHz at freq_table */
cooling-device = <&cpu0 13 13>;
};
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 99634c5..7504a5a 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -13,6 +13,7 @@
/dts-v1/;
#include "exynos4412-odroid-common.dtsi"
+#include "exynos4412-prime.dtsi"
/ {
model = "Hardkernel ODROID-U3 board based on Exynos4412";
@@ -47,11 +48,11 @@
cooling-maps {
map0 {
trip = <&cpu_alert1>;
- cooling-device = <&cpu0 7 7>;
+ cooling-device = <&cpu0 9 9>;
};
map1 {
trip = <&cpu_alert2>;
- cooling-device = <&cpu0 13 13>;
+ cooling-device = <&cpu0 15 15>;
};
map2 {
trip = <&cpu_alert0>;
diff --git a/arch/arm/boot/dts/exynos4412-odroidx2.dts b/arch/arm/boot/dts/exynos4412-odroidx2.dts
index 4d22885..d6e92ebc 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx2.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx2.dts
@@ -12,6 +12,7 @@
*/
#include "exynos4412-odroidx.dts"
+#include "exynos4412-prime.dtsi"
/ {
model = "Hardkernel ODROID-X2 board based on Exynos4412";
diff --git a/arch/arm/boot/dts/exynos4412-prime.dtsi b/arch/arm/boot/dts/exynos4412-prime.dtsi
new file mode 100644
index 0000000..e75bc17
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-prime.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Samsung's Exynos4412 Prime SoC device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Exynos4412 Prime SoC revision supports higher CPU frequencies than
+ * non-Prime version. Therefore we need to update OPPs table and
+ * thermal maps accordingly.
+ */
+
+&cpu0_opp_1500 {
+ /delete-property/turbo-mode;
+};
+
+&cpu0_opp_table {
+ opp at 1600000000 {
+ opp-hz = /bits/ 64 <1600000000>;
+ opp-microvolt = <1350000>;
+ clock-latency-ns = <200000>;
+ };
+ opp at 1704000000 {
+ opp-hz = /bits/ 64 <1704000000>;
+ opp-microvolt = <1350000>;
+ clock-latency-ns = <200000>;
+ };
+};
+
+&cooling_map0 {
+ cooling-device = <&cpu0 9 9>;
+};
+
+&cooling_map1 {
+ cooling-device = <&cpu0 15 15>;
+};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 40beede..3ebdf01 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -130,7 +130,7 @@
opp-microvolt = <1287500>;
clock-latency-ns = <200000>;
};
- opp at 1500000000 {
+ cpu0_opp_1500: opp at 1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433
From: Andi Shyti @ 2016-12-29 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229115059.ncvtakz32vhcfsij@kozik-lap>
Hi Krzysztof,
> > #define EXYNOS5420_PIN_DRV_LV3 2
> > #define EXYNOS5420_PIN_DRV_LV4 3
> >
> > +/* Drive strengths for Exynos5433 */
> > +#define EXYNOS5433_PIN_DRV_LV1 0
> > +#define EXYNOS5433_PIN_DRV_LV2 1
> > +#define EXYNOS5433_PIN_DRV_LV3 2
> > +#define EXYNOS5433_PIN_DRV_LV4 3
>
> Same values as existing. No need to re-define these.
Yes, I was in doubt when I prepared this patch as on one hand it
didn't look right to use EXYNOS5420_* for exynos5433, on the other
hand it didn't look right to duplicate the macros.
In anycase this values need to be fixed as Chanwoo wrote in the
other mail.
Thanks,
Andi
^ permalink raw reply
* [PATCH 4/4] ARM64: dts: exynos5433: remove unused code
From: Andi Shyti @ 2016-12-29 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229115421.pq52ab57e53xntoz@kozik-lap>
> > #include <dt-bindings/pinctrl/samsung.h>
> >
> > -#define PIN_PULL_NONE 0
> > -#define PIN_PULL_DOWN 1
> > -#define PIN_PULL_UP 3
> > -
> > -#define PIN_DRV_LV1 0
> > -#define PIN_DRV_LV2 2
> > -#define PIN_DRV_LV3 1
> > -#define PIN_DRV_LV4 3
> > -
> > -#define PIN_IN 0
> > -#define PIN_OUT 1
> > -#define PIN_FUNC1 2
> > -
>
> This should be squashed with 3/4 because logically it is strictly
> related to it and splitting it does not bring any benefits. Actually
> while looking at 3/4 I was surprised to see them not removed.
Yes, right :)
Thanks,
Andi
^ permalink raw reply
* [PATCH 0/4] video/exynos/cec: add HDMI state notifier & use in s5p-cec
From: Marek Szyprowski @ 2016-12-29 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213150813.37966-1-hverkuil@xs4all.nl>
Hi Hans,
On 2016-12-13 16:08, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> This patch series adds the HDMI notifier code, based on Russell's code:
>
> https://patchwork.kernel.org/patch/9277043/
>
> It adds support for it to the exynos_hdmi drm driver, adds support for
> it to the CEC framework and finally adds support to the s5p-cec driver,
> which now can be moved out of staging.
>
> Tested with my Odroid U3 exynos4 devboard.
>
> Comments are welcome. I'd like to get this in for the 4.11 kernel as
> this is a missing piece needed to integrate CEC drivers.
>
> Benjamin, can you look at doing the same notifier integration for your
> st-cec driver as is done for s5p-cec? It would be good to be able to
> move st-cec out of staging at the same time.
Thanks for working on this and taking it from by TODO list! :)
Please add:
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
If you plan to send an updated version, please send it also to
linux-samsung-soc at vger.kernel.org, Krzysztof and Inki to get their acks
for the bindings, dtsi and drm parts.
This HDMI notifier framework will probably be also useful for integrating
HDMI audio support for Samsung ASoC driver.
> Regards,
>
> Hans
>
> Hans Verkuil (4):
> video: add HDMI state notifier support
> exynos_hdmi: add HDMI notifier support
> cec: integrate HDMI notifier support
> s5p-cec: add hdmi-notifier support, move out of staging
>
> .../devicetree/bindings/media/s5p-cec.txt | 2 +
> arch/arm/boot/dts/exynos4.dtsi | 1 +
> drivers/gpu/drm/exynos/Kconfig | 1 +
> drivers/gpu/drm/exynos/exynos_hdmi.c | 24 +++-
> drivers/media/cec/cec-core.c | 50 ++++++++
> drivers/media/platform/Kconfig | 18 +++
> drivers/media/platform/Makefile | 1 +
> .../media => media/platform}/s5p-cec/Makefile | 0
> .../platform}/s5p-cec/exynos_hdmi_cec.h | 0
> .../platform}/s5p-cec/exynos_hdmi_cecctrl.c | 0
> .../media => media/platform}/s5p-cec/regs-cec.h | 0
> .../media => media/platform}/s5p-cec/s5p_cec.c | 35 +++++-
> .../media => media/platform}/s5p-cec/s5p_cec.h | 3 +
> drivers/staging/media/Kconfig | 2 -
> drivers/staging/media/Makefile | 1 -
> drivers/staging/media/s5p-cec/Kconfig | 9 --
> drivers/staging/media/s5p-cec/TODO | 7 --
> drivers/video/Kconfig | 3 +
> drivers/video/Makefile | 1 +
> drivers/video/hdmi-notifier.c | 134 +++++++++++++++++++++
> include/linux/hdmi-notifier.h | 109 +++++++++++++++++
> include/media/cec.h | 15 +++
> 22 files changed, 389 insertions(+), 27 deletions(-)
> rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
> rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
> delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
> delete mode 100644 drivers/staging/media/s5p-cec/TODO
> create mode 100644 drivers/video/hdmi-notifier.c
> create mode 100644 include/linux/hdmi-notifier.h
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
From: Jaehoon Chung @ 2016-12-29 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6ccade72-ae20-2ffa-1504-2536b9f03adf@soulik.info>
Hi,
On 12/29/2016 09:55 PM, ayaka wrote:
> [ 5.849733] rk_gmac-dwmac ff290000.ethernet (unnamed net_device) (uninitialized): Enable RX Mitigation via HW Watchdog Timer
> [ 5.944512] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
> [ 5.958249] mmc1: new ultra high speed DDR50 SDIO card at address 0001
> [ 6.294548] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 177
> [ 6.301591] mmc2: new HS200 MMC card at address 0001
> [ 6.306758] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
> [ 6.316830] mmcblk2: mmc2:0001 AGND3R 14.6 GiB
> [ 6.321881] mmcblk2boot0: mmc2:0001 AGND3R partition 1 4.00 MiB
> [ 6.328331] mmcblk2boot1: mmc2:0001 AGND3R partition 2 4.00 MiB
> [ 6.334792] mmcblk2rpmb: mmc2:0001 AGND3R partition 3 4.00 MiB
> [ 6.344295] mmcblk2: p1 p2 p3 p4 p5 p6 p7
> [ 6.469892] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
> [ 6.621888] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
> [ 6.917883] libphy: stmmac: probed
> [ 6.921319] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
> [ 6.930476] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at 2 IRQ POLL (stmmac-0:02)
> [ 6.939757] input: gpio-keys as /devices/platform/gpio-keys/input/input0
> [ 6.946937] rtc-hym8563 0-0051: no valid clock/calendar values available
> [ 6.953694] rtc-hym8563 0-0051: hctosys: unable to read the hardware clock
> [ 6.961262] vcc_sd: disabling
> [ 6.964275] dovdd_1v8: disabling
> [ 6.967527] dvdd_1v2: disabling
> [ 6.971006] vdd10_lcd: disabling
> [ 6.974701] vcc18_lcd: disabling
> [ 6.978467] ttyS2 - failed to request DMA
> [ 7.101883] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
> [ 7.253874] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
> [ 7.405883] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
> [ 7.557885] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
> [ 8.037872] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
> [ 8.189877] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
> [ 8.341881] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
> [ 8.493884] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
> [ 8.973871] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
> [ 9.125876] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
> [ 9.277884] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
> [ 9.429882] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
>
> looping here
>
> If I revert that patch, there are still lots of Bus speed messages, but finally would enter into system.
>
Plz..Don't put the comment on the top.
Which kernel did you use?
>
> On 12/29/2016 06:25 PM, Randy Li wrote:
>>
>>
>> On 12/29/2016 03:25 PM, Shawn Lin wrote:
>>> On 2016/12/29 15:13, Jaehoon Chung wrote:
>>>> On 12/29/2016 12:02 PM, Jaehoon Chung wrote:
>>>>> Hi Randy,
>>>>>
>>>>> On 12/29/2016 12:34 AM, Randy Li wrote:
>>>>>> This reverts commit f90142683f04bcb0729bf0df67a5e29562b725b9.
>>>>>> It is reported that making RK3288 can't boot from eMMC/MMC.
>>>>>
>>>>> Could you explain in more detail?
>>>>> As you mentioned, this patch is making that RK3288 can't boot..then why?
>>>>> Good way should be that finds the main reason and fixes it.
>>>>> Not just revert.
>>>>
>>>> To Shawn,
>>>>
>>>> Could you check this? If you have rk3288..
>>>> If it's not working fine, it needs to revert this patch until finding
>>>> the problem.
>>>>
>>>
>>> Hrmm.....as that patchset was tested based on rk3288 and rk3368, so I
>>> need to know which board Randy are using now and could you share some
>> Sorry, XZY has asked me about this in the morning and I answer him that I would give a feedback at home, so I didn't notice this mail.
>> The board is Firefly reload. but the reporter told me that Firefly release also have the same problem.
>>> log?
>>>
>>> I will have a look at it.
>>>
>>>
>>>> Best Regards,
>>>> Jaehoon Chung
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Jaehoon Chung
>>>>>
>>>>>>
>>>>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>>>>> ---
>>>>>> drivers/mmc/host/dw_mmc-rockchip.c | 41
>>>>>> +++-----------------------------------
>>>>>> 1 file changed, 3 insertions(+), 38 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>> b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>> index 9a46e46..3189234 100644
>>>>>> --- a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>> +++ b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>> @@ -14,7 +14,6 @@
>>>>>> #include <linux/mmc/dw_mmc.h>
>>>>>> #include <linux/of_address.h>
>>>>>> #include <linux/mmc/slot-gpio.h>
>>>>>> -#include <linux/pm_runtime.h>
>>>>>> #include <linux/slab.h>
>>>>>>
>>>>>> #include "dw_mmc.h"
>>>>>> @@ -327,7 +326,6 @@ static int dw_mci_rockchip_probe(struct
>>>>>> platform_device *pdev)
>>>>>> {
>>>>>> const struct dw_mci_drv_data *drv_data;
>>>>>> const struct of_device_id *match;
>>>>>> - int ret;
>>>>>>
>>>>>> if (!pdev->dev.of_node)
>>>>>> return -ENODEV;
>>>>>> @@ -335,49 +333,16 @@ static int dw_mci_rockchip_probe(struct
>>>>>> platform_device *pdev)
>>>>>> match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
>>>>>> drv_data = match->data;
>>>>>>
>>>>>> - pm_runtime_get_noresume(&pdev->dev);
>>>>>> - pm_runtime_set_active(&pdev->dev);
>>>>>> - pm_runtime_enable(&pdev->dev);
>>>>>> - pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
>>>>>> - pm_runtime_use_autosuspend(&pdev->dev);
>>>>>> -
>>>>>> - ret = dw_mci_pltfm_register(pdev, drv_data);
>>>>>> - if (ret) {
>>>>>> - pm_runtime_disable(&pdev->dev);
>>>>>> - pm_runtime_set_suspended(&pdev->dev);
>>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>>> - return ret;
>>>>>> - }
>>>>>> -
>>>>>> - pm_runtime_put_autosuspend(&pdev->dev);
>>>>>> -
>>>>>> - return 0;
>>>>>> + return dw_mci_pltfm_register(pdev, drv_data);
>>>>>> }
>>>>>>
>>>>>> -static int dw_mci_rockchip_remove(struct platform_device *pdev)
>>>>>> -{
>>>>>> - pm_runtime_get_sync(&pdev->dev);
>>>>>> - pm_runtime_disable(&pdev->dev);
>>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>>> -
>>>>>> - return dw_mci_pltfm_remove(pdev);
>>>>>> -}
>>>>>> -
>>>>>> -static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
>>>>>> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>>>>>> - pm_runtime_force_resume)
>>>>>> - SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
>>>>>> - dw_mci_runtime_resume,
>>>>>> - NULL)
>>>>>> -};
>>>>>> -
>>>>>> static struct platform_driver dw_mci_rockchip_pltfm_driver = {
>>>>>> .probe = dw_mci_rockchip_probe,
>>>>>> - .remove = dw_mci_rockchip_remove,
>>>>>> + .remove = dw_mci_pltfm_remove,
>>>>>> .driver = {
>>>>>> .name = "dwmmc_rockchip",
>>>>>> .of_match_table = dw_mci_rockchip_match,
>>>>>> - .pm = &dw_mci_rockchip_dev_pm_ops,
>>>>>> + .pm = &dw_mci_pltfm_pmops,
>>>>>> },
>>>>>> };
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>>> the body of a message to majordomo at vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
^ permalink raw reply
* [PATCH v2] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Krzysztof Kozlowski @ 2016-12-29 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=Wo273T20fe8D2v5Pn1HYR==7PHtr7WZGwzFPRspAYPzg@mail.gmail.com>
On Thu, Dec 15, 2016 at 04:54:30PM -0800, Doug Anderson wrote:
> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.365955950 +0100
> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.361955949 +0100
> > @@ -24,6 +24,16 @@
> > };
> >
> > &cluster_a15_opp_table {
> > + opp at 2000000000 {
> > + opp-hz = /bits/ 64 <2000000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > + opp at 1900000000 {
> > + opp-hz = /bits/ 64 <1900000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
>
> I don't think the voltages you listed are high enough for all peach pi
> boards for A15 at 1.9 GHz and 2.0 GHz, at least based on the research
> I did. See my response to v1.
I wanted to apply this but saw this remaining issue. Javier tested it
on Peach Pi so is this concern still valid?
Bartlomiej,
When sending dts patches please stick to the common subsystem prefix
(git log --oneline arch/arm/boot/dts/exynos*).
Best regards,
Krzysztof
^ permalink raw reply
* Linux fails to start secondary cores when system resumes from Suspend-to-RAM
From: Mason @ 2016-12-29 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9134f2dd-73f6-73d5-30a0-3129d5440d0a@free.fr>
On Thu, Dec 15, 2016 at 11:18 PM, Mason wrote:
> However, while Linux successfully starts the secondary cores when
> the system first boots, it fails when the system resumes from "S3".
Oh boy...
Turns out the firmware was, in fact, (upon resume) stomping over parts
of the Linux memory image in RAM, triggering all kinds of "interesting"
nasal demons when Linux ran (or, more accurately, limped).
The guilty party will be properly dealt with. (Where's my foam bat?)
Regards.
^ permalink raw reply
* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Sinan Kaya @ 2016-12-29 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <586072E9.3060609@huawei.com>
On 12/25/2016 8:31 PM, Hanjun Guo wrote:
>> A type->setup() would be somewhat cleaner I think, but then it's more
>> code. Whichever works better I guess. :-)
> Agree, I will demo the type->setup() way and send out the patch for review,
> also I find one minor issue for the IORT code, will update that also for next
> version.
Can you provide details on what the minor issue is with the IORT code?
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Add CPU OPPs for Exynos4412 Prime
From: Krzysztof Kozlowski @ 2016-12-29 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483018611-27998-3-git-send-email-b.zolnierkie@samsung.com>
On Thu, Dec 29, 2016 at 02:36:51PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Add CPU operating points for Exynos4412 Prime (it supports
> additional 1704MHz & 1600MHz OPPs and 1500MHz OPP is just
> a regular non-turbo OPP on this SoC). Also update relevant
> cooling maps to account for new OPPs.
>
> ODROID-X2/U2/U3 boards use Exynos4412 Prime SoC version so
> update their board files accordingly.
>
> Based on Hardkernel's kernel for ODROID-X2/U2/U3 boards.
>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Andreas Faerber <afaerber@suse.de>
> Cc: Thomas Abraham <thomas.ab@samsung.com>
> Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> Cc: Ben Gamari <ben@smart-cactus.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +--
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +--
> arch/arm/boot/dts/exynos4412-odroidx2.dts | 1 +
> arch/arm/boot/dts/exynos4412-prime.dtsi | 41 +++++++++++++++++++++++++
> arch/arm/boot/dts/exynos4412.dtsi | 2 +-
> 5 files changed, 48 insertions(+), 5 deletions(-)
> create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
>
Looks okay. Is the clock patch needed for this?
BR,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Add CPU OPPs for Exynos4412 Prime
From: Bartlomiej Zolnierkiewicz @ 2016-12-29 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229144908.6gkvjpso7ikdmfp7@kozik-lap>
Hi,
On Thursday, December 29, 2016 04:49:08 PM Krzysztof Kozlowski wrote:
> On Thu, Dec 29, 2016 at 02:36:51PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > Add CPU operating points for Exynos4412 Prime (it supports
> > additional 1704MHz & 1600MHz OPPs and 1500MHz OPP is just
> > a regular non-turbo OPP on this SoC). Also update relevant
> > cooling maps to account for new OPPs.
> >
> > ODROID-X2/U2/U3 boards use Exynos4412 Prime SoC version so
> > update their board files accordingly.
> >
> > Based on Hardkernel's kernel for ODROID-X2/U2/U3 boards.
> >
> > Cc: Doug Anderson <dianders@chromium.org>
> > Cc: Andreas Faerber <afaerber@suse.de>
> > Cc: Thomas Abraham <thomas.ab@samsung.com>
> > Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> > Cc: Ben Gamari <ben@smart-cactus.org>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > ---
> > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +--
> > arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +--
> > arch/arm/boot/dts/exynos4412-odroidx2.dts | 1 +
> > arch/arm/boot/dts/exynos4412-prime.dtsi | 41 +++++++++++++++++++++++++
> > arch/arm/boot/dts/exynos4412.dtsi | 2 +-
> > 5 files changed, 48 insertions(+), 5 deletions(-)
> > create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
> >
>
> Looks okay. Is the clock patch needed for this?
Yep.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
From: ayaka @ 2016-12-29 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95648282-38f5-42c2-fd8b-ab603eb3a168@gmail.com>
On 12/29/2016 10:04 PM, Jaehoon Chung wrote:
> Hi,
>
> On 12/29/2016 09:55 PM, ayaka wrote:
>> [ 5.849733] rk_gmac-dwmac ff290000.ethernet (unnamed net_device) (uninitialized): Enable RX Mitigation via HW Watchdog Timer
>> [ 5.944512] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
>> [ 5.958249] mmc1: new ultra high speed DDR50 SDIO card at address 0001
>> [ 6.294548] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 177
>> [ 6.301591] mmc2: new HS200 MMC card at address 0001
>> [ 6.306758] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
>> [ 6.316830] mmcblk2: mmc2:0001 AGND3R 14.6 GiB
>> [ 6.321881] mmcblk2boot0: mmc2:0001 AGND3R partition 1 4.00 MiB
>> [ 6.328331] mmcblk2boot1: mmc2:0001 AGND3R partition 2 4.00 MiB
>> [ 6.334792] mmcblk2rpmb: mmc2:0001 AGND3R partition 3 4.00 MiB
>> [ 6.344295] mmcblk2: p1 p2 p3 p4 p5 p6 p7
>> [ 6.469892] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
>> [ 6.621888] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
>> [ 6.917883] libphy: stmmac: probed
>> [ 6.921319] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
>> [ 6.930476] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at 2 IRQ POLL (stmmac-0:02)
>> [ 6.939757] input: gpio-keys as /devices/platform/gpio-keys/input/input0
>> [ 6.946937] rtc-hym8563 0-0051: no valid clock/calendar values available
>> [ 6.953694] rtc-hym8563 0-0051: hctosys: unable to read the hardware clock
>> [ 6.961262] vcc_sd: disabling
>> [ 6.964275] dovdd_1v8: disabling
>> [ 6.967527] dvdd_1v2: disabling
>> [ 6.971006] vdd10_lcd: disabling
>> [ 6.974701] vcc18_lcd: disabling
>> [ 6.978467] ttyS2 - failed to request DMA
>> [ 7.101883] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
>> [ 7.253874] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
>> [ 7.405883] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
>> [ 7.557885] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
>> [ 8.037872] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
>> [ 8.189877] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
>> [ 8.341881] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
>> [ 8.493884] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
>> [ 8.973871] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
>> [ 9.125876] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
>> [ 9.277884] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
>> [ 9.429882] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
>>
>> looping here
>>
>> If I revert that patch, there are still lots of Bus speed messages, but finally would enter into system.
>>
> Plz..Don't put the comment on the top.
>
> Which kernel did you use?
Add linux-next specific files for 20161224
>
>> On 12/29/2016 06:25 PM, Randy Li wrote:
>>>
>>> On 12/29/2016 03:25 PM, Shawn Lin wrote:
>>>> On 2016/12/29 15:13, Jaehoon Chung wrote:
>>>>> On 12/29/2016 12:02 PM, Jaehoon Chung wrote:
>>>>>> Hi Randy,
>>>>>>
>>>>>> On 12/29/2016 12:34 AM, Randy Li wrote:
>>>>>>> This reverts commit f90142683f04bcb0729bf0df67a5e29562b725b9.
>>>>>>> It is reported that making RK3288 can't boot from eMMC/MMC.
>>>>>> Could you explain in more detail?
>>>>>> As you mentioned, this patch is making that RK3288 can't boot..then why?
>>>>>> Good way should be that finds the main reason and fixes it.
>>>>>> Not just revert.
>>>>> To Shawn,
>>>>>
>>>>> Could you check this? If you have rk3288..
>>>>> If it's not working fine, it needs to revert this patch until finding
>>>>> the problem.
>>>>>
>>>> Hrmm.....as that patchset was tested based on rk3288 and rk3368, so I
>>>> need to know which board Randy are using now and could you share some
>>> Sorry, XZY has asked me about this in the morning and I answer him that I would give a feedback at home, so I didn't notice this mail.
>>> The board is Firefly reload. but the reporter told me that Firefly release also have the same problem.
>>>> log?
>>>>
>>>> I will have a look at it.
>>>>
>>>>
>>>>> Best Regards,
>>>>> Jaehoon Chung
>>>>>
>>>>>> Best Regards,
>>>>>> Jaehoon Chung
>>>>>>
>>>>>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>>>>>> ---
>>>>>>> drivers/mmc/host/dw_mmc-rockchip.c | 41
>>>>>>> +++-----------------------------------
>>>>>>> 1 file changed, 3 insertions(+), 38 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>>> b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>>> index 9a46e46..3189234 100644
>>>>>>> --- a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>>> +++ b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>>> @@ -14,7 +14,6 @@
>>>>>>> #include <linux/mmc/dw_mmc.h>
>>>>>>> #include <linux/of_address.h>
>>>>>>> #include <linux/mmc/slot-gpio.h>
>>>>>>> -#include <linux/pm_runtime.h>
>>>>>>> #include <linux/slab.h>
>>>>>>>
>>>>>>> #include "dw_mmc.h"
>>>>>>> @@ -327,7 +326,6 @@ static int dw_mci_rockchip_probe(struct
>>>>>>> platform_device *pdev)
>>>>>>> {
>>>>>>> const struct dw_mci_drv_data *drv_data;
>>>>>>> const struct of_device_id *match;
>>>>>>> - int ret;
>>>>>>>
>>>>>>> if (!pdev->dev.of_node)
>>>>>>> return -ENODEV;
>>>>>>> @@ -335,49 +333,16 @@ static int dw_mci_rockchip_probe(struct
>>>>>>> platform_device *pdev)
>>>>>>> match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
>>>>>>> drv_data = match->data;
>>>>>>>
>>>>>>> - pm_runtime_get_noresume(&pdev->dev);
>>>>>>> - pm_runtime_set_active(&pdev->dev);
>>>>>>> - pm_runtime_enable(&pdev->dev);
>>>>>>> - pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
>>>>>>> - pm_runtime_use_autosuspend(&pdev->dev);
>>>>>>> -
>>>>>>> - ret = dw_mci_pltfm_register(pdev, drv_data);
>>>>>>> - if (ret) {
>>>>>>> - pm_runtime_disable(&pdev->dev);
>>>>>>> - pm_runtime_set_suspended(&pdev->dev);
>>>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>>>> - return ret;
>>>>>>> - }
>>>>>>> -
>>>>>>> - pm_runtime_put_autosuspend(&pdev->dev);
>>>>>>> -
>>>>>>> - return 0;
>>>>>>> + return dw_mci_pltfm_register(pdev, drv_data);
>>>>>>> }
>>>>>>>
>>>>>>> -static int dw_mci_rockchip_remove(struct platform_device *pdev)
>>>>>>> -{
>>>>>>> - pm_runtime_get_sync(&pdev->dev);
>>>>>>> - pm_runtime_disable(&pdev->dev);
>>>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>>>> -
>>>>>>> - return dw_mci_pltfm_remove(pdev);
>>>>>>> -}
>>>>>>> -
>>>>>>> -static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
>>>>>>> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>>>>>>> - pm_runtime_force_resume)
>>>>>>> - SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
>>>>>>> - dw_mci_runtime_resume,
>>>>>>> - NULL)
>>>>>>> -};
>>>>>>> -
>>>>>>> static struct platform_driver dw_mci_rockchip_pltfm_driver = {
>>>>>>> .probe = dw_mci_rockchip_probe,
>>>>>>> - .remove = dw_mci_rockchip_remove,
>>>>>>> + .remove = dw_mci_pltfm_remove,
>>>>>>> .driver = {
>>>>>>> .name = "dwmmc_rockchip",
>>>>>>> .of_match_table = dw_mci_rockchip_match,
>>>>>>> - .pm = &dw_mci_rockchip_dev_pm_ops,
>>>>>>> + .pm = &dw_mci_pltfm_pmops,
>>>>>>> },
>>>>>>> };
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>> .
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Add CPU OPPs for Exynos4412 Prime
From: Sylwester Nawrocki @ 2016-12-29 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1840714.lHhVv9oNko@amdc3058>
On 12/29/2016 04:06 PM, Bartlomiej Zolnierkiewicz wrote:
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>> ---
>>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +--
>>> arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +--
>>> arch/arm/boot/dts/exynos4412-odroidx2.dts | 1 +
>>> arch/arm/boot/dts/exynos4412-prime.dtsi | 41 +++++++++++++++++++++++++
>>> arch/arm/boot/dts/exynos4412.dtsi | 2 +-
>>> 5 files changed, 48 insertions(+), 5 deletions(-)
>>> create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
>>>
>> Looks okay. Is the clock patch needed for this?
> Yep.
I applied the clock patch and here is a stable tag if it needs
to be pulled as a dependency.
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://linuxtv.org/snawrocki/samsung.git tags/clk-v4.11-exynos4-pll
for you to fetch changes up to c369596f895be88d09f4165b223fa31c64aaefd4:
clk: samsung: Add CPU clk configuration data for Exynos4412 Prime (2016-12-29
16:34:06 +0100)
----------------------------------------------------------------
Addition of the CPU clock configuration data for Exynos4412
Prime SoC variant.
----------------------------------------------------------------
Bartlomiej Zolnierkiewicz (1):
clk: samsung: Add CPU clk configuration data for Exynos4412 Prime
drivers/clk/samsung/clk-exynos4.c | 4 ++++
1 file changed, 4 insertions(+)
--
Regards,
Sylwester
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Bas van Tiel @ 2016-12-29 16:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
when using a signal handler as a way to context switch between
different usercontexts a reproducible exception occurs on my rpi3 in
64-bit mode. (https://gist.github.com/DanGe42/7148946)
Running the context_demo program as a 32-bit ARM executable on a
64-bit kernel is OK, running as a 32 || 64 bit executable on an x86
kernel is OK.
In the first exception the PC doesn?t look correct, and the *pmd is 0.
The 2nd exception happens after running the program again, the PC is 0x0.
A successful function trace was not possible -> complete kernel hangup
when enabling.
Is there another way to gather more information about what is happening?
Linux (none) 4.10.0-rc1-v8+ #3 SMP PREEMPT Thu Dec 29 12:10:12 CET
2016 aarch64 GNU/Linux
[ 46.350738] a.out[196]: unhandled level 2 translation fault (11) at
0x000000b8, esr 0x92000046
[ 46.360516] pgd = ffffffc0392cb000
[ 46.365377] [000000b8] *pgd=00000000392ec003
[ 46.365381] , *pud=00000000392ec003
[ 46.370878] , *pmd=0000000000000000
[ 46.375907]
[ 46.383974]
[ 46.389107] CPU: 0 PID: 196 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
[ 46.397949] Hardware name: Raspberry Pi 3 Model B (DT)
[ 46.406218] task: ffffffc039ad6580 task.stack: ffffffc039bfc000
[ 46.413892] PC is at 0x7fb4e34810
[ 46.418230] LR is at 0x400b84
[ 46.422956] pc : [<0000007fb4e34810>] lr : [<0000000000400b84>]
pstate: 60000000
[ 46.431522] sp : 0000000000413350
[ 46.436480] x29: 0000000000413350 x28: 0000000000000016
[ 46.443142] x27: 0000000000000000 x26: 0000000000000020
[ 46.451908] x25: 0000007fb4f35488 x24: 0000000000415f00
[ 46.459641] x23: 0000000000000016 x22: 0000000000400b84
[ 46.469198] x21: 0000000000413670 x20: 0000000000417030
[ 46.476970] x19: 0000000000001000 x18: 0000000000000000
[ 46.484744] x17: 0000007fb4e34810 x16: 0000000000411270
[ 46.492175] x15: 00000000000005f1 x14: 0000000000000000
[ 46.498884] x13: 0000000000000000 x12: 0000000000000000
[ 46.506013] x11: 0000000000000020 x10: 0101010101010101
[ 46.517164] x9 : 0000000000413670 x8 : 00000000ffffffe0
[ 46.525541] x7 : 0000000000413350 x6 : 0000000000413350
[ 46.533495] x5 : 00000000ffffffe0 x4 : 0000000000413730
[ 46.544052] x3 : 0000000000000008 x2 : 0000000000000000
[ 46.552211] x1 : 0000000000413670 x0 : 0000000000000000
[ 46.558668]
2nd time startup of the executable
[ 262.565147] a.out[201]: unhandled level 2 translation fault (11) at
0x00000000, esr 0x82000006
[ 262.575243] pgd = ffffffc03939a000
[ 262.579948] [00000000] *pgd=000000003938f003
[ 262.579951] , *pud=000000003938f003
[ 262.586040] , *pmd=0000000000000000
[ 262.590479]
[ 262.598234]
[ 262.601108] CPU: 0 PID: 201 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
[ 262.609086] Hardware name: Raspberry Pi 3 Model B (DT)
[ 262.615731] task: ffffffc03904a600 task.stack: ffffffc039bfc000
[ 262.621768] PC is at 0x0
[ 262.624300] LR is at 0x0
[ 262.626835] pc : [<0000000000000000>] lr : [<0000000000000000>]
pstate: 60000000
[ 262.634437] sp : 00000000004159c0
[ 262.637753] x29: 0000000000000000 x28: 0000000000000000
[ 262.643242] x27: 0000000000000000 x26: 0000000000000000
[ 262.648554] x25: 0000000000000000 x24: 0000000000000000
[ 262.654033] x23: 0000000000000000 x22: 0000000000000000
[ 262.659349] x21: 00000000004008f0 x20: 0000000000000000
[ 262.664825] x19: 0000000000000000 x18: 0000000000000000
[ 262.670145] x17: 0000007fb065b620 x16: 0000000000400b84
[ 262.675622] x15: 00000000000003d1 x14: 0000000000000000
[ 262.680938] x13: 0000000000000000 x12: 0000000000000000
[ 262.686413] x11: 0000000000000020 x10: 0101010101010101
[ 262.691835] x9 : 00000000004112c0 x8 : 0000000000000087
[ 262.697159] x7 : 0000000000000000 x6 : 0000000000000000
[ 262.702634] x5 : 0000000000000000 x4 : 0000000000000000
[ 262.707949] x3 : 0000000000000000 x2 : 0000000000000000
[ 262.713424] x1 : 0000000000000000 x0 : 0000000000000000
[ 262.718739]
rpi3:
minimal kernel (64-bit, cortex-a53, little endian, 4Kb page,
initramfs), different kernels tried 4.8/4.9/4.10.0-rc1-v8+ the same
result occurs, also with different compilers.
kernel, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
application, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
The only item I found by reading through the different source-files was the
structure definition of struct kernel_rt_sigframe
(http://osxr.org:8080/glibc/source/ports/sysdeps/unix/sysv/linux/aarch64/kernel_rt_sigframe.h?v=glibc-2.18)
compared to the struct rt_sigframe (linux/arch/arm64/signal.c).
Any help or pointers to solve this issue are welcome,
regards
Bas
^ 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