On Fri, Jun 07, 2013 at 10:37:08AM +0200, Steffen Trumtrar wrote:
> From: Markus Niebel
>
> Since 18 bit is supported as datawidth in device tree it should be
> supported in driver. Beside the LDB channel the IPU channel has also
> to be configured to use BGR666.
>
> Signed-off-by: Markus Niebel
On Fri, Jun 07, 2013 at 10:52:54AM -0700, Mike Turquette wrote:
> Yes, there was a time when I was firmly against doing such a thing.
> However I'm not sure it is so bad now. More and more SoCs are going to
> keep getting merged into the kernel and that just means more and more
> clock data. Perh
On 8 June 2013 01:41, Mike Dunn wrote:
> On 06/07/2013 08:16 AM, Haojian Zhuang wrote:
>>
>
> [...]
>
>
>> Since you need to configure both GPDRx and GAFRx. If we are talking
>> pinctrl-single
>> as reference, we can make it work by this way.
>>
>> We need to define two pinmux controllers. One is
On Tue, Jun 04, 2013 at 07:39:14AM +1200, Tony Prisk wrote:
> The following changes since commit f722406faae2d073cc1d01063d1123c35425939e:
>
> Linux 3.10-rc1 (2013-05-11 17:14:08 -0700)
>
> are available in the git repository at:
>
> git://github.com/linux-wmt/linux-vtwm.git tags/vt8500/dts-
On Fri, Jun 07, 2013 at 11:15:50PM +0200, Arnd Bergmann wrote:
> > The mbus driver should never read or write this register.
>
> That is not a hard requirement, right? I guess based on the
> recent discussion about the 0xd0 or 0xf1 window, there may
> actually be good reasons to reassign it, alth
Am Samstag, 8. Juni 2013, 01:13:48 schrieb Heiko Stübner:
> Am Freitag, 7. Juni 2013, 14:53:51 schrieb Linus Walleij:
> > On Thu, Jun 6, 2013 at 9:11 PM, Heiko Stübner wrote:
> > > + for (i = 0, j = 0; i < size; i += 4, j++) {
> > > + unsigned long pinconf;
> > > +
> > > +
On Thu, May 23, 2013 at 11:48:58AM +0100, Lorenzo Pieralisi wrote:
> Hi Arnd, Olof,
>
> please pull dts cpus/cpu node updates for all non-compliant ARM
> SoC/boards. Please notice I could not update all dts files since some of
> them are missing the cpus node altogether and I simply can not know
>
Am Freitag, 7. Juni 2013, 14:53:51 schrieb Linus Walleij:
> On Thu, Jun 6, 2013 at 9:11 PM, Heiko Stübner wrote:
> > + for (i = 0, j = 0; i < size; i += 4, j++) {
> > + unsigned long pinconf;
> > +
> > + num = be32_to_cpu(*list++);
> > + bank = bank_
On Saturday, June 8, 2013, luke.leighton wrote:
> right - too many people contributed to this, input from jon smirl,
> wookie, maxime, tomasz, henrik, i've made a start here and will
> continue editing: this is notes for me to put forward an agenda for
> discussion:
>
> http://hands.com/~lkcl/allw
On Fri, Jun 07, 2013 at 07:26:49PM +0100, luke.leighton wrote:
> maxime: we need to talk :)
>
> please tell me in 4 or 5 sentences what you've managed to do so far,
> expanding a little on what thomas says below, more specifically what
> it achieves and/or allows rather than technically what it
* Benoit Cousson [130603 07:42]:
> Hi Tony,
>
> Please pull three DTS fixes for the next -rc.
Thanks pulling into omap-for-v3.10/fixes.
Regards,
Tony
> The following changes since commit d683b96b072dc4680fc74964eca77e6a23d1fa6e:
> Linus Torvalds (1):
> Linux 3.10-rc4
>
> are avail
On Friday 07 June 2013, Jason Gunthorpe wrote:
>
> On Fri, Jun 07, 2013 at 09:53:03PM +0200, Arnd Bergmann wrote:
>
> > Can you explain to me why it is an invalid target ID value? Is it
> > treated very differently by the mbus register setup than all the
> > others? I guess we can define it as s
On Friday 07 June 2013, Jason Gunthorpe wrote:
> On Fri, Jun 07, 2013 at 09:01:44PM +0200, Arnd Bergmann wrote:
>
> > > +- compatible:Should be set to one of the following:
> > > + marvell,armada370-mbus
> > > + marvell,armadaxp-mbus
> >
> > I thought they are compatible with
* Tony Lindgren [130607 13:56]:
> Now pinctrl-single-omap can handle the wake-up events for us now
> as long as the events are configured in the .dts files.
This patch I should queue separately, the rest should go via
the pinctrl tree.
Regards,
Tony
_
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
Done in collaboration with Roger Quadros .
Cc: Haojian Zhuang
Cc: Peter Ujfalusi
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros
Signed-off-by: Tony Lin
For wake-up events from deeper idle modes we need to check the
configured padconf registers for the wake-up bit and then call
the related interrupt handler.
Done in collaboration with Roger Quadros .
Cc: Haojian Zhuang
Cc: Peter Ujfalusi
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Ro
At least on omaps, each board typically has at least one device
configured as wake-up capable from deeper idle modes. In the
deeper idle modes the normal interrupt wake-up path won't work
as the logic is powered off and separate wake-up hardware is
available either via IO ring or GPIO hardware. The
Let's replace is_pinconf with flags and add struct pcs_soc so we
can support also other features like pin wake-up events. Let's
export the probe so the SoC specific modules can pass their
SoC specific data to pinctrl-single if needed.
Done in collaboration with Roger Quadros .
Cc: Haojian Zhuang
On Fri, Jun 07, 2013 at 09:53:03PM +0200, Arnd Bergmann wrote:
> Can you explain to me why it is an invalid target ID value? Is it
> treated very differently by the mbus register setup than all the
> others? I guess we can define it as something else to make a valid
> target ID, by using one or m
On Fri, Jun 07, 2013 at 09:01:44PM +0200, Arnd Bergmann wrote:
> > +- compatible: Should be set to one of the following:
> > + marvell,armada370-mbus
> > + marvell,armadaxp-mbus
>
> I thought they are compatible with all older ones at the register level,
> as long as we d
On 06/07/2013 05:28 AM, J Keerthy wrote:
> Adds palmas mfd and palmas regulator nodes. This is
> based on the patch series:
>
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
>
> The device tree nodes are based on:
> https://lkml.org/lkml/2013/6/6/25
> diff --git a/arch/arm
On Friday 07 June 2013, Jason Gunthorpe wrote:
> We have a minimum requirement that the bootloader setup internal regs,
> so the minimum required DT bindings is going to be this:
>
> mbus {
> compatible = ...
> ranges = ;
> reg = <0xf1000xxx ...>; // MBUS regs block
> #address/size-cells..
On Fri, Jun 07, 2013 at 09:10:35PM +0200, Arnd Bergmann wrote:
> On Friday 07 June 2013, Ezequiel Garcia wrote:
> > + np = of_find_matching_node(NULL, of_mvebu_mbus_ids);
> > + if (!np) {
> > + pr_err("could not find a matching SoC family\n");
> > + return -E
On Fri, Jun 07, 2013 at 08:18:14PM +0100, Luke Kenneth Casson Leighton wrote:
> On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux
> wrote:
> > Luke Leighton on the other hand is demanding that we
>
> no demands have been made, russell: i've informed you of an immovable
> deadline which wi
On Fri, Jun 07, 2013 at 08:04:26PM +0100, luke.leighton wrote:
> On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson wrote:
> > By demanding
>
> a-a-ah, no demands made.
" well, tough. get me up to speed, *fast*. please stop wasting time
like this: get me up to speed."
That is a demand. Stop tro
On Fri, Jun 07, 2013 at 08:02:03PM +0100, luke.leighton wrote:
> well, tough. get me up to speed, *fast*.
No, not unless you're willing to *pay* someone to spend time teaching you,
because you are asking to be *taught* about the current situation, so
you're asking someone to do some _work_ _for_
On 06/07/2013 06:27 AM, Benoit Cousson wrote:
> Hi Keerthy,
>
> On 06/07/2013 01:28 PM, J Keerthy wrote:
>> Adds palmas mfd and palmas regulator nodes. This is
>> based on the patch series:
>>
>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
>>
>> The device tree nodes are b
On 06/06/2013 09:30 AM, Christian Ruppert wrote:
> On Thu, Jun 06, 2013 at 10:32:21PM +0800, Haojian Zhuang wrote:
>> On 6 June 2013 22:11, Christian Ruppert wrote:
>>> On Wed, Jun 05, 2013 at 09:44:27AM +0800, Haojian Zhuang wrote:
On 3 June 2013 20:30, Christian Ruppert
wrote:
>
On Friday 07 June 2013, Ezequiel Garcia wrote:
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -34,6 +34,51 @@
> compatible = "simple-bus";
> interrupt-parent = <&mpic>;
>
> + devbus-bootcs {
> +
On Friday 07 of June 2013 20:02:03 luke.leighton wrote:
> On Fri, Jun 7, 2013 at 9:57 AM, Tomasz Figa
wrote:
> >Seeing from your posts you don't have any knowledge on how Linux kernel
> >
> > development works
>
> check back to 2004.
$ git log --oneline --author="Luke Kenneth Casson Leighton"
On Friday 07 June 2013, Ezequiel Garcia wrote:
> + np = of_find_matching_node(NULL, of_mvebu_mbus_ids);
> + if (!np) {
> + pr_err("could not find a matching SoC family\n");
> + return -ENODEV;
> + }
> +
> + of_id = of_match_node(of_mvebu_mbus_ids,
On Friday 07 June 2013, Ezequiel Garcia wrote:
> This patch adds static window allocation to the device tree binding.
> Each first-child of the mbus-compatible node, with a suitable 'ranges'
> property, declaring an address translation, will trigger an address
> decoding window allocation.
>
> Sig
Hello,
On Fri, 7 Jun 2013 19:26:49 +0100, luke.leighton wrote:
> > Have you noticed that it is already the case in mainline?
>
> i knew there was a little bit, but not the extent of the commits.
Then you could probably use a bit of your time to read the kernel
commit logs rather than writing h
Luke,
I want only one thing from you at this time. See below.
On Fri, Jun 7, 2013 at 11:45 AM, luke.leighton wrote:
> but the Directors of Allwinner aren't been kept in the loop,
> here: that's my job, to get them up-to-speed.
The one job I would love for you to do instead of all this tr
On Fri, Jun 07, 2013 at 02:49:28PM +, joem wrote:
> > > SoC vendors are free to join the discussion, and many SoC vendors are part
> > > of the kernel community, so calling this unilateral is plain wrong.
> >
> > you're free to believe that, vladimir. i've explained why that
> > hasn't happe
Tomasz,
On Fri, Jun 7, 2013 at 10:42 AM, Tomasz Figa wrote:
> A question just out of curiousity: Is it really correct to have one vmmc
> regulator for the whole device, instead of one regulator per slot?
>
> This might be something obvious, but I don't know any details about
> dw_mmc, so sorry if
On Fri, Jun 07, 2013 at 06:03:54PM +0900, Alexandre Courbot wrote:
> On Fri, Jun 7, 2013 at 3:08 AM, Dave Martin wrote:
> >> I think we need to separate the concept of support for *a* secure
> >> monitor, from support for a *particular* secure monitor.
> >
> > There is no fixed set of functionalit
On Fri, 2013-06-07 at 19:07 +0400, Alexey Brodkin wrote:
> Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
> instantiated in some legacy ARC (Synopsys) FPGA Boards such as
> ARCAngel4/ML50x.
trivial comments only:
> diff --git a/drivers/net/ethernet/arc/arc_emac_main.c
> b/drive
Quoting Shawn Guo (2013-06-06 22:51:31)
> Mike,
>
> On Mon, Jun 03, 2013 at 10:53:07AM -0700, Mike Turquette wrote:
> > I am using this code while converting the OMAP4 clock data over to DT
>
> I see these basic clk bindings can be useful for platforms that have
> a relatively simple clock tree,
On Thu, Jun 06, 2013 at 12:29:14PM -0600, Stephen Warren wrote:
> On 06/06/2013 12:08 PM, Dave Martin wrote:
> > On Thu, Jun 06, 2013 at 10:44:48AM -0600, Stephen Warren wrote:
> >> On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
> >>> Boot loaders on some Tegra devices can be unlocked but do not
On Friday 07 June 2013, Jason Gunthorpe wrote:
> Sounds fair to me.
>
> But when we talk about multiple domains we don't mean a disjoint range
> bus bus numbers, as your other email shows:
>
> 00:00.0 PCI bridge: Samsung Electronics Co Ltd Device a549 (rev 01) (prog-if
> 00 [Normal decode])
> 10
On Friday 07 of June 2013 10:28:29 Doug Anderson wrote:
> It is possible to specify a regulator that should be turned on when
> dw_mmc is probed. At the moment dw_mmc will fail to use the regulator
> properly if the regulator probes after dw_mmc. Fix this problem by
> honoring EPROBE_DEFER.
>
>
On 06/07/2013 02:02 AM, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 2:10 PM, Russell King - ARM Linux
> wrote:
>
>> If companies are going to go off and invent the square wheel, and that
>> makes *them* suffer the loss of being able to merge back into the
>> mainline kernel, thereby making *the
On Fri, Jun 07, 2013 at 04:25:07PM +0900, Alexandre Courbot wrote:
> On Thu, Jun 6, 2013 at 8:02 PM, Dave Martin wrote:
>
> >> +static int __attribute__((used)) __tegra_smc_stack[10];
> >
> > Use __used instead of using GCC attributes directly.
> >
> >> +
> >> +/*
> >> + * With EABI, subtype and
As of now we rely on code outside of the driver to set the ciu clock
frequency. There's no reason to do that. Add support for setting up
the clock in the driver during probe.
Signed-off-by: Doug Anderson
Acked-by: Jaehoon Chung
---
Changes in v2:
- Added example as per Jaehoon.
.../devicetre
It is possible to specify a regulator that should be turned on when
dw_mmc is probed. At the moment dw_mmc will fail to use the regulator
properly if the regulator probes after dw_mmc. Fix this problem by
honoring EPROBE_DEFER.
At the same time move the regulator code out of the slot init code.
Dear Ezequiel Garcia,
On Fri, 7 Jun 2013 13:47:49 -0300, Ezequiel Garcia wrote:
> These properties are not needed so it's safe to remove them.
>
> Signed-off-by: Ezequiel Garcia
Acked-by: Thomas Petazzoni
I believe this one should be applied now, regardless of what happens to
the rest of the
Dear Ezequiel Garcia,
On Fri, 7 Jun 2013 13:47:38 -0300, Ezequiel Garcia wrote:
> In order to clean message printing, we replace pr_info with pr_fmt.
> This is purely cosmetic change, with the sole purpose of making
> the code a bit more readable.
>
> Signed-off-by: Ezequiel Garcia
Acked-by: T
Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-370-mirabox.dts | 32 +-
Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-xp-db.dts | 66 +
These properties are not needed so it's safe to remove them.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-370.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 1b11f1f..4fd483f 100644
--- a/arch
Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-370-xp.dtsi | 90 +++
The address decoding window to access the BootROM should not be
allocated programatically, but instead declared in the device tree.
Signed-off-by: Ezequiel Garcia
---
arch/arm/mach-mvebu/platsmp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mv
Now that mbus device tree binding has been introduced, remove the address
decoding window management from this driver.
A suitable 'ranges' entry should be added to the devbus-compatible node in
the device tree, as described by the mbus binding documentation.
Signed-off-by: Ezequiel Garcia
---
dr
In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/armada-370.dtsi | 6 ++
arch/arm/boot/dts/armada-xp.dtsi
Now that the mbus device tree binding has been introduced, we can
switch over to it.
Also, and since the initialization of the mbus driver is quite
fundamental for the system to work properly, this patch adds a BUG()
in case mbus fails to initialize.
Signed-off-by: Ezequiel Garcia
---
arch/arm/
The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.
This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behin
We introduce a common initialization function mvebu_mbus_common_init()
that will be used by both legacy and device-tree initialization code.
This patch is an intermediate step, which will allow to introduce the
DT binding for this driver in a less intrusive way.
Signed-off-by: Thomas Petazzoni
Si
This patch adds the most fundamental device-tree initialization.
We only introduce what's required to be able to probe the mvebu-mbus
driver from the DT. Follow-up patches will extend the device tree binding,
allowing to describe static address decoding windows.
Signed-off-by: Thomas Petazzoni
Si
Ideally 'ranges' entry should be added in device tree source files.
However, since those properties do not inherit the entries from included
files it would be a duplication hell, which means a nightmare to
maintain.
So, instead of hardcoding the required translation entries, we update
them program
This patch adds static window allocation to the device tree binding.
Each first-child of the mbus-compatible node, with a suitable 'ranges'
property, declaring an address translation, will trigger an address
decoding window allocation.
Signed-off-by: Ezequiel Garcia
---
.../devicetree/bindings/b
From: Ezequiel Garcia
This patchset introduces the MBus DT binding.
The MBus DT binding is in charge of several different tasks:
1. Allows the MBus driver to be probed through the Device Tree.
2. Allocates statically declared decoding windows, such as those
needed to access the BootRO
In order to clean message printing, we replace pr_info with pr_fmt.
This is purely cosmetic change, with the sole purpose of making
the code a bit more readable.
Signed-off-by: Ezequiel Garcia
---
drivers/bus/mvebu-mbus.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
On Fri, Jun 07, 2013 at 12:48:58PM +0100, James King wrote:
> Hi Lorenzo,
>
> On 7 June 2013 11:23, Lorenzo Pieralisi wrote:
> > Hi James,
> >
> > On Thu, Jun 06, 2013 at 06:11:25PM +0100, James King wrote:
> >> If CPUs are marked as disabled in the devicetree, make sure they do
> >> not exist in
On 06/07/2013 02:11 AM, Alexandre Courbot wrote:
> On Fri, Jun 7, 2013 at 1:44 AM, Stephen Warren wrote:
>> On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
>>> Boot loaders on some Tegra devices can be unlocked but do not let the
>>> system operate without SecureOS. SecureOS prevents access to so
On Fri, Jun 07, 2013 at 01:59:43PM +0200, Arnd Bergmann wrote:
> On Friday 07 June 2013 18:19:40 Jingoo Han wrote:
> > Hi Jason Gunthorpe,
> >
> > I implemented 'Single domain' with Exynos PCIe for last two months;
> > however, it cannot work properly due to the hardware restriction.
> > Each MEM
On Fri, Jun 07, 2013 at 03:20:20PM +0100, Rob Herring wrote:
> On 06/07/2013 05:23 AM, Lorenzo Pieralisi wrote:
> > Hi James,
> >
> > On Thu, Jun 06, 2013 at 06:11:25PM +0100, James King wrote:
> >> If CPUs are marked as disabled in the devicetree, make sure they do
> >> not exist in the system CP
On Friday 07 June 2013, Alexey Brodkin wrote:
> Driver for non-standard on-chip ethernet device ARC EMAC 10/100,
> instantiated in some legacy ARC (Synopsys) FPGA Boards such as
> ARCAngel4/ML50x.
>
> This is based off of current Linus tree, build tested for x86.
>
> Signed-off-by: Alexey Brodkin
On 7 June 2013 20:27, Heiko Stübner wrote:
> Am Freitag, 7. Juni 2013, 13:46:32 schrieb Linus Walleij:
>> On Thu, Jun 6, 2013 at 9:08 PM, Heiko Stübner wrote:
>> > There exist platforms, namely at least all Rockchip Cortex-A9 based ones,
>> > that don't use the paradigm of reading-changing-writin
On 7 June 2013 22:50, Mike Dunn wrote:
> On 06/06/2013 06:21 PM, Haojian Zhuang wrote:
>> On Fri, Jun 7, 2013 at 8:48 AM, Mike Dunn wrote:
>>> On 06/06/2013 04:58 PM, Haojian Zhuang wrote:
On 7 June 2013 01:33, Mike Dunn wrote:
>
>>>
>>>
>>> [...]
>>>
>>>
>
> Yes, but currently
Tomasz / Mark,
On Fri, Jun 7, 2013 at 3:30 AM, Tomasz Figa wrote:
> On Friday 07 of June 2013 11:24:04 Mark Brown wrote:
>> On Fri, Jun 07, 2013 at 12:19:58PM +0200, Tomasz Figa wrote:
>> > This interesting case makes me think that regulator core should
>> > differentiate between regulator lookup
On 7 June 2013 19:32, Christian Ruppert wrote:
> On Fri, Jun 07, 2013 at 08:00:57AM +0800, Haojian Zhuang wrote:
>> On 6 June 2013 23:30, Christian Ruppert wrote:
>> > On Thu, Jun 06, 2013 at 10:32:21PM +0800, Haojian Zhuang wrote:
>> >> On 6 June 2013 22:11, Christian Ruppert
>> >> wrote:
>> >
Thanks for the quick update.
I've just applied the series in my for_3.11/dts branch.
Regards,
Benoit
On 06/07/2013 03:22 PM, Sricharan R wrote:
> uevm is the only official board supported for OMAP5 soc in the mainline.
> This series deprecates the support for existent sevm which will no more
>
On 6/7/2013 1:12 PM, David Miller wrote:
From: Linus Walleij
Date: Fri, 7 Jun 2013 09:31:58 +0200
On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown wrote:
On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote:
On 6/6/2013 12:53 AM, Mark Brown wrote:
Linus Walleij posted some patches whic
On Fri, Jun 07, 2013 at 08:52:43AM +0100, luke.leighton wrote:
> coming back to what you said earlier: i'm formulating what to say to
> allwinner [and need to pre-send something by monday so that they can
> consider it before the meeting]. so far, it consists of:
>
> * device-tree is what the li
On 06/07/2013 05:23 AM, Lorenzo Pieralisi wrote:
> Hi James,
>
> On Thu, Jun 06, 2013 at 06:11:25PM +0100, James King wrote:
>> If CPUs are marked as disabled in the devicetree, make sure they do
>> not exist in the system CPU information and CPU topology information.
>> In this case these CPUs wi
Hi!
On 05/28/2013 05:08 PM, ext Jean-Christophe PLAGNIOL-VILLARD wrote:
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -131,6 +131,32 @@ void of_device_make_bus_id(struct device *dev)
> }
>
> /**
> + * of_device_alloc_irq - initialize irq of an platfrom_device
^
On Thu, Jun 6, 2013 at 9:11 PM, Heiko Stübner wrote:
> This driver adds support the Cortex-A9 based SoCs from Rockchip,
> so at least the RK2928, RK3066 (a and b) and RK3188.
> Earlier Rockchip SoCs seem to use similar mechanics for gpio
> handling so should be supportable with relative small cha
On Friday 07 June 2013 12:37:24 Alexey Brodkin wrote:
> On 06/07/2013 04:13 PM, Arnd Bergmann wrote:
> >>> I wonder if it would be better to name the directory "synopsys" or
> >>> "designware" rather than "arc" now. Is there a chance that the same
> >>> controller is used on non-arc CPUs?
> >>
> >>
Am Freitag, 7. Juni 2013, 13:46:32 schrieb Linus Walleij:
> On Thu, Jun 6, 2013 at 9:08 PM, Heiko Stübner wrote:
> > There exist platforms, namely at least all Rockchip Cortex-A9 based ones,
> > that don't use the paradigm of reading-changing-writing the register
> > contents, but instead only wri
Hi Keerthy,
On 06/07/2013 01:28 PM, J Keerthy wrote:
> Adds palmas mfd and palmas regulator nodes. This is
> based on the patch series:
>
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
>
> The device tree nodes are based on:
> https://lkml.org/lkml/2013/6/6/25
It looks l
On Friday 07 June 2013 10:42:28 Alexey Brodkin wrote:
> On 06/07/2013 12:47 PM, Arnd Bergmann wrote:
> > I wonder if it would be better to name the directory "synopsys" or
> > "designware" rather than "arc" now. Is there a chance that the same
> > controller is used on non-arc CPUs?
>
> The thing
On 06/06/2013 07:48 PM, Sricharan R wrote:
> uevm is the official board supported for OMAP5 soc in the mainline.
> This series renames the board dts file for OMAP5 accordingly and cleans
> up the same. Also a few additional device DT entry updates are done.
>
> This is on top of the below branch
>
Hi Sricharan,
On 06/06/2013 07:48 PM, Sricharan R wrote:
> The uevm is the official board supported for the OMAP5 soc
> in mainline. The uevm has an OMAP5432 with a DDR3 memory.
> Renaming the board dts file and adding the following cleanups.
OK, so in fact you are not just renaming the board fil
On Friday 07 June 2013 18:19:40 Jingoo Han wrote:
> Hi Jason Gunthorpe,
>
> I implemented 'Single domain' with Exynos PCIe for last two months;
> however, it cannot work properly due to the hardware restriction.
> Each MEM region is hard-wired.
>
> Thus, I will send Exynos PCIe V3 patch as 'Separ
Hi Nicolin,
On Fri, Jun 7, 2013 at 7:14 AM, Nicolin Chen wrote:
> + data->clk_frequency = clk_get_rate(data->codec_clk);
> + clk_prepare_enable(data->codec_clk);
Please check the return value from 'clk_prepare_enable()'
Regards,
Fabio Estevam
__
On 06/07/13 10:30, Thomas Petazzoni wrote:
On Thu, 6 Jun 2013 18:27:12 +0200, Sebastian Hesselbarth wrote:
- wdt@20300 {
+ wdt: watchdog-timer@20300 {
compatible = "marvell,orion-wdt";
reg = <0x20300 0x28>;
+
On Thu, Jun 6, 2013 at 9:08 PM, Heiko Stübner wrote:
> There exist platforms, namely at least all Rockchip Cortex-A9 based ones,
> that don't use the paradigm of reading-changing-writing the register contents,
> but instead only write the changes to the register with a mask that indicates
> the c
On Mon, Jun 3, 2013 at 11:42 AM, Christian Ruppert
wrote:
> Ease of use is also the reason why I added the gpio-base property to the
> original driver: Finding out the global GPIO number to use in
> /sys/class/gpio for a given GPIO of a given bank seems to be a recurring
> headache for our custom
Add pinmux configurations for RGMII based CPSW ethernet to am335x-evm.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Sleep mode is nothing but the values required for the module during
inactive state.
Add pinmux configurations for MII based CPSW ethernet to am335x-bone.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Sleep mode is nothing but the values required for the module during
inactive state.
Add pinmux DT nodes to CPSW for the following AM335x boards
* AM335x Beaglebone
* AM335x EVM
* AM335x EVMsk
default state contains the pinmux required for active mode and
sleep mode contains pinmux reset values for energy saving.
Mugunthan V N (3):
ARM: dts: AM33XX: Add pinmux configuration for
Add pinmux configurations for RGMII based CPSW ethernet to AM335x EVMsk.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Sleep mode is nothing but the values required for the module during
inactive stat
Hi,
On Fri, Jun 07 2013, Sekhar Nori wrote:
> + Chris since the patch has some davinci_mmc.c changes.
>
> Chris, Mark,
>
> On 3/6/2013 9:45 PM, Matt Porter wrote:
>> Move mach-davinci/dma.c to common/edma.c so it can be used
>> by OMAP (specifically AM33xx) as well.
>>
>> Signed-off-by: Matt Port
On Tue, May 21, 2013 at 4:08 PM, Manjunathappa, Prakash
wrote:
> Take care to name pin names as
> register-offset.bit-pos-of-pin-in-register in case configuring multiple
> pins in register.
>
> Signed-off-by: Manjunathappa, Prakash
Applied with Haojian and Tony's ACKs.
Thanks!
Linus Walleij
__
On Friday 07 June 2013 18:22:50 Jingoo Han wrote:
> diff --git a/Documentation/devicetree/bindings/pci/exynos-pcie.txt
> b/Documentation/devicetree/bindings/pci/exynos-pcie.txt
> new file mode 100644
> index 000..3eb4a2d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/exynos-pci
On Friday 07 of June 2013 11:24:04 Mark Brown wrote:
> On Fri, Jun 07, 2013 at 12:19:58PM +0200, Tomasz Figa wrote:
> > On Thursday 06 of June 2013 21:46:45 Doug Anderson wrote:
> > > dw_mmc is probed. This regulator is optional, though a warning will
> > > be printed if it's missing. The fact th
On Fri, Jun 07, 2013 at 06:14:13PM +0800, Nicolin Chen wrote:
> +Optional properties:
> +- hp-det-gpios : The gpio pin to detect plug in/out event that happens to
> + Headphone jack.
> +
> +- mic-det-gpios: The gpio pin to detect plug in/out event that happens to
> + Micphone jack.
So this is f
On Fri, Jun 07, 2013 at 12:19:58PM +0200, Tomasz Figa wrote:
> On Thursday 06 of June 2013 21:46:45 Doug Anderson wrote:
> > dw_mmc is probed. This regulator is optional, though a warning will
> > be printed if it's missing. The fact that the regulator is optional
> > means that (at the moment)
Hi James,
On Thu, Jun 06, 2013 at 06:11:25PM +0100, James King wrote:
> If CPUs are marked as disabled in the devicetree, make sure they do
> not exist in the system CPU information and CPU topology information.
> In this case these CPUs will not be able to be added to the system later
> using hot
1 - 100 of 128 matches
Mail list logo
