* [PATCH 5/5] arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
From: Chen-Yu Tsai @ 2017-12-18 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-6-embed3d@gmail.com>
On Mon, Dec 18, 2017 at 6:45 AM, Philipp Rossak <embed3d@gmail.com> wrote:
> The Bananapi M3 has an onboard IR receiver.
> This enables the onboard IR receiver subnode.
> Other than the other IR receivers this one needs a base clock frequency
Unlike the other...
> of 3000000 Hz (3 MHz), to be able to work.
>
> Signed-off-by: Philipp Rossak <embed3d@gmail.com>
> ---
> arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> index 6550bf0e594b..2bf25ca64133 100644
> --- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> +++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> @@ -100,6 +100,13 @@
> status = "okay";
> };
>
> +&ir {
See my other reply about the name.
Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
> + pinctrl-names = "default";
> + pinctrl-0 = <&ir_pins_a>;
> + clock-frequency = <3000000>;
> + status = "okay";
> +};
> +
> &mdio {
> rgmii_phy: ethernet-phy at 1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH 3/5] arm: dts: sun8i: a83t: Add the ir pin for the A83T
From: Chen-Yu Tsai @ 2017-12-18 3:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-4-embed3d@gmail.com>
On Mon, Dec 18, 2017 at 6:45 AM, Philipp Rossak <embed3d@gmail.com> wrote:
> The CIR Pin of the A83T is located at PL12.
>
> Signed-off-by: Philipp Rossak <embed3d@gmail.com>
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index a384b766f3dc..954c2393325f 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -521,6 +521,11 @@
> drive-strength = <20>;
> bias-pull-up;
> };
> +
> + ir_pins_a: ir at 0 {
ir_pins: ir-pins
And it really should be cir, to distinguish it from IrDA.
ChenYu
> + pins = "PL12";
> + function = "s_cir_rx";
> + };
> };
>
> r_rsb: rsb at 1f03400 {
> --
> 2.11.0
>
^ permalink raw reply
* [v2] arm: dts: ls1021a: fix the value of TMR_FIPER1
From: Y.b. Lu @ 2017-12-18 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130002905.GA22908@dragon>
Hi Shawn,
Sorry for bother. I just couldn?t find this patch on your git tree.
Could you help to check?
Thanks a lot.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: 2017?11?30? 8:29
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: devicetree at vger.kernel.org; linux-kernel at vger.kernel.org;
> linux-arm-kernel at lists.infradead.org; Mark Rutland <mark.rutland@arm.com>;
> Rob Herring <robh+dt@kernel.org>; Russell King <linux@armlinux.org.uk>
> Subject: Re: [v2] arm: dts: ls1021a: fix the value of TMR_FIPER1
>
> On Wed, Nov 29, 2017 at 02:54:58PM +0800, Yangbo Lu wrote:
> > The timer fixed interval period pulse generator register is used to
> > generate periodic pulses. The down count register loads the value
> > programmed in the fixed period interval (FIPER). At every tick of the
> > timer accumulator overflow, the counter decrements by the value of
> > TMR_CTRL[TCLK_PERIOD]. It generates a pulse when the down counter
> > value reaches zero. It reloads the down counter in the cycle following
> > a pulse. To use the TMR_FIPER1 register to generate a 1 PPS event, the
> > value
> > (10^9 nanoseconds) - TCLK_PERIOD should be programmed.
> > It should be 999999995 not 999999990 since TCLK_PERIOD is 5.
> >
> > Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
>
>
> Again, for arm dts, we usually use prefix like 'ARM: dts: ...'
>
> I fixed it up and applied the patch.
>
> Shawn
>
> > ---
> > Changes for v2:
> > - Added Shawn into cc list.
> > ---
> > arch/arm/boot/dts/ls1021a.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/ls1021a.dtsi
> > b/arch/arm/boot/dts/ls1021a.dtsi index 64249726b3cb..a861a4b9e319
> > 100644
> > --- a/arch/arm/boot/dts/ls1021a.dtsi
> > +++ b/arch/arm/boot/dts/ls1021a.dtsi
> > @@ -589,7 +589,7 @@
> > fsl,tclk-period = <5>;
> > fsl,tmr-prsc = <2>;
> > fsl,tmr-add = <0xaaaaaaab>;
> > - fsl,tmr-fiper1 = <999999990>;
> > + fsl,tmr-fiper1 = <999999995>;
> > fsl,tmr-fiper2 = <99990>;
> > fsl,max-adj = <499999999>;
> > };
> > --
> > 2.14.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> >
> s.infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&data=02%7C01%
> 7
> >
> Cyangbo.lu%40nxp.com%7C703a7f8c490745cac3d708d537896a63%7C686ea
> 1d3bc2b
> >
> 4c6fa92cd99c5c301635%7C0%7C0%7C636475985694945094&sdata=XLw6lJ
> ONCoo2jq
> > Hoixb%2BtlYTDcLC4tPbKWT3eQ7RI7c%3D&reserved=0
^ permalink raw reply
* [PATCH 1/5] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Andi Shyti @ 2017-12-18 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-2-embed3d@gmail.com>
Hi Philipp,
just a couple of small nitpicks.
> + u32 b_clk_freq;
[...]
> + /* Base clock frequency (optional) */
> + if (of_property_read_u32(dn, "clock-frequency", &b_clk_freq)) {
> + b_clk_freq = SUNXI_IR_BASE_CLK;
> + }
> +
how about you intialize 'b_clk_freq' to 'SUNXI_IR_BASE_CLK' and
just call 'of_property_read_u32' without if statement.
'b_clk_freq' value should not be changed if "clock-frequency"
is not present in the DTS.
This might avoid misinterpretation from static analyzers that
might think that 'b_clk_freq' is used uninitialized.
> + dev_info(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
Please use dev_dbg().
Andi
^ permalink raw reply
* [PATCH] mtd: mtk-nor: modify functions' name more generally
From: Guochun Mao @ 2017-12-18 1:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513561655-10570-1-git-send-email-guochun.mao@mediatek.com>
Since more and more Mediatek's SoC can use this driver to
control spi-nor flash, functions' name with "mt8173_" is
no longer properly. Replacing "mt8173_" with "mtk_" will
be more accurate to describe these functions' usable scope.
Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
---
drivers/mtd/spi-nor/mtk-quadspi.c | 240 ++++++++++++++++++-------------------
1 file changed, 120 insertions(+), 120 deletions(-)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
index abe455c..5442993 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -110,7 +110,7 @@
#define MTK_NOR_PRG_REG(n) (MTK_NOR_PRGDATA0_REG + 4 * (n))
#define MTK_NOR_SHREG(n) (MTK_NOR_SHREG0_REG + 4 * (n))
-struct mt8173_nor {
+struct mtk_nor {
struct spi_nor nor;
struct device *dev;
void __iomem *base; /* nor flash base address */
@@ -118,48 +118,48 @@ struct mt8173_nor {
struct clk *nor_clk;
};
-static void mt8173_nor_set_read_mode(struct mt8173_nor *mt8173_nor)
+static void mtk_nor_set_read_mode(struct mtk_nor *mtk_nor)
{
- struct spi_nor *nor = &mt8173_nor->nor;
+ struct spi_nor *nor = &mtk_nor->nor;
switch (nor->read_proto) {
case SNOR_PROTO_1_1_1:
- writeb(nor->read_opcode, mt8173_nor->base +
+ writeb(nor->read_opcode, mtk_nor->base +
MTK_NOR_PRGDATA3_REG);
- writeb(MTK_NOR_FAST_READ, mt8173_nor->base +
+ writeb(MTK_NOR_FAST_READ, mtk_nor->base +
MTK_NOR_CFG1_REG);
break;
case SNOR_PROTO_1_1_2:
- writeb(nor->read_opcode, mt8173_nor->base +
+ writeb(nor->read_opcode, mtk_nor->base +
MTK_NOR_PRGDATA3_REG);
- writeb(MTK_NOR_DUAL_READ_EN, mt8173_nor->base +
+ writeb(MTK_NOR_DUAL_READ_EN, mtk_nor->base +
MTK_NOR_DUAL_REG);
break;
case SNOR_PROTO_1_1_4:
- writeb(nor->read_opcode, mt8173_nor->base +
+ writeb(nor->read_opcode, mtk_nor->base +
MTK_NOR_PRGDATA4_REG);
- writeb(MTK_NOR_QUAD_READ_EN, mt8173_nor->base +
+ writeb(MTK_NOR_QUAD_READ_EN, mtk_nor->base +
MTK_NOR_DUAL_REG);
break;
default:
- writeb(MTK_NOR_DUAL_DISABLE, mt8173_nor->base +
+ writeb(MTK_NOR_DUAL_DISABLE, mtk_nor->base +
MTK_NOR_DUAL_REG);
break;
}
}
-static int mt8173_nor_execute_cmd(struct mt8173_nor *mt8173_nor, u8 cmdval)
+static int mtk_nor_execute_cmd(struct mtk_nor *mtk_nor, u8 cmdval)
{
int reg;
u8 val = cmdval & 0x1f;
- writeb(cmdval, mt8173_nor->base + MTK_NOR_CMD_REG);
- return readl_poll_timeout(mt8173_nor->base + MTK_NOR_CMD_REG, reg,
+ writeb(cmdval, mtk_nor->base + MTK_NOR_CMD_REG);
+ return readl_poll_timeout(mtk_nor->base + MTK_NOR_CMD_REG, reg,
!(reg & val), 100, 10000);
}
-static int mt8173_nor_do_tx_rx(struct mt8173_nor *mt8173_nor, u8 op,
- u8 *tx, int txlen, u8 *rx, int rxlen)
+static int mtk_nor_do_tx_rx(struct mtk_nor *mtk_nor, u8 op,
+ u8 *tx, int txlen, u8 *rx, int rxlen)
{
int len = 1 + txlen + rxlen;
int i, ret, idx;
@@ -167,26 +167,26 @@ static int mt8173_nor_do_tx_rx(struct mt8173_nor *mt8173_nor, u8 op,
if (len > MTK_NOR_MAX_SHIFT)
return -EINVAL;
- writeb(len * 8, mt8173_nor->base + MTK_NOR_CNT_REG);
+ writeb(len * 8, mtk_nor->base + MTK_NOR_CNT_REG);
/* start at PRGDATA5, go down to PRGDATA0 */
idx = MTK_NOR_MAX_RX_TX_SHIFT - 1;
/* opcode */
- writeb(op, mt8173_nor->base + MTK_NOR_PRG_REG(idx));
+ writeb(op, mtk_nor->base + MTK_NOR_PRG_REG(idx));
idx--;
/* program TX data */
for (i = 0; i < txlen; i++, idx--)
- writeb(tx[i], mt8173_nor->base + MTK_NOR_PRG_REG(idx));
+ writeb(tx[i], mtk_nor->base + MTK_NOR_PRG_REG(idx));
/* clear out rest of TX registers */
while (idx >= 0) {
- writeb(0, mt8173_nor->base + MTK_NOR_PRG_REG(idx));
+ writeb(0, mtk_nor->base + MTK_NOR_PRG_REG(idx));
idx--;
}
- ret = mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_PRG_CMD);
+ ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PRG_CMD);
if (ret)
return ret;
@@ -195,20 +195,20 @@ static int mt8173_nor_do_tx_rx(struct mt8173_nor *mt8173_nor, u8 op,
/* read out RX data */
for (i = 0; i < rxlen; i++, idx--)
- rx[i] = readb(mt8173_nor->base + MTK_NOR_SHREG(idx));
+ rx[i] = readb(mtk_nor->base + MTK_NOR_SHREG(idx));
return 0;
}
/* Do a WRSR (Write Status Register) command */
-static int mt8173_nor_wr_sr(struct mt8173_nor *mt8173_nor, u8 sr)
+static int mtk_nor_wr_sr(struct mtk_nor *mtk_nor, u8 sr)
{
- writeb(sr, mt8173_nor->base + MTK_NOR_PRGDATA5_REG);
- writeb(8, mt8173_nor->base + MTK_NOR_CNT_REG);
- return mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_WRSR_CMD);
+ writeb(sr, mtk_nor->base + MTK_NOR_PRGDATA5_REG);
+ writeb(8, mtk_nor->base + MTK_NOR_CNT_REG);
+ return mtk_nor_execute_cmd(mtk_nor, MTK_NOR_WRSR_CMD);
}
-static int mt8173_nor_write_buffer_enable(struct mt8173_nor *mt8173_nor)
+static int mtk_nor_write_buffer_enable(struct mtk_nor *mtk_nor)
{
u8 reg;
@@ -216,27 +216,27 @@ static int mt8173_nor_write_buffer_enable(struct mt8173_nor *mt8173_nor)
* 0: pre-fetch buffer use for read
* 1: pre-fetch buffer use for page program
*/
- writel(MTK_NOR_WR_BUF_ENABLE, mt8173_nor->base + MTK_NOR_CFG2_REG);
- return readb_poll_timeout(mt8173_nor->base + MTK_NOR_CFG2_REG, reg,
+ writel(MTK_NOR_WR_BUF_ENABLE, mtk_nor->base + MTK_NOR_CFG2_REG);
+ return readb_poll_timeout(mtk_nor->base + MTK_NOR_CFG2_REG, reg,
0x01 == (reg & 0x01), 100, 10000);
}
-static int mt8173_nor_write_buffer_disable(struct mt8173_nor *mt8173_nor)
+static int mtk_nor_write_buffer_disable(struct mtk_nor *mtk_nor)
{
u8 reg;
- writel(MTK_NOR_WR_BUF_DISABLE, mt8173_nor->base + MTK_NOR_CFG2_REG);
- return readb_poll_timeout(mt8173_nor->base + MTK_NOR_CFG2_REG, reg,
+ writel(MTK_NOR_WR_BUF_DISABLE, mtk_nor->base + MTK_NOR_CFG2_REG);
+ return readb_poll_timeout(mtk_nor->base + MTK_NOR_CFG2_REG, reg,
MTK_NOR_WR_BUF_DISABLE == (reg & 0x1), 100,
10000);
}
-static void mt8173_nor_set_addr_width(struct mt8173_nor *mt8173_nor)
+static void mtk_nor_set_addr_width(struct mtk_nor *mtk_nor)
{
u8 val;
- struct spi_nor *nor = &mt8173_nor->nor;
+ struct spi_nor *nor = &mtk_nor->nor;
- val = readb(mt8173_nor->base + MTK_NOR_DUAL_REG);
+ val = readb(mtk_nor->base + MTK_NOR_DUAL_REG);
switch (nor->addr_width) {
case 3:
@@ -246,115 +246,115 @@ static void mt8173_nor_set_addr_width(struct mt8173_nor *mt8173_nor)
val |= MTK_NOR_4B_ADDR_EN;
break;
default:
- dev_warn(mt8173_nor->dev, "Unexpected address width %u.\n",
+ dev_warn(mtk_nor->dev, "Unexpected address width %u.\n",
nor->addr_width);
break;
}
- writeb(val, mt8173_nor->base + MTK_NOR_DUAL_REG);
+ writeb(val, mtk_nor->base + MTK_NOR_DUAL_REG);
}
-static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr)
+static void mtk_nor_set_addr(struct mtk_nor *mtk_nor, u32 addr)
{
int i;
- mt8173_nor_set_addr_width(mt8173_nor);
+ mtk_nor_set_addr_width(mtk_nor);
for (i = 0; i < 3; i++) {
- writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG + i * 4);
+ writeb(addr & 0xff, mtk_nor->base + MTK_NOR_RADR0_REG + i * 4);
addr >>= 8;
}
/* Last register is non-contiguous */
- writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR3_REG);
+ writeb(addr & 0xff, mtk_nor->base + MTK_NOR_RADR3_REG);
}
-static ssize_t mt8173_nor_read(struct spi_nor *nor, loff_t from, size_t length,
- u_char *buffer)
+static ssize_t mtk_nor_read(struct spi_nor *nor, loff_t from, size_t length,
+ u_char *buffer)
{
int i, ret;
int addr = (int)from;
u8 *buf = (u8 *)buffer;
- struct mt8173_nor *mt8173_nor = nor->priv;
+ struct mtk_nor *mtk_nor = nor->priv;
/* set mode for fast read mode ,dual mode or quad mode */
- mt8173_nor_set_read_mode(mt8173_nor);
- mt8173_nor_set_addr(mt8173_nor, addr);
+ mtk_nor_set_read_mode(mtk_nor);
+ mtk_nor_set_addr(mtk_nor, addr);
for (i = 0; i < length; i++) {
- ret = mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_PIO_READ_CMD);
+ ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PIO_READ_CMD);
if (ret < 0)
return ret;
- buf[i] = readb(mt8173_nor->base + MTK_NOR_RDATA_REG);
+ buf[i] = readb(mtk_nor->base + MTK_NOR_RDATA_REG);
}
return length;
}
-static int mt8173_nor_write_single_byte(struct mt8173_nor *mt8173_nor,
- int addr, int length, u8 *data)
+static int mtk_nor_write_single_byte(struct mtk_nor *mtk_nor,
+ int addr, int length, u8 *data)
{
int i, ret;
- mt8173_nor_set_addr(mt8173_nor, addr);
+ mtk_nor_set_addr(mtk_nor, addr);
for (i = 0; i < length; i++) {
- writeb(*data++, mt8173_nor->base + MTK_NOR_WDATA_REG);
- ret = mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_PIO_WR_CMD);
+ writeb(*data++, mtk_nor->base + MTK_NOR_WDATA_REG);
+ ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PIO_WR_CMD);
if (ret < 0)
return ret;
}
return 0;
}
-static int mt8173_nor_write_buffer(struct mt8173_nor *mt8173_nor, int addr,
- const u8 *buf)
+static int mtk_nor_write_buffer(struct mtk_nor *mtk_nor, int addr,
+ const u8 *buf)
{
int i, bufidx, data;
- mt8173_nor_set_addr(mt8173_nor, addr);
+ mtk_nor_set_addr(mtk_nor, addr);
bufidx = 0;
for (i = 0; i < SFLASH_WRBUF_SIZE; i += 4) {
data = buf[bufidx + 3]<<24 | buf[bufidx + 2]<<16 |
buf[bufidx + 1]<<8 | buf[bufidx];
bufidx += 4;
- writel(data, mt8173_nor->base + MTK_NOR_PP_DATA_REG);
+ writel(data, mtk_nor->base + MTK_NOR_PP_DATA_REG);
}
- return mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_WR_CMD);
+ return mtk_nor_execute_cmd(mtk_nor, MTK_NOR_WR_CMD);
}
-static ssize_t mt8173_nor_write(struct spi_nor *nor, loff_t to, size_t len,
- const u_char *buf)
+static ssize_t mtk_nor_write(struct spi_nor *nor, loff_t to, size_t len,
+ const u_char *buf)
{
int ret;
- struct mt8173_nor *mt8173_nor = nor->priv;
+ struct mtk_nor *mtk_nor = nor->priv;
size_t i;
- ret = mt8173_nor_write_buffer_enable(mt8173_nor);
+ ret = mtk_nor_write_buffer_enable(mtk_nor);
if (ret < 0) {
- dev_warn(mt8173_nor->dev, "write buffer enable failed!\n");
+ dev_warn(mtk_nor->dev, "write buffer enable failed!\n");
return ret;
}
for (i = 0; i + SFLASH_WRBUF_SIZE <= len; i += SFLASH_WRBUF_SIZE) {
- ret = mt8173_nor_write_buffer(mt8173_nor, to, buf);
+ ret = mtk_nor_write_buffer(mtk_nor, to, buf);
if (ret < 0) {
- dev_err(mt8173_nor->dev, "write buffer failed!\n");
+ dev_err(mtk_nor->dev, "write buffer failed!\n");
return ret;
}
to += SFLASH_WRBUF_SIZE;
buf += SFLASH_WRBUF_SIZE;
}
- ret = mt8173_nor_write_buffer_disable(mt8173_nor);
+ ret = mtk_nor_write_buffer_disable(mtk_nor);
if (ret < 0) {
- dev_warn(mt8173_nor->dev, "write buffer disable failed!\n");
+ dev_warn(mtk_nor->dev, "write buffer disable failed!\n");
return ret;
}
if (i < len) {
- ret = mt8173_nor_write_single_byte(mt8173_nor, to,
- (int)(len - i), (u8 *)buf);
+ ret = mtk_nor_write_single_byte(mtk_nor, to,
+ (int)(len - i), (u8 *)buf);
if (ret < 0) {
- dev_err(mt8173_nor->dev, "write single byte failed!\n");
+ dev_err(mtk_nor->dev, "write single byte failed!\n");
return ret;
}
}
@@ -362,72 +362,72 @@ static ssize_t mt8173_nor_write(struct spi_nor *nor, loff_t to, size_t len,
return len;
}
-static int mt8173_nor_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
+static int mtk_nor_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
{
int ret;
- struct mt8173_nor *mt8173_nor = nor->priv;
+ struct mtk_nor *mtk_nor = nor->priv;
switch (opcode) {
case SPINOR_OP_RDSR:
- ret = mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_RDSR_CMD);
+ ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_RDSR_CMD);
if (ret < 0)
return ret;
if (len == 1)
- *buf = readb(mt8173_nor->base + MTK_NOR_RDSR_REG);
+ *buf = readb(mtk_nor->base + MTK_NOR_RDSR_REG);
else
- dev_err(mt8173_nor->dev, "len should be 1 for read status!\n");
+ dev_err(mtk_nor->dev, "len should be 1 for read status!\n");
break;
default:
- ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, NULL, 0, buf, len);
+ ret = mtk_nor_do_tx_rx(mtk_nor, opcode, NULL, 0, buf, len);
break;
}
return ret;
}
-static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
- int len)
+static int mtk_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
+ int len)
{
int ret;
- struct mt8173_nor *mt8173_nor = nor->priv;
+ struct mtk_nor *mtk_nor = nor->priv;
switch (opcode) {
case SPINOR_OP_WRSR:
/* We only handle 1 byte */
- ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
+ ret = mtk_nor_wr_sr(mtk_nor, *buf);
break;
default:
- ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
+ ret = mtk_nor_do_tx_rx(mtk_nor, opcode, buf, len, NULL, 0);
if (ret)
- dev_warn(mt8173_nor->dev, "write reg failure!\n");
+ dev_warn(mtk_nor->dev, "write reg failure!\n");
break;
}
return ret;
}
-static void mt8173_nor_disable_clk(struct mt8173_nor *mt8173_nor)
+static void mtk_nor_disable_clk(struct mtk_nor *mtk_nor)
{
- clk_disable_unprepare(mt8173_nor->spi_clk);
- clk_disable_unprepare(mt8173_nor->nor_clk);
+ clk_disable_unprepare(mtk_nor->spi_clk);
+ clk_disable_unprepare(mtk_nor->nor_clk);
}
-static int mt8173_nor_enable_clk(struct mt8173_nor *mt8173_nor)
+static int mtk_nor_enable_clk(struct mtk_nor *mtk_nor)
{
int ret;
- ret = clk_prepare_enable(mt8173_nor->spi_clk);
+ ret = clk_prepare_enable(mtk_nor->spi_clk);
if (ret)
return ret;
- ret = clk_prepare_enable(mt8173_nor->nor_clk);
+ ret = clk_prepare_enable(mtk_nor->nor_clk);
if (ret) {
- clk_disable_unprepare(mt8173_nor->spi_clk);
+ clk_disable_unprepare(mtk_nor->spi_clk);
return ret;
}
return 0;
}
-static int mtk_nor_init(struct mt8173_nor *mt8173_nor,
+static int mtk_nor_init(struct mtk_nor *mtk_nor,
struct device_node *flash_node)
{
const struct spi_nor_hwcaps hwcaps = {
@@ -439,18 +439,18 @@ static int mtk_nor_init(struct mt8173_nor *mt8173_nor,
struct spi_nor *nor;
/* initialize controller to accept commands */
- writel(MTK_NOR_ENABLE_SF_CMD, mt8173_nor->base + MTK_NOR_WRPROT_REG);
+ writel(MTK_NOR_ENABLE_SF_CMD, mtk_nor->base + MTK_NOR_WRPROT_REG);
- nor = &mt8173_nor->nor;
- nor->dev = mt8173_nor->dev;
- nor->priv = mt8173_nor;
+ nor = &mtk_nor->nor;
+ nor->dev = mtk_nor->dev;
+ nor->priv = mtk_nor;
spi_nor_set_flash_node(nor, flash_node);
/* fill the hooks to spi nor */
- nor->read = mt8173_nor_read;
- nor->read_reg = mt8173_nor_read_reg;
- nor->write = mt8173_nor_write;
- nor->write_reg = mt8173_nor_write_reg;
+ nor->read = mtk_nor_read;
+ nor->read_reg = mtk_nor_read_reg;
+ nor->write = mtk_nor_write;
+ nor->write_reg = mtk_nor_write_reg;
nor->mtd.name = "mtk_nor";
/* initialized with NULL */
ret = spi_nor_scan(nor, NULL, &hwcaps);
@@ -465,34 +465,34 @@ static int mtk_nor_drv_probe(struct platform_device *pdev)
struct device_node *flash_np;
struct resource *res;
int ret;
- struct mt8173_nor *mt8173_nor;
+ struct mtk_nor *mtk_nor;
if (!pdev->dev.of_node) {
dev_err(&pdev->dev, "No DT found\n");
return -EINVAL;
}
- mt8173_nor = devm_kzalloc(&pdev->dev, sizeof(*mt8173_nor), GFP_KERNEL);
- if (!mt8173_nor)
+ mtk_nor = devm_kzalloc(&pdev->dev, sizeof(*mtk_nor), GFP_KERNEL);
+ if (!mtk_nor)
return -ENOMEM;
- platform_set_drvdata(pdev, mt8173_nor);
+ platform_set_drvdata(pdev, mtk_nor);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- mt8173_nor->base = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(mt8173_nor->base))
- return PTR_ERR(mt8173_nor->base);
+ mtk_nor->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(mtk_nor->base))
+ return PTR_ERR(mtk_nor->base);
- mt8173_nor->spi_clk = devm_clk_get(&pdev->dev, "spi");
- if (IS_ERR(mt8173_nor->spi_clk))
- return PTR_ERR(mt8173_nor->spi_clk);
+ mtk_nor->spi_clk = devm_clk_get(&pdev->dev, "spi");
+ if (IS_ERR(mtk_nor->spi_clk))
+ return PTR_ERR(mtk_nor->spi_clk);
- mt8173_nor->nor_clk = devm_clk_get(&pdev->dev, "sf");
- if (IS_ERR(mt8173_nor->nor_clk))
- return PTR_ERR(mt8173_nor->nor_clk);
+ mtk_nor->nor_clk = devm_clk_get(&pdev->dev, "sf");
+ if (IS_ERR(mtk_nor->nor_clk))
+ return PTR_ERR(mtk_nor->nor_clk);
- mt8173_nor->dev = &pdev->dev;
+ mtk_nor->dev = &pdev->dev;
- ret = mt8173_nor_enable_clk(mt8173_nor);
+ ret = mtk_nor_enable_clk(mtk_nor);
if (ret)
return ret;
@@ -503,20 +503,20 @@ static int mtk_nor_drv_probe(struct platform_device *pdev)
ret = -ENODEV;
goto nor_free;
}
- ret = mtk_nor_init(mt8173_nor, flash_np);
+ ret = mtk_nor_init(mtk_nor, flash_np);
nor_free:
if (ret)
- mt8173_nor_disable_clk(mt8173_nor);
+ mtk_nor_disable_clk(mtk_nor);
return ret;
}
static int mtk_nor_drv_remove(struct platform_device *pdev)
{
- struct mt8173_nor *mt8173_nor = platform_get_drvdata(pdev);
+ struct mtk_nor *mtk_nor = platform_get_drvdata(pdev);
- mt8173_nor_disable_clk(mt8173_nor);
+ mtk_nor_disable_clk(mtk_nor);
return 0;
}
@@ -524,18 +524,18 @@ static int mtk_nor_drv_remove(struct platform_device *pdev)
#ifdef CONFIG_PM_SLEEP
static int mtk_nor_suspend(struct device *dev)
{
- struct mt8173_nor *mt8173_nor = dev_get_drvdata(dev);
+ struct mtk_nor *mtk_nor = dev_get_drvdata(dev);
- mt8173_nor_disable_clk(mt8173_nor);
+ mtk_nor_disable_clk(mtk_nor);
return 0;
}
static int mtk_nor_resume(struct device *dev)
{
- struct mt8173_nor *mt8173_nor = dev_get_drvdata(dev);
+ struct mtk_nor *mtk_nor = dev_get_drvdata(dev);
- return mt8173_nor_enable_clk(mt8173_nor);
+ return mtk_nor_enable_clk(mtk_nor);
}
static const struct dev_pm_ops mtk_nor_dev_pm_ops = {
--
1.7.9.5
^ permalink raw reply related
* [PATCH V1 1/1] mtd: mtk-nor: modify functions' name more generally
From: Guochun Mao @ 2017-12-18 1:47 UTC (permalink / raw)
To: linux-arm-kernel
Since more and more Mediatek's SoC can use this driver to control
spi-nor flash, functions' name with "mt8173_" is no longer properly.
Replacing "mt8173_" with "mtk_" will be more accurate to describe
these functions' usable scope.
Guochun Mao (1):
mtd: mtk-nor: modify functions' name more generally
drivers/mtd/spi-nor/mtk-quadspi.c | 240 +++++++++++++++++++-------------------
1 file changed, 120 insertions(+), 120 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2] ARM: dts: add reset property for rk3066a-rayeager emac phy
From: Chris Zhong @ 2017-12-18 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9893397.vbQdaeDkgV@phil>
Hi Heiko
Thanks :)
On 2017?12?17? 04:11, Heiko Stuebner wrote:
> Hi Chris,
>
> Am Mittwoch, 8. November 2017, 17:50:41 CET schrieb Chris Zhong:
>> The ethernet phy of rk3066a-rayeager has a reset pin, it controlled by
>> GPIO1_D6, this pin should be pull down then pull up to reset the phy.
>> Add a reset-gpios property in phy0, make the phy can be reset when emac
>> power on.
>>
>> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
>> ---
>>
>> Changes in v2:
>> use a generic property for reset, and this patch follow these 2 pathes
>> from Geert Uytterhoeven <geert+renesas@glider.be>
>> http://patchwork.ozlabs.org/patch/828499/
>> http://patchwork.ozlabs.org/patch/828505/
> looks like the phylib-patches were accepted some days ago,
> so I've now also applied this patch for 4.16, after fixing the subject
> by adding the "rockchip:" to "ARM: dts: rockchip": :-)
>
>
> Heiko
>
>
>
--
Chris Zhong
^ permalink raw reply
* [PATCH 1/5] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Sean Young @ 2017-12-17 23:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-2-embed3d@gmail.com>
On Sun, Dec 17, 2017 at 11:45:43PM +0100, Philipp Rossak wrote:
> This patch updates the sunxi-ir driver to set the base clock frequency from
> devicetree.
>
> This is neccessary since there are different ir recievers on the
> market, that operate with different frequencys. So this value could be
s/neccessary/necessary/
s/recievers/receivers/
s/frequencys/frequencies/
> set if the attached ir receiver needs an other base clock frequency,
> than the default 8 MHz.
s/other/different/
>
> Signed-off-by: Philipp Rossak <embed3d@gmail.com>
> ---
> drivers/media/rc/sunxi-cir.c | 20 ++++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
> index 97f367b446c4..9bbe55a76860 100644
> --- a/drivers/media/rc/sunxi-cir.c
> +++ b/drivers/media/rc/sunxi-cir.c
> @@ -72,12 +72,8 @@
> /* CIR_REG register idle threshold */
> #define REG_CIR_ITHR(val) (((val) << 8) & (GENMASK(15, 8)))
>
> -/* Required frequency for IR0 or IR1 clock in CIR mode */
> +/* Required frequency for IR0 or IR1 clock in CIR mode (default) */
> #define SUNXI_IR_BASE_CLK 8000000
> -/* Frequency after IR internal divider */
> -#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
> -/* Sample period in ns */
> -#define SUNXI_IR_SAMPLE (1000000000ul / SUNXI_IR_CLK)
> /* Noise threshold in samples */
> #define SUNXI_IR_RXNOISE 1
> /* Idle Threshold in samples */
> @@ -122,7 +118,7 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
> /* for each bit in fifo */
> dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
> rawir.pulse = (dt & 0x80) != 0;
> - rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
> + rawir.duration = ((dt & 0x7f) + 1) * ir->rc->rx_resolution;
Line over 80 characters.
> ir_raw_event_store_with_filter(ir->rc, &rawir);
> }
> }
> @@ -148,6 +144,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> struct device_node *dn = dev->of_node;
> struct resource *res;
> struct sunxi_ir *ir;
> + u32 b_clk_freq;
>
> ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
> if (!ir)
> @@ -172,6 +169,11 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> return PTR_ERR(ir->clk);
> }
>
> + /* Base clock frequency (optional) */
> + if (of_property_read_u32(dn, "clock-frequency", &b_clk_freq)) {
> + b_clk_freq = SUNXI_IR_BASE_CLK;
> + }
No braces here please; please use ./scripts/checkpatch.pl to find issues
like this.
> +
> /* Reset (optional) */
> ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
> if (IS_ERR(ir->rst))
> @@ -180,11 +182,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
> + ret = clk_set_rate(ir->clk, b_clk_freq);
> if (ret) {
> dev_err(dev, "set ir base clock failed!\n");
> goto exit_reset_assert;
> }
> + dev_info(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
>
> if (clk_prepare_enable(ir->apb_clk)) {
> dev_err(dev, "try to enable apb_ir_clk failed\n");
> @@ -225,7 +228,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
> ir->rc->dev.parent = dev;
> ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
> - ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
> + /* Frequency after IR internal divider with sample period in ns */
> + ir->rc->rx_resolution = (1000000000ul / (b_clk_freq / 64));
> ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
> ir->rc->driver_name = SUNXI_IR_DEV;
>
> --
> 2.11.0
^ permalink raw reply
* [PATCH v2 9/9] ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support
From: Philippe Ombredanne @ 2017-12-17 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BXEj9AKeQEVNhDYMCydpe+PVnXjchvTAuuwdM7Yp6d2w@mail.gmail.com>
Fabio,
On Sun, Dec 17, 2017 at 10:59 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Stefan,
>
> On Sun, Dec 17, 2017 at 6:37 PM, Stefan Agner <stefan@agner.ch> wrote:
>
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
>> @@ -0,0 +1,20 @@
>> +/*
>> + * Copyright 2017 Toradex AG
>> + *
>> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> + */
>
> In the previous patch you used GPL-2.0 text, instead of GPL-2.0+.
>
> The SPDX line should be the first one and start with a // style comment:
>
> // SPDX-License-Identifier: (GPL-2.0 OR MIT)
Yes this line as the top line is the correct way as explained in
Thomas doc patches [1]
I cannot comment of whether the author wants GPL 2 or 2+ though KISS is best.
[1] https://lkml.org/lkml/2017/12/4/934
> Philippe, please confirm this is the correct way.
>
> With this fixed you can add:
>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH] net: ethernet: fix call_kern.cocci warnings
From: Linus Walleij @ 2017-12-17 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1712170739410.2501@hadrien>
On Sun, Dec 17, 2017 at 7:43 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> From: Fengguang Wu <fengguang.wu@intel.com>
>
> Allocation with GFP_KERNEL in code called from the function
> geth_resize_freeq with locks held.
>
> Generated by: scripts/coccinelle/locks/call_kern.cocci
>
> Fixes: 502a2864e5e4 ("net: ethernet: Add a driver for Gemini gigabit ethernet")
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
> ---
>
> The proposed change of converting the GFP_KERNEL is not necessarily the
> correct one. It may be desired to unlock the lock, or to not call the
> function under the lock in the first place.
It's better to drop the lock around the offending call. the lock was just there
to protect the interrupt registers anyway.
But thanks for finding it!
I have updated the driver patch.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 5/5] arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
From: Philipp Rossak @ 2017-12-17 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-1-embed3d@gmail.com>
The Bananapi M3 has an onboard IR receiver.
This enables the onboard IR receiver subnode.
Other than the other IR receivers this one needs a base clock frequency
of 3000000 Hz (3 MHz), to be able to work.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..2bf25ca64133 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -100,6 +100,13 @@
status = "okay";
};
+&ir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_pins_a>;
+ clock-frequency = <3000000>;
+ status = "okay";
+};
+
&mdio {
rgmii_phy: ethernet-phy at 1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.11.0
^ permalink raw reply related
* [PATCH 4/5] arm: dts: sun8i: a83t: Add support for the ir interface
From: Philipp Rossak @ 2017-12-17 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-1-embed3d@gmail.com>
The ir interface is like on the H3 located at 0x01f02000 and is exactly
the same. This patch adds support for the ir interface on the A83T.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 954c2393325f..9e7ed3b9a6b8 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -503,6 +503,16 @@
#reset-cells = <1>;
};
+ ir: ir at 01f02000 {
+ compatible = "allwinner,sun5i-a13-ir";
+ clocks = <&r_ccu CLK_APB0_IR>, <&r_ccu CLK_IR>;
+ clock-names = "apb", "ir";
+ resets = <&r_ccu RST_APB0_IR>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x01f02000 0x40>;
+ status = "disabled";
+ };
+
r_pio: pinctrl at 1f02c00 {
compatible = "allwinner,sun8i-a83t-r-pinctrl";
reg = <0x01f02c00 0x400>;
--
2.11.0
^ permalink raw reply related
* [PATCH 3/5] arm: dts: sun8i: a83t: Add the ir pin for the A83T
From: Philipp Rossak @ 2017-12-17 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-1-embed3d@gmail.com>
The CIR Pin of the A83T is located at PL12.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index a384b766f3dc..954c2393325f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -521,6 +521,11 @@
drive-strength = <20>;
bias-pull-up;
};
+
+ ir_pins_a: ir at 0 {
+ pins = "PL12";
+ function = "s_cir_rx";
+ };
};
r_rsb: rsb at 1f03400 {
--
2.11.0
^ permalink raw reply related
* [PATCH 2/5] media: dt: bindings: Update binding documentation for sunxi IR controller
From: Philipp Rossak @ 2017-12-17 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-1-embed3d@gmail.com>
This patch updates documentation for Device-Tree bindings for sunxi IR
controller and adds the new optional property for the base clock
frequency.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
Documentation/devicetree/bindings/media/sunxi-ir.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 91648c569b1e..9f45bab07d6e 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -11,6 +11,7 @@ Required properties:
Optional properties:
- linux,rc-map-name: see rc.txt file in the same directory.
- resets : phandle + reset specifier pair
+- clock-frequency : overrides the default base clock frequency (8 MHz)
Example:
@@ -18,6 +19,7 @@ ir0: ir at 1c21800 {
compatible = "allwinner,sun4i-a10-ir";
clocks = <&apb0_gates 6>, <&ir0_clk>;
clock-names = "apb", "ir";
+ clock-frequency = <3000000>;
resets = <&apb0_rst 1>;
interrupts = <0 5 1>;
reg = <0x01C21800 0x40>;
--
2.11.0
^ permalink raw reply related
* [PATCH 1/5] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Philipp Rossak @ 2017-12-17 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-1-embed3d@gmail.com>
This patch updates the sunxi-ir driver to set the base clock frequency from
devicetree.
This is neccessary since there are different ir recievers on the
market, that operate with different frequencys. So this value could be
set if the attached ir receiver needs an other base clock frequency,
than the default 8 MHz.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
drivers/media/rc/sunxi-cir.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 97f367b446c4..9bbe55a76860 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -72,12 +72,8 @@
/* CIR_REG register idle threshold */
#define REG_CIR_ITHR(val) (((val) << 8) & (GENMASK(15, 8)))
-/* Required frequency for IR0 or IR1 clock in CIR mode */
+/* Required frequency for IR0 or IR1 clock in CIR mode (default) */
#define SUNXI_IR_BASE_CLK 8000000
-/* Frequency after IR internal divider */
-#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
-/* Sample period in ns */
-#define SUNXI_IR_SAMPLE (1000000000ul / SUNXI_IR_CLK)
/* Noise threshold in samples */
#define SUNXI_IR_RXNOISE 1
/* Idle Threshold in samples */
@@ -122,7 +118,7 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
/* for each bit in fifo */
dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
rawir.pulse = (dt & 0x80) != 0;
- rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
+ rawir.duration = ((dt & 0x7f) + 1) * ir->rc->rx_resolution;
ir_raw_event_store_with_filter(ir->rc, &rawir);
}
}
@@ -148,6 +144,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
struct device_node *dn = dev->of_node;
struct resource *res;
struct sunxi_ir *ir;
+ u32 b_clk_freq;
ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
if (!ir)
@@ -172,6 +169,11 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return PTR_ERR(ir->clk);
}
+ /* Base clock frequency (optional) */
+ if (of_property_read_u32(dn, "clock-frequency", &b_clk_freq)) {
+ b_clk_freq = SUNXI_IR_BASE_CLK;
+ }
+
/* Reset (optional) */
ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
if (IS_ERR(ir->rst))
@@ -180,11 +182,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
+ ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
dev_err(dev, "set ir base clock failed!\n");
goto exit_reset_assert;
}
+ dev_info(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
if (clk_prepare_enable(ir->apb_clk)) {
dev_err(dev, "try to enable apb_ir_clk failed\n");
@@ -225,7 +228,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
- ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
+ /* Frequency after IR internal divider with sample period in ns */
+ ir->rc->rx_resolution = (1000000000ul / (b_clk_freq / 64));
ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
ir->rc->driver_name = SUNXI_IR_DEV;
--
2.11.0
^ permalink raw reply related
* [PATCH 0/5] arm: sunxi: IR support for A83T
From: Philipp Rossak @ 2017-12-17 22:45 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for the sunxi A83T ir module and enhances the sunxi-ir driver.
Right now the base clock frequency for the ir driver is a hard coded define and is set to 8 MHz.
This works for the most common ir receivers. On the Sinovoip Bananapi M3 the ir receiver needs,
a 3 MHz base clock frequency to work without problems with this driver.
This patch series adds support for an optinal property that makes it able to override the default
base clock frequency and enables the ir interface on the a83t and the Bananapi M3.
changes since rfc:
* The property is now optinal. If the property is not available in the dtb the driver
uses the default base clock frequency.
* the driver prints out the the selected base clock frequency.
* changed devicetree property from base-clk-frequency to clock-frequency
Regards,
Philipp
rfc: https://www.mail-archive.com/linux-media at vger.kernel.org/msg123359.html
Philipp Rossak (5):
media: rc: update sunxi-ir driver to get base clock frequency from
devicetree
media: dt: bindings: Update binding documentation for sunxi IR
controller
arm: dts: sun8i: a83t: Add the ir pin for the A83T
arm: dts: sun8i: a83t: Add support for the ir interface
arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
Documentation/devicetree/bindings/media/sunxi-ir.txt | 2 ++
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +++++++++++++++
drivers/media/rc/sunxi-cir.c | 20 ++++++++++++--------
4 files changed, 36 insertions(+), 8 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH v3 04/11] thermal: armada: Rationalize register accesses
From: Baruch Siach @ 2017-12-17 22:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216221838.v6gtaoqy2xhozapp@tarshish>
Hi Miqu?l,
On Sun, Dec 17, 2017 at 12:18:38AM +0200, Baruch Siach wrote:
> On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> > Bindings were incomplete for a long time by only exposing one of the two
> > available control registers. To ease the migration to the full bindings
> > (already in use for the Armada 375 SoC), rename the pointers for
> > clarification. This way, it will only be needed to add another pointer
> > to access the other control register when the time comes.
> >
> > This avoids dangerous situations where the offset 0 of the control
> > area can be either one register or the other depending on the bindings
> > used. After this change, device trees of other SoCs could be migrated to
> > the "full" bindings if they may benefit from features from the
> > unaccessible register, without any change in the driver.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > ---
>
> [...]
>
> > + /*
> > + * Legacy DT bindings only described "control1" register (also referred
> > + * as "control MSB" on old documentation). New bindings cover
> > + * "control0/control LSB" and "control1/control MSB" registers within
> > + * the same resource, which is then of size 8 instead of 4.
> > + */
> > + if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> > + /* ->control0 unavailable in this configuration */
> > + priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> > + } else {
> > + priv->control0 = control + CONTROL0_OFFSET;
> > + priv->control1 = control + CONTROL1_OFFSET;
> > + }
>
> I think we need to add a check here that the control registers area size
> matches the expected value given the compatible string. In case of mismatch
> probe should fail.
One more thing. You should probably use resource_size() instead of open coding
it. resource_size() does "res->end - res->start + 1". Are you sure your code
is correct?
> > priv->data = (struct armada_thermal_data *)match->data;
> > priv->data->init_sensor(pdev, priv);
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v2 9/9] ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support
From: Fabio Estevam @ 2017-12-17 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217203723.15896-9-stefan@agner.ch>
Hi Stefan,
On Sun, Dec 17, 2017 at 6:37 PM, Stefan Agner <stefan@agner.ch> wrote:
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
> @@ -0,0 +1,20 @@
> +/*
> + * Copyright 2017 Toradex AG
> + *
> + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> + */
In the previous patch you used GPL-2.0 text, instead of GPL-2.0+.
The SPDX line should be the first one and start with a // style comment:
// SPDX-License-Identifier: (GPL-2.0 OR MIT)
Philippe, please confirm this is the correct way.
With this fixed you can add:
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v2 8/9] ARM: dts: imx7-colibri: add MCP2515 CAN controller
From: Fabio Estevam @ 2017-12-17 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217203723.15896-8-stefan@agner.ch>
On Sun, Dec 17, 2017 at 6:37 PM, Stefan Agner <stefan@agner.ch> wrote:
> The Colibri Evaluation Carrier Board provides a MCP2515 CAN
> controller connected via SPI. Note that the i.MX 7 provides
> an internal CAN controller which is much better suited for CAN
> operations. Using the MCP2515 with a Colibri iMX7 module is
> mainly useful to test the SPI interface.
>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Miquel RAYNAL @ 2017-12-17 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217222611.59f9031b@bbrezillon>
Hello Willy,
On Sun, 17 Dec 2017 22:26:11 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> +Miquel
>
> On Sun, 17 Dec 2017 22:16:50 +0100
> Willy Tarreau <w@1wt.eu> wrote:
>
> > On Sun, Dec 17, 2017 at 06:01:29PM -0300, Ezequiel Garcia wrote:
> > > On 17 December 2017 at 16:00, Willy Tarreau <w@1wt.eu> wrote:
> > > > On Sun, Dec 17, 2017 at 07:07:46PM +0100, Boris Brezillon
> > > > wrote:
> > > >> > > This would guarantee that devices with factory bad blocks,
> > > >> > > (and no BBT), would be OK with this patch.
> > > >> >
> > > >> > I see. I'm fine with trying provided I have reasonably good
> > > >> > assurance that I won't have to go through the kwboot pain
> > > >> > again :-/
> > > >>
> > > >> There's a easy test you can do without scrubing the NAND:
> > > >> 1/ comment the nand-on-flash-bbt property in your DT (this
> > > >> will trigger a full scan)
> > > >> 2/ from u-boot (before booting the kernel), erase a block that
> > > >> you know contains nothing important
> > > >> 3/ during the kernel scan, make sure this block is not
> > > >> reported as bad
> > > >
> > > > OK so I tried and never faced any error. Thus I also attempted
> > > > to mark a bad block in u-boot, it appeared in the bad blocks
> > > > table, then I had to scrub the whole table to get rid of it.
> > > > Each time when I booted I saw the message "Scanning device for
> > > > bad blocks" but no error ever happened. So I hope it's OK.
> > > >
> > >
> > > Nice. Thanks a lot Willy. I think this acks Boris' patch.
> >
> > You're welcome, you and Boris fixed my problem very quickly
> > allowing me to continue to prepare my new router :-)
> >
> > BTW, Boris please don't forget to mark your fix for -stable.
>
> Actually, if things go well it will only be applied to stable
> releases (I really hope we'll be able to switch to Miquel's driver in
> 4.16). BTW, if you have some time, maybe you can test Miquel's [1]
> branch and let us know if it still works properly.
As Boris said, we would really welcome a test of this branch, because
you almost have the same setup as Sean in the thread "pxa3xx: wait time
out when scanning for bb" and I am running out of explanation for his
problem unless it is related to U-Boot. So if you could try booting
with and without the on-flash-bbt property and report whether it fails
or not it would be of great help!
Thanks,
Miqu?l
>
> Thanks,
>
> Boris
>
> [1]https://github.com/miquelraynal/linux/tree/marvell/nand-next/nfc
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Lukasz Majewski @ 2017-12-17 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a09V1ZhhVCvdy27BiBCMM54zo4qyypgSDvrg2CdpneVmg@mail.gmail.com>
Hi Arnd,
> On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski <lukma@denx.de>
> wrote:
> >> >> We also need to think about upholding support in GCC for
> >> >> ARMv4(t) for the foreseeable future if there is a big web of
> >> >> random deeply embedded systems out there that will need
> >> >> updates.
> >> >
> >> > But we should definitely preserve at least what we have.
> >>
> >> Plain ARMv4 (and earlier) support in gcc is already marked
> >> 'deprecated' and will likely be gone in gcc-8 (it's still there as
> >> of last week). ARMv4T is going to be around for a while, and you
> >> can even keep building for ARMv4 using "-march=armv4t -marm" when
> >> linking with 'ld --fix-v4bx'.
> >
> > I think that we shall start complaining on the gcc-devel mailing
> > list now.
> >
> > I would be hard to wake up in 2 years time and realise that we don't
> > have a modern compiler.
>
> What distro or build system are you using?
I'm using OE with the "include conf/machine/include/tune-arm920t.inc"
GCC 7.2 is working
> It would also be helpful
> to test whether the -march=armv4t/--fix-v4bx workaround produces
> working binaries for you, in that case you could report to the gcc
> developers that the removal of armv4 can continue but that
> the --fix-v4bx option in ld needs to stay around.
I may ask this issue on OE/Yocto mailing list as well....
Thanks for hint.
>
> Arnd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171217/bec5a31a/attachment-0001.sig>
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Boris Brezillon @ 2017-12-17 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217211650.GA6815@1wt.eu>
+Miquel
On Sun, 17 Dec 2017 22:16:50 +0100
Willy Tarreau <w@1wt.eu> wrote:
> On Sun, Dec 17, 2017 at 06:01:29PM -0300, Ezequiel Garcia wrote:
> > On 17 December 2017 at 16:00, Willy Tarreau <w@1wt.eu> wrote:
> > > On Sun, Dec 17, 2017 at 07:07:46PM +0100, Boris Brezillon wrote:
> > >> > > This would guarantee that devices with factory bad blocks,
> > >> > > (and no BBT), would be OK with this patch.
> > >> >
> > >> > I see. I'm fine with trying provided I have reasonably good assurance
> > >> > that I won't have to go through the kwboot pain again :-/
> > >>
> > >> There's a easy test you can do without scrubing the NAND:
> > >> 1/ comment the nand-on-flash-bbt property in your DT (this will trigger
> > >> a full scan)
> > >> 2/ from u-boot (before booting the kernel), erase a block that you know
> > >> contains nothing important
> > >> 3/ during the kernel scan, make sure this block is not reported as bad
> > >
> > > OK so I tried and never faced any error. Thus I also attempted to mark
> > > a bad block in u-boot, it appeared in the bad blocks table, then I had
> > > to scrub the whole table to get rid of it. Each time when I booted I
> > > saw the message "Scanning device for bad blocks" but no error ever
> > > happened. So I hope it's OK.
> > >
> >
> > Nice. Thanks a lot Willy. I think this acks Boris' patch.
>
> You're welcome, you and Boris fixed my problem very quickly allowing me
> to continue to prepare my new router :-)
>
> BTW, Boris please don't forget to mark your fix for -stable.
Actually, if things go well it will only be applied to stable
releases (I really hope we'll be able to switch to Miquel's driver in
4.16). BTW, if you have some time, maybe you can test Miquel's [1]
branch and let us know if it still works properly.
Thanks,
Boris
[1]https://github.com/miquelraynal/linux/tree/marvell/nand-next/nfc
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Willy Tarreau @ 2017-12-17 21:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAEAJfArtxcWgcjHAb__3BQxWEBgWU8uWtHGYETc-m9eUs91nA@mail.gmail.com>
On Sun, Dec 17, 2017 at 06:01:29PM -0300, Ezequiel Garcia wrote:
> On 17 December 2017 at 16:00, Willy Tarreau <w@1wt.eu> wrote:
> > On Sun, Dec 17, 2017 at 07:07:46PM +0100, Boris Brezillon wrote:
> >> > > This would guarantee that devices with factory bad blocks,
> >> > > (and no BBT), would be OK with this patch.
> >> >
> >> > I see. I'm fine with trying provided I have reasonably good assurance
> >> > that I won't have to go through the kwboot pain again :-/
> >>
> >> There's a easy test you can do without scrubing the NAND:
> >> 1/ comment the nand-on-flash-bbt property in your DT (this will trigger
> >> a full scan)
> >> 2/ from u-boot (before booting the kernel), erase a block that you know
> >> contains nothing important
> >> 3/ during the kernel scan, make sure this block is not reported as bad
> >
> > OK so I tried and never faced any error. Thus I also attempted to mark
> > a bad block in u-boot, it appeared in the bad blocks table, then I had
> > to scrub the whole table to get rid of it. Each time when I booted I
> > saw the message "Scanning device for bad blocks" but no error ever
> > happened. So I hope it's OK.
> >
>
> Nice. Thanks a lot Willy. I think this acks Boris' patch.
You're welcome, you and Boris fixed my problem very quickly allowing me
to continue to prepare my new router :-)
BTW, Boris please don't forget to mark your fix for -stable.
Thanks,
Willy
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Ezequiel Garcia @ 2017-12-17 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217190056.GA1107@1wt.eu>
On 17 December 2017 at 16:00, Willy Tarreau <w@1wt.eu> wrote:
> On Sun, Dec 17, 2017 at 07:07:46PM +0100, Boris Brezillon wrote:
>> > > This would guarantee that devices with factory bad blocks,
>> > > (and no BBT), would be OK with this patch.
>> >
>> > I see. I'm fine with trying provided I have reasonably good assurance
>> > that I won't have to go through the kwboot pain again :-/
>>
>> There's a easy test you can do without scrubing the NAND:
>> 1/ comment the nand-on-flash-bbt property in your DT (this will trigger
>> a full scan)
>> 2/ from u-boot (before booting the kernel), erase a block that you know
>> contains nothing important
>> 3/ during the kernel scan, make sure this block is not reported as bad
>
> OK so I tried and never faced any error. Thus I also attempted to mark
> a bad block in u-boot, it appeared in the bad blocks table, then I had
> to scrub the whole table to get rid of it. Each time when I booted I
> saw the message "Scanning device for bad blocks" but no error ever
> happened. So I hope it's OK.
>
Nice. Thanks a lot Willy. I think this acks Boris' patch.
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh Sharma @ 2017-12-17 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-W5VpVrgA=FVZCCevksaRGOVvPdE+B8WkpZc6AE1jOPw@mail.gmail.com>
On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 15 December 2017 at 09:59, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
>> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
>>> On 13 December 2017 at 12:16, AKASHI Takahiro
>>> <takahiro.akashi@linaro.org> wrote:
>>> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
>>> >> On 13 December 2017 at 10:26, AKASHI Takahiro
>>> >> <takahiro.akashi@linaro.org> wrote:
>>> >> > Bhupesh, Ard,
>>> >> >
>>> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
>>> >> >> Hi Ard, Akashi
>>> >> >>
>>> >> > (snip)
>>> >> >
>>> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
>>> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
>>> >> >> identify its own usable memory and exclude, at its boot time, any
>>> >> >> other memory areas that are part of the panicked kernel's memory.
>>> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>>> >> >> , for details)
>>> >> >
>>> >> > Right.
>>> >> >
>>> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
>>> >> >> with the crashkernel memory range:
>>> >> >>
>>> >> >> /* add linux,usable-memory-range */
>>> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
>>> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
>>> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
>>> >> >> address_cells, size_cells);
>>> >> >>
>>> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
>>> >> >> , for details)
>>> >> >>
>>> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
>>> >> >> they are marked as System RAM or as RESERVED. As,
>>> >> >> 'linux,usable-memory-range' dt node is patched up only with
>>> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
>>> >> >>
>>> >> >> 3). As a result when the crashkernel boots up it doesn't find this
>>> >> >> ACPI memory and crashes while trying to access the same:
>>> >> >>
>>> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
>>> >> >> -r`.img --reuse-cmdline -d
>>> >> >>
>>> >> >> [snip..]
>>> >> >>
>>> >> >> Reserved memory range
>>> >> >> 000000000e800000-000000002e7fffff (0)
>>> >> >>
>>> >> >> Coredump memory ranges
>>> >> >> 0000000000000000-000000000e7fffff (0)
>>> >> >> 000000002e800000-000000003961ffff (0)
>>> >> >> 0000000039d40000-000000003ed2ffff (0)
>>> >> >> 000000003ed60000-000000003fbfffff (0)
>>> >> >> 0000001040000000-0000001ffbffffff (0)
>>> >> >> 0000002000000000-0000002ffbffffff (0)
>>> >> >> 0000009000000000-0000009ffbffffff (0)
>>> >> >> 000000a000000000-000000affbffffff (0)
>>> >> >>
>>> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
>>> >> >> memory cap'ing passed to the crash kernel inside
>>> >> >> 'arch/arm64/mm/init.c' (see below):
>>> >> >>
>>> >> >> static void __init fdt_enforce_memory_region(void)
>>> >> >> {
>>> >> >> struct memblock_region reg = {
>>> >> >> .size = 0,
>>> >> >> };
>>> >> >>
>>> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>>> >> >>
>>> >> >> if (reg.size)
>>> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
>>> >> >> comment this out */
>>> >> >> }
>>> >> >
>>> >> > Please just don't do that. It can cause a fatal damage on
>>> >> > memory contents of the *crashed* kernel.
>>> >> >
>>> >> >> 5). Both the above temporary solutions fix the problem.
>>> >> >>
>>> >> >> 6). However exposing all System RAM regions to the crashkernel is not
>>> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
>>> >> >> fail.
>>> >> >>
>>> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
>>> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
>>> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
>>> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
>>> >> >> dt node 'linux,usable-memory-range'
>>> >> >
>>> >> > I still don't understand why we need to carry over the information
>>> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
>>> >> > such regions are free to be reused by the kernel after some point of
>>> >> > initialization. Why does crash dump kernel need to know about them?
>>> >> >
>>> >>
>>> >> Not really. According to the UEFI spec, they can be reclaimed after
>>> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
>>> >> no longer needs them. Of course, in order to be able to boot a kexec
>>> >> kernel, those regions needs to be preserved, which is why they are
>>> >> memblock_reserve()'d now.
>>> >
>>> > For my better understandings, who is actually accessing such regions
>>> > during boot time, uefi itself or efistub?
>>> >
>>>
>>> No, only the kernel. This is where the ACPI tables are stored. For
>>> instance, on QEMU we have
>>>
>>> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
>>> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
>>> 01000013)
>>> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
>>> BXPC 00000001)
>>> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
>>> BXPC 00000001)
>>> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
>>> BXPC 00000001)
>>> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
>>> BXPC 00000001)
>>> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
>>> BXPC 00000001)
>>> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
>>> BXPC 00000001)
>>> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
>>> BXPC 00000001)
>>>
>>> covered by
>>>
>>> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
>>> ...
>>> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>>
>> OK. I mistakenly understood those regions could be freed after exiting
>> UEFI boot services.
>>
>>>
>>> >> So it seems that kexec does not honour the memblock_reserve() table
>>> >> when booting the next kernel.
>>> >
>>> > not really.
>>> >
>>> >> > (In other words, can or should we skip some part of ACPI-related init code
>>> >> > on crash dump kernel?)
>>> >> >
>>> >>
>>> >> I don't think so. And the change to the handling of ACPI reclaim
>>> >> regions only revealed the bug, not created it (given that other
>>> >> memblock_reserve regions may be affected as well)
>>> >
>>> > As whether we should honor such reserved regions over kexec'ing
>>> > depends on each one's specific nature, we will have to take care one-by-one.
>>> > As a matter of fact, no information about "reserved" memblocks is
>>> > exposed to user space (via proc/iomem).
>>> >
>>>
>>> That is why I suggested (somewhere in this thread?) to not expose them
>>> as 'System RAM'. Do you think that could solve this?
>>
>> Memblock-reserv'ing them is necessary to prevent their corruption and
>> marking them under another name in /proc/iomem would also be good in order
>> not to allocate them as part of crash kernel's memory.
>>
>
> I agree. However, this may not be entirely trivial, since iterating
> over the memblock_reserved table and creating iomem entries may result
> in collisions.
I found a method (using the patch I shared earlier in this thread) to mark these
entries as 'ACPI reclaim memory' ranges rather than System RAM or
reserved regions.
>> But I'm not still convinced that we should export them in useable-
>> memory-range to crash dump kernel. They will be accessed through
>> acpi_os_map_memory() and so won't be required to be part of system ram
>> (or memblocks), I guess.
>
> Agreed. They will be covered by the linear mapping in the boot kernel,
> and be mapped explicitly via ioremap_cache() in the kexec kernel,
> which is exactly what we want in this case.
Now this is what is confusing me. I don't see the above happening.
I see that the primary kernel boots up and adds the ACPI regions via:
acpi_os_ioremap
-> ioremap_cache
But during the crashkernel boot, ''acpi_os_ioremap' calls
'ioremap' for the ACPI Reclaim Memory regions and not the _cache
variant.
And it fails while accessing the ACPI tables:
[ 0.039205] ACPI: Core revision 20170728
pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
[ 0.095098] Internal error: Oops: 96000021 [#1] SMP
[ 0.100022] Modules linked in:
[ 0.103102] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
[ 0.109432] task: ffff000008d05180 task.stack: ffff000008cc0000
[ 0.115414] PC is at acpi_ns_lookup+0x25c/0x3c0
[ 0.119987] LR is at acpi_ds_load1_begin_op+0xa4/0x294
[ 0.125175] pc : [<ffff0000084a6764>] lr : [<ffff00000849b4f8>]
pstate: 60000045
[ 0.132647] sp : ffff000008ccfb40
[ 0.135989] x29: ffff000008ccfb40 x28: ffff000008a9f2a4
[ 0.141354] x27: ffff0000088be820 x26: 0000000000000000
[ 0.146718] x25: 000000000000001b x24: 0000000000000001
[ 0.152083] x23: 0000000000000001 x22: ffff000009710027
[ 0.157447] x21: ffff000008ccfc50 x20: 0000000000000001
[ 0.162812] x19: 000000000000001b x18: 0000000000000005
[ 0.168176] x17: 0000000000000000 x16: 0000000000000000
[ 0.173541] x15: 0000000000000000 x14: 000000000000038e
[ 0.178905] x13: ffffffff00000000 x12: ffffffffffffffff
[ 0.184270] x11: 0000000000000006 x10: 00000000ffffff76
[ 0.189634] x9 : 000000000000005f x8 : ffff8000126d0140
[ 0.194998] x7 : 0000000000000000 x6 : ffff000008ccfc50
[ 0.200362] x5 : ffff80000fe62c00 x4 : 0000000000000001
[ 0.205727] x3 : ffff000008ccfbe0 x2 : ffff0000095e3980
[ 0.211091] x1 : ffff000009710027 x0 : 0000000000000000
[ 0.216456] Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
[ 0.223224] Call trace:
[ 0.225688] Exception stack(0xffff000008ccfa00 to 0xffff000008ccfb40)
[ 0.232194] fa00: 0000000000000000 ffff000009710027
ffff0000095e3980 ffff000008ccfbe0
[ 0.240106] fa20: 0000000000000001 ffff80000fe62c00
ffff000008ccfc50 0000000000000000
[ 0.248018] fa40: ffff8000126d0140 000000000000005f
00000000ffffff76 0000000000000006
[ 0.255931] fa60: ffffffffffffffff ffffffff00000000
000000000000038e 0000000000000000
[ 0.263843] fa80: 0000000000000000 0000000000000000
0000000000000005 000000000000001b
[ 0.271754] faa0: 0000000000000001 ffff000008ccfc50
ffff000009710027 0000000000000001
[ 0.279667] fac0: 0000000000000001 000000000000001b
0000000000000000 ffff0000088be820
[ 0.287579] fae0: ffff000008a9f2a4 ffff000008ccfb40
ffff00000849b4f8 ffff000008ccfb40
[ 0.295491] fb00: ffff0000084a6764 0000000060000045
ffff000008ccfb40 ffff000008260a18
[ 0.303403] fb20: ffffffffffffffff ffff0000087f3fb0
ffff000008ccfb40 ffff0000084a6764
[ 0.311316] [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
[ 0.316943] [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
[ 0.323186] [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
[ 0.329428] [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
[ 0.335319] [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
[ 0.341298] [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
[ 0.347101] [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
[ 0.353783] [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
[ 0.359675] [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
[ 0.365479] [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
[ 0.371723] [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
[ 0.377350] [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
[ 0.382891] [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
[ 0.388343] Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
[ 0.394500] ---[ end trace c46ed37f9651c58e ]---
[ 0.399160] Kernel panic - not syncing: Fatal exception
[ 0.404437] Rebooting in 10 seconds.
So, I think the linear mapping done by the primary kernel does not
make these accessible in the crash kernel directly.
Any pointers?
Regards,
Bhupesh
>> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>> via a kernel command line parameter, "memmap=".
>>
^ 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