Re: [PATCH] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009

Hi Jian-Hong, On Fri, May 25, 2018 at 3:54 AM, Jian-Hong Pan wrote: > > Without this patch we cannot turn on the Bluethooth adapter on HP > 14-bs007la. Please correct me if I'm wrong, but it looks like we are still waiting for the testing of this patch from our

Re: [PATCH] Bluetooth: Add a new Realtek 8723DE ID 0bda:b009

Hi Jian-Hong, On Fri, May 25, 2018 at 3:54 AM, Jian-Hong Pan wrote: > > Without this patch we cannot turn on the Bluethooth adapter on HP > 14-bs007la. Please correct me if I'm wrong, but it looks like we are still waiting for the testing of this patch from our colleagues in Guatemala. There

Re: [PATCH v2] platform/x86: asus-wmi: Add keyboard backlight toggle support

On Tue, May 22, 2018 at 4:11 AM, Chris Chiu wrote: > On Tue, May 22, 2018 at 5:18 PM, Andy Shevchenko >> Btw, I mistakenly thought that patch in the queue for-next, while it's >> not. So, I'm going to drop it now. >> Feel free to re-submit a new (better) version. > > So it's

Re: [PATCH v2] platform/x86: asus-wmi: Add keyboard backlight toggle support

On Tue, May 22, 2018 at 4:11 AM, Chris Chiu wrote: > On Tue, May 22, 2018 at 5:18 PM, Andy Shevchenko >> Btw, I mistakenly thought that patch in the queue for-next, while it's >> not. So, I'm going to drop it now. >> Feel free to re-submit a new (better) version. > > So it's better to handle

Re: [PATCH v2] platform/x86: asus-wmi: Add keyboard backlight toggle support

Hi Andy, On Mon, May 7, 2018 at 8:46 AM, Daniel Drake <dr...@endlessm.com> wrote: > > > Some Asus laptops like UX550GE has hotkey (Fn+F7) for keyboard > > > backlight toggle. In this UX550GE, the hotkey incremet the level > > > of brightness for each keyp

Re: [PATCH v2] platform/x86: asus-wmi: Add keyboard backlight toggle support

Hi Andy, On Mon, May 7, 2018 at 8:46 AM, Daniel Drake wrote: > > > Some Asus laptops like UX550GE has hotkey (Fn+F7) for keyboard > > > backlight toggle. In this UX550GE, the hotkey incremet the level > > > of brightness for each keypress from 1 to 3, and th

Re: [BUG] i2c-hid: ELAN Touchpad does not work on ASUS X580GD

On Tue, May 8, 2018 at 8:31 AM, Jarkko Nikula wrote: >> Some update, we can make the touchpad work by simply modifying the >> clk_rate of spt_i2c_info from 12000 to 13300 in intel-lpss-pci.c for >> specific PCI ID 8086:a368 ~ a36a (CoffeeLake). Is the clock

Re: [BUG] i2c-hid: ELAN Touchpad does not work on ASUS X580GD

On Tue, May 8, 2018 at 8:31 AM, Jarkko Nikula wrote: >> Some update, we can make the touchpad work by simply modifying the >> clk_rate of spt_i2c_info from 12000 to 13300 in intel-lpss-pci.c for >> specific PCI ID 8086:a368 ~ a36a (CoffeeLake). Is the clock setting different >> for the

Re: [PATCH v2] platform/x86: asus-wmi: Add keyboard backlight toggle support

Hi Andy, On Mon, May 7, 2018 at 8:10 AM, Andy Shevchenko wrote: > > On Thu, May 3, 2018 at 6:04 AM, Chris Chiu wrote: > > Some Asus laptops like UX550GE has hotkey (Fn+F7) for keyboard > > backlight toggle. In this UX550GE, the hotkey incremet the

Re: [PATCH v2] platform/x86: asus-wmi: Add keyboard backlight toggle support

Hi Andy, On Mon, May 7, 2018 at 8:10 AM, Andy Shevchenko wrote: > > On Thu, May 3, 2018 at 6:04 AM, Chris Chiu wrote: > > Some Asus laptops like UX550GE has hotkey (Fn+F7) for keyboard > > backlight toggle. In this UX550GE, the hotkey incremet the level > > of brightness for each keypress from

[PATCH v2] ACPI / PM: allow deeper wakeup power states with no _SxD nor _SxW

hias Nyman for pointing us in the right direction. Signed-off-by: Daniel Drake <dr...@endlessm.com> Link: http://lkml.kernel.org/r/CAB4CAwf_k-WsF3zL4epm9TKAOu0h=bv1xhxv_gy3bzioo_n...@mail.gmail.com https://phabricator.endlessm.com/T21410 --- Notes: This should be considered for Li

[PATCH v2] ACPI / PM: allow deeper wakeup power states with no _SxD nor _SxW

hias Nyman for pointing us in the right direction. Signed-off-by: Daniel Drake Link: http://lkml.kernel.org/r/CAB4CAwf_k-WsF3zL4epm9TKAOu0h=bv1xhxv_gy3bzioo_n...@mail.gmail.com https://phabricator.endlessm.com/T21410 --- Notes: This should be considered for Linux 4.17 to give it a dec

[PATCH] ACPI / PM: allow deeper wakeup power states with no _SxD nor _SxW

hias Nyman for pointing us in the right direction. Signed-off-by: Daniel Drake <dr...@endlessm.com> Link: http://lkml.kernel.org/r/CAB4CAwf_k-WsF3zL4epm9TKAOu0h=bv1xhxv_gy3bzioo_n...@mail.gmail.com --- drivers/acpi/device_pm.c | 11 --- 1 file changed, 8 insertions(+), 3 deletion

[PATCH] ACPI / PM: allow deeper wakeup power states with no _SxD nor _SxW

hias Nyman for pointing us in the right direction. Signed-off-by: Daniel Drake Link: http://lkml.kernel.org/r/CAB4CAwf_k-WsF3zL4epm9TKAOu0h=bv1xhxv_gy3bzioo_n...@mail.gmail.com --- drivers/acpi/device_pm.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/d

Re: Intel GemniLake xHCI connected devices can never wake up the system from suspend

On Mon, Mar 19, 2018 at 6:36 AM, Rafael J. Wysocki wrote: > On Fri, Mar 16, 2018 at 10:06 AM, Mathias Nyman > wrote: >> Adding Rafael directly to CC >> >> In short, if _S3D and _S3W are missing in DSDT then a PCI device >> stays in D0 during

Re: Intel GemniLake xHCI connected devices can never wake up the system from suspend

On Mon, Mar 19, 2018 at 6:36 AM, Rafael J. Wysocki wrote: > On Fri, Mar 16, 2018 at 10:06 AM, Mathias Nyman > wrote: >> Adding Rafael directly to CC >> >> In short, if _S3D and _S3W are missing in DSDT then a PCI device >> stays in D0 during suspend in Linux, but goes to D3 in Windows. >> >> USB

Re: Intel GemniLake xHCI connected devices can never wake up the system from suspend

> I've studied the ACPI spec trying to understand better, but I'm > struggling with the question: > What is the maximum number (lowest power) permitted device power state > for a device that is configured as able to wake the system from S3, > **that does not implement the _S3W method**? Actually

Re: Intel GemniLake xHCI connected devices can never wake up the system from suspend

> I've studied the ACPI spec trying to understand better, but I'm > struggling with the question: > What is the maximum number (lowest power) permitted device power state > for a device that is configured as able to wake the system from S3, > **that does not implement the _S3W method**? Actually

Re: Intel GemniLake xHCI connected devices can never wake up the system from suspend

Hi, I'm working alongside Chris on this issue. On Fri, Mar 16, 2018 at 12:11 AM, Mathias Nyman wrote: > Scope (_SB.PCI0.XHC) has _PS0 method, so Linux will look for a _S3W to get > the > lowest possible D state in S3, but_S3W is missing, so Linux pci-acpi code >

Re: Intel GemniLake xHCI connected devices can never wake up the system from suspend

Hi, I'm working alongside Chris on this issue. On Fri, Mar 16, 2018 at 12:11 AM, Mathias Nyman wrote: > Scope (_SB.PCI0.XHC) has _PS0 method, so Linux will look for a _S3W to get > the > lowest possible D state in S3, but_S3W is missing, so Linux pci-acpi code > will > probably default to D0

Re: TPM driver breaks S3 suspend

Hi, Sorry for the delayed response. Unfortunately we had to return the affected machine to the vendor (Acer Veriton X4110G) although given we have a fairly complete understanding of the problem, perhaps we can find and push a fix anyway. Jarkko Sakkinen wrote:

Re: TPM driver breaks S3 suspend

Hi, Sorry for the delayed response. Unfortunately we had to return the affected machine to the vendor (Acer Veriton X4110G) although given we have a fairly complete understanding of the problem, perhaps we can find and push a fix anyway. Jarkko Sakkinen wrote: > Can you try it on

Re: [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device

Hi, On Mon, Feb 26, 2018 at 10:50 AM, wrote: > From: Corey Minyard > > Realtek has some sort of "Virtual" IPMI device on the PCI bus as a > KCS controller, but whatever it is, it's not one. Ignore it if seen. > > Reported-by: Chris Chiu

Re: [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device

Hi, On Mon, Feb 26, 2018 at 10:50 AM, wrote: > From: Corey Minyard > > Realtek has some sort of "Virtual" IPMI device on the PCI bus as a > KCS controller, but whatever it is, it's not one. Ignore it if seen. > > Reported-by: Chris Chiu > Signed-off-by: Corey Minyard > --- > > I haven't

Re: [PATCH 1/2] Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

On Wed, Dec 20, 2017 at 6:53 PM, Brian Norris wrote: > > On Wed, Dec 20, 2017 at 07:00:07PM +0800, Kai-Heng Feng wrote: > > This commit causes a regression on some QCA ROME chips. The USB device > > reset happens in btusb_open(), hence firmware loading gets interrupted.

Re: [PATCH 1/2] Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

On Wed, Dec 20, 2017 at 6:53 PM, Brian Norris wrote: > > On Wed, Dec 20, 2017 at 07:00:07PM +0800, Kai-Heng Feng wrote: > > This commit causes a regression on some QCA ROME chips. The USB device > > reset happens in btusb_open(), hence firmware loading gets interrupted. > > Oh, did you really

Re: GemniLake laptops goes power off directly after performing suspend

Hi, Adding intel-gfx list in case i915 developers can help. Updated summary below. On Thu, Dec 7, 2017 at 2:14 AM, Chris Chiu wrote: > On Wed, Dec 6, 2017 at 9:34 PM, Rafael J. Wysocki wrote: > > On Wed, Dec 6, 2017 at 10:33 AM, Chris Chiu

Re: GemniLake laptops goes power off directly after performing suspend

Hi, Adding intel-gfx list in case i915 developers can help. Updated summary below. On Thu, Dec 7, 2017 at 2:14 AM, Chris Chiu wrote: > On Wed, Dec 6, 2017 at 9:34 PM, Rafael J. Wysocki wrote: > > On Wed, Dec 6, 2017 at 10:33 AM, Chris Chiu wrote: > >> On Wed, Dec 6, 2017 at 5:56 AM, Rafael J.

Re: intel-gpio interrupts stop firing with Focaltech I2C-HID touchpad

On Thu, Nov 16, 2017 at 11:52 AM, Mika Westerberg wrote: > Please first check the signal with some analyzator if it works as > expected and let's then figure out what needs to be fixed and where ;-) It works fine under Windows, so I think it's already clear that

Re: intel-gpio interrupts stop firing with Focaltech I2C-HID touchpad

On Thu, Nov 16, 2017 at 11:52 AM, Mika Westerberg wrote: > Please first check the signal with some analyzator if it works as > expected and let's then figure out what needs to be fixed and where ;-) It works fine under Windows, so I think it's already clear that there is a Linux bug to be solved

intel-gpio interrupts stop firing with Focaltech I2C-HID touchpad

Hi, We have 2 new laptop samples which use ACPI GpioInt for the I2C-HID touchpad interrupt (via intel-gpio) and both models face different issues related to this interrupt, which is level-triggered active low (as defined by i2c-hid spec), and ultimately handled by a threaded interrupt handler in

intel-gpio interrupts stop firing with Focaltech I2C-HID touchpad

Hi, We have 2 new laptop samples which use ACPI GpioInt for the I2C-HID touchpad interrupt (via intel-gpio) and both models face different issues related to this interrupt, which is level-triggered active low (as defined by i2c-hid spec), and ultimately handled by a threaded interrupt handler in

Re: PCIe legacy interrupts blocked on Intel Apollo Lake platforms

Hi, On Wed, Oct 18, 2017 at 7:54 PM, Andy Shevchenko wrote: > While Rafael is looking for a solution, can you in meantime gather the > following on the affected hardware and share it via some resource on > Internet? > > 1. % acpidump -o tables.dat # tables.dat is point

Re: PCIe legacy interrupts blocked on Intel Apollo Lake platforms

Hi, On Wed, Oct 18, 2017 at 7:54 PM, Andy Shevchenko wrote: > While Rafael is looking for a solution, can you in meantime gather the > following on the affected hardware and share it via some resource on > Internet? > > 1. % acpidump -o tables.dat # tables.dat is point of interest

PCIe legacy interrupts blocked on Intel Apollo Lake platforms

[retitling and re-summarizing in hope of attention from Intel] Andy / Rafael, Thomas Gleixner suggested that you might be able to help with a nasty issue related to Intel Apollo Lake platforms - or you can put us in contact with another relevant person at Intel. On Thu, Oct 5, 2017 at 6:13 PM,

PCIe legacy interrupts blocked on Intel Apollo Lake platforms

[retitling and re-summarizing in hope of attention from Intel] Andy / Rafael, Thomas Gleixner suggested that you might be able to help with a nasty issue related to Intel Apollo Lake platforms - or you can put us in contact with another relevant person at Intel. On Thu, Oct 5, 2017 at 6:13 PM,

Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically

On Fri, Oct 13, 2017 at 9:12 AM, AceLan Kao wrote: > Hi Daniel, > > After applied the 2 commits you mentioned in the email, ath9k works. > > https://marc.info/?l=linux-wireless=150631274108016=2 > https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657 Thanks

Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically

On Fri, Oct 13, 2017 at 9:12 AM, AceLan Kao wrote: > Hi Daniel, > > After applied the 2 commits you mentioned in the email, ath9k works. > > https://marc.info/?l=linux-wireless=150631274108016=2 > https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657 Thanks for testing. However the

Re: r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

On Fri, Oct 6, 2017 at 9:24 AM, Rafael J. Wysocki wrote: >> On the other hand, the RP05 (root port) _PRW says it will wake up the >> system via GPE09, and the _L09 handler at least has one codepath which >> could potentially do a Notify(PXSX, 2) to indicate an ethernet wakeup.

Re: r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

On Fri, Oct 6, 2017 at 9:24 AM, Rafael J. Wysocki wrote: >> On the other hand, the RP05 (root port) _PRW says it will wake up the >> system via GPE09, and the _L09 handler at least has one codepath which >> could potentially do a Notify(PXSX, 2) to indicate an ethernet wakeup. > > Which can only

Re: r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

On Fri, Oct 6, 2017 at 8:16 AM, Francois Romieu <rom...@fr.zoreil.com> wrote: > Daniel Drake <dr...@endlessm.com> : > [...] >> Also, is there a standard behaviour defined for ethernet drivers >> regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default

Re: r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

On Fri, Oct 6, 2017 at 8:16 AM, Francois Romieu wrote: > Daniel Drake : > [...] >> Also, is there a standard behaviour defined for ethernet drivers >> regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default >> if it believes the hardware is capable of it

r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

Hi, On the Acer laptop models Aspire ES1-533, Aspire ES1-732, PackardBell ENTE69AP and Gateway NE533, we are seeing a problem where the system immediately wakes up after being put into S3 suspend. This problem has been seen on all kernel versions that we have tried, including 4.14-rc3. After

r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

Hi, On the Acer laptop models Aspire ES1-533, Aspire ES1-732, PackardBell ENTE69AP and Gateway NE533, we are seeing a problem where the system immediately wakes up after being put into S3 suspend. This problem has been seen on all kernel versions that we have tried, including 4.14-rc3. After

Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation

On Mon, Oct 2, 2017 at 10:38 PM, Thomas Gleixner wrote: >> After checking out the new code and thinking this through a bit, I think >> perhaps the only generic approach that would work is to make the >> ath9k driver require a vector allocation that enables the entire block >>

Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation

On Mon, Oct 2, 2017 at 10:38 PM, Thomas Gleixner wrote: >> After checking out the new code and thinking this through a bit, I think >> perhaps the only generic approach that would work is to make the >> ath9k driver require a vector allocation that enables the entire block >> of 4 MSI IRQs that

Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation

Hi Thomas, Thanks a lot for looking at this. On Wed, Sep 27, 2017 at 11:28 PM, Thomas Gleixner wrote: > This code is gone in -next and replaced by a new vector allocator. > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/apic Nice, thanks for cleaning that

Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation

Hi Thomas, Thanks a lot for looking at this. On Wed, Sep 27, 2017 at 11:28 PM, Thomas Gleixner wrote: > This code is gone in -next and replaced by a new vector allocator. > > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/apic Nice, thanks for cleaning that up! > But the real

Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically

Hi AceLan, On Thu, Sep 28, 2017 at 4:28 PM, AceLan Kao wrote: > Hi Daniel, > > I've tried your patch, but it doesn't work for me. > Wifi can scan AP, but can't get connected. Can you please clarify which patch(es) you have tried? This is the base patch which adds the

Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically

Hi AceLan, On Thu, Sep 28, 2017 at 4:28 PM, AceLan Kao wrote: > Hi Daniel, > > I've tried your patch, but it doesn't work for me. > Wifi can scan AP, but can't get connected. Can you please clarify which patch(es) you have tried? This is the base patch which adds the infrastructure to request

Re: [PATCH][pinctrl-next] pinctrl/amd: make functions amd_gpio_suspend and amd_gpio_resume static

tatic. > > Cleans up sparse warnings: > symbol 'amd_gpio_suspend' was not declared. Should it be static? > symbol 'amd_gpio_resume' was not declared. Should it be static? > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Reviewed-by: Daniel Drake <dr...@endlessm.com>

Re: [PATCH][pinctrl-next] pinctrl/amd: make functions amd_gpio_suspend and amd_gpio_resume static

uspend' was not declared. Should it be static? > symbol 'amd_gpio_resume' was not declared. Should it be static? > > Signed-off-by: Colin Ian King Reviewed-by: Daniel Drake

Re: [PATCH] ASoC: es8316: add I2C dependency

variable] > > This adds the required Kconfig dependency. > > Fixes: b8b88b70875a ("ASoC: add es8316 codec driver") > Signed-off-by: Arnd Bergmann <a...@arndb.de> Reviewed-by: Daniel Drake <dr...@endlessm.com> Thanks for the patch. > --- > sound/soc/co

Re: [PATCH] ASoC: es8316: add I2C dependency

> This adds the required Kconfig dependency. > > Fixes: b8b88b70875a ("ASoC: add es8316 codec driver") > Signed-off-by: Arnd Bergmann Reviewed-by: Daniel Drake Thanks for the patch. > --- > sound/soc/codecs/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > di

Re: [PATCH] acpica: Fix double-free in acpi_ns_repair_CID()

On Mon, Feb 6, 2017 at 8:46 AM, João Paulo Rechi Vita wrote: > Yes, the real problem is i2c_hid not being probed for the touchpad > device on this platform The lack of probe was because when i2c_acpi_add_device() called acpi_bus_get_device() on the handle for the touchpad

Re: [PATCH] acpica: Fix double-free in acpi_ns_repair_CID()

On Mon, Feb 6, 2017 at 8:46 AM, João Paulo Rechi Vita wrote: > Yes, the real problem is i2c_hid not being probed for the touchpad > device on this platform The lack of probe was because when i2c_acpi_add_device() called acpi_bus_get_device() on the handle for the touchpad device (TPL1), it was

Re: [PATCH] HID: add Asus macrokey support for Asus "Republic of Gamers" laptop

Hi Benjamin, On Tue, Dec 13, 2016 at 2:16 AM, Benjamin Tissoires wrote: > On Dec 12 2016 or thereabouts, Chris Chiu wrote: >> ROG means ASUS "Republic of Gamers" laptops. The input device info >> also represents itself as "ASASTeK COMPUTER INC. ROG MacroKey". It >>

Re: [PATCH] HID: add Asus macrokey support for Asus "Republic of Gamers" laptop

Hi Benjamin, On Tue, Dec 13, 2016 at 2:16 AM, Benjamin Tissoires wrote: > On Dec 12 2016 or thereabouts, Chris Chiu wrote: >> ROG means ASUS "Republic of Gamers" laptops. The input device info >> also represents itself as "ASASTeK COMPUTER INC. ROG MacroKey". It >> uses special HID_USAGE code

Re: pcieport AER error spam on Intel Skylake

f affected models. Enough hacks, I am wondering what we can do to solve this problem in the mainline kernel... On Thu, Sep 3, 2015 at 12:05 PM, Alexander Duyck <alexander.du...@gmail.com> wrote: > On 09/03/2015 06:32 AM, Daniel Drake wrote: >> >> On Wed, Sep 2, 2015 at 7:57 PM, A

Re: pcieport AER error spam on Intel Skylake

f affected models. Enough hacks, I am wondering what we can do to solve this problem in the mainline kernel... On Thu, Sep 3, 2015 at 12:05 PM, Alexander Duyck wrote: > On 09/03/2015 06:32 AM, Daniel Drake wrote: >> >> On Wed, Sep 2, 2015 at 7:57 PM, Alexander Duyck >> wrote:

Re: [PATCH] Input: elan_i2c - +200 ms delay before setting to ABS mode

On Tue, Jun 21, 2016 at 6:40 AM, 廖崇榮 wrote: > KT, is this feasible? > [KT] After internal discussion, we don't agree this patch. > It's a work-around to fix firmware bug for specific touchpad and not > tested by other device. For better or worse, Linux often takes on the

Re: [PATCH] Input: elan_i2c - +200 ms delay before setting to ABS mode

On Tue, Jun 21, 2016 at 6:40 AM, 廖崇榮 wrote: > KT, is this feasible? > [KT] After internal discussion, we don't agree this patch. > It's a work-around to fix firmware bug for specific touchpad and not > tested by other device. For better or worse, Linux often takes on the responsibility of

Re: pcieport AER error spam on Intel Skylake

On Wed, Sep 2, 2015 at 7:57 PM, Alexander Duyck wrote: > Since it is correctable errors it is likely some sort of signalling issue. > Could we get the output of something like an lspci -vt? Then you would be > able to tell what the device is on the other side of the link from 00:1c.5 > and then

Re: pcieport AER error spam on Intel Skylake

On Wed, Sep 2, 2015 at 7:57 PM, Alexander Duyck wrote: > Since it is correctable errors it is likely some sort of signalling issue. > Could we get the output of something like an lspci -vt? Then you would be > able to tell what the device is on the other side of the

pcieport AER error spam on Intel Skylake

Hi, Working with a sample for a new laptop based on Intel Skylake, the kernel logs are full of these messages: pcieport :00:1c.5: AER: Corrected error received: id=00e5 pcieport :00:1c.5: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e5(Receiver ID) pcieport

pcieport AER error spam on Intel Skylake

Hi, Working with a sample for a new laptop based on Intel Skylake, the kernel logs are full of these messages: pcieport :00:1c.5: AER: Corrected error received: id=00e5 pcieport :00:1c.5: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00e5(Receiver ID) pcieport

Re: [PATCH 5/5] ARM: dts: Add dts files for Exynos4415 SoC

On Fri, Oct 24, 2014 at 7:34 AM, Marek Szyprowski wrote: > Well, I also thought about such approach, but there are some fundamental > differences: > interrupt and clock controllers are completely different. Using a common > exynos4.dtsi > and overriding them in every node will result in a code,

Re: [PATCH 5/5] ARM: dts: Add dts files for Exynos4415 SoC

On Sun, Oct 19, 2014 at 9:32 PM, Chanwoo Choi wrote: > This patch adds new exynos4415.dtsi to support Exynos4415 SoC > based on Cortex-A9 quad cores and includes following dt nodes: There's a lot in common between your new exynos4415.dtsi and the existing exynos4.dtsi. Would it make more sense

Re: [PATCH 2/5] clk: samsung: exynos4415: Add clocks using common clock framework

On Sun, Oct 19, 2014 at 9:32 PM, Chanwoo Choi wrote: > This patch adds the new clock driver of Exynos4415 SoC based on Cortex-A9 > using common clock framework. The CMU (Clock Management Unit) of Exynos4415 > controls PLLs(Phase Locked Loops) and generates system clocks for CPU, buses > and

Re: [PATCH 2/5] clk: samsung: exynos4415: Add clocks using common clock framework

On Sun, Oct 19, 2014 at 9:32 PM, Chanwoo Choi cw00.c...@samsung.com wrote: This patch adds the new clock driver of Exynos4415 SoC based on Cortex-A9 using common clock framework. The CMU (Clock Management Unit) of Exynos4415 controls PLLs(Phase Locked Loops) and generates system clocks for CPU,

Re: [PATCH 5/5] ARM: dts: Add dts files for Exynos4415 SoC

On Sun, Oct 19, 2014 at 9:32 PM, Chanwoo Choi cw00.c...@samsung.com wrote: This patch adds new exynos4415.dtsi to support Exynos4415 SoC based on Cortex-A9 quad cores and includes following dt nodes: There's a lot in common between your new exynos4415.dtsi and the existing exynos4.dtsi. Would

Re: [PATCH 5/5] ARM: dts: Add dts files for Exynos4415 SoC

On Fri, Oct 24, 2014 at 7:34 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: Well, I also thought about such approach, but there are some fundamental differences: interrupt and clock controllers are completely different. Using a common exynos4.dtsi and overriding them in every node will

Re: [PATCH 3.17-rc4 v7 0/6] arm: Implement arch_trigger_all_cpu_backtrace

Hi, Thanks a lot for working on this! On Wed, Sep 17, 2014 at 10:10 AM, Daniel Thompson wrote: > Changes *before* v1: > > * This patchset is a hugely cut-down successor to "[PATCH v11 00/19] > arm: KGDB NMI/FIQ support". Thanks to Thomas Gleixner for suggesting > the new structure. For

Re: [PATCH 3.17-rc4 v7 0/6] arm: Implement arch_trigger_all_cpu_backtrace

Hi, Thanks a lot for working on this! On Wed, Sep 17, 2014 at 10:10 AM, Daniel Thompson daniel.thomp...@linaro.org wrote: Changes *before* v1: * This patchset is a hugely cut-down successor to [PATCH v11 00/19] arm: KGDB NMI/FIQ support. Thanks to Thomas Gleixner for suggesting the new

Re: [PATCH v2] drm/exynos: switch to universal plane API

On Fri, Sep 19, 2014 at 6:58 AM, Andrzej Hajda wrote: > The patch replaces legacy functions > drm_plane_init() / drm_crtc_init() with > drm_universal_plane_init() and drm_crtc_init_with_planes(). > It allows to replace fake primary plane with the real one. > Additionally the patch leaves cleanup

Re: [PATCH v2] drm/exynos: switch to universal plane API

On Fri, Sep 19, 2014 at 6:58 AM, Andrzej Hajda a.ha...@samsung.com wrote: The patch replaces legacy functions drm_plane_init() / drm_crtc_init() with drm_universal_plane_init() and drm_crtc_init_with_planes(). It allows to replace fake primary plane with the real one. Additionally the patch

Re: [PATCHv3 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC

On Tue, Sep 16, 2014 at 4:15 PM, Doug Anderson wrote: > NOTE: I don't think that the builtin RTC is terribly important for any > exynos-based Chromebooks that I'm aware of. We rely on the RTC that's > part of the Maxim PMIC itself and pretty much ignore the one built-in > to the exynos. I think

Re: [PATCHv3 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC

On Tue, Sep 16, 2014 at 4:15 PM, Doug Anderson diand...@chromium.org wrote: NOTE: I don't think that the builtin RTC is terribly important for any exynos-based Chromebooks that I'm aware of. We rely on the RTC that's part of the Maxim PMIC itself and pretty much ignore the one built-in to the

Re: [PATCHv3 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC

On Tue, Sep 16, 2014 at 7:48 AM, Javier Martinez Canillas wrote: >> Clock list for s3c-rtc device: >> - rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC. >> - rtc_src : XrtcXTI is 32.768.kHz source clock for RTC. > > Is this RTC source clock needed for all Exynos SoCs? It is at least

Re: [PATCHv3 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC

On Tue, Sep 16, 2014 at 7:48 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: Clock list for s3c-rtc device: - rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC. - rtc_src : XrtcXTI is 32.768.kHz source clock for RTC. Is this RTC source clock needed for all Exynos SoCs? It is

Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs

On Wed, Jul 9, 2014 at 2:23 PM, One Thousand Gnomes wrote: >> I like the sound of going to the standard ttyS notation and only >> providing ports for ones that exist, but is this userspace-visible > > ttyS is 8250 compatible UARTS. > > If the Samsung is not an 8250 compatible UART then it doesn't

Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs

On Wed, Jul 9, 2014 at 2:23 PM, One Thousand Gnomes gno...@lxorguk.ukuu.org.uk wrote: I like the sound of going to the standard ttyS notation and only providing ports for ones that exist, but is this userspace-visible ttyS is 8250 compatible UARTS. If the Samsung is not an 8250 compatible

Re: [PATCH v2 1/2] clk: samsung: exynos4: Enable ARMCLK down feature

to be working. I don't have a way of measuring the power usage, but the system seems as stable as before. Tested-by: Daniel Drake -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] ARM: dts: add CPU nodes for Exynos4 SoCs

On Fri, Jul 18, 2014 at 5:00 PM, Bartlomiej Zolnierkiewicz wrote: > Recent patch by Tomasz Figa ("irqchip: gic: Fix core ID calculation > when topology is read from DT") fixed GIC driver to filter cluster ID > from values returned by cpu_logical_map() for SoCs having registers > mapped without

Re: [PATCH] ARM: dts: add CPU nodes for Exynos4 SoCs

On Fri, Jul 18, 2014 at 5:00 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: Recent patch by Tomasz Figa (irqchip: gic: Fix core ID calculation when topology is read from DT) fixed GIC driver to filter cluster ID from values returned by cpu_logical_map() for SoCs having registers

Re: [PATCH v2 1/2] clk: samsung: exynos4: Enable ARMCLK down feature

the power usage, but the system seems as stable as before. Tested-by: Daniel Drake dr...@endlessm.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please

Re: [PATCH v3 0/4] ARM: EXYNOS: cpuidle: fix AFTR mode on boards with secure firmware enabled

Hi Bartlomiej, On Wed, Jul 9, 2014 at 6:17 PM, Bartlomiej Zolnierkiewicz wrote: > This patch series adds support for AFTR idle mode on boards with > secure firmware enabled and allows EXYNOS cpuidle driver usage on > Exynos4x12 SoCs. > > It has been tested on Trats2 board (using Exynos4412 SoC

Re: [PATCH v3 0/4] ARM: EXYNOS: cpuidle: fix AFTR mode on boards with secure firmware enabled

Hi Bartlomiej, On Wed, Jul 9, 2014 at 6:17 PM, Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com wrote: This patch series adds support for AFTR idle mode on boards with secure firmware enabled and allows EXYNOS cpuidle driver usage on Exynos4x12 SoCs. It has been tested on Trats2 board

Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs

Hi, How can we move forward here? On Thu, Jun 26, 2014 at 1:02 PM, Tomasz Figa wrote: > - basically Samsung UART already has its own namespace (ttySAC) and the > order inside it is well-defined - instance ID shall be the hardware > instance number as specified by documentation. The ports vary

Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs

Hi, How can we move forward here? On Thu, Jun 26, 2014 at 1:02 PM, Tomasz Figa t.f...@samsung.com wrote: - basically Samsung UART already has its own namespace (ttySAC) and the order inside it is well-defined - instance ID shall be the hardware instance number as specified by documentation.

Re: [PATCH v2] phy: phy-samsung-usb2: Change phy power on/power off sequence

d on and off. > > Signed-off-by: Kamil Debski Tested on ODROID-U2 with the internal LAN (which is a USB device), and an external USB mouse connected via the internal USB hub. Tested-by: Daniel Drake -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the

Re: [PATCH v2] phy: phy-samsung-usb2: Change phy power on/power off sequence

are powered on and off. Signed-off-by: Kamil Debski k.deb...@samsung.com Tested on ODROID-U2 with the internal LAN (which is a USB device), and an external USB mouse connected via the internal USB hub. Tested-by: Daniel Drake dr...@endlessm.com -- To unsubscribe from this list: send the line

Re: [PATCH 2/2] ARM: EXYNOS: Add support for firmware-assisted suspend/resume

Hi Tomasz, On Wed, Jun 25, 2014 at 5:18 PM, Tomasz Figa wrote: > On a numer of Exynos-based boards Linux kernel is running in non-secure > mode under a secure firmware. This means that certain operations need to > be handled in special way, with firmware assistance. System-wide > suspend/resume

Re: [PATCH v2 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality

On Wed, Jun 25, 2014 at 12:43 PM, Tomasz Figa wrote: > Due to recently merged patches and previous merge conflicts, the Samsung > PM Debug functionality no longer can be enabled. This patch fixes > incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds > missing header inclusion.

Re: [PATCH v2 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality

On Wed, Jun 25, 2014 at 12:43 PM, Tomasz Figa t.f...@samsung.com wrote: Due to recently merged patches and previous merge conflicts, the Samsung PM Debug functionality no longer can be enabled. This patch fixes incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds missing

Re: [PATCH 2/2] ARM: EXYNOS: Add support for firmware-assisted suspend/resume

Hi Tomasz, On Wed, Jun 25, 2014 at 5:18 PM, Tomasz Figa t.f...@samsung.com wrote: On a numer of Exynos-based boards Linux kernel is running in non-secure mode under a secure firmware. This means that certain operations need to be handled in special way, with firmware assistance. System-wide

Re: [PATCH 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality

Hi Tomasz, On Tue, Jun 24, 2014 at 2:57 PM, Tomasz Figa wrote: > Due to recently merged patches and previous merge conflicts, the Samsung > PM Debug functionality no longer can be enabled. This patch fixes > incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds > missing header

Re: [PATCH 3/6] clk: samsung: exynos4: Remove SRC_MASK_ISP gates

Hi Tomasz, On Tue, Jun 24, 2014 at 2:57 PM, Tomasz Figa wrote: > ISP special clocks have dedicated gating registers and so MUX SRC_MASK > register should not be used. This patch fixes the problem of > Exynos4x12-based boards freezing on system suspend, because those > mux outputs need not to be

Re: [PATCH v2 0/4] Add support for Exynos clock output configuration

Hi, On Tue, Jun 24, 2014 at 5:08 PM, Tomasz Figa wrote: > Tested on Odroid U3, with HSIC/USB hub using CLKOUT as reference clock, > with some additional patches. for all the patches: Tested-by: Daniel Drake Tested on ODROID-U2 alongside phy: phy-samsung-usb2: Change phy power on/pow

Re: [PATCH] phy: phy-samsung-usb2: Change phy power on/power off sequence

o enumerate without power cycling > (it's nRESET pin is connected to P3V3). > > I found that removing regulator-always-on from buck8_reg: BUCK8 in the > dts file fixes this problem. Yes, that fixes the problem. Thanks! Tested-by: Daniel Drake -- To unsubscribe from this list: se

<    1   2   3   4   5   6   >