Re: [linux-sunxi] No "spl/sunxi-spl.bin" for A31?
Hi Igor, El 18/03/14 23:36, Igor Cardoso escribió: Hello, I was trying to make a bootable SD CARD for A31 from scratch but I have a problem. A lot of places that helps build SD CARD for Allwinner processors talk about a file called spl/sunxi-spl.bin, but that doesn't exist on A31 folders... I've manage to find the boot0_sdcard.fex and boot1_sdcard.fex and u-boot.bin. I can load boot0 and boot1 like this: dd if=boot0_sdcard.fex of=/dev/sdd seek=8 bs=1024 dd if=boot1_sdcard.fex of=/dev/sdd seek=19096 bs=1024 But then I don't know how to put u-boot. I have bootloader.fex, boot.bin, a lot of boot's and I'm reallt confused. The boot from NAND is on e FAT partition, this make me more confused... Here is my questions: 1) What is bootloader.fex and what is the difference from boot.img and u-boot.bin? 2) How can I load u-boot or bootloader to SD CARD manually? Formating and creating partition with FDISK? Thanks, sorry for the confusion. We currently have no A31 support on the sunxi community U-Boot nor on linux-sunxi, so you'll probably need to use Allwinner's bootloaders. Cheers, Emilio -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: No "spl/sunxi-spl.bin" for A31?
No one? =( Em terça-feira, 18 de março de 2014 23h36min54s UTC-3, Igor Cardoso escreveu: > > > > Hello, > > I was trying to make a bootable SD CARD for A31 from scratch but I have a > problem. A lot of places that helps build SD CARD for Allwinner processors > talk about a file called spl/sunxi-spl.bin, but that doesn't exist on A31 > folders... > > I've manage to find the boot0_sdcard.fex and boot1_sdcard.fex and > u-boot.bin. I can load boot0 and boot1 like this: > > dd if=boot0_sdcard.fex of=/dev/sdd seek=8 bs=1024 > dd if=boot1_sdcard.fex of=/dev/sdd seek=19096 bs=1024 > > But then I don't know how to put u-boot. I have bootloader.fex, > boot.bin, a lot of boot's and I'm reallt confused. > > The boot from NAND is on e FAT partition, this make me more confused... > > Here is my questions: > > 1) What is bootloader.fex and what is the difference from boot.img and > u-boot.bin? > 2) How can I load u-boot or bootloader to SD CARD manually? Formating and > creating partition with FDISK? > > Thanks, sorry for the confusion. > > Igor. > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi.git 9/9] sunxi: mmc: checkpatch whitespace fixes
Signed-off-by: Ian Campbell
---
Normally I object to this sort of churn but this is so that the patches
submitted upstream can be checkpatch clean.
---
drivers/mmc/sunxi_mmc.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index a09e021..cf065f4 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -231,7 +231,8 @@ static int mmc_update_clk(struct mmc *mmc)
SUNXI_MMC_CMD_UPCLK_ONLY |
SUNXI_MMC_CMD_WAIT_PRE_OVER;
writel(cmd, &mmchost->reg->cmd);
- while ((readl(&mmchost->reg->cmd) & SUNXI_MMC_CMD_START) && timeout--);
+ while ((readl(&mmchost->reg->cmd) & SUNXI_MMC_CMD_START) && timeout--)
+ ;
if (!timeout)
return -1;
@@ -317,7 +318,8 @@ static int mmc_trans_data_by_cpu(struct mmc *mmc, struct
mmc_data *data)
for (i = 0; i < (byte_cnt >> 2); i++) {
while (--timeout &&
(readl(&mmchost->reg->status) &
- SUNXI_MMC_STATUS_FIFO_EMPTY));
+ SUNXI_MMC_STATUS_FIFO_EMPTY))
+ ;
if (timeout <= 0)
goto out;
buff[i] = readl(mmchost->database);
@@ -328,7 +330,8 @@ static int mmc_trans_data_by_cpu(struct mmc *mmc, struct
mmc_data *data)
for (i = 0; i < (byte_cnt >> 2); i++) {
while (--timeout &&
(readl(&mmchost->reg->status) &
- SUNXI_MMC_STATUS_FIFO_FULL));
+ SUNXI_MMC_STATUS_FIFO_FULL))
+ ;
if (timeout <= 0)
goto out;
writel(buff[i], mmchost->database);
@@ -485,7 +488,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
goto out;
}
- cmdval |= SUNXI_MMC_CMD_DATA_EXPIRE |
SUNXI_MMC_CMD_WAIT_PRE_OVER;
+ cmdval |= SUNXI_MMC_CMD_DATA_EXPIRE|SUNXI_MMC_CMD_WAIT_PRE_OVER;
if (data->flags & MMC_DATA_WRITE)
cmdval |= SUNXI_MMC_CMD_WRITE;
if (data->blocks > 1)
--
1.8.5.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi.git 5/9] sunxi: mmc: refactor enabling/disable DMA accesses
And remove a magic number in the process.
Signed-off-by: Ian Campbell
---
arch/arm/include/asm/arch-sunxi/mmc.h | 1 +
drivers/mmc/sunxi_mmc.c | 18 ++
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 1c19f85..6385bc9 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -57,6 +57,7 @@ struct sunxi_mmc {
SUNXI_MMC_GCTRL_FIFO_RESET|\
SUNXI_MMC_GCTRL_DMA_RESET)
#define SUNXI_MMC_GCTRL_DMA_ENABLE (0x1 << 5)
+#define SUNXI_MMC_GCTRL_ACCESS_BY_AHB (0x1 << 31)
#define SUNXI_MMC_CMD_RESP_EXPIRE (0x1 << 6)
#define SUNXI_MMC_CMD_LONG_RESPONSE(0x1 << 7)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index d2a82bf..d520599 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -419,6 +419,18 @@ static int mmc_trans_data_by_dma(struct mmc *mmc, struct
mmc_data *data)
return 0;
}
+static void mmc_enable_dma_accesses(struct mmc *mmc, int dma)
+{
+ struct sunxi_mmc_host *mmchost = (struct sunxi_mmc_host *)mmc->priv;
+
+ unsigned int gctrl = readl(&mmchost->reg->gctrl);
+ if (dma)
+ gctrl &= ~SUNXI_MMC_GCTRL_ACCESS_BY_AHB;
+ else
+ gctrl |= SUNXI_MMC_GCTRL_ACCESS_BY_AHB;
+ writel(gctrl, &mmchost->reg->gctrl);
+}
+
static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
{
@@ -484,13 +496,11 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
if (0) {
#endif
usedma = 1;
- writel(readl(&mmchost->reg->gctrl) & ~(0x1 << 31),
- &mmchost->reg->gctrl);
+ mmc_enable_dma_accesses(mmc, 1);
ret = mmc_trans_data_by_dma(mmc, data);
writel(cmdval | cmd->cmdidx, &mmchost->reg->cmd);
} else {
- writel(readl(&mmchost->reg->gctrl) | 0x1 << 31,
- &mmchost->reg->gctrl);
+ mmc_enable_dma_accesses(mmc, 0);
writel(cmdval | cmd->cmdidx, &mmchost->reg->cmd);
ret = mmc_trans_data_by_cpu(mmc, data);
}
--
1.8.5.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi.git 8/9] sunxi: mmc: refactor similar wait loops
Signed-off-by: Ian Campbell
---
drivers/mmc/sunxi_mmc.c | 55 ++---
1 file changed, 29 insertions(+), 26 deletions(-)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 34c4996..a09e021 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -433,6 +433,25 @@ static void mmc_enable_dma_accesses(struct mmc *mmc, int
dma)
writel(gctrl, &mmchost->reg->gctrl);
}
+static int mmc_rint_wait(struct mmc *mmc, signed int timeout,
+unsigned int done_bit, const char *what)
+{
+ struct sunxi_mmc_host *mmchost = (struct sunxi_mmc_host *)mmc->priv;
+ unsigned int status;
+
+ do {
+ status = readl(&mmchost->reg->rint);
+ if (!timeout-- ||
+ (status & SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT)) {
+ debug("%s timeout %x\n", what,
+ status & SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT);
+ return TIMEOUT;
+ }
+ } while (!(status & done_bit));
+
+ return 0;
+}
+
static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
struct mmc_data *data)
{
@@ -514,36 +533,20 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
}
}
- timeout = 0xf;
- do {
- status = readl(&mmchost->reg->rint);
- if (!timeout-- ||
- (status & SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT)) {
- error = status & SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT;
- debug("cmd timeout %x\n", error);
- error = TIMEOUT;
- goto out;
- }
- } while (!(status & SUNXI_MMC_RINT_COMMAND_DONE));
+ error = mmc_rint_wait(mmc, 0xf, SUNXI_MMC_RINT_COMMAND_DONE, "cmd");
+ if (error)
+ goto out;
if (data) {
- unsigned done = 0;
timeout = usedma ? 0x * bytecnt : 0x;
debug("cacl timeout %x\n", timeout);
- do {
- status = readl(&mmchost->reg->rint);
- if (!timeout-- ||
- (status & SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT)) {
- error = status &
SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT;
- debug("data timeout %x\n", error);
- error = TIMEOUT;
- goto out;
- }
- if (data->blocks > 1)
- done = status &
SUNXI_MMC_RINT_AUTO_COMMAND_DONE;
- else
- done = status & SUNXI_MMC_RINT_DATA_OVER;
- } while (!done);
+ error = mmc_rint_wait(mmc, timeout,
+ data->blocks > 1 ?
+ SUNXI_MMC_RINT_AUTO_COMMAND_DONE :
+ SUNXI_MMC_RINT_DATA_OVER,
+ "data");
+ if (error)
+ goto out;
}
if (cmd->resp_type & MMC_RSP_BUSY) {
--
1.8.5.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi.git 7/9] sunxi: mmc: defines for status register
Objdump confirms no change to the resulting binary.
Signed-off-by: Ian Campbell
---
arch/arm/include/asm/arch-sunxi/mmc.h | 8
drivers/mmc/sunxi_mmc.c | 8 +---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 10bf214..97b14c3 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -105,6 +105,14 @@ struct sunxi_mmc {
SUNXI_MMC_RINT_COMMAND_DONE | \
SUNXI_MMC_RINT_VOLTAGE_CHANGE_DONE)
+#define SUNXI_MMC_STATUS_RXWL_FLAG (0x1 << 0)
+#define SUNXI_MMC_STATUS_TXWL_FLAG (0x1 << 1)
+#define SUNXI_MMC_STATUS_FIFO_EMPTY(0x1 << 2)
+#define SUNXI_MMC_STATUS_FIFO_FULL (0x1 << 3)
+#define SUNXI_MMC_STATUS_CARD_PRESENT (0x1 << 8)
+#define SUNXI_MMC_STATUS_CARD_DATA_BUSY(0x1 << 9)
+#define SUNXI_MMC_STATUS_DATA_FSM_BUSY (0x1 << 10)
+
#define SUNXI_MMC_IDMAC_RESET (0x1 << 0)
#define SUNXI_MMC_IDMAC_FIXBURST (0x1 << 1)
#define SUNXI_MMC_IDMAC_ENABLE (0x1 << 7)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index e67b3ce..34c4996 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -316,7 +316,8 @@ static int mmc_trans_data_by_cpu(struct mmc *mmc, struct
mmc_data *data)
buff = (unsigned int *)data->dest;
for (i = 0; i < (byte_cnt >> 2); i++) {
while (--timeout &&
-(readl(&mmchost->reg->status) & (0x1 << 2)));
+ (readl(&mmchost->reg->status) &
+ SUNXI_MMC_STATUS_FIFO_EMPTY));
if (timeout <= 0)
goto out;
buff[i] = readl(mmchost->database);
@@ -326,7 +327,8 @@ static int mmc_trans_data_by_cpu(struct mmc *mmc, struct
mmc_data *data)
buff = (unsigned int *)data->src;
for (i = 0; i < (byte_cnt >> 2); i++) {
while (--timeout &&
-(readl(&mmchost->reg->status) & (0x1 << 3)));
+ (readl(&mmchost->reg->status) &
+ SUNXI_MMC_STATUS_FIFO_FULL));
if (timeout <= 0)
goto out;
writel(buff[i], mmchost->database);
@@ -553,7 +555,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
error = TIMEOUT;
goto out;
}
- } while (status & (1 << 9));
+ } while (status & SUNXI_MMC_STATUS_CARD_DATA_BUSY);
}
if (cmd->resp_type & MMC_RSP_136) {
--
1.8.5.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi.git 4/9] sunxi: mmc: defines for mmc ctrl and cmd registers
Inferred from Linux driver.
Objdump confirms no change to the resulting binary.
Signed-off-by: Ian Campbell
---
arch/arm/include/asm/arch-sunxi/mmc.h | 11 ++
drivers/mmc/sunxi_mmc.c | 39 ---
2 files changed, 24 insertions(+), 26 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 5690c2c..1c19f85 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -58,6 +58,17 @@ struct sunxi_mmc {
SUNXI_MMC_GCTRL_DMA_RESET)
#define SUNXI_MMC_GCTRL_DMA_ENABLE (0x1 << 5)
+#define SUNXI_MMC_CMD_RESP_EXPIRE (0x1 << 6)
+#define SUNXI_MMC_CMD_LONG_RESPONSE(0x1 << 7)
+#define SUNXI_MMC_CMD_CHK_RESPONSE_CRC (0x1 << 8)
+#define SUNXI_MMC_CMD_DATA_EXPIRE (0x1 << 9)
+#define SUNXI_MMC_CMD_WRITE(0x1 << 10)
+#define SUNXI_MMC_CMD_AUTO_STOP(0x1 << 12)
+#define SUNXI_MMC_CMD_WAIT_PRE_OVER(0x1 << 13)
+#define SUNXI_MMC_CMD_SEND_INIT_SEQ(0x1 << 15)
+#define SUNXI_MMC_CMD_UPCLK_ONLY (0x1 << 21)
+#define SUNXI_MMC_CMD_START(0x1 << 31)
+
#define SUNXI_MMC_IDMAC_RESET (0x1 << 0)
#define SUNXI_MMC_IDMAC_FIXBURST (0x1 << 1)
#define SUNXI_MMC_IDMAC_ENABLE (0x1 << 7)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 73b891d..d2a82bf 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -227,12 +227,15 @@ static int mmc_update_clk(struct mmc *mmc)
unsigned int cmd;
unsigned timeout = 0xf;
- cmd = (0x1 << 31) | (0x1 << 21) | (0x1 << 13);
+ cmd = SUNXI_MMC_CMD_START |
+ SUNXI_MMC_CMD_UPCLK_ONLY |
+ SUNXI_MMC_CMD_WAIT_PRE_OVER;
writel(cmd, &mmchost->reg->cmd);
- while ((readl(&mmchost->reg->cmd) & (0x1 << 31)) && timeout--);
+ while ((readl(&mmchost->reg->cmd) & SUNXI_MMC_CMD_START) && timeout--);
if (!timeout)
return -1;
+ /* clock update sets various irq status bits, clear these */
writel(readl(&mmchost->reg->rint), &mmchost->reg->rint);
return 0;
@@ -420,7 +423,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
struct mmc_data *data)
{
struct sunxi_mmc_host *mmchost = (struct sunxi_mmc_host *)mmc->priv;
- unsigned int cmdval = 0x8000;
+ unsigned int cmdval = SUNXI_MMC_CMD_START;
signed int timeout = 0;
int error = 0;
unsigned int status = 0;
@@ -434,30 +437,14 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
if (cmd->cmdidx == 12)
return 0;
- /*
-* CMDREG
-* CMD[5:0] : Command index
-* CMD[6] : Has response
-* CMD[7] : Long response
-* CMD[8] : Check response CRC
-* CMD[9] : Has data
-* CMD[10] : Write
-* CMD[11] : Steam mode
-* CMD[12] : Auto stop
-* CMD[13] : Wait previous over
-* CMD[14] : About cmd
-* CMD[15] : Send initialization
-* CMD[21] : Update clock
-* CMD[31] : Load cmd
-*/
if (!cmd->cmdidx)
- cmdval |= (0x1 << 15);
+ cmdval |= SUNXI_MMC_CMD_SEND_INIT_SEQ;
if (cmd->resp_type & MMC_RSP_PRESENT)
- cmdval |= (0x1 << 6);
+ cmdval |= SUNXI_MMC_CMD_RESP_EXPIRE;
if (cmd->resp_type & MMC_RSP_136)
- cmdval |= (0x1 << 7);
+ cmdval |= SUNXI_MMC_CMD_LONG_RESPONSE;
if (cmd->resp_type & MMC_RSP_CRC)
- cmdval |= (0x1 << 8);
+ cmdval |= SUNXI_MMC_CMD_CHK_RESPONSE_CRC;
if (data) {
if ((u32) data->dest & 0x3) {
@@ -465,11 +452,11 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
goto out;
}
- cmdval |= (0x1 << 9) | (0x1 << 13);
+ cmdval |= SUNXI_MMC_CMD_DATA_EXPIRE |
SUNXI_MMC_CMD_WAIT_PRE_OVER;
if (data->flags & MMC_DATA_WRITE)
- cmdval |= (0x1 << 10);
+ cmdval |= SUNXI_MMC_CMD_WRITE;
if (data->blocks > 1)
- cmdval |= (0x1 << 12);
+ cmdval |= SUNXI_MMC_CMD_AUTO_STOP;
writel(data->blocksize, &mmchost->reg->blksz);
writel(data->blocks * data->blocksize, &mmchost->reg->bytecnt);
}
--
1.8.5.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi.git 6/9] sunxi: mmc: defines for rint register bits
Names from Linux driver
Signed-off-by: Ian Campbell
---
arch/arm/include/asm/arch-sunxi/mmc.h | 35 +++
drivers/mmc/sunxi_mmc.c | 19 +++
2 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 6385bc9..10bf214 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -70,6 +70,41 @@ struct sunxi_mmc {
#define SUNXI_MMC_CMD_UPCLK_ONLY (0x1 << 21)
#define SUNXI_MMC_CMD_START(0x1 << 31)
+#define SUNXI_MMC_RINT_RESP_ERROR (0x1 << 1)
+#define SUNXI_MMC_RINT_COMMAND_DONE(0x1 << 2)
+#define SUNXI_MMC_RINT_DATA_OVER (0x1 << 3)
+#define SUNXI_MMC_RINT_TX_DATA_REQUEST (0x1 << 4)
+#define SUNXI_MMC_RINT_RX_DATA_REQUEST (0x1 << 5)
+#define SUNXI_MMC_RINT_RESP_CRC_ERROR (0x1 << 6)
+#define SUNXI_MMC_RINT_DATA_CRC_ERROR (0x1 << 7)
+#define SUNXI_MMC_RINT_RESP_TIMEOUT(0x1 << 8)
+#define SUNXI_MMC_RINT_DATA_TIMEOUT(0x1 << 9)
+#define SUNXI_MMC_RINT_VOLTAGE_CHANGE_DONE (0x1 << 10)
+#define SUNXI_MMC_RINT_FIFO_RUN_ERROR (0x1 << 11)
+#define SUNXI_MMC_RINT_HARD_WARE_LOCKED(0x1 << 12)
+#define SUNXI_MMC_RINT_START_BIT_ERROR (0x1 << 13)
+#define SUNXI_MMC_RINT_AUTO_COMMAND_DONE (0x1 << 14)
+#define SUNXI_MMC_RINT_END_BIT_ERROR (0x1 << 15)
+#define SUNXI_MMC_RINT_SDIO_INTERRUPT (0x1 << 16)
+#define SUNXI_MMC_RINT_CARD_INSERT (0x1 << 30)
+#define SUNXI_MMC_RINT_CARD_REMOVE (0x1 << 31)
+#define SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT \
+ (SUNXI_MMC_RINT_RESP_ERROR |\
+SUNXI_MMC_RINT_RESP_CRC_ERROR |\
+SUNXI_MMC_RINT_DATA_CRC_ERROR |\
+SUNXI_MMC_RINT_RESP_TIMEOUT | \
+SUNXI_MMC_RINT_DATA_TIMEOUT | \
+SUNXI_MMC_RINT_VOLTAGE_CHANGE_DONE | \
+SUNXI_MMC_RINT_FIFO_RUN_ERROR |\
+SUNXI_MMC_RINT_HARD_WARE_LOCKED | \
+SUNXI_MMC_RINT_START_BIT_ERROR | \
+SUNXI_MMC_RINT_END_BIT_ERROR) /* 0xbfc2 */
+#define SUNXI_MMC_RINT_INTERRUPT_DONE_BIT \
+ (SUNXI_MMC_RINT_AUTO_COMMAND_DONE | \
+SUNXI_MMC_RINT_DATA_OVER | \
+SUNXI_MMC_RINT_COMMAND_DONE | \
+SUNXI_MMC_RINT_VOLTAGE_CHANGE_DONE)
+
#define SUNXI_MMC_IDMAC_RESET (0x1 << 0)
#define SUNXI_MMC_IDMAC_FIXBURST (0x1 << 1)
#define SUNXI_MMC_IDMAC_ENABLE (0x1 << 7)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index d520599..e67b3ce 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -505,7 +505,8 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
ret = mmc_trans_data_by_cpu(mmc, data);
}
if (ret) {
- error = readl(&mmchost->reg->rint) & 0xbfc2;
+ error = readl(&mmchost->reg->rint) & \
+ SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT;
error = TIMEOUT;
goto out;
}
@@ -514,13 +515,14 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
timeout = 0xf;
do {
status = readl(&mmchost->reg->rint);
- if (!timeout-- || (status & 0xbfc2)) {
- error = status & 0xbfc2;
+ if (!timeout-- ||
+ (status & SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT)) {
+ error = status & SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT;
debug("cmd timeout %x\n", error);
error = TIMEOUT;
goto out;
}
- } while (!(status & 0x4));
+ } while (!(status & SUNXI_MMC_RINT_COMMAND_DONE));
if (data) {
unsigned done = 0;
@@ -528,16 +530,17 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
debug("cacl timeout %x\n", timeout);
do {
status = readl(&mmchost->reg->rint);
- if (!timeout-- || (status & 0xbfc2)) {
- error = status & 0xbfc2;
+ if (!timeout-- ||
+ (status & SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT)) {
+ error = status &
SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT;
debug("data timeout %x\n", error);
error = TIMEOUT;
goto out;
}
if (data->blocks > 1)
- done = status & (0x1 << 14);
+ done = status &
SUNXI_MMC_RINT_AUTO_COMMAND_DONE;
else
-
[linux-sunxi] [PATCH u-boot-sunxi.git 2/9] sunxi: mmc: defines for various mmc control bits
Mostly derived from existing comments. There are plenty of undefined bits still
though.
Objdump confirms that the resulting binary is identical.
Signed-off-by: Ian Campbell
---
arch/arm/include/asm/arch-sunxi/mmc.h | 19 ++
drivers/mmc/sunxi_mmc.c | 49 ---
2 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 354103d..5690c2c 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -46,5 +46,24 @@ struct sunxi_mmc {
u32 fifo; /* (0x100) SMC FIFO Access Address */
};
+#define SUNXI_MMC_CLK_POWERSAVE(0x1 << 17)
+#define SUNXI_MMC_CLK_ENABLE (0x1 << 16)
+#define SUNXI_MMC_CLK_DIVIDER_MASK (0xff)
+
+#define SUNXI_MMC_GCTRL_SOFT_RESET (0x1 << 0)
+#define SUNXI_MMC_GCTRL_FIFO_RESET (0x1 << 1)
+#define SUNXI_MMC_GCTRL_DMA_RESET (0x1 << 2)
+#define SUNXI_MMC_GCTRL_RESET (SUNXI_MMC_GCTRL_SOFT_RESET|\
+SUNXI_MMC_GCTRL_FIFO_RESET|\
+SUNXI_MMC_GCTRL_DMA_RESET)
+#define SUNXI_MMC_GCTRL_DMA_ENABLE (0x1 << 5)
+
+#define SUNXI_MMC_IDMAC_RESET (0x1 << 0)
+#define SUNXI_MMC_IDMAC_FIXBURST (0x1 << 1)
+#define SUNXI_MMC_IDMAC_ENABLE (0x1 << 7)
+
+#define SUNXI_MMC_IDIE_TXIRQ (0x1 << 0)
+#define SUNXI_MMC_IDIE_RXIRQ (0x1 << 1)
+
int sunxi_mmc_init(int sdc_no);
#endif /* _SUNXI_MMC_H */
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index b6f2f96..c336c70 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -242,25 +242,20 @@ static int mmc_config_clock(struct mmc *mmc, unsigned div)
struct sunxi_mmc_host *mmchost = (struct sunxi_mmc_host *)mmc->priv;
unsigned rval = readl(&mmchost->reg->clkcr);
- /*
-* CLKCREG[7:0]: divider
-* CLKCREG[16]: on/off
-* CLKCREG[17]: power save
-*/
/* Disable Clock */
- rval &= ~(0x1 << 16);
+ rval &= ~SUNXI_MMC_CLK_ENABLE;
writel(rval, &mmchost->reg->clkcr);
if (mmc_update_clk(mmc))
return -1;
/* Change Divider Factor */
- rval &= ~(0xff);
+ rval &= ~SUNXI_MMC_CLK_DIVIDER_MASK;
rval |= div;
writel(rval, &mmchost->reg->clkcr);
if (mmc_update_clk(mmc))
return -1;
/* Re-enable Clock */
- rval |= (0x1 << 16);
+ rval |= SUNXI_MMC_CLK_ENABLE;
writel(rval, &mmchost->reg->clkcr);
if (mmc_update_clk(mmc))
@@ -300,7 +295,7 @@ static int mmc_core_init(struct mmc *mmc)
struct sunxi_mmc_host *mmchost = (struct sunxi_mmc_host *)mmc->priv;
/* Reset controller */
- writel(0x7, &mmchost->reg->gctrl);
+ writel(SUNXI_MMC_GCTRL_RESET, &mmchost->reg->gctrl);
return 0;
}
@@ -397,32 +392,21 @@ static int mmc_trans_data_by_dma(struct mmc *mmc, struct
mmc_data *data)
flush_cache((unsigned long)pdes,
sizeof(struct sunxi_mmc_des) * (des_idx + 1));
- /*
-* GCTRLREG
-* GCTRL[2] : DMA reset
-* GCTRL[5] : DMA enable
-*
-* IDMACREG
-* IDMAC[0] : IDMA soft reset
-* IDMAC[1] : IDMA fix burst flag
-* IDMAC[7] : IDMA on
-*
-* IDIECREG
-* IDIE[0] : IDMA transmit interrupt flag
-* IDIE[1] : IDMA receive interrupt flag
-*/
rval = readl(&mmchost->reg->gctrl);
/* Enable DMA */
- writel(rval | (0x1 << 5) | (0x1 << 2), &mmchost->reg->gctrl);
+ writel(rval | SUNXI_MMC_GCTRL_DMA_RESET | SUNXI_MMC_GCTRL_DMA_ENABLE,
+ &mmchost->reg->gctrl);
/* Reset iDMA */
- writel((0x1 << 0), &mmchost->reg->dmac);
+ writel(SUNXI_MMC_IDMAC_RESET, &mmchost->reg->dmac);
/* Enable iDMA */
- writel((0x1 << 1) | (1 << 7), &mmchost->reg->dmac);
- rval = readl(&mmchost->reg->idie) & (~3);
+ writel(SUNXI_MMC_IDMAC_FIXBURST | SUNXI_MMC_IDMAC_ENABLE,
+ &mmchost->reg->dmac);
+ rval = readl(&mmchost->reg->idie) &
+ ~(SUNXI_MMC_IDIE_TXIRQ|SUNXI_MMC_IDIE_RXIRQ);
if (data->flags & MMC_DATA_WRITE)
- rval |= (0x1 << 0);
+ rval |= SUNXI_MMC_IDIE_TXIRQ;
else
- rval |= (0x1 << 1);
+ rval |= SUNXI_MMC_IDIE_RXIRQ;
writel(rval, &mmchost->reg->idie);
writel((u32) pdes, &mmchost->reg->dlba);
writel((0x2 << 28) | (0x7 << 16) | (0x01 << 3),
@@ -598,15 +582,16 @@ out:
writel(status, &mmchost->reg->idst);
writel(0, &mmchost->reg->idie);
writel(0, &mmchost->reg->dmac);
- writel(readl(&mmchost->reg->gctrl) & ~(0x1 << 5),
+ writel(readl(&mmchost->reg->gctrl) &
[linux-sunxi] [PATCH u-boot-sunxi.git 3/9] sunxi: mmc: defines for clock bits
Objdump confirms no difference in the resulting binary.
Signed-off-by: Ian Campbell
---
arch/arm/include/asm/arch-sunxi/clock.h | 7 +++
drivers/mmc/sunxi_mmc.c | 5 +++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
b/arch/arm/include/asm/arch-sunxi/clock.h
index b6184dc..ef03d5b 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -161,6 +161,7 @@ struct sunxi_ccm_reg {
#define AHB_GATE_OFFSET_MMC2 10
#define AHB_GATE_OFFSET_MMC1 9
#define AHB_GATE_OFFSET_MMC0 8
+#define AHB_GATE_OFFSET_MMC(n) (AHB_GATE_OFFSET_MMC0 + (n))
#define AHB_GATE_OFFSET_BIST 7
#define AHB_GATE_OFFSET_DMA6
#define AHB_GATE_OFFSET_SS 5
@@ -222,6 +223,12 @@ struct sunxi_ccm_reg {
#define CCM_MBUS_CTRL_CLK_SRC_PLL5 0x2
#define CCM_MBUS_CTRL_GATE (0x1 << 31)
+#define CCM_MMC_CTRL_OSCM24 (0x0 << 24)
+#define CCM_MMC_CTRL_PLL6 (0x1 << 24)
+#define CCM_MMC_CTRL_PLL5 (0x2 << 24)
+
+#define CCM_MMC_CTRL_ENABLE (0x1 << 31)
+
#define CCM_GMAC_CTRL_TX_CLK_SRC_MII 0x0
#define CCM_GMAC_CTRL_TX_CLK_SRC_EXT_RGMII 0x1
#define CCM_GMAC_CTRL_TX_CLK_SRC_INT_RGMII 0x2
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index c336c70..73b891d 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -200,7 +200,7 @@ static int mmc_clk_io_on(int sdc_no)
/* config ahb clock */
rval = readl(&ccm->ahb_gate0);
- rval |= (1 << (8 + sdc_no));
+ rval |= 1 << AHB_GATE_OFFSET_MMC(sdc_no);
writel(rval, &ccm->ahb_gate0);
/* config mod clock */
@@ -209,7 +209,8 @@ static int mmc_clk_io_on(int sdc_no)
divider = 4;
else
divider = 3;
- writel((0x1 << 31) | (0x2 << 24) | divider, mmchost->mclkreg);
+ writel(CCM_MMC_CTRL_ENABLE | CCM_MMC_CTRL_PLL5 | divider,
+ mmchost->mclkreg);
mmchost->mod_clk = pll5_clk / (divider + 1);
dumphex32("ccmu", (char *)SUNXI_CCM_BASE, 0x100);
--
1.8.5.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi.git 1/9] sunxi: mmc: add braces to remove ambiguity
Signed-off-by: Ian Campbell
---
Cleanup due to upstream review.
---
drivers/mmc/sunxi_mmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 80e4369..b6f2f96 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -279,11 +279,12 @@ static void mmc_set_ios(struct mmc *mmc)
/* Change clock first */
clkdiv = (mmchost->mod_clk + (mmc->clock >> 1)) / mmc->clock / 2;
- if (mmc->clock)
+ if (mmc->clock) {
if (mmc_config_clock(mmc, clkdiv)) {
mmchost->fatal_err = 1;
return;
}
+ }
/* Change bus width */
if (mmc->bus_width == 8)
--
1.8.5.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi.git 0/9] sunxi: mmc: removal of magic numbers
The following patches remove the majority of the magic numbers from the mmc driver, as part of the preparation for upstreaming. The names/meanings of the various bits are partially inferred from existing comments and partially from the Linux driver. Also a little refactoring and checkpatch cleanups. Most of the patches have been confirmed with objdump to make no difference the resulting drivers/mmc/sunxi_mmc.o. I've also tested on cubietruck. Ian. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH u-boot-sunxi.git] sunxi: setup environment so initrd and fdt are relocated to safe addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/20/2014 04:24 PM, Ian Campbell wrote: > Instead of setting CONFIG_SYS_BOOTMAPSZ instead set bootm_size to 512M in the > default environment. This causes boot_start_lmb to use addresses which are > covered by the kernels lowmem mapping, which is required by the boot protocol. > > This should mean that workarounds such as fdt_high= and > initrd_high= are no longer required. > > Signed-off-by: Ian Campbell > Cc: Tom Rini > --- > include/configs/sunxi-common.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index efa77f2..2757145 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -102,7 +102,6 @@ > > /* Flat Device Tree (FDT/DT) support */ > #define CONFIG_OF_LIBFDT > -#define CONFIG_SYS_BOOTMAPSZ (256 << 20) > > /* > * Miscellaneous configurable options > @@ -170,6 +169,7 @@ > #endif > > #define CONFIG_EXTRA_ENV_SETTINGS \ > + "bootm_size=0x2000\0" \ > "console=ttyS0,115200\0" \ > "panicarg=panic=10\0" \ > "extraargs=\0" \ > Acked-by: Tom Rini - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTK2LZAAoJENk4IS6UOR1WrwoQAJefaXgIUNdZkIofsH25sfnr Z8IXx02X7WnI92R2dkkLjU1akKsZrSPE7C4cDXGbtOReE5ii1AJoBU/2010BX1k1 brH2yNayD4pXUEzhZhJuh+AkBB7JXe9NdTlO9Pr5ry3Hk1ONjcQlkXVQ+h1vzLLc aymJ2NK6WbxGfNPA4uC6/kqiIYidI2NKoluyHZmH5qD+TB1yDUF7Xem95foJSl3N XFlkyHpBt3+bJBaSBgJIx74GEz3asqK6FveqkY+x0BeZ8NQXF5IUtGiiNFG9CQCI LTKJrm3v6aaSmdzmP+vFj0u6JT3bUcvIk2Q8mt5N5aCp41IjhqSMdTVp2oso6PI6 2mWLsVrywHT4LN8BR8abXX2Y44kwJbX3VI3UkTOsuvktxoQw95klpK8PCkPe74cC BAsgWnIIQOx2Yjpzr3AreQn9vkmkJZHF7Fq0/0vTSycYdOGzTeBtIm61xfdX/8xW dxgnTFxTdX4zyuYO5wGrbBRn6LyC7Bnu+GW5YfleE8yVKHKyGxP9PnjfeZ4n6f5l yzgLeYfs5YtAnyI6ZV1sqCxETrvan4kCUOeaindu10WmbySojLzfVk3g9Ov+RquO KkfZR8utV3qoVjht7oxHILwxKOHd+BjI4tpf4gJxEDP+T8s7U2iFzN55JHsGdj4P sq9dweAOJ/8C4ivgezTb =2Vt2 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi.git] sunxi: dram: checkpatch.pl cleanups
Mainly whitespace. The main construct which it complains about is:
while(POKE THE HARDWARE);
which obscures the potentially infinite loop, I've rewritten as:
while(POKE THE HARDWARE)
;
Signed-off-by: Ian Campbell
---
Normally I object to this sort of churn but this is so that the patches
submitted upstream can be checkpatch clean.
---
arch/arm/cpu/armv7/sunxi/dram.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram.c b/arch/arm/cpu/armv7/sunxi/dram.c
index 9348a5e..957db59 100644
--- a/arch/arm/cpu/armv7/sunxi/dram.c
+++ b/arch/arm/cpu/armv7/sunxi/dram.c
@@ -179,7 +179,7 @@ static u32 hpcr_value[32] = {
* 0x1031, 0x0301, 0x0301, 0x0731
* but boot0 code skips #28 and #30, and sets #29 and #31 to the
* value from #28 entry (0x1031)
- */
+*/
#endif
};
@@ -271,7 +271,8 @@ static int dramc_scan_readpipe(void)
setbits_le32(&dram->ccr, DRAM_CCR_DATA_TRAINING);
/* check whether data training process has completed */
- while (readl(&dram->ccr) & DRAM_CCR_DATA_TRAINING);
+ while (readl(&dram->ccr) & DRAM_CCR_DATA_TRAINING)
+ ;
/* check data training result */
reg_val = readl(&dram->csr);
@@ -548,7 +549,8 @@ unsigned long dramc_init(struct dram_para *para)
udelay(1);
- while (readl(&dram->ccr) & DRAM_CCR_INIT);
+ while (readl(&dram->ccr) & DRAM_CCR_INIT)
+ ;
mctl_enable_dllx(para->tpr3);
@@ -604,7 +606,8 @@ unsigned long dramc_init(struct dram_para *para)
#endif
/* reset external DRAM */
setbits_le32(&dram->ccr, DRAM_CCR_INIT);
- while (readl(&dram->ccr) & DRAM_CCR_INIT);
+ while (readl(&dram->ccr) & DRAM_CCR_INIT)
+ ;
#ifdef CONFIG_SUN7I
/* setup zq calibration manual */
@@ -620,25 +623,29 @@ unsigned long dramc_init(struct dram_para *para)
/* exit self-refresh state */
clrsetbits_le32(&dram->dcr, 0x1f << 27, 0x12 << 27);
/* check whether command has been executed */
- while (readl(&dram->dcr) & (0x1 << 31));
+ while (readl(&dram->dcr) & (0x1 << 31))
+ ;
udelay(2);
/* dram pad hold off */
setbits_le32(&dram->ppwrsctl, 0x1651);
- while (readl(&dram->ppwrsctl) & 0x1);
+ while (readl(&dram->ppwrsctl) & 0x1)
+ ;
/* exit self-refresh state */
clrsetbits_le32(&dram->dcr, 0x1f << 27, 0x12 << 27);
/* check whether command has been executed */
- while (readl(&dram->dcr) & (0x1 << 31));
- udelay(2);;
+ while (readl(&dram->dcr) & (0x1 << 31))
+ ;
+ udelay(2);
/* issue a refresh command */
clrsetbits_le32(&dram->dcr, 0x1f << 27, 0x13 << 27);
- while (readl(&dram->dcr) & (0x1 << 31));
+ while (readl(&dram->dcr) & (0x1 << 31))
+ ;
udelay(2);
}
--
1.8.5.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi.git] sunxi: setup environment so initrd and fdt are relocated to safe addresses
Instead of setting CONFIG_SYS_BOOTMAPSZ instead set bootm_size to 512M in the default environment. This causes boot_start_lmb to use addresses which are covered by the kernels lowmem mapping, which is required by the boot protocol. This should mean that workarounds such as fdt_high= and initrd_high= are no longer required. Signed-off-by: Ian Campbell Cc: Tom Rini --- include/configs/sunxi-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index efa77f2..2757145 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -102,7 +102,6 @@ /* Flat Device Tree (FDT/DT) support */ #define CONFIG_OF_LIBFDT -#define CONFIG_SYS_BOOTMAPSZ (256 << 20) /* * Miscellaneous configurable options @@ -170,6 +169,7 @@ #endif #define CONFIG_EXTRA_ENV_SETTINGS \ + "bootm_size=0x2000\0" \ "console=ttyS0,115200\0" \ "panicarg=panic=10\0" \ "extraargs=\0" \ -- 1.8.5.3 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [U-Boot] [PATCH v1 8/9] sunxi: non-FEL SPL boot support for sun7i
On Mon, 2014-03-17 at 15:33 -0400, Tom Rini wrote: > > So, I'm confused about what to do here ;-) > > And I've not made things clearer with a mis-recollection of things. I > don't know why I keep saying "bootm_low" when I mean "bootm_size" like > I've done in later patches (and thankfully, when poking people on G+). Ah, making that substitution makes things make a lot more sense! > There's three ways to say "Please ensure that the FDT and if passed initrd > do not relocate above a certain location". > 1) In the environment, set bootm_size to kernel lowmem. This means that > boot_start_lmb restricts the pool used by both fdt and initrd to that > value at the top. > 2) In the environment, set fdt_high (and if using initrd, initrd_high) > to the top of lowmem. This means that we'll make sure they don't get > relocated above that value. > 3) In the environment set initrd_high to top of lowmem and set > bootm_mapsize to lowmem. Looking at http://patchwork.ozlabs.org/patch/329210/ it seems that you went for #1 on TI stuff -- so I am going to follow suite. > In all of the above, lowmem can be replaced with any valid size that's > also smaller than lowmem, such as 256MB. 256MB sounds like a good value to be starting with. > Another option, in the > environment, is to set initrd_high and fdt_high to 0x and then > relocation is disabled. I would _not_ recommend this in the general > case as one of the points of relocation is to ensure we don't get > overwritten by the kernel BSS. Sure. Thanks, Ian. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v7 3/3] ARM: sun7i/sun6i: irqchip: Update the documentation
On Wed, Mar 19, 2014 at 08:21:19PM +0100, Carlo Caione wrote: > Added documentation for NMI irqchip. > > Signed-off-by: Carlo Caione Acked-by: Maxime Ripard -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v7 2/3] ARM: sun7i/sun6i: dts: Add NMI irqchip support
On Wed, Mar 19, 2014 at 08:21:18PM +0100, Carlo Caione wrote: > This patch adds DTS entries for NMI controller as child of GIC. > > Signed-off-by: Carlo Caione Acked-by: Maxime Ripard Thanks! -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 2/2] v1 ARM: sun4i: spi: Allow Tx transfers larger than FIFO size
On Wed, Mar 19, 2014 at 01:23:34PM -0500, mrnuke wrote: > > > /* Enable the interrupts */ > > > > > > - sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, SUN4I_INT_CTL_TC | > > > - SUN4I_INT_CTL_RF_F34); > > > + reg = SUN4I_INT_CTL_TC | SUN4I_INT_CTL_RF_F34; > > > + /* Only enable Tx FIFO interrupt if we really need it */ > > > + if (tx_len > SUN4I_FIFO_DEPTH) > > > + reg |= SUN4I_INT_CTL_TF_E34; > > > + sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, reg); > > > > I'd be much dumber than that. Why don't you just enable both > > interrupts all the time if we need larger transfers ? > > > SUN4I_INT_CTL_TF_E34 will trigger whenever the Tx FIFO has 16 bytes or less. > There are 2 cases where this is relevant: > > (a) We have a Tx transaction with a length less than the FIFO size. We start > the transaction, and SUN4I_INT_CTL_TF_E34 gets triggered somewhere along the > way. We enter the interrupt handler, see that sspi->len is 0, and disable > this > interrupt. Well, it wouldn't be triggered, since you wouldn't have enabled it. But it would be in the status register. > (b) We have a long Rx-only transaction. We start the transaction, and > SUN4I_INT_CTL_TF_E34 gets triggered right away, as our Tx buffer is empty. We > enter the handler, see that sspi->len is not zero, so we leave the interrupt > enabled. Exit the IRQ handler, and we're right back servicing the same > interrupt. Ah, yes. That one is nasty. > Case (a) only costs us an extra interrupt, whereas case (b) will cause an IRQ > storm, and essentially loop-brick the kernel. I think the current check is > the > simplest of the alternatives. It's also why I wanted to separate the Tx part > in a separate patch. This interrupt is tricky. I guess your suggestion of adding an enabled interrupt mask makes sense then, just to avoid handling status that we don't care for in the case of a spurious interrupt. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 1/2] v1 ARM: sun4i: spi: Allow Rx transfers larger than FIFO size
On Wed, Mar 19, 2014 at 01:03:45PM -0500, mrnuke wrote:
> > > - /* We don't support transfer larger than the FIFO */
> > > - if (tfr->len > SUN4I_FIFO_DEPTH)
> > > + if (tfr->len > SUN4I_MAX_XFER_SIZE)
> > > + return -EINVAL;
> >
> > Why do you still need this test?
> >
> SUN4I_MAX_XFER_SIZE is not the FIFO size. It is the max number we can write
> in
> SUN4I_BURST_CNT_REG. That's the maximum SPI burst size (16 MiB - 1) that the
> hardware supports. Anything larger, and we'd need to break up the transfer in
> several bursts. That's a different problem than the one I'm addressing.
Ok, it makes sense.
> > > + /* Receive FIFO 3/4 full */
> > > + if (status & SUN4I_INT_CTL_RF_F34) {
> > > + sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
> > > + /* Only clear the interrupt _after_ draining the FIFO */
> > > + sun4i_spi_write(sspi, SUN4I_INT_STA_REG,
> > > SUN4I_INT_CTL_RF_F34);
> >
> > Not that it's important, but it really doesn't matter to do it before
> > or after, the interrupts are disabled in the handler.
> >
> I think this was one of those bits that keeps being set by hardware until the
> Rx FIFO is under 48 bytes (less than 3/4 full). I'll have to look into this
> again.
Ok, it would deserve to be in the comments then :)
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [linux-sunxi] CSI driver problems in 16bit mode + some successful debug
Got it - instead of V4L2_PIX_FMT_YUV422P, CSI format needs to be set to
V4L2_PIX_FMT_NV16. Also display needs to set as:
format: DISP_FORMAT_YUV422
mode: DISP_MOD_NON_MB_UV_COMBINED
seq: DISP_SEQ_UVUV
works like a charm :)
On Thursday, March 20, 2014 10:08:15 AM UTC+1, Ivan Kozic wrote:
>
> This sunxi HW/SW/Docu combo is a complete mess. There's one more thing
> specific to YUV422 16bit capture - memory alignment is a bit different than
> when using 8bit capture. In fact, up to now, I've been using planar
> capture, which in turn means that Y, U and V components are stored into
> separate buffers (planes) => 3 addresses are generated, one for each
> buffer. So for example memory would look like:
>
> 0x10: Frame 1 Y plane
> 0x20: Frame 1 U plane
> 0x30: Frame 1 V plane
> 0x40: Frame 2 Y plane
> ...
>
> However, for 16bit capture when using the same CSI setting, I get
> UV_combined subcase - Y is stored in one buffer/plane, while U/V is stored
> in the other (so one plane for both U and V) => 2 addresses are generated.
> Memory:
>
> 0x10: Frame 1 Y plane
> 0x20: Frame 1 U/V plane
> 0x30: Frame 2 Y plane
> ...
>
> Admittedly, my fixes are quite dirty and some things might not really be
> optimal in my kernel (V4L MBUS codes are completely wrong for instance),
> but I still think that this alignment is one of the undocumented things by
> Allwinner - this alignment is set via CSI_CONF register - OUTPUT_FMT bits,
> but YUV422 16bit is not even mentioned here, so...
>
> Anyway, the reason that I'm mentioning this is that display driver needs
> correct info about alignment to work properly - I'm still trying out stuff
> here, since there is no SW user manual on how to properly use display
> ioctls in case of UV combined mode, but I don't think it will be a big
> issue to start it up correctly. Will post back when I get it right.
>
> On Tuesday, March 18, 2014 8:56:22 AM UTC+1, Ivan Kozic wrote:
>>
>> Cool, I was under the impression that VPU is quite messy to start on
>> these Allwinners - I'll probably have a follow-up project where I would use
>> VPU as well, so it's very good that someone's got it working.
>> Just wanted to say that it would be good to check the register settings
>> for VPU, but in fact I cannot find any registers for VPU in the User
>> Manual...
>>
>>
>> On Mon, Mar 17, 2014 at 6:36 PM, jonsm...@gmail.com
>> wrote:
>>
>>> Yes, the kernel source is inside the Android SDK downloads. I can send
>>> you files if you need them so that you don't have to install the 4.2GB
>>> thing.
>>>
>>> I was able to get my camera working. I then got stuck on the h.264
>>> encoder. The encoder works but it is not compressing enough. No matter
>>> what parameters I give it the output stream is still 5-10Mb/s. I need
>>> a stream less than 1Mb/s.
>>>
>>> On Mon, Mar 17, 2014 at 12:19 PM, Ivan Kozic wrote:
>>> > One more update - it seems that the error comes from me :) - I've used
>>> bad
>>> > multiplex options for d8..d15 pins (should be 5, but copy-paste from
>>> CSI1
>>> > made it 3 - standard copy-paste mistake...).
>>> > Anyway, all the other fixes that I've posted should be implemented, as
>>> it
>>> > will not work without them. Only the last one is my fault.
>>> >
>>> >
>>> > On Monday, March 17, 2014 4:53:46 PM UTC+1, Ivan Kozic wrote:
>>> >>
>>> >> Very happy to say that I've got it :)
>>> >>
>>> >> The solution is actually very simple - DMA seems to work just fine,
>>> the
>>> >> problem is with GPIOs - even though we initialize fex file with
>>> >> csi_d0..csi_d15, it seems that only settings for d0..d7 are applied.
>>> >> For quick check, I've modified csi_probe function found in
>>> sun4i_drv_csi.c
>>> >> like this:
>>> >>
>>> >> /*pin resource*/
>>> >> dev->csi_pin_hd = gpio_request_ex("csi0_para",NULL);
>>> >> if (dev->csi_pin_hd==-1) {
>>> >> csi_err("csi0 pin request error!\n");
>>> >> ret = -ENXIO;
>>> >> goto err_irq;
>>> >> }
>>> >>
>>> >> // IKfix - override pin muxing just in case
>>> >> writel(0x, 0xf1c20800+0x90);// this is really just in
>>> >> case, as PE PIO group works
>>> >> writel(0x, 0xf1c20800+0x94);// this is really just in
>>> >> case, as PE PIO group works
>>> >> writel(0x, 0xf1c20800+0xd8);// this is for PG PIO
>>> group -
>>> >> configure PG gpios as CSI0
>>> >> writel(0x, 0xf1c20800+0xdc);// this is for PG PIO
>>> group -
>>> >> configure PG gpios as CSI0
>>> >>
>>> >> Basically, just after the gpio_request_ex() has finished its work (by
>>> the
>>> >> way, this function should have already did this, but for some reason
>>> it
>>> >> didn't), I added a few lines of just-in-case configuration. First two
>>> are
>>> >> for lower 8 bits (d0..d7) - these are really just in case, as I've
>>> >> previously verified that it works. Second two are for upper 8 bits
>>> >> (d8..d15), and this is the culprit - gpio_request_ex should have
>>> already
[linux-sunxi] [PATCH] i2c-sunxi: use standard mode I2C speed of 100 kbit/s for I2C[1-4]
Standard mode I2C speed is 100 kbit/s and should be used instead of
200 kbit/s which is non-standard.
Signed-off-by: Jonathan Liu
---
arch/arm/plat-sunxi/include/plat/i2c.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-sunxi/include/plat/i2c.h
b/arch/arm/plat-sunxi/include/plat/i2c.h
index be8fe41..d75347b 100644
--- a/arch/arm/plat-sunxi/include/plat/i2c.h
+++ b/arch/arm/plat-sunxi/include/plat/i2c.h
@@ -194,10 +194,10 @@ Foscl is clock SCL;standard mode:100KHz or fast
mode:400KHz
#define TWI4_BASE_ADDR_END(TWI4_BASE_ADDR_START + AW_TWI_ADDR_SIZE)
#define I2C0_TRANSFER_SPEED (40)
-#define I2C1_TRANSFER_SPEED (20)
-#define I2C2_TRANSFER_SPEED (20)
-#define I2C3_TRANSFER_SPEED (20)
-#define I2C4_TRANSFER_SPEED (20)
+#define I2C1_TRANSFER_SPEED (10)
+#define I2C2_TRANSFER_SPEED (10)
+#define I2C3_TRANSFER_SPEED (10)
+#define I2C4_TRANSFER_SPEED (10)
struct sunxi_i2c_platform_data {
int bus_num;
--
1.9.0
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v6 04/18] ahci-platform: Add support for devices with more then 1 clock
On 19/02/14 15:52, Tejun Heo wrote:
On Wed, Feb 19, 2014 at 01:01:46PM +0100, Hans de Goede wrote:
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 434ab89..aaa0c08 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -87,6 +87,44 @@ static struct scsi_host_template ahci_platform_sht = {
AHCI_SHT("ahci_platform"),
};
+
+int ahci_platform_enable_clks(struct ahci_host_priv *hpriv)
Throughout the series, there are mixtures of one and two blank lines
in front of functions, let's just do one consistently. Also, can you
please add proper function comments on top of the exported functions?
+{
+ int c, rc;
+
+ for (c = 0; c < AHCI_MAX_CLKS && hpriv->clks[c]; c++) {
+ rc = clk_prepare_enable(hpriv->clks[c]);
+ if (rc)
+ goto disable_unprepare_clk;
+ }
+ return 0;
+
+disable_unprepare_clk:
+ while (--c >= 0)
+ clk_disable_unprepare(hpriv->clks[c]);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(ahci_platform_enable_clks);
+
+void ahci_platform_disable_clks(struct ahci_host_priv *hpriv)
+{
+ int c;
+
+ for (c = AHCI_MAX_CLKS - 1; c >= 0; c--)
+ if (hpriv->clks[c])
+ clk_disable_unprepare(hpriv->clks[c]);
+}
+EXPORT_SYMBOL_GPL(ahci_platform_disable_clks);
+
+
+static void ahci_put_clks(struct ahci_host_priv *hpriv)
+{
+ int c;
+
+ for (c = 0; c < AHCI_MAX_CLKS && hpriv->clks[c]; c++)
+ clk_put(hpriv->clks[c]);
+}
Urgh, clk can't do devm? ahci_platform itself should be able to build
devmized interface using devres_alloc() or devm_add_action().
Eh maybe later.
There is devm_clk_get()
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Auxtek-004 booting problems
Hi Emilio, I tested the settings you advised and it worked like a charm! Also I have updated the "Manual build specifics" with this information. Thanks to you all for your help! El miércoles, 19 de marzo de 2014 19:39:53 UTC+1, Emilio López escribió: > > Hi there, > > El 19/03/14 14:14, Daniel Mosquera escribió: > > Hi, > > > > I have built the kernel directly using sun5i_defconfig, but it refuses > > to boot. > > I have tested with the last uboot and with the Fedora R18 uboot provided > > by Hans de Goede, > > and in both cases Hans' image boots but the one built with > > sun5i_defconfig doesn't boot. > > Can you try with sun5i_defconfig, with EARLY_PRINTK enabled and > SW_DEBUG_UART configured to 0, and passing earlyprintk on your bootargs? > > Cheers, > > Emilio > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CSI driver problems in 16bit mode + some successful debug
This sunxi HW/SW/Docu combo is a complete mess. There's one more thing
specific to YUV422 16bit capture - memory alignment is a bit different than
when using 8bit capture. In fact, up to now, I've been using planar
capture, which in turn means that Y, U and V components are stored into
separate buffers (planes) => 3 addresses are generated, one for each
buffer. So for example memory would look like:
0x10: Frame 1 Y plane
0x20: Frame 1 U plane
0x30: Frame 1 V plane
0x40: Frame 2 Y plane
...
However, for 16bit capture when using the same CSI setting, I get
UV_combined subcase - Y is stored in one buffer/plane, while U/V is stored
in the other (so one plane for both U and V) => 2 addresses are generated.
Memory:
0x10: Frame 1 Y plane
0x20: Frame 1 U/V plane
0x30: Frame 2 Y plane
...
Admittedly, my fixes are quite dirty and some things might not really be
optimal in my kernel (V4L MBUS codes are completely wrong for instance),
but I still think that this alignment is one of the undocumented things by
Allwinner - this alignment is set via CSI_CONF register - OUTPUT_FMT bits,
but YUV422 16bit is not even mentioned here, so...
Anyway, the reason that I'm mentioning this is that display driver needs
correct info about alignment to work properly - I'm still trying out stuff
here, since there is no SW user manual on how to properly use display
ioctls in case of UV combined mode, but I don't think it will be a big
issue to start it up correctly. Will post back when I get it right.
On Tuesday, March 18, 2014 8:56:22 AM UTC+1, Ivan Kozic wrote:
>
> Cool, I was under the impression that VPU is quite messy to start on these
> Allwinners - I'll probably have a follow-up project where I would use VPU
> as well, so it's very good that someone's got it working.
> Just wanted to say that it would be good to check the register settings
> for VPU, but in fact I cannot find any registers for VPU in the User
> Manual...
>
>
> On Mon, Mar 17, 2014 at 6:36 PM, jonsm...@gmail.com wrote:
>
>> Yes, the kernel source is inside the Android SDK downloads. I can send
>> you files if you need them so that you don't have to install the 4.2GB
>> thing.
>>
>> I was able to get my camera working. I then got stuck on the h.264
>> encoder. The encoder works but it is not compressing enough. No matter
>> what parameters I give it the output stream is still 5-10Mb/s. I need
>> a stream less than 1Mb/s.
>>
>> On Mon, Mar 17, 2014 at 12:19 PM, Ivan Kozic wrote:
>> > One more update - it seems that the error comes from me :) - I've used
>> bad
>> > multiplex options for d8..d15 pins (should be 5, but copy-paste from
>> CSI1
>> > made it 3 - standard copy-paste mistake...).
>> > Anyway, all the other fixes that I've posted should be implemented, as
>> it
>> > will not work without them. Only the last one is my fault.
>> >
>> >
>> > On Monday, March 17, 2014 4:53:46 PM UTC+1, Ivan Kozic wrote:
>> >>
>> >> Very happy to say that I've got it :)
>> >>
>> >> The solution is actually very simple - DMA seems to work just fine, the
>> >> problem is with GPIOs - even though we initialize fex file with
>> >> csi_d0..csi_d15, it seems that only settings for d0..d7 are applied.
>> >> For quick check, I've modified csi_probe function found in
>> sun4i_drv_csi.c
>> >> like this:
>> >>
>> >> /*pin resource*/
>> >> dev->csi_pin_hd = gpio_request_ex("csi0_para",NULL);
>> >> if (dev->csi_pin_hd==-1) {
>> >> csi_err("csi0 pin request error!\n");
>> >> ret = -ENXIO;
>> >> goto err_irq;
>> >> }
>> >>
>> >> // IKfix - override pin muxing just in case
>> >> writel(0x, 0xf1c20800+0x90);// this is really just in
>> >> case, as PE PIO group works
>> >> writel(0x, 0xf1c20800+0x94);// this is really just in
>> >> case, as PE PIO group works
>> >> writel(0x, 0xf1c20800+0xd8);// this is for PG PIO
>> group -
>> >> configure PG gpios as CSI0
>> >> writel(0x, 0xf1c20800+0xdc);// this is for PG PIO
>> group -
>> >> configure PG gpios as CSI0
>> >>
>> >> Basically, just after the gpio_request_ex() has finished its work (by
>> the
>> >> way, this function should have already did this, but for some reason it
>> >> didn't), I added a few lines of just-in-case configuration. First two
>> are
>> >> for lower 8 bits (d0..d7) - these are really just in case, as I've
>> >> previously verified that it works. Second two are for upper 8 bits
>> >> (d8..d15), and this is the culprit - gpio_request_ex should have
>> already did
>> >> this, as it's in the fex file and a correct number of gpios is
>> reported (for
>> >> my config - 22).
>> >>
>> >> One problem solved.
>> >>
>> >> I would have figured out gpios last week, but something in the kernel
>> is
>> >> not letting me access PIO registers via /dev/mem from userland - I
>> always
>> >> get seg faults when trying to access PIO base (0xf1c20800) and all the
>> >> subsequent registers. As I thought DMA is
Re: [linux-sunxi] Possible G2D kernel bug
For testing purposes, setting timeout=500 has the effect, that OSD stops flickering, but instead of the correct image, only a black area with OSD dimensions is displayed. "wait g2d irq pending flag timeout" still is there. I also applied https://github.com/amery/linux-sunxi/commit/7015bbb75ac57b , no knowing, what it is doing due to lack of register documentation. Has no positive effect, too. So no positive feedback so far. Regards Andreas Am 05.03.2014 20:32, schrieb Andreas Baierl: Am 04.03.2014 11:56, schrieb Andreas Baierl: Hi all, it seems, that the G2D kernel driver has some issue: libvdpau-sunxi uses G2D_CMD_BITBLT for creating surfaces, so at the end of mixer_blt, there is g2d_wait_cmd_finish() called. As soon as (timeout==0) gets TRUE in https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/char/sunxi_g2d/g2d.c#L120 , g2d stops working. It's not possible to interact with /dev/g2d anymore until you reboot (or possibly un-/reload the module). I'm not sure how to exactly reproduce that. It mostly occurs the second time i start VDR with libvdpau-sunxi and OSD. Regards rellla I don't know if it's related to the above, but unloading the kernel module g2d_23 after it stopped working with the "wait g2d irq pending flag timeout" message shows me the following log: [ 735.058259] [DISP] layer allocated: 0,102 [ 735.065332] [DISP] layer allocated: 0,103 [ 735.227857] wait g2d irq pending flag timeout [ 783.215100] [DISP] layer released: 0,102 [ 783.222385] [DISP] layer released: 0,103 [ 792.500779] [DISP] layer released: 0,101 [ 792.541549] UMP<2>: Session closed [ 795.070534] G2D: g2d_module_exit [ 795.080032] G2D: Driver unloaded succesfully. [ 795.092261] [ cut here ] [ 795.105471] WARNING: at drivers/base/core.c:196 device_release+0x78/0x84() [ 795.122342] Device 'g2d' does not have a release() function, it is broken and must be fixed. [ 795.135209] Modules linked in: disp_ump mali_drm drm g2d_23(-) sunxi_cedar_mod sw_ahci_platform mali ump [ 795.162378] [] (unwind_backtrace+0x0/0x138) from [] (warn_slowpath_common+0x4c/0x64) [ 795.183234] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_fmt+0x30/0x40) [ 795.203586] [] (warn_slowpath_fmt+0x30/0x40) from [] (device_release+0x78/0x84) [ 795.223412] [] (device_release+0x78/0x84) from [] (kobject_release+0x98/0x1bc) [ 795.244079] [] (kobject_release+0x98/0x1bc) from [] (g2d_module_exit+0x34/0x68 [g2d_23]) [ 795.266065] [] (g2d_module_exit+0x34/0x68 [g2d_23]) from [] (sys_delete_module+0x1ac/0x28c) [ 795.287740] [] (sys_delete_module+0x1ac/0x28c) from [] (ret_fast_syscall+0x0/0x30) [ 795.304222] ---[ end trace ec0a564270cd7879 ]--- rellla -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
