* [PATCH v4 1/1] clk: mvebu: migrate CP110 system controller to clk_hw API and registration
From: Marcin Wojtas @ 2016-09-25 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474789673-3837-1-git-send-email-mw@semihalf.com>
Now that we have clk_hw based provider APIs to register clks, we
can get rid of struct clk pointers while registering clks in Armada
CP110 system controller driver. This commit introduces new
API and registration for all clocks in CP110 HW blocks.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
drivers/clk/mvebu/cp110-system-controller.c | 150 +++++++++++++---------------
1 file changed, 72 insertions(+), 78 deletions(-)
diff --git a/drivers/clk/mvebu/cp110-system-controller.c b/drivers/clk/mvebu/cp110-system-controller.c
index f2303da..0116808 100644
--- a/drivers/clk/mvebu/cp110-system-controller.c
+++ b/drivers/clk/mvebu/cp110-system-controller.c
@@ -87,7 +87,7 @@ struct cp110_gate_clk {
u8 bit_idx;
};
-#define to_cp110_gate_clk(clk) container_of(clk, struct cp110_gate_clk, hw)
+#define to_cp110_gate_clk(hw) container_of(hw, struct cp110_gate_clk, hw)
static int cp110_gate_enable(struct clk_hw *hw)
{
@@ -123,13 +123,14 @@ static const struct clk_ops cp110_gate_ops = {
.is_enabled = cp110_gate_is_enabled,
};
-static struct clk *cp110_register_gate(const char *name,
- const char *parent_name,
- struct regmap *regmap, u8 bit_idx)
+static struct clk_hw *cp110_register_gate(const char *name,
+ const char *parent_name,
+ struct regmap *regmap, u8 bit_idx)
{
struct cp110_gate_clk *gate;
- struct clk *clk;
+ struct clk_hw *hw;
struct clk_init_data init;
+ int ret;
gate = kzalloc(sizeof(*gate), GFP_KERNEL);
if (!gate)
@@ -146,39 +147,37 @@ static struct clk *cp110_register_gate(const char *name,
gate->bit_idx = bit_idx;
gate->hw.init = &init;
- clk = clk_register(NULL, &gate->hw);
- if (IS_ERR(clk))
+ hw = &gate->hw;
+ ret = clk_hw_register(NULL, hw);
+ if (ret) {
kfree(gate);
+ hw = ERR_PTR(ret);
+ }
- return clk;
+ return hw;
}
-static void cp110_unregister_gate(struct clk *clk)
+static void cp110_unregister_gate(struct clk_hw *hw)
{
- struct clk_hw *hw;
-
- hw = __clk_get_hw(clk);
- if (!hw)
- return;
-
- clk_unregister(clk);
+ clk_hw_unregister(hw);
kfree(to_cp110_gate_clk(hw));
}
-static struct clk *cp110_of_clk_get(struct of_phandle_args *clkspec, void *data)
+static struct clk_hw *cp110_of_clk_get(struct of_phandle_args *clkspec,
+ void *data)
{
- struct clk_onecell_data *clk_data = data;
+ struct clk_hw_onecell_data *clk_data = data;
unsigned int type = clkspec->args[0];
unsigned int idx = clkspec->args[1];
if (type == CP110_CLK_TYPE_CORE) {
if (idx > CP110_MAX_CORE_CLOCKS)
return ERR_PTR(-EINVAL);
- return clk_data->clks[idx];
+ return clk_data->hws[idx];
} else if (type == CP110_CLK_TYPE_GATABLE) {
if (idx > CP110_MAX_GATABLE_CLOCKS)
return ERR_PTR(-EINVAL);
- return clk_data->clks[CP110_MAX_CORE_CLOCKS + idx];
+ return clk_data->hws[CP110_MAX_CORE_CLOCKS + idx];
}
return ERR_PTR(-EINVAL);
@@ -189,8 +188,8 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
struct regmap *regmap;
struct device_node *np = pdev->dev.of_node;
const char *ppv2_name, *apll_name, *core_name, *eip_name, *nand_name;
- struct clk_onecell_data *cp110_clk_data;
- struct clk *clk, **cp110_clks;
+ struct clk_hw_onecell_data *cp110_clk_data;
+ struct clk_hw *hw, **cp110_clks;
u32 nand_clk_ctrl;
int i, ret;
@@ -203,80 +202,75 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
if (ret)
return ret;
- cp110_clks = devm_kcalloc(&pdev->dev, sizeof(struct clk *),
- CP110_CLK_NUM, GFP_KERNEL);
- if (!cp110_clks)
- return -ENOMEM;
-
- cp110_clk_data = devm_kzalloc(&pdev->dev,
- sizeof(*cp110_clk_data),
+ cp110_clk_data = devm_kzalloc(&pdev->dev, sizeof(*cp110_clk_data) +
+ sizeof(struct clk_hw *) * CP110_CLK_NUM,
GFP_KERNEL);
if (!cp110_clk_data)
return -ENOMEM;
- cp110_clk_data->clks = cp110_clks;
- cp110_clk_data->clk_num = CP110_CLK_NUM;
+ cp110_clks = cp110_clk_data->hws;
+ cp110_clk_data->num = CP110_CLK_NUM;
- /* Register the APLL which is the root of the clk tree */
+ /* Register the APLL which is the root of the hw tree */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_APLL, &apll_name);
- clk = clk_register_fixed_rate(NULL, apll_name, NULL, 0,
- 1000 * 1000 * 1000);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_rate(NULL, apll_name, NULL, 0,
+ 1000 * 1000 * 1000);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail0;
}
- cp110_clks[CP110_CORE_APLL] = clk;
+ cp110_clks[CP110_CORE_APLL] = hw;
/* PPv2 is APLL/3 */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_PPV2, &ppv2_name);
- clk = clk_register_fixed_factor(NULL, ppv2_name, apll_name, 0, 1, 3);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, ppv2_name, apll_name, 0, 1, 3);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail1;
}
- cp110_clks[CP110_CORE_PPV2] = clk;
+ cp110_clks[CP110_CORE_PPV2] = hw;
/* EIP clock is APLL/2 */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_EIP, &eip_name);
- clk = clk_register_fixed_factor(NULL, eip_name, apll_name, 0, 1, 2);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, eip_name, apll_name, 0, 1, 2);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail2;
}
- cp110_clks[CP110_CORE_EIP] = clk;
+ cp110_clks[CP110_CORE_EIP] = hw;
/* Core clock is EIP/2 */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_CORE, &core_name);
- clk = clk_register_fixed_factor(NULL, core_name, eip_name, 0, 1, 2);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, core_name, eip_name, 0, 1, 2);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail3;
}
- cp110_clks[CP110_CORE_CORE] = clk;
+ cp110_clks[CP110_CORE_CORE] = hw;
/* NAND can be either APLL/2.5 or core clock */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_NAND, &nand_name);
if (nand_clk_ctrl & NF_CLOCK_SEL_400_MASK)
- clk = clk_register_fixed_factor(NULL, nand_name,
- apll_name, 0, 2, 5);
+ hw = clk_hw_register_fixed_factor(NULL, nand_name,
+ apll_name, 0, 2, 5);
else
- clk = clk_register_fixed_factor(NULL, nand_name,
- core_name, 0, 1, 1);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, nand_name,
+ core_name, 0, 1, 1);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail4;
}
- cp110_clks[CP110_CORE_NAND] = clk;
+ cp110_clks[CP110_CORE_NAND] = hw;
for (i = 0; i < CP110_MAX_GATABLE_CLOCKS; i++) {
const char *parent, *name;
@@ -335,16 +329,16 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
break;
}
- clk = cp110_register_gate(name, parent, regmap, i);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = cp110_register_gate(name, parent, regmap, i);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail_gate;
}
- cp110_clks[CP110_MAX_CORE_CLOCKS + i] = clk;
+ cp110_clks[CP110_MAX_CORE_CLOCKS + i] = hw;
}
- ret = of_clk_add_provider(np, cp110_of_clk_get, cp110_clk_data);
+ ret = of_clk_add_hw_provider(np, cp110_of_clk_get, cp110_clk_data);
if (ret)
goto fail_clk_add;
@@ -355,44 +349,44 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
fail_clk_add:
fail_gate:
for (i = 0; i < CP110_MAX_GATABLE_CLOCKS; i++) {
- clk = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
+ hw = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
- if (clk)
- cp110_unregister_gate(clk);
+ if (hw)
+ cp110_unregister_gate(hw);
}
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
fail4:
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
fail3:
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
fail2:
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
fail1:
- clk_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
+ clk_hw_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
fail0:
return ret;
}
static int cp110_syscon_clk_remove(struct platform_device *pdev)
{
- struct clk **cp110_clks = platform_get_drvdata(pdev);
+ struct clk_hw **cp110_clks = platform_get_drvdata(pdev);
int i;
of_clk_del_provider(pdev->dev.of_node);
for (i = 0; i < CP110_MAX_GATABLE_CLOCKS; i++) {
- struct clk *clk = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
+ struct clk_hw *hw = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
- if (clk)
- cp110_unregister_gate(clk);
+ if (hw)
+ cp110_unregister_gate(hw);
}
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
- clk_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
+ clk_hw_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v4 0/1] Armada 7k/8k CP110 system controller fixes
From: Marcin Wojtas @ 2016-09-25 7:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Two patches from the third version of the patchset have already been
applied, so I re-send the last one with corrected allocation of
clock data, which was pointed in the review.
Any feedback would be very welcome.
Best regards,
Marcin
Changelog:
v4 <- v3
* fix allocation of clock data
v3 <- v2
* return -ENOMEM on alloc failures
v1 <- v2
* replace setting CLK_IS_BASIC flag with clearing init structure fields
with memset
* minor improvements of allocation and error checking
* add migration to clk_hw
Marcin Wojtas (1):
clk: mvebu: migrate CP110 system controller to clk_hw API and
registration
drivers/clk/mvebu/cp110-system-controller.c | 150 +++++++++++++---------------
1 file changed, 72 insertions(+), 78 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH 2/2] drm/rockchip: mark symbols static where possible
From: Baoyou Xie @ 2016-09-25 7:43 UTC (permalink / raw)
To: linux-arm-kernel
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/rockchip/rockchip_drm_drv.c:309:6: warning: no previous prototype for 'rockchip_drm_fb_suspend' [-Wmissing-prototypes]
drivers/gpu/drm/rockchip/rockchip_drm_drv.c:318:6: warning: no previous prototype for 'rockchip_drm_fb_resume' [-Wmissing-prototypes]
In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 76eaf1d..38c3be5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -309,7 +309,7 @@ static struct drm_driver rockchip_drm_driver = {
};
#ifdef CONFIG_PM_SLEEP
-void rockchip_drm_fb_suspend(struct drm_device *drm)
+static void rockchip_drm_fb_suspend(struct drm_device *drm)
{
struct rockchip_drm_private *priv = drm->dev_private;
@@ -318,7 +318,7 @@ void rockchip_drm_fb_suspend(struct drm_device *drm)
console_unlock();
}
-void rockchip_drm_fb_resume(struct drm_device *drm)
+static void rockchip_drm_fb_resume(struct drm_device *drm)
{
struct rockchip_drm_private *priv = drm->dev_private;
--
2.7.4
^ permalink raw reply related
* [PATCH] drm/mediatek: mark symbols static where possible
From: Baoyou Xie @ 2016-09-25 7:41 UTC (permalink / raw)
To: linux-arm-kernel
We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1089:6: warning: no previous prototype for 'mtk_hdmi_audio_enable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1095:6: warning: no previous prototype for 'mtk_hdmi_audio_disable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1101:5: warning: no previous prototype for 'mtk_hdmi_audio_set_param' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1627:5: warning: no previous prototype for 'mtk_hdmi_audio_digital_mute' [-Wmissing-prototypes]
In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks both functions with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 334562d..be4e19c 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1086,19 +1086,19 @@ static int mtk_hdmi_output_init(struct mtk_hdmi *hdmi)
return 0;
}
-void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
+static void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
{
mtk_hdmi_aud_enable_packet(hdmi, true);
hdmi->audio_enable = true;
}
-void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
+static void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
{
mtk_hdmi_aud_enable_packet(hdmi, false);
hdmi->audio_enable = false;
}
-int mtk_hdmi_audio_set_param(struct mtk_hdmi *hdmi,
+static int mtk_hdmi_audio_set_param(struct mtk_hdmi *hdmi,
struct hdmi_audio_param *param)
{
if (!hdmi->audio_enable) {
@@ -1624,7 +1624,8 @@ static void mtk_hdmi_audio_shutdown(struct device *dev, void *data)
mtk_hdmi_audio_disable(hdmi);
}
-int mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
+static int
+mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
{
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH] drm/mediatek: mark symbols static where possible
From: Baoyou Xie @ 2016-09-25 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474789109-22010-1-git-send-email-baoyou.xie@linaro.org>
We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1089:6: warning: no previous prototype for 'mtk_hdmi_audio_enable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1095:6: warning: no previous prototype for 'mtk_hdmi_audio_disable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1101:5: warning: no previous prototype for 'mtk_hdmi_audio_set_param' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1627:5: warning: no previous prototype for 'mtk_hdmi_audio_digital_mute' [-Wmissing-prototypes]
In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks both functions with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 334562d..be4e19c 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1086,19 +1086,19 @@ static int mtk_hdmi_output_init(struct mtk_hdmi *hdmi)
return 0;
}
-void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
+static void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
{
mtk_hdmi_aud_enable_packet(hdmi, true);
hdmi->audio_enable = true;
}
-void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
+static void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
{
mtk_hdmi_aud_enable_packet(hdmi, false);
hdmi->audio_enable = false;
}
-int mtk_hdmi_audio_set_param(struct mtk_hdmi *hdmi,
+static int mtk_hdmi_audio_set_param(struct mtk_hdmi *hdmi,
struct hdmi_audio_param *param)
{
if (!hdmi->audio_enable) {
@@ -1624,7 +1624,8 @@ static void mtk_hdmi_audio_shutdown(struct device *dev, void *data)
mtk_hdmi_audio_disable(hdmi);
}
-int mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
+static int
+mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
{
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] drm/rockchip: add missing header dependencies
From: Baoyou Xie @ 2016-09-25 7:38 UTC (permalink / raw)
To: linux-arm-kernel
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c:130:5: warning: no previous prototype for 'rockchip_drm_fbdev_init' [-Wmissing-prototypes]
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c:173:6: warning: no previous prototype for 'rockchip_drm_fbdev_fini' [-Wmissing-prototypes]
In fact, these functions are declared
in drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h,
so this patch adds missing header dependencies.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
index 207e01d..a16c69f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
@@ -20,6 +20,7 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_gem.h"
#include "rockchip_drm_fb.h"
+#include "rockchip_drm_fbdev.h"
#define PREFERRED_BPP 32
#define to_drm_private(x) \
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: exynos: Add reboot reason support for Trats2
From: Krzysztof Kozlowski @ 2016-09-25 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fuopvwjy.fsf@machinist.wiedmeyer.de>
On Sat, Sep 24, 2016 at 11:04:49PM +0200, Wolfgang Wiedmeyer wrote:
>
> Krzysztof Kozlowski writes:
>
> > On Thu, Sep 22, 2016 at 08:59:03PM +0200, Wolfgang Wiedmeyer wrote:
> >>
> >> Krzysztof Kozlowski writes:
> >>
> >> > On Thu, Sep 22, 2016 at 06:48:35PM +0200, Wolfgang Wiedmeyer wrote:
> >> >> This allows to reboot the device into recovery mode and into the download
> >> >> mode of the bootloader.
> >> >
> >> > Which bootloader? Probably UBoot... or Samsung stock one? Could you put
> >> > that information here?
> >>
> >> I'm only working with the stock one. I was under the impression that the
> >> stock bootloader cannot be replaced on a i9300 because there's a
> >> signature check. Is UBoot loaded after the stock one on Trats2 or how
> >> does this work? I didn't find information on that.
> >
> > +CC Marek,
> >
> > Trats2 is working with U-Boot. Just U-Boot. However I never converted S3
> > into Trats2 on my own. I always used targets prepared to be "Trats2"
> > type.
>
> It would be awesome to be able to run U-Boot on i9300. Is there a way to
> test this by not risking to brick the device, e.g. by booting from the
> SD card? Then I could send an updated version of the patch that is
> compatible with U-Boot :)
I don't think the stock bootloader supports chaining another bootloader
from SD card. There is a way of booting from SD card by shortening a
resistor but it is an emergency rescue procedure to overwrite existing
bootloader with data from SD card (to restore device). This thread might
be interesting:
http://forum.xda-developers.com/showpost.php?p=47234165&postcount=220
https://smyl.es/samsung-galaxy-iii-s3-gt-i9300-jtag-leaked-document-how-to-repair-soft-bricked-galaxy-s3/
On xda-developers you might find more data about this (including the
procedure for emergency restore from SD card). Somehow people flash and
unbrick their devices when playing with CyanogenMod...
Best regards,
Krzysztof
^ permalink raw reply
* Applied "ASoC: sun4i-codec: Rename some sun7i-only registers" to the asoc tree
From: Mark Brown @ 2016-09-25 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915143922.4890-3-dannym@scratchpost.org>
The patch
ASoC: sun4i-codec: Rename some sun7i-only registers
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 4f0c4e99312d8887483474d60e47ab4e24713114 Mon Sep 17 00:00:00 2001
From: Danny Milosavljevic <dannym@scratchpost.org>
Date: Thu, 22 Sep 2016 09:13:12 +0200
Subject: [PATCH] ASoC: sun4i-codec: Rename some sun7i-only registers
Some of the registers defined in the driver are only usable on the
A20. Rename these registers.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 44f170c73b06..9d8c027f7c55 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -96,8 +96,8 @@
/* Other various ADC registers */
#define SUN4I_CODEC_DAC_TXCNT (0x30)
#define SUN4I_CODEC_ADC_RXCNT (0x34)
-#define SUN4I_CODEC_AC_SYS_VERI (0x38)
-#define SUN4I_CODEC_AC_MIC_PHONE_CAL (0x3c)
+#define SUN7I_CODEC_AC_DAC_CAL (0x38)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
struct sun4i_codec {
struct device *dev;
@@ -680,7 +680,7 @@ static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
- .max_register = SUN4I_CODEC_AC_MIC_PHONE_CAL,
+ .max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
static const struct of_device_id sun4i_codec_of_match[] = {
--
2.9.3
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add custom regmap configs" to the asoc tree
From: Mark Brown @ 2016-09-25 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922071313.12891-4-dannym@scratchpost.org>
The patch
ASoC: sun4i-codec: Add custom regmap configs
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From c1d5065a0bd09bac783120b73bfa768ba6a493d9 Mon Sep 17 00:00:00 2001
From: Danny Milosavljevic <dannym@scratchpost.org>
Date: Thu, 22 Sep 2016 09:13:13 +0200
Subject: [PATCH] ASoC: sun4i-codec: Add custom regmap configs
The A20 has a few extra registers that the A10 doesn't have.
Therefore, use different regmaps for A10 as compared to A20.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 38 +++++++++++++++++++++++++++++++++++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 9d8c027f7c55..eb6808842208 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -680,12 +680,37 @@ static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
+ .max_register = SUN4I_CODEC_ADC_RXCNT,
+};
+
+static const struct regmap_config sun7i_codec_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
.max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
+struct sun4i_codec_quirks {
+ const struct regmap_config *regmap_config;
+};
+
+static const struct sun4i_codec_quirks sun4i_codec_quirks = {
+ .regmap_config = &sun4i_codec_regmap_config,
+};
+
+static const struct sun4i_codec_quirks sun7i_codec_quirks = {
+ .regmap_config = &sun7i_codec_regmap_config,
+};
+
static const struct of_device_id sun4i_codec_of_match[] = {
- { .compatible = "allwinner,sun4i-a10-codec" },
- { .compatible = "allwinner,sun7i-a20-codec" },
+ {
+ .compatible = "allwinner,sun4i-a10-codec",
+ .data = &sun4i_codec_quirks,
+ },
+ {
+ .compatible = "allwinner,sun7i-a20-codec",
+ .data = &sun7i_codec_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
@@ -758,6 +783,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
{
struct snd_soc_card *card;
struct sun4i_codec *scodec;
+ const struct sun4i_codec_quirks *quirks;
struct resource *res;
void __iomem *base;
int ret;
@@ -775,8 +801,14 @@ static int sun4i_codec_probe(struct platform_device *pdev)
return PTR_ERR(base);
}
+ quirks = of_device_get_match_data(&pdev->dev);
+ if (quirks == NULL) {
+ dev_err(&pdev->dev, "Failed to determine the quirks to use\n");
+ return -ENODEV;
+ }
+
scodec->regmap = devm_regmap_init_mmio(&pdev->dev, base,
- &sun4i_codec_regmap_config);
+ quirks->regmap_config);
if (IS_ERR(scodec->regmap)) {
dev_err(&pdev->dev, "Failed to create our regmap\n");
return PTR_ERR(scodec->regmap);
--
2.9.3
^ permalink raw reply related
* Applied "ASoC: exynos: organize the asoc audio into a menu" to the asoc tree
From: Mark Brown @ 2016-09-25 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474311470-23175-1-git-send-email-ayaka@soulik.info>
The patch
ASoC: exynos: organize the asoc audio into a menu
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 090d93488135c8422d7711a8cefa4ed1cff7744a Mon Sep 17 00:00:00 2001
From: Randy Li <ayaka@soulik.info>
Date: Tue, 20 Sep 2016 02:57:50 +0800
Subject: [PATCH] ASoC: exynos: organize the asoc audio into a menu
It is simple sound card time, we could assign different codec
to a interface without making a specific driver for it. The SPDIF
and I2S interface for Samsung would be possible used by
simple-sound-card, but not sure about the PCM.
Those S3C time entries are left alone as I don't think any new board
would need them.
Signed-off-by: Randy Li <ayaka@soulik.info>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/Kconfig | 57 ++++++++++++++++++++++++-----------------------
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 7b722b0094d9..f6023b46c107 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -1,12 +1,14 @@
-config SND_SOC_SAMSUNG
+menuconfig SND_SOC_SAMSUNG
tristate "ASoC support for Samsung"
depends on (PLAT_SAMSUNG || ARCH_EXYNOS)
select SND_SOC_GENERIC_DMAENGINE_PCM
- help
+ ---help---
Say Y or M if you want to add support for codecs attached to
the Samsung SoCs' Audio interfaces. You will also need to
select the audio interfaces to support below.
+if SND_SOC_SAMSUNG
+
config SND_S3C24XX_I2S
tristate
@@ -18,22 +20,22 @@ config SND_S3C2412_SOC_I2S
select SND_S3C_I2SV2_SOC
config SND_SAMSUNG_PCM
- tristate
+ tristate "Samsung PCM interface support"
config SND_SAMSUNG_AC97
tristate
select SND_SOC_AC97_BUS
config SND_SAMSUNG_SPDIF
- tristate
+ tristate "Samsung SPDIF transmitter support"
select SND_SOC_SPDIF
config SND_SAMSUNG_I2S
- tristate
+ tristate "Samsung I2S interface support"
config SND_SOC_SAMSUNG_NEO1973_WM8753
tristate "Audio support for Openmoko Neo1973 Smartphones (GTA02)"
- depends on SND_SOC_SAMSUNG && MACH_NEO1973_GTA02
+ depends on MACH_NEO1973_GTA02
select SND_S3C24XX_I2S
select SND_SOC_WM8753
select SND_SOC_BT_SCO
@@ -43,7 +45,7 @@ config SND_SOC_SAMSUNG_NEO1973_WM8753
config SND_SOC_SAMSUNG_JIVE_WM8750
tristate "SoC I2S Audio support for Jive"
- depends on SND_SOC_SAMSUNG && MACH_JIVE && I2C
+ depends on MACH_JIVE && I2C
select SND_SOC_WM8750
select SND_S3C2412_SOC_I2S
help
@@ -51,7 +53,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750
config SND_SOC_SAMSUNG_SMDK_WM8580
tristate "SoC I2S Audio support for WM8580 on SMDK"
- depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110)
+ depends on MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110
depends on I2C
select SND_SOC_WM8580
select SND_SAMSUNG_I2S
@@ -60,7 +62,6 @@ config SND_SOC_SAMSUNG_SMDK_WM8580
config SND_SOC_SAMSUNG_SMDK_WM8994
tristate "SoC I2S Audio support for WM8994 on SMDK"
- depends on SND_SOC_SAMSUNG
depends on I2C=y
select MFD_WM8994
select SND_SOC_WM8994
@@ -70,7 +71,7 @@ config SND_SOC_SAMSUNG_SMDK_WM8994
config SND_SOC_SAMSUNG_SMDK2443_WM9710
tristate "SoC AC97 Audio support for SMDK2443 - WM9710"
- depends on SND_SOC_SAMSUNG && MACH_SMDK2443
+ depends on MACH_SMDK2443
select AC97_BUS
select SND_SOC_AC97_CODEC
select SND_SAMSUNG_AC97
@@ -80,7 +81,7 @@ config SND_SOC_SAMSUNG_SMDK2443_WM9710
config SND_SOC_SAMSUNG_LN2440SBC_ALC650
tristate "SoC AC97 Audio support for LN2440SBC - ALC650"
- depends on SND_SOC_SAMSUNG && ARCH_S3C24XX
+ depends on ARCH_S3C24XX
select AC97_BUS
select SND_SOC_AC97_CODEC
select SND_SAMSUNG_AC97
@@ -90,7 +91,7 @@ config SND_SOC_SAMSUNG_LN2440SBC_ALC650
config SND_SOC_SAMSUNG_S3C24XX_UDA134X
tristate "SoC I2S Audio support UDA134X wired to a S3C24XX"
- depends on SND_SOC_SAMSUNG && ARCH_S3C24XX
+ depends on ARCH_S3C24XX
select SND_S3C24XX_I2S
select SND_SOC_L3
select SND_SOC_UDA134X
@@ -102,21 +103,21 @@ config SND_SOC_SAMSUNG_SIMTEC
config SND_SOC_SAMSUNG_SIMTEC_TLV320AIC23
tristate "SoC I2S Audio support for TLV320AIC23 on Simtec boards"
- depends on SND_SOC_SAMSUNG && ARCH_S3C24XX && I2C
+ depends on ARCH_S3C24XX && I2C
select SND_S3C24XX_I2S
select SND_SOC_TLV320AIC23_I2C
select SND_SOC_SAMSUNG_SIMTEC
config SND_SOC_SAMSUNG_SIMTEC_HERMES
tristate "SoC I2S Audio support for Simtec Hermes board"
- depends on SND_SOC_SAMSUNG && ARCH_S3C24XX && I2C
+ depends on ARCH_S3C24XX && I2C
select SND_S3C24XX_I2S
select SND_SOC_TLV320AIC3X
select SND_SOC_SAMSUNG_SIMTEC
config SND_SOC_SAMSUNG_H1940_UDA1380
tristate "Audio support for the HP iPAQ H1940"
- depends on SND_SOC_SAMSUNG && ARCH_H1940 && I2C
+ depends on ARCH_H1940 && I2C
select SND_S3C24XX_I2S
select SND_SOC_UDA1380
help
@@ -124,7 +125,7 @@ config SND_SOC_SAMSUNG_H1940_UDA1380
config SND_SOC_SAMSUNG_RX1950_UDA1380
tristate "Audio support for the HP iPAQ RX1950"
- depends on SND_SOC_SAMSUNG && MACH_RX1950 && I2C
+ depends on MACH_RX1950 && I2C
select SND_S3C24XX_I2S
select SND_SOC_UDA1380
help
@@ -132,7 +133,7 @@ config SND_SOC_SAMSUNG_RX1950_UDA1380
config SND_SOC_SAMSUNG_SMDK_WM9713
tristate "SoC AC97 Audio support for SMDK with WM9713"
- depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110)
+ depends on MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110
select SND_SOC_WM9713
select SND_SAMSUNG_AC97
help
@@ -140,20 +141,19 @@ config SND_SOC_SAMSUNG_SMDK_WM9713
config SND_SOC_SMARTQ
tristate "SoC I2S Audio support for SmartQ board"
- depends on SND_SOC_SAMSUNG && MACH_SMARTQ && I2C
+ depends on MACH_SMARTQ && I2C
select SND_SAMSUNG_I2S
select SND_SOC_WM8750
config SND_SOC_SAMSUNG_SMDK_SPDIF
tristate "SoC S/PDIF Audio support for SMDK"
- depends on SND_SOC_SAMSUNG
select SND_SAMSUNG_SPDIF
help
Say Y if you want to add support for SoC S/PDIF audio on the SMDK.
config SND_SOC_SMDK_WM8580_PCM
tristate "SoC PCM Audio support for WM8580 on SMDK"
- depends on SND_SOC_SAMSUNG && (MACH_SMDKV210 || MACH_SMDKC110)
+ depends on MACH_SMDKV210 || MACH_SMDKC110
depends on I2C
select SND_SOC_WM8580
select SND_SAMSUNG_PCM
@@ -162,7 +162,6 @@ config SND_SOC_SMDK_WM8580_PCM
config SND_SOC_SMDK_WM8994_PCM
tristate "SoC PCM Audio support for WM8994 on SMDK"
- depends on SND_SOC_SAMSUNG
depends on I2C=y
select MFD_WM8994
select SND_SOC_WM8994
@@ -172,7 +171,7 @@ config SND_SOC_SMDK_WM8994_PCM
config SND_SOC_SPEYSIDE
tristate "Audio support for Wolfson Speyside"
- depends on SND_SOC_SAMSUNG && I2C && SPI_MASTER
+ depends on I2C && SPI_MASTER
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select SND_SOC_WM8996
@@ -182,14 +181,14 @@ config SND_SOC_SPEYSIDE
config SND_SOC_TOBERMORY
tristate "Audio support for Wolfson Tobermory"
- depends on SND_SOC_SAMSUNG && INPUT && I2C
+ depends on INPUT && I2C
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select SND_SOC_WM8962
config SND_SOC_BELLS
tristate "Audio support for Wolfson Bells"
- depends on SND_SOC_SAMSUNG && MFD_ARIZONA && I2C && SPI_MASTER
+ depends on MFD_ARIZONA && I2C && SPI_MASTER
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select SND_SOC_WM5102
@@ -200,7 +199,7 @@ config SND_SOC_BELLS
config SND_SOC_LOWLAND
tristate "Audio support for Wolfson Lowland"
- depends on SND_SOC_SAMSUNG && I2C
+ depends on I2C
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select SND_SOC_WM5100
@@ -208,7 +207,7 @@ config SND_SOC_LOWLAND
config SND_SOC_LITTLEMILL
tristate "Audio support for Wolfson Littlemill"
- depends on SND_SOC_SAMSUNG && I2C
+ depends on I2C
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select MFD_WM8994
@@ -216,7 +215,7 @@ config SND_SOC_LITTLEMILL
config SND_SOC_SNOW
tristate "Audio support for Google Snow boards"
- depends on SND_SOC_SAMSUNG && I2C
+ depends on I2C
select SND_SOC_MAX98090
select SND_SOC_MAX98095
select SND_SAMSUNG_I2S
@@ -226,6 +225,8 @@ config SND_SOC_SNOW
config SND_SOC_ARNDALE_RT5631_ALC5631
tristate "Audio support for RT5631(ALC5631) on Arndale Board"
- depends on SND_SOC_SAMSUNG && I2C
+ depends on I2C
select SND_SAMSUNG_I2S
select SND_SOC_RT5631
+
+endif #SND_SOC_SAMSUNG
--
2.9.3
^ permalink raw reply related
* [PATCH v2] ARM: dts: socfpga: Add Macnica sodia board
From: Florian Fainelli @ 2016-09-25 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160924235945.32128-1-iwamatsu@nigauri.org>
On 09/24/2016 04:59 PM, Nobuhiro Iwamatsu wrote:
> Add support for board based on the Altera Cyclone V SoC.
> This board has the following functions:
> - 1 GiB of DRAM
> - 1 Gigabit ethernet
> - 1 SD card slot
> - 1 USB gadget port
> - QSPI NOR Flash
> - I2C EEPROMs and I2C RTC
> - DVI output
> - Audio port
>
> This commit supports without QSPI, DVI and Audio.
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> ---
> V2: move the PHY of setting to the Ethetnet PHY node level.
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 123 +++++++++++++++++++++++++++
> 2 files changed, 124 insertions(+)
> create mode 100644 arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..7c5f0c3 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -696,6 +696,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) += \
> socfpga_cyclone5_de0_sockit.dtb \
> socfpga_cyclone5_sockit.dtb \
> socfpga_cyclone5_socrates.dtb \
> + socfpga_cyclone5_sodia.dtb \
> socfpga_cyclone5_vining_fpga.dtb \
> socfpga_vt.dtb
> dtb-$(CONFIG_ARCH_SPEAR13XX) += \
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
> new file mode 100644
> index 0000000..9aaf413
> --- /dev/null
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
> @@ -0,0 +1,123 @@
> +/*
> + * Copyright (C) 2016 Nobuhiro Iwamatsu <iwamatsu@nigauri.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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include "socfpga_cyclone5.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> + model = "Altera SOCFPGA Cyclone V SoC Macnica Sodia board";
> + compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> +
> + chosen {
> + bootargs = "earlyprintk";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + name = "memory";
> + device_type = "memory";
> + reg = <0x0 0x40000000>;
> + };
> +
> + aliases {
> + ethernet0 = &gmac1;
> + };
> +
> + regulator_3_3v: 3-3-v-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "3.3V";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + leds: gpio-leds {
> + compatible = "gpio-leds";
> +
> + hps_led0 {
> + label = "hps:green:led0";
> + gpios = <&portb 12 GPIO_ACTIVE_LOW>;
> + };
> +
> + hps_led1 {
> + label = "hps:green:led1";
> + gpios = <&portb 13 GPIO_ACTIVE_LOW>;
> + };
> +
> + hps_led2 {
> + label = "hps:green:led2";
> + gpios = <&portb 14 GPIO_ACTIVE_LOW>;
> + };
> +
> + hps_led3 {
> + label = "hps:green:led3";
> + gpios = <&portb 15 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +&gmac1 {
> + status = "okay";
> + phy-mode = "rgmii";
> + phy = <&phy0>;
> +
> + mdio0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy0: ethernet-phy at 0 {
> + reg = <0>;
> + rxd0-skew-ps = <0>;
> + rxd1-skew-ps = <0>;
> + rxd2-skew-ps = <0>;
> + rxd3-skew-ps = <0>;
> + rxdv-skew-ps = <0>;
> + rxc-skew-ps = <3000>;
> + txen-skew-ps = <0>;
> + txc-skew-ps = <3000>;
> + };
This looks much better now, thanks!
--
Florian
^ permalink raw reply
* [PATCH] PCI: enable extended tags support for PCIe endpoints
From: Sinan Kaya @ 2016-09-25 2:10 UTC (permalink / raw)
To: linux-arm-kernel
Each PCIe device can issue up to 32 transactions at a time by default.
Each transaction is tracked by a tag number on the bus. 32 outstanding
transactions is not enough for some performance critical applications
especially when a lot of small sized frames are transmitted.
Extended tags support increases this number to 256. Devices not
supporting extended tags tie-off this field to 0. According to ECN, it
is safe to enable this feature for all PCIe endpoints.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/probe.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 93f280d..2424f38 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1505,12 +1505,19 @@ static void program_hpp_type2(struct pci_dev *dev, struct hpp_type2 *hpp)
*/
}
+static int pci_configure_extended_tags(struct pci_dev *dev)
+{
+ return pcie_capability_set_word(dev, PCI_EXP_DEVCTL,
+ PCI_EXP_DEVCTL_EXT_TAG);
+}
+
static void pci_configure_device(struct pci_dev *dev)
{
struct hotplug_params hpp;
int ret;
pci_configure_mps(dev);
+ pci_configure_extended_tags(dev);
memset(&hpp, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, &hpp);
--
1.9.1
^ permalink raw reply related
* [PATCH v2.1] arm64: kgdb: handle read-only text / modules
From: AKASHI Takahiro @ 2016-09-25 0:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923102340.GA2161@e104818-lin.cambridge.arm.com>
Hi Catalin,
On Fri, Sep 23, 2016 at 11:23:40AM +0100, Catalin Marinas wrote:
> On Fri, Sep 23, 2016 at 10:49:53AM +0100, Catalin Marinas wrote:
> > On Fri, Sep 23, 2016 at 04:42:08PM +0900, AKASHI Takahiro wrote:
> > > Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
> > > by using aarch64_insn_write() instead of probe_kernel_write().
> > > See how this works:
> > > commit 2f896d586610 ("arm64: use fixmap for text patching")
> > >
> > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Will Deacon <will.deacon@arm.com>
> > > Cc: Jason Wessel <jason.wessel@windriver.com>
> > > Cc: <stable@vger.kernel.org> # 3.18-3.19: 2f896d5: arm64: use fixmap
> > > Cc: <stable@vger.kernel.org> # 3.18-3.19: f6242ca: arm64: Fix text
> > > Cc: <stable@vger.kernel.org> # 4.0-
> >
> > Queued for 4.8 with a slight change in the last Cc: tag above:
> >
> > Cc: <stable@vger.kernel.org> # 3.18.x-
>
> I tried to apply this patch to 3.18, 4.1, 4.4, 4.7. It fails on all of
> them with smaller or slightly larger conflicts.
Oh, too bad.
I guest we'd better revert the following patches as well:
c696b93 arm64/debug: Simplify BRK insn opcode declarations
c172d99 arm64/debug: More consistent naming for the BRK ESR template macro
but I will check anyway.
> So, I'll merge it in 4.8 without any "Cc: stable" tags, just a "Fixes:"
> one for the commit introducing CONFIG_DEBUG_SET_MODULE_RONX (3.18). Once
> the patch reaches mainline, could you please back-port and test it on
> the stable kernel versions and send separate patches to
> stable at vger.kernel.org?
Thanks,
-Takahiro AKASHI
> Thanks.
>
> --
> Catalin
^ permalink raw reply
* [PATCH v2] ARM: dts: socfpga: Add Macnica sodia board
From: Nobuhiro Iwamatsu @ 2016-09-24 23:59 UTC (permalink / raw)
To: linux-arm-kernel
Add support for board based on the Altera Cyclone V SoC.
This board has the following functions:
- 1 GiB of DRAM
- 1 Gigabit ethernet
- 1 SD card slot
- 1 USB gadget port
- QSPI NOR Flash
- I2C EEPROMs and I2C RTC
- DVI output
- Audio port
This commit supports without QSPI, DVI and Audio.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
V2: move the PHY of setting to the Ethetnet PHY node level.
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 123 +++++++++++++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..7c5f0c3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -696,6 +696,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) += \
socfpga_cyclone5_de0_sockit.dtb \
socfpga_cyclone5_sockit.dtb \
socfpga_cyclone5_socrates.dtb \
+ socfpga_cyclone5_sodia.dtb \
socfpga_cyclone5_vining_fpga.dtb \
socfpga_vt.dtb
dtb-$(CONFIG_ARCH_SPEAR13XX) += \
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
new file mode 100644
index 0000000..9aaf413
--- /dev/null
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2016 Nobuhiro Iwamatsu <iwamatsu@nigauri.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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "socfpga_cyclone5.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "Altera SOCFPGA Cyclone V SoC Macnica Sodia board";
+ compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+
+ chosen {
+ bootargs = "earlyprintk";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ name = "memory";
+ device_type = "memory";
+ reg = <0x0 0x40000000>;
+ };
+
+ aliases {
+ ethernet0 = &gmac1;
+ };
+
+ regulator_3_3v: 3-3-v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ leds: gpio-leds {
+ compatible = "gpio-leds";
+
+ hps_led0 {
+ label = "hps:green:led0";
+ gpios = <&portb 12 GPIO_ACTIVE_LOW>;
+ };
+
+ hps_led1 {
+ label = "hps:green:led1";
+ gpios = <&portb 13 GPIO_ACTIVE_LOW>;
+ };
+
+ hps_led2 {
+ label = "hps:green:led2";
+ gpios = <&portb 14 GPIO_ACTIVE_LOW>;
+ };
+
+ hps_led3 {
+ label = "hps:green:led3";
+ gpios = <&portb 15 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&gmac1 {
+ status = "okay";
+ phy-mode = "rgmii";
+ phy = <&phy0>;
+
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy at 0 {
+ reg = <0>;
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ rxdv-skew-ps = <0>;
+ rxc-skew-ps = <3000>;
+ txen-skew-ps = <0>;
+ txc-skew-ps = <3000>;
+ };
+ };
+};
+
+&gpio1 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ eeprom at 51 {
+ compatible = "atmel,24c32";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+
+ rtc at 68 {
+ compatible = "dallas,ds1339";
+ reg = <0x68>;
+ };
+};
+
+&mmc0 {
+ cd-gpios = <&portb 18 0>;
+ vmmc-supply = <®ulator_3_3v>;
+ vqmmc-supply = <®ulator_3_3v>;
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: dts: exynos: Add reboot reason support for Trats2
From: Wolfgang Wiedmeyer @ 2016-09-24 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922205522.GA15917@kozik-lap>
Krzysztof Kozlowski writes:
> On Thu, Sep 22, 2016 at 08:59:03PM +0200, Wolfgang Wiedmeyer wrote:
>>
>> Krzysztof Kozlowski writes:
>>
>> > On Thu, Sep 22, 2016 at 06:48:35PM +0200, Wolfgang Wiedmeyer wrote:
>> >> This allows to reboot the device into recovery mode and into the download
>> >> mode of the bootloader.
>> >
>> > Which bootloader? Probably UBoot... or Samsung stock one? Could you put
>> > that information here?
>>
>> I'm only working with the stock one. I was under the impression that the
>> stock bootloader cannot be replaced on a i9300 because there's a
>> signature check. Is UBoot loaded after the stock one on Trats2 or how
>> does this work? I didn't find information on that.
>
> +CC Marek,
>
> Trats2 is working with U-Boot. Just U-Boot. However I never converted S3
> into Trats2 on my own. I always used targets prepared to be "Trats2"
> type.
It would be awesome to be able to run U-Boot on i9300. Is there a way to
test this by not risking to brick the device, e.g. by booting from the
SD card? Then I could send an updated version of the patch that is
compatible with U-Boot :)
> Of course kernel is independent to bootloader but in that case you want
> to use a specific interface between kernel and specific bootloader
> type/version. In that case - this should be U-Boot, I think.
I absolutely understand that. Having the patch in mainline doesn't make
much sense if it's not compatible with U-Boot.
Best regards,
Wolfgang
>> >> Signed-off-by: Wolfgang Wiedmeyer <wolfgit@wiedmeyer.de>
>> >> ---
>> >> arch/arm/boot/dts/exynos4412-trats2.dts | 14 ++++++++++++++
>> >> arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
>> >> 2 files changed, 15 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
>> >> index 129e973..a38d1e3 100644
>> >> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
>> >> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>> >> @@ -1294,3 +1294,17 @@
>> >> vtmu-supply = <&ldo10_reg>;
>> >> status = "okay";
>> >> };
>> >> +
>> >> +&pmu {
>> >> + compatible = "syscon", "simple-mfd";
>> >> +
>> >> + reboot-mode {
>> >> + compatible = "syscon-reboot-mode";
>> >> + offset = <0x80c>;
>> >> +
>> >> + mode-normal = <0x12345670>;
>> >> + mode-bootloader = <0x12345671>;
>> >> + mode-download = <0x12345671>;
>> >> + mode-recovery = <0x12345674>;
>> >
>> > Hmmm, how did you get these values? Are they already supported?
>>
>> I only have the vendor source drop as documentation. The magic mode
>> values [1] and the offset [2] can be found there.
>
> It would be useful to mention that in commit msg (just the source)...
> however as I wrote above, these values should be for U-Boot, not the
> stock one.
>
> Best regards,
> Krzysztof
>
>>
>> > It would be nice to document them:
>> > 1. In Documentation/arm/Samsung/Bootloader-interface.txt
>> > 2. In header. I hate such magic numbers... you could add new header next
>> > to existing rockchip one:
>> > include/dt-bindings/soc/samsung,boot-mode.h
>> > (and update maintainers entry :) )
>>
>> Thanks for the review! I will do the documentation and update the commit
>> message.
>>
>> Best regards,
>> Wolfgang
>>
>> [1] https://code.fossencdi.org/kernel_samsung_smdk4412.git/tree/arch/arm/mach-exynos/sec-reboot.c#n65
>>
>> [2] https://code.fossencdi.org/kernel_samsung_smdk4412.git/tree/arch/arm/mach-exynos/include/mach/regs-pmu.h#n79
>>
>>
>> --
>> Website: https://fossencdi.org
>> Jabber: wolfgang at wiedmeyer.de
>> OpenPGP: 0F30 D1A0 2F73 F70A 6FEE 048E 5816 A24C 1075 7FC4
>> Key download: https://wiedmeyer.de/keys/ww.asc
--
Website: https://fossencdi.org
Jabber: wolfgang at wiedmeyer.de
OpenPGP: 0F30 D1A0 2F73 F70A 6FEE 048E 5816 A24C 1075 7FC4
Key download: https://wiedmeyer.de/keys/ww.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160924/58a07749/attachment.sig>
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-09-24 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <05a573de-e963-6590-6ed3-55af97067d7a@gmail.com>
On Saturday, September 24, 2016 4:14:15 PM CEST zhichang wrote:
>
> In V3, the outb is :
>
> void outb(u8 value, unsigned long addr)
> {
> if (!arm64_extio_ops || arm64_extio_ops->start > addr ||
> arm64_extio_ops->end < addr)
> writeb(value, PCI_IOBASE + addr);
> else
> if (arm64_extio_ops->pfout)
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,
> addr + arm64_extio_ops->ptoffset, &value,
> sizeof(u8), 1);
> }
>
> here, arm64_extio_ops->ptoffset is the offset between the real legacy IO address
> and the logical IO address, similar to the offset of primary address and
> secondary address in PCI bridge.
Ok, though we can probably simplify this by making the assumption that
'ptoffset' is the negative of 'start', as the bus we register should
always start at port zero.
> But in V3, LPC driver call pci_address_to_pio to request the logical IO as PCI
> host bridge during its probing.
Right, so this still needs to be fixed.
Arnd
^ permalink raw reply
* [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
From: Maxime Ripard @ 2016-09-24 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473411668.731.75.camel@schinagl.nl>
Hi Oliver,
Sorry for the slow answer.
On Fri, Sep 09, 2016 at 11:01:08AM +0200, Olliver Schinagl wrote:
> > > > > *chip, struct pwm_device *pwm)
> > > > > ? spin_lock(&sun4i_pwm->ctrl_lock);
> > > > > ? val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> > > > > ? val &= ~BIT_CH(PWM_EN, pwm->hwpwm);
> > > > > + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> > > > > + spin_unlock(&sun4i_pwm->ctrl_lock);
> > > > > +
> > > > > + /* Allow for the PWM hardware to finish its last
> > > > > toggle.
> > > > > The pulse
> > > > > + ?* may have just started and thus we should wait a
> > > > > full
> > > > > period.
> > > > > + ?*/
> > > > > + ndelay(pwm_get_period(pwm));
> > > >
> > > > Can't that use the ready bit as well?
> > > It depends whatever is cheaper. If we disable the pwm, we have to
> > > commit that request to hardware first. Then we have to read back
> > > the
> > > has ready and in the strange situation it is not, wait for it to
> > > become
> > > ready?
> >
> > If it works like you were suggesting, yes.
> >
> > >
> > > Also, that would mean we would loop in a spin lock, or keep
> > > setting/clearing an additional spinlock to read the ready bit.
> >
> > You're using a spin_lock, so it's not that bad, but I was just
> > suggesting replacing the ndelay.
>
> If you say the spin_lock + wait for the ready is just as expensive as
> the ndelay, or the ndelay is less preferred, then I gladly make the
> change;
For the spin_lock part, I was just comparing it to a
spin_lock_irqsave, which is pretty expensive since it masks all the
interrupts in the system, introducing latencies.
> but I think we need the ndelay for the else where we do not
> have the ready flag (A10 or A13 iirc?)
Hmmmm, good point. But that would also apply to your second patch
then, wouldn't it?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160924/cb63cb8f/attachment.sig>
^ permalink raw reply
* [PATCH] drm/sun4i: rgb: Enable panel after controller
From: Maxime Ripard @ 2016-09-24 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB1PgaACukEj1jzUY-dQzbf50Em3h47KEsQu3rC3Jej=6Q@mail.gmail.com>
On Fri, Sep 23, 2016 at 11:43:55PM +1000, Jonathan Liu wrote:
> Hi Maxime,
>
> On 23 September 2016 at 23:16, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Thu, Sep 22, 2016 at 08:03:31AM +1000, Jonathan Liu wrote:
> >> Hi Maxime,
> >>
> >> On Thursday, 22 September 2016, Maxime Ripard <maxime.ripard@free-electrons.
> >> com> wrote:
> >>
> >> > On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote:
> >> > > The panel should be enabled after the controller so that the panel
> >> > > prepare/enable delays are properly taken into account. Similarly, the
> >> > > panel should be disabled before the controller so that the panel
> >> > > unprepare/disable delays are properly taken into account.
> >> > >
> >> > > This is useful for avoiding visual glitches.
> >> >
> >> > This is not really taking any delays into account, especially since
> >> > drm_panel_enable and prepare are suppose to block until their
> >> > operation is complete.
> >>
> >>
> >> drm_panel_prepare turns on power to the LCD using enable-gpios property of
> >> the panel and then blocks for prepare delay. The prepare delay for panel
> >> can be set to how long it takes between the time the panel is powered to
> >> when it is ready to receive images. If backlight property is specified the
> >> backlight will be off while the panel is powered on.
> >>
> >> drm_panel_enable blocks for enable delay and then turns on the backlight.
> >> The enable delay can be set to how long it takes for panel to start making
> >> the image visible after receiving the first valid frame. For example if the
> >> panel starts off as white and the TFT takes some time to initialize to
> >> black before it shows the image being received.
> >>
> >> Refer to drivers/gpu/drm/panel-panel.simple.c for details.
> >
> > From drm_panel.h:
> >
> > """
> > * drm_panel_enable - enable a panel
> > * @panel: DRM panel
> > *
> > * Calling this function will cause the panel display drivers to be turned on
> > * and the backlight to be enabled. Content will be visible on screen after
> > * this call completes.
> > """
> >
> > """
> > * drm_panel_prepare - power on a panel
> > * @panel: DRM panel
> > *
> > * Calling this function will enable power and deassert any reset signals to
> > * the panel. After this has completed it is possible to communicate with any
> > * integrated circuitry via a command bus.
> > """
> >
> > Those comments clearly says that the caller should not have to deal
> > with the delays, even more so by just moving calls around and hoping
> > that the code running in between is adding enough delay for the panel
> > to behave properly.
> >
> > Maxime
> >
> > --
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_panel.h#n34
>
> In comment for struct drm_panel_funcs:
> /**
> * struct drm_panel_funcs - perform operations on a given panel
> * @disable: disable panel (turn off back light, etc.)
> * @unprepare: turn off panel
> * @prepare: turn on panel and perform set up
> * @enable: enable panel (turn on back light, etc.)
> * @get_modes: add modes to the connector that the panel is attached to and
> * return the number of modes added
> * @get_timings: copy display timings into the provided array and return
> * the number of display timings available
> *
> * The .prepare() function is typically called before the display controller
> * starts to transmit video data. Panel drivers can use this to turn the panel
> * on and wait for it to become ready. If additional configuration is required
> * (via a control bus such as I2C, SPI or DSI for example) this is a good time
> * to do that.
> *
> * After the display controller has started transmitting video data, it's safe
> * to call the .enable() function. This will typically enable the backlight to
> * make the image on screen visible. Some panels require a certain amount of
> * time or frames before the image is displayed. This function is responsible
> * for taking this into account before enabling the backlight to avoid visual
> * glitches.
> *
> * Before stopping video transmission from the display controller it can be
> * necessary to turn off the panel to avoid visual glitches. This is done in
> * the .disable() function. Analogously to .enable() this typically involves
> * turning off the backlight and waiting for some time to make sure no image
> * is visible on the panel. It is then safe for the display controller to
> * cease transmission of video data.
> *
> * To save power when no video data is transmitted, a driver can power down
> * the panel. This is the job of the .unprepare() function.
> */
It kind of make my point. When drm_panel_enable is called, the content
is visible, and there's no extra delay needed.
If what you want to fix is that the panel is enabled before the
controller, hence resulting in garbage on the screen while the
controller is setup, then your commit log is seriously misleading.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160924/15933e61/attachment.sig>
^ permalink raw reply
* [PATCH v6 3/3] ASoC: sun4i-codec: Add custom regmap configs
From: Danny Milosavljevic @ 2016-09-24 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160924200503.10728-1-dannym@scratchpost.org>
The A20 has a few extra registers that the A10 doesn't have.
Therefore, use different regmaps for A10 as compared to A20.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
---
sound/soc/sunxi/sun4i-codec.c | 38 +++++++++++++++++++++++++++++++++++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 3b53b78..e047ec0 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -682,12 +682,37 @@ static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
+ .max_register = SUN4I_CODEC_ADC_RXCNT,
+};
+
+static const struct regmap_config sun7i_codec_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
.max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
+struct sun4i_codec_quirks {
+ const struct regmap_config *regmap_config;
+};
+
+static const struct sun4i_codec_quirks sun4i_codec_quirks = {
+ .regmap_config = &sun4i_codec_regmap_config,
+};
+
+static const struct sun4i_codec_quirks sun7i_codec_quirks = {
+ .regmap_config = &sun7i_codec_regmap_config,
+};
+
static const struct of_device_id sun4i_codec_of_match[] = {
- { .compatible = "allwinner,sun4i-a10-codec" },
- { .compatible = "allwinner,sun7i-a20-codec" },
+ {
+ .compatible = "allwinner,sun4i-a10-codec",
+ .data = &sun4i_codec_quirks,
+ },
+ {
+ .compatible = "allwinner,sun7i-a20-codec",
+ .data = &sun7i_codec_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
@@ -760,6 +785,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
{
struct snd_soc_card *card;
struct sun4i_codec *scodec;
+ const struct sun4i_codec_quirks *quirks;
struct resource *res;
void __iomem *base;
int ret;
@@ -777,8 +803,14 @@ static int sun4i_codec_probe(struct platform_device *pdev)
return PTR_ERR(base);
}
+ quirks = of_device_get_match_data(&pdev->dev);
+ if (quirks == NULL) {
+ dev_err(&pdev->dev, "Failed to determine the quirks to use\n");
+ return -ENODEV;
+ }
+
scodec->regmap = devm_regmap_init_mmio(&pdev->dev, base,
- &sun4i_codec_regmap_config);
+ quirks->regmap_config);
if (IS_ERR(scodec->regmap)) {
dev_err(&pdev->dev, "Failed to create our regmap\n");
return PTR_ERR(scodec->regmap);
^ permalink raw reply related
* [PATCH v6 2/3] ASoC: sun4i-codec: Rename some sun7i-only registers
From: Danny Milosavljevic @ 2016-09-24 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160924200503.10728-1-dannym@scratchpost.org>
Some of the registers defined in the driver are only usable on the
A20. Rename these registers.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
---
sound/soc/sunxi/sun4i-codec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index c2c0583..3b53b78 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -96,8 +96,8 @@
/* Other various ADC registers */
#define SUN4I_CODEC_DAC_TXCNT (0x30)
#define SUN4I_CODEC_ADC_RXCNT (0x34)
-#define SUN4I_CODEC_AC_SYS_VERI (0x38)
-#define SUN4I_CODEC_AC_MIC_PHONE_CAL (0x3c)
+#define SUN7I_CODEC_AC_DAC_CAL (0x38)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
struct sun4i_codec {
struct device *dev;
@@ -682,7 +682,7 @@ static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
- .max_register = SUN4I_CODEC_AC_MIC_PHONE_CAL,
+ .max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
static const struct of_device_id sun4i_codec_of_match[] = {
^ permalink raw reply related
* [PATCH v6 1/3] ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency
From: Danny Milosavljevic @ 2016-09-24 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160924200503.10728-1-dannym@scratchpost.org>
Rename "sun4i_codec_widgets" to "sun4i_codec_controls" for
consistency with the struct field name.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
---
sound/soc/sunxi/sun4i-codec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 0e19c50..c2c0583 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -509,7 +509,7 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
-static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
+static const struct snd_kcontrol_new sun4i_codec_controls[] = {
SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
sun4i_codec_pa_volume_scale),
@@ -629,8 +629,8 @@ static const struct snd_soc_dapm_route sun4i_codec_codec_dapm_routes[] = {
static struct snd_soc_codec_driver sun4i_codec_codec = {
.component_driver = {
- .controls = sun4i_codec_widgets,
- .num_controls = ARRAY_SIZE(sun4i_codec_widgets),
+ .controls = sun4i_codec_controls,
+ .num_controls = ARRAY_SIZE(sun4i_codec_controls),
.dapm_widgets = sun4i_codec_codec_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
.dapm_routes = sun4i_codec_codec_dapm_routes,
^ permalink raw reply related
* [PATCH v6 0/3] ASoC: sun4i-codec: Distinguish sun4i from sun7i
From: Danny Milosavljevic @ 2016-09-24 20:05 UTC (permalink / raw)
To: linux-arm-kernel
Introduce mechanism to detect sun7i and provide a different regmap
(different compared to sun4i Allwinner A10).
The controls will be extended in a forthcoming patch - it is necessary
to distinguish between sun4i and sun7i controls because they have different
registers.
Rename SUN4I_CODEC_AC_SYS_VERI to SUN7I_CODEC_AC_DAC_CAL and rename
SUN4I_CODEC_AC_MIC_PHONE_CAL to SUN7I_CODEC_AC_MIC_PHONE_CAL because these
are actually not present on Allwinner A10.
Handle quirks by regmap config and codec and select the correct quirks
automatically.
Danny Milosavljevic (3):
ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency
ASoC: sun4i-codec: Rename some sun7i-only registers
ASoC: sun4i-codec: Add custom regmap configs
sound/soc/sunxi/sun4i-codec.c | 50 +++++++++++++++++++++++++++++++++++--------
1 file changed, 41 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH v3 2/2] ASoC: rockchip: Add DP dai-links to the rk3399-gru machine driver
From: Mark Brown @ 2016-09-24 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473396235-11769-1-git-send-email-zyw@rock-chips.com>
On Thu, Sep 08, 2016 at 09:43:55PM -0700, Chris Zhong wrote:
> This patch adds DP audio output support to the rk3399-gru machine
> driver.
This doesn't apply against current code, please check and resend.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160924/e1cfac10/attachment.sig>
^ permalink raw reply
* [PATCH 4/5] input: touchscreen: support Allwinner SoCs' touchscreen
From: Dmitry Torokhov @ 2016-09-24 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ca39a2e7-6116-6f6e-3f61-78abfdefcbb7@free-electrons.com>
Hi Quentin,
On Sat, Sep 24, 2016 at 08:26:08PM +0200, Quentin Schulz wrote:
> Hi Dimitry,
>
> Sorry for the (long) delay, I did not have time to work on it. I'll
> mainly work in my free time now.
>
> On 20/07/2016 19:25, Dmitry Torokhov wrote:
> > Hi Quentin,
> >
> > On Wed, Jul 20, 2016 at 10:29:10AM +0200, Quentin Schulz wrote:
> >> This adds support for Allwinner SoCs' (A10, A13 and A31) resistive
> >> touchscreen. This driver is probed by the MFD sunxi-gpadc-mfd.
> >>
> >> This driver uses ADC channels exposed through the IIO framework by
> >> sunxi-gpadc-iio to get its data. When opening this input device, it will
> >> start buffering in the ADC driver and enable a TP_UP_PENDING irq. The ADC
> >> driver will fill in a buffer with all data and call the callback the input
> >> device associated with this buffer. The input device will then read the
> >> buffer two by two and send X and Y coordinates to the input framework based
> >> on what it received from the ADC's buffer. When closing this input device,
> >> the buffering is stopped.
> >>
> >> Note that locations in the first received buffer after an TP_UP_PENDING irq
> >> occurred are unreliable, thus dropped.
> >>
> >> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> >> ---
> [...]
> >> + info->buffer = iio_channel_get_all_cb(&pdev->dev,
> >> + &sunxi_gpadc_ts_callback,
> >> + (void *)info);
> >
> > Any chance we could introduce devm-variant here? If you do not want to
> > wait for IIO to add it you can temporarily add call
> > devm_add_action_or_reset() after getting channels and remove it when IIO
> > API catches up.
> >
>
> Something like:
>
> release_iio_channels(void* data)
> {
> struct sunxi_gpadc_ts *info = data;
> iio_channel_release_all_cb(info->buffer);
> }
>
> [...]
> info->buffer = iio_channel_get_all_cb(&pdev->dev,
> &sunxi_gpadc_ts_callback,
> (void *)info);
> ret = devm_add_action_or_reset(&pdev->dev,
> release_iio_channels,
> (void *)info);
> if (ret)
> return ret;
>
> ?
>
> May I know why you prefer that way instead of explicit removing in
> remove function of the platform device? I understand for devm-variant
> already in the framework but I am curious for this one.
So that you release all resources in the same order they were allocated.
When mixing devm and non-devm allocation/release order is often
incorrect.
>
> [...]
> >> +static int sunxi_gpadc_ts_remove(struct platform_device *pdev)
> >> +{
> >> + struct sunxi_gpadc_ts *info = platform_get_drvdata(pdev);
> >> +
> >> + iio_channel_stop_all_cb(info->buffer);
> >> + iio_channel_release_all_cb(info->buffer);
> >> +
> >> + disable_irq(info->tp_up_irq);
> >
> > You are mixing devm and non-devm so your unwind order is completely out
> > of wack. If input device is opened while you are unloading (or
> > unbinding) the dirver, then you'll release channels, then input device's
> > close() will be called, which will try to stop the IIO channels again
> > and disable IRQ yet again.
> >
>
> Do you mean that I should be using exclusively devm or non-devm functions?
Yes. Sometimes you can get away with mixing style (you have all devm
resources allocated first, then non-devm), but it is much clearer and
safer if you use one style or another exclusively.
> Do you mean input device's close will always be called when
> unloading/unbinding the driver?
If ->open() has been called() then input core will ensure that ->close()
is called as part of input_unregister_device(). If ->open() has not been
called, then ->close() will not be called either.
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 4/5] input: touchscreen: support Allwinner SoCs' touchscreen
From: Quentin Schulz @ 2016-09-24 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160720172532.GE25655@dtor-ws>
Hi Dimitry,
Sorry for the (long) delay, I did not have time to work on it. I'll
mainly work in my free time now.
On 20/07/2016 19:25, Dmitry Torokhov wrote:
> Hi Quentin,
>
> On Wed, Jul 20, 2016 at 10:29:10AM +0200, Quentin Schulz wrote:
>> This adds support for Allwinner SoCs' (A10, A13 and A31) resistive
>> touchscreen. This driver is probed by the MFD sunxi-gpadc-mfd.
>>
>> This driver uses ADC channels exposed through the IIO framework by
>> sunxi-gpadc-iio to get its data. When opening this input device, it will
>> start buffering in the ADC driver and enable a TP_UP_PENDING irq. The ADC
>> driver will fill in a buffer with all data and call the callback the input
>> device associated with this buffer. The input device will then read the
>> buffer two by two and send X and Y coordinates to the input framework based
>> on what it received from the ADC's buffer. When closing this input device,
>> the buffering is stopped.
>>
>> Note that locations in the first received buffer after an TP_UP_PENDING irq
>> occurred are unreliable, thus dropped.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>> ---
[...]
>> + info->buffer = iio_channel_get_all_cb(&pdev->dev,
>> + &sunxi_gpadc_ts_callback,
>> + (void *)info);
>
> Any chance we could introduce devm-variant here? If you do not want to
> wait for IIO to add it you can temporarily add call
> devm_add_action_or_reset() after getting channels and remove it when IIO
> API catches up.
>
Something like:
release_iio_channels(void* data)
{
struct sunxi_gpadc_ts *info = data;
iio_channel_release_all_cb(info->buffer);
}
[...]
info->buffer = iio_channel_get_all_cb(&pdev->dev,
&sunxi_gpadc_ts_callback,
(void *)info);
ret = devm_add_action_or_reset(&pdev->dev,
release_iio_channels,
(void *)info);
if (ret)
return ret;
?
May I know why you prefer that way instead of explicit removing in
remove function of the platform device? I understand for devm-variant
already in the framework but I am curious for this one.
[...]
>> +static int sunxi_gpadc_ts_remove(struct platform_device *pdev)
>> +{
>> + struct sunxi_gpadc_ts *info = platform_get_drvdata(pdev);
>> +
>> + iio_channel_stop_all_cb(info->buffer);
>> + iio_channel_release_all_cb(info->buffer);
>> +
>> + disable_irq(info->tp_up_irq);
>
> You are mixing devm and non-devm so your unwind order is completely out
> of wack. If input device is opened while you are unloading (or
> unbinding) the dirver, then you'll release channels, then input device's
> close() will be called, which will try to stop the IIO channels again
> and disable IRQ yet again.
>
Do you mean that I should be using exclusively devm or non-devm functions?
Do you mean input device's close will always be called when
unloading/unbinding the driver?
[...]
Thanks,
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ 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