* [PATCH] ARM: dts: add mshc controller node for Exynos4x12 SoCs
From: Dongjin Kim @ 2013-01-23 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADoNuNcF3oVEN3y-j4cxu2YLK0+YXLfCOAs1mU9jL2-Gbi98RA@mail.gmail.com>
Tested-by: Dongjin Kim <tobetter@gmail.com>
This patch had been tested on v3.8-rc4 with ODROID-X hardware.
On Wed, Jan 23, 2013 at 2:21 PM, Dongjin Kim <tobetter@gmail.com> wrote:
> Hello Thomas,
>
> Thank you. I will submit the change soon.
>
> Thanks again.
> Dongjin.
>
> On Wed, Jan 23, 2013 at 8:25 AM, Thomas Abraham
> <thomas.abraham@linaro.org> wrote:
>> Hi Dongjin,
>>
>> On 22 January 2013 10:15, Dongjin Kim <tobetter@gmail.com> wrote:
>>> Hi Thomas,
>>>
>>> Good to see your patch, actually I had sent similar one before but no
>>> one care my patch. And now I feel it seems to be wrong.
>>>
>>> But I have a couple of question if I use your patch to enable MSHC
>>> controller work properly on Exynos4412.
>>>
>>> What's the exact form of ".compatible" on board file?
>>> With your patch, MSHC is not probed at all in my board. The
>>> ".compatible" has to be 'samsung,exynos5250-dw-mshc' and it works.
>>>
>>> I also tried '.compatible = "samsung,exynos5250-dw-mshc",
>>> "samsung,exynos4412-dw-mshc"', it probes the driver but in the
>>> function 'dw_mci_exynos_priv_init', priv->ctrl_type always becomes
>>> DW_MCI_TYPE_EXYNOS5250. Because there is a loop and returns each
>>> compatible strings in alphanumeric order whatever it is ordered in the
>>> board file.
>>>
>>> I also tried below patch to add a compatible for Exynos4412 to
>>> 'dw_mci_exynos_match' with its specific data, and it works. What's the
>>> right direction? If I am missing something or wrong, please correct
>>> me. :)
>>
>> Yes, your below patch is the correct thing to do. The dt patches for
>> dwmmc controller driver were only tested on Exynos5250 based board. So
>> I had not added the compatible string for Exynos4412 in
>> 'of_match_table' of the driver. Please submit the below change as a
>> patch (minor comment below).
>>
>>>
>>> Many thanks,
>>> Dongjin.
>>>
>>> @@ -184,6 +186,25 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
>>> return 0;
>>> }
>>>
>>> +/* Exynos4412 controller specific capabilities */
>>> +static unsigned long exynos4412_dwmmc_caps[4] = {
>>> + MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
>>> + MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
>>> + MMC_CAP_CMD23,
>>> + MMC_CAP_CMD23,
>>> + MMC_CAP_CMD23,
>>> +};
>>
>> Since this is same as the 'exynos5250_dwmmc_caps', it can be reused
>> for 4412 as well, avoiding duplicate copy 'exynos4412_dwmmc_caps'.
>>
>>> +
>>> +static const struct dw_mci_drv_data exynos4412_drv_data = {
>>> + .caps = exynos4412_dwmmc_caps,
>>> + .init = dw_mci_exynos_priv_init,
>>> + .setup_clock = dw_mci_exynos_setup_clock,
>>> + .prepare_command = dw_mci_exynos_prepare_command,
>>> + .set_ios = dw_mci_exynos_set_ios,
>>> + .parse_dt = dw_mci_exynos_parse_dt,
>>> + .setup_bus = dw_mci_exynos_setup_bus,
>>> +};
>>
>> If the above change is done, 'exynos4412_drv_data ' also could be avoided.
>>
>>> +
>>> /* Exynos5250 controller specific capabilities */
>>> static unsigned long exynos5250_dwmmc_caps[4] = {
>>> MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
>>> @@ -204,6 +225,8 @@ static const struct dw_mci_drv_data exynos5250_drv_data = {
>>> };
>>>
>>> static const struct of_device_id dw_mci_exynos_match[] = {
>>> + { .compatible = "samsung,exynos4412-dw-mshc",
>>> + .data = &exynos4412_drv_data, },
>>> { .compatible = "samsung,exynos5250-dw-mshc",
>>> .data = &exynos5250_drv_data, },
>>> {},
>>
>> Thanks,
>> Thomas.
>>
>>>
>>>
>>> On Mon, Jan 21, 2013 at 7:39 PM, Thomas Abraham
>>> <thomas.abraham@linaro.org> wrote:
>>>> Commit cea0f256 ("ARM: dts: Add board dts file for ODROID-X") includes a node
>>>> to describe the board level properties for mshc controller. But the mshc
>>>> controller node was not added in the Exynos4x12 dtsi file which resulted
>>>> in the following warning when compiling the dtb files.
>>>>
>>>> Warning (reg_format): "reg" property in /mshc at 12550000/slot at 0 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
>>>> Warning (avoid_default_addr_size): Relying on default #address-cells value for /mshc at 12550000/slot at 0
>>>> Warning (avoid_default_addr_size): Relying on default #size-cells value for /mshc at 12550000/slot at 0
>>>>
>>>> Fix this by adding the mshc controller node for Exynos4x12 SoCs.
>>>>
>>>> Cc: Dongjin Kim <tobetter@gmail.com>
>>>> Cc: Kukjin Kim <kgene.kim@samsung.com>
>>>> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
>>>> ---
>>>> arch/arm/boot/dts/exynos4412.dtsi | 8 ++++++++
>>>> 1 files changed, 8 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
>>>> index 78ed377..96f5b66 100644
>>>> --- a/arch/arm/boot/dts/exynos4412.dtsi
>>>> +++ b/arch/arm/boot/dts/exynos4412.dtsi
>>>> @@ -32,4 +32,12 @@
>>>> interrupts = <0 57 0>, <0 0 0>, <0 0 0>, <0 0 0>,
>>>> <1 12 0>, <1 12 0>, <1 12 0>, <1 12 0>;
>>>> };
>>>> +
>>>> + mshc at 12550000 {
>>>> + compatible = "samsung,exynos4412-dw-mshc";
>>>> + reg = <0x12550000 0x1000>;
>>>> + interrupts = <0 77 0>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> };
>>>> --
>>>> 1.7.5.4
>>>>
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Soeren Moch @ 2013-01-23 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130119185907.GA20719@lunn.ch>
On 19.01.2013 19:59, Andrew Lunn wrote:
>> Please find attached a debug log generated with your patch.
>>
>> I used the sata disk and two em28xx dvb sticks, no other usb devices,
>> no ethernet cable connected, tuners on saa716x-based card not used.
>>
>> What I can see in the log: a lot of coherent mappings from sata_mv
>> and orion_ehci, a few from mv643xx_eth, no other coherent mappings.
>> All coherent mappings are page aligned, some of them (from orion_ehci)
>> are not really small (as claimed in __alloc_from_pool).
>>
>> I don't believe in a memory leak. When I restart vdr (the application
>> utilizing the dvb sticks) then there is enough dma memory available
>> again.
>
> Hi Soeren
>
> We should be able to rule out a leak. Mount debugfg and then:
>
> while [ /bin/true ] ; do cat /debug/dma-api/num_free_entries ; sleep 60 ; done
>
> while you are capturing. See if the number goes down.
>
> Andrew
Now I built a kernel with debugfs enabled.
It is not clear to me what I can see from the dma-api/num_free_entries
output. After reboot (vdr running) I see decreasing numbers (3453 3452
3445 3430...), min_free_entries is lower (3390). Sometimes the output is
constant for several minutes ( 3396 3396 3396 3396 3396,...)
Soeren
^ permalink raw reply
* [PATCH v2 3/3] arm: mvebu: Update defconfig to select USB support
From: Ezequiel Garcia @ 2013-01-23 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358954792-16160-1-git-send-email-ezequiel.garcia@free-electrons.com>
Cc: Lior Amsalem <alior@marvell.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Tested-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
arch/arm/configs/mvebu_defconfig | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index c3c6326..f8d0183 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -42,7 +42,10 @@ CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DW=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
-# CONFIG_USB_SUPPORT is not set
+CONFIG_USB_SUPPORT=y
+CONFIG_USB=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_MMC=y
CONFIG_MMC_MVSDIO=y
CONFIG_RTC_CLASS=y
--
1.7.8.6
^ permalink raw reply related
* [PATCH v2 2/3] arm: mvebu: Enable USB controllers on Armada 370/XP boards
From: Ezequiel Garcia @ 2013-01-23 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358954792-16160-1-git-send-email-ezequiel.garcia@free-electrons.com>
This patch activates every USB port provided by each SoC.
Except for Armada XP Openblocks AX3-4 board,
where we enable only the first two USB ports
until we have more information on the third one usage.
Cc: Lior Amsalem <alior@marvell.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Tested-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
Changes from v1:
* Squashed separate per-board patches into this one,
as suggested by Arnd.
* Remove usb at d0052000 activation in OpenBlocks AX3-4
until we have more information about it.
arch/arm/boot/dts/armada-370-db.dts | 8 ++++++++
arch/arm/boot/dts/armada-370-mirabox.dts | 8 ++++++++
arch/arm/boot/dts/armada-xp-db.dts | 12 ++++++++++++
arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 6 ++++++
4 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 8e66a7c..3d93902 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -74,5 +74,13 @@
status = "disabled";
/* No CD or WP GPIOs */
};
+
+ usb at d0050000 {
+ status = "okay";
+ };
+
+ usb at d0051000 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts b/arch/arm/boot/dts/armada-370-mirabox.dts
index 1864820..dd0c57d 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -62,5 +62,13 @@
* Wifi/Bluetooth chip
*/
};
+
+ usb at d0050000 {
+ status = "okay";
+ };
+
+ usb at d0051000 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index c7035c5..c84e1fe 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -97,5 +97,17 @@
status = "okay";
/* No CD or WP GPIOs */
};
+
+ usb at d0050000 {
+ status = "okay";
+ };
+
+ usb at d0051000 {
+ status = "okay";
+ };
+
+ usb at d0052000 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index ec36864..3818a82 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -133,5 +133,11 @@
nr-ports = <2>;
status = "okay";
};
+ usb at d0050000 {
+ status = "okay";
+ };
+ usb at d0051000 {
+ status = "okay";
+ };
};
};
--
1.7.8.6
^ permalink raw reply related
* [PATCH v2 1/3] arm: mvebu: Add support for USB host controllers in Armada 370/XP
From: Ezequiel Garcia @ 2013-01-23 15:26 UTC (permalink / raw)
To: linux-arm-kernel
The Armada 370 and Armada XP SoC has an Orion EHCI USB controller.
This patch adds support for this controller in Armada 370
and Armada XP SoC common device tree files.
Cc: Lior Amsalem <alior@marvell.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Tested-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
Changes from v1:
* Remove uneeded USB_ARCH_HAS_EHCI selection as noted by Florian.
arch/arm/boot/dts/armada-370-xp.dtsi | 15 +++++++++++++++
arch/arm/boot/dts/armada-370.dtsi | 9 +++++++++
arch/arm/boot/dts/armada-xp.dtsi | 17 +++++++++++++++++
3 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 28276fe..fa025c4 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -145,6 +145,21 @@
clocks = <&gateclk 17>;
status = "disabled";
};
+
+ usb at d0050000 {
+ compatible = "marvell,orion-ehci";
+ reg = <0xd0050000 0x500>;
+ interrupts = <45>;
+ status = "disabled";
+ };
+
+ usb at d0051000 {
+ compatible = "marvell,orion-ehci";
+ reg = <0xd0051000 0x500>;
+ interrupts = <46>;
+ status = "disabled";
+ };
+
};
};
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 88f9bab..8188d13 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -144,5 +144,14 @@
dmacap,memset;
};
};
+
+ usb at d0050000 {
+ clocks = <&coreclk 0>;
+ };
+
+ usb at d0051000 {
+ clocks = <&coreclk 0>;
+ };
+
};
};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 2e37ef1..c22a0c8 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -134,5 +134,22 @@
dmacap,memset;
};
};
+
+ usb at d0050000 {
+ clocks = <&gateclk 18>;
+ };
+
+ usb at d0051000 {
+ clocks = <&gateclk 19>;
+ };
+
+ usb at d0052000 {
+ compatible = "marvell,orion-ehci";
+ reg = <0xd0052000 0x500>;
+ interrupts = <47>;
+ clocks = <&gateclk 20>;
+ status = "disabled";
+ };
+
};
};
--
1.7.8.6
^ permalink raw reply related
* [PATCH V5] drivers/pinctrl: grab default handles from device core
From: Mark Brown @ 2013-01-23 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZTwvdmRnDOAcOObj7NhkuUunACpYBvAE1bY65suroQiA@mail.gmail.com>
On Wed, Jan 23, 2013 at 09:50:36AM +0100, Linus Walleij wrote:
> Greg/Mark: are you still confident with your ACK/Reviewed-by
> tags being added on this version?
Yup, this looks great.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130123/be9b4028/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/2] usb: host: tegra: don't touch EMC clock
From: Alan Stern @ 2013-01-23 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358900903-27654-1-git-send-email-swarren@wwwdotorg.org>
On Tue, 22 Jan 2013, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Clock "emc" is for the External Memory Controller. The USB driver has no
> business touching this clock directly. Remove the code that does so.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> Greg, Alan, I'd like to take this patch through the Tegra tree to avoid
> any merge conflicts with the Tegra USB changes that have recently
> happened there.
It's okay with me.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
^ permalink raw reply
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
From: Alan Stern @ 2013-01-23 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122210027.GN1906@pengutronix.de>
On Tue, 22 Jan 2013, Sascha Hauer wrote:
> On Tue, Jan 22, 2013 at 03:38:55PM +0000, Arnd Bergmann wrote:
> > On Tuesday 22 January 2013, Alan Stern wrote:
> > > In order to prevent this, you have to make sure that each glue driver
> > > depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround
> > > the Kconfig entries for those drivers with "if USB &&
> > > USB_ARCH_HAS_EHCI" ... "endif".
> >
> > I was actually thinking we could remove the use of USB_ARCH_HAS_EHCI
> > as well once we have inverted the logic for selecting USB_EHCI_HCD,
> > but there is another problem with that, because then we still need
> > something to select USB_ARCH_HAS_HCD, or kill that symbol as well.
>
> +1 for killing it. Such symbols get more and more meaningless anyway
> with multiarch kernels-
I tend to agree. Anyway, the symbols are named badly. _Any_
architecture with HAS_IOMEM can in theory aupport host-side USB.
Maybe some of the platforms don't, but that has nothing to do with the
CPU's architecture.
Furthermore, even platforms that don't support USB host controllers
can use things like dummy-hcd and usbip, which provide virtual host
controllers.
Anybody think these symbols should be retained?
Alan Stern
^ permalink raw reply
* [PATCH] ARM: dove: update dove_defconfig with a few useful options
From: Jason Cooper @ 2013-01-23 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358099647-22323-1-git-send-email-olof@lixom.net>
On Sun, Jan 13, 2013 at 09:54:07AM -0800, Olof Johansson wrote:
> This refreshes the dove_defconfig, and adds:
> PRINTK_TIME
> DEVTMPFS
> EXT4
>
> They're quite useful, and allows booting a cubox ubuntu rootfs on SD card,
> since that by default uses ext4.
>
> The rest of the churn is due to options and defaults moving around, no
> functional difference.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>
> ---
> arch/arm/configs/dove_defconfig | 28 ++++++++--------------------
> 1 file changed, 8 insertions(+), 20 deletions(-)
Applied to mvebu/boards
thx,
Jason.
^ permalink raw reply
* [PATCH 3.8-rc] arm: mvebu: i2c come back in defconfig
From: Jason Cooper @ 2013-01-23 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358953079-1277-2-git-send-email-gregory.clement@free-electrons.com>
On Wed, Jan 23, 2013 at 03:57:59PM +0100, Gregory CLEMENT wrote:
> When the patch "arm: mvebu: Use dw-apb-uart instead of ns16650 as UART
> driver" was applied to a git tree and became the commit b24212fbfba25
> it wrongly removed the i2c support. This patch reintroduce it.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> arch/arm/configs/mvebu_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
Applied to mvebu/fixes
thx,
Jason.
^ permalink raw reply
* [PATCH V5] drivers/pinctrl: grab default handles from device core
From: Greg Kroah-Hartman @ 2013-01-23 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZTwvdmRnDOAcOObj7NhkuUunACpYBvAE1bY65suroQiA@mail.gmail.com>
On Wed, Jan 23, 2013 at 09:50:36AM +0100, Linus Walleij wrote:
> OK!
>
> This modified version of the patch is way more beautiful, stupid
> me for not realizing it could be written like that.
>
> And I can sure live with the removed doc piece ... we can discuss
> that separately if need be, I have some argument for it but it's
> a separate issue.
>
> I've dubbed this version the v5 variant and applied it, and included
> the changelog (so I remember how it came about).
>
> Greg/Mark: are you still confident with your ACK/Reviewed-by
> tags being added on this version?
Yes, that's fine with me.
^ permalink raw reply
* [PATCH 3.8-rc] arm: mvebu: i2c come back in defconfig
From: Gregory CLEMENT @ 2013-01-23 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358953079-1277-1-git-send-email-gregory.clement@free-electrons.com>
When the patch "arm: mvebu: Use dw-apb-uart instead of ns16650 as UART
driver" was applied to a git tree and became the commit b24212fbfba25
it wrongly removed the i2c support. This patch reintroduce it.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/configs/mvebu_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index b5bc96c..cbd91bc 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -33,6 +33,8 @@ CONFIG_MVNETA=y
CONFIG_MARVELL_PHY=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_I2C=y
+CONFIG_I2C_MV64XXX=y
CONFIG_SERIAL_8250_DW=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3.8-rc] i2c come back in mvebu_defconfig
From: Gregory CLEMENT @ 2013-01-23 14:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jason,
I have just realised that there were a problem when you applied my
patch ``arm: mvebu: Use dw-apb-uart instead of ns16650 as UART''. I
don't know what happened exactly but the commit remove the i2c support
whereas it was not the case in the patch I posted. Anyway this patch
fix it.
Thanks,
Gregory CLEMENT (1):
arm: mvebu: i2c come back in defconfig
arch/arm/configs/mvebu_defconfig | 2 ++
1 file changed, 2 insertions(+)
--
1.7.9.5
^ permalink raw reply
* [PATCH 0/2] Remove two redundent clk aliases
From: Jason Cooper @ 2013-01-23 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357851669-25669-1-git-send-email-andrew@lunn.ch>
On Thu, Jan 10, 2013 at 10:01:07PM +0100, Andrew Lunn wrote:
> Both USB and MDIO are now instantiated using DT and these DT nodes
> have clocks properties. Remove the now redundant clkdev aliases.
>
> The first patch has no dependencies.
>
> The second patch is dependent on the SDIO patchset "Device Tree
> binding for the mvsdio driver" by Thomas Petazzoni.
>
>
> Andrew Lunn (2):
> ARM: Kirkwood: Remove redundent USB clock alias
> ARM: Kirkwood: Remove redundent SDIO clock alias
>
> arch/arm/mach-kirkwood/board-dt.c | 9 ---------
> 1 file changed, 9 deletions(-)
Both applied to mvebu/boards. Normally, I would put this in
mvebu/cleanup. However, the dependency on mvebu/drivers (mvsdio
changes) meant putting it in boards removed any circular dependencies.
thx,
Jason.
^ permalink raw reply
* ARM: hw_breakpoint mismatch breakpoint behaves unexpectedly like a match breakpoint on ARM_DEBUG_ARCH_V7_ECP14
From: Will Deacon @ 2013-01-23 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPfQmK+mwx39J5yWiLCTWbiFL=yL-rw=XZXRkOwGU_byQsDyQA@mail.gmail.com>
On Tue, Jan 22, 2013 at 05:11:11PM +0000, Valentin Pistol wrote:
> > The ptrace interface doesn't support mismatch breakpoints, and ignores those
> > bits in the user request, hence why you see a normal breakpoint being
> > created. Note that mismatch breakpoints are used internally for stepping
> > over breakpoints set by perf.
> >
> > If you wanted to add single-step using mismatch breakpoints, I think we'd be
> > better off re-introducing the SINGLESTEP ptrace request for ARM to use
> > hw_breakpoints.
>
> I noticed your old Feb 2011 post on SINGLESTEP being removed:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041408.html
>
> So it was managing its own breakpoints and instruction decoding (like
> gdb would) but didn't take advantage of either mismatch support or
> hw_breakpoints?
Correct. The code also didn't handle newer instructions especially well,
with issues on SMP too. Given that the request is only supposed to be
implemented for architectures with hardware single-step, it made sense to
remove the code.
> Such support seems really useful and yet much more simple if mismatch
> is supported.
> I definitely would like to use the ptrace and hw-breakpoints interface
> instead of avoiding and writing it from scratch, as it takes care of a
> lot of details, for instance SMP and context switches, uninstalling
> and installing the breakpoints as required.
Ok.
> I'm wondering how pervasive the required changes are to support
> SINGLESTEP with mismatch breakpoints.
> If you think it's a good idea I'm very willing to try and add-in such support.
> Please let me know if there's some obvious issues about going forward
> with this that you may be aware of.
Given that ARMv8 has hardware single-step, I'd be inclined to implement
that instead so that we don't have to overload the SINGLESTEP request later
on. Alternatively, you could implement something like PTRACE_HBPSTEP but I
think you will run into some problems:
1. Alignment restrictions. Stepping something like a 32-bit Thumb
instruction on a halfword boundary will need *two* breakpoints to
be added and handled appropriately.
2. Interaction with mismatch breakpoints being used internally by
the kernel. You might be ok here, but you want to check the code
which uses mismatch breakpoints to step over breakpoints and
watchpoints.
Will
^ permalink raw reply
* [GIT PULL] power: ab8500-bm: Latest Mainline<->STE delta reduction patch-set
From: Lee Jones @ 2013-01-23 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123113854.GK15873@gmail.com>
Okay, after Linus Walleij's diligent observaions, I have removed all
new functionallity related to Deep Debug and will continue to
investigate what I need to do in that regard.
In the mean-time, here's the fresh deep-debug:less pull-request:
----------------------------------------------------------------
The following changes since commit 8fd526fd18233887ba652079a369f4eee0de9d9d:
qnap-poweroff: Fix license string (2013-01-19 18:04:04 -0800)
are available in the git repository at:
git://git.linaro.org/people/ljones/linux-3.0-ux500.git tb-power-2
for you to fetch changes up to 34c11a709e928090cf34ecd706f7d3170f4e5026:
u8500-charger: Delay for USB enumeration (2013-01-23 14:39:22 +0000)
----------------------------------------------------------------
Hakan Berg (1):
ab8500-fg: Adjust for RF bursts voltage drops
Henrik S?lver (1):
ab8500-charger: AB workaround for invalid charger
Jonas Aaberg (2):
ab8500-bm: Flush all work queues before suspending
ab8500-charger: Do not touch VBUSOVV bits
Lee Jones (7):
ab8500-charger: Kick watchdog
ab8500-chargalg: Update battery health on safety timer exp
pm2301: Move all configuration and emum structs out to a header
file
ab8500-chargalg: Only root should have write permission on sysfs
file
abx500-chargalg: Add new sysfs interface to get current charge
status
pm2301: LPN mode control support
ab8500-bm: Remove individual [charger|btemp|fg|chargalg] pdata
structures
Loic Pallardy (2):
pm2301: Remove volt_now & curr_now properties
pm2301: Update watchdog for pm2xxx support
Martin Bergstr?m (1):
ab8500-fg: Go to INIT_RECOVERY when charger removed
Michel JAOUEN (2):
pm2301: Provide u9540 support for the pm2301 charger
ab8500-btemp: Adaptation to AB8505 and AB9540 platforms
Nicolas Guion (1):
ab8500-charger: Add support for autopower on AB8505 and AB9540
Olivier Clergeaud (1):
pm2301: Clean-up PM2301 interrupt management
Paer-Olof Haakansson (1):
u8500-charger: Delay for USB enumeration
Rajkumar Kasirajan (2):
pm2301: Enable vbat low monitoring
ab8500-fg: Use correct battery charge full design
drivers/mfd/ab8500-core.c | 6 +
drivers/power/Kconfig | 7 +
drivers/power/Makefile | 1 +
drivers/power/ab8500_btemp.c | 67 +-
drivers/power/ab8500_charger.c | 617 ++++++++++++----
drivers/power/ab8500_fg.c | 51 +-
drivers/power/abx500_chargalg.c | 43 +-
drivers/power/pm2301_charger.c | 1088 +++++++++++++++++++++++++++++
drivers/power/pm2301_charger.h | 513 ++++++++++++++
include/linux/mfd/abx500.h | 3 +
include/linux/mfd/abx500/ab8500-bm.h | 22 +-
include/linux/mfd/abx500/ab8500.h | 19 +
include/linux/mfd/abx500/ux500_chargalg.h | 5 +
include/linux/pm2301_charger.h | 61 ++
14 files changed, 2306 insertions(+), 197 deletions(-)
create mode 100644 drivers/power/pm2301_charger.c
create mode 100644 drivers/power/pm2301_charger.h
create mode 100644 include/linux/pm2301_charger.h
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3] arm: mvebu: add DTS file for Marvell RD-A370-A1 board
From: Jason Cooper @ 2013-01-23 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123142933.GO1758@titan.lakedaemon.net>
On Wed, Jan 23, 2013 at 09:29:33AM -0500, Jason Cooper wrote:
> On Mon, Jan 14, 2013 at 03:47:32PM +0100, Florian Fainelli wrote:
> > This patch adds the DTS file to support the Marvell RD-A370-A1
> > (Reference Design board) also known as RD-88F6710 board. It is almost
> > entirely similar to the DB-A370 except on the following points:
> >
> > - second Ethernet MAC is connected to a switch using RGMII
> > - it only has 512MB of physical RAM
> > - SDIO interface is enabled and working by default (no need for jumpers)
> >
> > Signed-off-by: Florian Fainelli <florian@openwrt.org>
> > ---
> > Jason,
> >
> > This is rebased against your mvebu/for-next branch, can you please drop v2 of
> > the previous patch and take this one instead? Thanks!
> >
> > Changes since v2:
> > - rebased against Jason's mvebu/for-next
> > - added SDIO bindings
> > - changed commit message a bit
> >
> > Changes since v1:
> > - added missing entry in arch/arm/boot/dts/Makefile to actually build the DTB
> >
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/armada-370-rd.dts | 68 +++++++++++++++++++++++++++++++++++
> > 2 files changed, 69 insertions(+)
> > create mode 100644 arch/arm/boot/dts/armada-370-rd.dts
>
> Applied to mvebu/dt
oops, I meant mvebu/boards.
thx,
Jason.
^ permalink raw reply
* [PATCH] arm: plat-orion: fix printing of "MPP config unavailable on this hardware"
From: Jason Cooper @ 2013-01-23 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FFF489.5070506@keymile.com>
On Wed, Jan 23, 2013 at 03:32:41PM +0100, Gerlando Falauto wrote:
> On 01/23/2013 03:25 PM, Jason Cooper wrote:
> >On Wed, Jan 23, 2013 at 02:50:59PM +0100, Gerlando Falauto wrote:
> >>Commit 3cff484d4b264ff467a3b45c544cbbbab69f0bf8
> >>ARM: dove: Consolidate mpp code with platform mpp.
> >>
> >>refactored printing of the kernel warning
> >>"orion_mpp_conf: requested MPP%u config unavailable on this hardware\n"
> >>which is not to be printed in case of variant_mask = 0 (unknown variant).
> >>This check should be performed using a logical AND (&&) as opposed
> >>to a bitwise AND (&).
> >>Otherwise, test would fail (and message would be printed) if variant_mask != 1
>
> Whooops, what I meant was "and message would NOT be printed"... sorry. :-(
> Shouldn't really matter anyway.
fixed in mvebu/fixes.
thx,
Jason.
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Soeren Moch @ 2013-01-23 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301221813.57741.arnd@arndb.de>
On 22.01.2013 19:13, Arnd Bergmann wrote:
> On Monday 21 January 2013, Greg KH wrote:
>>>
>>> I don't know a lot about USB, but I always assumed that this was not
>>> a normal condition and that there are only a couple of URBs per endpoint
>>> used at a time. Maybe Greg or someone else with a USB background can
>>> shed some light on this.
>>
>> There's no restriction on how many URBs a driver can have outstanding at
>> once, and if you have a system with a lot of USB devices running at the
>> same time, there could be lots of URBs in flight depending on the number
>> of host controllers and devices and drivers being used.
I only use one host controller and (in this test) two usb devices with
the same driver.
> Ok, thanks for clarifying that. I read some more of the em28xx driver,
> and while it does have a bunch of URBs in flight, there are only five
> audio and five video URBs that I see simultaneously being submitted,
> and then resubmitted from their completion handlers. I think this
> means that there should be 10 URBs active at any given time in this
> driver, which does not explain why we get 256 allocations.
I think the audio part of the em28xx bridge is not used in my DVB tests.
Are there other allocations from orion-ehci directly? Maybe something
special for isochronous transfers (since there is no problem with my
other dvb sticks using bulk transfers)?
> I also noticed that the initial submissions are all atomic but don't
> need to, so it may be worth trying the patch below, which should also
> help in low-memory situations. We could also try moving the resubmission
> into a workqueue in order to let those be GFP_KERNEL, but I don't think
> that will help.
I built a linux-3.7.4 with the em28xx patch and both of your dma-mapping.c
patches. I still see the
ERROR: 1024 KiB atomic DMA coherent pool is too small!
Soeren
^ permalink raw reply
* [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Rob Clark @ 2013-01-23 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGu2f_zqkKayS-7ZEiVHHEhEYcqE2eL2BQ4rxW6+08wm7w@mail.gmail.com>
On Wed, Jan 23, 2013 at 8:13 AM, Rob Clark <robdclark@gmail.com> wrote:
> On Wed, Jan 23, 2013 at 7:36 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
>>> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine <moinejf@free.fr> wrote:
>>> > Hi Rob,
>>> >
>>> > As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
>>> > I had a look at your IT LCD driver. Comments below.
>>>
>>> Just fyi, you can re-use the nxp-tda998x part independently of tilcdc
>>> (just in case that wasn't clear).
>>
>> Great, this chip is also used on the cubox too.
>
> cool, it would be great if other platforms could benefit from this as
> well.. the out-of-tree nxp driver is just horrid ;-)
>
>> The one thing I wonder is how you deal with the VSYNC/HSYNC polarities
>> that are provided to the TDA9988x chip. On the cubox, I have to adjust
>> the mode parameters such that the polarities are fixed up thusly:
>>
>> adjusted->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC |
>> DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC |
>> DRM_MODE_FLAG_PCSYNC | DRM_MODE_FLAG_NCSYNC);
>>
>> /* The TDA19988 always requires negative VSYNC? */
>> adjusted->flags |= DRM_MODE_FLAG_NVSYNC;
>>
>> /* The TDA19988 requires positive HSYNC on 1080p or 720p */
>> if ((adjusted->hdisplay == 1920 && adjusted->vdisplay == 1080) ||
>> (adjusted->hdisplay == 1280 && adjusted->vdisplay == 720))
>> adjusted->flags |= DRM_MODE_FLAG_PHSYNC;
>> else
>> adjusted->flags |= DRM_MODE_FLAG_NHSYNC;
>>
>> return true;
>>
>> for these resolutions to be displayed correctly.
>
> hmm, I didn't come across this. Although 1080p seems to be a bit more
> than what the little board I'm working on can drive. I didn't have to
> do any special fixup for 720p..
one thought.. I haven't enabled any hdmi features like audio yet..
which could be a reason that I didn't hit some of these issues. I'm
not really much of an audio/asoc expert so I'm not really sure how
this should hook in for audio stuff, but if someone out there with
some hw with a similar nxp encoder chip does have some better audio
experience, I'd be interested to work together on that.
BR,
-R
> I wonder if you are having to do that with the nxp out of tree driver?
> Maybe it is related to how that driver it is configuring the hw? It
> would be interesting if you hit the same issue w/ the i2c encoder
> slave version.
>
> At any rate, if it turns out to be needed, we can add this in
> tda998x_encoder_mode_fixup().
>
>> Also, when the only output is the HDMI device, reporting the display
>> "disconnected" and without any modes seems to cause problems - I have to
>> report "unknown" status when there's nothing connected, and also provide
>> a default (720p) mode when no EDID is received.
>
> hmm, also did not run into any issues here on my end. What sort of
> problems did you hit?
>
> BR,
> -R
^ permalink raw reply
* [PATCH] arm: plat-orion: fix printing of "MPP config unavailable on this hardware"
From: Gerlando Falauto @ 2013-01-23 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123142510.GN1758@titan.lakedaemon.net>
On 01/23/2013 03:25 PM, Jason Cooper wrote:
> On Wed, Jan 23, 2013 at 02:50:59PM +0100, Gerlando Falauto wrote:
>> Commit 3cff484d4b264ff467a3b45c544cbbbab69f0bf8
>> ARM: dove: Consolidate mpp code with platform mpp.
>>
>> refactored printing of the kernel warning
>> "orion_mpp_conf: requested MPP%u config unavailable on this hardware\n"
>> which is not to be printed in case of variant_mask = 0 (unknown variant).
>> This check should be performed using a logical AND (&&) as opposed
>> to a bitwise AND (&).
>> Otherwise, test would fail (and message would be printed) if variant_mask != 1
Whooops, what I meant was "and message would NOT be printed"... sorry. :-(
Shouldn't really matter anyway.
Thanks,
Gerlando
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Bedia, Vaibhav @ 2013-01-23 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122182331.GO22517@atomide.com>
Hi Tony,
On Tue, Jan 22, 2013 at 23:53:32, Tony Lindgren wrote:
[...]
> >
> > But I should get *something* from the kernel before it starts trying to access the rootfs ?
>
> Here's something Kevin fixed but did not send it out before going to
> a vacation. Can you give it a try with earlyprintk enabled?
>
> Note that this does not help with no output early on, that sounds
> like a bug configuring the DEBUG_LL port somewhere.
>
I think earlyprintk on AM335x has not been functional for a while [1].
Will the latest patches from you to enable multiplatform debug-ll be sufficient
to test this out? I am trying to track down the boot issues reported and just
want to be sure of the dependencies.
[1] http://marc.info/?l=linux-omap&m=134642491119235&w=2
[2] https://patchwork.kernel.org/patch/1896851/
Regards,
Vaibhav
^ permalink raw reply
* [PATCH v3] arm: mvebu: add DTS file for Marvell RD-A370-A1 board
From: Jason Cooper @ 2013-01-23 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358174852-19752-1-git-send-email-florian@openwrt.org>
On Mon, Jan 14, 2013 at 03:47:32PM +0100, Florian Fainelli wrote:
> This patch adds the DTS file to support the Marvell RD-A370-A1
> (Reference Design board) also known as RD-88F6710 board. It is almost
> entirely similar to the DB-A370 except on the following points:
>
> - second Ethernet MAC is connected to a switch using RGMII
> - it only has 512MB of physical RAM
> - SDIO interface is enabled and working by default (no need for jumpers)
>
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
> ---
> Jason,
>
> This is rebased against your mvebu/for-next branch, can you please drop v2 of
> the previous patch and take this one instead? Thanks!
>
> Changes since v2:
> - rebased against Jason's mvebu/for-next
> - added SDIO bindings
> - changed commit message a bit
>
> Changes since v1:
> - added missing entry in arch/arm/boot/dts/Makefile to actually build the DTB
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/armada-370-rd.dts | 68 +++++++++++++++++++++++++++++++++++
> 2 files changed, 69 insertions(+)
> create mode 100644 arch/arm/boot/dts/armada-370-rd.dts
Applied to mvebu/dt
thx,
Jason.
^ permalink raw reply
* [PATCH v1 0/6] USB: Add support for multiple PHYs of same type
From: kishon @ 2013-01-23 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA922F5@DBDE01.ent.ti.com>
Hi Afzal,
On Wednesday 23 January 2013 07:28 PM, Mohammed, Afzal wrote:
> Hi Koen,
>
> On Tue, Jan 22, 2013 at 22:32:56, Koen Kooi wrote:
>
>> Actually it uses nop-phy as a phy, which is missing from arch/arm/boot/dts/am33xx.dtsi, so mainline is already broken. But adding the nop-phy to the DT is easy enough to patch in locally.
>
> USB first instance of am335x works in mainline as of now.
Can you check if this series indeed breaks am335x?
Thanks for your help.
Regards
Kishon
^ permalink raw reply
* [PATCH] arm: plat-orion: fix printing of "MPP config unavailable on this hardware"
From: Jason Cooper @ 2013-01-23 14:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358949059-10803-1-git-send-email-gerlando.falauto@keymile.com>
On Wed, Jan 23, 2013 at 02:50:59PM +0100, Gerlando Falauto wrote:
> Commit 3cff484d4b264ff467a3b45c544cbbbab69f0bf8
> ARM: dove: Consolidate mpp code with platform mpp.
>
> refactored printing of the kernel warning
> "orion_mpp_conf: requested MPP%u config unavailable on this hardware\n"
> which is not to be printed in case of variant_mask = 0 (unknown variant).
> This check should be performed using a logical AND (&&) as opposed
> to a bitwise AND (&).
> Otherwise, test would fail (and message would be printed) if variant_mask != 1
>
> Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Nicolas Pitre <nico@linaro.org>
> Cc: Holger Brunck <holger.brunck@keymile.com>
> ---
> arch/arm/plat-orion/mpp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to mvebu/fixes with some minor cleanup of the commit message
thx,
Jason.
^ 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