* [PATCH 4/4] ARM: sa11x0/pxa: get rid of get_clock_tick_rate
From: Daniel Lezcano @ 2016-09-19 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-5-git-send-email-robert.jarzmik@free.fr>
On 19/09/2016 21:12, Robert Jarzmik wrote:
> The last user of this function is gone, so remove it. The clock API
> should now be used to get clock rates.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 3/4] watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
From: Daniel Lezcano @ 2016-09-19 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-4-git-send-email-robert.jarzmik@free.fr>
On 19/09/2016 21:12, Robert Jarzmik wrote:
> The OS timer rate used for the watchdog can now be fetched from the
> standard clock API. This will remove the last user of
> get_clock_tick_rate() in both pxa and sa11x0 architectures.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 2/4] ARM: sa11x0/pxa: acquire timer rate from the clock rate
From: Daniel Lezcano @ 2016-09-19 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-3-git-send-email-robert.jarzmik@free.fr>
On 19/09/2016 21:12, Robert Jarzmik wrote:
> As both pxa and sa1100 provide a clock to the timer, the rate can be
> inferred from the clock rather than hard encoded in a functional call.
>
> This patch changes the pxa timer to have a mandatory clock which is used
> as the timer rate.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
^ permalink raw reply
* [PATCH 17/19] power: reset: st: Remove obsolete platforms from dt doc
From: Sebastian Reichel @ 2016-09-19 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-18-git-send-email-peter.griffin@linaro.org>
Hi,
On Wed, Sep 14, 2016 at 02:27:55PM +0100, Peter Griffin wrote:
> This patch removes support for STiH415/6 SoC's from the
> st-restart dt binding documentation, as support for these
> platforms is being removed from the kernel. It also updates
> the dt example to a currently supported platform.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Also queued to power-supply's for-next branch.
-- Sebastian
-------------- 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/20160919/b61ceb5f/attachment-0001.sig>
^ permalink raw reply
* [PATCH 16/19] power: reset: st-poweroff: Remove obsolete platforms.
From: Sebastian Reichel @ 2016-09-19 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473859677-9231-17-git-send-email-peter.griffin@linaro.org>
Hi,
On Wed, Sep 14, 2016 at 02:27:54PM +0100, Peter Griffin wrote:
> This patch removes support for STiH415/6 SoC's from the
> st-poweroff driver, as support for these platforms is
> being removed from the kernel.
I queued this to power-supply's for-next branch. Please
cc me to full thread next time, so that I can see what
is goin on.
-- Sebastian
-------------- 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/20160919/fa4c20cc/attachment.sig>
^ permalink raw reply
* [PATCH 1/4] clk: pxa25x: OSTIMER0 clocks from the main oscillator
From: Stephen Boyd @ 2016-09-19 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-2-git-send-email-robert.jarzmik@free.fr>
On 09/19, Robert Jarzmik wrote:
> From: Russell King - ARM Linux <linux@armlinux.org.uk>
>
> The OSTIMER0 clock ticks at the main oscillator rate, not the 32kHz
> oscillator rate. Ensure that it is parented to the main oscillator.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
> Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite
From: ayaka @ 2016-09-19 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Agngx7b24bo3w7S84xtwZV81c-wAszs0B96FZhMeMW8A@mail.gmail.com>
On 09/20/2016 03:12 AM, Fabio Estevam wrote:
> On Mon, Sep 19, 2016 at 4:02 PM, Randy Li <ayaka@soulik.info> wrote:
>
>> + vcc_sys_lcd: sys-lcd {
>> + compatible = "regulator-fixed";
>> + regulator-name = "vcc_5v";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
> Is this really active high? If so, you should add the
> 'enable-active-high' property.
I see, thank you. Btw, let me make it clearly, it is really an
independentTransistor, not be controlled by PMIC.
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Scott Wood @ 2016-09-19 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919170707.GC30584@leverpostej>
On Mon, 2016-09-19 at 18:07 +0100, Mark Rutland wrote:
> On Mon, Sep 19, 2016 at 12:01:29PM -0500, Scott Wood wrote:
> >
> > On Mon, 2016-09-19 at 17:52 +0100, Mark Rutland wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > > > > > +{
> > > > > > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > > > > > + if
> > > > > > (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > > > > > + return;
> > > > > > +
> > > > > > + if (arch_timer_uses_ppi == VIRT_PPI)
> > > > > > + clk->set_next_event =
> > > > > > fsl_a008585_set_next_event_virt;
> > > > > > + else
> > > > > > + clk->set_next_event =
> > > > > > fsl_a008585_set_next_event_phys;
> > > > > > +#endif
> > > > > > +}
> > > > > > +
> > > > > I'm not keen on the magic hook to reset the function pointers, and
> > > > > the
> > > > > additional phys/virt stubs seem pointless. Instead, can we fold this
> > > > > into the existing set_next_event? e.g. have that do:
> > > > >
> > > > > if (needs_fsl_a008585_workaround() {
> > > > > fsl_a008585_set_next_event(access, evt, clk);
> > > > > return;
> > > > > }
> > > > OK. ?I had been trying to avoid messing with the standard
> > > > set_next_event,
> > > > but
> > > > it doesn't matter as much now that static branches are being used. ?In
> > > > that
> > > > case we can avoid duplicating the ctrl code, and only replace the tval
> > > > write.
> > > Reconsidering my suggestion, I realise this will also affect the MMIO
> > > timers, so that doesn't work.
> > >
> > > So for the moment, I guess we have to keep fsl_a008585_set_next_event().
> > What is the problem with MMIO timers? ?needs_fsl_a008585_workaround()
> > should
> > always be false for them.
> As suggested, needs_fsl_a008585_workaround() takes no parameter, and
> set_next_event is called for both cp15/sysreg and MMIO timers. So it
> would either be true for all, or false for all.
>
> If it's true for all, we'd end up calling fsl_a008585_set_next_event()
> for the MMIO timers too.
There should not be any MMIO timers on a system where
fsl_a008585_set_next_event() returns true.
-Scott
^ permalink raw reply
* [RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite
From: Fabio Estevam @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474311771-23321-2-git-send-email-ayaka@soulik.info>
On Mon, Sep 19, 2016 at 4:02 PM, Randy Li <ayaka@soulik.info> wrote:
> + vcc_sys_lcd: sys-lcd {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_5v";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
Is this really active high? If so, you should add the
'enable-active-high' property.
^ permalink raw reply
* [PATCH 4/4] ARM: sa11x0/pxa: get rid of get_clock_tick_rate
From: Robert Jarzmik @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-1-git-send-email-robert.jarzmik@free.fr>
The last user of this function is gone, so remove it. The clock API
should now be used to get clock rates.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/generic.c | 15 ---------------
arch/arm/mach-pxa/include/mach/hardware.h | 2 --
arch/arm/mach-sa1100/include/mach/hardware.h | 4 ----
3 files changed, 21 deletions(-)
diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index 2a9297991d74..cb73a9723d0e 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -43,21 +43,6 @@ void clear_reset_status(unsigned int mask)
}
}
-unsigned long get_clock_tick_rate(void)
-{
- unsigned long clock_tick_rate;
-
- if (cpu_is_pxa25x())
- clock_tick_rate = 3686400;
- else if (machine_is_mainstone())
- clock_tick_rate = 3249600;
- else
- clock_tick_rate = 3250000;
-
- return clock_tick_rate;
-}
-EXPORT_SYMBOL(get_clock_tick_rate);
-
/*
* For non device-tree builds, keep legacy timer init
*/
diff --git a/arch/arm/mach-pxa/include/mach/hardware.h b/arch/arm/mach-pxa/include/mach/hardware.h
index 8d63c211b22f..55064124ca4e 100644
--- a/arch/arm/mach-pxa/include/mach/hardware.h
+++ b/arch/arm/mach-pxa/include/mach/hardware.h
@@ -303,8 +303,6 @@
*/
extern unsigned int get_memclk_frequency_10khz(void);
-/* return the clock tick rate of the OS timer */
-extern unsigned long get_clock_tick_rate(void);
#endif
#endif /* _ASM_ARCH_HARDWARE_H */
diff --git a/arch/arm/mach-sa1100/include/mach/hardware.h b/arch/arm/mach-sa1100/include/mach/hardware.h
index cbedd75a9d65..474844a93e29 100644
--- a/arch/arm/mach-sa1100/include/mach/hardware.h
+++ b/arch/arm/mach-sa1100/include/mach/hardware.h
@@ -61,10 +61,6 @@
# define __REG(x) (*((volatile unsigned long __iomem *)io_p2v(x)))
# define __PREG(x) (io_v2p((unsigned long)&(x)))
-static inline unsigned long get_clock_tick_rate(void)
-{
- return 3686400;
-}
#else
# define __REG(x) io_p2v(x)
--
2.1.4
^ permalink raw reply related
* [PATCH 3/4] watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
From: Robert Jarzmik @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-1-git-send-email-robert.jarzmik@free.fr>
The OS timer rate used for the watchdog can now be fetched from the
standard clock API. This will remove the last user of
get_clock_tick_rate() in both pxa and sa11x0 architectures.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/watchdog/sa1100_wdt.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/sa1100_wdt.c b/drivers/watchdog/sa1100_wdt.c
index e1d39a1e9628..8965e3f536c3 100644
--- a/drivers/watchdog/sa1100_wdt.c
+++ b/drivers/watchdog/sa1100_wdt.c
@@ -22,6 +22,7 @@
#include <linux/module.h>
#include <linux/moduleparam.h>
+#include <linux/clk.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/fs.h>
@@ -155,12 +156,27 @@ static struct miscdevice sa1100dog_miscdev = {
};
static int margin __initdata = 60; /* (secs) Default is 1 minute */
+static struct clk *clk;
static int __init sa1100dog_init(void)
{
int ret;
- oscr_freq = get_clock_tick_rate();
+ clk = clk_get(NULL, "OSTIMER0");
+ if (IS_ERR(clk)) {
+ pr_err("SA1100/PXA2xx Watchdog Timer: clock not found: %d\n",
+ (int) PTR_ERR(clk));
+ return PTR_ERR(clk);
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ pr_err("SA1100/PXA2xx Watchdog Timer: clock failed to prepare+enable: %d\n",
+ ret);
+ goto err;
+ }
+
+ oscr_freq = clk_get_rate(clk);
/*
* Read the reset status, and save it for later. If
@@ -176,11 +192,17 @@ static int __init sa1100dog_init(void)
pr_info("SA1100/PXA2xx Watchdog Timer: timer margin %d sec\n",
margin);
return ret;
+err:
+ clk_disable_unprepare(clk);
+ clk_put(clk);
+ return ret;
}
static void __exit sa1100dog_exit(void)
{
misc_deregister(&sa1100dog_miscdev);
+ clk_disable_unprepare(clk);
+ clk_put(clk);
}
module_init(sa1100dog_init);
--
2.1.4
^ permalink raw reply related
* [PATCH 2/4] ARM: sa11x0/pxa: acquire timer rate from the clock rate
From: Robert Jarzmik @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-1-git-send-email-robert.jarzmik@free.fr>
As both pxa and sa1100 provide a clock to the timer, the rate can be
inferred from the clock rather than hard encoded in a functional call.
This patch changes the pxa timer to have a mandatory clock which is used
as the timer rate.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/generic.c | 3 +--
arch/arm/mach-sa1100/generic.c | 2 +-
drivers/clocksource/pxa_timer.c | 11 +++++------
include/clocksource/pxa.h | 3 +--
4 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index ec510ecf8370..2a9297991d74 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -69,8 +69,7 @@ void __init pxa_timer_init(void)
pxa27x_clocks_init();
if (cpu_is_pxa3xx())
pxa3xx_clocks_init();
- pxa_timer_nodt_init(IRQ_OST0, io_p2v(0x40a00000),
- get_clock_tick_rate());
+ pxa_timer_nodt_init(IRQ_OST0, io_p2v(0x40a00000));
}
/*
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index 3e09beddb6e8..2eb00691b07d 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -378,7 +378,7 @@ void __init sa1100_map_io(void)
void __init sa1100_timer_init(void)
{
- pxa_timer_nodt_init(IRQ_OST0, io_p2v(0x90000000), 3686400);
+ pxa_timer_nodt_init(IRQ_OST0, io_p2v(0x90000000));
}
static struct resource irq_resource =
diff --git a/drivers/clocksource/pxa_timer.c b/drivers/clocksource/pxa_timer.c
index 3e1cb512f3ce..9cae38eebec2 100644
--- a/drivers/clocksource/pxa_timer.c
+++ b/drivers/clocksource/pxa_timer.c
@@ -220,17 +220,16 @@ CLOCKSOURCE_OF_DECLARE(pxa_timer, "marvell,pxa-timer", pxa_timer_dt_init);
/*
* Legacy timer init for non device-tree boards.
*/
-void __init pxa_timer_nodt_init(int irq, void __iomem *base,
- unsigned long clock_tick_rate)
+void __init pxa_timer_nodt_init(int irq, void __iomem *base)
{
struct clk *clk;
timer_base = base;
clk = clk_get(NULL, "OSTIMER0");
- if (clk && !IS_ERR(clk))
+ if (clk && !IS_ERR(clk)) {
clk_prepare_enable(clk);
- else
+ pxa_timer_common_init(irq, clk_get_rate(clk));
+ } else {
pr_crit("%s: unable to get clk\n", __func__);
-
- pxa_timer_common_init(irq, clock_tick_rate);
+ }
}
diff --git a/include/clocksource/pxa.h b/include/clocksource/pxa.h
index 1efbe5a66958..a9a0f03024a4 100644
--- a/include/clocksource/pxa.h
+++ b/include/clocksource/pxa.h
@@ -12,7 +12,6 @@
#ifndef _CLOCKSOURCE_PXA_H
#define _CLOCKSOURCE_PXA_H
-extern void pxa_timer_nodt_init(int irq, void __iomem *base,
- unsigned long clock_tick_rate);
+extern void pxa_timer_nodt_init(int irq, void __iomem *base);
#endif
--
2.1.4
^ permalink raw reply related
* [PATCH 1/4] clk: pxa25x: OSTIMER0 clocks from the main oscillator
From: Robert Jarzmik @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-1-git-send-email-robert.jarzmik@free.fr>
From: Russell King - ARM Linux <linux@armlinux.org.uk>
The OSTIMER0 clock ticks at the main oscillator rate, not the 32kHz
oscillator rate. Ensure that it is parented to the main oscillator.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
drivers/clk/pxa/clk-pxa25x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/pxa/clk-pxa25x.c b/drivers/clk/pxa/clk-pxa25x.c
index a98b98e2a9e4..56b0a6027e38 100644
--- a/drivers/clk/pxa/clk-pxa25x.c
+++ b/drivers/clk/pxa/clk-pxa25x.c
@@ -230,7 +230,7 @@ static struct dummy_clk dummy_clks[] __initdata = {
DUMMY_CLK("GPIO11_CLK", NULL, "osc_3_6864mhz"),
DUMMY_CLK("GPIO12_CLK", NULL, "osc_32_768khz"),
DUMMY_CLK(NULL, "sa1100-rtc", "osc_32_768khz"),
- DUMMY_CLK("OSTIMER0", NULL, "osc_32_768khz"),
+ DUMMY_CLK("OSTIMER0", NULL, "osc_3_6864mhz"),
DUMMY_CLK("UARTCLK", "pxa2xx-ir", "STUART"),
};
--
2.1.4
^ permalink raw reply related
* [PATCH 0/4] kill get_clock_tick_rate()
From: Robert Jarzmik @ 2016-09-19 19:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This serie aims at killing get_clock_tick_rate() from pxa and sa1100 and replace
it by clock API calls.
I'd like to have this reviewed and acked afterwards at least by :
- Russell for the mach-sa1100 and sa1100_wdt.c
- Stephen or Michael for the clk-pxa25x.c
- Thomas or Daniel for the clocksource part
- Wim for sa1100_wdt.c
If the review converges, I'd also like to take it through the pxa/for-next tree,
or alternatively Russell's tree if there is a dependency I'm not seeing, for
v4.10 cycle.
Cheers.
Robert Jarzmik (3):
ARM: sa11x0/pxa: acquire timer rate from the clock rate
watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
ARM: sa11x0/pxa: get rid of get_clock_tick_rate
Russell King - ARM Linux (1):
clk: pxa25x: OSTIMER0 clocks from the main oscillator
arch/arm/mach-pxa/generic.c | 18 +-----------------
arch/arm/mach-pxa/include/mach/hardware.h | 2 --
arch/arm/mach-sa1100/generic.c | 2 +-
arch/arm/mach-sa1100/include/mach/hardware.h | 4 ----
drivers/clk/pxa/clk-pxa25x.c | 2 +-
drivers/clocksource/pxa_timer.c | 11 +++++------
drivers/watchdog/sa1100_wdt.c | 24 +++++++++++++++++++++++-
include/clocksource/pxa.h | 3 +--
8 files changed, 32 insertions(+), 34 deletions(-)
--
2.1.4
^ permalink raw reply
* [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel
From: Randy Li @ 2016-09-19 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474311771-23321-1-git-send-email-ayaka@soulik.info>
The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
supported by the simple panel driver.
Signed-off-by: Randy Li <ayaka@soulik.info>
---
.../display/panel/chunghwa,claa070wp03xg.txt | 7 ++++++
drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
diff --git a/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
new file mode 100644
index 0000000..dd22685
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
@@ -0,0 +1,7 @@
+Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "chunghwa,claa070wp03xg"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index f178998..3204e6b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -583,6 +583,30 @@ static const struct panel_desc avic_tm070ddh03 = {
},
};
+static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
+ .clock = 66770,
+ .hdisplay = 800,
+ .hsync_start = 800 + 49,
+ .hsync_end = 800 + 49 + 33,
+ .htotal = 800 + 49 + 33 + 17,
+ .vdisplay = 1280,
+ .vsync_start = 1280 + 1,
+ .vsync_end = 1280 + 1 + 7,
+ .vtotal = 1280 + 1 + 7 + 15,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc chunghwa_claa070wp03xg = {
+ .modes = &chunghwa_claa070wp03xg_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 94,
+ .height = 150,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
.clock = 72070,
.hdisplay = 1366,
@@ -1544,6 +1568,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "avic,tm070ddh03",
.data = &avic_tm070ddh03,
}, {
+ .compatible = "chunghwa,claa070wp03xg",
+ .data = &chunghwa_claa070wp03xg,
+ }, {
.compatible = "chunghwa,claa101wa01a",
.data = &chunghwa_claa101wa01a
}, {
--
2.7.4
^ permalink raw reply related
* [RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite
From: Randy Li @ 2016-09-19 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474311771-23321-1-git-send-email-ayaka@soulik.info>
It is actually a lvds panel connected through a rga-lvds bridge.
The touchscreen is communicated with i2c bus but the driver is not
support now.
Signed-off-by: Randy Li <ayaka@soulik.info>
---
arch/arm/boot/dts/exynos4412-itop-elite.dts | 54 +++++++++++++++++++++++++++--
1 file changed, 52 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts b/arch/arm/boot/dts/exynos4412-itop-elite.dts
index b08705e..5153522 100644
--- a/arch/arm/boot/dts/exynos4412-itop-elite.dts
+++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts
@@ -138,6 +138,36 @@
assigned-clocks = <&clock CLK_MOUT_CAM0>;
assigned-clock-parents = <&clock CLK_XUSBXTI>;
};
+
+ vcc_sys_lcd: sys-lcd {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>;
+ };
+
+ panel: panel at 0 {
+ compatible = "chunghwa,claa070wp03xg";
+
+ power-supply = <&vcc_sys_lcd>;
+ enable-gpios = <&gpl0 2 GPIO_ACTIVE_HIGH>;
+ backlight = <&bl>;
+
+ port {
+ lcd_ep: endpoint {
+ remote-endpoint = <&rga_lvds>;
+ };
+ };
+ };
+
+ bl: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 1 5000000 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 5 12 16 32 64 128 255>;
+ default-brightness-level = <5>;
+ power-supply = <&vcc_sys_lcd>;
+ };
};
&adc {
@@ -171,11 +201,31 @@
assigned-clock-rates = <0>, <176000000>;
};
+&fimd {
+ pinctrl-0 = <&lcd_clk &lcd_data24>;
+ pinctrl-names = "default";
+ status = "okay";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 3 {
+ reg = <3>;
+ rga_lvds: endpoint {
+ remote-endpoint = <&lcd_ep>;
+ };
+ };
+ };
+};
+
&hsotg {
dr_mode = "peripheral";
status = "okay";
};
+&i2c_3 {
+ status = "okay";
+};
+
&i2c_4 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-slave-addr = <0x10>;
@@ -215,9 +265,9 @@
&pwm {
status = "okay";
- pinctrl-0 = <&pwm0_out>;
+ pinctrl-0 = <&pwm0_out &pwm1_out>;
pinctrl-names = "default";
- samsung,pwm-outputs = <0>;
+ samsung,pwm-outputs = <0>, <1>;
};
&sdhci_2 {
--
2.7.4
^ permalink raw reply related
* [RFC PATCH v3 0/2] adding panel claa070wp03xg support for exynos
From: Randy Li @ 2016-09-19 19:02 UTC (permalink / raw)
To: linux-arm-kernel
The timings issue is still here, this version is just some modifications
in dts file.
Randy Li (2):
ARM: dts: samsung: add rga-lvds panel in itop elite
drm/panel: Add support for Chunghwa CLAA070WP03XG panel
.../display/panel/chunghwa,claa070wp03xg.txt | 7 +++
arch/arm/boot/dts/exynos4412-itop-elite.dts | 54 +++++++++++++++++++++-
drivers/gpu/drm/panel/panel-simple.c | 27 +++++++++++
3 files changed, 86 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
--
2.7.4
^ permalink raw reply
* [PATCH v3] ASoC: exynos: organize the asoc audio into a menu
From: Randy Li @ 2016-09-19 18:57 UTC (permalink / raw)
To: linux-arm-kernel
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>
---
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 7b722b0..f6023b4 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.7.4
^ permalink raw reply related
* [PATCH] arm64, numa: Add cpu_to_node() implementation.
From: David Daney @ 2016-09-19 18:49 UTC (permalink / raw)
To: linux-arm-kernel
From: David Daney <david.daney@cavium.com>
The wq_numa_init() function makes a private CPU to node map by calling
cpu_to_node() early in the boot process, before the non-boot CPUs are
brought online. Since the default implementation of cpu_to_node()
returns zero for CPUs that have never been brought online, the
workqueue system's view is that *all* CPUs are on node zero.
When the unbound workqueue for a non-zero node is created, the
tsk_cpus_allowed() for the worker threads is the empty set because
there are, in the view of the workqueue system, no CPUs on non-zero
nodes. The code in try_to_wake_up() using this empty cpumask ends up
using the cpumask empty set value of NR_CPUS as an index into the
per-CPU area pointer array, and gets garbage as it is one past the end
of the array. This results in:
[ 0.881970] Unable to handle kernel paging request at virtual address fffffb1008b926a4
[ 1.970095] pgd = fffffc00094b0000
[ 1.973530] [fffffb1008b926a4] *pgd=0000000000000000, *pud=0000000000000000, *pmd=0000000000000000
[ 1.982610] Internal error: Oops: 96000004 [#1] SMP
[ 1.987541] Modules linked in:
[ 1.990631] CPU: 48 PID: 295 Comm: cpuhp/48 Tainted: G W 4.8.0-rc6-preempt-vol+ #9
[ 1.999435] Hardware name: Cavium ThunderX CN88XX board (DT)
[ 2.005159] task: fffffe0fe89cc300 task.stack: fffffe0fe8b8c000
[ 2.011158] PC is at try_to_wake_up+0x194/0x34c
[ 2.015737] LR is at try_to_wake_up+0x150/0x34c
[ 2.020318] pc : [<fffffc00080e7468>] lr : [<fffffc00080e7424>] pstate: 600000c5
[ 2.027803] sp : fffffe0fe8b8fb10
[ 2.031149] x29: fffffe0fe8b8fb10 x28: 0000000000000000
[ 2.036522] x27: fffffc0008c63bc8 x26: 0000000000001000
[ 2.041896] x25: fffffc0008c63c80 x24: fffffc0008bfb200
[ 2.047270] x23: 00000000000000c0 x22: 0000000000000004
[ 2.052642] x21: fffffe0fe89d25bc x20: 0000000000001000
[ 2.058014] x19: fffffe0fe89d1d00 x18: 0000000000000000
[ 2.063386] x17: 0000000000000000 x16: 0000000000000000
[ 2.068760] x15: 0000000000000018 x14: 0000000000000000
[ 2.074133] x13: 0000000000000000 x12: 0000000000000000
[ 2.079505] x11: 0000000000000000 x10: 0000000000000000
[ 2.084879] x9 : 0000000000000000 x8 : 0000000000000000
[ 2.090251] x7 : 0000000000000040 x6 : 0000000000000000
[ 2.095621] x5 : ffffffffffffffff x4 : 0000000000000000
[ 2.100991] x3 : 0000000000000000 x2 : 0000000000000000
[ 2.106364] x1 : fffffc0008be4c24 x0 : ffffff0ffffada80
[ 2.111737]
[ 2.113236] Process cpuhp/48 (pid: 295, stack limit = 0xfffffe0fe8b8c020)
[ 2.120102] Stack: (0xfffffe0fe8b8fb10 to 0xfffffe0fe8b90000)
[ 2.125914] fb00: fffffe0fe8b8fb80 fffffc00080e7648
.
.
.
[ 2.442859] Call trace:
[ 2.445327] Exception stack(0xfffffe0fe8b8f940 to 0xfffffe0fe8b8fa70)
[ 2.451843] f940: fffffe0fe89d1d00 0000040000000000 fffffe0fe8b8fb10 fffffc00080e7468
[ 2.459767] f960: fffffe0fe8b8f980 fffffc00080e4958 ffffff0ff91ab200 fffffc00080e4b64
[ 2.467690] f980: fffffe0fe8b8f9d0 fffffc00080e515c fffffe0fe8b8fa80 0000000000000000
[ 2.475614] f9a0: fffffe0fe8b8f9d0 fffffc00080e58e4 fffffe0fe8b8fa80 0000000000000000
[ 2.483540] f9c0: fffffe0fe8d10000 0000000000000040 fffffe0fe8b8fa50 fffffc00080e5ac4
[ 2.491465] f9e0: ffffff0ffffada80 fffffc0008be4c24 0000000000000000 0000000000000000
[ 2.499387] fa00: 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000040
[ 2.507309] fa20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 2.515233] fa40: 0000000000000000 0000000000000000 0000000000000000 0000000000000018
[ 2.523156] fa60: 0000000000000000 0000000000000000
[ 2.528089] [<fffffc00080e7468>] try_to_wake_up+0x194/0x34c
[ 2.533723] [<fffffc00080e7648>] wake_up_process+0x28/0x34
[ 2.539275] [<fffffc00080d3764>] create_worker+0x110/0x19c
[ 2.544824] [<fffffc00080d69dc>] alloc_unbound_pwq+0x3cc/0x4b0
[ 2.550724] [<fffffc00080d6bcc>] wq_update_unbound_numa+0x10c/0x1e4
[ 2.557066] [<fffffc00080d7d78>] workqueue_online_cpu+0x220/0x28c
[ 2.563234] [<fffffc00080bd288>] cpuhp_invoke_callback+0x6c/0x168
[ 2.569398] [<fffffc00080bdf74>] cpuhp_up_callbacks+0x44/0xe4
[ 2.575210] [<fffffc00080be194>] cpuhp_thread_fun+0x13c/0x148
[ 2.581027] [<fffffc00080dfbac>] smpboot_thread_fn+0x19c/0x1a8
[ 2.586929] [<fffffc00080dbd64>] kthread+0xdc/0xf0
[ 2.591776] [<fffffc0008083380>] ret_from_fork+0x10/0x50
[ 2.597147] Code: b00057e1 91304021 91005021 b8626822 (b8606821)
[ 2.603464] ---[ end trace 58c0cd36b88802bc ]---
[ 2.608138] Kernel panic - not syncing: Fatal exception
Fix by supplying a cpu_to_node() implementation that returns correct
node mappings.
Cc: <stable@vger.kernel.org> # 4.7.x-
Signed-off-by: David Daney <david.daney@cavium.com>
---
arch/arm64/include/asm/topology.h | 3 +++
arch/arm64/mm/numa.c | 18 ++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index 8b57339..8d935447 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -30,6 +30,9 @@ int pcibus_to_node(struct pci_bus *bus);
cpu_all_mask : \
cpumask_of_node(pcibus_to_node(bus)))
+int cpu_to_node(int cpu);
+#define cpu_to_node cpu_to_node
+
#endif /* CONFIG_NUMA */
#include <asm-generic/topology.h>
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 5bb15ea..e76281b 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -130,6 +130,24 @@ void __init early_map_cpu_to_node(unsigned int cpu, int nid)
cpu_to_node_map[cpu] = nid;
}
+int cpu_to_node(int cpu)
+{
+ int nid;
+
+ /*
+ * Return 0 for unknown mapping so that we report something
+ * sensible if firmware doesn't supply a proper mapping.
+ */
+ if (cpu < 0 || cpu >= NR_CPUS)
+ return 0;
+
+ nid = cpu_to_node_map[cpu];
+ if (nid == NUMA_NO_NODE)
+ nid = 0;
+ return nid;
+}
+EXPORT_SYMBOL(cpu_to_node);
+
/**
* numa_add_memblk - Set node id to memblk
* @nid: NUMA node ID of the new memblk
--
1.8.3.1
^ permalink raw reply related
* [RFC] arm64: Ensure proper addressing for ldnp/stnp
From: bdegraaf at codeaurora.org @ 2016-09-19 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50fcc549-d785-6332-83bd-292a4f44e8d4@redhat.com>
On 2016-09-19 14:28, Laura Abbott wrote:
> On 09/19/2016 10:36 AM, Brent DeGraaf wrote:
>> According to section 6.3.8 of the ARM Programmer's Guide, non-temporal
>> loads and stores do not verify that address dependency is met between
>> a
>> load of an address to a register and a subsequent non-temporal load or
>> store using that address on the executing PE. Therefore, context
>> switch
>> code and subroutine calls that use non-temporally accessed addresses
>> as
>> parameters that might depend on a load of an address into an argument
>> register must ensure that ordering requirements are met by introducing
>> a barrier prior to the successive non-temporal access. Add
>> appropriate
>> barriers whereever this specific situation comes into play.
>>
>
> Was this found by code inspection or is there a (public) exciting test
> case to observe this behavior?
>
> Thanks,
> Laura
>
Code inspection only.
Brent
^ permalink raw reply
* [PATCH] arm: dts: fix rk3066a based boards vdd_log voltage initialization
From: Boris Brezillon @ 2016-09-19 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=U_BQez2eCqm7mX9kj0dcEsnBKiFWcLAhXXJD+yTZhACw@mail.gmail.com>
On Mon, 19 Sep 2016 11:12:12 -0700
Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Mon, Sep 19, 2016 at 11:06 AM, Boris Brezillon
> <boris.brezillon@free-electrons.com> wrote:
> > On Mon, 19 Sep 2016 10:52:51 -0700
> > Doug Anderson <dianders@chromium.org> wrote:
> >
> >> Hi,
> >>
> >> On Mon, Sep 19, 2016 at 10:48 AM, Boris Brezillon
> >> <boris.brezillon@free-electrons.com> wrote:
> >> > The PWM chip has always claimed the pins and muxed them to the PWM IP.
> >> > So, this means it's broken from the beginning, and my patch is only
> >> > uncovering the problem (unless the pins stay configured as input until
> >> > the PWM is enabled, which I'm not sure is the case).
> >>
> >> Such a solution is achievable with the pinctrl APIs pretty easily.
> >> You might not be able to use the automatic "init" state but you can do
> >> something similar and switch to an "active" state once the PWM is
> >> actually turned on the first time.
> >
> > But is it really the case here (I don't see any code requesting a
> > specific pinmux depending on the PWM state)?
>
> It is not happening right now as far as I know. ...but that's a bug.
Okay.
>
> > Anyway, we really need to handle this case, we should define the
> > typical voltage when the PWM is disabled. Same as what you suggested
> > with voltage-when-input, but with a different naming (since the concept
> > of pinmux is PWM hardware/driver specific).
> >
> > voltage-when-pwm-disabled = <...>;
>
> Voltage when disabled and voltage when input are two different states.
> A disabled PWM will typically either drive high or low (depending on
> where it was when you turned it off). Not all "disabled" states will
> mean that the pin is configured as an input.
Well, my point was that, from the regulator PoV, a PWM is either
enabled or disabled. The pinmux config when the PWM is disabled
depends on the PWM driver/hardware, and I don't think it's a good idea
to expose this information at the regulator level, hence the name
"voltage-when-pwm-disabled". Anyway, let's stop bikeshedding, no
matter the name, I think we both agree that a new DT property is needed
to handle this case :-).
^ permalink raw reply
* [RFC] arm64: Ensure proper addressing for ldnp/stnp
From: Laura Abbott @ 2016-09-19 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474306586-25118-1-git-send-email-bdegraaf@codeaurora.org>
On 09/19/2016 10:36 AM, Brent DeGraaf wrote:
> According to section 6.3.8 of the ARM Programmer's Guide, non-temporal
> loads and stores do not verify that address dependency is met between a
> load of an address to a register and a subsequent non-temporal load or
> store using that address on the executing PE. Therefore, context switch
> code and subroutine calls that use non-temporally accessed addresses as
> parameters that might depend on a load of an address into an argument
> register must ensure that ordering requirements are met by introducing
> a barrier prior to the successive non-temporal access. Add appropriate
> barriers whereever this specific situation comes into play.
>
Was this found by code inspection or is there a (public) exciting test
case to observe this behavior?
Thanks,
Laura
> Signed-off-by: Brent DeGraaf <bdegraaf@codeaurora.org>
> ---
> arch/arm64/kernel/entry.S | 1 +
> arch/arm64/lib/copy_page.S | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 441420c..982c4d3 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -679,6 +679,7 @@ ENTRY(cpu_switch_to)
> ldp x27, x28, [x8], #16
> ldp x29, x9, [x8], #16
> ldr lr, [x8]
> + dmb nshld // Existence of instructions with loose load-use dependencies (e.g. ldnp/stnp) make this barrier necessary
> mov sp, x9
> and x9, x9, #~(THREAD_SIZE - 1)
> msr sp_el0, x9
> diff --git a/arch/arm64/lib/copy_page.S b/arch/arm64/lib/copy_page.S
> index 4c1e700..21c6892 100644
> --- a/arch/arm64/lib/copy_page.S
> +++ b/arch/arm64/lib/copy_page.S
> @@ -47,6 +47,8 @@ alternative_endif
> ldp x14, x15, [x1, #96]
> ldp x16, x17, [x1, #112]
>
> + dmb nshld // In case x0 (for stnp) is dependent on a load
> +
> mov x18, #(PAGE_SIZE - 128)
> add x1, x1, #128
> 1:
>
^ permalink raw reply
* [RFC] arm64: Ensure proper addressing for ldnp/stnp
From: bdegraaf at codeaurora.org @ 2016-09-19 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be5f5bfd-fd41-d202-cec9-0ca3fcad28db@arm.com>
On 2016-09-19 14:01, Robin Murphy wrote:
> On 19/09/16 18:36, Brent DeGraaf wrote:
>> According to section 6.3.8 of the ARM Programmer's Guide, non-temporal
>> loads and stores do not verify that address dependency is met between
>> a
>> load of an address to a register and a subsequent non-temporal load or
>> store using that address on the executing PE. Therefore, context
>> switch
>> code and subroutine calls that use non-temporally accessed addresses
>> as
>> parameters that might depend on a load of an address into an argument
>> register must ensure that ordering requirements are met by introducing
>> a barrier prior to the successive non-temporal access. Add
>> appropriate
>> barriers whereever this specific situation comes into play.
>>
>> Signed-off-by: Brent DeGraaf <bdegraaf@codeaurora.org>
>> ---
>> arch/arm64/kernel/entry.S | 1 +
>> arch/arm64/lib/copy_page.S | 2 ++
>> 2 files changed, 3 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index 441420c..982c4d3 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -679,6 +679,7 @@ ENTRY(cpu_switch_to)
>> ldp x27, x28, [x8], #16
>> ldp x29, x9, [x8], #16
>> ldr lr, [x8]
>> + dmb nshld // Existence of instructions with loose load-use
>> dependencies (e.g. ldnp/stnp) make this barrier necessary
>> mov sp, x9
>> and x9, x9, #~(THREAD_SIZE - 1)
>> msr sp_el0, x9
>> diff --git a/arch/arm64/lib/copy_page.S b/arch/arm64/lib/copy_page.S
>> index 4c1e700..21c6892 100644
>> --- a/arch/arm64/lib/copy_page.S
>> +++ b/arch/arm64/lib/copy_page.S
>> @@ -47,6 +47,8 @@ alternative_endif
>> ldp x14, x15, [x1, #96]
>> ldp x16, x17, [x1, #112]
>>
>> + dmb nshld // In case x0 (for stnp) is dependent on a load
>
> The ARMv8 ARM (B2.7.2 in issue j) says that when an address dependency
> exists between a load and a subsequent LDNP, *other* observers may
> observe those accesses in any order. How's that related to an STNP on
> the same CPU?
>
> Robin.
>
>> +
>> mov x18, #(PAGE_SIZE - 128)
>> add x1, x1, #128
>> 1:
>>
Yes, I have seen the section in the ARM ARM about this. But the
Programmer's Guide goes further, even providing a concrete example:
"Non-temporal loads and stores relax the memory ordering
requirements...the LDNP instruction might
be observed before the preceding LDR instruction, which can result in
reading from an unpredictable
address in X0.
For example:
LDR X0, [X3]
LDNP X2, X1, [X0]
To correct the above, you need an explicit load barrier:
LDR X0, [X3]
DMB NSHLD
LDNP X2, X1, [X0]"
Did the ARM ARM leave this out? Or is the Programmer's Guide section
incorrect?
Thanks for your comments,
Brent
^ permalink raw reply
* [PATCH v2 0/3] Armada 7k/8k CP110 system controller fixes
From: Marcin Wojtas @ 2016-09-19 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919181549.GE7243@codeaurora.org>
Sure, thanks. I'll send it right away.
Best regards,
Marcin
2016-09-19 20:15 GMT+02:00 Stephen Boyd <sboyd@codeaurora.org>:
> On 09/19, Marcin Wojtas wrote:
>> Hi Stephen,
>>
>> Did you have any chance to take a look at v2? Do you have any remarks?
>>
>
> Hmm I don't have any of these patches in my queue. Probably
> because there was some bug in the second patch so I assumed it
> would go for another round. Please fix that bug and resend.
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 0/3] Armada 7k/8k CP110 system controller fixes
From: Stephen Boyd @ 2016-09-19 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPv3WKdoas6nJngFh2bLU0wvz2OZMga6G40UMPkfz9aunRawVw@mail.gmail.com>
On 09/19, Marcin Wojtas wrote:
> Hi Stephen,
>
> Did you have any chance to take a look at v2? Do you have any remarks?
>
Hmm I don't have any of these patches in my queue. Probably
because there was some bug in the second patch so I assumed it
would go for another round. Please fix that bug and resend.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ 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