* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Russell King - ARM Linux @ 2013-01-29 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301291636.38773.arnd@arndb.de>
On Tue, Jan 29, 2013 at 04:36:38PM +0000, Arnd Bergmann wrote:
> If the pl080 driver already has code for the mux in it, then it should
> handle both of_dma_controller instances in my example. It would
> not change anything regarding the binding, which just describes the
> way that the hardware is connected. I have not looked at the implementation
> of the pl080 driver, but I'd assume we could get away with just having
> two separate xlate() functions.
Well, how it all works in the PL08x driver at present is:
- the platform code passes into the PL08x driver a description of the
virtual channels, eg:
[1] = {
/* Muxed on channel 0-3 */
.bus_id = "aacirx",
.min_signal = 0,
.max_signal = 2,
.muxval = 0x01,
.periph_buses = PL08X_AHB1 | PL08X_AHB2,
},
- the virtual channels include:
- the minimum and maximum index of the DMA request signals into the
PL08x that can be used with this peripheral.
- the the register value for the external mux, if any.
- other PL08x specific data to do with this DMA peripheral
- when a virtual channel is requested by a DMA client, it claims just
the virtual channel. No actual hardware resources are assigned,
and no mappings are setup.
- when a transfer is prepared on a virtual channel, part of the
preparation is to locate the request signal to be used - and
platform code is requested to supply that from the description
associated with the channel (such as the above fragment.)
- the versatile PL08x code looks at min_signal/max_signal, and walks
this space looking for an unassigned request signal. If there is
an external mux associated with this request signal, the mux is
appropriately programmed. If a request signal is currently assigned
the next request signal will be tried until there are no further
possibilities, when failure occurs. In that case, the prepare
function also fails.
- the PL08x driver then knows which request signal is associated with
the peripheral, and sets up the descriptors to be dependent on this
request signal. This mapping must not change until the transfer
has completed.
- when the descriptor is completed - and freed, the muxing is released
and the DMA request signal becomes available for other users to make
use of.
Practically, what this means is that:
(a) we've ensured that all drivers using PL08x do _not_ expect that
descriptors can always be prepared; they must continue to work correctly
when the prepare function returns NULL.
(b) several devices end up sharing the first three request signals
and they're used on an opportunistic basis. Theoretically, if you have
one of these boards where AACI DMA works, you can be using one of these
DMA requests for audio playback, another for record, and the remaining
one can be used on an opportunistic basis between the second MMCI
interface (should that also work - which I've proven is an impossiblity!)
and the 3rd UART... or the USB if there was a driver for that device.
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Bjorn Helgaas @ 2013-01-29 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129055508.GA3339@obsidianresearch.com>
On Mon, Jan 28, 2013 at 10:55 PM, Jason Gunthorpe
<jgunthorpe@obsidianresearch.com> wrote:
> On Mon, Jan 28, 2013 at 08:29:24PM -0700, Bjorn Helgaas wrote:
>> On Mon, Jan 28, 2013 at 11:56 AM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>> > This driver implements the support for the PCIe interfaces on the
>> > Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
>> > cover earlier families of Marvell SoCs, such as Dove, Orion and
>> > Kirkwood.
>> >
>> > The driver implements the hw_pci operations needed by the core ARM PCI
>> > code to setup PCI devices and get their corresponding IRQs, and the
>> > pci_ops operations that are used by the PCI core to read/write the
>> > configuration space of PCI devices.
>> >
>> > Since the PCIe interfaces of Marvell SoCs are completely separate and
>> > not linked together in a bus, this driver sets up an emulated PCI host
>> > bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
>> > interface.
>>
>> There's no Linux requirement that multiple PCIe interfaces appear to
>> be in the same hierarchy. You can just use pci_scan_root_bus()
>> separately on each interface. Each interface can be in its own domain
>> if necessary.
>
> What you suggest is basically what the Marvell driver did originally,
> the probelm is that Linux requires a pre-assigned aperture for each
> PCI domain/root bus, and these new chips have so many PCI-E ports that
> they can exhaust the physical address space, and also a limited
> internal HW resource for setting address routing.
>
> Thus they require resource allocation that is sensitive to the devices
> present downstream.
>
> By far the simplest solution is to merge all the physical links into a
> single domain and rely on existing PCI resource allocation code to
> drive allocation of scarce physical address space and demand allocate
> the HW routing resource (specifically there are enough resources to
> accomidate MMIO only devices on every bus, but not enough to
> accomidate MMIO and IO on every bus).
>
>> > +/*
>> > + * For a given PCIe interface (represented by a mvebu_pcie_port
>> > + * structure), we read the PCI configuration space of the
>> > + * corresponding PCI-to-PCI bridge in order to find out which range of
>> > + * I/O addresses and memory addresses have been assigned to this PCIe
>> > + * interface. Using these informations, we set up the appropriate
>> > + * address decoding windows so that the physical address are actually
>> > + * resolved to the right PCIe interface.
>> > + */
>>
>> Are you inferring the host bridge apertures by using the resources
>> assigned to devices under the bridge, i.e., taking the union of all
>
> The flow is different, a portion of physical address space is set
> aside for use by PCI-E (via DT) and that portion is specified in the
> struct resource's ultimately attached to the PCI domain for the bus
> scan. You could call that the 'host bridge aperture' though it doesn't
> reflect any HW configuration at all. The values come from the device
> tree.
I think I would understand this better if we had a concrete example to
talk about, say a dmesg log and corresponding lspci -v output.
As I understand it, the DT is a description of the hardware, so in
that sense, the DT can't set aside physical address space. It can
describe what the hardware does with the address space, and I assume
that's what you mean. Maybe the hardware isn't configurable, e.g., it
is hard-wired to route certain address ranges to PCIe?
> During the bus scan the Linux core code splits up that contiguous
> space and assigns to the PCI-PCI bridges and devices under that domain.
>
> Each physical PCI-E link on the chip is seen by Linux through the SW
> emulated PCI-PCI bridge attached to bus 0. When Linux configures the
> bridge windows it triggers this code here to copy that window
> information from the PCI config space into non-standard internal HW
> registers.
>
> The purpose of the SW PCI-PCI bridge and this code here is to give
> the Linux PCI core control over the window (MMIO,IO,busnr) assigned
> to the PCI-E link.
>
> This arrangement with PCI-PCI bridges controlling address routing is
> part of the PCI-E standard, in this instance Marvell did not implement
> the required config space in HW so the driver is working around that
> deficiency.
>
> Other drivers, like tegra have a similar design, but their hardware
> does implement PCI-PCI bridge configuration space and does drive
> address decoding through the HW PCI-PCI window registers.
>
> Having PCI-E links be bridges, not domains/root_bus's is in-line with
> the standard and works better with the Linux PCI resource allocator.
>
> Jason
^ permalink raw reply
* [GIT PULL] imx6q cpuidle for 3.9
From: Olof Johansson @ 2013-01-29 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129054635.GA21504@S2101-09.ap.freescale.net>
On Tue, Jan 29, 2013 at 01:46:37PM +0800, Shawn Guo wrote:
> The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
>
> Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
>
> are available in the git repository at:
>
> git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx6q-cpudile-3.9
>
> for you to fetch changes up to e510aafde64a3fdd741f598e4d2be3c079bf5b0e:
>
> ARM: imx6q: support WAIT mode using cpuidle (2013-01-29 13:41:42 +0800)
>
> ----------------------------------------------------------------
> It's imx6q cpuidle series for 3.9.
>
> ----------------------------------------------------------------
> Shawn Guo (4):
> ARM: imx: return zero in case next event gets a large increment
> ARM: imx: mask gpc interrupts initially
> ARM: imx: move imx6q_cpuidle_driver into a separate file
> ARM: imx6q: support WAIT mode using cpuidle
This has some small conflicts with the cleanup branch. Can you please base it
on top of cleanup so we can avoid the merge conflicts when things go upstream?
It's common to have the per-soc cleanup branches as bases for some of the
feature branches just for this reason.
Thanks!
-Olof
^ permalink raw reply
* [RFC] arm: use built-in byte swap function
From: Woodhouse, David @ 2013-01-29 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129174249.GB25415@pd.tnic>
On Tue, 2013-01-29 at 18:42 +0100, Borislav Petkov wrote:
> On Tue, Jan 29, 2013 at 04:46:58PM +0000, Woodhouse, David wrote:
> > If we're really going to have many different architectures depending
> > on different versions of GCC for this (if it wasn't sane to use
> > it from 4.4/4.8 when it got introduced, and depends on some later
> > arch-specific optimisation), then perhaps we'll have the arch
> > provide the corresponding required GCC_VERSION for using each of
> > 64/32/16 bit builtins, instead of just a yes/no flag? Or just define
> > __HAVE_BUILTIN_BSWAPxx__ for itself, perhaps?
>
> Damn, there's already the __powerpc__ thing in there.
That's different though. That's because GCC didn't have a generic
__builtin_bswap16() until 4.8, while PowerPC got it in 4.6.
That's a relatively simple and manageable one-off arch-dependency. But
once we get into a mass of "well, it wasn't actually *usable* for ARM
until 4.9", we start wanting to push it into arch code.
> But I liked your other suggestion better to get the offending
> compilers fixed.
That wasn't an *alternative*. It's required if the compiler is doing
something suboptimal, whatever happens. And then we start to *use* the
compiler from the first version that's known to be fixed.
--
Sent with MeeGo's ActiveSync support.
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4370 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/f29c0f6f/attachment.bin>
^ permalink raw reply
* [GIT PULL 1/4] ARM: bcm2835: cleanup
From: Olof Johansson @ 2013-01-29 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359441742-32647-1-git-send-email-swarren@wwwdotorg.org>
On Mon, Jan 28, 2013 at 11:42:19PM -0700, Stephen Warren wrote:
> This pull request simply converts the bcm2835 clocksource driver to use
> the recently added CLKSRC_OF feature.
>
> The branch is based on v3.8-rc3, followed by a merge of arm-soc's
> timer/cleanup branch.
>
> (For this and pull 4/4, feel free to cherry-pick the one commit if you
> want to avoid the short pull requests!)
>
> ----------------------------------------------------------------
>
> The following changes since commit b2fc382aad0a8f52803acdc3ac4e5540dbcdf1f6:
>
> Merge remote-tracking branch 'korg_arm-soc/timer/cleanup' into cleanup
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git bcm2835-for-3.9-cleanup
Thanks, pulled branch 1-4.
-Olof
^ permalink raw reply
* [PATCH 4/5] net: mvmdio: allow Device Tree and platform device to coexist
From: Jason Gunthorpe @ 2013-01-29 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-5-git-send-email-florian@openwrt.org>
On Tue, Jan 29, 2013 at 04:24:07PM +0100, Florian Fainelli wrote:
> - dev->err_interrupt = irq_of_parse_and_map(pdev->dev.of_node, 0);
> + if (pdev->dev.of_node) {
> + dev->regs = of_iomap(pdev->dev.of_node, 0);
> + if (!dev->regs) {
> + dev_err(&pdev->dev, "No SMI register address given in DT\n");
> + ret = -ENODEV;
> + goto out_free;
> + }
> +
> + dev->err_interrupt = irq_of_parse_and_map(pdev->dev.of_node, 0);
> + } else {
> + r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> + dev->regs = ioremap(r->start, resource_size(r));
> + if (!dev->regs) {
> + dev_err(&pdev->dev, "No SMI register address given\n");
> + ret = -ENODEV;
> + goto out_free;
> + }
> +
> + dev->err_interrupt = platform_get_irq(pdev, 0);
> + }
Why do you have these different paths for OF and platform? AFAIK these
days when a OF device is automatically converted into a platform
device all the struct resources are created too, so you can't you just
use platform_get_resource and devm_request_and_ioremap for both flows?
Ditto for the interrupt - platform_get_irq should work in both cases?
Jason
^ permalink raw reply
* Section mismatch in drivers/mfd/vexpress-sysreg.c
From: Olof Johansson @ 2013-01-29 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129131244.GU23505@n2100.arm.linux.org.uk>
On Tue, Jan 29, 2013 at 01:12:45PM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 29, 2013 at 01:05:11PM +0000, Pawel Moll wrote:
> > On Tue, 2013-01-29 at 11:55 +0000, Shawn Guo wrote:
> > > I'm building v3.8-rc5 and seeing the following section mismatch warning
> > > in drivers/mfd/vexpress-sysreg.c.
> > >
> > > WARNING: drivers/mfd/built-in.o(.text+0x3108): Section mismatch in reference from the function vexpress_sysreg_probe() to the function .init.text:vexpress_sysreg_setup()
> > > The function vexpress_sysreg_probe() references
> > > the function __init vexpress_sysreg_setup().
> > > This is often because vexpress_sysreg_probe lacks a __init
> > > annotation or the annotation of vexpress_sysreg_setup is wrong.
> >
> > Arnd's got a fix for this already:
> >
> > https://patchwork.kernel.org/patch/2046991/
>
> Adding arm-soc people...
>
> Which wasn't in yesterday's arm-soc though, as highlighted by last night's
> autobuild (the build tree was created at 9:28am yesterday, which'll be
> just after my arm-soc pull).
Right. I checked it in as commit e065d3d417274bafed162b3dffd2e03a5128623c
yesterday, it's in 'fixes' as well as in for-next. It wasn't checked in until
3pm Pacific time though, so it missed your build.
Let me know if it isn't fixed by tonight's build.
-Olof
^ permalink raw reply
* [GIT PULL] Samsung fixes-4 for v3.8
From: Kukjin Kim @ 2013-01-29 18:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
Here is a pull request for Samsung fixes-4 for v3.8.
This fixes compatible values for exynos pinctrl and crash on soft reset,
tick and alarm irq numbers on exynos5440 and uninitialized variable on
s3c24xx.
If any problems, please kindly let me know.
Thanks.
- Kukjin
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
v3.8-samsung-fixes-4
for you to fetch changes up to 60db7e5f9c9a25a7a9b01007e6e3f5a93bc16a3a:
ARM: EXYNOS: Fix crash on soft reset on EXYNOS5440 (2013-01-28 14:27:50
-0800)
----------------------------------------------------------------
Cong Ding (1):
ARM: S3C24XX: fix uninitialized variable warning
Giridhar Maruthy (1):
ARM: dts: fix tick and alarm irq numbers for exynos5440
Kukjin Kim (1):
ARM: dts: fix compatible value for exynos pinctrl
Thomas Abraham (2):
ARM: dts: Fix compatible value of pinctrl module on EXYNOS5440
ARM: EXYNOS: Fix crash on soft reset on EXYNOS5440
Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 12
++++++------
arch/arm/boot/dts/exynos4210.dtsi | 6 +++---
arch/arm/boot/dts/exynos4x12.dtsi | 8
++++----
arch/arm/boot/dts/exynos5440.dtsi | 4 ++--
arch/arm/mach-exynos/common.c | 10
++++++----
arch/arm/mach-s3c24xx/common.c | 2 +-
drivers/gpio/gpio-samsung.c | 6 +++---
drivers/pinctrl/pinctrl-samsung.c | 4 ++--
8 files changed, 27 insertions(+), 25 deletions(-)
^ permalink raw reply
* [GIT PULL] ux500 <mach/id.h> removal
From: Linus Walleij @ 2013-01-29 18:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC maintainers,
This patch set removes the use of <mach/id.h> from being broadcasted across
the kernel and blocks any further usage of cpu_is* outside of the machine.
Target is v3.9 cleanups.
It is part of our path toward single zImage.
Please pull it in! Detailed description in the tag, MFD hunk ACKed by
Samuel Ortiz.
Yours,
Linus Walleij
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/ux500-no-idh
for you to fetch changes up to 7a4f26097d389c16c9956bc03b81532698d97d64:
ARM: ux500: de-globalize <mach/id.h> (2013-01-29 18:47:37 +0100)
----------------------------------------------------------------
Removal of the <mach/id.h> include from ux500
- First an ACKed MFD patch deleting the only consumer
of these cpu_is* functions outside of mach-ux500
- Introduce a new local cpu_is_u8580() in this patch
set to avoid clashing with other patch sets.
- Finally de-globalize <mach/id.h>.
----------------------------------------------------------------
Linus Walleij (2):
mfd: prcmu: delete pin control helpers
ARM: ux500: de-globalize <mach/id.h>
Maxime Coquelin (1):
ARM: ux500: Introduce cpu_is_u8580()
arch/arm/mach-ux500/board-mop500-uib.c | 1 +
arch/arm/mach-ux500/cache-l2x0.c | 3 +-
arch/arm/mach-ux500/cpu-db8500.c | 2 +
arch/arm/mach-ux500/cpu.c | 1 +
arch/arm/mach-ux500/id.c | 2 +
arch/arm/mach-ux500/{include/mach => }/id.h | 21 +++++++-
arch/arm/mach-ux500/include/mach/hardware.h | 1 -
arch/arm/mach-ux500/platsmp.c | 3 ++
arch/arm/mach-ux500/timer.c | 2 +
drivers/cpufreq/db8500-cpufreq.c | 3 --
drivers/mfd/db8500-prcmu.c | 17 +++---
include/linux/mfd/db8500-prcmu.h | 6 ---
include/linux/mfd/dbx500-prcmu.h | 81 -----------------------------
13 files changed, 39 insertions(+), 104 deletions(-)
rename arch/arm/mach-ux500/{include/mach => }/id.h (85%)
^ permalink raw reply
* [PATCH 6/7] ARM: DT: tegra114:add aliases and DMA requestor for serial controller
From: Stephen Warren @ 2013-01-29 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359464183-6255-7-git-send-email-ldewangan@nvidia.com>
On 01/29/2013 05:56 AM, Laxman Dewangan wrote:
> Add APB DMA requestor and serial aliases for serial controller.
> There will be two serial driver i.e. 8250 based simple serial driver
> and APB DMA based serial driver for higher baudrate and performace.
>
> The simple serial driver get enabled with compatible nvidia,tegra20-uart
> and APB DMA based driver will get enabled with compatible
> nvidia,tegra30-hsuart.
I also can't apply this patch yet since it depends on the APB DMA DT
node which as I mentioned I'm not apply yet.
^ permalink raw reply
* [RFC] arm: use built-in byte swap function
From: Borislav Petkov @ 2013-01-29 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359482147.3529.161.camel@shinybook.infradead.org>
On Tue, Jan 29, 2013 at 05:55:54PM +0000, Woodhouse, David wrote:
> That's different though. That's because GCC didn't have a generic
> __builtin_bswap16() until 4.8, while PowerPC got it in 4.6.
>
> That's a relatively simple and manageable one-off arch-dependency. But
> once we get into a mass of "well, it wasn't actually *usable* for ARM
> until 4.9", we start wanting to push it into arch code.
Yeah, and once people see one arch mentioned, all of a sudden they think
it is ok to add just one more ...
> > But I liked your other suggestion better to get the offending
> > compilers fixed.
>
> That wasn't an *alternative*. It's required if the compiler is doing
> something suboptimal, whatever happens. And then we start to *use* the
> compiler from the first version that's known to be fixed.
So, IMHO it sounds to me like we want to explicitly state for each arch
separately that it is ok to use the __builtin_bswapXX things. This also
takes care of the case where the compiler is doing something suboptimal
by excluding the affected versions.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
^ permalink raw reply
* [PATCH 5/5] mv643xx_eth: convert to use the Marvell Orion MDIO driver
From: Jason Gunthorpe @ 2013-01-29 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-6-git-send-email-florian@openwrt.org>
On Tue, Jan 29, 2013 at 04:24:08PM +0100, Florian Fainelli wrote:
> This patch converts the Marvell MV643XX ethernet driver to use the
> Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
> registering the Marvell MV643XX ethernet driver are also updated to
> register a Marvell Orion MDIO driver. This driver voluntarily overlaps
> with the Marvell Ethernet shared registers because it will use a subset
> of this shared register (shared_base + 0x4 - shared_base + 0x84). The
> Ethernet driver is also updated to look up for a PHY device using the
> Orion MDIO bus driver.
Can you finish off this job by making the mv643xx_eth driver accept
the standard phy-handle OF property instead of using a phy address?
Ie the end result should be something like:
smi0: mdio at 72000 {
device_type = "mdio";
compatible = "marvell,orion-mdio";
reg = <0x72004 0x4>;
#address-cells = <1>;
#size-cells = <0>;
PHY1: ethernet-phy at 1 {
reg = <1>;
device_type = "ethernet-phy";
phy-id = <0x01410e90>;
};
};
egiga0 {
device_type = "network";
compatible = "marvell,mv643xx-eth";
reg = <0x72000 0x4000>;
port_number = <0>;
phy-handle = <&PHY1>;
interrupts = <11>;
local-mac-address = [000000000002]; /* Filled by boot loader */
};
Regards,
Jason
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-29 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo7gCFfLB6+ebvANQjkr7Bii8Jqt3y5YqExD-DcnBG7hgA@mail.gmail.com>
Dear Bjorn Helgaas,
On Tue, 29 Jan 2013 10:47:09 -0700, Bjorn Helgaas wrote:
> I think I would understand this better if we had a concrete example to
> talk about, say a dmesg log and corresponding lspci -v output.
Please note that the cover letter of this patch series has the lspci
-vvv output.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 5/5] ARM: ux500: select the DB8540 pin controller
From: Linus Walleij @ 2013-01-29 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128230059.GE7789@quad.lixom.net>
On Tue, Jan 29, 2013 at 12:00 AM, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Jan 28, 2013 at 02:52:31PM +0100, Linus Walleij wrote:
>> From: Linus Walleij <linus.walleij@linaro.org>
>>
>> The pin controller is an inherent part of the SoC, without
>> it the system will not boot, thus it needs to be selected
>> from Kconfig.
>>
>> Cc: arm at kernel.org
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> Requesting ACK from ARM SoC on this patch.
>
> Acked-by: Olof Johansson <olof@lixom.net>
Thanks!
> ... but I wonder if this is growing out of hand. Since they will always
> be selected (and required) for UX500_SOC_DB8500, why not just make them
> silent options that default to y with that as a depend?
So either I do it like this by using select FOO in the
Kconfig for the affected SoC, or I just turn it around
and make it depend on the affected SoC and select it
to "y" default.
It's like eating eggs from the little or big end or something.
This current approach has the upside of not proliferating
the SoC Kconfig symbol outside of the ARM tree, but
I have no strong preference...
All this stuff used to live in the arch/arm/mach-foo
folders in the past, like the clocks you just have to
default-enable it somehow.
Linus Walleij
^ permalink raw reply
* [GIT PULL] vexpress: fixes for v3.9
From: Pawel Moll @ 2013-01-29 18:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
are available in the git repository at:
git://git.linaro.org/people/pawelmoll/linux.git tags/vexpress/fixes-for-3.9
for you to fetch changes up to aab7da708649388afc041b173e7d2cf0c4b27e50:
ARM: vexpress: Fix wdt interrupt in ca15{-tc1,_a7} dts (2013-01-29 18:20:28 +0000)
----------------------------------------------------------------
Versatile Express related fixes for 3.9
* Correct interrupt definitions for WDT node in
V2P-CA15 and V2P-CA15_A7 Device Trees
----------------------------------------------------------------
Mark Rutland (1):
ARM: vexpress: Fix wdt interrupt in ca15{-tc1,_a7} dts
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [GIT PULL] vexpress: drivers for v3.9
From: Pawel Moll @ 2013-01-29 18:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
are available in the git repository at:
git://git.linaro.org/people/pawelmoll/linux.git tags/vexpress/drivers-for-3.9
for you to fetch changes up to d299d4b5c95d37df0a8964930a3586f8d3cdb4ef:
arm: Move sp810.h to include/linux/amba/ (2013-01-29 18:13:24 +0000)
----------------------------------------------------------------
Versatile Express related driver updates for 3.9:
* Move sp810 header to a more generic location,
mainly to share it with arm64
* Add pseudo-GPIO lines (and equivalent gpio LED definitions)
to control LEDs on vexpress motherboard.
----------------------------------------------------------------
Catalin Marinas (1):
arm: Move sp810.h to include/linux/amba/
Pawel Moll (1):
mfd: vexpress: Add pseudo-GPIO based LEDs
arch/arm/plat-spear/restart.c | 2 +-
drivers/clk/versatile/clk-vexpress.c | 3 +-
drivers/mfd/vexpress-sysreg.c | 73 +++++++++++++++-----
.../asm/hardware => include/linux/amba}/sp810.h | 0
include/linux/vexpress.h | 8 +++
5 files changed, 65 insertions(+), 21 deletions(-)
rename {arch/arm/include/asm/hardware => include/linux/amba}/sp810.h (100%)
^ permalink raw reply
* [GIT PULL] Samsung fixes-4 for v3.8
From: Olof Johansson @ 2013-01-29 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <06c601cdfe4b$01ef8890$05ce99b0$@samsung.com>
On Tue, Jan 29, 2013 at 10:03:54AM -0800, Kukjin Kim wrote:
> Hi Arnd and Olof,
>
> Here is a pull request for Samsung fixes-4 for v3.8.
>
> This fixes compatible values for exynos pinctrl and crash on soft reset,
> tick and alarm irq numbers on exynos5440 and uninitialized variable on
> s3c24xx.
>
> If any problems, please kindly let me know.
>
> Thanks.
>
> - Kukjin
>
> The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
>
> Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v3.8-samsung-fixes-4
Pulled, but...
> for you to fetch changes up to 60db7e5f9c9a25a7a9b01007e6e3f5a93bc16a3a:
>
> ARM: EXYNOS: Fix crash on soft reset on EXYNOS5440 (2013-01-28 14:27:50
> -0800)
>
> ----------------------------------------------------------------
> Cong Ding (1):
> ARM: S3C24XX: fix uninitialized variable warning
Hm, that whole loop looks bogus. The compiler is still free to optimize
it away since 'tmp' isn't actually used anywhere. It's just not good
enough at it yet. :)
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mvebu fixes for v3.8-rc6
From: Olof Johansson @ 2013-01-29 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359472708.4cD60.22570@triton>
On Tue, Jan 29, 2013 at 03:18:28PM +0000, Jason Cooper wrote:
> The following changes since commit 09d75bc7d217bd8868899028a98b53423e6b3324:
>
> ARM: kirkwood: fix missing #interrupt-cells property (2013-01-23 01:10:48 +0000)
>
> are available in the git repository at:
>
> git://git.infradead.org/users/jcooper/linux.git tags/mvebu_fixes_for_v3.8-rc6
Pulled, but:
>
> for you to fetch changes up to de27686b77f1c5c5dddf06d48fd322c52f098d51:
>
> arm: mvebu: i2c come back in defconfig (2013-01-23 15:05:11 +0000)
>
> ----------------------------------------------------------------
> fixes for v3.8-rc6
>
> - add missing gpio interrupt lines to dove dt
> - fix bad logic for printing MPP error message on orion boards
> - build proper serial port driver after changing mvebu DT compatible property
> - This is a change to mvebu_defconfig that I wouldn't usually push out as a
> fix. However, the commit
>
> b24212f arm: mvebu: Use dw-apb-uart instead of ns16650 as UART driver
>
> changed the serial driver for the board in the dts file. without the patch
> I've included in this pull, users won't see any log messages.
>
> ----------------------------------------------------------------
> Gerlando Falauto (1):
> arm: plat-orion: fix printing of "MPP config unavailable on this hardware"
>
> Gregory CLEMENT (1):
> arm: mvebu: i2c come back in defconfig
>
> Jean-Francois Moine (1):
> Dove: activate GPIO interrupts in DT
Please keep an eye on the patch subjects you apply. We're trying to standardize
on "ARM: dove: <...>", etc.
-Olof
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Jason Gunthorpe @ 2013-01-29 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo7gCFfLB6+ebvANQjkr7Bii8Jqt3y5YqExD-DcnBG7hgA@mail.gmail.com>
On Tue, Jan 29, 2013 at 10:47:09AM -0700, Bjorn Helgaas wrote:
> As I understand it, the DT is a description of the hardware, so in
> that sense, the DT can't set aside physical address space. It can
> describe what the hardware does with the address space, and I assume
> that's what you mean. Maybe the hardware isn't configurable, e.g., it
> is hard-wired to route certain address ranges to PCIe?
The DT is largely a description of the hardware, but when it comes to
addresses, particularly HW programmable addresess, there is an general
expectation that the driver/bootloader will program HW address
decoders to either match the addresses given in the DT, or to new
values guided by the DT addresses.
In a real sense that means the DT also describes the physical address
map the kernel should use.
In the PCI-E case the DT PCI-E HW description includes physical
address ranges to use for the MMIO/IO/PREFETCH PCI-E interface windows
and the driver is expected to program the internal HW address decoders
based on those address ranges.
The catch is that the hardware decoders are on a link-by-link basis,
not on a root-complex basis, so the programming can only take place
once the Linux kernel has done PCI resource assignment.
So when I say set aside, I mean for instance, the PCI-E entry in DT
has 128M of physical address space marked for PCI MMIO use. The kernel
does PCI resource allocation and the HW decoders in each link will be
set to claim some portion of the 128M - based on the MMIO windows
programmed on the PCI-PCI root port bridges. The reamining part of the
128M is dead address space, not claimed by any hardware block at all.
Jason
^ permalink raw reply
* [PATCH v3 14/15] ARM: vexpress/dcscb: handle platform coherency exit/setup and CCI
From: Nicolas Pitre @ 2013-01-29 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129104642.GK30563@e102568-lin.cambridge.arm.com>
On Tue, 29 Jan 2013, Lorenzo Pieralisi wrote:
> On Tue, Jan 29, 2013 at 07:51:09AM +0000, Nicolas Pitre wrote:
>
> [...]
>
> > + /*
> > + * Flush the local CPU cache.
> > + *
> > + * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
> > + * a preliminary flush here for those CPUs. At least, that's
> > + * the theory -- without the extra flush, Linux explodes on
> > + * RTSM (maybe not needed anymore, to be investigated).
> > + */
> > + flush_cache_louis();
>
> This is not needed. If it is, that is a model bug and should be flagged
> up as such.
Could someone at ARM do that?
I just confirmed that this is still the case by commenting out the
preliminary flush calls and hot-plugging CPUs out and back. Result is a
non-sensical kernel oops which has the looks of serious memory
corruption. This is with RTSM version 7.1.42.
> > + cpu_proc_fin(); /* disable allocation into internal caches*/
>
> This code disables the I-cache causing following instruction fetches from
> DRAM; that is extremely slow and should be avoided, there is no point in
> disabling the I-cache here, that is not required.
> On fast-models that's a non-issue, but I really want to prevent copy'n'paste
> of this sequence as it stands.
Agreed, I'll change that. The (not included in this series) TC2 backend
does leave the I-cache active already.
> > diff --git a/arch/arm/mach-vexpress/dcscb_setup.S b/arch/arm/mach-vexpress/dcscb_setup.S
> > new file mode 100644
> > index 0000000000..cac033b982
> > --- /dev/null
> > +++ b/arch/arm/mach-vexpress/dcscb_setup.S
> > @@ -0,0 +1,80 @@
> > +/*
> > + * arch/arm/include/asm/dcscb_setup.S
> > + *
> > + * Created by: Dave Martin, 2012-06-22
> > + * Copyright: (C) 2012-2013 Linaro Limited
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +
> > +#include <linux/linkage.h>
> > +#include <asm/mcpm_entry.h>
> > +
> > +
> > +#define SLAVE_SNOOPCTL_OFFSET 0
> > +#define SNOOPCTL_SNOOP_ENABLE (1 << 0)
> > +#define SNOOPCTL_DVM_ENABLE (1 << 1)
> > +
> > +#define CCI_STATUS_OFFSET 0xc
> > +#define STATUS_CHANGE_PENDING (1 << 0)
> > +
> > +#define CCI_SLAVE_OFFSET(n) (0x1000 + 0x1000 * (n))
> > +
> > +#define RTSM_CCI_PHYS_BASE 0x2c090000
> > +#define RTSM_CCI_SLAVE_A15 3
> > +#define RTSM_CCI_SLAVE_A7 4
>
> We need to remove these hardcoded values in due course as you know, I am
> working on new code that allows us to match the CCI port address to
> MPIDR on resume.
Yes, absolutely. I was expecting this code to become generic and more
closely tied to the CCI driver. The CCI init
code could set up variables to be used by this code.
Nicolas
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: John Stultz @ 2013-01-29 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51076FA2.9070002@ti.com>
On 01/28/2013 10:43 PM, Santosh Shilimkar wrote:
> Jon,
>
> On Tuesday 29 January 2013 05:31 AM, John Stultz wrote:
>> On 01/27/2013 10:08 PM, Santosh Shilimkar wrote:
>>> On Tuesday 22 January 2013 08:35 PM, Santosh Shilimkar wrote:
>>>> On Tuesday 22 January 2013 08:21 PM, Russell King - ARM Linux wrote:
>>>>> On Tue, Jan 22, 2013 at 03:44:03PM +0530, Santosh Shilimkar wrote:
>
> [..]
>
>>>> Thanks for expanding it. It is really helpful.
>>>>
>>>>> And I think further discussion is pointless until such research has
>>>>> been
>>>>> done (or someone who _really_ knows the time keeping/timer/sched code
>>>>> inside out comments.)
>>>>>
>>>> Fully agree about experimentation to re-asses the drift.
>>>> From what I recollect from past, few OMAP customers did
>>>> report the time drift issue and that is how the switch
>>>> from 100 --> 128 happened.
>>>>
>>>> Anyway I have added the suggested task to my long todo list.
>>>>
>>> So I tried to see if any time drift with HZ = 100 on OMAP. I ran the
>>> setup for 62 hours and 27 mins with time synced up once with NTP
>>> server.
>>> I measure about ~174 millisecond drift which is almost noise
>>> considering
>>> the observed duration was ~224820000 milliseconds.
>>
>> So 174ms drift doesn't sound great, as < 2ms (often much less - though
>> that depends on how close the server is) can be expected with NTP.
>> Although its not clear how you were measuring: Did you see a max 174ms
>> offset while trying to sync with NTP? Was that offset shortly after
>> starting NTP or after NTP converged down?
>>
> To avoid the server latency, we didn't do continuous sync. The time
> was synced in the beginning and after 62.5 hours (#ntpd -qg) and the
> drift
> of about 174 ms was observed. As you said this could be because of
> server sync time along with probably some addition from system calls
> from #ntpd.
Ahh.. Ok. Thanks for the clarification. After a one time sync, ~774ppb
drift is surprisingly good!
> As mentioned, the other run with HZ = 128 which started
> 15 hours 20 mins is already showing about 24 mS drift now. I will
> let it run for couple of more days just to have similar duration run.
Yea, this is also great drift wise (but its not surprising, as both
cases we're keeping time off of the same clocksource, and HZ shouldn't
come into play). But its good to have the timekeeping side validated.
thanks
-john
^ permalink raw reply
* [PATCHv1 for soc 5/5] arm: socfpga: Add SMP support for actual socfpga harware
From: Pavel Machek @ 2013-01-29 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359075633-13502-6-git-send-email-dinguyen@altera.com>
Hi!
> index 9941caa..5b76dd4 100644
> --- a/arch/arm/mach-socfpga/core.h
> +++ b/arch/arm/mach-socfpga/core.h
> @@ -20,7 +20,7 @@
> #ifndef __MACH_CORE_H
> #define __MACH_CORE_H
>
> -extern void secondary_startup(void);
> +extern void v7_secondary_startup(void);
> extern void __iomem *socfpga_scu_base_addr;
>
One more thing. v7_secondary_startup() may be too generic name for a
symbol. mach-imx already uses that.
Plus, mach-imx also has the useless #ifdef.
---
Remove useless #ifdef; headsmp.S is only compiled in CONFIG_SMP
configuration.
Signed-off-by: Pavel Machek <pavel@denx.de>
diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S
index 7e49deb..4c9ec06 100644
--- a/arch/arm/mach-imx/headsmp.S
+++ b/arch/arm/mach-imx/headsmp.S
@@ -64,12 +64,10 @@ ENTRY(v7_invalidate_l1)
mov pc, lr
ENDPROC(v7_invalidate_l1)
-#ifdef CONFIG_SMP
ENTRY(v7_secondary_startup)
bl v7_invalidate_l1
b secondary_startup
ENDPROC(v7_secondary_startup)
-#endif
#ifdef CONFIG_PM
/*
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply related
* i.Mx6Quad - eth0: tx queue full!
From: Troy Kisky @ 2013-01-29 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5107FA00.2010809@gmail.com>
On 1/29/2013 9:34 AM, Vikram Narayanan wrote:
> On 1/29/2013 1:17 AM, Troy Kisky wrote:
>> On 1/28/2013 10:39 AM, Vikram Narayanan wrote:
>>> Running the latest head <linux-2.6.git> on an i.Mx6Quad based platform
>>> gives me the below error when flooded with ping requests.
>>>
>>> == Start log ==
>>> [ 2555.004031] ------------[ cut here ]------------
>>> [ 2555.009740] WARNING: at net/sched/sch_generic.c:254
>>> dev_watchdog+0x298/0x2b8()
>>> [ 2555.018721] NETDEV WATCHDOG: eth0 (fec): transmit queue 0 timed out
>>
>> I think the tx interrupt status bit was lost. The packets were
>> transmitted, but the interrupt never
>> happened. The controller should have been reset here, but perhaps a bug
>> with the reset code.
>> Are you using the mainline kernel, or a version Freescale's kernel.
>
> I tried with both the kernels. Freescale's and mainline results in the
> same error.
>
>> mainline fec_restart does not reset tx_full
>>
>> You can try adding
>> fep->tx_full = 0;
>
> With this there was no improvement.
I have fixed this bug (and more) on Freescale's kernel
(imx-3.0.35_1.1.0). I created a branch you can try.
Feel free to port to mainline.
This is the patch that should fix your problem
fec: clear TX_FULL in fec_restart
git://github.com/boundarydevices/linux-imx6.git ethernet_test
Please let me know results.
Thanks
Troy
^ permalink raw reply
* [PATCH 5/5] ARM: ux500: select the DB8540 pin controller
From: Olof Johansson @ 2013-01-29 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZuu0skVSPV5qcUx3g5UYGxzigeCDkN_NeuNB+Ak8m3wQ@mail.gmail.com>
On Tue, Jan 29, 2013 at 10:16 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Tue, Jan 29, 2013 at 12:00 AM, Olof Johansson <olof@lixom.net> wrote:
>> On Mon, Jan 28, 2013 at 02:52:31PM +0100, Linus Walleij wrote:
>>> From: Linus Walleij <linus.walleij@linaro.org>
>>>
>>> The pin controller is an inherent part of the SoC, without
>>> it the system will not boot, thus it needs to be selected
>>> from Kconfig.
>>>
>>> Cc: arm at kernel.org
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>> Requesting ACK from ARM SoC on this patch.
>>
>> Acked-by: Olof Johansson <olof@lixom.net>
>
> Thanks!
>
>> ... but I wonder if this is growing out of hand. Since they will always
>> be selected (and required) for UX500_SOC_DB8500, why not just make them
>> silent options that default to y with that as a depend?
>
> So either I do it like this by using select FOO in the
> Kconfig for the affected SoC, or I just turn it around
> and make it depend on the affected SoC and select it
> to "y" default.
>
> It's like eating eggs from the little or big end or something.
>
> This current approach has the upside of not proliferating
> the SoC Kconfig symbol outside of the ARM tree, but
> I have no strong preference...
>
> All this stuff used to live in the arch/arm/mach-foo
> folders in the past, like the clocks you just have to
> default-enable it somehow.
Hm. Damned if we do, damned if we don't.
Well, the slightly awkward part is probably that we split them up in a
bunch of Kconfig options that we need to select, but at the end of the
day, they are all either selected or unselected together. So the
granularity just means more Kconfig select lines.
Still, not a horrible problem, it just started to look at bit
excessive in the arch/arm/mach-* Kconfig.
-Olof
^ permalink raw reply
* [PATCH RESEND] ARM: EXYNOS: dts: Set up power domain for MFC and G-scaler
From: Kukjin Kim @ 2013-01-29 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359453320-14911-1-git-send-email-prasanna.ps@samsung.com>
Prasanna Kumar wrote:
>
> This patch adds device tree nodes for MFC and G-scaler power
> domains of exynos5250.It binds these power-domain nodes to repsective
> device tree nodes
>
> It also adds support to enable PM generic domains for exynos5250.
>
> Signed-off-by: Prasanna Kumar <prasanna.ps@samsung.com>
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 15 +++++++++++++++
> arch/arm/mach-exynos/Kconfig | 1 +
> 2 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 30485de..6d0e87c 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -85,6 +85,7 @@
> compatible = "samsung,mfc-v6";
> reg = <0x11000000 0x10000>;
> interrupts = <0 96 0>;
> + samsung,power-domain = <&pd_mfc>;
> };
>
> rtc {
> @@ -554,28 +555,42 @@
> };
> };
>
> + pd_gsc: gsc-power-domain at 0x10044000 {
> + compatible = "samsung,exynos4210-pd";
> + reg = <0x10044000 0x20>;
> + };
> +
> + pd_mfc: mfc-power-domain at 0x10044040 {
> + compatible = "samsung,exynos4210-pd";
> + reg = <0x10044040 0x20>;
> + };
> +
Please put the above nodes by order of address.
> gsc_0: gsc at 0x13e00000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e00000 0x1000>;
> interrupts = <0 85 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> gsc_1: gsc at 0x13e10000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e10000 0x1000>;
> interrupts = <0 86 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> gsc_2: gsc at 0x13e20000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e20000 0x1000>;
> interrupts = <0 87 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> gsc_3: gsc at 0x13e30000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e30000 0x1000>;
> interrupts = <0 88 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> hdmi {
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-
> exynos/Kconfig
> index e103c29..96f4a9f 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -61,6 +61,7 @@ config SOC_EXYNOS5250
> bool "SAMSUNG EXYNOS5250"
> default y
> depends on ARCH_EXYNOS5
> + select PM_GENERIC_DOMAINS if PM
> select S5P_PM if PM
> select S5P_SLEEP if PM
> select S5P_DEV_MFC
> --
> 1.7.5.4
^ 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