* [PATCH v2 1/4] dmaengine: xilinx_dma: populate dma caps properly
From: Appana Durga Kedareswara Rao @ 2018-01-08 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108103845.GE18649@localhost>
Hi Vinod,
Thanks for the review....
<Snip>
>> @@ -2398,6 +2398,7 @@ static int xilinx_dma_chan_probe(struct
>xilinx_dma_device *xdev,
>> chan->direction = DMA_MEM_TO_DEV;
>> chan->id = chan_id;
>> chan->tdest = chan_id;
>> + xdev->common.directions = BIT(DMA_MEM_TO_DEV);
>>
>> chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
>> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) { @@ -
>2415,6
>> +2416,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
>> chan->direction = DMA_DEV_TO_MEM;
>> chan->id = chan_id;
>> chan->tdest = chan_id - xdev->nr_channels;
>> + xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
>>
>> chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
>> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) { @@ -
>2629,6
>> +2631,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
>> dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
>> }
>>
>> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
>> + xdev->common.src_addr_widths = BIT(addr_width / 8);
>
>Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers? What is value
>of addr_width here typically? Usually controllers can support different widths and
>this is a surprise that you support only one value
Controller supports address width of 32 and 64.
addr_width typical values are 32-bit or 64-bit .
Here addr_width is device-tree parameter...
my understanding of src_addr_widths/dst_addr_widths is, it is a bit mask of the
address with in bytes that DMA supports, please correct if my understanding is wrong.
Regards,
Kedar.
>
>--
>~Vinod
^ permalink raw reply
* [PATCH] soc: imx: gpc: de-register power domains only if initialized
From: Lucas Stach @ 2018-01-08 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108102855.GA32635@b29396-OptiPlex-7040>
Am Montag, den 08.01.2018, 18:28 +0800 schrieb Dong Aisheng:
> On Sun, Jan 07, 2018 at 02:49:05PM +0100, Stefan Agner wrote:
> > If power domain information are missing in the device tree, no
> > power domains get initialized. However, imx_gpc_remove tries to
> > remove power domains always in the old DT binding case. Only
> > remove power domains when imx_gpc_probe initialized them in
> > first place.
> >
> > Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC
> > driver")
> > Cc: Lucas Stach <l.stach@pengutronix.de>
> > Signed-off-by: Stefan Agner <stefan@agner.ch>
> > ---
> > ?drivers/soc/imx/gpc.c | 10 +++++++++-
> > ?1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> > index 53f7275d6cbd..62bb724726d9 100644
> > --- a/drivers/soc/imx/gpc.c
> > +++ b/drivers/soc/imx/gpc.c
> > @@ -470,13 +470,21 @@ static int imx_gpc_probe(struct
> > platform_device *pdev)
> > ?
> > ?static int imx_gpc_remove(struct platform_device *pdev)
> > ?{
>
> What's the original purpose of imx_gpc_remove?
> ARM power domain can't be removed.
Why? As long as it stays powered on there is not reason why we wouldn't
be able to remove the driver.
> And why current imx_gpc_remove only remove domains for old DT but not
> for new ones?
With the new binding the power domains will be removed by the sub-
drivers for the domains.
> How about make it un-removable?
> e.g.
I don't see why this would be a good idea. Once more device-dependency
handling is in place we might need to unbind the power domains when the
regulator driver for the domain is unbound. Do you intend to make them
non-removable, too?
Regards,
Lucas
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 47e7aa9..7fc6737 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -454,36 +454,17 @@ static int imx_gpc_probe(struct platform_device
> *pdev)
> ????????return 0;
> ?}
> ?
> -static int imx_gpc_remove(struct platform_device *pdev)
> -{
> -???????int ret;
> -
> -???????/*
> -????????* If the old DT binding is used the toplevel driver needs to
> -????????* de-register the power domains
> -????????*/
> -???????if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
> -???????????????of_genpd_del_provider(pdev->dev.of_node);
> -
> -???????????????ret =
> pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
> -???????????????if (ret)
> -???????????????????????return ret;
> -???????????????imx_pgc_put_clocks(&imx_gpc_domains[GPC_PGC_DOMAIN_PU
> ]);
> -
> -???????????????ret =
> pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_ARM].base);
> -???????????????if (ret)
> -???????????????????????return ret;
> -???????}
> -
> -???????return 0;
> -}
> -
> ?static struct platform_driver imx_gpc_driver = {
> ????????.driver = {
> ????????????????.name = "imx-gpc",
> ????????????????.of_match_table = imx_gpc_dt_ids,
> +????????????????/*
> +?????????????????* We can't forcibly eject devices form power
> domain,
> +?????????????????* so we can't really remove power domains once they
> +?????????????????* were added.
> +?????????????????*/
> +????????????????.suppress_bind_attrs = true,
> ????????},
> ????????.probe = imx_gpc_probe,
> -???????.remove = imx_gpc_remove,
> ?};
> ?builtin_platform_driver(imx_gpc_driver)
>
> Regards
> Dong Aisheng
>
> > + struct device_node *pgc_node;
> > ? int ret;
> > ?
> > + pgc_node = of_get_child_by_name(pdev->dev.of_node, "pgc");
> > +
> > + /* bail out if DT too old and doesn't provide the
> > necessary info */
> > + if (!of_property_read_bool(pdev->dev.of_node, "#power-
> > domain-cells") &&
> > + ????!pgc_node)
> > + return 0;
> > +
> > ? /*
> > ? ?* If the old DT binding is used the toplevel driver needs
> > to
> > ? ?* de-register the power domains
> > ? ?*/
> > - if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
> > + if (!pgc_node) {
> > ? of_genpd_del_provider(pdev->dev.of_node);
> > ?
> > ? ret =
> > pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
> > --?
> > 2.15.1
> >
^ permalink raw reply
* [PATCH v3] PCI: imx6: Add PHY reference clock source support
From: Lucas Stach @ 2018-01-08 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515073977-10153-1-git-send-email-ilya@compulab.co.il>
Am Donnerstag, den 04.01.2018, 15:52 +0200 schrieb Ilya Ledvich:
> i.MX7D variant of the IP can use either Crystal Oscillator input
> or internal clock input as a Reference Clock input for PCIe PHY.
> Add support for an optional property 'fsl,pcie-phy-refclk-internal'.
> If present then an internal clock input is used as PCIe PHY
> reference clock source. By default an external oscillator input
> is still used.
>
> Verified on Compulab SBC-iMX7 Single Board Computer.
Sorry to get in late here, but I would rather have the external clock
input modeled as a real clock and only use the internal clock if that
isn't present.
Are you even sure that the i.MX7 clock you mention isn't the already
documented "pcie_bus" clock? This one is also allowed to be sourced
externally on the i.MX6.
Regards,
Lucas
> Signed-off-by: Ilya Ledvich <ilya@compulab.co.il>
> ---
> changes since V2:
> add a vendor prefix 'fsl' to a new property
>
> ?Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt | 5 +++++
> ?drivers/pci/dwc/pci-imx6.c???????????????????????????????| 8
> +++++++-
> ?2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> index 7b1e48b..1591a6a 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> @@ -50,6 +50,11 @@ Additional required properties for imx7d-pcie:
> ? ???????- "pciephy"
> ? ???????- "apps"
> ?
> +Additional optional properties for imx7d-pcie:
> +- fsl,pcie-phy-refclk-internal: If present then an internal PLL
> input is used
> +??as PCIe PHY reference clock source. By default an external
> oscillator input
> +??is used.
> +
> ?Example:
> ?
> ? pcie at 0x01000000 {
> diff --git a/drivers/pci/dwc/pci-imx6.c b/drivers/pci/dwc/pci-imx6.c
> index b734835..36812d3 100644
> --- a/drivers/pci/dwc/pci-imx6.c
> +++ b/drivers/pci/dwc/pci-imx6.c
> @@ -61,6 +61,7 @@ struct imx6_pcie {
> ? u32 tx_swing_low;
> ? int link_gen;
> ? struct regulator *vpcie;
> + bool pciephy_refclk_sel;
> ?};
> ?
> ?/* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
> @@ -474,7 +475,9 @@ static void imx6_pcie_init_phy(struct imx6_pcie
> *imx6_pcie)
> ? switch (imx6_pcie->variant) {
> ? case IMX7D:
> ? regmap_update_bits(imx6_pcie->iomuxc_gpr,
> IOMUXC_GPR12,
> - ???IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
> 0);
> + ???IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
> + ???imx6_pcie->pciephy_refclk_sel ?
> + ???IMX7D_GPR12_PCIE_PHY_REFCLK_SEL :
> 0);
> ? break;
> ? case IMX6SX:
> ? regmap_update_bits(imx6_pcie->iomuxc_gpr,
> IOMUXC_GPR12,
> @@ -840,6 +843,9 @@ static int imx6_pcie_probe(struct platform_device
> *pdev)
> ? imx6_pcie->vpcie = NULL;
> ? }
> ?
> + imx6_pcie->pciephy_refclk_sel =
> + of_property_read_bool(node, "fsl,pcie-phy-refclk-
> internal");
> +
> ? platform_set_drvdata(pdev, imx6_pcie);
> ?
> ? ret = imx6_add_pcie_port(imx6_pcie, pdev);
^ permalink raw reply
* [PATCH] ARM: dts: imx6ul: remove unnecessary clocks for cpu-freq
From: Dong Aisheng @ 2018-01-08 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514978534-27416-1-git-send-email-Anson.Huang@nxp.com>
On Wed, Jan 03, 2018 at 07:22:14PM +0800, Anson Huang wrote:
> Remove unnecessary clocks for cpu-freq driver to
> avoid confusion.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH] clk: imx: imx7d: correct video pll clock tree
From: Dong Aisheng @ 2018-01-08 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514999361-2723-1-git-send-email-Anson.Huang@nxp.com>
On Thu, Jan 04, 2018 at 01:09:21AM +0800, Anson Huang wrote:
> There is a test divider and post divider in video PLL,
> test divider is placed before post divider, all clocks
> that can select parent from video PLL should be from
> post divider, NOT from pll_video_main, below are
> clock tree dump before and after this patch:
>
> Before:
> pll_video_main
> pll_video_main_bypass
> pll_video_main_clk
> lcdif_pixel_src
> lcdif_pixel_cg
> lcdif_pixel_pre_div
> lcdif_pixel_post_div
> lcdif_pixel_root_clk
> After:
> pll_video_main
> pll_video_main_bypass
> pll_video_main_clk
> pll_video_test_div
> pll_video_post_div
> lcdif_pixel_src
> lcdif_pixel_cg
> lcdif_pixel_pre_div
> lcdif_pixel_post_div
> lcdif_pixel_root_clk
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH 2/2] ARM: dts: imx7s: add snvs rtc clock
From: Dong Aisheng @ 2018-01-08 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078402-22135-2-git-send-email-Anson.Huang@nxp.com>
On Thu, Jan 04, 2018 at 11:06:42PM +0800, Anson Huang wrote:
> Add i.MX7 SNVS RTC clock.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
If this clock IMX7D_SNVS_CLK is used for all SNVS sub modules,
then snvs_poweroff and snvs_pwrkey should also rely on it, right?
How about add them all in one time?
BTW, syscon-poweroff seems still not introduce clock support and
fsl,sec-v4.0-pwrkey also does not handle clock, they may need to
be added later.
Regards
Dong Aisheng
> ---
> arch/arm/boot/dts/imx7s.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index e718fd2..f9b97f3 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -534,6 +534,8 @@
> offset = <0x34>;
> interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX7D_SNVS_CLK>;
> + clock-names = "snvs-rtc";
> };
>
> snvs_poweroff: snvs-poweroff {
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 1/4] dmaengine: xilinx_dma: populate dma caps properly
From: Vinod Koul @ 2018-01-08 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514961731-1916-2-git-send-email-appanad@xilinx.com>
On Wed, Jan 03, 2018 at 12:12:08PM +0530, Kedareswara rao Appana wrote:
> When client driver uses dma_get_slave_caps() api,
> it checks for certain fields of dma_device struct
> currently driver is not settings the directions and addr_widths
> fields resulting dma_get_slave_caps() returning failure.
>
> This patch fixes this issue by populating proper values
> to the struct dma_device directions and addr_widths fields.
>
> Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
> ---
> Changes for v2:
> --> Improved commit message title and description
> as suggested by Vinod.
>
> drivers/dma/xilinx/xilinx_dma.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 88d317d..21ac954 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -2398,6 +2398,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->direction = DMA_MEM_TO_DEV;
> chan->id = chan_id;
> chan->tdest = chan_id;
> + xdev->common.directions = BIT(DMA_MEM_TO_DEV);
>
> chan->ctrl_offset = XILINX_DMA_MM2S_CTRL_OFFSET;
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
> @@ -2415,6 +2416,7 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->direction = DMA_DEV_TO_MEM;
> chan->id = chan_id;
> chan->tdest = chan_id - xdev->nr_channels;
> + xdev->common.directions |= BIT(DMA_DEV_TO_MEM);
>
> chan->ctrl_offset = XILINX_DMA_S2MM_CTRL_OFFSET;
> if (xdev->dma_config->dmatype == XDMA_TYPE_VDMA) {
> @@ -2629,6 +2631,8 @@ static int xilinx_dma_probe(struct platform_device *pdev)
> dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
> }
>
> + xdev->common.dst_addr_widths = BIT(addr_width / 8);
> + xdev->common.src_addr_widths = BIT(addr_width / 8);
Do you not support trf of 1byte, 2 bytes, or 4 bytes wide transfers? What is
value of addr_width here typically? Usually controllers can support
different widths and this is a surprise that you support only one value
--
~Vinod
^ permalink raw reply
* [PATCH 1/2] clk: imx: imx7d: add the snvs clock
From: Dong Aisheng @ 2018-01-08 10:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515078402-22135-1-git-send-email-Anson.Huang@nxp.com>
On Thu, Jan 04, 2018 at 11:06:41PM +0800, Anson Huang wrote:
> According to the i.MX7D Reference Manual,
> SNVS block has a clock gate, accessing SNVS block
> would need this clock gate to be enabled, add it
> into clock tree so that SNVS module driver can
> operate this clock gate.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH v2 0/5] constify struct imx_pinctrl_soc_info
From: Dong Aisheng @ 2018-01-08 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106142553.15322-1-stefan@agner.ch>
On Sat, Jan 06, 2018 at 03:25:48PM +0100, Stefan Agner wrote:
> This patchset grew out of the discussion around the first version
> of "pinctrl: imx6ul: add IOMUXC SNVS pinctrl driver for i.MX 6ULL".
> This is necessary for pinctrls of SoCs with multiple compatible
> strings (currently only imx7d) since the struct uses the .data
> pointer in struct of_device_id. It is also helpful for all other
> SoCs since it decreases the .data section for all drivers by 1276
> bytes.
>
> Bai Ping (1):
> pinctrl: imx6ul: add IOMUXC SNVS pinctrl driver for i.MX 6ULL
>
> Stefan Agner (4):
> pinctrl: imx: use struct imx_pinctrl_soc_info as a const
> pinctrl: imx7d: simplify imx7d_pinctrl_probe
> pinctrl: imx: constify struct imx_pinctrl_soc_info
> pinctrl: imx7ulp: constify struct imx_cfg_params_decode
>
This patch series looks really good to me.
So
Acked-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Dong Aisheng
^ permalink raw reply
* [PATCH] soc: imx: gpc: de-register power domains only if initialized
From: Dong Aisheng @ 2018-01-08 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180107134905.15624-1-stefan@agner.ch>
On Sun, Jan 07, 2018 at 02:49:05PM +0100, Stefan Agner wrote:
> If power domain information are missing in the device tree, no
> power domains get initialized. However, imx_gpc_remove tries to
> remove power domains always in the old DT binding case. Only
> remove power domains when imx_gpc_probe initialized them in
> first place.
>
> Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver")
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Signed-off-by: Stefan Agner <stefan@agner.ch>
> ---
> drivers/soc/imx/gpc.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 53f7275d6cbd..62bb724726d9 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -470,13 +470,21 @@ static int imx_gpc_probe(struct platform_device *pdev)
>
> static int imx_gpc_remove(struct platform_device *pdev)
> {
What's the original purpose of imx_gpc_remove?
ARM power domain can't be removed.
And why current imx_gpc_remove only remove domains for old DT but not
for new ones?
How about make it un-removable?
e.g.
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 47e7aa9..7fc6737 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -454,36 +454,17 @@ static int imx_gpc_probe(struct platform_device *pdev)
return 0;
}
-static int imx_gpc_remove(struct platform_device *pdev)
-{
- int ret;
-
- /*
- * If the old DT binding is used the toplevel driver needs to
- * de-register the power domains
- */
- if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
- of_genpd_del_provider(pdev->dev.of_node);
-
- ret = pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
- if (ret)
- return ret;
- imx_pgc_put_clocks(&imx_gpc_domains[GPC_PGC_DOMAIN_PU]);
-
- ret = pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_ARM].base);
- if (ret)
- return ret;
- }
-
- return 0;
-}
-
static struct platform_driver imx_gpc_driver = {
.driver = {
.name = "imx-gpc",
.of_match_table = imx_gpc_dt_ids,
+ /*
+ * We can't forcibly eject devices form power domain,
+ * so we can't really remove power domains once they
+ * were added.
+ */
+ .suppress_bind_attrs = true,
},
.probe = imx_gpc_probe,
- .remove = imx_gpc_remove,
};
builtin_platform_driver(imx_gpc_driver)
Regards
Dong Aisheng
> + struct device_node *pgc_node;
> int ret;
>
> + pgc_node = of_get_child_by_name(pdev->dev.of_node, "pgc");
> +
> + /* bail out if DT too old and doesn't provide the necessary info */
> + if (!of_property_read_bool(pdev->dev.of_node, "#power-domain-cells") &&
> + !pgc_node)
> + return 0;
> +
> /*
> * If the old DT binding is used the toplevel driver needs to
> * de-register the power domains
> */
> - if (!of_get_child_by_name(pdev->dev.of_node, "pgc")) {
> + if (!pgc_node) {
> of_genpd_del_provider(pdev->dev.of_node);
>
> ret = pm_genpd_remove(&imx_gpc_domains[GPC_PGC_DOMAIN_PU].base);
> --
> 2.15.1
>
^ permalink raw reply related
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
From: Maxime Ripard @ 2018-01-08 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180104152741.m6bsno4vdh65ouw3@core.my.home>
Hi,
On Thu, Jan 04, 2018 at 04:27:41PM +0100, Ond?ej Jirman wrote:
> On Thu, Jan 04, 2018 at 03:06:25PM +0100, Maxime Ripard wrote:
> > On Mon, Dec 25, 2017 at 09:58:02AM +0100, Ond?ej Jirman wrote:
> > > Hello,
> > >
> > > On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > > > Hi,
> > > >
> > > > On Fri, 22 Dec 2017 14:46:48 +0100
> > > > Ond?ej Jirman <megous@megous.com> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> > > > > >
> > > > > > Test input 0:
> > > > > >
> > > > > > Control ioctls:
> > > > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > > > Standard Controls: 0 Private Controls: 0
> > > > >
> > > > > I'm not sure if your driver passes control queries to the subdev. It
> > > > > did not originally, and I'm not sure you picked up the change from my
> > > > > version of the driver. "Not supported" here seems to indicate that it
> > > > > does not.
> > > > >
> > > > > I'd be interested what's the recommended practice here. It sure helps
> > > > > with some apps that expect to be able to modify various input controls
> > > > > directly on the /dev/video# device. These are then supported out of the
> > > > > box.
> > > > >
> > > > > It's a one-line change. See:
> > > > >
> > > > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > > > heriting-controls
> > > >
> > > > I think this is a feature and not affect the driver's main function.
> > > > I just focused on making the CSI main function to work properly in
> > > > the initial version. Is this feature mandatory or most commonly used?
> > >
> > > I grepped the platform/ code and it seems, that inheriting controls
> > > from subdevs is pretty common for input drivers. (there are varying
> > > approaches though, some inherit by hand in the link function, some
> > > just register and empty ctrl_handler on the v4l2_dev and leave the
> > > rest to the core).
> > >
> > > Practically, I haven't found a common app that would allow me to enter
> > > both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> > > themselves, but it would be better if current controls were available
> > > at the /dev/video0 device automatically.
> > >
> > > It's much simpler for the userspace apps than the alternative, which
> > > is trying to identify the correct subdev that is currently
> > > associated with the CSI driver at runtime, which is not exactly
> > > straightforward and requires much more code, than a few lines in
> > > the kernel, that are required to inherit controls:
> >
> > And it becomes much more complicated once you have the same controls
> > on the v4l2 device and subdevice, which is not that uncommon.
>
> I don't think you understand the issue. In your hypothetical situation, if the
> CSI device will have any controls in the future, the merging of controls from
> subdev will be done automatically anyway, it's not some optional feature.
>
> Also userspace will not get any more complicated than without my proposed change
> to the driver. It will be at most the same as without the change if any subdev
> controls are masked by the CSI device controls.
>
> This CSI driver has no controls anyway. All my change does is create an empty
> handler for future controls of the CSI driver, so that apps can depend on this
> merging behavior right now, and not wait until someone adds the first control
> to the CSI driver.
My point is slightly different though. In more complex pipelines like
we have (which is even more complicated due to the fact that the ISP
is largely unknown), you cannot just have an application that rely on
the controls exposed on the v4l2 device, but they should take the
subdevices into account as well.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180108/bdd92851/attachment.sig>
^ permalink raw reply
* [PATCH 5/5] clk: qcom: use divider_ro_round_rate helper
From: Jerome Brunet @ 2018-01-08 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-6-jbrunet@baylibre.com>
On Fri, 2018-01-05 at 18:09 +0100, Jerome Brunet wrote:
> There is now an helper function to round the rate when the
> divider is read-only. Let's use it
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/clk/qcom/clk-regmap-divider.c | 19 ++++++-------------
> 1 file changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/clk/qcom/clk-regmap-divider.c b/drivers/clk/qcom/clk-regmap-divider.c
> index 4e9b8c2c8980..114e36b97255 100644
> --- a/drivers/clk/qcom/clk-regmap-divider.c
> +++ b/drivers/clk/qcom/clk-regmap-divider.c
> @@ -28,22 +28,15 @@ static long div_round_ro_rate(struct clk_hw *hw, unsigned long rate,
> {
> struct clk_regmap_div *divider = to_clk_regmap_div(hw);
> struct clk_regmap *clkr = ÷r->clkr;
> - u32 div;
> + u32 val;
> struct clk_hw *hw_parent = clk_hw_get_parent(hw);
forgot to remove this line.
>
> - regmap_read(clkr->regmap, divider->reg, &div);
> - div >>= divider->shift;
> - div &= BIT(divider->width) - 1;
> - div += 1;
> -
> - if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
> - if (!hw_parent)
> - return -EINVAL;
> -
> - *prate = clk_hw_round_rate(hw_parent, rate * div);
> - }
> + regmap_read(clkr->regmap, divider->reg, &val);
> + val >>= divider->shift;
> + val &= BIT(divider->width) - 1;
>
> - return DIV_ROUND_UP_ULL((u64)*prate, div);
> + return divider_ro_round_rate(hw, rate, prate, NULL, divider->width,
> + CLK_DIVIDER_ROUND_CLOSEST, val);
> }
>
> static long div_round_rate(struct clk_hw *hw, unsigned long rate,
^ permalink raw reply
* [PATCH] Revert "ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells"
From: Stefan Wahren @ 2018-01-08 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3qfiX_ZsD8pLmoTJZ2+Q8PkHGmfTFW=NL8P8QFML_dLw@mail.gmail.com>
Hi Arnd,
Am 08.01.2018 um 10:27 schrieb Arnd Bergmann:
> On Mon, Jan 8, 2018 at 10:15 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>> Hi Eric,
>> Am 07.01.2018 um 23:08 schrieb Eric Anholt:
>>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>>
>>>> This reverts commit 014d6da6cb2525d7f48fb08c705cb130cc7b5f4a.
>>>>
>>>> The DT clean up could trigger an endless deferred probe of DWC2 USB
>>>> driver
>>>> on the Raspberry Pi 2/3. So revert the change until we fixed the probing
>>>> issue.
>>> Why's that? I found that I needed to enable the generic no-op phy
>>> driver, but other than that it was fine.
>>
>> in order to avoid this regression. Changing the configuration is not a
>> solution for the kernelci guys.
>>
>> Btw
>>
>> CONFIG_NOP_USB_XCEIV=y
>>
>> is already enabled in arm64/defconfig and the issue still occured. Do you
>> mean a different option?
> Obviously we need to fix this, but I really want to understand what exactly
> happened so we can fix the code if possible rather than making the
> dts file incompatible with the binding again.
i fully agree, but dwc2 "hacking" usually requires more time than
reverting this change.
>
> Do you have any more insight into how we get into the deferred probe
> situation?
I send this bug report [1] on Friday to linux-usb.
Stefan
[1] - https://marc.info/?l=linux-usb&m=151518314314753&w=2
>
> Arnd
^ permalink raw reply
* [PATCH] arm64: Implement branch predictor hardening for Falkor
From: Andrew Jones @ 2018-01-08 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515184139-23743-1-git-send-email-shankerd@codeaurora.org>
Hi Shanker,
On Fri, Jan 05, 2018 at 02:28:59PM -0600, Shanker Donthineni wrote:
...
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index cb0fb37..daf53a5 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -54,6 +54,8 @@ static int cpu_enable_trap_ctr_access(void *__unused)
>
> #ifdef CONFIG_KVM
> extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
> +extern char __qcom_hyp_sanitize_link_stack_start[];
> +extern char __qcom_hyp_sanitize_link_stack_end[];
>
> static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
> const char *hyp_vecs_end)
> @@ -96,8 +98,10 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
> spin_unlock(&bp_lock);
> }
> #else
> -#define __psci_hyp_bp_inval_start NULL
> -#define __psci_hyp_bp_inval_end NULL
> +#define __psci_hyp_bp_inval_start NULL
> +#define __psci_hyp_bp_inval_end NULL
> +#define __qcom_hyp_sanitize_link_stack_start NULL
> +#define __qcom_hyp_sanitize_link_stack_start NULL
^^ copy+paste error here
Thanks,
drew
^ permalink raw reply
* [PATCH] Revert "ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells"
From: Arnd Bergmann @ 2018-01-08 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <df3db2e7-5d0f-9c1c-b005-41cf00e7d851@i2se.com>
On Mon, Jan 8, 2018 at 10:15 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Hi Eric,
> Am 07.01.2018 um 23:08 schrieb Eric Anholt:
>>
>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>
>>> This reverts commit 014d6da6cb2525d7f48fb08c705cb130cc7b5f4a.
>>>
>>> The DT clean up could trigger an endless deferred probe of DWC2 USB
>>> driver
>>> on the Raspberry Pi 2/3. So revert the change until we fixed the probing
>>> issue.
>>
>> Why's that? I found that I needed to enable the generic no-op phy
>> driver, but other than that it was fine.
>
>
> in order to avoid this regression. Changing the configuration is not a
> solution for the kernelci guys.
>
> Btw
>
> CONFIG_NOP_USB_XCEIV=y
>
> is already enabled in arm64/defconfig and the issue still occured. Do you
> mean a different option?
Obviously we need to fix this, but I really want to understand what exactly
happened so we can fix the code if possible rather than making the
dts file incompatible with the binding again.
Do you have any more insight into how we get into the deferred probe
situation?
Arnd
^ permalink raw reply
* [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3
From: Marc Zyngier @ 2018-01-08 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108072253.GA178830@jc-sabre>
On 08/01/18 07:24, Jayachandran C wrote:
> On Fri, Jan 05, 2018 at 01:12:33PM +0000, Will Deacon wrote:
>> For non-KASLR kernels where the KPTI behaviour has not been overridden
>> on the command line we can use ID_AA64PFR0_EL1.CSV3 to determine whether
>> or not we should unmap the kernel whilst running at EL0.
>>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>> ---
>> arch/arm64/include/asm/sysreg.h | 1 +
>> arch/arm64/kernel/cpufeature.c | 8 +++++++-
>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
>> index 08cc88574659..ae519bbd3f9e 100644
>> --- a/arch/arm64/include/asm/sysreg.h
>> +++ b/arch/arm64/include/asm/sysreg.h
>> @@ -437,6 +437,7 @@
>> #define ID_AA64ISAR1_DPB_SHIFT 0
>>
>> /* id_aa64pfr0 */
>> +#define ID_AA64PFR0_CSV3_SHIFT 60
>> #define ID_AA64PFR0_SVE_SHIFT 32
>> #define ID_AA64PFR0_GIC_SHIFT 24
>> #define ID_AA64PFR0_ASIMD_SHIFT 20
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index 9f0545dfe497..d723fc071f39 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -145,6 +145,7 @@ static const struct arm64_ftr_bits ftr_id_aa64isar1[] = {
>> };
>>
>> static const struct arm64_ftr_bits ftr_id_aa64pfr0[] = {
>> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR0_CSV3_SHIFT, 4, 0),
>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_SVE_SHIFT, 4, 0),
>> ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_GIC_SHIFT, 4, 0),
>> S_ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR0_ASIMD_SHIFT, 4, ID_AA64PFR0_ASIMD_NI),
>> @@ -851,6 +852,8 @@ static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
>> static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
>> int __unused)
>> {
>> + u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
>> +
>> /* Forced on command line? */
>> if (__kpti_forced) {
>> pr_info_once("kernel page table isolation forced %s by command line option\n",
>> @@ -862,7 +865,9 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
>> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
>> return true;
>>
>> - return false;
>> + /* Defer to CPU feature registers */
>> + return !cpuid_feature_extract_unsigned_field(pfr0,
>> + ID_AA64PFR0_CSV3_SHIFT);
>
> If I read this correctly, this enables KPTI on all processors without the CSV3
> set (which seems to be a future capability).
>
> Turning on KPTI has a small but significant overhead, so I think we should turn
> it off on processors that are not vulnerable to CVE-2017-5754. Can we add something
> like this:
>
> --->8
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 19ed09b..202b037 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -862,6 +862,13 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
> return __kpti_forced > 0;
> }
>
> + /* Don't force KPTI for CPUs that are not vulnerable */
> + switch (read_cpuid_id() & MIDR_CPU_MODEL_MASK) {
> + case MIDR_CAVIUM_THUNDERX2:
> + case MIDR_BRCM_VULCAN:
> + return false;
> + }
> +
> /* Useful for KASLR robustness */
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
> return true;
>
KPTI is also an improvement for KASLR. Why would you deprive a user of
the choice to further secure their system?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 01/11] clk: sunxi-ng: Don't set k if width is 0 for nkmp plls
From: Chen-Yu Tsai @ 2018-01-08 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3625461.aU9oqMdpo3@jernej-laptop>
On Fri, Jan 5, 2018 at 3:28 AM, Jernej ?krabec <jernej.skrabec@siol.net> wrote:
> Hi,
>
> Dne ?etrtek, 04. januar 2018 ob 15:45:18 CET je Chen-Yu Tsai napisal(a):
>> On Sun, Dec 31, 2017 at 5:01 AM, Jernej Skrabec <jernej.skrabec@siol.net>
> wrote:
>> > For example, A83T have nmp plls which are modelled as nkmp plls. Since k
>> > is not specified, it has offset 0, shift 0 and lowest value 1. This
>> > means that LSB bit is always set to 1, which may change clock rate.
>> >
>> > Fix that by applying k factor only if k width is greater than 0.
>> >
>> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> > ---
>> >
>> > drivers/clk/sunxi-ng/ccu_nkmp.c | 21 +++++++++++++--------
>> > 1 file changed, 13 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c
>> > b/drivers/clk/sunxi-ng/ccu_nkmp.c index e58c95787f94..709f528af2b3 100644
>> > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
>> > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
>> > @@ -81,7 +81,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw
>> > *hw,>
>> > unsigned long parent_rate)
>> >
>> > {
>> >
>> > struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
>> >
>> > - unsigned long n, m, k, p;
>> > + unsigned long n, m, k = 1, p;
>> >
>> > u32 reg;
>> >
>> > reg = readl(nkmp->common.base + nkmp->common.reg);
>> >
>> > @@ -92,11 +92,13 @@ static unsigned long ccu_nkmp_recalc_rate(struct
>> > clk_hw *hw,>
>> > if (!n)
>> >
>> > n++;
>> >
>> > - k = reg >> nkmp->k.shift;
>> > - k &= (1 << nkmp->k.width) - 1;
>> > - k += nkmp->k.offset;
>> > - if (!k)
>> > - k++;
>> > + if (nkmp->k.width) {
>> > + k = reg >> nkmp->k.shift;
>> > + k &= (1 << nkmp->k.width) - 1;
>> > + k += nkmp->k.offset;
>> > + if (!k)
>> > + k++;
>> > + }
>>
>> The conditional shouldn't be necessary. With nkmp->k.width = 0,
>> you'd simply get k & 0, which is 0, which then gets bumped up to 1,
>> unless k.offset > 1, which would be a bug.
>>
>> > m = reg >> nkmp->m.shift;
>> > m &= (1 << nkmp->m.width) - 1;
>> >
>> > @@ -153,12 +155,15 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw,
>> > unsigned long rate,>
>> > reg = readl(nkmp->common.base + nkmp->common.reg);
>> > reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
>> >
>> > - reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
>> > + if (nkmp->k.width)
>> > + reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1,
>> > + nkmp->k.shift);
>> >
>> > reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
>> > reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
>> >
>> > reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
>> >
>> > - reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
>> > + if (nkmp->k.width)
>> > + reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
>>
>> I think a better way would be
>>
>> reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) &
>> GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
>>
>> And do this for all the factors, not just k. This pattern is what
>> regmap_update_bits does, which seems much safer. I wonder what
>> GENMASK() with a negative value would do though...
>
> You're right, GENMASK(-1, 0) equals 0 (calculated by hand, not tested). This
> seems much more elegant solution.
>
> Semi-related question: All nmp PLLs have much wider N range than real nkmp
> PLLs. This causes integer overflow when using nkmp formula from datasheet.
> Usually, N is 1-256 for nmp PLLs, which means that for very high N factors, it
> overflows. This also causes issue that M factor is never higher than 1.
Sounds like we can't use u8 for storing the factors. At least the
intermediate values we use to calculate the rates.
>
> I was wondering, if patch would be acceptable which would change this formula:
>
> RATE = (24MHz * N * K) / (M * P)
>
> to this:
>
> RATE ((24MHz / M) * N * K) / P
>
> I checked all M factors and are all in 1-4 or 1-2 range, which means it
> wouldn't have any impact for real nkmp PLLs when parent is 24 MHz clock which
> is probably always.
>
> What do you think?
I think this is acceptable. M is normally the pre-divider, so this
actually fits how the hardware works, including possible rounding
errors.
ChenYu
> I discovered that when I tried to set A83T PLL_VIDEO to 346.5 MHz which is
> possible only when above formula is changed.
>
> Best regards,
> Jernej
>
>>
>> ChenYu
>>
>> > reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
>> > reg |= ilog2(_nkmp.p) << nkmp->p.shift;
>> >
>> > --
>> > 2.15.1
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [linux-sunxi] [PATCH v2 3/6] ARM: sun4i: Convert to CCU
From: Chen-Yu Tsai @ 2018-01-08 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOi56cXTrGg+mx4aJsrMTHcwAV4KLCUZDy9bjpAq1hi1gngKAg@mail.gmail.com>
On Sat, Jan 6, 2018 at 12:10 AM, Kevin Hilman <khilman@baylibre.com> wrote:
> On Wed, Dec 13, 2017 at 11:46 AM, Kevin Hilman <khilman@baylibre.com> wrote:
>> On Wed, Dec 13, 2017 at 9:13 AM, Priit Laes <plaes@plaes.org> wrote:
>>> On Wed, Dec 13, 2017 at 05:09:33PM +0000, Priit Laes wrote:
>>>> On Tue, Dec 12, 2017 at 01:24:52PM -0800, Kevin Hilman wrote:
>>>> > On Tue, Dec 12, 2017 at 9:26 AM, Priit Laes <plaes@plaes.org> wrote:
>>>> > > On Mon, Dec 11, 2017 at 02:22:30PM -0800, Kevin Hilman wrote:
>>>> > >> On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes <plaes@plaes.org> wrote:
>>>> > >> > Convert sun4i-a10.dtsi to new CCU driver.
>>>> > >> >
>>>> > >> > Signed-off-by: Priit Laes <plaes@plaes.org>
>>>> > >>
>>>> > >> I finally got around to bisecting a mainline boot failure on
>>>> > >> sun4i-a10-cubieboard that's been happening for quite a while. Based
>>>> > >> on on kernelci.org, it showed up sometime during the v4.15 merge
>>>> > >> window[1]. It bisected down to this commit (in mainline as commit
>>>> > >> 41193869f2bdb585ce09bfdd16d9482aadd560ad).
>>>> > >>
>>>> > >> When it fails, there is no output on the serial console, so I don't
>>>> > >> know exactly how it's failing, just that it no longer boots.
>>>> > >
>>>> > > We tried out latest 4.15 with various compilers and it works:
>>>> > > - gcc version 7.1.1 20170622 (Red Hat Cross 7.1.1-3) (GCC) - A10 Gemei G9 tablet
>>>> > > - gcc 7.2.0-debian - A10 Cubieboard
>>>> >
>>>> > And you can reproduce the bug with gcc5 or gcc6?
>>>>
>>>> Tried following commits on Gemei G9 (A10 tablet):
>>>> * 4.15.0-rc3-00037-gd39a01eff9af - latest master
>>>> * 4.14.0-rc1-00002-g41193869f2bd - the exact commit, causing the issue.
>>>>
>>>> With the same Linaro toolchain:
>>>> (gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05))
>>>
>>> And I also tried the same dtb and zImage from kernelci page [1] and it works with
>>> that too...
>>>
>>> https://storage.kernelci.org/mainline/master/v4.15-rc3/arm/sunxi_defconfig/
>>
>> Can you share a full boot-log (including all the u-boot output etc.)
>> so I can see exactly how the kernel is being loaded? Especially the
>> u-boot version?
>>
>> As $SUBJECT patch seems to be changing clocks around, perhaps this is
>> an issue where some u-boot dependency is uncovered, and older versions
>> of u-boot don't play well with this change.
>
> Ping.
>
> This is still failing in mainline, but passing int stable <= v4.14
Just did a test with clean builds of v4.15-rc7 with sunxi_defconfig
and U-boot 2018.01-rc3 with Cubieboard_defconfig. It successfully
boots to a prompt. My previous bootloader was U-boot 2017.05 with
some local modifications.
Here is the full boot log: https://wens.tw/cb-boot-log.txt
The boot script is:
setenv bootargs console=tty0 console=ttyS0,115200n8
root=/dev/mmcblk0p1 rootwait panic=10 earlycon=uart,mmio32,0x01c28000
consoleblank=0 drm.debug=0x1e
load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} boot/zImage
load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} boot/${fdtfile}
bootz ${kernel_addr_r} - ${fdt_addr_r}
Regards
ChenYu
^ permalink raw reply
* [PATCH] Revert "ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells"
From: Stefan Wahren @ 2018-01-08 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87incdjp9k.fsf@anholt.net>
Hi Eric,
Am 07.01.2018 um 23:08 schrieb Eric Anholt:
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
>> This reverts commit 014d6da6cb2525d7f48fb08c705cb130cc7b5f4a.
>>
>> The DT clean up could trigger an endless deferred probe of DWC2 USB driver
>> on the Raspberry Pi 2/3. So revert the change until we fixed the probing
>> issue.
> Why's that? I found that I needed to enable the generic no-op phy
> driver, but other than that it was fine.
in order to avoid this regression. Changing the configuration is not a
solution for the kernelci guys.
Btw
CONFIG_NOP_USB_XCEIV=y
is already enabled in arm64/defconfig and the issue still occured. Do
you mean a different option?
Stefan
^ permalink raw reply
* [PATCH 2/5] clk: lpc32xx: read-only divider can propagate rate change
From: Jerome Brunet @ 2018-01-08 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <54782a8f-9735-a574-d8e1-7ff3e9173229@mleia.com>
On Sat, 2018-01-06 at 16:04 +0200, Vladimir Zapolskiy wrote:
> > I added the fix to LPC32xx because it looks like the generic divider (a lot) and
>
> right, the relevant divider operations were copied, however the difference
> is important, unfortunately there is no simple option to get rid of regmap,
> because System Control Block registers are shared with a number of other
> device drivers.
I have the same issue ;)
>
> > appears to support CLK_DIVIDER_READ_ONLY. If it does not, could you please kill
> > the related code ?
>
> The driver supports CLK_DIVIDER_READ_ONLY clocks, and it should not be
> changed, but all such clocks don't have children with CLK_SET_RATE_PARENT
> property, which invalidates your fix for LPC32xx. Please let me know,
> if I missed something.
You did not miss anything. I understand your choice.
I just have different approach and usually prefer to avoid these particularity
which may catch you later on.
At least, the fact that propagation would stop with CLK_DIVIDER_READ_ONLY on
LPC32xx, even with CLK_SET_RATE_PARENT, is now known.
Adding a comment in the code to make this explicit would be nice though.
Regards
Jerome
^ permalink raw reply
* [PATCH v2 2/5] ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
From: Jerome Brunet @ 2018-01-08 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-3-yixun.lan@amlogic.com>
On Sat, 2018-01-06 at 08:10 +0800, Yixun Lan wrote:
> When update the clock info for the UART controller in the EE domain,
> the driver explicitly require 'pclk' in order to work properly.
>
> With current logic of the code, the driver will go for the legacy clock probe
> routine[1] if it find current compatible string match to 'amlogic,meson-uart',
> which result in not requesting the 'pclk' clock, thus break the driver in the end.
>
> [1] drivers/tty/serial/meson_uart.c:685
>
> /* Use legacy way until all platforms switch to new bindings */
> if (of_device_is_compatible(pdev->dev.of_node, "amlogic,meson-uart"))
> ret = meson_uart_probe_clocks_legacy(pdev, port);
> else
> ret = meson_uart_probe_clocks(pdev, port);
I don't think you should add this code snip here. Anybody can look at the driver
code to see that
>
> Acked-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
^ permalink raw reply
* [PATCH v2 1/5] ARM64: dts: meson: uart: fix address space range
From: Jerome Brunet @ 2018-01-08 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180106001044.108163-2-yixun.lan@amlogic.com>
On Sat, 2018-01-06 at 08:10 +0800, Yixun Lan wrote:
> The address space range is actually 0x18, fixed here.
>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 10 +++++-----
> 2 files changed, 7 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH v2 3/6] clocksource/drivers: atmel-pit: allow unselecting ATMEL_PIT
From: Daniel Lezcano @ 2018-01-08 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108092255.7e0f9f07@bbrezillon>
On 08/01/2018 09:22, Boris Brezillon wrote:
> On Mon, 8 Jan 2018 08:23:02 +0100
> Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>
>> On 07/01/2018 19:44, Alexandre Belloni wrote:
>>> On 07/01/2018 at 19:07:13 +0100, Daniel Lezcano wrote:
>>>> On 05/01/2018 15:30, Alexandre Belloni wrote:
>>>>> With the new TCB clocksource driver, atmel platforms are now able to boot
>>>>> without the PIT driver. Allow unselecting it.
>>>>>
>>>>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>>>>> ---
>>>>> drivers/clocksource/Kconfig | 9 ++++++++-
>>>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
>>>>> index 5609572e0236..55ccfa0ba63b 100644
>>>>> --- a/drivers/clocksource/Kconfig
>>>>> +++ b/drivers/clocksource/Kconfig
>>>>> @@ -381,7 +381,14 @@ config ARMV7M_SYSTICK
>>>>>
>>>>> config ATMEL_PIT
>>>>> select TIMER_OF if OF
>>>>> - def_bool SOC_AT91SAM9 || SOC_SAMA5
>>>>> + bool "Atmel Periodic Interval Timer (PIT)"
>>>>> + depends on SOC_AT91SAM9 || SOC_SAMA5
>>>>> + default SOC_AT91SAM9 || SOC_SAMA5
>>>>> + help
>>>>> + Select this to get a clocksource based on the Atmel Periodic Interval
>>>>> + Timer. It has a relatively low resolution and the TC Block clocksource
>>>>> + should be preferred.
>>>>> + It also provides a clock event device.
>>>>
>>>> Please conform to the format:
>>>>
>>>> config ATMEL_PIT
>>>> bool "Atmel Periodic Interval Timer (PIT)" if COMPILE_TEST
>>>> select ...
>>>> help
>>>> bla bla
>>>>
>>>> and select ATMEL_PIT from the platform's Kconfig.
>>>>
>>>
>>> Well, the goal is actually to allow people to unselect it so we don't
>>> want the platform to select it.
>>
>> Why do you need people to unselect it?
>
> Because we have 2 possible clocksource for atmel platforms: the PIT or
> the TCB, if the TCB is selected there's no point in compiling the PIT
> driver.
Why the platform's Kconfig can't do that ?
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 0/2] pinctrl: meson: use one uniform 'function' name
From: Jerome Brunet @ 2018-01-08 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180108073328.205769-1-yixun.lan@amlogic.com>
On Mon, 2018-01-08 at 15:33 +0800, Yixun Lan wrote:
> These two patches are general improvement for meson pinctrl driver.
> It make the two pinctrl trees (ee/ao) to share one uniform 'function' name for
> one hardware block even its pin groups live inside two differet hardware domains,
> which for example EE vs AO domain here.
>
> This idea is motivated by Martin's question at [1]
>
> [1]
> http://lkml.kernel.org/r/CAFBinCCuQ-NK747+GHDkhZty_UMMgzCYOYFcNTrRDJgU8OM=Gw at mail.gmail.com
>
>
> Yixun Lan (2):
> pinctrl: meson: introduce a macro to have name/groups seperated
> pinctrl: meson-axg: correct the pin expansion of UART_AO_B
>
> drivers/pinctrl/meson/pinctrl-meson-axg.c | 4 ++--
> drivers/pinctrl/meson/pinctrl-meson.h | 8 +++++---
> 2 files changed, 7 insertions(+), 5 deletions(-)
Hi Yixun,
Honestly, I don't like the idea. I think it adds an unnecessary complexity.
I don't see the point of FUNCTION_EX(uart_ao_b, _z) when you could simply write
FUNCTION(uart_ao_b_z) ... especially when there is just a couple of function per
SoC available on different domains.
A pinctrl driver can already be challenging to understand at first, let's keep
it simple and avoid adding more macros.
Regards
Jerome
^ permalink raw reply
* [PATCH] imx6: fix pcie enumeration
From: Koen Vandeputte @ 2018-01-08 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105171828.GC24933@red-moon>
On 2018-01-05 18:18, Lorenzo Pieralisi wrote:
>>
>> Hi Lorenzo,
>>
>> This is exactly what I'm trying to explain:
>>
>> The host starts of with a (hardcoded today) subord of 1. [bits 16:23]
>>
>> Since commit a20c7f36bd3d, downstream devices cannot assign bus nr's
>> higher than the subord of the upstream device.
>> So in this case, scanning stops after the bridge as soon as bus 1 is
>> assigned .. :)
> There is one thing that I need to understand though. Before the commit
> above, how would enumeration works given that the subordinate bus number
> was set to 1 and that the kernel, AFAICS, does not overwrite it ?
>
> Are you able to send me a log (enumeration with debugging enabled and
> lspci) with the commit above reverted please ?
>
> Thanks,
> Lorenzo
>
Info below as requested:
[??? 0.116729] OF: PCI: host bridge /soc/pcie at 0x01000000 ranges:
[??? 0.116748] OF: PCI:?? No bus range found for /soc/pcie at 0x01000000,
using [bus 00-ff]
[??? 0.116777] OF: PCI:??? IO 0x01f80000..0x01f8ffff -> 0x00000000
[??? 0.116796] OF: PCI:?? MEM 0x01000000..0x01efffff -> 0x01000000
[??? 0.337917] imx6q-pcie 1ffc000.pcie: link up
[??? 0.337934] imx6q-pcie 1ffc000.pcie: Link: Gen2 disabled
[??? 0.337947] imx6q-pcie 1ffc000.pcie: link up
[??? 0.337958] imx6q-pcie 1ffc000.pcie: Link up, Gen1
[??? 0.338197] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[??? 0.338215] pci_bus 0000:00: root bus resource [bus 00-ff]
[??? 0.338230] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[??? 0.338243] pci_bus 0000:00: root bus resource [mem
0x01000000-0x01efffff]
[??? 0.338255] pci_bus 0000:00: scanning bus
[??? 0.338286] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[??? 0.338311] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[??? 0.338328] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[??? 0.338362] pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.338416] pci 0000:00:00.0: supports D1
[??? 0.338425] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[??? 0.338436] pci 0000:00:00.0: PME# disabled
[??? 0.338664] pci_bus 0000:00: fixups for bus
[??? 0.338676] PCI: bus0: Fast back to back transfers disabled
[??? 0.338692] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
[??? 0.338822] pci_bus 0000:01: scanning bus
[??? 0.338926] pci 0000:01:00.0: [10b5:8604] type 01 class 0x060400
[??? 0.338969] pci 0000:01:00.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.457984] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0001ffff]
[??? 0.458167] pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.458635] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[??? 0.458660] pci 0000:01:00.0: PME# disabled
[??? 0.458970] pci_bus 0000:01: fixups for bus
[??? 0.459027] PCI: bus1: Fast back to back transfers disabled
[??? 0.459052] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.459060] pci 0000:01:00.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.459115] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.459443] pci_bus 0000:02: busn_res: can not insert [bus 02-ff]
under [bus 01] (conflicts with (null) [bus 01])
[??? 0.459461] pci_bus 0000:02: scanning bus
[??? 0.459573] pci 0000:02:01.0: [10b5:8604] type 01 class 0x060400
[??? 0.459617] pci 0000:02:01.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.459865] pci 0000:02:01.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.460298] pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
[??? 0.460321] pci 0000:02:01.0: PME# disabled
[??? 0.460719] pci 0000:02:04.0: [10b5:8604] type 01 class 0x060400
[??? 0.460760] pci 0000:02:04.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.461009] pci 0000:02:04.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.461436] pci 0000:02:04.0: PME# supported from D0 D3hot D3cold
[??? 0.461460] pci 0000:02:04.0: PME# disabled
[??? 0.461841] pci 0000:02:05.0: [10b5:8604] type 01 class 0x060400
[??? 0.461883] pci 0000:02:05.0: calling ventana_pciesw_early_fixup+0x0/0xa4
[??? 0.462128] pci 0000:02:05.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.462553] pci 0000:02:05.0: PME# supported from D0 D3hot D3cold
[??? 0.462578] pci 0000:02:05.0: PME# disabled
[??? 0.463084] pci_bus 0000:02: fixups for bus
[??? 0.463231] PCI: bus2: Fast back to back transfers disabled
[??? 0.463255] pci 0000:02:01.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.463264] pci 0000:02:01.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.463319] pci 0000:02:04.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.463328] pci 0000:02:04.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.463378] pci 0000:02:05.0: scanning [bus 00-00] behind bridge, pass 0
[??? 0.463385] pci 0000:02:05.0: bridge configuration invalid ([bus
00-00]), reconfiguring
[??? 0.463435] pci 0000:02:01.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.463764] pci_bus 0000:03: scanning bus
[??? 0.463785] pci_bus 0000:03: fixups for bus
[??? 0.463791] PCI: bus3: Fast back to back transfers enabled
[??? 0.463803] pci_bus 0000:03: bus scan returning with max=03
[??? 0.463814] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
[??? 0.463833] pci_bus 0000:03: [bus 03] partially hidden behind bridge
0000:01 [bus 01]
[??? 0.463862] pci 0000:02:04.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.464178] pci_bus 0000:04: scanning bus
[??? 0.464197] pci_bus 0000:04: fixups for bus
[??? 0.464202] PCI: bus4: Fast back to back transfers enabled
[??? 0.464214] pci_bus 0000:04: bus scan returning with max=04
[??? 0.464223] pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
[??? 0.464242] pci_bus 0000:04: [bus 04] partially hidden behind bridge
0000:01 [bus 01]
[??? 0.464271] pci 0000:02:05.0: scanning [bus 00-00] behind bridge, pass 1
[??? 0.464586] pci_bus 0000:05: scanning bus
[??? 0.464691] pci 0000:05:00.0: [168c:0033] type 00 class 0x028000
[??? 0.464825] pci 0000:05:00.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit]
[??? 0.465036] pci 0000:05:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
[??? 0.465095] pci 0000:05:00.0: calling pci_fixup_ide_bases+0x0/0x4c
[??? 0.465117] pci 0000:05:00.0: calling quirk_no_bus_reset+0x0/0x20
[??? 0.465489] pci 0000:05:00.0: supports D1
[??? 0.465498] pci 0000:05:00.0: PME# supported from D0 D1 D3hot
[??? 0.465524] pci 0000:05:00.0: PME# disabled
[??? 0.465859] pci_bus 0000:05: fixups for bus
[??? 0.465903] PCI: bus5: Fast back to back transfers disabled
[??? 0.465916] pci_bus 0000:05: bus scan returning with max=05
[??? 0.465926] pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 05
[??? 0.465946] pci_bus 0000:05: [bus 05] partially hidden behind bridge
0000:01 [bus 01]
[??? 0.465965] pci_bus 0000:02: bus scan returning with max=05
[??? 0.465974] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 05
[??? 0.465984] pci_bus 0000:02: busn_res: can not insert [bus 02-05]
under [bus 01] (conflicts with (null) [bus 01])
[??? 0.466005] pci_bus 0000:02: [bus 02-05] partially hidden behind
bridge 0000:01 [bus 01]
[??? 0.466026] pci_bus 0000:01: bus scan returning with max=05
[??? 0.466033] pci 0000:00:00.0: bridge has subordinate 01 but max busn 05
[??? 0.466049] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 1
[??? 0.466059] pci_bus 0000:00: bus scan returning with max=01
[??? 0.466186] pci 0000:00:00.0: fixup irq: got 298
[??? 0.466196] pci 0000:00:00.0: assigning IRQ 298
[??? 0.466247] pci 0000:01:00.0: fixup irq: got 298
[??? 0.466254] pci 0000:01:00.0: assigning IRQ 298
[??? 0.466374] pci 0000:02:01.0: fixup irq: got 299
[??? 0.466382] pci 0000:02:01.0: assigning IRQ 299
[??? 0.466436] pci 0000:02:04.0: fixup irq: got 298
[??? 0.466442] pci 0000:02:04.0: assigning IRQ 298
[??? 0.466501] pci 0000:02:05.0: fixup irq: got 299
[??? 0.466509] pci 0000:02:05.0: assigning IRQ 299
[??? 0.466562] pci 0000:05:00.0: fixup irq: got 299
[??? 0.466569] pci 0000:05:00.0: assigning IRQ 299
[??? 0.466807] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[??? 0.466825] pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x012fffff]
[??? 0.466843] pci 0000:00:00.0: BAR 6: assigned [mem
0x01300000-0x0130ffff pref]
[??? 0.466862] pci 0000:01:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
[??? 0.466875] pci 0000:01:00.0: BAR 0: assigned [mem 0x01200000-0x0121ffff]
[??? 0.466908] pci 0000:02:05.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
[??? 0.466919] pci 0000:02:01.0: PCI bridge to [bus 03]
[??? 0.467001] pci 0000:02:04.0: PCI bridge to [bus 04]
[??? 0.467086] pci 0000:05:00.0: BAR 0: assigned [mem
0x01100000-0x0111ffff 64bit]
[??? 0.467160] pci 0000:05:00.0: BAR 6: assigned [mem
0x01120000-0x0112ffff pref]
[??? 0.467171] pci 0000:02:05.0: PCI bridge to [bus 05]
[??? 0.467206] pci 0000:02:05.0:?? bridge window [mem 0x01100000-0x011fffff]
[??? 0.467262] pci 0000:01:00.0: PCI bridge to [bus 02-05]
[??? 0.467297] pci 0000:01:00.0:?? bridge window [mem 0x01100000-0x011fffff]
[??? 0.467352] pci 0000:00:00.0: PCI bridge to [bus 01]
[??? 0.467364] pci 0000:00:00.0:?? bridge window [mem 0x01100000-0x012fffff]
[??? 0.467627] pcieport 0000:00:00.0: Signaling PME through PCIe PME
interrupt
[??? 0.467643] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[??? 0.467653] pci 0000:02:01.0: Signaling PME through PCIe PME interrupt
[??? 0.467662] pci 0000:02:04.0: Signaling PME through PCIe PME interrupt
[??? 0.467671] pci 0000:02:05.0: Signaling PME through PCIe PME interrupt
[??? 0.467680] pci 0000:05:00.0: Signaling PME through PCIe PME interrupt
[??? 0.467694] pcie_pme 0000:00:00.0:pcie001: service driver pcie_pme loaded
[??? 0.468019] pcieport 0000:01:00.0: enabling device (0140 -> 0142)
[??? 0.468147] pcieport 0000:01:00.0: enabling bus mastering
[??? 0.468886] pcieport 0000:02:01.0: enabling bus mastering
[??? 0.469576] pcieport 0000:02:04.0: enabling bus mastering
[??? 0.470165] pcieport 0000:02:05.0: enabling device (0140 -> 0142)
[??? 0.470275] pcieport 0000:02:05.0: enabling bus mastering
[ Node 4 | node-4 ] lspci -v
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
[Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 298
??? Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
??? Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: 01100000-012fffff [size=2M]
??? Prefetchable memory behind bridge: None
??? [virtual] Expansion ROM at 01300000 [disabled] [size=64K]
??? Capabilities: [40] Power Management version 3
??? Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
??? Capabilities: [70] Express Root Port (Slot-), MSI 00
??? Capabilities: [100] Advanced Error Reporting
??? Capabilities: [140] Virtual Channel
??? Kernel driver in use: pcieport
lspci: Unable to load libkmod resources: error -12
01:00.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 298
??? Memory at 01200000 (32-bit, non-prefetchable) [size=128K]
??? Bus: primary=01, secondary=02, subordinate=05, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: 01100000-011fffff [size=1M]
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Upstream Port, MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [138] Power Budgeting <?>
??? Capabilities: [148] Virtual Channel
??? Capabilities: [448] Vendor Specific Information: ID=0000 Rev=0
Len=0cc <?>
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
02:01.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 299
??? Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: None
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [148] Virtual Channel
??? Capabilities: [520] Access Control Services
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
02:04.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 298
??? Bus: primary=02, secondary=04, subordinate=04, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: None
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [148] Virtual Channel
??? Capabilities: [520] Access Control Services
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
02:05.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal decode])
??? Flags: bus master, fast devsel, latency 0, IRQ 299
??? Bus: primary=02, secondary=05, subordinate=05, sec-latency=0
??? I/O behind bridge: None
??? Memory behind bridge: 01100000-011fffff [size=1M]
??? Prefetchable memory behind bridge: None
??? Capabilities: [40] Power Management version 3
??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [68] Express Downstream Port (Slot+), MSI 00
??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604 4-lane,
4-Port PCI Express Gen 2 (5.0 GT/s) Switch
??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
??? Capabilities: [fb4] Advanced Error Reporting
??? Capabilities: [148] Virtual Channel
??? Capabilities: [520] Access Control Services
??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
Len=010 <?>
??? Kernel driver in use: pcieport
05:00.0 Network controller: Qualcomm Atheros AR958x 802.11abgn Wireless
Network Adapter (rev 01)
??? Subsystem: Device 19b6:d016
??? Flags: bus master, fast devsel, latency 0, IRQ 299
??? Memory at 01100000 (64-bit, non-prefetchable) [size=128K]
??? [virtual] Expansion ROM at 01120000 [disabled] [size=64K]
??? Capabilities: [40] Power Management version 3
??? Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
??? Capabilities: [70] Express Endpoint, MSI 00
??? Capabilities: [100] Advanced Error Reporting
??? Capabilities: [140] Virtual Channel
??? Capabilities: [300] Device Serial Number 00-00-00-00-00-00-00-00
??? Kernel driver in use: ath9k
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox