Re: [PATCH 08/10] platform/x86: intel_pmc_core: Add ICL platform support
On Fri, Feb 01, 2019 at 01:02:32PM +0530, Rajneesh Bhardwaj wrote:
> Icelake can resue most of the CNL PCH IPs as they are mostly similar.
> This patch enables the PMC Core driver for ICL family.
>
> It also addresses few other minor issues like upper case conversions and
> some tab alignments.
>
> Cc: "David E. Box"
> Cc: Srinivas Pandruvada
> Signed-off-by: Rajneesh Bhardwaj
Acked-and-tested-by:
> ---
> drivers/platform/x86/intel_pmc_core.c | 59 +--
> drivers/platform/x86/intel_pmc_core.h | 4 ++
> 2 files changed, 50 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/platform/x86/intel_pmc_core.c
> b/drivers/platform/x86/intel_pmc_core.c
> index d3752d75075b..400946b7a3b5 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -166,25 +166,26 @@ static const struct pmc_bit_map cnp_pfear_map[] = {
> {"SDX", BIT(4)},
> {"SPE", BIT(5)},
> {"Fuse",BIT(6)},
> - {"Res_23", BIT(7)},
> + /* Reserved for Cannonlake but valid for Icelake */
> + {"SBR8",BIT(7)},
>
> {"CSME_FSC",BIT(0)},
> {"USB3_OTG",BIT(1)},
> {"EXI", BIT(2)},
> {"CSE", BIT(3)},
> - {"csme_kvm",BIT(4)},
> - {"csme_pmt",BIT(5)},
> - {"csme_clink", BIT(6)},
> - {"csme_ptio", BIT(7)},
> -
> - {"csme_usbr", BIT(0)},
> - {"csme_susram", BIT(1)},
> - {"csme_smt1", BIT(2)},
> + {"CSME_KVM",BIT(4)},
> + {"CSME_PMT",BIT(5)},
> + {"CSME_CLINK", BIT(6)},
> + {"CSME_PTIO", BIT(7)},
> +
> + {"CSME_USBR", BIT(0)},
> + {"CSME_SUSRAM", BIT(1)},
> + {"CSME_SMT1", BIT(2)},
> {"CSME_SMT4", BIT(3)},
> - {"csme_sms2", BIT(4)},
> - {"csme_sms1", BIT(5)},
> - {"csme_rtc",BIT(6)},
> - {"csme_psf",BIT(7)},
> + {"CSME_SMS2", BIT(4)},
> + {"CSME_SMS1", BIT(5)},
> + {"CSME_RTC",BIT(6)},
> + {"CSME_PSF",BIT(7)},
>
> {"SBR0",BIT(0)},
> {"SBR1",BIT(1)},
> @@ -209,6 +210,20 @@ static const struct pmc_bit_map cnp_pfear_map[] = {
> {"HDA_PGD4",BIT(2)},
> {"HDA_PGD5",BIT(3)},
> {"HDA_PGD6",BIT(4)},
> + /* Reserved for Cannonlake but valid for Icelake */
> + {"PSF6",BIT(5)},
> + {"PSF7",BIT(6)},
> + {"PSF8",BIT(7)},
> +
> + /* Icelake generation onwards only */
> + {"RES_65", BIT(0)},
> + {"RES_66", BIT(1)},
> + {"RES_67", BIT(2)},
> + {"TAM", BIT(3)},
> + {"GBETSN", BIT(4)},
> + {"TBTLSX", BIT(5)},
> + {"RES_71", BIT(6)},
> + {"RES_72", BIT(7)},
> {}
> };
>
> @@ -290,6 +305,8 @@ static const struct pmc_bit_map cnp_ltr_show_map[] = {
> {"ISH", CNP_PMC_LTR_ISH},
> {"UFSX2", CNP_PMC_LTR_UFSX2},
> {"EMMC",CNP_PMC_LTR_EMMC},
> + /* Reserved for Cannonlake but valid for Icelake */
> + {"WIGIG", ICL_PMC_LTR_WIGIG},
> /* Below two cannot be used for LTR_IGNORE */
> {"CURRENT_PLATFORM",CNP_PMC_LTR_CUR_PLT},
> {"AGGREGATED_SYSTEM", CNP_PMC_LTR_CUR_ASLT},
> @@ -311,6 +328,21 @@ static const struct pmc_reg_map cnp_reg_map = {
> .ltr_ignore_max = CNP_NUM_IP_IGN_ALLOWED,
> };
>
> +static const struct pmc_reg_map icl_reg_map = {
> + .pfear_sts = cnp_pfear_map,
> + .slp_s0_offset = CNP_PMC_SLP_S0_RES_COUNTER_OFFSET,
> + .slps0_dbg_maps = cnp_slps0_dbg_maps,
> + .ltr_show_sts = cnp_ltr_show_map,
> + .slps0_dbg_offset = CNP_PMC_SLPS0_DBG_OFFSET,
> + .ltr_ignore_offset = CNP_PMC_LTR_IGNORE_OFFSET,
> + .regmap_length = CNP_PMC_MMIO_REG_LEN,
> + .ppfear0_offset = CNP_PMC_HOST_PPFEAR0A,
> + .ppfear_buckets = ICL_PPFEAR_NUM_ENTRIES,
> + .pm_cfg_offset = CNP_PMC_PM_CFG_OFFSET,
> + .pm_read_disable_bit = CNP_PMC_READ_DISABLE_BIT,
> + .ltr_ignore_max = ICL_NUM_IP_IGN_ALLOWED,
> +};
> +
> static inline u8 pmc_core_reg_read_byte(struct pmc_dev *pmcdev, int offset)
> {
> return readb(pmcdev->regbase + offset);
> @@ -740,6 +772,7 @@ static const struct x86_cpu_id intel_pmc_core_ids[] = {
> INTEL_CPU_FAM6(KABYLAKE_MOBILE, spt_reg_map),
> INTEL_CPU_FAM6(KABYLAKE_DESKTOP, spt_reg_map),
> INTEL_CPU_FAM6(CANNONLAKE_MOBILE, cnp_reg_map),
> + INTEL_CPU_FAM6(ICELAKE_MOBILE, icl_reg_map),
> {}
> };
>
> diff --git a/drivers/platform/x86/intel_pmc_core.h
> b/drivers/platform/x86/intel_pmc_core.h
> index
Re: [PATCH 09/10] platform/x86: intel_pmc_core: Add Package cstates residency info
On Fri, Feb 01, 2019 at 01:02:33PM +0530, Rajneesh Bhardwaj wrote:
> This patch introduces a new debugfs entry to read current Package
> cstate residency counters. A similar variant of this patch was discussed
> earlier "https://patchwork.kernel.org/patch/9908563/; but didn't make it
> into mainline for various reasons. Current version only adds debugfs
> entry which is quite useful for S0ix debug but excludes the exported API
> that was there in initial version. Though there are tools like turbostat
> and socwatch which can also show this info but sometimes its more
> practical to have it here as it's hard to switch between various tools for
> S0ix debug when pmc_core driver is the primary debug tool. Internal and
> external customers have requested for this patch to be included in the
> PMC driver on many occasions and Google Chrome OS team has already included
> it in their builds. This becomes handy when requesting logs from external
> customers who may not always have above mentioned tools in their integrated
> kernel builds.
>
> Package cstate residency MSRs provide useful debug information about
> system idle states. In idle states system must enter deeper Package
> cstates. Package cstates depend not only on Core cstates but also on
> various IP block's power gating status and LTR values.
>
> For Intel Core SoCs Package C10 entry is a must for deeper sleep states
> such as S0ix. "Suspend-to-idle" should ideally take this path:
> PC0 -> PC10 -> S0ix. For S0ix debug, its logical to check for
> Package C10 residency first if for some reason system fails to enter S0ix.
>
> Please refer to this link for MSR details:
> https://software.intel.com/sites/default/files/managed/22/0d/335592-sdm-vol-4.pdf
>
> Usage:
> cat /sys/kernel/debug/pmc_core/package_cstate_show
> Package C2 : 0xec2e21735f
> Package C3 : 0xc30113ba4
> Package C6 : 0x9ef4be15c5
> Package C7 : 0x1e011904
> Package C8 : 0x3c5653cfe5a
> Package C9 : 0x0
> Package C10 : 0x16fff4289
>
> Cc: Arjan van de Ven
> Cc: "David E. Box"
> Cc: Srinivas Pandruvada
> Cc: Anshuman Gupta
> Cc: Len Brown
> Cc: Rafael J. Wysocki
> Signed-off-by: Rajneesh Bhardwaj
Tested-by: Anshuman Gupta
Acked-by: Anshuman Gupta
> ---
> drivers/platform/x86/intel_pmc_core.c | 38 +++
> drivers/platform/x86/intel_pmc_core.h | 1 +
> 2 files changed, 39 insertions(+)
>
> diff --git a/drivers/platform/x86/intel_pmc_core.c
> b/drivers/platform/x86/intel_pmc_core.c
> index 400946b7a3b5..4e7aa1711148 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -22,11 +22,24 @@
>
> #include
> #include
> +#include
>
> #include "intel_pmc_core.h"
>
> static struct pmc_dev pmc;
>
> +/* PKGC MSRs are common across Intel Core SoCs */
> +static const struct pmc_bit_map msr_map[] = {
> + {"Package C2", MSR_PKG_C2_RESIDENCY},
> + {"Package C3", MSR_PKG_C3_RESIDENCY},
> + {"Package C6", MSR_PKG_C6_RESIDENCY},
> + {"Package C7", MSR_PKG_C7_RESIDENCY},
> + {"Package C8", MSR_PKG_C8_RESIDENCY},
> + {"Package C9", MSR_PKG_C9_RESIDENCY},
> + {"Package C10", MSR_PKG_C10_RESIDENCY},
> + {}
> +};
> +
> static const struct pmc_bit_map spt_pll_map[] = {
> {"MIPI PLL",SPT_PMC_BIT_MPHY_CMN_LANE0},
> {"GEN2 USB2PCIE2 PLL", SPT_PMC_BIT_MPHY_CMN_LANE1},
> @@ -129,6 +142,7 @@ static const struct pmc_reg_map spt_reg_map = {
> .mphy_sts = spt_mphy_map,
> .pll_sts = spt_pll_map,
> .ltr_show_sts = spt_ltr_show_map,
> + .msr_sts = msr_map,
> .slp_s0_offset = SPT_PMC_SLP_S0_RES_COUNTER_OFFSET,
> .ltr_ignore_offset = SPT_PMC_LTR_IGNORE_OFFSET,
> .regmap_length = SPT_PMC_MMIO_REG_LEN,
> @@ -318,6 +332,7 @@ static const struct pmc_reg_map cnp_reg_map = {
> .slp_s0_offset = CNP_PMC_SLP_S0_RES_COUNTER_OFFSET,
> .slps0_dbg_maps = cnp_slps0_dbg_maps,
> .ltr_show_sts = cnp_ltr_show_map,
> + .msr_sts = msr_map,
> .slps0_dbg_offset = CNP_PMC_SLPS0_DBG_OFFSET,
> .ltr_ignore_offset = CNP_PMC_LTR_IGNORE_OFFSET,
> .regmap_length = CNP_PMC_MMIO_REG_LEN,
> @@ -333,6 +348,7 @@ static const struct pmc_reg_map icl_reg_map = {
> .slp_s0_offset = CNP_PMC_SLP_S0_RES_COUNTER_OFFSET,
> .slps0_dbg_maps = cnp_slps0_dbg_maps,
> .ltr_show_sts = cnp_ltr_show_map,
> +
Re: [PATCH v2 1/1] hdac-codec runtime suspended at PM:Suspend.
Is this patch not in consideration, there are no review comment for it. this patch fixes an issue with hdac hdmi codec driver. On one of our platform HD audio controller takes arounf 300ms. Below are the snippet of dmesg log. [ 3778.461888] calling :00:0e.0+ @ 3667, parent: pci:00, cb: pci_pm_resume [ 3778.775273] call :00:0e.0+ returned 0 after 306016 usecs When HD audio controller is in runtime suspend state, with direct complete, we can improve overall system wide resume latency. On Sat, Aug 18, 2018 at 11:42:03PM +0530, Anshuman Gupta wrote: > Keep hdac hdmi codec to be in runtime suspended while entering to > system wide suspend. Currently hdac hdmi codec driver using its > suspend and resume operation in prepare and complete PM callbacks, > and it resumes the hd audio controller (parent of self) from runtime > suspend and blocks the direct complete for hd audio controller. > > If hdac-codec is already in runtime suspend state skip its power down > sequence in prepare, power up sequence in complete phase. It enables > direct complete path for hdac-codec and hd audio controller > PCI device. > > Signed-off-by: Anshuman Gupta > --- > Changes in v2 > - Changed the commit message. > - Using pm_runtime_suspended instead of pm_runtime_status_suspended > in order to handle any race condition. > > sound/soc/codecs/hdac_hdmi.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c > index 84f7a7a..e965338 100644 > --- a/sound/soc/codecs/hdac_hdmi.c > +++ b/sound/soc/codecs/hdac_hdmi.c > @@ -1859,6 +1859,9 @@ static int hdmi_codec_prepare(struct device *dev) > struct hdac_ext_device *edev = to_hda_ext_device(dev); > struct hdac_device *hdev = >hdev; > > + if (pm_runtime_suspended(dev)) > + return 1; > + > pm_runtime_get_sync(>hdev.dev); > > /* > @@ -1880,6 +1883,9 @@ static void hdmi_codec_complete(struct device *dev) > struct hdac_hdmi_priv *hdmi = hdev_to_hdmi_priv(>hdev); > struct hdac_device *hdev = >hdev; > > + if (pm_runtime_suspended(dev)) > + return; > + > /* Power up afg */ > snd_hdac_codec_read(hdev, hdev->afg, 0, AC_VERB_SET_POWER_STATE, > AC_PWRST_D0); > -- > 2.7.4 > -- Thanks, Anshuman.
Re: [PATCH v2 1/1] hdac-codec runtime suspended at PM:Suspend.
Is this patch not in consideration, there are no review comment for it. this patch fixes an issue with hdac hdmi codec driver. On one of our platform HD audio controller takes arounf 300ms. Below are the snippet of dmesg log. [ 3778.461888] calling :00:0e.0+ @ 3667, parent: pci:00, cb: pci_pm_resume [ 3778.775273] call :00:0e.0+ returned 0 after 306016 usecs When HD audio controller is in runtime suspend state, with direct complete, we can improve overall system wide resume latency. On Sat, Aug 18, 2018 at 11:42:03PM +0530, Anshuman Gupta wrote: > Keep hdac hdmi codec to be in runtime suspended while entering to > system wide suspend. Currently hdac hdmi codec driver using its > suspend and resume operation in prepare and complete PM callbacks, > and it resumes the hd audio controller (parent of self) from runtime > suspend and blocks the direct complete for hd audio controller. > > If hdac-codec is already in runtime suspend state skip its power down > sequence in prepare, power up sequence in complete phase. It enables > direct complete path for hdac-codec and hd audio controller > PCI device. > > Signed-off-by: Anshuman Gupta > --- > Changes in v2 > - Changed the commit message. > - Using pm_runtime_suspended instead of pm_runtime_status_suspended > in order to handle any race condition. > > sound/soc/codecs/hdac_hdmi.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c > index 84f7a7a..e965338 100644 > --- a/sound/soc/codecs/hdac_hdmi.c > +++ b/sound/soc/codecs/hdac_hdmi.c > @@ -1859,6 +1859,9 @@ static int hdmi_codec_prepare(struct device *dev) > struct hdac_ext_device *edev = to_hda_ext_device(dev); > struct hdac_device *hdev = >hdev; > > + if (pm_runtime_suspended(dev)) > + return 1; > + > pm_runtime_get_sync(>hdev.dev); > > /* > @@ -1880,6 +1883,9 @@ static void hdmi_codec_complete(struct device *dev) > struct hdac_hdmi_priv *hdmi = hdev_to_hdmi_priv(>hdev); > struct hdac_device *hdev = >hdev; > > + if (pm_runtime_suspended(dev)) > + return; > + > /* Power up afg */ > snd_hdac_codec_read(hdev, hdev->afg, 0, AC_VERB_SET_POWER_STATE, > AC_PWRST_D0); > -- > 2.7.4 > -- Thanks, Anshuman.
[PATCH v2 1/1] hdac-codec runtime suspended at PM:Suspend.
Keep hdac hdmi codec to be in runtime suspended while entering to system wide suspend. Currently hdac hdmi codec driver using its suspend and resume operation in prepare and complete PM callbacks, and it resumes the hd audio controller (parent of self) from runtime suspend and blocks the direct complete for hd audio controller. If hdac-codec is already in runtime suspend state skip its power down sequence in prepare, power up sequence in complete phase. It enables direct complete path for hdac-codec and hd audio controller PCI device. Signed-off-by: Anshuman Gupta --- Changes in v2 - Changed the commit message. - Using pm_runtime_suspended instead of pm_runtime_status_suspended in order to handle any race condition. sound/soc/codecs/hdac_hdmi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index 84f7a7a..e965338 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -1859,6 +1859,9 @@ static int hdmi_codec_prepare(struct device *dev) struct hdac_ext_device *edev = to_hda_ext_device(dev); struct hdac_device *hdev = >hdev; + if (pm_runtime_suspended(dev)) + return 1; + pm_runtime_get_sync(>hdev.dev); /* @@ -1880,6 +1883,9 @@ static void hdmi_codec_complete(struct device *dev) struct hdac_hdmi_priv *hdmi = hdev_to_hdmi_priv(>hdev); struct hdac_device *hdev = >hdev; + if (pm_runtime_suspended(dev)) + return; + /* Power up afg */ snd_hdac_codec_read(hdev, hdev->afg, 0, AC_VERB_SET_POWER_STATE, AC_PWRST_D0); -- 2.7.4
[PATCH v2 1/1] hdac-codec runtime suspended at PM:Suspend.
Keep hdac hdmi codec to be in runtime suspended while entering to system wide suspend. Currently hdac hdmi codec driver using its suspend and resume operation in prepare and complete PM callbacks, and it resumes the hd audio controller (parent of self) from runtime suspend and blocks the direct complete for hd audio controller. If hdac-codec is already in runtime suspend state skip its power down sequence in prepare, power up sequence in complete phase. It enables direct complete path for hdac-codec and hd audio controller PCI device. Signed-off-by: Anshuman Gupta --- Changes in v2 - Changed the commit message. - Using pm_runtime_suspended instead of pm_runtime_status_suspended in order to handle any race condition. sound/soc/codecs/hdac_hdmi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index 84f7a7a..e965338 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -1859,6 +1859,9 @@ static int hdmi_codec_prepare(struct device *dev) struct hdac_ext_device *edev = to_hda_ext_device(dev); struct hdac_device *hdev = >hdev; + if (pm_runtime_suspended(dev)) + return 1; + pm_runtime_get_sync(>hdev.dev); /* @@ -1880,6 +1883,9 @@ static void hdmi_codec_complete(struct device *dev) struct hdac_hdmi_priv *hdmi = hdev_to_hdmi_priv(>hdev); struct hdac_device *hdev = >hdev; + if (pm_runtime_suspended(dev)) + return; + /* Power up afg */ snd_hdac_codec_read(hdev, hdev->afg, 0, AC_VERB_SET_POWER_STATE, AC_PWRST_D0); -- 2.7.4
[PATCH v2 0/1] cover-letter hdac-codec runtime suspended at PM:Suspend.
Current implementation of hdac hdmi codec driver uses its suspend/resume operation callback in its prepare/complete callback which has issues with hdac direct-complete, it has been reviewed earlier that hdac hdmi codec driver requires a rework (https://patchwork.kernel.org/patch/10276021/), but as there is no rework with driver, it require to fix hdac direct complete issue to leverage hdac direct complete in order to optimize its resume latency while resuming from system wide suspend. Anshuman Gupta (1): hdac-codec runtime suspended at PM:Suspend. sound/soc/codecs/hdac_hdmi.c | 6 ++ 1 file changed, 6 insertions(+) -- 2.7.4
[PATCH v2 0/1] cover-letter hdac-codec runtime suspended at PM:Suspend.
Current implementation of hdac hdmi codec driver uses its suspend/resume operation callback in its prepare/complete callback which has issues with hdac direct-complete, it has been reviewed earlier that hdac hdmi codec driver requires a rework (https://patchwork.kernel.org/patch/10276021/), but as there is no rework with driver, it require to fix hdac direct complete issue to leverage hdac direct complete in order to optimize its resume latency while resuming from system wide suspend. Anshuman Gupta (1): hdac-codec runtime suspended at PM:Suspend. sound/soc/codecs/hdac_hdmi.c | 6 ++ 1 file changed, 6 insertions(+) -- 2.7.4
[PATCH v4] x86: i8237: Register based on FADT legacy boot flag
From: Rajneesh Bhardwaj <rajneesh.bhard...@intel.com>
>From Skylake onwards, the platform controller hub (Sunrisepoint PCH) does
not support legacy DMA operations to IO ports 81h-83h, 87h, 89h-8Bh, 8Fh.
Currently this driver registers as syscore ops and its resume function is
called on every resume from S3. On Skylake and Kabylake, this causes a
resume delay of around 100ms due to port IO operations, which is a problem.
This change allows to load the driver only when the platform bios
explicitly supports such devices or has a cut-off date earlier than 2017
due to the following reasons:
- The platforms released before year 2017 have support for the 8237.
(except Sunrisepoint PCH e.g. Skylake)
- Some of the BIOS that were released for platforms (Skylake, Kabylake)
during 2016-17 are buggy. These BIOS do not set/unset the
ACPI_FADT_LEGACY_DEVICES field in FADT table properly based on the
presence or absence of the DMA device.
Very recently, open source system firmware like coreboot started unsetting
ACPI_FADT_LEGACY_DEVICES field in FADT table if the 8237 DMA device is not
present on the PCH.
https://github.com/coreboot/coreboot/blob/05132707ca1e13a11cd13c77326bc65011b09feb/src/soc/intel/skylake/acpi.c#L271
Please refer to chapter 21 of 6th Generation Intel® Core™ Processor
Platform Controller Hub Family: BIOS Specification.
https://www.intel.in/content/www/in/en/embedded/products/skylake/u-mobile/software-and-drivers.html
Cc: Alan Cox <a...@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gu...@intel.com>
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhard...@intel.com>
---
Changes in v4:
* Modified the commit message about cut-off date year 2017.
Changes in v3:
* Added x86_pnpbios_disabled and using it instead of pnpbios.
* Modified the commit message.
Changes in v2:
* changed to dma_inb()
---
arch/x86/include/asm/x86_init.h | 1 +
arch/x86/kernel/i8237.c | 25 +
arch/x86/kernel/platform-quirks.c | 7 ++-
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index fc2f082..b6ceac0 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -286,6 +286,7 @@ extern struct x86_msi_ops x86_msi;
extern struct x86_io_apic_ops x86_io_apic_ops;
extern void x86_early_init_platform_quirks(void);
+extern bool x86_pnpbios_disabled(void);
extern void x86_init_noop(void);
extern void x86_init_uint_noop(unsigned int unused);
diff --git a/arch/x86/kernel/i8237.c b/arch/x86/kernel/i8237.c
index 8eeaa81..0a3e70f 100644
--- a/arch/x86/kernel/i8237.c
+++ b/arch/x86/kernel/i8237.c
@@ -9,10 +9,12 @@
* your option) any later version.
*/
+#include
#include
#include
#include
+#include
/*
* This module just handles suspend/resume issues with the
@@ -49,6 +51,29 @@ static struct syscore_ops i8237_syscore_ops = {
static int __init i8237A_init_ops(void)
{
+ /*
+* From SKL PCH onwards, the legacy DMA device is removed in which the
+* I/O ports (81h-83h, 87h, 89h-8Bh, 8Fh) related to it are removed
+* as well. All removed ports must return 0xff for a inb() request.
+*
+* Note: DMA_PAGE_2 (port 0x81) should not be checked for detecting
+* the presence of DMA device since it may be used by BIOS to decode
+* LPC traffic for POST codes. Original LPC only decodes one byte of
+* port 0x80 but some BIOS may choose to enhance PCH LPC port 0x8x
+* decoding.
+*/
+ if (dma_inb(DMA_PAGE_0) == 0xFF)
+ return -ENODEV;
+
+ /*
+* It is not required to load this driver as newer SoC may not
+* support 8237 DMA or bus mastering from LPC. Platform firmware
+* must announce the support for such legacy devices via
+* ACPI_FADT_LEGACY_DEVICES field in FADT table.
+*/
+ if (x86_pnpbios_disabled() && dmi_get_bios_year() >= 2017)
+ return -ENODEV;
+
register_syscore_ops(_syscore_ops);
return 0;
}
diff --git a/arch/x86/kernel/platform-quirks.c
b/arch/x86/kernel/platform-quirks.c
index 235fe60..b348a67 100644
--- a/arch/x86/kernel/platform-quirks.c
+++ b/arch/x86/kernel/platform-quirks.c
@@ -33,9 +33,14 @@ void __init x86_early_init_platform_quirks(void)
x86_platform.set_legacy_features();
}
+bool __init x86_pnpbios_disabled(void)
+{
+ return x86_platform.legacy.devices.pnpbios == 0;
+}
+
#if defined(CONFIG_PNPBIOS)
bool __init arch_pnpbios_disabled(void)
{
- return x86_platform.legacy.devices.pnpbios == 0;
+ return x86_pnpbios_disabled();
}
#endif
--
2.7.4
[PATCH v4] x86: i8237: Register based on FADT legacy boot flag
From: Rajneesh Bhardwaj
>From Skylake onwards, the platform controller hub (Sunrisepoint PCH) does
not support legacy DMA operations to IO ports 81h-83h, 87h, 89h-8Bh, 8Fh.
Currently this driver registers as syscore ops and its resume function is
called on every resume from S3. On Skylake and Kabylake, this causes a
resume delay of around 100ms due to port IO operations, which is a problem.
This change allows to load the driver only when the platform bios
explicitly supports such devices or has a cut-off date earlier than 2017
due to the following reasons:
- The platforms released before year 2017 have support for the 8237.
(except Sunrisepoint PCH e.g. Skylake)
- Some of the BIOS that were released for platforms (Skylake, Kabylake)
during 2016-17 are buggy. These BIOS do not set/unset the
ACPI_FADT_LEGACY_DEVICES field in FADT table properly based on the
presence or absence of the DMA device.
Very recently, open source system firmware like coreboot started unsetting
ACPI_FADT_LEGACY_DEVICES field in FADT table if the 8237 DMA device is not
present on the PCH.
https://github.com/coreboot/coreboot/blob/05132707ca1e13a11cd13c77326bc65011b09feb/src/soc/intel/skylake/acpi.c#L271
Please refer to chapter 21 of 6th Generation Intel® Core™ Processor
Platform Controller Hub Family: BIOS Specification.
https://www.intel.in/content/www/in/en/embedded/products/skylake/u-mobile/software-and-drivers.html
Cc: Alan Cox
Reviewed-by: Andy Shevchenko
Signed-off-by: Anshuman Gupta
Signed-off-by: Rajneesh Bhardwaj
---
Changes in v4:
* Modified the commit message about cut-off date year 2017.
Changes in v3:
* Added x86_pnpbios_disabled and using it instead of pnpbios.
* Modified the commit message.
Changes in v2:
* changed to dma_inb()
---
arch/x86/include/asm/x86_init.h | 1 +
arch/x86/kernel/i8237.c | 25 +
arch/x86/kernel/platform-quirks.c | 7 ++-
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index fc2f082..b6ceac0 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -286,6 +286,7 @@ extern struct x86_msi_ops x86_msi;
extern struct x86_io_apic_ops x86_io_apic_ops;
extern void x86_early_init_platform_quirks(void);
+extern bool x86_pnpbios_disabled(void);
extern void x86_init_noop(void);
extern void x86_init_uint_noop(unsigned int unused);
diff --git a/arch/x86/kernel/i8237.c b/arch/x86/kernel/i8237.c
index 8eeaa81..0a3e70f 100644
--- a/arch/x86/kernel/i8237.c
+++ b/arch/x86/kernel/i8237.c
@@ -9,10 +9,12 @@
* your option) any later version.
*/
+#include
#include
#include
#include
+#include
/*
* This module just handles suspend/resume issues with the
@@ -49,6 +51,29 @@ static struct syscore_ops i8237_syscore_ops = {
static int __init i8237A_init_ops(void)
{
+ /*
+* From SKL PCH onwards, the legacy DMA device is removed in which the
+* I/O ports (81h-83h, 87h, 89h-8Bh, 8Fh) related to it are removed
+* as well. All removed ports must return 0xff for a inb() request.
+*
+* Note: DMA_PAGE_2 (port 0x81) should not be checked for detecting
+* the presence of DMA device since it may be used by BIOS to decode
+* LPC traffic for POST codes. Original LPC only decodes one byte of
+* port 0x80 but some BIOS may choose to enhance PCH LPC port 0x8x
+* decoding.
+*/
+ if (dma_inb(DMA_PAGE_0) == 0xFF)
+ return -ENODEV;
+
+ /*
+* It is not required to load this driver as newer SoC may not
+* support 8237 DMA or bus mastering from LPC. Platform firmware
+* must announce the support for such legacy devices via
+* ACPI_FADT_LEGACY_DEVICES field in FADT table.
+*/
+ if (x86_pnpbios_disabled() && dmi_get_bios_year() >= 2017)
+ return -ENODEV;
+
register_syscore_ops(_syscore_ops);
return 0;
}
diff --git a/arch/x86/kernel/platform-quirks.c
b/arch/x86/kernel/platform-quirks.c
index 235fe60..b348a67 100644
--- a/arch/x86/kernel/platform-quirks.c
+++ b/arch/x86/kernel/platform-quirks.c
@@ -33,9 +33,14 @@ void __init x86_early_init_platform_quirks(void)
x86_platform.set_legacy_features();
}
+bool __init x86_pnpbios_disabled(void)
+{
+ return x86_platform.legacy.devices.pnpbios == 0;
+}
+
#if defined(CONFIG_PNPBIOS)
bool __init arch_pnpbios_disabled(void)
{
- return x86_platform.legacy.devices.pnpbios == 0;
+ return x86_pnpbios_disabled();
}
#endif
--
2.7.4
[PATCH v3] x86: i8237: Register based on FADT legacy boot flag
From: Rajneesh Bhardwaj <rajneesh.bhard...@intel.com>
>From Skylake onwards, the platform controller hub (Sunrisepoint PCH) does
not support legacy DMA operations to IO ports 81h-83h, 87h, 89h-8Bh, 8Fh.
Currently this driver registers as syscore ops and its resume function is
called on every resume from S3. On Skylake and Kabylake, this causes a
resume delay of around 100ms due to port IO operations, which is a problem.
This change allows to load the driver only when the platform bios
explicitly supports such devices or has a cut-off date earlier than 2017.
For example open source system firmware like coreboot started unsetting
ACPI_FADT_LEGACY_DEVICES field in FADT table very recently.
https://github.com/coreboot/coreboot/blob/05132707ca1e13a11cd13c77326bc65011b09feb/src/soc/intel/skylake/acpi.c#L271
Please refer to chapter 21 of 6th Generation Intel® Core™ Processor
Platform Controller Hub Family: BIOS Specification.
https://www.intel.in/content/www/in/en/embedded/products/skylake/u-mobile/software-and-drivers.html
Cc: Alan Cox <a...@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevche...@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gu...@intel.com>
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhard...@intel.com>
---
Changes in v3:
* Added x86_pnpbios_disabled and using it instead of pnpbios.
* Modified the commit message.
Changes in v2:
* changed to dma_inb()
---
arch/x86/include/asm/x86_init.h | 1 +
arch/x86/kernel/i8237.c | 25 +
arch/x86/kernel/platform-quirks.c | 7 ++-
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index fc2f082..b6ceac0 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -286,6 +286,7 @@ extern struct x86_msi_ops x86_msi;
extern struct x86_io_apic_ops x86_io_apic_ops;
extern void x86_early_init_platform_quirks(void);
+extern bool x86_pnpbios_disabled(void);
extern void x86_init_noop(void);
extern void x86_init_uint_noop(unsigned int unused);
diff --git a/arch/x86/kernel/i8237.c b/arch/x86/kernel/i8237.c
index 8eeaa81..0a3e70f 100644
--- a/arch/x86/kernel/i8237.c
+++ b/arch/x86/kernel/i8237.c
@@ -9,10 +9,12 @@
* your option) any later version.
*/
+#include
#include
#include
#include
+#include
/*
* This module just handles suspend/resume issues with the
@@ -49,6 +51,29 @@ static struct syscore_ops i8237_syscore_ops = {
static int __init i8237A_init_ops(void)
{
+ /*
+* From SKL PCH onwards, the legacy DMA device is removed in which the
+* I/O ports (81h-83h, 87h, 89h-8Bh, 8Fh) related to it are removed
+* as well. All removed ports must return 0xff for a inb() request.
+*
+* Note: DMA_PAGE_2 (port 0x81) should not be checked for detecting
+* the presence of DMA device since it may be used by BIOS to decode
+* LPC traffic for POST codes. Original LPC only decodes one byte of
+* port 0x80 but some BIOS may choose to enhance PCH LPC port 0x8x
+* decoding.
+*/
+ if (dma_inb(DMA_PAGE_0) == 0xFF)
+ return -ENODEV;
+
+ /*
+* It is not required to load this driver as newer SoC may not
+* support 8237 DMA or bus mastering from LPC. Platform firmware
+* must announce the support for such legacy devices via
+* ACPI_FADT_LEGACY_DEVICES field in FADT table.
+*/
+ if (x86_pnpbios_disabled() && dmi_get_bios_year() >= 2017)
+ return -ENODEV;
+
register_syscore_ops(_syscore_ops);
return 0;
}
diff --git a/arch/x86/kernel/platform-quirks.c
b/arch/x86/kernel/platform-quirks.c
index 235fe60..b348a67 100644
--- a/arch/x86/kernel/platform-quirks.c
+++ b/arch/x86/kernel/platform-quirks.c
@@ -33,9 +33,14 @@ void __init x86_early_init_platform_quirks(void)
x86_platform.set_legacy_features();
}
+bool __init x86_pnpbios_disabled(void)
+{
+ return x86_platform.legacy.devices.pnpbios == 0;
+}
+
#if defined(CONFIG_PNPBIOS)
bool __init arch_pnpbios_disabled(void)
{
- return x86_platform.legacy.devices.pnpbios == 0;
+ return x86_pnpbios_disabled();
}
#endif
--
2.7.4
[PATCH v3] x86: i8237: Register based on FADT legacy boot flag
From: Rajneesh Bhardwaj
>From Skylake onwards, the platform controller hub (Sunrisepoint PCH) does
not support legacy DMA operations to IO ports 81h-83h, 87h, 89h-8Bh, 8Fh.
Currently this driver registers as syscore ops and its resume function is
called on every resume from S3. On Skylake and Kabylake, this causes a
resume delay of around 100ms due to port IO operations, which is a problem.
This change allows to load the driver only when the platform bios
explicitly supports such devices or has a cut-off date earlier than 2017.
For example open source system firmware like coreboot started unsetting
ACPI_FADT_LEGACY_DEVICES field in FADT table very recently.
https://github.com/coreboot/coreboot/blob/05132707ca1e13a11cd13c77326bc65011b09feb/src/soc/intel/skylake/acpi.c#L271
Please refer to chapter 21 of 6th Generation Intel® Core™ Processor
Platform Controller Hub Family: BIOS Specification.
https://www.intel.in/content/www/in/en/embedded/products/skylake/u-mobile/software-and-drivers.html
Cc: Alan Cox
Reviewed-by: Andy Shevchenko
Signed-off-by: Anshuman Gupta
Signed-off-by: Rajneesh Bhardwaj
---
Changes in v3:
* Added x86_pnpbios_disabled and using it instead of pnpbios.
* Modified the commit message.
Changes in v2:
* changed to dma_inb()
---
arch/x86/include/asm/x86_init.h | 1 +
arch/x86/kernel/i8237.c | 25 +
arch/x86/kernel/platform-quirks.c | 7 ++-
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index fc2f082..b6ceac0 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -286,6 +286,7 @@ extern struct x86_msi_ops x86_msi;
extern struct x86_io_apic_ops x86_io_apic_ops;
extern void x86_early_init_platform_quirks(void);
+extern bool x86_pnpbios_disabled(void);
extern void x86_init_noop(void);
extern void x86_init_uint_noop(unsigned int unused);
diff --git a/arch/x86/kernel/i8237.c b/arch/x86/kernel/i8237.c
index 8eeaa81..0a3e70f 100644
--- a/arch/x86/kernel/i8237.c
+++ b/arch/x86/kernel/i8237.c
@@ -9,10 +9,12 @@
* your option) any later version.
*/
+#include
#include
#include
#include
+#include
/*
* This module just handles suspend/resume issues with the
@@ -49,6 +51,29 @@ static struct syscore_ops i8237_syscore_ops = {
static int __init i8237A_init_ops(void)
{
+ /*
+* From SKL PCH onwards, the legacy DMA device is removed in which the
+* I/O ports (81h-83h, 87h, 89h-8Bh, 8Fh) related to it are removed
+* as well. All removed ports must return 0xff for a inb() request.
+*
+* Note: DMA_PAGE_2 (port 0x81) should not be checked for detecting
+* the presence of DMA device since it may be used by BIOS to decode
+* LPC traffic for POST codes. Original LPC only decodes one byte of
+* port 0x80 but some BIOS may choose to enhance PCH LPC port 0x8x
+* decoding.
+*/
+ if (dma_inb(DMA_PAGE_0) == 0xFF)
+ return -ENODEV;
+
+ /*
+* It is not required to load this driver as newer SoC may not
+* support 8237 DMA or bus mastering from LPC. Platform firmware
+* must announce the support for such legacy devices via
+* ACPI_FADT_LEGACY_DEVICES field in FADT table.
+*/
+ if (x86_pnpbios_disabled() && dmi_get_bios_year() >= 2017)
+ return -ENODEV;
+
register_syscore_ops(_syscore_ops);
return 0;
}
diff --git a/arch/x86/kernel/platform-quirks.c
b/arch/x86/kernel/platform-quirks.c
index 235fe60..b348a67 100644
--- a/arch/x86/kernel/platform-quirks.c
+++ b/arch/x86/kernel/platform-quirks.c
@@ -33,9 +33,14 @@ void __init x86_early_init_platform_quirks(void)
x86_platform.set_legacy_features();
}
+bool __init x86_pnpbios_disabled(void)
+{
+ return x86_platform.legacy.devices.pnpbios == 0;
+}
+
#if defined(CONFIG_PNPBIOS)
bool __init arch_pnpbios_disabled(void)
{
- return x86_platform.legacy.devices.pnpbios == 0;
+ return x86_pnpbios_disabled();
}
#endif
--
2.7.4
[PATCH] [sound] hdac-codec runtime suspended at PM:Suspend.
Keep hdac-codec to be in runtime suspended while entering to suspend. If hdac-codec is already in runtime suspend state skip its power down sequence in prepare, power up sequence in complete phase. Avoid resuming hdac controller PCI device 00:1f.3 from runtime suspend state in case hdac-codec already in runtime-suspend state, this is unnecessary and block the direct complete even for hdac controller PCI device 00:1f.3. This enabled direct complete path for hdac-codec and PCI device 00:1f.3. Signed-off-by: Anshuman Gupta <anshuman.gu...@intel.com> --- sound/soc/codecs/hdac_hdmi.c | 4 1 file changed, 4 insertions(+) diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index f3b4f4d..810a8a6 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -1852,6 +1852,8 @@ static int hdmi_codec_prepare(struct device *dev) struct hdac_ext_device *edev = to_hda_ext_device(dev); struct hdac_device *hdac = >hdac; + if (pm_runtime_status_suspended(dev)) + return 1; pm_runtime_get_sync(>hdac.dev); /* @@ -1873,6 +1875,8 @@ static void hdmi_codec_complete(struct device *dev) struct hdac_hdmi_priv *hdmi = edev->private_data; struct hdac_device *hdac = >hdac; + if (pm_runtime_status_suspended(dev)) + return; /* Power up afg */ snd_hdac_codec_read(hdac, hdac->afg, 0, AC_VERB_SET_POWER_STATE, AC_PWRST_D0); -- 2.7.4
[PATCH] [sound] hdac-codec runtime suspended at PM:Suspend.
Keep hdac-codec to be in runtime suspended while entering to suspend. If hdac-codec is already in runtime suspend state skip its power down sequence in prepare, power up sequence in complete phase. Avoid resuming hdac controller PCI device 00:1f.3 from runtime suspend state in case hdac-codec already in runtime-suspend state, this is unnecessary and block the direct complete even for hdac controller PCI device 00:1f.3. This enabled direct complete path for hdac-codec and PCI device 00:1f.3. Signed-off-by: Anshuman Gupta --- sound/soc/codecs/hdac_hdmi.c | 4 1 file changed, 4 insertions(+) diff --git a/sound/soc/codecs/hdac_hdmi.c b/sound/soc/codecs/hdac_hdmi.c index f3b4f4d..810a8a6 100644 --- a/sound/soc/codecs/hdac_hdmi.c +++ b/sound/soc/codecs/hdac_hdmi.c @@ -1852,6 +1852,8 @@ static int hdmi_codec_prepare(struct device *dev) struct hdac_ext_device *edev = to_hda_ext_device(dev); struct hdac_device *hdac = >hdac; + if (pm_runtime_status_suspended(dev)) + return 1; pm_runtime_get_sync(>hdac.dev); /* @@ -1873,6 +1875,8 @@ static void hdmi_codec_complete(struct device *dev) struct hdac_hdmi_priv *hdmi = edev->private_data; struct hdac_device *hdac = >hdac; + if (pm_runtime_status_suspended(dev)) + return; /* Power up afg */ snd_hdac_codec_read(hdac, hdac->afg, 0, AC_VERB_SET_POWER_STATE, AC_PWRST_D0); -- 2.7.4
[PATCH v2] USB: xhci: reducing HS port auto-resume latency.
From: Anshuman Gupta <anshuman.gu...@intel.com> This patch will improve the variable auto-resume latency of an usb-port. When xhci gets a HS port status change event interrupt due to PORT_PLC (port link state transition), linux Host controller driver drives the resume signalling on the bus for the amount of time defined by USB_RESUME_TIMEOUT(40ms) macro. This 40ms delay for resume signalling is in acceptable limit, but it get worse when xhci goes for polling mode in order to detect other events on its ports and modify rh_timer timer with a variable time out of 1ms to (HZ/4)ms. drivers/usb/core/hcd.c line 799 mod_timer (>rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)). Due to above variable timeout usb auto-resume latency varies from 40ms to ~300ms(when HZ=1000). Log Snippet: ~128ms latency [ 53.112049] hub 1-0:1.0: state 7 ports 12 chg evt [ 53.229200] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 53.240177] usb 1-2: usb wakeup-resume [ 53.240195] usb 1-2: finish resume [ 53.240357] usb usb1-port2: resume, status 0 - ~300ms latency [ 59.946620] hub 1-0:1.0: state 7 ports 12 chg evt [ 59.979341] hub 1-0:1.0: state 7 ports 12 chg evt [ 60.229342] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 60.251321] usb 1-2: usb wakeup-resume [ 60.251335] usb 1-2: finish resume [ 60.251539] usb usb1-port2: resume, status 0 xhci bug behind the higher latency: When HS port is resuming, xhci passes the resume event to hub event thread after USB_RESUME_TIMEOUT delay. it modify rh_timer with USB_RESUME_TIMEOUT delay, and set the polling mode flag and invoke usb_hcd_poll_rh_status() function manually. This eventually makes hub event thread to read the HS port status before it resumes, since polling mode flag is set, host controller driver modify rh_timer again with (HZ/4)ms delay, This makes hub event thread to wait for (HZ/4)ms. which causes higher auto-resume latency. This variable resume latency can be optimized, as in case of HS port resume event rh_timer has already been modified with USB_RESUME_TIMEOUT (40ms) delay, leaving the rest to GetPortStatus. We can avoid calling usb_hcd_poll_rh_status() function manually in case of HS port resume event. This patch set the HCD_FLAG_POLL_RH to hcd->flags after modification of rh_timer, and avoid calling usb_hcd_poll_rh_status(), This makes to call usb_hcd_poll_rh_status() by rh_timer and passing the HS port resume event to hub event thread after USB_RESUME_TIMEOUT delay. Signed-off-by: Anshuman Gupta <anshuman.gu...@intel.com> --- Changes in v2 - Make the commit message more clearer. - Changing the comment. drivers/usb/host/xhci-ring.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index cc368ad..0bccff1 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1677,9 +1677,14 @@ static void handle_port_status(struct xhci_hcd *xhci, bus_state->resume_done[faked_port_index] = jiffies + msecs_to_jiffies(USB_RESUME_TIMEOUT); set_bit(faked_port_index, _state->resuming_ports); + /* Do the rest in GetPortStatus after resume time delay. +* Avoid calling usb_hcd_poll_rh_status before that,so +* an usb port can auto-resume after resume time delay. +*/ + set_bit(HCD_FLAG_POLL_RH, >flags); mod_timer(>rh_timer, bus_state->resume_done[faked_port_index]); - /* Do the rest in GetPortStatus */ + bogus_port_status = true; } } -- 2.7.4
[PATCH v2] USB: xhci: reducing HS port auto-resume latency.
From: Anshuman Gupta This patch will improve the variable auto-resume latency of an usb-port. When xhci gets a HS port status change event interrupt due to PORT_PLC (port link state transition), linux Host controller driver drives the resume signalling on the bus for the amount of time defined by USB_RESUME_TIMEOUT(40ms) macro. This 40ms delay for resume signalling is in acceptable limit, but it get worse when xhci goes for polling mode in order to detect other events on its ports and modify rh_timer timer with a variable time out of 1ms to (HZ/4)ms. drivers/usb/core/hcd.c line 799 mod_timer (>rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)). Due to above variable timeout usb auto-resume latency varies from 40ms to ~300ms(when HZ=1000). Log Snippet: ~128ms latency [ 53.112049] hub 1-0:1.0: state 7 ports 12 chg evt [ 53.229200] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 53.240177] usb 1-2: usb wakeup-resume [ 53.240195] usb 1-2: finish resume [ 53.240357] usb usb1-port2: resume, status 0 - ~300ms latency [ 59.946620] hub 1-0:1.0: state 7 ports 12 chg evt [ 59.979341] hub 1-0:1.0: state 7 ports 12 chg evt [ 60.229342] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 60.251321] usb 1-2: usb wakeup-resume [ 60.251335] usb 1-2: finish resume [ 60.251539] usb usb1-port2: resume, status 0 xhci bug behind the higher latency: When HS port is resuming, xhci passes the resume event to hub event thread after USB_RESUME_TIMEOUT delay. it modify rh_timer with USB_RESUME_TIMEOUT delay, and set the polling mode flag and invoke usb_hcd_poll_rh_status() function manually. This eventually makes hub event thread to read the HS port status before it resumes, since polling mode flag is set, host controller driver modify rh_timer again with (HZ/4)ms delay, This makes hub event thread to wait for (HZ/4)ms. which causes higher auto-resume latency. This variable resume latency can be optimized, as in case of HS port resume event rh_timer has already been modified with USB_RESUME_TIMEOUT (40ms) delay, leaving the rest to GetPortStatus. We can avoid calling usb_hcd_poll_rh_status() function manually in case of HS port resume event. This patch set the HCD_FLAG_POLL_RH to hcd->flags after modification of rh_timer, and avoid calling usb_hcd_poll_rh_status(), This makes to call usb_hcd_poll_rh_status() by rh_timer and passing the HS port resume event to hub event thread after USB_RESUME_TIMEOUT delay. Signed-off-by: Anshuman Gupta --- Changes in v2 - Make the commit message more clearer. - Changing the comment. drivers/usb/host/xhci-ring.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index cc368ad..0bccff1 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1677,9 +1677,14 @@ static void handle_port_status(struct xhci_hcd *xhci, bus_state->resume_done[faked_port_index] = jiffies + msecs_to_jiffies(USB_RESUME_TIMEOUT); set_bit(faked_port_index, _state->resuming_ports); + /* Do the rest in GetPortStatus after resume time delay. +* Avoid calling usb_hcd_poll_rh_status before that,so +* an usb port can auto-resume after resume time delay. +*/ + set_bit(HCD_FLAG_POLL_RH, >flags); mod_timer(>rh_timer, bus_state->resume_done[faked_port_index]); - /* Do the rest in GetPortStatus */ + bogus_port_status = true; } } -- 2.7.4
[PATCH] usb: reducing an usb-port auto-resume latency.
From: Anshuman Gupta <anshuman.gu...@intel.com> This patch will improve the variable auto-resume latency of an usb-port. When xhci gets a port status change event interrupt due to PORT_PLC (port link state transition), linux Host controller driver drives the resume signalling on the bus for the amount of time defined by USB_REUME_TIMEOUT(40ms) macro. This 40ms delay for resume signalling is in acceptable limit, but it get worse when xhci goes for polling mode in order to detect other events on its ports and modify rh_timer timer with a variable time out of 1ms to (HZ/4)ms. drivers/usb/core/hcd.c line 799 mod_timer (>rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)). Due to above variable timeout usb auto-resume latency varies from 40ms to ~300ms. Log Snippet: ~128ms latency [ 53.112049] hub 1-0:1.0: state 7 ports 12 chg evt [ 53.229200] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 53.240177] usb 1-2: usb wakeup-resume [ 53.240195] usb 1-2: finish resume [ 53.240357] usb usb1-port2: resume, status 0 - ~300ms latency [ 59.946620] hub 1-0:1.0: state 7 ports 12 chg evt [ 59.979341] hub 1-0:1.0: state 7 ports 12 chg evt [ 60.229342] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 60.251321] usb 1-2: usb wakeup-resume [ 60.251335] usb 1-2: finish resume [ 60.251539] usb usb1-port2: resume, status 0 This variable resume latency can be optimized, as in case of PORT_PLC change event rh_timer has already been modified with USB_RESUME_TIMEOUT (40ms) delay,leaving the rest to GetPortStatus and started polling for root hub status (invoking usb_hcd_poll_rh_status). We can avoid polling as we have already modified rh_timer with delay of 40ms. This patch set the HCD_FLAG_POLL_RH to hcd->flags after modification of rh_timer, and avoids polling of root hub status. so rh_timer can fire after 40ms and usb device auto-resuem latency will be around 40ms. Signed-off-by: Anshuman Gupta <anshuman.gu...@intel.com> --- drivers/usb/host/xhci-ring.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index cc368ad..3b7349a 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1677,9 +1677,14 @@ static void handle_port_status(struct xhci_hcd *xhci, bus_state->resume_done[faked_port_index] = jiffies + msecs_to_jiffies(USB_RESUME_TIMEOUT); set_bit(faked_port_index, _state->resuming_ports); + /* Do the rest in GetPortStatus after resume time delay. +* Avoid polling roothub status before that so that a +* usb device auto-resume latency around ~40ms. +*/ + set_bit(HCD_FLAG_POLL_RH, >flags); mod_timer(>rh_timer, bus_state->resume_done[faked_port_index]); - /* Do the rest in GetPortStatus */ + bogus_port_status = true; } } -- 2.7.4
[PATCH] usb: reducing an usb-port auto-resume latency.
From: Anshuman Gupta This patch will improve the variable auto-resume latency of an usb-port. When xhci gets a port status change event interrupt due to PORT_PLC (port link state transition), linux Host controller driver drives the resume signalling on the bus for the amount of time defined by USB_REUME_TIMEOUT(40ms) macro. This 40ms delay for resume signalling is in acceptable limit, but it get worse when xhci goes for polling mode in order to detect other events on its ports and modify rh_timer timer with a variable time out of 1ms to (HZ/4)ms. drivers/usb/core/hcd.c line 799 mod_timer (>rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4)). Due to above variable timeout usb auto-resume latency varies from 40ms to ~300ms. Log Snippet: ~128ms latency [ 53.112049] hub 1-0:1.0: state 7 ports 12 chg evt [ 53.229200] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 53.240177] usb 1-2: usb wakeup-resume [ 53.240195] usb 1-2: finish resume [ 53.240357] usb usb1-port2: resume, status 0 - ~300ms latency [ 59.946620] hub 1-0:1.0: state 7 ports 12 chg evt [ 59.979341] hub 1-0:1.0: state 7 ports 12 chg evt [ 60.229342] hub 1-0:1.0: state 7 ports 12 chg evt 0004 [ 60.251321] usb 1-2: usb wakeup-resume [ 60.251335] usb 1-2: finish resume [ 60.251539] usb usb1-port2: resume, status 0 This variable resume latency can be optimized, as in case of PORT_PLC change event rh_timer has already been modified with USB_RESUME_TIMEOUT (40ms) delay,leaving the rest to GetPortStatus and started polling for root hub status (invoking usb_hcd_poll_rh_status). We can avoid polling as we have already modified rh_timer with delay of 40ms. This patch set the HCD_FLAG_POLL_RH to hcd->flags after modification of rh_timer, and avoids polling of root hub status. so rh_timer can fire after 40ms and usb device auto-resuem latency will be around 40ms. Signed-off-by: Anshuman Gupta --- drivers/usb/host/xhci-ring.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index cc368ad..3b7349a 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1677,9 +1677,14 @@ static void handle_port_status(struct xhci_hcd *xhci, bus_state->resume_done[faked_port_index] = jiffies + msecs_to_jiffies(USB_RESUME_TIMEOUT); set_bit(faked_port_index, _state->resuming_ports); + /* Do the rest in GetPortStatus after resume time delay. +* Avoid polling roothub status before that so that a +* usb device auto-resume latency around ~40ms. +*/ + set_bit(HCD_FLAG_POLL_RH, >flags); mod_timer(>rh_timer, bus_state->resume_done[faked_port_index]); - /* Do the rest in GetPortStatus */ + bogus_port_status = true; } } -- 2.7.4
Re: [PATCH] populate platform device at late init
>You should generally test with something not ancient, It has been tested with 4.7 kernel too, board was booted but it can not verified further as 4.7 vanilla kernel does not launched shell prompt with udoo board, well this can be done. >Sorry, but this approach is never going to be accepted. Similar things >have come up for boot time optimizations. This needs to be part of >more general tracking of functional dependencies (e.g. camera depends >on i2c). Once we have that, then we can prioritize what to init first >(e.g. camera). I understands that approach is not correct but can you please elaborate or give any pointer to the approach mention by you ,"This needs to be part of more general tracking of functional dependencies". As there is scope of boot up time optimization. Thanks, Anshuman Gupta On Fri, Aug 19, 2016 at 6:28 AM, Rob Herring <robh...@kernel.org> wrote: > On Thu, Aug 18, 2016 at 1:55 PM, Anshuman Gupta <ansh...@gmail.com> wrote: >> This patch enables to populate platform devices from device tree at late-init >> As of now linux kernel has late-init call infrastructure which make a >> driver/module >> init call at late-init.it is not specific to a platform device. >> This patch make a platform device to be probe at late-init, >> without making its driver a late-init call. >> >> This will be useful in certain scenario when we have multiple instances of >> similar >> platform devices and it is ok to defer specific device to late-init among >> the multiple >> instance of similar devices. >> >> Currently ARM based SOC has multiple instance of similar modules/controller >> (i2c,uart,mmc controller), so for each module/controller device will get >> probe and >> initialized at early boot, but for some instances of device it may not be >> needful >> to be initialized it at early boot-up. If we can defer these device >> probe/initialization at post init, it can improve boot up time with respect >> to other >> system component.It can be useful in Linux based automotive infotainment >> platform, >> where we need camera functionality (reverse view camera) as early as >> possible. >> >> Example: if we have 4 i2c controller(i2c0~i2c3) and i2c0 controller is being >> used >> by a camera driver,if camera driver is required at early boot then i2c >> controller driver >> can not be initialized at late-init and i2c0 controller need to probe before >> camera driver, >> but this force other i2c controller devices also to be probe at early >> boot-up itself, >> which may not be really required. >> This patch tested on freescale imx6 udoo quad board with kernel version >> 3.14.56. > > You should generally test with something not ancient, but... > >> Patch is made against 4.7 kernel. >> >> In order to probe a platform device at late-init, we need to declare a >> late_init >> property at desired device tree node, and invoke >> of_platform_populate_late_nodes exported >> function call from desired board file init_late machine descriptor function. > > Sorry, but this approach is never going to be accepted. Similar things > have come up for boot time optimizations. This needs to be part of > more general tracking of functional dependencies (e.g. camera depends > on i2c). Once we have that, then we can prioritize what to init first > (e.g. camera). > >> Following files has been changed for this patch >> drivers/of/Kconfig >> drivers/of/base.c >> drivers/of/platform.c >> include/linux/of.h >> include/linux/of_platform.h > > Not useful information in the commit msg because it is generated right here: > >> drivers/of/Kconfig | 7 +++ >> drivers/of/base.c | 21 + >> drivers/of/platform.c | 109 >> >> include/linux/of.h | 3 ++ >> include/linux/of_platform.h | 14 ++ >> 5 files changed, 154 insertions(+)
Re: [PATCH] populate platform device at late init
>You should generally test with something not ancient, It has been tested with 4.7 kernel too, board was booted but it can not verified further as 4.7 vanilla kernel does not launched shell prompt with udoo board, well this can be done. >Sorry, but this approach is never going to be accepted. Similar things >have come up for boot time optimizations. This needs to be part of >more general tracking of functional dependencies (e.g. camera depends >on i2c). Once we have that, then we can prioritize what to init first >(e.g. camera). I understands that approach is not correct but can you please elaborate or give any pointer to the approach mention by you ,"This needs to be part of more general tracking of functional dependencies". As there is scope of boot up time optimization. Thanks, Anshuman Gupta On Fri, Aug 19, 2016 at 6:28 AM, Rob Herring wrote: > On Thu, Aug 18, 2016 at 1:55 PM, Anshuman Gupta wrote: >> This patch enables to populate platform devices from device tree at late-init >> As of now linux kernel has late-init call infrastructure which make a >> driver/module >> init call at late-init.it is not specific to a platform device. >> This patch make a platform device to be probe at late-init, >> without making its driver a late-init call. >> >> This will be useful in certain scenario when we have multiple instances of >> similar >> platform devices and it is ok to defer specific device to late-init among >> the multiple >> instance of similar devices. >> >> Currently ARM based SOC has multiple instance of similar modules/controller >> (i2c,uart,mmc controller), so for each module/controller device will get >> probe and >> initialized at early boot, but for some instances of device it may not be >> needful >> to be initialized it at early boot-up. If we can defer these device >> probe/initialization at post init, it can improve boot up time with respect >> to other >> system component.It can be useful in Linux based automotive infotainment >> platform, >> where we need camera functionality (reverse view camera) as early as >> possible. >> >> Example: if we have 4 i2c controller(i2c0~i2c3) and i2c0 controller is being >> used >> by a camera driver,if camera driver is required at early boot then i2c >> controller driver >> can not be initialized at late-init and i2c0 controller need to probe before >> camera driver, >> but this force other i2c controller devices also to be probe at early >> boot-up itself, >> which may not be really required. >> This patch tested on freescale imx6 udoo quad board with kernel version >> 3.14.56. > > You should generally test with something not ancient, but... > >> Patch is made against 4.7 kernel. >> >> In order to probe a platform device at late-init, we need to declare a >> late_init >> property at desired device tree node, and invoke >> of_platform_populate_late_nodes exported >> function call from desired board file init_late machine descriptor function. > > Sorry, but this approach is never going to be accepted. Similar things > have come up for boot time optimizations. This needs to be part of > more general tracking of functional dependencies (e.g. camera depends > on i2c). Once we have that, then we can prioritize what to init first > (e.g. camera). > >> Following files has been changed for this patch >> drivers/of/Kconfig >> drivers/of/base.c >> drivers/of/platform.c >> include/linux/of.h >> include/linux/of_platform.h > > Not useful information in the commit msg because it is generated right here: > >> drivers/of/Kconfig | 7 +++ >> drivers/of/base.c | 21 + >> drivers/of/platform.c | 109 >> >> include/linux/of.h | 3 ++ >> include/linux/of_platform.h | 14 ++ >> 5 files changed, 154 insertions(+)
[PATCH] populate platform device at late init
This patch enables to populate platform devices from device tree at late-init
As of now linux kernel has late-init call infrastructure which make a
driver/module
init call at late-init.it is not specific to a platform device.
This patch make a platform device to be probe at late-init,
without making its driver a late-init call.
This will be useful in certain scenario when we have multiple instances of
similar
platform devices and it is ok to defer specific device to late-init among the
multiple
instance of similar devices.
Currently ARM based SOC has multiple instance of similar modules/controller
(i2c,uart,mmc controller), so for each module/controller device will get probe
and
initialized at early boot, but for some instances of device it may not be
needful
to be initialized it at early boot-up. If we can defer these device
probe/initialization at post init, it can improve boot up time with respect to
other
system component.It can be useful in Linux based automotive infotainment
platform,
where we need camera functionality (reverse view camera) as early as possible.
Example: if we have 4 i2c controller(i2c0~i2c3) and i2c0 controller is being
used
by a camera driver,if camera driver is required at early boot then i2c
controller driver
can not be initialized at late-init and i2c0 controller need to probe before
camera driver,
but this force other i2c controller devices also to be probe at early boot-up
itself,
which may not be really required.
This patch tested on freescale imx6 udoo quad board with kernel version 3.14.56.
Patch is made against 4.7 kernel.
In order to probe a platform device at late-init, we need to declare a late_init
property at desired device tree node, and invoke
of_platform_populate_late_nodes exported
function call from desired board file init_late machine descriptor function.
Following files has been changed for this patch
drivers/of/Kconfig
drivers/of/base.c
drivers/of/platform.c
include/linux/of.h
include/linux/of_platform.h
Signed-off-by: Anshuman Gupta <ansh...@gmail.com>
---
drivers/of/Kconfig | 7 +++
drivers/of/base.c | 21 +
drivers/of/platform.c | 109
include/linux/of.h | 3 ++
include/linux/of_platform.h | 14 ++
5 files changed, 154 insertions(+)
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index bc07ad3..c8443f5 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -63,6 +63,13 @@ config OF_ADDRESS
config OF_ADDRESS_PCI
bool
+config OF_LATE_NODES
+ def_bool n
+ depends on OF_ADDRESS
+ help
+This option makes probe of certain device nodes at late init,
+whichever device nodes have a late_init property true.
+
config OF_IRQ
def_bool y
depends on !SPARC && IRQ_DOMAIN
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 7792266..c40e9a7 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -304,6 +304,7 @@ const void *__of_get_property(const struct device_node *np,
return pp ? pp->value : NULL;
}
+
/*
* Find a property with a given name for a given node
* and return the value.
@@ -317,6 +318,26 @@ const void *of_get_property(const struct device_node *np,
const char *name,
}
EXPORT_SYMBOL(of_get_property);
+int of_set_property(const struct device_node *np, const char *name,
+ const void *val, int len)
+{
+ struct property *pp;
+ int lenp;
+
+ if (!np)
+ return -ENOENT;
+
+ pp = of_find_property(np, name, );
+ if (pp) {
+ memcpy(pp->value, val, len);
+ pp->length = len;
+ }
+ else
+ return -ENOENT;
+ return 0;
+
+}
+EXPORT_SYMBOL(of_set_property);
/*
* arch_match_cpu_phys_id - Match the given logical CPU and physical id
*
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 765390e..2f6bcb4 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -64,6 +64,11 @@ EXPORT_SYMBOL(of_find_device_by_node);
* mechanism for creating devices from device tree nodes.
*/
+#ifdef CONFIG_OF_LATE_NODES
+static LIST_HEAD(late_device_node_list);
+static int of_add_late_device_node(struct device_node *bus,
+ struct device *parent);
+#endif
/**
* of_device_make_bus_id - Use the device node data to assign a unique name
* @dev: pointer to device structure that is linked to a device tree node
@@ -368,6 +373,12 @@ static int of_platform_bus_create(struct device_node *bus,
return 0;
}
+#ifdef CONFIG_OF_LATE_NODES
+ if (of_device_is_late_node(bus)) {
+ of_add_late_device_node(bus, parent);
+ return 0;
+ }
+#endif
auxdata = of_dev_lookup(lookup, bus);
if (auxdata) {
bus_id = auxdata->name;
[PATCH] populate platform device at late init
This patch enables to populate platform devices from device tree at late-init
As of now linux kernel has late-init call infrastructure which make a
driver/module
init call at late-init.it is not specific to a platform device.
This patch make a platform device to be probe at late-init,
without making its driver a late-init call.
This will be useful in certain scenario when we have multiple instances of
similar
platform devices and it is ok to defer specific device to late-init among the
multiple
instance of similar devices.
Currently ARM based SOC has multiple instance of similar modules/controller
(i2c,uart,mmc controller), so for each module/controller device will get probe
and
initialized at early boot, but for some instances of device it may not be
needful
to be initialized it at early boot-up. If we can defer these device
probe/initialization at post init, it can improve boot up time with respect to
other
system component.It can be useful in Linux based automotive infotainment
platform,
where we need camera functionality (reverse view camera) as early as possible.
Example: if we have 4 i2c controller(i2c0~i2c3) and i2c0 controller is being
used
by a camera driver,if camera driver is required at early boot then i2c
controller driver
can not be initialized at late-init and i2c0 controller need to probe before
camera driver,
but this force other i2c controller devices also to be probe at early boot-up
itself,
which may not be really required.
This patch tested on freescale imx6 udoo quad board with kernel version 3.14.56.
Patch is made against 4.7 kernel.
In order to probe a platform device at late-init, we need to declare a late_init
property at desired device tree node, and invoke
of_platform_populate_late_nodes exported
function call from desired board file init_late machine descriptor function.
Following files has been changed for this patch
drivers/of/Kconfig
drivers/of/base.c
drivers/of/platform.c
include/linux/of.h
include/linux/of_platform.h
Signed-off-by: Anshuman Gupta
---
drivers/of/Kconfig | 7 +++
drivers/of/base.c | 21 +
drivers/of/platform.c | 109
include/linux/of.h | 3 ++
include/linux/of_platform.h | 14 ++
5 files changed, 154 insertions(+)
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index bc07ad3..c8443f5 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -63,6 +63,13 @@ config OF_ADDRESS
config OF_ADDRESS_PCI
bool
+config OF_LATE_NODES
+ def_bool n
+ depends on OF_ADDRESS
+ help
+This option makes probe of certain device nodes at late init,
+whichever device nodes have a late_init property true.
+
config OF_IRQ
def_bool y
depends on !SPARC && IRQ_DOMAIN
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 7792266..c40e9a7 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -304,6 +304,7 @@ const void *__of_get_property(const struct device_node *np,
return pp ? pp->value : NULL;
}
+
/*
* Find a property with a given name for a given node
* and return the value.
@@ -317,6 +318,26 @@ const void *of_get_property(const struct device_node *np,
const char *name,
}
EXPORT_SYMBOL(of_get_property);
+int of_set_property(const struct device_node *np, const char *name,
+ const void *val, int len)
+{
+ struct property *pp;
+ int lenp;
+
+ if (!np)
+ return -ENOENT;
+
+ pp = of_find_property(np, name, );
+ if (pp) {
+ memcpy(pp->value, val, len);
+ pp->length = len;
+ }
+ else
+ return -ENOENT;
+ return 0;
+
+}
+EXPORT_SYMBOL(of_set_property);
/*
* arch_match_cpu_phys_id - Match the given logical CPU and physical id
*
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 765390e..2f6bcb4 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -64,6 +64,11 @@ EXPORT_SYMBOL(of_find_device_by_node);
* mechanism for creating devices from device tree nodes.
*/
+#ifdef CONFIG_OF_LATE_NODES
+static LIST_HEAD(late_device_node_list);
+static int of_add_late_device_node(struct device_node *bus,
+ struct device *parent);
+#endif
/**
* of_device_make_bus_id - Use the device node data to assign a unique name
* @dev: pointer to device structure that is linked to a device tree node
@@ -368,6 +373,12 @@ static int of_platform_bus_create(struct device_node *bus,
return 0;
}
+#ifdef CONFIG_OF_LATE_NODES
+ if (of_device_is_late_node(bus)) {
+ of_add_late_device_node(bus, parent);
+ return 0;
+ }
+#endif
auxdata = of_dev_lookup(lookup, bus);
if (auxdata) {
bus_id = auxdata->name;
@@ -614,4 +625,102 @@ void of_platform_register_re
