Re: [PATCH v1 0/6] misc: add reboot mode driver
Hi Arnd:
On 2015年12月28日 23:28, Arnd Bergmann wrote:
On Wednesday 23 December 2015 17:31:45 Andy Yan wrote:
I also have the idea to put is in drivers/power/reset, But considering
this driver have not bind anything about power, so I put it in
driver/misc
at last. So I hope if some people can give more suggestions here.
I vote for drivers/power/reset as well. On some platforms, the two things
are related, on others they are not, but it's good to have it all in one
place I think.
Okay, I will move to drivers/power/reset next version.
drivers/soc/rockchip/Kconfig | 9 ++
drivers/soc/rockchip/Makefile | 1 +
drivers/soc/rockchip/reboot.c | 68 +++
And maybe that part could be made generic instead of rockchip specific.
It simply uses a regmap to do the accesses, I guess a lot of other
platforms will do that. We have syscon-reboot and syscon-poweroff for example.
I think then we can extend the "framework" by having generic drivers to
store the value in eeprom or nvram for example.
I also hope the write interface can be generic. But I found some
platform
use different hardware to store the value. For example, John's patch
use
SRAM on qcom apq8064 to store value for nexus7. It seems there also have
some platform use dram or nvram to store it. And these different
hardware use
different write method. I don't have a generic way to handle this.
I have a idea to handle it like this:
+static const struct of_device_id reboot_mode_dt_match[] = {
+{ .compatible = "linux,reboot-mode-sfr",/*for magic value
stored in special function register, which can be accessed by regmap*/
+.data = (void *)&reboot-mode-sfr },
I'd make this one syscon-reboot-mode, to go along with syscon-poweroff
as implemented by drivers/power/reset/syscon-poweroff.c. The syscon concept
is already generic enough that we don't need a linux prefix for that.
Okay, syscon is better.
+{ .compatible = "linux,reboot-mode-sram", /*for magic value
stored in
+.data = (void *)&reboot-mode-sram },
the sram mode should probably follow the generic SRAM binding and make
the location that stores the reboot mode a separate partition, unless
we want to store other data in the same partition, in which case we might
want to use the same implementation as for the nvram.
+{ .compatible = "linux,reboot-mode-sdram",
+.data = (void *)&reboot-mode-sdram }, /*for magic value
stored
I think "sdram" is not an appropriate name here, as the main system memory
might use some other technology, e.g. DRAM or DDR2-SDRAM.
+{ .compatible = "rockchip,reboot-mode-nvram",
+.data = (void *)&reboot-mode-nvram },
+{},
+};
nvram is a complex topic by itself, because there are so many ways to do it.
I think what you are referring to here is a battery-backed memory that uses
one or more bytes at a fixed offset to store a particular piece of information,
as the drivers/char/nvram.c driver does. Maybe we should put the reboot mode
into that driver then?
There are other nvram drivers at various places in the kernel, and each may
be slightly different, or completely different, like the EFIVARs driver on
UEFI firmware or the key/value store on Open Firmware, these probably need
their own methods and not share the generic driver.
the data point to different hardware access method.
Hope to see more suggestions from you.
It's probably best to leave these four examples as separate drivers and we can
add further ones when needed.
Arnd
Okay, thanks for your suggestion. I will add the reboot-mode.c as
the core library, syscon-reboot-mode.c as one example first. As for
sram/dram/nvram case, I am not familiar with them, so hope there are
some hero will extend them when needed.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] PM/OPP: Set cpu_dev->id in cpumask first
On 28-12-15, 21:06, Pi-Cheng Chen wrote: > Set cpu_dev->id in cpumask first when setting up cpumask for CPUs that > share the same OPP table. This might be helpful when handling cpumask > without the original CPU bitfield set. > > Signed-off-by: Pi-Cheng Chen > --- > v1->v2: > - Set cpu_dev->id in cpumask at the top instead of skip it in the loop > --- > drivers/base/power/opp/cpu.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c > index 7b445e8..9f0c155 100644 > --- a/drivers/base/power/opp/cpu.c > +++ b/drivers/base/power/opp/cpu.c > @@ -214,7 +214,6 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_of_cpumask_add_table); > /* > * Works only for OPP v2 bindings. > * > - * cpumask should be already set to mask of cpu_dev->id. > * Returns -ENOENT if operating-points-v2 bindings aren't supported. > */ > int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, cpumask_var_t > cpumask) > @@ -230,6 +229,8 @@ int dev_pm_opp_of_get_sharing_cpus(struct device > *cpu_dev, cpumask_var_t cpumask > return -ENOENT; > } > > + cpumask_set_cpu(cpu_dev->id, cpumask); > + > /* OPPs are shared ? */ > if (!of_property_read_bool(np, "opp-shared")) > goto put_cpu_node; Acked-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v1 4/4] clk: rockchip: rk3036: fix and add node id for emac clock
On 2015年12月29日 09:59, Yakir Yang wrote:
Hi Heiko,
On 12/28/2015 08:41 PM, Heiko Stübner wrote:
Hi,
Am Montag, 28. Dezember 2015, 17:03:53 schrieb Xing Zheng:
Due to referred old version TRM, there is incorrect emac clock node,
we should fix it. The SEL_21_9 is the parent of SEL_21_4.
In the emac driver, we need to refer HCLK_MAC, and because There are
only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
GPLL, and it is unable to provide the accurate rate for mac_ref which
need to 50MHz probability, we should let it under the APLL and are
able to set the freq which integer multiples of 50MHz, so we add these
emac node for reference.
I don't really follow here. While I do understand that the emac needs
50MHz, I
don't think using the APLL as source is helpful.
The APLL is the main clocksource for the cpu-cores, including frequency
scaling, and while it currently only lists 816MHz as sole frequency,
you're
pretty much guaranteed to not get your correct multiple of 50MHz from
there
either. And limiting the cpu to just do 600MHz to get the mac working
sounds
pretty bad ;-) .
In the rk3036 cru-node the gpll gets set to 594MHz. Is there a
special reason
why it needs to be 594MHz and cannot be a round 600MHz? Because that
would
also provide your 50MHz-multiple nicely.
Yes, this magic 594MHz would help to support the standard HDMI
resolutions, here are the math:
1920x1080-60Hz DCLK = 148.5MHz = 594MHz / 4
1280x720-60Hz DCLK = 74.25MHz = 594MHz / 8
720x480-60Hz DCLK = 27MHz = 594MHz / 22
Thanks,
- Yakir
Thanks Yakir.
Hi Heiko,
From the above, do you have better idea for the RK3036's emac without
ext-oscillator?
Thanks. :-)
Signed-off-by: Xing Zheng
---
drivers/clk/rockchip/clk-rk3036.c | 11 ++-
include/dt-bindings/clock/rk3036-cru.h | 2 ++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3036.c
b/drivers/clk/rockchip/clk-rk3036.c index 7420cbe..7863c4d 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -328,13 +328,14 @@ static struct rockchip_clk_branch
rk3036_clk_branches[] __initdata = { RK2928_CLKSEL_CON(16), 0, 2,
MFLAGS,
2, 5, DFLAGS,
RK2928_CLKGATE_CON(10), 5, GFLAGS),
- COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
- RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 4, 5, DFLAGS),
+ MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
+ RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
+ DIV(0, "mac_pll_src", "mac_pll_pre", 0,
+ RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
MUX(SCLK_MACREF, "mac_clk_ref", mux_mac_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(21), 3, 1, MFLAGS),
-
COMPOSITE_NOMUX(SCLK_MAC, "mac_clk", "mac_clk_ref", 0,
- RK2928_CLKSEL_CON(21), 9, 5, DFLAGS,
+ RK2928_CLKSEL_CON(21), 4, 5, DFLAGS,
RK2928_CLKGATE_CON(2), 6, GFLAGS),
MUX(SCLK_HDMI, "dclk_hdmi", mux_dclk_p, 0,
@@ -389,7 +390,7 @@ static struct rockchip_clk_branch
rk3036_clk_branches[]
__initdata = { GATE(HCLK_OTG1, "hclk_otg1", "hclk_peri",
CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(7), 3, GFLAGS), GATE(HCLK_I2S, "hclk_i2s",
"hclk_peri",
0, RK2928_CLKGATE_CON(7), 2, GFLAGS), GATE(0, "hclk_sfc", "hclk_peri",
CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 14, GFLAGS), - GATE(0,
"hclk_mac", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 15,
GFLAGS), + GATE(HCLK_MAC, "hclk_mac", "hclk_peri", 0,
RK2928_CLKGATE_CON(3), 5, GFLAGS),
/* pclk_peri gates */
GATE(0, "pclk_peri_matrix", "pclk_peri", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(4), 1, GFLAGS), diff --git
a/include/dt-bindings/clock/rk3036-cru.h
b/include/dt-bindings/clock/rk3036-cru.h index ebc7a7b..de44109 100644
--- a/include/dt-bindings/clock/rk3036-cru.h
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -54,6 +54,7 @@
#define SCLK_PVTM_VIDEO 125
#define SCLK_MAC 151
#define SCLK_MACREF 152
+#define SCLK_MACPLL 153
#define SCLK_SFC 160
/* aclk gates */
@@ -92,6 +93,7 @@
please separate the hclk addition into two separate patches:
patch1: add the clock-id to the dt-binding header
patch2: use the clock in the clock-driver
Done.
#define HCLK_SDMMC 456
#define HCLK_SDIO 457
#define HCLK_EMMC 459
+#define HCLK_MAC 460
#define HCLK_I2S 462
#define HCLK_LCDC 465
#define HCLK_ROM 467
Thanks
Heiko
___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v1 4/4] clk: rockchip: rk3036: fix and add node id for emac clock
Hi Heiko,
On 12/28/2015 08:41 PM, Heiko Stübner wrote:
Hi,
Am Montag, 28. Dezember 2015, 17:03:53 schrieb Xing Zheng:
Due to referred old version TRM, there is incorrect emac clock node,
we should fix it. The SEL_21_9 is the parent of SEL_21_4.
In the emac driver, we need to refer HCLK_MAC, and because There are
only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
GPLL, and it is unable to provide the accurate rate for mac_ref which
need to 50MHz probability, we should let it under the APLL and are
able to set the freq which integer multiples of 50MHz, so we add these
emac node for reference.
I don't really follow here. While I do understand that the emac needs 50MHz, I
don't think using the APLL as source is helpful.
The APLL is the main clocksource for the cpu-cores, including frequency
scaling, and while it currently only lists 816MHz as sole frequency, you're
pretty much guaranteed to not get your correct multiple of 50MHz from there
either. And limiting the cpu to just do 600MHz to get the mac working sounds
pretty bad ;-) .
In the rk3036 cru-node the gpll gets set to 594MHz. Is there a special reason
why it needs to be 594MHz and cannot be a round 600MHz? Because that would
also provide your 50MHz-multiple nicely.
Yes, this magic 594MHz would help to support the standard HDMI
resolutions, here are the math:
1920x1080-60Hz DCLK = 148.5MHz = 594MHz / 4
1280x720-60Hz DCLK = 74.25MHz = 594MHz / 8
720x480-60Hz DCLK = 27MHz = 594MHz / 22
Thanks,
- Yakir
Signed-off-by: Xing Zheng
---
drivers/clk/rockchip/clk-rk3036.c | 11 ++-
include/dt-bindings/clock/rk3036-cru.h |2 ++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3036.c
b/drivers/clk/rockchip/clk-rk3036.c index 7420cbe..7863c4d 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -328,13 +328,14 @@ static struct rockchip_clk_branch
rk3036_clk_branches[] __initdata = { RK2928_CLKSEL_CON(16), 0, 2, MFLAGS,
2, 5, DFLAGS,
RK2928_CLKGATE_CON(10), 5, GFLAGS),
- COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
- RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 4, 5, DFLAGS),
+ MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
+ RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
+ DIV(0, "mac_pll_src", "mac_pll_pre", 0,
+ RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
MUX(SCLK_MACREF, "mac_clk_ref", mux_mac_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(21), 3, 1, MFLAGS),
-
COMPOSITE_NOMUX(SCLK_MAC, "mac_clk", "mac_clk_ref", 0,
- RK2928_CLKSEL_CON(21), 9, 5, DFLAGS,
+ RK2928_CLKSEL_CON(21), 4, 5, DFLAGS,
RK2928_CLKGATE_CON(2), 6, GFLAGS),
MUX(SCLK_HDMI, "dclk_hdmi", mux_dclk_p, 0,
@@ -389,7 +390,7 @@ static struct rockchip_clk_branch rk3036_clk_branches[]
__initdata = { GATE(HCLK_OTG1, "hclk_otg1", "hclk_peri", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(7), 3, GFLAGS), GATE(HCLK_I2S, "hclk_i2s", "hclk_peri",
0, RK2928_CLKGATE_CON(7), 2, GFLAGS), GATE(0, "hclk_sfc", "hclk_peri",
CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 14, GFLAGS), -GATE(0,
"hclk_mac", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 15,
GFLAGS), + GATE(HCLK_MAC, "hclk_mac", "hclk_peri", 0,
RK2928_CLKGATE_CON(3), 5, GFLAGS),
/* pclk_peri gates */
GATE(0, "pclk_peri_matrix", "pclk_peri", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(4), 1, GFLAGS), diff --git
a/include/dt-bindings/clock/rk3036-cru.h
b/include/dt-bindings/clock/rk3036-cru.h index ebc7a7b..de44109 100644
--- a/include/dt-bindings/clock/rk3036-cru.h
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -54,6 +54,7 @@
#define SCLK_PVTM_VIDEO 125
#define SCLK_MAC 151
#define SCLK_MACREF 152
+#define SCLK_MACPLL153
#define SCLK_SFC 160
/* aclk gates */
@@ -92,6 +93,7 @@
please separate the hclk addition into two separate patches:
patch1: add the clock-id to the dt-binding header
patch2: use the clock in the clock-driver
#define HCLK_SDMMC456
#define HCLK_SDIO 457
#define HCLK_EMMC 459
+#define HCLK_MAC 460
#define HCLK_I2S 462
#define HCLK_LCDC 465
#define HCLK_ROM 467
Thanks
Heiko
___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support
Hi Paul,
On 29/12/15 07:49, Paul Kocialkowski wrote:
Hi Milo, thanks for the review,
Le lundi 28 décembre 2015 à 09:56 +0900, Milo Kim a écrit :
Hi Paul,
On 23/12/15 20:56, Mark Brown wrote:
On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
+ gpio = lp->pdata->enable_gpio;
+ if (!gpio_is_valid(gpio))
+ return 0;
+
+ /* Always set enable GPIO high. */
+ ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X
EN");
+ if (ret) {
+ dev_err(lp->dev, "gpio request err: %d\n", ret);
+ return ret;
+ }
This isn't really adding support for the enable GPIO as the changelog
suggests, it's requesting but not managing the GPIO. Since there is
core support for manging enable GPIOs this seems especially silly,
please tell the core about the GPIO and then it will work at runtime
too.
With reference to my previous mail, external GPIOs for LDO3 and BUCK2 in
LP8725 can be specified through regulator_config.ena_gpio. BUCK2 only
can be controlled by external pin when CONFIG pin is grounded.
Please see the description at page 5 of the datasheet.
http://www.ti.com/lit/ds/symlink/lp8725.pdf
After reading the datasheets thoroughly, it seems to me that for the
lp8720, the EN pin is used to enable the regulators output, which is a
good fit for the core regulator GPIO framework, as there is no reason to
keep it on when no regulator is in use. The serial interface is already
available when EN=0 and regulators can be configured in that state. The
lp8725 seems seems to behave the same when CONFIG=0 (the datasheet
clearly states: "CONFIG=0: EN=1 turns on outputs or standby mode if
EN=0"). On the other hand, it is indeed used as a power-on pin when
CONFIG=1.
I think it's different use case. LP8720/5 are designed for system PMU,
so some regulators are enabled by default after the device is on. EN pin
is used for turning on/off the chip. This pin does not control regulator
outputs directly. It's separate functional block in the silicon.
On the other hand, 'ena_gpio' is used for each regulator control itself.
For example, WM8994 has two LDOs which are controlled by external pins.
LDOs are enabled/disabled through LDO1ENA and LDO2ENA pins. In this
case, 'ena_gpio' is used.
http://www.cirrus.com/en/pubs/proDatasheet/WM8994_v4.4.pdf
(please refer to page 224 and 225)
Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Cordial greeting
Cordial greeting message from Eva Zahra, I am seeking for your help,I will be very glad if you do assist me to relocate a sum of (US$4 Million Dollars)into your Bank account in your country for the benefit of both of us i want to use this money for investment. I will give you more details as you reply Yours Eva Zahra Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support
Hi Milo, thanks for the review,
Le lundi 28 décembre 2015 à 09:56 +0900, Milo Kim a écrit :
> Hi Paul,
>
> On 23/12/15 20:56, Mark Brown wrote:
> > On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote:
> >
> >> + gpio = lp->pdata->enable_gpio;
> >> + if (!gpio_is_valid(gpio))
> >> + return 0;
> >> +
> >> + /* Always set enable GPIO high. */
> >> + ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X
> >> EN");
> >> + if (ret) {
> >> + dev_err(lp->dev, "gpio request err: %d\n", ret);
> >> + return ret;
> >> + }
> >
> > This isn't really adding support for the enable GPIO as the changelog
> > suggests, it's requesting but not managing the GPIO. Since there is
> > core support for manging enable GPIOs this seems especially silly,
> > please tell the core about the GPIO and then it will work at runtime
> > too.
> >
>
> With reference to my previous mail, external GPIOs for LDO3 and BUCK2 in
> LP8725 can be specified through regulator_config.ena_gpio. BUCK2 only
> can be controlled by external pin when CONFIG pin is grounded.
>
> Please see the description at page 5 of the datasheet.
>
> http://www.ti.com/lit/ds/symlink/lp8725.pdf
After reading the datasheets thoroughly, it seems to me that for the
lp8720, the EN pin is used to enable the regulators output, which is a
good fit for the core regulator GPIO framework, as there is no reason to
keep it on when no regulator is in use. The serial interface is already
available when EN=0 and regulators can be configured in that state. The
lp8725 seems seems to behave the same when CONFIG=0 (the datasheet
clearly states: "CONFIG=0: EN=1 turns on outputs or standby mode if
EN=0"). On the other hand, it is indeed used as a power-on pin when
CONFIG=1.
Since my intent here is to cover the lp8720 use case, I suggest that we
implement this using the core regulator GPIO framework (I have patches
ready for that) and leave out the case where CONFIG=1, which could be
dealt with later by providing that piece of information via platform
data (and devicetree) and then either use the regulator GPIO framework
(when CONFIG=0 and default) or register the GPIO within the driver and
keep it on at all times (when CONFIG=1).
I could most certainly implement that behaviour, but I'd rather leave it
to someone else (or at least the testing) since I don't have any lp8725
to play with.
What do you think?
--
Paul Kocialkowski, Replicant developer
Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.
Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.
Quoting Eric Anholt (2015-12-24 15:45:15) > Michael Turquette writes: > > > On Fri, Dec 18, 2015 at 8:19 PM, Rob Herring wrote: > >> On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote: > >>> These will be used for enabling UART1, SPI1, and SPI2. > >>> > >>> Signed-off-by: Eric Anholt > >>> --- > >>> > >>> v2: Make the binding cover both the IRQ and clock enable registers. > >>> > >>> .../bindings/clock/brcm,bcm2835-aux-clock.txt | 31 > >>> ++ > >>> include/dt-bindings/clock/bcm2835-aux.h| 17 > >>> 2 files changed, 48 insertions(+) > >>> create mode 100644 > >>> Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt > >>> create mode 100644 include/dt-bindings/clock/bcm2835-aux.h > >> > >> Acked-by: Rob Herring > > > > Applied to clk-next. > > > > Next time if you put the header into the clk driver patch then we can > > send the binding description through the DT tree and take the header > > and C file through the clk tree in one patch. > > I would *love* to do that, but I've previously been told that having the > bindings patch reference a header file not present as of the bindings > patch is not acceptable and made to change it. Ugh, that is annoying. I would think that having code compile properly would trump the desire to have all of the documentation merged as one patch. On the other hand, I've been asked to not take binding descriptions through the clk tree. That is a policy that I'm happy to comply with, but it is at odds with the recommendation for the header and the binding description to be merged together. DT folks, what is the right way to do this? An immutable, shared branch just for a single header file solves the problem, but also feels very cumbersome for such a trivial issue. How about allowing binding descriptions to be merged without the header file, so long as it is merged through another tree? Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/2] add Alphascale asm9260-wdt driver
Hi Oleksij, > v2: > - fix DT types > - remove obsolet comments > - add clk error handling > - reduce log noise > - allow to return an error in asm9260_wdt_get_dt_mode > > v3: > - split patch to two parts, binding documentation and driver > - spelling fixes > - make reset a required property. It will make the code easier > - reduce timeout for asm9260_wdt_sys_reset > - rework error handling in asm9260_wdt_get_dt_clks > - asm9260_wdt_get_dt_mode - convert return type from int to void > - don't touch watchdog_set_nowayout > - don't do dev_err() if driver is still working, use dev_warn instead. > - asm9260_wdt_remove - use asm9260_wdt_disable() instead of > asm9260_wdt_shutdown() > > v4: > - update commit message > - remove IRQF_SHARED flag. This SOC don't need it. > - make "Watchdog enabled" more user freandly > - add watchdog_unregister_device to asm9260_wdt_remove > > Oleksij Rempel (2): > watchdog: add Alphascale asm9260-wdt driver > DT: watchdog: add Alphascale asm9260 watchdog binding documentation. > > .../bindings/watchdog/alphascale-asm9260.txt | 35 ++ > drivers/watchdog/Kconfig | 10 + > drivers/watchdog/Makefile | 1 + > drivers/watchdog/asm9260_wdt.c | 403 > + > 4 files changed, 449 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt > create mode 100644 drivers/watchdog/asm9260_wdt.c > > -- > 2.5.0 > This new driver has been added o linux-watchdog-next. Kind regards, Wim. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: porter: add DU DT support
On Mon, Dec 28, 2015 at 05:35:33PM +0300, Sergei Shtylyov wrote: > Hello. > > On 12/28/2015 08:29 AM, Simon Horman wrote: > > >>Define the Porter board dependent part of the DU device node. > >>Add the device node for Analog Devices ADV7511W HDMI transmitter to I2C2 > >>bus and the HDMI connector. Add the necessary subnodes to interconnect DU > >>and HDMI devices. > >> > >>Signed-off-by: Sergei Shtylyov > >> > >>--- > >>This patch is against 'renesas-devel-20151221-v4.4-rc6' tag of Simon > >>Horman's > >>'renesas.git' repo. > > > >Thanks, I have queued this up for v4.6. > >Actually, I was going to check this patch WRT the DU channels used, given > Laurent's remark. OK, I will just send an incremental patch if needed. Thanks and sorry for being a bit hasty. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8] watchdog: ts4800: add driver for TS-4800 watchdog
Hi Damien,
> This watchdog is instantiated in a FPGA that is memory mapped. It is
> made of only one register, called the feed register. Writing to this
> register will re-arm the watchdog for a given time (and enable it if it
> was disable). It can be disabled by writing a special value into it.
>
> It is part of a syscon block, and the watchdog register offset in this
> block varies from board to board. This offset is passed in the syscon
> property after the phandle to the syscon node.
>
> Signed-off-by: Damien Riegel
> Acked-by: Rob Herring
> Reviewed-by: Guenter Roeck
> ---
> Changes in v8:
> - Split the serie into two parts: watchdog and dts as there are no
>build dependencies between the two
> - Added Reviewed-by Guenter Roeck and Acked-by by Rob Herring (for
>the dts bindings).
>
> Changes in v7:
> - syscon: change bus-width DT property to reg-io-width
> - watchdog: add dependency on HAS_IOMEM (spotted by a 0-day build)
>
> Changes in v6:
> - vendor prefix: reorder to sort alphabetically (wrong order since v3)
> - split commit adding device tree into two patches: one for the doc, one for
>the bindings
>
> Changes in v5:
> - watchdog: changed iteration stop condition in set_timeout to be less
>error prone
>
> Changes in v4:
> - syscon: rewrite DT property reading to be clearer
> - watchdog: made fixes suggested by Guenter (now uses
>watchdog_init_timeout, u32 instead of u16, fixed error checking in
>probe, cleaned set_timeout)
>
> Changes in v3:
> - Rebased on v4.3
> - Changed vendor prefix from "ts" to "technologic"
> - Added a DT option to generic syscon driver to allow regmap configuration
> - Dropped custom mfd driver, use generic syscon driver instead.
>
> Changes in v2:
> - Added a mfd driver to handle syscon registers
> - The watchdog driver now uses the regmap (created by the mfd driver)
>to access the feed register
> - Remove watchdog's dependency on SOC_IMX51
>
> .../devicetree/bindings/watchdog/ts4800-wdt.txt| 25 +++
> drivers/watchdog/Kconfig | 10 +
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/ts4800_wdt.c | 215
> +
> 4 files changed, 251 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> create mode 100644 drivers/watchdog/ts4800_wdt.c
>
> diff --git a/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> b/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> new file mode 100644
> index 000..8f6caad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
> @@ -0,0 +1,25 @@
> +Technologic Systems Watchdog
> +
> +Required properties:
> +- compatible: must be "technologic,ts4800-wdt"
> +- syscon: phandle / integer array that points to the syscon node which
> + describes the FPGA's syscon registers.
> + - phandle to FPGA's syscon
> + - offset to the watchdog register
> +
> +Optional property:
> +- timeout-sec: contains the watchdog timeout in seconds.
> +
> +Example:
> +
> +syscon: syscon@b001 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0xb001 0x3d>;
> + reg-io-width = <2>;
> +
> + wdt@e {
> + compatible = "technologic,ts4800-wdt";
> + syscon = <&syscon 0xe>;
> + timeout-sec = <10>;
> + };
> +}
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 79e1aa1..bb624d2 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -426,6 +426,16 @@ config NUC900_WATCHDOG
> To compile this driver as a module, choose M here: the
> module will be called nuc900_wdt.
>
> +config TS4800_WATCHDOG
> + tristate "TS-4800 Watchdog"
> + depends on HAS_IOMEM && OF
> + select WATCHDOG_CORE
> + select MFD_SYSCON
> + help
> + Technologic Systems TS-4800 has watchdog timer implemented in
> + an external FPGA. Say Y here if you want to support for the
> + watchdog timer on TS-4800 board.
> +
> config TS72XX_WATCHDOG
> tristate "TS-72XX SBC Watchdog"
> depends on MACH_TS72XX
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 0c616e3..3863ce0 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
> obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
> obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
> obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
> +obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
> obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
> obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
> obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
> diff --git a/drivers/watchdog/ts4800_wdt.c b/drivers/watchdog/ts4800_wdt.c
> new file mode 100644
> index 000..2b8de86
> --- /dev/null
> +++ b/drivers/watchdog/ts4800_wdt.c
> @@ -0,0 +1,215 @@
> +/*
>
Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms
On Thu, Nov 26, 2015 at 1:32 AM, Ohad Ben-Cohen wrote: > On Thu, Nov 26, 2015 at 11:10 AM, Lee Jones wrote: >> On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote: >>> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones wrote: >>> > ST's platforms often have multiple co-processors (usually ST40s or ST231s) >>> > on-board. This provides the Linux-side infrastructure to flash and boot >>> > them successfully. >>> > >>> > This set has been tested on an STiH410-B2120. >>> >>> It would be nice if you could get at least one Reviewed-by tag coming >>> outside of ST (e.g., Suman or Bjorn who are actively using and >>> improving remoteproc). >> >> If you require reviews by these guys, shouldn't they be Maintainers? > > Additional review isn't a requirement, but it's a plus. > >> Please be aware that >> the DTS(I) changes are applied to this set for your information only >> and are not to be applied through the RemoteProc tree. The usual >> process to which we conform is that Maxime (the STi Maintainer) will >> apply the DT changes *after* the main driver has been applied, in this >> case by you. > > Ok, great, so I will not take patches 5 and 6. > I interpreted this as you picked patch 1-4 and didn't pay more attention to them, but I can't find them in your kernel.org trees. So I've looked through them again. Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to find a v5 of patch 2, but it's unrelated so no need to wait for a new version of that. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs
On Fri, Dec 4, 2015 at 12:24 AM, Lee Jones wrote: > On Thu, 03 Dec 2015, Arnd Bergmann wrote: > >> On Thursday 03 December 2015 17:28:30 Lee Jones wrote: >> > > >> > > Ah, interesting. I haven't tried myself, and just tried to read the >> > > code. Maybe glibc already catches zero-length writes before it gets >> > > into the kernel, or I just missed the part of the syscall that checks >> > > for this. >> > >> > Glibc is responsible indeed: >> > >> > http://osxr.org/glibc/source/io/write.c >> >> Ok, so an attacker can force the stack overflow by calling >> syscall(__NR_write, fd, p, 0) if that has any potential value, >> but normal users won't hit this case. > > Right. I have fixed the issue (and another one I found) anyway, if > only to rid the GCC warning. > Sorry, but I'm unable to find a new version of this patch, did I miss it or could you resend it? Also, as I looked at this again, we should probably return an error if count >= sizeof(buf) rather than just acknowledging the input (same in the other debugfs write function in this file). Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND v4 3/6] remoteproc: Supply controller driver for ST's Remote Processors
On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones wrote:
> Signed-off-by: Ludovic Barre
> Signed-off-by: Lee Jones
> ---
Acked-by: Bjorn Andersson
Regards,
Bjorn
> drivers/remoteproc/Kconfig | 9 ++
> drivers/remoteproc/Makefile| 1 +
> drivers/remoteproc/st_remoteproc.c | 297
> +
> 3 files changed, 307 insertions(+)
> create mode 100644 drivers/remoteproc/st_remoteproc.c
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 28c711f..72e97d7 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
> It's safe to say n here if you're not interested in multimedia
> offloading.
>
> +config ST_REMOTEPROC
> + tristate "ST remoteproc support"
> + depends on ARCH_STI
> + select REMOTEPROC
> + help
> + Say y here to support ST's adjunct processors via the remote
> + processor framework.
> + This can be either built-in or a loadable module.
> +
> endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 81b04d1..279cb2e 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
> obj-$(CONFIG_STE_MODEM_RPROC) += ste_modem_rproc.o
> obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
> obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
> +obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
> diff --git a/drivers/remoteproc/st_remoteproc.c
> b/drivers/remoteproc/st_remoteproc.c
> new file mode 100644
> index 000..6bb04d4
> --- /dev/null
> +++ b/drivers/remoteproc/st_remoteproc.c
> @@ -0,0 +1,297 @@
> +/*
> + * ST's Remote Processor Control Driver
> + *
> + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
> + *
> + * Author: Ludovic Barre
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct st_rproc_config {
> + boolsw_reset;
> + boolpwr_reset;
> + unsigned long bootaddr_mask;
> +};
> +
> +struct st_rproc {
> + struct st_rproc_config *config;
> + struct reset_control*sw_reset;
> + struct reset_control*pwr_reset;
> + struct clk *clk;
> + u32 clk_rate;
> + struct regmap *boot_base;
> + u32 boot_offset;
> +};
> +
> +static int st_rproc_start(struct rproc *rproc)
> +{
> + struct st_rproc *ddata = rproc->priv;
> + int err;
> +
> + regmap_update_bits(ddata->boot_base, ddata->boot_offset,
> + ddata->config->bootaddr_mask, rproc->bootaddr);
> +
> + err = clk_enable(ddata->clk);
> + if (err) {
> + dev_err(&rproc->dev, "Failed to enable clock\n");
> + return err;
> + }
> +
> + if (ddata->config->sw_reset) {
> + err = reset_control_deassert(ddata->sw_reset);
> + if (err) {
> + dev_err(&rproc->dev, "Failed to deassert S/W
> Reset\n");
> + goto sw_reset_fail;
> + }
> + }
> +
> + if (ddata->config->pwr_reset) {
> + err = reset_control_deassert(ddata->pwr_reset);
> + if (err) {
> + dev_err(&rproc->dev, "Failed to deassert Power
> Reset\n");
> + goto pwr_reset_fail;
> + }
> + }
> +
> + dev_info(&rproc->dev, "Started from 0x%x\n", rproc->bootaddr);
> +
> + return 0;
> +
> +
> +pwr_reset_fail:
> + if (ddata->config->pwr_reset)
> + reset_control_assert(ddata->sw_reset);
> +sw_reset_fail:
> + clk_disable(ddata->clk);
> +
> + return err;
> +}
> +
> +static int st_rproc_stop(struct rproc *rproc)
> +{
> + struct st_rproc *ddata = rproc->priv;
> + int sw_err = 0, pwr_err = 0;
> +
> + if (ddata->config->sw_reset) {
> + sw_err = reset_control_assert(ddata->sw_reset);
> + if (sw_err)
> + dev_err(&rproc->dev, "Failed to assert S/W Reset\n");
> + }
> +
> + if (ddata->config->pwr_reset) {
> + pwr_err = reset_control_assert(ddata->pwr_reset);
> + if (pwr_err)
> + dev_err(&rproc->dev, "Failed to assert Power
> Reset\n");
> + }
> +
> + clk_disable(ddata->clk);
> +
> + return sw_err ?: pwr_err;
> +}
> +
> +static struct rproc_ops st_rproc_ops = {
> +
Re: [RESEND v4 1/6] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver
On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones wrote:
> Signed-off-by: Ludovic Barre
> Signed-off-by: Lee Jones
> ---
Acked-by: Bjorn Andersson
Regards,
Bjorn
> .../devicetree/bindings/remoteproc/st-rproc.txt| 41
> ++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> new file mode 100644
> index 000..1031bcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> @@ -0,0 +1,41 @@
> +STMicroelectronics Co-Processor Bindings
> +
> +
> +This binding provides support for adjunct processors found on ST SoCs.
> +
> +Co-processors can be controlled from the bootloader or the primary OS. If
> +the bootloader starts a co-processor, the primary OS must detect its state
> +and act accordingly.
> +
> +Required properties:
> +- compatible Should be one of:
> + "st,st231-rproc"
> + "st,st40-rproc"
> +- memory-regionReserved memory (See:
> ../reserved-memory/reserved-memory.txt)
> +- resets Reset lines (See: ../reset/reset.txt)
> +- reset-names Must be "sw_reset" and "pwr_reset"
> +- clocks Clock for co-processor (See:
> ../clock/clock-bindings.txt)
> +- clock-frequency Clock frequency to set co-processor at if the
> bootloader
> + hasn't already done so
> +- st,syscfgSystem configuration register which holds the boot
> vector
> + for the co-processor
> + 1st cell: Phandle to syscon block
> + 2nd cell: Boot vector register offset
> +
> +Example:
> +
> + audio_reserved: rproc@4200 {
> + compatible = "shared-dma-pool";
> + reg = <0x4200 0x0100>;
> + no-map;
> + };
> +
> + st231-audio {
> + compatible = "st,st231-rproc";
> + memory-region = <&audio_reserved>;
> + resets = <&softreset STIH407_ST231_AUD_SOFTRESET>;
> + reset-names = "sw_reset";
> + clocks = <&clk_s_c0_flexgen CLK_ST231_AUD_0>;
> + clock-frequency = <6>;
> + st,syscfg = <&syscfg_core 0x228>;
> + };
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] watchdog: imx2_wdt: add external reset support via 'ext-reset-output' dt prop
Hi Tim, > On Wed, Dec 2, 2015 at 12:54 PM, Tim Harvey wrote: > > > > On Wed, Dec 2, 2015 at 11:11 AM, Akshay Bhat > > wrote: > > > > > > > > > On 11/06/2015 05:02 PM, Guenter Roeck wrote: > > >> > > >> On Fri, Nov 06, 2015 at 11:53:42AM -0800, Tim Harvey wrote: > > >>> > > >>> On Thu, Nov 5, 2015 at 2:23 PM, Guenter Roeck > > >>> wrote: > > > > On Thu, Nov 05, 2015 at 04:19:21PM -0500, Akshay Bhat wrote: > > > > > > From: Tim Harvey > > > > > > The IMX6 watchdog supports assertion of a signal (WDOG_B) which > > > can be pinmux'd to an external pin. This is typically used for boards > > > that > > > have PMIC's in control of the IMX6 power rails. In fact, failure to > > > use > > > such an external reset on boards with external PMIC's can result in > > > various > > > hangs due to the IMX6 not being fully reset [1] as well as the board > > > failing > > > to reset because its PMIC has not been reset to provide adequate > > > voltage for > > > the CPU when coming out of reset at 800Mhz. > > > > > > This uses a new device-tree property 'ext-reset-output' to indicate > > > the > > > board has such a reset and to cause the watchdog to be configured to > > > assert > > > WDOG_B instead of an internal reset both on a watchdog timeout and in > > > system_restart. > > > > > > [1] > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333689.html > > > > > > Cc: Lucas Stach > > > Signed-off-by: Tim Harvey > > > --- > > > .../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 ++ > > > drivers/watchdog/imx2_wdt.c | 20 > > > ++-- > > > 2 files changed, 20 insertions(+), 2 deletions(-) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > > > b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > > > index 8dab6fd..9b89b3a 100644 > > > --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > > > +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt > > > @@ -9,6 +9,8 @@ Optional property: > > > > > > properties ? > > > > > - big-endian: If present the watchdog device's registers are > > > implemented > > > in big endian mode, otherwise in native mode(same with CPU), for > > > more > > > detail please see: > > > Documentation/devicetree/bindings/regmap/regmap.txt. > > > +- ext-reset-output: If present the watchdog device is configured to > > > assert its > > > > > > Should that have a vendor prefix ? Also, not sure if "-output" > > has any real value in the property name. "fsl,external-reset", maybe ? > > >>> > > >>> > > >>> Hi Guenter, > > >>> > > >>> I don't see why a vendor prefix is necessary - its a feature of the > > >>> IMX6 watchdog supported by this driver to be able to trigger an > > >>> internal chip-level reset and/or an external signal that can be hooked > > >>> to additional hardware. > > >>> > > >> Sounded like vendor specific to me, but then I am not a devicetree > > >> maintainer, > > >> so I am not an authority on the subject. > > > > > > > > > Devicetree maintainers, > > > > > > Any thoughts? > > > > > > Tim, > > > > > > After looking at all the other watchdog drivers, it does not appear that > > > there is any other processor which uses a similar feature. Since imx is > > > the > > > only processor that appears to support this feature, it might make sense > > > in > > > making this vendor specific. If in the future it is found more processors > > > support a similar functionality, it can be revisited and moved out from > > > being vendor specific? > > > > > > > I'm certainly no expert on device-tree policy. I understand your > > point, but realize that the driver in question is imx2_wdt.c > > (compatible = "fsl,imx21-wdt"). This is an IP block inside the silicon > > of only Freescale chips, so its not like a future omap chip would be > > using this driver - only fsl devices. So why would it need a 'vendor' > > property any more than its other properties? > > > > Regards, > > > > Tim > > Wim, > > Does the lack of response mean overwhelming approval? > > I haven't heard any valid complaints - what does it take to get this approved? > > Regards, > > Tim I have no objections against the idea and the code itself. But as Guenter pointed out: it would be handy to get feedback from the devicetree maintainers on the above discussion. Kind regards, Wim. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/3] spi: sun4i: Fix clock calculations to be predictable and never exceed the requested rate
Hi again,
2015-12-28 0:29 GMT+01:00 Marcus Weseloh :
> 2015-12-27 22:09 GMT+01:00 Maxime Ripard :
[...]
> [...]
>>> - /* Ensure that we have a parent clock fast enough */
>>> + /*
>>> + * Ensure that the parent clock is set to twice the max speed
>>> + * of the spi device (possibly rounded up by the clk driver)
>>> + */
>>> mclk_rate = clk_get_rate(sspi->mclk);
>>> - if (mclk_rate < (2 * tfr->speed_hz)) {
>>> - clk_set_rate(sspi->mclk, 2 * tfr->speed_hz);
>>> + if (spi->max_speed_hz != sspi->cur_max_speed ||
>>> + mclk_rate != sspi->cur_mclk) {
>>
>> Do you need to cache the values? As far as I'm aware, you end up doing
>> the computation all the time anyway.
>
> By caching the values we optimize the case when a single SPI slave
> device (or even multiple slave devices with the same max_speed) are
> used multiple times in a row. In that case, we're saving two calls:
> clk_set_rate and clk_get_rate. I was unsure about how expensive the
> clk_* calls were, so I thought it would be safer use caching. But
> maybe it's not worth the extra code?
>
> Oh, and I just noticed a mistake in the comment: the clock driver
> rounds up _or_ down, so I should drop the "up".
As I'm looking further into this, I think the comment should read
"possibly rounded down", as the clk framework is expected to set a
frequency that is less or equal to the requested frequency. So the
effect I was seeing (that I got a frequency higher than the requested
one) is actually a bug!? Further details below.
> [...]
>>> - div = mclk_rate / (2 * tfr->speed_hz);
>>> - if (div <= (SUN4I_CLK_CTL_CDR2_MASK + 1)) {
>>> - if (div > 0)
>>> - div--;
>>> -
>>> + div = DIV_ROUND_UP(mclk_rate, 2 * tfr->speed_hz) - 1;
>>
>> Isn't it exactly the same thing as mclk_rate / (2 * tfr->speed_hz) ?
>
> It is quite often, but not in all cases. The plain division rounds to
> the nearest integer, so it rounds down sometimes. Consider the
> following case: we have a slow SPI device with a spi-max-frequency of
> 50kHz. Our clock driver can't find a clock as slow as 100kHz, so it
> sets mclk to 214,285Hz.
That clk_set_rate sets a higher frequency than requested seems to be a
problem in itself. I had a look at clk/sunxi/clk-mod0.c and noticed a
few small problems there. Will post an RFC patch in a couple of
minutes.
That doesn't invalidate any of the fixes proposed in this patch,
though. They are still needed, as I see it. But after fixing
clk-mod0.c, we need to make further changes to the spi-sun4i clock
selection, as clk_set_rate could now return -EINVAL. Will amend this
patch as well after receiving feedback on the (soon to come) mod0 clk
patch.
Cheers,
Marcus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/6] misc: add reboot mode driver
On Monday 28 December 2015 16:56:12 Heiko Stübner wrote:
> Am Montag, 28. Dezember 2015, 16:28:55 schrieb Arnd Bergmann:
> > On Wednesday 23 December 2015 17:31:45 Andy Yan wrote:
> > > +{ .compatible = "rockchip,reboot-mode-nvram",
> > > +.data = (void *)&reboot-mode-nvram },
> > > +{},
> > > +};
> >
> > nvram is a complex topic by itself, because there are so many ways to do it.
> > I think what you are referring to here is a battery-backed memory that uses
> > one or more bytes at a fixed offset to store a particular piece of
> > information, as the drivers/char/nvram.c driver does. Maybe we should put
> > the reboot mode into that driver then?
> >
> > There are other nvram drivers at various places in the kernel, and each may
> > be slightly different, or completely different, like the EFIVARs driver on
> > UEFI firmware or the key/value store on Open Firmware, these probably need
> > their own methods and not share the generic driver.
>
> actually we now have drivers/nvmem/* that does that byte-wise addressing for
> eeproms, efuses, etc in a generic way.
Good point, so some of the reboot-reason users will be able to use that
framework, but some will not:
- drivers/nvmem only works for fixed-length data in a fixed location, but
not for key/value pairs, TLVs etc.
- Coming back to an earlier problem I pointed out, a lot of the things
stored in an nvram need a consistent user interface. This includes stuff
like kernel command line, boot image name, boot device, console
configuration, network mac address. We probably want the reboot reason
to fit into the wider framework for these, and drivers/nvmem doesn't
(currently) look like a good place for that.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/6] misc: add reboot mode driver
Am Montag, 28. Dezember 2015, 16:28:55 schrieb Arnd Bergmann:
> On Wednesday 23 December 2015 17:31:45 Andy Yan wrote:
> > +{ .compatible = "rockchip,reboot-mode-nvram",
> > +.data = (void *)&reboot-mode-nvram },
> > +{},
> > +};
>
> nvram is a complex topic by itself, because there are so many ways to do it.
> I think what you are referring to here is a battery-backed memory that uses
> one or more bytes at a fixed offset to store a particular piece of
> information, as the drivers/char/nvram.c driver does. Maybe we should put
> the reboot mode into that driver then?
>
> There are other nvram drivers at various places in the kernel, and each may
> be slightly different, or completely different, like the EFIVARs driver on
> UEFI firmware or the key/value store on Open Firmware, these probably need
> their own methods and not share the generic driver.
actually we now have drivers/nvmem/* that does that byte-wise addressing for
eeproms, efuses, etc in a generic way.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver
On Monday 28 December 2015 10:20:56 Thierry Reding wrote: > > > > HTC apparently uses a separate RAM area to pass the reboot reason, > > > > and they have a driver to store that, which is separate from the > > > > driver that they use for actually rebooting the machine. > > > > > > I wasn't very clear, but the PMC_SCRATCH0 register is used to store the > > > reset reason. It supports the recovery mode, which I think is really an > > > Android thing, "bootloader" will typically cause the bootloader not to > > > boot anything, and "forced-recovery" will go into a recovery mode that > > > is used to bootstrap the device (usually by uploading a "miniloader" > > > that initializes RAM, downloads a bootloader for booting or flashing an > > > operating system, ...). > > > > > > The write that resets the SoC is to a different register. > > > > So is this scratch register interpreted by some maskrom code, or by code > > that > > can be provided by the OEM? > > My understanding is that its interpreted both by what's called BootROM > on Tegra (I guess that's what you call "maskrom code") and the system's > bootloader. The BootROM cannot typically be replaced by the OEM, but it > is quite typical for the bootloader to differ between devices. Ok, so not maskrom (which would not be OEM specific, but hardcoded for the chip) but rather some form of PROM. This means we can only guess that all OEMs use the same protocol but in theory someone could have implemented an incompatible BootROM, but it's also possible that HTC just ignore the register entirely and implement the same thing separately. > The BootROM will interpret a subset of the bits in that register. Most > notable the "force recovery" bit. That will cause the BootROM to go into > a mode which can be used to bootstrap the device. It implements a simple > protocol (RCM) which can be used to upload a loader (usually referred to > as mini-loader) to the device's IRAM which in turn will initialize the > memory and which can download a proper bootloader (such as U-Boot) to > memory using a slightly more complex protocol (the standard protocol is > called nv3p, but the particular choice of protocol no longer matters at > this point). > > The bootloader can also access this register and will interpret the > "bootloader" and "recovery" bits. On the, argueably small, sample of > Android devices I've worked with, the "bootloader" bit will make the > bootloader go into fastboot mode, whereas the "recovery" bit will make > it initiate the RCK mode, which is used to update through OTA. > > There are a couple of other bits in this register, but they are badly > documented and don't seem to relate to reboot. Ok. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 0/6] misc: add reboot mode driver
On Wednesday 23 December 2015 17:31:45 Andy Yan wrote:
>
> I also have the idea to put is in drivers/power/reset, But considering
> this driver have not bind anything about power, so I put it in
> driver/misc
> at last. So I hope if some people can give more suggestions here.
I vote for drivers/power/reset as well. On some platforms, the two things
are related, on others they are not, but it's good to have it all in one
place I think.
> >> drivers/soc/rockchip/Kconfig | 9 ++
> >> drivers/soc/rockchip/Makefile | 1 +
> >> drivers/soc/rockchip/reboot.c | 68 +++
> > And maybe that part could be made generic instead of rockchip specific.
> > It simply uses a regmap to do the accesses, I guess a lot of other
> > platforms will do that. We have syscon-reboot and syscon-poweroff for
> > example.
> >
> > I think then we can extend the "framework" by having generic drivers to
> > store the value in eeprom or nvram for example.
> >
>
> I also hope the write interface can be generic. But I found some
> platform
> use different hardware to store the value. For example, John's patch
> use
> SRAM on qcom apq8064 to store value for nexus7. It seems there also have
> some platform use dram or nvram to store it. And these different
> hardware use
> different write method. I don't have a generic way to handle this.
>
> I have a idea to handle it like this:
>
> +static const struct of_device_id reboot_mode_dt_match[] = {
> +{ .compatible = "linux,reboot-mode-sfr",/*for magic value
> stored in special function register, which can be accessed by regmap*/
> +.data = (void *)&reboot-mode-sfr },
I'd make this one syscon-reboot-mode, to go along with syscon-poweroff
as implemented by drivers/power/reset/syscon-poweroff.c. The syscon concept
is already generic enough that we don't need a linux prefix for that.
> +{ .compatible = "linux,reboot-mode-sram", /*for magic value
> stored in
> +.data = (void *)&reboot-mode-sram },
the sram mode should probably follow the generic SRAM binding and make
the location that stores the reboot mode a separate partition, unless
we want to store other data in the same partition, in which case we might
want to use the same implementation as for the nvram.
> +{ .compatible = "linux,reboot-mode-sdram",
> +.data = (void *)&reboot-mode-sdram }, /*for magic value
> stored
I think "sdram" is not an appropriate name here, as the main system memory
might use some other technology, e.g. DRAM or DDR2-SDRAM.
> +{ .compatible = "rockchip,reboot-mode-nvram",
> +.data = (void *)&reboot-mode-nvram },
> +{},
> +};
nvram is a complex topic by itself, because there are so many ways to do it.
I think what you are referring to here is a battery-backed memory that uses
one or more bytes at a fixed offset to store a particular piece of information,
as the drivers/char/nvram.c driver does. Maybe we should put the reboot mode
into that driver then?
There are other nvram drivers at various places in the kernel, and each may
be slightly different, or completely different, like the EFIVARs driver on
UEFI firmware or the key/value store on Open Firmware, these probably need
their own methods and not share the generic driver.
> the data point to different hardware access method.
>
>Hope to see more suggestions from you.
It's probably best to leave these four examples as separate drivers and we can
add further ones when needed.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT
On Monday 28 December 2015 15:54:35 Pali Rohár wrote: > On Monday 28 December 2015 15:41:01 Arnd Bergmann wrote: > > On Monday 28 December 2015 15:28:48 Pali Rohár wrote: > > > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote: > > > > On Friday 25 December 2015 13:53:11 Pali Rohár wrote: > > > > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > > > > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote: > > > > > > > * Arnd Bergmann [150515 14:26]: > > > > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote: > > > > > > > If setting up the generic binding is expected to take a > > > > > > > while, you can naturally pass it in pdata while waiting > > > > > > > for the generic binding to get merged. > > > > > > > > > > > > Yes, good idea. So the n900 machine can use auxdata to pass > > > > > > this for the time being, while the binding and generic > > > > > > implementation is being worked out. > > > > > > > > > > Ok, so what is needed to finish this patch series? > > > > > > > > I don't know where we are at this point. Has either the auxdata > > > > approach or the generic binding been worked on at all? > > > > > > What are auxdata data? > > > > I mean you can add the platform data to the omap_auxdata_lookup[] > > table for this board. > > But can I mix data from omap3-n900.dts and omap_auxdata_lookup[]? Yes. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT
On Monday 28 December 2015 15:41:01 Arnd Bergmann wrote: > On Monday 28 December 2015 15:28:48 Pali Rohár wrote: > > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote: > > > On Friday 25 December 2015 13:53:11 Pali Rohár wrote: > > > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > > > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote: > > > > > > * Arnd Bergmann [150515 14:26]: > > > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote: > > > > > > If setting up the generic binding is expected to take a > > > > > > while, you can naturally pass it in pdata while waiting > > > > > > for the generic binding to get merged. > > > > > > > > > > Yes, good idea. So the n900 machine can use auxdata to pass > > > > > this for the time being, while the binding and generic > > > > > implementation is being worked out. > > > > > > > > Ok, so what is needed to finish this patch series? > > > > > > I don't know where we are at this point. Has either the auxdata > > > approach or the generic binding been worked on at all? > > > > What are auxdata data? > > I mean you can add the platform data to the omap_auxdata_lookup[] > table for this board. But can I mix data from omap3-n900.dts and omap_auxdata_lookup[]? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT
On Monday 28 December 2015 15:28:48 Pali Rohár wrote: > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote: > > On Friday 25 December 2015 13:53:11 Pali Rohár wrote: > > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote: > > > > > * Arnd Bergmann [150515 14:26]: > > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote: > > > > > If setting up the generic binding is expected to take a while, > > > > > you can naturally pass it in pdata while waiting for the > > > > > generic binding to get merged. > > > > > > > > Yes, good idea. So the n900 machine can use auxdata to pass this > > > > for the time being, while the binding and generic implementation > > > > is being worked out. > > > > > > Ok, so what is needed to finish this patch series? > > > > I don't know where we are at this point. Has either the auxdata > > approach or the generic binding been worked on at all? > > What are auxdata data? I mean you can add the platform data to the omap_auxdata_lookup[] table for this board. > And what do you mean with "generic binding" approach? Start a discussion to specify slot names and implement that in the mmc driver core, so we can remove the hack from the OMAP driver and make it work the same way for any machine. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: porter: add DU DT support
Hello. On 12/28/2015 08:29 AM, Simon Horman wrote: Define the Porter board dependent part of the DU device node. Add the device node for Analog Devices ADV7511W HDMI transmitter to I2C2 bus and the HDMI connector. Add the necessary subnodes to interconnect DU and HDMI devices. Signed-off-by: Sergei Shtylyov --- This patch is against 'renesas-devel-20151221-v4.4-rc6' tag of Simon Horman's 'renesas.git' repo. Thanks, I have queued this up for v4.6. Actually, I was going to check this patch WRT the DU channels used, given Laurent's remark. OK, I will just send an incremental patch if needed. MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT
On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote: > On Friday 25 December 2015 13:53:11 Pali Rohár wrote: > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote: > > > > * Arnd Bergmann [150515 14:26]: > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote: > > > > If setting up the generic binding is expected to take a while, > > > > you can naturally pass it in pdata while waiting for the > > > > generic binding to get merged. > > > > > > Yes, good idea. So the n900 machine can use auxdata to pass this > > > for the time being, while the binding and generic implementation > > > is being worked out. > > > > Ok, so what is needed to finish this patch series? > > I don't know where we are at this point. Has either the auxdata > approach or the generic binding been worked on at all? What are auxdata data? And what do you mean with "generic binding" approach? > If not, please try to get the auxdata variant to work, it should not > be hard at all because there is no dependency on a generic binding. > > Arnd -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v2 1/3] wlcore/wl12xx: spi: add power operation function
Hi Grygorii,
On 12/28/2015 01:59 PM, Grygorii Strashko wrote:
On 12/27/2015 07:14 PM, Uri Mashiach wrote:
Hello Grygorii,
On 12/24/2015 06:32 PM, Grygorii Strashko wrote:
On 12/24/2015 05:35 PM, Uri Mashiach wrote:
The power function uses a consumer regulator access to update the WiFi
enable GPIO value.
Signed-off-by: Uri Mashiach
---
v1 -> v2: oops fix was removed to a separate fix.
drivers/net/wireless/ti/wlcore/spi.c | 37
1 file changed, 37 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/spi.c
b/drivers/net/wireless/ti/wlcore/spi.c
[...]
+
static struct wl1271_if_operations spi_ops = {
.read= wl12xx_spi_raw_read,
.write= wl12xx_spi_raw_write,
.reset= wl12xx_spi_reset,
.init= wl12xx_spi_init,
+.power= wl12xx_spi_set_power,
.set_block_size = NULL,
};
@@ -353,6 +384,12 @@ static int wl1271_probe(struct spi_device *spi)
* comes from the board-peripherals file */
spi->bits_per_word = 32;
+glue->reg = devm_regulator_get(&spi->dev, "vwlan");
+if (IS_ERR(glue->reg)) {
It will be more correct to handle -EPROBE_DEFER here also. Like:
if (PTR_ERR(glue->reg) == -EPROBE_DEFER)
return PTR_ERR(glue->reg);
It seems that the IS_ERR(glue->reg) condition covers the EPROBE_DEFER case.
True. But this is not an error and it's common practice do not print
any log messages in this case from driver :)
Sorry, already posted v3.
Will be in v4.
+dev_err(glue->dev, "can't get regulator\n");
+return PTR_ERR(glue->reg);
+}
+
ret = spi_setup(spi);
if (ret < 0) {
dev_err(glue->dev, "spi_setup failed\n");
--
Thanks,
Uri
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT
On Friday 25 December 2015 13:53:11 Pali Rohár wrote: > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote: > > > * Arnd Bergmann [150515 14:26]: > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote: > > > If setting up the generic binding is expected to take a while, > > > you can naturally pass it in pdata while waiting for the generic > > > binding to get merged. > > > > Yes, good idea. So the n900 machine can use auxdata to pass this for > > the time being, while the binding and generic implementation is > > being worked out. > > > > Ok, so what is needed to finish this patch series? I don't know where we are at this point. Has either the auxdata approach or the generic binding been worked on at all? If not, please try to get the auxdata variant to work, it should not be hard at all because there is no dependency on a generic binding. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: am437x: pixcir_tangoc: use correct flags for irq types
Now IRQs for Pixcir Tangoc touchscreen are defined using IRQ_TYPE_NONE in am437x-gp-evm.dts and am43x-epos-evm.dts wich do not correspond HW. Hence, update am437x-gp-evm.dts and am43x-epos-evm.dts files and use correct flag IRQ_TYPE_EDGE_FALLING for irq types. While here, remove duplicated irq declaration for pixcir_ts@5c node in am437x-gp-evm.dts. Signed-off-by: Grygorii Strashko --- arch/arm/boot/dts/am437x-gp-evm.dts | 4 +--- arch/arm/boot/dts/am43x-epos-evm.dts | 2 +- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts index d2450ab..fc4c371 100644 --- a/arch/arm/boot/dts/am437x-gp-evm.dts +++ b/arch/arm/boot/dts/am437x-gp-evm.dts @@ -590,8 +590,6 @@ pinctrl-names = "default"; pinctrl-0 = <&pixcir_ts_pins>; reg = <0x5c>; - interrupt-parent = <&gpio3>; - interrupts = <22 0>; attb-gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>; @@ -599,7 +597,7 @@ * 0x264 represents the offset of padconf register of * gpio3_22 from am43xx_pinmux base. */ - interrupts-extended = <&gpio3 22 IRQ_TYPE_NONE>, + interrupts-extended = <&gpio3 22 IRQ_TYPE_EDGE_FALLING>, <&am43xx_pinmux 0x264>; interrupt-names = "tsc", "wakeup"; diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts index 47954ed..29c6580 100644 --- a/arch/arm/boot/dts/am43x-epos-evm.dts +++ b/arch/arm/boot/dts/am43x-epos-evm.dts @@ -491,7 +491,7 @@ pinctrl-0 = <&pixcir_ts_pins>; reg = <0x5c>; interrupt-parent = <&gpio1>; - interrupts = <17 0>; + interrupts = <17 IRQ_TYPE_EDGE_FALLING>; attb-gpio = <&gpio1 17 GPIO_ACTIVE_HIGH>; -- 2.6.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: am4372: fix irq type for arm twd and global timer
As per ARM documentation
PPI(0) ID27 - global timer interrupt is rising-edge sensitive.
PPI(2) ID29 - twd interrupt is rising-edge sensitive.
and the same is proved by GIC distributor register value
GIC_DIST_CONFIG(0xC04) = 0x7DC0.
Hence, set IRQ triggering type to IRQ_TYPE_EDGE_RISING
for ARM TWD and Global timers.
Signed-off-by: Grygorii Strashko
---
arch/arm/boot/dts/am4372.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index de8791a..dfa1a29 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -72,7 +72,7 @@
global_timer: timer@48240200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x48240200 0x100>;
- interrupts = ;
+ interrupts = ;
interrupt-parent = <&gic>;
clocks = <&mpu_periphclk>;
};
@@ -80,7 +80,7 @@
local_timer: timer@48240600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x48240600 0x100>;
- interrupts = ;
+ interrupts = ;
interrupt-parent = <&gic>;
clocks = <&mpu_periphclk>;
};
--
2.6.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] memory: omap-gpmc: Add support for AAD timings
In order to support extended timings parameters on hardware supporting the
"AAD" mode like the AM335x or DM816x, add these entries into the GPMC driver
if the hardware is capable.
Tested on DM816x and AM335x.
Signed-off-by: Neil Armstrong
---
drivers/memory/omap-gpmc.c | 30 ++
include/linux/omap-gpmc.h | 5 +
2 files changed, 35 insertions(+)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 6515dfc..21825dd 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -541,9 +541,20 @@ static void gpmc_cs_show_timings(int cs, const char *desc)
GPMC_GET_TICKS(GPMC_CS_CONFIG3, 0, 3, "adv-on-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG3, 8, 12, "adv-rd-off-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG3, 16, 20, "adv-wr-off-ns");
+ if (gpmc_capability & GPMC_HAS_MUX_AAD) {
+ GPMC_GET_TICKS(GPMC_CS_CONFIG3, 4, 6, "adv-aad-mux-on-ns");
+ GPMC_GET_TICKS(GPMC_CS_CONFIG3, 24, 26,
+ "adv-aad-mux-rd-off-ns");
+ GPMC_GET_TICKS(GPMC_CS_CONFIG3, 28, 30,
+ "adv-aad-mux-wr-off-ns");
+ }
GPMC_GET_TICKS(GPMC_CS_CONFIG4, 0, 3, "oe-on-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG4, 8, 12, "oe-off-ns");
+ if (gpmc_capability & GPMC_HAS_MUX_AAD) {
+ GPMC_GET_TICKS(GPMC_CS_CONFIG4, 4, 6, "oe-aad-mux-on-ns");
+ GPMC_GET_TICKS(GPMC_CS_CONFIG4, 13, 15, "oe-aad-mux-off-ns");
+ }
GPMC_GET_TICKS(GPMC_CS_CONFIG4, 16, 19, "we-on-ns");
GPMC_GET_TICKS(GPMC_CS_CONFIG4, 24, 28, "we-off-ns");
@@ -734,9 +745,18 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t,
GPMC_SET_ONE(GPMC_CS_CONFIG3, 0, 3, adv_on);
GPMC_SET_ONE(GPMC_CS_CONFIG3, 8, 12, adv_rd_off);
GPMC_SET_ONE(GPMC_CS_CONFIG3, 16, 20, adv_wr_off);
+ if (gpmc_capability & GPMC_HAS_MUX_AAD) {
+ GPMC_SET_ONE(GPMC_CS_CONFIG3, 4, 6, adv_aad_mux_on);
+ GPMC_SET_ONE(GPMC_CS_CONFIG3, 24, 26, adv_aad_mux_rd_off);
+ GPMC_SET_ONE(GPMC_CS_CONFIG3, 28, 30, adv_aad_mux_wr_off);
+ }
GPMC_SET_ONE(GPMC_CS_CONFIG4, 0, 3, oe_on);
GPMC_SET_ONE(GPMC_CS_CONFIG4, 8, 12, oe_off);
+ if (gpmc_capability & GPMC_HAS_MUX_AAD) {
+ GPMC_SET_ONE(GPMC_CS_CONFIG4, 4, 6, oe_aad_mux_on);
+ GPMC_SET_ONE(GPMC_CS_CONFIG4, 13, 15, oe_aad_mux_off);
+ }
GPMC_SET_ONE(GPMC_CS_CONFIG4, 16, 19, we_on);
GPMC_SET_ONE(GPMC_CS_CONFIG4, 24, 28, we_off);
@@ -1722,6 +1742,12 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
of_property_read_u32(np, "gpmc,adv-on-ns", &gpmc_t->adv_on);
of_property_read_u32(np, "gpmc,adv-rd-off-ns", &gpmc_t->adv_rd_off);
of_property_read_u32(np, "gpmc,adv-wr-off-ns", &gpmc_t->adv_wr_off);
+ of_property_read_u32(np, "gpmc,adv-aad-mux-on-ns",
+&gpmc_t->adv_aad_mux_on);
+ of_property_read_u32(np, "gpmc,adv-aad-mux-rd-off-ns",
+&gpmc_t->adv_aad_mux_rd_off);
+ of_property_read_u32(np, "gpmc,adv-aad-mux-wr-off-ns",
+&gpmc_t->adv_aad_mux_wr_off);
/* WE signal timings */
of_property_read_u32(np, "gpmc,we-on-ns", &gpmc_t->we_on);
@@ -1730,6 +1756,10 @@ static void __maybe_unused gpmc_read_timings_dt(struct
device_node *np,
/* OE signal timings */
of_property_read_u32(np, "gpmc,oe-on-ns", &gpmc_t->oe_on);
of_property_read_u32(np, "gpmc,oe-off-ns", &gpmc_t->oe_off);
+ of_property_read_u32(np, "gpmc,oe-aad-mux-on-ns",
+&gpmc_t->oe_aad_mux_on);
+ of_property_read_u32(np, "gpmc,oe-aad-mux-off-ns",
+&gpmc_t->oe_aad_mux_off);
/* access and cycle timings */
of_property_read_u32(np, "gpmc,page-burst-access-ns",
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 7dee0014..d833eb4 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -51,6 +51,9 @@ struct gpmc_timings {
u32 adv_on; /* Assertion time */
u32 adv_rd_off; /* Read deassertion time */
u32 adv_wr_off; /* Write deassertion time */
+ u32 adv_aad_mux_on; /* ADV assertion time for AAD */
+ u32 adv_aad_mux_rd_off; /* ADV read deassertion time for AAD */
+ u32 adv_aad_mux_wr_off; /* ADV write deassertion time for AAD */
/* WE signals timings corresponding to GPMC_CONFIG4 */
u32 we_on; /* WE assertion time */
@@ -59,6 +62,8 @@ struct gpmc_timings {
/* OE signals timings corresponding to GPMC_CONFIG4 */
u32 oe_on; /* OE assertion time */
u32 oe_off; /* OE deassertion time */
+ u32 oe_aad_mux_on; /* OE assertion time for AAD */
+ u32 oe_aad_mux_off
[PATCH 2/2] dt-bindings: bus: ti-gpmc: Add AAD timings properties
In order to support advanced AAD timings, add these properties to the DT GPMC bindings. Signed-off-by: Neil Armstrong --- Documentation/devicetree/bindings/bus/ti-gpmc.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt index 704be93..0168370 100644 --- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt @@ -46,6 +46,9 @@ Timing properties for child nodes. All are optional and default to 0. - gpmc,adv-on-ns: Assertion time - gpmc,adv-rd-off-ns: Read deassertion time - gpmc,adv-wr-off-ns: Write deassertion time + - gpmc,adv-aad-mux-on-ns: Assertion time for AAD + - gpmc,adv-aad-mux-rd-off-ns: Read deassertion time for AAD + - gpmc,adv-aad-mux-wr-off-ns: Write deassertion time for AAD WE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4: - gpmc,we-on-ns Assertion time @@ -54,6 +57,8 @@ Timing properties for child nodes. All are optional and default to 0. OE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4: - gpmc,oe-on-ns: Assertion time - gpmc,oe-off-ns: Deassertion time + - gpmc,oe-aad-mux-on-ns: Assertion time for AAD + - gpmc,oe-aad-mux-off-ns: Deassertion time for AAD Access time and cycle time timings (in nanoseconds) corresponding to GPMC_CONFIG5: -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ti-gpmc: Add support for AAD timings
This serie add support for the GPMC Advanced AAD timings on hardware supporting the feature like the AM335x and DM816X. Neil Armstrong (2): memory: omap-gpmc: Add support for AAD timings dt-bindings: bus: ti-gpmc: Add AAD timings properties Documentation/devicetree/bindings/bus/ti-gpmc.txt | 5 drivers/memory/omap-gpmc.c| 30 +++ include/linux/omap-gpmc.h | 5 3 files changed, 40 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] PM/OPP: Set cpu_dev->id in cpumask first
Set cpu_dev->id in cpumask first when setting up cpumask for CPUs that share the same OPP table. This might be helpful when handling cpumask without the original CPU bitfield set. Signed-off-by: Pi-Cheng Chen --- v1->v2: - Set cpu_dev->id in cpumask at the top instead of skip it in the loop --- drivers/base/power/opp/cpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c index 7b445e8..9f0c155 100644 --- a/drivers/base/power/opp/cpu.c +++ b/drivers/base/power/opp/cpu.c @@ -214,7 +214,6 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_of_cpumask_add_table); /* * Works only for OPP v2 bindings. * - * cpumask should be already set to mask of cpu_dev->id. * Returns -ENOENT if operating-points-v2 bindings aren't supported. */ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, cpumask_var_t cpumask) @@ -230,6 +229,8 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, cpumask_var_t cpumask return -ENOENT; } + cpumask_set_cpu(cpu_dev->id, cpumask); + /* OPPs are shared ? */ if (!of_property_read_bool(np, "opp-shared")) goto put_cpu_node; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v1 4/4] clk: rockchip: rk3036: fix and add node id for emac clock
Hi,
Am Montag, 28. Dezember 2015, 17:03:53 schrieb Xing Zheng:
> Due to referred old version TRM, there is incorrect emac clock node,
> we should fix it. The SEL_21_9 is the parent of SEL_21_4.
>
> In the emac driver, we need to refer HCLK_MAC, and because There are
> only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
> GPLL, and it is unable to provide the accurate rate for mac_ref which
> need to 50MHz probability, we should let it under the APLL and are
> able to set the freq which integer multiples of 50MHz, so we add these
> emac node for reference.
I don't really follow here. While I do understand that the emac needs 50MHz, I
don't think using the APLL as source is helpful.
The APLL is the main clocksource for the cpu-cores, including frequency
scaling, and while it currently only lists 816MHz as sole frequency, you're
pretty much guaranteed to not get your correct multiple of 50MHz from there
either. And limiting the cpu to just do 600MHz to get the mac working sounds
pretty bad ;-) .
In the rk3036 cru-node the gpll gets set to 594MHz. Is there a special reason
why it needs to be 594MHz and cannot be a round 600MHz? Because that would
also provide your 50MHz-multiple nicely.
> Signed-off-by: Xing Zheng
> ---
>
> drivers/clk/rockchip/clk-rk3036.c | 11 ++-
> include/dt-bindings/clock/rk3036-cru.h |2 ++
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3036.c
> b/drivers/clk/rockchip/clk-rk3036.c index 7420cbe..7863c4d 100644
> --- a/drivers/clk/rockchip/clk-rk3036.c
> +++ b/drivers/clk/rockchip/clk-rk3036.c
> @@ -328,13 +328,14 @@ static struct rockchip_clk_branch
> rk3036_clk_branches[] __initdata = { RK2928_CLKSEL_CON(16), 0, 2, MFLAGS,
> 2, 5, DFLAGS,
> RK2928_CLKGATE_CON(10), 5, GFLAGS),
>
> - COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
> - RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 4, 5, DFLAGS),
> + MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
> + RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
> + DIV(0, "mac_pll_src", "mac_pll_pre", 0,
> + RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
> MUX(SCLK_MACREF, "mac_clk_ref", mux_mac_p, CLK_SET_RATE_PARENT,
> RK2928_CLKSEL_CON(21), 3, 1, MFLAGS),
> -
> COMPOSITE_NOMUX(SCLK_MAC, "mac_clk", "mac_clk_ref", 0,
> - RK2928_CLKSEL_CON(21), 9, 5, DFLAGS,
> + RK2928_CLKSEL_CON(21), 4, 5, DFLAGS,
> RK2928_CLKGATE_CON(2), 6, GFLAGS),
>
> MUX(SCLK_HDMI, "dclk_hdmi", mux_dclk_p, 0,
> @@ -389,7 +390,7 @@ static struct rockchip_clk_branch rk3036_clk_branches[]
> __initdata = { GATE(HCLK_OTG1, "hclk_otg1", "hclk_peri", CLK_IGNORE_UNUSED,
> RK2928_CLKGATE_CON(7), 3, GFLAGS), GATE(HCLK_I2S, "hclk_i2s", "hclk_peri",
> 0, RK2928_CLKGATE_CON(7), 2, GFLAGS), GATE(0, "hclk_sfc", "hclk_peri",
> CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 14, GFLAGS), - GATE(0,
> "hclk_mac", "hclk_peri", CLK_IGNORE_UNUSED, RK2928_CLKGATE_CON(3), 15,
> GFLAGS), +GATE(HCLK_MAC, "hclk_mac", "hclk_peri", 0,
> RK2928_CLKGATE_CON(3), 5, GFLAGS),
>
> /* pclk_peri gates */
> GATE(0, "pclk_peri_matrix", "pclk_peri", CLK_IGNORE_UNUSED,
> RK2928_CLKGATE_CON(4), 1, GFLAGS), diff --git
> a/include/dt-bindings/clock/rk3036-cru.h
> b/include/dt-bindings/clock/rk3036-cru.h index ebc7a7b..de44109 100644
> --- a/include/dt-bindings/clock/rk3036-cru.h
> +++ b/include/dt-bindings/clock/rk3036-cru.h
> @@ -54,6 +54,7 @@
> #define SCLK_PVTM_VIDEO 125
> #define SCLK_MAC 151
> #define SCLK_MACREF 152
> +#define SCLK_MACPLL 153
> #define SCLK_SFC 160
>
> /* aclk gates */
> @@ -92,6 +93,7 @@
please separate the hclk addition into two separate patches:
patch1: add the clock-id to the dt-binding header
patch2: use the clock in the clock-driver
> #define HCLK_SDMMC 456
> #define HCLK_SDIO457
> #define HCLK_EMMC459
> +#define HCLK_MAC 460
> #define HCLK_I2S 462
> #define HCLK_LCDC465
> #define HCLK_ROM 467
Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] wlcore/wl12xx: spi: add wifi support to cm-t335
Device tree modifications:
- Pinmux for SPI0 and WiFi GPIOs.
- SPI0 node with wlcore as a child node.
Cc: Tony Lindgren
Signed-off-by: Uri Mashiach
Acked-by: Igor Grinberg
---
v1 -> v2: Replace interrupts and interrupt-parent with interrupts-extended.
v2 -> v3: Move the pinctrl-0 = <&wifi_pins> to the wlcore node.
arch/arm/boot/dts/am335x-cm-t335.dts | 54
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts
b/arch/arm/boot/dts/am335x-cm-t335.dts
index 42e9b66..b700940 100644
--- a/arch/arm/boot/dts/am335x-cm-t335.dts
+++ b/arch/arm/boot/dts/am335x-cm-t335.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "am33xx.dtsi"
+#include
/ {
model = "CompuLab CM-T335";
@@ -40,6 +41,15 @@
regulator-max-microvolt = <330>;
};
+ /* Regulator for WiFi */
+ vwlan_fixed: fixedregulator@2 {
+ compatible = "regulator-fixed";
+ regulator-name = "vwlan_fixed";
+ gpio = <&gpio0 20 GPIO_ACTIVE_HIGH>; /* gpio0_20 */
+ enable-active-high;
+ regulator-boot-off;
+ };
+
backlight {
compatible = "pwm-backlight";
pwms = <&ecap0 0 5 0>;
@@ -223,6 +233,21 @@
>;
};
+ spi0_pins: pinmux_spi0_pins {
+ pinctrl-single,pins = <
+ /* spi0_sclk.spi0_sclk */
+ AM33XX_IOPAD(0x950, PIN_INPUT | MUX_MODE0)
+ /* spi0_d0.spi0_d0 */
+ AM33XX_IOPAD(0x954, PIN_OUTPUT_PULLUP | MUX_MODE0)
+ /* spi0_d1.spi0_d1 */
+ AM33XX_IOPAD(0x958, PIN_INPUT | MUX_MODE0)
+ /* spi0_cs0.spi0_cs0 */
+ AM33XX_IOPAD(0x95C, PIN_OUTPUT | MUX_MODE0)
+ /* spi0_cs1.spi0_cs1 */
+ AM33XX_IOPAD(0x960, PIN_OUTPUT | MUX_MODE0)
+ >;
+ };
+
/* wl1271 bluetooth */
bluetooth_pins: pinmux_bluetooth_pins {
pinctrl-single,pins = <
@@ -230,6 +255,16 @@
AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLUP | MUX_MODE7)
>;
};
+
+ /* wl1271 WiFi */
+ wifi_pins: pinmux_wifi_pins {
+ pinctrl-single,pins = <
+ /* EMU1.gpio3_8 - WiFi IRQ */
+ AM33XX_IOPAD(0x9e8, PIN_INPUT_PULLUP | MUX_MODE7)
+ /* XDMA_EVENT_INTR1.gpio0_20 - WiFi enable */
+ AM33XX_IOPAD(0x9b4, PIN_OUTPUT | MUX_MODE7)
+ >;
+ };
};
&uart0 {
@@ -394,3 +429,22 @@ status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
};
+
+&spi0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins>;
+ ti,pindir-d0-out-d1-in = <1>;
+ /* WLS1271 WiFi */
+ wlcore: wlcore@1 {
+ compatible = "ti,wl1271";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_pins>;
+ reg = <1>;
+ spi-max-frequency = <4800>;
+ clock-xtal;
+ ref-clock-frequency = <3840>;
+ interrupts-extended = <&gpio3 8 IRQ_TYPE_LEVEL_HIGH>;
+ vwlan-supply = <&vwlan_fixed>;
+ };
+};
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] wlcore/wl12xx: spi: add device tree support
Add DT support for the wl1271 SPI WiFi.
Add documentation file for the wl1271 SPI WiFi.
Signed-off-by: Uri Mashiach
Acked-by: Igor Grinberg
---
v1 -> v2: update interrupt documentation.
replace interrupts and interrupt-parent with interrupts-extended.
IRQ parameters retrieved from spi_device instead of DT.
remove redundant #ifdef CONFIG_OF
v2 -> v3: Add MODULE_DEVICE_TABLE.
Remove #ifdef CONFIG_OF.
Make the Kconfig symbol to depend on OF.
Replace irqd_get_trigger_type() with irq_get_trigger_type().
.../bindings/net/wireless/ti,wlcore,spi.txt| 34
drivers/net/wireless/ti/wlcore/Kconfig | 2 +-
drivers/net/wireless/ti/wlcore/spi.c | 47 --
3 files changed, 78 insertions(+), 5 deletions(-)
create mode 100644
Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
new file mode 100644
index 000..502c27e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -0,0 +1,34 @@
+* Texas Instruments wl1271 wireless lan controller
+
+The wl1271 chip can be connected via SPI or via SDIO. This
+document describes the binding for the SPI connected chip.
+
+Required properties:
+- compatible : Should be "ti,wl1271"
+- reg : Chip select address of device
+- spi-max-frequency : Maximum SPI clocking speed of device in Hz
+- ref-clock-frequency : Reference clock frequency
+- interrupts-extended : Should contain parameters for 1 interrupt line.
+Interrupt parameters: parent, line number, type.
+- vwlan-supply :Point the node of the regulator that powers/enable the
wl1271 chip
+
+Optional properties:
+- clock-xtal : boolean, clock is generated from XTAL
+
+- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
+ for optional SPI connection related properties,
+
+Examples:
+
+&spi1 {
+ wl1271@1 {
+ compatible = "ti,wl1271";
+
+ reg = <1>;
+ spi-max-frequency = <4800>;
+ clock-xtal;
+ ref-clock-frequency = <3840>;
+ interrupts-extended = <&gpio3 8 IRQ_TYPE_LEVEL_HIGH>;
+ vwlan-supply = <&vwlan_fixed>;
+ };
+};
diff --git a/drivers/net/wireless/ti/wlcore/Kconfig
b/drivers/net/wireless/ti/wlcore/Kconfig
index 7c09954..5918080 100644
--- a/drivers/net/wireless/ti/wlcore/Kconfig
+++ b/drivers/net/wireless/ti/wlcore/Kconfig
@@ -13,7 +13,7 @@ config WLCORE
config WLCORE_SPI
tristate "TI wlcore SPI support"
- depends on WLCORE && SPI_MASTER
+ depends on WLCORE && SPI_MASTER && OF
select CRC7
---help---
This module adds support for the SPI interface of adapters using
diff --git a/drivers/net/wireless/ti/wlcore/spi.c
b/drivers/net/wireless/ti/wlcore/spi.c
index d3a4bcb..0f2fb50 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include "wlcore.h"
@@ -357,6 +358,39 @@ static struct wl1271_if_operations spi_ops = {
.set_block_size = NULL,
};
+static const struct of_device_id wlcore_spi_of_match_table[] = {
+ { .compatible = "ti,wl1271" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, wlcore_spi_of_match_table);
+
+/**
+ * wlcore_probe_of - DT node parsing.
+ * @spi: SPI slave device parameters.
+ * @res: resource parameters.
+ * @glue: wl12xx SPI bus to slave device glue parameters.
+ * @pdev_data: wlcore device parameters
+ */
+static int wlcore_probe_of(struct spi_device *spi, struct wl12xx_spi_glue
*glue,
+ struct wlcore_platdev_data *pdev_data)
+{
+ struct device_node *dt_node = spi->dev.of_node;
+ int ret;
+
+ if (of_find_property(dt_node, "clock-xtal", NULL))
+ pdev_data->ref_clock_xtal = true;
+
+ ret = of_property_read_u32(dt_node, "ref-clock-frequency",
+ &pdev_data->ref_clock_freq);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(glue->dev,
+ "can't get reference clock frequency (%d)\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
static int wl1271_probe(struct spi_device *spi)
{
struct wl12xx_spi_glue *glue;
@@ -366,8 +400,6 @@ static int wl1271_probe(struct spi_device *spi)
memset(&pdev_data, 0x00, sizeof(pdev_data));
- /* TODO: add DT parsing when needed */
-
pdev_data.if_ops = &spi_ops;
glue = devm_kzalloc(&spi->dev, sizeof(*glue), GFP_KERNEL);
@@ -390,6 +422,13 @@ static int wl1271_probe(struct spi_device *spi)
return PTR_ERR(glue->reg);
}
+ ret = wlcore_probe_of(spi, glue, &pdev_data);
+ if (
[PATCH v3 0/3] wlcore/wl12xx: spi: add wifi support to cm-t335
Add DT support for WLS1271 SPI driver. Add power operation function to the WLS1271 SPI driver. Uri Mashiach (3): wlcore/wl12xx: spi: add power operation function wlcore/wl12xx: spi: add device tree support wlcore/wl12xx: spi: add wifi support to cm-t335 .../bindings/net/wireless/ti,wlcore,spi.txt| 34 + arch/arm/boot/dts/am335x-cm-t335.dts | 54 ++ drivers/net/wireless/ti/wlcore/Kconfig | 2 +- drivers/net/wireless/ti/wlcore/spi.c | 84 -- 4 files changed, 169 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] wlcore/wl12xx: spi: add power operation function
The power function uses a consumer regulator access to update the WiFi
enable GPIO value.
Signed-off-by: Uri Mashiach
---
v1 -> v2: oops fix was removed to a separate fix.
v2 -> v3: no changes
drivers/net/wireless/ti/wlcore/spi.c | 37
1 file changed, 37 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/spi.c
b/drivers/net/wireless/ti/wlcore/spi.c
index 44f059f..d3a4bcb 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "wlcore.h"
#include "wl12xx_80211.h"
@@ -81,6 +82,7 @@
struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
+ struct regulator *reg; /* Power regulator */
};
static void wl12xx_spi_reset(struct device *child)
@@ -318,11 +320,40 @@ static int __must_check wl12xx_spi_raw_write(struct
device *child, int addr,
return 0;
}
+/**
+ * wl12xx_spi_set_power - power on/off the wl12xx unit
+ * @child: wl12xx device handle.
+ * @enable: true/false to power on/off the unit.
+ *
+ * use the WiFi enable regulator to enable/disable the WiFi unit.
+ */
+static int wl12xx_spi_set_power(struct device *child, bool enable)
+{
+ int ret = 0;
+ struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
+
+ WARN_ON(!glue->reg);
+
+ /* Update regulator state */
+ if (enable) {
+ ret = regulator_enable(glue->reg);
+ if (ret)
+ dev_err(child, "Power enable failure\n");
+ } else {
+ ret = regulator_disable(glue->reg);
+ if (ret)
+ dev_err(child, "Power disable failure\n");
+ }
+
+ return ret;
+}
+
static struct wl1271_if_operations spi_ops = {
.read = wl12xx_spi_raw_read,
.write = wl12xx_spi_raw_write,
.reset = wl12xx_spi_reset,
.init = wl12xx_spi_init,
+ .power = wl12xx_spi_set_power,
.set_block_size = NULL,
};
@@ -353,6 +384,12 @@ static int wl1271_probe(struct spi_device *spi)
* comes from the board-peripherals file */
spi->bits_per_word = 32;
+ glue->reg = devm_regulator_get(&spi->dev, "vwlan");
+ if (IS_ERR(glue->reg)) {
+ dev_err(glue->dev, "can't get regulator\n");
+ return PTR_ERR(glue->reg);
+ }
+
ret = spi_setup(spi);
if (ret < 0) {
dev_err(glue->dev, "spi_setup failed\n");
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] wlcore/wl12xx: spi: add power operation function
On 12/27/2015 07:14 PM, Uri Mashiach wrote:
> Hello Grygorii,
>
> On 12/24/2015 06:32 PM, Grygorii Strashko wrote:
>> On 12/24/2015 05:35 PM, Uri Mashiach wrote:
>>> The power function uses a consumer regulator access to update the WiFi
>>> enable GPIO value.
>>>
>>> Signed-off-by: Uri Mashiach
>>> ---
>>> v1 -> v2: oops fix was removed to a separate fix.
>>>
>>> drivers/net/wireless/ti/wlcore/spi.c | 37
>>>
>>> 1 file changed, 37 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ti/wlcore/spi.c
>>> b/drivers/net/wireless/ti/wlcore/spi.c
>>>
>>
>> [...]
>>
>>> +
>>> static struct wl1271_if_operations spi_ops = {
>>> .read= wl12xx_spi_raw_read,
>>> .write= wl12xx_spi_raw_write,
>>> .reset= wl12xx_spi_reset,
>>> .init= wl12xx_spi_init,
>>> +.power= wl12xx_spi_set_power,
>>> .set_block_size = NULL,
>>> };
>>>
>>> @@ -353,6 +384,12 @@ static int wl1271_probe(struct spi_device *spi)
>>>* comes from the board-peripherals file */
>>> spi->bits_per_word = 32;
>>>
>>> +glue->reg = devm_regulator_get(&spi->dev, "vwlan");
>>> +if (IS_ERR(glue->reg)) {
>>
>> It will be more correct to handle -EPROBE_DEFER here also. Like:
>> if (PTR_ERR(glue->reg) == -EPROBE_DEFER)
>> return PTR_ERR(glue->reg);
>>
>
> It seems that the IS_ERR(glue->reg) condition covers the EPROBE_DEFER case.
True. But this is not an error and it's common practice do not print
any log messages in this case from driver :)
>
>>> +dev_err(glue->dev, "can't get regulator\n");
>>> +return PTR_ERR(glue->reg);
>>> +}
>>> +
>>> ret = spi_setup(spi);
>>> if (ret < 0) {
>>> dev_err(glue->dev, "spi_setup failed\n");
>>>
>>
>>
>
--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] Documentation: DT: Add entry for ARM SP805-WDT
This patch adds a devicetree binding documentation for ARM's
SP805 WatchDog Timer.
Signed-off-by: Bhupesh Sharma
Acked-by: Rob Herring
---
.../devicetree/bindings/watchdog/sp805-wdt.txt | 31
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
new file mode 100644
index 000..edc4f0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
@@ -0,0 +1,31 @@
+* ARM SP805 Watchdog Timer (WDT) Controller
+
+SP805 WDT is a ARM Primecell Peripheral and has a standard-id register that
+can be used to identify the peripheral type, vendor, and revision.
+This value can be used for driver matching.
+
+As SP805 WDT is a primecell IP, it follows the base bindings specified in
+'arm/primecell.txt'
+
+Required properties:
+- compatible : Should be "arm,sp805-wdt", "arm,primecell"
+- reg : Base address and size of the watchdog timer registers.
+- clocks : From common clock binding.
+ First clock is PCLK and the second is WDOGCLK.
+ WDOGCLK can be equal to or be a sub-multiple of the PCLK frequency.
+- clock-names : From common clock binding.
+Shall be "apb_pclk" for first clock and "wdog_clk" for the
+second one.
+
+Optional properties:
+- interrupts : Should specify WDT interrupt number.
+
+Examples:
+
+ cluster1_core0_watchdog: wdt@c00 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc00 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] dts/ls2080a: Update DTSI to add support of SP805 WDT
This patch updates the LS2080a DTSI (DTS Include) file to add
support for eight SP805 Watchdog units which can be used to
reset the eight Cortex-A57 cores available on LS2080A.
Signed-off-by: Bhupesh Sharma
---
arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 56
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index e81cd48..7b0f411 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -193,6 +193,62 @@
interrupts = <0 32 0x4>; /* Level high type */
};
+ cluster1_core0_watchdog: wdt@c00 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc00 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster1_core1_watchdog: wdt@c01 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc01 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster2_core0_watchdog: wdt@c10 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc10 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster2_core1_watchdog: wdt@c11 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc11 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster3_core0_watchdog: wdt@c20 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc20 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster3_core1_watchdog: wdt@c21 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc21 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster4_core0_watchdog: wdt@c30 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc30 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
+ cluster4_core1_watchdog: wdt@c31 {
+ compatible = "arm,sp805-wdt", "arm,primecell";
+ reg = <0x0 0xc31 0x0 0x1000>;
+ clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+ clock-names = "apb_pclk", "wdog_clk";
+ };
+
fsl_mc: fsl-mc@80c00 {
compatible = "fsl,qoriq-mc";
reg = <0x0008 0x0c00 0 0x40>,/* MC portal
base */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] ARM: dts: Add compatible property to "partitions" node
Hi Simon,
On Mon, Dec 28, 2015 at 6:01 AM, Simon Horman wrote:
> On Mon, Dec 21, 2015 at 11:33:44AM +0100, Geert Uytterhoeven wrote:
>> As of commit e488ca9f8d4f62c2 ("doc: dt: mtd: partitions: add compatible
>> property to "partitions" node"), which is in v4.4-rc6, the "partitions"
>> subnode of an SPI FLASH device node must have a compatible property. The
>> partitions are no longer detected if it is not present.
>>
>> However, several DTSes in -next have already been converted to the
>> "partitions" subnode without "compatible" property, introduced by
>> commits 5cfdedb7b9a0fe38 ("mtd: ofpart: move ofpart partitions to a
>> dedicated dt node") and fe2585e9c29a650a ("doc: dt: mtd: support
>> partitions in a special 'partitions' subnode"). Hence all of these are
>> now broken in -next, and will be broken in upstream during the merge
>> window.
>>
>> This series fixes all users in next-20151221.
>> Tested on r8a7791/koelsch.
>>
>> Changes since v1:
>> - Add Acked-by,
>> - Fix new users in -next (kirkwood, ci20).
>>
>> Most of these are in arm-soc/for-next. Exceptions are kirkwood (in
>> mvebu/for-next), and ci20 (in mips/mips-for-linux-next).
>>
>> Given we're late in the v4.4-rc cycle, perhaps it's easiest if the
>> arm-soc maintainers take all applicable patches directly, bypassing the
>> mvebu and shmobile maintainers?
>>
>> Thanks for queuing for v4.5!
>>
>> Geert Uytterhoeven (9):
>> ARM: mvebu: ix4-300d: Add compatible property to "partitions" node
>> ARM: mvebu: kirkwood: Add compatible property to "partitions" node
>> ARM: shmobile: bockw dts: Add compatible property to "partitions" node
>> ARM: shmobile: lager dts: Add compatible property to "partitions" node
>> ARM: shmobile: koelsch dts: Add compatible property to "partitions"
>> node
>> ARM: shmobile: porter dts: Add compatible property to "partitions"
>> node
>> ARM: shmobile: gose dts: Add compatible property to "partitions" node
>> ARM: shmobile: silk dts: Add compatible property to "partitions" node
>
> Thanks, I have queued up the above "shmobile" patches for v4.6.
I'm afraid v4.6 is too late, leaving all SPI FLASHes broken in v4.5.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/2] ARM64: Enable SP805 WDT support for FSL LS2080A
Hi Arnd, Kevin, Olof This is the v4 of patchset which adds the support for SP805 WDT on FSL LS2080A and also adds the missing documentation of SP805 WDT device-tree bindings. Rebased against arm-soc/next/dt Changes since v3: (v3 can be viewed here: https://www.mail-archive.com/devicetree@vger.kernel.org/msg97249.html) - Added Rob's Acked-by for patch 1/2. - Sending to 'a...@kernel.org' list and also cc'ed Shawn Guo Changes since v2: (v2 can be viewed here: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/463141) - Addressed Rob's comments regarding the second mandatory CLK source's (WDOGCLK) name in the bindings. Changes since v1: (v1 can be viewed here: http://www.spinics.net/lists/devicetree/msg102487.html) - Addressed Rob and Mark's comments regarding the mandatory CLK sources - Removed interrupt property from the bindings for now (as discussed with Mark on IRC) till Will's patch proceeds further and enables handling the WDOG interrupts for each core connected to the same PPI line (http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/391616.html) Bhupesh Sharma (2): Documentation: DT: Add entry for ARM SP805-WDT dts/ls2080a: Update DTSI to add support of SP805 WDT .../devicetree/bindings/watchdog/sp805-wdt.txt | 31 +++ arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 56 2 files changed, 87 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] dts/ls2080a: Update DTSI to add support of SP805 WDT
On Fri, Dec 25, 2015 at 7:26 AM, Shawn Guo wrote: > On Thu, Dec 24, 2015 at 08:41:54PM +, Sharma Bhupesh wrote: >> >> >> > -Original Message- >> > From: Arnd Bergmann [mailto:a...@arndb.de] >> > Sent: Thursday, December 24, 2015 3:49 PM >> > To: Bhupesh SHARMA >> > Cc: Sharma Bhupesh-B45370; Mark Rutland; linux-arm- >> > ker...@lists.infradead.org; Olof Johansson; devicetree@vger.kernel.org; >> > Rob Herring; Will Deacon; Catalin Marinas; Li Yang-Leo-R58472; Wood >> > Scott-B07421; Yoder Stuart-B08248; shawn@linaro.org >> > Subject: Re: [PATCH v3 2/2] dts/ls2080a: Update DTSI to add support of >> > SP805 WDT >> > >> > On Wednesday 23 December 2015, Bhupesh SHARMA wrote: >> > > >> > > Hi Arnd, Olof, Kevin >> > > >> > > On Tue, Dec 15, 2015 at 8:00 PM, Bhupesh Sharma >> > > wrote: >> > > > This patch updates the LS2080a DTSI (DTS Include) file to add >> > > > support for eight SP805 Watchdog units which can be used to reset >> > > > the eight Cortex-A57 cores available on LS2080A. >> > > > >> > > > Signed-off-by: Bhupesh Sharma >> > > > --- >> > > > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 56 >> > >> > > > 1 file changed, 56 insertions(+) >> > > >> > > Since Rob has acked the SP805 WDT binding documentation patch (patch >> > > 1/2 of this series), >> > > can this DTSI change, please be considered for absorption in the arm- >> > soc tree. >> > >> > Sure, please submit it for inclusion. Who is the maintainer for >> > arch/arm64/boot/dts/freescale/ ? Can they pick up all the freescale >> > related dts changes and submit them as a pull request? Should they go >> > through Shawn's tree maybe? >> >> Thanks Arnd. For now, may-be I can send this patchset with Rob's Acked-by >> added >> for 1/2 to 'a...@kernel.org'. So that this can be picked by via the arm-soc >> tree. >> Shawn, I hope it's ok with you. > > Yeah. I'm maintaining a git tree, collecting all Freescale arm32 > platform patches, and sending them to arm-soc for each merge window. > If I can be copied on those arm64 patches, I do not mind handling them > together with arm32 ones. Thanks Shawn. Sure, I will make sure to remember the same for future arm64 patches. Regards, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver
On Tue, Dec 15, 2015 at 09:38:41PM +0100, Arnd Bergmann wrote: > On Tuesday 15 December 2015 18:42:36 Thierry Reding wrote: > > On Tue, Dec 15, 2015 at 05:34:00PM +0100, Arnd Bergmann wrote: > > > On Tuesday 15 December 2015 17:31:22 Thierry Reding wrote: > > > > On Mon, Dec 14, 2015 at 12:39:44PM +0100, Arnd Bergmann wrote: > > > > > On Wednesday 18 November 2015 17:56:22 Andy Yan wrote: > > > > > > rockchip platform have a protocol to pass the kernel reboot > > > > > > mode to bootloader by some special registers when system reboot. > > > > > > By this way the bootloader can take different action according > > > > > > to the different kernel reboot mode, for example, command > > > > > > "reboot loader" will reboot the board to rockusb mode, this is > > > > > > a very convenient way to get the board enter download mode. > > > > > > > > > > > > Signed-off-by: Andy Yan > > > > > > > > > > Adding John Stultz to Cc > > > > > > > > > > I just saw this thread pop up again, and had to think of John's recent > > > > > patch to unify this across platforms. > > > > > > > > > > John, can you have a look at this driver too, and see how it fits in? > > > > > I think this is yet another variant, using an MMIO register rather > > > > > than > > > > > RAM (as HTC / NVIDIA does) or SRAM (as Qualcomm does), but otherwise > > > > > it conceptually fits in with what you had. > > > > > > > > FWIW, Tegra typically does use an MMIO register as well. See > > > > drivers/soc/tegra/pmc.c:tegra_pmc_restart_notify(). I don't know what > > > > HTC does, but if it's writing somewhere in RAM it isn't using the > > > > standard way of resetting the SoC. There's early boot ROM code which I > > > > think evaluates the PMC_SCRATCH0 register on Tegra to determine which > > > > mode to boot into. That's before even any firmware gets the chance of > > > > doing anything. > > > I just checked the android lollipop tree, and I could not find a > pmc_restart_notify > function, only this file > > https://android.googlesource.com/kernel/tegra/+/android-tegra-flounder-3.10-lollipop-release/drivers/htc_debug/stability/reboot_params.c > > with the device that stores into RAM. It looks like HTC ported over > a driver that they were already using on some Qualcomm MSM8960 device, > as in > > https://gitlab.com/MaC/android_kernel_htc_msm8960/blob/859977fc723f59a6b707df1d70e80826ee1dccc4/arch/arm/mach-msm/htc/htc_restart_handler.c > > On Android marshmallow (Flounder), that file again does not exist, and > I don't see how it's done. > > > > HTC apparently uses a separate RAM area to pass the reboot reason, > > > and they have a driver to store that, which is separate from the > > > driver that they use for actually rebooting the machine. > > > > I wasn't very clear, but the PMC_SCRATCH0 register is used to store the > > reset reason. It supports the recovery mode, which I think is really an > > Android thing, "bootloader" will typically cause the bootloader not to > > boot anything, and "forced-recovery" will go into a recovery mode that > > is used to bootstrap the device (usually by uploading a "miniloader" > > that initializes RAM, downloads a bootloader for booting or flashing an > > operating system, ...). > > > > The write that resets the SoC is to a different register. > > So is this scratch register interpreted by some maskrom code, or by code that > can be provided by the OEM? My understanding is that its interpreted both by what's called BootROM on Tegra (I guess that's what you call "maskrom code") and the system's bootloader. The BootROM cannot typically be replaced by the OEM, but it is quite typical for the bootloader to differ between devices. The BootROM will interpret a subset of the bits in that register. Most notable the "force recovery" bit. That will cause the BootROM to go into a mode which can be used to bootstrap the device. It implements a simple protocol (RCM) which can be used to upload a loader (usually referred to as mini-loader) to the device's IRAM which in turn will initialize the memory and which can download a proper bootloader (such as U-Boot) to memory using a slightly more complex protocol (the standard protocol is called nv3p, but the particular choice of protocol no longer matters at this point). The bootloader can also access this register and will interpret the "bootloader" and "recovery" bits. On the, argueably small, sample of Android devices I've worked with, the "bootloader" bit will make the bootloader go into fastboot mode, whereas the "recovery" bit will make it initiate the RCK mode, which is used to update through OTA. There are a couple of other bits in this register, but they are badly documented and don't seem to relate to reboot. Thierry signature.asc Description: PGP signature
[RESEND PATCH v1 4/4] clk: rockchip: rk3036: fix and add node id for emac clock
Due to referred old version TRM, there is incorrect emac clock node,
we should fix it. The SEL_21_9 is the parent of SEL_21_4.
In the emac driver, we need to refer HCLK_MAC, and because There are
only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
GPLL, and it is unable to provide the accurate rate for mac_ref which
need to 50MHz probability, we should let it under the APLL and are
able to set the freq which integer multiples of 50MHz, so we add these
emac node for reference.
Signed-off-by: Xing Zheng
---
drivers/clk/rockchip/clk-rk3036.c | 11 ++-
include/dt-bindings/clock/rk3036-cru.h |2 ++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3036.c
b/drivers/clk/rockchip/clk-rk3036.c
index 7420cbe..7863c4d 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -328,13 +328,14 @@ static struct rockchip_clk_branch rk3036_clk_branches[]
__initdata = {
RK2928_CLKSEL_CON(16), 0, 2, MFLAGS, 2, 5, DFLAGS,
RK2928_CLKGATE_CON(10), 5, GFLAGS),
- COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
- RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 4, 5, DFLAGS),
+ MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
+ RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
+ DIV(0, "mac_pll_src", "mac_pll_pre", 0,
+ RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
MUX(SCLK_MACREF, "mac_clk_ref", mux_mac_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(21), 3, 1, MFLAGS),
-
COMPOSITE_NOMUX(SCLK_MAC, "mac_clk", "mac_clk_ref", 0,
- RK2928_CLKSEL_CON(21), 9, 5, DFLAGS,
+ RK2928_CLKSEL_CON(21), 4, 5, DFLAGS,
RK2928_CLKGATE_CON(2), 6, GFLAGS),
MUX(SCLK_HDMI, "dclk_hdmi", mux_dclk_p, 0,
@@ -389,7 +390,7 @@ static struct rockchip_clk_branch rk3036_clk_branches[]
__initdata = {
GATE(HCLK_OTG1, "hclk_otg1", "hclk_peri", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(7), 3, GFLAGS),
GATE(HCLK_I2S, "hclk_i2s", "hclk_peri", 0, RK2928_CLKGATE_CON(7), 2,
GFLAGS),
GATE(0, "hclk_sfc", "hclk_peri", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(3), 14, GFLAGS),
- GATE(0, "hclk_mac", "hclk_peri", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(3), 15, GFLAGS),
+ GATE(HCLK_MAC, "hclk_mac", "hclk_peri", 0, RK2928_CLKGATE_CON(3), 5,
GFLAGS),
/* pclk_peri gates */
GATE(0, "pclk_peri_matrix", "pclk_peri", CLK_IGNORE_UNUSED,
RK2928_CLKGATE_CON(4), 1, GFLAGS),
diff --git a/include/dt-bindings/clock/rk3036-cru.h
b/include/dt-bindings/clock/rk3036-cru.h
index ebc7a7b..de44109 100644
--- a/include/dt-bindings/clock/rk3036-cru.h
+++ b/include/dt-bindings/clock/rk3036-cru.h
@@ -54,6 +54,7 @@
#define SCLK_PVTM_VIDEO125
#define SCLK_MAC 151
#define SCLK_MACREF152
+#define SCLK_MACPLL153
#define SCLK_SFC 160
/* aclk gates */
@@ -92,6 +93,7 @@
#define HCLK_SDMMC 456
#define HCLK_SDIO 457
#define HCLK_EMMC 459
+#define HCLK_MAC 460
#define HCLK_I2S 462
#define HCLK_LCDC 465
#define HCLK_ROM 467
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v1 0/4] fix some clock configuration for the RK3036 platform
Hi: In the development work, we found that some of the previous incorrect clock configuration on the RK3036 platform, we should fix them. Xing Zheng (4): clk: rockchip: rk3036: fix the FLAGs for clock mux clk: rockchip: rk3036: fix uarts clock error clk: rockchip: rk3036: rename emac ext source clock clk: rockchip: rk3036: fix and add node id for emac clock drivers/clk/rockchip/clk-rk3036.c | 33 include/dt-bindings/clock/rk3036-cru.h |2 ++ 2 files changed, 19 insertions(+), 16 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 1/3] dt-bindings: binding for jz4780-{nand,bch}
On Thu, 24 Dec 2015 12:20:13 +
Harvey Hunt wrote:
> From: Alex Smith
>
> Add DT bindings for NAND devices connected to the NEMC on JZ4780 SoCs,
> as well as the hardware BCH controller, used by the jz4780_{nand,bch}
> drivers.
>
> Signed-off-by: Alex Smith
> Cc: Zubair Lutfullah Kakakhel
> Cc: David Woodhouse
> Cc: Brian Norris
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: r...@kernel.org
> Signed-off-by: Harvey Hunt
> Acked-by: Rob Herring
Already put my Reviewed-by on the previous version, but you seem to
have forgotten it.
Reviewed-by: Boris Brezillon
> ---
> v9 -> v10:
> - Added Rob Herring's Acked-by.
>
> v8 -> v9:
> - Document that partitions are represented as a child node of a NAND chip.
>
> v7 -> v8:
> - Describe how NAND chips are now child nodes of the NAND controller.
>
> v6 -> v7:
> - Add nand-ecc-mode to DT bindings.
> - Add nand-on-flash-bbt to DT bindings.
>
> v5 -> v6:
> - No change.
>
> v4 -> v5:
> - Rename ingenic,bch-device to ingenic,bch-controller to fit with
>existing convention.
>
> v3 -> v4:
> - No change
>
> v2 -> v3:
> - Rebase to 4.0-rc6
> - Changed ingenic,ecc-size to common nand-ecc-step-size
> - Changed ingenic,ecc-strength to common nand-ecc-strength
> - Changed ingenic,busy-gpio to common rb-gpios
> - Changed ingenic,wp-gpio to common wp-gpios
>
> v1 -> v2:
> - Rebase to 4.0-rc3
>
> .../bindings/mtd/ingenic,jz4780-nand.txt | 86
> ++
> 1 file changed, 86 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> new file mode 100644
> index 000..29ea585
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> @@ -0,0 +1,86 @@
> +* Ingenic JZ4780 NAND/BCH
> +
> +This file documents the device tree bindings for NAND flash devices on the
> +JZ4780. NAND devices are connected to the NEMC controller (described in
> +memory-controllers/ingenic,jz4780-nemc.txt), and thus NAND device nodes must
> +be children of the NEMC node.
> +
> +Required NAND controller device properties:
> +- compatible: Should be set to "ingenic,jz4780-nand".
> +- reg: For each bank with a NAND chip attached, should specify a bank number,
> + an offset of 0 and a size of 0x100 (i.e. the whole NEMC bank).
> +
> +Optional NAND controller device properties:
> +- ingenic,bch-controller: To make use of the hardware BCH controller, this
> + property must contain a phandle for the BCH controller node. The required
> + properties for this node are described below. If this is not specified,
> + software BCH will be used instead.
> +
> +Optional children nodes:
> +- Individual NAND chips are children of the NAND controller node.
> +
> +Required children node properties:
> +- reg: An integer ranging from 1 to 6 representing the CS line to use.
> +
> +Optional children node properties:
> +- nand-ecc-step-size: ECC block size in bytes.
> +- nand-ecc-strength: ECC strength (max number of correctable bits).
> +- nand-ecc-mode: String, operation mode of the NAND ecc mode. "hw" by default
> +- nand-on-flash-bbt: boolean to enable on flash bbt option, if not present
> false
> +- rb-gpios: GPIO specifier for the busy pin.
> +- wp-gpios: GPIO specifier for the write protect pin.
> +
> +Optional child node of NAND chip nodes:
> +- partitions: see Documentation/devicetree/bindings/mtd/partition.txt
> +
> +Example:
> +
> +nemc: nemc@1341 {
> + ...
> +
> + nandc: nand-controller@1 {
> + compatible = "ingenic,jz4780-nand";
> + reg = <1 0 0x100>; /* Bank 1 */
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ingenic,bch-controller = <&bch>;
> +
> + nand@1 {
> + reg = <1>;
> +
> + nand-ecc-step-size = <1024>;
> + nand-ecc-strength = <24>;
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + rb-gpios = <&gpa 20 GPIO_ACTIVE_LOW>;
> + wp-gpios = <&gpf 22 GPIO_ACTIVE_LOW>;
> +
> + partitions {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ...
> + }
> + };
> + };
> +};
> +
> +The BCH controller is a separate SoC component used for error correction on
> +NAND devices. The following is a description of the device properties for a
> +BCH controller.
> +
> +Required BCH properties:
> +- compatible: Should be set to "ingenic,jz4780-bch".
> +- reg: Should specify the BCH controller registers location and length.
> +- clocks: Clock for the BCH controller.
> +
> +Example:
> +
> +bch: bch@134d00
Re: [PATCH v10 3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes
On Thu, 24 Dec 2015 12:20:15 +
Harvey Hunt wrote:
> From: Alex Smith
>
> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
> and make use of them in the Ci20 device tree to add a node for the
> board's NAND.
>
> Note that since the pinctrl driver is not yet upstream, this includes
> neither pin configuration nor busy/write-protect GPIO pins for the
> NAND. Use of the NAND relies on the boot loader to have left the pins
> configured in a usable state, which should be the case when booted
> from the NAND.
>
> Signed-off-by: Alex Smith
> Cc: Zubair Lutfullah Kakakhel
> Cc: David Woodhouse
> Cc: Brian Norris
> Cc: Paul Burton
> Cc: linux-...@lists.infradead.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: r...@kernel.org
> Signed-off-by: Harvey Hunt
Reviewed-by: Boris Brezillon
> ---
> v9 -> v10:
> - No change.
>
> v8 -> v9:
> - Represent the partition table as a subnode of a NAND chip.
>
> v7 -> v8:
> - Describe the NAND chips as children nodes of the NAND controller.
> - Remove ingenic, prefix from ECC settings.
> - Renamed some ECC settings.
>
> v6 -> v7:
> - Add nand-ecc-mode to DT.
> - Add nand-on-flash-bbt to DT.
>
> v4 -> v5:
> - New patch adding DT nodes for the NAND so that the driver can be
>tested.
>
> arch/mips/boot/dts/ingenic/ci20.dts| 63
> ++
> arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 ++
> 2 files changed, 89 insertions(+)
>
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 9fcb9e7..782258c 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> @@ -42,3 +42,66 @@
> &uart4 {
> status = "okay";
> };
> +
> +&nemc {
> + status = "okay";
> +
> + nandc: nand-controller@1 {
> + compatible = "ingenic,jz4780-nand";
> + reg = <1 0 0x100>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ingenic,bch-controller = <&bch>;
> +
> + ingenic,nemc-tAS = <10>;
> + ingenic,nemc-tAH = <5>;
> + ingenic,nemc-tBP = <10>;
> + ingenic,nemc-tAW = <15>;
> + ingenic,nemc-tSTRV = <100>;
> +
> + nand@1 {
> + reg = <1>;
> +
> + nand-ecc-step-size = <1024>;
> + nand-ecc-strength = <24>;
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + partitions {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + partition@0 {
> + label = "u-boot-spl";
> + reg = <0x0 0x0 0x0 0x80>;
> + };
> +
> + partition@0x80 {
> + label = "u-boot";
> + reg = <0x0 0x80 0x0 0x20>;
> + };
> +
> + partition@0xa0 {
> + label = "u-boot-env";
> + reg = <0x0 0xa0 0x0 0x20>;
> + };
> +
> + partition@0xc0 {
> + label = "boot";
> + reg = <0x0 0xc0 0x0 0x400>;
> + };
> +
> + partition@0x8c0 {
> + label = "system";
> + reg = <0x0 0x4c0 0x1 0xfb40>;
> + };
> + };
> + };
> + };
> +};
> +
> +&bch {
> + status = "okay";
> +};
> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> index 65389f6..b868b42 100644
> --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> @@ -108,4 +108,30 @@
>
> status = "disabled";
> };
> +
> + nemc: nemc@1341 {
> + compatible = "ingenic,jz4780-nemc";
> + reg = <0x1341 0x1>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <1 0 0x1b00 0x100
> + 2 0 0x1a00 0x100
> + 3 0 0x1900 0x100
> + 4 0 0x1800 0x100
> + 5 0 0x1700 0x100
> + 6 0 0x1600 0x100>;
> +
> + clocks = <&cgu JZ4780_CLK_NEMC>;
> +
> + status = "disabled";
> + };
> +
> + bch: bch@134d {
> + compatible = "ingenic,jz4780-bch";
> + reg = <0x134d 0x1>;
Re: [PATCH v3 4/5] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for mt2701
On Mon, 2015-12-28 at 15:09 +0800, Biao Huang wrote:
> Add mt2701 support using mediatek common pinctrl driver.
> MT2701 have some special pins need an extra setting register
> than other ICs, so adding this support to common code.
>
> Signed-off-by: Biao Huang
> Acked-by: Yingjoe Chen
<...>
> +
> +static struct platform_driver mtk_pinctrl_driver = {
> + .probe = mt2701_pinctrl_probe,
> + .driver = {
> + .name = "mediatek-mt2701-pinctrl",
> + .owner = THIS_MODULE,
> + .of_match_table = mt2701_pctrl_match,
> + },
> +};
> +
> +static int __init mtk_pinctrl_init(void)
> +{
> + return platform_driver_register(&mtk_pinctrl_driver);
> +}
> +
> +arch_initcall(mtk_pinctrl_init);
As discussed in
http://lists.infradead.org/pipermail/linux-mediatek/2015-December/003350.html
we should use subsys_initcall() instead.
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> index f307f1d..76279f0 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
<...>
> @@ -347,6 +352,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev
> *pctldev,
> ret = mtk_pconf_set_pull_select(pctl, pin, true, false, arg);
> break;
> case PIN_CONFIG_INPUT_ENABLE:
> + mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
> ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
> break;
> case PIN_CONFIG_OUTPUT:
> @@ -354,6 +360,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev
> *pctldev,
> ret = mtk_pmx_gpio_set_direction(pctldev, NULL, pin, false);
> break;
> case PIN_CONFIG_INPUT_SCHMITT_ENABLE:
> + mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
> ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
> break;
> case PIN_CONFIG_DRIVE_STRENGTH:
This change is not directly related to adding mt2710 support and change
behavior for all MTK pinctrl drivers, please create a separate patch for
this.
Joe.C
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
