Re: [yocto] [meta-intel] [PATCH] systemd-boot: fix bbappend file to suit latest version

2018-03-05 Thread Cal Sullivan 
Thanks for the patch. I assume this is needed when OE-core merges the 
update to v236?


Thanks,
Cal

On 03/04/2018 06:03 PM, Chen Qi wrote:

Fix the bbappend file to suit the latest systemd version.

As systemd has now dropped autotools support, using ninja
instead of make in do_compile.

Signed-off-by: Chen Qi 
---
  recipes-bsp/systemd-boot/systemd-boot_%.bbappend | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/systemd-boot/systemd-boot_%.bbappend 
b/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
index 9e6cc16..46dd8a4 100644
--- a/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
+++ b/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
@@ -7,11 +7,11 @@ SRC_URI_append_intel-x86-common = " \
  PACKAGE_ARCH_intel-x86-common = "${INTEL_COMMON_PACKAGE_ARCH}"
  
  do_compile_append_intel-x86-common() {

-   oe_runmake linux${SYSTEMD_BOOT_EFI_ARCH}.efi.stub
+   ninja src/boot/efi/linux${SYSTEMD_BOOT_EFI_ARCH}.efi.stub
  }
  
  do_deploy_append_intel-x86-common() {

-   install ${B}/linux*.efi.stub ${DEPLOYDIR}
+   install ${B}/src/boot/efi/linux*.efi.stub ${DEPLOYDIR}
  }
  
  # includes rmc-boot.inc if rmc-boot is the EFI_PROVIDER


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [kernel-cache][yocto-4.12][V2][PATCH 1/1] features/i915/i915.cfg: compile i915 as a module

2017-12-08 Thread Cal Sullivan 

Could this be merged into 4.9 as well?

Thanks,
Cal

On 12/07/2017 02:36 AM, Bruce Ashfield wrote:

On 12/06/2017 11:27 PM, Liwei Song wrote:

Set i915 as a module to trigger the firmware load
at the same time the module is loaded.

This can avoid a timing problem between the driver starting
and it triggering a firmware load, after compile it as module
i915 driver will start after the rootfs is ready, then the
firmware store in /lib/firmware/ can be load successful by
i915 driver.



merged.

Bruce


Signed-off-by: Liwei Song 
---
  features/i915/i915.cfg | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/features/i915/i915.cfg b/features/i915/i915.cfg
index 6dcc60f2dfc7..60cb963e014b 100644
--- a/features/i915/i915.cfg
+++ b/features/i915/i915.cfg
@@ -8,6 +8,6 @@ CONFIG_AGP=y
  CONFIG_AGP_INTEL=y
  CONFIG_DRM=y
  CONFIG_DRM_KMS_HELPER=y
-CONFIG_DRM_I915=y
+CONFIG_DRM_I915=m
  CONFIG_DRM_KMS_FB_HELPER=y
  CONFIG_DRM_I915_ALPHA_SUPPORT=y





--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel-cache][PATCH V2] intel-common-drivers: moved x2apic

2017-10-09 Thread Cal Sullivan 

Looks good to me.

Thanks,
Cal

On 10/07/2017 12:27 AM, Syed Mohamad Fauzi, Syed Johan Arif wrote:

intel-common-drivers: moved the x2apic kernel feature to intel-corei7-64.scc,
because it caused configcheck warnings for intel-core2-32

Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif 

---
  bsp/intel-common/intel-common-drivers.scc | 1 -
  bsp/intel-common/intel-corei7-64.scc  | 3 +++
  2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/bsp/intel-common/intel-common-drivers.scc 
b/bsp/intel-common/intel-common-drivers.scc
index 6b0de8d..bd56165 100644
--- a/bsp/intel-common/intel-common-drivers.scc
+++ b/bsp/intel-common/intel-common-drivers.scc
@@ -76,7 +76,6 @@ include cfg/dmaengine.scc
  include features/uio/uio.scc
  include cfg/efi-ext.scc
  include features/input/keyboard-gpio.scc
-include features/x2apic/x2apic.scc
  
  # default policy for standard kernels

  include cfg/usb-mass-storage.scc
diff --git a/bsp/intel-common/intel-corei7-64.scc 
b/bsp/intel-common/intel-corei7-64.scc
index ad6099e..4d5a8a9 100644
--- a/bsp/intel-common/intel-corei7-64.scc
+++ b/bsp/intel-common/intel-corei7-64.scc
@@ -23,6 +23,9 @@ include features/dca/dca.scc
  # INTEL_TELEMETRY is currently 64 bit only
  include features/telemetry/intel-telemetry.scc
  
+# x2apic required by the Denverton platform to boot

+include features/x2apic/x2apic.scc
+
  # This line comes last as it has the final word on
  # CONFIG values.
  kconf hardware intel-corei7-64.cfg


--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel-cache][PATCH] intel-common-drivers: moved x2apic

2017-10-06 Thread Cal Sullivan 



On 10/06/2017 12:30 AM, Syed Mohamad Fauzi, Syed Johan Arif wrote:

intel-common-drivers: moved the x2apic kernel feature to intel-corei7-64.scc,
because it caused configcheck warnings for intel-core2-32

Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif 

---
  bsp/intel-common/intel-common-drivers.scc | 1 -
  bsp/intel-common/intel-corei7-64.scc  | 3 +++
  2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/bsp/intel-common/intel-common-drivers.scc 
b/bsp/intel-common/intel-common-drivers.scc
index 6b0de8d..bd56165 100644
--- a/bsp/intel-common/intel-common-drivers.scc
+++ b/bsp/intel-common/intel-common-drivers.scc
@@ -76,7 +76,6 @@ include cfg/dmaengine.scc
  include features/uio/uio.scc
  include cfg/efi-ext.scc
  include features/input/keyboard-gpio.scc
-include features/x2apic/x2apic.scc
  
  # default policy for standard kernels

  include cfg/usb-mass-storage.scc
diff --git a/bsp/intel-common/intel-corei7-64.scc 
b/bsp/intel-common/intel-corei7-64.scc
index ad6099e..ee37226 100644
--- a/bsp/intel-common/intel-corei7-64.scc
+++ b/bsp/intel-common/intel-corei7-64.scc
@@ -26,3 +26,6 @@ include features/telemetry/intel-telemetry.scc
  # This line comes last as it has the final word on
  # CONFIG values.
  kconf hardware intel-corei7-64.cfg
+
+# x2apic required by the Denverton platform to boot
+include features/x2apic/x2apic.scc

This should probably go above the line that says "This line comes last".

Thanks,
Cal
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] problem adding first layer to yocto

2017-10-02 Thread Cal Sullivan 
Your layer appears to only be adding a new recipe. It won't be built 
unless you tell it to be built, or you build something that depends on 
it, or you add it to the image you're building.

So your options are:
bitbake example
add IMAGE_INSTALL_append = " example" to your local.conf
have another recipe that requires example, and build or add that to your 
image.


---
Cal

On 10/02/2017 04:05 PM, Mark Hieber wrote:

sorry, fat-fingered send

Anyway, I created this layer. I had it create a default recipe, I 
looked at all the files, they all seem to be correct. I then ran


source oe-init-build-env

and then edited build/conf/bblayers.conf, it has

BBLAYERS ?= " \

  /yocto/poky/meta \

  /yocto/poky/meta-poky \

  /yocto/poky/meta-yocto-bsp \

  /yocto/poky/meta-mylayer \

  "


I then ran "bitbake core-image-minimal" and then ran "runqemu qemux86 
nographic"
Inside qemu, I did a 'find / -name "hello*"' and got nothing. Also, 
when I ran bitbake, it said


#/yocto/poky/build$ bitbake core-image-minimal
Loading cache: 100% 
|#| 
Time: 0:00:00

Loaded 1302 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "i586-poky-linux"
MACHINE   = "qemux86"
DISTRO= "poky"
DISTRO_VERSION= "2.3.2"
TUNE_FEATURES = "m32 i586"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp
meta-mylayer  = "pyro:717303e6fbcbbe181ad9645d762eb5a85d934523"
Initialising tasks: 100% 
|| 
Time: 0:00:04

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 2426 tasks of which 2426 didn't need to 
be rerun and all succeeded.


It seems to me that yocto is NOT picking up my new layer. I am sure 
that I have missed something, but I read the docs 3 times, and can't 
find anything I missed.


Thanks for your help,

Mark

On Mon, Oct 2, 2017 at 3:58 PM, Mark Hieber > wrote:

>
> Hi, I am just starting out with yocto, and I have an issue. I 
followed the steps in 
http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-manual.html#creating-a-general-layer-using-the-yocto-layer-script,

> create meta-mylayer (in the /yocto/poky directory),
>
> #/yocto/poky tree meta-mylayer/
>
> meta-mylayer/
>
> ├── conf
>
> │   └── layer.conf
>
> ├── COPYING.MIT
>
> ├── README
>
> └── recipes-example
>
> └── example
>
> ├── example-0.1
>
> │   ├── example.patch
>
> │   └── helloworld.c
>
> └── example_0.1.bb 
>




-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [kernel-cache][PATCH] intel-common-drivers: adding x2apic

2017-09-29 Thread Cal Sullivan 

This causes new configcheck warnings for intel-core2-32:

WARNING: linux-intel-4.9.47+gitAUTOINC+e59e19269c_39b77977c6-r0 
do_kernel_configcheck: [kernel config]: specified values did not make it 
into the kernel's final configuration:


-- CONFIG_IRQ_REMAP -
Config: CONFIG_IRQ_REMAP
From: 
/home/clsulliv/yocto/poky/build/tmp/work-shared/intel-core2-32/kernel-source/.kernel-meta/configs/standard/intel/features/x2apic/x2apic.cfg

Requested value:  CONFIG_IRQ_REMAP=y
Actual value:

Config 'IRQ_REMAP' has the following conditionals:
  X86_64 && X86_IO_APIC && PCI_MSI && ACPI (value: "n")
Dependency values are:
  X86_64 [n] ACPI [y] X86_IO_APIC [y] PCI_MSI [y]

-- CONFIG_X86_X2APIC -
Config: CONFIG_X86_X2APIC
From: 
/home/clsulliv/yocto/poky/build/tmp/work-shared/intel-core2-32/kernel-source/.kernel-meta/configs/standard/intel/features/x2apic/x2apic.cfg

Requested value:  CONFIG_X86_X2APIC=y
Actual value:

Config 'X86_X2APIC' has the following conditionals:
  X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST) (value: "n")
Dependency values are:
  X86_LOCAL_APIC [y] HYPERVISOR_GUEST [n] X86_64 [n] IRQ_REMAP [n]



Seeing that it depends on X86_64, perhaps it should be corei7 specific?

---
Cal

On 09/21/2017 04:28 AM, Syed Mohamad Fauzi, Syed Johan Arif wrote:

Included features/x2apic/x2apic.scc to enable x2apic as a built-in feature.

Signed-off-by: Syed Mohamad Fauzi, Syed Johan Arif 

---
  bsp/intel-common/intel-common-drivers.scc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/bsp/intel-common/intel-common-drivers.scc 
b/bsp/intel-common/intel-common-drivers.scc
index bd56165..6b0de8d 100644
--- a/bsp/intel-common/intel-common-drivers.scc
+++ b/bsp/intel-common/intel-common-drivers.scc
@@ -76,6 +76,7 @@ include cfg/dmaengine.scc
  include features/uio/uio.scc
  include cfg/efi-ext.scc
  include features/input/keyboard-gpio.scc
+include features/x2apic/x2apic.scc
  
  # default policy for standard kernels

  include cfg/usb-mass-storage.scc


--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of __list_lru_init_key

2017-09-28 Thread Cal Sullivan 



On 09/28/2017 07:53 AM, Paul Gortmaker wrote:

[[linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of 
__list_lru_init_key] On 22/09/2017 (Fri 15:48) California Sullivan wrote:


__list_lru_init_key does not exist. We're looking for __list_lru_init as
shown in the patch "26690f5 mm: workingset: fix premature shadow node

I don't have that commit ID in mainline.  I see this:

That commit ID won't be in mainline - it was a backport patch to 4.8.


commit 0cefabdaf757a6455d75f00cb76874e62703ed18
Author: Johannes Weiner 
Date:   Fri Mar 31 15:11:52 2017 -0700

 mm: workingset: fix premature shadow node shrinking with cgroups

Did you perhaps rebase or similar?  Since the patch below is identical
to the commit above, it is more appropriate to preserve the original
commit log and authorship, as per how nearly all stable backports are
handled.

The patch isn't  quite identical: __list_lru_init_key vs list_lru_init_key.
It somehow got mangled in the merge commit 7f56c636.

---
Cal



P.
--


shrinking with cgroups".

Signed-off-by: California Sullivan 
---

This is for the standard/preempt-rt/base branch. Standard/base is OK.

  mm/workingset.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/workingset.c b/mm/workingset.c
index 1856fdb..5e953eb 100644
--- a/mm/workingset.c
+++ b/mm/workingset.c
@@ -493,7 +493,7 @@ static int __init workingset_init(void)
pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
   timestamp_bits, max_order, bucket_order);
  
-	ret = __list_lru_init_key(&__workingset_shadow_nodes, true, _nodes_key);

+   ret = __list_lru_init(&__workingset_shadow_nodes, true, 
_nodes_key);
if (ret)
goto err;
ret = register_shrinker(_shadow_shrinker);
--
2.9.5



--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [yocto-kernel-cache][PATCH] common-pc-wifi.cfg: Add CONFIG_BRCMFMAC_PCIE

2017-09-15 Thread Cal Sullivan 



On 09/15/2017 08:04 AM, Bruce Ashfield wrote:

On 09/14/2017 04:51 PM, California Sullivan wrote:

This is needed for some Broadcomm wifi drivers.

Signed-off-by: California Sullivan 
---
This is for yocto-4.9 and newer.



I got a reject when applying this to the tip of the yocto-4.9
branch.

Can you double check your top commit for that branch ?

Oops, I was working off of 4.4 still. I will send a v2.

---
Cal



Bruce


  bsp/common-pc/common-pc-wifi.cfg | 1 +
  1 file changed, 1 insertion(+)

diff --git a/bsp/common-pc/common-pc-wifi.cfg 
b/bsp/common-pc/common-pc-wifi.cfg

index 272f912..c2f7d38 100644
--- a/bsp/common-pc/common-pc-wifi.cfg
+++ b/bsp/common-pc/common-pc-wifi.cfg
@@ -20,6 +20,7 @@ CONFIG_BRCMUTIL=m
  CONFIG_BRCMSMAC=m
  CONFIG_BRCMFMAC=m
  CONFIG_BRCMFMAC_USB=y
+CONFIG_BRCMFMAC_PCIE=y
CONFIG_WEXT_CORE=y
  CONFIG_WEXT_PROC=y





--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto-4.4][PATCH] drivers/usb/dwc3/gadget.c: fix merge

2017-09-12 Thread Cal Sullivan 

Thanks for the super quick turnaround time!

And hey, I appreciate the effort you put in.
Thanks to you its very rare that we see issues on our end, and I know 
these branches aren't an ideal situation.


---
Cal

On 09/12/2017 04:42 PM, Bruce Ashfield wrote:

On 2017-09-12 7:38 PM, California Sullivan wrote:

Commit "c813008 usb: dwc3: replace %p with %pK" did not apply correctly
due a previous backport. In the confusion, some error checking was
added back which included a goto whose target didn't exist, causing a
compilation failure.



Well crap. I even looked at this during the merge and thought it
was ok.

I was just doing -stable updates to 4.4, so this is merged and pushed.

Bruce



--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] [meta-alexa-demo][PATCH 1/3] Moved meta-alexa-demo top level to meta-alexapi

2017-08-08 Thread Cal Sullivan 
Sorry for slow response. I see your signoff on the original patch, do I 
have permission to add it back to these?


Thanks,
Cal

On 08/07/2017 04:17 PM, Amanda Brindle wrote:

From: Matthew Hansen 

---
  COPYING.MIT => meta-alexapi/COPYING.MIT   | 0
  LICENSE => meta-alexapi/LICENSE   | 0
  README => meta-alexapi/README | 0
  {conf => meta-alexapi/conf}/layer.conf| 0
  .../recipes-connectivity}/libmtp/libmtp_1.1.5.bbappend| 0
  .../alexapi/alexapi/0001-common.sh-Get-rid-of-grep-perl-regex.patch   | 0
  .../0002-setup.sh-Change-some-things-that-don-t-make-sense-fo.patch   | 0
  .../0003-src.config.template.yaml-Set-default-input-to-defaul.patch   | 0
  {recipes-core => meta-alexapi/recipes-core}/alexapi/alexapi_git.bb| 0
  .../recipes-devtools}/python/python-cheroot_5.1.0.bb  | 0
  .../recipes-devtools}/python/python-cherrypy_10.1.1.bb| 0
  .../recipes-devtools}/python/python-memcached_1.58.bb | 0
  .../recipes-devtools}/python/python-pocketsphinx_0.1.3.bb | 0
  .../recipes-devtools}/python/python-portend_1.8.bb| 0
  .../recipes-devtools}/python/python-py-getch_1.0.1.bb | 0
  .../recipes-devtools}/python/python-tempora_1.6.1.bb  | 0
  .../recipes-devtools}/python/python-vlc_1.1.2.bb  | 0
  .../recipes-devtools}/python/python-wave_0.0.2.bb | 0
  .../recipes-devtools}/python/python-webrtcvad_2.0.10.bb   | 0
  .../recipes-multimedia}/vlc/vlc_2.2.2.bbappend| 0
  20 files changed, 0 insertions(+), 0 deletions(-)
  rename COPYING.MIT => meta-alexapi/COPYING.MIT (100%)
  rename LICENSE => meta-alexapi/LICENSE (100%)
  rename README => meta-alexapi/README (100%)
  rename {conf => meta-alexapi/conf}/layer.conf (100%)
  rename {recipes-connectivity => 
meta-alexapi/recipes-connectivity}/libmtp/libmtp_1.1.5.bbappend (100%)
  rename {recipes-core => 
meta-alexapi/recipes-core}/alexapi/alexapi/0001-common.sh-Get-rid-of-grep-perl-regex.patch
 (100%)
  rename {recipes-core => 
meta-alexapi/recipes-core}/alexapi/alexapi/0002-setup.sh-Change-some-things-that-don-t-make-sense-fo.patch
 (100%)
  rename {recipes-core => 
meta-alexapi/recipes-core}/alexapi/alexapi/0003-src.config.template.yaml-Set-default-input-to-defaul.patch
 (100%)
  rename {recipes-core => meta-alexapi/recipes-core}/alexapi/alexapi_git.bb 
(100%)
  rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-cheroot_5.1.0.bb (100%)
  rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-cherrypy_10.1.1.bb (100%)
  rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-memcached_1.58.bb (100%)
  rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-pocketsphinx_0.1.3.bb (100%)
  rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-portend_1.8.bb (100%)
  rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-py-getch_1.0.1.bb (100%)
  rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-tempora_1.6.1.bb (100%)
  rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-vlc_1.1.2.bb (100%)
  rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-wave_0.0.2.bb (100%)
  rename {recipes-devtools => 
meta-alexapi/recipes-devtools}/python/python-webrtcvad_2.0.10.bb (100%)
  rename {recipes-multimedia => 
meta-alexapi/recipes-multimedia}/vlc/vlc_2.2.2.bbappend (100%)



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-alexa-demo][PATCH] Fix setuptools_scm build error for several python packages

2017-07-11 Thread Cal Sullivan 
I actually wasn't able to reproduce the issue.I added alexapi to my 
IMAGE_INSTALL and ran a build, see below:


[clsulliv@clsulliv build]$ bitbake core-image-minimal
Parsing recipes: 100% 
|| 
Time: 0:00:08
Parsing of 1825 .bb files complete (0 cached, 1825 parsed). 2581 
targets, 143 skipped, 0 masked, 0 errors.

NOTE: There are 4 recipes to be removed from sysroot x86_64, removing...
NOTE: There are 1 recipes to be removed from sysroot corei7-64, removing...
NOTE: There are 1 recipes to be removed from sysroot intel-corei7-64, 
removing...

NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "x86_64-poky-linux"
MACHINE   = "intel-corei7-64"
DISTRO= "poky"
DISTRO_VERSION= "2.3"
TUNE_FEATURES = "m64 corei7"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp= "pyro:7c27bf2dd85ee77d643d975add4256e957652a5c"
meta-intel= "pyro:16aea09d224f3ed2021623d17c3e807f4b8ff18d"
meta-oe   = "pyro:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"
meta-alexa= "master:1b5618a1af6ea79f51aa89480b857648584c581f"
meta-python
meta-multimedia   = "pyro:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"

Initialising tasks: 100% 
|#| 
Time: 0:00:11
Checking sstate mirror object availability: 100% 
|#| 
Time: 0:00:00

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 5678 tasks of which 5653 didn't need to 
be rerun and all succeeded.


I'm curious as to what's different for you guys.

---
Cal


On 07/11/2017 02:25 PM, Tim Orling wrote:

python-setuptools-scm-native is needed at build time for:
   python-cheroot
   python-cherrypy
   python-portend
   python-tempora

Signed-off-by: Tim Orling 
---
  recipes-devtools/python/python-cheroot_5.1.0.bb   | 2 +-
  recipes-devtools/python/python-cherrypy_10.1.1.bb | 2 +-
  recipes-devtools/python/python-portend_1.8.bb | 2 +-
  recipes-devtools/python/python-tempora_1.6.1.bb   | 2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/recipes-devtools/python/python-cheroot_5.1.0.bb 
b/recipes-devtools/python/python-cheroot_5.1.0.bb
index 2da3115..e8795d1 100644
--- a/recipes-devtools/python/python-cheroot_5.1.0.bb
+++ b/recipes-devtools/python/python-cheroot_5.1.0.bb
@@ -14,7 +14,7 @@ FILES_${PN} += "${datadir}/cheroot"
  
  BBCLASSEXTEND = "nativesdk"
  
-DEPENDS += " swig-native"

+DEPENDS += " swig-native python-setuptools-scm-native"
  
  RDEPENDS_${PN} += " \

  python-pip \
diff --git a/recipes-devtools/python/python-cherrypy_10.1.1.bb 
b/recipes-devtools/python/python-cherrypy_10.1.1.bb
index 2a75fd8..6a9086a 100644
--- a/recipes-devtools/python/python-cherrypy_10.1.1.bb
+++ b/recipes-devtools/python/python-cherrypy_10.1.1.bb
@@ -14,7 +14,7 @@ FILES_${PN} += "${datadir}/CherryPy"
  
  BBCLASSEXTEND = "nativesdk"
  
-DEPENDS += " swig-native"

+DEPENDS += " swig-native python-setuptools-scm-native"
  
  RDEPENDS_${PN} += " \

  python-pip \
diff --git a/recipes-devtools/python/python-portend_1.8.bb 
b/recipes-devtools/python/python-portend_1.8.bb
index f50de7c..926d238 100644
--- a/recipes-devtools/python/python-portend_1.8.bb
+++ b/recipes-devtools/python/python-portend_1.8.bb
@@ -14,7 +14,7 @@ FILES_${PN} += "${datadir}/portend"
  
  BBCLASSEXTEND = "nativesdk"
  
-DEPENDS += " swig-native"

+DEPENDS += " swig-native python-setuptools-scm-native"
  
  RDEPENDS_${PN} += " \

  python-pip \
diff --git a/recipes-devtools/python/python-tempora_1.6.1.bb 
b/recipes-devtools/python/python-tempora_1.6.1.bb
index 417818b..4412030 100644
--- a/recipes-devtools/python/python-tempora_1.6.1.bb
+++ b/recipes-devtools/python/python-tempora_1.6.1.bb
@@ -14,7 +14,7 @@ FILES_${PN} += "${datadir}/tempora"
  
  BBCLASSEXTEND = "nativesdk"
  
-DEPENDS += " swig-native"

+DEPENDS += " swig-native python-setuptools-scm-native"
  
  RDEPENDS_${PN} += " \

  python-pip \


--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH] base.cfg: Add POSIX_TIMERS to fix ping hang

2017-04-21 Thread Cal Sullivan 



On 04/21/2017 11:19 AM, Bruce Ashfield wrote:

On 2017-04-18 11:38 AM, Paul Gortmaker wrote:

On 2017-04-17 08:31 PM, Saul Wold wrote:

busybox ping was hanging after 1 loop with 4.10.x/4.11.x kernel.
ping was hanging waiting for alarm to expire.
4.10.x kernel intrdoduced new kernel config CONFIG_POSIX_TIMERS
which needs to be enabled to enable calls timer_create, settimer,
alarm etc.


This shouldn't be needed:



ping.

Saul: are you still seeing this as not set ? And functionality
being dropped ?
With genericx86-64 MACHINE on poky master HEAD I'm seeing 
CONFIG_POSIX_TIMERS=y.


---
Cal



Bruce


init/Kconfig:config POSIX_TIMERS
init/Kconfig:   bool "Posix Clocks & timers" if EXPERT
init/Kconfig:   default y

...so unless we've got a config frag explicitly setting it to
off, it should be selected/on.  Since you say it is a new option,
then we shouldn't have any frag setting it to off.

Paul.
--


Signed-off-by: Kushwaha, Priyalee 
Signed-off-by: Saul Wold 
---
Targeted for 4.10 and beyond

 ktypes/base/base.cfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ktypes/base/base.cfg b/ktypes/base/base.cfg
index 91a140b..062f6e3 100644
--- a/ktypes/base/base.cfg
+++ b/ktypes/base/base.cfg
@@ -23,6 +23,7 @@ CONFIG_LOCALVERSION=""
 CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
+CONFIG_POSIX_TIMERS=y
 CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_BSD_PROCESS_ACCT_V3=y
 # CONFIG_AUDIT is not set





--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] [meta-inte][rmc][PATCH v2 1/1] rmc: add support for alternative EFI bootloaders

2016-12-15 Thread Cal Sullivan 



On 12/15/2016 10:23 AM, Todor Minchev wrote:

On Thu, 2016-12-15 at 10:09 -0800, Cal Sullivan wrote:

On 12/13/2016 04:50 PM, Todor Minchev wrote:

On Tue, 2016-12-13 at 16:22 -0800, Jianxun Zhang wrote:

On Dec 13, 2016, at 2:56 PM, Todor Minchev <todor.minchev@linux
.intel.com> wrote:

RMC was previously configured to work only with the systemd-
boot EFI
bootloader. With this commit we can specify alternative
bootloaders by
setting the RMC_BOOTLOADER variable in local.conf. If
RMC_BOOTLOADER is
not set systemd-boot will be used by default.

Signed-off-by: Todor Minchev <todor.minc...@linux.intel.com>
---
Remove references to grub-efi and gummiboot from V1.

classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} |  5
+++--
conf/machine/include/meta-intel.inc|  2 +-
documentation/rmc/README   | 16
+---
3 files changed, 17 insertions(+), 6 deletions(-)
rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass}
(73%)

diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-
boot.bbclass
similarity index 73%
rename from classes/rmc-systemd-boot.bbclass
rename to classes/rmc-boot.bbclass
index ad2cf10..a1f2093 100644
--- a/classes/rmc-systemd-boot.bbclass
+++ b/classes/rmc-boot.bbclass
@@ -1,9 +1,10 @@
-# rmc-systemd-boot bbclass
+# rmc-boot bbclass
# Deploy central RMC database file to ESP

IMAGE_INSTALL_append = " rmc"
+RMC_BOOTLOADER ?= "systemd-boot”

Maybe this is what we could have now without bothering OE. It is
better than the corrent code at the cost of another variable to
user. I hope in the future we could get rid of  the dependency to
EFI_PROVIDER (e.g. bz10084).

Also refer to my comment for the document change at the below.

-inherit systemd-boot
+inherit ${RMC_BOOTLOADER}

do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"

diff --git a/conf/machine/include/meta-intel.inc
b/conf/machine/include/meta-intel.inc
index c7555ce..fd0a792 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = "${
@bb.utils.contains('MACHINE_FEATURE
# merge the microcode data in the final initrd image.
INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES',
'intel-ucode', '${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"

-EFI_PROVIDER ?= "rmc-systemd-boot"
+EFI_PROVIDER ?= "rmc-boot"

# Add general MACHINEOVERRIDE for meta-intel
MACHINEOVERRIDES =. "intel-x86-common:"
diff --git a/documentation/rmc/README
b/documentation/rmc/README
index 2427ffd..dbee6b6 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -165,14 +165,24 @@ steps still can override results from
this hook for boot entries and KBOOTPARAM.

Enable RMC Feature
-
---
-To Enable RMC feature in build, add the below lines in a conf
file:
+To enable the RMC feature please add the following variables
to your local.conf.
+
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
+
+The default EFI bootloader used with RMC is systemd-boot. To
change the default
+bootloader please overwrite the RMC_BOOTLOADER variable in
your local.conf

Note:
Image could be still bootable if you only have either of two
lines, but RMC
feature won't be fully functional.

+To install only the RMC client with the systemd-boot
bootloader without
+including a default RMC database file, add the following lines
to your
+local.conf:
+
+EFI_PROVIDER = "systemd-boot"
+IMAGE_INSTALL_append = " rmc”

I think this use case could confuse for user without much
benefit. And actually they still can set EFI_PROVIDER to any
available efi bootloaders to get this effect as long as it is not
“rmc-boot”, right?
Maybe we should just say “you won’t get rmc database deployed if
you set EFI_PROVIDER to any values not rmc-boot."

Yes, this can be another way to phrase this.

Is there going to be a v3 or is it sufficient as-is?

This is OK for now. I will reword the README after we add full RMC
support to grub-efi.

Great, thanks. I will merge it shortly along with Ross' changes.

  

Thanks,
Cal



Examples
@@ -190,7 +200,7 @@ EXAMPLE 1: Support a new board type:
(1) enable the feature and do a build to get a live-boot image
by adding these
  lines in conf/local.conf:
  DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"

(2) flash the image to a USB stick and boot it on your board



--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-inte][rmc][PATCH v2 1/1] rmc: add support for alternative EFI bootloaders

2016-12-15 Thread Cal Sullivan 



On 12/13/2016 04:50 PM, Todor Minchev wrote:

On Tue, 2016-12-13 at 16:22 -0800, Jianxun Zhang wrote:

On Dec 13, 2016, at 2:56 PM, Todor Minchev  
wrote:

RMC was previously configured to work only with the systemd-boot EFI
bootloader. With this commit we can specify alternative bootloaders by
setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
not set systemd-boot will be used by default.

Signed-off-by: Todor Minchev 
---
Remove references to grub-efi and gummiboot from V1.

classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} |  5 +++--
conf/machine/include/meta-intel.inc|  2 +-
documentation/rmc/README   | 16 +---
3 files changed, 17 insertions(+), 6 deletions(-)
rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} (73%)

diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-boot.bbclass
similarity index 73%
rename from classes/rmc-systemd-boot.bbclass
rename to classes/rmc-boot.bbclass
index ad2cf10..a1f2093 100644
--- a/classes/rmc-systemd-boot.bbclass
+++ b/classes/rmc-boot.bbclass
@@ -1,9 +1,10 @@
-# rmc-systemd-boot bbclass
+# rmc-boot bbclass
# Deploy central RMC database file to ESP

IMAGE_INSTALL_append = " rmc"
+RMC_BOOTLOADER ?= "systemd-boot”

Maybe this is what we could have now without bothering OE. It is better than 
the corrent code at the cost of another variable to user. I hope in the future 
we could get rid of  the dependency to EFI_PROVIDER (e.g. bz10084).

Also refer to my comment for the document change at the below.

-inherit systemd-boot
+inherit ${RMC_BOOTLOADER}

do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"

diff --git a/conf/machine/include/meta-intel.inc 
b/conf/machine/include/meta-intel.inc
index c7555ce..fd0a792 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = 
"${@bb.utils.contains('MACHINE_FEATURE
# merge the microcode data in the final initrd image.
INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', 
'${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"

-EFI_PROVIDER ?= "rmc-systemd-boot"
+EFI_PROVIDER ?= "rmc-boot"

# Add general MACHINEOVERRIDE for meta-intel
MACHINEOVERRIDES =. "intel-x86-common:"
diff --git a/documentation/rmc/README b/documentation/rmc/README
index 2427ffd..dbee6b6 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -165,14 +165,24 @@ steps still can override results from this hook for boot 
entries and KBOOTPARAM.

Enable RMC Feature

-To Enable RMC feature in build, add the below lines in a conf file:
+To enable the RMC feature please add the following variables to your 
local.conf.
+
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
+
+The default EFI bootloader used with RMC is systemd-boot. To change the default
+bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf

Note:
Image could be still bootable if you only have either of two lines, but RMC
feature won't be fully functional.

+To install only the RMC client with the systemd-boot bootloader without
+including a default RMC database file, add the following lines to your
+local.conf:
+
+EFI_PROVIDER = "systemd-boot"
+IMAGE_INSTALL_append = " rmc”

I think this use case could confuse for user without much benefit. And actually 
they still can set EFI_PROVIDER to any available efi bootloaders to get this 
effect as long as it is not “rmc-boot”, right?
Maybe we should just say “you won’t get rmc database deployed if you set 
EFI_PROVIDER to any values not rmc-boot."

Yes, this can be another way to phrase this.

Is there going to be a v3 or is it sufficient as-is?

Thanks,
Cal



Examples
@@ -190,7 +200,7 @@ EXAMPLE 1: Support a new board type:
(1) enable the feature and do a build to get a live-boot image by adding these
 lines in conf/local.conf:
 DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"

(2) flash the image to a USB stick and boot it on your board

--
2.11.0





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-inte][rmc][PATCH v2 1/1] rmc: add support for alternative EFI bootloaders

2016-12-13 Thread Cal Sullivan 
I like where this is heading but does RMC function with bootloaders 
besides systemd-boot yet?
A quick boot test with this patch and RMC_BOOTLOADER = "grub-efi" seems 
to give me vanilla grub-efi.


Thanks,
Cal

On 12/13/2016 04:50 PM, Todor Minchev wrote:

On Tue, 2016-12-13 at 16:22 -0800, Jianxun Zhang wrote:

On Dec 13, 2016, at 2:56 PM, Todor Minchev  
wrote:

RMC was previously configured to work only with the systemd-boot EFI
bootloader. With this commit we can specify alternative bootloaders by
setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
not set systemd-boot will be used by default.

Signed-off-by: Todor Minchev 
---
Remove references to grub-efi and gummiboot from V1.

classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} |  5 +++--
conf/machine/include/meta-intel.inc|  2 +-
documentation/rmc/README   | 16 +---
3 files changed, 17 insertions(+), 6 deletions(-)
rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} (73%)

diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-boot.bbclass
similarity index 73%
rename from classes/rmc-systemd-boot.bbclass
rename to classes/rmc-boot.bbclass
index ad2cf10..a1f2093 100644
--- a/classes/rmc-systemd-boot.bbclass
+++ b/classes/rmc-boot.bbclass
@@ -1,9 +1,10 @@
-# rmc-systemd-boot bbclass
+# rmc-boot bbclass
# Deploy central RMC database file to ESP

IMAGE_INSTALL_append = " rmc"
+RMC_BOOTLOADER ?= "systemd-boot”

Maybe this is what we could have now without bothering OE. It is better than 
the corrent code at the cost of another variable to user. I hope in the future 
we could get rid of  the dependency to EFI_PROVIDER (e.g. bz10084).

Also refer to my comment for the document change at the below.

-inherit systemd-boot
+inherit ${RMC_BOOTLOADER}

do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"

diff --git a/conf/machine/include/meta-intel.inc 
b/conf/machine/include/meta-intel.inc
index c7555ce..fd0a792 100644
--- a/conf/machine/include/meta-intel.inc
+++ b/conf/machine/include/meta-intel.inc
@@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = 
"${@bb.utils.contains('MACHINE_FEATURE
# merge the microcode data in the final initrd image.
INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 'intel-ucode', 
'${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"

-EFI_PROVIDER ?= "rmc-systemd-boot"
+EFI_PROVIDER ?= "rmc-boot"

# Add general MACHINEOVERRIDE for meta-intel
MACHINEOVERRIDES =. "intel-x86-common:"
diff --git a/documentation/rmc/README b/documentation/rmc/README
index 2427ffd..dbee6b6 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -165,14 +165,24 @@ steps still can override results from this hook for boot 
entries and KBOOTPARAM.

Enable RMC Feature

-To Enable RMC feature in build, add the below lines in a conf file:
+To enable the RMC feature please add the following variables to your 
local.conf.
+
DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"
+
+The default EFI bootloader used with RMC is systemd-boot. To change the default
+bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf

Note:
Image could be still bootable if you only have either of two lines, but RMC
feature won't be fully functional.

+To install only the RMC client with the systemd-boot bootloader without
+including a default RMC database file, add the following lines to your
+local.conf:
+
+EFI_PROVIDER = "systemd-boot"
+IMAGE_INSTALL_append = " rmc”

I think this use case could confuse for user without much benefit. And actually 
they still can set EFI_PROVIDER to any available efi bootloaders to get this 
effect as long as it is not “rmc-boot”, right?
Maybe we should just say “you won’t get rmc database deployed if you set 
EFI_PROVIDER to any values not rmc-boot."

Yes, this can be another way to phrase this.


Examples
@@ -190,7 +200,7 @@ EXAMPLE 1: Support a new board type:
(1) enable the feature and do a build to get a live-boot image by adding these
 lines in conf/local.conf:
 DISTRO_FEATURES_append = " rmc"
-EFI_PROVIDER = "rmc-systemd-boot"
+EFI_PROVIDER = "rmc-boot"

(2) flash the image to a USB stick and boot it on your board

--
2.11.0





--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 0/3] For bxt-rebase: Enable MIPI DSI display support

2016-11-22 Thread Cal Sullivan 



On 11/22/2016 10:45 AM, Laitinen, Jukka wrote:

On 2016-11-22 09:09 AM, Jukka Laitinen wrote:

Hi!

This is a set of patches, cherry-picked from 4.8 kernel, to enable
MIPI DSI display support on Joule platform. The patches are unmodified
apart from some whitespaces, there was no real backporting needed.

I noticed that these also apply cleanly to standard/intel/base.

Any thoughts on whether that's an ok landing spot for them ? I'd of course then 
merge standard/intel/base into standard/intel/bxt-rebase.

Bruce


IMHO, it is fine to merge into standard/intel/base. It only touches the 
mipi-dsi code in the i915 driver.

Jukka

+1

These are actually backports though, so the upstream commit IDs should 
probably be added.


---
Cal
--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 0/2] Fix merge errors on bxt-rebase branch

2016-11-15 Thread Cal Sullivan 
These are likely appropriate for standard/intel/base as well (we have 
the same drm backport). Once a non-mangled version is sent please try 
applying there first.


Thanks,
Cal

On 11/15/2016 06:09 AM, Bruce Ashfield wrote:

On 2016-11-14 07:43 AM, Jukka Laitinen wrote:
The i915 module stopped compiling in 4.4.30 rebase. These patches fix 
the

merge errors causing this.



It looks like exchange mangled these patches on the way through, I'm
seeing line wraps in the header, which lead to:

Applying: Revert "UPSTREAM: drm/i915: take a power domain ref only 
when needed during HDMI detect"

fatal: corrupt patch at line 27
Patch failed at 0001 Revert "UPSTREAM: drm/i915: take a power domain 
ref only when needed during HDMI detect"


---

I'll see if I can fix them up manually, but if you can see if something
did reformat/reflow them on your end, that would be great as well.

Bruce



Jukka Laitinen (2):
  Revert "UPSTREAM: drm/i915: take a power domain ref only when needed
during HDMI detect"
  Fix merge errors for i915 to compile

 drivers/gpu/drm/i915/intel_drv.h  |  3 ---
 drivers/gpu/drm/i915/intel_hdmi.c | 12 +---
 2 files changed, 5 insertions(+), 10 deletions(-)





--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH v2 1/1] drm/i915: Fix v4.4.20 -> v4.4.22 i915 merge.

2016-10-14 Thread Cal Sullivan 

DO NOT MERGE.

Apologies, but my commit message is actually incorrect here, this 
actually fixes two patches. It seems that despite applying cleanly, one 
of the patches did somehow not get merged correctly. I will send a v3 in 
a few minutes.


Thanks,
Cal

On 10/14/2016 03:17 PM, California Sullivan wrote:

Portions of commit e153f52df9 "drm/i915: Check VBT for port presence in
addition to the strap on VLV/CHV" were missed in the merge commit,
causing build errors. This patch fixes the issues by reverting the i915
changes in the merge, reapplying the patches and fixing conflicts
where they occur, then squashing the result.

Patches besides e153f52df9 either applied cleanly or were also present
before the merge and did not need fixing.

Signed-off-by: California Sullivan 
---
  drivers/gpu/drm/i915/i915_drv.h  |  1 +
  drivers/gpu/drm/i915/intel_bios.c| 39 
  drivers/gpu/drm/i915/intel_display.c |  1 +
  drivers/gpu/drm/i915/intel_dp.c  |  6 +++---
  drivers/gpu/drm/i915/intel_drv.h |  2 +-
  5 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6f1e0f1..19819aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3485,6 +3485,7 @@ bool intel_bios_is_port_edp(struct drm_i915_private 
*dev_priv, enum port port);
  bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
*port);
  bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
 enum port port);
+bool intel_bios_is_port_present(struct drm_i915_private *dev_priv, enum port 
port);
  
  /* intel_opregion.c */

  #ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index e72dd9a..8118364 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1660,3 +1660,42 @@ intel_bios_is_port_hpd_inverted(struct drm_i915_private 
*dev_priv,
  
  	return false;

  }
+
+/**
+ * intel_bios_is_port_present - is the specified digital port present
+ * @dev_priv:  i915 device instance
+ * @port:  port to check
+ *
+ * Return true if the device in %port is present.
+ */
+bool intel_bios_is_port_present(struct drm_i915_private *dev_priv, enum port 
port)
+{
+   static const struct {
+   u16 dp, hdmi;
+   } port_mapping[] = {
+   [PORT_B] = { DVO_PORT_DPB, DVO_PORT_HDMIB, },
+   [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
+   [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
+   [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
+   };
+   int i;
+
+   /* FIXME maybe deal with port A as well? */
+   if (WARN_ON(port == PORT_A) || port >= ARRAY_SIZE(port_mapping))
+   return false;
+
+   if (!dev_priv->vbt.child_dev_num)
+   return false;
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+   const union child_device_config *p_child =
+   _priv->vbt.child_dev[i];
+   if ((p_child->common.dvo_port == port_mapping[port].dp ||
+p_child->common.dvo_port == port_mapping[port].hdmi) &&
+   (p_child->common.device_type & 
(DEVICE_TYPE_TMDS_DVI_SIGNALING |
+   
DEVICE_TYPE_DISPLAYPORT_OUTPUT)))
+   return true;
+   }
+
+   return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8a4a372..70dd990 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14559,6 +14559,7 @@ static void intel_setup_outputs(struct drm_device *dev)
if (I915_READ(PCH_DP_D) & DP_DETECTED)
intel_dp_init(dev, PCH_DP_D, PORT_D);
} else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
+   bool has_edp, has_port;
/*
 * The DP_DETECTED bit is the latched state of the DDC
 * SDA pin at boot. However since eDP doesn't require DDC
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62bd8f7..12bd17f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5957,9 +5957,9 @@ fail:
return false;
  }
  
-void

-intel_dp_init(struct drm_device *dev,
- i915_reg_t output_reg, enum port port)
+bool intel_dp_init(struct drm_device *dev,
+  i915_reg_t output_reg,
+  enum port port)
  {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_digital_port *intel_dig_port;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 236ce98..6f69e14 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1279,7

Re: [linux-yocto] [PATCH 1/1] drm/i915: Fix v4.4.20 -> v4.4.22 i915 merge.

2016-10-14 Thread Cal Sullivan 



On 10/14/2016 02:19 PM, Ernst, Eric wrote:

On Fri, Oct 14, 2016 at 02:14:02PM -0700, California Sullivan wrote:

The addition of a new function and some return types was missed in the
original merge, causing build errors.


If it were me, I would want to have details on exactly which patches had
conflicts, since it appears you went patch by patch based on your cover-letter.

Is that right?

That'll yield a bit more detail which, if there are issues later, could help
point is in the right location (that is, if there are regressions, or when we
run into merge conflicts on the next stable update/backport).

Eric

Yes, you're right. If all else looks good I will resubmit with a more 
detailed commit message.


Thanks,
Cal




Signed-off-by: California Sullivan 
---
  drivers/gpu/drm/i915/i915_drv.h  |  1 +
  drivers/gpu/drm/i915/intel_bios.c| 39 
  drivers/gpu/drm/i915/intel_display.c |  2 ++
  drivers/gpu/drm/i915/intel_dp.c  |  6 +++---
  drivers/gpu/drm/i915/intel_drv.h |  2 +-
  5 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6f1e0f1..19819aa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3485,6 +3485,7 @@ bool intel_bios_is_port_edp(struct drm_i915_private 
*dev_priv, enum port port);
  bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
*port);
  bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
 enum port port);
+bool intel_bios_is_port_present(struct drm_i915_private *dev_priv, enum port 
port);
  
  /* intel_opregion.c */

  #ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index e72dd9a..8118364 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1660,3 +1660,42 @@ intel_bios_is_port_hpd_inverted(struct drm_i915_private 
*dev_priv,
  
  	return false;

  }
+
+/**
+ * intel_bios_is_port_present - is the specified digital port present
+ * @dev_priv:  i915 device instance
+ * @port:  port to check
+ *
+ * Return true if the device in %port is present.
+ */
+bool intel_bios_is_port_present(struct drm_i915_private *dev_priv, enum port 
port)
+{
+   static const struct {
+   u16 dp, hdmi;
+   } port_mapping[] = {
+   [PORT_B] = { DVO_PORT_DPB, DVO_PORT_HDMIB, },
+   [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
+   [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
+   [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
+   };
+   int i;
+
+   /* FIXME maybe deal with port A as well? */
+   if (WARN_ON(port == PORT_A) || port >= ARRAY_SIZE(port_mapping))
+   return false;
+
+   if (!dev_priv->vbt.child_dev_num)
+   return false;
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+   const union child_device_config *p_child =
+   _priv->vbt.child_dev[i];
+   if ((p_child->common.dvo_port == port_mapping[port].dp ||
+p_child->common.dvo_port == port_mapping[port].hdmi) &&
+   (p_child->common.device_type & 
(DEVICE_TYPE_TMDS_DVI_SIGNALING |
+   
DEVICE_TYPE_DISPLAYPORT_OUTPUT)))
+   return true;
+   }
+
+   return false;
+}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8a4a372..bf0e19c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14559,6 +14559,8 @@ static void intel_setup_outputs(struct drm_device *dev)
if (I915_READ(PCH_DP_D) & DP_DETECTED)
intel_dp_init(dev, PCH_DP_D, PORT_D);
} else if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
+   bool has_edp, has_port;
+
/*
 * The DP_DETECTED bit is the latched state of the DDC
 * SDA pin at boot. However since eDP doesn't require DDC
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62bd8f7..12bd17f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5957,9 +5957,9 @@ fail:
return false;
  }
  
-void

-intel_dp_init(struct drm_device *dev,
- i915_reg_t output_reg, enum port port)
+bool intel_dp_init(struct drm_device *dev,
+  i915_reg_t output_reg,
+  enum port port)
  {
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_digital_port *intel_dig_port;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 236ce98..6f69e14 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1279,7 +1279,7

Re: [linux-yocto] [PATCH 0/2] Fix standard/base pollution

2016-09-30 Thread Cal Sullivan 



On 09/30/2016 01:51 PM, Bruce Ashfield wrote:

On 2016-09-30 4:46 PM, California Sullivan wrote:

Hi Bruce, Saul,

A while back before we created the standard/intel/base branches some
patches that were not appropriate for standard/base were merged into
the branch and caused bug [YOCTO #9587]. This patch set aims to fix
that.

The first patch reverts the inappropriate patches in standard/base. The
second patch reverts the revert and is intended for standard/intel/base
after the first revert patch waterfalls into it.

I know this is kind of kludgey but I believe its the right thing to do.

Let me know if you think otherwise.


I can do the individual reverts, rather than via a single patch. Just
provide the commit IDs (which you did in your email, so that is fine).

I can then apply those same changes to standard/intel/base again. That
way we keep a 1:1 commit granularity.

If git objects, I can go the route of these patches :D

Bruce



That will work!

I forgot to mention, this is intended for the 4.1 tree. The 4.4 tree has 
more inappropriate patches and their order matters. Here are the commit 
IDs in an order that reverted cleanly for me:


4086f8c349569926fd8fbe967ec24bdeabc79f95
0148b3601f29b159b4f84c1478ff1859bbd48efe
08943f2bbd507f8b7f5ef101ccc4755cbec79aad
a517d5b72e764ec22f0055edeb685c102051239e
cd83f4095b234652ae65321f35700f7e3441f0f9

Thanks,
Cal



Thanks,
Cal

California Sullivan (2):
  Revert Upstream-status: Inappropriate commits in standard/base
  Reapply Upstream-status: Inappropriate commits removed from
standard/base






--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH] intel-quark.cfg: Explicitly disable CONFIG_64BIT

2016-08-29 Thread Cal Sullivan 

Ack'd.
We'll need this setting on master, yocto-4.4, and yocto-4.1.

Thanks,
Cal Sullivan

On 08/29/2016 10:49 AM, Mikko Ylinen wrote:

In a follow-up to e9ec769926b2378e63380bd7762ce7ce201af151
explicitly disable CONFIG_64BIT on Quark too.

Signed-off-by: Mikko Ylinen <mikko.yli...@linux.intel.com>
---
  bsp/intel-common/intel-quark.cfg | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/bsp/intel-common/intel-quark.cfg b/bsp/intel-common/intel-quark.cfg
index bdb555d..e8198bb 100644
--- a/bsp/intel-common/intel-quark.cfg
+++ b/bsp/intel-common/intel-quark.cfg
@@ -3,6 +3,9 @@ CONFIG_X86_TSC=y
  CONFIG_X86_MCE=y
  CONFIG_PM=y
  
+# Must explicitly disable 64BIT

+# CONFIG_64BIT is not set
+
  CONFIG_X86_INTEL_QUARK=y
  CONFIG_MFD_INTEL_QUARK_I2C_GPIO=y
  CONFIG_INTEL_QUARK_DTS_THERMAL=y


--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto