gmane.linux.ports.arm.kernel

Re: AT91SAM9260 I2C Driver

Elyas Razzaghi — 2013-05-21T22:36:52

Hello,

I have decided to use the PCA9665 I2C controller on my AT91RM9200 custom 
board. Could you help me with my board specific code to initialize the 
driver? How should I modify the code for PCA(I2C) part of my 
arch/arm/mach-at91/board-xxx.c file?

Best regards,
Elyas

On 2007-08-07 11:26, Michel Benoit wrote:
 > Hello Alex,
 >
 > I've cc'ed this email to the linux-arm-kernel list.
 >
 > > I too have decided to use the PCA9564 I2C controller, as the on-chip
 > > TWI controller was too buggy. I'm now trying to utilize the PCA9564
 > > driver included in 2.6.21, but am having some trouble figuring out how
 > > to use it. Would you mind answering a few questions for me?
 > >
 > > First off, I've included the PCA driver (not the ISA version) in my
 > > kernel using the menu configuration (not as a loadable module, but
 > > included it directly in the kernel), but I can't find anything in the
 > > running kernel that lets me know it has been included, except that the
 > > directory "/sys/bus/platform/drivers

Re: [PATCH] arm: mvebu: enable two USB interfaces on the Armada XP GP board

Jason Cooper — 2013-05-21T22:32:50

Applied to mvebu/dt

thx,

Jason.

Re: [PATCH] ARM: Kirkwood: TS219: Fix crash by double PCIe instantiation

Jason Cooper — 2013-05-21T22:27:44

Applied to mvebu/fixes

thx,

Jason.

[PATCH] v2 rtc-at91rm9200: add support for at91sam9x5

Douglas Gilbert — 2013-05-21T22:21:07

An unspecified number of SoCs from the Atmel's
at91sam9x5 family including the at91sam9g25 have a
broken AT91_RTC_IMR (interrupt mask) register which
always returns zero.

If this bug can be neutralized, then the existing
rtc-at91rm9200 driver will work. On the other hand,
leaving this bug in place, and starting the RTC
causes unhandled interrupts which result in the
"SYS" interrupt being disabled. And that takes down
several other interrupts wired or-ed through the
SYS interrupt including the DBG port.

This is the second version of this patch, and is
against lk 3.10.0-rc2 .

ChangeLog:
    - checks in probe() function if AT91_RTC_IMR is broken.
      If so, uses a shadow imr
    - apart from that check, SoCs with a good IMR register
      take the same paths through rtc-at91rm9200.c as before
    - SoCs with a broken IMR take a spinlock while changing
      the state of IER or IDR (and the shadow), mainly to
      disable interrupts **.

** similar technique used in arch/arm/mach-at91/clock.c

Tested on an

Re: [PATCH 0/9] Switch internal registers address to 0xF1 on Armada 370/XP

Willy Tarreau — 2013-05-21T20:26:01

OK, thank you for these precisions.

Best regards,
Willy

Re: [PATCH 0/9] Switch internal registers address to 0xF1 on Armada 370/XP

Thomas Petazzoni — 2013-05-21T20:12:35

Dear Willy Tarreau,

On Tue, 21 May 2013 21:38:03 +0200, Willy Tarreau wrote:


On Armada 370/XP, it hangs the CPU.


Answered above: it hangs.


No, as explained above, we have considered a way of "detecting" whether
the remapping occurred, or to unconditionally do the remapping. But
none of those solutions work: we need to know, through some external
mechanism, whether the remapping has already taken place or not.

Best regards,

Thomas

Re: [PATCH 0/9] Switch internal registers address to 0xF1 on Armada 370/XP

Willy Tarreau — 2013-05-21T19:38:03

Hi Thomas,

On Tue, May 21, 2013 at 12:33:25PM +0200, Thomas Petazzoni wrote:
(...)

Just out of curiosity, what happens if you touch the register at the
wrong address ? I mean, if you blindly write to the 0xD0xxxxxx address
that you want the registers to be mapped at 0xF1xxxxxx. Will the chip
hang, will it silently ignore the sequence ? Because maybe you don't
need to detect using CP15 whether the remapping was done, you could
simply perform it unconditionally. Another point would be that if the
boot loader is the only one to know whether the registeres were remapped,
then maybe it could put something into the atags or DT about this. And
maybe we'll simply find that DT-enabled boot loaders are remapped and
that non-DT ones are not.

Just a few ideas since you feel a bit worried about the fragility of
the CP15 bit :-)

Willy

Re: [PATCH] ARM: iomux-mx51: Always define PUE for pins used as GPIO

Sascha Hauer — 2013-05-21T19:24:30

I don't understand. If there's an external pullup why do you want to
turn on the internal one?

Sascha

Re: [PATCH 14/14] ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions

Rob Herring — 2013-05-21T18:48:35

On Mon, May 20, 2013 at 9:18 AM, Catalin Marinas
<catalin.marinas< at >arm.com> wrote:

How does userspace know whether to install a non-LPAE or LPAE kernel
in a generic way?

Rob

[PATCH 1/3] ARM: ux500: Enable MMC_UNSAFE_RESUME

Ulf Hansson — 2013-05-21T09:46:14

Enable CONFIG_MMC_UNSAFE_RESUME to be accomplish a proper
suspend/resume cycle for SD/SDIO/(e)MMC.

Signed-off-by: Ulf Hansson <ulf.hansson< at >linaro.org>
---
 arch/arm/configs/u300_defconfig  |    1 +
 arch/arm/configs/u8500_defconfig |    1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/configs/u300_defconfig b/arch/arm/configs/u300_defconfig
index 374000e..c839375 100644
--- a/arch/arm/configs/u300_defconfig
+++ b/arch/arm/configs/u300_defconfig
< at >< at > -51,6 +51,7 < at >< at > CONFIG_BACKLIGHT_CLASS_DEVICE=y
 # CONFIG_HID_SUPPORT is not set
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
+CONFIG_MMC_UNSAFE_RESUME=y
 CONFIG_MMC_CLKGATE=y
 CONFIG_MMC_ARMMMCI=y
 CONFIG_RTC_CLASS=y
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index c037aa1..f9e3f38 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
< at >< at > -82,6 +82,7 < at >< at > CONFIG_REGULATOR_GPIO=y
 CONFIG_USB_GADGET=y
 CONFIG_AB8500_USB=y
 CONFIG_MMC=y
+CONFIG_MMC_UNSAFE_RESUME=y
 CONFIG_MMC_CLKGATE=y
 C

RE: hugetlbfs support plan for ARM

Karicheri, Muralidharan — 2013-05-21T12:24:32

Steve, Bill and Will

Thanks all for the response. So I understand this will get merged eventually to a future kernel version. If this is true, I would like to pull in the latest and give it a try on our Cortex A15 SMP ARM platform. We haven't upstream-ed this machine, but have plan to do so this year. I am on 3.8.4 kernel currently (due to dependency with RT Preempt patch) and will start using this patch and let you know the feedback.  BTW, do you see any issues with using this patch with RT Preempt kernel patch and also on A15 SMP kernel?

Thanks

Murali Karicheri
Software Design Engineer



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

Re: [PATCH 14/14] ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions

Will Deacon — 2013-05-21T18:02:01

I don't think it *can* be a feature of the CPU, because it depends on
system-wide support. It could be a feature of an SoC, but per-SoC hwcaps
isn't something we currently support. As I said, the only reason we can even
probe this is because the architecture helps us out.


Argh! :)

Will

[PATCH 6/9] arm: mvebu: move cache and mvebu-mbus initialization later

Thomas Petazzoni — 2013-05-21T10:33:31

Current, the L2 cache and the mvebu-mbus drivers are initialized at
->init_early() time. However, at ->init_early() time, ioremap() only
works if a static I/O mapping has already been put in place. If it's
not the case, it tries to do a memory allocation with kmalloc() which
is not possible so early at this stage of the initialization.

Since we want to get rid of the static I/O mapping, we cannot
initialize the L2 cache driver and the mvebu-mbus driver so early. So,
we move their initialization to the ->init_time() level, which is
slightly later (so ioremap() works properly), but sufficiently early
to be before the call of the ->smp_prepare_cpus() hook, which creates
an address decoding window for the BootROM, which requires the
mvebu-mbus driver to be properly initialized.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni< at >free-electrons.com>
---
 arch/arm/mach-mvebu/armada-370-xp.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-mvebu/armada-3

[PATCH 1/9] arm: mvebu: fix length of SATA registers area in .dtsi

Thomas Petazzoni — 2013-05-21T10:33:26

The length of the registers area for the Marvell 370/XP SATA
controller was incorrect in the .dtsi: 0x2400 while it should have
been 0x5000. Until now, this problem wasn't noticed because there was
a large static mapping for all I/Os set up by ->map_io(). But since
we're going to get rid of this static mapping, we need to ensure that
the register areas are properly sized.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni< at >free-electrons.com>
---
 arch/arm/boot/dts/armada-370-xp.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 272bbc6..75de3fe 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
< at >< at > -79,7 +79,7 < at >< at >
 
 sata< at >a0000 {
 compatible = "marvell,orion-sata";
-reg = <0xa0000 0x2400>;
+reg = <0xa0000 0x5000>;
 interrupts = <55>;
 clocks = <&gateclk 15>, <&gateclk 30>;
 clock-names = "0", "1";

[PATCH v2 2/3] staging: drm/imx: fix spelling error for vsync flag config

Markus Niebel — 2013-05-21T18:04:06

From: Markus Niebel <Markus.Niebel< at >tqs.de>

partial fix of changes from
"staging: drm/imx: Add support for VGA via TVE on i.MX53"

Have to check for vsync_pin instead of hsync_pin to set Vsync_pol.

Signed-off-by: Markus Niebel <Markus.Niebel< at >tqs.de>
Acked-by: Philipp Zabel <p.zabel< at >pengutronix.de>
---
V2:
  - no changes in patch
  - add Acked-by from v1 of patch

 drivers/staging/imx-drm/ipu-v3/ipu-di.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-di.c b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
index 19d777e..e7b9c98 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
< at >< at > -614,11 +614,11 < at >< at > int ipu_di_init_sync_panel(struct ipu_di *di, struct ipu_di_signal_cfg *sig)
 di_gen |= DI_GEN_POLARITY_7;
 }
 if (sig->Vsync_pol) {
-if (sig->hsync_pin == 3)
+if (sig->vsync_pin == 3)
 di_gen |= DI_GEN_POLARITY_3;
-else if (sig->hsync_pin == 6)
+else if (sig->vsync_pin == 6)
 di_gen

[PATCH v2 3/3] staging: drm/imx: revert vsync_cnt for di->id 1

Markus Niebel — 2013-05-21T18:04:07

From: Markus Niebel <Markus.Niebel< at >tqs.de>

partial fix of changes from
"staging: drm/imx: Add support for VGA via TVE on i.MX53"

parallel display support / DVI needs the original setting to work

Signed-off-by: Markus Niebel <Markus.Niebel< at >tqs.de>
Acked-by: Philipp Zabel <p.zabel< at >pengutronix.de>
---
V2:
  - no changes in patch
  - add Acked-by from v1 of patch

 drivers/staging/imx-drm/ipu-v3/ipu-di.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-di.c b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
index e7b9c98..0b6806e 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-di.c
+++ b/drivers/staging/imx-drm/ipu-v3/ipu-di.c
< at >< at > -603,7 +603,12 < at >< at > int ipu_di_init_sync_panel(struct ipu_di *di, struct ipu_di_signal_cfg *sig)
 
 vsync_cnt = 3;
 if (di->id == 1)
-vsync_cnt = 6;
+/*
+ * TODO: change only for TVEv2, parallel display
+ * uses pin 2 / 3
+ */
+if (!(sig->hsync_pin == 2 && sig->vsync_pin == 3))
+vsync_cnt = 6;
 
 if (sig-

[PATCH v2 0/3] staging: fix parallel display regressions

Markus Niebel — 2013-05-21T18:04:04

From: Markus Niebel <Markus.Niebel< at >tqs.de>

Support for VGA via TVE on i.MX53 causes regressions, which prevents
parallel display from working. This series brings the parallel display
functionality back.

The updated series was tested with 3.10-rc2 on a TQMa53 module with
modified device tree.

Markus Niebel (3):
  staging: drm/imx: set correct sync pins for display
  staging: drm/imx: fix spelling error for vsync flag config
  staging: drm/imx: revert vsync_cnt for di->id 1

 drivers/staging/imx-drm/imx-drm-core.c  |    2 +-
 drivers/staging/imx-drm/ipu-v3/ipu-di.c |   13 +++++++++----
 2 files changed, 10 insertions(+), 5 deletions(-)

[PATCH v2 1/3] staging: drm/imx: set correct sync pins for display

Markus Niebel — 2013-05-21T18:04:05

From: Markus Niebel <Markus.Niebel< at >tqs.de>

partial fix of changes from
"staging: drm/imx: Add support for VGA via TVE on i.MX53"

Have to call imx_drm_crtc_panel_format_pins in imx_drm_crtc_panel_format
with the correct pins instead of (0, 0) This enables configuration of
correct waveforms for vsync / hsync for parallel display, LDB (i.MX53 and
i.MX6) as well as HDMI and MIPI (i.MX6)

TODO: configure pins via device tree

Signed-off-by: Markus Niebel <Markus.Niebel< at >tqs.de>
---
V2:
  changed patch as suggested by Philipp Zabel. This will
  fix regressions for other interfaces, too

 drivers/staging/imx-drm/imx-drm-core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/imx-drm/imx-drm-core.c b/drivers/staging/imx-drm/imx-drm-core.c
index 6455305..8c433fc 100644
--- a/drivers/staging/imx-drm/imx-drm-core.c
+++ b/drivers/staging/imx-drm/imx-drm-core.c
< at >< at > -144,7 +144,7 < at >< at > int imx_drm_crtc_panel_format(struct drm_crtc *crtc, u32 encoder_type,
 u32 interface_pix_fmt)
 {
 r

[PATCH] arm: mvebu: enable two USB interfaces on the Armada XP GP board

Thomas Petazzoni — 2013-05-21T17:53:09

The Armada XP GP board has two USB slots: one on the front side and
one on the back side. This commit enables the two USB host controllers
that correspond to those wo USB slots.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni< at >free-electrons.com>
---
 arch/arm/boot/dts/armada-xp-gp.dts |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-gp.dts b/arch/arm/boot/dts/armada-xp-gp.dts
index 26ad06f..f63426e 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
< at >< at > -101,6 +101,16 < at >< at >
 phy-mode = "rgmii-id";
 };
 
+/* Front-side USB slot */
+usb< at >50000 {
+status = "okay";
+};
+
+/* Back-side USB slot */
+usb< at >51000 {
+status = "okay";
+};
+
 spi0: spi< at >10600 {
 status = "okay";

[PATCH] ARM: Kirkwood: TS219: Fix crash by double PCIe instantiation

Andrew Lunn — 2013-05-21T17:41:48

When creating the DT based boards-ts219.c the none DT ts219-setup.c
was used as a template. This includes a lateinit() call to initialize
the PCIe bus. The code makes use of machine_is_ts219() which is never
true on DT, so a FIXME was added and the code left as is. This was
unproblematic until b73690c8f8b5d: "ARM: Kirkwood: Support basic
hotplug for PCI-E" which changes the way the PCIe bus is
initialized. The non-DT ts219-setup.c now crashes during boot.  The
lateinit() call in the DT boards-ts219.c is being called,
machine_is_ts219() is true and so the PCIe is initialized a second
time.

This patch removes the useless, and now clearly dangerous, code from
boards-ts219.c, making ts219-setup.c work again.

Signed-off-by: Andrew Lunn <andrew< at >lunn.ch>
---
This can also be tagged for stable 3.9

 arch/arm/mach-kirkwood/board-ts219.c |   10 ----------
 1 file changed, 10 deletions(-)

diff --git a/arch/arm/mach-kirkwood/board-ts219.c b/arch/arm/mach-kirkwood/board-ts219.c
index acb0187..4695d5f 100644
--- a/arch

[PATCH 0/9] Switch internal registers address to 0xF1 on Armada 370/XP

Thomas Petazzoni — 2013-05-21T10:33:25

Hello,

The aim of this patch series is to move the internal registers space
of the Armada 370 and Armada XP support to 0xf1000000 instead of
0xd0000000, and prepare for the support of the new versions of U-Boot
installed by Marvell on Armada 370 and XP platforms that boot the
kernel with the internal registers space already mapped at 0xf1000000.

Before reading the patches, and especially the last one, please read
on for a description of the problem and the proposed solution. The
solution has been carefully thought of, and all the details explained
below are important to understand how the proposed solution was
designed.

On Marvell EBU SoCs, including earlier families such as Kirkwood or
Dove, all the peripheral registers belong to a memory window of 1 MB,
called the "internal registers window". This window of physical memory
can be freely moved to an arbitrary physical address. At reset, this
memory window is at 0xD0000000, but it can be changed by software to
another address if needed.

The *very* import