[yocto] [meta-ivi][PATCH] weston: Add weston.ini config file
Adding weston.ini to /etc/xdg. With this change
user can login and launch weston with ivi-shell.
Signed-off-by: Sujith H sujith_harida...@mentor.com
---
recipes-graphics/wayland/weston_1.4.0.bbappend | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/recipes-graphics/wayland/weston_1.4.0.bbappend
b/recipes-graphics/wayland/weston_1.4.0.bbappend
index 7a8ba6f..b324335 100644
--- a/recipes-graphics/wayland/weston_1.4.0.bbappend
+++ b/recipes-graphics/wayland/weston_1.4.0.bbappend
@@ -8,7 +8,20 @@ SRC_URI_remove =
http://wayland.freedesktop.org/releases/weston-1.4.0.tar.xz;
SRC_URI_prepend =
git://github.com/ntanibata/weston-ivi-shell.git;branch=weston-ivi-shell-1.4.0-v12;protocol=http
S = ${WORKDIR}/git
-PR = r1
+PR = r2
FILES_${PN} += ${libdir}/weston/*
FILES_${PN}-dbg += ${libdir}/weston/.debug/*
+
+do_install_append() {
+ WESTON_INI_CONFIG=${sysconfdir}/xdg/weston
+ install -d ${D}${WESTON_INI_CONFIG}
+ install -m 0644 ${S}/ivi-shell/weston.ini.in
${D}${WESTON_INI_CONFIG}/weston.ini
+ sed -i -e 's/hmi-controller.so/hmi-controller.so,ivi-controller.so/' \
+ -e 's|\@libexecdir\@|${libexecdir}|' \
+ -e 's|\@abs_top_builddir\@\/data|${datadir}\/weston|' \
+ -e 's|\@abs_top_builddir\@\/clients|${bindir}|'
${D}${WESTON_INI_CONFIG}/weston.ini
+
+}
+
+FILES_${PN} += ${sysconfdir}/xdg
--
1.8.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Binary {deb,rpm} package install without repackaging
Hi everybody,
I've got a question regarding the binary deb/rpm packages in yocto.
Is there any possibility to install a binary deb/rpm package in the rootfs
build without repackaging it?
Naively I'm for example thinking of an option in the image recipe like:
ADDITIONAL_PACKAGES += /path/to/package.{deb,rpm}
The point is that all possible solutions I found using recipes are extracting
and then repackaging the package.
Due to the fact that during the repackaging all meta data and
{pre,post}{rm,inst} scripts of the original package are lost this is a no-go
for me.
I'd appreciate any help and hints!
Thanks!
best regards,
Richard
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel config fragments are not applied
Hello
I am trying to add a custom kernel config to my layer. I followed the
following guide:
http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#creating-config-fragments
I have the following files in my layer:
recipes-kernel/linux/linux-cubox-i_3.0.35.bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}-${PV}:
inherit kernel
COMPATIBLE_MACHINE_cubox-i = (cubox-i)
SRC_URI += file://videoin.cfg
recipes-kernel/linux/linux-cubox-i-3.0.35/videoin.cfg:
CONFIG_VIDEOBUF_VMALLOC=y
CONFIG_VIDEO_TVEEPROM=y
CONFIG_VIDEO_TUNER=y
CONFIG_VIDEO_ADV7180=y
CONFIG_VIDEO_MXC_CAMERA=y
CONFIG_MXC_TVIN_ADV7180=y
CONFIG_USB_VIDEO_CLASS=y
CONFIG_USB_GSPCA=y
CONFIG_USB_M5602=y
CONFIG_USB_STV06XX=y
...
The layer is included in conf/bblayers.conf. The file videoin.cfg is
found and installed in the correct tmp/work directory. However the
config is never added to the kernel config file.
What am I doing wrong?
I use Yocto master-next, cubox-i4pro.
Thanks
Michael
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Modify RFS before final image is created
Hi Tobias,
On Friday 25 April 2014 11:16:20 Tobias Blom wrote:
On 25 apr 2014, at 09:22, Tobias Blom tobias.b...@techne-dev.se wrote:
I have run into a problem that I’m not able to figure out how to solve,
and turn to the list to ask for general directions.
I need to modify my root FS just before the final image is created. The
problem is that I do now know where to implement my code.
More specific, I want to copy a couple of RPM-packages to the final RFS,
packages that have just been installed. The reason is to be able to
perform a rollback later on.
I’ll answer my own question. It seem ROOTFS_POSTPROCESS_COMMAND or
ROOTFS_POSTINSTALL_COMMAND is the way to go.
Yep, adding to ROOTFS_POSTPROCESS_COMMAND is the expected way to do this.
I did however run into a problem when running my script. Using variable ${D}
in my ROOTFS_POSTINSTALL_COMMAND gives the “wrong” path - it points to
…/image and I’d expect it to contain the path to …/rootfs. It seem the
variable is replaced before my function is executed.
I solved this by using variable ${IMAGE_ROOTFS} instead.
Right, IMAGE_ROOTFS is the variable that points to the directory structure
being created for the image.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel config fragments are not applied
On 14-04-28 04:03 AM, Neuer User wrote:
Hello
I am trying to add a custom kernel config to my layer. I followed the
following guide:
http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#creating-config-fragments
I have the following files in my layer:
recipes-kernel/linux/linux-cubox-i_3.0.35.bbappend:
The answer to your question depends on the base linux-cubox-i
recipe.
Config fragment support works for kernels that inherit from linux-yocto,
versus ones that inherit directly from kernel.bbclass. So if you
pop open that base recipe, and look for a reference to linux-yocto.inc,
you'll have the answer.
It is possible to bbappend the linux-yocto support into the kernel
recipe via your layer, and might be worth a try.
The separation between the two classes exists to not break compatibility
with existing kernel recipes, or change long standing oe workflow with
the existing classes.
Cheers,
Bruce
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}-${PV}:
inherit kernel
COMPATIBLE_MACHINE_cubox-i = (cubox-i)
SRC_URI += file://videoin.cfg
recipes-kernel/linux/linux-cubox-i-3.0.35/videoin.cfg:
CONFIG_VIDEOBUF_VMALLOC=y
CONFIG_VIDEO_TVEEPROM=y
CONFIG_VIDEO_TUNER=y
CONFIG_VIDEO_ADV7180=y
CONFIG_VIDEO_MXC_CAMERA=y
CONFIG_MXC_TVIN_ADV7180=y
CONFIG_USB_VIDEO_CLASS=y
CONFIG_USB_GSPCA=y
CONFIG_USB_M5602=y
CONFIG_USB_STV06XX=y
...
The layer is included in conf/bblayers.conf. The file videoin.cfg is
found and installed in the correct tmp/work directory. However the
config is never added to the kernel config file.
What am I doing wrong?
I use Yocto master-next, cubox-i4pro.
Thanks
Michael
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel config fragments are not applied
Am 28.04.2014 15:03, schrieb Bruce Ashfield: The answer to your question depends on the base linux-cubox-i recipe. Config fragment support works for kernels that inherit from linux-yocto, versus ones that inherit directly from kernel.bbclass. So if you pop open that base recipe, and look for a reference to linux-yocto.inc, you'll have the answer. It is possible to bbappend the linux-yocto support into the kernel recipe via your layer, and might be worth a try. The separation between the two classes exists to not break compatibility with existing kernel recipes, or change long standing oe workflow with the existing classes. Cheers, Bruce Ahh, I see. That is probably the reason then. It includes from linux-imx: include recipes-kernel/linux/linux-imx.inc Now, should I just forget the fragment idea and use my own defconfig file? Or can I just include linux-yocto.inc in my bbappend? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel config fragments are not applied
On 14-04-28 09:14 AM, Neuer User wrote: Am 28.04.2014 15:03, schrieb Bruce Ashfield: The answer to your question depends on the base linux-cubox-i recipe. Config fragment support works for kernels that inherit from linux-yocto, versus ones that inherit directly from kernel.bbclass. So if you pop open that base recipe, and look for a reference to linux-yocto.inc, you'll have the answer. It is possible to bbappend the linux-yocto support into the kernel recipe via your layer, and might be worth a try. The separation between the two classes exists to not break compatibility with existing kernel recipes, or change long standing oe workflow with the existing classes. Cheers, Bruce Ahh, I see. That is probably the reason then. It includes from linux-imx: include recipes-kernel/linux/linux-imx.inc Now, should I just forget the fragment idea and use my own defconfig file? Or can I just include linux-yocto.inc in my bbappend? It all depends on how adventurous you are today :) Using a defconfig will work, and you can generate one without much trouble. Using fragments will allow you to keep your changes separate from the baseline configuration, but you'll need to tweak the recipe .. which always carries a risk of some unexpected side effects. I'm around to help regardless of which way you chose. Cheers, Bruce -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel config fragments are not applied
Am 28.04.2014 15:16, schrieb Bruce Ashfield:
It all depends on how adventurous you are today :) Using a defconfig
will work, and you can generate one without much trouble. Using
fragments will allow you to keep your changes separate from the
baseline configuration, but you'll need to tweak the recipe .. which
always carries a risk of some unexpected side effects.
I'm around to help regardless of which way you chose.
Cheers,
Bruce
Well, I looked at the linux-yocto file and tried a couple of
combinations in my bbappend. All of them geenrated lots of different errors.
e.g. I used:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}-${PV}:
COMPATIBLE_MACHINE_cubox-i = (cubox-i)
SRC_URI += file://videoin.cfg
addtask kernel_configme before do_configure after do_patch
# Pick up shared functions
inherit kernel
inherit kernel-yocto
#require linux-dtb.inc
# extra tasks
addtask kernel_configcheck after do_configure before do_compile
The error messages are too long to include here :-/
Guess, it is probably best to go the defconfig way.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel config fragments are not applied
On 14-04-28 09:35 AM, Neuer User wrote:
Am 28.04.2014 15:16, schrieb Bruce Ashfield:
It all depends on how adventurous you are today :) Using a defconfig
will work, and you can generate one without much trouble. Using
fragments will allow you to keep your changes separate from the
baseline configuration, but you'll need to tweak the recipe .. which
always carries a risk of some unexpected side effects.
I'm around to help regardless of which way you chose.
Cheers,
Bruce
Well, I looked at the linux-yocto file and tried a couple of
combinations in my bbappend. All of them geenrated lots of different errors.
If you send me pointers to your bblayers and local.conf settings, I'll
run a build to see what happens here as well.
I'm always interested in tracking these down regardless.
Bruce
e.g. I used:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}-${PV}:
COMPATIBLE_MACHINE_cubox-i = (cubox-i)
SRC_URI += file://videoin.cfg
addtask kernel_configme before do_configure after do_patch
# Pick up shared functions
inherit kernel
inherit kernel-yocto
#require linux-dtb.inc
# extra tasks
addtask kernel_configcheck after do_configure before do_compile
The error messages are too long to include here :-/
Guess, it is probably best to go the defconfig way.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Kernel config fragments are not applied
Am 28.04.2014 15:37, schrieb Bruce Ashfield:
If you send me pointers to your bblayers and local.conf settings, I'll
run a build to see what happens here as well.
I'm always interested in tracking these down regardless.
Bruce
Testing this should be pretty straightforward, if see that correctly.
Just init the repo with yocto master-next. Then export MACHINE=cubox-i.
My layer has:
recipes-kernel/linux/linux-cubox-i_3.0.35.bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}-${PV}:
inherit kernel
COMPATIBLE_MACHINE_cubox-i = (cubox-i)
SRC_URI += file://videoin.cfg
And in recipes-kernel/linux/linux-cubox-i-3.0.35/videoin.cfg:
CONFIG_VIDEO_ADV7180=y
(for a test this should suffice)
Then after a bitbake linux-cubix-i -c configure you can grep ADV7180
in tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/git/.config
Normally it is =n, now it should be =y.
Thanks
Michael
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] libav without X ?
Hi
I want to include the package sox_14.4.0.bb in my distro. Should be
straight forward, I thought. But I am having problems as the package
always wants GL as a requirement, which my distro does not have (without X).
the sox recipe looks like this:
DESCRIPTION=SoX is the Swiss Army knife of sound processing tools. \
It converts audio files among various standard audio file formats \
and can apply different effects and filters to the audio data.
HOMEPAGE = http://sox.sourceforge.net;
SECTION = audio
DEPENDS = libpng libav libsndfile1
PR = r2
PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'pulseaudio',
'pulseaudio', '', d)} \
${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa',
'', d)} \
magic \
PACKAGECONFIG[pulseaudio] =
--with-pulseaudio=dyn,--with-pulseaudio=no,pulseaudio,
PACKAGECONFIG[alsa] = --with-alsa=dyn,--with-alsa=no,alsa-lib,
PACKAGECONFIG[wavpack] = --with-wavpack=dyn,--with-wavpack=no,wavpack,
PACKAGECONFIG[magic] = --with-magic,--without-magic,file,
PACKAGECONFIG[mad] = --with-mad,--without-mad,libmad,
PACKAGECONFIG[id3tag] = --with-id3tag,--without-id3tag,libid3tag,
PACKAGECONFIG[lame] = --with-lame,--without-lame,lame,
LICENSE = GPLv2 LGPLv2.1
LIC_FILES_CHKSUM =
file://LICENSE.GPL;md5=751419260aa954499f7abaabaa882bbe \
file://LICENSE.LGPL;md5=fbc093901857fcd118f065f900982c24
SRC_URI = ${SOURCEFORGE_MIRROR}/sox/sox-${PV}.tar.gz
SRC_URI[md5sum] = b0c15cff7a4ba0ec17fdc74e6a1f9cf1
SRC_URI[sha256sum] =
3ee34b14dd267de378e8a117aae81ec4cae330772342e6a55bbf6520a0a88aa3
inherit autotools
BBCLASSEXTEND = native
So,it depends on libav. Libav.inc looks like this (just the important part):
DEPENDS = virtual/libsdl zlib libogg libvorbis libtheora yasm-native
INC_PR = r8
inherit autotools pkgconfig
B = ${S}/build.${HOST_SYS}.${TARGET_SYS}
FULL_OPTIMIZATION_armv7a = -fexpensive-optimizations
-fomit-frame-pointer -O4 -ffast-math
BUILD_OPTIMIZATION = ${FULL_OPTIMIZATION}
EXTRA_FFCONF_armv7a = --cpu=cortex-a8
EXTRA_FFCONF ?=
PACKAGECONFIG ??= bzip2 x264 ${@base_contains('DISTRO_FEATURES', 'x11',
'x11', '', d)}
PACKAGECONFIG[jack] = --enable-indev=jack,--disable-indev=jack,jack
PACKAGECONFIG[bzip2] = --enable-bzlib,--disable-bzlib,bzip2
PACKAGECONFIG[schroedinger] =
--enable-libschroedinger,--disable-libschroedinger,schroedinger
PACKAGECONFIG[gsm] = --enable-libgsm,--disable-libgsm,libgsm
PACKAGECONFIG[x264] = --enable-libx264,--disable-libx264,x264
PACKAGECONFIG[vpx] = --enable-libvpx,--disable-libvpx,libvpx
PACKAGECONFIG[mp3lame] = --enable-libmp3lame,--disable-libmp3lame,lame
PACKAGECONFIG[faac] = --enable-libfaac,--disable-libfaac,faac
PACKAGECONFIG[x11] = --enable-x11grab,--disable-x11grab,virtual/libx11
libxfixes libxext xproto
My local.conf has:
DISTRO_FEATURES_remove = x11 wayland
So, I don't understand why it always wants to build
recipe libglu-2_9.0.0-0: task do_configure: Started
Which fails, of course:
| checking for GL/gl.h... no
| configure: error: GL not found
| Configure failed. The contents of all config.log files follows to aid
debugging
| ERROR: oe_runconf failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at
/home/ubuntu/yocto/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-gnueabi/libglu/2_9.0.0-0/temp/log.do_configure.13955)
NOTE: recipe libglu-2_9.0.0-0: task do_configure: Failed
I seem to be missing something. Can anybody help me how I can build sox
without x11 dependency (which it shouldn't have)?
Thanks
Michael
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
Update Now I have core-image-minimal building and booting for all of the supported QEMU targets in OE-Core with musl/gcc-4.9. The updates are all available on contrib tree branch kraj/musl, try it out for your machine/distro if you are interested in musl http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/musl On Wed, Apr 2, 2014 at 10:27 AM, Paul Barker p...@paulbarker.me.uk wrote: On 2 April 2014 18:13, Khem Raj raj.k...@gmail.com wrote: On Wed, Apr 2, 2014 at 10:03 AM, Paul Barker p...@paulbarker.me.uk wrote: You've fixed util-linux in a different way to me, I added qsort_r to musl this won't fly in musl community. whereas you've removed it's use from util-linux. I'm not bothered which one we use if both work. We do now have 4 people looking at util-linux fixes: Me, you and Robert Yang (as util-linux-native doesn't build on Centos 5.10 due to the same qsort_r usage) here in oe-core and Karel Zak from upstream (as they want to fix it for their next release). I think we need to pick one fix (probably yours if it's tested and working in another distro) and get it applied to oe-core master. yes, I think not using qsort_r is common solution for all these issues. Ok, sounds good. Could we split this out and send it to the mailing list on its own for now? It's much better than the patch that's currently in oe-core. Your latest commit glibc-2.0: Fix build issues that arise on musl should say glib not glibc. Other than that, your glib fix is better than mine (I did add string.h but didn't add the '--with-libiconv=gnu' option, instead I set musl as the provider of virtual/libiconv). in order to build a lot of software we would need some sort of iconv implementation letting musl to provide it is probably ok too but I wanted to take the tested path to get to an image to build and then we have a known baseline and we could experiment more. I'd like to see both as options but I agree we should get an image working in the simplest way possible first. I'm really impressed with how fast this is moving forward so don't take my comments as in any way negative! -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [oe] initial support for musl libc with OE/Yocto Project
On Mon, Apr 28, 2014 at 10:17 AM, Khem Raj raj.k...@gmail.com wrote: Now I have core-image-minimal building and booting for all of the supported QEMU targets in OE-Core with musl/gcc-4.9. The updates are all available on contrib tree branch kraj/musl, try it out for your machine/distro if you are interested in musl http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/musl Congrats on the progress :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Question about remote debugging via gdbserver
Hi Frederico, Sorry for the delayed response. If you want to step into code for which the debugger does not have the source info Eclipse should actually tell you. But as a prerequisite you will need to install the dev and debug packages for gstreamer (and eventually others) to the root file system you are using on your development host. For that you need to tell YP to include them which you do by adding dev-pkg and dbg-pkg to EXTRA_IMAGE_INSTALL in the conf/local.conf file of your build environment. Rudi On Fri, Apr 18, 2014 at 1:28 AM, Federico Vitali fede.vit...@gmail.comwrote: Goodmorning Rudolf, thank you again for your time. I have not explained my goal very well, so I try to explain with a specific example. I'm working with gstreamer for a project I'm following for my company. Let's take the gstreamer hello world application, here is the source code: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/chapter-helloworld.html#section-helloworld I've succesfully built and deployed the application. I can debug and follow the code of the application line by line with eclipse. Now, if I want to enter into a function of gstreamer libs (e.g. gst_pipeline_new), what should I have to do? Federico 2014-04-16 21:22 GMT+02:00 Rudolf Streif rstr...@linuxfoundation.org: Hi Federico, I knew that I can add source paths to the debugger. Ok, if that's not the issue what exactly is not working for you? I see in your debug profiles that you have some binaries eg ls. Did you import that binary from sysrootfs on your build machine? Can you please tell me the steps before adding the path? No, that's actually sample code of a simple ls application that I use for teaching a class on Linux APIs. Cheers, Rudi -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] 1.5.2.rc3 now available for QA
http://autobuilder.yoctoproject.org/pub/releases/yocto-1.5.2.rc3 bitbake 0a94e568152de550dedc8135a766beb18bf064ab eclipse-poky-juno 79cd3c6ff119526f3f85567253450d2e857afed0 eclipse-poky-kepler e842d41f05066df1533a2788e650f0be213ad5b5 meta-fsl-arm 5fdb620c09df11e70434092f675c891e0ba84108 meta-fsl-ppc 40465bac88ca28b554cff35346341d19552548bf meta-intel acf2b4013d981563081bc072e778c4caaab7c67d meta-minnow 9aa60d0eaf03fe30670acf581eaf7e57c76b5f99 meta-qt3 4772424ab69908d4e3b9d6d4717ca889468e6acd oecore 97bc1bce9a226cc02db8a5afc2c0d4f4f70034a6 poky 9b7d43963f54d25e087a4cc55623a4cfeac121a9 -- Elizabeth Flanagan Yocto Project Build and Release -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PULL REQUEST] Kernel: 3.10 Branch: standard/axxia/base
Bruce,
I resubmitted this request, I had given you the wrong starting point, this
should fix the merge problem
Charlie
The following changes since commit 55bf6f0b78353c34d4910bca7bfc9eed0aff5de4:
Merge branch 'standard/base' into standard/axxia/base (2014-04-01 21:11:34
-0400)
are available in the git repository at:
g...@github.com:butlerpaul/lsikernel-3.10 sab-next-1
for you to fetch changes up to a72435875d8a4b4e5d61779dd823c59fd4180921:
gpio: repairs merge comflict (2014-04-22 14:44:24 -0700)
Anders Berg (13):
i2c-axxia: Fix broken smbus block read
i2c-axxia: Adjust tLOW,tHIGH to match fast-mode requirements
arm/axxia: Workaround for cross-cluster sev issue
Revert LSI AXM55XX: Add GENERIC_LOCKBREAK
Revert LSI AXM55XX: Disable use of wfe/sev in arch spinlock
dma: lsi-dma32: DMA driver configuration update
dma: lsi-dma32: Cleanup DMA driver
mach-axxia: Split device tree into SoC/board parts
arm/axxia: Configure changes to 'GPIO driver for SPI chip selects'
arm/axxia: GPIO driver for SPI chip selects
spi: Revert to mainline spi-pl022
hwmon: Support new revision of LTC2974
i2c-axxia: Use managed functions devm_*
Charlie Paul (3):
i2c-axxia: code update kernel.org coding spec
LSI powerpc/boot: added for rapidio
i2c-axxia: Configure changes to 'Use managed functions devm_*'
David Mercado (3):
LSI FEMAC Ethernet Driver
kernel/irq/manage.c: Fix irq_set_affinity to allow use with buslocks
LSI AXM55xx: Axxia GIC driver improvements (3rd gen)
Gary McGee (2):
LSI AXXIA: fixes for VP engine quiesce and DDR shutdown
arm/axxia: improved robustness for DDR retention
John Jacques (10):
arch/arm/mach-axxia: Updated Device Tree for Emulation
arch/arm/mach-axxia: Accept the new lsi,axm5516-emu Machine
arch/arm/mach-axxia: Disable DDR Retention Resets in Sim/Emu
arch/arm/mach-axxia: Updates to the VMFS File System
LSI RapidIO: Updated Device Trees for rapidio
arch/arm/mach-axxia: Name Cleanup
arch/arm/mach-axxia: Work-Around for Event Problems in v1.0 Silicon
arch/powerpc: Update the Axxia Device Tree Files
arch/powerpc: Clean up of Compatible Names in Axxia Device Trees
LSI drivers/tty: Axxia Serial Driver Update
Jonas Svennebring (2):
ARM: 7840/1: LPAE: don't reject mapping /dev/mem above 4GB
LSI AXXIA: Basic perf support for axxia plaform block provided by LSI.
Michael Bringmann (2):
LSI AXM55xx: Configuration updates
LSI AXM55xx: Disable linkdown reset configuration.
Paul Butler (2):
i2c: comforming to changes introduced by move of_i2c to core
gpio: repairs merge comflict
SangeethaRao (2):
arch/powerpc: Checking in correct USB entries to ACP3421 DTS
LSI powerpc/sysdev: Removing the power of 2 size restriction
arch/arm/Kconfig |7 +-
arch/arm/boot/dts/Makefile |5 +
arch/arm/boot/dts/axm-sim.dts | 403
arch/arm/boot/dts/axm-ve-tc1.dts | 363 ---
arch/arm/boot/dts/axm-ve-tc2.dts | 174 --
arch/arm/boot/dts/axm5504-cpus.dtsi| 49 +
arch/arm/boot/dts/axm5504-emu.dts | 44 +
arch/arm/boot/dts/axm5504-sim.dts | 127 +
arch/arm/boot/dts/axm5507-cpus.dtsi| 73 +
arch/arm/boot/dts/axm5507-emu.dts | 44 +
arch/arm/boot/dts/axm5508-cpus.dtsi| 81 +
arch/arm/boot/dts/axm5512-cpus.dtsi| 114 +
arch/arm/boot/dts/axm5516-amarillo.dts | 195 ++
arch/arm/boot/dts/axm5516-cpus.dtsi| 145 ++
arch/arm/boot/dts/axm5516-sim.dts | 127 +
arch/arm/boot/dts/axm55xx.dts | 464
arch/arm/boot/dts/axm55xx.dtsi | 390 +++
.../boot/dts/{axm55xxemu.dts = axm55xxemu7.dts} | 17 +-
arch/arm/boot/dts/axm55xxsim.dts | 363 ---
arch/arm/boot/dts/axm55xxsim16.dts | 459
arch/arm/boot/fmboot/Makefile | 12 +-
arch/arm/include/asm/spinlock.h|9 +-
arch/arm/mach-axxia/Makefile |6 +-
arch/arm/mach-axxia/axxia-gic.c| 1138 -
arch/arm/mach-axxia/axxia.c| 66 +-
arch/arm/mach-axxia/clock.c|2 +-
arch/arm/mach-axxia/ddr_retention.c| 255 +-
arch/arm/mach-axxia/ddr_shutdown.c | 332 +++
arch/arm/mach-axxia/ev.c | 53 +
arch/arm/mach-axxia/ncr.c | 18 +-
arch/arm/mach-axxia/perf_event_memc.c | 130 +
arch/arm/mach-axxia/perf_event_memc.h | 62 +
arch/arm/mach-axxia/perf_event_pcx.c | 46 +
[linux-yocto] [PATCH 03/15] dma: lsi-dma32: Add parameter to setup burst size
From: Anders Berg anders.b...@lsi.com
Added module parameter 'burst' that allows the setup of the DMA controller
preferred burst setting on reads and writes. Set this to 7 for INCR16, 5 for
INCR8, 3 for INCR4 or 0 for singles (no bursts).
Signed-off-by: Anders Berg anders.b...@lsi.com
---
drivers/dma/lsi-dma32.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/lsi-dma32.c b/drivers/dma/lsi-dma32.c
index 0c679bf..f08a1e8 100644
--- a/drivers/dma/lsi-dma32.c
+++ b/drivers/dma/lsi-dma32.c
@@ -59,6 +59,9 @@
#define ch_dbg(dmac, fmt, ...) do {} while (0)
#endif
+static unsigned int burst = 5;
+module_param(burst, uint, 0644);
+MODULE_PARM_DESC(burst, Set preferred bust size during DMA transfters);
static void reset_channel(struct gpdma_channel *dmac)
{
@@ -416,6 +419,8 @@ gpdma_prep_memcpy(struct dma_chan *chan,
struct gpdma_channel *dmac = to_gpdma_chan(chan);
struct gpdma_desc *desc;
u16 rot_len, x_count, src_size, access_size;
+ u16 src_burst = burst;
+ u16 dst_burst = burst;
desc = get_descriptor(dmac-engine);
if (desc == NULL) {
@@ -461,8 +466,11 @@ gpdma_prep_memcpy(struct dma_chan *chan,
desc-hw.src_y_mod = 0;
desc-hw.src_addr = cpu_to_le32(src 0x);
desc-hw.src_data_mask = ~0;
- desc-hw.src_access= cpu_to_le16((rot_len 6) | access_size);
- desc-hw.dst_access= cpu_to_le16(access_size);
+ desc-hw.src_access= cpu_to_le16((rot_len 6) |
+access_size |
+(src_burst 7));
+ desc-hw.dst_access= cpu_to_le16(access_size |
+(dst_burst 7));
desc-hw.ch_config = cpu_to_le32(DMA_CONFIG_ONE_SHOT(1));
desc-hw.next_ptr = 0;
desc-hw.dst_x_ctr = cpu_to_le16(x_count);
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 02/15] arch/powerpc: Disable the ACP NAND Driver for 3500
From: John Jacques john.jacq...@lsi.com
Added code to check for the existence of the NAND driver for
3500. If the driver does not exist then the error is returned
gracefully
Signed-off-by: John Jacques john.jacq...@lsi.com
---
drivers/mtd/nand/lsi_acp_nand.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mtd/nand/lsi_acp_nand.c b/drivers/mtd/nand/lsi_acp_nand.c
index ddc58e3..ff2566b 100644
--- a/drivers/mtd/nand/lsi_acp_nand.c
+++ b/drivers/mtd/nand/lsi_acp_nand.c
@@ -3433,6 +3433,13 @@ lsi_nand_init(void)
static const char *part_probe_types[]
= { cmdlinepart, ofpart, NULL };
+ np = of_find_compatible_node(NULL, NULL, lsi,acp3500);
+
+ if (NULL != np) {
+ pr_err(NAND Support is Not Yet Available on 3500\n);
+ return -1;
+ }
+
memset(ppdata, 0, sizeof(ppdata));
np = of_find_node_by_type(np, nand);
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 09/15] ARM: axxia: Cleanup timer init code
From: Anders Berg anders.b...@lsi.com
Remove some unneeded code from the timer init function. The clocksource and
clockevent devices are all instansiated via clocksource_of_init().
Signed-off-by: Anders Berg anders.b...@lsi.com
---
arch/arm/mach-axxia/axxia.c | 20
1 file changed, 20 deletions(-)
diff --git a/arch/arm/mach-axxia/axxia.c b/arch/arm/mach-axxia/axxia.c
index a8b213f..9ed7ce1 100644
--- a/arch/arm/mach-axxia/axxia.c
+++ b/arch/arm/mach-axxia/axxia.c
@@ -97,34 +97,14 @@ static void __init axxia_dt_init_irq(void)
void __init axxia_dt_timer_init(void)
{
- const char *path;
- struct device_node *node;
- void __iomem *base;
int is_sim;
is_sim = of_find_compatible_node(NULL, NULL, lsi,axm5516-sim) != NULL;
axxia_init_clocks(is_sim);
-#ifdef CONFIG_ARM_ARCH_TIMER
of_clk_init(NULL);
clocksource_of_init();
-#endif
-
- if (of_property_read_string(of_aliases, timer, path)) {
- WARN_ON(1);
- return;
- }
-
- node = of_find_node_by_path(path);
- if (WARN_ON(node == NULL))
- return;
-
- base = of_iomap(node, 0);
- if (WARN_ON(base == NULL))
- return;
-
- sp804_clocksource_and_sched_clock_init(base, axxia-timer0);
}
static struct mmci_platform_data mmc_plat_data = {
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 00/15] LSI AXXIA updates to standard/axxia/base 3.10
Second set of patches ready to go. Anders Berg (9): i2c-axxia: Avoid timeout when interrupt delayed dma: lsi-dma32: Add parameter to setup burst size dma: lsi-dma32: Handle DMA transfer sizes 1MB ARM: axxia: dts: Enable sp804 timers by default ARM: axxia: Cleanup timer init code i2c: axxia: Add support for 10-bit addressing ARM: axxia: Alloc GIC to be initialized from non-primary core ARM: axxia: Fix release of CPUs with booted via kexec ARM: axxia: Flush L3 in kexec_reinit David Mercado (2): LSI AXM55xx: Fix PMU handler issue LSI AXM55xx: Fix CPU hotplug John Jacques (4): arch/powerpc: Disable the ACP NAND Driver for 3500 arch/powerpc: Fix Compile Error when the Target is PowerPC axxia: Use the Device Tree for MDIO Clock Offset/Period if Provided arch/powerpc: Support Older Machine Name for LSI Axxia arch/arm/boot/dts/axm5504-emu.dts|2 + arch/arm/boot/dts/axm5507-emu.dts|2 + arch/arm/boot/dts/axm5516-amarillo.dts |2 + arch/arm/boot/dts/axm55xx.dtsi |1 - arch/arm/mach-axxia/axxia-gic.c | 47 +-- arch/arm/mach-axxia/axxia.c | 102 +++--- arch/arm/mach-axxia/axxia.h |1 + arch/arm/mach-axxia/hotplug.c|2 +- arch/arm/mach-axxia/include/mach/axxia-gic.h |1 - arch/arm/mach-axxia/platsmp.c| 27 ++-- arch/powerpc/boot/dts/acp25xx.dts|3 + arch/powerpc/boot/dts/acp342x.dts|3 + arch/powerpc/boot/dts/acp344x.dts|3 + arch/powerpc/boot/dts/acp35xx.dts|3 + arch/powerpc/platforms/44x/acpx1.c |5 +- drivers/dma/lsi-dma32.c | 185 +++--- drivers/dma/lsi-dma32.h |4 +- drivers/i2c/busses/i2c-axxia.c | 84 +++- drivers/mtd/nand/lsi_acp_nand.c |7 + drivers/net/ethernet/lsi/lsi_acp_mdio.c | 33 +++-- 20 files changed, 306 insertions(+), 211 deletions(-) -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 06/15] LSI AXM55xx: Fix PMU handler issue
From: David Mercado david.merc...@windriver.com
The AXM55xx has the PMU IRQ lines from each core in a cluster OR'ed
together. As a workaround for this, a PMU handler extension was created
in the BSP to dynamically call irq_set_affinity() to rotate the PMU IRQ
assignment as needed, in order to maintain perf accuracy. However, with
the introduction of the Axxia GIC driver slow bus implementation,
irq_set_affinity() cannot be called directly from interrupt context.
Instead, the PMU IRQ handler extension is removed from the BSP and the
rotation of IRQ affinity is performed directly within the Axxia GIC
driver.
Signed-off-by: David Mercado david.merc...@windriver.com
---
arch/arm/mach-axxia/axxia-gic.c | 25 +
arch/arm/mach-axxia/axxia.c | 36
2 files changed, 25 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-axxia/axxia-gic.c b/arch/arm/mach-axxia/axxia-gic.c
index 32c7525..8cfed90 100644
--- a/arch/arm/mach-axxia/axxia-gic.c
+++ b/arch/arm/mach-axxia/axxia-gic.c
@@ -909,6 +909,10 @@ asmlinkage void __exception_irq_entry
axxia_gic_handle_irq(struct pt_regs *regs)
u32 irqstat, irqnr;
struct gic_chip_data *gic = gic_data;
void __iomem *cpu_base = gic_data_cpu_base(gic);
+ void __iomem *dist_base = gic_data_dist_base(gic);
+ u32 pcpu = cpu_logical_map(smp_processor_id());
+ u32 cluster = pcpu / CORES_PER_CLUSTER;
+ u32 next, mask;
do {
irqstat = readl_relaxed(cpu_base + GIC_CPU_INTACK);
@@ -969,6 +973,27 @@ asmlinkage void __exception_irq_entry
axxia_gic_handle_irq(struct pt_regs *regs)
writel_relaxed(irqnr, cpu_base + GIC_CPU_EOI);
break;
+ case IRQ_PMU:
+ /*
+* The PMU IRQ line is OR'ed among all cores
+* within a cluster, so no way to tell which
+* core actually generated the interrupt.
+* Therefore, rotate PMU IRQ affinity to allow
+* perf to work accurately as possible. Skip
+* over offline cpus.
+*/
+ do {
+ next = (++pcpu % CORES_PER_CLUSTER) +
+ (cluster * CORES_PER_CLUSTER);
+ } while (!cpu_online(next));
+
+ mask = 0x01 (next % CORES_PER_CLUSTER);
+ raw_spin_lock(irq_controller_lock);
+ writeb_relaxed(mask, dist_base +
+ GIC_DIST_TARGET + IRQ_PMU);
+ raw_spin_unlock(irq_controller_lock);
+ /* Fall through ... */
+
default:
/* External interrupt */
handle_IRQ(irqnr, regs);
diff --git a/arch/arm/mach-axxia/axxia.c b/arch/arm/mach-axxia/axxia.c
index d73e11b..a8b213f 100644
--- a/arch/arm/mach-axxia/axxia.c
+++ b/arch/arm/mach-axxia/axxia.c
@@ -166,47 +166,11 @@ static struct resource axxia_pmu_resources[] = {
},
};
-/*
- * The PMU IRQ lines of four cores are wired together into a single interrupt.
- * Bounce the interrupt to other cores if it's not ours.
- */
-#define CORES_PER_CLUSTER 4
-static irqreturn_t axxia_pmu_handler(int irq, void *dev, irq_handler_t handler)
-{
- irqreturn_t ret = handler(irq, dev);
- int cpu = smp_processor_id();
- int cluster = cpu / CORES_PER_CLUSTER;
- int other;
-
- if (ret == IRQ_NONE) {
-
- /* Look until we find another cpu that's online. */
- do {
- other = (++cpu % CORES_PER_CLUSTER) +
- (cluster * CORES_PER_CLUSTER);
- } while (!cpu_online(other));
-
- irq_set_affinity(irq, cpumask_of(other));
- }
-
- /*
-* We should be able to get away with the amount of IRQ_NONEs we give,
-* while still having the spurious IRQ detection code kick in if the
-* interrupt really starts hitting spuriously.
-*/
- return ret;
-}
-
-static struct arm_pmu_platdata axxia_pmu_platdata = {
- .handle_irq = axxia_pmu_handler,
-};
-
static struct platform_device pmu_device = {
.name = arm-pmu,
.id = -1,
.num_resources = ARRAY_SIZE(axxia_pmu_resources),
.resource = axxia_pmu_resources,
- .dev.platform_data = axxia_pmu_platdata,
};
static int
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
[linux-yocto] [PATCH 04/15] dma: lsi-dma32: Handle DMA transfer sizes 1MB
From: Anders Berg anders.b...@lsi.com
One descriptor can only transfer up to 64K 128-bit words. To handle larger
transfers the driver is now able to chain multiple descriptors.
Signed-off-by: Anders Berg anders.b...@lsi.com
---
drivers/dma/lsi-dma32.c | 188 ++-
drivers/dma/lsi-dma32.h |4 +-
2 files changed, 107 insertions(+), 85 deletions(-)
diff --git a/drivers/dma/lsi-dma32.c b/drivers/dma/lsi-dma32.c
index f08a1e8..837f3e1 100644
--- a/drivers/dma/lsi-dma32.c
+++ b/drivers/dma/lsi-dma32.c
@@ -61,7 +61,8 @@
static unsigned int burst = 5;
module_param(burst, uint, 0644);
-MODULE_PARM_DESC(burst, Set preferred bust size during DMA transfters);
+MODULE_PARM_DESC(burst,
+Preferred burst setting (0=SINGLE,3=INCR4,5=INCR8,7=INCR16));
static void reset_channel(struct gpdma_channel *dmac)
{
@@ -130,9 +131,8 @@ static int alloc_desc_table(struct gpdma_engine *engine)
* Controller can do full descriptor addresses, then we need no
* special alignment on the descriptor block.
*/
- order = ilog2((ALIGN(GPDMA_MAX_DESCRIPTORS *
-sizeof(struct gpdma_desc),
-PAGE_SIZE)) PAGE_SHIFT);
+ order = get_order(GPDMA_MAX_DESCRIPTORS *
+ sizeof(struct gpdma_desc));
}
engine-pool.va = (struct gpdma_desc *)
@@ -144,9 +144,11 @@ static int alloc_desc_table(struct gpdma_engine *engine)
engine_dbg(engine, order=%d pa=%#llx va=%p\n,
engine-pool.order, engine-pool.phys, engine-pool.va);
- for (i = 0; i GPDMA_MAX_DESCRIPTORS; i++)
- engine-pool.free[i] = engine-pool.va[i];
- engine-pool.next = 0;
+ engine-pool.free = NULL;
+ for (i = 0; i GPDMA_MAX_DESCRIPTORS-1; i++)
+ engine-pool.va[i].chain = engine-pool.va[i+1];
+ engine-pool.va[GPDMA_MAX_DESCRIPTORS-1].chain = NULL;
+ engine-pool.free = engine-pool.va[0];
return 0;
}
@@ -160,26 +162,48 @@ static void free_desc_table(struct gpdma_engine *engine)
static struct gpdma_desc *get_descriptor(struct gpdma_engine *engine)
{
unsigned long flags;
- struct gpdma_desc *desc = NULL;
+ struct gpdma_desc *desc;
spin_lock_irqsave(engine-lock, flags);
- if (engine-pool.next GPDMA_MAX_DESCRIPTORS)
- desc = engine-pool.free[engine-pool.next++];
+ desc = engine-pool.free;
+ if (desc) {
+ engine-pool.free = desc-chain;
+ desc-chain = NULL;
+ desc-engine = engine;
+ }
spin_unlock_irqrestore(engine-lock, flags);
- desc-engine = engine;
return desc;
}
+static phys_addr_t desc_to_paddr(const struct gpdma_channel *dmac,
+const struct gpdma_desc *desc)
+{
+ phys_addr_t paddr = virt_to_phys(desc-hw);
+ WARN_ON(paddr 0xf);
+ if (dmac-engine-chip-flags LSIDMA_NEXT_FULL)
+ paddr |= 0x8;
+ else
+ paddr = 0xf;
+
+ return paddr;
+}
+
static void free_descriptor(struct virt_dma_desc *vd)
{
struct gpdma_desc *desc = to_gpdma_desc(vd);
struct gpdma_engine *engine = desc-engine;
unsigned long flags;
+ struct gpdma_desc *tail;
+
+ BUG_ON(desc == NULL);
+
+ for (tail = desc; tail-chain != NULL; tail = tail-chain)
+ ;
spin_lock_irqsave(engine-lock, flags);
- BUG_ON(engine-pool.next == 0);
- engine-pool.free[--engine-pool.next] = desc;
+ tail-chain = engine-pool.free;
+ engine-pool.free = desc;
spin_unlock_irqrestore(engine-lock, flags);
}
@@ -220,14 +244,9 @@ static void gpdma_start(struct gpdma_channel *dmac)
return;
}
- paddr = virt_to_phys(desc-hw);
- WARN_ON(paddr 0xf);
- if (dmac-engine-chip-flags LSIDMA_NEXT_FULL) {
- /* Physical address of descriptor to load */
- writel((u32)paddr | 0x8, dmac-base + DMA_NXT_DESCR);
- } else {
- writel((u32)paddr 0xf, dmac-base + DMA_NXT_DESCR);
- }
+ /* Physical address of descriptor to load */
+ paddr = desc_to_paddr(dmac, desc);
+ writel((u32)paddr, dmac-base + DMA_NXT_DESCR);
if (dmac-engine-chip-flags LSIDMA_SEG_REGS) {
/* Segment bits [39..32] of descriptor, src and dst addresses */
@@ -417,73 +436,76 @@ gpdma_prep_memcpy(struct dma_chan *chan,
unsigned long dma_flags)
{
struct gpdma_channel *dmac = to_gpdma_chan(chan);
- struct gpdma_desc *desc;
- u16 rot_len, x_count, src_size, access_size;
- u16 src_burst = burst;
- u16 dst_burst = burst;
+ struct gpdma_desc *first = NULL, *prev = NULL, *new;
+ u32 rot_len, x_count, src_size, access;
-
[linux-yocto] [PATCH 08/15] ARM: axxia: dts: Enable sp804 timers by default
From: Anders Berg anders.b...@lsi.com
Let the timers block be enabled by default in the axm55xx.dsti device-tree
since all systems will need it anyway.
Signed-off-by: Anders Berg anders.b...@lsi.com
---
arch/arm/boot/dts/axm55xx.dtsi |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/axm55xx.dtsi b/arch/arm/boot/dts/axm55xx.dtsi
index 92347d8..6a43139 100644
--- a/arch/arm/boot/dts/axm55xx.dtsi
+++ b/arch/arm/boot/dts/axm55xx.dtsi
@@ -328,7 +328,6 @@
0 51 4,
0 52 4,
0 53 4;
- status = disabled;
};
gpio0: gpio@2010092000 {
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 07/15] LSI AXM55xx: Fix CPU hotplug
From: David Mercado david.merc...@windriver.com
The platform CPU die routine was not being called. Added hook to
axxia_platform_cpu_die().
Signed-off-by: David Mercado david.merc...@windriver.com
---
arch/arm/mach-axxia/axxia.h |1 +
arch/arm/mach-axxia/hotplug.c |2 +-
arch/arm/mach-axxia/platsmp.c |5 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-axxia/axxia.h b/arch/arm/mach-axxia/axxia.h
index 3393d37..156c6e0 100644
--- a/arch/arm/mach-axxia/axxia.h
+++ b/arch/arm/mach-axxia/axxia.h
@@ -2,6 +2,7 @@
void axxia_init_clocks(int is_sim);
void axxia_ddr_retention_init(void);
+void axxia_platform_cpu_die(unsigned int cpu);
extern struct smp_operations axxia_smp_ops;
diff --git a/arch/arm/mach-axxia/hotplug.c b/arch/arm/mach-axxia/hotplug.c
index d919bff..fb5ec90 100644
--- a/arch/arm/mach-axxia/hotplug.c
+++ b/arch/arm/mach-axxia/hotplug.c
@@ -114,7 +114,7 @@ int platform_cpu_kill(unsigned int cpu)
*
* Called with IRQs disabled
*/
-void platform_cpu_die(unsigned int cpu)
+void axxia_platform_cpu_die(unsigned int cpu)
{
int spurious = 0;
diff --git a/arch/arm/mach-axxia/platsmp.c b/arch/arm/mach-axxia/platsmp.c
index 8e863b0..dec7b5b 100644
--- a/arch/arm/mach-axxia/platsmp.c
+++ b/arch/arm/mach-axxia/platsmp.c
@@ -22,6 +22,7 @@
#include asm/mach/map.h
#include asm/virt.h
+#include axxia.h
#include mach/axxia-gic.h
extern void axxia_secondary_startup(void);
@@ -246,4 +247,8 @@ struct smp_operations axxia_smp_ops __initdata = {
.smp_prepare_cpus = axxia_smp_prepare_cpus,
.smp_secondary_init = axxia_secondary_init,
.smp_boot_secondary = axxia_boot_secondary,
+#ifdef CONFIG_HOTPLUG_CPU
+ .cpu_die= axxia_platform_cpu_die,
+#endif
+
};
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 01/15] i2c-axxia: Avoid timeout when interrupt delayed
From: Anders Berg anders.b...@lsi.com
Changed the order in which the interrupt conditions are checked in the
interrupt handler. Need to check for transfer-complete before timeout-error,
otherwise a delayed interrupt may report a false timeout error (since the
timeout may expire after the transfer was completed).
Signed-off-by: Anders Berg anders.b...@lsi.com
---
drivers/i2c/busses/i2c-axxia.c | 50 ++--
1 file changed, 23 insertions(+), 27 deletions(-)
diff --git a/drivers/i2c/busses/i2c-axxia.c b/drivers/i2c/busses/i2c-axxia.c
index 86fc695..cd68166 100644
--- a/drivers/i2c/busses/i2c-axxia.c
+++ b/drivers/i2c/busses/i2c-axxia.c
@@ -332,33 +332,6 @@ axxia_i2c_isr(int irq, void *_dev)
/* Clear interrupt */
writel(0x01, idev-regs-interrupt_status);
- if (unlikely(status MST_STATUS_ERR)) {
- idev-msg_err = status MST_STATUS_ERR;
- i2c_int_disable(idev, ~0);
- dev_dbg(idev-dev, error %s, rx=%u/%u tx=%u/%u\n,
- status_str(idev-msg_err),
- readl(idev-regs-mst_rx_bytes_xfrd),
- readl(idev-regs-mst_rx_xfer),
- readl(idev-regs-mst_tx_bytes_xfrd),
- readl(idev-regs-mst_tx_xfer));
- complete(idev-msg_complete);
- return IRQ_HANDLED;
- }
-
- /* Stop completed? */
- if (status MST_STATUS_SCC) {
- i2c_int_disable(idev, ~0);
- complete(idev-msg_complete);
- }
-
- /* Transfer done? */
- if (status (MST_STATUS_SNS | MST_STATUS_SS)) {
- if (i2c_m_rd(idev-msg) idev-msg_xfrd idev-msg-len)
- axxia_i2c_empty_rx_fifo(idev);
- i2c_int_disable(idev, ~0);
- complete(idev-msg_complete);
- }
-
/* RX FIFO needs service? */
if (i2c_m_rd(idev-msg) (status MST_STATUS_RFL))
axxia_i2c_empty_rx_fifo(idev);
@@ -371,6 +344,29 @@ axxia_i2c_isr(int irq, void *_dev)
i2c_int_disable(idev, MST_STATUS_TFL);
}
+ if (status MST_STATUS_SCC) {
+ /* Stop completed? */
+ i2c_int_disable(idev, ~0);
+ complete(idev-msg_complete);
+ } else if (status (MST_STATUS_SNS | MST_STATUS_SS)) {
+ /* Transfer done? */
+ if (i2c_m_rd(idev-msg) idev-msg_xfrd idev-msg-len)
+ axxia_i2c_empty_rx_fifo(idev);
+ i2c_int_disable(idev, ~0);
+ complete(idev-msg_complete);
+ } else if (unlikely(status MST_STATUS_ERR)) {
+ /* Transfer error? */
+ idev-msg_err = status MST_STATUS_ERR;
+ i2c_int_disable(idev, ~0);
+ dev_dbg(idev-dev, error %s, rx=%u/%u tx=%u/%u\n,
+ status_str(idev-msg_err),
+ readl(idev-regs-mst_rx_bytes_xfrd),
+ readl(idev-regs-mst_rx_xfer),
+ readl(idev-regs-mst_tx_bytes_xfrd),
+ readl(idev-regs-mst_tx_xfer));
+ complete(idev-msg_complete);
+ }
+
return IRQ_HANDLED;
}
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 10/15] axxia: Use the Device Tree for MDIO Clock Offset/Period if Provided
From: John Jacques john.jacq...@lsi.com
Updated the device trees to suppor the MDIO Clock offset
Signed-off-by: John Jacques john.jacq...@lsi.com
---
arch/arm/boot/dts/axm5504-emu.dts |2 ++
arch/arm/boot/dts/axm5507-emu.dts |2 ++
arch/arm/boot/dts/axm5516-amarillo.dts |2 ++
arch/powerpc/boot/dts/acp25xx.dts |3 +++
arch/powerpc/boot/dts/acp342x.dts |3 +++
arch/powerpc/boot/dts/acp344x.dts |3 +++
arch/powerpc/boot/dts/acp35xx.dts |3 +++
drivers/net/ethernet/lsi/lsi_acp_mdio.c | 33 ---
8 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/axm5504-emu.dts
b/arch/arm/boot/dts/axm5504-emu.dts
index 0d7ca8f..2b13386 100644
--- a/arch/arm/boot/dts/axm5504-emu.dts
+++ b/arch/arm/boot/dts/axm5504-emu.dts
@@ -29,6 +29,8 @@
femac {
status = okay;
phy-address = 0x03;
+ mdio-clock-offset = 0x10;
+ mdio-clock-period = 0x2c;
};
serial0 {
diff --git a/arch/arm/boot/dts/axm5507-emu.dts
b/arch/arm/boot/dts/axm5507-emu.dts
index 8de0b23..ed0bf10 100644
--- a/arch/arm/boot/dts/axm5507-emu.dts
+++ b/arch/arm/boot/dts/axm5507-emu.dts
@@ -29,6 +29,8 @@
femac {
status = okay;
phy-address = 0x03;
+ mdio-clock-offset = 0x10;
+ mdio-clock-period = 0x2c;
};
serial0 {
diff --git a/arch/arm/boot/dts/axm5516-amarillo.dts
b/arch/arm/boot/dts/axm5516-amarillo.dts
index a802b52..aabc839 100644
--- a/arch/arm/boot/dts/axm5516-amarillo.dts
+++ b/arch/arm/boot/dts/axm5516-amarillo.dts
@@ -28,6 +28,8 @@
femac {
status = okay;
+ mdio-clock-offset = 0x1c;
+ mdio-clock-period = 0xf0;
};
pcie0 {
diff --git a/arch/powerpc/boot/dts/acp25xx.dts
b/arch/powerpc/boot/dts/acp25xx.dts
index ad9dfe8..e089692 100644
--- a/arch/powerpc/boot/dts/acp25xx.dts
+++ b/arch/powerpc/boot/dts/acp25xx.dts
@@ -178,6 +178,9 @@
// The following will get filled in by
// the boot loader.
mdio-clock = 0;
+ // Not filled in by U-Boot
+ mdio-clock-offset = 0x10;
+ mdio-clock-period = 0x2c;
phy-address = 0;
ad-value = 0;
mac-address = [00 00 00 00 00 00];
diff --git a/arch/powerpc/boot/dts/acp342x.dts
b/arch/powerpc/boot/dts/acp342x.dts
index f947d3b..cbc934f 100644
--- a/arch/powerpc/boot/dts/acp342x.dts
+++ b/arch/powerpc/boot/dts/acp342x.dts
@@ -175,6 +175,9 @@
// The following will get filled in by
// the boot loader.
mdio-clock = 0;
+ // Not filled in by U-Boot
+ mdio-clock-offset = 0x10;
+ mdio-clock-period = 0x2c;
phy-address = 0;
ad-value = 0;
mac-address = [00 00 00 00 00 00];
diff --git a/arch/powerpc/boot/dts/acp344x.dts
b/arch/powerpc/boot/dts/acp344x.dts
index 0efd820..6c07b9d 100644
--- a/arch/powerpc/boot/dts/acp344x.dts
+++ b/arch/powerpc/boot/dts/acp344x.dts
@@ -218,6 +218,9 @@
// The following will get filled in by
// the boot loader.
mdio-clock = 0;
+ // Not filled in by U-Boot
+ mdio-clock-offset = 0x10;
+ mdio-clock-period = 0x2c;
phy-address = 0;
ad-value = 0;
mac-address = [00 00 00 00 00 00];
diff --git a/arch/powerpc/boot/dts/acp35xx.dts
b/arch/powerpc/boot/dts/acp35xx.dts
index 198b41f..b03680b 100644
--- a/arch/powerpc/boot/dts/acp35xx.dts
+++ b/arch/powerpc/boot/dts/acp35xx.dts
@@ -279,6 +279,9 @@
// The following will get filled in by
// the boot loader.
mdio-clock = 0;
+ // offset and period
+ mdio-clock-offset = 0x10;
+ mdio-clock-period = 0x2c;
phy-address = 0;
ad-value = 0;
mac-address = [00 00 00 00 00 00];
diff --git a/drivers/net/ethernet/lsi/lsi_acp_mdio.c
b/drivers/net/ethernet/lsi/lsi_acp_mdio.c
index 6427ae0..b11011f 100644
--- a/drivers/net/ethernet/lsi/lsi_acp_mdio.c
+++ b/drivers/net/ethernet/lsi/lsi_acp_mdio.c
@@ -247,17 +247,12 @@ EXPORT_SYMBOL(acp_mdio_write);
/* acp_mdio_initialize */
static void
-acp_mdio_initialize(void)
+acp_mdio_initialize(int offset, int period)
{
-#ifdef
[linux-yocto] [PATCH 14/15] ARM: axxia: Fix release of CPUs with booted via kexec
From: Anders Berg anders.b...@lsi.com
When booting a crash kernel via kexec, the memory specified by the
cpu-release-addr property is not valid physical memory (not part of
the crash kernel reserved memory area). In this case the memory needs an
ioremap to be written.
Signed-off-by: Anders Berg anders.b...@lsi.com
Signed-off-by: Fredrik Markström fredrik.markst...@gmail.com
---
arch/arm/mach-axxia/platsmp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-axxia/platsmp.c b/arch/arm/mach-axxia/platsmp.c
index 7975c44..0ee417e 100644
--- a/arch/arm/mach-axxia/platsmp.c
+++ b/arch/arm/mach-axxia/platsmp.c
@@ -205,8 +205,8 @@ static void __init axxia_smp_prepare_cpus(unsigned int
max_cpus)
* from reset in hyp mode.
*/
if (!is_hyp_mode_available()) {
- u32 phys_cpu = cpu_logical_map(cpu);
- if (phys_cpu != 0) {
+ if (cpu != 0) {
+ u32 phys_cpu = cpu_logical_map(cpu);
u32 tmp = readl(syscon + 0x1010);
writel(0xab, syscon + 0x1000);
tmp = ~(1 phys_cpu);
@@ -225,10 +225,16 @@ static void __init axxia_smp_prepare_cpus(unsigned int
max_cpus)
* holding pen.
*/
if (release_phys != 0) {
- release_virt = (u32 *)phys_to_virt(release_phys);
+ int is_kmapped = pfn_valid(__phys_to_pfn(release_phys));
+ if (is_kmapped)
+ release_virt = phys_to_virt(release_phys);
+ else
+ release_virt = ioremap(release_phys, PAGE_SIZE);
*release_virt = virt_to_phys(axxia_secondary_startup);
smp_wmb();
__cpuc_flush_dcache_area(release_virt, sizeof(u32));
+ if (!is_kmapped)
+ iounmap(release_virt);
}
}
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PULL REQUEST] Kernel: 3.10 Branch: standard/axxia/base
On 2014-04-28, 1:28 PM, Paul, Charlie wrote:
Bruce,
I resubmitted this request, I had given you the wrong starting point,
this should fix the merge problem
Indeed. This merged as a fastforward to the existing BSP branch and
has now been pushed to the repo.
Bruce
Charlie
The following changes since commit 55bf6f0b78353c34d4910bca7bfc9eed0aff5de4:
Merge branch 'standard/base' into standard/axxia/base (2014-04-01
21:11:34 -0400)
are available in the git repository at:
g...@github.com:butlerpaul/lsikernel-3.10 sab-next-1
for you to fetch changes up to a72435875d8a4b4e5d61779dd823c59fd4180921:
gpio: repairs merge comflict (2014-04-22 14:44:24 -0700)
Anders Berg (13):
i2c-axxia: Fix broken smbus block read
i2c-axxia: Adjust tLOW,tHIGH to match fast-mode requirements
arm/axxia: Workaround for cross-cluster sev issue
Revert LSI AXM55XX: Add GENERIC_LOCKBREAK
Revert LSI AXM55XX: Disable use of wfe/sev in arch spinlock
dma: lsi-dma32: DMA driver configuration update
dma: lsi-dma32: Cleanup DMA driver
mach-axxia: Split device tree into SoC/board parts
arm/axxia: Configure changes to 'GPIO driver for SPI chip selects'
arm/axxia: GPIO driver for SPI chip selects
spi: Revert to mainline spi-pl022
hwmon: Support new revision of LTC2974
i2c-axxia: Use managed functions devm_*
Charlie Paul (3):
i2c-axxia: code update kernel.org coding spec
LSI powerpc/boot: added for rapidio
i2c-axxia: Configure changes to 'Use managed functions devm_*'
David Mercado (3):
LSI FEMAC Ethernet Driver
kernel/irq/manage.c: Fix irq_set_affinity to allow use with buslocks
LSI AXM55xx: Axxia GIC driver improvements (3rd gen)
Gary McGee (2):
LSI AXXIA: fixes for VP engine quiesce and DDR shutdown
arm/axxia: improved robustness for DDR retention
John Jacques (10):
arch/arm/mach-axxia: Updated Device Tree for Emulation
arch/arm/mach-axxia: Accept the new lsi,axm5516-emu Machine
arch/arm/mach-axxia: Disable DDR Retention Resets in Sim/Emu
arch/arm/mach-axxia: Updates to the VMFS File System
LSI RapidIO: Updated Device Trees for rapidio
arch/arm/mach-axxia: Name Cleanup
arch/arm/mach-axxia: Work-Around for Event Problems in v1.0 Silicon
arch/powerpc: Update the Axxia Device Tree Files
arch/powerpc: Clean up of Compatible Names in Axxia Device Trees
LSI drivers/tty: Axxia Serial Driver Update
Jonas Svennebring (2):
ARM: 7840/1: LPAE: don't reject mapping /dev/mem above 4GB
LSI AXXIA: Basic perf support for axxia plaform block provided by
LSI.
Michael Bringmann (2):
LSI AXM55xx: Configuration updates
LSI AXM55xx: Disable linkdown reset configuration.
Paul Butler (2):
i2c: comforming to changes introduced by move of_i2c to core
gpio: repairs merge comflict
SangeethaRao (2):
arch/powerpc: Checking in correct USB entries to ACP3421 DTS
LSI powerpc/sysdev: Removing the power of 2 size restriction
arch/arm/Kconfig |7 +-
arch/arm/boot/dts/Makefile |5 +
arch/arm/boot/dts/axm-sim.dts | 403
arch/arm/boot/dts/axm-ve-tc1.dts | 363 ---
arch/arm/boot/dts/axm-ve-tc2.dts | 174 --
arch/arm/boot/dts/axm5504-cpus.dtsi| 49 +
arch/arm/boot/dts/axm5504-emu.dts | 44 +
arch/arm/boot/dts/axm5504-sim.dts | 127 +
arch/arm/boot/dts/axm5507-cpus.dtsi| 73 +
arch/arm/boot/dts/axm5507-emu.dts | 44 +
arch/arm/boot/dts/axm5508-cpus.dtsi| 81 +
arch/arm/boot/dts/axm5512-cpus.dtsi| 114 +
arch/arm/boot/dts/axm5516-amarillo.dts | 195 ++
arch/arm/boot/dts/axm5516-cpus.dtsi| 145 ++
arch/arm/boot/dts/axm5516-sim.dts | 127 +
arch/arm/boot/dts/axm55xx.dts | 464
arch/arm/boot/dts/axm55xx.dtsi | 390 +++
.../boot/dts/{axm55xxemu.dts = axm55xxemu7.dts} | 17 +-
arch/arm/boot/dts/axm55xxsim.dts | 363 ---
arch/arm/boot/dts/axm55xxsim16.dts | 459
arch/arm/boot/fmboot/Makefile | 12 +-
arch/arm/include/asm/spinlock.h|9 +-
arch/arm/mach-axxia/Makefile |6 +-
arch/arm/mach-axxia/axxia-gic.c| 1138 -
arch/arm/mach-axxia/axxia.c| 66 +-
arch/arm/mach-axxia/clock.c|2 +-
arch/arm/mach-axxia/ddr_retention.c| 255 +-
arch/arm/mach-axxia/ddr_shutdown.c | 332 +++
arch/arm/mach-axxia/ev.c
Re: [linux-yocto] [PATCH 00/15] LSI AXXIA updates to standard/axxia/base 3.10
On 2014-04-28, 8:13 PM, Charlie Paul wrote: Second set of patches ready to go. No complaints from me on this one. All the commits have good short logs and summaries that explain the changes. Nicely done. I can't say that I did a detailed tech review of each one, so I'll trust that testing proves they work as intended :) Cheers, Bruce Anders Berg (9): i2c-axxia: Avoid timeout when interrupt delayed dma: lsi-dma32: Add parameter to setup burst size dma: lsi-dma32: Handle DMA transfer sizes 1MB ARM: axxia: dts: Enable sp804 timers by default ARM: axxia: Cleanup timer init code i2c: axxia: Add support for 10-bit addressing ARM: axxia: Alloc GIC to be initialized from non-primary core ARM: axxia: Fix release of CPUs with booted via kexec ARM: axxia: Flush L3 in kexec_reinit David Mercado (2): LSI AXM55xx: Fix PMU handler issue LSI AXM55xx: Fix CPU hotplug John Jacques (4): arch/powerpc: Disable the ACP NAND Driver for 3500 arch/powerpc: Fix Compile Error when the Target is PowerPC axxia: Use the Device Tree for MDIO Clock Offset/Period if Provided arch/powerpc: Support Older Machine Name for LSI Axxia arch/arm/boot/dts/axm5504-emu.dts|2 + arch/arm/boot/dts/axm5507-emu.dts|2 + arch/arm/boot/dts/axm5516-amarillo.dts |2 + arch/arm/boot/dts/axm55xx.dtsi |1 - arch/arm/mach-axxia/axxia-gic.c | 47 +-- arch/arm/mach-axxia/axxia.c | 102 +++--- arch/arm/mach-axxia/axxia.h |1 + arch/arm/mach-axxia/hotplug.c|2 +- arch/arm/mach-axxia/include/mach/axxia-gic.h |1 - arch/arm/mach-axxia/platsmp.c| 27 ++-- arch/powerpc/boot/dts/acp25xx.dts|3 + arch/powerpc/boot/dts/acp342x.dts|3 + arch/powerpc/boot/dts/acp344x.dts|3 + arch/powerpc/boot/dts/acp35xx.dts|3 + arch/powerpc/platforms/44x/acpx1.c |5 +- drivers/dma/lsi-dma32.c | 185 +++--- drivers/dma/lsi-dma32.h |4 +- drivers/i2c/busses/i2c-axxia.c | 84 +++- drivers/mtd/nand/lsi_acp_nand.c |7 + drivers/net/ethernet/lsi/lsi_acp_mdio.c | 33 +++-- 20 files changed, 306 insertions(+), 211 deletions(-) -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
