* [RFC PATCH v2 11/11] irqchip: mbigen: promote mbigen init
From: Hanjun Guo @ 2016-09-20 2:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DFBA0D.7040801@arm.com>
On 2016/9/19 18:12, Marc Zyngier wrote:
> On 19/09/16 10:49, Hanjun Guo wrote:
>> On 2016/9/15 23:24, Marc Zyngier wrote:
>>> On 14/09/16 15:21, Hanjun Guo wrote:
>>>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>>>
>>>> mbigen is an irqchip and it needs to be probed before
>>>> devices, same logic is used for SMMU and etc., let's
>>>> use arch_initcall instead of platform init for mbigen.
>>>>
>>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>>> Cc: Ma Jun <majun258@huawei.com>
>>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>>> ---
>>>> drivers/irqchip/irq-mbigen.c | 6 +++++-
>>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
>>>> index ca6add1..3a33de6 100644
>>>> --- a/drivers/irqchip/irq-mbigen.c
>>>> +++ b/drivers/irqchip/irq-mbigen.c
>>>> @@ -374,7 +374,11 @@ static struct platform_driver mbigen_platform_driver = {
>>>> .probe = mbigen_device_probe,
>>>> };
>>>>
>>>> -module_platform_driver(mbigen_platform_driver);
>>>> +static __init int mbigen_init(void)
>>>> +{
>>>> + return platform_driver_register(&mbigen_platform_driver);
>>>> +}
>>>> +arch_initcall(mbigen_init);
>>>>
>>>> MODULE_AUTHOR("Jun Ma <majun258@huawei.com>");
>>>> MODULE_AUTHOR("Yun Wu <wuyun.wu@huawei.com>");
>>>>
>>> I've already NACKed such a patch in the past, and I will carry on
>>> NACKing it until all the other avenues (like properly tracking device
>>> dependencies) have been explored and have been proven not to be fit for
>>> purpose.
>> I'd happy to work on this to make progress.
>>
>>> Rafael had proposed something around this subject last year, and I've
>> Sorry, obviously I missed something, could you give me the link about
>> Rafael's patches? I will pull back and test it on our hardware.
> Please see this discussion from almost a year ago:
>
> https://patchwork.kernel.org/patch/7407401/
>
> in which I give the existing pointers and explain why I'm pushing back
> on things like this patch.
We (Majun and me ) will look into it, thanks!
Hanjun
^ permalink raw reply
* [PATCH] mtd: s3c2410: add device tree support
From: Sergio Prado @ 2016-09-20 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f8907616-0d6b-37ef-1419-f6aedf3ddbdc@samsung.com>
On Mon, Sep 19, 2016 at 12:44:07PM +0200, Sylwester Nawrocki wrote:
> On 09/17/2016 05:22 PM, Sergio Prado wrote:
> > +static int s3c24xx_nand_probe_dt(struct platform_device *pdev)
> > +{
> > + const struct s3c24XX_nand_devtype_data *devtype_data;
> > + struct s3c2410_platform_nand *pdata;
> > + struct s3c2410_nand_info *info = platform_get_drvdata(pdev);
> > + struct device_node *np = pdev->dev.of_node, *child;
> > + const struct of_device_id *of_id;
> > + struct s3c2410_nand_set *sets;
> > +
> > + of_id = of_match_device(s3c24xx_nand_dt_ids, &pdev->dev);
> > + if (!of_id)
> > + return 1;
> > +
> > + devtype_data = of_id->data;
>
> You could make it a bit simpler with of_device_get_match_data().
I wasn't aware of this interface. I'll use it. Thanks!
>
> --
> Thanks,
> Sylwester
--
Sergio Prado
Embedded Labworks
Office: +55 11 2628-3461
Mobile: +55 11 97123-3420
^ permalink raw reply
* [PATCH] mtd: s3c2410: add device tree support
From: Sergio Prado @ 2016-09-20 2:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919091155.GB11118@leverpostej>
On Mon, Sep 19, 2016 at 10:11:55AM +0100, Mark Rutland wrote:
> On Sat, Sep 17, 2016 at 12:22:40PM -0300, Sergio Prado wrote:
> > Tested on FriendlyARM Mini2440
> >
> > Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> > ---
> > .../devicetree/bindings/mtd/samsung-s3c2410.txt | 70 +++++++++++
> > drivers/mtd/nand/s3c2410.c | 129 ++++++++++++++++++++-
> > include/linux/platform_data/mtd-nand-s3c2410.h | 1 +
> > 3 files changed, 195 insertions(+), 5 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
> > new file mode 100644
> > index 000000000000..1c39f6cf483b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
> > @@ -0,0 +1,70 @@
> > +* Samsung S3C2410 and compatible NAND flash controller
> > +
> > +Required properties:
> > +- compatible : The possible values are:
> > + "samsung,s3c2410-nand"
> > + "samsung,s3c2412-nand"
> > + "samsung,s3c2440-nand"
> > + "samsung,s3c6400-nand"
> > +- reg : register's location and length.
> > +- #address-cells, #size-cells : see nand.txt
> > +- clocks : phandle to the nand controller clock
> > +- clock-names : must contain "nand"
>
> Is there only one clock feeding into the NAND block? Is it actually
> called "nand", or does the datasheet not give the input a nme?
Yes, there is only one clock associated with the NAND controller. The
clock is called "NAND Flash Controller" clock by the datasheet.
>
> > +
> > +Optional properties:
> > +- samsung,tacls : time for active CLE/ALE to nWE/nOE
> > +- samsung,twrph0 : active time for nWE/nOE
> > +- samsung,twrph1 : time for release CLE/ALE from nWE/nOE inactive
>
> If these are necessary, what units are these in?
They are probably not necessary and will be removed as suggested by
Boris Brezillon.
>
> > +- samsung,ignore_unset_ecc : boolean to ignore error when we have
> > + 0xff,0xff,0xff read ECC, on the
> > + assumption that it is an un-eccd page
>
> s/_/-/ in property names, please.
OK. If I keep this property, I will change it to
samsung,ignore-unset-ecc.
>
> That said, this name reads like policy rather than a HW description.
> Why/when is this necessary to set?
I'll evaluate if this property is really necessary, as suggested by
Boris Brezillon.
>
> [...]
>
> > + of_property_read_u32(np, "samsung,tacls", &pdata->tacls);
> > + of_property_read_u32(np, "samsung,twrph0", &pdata->twrph0);
> > + of_property_read_u32(np, "samsung,twrph1", &pdata->twrph1);
>
> Are all values in the range [0, 0xffffffff] valid for these? If not, it
> would be a good idea to sanity-check the values.
OK.
>
> > + if (of_get_property(np, "samsung,ignore_unset_ecc", NULL))
> > + pdata->ignore_unset_ecc = 1;
>
> Use of_property_read_bool();
Right.
>
> [...]
>
> > + for_each_available_child_of_node(np, child) {
> > +
> > + sets->name = (char *)child->name;
> > + sets->of_node = child;
>
> Strictly speaking, you should increment the child node refcount here, as
> you maintain a reference to it and its name field.
OK.
>
> > + sets->nr_chips = 1;
> > +
> > + if (!of_property_match_string(child, "nand-ecc-mode", "none"))
> > + sets->disable_ecc = 1;
> > +
> > + if (of_get_property(child, "nand-on-flash-bbt", NULL))
> > + sets->flash_bbt = 1;
>
> Use of_property_read_bool().
OK.
>
> Thanks,
> Mark.
--
Sergio Prado
Embedded Labworks
Office: +55 11 2628-3461
Mobile: +55 11 97123-3420
^ permalink raw reply
* [PATCH] mtd: s3c2410: add device tree support
From: Sergio Prado @ 2016-09-20 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160917193123.762587d0@bbrezillon>
On Sat, Sep 17, 2016 at 07:31:23PM +0200, Boris Brezillon wrote:
> Hi Sergio,
>
> On Sat, 17 Sep 2016 12:22:40 -0300
> Sergio Prado <sergio.prado@e-labworks.com> wrote:
>
> > Tested on FriendlyARM Mini2440
> >
> > Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> > ---
> > .../devicetree/bindings/mtd/samsung-s3c2410.txt | 70 +++++++++++
>
> DT maintainers usually ask people to keep the DT bindings doc in a
> separate patch.
Right. I'll send the DT bindings doc in a separate patch.
>
> > drivers/mtd/nand/s3c2410.c | 129 ++++++++++++++++++++-
> > include/linux/platform_data/mtd-nand-s3c2410.h | 1 +
> > 3 files changed, 195 insertions(+), 5 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
> > new file mode 100644
> > index 000000000000..1c39f6cf483b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/samsung-s3c2410.txt
> > @@ -0,0 +1,70 @@
> > +* Samsung S3C2410 and compatible NAND flash controller
> > +
> > +Required properties:
> > +- compatible : The possible values are:
> > + "samsung,s3c2410-nand"
> > + "samsung,s3c2412-nand"
> > + "samsung,s3c2440-nand"
> > + "samsung,s3c6400-nand"
> > +- reg : register's location and length.
> > +- #address-cells, #size-cells : see nand.txt
> > +- clocks : phandle to the nand controller clock
> > +- clock-names : must contain "nand"
> > +
> > +Optional properties:
> > +- samsung,tacls : time for active CLE/ALE to nWE/nOE
> > +- samsung,twrph0 : active time for nWE/nOE
> > +- samsung,twrph1 : time for release CLE/ALE from nWE/nOE inactive
>
> Can you try to extract these information from the nand_sdr_timings
> struct instead of passing it in your DT?
OK. Looks like it is possible to extract the timings from
nand_sdr_timings. I'll try to do it.
>
> > +- samsung,ignore_unset_ecc : boolean to ignore error when we have
> > + 0xff,0xff,0xff read ECC, on the
> > + assumption that it is an un-eccd page
> > +
> > +Optional children nodes:
> > +Children nodes representing the available nand chips.
> > +
> > +Optional children properties:
> > +- nand-ecc-mode : see nand.txt
> > +- nand-on-flash-bbt : see nand.txt
> > +
> > +Each children device node may optionally contain a 'partitions' sub-node,
> > +which further contains sub-nodes describing the flash partition mapping.
> > +See partition.txt for more detail.
> > +
> > +Example:
> > +
> > +nand at 4e000000 {
>
> s/nand/nand-controller/
Ops. My bad.
>
> > + compatible = "samsung,s3c2440-nand";
> > + reg = <0x4e000000 0x40>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + clocks = <&clocks HCLK_NAND>;
> > + clock-names = "nand";
> > +
> > + samsung,tacls = <0>;
> > + samsung,twrph0 = <25>;
> > + samsung,twrph1 = <15>;
>
> As said above, I think these timings can be extracted from the
> nand_sdr_timings struct, which is know automatically attached to
> nand_chip at detection time.
Right.
>
> > + samsung,ignore_unset_ecc;
>
> Just discovered this ->ignore_unset_ecc property, and I don't
> understand why it's here for...
> Either you don't want to have ECC, and in this case you should set
> NAND_ECC_NONE, or you want to have ECC calculated, and in this case,
> the only valid situation where ECC bytes are 0xff is when the page is
> erased.
>
> If I'm right, please fix the driver instead of adding this DT property.
> If I'm wrong, could you explain in more detail when you have ECC bytes
> set to 0xff?
That's what I initially thought, but I must confess I just focused on
keeping the same interface. I'll try to understand better if this check is
really necessary.
>
> > +
> > + nand at 0 {
>
> @0 implies having a reg property. I don't see any in your example, and
> it's not document in the required property list.
>
> Is your controller able to connect to different CS?
No, it is not necessary. I'll remove @0.
>
> > + nand-ecc-mode = "soft";
> > + nand-on-flash-bbt;
> > +
> > + partitions {
> > + compatible = "fixed-partitions";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + partition at 0 {
> > + label = "u-boot";
> > + reg = <0 0x040000>;
> > + };
> > +
> > + partition at 40000 {
> > + label = "kernel";
> > + reg = <0x040000 0x500000>;
> > + };
> > + };
> > + };
> > +};
> > diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> > index d9309cf0ce2e..ecbb9c9c1e9a 100644
> > --- a/drivers/mtd/nand/s3c2410.c
> > +++ b/drivers/mtd/nand/s3c2410.c
> > @@ -39,6 +39,8 @@
> > #include <linux/slab.h>
> > #include <linux/clk.h>
> > #include <linux/cpufreq.h>
> > +#include <linux/of.h>
> > +#include <linux/of_device.h>
> >
> > #include <linux/mtd/mtd.h>
> > #include <linux/mtd/nand.h>
> > @@ -185,6 +187,26 @@ struct s3c2410_nand_info {
> > #endif
> > };
> >
> > +struct s3c24XX_nand_devtype_data {
> > + enum s3c_cpu_type type;
> > +};
> > +
> > +struct s3c24XX_nand_devtype_data s3c2410_nand_devtype_data = {
> > + .type = TYPE_S3C2410,
> > +};
> > +
> > +struct s3c24XX_nand_devtype_data s3c2412_nand_devtype_data = {
> > + .type = TYPE_S3C2412,
> > +};
> > +
> > +struct s3c24XX_nand_devtype_data s3c2440_nand_devtype_data = {
> > + .type = TYPE_S3C2440,
> > +};
> > +
> > +struct s3c24XX_nand_devtype_data s3c6400_nand_devtype_data = {
> > + .type = TYPE_S3C2412,
> > +};
> > +
> > /* conversion functions */
> >
> > static struct s3c2410_nand_mtd *s3c2410_nand_mtd_toours(struct mtd_info *mtd)
> > @@ -813,6 +835,8 @@ static void s3c2410_nand_init_chip(struct s3c2410_nand_info *info,
> > struct nand_chip *chip = &nmtd->chip;
> > void __iomem *regs = info->regs;
> >
> > + nand_set_flash_node(chip, set->of_node);
> > +
> > chip->write_buf = s3c2410_nand_write_buf;
> > chip->read_buf = s3c2410_nand_read_buf;
> > chip->select_chip = s3c2410_nand_select_chip;
> > @@ -947,6 +971,96 @@ static void s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
> > }
> > }
> >
> > +#ifdef CONFIG_OF_MTD
>
> Hm, I thought this symbol had been dropped, but apparently I forgot to
> remove it. You should make it dependent on CONFIG_OF, not CONFIG_OF_MTD.
>
> Anyway, I'm not even sure this ifdef is needed. Just test if
> pdev->dev.of_node is NULL in s3c24xx_nand_probe_dt() and return -1 in
> this case.
Right. I'll remove this ifdef.
>
> > +static const struct of_device_id s3c24xx_nand_dt_ids[] = {
> > + {
> > + .compatible = "samsung,s3c2410-nand",
> > + .data = &s3c2410_nand_devtype_data,
> > + }, {
> > + .compatible = "samsung,s3c2412-nand",
> > + .data = &s3c2412_nand_devtype_data,
> > + }, {
> > + .compatible = "samsung,s3c2440-nand",
> > + .data = &s3c2440_nand_devtype_data,
> > + }, {
> > + .compatible = "samsung,s3c6400-nand",
> > + .data = &s3c6400_nand_devtype_data,
> > + },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, s3c24xx_nand_dt_ids);
> > +
> > +static int s3c24xx_nand_probe_dt(struct platform_device *pdev)
> > +{
> > + const struct s3c24XX_nand_devtype_data *devtype_data;
> > + struct s3c2410_platform_nand *pdata;
> > + struct s3c2410_nand_info *info = platform_get_drvdata(pdev);
> > + struct device_node *np = pdev->dev.of_node, *child;
> > + const struct of_device_id *of_id;
> > + struct s3c2410_nand_set *sets;
> > +
> > + of_id = of_match_device(s3c24xx_nand_dt_ids, &pdev->dev);
> > + if (!of_id)
> > + return 1;
> > +
> > + devtype_data = of_id->data;
> > + info->cpu_type = devtype_data->type;
> > +
> > + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> > + if (!pdata)
> > + return -ENOMEM;
> > +
> > + pdev->dev.platform_data = pdata;
> > +
> > + of_property_read_u32(np, "samsung,tacls", &pdata->tacls);
> > + of_property_read_u32(np, "samsung,twrph0", &pdata->twrph0);
> > + of_property_read_u32(np, "samsung,twrph1", &pdata->twrph1);
> > +
> > + if (of_get_property(np, "samsung,ignore_unset_ecc", NULL))
> > + pdata->ignore_unset_ecc = 1;
> > +
> > + pdata->nr_sets = of_get_child_count(np);
> > + if (!pdata->nr_sets)
> > + return 0;
> > +
> > + sets = devm_kzalloc(&pdev->dev, sizeof(*sets) * pdata->nr_sets,
> > + GFP_KERNEL);
> > + if (!sets)
> > + return -ENOMEM;
> > +
> > + pdata->sets = sets;
> > +
> > + for_each_available_child_of_node(np, child) {
> > +
> > + sets->name = (char *)child->name;
> > + sets->of_node = child;
> > + sets->nr_chips = 1;
> > +
> > + if (!of_property_match_string(child, "nand-ecc-mode", "none"))
> > + sets->disable_ecc = 1;
> > +
> > + if (of_get_property(child, "nand-on-flash-bbt", NULL))
> > + sets->flash_bbt = 1;
> > +
>
> These properties are automatically extracted in nand_scan_ident(), why
> do you need to parse them twice?
Looks like the driver uses this properties before they are extracted in
nand_scan_ident(). But I'll try to understand better what the driver is
doing and prevent from parsing these properties twice.
>
> > + sets++;
> > + }
> > +
> > + return 0;
> > +}
> > +#else
> > +static int s3c24xx_nand_probe_dt(struct platform_device *pdev)
> > +{
> > + return 1;
> > +}
> > +#endif
> > +
> > +static void s3c24xx_nand_probe_pdata(struct platform_device *pdev)
> > +{
> > + struct s3c2410_nand_info *info = platform_get_drvdata(pdev);
> > +
> > + info->cpu_type = platform_get_device_id(pdev)->driver_data;
> > +}
> > +
> > /* s3c24xx_nand_probe
> > *
> > * called by device layer when it finds a device matching
> > @@ -956,8 +1070,7 @@ static void s3c2410_nand_update_chip(struct s3c2410_nand_info *info,
> > */
> > static int s3c24xx_nand_probe(struct platform_device *pdev)
> > {
> > - struct s3c2410_platform_nand *plat = to_nand_plat(pdev);
> > - enum s3c_cpu_type cpu_type;
> > + struct s3c2410_platform_nand *plat;
> > struct s3c2410_nand_info *info;
> > struct s3c2410_nand_mtd *nmtd;
> > struct s3c2410_nand_set *sets;
> > @@ -967,8 +1080,6 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
> > int nr_sets;
> > int setno;
> >
> > - cpu_type = platform_get_device_id(pdev)->driver_data;
> > -
> > info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
> > if (info == NULL) {
> > err = -ENOMEM;
> > @@ -991,6 +1102,14 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
> >
> > s3c2410_nand_clk_set_state(info, CLOCK_ENABLE);
> >
> > + err = s3c24xx_nand_probe_dt(pdev);
> > + if (err > 0)
> > + s3c24xx_nand_probe_pdata(pdev);
> > + else if (err < 0)
> > + goto exit_error;
> > +
> > + plat = to_nand_plat(pdev);
> > +
> > /* allocate and map the resource */
> >
> > /* currently we assume we have the one resource */
> > @@ -999,7 +1118,6 @@ static int s3c24xx_nand_probe(struct platform_device *pdev)
> >
> > info->device = &pdev->dev;
> > info->platform = plat;
> > - info->cpu_type = cpu_type;
> >
> > info->regs = devm_ioremap_resource(&pdev->dev, res);
> > if (IS_ERR(info->regs)) {
> > @@ -1156,6 +1274,7 @@ static struct platform_driver s3c24xx_nand_driver = {
> > .id_table = s3c24xx_driver_ids,
> > .driver = {
> > .name = "s3c24xx-nand",
> > + .of_match_table = s3c24xx_nand_dt_ids,
>
> If you keep the #ifdef CONFIG_OF section
>
> .of_match_table = of_match_ptr(s3c24xx_nand_dt_ids),
I'll remove the ifdef.
>
> > },
> > };
> >
> > diff --git a/include/linux/platform_data/mtd-nand-s3c2410.h b/include/linux/platform_data/mtd-nand-s3c2410.h
> > index c55e42ee57fa..9d20871e4bbd 100644
> > --- a/include/linux/platform_data/mtd-nand-s3c2410.h
> > +++ b/include/linux/platform_data/mtd-nand-s3c2410.h
> > @@ -40,6 +40,7 @@ struct s3c2410_nand_set {
> > char *name;
> > int *nr_map;
> > struct mtd_partition *partitions;
> > + struct device_node *of_node;
> > };
> >
> > struct s3c2410_platform_nand {
>
--
Sergio Prado
Embedded Labworks
Office: +55 11 2628-3461
Mobile: +55 11 97123-3420
^ permalink raw reply
* [PATCH 2/2] net: ethernet: broadcom: bcm63xx: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-09-20 1:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474210747-19627-2-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 18 Sep 2016 16:59:07 +0200
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* [PATCH 1/2] net: ethernet: broadcom: bcm63xx: use phydev from struct net_device
From: David Miller @ 2016-09-20 1:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474210747-19627-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 18 Sep 2016 16:59:06 +0200
> The private structure contain a pointer to phydev, but the structure
> net_device already contain such pointer. So we can remove the pointer
> phydev in the private structure, and update the driver to use the
> one contained in struct net_device.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* [PATCH 2/8] drm/rockchip: Get rid of some unnecessary code
From: Mark yao @ 2016-09-20 1:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAFQd5A0M6vAbXHhUDMMXsaWND0hzWcT71HzOsSSCHa--qh0dA@mail.gmail.com>
On 2016?09?18? 12:01, Tomasz Figa wrote:
> Hi Mark,
>
> On Sun, Sep 18, 2016 at 10:50 AM, Mark yao <mark.yao@rock-chips.com> wrote:
>> On 2016?09?14? 20:54, Tomasz Figa wrote:
>>> Current code implements prepare_fb and cleanup_fb callbacks only to
>>> grab/release fb references, which is already done by atomic framework
>>> when creating/destryoing plane state. Let's remove these
>>> unused bits.
>>>
>>> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
>>> ---
>>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ------------------
>>> 1 file changed, 18 deletions(-)
>>
>> Hi Tomasz
>>
>> I think we can't get rid of the prepare_fb and cleanup_fb
> I think I have to disagree. Please see below for detailed explanation.
>
>> see the reason:
>> commit 44d0237a26395ac94160cf23f32769013b365590
>> Author: Mark Yao <mark.yao@rock-chips.com>
>> Date: Fri Apr 29 11:37:20 2016 +0800
>>
>> drm/rockchip: vop: fix iommu crash with async atomic
>>
>> After async atomic_commit callback, drm_atomic_clean_old_fb will
>> clean all old fb, but because async, the old fb may be also on
>> the vop hardware, dma will access the old fb buffer, clean old
>> fb will cause iommu page fault.
> I think the above is not quite right. Atomic plane state holds a
> reference to its fb and old state is not supposed to be destroyed
> until the flip completes.
>
> Indeed current rockchip_atomic_commit implementation has following
> order of calls: rockchip_atomic_wait_for_complete(),
> drm_atomic_helper_cleanup_planes(), drm_atomic_state_free(). This
> means that .cleanup_fb() is called from
> drm_atomic_helper_cleanup_planes() just before drm_atomic_state_free()
> will release references by destroying old plane states. Note that both
> are called already after rockchip_atomic_wait_for_complete(), so it
> should be already safe to free the old fbs.
>
> So the above fix doesn't really do anything, possibly just covers the
> race condition of the original wait for vblank function by delaying
> drm_atomic_state_free() a bit.
>
> Moreover, the whole series has been thoroughly tested in Chrome OS 4.4
> kernel, including async commits. (There is still a possibility some
> newer upstream changes slightly modified the semantics, but I couldn't
> find such difference. Actually one of the advantages of atomic helpers
> was to avoid manually refcounting the fbs from the driver.)
>
> Best regards,
> Tomasz
>
Hi Tomasz
You are right, plane_duplicate_state/plane_destroy_state already protect
the old fbs.
we can get rid of prepare_fb and cleanup_fb.
--
?ark Yao
^ permalink raw reply
* [RFC] Arm64 boot fail with numa enable in BIOS
From: Leizhen (ThunderTown) @ 2016-09-20 1:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919144542.GK9005@arm.com>
On 2016/9/19 22:45, Will Deacon wrote:
> On Mon, Sep 19, 2016 at 03:07:19PM +0100, Mark Rutland wrote:
>> [adding LAKML, arm64 maintainers]
>
> I've also looped in Euler ThunderTown, since (a) he's at Huawei and is
> assumedly testing this stuff and (b) he has a fairly big NUMA patch
> series doing the rounds (some of which I've queued).
In my patch series, only one is used to resolve crashed problem, but it's related to device-tree.
>
>> On Mon, Sep 19, 2016 at 09:05:26PM +0800, Yisheng Xie wrote:
>> In future, please make sure to Cc LAKML along with relevant parties when
>> sending arm64 patches/queries.
>>
>> For everyone newly Cc'd, the original message (with attachments) can be
>> found at:
>>
>> http://lkml.kernel.org/r/7618d76d-bfa8-d8aa-59aa-06f9d90c1a98 at huawei.com
>>
>>> When I enable NUMA in BIOS for arm64, it failed to boot on v4.8-rc4-162-g071e31e.
>>
>> That commit ID doesn't seem to be in mainline (I can't find it in my
>> local tree). Which tree are you using? Do you have local patches
>> applied?
>
> That commit is in mainline:
>
> http://git.kernel.org/linus/071e31e
>
> It would be nice to know if the problem also exists on the arm64
> for-next/core branch.
>
> Will
>
>
>> I take it that by "enable NUMA in BIOS", you mean exposing SRAT to the
>> OS?
>>
>>> For the crash log, it seems caused by error number of cpumask.
>>> Any ideas about it?
>>
>> Much earlier in your log, there was a (non-fatal) warning, as below. Do
>> you see this without NUMA/SRAT enabled in your FW? I don't see how the
>> SRAT should affect the secondaries we try to bring online.
>>
>> Given your MPIDRs have Aff2 bits set, I wonder if we've conflated a
>> logical ID with a physical ID somewhere, and it just so happens that the
>> NUMA code is more likely to poke something based on that.
>>
>> Can you modify the warning in cpumask.h to dump the bad CPU number? That
>> would make it fairly clear if that's the case.
>>
>> Thanks,
>> Mark.
>>
>>> [ 0.297337] Detected PIPT I-cache on CPU1
>>> [ 0.297347] GICv3: CPU1: found redistributor 10001 region 1:0x000000004d140000
>>> [ 0.297356] CPU1: Booted secondary processor [410fd082]
>>> [ 0.297375] ------------[ cut here ]------------
>>> [ 0.320390] WARNING: CPU: 1 PID: 0 at ./include/linux/cpumask.h:121 gic_raise_softirq+0x128/0x17c
>>> [ 0.329356] Modules linked in:
>>> [ 0.332434]
>>> [ 0.333932] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0-rc4-00163-g803ea3a #21
>>> [ 0.341581] Hardware name: Hisilicon Hi1616 Evaluation Board (DT)
>>> [ 0.347735] task: ffff8013e9dd0000 task.stack: ffff8013e9dcc000
>>> [ 0.353714] PC is at gic_raise_softirq+0x128/0x17c
>>> [ 0.358550] LR is at gic_raise_softirq+0xa0/0x17c
>>> [ 0.363298] pc : [<ffff00000838c124>] lr : [<ffff00000838c09c>] pstate: 200001c5
>>> [ 0.370770] sp : ffff8013e9dcfde0
>>> [ 0.374112] x29: ffff8013e9dcfde0 x28: 0000000000000000
>>> [ 0.379476] x27: 000000000083207c x26: ffff000008ca5d70
>>> [ 0.384841] x25: 0000000100000001 x24: ffff000008d63ff3
>>> [ 0.390205] x23: 0000000000000000 x22: ffff000008cb0000
>>> [ 0.395569] x21: ffff00000884edb0 x20: 0000000000000001
>>> [ 0.400933] x19: 0000000100000000 x18: 0000000000000000
>>> [ 0.406298] x17: 0000000000000000 x16: 0000000003010066
>>> [ 0.411661] x15: ffff000008ca8000 x14: 0000000000000013
>>> [ 0.417025] x13: 0000000000000000 x12: 0000000000000013
>>> [ 0.422389] x11: 0000000000000013 x10: 0000000002e92aa7
>>> [ 0.427754] x9 : 0000000000000000 x8 : ffff8413eb6ca668
>>> [ 0.433118] x7 : ffff8413eb6ca690 x6 : 0000000000000000
>>> [ 0.438482] x5 : fffffffffffffffe x4 : 0000000000000000
>>> [ 0.443845] x3 : 0000000000000040 x2 : 0000000000000041
>>> [ 0.449209] x1 : 0000000000000000 x0 : 0000000000000001
>>> [ 0.454573]
>>> [ 0.456069] ---[ end trace b58e70f3295a8cd7 ]---
>>> [ 0.460730] Call trace:
>>> [ 0.463193] Exception stack(0xffff8013e9dcfc10 to 0xffff8013e9dcfd40)
>>> [ 0.469699] fc00: 0000000100000000 0001000000000000
>>> [ 0.477611] fc20: ffff8013e9dcfde0 ffff00000838c124 ffff000008d72228 ffff8013e9dcff70
>>> [ 0.485524] fc40: ffff000008d72608 ffff000008ab02a4 0000000000000000 0000000000000000
>>> [ 0.493436] fc60: 0000000000000000 3464313430303030 0000000000000000 0000000000000000
>>> [ 0.501348] fc80: ffff8013e9dcfc90 ffff00000836e678 ffff8013e9dcfca0 ffff00000836e910
>>> [ 0.509259] fca0: ffff8013e9dcfd30 ffff00000836ec10 0000000000000001 0000000000000000
>>> [ 0.517171] fcc0: 0000000000000041 0000000000000040 0000000000000000 fffffffffffffffe
>>> [ 0.525083] fce0: 0000000000000000 ffff8413eb6ca690 ffff8413eb6ca668 0000000000000000
>>> [ 0.532995] fd00: 0000000002e92aa7 0000000000000013 0000000000000013 0000000000000000
>>> [ 0.540907] fd20: 0000000000000013 ffff000008ca8000 0000000003010066 0000000000000000
>>> [ 0.548819] [<ffff00000838c124>] gic_raise_softirq+0x128/0x17c
>>> [ 0.554713] [<ffff00000808e1f4>] smp_send_reschedule+0x34/0x3c
>>> [ 0.560605] [<ffff0000080ddf18>] resched_curr+0x40/0x5c
>>> [ 0.565881] [<ffff0000080de650>] check_preempt_curr+0x58/0xa0
>>> [ 0.571685] [<ffff0000080de6b0>] ttwu_do_wakeup+0x18/0x80
>>> [ 0.577136] [<ffff0000080de790>] ttwu_do_activate+0x78/0x88
>>> [ 0.582763] [<ffff0000080df5cc>] try_to_wake_up+0x1f8/0x300
>>> [ 0.588390] [<ffff0000080df79c>] default_wake_function+0x10/0x18
>>> [ 0.594458] [<ffff0000080f3210>] __wake_up_common+0x5c/0x9c
>>> [ 0.600085] [<ffff0000080f3264>] __wake_up_locked+0x14/0x1c
>>> [ 0.605712] [<ffff0000080f3e10>] complete+0x40/0x5c
>>> [ 0.610635] [<ffff00000808dba8>] secondary_start_kernel+0x148/0x1a8
>>> [ 0.616965] [<00000000000831a8>] 0x831a8
>>
>
> .
>
^ permalink raw reply
* [RFC PATCH] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Duc Dang @ 2016-09-20 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919200614.GB21763@localhost>
Hi Bjorn,
Thanks for reviewing my RFC patch.
On Mon, Sep 19, 2016 at 1:06 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> Hi Duc,
>
> On Sat, Sep 17, 2016 at 07:24:38AM -0700, Duc Dang wrote:
>> PCIe controller in X-Gene SoCs is not ECAM compliant: software
>> needs to configure additional concontroller register to address
>> device at bus:dev:function.
>>
>> This patch depends on "ECAM quirks handling for ARM64 platforms"
>> series (http://www.spinics.net/lists/arm-kernel/msg530692.html)
>> to address the limitation above for X-Gene PCIe controller.
>>
>> The quirk will only be applied for X-Gene PCIe MCFG table with
>> OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>>
>> Signed-off-by: Duc Dang <dhdang@apm.com>
>> ---
>> drivers/acpi/pci_mcfg.c | 32 +++++
>> drivers/pci/host/Makefile | 2 +-
>> drivers/pci/host/pci-xgene-ecam.c | 280 ++++++++++++++++++++++++++++++++++++++
>> include/linux/pci-ecam.h | 5 +
>> 4 files changed, 318 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/pci/host/pci-xgene-ecam.c
>
> This adds a bunch of stuff, but doesn't remove anything. So I assume
> it's adding new functionality that didn't exist before. What is it?
This patch only adds the ability for X-Gene PCIe controller to be
probable in ACPI boot mode. All the 'quirk' code added is for ECAM to
work with X-Gene.
>
> I sort of expected this to also remove, for example, the seemingly
> identical xgene_pcie_config_read32() in drivers/pci/host/pci-xgene.c.
> Actually, a bunch of this code seems to be duplicated from there. It
> doesn't seem like we should end up with all this duplicated code.
>
> I'd really like it better if all this could get folded into
> pci-xgene.c so we don't end up with more files.
I am still debating whether to put this X-Gene ECAM quirk code into
drivers/acpi or keep it here in drivers/pci/host. But given the
direction of other quirk patches for ThunderX and HiSi, seem like the
quirk will stay in drivers/pci/host. I can definitely fold the new
quirk code into pci-xgene.c as you suggested and eliminate the
identical one.
>
>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
>> index ddf338b..adce35f 100644
>> --- a/drivers/acpi/pci_mcfg.c
>> +++ b/drivers/acpi/pci_mcfg.c
>> @@ -123,6 +123,38 @@ static struct mcfg_fixup mcfg_quirks[] = {
>> { "CAVIUM", "THUNDERX", 2, 13, MCFG_BUS_ANY, &pci_thunder_ecam_ops,
>> MCFG_RES_EMPTY},
>> #endif
>> +#ifdef CONFIG_PCI_XGENE
>> + {"APM ", "XGENE ", 1, 0, MCFG_BUS_ANY,
>> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 1, 1, MCFG_BUS_ANY,
>> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 1, 2, MCFG_BUS_ANY,
>> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 1, 3, MCFG_BUS_ANY,
>> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 1, 4, MCFG_BUS_ANY,
>> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 2, 0, MCFG_BUS_ANY,
>> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 2, 1, MCFG_BUS_ANY,
>> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 2, 2, MCFG_BUS_ANY,
>> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 2, 3, MCFG_BUS_ANY,
>> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 2, 4, MCFG_BUS_ANY,
>> + &xgene_v1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 3, 0, MCFG_BUS_ANY,
>> + &xgene_v2_1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 3, 1, MCFG_BUS_ANY,
>> + &xgene_v2_1_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 4, 0, MCFG_BUS_ANY,
>> + &xgene_v2_2_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 4, 1, MCFG_BUS_ANY,
>> + &xgene_v2_2_pcie_ecam_ops, MCFG_RES_EMPTY},
>> + {"APM ", "XGENE ", 4, 2, MCFG_BUS_ANY,
>> + &xgene_v2_2_pcie_ecam_ops, MCFG_RES_EMPTY},
>
> Most of these are the same. Let's add a macro that fills in the
> boilerplate so each entry only contains the variable parts. I'm going
> to propose the same for the ThunderX quirks.
I will follow up on this.
>
>> +#endif
>> };
>>
>> static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
>> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
>> index 8843410..af4f505 100644
>> --- a/drivers/pci/host/Makefile
>> +++ b/drivers/pci/host/Makefile
>> @@ -15,7 +15,7 @@ obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
>> obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
>> obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
>> obj-$(CONFIG_PCIE_XILINX_NWL) += pcie-xilinx-nwl.o
>> -obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
>> +obj-$(CONFIG_PCI_XGENE) += pci-xgene.o pci-xgene-ecam.o
>> obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
>> obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
>> obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
>> diff --git a/drivers/pci/host/pci-xgene-ecam.c b/drivers/pci/host/pci-xgene-ecam.c
>> new file mode 100644
>> index 0000000..b66a04f
>> --- /dev/null
>> +++ b/drivers/pci/host/pci-xgene-ecam.c
>> @@ -0,0 +1,280 @@
>> +/*
>> + * APM X-Gene PCIe ECAM fixup driver
>> + *
>> + * Copyright (c) 2016, Applied Micro Circuits Corporation
>> + * Author:
>> + * Duc Dang <dhdang@apm.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_pci.h>
>> +#include <linux/pci-acpi.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pci-ecam.h>
>> +
>> +#ifdef CONFIG_ACPI
>> +#define RTDID 0x160
>> +#define ROOT_CAP_AND_CTRL 0x5C
>> +
>> +/* PCIe IP version */
>> +#define XGENE_PCIE_IP_VER_UNKN 0
>> +#define XGENE_PCIE_IP_VER_1 1
>> +#define XGENE_PCIE_IP_VER_2 2
>
> We only use XGENE_PCIE_IP_VER_1, so I think the others should be
> removed. I think it would be nicer to have a "crs_broken:1" bit set
> by the probe path, and get rid of the version field altogether.
We do use XGENE_PCIE_IP_VER_2 for X-Gene v2 PCIe controller, but your
idea about using crs_broken is much better. I will make change
following that. This will affect DT booting too.
>
>> +#define XGENE_CSR_LENGTH 0x10000
>> +
>> +struct xgene_pcie_acpi_root {
>> + void __iomem *csr_base;
>> + u32 version;
>> +};
>
> I think this should be folded into struct xgene_pcie_port so we don't
> have to allocate and manage it separately.
I will need to look into this more. When booting with ACPI mode, the
code in pci-xgene.c is not used (except the cfg read/write functions
that are shared with ECAM quirk code), so puting these into
xgene_pcie_port will force ECAM quirk code to allocate this structure
as well.
>
>> +static int xgene_v1_pcie_ecam_init(struct pci_config_window *cfg)
>> +{
>> + struct xgene_pcie_acpi_root *xgene_root;
>> + struct device *dev = cfg->parent;
>> + u32 csr_base;
>> +
>> + xgene_root = devm_kzalloc(dev, sizeof(*xgene_root), GFP_KERNEL);
>> + if (!xgene_root)
>> + return -ENOMEM;
>> +
>> + switch (cfg->res.start) {
>> + case 0xE0D0000000ULL:
>> + csr_base = 0x1F2B0000;
>> + break;
>> + case 0xD0D0000000ULL:
>> + csr_base = 0x1F2C0000;
>> + break;
>> + case 0x90D0000000ULL:
>> + csr_base = 0x1F2D0000;
>> + break;
>> + case 0xA0D0000000ULL:
>> + csr_base = 0x1F500000;
>> + break;
>> + case 0xC0D0000000ULL:
>> + csr_base = 0x1F510000;
>> + break;
>
> Ugh. What in the world is going on here? Apparently we're testing a
> host bridge resource against this hard-coded list of random values,
> and based on that, we know about this *other* list of hard-coded CSR
> ranges? This is not the way resource discovery normally works ;)
Yes, this is very ugly :(
But discovering CSR regions by using acpi_walk_resource for each root
port is not a preferred solution because of the concern that it may
open a backdoor for continuously abusive usage of the quirk for new
version of SoCs (https://patchwork.kernel.org/patch/9178791/, last 2
comments from Lorenzo and Ard)
>
>> + default:
>> + return -ENODEV;
>> + }
>> +
>> + xgene_root->csr_base = ioremap(csr_base, XGENE_CSR_LENGTH);
>
> There should be a request_region() somewhere, too. Ideal would be to
> use devm_ioremap_resource(), but I don't know where this apparent
> resource is coming from.
Yes, I will use request_region/devm_ioremap_resource here.
>
>> + if (!xgene_root->csr_base) {
>> + kfree(xgene_root);
>> + return -ENODEV;
>> + }
>> +
>> + xgene_root->version = XGENE_PCIE_IP_VER_1;
>> +
>> + cfg->priv = xgene_root;
>> +
>> + return 0;
>> +}
>> +
>> +static int xgene_v2_1_pcie_ecam_init(struct pci_config_window *cfg)
>> +{
>> + struct xgene_pcie_acpi_root *xgene_root;
>> + struct device *dev = cfg->parent;
>> + resource_size_t csr_base;
>> +
>> + xgene_root = devm_kzalloc(dev, sizeof(*xgene_root), GFP_KERNEL);
>> + if (!xgene_root)
>> + return -ENOMEM;
>> +
>> + switch (cfg->res.start) {
>> + case 0xC0D0000000ULL:
>> + csr_base = 0x1F2B0000;
>> + break;
>> + case 0xA0D0000000ULL:
>> + csr_base = 0x1F2C0000;
>> + break;
>> + default:
>> + return -ENODEV;
>> + }
>> +
>> + xgene_root->csr_base = ioremap(csr_base, XGENE_CSR_LENGTH);
>> + if (!xgene_root->csr_base) {
>> + kfree(xgene_root);
>> + return -ENODEV;
>> + }
>> +
>> + xgene_root->version = XGENE_PCIE_IP_VER_2;
>> +
>> + cfg->priv = xgene_root;
>> +
>> + return 0;
>> +}
>> +
>> +static int xgene_v2_2_pcie_ecam_init(struct pci_config_window *cfg)
>> +{
>> + struct xgene_pcie_acpi_root *xgene_root;
>> + struct device *dev = cfg->parent;
>> + resource_size_t csr_base;
>> +
>> + xgene_root = devm_kzalloc(dev, sizeof(*xgene_root), GFP_KERNEL);
>> + if (!xgene_root)
>> + return -ENOMEM;
>> +
>> + switch (cfg->res.start) {
>> + case 0xE0D0000000ULL:
>> + csr_base = 0x1F2B0000;
>> + break;
>> + case 0xA0D0000000ULL:
>> + csr_base = 0x1F500000;
>> + break;
>> + case 0x90D0000000ULL:
>> + csr_base = 0x1F2D0000;
>> + break;
>> + default:
>> + return -ENODEV;
>> + }
>> +
>> + xgene_root->csr_base = ioremap(csr_base, XGENE_CSR_LENGTH);
>> + if (!xgene_root->csr_base) {
>> + kfree(xgene_root);
>> + return -ENODEV;
>> + }
>> +
>> + xgene_root->version = XGENE_PCIE_IP_VER_2;
>> +
>> + cfg->priv = xgene_root;
>> +
>> + return 0;
>> +}
>> +/*
>> + * For Configuration request, RTDID register is used as Bus Number,
>> + * Device Number and Function number of the header fields.
>> + */
>> +static void xgene_pcie_set_rtdid_reg(struct pci_bus *bus, uint devfn)
>> +{
>> + struct pci_config_window *cfg = bus->sysdata;
>> + struct xgene_pcie_acpi_root *port = cfg->priv;
>> + unsigned int b, d, f;
>> + u32 rtdid_val = 0;
>> +
>> + b = bus->number;
>> + d = PCI_SLOT(devfn);
>> + f = PCI_FUNC(devfn);
>> +
>> + if (!pci_is_root_bus(bus))
>> + rtdid_val = (b << 8) | (d << 3) | f;
>> +
>> + writel(rtdid_val, port->csr_base + RTDID);
>> + /* read the register back to ensure flush */
>> + readl(port->csr_base + RTDID);
>> +}
>> +
>> +/*
>> + * X-Gene PCIe port uses BAR0-BAR1 of RC's configuration space as
>> + * the translation from PCI bus to native BUS. Entire DDR region
>> + * is mapped into PCIe space using these registers, so it can be
>> + * reached by DMA from EP devices. The BAR0/1 of bridge should be
>> + * hidden during enumeration to avoid the sizing and resource allocation
>> + * by PCIe core.
>> + */
>> +static bool xgene_pcie_hide_rc_bars(struct pci_bus *bus, int offset)
>> +{
>> + if (pci_is_root_bus(bus) && ((offset == PCI_BASE_ADDRESS_0) ||
>> + (offset == PCI_BASE_ADDRESS_1)))
>> + return true;
>> +
>> + return false;
>> +}
>> +
>> +void __iomem *xgene_pcie_ecam_map_bus(struct pci_bus *bus,
>> + unsigned int devfn, int where)
>> +{
>> + struct pci_config_window *cfg = bus->sysdata;
>> + unsigned int busn = bus->number;
>> + void __iomem *base;
>> +
>> + if (busn < cfg->busr.start || busn > cfg->busr.end)
>> + return NULL;
>> +
>> + if ((pci_is_root_bus(bus) && devfn != 0) ||
>> + xgene_pcie_hide_rc_bars(bus, where))
>> + return NULL;
>> +
>> + xgene_pcie_set_rtdid_reg(bus, devfn);
>> +
>> + if (busn > cfg->busr.start)
>> + base = cfg->win + (1 << cfg->ops->bus_shift);
>> + else
>> + base = cfg->win;
>> +
>> + return base + where;
>> +}
>> +
>> +static int xgene_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
>> + int where, int size, u32 *val)
>> +{
>> + struct pci_config_window *cfg = bus->sysdata;
>> + struct xgene_pcie_acpi_root *port = cfg->priv;
>> +
>> + if (pci_generic_config_read32(bus, devfn, where & ~0x3, 4, val) !=
>> + PCIBIOS_SUCCESSFUL)
>> + return PCIBIOS_DEVICE_NOT_FOUND;
>> +
>> + /*
>> + * The v1 controller has a bug in its Configuration Request
>> + * Retry Status (CRS) logic: when CRS is enabled and we read the
>> + * Vendor and Device ID of a non-existent device, the controller
>> + * fabricates return data of 0xFFFF0001 ("device exists but is not
>> + * ready") instead of 0xFFFFFFFF ("device does not exist"). This
>> + * causes the PCI core to retry the read until it times out.
>> + * Avoid this by not claiming to support CRS.
>> + */
>> + if (pci_is_root_bus(bus) && (port->version == XGENE_PCIE_IP_VER_1) &&
>> + ((where & ~0x3) == ROOT_CAP_AND_CTRL))
>> + *val &= ~(PCI_EXP_RTCAP_CRSVIS << 16);
>> +
>> + if (size <= 2)
>> + *val = (*val >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
>> +
>> + return PCIBIOS_SUCCESSFUL;
>> +}
>> +
>> +struct pci_ecam_ops xgene_v1_pcie_ecam_ops = {
>> + .bus_shift = 16,
>> + .init = xgene_v1_pcie_ecam_init,
>> + .pci_ops = {
>> + .map_bus = xgene_pcie_ecam_map_bus,
>> + .read = xgene_pcie_config_read32,
>> + .write = pci_generic_config_write,
>> + }
>> +};
>> +
>> +struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops = {
>> + .bus_shift = 16,
>> + .init = xgene_v2_1_pcie_ecam_init,
>> + .pci_ops = {
>> + .map_bus = xgene_pcie_ecam_map_bus,
>> + .read = xgene_pcie_config_read32,
>> + .write = pci_generic_config_write,
>> + }
>> +};
>> +
>> +struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops = {
>> + .bus_shift = 16,
>> + .init = xgene_v2_2_pcie_ecam_init,
>> + .pci_ops = {
>> + .map_bus = xgene_pcie_ecam_map_bus,
>> + .read = xgene_pcie_config_read32,
>> + .write = pci_generic_config_write,
>> + }
>> +};
>> +#endif
>> diff --git a/include/linux/pci-ecam.h b/include/linux/pci-ecam.h
>> index 35f0e81..40da3e7 100644
>> --- a/include/linux/pci-ecam.h
>> +++ b/include/linux/pci-ecam.h
>> @@ -65,6 +65,11 @@ extern struct pci_ecam_ops pci_thunder_pem_ops;
>> #ifdef CONFIG_PCI_HOST_THUNDER_ECAM
>> extern struct pci_ecam_ops pci_thunder_ecam_ops;
>> #endif
>> +#ifdef CONFIG_PCI_XGENE
>> +extern struct pci_ecam_ops xgene_v1_pcie_ecam_ops;
>> +extern struct pci_ecam_ops xgene_v2_1_pcie_ecam_ops;
>> +extern struct pci_ecam_ops xgene_v2_2_pcie_ecam_ops;
>> +#endif
>>
>> #ifdef CONFIG_PCI_HOST_GENERIC
>> /* for DT-based PCI controllers that support ECAM */
>> --
>> 1.9.1
>>
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH v2 3/7] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank
From: Tomasz Figa @ 2016-09-20 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57CD27FC.2020201@samsung.com>
Hi Chanwoo,
Sorry for late reply. Yours was quick compared to mine. ;(
2016-09-05 17:08 GMT+09:00 Chanwoo Choi <cw00.choi@samsung.com>:
> Hi Tomasz,
>
> I'm sorry for late reply.
>
> On 2016? 08? 25? 23:41, Tomasz Figa wrote:
>> 2016-08-25 23:30 GMT+09:00 Tomasz Figa <tomasz.figa@gmail.com>:
>>>> + }
>>>> +
>>>> +#define EXYNOS_PIN_BANK_EINTN_EXT(pins, reg, id, pctl_idx, eint_idx) \
>>>> + { \
>>>> + .type = &bank_type_off, \
>>>> + .pctl_offset = reg, \
>>>> + .nr_pins = pins, \
>>>> + .eint_type = EINT_TYPE_NONE, \
>>>> + .name = id, \
>>>> + .pctl_res_idx = pctl_idx, \
>>>> + .eint_res_idx = eint_dix \
>>>> + }
>>>
>>> Your patch 4/7 doesn't seem to use this one, so this is dead code for
>>> the time being. Please add when there is real need for it.
>>>
>>> Also it doesn't really make much sense to have index for both pctl and
>>> eint. Please define first entry of regs property as always pointing to
>>> pctl registers and by also eint registers for usual controllers. Then
>>> second regs entry would be eint registers for controllers with
>>> separate register blocks. Then there is only a need to have
>>> eint_res_idx in the driver and no need for pctl_res_idx, because it
>>> would be always 0.
>>
>> Ah, sorry, I got confused again by which registers are where in these
>> GPF banks. Let's make it the other way around and make DT contain eint
>> registers in first regs entry and hardcode eint_res_idx to 0 for the
>> time being.
>
> I got with slight confusion.
> Do you mean that you want to remove the 'eint_res_idx' because
> it is always zero(0) as your comment. And do you agree to add 'pctl_res_idx'?
>
> Also, as you commented, the eint_res_idx for both GPA and GPFx is zero(0).
>
> Example:
> pinctrl_alive: pinctrl at 10580000 {
> compatible = "samsung,exynos5433-pinctrl";
> /* ALIVE domain , IMEM domain */
> reg = <0x10580000 0x1a20>, <0x11090000 0x100>;
>
> wakeup-interrupt-controller {
> compatible = "samsung,exynos7-wakeup-eint";
> interrupts = <GIC_SPI 16 0>;
> };
> };
>
> GPA's eint_res_idx is 0
> GPA's pctl_res_idx is 0
>
> GPFx's eint_res_idx is 0
> GPFx's pctl_res_idx is 1
Yeah, that's right. I just want to avoid adding eint_res_idx until it
is found to be really needed.
>
>
> However it should be still beneficial to refactor the code
>> and calculate per-bank eint_base to avoid adding the offset every
>> time, similarly to pctl_base/offset, from my suggestion below.
>
> I agree. I'll modify it according to your comment.
Thanks. Looking forward to the patch.
Best regards,
Tomasz
^ permalink raw reply
* linux-next: manual merge of the amlogic tree with the arm-soc tree
From: Stephen Rothwell @ 2016-09-20 0:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the amlogic tree got a conflict in:
arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
between commit:
8735053d7968 ("ARM64: dts: meson-gxbb-p20x: Enable USB Nodes")
from the arm-soc tree and commit:
d82801a385a1 ("ARM64: dts: meson-gxbb-p20x: Enable USB Nodes")
from the amlogic tree.
This patch was modified before being merged into the arm-soc tree.
Please clean up the amlogic tree.
I fixed it up (I used the arm-soc tree version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
From: Emil Velikov @ 2016-09-19 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473081421-16555-18-git-send-email-peter.griffin@linaro.org>
On 5 September 2016 at 14:16, Peter Griffin <peter.griffin@linaro.org> wrote:
> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
>From a humble skim through remoteproc, drm and a few other subsystems
I think the above is wrong. All the drivers (outside of remoteproc),
that I've seen, depend on the core component, they don't select it.
Furthermore most places explicitly hide the drivers from the menu if
the core component isn't enabled.
Is there something that requires such a different/unusual behaviour in
remoteproc ?
Regards,
Emil
^ permalink raw reply
* [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Brian Norris @ 2016-09-19 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DBA81F.2060404@arm.com>
On Fri, Sep 16, 2016 at 09:06:55AM +0100, Marc Zyngier wrote:
> Hi Brian,
Hi Marc,
Thanks for the quick response.
> On 16/09/16 06:49, Brian Norris wrote:
> > Since commit 4fbcdc813fb9 ("clocksource: arm_arch_timer: Use clocksource
> > for suspend timekeeping"), this driver assumes that the ARM architected
> > timer keeps running in suspend. This is not the case for some ARM SoCs,
> > depending on the HW state used for system suspend. Let's not assume that
> > all SoCs support this, and instead only support this if the device tree
> > explicitly tells us it's "always on". In all other cases, just fall back
> > to the RTC. This should be relatively harmless.
>
> I'm afraid you're confusing two things:
> - the counter, which *must* carry on counting no matter what, as
> (quoting the ARM ARM) "The system counter must be implemented in an
> always-on power domain"
> - the timer, which is allowed to be powered off, and can be tagged with
> the "always-on" property to indicate that it is guaranteed to stay up
> (which in practice only exists in virtual machines and never on real HW).
Indeed, sorry for that confusion, and thanks for the explanations.
> If your counter does stop counting when suspended, then this is starting
> to either feel like a HW bug, or someone is killing the clock that feeds
> this counter when entering suspend.
>
> If this is the former, then we need a separate quirk to indicate the
> non-standard behaviour. If it is the latter, don't do it! ;-)
It's beginning to seem more like a HW quirk which yields nonstandard
behavior. AIUI, this SoC normally runs the counter off its 24 MHz clock,
but for low power modes, this "always-on" domain switches over to a 32
KHz alternative clock. Unfortunately, the counter doesn't actually tick
when run this way. I'm trying to confirm with the chip designers
(Rockchip, RK3399) about the nature of the quirk, but I think we'll need
a separate DT flag for this behavior.
Brian
^ permalink raw reply
* [PATCH] ARM: dts: Add power button support for igepv5
From: Tony Lindgren @ 2016-09-19 23:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMVEqEkKrw2eH3L6+te5MZLqxBT2jUiRO-KNuS+9nuNYvihCRA@mail.gmail.com>
* Pau Pajuel <ppajuel@gmail.com> [160919 01:13]:
> Hello Tony,
>
> 2016-09-14 3:26 GMT+02:00 Javier Martinez Canillas <javier@osg.samsung.com>:
> > Hello Tony,
> >
> > On 09/09/2016 05:07 PM, Tony Lindgren wrote:
> >> Add power button support for igepv5.
> >>
> >> Cc: Agust? Fontquerni i Gorchs <afontquerni@iseebcn.com>
> >> Cc: Enric Balletbo Serra <eballetbo@gmail.com>
> >> Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> >> Cc: Pau Pajuel <ppajuel@gmail.com>
> >> Signed-off-by: Tony Lindgren <tony@atomide.com>
> >> ---
> >
> > I don't have a schematics for this board, but the patch looks good to me.
> Patch has an errata. Power button is GPIO_ACTIVE_LOW instead GPIO_ACTIVE_HIGH.
Oops sorry about that, here's an incremental fix.
Regards,
Tony
8< -----------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 19 Sep 2016 16:02:12 -0700
Subject: [PATCH] ARM: dts: Fix igepv5 power button GPIO direction
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
It should be GPIO_ACTIVE_LOW instead of GPIO_ACTIVE_HIGH as
pointed out by Pau Pajuel <ppajuel@gmail.com>.
Cc: Agust? Fontquerni i Gorchs <afontquerni@iseebcn.com>
Cc: Enric Balletbo Serra <eballetbo@gmail.com>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>
Cc: Pau Pajuel <ppajuel@gmail.com>
Fixes: b118c6a6ffa1 ("ARM: dts: Add power button support for igepv5")
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap5-igep0050.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-igep0050.dts b/arch/arm/boot/dts/omap5-igep0050.dts
--- a/arch/arm/boot/dts/omap5-igep0050.dts
+++ b/arch/arm/boot/dts/omap5-igep0050.dts
@@ -27,7 +27,7 @@
power-button {
label = "Power Button";
linux,code = <KEY_POWER>;
- gpios = <&gpio4 22 GPIO_ACTIVE_HIGH>;
+ gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
};
};
--
2.9.3
^ permalink raw reply
* [PATCH V5] perf tools: adding support for address filters
From: Masami Hiramatsu @ 2016-09-19 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <008718a0-13bf-8245-e2ee-562cffeba3c5@intel.com>
On Mon, 19 Sep 2016 09:15:40 +0300
Adrian Hunter <adrian.hunter@intel.com> wrote:
> On 17/09/16 16:33, Masami Hiramatsu wrote:
> > On Fri, 16 Sep 2016 09:32:43 -0600
> > Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >
> >> On 13 September 2016 at 17:25, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >>> On Tue, 13 Sep 2016 08:18:10 -0600
> >>> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >>>
> >>>> On 13 September 2016 at 04:01, Adrian Hunter <adrian.hunter@intel.com> wrote:
> >>>>> On 12/09/16 20:53, Mathieu Poirier wrote:
> >>>>>> This patch makes it possible to use the current filter
> >>>>>> framework with address filters. That way address filters for
> >>>>>> HW tracers such as CoreSight and IntelPT can be communicated
> >>>>>> to the kernel drivers.
> >>>>>>
> >>>>>> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> >>>>>>
> >>>>>> ---
> >>>>>> Changes for V5:
> >>>>>> - Modified perf_evsel__append_filter() to take a string format
> >>>>>> rather than an operation.
> >>>>>
> >>>>> Hope I'm not being a pain, but aren't there other places calling
> >>>>> perf_evsel__append_filter() that need to be changed. Might make
> >>>>> sense as a separate patch.
> >>>>
> >>>> No no, you're right - I completely overlooked that.
> >>>>
> >>>> But shouldn't it be in the same patch? That way a git bisect would
> >>>> stay consistent...
> >>>
> >>> You're right. Caller and callee should be changed in atomic.
> >>>
> >>> BTW, could you add document updates how the perf command line
> >>> will be changed, and also show the result in the patch description?
> >>
> >> This patch does not change anything on the perf command line. It
> >> simply allows current options to succeed (as they should) rather than
> >> fail.
> >
> > Yes, and it will make perf acceptable to pass --filter to CoreSight or
> > Intel PT events, or am I misunderstand?
> > If it is correct, could you give us an example how to pass it, since
> > tools/perf/Documentation/perf-record.txt says it is only for tracepoints?
>
> I am adding support for symbols in the address filter. I will send the
> patches soon, but the documentation will be:
>
> --filter=<filter>::
> Event filter. This option should follow a event selector (-e) which
> selects either tracepoint event(s) or a hardware trace PMU
> (e.g. Intel PT or CoreSight).
>
> - tracepoint filters
>
> In the case of tracepoints, multiple '--filter' options are combined
> using '&&'.
>
> - address filters
>
> A hardware trace PMU advertises its ability to accept a number of
> address filters by specifying a non-zero value in
> /sys/bus/event_source/devices/<pmu>/nr_addr_filters.
>
> Address filters have the format:
>
> filter|start|stop|tracestop <start> [/ <size>] [@<file name>]
>
> Where:
> - 'filter': defines a region that will be traced.
> - 'start': defines an address at which tracing will begin.
> - 'stop': defines an address at which tracing will stop.
> - 'tracestop': defines a region in which tracing will stop.
>
> <file name> is the name of the object file, <start> is the offset to the
> code to trace in that file, and <size> is the size of the region to
> trace. 'start' and 'stop' filters need not specify a <size>.
>
> If no object file is specified then the kernel is assumed, in which case
> the start address must be a current kernel memory address.
>
> <start> can also be specified by providing the name of a symbol. If the
> symbol name is not unique, it can be disambiguated by inserting #n where
> 'n' selects the n'th symbol in address order. Alternately #0, #g or #G
> select only a global symbol. <size> can also be specified by providing
> the name of a symbol, in which case the size is calculated to the end
> of that symbol. For 'filter' and 'tracestop' filters, if <size> is
> omitted and <start> is a symbol, then the size is calculated to the end
> of that symbol.
>
> If <size> is omitted and <start> is '*', then the start and size will
> be calculated from the first and last symbols, i.e. to trace the whole
> file.
>
> If symbol names (or "*") are provided, they must be surrounded by white
> space.
>
> The filter passed to the kernel is not necessarily the same as entered.
> To see the filter that is passed, use the -v option.
>
> The kernel may not be able to configure a trace region if it is not
> within a single mapping. MMAP events (or /proc/<pid>/maps) can be
> examined to determine if that is a possibility.
>
> Multiple filters can be separated with space or comma.
Perfect! :)
OK, I'll wait your patch.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH 3/4] watchdog: sa11x0/pxa: get rid of get_clock_tick_rate
From: Russell King - ARM Linux @ 2016-09-19 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160919200816.GC29242@roeck-us.net>
On Mon, Sep 19, 2016 at 01:08:16PM -0700, Guenter Roeck wrote:
> On Mon, Sep 19, 2016 at 09:12:14PM +0200, Robert Jarzmik wrote:
> > The OS timer rate used for the watchdog can now be fetched from the
> > standard clock API. This will remove the last user of
> > get_clock_tick_rate() in both pxa and sa11x0 architectures.
> >
> > Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>
> Did you test this ? Potential problem, if built into the kernel, could be that
> the clocks might not be ready by the time the driver is instantiated. Unless
> this is converted to a platform driver, it won't be able to handle a
> -EPROBE_DEFER from the clock subsystem.
Really not a problem at all. The OSTIMER0 is required for the system
tick, and if that's not present, the kernel will be without any kind
of time keeping, so a missing watchdog driver is the least of the
problems.
Therefore, both PXA and SA11x0 register their clocks really early to
ensure that OSTIMER0 is available by the time_init() stage, which is
way before driver probe time.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [GIT PULL] Qualcomm EBI2 bindings and bus driver
From: Andy Gross @ 2016-09-19 22:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4360974.U0qvolVKdi@wuerfel>
On Tue, Sep 20, 2016 at 12:12:33AM +0200, Arnd Bergmann wrote:
> On Thursday, September 8, 2016 3:34:42 PM CEST Linus Walleij wrote:
> > please pull this new EBI2 bus driver and its bindings into an
> > apropriate branch in the ARM SoC tree. The binding now has
> > Rob Herrings ACK and we have hopefully finally figured out how
> > this should be done.
> >
>
> I just noticed that you sent the pull request directly to arm at kernel.org
> rather than the Qualcomm maintainers (which are only on Cc).
>
> Usually, I'd expect to see this forwarded from Andy, is there a
> reason to do it differently here? If so, can I have an Ack
> from him?
When I looked at this last, I thought there were comments. Sorry I missed it.
If you want to pick it up Arnd, please do, otherwise I can send it along in the
next pull request.
Acked-by: Andy Gross <andy.gross@linaro.org>
^ permalink raw reply
* [GIT PULL 2/2] arm64: X-Gene platforms DTS changes queued for 4.9
From: Duc Dang @ 2016-09-19 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5369836.4ELrYOmq06@wuerfel>
On Mon, Sep 19, 2016 at 1:32 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Friday, September 16, 2016 12:01:28 AM CEST Duc Dang wrote:
> > This is the DTS changes for X-Gene platforms targeted for 4.9.
> >
> > The changes include:
> > + X-Gene Soc PMU DTS entry from X-Gene PMU patch set of Tai Nguyen [1]
> > + Follow up patch to enable DTS entry for SoC PMU on X-Gene v2
> > + Correct PCIe legacy interrupt mode to level-active high
> > + DTS entry for X-Gene hwmon (v4 acked by Guenter, DT binding document
> > and driver is in linux-next now [2])
> > + DTS entries for X-Gene v2 CPU clock from X-Gene PMD clock patch set
> > (v3 already accepted by Stephen into clk-next [3])
> >
> >
>
> Pulled into next/dt64, thanks!
Thanks, Arnd.
>
> Arnd
>
Regards,
Duc Dang.
^ permalink raw reply
* [RESEND PATCH] arm64: kgdb: fix single stepping
From: Jason Wessel @ 2016-09-19 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916043218.GA30248@linaro.org>
On 09/15/2016 11:32 PM, AKASHI Takahiro wrote:
> @@ -176,18 +183,14 @@ int kgdb_arch_handle_exception(int exception_vector, int signo,
>>> * over and over again.
>>> */
>>> kgdb_arch_update_addr(linux_regs, remcom_in_buffer);
>>> - atomic_set(&kgdb_cpu_doing_single_step, -1);
>>> - kgdb_single_step = 0;
>>
>> This is a subtle change, but I assume it is what you intended? All the CPUs will get released into the run state when exiting the kgdb exception handler.
> You are talking about "- kgdb_single_step = 0." Right?
Correct.
> Do you think that there is any (negative) side effect of this change?
Not at all. The kernel debugger always skids to a stop, and it is more reliable from a locking perspective if the other CPU threads are released while a single CPU is asked to single step until the next "skid" for all the other CPUs.
When you do not release the other CPUs you can end up single stepping a CPU which dead locks or never exits a lock elsewhere due to what ever it was blocking on never getting freed from another CPU.
Cheers,
Jason.
^ permalink raw reply
* [RESEND PATCH] arm64: kgdb: fix single stepping
From: Jason Wessel @ 2016-09-19 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916074513.GI3380@arm.com>
On 09/16/2016 02:45 AM, Will Deacon wrote:
> On Fri, Sep 16, 2016 at 01:32:19PM +0900, AKASHI Takahiro wrote:
>> On Thu, Sep 15, 2016 at 08:04:57AM -0500, Jason Wessel wrote:
>>> I added the patch to kgdb-next after fixing up the context since it no
>>> longer applied to the mainline (
>>> https://git.kernel.org/cgit/linux/kernel/git/jwessel/kgdb.git/log/?h=kgdb-next).
>>> If there is further discussion on the point above, another patch can be
>>> added, but it I am assuming this is the way you desire it to work as
>>> there are some other architectures that use the same behaviour. I do
>>> not presently have any ARM64 hardware to validate this particular
>>> change.
>>>
>>> I also added to the patch a "Cc: linux-stable <stable@vger.kernel.org>"
>>> so we can have this appear on some of the older kernels.
>> Since Will asked me to split this patch into a few, I need some reworks
>> to clarify which hunks in the patch are necessary for which version of kernel.
> Yes, splitting the patch would be much better for sorting out the stable
> backports too. Jason, please can you drop the patch for now? I don't mind
> whether the end result goes via arm64 or kgdb, but we should at least both
> agree on it first :)
Splitting it is a very wise idea so that we can have all the -stable kernels patched up with a working single step function.
The separated patches can easily be tagged with the CC line examples as shown below:
Cc: <stable@vger.kernel.org> # 3.15.x-
Cc: <stable@vger.kernel.org> # 4.4
Cc: <stable@vger.kernel.org> # 4.4-4.5
I had dropped the original patch.
Cheers,
Jason.
^ permalink raw reply
* [PATCH] MAINTAINERS: update list of Oxnas maintainers
From: Arnd Bergmann @ 2016-09-19 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916080917.19162-1-narmstrong@baylibre.com>
On Friday, September 16, 2016 10:09:17 AM CEST Neil Armstrong wrote:
> Add a new list address in the MAINTAINERS file for the Oxnas platform.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Applied to next/soc, thanks!
When you send a single patch to be applied, please try to be specific
about who you send it to, and put only the recipient (arm at kernel.org here)
on "To:", while the mailing lists and any other people should all be on
Cc.
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: drivers for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-19 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a8fabikx.fsf@free-electrons.com>
On Wednesday, September 14, 2016 5:35:10 PM CEST Gregory CLEMENT wrote:
> mvebu drivers for 4.9 (part 1)
>
> - Add pinctrl and clk support for the Orion5x SoC mv88f5181 variant
>
> ----------------------------------------------------------------
> Jamie Lentin (2):
> clk: mvebu: Add clk support for the orion5x SoC mv88f5181
> pinctrl: mvebu: orion5x: Generalise mv88f5181l support for 88f5181
>
> .../devicetree/bindings/clock/mvebu-core-clock.txt | 1 +
> .../bindings/pinctrl/marvell,orion-pinctrl.txt | 4 +-
> drivers/clk/mvebu/orion.c | 70 ++++++++++++++++++++++
> drivers/pinctrl/mvebu/pinctrl-orion.c | 23 +++----
> 4 files changed, 86 insertions(+), 12 deletions(-)
I see this touches pinctrl and clk drivers, but none of the maintainers are
on Cc for this pull request, nor have they provided an Ack for the patches
according to your git log.
Why did you not send the driver changes to them?
Not pulled for now, until this is resolved, sorry.
Arnd
^ permalink raw reply
* [GIT PULL] Qualcomm EBI2 bindings and bus driver
From: Arnd Bergmann @ 2016-09-19 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYvowN2htUuN46JNVdfaKNw3AEbBfzAeScHQcLU5o3ZUg@mail.gmail.com>
On Thursday, September 8, 2016 3:34:42 PM CEST Linus Walleij wrote:
> please pull this new EBI2 bus driver and its bindings into an
> apropriate branch in the ARM SoC tree. The binding now has
> Rob Herrings ACK and we have hopefully finally figured out how
> this should be done.
>
I just noticed that you sent the pull request directly to arm at kernel.org
rather than the Qualcomm maintainers (which are only on Cc).
Usually, I'd expect to see this forwarded from Andy, is there a
reason to do it differently here? If so, can I have an Ack
from him?
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: soc for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-19 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21718559.viYP8Vn8qc@wuerfel>
On Monday, September 19, 2016 11:46:22 PM CEST Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 5:34:37 PM CEST Gregory CLEMENT wrote:
> > mvebu soc for 4.9 (part 1)
> >
> > - irq cleanup for old mvebu SoC
> > - Convert orion5x based SoC Netgear WNR854T to devicetree
> >
>
> Pulled into next/soc, thanks!
Sorry, backed out again after seeing the PCI stuff on the WNR854T in
there. I thought the plan was to leave out PCI support from the DT
based machine file, and leave the old board in place, or am I
missing something?
Arnd
^ permalink raw reply
* [GIT PULL] ARM: mvebu: soc for v4.9 (#1)
From: Arnd Bergmann @ 2016-09-19 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bmzqbilu.fsf@free-electrons.com>
On Wednesday, September 14, 2016 5:34:37 PM CEST Gregory CLEMENT wrote:
> mvebu soc for 4.9 (part 1)
>
> - irq cleanup for old mvebu SoC
> - Convert orion5x based SoC Netgear WNR854T to devicetree
>
Pulled into next/soc, thanks!
Arnd
^ 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