Re: [PATCH v5 REPOST 1/5] ARM: l2x0/pl310: Refactor Kconfig to be more maintainable

On Fri, Dec 16, 2011 at 5:35 PM, Dave Martin <dave.martin <at> linaro.org> wrote:

> Making CACHE_L2X0 depend on (huge list of MACH_ and ARCH_ configs)
> is bothersome to maintain and likely to lead to merge conflicts.
(...)
>
> Signed-off-by: Dave Martin <dave.martin <at> linaro.org>
> Acked-by: Anton Vorontsov <cbouatmailru <at> gmail.com>
>        (for cns3xxx)
> Acked-by: Tony Lindgren <tony <at> atomide.com>
>        (for omap)
> Acked-by: Shawn Guo <shawn.guo <at> linaro.org>
>        (for imx)

Acked-by: Linus Walleij <linus.walleij <at> linaro.org>
(for ux500)

Yours,
Linus Walleij

Re: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings

On Tue, Dec 20, 2011 at 6:40 PM, Dong Aisheng <b29396 <at> freescale.com> wrote:

> From: Dong Aisheng <dong.aisheng <at> linaro.org>
>
> This patch provies a common API for driver to use to register pinmux
> mappings from dts file. It is needed for dt support.

Overall I feel lost in this discussion due to limited exposure to
device tree concepts. If I get Stephen Warrens and one of the
DT people's (Rob, Grant) ACK on this I'll be happy to merge it.

Until then, I guess it will need to be refined for the next kernel
cycle.

Yours,
Linus Walleij

Re: [PATCH v2] MTD/GPMI bugfix : reset the BCH module when it is not MX23

On Sat, Dec 31, 2011 at 10:43 AM, Wolfram Sang <w.sang <at> pengutronix.de> wrote:
> Hi,
>
> On Sat, Dec 31, 2011 at 10:23:50AM +0800, Huang Shijie wrote:
>
>> > On Fri, Dec 30, 2011 at 04:27:26PM +0800, Huang Shijie wrote:
>> >> In MX28, if we do not reset the BCH module. The BCH module may
>> >> becomes unstable when the board reboots for several thousands times.
>> > Do you have more details when and why this happens? What happens on MX23 then?
>> In one customer's 3G router which uses the MX28:
>> [0] NAND boot mode, mount the UBIFS in the NAND partition.
>> [1] We used the gpmi_reset_block(r->bch_regs, true) to init the BCH module.
>> [2] The board will automatically reboot again after it booted by NAND
>> boot mode.
>> [3] After reboot more then thousands times(cost nearly one day), the BCH
>> mode became UNSTABLE,
>> the data read out was not right, so the system could not mount the UBIFS.
>>
>> After we use gpmi_reset_block(r->bch_regs, false) to init the BCH
>> module, the bug never happens.
>
> Yes, I undestood that. I was curious _why_ this happens, for example, because
> of a bug in the rom-code or such. This would then lead to the question if this

This happens because we do NOT follow the right init procedure. The IC
guy told me.
If the BCH was not initialized correctly, it can not guarantees the
data is right.
This is why the mx28 failed.

Re: Renaming MACH_TYPE_KINETIS_K60 into MACH_TYPE_KINETIS

On 12/28/2011 04:51 AM, Alexander Potashev wrote:
> On Wed, 2011-12-28 at 11:00 +0100, Marek Vasut wrote:
>> If you use FDT, you won't need machine ID at all. 
> 
> Hi Marek,
> 
> You are right, but we have not used FDT for any of our ARM Linux ports
> yet (consistency matters.) If we switch to FDT now, a lot of code will
> need to be rewritten.

Not if you are only talking about the machine identification. You need a
minimal dts file with a compatible string for the board and add this
string to your machine desc.

DT is a requirement for adding any new ARM platform.

Rob

Re: [PATCH v2] MTD/GPMI bugfix : reset the BCH module when it is not MX23

Hi,

> This happens because we do NOT follow the right init procedure. The IC
> guy told me.
> If the BCH was not initialized correctly, it can not guarantees the
> data is right.
> This is why the mx28 failed.
...
> For mx23, it should not reset the BCH, this is the right init
> procedure for mx23.

Okay, this was the information I was looking for. So, the MX23 cannot be reset
due to bug #2847. But it also does not NEED to be reset, which is unlike the
MX28 which needs the reset. Correct? Before that, it was only clear that MX23
cannot be reset. It was not clear (at least to me) if it still could then run
into the same problems as the MX28 after 10000+x boot cycles. That would be a
really bad situation: being in need of the reset which we can't do due to 2847.

> But I did not ever boot 10000 times on mx23. I am not sure if it can
> fail or not.

Hmm, can't your IC guy tell you? I was hoping he knows if the same problem which
happens on the MX28 can also happen on the MX23? I don't want to make your life
unnecessarily hard, but I'd really like to know if I need to warn customers
when using MX23 and NAND (and if so, we have to update the comment in the code).

> > bug 2847, we have a serious problem, because NAND won't work until the next
> > power-cycle? I am curious if my assumptions are true and we have a serious
> > problem on the MX23.
> You can test it if you have time. :)

Circular dependency between <linux/kernel.h> and <asm/bug.h> on ARM

Commit 87e040b6456fd3416a1f6831c1eedaef5c0a94ff ("ARM: 7017/1: Use
generic BUG() handler") makes BUG() use BUILD_BUG_ON().  However,
BUILD_BUG_ON() is not defined in <linux/bug.h> but in <linux/kernel.h>.

arch/include/asm/bug.h does not include <linux/kernel.h> and *cannot* do
so because the latter already includes <asm/bug.h>.

Maybe BUILD_BUG_ON() should be moved out to a header of its own, or else
this particular use should be moved to some other file.  This needs to
be fixed somehow, as it obviously leads to build failures, e.g.:

https://buildd.debian.org/status/fetch.php?pkg=linux-2.6&arch=armel&ver=3.2~rc7-1~experimental.1&stamp=1325142904

Ben.

--

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel <at> lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC][PATCH 4/4] lcd: platform-lcd: Add device tree support

Add device tree based initialization for Hydis hv070wsa lcd panel.

Cc: Ben Dooks <ben-linux <at> fluff.org>
Signed-off-by: Thomas Abraham <thomas.abraham <at> linaro.org>
---
 drivers/video/backlight/platform_lcd.c |   33 ++++++++++++++++++++++++++++++++
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/drivers/video/backlight/platform_lcd.c b/drivers/video/backlight/platform_lcd.c
index feb4fd0..ebdddfd 100644
--- a/drivers/video/backlight/platform_lcd.c
+++ b/drivers/video/backlight/platform_lcd.c
 <at>  <at>  -18,6 +18,8  <at>  <at> 
 #include <linux/lcd.h>
 #include <linux/slab.h>
 #include <linux/gpio.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>

 #include <video/platform_lcd.h>

 <at>  <at>  -81,9 +83,18  <at>  <at>  static struct lcd_ops platform_lcd_ops = {
 	.check_fb	= platform_lcd_match,
 };

+static const struct of_device_id platform_lcd_dt_match[];
+
 static inline struct plat_lcd_driver_data *platform_lcd_get_driver_data(
 			struct platform_device *pdev)
 {

[PATCH] ARM: include linux/kernel.h in asm/bug.h

__BUG() has a dependency on BUILD_BUG_ON() which comes from
include/linux/kernel.h. Found with mini2440_defconfig:

In file included from include/linux/mtd/qinfo.h:4:0,
                 from include/linux/mtd/pfow.h:7,
                 from drivers/mtd/lpddr/lpddr_cmds.c:27:
include/linux/mtd/map.h: In function 'inline_map_read':
include/linux/mtd/map.h:408:3: error: implicit declaration of function 'BUILD_BUG_ON' [-Werror=implicit-function-declaration]

Signed-off-by: Olof Johansson <olof <at> lixom.net>
---
 arch/arm/include/asm/bug.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
index 9abe7a0..0291594 100644
--- a/arch/arm/include/asm/bug.h
+++ b/arch/arm/include/asm/bug.h
 <at>  <at>  -1,6 +1,7  <at>  <at> 
 #ifndef _ASMARM_BUG_H
 #define _ASMARM_BUG_H

+#include <linux/kernel.h>

 #ifdef CONFIG_BUG

--

-- 
1.7.8.GIT

snowball does not compile on linux-next

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

the kernel does not compile when
CONFIG_CLKSRC_DBX500_PRCMU_SCHED_CLOCK is set.

it fails with :

  CHK     include/linux/version.h
  CHK     include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  CC      drivers/clocksource/clksrc-dbx500-prcmu.o
drivers/clocksource/clksrc-dbx500-prcmu.c:61: warning: type defaults
to ?int? in declaration of ?DEFINE_CLOCK_DATA?
drivers/clocksource/clksrc-dbx500-prcmu.c:61: warning: parameter names
(without types) in function declaration
drivers/clocksource/clksrc-dbx500-prcmu.c: In function ?sched_clock?:
drivers/clocksource/clksrc-dbx500-prcmu.c:72: error: implicit
declaration of function ?cyc_to_sched_clock?
drivers/clocksource/clksrc-dbx500-prcmu.c:72: error: ?cd? undeclared
(first use in this function)
drivers/clocksource/clksrc-dbx500-prcmu.c:72: error: (Each undeclared
identifier is reported only once
drivers/clocksource/clksrc-dbx500-prcmu.c:72: error: for each function
it appears in.)

[PATCH 1/2] dmaengine: Fix status handling in imx-dma.

Status must only be changed to DMA_IN_PROGRESS
when the DMA transfer has really begun.

However, since this driver lacks of support for
multiple descriptors a new flag has to be introduced
to avoid the prepare function be called multiple times.

Signed-off-by: Javier Martin <javier.martin <at> vista-silicon.com>
---
 drivers/dma/imx-dma.c |   22 +++++++++++++++-------
 1 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index d99f71c..9a0ac14 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
 <at>  <at>  -43,6 +43,7  <at>  <at>  struct imxdma_channel {
 	enum dma_status			status;
 	int				dma_request;
 	struct scatterlist		*sg_list;
+	bool				prepared;
 };

 #define MAX_DMA_CHANNELS 8
 <at>  <at>  -72,6 +73,7  <at>  <at>  static void imxdma_irq_handler(int channel, void *data)

 	imxdmac->status = DMA_SUCCESS;
 	imxdma_handle(imxdmac);
+	imxdmac->prepared = false;
 }