Re: [linux-yocto] [meta-intel] how to enable 2nd HDMI port on Intel Atom (bay-trail) E3800 SoC?
On 7/24/15 9:44 AM, Bruce Ashfield wrote: On 15-07-23 04:54 PM, Gerard Bucas wrote: Hi everyone We have a new Intel Atom E3800 (Bay Trail) based board with 2 x HDMI ports. We are using the edk2 firmware (used the minnowBoard MAX firmware source as basis) but we can't seem to get the HDMI-2 port to be recognized by either the firmware or our linux kernel (built with latest yocto project - kernel version is 3.19.5). Can anyone give me some pointers as to what we need in either/both firmware and/or linux kernel to get the 2nd HDMI port to be enumerated/recognized? Please take this question to the edk2-devel mailing list. Take a look at the archives for an example subject for minnow, I believe they tag subjects with [MinnowBoard] or similar to help get the attention of the maintainers. -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH v2 06/11] stmicro: Add support for the STMMAC Ethernet controller family
On 7/6/15, 9:42 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 2015-07-06 12:16 PM, Saul Wold wrote: On 07/06/2015 07:18 AM, Bruce Ashfield wrote: On 2015-07-06 9:55 AM, Paul Gortmaker wrote: [Re: [PATCH v2 06/11] stmicro: Add support for the STMMAC Ethernet controller family] On 05/07/2015 (Sun 22:30) Saul Wold wrote: On 07/05/2015 08:52 PM, Bruce Ashfield wrote: On 2015-07-01 7:15 PM, Darren Hart wrote: On 7/1/15 4:06 PM, Saul Wold wrote: This is needed for the meta-quark BSP which is used by the Galileo Board. Still would like to see this in features/net - or some discussion as to why not. Agreed. We can start a cleanup of the net* fragments with a small bit of effort here. A good example for any following SOCs. I have updated my branch linux-yocto-contrib/sgw/refactor-wip with this change along with the rest of the refactoring of the x86/x86_64 and x86_base changes. One of the key differences is the way we handle MTRR_SANITIZER, by removing the not set as Darren recommended we get the following difference: # CONFIG_MTRR_SANITIZER is not set --- CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 Paul G was the person that added the not set to have it match the kernel.org defconfig for x86/x86_64. Since the default is disabled is there any reason to continue explicitly saying not set? There are a couple reasons I typically do sth. like that. One is that it makes it explicitly clear that it was a choice and not just a lets go with the default, even if in this case the underlying reason was to get better alignment with the defconfig (which is _not_ the same as taking the defaults for everything). Another reason, is that if the default changes, you won't just get swept along for the ride without knowing what happened. You will stay where you were until you decide whether you consciously want to align with the new default. I'm also a fan of not relying on defaults for configs we care about (as we all know, we don't set them all) for the same reasons paul highlights. And finally, (assuming that this is set at a higher level) you will get a warning from the config audit about the divergence from the more global value if a later level (in config prio) BSP decides to change it. Yep, and even if something selects it (to change our default), we'll get a log in the configuration audit. Of course none of these are critical, and if we have a lot of BSPs that want it on, then the explicit not set may not make sense anymore and hence rolling back to accepting the default to make BSP life easier may be the right thing to do; I don't have enough context to know, given that I just got dragged into this discussion now. :) Agreed as well. We all got dragged into this as I started the refactor and Darren asked the questions. I looked at the Kconfig description for MTRR_SANITIZER and related and it seems safe to enable it as default. Bruce, do you want me include or exclude the MTRR_SANITIZER in a v4? Let's try it as a default to 'on' for the x86 platforms. I thought Paul made a strong case for leaving it is not set. It wasn't that I objected to it being is not set, I just wanted to know the reasoning for it. Keeping close to defconfig unless there is a specific reason not to makes a lot of sense to me. For one thing, we'll be testing and using what has seen the broadest usage in industry. I suggest leaving it as is not set, but include a comment as to why. Thanks for the context Paul. -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 07/10] stmicro: Add support for the STMMAC Ethernet controller family
On 7/1/15 9:57 AM, Saul Wold wrote: This is needed for the x1000 SOC platform This is on the SoC itself? Not an additional chip on the board? Signed-off-by: Saul Wold s...@linux.intel.com --- meta/cfg/kernel-cache/features/stmicro/stmmac.cfg | 6 ++ meta/cfg/kernel-cache/features/stmicro/stmmac.scc | 2 ++ 2 files changed, 8 insertions(+) create mode 100644 meta/cfg/kernel-cache/features/stmicro/stmmac.cfg create mode 100644 meta/cfg/kernel-cache/features/stmicro/stmmac.scc diff --git a/meta/cfg/kernel-cache/features/stmicro/stmmac.cfg b/meta/cfg/kernel-cache/features/stmicro/stmmac.cfg new file mode 100644 index 000..63e06d61 --- /dev/null +++ b/meta/cfg/kernel-cache/features/stmicro/stmmac.cfg @@ -0,0 +1,6 @@ +CONFIG_NET_CORE=y +CONFIG_ETHERNET=y +CONFIG_NET_VENDOR_STMICRO=y +CONFIG_STMMAC_ETH=y +CONFIG_STMMAC_PLATFORM=y +CONFIG_STMMAC_PCI=y diff --git a/meta/cfg/kernel-cache/features/stmicro/stmmac.scc b/meta/cfg/kernel-cache/features/stmicro/stmmac.scc new file mode 100644 index 000..7951713b --- /dev/null +++ b/meta/cfg/kernel-cache/features/stmicro/stmmac.scc @@ -0,0 +1,2 @@ + +kconf hardware stmmac.cfg Taking a closer look at the current set of features, they are mostly topical, rather than vendor. I'm surprised to find we don't have a net in there yet. We do have net in cfg (rather than features), but that's more about protocols than drivers (inexplicably so). In my opinion, this would be better organized as: features/ net/ net.scc net.cfg net-all.scc stmicro/ stmmac.scc (includes net.cfg) stmmac.cfg Similar to the features/media setup. Bruce, any preference? I think we need a couple of READMEs in the kernel-cache hierarchy (cfg, features, ktype, etc. to help guide folks creating fragments). I would suggest following the Kconfig hierarchy as much as possible to avoid confusion. -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 03/10] cfg/intel: Add Intel Vendor Specific enabler
On 7/1/15 9:57 AM, Saul Wold wrote: As part of the larger breaking up of x86 put the Intel Vendor Enablers in their own file Signed-off-by: Saul Wold s...@linux.intel.com --- meta/cfg/kernel-cache/cfg/intel.cfg | 19 +++ meta/cfg/kernel-cache/cfg/intel.scc | 1 + 2 files changed, 20 insertions(+) create mode 100644 meta/cfg/kernel-cache/cfg/intel.cfg create mode 100644 meta/cfg/kernel-cache/cfg/intel.scc diff --git a/meta/cfg/kernel-cache/cfg/intel.cfg b/meta/cfg/kernel-cache/cfg/intel.cfg new file mode 100644 index 000..108022e --- /dev/null +++ b/meta/cfg/kernel-cache/cfg/intel.cfg @@ -0,0 +1,19 @@ +# Config settings specific to intel processors +CONFIG_MICROCODE=y +CONFIG_MICROCODE_INTEL=y +CONFIG_MICROCODE_EARLY=y +CONFIG_MICROCODE_INTEL_EARLY=y + + +CONFIG_PROCESSOR_SELECT=y +CONFIG_CPU_SUP_INTEL=y + +CONFIG_X86_EXTENDED_PLATFORM=y +CONFIG_X86_PLATFORM_DEVICES=y +CONFIG_X86_INTEL_MID=y +CONFIG_X86_INTEL_QUARK=y +CONFIG_X86_INTEL_LPSS=y I was going to push back on LPSS, like with PCI and hotplug, but it's a single option here, contained properly to intel.cfg, and unlikely to be not wanted on any recent, current, or near future SoC as far as I can tell so this is actually fine with me. -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 04/10] common-pc-drivers: Move CONFIG_HOTPLUG_PCI from cfg/x86
On 7/1/15 9:57 AM, Saul Wold wrote: As part of the broader refactor move this item out of the core cpu configuration items I agree this shouldn't be in the arch definition, but common-pc-drivers seems a bit too far the other way. There is a cfg/pci bucket. Seems to me that would be a good place for it, and common-pc-drivers.scc should include the set of bus options it requires from there. That way other systems that want to specialize, can also resuse the cfg/pci organization without have to duplicate the fragment contents or include all of common-pc-drivers. Signed-off-by: Saul Wold s...@linux.intel.com --- meta/cfg/kernel-cache/bsp/common-pc/common-pc-drivers.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/cfg/kernel-cache/bsp/common-pc/common-pc-drivers.cfg b/meta/cfg/kernel-cache/bsp/common-pc/common-pc-drivers.cfg index 0b82190..26d7c4a 100644 --- a/meta/cfg/kernel-cache/bsp/common-pc/common-pc-drivers.cfg +++ b/meta/cfg/kernel-cache/bsp/common-pc/common-pc-drivers.cfg @@ -1,6 +1,7 @@ CONFIG_PCI=y CONFIG_PCIEPORTBUS=y CONFIG_PCI_MSI=y +CONFIG_HOTPLUG_PCI=y CONFIG_ATA=y CONFIG_ATA_ACPI=y -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 09/10] features/usb/serial-vendors: Add new set of configs for USB_SERIAL devices
On 7/1/15 9:57 AM, Saul Wold wrote: This config fragment will enable the various vendor module code for different USB serial devices to enable serial over usb. Signed-off-by: Saul Wold s...@linux.intel.com --- meta/cfg/kernel-cache/features/usb/serial-vendor.cfg | 17 + meta/cfg/kernel-cache/features/usb/serial-vendor.scc | 4 2 files changed, 21 insertions(+) create mode 100644 meta/cfg/kernel-cache/features/usb/serial-vendor.cfg create mode 100644 meta/cfg/kernel-cache/features/usb/serial-vendor.scc diff --git a/meta/cfg/kernel-cache/features/usb/serial-vendor.cfg b/meta/cfg/kernel-cache/features/usb/serial-vendor.cfg new file mode 100644 index 000..be74467 --- /dev/null +++ b/meta/cfg/kernel-cache/features/usb/serial-vendor.cfg @@ -0,0 +1,17 @@ +CONFIG_USB_SERIAL=y +CONFIG_USB_SERIAL_GENERIC=y +CONFIG_USB_SERIAL_ARK3116=m +CONFIG_USB_SERIAL_BELKIN=m +CONFIG_USB_SERIAL_CH341=m +CONFIG_USB_SERIAL_CP210X=m +CONFIG_USB_SERIAL_FTDI_SIO=m +CONFIG_USB_SERIAL_F81232=m +CONFIG_USB_SERIAL_IPW=m +CONFIG_USB_SERIAL_PL2303=m +CONFIG_USB_SERIAL_OTI6858=m +CONFIG_USB_SERIAL_QUALCOMM=m +CONFIG_USB_SERIAL_SPCP8X5=m +CONFIG_USB_SERIAL_SIERRAWIRELESS=m +CONFIG_USB_SERIAL_TI=m +CONFIG_USB_SERIAL_WWAN=m +CONFIG_USB_SERIAL_OPTION=m diff --git a/meta/cfg/kernel-cache/features/usb/serial-vendor.scc b/meta/cfg/kernel-cache/features/usb/serial-vendor.scc Suggest serial-all.scc instead of serial-vendor, just to keep it consistent with things like media-all.scc. new file mode 100644 index 000..3b06793 --- /dev/null +++ b/meta/cfg/kernel-cache/features/usb/serial-vendor.scc @@ -0,0 +1,4 @@ +define KFEATURE_DESCRIPTION Enable USB serial support for all vendors +define KFEATURE_COMPATIBILITY board + +kconf hardware serial_vendor.cfg -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 05/10] cfg/x86_base: Create new base config for x86 Architectures
On 7/1/15 9:57 AM, Saul Wold wrote: Place the core x86 architecture kernel config items into a new base config that the other x86 related architectures will use Signed-off-by: Saul Wold s...@linux.intel.com --- meta/cfg/kernel-cache/cfg/x86_base.cfg | 9 + meta/cfg/kernel-cache/cfg/x86_base.scc | 4 2 files changed, 13 insertions(+) create mode 100644 meta/cfg/kernel-cache/cfg/x86_base.cfg create mode 100644 meta/cfg/kernel-cache/cfg/x86_base.scc diff --git a/meta/cfg/kernel-cache/cfg/x86_base.cfg b/meta/cfg/kernel-cache/cfg/x86_base.cfg new file mode 100644 index 000..39263ef --- /dev/null +++ b/meta/cfg/kernel-cache/cfg/x86_base.cfg @@ -0,0 +1,9 @@ +CONFIG_X86=y +CONFIG_X86_MSR=y +CONFIG_X86_CPUID=y +CONFIG_MTRR=y +CONFIG_PCI_MSI=y PCI_MSI seems a strange option for this list. It depends on PCI=y which isn't specified. It is automatically selected for one case (AMD specific). Curious how this ended up here. + +CONFIG_X86_CHECK_BIOS_CORRUPTION=y +CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y +# CONFIG_MTRR_SANITIZER is not set Since this is expressly disabling something that is recommended to leave on, and which has a enable/disable default, and can be controlled via the command line - we need a specific reason for disabling MTRR_SANITIZER. Do we have a compelling case for disabling this on ALL x86 systems? diff --git a/meta/cfg/kernel-cache/cfg/x86_base.scc b/meta/cfg/kernel-cache/cfg/x86_base.scc new file mode 100644 index 000..a75808d --- /dev/null +++ b/meta/cfg/kernel-cache/cfg/x86_base.scc @@ -0,0 +1,4 @@ +include efi.scc +include timer/hpet.scc +include timer/no_hz.scc +kconf hardware x86_base.cfg -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH v2 06/11] stmicro: Add support for the STMMAC Ethernet controller family
On 7/1/15 4:06 PM, Saul Wold wrote: This is needed for the meta-quark BSP which is used by the Galileo Board. Still would like to see this in features/net - or some discussion as to why not. Signed-off-by: Saul Wold s...@linux.intel.com --- meta/cfg/kernel-cache/features/stmicro/stmmac.cfg | 6 ++ meta/cfg/kernel-cache/features/stmicro/stmmac.scc | 2 ++ 2 files changed, 8 insertions(+) create mode 100644 meta/cfg/kernel-cache/features/stmicro/stmmac.cfg create mode 100644 meta/cfg/kernel-cache/features/stmicro/stmmac.scc diff --git a/meta/cfg/kernel-cache/features/stmicro/stmmac.cfg b/meta/cfg/kernel-cache/features/stmicro/stmmac.cfg new file mode 100644 index 000..63e06d61 --- /dev/null +++ b/meta/cfg/kernel-cache/features/stmicro/stmmac.cfg @@ -0,0 +1,6 @@ +CONFIG_NET_CORE=y +CONFIG_ETHERNET=y +CONFIG_NET_VENDOR_STMICRO=y +CONFIG_STMMAC_ETH=y +CONFIG_STMMAC_PLATFORM=y +CONFIG_STMMAC_PCI=y diff --git a/meta/cfg/kernel-cache/features/stmicro/stmmac.scc b/meta/cfg/kernel-cache/features/stmicro/stmmac.scc new file mode 100644 index 000..7951713b --- /dev/null +++ b/meta/cfg/kernel-cache/features/stmicro/stmmac.scc @@ -0,0 +1,2 @@ + +kconf hardware stmmac.cfg -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH v2 03/11] cfg/intel: Add Intel Vendor Specific enabler
On 7/1/15 4:06 PM, Saul Wold wrote: As part of the larger breaking up of x86 put the Intel Vendor Enablers in their own file Signed-off-by: Saul Wold s...@linux.intel.com --- meta/cfg/kernel-cache/cfg/intel.cfg | 19 +++ meta/cfg/kernel-cache/cfg/intel.scc | 1 + 2 files changed, 20 insertions(+) create mode 100644 meta/cfg/kernel-cache/cfg/intel.cfg create mode 100644 meta/cfg/kernel-cache/cfg/intel.scc diff --git a/meta/cfg/kernel-cache/cfg/intel.cfg b/meta/cfg/kernel-cache/cfg/intel.cfg new file mode 100644 index 000..108022e --- /dev/null +++ b/meta/cfg/kernel-cache/cfg/intel.cfg @@ -0,0 +1,19 @@ +# Config settings specific to intel processors +CONFIG_MICROCODE=y +CONFIG_MICROCODE_INTEL=y +CONFIG_MICROCODE_EARLY=y +CONFIG_MICROCODE_INTEL_EARLY=y + + +CONFIG_PROCESSOR_SELECT=y +CONFIG_CPU_SUP_INTEL=y + +CONFIG_X86_EXTENDED_PLATFORM=y +CONFIG_X86_PLATFORM_DEVICES=y +CONFIG_X86_INTEL_MID=y +CONFIG_X86_INTEL_QUARK=y I doubt this is a significant overhead, so I don't really care - but reviewing this again, I remember seeing intel-quark.cfg - it seems likely that anyone using a quark will use intel-quark, and anyone not using intel-quark will not try to boot on quark - so X86_INTEL_QUARK here is probably unnecessary. Again, not a big deal.\ -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH v2 00/11] Introduce new quark BSP with refactor and additional features
On 7/1/15 4:06 PM, Saul Wold wrote: Bruce: This patch set introduces several new feautres and begins a refactor of the x86 cfg files to have a common base. This also introduces the Quark/X1000 BSP with basic drivers enabled. Updates in v2: - addressed issues raised by Darren - Moved PCI related to features/pci - removed PCI_MSI and MTRR_SANITIZER not set from x86_base - renamed serial-vendor - erial-all - Added misc/bosch-pressure-sensor-i2c - updated Quark/X1000 soc and bsp configs I am leaving stmicro alone for now, I hope that we don't hold this up for a further refactor. I'm out for a few days, so with the exception of the 2 comments to 3/11 and 6/11, this series looks good to me: Reviewed-by: Darren Hart dvh...@linux.intel.com (minus 3/11 and 6/11) -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH v3 11/11] Quark/X1000: Add new SOC and BSP
On 7/1/15 4:35 PM, Saul Wold wrote: Add the new intel-quark bsp type using the refactored x86_base and Intel Vendor enablers. Create a new soc for the x1000 SOC package. Signed-off-by: Saul Wold s...@linux.intel.com --- v2: Updated for additional refactor related changes - use pci.scc - added serial.scc Seems to me serial would be better added to intel-quark-standard, rather than the intel-common/intel-quark which is more about the SoC than the board. Stands to reason people may want the SoC enabling fragments without a load of extra drivers that are not necessary to use the SoC (like USB Serial drivers). I have assumed this are to plug in USB to serial adapters to the board - and are not somehow integrated on the board. Is that not a correct assumption? -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH v3 11/11] Quark/X1000: Add new SOC and BSP
On 7/1/15, 5:36 PM, Saul Wold s...@linux.intel.com wrote: On 07/01/2015 05:28 PM, Darren Hart wrote: On 7/1/15 4:35 PM, Saul Wold wrote: Add the new intel-quark bsp type using the refactored x86_base and Intel Vendor enablers. Create a new soc for the x1000 SOC package. Signed-off-by: Saul Wold s...@linux.intel.com --- v2: Updated for additional refactor related changes - use pci.scc - added serial.scc Seems to me serial would be better added to intel-quark-standard, rather than the intel-common/intel-quark which is more about the SoC than the board. Stands to reason people may want the SoC enabling fragments without a load of extra drivers that are not necessary to use the SoC (like USB Serial drivers). I have assumed this are to plug in USB to serial adapters to the board - and are not somehow integrated on the board. Is that not a correct assumption? Yes, plugin, I can move them, I guess I was trying to follow the core* standard a bit differently then you intended and that the features/soc/x1000 was the SOC side and intel-quark was more the general guark/x1000 based devices using x1000. I worded that poorly. Intel-quark is more about the board itself and not how it's used. While standard/tiny/preempt-rt make policy decision about how it's used, including which extra drivers should be included in the build. The -standard, -premept and -tiny will eventually use the intel-quark, and I can see both points of view where -tiny might not want usb-serial, or might want a very specific one for tethering something else. I will let this soak until next week and we can revisit it. Sau! -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] Minimal GPLv3-free x86 image
On 5/13/15, 12:11 AM, Dan Rosenqvist da...@kth.se wrote: Hi, Hi Dan, I'm trying to create a minimal GPLv3-free x86 image using the yocto project. As I'm looking for ways around the GPLv3 license, I'm unable to use certain packages (such as the live-install which depends on parted, and grub-2.0). First - I am not a lawyer - just getting that out there. Instead I'm trying to create a minimal filesystem, stored as a tarball, which includes grub-0.97. So dropping the live image type avoids the first set of issues. Is your target system using legacy PC BIOS or UEFI? If UEFI, then you can specify EFI_PROVIDER = gummiboot and use that instead of grub-efi as gummiboot is LGPL v2. If you are using PC BIOS, have you considered not using grub at all and just relying on syslinux, GPL v2 or later. To install the image in the target environment (currently a virtual machine) I use a small bootable linux image used to set up the partitions and extracting the tarball image. After doing so, I mount proc and dev to be able to chroot into the target file system and run grub-install (to set up grub in the mbr). However, grub-install seem to segfault (a lot), and later prints out that the installation was successful. Grub-install is a nightmare in my experience, and doubly so in atypical environments as you describe. Without a lot more diagnostics, straces, etc, I can't offer much advice. Which device are you attempting to install grub to? This methodology has previously been working with gentoo minimal builds. Same version of Grub? -- Darren It feels like I can't be the only one who is in need of a minimalistic GPLv3-free x86 build, is there someone here who might be able to guide me in the right direction? Regards, Dan -- ___ yocto mailing list yocto@yoctoproject.orghttps://lists.yoctoproject.org/listinfo/yocto -- Darren Hart Intel Open Source Technology Center -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH 2/2] baytrail: move PINCTRL to new intel-pinctrl
On 3/24/15 4:47 PM, Saul Wold wrote: Since we add BAYTRAIL to the intel-pinctrl remove it from here along with the PINCONF and PINMUX since they will be selected automagically. Signed-off-by: Saul Wold s...@linux.intel.com Acked-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg | 5 + meta/cfg/kernel-cache/features/soc/baytrail/baytrail.scc | 1 + 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg b/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg index 96e54aa..bdaa563 100644 --- a/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg +++ b/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg @@ -12,10 +12,7 @@ CONFIG_CHR_DEV_SG=y CONFIG_X86_INTEL_LPSS=y -# Pinctrl and GPIO Support -CONFIG_PINMUX=y -CONFIG_PINCONF=y -CONFIG_PINCTRL_BAYTRAIL=y +# GPIO Support CONFIG_GPIOLIB=y CONFIG_GPIO_SYSFS=y diff --git a/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.scc b/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.scc index c593896..33a6ecd 100644 --- a/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.scc +++ b/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.scc @@ -9,5 +9,6 @@ include features/power/intel.scc include features/usb/xhci-hcd.scc include features/usb/ehci-hcd.scc +include features/intel-pinctrl/intel-pinctrl.scc kconf hardware baytrail.cfg -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH][meta][dev][3.19][3.14] tiny.cfg: Enable BINFMT_SCRIPT
Ed, Would you update the SRC_REVs, test the final result, and submit the patches? (I only just swooped in here for an hour yesterday, so if the above is inconsistent with what RP has been asking, please defer to him. I'm asking Ed because if it is dependent on me it won't get done until EOD tomorrow.) -- Darren On 3/18/15, 10:08 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 03/18/2015 01:57 PM, Darren Hart wrote: Tiny kernels currently fail to run /init from tiny-init, a #!/bin/sh script as the kernel is missing BINFMT_SCRIPT. Add this to the tiny.cfg fragment. Thanks! Merged to 3.19 and 3.14 meta branches. Update your SRCREVs appropriately, and I'll do a full linux-yocto update shortly as well. Bruce Developed on 3.19, applied and verified on 3.14. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Richard Purdie richard.pur...@linuxfoundation.org Cc: Saul Wold s...@linux.intel.com Cc: Eduard Bartosh eduard.bart...@intel.com --- meta/cfg/kernel-cache/ktypes/tiny/tiny.cfg | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/cfg/kernel-cache/ktypes/tiny/tiny.cfg b/meta/cfg/kernel-cache/ktypes/tiny/tiny.cfg index 7c06aa4..299e9be 100644 --- a/meta/cfg/kernel-cache/ktypes/tiny/tiny.cfg +++ b/meta/cfg/kernel-cache/ktypes/tiny/tiny.cfg @@ -26,3 +26,6 @@ CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=1 CONFIG_BLK_DEV_RAM_SIZE=6144 CONFIG_RD_GZIP=y + +# Support /init as a script and #!/bin/sh in general +CONFIG_BINFMT_SCRIPT=y -- Darren Hart Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH][meta][dev][3.19][3.14] tiny.cfg: Enable BINFMT_SCRIPT
Tiny kernels currently fail to run /init from tiny-init, a #!/bin/sh script as the kernel is missing BINFMT_SCRIPT. Add this to the tiny.cfg fragment. Developed on 3.19, applied and verified on 3.14. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Richard Purdie richard.pur...@linuxfoundation.org Cc: Saul Wold s...@linux.intel.com Cc: Eduard Bartosh eduard.bart...@intel.com --- meta/cfg/kernel-cache/ktypes/tiny/tiny.cfg | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/cfg/kernel-cache/ktypes/tiny/tiny.cfg b/meta/cfg/kernel-cache/ktypes/tiny/tiny.cfg index 7c06aa4..299e9be 100644 --- a/meta/cfg/kernel-cache/ktypes/tiny/tiny.cfg +++ b/meta/cfg/kernel-cache/ktypes/tiny/tiny.cfg @@ -26,3 +26,6 @@ CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=1 CONFIG_BLK_DEV_RAM_SIZE=6144 CONFIG_RD_GZIP=y + +# Support /init as a script and #!/bin/sh in general +CONFIG_BINFMT_SCRIPT=y -- 2.1.4 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend
On 2/25/15, 12:54 AM, Robert P. J. Day rpj...@crashcourse.ca wrote:
minor quibble about kernel dev manual -- section 2.2.1, creating
the append file, uses the example of:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
while section 2.2.3 uses:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
both sections kind of implying that that's the way to do it, without
making it clear that *either* way works as long as the variable
prepend matches up with the directory name.
both ways are correct, of course, but the wording is a bit
confusing.
Thanks, I agree, the same syntax should be used throughout the document.
The FILESEXTRAPATHS variable does correctly link to the ref manual where
people can get details on usage.
For simplicity, I should using files instead of ${PN}, it avoids the
make sure your directory name matches ${PN} issue.
--
Darren Hart
Intel Open Source Technology Center
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel dev manual: KBRANCH_DEFAULT is dead, jim.
Good catch, thanks Robert. Care to send a patch to the documentation? On 2/25/15, 3:20 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: ch 3 still refers to the variable KBRANCH_DEFAULT even though that variable was tossed back in march of 2014: commit e631fc989b08873f559c5927117301294f04298c Author: Bruce Ashfield bruce.ashfi...@windriver.com Date: Tue Mar 18 23:01:19 2014 -0400 kernel-yocto: remove KBRANCH_DEFAULT KBRANCH_DEFAULT is no longer used, so we can remove it from all recipes (and it won't be missed). rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Darren Hart Intel Open Source Technology Center -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] more observations on kernel dev manual
On 2/25/15, 2:52 AM, Robert P. J. Day rpj...@crashcourse.ca wrote: been a while since i went through this manual so some probably simple observations -- based on in-progress manual. if scott rifenbark wants to process any of this, he has my blessing. Thanks for your review of the document Robert. For future comments, please do include the author on Cc. ... section 2.3.2: hang on ... Complete a build at least through the kernel configuration task as follows: $ bitbake linux-yocto -c kernel_configme -f but i thought that -c command would run *only* that bitbake task ... the wording suggests that that command will run everything *up to* that task. It will run everything necessary up to and including that task. If everything, including that task, have already been run, it will run only the specified task again. You can verify this with: 1 $ bitbake virtual/kernel 2 $ bitbake virtual/kernel -c kernel_configme -f 3 $ bitbake virtual/kernel -c cleansstate 4 $ bitbake virtual/kernel -c kernel_configme -f #2 will only run kernel_configme #4 will run everything after fetch up to and including kernel_configme. This usage helps us keep the documentation concise rather than having to spell out how to get to a specific state in order for the command used to work correctly. also in that section, are not't should just say aren't in sample warning output. This output should be updated for 1.8 as config warnings are now sent to the console and not just buried in the logs. Yay! -- Darren Hart Intel Open Source Technology Center -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH] x86: Support 32 bit binaries
Fixes [YOCTO 6777] Unable to set CONFIG_COMPAT=y to kernel config Add support for running 32 bit binaries to the x32 and x86_64 fragments. This supports legacy software and is follows the recommendation in the Kconfig help. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/cfg/x32.cfg| 3 +++ meta/cfg/kernel-cache/cfg/x86_64.cfg | 4 2 files changed, 7 insertions(+) diff --git a/meta/cfg/kernel-cache/cfg/x32.cfg b/meta/cfg/kernel-cache/cfg/x32.cfg index 725e05f..bbe0201 100644 --- a/meta/cfg/kernel-cache/cfg/x32.cfg +++ b/meta/cfg/kernel-cache/cfg/x32.cfg @@ -1 +1,4 @@ CONFIG_X86_X32=y + +# Support running 32 bit binaries +CONFIG_COMPAT=y diff --git a/meta/cfg/kernel-cache/cfg/x86_64.cfg b/meta/cfg/kernel-cache/cfg/x86_64.cfg index 5133fc2..f6dab86 100644 --- a/meta/cfg/kernel-cache/cfg/x86_64.cfg +++ b/meta/cfg/kernel-cache/cfg/x86_64.cfg @@ -13,3 +13,7 @@ CONFIG_MTRR=y CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_PCIE is not set CONFIG_PCI_MSI=y + +# Support running 32 bit binaries +CONFIG_IA32_EMULATION=y +CONFIG_COMPAT=y -- 2.1.0 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 0/2] Fix BPF merge build breakage
The merge of the net BPF stuff appears to have broken the pch_gbe driver. Backporting these two additional patches from mainline gets the driver building again. -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 1/2] net: ptp: use sk_unattached_filter_create() for BPF
From: Daniel Borkmann dbork...@redhat.com
This patch migrates an open-coded sk_run_filter() implementation with
proper use of the BPF API, that is, sk_unattached_filter_create(). This
migration is needed, as we will be internally transforming the filter
to a different representation, and therefore needs to be decoupled.
It is okay to do so as skb_timestamping_init() is called during
initialization of the network stack in core initcall via sock_init().
This would effectively also allow for PTP filters to be jit compiled if
bpf_jit_enable is set.
For better readability, there are also some newlines introduced, also
ptp_classify.h is only in kernel space.
Joint work with Alexei Starovoitov.
Signed-off-by: Daniel Borkmann dbork...@redhat.com
Signed-off-by: Alexei Starovoitov a...@plumgrid.com
Cc: Richard Cochran richard.coch...@omicron.at
Cc: Jiri Benc jb...@redhat.com
Signed-off-by: David S. Miller da...@davemloft.net
(cherry picked from commit e62d2df084e2849edffb206559725fa81bb569a8)
---
include/linux/ptp_classify.h | 4
net/core/timestamping.c | 21 ++---
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/include/linux/ptp_classify.h b/include/linux/ptp_classify.h
index 1dc420b..3decfa4 100644
--- a/include/linux/ptp_classify.h
+++ b/include/linux/ptp_classify.h
@@ -27,11 +27,7 @@
#include linux/if_vlan.h
#include linux/ip.h
#include linux/filter.h
-#ifdef __KERNEL__
#include linux/in.h
-#else
-#include netinet/in.h
-#endif
#define PTP_CLASS_NONE 0x00 /* not a PTP event message */
#define PTP_CLASS_V10x01 /* protocol version 1 */
diff --git a/net/core/timestamping.c b/net/core/timestamping.c
index 661b5a4..e43d56a 100644
--- a/net/core/timestamping.c
+++ b/net/core/timestamping.c
@@ -23,16 +23,13 @@
#include linux/skbuff.h
#include linux/export.h
-static struct sock_filter ptp_filter[] = {
- PTP_FILTER
-};
+static struct sk_filter *ptp_insns __read_mostly;
static unsigned int classify(const struct sk_buff *skb)
{
- if (likely(skb-dev
- skb-dev-phydev
+ if (likely(skb-dev skb-dev-phydev
skb-dev-phydev-drv))
- return sk_run_filter(skb, ptp_filter);
+ return SK_RUN_FILTER(ptp_insns, skb);
else
return PTP_CLASS_NONE;
}
@@ -60,11 +57,13 @@ void skb_clone_tx_timestamp(struct sk_buff *skb)
if (likely(phydev-drv-txtstamp)) {
if (!atomic_inc_not_zero(sk-sk_refcnt))
return;
+
clone = skb_clone(skb, GFP_ATOMIC);
if (!clone) {
sock_put(sk);
return;
}
+
clone-sk = sk;
phydev-drv-txtstamp(phydev, clone, type);
}
@@ -89,12 +88,15 @@ void skb_complete_tx_timestamp(struct sk_buff *skb,
}
*skb_hwtstamps(skb) = *hwtstamps;
+
serr = SKB_EXT_ERR(skb);
memset(serr, 0, sizeof(*serr));
serr-ee.ee_errno = ENOMSG;
serr-ee.ee_origin = SO_EE_ORIGIN_TIMESTAMPING;
skb-sk = NULL;
+
err = sock_queue_err_skb(sk, skb);
+
sock_put(sk);
if (err)
kfree_skb(skb);
@@ -135,5 +137,10 @@ EXPORT_SYMBOL_GPL(skb_defer_rx_timestamp);
void __init skb_timestamping_init(void)
{
- BUG_ON(sk_chk_filter(ptp_filter, ARRAY_SIZE(ptp_filter)));
+ static struct sock_filter ptp_filter[] = { PTP_FILTER };
+ struct sock_fprog ptp_prog = {
+ .len = ARRAY_SIZE(ptp_filter), .filter = ptp_filter,
+ };
+
+ BUG_ON(sk_unattached_filter_create(ptp_insns, ptp_prog));
}
--
2.1.0
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 2/2] net: ptp: do not reimplement PTP/BPF classifier
From: Daniel Borkmann dbork...@redhat.com
There are currently pch_gbe, cpts, and ixp4xx_eth drivers that open-code
and reimplement a BPF classifier for the PTP protocol. Since all of them
effectively do the very same thing and load the very same PTP/BPF filter,
we can just consolidate that code by introducing ptp_classify_raw() in
the time-stamping core framework which can be used in drivers.
As drivers get initialized after bootstrapping the core networking
subsystem, they can make use of ptp_insns wrapped through
ptp_classify_raw(), which allows to simplify and remove PTP classifier
setup code in drivers.
Joint work with Alexei Starovoitov.
Signed-off-by: Daniel Borkmann dbork...@redhat.com
Signed-off-by: Alexei Starovoitov a...@plumgrid.com
Cc: Richard Cochran richard.coch...@omicron.at
Cc: Jiri Benc jb...@redhat.com
Signed-off-by: David S. Miller da...@davemloft.net
(cherry picked from commit 164d8c6665213c931645578310256da7b1259331)
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 11 +--
drivers/net/ethernet/ti/cpts.c | 10 +-
drivers/net/ethernet/xscale/ixp4xx_eth.c | 11 +--
include/linux/ptp_classify.h | 10 ++
net/core/timestamping.c | 8 +++-
5 files changed, 12 insertions(+), 38 deletions(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 464e910..73e6683 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -120,10 +120,6 @@ static void pch_gbe_mdio_write(struct net_device *netdev,
int addr, int reg,
int data);
static void pch_gbe_set_multi(struct net_device *netdev);
-static struct sock_filter ptp_filter[] = {
- PTP_FILTER
-};
-
static int pch_ptp_match(struct sk_buff *skb, u16 uid_hi, u32 uid_lo, u16
seqid)
{
u8 *data = skb-data;
@@ -131,7 +127,7 @@ static int pch_ptp_match(struct sk_buff *skb, u16 uid_hi,
u32 uid_lo, u16 seqid)
u16 *hi, *id;
u32 lo;
- if (sk_run_filter(skb, ptp_filter) == PTP_CLASS_NONE)
+ if (ptp_classify_raw(skb) == PTP_CLASS_NONE)
return 0;
offset = ETH_HLEN + IPV4_HLEN(data) + UDP_HLEN;
@@ -2635,11 +2631,6 @@ static int pch_gbe_probe(struct pci_dev *pdev,
adapter-ptp_pdev = pci_get_bus_and_slot(adapter-pdev-bus-number,
PCI_DEVFN(12, 4));
- if (ptp_filter_init(ptp_filter, ARRAY_SIZE(ptp_filter))) {
- dev_err(pdev-dev, Bad ptp filter\n);
- ret = -EINVAL;
- goto err_free_netdev;
- }
netdev-netdev_ops = pch_gbe_netdev_ops;
netdev-watchdog_timeo = PCH_GBE_WATCHDOG_PERIOD;
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index 8c351f1..fd31546 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -31,10 +31,6 @@
#ifdef CONFIG_TI_CPTS
-static struct sock_filter ptp_filter[] = {
- PTP_FILTER
-};
-
#define cpts_read32(c, r) __raw_readl(c-reg-r)
#define cpts_write32(c, v, r) __raw_writel(v, c-reg-r)
@@ -300,7 +296,7 @@ static u64 cpts_find_ts(struct cpts *cpts, struct sk_buff
*skb, int ev_type)
u64 ns = 0;
struct cpts_event *event;
struct list_head *this, *next;
- unsigned int class = sk_run_filter(skb, ptp_filter);
+ unsigned int class = ptp_classify_raw(skb);
unsigned long flags;
u16 seqid;
u8 mtype;
@@ -371,10 +367,6 @@ int cpts_register(struct device *dev, struct cpts *cpts,
int err, i;
unsigned long flags;
- if (ptp_filter_init(ptp_filter, ARRAY_SIZE(ptp_filter))) {
- pr_err(cpts: bad ptp filter\n);
- return -EINVAL;
- }
cpts-info = cpts_info;
cpts-clock = ptp_clock_register(cpts-info, dev);
if (IS_ERR(cpts-clock)) {
diff --git a/drivers/net/ethernet/xscale/ixp4xx_eth.c
b/drivers/net/ethernet/xscale/ixp4xx_eth.c
index 25283f1..f7e0f0f 100644
--- a/drivers/net/ethernet/xscale/ixp4xx_eth.c
+++ b/drivers/net/ethernet/xscale/ixp4xx_eth.c
@@ -256,10 +256,6 @@ static int ports_open;
static struct port *npe_port_tab[MAX_NPES];
static struct dma_pool *dma_pool;
-static struct sock_filter ptp_filter[] = {
- PTP_FILTER
-};
-
static int ixp_ptp_match(struct sk_buff *skb, u16 uid_hi, u32 uid_lo, u16
seqid)
{
u8 *data = skb-data;
@@ -267,7 +263,7 @@ static int ixp_ptp_match(struct sk_buff *skb, u16 uid_hi,
u32 uid_lo, u16 seqid)
u16 *hi, *id;
u32 lo;
- if (sk_run_filter(skb, ptp_filter) != PTP_CLASS_V1_IPV4)
+ if (ptp_classify_raw(skb) != PTP_CLASS_V1_IPV4)
return 0;
offset = ETH_HLEN + IPV4_HLEN(data) + UDP_HLEN;
@@ -1413,11 +1409,6 @@ static int eth_init_one(struct
Re: [linux-yocto] [PATCH 1/2] net: ptp: use sk_unattached_filter_create() for BPF
I accidentally included the original CC'd people, please do not reply to
this with them on Cc. Use this message to reply-all. Apologies. Git
sendmail screw up.
On 9/26/14, 10:07, Darren Hart dvh...@linux.intel.com wrote:
From: Daniel Borkmann dbork...@redhat.com
This patch migrates an open-coded sk_run_filter() implementation with
proper use of the BPF API, that is, sk_unattached_filter_create(). This
migration is needed, as we will be internally transforming the filter
to a different representation, and therefore needs to be decoupled.
It is okay to do so as skb_timestamping_init() is called during
initialization of the network stack in core initcall via sock_init().
This would effectively also allow for PTP filters to be jit compiled if
bpf_jit_enable is set.
For better readability, there are also some newlines introduced, also
ptp_classify.h is only in kernel space.
Joint work with Alexei Starovoitov.
Signed-off-by: Daniel Borkmann dbork...@redhat.com
Signed-off-by: Alexei Starovoitov a...@plumgrid.com
Cc: Richard Cochran richard.coch...@omicron.at
Cc: Jiri Benc jb...@redhat.com
Signed-off-by: David S. Miller da...@davemloft.net
(cherry picked from commit e62d2df084e2849edffb206559725fa81bb569a8)
---
include/linux/ptp_classify.h | 4
net/core/timestamping.c | 21 ++---
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/include/linux/ptp_classify.h b/include/linux/ptp_classify.h
index 1dc420b..3decfa4 100644
--- a/include/linux/ptp_classify.h
+++ b/include/linux/ptp_classify.h
@@ -27,11 +27,7 @@
#include linux/if_vlan.h
#include linux/ip.h
#include linux/filter.h
-#ifdef __KERNEL__
#include linux/in.h
-#else
-#include netinet/in.h
-#endif
#define PTP_CLASS_NONE 0x00 /* not a PTP event message */
#define PTP_CLASS_V10x01 /* protocol version 1 */
diff --git a/net/core/timestamping.c b/net/core/timestamping.c
index 661b5a4..e43d56a 100644
--- a/net/core/timestamping.c
+++ b/net/core/timestamping.c
@@ -23,16 +23,13 @@
#include linux/skbuff.h
#include linux/export.h
-static struct sock_filter ptp_filter[] = {
- PTP_FILTER
-};
+static struct sk_filter *ptp_insns __read_mostly;
static unsigned int classify(const struct sk_buff *skb)
{
- if (likely(skb-dev
- skb-dev-phydev
+ if (likely(skb-dev skb-dev-phydev
skb-dev-phydev-drv))
- return sk_run_filter(skb, ptp_filter);
+ return SK_RUN_FILTER(ptp_insns, skb);
else
return PTP_CLASS_NONE;
}
@@ -60,11 +57,13 @@ void skb_clone_tx_timestamp(struct sk_buff *skb)
if (likely(phydev-drv-txtstamp)) {
if (!atomic_inc_not_zero(sk-sk_refcnt))
return;
+
clone = skb_clone(skb, GFP_ATOMIC);
if (!clone) {
sock_put(sk);
return;
}
+
clone-sk = sk;
phydev-drv-txtstamp(phydev, clone, type);
}
@@ -89,12 +88,15 @@ void skb_complete_tx_timestamp(struct sk_buff *skb,
}
*skb_hwtstamps(skb) = *hwtstamps;
+
serr = SKB_EXT_ERR(skb);
memset(serr, 0, sizeof(*serr));
serr-ee.ee_errno = ENOMSG;
serr-ee.ee_origin = SO_EE_ORIGIN_TIMESTAMPING;
skb-sk = NULL;
+
err = sock_queue_err_skb(sk, skb);
+
sock_put(sk);
if (err)
kfree_skb(skb);
@@ -135,5 +137,10 @@ EXPORT_SYMBOL_GPL(skb_defer_rx_timestamp);
void __init skb_timestamping_init(void)
{
- BUG_ON(sk_chk_filter(ptp_filter, ARRAY_SIZE(ptp_filter)));
+ static struct sock_filter ptp_filter[] = { PTP_FILTER };
+ struct sock_fprog ptp_prog = {
+ .len = ARRAY_SIZE(ptp_filter), .filter = ptp_filter,
+ };
+
+ BUG_ON(sk_unattached_filter_create(ptp_insns, ptp_prog));
}
--
2.1.0
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
--
Darren Hart Open Source Technology Center
darren.h...@intel.com Intel Corporation
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/2] Fix BPF merge build breakage
On 9/26/14, 10:07, Darren Hart dvh...@linux.intel.com wrote: The merge of the net BPF stuff appears to have broken the pch_gbe driver. Backporting these two additional patches from mainline gets the driver building again. Hold off, this gets the driver to build, but link is failing. Sorry, jumped the gun I guess. Still working this out. -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] Please revert this entire series: Re: [PATCH 1/1] Revert net: Rename skb-rxhash to skb-hash
This patch series has broken the kernel build. Multiple drivers and core feature no longer even compile. In the future, do not submit patches for inclusion that have not passed a basic allyesconfig/allmodconfig test, if you are changing core features that impact multiple architectures, then you must test them on other architectures, particularly x86 as it's trivial to perform the test. This is not a trivial error, this is a HUGE ISSUE. This breaks standard and preempt-rt kernels for all Intel-common platforms and all tunnel creek platforms. There is additional breakage in the 3.14 kernel which may or may not be related to this. Bruce, please revert this entire series and ask that the backport be performed properly. He Zhe, please build with an allyesconfig and an allmodconfig build. Find where it breaks, use git log to find the changes in the impacted files up to the latest patch you backported, and pull in the necessary changes. For example, at least the following two are required even to get pch_gbe to compile (and it still doesn't link): 164d8c6 net: ptp: do not reimplement PTP/BPF classifier e62d2df net: ptp: use sk_unattached_filter_create() for BPF I've seen build failures in isdn_ppp, pch_gbe, ti/cpts.c, ixp4xx_eth.c, crypto, aufs fs, etc. Again, this is completely unacceptable. Submitting patches for inclusion in a Linux kernel tree requires that the resulting tree compiles for all drivers and all architectures. This goes triple for standard/base and standard/preempt-rt/base which every BSP depends on. -- Darren Hart On 9/10/14, 18:41, He Zhe zhe...@windriver.com wrote: On 09/10/2014 10:06 PM, Bruce Ashfield wrote: On 14-09-10 03:17 AM, He Zhe wrote: On 09/10/2014 02:41 PM, Bruce Ashfield wrote: On 14-09-09 10:56 PM, zhe...@windriver.com wrote: From: He Zhe zhe...@windriver.com Revert unnecessary renaming for BPF. Build will fail if related drivers are enabled but do not get updated accordingly. Did you actually perform a git revert on this commit on linux-yocto-3.14 standard/base branch ? This didn't revert cleanly for me. So please double check, and make sure you've cloned the latest tree from the git servers. I can apply the patch successfully as follow. Could you please send me your process? 1) Clone and pull on this repo git://git.yoctoproject.org/linux-yocto-3.14 2) Switch to standard/base 3) Apply the patch git am ~/0001-Revert-net-Rename-skb-rxhash-to-skb-hash.patch Applying: Revert net: Rename skb-rxhash to skb-hash Right here. If a patch is a pure revert of the original, you do not apply a patch .. you revert it. Find the git commit and issue git revert hash, if it fails, there are other stacked patches that have changed context to adapt to the first one. In that case, we are not doing a clean revert, and your patch is also implicitly fixing up those other patches. So we can't call it a revert in the commit header, and you need to document/explain those other fixes as well. Yes, some details were omitted. I'll send V2 and explain them.Thanks. Zhe Bruce 4) git log --pretty=oneline -40 | grep -v ^: c33f98897774024687745f6d0f4a651e98031b13 Revert net: Rename skb-rxhash to skb-hash the revert b85edae6fd61ceadfc08099608e8ac90aa4c5c33 net: e1000e calls skb_set_hash last one of BPF set b45e6dec1972bc70ceba882da17a043b7a9b58bc net: ppp: use sk_unattached_filter api d310945fb6d8729cfd538bfcf28d348a863ff486 tracing: accelerate tracing filters with BPF 6742a0d5e218809106b107a58378811201445fd8 net: filter: x86: internal BPF JIT 66f2b151dd096f2e531ffa6985115b5ad850e3f5 net: filter: x86: split bpf_jit_compile() 3c82c5d1fc493f1240e689020790777351b8f9f3 net: filter: Fix redefinition warnings on x86-64. 5ad74ef546a4b453277d66bb40d0605f6a95be2b net: filter: additional BPF tests f097814fc3051b37918ac496dd16fc70215d836e net: filter: BPF testsuite 1bcefe39e229c4cd4ef81e62ee8c7016077ce709 net: filter: make BPF conversion more readable e75a3abd0c6f56c0e368e66dd1a9040edb3bed3b net: filter: misc/various cleanups f5cd96317979c402ba9e10ead36f6baef66bfd29 net: filter: make register naming more comprehensible 2f485870e68b5dacfb49cd36b92e8110f7eb2274 net: filter: simplify label names from jump-table d381512d96f085353e96dec245d6045c8b7cd27e bpf_dbg: fix wrong register usage d99d91c2c5a95a6764b30be63aa5b9cfc3936c85 sched, cls: check if we could overwrite actions when changing a filter 8a03c23319dc747b76924f43be37e7554dfffea2 net: filter: initialize A and X registers 77a8a3fb86cb81d92892f09fa7e9075a9165d7fb filter: added BPF random opcode a9bb9bcd5a0485ec4b95b0212b3b442e2298b581 net: filter: seccomp: fix wrong decoding of BPF_S_ANC_SECCOMP_LD_W 724096236a6836581ea4d46a9a3631ad8bf3b20c filter: prevent nla extensions to peek beyond the end of the message 41bdf9a8c75f62d49138df4aaff09553b8675a29 net: filter: be more defensive on div/mod by X==0 2f908136e31125fd28004c95c7921e693d3e3673 net
[linux-yocto] [PATCH] intel: Remove the standard ktype nesting
Fixes [YOCTO 6710] intel-common-standard.scc included the standard ktype, but the preempt-rt scc files included intel-common-standard and the preempt-rt ktype. This resulted in a double include of the standard ktype, which caused the meta/scripts/updateme to change the source tree from standard/preempt-rt/base to standard/standard/preempt-rt and drop all the preempt-rt commits. To address this, avoid the nested inclusion of ktypes by explicitly including them in each top level BSP definition. Remove the ktype from intel-common-standard.scc and rename it intel-common-drivers.scc, which more accurately describes its purpose anyway. Update the top the BSPs to use the new name and explicitly include the required ktype. Remove some obsolete comments and clean-up the whitespace in the top-level BSP scc files a bit. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Bruce Ashfield bruce.ashfi...@windriver.com -- Please apply to linux-yocto-3.14 and to 3.17 after reverting: intel: create intel-common-preempt-rt and use it --- .../bsp/intel-common/intel-common-drivers.scc | 72 + .../bsp/intel-common/intel-common-standard.scc | 74 -- .../bsp/intel-common/intel-core2-32-preempt-rt.scc | 5 +- .../bsp/intel-common/intel-core2-32-standard.scc | 3 +- .../intel-common/intel-corei7-64-preempt-rt.scc| 5 +- .../bsp/intel-common/intel-corei7-64-standard.scc | 3 +- 6 files changed, 78 insertions(+), 84 deletions(-) create mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-common-drivers.scc delete mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-drivers.scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-drivers.scc new file mode 100644 index 000..5dc19fc --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-drivers.scc @@ -0,0 +1,72 @@ +# intel-common-drivers.scc +# +# Common drivers and technologies to enable intel-common derived BSPs. +# + +include intel-common.scc + +# Borrow the driver selection from common-pc until +# it is better abstracted on its own. +kconf hardware bsp/common-pc/common-pc-drivers.cfg +kconf hardware bsp/common-pc/common-pc-eth.cfg +kconf hardware bsp/common-pc/common-pc-gfx.cfg +kconf hardware bsp/common-pc/common-pc-wifi.cfg + +# USB +include features/usb/ehci-hcd.scc +include features/usb/uhci-hcd.scc +include features/usb/ohci-hcd.scc +include features/usb/xhci-hcd.scc +include features/usb/usb-gadgets.scc +include features/usb/touchscreen-composite.scc + +include cfg/timer/hpet.scc +include cfg/timer/rtc.scc +include features/eg20t/eg20t.scc + +# Graphics +include cfg/vesafb.scc +include features/i915/i915.scc + +# Networking +include features/intel-e1/intel-e100.scc +include features/intel-e1/intel-e1.scc +include features/ericsson-3g/f5521gw.scc +include features/igb/igb.scc +include features/ixgbe/ixgbe.scc +include features/iwlwifi/iwlwifi.scc +include features/iwlegacy/iwlegacy.scc + +# Various RF/Wireless technologies +include features/bluetooth/bluetooth.scc +include features/ieee802154/ieee802154.scc + +# Various media device support, like webcams and capture cards +include features/media/media-all.scc + +# Industrial IO Support +include features/iio/iio.scc + +# Intel HD Audio +include features/sound/snd_hda_intel.scc + +# Intel technology +include features/amt/mei/mei.scc +include features/power/intel.scc + +# Subsystems and interfaces +include features/hugetlb/hugetlb.scc +include features/i2c/i2cdev.scc +include features/leds/leds.scc +include features/spi/spidev.scc + +# Miscellaneous +include cfg/dmaengine.scc +include features/uio/uio.scc +include cfg/efi-ext.scc + +# default policy for standard kernels +include cfg/usb-mass-storage.scc +include cfg/boot-live.scc +include features/latencytop/latencytop.scc +include features/profiling/profiling.scc diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc deleted file mode 100644 index 2b4930c..000 --- a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc +++ /dev/null @@ -1,74 +0,0 @@ -# intel-common-standard.scc -# -# Common drivers and technologies to enable for the standard ktype for -# intel-common derived BSPs. -# - -include ktypes/standard/standard.scc -include intel-common.scc - -# Borrow the driver selection from common-pc until -# it is better abstracted on its own. -kconf hardware bsp/common-pc/common-pc-drivers.cfg -kconf hardware bsp/common-pc/common-pc-eth.cfg -kconf hardware bsp/common-pc/common-pc-gfx.cfg -kconf hardware bsp/common-pc/common-pc-wifi.cfg - -# USB -include features/usb/ehci-hcd.scc -include features/usb/uhci-hcd.scc -include features/usb/ohci-hcd.scc -include features/usb/xhci-hcd.scc -include features/usb/usb-gadgets.scc -include features/usb/touchscreen-composite.scc - -include
Re: [linux-yocto] Please revert this entire series: Re: [PATCH 1/1] Revert net: Rename skb-rxhash to skb-hash
On 9/26/14, 12:34, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 14-09-26 02:42 PM, Darren Hart wrote: This patch series has broken the kernel build. Multiple drivers and core feature no longer even compile. In the future, do not submit patches for inclusion that have not passed a basic allyesconfig/allmodconfig test, if you are changing core features that impact multiple architectures, then you must test them on other architectures, particularly x86 as it's trivial to perform the test. This is not a trivial error, this is a HUGE ISSUE. This breaks standard and preempt-rt kernels for all Intel-common platforms and all tunnel creek platforms. There is additional breakage in the 3.14 kernel which may or may not be related to this. Bruce, please revert this entire series and ask that the backport be performed properly. He Zhe, please build with an allyesconfig and an allmodconfig build. Find where it breaks, use git log to find the changes in the impacted files up to the latest patch you backported, and pull in the necessary changes. So everyone knows, I'm doing the following reverts: If you want to push standard/base and standard/preempt-rt/base to the linux-yocto-contrib repo I'll download perform some sanity tests as well. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] Please revert this entire series: Re: [PATCH 1/1] Revert net: Rename skb-rxhash to skb-hash
(Resend due to an MUA failure which caused this to be dropped from the list) On 9/26/14, 12:56, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 14-09-26 03:43 PM, Darren Hart wrote: On 9/26/14, 12:34, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 14-09-26 02:42 PM, Darren Hart wrote: This patch series has broken the kernel build. Multiple drivers and core feature no longer even compile. In the future, do not submit patches for inclusion that have not passed a basic allyesconfig/allmodconfig test, if you are changing core features that impact multiple architectures, then you must test them on other architectures, particularly x86 as it's trivial to perform the test. This is not a trivial error, this is a HUGE ISSUE. This breaks standard and preempt-rt kernels for all Intel-common platforms and all tunnel creek platforms. There is additional breakage in the 3.14 kernel which may or may not be related to this. Bruce, please revert this entire series and ask that the backport be performed properly. He Zhe, please build with an allyesconfig and an allmodconfig build. Find where it breaks, use git log to find the changes in the impacted files up to the latest patch you backported, and pull in the necessary changes. So everyone knows, I'm doing the following reverts: If you want to push standard/base and standard/preempt-rt/base to the linux-yocto-contrib repo I'll download perform some sanity tests as well. * [new branch]standard/base - zedd/bpf-gone/standard/base * [new branch]standard/preempt-rt/base - zedd/bpf-gone/standard/preempt-rt/base My qemux86-64 build just passed. Thanks, $ make allyesconfig make drivers/net Now passes, which should allow for the meta-intel BSPs to build. Unfortunately, there are still several breakages remaining: scsi vdso hfs aufs crypto I believe you mentioned having a fix pending for crypto? Same for standard/base and standard/preempt-rt/base We will need to get these breakages fixed so we can all validate our changes to the kernel using allyesconfig and allmodconfig, as we can't depend on it if there is existing breakage. Obviously :-) Thanks for working through the firedrill today. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] [meta-intel] Why won't my app use multiple threads under 'valleyisland'?
On Thu, Jul 24, 2014 at 09:45:41PM +0100, Chris Tapp wrote:
I've got a recipe for an application. This has:
1) A main thread;
2) An OpenGL ('X' / EGL) graphics rendering thread created using posix
threads;
3) As many threads as required from the graphics thread for GStreamer to
service various pipelines.
On a Cedartrail platform this happily uses multiple cores.
Major difference here is graphics chip, cedartrail uses EMGD binary drivers,
baytrail (valleyisland) uses the open source Intel i965 drivers.
I recently (yesterday) updated meta-intel master and daisy to properly support
video acceleration in gstreamer 1.0 - I don't know if this impacts you or not.
However, if I use the same recipe under a 64-bit valleyisland build (daisy) it
only ever uses a single core (and virtually grinds to a halt).
'top' shows CPU usage for the application never goes above 25% (J1900, so four
cores available). Running four instances of 'yes' gets the total CPU usage to
100%, so all the cores are available.
Does /proc/cpu list four cores?
'taskset' shows that the affinity mask for the application is not restricting
the set of available cores.
Umm... Any ideas what's going on here?
It looks as if GStreamer and OpenGL are fighting for access to something, but
the pipelines only render to 'fakesink' and 'appsink'.
I don't have any GL/GST development experience, so this is likely best taken to
those respective lists.
--
Darren
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] [PATCH 0/2][3.14][dev] meta: Industrial IO Support
Add a new config fragment enabling Industrial IO (IIO) and all the non-staging drivers. Add this to the intel-common-standard. Please apply to 3.14 and -dev. -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 1/2] meta: Add IIO feature
Add a new IIO feature / config fragment which enables all the non-staging IIO drivers as modules. I didn't bother separating these out by class as there weren't too many of them and it's far more likely people would select one of each class (accelerometer, adc, etc.) rather than all of one class in a customized image. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/features/iio/iio.cfg | 160 + meta/cfg/kernel-cache/features/iio/iio.scc | 4 + 2 files changed, 164 insertions(+) create mode 100644 meta/cfg/kernel-cache/features/iio/iio.cfg create mode 100644 meta/cfg/kernel-cache/features/iio/iio.scc diff --git a/meta/cfg/kernel-cache/features/iio/iio.cfg b/meta/cfg/kernel-cache/features/iio/iio.cfg new file mode 100644 index 000..0084179 --- /dev/null +++ b/meta/cfg/kernel-cache/features/iio/iio.cfg @@ -0,0 +1,160 @@ +# HID Sensor Hub required by many IIO devices +CONFIG_HID_SENSOR_HUB=m + +CONFIG_IIO=m +CONFIG_IIO_BUFFER=y +CONFIG_IIO_BUFFER_CB=y +CONFIG_IIO_KFIFO_BUF=m +CONFIG_IIO_TRIGGERED_BUFFER=m +CONFIG_IIO_TRIGGER=y +CONFIG_IIO_CONSUMERS_PER_TRIGGER=2 + +# +# Accelerometers +# +CONFIG_BMA180=m +CONFIG_HID_SENSOR_ACCEL_3D=m +CONFIG_IIO_ST_ACCEL_3AXIS=m +CONFIG_IIO_ST_ACCEL_I2C_3AXIS=m +CONFIG_IIO_ST_ACCEL_SPI_3AXIS=m +CONFIG_KXSD9=m + +# +# Analog to digital converters +# +CONFIG_AD_SIGMA_DELTA=m +CONFIG_AD7266=m +CONFIG_AD7298=m +CONFIG_AD7476=m +CONFIG_AD7791=m +CONFIG_AD7793=m +CONFIG_AD7887=m +CONFIG_AD7923=m +CONFIG_MAX1363=m +CONFIG_MCP320X=m +CONFIG_MCP3422=m +CONFIG_NAU7802=m +CONFIG_TI_ADC081C=m + +# +# Amplifiers +# +CONFIG_AD8366=m + +# +# Hid Sensor IIO Common +# +CONFIG_HID_SENSOR_IIO_COMMON=m +CONFIG_HID_SENSOR_IIO_TRIGGER=m +CONFIG_IIO_ST_SENSORS_I2C=m +CONFIG_IIO_ST_SENSORS_SPI=m +CONFIG_IIO_ST_SENSORS_CORE=m + +# +# Digital to analog converters +# +CONFIG_AD5064=m +CONFIG_AD5360=m +CONFIG_AD5380=m +CONFIG_AD5421=m +CONFIG_AD5446=m +CONFIG_AD5449=m +CONFIG_AD5504=m +CONFIG_AD5624R_SPI=m +CONFIG_AD5686=m +CONFIG_AD5755=m +CONFIG_AD5764=m +CONFIG_AD5791=m +CONFIG_AD7303=m +CONFIG_MAX517=m +CONFIG_MCP4725=m + +# +# Frequency Synthesizers DDS/PLL +# + +# +# Clock Generator/Distribution +# +CONFIG_AD9523=m + +# +# Phase-Locked Loop (PLL) frequency synthesizers +# +CONFIG_ADF4350=m + +# +# Digital gyroscope sensors +# +CONFIG_ADIS16080=m +CONFIG_ADIS16130=m +CONFIG_ADIS16136=m +CONFIG_ADIS16260=m +CONFIG_ADXRS450=m +CONFIG_HID_SENSOR_GYRO_3D=m +CONFIG_IIO_ST_GYRO_3AXIS=m +CONFIG_IIO_ST_GYRO_I2C_3AXIS=m +CONFIG_IIO_ST_GYRO_SPI_3AXIS=m +CONFIG_ITG3200=m + +# +# Humidity sensors +# +CONFIG_DHT11=m + +# +# Inertial measurement units +# +CONFIG_ADIS16400=m +CONFIG_ADIS16480=m +CONFIG_IIO_ADIS_LIB=m +CONFIG_IIO_ADIS_LIB_BUFFER=y +CONFIG_INV_MPU6050_IIO=m + +# +# Light sensors +# +CONFIG_ADJD_S311=m +CONFIG_APDS9300=m +CONFIG_CM32181=m +CONFIG_CM36651=m +CONFIG_GP2AP020A00F=m +CONFIG_HID_SENSOR_ALS=m +CONFIG_TCS3472=m +CONFIG_SENSORS_TSL2563=m +CONFIG_TSL4531=m +CONFIG_VCNL4000=m + +# +# Magnetometer sensors +# +CONFIG_AK8975=m +CONFIG_MAG3110=m +CONFIG_HID_SENSOR_MAGNETOMETER_3D=m +CONFIG_IIO_ST_MAGN_3AXIS=m +CONFIG_IIO_ST_MAGN_I2C_3AXIS=m +CONFIG_IIO_ST_MAGN_SPI_3AXIS=m + +# +# Inclinometer sensors +# +CONFIG_HID_SENSOR_INCLINOMETER_3D=m + +# +# Triggers - standalone +# +CONFIG_IIO_INTERRUPT_TRIGGER=m +CONFIG_IIO_SYSFS_TRIGGER=m + +# +# Pressure sensors +# +CONFIG_MPL3115=m +CONFIG_IIO_ST_PRESS=m +CONFIG_IIO_ST_PRESS_I2C=m +CONFIG_IIO_ST_PRESS_SPI=m + +# +# Temperature sensors +# +CONFIG_TMP006=m diff --git a/meta/cfg/kernel-cache/features/iio/iio.scc b/meta/cfg/kernel-cache/features/iio/iio.scc new file mode 100644 index 000..2e2aaf0 --- /dev/null +++ b/meta/cfg/kernel-cache/features/iio/iio.scc @@ -0,0 +1,4 @@ +define KFEATURE_DESCRIPTION Enable support for Industrail IO +define KFEATURE_COMPATIBILITY all + +kconf hardware iio.cfg -- 2.0.0 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 2/2] meta: intel-common: Enable Industrial IO
Include the IIO fragment in all intel-common standard kernel configurations. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc index 08b08f8..06839ac 100644 --- a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc @@ -41,6 +41,9 @@ include features/iwlegacy/iwlegacy.scc # Various media device support, like webcams and capture cards include features/media/media-all.scc +# Industrial IO Support +include features/iio/iio.scc + # Intel HD Audio include features/sound/snd_hda_intel.scc -- 2.0.0 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/2] meta: Add IIO feature
Ah thanks John. I'll resend since I believe Bruce is MIA for a couple hours right about now. On 7/22/14, 14:31, Mehaffey, John john_mehaf...@mentor.com wrote: Hi Darren, Nice! There's a typo in line 1 of iio.scc: define KFEATURE_DESCRIPTION Enable support for Industrail IO should be Industrial, I believe. -mehaf -Original Message- From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto-boun...@yoctoproject.org] On Behalf Of Darren Hart Sent: Tuesday, July 22, 2014 2:03 PM To: Linux Yocto Cc: Darren Hart Subject: [linux-yocto] [PATCH 1/2] meta: Add IIO feature Add a new IIO feature / config fragment which enables all the non-staging IIO drivers as modules. I didn't bother separating these out by class as there weren't too many of them and it's far more likely people would select one of each class (accelerometer, adc, etc.) rather than all of one class in a customized image. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/features/iio/iio.cfg | 160 + meta/cfg/kernel-cache/features/iio/iio.scc | 4 + 2 files changed, 164 insertions(+) create mode 100644 meta/cfg/kernel-cache/features/iio/iio.cfg create mode 100644 meta/cfg/kernel-cache/features/iio/iio.scc diff --git a/meta/cfg/kernel-cache/features/iio/iio.cfg b/meta/cfg/kernel-cache/features/iio/iio.cfg new file mode 100644 index 000..0084179 --- /dev/null +++ b/meta/cfg/kernel-cache/features/iio/iio.cfg @@ -0,0 +1,160 @@ +# HID Sensor Hub required by many IIO devices CONFIG_HID_SENSOR_HUB=m + +CONFIG_IIO=m +CONFIG_IIO_BUFFER=y +CONFIG_IIO_BUFFER_CB=y +CONFIG_IIO_KFIFO_BUF=m +CONFIG_IIO_TRIGGERED_BUFFER=m +CONFIG_IIO_TRIGGER=y +CONFIG_IIO_CONSUMERS_PER_TRIGGER=2 + +# +# Accelerometers +# +CONFIG_BMA180=m +CONFIG_HID_SENSOR_ACCEL_3D=m +CONFIG_IIO_ST_ACCEL_3AXIS=m +CONFIG_IIO_ST_ACCEL_I2C_3AXIS=m +CONFIG_IIO_ST_ACCEL_SPI_3AXIS=m +CONFIG_KXSD9=m + +# +# Analog to digital converters +# +CONFIG_AD_SIGMA_DELTA=m +CONFIG_AD7266=m +CONFIG_AD7298=m +CONFIG_AD7476=m +CONFIG_AD7791=m +CONFIG_AD7793=m +CONFIG_AD7887=m +CONFIG_AD7923=m +CONFIG_MAX1363=m +CONFIG_MCP320X=m +CONFIG_MCP3422=m +CONFIG_NAU7802=m +CONFIG_TI_ADC081C=m + +# +# Amplifiers +# +CONFIG_AD8366=m + +# +# Hid Sensor IIO Common +# +CONFIG_HID_SENSOR_IIO_COMMON=m +CONFIG_HID_SENSOR_IIO_TRIGGER=m +CONFIG_IIO_ST_SENSORS_I2C=m +CONFIG_IIO_ST_SENSORS_SPI=m +CONFIG_IIO_ST_SENSORS_CORE=m + +# +# Digital to analog converters +# +CONFIG_AD5064=m +CONFIG_AD5360=m +CONFIG_AD5380=m +CONFIG_AD5421=m +CONFIG_AD5446=m +CONFIG_AD5449=m +CONFIG_AD5504=m +CONFIG_AD5624R_SPI=m +CONFIG_AD5686=m +CONFIG_AD5755=m +CONFIG_AD5764=m +CONFIG_AD5791=m +CONFIG_AD7303=m +CONFIG_MAX517=m +CONFIG_MCP4725=m + +# +# Frequency Synthesizers DDS/PLL +# + +# +# Clock Generator/Distribution +# +CONFIG_AD9523=m + +# +# Phase-Locked Loop (PLL) frequency synthesizers # CONFIG_ADF4350=m + +# +# Digital gyroscope sensors +# +CONFIG_ADIS16080=m +CONFIG_ADIS16130=m +CONFIG_ADIS16136=m +CONFIG_ADIS16260=m +CONFIG_ADXRS450=m +CONFIG_HID_SENSOR_GYRO_3D=m +CONFIG_IIO_ST_GYRO_3AXIS=m +CONFIG_IIO_ST_GYRO_I2C_3AXIS=m +CONFIG_IIO_ST_GYRO_SPI_3AXIS=m +CONFIG_ITG3200=m + +# +# Humidity sensors +# +CONFIG_DHT11=m + +# +# Inertial measurement units +# +CONFIG_ADIS16400=m +CONFIG_ADIS16480=m +CONFIG_IIO_ADIS_LIB=m +CONFIG_IIO_ADIS_LIB_BUFFER=y +CONFIG_INV_MPU6050_IIO=m + +# +# Light sensors +# +CONFIG_ADJD_S311=m +CONFIG_APDS9300=m +CONFIG_CM32181=m +CONFIG_CM36651=m +CONFIG_GP2AP020A00F=m +CONFIG_HID_SENSOR_ALS=m +CONFIG_TCS3472=m +CONFIG_SENSORS_TSL2563=m +CONFIG_TSL4531=m +CONFIG_VCNL4000=m + +# +# Magnetometer sensors +# +CONFIG_AK8975=m +CONFIG_MAG3110=m +CONFIG_HID_SENSOR_MAGNETOMETER_3D=m +CONFIG_IIO_ST_MAGN_3AXIS=m +CONFIG_IIO_ST_MAGN_I2C_3AXIS=m +CONFIG_IIO_ST_MAGN_SPI_3AXIS=m + +# +# Inclinometer sensors +# +CONFIG_HID_SENSOR_INCLINOMETER_3D=m + +# +# Triggers - standalone +# +CONFIG_IIO_INTERRUPT_TRIGGER=m +CONFIG_IIO_SYSFS_TRIGGER=m + +# +# Pressure sensors +# +CONFIG_MPL3115=m +CONFIG_IIO_ST_PRESS=m +CONFIG_IIO_ST_PRESS_I2C=m +CONFIG_IIO_ST_PRESS_SPI=m + +# +# Temperature sensors +# +CONFIG_TMP006=m diff --git a/meta/cfg/kernel-cache/features/iio/iio.scc b/meta/cfg/kernel-cache/features/iio/iio.scc new file mode 100644 index 000..2e2aaf0 --- /dev/null +++ b/meta/cfg/kernel-cache/features/iio/iio.scc @@ -0,0 +1,4 @@ +define KFEATURE_DESCRIPTION Enable support for Industrail IO +define KFEATURE_COMPATIBILITY all + +kconf hardware iio.cfg -- 2.0.0 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH v2 0/2][3.14][dev] meta: Industrial IO Support
Add a new config fragment enabling Industrial IO (IIO) and all the non-staging drivers. Add this to the intel-common-standard. Please apply to 3.14 and -dev. v2: Correct typo in iio.scc -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 2/2] meta: intel-common: Enable Industrial IO
Include the IIO fragment in all intel-common standard kernel configurations. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc index 08b08f8..06839ac 100644 --- a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc @@ -41,6 +41,9 @@ include features/iwlegacy/iwlegacy.scc # Various media device support, like webcams and capture cards include features/media/media-all.scc +# Industrial IO Support +include features/iio/iio.scc + # Intel HD Audio include features/sound/snd_hda_intel.scc -- 2.0.0 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 1/2] meta: Add IIO feature
Add a new IIO feature / config fragment which enables all the non-staging IIO drivers as modules. I didn't bother separating these out by class as there weren't too many of them and it's far more likely people would select one of each class (accelerometer, adc, etc.) rather than all of one class in a customized image. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/features/iio/iio.cfg | 160 + meta/cfg/kernel-cache/features/iio/iio.scc | 4 + 2 files changed, 164 insertions(+) create mode 100644 meta/cfg/kernel-cache/features/iio/iio.cfg create mode 100644 meta/cfg/kernel-cache/features/iio/iio.scc diff --git a/meta/cfg/kernel-cache/features/iio/iio.cfg b/meta/cfg/kernel-cache/features/iio/iio.cfg new file mode 100644 index 000..0084179 --- /dev/null +++ b/meta/cfg/kernel-cache/features/iio/iio.cfg @@ -0,0 +1,160 @@ +# HID Sensor Hub required by many IIO devices +CONFIG_HID_SENSOR_HUB=m + +CONFIG_IIO=m +CONFIG_IIO_BUFFER=y +CONFIG_IIO_BUFFER_CB=y +CONFIG_IIO_KFIFO_BUF=m +CONFIG_IIO_TRIGGERED_BUFFER=m +CONFIG_IIO_TRIGGER=y +CONFIG_IIO_CONSUMERS_PER_TRIGGER=2 + +# +# Accelerometers +# +CONFIG_BMA180=m +CONFIG_HID_SENSOR_ACCEL_3D=m +CONFIG_IIO_ST_ACCEL_3AXIS=m +CONFIG_IIO_ST_ACCEL_I2C_3AXIS=m +CONFIG_IIO_ST_ACCEL_SPI_3AXIS=m +CONFIG_KXSD9=m + +# +# Analog to digital converters +# +CONFIG_AD_SIGMA_DELTA=m +CONFIG_AD7266=m +CONFIG_AD7298=m +CONFIG_AD7476=m +CONFIG_AD7791=m +CONFIG_AD7793=m +CONFIG_AD7887=m +CONFIG_AD7923=m +CONFIG_MAX1363=m +CONFIG_MCP320X=m +CONFIG_MCP3422=m +CONFIG_NAU7802=m +CONFIG_TI_ADC081C=m + +# +# Amplifiers +# +CONFIG_AD8366=m + +# +# Hid Sensor IIO Common +# +CONFIG_HID_SENSOR_IIO_COMMON=m +CONFIG_HID_SENSOR_IIO_TRIGGER=m +CONFIG_IIO_ST_SENSORS_I2C=m +CONFIG_IIO_ST_SENSORS_SPI=m +CONFIG_IIO_ST_SENSORS_CORE=m + +# +# Digital to analog converters +# +CONFIG_AD5064=m +CONFIG_AD5360=m +CONFIG_AD5380=m +CONFIG_AD5421=m +CONFIG_AD5446=m +CONFIG_AD5449=m +CONFIG_AD5504=m +CONFIG_AD5624R_SPI=m +CONFIG_AD5686=m +CONFIG_AD5755=m +CONFIG_AD5764=m +CONFIG_AD5791=m +CONFIG_AD7303=m +CONFIG_MAX517=m +CONFIG_MCP4725=m + +# +# Frequency Synthesizers DDS/PLL +# + +# +# Clock Generator/Distribution +# +CONFIG_AD9523=m + +# +# Phase-Locked Loop (PLL) frequency synthesizers +# +CONFIG_ADF4350=m + +# +# Digital gyroscope sensors +# +CONFIG_ADIS16080=m +CONFIG_ADIS16130=m +CONFIG_ADIS16136=m +CONFIG_ADIS16260=m +CONFIG_ADXRS450=m +CONFIG_HID_SENSOR_GYRO_3D=m +CONFIG_IIO_ST_GYRO_3AXIS=m +CONFIG_IIO_ST_GYRO_I2C_3AXIS=m +CONFIG_IIO_ST_GYRO_SPI_3AXIS=m +CONFIG_ITG3200=m + +# +# Humidity sensors +# +CONFIG_DHT11=m + +# +# Inertial measurement units +# +CONFIG_ADIS16400=m +CONFIG_ADIS16480=m +CONFIG_IIO_ADIS_LIB=m +CONFIG_IIO_ADIS_LIB_BUFFER=y +CONFIG_INV_MPU6050_IIO=m + +# +# Light sensors +# +CONFIG_ADJD_S311=m +CONFIG_APDS9300=m +CONFIG_CM32181=m +CONFIG_CM36651=m +CONFIG_GP2AP020A00F=m +CONFIG_HID_SENSOR_ALS=m +CONFIG_TCS3472=m +CONFIG_SENSORS_TSL2563=m +CONFIG_TSL4531=m +CONFIG_VCNL4000=m + +# +# Magnetometer sensors +# +CONFIG_AK8975=m +CONFIG_MAG3110=m +CONFIG_HID_SENSOR_MAGNETOMETER_3D=m +CONFIG_IIO_ST_MAGN_3AXIS=m +CONFIG_IIO_ST_MAGN_I2C_3AXIS=m +CONFIG_IIO_ST_MAGN_SPI_3AXIS=m + +# +# Inclinometer sensors +# +CONFIG_HID_SENSOR_INCLINOMETER_3D=m + +# +# Triggers - standalone +# +CONFIG_IIO_INTERRUPT_TRIGGER=m +CONFIG_IIO_SYSFS_TRIGGER=m + +# +# Pressure sensors +# +CONFIG_MPL3115=m +CONFIG_IIO_ST_PRESS=m +CONFIG_IIO_ST_PRESS_I2C=m +CONFIG_IIO_ST_PRESS_SPI=m + +# +# Temperature sensors +# +CONFIG_TMP006=m diff --git a/meta/cfg/kernel-cache/features/iio/iio.scc b/meta/cfg/kernel-cache/features/iio/iio.scc new file mode 100644 index 000..94261c7 --- /dev/null +++ b/meta/cfg/kernel-cache/features/iio/iio.scc @@ -0,0 +1,4 @@ +define KFEATURE_DESCRIPTION Enable support for Industrial IO +define KFEATURE_COMPATIBILITY all + +kconf hardware iio.cfg -- 2.0.0 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 00/21] [PATCH] valleyisland feature branch rebase
On 6/11/14, 23:32, rebecca.swee.fun.ch...@intel.com rebecca.swee.fun.ch...@intel.com wrote: From: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com Hi Bruce and all, This patchset is for rebasing the valleyisland-io-1.0 feature branch. I recently received a notification from Greg that the Baytrail SMBUS back-porting commits were successfully got merged into linux-stable tree on branch linux-3.10.y. I foresee that you might as well merging in the latest 3.10 LTS commits into linux-yocto-3.10. What is the changes I've made in this patchset is, remove two commits related to SMBUS. These two commits had been merge in to the 3.10 LTS. 8567f56 i2c: i801: enable Intel BayTrail SMBUS 1b796c0 i2c: i801: Add Device IDs for Intel Wildcat Point-LP PCH For other patches in this feature branch, some are still staging in queue to merge into 3.10 LTSI. If you have plan to merge in 3.10 LTS commits into linux-yocto-3.10, please help to rebase valleyisland-io-1.0 feature branch to this new branch. After rebasing, valleyisland feature branch should have a new rev. branch name called: valleyisland-io-2.0. Agreed on the approach. Thanks for clearly explaining it. For the series: Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 3/7] meta: Add aufs-disable feature
On 5/19/14, 14:52, Tom Zanussi tom.zanu...@linux.intel.com wrote: Add an aufs-disable feature allowing aufs to be selectively disabled, specifically for preempt-rt since aufs doesn't build with preempt-rt kernels (as opposed to just blanket disabling it in standard since there may already be users who would miss it). Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 7/7] meta: Explicitly add boot-live to intel-core2-32
On 5/19/14, 14:53, Tom Zanussi tom.zanu...@linux.intel.com wrote: intel-core2-32 hangs with 'waiting for removable media' because the preempt-rt cfg overwrites BLK_DEV_LOOP. Presumably there's a good reason for that which should be fixed properly, but this at least lets the system boot. Meh... OK. A PREEMPT_RT config audit is in order, but this gets things unstuck and moving forward. Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/7] meta: Add qat (QuickAssist) feature
On 5/19/14, 14:52, Tom Zanussi tom.zanu...@linux.intel.com wrote: Add config items required to enable QuickAssist Technology. Note that this apparently includes disabling PREEMPT, making it incompatible with -rt. Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 2/7] mohonpeak: Replace QAT in mohonpeak.cfg with qat feature
On 5/19/14, 14:52, Tom Zanussi tom.zanu...@linux.intel.com wrote: Remove the QAT configuration from mohonpeak.cfg, as it breaks -rt for everything else, and instead have the mohonpeak standard BSPs use the new qat feature. Note that as defined, the QAT configuration is incompatible with -rt, so it isn't added back to those. Signed-off-by: Tom Zanussi tom.zanu...@linux.intel.com Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 01/24] genirq: x86: Ensure that dynamic irq allocation does not conflict
From: Thomas Gleixner t...@linutronix.de
On x86 the allocation of irq descriptors may allocate interrupts which
are in the range of the GSI interrupts. That's wrong as those
interrupts are hardwired and we don't have the irq domain translation
like PPC. So one of these interrupts can be hooked up later to one of
the devices which are hard wired to it and the io_apic init code for
that particular interrupt line happily reuses that descriptor with a
completely different configuration so hell breaks lose.
Inside x86 we allocate dynamic interrupts from above nr_gsi_irqs,
except for a few usage sites which have not yet blown up in our face
for whatever reason. But for drivers which need an irq range, like the
GPIO drivers, we have no limit in place and we don't want to expose
such a detail to a driver.
To cure this introduce a function which an architecture can implement
to impose a lower bound on the dynamic interrupt allocations.
Implement it for x86 and set the lower bound to nr_gsi_irqs, which is
the end of the hardwired interrupt space, so all dynamic allocations
happen above.
That not only allows the GPIO driver to work sanely, it also protects
the bogus callsites of create_irq_nr() in hpet, uv, irq_remapping and
htirq code. They need to be cleaned up as well, but that's a separate
issue.
Reported-by: Jin Yao yao@linux.intel.com
Signed-off-by: Thomas Gleixner t...@linutronix.de
Tested-by: Mika Westerberg mika.westerb...@linux.intel.com
Cc: Mathias Nyman mathias.ny...@linux.intel.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: H. Peter Anvin h...@linux.intel.com
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Cc: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Krogerus Heikki heikki.kroge...@intel.com
Cc: Linus Walleij linus.wall...@linaro.org
Link:
http://lkml.kernel.org/r/alpine.deb.2.02.1404241617360.28...@ionos.tec.linutronix.de
Signed-off-by: Thomas Gleixner t...@linutronix.de
(cherry picked from commit 62a08ae2a5763aabeee98264605236b001503e0c)
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
arch/x86/kernel/apic/io_apic.c |5 +
include/linux/irq.h|2 ++
kernel/irq/irqdesc.c |7 +++
kernel/softirq.c |5 +
4 files changed, 19 insertions(+)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 6ad4658..d23aa82 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3425,6 +3425,11 @@ int get_nr_irqs_gsi(void)
return nr_irqs_gsi;
}
+unsigned int arch_dynirq_lower_bound(unsigned int from)
+{
+ return from nr_irqs_gsi ? nr_irqs_gsi : from;
+}
+
int __init arch_probe_nr_irqs(void)
{
int nr;
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 7dc1003..ead802d 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -593,6 +593,8 @@ static inline u32 irq_get_trigger_type(unsigned int irq)
return d ? irqd_get_trigger_type(d) : 0;
}
+unsigned int arch_dynirq_lower_bound(unsigned int from);
+
int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
struct module *owner);
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 8ab8e93..b88dba1 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -363,6 +363,13 @@ __irq_alloc_descs(int irq, unsigned int from, unsigned int
cnt, int node,
if (from irq)
return -EINVAL;
from = irq;
+ } else {
+ /*
+* For interrupts which are freely allocated the
+* architecture can force a lower bound to the @from
+* argument. x86 uses this to exclude the GSI space.
+*/
+ from = arch_dynirq_lower_bound(from);
}
mutex_lock(sparse_irq_lock);
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 490fcbb..3c8b4e7 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -778,3 +778,8 @@ int __init __weak arch_early_irq_init(void)
{
return 0;
}
+
+unsigned int __weak arch_dynirq_lower_bound(unsigned int from)
+{
+ return from;
+}
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 08/24] pinctrl-baytrail: add function mux checking in gpio pin request
From: Chew, Kean Ho kean.ho.c...@intel.com
The requested gpio pin must has the func_pin_mux field set
to GPIO function by BIOS/FW in advanced. Else, the gpio pin
request would fail. This is to ensure that we do not expose
any gpio pins which shall be used for alternate functions,
for eg: wakeup pin, I/O interfaces for LPSS, etc.
Signed-off-by: Chew, Kean Ho kean.ho.c...@intel.com
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Reviewed-by: Darren Hart dvh...@linux.intel.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
(cherry picked from commit 42bd00706ce95d74ad6ebcb8528ee1fbbb992f6a)
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
drivers/pinctrl/pinctrl-baytrail.c | 42 +---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-baytrail.c
b/drivers/pinctrl/pinctrl-baytrail.c
index 665b96b..bf2b3f6 100644
--- a/drivers/pinctrl/pinctrl-baytrail.c
+++ b/drivers/pinctrl/pinctrl-baytrail.c
@@ -60,6 +60,10 @@
#define BYT_NGPIO_NCORE28
#define BYT_NGPIO_SUS 44
+#define BYT_SCORE_ACPI_UID 1
+#define BYT_NCORE_ACPI_UID 2
+#define BYT_SUS_ACPI_UID 3
+
/*
* Baytrail gpio controller consist of three separate sub-controllers called
* SCORE, NCORE and SUS. The sub-controllers are identified by their acpi UID.
@@ -102,17 +106,17 @@ static unsigned const sus_pins[BYT_NGPIO_SUS] = {
static struct pinctrl_gpio_range byt_ranges[] = {
{
- .name = 1, /* match with acpi _UID in probe */
+ .name = BYT_SCORE_ACPI_UID, /* match with acpi _UID in probe */
.npins = BYT_NGPIO_SCORE,
.pins = score_pins,
},
{
- .name = 2,
+ .name = BYT_NCORE_ACPI_UID,
.npins = BYT_NGPIO_NCORE,
.pins = ncore_pins,
},
{
- .name = 3,
+ .name = BYT_SUS_ACPI_UID,
.npins = BYT_NGPIO_SUS,
.pins = sus_pins,
},
@@ -145,9 +149,41 @@ static void __iomem *byt_gpio_reg(struct gpio_chip *chip,
unsigned offset,
return vg-reg_base + reg_offset + reg;
}
+static bool is_special_pin(struct byt_gpio *vg, unsigned offset)
+{
+ /* SCORE pin 92-93 */
+ if (!strcmp(vg-range-name, BYT_SCORE_ACPI_UID)
+ offset = 92 offset = 93)
+ return true;
+
+ /* SUS pin 11-21 */
+ if (!strcmp(vg-range-name, BYT_SUS_ACPI_UID)
+ offset = 11 offset = 21)
+ return true;
+
+ return false;
+}
+
static int byt_gpio_request(struct gpio_chip *chip, unsigned offset)
{
struct byt_gpio *vg = to_byt_gpio(chip);
+ void __iomem *reg = byt_gpio_reg(chip, offset, BYT_CONF0_REG);
+ u32 value;
+ bool special;
+
+ /*
+* In most cases, func pin mux 000 means GPIO function.
+* But, some pins may have func pin mux 001 represents
+* GPIO function. Only allow user to export pin with
+* func pin mux preset as GPIO function by BIOS/FW.
+*/
+ value = readl(reg) BYT_PIN_MUX;
+ special = is_special_pin(vg, offset);
+ if ((special value != 1) || (!special value)) {
+ dev_err(vg-pdev-dev,
+ pin %u cannot be used as GPIO.\n, offset);
+ return -EINVAL;
+ }
pm_runtime_get(vg-pdev-dev);
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 07/24] i2c: i801: enable Intel BayTrail SMBUS
From: Chew, Kean ho kean.ho.c...@intel.com
Add Device ID of Intel BayTrail SMBus Controller.
Signed-off-by: Chew, Kean ho kean.ho.c...@intel.com
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Reviewed-by: Jean Delvare jdelv...@suse.de
Signed-off-by: Wolfram Sang w...@the-dreams.de
(cherry picked from commit 1b31e9b76ef8c62291e698dfdb973499986a7f68)
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
Documentation/i2c/busses/i2c-i801 |1 +
drivers/i2c/busses/Kconfig|1 +
drivers/i2c/busses/i2c-i801.c |3 +++
3 files changed, 5 insertions(+)
diff --git a/Documentation/i2c/busses/i2c-i801
b/Documentation/i2c/busses/i2c-i801
index aaaf0693..adf5e33 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -26,6 +26,7 @@ Supported adapters:
* Intel Wellsburg (PCH)
* Intel Coleto Creek (PCH)
* Intel Wildcat Point-LP (PCH)
+ * Intel BayTrail (SOC)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index de17c55..c5eec02 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -110,6 +110,7 @@ config I2C_I801
Wellsburg (PCH)
Coleto Creek (PCH)
Wildcat Point-LP (PCH)
+ BayTrail (SOC)
This driver can also be built as a module. If so, the module
will be called i2c-i801.
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 349c2d3..899f559 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -60,6 +60,7 @@
Wellsburg (PCH) MS0x8d7f 32 hard yes yes yes
Coleto Creek (PCH)0x23b0 32 hard yes yes yes
Wildcat Point-LP (PCH) 0x9ca2 32 hard yes yes yes
+ BayTrail (SOC)0x0f12 32 hard yes yes yes
Features supported by this driver:
Software PEC no
@@ -161,6 +162,7 @@
STATUS_ERROR_FLAGS)
/* Older devices have their ID defined in linux/pci_ids.h */
+#define PCI_DEVICE_ID_INTEL_BAYTRAIL_SMBUS 0x0f12
#define PCI_DEVICE_ID_INTEL_COUGARPOINT_SMBUS 0x1c22
#define PCI_DEVICE_ID_INTEL_PATSBURG_SMBUS 0x1d22
/* Patsburg also has three 'Integrated Device Function' SMBus controllers */
@@ -822,6 +824,7 @@ static DEFINE_PCI_DEVICE_TABLE(i801_ids) = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_WELLSBURG_SMBUS_MS2) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_COLETOCREEK_SMBUS) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_SMBUS) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BAYTRAIL_SMBUS) },
{ 0, }
};
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 03/24] ACPI / LPSS: Add Intel BayTrail ACPI mode PWM
From: Chew, Chiau Ee chiau.ee.c...@intel.com
Intel BayTrail LPSS consists of two PWM controllers which can
be enumerated from ACPI namespace. This change will cause
platform device objects to be created for Intel BayTrail PWM
controllers which will allow the pwm-lpss driver to bind to them
and handle those devices.
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
(cherry picked from commit e1c7481797542f4d2039d5a458ef80603298ad78)
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
drivers/acpi/acpi_lpss.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 6745fe1..8c2bae9 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -102,6 +102,16 @@ static struct lpss_device_desc lpt_sdio_dev_desc = {
.ltr_required = true,
};
+static struct lpss_shared_clock pwm_clock = {
+ .name = pwm_clk,
+ .rate = 2500,
+};
+
+static struct lpss_device_desc byt_pwm_dev_desc = {
+ .clk_required = true,
+ .shared_clock = pwm_clock,
+};
+
static struct lpss_shared_clock uart_clock = {
.name = uart_clk,
.rate = 44236800,
@@ -157,6 +167,7 @@ static const struct acpi_device_id acpi_lpss_device_ids[] =
{
{ INT33C7, },
/* BayTrail LPSS devices */
+ { 80860F09, (unsigned long)byt_pwm_dev_desc },
{ 80860F0A, (unsigned long)byt_uart_dev_desc },
{ 80860F0E, (unsigned long)byt_spi_dev_desc },
{ 80860F14, (unsigned long)byt_sdio_dev_desc },
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 16/24] i2c: designware-pci: set ideal HCNT, LCNT and SDA hold time value
From: Chew, Chiau Ee chiau.ee.c...@intel.com
On Intel BayTrail, there was case whereby the resulting fast mode
bus speed becomes slower (~20% slower compared to expected speed)
if using the HCNT/LCNT calculated in the core layer. Thus, this
patch is added to allow pci glue layer to pass in optimal
HCNT/LCNT/SDA hold time values to core layer since the core
layer supports cofigurable HCNT/LCNT/SDA hold time values now.
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Acked-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Wolfram Sang w...@the-dreams.de
(cherry picked from commit 8efd1e9ee3bd55e20cb36e56ca53096cf2b3a930)
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
drivers/i2c/busses/i2c-designware-pcidrv.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index 87f2fc4..9dec4be 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -58,6 +58,14 @@ enum dw_pci_ctl_id_t {
baytrail,
};
+struct dw_scl_sda_cfg {
+ u32 ss_hcnt;
+ u32 fs_hcnt;
+ u32 ss_lcnt;
+ u32 fs_lcnt;
+ u32 sda_hold;
+};
+
struct dw_pci_controller {
u32 bus_num;
u32 bus_cfg;
@@ -65,6 +73,7 @@ struct dw_pci_controller {
u32 rx_fifo_depth;
u32 clk_khz;
u32 functionality;
+ struct dw_scl_sda_cfg *scl_sda_cfg;
};
#define INTEL_MID_STD_CFG (DW_IC_CON_MASTER | \
@@ -77,6 +86,15 @@ struct dw_pci_controller {
I2C_FUNC_SMBUS_WORD_DATA | \
I2C_FUNC_SMBUS_I2C_BLOCK)
+/* BayTrail HCNT/LCNT/SDA hold time */
+static struct dw_scl_sda_cfg byt_config = {
+ .ss_hcnt = 0x200,
+ .fs_hcnt = 0x55,
+ .ss_lcnt = 0x200,
+ .fs_lcnt = 0x99,
+ .sda_hold = 0x6,
+};
+
static struct dw_pci_controller dw_pci_controllers[] = {
[moorestown_0] = {
.bus_num = 0,
@@ -148,6 +166,7 @@ static struct dw_pci_controller dw_pci_controllers[] = {
.rx_fifo_depth = 32,
.clk_khz = 10,
.functionality = I2C_FUNC_10BIT_ADDR,
+ .scl_sda_cfg = byt_config,
},
};
static struct i2c_algorithm i2c_dw_algo = {
@@ -231,6 +250,7 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
struct i2c_adapter *adap;
int r;
struct dw_pci_controller *controller;
+ struct dw_scl_sda_cfg *cfg;
if (id-driver_data = ARRAY_SIZE(dw_pci_controllers)) {
dev_err(pdev-dev, %s: invalid driver data %ld\n, __func__,
@@ -268,6 +288,14 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
DW_DEFAULT_FUNCTIONALITY;
dev-master_cfg = controller-bus_cfg;
+ if (controller-scl_sda_cfg) {
+ cfg = controller-scl_sda_cfg;
+ dev-ss_hcnt = cfg-ss_hcnt;
+ dev-fs_hcnt = cfg-fs_hcnt;
+ dev-ss_lcnt = cfg-ss_lcnt;
+ dev-fs_lcnt = cfg-fs_lcnt;
+ dev-sda_hold_time = cfg-sda_hold;
+ }
pci_set_drvdata(pdev, dev);
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 23/24] spi/pxa2xx: Add common clock framework support in PCI glue layer
From: Chew, Chiau Ee chiau.ee.c...@intel.com
SPI PXA2XX core layer has dependency on common clock framework
to obtain information on host supported clock rate. Thus, we
setup the clock device in the PCI glue layer to enable PCI mode
host pass in the clock rate information.
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
PENDING: Out for review
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
drivers/spi/spi-pxa2xx-pci.c | 17 +
drivers/spi/spi-pxa2xx.c |5 -
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index c1865c9..71767a1 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -7,6 +7,9 @@
#include linux/of_device.h
#include linux/module.h
#include linux/spi/pxa2xx_spi.h
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
enum {
PORT_CE4100,
@@ -21,6 +24,7 @@ struct pxa_spi_info {
int tx_chan_id;
int rx_slave_id;
int rx_chan_id;
+ unsigned long max_clk_rate;
};
static struct pxa_spi_info spi_info_configs[] = {
@@ -32,6 +36,7 @@ static struct pxa_spi_info spi_info_configs[] = {
.tx_chan_id = -1,
.rx_slave_id = -1,
.rx_chan_id = -1,
+ .max_clk_rate = 3686400,
},
[PORT_BYT] = {
.type = LPSS_SSP,
@@ -41,6 +46,7 @@ static struct pxa_spi_info spi_info_configs[] = {
.tx_chan_id = 0,
.rx_slave_id = 1,
.rx_chan_id = 1,
+ .max_clk_rate = 5000,
},
};
@@ -53,6 +59,8 @@ static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
struct pxa2xx_spi_master spi_pdata;
struct ssp_device *ssp;
struct pxa_spi_info *c;
+ struct clk *clk;
+ char buf[40];
ret = pcim_enable_device(dev);
if (ret)
@@ -84,6 +92,15 @@ static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
ssp-port_id = (c-port_id = 0) ? c-port_id : dev-devfn;
ssp-type = c-type;
+ clk = clk_register_fixed_rate(NULL, spi_pxa2xx_clk, NULL,
+ CLK_IS_ROOT, c-max_clk_rate);
+if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ snprintf(buf, sizeof(buf), pxa2xx-spi.%d, ssp-port_id);
+
+ clk_register_clkdev(clk, NULL, buf);
+
memset(pi, 0, sizeof(pi));
pi.parent = dev-dev;
pi.name = pxa2xx-spi;
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index c702fc5..995038f 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -1055,7 +1055,6 @@ pxa2xx_spi_acpi_get_pdata(struct platform_device *pdev)
if (IS_ERR(ssp-mmio_base))
return NULL;
- ssp-clk = devm_clk_get(pdev-dev, NULL);
ssp-irq = platform_get_irq(pdev, 0);
ssp-type = LPSS_SSP;
ssp-pdev = pdev;
@@ -1181,6 +1180,10 @@ static int pxa2xx_spi_probe(struct platform_device *pdev)
}
/* Enable SOC clock */
+ ssp-clk = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(ssp-clk))
+ return PTR_ERR(ssp-clk);
+
clk_prepare_enable(ssp-clk);
drv_data-max_clk_rate = clk_get_rate(ssp-clk);
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 14/24] mmc: slot-gpio: Add GPIO descriptor based CD GPIO API
From: Adrian Hunter adrian.hun...@intel.com
Add functions to request a CD GPIO using the GPIO descriptor API.
Note that the new request function is paired with mmc_gpiod_free_cd()
not mmc_gpio_free_cd(). Note also that it must be called prior to
mmc_add_host() otherwise the caller must also call
mmc_gpiod_request_cd_irq().
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Reviewed-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Chris Ball ch...@printf.net
(cherry picked from commit 740a221ef0e579dc7c675cf6b90f5313509788f7)
---
drivers/mmc/core/core.c |4 ++
drivers/mmc/core/slot-gpio.c | 81 -
include/linux/mmc/slot-gpio.h |6 +++
3 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 098374b..ff2476e 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -34,6 +34,7 @@
#include linux/mmc/host.h
#include linux/mmc/mmc.h
#include linux/mmc/sd.h
+#include linux/mmc/slot-gpio.h
#include core.h
#include bus.h
@@ -2490,6 +2491,7 @@ void mmc_start_host(struct mmc_host *host)
mmc_power_off(host);
else
mmc_power_up(host, host-ocr_avail);
+ mmc_gpiod_request_cd_irq(host);
_mmc_detect_change(host, 0, false);
}
@@ -2501,6 +2503,8 @@ void mmc_stop_host(struct mmc_host *host)
host-removed = 1;
spin_unlock_irqrestore(host-lock, flags);
#endif
+ if (host-slot.cd_irq = 0)
+ disable_irq(host-slot.cd_irq);
host-rescan_disable = 1;
cancel_delayed_work_sync(host-detect);
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 47fa07e..f7650b8 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -139,7 +139,7 @@ int mmc_gpio_request_ro(struct mmc_host *host, unsigned int
gpio)
}
EXPORT_SYMBOL(mmc_gpio_request_ro);
-static void mmc_gpiod_request_cd_irq(struct mmc_host *host)
+void mmc_gpiod_request_cd_irq(struct mmc_host *host)
{
struct mmc_gpio *ctx = host-slot.handler_priv;
int ret, irq;
@@ -171,6 +171,7 @@ static void mmc_gpiod_request_cd_irq(struct mmc_host *host)
if (irq 0)
host-caps |= MMC_CAP_NEEDS_POLL;
}
+EXPORT_SYMBOL(mmc_gpiod_request_cd_irq);
/**
* mmc_gpio_request_cd - request a gpio for card-detection
@@ -276,3 +277,81 @@ void mmc_gpio_free_cd(struct mmc_host *host)
devm_gpio_free(host-class_dev, gpio);
}
EXPORT_SYMBOL(mmc_gpio_free_cd);
+
+/**
+ * mmc_gpiod_request_cd - request a gpio descriptor for card-detection
+ * @host: mmc host
+ * @con_id: function within the GPIO consumer
+ * @idx: index of the GPIO to obtain in the consumer
+ * @override_active_level: ignore %GPIO_ACTIVE_LOW flag
+ * @debounce: debounce time in microseconds
+ *
+ * Use this function in place of mmc_gpio_request_cd() to use the GPIO
+ * descriptor API. Note that it is paired with mmc_gpiod_free_cd() not
+ * mmc_gpio_free_cd(). Note also that it must be called prior to
mmc_add_host()
+ * otherwise the caller must also call mmc_gpiod_request_cd_irq().
+ *
+ * Returns zero on success, else an error.
+ */
+int mmc_gpiod_request_cd(struct mmc_host *host, const char *con_id,
+unsigned int idx, bool override_active_level,
+unsigned int debounce)
+{
+ struct mmc_gpio *ctx;
+ struct gpio_desc *desc;
+ int ret;
+
+ ret = mmc_gpio_alloc(host);
+ if (ret 0)
+ return ret;
+
+ ctx = host-slot.handler_priv;
+
+ if (!con_id)
+ con_id = ctx-cd_label;
+
+ desc = devm_gpiod_get_index(host-parent, con_id, idx);
+ if (IS_ERR(desc))
+ return PTR_ERR(desc);
+
+ ret = gpiod_direction_input(desc);
+ if (ret 0)
+ return ret;
+
+ if (debounce) {
+ ret = gpiod_set_debounce(desc, debounce);
+ if (ret 0)
+ return ret;
+ }
+
+ ctx-override_cd_active_level = override_active_level;
+ ctx-cd_gpio = desc;
+
+ return 0;
+}
+EXPORT_SYMBOL(mmc_gpiod_request_cd);
+
+/**
+ * mmc_gpiod_free_cd - free the card-detection gpio descriptor
+ * @host: mmc host
+ *
+ * It's provided only for cases that client drivers need to manually free
+ * up the card-detection gpio requested by mmc_gpiod_request_cd().
+ */
+void mmc_gpiod_free_cd(struct mmc_host *host)
+{
+ struct mmc_gpio *ctx = host-slot.handler_priv;
+
+ if (!ctx || !ctx-cd_gpio)
+ return;
+
+ if (host-slot.cd_irq = 0) {
+ devm_free_irq(host-class_dev, host-slot.cd_irq, host);
+ host-slot.cd_irq = -EINVAL;
+ }
+
+ devm_gpiod_put(host-class_dev, ctx-cd_gpio);
+
+ ctx-cd_gpio = NULL;
+}
+EXPORT_SYMBOL(mmc_gpiod_free_cd);
diff --git a/include/linux/mmc/slot-gpio.h b/include/linux/mmc/slot-gpio.h
index b0c73e4..d243338 100644
[linux-yocto] [PATCH 17/24] mmc: sdhci-acpi: Intel SDIO has broken card detect
From: Adrian Hunter adrian.hun...@intel.com
Intel SDIO has broken card detect so add a quirk to reflect that.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Acked-by: Ulf Hansson ulf.hans...@linaro.org
Signed-off-by: Chris Ball ch...@printf.net
(cherry picked from commit c67480173f72e883235dd0ad09d90156c8f87600)
---
drivers/mmc/host/sdhci-acpi.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index 0d372f0..ebb3f39 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -122,6 +122,7 @@ static const struct sdhci_acpi_slot
sdhci_acpi_slot_int_emmc = {
};
static const struct sdhci_acpi_slot sdhci_acpi_slot_int_sdio = {
+ .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION,
.quirks2 = SDHCI_QUIRK2_HOST_OFF_CARD_ON,
.caps= MMC_CAP_NONREMOVABLE | MMC_CAP_POWER_OFF_CARD,
.flags = SDHCI_ACPI_RUNTIME_PM,
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 15/24] mmc: sdhci-acpi: Add device id 80860F16
From: Adrian Hunter adrian.hun...@intel.com
Add ACPI HID 80860F16 as a host controller for a SD card.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Signed-off-by: Chris Ball ch...@printf.net
(cherry picked from commit aad95dc49c6dad19b49af7cd90c53473ec0536d1)
---
drivers/mmc/host/sdhci-acpi.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index 98c7420..0d372f0 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -143,6 +143,7 @@ struct sdhci_acpi_uid_slot {
static const struct sdhci_acpi_uid_slot sdhci_acpi_uids[] = {
{ 80860F14 , 1 , sdhci_acpi_slot_int_emmc },
{ 80860F14 , 3 , sdhci_acpi_slot_int_sd },
+ { 80860F16 , NULL, sdhci_acpi_slot_int_sd },
{ INT33BB , 2 , sdhci_acpi_slot_int_sdio },
{ INT33C6 , NULL, sdhci_acpi_slot_int_sdio },
{ INT3436 , NULL, sdhci_acpi_slot_int_sdio },
@@ -152,6 +153,7 @@ static const struct sdhci_acpi_uid_slot sdhci_acpi_uids[] =
{
static const struct acpi_device_id sdhci_acpi_ids[] = {
{ 80860F14 },
+ { 80860F16 },
{ INT33BB },
{ INT33C6 },
{ INT3436 },
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 18/24] spi/pxa2xx-pci: Add PCI mode support for BayTrail LPSS SPI
From: Chew, Chiau Ee chiau.ee.c...@intel.com
Similar to CE4100, BayTrail LPSS SPI can be PCI enumerated
as well. Thus, the functions are renamed from ce4100_xxx
to pxa2xx_spi_pci_xxx to clarify that this is a generic
PCI glue layer. Also, added required infrastructure to
support SPI hosts with different configurations.
This patch is based on Mika Westerberg's previous work.
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Mark Brown broo...@linaro.org
(cherry picked from commit d6ba32d5c60f569d252ec9dcd96cd46b19785b60)
From linux-next
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
drivers/spi/spi-pxa2xx-pci.c | 76 +-
1 file changed, 61 insertions(+), 15 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 3f006d3..c1865c9 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -8,7 +8,43 @@
#include linux/module.h
#include linux/spi/pxa2xx_spi.h
-static int ce4100_spi_probe(struct pci_dev *dev,
+enum {
+ PORT_CE4100,
+ PORT_BYT,
+};
+
+struct pxa_spi_info {
+ enum pxa_ssp_type type;
+ int port_id;
+ int num_chipselect;
+ int tx_slave_id;
+ int tx_chan_id;
+ int rx_slave_id;
+ int rx_chan_id;
+};
+
+static struct pxa_spi_info spi_info_configs[] = {
+ [PORT_CE4100] = {
+ .type = PXA25x_SSP,
+ .port_id = -1,
+ .num_chipselect = -1,
+ .tx_slave_id = -1,
+ .tx_chan_id = -1,
+ .rx_slave_id = -1,
+ .rx_chan_id = -1,
+ },
+ [PORT_BYT] = {
+ .type = LPSS_SSP,
+ .port_id = 0,
+ .num_chipselect = 1,
+ .tx_slave_id = 0,
+ .tx_chan_id = 0,
+ .rx_slave_id = 1,
+ .rx_chan_id = 1,
+ },
+};
+
+static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
const struct pci_device_id *ent)
{
struct platform_device_info pi;
@@ -16,6 +52,7 @@ static int ce4100_spi_probe(struct pci_dev *dev,
struct platform_device *pdev;
struct pxa2xx_spi_master spi_pdata;
struct ssp_device *ssp;
+ struct pxa_spi_info *c;
ret = pcim_enable_device(dev);
if (ret)
@@ -25,8 +62,16 @@ static int ce4100_spi_probe(struct pci_dev *dev,
if (ret)
return ret;
+ c = spi_info_configs[ent-driver_data];
+
memset(spi_pdata, 0, sizeof(spi_pdata));
- spi_pdata.num_chipselect = dev-devfn;
+ spi_pdata.num_chipselect = (c-num_chipselect 0) ?
+ c-num_chipselect : dev-devfn;
+ spi_pdata.tx_slave_id = c-tx_slave_id;
+ spi_pdata.tx_chan_id = c-tx_chan_id;
+ spi_pdata.rx_slave_id = c-rx_slave_id;
+ spi_pdata.rx_chan_id = c-rx_chan_id;
+ spi_pdata.enable_dma = c-rx_slave_id = 0 c-tx_slave_id = 0;
ssp = spi_pdata.ssp;
ssp-phys_base = pci_resource_start(dev, 0);
@@ -36,8 +81,8 @@ static int ce4100_spi_probe(struct pci_dev *dev,
return -EIO;
}
ssp-irq = dev-irq;
- ssp-port_id = dev-devfn;
- ssp-type = PXA25x_SSP;
+ ssp-port_id = (c-port_id = 0) ? c-port_id : dev-devfn;
+ ssp-type = c-type;
memset(pi, 0, sizeof(pi));
pi.parent = dev-dev;
@@ -55,28 +100,29 @@ static int ce4100_spi_probe(struct pci_dev *dev,
return 0;
}
-static void ce4100_spi_remove(struct pci_dev *dev)
+static void pxa2xx_spi_pci_remove(struct pci_dev *dev)
{
struct platform_device *pdev = pci_get_drvdata(dev);
platform_device_unregister(pdev);
}
-static const struct pci_device_id ce4100_spi_devices[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x2e6a) },
+static const struct pci_device_id pxa2xx_spi_pci_devices[] = {
+ { PCI_VDEVICE(INTEL, 0x2e6a), PORT_CE4100 },
+ { PCI_VDEVICE(INTEL, 0x0f0e), PORT_BYT },
{ },
};
-MODULE_DEVICE_TABLE(pci, ce4100_spi_devices);
+MODULE_DEVICE_TABLE(pci, pxa2xx_spi_pci_devices);
-static struct pci_driver ce4100_spi_driver = {
- .name = ce4100_spi,
- .id_table = ce4100_spi_devices,
- .probe = ce4100_spi_probe,
- .remove = ce4100_spi_remove,
+static struct pci_driver pxa2xx_spi_pci_driver = {
+ .name = pxa2xx_spi_pci,
+ .id_table = pxa2xx_spi_pci_devices,
+ .probe = pxa2xx_spi_pci_probe,
+ .remove = pxa2xx_spi_pci_remove,
};
-module_pci_driver(ce4100_spi_driver);
+module_pci_driver(pxa2xx_spi_pci_driver);
-MODULE_DESCRIPTION(CE4100 PCI-SPI glue code for PXA's driver);
+MODULE_DESCRIPTION(CE4100/LPSS PCI-SPI glue code for PXA's driver);
MODULE_LICENSE(GPL v2);
MODULE_AUTHOR(Sebastian Andrzej Siewior bige...@linutronix.de);
--
1.7.9.5
--
___
linux-yocto mailing list
linux
[linux-yocto] [PATCH 20/24] pwm: lpss: Add support for PCI devices
From: Alan Cox a...@linux.intel.com
Not all systems enumerate the PWM devices via ACPI. They can also be
exposed via the PCI interface.
Signed-off-by: Alan Cox a...@linux.intel.com
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Reviewed-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Thierry Reding thierry.red...@gmail.com
(cherry picked from commit 093e00bb3f82f3c67e2d1682e316fc012bcd0d92)
From linux-next/next-20140512
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
drivers/pwm/pwm-lpss.c | 161 ++--
1 file changed, 130 insertions(+), 31 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 449e372..c718ad1 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -6,6 +6,7 @@
* Author: Chew Kean Ho kean.ho.c...@intel.com
* Author: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com
* Author: Chew Chiau Ee chiau.ee.c...@intel.com
+ * Author: Alan Cox a...@linux.intel.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -19,6 +20,9 @@
#include linux/module.h
#include linux/pwm.h
#include linux/platform_device.h
+#include linux/pci.h
+
+static int pci_drv, plat_drv; /* So we know which drivers registered */
#define PWM0x
#define PWM_ENABLE BIT(31)
@@ -34,6 +38,16 @@ struct pwm_lpss_chip {
struct pwm_chip chip;
void __iomem *regs;
struct clk *clk;
+ unsigned long clk_rate;
+};
+
+struct pwm_lpss_boardinfo {
+ unsigned long clk_rate;
+};
+
+/* BayTrail */
+static const struct pwm_lpss_boardinfo byt_info = {
+ 2500
};
static inline struct pwm_lpss_chip *to_lpwm(struct pwm_chip *chip)
@@ -55,7 +69,7 @@ static int pwm_lpss_config(struct pwm_chip *chip, struct
pwm_device *pwm,
/* The equation is: base_unit = ((freq / c) * 65536) + correction */
base_unit = freq * 65536;
- c = clk_get_rate(lpwm-clk);
+ c = lpwm-clk_rate;
if (!c)
return -EINVAL;
@@ -113,52 +127,48 @@ static const struct pwm_ops pwm_lpss_ops = {
.owner = THIS_MODULE,
};
-static const struct acpi_device_id pwm_lpss_acpi_match[] = {
- { 80860F09, 0 },
- { },
-};
-MODULE_DEVICE_TABLE(acpi, pwm_lpss_acpi_match);
-
-static int pwm_lpss_probe(struct platform_device *pdev)
+static struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev,
+ struct resource *r,
+ struct pwm_lpss_boardinfo *info)
{
struct pwm_lpss_chip *lpwm;
- struct resource *r;
int ret;
- lpwm = devm_kzalloc(pdev-dev, sizeof(*lpwm), GFP_KERNEL);
+ lpwm = devm_kzalloc(dev, sizeof(*lpwm), GFP_KERNEL);
if (!lpwm)
- return -ENOMEM;
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ return ERR_PTR(-ENOMEM);
- lpwm-regs = devm_ioremap_resource(pdev-dev, r);
+ lpwm-regs = devm_ioremap_resource(dev, r);
if (IS_ERR(lpwm-regs))
- return PTR_ERR(lpwm-regs);
-
- lpwm-clk = devm_clk_get(pdev-dev, NULL);
- if (IS_ERR(lpwm-clk)) {
- dev_err(pdev-dev, failed to get PWM clock\n);
- return PTR_ERR(lpwm-clk);
+ return lpwm-regs;
+
+ if (info) {
+ lpwm-clk_rate = info-clk_rate;
+ } else {
+ lpwm-clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(lpwm-clk)) {
+ dev_err(dev, failed to get PWM clock\n);
+ return ERR_CAST(lpwm-clk);
+ }
+ lpwm-clk_rate = clk_get_rate(lpwm-clk);
}
- lpwm-chip.dev = pdev-dev;
+ lpwm-chip.dev = dev;
lpwm-chip.ops = pwm_lpss_ops;
lpwm-chip.base = -1;
lpwm-chip.npwm = 1;
ret = pwmchip_add(lpwm-chip);
if (ret) {
- dev_err(pdev-dev, failed to add PWM chip: %d\n, ret);
- return ret;
+ dev_err(dev, failed to add PWM chip: %d\n, ret);
+ return ERR_PTR(ret);
}
- platform_set_drvdata(pdev, lpwm);
- return 0;
+ return lpwm;
}
-static int pwm_lpss_remove(struct platform_device *pdev)
+static int pwm_lpss_remove(struct pwm_lpss_chip *lpwm)
{
- struct pwm_lpss_chip *lpwm = platform_get_drvdata(pdev);
u32 ctrl;
ctrl = readl(lpwm-regs + PWM);
@@ -167,15 +177,104 @@ static int pwm_lpss_remove(struct platform_device *pdev)
return pwmchip_remove(lpwm-chip);
}
-static struct platform_driver pwm_lpss_driver = {
+static int pwm_lpss_probe_pci(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ const struct pwm_lpss_boardinfo *info;
+ struct pwm_lpss_chip *lpwm;
+ int err
[linux-yocto] [PATCH 19/24] drm/i915/vlv: reset VLV media force wake request register
Media force wake get hangs the machine when the system is booted without
displays attached. The assumption is that (at least some versions of)
the firmware has skipped some initialization in that case.
Empirical evidence suggests we need to reset the media force wake
request register in addition to the render one to avoid hangs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75895
Reported-by: Imre Deak imre.d...@intel.com
Reported-by: Darren Hart dvh...@linux.intel.com
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_uncore.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 87df68f..c879631 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -177,6 +177,8 @@ static void vlv_force_wake_reset(struct drm_i915_private
*dev_priv)
{
__raw_i915_write32(dev_priv, FORCEWAKE_VLV,
_MASKED_BIT_DISABLE(0x));
+ __raw_i915_write32(dev_priv, FORCEWAKE_MEDIA_VLV,
+ _MASKED_BIT_DISABLE(0x));
/* something from same cacheline, but !FORCEWAKE_VLV */
__raw_posting_read(dev_priv, FORCEWAKE_ACK_VLV);
}
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 00/24] [3.14] Baytrail driver updates
A number of incremental fixes have been made upstream and in linux-next. There are a couple still under review, but which are functional and useful. All non-mainline patches are annotated as such in the commit message, but for reference, the top 7 patches are not yet in mainline: d0047ab acpi_lpss: Add Bay Trail pinctrl HID 97d42f9 spi/pxa2xx: Add common clock framework support in PCI glue layer ac5ccf2 clkdev: Export clk_register_clkdev 6d381c2 pwm: lpss: Fix const qualifier and sparse warnings e4a7de2 pwm: lpss: Add support for PCI devices e2eb8ab drm/i915/vlv: reset VLV media force wake request register f695f17 spi/pxa2xx-pci: Add PCI mode support for BayTrail LPSS SPI Of those, the top three are still undergoing review, and only: 97d42f9 spi/pxa2xx: Add common clock framework support in PCI glue layer Adds any new functionality. It has received considerable review and should be close to acceptance. It is required to use the SPI device when enumerated as PCI on Baytrail platforms. From a high level, this series accomplishes the following: * Fix MMC in ACPI mode * Enable PCI mode for SPI and PWM * Fix an i915 initialization hang when no display is connected at boot The following changes since commit b0b9c962ea01f9356fc1542b9696ebe4a38e196a: Merge tag 'v3.14.2' into standard/base (2014-04-28 23:52:14 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-3.14 dvhart/standard/minnowmax http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.14/log/?h=dvhart/standard/minnowmax Adrian Hunter (7): mmc: sdhci: Allow for irq being shared mmc: sdhci-acpi: Fix broken card detect for ACPI HID 80860F14 mmc: slot-gpio: Record GPIO descriptors instead of GPIO numbers mmc: slot-gpio: Split out CD IRQ request into a separate function mmc: slot-gpio: Add GPIO descriptor based CD GPIO API mmc: sdhci-acpi: Add device id 80860F16 mmc: sdhci-acpi: Intel SDIO has broken card detect Alan Cox (1): pwm: lpss: Add support for PCI devices Chew, Chiau Ee (6): ACPI / LPSS: Add Intel BayTrail ACPI mode PWM dma: dw: Add suspend and resume handling for PCI mode DW_DMAC. i2c: designware-pci: add 10-bit addressing mode functionality for BYT I2C i2c: designware-pci: set ideal HCNT, LCNT and SDA hold time value spi/pxa2xx-pci: Add PCI mode support for BayTrail LPSS SPI spi/pxa2xx: Add common clock framework support in PCI glue layer Chew, Kean Ho (1): pinctrl-baytrail: add function mux checking in gpio pin request Chew, Kean ho (1): i2c: i801: enable Intel BayTrail SMBUS Darren Hart (3): drm/i915/vlv: reset VLV media force wake request register clkdev: Export clk_register_clkdev acpi_lpss: Add Bay Trail pinctrl HID Mika Westerberg (2): pwm: add support for Intel Low Power Subsystem PWM i2c: designware-pci: Add Baytrail PCI IDs Paul Drews (1): ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs Thierry Reding (1): pwm: lpss: Fix const qualifier and sparse warnings Thomas Gleixner (1): genirq: x86: Ensure that dynamic irq allocation does not conflict Documentation/i2c/busses/i2c-i801 |1 + arch/x86/kernel/apic/io_apic.c |5 + drivers/acpi/acpi_lpss.c | 12 ++ drivers/clk/clkdev.c |1 + drivers/dma/dw/pci.c | 33 drivers/gpu/drm/i915/intel_uncore.c|2 + drivers/i2c/busses/Kconfig |1 + drivers/i2c/busses/i2c-designware-pcidrv.c | 66 ++- drivers/i2c/busses/i2c-i801.c |3 + drivers/mmc/core/core.c|4 + drivers/mmc/core/slot-gpio.c | 180 ++ drivers/mmc/host/sdhci-acpi.c | 80 ++-- drivers/mmc/host/sdhci.c |4 +- drivers/pinctrl/pinctrl-baytrail.c | 43 - drivers/pwm/Kconfig| 10 + drivers/pwm/Makefile |1 + drivers/pwm/pwm-lpss.c | 282 drivers/spi/spi-pxa2xx-pci.c | 93 +++-- drivers/spi/spi-pxa2xx.c |5 +- include/linux/irq.h|2 + include/linux/mmc/slot-gpio.h |6 + kernel/irq/irqdesc.c |7 + kernel/softirq.c |5 + 23 files changed, 714 insertions(+), 132 deletions(-) create mode 100644 drivers/pwm/pwm-lpss.c -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 02/24] pwm: add support for Intel Low Power Subsystem PWM
From: Mika Westerberg mika.westerb...@linux.intel.com
Add support for Intel Low Power I/O subsystem PWM controllers found on
Intel BayTrail SoC.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Chew, Kean Ho kean.ho.c...@intel.com
Signed-off-by: Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Thierry Reding thierry.red...@gmail.com
(cherry picked from commit d16a5aa9e821633a3095d7a88cd1d2cd108bf966)
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
drivers/pwm/Kconfig| 10 +++
drivers/pwm/Makefile |1 +
drivers/pwm/pwm-lpss.c | 183
3 files changed, 194 insertions(+)
create mode 100644 drivers/pwm/pwm-lpss.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 22f2f28..36bf194 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -119,6 +119,16 @@ config PWM_LPC32XX
To compile this driver as a module, choose M here: the module
will be called pwm-lpc32xx.
+config PWM_LPSS
+ tristate Intel LPSS PWM support
+ depends on ACPI
+ help
+ Generic PWM framework driver for Intel Low Power Subsystem PWM
+ controller.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-lpss.
+
config PWM_MXS
tristate Freescale MXS PWM support
depends on ARCH_MXS OF
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index d8906ec..61bf073 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_PWM_IMX) += pwm-imx.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LP3943) += pwm-lp3943.o
obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
+obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
new file mode 100644
index 000..449e372
--- /dev/null
+++ b/drivers/pwm/pwm-lpss.c
@@ -0,0 +1,183 @@
+/*
+ * Intel Low Power Subsystem PWM controller driver
+ *
+ * Copyright (C) 2014, Intel Corporation
+ * Author: Mika Westerberg mika.westerb...@linux.intel.com
+ * Author: Chew Kean Ho kean.ho.c...@intel.com
+ * Author: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com
+ * Author: Chew Chiau Ee chiau.ee.c...@intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/acpi.h
+#include linux/clk.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pwm.h
+#include linux/platform_device.h
+
+#define PWM0x
+#define PWM_ENABLE BIT(31)
+#define PWM_SW_UPDATE BIT(30)
+#define PWM_BASE_UNIT_SHIFT8
+#define PWM_BASE_UNIT_MASK 0x0000
+#define PWM_ON_TIME_DIV_MASK 0x00ff
+#define PWM_DIVISION_CORRECTION0x2
+#define PWM_LIMIT (0x8000 + PWM_DIVISION_CORRECTION)
+#define NSECS_PER_SEC 10UL
+
+struct pwm_lpss_chip {
+ struct pwm_chip chip;
+ void __iomem *regs;
+ struct clk *clk;
+};
+
+static inline struct pwm_lpss_chip *to_lpwm(struct pwm_chip *chip)
+{
+ return container_of(chip, struct pwm_lpss_chip, chip);
+}
+
+static int pwm_lpss_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ struct pwm_lpss_chip *lpwm = to_lpwm(chip);
+ u8 on_time_div;
+ unsigned long c;
+ unsigned long long base_unit, freq = NSECS_PER_SEC;
+ u32 ctrl;
+
+ do_div(freq, period_ns);
+
+ /* The equation is: base_unit = ((freq / c) * 65536) + correction */
+ base_unit = freq * 65536;
+
+ c = clk_get_rate(lpwm-clk);
+ if (!c)
+ return -EINVAL;
+
+ do_div(base_unit, c);
+ base_unit += PWM_DIVISION_CORRECTION;
+ if (base_unit PWM_LIMIT)
+ return -EINVAL;
+
+ if (duty_ns = 0)
+ duty_ns = 1;
+ on_time_div = 255 - (255 * duty_ns / period_ns);
+
+ ctrl = readl(lpwm-regs + PWM);
+ ctrl = ~(PWM_BASE_UNIT_MASK | PWM_ON_TIME_DIV_MASK);
+ ctrl |= (u16) base_unit PWM_BASE_UNIT_SHIFT;
+ ctrl |= on_time_div;
+ /* request PWM to update on next cycle */
+ ctrl |= PWM_SW_UPDATE;
+ writel(ctrl, lpwm-regs + PWM);
+
+ return 0;
+}
+
+static int pwm_lpss_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct pwm_lpss_chip *lpwm = to_lpwm(chip);
+ u32 ctrl;
+ int ret;
+
+ ret = clk_prepare_enable(lpwm-clk);
+ if (ret)
+ return ret
[linux-yocto] [PATCH 05/24] mmc: sdhci: Allow for irq being shared
From: Adrian Hunter adrian.hun...@intel.com
If the SDHCI irq is shared with another device then the interrupt
handler can get called while SDHCI is runtime suspended. That is
harmless but the warning message is not useful so remove it. Also
returning IRQ_NONE is more appropriate.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Signed-off-by: Chris Ball ch...@printf.net
(cherry picked from commit 655bca7616bf6076d30b14d1478bca6807d49c45)
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
drivers/mmc/host/sdhci.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9ddef47..135018e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2434,9 +2434,7 @@ static irqreturn_t sdhci_irq(int irq, void *dev_id)
if (host-runtime_suspended) {
spin_unlock(host-lock);
- pr_warning(%s: got irq while runtime suspended\n,
- mmc_hostname(host-mmc));
- return IRQ_HANDLED;
+ return IRQ_NONE;
}
intmask = sdhci_readl(host, SDHCI_INT_STATUS);
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 06/24] dma: dw: Add suspend and resume handling for PCI mode DW_DMAC.
From: Chew, Chiau Ee chiau.ee.c...@intel.com
This is to disable/enable DW_DMAC hw during late suspend/early resume.
Since DMA is providing service to other clients (eg: SPI, HSUART),
we need to ensure DMA suspends after the clients and resume
before the clients are active.
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Acked-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Vinod Koul vinod.k...@intel.com
(cherry picked from commit 4501fe61b286e35be5b372a4f1ffcf5881ceeaed)
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
drivers/dma/dw/pci.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/dma/dw/pci.c b/drivers/dma/dw/pci.c
index e89fc24..806bcb2 100644
--- a/drivers/dma/dw/pci.c
+++ b/drivers/dma/dw/pci.c
@@ -75,6 +75,36 @@ static void dw_pci_remove(struct pci_dev *pdev)
dev_warn(pdev-dev, can't remove device properly: %d\n, ret);
}
+#ifdef CONFIG_PM_SLEEP
+
+static int dw_pci_suspend_late(struct device *dev)
+{
+ struct pci_dev *pci = to_pci_dev(dev);
+ struct dw_dma_chip *chip = pci_get_drvdata(pci);
+
+ return dw_dma_suspend(chip);
+};
+
+static int dw_pci_resume_early(struct device *dev)
+{
+ struct pci_dev *pci = to_pci_dev(dev);
+ struct dw_dma_chip *chip = pci_get_drvdata(pci);
+
+ return dw_dma_resume(chip);
+};
+
+#else /* !CONFIG_PM_SLEEP */
+
+#define dw_pci_suspend_lateNULL
+#define dw_pci_resume_earlyNULL
+
+#endif /* !CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops dw_pci_dev_pm_ops = {
+ .suspend_late = dw_pci_suspend_late,
+ .resume_early = dw_pci_resume_early,
+};
+
static DEFINE_PCI_DEVICE_TABLE(dw_pci_id_table) = {
/* Medfield */
{ PCI_VDEVICE(INTEL, 0x0827), (kernel_ulong_t)dw_pci_pdata },
@@ -92,6 +122,9 @@ static struct pci_driver dw_pci_driver = {
.id_table = dw_pci_id_table,
.probe = dw_pci_probe,
.remove = dw_pci_remove,
+ .driver = {
+ .pm = dw_pci_dev_pm_ops,
+ },
};
module_pci_driver(dw_pci_driver);
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 21/24] pwm: lpss: Fix const qualifier and sparse warnings
From: Thierry Reding thierry.red...@gmail.com
Fixes the following warnings reported by the 0-DAY kernel build testing
backend:
drivers/pwm/pwm-lpss.c: In function 'pwm_lpss_probe_pci':
drivers/pwm/pwm-lpss.c:192:2: warning: passing argument 3 of
'pwm_lpss_probe' discards 'const' qualifier from pointer target type
[enabled by default]
lpwm = pwm_lpss_probe(pdev-dev, pdev-resource[0], info);
^
drivers/pwm/pwm-lpss.c:130:30: note: expected 'struct pwm_lpss_boardinfo *'
but argument is of type 'const struct pwm_lpss_boardinfo *'
static struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev,
^
drivers/pwm/pwm-lpss.c:143:28: sparse: incorrect type in return expression
(different address spaces)
drivers/pwm/pwm-lpss.c:143:28:expected struct pwm_lpss_chip *
drivers/pwm/pwm-lpss.c:143:28:got void [noderef] asn:2*regs
drivers/pwm/pwm-lpss.c:192:63: sparse: incorrect type in argument 3
(different modifiers)
drivers/pwm/pwm-lpss.c:192:63:expected struct pwm_lpss_boardinfo *info
drivers/pwm/pwm-lpss.c:192:63:got struct pwm_lpss_boardinfo const
*[assigned] info
drivers/pwm/pwm-lpss.c: In function 'pwm_lpss_probe_pci':
drivers/pwm/pwm-lpss.c:192:2: warning: passing argument 3 of
'pwm_lpss_probe' discards 'const' qualifier from pointer target type [enabled
by default]
lpwm = pwm_lpss_probe(pdev-dev, pdev-resource[0], info);
^
drivers/pwm/pwm-lpss.c:130:30: note: expected 'struct pwm_lpss_boardinfo *'
but argument is of type 'const struct pwm_lpss_boardinfo *'
static struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev,
^
Reported-by: kbuild test robot fengguang...@intel.com
Signed-off-by: Thierry Reding thierry.red...@gmail.com
(cherry picked from commit 89c0339e0aa097384b3efed894b23820814c21d3)
From linux-next/next-20140512
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
drivers/pwm/pwm-lpss.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index c718ad1..44ce6c6 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -129,7 +129,7 @@ static const struct pwm_ops pwm_lpss_ops = {
static struct pwm_lpss_chip *pwm_lpss_probe(struct device *dev,
struct resource *r,
- struct pwm_lpss_boardinfo *info)
+ const struct pwm_lpss_boardinfo
*info)
{
struct pwm_lpss_chip *lpwm;
int ret;
@@ -140,7 +140,7 @@ static struct pwm_lpss_chip *pwm_lpss_probe(struct device
*dev,
lpwm-regs = devm_ioremap_resource(dev, r);
if (IS_ERR(lpwm-regs))
- return lpwm-regs;
+ return ERR_CAST(lpwm-regs);
if (info) {
lpwm-clk_rate = info-clk_rate;
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 12/24] mmc: slot-gpio: Record GPIO descriptors instead of GPIO numbers
From: Adrian Hunter adrian.hun...@intel.com
In preparation for adding a descriptor-based CD GPIO API, switch from
recording GPIO numbers to recording GPIO descriptors.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Tested-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Chris Ball ch...@printf.net
(cherry picked from commit 842f4bdd37c7a0984e22aa919ad1f043137ac5c8)
---
drivers/mmc/core/slot-gpio.c | 45 +-
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc/core/slot-gpio.c b/drivers/mmc/core/slot-gpio.c
index 46596b71..86547a2 100644
--- a/drivers/mmc/core/slot-gpio.c
+++ b/drivers/mmc/core/slot-gpio.c
@@ -10,6 +10,7 @@
#include linux/err.h
#include linux/gpio.h
+#include linux/gpio/consumer.h
#include linux/interrupt.h
#include linux/jiffies.h
#include linux/mmc/host.h
@@ -18,8 +19,10 @@
#include linux/slab.h
struct mmc_gpio {
- int ro_gpio;
- int cd_gpio;
+ struct gpio_desc *ro_gpio;
+ struct gpio_desc *cd_gpio;
+ bool override_ro_active_level;
+ bool override_cd_active_level;
char *ro_label;
char cd_label[0];
};
@@ -57,8 +60,6 @@ static int mmc_gpio_alloc(struct mmc_host *host)
ctx-ro_label = ctx-cd_label + len;
snprintf(ctx-cd_label, len, %s cd,
dev_name(host-parent));
snprintf(ctx-ro_label, len, %s ro,
dev_name(host-parent));
- ctx-cd_gpio = -EINVAL;
- ctx-ro_gpio = -EINVAL;
host-slot.handler_priv = ctx;
}
}
@@ -72,11 +73,14 @@ int mmc_gpio_get_ro(struct mmc_host *host)
{
struct mmc_gpio *ctx = host-slot.handler_priv;
- if (!ctx || !gpio_is_valid(ctx-ro_gpio))
+ if (!ctx || !ctx-ro_gpio)
return -ENOSYS;
- return !gpio_get_value_cansleep(ctx-ro_gpio) ^
- !!(host-caps2 MMC_CAP2_RO_ACTIVE_HIGH);
+ if (ctx-override_ro_active_level)
+ return !gpiod_get_raw_value_cansleep(ctx-ro_gpio) ^
+ !!(host-caps2 MMC_CAP2_RO_ACTIVE_HIGH);
+
+ return gpiod_get_value_cansleep(ctx-ro_gpio);
}
EXPORT_SYMBOL(mmc_gpio_get_ro);
@@ -84,11 +88,14 @@ int mmc_gpio_get_cd(struct mmc_host *host)
{
struct mmc_gpio *ctx = host-slot.handler_priv;
- if (!ctx || !gpio_is_valid(ctx-cd_gpio))
+ if (!ctx || !ctx-cd_gpio)
return -ENOSYS;
- return !gpio_get_value_cansleep(ctx-cd_gpio) ^
- !!(host-caps2 MMC_CAP2_CD_ACTIVE_HIGH);
+ if (ctx-override_cd_active_level)
+ return !gpiod_get_raw_value_cansleep(ctx-cd_gpio) ^
+ !!(host-caps2 MMC_CAP2_CD_ACTIVE_HIGH);
+
+ return gpiod_get_value_cansleep(ctx-cd_gpio);
}
EXPORT_SYMBOL(mmc_gpio_get_cd);
@@ -125,7 +132,8 @@ int mmc_gpio_request_ro(struct mmc_host *host, unsigned int
gpio)
if (ret 0)
return ret;
- ctx-ro_gpio = gpio;
+ ctx-override_ro_active_level = true;
+ ctx-ro_gpio = gpio_to_desc(gpio);
return 0;
}
@@ -201,7 +209,8 @@ int mmc_gpio_request_cd(struct mmc_host *host, unsigned int
gpio,
if (irq 0)
host-caps |= MMC_CAP_NEEDS_POLL;
- ctx-cd_gpio = gpio;
+ ctx-override_cd_active_level = true;
+ ctx-cd_gpio = gpio_to_desc(gpio);
return 0;
}
@@ -219,11 +228,11 @@ void mmc_gpio_free_ro(struct mmc_host *host)
struct mmc_gpio *ctx = host-slot.handler_priv;
int gpio;
- if (!ctx || !gpio_is_valid(ctx-ro_gpio))
+ if (!ctx || !ctx-ro_gpio)
return;
- gpio = ctx-ro_gpio;
- ctx-ro_gpio = -EINVAL;
+ gpio = desc_to_gpio(ctx-ro_gpio);
+ ctx-ro_gpio = NULL;
devm_gpio_free(host-class_dev, gpio);
}
@@ -241,7 +250,7 @@ void mmc_gpio_free_cd(struct mmc_host *host)
struct mmc_gpio *ctx = host-slot.handler_priv;
int gpio;
- if (!ctx || !gpio_is_valid(ctx-cd_gpio))
+ if (!ctx || !ctx-cd_gpio)
return;
if (host-slot.cd_irq = 0) {
@@ -249,8 +258,8 @@ void mmc_gpio_free_cd(struct mmc_host *host)
host-slot.cd_irq = -EINVAL;
}
- gpio = ctx-cd_gpio;
- ctx-cd_gpio = -EINVAL;
+ gpio = desc_to_gpio(ctx-cd_gpio);
+ ctx-cd_gpio = NULL;
devm_gpio_free(host-class_dev, gpio);
}
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 22/24] clkdev: Export clk_register_clkdev
Allow spi-pxa2xx-pci with common clock framework support to build as a module by exporting clk_register_clkdev. Signed-off-by: Darren Hart dvh...@linux.intel.com Cc: Chew, Chiau Ee chiau.ee.c...@intel.com Cc: Mika Westerberg mika.westerb...@linux.intel.com --- drivers/clk/clkdev.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c index 48f6721..64cac1c 100644 --- a/drivers/clk/clkdev.c +++ b/drivers/clk/clkdev.c @@ -308,6 +308,7 @@ int clk_register_clkdev(struct clk *clk, const char *con_id, return 0; } +EXPORT_SYMBOL(clk_register_clkdev); /** * clk_register_clkdevs - register a set of clk_lookup for a struct clk -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 00/24] [3.14] Baytrail driver updates
On 5/13/14, 9:29, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 14-05-13 12:11 PM, Darren Hart wrote: A number of incremental fixes have been made upstream and in linux-next. There are a couple still under review, but which are functional and useful. All non-mainline patches are annotated as such in the commit message, but for reference, the top 7 patches are not yet in mainline: d0047ab acpi_lpss: Add Bay Trail pinctrl HID 97d42f9 spi/pxa2xx: Add common clock framework support in PCI glue layer ac5ccf2 clkdev: Export clk_register_clkdev 6d381c2 pwm: lpss: Fix const qualifier and sparse warnings e4a7de2 pwm: lpss: Add support for PCI devices e2eb8ab drm/i915/vlv: reset VLV media force wake request register f695f17 spi/pxa2xx-pci: Add PCI mode support for BayTrail LPSS SPI Of those, the top three are still undergoing review, and only: 97d42f9 spi/pxa2xx: Add common clock framework support in PCI glue layer Adds any new functionality. It has received considerable review and should be close to acceptance. It is required to use the SPI device when enumerated as PCI on Baytrail platforms. I can live with the above. From a high level, this series accomplishes the following: * Fix MMC in ACPI mode * Enable PCI mode for SPI and PWM * Fix an i915 initialization hang when no display is connected at boot excellent. The following changes since commit b0b9c962ea01f9356fc1542b9696ebe4a38e196a: Merge tag 'v3.14.2' into standard/base (2014-04-28 23:52:14 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-3.14 dvhart/standard/minnowmax http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.14/log/?h=dvhart/stand ard/minnowmax And to confirm .. you do want this on a minnowmax holding zone branch ? Blarg, I missed that rather critical point. Given that this is pretty much all ready to go, I'd prefer this goes to standard/base. If we don't want anything on standard/base that isn't a mainline backport, then we should discuss a standard/intel branch as this is intel-common material, and not necessarily BSP specific. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 00/24] [3.14] Baytrail driver updates
On 5/13/14, 9:49, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 14-05-13 12:11 PM, Darren Hart wrote: A number of incremental fixes have been made upstream and in linux-next. There are a couple still under review, but which are functional and useful. All non-mainline patches are annotated as such in the commit message, but for reference, the top 7 patches are not yet in mainline: d0047ab acpi_lpss: Add Bay Trail pinctrl HID 97d42f9 spi/pxa2xx: Add common clock framework support in PCI glue layer ac5ccf2 clkdev: Export clk_register_clkdev 6d381c2 pwm: lpss: Fix const qualifier and sparse warnings e4a7de2 pwm: lpss: Add support for PCI devices e2eb8ab drm/i915/vlv: reset VLV media force wake request register f695f17 spi/pxa2xx-pci: Add PCI mode support for BayTrail LPSS SPI Of those, the top three are still undergoing review, and only: 97d42f9 spi/pxa2xx: Add common clock framework support in PCI glue layer Adds any new functionality. It has received considerable review and should be close to acceptance. It is required to use the SPI device when enumerated as PCI on Baytrail platforms. From a high level, this series accomplishes the following: * Fix MMC in ACPI mode * Enable PCI mode for SPI and PWM * Fix an i915 initialization hang when no display is connected at boot The following changes since commit b0b9c962ea01f9356fc1542b9696ebe4a38e196a: Merge tag 'v3.14.2' into standard/base (2014-04-28 23:52:14 -0400) Merged to standard/base (and then propagated out to all BSP branches). Keep an eye out for issues, but since this is mainline code, it is safe for all boards (i.e. not used), so nothing should go wrong :) Thanks - I noticed there is a dvhart/meta and a dvhart/standard/minnowmax in the linux-yocto-3.14 repository - those shouldn't be there. Did you accidentally push those? If not... Did I... I didn't think I could... -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] pruning of unused branches from linux-yocto-3.14 kernel repository
On 5/13/14, 10:06, Kamble, Nitin A nitin.a.kam...@intel.com wrote: Hi Bruce, As most of the BSPs from meta-intel layer are using the standard/base for KBRANCH, these kernel branches from the linux-yocto-3.14 repository are not needed anymore, and can be deleted to reduce the branch count. Darren, Tom, Do you see any of these branches used anywhere else? standard/common-pc-64/chiefriver standard/common-pc-64/crystalforest standard/common-pc-64/jasperforest standard/common-pc-64/mohonpeak standard/common-pc-64/rangeley standard/common-pc-64/romley standard/common-pc-64/sugarbay standard/common-pc/atom-pc standard/crownbay standard/emenlow standard/fri2 standard/preempt-rt/base Let's not prune preempt-rt/base - we should instead be adding the linux-yocto-rt recipe for 3.14! Bruce, there is a preempt-rt 3.14.3-rt5 available. I don't see it in the linux-yoct 3.14 repository. Am I missing it - are you waiting for someone to send the patch? This is *way* late to be doing this But we really should have preempt-rt at least in the tree :-( Sadly, I just haven't had time to do it unfortunately, but there is enough interest out there that we really should be making this part of our release criteria going forward. If it just builds Should we add the recipe and include it? standard/sys940x standard/tiny/fri2 Bruce, If there is no objection you can proceed with deleting of these branches from the L-Y v3.14 kernel repository. Thanks, Nitin -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 00/24] [3.14] Baytrail driver updates
On 5/13/14, 20:47, Ong, Boon Leong boon.leong@intel.com wrote: Merged to standard/base (and then propagated out to all BSP branches). Keep an eye out for issues, but since this is mainline code, it is safe for all boards (i.e. not used), so nothing should go wrong :) Just want to clarify the practice below because it does conflicts with my understand on linux-yocto only merges commits from -stable branch. This isn't quite right. The general rule is that linux-yocto only accepts mainline backports to standard/base. Consider it more like LTSI than -stable. Features and new drivers are acceptable in linux-yocto standard/base so long as they are sufficiently self contained and do not put other BSPs at risk. Linux-yocto is, effectively, a distro kernel in terms of patch policy. Is this true that with intel common kernel, standard/base is now accepting patches of type: (1) in-queue for mainline (2) yet to be in-queue for mainline. You're absolutely right that this is a stretch from the guiding principles. Of this series, there is only 1 patch that has any real risk of changing before merge - that's the PCI enumeration of the SPI bus. It has undergone quite a bit of review and we felt was likely baked enough to go in (I suspect it would also be acceptable to LTSI 3.14 - if such a thing existed). That was the criteria I used. All such patch series will have to be considered on a case by case basis and will be the exception, rather than the rule. We shouldn't plan for such things :-) Question to clarify on what is happening here on v3.14 standard/base: 1) Will the patches in-flight for mainline be eventually cherry-picked back to v3.14 -stable branch? No, because they are not all bug fixes. Some of them could be though and we should look into which if any have already been queued for stable, and then consider the rest. The reason that I ask is, if someone does, I assume that these patches which are now merged into standard/base be dropped/updated with the commit back-ported into v3.14-stable branch? When Bruce does a git merge v3.14.4 or whatever, the two trees will merge - that brings two different development branches together into one - you don't explicitly drop older versions of patches. If the merge becomes a problem, Bruce may choose to revert the problematic patches - but there is only one real candidate for that (the PCI SPI patch). 2) Why the patches not in-flight to mainline be lined-up on feature or machine branch, then be merged into standard/base? There is only 1 really (the other two are trivial one liners which will be incorporated into future patches in mainline and disappear in the merges to follow). This one could have been in a feature branch. The reason it isn't is because after reviewing its history, I felt it was pretty much baked. Time will tell if that was the right call or not. It's possible we should have created a new standard/intel branch for all such things. In general though, that should only be necessary if we risk breaking other platforms with patches or if the patches are still under relatively active development. I would reject such patches anyway and suggest they go into a feature branch, so the standard/intel branch seemed unnecessary to me. Definitely an exception to the rule and you are right to ask for more detail on the decision making process here. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 0/1] [3.14] meta: Update Baytrail SoC config fragment
Minnowboard Max makes use of the I2C and PWM devices and may use either ACPI or PCI enumeration. Make sure these are available in the SoC config fragment. The following changes since commit 4df1e2ed992adeac4da60ad5118d0237e8cb88df: meta: bump to v3.14.2 (2014-04-28 23:50:30 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-3.14 dvhart/meta/baytrail http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.14/log/?h=dvhart/meta/baytrail Darren Hart (1): baytrail: Add I2C PCI and LPSS_PWM support .../features/soc/baytrail/baytrail.cfg |2 ++ 1 file changed, 2 insertions(+) -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] meta: intel-corei7-64 nr_cpus set to 24
On 4/9/14, 10:39, boon.leong@intel.com boon.leong@intel.com wrote: From: Ong Boon Leong boon.leong@intel.com Change default nr_cpus to 24 instead of default 8 because Romley platform supports 24 SMP processors. Signed-off-by: Ong Boon Leong boon.leong@intel.com --- meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.cfg |1 + 1 file changed, 1 insertion(+) diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.cfg b/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.cfg index e7616f3..b9dd9fb 100644 --- a/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.cfg +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.cfg @@ -1,2 +1,3 @@ # There isn't an option for CPUs newer than MCORE2 in the Kconfig CONFIG_MCORE2=y +CONFIG_NR_CPUS=24 I'd prefer to see this in the SMP fragment. I discussed with Nitin and we agreed that 64 was reasonable. I doubt the overhead will be a problem. If it is, we can split into amp-small and smp-big. But lets not start making this BSP specific unless we really have a need to. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH] minnow: Add minnow-drivers-extra fragment
Driver requests tend to trickle in slowly. Provide a staging fragment where we can collect those that are not already covered by existing scc files. As blocks of drivers become apparent, new scc files can be created and this file pruned. Signed-off-by: Darren Hart dvh...@linux.intel.com --- .../bsp/minnow/minnow-drivers-extra.cfg|1 + .../kernel-cache/bsp/minnow/minnow-preempt-rt.scc |3 +++ .../kernel-cache/bsp/minnow/minnow-standard.scc|3 +++ 3 files changed, 7 insertions(+) create mode 100644 meta/cfg/kernel-cache/bsp/minnow/minnow-drivers-extra.cfg diff --git a/meta/cfg/kernel-cache/bsp/minnow/minnow-drivers-extra.cfg b/meta/cfg/kernel-cache/bsp/minnow/minnow-drivers-extra.cfg new file mode 100644 index 000..62189f6 --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/minnow/minnow-drivers-extra.cfg @@ -0,0 +1 @@ +CONFIG_USB_ACM=m diff --git a/meta/cfg/kernel-cache/bsp/minnow/minnow-preempt-rt.scc b/meta/cfg/kernel-cache/bsp/minnow/minnow-preempt-rt.scc index b5c7b50..4a383fb 100644 --- a/meta/cfg/kernel-cache/bsp/minnow/minnow-preempt-rt.scc +++ b/meta/cfg/kernel-cache/bsp/minnow/minnow-preempt-rt.scc @@ -22,3 +22,6 @@ include cfg/usb-mass-storage.scc include cfg/boot-live.scc include features/latencytop/latencytop.scc include features/profiling/profiling.scc + +# Requested drivers that don't have an existing scc +kconf hardware minnow-drivers-extra.cfg diff --git a/meta/cfg/kernel-cache/bsp/minnow/minnow-standard.scc b/meta/cfg/kernel-cache/bsp/minnow/minnow-standard.scc index 7d4d6e1..741ef3e 100644 --- a/meta/cfg/kernel-cache/bsp/minnow/minnow-standard.scc +++ b/meta/cfg/kernel-cache/bsp/minnow/minnow-standard.scc @@ -18,3 +18,6 @@ include cfg/boot-live.scc # Basic profiling include features/latencytop/latencytop.scc include features/profiling/profiling.scc + +# Requested drivers that don't have an existing scc +kconf hardware minnow-drivers-extra.cfg -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] meta: smp.scc: increase default NR_CPUS to 64
On 4/10/14, 4:20, boon.leong@intel.com boon.leong@intel.com wrote: From: Ong Boon Leong boon.leong@intel.com Change CONFIG_NR_CPUS from 8 to 64 so that platform with processors count more than 8 will be all activited. Signed-off-by: Ong Boon Leong boon.leong@intel.com Acked-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/cfg/smp.cfg |3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/cfg/kernel-cache/cfg/smp.cfg b/meta/cfg/kernel-cache/cfg/smp.cfg index f53b969..2204774 100644 --- a/meta/cfg/kernel-cache/cfg/smp.cfg +++ b/meta/cfg/kernel-cache/cfg/smp.cfg @@ -1,2 +1,5 @@ CONFIG_SMP=y CONFIG_SCHED_SMT=y +# Increase default NR_CPUS from 8 to 64 so that platform with +# more than 8 processors can be all activated at boot time +CONFIG_NR_CPUS=64 -- 1.7.10.4 -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/1] [v3.10] meta: change smp.scc default NR_CPUS to 64
On 4/10/14, 4:20, boon.leong@intel.com boon.leong@intel.com wrote: From: Ong Boon Leong boon.leong@intel.com This patch is for Linux v3.10 meta: Bruce, please also apply to 3.14. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/2] intel-common: change intel-corei7064-preempt-rt-scc filename
On 4/3/14, 17:47, boon.leong@intel.com boon.leong@intel.com wrote: From: Ong Boon Leong boon.leong@intel.com Changed intel-corei7064-preempt-rt-scc file name to intel-corei7-64-preempt-rt.scc. Signed-off-by: Ong Boon Leong boon.leong@intel.com Acked-by: Darren Hart dvh...@linux.intel.com I may have missed this if not for Bruce's response. Please Cc the relevant parties in patches. -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH][3.10][meta] intel-common: Add preempt-rt ktype targets
On 4/1/14, 17:52, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 2014-03-31, 7:34 PM, Darren Hart wrote: Add the preempt-rt ktype scc targets for the intel-core2-32 and intel-corei7-64 BSPs. These are also the intel-common configuration used for all intel-common compatible BSPs. I assume you want this on 3.14 and -dev as well ? It looks fine to me, confirm which versions you want it for, and I'll do the merge. Only tested on 3.10 since that's where our RT support is. But yes, they can go everywhere and keep it all in sync if you are OK with PREEMPT-RT meta-data where there is no preempt-rt support. -- Darren Cheers, Bruce Signed-off-by: Darren Hart dvh...@linux.intel.com --- .../bsp/intel-common/intel-core2-32-preempt-rt.scc |9 + .../intel-common/intel-corei7064-preempt-rt-scc|9 + 2 files changed, 18 insertions(+) create mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-preempt-rt.scc create mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-corei7064-preempt-rt-scc diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-preempt-rt.scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-preempt-rt.scc new file mode 100644 index 000..1b33927 --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-preempt-rt.scc @@ -0,0 +1,9 @@ +define KMACHINE intel-core2-32 +define KTYPE preempt-rt +define KARCH i386 + +# no new branch required, re-use the ktypes/preempt-rt/preempt-rt.scc branch +include ktypes/preempt-rt/preempt-rt.scc + +include intel-common-standard.scc +include intel-core2-32.scc diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7064-preempt-rt-scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7064-preempt-rt-scc new file mode 100644 index 000..d020408 --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7064-preempt-rt-scc @@ -0,0 +1,9 @@ +define KMACHINE intel-corei7-64 +define KTYPE preempt-rt +define KARCH x86_64 + +# no new branch required, re-use the ktypes/preempt-rt/preempt-rt.scc branch +include ktypes/preempt-rt/preempt-rt.scc + +include intel-common-standard.scc +include intel-corei7-64.scc -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 2/6] common-pc: Remove SMP from common-pc*-cpu fragments
The x86 and x86_64 config fragments already include SMP and SMT support, remove the redundant configuration in the common-pc*-cpu.cfg files. Signed-off-by: Darren Hart dvh...@linux.intel.com --- .../bsp/common-pc-64/common-pc-64-cpu.cfg |2 -- .../kernel-cache/bsp/common-pc/common-pc-cpu.cfg |1 - 2 files changed, 3 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64-cpu.cfg b/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64-cpu.cfg index 3cf6df2..8dced73 100644 --- a/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64-cpu.cfg +++ b/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64-cpu.cfg @@ -11,9 +11,7 @@ # #. -CONFIG_SMP=y CONFIG_MCORE2=y CONFIG_IA32_EMULATION=y -CONFIG_SCHED_SMT=y CONFIG_NR_CPUS=24 CONFIG_PM=y diff --git a/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg b/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg index ad55eb6..7254517 100644 --- a/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg +++ b/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg @@ -16,5 +16,4 @@ CONFIG_X86_GENERIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_MTRR=y -CONFIG_SMP=y CONFIG_PM=y -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 1/6] x86: Consolidate common x86* CPU features
Move the basic arch, MSR, CPUID, and MICROCODE CONFIG options out of the common-pc*-cpu.cfg fragments and into the cfg/x86*cfg fragments where they can be more easily reused. Signed-off-by: Darren Hart dvh...@linux.intel.com --- .../bsp/common-pc-64/common-pc-64-cpu.cfg |5 - .../kernel-cache/bsp/common-pc/common-pc-cpu.cfg |5 - meta/cfg/kernel-cache/cfg/x86.cfg |8 +++- meta/cfg/kernel-cache/cfg/x86_64.cfg |7 +++ 4 files changed, 14 insertions(+), 11 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64-cpu.cfg b/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64-cpu.cfg index e44b958..3cf6df2 100644 --- a/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64-cpu.cfg +++ b/meta/cfg/kernel-cache/bsp/common-pc-64/common-pc-64-cpu.cfg @@ -11,14 +11,9 @@ # #. -CONFIG_X86=y -CONFIG_64BIT=y CONFIG_SMP=y CONFIG_MCORE2=y CONFIG_IA32_EMULATION=y -CONFIG_MICROCODE=y -CONFIG_X86_MSR=y -CONFIG_X86_CPUID=y CONFIG_SCHED_SMT=y CONFIG_NR_CPUS=24 CONFIG_PM=y diff --git a/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg b/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg index 077de28..ad55eb6 100644 --- a/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg +++ b/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg @@ -11,15 +11,10 @@ # #. CONFIG_X86_32=y -# CONFIG_64BIT is not set -CONFIG_X86=y CONFIG_MPENTIUMM=y CONFIG_X86_GENERIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y -CONFIG_MICROCODE=y -CONFIG_X86_MSR=y -CONFIG_X86_CPUID=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_PM=y diff --git a/meta/cfg/kernel-cache/cfg/x86.cfg b/meta/cfg/kernel-cache/cfg/x86.cfg index 473d399..06906b0 100644 --- a/meta/cfg/kernel-cache/cfg/x86.cfg +++ b/meta/cfg/kernel-cache/cfg/x86.cfg @@ -1,10 +1,16 @@ # Config settings specific to x86 and not in an existing cfg/foo.cfg +CONFIG_X86=y +# CONFIG_64BIT is not set CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y CONFIG_X86_REBOOTFIXUPS=y -CONFIG_MICROCODE_AMD=y CONFIG_HIGHPTE=y CONFIG_X86_CHECK_BIOS_CORRUPTION=y CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y +CONFIG_X86_MSR=y +CONFIG_X86_CPUID=y +CONFIG_MICROCODE=y +CONFIG_MICROCODE_AMD=y +CONFIG_MICROCODE_INTEL=y # CONFIG_MTRR_SANITIZER is not set CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_PCIE is not set diff --git a/meta/cfg/kernel-cache/cfg/x86_64.cfg b/meta/cfg/kernel-cache/cfg/x86_64.cfg index 2050c22..c45f496 100644 --- a/meta/cfg/kernel-cache/cfg/x86_64.cfg +++ b/meta/cfg/kernel-cache/cfg/x86_64.cfg @@ -1,6 +1,13 @@ # Config settings specific to x86_64 and not in an existing cfg/foo.cfg +CONFIG_X86=y +CONFIG_64BIT=y CONFIG_X86_CHECK_BIOS_CORRUPTION=y CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y +CONFIG_X86_MSR=y +CONFIG_X86_CPUID=y +CONFIG_MICROCODE=y +CONFIG_MICROCODE_AMD=y +CONFIG_MICROCODE_INTEL=y # CONFIG_MTRR_SANITIZER is not set CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_PCIE is not set -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 5/6] x32: Drop x32 config
CONFIG_X86_32 is a non-selectable configuration item, automatically set by ARCH and !CONFIG_64BIT. There are no users of the .cfg nor the .scc. Delete them. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/cfg/x32.cfg |1 - meta/cfg/kernel-cache/cfg/x32.scc |4 2 files changed, 5 deletions(-) delete mode 100644 meta/cfg/kernel-cache/cfg/x32.cfg delete mode 100644 meta/cfg/kernel-cache/cfg/x32.scc diff --git a/meta/cfg/kernel-cache/cfg/x32.cfg b/meta/cfg/kernel-cache/cfg/x32.cfg deleted file mode 100644 index 725e05f..000 --- a/meta/cfg/kernel-cache/cfg/x32.cfg +++ /dev/null @@ -1 +0,0 @@ -CONFIG_X86_X32=y diff --git a/meta/cfg/kernel-cache/cfg/x32.scc b/meta/cfg/kernel-cache/cfg/x32.scc deleted file mode 100644 index e4b954a..000 --- a/meta/cfg/kernel-cache/cfg/x32.scc +++ /dev/null @@ -1,4 +0,0 @@ -define KFEATURE_DESCRIPTION x86 x32 support -define KFEATURE_COMPATIBILITY arch - -kconf non-hardware x32.cfg -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 6/6] meta: Purge retired BSPs chiefriver, sys940x, and atom-pc
Drop the BSP configs for the BSPs retired from meta-intel, which will never have a 3.14 recipe: chiefriver, sys940x, and atom-pc (from the n450 BSP). Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-eth.cfg |2 - .../bsp/atom-pc/atom-pc-preempt-rt.scc |9 .../kernel-cache/bsp/atom-pc/atom-pc-standard.scc |8 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-wifi.cfg |4 -- meta/cfg/kernel-cache/bsp/atom-pc/atom-pc.scc |6 --- .../bsp/chiefriver/chiefriver-preempt-rt.scc | 15 --- .../bsp/chiefriver/chiefriver-standard.scc | 10 - .../cfg/kernel-cache/bsp/chiefriver/chiefriver.cfg | 33 -- .../cfg/kernel-cache/bsp/chiefriver/chiefriver.scc |8 .../bsp/intel-common/intel-core2-32.scc|1 - .../bsp/intel-common/intel-corei7-64.scc |1 - .../bsp/sys940x/sys940x-preempt-rt.scc | 15 --- .../kernel-cache/bsp/sys940x/sys940x-standard.scc | 15 --- meta/cfg/kernel-cache/bsp/sys940x/sys940x.cfg | 45 meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc | 10 - 15 files changed, 182 deletions(-) delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-eth.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-preempt-rt.scc delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-standard.scc delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-wifi.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc.scc delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver-preempt-rt.scc delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver-standard.scc delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver.scc delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x-preempt-rt.scc delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x-standard.scc delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc diff --git a/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-eth.cfg b/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-eth.cfg deleted file mode 100644 index bb392f4..000 --- a/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-eth.cfg +++ /dev/null @@ -1,2 +0,0 @@ -CONFIG_R8169=y -CONFIG_ATL1E=y diff --git a/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-preempt-rt.scc b/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-preempt-rt.scc deleted file mode 100644 index 3f4e360..000 --- a/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-preempt-rt.scc +++ /dev/null @@ -1,9 +0,0 @@ -define KMACHINE atom-pc -define KTYPE preempt-rt -define KARCH i386 - -include bsp/common-pc/common-pc-preempt-rt.scc -# No new branch required, re-use from preempt-rt.scc -#branch atom-pc - -include atom-pc.scc diff --git a/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-standard.scc b/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-standard.scc deleted file mode 100644 index 8892e8d..000 --- a/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-standard.scc +++ /dev/null @@ -1,8 +0,0 @@ -define KMACHINE atom-pc -define KTYPE standard -define KARCH i386 - -include bsp/common-pc/common-pc-standard.scc -branch atom-pc - -include atom-pc.scc diff --git a/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-wifi.cfg b/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-wifi.cfg deleted file mode 100644 index 7226c08..000 --- a/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-wifi.cfg +++ /dev/null @@ -1,4 +0,0 @@ -CONFIG_ATH9K=y - -CONFIG_RT2X00=y -CONFIG_RT2800PCI=y diff --git a/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc.scc b/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc.scc deleted file mode 100644 index 00585f0..000 --- a/meta/cfg/kernel-cache/bsp/atom-pc/atom-pc.scc +++ /dev/null @@ -1,6 +0,0 @@ -kconf hardware atom-pc-eth.cfg -kconf hardware atom-pc-wifi.cfg - -include cfg/x86.scc -include cfg/boot-live.scc -include features/i915/i915.scc diff --git a/meta/cfg/kernel-cache/bsp/chiefriver/chiefriver-preempt-rt.scc b/meta/cfg/kernel-cache/bsp/chiefriver/chiefriver-preempt-rt.scc deleted file mode 100644 index c8b5210..000 --- a/meta/cfg/kernel-cache/bsp/chiefriver/chiefriver-preempt-rt.scc +++ /dev/null @@ -1,15 +0,0 @@ -define KMACHINE chiefriver -define KTYPE preempt-rt -define KARCH x86_64 - -# no new branch required, re-use the ktypes/preempt-rt/preempt-rt.scc branch -include ktypes/preempt-rt/preempt-rt.scc -include bsp/common-pc-64/common-pc-64.scc - -include chiefriver.scc - -# default policy for preempt-rt kernels -include cfg/usb-mass-storage.scc -include cfg/boot-live.scc -include features/latencytop/latencytop.scc -include features/profiling/profiling.scc diff --git a/meta/cfg/kernel-cache/bsp/chiefriver/chiefriver-standard.scc b/meta/cfg/kernel-cache/bsp/chiefriver/chiefriver-standard.scc deleted file mode 100644 index 2681ab7..000 --- a/meta
[linux-yocto] [PATCH 3/6] x86: Move MTRR config into x86 common fragments
MTRR is common enough it should just be included in the x86* cfg fragments already included by these machines. Signed-off-by: Darren Hart dvh...@linux.intel.com --- .../kernel-cache/bsp/common-pc/common-pc-cpu.cfg |1 - meta/cfg/kernel-cache/bsp/fri2/fri2.cfg|1 - meta/cfg/kernel-cache/bsp/minnow/minnow.cfg|1 - meta/cfg/kernel-cache/cfg/x86.cfg |1 + meta/cfg/kernel-cache/cfg/x86_64.cfg |1 + 5 files changed, 2 insertions(+), 3 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg b/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg index 7254517..3479648 100644 --- a/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg +++ b/meta/cfg/kernel-cache/bsp/common-pc/common-pc-cpu.cfg @@ -15,5 +15,4 @@ CONFIG_MPENTIUMM=y CONFIG_X86_GENERIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y -CONFIG_MTRR=y CONFIG_PM=y diff --git a/meta/cfg/kernel-cache/bsp/fri2/fri2.cfg b/meta/cfg/kernel-cache/bsp/fri2/fri2.cfg index b4cfffe..1ed21a9 100644 --- a/meta/cfg/kernel-cache/bsp/fri2/fri2.cfg +++ b/meta/cfg/kernel-cache/bsp/fri2/fri2.cfg @@ -4,7 +4,6 @@ CONFIG_PRINTK=y # Configs required for boot on this device CONFIG_DMI=y -CONFIG_MTRR=y # Basic hardware support for the box - network, USB, PCI, sound CONFIG_ATA=y diff --git a/meta/cfg/kernel-cache/bsp/minnow/minnow.cfg b/meta/cfg/kernel-cache/bsp/minnow/minnow.cfg index 2be4ea4..e20fdc0 100644 --- a/meta/cfg/kernel-cache/bsp/minnow/minnow.cfg +++ b/meta/cfg/kernel-cache/bsp/minnow/minnow.cfg @@ -3,7 +3,6 @@ CONFIG_MATOM=y # Configs required for boot on this device CONFIG_DMI=y -CONFIG_MTRR=y # Basic hardware support for the box - network, USB, PCI, sound CONFIG_PCI=y diff --git a/meta/cfg/kernel-cache/cfg/x86.cfg b/meta/cfg/kernel-cache/cfg/x86.cfg index 06906b0..9edd6d2 100644 --- a/meta/cfg/kernel-cache/cfg/x86.cfg +++ b/meta/cfg/kernel-cache/cfg/x86.cfg @@ -11,6 +11,7 @@ CONFIG_X86_CPUID=y CONFIG_MICROCODE=y CONFIG_MICROCODE_AMD=y CONFIG_MICROCODE_INTEL=y +CONFIG_MTRR=y # CONFIG_MTRR_SANITIZER is not set CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_PCIE is not set diff --git a/meta/cfg/kernel-cache/cfg/x86_64.cfg b/meta/cfg/kernel-cache/cfg/x86_64.cfg index c45f496..5133fc2 100644 --- a/meta/cfg/kernel-cache/cfg/x86_64.cfg +++ b/meta/cfg/kernel-cache/cfg/x86_64.cfg @@ -8,6 +8,7 @@ CONFIG_X86_CPUID=y CONFIG_MICROCODE=y CONFIG_MICROCODE_AMD=y CONFIG_MICROCODE_INTEL=y +CONFIG_MTRR=y # CONFIG_MTRR_SANITIZER is not set CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_PCIE is not set -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 0/6][dev][3.14]meta: Cleanup x86 config fragments
These patches cleanup various aspects of the x86 and x86_64 CPU support by consolidating it into the cfg/x86 and cfg/x86_64 fragments and removing redundant configuration from some of the BSPs. The redundant bits were not removed from the ISG BSPs, leaving that to their maintainers. Build tested and config verified on intel-core* systems with linux-yocto-dev. The most significant net change from this series is the addition of X86_MSR and X86_CPUID options to the intel-core* BSPs which were missing these before. These are intended for linux-yocto-dev and linux-yocto-3.14. I assume that we want to avoid refactoring the 3.10 meta-data at this point? The following changes since commit fc8c30398dbc3cdea787a1042242d4aab689d0ae: meta: bump kver to v3.14 (2014-03-31 09:56:45 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib dvhart/meta/x86 http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=dvhart/meta/x86 Darren Hart (6): x86: Consolidate common x86* CPU features common-pc: Remove SMP from common-pc*-cpu fragments x86: Move MTRR config into x86 common fragments x86: Drop X86_32 configs x32: Drop x32 config meta: Purge retired BSPs chiefriver, sys940x, and atom-pc meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-eth.cfg |2 - .../bsp/atom-pc/atom-pc-preempt-rt.scc |9 .../kernel-cache/bsp/atom-pc/atom-pc-standard.scc |8 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-wifi.cfg |4 -- meta/cfg/kernel-cache/bsp/atom-pc/atom-pc.scc |6 --- .../bsp/chiefriver/chiefriver-preempt-rt.scc | 15 --- .../bsp/chiefriver/chiefriver-standard.scc | 10 - .../cfg/kernel-cache/bsp/chiefriver/chiefriver.cfg | 33 -- .../cfg/kernel-cache/bsp/chiefriver/chiefriver.scc |8 .../bsp/common-pc-64/common-pc-64-cpu.cfg |7 --- .../kernel-cache/bsp/common-pc/common-pc-cpu.cfg |8 meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg|1 - meta/cfg/kernel-cache/bsp/emenlow/emenlow.cfg |2 - meta/cfg/kernel-cache/bsp/fri2/fri2.cfg|2 - .../bsp/intel-common/intel-core2-32.scc|1 - .../bsp/intel-common/intel-corei7-64.scc |1 - meta/cfg/kernel-cache/bsp/minnow/minnow.cfg|2 - .../bsp/sys940x/sys940x-preempt-rt.scc | 15 --- .../kernel-cache/bsp/sys940x/sys940x-standard.scc | 15 --- meta/cfg/kernel-cache/bsp/sys940x/sys940x.cfg | 46 meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc | 10 - meta/cfg/kernel-cache/cfg/x32.cfg |1 - meta/cfg/kernel-cache/cfg/x32.scc |4 -- meta/cfg/kernel-cache/cfg/x86.cfg |9 +++- meta/cfg/kernel-cache/cfg/x86_64.cfg |8 25 files changed, 16 insertions(+), 211 deletions(-) delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-eth.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-preempt-rt.scc delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-standard.scc delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-wifi.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc.scc delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver-preempt-rt.scc delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver-standard.scc delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver.scc delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x-preempt-rt.scc delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x-standard.scc delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc delete mode 100644 meta/cfg/kernel-cache/cfg/x32.cfg delete mode 100644 meta/cfg/kernel-cache/cfg/x32.scc -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 0/6][dev][3.14]meta: Cleanup x86 config fragments
On 4/2/14, 7:20, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 14-04-02 03:19 AM, Darren Hart wrote: These patches cleanup various aspects of the x86 and x86_64 CPU support by consolidating it into the cfg/x86 and cfg/x86_64 fragments and removing redundant configuration from some of the BSPs. The redundant bits were not removed from the ISG BSPs, leaving that to their maintainers. Build tested and config verified on intel-core* systems with linux-yocto-dev. The most significant net change from this series is the addition of X86_MSR and X86_CPUID options to the intel-core* BSPs which were missing these before. These are intended for linux-yocto-dev and linux-yocto-3.14. I assume that we want to avoid refactoring the 3.10 meta-data at this point? The series looks fine to me. As for 3.10, the only issue might be the removal of the retired boards, but as long as my 3.10 updates aren't pull back to an older release, there's no issue. But just in case that does happen, lets isolate this to 3.10 and -dev. Yeah, the purge retired BSPs patch should be only on 3.14 and dev. The rest should be OK for 3.10, 3.14, and dev. Is that what you meant? -- Darren Bruce The following changes since commit fc8c30398dbc3cdea787a1042242d4aab689d0ae: meta: bump kver to v3.14 (2014-03-31 09:56:45 -0400) are available in the git repository at: git://git.yoctoproject.org/linux-yocto-contrib dvhart/meta/x86 http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=dvhart/me ta/x86 Darren Hart (6): x86: Consolidate common x86* CPU features common-pc: Remove SMP from common-pc*-cpu fragments x86: Move MTRR config into x86 common fragments x86: Drop X86_32 configs x32: Drop x32 config meta: Purge retired BSPs chiefriver, sys940x, and atom-pc meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-eth.cfg |2 - .../bsp/atom-pc/atom-pc-preempt-rt.scc |9 .../kernel-cache/bsp/atom-pc/atom-pc-standard.scc |8 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-wifi.cfg |4 -- meta/cfg/kernel-cache/bsp/atom-pc/atom-pc.scc |6 --- .../bsp/chiefriver/chiefriver-preempt-rt.scc | 15 --- .../bsp/chiefriver/chiefriver-standard.scc | 10 - .../cfg/kernel-cache/bsp/chiefriver/chiefriver.cfg | 33 -- .../cfg/kernel-cache/bsp/chiefriver/chiefriver.scc |8 .../bsp/common-pc-64/common-pc-64-cpu.cfg |7 --- .../kernel-cache/bsp/common-pc/common-pc-cpu.cfg |8 meta/cfg/kernel-cache/bsp/crownbay/crownbay.cfg|1 - meta/cfg/kernel-cache/bsp/emenlow/emenlow.cfg |2 - meta/cfg/kernel-cache/bsp/fri2/fri2.cfg|2 - .../bsp/intel-common/intel-core2-32.scc|1 - .../bsp/intel-common/intel-corei7-64.scc |1 - meta/cfg/kernel-cache/bsp/minnow/minnow.cfg|2 - .../bsp/sys940x/sys940x-preempt-rt.scc | 15 --- .../kernel-cache/bsp/sys940x/sys940x-standard.scc | 15 --- meta/cfg/kernel-cache/bsp/sys940x/sys940x.cfg | 46 meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc | 10 - meta/cfg/kernel-cache/cfg/x32.cfg |1 - meta/cfg/kernel-cache/cfg/x32.scc |4 -- meta/cfg/kernel-cache/cfg/x86.cfg |9 +++- meta/cfg/kernel-cache/cfg/x86_64.cfg |8 25 files changed, 16 insertions(+), 211 deletions(-) delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-eth.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-preempt-rt.scc delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-standard.scc delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc-wifi.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/atom-pc/atom-pc.scc delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver-preempt-rt.scc delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver-standard.scc delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/chiefriver/chiefriver.scc delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x-preempt-rt.scc delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x-standard.scc delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x.cfg delete mode 100644 meta/cfg/kernel-cache/bsp/sys940x/sys940x.scc delete mode 100644 meta/cfg/kernel-cache/cfg/x32.cfg delete mode 100644 meta/cfg/kernel-cache/cfg/x32.scc -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 5/6] x32: Drop x32 config
On 4/2/14, 8:20, Stanacar, StefanX stefanx.stana...@intel.com wrote:
On Wed, 2014-04-02 at 18:11 +0300, Stefan Stanacar wrote:
On Wed, 2014-04-02 at 00:19 -0700, Darren Hart wrote:
CONFIG_X86_32 is a non-selectable configuration item, automatically
set
by ARCH and !CONFIG_64BIT. There are no users of the .cfg nor the
.scc.
Delete them.
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
meta/cfg/kernel-cache/cfg/x32.cfg |1 -
meta/cfg/kernel-cache/cfg/x32.scc |4
2 files changed, 5 deletions(-)
delete mode 100644 meta/cfg/kernel-cache/cfg/x32.cfg
delete mode 100644 meta/cfg/kernel-cache/cfg/x32.scc
Does this mean oe-core will need an update on linux-yocto*.bb which has:
KERNEL_FEATURES_append = ${@bb.utils.contains(TUNE_FEATURES, mx32,
cfg/x32.scc, ,d)}
?
And on a second look, your commit message says CONFIG_X86_32 but this is
about x32, which I don't think gets set like that.
Kconfig says:
config X86_X32
bool x32 ABI for 64-bit mode
depends on X86_64 IA32_EMULATION
Ugh, you are correct. Thank you for catching that. Oh the difference an X
makes!
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] yocto-layer vs bsp-layer : criteria of choice of approach toward a custom image
From: New B new...@yahoo.com Date: Monday, March 31, 2014 at 16:27 To: linux-yocto linux-yocto@yoctoproject.org Subject: [linux-yocto] yocto-layer vs bsp-layer : criteria of choice of approach toward a custom image Hi, I am v new to yocto; read most of the doc'n and skimmed through the rest. I git cloned the dora branch, tag yocto 1.5.1 final Here are my questions: 1- how come yocto-bsp tool wont work except when invoked within the poky/build dir though e doc'n implies that new layers should be at the top level within the source directory? Does it even make sense to create the bsp layer in a disposable directory that is not part of the repo? Yocto-bsp depends on the source dir to create the new layer. Once created, you can (should) move the generated layer to a location of your choosing, get it under revision control, etc. No, it doesn't make sense to leave it where it is generated. 2- ditto for hob? Hob uses bitbake, so also requires the proper environment to be setup. My task is to build an arm8 linux image, where the specific board has not yet been designed (because of stuff i signed, i can only share that the image is being used as an element into modeling what the board should look like). So: 3- how do you decide the approach you take in building custom image? A- Do i build a64-bit arm8 linux distro using yocto-layer create and add within it a conf/machine? Example? B- Do i build a64-bit arm8 bsp layer using yocto-bsp create and add within it a conf/recipes-kernel ? Example? Depends on what you want to add. Anything with an _MACHINEOVERRIDE or a files/MACHINE should be in a BSP layer. Anything else belongs in a separate layer. It will work regardless, but this is the guideline for Yocto Project Compatibility. Whether or not you need a new BSP depends of course on whether or not one already exists that works for your device. If you want to change something in the MACHINE.conf, you basically want a new BSP. Recipes don't go under conf, see meta-intel or another BSP layer for examples of where to add kernel recipes. (typically under the top level meta layer /recipes-kernel/linux/linux-*.bb). -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] intel-common: Add mohonpeak BSP
On 3/25/14, 17:48, boon.leong@intel.com boon.leong@intel.com wrote: From: Ong Boon Leong boon.leong@intel.com Add mohonpeak 32-bit 64-bit BSP into intel-common. Signed-off-by: Ong Boon Leong boon.leong@intel.com Acked-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32.scc |1 + meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.scc |1 + 2 files changed, 2 insertions(+) diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32.scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32.scc index b6d18a4..6505035 100644 --- a/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32.scc +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32.scc @@ -15,6 +15,7 @@ include bsp/crownbay/crownbay.scc include bsp/emenlow/emenlow.scc include bsp/fri2/fri2.scc include bsp/sys940x/sys940x.scc +include bsp/mohonpeak/mohonpeak32.scc # This line comes last as it has the final word on # CONFIG values. diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.scc index 853ec92..159c3f2 100644 --- a/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.scc +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7-64.scc @@ -17,6 +17,7 @@ include bsp/haswell-wc/haswell-wc.scc include bsp/jasperforest/jasperforest.scc include bsp/romley/romley.scc include bsp/sugarbay/sugarbay.scc +include bsp/mohonpeak/mohonpeak.scc # This line comes last as it has the final word on # CONFIG values. -- 1.7.10.4 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH][3.10][meta] intel-common: Add preempt-rt ktype targets
Add the preempt-rt ktype scc targets for the intel-core2-32 and intel-corei7-64 BSPs. These are also the intel-common configuration used for all intel-common compatible BSPs. Signed-off-by: Darren Hart dvh...@linux.intel.com --- .../bsp/intel-common/intel-core2-32-preempt-rt.scc |9 + .../intel-common/intel-corei7064-preempt-rt-scc|9 + 2 files changed, 18 insertions(+) create mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-preempt-rt.scc create mode 100644 meta/cfg/kernel-cache/bsp/intel-common/intel-corei7064-preempt-rt-scc diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-preempt-rt.scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-preempt-rt.scc new file mode 100644 index 000..1b33927 --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-core2-32-preempt-rt.scc @@ -0,0 +1,9 @@ +define KMACHINE intel-core2-32 +define KTYPE preempt-rt +define KARCH i386 + +# no new branch required, re-use the ktypes/preempt-rt/preempt-rt.scc branch +include ktypes/preempt-rt/preempt-rt.scc + +include intel-common-standard.scc +include intel-core2-32.scc diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7064-preempt-rt-scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7064-preempt-rt-scc new file mode 100644 index 000..d020408 --- /dev/null +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-corei7064-preempt-rt-scc @@ -0,0 +1,9 @@ +define KMACHINE intel-corei7-64 +define KTYPE preempt-rt +define KARCH x86_64 + +# no new branch required, re-use the ktypes/preempt-rt/preempt-rt.scc branch +include ktypes/preempt-rt/preempt-rt.scc + +include intel-common-standard.scc +include intel-corei7-64.scc -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [meta][dev][3.10] intel-common: Add media-all
Please apply this patch to both the dev kernel and the 3.10 kernel to add the medial-all fragment to all intel-common-standard kernels. Currently this impacts the intel-core2-32 and intel-corei7-64 standard KTYPE kernels. -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH] intel-common: Add media-all to the standard builds
Provide the drivers for common media devices like webcabs and tuners in the intel-common-standard kernels. Reported-by: Scott Garman scott.a.gar...@intel.com Signed-off-by: Darren Hart dvh...@linux.intel.com --- .../bsp/intel-common/intel-common-standard.scc |3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc index 9ffebd5..6970a3f 100644 --- a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc @@ -38,6 +38,9 @@ include features/ixgbe/ixgbe.scc include features/iwlwifi/iwlwifi.scc include features/iwlegacy/iwlegacy.scc +# Various media device support, like webcams and capture cards +include features/media/media-all.scc + # Intel technology include features/amt/mei/mei.scc include features/power/intel.scc -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/2] meta: add cfg and scc files for valleyisland io features
On 3/19/14, 3:20, rebecca.swee.fun.ch...@intel.com rebecca.swee.fun.ch...@intel.com wrote: From: Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com Added Valley Island LPSS I/O device drivers configs. The feature looks good, but we do need to include a more complete description in the commit log. Specifics about what Valley Island is, for example, would be welcome. Which CPU/SoC in particular. Some of what you mentioned in your cover letter might better added to the two commit messages themselves. -- Darren Signed-off-by: Chang, Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com --- .../features/valleyisland-io/valleyisland-io.cfg | 30 .../features/valleyisland-io/valleyisland-io.scc |4 +++ 2 files changed, 34 insertions(+) create mode 100644 meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.cfg create mode 100644 meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.scc diff --git a/meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.cfg b/meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.cfg new file mode 100644 index 000..7aa630b --- /dev/null +++ b/meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.cfg @@ -0,0 +1,30 @@ +#GPIO Support +CONFIG_GPIOLIB=y +CONFIG_GPIO_SYSFS=y +CONFIG_GPIO_ACPI=y +CONFIG_GPIO_BAYTRAIL=y + +# I2C Support +CONFIG_I2C_DESIGNWARE_CORE=y +CONFIG_I2C_DESIGNWARE_PLATFORM=y + +# SPI Support +CONFIG_SPI_PXA2XX_DMA=y +CONFIG_SPI_PXA2XX=y + +# UART Support +CONFIG_SERIAL_8250_DW=y + +# DMA Support +CONFIG_DW_DMAC=y + +# PWM Support +CONFIG_PWM=y +CONFIG_PWM_LPSS=y + +# PINCTRL Support +CONFIG_PINCTRL=y +CONFIG_PINMUX=y +CONFIG_PINCONF=y +CONFIG_PINCTRL_BAYTRAIL=y +CONFIG_PINCTRL_BAYTRAIL_DEVICE=y diff --git a/meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.scc b/meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.scc new file mode 100644 index 000..90c2646 --- /dev/null +++ b/meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.scc @@ -0,0 +1,4 @@ +define KFEATURE_DESCRIPTION Enable Valley Island LPSS I/O Devices +define KFEATURE_COMPATIBILITY arch + +kconf hardware valleyisland-io.cfg -- 1.7.10.4 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 1/2] DRM: Restore synth_clock and clock_index fields in drm_display_mode
These two fields:
clock_index
synth_clock
Have been removed from the upstream DRM subsystem as they were unused.
EMGD is still making use of them, so add them back. This is really just
one final bandaid to keep the EMGD driver limping along through
3.10-LTSI.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Tested-by: Tom Zanussi tom.zanu...@linux.intel.com
---
include/drm/drm_crtc.h |4
1 file changed, 4 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b3cdbf6..bf5b46b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -156,6 +156,10 @@ struct drm_display_mode {
int height_mm;
/* Actual mode we give to hw */
+ /* EMGD still uses these two */
+ int clock_index; /* this is used for VESA/VGA mode number */
+ int synth_clock; /* perhaps this should be crtc_clock ? */
+ /* END EMGD */
int crtc_clock; /* in KHz */
int crtc_hdisplay;
int crtc_hblank_start;
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 2/2] emgd: Drop drm_fasync
drm_fasync has been removed with prejudice. These assignments appear
to be unused as well.
Signed-off-by: Darren Hart dvh...@linux.intel.com
Tested-by: Tom Zanussi tom.zanu...@linux.intel.com
---
drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c |1 -
.../emgd/pvr/services4/srvkm/env/linux/pvr_drm.c |1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c
b/drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c
index 11a53b0..fb1b730 100755
--- a/drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c
+++ b/drivers/gpu/drm/emgd/emgd/drm/emgd_drv.c
@@ -2475,7 +2475,6 @@ static struct pci_driver emgd_pci_driver =
EMGD_PCI_DRIVER;
.IOCTL = drm_ioctl, \
.mmap= emgd_mmap, \
.poll= drm_poll, \
-.fasync = drm_fasync, \
.read= drm_read, \
}
diff --git a/drivers/gpu/drm/emgd/pvr/services4/srvkm/env/linux/pvr_drm.c
b/drivers/gpu/drm/emgd/pvr/services4/srvkm/env/linux/pvr_drm.c
index f31f989..c49b890 100644
--- a/drivers/gpu/drm/emgd/pvr/services4/srvkm/env/linux/pvr_drm.c
+++ b/drivers/gpu/drm/emgd/pvr/services4/srvkm/env/linux/pvr_drm.c
@@ -259,7 +259,6 @@ static struct drm_driver sPVRDrmDriver =
.ioctl = drm_ioctl,
.mmap = PVRMMap,
.poll = drm_poll,
- .fasync = drm_fasync,
},
.pci_driver =
{
--
1.7.9.5
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] [yocto-docs][PATCH] kernel-dev: Updates Generating Configuration Files section
On 3/5/14, 18:20, João Henrique Ferreira de Freitas joa...@gmail.com
wrote:
Add a new step about how to use diffconfig task to create
kernel config fragments.
[YOCTO #3862]
Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com
Thank you for updating the documentation. Please Cc: the relevant parties
with patches to the list (the author for one, and a git log would reveal
Scott R. as the next obvious owner).
Scott, This is good stuff to add. My only thought is this is new
functionality, the old method is still valid - and necessary before 1.6.
What are your thoughts on dealing with this? Does the manual with 1.6 ONLY
apply to 1.6?
--
Darren
---
documentation/kernel-dev/kernel-dev-common.xml | 25
+
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/documentation/kernel-dev/kernel-dev-common.xml
b/documentation/kernel-dev/kernel-dev-common.xml
index a152f9f..de04a39 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -342,32 +342,25 @@
literallayout class='monospaced'
$ bitbake linux-yocto -c kernel_configme -f
/literallayout/para/listitem
-listitemparaCopy and rename the resulting
-filename.config/filename file (e.g.
-filenameconfig.orig/filename).
-/para/listitem
listitemparaRun the
filenamemenuconfig/filename
command:
literallayout class='monospaced'
$ bitbake linux-yocto -c menuconfig
/literallayout/para/listitem
-listitemparaPrepare a configuration fragment
based on
-the differences between the two files.
-/para/listitem
+listitemparaRun the
filenamediffconfig/filename
+command to prepare a configuration fragment.
+The result file
filenamefragment.cfg/filename will be placed in
+filename${/filenameulink
url='YOCTO_DOCS_REF_URL;#var-WORKDIR'filenameWORKDIR/filename/ulink
filename}/filename directory:
+literallayout class='monospaced'
+ $ bitbake linux-yocto -c diffconfig
+/literallayout/para/listitem
/orderedlist
/para
para
-Ultimately, the configuration fragment file needs to be a
+The filenamediffconfig/filename command creates a
file that is a
list of Linux kernel filenameCONFIG_/filename
assignments.
-It cannot be in filenamediff/filename format.
-Here is an example of a command that creates your
-configuration fragment file.
-Regardless of the exact command you use, plan on
reviewing
-the output as you can usually remove some of the
defaults:
-literallayout class='monospaced'
- $ diff -Nurp config.orig .config | sed -n s/^\+//p frag.cfg
-/literallayout
+
See the link
linkend='changing-the-configuration'Changing the Configuration/link
section for information on how to use the output as a
configuration fragment.
--
1.8.3.2
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-docs][PATCH] kernel-dev: Updates Generating Configuration Files section
On 3/10/14, 14:55, Rifenbark, Scott M scott.m.rifenb...@intel.com
wrote:
Yes - the manual for 1.6 is only for that release. I would have to take
separate steps to apply it to dora or Dylan branches.
The point there being that someone reading the current manual and working
on the 1.5 releases, would find these proposed changes will fail. The
method being removed here would work on all versions since this document
was created.
--
Darren
-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com]
Sent: Monday, March 10, 2014 4:52 PM
To: João Henrique Ferreira de Freitas; yocto@yoctoproject.org
Cc: Rifenbark, Scott M
Subject: Re: [yocto] [yocto-docs][PATCH] kernel-dev: Updates Generating
Configuration Files section
On 3/5/14, 18:20, João Henrique Ferreira de Freitas joa...@gmail.com
wrote:
Add a new step about how to use diffconfig task to create kernel config
fragments.
[YOCTO #3862]
Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com
Thank you for updating the documentation. Please Cc: the relevant parties
with patches to the list (the author for one, and a git log would reveal
Scott R.
as the next obvious owner).
Scott, This is good stuff to add. My only thought is this is new
functionality, the
old method is still valid - and necessary before 1.6.
What are your thoughts on dealing with this? Does the manual with 1.6
ONLY
apply to 1.6?
--
Darren
---
documentation/kernel-dev/kernel-dev-common.xml | 25
+
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/documentation/kernel-dev/kernel-dev-common.xml
b/documentation/kernel-dev/kernel-dev-common.xml
index a152f9f..de04a39 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -342,32 +342,25 @@
literallayout class='monospaced'
$ bitbake linux-yocto -c kernel_configme -f
/literallayout/para/listitem
-listitemparaCopy and rename the resulting
-filename.config/filename file (e.g.
-filenameconfig.orig/filename).
-/para/listitem
listitemparaRun the
filenamemenuconfig/filename
command:
literallayout class='monospaced'
$ bitbake linux-yocto -c menuconfig
/literallayout/para/listitem
-listitemparaPrepare a configuration fragment
based on
-the differences between the two files.
-/para/listitem
+listitemparaRun the
filenamediffconfig/filename
+command to prepare a configuration fragment.
+The result file
filenamefragment.cfg/filename will be placed in
+filename${/filenameulink
url='YOCTO_DOCS_REF_URL;#var-
WORKDIR'filenameWORKDIR/filename/ul
ink
filename}/filename directory:
+literallayout class='monospaced'
+ $ bitbake linux-yocto -c diffconfig
+/literallayout/para/listitem
/orderedlist
/para
para
-Ultimately, the configuration fragment file needs to
be a
+The filenamediffconfig/filename command creates a
file that is a
list of Linux kernel filenameCONFIG_/filename
assignments.
-It cannot be in filenamediff/filename format.
-Here is an example of a command that creates your
-configuration fragment file.
-Regardless of the exact command you use, plan on
reviewing
-the output as you can usually remove some of the
defaults:
-literallayout class='monospaced'
- $ diff -Nurp config.orig .config | sed -n s/^\+//p frag.cfg
-/literallayout
+
See the link
linkend='changing-the-configuration'Changing the Configuration/link
section for information on how to use the output as a
configuration fragment.
--
1.8.3.2
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-docs][PATCH] kernel-dev: Updates Generating Configuration Files section
On 3/10/14, 15:02, Rifenbark, Scott M scott.m.rifenb...@intel.com
wrote:
What you are saying is that the current method works for pre-1.6. And,
the proposed changes from the patch apply only to 1.6 and on. I would
apply the patch only to the latest version of the docs, which is the
tip of master and will be for 1.6.
OK. My hesitation/question here is about the expectation of the document.
If someone is working on the 1.5 release, should they ONLY use the 1.5
documentation? Does this mean you backport fixes from the current
development docs back to the previous releases of the docs?
--
Darren
Scott
-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com]
Sent: Monday, March 10, 2014 5:00 PM
To: Rifenbark, Scott M; João Henrique Ferreira de Freitas;
yocto@yoctoproject.org
Subject: Re: [yocto] [yocto-docs][PATCH] kernel-dev: Updates Generating
Configuration Files section
On 3/10/14, 14:55, Rifenbark, Scott M scott.m.rifenb...@intel.com
wrote:
Yes - the manual for 1.6 is only for that release. I would have to
take separate steps to apply it to dora or Dylan branches.
The point there being that someone reading the current manual and working
on the 1.5 releases, would find these proposed changes will fail. The
method
being removed here would work on all versions since this document was
created.
--
Darren
-Original Message-
From: Darren Hart [mailto:dvh...@linux.intel.com]
Sent: Monday, March 10, 2014 4:52 PM
To: João Henrique Ferreira de Freitas; yocto@yoctoproject.org
Cc: Rifenbark, Scott M
Subject: Re: [yocto] [yocto-docs][PATCH] kernel-dev: Updates
Generating Configuration Files section
On 3/5/14, 18:20, João Henrique Ferreira de Freitas
joa...@gmail.com
wrote:
Add a new step about how to use diffconfig task to create kernel
config fragments.
[YOCTO #3862]
Signed-off-by: João Henrique Ferreira de Freitas joa...@gmail.com
Thank you for updating the documentation. Please Cc: the relevant
parties with patches to the list (the author for one, and a git log
would reveal Scott R.
as the next obvious owner).
Scott, This is good stuff to add. My only thought is this is new
functionality, the old method is still valid - and necessary before
1.6.
What are your thoughts on dealing with this? Does the manual with 1.6
ONLY apply to 1.6?
--
Darren
---
documentation/kernel-dev/kernel-dev-common.xml | 25
+
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/documentation/kernel-dev/kernel-dev-common.xml
b/documentation/kernel-dev/kernel-dev-common.xml
index a152f9f..de04a39 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -342,32 +342,25 @@
literallayout class='monospaced'
$ bitbake linux-yocto -c kernel_configme -f
/literallayout/para/listitem
-listitemparaCopy and rename the resulting
-filename.config/filename file (e.g.
-filenameconfig.orig/filename).
-/para/listitem
listitemparaRun the
filenamemenuconfig/filename
command:
literallayout class='monospaced'
$ bitbake linux-yocto -c menuconfig
/literallayout/para/listitem
-listitemparaPrepare a configuration fragment
based on
-the differences between the two files.
-/para/listitem
+listitemparaRun the
filenamediffconfig/filename
+command to prepare a configuration fragment.
+The result file
filenamefragment.cfg/filename will be placed in
+filename${/filenameulink
url='YOCTO_DOCS_REF_URL;#var-
WORKDIR'filenameWORKDIR/filename/ul
ink
filename}/filename directory:
+literallayout class='monospaced'
+ $ bitbake linux-yocto -c diffconfig
+/literallayout/para/listitem
/orderedlist
/para
para
-Ultimately, the configuration fragment file needs to
be a
+The filenamediffconfig/filename command creates
+ a
file that is a
list of Linux kernel filenameCONFIG_/filename
assignments.
-It cannot be in filenamediff/filename format.
-Here is an example of a command that creates your
-configuration fragment file.
-Regardless of the exact command you use, plan on
reviewing
-the output as you can usually remove some of the
defaults:
-literallayout class='monospaced'
- $ diff -Nurp config.orig .config | sed -n s/^\+//p frag.cfg
-/literallayout
+
See the link
linkend='changing-the-configuration'Changing the
Configuration/link
section for information
Re: [linux-yocto] [PATCH 1/1] meta: update mohonpeak.cfg for SATA, SMBus, LPC, WDT, crypto highmem64g
On 3/5/14, 8:38, boon.leong@intel.com boon.leong@intel.com wrote: From: Ong Boon Leong boon.leong@intel.com Update mohonpeak.cfg to enable SMBus iSMT driver, crypto framework, LPC, watchdog-timer 4G memory for 32-bit build. The update is possible due to recent merge of LTS/LTSI commits available since 3.4.74. Remove CONFIG_PATA_SCH because pata_sch.c only supports Intel SCH IDE PCI ID(0x811A) and not Rangeley/Avoton IDE PCI ID(0x1C02). To enable SATA AHCI, CONFIG_SATA_AHCI is turned now because of upstream commit-ID 29e674dd5c8e781589f09c3ee139c80f6da274e4 has been merged into linux-yocto. On Mohonpeak platform, there are only SATA ports and not PATA. Signed-off-by: Ong Boon Leong boon.leong@intel.com Acked-by: Darren Hart dvh...@linux.intel.com -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] meta: update mohonpeak.cfg for SATA, SMBus, LPC, WDT, crypto highmem64g
On 3/4/14, 15:20, boon.leong@intel.com boon.leong@intel.com wrote: From: Ong Boon Leong boon.leong@intel.com With Linux-yocto, it's good practice to include the version in the subject: [PATCH 1/1][3.4] meta: ... Update mohonpeak.cfg to enable SMBus iSMT driver, crypto framework, LPC, watchdog-timer 4G memory for 32-bit build. The update is possible due to recent merge of LTS/LTSI commits available since 3.4.74. Signed-off-by: Ong Boon Leong boon.leong@intel.com --- meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak.cfg | 23 ++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak.cfg b/meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak.cfg index 2111aed..d0d1d92 100644 --- a/meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak.cfg +++ b/meta/cfg/kernel-cache/bsp/mohonpeak/mohonpeak.cfg @@ -1,13 +1,30 @@ -# Basic hardware support for the box - network, PCI, sound +# Basic hardware support for the box CONFIG_ATA=y CONFIG_ATA_GENERIC=y CONFIG_ATA_SFF=y +CONFIG_SATA_AHCI=y CONFIG_PCI=y -CONFIG_PATA_SCH=y Were the SATA and PATA changes intentional? They aren't mentioned in the commit message and don't seem likely to have been impacted by the general update. If so, please not it in the message. General updates are OK if they are documented as such, but this one is described fairly specifically, so this appears inadvertent. CONFIG_PCIEPORTBUS=y CONFIG_CHR_DEV_SG=y -CONFIG_I2C=y CONFIG_PM=y CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_INPUT=y +# Enable 4G memory on 32-bit system +CONFIG_HIGHMEM64G=y +CONFIG_X86_PAE=y +# Linux Crypto Framework +CONFIG_CRYPTO_CTR=y +CONFIG_CRYPTO_CCM=m +CONFIG_CRYPTO_GCM=m +CONFIG_CRYPTO_XCBC=m +CONFIG_CRYPTO_VMAC=m +CONFIG_CRYPTO_CTS=m +# SMBus ISMT Driver for Mohon-peak +CONFIG_I2C=y +CONFIG_I2C_I801=m +CONFIG_I2C_ISMT=m +CONFIG_I2C_CHARDEV=y +# LPC driver Watchdog Timer +CONFIG_LPC_ICH=m +CONFIG_ITCO_WDT=y -- 1.7.10.4 Otherwise looks good. -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 1/4] meta: input: add CONFIG_INPUT dependency
CONFIG_INPUT_EVDEV depends on CONFIG_INPUT, the input.cfg should contain both. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/features/input/input.cfg | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/cfg/kernel-cache/features/input/input.cfg b/meta/cfg/kernel-cache/features/input/input.cfg index b738491..55e65d1 100644 --- a/meta/cfg/kernel-cache/features/input/input.cfg +++ b/meta/cfg/kernel-cache/features/input/input.cfg @@ -1 +1,2 @@ +CONFIG_INPUT=y CONFIG_INPUT_EVDEV=y -- 1.8.5.3 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 2/4] baytrail: Add feature/soc/baytrail
Add support for the various devices on the BayTrail SoCs, including PWM, SPI, I2C, ASOC, UARTs, DMA, LPSS, etc. Signed-off-by: Darren Hart dvh...@linux.intel.com --- .../features/soc/baytrail/baytrail.cfg | 53 ++ .../features/soc/baytrail/baytrail.scc | 13 ++ 2 files changed, 66 insertions(+) create mode 100644 meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg create mode 100644 meta/cfg/kernel-cache/features/soc/baytrail/baytrail.scc diff --git a/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg b/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg new file mode 100644 index 000..c437b09 --- /dev/null +++ b/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.cfg @@ -0,0 +1,53 @@ +CONFIG_PCI=y + +CONFIG_SOUND=y +CONFIG_SND=y +CONFIG_SND_HDA_INTEL=y +CONFIG_SND_SOC=m + +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_BACKLIGHT_CLASS_DEVICE=y + +# SATA Support +CONFIG_ATA=y +CONFIG_SATA_AHCI=y +CONFIG_CHR_DEV_SG=y + +CONFIG_X86_INTEL_LPSS=y + +# Pinctrl and GPIO Support +CONFIG_PINMUX=y +CONFIG_PINCONF=y +CONFIG_PINCTRL_BAYTRAIL=y +CONFIG_GPIOLIB=y +CONFIG_GPIO_SYSFS=y + +CONFIG_SERIAL_8250_DW=y + +# MMC / SDHCI Support +CONFIG_MMC=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_PCI=y +CONFIG_MMC_SDHCI_ACPI=y + +CONFIG_I2C_DESIGNWARE_CORE=m +CONFIG_I2C_DESIGNWARE_PLATFORM=m + +# SMBus Support +CONFIG_I2C_I801=m + +CONFIG_SPI_PXA2XX=m + +CONFIG_DW_DMAC=m +CONFIG_DW_PCI=m + +# PWM Support +CONFIG_PWM=y + +# USB Device Support +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GADGET=y +CONFIG_USB_GADGET=y +CONFIG_USB_LIBCOMPOSITE=m +CONFIG_USB_MASS_STORAGE=m +CONFIG_NOP_USB_XCEIV=y diff --git a/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.scc b/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.scc new file mode 100644 index 000..c593896 --- /dev/null +++ b/meta/cfg/kernel-cache/features/soc/baytrail/baytrail.scc @@ -0,0 +1,13 @@ +# baytrail.scc +# +# Features and devices found on the Bay Trail SoCs +# + +include cfg/8250.scc +include features/i915/i915.scc +include features/power/intel.scc + +include features/usb/xhci-hcd.scc +include features/usb/ehci-hcd.scc + +kconf hardware baytrail.cfg -- 1.8.5.3 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 4/4] intel-common: Remove GMA500 support
The current GMA500 support currently requires custom configuration which is not appropriate for an intel-common BSP. Remove it for the time being so the config-less alternatives can work out of the box. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc index 19d6521..9ffebd5 100644 --- a/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc +++ b/meta/cfg/kernel-cache/bsp/intel-common/intel-common-standard.scc @@ -29,7 +29,6 @@ include features/eg20t/eg20t.scc # Graphics include cfg/vesafb.scc include features/i915/i915.scc -include features/drm-gma500/drm-gma500.scc # Networking include features/intel-e1/intel-e100.scc -- 1.8.5.3 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] meta: update mohonpeak.cfg for SATA, SMBus, LPC, WDT, crypto highmem64g
On 3/4/14, 18:40, Ong, Boon Leong boon.leong@intel.com wrote: -Original Message- From: Darren Hart [mailto:dvh...@linux.intel.com] Sent: Wednesday, March 05, 2014 5:10 AM To: Ong, Boon Leong; linux-yocto@yoctoproject.org Subject: Re: [linux-yocto] [PATCH 1/1] meta: update mohonpeak.cfg for SATA, SMBus, LPC, WDT, crypto highmem64g On 3/4/14, 15:20, boon.leong@intel.com boon.leong@intel.com wrote: From: Ong Boon Leong boon.leong@intel.com With Linux-yocto, it's good practice to include the version in the subject: [PATCH 1/1][3.4] meta: ... I understand that on the cover-letter, we practice that to channel the commits correctly. Adding [3.4] tag in the subject of patch-set is also encouraged? If yes, we need to add this manually after create-pull-request script since we don't want to have commit title that have [3.4] tag. Is my understanding correct? Just the cover letter, correct. Yes, I add this manually to the -cover-letter.patch generated by create-pull-request. Not too bad since we have to edit it anyway. -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 1/1] meta: update mohonpeak.cfg for SATA, SMBus, LPC, WDT, crypto highmem64g
On 3/4/14, 20:05, Ong, Boon Leong boon.leong@intel.com wrote: PATA_SCH enable pata_sch.c only supports PCI_DEVICE_ID_INTEL_SCH_IDE (0x811A) For Mohonpeak, i.e. Rangeley Avoton, the PCI ID is 1C02. So, I am cleaning-up. Enable SATA_AHCI which include supports for Rangeley|Avoton since upstream 29e674dd5c8e781589f09c3ee139c80f6da274e4 is sufficient. On actual board, there is only SATA port and not PATA. I will update the above info into commit message for details. The cleanup is much appreciated. I was wondering about that in this and other BSPs. -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 03/18] arch/powerpc: Checking in correct USB entries to ACP3421 DTS
On 2/26/14, 13:40, Charlie Paul cpaul.windri...@gmail.com wrote:
From: SangeethaRao sangeetha@lsi.com
These changes were made to fix the failure in the USB.
What is the failure? How does it manifest?
This change only affects the ACP34321 DTS
Signed-off-by: SangeethaRao sangeetha@lsi.com
---
arch/powerpc/boot/dts/acp342x.dts | 33
+
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/boot/dts/acp342x.dts
b/arch/powerpc/boot/dts/acp342x.dts
index b851788..f5cf3a6 100644
--- a/arch/powerpc/boot/dts/acp342x.dts
+++ b/arch/powerpc/boot/dts/acp342x.dts
@@ -90,64 +90,65 @@
clock-frequency = 0; // Filled in by zImage
UART0: serial@00404000 {
device_type = serial;
-compatible = acp-uart0;
+compatible = lsi,acp-uart0;
So you are adding lsi as a driver that can consume this DT. That should
be in the commit message for sure.
USB0: usb@004a4000 {
device_type = usb;
-compatible = acp-usb;
-enabled = 0;
-reg = 0x004a4000 0x0002;
+compatible = lsi,acp-usb;
+enabled = 1;
+reg = 0x20 0x004A 0x0 002,
+ 0x20 0x0040C000 0x0 0001000;
Does this impact the existing use cases for this dts? acp-usb for example?
--
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [PATCH 00/18] Re-submit upgrades to the lsi 3.10 axxia
On 2/24/14, 10:21, Paul, Charlie charlie.p...@windriver.com wrote: Darren: Ultimately we need to get these patches up to the LTSI. It would make things easier, right now we are on a strict time schedule and we need to get the standard/axxia/base branch corrected with proper checkpatching and the latest changes. We have a few more patches to submit and then we can concentrate on getting in onto LTSI. The reason I asked was first to verify which branch these were targeted for and whether it was appropriate. If these patches are not coming from mainline, then standard/axxia* is the right place for them. As to LTSI - please put your effort into getting your patches into mainline first, and then backport to LTSI if needed. Otherwise you will constantly be forward porting to a new LTSI, it's wasted effort. -- Darren Hart Yocto Project - Linux Kernel Intel Open Source Technology Center ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
