* [PATCH v4 12/13] ARM: mm: clean up membank size limit checks
From: Cyril Chemparathy @ 2013-01-31 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359669512-31276-1-git-send-email-cyril@ti.com>
This patch cleans up the highmem sanity check code by simplifying the range
checks with a pre-calculated size_limit. This patch should otherwise have no
functional impact on behavior.
This patch also removes a redundant (bank->start < vmalloc_limit) check, since
this is already covered by the !highmem condition.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
---
arch/arm/mm/mmu.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 85ed732..2a02ff0 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -933,10 +933,15 @@ void __init sanity_check_meminfo(void)
for (i = 0, j = 0; i < meminfo.nr_banks; i++) {
struct membank *bank = &meminfo.bank[j];
+ phys_addr_t size_limit;
+
*bank = meminfo.bank[i];
+ size_limit = bank->size;
if (bank->start >= vmalloc_limit)
highmem = 1;
+ else
+ size_limit = vmalloc_limit - bank->start;
bank->highmem = highmem;
@@ -945,8 +950,7 @@ void __init sanity_check_meminfo(void)
* Split those memory banks which are partially overlapping
* the vmalloc area greatly simplifying things later.
*/
- if (!highmem && bank->start < vmalloc_limit &&
- bank->size > vmalloc_limit - bank->start) {
+ if (!highmem && bank->size > size_limit) {
if (meminfo.nr_banks >= NR_BANKS) {
printk(KERN_CRIT "NR_BANKS too low, "
"ignoring high memory\n");
@@ -955,12 +959,12 @@ void __init sanity_check_meminfo(void)
(meminfo.nr_banks - i) * sizeof(*bank));
meminfo.nr_banks++;
i++;
- bank[1].size -= vmalloc_limit - bank->start;
+ bank[1].size -= size_limit;
bank[1].start = vmalloc_limit;
bank[1].highmem = highmem = 1;
j++;
}
- bank->size = vmalloc_limit - bank->start;
+ bank->size = size_limit;
}
#else
/*
@@ -978,14 +982,13 @@ void __init sanity_check_meminfo(void)
* Check whether this memory bank would partially overlap
* the vmalloc area.
*/
- if (bank->start + bank->size > vmalloc_limit)
- unsigned long newsize = vmalloc_limit - bank->start;
+ if (bank->size > size_limit) {
printk(KERN_NOTICE "Truncating RAM at %.8llx-%.8llx "
"to -%.8llx (vmalloc region overlap).\n",
(unsigned long long)bank->start,
(unsigned long long)bank->start + bank->size - 1,
- (unsigned long long)bank->start + newsize - 1);
- bank->size = newsize;
+ (unsigned long long)bank->start + size_limit - 1);
+ bank->size = size_limit;
}
#endif
if (!bank->highmem && bank->start + bank->size > arm_lowmem_limit)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 13/13] ARM: fix type of PHYS_PFN_OFFSET to unsigned long
From: Cyril Chemparathy @ 2013-01-31 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359669512-31276-1-git-send-email-cyril@ti.com>
On LPAE machines, PHYS_OFFSET evaluates to a phys_addr_t and this type is
inherited by the PHYS_PFN_OFFSET definition as well. Consequently, the kernel
build emits warnings of the form:
init/main.c: In function 'start_kernel':
init/main.c:588:7: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'phys_addr_t' [-Wformat]
This patch fixes this warning by pinning down the PFN type to unsigned long.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
---
arch/arm/include/asm/memory.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index f3a7f76..32e9e5a 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -223,7 +223,7 @@ static inline unsigned long __phys_to_virt(unsigned long x)
* direct-mapped view. We assume this is the first page
* of RAM in the mem_map as well.
*/
-#define PHYS_PFN_OFFSET (PHYS_OFFSET >> PAGE_SHIFT)
+#define PHYS_PFN_OFFSET ((unsigned long)(PHYS_OFFSET >> PAGE_SHIFT))
/*
* These are *only* valid on the kernel direct mapped RAM memory.
--
1.7.9.5
^ permalink raw reply related
* [RFC] arm: use built-in byte swap function
From: Woodhouse, David @ 2013-01-31 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131145947.f62474a0600848df86548b96@freescale.com>
On Thu, 2013-01-31 at 14:59 -0600, Kim Phillips wrote:
>
> - add new ARCH_DEFINES_BUILTIN_BSWAP (see Kconfig help).
Ick, no.
> - if set, generic compiler header does not set HAVE_BUILTIN_BSWAPxx
It won't do that anyway if !ARCH_USE_BUILTIN_BSWAP. I don't see the
point in adding a new config option just for this.
If you want to define __HAVE_BUILTIN_BSWAPxx__ for yourself manually,
just go ahead and do so. As I said, if lots of architectures end up
doing it then we'll worry about cleaning things up when we've got a
better picture of who needs what.
--
Sent with MeeGo's ActiveSync support.
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4370 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130131/c8350417/attachment.bin>
^ permalink raw reply
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: Nicolas Pitre @ 2013-01-31 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510AE6BF.4080303@zytor.com>
On Thu, 31 Jan 2013, H. Peter Anvin wrote:
> On 01/30/2013 10:33 AM, Nicolas Pitre wrote:
> >>
> >> The only concern I have with that is if someone paints themselves into a
> >> corner and absolutely wants, say, LZO.
> >
> > That would be hard to justify given that the kernel provides its own
> > decompressor code, making the compression format transparent to
> > bootloaders, etc. And no one should be poking into the compressed
> > zImage.
> >
>
> Some utterly weird things like the Xen domain builder do that, because
> they have to. That is why we explicitly document that the payload is
> ELF and how to access it in the bzImage spec.
Are you kidding?
And what format do they expect?
If people are doing weird things with formats we're about to remove then
it's their fault if they didn't make upstream developers aware of it.
And if the reason they didn't tell anyone is because it is too nasty for
public confession then they simply deserve to be broken and come up with
a more sustainable solution.
Nicolas
^ permalink raw reply
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: H. Peter Anvin @ 2013-01-31 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301311700470.6300@xanadu.home>
On 01/31/2013 02:16 PM, Nicolas Pitre wrote:
>>
>> Some utterly weird things like the Xen domain builder do that, because
>> they have to. That is why we explicitly document that the payload is
>> ELF and how to access it in the bzImage spec.
>
> Are you kidding?
>
> And what format do they expect?
>
I think they can be fairly flexible. Obviously gzip is always
supported. I don't know the details.
> If people are doing weird things with formats we're about to remove then
> it's their fault if they didn't make upstream developers aware of it.
> And if the reason they didn't tell anyone is because it is too nasty for
> public confession then they simply deserve to be broken and come up with
> a more sustainable solution.
Well, it is too nasty for public confession, but it's called
"paravirtualization".
-hpa
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Simon Baatz @ 2013-01-31 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131003222.GX7717@titan.lakedaemon.net>
Hi Jason,
On Wed, Jan 30, 2013 at 07:32:22PM -0500, Jason Cooper wrote:
> On Thu, Jan 31, 2013 at 12:22:24AM +0100, Sebastian Hesselbarth wrote:
> > On 01/31/2013 12:01 AM, Jason Cooper wrote:
> > >As it stands, there are three patches to fix this issue:
> > >
> > >ARM: kirkwood: of_serial: fix clock gating by removing clock-frequency
> > >ARM: kirkwood: provide ge clock aliases for shared smi
> > >ARM: kirkwood: fix to retain gbe MAC addresses for DT kernels
> >
> > Actually, for the second patch I got distracted by the smi split patch
> > set floating around. But that is not in current kernel and smi will not
> > request any clock at all.
> >
> > If Simon can hit another round of testing without second patch included
> > and agrees, I suggest to keep it for next release.
>
> Ok, I'll wait for Simon on this. fixes can go anytime, so no rush.
> Better to get it right the first (second?) time out.
Ok, will do. For the first patch you already have my Tested-by.
Sebastian is right on the second one, it does not add value for 3.8
yet. I will test the third patch as soon as I find time.
- Simon
^ permalink raw reply
* [PATCH 6/6] ARM: integrator: ensure ap_syscon_base is initialised when !CONFIG_MMU
From: Will Deacon @ 2013-01-31 22:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbFL6cA9wPdc7h8bTmH0t7PeVwmO+4LBwQGbSKNFJOS+Q@mail.gmail.com>
Hi Linus,
On Thu, Jan 31, 2013 at 08:21:04PM +0000, Linus Walleij wrote:
> On Wed, Jan 30, 2013 at 3:27 PM, Will Deacon <will.deacon@arm.com> wrote:
>
> > When running on Integrator/AP using atags, ap_syscon_base is initialised
> > in ->map_io, which isn't called for !MMU platforms.
>
> Oh hm. Haha apparently there is one guy with more bizarre hobbies
> than myself, you're making me feel un-geeky... ;-)
Ha! Unfortunately, I only have one core-tile otherwise you could have one to
help you feel less left-out :)
> > Instead, initialise the pointer in ->machine_init, as we do when booting
> > with device-tree.
>
> I was trying to figure out if there is some case where we need it earlier
> but apparently not so.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cheers!
> Maybe you should send this oneliner directly to the ARM SoC
> people?
[adding Olof and Arnd] Is it worth sending a pull request containing a
single patch, or can this patch just be picked directly?
Cheers,
Will
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Simon Baatz @ 2013-01-31 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130230100.GV7717@titan.lakedaemon.net>
Hi Jason, Sebastian,
On Wed, Jan 30, 2013 at 06:01:00PM -0500, Jason Cooper wrote:
>
> wrt to runit gating, the only case we are not covering is if of_serial
> is a module (and so is everything else using the runit clk). That's
> *really* rare. If someone embarks down that path, they get the
> responsibility of not writing to all the deactivated registers. ;-)
With the serial driver now enabling runit it is really rare, but
where is your enthusiasm to get to the bottom of it? At least we
have indications that there really is something in "..." (my box
stops somewhere when no driver enables runit)
Sebastian, are you still interested in the .flags stuff from the
runit patch or do you see no need now since "ddr" is the only
exception anyway?
- Simon
^ permalink raw reply
* [rtc-linux] [PATCH] rtc: pl031: fix the missing operation on enable
From: Andrew Morton @ 2013-01-31 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359507865-29808-1-git-send-email-haojian.zhuang@linaro.org>
On Wed, 30 Jan 2013 09:04:25 +0800
Haojian Zhuang <haojian.zhuang@linaro.org> wrote:
> RTC control register should be enabled in the process of initliazing.
>
> ...
>
> --- a/drivers/rtc/rtc-pl031.c
> +++ b/drivers/rtc/rtc-pl031.c
> @@ -44,6 +44,7 @@
> #define RTC_YMR 0x34 /* Year match register */
> #define RTC_YLR 0x38 /* Year data load register */
>
> +#define RTC_CR_EN (1 << 0) /* counter enable bit */
> #define RTC_CR_CWEN (1 << 26) /* Clockwatch enable bit */
>
> #define RTC_TCR_EN (1 << 1) /* Periodic timer enable bit */
> @@ -320,7 +321,7 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
> struct pl031_local *ldata;
> struct pl031_vendor_data *vendor = id->data;
> struct rtc_class_ops *ops = &vendor->ops;
> - unsigned long time;
> + unsigned long time, data;
>
> ret = amba_request_regions(adev, NULL);
> if (ret)
> @@ -345,10 +346,11 @@ static int pl031_probe(struct amba_device *adev, const struct amba_id *id)
> dev_dbg(&adev->dev, "designer ID = 0x%02x\n", amba_manf(adev));
> dev_dbg(&adev->dev, "revision = 0x%01x\n", amba_rev(adev));
>
> + data = readl(ldata->base + RTC_CR);
> /* Enable the clockwatch on ST Variants */
> if (vendor->clockwatch)
> - writel(readl(ldata->base + RTC_CR) | RTC_CR_CWEN,
> - ldata->base + RTC_CR);
> + data |= RTC_CR_CWEN;
> + writel(data | RTC_CR_EN, ldata->base + RTC_CR);
Does this patch fix some user-visible misbehaviour? If so, please
fully describe that misbehaviour.
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Jason Gunthorpe @ 2013-01-31 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301312046.22560.arnd@arndb.de>
On Thu, Jan 31, 2013 at 08:46:22PM +0000, Arnd Bergmann wrote:
> > If it is 0xDEAD0000, then Thomas has to keep what he has now, you
> > can't mess with this address. Verify that the full 32 bit address
> > exactly matching the MBUS window address is written to the PCI-PCI
> > bridge IO base/limit registers.
>
> If you do this, you break all sorts of expectations in the kernel and
> I guess you'd have to set the io_offset value of that bus to 0x21530000
> in order to make Linux I/O port 0 go to the first byte of the window
> and come out as 0xDEAD0000 on the bus, but you still won't be able to
> use legacy devices with hardcoded I/O port numbers.
I'm not sure exactly how the PCI core handles this, but it does look
like pci_add_resource_offset via io_offset is the answer. I'm not sure
what goes in the struct resource passed to the PCI core - the *bus* IO
address range or the *kernel* IO address range..
> > If it is 0x00000000 then the mmap scheme I outlined before must be
> > used, and verify that only 0->0xFFFF is written to the PCI-PCI bridge
> > IO base/limit registers..
>
> For the primary bus, yes, but there are still two options for the
> second one: you can either start at 0 again or you can continue
No, for *all* links. You use a mmap scheme with 4k granularity, I
explained in a past email, but to quickly review..
- Each link gets 64k of reserved physical address space for IO,
this is just set aside, no MBUS windows are permantently assigned.
- Linux is told to use a 64k IO range with bus IO address 0->0xFFFF
- When the IO base/limit register in the link PCI-PCI bridge is programmed
the driver gets a 4k aligned region somewhere from 0->0xFFFF and then:
- Allocates a 64k MBUS window that translates physical address
0xZZZZxxxx to IO bus address 0x0000xxxx (goes in the TLP) for
that link
- Uses pci_ioremap_io to map the fraction of the link's 64k MBUS window
allocated to that bridge to the correct offset in the
PCI_IO_VIRT_BASE region
So you'd end up with a MMU mapping something like:
PCI_IO_VIRT_BASE MBUS_IO_PHYS_BASE
0->4k => 0 -> 4k // 4k assigned to link0
4k->8k => 64k+4k -> 64k+8k // 4k assigned to link1
8k->24k => 128k+8k -> 128k+24k // 8k assigned to link2
Where the physical mbus window for each link starts on each 64k block.
Thomas: This solves the need to have alignment of the IO regions, and
gets rid of any trouble with 32 bit IO addreses, however you'll need
to allocate the remap capable mbus windows separately for use by IO
mappings..
Though, there is still a problem with the MMIO mbus window
alignment. mbus windows are aligned to a multiple of their size, PCI
MMIO bridge windows are always aligned to 1M...
> at 0x10000 as we do for mv78xx0 and kirkwood for instance. Both
> approaches probably have their merit.
Kirkwood uses the MBUS remapping registers to set the TLP address of
link 0 to start at 0 and of link 1 to start at 0x10000 - so it is
consistent with what you describe..
However, this is a suboptimal way to run the HW. It would be much
better to place each link in a seperate PCI domain and have each link
start its bus IO address at 0, and assign the kernel IO address in
sequential 64k blocks as today.
Though, it is my hope that Thomas's driver will work on Kirkwood as
well...
Jason
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Sebastian Hesselbarth @ 2013-01-31 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131224457.GB17976@schnuecks.de>
On 01/31/2013 11:44 PM, Simon Baatz wrote:
> Hi Jason, Sebastian,
>
> On Wed, Jan 30, 2013 at 06:01:00PM -0500, Jason Cooper wrote:
>>
>> wrt to runit gating, the only case we are not covering is if of_serial
>> is a module (and so is everything else using the runit clk). That's
>> *really* rare. If someone embarks down that path, they get the
>> responsibility of not writing to all the deactivated registers. ;-)
>
> With the serial driver now enabling runit it is really rare, but
> where is your enthusiasm to get to the bottom of it? At least we
> have indications that there really is something in "..." (my box
> stops somewhere when no driver enables runit)
I think watchdog could be an issue, Jason had it disabled and
he was able to run it, right? I don't have a strong opinion on that,
but I'd disable every clock you can - OTOH runit will be enabled
anyway if you choose to have serial.
> Sebastian, are you still interested in the .flags stuff from the
> runit patch or do you see no need now since "ddr" is the only
> exception anyway?
I don't expect to use it on Dove but it should be good to have for
Kirkwood and maybe Armada XP/370 too. You prepare a patch?
Sebastian
^ permalink raw reply
* [rtc-linux] [RFC] ARM i.MX: rtc: change interrupt handling for DryIce
From: Andrew Morton @ 2013-01-31 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359641777-975-1-git-send-email-s.trumtrar@pengutronix.de>
On Thu, 31 Jan 2013 15:16:17 +0100
Steffen Trumtrar <s.trumtrar@pengutronix.de> wrote:
> di_write_wait uses a very short timeout of 1ms for the wait_queue.
> This may lead to write errors to some registers. Write errors to DCAMR and
> DSR_CAF where the only one observed, though:
>
> Tue Jan 14 15:32:23 2014 -0.985304 seconds
> Tue Jan 14 15:32:24 2014 -0.985236 seconds
> Tue Jan 14 15:32:25 2014 -0.986601 seconds
> imxdi_rtc 53ffc000.dryice: Write-wait timeout val = 0x52d5588a reg = 0x00000008
> Tue Jan 14 15:32:26 2014 -0.983772 seconds
> Tue Jan 14 15:32:27 2014 -0.983594 seconds
> imxdi_rtc 53ffc000.dryice: Write-wait timeout val = 0x52d5588c reg = 0x00000008
> Tue Jan 14 15:32:28 2014 -0.983596 seconds
> imxdi_rtc 53ffc000.dryice: Write-wait timeout val = 0x52d5588d reg = 0x00000008
> Tue Jan 14 15:32:29 2014 -0.983300 seconds
> Tue Jan 14 15:32:30 2014 -0.982809 seconds
>
> Just increasing this timeout leads to a race condition in the interrupt handler.
> After a couple minutes of running
> while true; do hwclock; done
> the interrupt isn't handled by the driver and disabled in the process.
> This seems to be because of the waitqueue check and then returning out of the
> handler, as there is no other handler that takes over.
>
> Use wait_event_interruptible without a timeout instead and do not leave the
> interrupt handler in case of an empty waitqueue, but handle the actual irq case.
> As before, nothing is done in that case though.
>
The patch makes changes which aren't described in the above changelog:
- Fiddles with the new DIER_SVIE
- Enables the DIER_WEIE interrupt
> @@ -168,15 +169,18 @@ static int di_write_wait(struct imxdi_dev *imxdi, u32 val, int reg)
> __raw_writel(val, imxdi->ioaddr + reg);
>
> /* wait for the write to finish */
> - ret = wait_event_interruptible_timeout(imxdi->write_wait,
> - imxdi->dsr & (DSR_WCF | DSR_WEF), msecs_to_jiffies(1));
> - if (ret < 0) {
> + ret = wait_event_interruptible(imxdi->write_wait, imxdi->dsr &
> + (DSR_WCF | DSR_WEF));
> +
> + if (ret <= 0) {
> rc = ret;
> goto out;
> - } else if (ret == 0) {
> + } else if (ret > 0) {
> dev_warn(&imxdi->pdev->dev,
> "Write-wait timeout "
> "val = 0x%08x reg = 0x%08x\n", val, reg);
> + rc = -ERESTARTSYS;
> + goto out;
> }
This code looks all confused. wait_event_interruptible() can only
return two things: zero or -ERESTARTSYS. That code which handles (ret
> 0) will never be executed.
di_write_wait() should return -ERESTARTSYS if
wait_event_interruptible() returned -ERESTARTSYS and it should return 0
if wait_event_interruptible() returned 0. So local variable `ret' can
just go away. Although I'd suggest then renaming `rc' to `ret', as the
latter is more conventional.
^ permalink raw reply
* [PATCH 6/6] ARM: integrator: ensure ap_syscon_base is initialised when !CONFIG_MMU
From: Olof Johansson @ 2013-01-31 22:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131223417.GB19961@mudshark.cambridge.arm.com>
On Thu, Jan 31, 2013 at 10:34:17PM +0000, Will Deacon wrote:
> Hi Linus,
>
> On Thu, Jan 31, 2013 at 08:21:04PM +0000, Linus Walleij wrote:
> > On Wed, Jan 30, 2013 at 3:27 PM, Will Deacon <will.deacon@arm.com> wrote:
> >
> > > When running on Integrator/AP using atags, ap_syscon_base is initialised
> > > in ->map_io, which isn't called for !MMU platforms.
> >
> > Oh hm. Haha apparently there is one guy with more bizarre hobbies
> > than myself, you're making me feel un-geeky... ;-)
>
> Ha! Unfortunately, I only have one core-tile otherwise you could have one to
> help you feel less left-out :)
>
> > > Instead, initialise the pointer in ->machine_init, as we do when booting
> > > with device-tree.
> >
> > I was trying to figure out if there is some case where we need it earlier
> > but apparently not so.
> >
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Cheers!
>
> > Maybe you should send this oneliner directly to the ARM SoC
> > people?
>
> [adding Olof and Arnd] Is it worth sending a pull request containing a
> single patch, or can this patch just be picked directly?
Definitely ok to just send the patch like this. However -- where was
the breakage introduced, i.e. what should we apply the fix to?
-Olof
^ permalink raw reply
* [GIT PULL] Nomadik devicetree and cleanups
From: Olof Johansson @ 2013-01-31 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaVOV4d9xeuKnMyfGgM+Su3M6dmo2pyeEQE9Qb2sErzzA@mail.gmail.com>
On Wed, Jan 30, 2013 at 11:21:06PM +0100, Linus Walleij wrote:
> On Tue, Jan 29, 2013 at 6:36 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Mon, Jan 28, 2013 at 11:36:59PM +0100, Linus Walleij wrote:
> >> On Mon, Jan 28, 2013 at 10:31 PM, Olof Johansson <olof@lixom.net> wrote:
> >>
> >> > Would you mind rebasing on top of the depends/cleanup branch in arm-soc, sort
> >> > out the breakage (and test it) and resubmit?
> >>
> >> So Olof, please try this instead, based on the ARM depends/cleanup HEAD
> >> when I fetched it:
> >>
> >> The following changes since commit f8060f5446b1f2782f0a8ca9be2d870ea4198aee:
> >>
> >> Merge tag 'gic-vic-to-irqchip' of
> >> git://sources.calxeda.com/kernel/linux into next/cleanup (2013-01-14
> >> 19:55:03 -0800)
> >>
> >> are available in the git repository at:
> >>
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
> >> tags/nmk-dt-on-cleanups
> >
> > Beautiful! Pulled. Zero conflicts. :)
>
> So as I heard this blew up for selecting OF instead of USE_OF here
> is yet another pull request, with this oneliner change in the relevant
> patch ("ARM: nomadik: delete old board files"):
>
> - select OF
> + select USE_OF
>
> I have tried to provoke builderrors with the defconfig but couldn't.
>
> Here is then yet another pull request, and let's hope it works this
> time around:
Dropping and replacing branches is awkward, and you rewrote history here. It'd
be better to just take a fixup patch on top that switches the two selects.
-Olof
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Cooper @ 2013-02-01 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131224457.GB17976@schnuecks.de>
On Thu, Jan 31, 2013 at 11:44:57PM +0100, Simon Baatz wrote:
> Hi Jason, Sebastian,
>
> On Wed, Jan 30, 2013 at 06:01:00PM -0500, Jason Cooper wrote:
> >
> > wrt to runit gating, the only case we are not covering is if of_serial
> > is a module (and so is everything else using the runit clk). That's
> > *really* rare. If someone embarks down that path, they get the
> > responsibility of not writing to all the deactivated registers. ;-)
>
> With the serial driver now enabling runit it is really rare, but
> where is your enthusiasm to get to the bottom of it?
No one responded to my email. I figured I got a little too intense and
decided to let it go. Didn't want to be the ranting a-hole (too late). :-)
If you're interested, I still have a few ideas. One was to wire two USB
serial adapters end to end to create a different console
(console=/dev/ttyUSB0,115200, getty, etc). Since they would be going
over usb, that's a different clock, so it should work and provide us
with a safety net.
I'll see if I can dig up a few spare cables and try it out over the next
few days. Priority is to get the pull requests for v3.9 in, though.
thx,
Jason.
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Cooper @ 2013-02-01 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510AF502.5060306@gmail.com>
On Thu, Jan 31, 2013 at 11:49:38PM +0100, Sebastian Hesselbarth wrote:
> On 01/31/2013 11:44 PM, Simon Baatz wrote:
> >Hi Jason, Sebastian,
> >
> >On Wed, Jan 30, 2013 at 06:01:00PM -0500, Jason Cooper wrote:
> >>
> >>wrt to runit gating, the only case we are not covering is if of_serial
> >>is a module (and so is everything else using the runit clk). That's
> >>*really* rare. If someone embarks down that path, they get the
> >>responsibility of not writing to all the deactivated registers. ;-)
> >
> >With the serial driver now enabling runit it is really rare, but
> >where is your enthusiasm to get to the bottom of it? At least we
> >have indications that there really is something in "..." (my box
> >stops somewhere when no driver enables runit)
>
> I think watchdog could be an issue, Jason had it disabled and
> he was able to run it, right? I don't have a strong opinion on that,
> but I'd disable every clock you can - OTOH runit will be enabled
> anyway if you choose to have serial.
I got the list of modules be searching kirkwood.dtsi for '&gate_clk 7'.
the watchdog made the list.
Once I can get a proper test environment setup, my first goal is to show
runit gated from a command prompt. The second goal is to use it in a
*really* locked down / low power firewall gateway. There is no timeline
for goal number two. ;-)
> >Sebastian, are you still interested in the .flags stuff from the
> >runit patch or do you see no need now since "ddr" is the only
> >exception anyway?
>
> I don't expect to use it on Dove but it should be good to have for
> Kirkwood and maybe Armada XP/370 too. You prepare a patch?
I'm thinking we probably don't need it atm.
thx,
Jason.
^ permalink raw reply
* [PATCH 2/4] ARM: mach-shmobile: r8a7779: Allow initialisation of GIC by DT
From: Simon Horman @ 2013-02-01 0:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131123213.GB7235@e106331-lin.cambridge.arm.com>
On Thu, Jan 31, 2013 at 12:32:13PM +0000, Mark Rutland wrote:
> Hi Simon,
>
> On Thu, Jan 31, 2013 at 01:50:49AM +0000, Simon Horman wrote:
> > This allows the GIC interrupt controller of the r8a7779 SoC to be
> > initialised using a flattened device tree blob.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > ---
> > arch/arm/boot/dts/r8a7779.dtsi | 40 ++++++++++++++++++++++++++
> > arch/arm/mach-shmobile/include/mach/common.h | 1 +
> > arch/arm/mach-shmobile/intc-r8a7779.c | 27 +++++++++++++----
> > 3 files changed, 62 insertions(+), 6 deletions(-)
> > create mode 100644 arch/arm/boot/dts/r8a7779.dtsi
> >
> > diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
> > new file mode 100644
> > index 0000000..eadc12e
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/r8a7779.dtsi
> > @@ -0,0 +1,40 @@
> > +/*
> > + * Device Tree Source for Renesas r8a7740
> > + *
> > + * Copyright (C) 2013 Renesas Solutions Corp.
> > + * Copyright (C) 2013 Simon Horman
> > + *
> > + * This file is licensed under the terms of the GNU General Public License
> > + * version 2. This program is licensed "as is" without any warranty of any
> > + * kind, whether express or implied.
> > + */
> > +
> > +/include/ "skeleton.dtsi"
> > +
> > +/ {
> > + compatible = "renesas,r8a7779";
> > +
> > + cpus {
> > + cpu at 0 {
> > + compatible = "arm,cortex-a9";
> > + };
> > + cpu at 1 {
> > + compatible = "arm,cortex-a9";
> > + };
> > + cpu at 2 {
> > + compatible = "arm,cortex-a9";
> > + };
> > + cpu at 3 {
> > + compatible = "arm,cortex-a9";
> > + };
> > + };
>
> Sorry to sound like a broken record, but it'd be good to see reg and
> device_type set here.
Sure, will do.
> > +
> > + gic: interrupt-controller at f0001000 {
> > + compatible = "arm,cortex-a9-gic";
> > + #interrupt-cells = <3>;
> > + #address-cells = <1>;
>
> Why is #address-cells needed here (and without #size-cells)? I see it's in the
> binding document example, but I can't figure out why.
Its here because I copied the example.
I will see about removing it from here.
> > + interrupt-controller;
> > + reg = <0xf0001000 0x1000>,
> > + <0xf0000100 0x100>;
> > + };
> > +};
>
> [...]
>
> Thanks,
> Mark.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/2] ARM: shmobile: sh73a0: Add CPU sleep suspend
From: Simon Horman @ 2013-02-01 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CABYn4syaAmi6mJApwa_kTRBDwv+HPbPnAJAwwRWrN2-0zY=SmQ@mail.gmail.com>
On Thu, Jan 31, 2013 at 12:31:17PM -0400, Bastian Hecht wrote:
> Looks perfect, thanks!
Great, thanks.
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Gunthorpe @ 2013-02-01 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201000109.GK7717@titan.lakedaemon.net>
On Thu, Jan 31, 2013 at 07:01:09PM -0500, Jason Cooper wrote:
> If you're interested, I still have a few ideas. One was to wire two USB
> serial adapters end to end to create a different console
> (console=/dev/ttyUSB0,115200, getty, etc). Since they would be going
> over usb, that's a different clock, so it should work and provide us
> with a safety net.
I can't recall, can you still use JTAG once the CPU has hung on a mbus
access?
If so memory dumping the console ring, or cpu registers would get the
answer pretty directly..
My guesses would be the RTC and/or GPIO blocks (the GPIO blinker needs
a clock), based on table 94.
Jason
^ permalink raw reply
* [PATCH 2/4] ARM: mach-shmobile: r8a7779: Allow initialisation of GIC by DT
From: Simon Horman @ 2013-02-01 0:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130201001119.GO10312@verge.net.au>
On Fri, Feb 01, 2013 at 09:11:19AM +0900, Simon Horman wrote:
> On Thu, Jan 31, 2013 at 12:32:13PM +0000, Mark Rutland wrote:
> > Hi Simon,
> >
> > On Thu, Jan 31, 2013 at 01:50:49AM +0000, Simon Horman wrote:
> > > This allows the GIC interrupt controller of the r8a7779 SoC to be
> > > initialised using a flattened device tree blob.
> > >
> > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> > > ---
> > > arch/arm/boot/dts/r8a7779.dtsi | 40 ++++++++++++++++++++++++++
> > > arch/arm/mach-shmobile/include/mach/common.h | 1 +
> > > arch/arm/mach-shmobile/intc-r8a7779.c | 27 +++++++++++++----
> > > 3 files changed, 62 insertions(+), 6 deletions(-)
> > > create mode 100644 arch/arm/boot/dts/r8a7779.dtsi
> > >
> > > diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
> > > new file mode 100644
> > > index 0000000..eadc12e
> > > --- /dev/null
> > > +++ b/arch/arm/boot/dts/r8a7779.dtsi
> > > @@ -0,0 +1,40 @@
> > > +/*
> > > + * Device Tree Source for Renesas r8a7740
> > > + *
> > > + * Copyright (C) 2013 Renesas Solutions Corp.
> > > + * Copyright (C) 2013 Simon Horman
> > > + *
> > > + * This file is licensed under the terms of the GNU General Public License
> > > + * version 2. This program is licensed "as is" without any warranty of any
> > > + * kind, whether express or implied.
> > > + */
> > > +
> > > +/include/ "skeleton.dtsi"
> > > +
> > > +/ {
> > > + compatible = "renesas,r8a7779";
> > > +
> > > + cpus {
> > > + cpu at 0 {
> > > + compatible = "arm,cortex-a9";
> > > + };
> > > + cpu at 1 {
> > > + compatible = "arm,cortex-a9";
> > > + };
> > > + cpu at 2 {
> > > + compatible = "arm,cortex-a9";
> > > + };
> > > + cpu at 3 {
> > > + compatible = "arm,cortex-a9";
> > > + };
> > > + };
> >
> > Sorry to sound like a broken record, but it'd be good to see reg and
> > device_type set here.
>
> Sure, will do.
>
> > > +
> > > + gic: interrupt-controller at f0001000 {
> > > + compatible = "arm,cortex-a9-gic";
> > > + #interrupt-cells = <3>;
> > > + #address-cells = <1>;
> >
> > Why is #address-cells needed here (and without #size-cells)? I see it's in the
> > binding document example, but I can't figure out why.
>
> Its here because I copied the example.
> I will see about removing it from here.
>
> > > + interrupt-controller;
> > > + reg = <0xf0001000 0x1000>,
> > > + <0xf0000100 0x100>;
> > > + };
> > > +};
A revised patch is below. I should also remove "#address-cells = <1>" from
gic in arch/arm/boot/dts/sh73a0.dtsi if it is indeed unnecessary.
>From f08f5df1bd6e2133232d06b8cfb847424d6d4cc8 Mon Sep 17 00:00:00 2001
From: Simon Horman <horms+renesas@verge.net.au>
Date: Tue, 29 Jan 2013 14:21:46 +0900
Subject: [PATCH] ARM: mach-shmobile: r8a7779: Allow initialisation of GIC by
DT
This allows the GIC interrupt controller of the r8a7779 SoC to be
initialised using a flattened device tree blob.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm/boot/dts/r8a7779.dtsi | 50 ++++++++++++++++++++++++++
arch/arm/mach-shmobile/include/mach/common.h | 1 +
arch/arm/mach-shmobile/intc-r8a7779.c | 27 ++++++++++----
3 files changed, 72 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/boot/dts/r8a7779.dtsi
v2
As suggested by Mark Rutland
* Add reg and device_type to cpus
* Remove #address-cells from gic
diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
new file mode 100644
index 0000000..d1fde48
--- /dev/null
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -0,0 +1,50 @@
+/*
+ * Device Tree Source for Renesas r8a7740
+ *
+ * Copyright (C) 2013 Renesas Solutions Corp.
+ * Copyright (C) 2013 Simon Horman
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "renesas,r8a7779";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ };
+ cpu at 1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ };
+ cpu at 2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ };
+ cpu at 3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ reg = <0>;
+ };
+ };
+
+ gic: interrupt-controller at f0001000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0xf0001000 0x1000>,
+ <0xf0000100 0x100>;
+ };
+};
diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index 16dab18..8ef7ebb 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -63,6 +63,7 @@ extern void r8a7740_pinmux_init(void);
extern void r8a7740_pm_init(void);
extern void r8a7779_init_irq(void);
+extern void r8a7779_init_irq_dt(void);
extern void r8a7779_map_io(void);
extern void r8a7779_earlytimer_init(void);
extern void r8a7779_add_early_devices(void);
diff --git a/arch/arm/mach-shmobile/intc-r8a7779.c b/arch/arm/mach-shmobile/intc-r8a7779.c
index 8807c27..f9cc4bc 100644
--- a/arch/arm/mach-shmobile/intc-r8a7779.c
+++ b/arch/arm/mach-shmobile/intc-r8a7779.c
@@ -24,6 +24,7 @@
#include <linux/io.h>
#include <linux/irqchip/arm-gic.h>
#include <mach/common.h>
+#include <linux/irqchip.h>
#include <mach/intc.h>
#include <mach/r8a7779.h>
#include <asm/mach-types.h>
@@ -43,13 +44,8 @@ static int r8a7779_set_wake(struct irq_data *data, unsigned int on)
return 0; /* always allow wakeup */
}
-void __init r8a7779_init_irq(void)
+static void __init r8a7779_init_irq_common(void)
{
- void __iomem *gic_dist_base = IOMEM(0xf0001000);
- void __iomem *gic_cpu_base = IOMEM(0xf0000100);
-
- /* use GIC to handle interrupts */
- gic_init(0, 29, gic_dist_base, gic_cpu_base);
gic_arch_extn.irq_set_wake = r8a7779_set_wake;
/* route all interrupts to ARM */
@@ -63,3 +59,22 @@ void __init r8a7779_init_irq(void)
__raw_writel(0xbffffffc, INT2SMSKCR3);
__raw_writel(0x003fee3f, INT2SMSKCR4);
}
+
+void __init r8a7779_init_irq(void)
+{
+ void __iomem *gic_dist_base = IOMEM(0xf0001000);
+ void __iomem *gic_cpu_base = IOMEM(0xf0000100);
+
+ /* use GIC to handle interrupts */
+ gic_init(0, 29, gic_dist_base, gic_cpu_base);
+
+ r8a7779_init_irq_common();
+}
+
+#ifdef CONFIG_OF
+void __init r8a7779_init_irq_dt(void)
+{
+ irqchip_init();
+ r8a7779_init_irq_common();
+}
+#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Stephen Warren @ 2013-02-01 0:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359399397-29729-20-git-send-email-thomas.petazzoni@free-electrons.com>
On 01/28/2013 11:56 AM, Thomas Petazzoni wrote:
> This driver implements the support for the PCIe interfaces on the
> Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
> cover earlier families of Marvell SoCs, such as Dove, Orion and
> Kirkwood.
Bjorn and I happen to live very close, so we got together today and
talked about PCIe on ARM.
One of the questions he asked is: why does the window management on the
Marvell SoCs need to be dynamic?
(Sorry if this was covered earlier; I vaguely recall some discussion on
the topic, but couldn't find it quickly)
As background, PCIe enumeration in Linux usually works like:
1) You start off with some CPU physical address regions that generate
transactions on the PCIe bus.
2) You enumerate all the PCIe devices, and assign an address to each BAR
found, carved out of the PCIe address range corresponding to the regions
you knew from (1).
However, it sounds like the Marvell code wants to:
1) Start off with no real knowledge of the CPU physical address that
will generate transactions on the PCIe bus, since you want to assign
that later.
2) You enumerate all the PCIe devices, and assign an address. But, what
address range do you use?
3) Then you program the SoC's windows to set up the CPU->PCIe address
translations.
Am I recalling what you're trying to do correctly, or am I completely
confused?
Now, I recall that a related issue was that you are tight on CPU
physical address space, and the second algorithm above would allow the
size of the PCIe controller's window configuration to be as small as
possible, and hence there would be more CPU physical address space
available to fit in other peripherals.
However, why does this need to be dynamic? On a particular board, you
know all the other (non-PCIe) peripherals that you need to fit into the
CPU physical address space, so you know how much is left over for PCIe,
so why not always make the PCIe window fill up all the available space,
and use the first algorithm I described above? And also, I think you
always know the exact set of PCIe devices that are attached to the
boards, so you know the exact BAR size requirements there (or are there
user-accessible PCIe devices; I don't think so from your recent comments
about PCIe<->PCIe bridges not needing to be supported since the user
couldn't plug one in?)
Note that with DT, you can easily specify the window location/size in
the board .dts file rather than the SoC .dtsi file, so it can easily be
customized based on how much physical address space is taken up by RAM,
directly mapped NOR flash, etc.
With a static window configuration in DT, you'd end up with a system
that worked much like any x86 system or Tegra, with some static memory
range available to PCIe. It's just that in your case, the region
location/size could change from boot to boot based on DT, whereas it's
hard-coded in HW for Tegra and I assume x86 too.
^ permalink raw reply
* [PATCH v4] arm: use built-in byte swap function
From: Kim Phillips @ 2013-02-01 0:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359670248.27468.13.camel@shinybook.infradead.org>
>From 1490bd8823c05e0dda982524bb70cb6c6427ddf9 Mon Sep 17 00:00:00 2001
From: Kim Phillips <kim.phillips@freescale.com>
Date: Mon, 28 Jan 2013 19:30:33 -0600
Subject: [PATCH] arm: use built-in byte swap function
Enable the compiler intrinsic for byte swapping on arch ARM. This
allows the compiler to detect and be able to optimize out byte
swappings, e.g. in big endian to big endian moves.
A ARCH_DEFINES_BUILTIN_BSWAP is added to allow an ARCH to select
it when it wants to control HAVE_BUILTIN_BSWAPxx definitions over
those in the generic compiler headers. It can be dependent on a
combination of byte swapping instruction availability, the
instruction set version, and the state of support in different
compiler versions.
AFAICT, arm gcc got __builtin_bswap{32,64} support in 4.6,
and for the 16-bit version in 4.8.
This has a tiny benefit on vmlinux text size (gcc 4.6.4):
multi_v7_defconfig:
text data bss dec hex filename
3135208 188396 203344 3526948 35d124 vmlinux
multi_v7_defconfig with builtin_bswap:
text data bss dec hex filename
3135112 188396 203344 3526852 35d0c4 vmlinux
exynos_defconfig:
text data bss dec hex filename
4286605 360564 223172 4870341 4a50c5 vmlinux
exynos_defconfig with builtin_bswap:
text data bss dec hex filename
4286405 360564 223172 4870141 4a4ffd vmlinux
The savings come mostly from device-tree related code, and some
from drivers.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
akin to: http://comments.gmane.org/gmane.linux.kernel.cross-arch/16016
based on linux-next-20130128. Depends on commit "compiler-gcc{3,4}.h:
Use GCC_VERSION macro" by Daniel Santos <daniel.santos@pobox.com>,
currently in the akpm branch.
v4:
- undo v2-3's addition of ARCH_DEFINES_BUILTIN_BSWAP per Boris
and David - patch is much less intrusive :)
v3:
- moved out of uapi swab.h into arch/arm/include/asm/swab.h
- moved ARCH_DEFINES_BUILTIN_BSWAP help text into commit message
- moved GCC_VERSION >= 40800 ifdef into GCC_VERSION >= 40600 block
v2:
- at91 and lpd270 builds fixed by limiting to ARMv6 and above
(i.e., ARM cores that have support for the 'rev' instruction).
Otherwise, the compiler emits calls to libgcc's __bswapsi2 on
these ARMv4/v5 builds (and arch ARM doesn't link with libgcc).
All ARM defconfigs now have the same build status as they did
without this patch (some are broken on linux-next).
- move ARM check from generic compiler.h to arch ARM's swab.h.
- pretty sure it should be limited to __KERNEL__ builds
- add new ARCH_DEFINES_BUILTIN_BSWAP (see Kconfig help).
- if set, generic compiler header does not set HAVE_BUILTIN_BSWAPxx
- not too sure about this having to be a new CONFIG_, but it's hard
to find a place for it given linux/compiler.h doesn't include any
arch-specific files.
- move new selects to end of CONFIG_ARM's Kconfig select list,
as is done in David Woodhouse's original patchseries for ppc/x86.
arch/arm/include/asm/swab.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/include/asm/swab.h b/arch/arm/include/asm/swab.h
index 537fc9b..e56acff 100644
--- a/arch/arm/include/asm/swab.h
+++ b/arch/arm/include/asm/swab.h
@@ -34,5 +34,13 @@ static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
}
#define __arch_swab32 __arch_swab32
+#if GCC_VERSION >= 40600
+#define __HAVE_BUILTIN_BSWAP32__
+#define __HAVE_BUILTIN_BSWAP64__
+#if GCC_VERSION >= 40800
+#define __HAVE_BUILTIN_BSWAP16__
+#endif
+#endif
+
#endif
#endif
--
1.7.9.7
^ permalink raw reply related
* [PATCH] ARM: S3C24XX: Remove plat-s3c24xx directory in arch/arm/
From: Kukjin Kim @ 2013-02-01 1:02 UTC (permalink / raw)
To: linux-arm-kernel
This patch is for just moving plat-s3c24xx/*.c into mach-s3c24xx/, so
that we could remove plat-s3c24xx directory. But since the PLAT_S3C24XX
is used in drivers, the statement is not deleted and it will be sorted
out next time.
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
arch/arm/Kconfig | 1 -
arch/arm/Makefile | 2 +-
arch/arm/mach-s3c24xx/Kconfig | 104 +++++++++++++++++
arch/arm/mach-s3c24xx/Makefile | 14 ++-
.../{plat-s3c24xx => mach-s3c24xx}/clock-dclk.c | 3 +-
.../clock-s3c2410.c} | 3 +-
.../cpufreq-debugfs.c} | 3 +-
.../cpufreq-utils.c} | 3 +-
.../cpu-freq.c => mach-s3c24xx/cpufreq.c} | 3 +-
arch/arm/{plat-s3c24xx => mach-s3c24xx}/dma.c | 3 +-
.../iotiming-s3c2410.c} | 3 +-
.../iotiming-s3c2412.c} | 3 +-
arch/arm/{plat-s3c24xx => mach-s3c24xx}/irq.c | 0
arch/arm/plat-s3c24xx/Kconfig | 117 --------------------
arch/arm/plat-s3c24xx/Makefile | 27 -----
15 files changed, 126 insertions(+), 163 deletions(-)
rename arch/arm/{plat-s3c24xx => mach-s3c24xx}/clock-dclk.c (98%)
rename arch/arm/{plat-s3c24xx/s3c2410-clock.c => mach-s3c24xx/clock-s3c2410.c} (99%)
rename arch/arm/{plat-s3c24xx/cpu-freq-debugfs.c => mach-s3c24xx/cpufreq-debugfs.c} (98%)
rename arch/arm/{plat-s3c24xx/s3c2410-cpufreq-utils.c => mach-s3c24xx/cpufreq-utils.c} (96%)
rename arch/arm/{plat-s3c24xx/cpu-freq.c => mach-s3c24xx/cpufreq.c} (99%)
rename arch/arm/{plat-s3c24xx => mach-s3c24xx}/dma.c (99%)
rename arch/arm/{plat-s3c24xx/s3c2410-iotiming.c => mach-s3c24xx/iotiming-s3c2410.c} (99%)
rename arch/arm/{plat-s3c24xx/s3c2412-iotiming.c => mach-s3c24xx/iotiming-s3c2412.c} (99%)
rename arch/arm/{plat-s3c24xx => mach-s3c24xx}/irq.c (100%)
delete mode 100644 arch/arm/plat-s3c24xx/Kconfig
delete mode 100644 arch/arm/plat-s3c24xx/Makefile
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4350235..8b72d23 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1089,7 +1089,6 @@ source "arch/arm/mach-realview/Kconfig"
source "arch/arm/mach-sa1100/Kconfig"
source "arch/arm/plat-samsung/Kconfig"
-source "arch/arm/plat-s3c24xx/Kconfig"
source "arch/arm/mach-socfpga/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 0935dac..a554f75 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -204,7 +204,7 @@ plat-$(CONFIG_ARCH_S3C64XX) += samsung
plat-$(CONFIG_PLAT_IOP) += iop
plat-$(CONFIG_PLAT_ORION) += orion
plat-$(CONFIG_PLAT_PXA) += pxa
-plat-$(CONFIG_PLAT_S3C24XX) += s3c24xx samsung
+plat-$(CONFIG_PLAT_S3C24XX) += samsung
plat-$(CONFIG_PLAT_S5P) += samsung
plat-$(CONFIG_PLAT_SPEAR) += spear
plat-$(CONFIG_PLAT_VERSATILE) += versatile
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 5e17e1d..d4f1fea 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -9,6 +9,15 @@
if ARCH_S3C24XX
+config PLAT_S3C24XX
+ def_bool y
+ select ARCH_REQUIRE_GPIOLIB
+ select NO_IOPORT
+ select S3C_DEV_NAND
+ select IRQ_DOMAIN
+ help
+ Base platform code for any Samsung S3C24XX device
+
menu "SAMSUNG S3C24XX SoCs Support"
comment "S3C24XX SoCs"
@@ -89,6 +98,17 @@ config CPU_S3C2443
# common code
+config S3C2410_CLOCK
+ bool
+ help
+ Clock code for the S3C2410, and similar processors which
+ is currently includes the S3C2410, S3C2440, S3C2442.
+
+config S3C24XX_DCLK
+ bool
+ help
+ Clock code for supporting DCLK/CLKOUT on S3C24XX architectures
+
config S3C24XX_SMDK
bool
help
@@ -117,6 +137,22 @@ config S3C24XX_SETUP_TS
help
Compile in platform device definition for Samsung TouchScreen.
+config S3C24XX_DMA
+ bool "S3C2410 DMA support"
+ depends on ARCH_S3C24XX
+ select S3C_DMA
+ help
+ S3C2410 DMA support. This is needed for drivers like sound which
+ use the S3C2410's DMA system to move data to and from the
+ peripheral blocks.
+
+config S3C2410_DMA_DEBUG
+ bool "S3C2410 DMA support debug"
+ depends on ARCH_S3C24XX && S3C2410_DMA
+ help
+ Enable debugging output for the DMA code. This option sends info
+ to the kernel log, at priority KERN_DEBUG.
+
config S3C2410_DMA
bool
depends on S3C24XX_DMA && (CPU_S3C2410 || CPU_S3C2442)
@@ -129,6 +165,74 @@ config S3C2410_PM
help
Power Management code common to S3C2410 and better
+# low-level serial option nodes
+
+config CPU_LLSERIAL_S3C2410_ONLY
+ bool
+ default y if CPU_LLSERIAL_S3C2410 && !CPU_LLSERIAL_S3C2440
+
+config CPU_LLSERIAL_S3C2440_ONLY
+ bool
+ default y if CPU_LLSERIAL_S3C2440 && !CPU_LLSERIAL_S3C2410
+
+config CPU_LLSERIAL_S3C2410
+ bool
+ help
+ Selected if there is an S3C2410 (or register compatible) serial
+ low-level implementation needed
+
+config CPU_LLSERIAL_S3C2440
+ bool
+ help
+ Selected if there is an S3C2440 (or register compatible) serial
+ low-level implementation needed
+
+# gpio configurations
+
+config S3C24XX_GPIO_EXTRA
+ int
+ default 128 if S3C24XX_GPIO_EXTRA128
+ default 64 if S3C24XX_GPIO_EXTRA64
+ default 16 if ARCH_H1940
+ default 0
+
+config S3C24XX_GPIO_EXTRA64
+ bool
+ help
+ Add an extra 64 gpio numbers to the available GPIO pool. This is
+ available for boards that need extra gpios for external devices.
+
+config S3C24XX_GPIO_EXTRA128
+ bool
+ help
+ Add an extra 128 gpio numbers to the available GPIO pool. This is
+ available for boards that need extra gpios for external devices.
+
+# cpu frequency items common between s3c2410 and s3c2440/s3c2442
+
+config S3C2410_IOTIMING
+ bool
+ depends on CPU_FREQ_S3C24XX
+ help
+ Internal node to select io timing code that is common to the s3c2410
+ and s3c2440/s3c2442 cpu frequency support.
+
+config S3C2410_CPUFREQ_UTILS
+ bool
+ depends on CPU_FREQ_S3C24XX
+ help
+ Internal node to select timing code that is common to the s3c2410
+ and s3c2440/s3c244 cpu frequency support.
+
+# cpu frequency support common to s3c2412, s3c2413 and s3c2442
+
+config S3C2412_IOTIMING
+ bool
+ depends on CPU_FREQ_S3C24XX && (CPU_S3C2412 || CPU_S3C2443)
+ help
+ Intel node to select io timing code that is common to the s3c2412
+ and the s3c2443.
+
# cpu-specific sections
if CPU_S3C2410
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 1d67582..af53d27 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -14,7 +14,7 @@ obj- :=
# core
-obj-y += common.o
+obj-y += common.o irq.o
obj-$(CONFIG_CPU_S3C2410) += s3c2410.o
obj-$(CONFIG_S3C2410_CPUFREQ) += cpufreq-s3c2410.o
@@ -47,9 +47,21 @@ obj-$(CONFIG_PM) += pm.o irq-pm.o sleep.o
# common code
+obj-$(CONFIG_S3C24XX_DCLK) += clock-dclk.o
+obj-$(CONFIG_S3C24XX_DMA) += dma.o
+
+obj-$(CONFIG_S3C2410_CLOCK) += clock-s3c2410.o
+obj-$(CONFIG_S3C2410_CPUFREQ_UTILS) += cpufreq-utils.o
+
+obj-$(CONFIG_S3C2410_IOTIMING) += iotiming-s3c2410.o
+obj-$(CONFIG_S3C2412_IOTIMING) += iotiming-s3c2412.o
+
obj-$(CONFIG_S3C2443_COMMON) += common-s3c2443.o
obj-$(CONFIG_S3C2443_DMA) += dma-s3c2443.o
+obj-$(CONFIG_CPU_FREQ_S3C24XX) += cpufreq.o
+obj-$(CONFIG_CPU_FREQ_S3C24XX_DEBUGFS) += cpufreq-debugfs.o
+
#
# machine support
# following is ordered alphabetically by option text.
diff --git a/arch/arm/plat-s3c24xx/clock-dclk.c b/arch/arm/mach-s3c24xx/clock-dclk.c
similarity index 98%
rename from arch/arm/plat-s3c24xx/clock-dclk.c
rename to arch/arm/mach-s3c24xx/clock-dclk.c
index f95d326..1edd9b2 100644
--- a/arch/arm/plat-s3c24xx/clock-dclk.c
+++ b/arch/arm/mach-s3c24xx/clock-dclk.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-s3c24xx/clock-dclk.c
- *
+/*
* Copyright (c) 2004-2008 Simtec Electronics
* Ben Dooks <ben@simtec.co.uk>
* http://armlinux.simtec.co.uk/
diff --git a/arch/arm/plat-s3c24xx/s3c2410-clock.c b/arch/arm/mach-s3c24xx/clock-s3c2410.c
similarity index 99%
rename from arch/arm/plat-s3c24xx/s3c2410-clock.c
rename to arch/arm/mach-s3c24xx/clock-s3c2410.c
index 25dc4d4..641266f3 100644
--- a/arch/arm/plat-s3c24xx/s3c2410-clock.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2410.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/mach-s3c2410/clock.c
- *
+/*
* Copyright (c) 2006 Simtec Electronics
* Ben Dooks <ben@simtec.co.uk>
*
diff --git a/arch/arm/plat-s3c24xx/cpu-freq-debugfs.c b/arch/arm/mach-s3c24xx/cpufreq-debugfs.c
similarity index 98%
rename from arch/arm/plat-s3c24xx/cpu-freq-debugfs.c
rename to arch/arm/mach-s3c24xx/cpufreq-debugfs.c
index c7adad0..9b7b428 100644
--- a/arch/arm/plat-s3c24xx/cpu-freq-debugfs.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-debugfs.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-s3c24xx/cpu-freq-debugfs.c
- *
+/*
* Copyright (c) 2009 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks <ben@simtec.co.uk>
diff --git a/arch/arm/plat-s3c24xx/s3c2410-cpufreq-utils.c b/arch/arm/mach-s3c24xx/cpufreq-utils.c
similarity index 96%
rename from arch/arm/plat-s3c24xx/s3c2410-cpufreq-utils.c
rename to arch/arm/mach-s3c24xx/cpufreq-utils.c
index 43ea801..89e4e2b 100644
--- a/arch/arm/plat-s3c24xx/s3c2410-cpufreq-utils.c
+++ b/arch/arm/mach-s3c24xx/cpufreq-utils.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-s3c24xx/s3c2410-cpufreq-utils.c
- *
+/*
* Copyright (c) 2009 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks <ben@simtec.co.uk>
diff --git a/arch/arm/plat-s3c24xx/cpu-freq.c b/arch/arm/mach-s3c24xx/cpufreq.c
similarity index 99%
rename from arch/arm/plat-s3c24xx/cpu-freq.c
rename to arch/arm/mach-s3c24xx/cpufreq.c
index 4680799..5f181e7 100644
--- a/arch/arm/plat-s3c24xx/cpu-freq.c
+++ b/arch/arm/mach-s3c24xx/cpufreq.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-s3c24xx/cpu-freq.c
- *
+/*
* Copyright (c) 2006-2008 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks <ben@simtec.co.uk>
diff --git a/arch/arm/plat-s3c24xx/dma.c b/arch/arm/mach-s3c24xx/dma.c
similarity index 99%
rename from arch/arm/plat-s3c24xx/dma.c
rename to arch/arm/mach-s3c24xx/dma.c
index ba3e76c..aab6490 100644
--- a/arch/arm/plat-s3c24xx/dma.c
+++ b/arch/arm/mach-s3c24xx/dma.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-s3c24xx/dma.c
- *
+/*
* Copyright 2003-2006 Simtec Electronics
* Ben Dooks <ben@simtec.co.uk>
*
diff --git a/arch/arm/plat-s3c24xx/s3c2410-iotiming.c b/arch/arm/mach-s3c24xx/iotiming-s3c2410.c
similarity index 99%
rename from arch/arm/plat-s3c24xx/s3c2410-iotiming.c
rename to arch/arm/mach-s3c24xx/iotiming-s3c2410.c
index b1908e5..48ccfcf 100644
--- a/arch/arm/plat-s3c24xx/s3c2410-iotiming.c
+++ b/arch/arm/mach-s3c24xx/iotiming-s3c2410.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-s3c24xx/s3c2410-iotiming.c
- *
+/*
* Copyright (c) 2006-2009 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks <ben@simtec.co.uk>
diff --git a/arch/arm/plat-s3c24xx/s3c2412-iotiming.c b/arch/arm/mach-s3c24xx/iotiming-s3c2412.c
similarity index 99%
rename from arch/arm/plat-s3c24xx/s3c2412-iotiming.c
rename to arch/arm/mach-s3c24xx/iotiming-s3c2412.c
index 48eee39..9527342 100644
--- a/arch/arm/plat-s3c24xx/s3c2412-iotiming.c
+++ b/arch/arm/mach-s3c24xx/iotiming-s3c2412.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-s3c24xx/s3c2412-iotiming.c
- *
+/*
* Copyright (c) 2006-2008 Simtec Electronics
* http://armlinux.simtec.co.uk/
* Ben Dooks <ben@simtec.co.uk>
diff --git a/arch/arm/plat-s3c24xx/irq.c b/arch/arm/mach-s3c24xx/irq.c
similarity index 100%
rename from arch/arm/plat-s3c24xx/irq.c
rename to arch/arm/mach-s3c24xx/irq.c
diff --git a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig
deleted file mode 100644
index 3bb5c8f..0000000
--- a/arch/arm/plat-s3c24xx/Kconfig
+++ /dev/null
@@ -1,117 +0,0 @@
-# Copyright 2007 Simtec Electronics
-#
-# Licensed under GPLv2
-
-config PLAT_S3C24XX
- bool
- depends on ARCH_S3C24XX
- default y
- select ARCH_REQUIRE_GPIOLIB
- select NO_IOPORT
- select S3C_DEV_NAND
- select IRQ_DOMAIN
- help
- Base platform code for any Samsung S3C24XX device
-
-if PLAT_S3C24XX
-
-# low-level serial option nodes
-
-config CPU_LLSERIAL_S3C2410_ONLY
- bool
- default y if CPU_LLSERIAL_S3C2410 && !CPU_LLSERIAL_S3C2440
-
-config CPU_LLSERIAL_S3C2440_ONLY
- bool
- default y if CPU_LLSERIAL_S3C2440 && !CPU_LLSERIAL_S3C2410
-
-config CPU_LLSERIAL_S3C2410
- bool
- help
- Selected if there is an S3C2410 (or register compatible) serial
- low-level implementation needed
-
-config CPU_LLSERIAL_S3C2440
- bool
- help
- Selected if there is an S3C2440 (or register compatible) serial
- low-level implementation needed
-
-# code that is shared between a number of the s3c24xx implementations
-
-config S3C2410_CLOCK
- bool
- help
- Clock code for the S3C2410, and similar processors which
- is currently includes the S3C2410, S3C2440, S3C2442.
-
-config S3C24XX_DCLK
- bool
- help
- Clock code for supporting DCLK/CLKOUT on S3C24XX architectures
-
-# gpio configurations
-
-config S3C24XX_GPIO_EXTRA
- int
- default 128 if S3C24XX_GPIO_EXTRA128
- default 64 if S3C24XX_GPIO_EXTRA64
- default 16 if ARCH_H1940
- default 0
-
-config S3C24XX_GPIO_EXTRA64
- bool
- help
- Add an extra 64 gpio numbers to the available GPIO pool. This is
- available for boards that need extra gpios for external devices.
-
-config S3C24XX_GPIO_EXTRA128
- bool
- help
- Add an extra 128 gpio numbers to the available GPIO pool. This is
- available for boards that need extra gpios for external devices.
-
-config S3C24XX_DMA
- bool "S3C2410 DMA support"
- depends on ARCH_S3C24XX
- select S3C_DMA
- help
- S3C2410 DMA support. This is needed for drivers like sound which
- use the S3C2410's DMA system to move data to and from the
- peripheral blocks.
-
-config S3C2410_DMA_DEBUG
- bool "S3C2410 DMA support debug"
- depends on ARCH_S3C24XX && S3C2410_DMA
- help
- Enable debugging output for the DMA code. This option sends info
- to the kernel log, at priority KERN_DEBUG.
-
-# common code for s3c24xx based machines, such as the SMDKs.
-
-# cpu frequency items common between s3c2410 and s3c2440/s3c2442
-
-config S3C2410_IOTIMING
- bool
- depends on CPU_FREQ_S3C24XX
- help
- Internal node to select io timing code that is common to the s3c2410
- and s3c2440/s3c2442 cpu frequency support.
-
-config S3C2410_CPUFREQ_UTILS
- bool
- depends on CPU_FREQ_S3C24XX
- help
- Internal node to select timing code that is common to the s3c2410
- and s3c2440/s3c244 cpu frequency support.
-
-# cpu frequency support common to s3c2412, s3c2413 and s3c2442
-
-config S3C2412_IOTIMING
- bool
- depends on CPU_FREQ_S3C24XX && (CPU_S3C2412 || CPU_S3C2443)
- help
- Intel node to select io timing code that is common to the s3c2412
- and the s3c2443.
-
-endif
diff --git a/arch/arm/plat-s3c24xx/Makefile b/arch/arm/plat-s3c24xx/Makefile
deleted file mode 100644
index 9f60549c..0000000
--- a/arch/arm/plat-s3c24xx/Makefile
+++ /dev/null
@@ -1,27 +0,0 @@
-# arch/arm/plat-s3c24xx/Makefile
-#
-# Copyright 2007 Simtec Electronics
-#
-# Licensed under GPLv2
-
-obj-y :=
-obj-m :=
-obj-n :=
-obj- :=
-
-
-# Core files
-
-obj-y += irq.o
-obj-$(CONFIG_S3C24XX_DCLK) += clock-dclk.o
-
-obj-$(CONFIG_CPU_FREQ_S3C24XX) += cpu-freq.o
-obj-$(CONFIG_CPU_FREQ_S3C24XX_DEBUGFS) += cpu-freq-debugfs.o
-
-# Architecture dependent builds
-
-obj-$(CONFIG_S3C2410_CLOCK) += s3c2410-clock.o
-obj-$(CONFIG_S3C24XX_DMA) += dma.o
-obj-$(CONFIG_S3C2410_IOTIMING) += s3c2410-iotiming.o
-obj-$(CONFIG_S3C2412_IOTIMING) += s3c2412-iotiming.o
-obj-$(CONFIG_S3C2410_CPUFREQ_UTILS) += s3c2410-cpufreq-utils.o
--
1.7.10.4
^ permalink raw reply related
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Peter Chen @ 2013-02-01 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130131102913.GA6937@pengutronix.de>
On Thu, Jan 31, 2013 at 11:29:13AM +0100, Sascha Hauer wrote:
> On Thu, Jan 31, 2013 at 10:05:44AM +0800, Peter Chen wrote:
> > On Wed, Jan 30, 2013 at 03:00:15PM +0100, Sascha Hauer wrote:
> > > On Wed, Jan 30, 2013 at 10:06:28AM +0800, Peter Chen wrote:
> > > > On Tue, Jan 29, 2013 at 01:55:04PM +0200, Alexander Shishkin wrote:
> > > > > Sascha Hauer <s.hauer@pengutronix.de> writes:
> > > > >
> > > > > > From: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > > > > >
> > > > > > This adds two little devicetree helper functions for determining the
> > > > > > dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
> > > > > > the devicetree.
> > > > > >
> > > > > > Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > > > > > Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
> > > > > > ---
> > > > > >
> > > > > > The properties and their values have been taken from the fsl-mph-dr driver.
> > > > > > This binding is also documented (though currently not used) for the tegra
> > > > > > ehci driver (Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt).
> > > > > > This is a first attempt to parse these bindings at a common place so that
> > > > > > others can make use of it.
> > > > > >
> > > > > > Basically I want to know whether this binding is recommended for new drivers
> > > > > > since normally the devicetree uses '-' instead of '_', and maybe there are
> > > > > > other problems with it.
> > > > > >
> > > > > > I need this binding for the chipidea driver. I suspect that the fsl-mph-dr
> > > > > > driver also really handles a chipidea core.
> > > > >
> > > > > As far as I know, it is a chipidea core. Adding Peter to Cc list, he can
> > > > > probably confirm.
> > > >
> > > > The fsl-mph-dr can't be used for chipdiea as it handles three platform
> > > > drivers for three roles (peripheral , host, otg). But chipidea only has
> > > > two platform drivers, one is the chipidea core, the other is related
> > > > controller wrapper.
> > >
> > > What do you mean by 'three platform drivers'? That's only how the driver
> > > is built, no? I was talking about the hardware the fsl-mph-dr driver
> > > handles which definitely smells like chipidea.
> >
> > It creates host/device/otg platform device according to dr_mode from
> > the device tree.
>
> Again, that's software specific. What I'd like to know is whether the
> *hardware* could be handled by the chipidea driver.
not understand u, you mean the DT information at there? Those DT information
may not be used for i.mx hardware.
>
> Sascha
>
>
> --
> 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 |
>
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH] ARM:mach-msm: seting tail NUL after strncpy
From: Chen Gang @ 2013-02-01 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <510997DD.8080600@codeaurora.org>
? 2013?01?31? 05:59, Stephen Boyd ??:
> On 01/30/13 13:33, David Brown wrote:
>> I believe that Stephen Boyd is putting some significant work into this
>> code. Stephen, can you see if this bug is still in your current
>> version of the code, and make sure that it is fixed there?
>>
>
> This entire file is deleted in my set of patches that moves the current
> MSM clock code to the common clock framework.
>
ok, thank you.
:-)
--
Chen Gang
Asianux Corporation
^ 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