* [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc
From: Michal Hocko @ 2016-10-26 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58101EB4.2080305@huawei.com>
On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote:
>
>
> On 2016/10/25 21:23, Michal Hocko wrote:
> > On Tue 25-10-16 10:59:17, Zhen Lei wrote:
> >> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
> >> actually exist. The percpu variable areas and numa control blocks of that
> >> memoryless numa nodes need to be allocated from the nearest available
> >> node to improve performance.
> >>
> >> Although memblock_alloc_try_nid and memblock_virt_alloc_try_nid try the
> >> specified nid at the first time, but if that allocation failed it will
> >> directly drop to use NUMA_NO_NODE. This mean any nodes maybe possible at
> >> the second time.
> >>
> >> To compatible the above old scene, I use a marco node_distance_ready to
> >> control it. By default, the marco node_distance_ready is not defined in
> >> any platforms, the above mentioned functions will work as normal as
> >> before. Otherwise, they will try the nearest node first.
> >
> > I am sorry but it is absolutely unclear to me _what_ is the motivation
> > of the patch. Is this a performance optimization, correctness issue or
> > something else? Could you please restate what is the problem, why do you
> > think it has to be fixed at memblock layer and describe what the actual
> > fix is please?
>
> This is a performance optimization.
Do you have any numbers to back the improvements?
> The problem is if some memoryless numa nodes are
> actually exist, for example: there are total 4 nodes, 0,1,2,3, node 1 has no memory,
> and the node distances is as below:
> ---------board-------
> | |
> | |
> socket0 socket1
> / \ / \
> / \ / \
> node0 node1 node2 node3
> distance[1][0] is nearer than distance[1][2] and distance[1][3]. CPUs on node1 access
> the memory of node0 is faster than node2 or node3.
>
> Linux defines a lot of percpu variables, each cpu has a copy of it and most of the time
> only to access their own percpu area. In this example, we hope the percpu area of CPUs
> on node1 allocated from node0. But without these patches, it's not sure that.
I am not familiar with the percpu allocator much so I might be
completely missig a point but why cannot this be solved in the percpu
allocator directly e.g. by using cpu_to_mem which should already be
memoryless aware.
Generating a new API while we have means to use an existing one sounds
just not right to me.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH 3/4] usb: musb: da8xx: Add DT support for the DA8xx driver
From: Alexandre Bailon @ 2016-10-26 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <82a39c63-8486-de00-3a0f-8d9d267b6404@cogentembedded.com>
On 10/25/2016 07:38 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 10/25/2016 05:39 PM, Alexandre Bailon wrote:
>
>> From: Petr Kulhavy <petr@barix.com>
>>
>> This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
>>
>> Signed-off-by: Petr Kulhavy <petr@barix.com>
>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>> ---
>> drivers/usb/musb/da8xx.c | 76
>> ++++++++++++++++++++++++++++++++++++++++++------
>> 1 file changed, 67 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
>> index 210b7e4..d465087 100644
>> --- a/drivers/usb/musb/da8xx.c
>> +++ b/drivers/usb/musb/da8xx.c
>> @@ -6,6 +6,9 @@
>> * Based on the DaVinci "glue layer" code.
>> * Copyright (C) 2005-2006 by Texas Instruments
>> *
>> + * DT support
>> + * Copyright (c) 2016 Petr Kulhavy <petr@barix.com>
>> + *
>> * This file is part of the Inventra Controller Driver for Linux.
>> *
>> * The Inventra Controller Driver for Linux is free software; you
> [...]
>> @@ -499,15 +537,21 @@ static int da8xx_probe(struct platform_device
>> *pdev)
>> memset(musb_resources, 0x00, sizeof(*musb_resources) *
>> ARRAY_SIZE(musb_resources));
>>
>> - musb_resources[0].name = pdev->resource[0].name;
>> - musb_resources[0].start = pdev->resource[0].start;
>> - musb_resources[0].end = pdev->resource[0].end;
>> - musb_resources[0].flags = pdev->resource[0].flags;
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res) {
>> + dev_err(&pdev->dev, "failed to get memory.\n");
>> + ret = -EINVAL;
>> + goto err_unregister_usb_phy;
>> + }
>> + musb_resources[0] = *res;
>
> What does this change have to do with the DT conversion?
Nothing. I will remove it.
>
>>
>> - musb_resources[1].name = pdev->resource[1].name;
>> - musb_resources[1].start = pdev->resource[1].start;
>> - musb_resources[1].end = pdev->resource[1].end;
>> - musb_resources[1].flags = pdev->resource[1].flags;
>> + res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
>> + if (!res) {
>> + dev_err(&pdev->dev, "failed to get irq.\n");
>> + ret = -EINVAL;
>> + goto err_unregister_usb_phy;
>> + }
>> + musb_resources[1] = *res;
>
> And this?
> I'm also concerned that you'd copy the resource linkage fields which
> the existing code avoids...
>
> [...]
>
> MBR, Sergei
>
^ permalink raw reply
* [PATCH/RFT v2 07/17] ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable
From: Sekhar Nori @ 2016-10-26 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5abddbfe-0338-6406-9299-1d2d3fb957a3@lechnology.com>
On Tuesday 25 October 2016 09:35 PM, David Lechner wrote:
> On 10/25/2016 05:12 AM, Sekhar Nori wrote:
>> On Monday 24 October 2016 10:16 PM, ahaslam at baylibre.com wrote:
>>> diff --git a/arch/arm/mach-davinci/usb-da8xx.c
>>> b/arch/arm/mach-davinci/usb-da8xx.c
>>> index 9e41a7f..982e105 100644
>>> --- a/arch/arm/mach-davinci/usb-da8xx.c
>>> +++ b/arch/arm/mach-davinci/usb-da8xx.c
>>> @@ -53,11 +53,19 @@ int __init da8xx_register_usb_refclkin(int rate)
>>>
>>> static void usb20_phy_clk_enable(struct clk *clk)
>>> {
>>> + struct clk *usb20_clk;
>>> u32 val;
>>> u32 timeout = 500000; /* 500 msec */
>>>
>>> val = readl(DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG));
>>>
>>> + usb20_clk = clk_get(NULL, "usb20");
>>
>> We should not be using a NULL device pointer here. Can you pass the musb
>> device pointer available in the same file? Also, da850_clks[] in da850.c
>> needs to be fixed to add the matching device name.
>
> This clock can be used for usb 1.1 PHY even when musb is not being used,
> so I don't think we can depend on having a musb device here.
Replied to this against the same question in v6 patch series you posted.
> Also, in a previous review, it was decided that the usb clocks should
> *not* be added to da850_clks[] [1]. Instead, they are dynamically
> registered elsewhere.
Thats only the USB phy clocks since there is associated
enable()/disable()/set_parent() code which is better kept outside of
da850.c for readability. No other reason. Lookup for the USB 2.0 module
clock is already present in da850.c
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Will Deacon @ 2016-10-26 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7aff47c3-c794-5291-4b2a-44493f398828@arm.com>
On Fri, Oct 21, 2016 at 05:20:43PM +0100, Robin Murphy wrote:
> On 19/10/16 13:49, Will Deacon wrote:
> > On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote:
> >> We now delay installing our per-bus iommu_ops until we know an SMMU has
> >> successfully probed, as they don't serve much purpose beforehand, and
> >> doing so also avoids fights between multiple IOMMU drivers in a single
> >> kernel. However, the upshot of passing the return value of bus_set_iommu()
> >> back from our probe function is that if there happens to be more than
> >> one SMMUv3 device in a system, the second and subsequent probes will
> >> wind up returning -EBUSY to the driver core and getting torn down again.
> >>
> >> There are essentially 3 cases in which bus_set_iommu() returns nonzero:
> >> 1. The bus already has iommu_ops installed
> >> 2. One of the add_device callbacks from the initial notifier failed
> >> 3. Allocating or installing the notifier itself failed
> >>
> >> The first two are down to devices other than the SMMU in question, so
> >> shouldn't abort an otherwise-successful SMMU probe, whilst the third is
> >> indicative of the kind of catastrophic system failure which isn't going
> >> to get much further anyway. Consequently, there is little harm in
> >> ignoring the return value either way.
> >>
> >> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >> ---
> >> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
> >> 1 file changed, 4 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> >> index 15c01c3cd540..74fbef384deb 100644
> >> --- a/drivers/iommu/arm-smmu-v3.c
> >> +++ b/drivers/iommu/arm-smmu-v3.c
> >> @@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> >> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> >> #ifdef CONFIG_PCI
> >> pci_request_acs();
> >> - ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> >> - if (ret)
> >> - return ret;
> >> + bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> >> #endif
> >> #ifdef CONFIG_ARM_AMBA
> >> - ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> >> - if (ret)
> >> - return ret;
> >> + bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> >> #endif
> >> - return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> >> + bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> >> + return 0;
> >
> > In which case, we should probably add an iommu_present check, like we
> > have for the v2 driver.
>
> As touched upon in the commit message, the first thing bus_set_iommu()
> does is perform that same check and return immediately if any ops are
> already set. Do you really want redundant checks added, or shall I spin
> that cleanup patch removing them from v2 that I proposed to Lorenzo?
A cleanup patch sounds good, to keep the two drivers consistent.
Will
^ permalink raw reply
* [PATCH 1/1] power: axp20x_ac: Add support for ac power-supply on axp20x and axp22x pmics
From: Lee Jones @ 2016-10-26 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474129243-10873-1-git-send-email-lyu@micile.com>
On Sat, 17 Sep 2016, Lawrence Yu wrote:
> Add support for monitoring of ac power supply input. axp22x is the same
> as axp20x except it can not monitor voltage or current, only presence of
> power.
>
> This is mainly a copy of the existing axp20x_usb_power driver modified to
> use the ac power supply registers instead of the usb registers.
>
> axp20x tested on a generic A20 tablet.
> axp22x tested on an a33 ga10h-v1.1 tablet.
>
> Signed-off-by: Lawrence Yu <lyu@micile.com>
> ---
> .../bindings/power_supply/axp20x_ac_power.txt | 35 ++++
> arch/arm/boot/dts/axp209.dtsi | 5 +
> arch/arm/boot/dts/axp22x.dtsi | 5 +
> drivers/mfd/axp20x.c | 11 ++
> drivers/power/Makefile | 1 +
> drivers/power/axp20x_ac_power.c | 219 +++++++++++++++++++++
Please split this patch up per-subsystem.
> 6 files changed, 276 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
> create mode 100644 drivers/power/axp20x_ac_power.c
>
> diff --git a/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
> new file mode 100644
> index 0000000..d751cdc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power_supply/axp20x_ac_power.txt
> @@ -0,0 +1,35 @@
> +AXP20x AC power supply
> +
> +Required Properties:
> +-compatible: One of: "x-powers,axp202-ac-power-supply"
> + "x-powers,axp221-ac-power-supply"
> +
> +This node is a subnode of the axp20x PMIC.
> +
> +Example:
> +
> +axp209: pmic at 34 {
> + compatible = "x-powers,axp209";
> + reg = <0x34>;
> + interrupt-parent = <&nmi_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + regulators {
> + x-powers,dcdc-freq = <1500>;
> +
> + vdd_cpu: dcdc2 {
> + regulator-always-on;
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1450000>;
> + regulator-name = "vdd-cpu";
> + };
> +
> + ...
> + };
> +
> + ac-power-supply: ac-power-supply {
> + compatible = "x-powers,axp202-ac-power-supply";
> + };
> +};
> diff --git a/arch/arm/boot/dts/axp209.dtsi b/arch/arm/boot/dts/axp209.dtsi
> index 675bb0f..54e23c6 100644
> --- a/arch/arm/boot/dts/axp209.dtsi
> +++ b/arch/arm/boot/dts/axp209.dtsi
> @@ -97,6 +97,11 @@
> };
> };
>
> + ac_power_supply: ac_power_supply {
> + compatible = "x-powers,axp202-ac-power-supply";
> + status = "disabled";
> + };
> +
> usb_power_supply: usb_power_supply {
> compatible = "x-powers,axp202-usb-power-supply";
> status = "disabled";
> diff --git a/arch/arm/boot/dts/axp22x.dtsi b/arch/arm/boot/dts/axp22x.dtsi
> index 458b668..cdd5d4f 100644
> --- a/arch/arm/boot/dts/axp22x.dtsi
> +++ b/arch/arm/boot/dts/axp22x.dtsi
> @@ -148,6 +148,11 @@
> };
> };
>
> + ac_power_supply: ac_power_supply {
> + compatible = "x-powers,axp221-ac-power-supply";
> + status = "disabled";
> + };
> +
> usb_power_supply: usb_power_supply {
> compatible = "x-powers,axp221-usb-power-supply";
> status = "disabled";
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index ba130be..450d1a0 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -162,6 +162,12 @@ static struct resource axp20x_ac_power_supply_resources[] = {
> DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
> };
>
> +static struct resource axp22x_ac_power_supply_resources[] = {
> + DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_PLUGIN, "ACIN_PLUGIN"),
> + DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_REMOVAL, "ACIN_REMOVAL"),
> + DEFINE_RES_IRQ_NAMED(AXP20X_IRQ_ACIN_OVER_V, "ACIN_OVER_V"),
> +};
> +
> static struct resource axp20x_pek_resources[] = {
> {
> .name = "PEK_DBR",
> @@ -595,6 +601,11 @@ static struct mfd_cell axp22x_cells[] = {
> }, {
> .name = "axp20x-regulator",
> }, {
> + .name = "axp20x-ac-power-supply",
> + .of_compatible = "x-powers,axp221-ac-power-supply",
> + .num_resources = ARRAY_SIZE(axp22x_ac_power_supply_resources),
> + .resources = axp22x_ac_power_supply_resources,
> + }, {
> .name = "axp20x-usb-power-supply",
> .of_compatible = "x-powers,axp221-usb-power-supply",
> .num_resources = ARRAY_SIZE(axp22x_usb_power_supply_resources),
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index e46b75d..295ec0f 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
>
> obj-$(CONFIG_PDA_POWER) += pda_power.o
> obj-$(CONFIG_APM_POWER) += apm_power.o
> +obj-$(CONFIG_AXP20X_POWER) += axp20x_ac_power.o
> obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o
> obj-$(CONFIG_MAX8925_POWER) += max8925_power.o
> obj-$(CONFIG_WM831X_BACKUP) += wm831x_backup.o
> diff --git a/drivers/power/axp20x_ac_power.c b/drivers/power/axp20x_ac_power.c
> new file mode 100644
> index 0000000..13bb093
> --- /dev/null
> +++ b/drivers/power/axp20x_ac_power.c
> @@ -0,0 +1,219 @@
> +/*
> + * AXP20x PMIC AC power supply status driver
> + *
> + * Copyright (C) 2015 Hans de Goede <hdegoede@redhat.com>
> + * Copyright (C) 2014 Bruno Pr?mont <bonbons@linux-vserver.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/axp20x.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/power_supply.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +#define DRVNAME "axp20x-ac-power-supply"
> +
> +#define AXP20X_PWR_STATUS_ACIN_PRESENT BIT(7)
> +#define AXP20X_PWR_STATUS_ACIN_USED BIT(6)
> +#define AXP20X_ADC_EN1_ACIN_CURR BIT(4)
> +#define AXP20X_ADC_EN1_ACIN_VOLT BIT(5)
> +
> +struct axp20x_ac_power {
> + struct device_node *np;
> + struct regmap *regmap;
> + struct power_supply *supply;
> +};
> +
> +static irqreturn_t axp20x_ac_power_irq(int irq, void *devid)
> +{
> + struct axp20x_ac_power *power = devid;
> +
> + power_supply_changed(power->supply);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int axp20x_ac_power_get_property(struct power_supply *psy,
> + enum power_supply_property psp, union power_supply_propval *val)
> +{
> + struct axp20x_ac_power *power = power_supply_get_drvdata(psy);
> + unsigned int input;
> + int ret;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_VOLTAGE_NOW:
> + ret = axp20x_read_variable_width(power->regmap,
> + AXP20X_ACIN_V_ADC_H, 12);
> + if (ret < 0)
> + return ret;
> +
> + val->intval = ret * 1700; /* 1 step = 1.7 mV */
> + return 0;
> + case POWER_SUPPLY_PROP_CURRENT_NOW:
> + ret = axp20x_read_variable_width(power->regmap,
> + AXP20X_ACIN_I_ADC_H, 12);
> + if (ret < 0)
> + return ret;
> +
> + val->intval = ret * 625; /* 1 step = 0.375 mA */
> + return 0;
> + default:
> + break;
> + }
> +
> + /* All the properties below need the input-status reg value */
> + ret = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, &input);
> + if (ret)
> + return ret;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_PRESENT:
> + val->intval = !!(input & AXP20X_PWR_STATUS_ACIN_PRESENT);
> + break;
> + case POWER_SUPPLY_PROP_ONLINE:
> + val->intval = !!(input & AXP20X_PWR_STATUS_ACIN_USED);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static enum power_supply_property axp20x_ac_power_properties[] = {
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_ONLINE,
> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
> + POWER_SUPPLY_PROP_CURRENT_NOW,
> +};
> +
> +static enum power_supply_property axp22x_ac_power_properties[] = {
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_ONLINE,
> +};
> +
> +static const struct power_supply_desc axp20x_ac_power_desc = {
> + .name = "axp20x-ac",
> + .type = POWER_SUPPLY_TYPE_MAINS,
> + .properties = axp20x_ac_power_properties,
> + .num_properties = ARRAY_SIZE(axp20x_ac_power_properties),
> + .get_property = axp20x_ac_power_get_property,
> +};
> +
> +static const struct power_supply_desc axp22x_ac_power_desc = {
> + .name = "axp20x-ac",
> + .type = POWER_SUPPLY_TYPE_MAINS,
> + .properties = axp22x_ac_power_properties,
> + .num_properties = ARRAY_SIZE(axp22x_ac_power_properties),
> + .get_property = axp20x_ac_power_get_property,
> +};
> +
> +static int axp20x_ac_power_probe(struct platform_device *pdev)
> +{
> + struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> + struct power_supply_config psy_cfg = {};
> + struct axp20x_ac_power *power;
> + static const char * const axp20x_irq_names[] = {
> + "ACIN_PLUGIN", "ACIN_REMOVAL", NULL };
> + static const char * const axp22x_irq_names[] = {
> + "ACIN_PLUGIN", "ACIN_REMOVAL", NULL };
> + static const char * const *irq_names;
> + const struct power_supply_desc *ac_power_desc;
> + int i, irq, ret;
> +
> + if (!of_device_is_available(pdev->dev.of_node))
> + return -ENODEV;
> +
> + if (!axp20x) {
> + dev_err(&pdev->dev, "Parent drvdata not set\n");
> + return -EINVAL;
> + }
> +
> + power = devm_kzalloc(&pdev->dev, sizeof(*power), GFP_KERNEL);
> + if (!power)
> + return -ENOMEM;
> +
> + power->np = pdev->dev.of_node;
> + power->regmap = axp20x->regmap;
> +
> + if (of_device_is_compatible(power->np,
> + "x-powers,axp202-ac-power-supply")) {
> +
> + /* Enable acin voltage and current measurement */
> + ret = regmap_update_bits(power->regmap, AXP20X_ADC_EN1,
> + AXP20X_ADC_EN1_ACIN_CURR | AXP20X_ADC_EN1_ACIN_VOLT,
> + AXP20X_ADC_EN1_ACIN_CURR | AXP20X_ADC_EN1_ACIN_VOLT);
> + if (ret)
> + return ret;
> +
> + ac_power_desc = &axp20x_ac_power_desc;
> + irq_names = axp20x_irq_names;
> + } else if (of_device_is_compatible(power->np,
> + "x-powers,axp221-ac-power-supply")) {
> + ac_power_desc = &axp22x_ac_power_desc;
> + irq_names = axp22x_irq_names;
> + } else {
> + dev_err(&pdev->dev, "Unsupported AXP variant: %ld\n",
> + axp20x->variant);
> + return -EINVAL;
> + }
> +
> + psy_cfg.of_node = pdev->dev.of_node;
> + psy_cfg.drv_data = power;
> +
> + power->supply = devm_power_supply_register(&pdev->dev, ac_power_desc,
> + &psy_cfg);
> + if (IS_ERR(power->supply))
> + return PTR_ERR(power->supply);
> +
> + /* Request irqs after registering, as irqs may trigger immediately */
> + for (i = 0; irq_names[i]; i++) {
> + irq = platform_get_irq_byname(pdev, irq_names[i]);
> + if (irq < 0) {
> + dev_warn(&pdev->dev, "No IRQ for %s: %d\n",
> + irq_names[i], irq);
> + continue;
> + }
> + irq = regmap_irq_get_virq(axp20x->regmap_irqc, irq);
> + ret = devm_request_any_context_irq(&pdev->dev, irq,
> + axp20x_ac_power_irq, 0, DRVNAME, power);
> + if (ret < 0)
> + dev_warn(&pdev->dev, "Error requesting %s IRQ: %d\n",
> + irq_names[i], ret);
> + }
> +
> + return 0;
> +}
> +
> +static const struct of_device_id axp20x_ac_power_match[] = {
> + { .compatible = "x-powers,axp202-ac-power-supply" },
> + { .compatible = "x-powers,axp221-ac-power-supply" },
> + { }
> +};
> +
> +MODULE_DEVICE_TABLE(of, axp20x_ac_power_match);
> +
> +static struct platform_driver axp20x_ac_power_driver = {
> + .probe = axp20x_ac_power_probe,
> + .driver = {
> + .name = DRVNAME,
> + .of_match_table = axp20x_ac_power_match,
> + },
> +};
> +
> +module_platform_driver(axp20x_ac_power_driver);
> +
> +MODULE_AUTHOR("Hans de Goede <hdegoede@redhat.com>");
> +MODULE_DESCRIPTION("AXP20x PMIC AC power supply status driver");
> +MODULE_LICENSE("GPL");
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v6 1/5] ARM: davinci: da8xx: add usb phy clocks
From: Sekhar Nori @ 2016-10-26 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477451211-31979-2-git-send-email-david@lechnology.com>
On Wednesday 26 October 2016 08:36 AM, David Lechner wrote:
> diff --git a/arch/arm/mach-davinci/usb-da8xx.c b/arch/arm/mach-davinci/usb-da8xx.c
> index f141f51..71a6d85 100644
> --- a/arch/arm/mach-davinci/usb-da8xx.c
> +++ b/arch/arm/mach-davinci/usb-da8xx.c
> @@ -1,20 +1,248 @@
> /*
> * DA8xx USB
> */
> -#include <linux/dma-mapping.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> #include <linux/init.h>
> #include <linux/platform_data/usb-davinci.h>
> #include <linux/platform_device.h>
> +#include <linux/mfd/da8xx-cfgchip.h>
> #include <linux/usb/musb.h>
>
> +#include <mach/clock.h>
> #include <mach/common.h>
> #include <mach/cputype.h>
> #include <mach/da8xx.h>
> -#include <mach/irqs.h>
Looks like you have cleaned up some unneeded includes. Thats fine, just
mention it in the commit description too, so its clear that it is intended.
Also, when adding new include files, please do it in alphabetical order.
> +static struct clk usb_refclkin = {
> + .name = "usb_refclkin",
> + .set_rate = davinci_simple_set_rate,
> +};
> +
> +static struct clk_lookup usb_refclkin_lookup =
> + CLK(NULL, "usb_refclkin", &usb_refclkin);
> +
> +static struct clk usb20_phy_clk = {
> + .name = "usb20_phy",
> + .clk_enable = usb20_phy_clk_enable,
> + .clk_disable = usb20_phy_clk_disable,
> + .set_parent = usb20_phy_clk_set_parent,
> +};
> +
> +static struct clk_lookup usb20_phy_clk_lookup =
> + CLK(NULL, "usb20_phy", &usb20_phy_clk);
NULL device name here is wrong. There is a PHY device that gets added
3/5. The name of that device should appear here. Since that phy device
is the consumer of this clock. You can change the order of patches so
the device appears before the associated clocks.
> +static struct clk usb11_phy_clk = {
> + .name = "usb11_phy",
> + .set_parent = usb11_phy_clk_set_parent,
> +};
> +
> +static struct clk_lookup usb11_phy_clk_lookup =
> + CLK(NULL, "usb11_phy", &usb11_phy_clk);
here too, please have the phy device name as the consumer of this clock.
It is okay to have NULL device name for the usb_refclkin since that is a
root clock not associated with any device.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v3] ARM: dts: Add gyro and accel to APQ8060 Dragonboard
From: Linus Walleij @ 2016-10-26 9:23 UTC (permalink / raw)
To: linux-arm-kernel
This adds the MPU-3050 gyroscope and the KXSD9 accelerometer to
the Qualcomm APQ8060 Dragonboard. The KXSD9 is mounted beyond the
MPU-3050 and appear as a subdevice beyond it. We set up the
required GPIO and interrupt lines to make the devices work.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Should be fine to apply now: all bindings and requirements are
merged.
ChangeLog v1->v2:
- Use the new I2C mux gate bindings from Peter Rosin (merged to
the I2C subsystem)
---
arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 53 ++++++++++++++++++++++++++
1 file changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
index 6c0038398ef2..1d76b7415f08 100644
--- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
@@ -167,6 +167,14 @@
bias-pull-up;
};
};
+
+ /* Interrupt line for the KXSD9 accelerometer */
+ dragon_kxsd9_gpios: kxsd9 {
+ irq {
+ pins = "gpio57"; /* IRQ line */
+ bias-pull-up;
+ };
+ };
};
qcom,ssbi at 500000 {
@@ -210,6 +218,15 @@
power-source = <PM8058_GPIO_S3>;
};
};
+ dragon_mpu3050_gpios: mpu3050-gpios {
+ pinconf {
+ pins = "gpio17";
+ function = "normal";
+ input-enable;
+ bias-disable;
+ power-source = <PM8058_GPIO_S3>;
+ };
+ };
dragon_sdcc3_gpios: sdcc3-gpios {
pinconf {
pins = "gpio22";
@@ -319,6 +336,42 @@
vddd-supply = <&pm8058_lvs0>; // 1.8V
vdda-supply = <&pm8058_l14>; // 2.85V
};
+ mpu3050 at 68 {
+ compatible = "invensense,mpu3050";
+ reg = <0x68>;
+ /*
+ * GPIO17 has interrupt 208 on the
+ * PM8058, it is pulled high by a 10k
+ * resistor to VLOGIC so needs to be
+ * active low/falling edge.
+ */
+ interrupt-parent = <&pm8058_gpio>;
+ interrupts = <208 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dragon_mpu3050_gpios>;
+ vlogic-supply = <&pm8058_lvs0>; // 1.8V
+ vdd-supply = <&pm8058_l14>; // 2.85V
+
+ /*
+ * The MPU-3050 acts as a hub for the
+ * accelerometer.
+ */
+ i2c-gate {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ kxsd9 at 18 {
+ compatible = "kionix,kxsd9";
+ reg = <0x18>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <57 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dragon_kxsd9_gpios>;
+ iovdd-supply = <&pm8058_lvs0>; // 1.8V
+ vdd-supply = <&pm8058_l14>; // 2.85V
+ };
+ };
+ };
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/9] drm/hisilicon/hibmc: Add support for frame buffer
From: Rongrong Zou @ 2016-10-26 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026055648.bipks7wthiu4gmlf@phenom.ffwll.local>
Hi Daniel,
Thansk for reviewing!
? 2016/10/26 13:56, Daniel Vetter ??:
> On Wed, Oct 26, 2016 at 10:37:00AM +0800, Rongrong Zou wrote:
>> Add support for fbdev and kms fb management.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>
> Small drive-by comment below.
>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index db8d80e..d41138a 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -20,9 +20,23 @@
>> #define HIBMC_DRM_DRV_H
>>
>> #include <drm/drmP.h>
>> +#include <drm/drm_fb_helper.h>
>> #include <drm/ttm/ttm_bo_driver.h>
>> #include <drm/drm_gem.h>
>>
>> +struct hibmc_framebuffer {
>> + struct drm_framebuffer fb;
>> + struct drm_gem_object *obj;
>> + bool is_fbdev_fb;
>> +};
>> +
>> +struct hibmc_fbdev {
>> + struct drm_fb_helper helper;
>> + struct hibmc_framebuffer fb;
>
> I wouldn't embed the single framebuffer here, but instead have a pointer
> and just refcount it. This here is a pattern that predates framebuffer
> refcounting, and it leads to plenty of surprises.
will allocate fbdev in next patch version, thanks.
>
> Maybe we should update the documentation of
> drm_framebuffer_unregister_private() to mention that it is deprecated? The
> overview doc in drm_framebuffer.c already explains that, but I guess
> that's not obvious enough.
Just replace drm_framebuffer_unregister_private() with
drm_framebuffer_remove()?
I found many other drivers use the following two functions in their
own xxx_fbdev_destroy():
drm_framebuffer_unregister_private(fbdev->fb);
drm_framebuffer_remove(fbdev->fb);
so the former is redundant and can be removed directly?
>
> Can you pls do that patch? And pls make sure it all looks pretty when
> building the docs with
No problem, i'll send another patch later.
Regards,
Rongrong
>
> $ make htmldocs
>
> Thanks, Daniel
>
^ permalink raw reply
* [PATCH v6 1/2] mfd: add support for Allwinner SoCs ADC
From: Lee Jones @ 2016-10-26 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473943444-23979-2-git-send-email-quentin.schulz@free-electrons.com>
On Thu, 15 Sep 2016, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a touchscreen
> controller and a thermal sensor. For now, only the ADC and the thermal
> sensor drivers are probed by the MFD, the touchscreen controller support
> will be added later.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Jonathan Cameron <jic23@kernel.org>
> ---
>
> v6:
> - remove "-mfd" from filenames and variables inside MFD driver,
> - use DEFINE_RES_IRQ_NAMED instead of setting resources manually,
> - cosmetic changes,
> - use IDs and switch over ID to get cells specific to an architecture, instead
> of using cells direclty, in of_device_id.data,
> - compute size of mfd_cells array instead of hardcoded one,
>
> v5:
> - correct mail address,
>
> v4:
> - rename files and variables from sunxi* to sun4i*,
> - rename defines from SUNXI_* to SUN4I_* or SUN6I_*,
> - remove TP in defines name,
> - rename SUNXI_IRQ_* to SUN4I_GPADC_IRQ_* for consistency,
> - use devm functions for regmap_add_irq_chip and mfd_add_devices,
> - remove remove functions (now empty thanks to devm functions),
>
> v3:
> - use defines in regmap_irq instead of hard coded BITs,
> - use of_device_id data field to chose which MFD cells to add considering
> the compatible responsible of the MFD probe,
> - remove useless initializations,
> - disable all interrupts before adding them to regmap_irqchip,
> - add goto error label in probe,
> - correct wrapping in header license,
> - move defines from IIO driver to header,
> - use GENMASK to limit the size of the variable passed to a macro,
> - prefix register BIT defines with the name of the register,
> - reorder defines,
>
> v2:
> - add license headers,
> - reorder alphabetically includes,
> - add SUNXI_GPADC_ prefixes for defines,
>
> drivers/mfd/Kconfig | 15 ++++
> drivers/mfd/Makefile | 2 +
> drivers/mfd/sun4i-gpadc.c | 181 ++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/sun4i-gpadc.h | 94 +++++++++++++++++++++
> 4 files changed, 292 insertions(+)
> create mode 100644 drivers/mfd/sun4i-gpadc.c
> create mode 100644 include/linux/mfd/sun4i-gpadc.h
Applied, thanks.
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 1bcf601..45db3f4 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -29,6 +29,21 @@ config MFD_ACT8945A
> linear regulators, along with a complete ActivePath battery
> charger.
>
> +config MFD_SUN4I_GPADC
> + tristate "Allwinner sunxi platforms' GPADC MFD driver"
> + select MFD_CORE
> + select REGMAP_MMIO
> + depends on ARCH_SUNXI || COMPILE_TEST
> + help
> + Select this to get support for Allwinner SoCs (A10, A13 and A31) ADC.
> + This driver will only map the hardware interrupt and registers, you
> + have to select individual drivers based on this MFD to be able to use
> + the ADC or the thermal sensor. This will try to probe the ADC driver
> + sun4i-gpadc-iio and the hwmon driver iio_hwmon.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called sun4i-gpadc.
> +
> config MFD_AS3711
> bool "AMS AS3711"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 42a66e1..12c49af 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -205,3 +205,5 @@ intel-soc-pmic-objs := intel_soc_pmic_core.o intel_soc_pmic_crc.o
> intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +
> +obj-$(CONFIG_MFD_SUN4I_GPADC) += sun4i-gpadc.o
> diff --git a/drivers/mfd/sun4i-gpadc.c b/drivers/mfd/sun4i-gpadc.c
> new file mode 100644
> index 0000000..276a1f4
> --- /dev/null
> +++ b/drivers/mfd/sun4i-gpadc.c
> @@ -0,0 +1,181 @@
> +/* ADC MFD core driver for sunxi platforms
> + *
> + * Copyright (c) 2016 Quentin Schulz <quentin.schulz@free-electrons.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.
> + */
> +
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> +#include <linux/regmap.h>
> +
> +#include <linux/mfd/sun4i-gpadc.h>
> +
> +#define ARCH_SUN4I_A10 0
> +#define ARCH_SUN5I_A13 1
> +#define ARCH_SUN6I_A31 2
> +
> +static struct resource adc_resources[] = {
> + DEFINE_RES_IRQ_NAMED(SUN4I_GPADC_IRQ_FIFO_DATA, "FIFO_DATA_PENDING"),
> + DEFINE_RES_IRQ_NAMED(SUN4I_GPADC_IRQ_TEMP_DATA, "TEMP_DATA_PENDING"),
> +};
> +
> +static const struct regmap_irq sun4i_gpadc_regmap_irq[] = {
> + REGMAP_IRQ_REG(SUN4I_GPADC_IRQ_FIFO_DATA, 0,
> + SUN4I_GPADC_INT_FIFOC_TP_DATA_IRQ_EN),
> + REGMAP_IRQ_REG(SUN4I_GPADC_IRQ_TEMP_DATA, 0,
> + SUN4I_GPADC_INT_FIFOC_TEMP_IRQ_EN),
> +};
> +
> +static const struct regmap_irq_chip sun4i_gpadc_regmap_irq_chip = {
> + .name = "sun4i_gpadc_irq_chip",
> + .status_base = SUN4I_GPADC_INT_FIFOS,
> + .ack_base = SUN4I_GPADC_INT_FIFOS,
> + .mask_base = SUN4I_GPADC_INT_FIFOC,
> + .init_ack_masked = true,
> + .mask_invert = true,
> + .irqs = sun4i_gpadc_regmap_irq,
> + .num_irqs = ARRAY_SIZE(sun4i_gpadc_regmap_irq),
> + .num_regs = 1,
> +};
> +
> +static struct mfd_cell sun4i_gpadc_cells[] = {
> + {
> + .name = "sun4i-a10-gpadc-iio",
> + .resources = adc_resources,
> + .num_resources = ARRAY_SIZE(adc_resources),
> + },
> + { .name = "iio_hwmon" }
> +};
> +
> +static struct mfd_cell sun5i_gpadc_cells[] = {
> + {
> + .name = "sun5i-a13-gpadc-iio",
> + .resources = adc_resources,
> + .num_resources = ARRAY_SIZE(adc_resources),
> + },
> + { .name = "iio_hwmon" },
> +};
> +
> +static struct mfd_cell sun6i_gpadc_cells[] = {
> + {
> + .name = "sun6i-a31-gpadc-iio",
> + .resources = adc_resources,
> + .num_resources = ARRAY_SIZE(adc_resources),
> + },
> + { .name = "iio_hwmon" },
> +};
> +
> +static const struct regmap_config sun4i_gpadc_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .fast_io = true,
> +};
> +
> +static const struct of_device_id sun4i_gpadc_of_match[] = {
> + {
> + .compatible = "allwinner,sun4i-a10-ts",
> + .data = (void *)ARCH_SUN4I_A10,
> + }, {
> + .compatible = "allwinner,sun5i-a13-ts",
> + .data = (void *)ARCH_SUN5I_A13,
> + }, {
> + .compatible = "allwinner,sun6i-a31-ts",
> + .data = (void *)ARCH_SUN6I_A31,
> + }, { /* sentinel */ }
> +};
> +
> +MODULE_DEVICE_TABLE(of, sun4i_gpadc_of_match);
> +
> +static int sun4i_gpadc_probe(struct platform_device *pdev)
> +{
> + struct sun4i_gpadc_dev *dev;
> + struct resource *mem;
> + const struct of_device_id *of_id;
> + const struct mfd_cell *cells;
> + unsigned int irq, size;
> + int ret;
> +
> + of_id = of_match_node(sun4i_gpadc_of_match, pdev->dev.of_node);
> + if (!of_id)
> + return -EINVAL;
> +
> + switch ((int)of_id->data) {
> + case ARCH_SUN4I_A10:
> + cells = sun4i_gpadc_cells;
> + size = ARRAY_SIZE(sun4i_gpadc_cells);
> + break;
> + case ARCH_SUN5I_A13:
> + cells = sun5i_gpadc_cells;
> + size = ARRAY_SIZE(sun5i_gpadc_cells);
> + break;
> + case ARCH_SUN6I_A31:
> + cells = sun6i_gpadc_cells;
> + size = ARRAY_SIZE(sun6i_gpadc_cells);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
> + if (!dev)
> + return -ENOMEM;
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + dev->base = devm_ioremap_resource(&pdev->dev, mem);
> + if (IS_ERR(dev->base))
> + return PTR_ERR(dev->base);
> +
> + dev->dev = &pdev->dev;
> + dev_set_drvdata(dev->dev, dev);
> +
> + dev->regmap = devm_regmap_init_mmio(dev->dev, dev->base,
> + &sun4i_gpadc_regmap_config);
> + if (IS_ERR(dev->regmap)) {
> + ret = PTR_ERR(dev->regmap);
> + dev_err(&pdev->dev, "failed to init regmap: %d\n", ret);
> + return ret;
> + }
> +
> + /* Disable all interrupts */
> + regmap_write(dev->regmap, SUN4I_GPADC_INT_FIFOC, 0);
> +
> + irq = platform_get_irq(pdev, 0);
> + ret = devm_regmap_add_irq_chip(&pdev->dev, dev->regmap, irq,
> + IRQF_ONESHOT, 0,
> + &sun4i_gpadc_regmap_irq_chip,
> + &dev->regmap_irqc);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to add irq chip: %d\n", ret);
> + return ret;
> + }
> +
> + ret = devm_mfd_add_devices(dev->dev, 0, cells, size, NULL, 0, NULL);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to add MFD devices: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static struct platform_driver sun4i_gpadc_driver = {
> + .driver = {
> + .name = "sun4i-gpadc",
> + .of_match_table = of_match_ptr(sun4i_gpadc_of_match),
> + },
> + .probe = sun4i_gpadc_probe,
> +};
> +
> +module_platform_driver(sun4i_gpadc_driver);
> +
> +MODULE_DESCRIPTION("Allwinner sunxi platforms' GPADC MFD core driver");
> +MODULE_AUTHOR("Quentin Schulz <quentin.schulz@free-electrons.com>");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> new file mode 100644
> index 0000000..d7a29f2
> --- /dev/null
> +++ b/include/linux/mfd/sun4i-gpadc.h
> @@ -0,0 +1,94 @@
> +/* Header of ADC MFD core driver for sunxi platforms
> + *
> + * Copyright (c) 2016 Quentin Schulz <quentin.schulz@free-electrons.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.
> + */
> +
> +#ifndef __SUN4I_GPADC__H__
> +#define __SUN4I_GPADC__H__
> +
> +#define SUN4I_GPADC_CTRL0 0x00
> +
> +#define SUN4I_GPADC_CTRL0_ADC_FIRST_DLY(x) ((GENMASK(7, 0) & (x)) << 24)
> +#define SUN4I_GPADC_CTRL0_ADC_FIRST_DLY_MODE BIT(23)
> +#define SUN4I_GPADC_CTRL0_ADC_CLK_SELECT BIT(22)
> +#define SUN4I_GPADC_CTRL0_ADC_CLK_DIVIDER(x) ((GENMASK(1, 0) & (x)) << 20)
> +#define SUN4I_GPADC_CTRL0_FS_DIV(x) ((GENMASK(3, 0) & (x)) << 16)
> +#define SUN4I_GPADC_CTRL0_T_ACQ(x) (GENMASK(15, 0) & (x))
> +
> +#define SUN4I_GPADC_CTRL1 0x04
> +
> +#define SUN4I_GPADC_CTRL1_STYLUS_UP_DEBOUNCE(x) ((GENMASK(7, 0) & (x)) << 12)
> +#define SUN4I_GPADC_CTRL1_STYLUS_UP_DEBOUNCE_EN BIT(9)
> +#define SUN4I_GPADC_CTRL1_TOUCH_PAN_CALI_EN BIT(6)
> +#define SUN4I_GPADC_CTRL1_TP_DUAL_EN BIT(5)
> +#define SUN4I_GPADC_CTRL1_TP_MODE_EN BIT(4)
> +#define SUN4I_GPADC_CTRL1_TP_ADC_SELECT BIT(3)
> +#define SUN4I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(2, 0) & (x))
> +
> +/* TP_CTRL1 bits for sun6i SOCs */
> +#define SUN6I_GPADC_CTRL1_TOUCH_PAN_CALI_EN BIT(7)
> +#define SUN6I_GPADC_CTRL1_TP_DUAL_EN BIT(6)
> +#define SUN6I_GPADC_CTRL1_TP_MODE_EN BIT(5)
> +#define SUN6I_GPADC_CTRL1_TP_ADC_SELECT BIT(4)
> +#define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
> +
> +#define SUN4I_GPADC_CTRL2 0x08
> +
> +#define SUN4I_GPADC_CTRL2_TP_SENSITIVE_ADJUST(x) ((GENMASK(3, 0) & (x)) << 28)
> +#define SUN4I_GPADC_CTRL2_TP_MODE_SELECT(x) ((GENMASK(1, 0) & (x)) << 26)
> +#define SUN4I_GPADC_CTRL2_PRE_MEA_EN BIT(24)
> +#define SUN4I_GPADC_CTRL2_PRE_MEA_THRE_CNT(x) (GENMASK(23, 0) & (x))
> +
> +#define SUN4I_GPADC_CTRL3 0x0c
> +
> +#define SUN4I_GPADC_CTRL3_FILTER_EN BIT(2)
> +#define SUN4I_GPADC_CTRL3_FILTER_TYPE(x) (GENMASK(1, 0) & (x))
> +
> +#define SUN4I_GPADC_TPR 0x18
> +
> +#define SUN4I_GPADC_TPR_TEMP_ENABLE BIT(16)
> +#define SUN4I_GPADC_TPR_TEMP_PERIOD(x) (GENMASK(15, 0) & (x))
> +
> +#define SUN4I_GPADC_INT_FIFOC 0x10
> +
> +#define SUN4I_GPADC_INT_FIFOC_TEMP_IRQ_EN BIT(18)
> +#define SUN4I_GPADC_INT_FIFOC_TP_OVERRUN_IRQ_EN BIT(17)
> +#define SUN4I_GPADC_INT_FIFOC_TP_DATA_IRQ_EN BIT(16)
> +#define SUN4I_GPADC_INT_FIFOC_TP_DATA_XY_CHANGE BIT(13)
> +#define SUN4I_GPADC_INT_FIFOC_TP_FIFO_TRIG_LEVEL(x) ((GENMASK(4, 0) & (x)) << 8)
> +#define SUN4I_GPADC_INT_FIFOC_TP_DATA_DRQ_EN BIT(7)
> +#define SUN4I_GPADC_INT_FIFOC_TP_FIFO_FLUSH BIT(4)
> +#define SUN4I_GPADC_INT_FIFOC_TP_UP_IRQ_EN BIT(1)
> +#define SUN4I_GPADC_INT_FIFOC_TP_DOWN_IRQ_EN BIT(0)
> +
> +#define SUN4I_GPADC_INT_FIFOS 0x14
> +
> +#define SUN4I_GPADC_INT_FIFOS_TEMP_DATA_PENDING BIT(18)
> +#define SUN4I_GPADC_INT_FIFOS_FIFO_OVERRUN_PENDING BIT(17)
> +#define SUN4I_GPADC_INT_FIFOS_FIFO_DATA_PENDING BIT(16)
> +#define SUN4I_GPADC_INT_FIFOS_TP_IDLE_FLG BIT(2)
> +#define SUN4I_GPADC_INT_FIFOS_TP_UP_PENDING BIT(1)
> +#define SUN4I_GPADC_INT_FIFOS_TP_DOWN_PENDING BIT(0)
> +
> +#define SUN4I_GPADC_CDAT 0x1c
> +#define SUN4I_GPADC_TEMP_DATA 0x20
> +#define SUN4I_GPADC_DATA 0x24
> +
> +#define SUN4I_GPADC_IRQ_FIFO_DATA 0
> +#define SUN4I_GPADC_IRQ_TEMP_DATA 1
> +
> +/* 10s delay before suspending the IP */
> +#define SUN4I_GPADC_AUTOSUSPEND_DELAY 10000
> +
> +struct sun4i_gpadc_dev {
> + struct device *dev;
> + struct regmap *regmap;
> + struct regmap_irq_chip_data *regmap_irqc;
> + void __iomem *base;
> +};
> +
> +#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* bpf on Alpha [was Re: [PATCH 2/3] ARM: convert to generated system call tables]
From: Michael Cree @ 2016-10-26 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026070430.e2tkbzza5lk4lgju@tower>
On Wed, Oct 26, 2016 at 08:04:30PM +1300, Michael Cree wrote:
> On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> > On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > > I see your point, but I think there are serious issues with the current
> > > > approach as well:
> > > >
> > > > - a lot of the less common architectures just don't get updated
> > > > in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > > > only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > > >
> > > > - some architectures that add all syscalls sometimes make a mistake
> > > > and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > > > did add the later __NR_execveat.
> > >
> > > __NR_bpf was not forgotten on Alpha. It was not wired up because
> > > extra architecture support is needed which has not been implemented.
> > >
> > > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > > so a syscall number is reserved for it, and user space can call it to
> > > get -ENOSYS returned.
> >
> > Ah, I must have misinterpreted the code then. I assumed that the
> > bpf syscall always works on all architectures, but that only the
> > jit compiler for it required architecture specific code to make it
> > more efficient.
>
> Oh. When someone posted wiring up of syscalls on Alpha some time
> back I raised a query about seccomp then someone else (I can't be
> bothered looking up the old emails, it doesn't really matter)
> said bpf was in the same basket, so the patch was re-submitted with
> neither of those syscalls.
>
> > sys_seccomp is another one that falls into a similar category, but
> > it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> > architectures have assigned a syscall number but not set this symbol.
> > This one will actually allow you to set strict seccomp mode even
> > without the Kconfig symbol, just not allow to set a filter.
>
> We have got way behind on syscalls on Alpha and I was just in the
> process of wiring them up and testing them, so I will include both
> seccomp and bpf in that.
Having just wired up bpf on an Alpha and run samples/bpf/test_verifier
I get:
#0 add+sub+mul OK
#1 unreachable OK
#2 unreachable2 OK
#3 out of range jump OK
[snip many passing tests]
#69 unpriv: check that printk is disallowed FAIL
failed to load prog 'Invalid argument'
0: (7a) *(u64 *)(r10 -8) = 0
1: (bf) r1 = r10
2: (07) r1 += -8
3: (b7) r2 = 8
4: (bf) r3 = r1
5: (85) call 6
unknown func 6
[snip many more passing tests]
Summary: 101 PASSED, 1 FAILED
Should I be concerned about the failing #69 test?
Cheers
Michael.
^ permalink raw reply
* [PATCH] ARM: DT: stm32: move dma translation to board files
From: Alexandre Torgue @ 2016-10-26 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF3+Tqd2MGmz+8XhLXhaZiEc78QOwHSpVrQA65-p1AcfT+_xgg@mail.gmail.com>
Hi Bruno,
On 10/25/2016 11:06 PM, Bruno Herrera wrote:
> Hi Alexandre,
>
>>
>> stm32f469-disco and stm32f429-eval boards use SDRAM start address remapping
>> (to @0) to boost performances. A DMA translation through "dma-ranges"
>> property was needed for other masters than the M4 CPU.
>> stm32f429-disco doesn't use remapping so doesn't need this DMA translation.
>> This patches moves this DMA translation definition from stm32f429 soc file
>> to board files.
>>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>>
>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
>> index 13c7cd2..a763c15 100644
>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> @@ -82,6 +82,10 @@
>> };
>> };
>>
>> + soc {
>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> + };
>> +
>> usbotg_hs_phy: usbphy {
>> #phy-cells = <0>;
>> compatible = "usb-nop-xceiv";
>
> Shouldn't also the peripheral dma-ranges property move to board specific too?
> I had this patch for while but I didn't had the time to submit:
Well spot I forgot it. Actually, discussing with Arnd ysterday on IIRC,
empty dma-ranges is not needed. Can you test on your side by removing
dma-ranges in usb node please ?
I will push a v2 by removing empty dma-ranges if tests are ok in your side.
Thanks in advance
Alex
>
> Author: Bruno Herrera <bruherrera@gmail.com>
> Date: Sun Oct 16 14:50:00 2016 -0200
>
> ARM: DT: STM32: Use dma-ranges property per board not at dtsi file
>
> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
> b/arch/arm/boot/dts/stm32429i-eval.dts
> index 6bfc595..2a22a82 100644
> --- a/arch/arm/boot/dts/stm32429i-eval.dts
> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
> @@ -52,6 +52,10 @@
> model = "STMicroelectronics STM32429i-EVAL board";
> compatible = "st,stm32429i-eval", "st,stm32f429";
>
> + soc {
> + dma-ranges = <0xC0000000 0x0 0x10000000>;
> + };
> +
> chosen {
> bootargs = "root=/dev/ram rdinit=/linuxrc";
> stdout-path = "serial0:115200n8";
> @@ -96,6 +100,7 @@
>
> ðernet0 {
> status = "okay";
> + dma-ranges;
> pinctrl-0 = <ðernet0_mii>;
> pinctrl-names = "default";
> phy-mode = "mii-id";
> @@ -116,6 +121,7 @@
> };
>
> &usbotg_hs {
> + dma-ranges;
> dr_mode = "host";
> phys = <&usbotg_hs_phy>;
> phy-names = "usb2-phy";
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 7d624a2..697a133 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -59,7 +59,6 @@
> };
>
> soc {
> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>
> timer2: timer at 40000000 {
> compatible = "st,stm32-timer";
> @@ -472,13 +471,11 @@
> st,syscon = <&syscfg 0x4>;
> snps,pbl = <8>;
> snps,mixed-burst;
> - dma-ranges;
> status = "disabled";
> };
>
> usbotg_hs: usb at 40040000 {
> compatible = "snps,dwc2";
> - dma-ranges;
> reg = <0x40040000 0x40000>;
> interrupts = <77>;
> clocks = <&rcc 0 29>;
>
>
>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
>> index 0596d60..3a1cfdd 100644
>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> @@ -59,8 +59,6 @@
>> };
>>
>> soc {
>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>> -
>> timer2: timer at 40000000 {
>> compatible = "st,stm32-timer";
>> reg = <0x40000000 0x400>;
>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
>> index 9e73656..c2213c0 100644
>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>> @@ -64,6 +64,10 @@
>> aliases {
>> serial0 = &usart3;
>> };
>> +
>> + soc {
>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> + };
>> };
>>
>> &clk_hse {
>> --
>
>
> Br.,
> Bruno
>
^ permalink raw reply
* [PATCH v2] drm/mediatek: fixed the calc method of data rate per lane
From: Jitao Shi @ 2016-10-26 9:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477464081.17405.2.camel@mtksdaap41>
On Wed, 2016-10-26 at 14:41 +0800, CK Hu wrote:
> Hi, Jitao:
>
> On Tue, 2016-10-25 at 13:40 +0800, Jitao Shi wrote:
> > Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
> > Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
> > signal will cause h-time larger than normal and reduce FPS.
> > Need to multiply a coefficient to offset the extra signal's effect.
> > coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
> > Ths_exit)/(htotal*bpp/lane_number))
> >
> > Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
> > ---
> > Change since v1:
> > - phy_timing2 and phy_timing3 refer clock cycle time.
> > - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 103 +++++++++++++++++++++++-------------
> > 1 file changed, 67 insertions(+), 36 deletions(-)
> >
>
> [snip...]
>
> >
> > -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> > +static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
> > + u32 phy_timing1, u32 phy_timing2,
> > + u32 phy_timing3)
> > {
> > - u32 timcon0, timcon1, timcon2, timcon3;
> > - unsigned int ui, cycle_time;
> > - unsigned int lpx;
> > -
> > - ui = 1000 / dsi->data_rate + 0x01;
> > - cycle_time = 8000 / dsi->data_rate + 0x01;
> > - lpx = 5;
> > -
> > - timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
> > - timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
> > - (4 * lpx);
> > - timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> > - (NS_TO_CYCLE(0x150, cycle_time) << 16);
> > - timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> > - NS_TO_CYCLE(0x40, cycle_time);
> > -
> > - writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
> > - writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
> > - writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
> > - writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
>
> Why do you move these calculation to mtk_dsi_poweron()? You can keep
> calculation here and just do some modification.
>
> Regards,
> CK
Thanks for your review. I'll fix it in next patchset.
Best Regards
jitao
>
> > + writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
> > + writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
> > + writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
> > + writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
> > }
> >
> > static void mtk_dsi_enable(struct mtk_dsi *dsi)
> > @@ -202,19 +188,51 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> > {
> > struct device *dev = dsi->dev;
> > int ret;
> > + u64 bit_clock, total_bits;
> > + u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
> > + u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
> > + u32 ui, cycle_time;
> >
> > if (++dsi->refcount != 1)
> > return 0;
> >
> > + switch (dsi->format) {
> > + case MIPI_DSI_FMT_RGB565:
> > + bit_per_pixel = 16;
> > + break;
> > + case MIPI_DSI_FMT_RGB666_PACKED:
> > + bit_per_pixel = 18;
> > + break;
> > + case MIPI_DSI_FMT_RGB666:
> > + case MIPI_DSI_FMT_RGB888:
> > + default:
> > + bit_per_pixel = 24;
> > + break;
> > + }
> > + /**
> > + * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
> > + * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
> > + * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
> > + * + Thstrail + Ths_exit + Ths_zero) /
> > + * (htotal * byte_per_pixel /lane_number)
> > + */
> > + bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
> > + htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
> > + dsi->vm.hsync_len;
> > + htotal_bits = htotal * bit_per_pixel;
> > +
> > /**
> > - * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
> > - * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
> > - * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> > - * we set mipi_ratio is 1.05.
> > + * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
> > */
> > - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> > + overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
> > + (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
> > + overhead_bits = overhead_cycles * dsi->lanes * 8;
> > + total_bits = htotal_bits + overhead_bits;
> >
> > - ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> > + dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
> > + htotal_bits * dsi->lanes);
> > +
> > + ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
> > if (ret < 0) {
> > dev_err(dev, "Failed to set data rate: %d\n", ret);
> > goto err_refcount;
> > @@ -236,7 +254,20 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> >
> > mtk_dsi_enable(dsi);
> > mtk_dsi_reset(dsi);
> > - dsi_phy_timconfig(dsi);
> > +
> > + ui = 1000 / dsi->data_rate + 0x01;
> > + cycle_time = 8000 / dsi->data_rate + 0x01;
> > +
> > + phy_timing0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
> > + phy_timing1 = TA_GO | TA_SURE | TA_GET | DA_HS_EXIT;
> > + phy_timing2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
> > + (NS_TO_CYCLE(0x150, cycle_time) << 16);
> > + phy_timing3 = (2 * LPX) << 16 |
> > + NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
> > + NS_TO_CYCLE(0x40, cycle_time);
> > +
> > + dsi_phy_timconfig(dsi, phy_timing0, phy_timing1, phy_timing2,
> > + phy_timing3);
> >
> > return 0;
> >
>
>
^ permalink raw reply
* [PATCH v3] drm/mediatek: fixed the calc method of data rate per lane
From: Jitao Shi @ 2016-10-26 8:59 UTC (permalink / raw)
To: linux-arm-kernel
Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
signal will cause h-time larger than normal and reduce FPS.
Need to multiply a coefficient to offset the extra signal's effect.
coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
Ths_exit)/(htotal*bpp/lane_number))
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
Change since v2:
- move phy timing back to dsi_phy_timconfig.
Change since v1:
- phy_timing2 and phy_timing3 refer clock cycle time.
- define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 74 +++++++++++++++++++++++++-----------
1 file changed, 51 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..8b3b38a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -85,16 +85,16 @@
#define LD0_WAKEUP_EN BIT(2)
#define DSI_PHY_TIMECON0 0x110
-#define LPX (0xff << 0)
-#define HS_PRPR (0xff << 8)
-#define HS_ZERO (0xff << 16)
-#define HS_TRAIL (0xff << 24)
+#define LPX (5 << 0)
+#define HS_PRPR (6 << 8)
+#define HS_ZERO (10 << 16)
+#define HS_TRAIL (8 << 24)
#define DSI_PHY_TIMECON1 0x114
-#define TA_GO (0xff << 0)
-#define TA_SURE (0xff << 8)
-#define TA_GET (0xff << 16)
-#define DA_HS_EXIT (0xff << 24)
+#define TA_GO (20 << 0)
+#define TA_SURE (7 << 8)
+#define TA_GET (25 << 16)
+#define DA_HS_EXIT (7 << 24)
#define DSI_PHY_TIMECON2 0x118
#define CONT_DET (0xff << 0)
@@ -161,20 +161,18 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, u32 mask, u32 data)
static void dsi_phy_timconfig(struct mtk_dsi *dsi)
{
u32 timcon0, timcon1, timcon2, timcon3;
- unsigned int ui, cycle_time;
- unsigned int lpx;
+ u32 ui, cycle_time;
ui = 1000 / dsi->data_rate + 0x01;
cycle_time = 8000 / dsi->data_rate + 0x01;
- lpx = 5;
- timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
- timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
- (4 * lpx);
+ timcon0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
+ timcon1 = 4 * LPX | (3 * LPX / 2) << 8 | 5 * LPX << 16 | DA_HS_EXIT;
timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
- (NS_TO_CYCLE(0x150, cycle_time) << 16);
- timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
- NS_TO_CYCLE(0x40, cycle_time);
+ (NS_TO_CYCLE(0x150, cycle_time) << 16);
+ timcon3 = (2 * LPX) << 16 |
+ NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
+ NS_TO_CYCLE(0x40, cycle_time);
writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
@@ -202,19 +200,49 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
{
struct device *dev = dsi->dev;
int ret;
+ u64 bit_clock, total_bits;
+ u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
if (++dsi->refcount != 1)
return 0;
+ switch (dsi->format) {
+ case MIPI_DSI_FMT_RGB565:
+ bit_per_pixel = 16;
+ break;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ bit_per_pixel = 18;
+ break;
+ case MIPI_DSI_FMT_RGB666:
+ case MIPI_DSI_FMT_RGB888:
+ default:
+ bit_per_pixel = 24;
+ break;
+ }
/**
- * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
- * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
- * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
- * we set mipi_ratio is 1.05.
+ * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
+ * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
+ * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
+ * + Thstrail + Ths_exit + Ths_zero) /
+ * (htotal * byte_per_pixel /lane_number)
*/
- dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+ bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
+ htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
+ dsi->vm.hsync_len;
+ htotal_bits = htotal * bit_per_pixel;
+
+ /**
+ * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
+ */
+ overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
+ (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
+ overhead_bits = overhead_cycles * dsi->lanes * 8;
+ total_bits = htotal_bits + overhead_bits;
+
+ dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
+ htotal_bits * dsi->lanes);
- ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
+ ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
if (ret < 0) {
dev_err(dev, "Failed to set data rate: %d\n", ret);
goto err_refcount;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] dt-bindings: Update domain-idle-state binding to use correct compatibles
From: Sudeep Holla @ 2016-10-26 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7hh980taqp.fsf@baylibre.com>
On 25/10/16 21:49, Kevin Hilman wrote:
> Lina Iyer <lina.iyer@linaro.org> writes:
>
>> Update domain-idle-state binding to use "domain-idle-state" compatible
>> from Documentation/devicetree/bindings/arm/idle-states.txt.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Cc: Rob Herring <robh@kernel.org>
>> Suggested-by: Sudeep Holla <sudeep.holla@arm.com>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> ---
>> Documentation/devicetree/bindings/power/power_domain.txt | 9 +++++----
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> With no current users for this, I don't see the point of adding a
> compatible now.
>
> IMO, this should wait and be added with the identified user we can
> discuss it then.
>
No, IMO it needs to be used for the proposed SoC idle/genpd solution.
I understand the nodes that are "arm,idle-state" compatible can be used
for this new SoC hierarchical idle management, but it was never defined
for that use originally. So this new feature must be advertised by the
firmware with the presence of "domain-idle-state".
Yes we might have other ways to detect that but I have already seen that
broken on the reference platform, so we need alternate/DT way to specify
that.
Not all existing "arm,idle-state" compatible nodes will be capable of
supporting this new SoC idle feature. It's just better and safer for a
new feature getting added that relies on DT to have a new compatible.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] ARM: sti: stih410-clocks: Add PROC_STFE as a critical clock
From: Peter Griffin @ 2016-10-26 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026085141.GJ8574@dell>
Hi Lee,
On Wed, 26 Oct 2016, Lee Jones wrote:
> > > > If the clock is enabled when Linux boots, the Linux clock framework *needs*
> > > > to assume the hardware may have been used in previous boot stages, and it should
> > > > not attempt to disable the clock.
> > >
> > > None of the boot loaders we use do this.
> >
> > But the Linux kernel isn't just used by us. It is not uncommon for STB
> > bootloaders to get information from the frontend as part of the boot process.
>
> Okay, this is the clincher. Since we need to support non-standard
> bootloaders, it's difficult to guarantee that the clock will be
> disabled at boot. For this reason, I believe that we can call this a
> critical clock.
>
That's good news as the STi maintainer already acked and applied the patch.
Peter.
^ permalink raw reply
* [PATCH/RFT v2 02/17] ARM: davinci: da8xx: Add CFGCHIP syscon platform declaration.
From: Sekhar Nori @ 2016-10-26 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3af8517-c452-ae8c-6840-dd8a684e4ab2@lechnology.com>
On Tuesday 25 October 2016 09:23 PM, David Lechner wrote:
> Hi Sekhar,
>
> On 10/25/2016 05:17 AM, Sekhar Nori wrote:
>> On Tuesday 25 October 2016 03:07 PM, Axel Haslam wrote:
>>> Hi Sekar,
>>>
>>> On Tue, Oct 25, 2016 at 10:10 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>>>> On Monday 24 October 2016 10:16 PM, ahaslam at baylibre.com wrote:
>>>>> From: David Lechner <david@lechnology.com>
>>>>>
>>>>> The CFGCHIP registers are used by a number of devices, so using a
>>>>> syscon
>>>>> device to share them. The first consumer of this will by the
>>>>> phy-da8xx-usb
>>>>> driver.
>>>>>
>>>>> Signed-off-by: David Lechner <david@lechnology.com>
>>>>> [Axel: minor fix: change id to -1]
>>>>
>>>> Can you please clarify this change? There could be other syscon devices
>>>> on the chip for other common registers. Why use the singular device-id?
>>>>
>>>
>>> in the case of non DT boot, the phy driver is looking for "syscon" :
>>>
>>> d_phy->regmap = syscon_regmap_lookup_by_pdevname("syscon");
>>>
>>> if we register the syscon driver with id = 0, the actual name of the
>>> syscon
>>> device will be "syscon.0" and the phy driver will fail to probe, because
>>> the strncmp match in the syscon driver (syscon_match_pdevname)
>>> will fail.
>>>
>>> should i change the phy driver instead?
>>
>> Yes, please. Forcing only one syscon region for the whole chip will be
>> too restrictive, I am pretty sure.
>>
>> Thanks,
>> Sekhar
>>
>
> In the previous review, you requested that this be changed to -1 [1].
>
> If we change it back to 0, it will also require reverting a patch to the
> phy driver that has already been merged[2].
Sigh. Sorry about going around in circles on this one. Lets go with what
you have. If and when there is a need for another syscon node, the
driver and platform code can be updated. At least we will know why the
change is being done at that time.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v7] spi: sun4i: Allow transfers larger than FIFO size
From: Maxime Ripard @ 2016-10-26 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477465231-17704-1-git-send-email-mr.nuke.me@gmail.com>
On Wed, Oct 26, 2016 at 12:00:30AM -0700, Alexandru Gagniuc wrote:
> This is the seventh attempt to get this patch in. I was prompted to look
> into this again as someone recently remarked:
>
> " cool, to bad spi does not work properly on allwinner..."
>
> Two and a half years ago, we were told this will all be handled with DMA.
> A year or so ago, we were told this will all be handled with DMA.
> A week or so ago, we were told this will all be handled with DMA.
>
> See the pattern?
> When DMA finally takes over, this fallback path is not mutually exclusive.
I definitely agree, and we had this patch in the CHIP kernel for quite
some time, working like a charm.
I was planning to respin it in the next few days, glad to see you took
care of it :)
Mark, any comments on this? For the record, it already has my Acked-by.
Thanks,
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161026/f2bea18e/attachment.sig>
^ permalink raw reply
* [PATCH v14 5/9] clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
From: Fu Wei @ 2016-10-26 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021112120.GC16630@leverpostej>
Hi Mark,
On 21 October 2016 at 19:21, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Oct 21, 2016 at 12:14:01PM +0100, Mark Rutland wrote:
>> On Thu, Oct 20, 2016 at 05:58:17PM +0100, Mark Rutland wrote:
>> > On Thu, Sep 29, 2016 at 02:17:13AM +0800, fu.wei at linaro.org wrote:
>> > > + arch_timer_ppi[PHYS_NONSECURE_PPI] = acpi_gtdt_map_ppi(PHYS_NONSECURE_PPI);
>> > > + arch_timer_ppi[VIRT_PPI] = acpi_gtdt_map_ppi(VIRT_PPI);
>> > > + arch_timer_ppi[HYP_PPI] = acpi_gtdt_map_ppi(HYP_PPI);
>> > > + /* Always-on capability */
>> > > + arch_timer_c3stop = acpi_gtdt_c3stop();
>> >
>> > ... I think we should check the flag on the relevant interrupt, though
>> > that's worth clarifying.
>>
>> I see I misread the spec; this is part of the common flags.
>>
>> Please ignore this point; sorry for the noise.
>
> Actually, I misread the spec this time around; the flag *can* differ per
> interrupt for the sysreg/cp15 timer, but not for the MMIO timers where
> the flag is in a common field.
>
> So please *do* consider the above.
yes , you are right , will do
Thanks :-)
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [linux-sunxi] [PATCH RESEND 1/2] dt: bindings: add allwinner, otg-routed property for phy-sun4i-usb
From: Icenowy Zheng @ 2016-10-26 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55fe59fc-6e93-d519-2d7c-264c48820fc4@redhat.com>
26.10.2016, 16:28, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 25-10-16 06:11, Icenowy Zheng wrote:
>> ?On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
>> ?the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
>> ?(which is a Host-only controller, but more stable and easy to implement).
>>
>> ?This property marks whether on a certain board which controller should be
>> ?attached to the PHY.
>>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> Icenowy, I appreciate your work on this, but we really need full otg
> support with dynamic switching rather then hardwiring the routing, so
> this cannot go in as is.
Now I have both PHY0 controllers' drivers.
In the tree of https://github.com/Icenowy/linux/tree/ice-a64-v6.1 , I have already
enabled MUSB controller.
And this patchset is for those prefer a stable USB host implement to dual-role
implementation. MUSB is a good UDC, but not a good host controller. My USB
sound card cannot work on MUSB on A33. Even connecting a R8's MUSB (Serial
Gadget) to an A33's MUSB cannot work.
See the IRC log between Andre and me,
https://irclog.whitequark.org/linux-sunxi/2016-10-24#18012695; .
>
> NACK.
>
> Regards,
>
> Hans
>
>> ?---
>> ??Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 6 ++++++
>> ??1 file changed, 6 insertions(+)
>>
>> ?diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?index 287150d..a63c766 100644
>> ?--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> ?@@ -36,6 +36,12 @@ Optional properties:
>> ??- usb1_vbus-supply : regulator phandle for controller usb1 vbus
>> ??- usb2_vbus-supply : regulator phandle for controller usb2 vbus
>>
>> ?+Optional properties for H3 or A64 SoCs:
>> ?+- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
>> ?+ MUSB. (boolean, if this property is set, the OHCI/EHCI
>> ?+ controllers at PHY0 should be enabled and the MUSB
>> ?+ controller must *NOT* be enabled)
>> ?+
>> ??Example:
>> ??????????usbphy: phy at 0x01c13400 {
>> ??????????????????#phy-cells = <1>;
^ permalink raw reply
* [PATCH] ARM: sti: stih410-clocks: Add PROC_STFE as a critical clock
From: Lee Jones @ 2016-10-26 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025134940.GA3993@griffinp-ThinkPad-X1-Carbon-2nd>
> > > If the clock is enabled when Linux boots, the Linux clock framework *needs*
> > > to assume the hardware may have been used in previous boot stages, and it should
> > > not attempt to disable the clock.
> >
> > None of the boot loaders we use do this.
>
> But the Linux kernel isn't just used by us. It is not uncommon for STB
> bootloaders to get information from the frontend as part of the boot process.
Okay, this is the clincher. Since we need to support non-standard
bootloaders, it's difficult to guarantee that the clock will be
disabled at boot. For this reason, I believe that we can call this a
critical clock.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Lee Jones @ 2016-10-26 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CC15CFB4-60D0-4A63-A3D3-2079CFA31274@gmail.com>
On Tue, 25 Oct 2016, John Syne wrote:
> > On Oct 24, 2016, at 11:38 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Mon, 24 Oct 2016, John Syne wrote:
> >>> On Oct 24, 2016, at 11:01 PM, John Syne <john3909@gmail.com> wrote:
> >>>> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> >>>>
> >>>> On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
> >>>>>>> On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> >>>>>>>
> >>>>>>> Increase ADC reference clock from 3MHz to 24MHz so that the
> >>>>>>> sampling rates goes up from 100K samples per second to 800K
> >>>>>>> samples per second on AM335x and AM437x SoC.
> >>>>>>>
> >>>>>>> Also increase opendelay for touchscreen configuration to
> >>>>>>> equalize the increase in ADC reference clock frequency,
> >>>>>>> which results in the same amount touch events reported via
> >>>>>>> evtest on AM335x GP EVM.
> >>>>>>>
> >>>>>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> >>>>>>> ---
> >>>>>>>
> >>>>>>> This patch depends on ADC DMA patch series [1]
> >>>>>>>
> >>>>>>> Without DMA support, when ADC ref clock is set at 24MHz, I am
> >>>>>>> seeing fifo overflow as CPU is not able to pull the ADC samples.
> >>>>>>> This answers that DMA support is must for ADC to consume the
> >>>>>>> samples generated at 24MHz with no open, step delay or
> >>>>>>> averaging with patch [2].
> >>>>>>>
> >>>>>>> Measured the performance with the iio_generic_buffer with the
> >>>>>>> patch [3] applied
> >>>>>>>
> >>>>>>> [1] - http://www.spinics.net/lists/devicetree/msg145045.html
> >>>>>>> [2] - http://pastebin.ubuntu.com/23357935/
> >>>>>>> [3] - http://pastebin.ubuntu.com/23357939/
> >>>>>>>
> >>>>>>> ---
> >>>>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
> >>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
> >>>>>>> index b9a53e0..96c4207 100644
> >>>>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
> >>>>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> >>>>>>> @@ -90,7 +90,7 @@
> >>>>>>> /* Delay register */
> >>>>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
> >>>>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
> >>>>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
> >>>>> Wouldn?t this be better to add this to the devicetree?
> >>>>>
> >>>>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> >>>>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> >>>>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
> >>>>
> >>>> For a touch screen, there is not need to change in these parameter
> >>>> settings, so my opinion is to keep it as is. Or am I missing something?
> >>> I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
> >>
> >> Here is a DT overlay were this gets using on the BeagleBoneBlack.
> >>
> >> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
> >>
> >> Besides, these DT features are already implemented in the driver so it is just a matter of adding these entries to the am33xx.dtsi & am4372.dtsi, which you modified in this patch series.
> >
> > This looks like configuration, no?
> >
> > DT should be used to describe the hardware.
> You may be right, but how is this different to setting the baud rate on a serial channel or sampling rate on a audio channel? Looking through the DT, there are many configuration settings, so I?m not sure what is the correct way to handle this. Surely it is better to handle this in DT vs hard coding these settings?
I think setting the UART baud rate is also an invalid DT entry.
It's okay to list all of the options in DT, but to actually select
one, that should be done either in userspace or as a kernel option.
Perhaps as a Kconfig selection.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v14 1/9] clocksource/drivers/arm_arch_timer: Move enums and defines to header file
From: Fu Wei @ 2016-10-26 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020144510.GJ10234@leverpostej>
Hi Mark
On 20 October 2016 at 22:45, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
> On Thu, Sep 29, 2016 at 02:17:09AM +0800, fu.wei at linaro.org wrote:
>> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
>> index caedb74..6f06481 100644
>> --- a/include/clocksource/arm_arch_timer.h
>> +++ b/include/clocksource/arm_arch_timer.h
>> @@ -19,6 +19,9 @@
>
> Please add:
>
> #include <linux/bitops.h>
>
> ... immediately before the includes below; it's needed to ensure that
> BIT() is defined in all cases. Previously we were relying on implicit
> header includes, which is not good practice.
yes, you are right!
added this, thanks !
>
>> #include <linux/timecounter.h>
>> #include <linux/types.h>
>>
>> +#define ARCH_CP15_TIMER BIT(0)
>> +#define ARCH_MEM_TIMER BIT(1)
>
> If we're going to expose these in a header, it would be better to rename
> them to something that makes their usage/meaning clear. These should
> probably be ARCH_TIMER_TYPE_{CP15,MEM}.
>
> I guess this can wait for subsequent cleanup.
>
>> +enum ppi_nr {
>> + PHYS_SECURE_PPI,
>> + PHYS_NONSECURE_PPI,
>> + VIRT_PPI,
>> + HYP_PPI,
>> + MAX_TIMER_PPI
>> +};
>
> Please rename this to arch_timer_ppi_nr (updating the single user in
> drivers/clocksource/arm_arch_timer.c). That'll avoid the potential for
> name clashes in files this happens to get included in (potentially
> transitively via other headers).
OK, NP, I have fixed this.
>
> With those changes (regardless of the ARCH_TIMER_TYPE_* bits):
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
For ARCH_TIMER_TYPE_*, maybe I should add a patch at the end of this
patchset to fix it, OK ?
Thanks for ACK :-)
>
> Thanks,
> Mark.
>
>> +
>> #define ARCH_TIMER_PHYS_ACCESS 0
>> #define ARCH_TIMER_VIRT_ACCESS 1
>> #define ARCH_TIMER_MEM_PHYS_ACCESS 2
>> --
>> 2.7.4
>>
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [linux-sunxi] [PATCH RESEND 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb
From: Hans de Goede @ 2016-10-26 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025041139.46454-1-icenowy@aosc.xyz>
Hi,
On 25-10-16 06:11, Icenowy Zheng wrote:
> On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
> the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
> (which is a Host-only controller, but more stable and easy to implement).
>
> This property marks whether on a certain board which controller should be
> attached to the PHY.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Icenowy, I appreciate your work on this, but we really need full otg
support with dynamic switching rather then hardwiring the routing, so
this cannot go in as is.
NACK.
Regards,
Hans
> ---
> Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 287150d..a63c766 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -36,6 +36,12 @@ Optional properties:
> - usb1_vbus-supply : regulator phandle for controller usb1 vbus
> - usb2_vbus-supply : regulator phandle for controller usb2 vbus
>
> +Optional properties for H3 or A64 SoCs:
> +- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
> + MUSB. (boolean, if this property is set, the OHCI/EHCI
> + controllers at PHY0 should be enabled and the MUSB
> + controller must *NOT* be enabled)
> +
> Example:
> usbphy: phy at 0x01c13400 {
> #phy-cells = <1>;
>
^ permalink raw reply
* [PATCH v14 3/9] clocksource/drivers/arm_arch_timer: Improve printk relevant code
From: Fu Wei @ 2016-10-26 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020153244.GB27598@leverpostej>
Hi Mark,
On 20 October 2016 at 23:32, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Sep 29, 2016 at 02:17:11AM +0800, fu.wei at linaro.org wrote:
>> static void arch_timer_banner(unsigned type)
>> {
>> - pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
>> - type & ARCH_CP15_TIMER ? "cp15" : "",
>> - type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "",
>> - type & ARCH_MEM_TIMER ? "mmio" : "",
>> - (unsigned long)arch_timer_rate / 1000000,
>> - (unsigned long)(arch_timer_rate / 10000) % 100,
>> - type & ARCH_CP15_TIMER ?
>> - (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
>> - "",
>> - type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "",
>> - type & ARCH_MEM_TIMER ?
>> - arch_timer_mem_use_virtual ? "virt" : "phys" :
>> - "");
>> + pr_info("%s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
>> + type & ARCH_CP15_TIMER ? "cp15" : "",
>> + type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "",
>> + type & ARCH_MEM_TIMER ? "mmio" : "",
>> + (unsigned long)arch_timer_rate / 1000000,
>> + (unsigned long)(arch_timer_rate / 10000) % 100,
>> + type & ARCH_CP15_TIMER ?
>> + (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :
>> + "",
> Please restore the additional indent on this line...
>
>> + type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "",
>> + type & ARCH_MEM_TIMER ?
>> + arch_timer_mem_use_virtual ? "virt" : "phys" :
>> + "");
>
> ... and these two.
>
> No matter what checkpatch says, I prefer the code that way so as to keep
> the ternary clear.
yes, NP, I have fixed it :-)
>
> [...]
>
>> @@ -768,7 +769,7 @@ static int __init arch_timer_init(void)
>> return ret;
>>
>> arch_timer_kvm_info.virtual_irq = arch_timer_ppi[VIRT_PPI];
>> -
>> +
>
> Please mention the whitespace fixup in the commit message. It's
> surprising otherwise.
OK, added this message.
>
> With all that:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
Great thanks :-)
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ permalink raw reply
* [PATCH v14 2/9] clocksource/drivers/arm_arch_timer: Add a new enum for spi type
From: Fu Wei @ 2016-10-26 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020150933.GK10234@leverpostej>
Hi Mark,
On 20 October 2016 at 23:09, Mark Rutland <mark.rutland@arm.com> wrote:
> On Thu, Sep 29, 2016 at 02:17:10AM +0800, fu.wei at linaro.org wrote:
>> diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h
>> index 6f06481..16dcd10 100644
>> --- a/include/clocksource/arm_arch_timer.h
>> +++ b/include/clocksource/arm_arch_timer.h
>> @@ -45,6 +45,12 @@ enum ppi_nr {
>> MAX_TIMER_PPI
>> };
>>
>> +enum spi_nr {
>> + PHYS_SPI,
>> + VIRT_SPI,
>> + MAX_TIMER_SPI
>> +};
>
> Please rename this to arch_timer_spi_nr (as with patch 1 for
> s/ppi_nr/arch_timer_ppi_nr/). With that:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
OK, NP, done :-)
Great thanks!
>
> Thanks,
> Mark.
--
Best regards,
Fu Wei
Software Engineer
Red Hat
^ 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