* [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] 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] 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 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 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 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 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 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 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 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 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
* 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
* Kconfig errors
From: Prabhakar Lad @ 2014-01-22 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+V-a8vcvTRpP-cE6SKd1KgWgzSbOXvSNW+5Jh8wqOfr1za4SQ@mail.gmail.com>
Hi Russell,
On Fri, Jan 17, 2014 at 1:07 PM, Prabhakar Lad
<prabhakar.csengg@gmail.com> wrote:
> Hi,
>
> On Linux-next branch I see following errors for davinci_all_defconfig
> & da8xx_omapl_defconfig configs,
>
> arch/arm/Kconfig:1966:error: recursive dependency detected!
> arch/arm/Kconfig:1966: symbol ZBOOT_ROM depends on AUTO_ZRELADDR
> arch/arm/Kconfig:2154: symbol AUTO_ZRELADDR is selected by ZBOOT_ROM
> #
> # configuration written to .config
> #
>
I am seeing this errors on linux-next, with your recent patch,
"[PATCH] Fix select-induced Kconfig warning for ZBOOT_ROM"
and strangely I see that AUTO_ZRELADDR doesnt select ZBOOT_ROM
but still an error.
Note: For the davinci configs CONFIG_AUTO_ZRELADDR is not set and
CONFIG_ZBOOT_ROM_TEXT=0x0, CONFIG_ZBOOT_ROM_BSS=0x0
Regards,
--Prabhakar Lad
^ permalink raw reply
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Will Deacon @ 2014-01-22 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e92c5fd617fb4068b4ec5de696527ee3@BL2PR03MB468.namprd03.prod.outlook.com>
Hi Varun, Andreas,
On Tue, Jan 21, 2014 at 05:48:02PM +0000, Varun Sethi wrote:
> > +static int arm_smmu_group_notifier(struct notifier_block *nb,
> > + unsigned long action, void *data)
> > +{
> > + struct device *dev = data;
> > + struct dma_iommu_mapping *mapping;
> > + struct arm_smmu_device *smmu;
> > + int ret;
> > +
> > + switch (action) {
> > + case IOMMU_GROUP_NOTIFY_BIND_DRIVER:
> > +
> > + smmu = dev->archdata.iommu;
> > + if (!smmu || !(smmu->options & ARM_SMMU_OPT_ISOLATE_DEVICES))
> > + break;
> [Sethi Varun-B16395] Should this check be really done here? The "Isolate
> devices" property would allow us to set up iommu groups. My understanding
> is that if we specify the isolate devices property, then each device would
> have a separate iommu group otherwise all devices connected to the SMMU
> would share the iommu group.
That's not what currently happens (at least, in the patch I have queued for
groups). The code queued adds each device to its own group in
arm_smmu_add_device, which I think is the right thing to do.
> With that logic, we should link the mapping to the iommu group.
Ok, so are you suggesting that we perform the isolation mapping in
arm_smmu_add_device and drop the notifier altogether?
Will
^ permalink raw reply
* Kconfig errors
From: Russell King - ARM Linux @ 2014-01-22 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+V-a8uy6wM8nS993VeezJGOaoqM5GRsJE7FrKe7=bhD6nZhXw@mail.gmail.com>
On Wed, Jan 22, 2014 at 05:54:29PM +0530, Prabhakar Lad wrote:
> Hi Russell,
>
> On Fri, Jan 17, 2014 at 1:07 PM, Prabhakar Lad
> <prabhakar.csengg@gmail.com> wrote:
> > Hi,
> >
> > On Linux-next branch I see following errors for davinci_all_defconfig
> > & da8xx_omapl_defconfig configs,
> >
> > arch/arm/Kconfig:1966:error: recursive dependency detected!
> > arch/arm/Kconfig:1966: symbol ZBOOT_ROM depends on AUTO_ZRELADDR
> > arch/arm/Kconfig:2154: symbol AUTO_ZRELADDR is selected by ZBOOT_ROM
> > #
> > # configuration written to .config
> > #
> >
> I am seeing this errors on linux-next, with your recent patch,
> "[PATCH] Fix select-induced Kconfig warning for ZBOOT_ROM"
> and strangely I see that AUTO_ZRELADDR doesnt select ZBOOT_ROM
> but still an error.
>
> Note: For the davinci configs CONFIG_AUTO_ZRELADDR is not set and
> CONFIG_ZBOOT_ROM_TEXT=0x0, CONFIG_ZBOOT_ROM_BSS=0x0
I've killed off the "select AUTO_ZRELADDR if !ZBOOT_ROM" in the IMX
Kconfig now, so when linux-next picks up my tree, that should be gone.
--
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 RFC 4/6] net: rfkill: gpio: add device tree support
From: Mark Brown @ 2014-01-22 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401211950.07011.arnd@arndb.de>
On Tue, Jan 21, 2014 at 07:50:06PM +0100, Arnd Bergmann wrote:
> I should have another look at the debugfs representation, but isn't
> there a global namespace that gets used for all gpios? Neither the
> con_id nor the name that the driver picks would be globally unique
> and stable across kernel versions, so they don't make a good user
> interface.
Currently the globally unique name is the GPIO number but that's not
stable since it gets dynamically assigned.
> I think what we want here is a system-wide unique identifier for
> each gpio line that may get represented in debugfs, and use a new
> DT mechanism to communicate that.
We've mostly been using things based off dev_name() for stability.
-------------- 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/dfe74bd2/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] at91: gpio: use gpiolib API to mark a GPIO used as an IRQ
From: Jean-Jacques Hiblot @ 2014-01-22 12:39 UTC (permalink / raw)
To: linux-arm-kernel
When an IRQ is started on a GPIO line, mark this GPIO as IRQ in
the gpiolib so we can keep track of the usage centrally.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
---
arch/arm/mach-at91/gpio.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/mach-at91/gpio.c b/arch/arm/mach-at91/gpio.c
index a5afcf7..6176b4b 100644
--- a/arch/arm/mach-at91/gpio.c
+++ b/arch/arm/mach-at91/gpio.c
@@ -577,8 +577,32 @@ static int alt_gpio_irq_type(struct irq_data *d, unsigned type)
return 0;
}
+static unsigned int gpio_irq_startup(struct irq_data *d)
+{
+ struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
+ unsigned pin = d->hwirq;
+ int ret;
+
+ ret = gpio_lock_as_irq(&at91_gpio->chip, pin);
+ if (ret) {
+ dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
+ d->hwirq);
+ return ret;
+ }
+ return 0;
+}
+static void gpio_irq_shutdown(struct irq_data *d)
+{
+ struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
+ unsigned pin = d->hwirq;
+
+ gpio_unlock_as_irq(&at91_gpio->chip, pin);
+}
+
static struct irq_chip gpio_irqchip = {
.name = "GPIO",
+ .irq_shutdown = gpio_irq_shutdown,
+ .irq_startup = gpio_irq_startup,
.irq_disable = gpio_irq_mask,
.irq_mask = gpio_irq_mask,
.irq_unmask = gpio_irq_unmask,
--
1.8.5.2
^ permalink raw reply related
* [PATCH 2/2] at91: pinctrl: use gpiolib API to mark a GPIO used as an IRQ
From: Jean-Jacques Hiblot @ 2014-01-22 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390394341-12548-1-git-send-email-jjhiblot@traphandler.com>
When an IRQ is started on a GPIO line, mark this GPIO as IRQ in
the gpiolib so we can keep track of the usage centrally.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
---
drivers/pinctrl/pinctrl-at91.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index e8c8301..fbedde2 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -1299,6 +1299,28 @@ static int alt_gpio_irq_type(struct irq_data *d, unsigned type)
return 0;
}
+static unsigned int gpio_irq_startup(struct irq_data *d)
+{
+ struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
+ unsigned pin = d->hwirq;
+ int ret;
+
+ ret = gpio_lock_as_irq(&at91_gpio->chip, pin);
+ if (ret) {
+ dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
+ d->hwirq);
+ return ret;
+ }
+ return 0;
+}
+static void gpio_irq_shutdown(struct irq_data *d)
+{
+ struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
+ unsigned pin = d->hwirq;
+
+ gpio_unlock_as_irq(&at91_gpio->chip, pin);
+}
+
#ifdef CONFIG_PM
static u32 wakeups[MAX_GPIO_BANKS];
@@ -1377,6 +1399,8 @@ void at91_pinctrl_gpio_resume(void)
static struct irq_chip gpio_irqchip = {
.name = "GPIO",
+ .irq_startup = gpio_irq_startup,
+ .irq_shutdown = gpio_irq_shutdown,
.irq_disable = gpio_irq_mask,
.irq_mask = gpio_irq_mask,
.irq_unmask = gpio_irq_unmask,
--
1.8.5.2
^ permalink raw reply related
* [PATCH] watchdog: Add sp805_wdt depends on ARM64
From: naresh.bhat at linaro.org @ 2014-01-22 12:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Naresh Bhat <naresh.bhat@linaro.org>
Add sp805_wdt depends on ARM64.
Signed-off-by: Naresh Bhat <naresh.bhat@linaro.org>
---
drivers/watchdog/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 5be6e91..2385124 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -109,7 +109,7 @@ config WM8350_WATCHDOG
config ARM_SP805_WATCHDOG
tristate "ARM SP805 Watchdog"
- depends on ARM && ARM_AMBA
+ depends on (ARM || ARM64) && ARM_AMBA
select WATCHDOG_CORE
help
ARM Primecell SP805 Watchdog timer. This will reboot your system when
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] at91: gpio: use gpiolib API to mark a GPIO used as an IRQ
From: Gregory CLEMENT @ 2014-01-22 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390394341-12548-1-git-send-email-jjhiblot@traphandler.com>
Hi Jean-Jacques,
On 22/01/2014 13:39, Jean-Jacques Hiblot wrote:
> When an IRQ is started on a GPIO line, mark this GPIO as IRQ in
> the gpiolib so we can keep track of the usage centrally.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> arch/arm/mach-at91/gpio.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/mach-at91/gpio.c b/arch/arm/mach-at91/gpio.c
> index a5afcf7..6176b4b 100644
> --- a/arch/arm/mach-at91/gpio.c
> +++ b/arch/arm/mach-at91/gpio.c
> @@ -577,8 +577,32 @@ static int alt_gpio_irq_type(struct irq_data *d, unsigned type)
> return 0;
> }
>
> +static unsigned int gpio_irq_startup(struct irq_data *d)
> +{
> + struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
> + unsigned pin = d->hwirq;
> + int ret;
> +
> + ret = gpio_lock_as_irq(&at91_gpio->chip, pin);
> + if (ret) {
> + dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
> + d->hwirq);
> + return ret;
> + }
> + return 0;
> +}
Nitpick: a blank line should be nice here between the 2 functions
> +static void gpio_irq_shutdown(struct irq_data *d)
> +{
> + struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
> + unsigned pin = d->hwirq;
> +
> + gpio_unlock_as_irq(&at91_gpio->chip, pin);
> +}
> +
> static struct irq_chip gpio_irqchip = {
> .name = "GPIO",
> + .irq_shutdown = gpio_irq_shutdown,
> + .irq_startup = gpio_irq_startup,
> .irq_disable = gpio_irq_mask,
> .irq_mask = gpio_irq_mask,
> .irq_unmask = gpio_irq_unmask,
>
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] at91: pinctrl: use gpiolib API to mark a GPIO used as an IRQ
From: Gregory CLEMENT @ 2014-01-22 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390394341-12548-2-git-send-email-jjhiblot@traphandler.com>
Hi Jean-Jacques,
On 22/01/2014 13:39, Jean-Jacques Hiblot wrote:
> When an IRQ is started on a GPIO line, mark this GPIO as IRQ in
> the gpiolib so we can keep track of the usage centrally.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> drivers/pinctrl/pinctrl-at91.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index e8c8301..fbedde2 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -1299,6 +1299,28 @@ static int alt_gpio_irq_type(struct irq_data *d, unsigned type)
> return 0;
> }
>
> +static unsigned int gpio_irq_startup(struct irq_data *d)
> +{
> + struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
> + unsigned pin = d->hwirq;
> + int ret;
> +
> + ret = gpio_lock_as_irq(&at91_gpio->chip, pin);
> + if (ret) {
> + dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
> + d->hwirq);
> + return ret;
> + }
> + return 0;
> +}
As for the 1st patch, a blank line between the 2 functions should be nice
Thanks,
Gregory
> +static void gpio_irq_shutdown(struct irq_data *d)
> +{
> + struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
> + unsigned pin = d->hwirq;
> +
> + gpio_unlock_as_irq(&at91_gpio->chip, pin);
> +}
> +
> #ifdef CONFIG_PM
>
> static u32 wakeups[MAX_GPIO_BANKS];
> @@ -1377,6 +1399,8 @@ void at91_pinctrl_gpio_resume(void)
>
> static struct irq_chip gpio_irqchip = {
> .name = "GPIO",
> + .irq_startup = gpio_irq_startup,
> + .irq_shutdown = gpio_irq_shutdown,
> .irq_disable = gpio_irq_mask,
> .irq_mask = gpio_irq_mask,
> .irq_unmask = gpio_irq_unmask,
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 00/36] mtd: st_spi_fsm: Add new driver
From: Lee Jones @ 2014-01-22 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140108143316.GA14575@lee--X1>
Hi Brian,
> Version 4:
> Tended to Brian's previous review comments
> - Checkpatch acceptance
> - MODULE_DEVICE_TABLE() name slip correction
> - Timeout issue(s) resolved
> - Potential infinite loop mitigated
> - Code clarity suggests heeded
> - Duplication with MTD core code removed
> - Upgraded to using ROUND_UP() helper
> - Moved non-shared header code into main driver
> - Relocated dynamic msg sequence stores into main struct
> - Averted adaption of static (table) data
> - Basic whitespace/spelling/data type/dev_err suggestions accepted
>
> Version 3:
> Okay, this thing should be fully functional now. Identify a chip
> based on it's JEDEC ID, Read, Write, Erase (all or by sector).
> Support for various chip quirks added too.
>
> Version 2:
> The first bunch of these patches have been on the MLs before, but
> didn't receive a great deal of attention for the most part. We are
> a little more featureful this time however. We can now successfully
> setup and configure the N25Q256. We still can't read/write/erase
> it though. I'll start work on that next week and will provide it in
> the next instalment.
>
> Version 1:
> First stab at getting this thing Mainlined. It doesn't do a great deal
> yet, but we are able to initialise the device and dynamically set it up
> correctly based on an extracted JEDEC ID.
>
> Documentation/devicetree/bindings/mtd/st-fsm.txt | 26 ++
> arch/arm/boot/dts/stih416-b2105.dts | 14 +
> arch/arm/boot/dts/stih416-pinctrl.dtsi | 12 +
> drivers/mtd/devices/Kconfig | 8 +
> drivers/mtd/devices/Makefile | 1 +
> drivers/mtd/devices/serial_flash_cmds.h | 81 ++++
> drivers/mtd/devices/st_spi_fsm.c | 2124 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 7 files changed, 2266 insertions(+)
Can you confirm receipt of this set, or would you like me to resend?
Kind regards,
Lee
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH RFC 03/26] dmaengine: omap-dma: program hardware directly
From: Sricharan R @ 2014-01-22 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1Vyjtf-0005E5-Vw@rmk-PC.arm.linux.org.uk>
On Thursday 02 January 2014 08:39 PM, Russell King wrote:
> Program the transfer parameters directly into the hardware, rather
> than using the functions in arch/arm/plat-omap/dma.c.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/dma/omap-dma.c | 144 ++++++++++++++++++++++++++++++++++++++++-----
> include/linux/omap-dma.h | 6 +-
> 2 files changed, 132 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 3c1bb34aad0a..dd233ca2cf5a 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -99,16 +99,96 @@ static void omap_dma_start_sg(struct omap_chan *c, struct omap_desc *d,
> unsigned idx)
> {
> struct omap_sg *sg = d->sg + idx;
> + uint32_t val;
> +
> + if (d->dir == DMA_DEV_TO_MEM) {
> + if (dma_omap1()) {
> + val = c->plat->dma_read(CSDP, c->dma_ch);
> + val &= ~(0x1f << 9);
> + val |= OMAP_DMA_PORT_EMIFF << 9;
> + c->plat->dma_write(val, CSDP, c->dma_ch);
> + }
>
> - if (d->dir == DMA_DEV_TO_MEM)
> - omap_set_dma_dest_params(c->dma_ch, OMAP_DMA_PORT_EMIFF,
> - OMAP_DMA_AMODE_POST_INC, sg->addr, 0, 0);
> - else
> - omap_set_dma_src_params(c->dma_ch, OMAP_DMA_PORT_EMIFF,
> - OMAP_DMA_AMODE_POST_INC, sg->addr, 0, 0);
> + val = c->plat->dma_read(CCR, c->dma_ch);
> + val &= ~(0x03 << 14);
> + val |= OMAP_DMA_AMODE_POST_INC << 14;
> + c->plat->dma_write(val, CCR, c->dma_ch);
> +
> + c->plat->dma_write(sg->addr, CDSA, c->dma_ch);
> + c->plat->dma_write(0, CDEI, c->dma_ch);
> + c->plat->dma_write(0, CDFI, c->dma_ch);
> + } else {
> + if (dma_omap1()) {
> + val = c->plat->dma_read(CSDP, c->dma_ch);
> + val &= ~(0x1f << 2);
> + val |= OMAP_DMA_PORT_EMIFF << 2;
> + c->plat->dma_write(val, CSDP, c->dma_ch);
> + }
> +
> + val = c->plat->dma_read(CCR, c->dma_ch);
> + val &= ~(0x03 << 12);
> + val |= OMAP_DMA_AMODE_POST_INC << 12;
> + c->plat->dma_write(val, CCR, c->dma_ch);
> +
> + c->plat->dma_write(sg->addr, CSSA, c->dma_ch);
> + c->plat->dma_write(0, CSEI, c->dma_ch);
> + c->plat->dma_write(0, CSFI, c->dma_ch);
> + }
> +
EI and FI are always set to zero. So interleaved transfers support
have to enabled in omap-dma, as it was supported by the
legacy driver. It was not enabled because of no users of the feature,
right ?
Regards,
Sricharan
^ permalink raw reply
* [PATCH RFC 08/26] dmaengine: omap-dma: consolidate setup of CCR
From: Sricharan R @ 2014-01-22 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1VyjuU-0005EQ-H5@rmk-PC.arm.linux.org.uk>
Hi Russell,
On Thursday 02 January 2014 08:40 PM, Russell King wrote:
> Consolidate the setup of the channel control register. Prepare the
> basic value in the preparation of the DMA descriptor, and write it into
> the register upon descriptor execution.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/dma/omap-dma.c | 133 ++++++++++++++++-------------------------------
> 1 files changed, 45 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
> index 98928f7209f6..796f882da03c 100644
> --- a/drivers/dma/omap-dma.c
> +++ b/drivers/dma/omap-dma.c
> @@ -58,8 +58,7 @@ struct omap_desc {
>
> int16_t fi; /* for OMAP_DMA_SYNC_PACKET */
> uint8_t es; /* OMAP_DMA_DATA_TYPE_xxx */
> - uint8_t sync_mode; /* OMAP_DMA_SYNC_xxx */
> - uint8_t sync_type; /* OMAP_DMA_xxx_SYNC* */
> + uint32_t ccr; /* CCR value */
> uint16_t cicr; /* CICR value */
> uint32_t csdp; /* CSDP value */
>
> @@ -228,7 +227,6 @@ static void omap_dma_start_desc(struct omap_chan *c)
> {
> struct virt_dma_desc *vd = vchan_next_desc(&c->vc);
> struct omap_desc *d;
> - uint32_t val;
>
> if (!vd) {
> c->desc = NULL;
> @@ -240,23 +238,15 @@ static void omap_dma_start_desc(struct omap_chan *c)
> c->desc = d = to_omap_dma_desc(&vd->tx);
> c->sgidx = 0;
>
> - if (d->dir == DMA_DEV_TO_MEM) {
> - val = c->plat->dma_read(CCR, c->dma_ch);
> - val &= ~(0x03 << 14 | 0x03 << 12);
> - val |= OMAP_DMA_AMODE_POST_INC << 14;
> - val |= OMAP_DMA_AMODE_CONSTANT << 12;
> - c->plat->dma_write(val, CCR, c->dma_ch);
> + c->plat->dma_write(d->ccr, CCR, c->dma_ch);
> + if (dma_omap1())
> + c->plat->dma_write(d->ccr >> 16, CCR2, c->dma_ch);
>
> + if (d->dir == DMA_DEV_TO_MEM) {
> c->plat->dma_write(d->dev_addr, CSSA, c->dma_ch);
> c->plat->dma_write(0, CSEI, c->dma_ch);
> c->plat->dma_write(d->fi, CSFI, c->dma_ch);
> } else {
> - val = c->plat->dma_read(CCR, c->dma_ch);
> - val &= ~(0x03 << 12 | 0x03 << 14);
> - val |= OMAP_DMA_AMODE_CONSTANT << 14;
> - val |= OMAP_DMA_AMODE_POST_INC << 12;
> - c->plat->dma_write(val, CCR, c->dma_ch);
> -
> c->plat->dma_write(d->dev_addr, CDSA, c->dma_ch);
> c->plat->dma_write(0, CDEI, c->dma_ch);
> c->plat->dma_write(d->fi, CDFI, c->dma_ch);
> @@ -264,47 +254,6 @@ static void omap_dma_start_desc(struct omap_chan *c)
>
> c->plat->dma_write(d->csdp, CSDP, c->dma_ch);
>
> - if (dma_omap1()) {
> - val = c->plat->dma_read(CCR, c->dma_ch);
> - val &= ~(1 << 5);
> - if (d->sync_mode == OMAP_DMA_SYNC_FRAME)
> - val |= 1 << 5;
> - c->plat->dma_write(val, CCR, c->dma_ch);
> -
> - val = c->plat->dma_read(CCR2, c->dma_ch);
> - val &= ~(1 << 2);
> - if (d->sync_mode == OMAP_DMA_SYNC_BLOCK)
> - val |= 1 << 2;
> - c->plat->dma_write(val, CCR2, c->dma_ch);
> - }
> -
> - if (dma_omap2plus() && c->dma_sig) {
> - val = c->plat->dma_read(CCR, c->dma_ch);
> -
> - /* DMA_SYNCHRO_CONTROL_UPPER depends on the channel number */
> - val &= ~(1 << 24 | 1 << 23 | 3 << 19 | 1 << 18 | 1 << 5 | 0x1f);
> - val |= (c->dma_sig & ~0x1f) << 14;
> - val |= c->dma_sig & 0x1f;
> -
> - if (d->sync_mode & OMAP_DMA_SYNC_FRAME)
> - val |= 1 << 5;
> -
> - if (d->sync_mode & OMAP_DMA_SYNC_BLOCK)
> - val |= 1 << 18;
> -
> - switch (d->sync_type) {
> - case OMAP_DMA_DST_SYNC_PREFETCH:/* dest synch */
> - val |= 1 << 23; /* Prefetch */
> - break;
> - case 0:
> - break;
> - default:
> - val |= 1 << 24; /* source synch */
> - break;
> - }
> - c->plat->dma_write(val, CCR, c->dma_ch);
> - }
> -
> omap_dma_start_sg(c, d, 0);
> }
>
> @@ -543,19 +492,17 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
> struct scatterlist *sgent;
> struct omap_desc *d;
> dma_addr_t dev_addr;
> - unsigned i, j = 0, es, en, frame_bytes, sync_type;
> + unsigned i, j = 0, es, en, frame_bytes;
> u32 burst;
>
> if (dir == DMA_DEV_TO_MEM) {
> dev_addr = c->cfg.src_addr;
> dev_width = c->cfg.src_addr_width;
> burst = c->cfg.src_maxburst;
> - sync_type = OMAP_DMA_SRC_SYNC;
> } else if (dir == DMA_MEM_TO_DEV) {
> dev_addr = c->cfg.dst_addr;
> dev_width = c->cfg.dst_addr_width;
> burst = c->cfg.dst_maxburst;
> - sync_type = OMAP_DMA_DST_SYNC;
> } else {
> dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
> return NULL;
> @@ -584,12 +531,20 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
> d->dir = dir;
> d->dev_addr = dev_addr;
> d->es = es;
> - d->sync_mode = OMAP_DMA_SYNC_FRAME;
> - d->sync_type = sync_type;
> +
> + d->ccr = 0;
> + if (dir == DMA_DEV_TO_MEM)
> + d->ccr |= OMAP_DMA_AMODE_POST_INC << 14 |
> + OMAP_DMA_AMODE_CONSTANT << 12;
> + else
> + d->ccr |= OMAP_DMA_AMODE_CONSTANT << 14 |
> + OMAP_DMA_AMODE_POST_INC << 12;
> +
> d->cicr = OMAP_DMA_DROP_IRQ | OMAP_DMA_BLOCK_IRQ;
> d->csdp = es;
>
> if (dma_omap1()) {
> + d->ccr |= 1 << 5; /* frame sync */
> d->cicr |= OMAP1_DMA_TOUT_IRQ;
>
> if (dir == DMA_DEV_TO_MEM)
> @@ -599,6 +554,13 @@ static struct dma_async_tx_descriptor *omap_dma_prep_slave_sg(
> d->csdp |= OMAP_DMA_PORT_TIPB << 9 |
> OMAP_DMA_PORT_EMIFF << 2;
> } else if (dma_omap2plus()) {
> + d->ccr |= (c->dma_sig & ~0x1f) << 14;
> + d->ccr |= c->dma_sig & 0x1f;
> + d->ccr |= 1 << 5; /* frame sync */
> +
> + if (dir == DMA_DEV_TO_MEM)
> + d->ccr |= 1 << 24; /* source synch */
> +
> d->cicr |= OMAP2_DMA_MISALIGNED_ERR_IRQ | OMAP2_DMA_TRANS_ERR_IRQ;
> }
>
> @@ -635,19 +597,17 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
> enum dma_slave_buswidth dev_width;
> struct omap_desc *d;
> dma_addr_t dev_addr;
> - unsigned es, sync_type;
> + unsigned es;
> u32 burst;
>
> if (dir == DMA_DEV_TO_MEM) {
> dev_addr = c->cfg.src_addr;
> dev_width = c->cfg.src_addr_width;
> burst = c->cfg.src_maxburst;
> - sync_type = OMAP_DMA_SRC_SYNC;
> } else if (dir == DMA_MEM_TO_DEV) {
> dev_addr = c->cfg.dst_addr;
> dev_width = c->cfg.dst_addr_width;
> burst = c->cfg.dst_maxburst;
> - sync_type = OMAP_DMA_DST_SYNC;
> } else {
> dev_err(chan->device->dev, "%s: bad direction?\n", __func__);
> return NULL;
> @@ -677,15 +637,21 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
> d->dev_addr = dev_addr;
> d->fi = burst;
> d->es = es;
> - if (burst)
> - d->sync_mode = OMAP_DMA_SYNC_PACKET;
> - else
> - d->sync_mode = OMAP_DMA_SYNC_ELEMENT;
> - d->sync_type = sync_type;
> d->sg[0].addr = buf_addr;
> d->sg[0].en = period_len / es_bytes[es];
> d->sg[0].fn = buf_len / period_len;
> d->sglen = 1;
> +
> + d->ccr = 0;
> + if (__dma_omap15xx(od->plat->dma_attr))
> + d->ccr = 3 << 8;
> + if (dir == DMA_DEV_TO_MEM)
> + d->ccr |= OMAP_DMA_AMODE_POST_INC << 14 |
> + OMAP_DMA_AMODE_CONSTANT << 12;
> + else
> + d->ccr |= OMAP_DMA_AMODE_CONSTANT << 14 |
> + OMAP_DMA_AMODE_POST_INC << 12;
> +
> d->cicr = OMAP_DMA_DROP_IRQ;
> if (flags & DMA_PREP_INTERRUPT)
> d->cicr |= OMAP_DMA_FRAME_IRQ;
> @@ -702,23 +668,22 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic(
> d->csdp |= OMAP_DMA_PORT_MPUI << 9 |
> OMAP_DMA_PORT_EMIFF << 2;
> } else if (dma_omap2plus()) {
> + d->ccr |= (c->dma_sig & ~0x1f) << 14;
> + d->ccr |= c->dma_sig & 0x1f;
> +
> + if (burst)
> + d->ccr |= 1 << 18 | 1 << 5; /* packet */
> +
> + if (dir == DMA_DEV_TO_MEM)
> + d->ccr |= 1 << 24; /* source synch */
> +
> d->cicr |= OMAP2_DMA_MISALIGNED_ERR_IRQ | OMAP2_DMA_TRANS_ERR_IRQ;
>
> /* src and dst burst mode 16 */
> d->csdp |= 3 << 14 | 3 << 7;
> }
>
> - if (!c->cyclic) {
> - c->cyclic = true;
> -
> - if (__dma_omap15xx(od->plat->dma_attr)) {
> - uint32_t val;
> -
> - val = c->plat->dma_read(CCR, c->dma_ch);
> - val |= 3 << 8;
> - c->plat->dma_write(val, CCR, c->dma_ch);
> - }
> - }
> + c->cyclic = true;
>
> return vchan_tx_prep(&c->vc, &d->vd, flags);
> }
> @@ -762,14 +727,6 @@ static int omap_dma_terminate_all(struct omap_chan *c)
> if (c->cyclic) {
> c->cyclic = false;
> c->paused = false;
> -
> - if (__dma_omap15xx(od->plat->dma_attr)) {
> - uint32_t val;
> -
> - val = c->plat->dma_read(CCR, c->dma_ch);
> - val &= ~(3 << 8);
> - c->plat->dma_write(val, CCR, c->dma_ch);
> - }
> }
>
> vchan_get_all_descriptors(&c->vc, &head);
Setting up of DMA_DST_SYNC_PREFETCH is missing after this ?
Regards,
Sricharan
^ permalink raw reply
* [PATCH 2/3] ARM: kexec: copying code to ioremapped area
From: Wang Nan @ 2014-01-22 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANacCWz2DdLvns9htszpwWnASrYGXQt+tHMsw4aBbjoyw-DmeQ@mail.gmail.com>
On 2014/1/22 20:56, Vaibhav Bedia wrote:
> On Wed, Jan 22, 2014 at 6:25 AM, Wang Nan <wangnan0 at huawei.com <mailto:wangnan0@huawei.com>> wrote:
>
> 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.
>
>
> AFAIK ioremap on RAM in forbidden in ARM and device memory that ioremap()
> ends up creating is not meant for executable code.
>
> Doesn't this trigger the WARN_ON() in _arm_ioremap_pfn_caller)?
This patch is depend on the previous one:
ARM: Premit ioremap() to map reserved pages
However, Russell is opposed to it.
^ 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