* [PATCH v3 1/6] ARM: davinci: sram: ioremap the davinci_soc_info specified sram regions
From: Sekhar Nori @ 2012-10-04 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349276133-26408-2-git-send-email-mporter@ti.com>
On 10/3/2012 8:25 PM, Matt Porter wrote:
> From: Ben Gardiner <bengardiner@nanometrics.ca>
>
> The current davinci init sets up SRAM in iotables. There has been an observed
> failure to boot a da850 with 128K specified in the iotable.
>
> Make the davinci sram allocator -- now based on RMK's consolidated SRAM
> support -- do an ioremap of the region specified by the entries in
The part about being based on RMK's consolidated SRAM support should be
dropped.
> davinci_soc_info before registering with gen_pool_add_virt().
>
> This commit breaks runtime of davinci boards since the regions that
> the sram init is now trying to ioremap have been iomapped by their
> iotable entries. The iotable entries will be removed in the patches
> to come.
I would prefer merging 2/6 into this for this reason.
>
> Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
> [rebased to mainline as the consolidated SRAM support was dropped]
> Signed-off-by: Matt Porter <mporter@ti.com>
> ---
> arch/arm/mach-davinci/sram.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> index db0f778..0e8ca4f 100644
> --- a/arch/arm/mach-davinci/sram.c
> +++ b/arch/arm/mach-davinci/sram.c
> @@ -10,6 +10,7 @@
> */
> #include <linux/module.h>
> #include <linux/init.h>
> +#include <linux/io.h>
> #include <linux/genalloc.h>
>
> #include <mach/common.h>
> @@ -32,7 +33,7 @@ void *sram_alloc(size_t len, dma_addr_t *dma)
> return NULL;
>
> if (dma)
> - *dma = dma_base + (vaddr - SRAM_VIRT);
> + *dma = gen_pool_virt_to_phys(sram_pool, vaddr);
> return (void *)vaddr;
>
> }
> @@ -53,8 +54,10 @@ EXPORT_SYMBOL(sram_free);
> */
> static int __init sram_init(void)
> {
> + phys_addr_t phys = davinci_soc_info.sram_dma;
> unsigned len = davinci_soc_info.sram_len;
> int status = 0;
> + void *addr;
>
> if (len) {
> len = min_t(unsigned, len, SRAM_SIZE);
> @@ -62,8 +65,16 @@ static int __init sram_init(void)
> if (!sram_pool)
> status = -ENOMEM;
> }
> - if (sram_pool)
> - status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
> +
> + if (sram_pool) {
> + addr = ioremap(phys, len);
> + if (!addr)
> + return -ENOMEM;
> + if((status = gen_pool_add_virt(sram_pool, (unsigned)addr,
> + phys, len, -1)))
Nit: prefer to set status outside of if().
Looks good otherwise. Thanks for reviving this.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] [ARM] Use AT() in the linker script to create correct program headers
From: Dave Martin @ 2012-10-04 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121003184437.GB12231@obsidianresearch.com>
On Wed, Oct 03, 2012 at 12:44:38PM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 03, 2012 at 11:43:35AM +0100, Dave Martin wrote:
>
> > I'm not sure exactly what you mean by linking the DTB into vmlinux.
> > I don't think this is supported upstream, at least for ARM. It could
> > be done externally by post-processing vmlinux to add extra sections
> > and some boot shim code which initialises the registers appropriately
> > for kernel entry ... but you're really inventing a bootloader if you
> > start to do that.
>
> We use the existing build infrastructure (see cmd_dt_S_dtb) and add a
> 4 line patch to head.S to put the dtb address into the right
> register. I think it would be great to have a CONFIG_ARM_BUILT_IN_DTB
> for applications like mine, but it is really no problem to carry the
> head.S patch. The normal build process produces a vmlinux that is self
> contained, no post processing required.
OK, so it is supported, but not for ARM, yet. I'm not sure that such
a patch would be rejected, since building in a DTB is not really that
different from building in a command-line.
The post-processing that would otherwise be needed is likely to be
pretty trivial, though (see example below).
> > Making a simple bootloader DT-aware is not actually that hard: libfdt
> > is intentionally pretty straightforward to integrate.
>
> Sure, but we have several major issues with that entire idea:
> 1) Our bootloader (on PPC and ARM) is in redundant NOR flash and
> is limited to 16K. That is just enough to do gzip, elf, cramfs
> and tftpv6 - there is no space left for dtb or fdt code.
> 2) Experience using DT with PPC has shown that the vmlinux is very
> sensitive to the DTB. Every DTB/vmlinux combination must be tested
> to ensure it works. By far the best way to manage this *for us* is
> to guarentee that the vmlinux sees only the DTB it was designed
> for by including it in vmlinux.
> 3) The DTB *changes*. We change it because we've changed things in the
> programmable part of our environment and we change it because the
> kernel has shifted. Planning for this inevitable change is
> necessary.
> 4) On our ARM platforms updating the boot loader in the field is more
> challenging than updating the vmlinux, not impossible, but not
> something we want to do every day. Our PPC boot loader has
> survived without change since 2007, and has booted kernels from
> 2.6.12 to 3.6 with and without DT. This is a time tested,
> field proven approach.
>
> Fundamentally we treat the DTB like the .config - an integral,
> internal, part of vmlinux.
>
> As far as I can see, the *only* argument to put the DT in the boot
> loader is to support standard, distribution kernels.
DT-aware does not have to mean that the DTB is part of the bootloader.
Generally, that's considered to be a bad idea for the reasons you
describe (among others).
The other solution to this problem is to distribute the dtb alongside the
kernel as a supplementary image (similar to initramfs), with the
bootloader doing the bare minimum of modifications to it.
Naturally, if zero modifications are needed then the bootloader does not
need libfdt (or equivalent code) at all.
> > It's more than 100 lines, but not _that_ much more, and contains
> > some implementation features you probably don't need.
>
> But that is not enough, variations of our platforms use bit bang I2C,
> SPI and NOR FLASH to store things like the MAC address and other
> DT-relevant information. So, swaths of that code would need to go into
> the boot loader/zImage as well.
>
> At that point we may as well take our chances with uBoot. :)
>
> > From my side, I think that the fact this takes arch/arm/vmlinux.lds.S
> > closer to some other common arches means that this is low risk and should
> > be mostly harmless, but I will take another look at the patch first.
>
> This matches my opinion..
>
> > > > You store vmlinux.gz in a cramfs? Is that a typo, or have you already
> > > > compressed the kernel twice?
> > >
> > > The compression can either be intrisic to cramfs or a raw elf that has
> > > been gzip'd.
> >
> > If you can have files with intrinsic compression such that they don't
> > get double-compressed, why can you not do this for zImage?
> >
> > Am I still misunderstanding something?
>
> We have two boot modes, one boots ELF.gz (for development), the other
> boots ELF in CRAMFS (for deployment). Both are compressed, one is
> compressed using gzip and one is compressed using zlib in CRAMFS. It
> is hard to see how to store a zImage in CRAMFS and avoid double
> de-compression. We never store an ELF.gz in CRAMFS.
OK, now I understand.
> Since the entire point of zImage is to introduce compression it is
> hard to see *why* we'd want to store a zImage in a CRAMFS.
Because zImage has grown one or two extra features (which in fact have
nothing to do with compression). But I can see why you're not keen
on the idea. In principle we could have an uncompressed zImage, but
for now this doesn't exist.
One other option open to you would be to provide an ELF image loadable
by your bootloader via a simple wrapper. This would probably be a more
robust approach than carrying patches against head.S, since it removes
any intimate dependency on the kernel code itself.
---8<--- boot.lds.S ---
OUTPUT_FORMAT(elf32-littlearm)
TARGET(binary)
INPUT(Image)
INPUT(dtb)
TARGET(elf32-littlearm)
ENTRY(__entry)
SECTIONS {
.text PHYS_OFFSET : {
boot.o(.text)
}
kernel PHYS_OFFSET + TEXT_OFFSET : {
__kernel_entry = .;
Image(*)
payload PHYS_OFFSET + PAYLOAD_OFFSET : {
__dtb_start = .;
dtb(*)
}
/DISCARD/ : {
*(*)
}
}
--- boot.S ---
.globl __entry
.type __entry, %function
__entry:
mov r0, #0
mov r1, #0xFFFFFFFF
ldr r2, =__dtb_start
b __kernel_entry
--->8---
Where PHYS_OFFSET and TEXT_OFFSET are the appropriate definitions
for your platform, and PAYLOAD_OFFSET is an appropriate safe
location for the dtb.
The resulting image can be a bit smaller than vmlinux, too (but only
slightly).
---Dave
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Daniel Mack @ 2012-10-04 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004102819.GA11149@beef>
On 04.10.2012 12:28, Matt Porter wrote:
> On Thu, Oct 04, 2012 at 11:57:30AM +0200, Daniel Mack wrote:
>> On 04.10.2012 11:38, Porter, Matt wrote:
>>>
>>> On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:
>>>
>>>>
>>>>
>>>> On 02.10.2012 18:50, Daniel Mack wrote:
>>>>> On 02.10.2012 18:41, Matt Porter wrote:
>>>>>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>>>>>>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>>>>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>>>>>>>>> On 02.10.2012 11:37, Mark Brown wrote:
>>>>>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>>>>>>>>
>>>>>>>>>>> I also agree that ifdef is not a good solution.
>>>>>>>>>>> It is better to have this information passed as device_data and via DT it can
>>>>>>>>>>> be decided based on the compatible property for the device.
>>>>>>>>>>
>>>>>>>>>> That's not really the problem here - the problem is that the APIs used
>>>>>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>>>>>>>>> or other platforms. The SRAM code needs to move to a standard API.
>>>>>>>>>
>>>>>>>>> What about following Matt Porter's idea and ignore the SRAM code
>>>>>>>>> entirely and port the entire PCM code to generic dmaengine code first?
>>>>>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>>>>>>>>> might give that a try in near future.
>>>>>>>>>
>>>>>>>>> Later on, the SRAM ping-pong code can get added back using genalloc
>>>>>>>>> functions, as Sekhar proposed. That needs to be done by someone who has
>>>>>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
>>>>>>>>
>>>>>>>> We cannot "get rid" of SRAM code and add it back "later". It is required
>>>>>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
>>>>>>>> (conversion should be straightforward and I can help test it) and the
>>>>>>>> code that uses SRAM can probably keep using the private EDMA API till
>>>>>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
>>>>>>>> posted patches to move private EDMA APIs to a common location. That
>>>>>>>> should keep AM335x build from breaking. Is this something that is feasible?
>>>>>>>
>>>>>>> Yes - by "later" I just meant in a subsequent patch. But you're probably
>>>>>>> right, we can also do that first.
>>>>>>>
>>>>>>> I'm looking at that right now and the problem seems that we don't have a
>>>>>>> sane way to dynamically look up gen_pools independently of the actual
>>>>>>> run-time platform. All users of gen_pools seem to know which platform
>>>>>>> they run on and access a platform-specific pool. So I don't currently
>>>>>>> see how we could implement multi-platform code, gen_pools are fine but
>>>>>>> don't solve the problem here.
>>>>>>>
>>>>>>> Would it be an idea to add a char* member to gen_pools and a function
>>>>>>> that can be used to dynamically look it up again? If a buffer with a
>>>>>>> certain name exists, we can use it and install that ping-pong buffer,
>>>>>>> otherwise we just don't. While that would be easy to do, it's a
>>>>>>> tree-wide change.
>>>>>>>
>>>>>>> Is there a better way that I miss?
>>>>>>
>>>>>> At the high level there's two platform models we have to handle, the
>>>>>> boot from board file !DT case, and then the boot from DT case. Since
>>>>>> Davinci is just starting DT conversion, we mostly care about the !DT
>>>>>> base in which the struct gen_pool * is passed in pdata to the ASoC
>>>>>> driver. It is then selectable on a per-platform basis where the decision
>>>>>> should be made.
>>>>>>
>>>>>> Given a separate discussion with Sekhar, we're only going to have one
>>>>>> SRAM pool on any DaVinci part right now...this was only a question on
>>>>>> L138 anyway. But regardless, the created gen_pool will be passed via
>>>>>> pdata.
>>>>>
>>>>> I thought about this too, as mmp does it that way.
>>>>>
>>>>>> Since DT conversion is starting and we need to consider that now,
>>>>>> the idea there is to use the DT-based generic sram driver [1] such that
>>>>>> when we do boot from DT on Davinci, the genpool is provided via phandle
>>>>>> and the pointer extracted with the OF helpers that are part of the
>>>>>> series.
>>>>>
>>>>> A phandle is the cleanest way I think, yes.
>>>>>
>>>>>> That's pretty much it. I'm reworking the backend support as discussed
>>>>>> with Sekhar wrt to my uio_pruss series. I can post a standalone series
>>>>>> that just replaces sram_* with genalloc for davinci ASoC.
>>>>>
>>>>> As you can also test it, it would be easiest if you came up with a patch
>>>>> for that, yes. I can have a look at the dma bits laters, once my OMAP
>>>>> board finally works with the code as it currently stands. I'm still
>>>>> fighting with the mcasp driver right now ...
>>>>
>>>> I quickly prepared two patches to change that, so that topic is out of
>>>> the way. But I did only compile-test them on OMAP - could you check on
>>>> your Davinci platform? Note that these apply on top of the patch in
>>>> discussion here (which isn't applied to the asoc tree yet).
>>>
>>> I put a series together yesterday, just ran out of time to post
>>> last night after testing. I'm posting that now...it's on top of my
>>> uio_pruss/genalloc series and only addresss switching davinci-pcm to
>>> genalloc (and actually enabling ping-pon from sram).
>>
>> Ok, I don't care which version makes it in after all :)
>
> Ok :)
>
>>> I'll take a look a your OMAP patches.
>>
>> The patches I just sent out are only for Davinci and change the SRAM
>> functions to genalloc in the mcasp driver. They work just fine on OMAP
>> of course, as the code is disabled in there.
>
> Ok, same thing as I did and just sent out. These are tested on AM180x
> and hook up ping-pong buffering so that there's actually one user of
> all this ping-pong code. It's been sitting idle for a long time.
>
> I didn't see your patches come by yet but will take a look to see if
> we need to combine.
I attached them to my mail for a quick review. I wanted to queue them up
to a bigger series I'll send out later ...
Daniel
^ permalink raw reply
* [PATCH] serial: i.MX: evaluate linux,stdout-path property
From: Sascha Hauer @ 2012-10-04 10:39 UTC (permalink / raw)
To: linux-arm-kernel
devicetrees may have the linux,stdout-path property to specify the
console. This patch adds support to the i.MX serial driver for this.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
I was originally looking for a more generic way to handle this, but
since a struct console has no device associated to it, it's not
possible to match a console with a device in a generic way. So we
just call add_preferred_console from the driver and let it go down
to a string matching in the console code.
If anyone has a better idea how to handle this, please let me know.
Otherwise I'm happy to see this patch applied aswell.
Thanks
Sascha
drivers/tty/serial/imx.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e309e8b..b52c4a7 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1397,6 +1397,32 @@ static int serial_imx_resume(struct platform_device *dev)
#ifdef CONFIG_OF
/*
+ * Check if this device matches the linux,stdout-path property
+ * in the chosen node. return true if yes, false otherwise
+ */
+static int serial_imx_is_stdoutpath(struct platform_device *pdev)
+{
+ struct device_node *dn;
+ const char *name;
+
+ if (!IS_ENABLED(CONFIG_SERIAL_IMX_CONSOLE))
+ return 0;
+
+ name = of_get_property(of_chosen, "linux,stdout-path", NULL);
+ if (name == NULL)
+ return 0;
+
+ dn = of_find_node_by_path(name);
+ if (!dn)
+ return 0;
+
+ if (dn == pdev->dev.of_node)
+ return 1;
+
+ return 0;
+}
+
+/*
* This function returns 1 iff pdev isn't a device instatiated by dt, 0 iff it
* could successfully get all information from dt or a negative errno.
*/
@@ -1427,6 +1453,9 @@ static int serial_imx_probe_dt(struct imx_port *sport,
sport->devdata = of_id->data;
+ if (serial_imx_is_stdoutpath(pdev))
+ add_preferred_console(imx_reg.cons->name, sport->port.line, 0);
+
return 0;
}
#else
--
1.7.10.4
^ permalink raw reply related
* [PATCH 12/17] ARM: iop13xx: mark iop13xx_scan_bus as __devinit
From: Arnd Bergmann @ 2012-10-04 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo7rkN_F=AxweoEG3oXj392FvzVGPSKnkXCd=JX6cg0aTA@mail.gmail.com>
(+Greg)
On Tuesday 02 October 2012, Bjorn Helgaas wrote:
>
> On Tue, Oct 2, 2012 at 10:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > pci_scan_root_bus is __devinit, so iop13xx_scan_bus has to be the
> > same in order to safely call it. This is ok because the function
> > itself is only called from the hwpci->scan callback.
> >
> > WARNING: vmlinux.o(.text+0x10138): Section mismatch in reference from the function iop13xx_scan_bus() to the function .devinit.text:pci_scan_root_bus()
> > The function iop13xx_scan_bus() references
> > the function __devinit pci_scan_root_bus().
> > This is often because iop13xx_scan_bus lacks a __devinit
> > annotation or the annotation of pci_scan_root_bus is wrong.
>
> With CONFIG_HOTPLUG going away (I think the current state is that it
> is always set to "y"), __devinit will effectively become a no-op, so I
> expect we'll remove it from pci_scan_root_bus().
>
> Therefore, I would skip this patch and live with the warning a little longer.
Hmm, I'm just trying to get rid of all build time warnings in the defconfigs
right now, and modpost still complains about the section mismatches. I have
a bunch more of these patches, but it would also be fine with me if we can
patch mostpost to ignore these cases.
I've also redone the analysis that Greg cited in the commit message for
45f035ab9b8 "CONFIG_HOTPLUG should be always on"
It is quite hard to disable it these days, and even if you do, it
only saves you about 200 bytes. However, if it is disabled, lots of
bugs show up because it is almost never tested if the option is disabled.
My test case (ARM omap2plus_defconfig, one of the most common configurations)
shows these size -A differences:
section nohotplug hotplug difference
.head.text 392 392 0
.text 4829940 4881140 51200
.rodata 1630360 1633056 2696
__ksymtab 25720 25720 0
__ksymtab_gpl 17096 17136 40
__kcrctab 12860 12860 0
__kcrctab_gpl 8548 8568 20
__ksymtab_stri 96427 96509 82
__init_rodata 0 9800 9800
__param 2320 2320 0
__modver 716 364 -352
.ARM.unwind_idx 160360 160792 432
.ARM.unwind_tab 24312 24312 0
.init.text 234632 195688 -38944
.exit.text 8680 5116 -3564
.init.proc.info 312 312 0
.init.arch.info 2964 2964 0
.init.tagtable 72 72 0
.init.smpalt 776 776 0
.init.pv_table 880 880 0
.init.data 123356 111348 -12008
.exit.data 0 0 0
.data..percpu 12928 12928 0
.data 560160 562688 2528
.notes 36 36 0
.bss 5605324 5605580 256
total 13359171 13371357 12186
after boot 13001183 13054521 53338
That is over 50kb difference after discarding the init sections,
significantly more than the 200 bytes that Greg found.
The point about lack of testing is still valid of course, and I'm
not saying we need to keep the option around, but it's really
not as obvious as before. An argument in favor of removing the
__devinit logic is that these 50kb is still just 0.4% of the
kernel size.
For the five ARM defconfig files that actually turn off hotplug,
the absolute numbers are a bit lower, but the percentage is similar.
This is the amount of space wasted by enabling on CONFIG_HOTPLUG
on them, in bytes after discarding the init sections, and as a
percentage of the vmlinux size:
at91x40_defconfig 3448 0.27%
edb7211_defconfig 8912 0.41%
footbridge_defconfig 33347 0.97%
fortunet_defconfig 4592 0.25%
pleb_defconfig 7405 0.28%
Footbridge is the only config among these that enables PCI and USB, so
it has a bunch more drivers that actually have notable functions that
can be discarded.
Arnd
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Matt Porter @ 2012-10-04 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506D5D8A.7030902@gmail.com>
On Thu, Oct 04, 2012 at 11:57:30AM +0200, Daniel Mack wrote:
> On 04.10.2012 11:38, Porter, Matt wrote:
> >
> > On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:
> >
> >>
> >>
> >> On 02.10.2012 18:50, Daniel Mack wrote:
> >>> On 02.10.2012 18:41, Matt Porter wrote:
> >>>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
> >>>>> On 02.10.2012 13:06, Sekhar Nori wrote:
> >>>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
> >>>>>>> On 02.10.2012 11:37, Mark Brown wrote:
> >>>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
> >>>>>>>>
> >>>>>>>>> I also agree that ifdef is not a good solution.
> >>>>>>>>> It is better to have this information passed as device_data and via DT it can
> >>>>>>>>> be decided based on the compatible property for the device.
> >>>>>>>>
> >>>>>>>> That's not really the problem here - the problem is that the APIs used
> >>>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
> >>>>>>>> or other platforms. The SRAM code needs to move to a standard API.
> >>>>>>>
> >>>>>>> What about following Matt Porter's idea and ignore the SRAM code
> >>>>>>> entirely and port the entire PCM code to generic dmaengine code first?
> >>>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
> >>>>>>> might give that a try in near future.
> >>>>>>>
> >>>>>>> Later on, the SRAM ping-pong code can get added back using genalloc
> >>>>>>> functions, as Sekhar proposed. That needs to be done by someone who has
> >>>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
> >>>>>>
> >>>>>> We cannot "get rid" of SRAM code and add it back "later". It is required
> >>>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
> >>>>>> (conversion should be straightforward and I can help test it) and the
> >>>>>> code that uses SRAM can probably keep using the private EDMA API till
> >>>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
> >>>>>> posted patches to move private EDMA APIs to a common location. That
> >>>>>> should keep AM335x build from breaking. Is this something that is feasible?
> >>>>>
> >>>>> Yes - by "later" I just meant in a subsequent patch. But you're probably
> >>>>> right, we can also do that first.
> >>>>>
> >>>>> I'm looking at that right now and the problem seems that we don't have a
> >>>>> sane way to dynamically look up gen_pools independently of the actual
> >>>>> run-time platform. All users of gen_pools seem to know which platform
> >>>>> they run on and access a platform-specific pool. So I don't currently
> >>>>> see how we could implement multi-platform code, gen_pools are fine but
> >>>>> don't solve the problem here.
> >>>>>
> >>>>> Would it be an idea to add a char* member to gen_pools and a function
> >>>>> that can be used to dynamically look it up again? If a buffer with a
> >>>>> certain name exists, we can use it and install that ping-pong buffer,
> >>>>> otherwise we just don't. While that would be easy to do, it's a
> >>>>> tree-wide change.
> >>>>>
> >>>>> Is there a better way that I miss?
> >>>>
> >>>> At the high level there's two platform models we have to handle, the
> >>>> boot from board file !DT case, and then the boot from DT case. Since
> >>>> Davinci is just starting DT conversion, we mostly care about the !DT
> >>>> base in which the struct gen_pool * is passed in pdata to the ASoC
> >>>> driver. It is then selectable on a per-platform basis where the decision
> >>>> should be made.
> >>>>
> >>>> Given a separate discussion with Sekhar, we're only going to have one
> >>>> SRAM pool on any DaVinci part right now...this was only a question on
> >>>> L138 anyway. But regardless, the created gen_pool will be passed via
> >>>> pdata.
> >>>
> >>> I thought about this too, as mmp does it that way.
> >>>
> >>>> Since DT conversion is starting and we need to consider that now,
> >>>> the idea there is to use the DT-based generic sram driver [1] such that
> >>>> when we do boot from DT on Davinci, the genpool is provided via phandle
> >>>> and the pointer extracted with the OF helpers that are part of the
> >>>> series.
> >>>
> >>> A phandle is the cleanest way I think, yes.
> >>>
> >>>> That's pretty much it. I'm reworking the backend support as discussed
> >>>> with Sekhar wrt to my uio_pruss series. I can post a standalone series
> >>>> that just replaces sram_* with genalloc for davinci ASoC.
> >>>
> >>> As you can also test it, it would be easiest if you came up with a patch
> >>> for that, yes. I can have a look at the dma bits laters, once my OMAP
> >>> board finally works with the code as it currently stands. I'm still
> >>> fighting with the mcasp driver right now ...
> >>
> >> I quickly prepared two patches to change that, so that topic is out of
> >> the way. But I did only compile-test them on OMAP - could you check on
> >> your Davinci platform? Note that these apply on top of the patch in
> >> discussion here (which isn't applied to the asoc tree yet).
> >
> > I put a series together yesterday, just ran out of time to post
> > last night after testing. I'm posting that now...it's on top of my
> > uio_pruss/genalloc series and only addresss switching davinci-pcm to
> > genalloc (and actually enabling ping-pon from sram).
>
> Ok, I don't care which version makes it in after all :)
Ok :)
> > I'll take a look a your OMAP patches.
>
> The patches I just sent out are only for Davinci and change the SRAM
> functions to genalloc in the mcasp driver. They work just fine on OMAP
> of course, as the code is disabled in there.
Ok, same thing as I did and just sent out. These are tested on AM180x
and hook up ping-pong buffering so that there's actually one user of
all this ping-pong code. It's been sitting idle for a long time.
I didn't see your patches come by yet but will take a look to see if
we need to combine.
-Matt
^ permalink raw reply
* [PATCH 4/4] mtd: nand: omap2: Add data correction support
From: Philip, Avinash @ 2012-10-04 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121003192044.GB27502@parrot.com>
On Thu, Oct 04, 2012 at 00:50:45, Ivan Djelic wrote:
> On Wed, Oct 03, 2012 at 03:29:49PM +0100, Philip, Avinash wrote:
> > ELM module can be used for error correction of BCH 4 & 8 bit. Also
> > support read & write page in one shot by adding custom read_page &
> > write_page methods. This helps in optimizing code.
> >
> > New structure member "is_elm_used" is added to know the status of
> > whether the ELM module is used for error correction or not.
> >
> > Note:
> > ECC layout of BCH8 uses 14 bytes for 512 byte of data to make compatible
> > with RBL ECC layout, even though the requirement was only 13 byte. This
> > results a common ecc layout across RBL, U-boot & Linux.
> >
>
> See a few comments below,
>
> (...)
> > +static int omap_elm_correct_data(struct mtd_info *mtd, u_char *dat,
> > + u_char *read_ecc, u_char *calc_ecc)
> > +{
> > + struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
> > + mtd);
> > + int eccsteps = info->nand.ecc.steps;
> > + int i , j, stat = 0;
> > + int eccsize, eccflag, size;
> > + struct elm_errorvec err_vec[ERROR_VECTOR_MAX];
> > + u_char *ecc_vec = calc_ecc;
> > + enum bch_ecc type;
> > + bool is_error_reported = false;
> > +
> > + /* initialize elm error vector to zero */
> > + memset(err_vec, 0, sizeof(err_vec));
> > + if (info->nand.ecc.strength == BCH8_MAX_ERROR) {
> > + size = BCH8_SIZE;
> > + eccsize = BCH8_ECC_OOB_BYTES;
> > + type = BCH8_ECC;
> > + } else {
> > + size = BCH4_SIZE;
> > + eccsize = BCH4_SIZE;
> > + type = BCH4_ECC;
> > + }
> > +
> > + for (i = 0; i < eccsteps ; i++) {
> > + eccflag = 0; /* initialize eccflag */
> > +
> > + for (j = 0; (j < eccsize); j++) {
> > + if (read_ecc[j] != 0xFF) {
> > + eccflag = 1; /* data area is flashed */
>
> Just a reminder: this way of checking if a page has been programmed is not robust to bitflips,
> so you may get into trouble with UBIFS on a fairly recent device.
>
> (...)
> > @@ -1039,14 +1180,45 @@ static void omap3_enable_hwecc_bch(struct mtd_info *mtd, int mode)
> >
> > nerrors = info->nand.ecc.strength;
> > dev_width = (chip->options & NAND_BUSWIDTH_16) ? 1 : 0;
> > +#ifdef CONFIG_MTD_NAND_OMAP_BCH
> > + if (info->is_elm_used) {
> > + /*
> > + * Program GPMC to perform correction on (steps * 512) byte
> > + * sector at a time.
> > + */
> > + gpmc_enable_hwecc_bch(info->gpmc_cs, mode, dev_width,
> > + info->nand.ecc.steps, nerrors);
> > + return;
> > + }
> > +#endif
> > /*
> > - * Program GPMC to perform correction on one 512-byte sector at a time.
> > - * Using 4 sectors at a time (i.e. ecc.size = 2048) is also possible and
> > - * gives a slight (5%) performance gain (but requires additional code).
> > + * Program GPMC to perform correction on one 512-byte sector at
> > + * a time.
>
> Why removing the comment about 4-sector perf gain ? :-)
With this patch, support for reading 4 sectors (max 8) is available.
Hence I am removing it.
>
> (...)
> > @@ -1146,35 +1402,62 @@ static int omap3_init_bch(struct mtd_info *mtd, int ecc_opt)
> > goto fail;
> > }
> >
> > - /* initialize GPMC BCH engine */
> > - ret = gpmc_init_hwecc_bch(info->gpmc_cs, 1, max_errors);
> > - if (ret)
> > - goto fail;
> > -
> > - /* software bch library is only used to detect and locate errors */
> > - info->bch = init_bch(13, max_errors, 0x201b /* hw polynomial */);
> > - if (!info->bch)
> > - goto fail;
> > + info->nand.ecc.size = 512;
> > + info->nand.ecc.hwctl = omap3_enable_hwecc_bch;
> > + info->nand.ecc.mode = NAND_ECC_HW;
> > + info->nand.ecc.strength = hw_errors;
> >
> > - info->nand.ecc.size = 512;
> > - info->nand.ecc.hwctl = omap3_enable_hwecc_bch;
> > - info->nand.ecc.correct = omap3_correct_data_bch;
> > - info->nand.ecc.mode = NAND_ECC_HW;
> > + if (info->is_elm_used && (mtd->writesize <= 4096)) {
> > + enum bch_ecc bch_type;
> >
> > - /*
> > - * The number of corrected errors in an ecc block that will trigger
> > - * block scrubbing defaults to the ecc strength (4 or 8).
> > - * Set mtd->bitflip_threshold here to define a custom threshold.
> > - */
> > + if (hw_errors == BCH8_MAX_ERROR) {
> > + bch_type = BCH8_ECC;
> > + info->nand.ecc.bytes = BCH8_SIZE;
> > + } else {
> > + bch_type = BCH4_ECC;
> > + info->nand.ecc.bytes = BCH4_SIZE;
> > + }
> >
> > - if (max_errors == 8) {
> > - info->nand.ecc.strength = 8;
> > - info->nand.ecc.bytes = 13;
> > - info->nand.ecc.calculate = omap3_calculate_ecc_bch8;
> > + info->nand.ecc.correct = omap_elm_correct_data;
> > + info->nand.ecc.calculate = omap3_calculate_ecc_bch;
> > + info->nand.ecc.read_page = omap_read_page_bch;
> > + info->nand.ecc.write_page = omap_write_page_bch;
> > + info->elm_dev = elm_request(bch_type);
> > + if (!info->elm_dev) {
> > + pr_err("Request to elm module failed\n");
> > + goto fail;
> > + }
> > } else {
> > - info->nand.ecc.strength = 4;
> > - info->nand.ecc.bytes = 7;
> > - info->nand.ecc.calculate = omap3_calculate_ecc_bch4;
> > +
> > + /* initialize GPMC BCH engine */
> > + ret = gpmc_init_hwecc_bch(info->gpmc_cs, 1, max_errors);
> > + if (ret)
> > + goto fail;
> > +
> > + /*
> > + * software bch library is only used to detect and
> > + * locateerrors
>
> s/locateerrors/locate errors/
Ok I will correct it.
>
> BTW, did you check that your patch does not break the software BCH case (i.e. no ELM) ?
I had checked in AM335x-evm software BCH without ELM. So this patch set is not breaking
software BCH functionality.
Thanks
Avinash
>
> BR,
> --
> Ivan
>
^ permalink raw reply
* [PATCH 1/2] mtd: sh_flctl: Add DMA capabilty
From: Bastian Hecht @ 2012-10-04 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1210021534570.15778@axis700.grange>
Hey Guennadi,
2012/10/2 Guennadi Liakhovetski <g.liakhovetski@gmx.de>:
> On Tue, 2 Oct 2012, Bastian Hecht wrote:
>
>> The code probes if DMA channels can get allocated and tears them down at
>> removal/failure if needed.
>> If available it uses them to transfer the data part (not ECC). On
>> failure we fall back to PIO mode.
>>
>> Based on Guennadi Liakhovetski's code from the sh_mmcif driver.
>>
>> Signed-off-by: Bastian Hecht <hechtb@gmail.com>
>
> Looks mostly good to me, just a couple of cosmetic remarks below. They are
> not critical, so, I won't be upset, if you fix them later:-) In any case
>
> Reviewed-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Great, will add that to the next version!
>> ---
>> drivers/mtd/nand/sh_flctl.c | 174 +++++++++++++++++++++++++++++++++++++++++-
>> include/linux/mtd/sh_flctl.h | 12 +++
>> 2 files changed, 183 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/sh_flctl.c b/drivers/mtd/nand/sh_flctl.c
>> index 4fbfe96..0fead2a 100644
>> --- a/drivers/mtd/nand/sh_flctl.c
>> +++ b/drivers/mtd/nand/sh_flctl.c
>> @@ -24,10 +24,13 @@
>> #include <linux/module.h>
>> #include <linux/kernel.h>
>> #include <linux/delay.h>
>> +#include <linux/dmaengine.h>
>> +#include <linux/dma-mapping.h>
>> #include <linux/interrupt.h>
>> #include <linux/io.h>
>> #include <linux/platform_device.h>
>> #include <linux/pm_runtime.h>
>> +#include <linux/sh_dma.h>
>> #include <linux/slab.h>
>> #include <linux/string.h>
>>
>> @@ -106,6 +109,84 @@ static void wait_completion(struct sh_flctl *flctl)
>> writeb(0x0, FLTRCR(flctl));
>> }
>>
>> +static void flctl_dma_complete(void *param)
>> +{
>> + struct sh_flctl *flctl = param;
>> +
>> + complete(&flctl->dma_complete);
>
> I think I mentioned in the first review, that it is good to include
> headers everywhere, where they are needed and not rely on pulling them in
> via other headers. So, it would be good to also include complete.h here
> directly.
Ok sure, I will include that as well.
> [snip]
>> @@ -308,13 +462,23 @@ static enum flctl_ecc_res_t read_ecfiforeg
>> static void write_fiforeg(struct sh_flctl *flctl, int rlen, int offset)
>> {
>> int i, len_4align;
>> - unsigned long *data = (unsigned long *)&flctl->done_buff[offset];
>> + unsigned long *buf = (unsigned long *)&flctl->done_buff[offset];
>> void *fifo_addr = (void *)FLDTFIFO(flctl);
>>
>> len_4align = (rlen + 3) / 4;
>> +
>> + for (i = 0; i < len_4align; i++)
>> + buf[i] = cpu_to_be32(buf[i]);
>
> indentation ran away here.
Ah nice, thanks for the hawk's eye ;)
> Thanks
> Guennadi
Thanks!
Bastian
^ permalink raw reply
* [PATCH 2/2] mtd: sh_flctl: Add device tree support
From: Bastian Hecht @ 2012-10-04 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210022047.50064.arnd.bergmann@linaro.org>
Hi Arnd, hi Guennadi,
2012/10/2 Arnd Bergmann <arnd.bergmann@linaro.org>:
> On Tuesday 02 October 2012, Guennadi Liakhovetski wrote:
>> >
>> > Since you are also adding dma-engine support, I would suggest you specify
>> > a "dmas" and "dma-names" property as well, so the device can find the
>> > right dma channel. The code might not do that yet while you're still
>> > sorting out the dependencies (and the sh dmaengine code is not yet
>> > converted to DT), but I think it would be good to nail down the binding
>> > for this device.
Ok good, so I will include these field in v2. The FLCTL has support
for 4 channels, 2 for data read/write and 2 for ECC read/write.
The driver currently supports only the data part. Should I include the
ECC part nevertheless?
Further would you prefer the naming
- fifo0_rx fifo0_tx fifo1_rx fifo1_tx (close to the datasheet) or
- data_rx data_tx ecc_rx ecc_tx
Then the dmas field:
If I get it right, we have 3 possible DMA controllers to use on the
sh7372 and we specify the mid/rid value as second argument?
So how about this to add to the docs:
dmas = <&dma1 0x83 /* fifo0_rx */
&dma1 0x83 /* fifo0_tx */
&dma2 0x83 /* fifo0_rx */
&dma2 0x83 /* fifo0_tx */
&dma3 0x83 /* fifo0_rx */
&dma3 0x83>; /* fifo0_tx */
dma-names = "fifo0_rx", "fifo0_tx", fifo0_rx", "fifo0_tx", fifo0_rx",
"fifo0_tx";
Many thanks for the help,
Bastian
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Daniel Mack @ 2012-10-04 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E4D2ACDC-4749-4988-ADC5-277C187B0DC6@ti.com>
On 04.10.2012 11:38, Porter, Matt wrote:
>
> On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:
>
>>
>>
>> On 02.10.2012 18:50, Daniel Mack wrote:
>>> On 02.10.2012 18:41, Matt Porter wrote:
>>>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>>>>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>>>>>>> On 02.10.2012 11:37, Mark Brown wrote:
>>>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>>>>>>
>>>>>>>>> I also agree that ifdef is not a good solution.
>>>>>>>>> It is better to have this information passed as device_data and via DT it can
>>>>>>>>> be decided based on the compatible property for the device.
>>>>>>>>
>>>>>>>> That's not really the problem here - the problem is that the APIs used
>>>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>>>>>>> or other platforms. The SRAM code needs to move to a standard API.
>>>>>>>
>>>>>>> What about following Matt Porter's idea and ignore the SRAM code
>>>>>>> entirely and port the entire PCM code to generic dmaengine code first?
>>>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>>>>>>> might give that a try in near future.
>>>>>>>
>>>>>>> Later on, the SRAM ping-pong code can get added back using genalloc
>>>>>>> functions, as Sekhar proposed. That needs to be done by someone who has
>>>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
>>>>>>
>>>>>> We cannot "get rid" of SRAM code and add it back "later". It is required
>>>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
>>>>>> (conversion should be straightforward and I can help test it) and the
>>>>>> code that uses SRAM can probably keep using the private EDMA API till
>>>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
>>>>>> posted patches to move private EDMA APIs to a common location. That
>>>>>> should keep AM335x build from breaking. Is this something that is feasible?
>>>>>
>>>>> Yes - by "later" I just meant in a subsequent patch. But you're probably
>>>>> right, we can also do that first.
>>>>>
>>>>> I'm looking at that right now and the problem seems that we don't have a
>>>>> sane way to dynamically look up gen_pools independently of the actual
>>>>> run-time platform. All users of gen_pools seem to know which platform
>>>>> they run on and access a platform-specific pool. So I don't currently
>>>>> see how we could implement multi-platform code, gen_pools are fine but
>>>>> don't solve the problem here.
>>>>>
>>>>> Would it be an idea to add a char* member to gen_pools and a function
>>>>> that can be used to dynamically look it up again? If a buffer with a
>>>>> certain name exists, we can use it and install that ping-pong buffer,
>>>>> otherwise we just don't. While that would be easy to do, it's a
>>>>> tree-wide change.
>>>>>
>>>>> Is there a better way that I miss?
>>>>
>>>> At the high level there's two platform models we have to handle, the
>>>> boot from board file !DT case, and then the boot from DT case. Since
>>>> Davinci is just starting DT conversion, we mostly care about the !DT
>>>> base in which the struct gen_pool * is passed in pdata to the ASoC
>>>> driver. It is then selectable on a per-platform basis where the decision
>>>> should be made.
>>>>
>>>> Given a separate discussion with Sekhar, we're only going to have one
>>>> SRAM pool on any DaVinci part right now...this was only a question on
>>>> L138 anyway. But regardless, the created gen_pool will be passed via
>>>> pdata.
>>>
>>> I thought about this too, as mmp does it that way.
>>>
>>>> Since DT conversion is starting and we need to consider that now,
>>>> the idea there is to use the DT-based generic sram driver [1] such that
>>>> when we do boot from DT on Davinci, the genpool is provided via phandle
>>>> and the pointer extracted with the OF helpers that are part of the
>>>> series.
>>>
>>> A phandle is the cleanest way I think, yes.
>>>
>>>> That's pretty much it. I'm reworking the backend support as discussed
>>>> with Sekhar wrt to my uio_pruss series. I can post a standalone series
>>>> that just replaces sram_* with genalloc for davinci ASoC.
>>>
>>> As you can also test it, it would be easiest if you came up with a patch
>>> for that, yes. I can have a look at the dma bits laters, once my OMAP
>>> board finally works with the code as it currently stands. I'm still
>>> fighting with the mcasp driver right now ...
>>
>> I quickly prepared two patches to change that, so that topic is out of
>> the way. But I did only compile-test them on OMAP - could you check on
>> your Davinci platform? Note that these apply on top of the patch in
>> discussion here (which isn't applied to the asoc tree yet).
>
> I put a series together yesterday, just ran out of time to post
> last night after testing. I'm posting that now...it's on top of my
> uio_pruss/genalloc series and only addresss switching davinci-pcm to
> genalloc (and actually enabling ping-pon from sram).
Ok, I don't care which version makes it in after all :)
> I'll take a look a your OMAP patches.
The patches I just sent out are only for Davinci and change the SRAM
functions to genalloc in the mcasp driver. They work just fine on OMAP
of course, as the code is disabled in there.
Daniel
^ permalink raw reply
* [PATCH] clk: SPEAr: Vco-pll: Fix compilation warning
From: Viresh Kumar @ 2012-10-04 9:49 UTC (permalink / raw)
To: linux-arm-kernel
Currently we are getting following warning for SPEAr clk-vco-pll.
"warning: i is used uninitialized in this function."
This is because we are getting value of i by passing its pointer to another
routine.
The variables here are really not used uninitialized.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Andrew,
I know this must have gone through Mike Turquette. But he is not around for a
week. As, this is a pretty small change, can you take it upstream?
drivers/clk/spear/clk-vco-pll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/spear/clk-vco-pll.c b/drivers/clk/spear/clk-vco-pll.c
index 5f1b6ba..1b9b65b 100644
--- a/drivers/clk/spear/clk-vco-pll.c
+++ b/drivers/clk/spear/clk-vco-pll.c
@@ -147,7 +147,7 @@ static int clk_pll_set_rate(struct clk_hw *hw, unsigned long drate,
struct clk_pll *pll = to_clk_pll(hw);
struct pll_rate_tbl *rtbl = pll->vco->rtbl;
unsigned long flags = 0, val;
- int i;
+ int uninitialized_var(i);
clk_pll_round_rate_index(hw, drate, NULL, &i);
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [RFC PATCH 1/2] ARM: use generic strnlen_user and strncpy_from_user functions
From: Uwe Kleine-König @ 2012-10-04 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121003091636.GC22445@mudshark.cambridge.arm.com>
On Wed, Oct 03, 2012 at 10:16:36AM +0100, Will Deacon wrote:
> On Wed, Oct 03, 2012 at 07:00:42AM +0100, Uwe Kleine-K?nig wrote:
> > On Tue, Oct 02, 2012 at 08:18:51PM +0100, Will Deacon wrote:
> > > Ok, thanks for the heads-up. I didn't test it with an M-class CPU, but
> > > hopefully that's understandable :)
> >
> > I think so, yes. But I intend to change that, and I heard your coworker
> > gets an efm32 :-)
>
> Yep, he'll be in charge of testing for us (!)
:-)
> > > > > +#define user_addr_max() \
> > > > > + (segment_eq(get_fs(), USER_DS) ? TASK_SIZE : ~0UL)
> > > > > +
> > > > I think this is the problem as for no-mmu USER_DS == KERNEL_DS. I will
> > > > take a look tomorrow.
> > >
> > > I can't immediately see why that would cause a problem, so please let me
> > > know if you get more information.
> > BTW, I once saw the call to sys_mount fail:
> >
> > sys_mount ->
> > copy_mount_string ->
> > strndup_user ->
> > strnlen_user returns 0 which makes sys_mount fail with -EFAULT.
> >
> > but that was not the problem I hit when I bisected (using merges instead
> > of rebasing).
>
> Was this also on your M3?
Yeah. I found a change that fixes it for me:
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 77bd79f..7775e03 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -216,7 +216,7 @@ static inline void set_fs(mm_segment_t fs)
#define access_ok(type,addr,size) (__range_ok(addr,size) == 0)
#define user_addr_max() \
- (segment_eq(get_fs(), USER_DS) ? TASK_SIZE : ~0UL)
+ (segment_eq(get_fs(), KERNEL_DL) ? ~0UL : TASK_SIZE)
/*
* The "__xxx" versions of the user access functions do not verify the
I'm not sure if this has some security implications for the !MMU case!?
(But if so according to my understanding (which might well be wrong)
using TASK_SIZE isn't correct also. So this only widens the window, but
doesn't create it.)
On !MMU TASK_SIZE is CONFIG_DRAM_SIZE, but I'm using XIP and the flash
is at an higher address than RAM. So maybe XIP is broken on MMU
machines, too?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply related
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Porter, Matt @ 2012-10-04 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506D552A.2000506@gmail.com>
On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:
>
>
> On 02.10.2012 18:50, Daniel Mack wrote:
>> On 02.10.2012 18:41, Matt Porter wrote:
>>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>>>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>>>>>> On 02.10.2012 11:37, Mark Brown wrote:
>>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>>>>>
>>>>>>>> I also agree that ifdef is not a good solution.
>>>>>>>> It is better to have this information passed as device_data and via DT it can
>>>>>>>> be decided based on the compatible property for the device.
>>>>>>>
>>>>>>> That's not really the problem here - the problem is that the APIs used
>>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>>>>>> or other platforms. The SRAM code needs to move to a standard API.
>>>>>>
>>>>>> What about following Matt Porter's idea and ignore the SRAM code
>>>>>> entirely and port the entire PCM code to generic dmaengine code first?
>>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>>>>>> might give that a try in near future.
>>>>>>
>>>>>> Later on, the SRAM ping-pong code can get added back using genalloc
>>>>>> functions, as Sekhar proposed. That needs to be done by someone who has
>>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
>>>>>
>>>>> We cannot "get rid" of SRAM code and add it back "later". It is required
>>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
>>>>> (conversion should be straightforward and I can help test it) and the
>>>>> code that uses SRAM can probably keep using the private EDMA API till
>>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
>>>>> posted patches to move private EDMA APIs to a common location. That
>>>>> should keep AM335x build from breaking. Is this something that is feasible?
>>>>
>>>> Yes - by "later" I just meant in a subsequent patch. But you're probably
>>>> right, we can also do that first.
>>>>
>>>> I'm looking at that right now and the problem seems that we don't have a
>>>> sane way to dynamically look up gen_pools independently of the actual
>>>> run-time platform. All users of gen_pools seem to know which platform
>>>> they run on and access a platform-specific pool. So I don't currently
>>>> see how we could implement multi-platform code, gen_pools are fine but
>>>> don't solve the problem here.
>>>>
>>>> Would it be an idea to add a char* member to gen_pools and a function
>>>> that can be used to dynamically look it up again? If a buffer with a
>>>> certain name exists, we can use it and install that ping-pong buffer,
>>>> otherwise we just don't. While that would be easy to do, it's a
>>>> tree-wide change.
>>>>
>>>> Is there a better way that I miss?
>>>
>>> At the high level there's two platform models we have to handle, the
>>> boot from board file !DT case, and then the boot from DT case. Since
>>> Davinci is just starting DT conversion, we mostly care about the !DT
>>> base in which the struct gen_pool * is passed in pdata to the ASoC
>>> driver. It is then selectable on a per-platform basis where the decision
>>> should be made.
>>>
>>> Given a separate discussion with Sekhar, we're only going to have one
>>> SRAM pool on any DaVinci part right now...this was only a question on
>>> L138 anyway. But regardless, the created gen_pool will be passed via
>>> pdata.
>>
>> I thought about this too, as mmp does it that way.
>>
>>> Since DT conversion is starting and we need to consider that now,
>>> the idea there is to use the DT-based generic sram driver [1] such that
>>> when we do boot from DT on Davinci, the genpool is provided via phandle
>>> and the pointer extracted with the OF helpers that are part of the
>>> series.
>>
>> A phandle is the cleanest way I think, yes.
>>
>>> That's pretty much it. I'm reworking the backend support as discussed
>>> with Sekhar wrt to my uio_pruss series. I can post a standalone series
>>> that just replaces sram_* with genalloc for davinci ASoC.
>>
>> As you can also test it, it would be easiest if you came up with a patch
>> for that, yes. I can have a look at the dma bits laters, once my OMAP
>> board finally works with the code as it currently stands. I'm still
>> fighting with the mcasp driver right now ...
>
> I quickly prepared two patches to change that, so that topic is out of
> the way. But I did only compile-test them on OMAP - could you check on
> your Davinci platform? Note that these apply on top of the patch in
> discussion here (which isn't applied to the asoc tree yet).
I put a series together yesterday, just ran out of time to post
last night after testing. I'm posting that now...it's on top of my
uio_pruss/genalloc series and only addresss switching davinci-pcm to
genalloc (and actually enabling ping-pon from sram).
I'll take a look a your OMAP patches.
-Matt
^ permalink raw reply
* [GIT PULL] remoteproc for 3.7
From: Ohad Ben-Cohen @ 2012-10-04 9:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull remoteproc 3.7 material, thanks.
PS - I recently found an annoying typo in the subject of one of the
patches, but I decided to accept it over doing a rebase.
The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:
Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-for-3.7
for you to fetch changes up to d09f53a735bae43806a77754312a45d3f1198342:
remoteproc: Fix use of format specifyer (2012-10-02 10:14:43 +0200)
----------------------------------------------------------------
- Remoteproc Recovery - by Fernando Guzman Lugo - when a remote processor
crash is detected, this mechanism will remove all virtio children
devices, wait until their drivers let go, hard reset the remote
processor and reload the firmware (resulting in the relevant virtio
children devices re-added). Essentially the entire software stack
is reset, together with the relevant hardware, so users don't have
to reset the entire phone.
- STE Modem driver is added - by Sjur Br?ndeland
- OMAP DSP boot address support is added - by Juan Gutierrez
- A handful of fixes/cleanups - Sjur Br?ndeland, Dan Carpenter, Emil Goode
----------------------------------------------------------------
Dan Carpenter (3):
remoteproc: snprintf() can return more than was printed
remoteproc: return -EFAULT on copy_from_user failure
remoteproc: fix a potential NULL-dereference on cleanup
Emil Goode (1):
remoteproc: Fix use of format specifyer
Fernando Guzman Lugo (3):
remoteproc: add rproc_report_crash function to notify rproc crashes
remoteproc: add actual recovery implementation
remoteproc: create a 'recovery' debugfs entry
Juan Gutierrez (1):
remoteproc/omap: set bootaddr support
Ohad Ben-Cohen (1):
remoteproc: select VIRTIO to avoid build breakage
Sjur Br?ndeland (3):
remoteproc: Add dependency to HAS_DMA
remtoteproc: maintain max notifyid
remoteproc: Add STE modem driver
Documentation/remoteproc.txt | 7 +
arch/arm/plat-omap/include/plat/remoteproc.h | 2 +
drivers/remoteproc/Kconfig | 14 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/omap_remoteproc.c | 3 +
drivers/remoteproc/remoteproc_core.c | 209 +++++++++++++----
drivers/remoteproc/remoteproc_debugfs.c | 85 ++++++-
drivers/remoteproc/remoteproc_internal.h | 1 +
drivers/remoteproc/ste_modem_rproc.c | 322 +++++++++++++++++++++++++++
include/linux/remoteproc.h | 24 ++
include/linux/ste_modem_shm.h | 56 +++++
11 files changed, 682 insertions(+), 42 deletions(-)
create mode 100644 drivers/remoteproc/ste_modem_rproc.c
create mode 100644 include/linux/ste_modem_shm.h
^ permalink raw reply
* [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms
From: Daniel Mack @ 2012-10-04 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506B1B46.2070006@gmail.com>
On 02.10.2012 18:50, Daniel Mack wrote:
> On 02.10.2012 18:41, Matt Porter wrote:
>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>>>>> On 02.10.2012 11:37, Mark Brown wrote:
>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>>>>
>>>>>>> I also agree that ifdef is not a good solution.
>>>>>>> It is better to have this information passed as device_data and via DT it can
>>>>>>> be decided based on the compatible property for the device.
>>>>>>
>>>>>> That's not really the problem here - the problem is that the APIs used
>>>>>> to get the SRAM are DaVinci only so it's not possible to build on OMAP
>>>>>> or other platforms. The SRAM code needs to move to a standard API.
>>>>>
>>>>> What about following Matt Porter's idea and ignore the SRAM code
>>>>> entirely and port the entire PCM code to generic dmaengine code first?
>>>>> The EDMA driver needs to learn support for cyclic DMA for that, and I
>>>>> might give that a try in near future.
>>>>>
>>>>> Later on, the SRAM ping-pong code can get added back using genalloc
>>>>> functions, as Sekhar proposed. That needs to be done by someone who has
>>>>> access to a Davinci board though, I only have a AM33xx/OMAP here.
>>>>
>>>> We cannot "get rid" of SRAM code and add it back "later". It is required
>>>> for most DaVinci parts. The SRAM code can be converted to use genalloc
>>>> (conversion should be straightforward and I can help test it) and the
>>>> code that uses SRAM can probably keep using the private EDMA API till
>>>> the dmaengine EDMA driver has cyclic DMA support. Matt has already
>>>> posted patches to move private EDMA APIs to a common location. That
>>>> should keep AM335x build from breaking. Is this something that is feasible?
>>>
>>> Yes - by "later" I just meant in a subsequent patch. But you're probably
>>> right, we can also do that first.
>>>
>>> I'm looking at that right now and the problem seems that we don't have a
>>> sane way to dynamically look up gen_pools independently of the actual
>>> run-time platform. All users of gen_pools seem to know which platform
>>> they run on and access a platform-specific pool. So I don't currently
>>> see how we could implement multi-platform code, gen_pools are fine but
>>> don't solve the problem here.
>>>
>>> Would it be an idea to add a char* member to gen_pools and a function
>>> that can be used to dynamically look it up again? If a buffer with a
>>> certain name exists, we can use it and install that ping-pong buffer,
>>> otherwise we just don't. While that would be easy to do, it's a
>>> tree-wide change.
>>>
>>> Is there a better way that I miss?
>>
>> At the high level there's two platform models we have to handle, the
>> boot from board file !DT case, and then the boot from DT case. Since
>> Davinci is just starting DT conversion, we mostly care about the !DT
>> base in which the struct gen_pool * is passed in pdata to the ASoC
>> driver. It is then selectable on a per-platform basis where the decision
>> should be made.
>>
>> Given a separate discussion with Sekhar, we're only going to have one
>> SRAM pool on any DaVinci part right now...this was only a question on
>> L138 anyway. But regardless, the created gen_pool will be passed via
>> pdata.
>
> I thought about this too, as mmp does it that way.
>
>> Since DT conversion is starting and we need to consider that now,
>> the idea there is to use the DT-based generic sram driver [1] such that
>> when we do boot from DT on Davinci, the genpool is provided via phandle
>> and the pointer extracted with the OF helpers that are part of the
>> series.
>
> A phandle is the cleanest way I think, yes.
>
>> That's pretty much it. I'm reworking the backend support as discussed
>> with Sekhar wrt to my uio_pruss series. I can post a standalone series
>> that just replaces sram_* with genalloc for davinci ASoC.
>
> As you can also test it, it would be easiest if you came up with a patch
> for that, yes. I can have a look at the dma bits laters, once my OMAP
> board finally works with the code as it currently stands. I'm still
> fighting with the mcasp driver right now ...
I quickly prepared two patches to change that, so that topic is out of
the way. But I did only compile-test them on OMAP - could you check on
your Davinci platform? Note that these apply on top of the patch in
discussion here (which isn't applied to the asoc tree yet).
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-davinci-pass-SRAM-gen_pool-to-mcasp-platform-dat.patch
Type: text/x-patch
Size: 8048 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121004/c5c4e92c/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-ALSA-ASoC-McASP-use-gen_pool-from-platform-data.patch
Type: text/x-patch
Size: 4201 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121004/c5c4e92c/attachment-0003.bin>
^ permalink raw reply
* [PATCH] ARM: Push selects for TWD/SCU into machine entries
From: Santosh Shilimkar @ 2012-10-04 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349340644-13937-1-git-send-email-sboyd@codeaurora.org>
On Thursday 04 October 2012 02:20 PM, Stephen Boyd wrote:
> The TWD and SCU configs are selected by default as long as
> SCORPIONMP is false and/or MCT is false. Implementing the logic
> this way certainly saves lines in the Kconfig but it precludes
> those machines which select SCORPIONMP or MCT from participating
> in the single zImage effort because when those machines are
> combined with other SMP capable machines the TWD and SCU are no
> longer selected.
>
> Push the select out to the machine entries so that we can compile
> these machines together and still select the appropriate configs.
>
> Signed-off-by: Stephen Boyd<sboyd@codeaurora.org>
> Cc: David Brown<davidb@codeaurora.org>
> Cc: Kukjin Kim<kgene.kim@samsung.com>
> Cc: Linus Walleij<linus.walleij@linaro.org>
> Cc: Pawel Moll<pawel.moll@arm.com>
> Cc: Rob Herring<rob.herring@calxeda.com>
> Cc: Russell King<linux@arm.linux.org.uk>
> Cc: Sascha Hauer<kernel@pengutronix.de>
> Cc: Shiraz Hashim<shiraz.hashim@st.com>
> Cc: Simon Horman<horms@verge.net.au>
> Cc: Srinidhi Kasagar<srinidhi.kasagar@stericsson.com>
> Cc: Stephen Warren<swarren@wwwdotorg.org>
> Cc: Tony Lindgren<tony@atomide.com>
> Cc: Viresh Kumar<viresh.linux@gmail.com>
> ---
>
> Does OMAP5 need to select TWD? I suspect not if it uses the
> architected timers.
>
Nope. OMAP5 don't use TWD. Infact the external SCU is also used
for A9 SOCs. You might want to check other A15 SOCS for SCU as
well.
[..]
> arch/arm/mach-omap2/Kconfig | 4 ++++
[..]
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index a6219ea..b618748 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -58,7 +58,9 @@ config ARCH_OMAP4
> select CPU_V7
> select ARM_GIC
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> select LOCAL_TIMERS if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select PL310_ERRATA_588369
> select PL310_ERRATA_727915
> select ARM_ERRATA_720789
Ok.
> @@ -75,6 +77,8 @@ config SOC_OMAP5
> select CPU_V7
> select ARM_GIC
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select ARM_CPU_SUSPEND if PM
> select SOC_HAS_REALTIME_COUNTER
> select ARM_ARCH_TIMER
Drop this change.
With that fixed, for OMAP changes
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* [PATCH v3 0/6] uio_pruss cleanup and platform support
From: Philipp Zabel @ 2012-10-04 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349276133-26408-1-git-send-email-mporter@ti.com>
Hi Matt,
On 10/3/12, Matt Porter <mporter@ti.com> wrote:
> This series enables uio_pruss on DA850 and removes use of the
> private SRAM API by the driver. The driver previously was not
> enabled by any platform and the private SRAM API was accessing
> an invalid SRAM bank.
have you seen my SRAM patch series at https://lkml.org/lkml/2012/9/7/281
"Add device tree support for on-chip SRAM" ?
I think the generic SRAM/genalloc driver (https://lkml.org/lkml/2012/9/7/282)
could be useful to map the L3RAM on Davinci.
With the gen_pool lookup patch (https://lkml.org/lkml/2012/9/7/284) the
uio_pruss driver could then use the gen_pool_find_by_phys() (or
of_get_named_gen_pool() for initialization from device tree) to
retrieve the struct gen_pool*.
This way you could avoid handing it over via platform data and you could
get rid of arch/arm/mach-davinci/{sram.c,include/mach/sram.h} completely.
regards
Philipp
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH V2 3/3] spi: spi-pl022: Minor simplification for runtime pm
From: Ulf Hansson @ 2012-10-04 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349337881-15917-4-git-send-email-ulf.hansson@stericsson.com>
Hi,
Mark, I am not sure this particular patch is actually wanted. Realized
that when reading up on the driver/base/* patches for PM changes this
summer. Especially how device probe/suspend/shutdown etc. has been
changed for runtime PM point of view.
Maybe you can comment?
Kind regards
Ulf Hansson
On 4 October 2012 10:04, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> In probe pm_runtime_put_autosuspend has the same effect as doing
> pm_runtime_put. This due to upper layer in driver core is preventing
> the device from being runtime suspended by a pm_runtime_get*.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/spi/spi-pl022.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
> index a1db91a..51b7a95 100644
> --- a/drivers/spi/spi-pl022.c
> +++ b/drivers/spi/spi-pl022.c
> @@ -2246,10 +2246,9 @@ pl022_probe(struct amba_device *adev, const struct amba_id *id)
> pm_runtime_set_autosuspend_delay(dev,
> platform_info->autosuspend_delay);
> pm_runtime_use_autosuspend(dev);
> - pm_runtime_put_autosuspend(dev);
> - } else {
> - pm_runtime_put(dev);
> }
> + pm_runtime_put(dev);
> +
> return 0;
>
> err_spi_register:
> --
> 1.7.10
>
^ permalink raw reply
* [PATCH] ARM: Push selects for TWD/SCU into machine entries
From: viresh kumar @ 2012-10-04 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349340644-13937-1-git-send-email-sboyd@codeaurora.org>
On Thu, Oct 4, 2012 at 2:20 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> arch/arm/plat-spear/Kconfig | 2 ++
> diff --git a/arch/arm/plat-spear/Kconfig b/arch/arm/plat-spear/Kconfig
> index 4404f82..a090ea3 100644
> --- a/arch/arm/plat-spear/Kconfig
> +++ b/arch/arm/plat-spear/Kconfig
> @@ -14,6 +14,8 @@ config ARCH_SPEAR13XX
> select CPU_V7
> select USE_OF
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select MIGHT_HAVE_CACHE_L2X0
> select PINCTRL
> help
For SPEAr:
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH] ARM: Push selects for TWD/SCU into machine entries
From: Stephen Boyd @ 2012-10-04 8:50 UTC (permalink / raw)
To: linux-arm-kernel
The TWD and SCU configs are selected by default as long as
SCORPIONMP is false and/or MCT is false. Implementing the logic
this way certainly saves lines in the Kconfig but it precludes
those machines which select SCORPIONMP or MCT from participating
in the single zImage effort because when those machines are
combined with other SMP capable machines the TWD and SCU are no
longer selected.
Push the select out to the machine entries so that we can compile
these machines together and still select the appropriate configs.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Cc: David Brown <davidb@codeaurora.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Shiraz Hashim <shiraz.hashim@st.com>
Cc: Simon Horman <horms@verge.net.au>
Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Viresh Kumar <viresh.linux@gmail.com>
---
Does OMAP5 need to select TWD? I suspect not if it uses the
architected timers.
arch/arm/Kconfig | 8 ++++++--
arch/arm/mach-exynos/Kconfig | 2 ++
arch/arm/mach-highbank/Kconfig | 1 +
arch/arm/mach-imx/Kconfig | 2 ++
arch/arm/mach-msm/Kconfig | 7 ++-----
arch/arm/mach-omap2/Kconfig | 4 ++++
arch/arm/mach-realview/Kconfig | 8 ++++++++
arch/arm/mach-vexpress/Kconfig | 2 ++
arch/arm/plat-spear/Kconfig | 2 ++
9 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e85f2b6..303ce90 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -639,6 +639,8 @@ config ARCH_TEGRA
select GENERIC_GPIO
select HAVE_CLK
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select MIGHT_HAVE_CACHE_L2X0
select ARCH_HAS_CPUFREQ
select USE_OF
@@ -686,6 +688,8 @@ config ARCH_SHMOBILE
select CLKDEV_LOOKUP
select HAVE_MACH_CLKDEV
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select GENERIC_CLOCKEVENTS
select MIGHT_HAVE_CACHE_L2X0
select NO_IOPORT
@@ -882,6 +886,8 @@ config ARCH_U8500
select ARCH_REQUIRE_GPIOLIB
select ARCH_HAS_CPUFREQ
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select MIGHT_HAVE_CACHE_L2X0
help
Support for ST-Ericsson's Ux500 architecture
@@ -1507,7 +1513,6 @@ config SMP
depends on HAVE_SMP
depends on MMU
select USE_GENERIC_SMP_HELPERS
- select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
help
This enables support for systems with more than one CPU. If you have
a system with only one CPU, like most personal computers, say N. If
@@ -1620,7 +1625,6 @@ config LOCAL_TIMERS
bool "Use local timer interrupts"
depends on SMP
default y
- select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
help
Enable support for local timers on SMP platforms, rather then the
legacy IPI broadcast method. Local timers allows the system
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 4372075..8f97e92 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -15,6 +15,7 @@ config ARCH_EXYNOS4
bool "SAMSUNG EXYNOS4"
default y
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
select MIGHT_HAVE_CACHE_L2X0
help
Samsung EXYNOS4 SoCs based systems
@@ -22,6 +23,7 @@ config ARCH_EXYNOS4
config ARCH_EXYNOS5
bool "SAMSUNG EXYNOS5"
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
help
Samsung EXYNOS5 (Cortex-A15) SoC based systems
diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index 0e1d0a4..f1ad1f0 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -11,5 +11,6 @@ config ARCH_HIGHBANK
select GENERIC_CLOCKEVENTS
select HAVE_ARM_SCU
select HAVE_SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select SPARSE_IRQ
select USE_OF
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 519ed57..13f765c 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -759,6 +759,8 @@ config SOC_IMX6Q
select HAVE_IMX_MMDC
select HAVE_IMX_SRC
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select MFD_SYSCON
select PINCTRL
select PINCTRL_IMX6Q
diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
index 7902de15..5bff882 100644
--- a/arch/arm/mach-msm/Kconfig
+++ b/arch/arm/mach-msm/Kconfig
@@ -44,7 +44,7 @@ endchoice
config ARCH_MSM8X60
bool "MSM8X60"
- select ARCH_MSM_SCORPIONMP
+ select HAVE_SMP
select ARM_GIC
select CPU_V7
select MSM_V2_TLMM
@@ -55,7 +55,7 @@ config ARCH_MSM8X60
config ARCH_MSM8960
bool "MSM8960"
- select ARCH_MSM_SCORPIONMP
+ select HAVE_SMP
select ARM_GIC
select CPU_V7
select MSM_V2_TLMM
@@ -68,9 +68,6 @@ config MSM_HAS_DEBUG_UART_HS
config MSM_SOC_REV_A
bool
-config ARCH_MSM_SCORPIONMP
- bool
- select HAVE_SMP
config ARCH_MSM_ARM11
bool
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a6219ea..b618748 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -58,7 +58,9 @@ config ARCH_OMAP4
select CPU_V7
select ARM_GIC
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
select LOCAL_TIMERS if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select PL310_ERRATA_588369
select PL310_ERRATA_727915
select ARM_ERRATA_720789
@@ -75,6 +77,8 @@ config SOC_OMAP5
select CPU_V7
select ARM_GIC
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select ARM_CPU_SUSPEND if PM
select SOC_HAS_REALTIME_COUNTER
select ARM_ARCH_TIMER
diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
index c593be4..0c019b7 100644
--- a/arch/arm/mach-realview/Kconfig
+++ b/arch/arm/mach-realview/Kconfig
@@ -13,6 +13,8 @@ config REALVIEW_EB_A9MP
depends on MACH_REALVIEW_EB
select CPU_V7
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select MIGHT_HAVE_CACHE_L2X0
help
Enable support for the Cortex-A9MPCore tile fitted to the
@@ -24,6 +26,8 @@ config REALVIEW_EB_ARM11MP
select CPU_V6K
select ARCH_HAS_BARRIERS if SMP
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select MIGHT_HAVE_CACHE_L2X0
help
Enable support for the ARM11MPCore tile fitted to the Realview(R)
@@ -44,6 +48,8 @@ config MACH_REALVIEW_PB11MP
select ARM_GIC
select HAVE_PATA_PLATFORM
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select MIGHT_HAVE_CACHE_L2X0
select ARCH_HAS_BARRIERS if SMP
help
@@ -86,6 +92,8 @@ config MACH_REALVIEW_PBX
select ARM_GIC
select HAVE_PATA_PLATFORM
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select MIGHT_HAVE_CACHE_L2X0
select ARCH_SPARSEMEM_ENABLE if CPU_V7 && !REALVIEW_HIGH_PHYS_OFFSET
select ZONE_DMA if SPARSEMEM
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index c952960..4f8e0db 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -11,6 +11,8 @@ config ARCH_VEXPRESS
select HAVE_CLK
select HAVE_PATA_PLATFORM
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select ICST
select MIGHT_HAVE_CACHE_L2X0
select NO_IOPORT
diff --git a/arch/arm/plat-spear/Kconfig b/arch/arm/plat-spear/Kconfig
index 4404f82..a090ea3 100644
--- a/arch/arm/plat-spear/Kconfig
+++ b/arch/arm/plat-spear/Kconfig
@@ -14,6 +14,8 @@ config ARCH_SPEAR13XX
select CPU_V7
select USE_OF
select HAVE_SMP
+ select HAVE_ARM_SCU if SMP
+ select HAVE_ARM_TWD if LOCAL_TIMERS
select MIGHT_HAVE_CACHE_L2X0
select PINCTRL
help
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform data
From: Inki Dae @ 2012-10-04 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8952601.531301349336373038.JavaMail.weblogic@epml07>
Hello Media guys,
This is dependent of exynos drm patch set to be merged to mainline so if
there is no problem then please, give me ack so that I can merge this patch
with exynos drm patch set.
Thanks,
Inki Dae
> -----Original Message-----
> From: RAHUL SHARMA [mailto:rahul.sharma at samsung.com]
> Sent: Thursday, October 04, 2012 4:40 PM
> To: Tomasz Stanislawski; Kyungmin Park; linux-arm-
> kernel at lists.infradead.org; linux-media at vger.kernel.org
> Cc: In-Ki Dae; SUNIL JOSHI; r.sh.open at gmail.com
> Subject: Re: [PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform
> data
>
> Hi Mr. Tomasz, Mr. Park, list,
>
> First patch in the following set belongs to s5p-media, rest to exynos-drm.
> Please review the media patch so that It can be merged for mainline.
>
> regards,
> Rahul Sharma
>
> On Thu, Oct 4, 2012 at 9:12 PM, Rahul Sharma <rahul.sharma@samsung.com>
> wrote:
> > From: Tomasz Stanislawski <t.stanislaws@samsung.com>
> >
> > This patch extends s5p-hdmi platform data by a GPIO identifier for
> > Hot-Plug-Detection pin.
> >
> > Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> > ---
> > include/media/s5p_hdmi.h | 2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
> > index 361a751..181642b 100644
> > --- a/include/media/s5p_hdmi.h
> > +++ b/include/media/s5p_hdmi.h
> > @@ -20,6 +20,7 @@ struct i2c_board_info;
> > * @hdmiphy_info: template for HDMIPHY I2C device
> > * @mhl_bus: controller id for MHL control bus
> > * @mhl_info: template for MHL I2C device
> > + * @hpd_gpio: GPIO for Hot-Plug-Detect pin
> > *
> > * NULL pointer for *_info fields indicates that
> > * the corresponding chip is not present
> > @@ -29,6 +30,7 @@ struct s5p_hdmi_platform_data {
> > struct i2c_board_info *hdmiphy_info;
> > int mhl_bus;
> > struct i2c_board_info *mhl_info;
> > + int hpd_gpio;
> > };
> >
> > #endif /* S5P_HDMI_H */
> > --
> > 1.7.0.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* arm-soc maintainer entry
From: Stephen Boyd @ 2012-10-04 8:41 UTC (permalink / raw)
To: linux-arm-kernel
Is the arm at kernel.org alias going to be added into the MAINTAINERS file?
Should anybody be sending mails to this address?
It seems I asked this over a year ago and the response was positive but
nothing ever happened[1]. Maybe something like below? I only ask because
get_maintainer.pl isn't picking up this email.
diff --git a/MAINTAINERS b/MAINTAINERS
index ecd8796..0e1ec23 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -606,6 +606,14 @@ W: http://www.arm.linux.org.uk/
S: Maintained
F: arch/arm/
+ARM SUB-ARCHITECTURES
+M: arm at kernel.org
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S: MAINTAINED
+F: arch/arm/mach-*/
+F: arch/arm/plat-*/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
+
ARM PRIMECELL AACI PL041 DRIVER
M: Russell King <linux@arm.linux.org.uk>
S: Maintained
[1] https://lkml.org/lkml/2011/7/26/307
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH] ARM: OMAP2+: gpmc: annotate exit sections properly
From: Afzal Mohammed @ 2012-10-04 8:31 UTC (permalink / raw)
To: linux-arm-kernel
compiler complained,
`gpmc_remove' referenced in section `.data' of arch/arm/mach-omap2/built-in.o: defined in discarded section `.exit.text' of arch/arm/mach-omap2/built-in.o
Annotate gpmc_remove function and dependents with __devexit.
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
Hi,
Section mismatch occured due to my change,
"ARM: OMAP2+: gpmc: minimal driver support".
As this change is not yet in vanilla, SHA1 has not been
mentioned in commit log. Original change that introduced the
above mentioned warning has as of now swimmed only till
linux-omap and linux-next.
This has been generated against linux-next (next-20121003)
Regards
Afzal
arch/arm/mach-omap2/gpmc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8ab1e1b..5ac5cf3 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -838,7 +838,7 @@ static int gpmc_setup_irq(void)
return request_irq(gpmc_irq, gpmc_handle_irq, 0, "gpmc", NULL);
}
-static __exit int gpmc_free_irq(void)
+static __devexit int gpmc_free_irq(void)
{
int i;
@@ -944,7 +944,7 @@ static __devinit int gpmc_probe(struct platform_device *pdev)
return 0;
}
-static __exit int gpmc_remove(struct platform_device *pdev)
+static __devexit int gpmc_remove(struct platform_device *pdev)
{
gpmc_free_irq();
gpmc_mem_exit();
--
1.7.12
^ permalink raw reply related
* [RFC PATCH v2 2/2] watchdog: add timeout-sec property binding to some drivers
From: Fabio Porcedda @ 2012-10-04 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349339219-1467-1-git-send-email-fabio.porcedda@gmail.com>
The binding is provided by the watchdog core.
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
f2
---
.../devicetree/bindings/watchdog/atmel-wdt.txt | 4 ++++
.../devicetree/bindings/watchdog/marvel.txt | 5 +++++
drivers/watchdog/at91sam9_wdt.c | 23 ++++++++++++++++------
drivers/watchdog/orion_wdt.c | 13 ++++++------
4 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
index 2957ebb..ad4cc0a 100644
--- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
@@ -7,9 +7,13 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped
region.
+Optional properties:
+- timeout-sec : Contains the watchdog timeout in seconds
+
Example:
watchdog at fffffd40 {
compatible = "atmel,at91sam9260-wdt";
reg = <0xfffffd40 0x10>;
+ timeout-sec = <10>;
};
diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt
index 0b2503a..5dc8d30 100644
--- a/Documentation/devicetree/bindings/watchdog/marvel.txt
+++ b/Documentation/devicetree/bindings/watchdog/marvel.txt
@@ -5,10 +5,15 @@ Required Properties:
- Compatibility : "marvell,orion-wdt"
- reg : Address of the timer registers
+Optional properties:
+
+- timeout-sec : Contains the watchdog timeout in seconds
+
Example:
wdt at 20300 {
compatible = "marvell,orion-wdt";
reg = <0x20300 0x28>;
+ timeout-sec = <10>;
status = "okay";
};
diff --git a/drivers/watchdog/at91sam9_wdt.c b/drivers/watchdog/at91sam9_wdt.c
index dc42e44..3f66193 100644
--- a/drivers/watchdog/at91sam9_wdt.c
+++ b/drivers/watchdog/at91sam9_wdt.c
@@ -32,7 +32,6 @@
#include <linux/timer.h>
#include <linux/bitops.h>
#include <linux/uaccess.h>
-#include <linux/of.h>
#include "at91sam9_wdt.h"
@@ -57,11 +56,13 @@
#define WDT_TIMEOUT (HZ/2)
/* User land timeout */
-#define WDT_HEARTBEAT 15
-static int heartbeat = WDT_HEARTBEAT;
+#define MIN_HEARTBEAT 1
+#define MAX_HEARTBEAT 16
+#define DEF_HEARTBEAT 15
+static int heartbeat = 0;
module_param(heartbeat, int, 0);
MODULE_PARM_DESC(heartbeat, "Watchdog heartbeats in seconds. "
- "(default = " __MODULE_STRING(WDT_HEARTBEAT) ")");
+ "(default = " __MODULE_STRING(DEF_HEARTBEAT) ")");
static bool nowayout = WATCHDOG_NOWAYOUT;
module_param(nowayout, bool, 0);
@@ -255,6 +256,11 @@ static struct miscdevice at91wdt_miscdev = {
.fops = &at91wdt_fops,
};
+static struct watchdog_device at91wdt_wdd __initdata = {
+ .min_timeout = MIN_HEARTBEAT,
+ .max_timeout = MAX_HEARTBEAT,
+};
+
static int __init at91wdt_probe(struct platform_device *pdev)
{
struct resource *r;
@@ -273,6 +279,11 @@ static int __init at91wdt_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ if ((heartbeat < MIN_HEARTBEAT) || (heartbeat > MAX_HEARTBEAT)) {
+ at91wdt_wdd.timeout = DEF_HEARTBEAT;
+ watchdog_probe_dt_timeout(&at91wdt_wdd, pdev->dev.of_node);
+ }
+
/* Set watchdog */
res = at91_wdt_settimeout(ms_to_ticks(WDT_HW_TIMEOUT * 1000));
if (res)
@@ -282,12 +293,12 @@ static int __init at91wdt_probe(struct platform_device *pdev)
if (res)
return res;
- at91wdt_private.next_heartbeat = jiffies + heartbeat * HZ;
+ at91wdt_private.next_heartbeat = jiffies + at91wdt_wdd.timeout * HZ;
setup_timer(&at91wdt_private.timer, at91_ping, 0);
mod_timer(&at91wdt_private.timer, jiffies + WDT_TIMEOUT);
pr_info("enabled (heartbeat=%d sec, nowayout=%d)\n",
- heartbeat, nowayout);
+ at91wdt_wdd.timeout, nowayout);
return 0;
}
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index c20f96b..14406e6 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -24,7 +24,6 @@
#include <linux/spinlock.h>
#include <linux/clk.h>
#include <linux/err.h>
-#include <linux/of.h>
#include <mach/bridge-regs.h>
/*
@@ -162,12 +161,14 @@ static int __devinit orion_wdt_probe(struct platform_device *pdev)
wdt_max_duration = WDT_MAX_CYCLE_COUNT / wdt_tclk;
- if ((heartbeat < 1) || (heartbeat > wdt_max_duration))
- heartbeat = wdt_max_duration;
-
- orion_wdt.timeout = heartbeat;
orion_wdt.min_timeout = 1;
orion_wdt.max_timeout = wdt_max_duration;
+ if ((heartbeat >= 1) && (heartbeat <= wdt_max_duration)) {
+ orion_wdt.timeout = heartbeat;
+ } else {
+ orion_wdt.timeout = wdt_max_duration;
+ watchdog_probe_dt_timeout(&orion_wdt, pdev->dev.of_node);
+ }
watchdog_set_nowayout(&orion_wdt, nowayout);
ret = watchdog_register_device(&orion_wdt);
@@ -177,7 +178,7 @@ static int __devinit orion_wdt_probe(struct platform_device *pdev)
}
pr_info("Initial timeout %d sec%s\n",
- heartbeat, nowayout ? ", nowayout" : "");
+ orion_wdt.timeout, nowayout ? ", nowayout" : "");
return 0;
}
--
1.7.11.3
^ permalink raw reply related
* [RFC PATCH v2 1/2] watchdog: core: dt: add support for the timeout-sec dt property
From: Fabio Porcedda @ 2012-10-04 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349339219-1467-1-git-send-email-fabio.porcedda@gmail.com>
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
Documentation/watchdog/watchdog-kernel-api.txt | 3 +++
include/linux/watchdog.h | 15 +++++++++++++++
2 files changed, 18 insertions(+)
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt
index 086638f..35057b2 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -212,3 +212,6 @@ driver specific data to and a pointer to the data itself.
The watchdog_get_drvdata function allows you to retrieve driver specific data.
The argument of this function is the watchdog device where you want to retrieve
data from. The function returns the pointer to the driver specific data.
+
+The watchdog_probe_dt_timeout function allows you to retrieve the timeout-sec
+property from the device tree.
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index da70f0f..18af39f 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -11,6 +11,7 @@
#include <linux/ioctl.h>
#include <linux/types.h>
+#include <linux/of.h>
#define WATCHDOG_IOCTL_BASE 'W'
@@ -174,6 +175,20 @@ static inline void *watchdog_get_drvdata(struct watchdog_device *wdd)
return wdd->driver_data;
}
+/* Use the following function to retrieve the timeout-sec property from dt */
+static inline void watchdog_probe_dt_timeout(struct watchdog_device *wdd,
+ struct device_node *node)
+{
+ unsigned int t = 0;
+
+ if (!node)
+ return;
+
+ of_property_read_u32(node, "timeout-sec", &t);
+ if ((t >= wdd->min_timeout) && (t <= wdd->max_timeout))
+ wdd->timeout = t;
+}
+
/* drivers/watchdog/core/watchdog_core.c */
extern int watchdog_register_device(struct watchdog_device *);
extern void watchdog_unregister_device(struct watchdog_device *);
--
1.7.11.3
^ permalink raw reply related
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