* Re: [PATCH v8 6/6] PM / devfreq: Use PM QoS for sysfs min/max_freq
From: Leonard Crestez @ 2019-09-25 22:11 UTC (permalink / raw)
To: Chanwoo Choi, Matthias Kaehlcke
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan,
linux-pm@vger.kernel.org, Viresh Kumar, dl-linux-imx,
Krzysztof Kozlowski, Lukasz Luba, Kyungmin Park, MyungJoo Ham,
Alexandre Bailon, Georgi Djakov,
linux-arm-kernel@lists.infradead.org, Jacky Bai
In-Reply-To: <c521989f-51b6-84eb-b4f1-c4469494345e@samsung.com>
On 25.09.2019 05:36, Chanwoo Choi wrote:
> On 19. 9. 24. 오후 7:11, Leonard Crestez wrote:
>> Switch the handling of min_freq and max_freq from sysfs to use the
>> dev_pm_qos_request interface.
>>
>> Since PM QoS handles frequencies as kHz this change reduces the
>> precision of min_freq and max_freq. This shouldn't introduce problems
>> because frequencies which are not an integer number of kHz are likely
>> not an integer number of Hz either.
>>
>> Try to ensure compatibility by rounding min values down and rounding
>> max values up.
>>
>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
>> ---
>> drivers/devfreq/devfreq.c | 46 ++++++++++++++++++++++++---------------
>> include/linux/devfreq.h | 9 ++++----
>> 2 files changed, 33 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index 784f3e40536a..8bb7efd821ab 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -137,14 +137,10 @@ static void get_freq_range(struct devfreq *devfreq,
>> qos_max_freq = dev_pm_qos_read_value(devfreq->dev.parent,
>> DEV_PM_QOS_MIN_FREQUENCY);
>> *min_freq = max(*min_freq, HZ_PER_KHZ * qos_min_freq);
>> *max_freq = min(*max_freq, HZ_PER_KHZ * qos_max_freq);
>>
>> - /* constraints from sysfs */
>> - *min_freq = max(*min_freq, devfreq->min_freq);
>> - *max_freq = min(*max_freq, devfreq->max_freq);
>> -
>> /* constraints from OPP interface */
>> *min_freq = max(*min_freq, devfreq->scaling_min_freq);
>> /* scaling_max_freq can be zero on error */
>> if (devfreq->scaling_max_freq)
>> *max_freq = min(*max_freq, devfreq->scaling_max_freq);
>> @@ -679,10 +675,12 @@ static void devfreq_dev_release(struct device *dev)
>> DEV_PM_QOS_MIN_FREQUENCY);
>>
>> if (devfreq->profile->exit)
>> devfreq->profile->exit(devfreq->dev.parent);
>>
>> + dev_pm_qos_remove_request(&devfreq->user_max_freq_req);
>> + dev_pm_qos_remove_request(&devfreq->user_min_freq_req);
>
> Please check the return value if error happen, just print the err with dev_err()
> without stopping the release steps.
OK, will print errors
>> kfree(devfreq->time_in_state);
>> kfree(devfreq->trans_table);
>> mutex_destroy(&devfreq->lock);
>> kfree(devfreq);
>> }
>> @@ -747,18 +745,25 @@ struct devfreq *devfreq_add_device(struct device *dev,
>> devfreq->scaling_min_freq = find_available_min_freq(devfreq);
>> if (!devfreq->scaling_min_freq) {
>> err = -EINVAL;
>> goto err_dev;
>> }
>> - devfreq->min_freq = devfreq->scaling_min_freq;
>>
>> devfreq->scaling_max_freq = find_available_max_freq(devfreq);
>> if (!devfreq->scaling_max_freq) {
>> err = -EINVAL;
>> goto err_dev;
>> }
>> - devfreq->max_freq = devfreq->scaling_max_freq;
>> +
>> + err = dev_pm_qos_add_request(dev, &devfreq->user_min_freq_req,
>> + DEV_PM_QOS_MIN_FREQUENCY, 0);
>> + if (err < 0)
>> + goto err_dev;
>> + err = dev_pm_qos_add_request(dev, &devfreq->user_max_freq_req,
>> + DEV_PM_QOS_MAX_FREQUENCY, S32_MAX);
>> + if (err < 0)
>> + goto err_dev;
>>
>> devfreq->suspend_freq = dev_pm_opp_get_suspend_opp_freq(dev);
>> atomic_set(&devfreq->suspend_count, 0);
>>
>> devfreq->trans_table = kzalloc(
>> @@ -843,10 +848,14 @@ struct devfreq *devfreq_add_device(struct device *dev,
>> err_dev:
>> /*
>> * Cleanup path for errors that happen before registration.
>> * Otherwise we rely on devfreq_dev_release.
>> */
>> + if (dev_pm_qos_request_active(&devfreq->user_max_freq_req))
>> + dev_pm_qos_remove_request(&devfreq->user_max_freq_req);
>
> Please check the return value if error happen, just print the err with dev_err()
> without stopping the release steps.
OK, will print errors
>
> dev_err(... "failed to remove request of DEV_PM_QOS_MAX_FREQUENCY\n");
>
>> + if (dev_pm_qos_request_active(&devfreq->user_min_freq_req))
>> + dev_pm_qos_remove_request(&devfreq->user_min_freq_req);
>
> dev_err(... "failed to remove request of DEV_PM_QOS_MIN_FREQUENCY\n");
>
>> kfree(devfreq->time_in_state);
>> kfree(devfreq->trans_table);
>> kfree(devfreq);
>> err_out:
>> return ERR_PTR(err);
>> @@ -1407,14 +1416,15 @@ static ssize_t min_freq_store(struct device *dev, struct device_attribute *attr,
>>
>> ret = sscanf(buf, "%lu", &value);
>> if (ret != 1)
>> return -EINVAL;
>>
>> - mutex_lock(&df->lock);
>> - df->min_freq = value;
>> - update_devfreq(df);
>> - mutex_unlock(&df->lock);
>> + /* round down to kHz for PM QoS */
>
> I prefer more detailed description as following:
>
> /*
> * Round down to KHz to decide the proper minimum frequency
> * which is closed to user request.
> */
>
>
>> + ret = dev_pm_qos_update_request(&df->user_min_freq_req,
>> + value / HZ_PER_KHZ);
>> + if (ret < 0)
>> + return ret;
>>
>> return count;
>> }
>>
>> static ssize_t min_freq_show(struct device *dev, struct device_attribute *attr,
>> @@ -1439,19 +1449,19 @@ static ssize_t max_freq_store(struct device *dev, struct device_attribute *attr,
>>
>> ret = sscanf(buf, "%lu", &value);
>> if (ret != 1)
>> return -EINVAL;
>>
>> - mutex_lock(&df->lock);
>> -
>> - /* Interpret zero as "don't care" */
>> - if (!value)
>> - value = ULONG_MAX;
>> + /* round up to kHz for PM QoS and interpret zero as "don't care" */
>
> I think that "don't care" comment style is not good.
>
> I referred to the Documentation/ABI/testing/sysfs-class-devfreq file.
> I prefer more detailed description as following:
> /*
> * Round up to KHz to decide the proper maximum frequency
> * which is closed to user request. If value is zero,
> * the user does not care.
> */
OK, will update this comment
>> + if (value)
>> + value = DIV_ROUND_UP(value, HZ_PER_KHZ);
>> + else
>> + value = S32_MAX;
>>
>> - df->max_freq = value;
>> - update_devfreq(df);
>> - mutex_unlock(&df->lock);
>> + ret = dev_pm_qos_update_request(&df->user_max_freq_req, value);
>> + if (ret < 0)
>> + return ret;
>>
>> return count;
>> }
>> static DEVICE_ATTR_RW(min_freq);
>>
>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>> index dac0dffeabb4..7849fe4c666d 100644
>> --- a/include/linux/devfreq.h
>> +++ b/include/linux/devfreq.h
>> @@ -11,10 +11,11 @@
>> #define __LINUX_DEVFREQ_H__
>>
>> #include <linux/device.h>
>> #include <linux/notifier.h>
>> #include <linux/pm_opp.h>
>> +#include <linux/pm_qos.h>
>>
>> #define DEVFREQ_NAME_LEN 16
>>
>> /* DEVFREQ governor name */
>> #define DEVFREQ_GOV_SIMPLE_ONDEMAND "simple_ondemand"
>> @@ -121,12 +122,12 @@ struct devfreq_dev_profile {
>> * devfreq.nb to the corresponding register notifier call chain.
>> * @work: delayed work for load monitoring.
>> * @previous_freq: previously configured frequency value.
>> * @data: Private data of the governor. The devfreq framework does not
>> * touch this.
>> - * @min_freq: Limit minimum frequency requested by user (0: none)
>> - * @max_freq: Limit maximum frequency requested by user (0: none)
>> + * @user_min_freq_req: PM QoS min frequency request from user (via sysfs)
>
> min -> minimum and then remove parenthesis as following:
> PM QoS minimum frequency request by user via sysfs
>
>> + * @user_max_freq_req: PM QoS max frequency request from user (via sysfs)
>
> ditto. max -> maximum
> PM QoS maximum frequency request by user via sysfs
OK
>> * @scaling_min_freq: Limit minimum frequency requested by OPP interface
>> * @scaling_max_freq: Limit maximum frequency requested by OPP interface
>> * @stop_polling: devfreq polling status of a device.
>> * @suspend_freq: frequency of a device set during suspend phase.
>> * @resume_freq: frequency of a device set in resume phase.
>> @@ -161,12 +162,12 @@ struct devfreq {
>> unsigned long previous_freq;
>> struct devfreq_dev_status last_status;
>>
>> void *data; /* private data for governors */
>>
>> - unsigned long min_freq;
>> - unsigned long max_freq;
>> + struct dev_pm_qos_request user_min_freq_req;
>> + struct dev_pm_qos_request user_max_freq_req;
>> unsigned long scaling_min_freq;
>> unsigned long scaling_max_freq;
>> bool stop_polling;
>>
>> unsigned long suspend_freq;
>>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv4-next 0/3] Odroid c2 usb fixs rebase on linux-next
From: Kevin Hilman @ 2019-09-25 22:04 UTC (permalink / raw)
To: Anand Moon, Rob Herring, Martin Blumenstingl, Jerome Brunet,
Neil Armstrong
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-amlogic
In-Reply-To: <20190902054935.4899-1-linux.amoon@gmail.com>
Anand Moon <linux.amoon@gmail.com> writes:
> Some time ago I had tired to enable usb bus 1 for Odroid C2/C1
> but it's look like some more work is needed to u-boot and
> usb_phy driver to initialize this port.
>
> Below patches tries to address the issue regarding usb bus 2 (4 port)
> while disable the usb bus 1 on this board.
>
> Previous patch
> [0] https://lkml.org/lkml/2019/1/29/325
>
> Re send below series based re based on linux-next-20190830.
> For review and testing.
>
> [1] https://patchwork.kernel.org/cover/11113091/
>
> Small changes from previous series.
> Fix the commit message for patch 1
Queued for v5.5.
I fixed up the typo in patch 2/3 when applying as suggested by Martin.
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/2] soc: amlogic: ee-pwrc: rename get_power
From: Kevin Hilman @ 2019-09-25 21:35 UTC (permalink / raw)
To: linux-amlogic, Neil Armstrong; +Cc: linux-arm-kernel, linux-pm
In-Reply-To: <20190925213528.21515-1-khilman@kernel.org>
From: Kevin Hilman <khilman@baylibre.com>
The function named _get_power() is misleading since it returns true
if the power is off. Rename to _is_off() for better readability.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/amlogic/meson-ee-pwrc.c | 34 ++++++++++++++---------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/soc/amlogic/meson-ee-pwrc.c b/drivers/soc/amlogic/meson-ee-pwrc.c
index 5823f5b67d16..dcce8e694a07 100644
--- a/drivers/soc/amlogic/meson-ee-pwrc.c
+++ b/drivers/soc/amlogic/meson-ee-pwrc.c
@@ -56,7 +56,7 @@ struct meson_ee_pwrc_domain_desc {
struct meson_ee_pwrc_top_domain *top_pd;
unsigned int mem_pd_count;
struct meson_ee_pwrc_mem_domain *mem_pd;
- bool (*get_power)(struct meson_ee_pwrc_domain *pwrc_domain);
+ bool (*is_off)(struct meson_ee_pwrc_domain *pwrc_domain);
};
struct meson_ee_pwrc_domain_data {
@@ -173,7 +173,7 @@ static struct meson_ee_pwrc_mem_domain sm1_pwrc_mem_audio[] = {
{ HHI_AUDIO_MEM_PD_REG0, GENMASK(27, 26) },
};
-#define VPU_PD(__name, __top_pd, __mem, __get_power, __resets, __clks) \
+#define VPU_PD(__name, __top_pd, __mem, __is_off, __resets, __clks) \
{ \
.name = __name, \
.reset_names_count = __resets, \
@@ -181,40 +181,40 @@ static struct meson_ee_pwrc_mem_domain sm1_pwrc_mem_audio[] = {
.top_pd = __top_pd, \
.mem_pd_count = ARRAY_SIZE(__mem), \
.mem_pd = __mem, \
- .get_power = __get_power, \
+ .is_off = __is_off, \
}
-#define TOP_PD(__name, __top_pd, __mem, __get_power) \
+#define TOP_PD(__name, __top_pd, __mem, __is_off) \
{ \
.name = __name, \
.top_pd = __top_pd, \
.mem_pd_count = ARRAY_SIZE(__mem), \
.mem_pd = __mem, \
- .get_power = __get_power, \
+ .is_off = __is_off, \
}
#define MEM_PD(__name, __mem) \
TOP_PD(__name, NULL, __mem, NULL)
-static bool pwrc_ee_get_power(struct meson_ee_pwrc_domain *pwrc_domain);
+static bool pwrc_ee_is_off(struct meson_ee_pwrc_domain *pwrc_domain);
static struct meson_ee_pwrc_domain_desc g12a_pwrc_domains[] = {
[PWRC_G12A_VPU_ID] = VPU_PD("VPU", &g12a_pwrc_vpu, g12a_pwrc_mem_vpu,
- pwrc_ee_get_power, 11, 2),
+ pwrc_ee_is_off, 11, 2),
[PWRC_G12A_ETH_ID] = MEM_PD("ETH", g12a_pwrc_mem_eth),
};
static struct meson_ee_pwrc_domain_desc sm1_pwrc_domains[] = {
[PWRC_SM1_VPU_ID] = VPU_PD("VPU", &sm1_pwrc_vpu, sm1_pwrc_mem_vpu,
- pwrc_ee_get_power, 11, 2),
+ pwrc_ee_is_off, 11, 2),
[PWRC_SM1_NNA_ID] = TOP_PD("NNA", &sm1_pwrc_nna, sm1_pwrc_mem_nna,
- pwrc_ee_get_power),
+ pwrc_ee_is_off),
[PWRC_SM1_USB_ID] = TOP_PD("USB", &sm1_pwrc_usb, sm1_pwrc_mem_usb,
- pwrc_ee_get_power),
+ pwrc_ee_is_off),
[PWRC_SM1_PCIE_ID] = TOP_PD("PCI", &sm1_pwrc_pci, sm1_pwrc_mem_pcie,
- pwrc_ee_get_power),
+ pwrc_ee_is_off),
[PWRC_SM1_GE2D_ID] = TOP_PD("GE2D", &sm1_pwrc_ge2d, sm1_pwrc_mem_ge2d,
- pwrc_ee_get_power),
+ pwrc_ee_is_off),
[PWRC_SM1_AUDIO_ID] = MEM_PD("AUDIO", sm1_pwrc_mem_audio),
[PWRC_SM1_ETH_ID] = MEM_PD("ETH", g12a_pwrc_mem_eth),
};
@@ -237,7 +237,7 @@ struct meson_ee_pwrc {
struct genpd_onecell_data xlate;
};
-static bool pwrc_ee_get_power(struct meson_ee_pwrc_domain *pwrc_domain)
+static bool pwrc_ee_is_off(struct meson_ee_pwrc_domain *pwrc_domain)
{
u32 reg;
@@ -367,7 +367,7 @@ static int meson_ee_pwrc_init_domain(struct platform_device *pdev,
* we need to power the domain off, otherwise the internal clocks
* prepare/enable counters won't be in sync.
*/
- if (dom->num_clks && dom->desc.get_power && !dom->desc.get_power(dom)) {
+ if (dom->num_clks && dom->desc.is_off && !dom->desc.is_off(dom)) {
int ret = clk_bulk_prepare_enable(dom->num_clks, dom->clks);
if (ret)
return ret;
@@ -375,8 +375,8 @@ static int meson_ee_pwrc_init_domain(struct platform_device *pdev,
pm_genpd_init(&dom->base, &pm_domain_always_on_gov, false);
} else
pm_genpd_init(&dom->base, NULL,
- (dom->desc.get_power ?
- dom->desc.get_power(dom) : true));
+ (dom->desc.is_off ?
+ dom->desc.is_off(dom) : true));
return 0;
}
@@ -454,7 +454,7 @@ static void meson_ee_pwrc_shutdown(struct platform_device *pdev)
for (i = 0 ; i < pwrc->xlate.num_domains ; ++i) {
struct meson_ee_pwrc_domain *dom = &pwrc->domains[i];
- if (dom->desc.get_power && !dom->desc.get_power(dom))
+ if (dom->desc.is_off && !dom->desc.is_off(dom))
meson_ee_pwrc_off(&dom->base);
}
}
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/2] soc: amlogic: ee-pwrc: ensure driver state maches HW state
From: Kevin Hilman @ 2019-09-25 21:35 UTC (permalink / raw)
To: linux-amlogic, Neil Armstrong; +Cc: linux-arm-kernel, linux-pm
In-Reply-To: <20190925213528.21515-1-khilman@kernel.org>
From: Kevin Hilman <khilman@baylibre.com>
During init, ensure that the driver on/off state as well as clock and
reset state matches the hardware state. Do this by always calling the
drivers 'on' function, and then callling the 'off' function if the
HW state was initially detected as off.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/soc/amlogic/meson-ee-pwrc.c | 29 ++++++++---------------------
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/soc/amlogic/meson-ee-pwrc.c b/drivers/soc/amlogic/meson-ee-pwrc.c
index dcce8e694a07..2e8eee0dc166 100644
--- a/drivers/soc/amlogic/meson-ee-pwrc.c
+++ b/drivers/soc/amlogic/meson-ee-pwrc.c
@@ -323,6 +323,8 @@ static int meson_ee_pwrc_init_domain(struct platform_device *pdev,
struct meson_ee_pwrc *pwrc,
struct meson_ee_pwrc_domain *dom)
{
+ bool is_off;
+
dom->pwrc = pwrc;
dom->num_rstc = dom->desc.reset_names_count;
dom->num_clks = dom->desc.clk_names_count;
@@ -356,27 +358,12 @@ static int meson_ee_pwrc_init_domain(struct platform_device *pdev,
dom->base.power_on = meson_ee_pwrc_on;
dom->base.power_off = meson_ee_pwrc_off;
- /*
- * TOFIX: This is a special case for the VPU power domain, which can
- * be enabled previously by the bootloader. In this case the VPU
- * pipeline may be functional but no driver maybe never attach
- * to this power domain, and if the domain is disabled it could
- * cause system errors. This is why the pm_domain_always_on_gov
- * is used here.
- * For the same reason, the clocks should be enabled in case
- * we need to power the domain off, otherwise the internal clocks
- * prepare/enable counters won't be in sync.
- */
- if (dom->num_clks && dom->desc.is_off && !dom->desc.is_off(dom)) {
- int ret = clk_bulk_prepare_enable(dom->num_clks, dom->clks);
- if (ret)
- return ret;
-
- pm_genpd_init(&dom->base, &pm_domain_always_on_gov, false);
- } else
- pm_genpd_init(&dom->base, NULL,
- (dom->desc.is_off ?
- dom->desc.is_off(dom) : true));
+ /* Ensure that driver state matches HW state */
+ is_off = dom->desc.is_off ? dom->desc.is_off(dom) : true;
+ meson_ee_pwrc_on(&dom->base);
+ if (is_off)
+ meson_ee_pwrc_off(&dom->base);
+ pm_genpd_init(&dom->base, NULL, is_off);
return 0;
}
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/2] soc: amlogic: ee-pwrc: cleanup init state
From: Kevin Hilman @ 2019-09-25 21:35 UTC (permalink / raw)
To: linux-amlogic, Neil Armstrong; +Cc: linux-arm-kernel, linux-pm
From: Kevin Hilman <khilman@baylibre.com>
Cleanup the PM domain init state and ensure that the driver state
matches the HW state for all domains.
Tested on meson-g12a-sei510 and meson-sm1-sei610 and verified that fb
console still working (VPU power domain.)
Changes since v1:
- always call 'on'
Kevin Hilman (2):
soc: amlogic: ee-pwrc: rename get_power
soc: amlogic: ee-pwrc: ensure driver state maches HW state
drivers/soc/amlogic/meson-ee-pwrc.c | 57 +++++++++++------------------
1 file changed, 22 insertions(+), 35 deletions(-)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters
From: Rob Herring @ 2019-09-25 21:33 UTC (permalink / raw)
To: Robin Murphy
Cc: moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree, Matthias Brugger, Frank Rowand, linux-arm-msm,
linux-wireless, linux-kernel@vger.kernel.org, dri-devel, etnaviv,
open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM, Florian Fainelli,
Stefan Wahren, james.quinlan, linux-pci, linux-tegra, xen-devel,
Dan Williams, freedreno, Nicolas Saenz Julienne,
Linux Media Mailing List
In-Reply-To: <aa4c8d62-7990-e385-2bb1-cec55148f0a8@arm.com>
On Wed, Sep 25, 2019 at 11:52 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 25/09/2019 17:16, Rob Herring wrote:
> > On Wed, Sep 25, 2019 at 10:30 AM Nicolas Saenz Julienne
> > <nsaenzjulienne@suse.de> wrote:
> >>
> >> On Wed, 2019-09-25 at 16:09 +0100, Robin Murphy wrote:
> >>> On 25/09/2019 15:52, Nicolas Saenz Julienne wrote:
> >>>> On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote:
> >>>>> On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne
> >>>>> <nsaenzjulienne@suse.de> wrote:
> >>>>>> Hi All,
> >>>>>> this series tries to address one of the issues blocking us from
> >>>>>> upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that
> >>>>>> devices not represented in DT which sit behind a PCI bus fail to get the
> >>>>>> bus' DMA addressing constraints.
> >>>>>>
> >>>>>> This is due to the fact that of_dma_configure() assumes it's receiving a
> >>>>>> DT node representing the device being configured, as opposed to the PCIe
> >>>>>> bridge node we currently pass. This causes the code to directly jump
> >>>>>> into PCI's parent node when checking for 'dma-ranges' and misses
> >>>>>> whatever was set there.
> >>>>>>
> >>>>>> To address this I create a new API in OF - inspired from Robin Murphys
> >>>>>> original proposal[2] - which accepts a bus DT node as it's input in
> >>>>>> order to configure a device's DMA constraints. The changes go deep into
> >>>>>> of/address.c's implementation, as a device being having a DT node
> >>>>>> assumption was pretty strong.
> >>>>>>
> >>>>>> On top of this work, I also cleaned up of_dma_configure() removing its
> >>>>>> redundant arguments and creating an alternative function for the special
> >>>>>> cases
> >>>>>> not applicable to either the above case or the default usage.
> >>>>>>
> >>>>>> IMO the resulting functions are more explicit. They will probably
> >>>>>> surface some hacky usages that can be properly fixed as I show with the
> >>>>>> DT fixes on the Layerscape platform.
> >>>>>>
> >>>>>> This was also tested on a Raspberry Pi 4 with a custom PCIe driver and
> >>>>>> on a Seattle AMD board.
> >>>>>
> >>>>> Humm, I've been working on this issue too. Looks similar though yours
> >>>>> has a lot more churn and there's some other bugs I've found.
> >>>>
> >>>> That's good news, and yes now that I see it, some stuff on my series is
> >>>> overly
> >>>> complicated. Specially around of_translate_*().
> >>>>
> >>>> On top of that, you removed in of_dma_get_range():
> >>>>
> >>>> - /*
> >>>> - * At least empty ranges has to be defined for parent node if
> >>>> - * DMA is supported
> >>>> - */
> >>>> - if (!ranges)
> >>>> - break;
> >>>>
> >>>> Which I assumed was bound to the standard and makes things easier.
> >>>>
> >>>>> Can you test out this branch[1]. I don't have any h/w needing this,
> >>>>> but wrote a unittest and tested with modified QEMU.
> >>>>
> >>>> I reviewed everything, I did find a minor issue, see the patch attached.
> >>>
> >>> WRT that patch, the original intent of "force_dma" was purely to
> >>> consider a device DMA-capable regardless of the presence of
> >>> "dma-ranges". Expecting of_dma_configure() to do anything for a non-OF
> >>> device has always been bogus - magic paravirt devices which appear out
> >>> of nowhere and expect to be treated as genuine DMA masters are a
> >>> separate problem that we haven't really approached yet.
> >>
> >> I agree it's clearly abusing the function. I have no problem with the behaviour
> >> change if it's OK with you.
>
> Thinking about it, you could probably just remove that call from the Xen
> DRM driver now anyway - since the dma-direct rework, we lost the ability
> to set dma_dummy_ops by default, and NULL ops now represent what it
> (presumably) wants.
Not xen_dma_ops? In any case, I'll send out a patch for the the Xen
folks to comment on.
> >> Robin, have you looked into supporting multiple dma-ranges? It's the next thing
> >> we need for BCM STB's PCIe. I'll have a go at it myself if nothing is in the
> >> works already.
> >
> > Multiple dma-ranges as far as configuring inbound windows should work
> > already other than the bug when there's any parent translation. But if
> > you mean supporting multiple DMA offsets and masks per device in the
> > DMA API, there's nothing in the works yet.
>
> There's also the in-between step of making of_dma_get_range() return a
> size based on all the dma-ranges entries rather than only the first one
> - otherwise, something like [1] can lead to pretty unworkable default
> masks. We implemented that when doing acpi_dma_get_range(), it's just
> that the OF counterpart never caught up.
Right. I suppose we assume any holes in the ranges are addressable by
the device but won't get used for other reasons (such as no memory
there). However, to be correct, the range of the dma offset plus mask
would need to be within the min start and max end addresses. IOW,
while we need to round up (0xa_8000_0000 - 0x2c1c_0000) to the next
power of 2, the 'correct' thing to do is round down.
Rob
> [1]
> http://linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=a2814af56b3486c2985a95540a88d8f9fa3a699f
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] soc: amlogic: ee-pwrc: ensure driver state maches HW state
From: Kevin Hilman @ 2019-09-25 21:25 UTC (permalink / raw)
To: linux-amlogic, Neil Armstrong; +Cc: linux-arm-kernel, linux-pm
In-Reply-To: <20190925191233.22253-3-khilman@baylibre.com>
Kevin Hilman <khilman@baylibre.com> writes:
> During init, ensure that the driver on/off state as well as clock
> state matches the hardware state by calling drivers on/off functions
> based on whether the HW state is on/off.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> drivers/soc/amlogic/meson-ee-pwrc.c | 30 +++++++++--------------------
> 1 file changed, 9 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/soc/amlogic/meson-ee-pwrc.c b/drivers/soc/amlogic/meson-ee-pwrc.c
> index dcce8e694a07..2cb5341aedfa 100644
> --- a/drivers/soc/amlogic/meson-ee-pwrc.c
> +++ b/drivers/soc/amlogic/meson-ee-pwrc.c
> @@ -323,6 +323,8 @@ static int meson_ee_pwrc_init_domain(struct platform_device *pdev,
> struct meson_ee_pwrc *pwrc,
> struct meson_ee_pwrc_domain *dom)
> {
> + bool is_off;
> +
> dom->pwrc = pwrc;
> dom->num_rstc = dom->desc.reset_names_count;
> dom->num_clks = dom->desc.clk_names_count;
> @@ -356,27 +358,13 @@ static int meson_ee_pwrc_init_domain(struct platform_device *pdev,
> dom->base.power_on = meson_ee_pwrc_on;
> dom->base.power_off = meson_ee_pwrc_off;
>
> - /*
> - * TOFIX: This is a special case for the VPU power domain, which can
> - * be enabled previously by the bootloader. In this case the VPU
> - * pipeline may be functional but no driver maybe never attach
> - * to this power domain, and if the domain is disabled it could
> - * cause system errors. This is why the pm_domain_always_on_gov
> - * is used here.
> - * For the same reason, the clocks should be enabled in case
> - * we need to power the domain off, otherwise the internal clocks
> - * prepare/enable counters won't be in sync.
> - */
> - if (dom->num_clks && dom->desc.is_off && !dom->desc.is_off(dom)) {
> - int ret = clk_bulk_prepare_enable(dom->num_clks, dom->clks);
> - if (ret)
> - return ret;
> -
> - pm_genpd_init(&dom->base, &pm_domain_always_on_gov, false);
> - } else
> - pm_genpd_init(&dom->base, NULL,
> - (dom->desc.is_off ?
> - dom->desc.is_off(dom) : true));
> + /* Ensure that driver state matches HW state */
> + is_off = dom->desc.is_off ? dom->desc.is_off(dom) : true;
> + if (is_off)
> + meson_ee_pwrc_off(&dom->base);
Neil pointed out off-list that this isn't quite right.
This _off() call can potentially try to disable clocks that have never
been enabled (by the clock fwk) resulting in noisy warnings.
I'll send a v2 which always calls _on() and then optionall calls _off().
That will ensure that the drivers notion of the clock state also matches
the HW state.
Kevin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 11/18] int128: move __uint128_t compiler test to Kconfig
From: Ard Biesheuvel @ 2019-09-25 21:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jason A . Donenfeld, Catalin Marinas, Herbert Xu, Arnd Bergmann,
Eric Biggers, Greg KH, Samuel Neves, Linux Crypto Mailing List,
Andy Lutomirski, Marc Zyngier, Dan Carpenter, Will Deacon,
David Miller, Linux ARM
In-Reply-To: <CAHk-=wi8+MHz8xGtx_mUZPBsRT6qkptGW7a_pOrK=SnTRAiecA@mail.gmail.com>
On Wed, 25 Sep 2019 at 23:01, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, Sep 25, 2019 at 9:14 AM Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> >
> > config ARCH_SUPPORTS_INT128
> > bool
> > + depends on !$(cc-option,-D__SIZEOF_INT128__=0)
>
> Hmm. Does this actually work?
>
> If that "depends on" now ends up being 'n', afaik the people who
> _enable_ it just do a
>
> select ARCH_SUPPORTS_INT128
>
> and now you'll end up with the Kconfig erroring out with
>
> WARNING: unmet direct dependencies detected for ARCH_SUPPORTS_INT128
>
> and then you end up with CONFIG_ARCH_SUPPORTS_INT128 anyway, instead
> of the behavior you _want_ to get, which is to not get that CONFIG
> defined at all.
>
> So I heartily agree with your intent, but I don't think that model
> works. I think you need to change the cases that currently do
>
> select ARCH_SUPPORTS_INT128
>
> to instead have that cc-option test.
>
> And take all the above with a pinch of salt. Maybe what you are doing
> works, and I am just missing some piece of the puzzle. But I _think_
> it's broken, and you didn't test with a compiler that doesn't support
> that thing properly.
>
I think you may be right.
Instead, I'll add a separate CC_HAS_INT128 symbol with the
$(cc-option) test, and replace occurrences of
select ARCH_SUPPORTS_INT128
with
select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
which is a slightly cleaner approach in any case.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 5/6] PM / devfreq: Add PM QoS support
From: Leonard Crestez @ 2019-09-25 21:18 UTC (permalink / raw)
To: Chanwoo Choi, Matthias Kaehlcke
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan,
linux-pm@vger.kernel.org, Viresh Kumar, dl-linux-imx,
Krzysztof Kozlowski, Lukasz Luba, Kyungmin Park, MyungJoo Ham,
Alexandre Bailon, Georgi Djakov,
linux-arm-kernel@lists.infradead.org, Jacky Bai
In-Reply-To: <40885624-8f11-4eea-d5bf-d6bb50fa44dd@samsung.com>
On 25.09.2019 05:11, Chanwoo Choi wrote:
> On 19. 9. 24. 오후 7:11, Leonard Crestez wrote:
>> Register notifiers with the PM QoS framework in order to respond to
>> requests for DEV_PM_QOS_MIN_FREQUENCY and DEV_PM_QOS_MAX_FREQUENCY.
>>
>> No notifiers are added by this patch but PM QoS constraints can be
>> imposed externally (for example from other devices).
>>
>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
>> ---
>> drivers/devfreq/devfreq.c | 75 +++++++++++++++++++++++++++++++++++++++
>> include/linux/devfreq.h | 5 +++
>> 2 files changed, 80 insertions(+)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index eee403e70c84..784f3e40536a 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -22,15 +22,18 @@
>> #include <linux/platform_device.h>
>> #include <linux/list.h>
>> #include <linux/printk.h>
>> #include <linux/hrtimer.h>
>> #include <linux/of.h>
>> +#include <linux/pm_qos.h>
>> #include "governor.h"
>>
>> #define CREATE_TRACE_POINTS
>> #include <trace/events/devfreq.h>
>>
>> +#define HZ_PER_KHZ 1000
>> +
>> static struct class *devfreq_class;
>>
>> /*
>> * devfreq core provides delayed work based load monitoring helper
>> * functions. Governors can use these or can implement their own
>> @@ -109,10 +112,11 @@ static unsigned long find_available_max_freq(struct devfreq *devfreq)
>> static void get_freq_range(struct devfreq *devfreq,
>> unsigned long *min_freq,
>> unsigned long *max_freq)
>> {
>> unsigned long *freq_table = devfreq->profile->freq_table;
>> + unsigned long qos_min_freq, qos_max_freq;
>>
>> lockdep_assert_held(&devfreq->lock);
>>
>> /*
>> * Init min/max frequency from freq table.
>> @@ -125,10 +129,18 @@ static void get_freq_range(struct devfreq *devfreq,
>> } else {
>> *min_freq = freq_table[devfreq->profile->max_state - 1];
>> *max_freq = freq_table[0];
>> }
>>
>> + /* constraints from PM QoS */
>
> As I commented on patch4,
> 'constraints' -> 'Constraint' because first verb have to be used
> as the sigular verbs.
Already discussed for another patch; I will modify to "Apply constraints
from PM QoS" instead.
> I prefer to use following comments:
>
> /* Constraint minimum/maximum frequency from PM QoS constraints */
>
>> + qos_min_freq = dev_pm_qos_read_value(devfreq->dev.parent,
>> + DEV_PM_QOS_MIN_FREQUENCY);
>> + qos_max_freq = dev_pm_qos_read_value(devfreq->dev.parent,
>> + DEV_PM_QOS_MIN_FREQUENCY);
>> + *min_freq = max(*min_freq, HZ_PER_KHZ * qos_min_freq);
>> + *max_freq = min(*max_freq, HZ_PER_KHZ * qos_max_freq);
>> +
>> /* constraints from sysfs */
>> *min_freq = max(*min_freq, devfreq->min_freq);
>> *max_freq = min(*max_freq, devfreq->max_freq);
>>
>> /* constraints from OPP interface */
>> @@ -606,10 +618,49 @@ static int devfreq_notifier_call(struct notifier_block *nb, unsigned long type,
>> mutex_unlock(&devfreq->lock);
>>
>> return ret;
>> }
>>
>> +/**
>> + * qos_notifier_call() - Common handler for QoS constraints.
>> + * @devfreq: the devfreq instance.
>> + */
>> +static int qos_notifier_call(struct devfreq *devfreq)
>> +{
>> + int err;
>> +
>> + mutex_lock(&devfreq->lock);
>> + err = update_devfreq(devfreq);
>> + mutex_unlock(&devfreq->lock);
>> + if (err)
>> + dev_err(devfreq->dev.parent,
>> + "failed to update frequency for PM QoS constraints (%d)\n",
>
> Is it not over 80 char?
Yes but coding style explicitly forbids breaking strings.
>> + err);
>> +
>> + return NOTIFY_OK;
>> +}
>> +
>> +/**
>> + * qos_min_notifier_call() - Callback for QoS min_freq changes.
>> + * @nb: Should be devfreq->nb_min
>> + */
>> +static int qos_min_notifier_call(struct notifier_block *nb,
>> + unsigned long val, void *ptr)
>> +{
>> + return qos_notifier_call(container_of(nb, struct devfreq, nb_min));
>> +}
>> +
>> +/**
>> + * qos_max_notifier_call() - Callback for QoS max_freq changes.
>> + * @nb: Should be devfreq->nb_max
>> + */
>> +static int qos_max_notifier_call(struct notifier_block *nb,
>> + unsigned long val, void *ptr)
>> +{
>> + return qos_notifier_call(container_of(nb, struct devfreq, nb_max));
>> +}
>> +
>> /**
>> * devfreq_dev_release() - Callback for struct device to release the device.
>> * @dev: the devfreq device
>> *
>> * Remove devfreq from the list and release its resources.
>> @@ -620,10 +671,15 @@ static void devfreq_dev_release(struct device *dev)
>>
>> mutex_lock(&devfreq_list_lock);
>> list_del(&devfreq->node);
>> mutex_unlock(&devfreq_list_lock);
>>
>> + dev_pm_qos_remove_notifier(devfreq->dev.parent, &devfreq->nb_max,
>> + DEV_PM_QOS_MAX_FREQUENCY);
>> + dev_pm_qos_remove_notifier(devfreq->dev.parent, &devfreq->nb_min,
>> + DEV_PM_QOS_MIN_FREQUENCY);
>> +
>
> Just print error with dev_err() without stopping the release step.
>
> I prefer to handle the return value if kernel API provides
> the error code.
>
>> if (devfreq->profile->exit)
>> devfreq->profile->exit(devfreq->dev.parent);
>>
>> kfree(devfreq->time_in_state);
>> kfree(devfreq->trans_table);
>> @@ -733,10 +789,28 @@ struct devfreq *devfreq_add_device(struct device *dev,
>> if (err) {
>> put_device(&devfreq->dev);
>> goto err_out;
>> }
>>
>> + /*
>> + * Register notifiers for updates to min/max_freq after device is
>> + * initialized (and we can handle notifications) but before the
>> + * governor is started (which should do an initial enforcement of
>> + * constraints).
>> + */
>
> My previous comment is not enough why I prefer to remove it. Sorry.
> Actually, until now, the devfreq_add_device() don't have the detailed
> comments because the line code is not too long. But, at the present time,
> devfreq_add_device() is too long. It means that the detailed comment
> are necessary.
>
> So, I'll add the detailed comment for each step of devfreq_add_device()
> on separate patch to keep the same style. I'll send the patch to you
> for the review.
This is very likely to result in merge conflicts, maybe wait for my
series to go in first?
>> + devfreq->nb_min.notifier_call = qos_min_notifier_call;
>> + err = dev_pm_qos_add_notifier(devfreq->dev.parent, &devfreq->nb_min,
>> + DEV_PM_QOS_MIN_FREQUENCY);
>> + if (err)
>> + goto err_devfreq;
>> +
>> + devfreq->nb_max.notifier_call = qos_max_notifier_call;
>> + err = dev_pm_qos_add_notifier(devfreq->dev.parent, &devfreq->nb_max,
>> + DEV_PM_QOS_MAX_FREQUENCY);
>> + if (err)
>> + goto err_devfreq;
>> +
>> mutex_lock(&devfreq_list_lock);
>>
>> governor = try_then_request_governor(devfreq->governor_name);
>> if (IS_ERR(governor)) {
>> dev_err(dev, "%s: Unable to find governor for the device\n",
>> @@ -760,10 +834,11 @@ struct devfreq *devfreq_add_device(struct device *dev,
>>
>> return devfreq;
>>
>> err_init:
>> mutex_unlock(&devfreq_list_lock);
>> +err_devfreq:
>> devfreq_remove_device(devfreq);
>> return ERR_PTR(err);
>>
>> err_dev:
>> /*
>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>> index c3cbc15fdf08..dac0dffeabb4 100644
>> --- a/include/linux/devfreq.h
>> +++ b/include/linux/devfreq.h
>> @@ -134,10 +134,12 @@ struct devfreq_dev_profile {
>> * @total_trans: Number of devfreq transitions
>> * @trans_table: Statistics of devfreq transitions
>> * @time_in_state: Statistics of devfreq states
>> * @last_stat_updated: The last time stat updated
>> * @transition_notifier_list: list head of DEVFREQ_TRANSITION_NOTIFIER notifier
>> + * @nb_min: Notifier block for DEV_PM_QOS_MIN_FREQUENCY
>> + * @nb_max: Notifier block for DEV_PM_QOS_MAX_FREQUENCY
>> *
>> * This structure stores the devfreq information for a give device.
>> *
>> * Note that when a governor accesses entries in struct devfreq in its
>> * functions except for the context of callbacks defined in struct
>> @@ -176,10 +178,13 @@ struct devfreq {
>> unsigned int *trans_table;
>> unsigned long *time_in_state;
>> unsigned long last_stat_updated;
>>
>> struct srcu_notifier_head transition_notifier_list;
>> +
>> + struct notifier_block nb_min;
>> + struct notifier_block nb_max;
>> };
>>
>> struct devfreq_freqs {
>> unsigned long old;
>> unsigned long new;
>>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 11/18] int128: move __uint128_t compiler test to Kconfig
From: Linus Torvalds @ 2019-09-25 21:01 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Jason A . Donenfeld, Catalin Marinas, Herbert Xu, Arnd Bergmann,
Eric Biggers, Greg KH, Samuel Neves, Linux Crypto Mailing List,
Andy Lutomirski, Marc Zyngier, Dan Carpenter, Will Deacon,
David Miller, Linux ARM
In-Reply-To: <20190925161255.1871-12-ard.biesheuvel@linaro.org>
On Wed, Sep 25, 2019 at 9:14 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> config ARCH_SUPPORTS_INT128
> bool
> + depends on !$(cc-option,-D__SIZEOF_INT128__=0)
Hmm. Does this actually work?
If that "depends on" now ends up being 'n', afaik the people who
_enable_ it just do a
select ARCH_SUPPORTS_INT128
and now you'll end up with the Kconfig erroring out with
WARNING: unmet direct dependencies detected for ARCH_SUPPORTS_INT128
and then you end up with CONFIG_ARCH_SUPPORTS_INT128 anyway, instead
of the behavior you _want_ to get, which is to not get that CONFIG
defined at all.
So I heartily agree with your intent, but I don't think that model
works. I think you need to change the cases that currently do
select ARCH_SUPPORTS_INT128
to instead have that cc-option test.
And take all the above with a pinch of salt. Maybe what you are doing
works, and I am just missing some piece of the puzzle. But I _think_
it's broken, and you didn't test with a compiler that doesn't support
that thing properly.
Linus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 4/6] PM / devfreq: Introduce get_freq_range helper
From: Leonard Crestez @ 2019-09-25 20:55 UTC (permalink / raw)
To: Chanwoo Choi, MyungJoo Ham, Kyungmin Park, Matthias Kaehlcke,
Viresh Kumar
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan,
linux-pm@vger.kernel.org, dl-linux-imx, Krzysztof Kozlowski,
Lukasz Luba, Alexandre Bailon, Georgi Djakov,
linux-arm-kernel@lists.infradead.org, Jacky Bai
In-Reply-To: <fe6845b9-4e20-3dad-0178-97b216e858e7@samsung.com>
On 25.09.2019 04:32, Chanwoo Choi wrote:
> On 19. 9. 24. 오후 7:11, Leonard Crestez wrote:
>> Moving handling of min/max freq to a single function and call it from
>> update_devfreq and for printing min/max freq values in sysfs.
>>
>> This changes the behavior of out-of-range min_freq/max_freq: clamping
>> is now done at evaluation time. This means that if an out-of-range
>> constraint is imposed by sysfs and it later becomes valid then it will
>> be enforced.
>>
>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
>> ---
>> drivers/devfreq/devfreq.c | 112 ++++++++++++++++++++++----------------
>> 1 file changed, 64 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index 4a878baa809e..eee403e70c84 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -96,10 +96,54 @@ static unsigned long find_available_max_freq(struct devfreq *devfreq)
>> dev_pm_opp_put(opp);
>>
>> return max_freq;
>> }
>>
>> +/**
>> + * get_freq_range() - Get the current freq range
>> + * @devfreq: the devfreq instance
>> + * @min_freq: the min frequency
>> + * @max_freq: the max frequency
>> + *
>> + * This takes into consideration all constraints.
>> + */
>> +static void get_freq_range(struct devfreq *devfreq,
>> + unsigned long *min_freq,
>> + unsigned long *max_freq)
>> +{
>> + unsigned long *freq_table = devfreq->profile->freq_table;
>> +
>> + lockdep_assert_held(&devfreq->lock);
>> +
>> + /*
>> + * Init min/max frequency from freq table.
>
> Init -> Initialize
> min/max -> minimum/maximum
>
>> + * Drivers can initialize this in either ascending or descending order
>
> Drivers -> devfreq drivers
>
>> + * and devfreq core supports both.
>> + */
>
>
> In result, I prefer to change the comments as following:
> /*
> * Initialize the minimum/maximum frequency from freq_table.
> * The devfreq drivers can initialize freq_table in either
> * ascending or descending order and devfreq core supports both.
> */
OK
>> + if (freq_table[0] < freq_table[devfreq->profile->max_state - 1]) {
>> + *min_freq = freq_table[0];
>> + *max_freq = freq_table[devfreq->profile->max_state - 1];
>> + } else {
>> + *min_freq = freq_table[devfreq->profile->max_state - 1];
>> + *max_freq = freq_table[0];
>> + }
>> +
>> + /* constraints from sysfs */
>
> 'constraints' -> Constraint because first verb have to be used
> as the sigular verbs. Also, I think that have to enhance the comments
> I prefer to use following comments:
>
> /* Constraint minimum/maximum frequency from user input via sysfs */
>
>
>
>> + *min_freq = max(*min_freq, devfreq->min_freq);
>> + *max_freq = min(*max_freq, devfreq->max_freq);
>> +
>> + /* constraints from OPP interface */
>
> ditto. I prefer to use following comments:
>
> /* Constraint minimum/maximum frequency from OPP interface */
>
>
>> + *min_freq = max(*min_freq, devfreq->scaling_min_freq);
>> + /* scaling_max_freq can be zero on error */
>
> Please remove it.
>
>> + if (devfreq->scaling_max_freq)
>
> As I knew, devfreq->scaling_max_freq is never zero.
> So, it is always true. This if statement is needed.
It can happen if find_available_max_freq encounters an error when called
from devfreq_notifier_call.
Maybe that should be separately fixed to set scaling_max_freq to a
neutral value such as "ULONG_MAX" instead?
BTW: the devfreq_notifier_call function returns -EINVAL on error but it
should return one of the NOTIFY_OK/DONE/STOP values instead. The OPP
framework ignores notifier results but (-EINVAL & NOTIFY_STOP) evaluates
as true so other notifiers will be skipped unintentionally.
>> + *max_freq = min(*max_freq, devfreq->scaling_max_freq);
>> +
>> + /* max_freq takes precedence over min_freq */
>
> As I said, almost people know that min_freq have be under than max_freq.
> Please remove it. And until finishing the discussion on mailing list,
> please don't send the next version. If you just replied from my comment
> and then wait my next comment, we can save the time without replying
> the repetitive and same comment for same point.
This series makes it possible to set a min_freq higher than max_freq
(for example via PM QoS from various devices).
It is not obvious that min_freq takes precedence over max_freq but the
code is self-evident so I will remove the comment.
>> + if (*min_freq > *max_freq)
>> + *min_freq = *max_freq;
>> +}
>> +
>> /**
>> * devfreq_get_freq_level() - Lookup freq_table for the frequency
>> * @devfreq: the devfreq instance
>> * @freq: the target frequency
>> */
>> @@ -349,20 +393,11 @@ int update_devfreq(struct devfreq *devfreq)
>>
>> /* Reevaluate the proper frequency */
>> err = devfreq->governor->get_target_freq(devfreq, &freq);
>> if (err)
>> return err;
>> -
>> - /*
>> - * Adjust the frequency with user freq, QoS and available freq.
>> - *
>> - * List from the highest priority
>> - * max_freq
>> - * min_freq
>> - */
>> - max_freq = min(devfreq->scaling_max_freq, devfreq->max_freq);
>> - min_freq = max(devfreq->scaling_min_freq, devfreq->min_freq);
>> + get_freq_range(devfreq, &min_freq, &max_freq);
>>
>> if (freq < min_freq) {
>> freq = min_freq;
>> flags &= ~DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use GLB */
>> }
>> @@ -1298,40 +1333,28 @@ static ssize_t min_freq_store(struct device *dev, struct device_attribute *attr,
>> ret = sscanf(buf, "%lu", &value);
>> if (ret != 1)
>> return -EINVAL;
>>
>> mutex_lock(&df->lock);
>> -
>> - if (value) {
>> - if (value > df->max_freq) {
>> - ret = -EINVAL;
>> - goto unlock;
>> - }
>> - } else {
>> - unsigned long *freq_table = df->profile->freq_table;
>> -
>> - /* Get minimum frequency according to sorting order */
>> - if (freq_table[0] < freq_table[df->profile->max_state - 1])
>> - value = freq_table[0];
>> - else
>> - value = freq_table[df->profile->max_state - 1];
>> - }
>> -
>> df->min_freq = value;
>> update_devfreq(df);
>> - ret = count;
>> -unlock:
>> mutex_unlock(&df->lock);
>> - return ret;
>> +
>> + return count;
>> }
>>
>> static ssize_t min_freq_show(struct device *dev, struct device_attribute *attr,
>> char *buf)
>> {
>> struct devfreq *df = to_devfreq(dev);
>> + unsigned long min_freq, max_freq;
>> +
>> + mutex_lock(&df->lock);
>> + get_freq_range(df, &min_freq, &max_freq);
>> + mutex_unlock(&df->lock);
>>
>> - return sprintf(buf, "%lu\n", max(df->scaling_min_freq, df->min_freq));
>> + return sprintf(buf, "%lu\n", min_freq);
>> }
>>
>> static ssize_t max_freq_store(struct device *dev, struct device_attribute *attr,
>> const char *buf, size_t count)
>> {
>> @@ -1343,40 +1366,33 @@ static ssize_t max_freq_store(struct device *dev, struct device_attribute *attr,
>> if (ret != 1)
>> return -EINVAL;
>>
>> mutex_lock(&df->lock);
>>
>> - if (value) {
>> - if (value < df->min_freq) {
>> - ret = -EINVAL;
>> - goto unlock;
>> - }
>> - } else {
>> - unsigned long *freq_table = df->profile->freq_table;
>> -
>> - /* Get maximum frequency according to sorting order */
>> - if (freq_table[0] < freq_table[df->profile->max_state - 1])
>> - value = freq_table[df->profile->max_state - 1];
>> - else
>> - value = freq_table[0];
>> - }
>> + /* Interpret zero as "don't care" */
>
> Please remove it. Also, the detailed comment for user have to add
> the documentation file.
OK
>
>> + if (!value)
>> + value = ULONG_MAX;
>>
>> df->max_freq = value;
>> update_devfreq(df);
>> - ret = count;
>> -unlock:
>> mutex_unlock(&df->lock);
>> - return ret;
>> +
>> + return count;
>> }
>> static DEVICE_ATTR_RW(min_freq);
>>
>> static ssize_t max_freq_show(struct device *dev, struct device_attribute *attr,
>> char *buf)
>> {
>> struct devfreq *df = to_devfreq(dev);
>> + unsigned long min_freq, max_freq;
>> +
>> + mutex_lock(&df->lock);
>> + get_freq_range(df, &min_freq, &max_freq);
>> + mutex_unlock(&df->lock);
>>
>> - return sprintf(buf, "%lu\n", min(df->scaling_max_freq, df->max_freq));
>> + return sprintf(buf, "%lu\n", max_freq);
>> }
>> static DEVICE_ATTR_RW(max_freq);
>>
>> static ssize_t available_frequencies_show(struct device *d,
>> struct device_attribute *attr,
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] i2c: i2c-mt65xx: fix NULL ptr dereference
From: Fabien Parent @ 2019-09-25 20:31 UTC (permalink / raw)
To: linux-i2c, linux-arm-kernel, linux-mediatek, linux-kernel
Cc: drinkcat, wsa, Fabien Parent, hsinyi, matthias.bgg, tglx,
qii.wang
Since commit abf4923e97c3 ("i2c: mediatek: disable zero-length transfers
for mt8183"), there is a NULL pointer dereference for all the SoCs
that don't have any quirk. mtk_i2c_functionality is not checking that
the quirks pointer is not NULL before starting to use it.
This commit add a check on the quirk pointer before dereferencing it.
Fixes: abf4923e97c3 ("i2c: mediatek: disable zero-length transfers for mt8183")
Signed-off-by: Fabien Parent <fparent@baylibre.com>
---
drivers/i2c/busses/i2c-mt65xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 29eae1bf4f86..ec00fc6af9ae 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -875,7 +875,7 @@ static irqreturn_t mtk_i2c_irq(int irqno, void *dev_id)
static u32 mtk_i2c_functionality(struct i2c_adapter *adap)
{
- if (adap->quirks->flags & I2C_AQ_NO_ZERO_LEN)
+ if (adap->quirks && adap->quirks->flags & I2C_AQ_NO_ZERO_LEN)
return I2C_FUNC_I2C |
(I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
else
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] dmaengine: uniphier-mdmac: use devm_platform_ioremap_resource()
From: Vinod Koul @ 2019-09-25 20:21 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: dmaengine, Dan Williams, linux-kernel, linux-arm-kernel
In-Reply-To: <20190905034133.29514-1-yamada.masahiro@socionext.com>
On 05-09-19, 12:41, Masahiro Yamada wrote:
> Replace the chain of platform_get_resource() and devm_ioremap_resource()
> with devm_platform_ioremap_resource().
>
> This allows to remove the local variable for (struct resource *), and
> have one function call less.
Applied, thanks
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 1/2] kselftest: add capability to skip chosen TARGETS
From: Tim.Bird @ 2019-09-25 20:20 UTC (permalink / raw)
To: cristian.marussi, linux-kselftest, linux-arm-kernel, shuah; +Cc: dave.martin
In-Reply-To: <20190925132421.23572-1-cristian.marussi@arm.com>
Just a few nits inline below.
> -----Original Message-----
> From: Cristian Marussi on Wednesday, September 25, 2019 3:24 AM
>
> Let the user specify an optional TARGETS skiplist through the new optional
> SKIP_TARGETS Makefile variable.
>
> It is easier to skip at will a reduced and well defined list of possibly
It seems like there's a word missing.
at will a -> at will using a
> problematic targets with SKIP_TARGETS then to provide a partially stripped
then -> than
> down list of good targets using the usual TARGETS variable.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> tools/testing/selftests/Makefile | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/testing/selftests/Makefile
> b/tools/testing/selftests/Makefile
> index 25b43a8c2b15..103936faa46d 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -132,6 +132,10 @@ else
> ARCH=$(ARCH) -C $(top_srcdir) headers_install
> endif
>
> +# User can optionally provide a TARGETS skiplist.
> +SKIP_TARGETS ?=
> +TARGETS := $(filter-out $(SKIP_TARGETS), $(TARGETS))
> +
> all: khdr
> @for TARGET in $(TARGETS); do \
> BUILD_TARGET=$$BUILD/$$TARGET; \
> --
> 2.17.1
Great feature! Thanks.
-- Tim
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: OMAP2+: Fix warnings with broken omap2_set_init_voltage()
From: Adam Ford @ 2019-09-25 19:51 UTC (permalink / raw)
To: Tony Lindgren
Cc: Nishanth Menon, H. Nikolaus Schaller, Tero Kristo,
André Roth, Linux-OMAP, arm-soc
In-Reply-To: <20190924233222.52757-1-tony@atomide.com>
On Tue, Sep 24, 2019 at 6:32 PM Tony Lindgren <tony@atomide.com> wrote:
>
> This code is currently unable to find the dts opp tables as ti-cpufreq
> needs to set them up first based on speed binning.
>
> We stopped initializing the opp tables with platform code years ago for
> device tree based booting with commit 92d51856d740 ("ARM: OMAP3+: do not
> register non-dt OPP tables for device tree boot"), and all of mach-omap2
> is now booting using device tree.
>
> We currently get the following errors on init:
>
> omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu
> omap2_set_init_voltage: unable to set vdd_mpu
> omap2_set_init_voltage: unable to find boot up OPP for vdd_core
> omap2_set_init_voltage: unable to set vdd_core
> omap2_set_init_voltage: unable to find boot up OPP for vdd_iva
> omap2_set_init_voltage: unable to set vdd_iva
>
> Let's just drop the unused code. Nowadays ti-cpufreq should be used to
> to initialize things properly.
AFAICT, the ti-cpufreq changes haven't been applied yet to support
omap3 boards, but the regular cpufreq does, and it seems OK.
>
> Cc: Adam Ford <aford173@gmail.com>
> Cc: André Roth <neolynx@gmail.com>
> Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
> Cc: Nishanth Menon <nm@ti.com>
> Cc: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>
> Guys, please check and ack if we can really do this to get rid of some
> pointless dmesg -l3 errors without affecting the ongoing cpufreq and
> voltage work.
>
Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
> ---
> arch/arm/mach-omap2/pm.c | 100 ---------------------------------------
> 1 file changed, 100 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -74,83 +74,6 @@ int omap_pm_clkdms_setup(struct clockdomain *clkdm, void *unused)
> return 0;
> }
>
> -/*
> - * This API is to be called during init to set the various voltage
> - * domains to the voltage as per the opp table. Typically we boot up
> - * at the nominal voltage. So this function finds out the rate of
> - * the clock associated with the voltage domain, finds out the correct
> - * opp entry and sets the voltage domain to the voltage specified
> - * in the opp entry
> - */
> -static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
> - const char *oh_name)
> -{
> - struct voltagedomain *voltdm;
> - struct clk *clk;
> - struct dev_pm_opp *opp;
> - unsigned long freq, bootup_volt;
> - struct device *dev;
> -
> - if (!vdd_name || !clk_name || !oh_name) {
> - pr_err("%s: invalid parameters\n", __func__);
> - goto exit;
> - }
> -
> - if (!strncmp(oh_name, "mpu", 3))
> - /*
> - * All current OMAPs share voltage rail and clock
> - * source, so CPU0 is used to represent the MPU-SS.
> - */
> - dev = get_cpu_device(0);
> - else
> - dev = omap_device_get_by_hwmod_name(oh_name);
> -
> - if (IS_ERR(dev)) {
> - pr_err("%s: Unable to get dev pointer for hwmod %s\n",
> - __func__, oh_name);
> - goto exit;
> - }
> -
> - voltdm = voltdm_lookup(vdd_name);
> - if (!voltdm) {
> - pr_err("%s: unable to get vdd pointer for vdd_%s\n",
> - __func__, vdd_name);
> - goto exit;
> - }
> -
> - clk = clk_get(NULL, clk_name);
> - if (IS_ERR(clk)) {
> - pr_err("%s: unable to get clk %s\n", __func__, clk_name);
> - goto exit;
> - }
> -
> - freq = clk_get_rate(clk);
> - clk_put(clk);
> -
> - opp = dev_pm_opp_find_freq_ceil(dev, &freq);
> - if (IS_ERR(opp)) {
> - pr_err("%s: unable to find boot up OPP for vdd_%s\n",
> - __func__, vdd_name);
> - goto exit;
> - }
> -
> - bootup_volt = dev_pm_opp_get_voltage(opp);
> - dev_pm_opp_put(opp);
> -
> - if (!bootup_volt) {
> - pr_err("%s: unable to find voltage corresponding to the bootup OPP for vdd_%s\n",
> - __func__, vdd_name);
> - goto exit;
> - }
> -
> - voltdm_scale(voltdm, bootup_volt);
> - return 0;
> -
> -exit:
> - pr_err("%s: unable to set vdd_%s\n", __func__, vdd_name);
> - return -EINVAL;
> -}
> -
> #ifdef CONFIG_SUSPEND
> static int omap_pm_enter(suspend_state_t suspend_state)
> {
> @@ -208,25 +131,6 @@ void omap_common_suspend_init(void *pm_suspend)
> }
> #endif /* CONFIG_SUSPEND */
>
> -static void __init omap3_init_voltages(void)
> -{
> - if (!soc_is_omap34xx())
> - return;
> -
> - omap2_set_init_voltage("mpu_iva", "dpll1_ck", "mpu");
> - omap2_set_init_voltage("core", "l3_ick", "l3_main");
> -}
> -
> -static void __init omap4_init_voltages(void)
> -{
> - if (!soc_is_omap44xx())
> - return;
> -
> - omap2_set_init_voltage("mpu", "dpll_mpu_ck", "mpu");
> - omap2_set_init_voltage("core", "l3_div_ck", "l3_main_1");
> - omap2_set_init_voltage("iva", "dpll_iva_m5x2_ck", "iva");
> -}
> -
> int __maybe_unused omap_pm_nop_init(void)
> {
> return 0;
> @@ -246,10 +150,6 @@ int __init omap2_common_pm_late_init(void)
> omap4_twl_init();
> omap_voltage_late_init();
>
> - /* Initialize the voltages */
> - omap3_init_voltages();
> - omap4_init_voltages();
> -
> /* Smartreflex device init */
> omap_devinit_smartreflex();
>
> --
> 2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 5/6] PM / devfreq: Add PM QoS support
From: Leonard Crestez @ 2019-09-25 19:40 UTC (permalink / raw)
To: Chanwoo Choi, Matthias Kaehlcke
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan,
linux-pm@vger.kernel.org, Viresh Kumar, dl-linux-imx,
Krzysztof Kozlowski, Lukasz Luba, Kyungmin Park, MyungJoo Ham,
Alexandre Bailon, Georgi Djakov,
linux-arm-kernel@lists.infradead.org, Jacky Bai
In-Reply-To: <080027a2-d807-5fa4-f148-4469678ce849@samsung.com>
On 25.09.2019 05:13, Chanwoo Choi wrote:
> On 19. 9. 25. 오전 4:22, Leonard Crestez wrote:
>> On 24.09.2019 22:11, Matthias Kaehlcke wrote:
>>> On Tue, Sep 24, 2019 at 01:11:29PM +0300, Leonard Crestez wrote:
>>>> Register notifiers with the PM QoS framework in order to respond to
>>>> requests for DEV_PM_QOS_MIN_FREQUENCY and DEV_PM_QOS_MAX_FREQUENCY.
>>>>
>>>> No notifiers are added by this patch but PM QoS constraints can be
>>>> imposed externally (for example from other devices).
>>>>
>>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
>>>> ---
>>>> drivers/devfreq/devfreq.c | 75 +++++++++++++++++++++++++++++++++++++++
>>>> include/linux/devfreq.h | 5 +++
>>>> 2 files changed, 80 insertions(+)
>>>>
>>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>>> index eee403e70c84..784f3e40536a 100644
>>>> --- a/drivers/devfreq/devfreq.c
>>>> +++ b/drivers/devfreq/devfreq.c
>>>> @@ -22,15 +22,18 @@
>>>> #include <linux/platform_device.h>
>>>> #include <linux/list.h>
>>>> #include <linux/printk.h>
>>>> #include <linux/hrtimer.h>
>>>> #include <linux/of.h>
>>>> +#include <linux/pm_qos.h>
>>>> #include "governor.h"
>>>>
>>>> #define CREATE_TRACE_POINTS
>>>> #include <trace/events/devfreq.h>
>>>>
>>>> +#define HZ_PER_KHZ 1000
>>>> +
>>>> static struct class *devfreq_class;
>>>>
>>>> /*
>>>> * devfreq core provides delayed work based load monitoring helper
>>>> * functions. Governors can use these or can implement their own
>>>> @@ -109,10 +112,11 @@ static unsigned long find_available_max_freq(struct devfreq *devfreq)
>>>> static void get_freq_range(struct devfreq *devfreq,
>>>> unsigned long *min_freq,
>>>> unsigned long *max_freq)
>>>> {
>>>> unsigned long *freq_table = devfreq->profile->freq_table;
>>>> + unsigned long qos_min_freq, qos_max_freq;
>>>>
>>>> lockdep_assert_held(&devfreq->lock);
>>>>
>>>> /*
>>>> * Init min/max frequency from freq table.
>>>> @@ -125,10 +129,18 @@ static void get_freq_range(struct devfreq *devfreq,
>>>> } else {
>>>> *min_freq = freq_table[devfreq->profile->max_state - 1];
>>>> *max_freq = freq_table[0];
>>>> }
>>>>
>>>> + /* constraints from PM QoS */
>>>> + qos_min_freq = dev_pm_qos_read_value(devfreq->dev.parent,
>>>> + DEV_PM_QOS_MIN_FREQUENCY);
>>>> + qos_max_freq = dev_pm_qos_read_value(devfreq->dev.parent,
>>>> + DEV_PM_QOS_MIN_FREQUENCY); >
>>> This needs to be DEV_PM_QOS_MAX_FREQUENCY. I missed this in the earlier
>>> reviews, but stumbled across it when testing.
>>>
>>> !Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
>>
>> I broke it in v8 while processing comments. Thanks for catching it.
>
> Did you test this patchset with v8?
> Maybe it is not working with this mistake.
I ran some scripts which test that min_freq requests work as expected
(using imx interconnect+devfreq). They don't touch max_freq.
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/6] PM / devfreq: Add dev_pm_qos support
From: Leonard Crestez @ 2019-09-25 19:37 UTC (permalink / raw)
To: Chanwoo Choi, MyungJoo Ham, Kyungmin Park, Matthias Kaehlcke
Cc: Artur Świgoń, Abel Vesa, Saravana Kannan,
linux-pm@vger.kernel.org, Viresh Kumar, dl-linux-imx,
Krzysztof Kozlowski, Lukasz Luba, Alexandre Bailon, Georgi Djakov,
linux-arm-kernel@lists.infradead.org, Jacky Bai
In-Reply-To: <b0cb5290-7b85-b803-2264-89d7d572fd1c@samsung.com>
On 25.09.2019 04:40, Chanwoo Choi wrote:
> Hi Leonard,
>
> Basically, I think that these series are very important.
>
> But, you better to send the next version patch
> after finishing the review/discussion on previous version.
>
> I reviewed the v7 and then you replied your comment.
> It is OK. But, you just send v8 without waiting my comment
> from your reply. It is not efficient discussion method.
>
> If we finish the review of some point in the v7,
> it doesn't need to discuss the same comment on v8.
>
> Please wait the reply for review. I think that
> it can save the our time for the review and contribution.
Sorry.
I already incorporated a large number of the changes in v7 so I thought
I'd post the new version already.
> On 19. 9. 24. 오후 7:11, Leonard Crestez wrote:
>> Add dev_pm_qos notifiers to devfreq core in order to support frequency
>> limits via dev_pm_qos_add_request.
>>
>> Unlike the rest of devfreq the dev_pm_qos frequency is measured in Khz,
>> this is consistent with current dev_pm_qos usage for cpufreq and
>> allows frequencies above 2Ghz (pm_qos expresses limits as s32).
>>
>> Like with cpufreq the handling of min_freq/max_freq is moved to the
>> dev_pm_qos mechanism. Constraints from userspace are no longer clamped on
>> store, instead all values can be written and we only check against OPPs in a
>> new devfreq_get_freq_range function. This is consistent with the design of
>> dev_pm_qos.
>>
>> Notifiers from pm_qos are executed under a single global dev_pm_qos_mtx and
>> need to take devfreq->lock. Notifier registration takes the same dev_pm_qos_mtx
>> so in order to prevent lockdep warnings it must be done outside devfreq->lock.
>> Current devfreq_add_device does all initialization under devfreq->lock and that
>> needs to be relaxed.
>>
>> ---
>> Changes since v7:
>> * Only #define HZ_PER_KHZ in patch where it's used.
>> * Drop devfreq_ prefix for some internal functions.
>> * Improve qos update error message.
>> * Remove some unnecessary comments.
>> * Collect reviews
>> Link to v7: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11157649%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb4e87dc885c64c7fe83d08d741594dcb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637049724139242058&sdata=mbxGHSFiLylBMcuoA4ABoyClJq0ELiZtr9QytMnPT7w%3D&reserved=0
>>
>> Changes since v6:
>> * Don't return errno from devfreq_qos_notifier_call, return NOTIFY_DONE
>> and print the error.
>> * More spelling and punctuation nits
>> Link to v6: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11157201%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb4e87dc885c64c7fe83d08d741594dcb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637049724139242058&sdata=ry1hAJ8Gb5zmefVDRMOup5E2agQ8lrha4MxU66kN27U%3D&reserved=0
>>
>> Changes since v5:
>> * Drop patches which are not strictly related to PM QoS.
>> * Add a comment explaining why devfreq_add_device needs two cleanup paths.
>> * Remove {} for single line.
>> * Rename {min,max}_freq_req to user_{min,max}_freq_req
>> * Collect reviews
>> Link to v5: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11149497%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb4e87dc885c64c7fe83d08d741594dcb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637049724139242058&sdata=ShneYomxXC1gUt5hU4agsZH%2FLfsHvxO%2FiaCNDGKsv94%3D&reserved=0
>>
>> Sorry for forgetting to properly label v5. I know this is inside the
>> merge window but review would still be appreciated.
>>
>> Changes since v4:
>> * Move more devfreq_add_device init ahead of device_register.
>> * Make devfreq_dev_release cleanup devices not yet in devfreq_list. This is
>> simpler than previous attempt to add to devfreq_list sonner.
>> * Take devfreq->lock in trans_stat_show
>> * Register dev_pm_opp notifier on devfreq parent dev (which has OPPs)
>> Link to v4: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11114657%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb4e87dc885c64c7fe83d08d741594dcb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637049724139242058&sdata=n3f%2Fd86jzWTG005SPrikbUOg%2FaGpf7LMZRoVrwybqSk%3D&reserved=0
>>
>> Changes since v4:
>> * Move more devfreq_add_device init ahead of device_register.
>> * Make devfreq_dev_release cleanup devices not yet in devfreq_list. This is
>> simpler than previous attempt to add to devfreq_list sonner.
>> * Take devfreq->lock in trans_stat_show
>> * Register dev_pm_opp notifier on devfreq parent dev (which has OPPs)
>> Like to v4: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11114657%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb4e87dc885c64c7fe83d08d741594dcb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637049724139242058&sdata=n3f%2Fd86jzWTG005SPrikbUOg%2FaGpf7LMZRoVrwybqSk%3D&reserved=0
>>
>> Changes since v3:
>> * Cleanup locking and error-handling in devfreq_add_device
>> * Register notifiers after device registration but before governor start
>> * Keep the initialization of min_req/max_req ahead of device_register
>> because it's used for sysfs handling
>> * Use HZ_PER_KHZ instead of 1000
>> * Add kernel-doc comments
>> * Move OPP notifier to core
>> Link to v3: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fcover%2F11104061%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb4e87dc885c64c7fe83d08d741594dcb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637049724139242058&sdata=XXzabOjV26KBso7j7BC%2BGTdIiKxiFUNmf3P5q1vXgbs%3D&reserved=0
>>
>> Changes since v2:
>> * Handle sysfs via dev_pm_qos (in separate patch)
>> * Add locking to {min,max}_freq_show
>> * Fix checkpatch issues (long lines etc)
>> Link to v2: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fpatch%2F11084279%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb4e87dc885c64c7fe83d08d741594dcb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637049724139242058&sdata=3CB%2FD82NoBKd%2FAREWaI%2FTl9uIPLXxz6e%2Fhzd3msRGcw%3D&reserved=0
>>
>> Changes since v1:
>> * Add doxygen comments for min_nb/max_nb
>> * Remove notifiers on error/cleanup paths. Keep gotos simple by relying on
>> dev_pm_qos_remove_notifier ignoring notifiers which were not added.
>> Link to v1: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.kernel.org%2Fpatch%2F11078475%2F&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cb4e87dc885c64c7fe83d08d741594dcb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637049724139242058&sdata=tqOV6t0KUvFtUWxHrzAwVozZ4sKrylmuvdtiFSW3FV4%3D&reserved=0
>>
>> Leonard Crestez (6):
>> PM / devfreq: Don't fail devfreq_dev_release if not in list
>> PM / devfreq: Move more initialization before registration
>> PM / devfreq: Don't take lock in devfreq_add_device
>> PM / devfreq: Introduce get_freq_range helper
>> PM / devfreq: Add PM QoS support
>> PM / devfreq: Use PM QoS for sysfs min/max_freq
>>
>> drivers/devfreq/devfreq.c | 268 +++++++++++++++++++++++++-------------
>> include/linux/devfreq.h | 14 +-
>> 2 files changed, 191 insertions(+), 91 deletions(-)
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] kselftest: exclude failed TARGETS from runlist
From: shuah @ 2019-09-25 19:36 UTC (permalink / raw)
To: Cristian Marussi, linux-kselftest, linux-arm-kernel; +Cc: shuah, dave.martin
In-Reply-To: <20190925132421.23572-2-cristian.marussi@arm.com>
On 9/25/19 7:24 AM, Cristian Marussi wrote:
> A TARGET which failed to be built/installed should not be included in the
> runlist generated inside the run_kselftest.sh script.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> As an example, here BPF failed to compile but was included in the runlist
> and attempted to run anyway:
>
> ...
> ./KSFT_LAST_2/run_kselftest.sh: 37: cd: can't cd to bpf
> TAP version 13
> 1..49
> \# selftests: KSFT_LAST_2: test_verifier
> \# Warning: file test_verifier is missing!
> not ok 1 selftests: KSFT_LAST_2: test_verifier
> \# selftests: KSFT_LAST_2: test_tag
> \# Warning: file test_tag is missing!
> ---
> tools/testing/selftests/Makefile | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
> index 103936faa46d..e11ace11b07c 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -202,8 +202,12 @@ ifdef INSTALL_PATH
> echo " cat /dev/null > \$$logfile" >> $(ALL_SCRIPT)
> echo "fi" >> $(ALL_SCRIPT)
>
> + @# While building run_kselftest.sh skip also non-existent TARGET dirs:
> + @# they could be the result of a build failure and should NOT be
> + @# included in the generated runlist.
> for TARGET in $(TARGETS); do \
> BUILD_TARGET=$$BUILD/$$TARGET; \
> + [ ! -d $$INSTALL_PATH/$$TARGET ] && echo "Skipping non-existent dir: $$TARGET" && continue; \
> echo "[ -w /dev/kmsg ] && echo \"kselftest: Running tests in $$TARGET\" >> /dev/kmsg" >> $(ALL_SCRIPT); \
> echo "cd $$TARGET" >> $(ALL_SCRIPT); \
> echo -n "run_many" >> $(ALL_SCRIPT); \
>
This is great. Thanks for the patch.
-- Shuah
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PM / devfreq: Lock devfreq in trans_stat_show
From: Leonard Crestez @ 2019-09-25 19:36 UTC (permalink / raw)
To: Chanwoo Choi, Matthias Kaehlcke, MyungJoo Ham
Cc: Artur Świgoń, linux-pm@vger.kernel.org,
Krzysztof Kozlowski, Lukasz Luba, Kyungmin Park, dl-linux-imx,
Georgi Djakov, linux-arm-kernel@lists.infradead.org
In-Reply-To: <98042a95-40cc-7f05-ede7-d042640b135b@samsung.com>
On 25.09.2019 04:17, Chanwoo Choi wrote:
> On 19. 9. 24. 오후 4:44, Leonard Crestez wrote:
>> On 2019-09-24 5:07 AM, Chanwoo Choi wrote:
>>> Hi,
>>>
>>> On 19. 9. 24. 오전 1:27, Leonard Crestez wrote:
>>>> There is no locking in this sysfs show function so stats printing can
>>>> race with a devfreq_update_status called as part of freq switching or
>>>> with initialization.
>>>>
>>>> Also add an assert in devfreq_update_status to make it clear that lock
>>>> must be held by caller.
>>>>
>>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>>> ---
>>>> drivers/devfreq/devfreq.c | 13 ++++++++++---
>>>> 1 file changed, 10 insertions(+), 3 deletions(-)
>>>>
>>>> Changes since v1:
>>>> * Split from series: low-priority bugfix not strictly required for PM QoS
>>>> * Only keep lock during update, release before sprintf
>>>>
>>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>>> index 4c58fbf7d4e4..00fc23fea5b2 100644
>>>> --- a/drivers/devfreq/devfreq.c
>>>> +++ b/drivers/devfreq/devfreq.c
>>>> @@ -206,10 +206,11 @@ int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
>>>> {
>>>> int lev, prev_lev, ret = 0;
>>>> unsigned long cur_time;
>>>>
>>>> cur_time = jiffies;
>>>> + lockdep_assert_held(&devfreq->lock);
>>>
>>> It better to move lock checking before 'cur_time = jiffies'
>>> in order to reduce the redundant code execution.
>>
>> OK but I don't see how this makes a difference for an assert? It just
>> prints a warning and carries on.
>
> According to the sequence between 'lockdep_assert_held' and 'cur_time = jiffies',
> cur_time will be initialized with different jiffies because 'jiffies' is continuously
> changed. In order to get the more correct time from 'jiffies',
> we better to get 'jiffies' after releasing the lock.
That makes sense.
>>>> /* Immediately exit if previous_freq is not initialized yet. */
>>>> if (!devfreq->previous_freq)
>>>> goto out;
>>>>
>>>> @@ -1507,16 +1508,22 @@ static ssize_t trans_stat_show(struct device *dev,
>>>> struct devfreq *devfreq = to_devfreq(dev);
>>>> ssize_t len;
>>>> int i, j;
>>>> unsigned int max_state = devfreq->profile->max_state;
>>>>
>>>> - if (!devfreq->stop_polling &&
>>>> - devfreq_update_status(devfreq, devfreq->previous_freq))
>>>> - return 0;
>>>> if (max_state == 0)
>>>> return sprintf(buf, "Not Supported.\n");
>>>>
>>>> + /* lock and update */
>>>
>>> It is not necessary. Anyone can know that this code is related to mutex lock/unlock.
>>
>> OK. You're the second person to mention this but it's quite strange to
>> see objections raised against comments.
>
> The comment is very important to understand the code
> for everyone. But, in this case, almost people understand
> the usage of mutex_lock/mutex_unlock. It is no difficult
> to understand the meaning of below codes.
>
> Usually, we would add the comments if some codes are very difficult
> without comments or some codes have depend on some call sequence and so on.
OK. Sometimes I add brief comments ahead of a paragraph of code so that
I can read it faster.
>>>> + mutex_lock(&devfreq->lock);
>>>> + if (!devfreq->stop_polling &&
>>>> + devfreq_update_status(devfreq, devfreq->previous_freq)) {
>>>> + mutex_unlock(&devfreq->lock);
>>>> + return 0;
>>>> + }
>>>> + mutex_unlock(&devfreq->lock);
>>>> +
>>>> len = sprintf(buf, " From : To\n");
>>>> len += sprintf(buf + len, " :");
>>>> for (i = 0; i < max_state; i++)
>>>> len += sprintf(buf + len, "%10lu",
>>>> devfreq->profile->freq_table[i]);
>>>>
>>>
>>> Basically, it is necessary. Please edit it by my comments.
>>> Also, you have to add the following 'fixes' as following:
>>> and send it stable mailing list.
>>>
>>> Fixes: 39688ce6facd ("PM / devfreq: account suspend/resume for stats")
>>>
>>> If you edit it by my comments, feel free to add my tag:
>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Already posted v2 with all the requested changes:
https://patchwork.kernel.org/patch/11158225/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] kselftest: add capability to skip chosen TARGETS
From: shuah @ 2019-09-25 19:36 UTC (permalink / raw)
To: Cristian Marussi, linux-kselftest, linux-arm-kernel; +Cc: shuah, dave.martin
In-Reply-To: <20190925132421.23572-1-cristian.marussi@arm.com>
On 9/25/19 7:24 AM, Cristian Marussi wrote:
> Let the user specify an optional TARGETS skiplist through the new optional
> SKIP_TARGETS Makefile variable.
>
> It is easier to skip at will a reduced and well defined list of possibly
> problematic targets with SKIP_TARGETS then to provide a partially stripped
> down list of good targets using the usual TARGETS variable.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> tools/testing/selftests/Makefile | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
> index 25b43a8c2b15..103936faa46d 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -132,6 +132,10 @@ else
> ARCH=$(ARCH) -C $(top_srcdir) headers_install
> endif
>
> +# User can optionally provide a TARGETS skiplist.
> +SKIP_TARGETS ?=
> +TARGETS := $(filter-out $(SKIP_TARGETS), $(TARGETS))
> +
> all: khdr
> @for TARGET in $(TARGETS); do \
> BUILD_TARGET=$$BUILD/$$TARGET; \
>
Thanks for doing this. This looks good to me. Would you like to
update the documentation file?
thanks,
-- Shuah
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 2/6] PM / devfreq: Move more initialization before registration
From: Leonard Crestez @ 2019-09-25 19:33 UTC (permalink / raw)
To: myungjoo.ham@samsung.com, Kyungmin Park, Matthias Kaehlcke
Cc: Abel Vesa, Saravana Kannan, linux-pm@vger.kernel.org,
Viresh Kumar, Artur Swigon, Krzysztof Kozlowski, Lukasz Luba,
Chanwoo Choi, Alexandre Bailon, dl-linux-imx, Georgi Djakov,
linux-arm-kernel@lists.infradead.org, Jacky Bai
In-Reply-To: <20190925015845epcms1p4f788aa587e53bfa38b9b847838b02342@epcms1p4>
On 25.09.2019 04:59, MyungJoo Ham wrote:
>> In general it is a better to initialize an object before making it
>> accessible externally (through device_register).
>>
>> This makes it possible to avoid relying on locking a partially
>> initialized object.
>>
>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
>
> Do you object to the general idea of devm_* for device drivers?
> or did you find a bug in the memory handling in the code?
>
> The result of this commit still relies on locking anyway.
This is a dependency of the following patch which removes the locking. I
will add this to the commit message because everybody asks.
This patch removes devm because devm itself is only available after
device_initialize. Moving the allocation ahead of device_register (which
calls device_initialize) requires switching to manual memory management.
Since there are only two pointers it seemed reasonable.
Alternatively device_register could be split into explicit
"device_initialize" and "device_add" steps and devm could be used
between those steps.
Before:
- device_register
- devm-based-alloc
After:
+ device_initialize
+ devm-based-alloc
+ device_add
Does this make sense?
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [v2, 2/2] gpio: dts: aspeed: Add SGPIO driver
From: Hongwei Zhang @ 2019-09-25 19:22 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, linux-gpio, Joel Stanley
Cc: Mark Rutland, devicetree, Arnd Bergmann, linux-aspeed,
Ard Biesheuvel, Masahiro Yamada, linux-kernel, Russell King,
Mike Rapoport, Bartosz Golaszewski, Rob Herring,
Benjamin Gaignard, Mauro Carvalho Chehab, Doug Anderson,
Andrew Morton, Hongwei Zhang, linux-arm-kernel
In-Reply-To: <1569439337-10482-1-git-send-email-hongweiz@ami.com>
Add SGPIO driver support for Aspeed AST2500 SoC.
Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
---
drivers/gpio/Kconfig | 8 ++++++++
drivers/gpio/Makefile | 1 +
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index bb13c26..e94f903 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -120,6 +120,14 @@ config GPIO_ASPEED
help
Say Y here to support Aspeed AST2400 and AST2500 GPIO controllers.
+config SGPIO_ASPEED
+ bool "Aspeed SGPIO support"
+ depends on (ARCH_ASPEED || COMPILE_TEST) && OF_GPIO
+ select GPIO_GENERIC
+ select GPIOLIB_IRQCHIP
+ help
+ Say Y here to support Aspeed AST2500 SGPIO functionality.
+
config GPIO_ATH79
tristate "Atheros AR71XX/AR724X/AR913X GPIO support"
default y if ATH79
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index a4e9117..bebbd82 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_GPIO_AMD_FCH) += gpio-amd-fch.o
obj-$(CONFIG_GPIO_AMDPT) += gpio-amdpt.o
obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
obj-$(CONFIG_GPIO_ASPEED) += gpio-aspeed.o
+obj-$(CONFIG_SGPIO_ASPEED) += sgpio-aspeed.o
obj-$(CONFIG_GPIO_ATH79) += gpio-ath79.o
obj-$(CONFIG_GPIO_BCM_KONA) += gpio-bcm-kona.o
obj-$(CONFIG_GPIO_BD70528) += gpio-bd70528.o
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [v2, 1/2] gpio: dts: aspeed: Add SGPIO driver
From: Hongwei Zhang @ 2019-09-25 19:22 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, linux-gpio, Joel Stanley
Cc: Mark Rutland, devicetree, Arnd Bergmann, linux-aspeed,
Ard Biesheuvel, Masahiro Yamada, linux-kernel, Russell King,
Mike Rapoport, Bartosz Golaszewski, Rob Herring,
Benjamin Gaignard, Mauro Carvalho Chehab, Doug Anderson,
Andrew Morton, Hongwei Zhang, linux-arm-kernel
In-Reply-To: <1569439337-10482-1-git-send-email-hongweiz@ami.com>
Add SGPIO driver support for Aspeed AST2500 SoC.
Signed-off-by: Hongwei Zhang <hongweiz@ami.com>
---
arch/arm/Kconfig | 2 ++
arch/arm/boot/dts/aspeed-g5.dtsi | 16 +++++++++++++++-
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2436021..c9f08ab 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1460,6 +1460,8 @@ config ARCH_NR_GPIO
default 416 if ARCH_SUNXI
default 392 if ARCH_U8500
default 352 if ARCH_VT8500
+ default 312 if MACH_ASPEED_G5
+ default 304 if MACH_ASPEED_G4
default 288 if ARCH_ROCKCHIP
default 264 if MACH_H4700
default 0
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 00f05bd..85da7ea 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -311,7 +311,7 @@
#gpio-cells = <2>;
gpio-controller;
compatible = "aspeed,ast2500-gpio";
- reg = <0x1e780000 0x1000>;
+ reg = <0x1e780000 0x200>;
interrupts = <20>;
gpio-ranges = <&pinctrl 0 0 232>;
clocks = <&syscon ASPEED_CLK_APB>;
@@ -319,6 +319,20 @@
#interrupt-cells = <2>;
};
+ sgpio: sgpio@1e780200 {
+ #gpio-cells = <2>;
+ compatible = "aspeed,ast2500-sgpio";
+ gpio-controller;
+ interrupts = <40>;
+ reg = <0x1e780200 0x0100>;
+ clocks = <&syscon ASPEED_CLK_APB>;
+ interrupt-controller;
+ ngpios = <8>;
+ bus-frequency = <12000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sgpm_default>;
+ };
+
rtc: rtc@1e781000 {
compatible = "aspeed,ast2500-rtc";
reg = <0x1e781000 0x18>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [v2, 0/2] gpio: dts: aspeed: Add SGPIO driver
From: Hongwei Zhang @ 2019-09-25 19:22 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, linux-gpio, Joel Stanley
Cc: Mark Rutland, devicetree, Arnd Bergmann, linux-aspeed,
Ard Biesheuvel, Masahiro Yamada, linux-kernel, Russell King,
Mike Rapoport, Bartosz Golaszewski, Rob Herring,
Benjamin Gaignard, Mauro Carvalho Chehab, Doug Anderson,
Andrew Morton, Hongwei Zhang, linux-arm-kernel
Hello,
This short series introduce the Kconfig, Makefile, and dts for the
Aspeed AST2500 SGPIO controller. This is the last patch set.
Please review.
[v2]: changes between v1 and v2:
- split the patches based on review feedback.
[v1]: Initial commit
The related SGPIO driver has been accepted and merged into v5.4:
_http://patchwork.ozlabs.org/patch/1150357/
The related SGPM pinmux dt-binding document, dts, and pinctrl driver
updates have been accepted and merged:
_http://patchwork.ozlabs.org/patch/1110210/
Thanks!
Hongwei Zhang (1):
gpio: dts: aspeed: Add SGPIO driver
arch/arm/Kconfig | 2 ++
arch/arm/boot/dts/aspeed-g5.dtsi | 16 +++++++++++++++-
drivers/gpio/Kconfig | 8 ++++++++
drivers/gpio/Makefile | 1 +
4 files changed, 26 insertions(+), 1 deletion(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [v1, 0/1] gpio: dts: aspeed: Add SGPIO driver
From: Hongwei Zhang @ 2019-09-25 19:20 UTC (permalink / raw)
To: Linus Walleij, Andrew Jeffery, linux-gpio, Joel Stanley
Cc: Mark Rutland, devicetree, Arnd Bergmann, linux-aspeed,
Ard Biesheuvel, Masahiro Yamada, linux-kernel, Russell King,
Mike Rapoport, Bartosz Golaszewski, Rob Herring,
Benjamin Gaignard, Mauro Carvalho Chehab, Doug Anderson,
Andrew Morton, Hongwei Zhang, linux-arm-kernel
In-Reply-To: <1569351740-6285-1-git-send-email-hongweiz@ami.com>
>
> > The related SGPIO driver has been accepted and merged into v5.4:
> > _http://patchwork.ozlabs.org/patch/1150357/
>
> Oh what a mess, it didn't add the necessary code into Kconfig and Makefile, also names it sgpio-gpio.c
> when everything else is named gpio-sgpio.c.
>
> I guess I have to fix it up. My fault for missing.
>
> Linus Walleij
Thanks Linus,
It's not your fault, I misunderstood a earlier comment from another
reviewer and thought I should wait until the driver is accecpted,
and then submit the patch to include / enable it.
As Bart suggested, I splitte the patches.
Regarding the driver name, following the gpio-SoC_name.o convention
in the Makefile, we choose sgpio-aspeed.o .
--Hongwei
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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