* [PATCH V6 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Sinan Kaya @ 2016-10-20 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a4c95bd6-d760-1f02-bbb1-89538037d41e@codeaurora.org>
Hi Vinod,
On 10/20/2016 10:34 AM, Sinan Kaya wrote:
> On 10/20/2016 9:43 AM, Vinod Koul wrote:
>>> slave-dma git://git.infradead.org/users/vkoul/slave-dma.git (fetch)
>>>> slave-dma git://git.infradead.org/users/vkoul/slave-dma.git (push)
>> You seem to have missed topic/qcom which I pushed last night. next would have worked too!!
>>
>
> OK. Let me pick that up and test.
>
It looks like patches were applied out of order.
This is the post order
-rw-rw-r-- 1 okaya users 8176 Oct 20 17:44 0010-dmaengine-qcom_hidma-add-MSI-support-for-interrupts.patch
-rw-rw-r-- 1 okaya users 1175 Oct 20 17:44 0009-dmaengine-qcom_hidma-break-completion-processing-on-.patch
-rw-rw-r-- 1 okaya users 4773 Oct 20 17:44 0008-dmaengine-qcom_hidma-protect-common-data-structures.patch
-rw-rw-r-- 1 okaya users 2752 Oct 20 17:44 0007-dmaengine-qcom_hidma-add-a-common-API-to-setup-the-i.patch
-rw-rw-r-- 1 okaya users 3225 Oct 20 17:44 0006-dmaengine-qcom_hidma-bring-out-interrupt-cause.patch
-rw-rw-r-- 1 okaya users 4284 Oct 20 17:44 0005-dmaengine-qcom_hidma-make-pending_tre_count-atomic.patch
-rw-rw-r-- 1 okaya users 1090 Oct 20 17:44 0004-dmaengine-qcom_hidma-configure-DMA-and-MSI-for-OF.patch
-rw-rw-r-- 1 okaya users 959 Oct 20 17:44 0003-of-irq-make-of_msi_configure-accessible-from-modules.patch
-rw-rw-r-- 1 okaya users 1558 Oct 20 17:44 0002-Documentation-DT-qcom_hidma-correct-spelling-mistake.patch
-rw-rw-r-- 1 okaya users 1588 Oct 20 17:44 0001-Documentation-DT-qcom_hidma-update-binding-for-MSI.patch
This is the commit order in topic/dma branch. I added <<< for the patches missing below.
<<< 0010-dmaengine-qcom_hidma-add-MSI-support-for-interrupts.patch
<<< 0009-dmaengine-qcom_hidma-break-completion-processing-on-.patch
fc73796 dmaengine: qcom_hidma: break completion processing on error
<<< 0008-dmaengine-qcom_hidma-protect-common-data-structures.patch
d3eab50 dmaengine: qcom_hidma: add a common API to setup the interrupt
<<< 0006-dmaengine-qcom_hidma-bring-out-interrupt-cause.patch
<<< 0005-dmaengine-qcom_hidma-make-pending_tre_count-atomic.patch
9da0be8 dmaengine: qcom_hidma: configure DMA and MSI for OF
5282c18 of: irq: make of_msi_configure accessible from modules
13af1c8 Documentation: DT: qcom_hidma: correct spelling mistakes
ef6661b Documentation: DT: qcom_hidma: update binding for MSI
I also looked@the binary contents of the patches in topic/dma with what I posted
on v6. They match excluding your Signed off lines.
Sinan
--
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 3/4] arm64: dts: msm8996: Add SMEM DT nodes
From: Sarangdhar Joshi @ 2016-10-20 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020215137.GF3145@hector.attlocal.net>
On 10/20/2016 02:51 PM, Andy Gross wrote:
> On Thu, Oct 20, 2016 at 02:18:33PM -0700, Sarangdhar Joshi wrote:
>> On 10/20/2016 12:56 PM, Bjorn Andersson wrote:
>>> On Thu 20 Oct 11:56 PDT 2016, Sarangdhar Joshi wrote:
>>>
>>>> From: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>>
>>>> Add SMEM and TCSR DT nodes on MSM8996.
>>>>
>>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/msm8996.dtsi | 19 +++++++++++++++++++
>>>> 1 file changed, 19 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
>>>> index 949b096..0a810f5 100644
>>>> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
>>>> @@ -169,12 +169,31 @@
>>>> method = "smc";
>>>> };
>>>>
>>>> + smem {
>>>> + compatible = "qcom,smem";
>>>> +
>>>> + memory-region = <&smem_mem>;
>>>> +
>>>> + hwlocks = <&tcsr_mutex 3>;
>>>> + };
>>>> +
>>>> soc: soc {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> ranges = <0 0 0 0xffffffff>;
>>>> compatible = "simple-bus";
>>>>
>>>> + tcsr_mutex_regs: syscon at 740000 {
>>>> + compatible = "syscon";
>>>> + reg = <0x740000 0x20000>;
>>>> + };
>>>> +
>>>> + tcsr_mutex: hwlock {
>>>> + compatible = "qcom,tcsr-mutex";
>>>> + syscon = <&tcsr_mutex_regs 0 0x1000>;
>>>> + #hwlock-cells = <1>;
>>>> + };
>>>
>>> Sorry, I got this in the wrong place, the hwlock node should sit outside
>>> of soc {} - looks like we got this wrong in msm8916 as well.
>>
>> Thanks for reviewing the patch. Do you mean to move it under / {}; (i.e.
>> root)?
>
> Yes. Any node that doesn't have reg properties should go under the root.
>
Got it. Will update the patch(es) and add cover letter. Thanks.
>
> Andy
>
Regards,
Sarang
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V6 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Sinan Kaya @ 2016-10-20 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <37baf7db-1e14-4027-9397-70649e8fa946@codeaurora.org>
On 10/20/2016 2:55 PM, Sinan Kaya wrote:
> I also looked at the binary contents of the patches in topic/dma with what I posted
> on v6. They match excluding your Signed off lines.
Correction.
I checkout out topic/qcom not topic/dma from
git://git.infradead.org/users/vkoul/slave-dma.git
--
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] watchdog: meson: Remove unneeded platform MODULE_ALIAS
From: Guenter Roeck @ 2016-10-20 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476906582-14241-1-git-send-email-javier@osg.samsung.com>
On Wed, Oct 19, 2016 at 04:49:42PM -0300, Javier Martinez Canillas wrote:
> The Amlogic Meson is a DT-only platform, which means the devices are
> registered via OF and not using the legacy platform devices support.
>
> So there's no need to have a MODULE_ALIAS("platform:meson-gxbb-wdt")
> since the reported uevent MODALIAS to user-space will be the OF one.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* [PATCH v3 0/8] PM / Domains: DT support for domain idle states & atomic PM domains
From: Lina Iyer @ 2016-10-20 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFpQwOkXUk8wT6sZ-Ad4XpTnyodK5m24fYJ3P+1QtS0XOA@mail.gmail.com>
On Mon, Oct 17 2016 at 01:30 -0600, Ulf Hansson wrote:
>On 14 October 2016 at 19:47, Lina Iyer <lina.iyer@linaro.org> wrote:
>> Hi all,
>>
>> Changes since v2 [3] -
>> - Addressed review comments from v2.
>> - domain-idle-states documentation updated
>> - fixed compiler issues with imx driver
>> - minor code change in pm_domains.c
>> - The series is available at [4].
>>
>> Changes since v1 [2] -
>> - Addressed review comments from v1.
>> - Fixes around dynamic allocation of genpd states
>> - Used OF method for iterating phandles
>> - Updated documentation, examples
>> - Rename state variable (provider -> fwnode)
>> - The series is available at [3].
>>
>> The changes from [1] are -
>> - Allocating memory for domain idle states dynamically
>> - Conform to naming conventions for internal and exported genpd functions
>> - DT binding example for domain-idle-state
>> - Use fwnode instead of of_node
>> - Handle atomic case for removal of PM Domain
>> - Rebase on top of Rafael's pm/genpd tree
>>
>> Thanks,
>> Lina
>>
>> Lina Iyer (8):
>> PM / Domains: Make genpd state allocation dynamic
>> PM / Domain: Add residency property to genpd states
>> PM / Domains: Allow domain power states to be read from DT
>> PM / Domains: Save the fwnode in genpd_power_state
>> dt/bindings: Update binding for PM domain idle states
>> PM / Domains: Abstract genpd locking
>> PM / Domains: Support IRQ safe PM domains
>> PM / doc: Update device documentation for devices in IRQ safe PM
>> domains
>>
>> .../devicetree/bindings/power/power_domain.txt | 43 +++
>> Documentation/power/devices.txt | 9 +-
>> arch/arm/mach-imx/gpc.c | 17 +-
>> drivers/base/power/domain.c | 358 +++++++++++++++++----
>> include/linux/pm_domain.h | 28 +-
>> 5 files changed, 383 insertions(+), 72 deletions(-)
>>
>
>Rafael, Lina,
>
>This looks good to me! Unless any other objections, I suggest to apply
>this to get it tested in linux-next.
>
>Kind regards
>Uffe
>
Rafael,
If there are no objections, could you pick this patch for linux-next?
Thanks,
Lina
>> --
>> 2.7.4
>>
>> [1]. https://www.spinics.net/lists/arm-kernel/msg526814.html
>> [2]. http://www.spinics.net/lists/arm-kernel/msg535106.html
>> [3]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-v2
>> [4]. https://git.linaro.org/people/lina.iyer/linux-next.git/shortlog/refs/heads/genpd-v3
^ permalink raw reply
* [PATCH v3 3/6] pwm: imx: support output polarity inversion
From: Stefan Agner @ 2016-10-20 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020103018.44fb94ea@jawa>
On 2016-10-20 01:30, Lukasz Majewski wrote:
> Hi Stefan,
>
>> Hi Stefan,
>>
>> > On 2016-10-12 15:15, Lukasz Majewski wrote:
>> > > Hi Stefan,
>> > >
>> > >> On 2016-10-07 08:11, Bhuvanchandra DV wrote:
>> > >> > From: Lothar Wassmann <LW@KARO-electronics.de>
>> > >> >
>> > >> > The i.MX pwm unit on i.MX27 and newer SoCs provides a
>> > >> > configurable output polarity. This patch adds support to
>> > >> > utilize this feature where available.
>> > >> >
>> > >> > Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
>> > >> > Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
>> > >> > Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
>> > >> > Acked-by: Shawn Guo <shawn.guo@linaro.org>
>> > >> > Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
>> > >> > ---
>> > >> > Documentation/devicetree/bindings/pwm/imx-pwm.txt | 6 +--
>> > >> > drivers/pwm/pwm-imx.c | 51
>> > >> > +++++++++++++++++++++-- 2 files changed, 51 insertions(+), 6
>> > >> > deletions(-)
>> > >> >
>> > >> > diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
>> > >> > b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
>> > >> > index e00c2e9..c61bdf8 100644
>> > >> > --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
>> > >> > +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
>> > >> > @@ -6,8 +6,8 @@ Required properties:
>> > >> > - "fsl,imx1-pwm" for PWM compatible with the one integrated
>> > >> > on i.MX1
>> > >> > - "fsl,imx27-pwm" for PWM compatible with the one integrated
>> > >> > on i.MX27
>> > >> > - reg: physical base address and length of the controller's
>> > >> > registers -- #pwm-cells: should be 2. See pwm.txt in this
>> > >> > directory for a description of
>> > >> > - the cells format.
>> > >> > +- #pwm-cells: 2 for i.MX1 and 3 for i.MX27 and newer SoCs. See
>> > >> > pwm.txt
>> > >> > + in this directory for a description of the cells format.
>> > >> > - clocks : Clock specifiers for both ipg and per clocks.
>> > >> > - clock-names : Clock names should include both "ipg" and
>> > >> > "per" See the clock consumer binding,
>> > >> > @@ -17,7 +17,7 @@ See the clock consumer binding,
>> > >> > Example:
>> > >> >
>> > >> > pwm1: pwm at 53fb4000 {
>> > >> > - #pwm-cells = <2>;
>> > >> > + #pwm-cells = <3>;
>> > >> > compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
>> > >> > reg = <0x53fb4000 0x4000>;
>> > >> > clocks = <&clks IMX5_CLK_PWM1_IPG_GATE>,
>> > >> > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
>> > >> > index d600fd5..c37d223 100644
>> > >> > --- a/drivers/pwm/pwm-imx.c
>> > >> > +++ b/drivers/pwm/pwm-imx.c
>> > >> > @@ -38,6 +38,7 @@
>> > >> > #define MX3_PWMCR_DOZEEN (1 << 24)
>> > >> > #define MX3_PWMCR_WAITEN (1 << 23)
>> > >> > #define MX3_PWMCR_DBGEN (1 << 22)
>> > >> > +#define MX3_PWMCR_POUTC (1 << 18)
>> > >> > #define MX3_PWMCR_CLKSRC_IPG_HIGH (2 << 16)
>> > >> > #define MX3_PWMCR_CLKSRC_IPG (1 << 16)
>> > >> > #define MX3_PWMCR_SWR (1 << 3)
>> > >> > @@ -180,6 +181,9 @@ static int imx_pwm_config_v2(struct
>> > >> > pwm_chip *chip, if (enable)
>> > >> > cr |= MX3_PWMCR_EN;
>> > >> >
>> > >> > + if (pwm->args.polarity == PWM_POLARITY_INVERSED)
>> > >> > + cr |= MX3_PWMCR_POUTC;
>> > >> > +
>> > >>
>> > >> This seems wrong to me, the config callback is meant for
>> > >> period/duty cycle only.
>
> Unfortunately, it also resets the PWM IP block and setups it again (by
> writing to PWMCR register). In that function we setup for example
> MX3_PWMCR_DOZEEN
> and MX3_PWMCR_DBGEN. Why cannot we setup polarity as well?
>
>
> I've double checked the backlight and pwm code flow.
>
> Please find following snippet:
>
> [ 0.135545] ######### imx_pwm_probe
> [ 0.135581] PWM supports output inversion
> [ 0.136864] ######### pwm_backlight_probe
> [ 0.136913] backlight supply power not found, using dummy regulator
> [ 0.136984] ######### imx_pwm_set_polarity 1
> [ 0.136995] imx_pwm_set_polarity: polarity set to inverted cr:
> 0x40000 0xf08f8000
> [ 0.137005] #########0 imx_pwm_config_v2 cr: 0x40000
> [ 0.137683] #########1 imx_pwm_config_v2 cr: 0x0 0xf08f8000
> [ 0.137693] #########2 imx_pwm_config_v2 cr: 0x1c20050
> [ 0.137702] #########3 imx_pwm_config_v2 cr: 0x1c20050 0xf08f8000
> [ 0.137711] @@@@@@@@@@ pwm_apply_state
>
> Here the pwm_backlight_probe calls set_polarity callback available in
> pwm - the polarity is set (the 0x40000 value).
>
> The above operation is performed in pwm_apply_state (@ drivers/pwm/core.c).
> In the same function, latter we call the pwm->chip->ops->config(), which is the
> pointer to config_v2.
> Since the PWM is not yet enabled, this function performs SW reset and
> PWM inversion setting is cleared.
That function should not do that. It was probably already problematic in
the old times, it is definitely now with the atomic PWM stuff.
>
> Possible solutions:
>
> 1. Leave the original patch from Bhuvanchandra as it was (I'm for this
> option)
That really seems like a hack to me, and makes transition to the atomic
PWM API more complex.
If we can't make it happen properly in the current state of affairs, we
probably should first move to the atomic API.
It really should not be that hard, since we already do almost everything
in one function (imx_pwm_config_v2). We probably can almost just assign
that function to the new apply function pointer and read information
from the new state struct.
There are examples for instance here:
https://patchwork.kernel.org/patch/7228221/
--
Stefan
>
> 2. Enable early PWM (in core, or in bl driver) so the config_v2 is not
> calling SW reset on the PWM. (but this solutions seems _really_ bad to me)
>
> 3. Perform defer probe of pwm backlight driver (pwm_bl.c) until the pwm
> is fully configured (it might be a bit tricky).
>
>
> Best regards,
> ?ukasz Majewski
>
>> > >
>> > > If it is meant only for that, then the polarity should be removed
>> > > from it.
>> > >
>> > > However after very quick testing, at least on my setup, it turns
>> > > out that removing this lines causes polarity to _not_ being set
>> > > (and the polarity is not inverted).
>> > >
>> > > I will investigate this further on my setup and hopefully sent
>> > > proper patch.
>> > >
>> > >> The set_polarity callback should get called in case a
>> > >> different polarity is requested.
>> > >
>> > > On my setup the pwm2 is set from DT and pwm_backlight_probe()
>> > > calls pwm_apply_args(), so everything should work. However, as I
>> > > mentioned above there still is some problem with inversion
>> > > setting.
>> > >
>> > >>
>> > >>
>> > >> > writel(cr, imx->mmio_base + MX3_PWMCR);
>> > >> >
>> > >> > return 0;
>> > >> > @@ -240,27 +244,62 @@ static void imx_pwm_disable(struct
>> > >> > pwm_chip *chip, struct pwm_device *pwm)
>> > >> > clk_disable_unprepare(imx->clk_per);
>> > >> > }
>> > >> >
>> > >> > -static struct pwm_ops imx_pwm_ops = {
>> > >> > +static int imx_pwm_set_polarity(struct pwm_chip *chip, struct
>> > >> > pwm_device *pwm,
>> > >> > + enum pwm_polarity polarity)
>> > >> > +{
>> > >> > + struct imx_chip *imx = to_imx_chip(chip);
>> > >> > + u32 val;
>> > >> > +
>> > >> > + if (polarity == pwm->args.polarity)
>> > >> > + return 0;
>> > >>
>> > >> I don't think that this is right. Today, pwm_apply_args (in
>> > >> include/linux/pwm.h) copies the polarity from args to
>> > >> state.polarity, which is then passed as polarity argument to this
>> > >> function. So this will always return 0 afaict.
>> > >
>> > > Yes, I've overlooked it (that the state is copied).
>> > >
>> > > It can be dropped.
>> >
>> > Did you do the above test with that line dropped?
>>
>> Yes. The above code has been also removed.
>>
>> Best regards,
>> ?ukasz Majewski
>>
>> >
>> > >
>> > >>
>> > >> I would just drop that.
>> > >>
>> > >> There is probably one little problem in the current state of
>> > >> affairs: If the bootloader makes use of a PWM channel with
>> > >> inverted state, then the kernel would not know about that and
>> > >> currently assume a wrong initial state... I guess at one point in
>> > >> time we should implement the state retrieval callback and move to
>> > >> the new atomic PWM API, which would mean to implement apply
>> > >> callback.
>> > >
>> > > Are there any patches on the horizon?
>> > >
>> >
>> > Not that I know of...
>> >
>> > --
>> > Stefan
>> >
>> > >>
>> > >> --
>> > >> Stefan
>> > >>
>> > >>
>> > >> > +
>> > >> > + val = readl(imx->mmio_base + MX3_PWMCR);
>> > >> > +
>> > >> > + if (polarity == PWM_POLARITY_INVERSED)
>> > >> > + val |= MX3_PWMCR_POUTC;
>> > >> > + else
>> > >> > + val &= ~MX3_PWMCR_POUTC;
>> > >> > +
>> > >> > + writel(val, imx->mmio_base + MX3_PWMCR);
>> > >> > +
>> > >> > + dev_dbg(imx->chip.dev, "%s: polarity set to %s\n",
>> > >> > __func__,
>> > >> > + polarity == PWM_POLARITY_INVERSED ?
>> > >> > "inverted" : "normal"); +
>> > >> > + return 0;
>> > >> > +}
>> > >> > +
>> > >> > +static struct pwm_ops imx_pwm_ops_v1 = {
>> > >> > .enable = imx_pwm_enable,
>> > >> > .disable = imx_pwm_disable,
>> > >> > .config = imx_pwm_config,
>> > >> > .owner = THIS_MODULE,
>> > >> > };
>> > >> >
>> > >> > +static struct pwm_ops imx_pwm_ops_v2 = {
>> > >> > + .enable = imx_pwm_enable,
>> > >> > + .disable = imx_pwm_disable,
>> > >> > + .set_polarity = imx_pwm_set_polarity,
>> > >> > + .config = imx_pwm_config,
>> > >> > + .owner = THIS_MODULE,
>> > >> > +};
>> > >> > +
>> > >> > struct imx_pwm_data {
>> > >> > int (*config)(struct pwm_chip *chip,
>> > >> > struct pwm_device *pwm, int duty_ns, int
>> > >> > period_ns); void (*set_enable)(struct pwm_chip *chip, bool
>> > >> > enable);
>> > >> > + struct pwm_ops *pwm_ops;
>> > >> > };
>> > >> >
>> > >> > static struct imx_pwm_data imx_pwm_data_v1 = {
>> > >> > .config = imx_pwm_config_v1,
>> > >> > .set_enable = imx_pwm_set_enable_v1,
>> > >> > + .pwm_ops = &imx_pwm_ops_v1,
>> > >> > };
>> > >> >
>> > >> > static struct imx_pwm_data imx_pwm_data_v2 = {
>> > >> > .config = imx_pwm_config_v2,
>> > >> > .set_enable = imx_pwm_set_enable_v2,
>> > >> > + .pwm_ops = &imx_pwm_ops_v2,
>> > >> > };
>> > >> >
>> > >> > static const struct of_device_id imx_pwm_dt_ids[] = {
>> > >> > @@ -282,6 +321,8 @@ static int imx_pwm_probe(struct
>> > >> > platform_device *pdev) if (!of_id)
>> > >> > return -ENODEV;
>> > >> >
>> > >> > + data = of_id->data;
>> > >> > +
>> > >> > imx = devm_kzalloc(&pdev->dev, sizeof(*imx),
>> > >> > GFP_KERNEL); if (imx == NULL)
>> > >> > return -ENOMEM;
>> > >> > @@ -300,18 +341,22 @@ static int imx_pwm_probe(struct
>> > >> > platform_device *pdev) return PTR_ERR(imx->clk_ipg);
>> > >> > }
>> > >> >
>> > >> > - imx->chip.ops = &imx_pwm_ops;
>> > >> > + imx->chip.ops = data->pwm_ops;
>> > >> > imx->chip.dev = &pdev->dev;
>> > >> > imx->chip.base = -1;
>> > >> > imx->chip.npwm = 1;
>> > >> > imx->chip.can_sleep = true;
>> > >> > + if (data->pwm_ops->set_polarity) {
>> > >> > + dev_dbg(&pdev->dev, "PWM supports output
>> > >> > inversion\n");
>> > >> > + imx->chip.of_xlate = of_pwm_xlate_with_flags;
>> > >> > + imx->chip.of_pwm_n_cells = 3;
>> > >> > + }
>> > >> >
>> > >> > r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> > >> > imx->mmio_base = devm_ioremap_resource(&pdev->dev, r);
>> > >> > if (IS_ERR(imx->mmio_base))
>> > >> > return PTR_ERR(imx->mmio_base);
>> > >> >
>> > >> > - data = of_id->data;
>> > >> > imx->config = data->config;
>> > >> > imx->set_enable = data->set_enable;
>> > >>
>> > >
>> > > Best regards,
>> > >
>> > > ?ukasz Majewski
>>
^ permalink raw reply
* [PATCH v3 0/8] PM / Domains: DT support for domain idle states & atomic PM domains
From: Rafael J. Wysocki @ 2016-10-20 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020224432.GB72940@linaro.org>
On Fri, Oct 21, 2016 at 12:44 AM, Lina Iyer <lina.iyer@linaro.org> wrote:
> On Mon, Oct 17 2016 at 01:30 -0600, Ulf Hansson wrote:
>>
>> On 14 October 2016 at 19:47, Lina Iyer <lina.iyer@linaro.org> wrote:
>>>
>>> Hi all,
>>>
>>> Changes since v2 [3] -
>>> - Addressed review comments from v2.
>>> - domain-idle-states documentation updated
>>> - fixed compiler issues with imx driver
>>> - minor code change in pm_domains.c
>>> - The series is available at [4].
>>>
>>> Changes since v1 [2] -
>>> - Addressed review comments from v1.
>>> - Fixes around dynamic allocation of genpd states
>>> - Used OF method for iterating phandles
>>> - Updated documentation, examples
>>> - Rename state variable (provider -> fwnode)
>>> - The series is available at [3].
>>>
>>> The changes from [1] are -
>>> - Allocating memory for domain idle states dynamically
>>> - Conform to naming conventions for internal and exported genpd functions
>>> - DT binding example for domain-idle-state
>>> - Use fwnode instead of of_node
>>> - Handle atomic case for removal of PM Domain
>>> - Rebase on top of Rafael's pm/genpd tree
>>>
>>> Thanks,
>>> Lina
>>>
>>> Lina Iyer (8):
>>> PM / Domains: Make genpd state allocation dynamic
>>> PM / Domain: Add residency property to genpd states
>>> PM / Domains: Allow domain power states to be read from DT
>>> PM / Domains: Save the fwnode in genpd_power_state
>>> dt/bindings: Update binding for PM domain idle states
>>> PM / Domains: Abstract genpd locking
>>> PM / Domains: Support IRQ safe PM domains
>>> PM / doc: Update device documentation for devices in IRQ safe PM
>>> domains
>>>
>>> .../devicetree/bindings/power/power_domain.txt | 43 +++
>>> Documentation/power/devices.txt | 9 +-
>>> arch/arm/mach-imx/gpc.c | 17 +-
>>> drivers/base/power/domain.c | 358
>>> +++++++++++++++++----
>>> include/linux/pm_domain.h | 28 +-
>>> 5 files changed, 383 insertions(+), 72 deletions(-)
>>>
>>
>> Rafael, Lina,
>>
>> This looks good to me! Unless any other objections, I suggest to apply
>> this to get it tested in linux-next.
>>
>> Kind regards
>> Uffe
>>
> Rafael,
>
> If there are no objections, could you pick this patch for linux-next?
It is in my queue, but not at the top yet.
Thanks,
Rafael
^ permalink raw reply
* [PATCH v2 0/4] MSM8996 DT Support for ADSP PIL
From: Sarangdhar Joshi @ 2016-10-20 23:12 UTC (permalink / raw)
To: linux-arm-kernel
Add various device tree nodes to lay the groundwork for
Qualcomm ADSP Peripheral Image Loader.
Sorry, I didn't send any cover letter for v1.
Changes since v1:
- Move hwlock DT node under root (/) (Bjorn and Andy)
- Rename smp2p-adsp to adsp-smp2p (Bjorn)
- Remove interrupt-parent property from node (Bjorn)
Bjorn Andersson (1):
arm64: dts: msm8996: Add SMEM DT nodes
Sarangdhar Joshi (3):
arm64: dts: msm8996: Add SMEM reserve-memory node
arm64: dts: msm8996: Add reserve-memory nodes
arm64: dts: msm8996: Add SMP2P and APCS nodes
arch/arm64/boot/dts/qcom/msm8996.dtsi | 84 +++++++++++++++++++++++++++++++++++
1 file changed, 84 insertions(+)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 1/4] arm64: dts: msm8996: Add SMEM reserve-memory node
From: Sarangdhar Joshi @ 2016-10-20 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477005139-15564-1-git-send-email-spjoshi@codeaurora.org>
Add DT node to carveout memory for shared memory region.
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index d6da223..36216ae 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -31,6 +31,17 @@
reg = <0 0 0 0>;
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ smem_mem: smem-mem at 86000000 {
+ reg = <0x0 0x86000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <2>;
#size-cells = <0>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v2 2/4] arm64: dts: msm8996: Add reserve-memory nodes
From: Sarangdhar Joshi @ 2016-10-20 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477005139-15564-1-git-send-email-spjoshi@codeaurora.org>
Add reserve-memory nodes required for Qualcomm
Peripheral Image Loaders
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 36216ae..949b096 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -36,6 +36,31 @@
#size-cells = <2>;
ranges;
+ mba_region: mba at 91500000 {
+ reg = <0x0 0x91500000 0x0 0x200000>;
+ no-map;
+ };
+
+ slpi_region: slpi at 90b00000 {
+ reg = <0x0 0x90b00000 0xa00000>;
+ no-map;
+ };
+
+ venus_region: venus at 90400000 {
+ reg = <0x0 0x90400000 0x0 0x700000>;
+ no-map;
+ };
+
+ adsp_region: adsp at 8ea00000 {
+ reg = <0x0 0x8ea00000 0x0 0x1a00000>;
+ no-map;
+ };
+
+ mpss_region: mpss at 88800000 {
+ reg = <0x0 0x88800000 0x0 0x6200000>;
+ no-map;
+ };
+
smem_mem: smem-mem at 86000000 {
reg = <0x0 0x86000000 0x0 0x200000>;
no-map;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v2 3/4] arm64: dts: msm8996: Add SMEM DT nodes
From: Sarangdhar Joshi @ 2016-10-20 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477005139-15564-1-git-send-email-spjoshi@codeaurora.org>
From: Bjorn Andersson <bjorn.andersson@linaro.org>
Add SMEM and TCSR DT nodes on MSM8996.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 949b096..abc1089 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -164,17 +164,36 @@
};
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_regs 0 0x1000>;
+ #hwlock-cells = <1>;
+ };
+
psci {
compatible = "arm,psci-1.0";
method = "smc";
};
+ smem {
+ compatible = "qcom,smem";
+
+ memory-region = <&smem_mem>;
+
+ hwlocks = <&tcsr_mutex 3>;
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0 0xffffffff>;
compatible = "simple-bus";
+ tcsr_mutex_regs: syscon at 740000 {
+ compatible = "syscon";
+ reg = <0x740000 0x20000>;
+ };
+
intc: interrupt-controller at 9bc0000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v2 4/4] arm64: dts: msm8996: Add SMP2P and APCS nodes
From: Sarangdhar Joshi @ 2016-10-20 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477005139-15564-1-git-send-email-spjoshi@codeaurora.org>
Add SMP2P and APCS DT nodes required for Qualcomm ADSP
Peripheral Image Loader.
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index abc1089..26c4827 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -175,6 +175,30 @@
method = "smc";
};
+ adsp-smp2p {
+ compatible = "qcom,smp2p";
+ qcom,smem = <443>, <429>;
+
+ interrupts = <0 158 IRQ_TYPE_EDGE_RISING>;
+
+ qcom,ipc = <&apcs 16 10>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <2>;
+
+ adsp_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,state-cells = <1>;
+ };
+
+ adsp_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
smem {
compatible = "qcom,smem";
@@ -205,6 +229,11 @@
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
+ apcs: syscon at 9820000 {
+ compatible = "syscon";
+ reg = <0x9820000 0x1000>;
+ };
+
gcc: clock-controller at 300000 {
compatible = "qcom,gcc-msm8996";
#clock-cells = <1>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH] drm: convert DT component matching to component_match_add_release()
From: Sean Paul @ 2016-10-20 23:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020215022.GZ1041@n2100.armlinux.org.uk>
On Thu, Oct 20, 2016 at 5:50 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Oct 20, 2016 at 04:39:04PM -0400, Sean Paul wrote:
>> On Wed, Oct 19, 2016 at 6:28 AM, Russell King
>> <rmk+kernel@armlinux.org.uk> wrote:
>> > Convert DT component matching to use component_match_add_release().
>> >
>> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>> > ---
>> > Can we please get this patch from May merged into the drm-misc or
>> > whatever trees so that we don't end up with conflicts? I've no idea
>> > who looks after drm-misc, as they have _still_ failed to add
>> > themselves to MAINTAINERS.
>>
>> I think Daniel explained pretty clearly why this wasn't happening in
>> the previous thread.
>>
>> Next time you send a v2, can you please mark it as such and include a
>> "Changes in v2" section?
>
> Why - nothing's changed other than a rebase onto 4.9-rc1. This isn't
> a "I've changed it in XYZ way, so here's a new copy".
Changes in v2: None
Is still useful since:
a) the diffstat is different from v1, which necessitates me going
through both versions to see what's changed from the previous reviews
(only to find out myself that it's been rebased and a function has
changed names)
b) in June, you said you were going to roll a new version with the
common OF bits extracted. it's nice to know at the outset that this
has/hasn't happened
Also, prefacing the subject with [PATCH v2] or [PATCH RESEND] lets me
know there is prior history with the change. Reading the previous
version is helpful to see what reviewer's concerns were, and whether
they've been addressed.
> It's being
> posted in the hope that someone will finally either comment on it or
> merge the damn thing, rather than ignoring it was done when it was
> last posted.
>
>> > drivers/gpu/drm/arm/hdlcd_drv.c | 3 ++-
>> > drivers/gpu/drm/arm/malidp_drv.c | 4 +++-
>> > drivers/gpu/drm/armada/armada_drv.c | 2 +-
>> > drivers/gpu/drm/drm_of.c | 28 +++++++++++++++++++++++--
>> > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 5 +++--
>> > drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 7 ++++---
>> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +++-
>> > drivers/gpu/drm/msm/msm_drv.c | 12 ++++++-----
>> > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++++--
>> > drivers/gpu/drm/sti/sti_drv.c | 5 +++--
>> > drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++-
>> > drivers/gpu/drm/tilcdc/tilcdc_external.c | 4 +++-
>> > include/drm/drm_of.h | 12 +++++++++++
>> > 13 files changed, 73 insertions(+), 22 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
>> > index fb6a418ce6be..6477d1a65266 100644
>> > --- a/drivers/gpu/drm/arm/hdlcd_drv.c
>> > +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
>> > @@ -453,7 +453,8 @@ static int hdlcd_probe(struct platform_device *pdev)
>> > return -EAGAIN;
>> > }
>> >
>> > - component_match_add(&pdev->dev, &match, compare_dev, port);
>> > + drm_of_component_match_add(&pdev->dev, &match, compare_dev, port);
>> > + of_node_put(port);
>>
>> There's no mention in your commit message about fixing these node leaks.
>
> Isn't that kind-of the whole point of this patch?
>
Not according to the commit msg, it isn't.
You could have just done the of_node_put adds/relocations without
wrapping component_match_add_release.
Sean
>> >
>> > return component_master_add_with_match(&pdev->dev, &hdlcd_master_ops,
>> > match);
>> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
>> > index 9280358b8f15..9f4739452a25 100644
>> > --- a/drivers/gpu/drm/arm/malidp_drv.c
>> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
>> > @@ -493,7 +493,9 @@ static int malidp_platform_probe(struct platform_device *pdev)
>> > return -EAGAIN;
>> > }
>> >
>> > - component_match_add(&pdev->dev, &match, malidp_compare_dev, port);
>> > + drm_of_component_match_add(&pdev->dev, &match, malidp_compare_dev,
>> > + port);
>> > + of_node_put(port);
>> > return component_master_add_with_match(&pdev->dev, &malidp_master_ops,
>> > match);
>> > }
>> > diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
>> > index 1e0e68f608e4..94e46da9a758 100644
>> > --- a/drivers/gpu/drm/armada/armada_drv.c
>> > +++ b/drivers/gpu/drm/armada/armada_drv.c
>> > @@ -254,7 +254,7 @@ static void armada_add_endpoints(struct device *dev,
>> > continue;
>> > }
>> >
>> > - component_match_add(dev, match, compare_of, remote);
>> > + drm_of_component_match_add(dev, match, compare_of, remote);
>> > of_node_put(remote);
>> > }
>> > }
>> > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
>> > index bc98bb94264d..47848ed8ca48 100644
>> > --- a/drivers/gpu/drm/drm_of.c
>> > +++ b/drivers/gpu/drm/drm_of.c
>> > @@ -6,6 +6,11 @@
>> > #include <drm/drm_crtc.h>
>> > #include <drm/drm_of.h>
>> >
>> > +static void drm_release_of(struct device *dev, void *data)
>> > +{
>> > + of_node_put(data);
>> > +}
>> > +
>> > /**
>> > * drm_crtc_port_mask - find the mask of a registered CRTC by port OF node
>> > * @dev: DRM device
>> > @@ -64,6 +69,24 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>> > EXPORT_SYMBOL(drm_of_find_possible_crtcs);
>> >
>> > /**
>> > + * drm_of_component_match_add - Add a component helper OF node match rule
>> > + * @master: master device
>> > + * @matchptr: component match pointer
>> > + * @compare: compare function used for matching component
>> > + * @node: of_node
>> > + */
>> > +void drm_of_component_match_add(struct device *master,
>> > + struct component_match **matchptr,
>> > + int (*compare)(struct device *, void *),
>> > + struct device_node *node)
>> > +{
>> > + of_node_get(node);
>> > + component_match_add_release(master, matchptr, drm_release_of,
>> > + compare, node);
>> > +}
>> > +EXPORT_SYMBOL_GPL(drm_of_component_match_add);
>> > +
>> > +/**
>> > * drm_of_component_probe - Generic probe function for a component based master
>> > * @dev: master device containing the OF node
>> > * @compare_of: compare function used for matching components
>> > @@ -101,7 +124,7 @@ int drm_of_component_probe(struct device *dev,
>> > continue;
>> > }
>> >
>> > - component_match_add(dev, &match, compare_of, port);
>> > + drm_of_component_match_add(dev, &match, compare_of, port);
>> > of_node_put(port);
>> > }
>> >
>> > @@ -140,7 +163,8 @@ int drm_of_component_probe(struct device *dev,
>> > continue;
>> > }
>> >
>> > - component_match_add(dev, &match, compare_of, remote);
>> > + drm_of_component_match_add(dev, &match, compare_of,
>> > + remote);
>> > of_node_put(remote);
>> > }
>> > of_node_put(port);
>> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > index aa687669e22b..0dee6acbd880 100644
>> > --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > @@ -16,6 +16,7 @@
>> >
>> > #include <linux/component.h>
>> > #include <linux/of_platform.h>
>> > +#include <drm/drm_of.h>
>> >
>> > #include "etnaviv_drv.h"
>> > #include "etnaviv_gpu.h"
>> > @@ -629,8 +630,8 @@ static int etnaviv_pdev_probe(struct platform_device *pdev)
>> > if (!core_node)
>> > break;
>> >
>> > - component_match_add(&pdev->dev, &match, compare_of,
>> > - core_node);
>> > + drm_of_component_match_add(&pdev->dev, &match,
>> > + compare_of, core_node);
>> > of_node_put(core_node);
>> > }
>> > } else if (dev->platform_data) {
>> > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> > index 90377a609c98..e88fde18c946 100644
>> > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
>> > @@ -24,6 +24,7 @@
>> > #include <drm/drm_fb_cma_helper.h>
>> > #include <drm/drm_atomic_helper.h>
>> > #include <drm/drm_crtc_helper.h>
>> > +#include <drm/drm_of.h>
>> >
>> > #include "kirin_drm_drv.h"
>> >
>> > @@ -260,14 +261,13 @@ static struct device_node *kirin_get_remote_node(struct device_node *np)
>> > DRM_ERROR("no valid endpoint node\n");
>> > return ERR_PTR(-ENODEV);
>> > }
>> > - of_node_put(endpoint);
>> >
>> > remote = of_graph_get_remote_port_parent(endpoint);
>> > + of_node_put(endpoint);
>>
>> Another bug that's being fixed without mention in the commit.
>>
>> > if (!remote) {
>> > DRM_ERROR("no valid remote node\n");
>> > return ERR_PTR(-ENODEV);
>> > }
>> > - of_node_put(remote);
>> >
>> > if (!of_device_is_available(remote)) {
>> > DRM_ERROR("not available for remote node\n");
>> > @@ -294,7 +294,8 @@ static int kirin_drm_platform_probe(struct platform_device *pdev)
>> > if (IS_ERR(remote))
>> > return PTR_ERR(remote);
>> >
>> > - component_match_add(dev, &match, compare_of, remote);
>> > + drm_of_component_match_add(dev, &match, compare_of, remote);
>> > + of_node_put(remote);
>> >
>> > return component_master_add_with_match(dev, &kirin_drm_ops, match);
>> >
>> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> > index cf83f6507ec8..9c5430fb82a2 100644
>> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>> > @@ -18,6 +18,7 @@
>> > #include <drm/drm_crtc_helper.h>
>> > #include <drm/drm_gem.h>
>> > #include <drm/drm_gem_cma_helper.h>
>> > +#include <drm/drm_of.h>
>> > #include <linux/component.h>
>> > #include <linux/iommu.h>
>> > #include <linux/of_address.h>
>> > @@ -415,7 +416,8 @@ static int mtk_drm_probe(struct platform_device *pdev)
>> > comp_type == MTK_DPI) {
>> > dev_info(dev, "Adding component match for %s\n",
>> > node->full_name);
>> > - component_match_add(dev, &match, compare_of, node);
>> > + drm_of_component_match_add(dev, &match, compare_of,
>> > + node);
>> > } else {
>> > struct mtk_ddp_comp *comp;
>> >
>> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
>> > index fb5c0b0a7594..84d38eaea585 100644
>> > --- a/drivers/gpu/drm/msm/msm_drv.c
>> > +++ b/drivers/gpu/drm/msm/msm_drv.c
>> > @@ -15,6 +15,8 @@
>> > * this program. If not, see <http://www.gnu.org/licenses/>.
>> > */
>> >
>> > +#include <drm/drm_of.h>
>> > +
>> > #include "msm_drv.h"
>> > #include "msm_debugfs.h"
>> > #include "msm_fence.h"
>> > @@ -919,8 +921,8 @@ static int add_components_mdp(struct device *mdp_dev,
>> > continue;
>> > }
>> >
>> > - component_match_add(master_dev, matchptr, compare_of, intf);
>> > -
>> > + drm_of_component_match_add(master_dev, matchptr, compare_of,
>> > + intf);
>> > of_node_put(intf);
>> > of_node_put(ep_node);
>> > }
>> > @@ -962,8 +964,8 @@ static int add_display_components(struct device *dev,
>> > put_device(mdp_dev);
>> >
>> > /* add the MDP component itself */
>> > - component_match_add(dev, matchptr, compare_of,
>> > - mdp_dev->of_node);
>> > + drm_of_component_match_add(dev, matchptr, compare_of,
>> > + mdp_dev->of_node);
>> > } else {
>> > /* MDP4 */
>> > mdp_dev = dev;
>> > @@ -996,7 +998,7 @@ static int add_gpu_components(struct device *dev,
>> > if (!np)
>> > return 0;
>> >
>> > - component_match_add(dev, matchptr, compare_of, np);
>> > + drm_of_component_match_add(dev, matchptr, compare_of, np);
>> >
>> > of_node_put(np);
>> >
>> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>> > index 8c8cbe837e61..6fe161192bb4 100644
>> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>> > @@ -20,6 +20,7 @@
>> > #include <drm/drm_crtc_helper.h>
>> > #include <drm/drm_fb_helper.h>
>> > #include <drm/drm_gem_cma_helper.h>
>> > +#include <drm/drm_of.h>
>> > #include <linux/dma-mapping.h>
>> > #include <linux/pm_runtime.h>
>> > #include <linux/module.h>
>> > @@ -388,7 +389,7 @@ static void rockchip_add_endpoints(struct device *dev,
>> > continue;
>> > }
>> >
>> > - component_match_add(dev, match, compare_of, remote);
>> > + drm_of_component_match_add(dev, match, compare_of, remote);
>> > of_node_put(remote);
>> > }
>> > }
>> > @@ -437,7 +438,8 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
>> > }
>> >
>> > of_node_put(iommu);
>> > - component_match_add(dev, &match, compare_of, port->parent);
>> > + drm_of_component_match_add(dev, &match, compare_of,
>> > + port->parent);
>> > of_node_put(port);
>> > }
>> >
>> > diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
>> > index 2784919a7366..5e819876e642 100644
>> > --- a/drivers/gpu/drm/sti/sti_drv.c
>> > +++ b/drivers/gpu/drm/sti/sti_drv.c
>> > @@ -17,6 +17,7 @@
>> > #include <drm/drm_crtc_helper.h>
>> > #include <drm/drm_gem_cma_helper.h>
>> > #include <drm/drm_fb_cma_helper.h>
>> > +#include <drm/drm_of.h>
>> >
>> > #include "sti_crtc.h"
>> > #include "sti_drv.h"
>> > @@ -423,8 +424,8 @@ static int sti_platform_probe(struct platform_device *pdev)
>> > child_np = of_get_next_available_child(node, NULL);
>> >
>> > while (child_np) {
>> > - component_match_add(dev, &match, compare_of, child_np);
>> > - of_node_put(child_np);
>> > + drm_of_component_match_add(dev, &match, compare_of,
>> > + child_np);
>> > child_np = of_get_next_available_child(node, child_np);
>> > }
>> >
>> > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> > index 0da9862ad8ed..b3c4ad605e81 100644
>> > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
>> > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
>> > @@ -18,6 +18,7 @@
>> > #include <drm/drm_fb_cma_helper.h>
>> > #include <drm/drm_gem_cma_helper.h>
>> > #include <drm/drm_fb_helper.h>
>> > +#include <drm/drm_of.h>
>> >
>> > #include "sun4i_crtc.h"
>> > #include "sun4i_drv.h"
>> > @@ -239,7 +240,7 @@ static int sun4i_drv_add_endpoints(struct device *dev,
>> > /* Add current component */
>> > DRM_DEBUG_DRIVER("Adding component %s\n",
>> > of_node_full_name(node));
>> > - component_match_add(dev, match, compare_of, node);
>> > + drm_of_component_match_add(dev, match, compare_of, node);
>> > count++;
>> > }
>> >
>> > diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c b/drivers/gpu/drm/tilcdc/tilcdc_external.c
>> > index 68e895021005..06a4c584f3cb 100644
>> > --- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
>> > +++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
>> > @@ -10,6 +10,7 @@
>> >
>> > #include <linux/component.h>
>> > #include <linux/of_graph.h>
>> > +#include <drm/drm_of.h>
>> >
>> > #include "tilcdc_drv.h"
>> > #include "tilcdc_external.h"
>> > @@ -160,7 +161,8 @@ int tilcdc_get_external_components(struct device *dev,
>> >
>> > dev_dbg(dev, "Subdevice node '%s' found\n", node->name);
>> > if (match)
>> > - component_match_add(dev, match, dev_match_of, node);
>> > + drm_of_component_match_add(dev, match, dev_match_of,
>> > + node);
>> > of_node_put(node);
>> > count++;
>> > }
>> > diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
>> > index 3fd87b386ed7..d6b4c5587bbe 100644
>> > --- a/include/drm/drm_of.h
>> > +++ b/include/drm/drm_of.h
>> > @@ -4,6 +4,7 @@
>> > #include <linux/of_graph.h>
>> >
>> > struct component_master_ops;
>> > +struct component_match;
>> > struct device;
>> > struct drm_device;
>> > struct drm_encoder;
>> > @@ -12,6 +13,10 @@ struct device_node;
>> > #ifdef CONFIG_OF
>> > extern uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>> > struct device_node *port);
>> > +extern void drm_of_component_match_add(struct device *master,
>> > + struct component_match **matchptr,
>> > + int (*compare)(struct device *, void *),
>> > + struct device_node *node);
>> > extern int drm_of_component_probe(struct device *dev,
>> > int (*compare_of)(struct device *, void *),
>> > const struct component_master_ops *m_ops);
>> > @@ -25,6 +30,13 @@ static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
>> > return 0;
>> > }
>> >
>> > +static void drm_of_component_match_add(struct device *master,
>> > + struct component_match **matchptr,
>> > + int (*compare)(struct device *, void *),
>> > + struct device_node *node)
>> > +{
>> > +}
>> > +
>> > static inline int
>> > drm_of_component_probe(struct device *dev,
>> > int (*compare_of)(struct device *, void *),
>> > --
>> > 2.1.0
>> >
>> >
>> > _______________________________________________
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
^ permalink raw reply
* [PATCH v5 23/23] phy: Add support for Qualcomm's USB HS phy
From: Stephen Boyd @ 2016-10-20 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018015636.11701-24-stephen.boyd@linaro.org>
Quoting Stephen Boyd (2016-10-17 18:56:36)
> +
> +static int
> +qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
> + void *ptr)
> +{
> + struct qcom_usb_hs_phy *uphy;
> + int is_host;
> + u8 addr;
> +
> + uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
> + is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);
Please don't apply this patch. This call now deadlocks on v4.9-rc1
because of how extcon_get_cable_state_() now grabs a lock that is
already held here when we're inside the notifier. It's not really
required that we grab the lock in extcon there, but this has exposed a
flaw in the logic anyway. We don't know if the id pin is going to toggle
before or after this function is called, so we should really keep track
of both vbus and id state in this driver and then do the same ulpi
writes from two different notifiers for both vbus and id pin. We would
be duplicating work sometimes, but that's pretty much the best solution
I can come up with. Otherwise it's racy.
^ permalink raw reply
* [PATCH 2/2] clk: mxs: don't register a clkdev for enet_out
From: Stephen Boyd @ 2016-10-20 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020075840.16406-2-u.kleine-koenig@pengutronix.de>
On 10/20, Uwe Kleine-K?nig wrote:
> The last user is gone in the previous commit. So this can be removed, too.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
I'm fine if this goes through arm-soc if you want to bunch them
together. Otherwise just resend the patch once the ARM side
merges into some -rc1 and we can remove it in the next next
release.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 3/4] arm64: dts: msm8996: Add SMEM DT nodes
From: Stephen Boyd @ 2016-10-21 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477005139-15564-4-git-send-email-spjoshi@codeaurora.org>
On 10/20, Sarangdhar Joshi wrote:
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> Add SMEM and TCSR DT nodes on MSM8996.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index 949b096..abc1089 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -164,17 +164,36 @@
>
> };
>
> + tcsr_mutex: hwlock {
> + compatible = "qcom,tcsr-mutex";
> + syscon = <&tcsr_mutex_regs 0 0x1000>;
> + #hwlock-cells = <1>;
> + };
> +
> psci {
> compatible = "arm,psci-1.0";
> method = "smc";
> };
>
> + smem {
> + compatible = "qcom,smem";
> +
> + memory-region = <&smem_mem>;
> +
> + hwlocks = <&tcsr_mutex 3>;
Super nitpick: Is there a reason we have newlines between
everything in this node? This node is the only one that isn't
consistent.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [linux-sunxi] [PATCH v5 3/4] Documentation: devicetree: add vendor prefix for Pine64
From: Jonathan Liu @ 2016-10-21 0:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <73852fb92ac0aeec294dc9883cf235d9fa74a07b.1476986335.git-series.maxime.ripard@free-electrons.com>
On 21 October 2016 at 05:00, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> From: Andre Przywara <andre.przywara@arm.com>
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> [Maxime: Change title prefix to match the usual style]
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index f0a48ea78659..4eefd1c3ff16 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -208,7 +208,7 @@ parade Parade Technologies Inc.
> pericom Pericom Technology Inc.
> phytec PHYTEC Messtechnik GmbH
> picochip Picochip Ltd
> -pixcir PIXCIR MICROELECTRONICS Co., Ltd
Why is "pixcir PIXCIR MICROELECTRONICS Co., Ltd" removed?
> +pine64 Pine64
> plathome Plat'Home Co., Ltd.
> plda PLDA
> powervr PowerVR (deprecated, use img)
> --
> git-series 0.8.10
Regards,
Jonathan
^ permalink raw reply
* [PATCH 6/8] pinctrl: aspeed-g4: Capture SuperIO pinmux dependency
From: Andrew Jeffery @ 2016-10-21 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYLDesENtq2cQBrWQeL6NH+mO_N5Z=e9=gsoZSCE85Jag@mail.gmail.com>
Hi Linus,
On Thu, 2016-10-20 at 13:53 +0200, Linus Walleij wrote:
> On Tue, Sep 27, 2016 at 4:50 PM, Andrew Jeffery <andrew@aj.id.au>
> wrote:
>
> >
> > Two LPC-related signals in the AST2400 depend on state in the
> > SuperIO IP
> > block. Use the recently added infrastructure to capture this
> > relationship.
> >
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Patch applied for v4.10.
> (Tell me if I'm applying patches in wrong order or something, and
> I hope this doesn't clash with the fixes.)
Both this patch and 8/8 functionally depend on 5/8. I fetched the
pinctrl tree to poke around but this patch didn't appear in any of the
updated branches, so I'm not sure whether we have the right ordering.
Without it we should hit build failures from missing macro definitions.
Have you had a chance to look over patch 5/8? Joel wasn't keen on its
current form, so I would appreciate your input.
Cheers,
Andrew
>
> Yours,
> Linus Walleij
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161021/07de7adc/attachment.sig>
^ permalink raw reply
* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Bjorn Helgaas @ 2016-10-21 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0gE8uZ4NfuJVtuzkioJS0TpG2mvgJV3o3j0oM7WsVmh7w@mail.gmail.com>
On Thu, Oct 20, 2016 at 01:17:23AM +0200, Rafael J. Wysocki wrote:
> On Thu, Oct 20, 2016 at 12:44 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Oct 18, 2016 at 08:32:44AM -0700, Sinan Kaya wrote:
> >> Sorry, I think I didn't have enough morning coffee.
> >>
> >> Looking at these again and trying to be specific.
> >>
> >> On 10/18/2016 8:20 AM, Sinan Kaya wrote:
> >> > It seems wrong to me that we call acpi_irq_get_penalty() from
> >> >> acpi_irq_penalty_update() and acpi_penalize_isa_irq(). It seems like they
> >> >> should just manipulate acpi_isa_irq_penalty[irq] directly.
> >> >>
> >> >> acpi_irq_penalty_update() is for command-line parameters, so it certainly
> >> >> doesn't need the acpi_irq_pci_sharing_penalty() information (the
> >> >> acpi_link_list should be empty at the time we process the command-line
> >> >> parameters).
> >>
> >> Calling acpi_irq_get_penalty for ISA IRQ is OK as long as it doesn't have
> >> any dynamic IRQ calculation such that acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty.
> >>
> >> If this is broken, then we need special care so that we don't assign
> >> dynamically calcualted sci_penalty back to acpi_isa_irq_penalty[irq]. This
> >> results in returning incorrect penalty as
> >>
> >> acpi_irq_get_penalty = acpi_isa_irq_original_penalty[irq] + 2 * sci_penalty.
> >>
> >> Now that we added sci_penalty into the acpi_irq_get_penalty function,
> >> calling acpi_irq_get_penalty is not correct anymore. This line here needs to
> >> be replaced with acpi_isa_irq_penalty[irq] as you suggested.
> >>
> >> if (used)
> >> new_penalty = acpi_irq_get_penalty(irq) +
> >> PIRQ_PENALTY_ISA_USED;
> >> else
> >> new_penalty = 0;
> >>
> >> acpi_isa_irq_penalty[irq] = new_penalty;
> >>
> >>
> >> >>
> >> >> acpi_penalize_isa_irq() is telling us that a PNP or ACPI device is using
> >> >> the IRQ -- this should modify the IRQ's penalty, but it shouldn't depend on
> >> >> the acpi_irq_pci_sharing_penalty() value at all.
> >> >>
> >>
> >> Same problem here. This line will be broken after the sci_penalty change.
> >>
> >> acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> >> (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
> >
> > I think the fragility of this code is an indication that we have a
> > design problem, so I want to step back from the nitty gritty details
> > for a bit and look at the overall design.
> >
> > Let me restate the overall problem: We have a PCI device connected to
> > an interrupt link. The interrupt link can be connected to one of
> > several IRQs, and we want to choose one of those IRQs to minimize IRQ
> > sharing.
> >
> > That means we need information about which IRQs are used.
> > Historically we've started with a compiled-in table of common ISA IRQ
> > usage, and we also collect information about which IRQs are used and
> > which *might* be used. So we have the following inputs:
> >
> > - Compiled-in ISA IRQ usage: the static acpi_isa_irq_penalty[]
> > values. ACPI is *supposed* to tell us about all these usages, so
> > I don't know why we have the table. But it's been there as long
> > as I can remember. The table is probably x86-specific, but we
> > keep it in the supposedly generic pci_link.c.
> >
> > - The "acpi_irq_isa=" and "acpi_irq_pci=" command-line overrides via
> > acpi_irq_pci(). I suppose these are for cases where we can't
> > figure things out automatically. I would resist adding parameters
> > like this today (I would treat the need for them as a bug and look
> > for a fix or a quirk), but we might be stuck with these.
> >
> > - SCI information from the ACPI FADT (acpi_penalize_sci_irq()).
> >
> > - PNPBIOS and PNPACPI device IRQ usage from _CRS and _PRS via
> > acpi_penalize_isa_irq(). This is only for IRQs 0-15, and it does
> > NOT include interrupt link (PNP0C0F) devices because we don't
> > handle them as PNPACPI devices. I think this is related to the
> > fact that PNP0C0F doesn't appear in acpi_pnp_device_ids[].
> >
> > - For non-PNP0C0F, non-PNPACPI devices, we completely ignore IRQ
> > information from _CRS and _PRS. This seems sub-optimal and
> > possibly buggy.
> >
> > - Interrupt link (PNP0C0F) IRQ usage from _CRS and _PRS via
> > acpi_irq_penalty_init(). This is only for IRQs 0-15, and we only
> > call this on x86. If _PRS exists, we penalize each possible IRQ.
> > If there's no _PRS but _CRS contains an active IRQ, we penalize
> > it.
> >
> > - Interrupt link (PNP0C0F) IRQ usage from _CRS and _PRS when
> > enabling a new link. In acpi_irq_pci_sharing_penalty(), we
> > penalize an IRQ if it appears in _CRS or _PRS of any link device
> > in the system.
> >
> > For IRQs 0-15, this overlaps with the penalization done at
> > boot-time by acpi_irq_penalty_init(): if a device has _PRS, we'll
> > add the "possible" penalty twice (once in acpi_irq_penalty_init()
> > and again in acpi_irq_pci_sharing_penalty()), and the "using"
> > penalty once (in acpi_irq_pci_sharing_penalty()).
> >
> > If a device has no _PRS but has _CRS, the "using" penalty is
> > applied twice (once in once in acpi_irq_penalty_init() and again
> > in acpi_irq_pci_sharing_penalty())
> >
> > I think this whole thing is baroque and grotesque.
>
> While I agree, I also would like the regression introduced here to be
> fixed ASAP.
>
> So do you want me to revert all of the changes made here so far and start over?
You're right, of course. We need to fix the regression first, then
worry about longer-term changes. I don't think we necessarily need to
fix *all* the issues with the current scheme, because most of them
have been there forever and I don't think people are tripping over
them.
Bjorn
^ permalink raw reply
* [PATCH] kernel: irq: fix build failure
From: Stephen Rothwell @ 2016-10-21 1:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1610201454410.5073@nanos>
Hi Thomas,
On Thu, 20 Oct 2016 14:55:45 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Mon, 10 Oct 2016, Sudip Mukherjee wrote:
>
> > On Thursday 06 October 2016 11:06 PM, Sudip Mukherjee wrote:
> > > The allmodconfig build of powerpc is failing with the error:
> > > ERROR: ".irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
> > >
> > > export the symbol to fix the failure.
> >
> > Hi Thomas,
> > powerpc and arm allmodconfig builds still fails with the same error.
> > Build logs of next-20161010 are at:
> > arm at https://travis-ci.org/sudipm-mukherjee/parport/jobs/166321467
> > powerpc at https://travis-ci.org/sudipm-mukherjee/parport/jobs/166321473
>
> I know. This is under discussion with the driver folks as we are not going
> to blindly export stuff just because someone slapped a irq_set_parent()
> into the code w/o knowing why.
Do we have any idea if a resolution is close. This was first reported
in linux-next in September 14/15. :-(
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH] ARM: imx: gpc: Initialize all power domains
From: Fabio Estevam @ 2016-10-21 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CORjf_86-XBy+STd4sEhcus8y1G4B-n58h3KNyuVyEew@mail.gmail.com>
On Thu, Oct 20, 2016 at 3:29 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Shawn,
>
> On Wed, Oct 19, 2016 at 12:15 PM, Shawn Guo <shawnguo@kernel.org> wrote:
>
>> It's not clear to me why this is only with multi_v7_defconfig, not
>> imx_v6_v7_defconfig. Also, is it a regression or long-standing issue?
>
> Investigated this a bit further and the problem seems to be in the
> power domain driver.
>
> The change below fixes the problem on mx6:
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index e023066..461d03c 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -1572,8 +1572,6 @@ int of_genpd_add_provider_onecell(struct device_node *np,
> for (i = 0; i < data->num_domains; i++) {
> if (!data->domains[i])
> continue;
> - if (!pm_genpd_present(data->domains[i]))
> - goto error;
>
> data->domains[i]->provider = &np->fwnode;
> data->domains[i]->has_provider = true;
>
> , will submit this to the power domain folks.
Actually the above change would go against:
Author: Jon Hunter <jonathanh@nvidia.com>
Date: Mon Sep 12 12:01:10 2016 +0100
PM / Domains: Verify the PM domain is present when adding a provider
When a PM domain provider is added, there is currently no way to tell if
any PM domains associated with the provider are present. Naturally, the
PM domain provider should not be registered if the PM domains have not
been added. Nonetheless, verify that the PM domain(s) associated with a
provider are present when registering the PM domain provider.
This change adds a dependency on the function pm_genpd_present() when
CONFIG_PM_GENERIC_DOMAINS_OF is enabled and so ensure this function is
available when CONFIG_PM_GENERIC_DOMAINS_OF selected.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
,so it seems the original patch in this thread is correct.
I will update the commit log and submit a v2.
^ permalink raw reply
* [PATCH v7 3/5] ARM: dts: imx6qdl-icore: Add usbhost support
From: Shawn Guo @ 2016-10-21 1:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476437243-13297-4-git-send-email-jteki@openedev.com>
On Fri, Oct 14, 2016 at 02:57:21PM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Add usbhost support for Engicam i.CoreM6 dql modules.
>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v7:
> - none
> Changes for v6:
> - none
> Changes for v5:
> - none
> Changes for v4:
> - new patch
>
> arch/arm/boot/dts/imx6qdl-icore.dtsi | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> index f424cd5..ffec879 100644
> --- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> @@ -56,6 +56,15 @@
> regulator-boot-on;
> regulator-always-on;
> };
> +
> + reg_usb_h1_vbus: usb_h1_vbus {
Hyphen instead of underscore should be used in node name. Also please
name fixed regulator in the following schema:
reg_xxx: regulator-xxx {
...
};
Shawn
> + compatible = "regulator-fixed";
> + regulator-name = "usb_h1_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> };
>
> &can1 {
> @@ -109,6 +118,12 @@
> status = "okay";
> };
>
> +&usbh1 {
> + vbus-supply = <®_usb_h1_vbus>;
> + disable-over-current;
> + status = "okay";
> +};
> +
> &usdhc1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc1>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v7 4/5] ARM: dts: imx6qdl-icore: Add usbotg support
From: Shawn Guo @ 2016-10-21 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476437243-13297-5-git-send-email-jteki@openedev.com>
On Fri, Oct 14, 2016 at 02:57:22PM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Add usbotg support for Engicam i.CoreM6 dql modules.
>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v7:
> - none
> Changes for v6:
> - none
> Changes for v5:
> - none
> Changes for v4:
> - new patch
>
> arch/arm/boot/dts/imx6qdl-icore.dtsi | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> index ffec879..4e79858 100644
> --- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> @@ -65,6 +65,15 @@
> regulator-boot-on;
> regulator-always-on;
> };
> +
> + reg_usb_otg_vbus: usb_otg_vbus {
Same as host patch, please fix the node name.
Shawn
> + compatible = "regulator-fixed";
> + regulator-name = "usb_otg_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> };
>
> &can1 {
> @@ -124,6 +133,14 @@
> status = "okay";
> };
>
> +&usbotg {
> + vbus-supply = <®_usb_otg_vbus>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usbotg>;
> + disable-over-current;
> + status = "okay";
> +};
> +
> &usdhc1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_usdhc1>;
> @@ -198,6 +215,12 @@
> >;
> };
>
> + pinctrl_usbotg: usbotggrp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
> + >;
> + };
> +
> pinctrl_usdhc1: usdhc1grp {
> fsl,pins = <
> MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17070
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2] ARM: imx: gpc: Initialize all power domains
From: Fabio Estevam @ 2016-10-21 1:28 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
Since commit 0159ec670763dd ("PM / Domains: Verify the PM domain is present
when adding a provider") the following regression is observed on imx6:
imx-gpc: probe of 20dc000.gpc failed with error -22
The imx-gpc driver probe failure causes several issues such as:
- When booting a kernel built with multi_v7_defconfig a kernel crash is
seen.
- When booting a kernel built with imx_v6_v7_defconfig the Etnaviv GPU
driver is not loaded due to the lack of power domains.
The gpc probe fails because of_genpd_add_provider_onecell() now checks
if all the domains are initialized via pm_genpd_present() function
and it fails because not all the power domains are initialized.
In order to fix this error, initialize all the power domains from
imx_gpc_domains[], not only the imx6q_pu_domain.base one.
Reported-by: Olof's autobooter <build@lixom.net>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/mach-imx/gpc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 0df062d..d0463e9 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -430,7 +430,8 @@ static int imx_gpc_genpd_init(struct device *dev, struct regulator *pu_reg)
if (!IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS))
return 0;
- pm_genpd_init(&imx6q_pu_domain.base, NULL, false);
+ for (i = 0; i < ARRAY_SIZE(imx_gpc_domains); i++)
+ pm_genpd_init(imx_gpc_domains[i], NULL, false);
return of_genpd_add_provider_onecell(dev->of_node,
&imx_gpc_onecell_data);
--
2.7.4
^ permalink raw reply related
* [PATCH v7 5/5] ARM: dts: imx6qdl-icore: Add FEC support
From: Shawn Guo @ 2016-10-21 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476437243-13297-6-git-send-email-jteki@openedev.com>
On Fri, Oct 14, 2016 at 02:57:23PM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Add FEC support for Engicam i.CoreM6 dql modules.
>
> Observed similar 'eth0: link is not ready' issue which was
> discussed in [1] due rmii mode with external ref_clk, so added
> clock node along with the properties mentioned by Shawn in [2]
>
> FEC link log:
> ------------
> $ ifconfig eth0 up
> [ 27.905187] SMSC LAN8710/LAN8720 2188000.ethernet:00: attached PHY driver
> [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=2188000.ethernet:00, irq=-1)
> [ 27.918982] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>
> [1] https://patchwork.kernel.org/patch/3491061/
> [2] https://patchwork.kernel.org/patch/3490511/
>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v7:
> - none
> Changes for v6:
> - none
> Changes for v5:
> - new patch
>
> arch/arm/boot/dts/imx6qdl-icore.dtsi | 37 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> index 4e79858..972f48f 100644
> --- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> @@ -48,6 +48,18 @@
> reg = <0x10000000 0x80000000>;
> };
>
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
DT maintainers do not like this container node. So please, just like
fix regulator node, put the fixed clock directly under root and give the
node an unique name like clock-xxx.
> +
> + rmii_clk: clock at 0 {
> + compatible = "fixed-clock";
> + reg = <0>;
> + #clock-cells = <0>;
> + clock-frequency = <25000000>; /* 25MHz for example */
> + };
> + };
> +
> reg_3p3v: regulator-3p3v {
> compatible = "regulator-fixed";
> regulator-name = "3P3V";
> @@ -93,6 +105,15 @@
> assigned-clock-parents = <&clks IMX6QDL_CLK_OSC>;
> };
>
> +&fec {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet>;
> + phy-reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> + clocks = <&clks 117>, <&clks 117>, <&rmii_clk>;
s/117/IMX6QDL_CLK_ENET
Shawn
> + phy-mode = "rmii";
> + status = "okay";
> +};
> +
> &gpmi {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_gpmi_nand>;
> @@ -150,6 +171,22 @@
> };
>
> &iomuxc {
> + pinctrl_enet: enetgrp {
> + fsl,pins = <
> + MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
> + MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x1b0b1
> + MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
> + MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
> + MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
> + MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
> + MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> + MX6QDL_PAD_ENET_REF_CLK__GPIO1_IO23 0x1b0b0
> + MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
> + >;
> + };
> +
> pinctrl_flexcan1: flexcan1grp {
> fsl,pins = <
> MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b020
> --
> 2.7.4
>
^ 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