* Booting vanilla kernel on the beaglebone
From: Richard Cochran @ 2012-10-09 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9F27CE@DBDE01.ent.ti.com>
On Tue, Oct 09, 2012 at 04:27:03PM +0000, N, Mugunthan V wrote:
>
> I have implemented the CPTS hardware clock and will be submitting the
> patches soon to TI's kernel repo and also planning to submit the patches
> to Mainline kernel mailing lists soon.
I did see the stuff you added into arago for the DM814x, but it didn't
look correct to me.
Anyhow, I went ahead and wrote my own from stratch, based on the
AM335XPSP_04.06.00.08 branch, and it is working well. So go ahead and
post your driver, and I'll post mine, and we can go from there.
Right now, I can't for the life of me get a mainline kernel to boot on
the beaglebone, so I think we should focus on getting the mainline
support on the am335x stable before adding new drivers.
Thanks,
Richard
^ permalink raw reply
* Booting vanilla kernel on the beaglebone
From: Richard Cochran @ 2012-10-09 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB39F42@DBDE01.ent.ti.com>
On Tue, Oct 09, 2012 at 12:17:45PM +0000, Hiremath, Vaibhav wrote:
> Just with recent u-boot.
So this just doesn't work at all for me. It hangs just after:
U-Boot# bootm 81000000 - 80000000
## Booting kernel from Legacy Image at 81000000 ...
Image Name: Linux-3.6.0-next-20121009
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3845136 Bytes = 3.7 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 80000000
Booting using the fdt blob at 0x80000000
Loading Kernel Image ... OK
OK
Loading Device Tree to 8fe66000, end 8fe6a433 ... OK
Starting kernel ...
(That was with linux-next-b066f61 from today.)
I do have a Rev A6 board. Could that be an issue?
You said that you are carrying along some patches (like the
defconfig). Are you sure every needed patch is now upstream?
Thanks,
Richard
^ permalink raw reply
* ARM: hw_breakpoint: silent EPERM when setting ARM_DSCR_MDBGEN on ARM_DEBUG_ARCH_V7_ECP14
From: Valentin Pistol @ 2012-10-09 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120918100438.GC32204@mudshark.cambridge.arm.com>
Will,
On Tue, Sep 18, 2012 at 3:04 AM, Will Deacon <will.deacon@arm.com> wrote:
>
> On Fri, Sep 14, 2012 at 09:08:24AM +0100, Valentin Pistol wrote:
> > Is there a reliable way to determine that they are locked down?
> > Any particular register/bit I can check to confirm?
>
> You can take a look at the DBGAUTHSTATUS register and try to determine the
> signal values for SPNIDEN, DBGEN and NIDEN.
DBGAUTHSTATUS=0xaa confirming DBGEN is LOW. Since then I found out
that there are two types of OMAP devices:
GP (General Purpose) and HS (High Security) and supposedly Debug
Capabilities are only available on GP devices.
Thus, I ordered a Pandaboard ES with OMAP4460 and tested it with a
prebuilt Ubuntu 12.04 image.
After boot monitor mode is still not set, the DSCR reads the same
0x01030002 just as with the previous Galaxy Nexus.
I contacted TI and they seem to say hw breakpoints/watchpoints are
available on Pandaboard but they are confused about monitor mode,
saying it's not available on Pandaboard GP.
See http://e2e.ti.com/support/omap/f/849/p/216276/770995.aspx for the
discussion.
Isn't monitor mode and DBGEN on HIGH required for access to
breakpoints/watchpoints?
Maybe they are thinking about Secure Monitor Mode and TrustZone which
is not related?
Have you used a Pandaboard and can comment on how to enable the
breakpoints/watchpoints?
Could you also mention a specific development board that you are using
and recommend for access to these features?
>
> > > Completely untested patch below, please let me know how you get on...
> >
> > Looks good, I'll give it a try.
>
> Great. Let me know if it helps and, if so, I'll merge it.
Sorry I wasn't able to directly apply your patch to the specific
Android kernel version I was using.
Manually merging the code seems to perform as expected.
Thanks a lot for your help,
Valentin
^ permalink raw reply
* [GIT PULL 0/9] ARM architecture fixes for 3.7
From: Stefano Stabellini @ 2012-10-09 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009160814.GH4625@n2100.arm.linux.org.uk>
On Tue, 9 Oct 2012, Russell King - ARM Linux wrote:
> On Tue, Oct 09, 2012 at 05:22:54PM +0200, Arnd Bergmann wrote:
> > Here are some patches that belong into your domain, I hope you can
> > just send the lot to Linus the next time you send other patches.
> >
> > These bug fixes all address problems found with automated build testing.
> > Some of them have been around for a long time, other bugs are
> > regressions since the merge window.
>
> Apart from the sliced off comment in one commit (which XEN people need
> to confirm they're happy with the final version), I think these are
> otherwise fine... I'll hold off pulling them until that can be fixed.
I am OK with the comment being truncated.
I am going to submit a better fix for the Kconfig issues separately
anyway, on top of this patch.
^ permalink raw reply
* [PATCH] mmc: mxs: fix build regression from mismerge
From: Marek Vasut @ 2012-10-09 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877gqzabjy.fsf@octavius.laptop.org>
Dear Chris Ball,
> Hi,
>
> On Tue, Oct 09 2012, Arnd Bergmann wrote:
> > From all I can tell, the patches
> >
> > fc108d24 "mmc: mxs-mmc: fix deadlock caused by recursion loop"
> > 829c1bf4 "mmc: spi: Pull out parts shared between MMC and SPI"
> >
> > came in through separate branches and cause this build error when
> > combined.
[...]
>
> I'll send Marek's change to Linus once the main MMC merge has been pulled.
> Thanks,
>
> - Chris.
Thanks! Sorry from my previous reply from Android phone, I just saw what
horrible email it generated :-(
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 01/11] fsmc/nand:FIX: Change the type for regs to void __iomem *
From: viresh kumar @ 2012-10-09 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c30a9228d4bff7dbedd5d011f84c79c324736452.1349778820.git.vipin.kumar@st.com>
On Tue, Oct 9, 2012 at 4:14 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
> Signed-off-by: Vipin Kumar <vipin.kumar@st.com>
> ---
> drivers/mtd/nand/fsmc_nand.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
> index 38d2624..e96d7d1 100644
> --- a/drivers/mtd/nand/fsmc_nand.c
> +++ b/drivers/mtd/nand/fsmc_nand.c
> @@ -361,7 +361,7 @@ static void fsmc_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
> struct nand_chip *this = mtd->priv;
> struct fsmc_nand_data *host = container_of(mtd,
> struct fsmc_nand_data, mtd);
> - void *__iomem *regs = host->regs_va;
> + void __iomem *regs = host->regs_va;
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH 02/11] fsmc/nand: Rearrange the fsmc_nand_data structure and update comments
From: viresh kumar @ 2012-10-09 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2aa2a9c00bcfa62605edfab8fb4c29448612ced3.1349778820.git.vipin.kumar@st.com>
On Tue, Oct 9, 2012 at 4:14 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
> Signed-off-by: Vipin Kumar <vipin.kumar@st.com>
> ---
> drivers/mtd/nand/fsmc_nand.c | 51 ++++++++++++++++++++++++++------------------
> 1 file changed, 30 insertions(+), 21 deletions(-)
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH 04/11] fsmc/nand: Accept nand timing parameters via DT
From: viresh kumar @ 2012-10-09 17:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54eda40e56e8ea02ed9c5332ca6d3fb90d617cc7.1349778821.git.vipin.kumar@st.com>
On Tue, Oct 9, 2012 at 4:14 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
> diff --git a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
> +- nand-timings-enabled: Indicates if the timing parameters are passed
> + via DT
> +- nand-timings,tclr:
> +- nand-timings,tar:
> +- nand-timings,thiz:
> +- nand-timings,thold:
> +- nand-timings,twait:
> +- nand-timings,tset: All these timing parameters come from the actual
> + nand device specification. Each of this represents a number of time
> + period of hclk ie a number 4 in thold with hclk = 166MHz means that
> + thold = (1000 / 166) * 4 ns = 24.09ns
Are they specific to fsmc controller or nand memory type? If to fsmc then
please add my
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
else
I would suggest to add these to mtd bindings instead, so that same fields
can be used by multiple drivers....
Similar approach is used for mmc controllers too.
^ permalink raw reply
* Booting vanilla kernel on the beaglebone
From: Hiremath, Vaibhav @ 2012-10-09 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009165405.GB6870@netboy.at.omicron.at>
On Tue, Oct 09, 2012 at 22:24:05, Richard Cochran wrote:
> On Tue, Oct 09, 2012 at 12:17:45PM +0000, Hiremath, Vaibhav wrote:
> > Just with recent u-boot.
>
> So this just doesn't work at all for me. It hangs just after:
>
> U-Boot# bootm 81000000 - 80000000
> ## Booting kernel from Legacy Image at 81000000 ...
> Image Name: Linux-3.6.0-next-20121009
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 3845136 Bytes = 3.7 MiB
> Load Address: 80008000
> Entry Point: 80008000
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 80000000
> Booting using the fdt blob at 0x80000000
> Loading Kernel Image ... OK
> OK
> Loading Device Tree to 8fe66000, end 8fe6a433 ... OK
>
> Starting kernel ...
>
> (That was with linux-next-b066f61 from today.)
>
> I do have a Rev A6 board. Could that be an issue?
>
> You said that you are carrying along some patches (like the
> defconfig). Are you sure every needed patch is now upstream?
>
Can you make sure that you have below patches, which I have already
submitted to linux-omap and expected to get merged for rc1.
https://patchwork.kernel.org/patch/1499271/
https://patchwork.kernel.org/patch/1569231/
These patches addresses integration related issues which occurs during merge
window.
Please note that, these patches are already submitted to list and expected
to get merged for rc1.
Thanks,
Vaibhav
> Thanks,
> Richard
>
^ permalink raw reply
* [GIT PULL] Disintegrate UAPI for arm64 [ver #2]
From: Catalin Marinas @ 2012-10-09 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21110.1349774113@warthog.procyon.org.uk>
On Tue, Oct 09, 2012 at 10:15:13AM +0100, David Howells wrote:
> David Howells (1):
> UAPI: (Scripted) Disintegrate arch/arm64/include/asm
It still fails on arm64. The reason is that I had a __SYSCALL_COMPAT
guard to provide either the 32-bit syscalls or the 64-bit (generic) ones
via asm/unistd.h. With this change:
> diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
> index 8f03dee..3d43b19 100644
> --- a/arch/arm64/include/asm/unistd.h
> +++ b/arch/arm64/include/asm/unistd.h
> @@ -13,13 +13,7 @@
> * You should have received a copy of the GNU General Public License
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
> -
> -#ifndef __SYSCALL_COMPAT
> -#include <asm-generic/unistd.h>
> -#endif
> -
> -#ifdef __KERNEL__
> #ifdef CONFIG_COMPAT
> #include <asm/unistd32.h>
> #endif
> -#endif
> +#include <uapi/asm/unistd.h>
the guard disappears and I get conflicting entries between unistd32.h
and unistd.h.
The solution is to either keep the __SYSCALL_COMPAT guard in place or
rename all the __NR_* macros in unistd32.h to __NR_compat_* and include
unistd32.h explicitly where needed (kernel-only header anyway). Since
the arm64 kernel would not export 32-bit headers, I would go with the
second solution (tried it already). But you need to re-generate the
arm64 headers again.
BTW, I see the script generated some pretty much empty
uapi/asm/unistd.h. Is it possible to using something like Kbuild and
just add "generic-y += ..." to just point it to the
include/uapi/asm-generic header?
--
Catalin
^ permalink raw reply
* [PATCH 6/9] ARM: pass -marm to gcc by default for both C and assembler
From: Dave Martin @ 2012-10-09 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-7-git-send-email-arnd@arndb.de>
On Tue, Oct 09, 2012 at 05:23:00PM +0200, Arnd Bergmann wrote:
> The Linaro cross toolchain and probably others nowadays default to
> building in THUMB2 mode. When building a kernel for a CPU that does
> not support THUMB2, the compiler complains about incorrect flags.
> We can work around this by setting -marm for all non-T2 builds.
>
> Without this patch, building assabet_defconfig results in:
>
> usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
> arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
> firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
> (and many more)
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Nicolas Pitre <nico@linaro.org>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Dave Martin <dave.martin@linaro.org>
This looks like a sensible fix, but it could be worth amending the
commit message to explain what was fixed, since it took me a moment or
two to puzzle out why the code this patch removes was broken. Maybe
something like:
-marm was passed unconditionally for C files previously, but nothing was
passed to the gcc frontend when processing .S files, resulting in a
warning. The assembler never defaults to ARM unless -Wa,-mthumb is
supplied explicitly, so the files were still assembled correctly.
This patch makes sure that -marm is passed for .S files too, and also
avoids the redundant gcc -marm -mthumb in Thumb kernels.
Preferably with that (or equivalent):
Acked-by: Dave Martin <dave.martin@linaro.org>
> ---
> arch/arm/Makefile | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index f023e3a..5f914fc 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -21,8 +21,6 @@ endif
> OBJCOPYFLAGS :=-O binary -R .comment -S
> GZFLAGS :=-9
> #KBUILD_CFLAGS +=-pipe
> -# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
> -KBUILD_CFLAGS +=$(call cc-option,-marm,)
>
> # Never generate .eh_frame
> KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
> @@ -105,17 +103,20 @@ endif
> ifeq ($(CONFIG_THUMB2_KERNEL),y)
> AFLAGS_AUTOIT :=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)
> AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
> -CFLAGS_THUMB2 :=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
> -AFLAGS_THUMB2 :=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb
> +CFLAGS_ISA :=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
> +AFLAGS_ISA :=$(CFLAGS_ISA) -Wa$(comma)-mthumb
> # Work around buggy relocation from gas if requested:
> ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
> CFLAGS_MODULE +=-fno-optimize-sibling-calls
> endif
> +else
> +CFLAGS_ISA :=$(call cc-option,-marm,)
> +AFLAGS_ISA :=$(CFLAGS_ISA)
> endif
>
> # Need -Uarm for gcc < 3.x
> -KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_THUMB2) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> -KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_THUMB2) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
> +KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
> +KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
>
> CHECKFLAGS += -D__arm__
>
> --
> 1.7.10
>
^ permalink raw reply
* [PATCH 05/11] fsmc: Implement ready/busy through gpio pin
From: viresh kumar @ 2012-10-09 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e455d98df0fba37e8b7ecd7e72d510a05f23d2ba.1349778821.git.vipin.kumar@st.com>
On Tue, Oct 9, 2012 at 4:14 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
> diff --git a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
> +- st,ready-busy: Should contain either of "rb-gpio" or "rb-wait". When
> + this property is not defined, the default is to use rb-wait.
> +- st,rb-gpios: When the st,ready-busy is defined as "rb-gpio", a gpio
> + pin number is defined in this property
Why st,*** maybe fsmc,***?
Would be better if you update the example too in this file.
> diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
> + * @rb_pin: Ready/Busy data
> + struct fsmc_rbpin *rbpin;
comment variable mismatch :(
> -static void fsmc_nand_setup(void __iomem *regs, uint32_t bank,
> - uint32_t busw, struct fsmc_nand_timings *timings)
> +static void fsmc_nand_setup(void __iomem *regs, uint32_t bank, uint32_t busw,
> + struct fsmc_nand_timings *timings,
> + struct fsmc_rbpin *rbpin)
Can function prototype come in two lines instead of three?
> @@ -1049,6 +1075,8 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
> + if (host->rbpin->use_pin == FSMC_RB_GPIO) {
> + ret = gpio_request(host->rbpin->gpio_pin, "fsmc-rb");
> + if (ret < 0) {
> + dev_err(&pdev->dev, "gpio request fail: %d\n",
> + host->rbpin->gpio_pin);
> + goto err_gpio_req;
> + }
> + }
Don't you want to set its direction to input?
^ permalink raw reply
* [PATCH] [ARM] Use AT() in the linker script to create correct program headers
From: Jason Gunthorpe @ 2012-10-09 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008102413.GC2302@linaro.org>
On Mon, Oct 08, 2012 at 11:24:13AM +0100, Dave Martin wrote:
> Partly this came from some side speculation about whether we could do
> things like privileged read-only permissions on newer CPUs, for preventing
> unintended or undesired writes to the kernel's code or read-only data.
Some other arches page protect the kernel, but that tends to be at
odds with the desire to use huge pages for the kernel mapping, and
independent of the load headers..
Jason
^ permalink raw reply
* [PATCH 07/11] fsmc/nand: Provide contiguous buffers to dma
From: viresh kumar @ 2012-10-09 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b88c853b3691338fae037f569917fc300cd6032.1349778821.git.vipin.kumar@st.com>
On Tue, Oct 9, 2012 at 4:14 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
> diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
> @@ -675,7 +676,8 @@ static void fsmc_read_buf_dma(struct mtd_info *mtd, uint8_t *buf, int len)
> struct fsmc_nand_data *host;
>
> host = container_of(mtd, struct fsmc_nand_data, mtd);
> - dma_xfer(host, buf, len, DMA_FROM_DEVICE);
> + dma_xfer(host, host->dma_buf, len, DMA_FROM_DEVICE);
> + memcpy(buf, (const void *)host->dma_buf, len);
Ahh.. Too much overhead. Can't you do something better here?
- DMA can be done to user buffers too, Pratyush has done some work in
past on this.
- There must be some other way of sharing kernel buffer to user space.
--
viresh
^ permalink raw reply
* [PATCH 08/11] fsmc/nand: Use relaxed variants of io accessors
From: viresh kumar @ 2012-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <88484dbae96f7db42ce615552a4c758844a5e6cc.1349778821.git.vipin.kumar@st.com>
On Tue, Oct 9, 2012 at 4:14 PM, Vipin Kumar <vipin.kumar@st.com> wrote:
> Use relaxed variants of readl/writel accessors. readl/writel io accessors use
> explicit dsb instruction which causes stalls in the processor core resulting
> several cycles of delay for each access
>
> Use relaxed variants where ever possible. This also results in an improved
> read/write performance.
Good change.
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH 0/3] new ARM-soc warning fixes
From: Olof Johansson @ 2012-10-09 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796861-31164-1-git-send-email-arnd@arndb.de>
On Tue, Oct 09, 2012 at 05:34:18PM +0200, Arnd Bergmann wrote:
> Hi Olof,
>
> Here are three more fixes that I'd like to merge through the arm-soc
> as time permits. All of them should be completely harmless and they
> only fix harmless gcc warnings.
>
> I don't know what your plans are for sending the next fixes branch.
> I've uploaded these into a new "fixes2" branch on top of the patches
> that are already in "fixes". We can either send them all together,
> or you send the ones that are already queued first and these ones
> with the next batch. Feel free to rebase if necessary.
I've pulled it in and will send up with fixes tonight (Tony has OMAP
fixes coming, others might too).
-Olof
^ permalink raw reply
* [kvmarm] [PATCH v2 12/14] KVM: ARM: VFP userspace interface
From: Peter Maydell @ 2012-10-09 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001091125.49198.90819.stgit@ubuntu>
On 1 October 2012 10:11, Christoffer Dall <c.dall@virtualopensystems.com> wrote:
> From: Rusty Russell <rusty.russell@linaro.org>
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1765,6 +1765,12 @@ ARM 64-bit CP15 registers have the following id bit patterns:
> ARM CCSIDR registers are demultiplexed by CSSELR value:
> 0x4002 0000 0011 00 <csselr:8>
>
> +ARM 32-bit VFP control registers have the following id bit patterns:
> + 0x4002 0000 0012 1 <selector:3>
> +
> +ARM 64-bit FP registers have the following id bit patterns:
> + 0x4002 0000 0012 0 <selector:3>
> +
In the other entries in this section, <foo:3> indicates a 3 bit field.
But I think for these two it's trying to indicate a 3 byte field.
Compare the include file constants:
+#define KVM_REG_ARM_VFP (0x0012 <<
KVM_REG_ARM_COPROC_SHIFT)
+#define KVM_REG_ARM_VFP_MASK 0x000000000000FFFF
+#define KVM_REG_ARM_VFP_BASE_REG 0x0
+#define KVM_REG_ARM_VFP_FPSID 0x1000
+#define KVM_REG_ARM_VFP_FPSCR 0x1001
so eg the first control register is
0x4002 0000 0012 1000
and the first D reg is
0x4002 0000 0012 0000
So my guess is these should be <selector:12>
(or possibly even something slightly more specific than 'selector'
like '<regno:12>' ?)
-- PMM
^ permalink raw reply
* [kvmarm] [PATCH v2 12/14] KVM: ARM: VFP userspace interface
From: Christoffer Dall @ 2012-10-09 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA8zLr5mPYnd6EzaxyugASWPzvY4RE6LiE-K2uRRGWtFZA@mail.gmail.com>
On Tue, Oct 9, 2012 at 2:11 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 1 October 2012 10:11, Christoffer Dall <c.dall@virtualopensystems.com> wrote:
>> From: Rusty Russell <rusty.russell@linaro.org>
>> --- a/Documentation/virtual/kvm/api.txt
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -1765,6 +1765,12 @@ ARM 64-bit CP15 registers have the following id bit patterns:
>> ARM CCSIDR registers are demultiplexed by CSSELR value:
>> 0x4002 0000 0011 00 <csselr:8>
>>
>> +ARM 32-bit VFP control registers have the following id bit patterns:
>> + 0x4002 0000 0012 1 <selector:3>
>> +
>> +ARM 64-bit FP registers have the following id bit patterns:
>> + 0x4002 0000 0012 0 <selector:3>
>> +
>
> In the other entries in this section, <foo:3> indicates a 3 bit field.
> But I think for these two it's trying to indicate a 3 byte field.
> Compare the include file constants:
>
> +#define KVM_REG_ARM_VFP (0x0012 <<
> KVM_REG_ARM_COPROC_SHIFT)
> +#define KVM_REG_ARM_VFP_MASK 0x000000000000FFFF
> +#define KVM_REG_ARM_VFP_BASE_REG 0x0
> +#define KVM_REG_ARM_VFP_FPSID 0x1000
> +#define KVM_REG_ARM_VFP_FPSCR 0x1001
>
> so eg the first control register is
> 0x4002 0000 0012 1000
> and the first D reg is
> 0x4002 0000 0012 0000
>
> So my guess is these should be <selector:12>
> (or possibly even something slightly more specific than 'selector'
> like '<regno:12>' ?)
>
right you are, I'll modify this.
Thanks,
-Christoffer
^ permalink raw reply
* [Xen-devel] [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Arnd Bergmann @ 2012-10-09 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349799035.21847.222.camel@zakaz.uk.xensource.com>
On Tuesday 09 October 2012, Ian Campbell wrote:
> On Tue, 2012-10-09 at 16:39 +0100, Arnd Bergmann wrote:
> > On Tuesday 09 October 2012, Ian Campbell wrote:
> > > > * The tmem hypercall is not available on ARM
> > > >
> > > > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > >
> > > missing the end of this sentence?
> >
> > Right, I meant to say
> >
> > * ARMv6 does not support cmpxchg on 16-bit words that are used in the
> > Xen grant table code, so we must ensure that Xen support is only built
> > on ARMv7-only kernels not combined ARMv6/v7 kernels.
> >
> > This should be fixed differently in the future.
>
> Is this is a build time failure because gcc/gas/etc refuses to generate
> these instructions if it is configured for v6?
>
> I ask because if it is only a runtime issue then we can reason that if
> we are running Xen specific grant table code, then we must be running on
> Xen and therefore must necessarily be running on a v7 (because Xen only
> support v7+virt extensions) even if the kernel happens to be capable of
> running on v6 too.
The underlying reason of course is that ARMv6 doesn't have those
instructions. The symptom you see is a link error because gcc emits
a reference to the (intentionally missing) __bad_cmpxchg() function
from
static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
unsigned long new, int size)
{
unsigned long oldval, res;
switch (size) {
#ifndef CONFIG_CPU_V6 /* min ARCH >= ARMv6K */
case 1:
...
break;
case 2:
...
break;
#endif
case 4:
...
break;
default:
__bad_cmpxchg(ptr, size);
oldval = 0;
}
return oldval;
}
The possible solutions I can see for this are:
* change the grant table format to use 32 bits for the flags on ARM
* change the code to always cmpxchg the entire 32 bit word including the flags.
* implement your own cmpxchg wrapper that may be implemented using a spinlock
rather than cmpxchg if ARMv6 is enabled.
Arnd
^ permalink raw reply
* [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Arnd Bergmann @ 2012-10-09 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1210091630170.29539@kaball.uk.xensource.com>
On Tuesday 09 October 2012, Stefano Stabellini wrote:
> > config XEN
> > bool "Xen guest support on ARM (EXPERIMENTAL)"
> > depends on EXPERIMENTAL && ARM && OF
> > + depends on !CPU_V6
> > help
> > Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
>
> Considering that we rely on the virtualization extensions, this one can
> be:
>
> depends on CPU_V7
>
> The rest looks fine. I can submit a second patch to change !CPU_V6 into
> CPU_V7 later, if you prefer.
CPU_V6 and CPU_V7 are not exclusive, I saw the problem when building a
combined kernel for both V6 and V7. The code also needs to depend on ARMv7
with virtualization extensions, but that is a different issue. We don't
actually have a configuration symbol for that yet, as far as I can tell.
Arnd
^ permalink raw reply
* [PATCH] mmc: mxs: fix build regression from mismerge
From: Arnd Bergmann @ 2012-10-09 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877gqzabjy.fsf@octavius.laptop.org>
On Tuesday 09 October 2012, Chris Ball wrote:
> I'll send Marek's change to Linus once the main MMC merge has been pulled.
Ok, thanks!
Arnd
^ permalink raw reply
* [PATCH] [ARM] Use AT() in the linker script to create correct program headers
From: Jason Gunthorpe @ 2012-10-09 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121008104649.GD2302@linaro.org>
On Mon, Oct 08, 2012 at 11:46:49AM +0100, Dave Martin wrote:
> > Yes, but we still need rely on complex code like I2C/MTD to create a
> > correct DTB, which again puts us back to patching the kernel for that
> > functionality.
>
> I'm still confused as to where this complexity is coming from.
>
> If you need to run some complex I2C and MTD code to generate the DT, what
> is that code doing? If it is probing to get the information, then can you
> avoid putting the info in the DT at all? Primarily the DT is to describe
> those aspects of the hardware which can't be probed.
At manufacturing the unit is programmed with a small datastructure that
contains all the unique ID's (MAC addresses, etc), manufacturing
variations (ie vendor A or B was used for a socket) and other
ancillary data.
So a fair amount of I2C and MTD stack is required just to fetch this
structure - a full CFI probe, for instance, is needed in the NOR flash
case just to locate the structure.
Once read, things like MAC addresses are copied into the DTB, and
certain sections of the DTB are NOP'd out - we have stanzas for chip
vendor A and vendor B, the one that was not put on the board is
replaced with NOP.
Similar to the A/B fix, a further fixup is done based on a runtime
probe of the programmable devices to learn their current
configuration/memory map.
It seems desirable to present a complete/correct DTB to the kernel,
it doesn't seem there are great places to hook in custom discovery
procedures.
>From a maintenance perspective we already have to test/etc the kernel
code for all of this, we don't want to do that twice by duplicating
this stuff outside the kernel.
> Otherwise, you that have a few static configurations: you could have one
> pre-baked DT per hardware platform, and choose the correct one once you
> have detected the platform.
We do that too, for instance the PPC kernel we build supports 4
different circuit boards, each served by a separate DTB, that needs a
fixup pass.
I think the biggest DTB describes about 49 devices..
> > Where the 'dev tree provider' would use the stored bootloader
> > registers and any other information to return the proper DTB.
>
> It would need developing a bit, but something like that might be
> possible -- it should probably be discussed via devicetree-discuss.
>
> If it is doing anything less trivial than picking a pre-baked DT, the
> rationale would need to be carefully argued.
I'm not sure there is a great interest in this? What are other folks
working on production embedded stuff doing? I suppose that will be
more clear as device tree is rolled out.
Jason
^ permalink raw reply
* [PATCH 2/6] ARM: EXYNOS5: DT Support for SATA and SATA PHY
From: Olof Johansson @ 2012-10-09 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349783332-18467-3-git-send-email-vasanthananthan@gmail.com>
Hi,
On Tue, Oct 09, 2012 at 05:18:48PM +0530, Vasanth Ananthan wrote:
> This patch adds Device Nodes for SATA and SATA PHY device.
>
> Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
> ---
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 11 +++++++++++
> arch/arm/boot/dts/exynos5250.dtsi | 20 ++++++++++++++++++++
> arch/arm/mach-exynos/include/mach/map.h | 7 +++++++
> arch/arm/mach-exynos/mach-exynos5-dt.c | 6 ++++++
> 4 files changed, 44 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index 8a5e348..bb262ce 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -48,6 +48,17 @@
> };
> };
>
> + i2c at 121D0000 {
> + samsung,i2c-sda-delay = <100>;
> + samsung,i2c-max-bus-freq = <40000>;
> + samsung,i2c-slave-addr = <0x38>;
Whitespace is off above.
> +
> + sataphy at 70 {
sata-phy would be a more conventional name.
> + compatible = "samsung,i2c-phy";
i2c-phy? Seems like an odd choice of name. What is this device?
> + reg = <0x38>;
70 is unit address but here it's 0x38? One of them is wrong. No need for a unit
address if it's a unique name, by the way.
> + };
> + };
> +
> i2c at 12C80000 {
> status = "disabled";
> };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index 004aaa8..5a47a8f 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -88,6 +88,18 @@
> interrupts = <0 54 0>;
> };
>
> + sata at 122F0000 {
> + compatible = "samsung,exynos-sata-ahci";
> + reg = <0x122F0000 0x1ff>;
> + interrupts = <0 115 0>;
More whitespace damage. And need binding.
> + };
> +
> + sata-phy at 12170000 {
> + compatible = "samsung,exynos-sata-phy";
> + reg = <0x12170000 0x1ff>;
> + };
Should have binding too. How does this relate to the i2c device above.
> +
> i2c at 12C60000 {
> compatible = "samsung,s3c2440-i2c";
> reg = <0x12C60000 0x100>;
> @@ -152,6 +164,13 @@
> #size-cells = <0>;
> };
>
> + i2c at 121D0000 {
> + compatible = "samsung,s3c2440-sataphy-i2c";
Is this a unique i2c controller, or is it just another one like the others on
the chip? If it's the latter, it should use the regular compatible string.
> + reg = <0x121D0000 0x100>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> spi_0: spi at 12d20000 {
> compatible = "samsung,exynos4210-spi";
> reg = <0x12d20000 0x100>;
> @@ -460,4 +479,5 @@
> #gpio-cells = <4>;
> };
> };
> +
Stray whitespace change.
> };
> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-exynos/include/mach/map.h
> index c72b675..6827190 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -177,9 +177,16 @@
> #define EXYNOS4_PA_HSOTG 0x12480000
> #define EXYNOS4_PA_USB_HSPHY 0x125B0000
>
> +#ifdef CONFIG_ARCH_EXYNOS4
No need to ifdef since namespace isn't overlapped.
> #define EXYNOS4_PA_SATA 0x12560000
> #define EXYNOS4_PA_SATAPHY 0x125D0000
> #define EXYNOS4_PA_SATAPHY_CTRL 0x126B0000
> +#endif
> +#ifdef CONFIG_ARCH_EXYNOS5
Same here.
> +#define EXYNOS5_PA_SATA_PHY_CTRL 0x12170000
> +#define EXYNOS5_PA_SATA_PHY_I2C 0x121D0000
> +#define EXYNOS5_PA_SATA_BASE 0x122F0000
> +#endif
-Olof
^ permalink raw reply
* Booting vanilla kernel on the beaglebone
From: Richard Cochran @ 2012-10-09 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB3A636@DBDE01.ent.ti.com>
On Tue, Oct 09, 2012 at 05:22:15PM +0000, Hiremath, Vaibhav wrote:
> https://patchwork.kernel.org/patch/1499271/
> https://patchwork.kernel.org/patch/1569231/
>
> These patches addresses integration related issues which occurs during merge
> window.
>
> Please note that, these patches are already submitted to list and expected
> to get merged for rc1.
Okay, so now it is working. It appears that these two are neither in
linux-next or in mainline.
Thanks,
Richard
^ permalink raw reply
* Pull request for mainline
From: Roland Stigge @ 2012-10-09 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506EA8B4.6050309@antcom.de>
Hi David and Artem!
On 05/10/12 11:30, Roland Stigge wrote:
> just small reminder, just in case: Now would be a good opportunity for a
> pull request for mtd to mainline, if not already done. ;-)
I found two others asking on the mtd list for the same, but also without
a reply.
So I hope you are well and can prepare a pull request in time for this
merge window (closing at the end of this week).
Please tell me if I can do anything to help here. I would volunteer.
Thanks in advance,
Roland
^ 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