* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Jean-Jacques Hiblot @ 2014-01-22 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaAe7M3RjOiOrs9-bF5p80mshxbcNwKoDSMAXJ+5D27Ew@mail.gmail.com>
2014/1/22 Linus Walleij <linus.walleij@linaro.org>:
> On Wed, Jan 15, 2014 at 6:28 PM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
>> On 13/01/2014 11:35, boris brezillon :
>
>>> You should only request it as a GPIO and then use gpio_to_irq to get the
>>> related IRQ.
>>> Because what is done here, is to solve the case where only the irq
>>> is request, and in this specific case we need to request the pin as a
>>> GPIO.
>>
>> Yes, this is what we do.
>>
>> It seems simple and obvious to me, but some may say that "you shall not
>> do that, it is horrible!". Well... I always tend to choose a solution
>> that works. It is one of my weaknesses, I admit ;-)
>>
>> Linus W. any advice on this, before we hit again one of those infinite
>> threads that leads no progress at all?
>
> So we recently established that it is actually OK for any IRQ
> consumer to request an IRQ from any irq_chip no matter if
> that is a combined GPIO+IRQ driver. This was concluded after
> a long discussion involving several parties.
>
> gpio_to_irq() is just a convenience function and should not be
> relied upon to have been called before the IRQ is used.
>
> The basic premise is that gpio_chip and irq_chip are
> orthogonal, and offering their services independent of each
> other.
>
> Especially in the device tree use case it is very hard to
> dictate that a certain semantic need to be followed to use
> a certain interrupt-controller to have dependencies to a
> certain gpio-controller. So they need to be orthogonal.
>
> First step is: always prepare the hardware and make it
> ready for action in respective callbacks from the gpio_chip API
> and irq_chip API. Do not rely on gpio_to_irq() having been
> called first anymore.
>
> This leads to ambiguities that we need to solve: if there is
> competition inside the subsystem which side is using
> the resource (a certain GPIO line and register for example)
> it needs to deny certain operations and keep track of usage
> inside of the gpiolib subsystem.
>
> We have added a new API to help with this situation:
>
> gpio_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
> gpio_unlock_as_irq(struct gpio_chip *chip,
> unsigned int offset)
>
> These should be called from the irq_chip startup() and
> .shutdown() callbacks to flag that the line is now in use by
> an IRQ. For example the GPIOlib core will deny the line to
> be set as output after this.
>
> If we need more infrastructure to help with this, I'm game.
>
> Clear as mud? ;-)
it's actually crystal clear.
>
> Yours,
> Linus Walleij
^ permalink raw reply
* [PATCH 1/3] ARM: Premit ioremap() to map reserved pages
From: Wang Nan @ 2014-01-22 11:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122114215.GZ15937@n2100.arm.linux.org.uk>
On 2014/1/22 19:42, Russell King - ARM Linux wrote:
> On Wed, Jan 22, 2014 at 07:25:14PM +0800, Wang Nan wrote:
>> This patch relaxes the restriction set by commit 309caa9cc, which
>> prohibit ioremap() on all kernel managed pages.
>>
>> Other architectures, such as x86 and (some specific platforms of) powerpc,
>> allow such mapping.
>>
>> ioremap() pages is an efficient way to avoid arm's mysterious cache control.
>> This feature will be used for arm kexec support to ensure copied data goes into
>> RAM even without cache flushing, because we found that flush_cache_xxx can't
>> reliably flush code to memory.
>
> Yes, let's bypass the check and allow this in violation of the
> architecture specification by allowing mapping the same memory with
> different types, which leads to unpredictable behaviour. Yes, that's
> a very good idea, because what we want to do is far more important than
> following the requirements of the architecture.
>
> So... NAK.
>
> Yes, flush_cache_xxx() doesn't flush back to physical RAM, that's not
> what it's defined to do - it's defined that it flushes enough of the
> cache to ensure that page table updates are safe (such as when tearing
> down a page mapping.) So it's hardly surprising that doesn't work.
>
> If you want to be able to have DMA access to memory, then you need to
> use an API which has been designed for that purpose, and if there isn't
> one, then you need to discuss your requirements, rather than trying to
> hack around the problem.
So what is correct API which is designed for this propose?
>
> The issue here will be that the APIs we currently have for DMA become
> extremely expensive when you want to deal with (eg) all system RAM.
> Or, there's flush_cache_all() which should flush all levels of cache
> in the system, and thus push all data back to RAM.
>
> Now, why are you copying your patches to the stable people? That makes
> no sense - they haven't been reviewed and they haven't been integrated
> into an existing kernel. So, they don't meet the basic requirements
> for stable tree submission...
>
^ permalink raw reply
* [PATCH 04/20] ARM64 / ACPI: Introduce arm_core.c and its related head file
From: Lorenzo Pieralisi @ 2014-01-22 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389961514-13562-5-git-send-email-hanjun.guo@linaro.org>
On Fri, Jan 17, 2014 at 12:24:58PM +0000, Hanjun Guo wrote:
[...]
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index bd9bbd0..2210353 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -41,6 +41,7 @@
> #include <linux/memblock.h>
> #include <linux/of_fdt.h>
> #include <linux/of_platform.h>
> +#include <linux/acpi.h>
>
> #include <asm/cputype.h>
> #include <asm/elf.h>
> @@ -225,6 +226,11 @@ void __init setup_arch(char **cmdline_p)
>
> arm64_memblock_init();
>
> + /* Parse the ACPI tables for possible boot-time configuration */
> + acpi_boot_table_init();
> + early_acpi_boot_init();
> + acpi_boot_init();
> +
> paging_init();
Can I ask you please why we need to parse ACPI tables before
paging_init() ?
[...]
> +/*
> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
> + * or early_memremap() should be called here.
Again, why is this needed ? What's needed before paging_init() from ACPI ?
[...]
> +/*
> + * acpi_boot_table_init() and acpi_boot_init()
> + * called from setup_arch(), always.
> + * 1. checksums all tables
> + * 2. enumerates lapics
> + * 3. enumerates io-apics
> + *
> + * acpi_table_init() is separated to allow reading SRAT without
> + * other side effects.
> + */
> +void __init acpi_boot_table_init(void)
> +{
> + /*
> + * If acpi_disabled, bail out
> + */
> + if (acpi_disabled)
> + return;
> +
> + /*
> + * Initialize the ACPI boot-time table parser.
> + */
> + if (acpi_table_init()) {
> + disable_acpi();
> + return;
> + }
> +}
> +
> +int __init early_acpi_boot_init(void)
> +{
> + /*
> + * If acpi_disabled, bail out
> + */
> + if (acpi_disabled)
> + return -ENODEV;
> +
> + /*
> + * Process the Multiple APIC Description Table (MADT), if present
> + */
> + early_acpi_process_madt();
> +
> + return 0;
> +}
> +
> +int __init acpi_boot_init(void)
> +{
> + /*
> + * If acpi_disabled, bail out
> + */
> + if (acpi_disabled)
> + return -ENODEV;
> +
> + acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> +
> + /*
> + * Process the Multiple APIC Description Table (MADT), if present
> + */
> + acpi_process_madt();
> +
> + return 0;
> +}
Well, apart from having three init calls, one returning void and two
returning proper values, do not understand why, and do not understand
why we need three calls in the first place...why should we process MADT
twice in two separate calls ? What is supposed to change in between that
prevents you from merging the two together ?
Thanks,
Lorenzo
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Mark Brown @ 2014-01-22 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121152358.GD28801@e102568-lin.cambridge.arm.com>
On Tue, Jan 21, 2014 at 03:23:59PM +0000, Lorenzo Pieralisi wrote:
> On Tue, Jan 21, 2014 at 02:35:11PM +0000, Amit Kucheria wrote:
> > DT-newbie here. What would happen if a vendor does not characterise
> > the latency at each OPP? IOW, the table only contains latency values
> > for a subset of the OPPs.
> The bindings are explicit, so the kernel will barf. Adding a LUT to map
> latencies to OPPs make me cringe, so I would not change the current
> bindings.
Actually looking at the OPP binding I do wonder if it might not be
better to have a v2/rich binding for them which is extensible - the fact
that it's not possible to add additional information seems like an
issue, this can't be the only thing anyone might want to add and lining
up multiple tables is never fun.
-------------- 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/20140122/8b7df996/attachment.sig>
^ permalink raw reply
* [PATCH 01/11] iommu/arm-smmu: Introduce driver option handling
From: Will Deacon @ 2014-01-22 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389876263-25759-2-git-send-email-andreas.herrmann@calxeda.com>
Hi Andreas,
Couple of *tiny* comments.
On Thu, Jan 16, 2014 at 12:44:13PM +0000, Andreas Herrmann wrote:
> Introduce handling of driver options. Options are set based on DT
> information when probing an SMMU device. The first option introduced
> is "arm,smmu-isolate-devices". (It will be used in the bus notifier
> block.)
>
> Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
> Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
> ---
> drivers/iommu/arm-smmu.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index e46a887..0b97d03 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -47,6 +47,9 @@
>
> #include <asm/pgalloc.h>
>
> +/* Driver options */
> +#define ARM_SMMU_OPT_ISOLATE_DEVICES (1 << 0)
You can move this...
> /* Maximum number of stream IDs assigned to a single device */
> #define MAX_MASTER_STREAMIDS 8
>
> @@ -348,6 +351,7 @@ struct arm_smmu_device {
> #define ARM_SMMU_FEAT_TRANS_S2 (1 << 3)
> #define ARM_SMMU_FEAT_TRANS_NESTED (1 << 4)
> u32 features;
... to here. Like the *_FEAT_* defines above.
> + u32 options;
> int version;
>
> u32 num_context_banks;
> @@ -398,6 +402,29 @@ struct arm_smmu_domain {
> static DEFINE_SPINLOCK(arm_smmu_devices_lock);
> static LIST_HEAD(arm_smmu_devices);
>
> +struct arm_smmu_option_prop {
> + u32 opt;
> + const char *prop;
> +};
> +
> +static struct arm_smmu_option_prop arm_smmu_options [] = {
> + { ARM_SMMU_OPT_ISOLATE_DEVICES, "arm,smmu-isolate-devices" },
> + { 0, NULL},
> +};
> +
> +static void check_driver_options(struct arm_smmu_device *smmu)
> +{
> + int i = 0;
> + do {
> + if (of_property_read_bool(smmu->dev->of_node,
> + arm_smmu_options[i].prop)) {
> + smmu->options |= arm_smmu_options[i].opt;
> + dev_dbg(smmu->dev, "option %s\n",
> + arm_smmu_options[i].prop);
> + }
> + } while (arm_smmu_options[++i].opt);
> +}
> +
> static struct arm_smmu_master *find_smmu_master(struct arm_smmu_device *smmu,
> struct device_node *dev_node)
> {
> @@ -1783,6 +1810,8 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> }
> smmu->dev = dev;
>
> + check_driver_options(smmu);
I think parse_driver_opts is a better name. Also, if we called this after
arm_smmu_device_cfg_probe, we could replace the dev_dbg with a dev_notice,
since the user probably wants to know which options ended up getting
enabled. Is there a reason you need to probe the option so early?
Will
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Mark Rutland @ 2014-01-22 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DCE790.6080809@linaro.org>
On Mon, Jan 20, 2014 at 09:08:32AM +0000, Hanjun Guo wrote:
> On 2014-1-17 22:21, Arnd Bergmann wrote:
> > On Friday 17 January 2014, Hanjun Guo wrote:
> >>
> >> From: Amit Daniel Kachhap <amit.daniel@samsung.com>
> >>
> >> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
> >> name from the ACPI timer table is matched with all the registered
> >> timer controllers and matching initialisation routine is invoked.
> >
> > I wouldn't anticipate this infrastructure to be required. Shouldn't all
> > ARMv8 machines have an architected timer?
>
> I not sure of this, could anyone can give some guidance? if only arch
> timer is available for ARM64, this will make thing very simple.
All ARMv8 systems should have an architected timer.
However, they may also have other timers (e.g. global timers for use
when CPUs are in low power states and their local architected timers
aren't active).
Thanks,
Mark.
^ permalink raw reply
* [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE
From: Mark Rutland @ 2014-01-22 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYKwaH5DX27irzmcTDAMhQMUhuzz6N7mjKWv9tZchv0Ug@mail.gmail.com>
On Wed, Jan 22, 2014 at 08:26:50AM +0000, Linus Walleij wrote:
> On Fri, Jan 17, 2014 at 1:25 PM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>
> > From: Amit Daniel Kachhap <amit.daniel@samsung.com>
> >
> > This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
> > name from the ACPI timer table is matched with all the registered
> > timer controllers and matching initialisation routine is invoked.
> >
> > Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
> > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>
> Actually I have a fat patch renaming CLOCKSOURCE_OF_DECLARE()
> to TIMER_OF_DECLARE() and I think this macro, if needed, should
> be named TIMER_ACPI_DECLARE().
>
> The reason is that "clocksource" is a Linux-internal name and this
> macro pertains to the hardware name in respective system
> description type.
>
> > +#ifdef CONFIG_ACPI
> > +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn) \
> > + static const struct acpi_device_id __clksrc_acpi_table_##name \
> > + __used __section(__clksrc_acpi_table) \
> > + = { .id = compat, \
> > + .driver_data = (kernel_ulong_t)fn }
> > +#else
> > +#define CLOCKSOURCE_ACPI_DECLARE(name, compat, fn)
> > +#endif
>
> This hammers down the world to compile one binary for ACPI
> and one binary for device tree. Maybe that's fine, I don't know.
How does it do that?
As far as I could tell CONFIG_ACPI and CONFIG_OF are not mutually
exclusive, and this just means that we only build the datastructures for
matching from ACPI when CONFIG_ACPI is enabled.
Have I missed something?
I definitely don't want to see mutually exclusive ACPI and DT support.
Cheers,
Mark.
^ permalink raw reply
* [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Mark Brown @ 2014-01-22 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121133148.GB28801@e102568-lin.cambridge.arm.com>
On Tue, Jan 21, 2014 at 01:31:48PM +0000, Lorenzo Pieralisi wrote:
> On Tue, Jan 21, 2014 at 11:16:46AM +0000, Vincent Guittot wrote:
> > > + - psci-power-state
> > > + Usage: Required if entry-method property value is set to
> > > + "psci".
> > > + Value type: <u32>
> > > + Definition: power_state parameter to pass to the PSCI
> > > + suspend call to enter the C-state.
> > Why psci has got a dedicated field and not vendor methods ? can't you
> > make that more generic ?
> If anyone provides me with an example usage why not, for now I know I
> need that parameter for PSCI, I can call it differently, define it for PSCI
> and leave it as optional for other methods.
Would it not be sensible to define a PSCI binding that extends this and
other bindings - ISTR some other properties getting scattered into
bindings for it?
-------------- 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/20140122/08080b74/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] ARM: Premit ioremap() to map reserved pages
From: Russell King - ARM Linux @ 2014-01-22 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390389916-8711-2-git-send-email-wangnan0@huawei.com>
On Wed, Jan 22, 2014 at 07:25:14PM +0800, Wang Nan wrote:
> This patch relaxes the restriction set by commit 309caa9cc, which
> prohibit ioremap() on all kernel managed pages.
>
> Other architectures, such as x86 and (some specific platforms of) powerpc,
> allow such mapping.
>
> ioremap() pages is an efficient way to avoid arm's mysterious cache control.
> This feature will be used for arm kexec support to ensure copied data goes into
> RAM even without cache flushing, because we found that flush_cache_xxx can't
> reliably flush code to memory.
Yes, let's bypass the check and allow this in violation of the
architecture specification by allowing mapping the same memory with
different types, which leads to unpredictable behaviour. Yes, that's
a very good idea, because what we want to do is far more important than
following the requirements of the architecture.
So... NAK.
Yes, flush_cache_xxx() doesn't flush back to physical RAM, that's not
what it's defined to do - it's defined that it flushes enough of the
cache to ensure that page table updates are safe (such as when tearing
down a page mapping.) So it's hardly surprising that doesn't work.
If you want to be able to have DMA access to memory, then you need to
use an API which has been designed for that purpose, and if there isn't
one, then you need to discuss your requirements, rather than trying to
hack around the problem.
The issue here will be that the APIs we currently have for DMA become
extremely expensive when you want to deal with (eg) all system RAM.
Or, there's flush_cache_all() which should flush all levels of cache
in the system, and thus push all data back to RAM.
Now, why are you copying your patches to the stable people? That makes
no sense - they haven't been reviewed and they haven't been integrated
into an existing kernel. So, they don't meet the basic requirements
for stable tree submission...
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 1/3] ARM: Premit ioremap() to map reserved pages
From: Will Deacon @ 2014-01-22 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390389916-8711-2-git-send-email-wangnan0@huawei.com>
On Wed, Jan 22, 2014 at 11:25:14AM +0000, Wang Nan wrote:
> This patch relaxes the restriction set by commit 309caa9cc, which
> prohibit ioremap() on all kernel managed pages.
>
> Other architectures, such as x86 and (some specific platforms of) powerpc,
> allow such mapping.
>
> ioremap() pages is an efficient way to avoid arm's mysterious cache control.
> This feature will be used for arm kexec support to ensure copied data goes into
> RAM even without cache flushing, because we found that flush_cache_xxx can't
> reliably flush code to memory.
>
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> Cc: <stable@vger.kernel.org> # 3.4+
> Cc: Eric Biederman <ebiederm@xmission.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Geng Hui <hui.geng@huawei.com>
> ---
> arch/arm/mm/ioremap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> index f123d6e..98b1c10 100644
> --- a/arch/arm/mm/ioremap.c
> +++ b/arch/arm/mm/ioremap.c
> @@ -298,7 +298,7 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
> /*
> * Don't allow RAM to be mapped - this causes problems with ARMv6+
> */
> - if (WARN_ON(pfn_valid(pfn)))
> + if (WARN_ON(pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn))))
Since reserved pages can still be mapped, how does this avoid the cacheable
alias issue fixed by 309caa9cc6ff ("ARM: Prohibit ioremap() on kernel
managed RAM")?
Will
^ permalink raw reply
* [PATCH] ARM: imx: enable delaytimer on the imx timer
From: Sebastian Andrzej Siewior @ 2014-01-22 11:35 UTC (permalink / raw)
To: linux-arm-kernel
The imx can support timer-based delays, so implement this.
Skips past jiffy calibration.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
Tested on imx51.
arch/arm/mach-imx/time.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-imx/time.c b/arch/arm/mach-imx/time.c
index cd46529..19c5cf9 100644
--- a/arch/arm/mach-imx/time.c
+++ b/arch/arm/mach-imx/time.c
@@ -25,6 +25,7 @@
#include <linux/irq.h>
#include <linux/clockchips.h>
#include <linux/clk.h>
+#include <linux/delay.h>
#include <linux/err.h>
#include <linux/sched_clock.h>
@@ -116,11 +117,22 @@ static u32 notrace mxc_read_sched_clock(void)
return sched_clock_reg ? __raw_readl(sched_clock_reg) : 0;
}
+static struct delay_timer imx_delay_timer;
+
+static unsigned long imx_read_current_timer(void)
+{
+ return __raw_readl(sched_clock_reg);
+}
+
static int __init mxc_clocksource_init(struct clk *timer_clk)
{
unsigned int c = clk_get_rate(timer_clk);
void __iomem *reg = timer_base + (timer_is_v2() ? V2_TCN : MX1_2_TCN);
+ imx_delay_timer.read_current_timer = &imx_read_current_timer;
+ imx_delay_timer.freq = c;
+ register_current_timer_delay(&imx_delay_timer);
+
sched_clock_reg = reg;
setup_sched_clock(mxc_read_sched_clock, 32, c);
--
1.8.5.2
^ permalink raw reply related
* [PATCH 1/3] mmc: add support for power-on sequencing through DT
From: Mark Brown @ 2014-01-22 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMi9puZSzdDJ-sur5ks7VcDH+XV_MbuA0xeidLgp=uJacg@mail.gmail.com>
On Tue, Jan 21, 2014 at 10:14:49AM -0800, Olof Johansson wrote:
> On Tue, Jan 21, 2014 at 12:55 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > That could make sense, but still I wonder how those shall be handled
> > in a fine grained power management setup. In other words, when shall
> > those be gated/ungated? Is the mmc core able to take the correct
> > decision about these?
> The reference clock is in most cases I've seen 32kHz, and not
> something that's under fine-grained power management. So it's not used
> to regulate interface speed, etc.
I have seen devices connected using SDIO which did use fine grained
power management here with faster clocks. They're definitely not the
common case but they're there. :/
-------------- 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/20140122/de54e4eb/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Will Deacon @ 2014-01-22 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390325166-16840-1-git-send-email-lauraa@codeaurora.org>
Hi Laura,
On Tue, Jan 21, 2014 at 05:26:06PM +0000, Laura Abbott wrote:
> arm64 currently lacks support for -fstack-protector. Add
> similar functionality to arm to detect stack corruption.
>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> ---
> arch/arm64/Kconfig | 12 +++++++++
> arch/arm64/Makefile | 4 +++
> arch/arm64/include/asm/stackprotector.h | 38 +++++++++++++++++++++++++++++++
> arch/arm64/kernel/process.c | 9 +++++++
> 4 files changed, 63 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm64/include/asm/stackprotector.h
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 6d4dd22..4f86874 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -168,6 +168,18 @@ config HOTPLUG_CPU
> Say Y here to experiment with turning CPUs off and on. CPUs
> can be controlled through /sys/devices/system/cpu.
>
> +config CC_STACKPROTECTOR
> + bool "Enable -fstack-protector buffer overflow detection"
> + help
> + This option turns on the -fstack-protector GCC feature. This
> + feature puts, at the beginning of functions, a canary value on
> + the stack just before the return address, and validates
> + the value just before actually returning. Stack based buffer
> + overflows (that need to overwrite this return address) now also
> + overwrite the canary, which gets detected and the attack is then
> + neutralized via a kernel panic.
> + This feature requires gcc version 4.2 or above.
You can remove that bit about GCC -- GCC 4.2 doesn't support AArch64.
> +
> source kernel/Kconfig.preempt
>
> config HZ
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 2fceb71..1ce221e 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -48,6 +48,10 @@ core-$(CONFIG_XEN) += arch/arm64/xen/
> libs-y := arch/arm64/lib/ $(libs-y)
> libs-y += $(LIBGCC)
>
> +ifeq ($(CONFIG_CC_STACKPROTECTOR),y)
> +KBUILD_CFLAGS +=-fstack-protector
> +endif
> +
> # Default target when executing plain make
> KBUILD_IMAGE := Image.gz
> KBUILD_DTBS := dtbs
> diff --git a/arch/arm64/include/asm/stackprotector.h b/arch/arm64/include/asm/stackprotector.h
> new file mode 100644
> index 0000000..de00332
> --- /dev/null
> +++ b/arch/arm64/include/asm/stackprotector.h
> @@ -0,0 +1,38 @@
> +/*
> + * GCC stack protector support.
> + *
> + * Stack protector works by putting predefined pattern at the start of
> + * the stack frame and verifying that it hasn't been overwritten when
> + * returning from the function. The pattern is called stack canary
> + * and gcc expects it to be defined by a global variable called
> + * "__stack_chk_guard" on ARM. This unfortunately means that on SMP
> + * we cannot have a different canary value per task.
> + */
> +
> +#ifndef _ASM_STACKPROTECTOR_H
__ASM_ for consistency.
> +#define _ASM_STACKPROTECTOR_H 1
Why #define explicitly to 1?
> +
> +#include <linux/random.h>
> +#include <linux/version.h>
> +
> +extern unsigned long __stack_chk_guard;
> +
> +/*
> + * Initialize the stackprotector canary value.
> + *
> + * NOTE: this must only be called from functions that never return,
> + * and it must always be inlined.
> + */
> +static __always_inline void boot_init_stack_canary(void)
> +{
> + unsigned long canary;
> +
> + /* Try to get a semi random initial value. */
> + get_random_bytes(&canary, sizeof(canary));
> + canary ^= LINUX_VERSION_CODE;
> +
> + current->stack_canary = canary;
> + __stack_chk_guard = current->stack_canary;
> +}
> +
> +#endif /* _ASM_STACKPROTECTOR_H */
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index de17c89..592d630 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -50,6 +50,12 @@
> #include <asm/processor.h>
> #include <asm/stacktrace.h>
>
> +#ifdef CONFIG_CC_STACKPROTECTOR
> +#include <linux/stackprotector.h>
> +unsigned long __stack_chk_guard __read_mostly;
> +EXPORT_SYMBOL(__stack_chk_guard);
> +#endif
> +
> static void setup_restart(void)
> {
> /*
> @@ -288,6 +294,9 @@ struct task_struct *__switch_to(struct task_struct *prev,
> {
> struct task_struct *last;
>
> +#if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
> + __stack_chk_guard = next->stack_canary;
> +#endif
I don't get the dependency on !SMP. Assumedly, the update of
__stack_chk_guard would be racy otherwise, but that sounds solvable with
atomics. Is the stack_canary updated periodically somewhere else?
Will
^ permalink raw reply
* [PATCH 1/4] ARM: dts: cm-fx6: rearrange the dts file
From: Igor Grinberg @ 2014-01-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121204201.GX16215@pengutronix.de>
Hi Sascha,
On 01/21/14 22:42, Sascha Hauer wrote:
> Hi Igor,
>
> On Tue, Jan 21, 2014 at 06:13:29PM +0200, Igor Grinberg wrote:
>> Move the iomuxc definition before the devices definitions
>> (e.g. gpmi, fec).
>
> The nodes are sorted alphabetically. Please keep them sorted.
Hmmm.. I missed that point... Thanks!
Will fix this up and resend.
--
Regards,
Igor.
^ permalink raw reply
* [PATCH 3/3] ARM: allow kernel to be loaded in middle of phymem
From: Wang Nan @ 2014-01-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390389916-8711-1-git-send-email-wangnan0@huawei.com>
This patch allows the kernel to be loaded at the middle of kernel awared
physical memory. Before this patch, users must use mem= or device tree to cheat
kernel about the start address of physical memory.
This feature is useful in some special cases, for example, building a crash
dump kernel. Without it, kernel command line, atag and devicetree must be
adjusted carefully, sometimes is impossible.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: <stable@vger.kernel.org> # 3.4+
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geng Hui <hui.geng@huawei.com>
---
arch/arm/mm/init.c | 21 ++++++++++++++++++++-
arch/arm/mm/mmu.c | 13 +++++++++++++
mm/page_alloc.c | 7 +++++--
3 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 3e8f106..4952726 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -334,9 +334,28 @@ void __init arm_memblock_init(struct meminfo *mi,
{
int i;
- for (i = 0; i < mi->nr_banks; i++)
+ for (i = 0; i < mi->nr_banks; i++) {
memblock_add(mi->bank[i].start, mi->bank[i].size);
+ /*
+ * In some special case, for example, building a crushdump
+ * kernel, we want the kernel to be loaded in the middle of
+ * physical memory. In such case, the physical memory before
+ * PHYS_OFFSET is awkward: it can't get directly mapped
+ * (because its address will be smaller than PAGE_OFFSET,
+ * disturbs user address space) also can't be mapped as
+ * HighMem. We reserve such pages here. The only way to access
+ * those pages is ioremap.
+ */
+ if (mi->bank[i].start < PHYS_OFFSET) {
+ unsigned long reserv_size = PHYS_OFFSET -
+ mi->bank[i].start;
+ if (reserv_size > mi->bank[i].size)
+ reserv_size = mi->bank[i].size;
+ memblock_reserve(mi->bank[i].start, reserv_size);
+ }
+ }
+
/* Register the kernel text, kernel data and initrd with memblock. */
#ifdef CONFIG_XIP_KERNEL
memblock_reserve(__pa(_sdata), _end - _sdata);
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 580ef2d..2a17c24 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1308,6 +1308,19 @@ static void __init map_lowmem(void)
if (start >= end)
break;
+ /*
+ * If this memblock contain memory before PAGE_OFFSET, memory
+ * before PAGE_OFFSET should't get directly mapped, see code
+ * in create_mapping(). However, memory after PAGE_OFFSET is
+ * occupyed by kernel and still need to be mapped.
+ */
+ if (__phys_to_virt(start) < PAGE_OFFSET) {
+ if (__phys_to_virt(end) > PAGE_OFFSET)
+ start = __virt_to_phys(PAGE_OFFSET);
+ else
+ break;
+ }
+
map.pfn = __phys_to_pfn(start);
map.virtual = __phys_to_virt(start);
map.length = end - start;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5248fe0..d2959e3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4840,10 +4840,13 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat)
*/
if (pgdat == NODE_DATA(0)) {
mem_map = NODE_DATA(0)->node_mem_map;
-#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
+ /*
+ * In case of CONFIG_HAVE_MEMBLOCK_NODE_MAP or when kernel
+ * loaded at the middle of physical memory, mem_map should
+ * be adjusted.
+ */
if (page_to_pfn(mem_map) != pgdat->node_start_pfn)
mem_map -= (pgdat->node_start_pfn - ARCH_PFN_OFFSET);
-#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
}
#endif
#endif /* CONFIG_FLAT_NODE_MEM_MAP */
--
1.8.4
^ permalink raw reply related
* [PATCH 2/3] ARM: kexec: copying code to ioremapped area
From: Wang Nan @ 2014-01-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390389916-8711-1-git-send-email-wangnan0@huawei.com>
ARM's kdump is actually corrupted (at least for omap4460), mainly because of
cache problem: flush_icache_range can't reliably ensure the copied data
correctly goes into RAM. After mmu turned off and jump to the trampoline, kexec
always failed due to random undef instructions.
This patch use ioremap to make sure the destnation of all memcpy() is
uncachable memory, including copying of target kernel and trampoline.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: <stable@vger.kernel.org> # 3.4+
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geng Hui <hui.geng@huawei.com>
---
arch/arm/kernel/machine_kexec.c | 18 ++++++++++++++++--
kernel/kexec.c | 40 +++++++++++++++++++++++++++++++++++-----
2 files changed, 51 insertions(+), 7 deletions(-)
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index f0d180d..ba0a5a8 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -144,6 +144,7 @@ void machine_kexec(struct kimage *image)
unsigned long page_list;
unsigned long reboot_code_buffer_phys;
unsigned long reboot_entry = (unsigned long)relocate_new_kernel;
+ void __iomem *reboot_entry_remap;
unsigned long reboot_entry_phys;
void *reboot_code_buffer;
@@ -171,9 +172,22 @@ void machine_kexec(struct kimage *image)
/* copy our kernel relocation code to the control code page */
- reboot_entry = fncpy(reboot_code_buffer,
- reboot_entry,
+ reboot_entry_remap = ioremap_nocache(reboot_code_buffer_phys,
+ relocate_new_kernel_size);
+ if (reboot_entry_remap == NULL) {
+ pr_warn("startup code may not be reliably flushed\n");
+ reboot_entry_remap = (void __iomem *)reboot_code_buffer;
+ }
+
+ reboot_entry = fncpy(reboot_entry_remap, reboot_entry,
relocate_new_kernel_size);
+ reboot_entry = (unsigned long)reboot_code_buffer +
+ (reboot_entry -
+ (unsigned long)reboot_entry_remap);
+
+ if (reboot_entry_remap != reboot_code_buffer)
+ iounmap(reboot_entry_remap);
+
reboot_entry_phys = (unsigned long)reboot_entry +
(reboot_code_buffer_phys - (unsigned long)reboot_code_buffer);
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 9c97016..3e92999 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -806,6 +806,7 @@ static int kimage_load_normal_segment(struct kimage *image,
while (mbytes) {
struct page *page;
char *ptr;
+ void __iomem *ioptr;
size_t uchunk, mchunk;
page = kimage_alloc_page(image, GFP_HIGHUSER, maddr);
@@ -818,7 +819,17 @@ static int kimage_load_normal_segment(struct kimage *image,
if (result < 0)
goto out;
- ptr = kmap(page);
+ /*
+ * Try ioremap to make sure the copied data goes into RAM
+ * reliably. If failed (some archs don't allow ioremap RAM),
+ * use kmap instead.
+ */
+ ioptr = ioremap(page_to_pfn(page) << PAGE_SHIFT,
+ PAGE_SIZE);
+ if (ioptr != NULL)
+ ptr = ioptr;
+ else
+ ptr = kmap(page);
/* Start with a clear page */
clear_page(ptr);
ptr += maddr & ~PAGE_MASK;
@@ -827,7 +838,10 @@ static int kimage_load_normal_segment(struct kimage *image,
uchunk = min(ubytes, mchunk);
result = copy_from_user(ptr, buf, uchunk);
- kunmap(page);
+ if (ioptr != NULL)
+ iounmap(ioptr);
+ else
+ kunmap(page);
if (result) {
result = -EFAULT;
goto out;
@@ -846,7 +860,7 @@ static int kimage_load_crash_segment(struct kimage *image,
{
/* For crash dumps kernels we simply copy the data from
* user space to it's destination.
- * We do things a page at a time for the sake of kmap.
+ * We do things a page@a time for the sake of ioremap/kmap.
*/
unsigned long maddr;
size_t ubytes, mbytes;
@@ -861,6 +875,7 @@ static int kimage_load_crash_segment(struct kimage *image,
while (mbytes) {
struct page *page;
char *ptr;
+ void __iomem *ioptr;
size_t uchunk, mchunk;
page = pfn_to_page(maddr >> PAGE_SHIFT);
@@ -868,7 +883,18 @@ static int kimage_load_crash_segment(struct kimage *image,
result = -ENOMEM;
goto out;
}
- ptr = kmap(page);
+ /*
+ * Try ioremap to make sure the copied data goes into RAM
+ * reliably. If failed (some archs don't allow ioremap RAM),
+ * use kmap instead.
+ */
+ ioptr = ioremap_nocache(page_to_pfn(page) << PAGE_SHIFT,
+ PAGE_SIZE);
+ if (ioptr != NULL)
+ ptr = ioptr;
+ else
+ ptr = kmap(page);
+
ptr += maddr & ~PAGE_MASK;
mchunk = min_t(size_t, mbytes,
PAGE_SIZE - (maddr & ~PAGE_MASK));
@@ -879,7 +905,11 @@ static int kimage_load_crash_segment(struct kimage *image,
}
result = copy_from_user(ptr, buf, uchunk);
kexec_flush_icache_page(page);
- kunmap(page);
+ if (ioptr != NULL)
+ iounmap(ioptr);
+ else
+ kunmap(page);
+
if (result) {
result = -EFAULT;
goto out;
--
1.8.4
^ permalink raw reply related
* [PATCH 1/3] ARM: Premit ioremap() to map reserved pages
From: Wang Nan @ 2014-01-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390389916-8711-1-git-send-email-wangnan0@huawei.com>
This patch relaxes the restriction set by commit 309caa9cc, which
prohibit ioremap() on all kernel managed pages.
Other architectures, such as x86 and (some specific platforms of) powerpc,
allow such mapping.
ioremap() pages is an efficient way to avoid arm's mysterious cache control.
This feature will be used for arm kexec support to ensure copied data goes into
RAM even without cache flushing, because we found that flush_cache_xxx can't
reliably flush code to memory.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: <stable@vger.kernel.org> # 3.4+
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geng Hui <hui.geng@huawei.com>
---
arch/arm/mm/ioremap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index f123d6e..98b1c10 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -298,7 +298,7 @@ void __iomem * __arm_ioremap_pfn_caller(unsigned long pfn,
/*
* Don't allow RAM to be mapped - this causes problems with ARMv6+
*/
- if (WARN_ON(pfn_valid(pfn)))
+ if (WARN_ON(pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn))))
return NULL;
area = get_vm_area_caller(size, VM_IOREMAP, caller);
--
1.8.4
^ permalink raw reply related
* [PATCH 0/3] Bugfix for kdump on arm
From: Wang Nan @ 2014-01-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
This patch series introduce 3 bugfix for kdump (and kexec) on arm platform.
kdump for arm in fact is corrupted (at least for omap4460). With one-month hard
work and with the help of a jtag debugger, we finally make kdump works
reliablly.
Following is the patches. The first 2 patches forms a group, it allow
ioremap_nocache to be taken on reserved pages on arm platform (which is
prohibited by 309caa9cc) and then use ioremap_nocache to copy kexec required
code. The last 1 is for crash dump kernel. It allow kernel to be loaded in the
middle of kernel awared physical memory. Without it, crashdump kernel must be
carefully configured to boot.
Wang Nan (3):
ARM: Premit ioremap() to map reserved pages
ARM: kexec: copying code to ioremapped area
ARM: allow kernel to be loaded in middle of phymem
arch/arm/kernel/machine_kexec.c | 18 ++++++++++++++++--
arch/arm/mm/init.c | 21 ++++++++++++++++++++-
arch/arm/mm/ioremap.c | 2 +-
arch/arm/mm/mmu.c | 13 +++++++++++++
kernel/kexec.c | 40 +++++++++++++++++++++++++++++++++++-----
mm/page_alloc.c | 7 +++++--
6 files changed, 90 insertions(+), 11 deletions(-)
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geng Hui <hui.geng@huawei.com>
--
1.8.4
^ permalink raw reply
* [PATCH v4 2/5] arm: add new asm macro update_sctlr
From: Will Deacon @ 2014-01-22 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389445524-30623-3-git-send-email-leif.lindholm@linaro.org>
On Sat, Jan 11, 2014 at 01:05:21PM +0000, Leif Lindholm wrote:
> A new macro for setting/clearing bits in the SCTLR.
>
> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
> Suggested-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/include/asm/assembler.h | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 5c22851..aba6458 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -383,4 +383,17 @@ THUMB( orr \reg , \reg , #PSR_T_BIT )
> #endif
> .endm
>
> +#ifdef CONFIG_CPU_CP15
> +/* Macro for setting/clearing bits in sctlr */
> + .macro update_sctlr, set:req, clear:req, tmp:req, tmp2:req
> + mrc p15, 0, \tmp, c1, c0, 0
> + ldr \tmp2, =\set
> + orr \tmp, \tmp, \tmp2
> + ldr \tmp2, =\clear
> + mvn \tmp2, \tmp2
> + and \tmp, \tmp, \tmp2
> + mcr p15, 0, \tmp, c1, c0, 0
I think this would be cleaner if you force the caller to put set and clear
into registers beforehand, rather than have to do the literal load every
time. Also, I don't think set and clear should be required (and then you can
lose tmp2 as well).
Will
^ permalink raw reply
* [PATCH v4 1/5] arm: break part of __soft_restart out into separate function
From: Will Deacon @ 2014-01-22 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389445524-30623-2-git-send-email-leif.lindholm@linaro.org>
On Sat, Jan 11, 2014 at 01:05:20PM +0000, Leif Lindholm wrote:
> Certain operations can be considered mandatory for any piece of code
> preparing to switch off the MMU. Break this out into separate function
> dmap_prepare().
idmap_prepare. dmap_prepare sounds like something *completely* different!
With that:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
From: Jack Mitchell @ 2014-01-22 11:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Jack Mitchell <jack@embed.me.uk>
Devicetree include file for setting up the am335x mcasp bus, i2c-2
bus, and audio codec required for a functioning BeagleBone Audio Cape.
Signed-off-by: Jack Mitchell <jack@embed.me.uk>
Signed-off-by: Matt Porter <mporter@linaro.org>
---
arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi | 124 +++++++++++++++++++++
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++
2 files changed, 138 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
diff --git a/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
new file mode 100644
index 0000000..b8ec3dc
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
@@ -0,0 +1,124 @@
+/*
+ * Copyright (C) 2014 Jack Mitchell <jack@embed.me.uk>
+ *
+ * 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.
+ *
+ * In order to enable the BeagleBone Audio Cape this dtsi must be
+ * incuded in the top level dts. On BeagleBone Black hardware the
+ * status of the HDMI dts node must also be set to "disabled".
+ *
+ * --- a/arch/arm/boot/dts/am335x-bone.dts
+ * +++ b/arch/arm/boot/dts/am335x-bone.dts
+ * @@ -9,6 +9,7 @@
+ *
+ * #include "am33xx.dtsi"
+ * #include "am335x-bone-common.dtsi"
+ * +#include "am335x-bone-audio-cape-reva.dtsi"
+ *
+ * &ldo3_reg {
+ * regulator-min-microvolt = <1800000>;
+ *
+ * On BeagleBone Black hardware the status of the HDMI dts node must
+ * also be set to "disabled"
+ *
+ * --- a/arch/arm/boot/dts/am335x-boneblack.dts
+ * +++ b/arch/arm/boot/dts/am335x-boneblack.dts
+ * @@ -73,6 +74,6 @@
+ * pinctrl-names = "default", "off";
+ * pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+ * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+ * - status = "okay";
+ * + status = "disabled";
+ * };
+ * };
+ */
+
+/ {
+ sound {
+ compatible = "ti,da830-evm-audio";
+ ti,model = "AM335x BeagleBone Audio Cape Rev. A";
+ ti,audio-codec = <&tlv320aic3106>;
+ ti,mcasp-controller = <&mcasp0>;
+ ti,codec-clock-rate = <12000000>;
+ ti,audio-routing =
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "LINE1L", "Line In",
+ "LINE1R", "Line In";
+ };
+
+ audio-cape-gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&bone_audio_cape_led_pins>;
+
+ audio-led0 {
+ label = "audio:green:usr0";
+ gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ audio-led1 {
+ label = "audio:green:usr1";
+ gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+ };
+};
+
+&am33xx_pinmux {
+ bone_audio_cape_led_pins: pinmux_bone_audio_cape_led_pins {
+ pinctrl-single,pins = <
+ 0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a2.gpio1_18 */
+ 0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a3.gpio1_19 */
+ >;
+ };
+
+ bone_audio_cape_pins: bone_audio_cape_pins {
+ pinctrl-single,pins = <
+ 0x190 (PIN_INPUT_PULLUP | MUX_MODE0) /* mcasp0_aclkx.mcasp0_aclkx */
+ 0x194 (PIN_INPUT_PULLUP | MUX_MODE0) /* mcasp0_fsx.mcasp0_fsx */
+ 0x19c (PIN_INPUT_PULLUP | MUX_MODE2) /* mcasp0_ahclkr.mcasp0_axr2 */
+ 0x1ac (PIN_INPUT_PULLUP | MUX_MODE2) /* mcasp0_ahclkx.mcasp0_axr3 */
+ >;
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
+ status = "okay";
+ clock-frequency = <100000>;
+
+ tlv320aic3106: tlv320aic3106 at 1b {
+ compatible = "ti,tlv320aic3106";
+ reg = <0x1b>;
+ status = "okay";
+
+ /* Regulators */
+ AVDD-supply = <&vmmcsd_fixed>;
+ IOVDD-supply = <&vmmcsd_fixed>;
+ DRVDD-supply = <&vmmcsd_fixed>;
+ DVDD-supply = <&vdd1v8_fixed>;
+ };
+};
+
+&mcasp0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&bone_audio_cape_pins>;
+
+ status = "okay";
+
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 2 1
+ >;
+ tx-num-evt = <1>;
+ rx-num-evt = <1>;
+};
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index e3f27ec..c1c0f74 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -62,12 +62,26 @@
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
+
+ vdd1v8_fixed: fixedregulator at 1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd1v8_fixed";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
};
&am33xx_pinmux {
pinctrl-names = "default";
pinctrl-0 = <&clkout2_pin>;
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0x178 (PIN_INPUT_PULLUP | MUX_MODE3) /* uart1_ctsn.i2c2_sda */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE3) /* uart1_rtsn.i2c2_scl */
+ >;
+ };
+
user_leds_s0: user_leds_s0 {
pinctrl-single,pins = <
0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a5.gpio1_21 */
--
1.8.5.2
^ permalink raw reply related
* [PATCH RFC 04/10] base: power: Add generic OF-based power domain look-up
From: Lorenzo Pieralisi @ 2014-01-22 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD5DC5.3000908@samsung.com>
On Mon, Jan 20, 2014 at 05:32:53PM +0000, Tomasz Figa wrote:
> Hi Lorenzo,
>
> On 16.01.2014 17:34, Lorenzo Pieralisi wrote:
> > Hi Tomasz,
> >
> > thank you for posting this series. I would like to use the DT bindings
> > for power domains in the bindings for C-states on ARM:
> >
> > http://comments.gmane.org/gmane.linux.power-management.general/41012
> >
> > and in particular link a given C-state to a given power domain so that the
> > kernel will have a way to actually check what devices are lost upon C-state
> > entry (and for devices I also mean CPU peripheral like PMUs, GIC CPU IF,
> > caches and possibly cpus, all of them already represented with DT nodes).
> >
> > I have a remark:
> >
> > - Can we group device nodes under a single power-domain-parent so that
> > all devices defined under that parent won't have to re-define a
> > power-domain property (a property like interrupt-parent, so to speak)
> >
> > What do you think ?
>
> Hmm, I can see potential benefits of such construct on platforms with
> clear hierarchy of devices, but to make sure I'm getting it correctly,
> is the following what you have in mind?
>
> soc-domain-x at 12340000 {
> compatible = "...";
> reg = <...>;
> power-domain-parent = <&power_domains DOMAIN_X>;
>
> device at 1000 {
> compatible = "...";
> // inherits power-domain = <&power_domains DOMAIN_X>
> };
>
> device at 2000 {
> compatible = "...";
> // inherits power-domain = <&power_domains DOMAIN_X>
> };
> };
Yes, exactly, it could avoid duplicated data. I still have an issue
with nodes that are per-cpu but define just one node (eg PMU), since
a CPU might belong in a power-domain on its own (ie one power domain
per-CPU) and basically this means that arch-timers, PMU & company should
link to multiple power domains, ie one per CPU or we find a way to define
a power domain as "banked".
I need to think about this a bit more, thanks for your feedback.
Lorenzo
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Mika Westerberg @ 2014-01-22 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZbb=eO8YRtMn6hW0vn97PkHUo88e_o61DEC8=wPY3_PQ@mail.gmail.com>
On Wed, Jan 22, 2014 at 10:58:38AM +0100, Linus Walleij wrote:
> On Tue, Jan 21, 2014 at 3:53 PM, Alexandre Courbot <gnurou@gmail.com> wrote:
>
> > The good (or bad, rather) thing about DT is that we can do whatever we
> > please with the new bindings: decide which name or which index
> > (doesn't matter here) a GPIO should have. However we don't have this
> > control over ACPI, where nothing guarantees that the same index will
> > be used for the same GPIO function.
>
> It's not like ACPI will impose some tables on us and expect us to
> use them as-is no matter how crazy they are. Then indeed the whole
> idea of unifying ACPI and DT accessors would be moot and it would
> only work by mistake or as a good joke.
With the current ACPI version we really don't have much of a choice here.
Only way we can distinguish between a set of GPIOs is to use index and hope
that the vendor puts the GPIOs in the table in same order that the driver
expects :-(
This is going to get a bit better when ACPI gets properties (like Arnd
commented already) as then we can get the correct index based on a name in
a table. However, it still requires the vendor to use naming that is
suitable for Linux driver in question.
> The situation with ACPI is just like with DT, it is assumed that the
> author of these tables also look at the Linux kernel drivers to figure
> out what argument goes where and we can influence them.
I certainly hope, now that Android is becoming more and more important,
that the vendors will actually check what the Linux drivers expect and
populate the tables with such information that is suitable for both ACPI
and DT enabled driver.
^ permalink raw reply
* [PATCH v2 5/7] ARM: perf_event: Fully support Krait CPU PMU events
From: Will Deacon @ 2014-01-22 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DEEDDA.4060302@codeaurora.org>
On Tue, Jan 21, 2014 at 09:59:54PM +0000, Stephen Boyd wrote:
> On 01/21/14 10:37, Stephen Boyd wrote:
> > On 01/21/14 10:07, Will Deacon wrote:
> >> Finally, I'd really like to see this get some test coverage, but I don't
> >> want to try running mainline on my phone :) Could you give your patches a
> >> spin with Vince's perf fuzzer please?
> >>
> >> https://github.com/deater/perf_event_tests.git
> >>
> >> (then build the contents of the fuzzer directory and run it for as long as
> >> you can).
> >>
> > Ok. I'll see what I can do.
>
> Neat. This quickly discovered a problem.
Yeah, the fuzzer is good at that!
> BUG: using smp_processor_id() in preemptible [00000000] code: perf_fuzzer/70
> caller is krait_pmu_get_event_idx+0x58/0xd8
> CPU: 2 PID: 70 Comm: perf_fuzzer Not tainted 3.13.0-rc7-next-20140108-00041-gb038353c8516-dirty #58
> [<c02165dc>] (unwind_backtrace) from [<c0212ffc>] (show_stack+0x10/0x14)
> [<c0212ffc>] (show_stack) from [<c06ad5fc>] (dump_stack+0x6c/0xb8)
> [<c06ad5fc>] (dump_stack) from [<c04b0928>] (debug_smp_processor_id+0xc4/0xe8)
> [<c04b0928>] (debug_smp_processor_id) from [<c021a19c>] (krait_pmu_get_event_idx+0x58/0xd8)
> [<c021a19c>] (krait_pmu_get_event_idx) from [<c021833c>] (validate_event+0x2c/0x54)
> [<c021833c>] (validate_event) from [<c02186b4>] (armpmu_event_init+0x264/0x2dc)
> [<c02186b4>] (armpmu_event_init) from [<c02b28e4>] (perf_init_event+0x138/0x194)
> [<c02b28e4>] (perf_init_event) from [<c02b2c04>] (perf_event_alloc+0x2c4/0x348)
> [<c02b2c04>] (perf_event_alloc) from [<c02b37e4>] (SyS_perf_event_open+0x7b8/0x9cc)
> [<c02b37e4>] (SyS_perf_event_open) from [<c020ef80>] (ret_fast_syscall+0x0/0x48)
>
> This is happening because the pmresrn_used mask is per-cpu but
> validate_group() is called in preemptible context. It looks like we'll
> need to add another unsigned long * field to struct pmu_hw_events just
> for Krait purposes? Or we could use the upper 16 bits of the used_mask
> bitmap to hold the pmresr_used values? Sounds sort of hacky but it
> avoids adding another bitmap for every PMU user and there aren't any
> Krait CPUs with more than 5 counters anyway.
I'm fine with that approach, but a comment saying what we're doing with
those upper bits wouldn't go amiss.
> This is the diff for the latter version. I'll let the fuzzer run overnight.
Cheers,
Will
^ permalink raw reply
* [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Jean-Francois Moine @ 2014-01-22 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122111953.238349a5@armhf>
On Wed, 22 Jan 2014 11:19:53 +0100
Jean-Francois Moine <moinejf@free.fr> wrote:
> As both I2S and S/PDIF may be used for HDMI output in the Cubox,
> I wrote a tda998x CODEC which gets the audio ports from the DT and
> dynamically sets these ports and the audio type (i2s / spdif) on audio
> streaming start. I have not submitted yet this codec and the associated
> changes in tda998x, because I am waiting for a first patch series on the
> tda998x to be applied
> (http://lists.freedesktop.org/archives/dri-devel/2014-January/051552.html).
Sorry, the last patch request is
http://lists.freedesktop.org/archives/dri-devel/2014-January/052201.html
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ 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