* [PATCH 0/5] Minimal cpuidle fixes for omap5 and dra7
From: Santosh Shilimkar @ 2016-10-26 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-1-tony@atomide.com>
On 10/26/2016 8:16 AM, Tony Lindgren wrote:
> Hi all,
>
> Here are some fixes to get minimal cpuidle support working with omap5
> and dra7. Not sure if there are still some unsorted issues on enabling
> this on dra7, but at least omap5 has been behving for me for few
> weeks with these.
>
> Regards,
>
> Tony
>
>
> Santosh Shilimkar (1):
> ARM: DRA7: PM: cpuidle MPU CSWR support
>
> Tony Lindgren (4):
> ARM: OMAP5: Fix build for PM code
> ARM: OMAP5: Fix mpuss_early_init
> ARM: OMAP4+: Fix bad fallthrough for cpuidle
> ARM: OMAP5: Enable minimal cpuidle for omap5 retention
>
Feel free to add my ack if you need one.
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
^ permalink raw reply
* [PATCH V4 0/5] firmware: Add support for TI System Control Interface (TI-SCI) protocol driver
From: Santosh Shilimkar @ 2016-10-26 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2694e4b5-20d5-f590-c6a6-55ff4cb8c16b@ti.com>
On 10/25/2016 10:34 AM, Tero Kristo wrote:
> On 19/10/16 02:08, Nishanth Menon wrote:
>> Version 4 of the series is basically a rebase to v4.9-rc1, no functional
>> changes.
>
> Hi,
>
> Any final comments on this series, or shall I send a pull-req forward?
> Very minimal changes compared to v3 so should be good to go imo.
>
The patchset looks fine to me from brief scan so please Go from
my side at least for the pull request.
Regards,
Santosh
^ permalink raw reply
* [PATCH] arm64: Add support of R_AARCH64_PREL32 relocation in purgatory
From: Geoff Levand @ 2016-10-26 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0eb8a908f617e0f957df7fb3ef293596f47e6832.1477456661.git.panand@redhat.com>
On 10/25/2016 09:40 PM, Pratyush Anand wrote:
> + case R_AARCH64_PREL32:
> + type = "PREL32";
> + loc32 = ptr;
> + *loc32 = cpu_to_elf32(ehdr, elf32_to_cpu(ehdr, *loc32) + value - address);
Please keep line width less than 80 chars.
> + break;
^ permalink raw reply
* [PATCH] ARM: davinci: register the usb20_phy clock on the DT file
From: David Lechner @ 2016-10-26 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026194916.14546-1-ahaslam@baylibre.com>
On 10/26/2016 02:49 PM, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> The usb20_phy clock needs to be registered for the driver to be able
> to get and enable a clock. Currently the usb phy clocks are registered
> form board files, which will not be called during a device tree based
> boot.
>
> To be able to probe correctly usb form a device tree boot, register
> the usb phy clocks form the DT specific init.
>
> Unfourtunatly, davinci does not have proper clock support on device tree
> yet, so by registering the clock form de DT specific file we are
> forced to hardcode the parent clock, and cannot select refclkin as
> parent for any of the phy clocks of the da850 family.
>
> As none of the current da850 based boards currently in mainline use
> refclkin as source. I guess we can live with this limitation until clocks
> are correctly represented through CCF/device tree.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
>
> This patch depends on David's series for usb clocks:
>
> currently:
> [PATCH v6 0/5] da8xx USB PHY platform devices and clocks
> https://lkml.org/lkml/2016/10/25/867
>
> arch/arm/mach-davinci/da8xx-dt.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index c9f7e92..7947267 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -45,6 +45,8 @@
>
> static void __init da850_init_machine(void)
> {
> + da8xx_register_usb20_phy_clk(false);
> + da8xx_register_usb11_phy_clk(false);
> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
> }
>
>
You should check for error on return and print a warning if there is an
error. Like this: https://patchwork.kernel.org/patch/9395635/
(I actually just had to make this change a few minutes ago to
troubleshoot a problem that I am working on.
da8xx_register_usb11_phy_clk() is failing for some reason that I have
not figured out yet.)
^ permalink raw reply
* [PATCH 1/3] coresight: tmc: Cleanup operation mode handling
From: Mathieu Poirier @ 2016-10-26 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474983865-11816-1-git-send-email-suzuki.poulose@arm.com>
On 27 September 2016 at 07:44, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> The mode of operation of the TMC tracked in drvdata->mode is defined
> as a local_t type. This is always checked and modified under the
> drvdata->spinlock and hence we don't need local_t for it and the
> unnecessary synchronisation instructions that comes with it. This
> change makes the code a bit more cleaner.
>
> Also fixes the order in which we update the drvdata->mode to
> CS_MODE_DISABLED. i.e, in tmc_disable_etX_sink we change the
> mode to CS_MODE_DISABLED before invoking tmc_disable_etX_hw()
> which in turn depends on the mode to decide whether to dump the
> trace to a buffer.
>
> Applies on mathieu's coresight/next tree [1]
>
> https://git.linaro.org/kernel/coresight.git next
>
> Reported-by: Venkatesh Vivekanandan <venkatesh.vivekanandan@broadcom.com>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etf.c | 32 +++++++++++--------------
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 26 +++++++++-----------
> drivers/hwtracing/coresight/coresight-tmc.h | 2 +-
> 3 files changed, 26 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> index d6941ea..e80a8f4 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
> @@ -70,7 +70,7 @@ static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
> * When operating in sysFS mode the content of the buffer needs to be
> * read before the TMC is disabled.
> */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etb_dump_hw(drvdata);
> tmc_disable_hw(drvdata);
>
> @@ -108,7 +108,6 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev, u32 mode)
> int ret = 0;
> bool used = false;
> char *buf = NULL;
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -138,13 +137,12 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In sysFS mode we can have multiple writers per sink. Since this
> * sink is already enabled no memory is needed and the HW need not be
> * touched.
> */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> goto out;
>
> /*
> @@ -163,6 +161,7 @@ static int tmc_enable_etf_sink_sysfs(struct coresight_device *csdev, u32 mode)
> drvdata->buf = buf;
> }
>
> + drvdata->mode = CS_MODE_SYSFS;
> tmc_etb_enable_hw(drvdata);
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> @@ -180,7 +179,6 @@ out:
> static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, u32 mode)
> {
> int ret = 0;
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -194,17 +192,17 @@ static int tmc_enable_etf_sink_perf(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In Perf mode there can be only one writer per sink. There
> * is also no need to continue if the ETB/ETR is already operated
> * from sysFS.
> */
> - if (val != CS_MODE_DISABLED) {
> + if (drvdata->mode != CS_MODE_DISABLED) {
> ret = -EINVAL;
> goto out;
> }
>
> + drvdata->mode = mode;
> tmc_etb_enable_hw(drvdata);
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> @@ -227,7 +225,6 @@ static int tmc_enable_etf_sink(struct coresight_device *csdev, u32 mode)
>
> static void tmc_disable_etf_sink(struct coresight_device *csdev)
> {
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -237,10 +234,11 @@ static void tmc_disable_etf_sink(struct coresight_device *csdev)
> return;
> }
>
> - val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
> /* Disable the TMC only if it needs to */
> - if (val != CS_MODE_DISABLED)
> + if (drvdata->mode != CS_MODE_DISABLED) {
> tmc_etb_disable_hw(drvdata);
> + drvdata->mode = CS_MODE_DISABLED;
> + }
>
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> @@ -260,7 +258,7 @@ static int tmc_enable_etf_link(struct coresight_device *csdev,
> }
>
> tmc_etf_enable_hw(drvdata);
> - local_set(&drvdata->mode, CS_MODE_SYSFS);
> + drvdata->mode = CS_MODE_SYSFS;
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> dev_info(drvdata->dev, "TMC-ETF enabled\n");
> @@ -280,7 +278,7 @@ static void tmc_disable_etf_link(struct coresight_device *csdev,
> }
>
> tmc_etf_disable_hw(drvdata);
> - local_set(&drvdata->mode, CS_MODE_DISABLED);
> + drvdata->mode = CS_MODE_DISABLED;
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> dev_info(drvdata->dev, "TMC disabled\n");
> @@ -383,7 +381,7 @@ static void tmc_update_etf_buffer(struct coresight_device *csdev,
> return;
>
> /* This shouldn't happen */
> - if (WARN_ON_ONCE(local_read(&drvdata->mode) != CS_MODE_PERF))
> + if (WARN_ON_ONCE(drvdata->mode != CS_MODE_PERF))
> return;
>
> CS_UNLOCK(drvdata->base);
> @@ -504,7 +502,6 @@ const struct coresight_ops tmc_etf_cs_ops = {
>
> int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> {
> - long val;
> enum tmc_mode mode;
> int ret = 0;
> unsigned long flags;
> @@ -528,9 +525,8 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> goto out;
> }
>
> - val = local_read(&drvdata->mode);
> /* Don't interfere if operated from Perf */
> - if (val == CS_MODE_PERF) {
> + if (drvdata->mode == CS_MODE_PERF) {
> ret = -EINVAL;
> goto out;
> }
> @@ -542,7 +538,7 @@ int tmc_read_prepare_etb(struct tmc_drvdata *drvdata)
> }
>
> /* Disable the TMC if need be */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etb_disable_hw(drvdata);
>
> drvdata->reading = true;
> @@ -573,7 +569,7 @@ int tmc_read_unprepare_etb(struct tmc_drvdata *drvdata)
> }
>
> /* Re-enable the TMC if need be */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS) {
> + if (drvdata->mode == CS_MODE_SYSFS) {
> /*
> * The trace run will continue with the same allocated trace
> * buffer. As such zero-out the buffer so that we don't end
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 886ea83..f23ef0c 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -86,7 +86,7 @@ static void tmc_etr_disable_hw(struct tmc_drvdata *drvdata)
> * When operating in sysFS mode the content of the buffer needs to be
> * read before the TMC is disabled.
> */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etr_dump_hw(drvdata);
> tmc_disable_hw(drvdata);
>
> @@ -97,7 +97,6 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev, u32 mode)
> {
> int ret = 0;
> bool used = false;
> - long val;
> unsigned long flags;
> void __iomem *vaddr = NULL;
> dma_addr_t paddr;
> @@ -134,13 +133,12 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In sysFS mode we can have multiple writers per sink. Since this
> * sink is already enabled no memory is needed and the HW need not be
> * touched.
> */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> goto out;
>
> /*
> @@ -157,6 +155,7 @@ static int tmc_enable_etr_sink_sysfs(struct coresight_device *csdev, u32 mode)
>
> memset(drvdata->vaddr, 0, drvdata->size);
>
> + drvdata->mode = CS_MODE_SYSFS;
> tmc_etr_enable_hw(drvdata);
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> @@ -174,7 +173,6 @@ out:
> static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, u32 mode)
> {
> int ret = 0;
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -188,17 +186,17 @@ static int tmc_enable_etr_sink_perf(struct coresight_device *csdev, u32 mode)
> goto out;
> }
>
> - val = local_xchg(&drvdata->mode, mode);
> /*
> * In Perf mode there can be only one writer per sink. There
> * is also no need to continue if the ETR is already operated
> * from sysFS.
> */
> - if (val != CS_MODE_DISABLED) {
> + if (drvdata->mode != CS_MODE_DISABLED) {
> ret = -EINVAL;
> goto out;
> }
>
> + drvdata->mode = CS_MODE_PERF;
> tmc_etr_enable_hw(drvdata);
> out:
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
> @@ -221,7 +219,6 @@ static int tmc_enable_etr_sink(struct coresight_device *csdev, u32 mode)
>
> static void tmc_disable_etr_sink(struct coresight_device *csdev)
> {
> - long val;
> unsigned long flags;
> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -231,10 +228,11 @@ static void tmc_disable_etr_sink(struct coresight_device *csdev)
> return;
> }
>
> - val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
> /* Disable the TMC only if it needs to */
> - if (val != CS_MODE_DISABLED)
> + if (drvdata->mode != CS_MODE_DISABLED) {
> tmc_etr_disable_hw(drvdata);
> + drvdata->mode = CS_MODE_DISABLED;
> + }
>
> spin_unlock_irqrestore(&drvdata->spinlock, flags);
>
> @@ -253,7 +251,6 @@ const struct coresight_ops tmc_etr_cs_ops = {
> int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> {
> int ret = 0;
> - long val;
> unsigned long flags;
>
> /* config types are set a boot time and never change */
> @@ -266,9 +263,8 @@ int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> goto out;
> }
>
> - val = local_read(&drvdata->mode);
> /* Don't interfere if operated from Perf */
> - if (val == CS_MODE_PERF) {
> + if (drvdata->mode == CS_MODE_PERF) {
> ret = -EINVAL;
> goto out;
> }
> @@ -280,7 +276,7 @@ int tmc_read_prepare_etr(struct tmc_drvdata *drvdata)
> }
>
> /* Disable the TMC if need be */
> - if (val == CS_MODE_SYSFS)
> + if (drvdata->mode == CS_MODE_SYSFS)
> tmc_etr_disable_hw(drvdata);
>
> drvdata->reading = true;
> @@ -303,7 +299,7 @@ int tmc_read_unprepare_etr(struct tmc_drvdata *drvdata)
> spin_lock_irqsave(&drvdata->spinlock, flags);
>
> /* RE-enable the TMC if need be */
> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS) {
> + if (drvdata->mode == CS_MODE_SYSFS) {
> /*
> * The trace run will continue with the same allocated trace
> * buffer. The trace buffer is cleared in tmc_etr_enable_hw(),
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h
> index 44b3ae3..51c0185 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.h
> +++ b/drivers/hwtracing/coresight/coresight-tmc.h
> @@ -117,7 +117,7 @@ struct tmc_drvdata {
> void __iomem *vaddr;
> u32 size;
> u32 len;
> - local_t mode;
> + u32 mode;
> enum tmc_config_type config_type;
> enum tmc_mem_intf_width memwidth;
> u32 trigger_cntr;
> --
> 2.7.4
>
I have applied all 3 patches in this set.
Thank you for the code and apologies for the delay,
Mathieu
^ permalink raw reply
* [PATCH] ARM: davinci: register the usb20_phy clock on the DT file
From: David Lechner @ 2016-10-26 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f2aeafb1-38f4-9b1e-c3fd-a2984333d00f@lechnology.com>
On 10/26/2016 03:01 PM, David Lechner wrote:
> On 10/26/2016 02:49 PM, ahaslam at baylibre.com wrote:
>> From: Axel Haslam <ahaslam@baylibre.com>
>>
>> The usb20_phy clock needs to be registered for the driver to be able
>> to get and enable a clock. Currently the usb phy clocks are registered
>> form board files, which will not be called during a device tree based
>> boot.
>>
>> To be able to probe correctly usb form a device tree boot, register
>> the usb phy clocks form the DT specific init.
>>
>> Unfourtunatly, davinci does not have proper clock support on device tree
>> yet, so by registering the clock form de DT specific file we are
>> forced to hardcode the parent clock, and cannot select refclkin as
>> parent for any of the phy clocks of the da850 family.
>>
>> As none of the current da850 based boards currently in mainline use
>> refclkin as source. I guess we can live with this limitation until clocks
>> are correctly represented through CCF/device tree.
>>
>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>> ---
>>
>> This patch depends on David's series for usb clocks:
>>
>> currently:
>> [PATCH v6 0/5] da8xx USB PHY platform devices and clocks
>> https://lkml.org/lkml/2016/10/25/867
>>
>> arch/arm/mach-davinci/da8xx-dt.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
>> b/arch/arm/mach-davinci/da8xx-dt.c
>> index c9f7e92..7947267 100644
>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>> @@ -45,6 +45,8 @@
>>
>> static void __init da850_init_machine(void)
>> {
>> + da8xx_register_usb20_phy_clk(false);
>> + da8xx_register_usb11_phy_clk(false);
>> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
>> }
>>
>>
>
>
> You should check for error on return and print a warning if there is an
> error. Like this: https://patchwork.kernel.org/patch/9395635/
>
> (I actually just had to make this change a few minutes ago to
> troubleshoot a problem that I am working on.
> da8xx_register_usb11_phy_clk() is failing for some reason that I have
> not figured out yet.)
And actually, since my patch that provides these functions has not been
accepted yet, why don't I just add this change to that series?
^ permalink raw reply
* [PATCH] ARM: davinci: register the usb20_phy clock on the DT file
From: Axel Haslam @ 2016-10-26 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <48fa5315-74db-cf33-1f34-86764f0e2c1c@lechnology.com>
On Wed, Oct 26, 2016 at 10:03 PM, David Lechner <david@lechnology.com> wrote:
> On 10/26/2016 03:01 PM, David Lechner wrote:
>>
>> On 10/26/2016 02:49 PM, ahaslam at baylibre.com wrote:
>>>
>>> From: Axel Haslam <ahaslam@baylibre.com>
>>>
>>> The usb20_phy clock needs to be registered for the driver to be able
>>> to get and enable a clock. Currently the usb phy clocks are registered
>>> form board files, which will not be called during a device tree based
>>> boot.
>>>
>>> To be able to probe correctly usb form a device tree boot, register
>>> the usb phy clocks form the DT specific init.
>>>
>>> Unfourtunatly, davinci does not have proper clock support on device tree
>>> yet, so by registering the clock form de DT specific file we are
>>> forced to hardcode the parent clock, and cannot select refclkin as
>>> parent for any of the phy clocks of the da850 family.
>>>
>>> As none of the current da850 based boards currently in mainline use
>>> refclkin as source. I guess we can live with this limitation until clocks
>>> are correctly represented through CCF/device tree.
>>>
>>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>>> ---
>>>
>>> This patch depends on David's series for usb clocks:
>>>
>>> currently:
>>> [PATCH v6 0/5] da8xx USB PHY platform devices and clocks
>>> https://lkml.org/lkml/2016/10/25/867
>>>
>>> arch/arm/mach-davinci/da8xx-dt.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
>>> b/arch/arm/mach-davinci/da8xx-dt.c
>>> index c9f7e92..7947267 100644
>>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>>> @@ -45,6 +45,8 @@
>>>
>>> static void __init da850_init_machine(void)
>>> {
>>> + da8xx_register_usb20_phy_clk(false);
>>> + da8xx_register_usb11_phy_clk(false);
>>> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
>>> }
>>>
>>>
>>
>>
>> You should check for error on return and print a warning if there is an
>> error. Like this: https://patchwork.kernel.org/patch/9395635/
>>
>> (I actually just had to make this change a few minutes ago to
>> troubleshoot a problem that I am working on.
>> da8xx_register_usb11_phy_clk() is failing for some reason that I have
>> not figured out yet.)
>
>
>
> And actually, since my patch that provides these functions has not been
> accepted yet, why don't I just add this change to that series?
Ok, sure, if you are planing on sending another version.
Regards
Axel
^ permalink raw reply
* [PATCH] ARM: davinci: register the usb20_phy clock on the DT file
From: David Lechner @ 2016-10-26 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKXjFTNyNEykVn3+mxiaQionxuzrp812nfdD=9uNgrbddv939Q@mail.gmail.com>
On 10/26/2016 03:05 PM, Axel Haslam wrote:
> On Wed, Oct 26, 2016 at 10:03 PM, David Lechner <david@lechnology.com> wrote:
>> On 10/26/2016 03:01 PM, David Lechner wrote:
>>>
>>> On 10/26/2016 02:49 PM, ahaslam at baylibre.com wrote:
>>>>
>>>> From: Axel Haslam <ahaslam@baylibre.com>
>>>>
>>>> The usb20_phy clock needs to be registered for the driver to be able
>>>> to get and enable a clock. Currently the usb phy clocks are registered
>>>> form board files, which will not be called during a device tree based
>>>> boot.
>>>>
>>>> To be able to probe correctly usb form a device tree boot, register
>>>> the usb phy clocks form the DT specific init.
>>>>
>>>> Unfourtunatly, davinci does not have proper clock support on device tree
>>>> yet, so by registering the clock form de DT specific file we are
>>>> forced to hardcode the parent clock, and cannot select refclkin as
>>>> parent for any of the phy clocks of the da850 family.
>>>>
>>>> As none of the current da850 based boards currently in mainline use
>>>> refclkin as source. I guess we can live with this limitation until clocks
>>>> are correctly represented through CCF/device tree.
>>>>
>>>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>>>> ---
>>>>
>>>> This patch depends on David's series for usb clocks:
>>>>
>>>> currently:
>>>> [PATCH v6 0/5] da8xx USB PHY platform devices and clocks
>>>> https://lkml.org/lkml/2016/10/25/867
>>>>
>>>> arch/arm/mach-davinci/da8xx-dt.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/arch/arm/mach-davinci/da8xx-dt.c
>>>> b/arch/arm/mach-davinci/da8xx-dt.c
>>>> index c9f7e92..7947267 100644
>>>> --- a/arch/arm/mach-davinci/da8xx-dt.c
>>>> +++ b/arch/arm/mach-davinci/da8xx-dt.c
>>>> @@ -45,6 +45,8 @@
>>>>
>>>> static void __init da850_init_machine(void)
>>>> {
>>>> + da8xx_register_usb20_phy_clk(false);
>>>> + da8xx_register_usb11_phy_clk(false);
>>>> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
>>>> }
>>>>
>>>>
>>>
>>>
>>> You should check for error on return and print a warning if there is an
>>> error. Like this: https://patchwork.kernel.org/patch/9395635/
>>>
>>> (I actually just had to make this change a few minutes ago to
>>> troubleshoot a problem that I am working on.
>>> da8xx_register_usb11_phy_clk() is failing for some reason that I have
>>> not figured out yet.)
>>
>>
>>
>> And actually, since my patch that provides these functions has not been
>> accepted yet, why don't I just add this change to that series?
>
> Ok, sure, if you are planing on sending another version.
>
> Regards
> Axel
>
Yes, I have some more changes to make and resubmit, so I will include
this too.
^ permalink raw reply
* [PATCH 2/3] ARM: convert to generated system call tables
From: Robert Jarzmik @ 2016-10-26 20:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVy_h6Uss9bwVK5hGD42bXeEBcBsBDwCpx_eYnT9r+=Lw@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Sat, Oct 22, 2016 at 10:23 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
>> Arnd Bergmann <arnd@arndb.de> writes:
>>
>>> On Friday, October 21, 2016 4:48:56 PM CEST Russell King - ARM Linux wrote:
>>>> What's the point of the x32 mode?
>>>
>>> On x86, the motivation is faster code for most use cases that
>>> don't need a lot of memory, as the 64-bit opcodes have 16 registers
>>> rather than 8 in 32-bit mode but 32-bit pointers have lower
>>> cache footprint than 64-bit pointers.
>>
>> For completness, the second point of x32 AFAIU is the IP-relative addressing
>> which is not available in standard 32 bit mode, which improves PIC code. For
>> simple not algorithmic code (think Android HAL for example) with many shared
>> libraries, it's better in the Hardware Abstraction Layer Libraries, instead of
>> the push-to-stack and pop register.
>
> But that's not an advantage compared to full am64 mode, right?
Nope, the amd64 (that's what you have in mind with am64, not aarch64 right ?)
mode has the IP-relative has well, so x32 has no advantage over amd64 in this
area.
x32 over amd64 advantage is cache and memory footprint AFAICT, I don't see other
benefits. There doesn't seem to be any ISA differences, or I didn't really
notice in my daily system performance analysis job.
There was a nice presentation made by Peter Anvin at a Plumber conference, here
: http://linuxplumbersconf.org/2011/ocw/sessions/531
Cheers.
--
Robert
^ permalink raw reply
* [PATCH 2/5] ARM: OMAP5: Fix mpuss_early_init
From: Tony Lindgren @ 2016-10-26 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-3-tony@atomide.com>
* Tony Lindgren <tony@atomide.com> [161026 08:18]:
> We need to properly initialize mpuss also on omap5 like we do on omap4.
> Otherwise we run into similar kexec problems like we had on omap4 when
> trying to kexec from a kernel with PM initialized.
...
> + else if (cpu_is_omap446x())
> startup_pa = virt_to_phys(omap4460_secondary_startup);
> + else
> + startup_pa = virt_to_phys(omap5_secondary_startup);
Here we need to check for omap5_secondary_hyp_startup too. And with
omap4 and omap5 being optional, we need to fix up things for make
randconfig builds as reported by the kbuild test robot.
Updated patch below.
Regards,
Tony
8< -----------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 25 Oct 2016 08:33:32 -0700
Subject: [PATCH] ARM: OMAP5: Fix mpuss_early_init
We need to properly initialize mpuss also on omap5 like we do on omap4.
Otherwise we run into similar kexec problems like we had on omap4 when
trying to kexec from a kernel with PM initialized.
Fixes: 0573b957fc21 ("ARM: OMAP4+: Prevent CPU1 related hang with kexec")
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/common.h | 38 +++++++++++++++++++++++--------
arch/arm/mach-omap2/io.c | 3 ++-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 32 ++++++++++++++++++++------
arch/arm/mach-omap2/omap4-sar-layout.h | 2 ++
4 files changed, 58 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -262,8 +262,6 @@ extern void __iomem *omap4_get_sar_ram_base(void);
extern void omap4_mpuss_early_init(void);
extern void omap_do_wfi(void);
-extern void omap4_secondary_startup(void);
-extern void omap4460_secondary_startup(void);
#ifdef CONFIG_SMP
/* Needed for secondary core boot */
@@ -275,16 +273,11 @@ extern void omap4_cpu_die(unsigned int cpu);
extern int omap4_cpu_kill(unsigned int cpu);
extern const struct smp_operations omap4_smp_ops;
-
-extern void omap5_secondary_startup(void);
-extern void omap5_secondary_hyp_startup(void);
#endif
#if defined(CONFIG_SMP) && defined(CONFIG_PM)
extern int omap4_mpuss_init(void);
extern int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state);
-extern int omap4_finish_suspend(unsigned long cpu_state);
-extern void omap4_cpu_resume(void);
extern int omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state);
#else
static inline int omap4_enter_lowpower(unsigned int cpu,
@@ -305,14 +298,41 @@ static inline int omap4_mpuss_init(void)
return 0;
}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP4
+void omap4_secondary_startup(void);
+void omap4460_secondary_startup(void);
+int omap4_finish_suspend(unsigned long cpu_state);
+void omap4_cpu_resume(void);
+#else
+static inline void omap4_secondary_startup(void)
+{
+}
+
+static inline void omap4460_secondary_startup(void)
+{
+}
static inline int omap4_finish_suspend(unsigned long cpu_state)
{
return 0;
}
-
static inline void omap4_cpu_resume(void)
-{}
+{
+}
+#endif
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
+void omap5_secondary_startup(void);
+void omap5_secondary_hyp_startup(void);
+#else
+static inline void omap5_secondary_startup(void)
+{
+}
+
+static inline void omap5_secondary_hyp_startup(void)
+{
+}
#endif
void pdata_quirks_init(const struct of_device_id *);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -717,10 +717,11 @@ void __init omap5_init_early(void)
OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
omap2_control_base_init();
- omap4_pm_init_early();
omap2_prcm_base_init();
omap5xxx_check_revision();
omap4_sar_ram_init();
+ omap4_mpuss_early_init();
+ omap4_pm_init_early();
omap54xx_voltagedomains_init();
omap54xx_powerdomains_init();
omap54xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -48,6 +48,7 @@
#include <asm/smp_scu.h>
#include <asm/pgalloc.h>
#include <asm/suspend.h>
+#include <asm/virt.h>
#include <asm/hardware/cache-l2x0.h>
#include "soc.h"
@@ -371,8 +372,12 @@ int __init omap4_mpuss_init(void)
pm_info = &per_cpu(omap4_pm_info, 0x0);
if (sar_base) {
pm_info->scu_sar_addr = sar_base + SCU_OFFSET0;
- pm_info->wkup_sar_addr = sar_base +
- CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ if (cpu_is_omap44xx())
+ pm_info->wkup_sar_addr = sar_base +
+ CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
+ else
+ pm_info->wkup_sar_addr = sar_base +
+ OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET0;
}
pm_info->pwrdm = pwrdm_lookup("cpu0_pwrdm");
@@ -391,8 +396,12 @@ int __init omap4_mpuss_init(void)
pm_info = &per_cpu(omap4_pm_info, 0x1);
if (sar_base) {
pm_info->scu_sar_addr = sar_base + SCU_OFFSET1;
- pm_info->wkup_sar_addr = sar_base +
- CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ if (cpu_is_omap44xx())
+ pm_info->wkup_sar_addr = sar_base +
+ CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
+ else
+ pm_info->wkup_sar_addr = sar_base +
+ OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET;
pm_info->l2x0_sar_addr = sar_base + L2X0_SAVE_OFFSET1;
}
@@ -453,15 +462,24 @@ void __init omap4_mpuss_early_init(void)
{
unsigned long startup_pa;
- if (!cpu_is_omap44xx())
+ if (!(cpu_is_omap44xx() || soc_is_omap54xx()))
return;
sar_base = omap4_get_sar_ram_base();
if (cpu_is_omap443x())
startup_pa = virt_to_phys(omap4_secondary_startup);
- else
+ else if (cpu_is_omap446x())
startup_pa = virt_to_phys(omap4460_secondary_startup);
+ else if ((__boot_cpu_mode & MODE_MASK) == HYP_MODE)
+ startup_pa = virt_to_phys(omap5_secondary_hyp_startup);
+ else
+ startup_pa = virt_to_phys(omap5_secondary_startup);
- writel_relaxed(startup_pa, sar_base + CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
+ if (cpu_is_omap44xx())
+ writel_relaxed(startup_pa, sar_base +
+ CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
+ else
+ writel_relaxed(startup_pa, sar_base +
+ OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET);
}
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -31,6 +31,8 @@
/* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
#define CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xa08
+#define OMAP5_CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xe00
+#define OMAP5_CPU1_WAKEUP_NS_PA_ADDR_OFFSET 0xe04
#define SAR_BACKUP_STATUS_OFFSET (SAR_BANK3_OFFSET + 0x500)
#define SAR_SECURE_RAM_SIZE_OFFSET (SAR_BANK3_OFFSET + 0x504)
--
2.9.3
^ permalink raw reply
* [PATCH 1/6] dt: bindings: Add Allwinner Q8 tablets hardware manager bindings
From: Rob Herring @ 2016-10-26 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161014075337.10452-2-hdegoede@redhat.com>
On Fri, Oct 14, 2016 at 09:53:32AM +0200, Hans de Goede wrote:
> Allwinnner A13 / A23 / A33 based Q8 tablets are popular cheap 7" tablets
> of which a new batch is produced every few weeks. Each batch uses a
> different mix of touchscreen, accelerometer and wifi peripherals.
>
> Given that each batch is different creating a devicetree for each variant
> is not desirable, work is being done on a Q8 tablet hardware manager which
> auto-detects the touchscreen and accelerometer and will update the dt with
> what it has found, so that a single generic dt can be used for these tablets.
>
> This commit adds dt-bindings for this hardware manager.
>
> Note the wifi is connected to a discoverable bus (sdio or usb) and will be
> autodetected by the mmc resp. usb subsystems.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../misc/allwinner,sunxi-q8-hardwaremgr.txt | 71 ++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt b/Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt
> new file mode 100644
> index 0000000..a81b258
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/allwinner,sunxi-q8-hardwaremgr.txt
> @@ -0,0 +1,71 @@
> +Q8 tablet hardware manager
> +--------------------------
> +
> +Allwinnner A13 / A23 / A33 based Q8 tablets are popular cheap 7" tablets of
> +which a new batch is produced every few weeks. Each batch uses a different
> +mix of touchscreen, accelerometer and wifi peripherals.
> +
> +Given that each batch is different creating a devicetree for each variant is
> +not desirable. The Q8 tablet hardware manager bindings are bindings for an os
> +module which auto-detects the touchscreen and accelerometer so that a single
> +generic dts can be used for these tablets.
> +
> +The wifi is connected to a discoverable bus and will be autodetected by the os.
> +
> +Required properties:
> + - toplevel / machine compatible, one of:
> + "allwinner,q8-a13"
> + "allwinner,q8-a23"
> + "allwinner,q8-a33"
> + - touchscreen node : There must be a template touchscreen node named
> + "touchscreen", this must be a child node of the
> + touchscreen i2c bus
> + - accelerometer node : There must be a template accelerometer node named
> + "accelerometer", this must be a child node of the
> + accelerometer i2c bus
> +
> +touchscreen node required properties:
> + - interrupt-parent : phandle pointing to the interrupt controller
> + serving the touchscreen interrupt
> + - interrupts : interrupt specification for the touchscreen interrupt
> + - power-gpios : Specification for the pin connected to the touchscreen's
> + enable / wake pin. This needs to be driven high to
> + enable the touchscreen controller
enable-gpios is the common name.
I was going to say you need to list possible compatible strings here
also. However, I now wonder if this binding doc is even needed. The
binding docs should just be the bindings for each touchscreen or
accelerometer. The fact that the node is completed at run-time whether
the bootloader or kernel doesn't matter for the binding definition. When
and it is completed is orthogonal to the binding definition.
Rob
^ permalink raw reply
* Add Allwinner Q8 tablets hardware manager
From: Rob Herring @ 2016-10-26 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024173900.GP15620@leverpostej>
On Mon, Oct 24, 2016 at 06:39:01PM +0100, Mark Rutland wrote:
> On Fri, Oct 14, 2016 at 09:53:31AM +0200, Hans de Goede wrote:
> > Hi Rob, Mark, et al.,
>
> Hi Hans,
>
> Apologies for the delay in replying to this.
>
> I'd like to be clear that I do understand that there is a problem that
> needs to be addressed here. However, I do not believe that the *current*
> in-kernel approach is correct. More on that below.
>
> > Mark, I know that we discussed this at ELCE and you clearly indicated
> > that according to you this does not belong in the kernel. I was a bit
> > surprised by this part of the discussion.
> >
> > I had posted a RFC earlier and Rob had indicated that given that the q8
> > tablets are a special case, as my code uses actual probing rather then some
> > pre-arranged id mechanism with say an eeprom, that doing this in a
> > non-generic manner would be ok for my special case.
>
> To some extent, Rob and I may have differing views here; I'm not
> entirely sure what Rob's view is, and I cannot talk on his behalf. I
> certainly must apologise for having not commented on said RFC, however.
I've focused mainly on the bindings which I certainly had issues with
how the RFC was done. As to where this should be done, keeping all the
dirty bits in firmware/bootloader is certainly appealing. However, there
are cases where data alone can't abstract out board differences and we
need board code. Whether this is one of them, well, that is Hans' job to
convince Mark.
Rob
^ permalink raw reply
* [PATCH 0/5] Minimal cpuidle fixes for omap5 and dra7
From: Nishanth Menon @ 2016-10-26 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026151703.24730-1-tony@atomide.com>
Tony,
On 10/26/2016 10:16 AM, Tony Lindgren wrote:
> Hi all,
>
> Here are some fixes to get minimal cpuidle support working with omap5
> and dra7. Not sure if there are still some unsorted issues on enabling
> this on dra7, but at least omap5 has been behving for me for few
> weeks with these.
I am OK with cpuidle for OMAP5, but NOT dra7. we have enabled this
series of patches close to a couple of years back and hit quiet a few
issues that do not have silicon resolution. CPU states lower than WFI
will not work in cpuidle for DRA7 and has already been "descoped" from
TI investigation charter. details of the issue remain TI internal,
given that the descope was already done.
Again, OMAP5 has only had limited exposure from verification point of
view - and all of it TI internal (unlike OMAP4 which has had
production devices go ahead) -> at the very least, I'd link it with
experimental.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v1 1/4] dt-bindings: Document Broadcom iProc mailbox controller driver
From: Rob Herring @ 2016-10-26 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476817238-1226-2-git-send-email-jonathan.richardson@broadcom.com>
On Tue, Oct 18, 2016 at 12:00:35PM -0700, Jonathan Richardson wrote:
> Reviewed-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> Reviewed-by: Vikram Prakash <vikram.prakash@broadcom.com>
> Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
> ---
> .../bindings/mailbox/brcm,iproc-mailbox.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [rjarzmik:work/ac97 9/13] sound/arm/pxa2xx-ac97.c:34:34: error: passing argument 1 of 'pxa2xx_ac97_try_cold_reset' from incompatible pointer type
From: kbuild test robot @ 2016-10-26 21:06 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/rjarzmik/linux work/ac97
head: 223e9c527c425b1b519468e54fff9f4f82a7f390
commit: 99ed942665174ff3212a5e2353a1dc2e6df76ff9 [9/13] ASoC: pxa: switch to new ac97 bus support
config: arm-viper_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 99ed942665174ff3212a5e2353a1dc2e6df76ff9
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
sound/arm/pxa2xx-ac97.c: In function 'pxa2xx_ac97_reset':
>> sound/arm/pxa2xx-ac97.c:34:34: error: passing argument 1 of 'pxa2xx_ac97_try_cold_reset' from incompatible pointer type [-Werror=incompatible-pointer-types]
if (!pxa2xx_ac97_try_cold_reset(ac97)) {
^~~~
In file included from sound/arm/pxa2xx-ac97.c:24:0:
include/sound/pxa2xx-lib.h:31:13: note: expected 'struct ac97_controller *' but argument is of type 'struct snd_ac97 *'
extern bool pxa2xx_ac97_try_cold_reset(struct ac97_controller *adrv);
^~~~~~~~~~~~~~~~~~~~~~~~~~
>> sound/arm/pxa2xx-ac97.c:35:30: error: passing argument 1 of 'pxa2xx_ac97_try_warm_reset' from incompatible pointer type [-Werror=incompatible-pointer-types]
pxa2xx_ac97_try_warm_reset(ac97);
^~~~
In file included from sound/arm/pxa2xx-ac97.c:24:0:
include/sound/pxa2xx-lib.h:30:13: note: expected 'struct ac97_controller *' but argument is of type 'struct snd_ac97 *'
extern bool pxa2xx_ac97_try_warm_reset(struct ac97_controller *adrv);
^~~~~~~~~~~~~~~~~~~~~~~~~~
>> sound/arm/pxa2xx-ac97.c:38:27: error: passing argument 1 of 'pxa2xx_ac97_finish_reset' from incompatible pointer type [-Werror=incompatible-pointer-types]
pxa2xx_ac97_finish_reset(ac97);
^~~~
In file included from sound/arm/pxa2xx-ac97.c:24:0:
include/sound/pxa2xx-lib.h:32:13: note: expected 'struct ac97_controller *' but argument is of type 'struct snd_ac97 *'
extern void pxa2xx_ac97_finish_reset(struct ac97_controller *adrv);
^~~~~~~~~~~~~~~~~~~~~~~~
sound/arm/pxa2xx-ac97.c: At top level:
>> sound/arm/pxa2xx-ac97.c:42:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.read = pxa2xx_ac97_read,
^~~~~~~~~~~~~~~~
sound/arm/pxa2xx-ac97.c:42:10: note: (near initialization for 'pxa2xx_ac97_ops.read')
sound/arm/pxa2xx-ac97.c:43:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.write = pxa2xx_ac97_write,
^~~~~~~~~~~~~~~~~
sound/arm/pxa2xx-ac97.c:43:11: note: (near initialization for 'pxa2xx_ac97_ops.write')
cc1: some warnings being treated as errors
vim +/pxa2xx_ac97_try_cold_reset +34 sound/arm/pxa2xx-ac97.c
a09e64fb Russell King 2008-08-05 28 #include <mach/audio.h>
2c484df0 Takashi Iwai 2005-06-30 29
2c484df0 Takashi Iwai 2005-06-30 30 #include "pxa2xx-pcm.h"
2c484df0 Takashi Iwai 2005-06-30 31
d18f8376 Takashi Iwai 2005-11-17 32 static void pxa2xx_ac97_reset(struct snd_ac97 *ac97)
2c484df0 Takashi Iwai 2005-06-30 33 {
9c636342 Dmitry Eremin-Solenikov 2008-09-10 @34 if (!pxa2xx_ac97_try_cold_reset(ac97)) {
9c636342 Dmitry Eremin-Solenikov 2008-09-10 @35 pxa2xx_ac97_try_warm_reset(ac97);
2c484df0 Takashi Iwai 2005-06-30 36 }
2c484df0 Takashi Iwai 2005-06-30 37
9c636342 Dmitry Eremin-Solenikov 2008-09-10 @38 pxa2xx_ac97_finish_reset(ac97);
2c484df0 Takashi Iwai 2005-06-30 39 }
2c484df0 Takashi Iwai 2005-06-30 40
d18f8376 Takashi Iwai 2005-11-17 41 static struct snd_ac97_bus_ops pxa2xx_ac97_ops = {
2c484df0 Takashi Iwai 2005-06-30 @42 .read = pxa2xx_ac97_read,
2c484df0 Takashi Iwai 2005-06-30 43 .write = pxa2xx_ac97_write,
2c484df0 Takashi Iwai 2005-06-30 44 .reset = pxa2xx_ac97_reset,
2c484df0 Takashi Iwai 2005-06-30 45 };
:::::: The code at line 34 was first introduced by commit
:::::: 9c63634221f67450ead19820e33996b69691194f ALSA: Separate common pxa2xx-ac97 code
:::::: TO: Dmitry Baryshkov <dbaryshkov@gmail.com>
:::::: CC: Jaroslav Kysela <perex@perex.cz>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 18279 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161027/286943ab/attachment-0001.gz>
^ permalink raw reply
* MAINTAINERS entry for ARM/CLKDEV SUPPORT
From: Stephen Boyd @ 2016-10-26 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026191938.GT4418@mwanda>
On 10/26/2016 12:19 PM, Dan Carpenter wrote:
> On Mon, Oct 10, 2016 at 03:18:19PM +0100, Russell King - ARM Linux wrote:
>> On Mon, Oct 10, 2016 at 05:08:10PM +0300, Dan Carpenter wrote:
>>> Hello Stephen Boyd,
>> Okay, that's really not nice.
>>
>> This is _not_ a question for Stephen. Stephen does _not_ co-maintain
>> clkdev or the clk API, but co-maintains CCF. I've no idea why you are
>> addressing this to Stephen when this is clearly a question for me to
>> answer.
>>
> Sorry, I didn't mean to offend. He's the one who deleted the clkdev.h
> file though so I thought he might know if it should still be listed or
> if it was gone for good.
>
Yes, the arm version isn't coming back. We should delete
arch/arm/include/asm/clkdev.h from the maintainers file and perhaps
replace it with the asm-generic one. But we can delete the generic file
too once blackfin removes their clkdev.h header. That patch is still
outstanding.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 0/5] Minimal cpuidle fixes for omap5 and dra7
From: Tony Lindgren @ 2016-10-26 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1b6bf69-ed11-3355-323f-9d6503180310@ti.com>
* Nishanth Menon <nm@ti.com> [161026 13:57]:
> Tony,
> On 10/26/2016 10:16 AM, Tony Lindgren wrote:
> > Hi all,
> >
> > Here are some fixes to get minimal cpuidle support working with omap5
> > and dra7. Not sure if there are still some unsorted issues on enabling
> > this on dra7, but at least omap5 has been behving for me for few
> > weeks with these.
>
> I am OK with cpuidle for OMAP5, but NOT dra7. we have enabled this series of
> patches close to a couple of years back and hit quiet a few issues that do
> not have silicon resolution. CPU states lower than WFI will not work in
> cpuidle for DRA7 and has already been "descoped" from TI investigation
> charter. details of the issue remain TI internal, given that the descope was
> already done.
Hmm OK, no point adding it if not supported by hardware. I'll modify the
series for omap5 only.
> Again, OMAP5 has only had limited exposure from verification point of view -
> and all of it TI internal (unlike OMAP4 which has had production devices go
> ahead) -> at the very least, I'd link it with experimental.
Sure, this is a subset already to let's see how that works before adding
any other modes.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 2/9] dt-bindings: interrupt-controller: add DT binding for meson GPIO interrupt controller
From: Rob Herring @ 2016-10-26 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476890480-8884-3-git-send-email-jbrunet@baylibre.com>
On Wed, Oct 19, 2016 at 05:21:13PM +0200, Jerome Brunet wrote:
>
> This commit adds the device tree bindings description for Amlogic's GPIO
> interrupt controller available on the meson8, meson8b and gxbb SoC families
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> Rob, I did not include the Ack you gave for the RFC as bindings have slightly
> changed. Only the interrupt property has be removed following a discussion I
> had with Marc
As Mark R already said, you should keep the interrupts property.
^ permalink raw reply
* [PATCH V6 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Rob Herring @ 2016-10-26 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476899512-20431-2-git-send-email-okaya@codeaurora.org>
On Wed, Oct 19, 2016 at 01:51:43PM -0400, Sinan Kaya wrote:
> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
> MSI interrupts from the older revision.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
Please add acks when posting new versions.
Rob
^ permalink raw reply
* [PATCH v6 2/2] Documentation: DT: MMC: meson-gx: new bindings doc
From: Rob Herring @ 2016-10-26 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019181825.2186-2-khilman@baylibre.com>
On Wed, Oct 19, 2016 at 11:18:25AM -0700, Kevin Hilman wrote:
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> .../devicetree/bindings/mmc/amlogic,meson-gx.txt | 33 ++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/amlogic,meson-gx.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 4/5] net: ethernet: bgmac: add NS2 support
From: Florian Fainelli @ 2016-10-26 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-5-git-send-email-jon.mason@broadcom.com>
On 10/26/2016 12:36 PM, Jon Mason wrote:
> Add support for the variant of amac hardware present in the Broadcom
> Northstar2 based SoCs. Northstar2 requires an additional register to be
> configured with the port speed/duplexity (NICPM). This can be added to
> the link callback to hide it from the instances that do not use this.
> Also, the bgmac_chip_reset() was intentionally removed to prevent the
> resetting of the chip to the default values on open. Finally, clearing
> of the pending interrupts on init is required due to observed issues on
> some platforms.
>
> Signed-off-by: Jon Mason <jon.mason@broadcom.com>
> ---
> +static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> +{
> + struct bgmac *bgmac = netdev_priv(net_dev);
> + u32 val;
> +
> + if (!bgmac->plat.nicpm_base)
> + return;
> +
> + val = NICPM_IOMUX_CTRL_INIT_VAL;
> + switch (bgmac->net_dev->phydev->speed) {
> + default:
> + pr_err("Unsupported speed. Defaulting to 1000Mb\n");
> + case SPEED_1000:
> + val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_100:
> + val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_10:
> + val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + }
> +
> + writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> +
> + usleep_range(10, 100);
Does not seem like a good idea, do you need that sleep?
> +
> + bgmac_adjust_link(bgmac->net_dev);
> +}
> +
> static int platform_phy_connect(struct bgmac *bgmac)
> {
> struct phy_device *phy_dev;
>
> - phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> - bgmac_adjust_link);
> + if (bgmac->plat.nicpm_base)
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_nicpm_speed_set);
> + else
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_adjust_link);
> if (!phy_dev) {
> dev_err(bgmac->dev, "Phy connect failed\n");
> return -ENODEV;
> }
>
> + if (bgmac->feature_flags & BGMAC_FEAT_LANE_SWAP)
> + phy_dev->dev_flags |= PHY_BRCM_EXP_LANE_SWAP;
> +
> return 0;
> }
>
> @@ -140,6 +188,9 @@ static int bgmac_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, bgmac);
>
> + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap"))
> + bgmac->feature_flags |= BGMAC_FEAT_LANE_SWAP;
> +
> /* Set the features of the 4707 family */
> bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
> bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
> @@ -182,6 +233,14 @@ static int bgmac_probe(struct platform_device *pdev)
> if (IS_ERR(bgmac->plat.idm_base))
> return PTR_ERR(bgmac->plat.idm_base);
>
> + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> + if (regs) {
> + bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> + regs);
> + if (IS_ERR(bgmac->plat.nicpm_base))
> + return PTR_ERR(bgmac->plat.nicpm_base);
> + }
> +
> bgmac->read = platform_bgmac_read;
> bgmac->write = platform_bgmac_write;
> bgmac->idm_read = platform_bgmac_idm_read;
> @@ -213,6 +272,7 @@ static int bgmac_remove(struct platform_device *pdev)
> static const struct of_device_id bgmac_of_enet_match[] = {
> {.compatible = "brcm,amac",},
> {.compatible = "brcm,nsp-amac",},
> + {.compatible = "brcm,ns2-amac",},
> {},
> };
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> index 38876ec..1796208 100644
> --- a/drivers/net/ethernet/broadcom/bgmac.c
> +++ b/drivers/net/ethernet/broadcom/bgmac.c
> @@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> static void bgmac_chip_init(struct bgmac *bgmac)
> {
> + /* Clear any erroneously pending interrupts */
> + bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> +
> /* 1 interrupt per received frame */
> bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
>
> @@ -1158,8 +1161,6 @@ static int bgmac_open(struct net_device *net_dev)
> struct bgmac *bgmac = netdev_priv(net_dev);
> int err = 0;
>
> - bgmac_chip_reset(bgmac);
> -
Is this removal intentional? Maybe it should be special cased with
checking for a NS2 BGMAC instance and not do it in that case?
--
Florian
^ permalink raw reply
* [PATCH V6 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Sinan Kaya @ 2016-10-26 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026214512.ofwbxnl2d46n6ef5@rob-hp-laptop>
On 10/26/2016 5:45 PM, Rob Herring wrote:
> On Wed, Oct 19, 2016 at 01:51:43PM -0400, Sinan Kaya wrote:
>> Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
>> MSI interrupts from the older revision.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> Please add acks when posting new versions.
>
Sure, sorry about that. Your acked version already got merged to Vinod's branch.
During the merge, Vinod got some merge conflicts for the remainder of the patches.
I was trying to post the remaining patches for Vinod to pick it up.
Apologies if it was not clear.
I posted V7 with only four remaining patches without the already merged
DT changes.
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2016-10-26 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7h1sz51y3p.fsf@baylibre.com>
On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Dave Gerlach <d-gerlach@ti.com> writes:
>
>> Hi,
>> On 10/21/2016 01:48 PM, Kevin Hilman wrote:
>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>
>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>> control device power states.
>>>>
>>>> Also, provide macros representing each device index as understood
>>>> by TI SCI to be used in the device node power-domain references.
>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>
>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>> ---
>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++
>>>> MAINTAINERS | 2 +
>>>> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
>>>> 3 files changed, 146 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>> new file mode 100644
>>>> index 000000000000..32f38a349656
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>> @@ -0,0 +1,54 @@
>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>> +---------------------------------------------
>>>> +
>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>>>> +responsible for controlling the state of the IPs that are present.
>>>> +Communication between the host processor running an OS and the system
>>>> +controller happens through a protocol known as TI-SCI [1]. This pm domain
>>>> +implementation plugs into the generic pm domain framework and makes use of
>>>> +the TI SCI protocol power on and off each device when needed.
>>>> +
>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>> +
>>>> +PM Domain Node
>>>> +==============
>>>> +The PM domain node represents the global PM domain managed by the PMMC,
>>>> +which in this case is the single implementation as documented by the generic
>>>> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
>>>> +
>>>> +Required Properties:
>>>> +--------------------
>>>> +- compatible: should be "ti,sci-pm-domain"
>>>> +- #power-domain-cells: Must be 0.
>>>> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
>>>>
>>>> +Example:
>>>> +--------------------
>>>> +k2g_pds: k2g_pds {
>>>
>>> should use generic name like "power-contoller", e.g. k2g_pds: power-controller
>>
>> Ok, that makes more sense.
>>
>>>
>>>> + compatible = "ti,sci-pm-domain";
>>>> + #power-domain-cells = <0>;
>>>> + ti,sci = <&pmmc>;
>>>> +};
>>>> +
>>>> +PM Domain Consumers
>>>> +===================
>>>> +Hardware blocks that require SCI control over their state must provide
>>>> +a reference to the sci-pm-domain they are part of and a unique device
>>>> +specific ID that identifies the device.
>>>> +
>>>> +Required Properties:
>>>> +--------------------
>>>> +- power-domains: phandle pointing to the corresponding PM domain node.
>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>>>> + be used for device control.
>>>
>>> This ID doesn't look right.
>>>
>>> Why not use #power-domain-cells = <1> and pass the index in the DT? ...
Exactly. ti,sci-id is a NAK for me.
>>>
>>>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
>>>> +
>>>> +Example:
>>>> +--------------------
>>>> +uart0: serial at 02530c00 {
>>>> + compatible = "ns16550a";
>>>> + ...
>>>> + power-domains = <&k2g_pds>;
>>>> + ti,sci-id = <K2G_DEV_UART0>;
>>>
>>> ... like this:
>>>
>>> power-domains = <&k2g_pds K2G_DEV_UART0>;
>>
>> That's how I did it in version one actually. I was able to define my
>> own xlate function to parse the phandle and get that index, but Ulf
>> pointed me to this series by Jon Hunter [1] that simplified genpd
>> providers and dropped the concept of adding your own xlate. This locks
>> the onecell approach to using a fixed static array of genpds that get
>> indexed into (without passing the index to the provider, just the
>> genpd that's looked up), which doesn't fit our usecase, as we don't
>> want a 1 to 1 genpd to device mapping based on the comments provided
>> in v1. Now we just use the genpd device attach/detach hooks to parse
>> the sci-id and then use it in the genpd device start/stop hooks.
I have no idea what any of this means. All sounds like driver
architecture, not anything to do with bindings.
>
> Ah, right. I remember now. This approach allows you to use a single
> genpd as discussed earlier.
>
> Makes sense now, suggestion retracted.
IIRC, the bindings in Jon's case had a node for each domain and didn't
need any additional property.
Rob
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Rob Herring @ 2016-10-26 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019203347.17893-3-d-gerlach@ti.com>
On Wed, Oct 19, 2016 at 03:33:45PM -0500, Dave Gerlach wrote:
> Add a generic power domain implementation, TI SCI PM Domains, that
> will hook into the genpd framework and allow the TI SCI protocol to
> control device power states.
>
> Also, provide macros representing each device index as understood
> by TI SCI to be used in the device node power-domain references.
> These are identifiers for the K2G devices managed by the PMMC.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
> 3 files changed, 146 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> create mode 100644 include/dt-bindings/genpd/k2g.h
>
> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> new file mode 100644
> index 000000000000..32f38a349656
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> @@ -0,0 +1,54 @@
> +Texas Instruments TI-SCI Generic Power Domain
> +---------------------------------------------
> +
> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
> +responsible for controlling the state of the IPs that are present.
> +Communication between the host processor running an OS and the system
> +controller happens through a protocol known as TI-SCI [1]. This pm domain
> +implementation plugs into the generic pm domain framework and makes use of
> +the TI SCI protocol power on and off each device when needed.
> +
> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +PM Domain Node
> +==============
> +The PM domain node represents the global PM domain managed by the PMMC,
> +which in this case is the single implementation as documented by the generic
> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> +
> +Required Properties:
> +--------------------
> +- compatible: should be "ti,sci-pm-domain"
> +- #power-domain-cells: Must be 0.
> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
> +
> +Example:
> +--------------------
> +k2g_pds: k2g_pds {
> + compatible = "ti,sci-pm-domain";
> + #power-domain-cells = <0>;
> + ti,sci = <&pmmc>;
> +};
Why not just make the PMMC node be the power-domain provider itself? If
not that, then make this a child node of it. The same comment applies to
all the SCI functions, but I guess I've already acked some of them.
I really don't like reviewing all these TI SCI bindings one by one. Each
one on its own seems fine, but I don't see the full picture.
Rob
^ permalink raw reply
* [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI
From: Leo Li @ 2016-10-26 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026103101.GC19965@leverpostej>
> -----Original Message-----
> From: Mark Rutland [mailto:mark.rutland at arm.com]
> Sent: Wednesday, October 26, 2016 5:31 AM
> To: M.H. Lian <minghuan.lian@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; Marc Zyngier <marc.zyngier@arm.com>; Stuart
> Yoder <stuart.yoder@nxp.com>; Leo Li <leoyang.li@nxp.com>; Scott Wood
> <scott.wood@nxp.com>; Shawn Guo <shawnguo@kernel.org>; Mingkai Hu
> <mingkai.hu@nxp.com>
> Subject: Re: [PATCH 1/6] dt/bindings: adjust bindings for Layerscape SCFG MSI
>
> On Tue, Oct 25, 2016 at 08:35:40PM +0800, Minghuan Lian wrote:
> > 1. The different version of a SoC may have different MSI
> > implementation. But compatible "fsl,<soc-name>-msi" can not describe
> > the SoC version.
>
> Surely, "fsl,<soc-name>-<rev>-msi" can describe this?
>
> If the hardware differs, it needs a new compatible string.
>
> If there's some configuration value that varies across revisions (e.g.
> number of slots), you can add a proeprty to describe that explciitly.
>
> > The MSI driver will use SoC match interface to get SoC type and
> > version instead of compatible string. So all MSI node can use the
> > common compatible "fsl,ls-scfg-msi" and the original compatible is
> > unnecessary.
> >
> > 2. Layerscape SoCs may have one or several MSI controllers.
> > In order to increase MSI interrupt number of a PCIe, the patch moves
> > all MSI node into the parent node "msi-controller". So a PCIe can
> > request MSI from all the MSI controllers.
>
> This is not necessary, and does not represent a real block of hardware.
> So NAK for this approach.
>
> The msi-parent property can contain a list of MSI controllers. See the examples
> in Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> Likewise, the msi-map property can map to a number of MSI controllers.
>
> If the core code can only consider one at a time, then that's an issue to be
> addressed in core code, not one to be bodged around in bindings.
>
> >
> > Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
> > ---
> > .../interrupt-controller/fsl,ls-scfg-msi.txt | 57 +++++++++++++++++++---
> > 1 file changed, 49 insertions(+), 8 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > index 9e38949..29f95fd 100644
> > ---
> > a/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-scfg-m
> > si.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,ls-sc
> > +++ fg-msi.txt
> > @@ -1,18 +1,28 @@
> > * Freescale Layerscape SCFG PCIe MSI controller
> >
> > +Layerscape SoCs may have one or multiple MSI controllers.
> > +Each MSI controller must be showed as a child node.
> > +
> > Required properties:
> >
> > -- compatible: should be "fsl,<soc-name>-msi" to identify
> > - Layerscape PCIe MSI controller block such as:
> > - "fsl,1s1021a-msi"
> > - "fsl,1s1043a-msi"
> > +- compatible: should be "fsl,ls-scfg-msi"
>
> This breaks old DTBs, and throws away information which you describe above as
> valuable. So another NAK for that.
I agree with you that we should maintain the backward compatibility. But on the other hand, I just found that there is a silly typo in the original binding that "ls" is wrongly spelled as "1s" and they look too close to be noticed in previous patch reviews. :( The driver and all the DTSes used the binding with the typo which covered up the problem. So even if we want to keep the "fsl,<soc-name>-msi" binding, we probably want to fix the typo, right? And that breaks the backward compatibility too.
Regards,
Leo
^ 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