* [PATCH 3/3] clk: sunxi-ng: sun6i-a31: Fix register offset for mipi-csi clk
From: Chen-Yu Tsai @ 2016-09-15 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915065740.13664-1-wens@csie.org>
The register offset for the mipi-csi clk is off by 4, a copy paste
error from the mipi-dsi clk.
Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index ff0d621495fd..79596463e0d9 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -633,7 +633,7 @@ static SUNXI_CCU_M_WITH_MUX_GATE(mipi_dsi_dphy_clk, "mipi-dsi-dphy",
lcd_ch1_parents, 0x168, 0, 3, 8, 2,
BIT(15), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(mipi_csi_dphy_clk, "mipi-csi-dphy",
- lcd_ch1_parents, 0x168, 0, 3, 8, 2,
+ lcd_ch1_parents, 0x16c, 0, 3, 8, 2,
BIT(15), 0);
static SUNXI_CCU_M_WITH_MUX_GATE(iep_drc0_clk, "iep-drc0", de_parents,
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] clk: sunxi-ng: sun6i-a31: set CLK_SET_RATE_UNGATE for all PLLs
From: Chen-Yu Tsai @ 2016-09-15 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915065740.13664-1-wens@csie.org>
The PLLs have a "lock" bit in their configuration registers which
indicate if the PLL has locked on to the requested clock rate. We
check this bit in the .set_rate op. The PLL cannot lock on if it's
not running, which might be a false positive (warning).
Set the CLK_SET_RATE_UNGATE flag for all PLLs so whenever clk_set_rate
is called on them, they get enabled and the "lock" check is really
checking the PLL.
Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index bb488e8baea8..ff0d621495fd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -59,7 +59,7 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
0, 5, /* M */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
"osc24M", 0x010,
@@ -71,7 +71,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
"osc24M", 0x018,
@@ -83,7 +83,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_ddr_clk, "pll-ddr",
"osc24M", 0x020,
@@ -92,7 +92,7 @@ static SUNXI_CCU_NKM_WITH_GATE_LOCK(pll_ddr_clk, "pll-ddr",
0, 2, /* M */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph_clk, "pll-periph",
"osc24M", 0x028,
@@ -101,7 +101,7 @@ static SUNXI_CCU_NK_WITH_GATE_LOCK_POSTDIV(pll_periph_clk, "pll-periph",
BIT(31), /* gate */
BIT(28), /* lock */
2, /* post-div */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video1_clk, "pll-video1",
"osc24M", 0x030,
@@ -113,7 +113,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video1_clk, "pll-video1",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_gpu_clk, "pll-gpu",
"osc24M", 0x038,
@@ -125,7 +125,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_gpu_clk, "pll-gpu",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
/*
* The MIPI PLL has 2 modes: "MIPI" and "HDMI".
@@ -145,7 +145,7 @@ static SUNXI_CCU_NKM_WITH_MUX_GATE_LOCK(pll_mipi_clk, "pll-mipi",
21, 0, /* mux */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll9_clk, "pll9",
"osc24M", 0x044,
@@ -157,7 +157,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll9_clk, "pll9",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll10_clk, "pll10",
"osc24M", 0x048,
@@ -169,7 +169,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll10_clk, "pll10",
297000000, /* frac rate 1 */
BIT(31), /* gate */
BIT(28), /* lock */
- 0);
+ CLK_SET_RATE_UNGATE);
static const char * const cpux_parents[] = { "osc32k", "osc24M",
"pll-cpu", "pll-cpu" };
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] clk: sunxi-ng: sun6i-a31: Set CLK_SET_RATE_PARENT for display output clocks
From: Chen-Yu Tsai @ 2016-09-15 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915065740.13664-1-wens@csie.org>
The LCD controller and HDMI controller use the LCDx-CHy and HDMI clocks
to generate their dot clocks. To be able to generate a full range of
possible clock rates, the parent PLL clock rates should also be changed.
Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index f1d61faa5bd9..bb488e8baea8 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -543,17 +543,19 @@ static const char * const lcd_ch0_parents[] = { "pll-video0", "pll-video1",
"pll-video0-2x",
"pll-video1-2x", "pll-mipi" };
static SUNXI_CCU_MUX_WITH_GATE(lcd0_ch0_clk, "lcd0-ch0", lcd_ch0_parents,
- 0x118, 24, 2, BIT(31), 0);
+ 0x118, 24, 2, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_MUX_WITH_GATE(lcd1_ch0_clk, "lcd1-ch0", lcd_ch0_parents,
- 0x11c, 24, 2, BIT(31), 0);
+ 0x11c, 24, 2, BIT(31), CLK_SET_RATE_PARENT);
static const char * const lcd_ch1_parents[] = { "pll-video0", "pll-video1",
"pll-video0-2x",
"pll-video1-2x" };
static SUNXI_CCU_M_WITH_MUX_GATE(lcd0_ch1_clk, "lcd0-ch1", lcd_ch1_parents,
- 0x12c, 0, 4, 24, 3, BIT(31), 0);
+ 0x12c, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(lcd1_ch1_clk, "lcd1-ch1", lcd_ch1_parents,
- 0x12c, 0, 4, 24, 3, BIT(31), 0);
+ 0x12c, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static const char * const csi_sclk_parents[] = { "pll-video0", "pll-video1",
"pll9", "pll10", "pll-mipi",
@@ -601,7 +603,8 @@ static SUNXI_CCU_GATE(digital_mic_clk, "digital-mic", "pll-audio",
0x148, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", lcd_ch1_parents,
- 0x150, 0, 4, 24, 2, BIT(31), 0);
+ 0x150, 0, 4, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(hdmi_ddc_clk, "hdmi-ddc", "osc24M", 0x150, BIT(31), 0);
@@ -624,10 +627,11 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(mbus1_clk, "mbus1", mbus_parents, 0x160,
CLK_IS_CRITICAL);
static SUNXI_CCU_M_WITH_MUX_GATE(mipi_dsi_clk, "mipi-dsi", lcd_ch1_parents,
- 0x168, 16, 3, 24, 2, BIT(31), 0);
+ 0x168, 16, 3, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(mipi_dsi_dphy_clk, "mipi-dsi-dphy",
lcd_ch1_parents, 0x168, 0, 3, 8, 2,
- BIT(15), 0);
+ BIT(15), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(mipi_csi_dphy_clk, "mipi-csi-dphy",
lcd_ch1_parents, 0x168, 0, 3, 8, 2,
BIT(15), 0);
@@ -956,9 +960,9 @@ static CLK_FIXED_FACTOR(pll_audio_8x_clk, "pll-audio-8x",
static CLK_FIXED_FACTOR(pll_periph_2x_clk, "pll-periph-2x",
"pll-periph", 1, 2, 0);
static CLK_FIXED_FACTOR(pll_video0_2x_clk, "pll-video0-2x",
- "pll-video0", 1, 2, 0);
+ "pll-video0", 1, 2, CLK_SET_RATE_PARENT);
static CLK_FIXED_FACTOR(pll_video1_2x_clk, "pll-video1-2x",
- "pll-video1", 1, 2, 0);
+ "pll-video1", 1, 2, CLK_SET_RATE_PARENT);
static struct clk_hw_onecell_data sun6i_a31_hw_clks = {
.hws = {
--
2.9.3
^ permalink raw reply related
* [PATCH 0/3] clk: sunxi-ng: sun6i-a31: Register offset and clk flag fixes
From: Chen-Yu Tsai @ 2016-09-15 6:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here are 3 fixes for the new sunxi-ng clk driver for sun6i-a31 recently
introduced for 4.9. The issues were noticed while working on the display
pipeline for the A31/A31s. The second patch follows what Maxime has done
for the A33 CCU driver. The third issue was noticed while doing the first
patch.
I hope we can get this into 4.9 as well, either right in -rc1, or in a
later -rc.
Thanks!
Regards
ChenYu
Chen-Yu Tsai (3):
clk: sunxi-ng: sun6i-a31: Set CLK_SET_RATE_PARENT for display output
clocks
clk: sunxi-ng: sun6i-a31: set CLK_SET_RATE_UNGATE for all PLLs
clk: sunxi-ng: sun6i-a31: Fix register offset for mipi-csi clk
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 44 ++++++++++++++++++++----------------
1 file changed, 24 insertions(+), 20 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/3] misc: Add Aspeed BT IPMI host driver
From: Cédric Le Goater @ 2016-09-15 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7db5ada0-49ea-55eb-089e-d979941ceff5@gmail.com>
On 09/12/2016 10:33 PM, Corey Minyard wrote:
> On 09/12/2016 02:15 PM, Arnd Bergmann wrote:
>> On Monday, September 12, 2016 1:55:40 PM CEST Corey Minyard wrote:
>>> On 09/02/2016 08:22 AM, C?dric Le Goater wrote:
>>>> Hello,
>>>>
>>>> Adding Corey in cc: . I guess I should have done that in the first place.
>>> Yes, probably so. I've been travelling and didn't see it on the mailing
>>> lists until now.
>>>
>>> There is already a BT driver in the kernel, in drivers/char/ipmi, why
>>> won't that work?
>> The new driver is the host side (running on the BMC), the existing one
>> is the client (running on the PC).
>>
>> Arnd
>
> Ok, that's not really clear from the documentation or the Kconfig.
> In the IPMI spec the "host" side is the computer side, not the BMC
> side. Like:
>
> 11.6.1 BT Host Interface Registers
> The Host BT interface provides an independent set of registers and
> interrupts to allow the Host driver to
> communicate with the baseboard management controller without
> conflicting with the O/S ACPI driver.
>
> In light of that, this should probably be named the bt-bmc driver.
>
> I haven't reviewed this in detail, but I'm ok with putting it in
> drivers/char/ipmi. The state machine part looks reasonably
> generic. The configuration part isn't, but that could be split
> out later if necessary.
what do you mean by configuration ? I am ready to send a v2. May be
I can add a few other things.
Thanks,
C.
^ permalink raw reply
* [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family flash
From: Krzeminski, Marcin (Nokia - PL/Wroclaw) @ 2016-09-15 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+EcR20NkBzFjMJ_ArWw9ALZY-x1SqwS1nUyGYAnjsygTk8K-Q@mail.gmail.com>
Hello,
> -----Original Message-----
> From: linux-mtd [mailto:linux-mtd-bounces at lists.infradead.org] On Behalf
> Of Han Xu
> Sent: Wednesday, September 14, 2016 9:49 PM
> To: Yunhui Cui <B56489@freescale.com>
> Cc: Yunhui Cui <yunhui.cui@nxp.com>; David Woodhouse
> <dwmw2@infradead.org>; linux-kernel at vger.kernel.org; linux-
> mtd at lists.infradead.org; han.xu at freescale.com; Brian Norris
> <computersforpeace@gmail.com>; jagannadh.teki at gmail.com; linux-arm-
> kernel at lists.infradead.org; Yao Yuan <yao.yuan@nxp.com>
> Subject: Re: [PATCH v3 6/9] mtd: spi-nor: Support R/W for S25FS-S family
> flash
>
> On Thu, Aug 18, 2016 at 2:38 AM, Yunhui Cui <B56489@freescale.com>
> wrote:
> > From: Yunhui Cui <yunhui.cui@nxp.com>
> >
> > With the physical sectors combination, S25FS-S family flash requires
> > some special operations for read/write functions.
> >
> > Signed-off-by: Yunhui Cui <yunhui.cui@nxp.com>
> > ---
> > drivers/mtd/spi-nor/spi-nor.c | 56
> > +++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 56 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > b/drivers/mtd/spi-nor/spi-nor.c index d0fc165..495d0bb 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -39,6 +39,10 @@
> >
> > #define SPI_NOR_MAX_ID_LEN 6
> > #define SPI_NOR_MAX_ADDR_WIDTH 4
> > +/* Added for S25FS-S family flash */
> > +#define SPINOR_CONFIG_REG3_OFFSET 0x800004
> > +#define CR3V_4KB_ERASE_UNABLE 0x8
> > +#define SPINOR_S25FS_FAMILY_EXT_JEDEC 0x81
> >
> > struct flash_info {
> > char *name;
> > @@ -78,6 +82,7 @@ struct flash_info {
> > };
> >
> > #define JEDEC_MFR(info) ((info)->id[0])
> > +#define EXT_JEDEC(info) ((info)->id[5])
> >
> > static const struct flash_info *spi_nor_match_id(const char *name);
> >
> > @@ -899,6 +904,7 @@ static const struct flash_info spi_nor_ids[] = {
> > */
> > { "s25sl032p", INFO(0x010215, 0x4d00, 64 * 1024, 64,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "s25sl064p", INFO(0x010216, 0x4d00, 64 * 1024, 128,
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > + { "s25fs256s1", INFO6(0x010219, 0x4d0181, 64 * 1024, 512, 0)},
> > { "s25fl256s0", INFO(0x010219, 0x4d00, 256 * 1024, 128, 0) },
> > { "s25fl256s1", INFO(0x010219, 0x4d01, 64 * 1024, 512,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { "s25fl512s", INFO(0x010220, 0x4d00, 256 * 1024, 256,
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, @@ -1036,6 +1042,50
> @@ static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
> > return ERR_PTR(-ENODEV);
> > }
> >
> > +/*
> > + * The S25FS-S family physical sectors may be configured as a
> > + * hybrid combination of eight 4-kB parameter sectors
> > + * at the top or bottom of the address space with all
> > + * but one of the remaining sectors being uniform size.
> > + * The Parameter Sector Erase commands (20h or 21h) must
> > + * be used to erase the 4-kB parameter sectors individually.
> > + * The Sector (uniform sector) Erase commands (D8h or DCh)
> > + * must be used to erase any of the remaining
> > + * sectors, including the portion of highest or lowest address
> > + * sector that is not overlaid by the parameter sectors.
> > + * The uniform sector erase command has no effect on parameter
> sectors.
> > + */
> > +static int spansion_s25fs_disable_4kb_erase(struct spi_nor *nor) {
> > + u32 cr3v_addr = SPINOR_CONFIG_REG3_OFFSET;
> > + u8 cr3v = 0x0;
> > + int ret = 0x0;
> > +
> > + nor->cmd_buf[2] = cr3v_addr >> 16;
> > + nor->cmd_buf[1] = cr3v_addr >> 8;
> > + nor->cmd_buf[0] = cr3v_addr >> 0;
> > +
> > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
> > + if (ret)
> > + return ret;
> > + if (cr3v & CR3V_4KB_ERASE_UNABLE)
> > + return 0;
> > + ret = nor->write_reg(nor, SPINOR_OP_WREN, NULL, 0);
> > + if (ret)
> > + return ret;
> > + cr3v = CR3V_4KB_ERASE_UNABLE;
> > + nor->program_opcode = SPINOR_OP_SPANSION_WRAR;
> > + nor->write(nor, cr3v_addr, 1, &cr3v);
> > +
> > + ret = nor->read_reg(nor, SPINOR_OP_SPANSION_RDAR, &cr3v, 1);
> > + if (ret)
> > + return ret;
> > + if (!(cr3v & CR3V_4KB_ERASE_UNABLE))
> > + return -EPERM;
> > +
> > + return 0;
> > +}
> > +
> > static int spi_nor_read(struct mtd_info *mtd, loff_t from, size_t len,
> > size_t *retlen, u_char *buf) { @@ -1361,6
> > +1411,12 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
> enum read_mode mode)
> > spi_nor_wait_till_ready(nor);
> > }
> >
> > + if (EXT_JEDEC(info) == SPINOR_S25FS_FAMILY_EXT_JEDEC) {
> > + ret = spansion_s25fs_disable_4kb_erase(nor);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > if (!mtd->name)
> > mtd->name = dev_name(dev);
> > mtd->priv = nor;
> > --
> > 2.1.0.27.g96db324
> >
> >
> Hi Brian, I will ack this change but still feel it's kind of hacking code.
>
> Acked-by: Han xu <han.xu@nxp.com>
I am new on the list so I am not sure if this topic has been discussed.
Generally our product functionality relay on those 4KiB sectors.
I know that this hack is already in u-boot, but if you mainstream this
you will force users of those 4KiB sectors to do hack the hack...
I believe the proper solution here is to use erase regions functionality,
I send and RFS about that some time ago.
Thanks,
Marcin
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>
>
> --
> Sincerely,
>
> Han XU
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* [PATCH] cpufreq: ti: Use generic platdev driver
From: Viresh Kumar @ 2016-09-15 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914204137.20346-1-d-gerlach@ti.com>
On 14-09-16, 15:41, Dave Gerlach wrote:
> Now that the cpufreq-dt-platdev is used to create the cpufreq-dt platform
> device for all OMAP platforms and the platform code that did it
> before has been removed, add ti,am33xx and ti,dra7xx to the machine list
> in cpufreq-dt-platdev which had relied on the removed platform code to do
> this previously.
>
> Fixes: 7694ca6e1d6f ("cpufreq: omap: Use generic platdev driver")
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Any stable trees you want this to be added to ?
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 0bb44d5b5df4..d5e8ba50f8a3 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -68,6 +68,8 @@ static const struct of_device_id machines[] __initconst = {
>
> { .compatible = "sigma,tango4" },
>
> + { .compatible = "ti,am33xx", },
> + { .compatible = "ti,dra7", },
> { .compatible = "ti,omap2", },
> { .compatible = "ti,omap3", },
> { .compatible = "ti,omap4", },
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH 2/2 v5] dmaengine: mv_xor: Add support for IO (PCIe) src/dst areas
From: Stefan Roese @ 2016-09-15 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915053731.25263-1-sr@denx.de>
To enable the access to a specific area, the MVEBU XOR controllers needs
to have this area enabled / mapped via an address window. Right now,
only the DRAM memory area is enabled via such memory windows. So
using this driver to DMA to / from a e.g. PCIe memory region is
currently not supported.
This patch now adds support for such PCIe / IO regions by checking
if the src / dst address is located in an IO memory area in contrast
to being located in DRAM. This is done by using the newly introduced
MBus function mvebu_mbus_get_io_win_info(). If the src / dst address
is located in such an IO area, a new address window is created in
the XOR DMA controller. Enabling the controller to access this area.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vinod Koul <vinod.koul@intel.com>
---
v4 -> v5:
- Added Andrew to Cc
v3 -> v4:
- Don't try to add the IO windows on Armada 3700 which does not implement
the MBus driver
v2 -> v3:
- Included separate patch to add a stub function for mvebu_mbus_get_io_win_info()
to this patch series
- COMPILE_TEST added again, as the stub function now allows compilation on
all platforms
v1 -> v2:
- Removed COMPILE_TEST from Kconfig entry as this results in compilation
errors on non-Marvell platforms because of references to MBus driver
functions. Since this driver will never be used on non-Marvell platforms
this should be okay.
RFC -> v1:
- Use a cache for the already mapped areas for performance reasons, as
the MMIO registers don't need to get queried any more if the area is
already mapped now
drivers/dma/mv_xor.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++-
drivers/dma/mv_xor.h | 7 ++++
2 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index f4c9f98..ff4a094 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -470,12 +470,90 @@ static int mv_xor_alloc_chan_resources(struct dma_chan *chan)
return mv_chan->slots_allocated ? : -ENOMEM;
}
+/*
+ * Check if source or destination is an PCIe/IO address (non-SDRAM) and add
+ * a new MBus window if necessary. Use a cache for these check so that
+ * the MMIO mapped registers don't have to be accessed for this check
+ * to speed up this process.
+ */
+static int mv_xor_add_io_win(struct mv_xor_chan *mv_chan, u32 addr)
+{
+ struct mv_xor_device *xordev = mv_chan->xordev;
+ void __iomem *base = mv_chan->mmr_high_base;
+ u32 win_enable;
+ u32 size;
+ u8 target, attr;
+ int ret;
+ int i;
+
+ /* Nothing needs to get done for the Armada 3700 */
+ if (xordev->xor_type == XOR_ARMADA_37XX)
+ return 0;
+
+ /*
+ * Loop over the cached windows to check, if the requested area
+ * is already mapped. If this the case, nothing needs to be done
+ * and we can return.
+ */
+ for (i = 0; i < WINDOW_COUNT; i++) {
+ if (addr >= xordev->win_start[i] &&
+ addr <= xordev->win_end[i]) {
+ /* Window is already mapped */
+ return 0;
+ }
+ }
+
+ /*
+ * The window is not mapped, so we need to create the new mapping
+ */
+
+ /* If no IO window is found that addr has to be located in SDRAM */
+ ret = mvebu_mbus_get_io_win_info(addr, &size, &target, &attr);
+ if (ret < 0)
+ return 0;
+
+ /*
+ * Mask the base addr 'addr' according to 'size' read back from the
+ * MBus window. Otherwise we might end up with an address located
+ * somewhere in the middle of this area here.
+ */
+ size -= 1;
+ addr &= ~size;
+
+ /*
+ * Reading one of both enabled register is enough, as they are always
+ * programmed to the identical values
+ */
+ win_enable = readl(base + WINDOW_BAR_ENABLE(0));
+
+ /* Set 'i' to the first free window to write the new values to */
+ i = ffs(~win_enable) - 1;
+ if (i >= WINDOW_COUNT)
+ return -ENOMEM;
+
+ writel((addr & 0xffff0000) | (attr << 8) | target,
+ base + WINDOW_BASE(i));
+ writel(size & 0xffff0000, base + WINDOW_SIZE(i));
+
+ /* Fill the caching variables for later use */
+ xordev->win_start[i] = addr;
+ xordev->win_end[i] = addr + size;
+
+ win_enable |= (1 << i);
+ win_enable |= 3 << (16 + (2 * i));
+ writel(win_enable, base + WINDOW_BAR_ENABLE(0));
+ writel(win_enable, base + WINDOW_BAR_ENABLE(1));
+
+ return 0;
+}
+
static struct dma_async_tx_descriptor *
mv_xor_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
unsigned int src_cnt, size_t len, unsigned long flags)
{
struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
struct mv_xor_desc_slot *sw_desc;
+ int ret;
if (unlikely(len < MV_XOR_MIN_BYTE_COUNT))
return NULL;
@@ -486,6 +564,11 @@ mv_xor_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
"%s src_cnt: %d len: %zu dest %pad flags: %ld\n",
__func__, src_cnt, len, &dest, flags);
+ /* Check if a new window needs to get added for 'dest' */
+ ret = mv_xor_add_io_win(mv_chan, dest);
+ if (ret)
+ return NULL;
+
sw_desc = mv_chan_alloc_slot(mv_chan);
if (sw_desc) {
sw_desc->type = DMA_XOR;
@@ -493,8 +576,13 @@ mv_xor_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
mv_desc_init(sw_desc, dest, len, flags);
if (mv_chan->op_in_desc == XOR_MODE_IN_DESC)
mv_desc_set_mode(sw_desc);
- while (src_cnt--)
+ while (src_cnt--) {
+ /* Check if a new window needs to get added for 'src' */
+ ret = mv_xor_add_io_win(mv_chan, src[src_cnt]);
+ if (ret)
+ return NULL;
mv_desc_set_src_addr(sw_desc, src_cnt, src[src_cnt]);
+ }
}
dev_dbg(mv_chan_to_devp(mv_chan),
@@ -959,6 +1047,7 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
mv_chan->op_in_desc = XOR_MODE_IN_DESC;
dma_dev = &mv_chan->dmadev;
+ mv_chan->xordev = xordev;
/*
* These source and destination dummy buffers are used to implement
@@ -1086,6 +1175,10 @@ mv_xor_conf_mbus_windows(struct mv_xor_device *xordev,
dram->mbus_dram_target_id, base + WINDOW_BASE(i));
writel((cs->size - 1) & 0xffff0000, base + WINDOW_SIZE(i));
+ /* Fill the caching variables for later use */
+ xordev->win_start[i] = cs->base;
+ xordev->win_end[i] = cs->base + cs->size - 1;
+
win_enable |= (1 << i);
win_enable |= 3 << (16 + (2 * i));
}
diff --git a/drivers/dma/mv_xor.h b/drivers/dma/mv_xor.h
index bf56e08..88eeab2 100644
--- a/drivers/dma/mv_xor.h
+++ b/drivers/dma/mv_xor.h
@@ -80,12 +80,17 @@
#define WINDOW_BAR_ENABLE(chan) (0x40 + ((chan) << 2))
#define WINDOW_OVERRIDE_CTRL(chan) (0xA0 + ((chan) << 2))
+#define WINDOW_COUNT 8
+
struct mv_xor_device {
void __iomem *xor_base;
void __iomem *xor_high_base;
struct clk *clk;
struct mv_xor_chan *channels[MV_XOR_MAX_CHANNELS];
int xor_type;
+
+ u32 win_start[WINDOW_COUNT];
+ u32 win_end[WINDOW_COUNT];
};
/**
@@ -127,6 +132,8 @@ struct mv_xor_chan {
char dummy_dst[MV_XOR_MIN_BYTE_COUNT];
dma_addr_t dummy_src_addr, dummy_dst_addr;
u32 saved_config_reg, saved_int_mask_reg;
+
+ struct mv_xor_device *xordev;
};
/**
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2 v3] bus: mvebu-mbus: Provide stub function for mvebu_mbus_get_io_win_info()
From: Stefan Roese @ 2016-09-15 5:37 UTC (permalink / raw)
To: linux-arm-kernel
This patch provides a stub function for mvebu_mbus_get_io_win_info(),
which will be used for all non-Orion (ARM32 MVEBU) platforms for
compile test coverage.
On such platforms this function will return an error so that drivers
might detect a potential problem.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Marcin Wojtas <mw@semihalf.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vinod Koul <vinod.koul@intel.com>
---
v3:
- Include errno.h to fix the compile breakage on ARM64
- Change comment as suggested by Andrew
- Added Andrew to Cc
v2:
- Return error code in stub function. This may be useful on Armada 3700
boards. As Armada 3700 does not implement the MBus driver but some
device driver might call into these functions anyways (e.g. mvneta).
include/linux/mbus.h | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index d610232..2931aa4 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -11,6 +11,8 @@
#ifndef __LINUX_MBUS_H
#define __LINUX_MBUS_H
+#include <linux/errno.h>
+
struct resource;
struct mbus_dram_target_info
@@ -55,6 +57,8 @@ struct mbus_dram_target_info
#ifdef CONFIG_PLAT_ORION
extern const struct mbus_dram_target_info *mv_mbus_dram_info(void);
extern const struct mbus_dram_target_info *mv_mbus_dram_info_nooverlap(void);
+int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target,
+ u8 *attr);
#else
static inline const struct mbus_dram_target_info *mv_mbus_dram_info(void)
{
@@ -64,14 +68,24 @@ static inline const struct mbus_dram_target_info *mv_mbus_dram_info_nooverlap(vo
{
return NULL;
}
+static inline int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size,
+ u8 *target, u8 *attr)
+{
+ /*
+ * On all ARM32 MVEBU platforms with MBus support, this stub
+ * function will not get called. The real function from the
+ * MBus driver is called instead. ARM64 MVEBU platforms like
+ * the Armada 3700 could use the mv_xor device driver which calls
+ * into this function
+ */
+ return -EINVAL;
+}
#endif
int mvebu_mbus_save_cpu_target(u32 __iomem *store_addr);
void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr);
-int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target,
- u8 *attr);
int mvebu_mbus_add_window_remap_by_id(unsigned int target,
unsigned int attribute,
phys_addr_t base, size_t size,
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2 v3] bus: mvebu-mbus: Provide stub function for mvebu_mbus_get_io_win_info()
From: Stefan Roese @ 2016-09-15 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914134559.GM13920@localhost>
Hi Vinod,
On 14.09.2016 15:45, Vinod Koul wrote:
> On Wed, Sep 14, 2016 at 03:06:07PM +0200, Gregory CLEMENT wrote:
>> Hi,
>>
>> On lun., sept. 05 2016, Stefan Roese <sr@denx.de> wrote:
>>
>>> This patch provides a stub function for mvebu_mbus_get_io_win_info(),
>>> which will be used for all non-Orion (ARM32 MVEBU) platforms for
>>> compile test coverage.
>>>
>>> On such platforms this function will return an error so that drivers
>>> might detect a potential problem.
>>
>> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>>
>> Vinod, if you happy with the second patch of the series you can apply
>> both patches on your tree. It will allow to keep the bisactibility, and
>> as I didn't have any commit modifying these file in my trees it won't
>> generate merge conflict.
>
> Okay, somehow I dont see this in my queue. Can you guys pls resend.
Sure. I'll resend it in a minute...
Thanks,
Stefan
^ permalink raw reply
* [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy
From: Peter Chen @ 2016-09-15 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147387497029.16543.5921198225528254345@sboyd-linaro>
On Wed, Sep 14, 2016 at 10:42:50AM -0700, Stephen Boyd wrote:
> > >
> > > Hmm.. maybe the confusion is in which registers we should be able to
> > > access? Are we talking about the ULPI viewport MMIO register space or
> > > the ULPI registers that we access through the viewport? I have a
> > > hw_phymode_configure() inside of of ci_ulpi_init() so that the
> > > identification registers through the ULPI viewport read properly
> > > (assuming there aren't other power requirements like regulators). If we
> > > don't set the portsc.pts before using the viewport, the viewport doesn't
> > > work and reads timeout. So we really don't touch the ULPI registers
> > > except for the scratch space and the id registers until after the phy is
> > > properly powered on with clks and regulators, because the only place we
> > > touch them after doing the id checking is in this phy driver in
> > > qcom_usb_hs_phy_power_on(). We've "solved" the chicken-egg problem where
> > > we don't know which device driver to probe because the phy needs to be
> > > powered on to read the id registers to know which device driver to use
> > > by using DT to match up device drivers instead.
> > >
> > > [1] https://www.sparkfun.com/datasheets/Components/SMD/ULPI_v1_1.pdf
> >
> > Ok, ulpi phy works like USB device on USB bus which create device at
> > runtime. So, like some hard-wired USB devices, it may needs power
> > sequence too, otherwise, how it knows which driver can loads.
> >
>
> Yes. We use the DT compatible string to ignore any issues with reading
> the device ids when the device is powered off. Unlike USB though, we
> have device drivers for the ULPI PHYs that do the power sequencing along
> with other initializations, so using a common pwrseq layer seems like
> overkill just so we can read the id registers.
If the attempt to read id registers will not hang the system, it can
work. Like the case [1], without PHY ref_clk, it will hang when
configure PHY mode (visit portsc.pts), it has no chance to read id
registers. So, I still think the ULPI bus driver needs to do power
sequence for its children, unless you have some place to open the
ref_clk.
>
> Are there any concerns with this patch? Or can they be reapplied?
For this patch, it is ok for me.
[1] http://www.spinics.net/lists/linux-usb/msg146336.html
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH 1/6] PCI: xilinx: Keep both legacy and MSI interrupt references.
From: Bharat Kumar Gogada @ 2016-09-15 5:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914191704.GA9208@localhost>
On Wed, Sep 14, 2016 at 03:32:44PM +0000, Bharat Kumar Gogada wrote:
> On Thu, Sep 01, 2016 at 03:44:41PM +0530, Bharat Kumar Gogada wrote:
> > When built with MSI support the legacy domain reference is being
> > overwritten with MSI.
> > Instead creating two separate domains for MSI and legacy interrupts.
> >
> > Signed-off-by: Bharat Kumar Gogada <bharatku@xilinx.com>
>
> Applied all these (except [5/6]) with Michal's ack to pci/host-xilinx for v4.9, thanks!
>
> I already applied Po Liu's patch ("PCI: xilinx: Relax device number checking to allow SR-IOV") to pci/virtualization. This is identical to [5/6], so I dropped [5/6] to avoid a conflict.
>
> Thanks Bjorn.
> Some how I couldn't find Po Liu's patch, can you provide git link of patch that was applied.
Sure, here it is: https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/virtualization&id=8e7ca8ca5fd8a3242289105723c429733be8b73b
Thanks Bjorn, this patch is similar to [5/6] patch.
^ permalink raw reply
* [PATCH v4] arm64: Improve kprobes test for atomic sequence
From: Masami Hiramatsu @ 2016-09-15 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D7515C.30704@linaro.org>
On Mon, 12 Sep 2016 21:07:40 -0400
David Long <dave.long@linaro.org> wrote:
>
> After the patch the function reads as follows:
>
> > enum kprobe_insn __kprobes
> > arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi)
> > {
> > enum kprobe_insn decoded;
> > kprobe_opcode_t insn = le32_to_cpu(*addr);
> > kprobe_opcode_t *scan_end = NULL;
> > unsigned long size = 0, offset = 0;
> >
> > /*
> > * If there's a symbol defined in front of and near enough to
> > * the probe address assume it is the entry point to this
> > * code and use it to further limit how far back we search
> > * when determining if we're in an atomic sequence. If we could
> > * not find any symbol skip the atomic test altogether as we
> > * could otherwise end up searching irrelevant text/literals.
> > * KPROBES depends on KALLSYMS so this last case should never
> > * happen.
> > */
> > if (kallsyms_lookup_size_offset((unsigned long) addr, &size, &offset)) {
> > if (offset < (MAX_ATOMIC_CONTEXT_SIZE*sizeof(kprobe_opcode_t)))
> > scan_end = addr - (offset / sizeof(kprobe_opcode_t));
> > else
> > scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
> > }
> > decoded = arm_probe_decode_insn(insn, asi);
> >
> > if (decoded != INSN_REJECTED && scan_end)
> > if (is_probed_address_atomic(addr - 1, scan_end))
> > return INSN_REJECTED;
> >
> > return decoded;
> > }
>
> A failed kallsyms_lookup_size_offset() call means scan_end will be left
> as NULL, which in turn means arm_kprobe_decode_insn() will simply return
> the result of the arm_probe_decode_insn() call. In other words it does
> the normal analysis of the instruction to be probed, but does not do the
> atomic sequence search that normally follows that (since it doesn't
> really know how far back to search).
OK, my idea was just rejecting it when kallsyms_lookup_size_offset() is
failed, because we can not ensure that the address is in the kernel
text. But anyway, that should be tested in general code like kernel/kprobes.c.
OK, now I think it is clear to apply.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks,
>
> Thanks,
> -dl
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH -next] drm/sun4i: backend: remove redundant dev_err call in sun4i_backend_bind()
From: Wei Yongjun @ 2016-09-15 3:25 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 91a7022..fcd4e91 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -288,10 +288,8 @@ static int sun4i_backend_bind(struct device *dev, struct device *master,
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_ioremap_resource(dev, res);
- if (IS_ERR(regs)) {
- dev_err(dev, "Couldn't map the backend registers\n");
+ if (IS_ERR(regs))
return PTR_ERR(regs);
- }
backend->regs = devm_regmap_init_mmio(dev, regs,
&sun4i_backend_regmap_config);
^ permalink raw reply related
* [PATCH] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board
From: Icenowy Zheng @ 2016-09-15 2:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915021504.65483-1-icenowy@aosc.xyz>
15.09.2016, 10:15, "Icenowy Zheng" <icenowy@aosc.xyz>:
> UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo card
> on iNet D978 Rev2 board.
>
> Enable the UART1 to make it possible to use the modified hciattach by
> Realtek to drive the BT part of RTL8723BS.
>
> On the board no r_uart pins are found now (the onboard RX/TX pins are
> wired to PF2/PF4, which is muxed with mmc0), so also disabled it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Oh I forgot to add a patch version number...
It's PATCH v3.
(But it seems that I should send a v4 to split the dtsi change and dts change.)
> ---
> ?arch/arm/boot/dts/sun8i-a23-a33.dtsi | 14 ++++++++++++++
> ?arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 20 ++++++++++++++++++++
> ?2 files changed, 34 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> index 7e05e09..c340885 100644
> --- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> @@ -361,6 +361,20 @@
> ?????????????????????????????????allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> ?????????????????????????};
>
> + uart1_pins_a: uart1 at 0 {
> + allwinner,pins = "PG6", "PG7";
> + allwinner,function = "uart1";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + uart1_pins_cts_rts_a: uart1-cts-rts at 0 {
> + allwinner,pins = "PG8", "PG9";
> + allwinner,function = "uart1";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> ?????????????????????????mmc0_pins_a: mmc0 at 0 {
> ?????????????????????????????????allwinner,pins = "PF0", "PF1", "PF2",
> ??????????????????????????????????????????????????"PF3", "PF4", "PF5";
> diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> index 0f52cd9..fb46655 100644
> --- a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> +++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> @@ -49,6 +49,15 @@
> ?????????model = "INet-D978 Rev 02";
> ?????????compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
>
> + aliases {
> + serial0 = &uart1;
> + };
> +
> + chosen {
> + /* Delete debug UART as serial0 is the UART for bluetooth */
> + /delete-property/stdout-path;
> + };
> +
> ?????????leds {
> ?????????????????compatible = "gpio-leds";
> ?????????????????pinctrl-names = "default";
> @@ -86,3 +95,14 @@
> ?????????????????allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> ?????????};
> ?};
> +
> +&r_uart {
> + status = "disabled";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins_a>,
> + <&uart1_pins_cts_rts_a>;
> + status = "okay";
> +};
> --
> 2.9.3
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board
From: Icenowy Zheng @ 2016-09-15 2:15 UTC (permalink / raw)
To: linux-arm-kernel
UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo card
on iNet D978 Rev2 board.
Enable the UART1 to make it possible to use the modified hciattach by
Realtek to drive the BT part of RTL8723BS.
On the board no r_uart pins are found now (the onboard RX/TX pins are
wired to PF2/PF4, which is muxed with mmc0), so also disabled it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 14 ++++++++++++++
arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 20 ++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 7e05e09..c340885 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -361,6 +361,20 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
+ uart1_pins_a: uart1 at 0 {
+ allwinner,pins = "PG6", "PG7";
+ allwinner,function = "uart1";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
+ uart1_pins_cts_rts_a: uart1-cts-rts at 0 {
+ allwinner,pins = "PG8", "PG9";
+ allwinner,function = "uart1";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
+
mmc0_pins_a: mmc0 at 0 {
allwinner,pins = "PF0", "PF1", "PF2",
"PF3", "PF4", "PF5";
diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
index 0f52cd9..fb46655 100644
--- a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
+++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
@@ -49,6 +49,15 @@
model = "INet-D978 Rev 02";
compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
+ aliases {
+ serial0 = &uart1;
+ };
+
+ chosen {
+ /* Delete debug UART as serial0 is the UART for bluetooth */
+ /delete-property/stdout-path;
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -86,3 +95,14 @@
allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
};
};
+
+&r_uart {
+ status = "disabled";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins_a>,
+ <&uart1_pins_cts_rts_a>;
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [GIT PULL] arm64: X-Gene platforms DTS changes queued for 4.9 - part1
From: Duc Dang @ 2016-09-15 1:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6041122.z65jfDXEcc@wuerfel>
On Wed, Sep 14, 2016 at 7:59 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday, September 2, 2016 11:46:31 AM CEST Duc Dang wrote:
>> Hi Arnd, Olof,
>>
>> This is the first part of DTS changes for X-Gene platforms targeted for 4.9.
>>
>> The changes include:
>> + X-Gene Soc PMU support patch set from Tai Nguyen (v10 reviewed by
>> Mark, DT binding document acked by Rob [1] and was suggested to merge
>> via am-soc tree by Will [2])
>> + Follow up patch to enable DT entry for SoC PMU on X-Gene v2
>> + Correct PCIe legacy interrupt mode to level-active high
>> + DTS entry for X-Gene hwmon (v4 acked by Guenter, DT binding document
>> and driver is in linux-next now [3])
>>
>> Regards,
>> Duc Dang.
>
> Sorry for the long delay, I've just now started looking at the dts changes
> for arm64. The changes to arch/arm64/boot/dts look fine, but I don't
> want to mix driver changes with dts changes, as we use separate
> branches for those.
>
> Please send this again as two pull requests, one for the dts changes, and
> one for the rest (pmu driver, binding and MAINTAINERS file). Please
> also include an explanation in the tag description about why this gets
> merged through arm-soc. I see that Will suggested doing it that way,
> but I don't see what the reason is. We normally don't touch that directory.
Hi Arnd,
I am not clear about the reason either. Probably we don't have a
dedicated tree for SoC PMU?
Hi Will,
Can you please comment?
Regards,
Duc Dang.
>
> Arnd
>
>>
>> [1]: https://lkml.org/lkml/2016/7/15/563
>> [2]: https://lkml.org/lkml/2016/7/20/224
>> [3]: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=893485e74c37669aeecf0b648dbfbd8e2f0471c3
>> ------
>>
>> The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
>>
>> Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
>>
>> are available in the git repository at:
>>
>> https://github.com/AppliedMicro/xgene-next.git tags/xgene-dts-for-v4.9-part1
>>
>> for you to fetch changes up to 1c983fc9369420748192712bde2429af3e580390:
>>
>> arm64: dts: apm: Add X-Gene SoC hwmon to device tree (2016-09-02
>> 10:43:41 -0700)
>>
>> ----------------------------------------------------------------
>> X-Gene DTS changes queued for v4.9 - part 1
>>
>> This patch set includes:
>> + X-Gene v1 SoC Performance Monitoring Unit (PMU) support
>> + DTS entry to enable SoC PMU for X-Gene v2 SoC
>> + PCIe legacy interrupt polarity fix for X-Gene
>> + X-Gene SoC hwmon DTS entry
>>
>
>
^ permalink raw reply
* [clk:clk-next 19/25] drivers/clk/zte/clk-zx296718.c:554:35: warning: cast from pointer to integer of different size
From: kbuild test robot @ 2016-09-15 0:48 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
head: f5644f10dcfbab90ffd27da1d8d51ffc13e1bc84
commit: ca0233285a93222b2b0c7384b9345711b3d68b5c [19/25] clk: zx: register ZX296718 clocks
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ca0233285a93222b2b0c7384b9345711b3d68b5c
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
drivers/clk/zte/clk-zx296718.c: In function 'top_clocks_init':
>> drivers/clk/zte/clk-zx296718.c:554:35: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
zx296718_pll_clk[i].reg_base += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:579:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
top_mux_clk[i].mux.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:592:31: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
top_gate_clk[i].gate.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:605:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
top_div_clk[i].div.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c: In function 'lsp0_clocks_init':
drivers/clk/zte/clk-zx296718.c:745:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp0_mux_clk[i].mux.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:758:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp0_gate_clk[i].gate.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:771:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp0_div_clk[i].div.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c: In function 'lsp1_clocks_init':
drivers/clk/zte/clk-zx296718.c:850:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp1_mux_clk[i].mux.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:863:32: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp1_gate_clk[i].gate.reg += (u64)reg_base;
^
drivers/clk/zte/clk-zx296718.c:876:30: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
lsp1_div_clk[i].div.reg += (u64)reg_base;
^
vim +554 drivers/clk/zte/clk-zx296718.c
538 [TOP_NR_CLKS - 1] = NULL,
539 },
540 };
541
542 static int __init top_clocks_init(struct device_node *np)
543 {
544 void __iomem *reg_base;
545 int i, ret;
546
547 reg_base = of_iomap(np, 0);
548 if (!reg_base) {
549 pr_err("%s: Unable to map clk base\n", __func__);
550 return -ENXIO;
551 }
552
553 for (i = 0; i < ARRAY_SIZE(zx296718_pll_clk); i++) {
> 554 zx296718_pll_clk[i].reg_base += (u64)reg_base;
555 ret = clk_hw_register(NULL, &zx296718_pll_clk[i].hw);
556 if (ret) {
557 pr_warn("top clk %s init error!\n",
558 zx296718_pll_clk[i].hw.init->name);
559 }
560 }
561
562 for (i = 0; i < ARRAY_SIZE(top_ffactor_clk); i++) {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 58522 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160915/1d2cc8ea/attachment-0001.obj>
^ permalink raw reply
* [PATCH v2 0/5] AT91: sckc improvements
From: Stephen Boyd @ 2016-09-15 0:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908145146.20422-1-alexandre.belloni@free-electrons.com>
On 09/08, Alexandre Belloni wrote:
> Hi,
>
> This patch set improves the slow clock controller driver.
>
> The first patch simply moves some code around to avoid having extern
> functions declared.
>
> The second patch adds support for the SCKC found on sama5d4 and later.
> It is notably missing the OSC32EN bit.
> The third and fourth patches make use of this new driver (DT ABI is not
> broken \o/)
>
> Finally, there is an optimization. Trying to find wether the slow
> oscillator is already stable to avoid waiting 1.2s twice in the boot
> process.
clk patches look ok. We'll need to move this to use clk_hw
registration based APIs some time, but that isn't critical to
handle now. Will you resend?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 02/34] clk: at91: Migrate to clk_hw based registration and OF APIs
From: Stephen Boyd @ 2016-09-15 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160607184059.6c83477f@bbrezillon>
On 06/07, Boris Brezillon wrote:
> On Tue, 7 Jun 2016 18:36:21 +0200
> Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote:
>
> > On 01/06/2016 at 16:15:01 -0700, Stephen Boyd wrote :
> > > Now that we have clk_hw based provider APIs to register clks, we
> > > can get rid of struct clk pointers in this driver, allowing us to
> > > move closer to a clear split of consumer and provider clk APIs.
> > >
> > > Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> >
> > Well, apart the same comment about alignement:
> >
> > Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> > Tested-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>
> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>
Ok I fixed the alignment and pushed to clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 04/34] clk: bcm2835: Migrate to clk_hw based registration and OF APIs
From: Stephen Boyd @ 2016-09-15 0:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r3cfa1n7.fsf@eliezer.anholt.net>
On 06/02, Eric Anholt wrote:
> Stephen Boyd <stephen.boyd@linaro.org> writes:
>
> > Now that we have clk_hw based provider APIs to register clks, we
> > can get rid of struct clk pointers while registering clks in
> > these drivers, allowing us to move closer to a clear split of
> > consumer and provider clk APIs.
>
> This looks good, but it'll conflict with the fixes for 4.7. Could we
> land those first and then put this commit on top of that?
Done and merged to clk-next.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2] clk: iproc: Make clocks visible options
From: Stephen Boyd @ 2016-09-15 0:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1446151450-23563-1-git-send-email-jonmason@broadcom.com>
On 10/29, Jon Mason wrote:
> Make the clocks visible options that can be selected by anyone. This
> avoids the problems of:
> 1) Select is a reverse dependency and is hard for people to understand
> and can sometimes be a pain to track down
> 2) Build coverage goes down because configs are hidden
> 3) Code bloat
>
> Patch suggested by Stephen Boyd
>
> Signed-off-by: Jon Mason <jonmason@broadcom.com>
> ---
Applied to clk-next with some minor fixup in the Makefile. I know
this is almost a year old, but it still mostly applied.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 3/4] arm64: dts: add Allwinner A64 SoC .dtsi
From: André Przywara @ 2016-09-15 0:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909201029.24530-4-maxime.ripard@free-electrons.com>
On 09/09/16 21:10, Maxime Ripard wrote:
Hi Maxime,
> From: Andre Przywara <andre.przywara@arm.com>
>
> The Allwinner A64 SoC is a low-cost chip with 4 ARM Cortex-A53 cores
> and the typical tablet / TV box peripherals.
> The SoC is based on the (32-bit) Allwinner H3 chip, sharing most of
> the peripherals and the memory map.
> Although the cores are proper 64-bit ones, the whole SoC is actually
> limited to 4GB (including all the supported DRAM), so we use 32-bit
> address and size cells. This has the nice feature of us being able to
> reuse the DT for 32-bit kernels as well.
> This .dtsi lists the hardware that we support so far.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Rob Herring <robh@kernel.org>
> [Maxime: Convert to CCU binding, drop the MMC support for now]
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
> MAINTAINERS | 1 +
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 279 ++++++++++++++++++++++++
> 3 files changed, 281 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
> index 7e79fcc36b0d..7e59d8ba86af 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -14,3 +14,4 @@ using one of the following compatible strings:
> allwinner,sun8i-a83t
> allwinner,sun8i-h3
> allwinner,sun9i-a80
> + allwinner,sun50i-a64
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 20bb1d00098c..c8c0c85c113f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -982,6 +982,7 @@ M: Chen-Yu Tsai <wens@csie.org>
> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> N: sun[x456789]i
> +F: arch/arm64/boot/dts/allwinner/
If you promise to not break it needlessly ;-)
>
> ARM/Allwinner SoC Clock Support
> M: Emilio L?pez <emilio@elopez.com.ar>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> new file mode 100644
> index 000000000000..028cdbee20aa
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -0,0 +1,279 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
> + * based on the Allwinner H3 dtsi:
> + * Copyright (C) 2015 Jens Kuske <jenskuske@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include <dt-bindings/clock/sun50i-a64-ccu.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +#include <dt-bindings/reset/sun50i-a64-ccu.h>
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 0 {
This is probably me to blame here since I put you up to it, but you need
"cpux" names (e.g. "cpu0: cpu at 0 {") to match the ones that the PMU node
references below. dtc will refuse to compile it otherwise.
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <0>;
> + enable-method = "psci";
> + };
> +
> + cpu at 1 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + };
> +
> + cpu at 2 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + };
> +
> + cpu at 3 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + };
> + };
> +
> + osc24M: osc24M_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <24000000>;
> + clock-output-names = "osc24M";
> + };
> +
> + osc32k: osc32k_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + clock-output-names = "osc32k";
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
> + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&cpu0>,
> + <&cpu1>,
> + <&cpu2>,
> + <&cpu3>;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 14
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 11
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 10
> + (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + ccu: clock at 01c20000 {
> + compatible = "allwinner,sun50i-a64-ccu";
> + reg = <0x01c20000 0x400>;
> + clocks = <&osc24M>, <&osc32k>;
> + clock-names = "hosc", "losc";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> + pio: pinctrl at 1c20800 {
> + compatible = "allwinner,sun50i-a64-pinctrl";
> + reg = <0x01c20800 0x400>;
> + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_PIO>;
> + gpio-controller;
> + #gpio-cells = <3>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + i2c1_pins: i2c1_pins {
> + allwinner,pins = "PH2", "PH3";
> + allwinner,function = "i2c1";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
> + uart0_pins_a: uart0 at 0 {
> + allwinner,pins = "PB8", "PB9";
> + allwinner,function = "uart0";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
So did I get this right that there is a strict "no user - no pins"
policy here?
I don't see a reason why we shouldn't have at least the other UART pins
described here as well - since they are a pure SoC property. That would
make it easier for people to enable them (with a simple, scripted fdt
one-liner command in U-Boot, for instance).
I guess there will never be an official DT with more than 2 UARTs
enabled, although we have actually five UARTs on the headers on the
Pine64, for instance (and personally I am looking into using one as a
terminal server).
Also UART1 is connected to that WiFi/Bluetooth slot, having it enabled
should make BT work without further ado (but I haven't tested this).
Thoughts?
> + };
> +
> + uart0: serial at 1c28000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28000 0x400>;
> + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART0>;
> + resets = <&ccu RST_BUS_UART0>;
> + status = "disabled";
> + };
> +
> + uart1: serial at 1c28400 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28400 0x400>;
> + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART1>;
> + resets = <&ccu RST_BUS_UART1>;
> + status = "disabled";
> + };
> +
> + uart2: serial at 1c28800 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28800 0x400>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART2>;
> + resets = <&ccu RST_BUS_UART2>;
> + status = "disabled";
> + };
> +
> + uart3: serial at 1c28c00 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c28c00 0x400>;
> + interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART3>;
> + resets = <&ccu RST_BUS_UART3>;
> + status = "disabled";
> + };
> +
> + uart4: serial at 1c29000 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x01c29000 0x400>;
> + interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&ccu CLK_BUS_UART4>;
> + resets = <&ccu RST_BUS_UART4>;
> + status = "disabled";
> + };
> +
> + rtc: rtc at 1f00000 {
> + compatible = "allwinner,sun6i-a31-rtc";
> + reg = <0x01f00000 0x54>;
> + interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + i2c0: i2c at 1c2ac00 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2ac00 0x400>;
> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C0>;
> + resets = <&ccu RST_BUS_I2C0>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c1: i2c at 1c2b000 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2b000 0x400>;
> + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C1>;
> + resets = <&ccu RST_BUS_I2C1>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + i2c2: i2c at 1c2b400 {
> + compatible = "allwinner,sun6i-a31-i2c";
> + reg = <0x01c2b400 0x400>;
> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_I2C2>;
> + resets = <&ccu RST_BUS_I2C2>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + gic: interrupt-controller at 1c81000 {
> + compatible = "arm,gic-400";
> + reg = <0x01c81000 0x1000>,
> + <0x01c82000 0x2000>,
> + <0x01c84000 0x2000>,
> + <0x01c86000 0x2000>;
> + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + };
This is clearly bike-shedding at this point ;-), but I think the GIC
should belong up into the core peripherals, not under the "soc" node.
> + };
> +};
>
Cheers,
Andre.
^ permalink raw reply
* next-20160914 build: 2 failures 3 warnings (next-20160914)
From: Michael Ellerman @ 2016-09-14 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914171137.GF27974@sirena.org.uk>
Mark Brown <broonie@kernel.org> writes:
> [ Unknown signature status ]
> On Wed, Sep 14, 2016 at 09:18:08AM +0100, Build bot for Mark Brown wrote:
>
> Today's -next fails to build both arm and arm64 allmodconfig due to:
>
>> arm64-allmodconfig
>> ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
>>
>> arm-allmodconfig
>> ERROR: "irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
>
> due to 262d5cc6ceb293 (mfd: tps65217: Add support for IRQs) since
> irq_set_parent() isn't exported.
And powerpc too.
cheers
^ permalink raw reply
* [PATCH 0/3] ARM: dts: am33xx/dra7xx: Fix cpufreq regression
From: Tony Lindgren @ 2016-09-14 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914205717.21975-1-d-gerlach@ti.com>
* Dave Gerlach <d-gerlach@ti.com> [160914 13:57]:
> Hi,
> CPUFreq on am335x and dra7 platforms got broken by two things:
> - Updated OPPv2 nodes in device tree were merged before driver to
> handle them was accepted.
> - OMAP platforms now use the new cpufreq-dt-platdev driver to create
> cpufreq-dt platform device but non OMAP TI devices were not changed
> over to this driver.
>
> This series addresses the first issue listed above by reverting three of
> the dts patches that got merged to restore OPPv1 tables. The second issue
> is addressed by [1].
>
> With both this series and that patch we will have the existing cpufreq
> support restored on am335x and dra7xx.
OK thanks I've applied these into am335x-cpufreq-regression branch
and merging that into omap-for-v4.9/dt-v2 branch as well. Seems
like no huge rush to get these into v4.8-rc series as nobody has
noticed since May. And we can request these for stable inclusion
after they hit mainline. If there is need to have these in v4.8-rc,
let me know and I'll send a pull request for am335x-cpufreq-regression
separately.
Regards,
Tony
> [1] http://marc.info/?l=linux-pm&m=147388573513082&w=2
>
> Dave Gerlach (3):
> Revert "ARM: dts: am335x-boneblack: Enable 1GHz OPP for cpu"
> Revert "ARM: dts: am33xx: Move to operating-points-v2 table and
> ti-cpufreq driver"
> Revert "ARM: dts: dra7: Move to operating-points-v2 table"
>
> arch/arm/boot/dts/am335x-boneblack.dts | 11 -----
> arch/arm/boot/dts/am33xx.dtsi | 88 +++++-----------------------------
> arch/arm/boot/dts/dra7.dtsi | 26 ++--------
> arch/arm/boot/dts/dra74x.dtsi | 1 -
> 4 files changed, 18 insertions(+), 108 deletions(-)
>
> --
> 2.9.3
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox